Running Istio on Azure

Istio service mesh, the recently graduated project originally from Google and now under the wings of the CNCF, is a battle-proven, production-grade tool. It’s very popular among end-users for its ability to address the challenges of security, resiliency, and observability that modern cloud native applications impose on container infrastructures.

There are several ways to run Istio in Azure Kubernetes Service (AKS), and Microsoft is embracing the CNCF ecosystem and its newly graduated project, Istio, to provide an out-of-the-box experience for containerized workloads; for more advanced scenarios though, the flexibility of the Helm installation, and of supported, commercial offerings like Gloo Platform, is what enterprises and power users should be looking for.

Installing Istio the Hard Way on Azure

The most straightforward way to install Istio is using the istioctl command line tool, following the official documentation, on a fresh Azure Kubernetes Cluster.

While this method provides an easy and seamless way to deploy Istio and its components, it’s also very imperative and it can lead to a less-than-ideal situation where changes to your cluster cannot be traced back to a single source of truth (like in a GitOps approach, as described later). Istioctl can be used with all the parameters accepted by the Helm chart, similarly to:

$> istioctl install --set profile=ambient -y \
--set "components.ingressGateways[0].enabled=true" \
--set "components.ingressGateways[0].name=istio-ingressgateway"

Istioctl supports the use of “profiles”, which are a collection of predefined values for deploying Istio in specific ways; you can get a list of profiles using:

$> istioctl profile list

A Better Way: Helm

Helm charts for Istio have been around for a long time and they provide the best declarative way to deploy and maintain one or multiple Istio installations on your AKS clusters. Moreover, Helm has a built-in lifecycle management for releases, making it easy to pinpoint the version of Istio installed, upgrading and modifying the various options and tracking and rolling back deployments.

Lastly, using Helm charts makes for a straightforward integration with GitOps tools like ArgoCD or FluxCD, which support deploying Helm charts through the native Application/ApplicationSets (for ArgoCD) or HelmRelease (for Flux) Custom Resource Definitions.

You can install Istio using Helm according to the official documentation like this:

$> helm install istio-base istio/base -n istio-system \
--set defaultRevision=default
$> helm install istiod istio/istiod --namespace istio-system
$> helm install istio-ingressgateway istio/gateway

The charts follow a modular design for better flexibility where every component is optional; it is split in several components (base, istiod, gateways and so on). More information is available on the manifest/charts directory on the Istio github repository.

A Superior Way: GitOps

GitOps is the mainstay, modern way to deploy cloud native applications (and CNCF has a working group dedicated to fostering and promoting the OpenGitOps principles).

While not the focus of this blog, Azure introduced GitOps support for AKS through Azure Arc-enabled Kubernetes cluster available for AKS clusters too. Azure Arc is a one-stop solution for managing clusters and applications at scale in Azure and it provides a great developer experience to get started with GitOps; at Solo.io we also embrace the ideas and practices of GitOps. GitOps provides you with more repeatable and trustable deployments, simplified processes, and increased visibility and rollbacks into your applications and infrastructure. Read the blog post “From Zero to Gloo Edge in 15 Minutes” to learn more.

Istio-based Service Mesh Add-on for AKS

At the last KubeCon Europe in Amsterdam, Azure introduced the Istio AKS add-on (add-ons in AKS are pre-configured tooling for AKS) as managed service for AKS, where Istio control plane is managed by Azure (but runs in the cluster) and the Istio version is known and tested to work well alongside the AKS version.

$> az aks create \
--resource-group ${RESOURCE_GROUP} \
--name ${CLUSTER} \
--enable-asm

#for existing clusters:
$> az aks mesh enable --resource-group ${RESOURCE_GROUP} --name ${CLUSTER}

Moreover, it provides a facilitated deployment of ingress-gateway; for example, here’s how you can use az CLI to quickly deploy the Istio ingress-gateway:

$> az aks mesh enable-ingress-gateway --resource-group ${RESOURCE_GROUP} --name ${CLUSTER}

You can use the flag --ingress-gateway-type to specify if you want an external (with a Public IP) or internal (with an IP from the AKS Vnet) type of ingress. Please note that the Kubernetes community and the Istio community are transitioning to the new Gateway API (here’s the Istio page on GatewayAPI); Istio supports GatewayAPI in beta since November 2020 as this is clearly the direction forward for traffic ingress in Kubernetes and Istio.

At the time of writing, the Istio Service Mesh Add-on runs the 1.17.4 version, just one minor version behind the latest supported release. This add-on represents a big step forward for Istio adoption, signaling strong support from a major cloud provider (following other large clouds) for the project, and acknowledges that a simplified user experience is crucial for widespread adoption. We believe that power users and enterprise customers of Azure and Azure Kubernetes Service will want more control and support in their service mesh journey with Istio.

Istio Supported: The Enterprise Way

At Solo.io, we love and foster open source and play a leadership role in driving the Istio project. We understand the enterprise’s needs for trusted support and peace of mind that comes from knowing the best-in-class professionals and strong organizations behind them have their backs.

Solo.io offers production-grade support for Istio, together with specific enhancements that cater to the needs of the enterprise, such as FIPS-certified builds and lifecycle management of Istio versions, security hot-fixes backported to upstream, and dedicated SLAs on customer issues; we’re leader in the Istio community and show it in our continuous dedication to our customer success.

One Step Forward: Integrated Gloo Platform

Addressing security within a cloud native application brings fresh complexities that can be challenging to manage. Leveraging the capabilities of the Gloo Platform empowers organizations to effectively oversee the security of their containerized applications as they expand within the Azure ecosystem. This encompasses both the API gateway and Istio service mesh features, ensuring the safeguarding of both external and internal communication of applications.

The Gloo Platform seamlessly combines essential products from Solo.io into a unified environment, establishing a zero trust security model within your application network. Central to enabling API gateway and service mesh functionality are the Gloo Gateway and Gloo Mesh components. Additionally, the Gloo Platform licensing includes Gloo Network for heightened security, alongside the Gloo GraphQL and Gloo Portal modules.

Gloo Platform can be used to simplify adoption of service mesh at scale, with its built-in multicluster capabilities and integrated API gateway.

What’s Next?

We will continue this blog series in the coming weeks with more information on how to run Istio and Gloo Platform on Azure (like our previous article on running Istio Ambient Mesh on AKS) and we’re looking forward to combine the best practices from Microsoft with the best service mesh platform today. You can engage with me directly on X or on Solo.io public Slack if you want to discuss these topics further.