Skip to content

v0.10.0

Latest
Latest
Compare
Choose a tag to compare
@nastena1606 nastena1606 released this 06 Jun 15:10
· 30 commits to main since this release
v0.10.0
3aaba39
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Release highlights

PMM3 support

The Operator is natively integrated with PMM 3, enabling you to monitor the health and performance of your Percona Server MySQL deployment and at the same time enjoy enhanced performance, new features, and improved security that PMM 3 provides.

Note that the support for PMM2 is dropped. This means you must do the following to monitor your deployment further:

  • transition to PMM 3 if you had PMM 2 to. The PMM documentation explains how to upgrade.
  • run the Operator version 0.10.0. Check the Upgrade the Operator tutorial for the update steps.
  • ensure that PMM 3 Server version must be equal to or newer than the PMM Client.

Support for deployments on OpenShift

OpenShift is a fully integrated Kubernetes-based platform enhanced with automation, security, and developer-friendly tools. You can now deploy Percona Operator for MySQL based on Percona Server for MySQL on OpenShift and benefit from its portability across hybrid clouds. The Operator also fully supports the Red Hat OpenShift lifecycle which ensures its security and reliability.

Follow our installation guide to install the Operator on OpenShift.

Added labels to identify the version of the Operator

CRD is compatible with the last 3 Operator versions. To know which Operator version is attached to it, we've added lables to all Custom Resource Definitions. The labels help you identify the current Operator version and decide if you need to update the CRD.

To view the labels, run: kubectl get crd perconaservermysqls.ps.percona.com --show-labels

Improved configuration validation during cluster deployment

The Operator now enforces these mandatory parameters to have values when it deploys the database cluster:

  • .spec.mysql.size
  • .spec.proxy.haproxy.size
  • .spec.proxy.router.size
  • .spec.orchestrator.size
  • .spec.backup.pitr.binlogServer.size

If any of the following configuration options are empty, the deployment fails.

This improved validation ensures that every cluster is deployed with the necessary settings for stability and functionality.

Changelog

New features

Improvements

  • K8SPS-135 - Use MD5 hashing for stored configuration

  • K8SPS-320 - Added labels to TLS and user secret objects created by the Operator

  • K8SPS-357, K8SPS-423 - Added the state-monitor utility to read MySQL state during startup. It is a valuable tool to improve cluster provisioning

  • K8SPS-382 - Removed the loadBalancerIP Service type as deprecated

  • K8SPS-392 - Added the ability to increase timeout for the CLONE operation while bootstrapping a cluster (Thank you Alexander Kuleshov for reporting this issue)

  • K8SPS-426 - Added Labels for Custom Resource Definitions (CRD) to identify the Operator version attached to them

Bugs Fixed

  • K8SPS-212 - Improved the Custom Resource validation during a cluster deployment when the .mysql.clusterType is set to async. The validation rules verify that HAProxy and Orchestrator are enabled, while MySQL Router is disabled for async deployments. The corresponding log message is also printed. This helps ensure your cluster is configured according to the requirements for this replication type.

  • K8SPS-221 - Fixed a bug with bootstrapping the cluster after crash when the clusterType is set to group-replication. The fix uses the state-monitor utility that checks MySQL state and proceeds with bootstrappins based on the database state.

  • K8SPS-299 - Fixed the issue with the Operator failing to initialize the cluster when the size for MySQL is absent in Custom Resource manifest by making the parameters that affect cluster operation mandatory for deployment. If any option has no value, the Operator fails to deploy the cluster

  • K8SPS-365 - Fixed the issue with clusterType set to group-replication failing after the upgrade of the MySQL image. The issue was fixed by removing the excessive restart of the mysql container after adding a pod to the cluster.

  • K8SPS-375 - Improved the cluster startup process by handling reconciling errors

  • K8SPS-379 - Automated the ClusterRole generation when installing the Operator in a cluster-wide mode

  • K8SPS-387 - Added the wait_for_delete function to ensure that the cluster or its components are fully cleaned up before performing operations like restoration, scaling, or re-deployment.

Deprecation and removal

The loadBalancerIP type for the Service objects is deprecated in Kubernetes v1.24+. It is removed from the HAProxy and Router subsections of the deploy/cr.yaml Custom Resource manifest. Please refer to Kubernetes documentation for recommendations how to proceed if you have defined this type before.

Supported software

The Operator was developed and tested with the following software:

  • Percona Server for MySQL 8.0.42-33
  • Orchestrator 3.2.6-17
  • MySQL Router 8.0.42
  • XtraBackup 8.0.35-33
  • Percona Toolkit 3.7.0
  • HAProxy 2.8.14
  • PMM Client 3.2.0

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.

Assets 2
Loading