Design 38: Service Mesh (Istio on AKS)

Summary

This design implements Istio (Service Mesh) on AKS to manage microservices traffic.

Topology: Runs inside the AKS Cluster (Design 33) in the Spoke VNet.

1. Key Design Decisions (ADR)

ADR-01: Mesh Selection

Decision: Istio (AKS Add-on).
Rationale: Managed by Microsoft. Easier to upgrade than open-source Istio.

ADR-02: mTLS

Decision: Strict mTLS.
Rationale: Encrypts all traffic between pods (East-West). Zero Trust inside the cluster.

2. High-Level Design (HLD)

+--------------+           +--------------------------+
|  Ingress     |           |        AKS CLUSTER       |
|  Gateway     |---------->|        (Mesh)            |
+------+-------+           |                          |
       |                   |  +-------+    +-------+  |
       |                   |  | Pod A |<-->| Pod B |  |
       |                   |  | Proxy |    | Proxy |  |
       |                   |  +-------+    +-------+  |
       |                   |       ^          ^       |
       |                   |       | (mTLS)   |       |
       |                   +-------|----------|-------+
       |                           |          |
       v                           v          v
+--------------+           +--------------------------+
|  Cert Manager|           |      Istio Control       |
|  (Rotation)  |           |      Plane (Istiod)      |
+--------------+           +--------------------------+

3. Low-Level Design (LLD)

+-----------------------------------------------------------------------+
| SPOKE VNet: vnet-aks-spoke                                            |
|   +---------------------------------------------------------------+   |
|   | Namespace: default                                            |   |
|   |   [Pod: Frontend]                                             |   |
|   |     |-- [Container: App]                                      |   |
|   |     +-- [Container: Envoy Sidecar] <--- Intercepts Traffic    |   |
|   |                                                               |   |
|   |   [Pod: Backend]                                              |   |
|   |     |-- [Container: App]                                      |   |
|   |     +-- [Container: Envoy Sidecar]                            |   |
|   +---------------------------------------------------------------+   |
+-----------------------------------------------------------------------+

4. Component Rationale

Envoy Proxy: Sidecar container that handles networking (retries, encryption) so the App doesn't have to.

5. Strategy: High Availability (HA)

Control Plane: Managed Istio is highly available.

6. Strategy: Disaster Recovery (DR)

Implementation: Multi-Cluster Mesh.
Process: Complex. Typically, just run independent meshes in East and West, and failover at the Front Door level.

7. Strategy: Backup

Config: Backup Istio VirtualServices and Gateways (YAML).

8. Strategy: Security

mTLS: Mutual TLS ensures Pod A knows it's talking to Pod B, and traffic is encrypted.
Authorization: "Frontend can call Backend GET /api, but not POST /admin".

9. Well-Architected Framework Analysis

Reliability: High. Intelligent retries and circuit breaking.
Security: Excellent.
Cost Optimization: Medium. Sidecars consume CPU/RAM.
Operational Excellence: High. Observability (Kiali/Grafana) is built-in.
Performance Efficiency: Medium. Adds slight latency (<5ms).

10. Detailed Traffic Flow

1. Call: Frontend calls http://backend.

2. Intercept: Local Envoy proxy catches request.

3. Route: Envoy checks route table. Finds Backend endpoint.

4. Encrypt: Encrypts with mTLS cert.

5. Send: Sends to Backend Envoy.

6. Decrypt: Backend Envoy decrypts.

7. Deliver: Delivers to Backend App on localhost.

11. Runbook: Deployment Guide (Azure Portal)

Phase 1: Enable Istio Add-on

1. Go to your AKS Cluster (aks-prod).

2. Settings -> Service Mesh (Left Menu).

3. Select: Istio.

4. Enable: Check the box.

5. Ingress Gateway: External (Creates a Load Balancer) or Internal. Select External for this lab.

6. Save.

* *Wait 5-10 minutes for the add-on to install.*

Phase 2: Label Namespace for Injection

1. Click Connect to open Cloud Shell (or use local terminal).

2. Create a namespace (or use default):

* kubectl create ns bookinfo

3. Label it:

* kubectl label namespace bookinfo istio-injection=enabled

* *This tells Istio to automatically inject the Envoy sidecar into any new pod in this namespace.*

Phase 3: Deploy Sample App (Bookinfo)

1. Download the Istio Bookinfo YAMLs (standard demo).

2. Apply them:

* kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo

3. Verify Pods:

* kubectl get pods -n bookinfo

* Crucial: Look at the READY column. It should say 2/2 (1 App Container + 1 Envoy Sidecar).

Phase 4: Verify mTLS

1. Check the authentication policy:

* kubectl get peerauthentication -n bookinfo (Might be empty if default is Permissive).

2. Enforce Strict mTLS:

* Create a file strict-mtls.yaml:

```yaml

apiVersion: security.istio.io/v1beta1

kind: PeerAuthentication

metadata:

name: default

namespace: bookinfo

spec:

mtls:

mode: STRICT

```

* kubectl apply -f strict-mtls.yaml

3. Now, any traffic NOT using mTLS (e.g., from outside the mesh) will be rejected.

Phase 5: Visualize (Optional)

1. If you enabled the monitoring add-ons, you can port-forward Kiali or Grafana to see the traffic map.