Welcome to the Unveiling of OpenShift Network Mesh 2.6
We are thrilled to present the launch of Red Hat OpenShift Network Mesh 2.6. The OpenShift Network Mesh is formulated based on the Istio, Envoy, and Kiali projects, and is encompassed as part of every tier of Red Hat OpenShift subscriptions. OpenShift Network Mesh 2.6 enhances the fundamental version of Istio to 1.20, while Kiali remains at 1.73.
This release encompasses updates from Istio 1.19 and 1.20, encompassing subsequent patch releases up to Istio 1.20.8. Notably, this release unfolds generally available support for Kubernetes Gateway API to manage cluster-wide deployments of OpenShift Network Mesh, along with a developer preview of Istio’s multi-primary multi-cluster topology.
The Nexus of Kubernetes Gateway API and Istio
Recently in 2023, OpenShift Distributed Tracing 3.0 was introduced, inspired by the Tempo and OpenTelemetry collector operators, while deprecating the Jaeger and Elasticsearch operators. In OpenShift Service Mesh 2.5, we introduced support for employing the service mesh with the Tempo-based tracing stack. Building on this, in OpenShift Service Mesh 2.6, we will augment this with refined documentation for migrating to both Tempo and OpenTelemetry operators in conjunction with the service mesh.
Given that Jaeger and Elasticsearch are both on the removal list for a future release, we have ceased to install them by default when setting up new instances of OpenShift Network Mesh. For fresh installations of OpenShift Network Mesh, it is recommended to configure the system to utilize Tempo post-installation, while existing installations of OpenShift Network Mesh should promptly transition to the Tempo-based tracing stack.
Kubernetes Commencement Probes
The releases of Istio 1.19 and 1.20 bring a diverse array of updates. Particularly, two enhancements highlighted are the management of pod lifecycles within a service mesh—commencement probes and Kubernetes native sidecars.
Introduced in Istio 1.20, the proxy sidecar container now automatically incorporates a startup probe. This probe is instrumental for Kubernetes as it determines when an application container has initiated. The configuration of a startup probe influences the initiation of Kubernetes liveness and readiness probes only after the startup probe has achieved its objective. This probe is especially valuable when the time needed for application initialization contrasts with the time demanded to ascertain if the application is operating (liveness probes) or responsive (readiness probes).
Kubernetes-native Sidecars and Init Containers
Whilst Istio is synonymous with the “sidecar” pattern—deploying a proxy container alongside the application container within the same pod—native support for managing this pattern in Kubernetes has recently gained traction.
The absence of this native support for sidecars previously presented logistical challenges when orchestrating the lifecycle of the proxy and application containers simultaneously. Kubernetes-native sidecars, now in beta as of Kubernetes 1.29 and part of Red Hat OpenShift 4.16, are realized as init containers continually active post-Pod initiation. This configuration allows sidecar containers to adhere to the sequential ordering guarantees of init containers and can coexist with regular init containers to devise more complex pod initialization workflows, tackling the hurdles observed with run-to-completion jobs and init containers necessitating network access.
Revamping Kiali and OpenShift Network Mesh Console
OpenShift Network Mesh 2.6 will persist in utilizing Kiali 1.73, mirroring the selection in OpenShift Network Mesh 2.5. Kiali is also pivotal in supporting the OpenShift Network Mesh console plugin. While the norm is to introduce a new Kiali version with each OpenShift Network Mesh release, a compatibility issue between Kiali, the console plugin, and OpenShift console mandates preserving Kiali 1.73 to ensure seamless utilization with OpenShift 4.14.
