Skip to content

v0.12.0

Latest
Latest
Compare
Choose a tag to compare
@nastena1606 nastena1606 released this 23 Sep 13:32
· 17 commits to main since this release
v0.12.0
1aae002

Release highlights

Full MySQL 8.4 support is now available

With this release, data-at-rest encryption is now supported for Percona Server for MySQL 8.4.

In the previous release, we have added support for Percona Server for MySQL 8.4 within the Operator. However, data-at-rest encryption was not yet available. That limitation has now been lifted, unlocking the full potential of Percona Server for MySQL’s latest major version. Check our documentation for Percona Server for MySQL 8.4-specific setup instructions.

This improvement empowers you to take full advantage of Percona Server for MySQL 8.4’s features while benefiting from seamless, automated lifecycle management provided by the Operator. Percona Server for MySQL 8.4 is now the default version for deploying a database cluster.

Ensure cluster availability with PodDisruptionBudgets

A PodDisruptionBudget (PDB) in Kubernetes helps keep your applications available during voluntary disruptions, such as deleting a deployment or draining a node for maintenance. A PDB sets a limit on how many Pods can be unavailable at the same time due to these voluntary actions.

With this release, you can now configure PodDisruptionBudgets for MySQL, HAProxy, MySQL Router, and Orchestrator Pods, thus ensuring your cluster remains available, even during disruptions or planned maintenance.

Fine-tune backup and restore operations

The Operator sets sensible defaults for backups and restores to ensure their smooth flow. If you need more control, you can fine-tune xtrabackup, xbstream, and xbcloud settings. You can do this globally via the deploy/cr.yaml Custom resource manifest or individually for a specific backup / restore operation via the respective deploy/backup.yaml or deploy/restore.yaml manifests. In either case, define your configuration in the spec.containerOptions subsection. For example:

spec:
  backup:
    storages:
      <STORAGE-NAME>:
         containerOptions:
           env:
           - name: CUSTOM_VAR
             value: "false"
           args:
             xtrabackup:
             - "--someflag=abc"
             xbcloud:
             - "--someflag=abc"
             xbstream:
             - "--someflag=abc"

Note that individual settings take precedence over the global ones. Read more about fine-tuning backups and restores and how the settings are applied in our documentation.

Monitor PMM Client health and status

Percona Monitoring and Management (PMM) is a great tool to monitor the health of your database cluster. Now you can also learn if PMM itself is healthy using probes - a Kubernetes diagnostics mechanism to check the health and status of containers. Use the spec.pmm.readinessProbes.* and spec.pmm.livenessProbes.* Custom Resource options to fine-tune Readiness and Liveness probes for PMM Client.

Define a source Pod for backups

You can now explicitly define from what MySQL instance Pod the Operator should make a backup. You can specify the Pod in the deploy/cr.yaml to apply it for all backups, both scheduled and on-demand. You can also override it for an on-demand backup in its resource manifest.

spec:
  backup:
      sourcePod: ps-cluster1-mysql-1

These options let you tailor your backup strategy to fit your organization's policies.

For asynchronous replication clusters, the Operator must know the cluster topology to run a backup. For this, either enable the Orchestrator in your deployment. Or specify the sourcePod value, if your cluster has more than one MySQL Pods.

Deprecation, rename and removal

  • The .spec.initImage field has been replaced by the .spec.initContainer subsection, which follows Kubernetes best practices for defining containers that run before the main containers in a Pod. The initContainer feature is helpful for setup tasks such as:

    • Initializing data
    • Waiting for services to become available
    • Setting permissions
    • Pulling secrets or configuration files

  • The default cluster name has been changed to ps-cluster1 to prevent possible conflicts if you have custom resources of both Percona Operator for MySQL based on Percona Server for MySQL and Percona XtraDB Cluster in the same namespace.

  • The API version in CRD has changed from v1alpha to v1. Read more about updates in Known limitations.

Known limitations

Due to the API version change, CRD updates are currently not supported. In order to update to version 0.12.0, you must manually delete the CRDs, apply new ones and recreate the cluster. To keep the data, do the following:

  • check that the percona.com/delete-mysql-pvc finalizer is not enabled in deploy/cr.yaml
  • don't delete PVCs manually
  • Recreate the cluster with the same name. The Operator then automatically reuses the same PVCs.

Changelog

New features

  • K8SPS-400 - Improved flexibility for backups and restores via adding support for custom options for xtrabackup, xbstream, and xbcloud binaries.

  • K8SPS-405 - Users can now configure the LivenessProbe for the PMM Client container, allowing for custom timeouts and improved container health checks.

  • K8SPS-413 - Add ability to set resources and containerSecurityContext for init containers.

  • K8SPS-480 - Added support for data-at-rest encryption for MySQL 8.4.

Improvements

  • K8SPS-172 - The operator now includes logs for all haproxy manipulations, providing better visibility for operations like adding, deleting, or downscaling.

  • K8SPS-269 - All Kubernetes objects created by the Operator now have appropriate labels, including the Orchestrator configmap in async clusters. This improves object filtering and grouping.

  • K8SPS-417 - Added ability to define PodDisruptionBudget, which helps manage voluntary disruptions to your cluster.

  • K8SPS-427 - Simplified the Custom Resource (CR) validation logic by using Kubernetes validations for CR input.

  • K8SPS-464 - The Operator will now automatically set the crVersion to the Operator's current version if it is not defined by the user.

  • K8SPS-466 - Added ability to set global labels and annotations for all Kubernetes objects created by the Operator.

  • K8SPS-478 - Improved bootstrapper behavior to determine if incremental recovery is possible and specify it when adding new instances to the existing cluster.

  • K8SPS-488 - Switched to using API version v1 in custom resource definitions

Bugs fixed

  • K8SPS-371 - Added the ability to set a backup source Pod to ensure backups are made for clusters with asynchronous replication when the Orchestrator is disabled.

  • K8SPS-374 - Fixed the issue with the Operator reporting the reconciliation error when an async cluster was being paused or recovered.

  • K8SPS-378 - Fixed an issue where the cluster would remain in an unready state if the Orchestrator was scaled down to 1 Pod.

  • K8SPS-430 - The Operator now updates TLS certificates when new Subject Alternative Names (SANs) are added to the CR.

  • K8SPS-465 - Readiness and liveness probes have been added for HAProxy Pods to ensure their health.

  • K8SPS-475 - Fixed an issue where the exposePrimary.labels field was incorrectly applied to the service selector. The exposed services now contain global labels together with the exposed labels and the selectors do not contain labels.

  • K8SPS-494 - Fixed the issue with the constant update of the resourceVersion of the PerconaServerMySQL object after a cluster is created. The issue was caused by the Operator receiving stale objects during reconciliation, which resulted in the InnoDBClusterBootstrapped condition being set twice in every loop and constantly updating its last transition time. The Fix updates the status directly after setting the condition and waits for consistency with the API server.

Supported software

The Operator was developed and tested with the following software:

  • Percona Server for MySQL 8.4.6-6
  • Percona Server for MySQL 8.0.43-34
  • XtraBackup 8.4.0-4
  • XtraBackup 8.0.35-34
  • MySQL Router 8.4.6-6
  • MySQL Router 8.0.43-34
  • HAProxy 2.8.15-1
  • Orchestrator 3.2.6-18
  • Percona Toolkit 3.7.0-2
  • PMM Client 3.4.0
  • Cert Manager 1.18.2

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 for Operator version 0.9.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 backward compatibility offered by Kubernetes itself.

Find images for previous versions

Assets 2
Loading