percona/percona-server-mongodb-operator v1.23.1

on GitHub

Release Highlights

Persistent logging for mongos

mongos is the query router in a sharded cluster. Its logs record connection failures, slow queries, authentication errors, and which shard received a query.

Starting with this release, persistent logging also covers mongos Pods. This enables you to see what the
router did after a rollout, an out-of-memory restart, a node
drain or another incident.

The Operator adds the logs (Fluent Bit) and logrotate sidecars to each mongos Pod. Those logs survive a Pod restart only when you configure the storage for them via the sharding.mongos.logs.persistentVolumeClaim section in the Custom Resource. The Operator then creates one Persistent Volume Claim (PVC) per mongos Pod and stores the log file on that volume.

Resize that PVC the same way you resize storage for replica set and config server Pods. Automatic storage resizing for mongos is not supported yet.

If you turn persistent logging off, the Operator removes the sidecars but keeps existing mongos log PVCs. Files already on the volume stay readable.

logrotate uses one cluster-wide policy for mongod and mongos. It rotates logs daily, when they exceed 100 MB and keeps up to 7 rotated files. When you change that policy, include the configuration for both mongod and mongos.

Read more in the persistent logging and log rotation documentation.

Control how often the Operator contacts HashiCorp Vault

When you store system user passwords in HashiCorp Vault, you can now configure how often the Operator reaches Vault to read those passwords and to sign in. The Operator creates a Vault client to sign in, and uses it for password reads.

Use these options in the Custom Resource:

• vault.requestInterval sets how often the Operator reads passwords from Vault. A longer interval sends fewer requests when passwords change infrequently. Leave it unset to read Vault on every reconciliation.
• vault.reinitInterval sets how often the Operator creates a new Vault client and signs in again. Shorten it when your Vault tokens expire quickly. The default is 30 minutes.

If you update the Vault token in vault.syncUsers.tokenSecret, the Operator creates a new Vault client on the next reconciliation and uses that token.

spec:
  vault:
    reinitInterval: 30m
    requestInterval: 1m

Learn more in Manage system users with Vault.

CRD Changes

• The .status.oci.credentials.secretName field has now the minimum length of 1 and maximum length of 253. An empty name is rejected, and a name longer than 253 characters is rejected.

• The status.oci.credentials field requires the secretName to be present when credentials.type is userPrincipal.

• New fields added:

  • sharding.mongos.logs.persistentVolumeClaim to configure persistent log storage for mongos Pods.
  • vault.requestInterval and vault.reinitInterval to control Vault password-read and client reinitialization intervals.

Changelog

New Features

• K8SPSMDB-1795 - Added persistent logging for mongos Pods so you can keep query router logs after a Pod restart or rollout. Those logs survive a restart only when you configure sharding.mongos.logs.persistentVolumeClaim.

Improvements

• K8SPSMDB-1778 - Added Custom Resource options so you can set how often the Operator reads system user passwords from HashiCorp Vault and how often it creates a new Vault client to sign in. A longer vault.requestInterval sends fewer Vault requests when passwords change infrequently, vault.reinitInterval can match short-lived tokens (default 30 minutes), and an update to vault.syncUsers.tokenSecret applies on the next reconciliation.

Bug Fixes

• K8SPSMDB-1794 - Fixed Percona ClusterSync target connection failures caused by a missing slash in the generated MongoDB URI. The Operator now writes a valid target-uri so Percona ClusterSync for MongoDB can connect to the target cluster.

• K8SPSMDB-1817 - Fixed a deadlock where Smart Update stayed blocked while Percona ClusterSync for MongoDB (PCSM) held the cluster lease and scheduled backups sat in Waiting. Smart Update no longer waits forever on backups that are parked because PCSM is replicating.

• K8SPSMDB-1834 - Fixed endless Smart Update Pod restarts after you upgrade from Operator 1.22 to 1.23 when spec.tls.issuerConf.kind is ClusterIssuer. The Operator now keeps leaf certificate issuerRef.kind set to ClusterIssuer, so cert-manager no longer reissues those certificates in a loop.

Supported software

The Operator was developed and tested with the following software:

• Percona Server for MongoDB 6.0.29-23, 7.0.43-23, and 8.0.32-14
• Percona Backup for MongoDB 2.15.0
• PMM3 Client: 3.9.1
• cert-manager: 1.21.0
• LogCollector based on fluent-bit: 5.1.2-1

Other options may also work but have not been tested.

Supported platforms

Percona Operators are designed for compatibility with all CNCF-certified Kubernetes distributions. Our release process includes targeted testing and validation on major cloud provider platforms and OpenShift, as detailed below:

• Google Kubernetes Engine (GKE) 1.34 - 1.35
• Amazon Elastic Kubernetes Service (EKS) 1.34 - 1.36
• Azure Kubernetes Service (AKS) 1.34 - 1.36
• OpenShift Container Platform 4.19 - 4.22
• Rancher with Rancher Kubernetes Engine (RKE2) 1.34 - 1.36
• Minikube 1.39.0 with Kubernetes v1.37.0

This list only includes the platforms that the Percona Operators are specifically tested on as part of the release process. Other Kubernetes flavors and versions depend on the backward compatibility offered by Kubernetes itself.