The latest release of the Percona Operator for MongoDB, 1.22.0 is here. It brings automatic storage resizing, HashiCorp Vault integration for system user credentials, better integration with service meshes, improved backup and restore options, and more. This post walks through the highlights and how they can help your MongoDB deployments on Kubernetes.
Percona Operator for MongoDB 1.22.0
Automatic Storage Resizing
Running out of disk space is a common cause of outages. Starting with 1.22.0, the Operator can automatically resize Persistent Volume Claims (PVCs) for replica sets and config server pods based on configurable thresholds.
The Operator monitors storage usage and, when it exceeds your threshold, triggers resizing up to a maximum size you define.
You get:
- Fewer outages from full disks
- Less guesswork in capacity planning
- Lower operational overhead
- Cost control by expanding only when needed
Enable it in your Custom Resource:
|
1 2 3 4 5 6 7 8 |
spec: storageScaling: enableVolumeScaling: true autoscaling: enabled: true triggerThresholdPercent: 80 growthStep: 2Gi maxSize: "10Gi" |
See the documentation for the full workflow and troubleshooting.
Vault Integration for System User Password Management
You can now integrate the Operator with HashiCorp Vault for system user password management. Credentials stay centralized in Vault while the Operator applies them to the database.
When enabled, the Operator authenticates to Vault (Kubernetes auth or token), retrieves system user passwords at cluster creation, and creates the corresponding Kubernetes Secret. It also periodically checks Vault for changes and updates the Secret. If Vault is temporarily unavailable, the Operator logs the event and continues reconciling so cluster availability is not affected.
This helps when you need:
- Centralized credential governance
- Auditable password rotation
- Compliance with internal security policies
- Separation of duties (DBAs vs security team)
- Consistent password lifecycle across environments
Vault is the single source of truth; the Operator ensures Percona Server for MongoDB uses the right credentials. See the documentation for setup.
Service Mesh Integration
Ensure smooth integration with service meshes
The Operator now supports the Kubernetes appProtocol field and automatically sets the mongo application layer protocol on all services it creates.
This is a highly requested feature within the community and has been consistently brought up by users. For clusters running with service meshes such as Istio, the mesh can now correctly recognize and handle MongoDB traffic. The result is reliable cluster formation and proper mutual TLS (mTLS) for MongoDB in Kubernetes.
Logcollector Improvement: Configure Log Rotation for Persistent Logs
When persistent logging is enabled, MongoDB and logcollector logs can grow quickly and fill disk if left unchecked, or you may need to retain logs for a specific period for compliance or post-incident analysis, while the default rotation schedule and retention don’t match your requirements. You can now customize log rotation for persistent logs so that retention and schedule fit your environment.
This helps you:
- Override the default configuration via the Custom Resource
- Add your own rules via a ConfigMap or Secret (the Operator merges them with the default)
- Set a new rotation schedule
See the documentation for step-by-step configuration.
Backup and Restore
Restore to a Cluster with Different Replica Set Names
You can run physical and logical restores to clusters that use replica set names different from the source. Define source-to-target mappings in your PerconaServerMongoDBRestore object:
|
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: psmdb.percona.com/v1 kind: PerconaServerMongoDBRestore metadata: name: restore-with-remapping spec: clusterName: some-name-target backupName: backup1 replsetRemapping: shard0: rs0 shard1: rs1 csReplSet: cfg |
Inside replsetRemapping, the keys are source replica set names, and the values are target replica set names. This makes recovery more flexible across environments.
See the documentation for step-by-step configuration.
Configurable Timeout for PBM to Start Backups
You can configure how long the Operator waits for PBM to report that a backup has started, via startingDeadlineSeconds in the Custom Resource (default 120 seconds).
This helps:
- Avoid false backup failures when PBM starts slowly under load
- Give PBM enough time in resource-constrained environments
- Keep backup flows predictable in large or memory-intensive clusters
Support of the MinIO Storage Type for S3-Compatible storage service
The Operator adds a minio storage type for backups to S3-compatible storage. PBM uses the native MinIO SDK, which helps when your S3-compatible service does not support Signature Version 4 (SigV4) used by AWS SDK v2.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
backup: storages: minio: type: minio minio: bucket: MINIO-BACKUP-BUCKET-NAME-HERE region: us-east-1 credentialsSecret: my-cluster-name-backup-minio endpointUrl: minio.psmdb.svc.cluster.local:9000/minio/ insecureSkipTLSVerify: false prefix: "" secure: false |
Private CA for TLS with S3-Compatible Storage
You can provide a Private Certificate Authority (CA) bundle to verify TLS to S3-compatible storage. Create a Secret with your private CA (and any client certificates), then reference it and the CA key in the caBundle option in the Custom Resource. The Operator uses it to verify TLS. Use the minio storage type for this. Multiple storages can each use their own private CA certificates. These certificates are merged into a single file as needed
Cluster Readiness Now Reflects PBM State
The PerconaServerMongoDB Custom Resource status now includes a PBMReady condition. Automation can rely on this to know when PBM has finished processing all configured storages before triggering backups or other operations.
Check it with kubectl describe psmdb <cluster-name> or kubectl get psmdb <cluster-name> -o yaml. During initialization or config changes, it is False with a reason. When PBM is fully configured, it becomes True.
Additional Customization Features
Hook Script Support
The hookScript option lets you run a custom shell script before mongod, mongos, or a pbm-agent starts without custom images or Operator changes. You can define the script inline or via a ConfigMap. It runs in the container and can block startup if it exits with a non-zero status.
Supported for replica set members (including hidden, arbiter, and non-voting), config server replica set, and mongos pods. Use cases include fetching external secrets, security checks, adjusting config files, downloading external tools, or registering nodes in external systems. It can be really useful for some debugging or advanced deployments.
Ability to Define Custom Environment Variables
You can set custom environment variables for mongod, mongos, and logcollector to control behavior without hardcoding values in manifests. Use them to:
- Pass non-sensitive flags to custom entrypoints
- Provide credentials or API tokens from a Secret
Variables can be set directly in the Custom Resource, via a ConfigMap, or via a Secret, so you can keep one manifest and inject values per environment.
Deprecation: PMM2 Support
The Operator deprecates support for PMM2, as that version has reached end-of-life. PMM2 remains available so you can still monitor existing setups, but we encourage planning migration to PMM3 for recent features and fixes. Support for PMM2 will be dropped in two releases. See the PMM upgrade documentation for migration steps.
Conclusion
Percona Operator for MongoDB 1.22.0 adds automatic storage resizing, Vault integration for system users, service mesh–friendly appProtocol, more flexible backup and restore (including replica set remapping and PBM readiness), configurable log rotation, hook scripts, and custom environment variables. PMM2 is deprecated with removal in two releases.
We encourage you to read the full release notes and try the new features. Feedback is welcome on the GitHub repository or the Community Forum.
About the Author
Slava SarzhanSenior Cloud Engineering Manager from Lviv, Ukraine, with a passion for building smarter, more efficient Kubernetes solutions. I joined Percona in January 2019, starting as a build/release engineer managing Jenkins farms and automating testing and release processes. Soon after, I moved to the cloud team, creating testing infrastructure and developing new features for Kubernetes operators. Over the years, I’ve grown into leadership, guiding distributed engineering teams to deliver scalable, production-ready solutions while fostering a culture of ownership, clarity, and continuous improvement. Kubernetes isn’t just a tool for me, it’s a playground for innovation. I focus on solving complex problems, improving systems, and sharing insights with the community.
