Learn Cilium - Latest Stable Features (1.19 & 1.20)

#Introduction

Cilium moves fast. The two releases that just came out — 1.19 in February 2026 and 1.20 in July 2026 — bring a number of features directly relevant to the earlier episodes of this series. Episode 20 summarizes what changed and why it matters.

More than just a feature list, this episode also covers how to upgrade safely between minor versions. Versions 1.19.6 and 1.18.12 are still on the maintenance track, but older branches are already EOL — so understanding the upgrade path is part of day-to-day operations.

Before diving into the feature list, a reminder about version numbering. Cilium uses time-based releases with semver: minor releases appear periodically, and each release brings new features along with fixes. Understanding this rhythm helps you plan upgrades — for example, waiting one release after a big one if you want to avoid early bugs.

#Cilium 1.19 (Feb 2026)

Release 1.19 marks an important milestone: Multi-Pool IPAM became stable. The feature we learned in episode 9 — allocating IPs from several different pools at the same time — is now guaranteed stable for production, complete with the mature CiliumPodIPPool CRD.

It is also worth remembering that 1.19 is the foundation for 1.20: many features stabilized in 1.19 (such as Multi-Pool IPAM) became the stepping stone for what came in 1.20. Following releases in sequence makes version transitions far smoother than jumping far ahead.

Other 1.19 improvements worth noting:

• Network Policy enhancements: refinements to policy evaluation and performance, especially for many-rule scenarios.
• IPv6 progress: IPv6 support keeps improving, narrowing the gap with IPv4 across various scenarios.
• ztunnel transparent encryption: a new, lighter data path for encrypting service mesh traffic, offering a lower-overhead alternative to full Envoy for specific needs.

Besides those three items, 1.19 brings many small improvements that add up operationally: reliability fixes for the agent on busy nodes, memory optimizations for large clusters, and improvements to the Cilium CLI user experience. Small features like these rarely make headlines, but they are often the reason teams decide to upgrade on time.

#Cilium 1.20 (Jul 2026)

Release 1.20 is a big leap for multi-cluster: the MCS API (Multi-Cluster Services) became stable. The feature we discussed in episode 17 — ServiceExport and ServiceImport — is now guaranteed stable, making ClusterMesh a truly production-ready multi-cluster solution.

One important detail of 1.20 for multi-cluster teams: the stability of the MCS API means ServiceExport and ServiceImport no longer require experimental features. This significantly lowers the barrier to adopting ClusterMesh — a major reason many multi-region architectures target Cilium 1.20 as their baseline.

Other 1.20 updates:

• Dataplane refinements: performance optimizations on the eBPF path, including kube-proxy replacement and routing.
• Hubble and security updates: improvements to observability and handling of security vulnerabilities found since the previous release.

For version context, here is the support map at the time this series was written:

1.20.0   - latest stable release (Jul 2026)
1.19.6   - maintenance
1.18.12  - maintenance
< 1.18   - EOL

1.20.0 is the most recommended version for new installations; you should be using this number in the install command from episode 3.

#Version Selection Strategy

#New Versions vs Stable Versions

A healthy general policy: install the latest version for new clusters, and upgrade older versions one minor at a time. Avoid jumping three minors ahead at once, because each jump carries configuration changes that can pile up.

For production, there is real value in using a version that has been "settling" for a few weeks: early bugs in a new release are usually found and fixed by the community. A critical cluster should not be the testing ground for a just-released version.

#Upgrading to the Latest Version

Upgrading between minor versions is safe in principle, as long as you follow the rules: never jump more than one minor at a time, and always verify after the upgrade. For a cluster installed via Helm:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --version 1.20.0
cilium connectivity test

helm upgrade cilium cilium/cilium --version 1.20.0 bumps the chart version, then cilium connectivity test makes sure all traffic paths stay healthy. If the cluster was installed via the Cilium CLI, the equivalent command is:

cilium upgrade --version v1.20.0

cilium upgrade --version v1.20.0 performs the upgrade with the existing configuration. Before upgrading in production, read the official Upgrade Guide for the target version and check the release notes for breaking changes — especially for features that changed status from alpha to stable.

Before the upgrade, take a configuration snapshot: helm get values cilium -n kube-system > before-upgrade.yaml. Keep this file as a rollback reference. If the upgrade causes a problem you cannot solve, you can return to the previous values while comparing the configuration differences before and after.

During the upgrade, note that Cilium agents are upgraded in a rolling fashion by the DaemonSet update mechanism. Network traffic does not stop completely, but a few nodes will run mixed versions for a short period. This is normal, as long as the old and new versions are compatible — which is guaranteed if you only jump one minor.

#Planning the Upgrade Properly

A good upgrade starts with planning, not with a command. Before touching a production cluster, do the following:

helm repo update
helm search repo cilium/cilium | head -5
cilium version
cilium connectivity test

helm repo update refreshes the Helm repository index. helm search repo cilium/cilium | head -5 shows the available versions along with their chart numbers. cilium version confirms the current version is recorded, and cilium connectivity test proves the baseline before the upgrade is healthy — important because after the upgrade, comparing against this baseline is what indicates whether there is a regression.

Then perform the upgrade across environments step by step:

helm upgrade cilium cilium/cilium --namespace kube-system --version 1.20.0 --context dev
cilium connectivity test --context dev
helm upgrade cilium cilium/cilium --namespace kube-system --version 1.20.0 --context staging
cilium connectivity test --context staging

helm upgrade cilium cilium/cilium --namespace kube-system --version 1.20.0 is repeated per environment, from dev to staging, with cilium connectivity test between each step. This pattern ensures problems are detected as early as possible in environments that do not affect end users.

An additional practice that is often overlooked: schedule a maintenance window outside peak hours, and inform the application teams before the upgrade. Even though Cilium is designed for smooth upgrades, some applications with very long-lived connections can be briefly disconnected during the agent's rolling restart. Good communication turns an upgrade from an "incident waiting to happen" into a "planned routine activity".

#Closing

Key takeaways:

• Cilium 1.19 stabilized Multi-Pool IPAM and improved Network Policy and IPv6.
• 1.19 introduced ztunnel transparent encryption for lighter mesh encryption.
• Cilium 1.20 stabilized the MCS API, strengthening multi-cluster ClusterMesh.
• 1.20 also brought dataplane refinements plus Hubble and security updates.
• Upgrades between minors are done via helm upgrade or cilium upgrade.
• Always verify with cilium connectivity test and check the official Upgrade Guide.

In the next episode 21, we will cover production-ready architecture — IPAM planning, kube-proxy replacement, encryption, observability with Hubble and Prometheus, upgrade strategy, a CI/CD pipeline with connectivity tests, GitOps policies, node sizing, and an incident runbook. This consolidates all previous lessons into a blueprint for production.