[CLOUDP-341578] Update client-go and related module to version to v0.31.11

[viveksinghggits]

Summary

As part of the release process we are planning to upgrade the client-go version to 0.31.11. This PR does that. Just updating the client-go results into a compatibility issue with controller-runtime,

# sigs.k8s.io/controller-runtime/pkg/internal/controller
../../../go/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.7/pkg/internal/controller/controller.go:103:9: not enough arguments in call to fn
        have (interface{})
        want (context.Context, interface{})
# sigs.k8s.io/controller-runtime/pkg/webhook/admission
../../../go/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.7/pkg/webhook/admission/webhook.go:158:9: not enough arguments in call to fn
        have (interface{})
        want (context.Context, interface{})

that's why we are also updating controller-runtime to newer version (v0.19.4).

Updating controller-runtime was a breaking because most of the utilities now are typed (using generics) that why we had to make respective go file changes.

Proof of Work

Running go build in the root of the repo works, that makes sure that we are able to build the binary. Apart from that I also ran go test in the dirs where I am changing the test files and that worked as well.

~/work/opensource/mongodb-kubernetes/mongodb-community-operator/controllers/watch (update-client-go) » go test -run TestWatcher                                  vivek.s@M-HYXVRF7WDG
PASS
ok      github.com/mongodb/mongodb-kubernetes/mongodb-community-operator/controllers/watch      0.374s

~/work/opensource/mongodb-kubernetes/controllers/operator (update-client-go*) » go test -run TestMongoDBSearchReconcile_Success                              1 ↵ vivek.s@M-HYXVRF7WDG
2025-08-26T12:17:41.620+0200    INFO    operator/mongodbsearch_controller.go:46 -> MongoDBSearch.Reconcile      {"MongoDBSearch": "my-namespace/search"}
2025-08-26T12:17:41.621+0200    INFO    search_controller/mongodbsearch_reconcile_helper.go:73  Reconciling MongoDBSearch       {"MongoDBSearch": "my-namespace/search", "MongoDBSearch": "my-namespace/search"}
2025-08-26T12:17:41.621+0200    DEBUG   search_controller/mongodbsearch_reconcile_helper.go:140 Updated search service my-namespace/search-search-svc: created
2025-08-26T12:17:41.621+0200    DEBUG   search_controller/mongodbsearch_reconcile_helper.go:166 Updated mongot config yaml config map: my-namespace/search-search-config (created) with the following configuration: communityPrivatePreview:
  dataPath: /mongot/data/config.yml
  keyFilePath: /mongot/keyfile/keyfile
  logging:
    verbosity: DEBUG
  metrics:
    address: localhost:9946
    enabled: true
  mongodHostAndPort: mdb-svc.my-namespace.svc.cluster.local:27017
  queryServerAddress: localhost:27027

2025-08-26T12:17:41.621+0200    DEBUG   search_controller/mongodbsearch_reconcile_helper.go:122 Search statefulset my-namespace/search-search CreateOrUpdate result: created    {"MongoDBSearch": "my-namespace/search", "MongoDBSearch": "my-namespace/search"}
2025-08-26T12:17:41.623+0200    DEBUG   inspect/statefulset_inspector.go:32     StatefulSet search-search (wanted: 1, ready: 0, updated: 0, generation: 0, observedGeneration: 0)
2025-08-26T12:17:41.623+0200    DEBUG   commoncontroller/resourcestatus.go:25   Updating status: phase=Pending, options=[{Message:StatefulSet not ready} {Warnings:[]} {ResourcesNotReady:[{Kind:StatefulSet Name:search-search Errors:[] Message:Not all the Pods are ready (wanted: 1, updated: 0, ready: 0, current: 0)}]}]        {"MongoDBSearch": "my-namespace/search"}
PASS
ok      github.com/mongodb/mongodb-kubernetes/controllers/operator      0.835s

Checklist

• Have you linked a jira ticket and/or is the ticket in the title?
• Have you checked whether your jira ticket required DOCSP changes?
• Have you added changelog file?
  • use skip-changelog label if not needed
  • refer to Changelog files and Release Notes section in CONTRIBUTING.md for more details

