etcd v3.6.0: A Milestone for Security and Performance

Today, we are excited to announce the release of etcd v3.6.0, the first minor release since etcd v3.5.0. This update brings numerous new features, enhances support for downgrades and migrations to the v3store, and addresses many critical and important issues. Additionally, significant optimizations in memory usage have been made, improving both efficiency and performance.

Another key point: etcd is now part of Kubernetes as a SIG (sig-etcd). This will help us improve the sustainability of the project. We have introduced systematic robustness testing to ensure correctness and reliability. Through the etcd-Operator Working Group, we also plan to enhance user-friendliness.

Here are the main changes in etcd v3.6.0, along with a discussion on the roadmap for future development. A detailed list of changes can be found in the CHANGELOG-3.6.

A heartfelt thanks to all contributors who made this release possible!

Security

Security is paramount at etcd. To enhance the software’s security in v3.6.0, we have optimized our workflow by integrating govulncheck for source code review and trivy for container image scanning. These improvements have also been backported to supported stable releases.

etcd continues to follow the Security Release Process to ensure vulnerabilities are properly managed and resolved.

Features

Migration to v3store

The v2store has been considered deprecated since etcd v3.4, but could still be enabled via --enable-v2. It remained the data source for membership information. In etcd v3.6.0, however, the v2store can no longer be activated as the --enable-v2 flag has been removed, making the v3store the sole source for membership data.

Although the v2store still exists in v3.6.0, etcd will not start if it contains data other than membership information. To assist with migration, etcd v3.5.18+ offers the etcdutl check v2store command to verify that the v2store contains only membership data.

Compared to the v2store, the v3store offers better performance and transaction support. It is also the actively maintained storage engine for the future.

The removal of the v2store is still ongoing and is tracked in issues/12913.

Downgrade

etcd v3.6.0 is the first version to fully support downgrades. The effort for this downgrade task spans versions 3.5 and 3.6, with all related work tracked in issues/11716.

At a high level, the process involves migrating the data schema to the target version (e.g., v3.5), followed by a step-by-step downgrade. Ensure the cluster is healthy and create a snapshot backup. Verify if the downgrade is valid:

$ etcdctl downgrade validate 3.5
Downgrade validate success, cluster version 3.6

If the downgrade is valid, enable the downgrade mode:

$ etcdctl downgrade enable 3.5
Downgrade enable success, cluster version 3.6

etcd then migrates the data schema in the background. Upon completion, proceed with the step-by-step downgrade. For details, see the Downgrade-3.6.

Feature Gates

In etcd v3.6.0, we have introduced Kubernetes-like feature gates to manage new features. Previously, unstable features were indicated by the --experimental prefix in the feature flag names. This prefix was removed once the feature was stable, leading to a breaking change. Now, features start in Alpha, evolve to Beta, and then GA or become deprecated. This ensures a much smoother upgrade and downgrade experience for users.

For more details, see feature-gates.

At ayedo, we are happy to support you in implementing etcd in your Kubernetes projects and help you make the most of the new capabilities!

Source: Kubernetes Blog