The Istio's 1.5 release has introduced a monolithic "Istiod" control plane binary to simplify installation of the service mesh, with the goal of improving the operational experience. This version has also introduced a new extension model for proxy servers using Wasm, and included improved usability, security, telemetry and traffic control.
The move towards a single Istiod binary means that there are fewer moving parts, with the intention of making it easier to debug and understand. The use of Istiod doesn't change mesh users' experience; all APIs and runtime characteristics are consistent with the previous components. Istiod is effectively the reversal of the microservice architecture model.
Istio 1.4's structure had a control plane that consisted of five services and plugins for extensibility: sidecar proxy loading, provided by the sidecar-injector service; extensibility and extensibility plugins, provided by the Mixer services and adapter plugins; sidecar proxy config generation and serving, provided by the Pilot service; security, provided by the Citadel service; and validation, provided by the galley service. Istio 1.5 has reorganised the control plane into one service and reimplemented extensibility; Istiod provides proxy sidecar loading, mesh operation, security and validation, and the data plane now implements mixer adapters within the mesh as Envoy WebAssembly (Wasm) plugins.
Istio has been designed to be an extensible service mesh, with Mixer plugins allowing custom policy and telemetry support, and Envoy extensions allowing data plane customisation. In Istio 1.5 a new model unifies Istio's extensibility model with Envoy's, using Wasm. Wasm gives developers the ability to distribute and execute code in the Envoy proxy in order to integrate with telemetry systems, policy systems, control routing and even transform the body of a message. Istio will no longer require the running of a separate mixer component, which will likely simplify deployments.
Steven Dake explains in his blog post that Istio initially used a microservice architecture to support the way teams within Istio were working. At the time, teams were delivering updates and releases for services on different schedules. Teams were using API contracts between themselves and needed independent horizontal scaling. As Istio's team and technology matured, the advantages of a microservice architecture waned. As development of Istio 1.4 was wrapped up, the Istio environments working group received a proposal to compose a monolith of the existing components. The environments working group led the technical debates, and the Istiod concept was born. During the Istio technical oversight committee meeting that followed, the environments working group proposed using the Istiod binary.
Another new enhancement is command line installation of Istio using istioctl, which is now beta for installations. Managing installation via a Kubernetes Operator is still alpha, but Istio continues to improve it with a new IstioOperator API. istioctl has a number of improvements: new items it can analyse, improved validation rules and ability to integrate with CI systems. istioctl analyse has graduated from the experimental stage.
Enhancements have also been made to Istio security: mTLS configuration is simplified and automated with the beta launch of auto mTLS, and access control has been simplified by removing indirection and consolidating to a single CRD, building on the beta launch of the authorisation policy in Istio 1.4. In 1.5, all security policies including Auto mTLS, AuthenticationPolicy (PeerAuthentication and RequestAuthentication) and authorisation are now in beta and SDS is now stable. Authorisation now supports deny semantics to enforce mandatory controls that cannot be overridden.
The Node agent and the Istio agent have been combined into a single binary, which means configuration of a PodSecurityPolicy is no longer required. Certificates no longer need to be mounted on every pod, and Envoy no longer needs to be restarted when certificates change. Certificates are delivered directly from Istiod to every pod and each pod received a unique certificate.
Telemetry v2 now reports metrics for raw TCP connections (in addition to HTTP), and the support for gRPC workloads has been enhanced by adding response status codes in telemetry and logs. Telemetry v2 is now used by default. The new telemetry system is reported to cut latency in half: 90th percentile latency has been reduced from 7ms to 3.3 ms. The elimination of Mixer has reportedly reduced total CPU consumption by 50% to 0.55 vCPUs per 1,000 requests per second.
Both Solo.io and Google have responded to the announcement from Istio, with Google introducing WebAssembly (Wasm) extensions in Envoy, built with their collaborators Lyft and IBM. Solo.io has extended and improved WebAssembly Hub to include Envoy and Istio support.