# Kubernetes Ecosystem Roundup: OpenShift 4.22 Reimagines Observability, Service Mesh 3.4 Brings Istio 1.30, and etcd Hits 3.7

- Link: https://thestackobserver.com/kubernetes-ecosystem-roundup-openshift-4-22-reimagines-observability-service-mesh-3-4-brings-istio-1-30-and-etcd-hits-3-7/
- Published: 2026-07-15T11:43:42-04:00
- Author: Stackxx

\

The Kubernetes ecosystem has been anything but quiet this July. From a ground-up
observability overhaul in Red Hat OpenShift 4.22 to the maturation of Istio’s ambient
mode in Service Mesh 3.4, from a major etcd release to Google pushing agentic AI
infrastructure directly onto GKE — there is a lot to unpack. Here is what matters
and why it matters now.

## OpenShift 4.22: Observability Becomes a First-Class Citizen

Red Hat’s latest OpenShift release is arguably the most observability-focused platform
update in recent memory. The headline change is the **Cluster Observability Operator(
COO) 1.5**, which now treats metrics, logs, traces, and network telemetry as a single
unified workflow rather than disconnected add-ons.

Perhaps the most significant addition is the **general availability of Perses**,
the Kubernetes-native dashboarding platform that Red Hat has been building upstream.
Unlike traditional dashboarding tools that bolt onto clusters, Perses is designed
from the ground up for cloud-native environments. Dashboards are declarative YAML—
versioned in Git, deployed through CI/CD, and aligned with OpenShift RBAC. For teams
running multi-cluster fleets through Red Hat Advanced Cluster Management, Perses
provides normalized observability views without the usual dashboard duplication.
It is a meaningful step toward treating dashboards as code.

Behind the scenes, the monitoring stack itself has been refreshed. **Prometheus 
3.9.1**, **Thanos 0.41.0**, **Alertmanager 0.31.1**, and **kube-state-metrics 2.18.0**
are all included. The Prometheus operator jumped from 0.87.1 to 0.90.1. OpenShift
4.22 also migrates from the deprecated Endpoints API to EndpointSlices, keeping 
the platform aligned with Kubernetes 1.33 and eliminating deprecation noise that
had been cluttering platform logs.

A subtle but important quality-of-life improvement: the monitoring ClusterOperator
now reports degraded status more accurately. In previous releases, routine upgrades
and transient etcd leader changes could trigger false alarms. That noise reduction
matters when platform teams are making go/no-go decisions during change windows.

### Logging and Tracing: Azure, OpenTelemetry, and Day-One Simplicity

OpenShift 4.22 also tackles a looming deadline. Microsoft is retiring its legacy
Data Collector API on September 14, 2026, and Red Hat has proactively updated the
Cluster Log Forwarder to use **OpenTelemetry Protocol (OTLP)** natively when forwarding
to Azure Monitor Logs. Rather than scrambling for a migration path in September,
OpenShift users can transition now without interruption. The integration also adopts**
Workload Identity Federation (WIF)**, replacing static shared keys with short-lived
cryptographic tokens — a meaningful security upgrade.

Perhaps the most forward-thinking logging change is that the entire logging stack—
both the Cluster Logging operator and the Loki operator — can now be deployed through
the COO installer as part of initial cluster provisioning. Application and infrastructure
logs are available for troubleshooting the moment the cluster goes live. Observability
is no longer an afterthought.

Distributed Tracing 3.10 also ships with updated OpenTelemetry collectors and the
Tempo operator for trace storage and querying, continuing the theme of unified signal
management.

## OpenShift Service Mesh 3.4: Ambient Mode Matures

While observability got the spotlight in OpenShift 4.22, the Service Mesh 3.4 release
is where the architecture evolution is most visible. This release jumps two Istio
minor versions — from 1.28 to **Istio 1.30** — and brings the sidecar-less ambient
mode significantly closer to production parity with traditional sidecar deployments.

The most important ambient mode update is **official coexistence and migration guidance**.
Teams can now run sidecar and ambient workloads within the same mesh, migrating 
gradually without a big-bang cutover. This is precisely the kind of pragmatic path
that enterprise adoption requires. Red Hat’s documentation covers the limitations
transparently, and the migration is designed to be reversible.

**Multicluster ambient mode** remains in technology preview, but this release includes
substantial enhancements. A bug fix for ingress gateways routing to remote backends
is now available behind the AMBIENT_ENABLE_MULTI_NETWORK_INGRESS feature flag. Telemetry
gaps around peer metadata exchange across network boundaries have also been closed.
For organizations already running multi-primary, multi-network meshes in sidecar
mode, these ambient mode improvements signal where the architecture is headed.

Security hardening also continues. **Certificate Revocation List (CRL) support**
has been added to ztunnel, enabling ambient mode to reject revoked certificates 
when using external certificate authorities. **Native nftables support** has been
introduced for both sidecar and ambient modes, preparing Istio for RHEL 10 where
iptables will no longer be the default. Optional network policies for core Istio
components (istiod, istio-cni, ztunnel) are now available and will become the default
in a future release.

Gateway API support advances to **version 1.5**, adding full TLSRoute termination
and mixed mode, TLS passthrough for east-west gateways, and custom cipher suite 
configuration via annotations. These are not cosmetic additions — they are foundational
for encrypted cross-cluster traffic in ambient mode.

## AWS EKS: Private GitOps Gets Simpler

AWS has been steadily building out its managed Argo CD offering for EKS, and the
latest capability addresses a real friction point: **private Git repositories**.
Previously, Amazon EKS capability for Argo CD could reach public repos natively,
but private GitHub Enterprise Server or self-managed GitLab instances required workarounds.

