Testing the Istio-based service mesh add-on for Azure Kubernetes Service
On April 18th 2023, at Kubecon 2023, Microsoft launched the Istio Service Mesh AKS add-on.
In this article I will share how I tested this preview product.
Installation
To install Istio Service Mesh AKS add-on, first you need to register the AzureServiceMeshPreview feature, as shown in “Deploy Istio-based service mesh add-on for Azure Kubernetes Service”, and use the --enable-asm flag in the az aks createcommand line used to create the AKS cluster.
# Update the aks-preview extension
az extension update --name aks-preview
# Register the preview feature AzureServiceMesh
az feature register --namespace "Microsoft.ContainerService" --name "AzureServiceMeshPreview"
# Wait for RegistrationState to be "Registered"
az feature show --namespace "Microsoft.ContainerService" --name "AzureServiceMeshPreview"
# Register the provider again
az provider register -n Microsoft.ContainerService
#Create a resource group
az group create --name azureservicemesh --location eastus
#Create a cluster
az aks create \
--location eastus \
--name azureservicemesh \
--enable-addons monitoring \
-g azureservicemesh \
--network-plugin azure \
--kubernetes-version 1.25.6 \
--node-vm-size Standard_DS3_v2 \
--node-count 2 \
--auto-upgrade-channel rapid \
--node-os-upgrade-channel NodeImage \
--enable-asm
# Get credentials
az aks get-credentials --resource-group azureservicemesh --name azureservicemeshIstio service mesh is installed in the aks-istio-system namespace, while the Istio ingress gateway will be created in an additional namespace aks-istio-ingress that at this step is still empty. Because Istio is not deployed into the default istio-system namespace all your istioctl commands should use the -i aks-istio-system flag.
As described in the documentation I enable the Istio injection using a revision label.
kubectl label namespace default istio.io/rev=asm-1-17This choice of using the revision label for injection makes me think that it will be possible to use this for Istio upgrades, however there is still no documentation about Istio upgrades.
I create also an external Istio ingress gateway with the following command:
az aks mesh enable-ingress-gateway --resource-group azureservicemesh --name azureservicemesh --ingress-gateway-type externalDeploy a workload
Then, I deploy an example workload, nothing special here, I just updated the Gateway resource to match the selector created by AKS aks-istio-ingressgateway-external :
kubectl apply -f - <<EOF
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: istio-ingressgateway
namespace: aks-istio-ingress
spec:
selector:
istio: aks-istio-ingressgateway-external
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- '*'
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: echoserver
namespace: default
spec:
replicas: 1
selector:
matchLabels:
run: echoserver
template:
metadata:
labels:
run: echoserver
spec:
containers:
- name: echoserver
image: gcr.io/google_containers/echoserver:1.10
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: echoserver
namespace: default
spec:
ports:
- port: 8080
protocol: TCP
targetPort: 8080
selector:
run: echoserver
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: echoserver
namespace: default
spec:
hosts:
- "*"
gateways:
- aks-istio-ingress/istio-ingressgateway
http:
- match:
- uri:
prefix: "/"
route:
- destination:
host: "echoserver.default.svc.cluster.local"
port:
number: 8080
EOFIstio version
Let’s check the Istio version with the following command:
$ istioctl -i aks-istio-system version
client version: 1.17.2
control plane version: 1.17-dev
data plane version: 1.17.1-distroless (3 proxies)The control plane version has this 1.17-dev tag that does not provide the patch version. However, it is easy to get more information inspecting the Pods and looking at the container images used:
- mcr.microsoft.com/oss/istio/proxyv2:1.17.1-distroless
- mcr.microsoft.com/oss/istio/pilot:1.17.1-distroless
Istio CA
The certificates used by the Istio ingress gateways and by the sidecars are signed by a self-signed CA. You find a kubernetes secret istio-ca-secret in the aks-istio-system namespace that contains the CA certificate and the private key. This is like the default Istio open-source installation.
You can test that this CA is used to sign the certificates by inspecting the envoy certificates in the ingress gateway pods, or workload pods, for example:
istioctl pc -i aks-istio-system secret \
-n aks-istio-ingress \
aks-istio-ingressgateway-external-5fdf594f9b-bqcbk -o json \
| jq -r '.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes' \
| base64 --decode \
| openssl x509 -noout -text -in /dev/stdinHelm charts
Looking at the existing secrets in the aks-istio-system and aks-istio-ingress namespaces I understand that Istio was installed using Helm. I like the usage of Helm to install Istio, because I can track exactly what was installed by the Azure Service Mesh add-on. To get the manifests you can run:
# See manifest for istiod
helm -n aks-istio-system get manifest azure-service-mesh-istio-discovery
# See manifest for istio ingress
helm -n aks-istio-ingress get manifest asm-igx-aks-istio-ingressgateway-externaConclusion
Istio is a production grade Service Mesh with a very wide adoption. The Istio add-on for Azure Kubernetes Service makes Istio a first-class citizen on Azure. Istio was already working great on AKS, but this official Microsoft adoption of Istio as an AKS add-on will further improve the situation with regular Istio testing on AKS and options for customer support.
Related work
Paolo Salvatori published an article where he explains how to use the Bicep aksCluster resource to enable the Istio AKS add-on:
Here a list of my related work about Istio on AKS before this add-on was published:
