Skip to Main Content

MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Status Future Consideration
Categories Kubernetes
Created by Vishal Katikineni
Created on Jul 30, 2026

Allow custom annotations on the internal (headless) per-pod Services created by the MongoDB CR

What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

When deploying a MongoDB resource with topology: MultiCluster (replica set or sharded cluster) and relying on a CNI-level mesh for cross-cluster connectivity — e.g. Cilium ClusterMesh — instead of externalAccess/externalDomain, the mesh needs mesh-specific annotations on the operator-created internal per-pod Services (the headless -svc objects, e.g. <name>-<shard>-<cluster>-<pod>-svc, <name>-config-<cluster>-<pod>-svc, <name>-mongos-<cluster>-<pod>-svc). For Cilium these are service.cilium.io/global: "true" and service.cilium.io/shared: "true".

The MongoDB CR exposes no way to set annotations on these internal Services. The only annotation field, spec.externalAccess.externalService.annotations, applies exclusively to external LoadBalancer/NodePort services. There is therefore no supported injection point for internal-service annotations, even though the sibling MongoDBOpsManager CR already supports this via spec.internalConnectivity.

What would you like to see happen?

Describe the desired outcome or enhancement.

Add a field to annotate the operator-managed internal Services, mirroring the existing MongoDBOpsManager spec.internalConnectivity capability. Concretely:

  • spec.internalConnectivity.annotations at the top level of the MongoDB CR, and

  • per-cluster / per-component siblings alongside the existing externalAccess block under spec.shard.clusterSpecList[], spec.configSrv.clusterSpecList[], and spec.mongos.clusterSpecList[] (and the equivalent for replica-set clusterSpecList[]),

  • ideally supporting the same per-pod placeholder substitution already available for external-service annotations.

The operator should merge these annotations onto the internal Services it creates and preserve them across reconciles (not overwrite them on the next reconcile loop).

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

CNI-mesh multi-cluster (Cilium ClusterMesh, and similar) is a supported, lower-overhead alternative to externalAccess + externalDomain, which otherwise forces external DNS, per-pod external services, and per-pod TLS SANs. Cilium "global services" require the annotations to live on the internal Services, so without a CR field this topology cannot be expressed declaratively.

This matters at scale: a multi-cluster sharded cluster produces (shards × clusters × replicas) + config servers + mongos internal Services, all of which need the annotation. Managing that outside the CR is fragile, and because the operator reconciles these Services it silently reverts any externally-applied annotations. A first-class field makes mesh-based multi-cluster deployments declarative, reconcile-safe, and consistent with how MongoDBOpsManager already works.

What steps, if any, are you taking today to manage this problem?