Istio has emerged as one of the most frequently utilized service mesh technologies for securing and controlling network traffic within containers and Kubernetes. Its powerful feature set makes it instrumental in solving a number of real issues users regularly encounter when running microservices. Following the standard three-month period since the release of Istio 1.4, Istio 1.5 introduces an impressive number of improvements that increase automation and provide tooling to help further operationalize the platform.
With major architectural changes and several API updates under the hood, Istio 1.5 provides new capabilities that improve the user experience and functionality of the platform. The following highlights will help organizations optimize Istio for configuration management, architecture support, and overall performance.
Istio 1.5 increases the functionality and reliability of istioctl, the primary management tool for the Istio installation. Installation via istioctl has now graduated to beta. It can either directly install Istio into a cluster from an existing profile or produce a manifest that can be applied to multiple clusters for consistency.
In Istio 1.5, the IstioOperator API replaces the IstioControlPlane custom resource used by the Istio operator. While the operator is still in its alpha release, it can now be used to install Istio in the cluster. It has been designed to support the installation and de-installation of Istio within clusters to enable seamless configuration updates.
Istio 1.5 also introduces more options to validate installations and configurations using istioctl. Promoted from experimental status, istioctl analyze adds additional checks and resources to ensure proper configuration.
Istio 1.5 makes considerable structural changes to Istio’s control plane architecture, ultimately scaling back the number of microservices in exchange for a single, monolithic Istiod. In earlier versions, a full Istio deployment would have had six major services deployed in the control plane. In v1.5 these have been consolidated into a single Istiod deployment with a single container running one application process.
Web Assembly Extensions
Istio 1.5 merges its extension model with that of the Envoy proxy, using the portable instruction format WebAssembly. Before this change, Istio extensions leveraged Mixer telemetry and policy services, which resulted in poor scalability. Each service-to-service connection by a sidecar proxy needed to connect Mixer for metrics reporting and authorization checks, which introduced latency for every connection. Meanwhile, Envoy extensions had to be written in C++ and then compiled into the proxy binary, which was ultimately challenging and time-consuming for users.
WebAssembly supports a number of different languages, many of which come out of the growing community around the project. The extensions then get compiled into a portable bytecode format. Once compiled, new filters can be deployed into existing Istio clusters using a single command line. The shift to a common extension model simplifies the ability to add custom functionality to Istio and also reduces latency.
The evolution of Istio Telemetry v2 continues as it introduces metrics for non-HTTP TCP connections, status code reporting for gRPC connections, and alpha support for telemetry configuration. The earlier Mixer-based version also suffered from per-connection latency and increased CPU usage, both of which have been cut in half in v2. This version also adds support for setting canonical services for workloads which back more than one Kubernetes Service, enabling user-friendly data aggregation.
Istio 1.5 provides a more systematic, structured, and logical approach to traffic management, centered on the Envoy proxy. To reduce network traffic and computation, the Envoy proxy now supports receiving partial routing updates from the Pilot. It also introduces more reliable health checks. Istio 1.5 also introduces support for locality-based load balancing HTTP proxy settings for cluster egress traffic.
Istio has contributed significantly to the security of cloud native environments, and the latest features in 1.5 take it a step further, enhancing both its own security and that of its workloads. In Istio 1.5, Auto mTLS graduates to beta to help ease workload migration during Istio adoption. In addition, several new APIs graduated to beta too, including PeerAuthentication and RequestAuthentication, which replace AuthenticationPolicy, and the AuthorizationPolicy API, which now supports Deny semantics to prevent local overrides of global controls.
Istio 1.5 also now uses the Istio Secret Discovery Service (SDS) as the default to deliver mTLS certificates to proxy sidecars. This service uses APIs to send certificates directly to Envoy instead of creating Kubernetes Secrets that would then get mounted in the proxy container. This method is significantly more secure, allowing Istio Citadel to issue per-pod instead of per-workload certificates, and supporting the dynamic update of certificates without having to restart Envoy.
The Istio team has definitely been busy in the time since it introduced Istio 1.4. With major changes to the ways organizations can use Istio for securing and controlling their network traffic, Istio 1.5 significantly enhances user experience with improved traffic efficiency, configuration management, and simplified installation. Istio continues to lead in the open source space in service mesh technologies, and this release’s improvements in automation, security, and performance clearly demonstrate that the Istio team is focused on creating a user-friendly platform that will be increasingly critical to optimizing cloud native investments.