Istio-based service mesh add-on for Azure Kubernetes Service now in General Availability (GA)!

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

Modern applications are typically architected as distributed collections of microservices, with each collection of microservices performing some discrete business function. This distributed microservices architecture allows multiple teams within large organizations to operate independently of each other and release new versions of their microservices at their own cadence. However, this requires an additional level of supervision to address observability, traffic management, and security use cases for service-to-service communication across these distributed workloads. This can be done by embedding logic directly within the application code of each microservice, or it can be done in a transparent way using service mesh which deploys sidecars to application pods to achieve the same use cases. 


As the deployment of distributed services — such as in a Kubernetes-based system — grows in size and complexity, it can become harder to understand and manage. You may need to implement capabilities such as discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh can address these needs, as well as more complex operational requirements like A/B testing, canary deployments, rate limiting, access control, encryption, and end-to-end authentication. 


Istio has been the de facto service mesh of choice in the open-source cloud-native service mesh landscape for most organizations. To address the service mesh requirements of customers, and to align ourselves with the most popular service mesh choice of the cloud-native customers, we announced the public preview of the Istio add-on for Azure Kubernetes Service in April 2023. Today, we are excited to announce the General Availability of the Istio add-on for Azure Kubernetes Service. 




Also, as part of the general availability announcement, we are also excited to discuss new enhancements we’ve added since the public preview announcement last year –  


Mesh upgrades 

Istio add-on now allows upgrading the minor revision using canary upgrade process. When an upgrade is initiated, the control plane of the new (canary) revision is deployed alongside the old (stable) revision's control plane. You can then manually roll over data plane workloads while using monitoring tools to track the health of workloads during this process. If you are satisfied with the health of your workloads, you can complete the upgrade so that only the new revision remains on the cluster. Else, you can roll back to the previous revision of Istio. 


Revisions asm-1-20 and asm-1-19 have now been made available corresponding to Istio releases 1.20 and 1.19 from upstream. With each new open source Istio release, AKS tests its compatibility with AKS distributions of the K8s minor versions listed in the upstream Istio page. Availability of new mesh releases is communicated through AKS release notes, CLI command, or Azure portal experiences for Istio. 


More details about the upgrade experiences for Istio add-on can be found here. 


Plug-in CA 

In the Istio-based service mesh add-on for Azure Kubernetes Service, by default the Istio certificate authority (CA) generates a self-signed root certificate and key and uses them to sign the workload certificates. To protect the root CA key, you should use a root CA, which runs on a secure machine offline. You can use the root CA to issue intermediate certificates to the Istio CAs that run in each cluster. An Istio CA can sign workload certificates using the administrator-specified certificate and key, and distribute an administrator-specified root certificate to the workloads as the root of trust. 



More details about the plug-in CA set up for Istio add-on and the CA rotation steps can be found here.



Open-source Istio uses MeshConfig to define mesh-wide settings for the Istio service mesh. Istio-based service mesh add-on for AKS builds on top of MeshConfig and classifies different properties as supported, allowed, and blocked. 


MeshConfig opens up the add-on to cover key requirements such as customizing access logging file/format, defining extension providers, or enabling tracing.  


More details about what configurations are supported, allowed, or blocked can be found here.


Azure Portal experiences 

We now have portal experiences for enabling/disabling Istio mesh, canary upgrade, and for visualizing the core metrics (requests/second, error rate, latency) related to services of the mesh. 





Now that the foundational building block of the Istio-based service mesh add-on for AKS is in place, we have a rich roadmap that we will be working on in the coming months:


Egress gateway: Istio addon currently supports easy set-up of external and internal Istio ingresses. We plan to introduce Istio egresses with the ability to configure egress from pods across the entire cluster while still being able to apply Istio features including monitoring and route rules to traffic exiting the mesh.


Further enhancements to upgrade experiences:  With the core minor and patch revision upgrade flows in place, we plan to augment these with opt-in for automatic data plane rollover, auto-upgrade release channels, and integration with planned maintenance windows. 


Mesh CA: The Istio-based service mesh add-on currently supports self-signed and plugin CA options. We plan to augment and enhance the certificate management experience of the add-on with a Microsoft provisioned and managed CA for issuing certificates for mTLS. With Mesh CA, Microsoft will manage the hosting and availability of the CA. 


Multi-cluster mesh:  The Istio add-on announcement covers single cluster AKS deployments of Istio. 

We are now working on expanding this to supporting multi-cluster service mesh. Using Azure Kubernetes Fleet Manager as a convenience option to coordinate set up and lifecycle of mesh across multiple clusters is on the roadmap too. We would love to hear your inputs/requirements for multi-cluster via this questionnaire. 


Observability: Azure Monitor managed service for Prometheus can be used to collect your mesh metrics in a hosted way today. We are currently working on making TLS verification-based scraping of metrics between Prometheus server and mesh pods as seamless as possible. We also plan to provide pre-built Istio dashboards in Grafana. An integration with Application Insights is planned to provide a hosted storage and querying experience for your mesh-generated traces. We are also working towards adding a topology graph experience for the mesh under Azure portal. 


The full roadmap for the service mesh space of Azure Kubernetes ecosystem can be found here. We are excited to see how you will use service mesh. We are also looking forward to hearing more about your scenarios and feature asks! 

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.