The new integration uses **AWS CodeConnections** as a VPC-hosted git-proxy. Organizations
create a CodeConnections host inside their VPC with connectivity to their private
Git server, establish the connection with IAM-based authentication, and then reference
that connection from Argo CD. No long-lived credentials stored in Argo CD. No VPN
complexity. Just IAM roles, short-lived tokens, and private network routing. For
regulated environments where Git servers never touch the public internet, this removes
a significant adoption barrier.

## Google GKE: The Agentic AI Infrastructure Play

Google’s Kubernetes announcements this month have a clear through-line: **AI infrastructure**.
GKE Inference Gateway now delivers up to **92% faster AI responses** through prefix
caching, according to Google’s own benchmarks. The new **GKE standby buffer** lets
clusters pre-warm nodes without the usual cost explosion, improving autoscaling 
responsiveness for latency-sensitive AI workloads.

Perhaps more strategically, **Agent Sandbox on GKE is now generally available**.
This is Google’s bet that agentic AI workloads — autonomous systems that reason,
plan, and act — will run on Kubernetes just like traditional microservices. Alongside
Agent Sandbox, Google previewed **Agent Substrate**, a lower-level infrastructure
primitive for building agent platforms. GKE is positioning itself not just as a 
container orchestrator, but as the runtime for the next generation of AI-native 
applications.

Storage optimizations have also arrived for AI/ML workloads. **GKE Cloud Storage
FUSE Profiles** remove the guesswork from configuring storage for training and inference
pipelines, providing pre-tuned I/O patterns for common workload types.

## Runtime and Tooling Updates

### containerd 2.3.3

The containerd project shipped **v2.3.3** in early July, a patch release focused
on stability. Key fixes include a nil pointer dereference in NRI GetIPs during pod
sandbox teardown, improved sandbox cleanup on RunPodSandbox hook failures to prevent
mount leaks, and better OCI error body surfacing in registry 403 responses. For 
Windows deployments, the release also ensures the SystemTemp environment variable
is respected for SYSTEM services.

### etcd 3.7.0

etcd **v3.7.0** is a milestone release for Kubernetes’ consensus backbone. This 
is a major version bump with breaking changes, and the etcd project published a 
dedicated upgrade guide alongside the release. For platform engineers running self-
managed Kubernetes control planes, this is a release to plan for carefully — but
the upstream changelog promises significant improvements in performance and operational
ergonomics.

### Helm v4.2.3

Helm shipped **v4.2.3**, a routine patch release with dependency bumps including
golang.org/x/crypto from 0.53.0 to 0.54.0. The next minor releases (4.3.0 and 3.22.0)
are scheduled for September 9, 2026.

### HAProxy: Post-Quantum Cryptography

HAProxy Enterprise 3.2 and Community 3.3 now support **hybrid post-quantum cryptography**
natively, powered by AWS-LC integration. This combines classical ECDHE with ML-KEM(
formerly CRYSTALS-Kyber) for TLS 1.3 key exchange. The threat model here is “harvest
now, decrypt later” — the kind of long-term cryptographic risk that nation-state
actors pose to sensitive traffic. HAProxy’s implementation requires TLS 1.3 and 
maintains backward compatibility, falling back to classical ECDHE for clients that
do not support post-quantum curves.

## What This Means for Platform Teams

Three themes emerge from this month’s Kubernetes ecosystem updates.

First, **observability is becoming platform-native**, not an after-market bolt-on.
OpenShift 4.22’s unified observability stack, Perses GA, and OTLP-native Azure forwarding
all point to a future where metrics, logs, and traces are deployed, managed, and
secured through the same lifecycle as the platform itself.

Second, **service mesh architecture is quietly being rewritten**. Istio’s ambient
mode is not experimental anymore — it is a viable migration path with official coexistence
guidance, multicluster improvements, and security parity with sidecar mode. Within
12-18 months, ambient mode will likely be the default recommendation for new deployments.

Third, **Kubernetes is becoming the infrastructure layer for AI**. Google’s Agent
Sandbox on GKE, inference-optimized networking, and storage profiles all point to
a future where Kubernetes orchestrates not just containers, but autonomous agents
and large language model serving pipelines. The boundary between “cloud-native” 
and “AI-native” infrastructure is dissolving.

## Sources

 * [Red Hat: New observability features in OpenShift 4.22](https://www.redhat.com/en/blog/new-observability-features-red-hat-openshift-422)
 * [Red Hat: Introducing OpenShift Service Mesh 3.4](https://www.redhat.com/en/blog/introducing-red-hat-openshift-service-mesh-34)
 * [AWS: Accessing private Git repositories from Amazon EKS capability for Argo CD](https://aws.amazon.com/blogs/containers/accessing-private-git-repositories-from-amazon-eks-capability-for-argo-cd/)
 * [Google Cloud Blog: Containers & Kubernetes](https://cloud.google.com/blog/products/containers-kubernetes)
 * [containerd v2.3.3 Release Notes](https://github.com/containerd/containerd/releases/tag/v2.3.3)
 * [etcd v3.7.0 Release Notes](https://github.com/etcd-io/etcd/releases/tag/v3.7.0)
 * [Helm v4.2.3 Release Notes](https://github.com/helm/helm/releases/tag/v4.2.3)
 * [HAProxy: How to enable post-quantum cryptography](https://www.haproxy.com/blog/how-to-enable-post-quantum-cryptography-and-tls-termination-with-haproxy)
 * [Kubernetes Blog: Building a Custom Metrics Exporter for Kubernetes](https://kubernetes.io/blog/2026/07/14/custom-metrics-exporter-kubernetes/)