Istio just changed one of the things you don’t notice until it breaks: where your control-plane artifacts come from. In 1.31.0 Istio continues to publish container images to Docker Hub (and other registries where Istio maintains mirrors), but Helm charts are now served from Istio’s blob host (blob.istio.io) and OCI charts are published to GitHub Container Registry under the istio org. If your CI, air-gapped packaging, or cluster bootstrapping assumes charts come from an older Helm repo or a single OCI registry, expect surprises.
That registry move is the most operationally significant item in this release — more so than the support-matrix tweak. Istio 1.31.0 is explicitly supported on Kubernetes 1.32 through 1.36, and the project also announced that support for Istio 1.29 will end in 2026. In plain terms: teams still on 1.29 have a clearly surfaced deadline and will need to plan upgrades this year. The combination of a registry migration plus an upgrade window is exactly the kind of cascade that uncovers hidden, brittle parts of CI/CD and platform provisioning.
Why the artifact move matters
- Charts vs images: container images remain available from Docker Hub and mirrors, but Helm and OCI charts are now split across different hosts. That fragmentation matters for reproducibility, mirror strategies, and for environments that restrict outbound registry access.
- Tooling assumptions: Helm repo entries, Flux HelmRelease configs, and ArgoCD OCI fetches often embed registry names. The new defaults will require updating manifests, and some tooling that expects a legacy index.yaml may not work the same way with a static blob store.
- Air-gapped operators: teams using local chart proxies or internal mirrors need to add blob.istio.io and ghcr.io targets (or mirror the artifacts) before rolling 1.31 into production.
This is the right move long-term. Centralizing chart hosting under Istio’s control with immutable blob URLs is better for release hygiene. But it’s overdue and will bite teams that have accepted implicit defaults from older installs. If you want a quick follow-up on where this has already tripped people, I wrote more about the artifact-hosting change and how tests exposed hidden registry dependencies: Istio 1.31.0: artifact hosting migration and 'scream tests' reveal hidden registry dependencies.
Cilium 1.20: eBPF extensibility and IPv6 ENI IPAM
If Istio’s release nudges platform plumbing, Cilium 1.20 shifts the datapath itself. The headline is a beta "datapath plugins" capability: a formal eBPF plugin surface that lets third-party code hook into Cilium’s datapath without forking the project. That’s a big design change — moving from monolithic eBPF bytecode to an extensible model where vendors and internal teams can attach logic to packet-processing stages.
Other notable additions in 1.20 include Gateway API integration for external authentication hooks, TCPRoute and UDPRoute support from the Gateway API, and ENI IPAM improvements for IPv6 — features that matter for cloud-provider environments and service-mesh-adjacent routing:
- Gateway API external auth integration: puts authentication hooks closer to data-plane ingress without requiring full sidecar logic.
- TCPRoute / UDPRoute: fills gaps for L4+ routing use cases that previously forced hacks or Service-based workarounds.
- ENI IPAM for IPv6: practical for AWS environments that need IPv6 addressing on ENIs.
Read the CNCF roundup for details; the long-term implication is clear: eBPF is not just a performance lever anymore, it’s a composability surface. I covered Cilium 1.20’s feature set in more detail here: Cilium 1.20 Adds Gateway API ExternalAuth, TCPRoute/UDPRoute, and ENI IPv6 IPAM Improvements.
One candid take: Cilium’s datapath plugin model is the right technical direction, but it raises a governance problem platform teams already dodge — who reviews and tests bytecode that runs in kernel context? Expect an explosion of useful plugins and, regrettably, a few that cause kernel regressions or unexpected resource pressure. Treat any third-party eBPF plugin like you treat privileged kernel modules.
If you run meshes or manage platform bootstrapping: schedule the Istio upgrade work and validate chart fetch paths now. If you operate clusters on AWS or are building networking extensions, start sandboxing Cilium datapath plugins in non-production clusters — this is where the next wave of network features and failures will originate.
These two releases point in the same direction: infrastructure projects are taking hard ownership of artifact and datapath surfaces. That reduces ambiguity for maintainers, but it raises the bar for operators. The safe bet for platform teams in the next 12 months is deliberate, automated discovery of external dependencies (registry and plugin) — or you'll be the one paged at 3 a.m.