Istio has become one of the most popular service meshes for securing and controlling network traffic in Kubernetes clusters. The releases of the past year have focused in large part on improving the performance of Istio and simplifying its installation, configuration, and management. Istio version 1.5, released on March 5, continues this trend towards operational maturity. This new release combines some major architectural and API changes with increased automation and tooling. This post covers some of the highlights.
Configuration Management
Installation with istioctl
The new release adds a large amount of added functionality and more reliable behavior to istioctl, the command-line tool for managing Istio installations.
Installation via istioctl graduates to beta. It can be used either to install Istio directly into a cluster from a pre-defined profile or to generate a manifest that can be edited, committed to version control, and applied to multiple clusters for consistency.
Istio Operator Improvements
Users can also install Istio in a cluster using the Istio operator. The previous Kubernetes Custom Resource API for the operator, IstioControlPlane, has been replaced by the IstioOperator API. The operator is still in alpha release, and it supports updating or uninstalling Istio in a cluster as well as installation.
Istio also still supports installation via Helm.
Diagnostic Tools
istioctl also continues to add more options and coverage for validating an Istio installation and configuration. istioctl analyze adds more checks and supported resources. It has been promoted out of experimental status.
Architecture
Istiod
Istio 1.5 makes a major change to its control plane architecture: the replacement of its sizeable array of microservices with a single, monolithic Istiod. While it does seem a bit ironic that a service mesh built to control and manage microservice networking would drop its own microservice architecture, the Istio team makes a good case for the change.
Previously, a full Istio deployment had six major services in the control plane: Pilot, which processed service configurations for consumption by the mesh’s proxies; Citadel, which managed the mTLS certificates used by the proxies; the sidecar injector mutating admission controller, which added the proxy automatically to each new pod; Galley, the controller for the Istio custom resources; and the two Mixer components, one for mesh telemetry and the other for policy enforcement. (This list does not include the optional monitoring and visibility components, which are still deployed separately.) These six separate services have been combined into the Istiod deployment: a single container running one application process.
This blog post explains some of the motivations for consolidating the Istio control plane into one service deployment. A microservices architecture often provides the most value when the various services evolve at different paces, scale at different rates, require different degrees of isolation for security purposes (e.g., limit access to a database to the functions that need to connect directly), or get developed by unrelated teams or organizations. The Istio team realized that their control plane meets few of those requirements. Moreover, multiple components made the user experience of installing and managing the control plane more complex.
In another nice touch, Istio 1.5 deploys by default with horizontal pod autoscaling configured for the Istiod deployment.
WebAssembly Extensions for Envoy and Istio
Another major new feature in 1.5 sees Istio merging its extension model with Envoy’s, using WebAssembly (abbreviated Wasm), a portable instruction format.
Previously, Istio extensions focused mainly on the Mixer telemetry and policy services. This method scaled poorly, however, as each service-to-service connection by a sidecar proxy required connections to Mixer for metrics reporting and authorization checks, if policy was enabled. Meanwhile, Envoy required its extensions to be written in C++, the proxy’s programming language, and then compiled into the proxy binary. Building custom proxies to tailor Envoy’s functionality could be challenging or time consuming for many Istio users.
WebAssembly supports development in several different languages. The extensions then get compiled into a portable bytecode format. Wasm currently has full official support for just a few languages, but many more are in development or supported by the community. Once built, Wasm filters can be deployed to existing Istio clusters with a single command line.
Moving to a common, dynamic extension model which focuses on the proxy both simplifies the process of adding custom functionality to Istio and also reduces latency by moving the decision-making process into the proxy instead of farming it out to Mixer. This blog post explains the change’s background and new model in greater detail.
Other New Features and Improvements
Observability
Istio Telemetry v2 continues to evolve. It now includes metrics for non-HTTP TCP connections, adds status code reporting for gRPC connections, and provides alpha support for telemetry configuration. In addition, the latency and CPU usage of the new telemetry system are both roughly half that of the previous, Mixer-based incarnation.
Istio also now supports setting a canonical service for a workload. While a pod in a Kubernetes cluster can be a back end for multiple Service objects, allowing configuration of a canonical service to associate with the pod’s metrics simplifies aggregating the data in a user-friendly way.
Traffic Management
A few additional improvements center on the Envoy proxy. First, it now supports receiving partial routing updates from Pilot, which reduces network traffic and computation. The proxy also has more reliable health checking.
Istio 1.5 also adds support for locality-based load balancing, defined in DestinationRule objects. It also supports HTTP proxy settings for cluster egress traffic.
Security
Istio 1.5 continues to add and enhance both its own security and that of the mesh’s workloads.
Auto mTLS for migrating workloads during Istio adoption graduates to beta. Two new APIs replace AuthenticationPolicy, PeerAuthentication and RequestAuthentication. Those new APIs, in addition to the AuthorizationPolicy API, all graduate to beta. AuthorizationPolicy also now supports Deny semantics for preventing the override of global controls.
The Istio Secret Discovery Service (SDS) is now stable and the default method for delivering mTLS certificates to the proxy sidecars. SDS uses APIs to send certificates directly to Envoy, rather than the original method of creating Kubernetes Secrets, which would get mounted in the proxy container. Direct delivery of the certificates is much more secure and allows for issuing per-pod rather than per-workload certificates, and it supports dynamically updating certificates without restarting Envoy.
The 1.5 release offers an impressive number of improvements in the three months since the last release. While configuring and managing Istio meshes often requires climbing a steep initial learning curve, the project’s developers continue to make major, thoughtful improvements to the operator experience, performance, and functionality.