A service mesh is a dedicated infrastructure layer that controls service-to-service communication over a network. This method enables separate parts of an application to communicate with each other. Service meshes appear commonly in concert with cloud-based applications, containers and microservices. Istio service mesh is a first choice in the open-source cloud-native service mesh landscape for most organizations. It was also recently accepted into Cloud Native Computing Foundation as an incubating project.
Azure done a very good job last years to introduce a service mesh concept into AKS. There are two primary chooses to setup in Azure Kubernetes environment: Open Service Mesh (OSM) and Istio-based service mesh add-on. Both are based on Envy proxy, while OSM is Azure native solution. OSM is pretty straightforward to install and configurate using Azure Portal.
Istio is an open-source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio enables load balancing, service-to-service authentication, and monitoring – with few or no service code changes.
A few months ago Microsoft announced Istio-based service mesh add-on for Azure Kubernetes Service in his Preview.
This service mesh add-on uses and builds on top of open-source Istio. The add-on flavor provides the following extra benefits:
- Istio versions are tested and verified to be compatible with supported versions of Azure Kubernetes Service.
- Microsoft handles scaling and configuration of Istio control plane, provides managed lifecycle (upgrades) for Istio components
- Microsoft adjusts scaling of AKS components like
corednswhen Istio is enabled. - Verified external and internal ingress set-up.
- Verified to work with Azure Monitor managed service for Prometheus and Azure Managed Grafana.
- Official Azure support provided for the add-on.
But having a number of limitation, especially for a solution already based on native version of Istio service mesh:
- The add-on doesn’t work on AKS clusters that are using Open Service Mesh addon for AKS.
- The add-on doesn’t work on AKS clusters that have Istio installed on them already outside the add-on installation.
Architecture model of Azure Istio-based service mesh add-on for Azure Kubernetes Service:
Istio add-on installs a sidecar container along with application one which acts as a proxy for network communication with another microservices on a node. The metrics that may easy be ingested to Azure Monitor workspace using both Azure Monitor managed service for Prometheus or Application Insights.
To start with Istio add-on first check if AzureServiceMeshPreview feature is enabled on your cluster:
PS> az aks mesh enable --resource-group $RESOURCE_GROUP -n $CLUSTER_NAME
After installation done successfully, you should see Istio on cluster:
PS> az aks show --resource-group $RESOURCE_GROUP -n $CLUSTER_NAME --query 'serviceMeshProfile.mode'
Next, verify that istiod (Istio control plane) pods are running successfully:
Using Istio service mesh automatically
For any new deployment, we are going to annotate the cluster namespace with specific version:
PS> kubectl label namespace default istio.io/rev=asm-1-17
And then:
Manual sidecar injection
For existed solution, you have to setup sidecar container first as a part of deployment. I will do so with help of istioctl:
PS> choco search istioctl
After installation done, use istioctl kube-inject command and specify extra parameters for istioNamespace (-i) and revision (-r).
PS> istioctl kube-inject -f .\kustomize\deployment.yaml -i aks-istio-system -r asm-1-17 > deployment-sidecar.yaml
The last step is to include deployment with kustomize:
Push changes and wait till GitOps apply the kustomization.
After Flux2 reconciliation finished, you should find one more additional istio-proxy container deployed along to application:
Hope, you like the post. Please follow me on Twitter or LinkedIn and subscribe to newsletter below.
Be an ethical, save your privacy!