[github-actions]

⚠️ (this preview might not be accurate if the PR is not rebased on current master branch)

MCK 1.3.0 Release Notes

New Features

Multi-Architecture Support

We've added comprehensive multi-architecture support for the kubernetes operator. This enhancement enables deployment on IBM Power (ppc64le) and IBM Z (s390x) architectures alongside
existing x86_64 support. Core images (operator, agent, init containers, database, readiness probe) now support multiple architectures. We do not add support IBM and ARM support for Ops-Manager and the init-ops-manager image.

Bug Fixes

• This change fixes the current complex and difficult-to-maintain architecture for stateful set containers, which relies on an "agent matrix" to map operator and agent versions which led to a sheer amount of images.
• We solve this by shifting to a 3-container setup. This new design eliminates the need for the operator-version/agent-version matrix by adding one additional container containing all required binaries. This architecture maps to what we already do with the mongodb-database container.
• Fixed an issue where the readiness probe reported the node as ready even when its authentication mechanism was not in sync with the other nodes, potentially causing premature restarts.

Other Changes

• Optional permissions for PersistentVolumeClaim moved to a separate role. When managing the operator with Helm it is possible to disable permissions for PersistentVolumeClaim resources by setting operator.enablePVCResize value to false (true by default). When enabled, previously these permissions were part of the primary operator role. With this change, permissions have a separate role.
• subresourceEnabled Helm value was removed. This setting used to be true by default and made it possible to exclude subresource permissions from the operator role by specifying false as the value. We are removing this configuration option, making the operator roles always have subresource permissions. This setting was introduced as a temporary solution for this OpenShift issue. The issue has since been resolved and the setting is no longer needed.
• We have deliberately not published the container images for OpsManager versions 7.0.16, 8.0.8, 8.0.9 and 8.0.10 due to a bug in the OpsManager which prevents MCK customers to upgrade their OpsManager deployments to those versions.

[anandsyncs]

@viveksinghggits I think that it makes sense to add a ticket for this

[viveksinghggits]

@viveksinghggits I think that it makes sense to add a ticket for this

Sure, I will create and link the ticket Anand.

[lucian-tosa]

1.34 was released last week, this means that the lowest version we support is now 1.32. Should we update the libraries again?

[mircea-cosbuc]

1.34 was released last week, this means that the lowest version we support is now 1.32. Should we update the libraries again?

Based on our versioning policy (https://wiki.corp.mongodb.com/spaces/MMS/pages/193108905/Kubernetes+Operators+Versioning), we don't support 1.34 yet. We can only start supporting 2m after release, thus we don't need to change it again in this PR.

[viveksinghggits]

1.34 was released last week, this means that the lowest version we support is now 1.32. Should we update the libraries again?

"All three Operators (AKO, MCO and MEKO) aim to provide support for the latest Kubernetes release as the highest supported version, as long as that version of Kubernetes is released 2 months or more ahead of the release of an Operator version."

"The lowest supported Kubernetes version is 2 versions below the highest supported version. I.e. if the highest supported Kubernetes version is 1.29, then the lowest supported version is 1.29-2 = 1.27."

If I understood these two statements from the document https://wiki.corp.mongodb.com/spaces/MMS/pages/193108905/Kubernetes+Operators+Versioning correctly, it means that we (MCK) don't necessarily have to support a K8s version as soon as it's released. It's ok to have the K8s version that was released 2 months back (let's say x) as latest supported version of my MCK. And then x-2 would be the least supported version.

I raised the PR considering above statements, but I was a little confused and that's why I commented here https://docs.google.com/document/d/1eJ8iKsI0libbpcJakGjxcPfbrTn8lmcZDbQH1UqMR_g/edit?disco=AAABp7ADmA4, but we can change the module version to 0.32 as well, if thats suites our policy better. cc @mircea-cosbuc

[viveksinghggits]

I didn't notice, @mircea-cosbuc's comment. And I think said the same thing.

[lucian-tosa]

got it, thanks