Chapter 10.1: Service Mesh (Istio)

Part 3: Installing Istio (on Minikube)

The best way to install and manage Istio is with its official command-line tool, istioctl.

Step 1: Download `istioctl`

# Download the latest version
$ curl -L https://istio.io/downloadIstio | sh -

# Move the 'istioctl' binary to your path
$ cd istio-1.20.0
$ sudo mv bin/istioctl /usr/local/bin/

Step 2: Install Istio on your Cluster

This command will install the main `istiod` Control Plane into your cluster (e.g., Minikube).

# 'demo' profile installs all the main features
$ istioctl install --set profile=demo -y

✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

Step 3: Enable Automatic Sidecar Injection

This is the final, magic step. You need to tell Istio which namespace to "watch." We will label the default namespace.

# Tell Istio to automatically inject sidecars
# into any Pods deployed in the 'default' namespace
$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

That's it! Now, any *new* app you deploy to the `default` namespace will automatically get the Envoy sidecar.
(To check, if you deploy an Nginx pod, run kubectl get pods. You will see `READY 2/2`, which means your Nginx container *and* the Envoy sidecar are both running).

Part 4: Deep Dive - Traffic Management

This is Istio's killer feature. We will use three new K8s objects (CRDs) to control traffic: Gateway, VirtualService, and DestinationRule.

1. `Gateway` (The "Door")

An Istio Gateway replaces the K8s Ingress. It's a much more powerful "door" for traffic *entering* your cluster. It just defines the port and protocol (e.g., "Allow HTTPS traffic on port 443 for codewithmsmaxpro.me").

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-app-gateway
spec:
  selector:
    # Use the default Istio Ingress (which is a K8s LoadBalancer)
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "codewithmsmaxpro.me" # Only allow traffic for this host

2. `VirtualService` (The "Internal Router")

This is the most important object. A VirtualService *attaches* to a Gateway and tells it *where* to send the traffic. This is where you define your routing rules.

Let's create a rule: "When traffic comes in for codewithmsmaxpro.me, send it to our K8s service my-blog-service."

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-blog-vs
spec:
  hosts:
  - "codewithmsmaxpro.me" # Must match the host in the Gateway
  gateways:
  - my-app-gateway # Attaches to the Gateway we just made
  http:
  - route:
    - destination:
        host: my-blog-service # The K8s Service name
        port:
          number: 80

3. `DestinationRule` (The "Version Splitter")

This object defines *versions* (subsets) of your service. For example, "all Pods with label version: v1 are in the 'v1' subset, and all Pods with version: v2 are in the 'v2' subset."

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-app-versions
spec:
  host: my-app-service # We are defining subsets for this K8s service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Putting It All Together: The Canary Deployment

Now we have all the pieces. Let's deploy two versions of our app and use Istio to send **90%** of traffic to v1 and **10%** of (canary) traffic to v2.

First, you would have two K8s Deployment files, one for `v1` (with `replicas: 9`) and one for `v2` (with `replicas: 1`), both with the `version` label set.

Then, you apply this `VirtualService`:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app-canary
spec:
  hosts:
  - "my-app.example.com"
  ... (gateways) ...
  http:
  - route:
    # This is the routing rule
    - destination:
        host: my-app-service
        subset: v1 # From our DestinationRule
      weight: 90 # Send 90% of traffic to v1
    - destination:
        host: my-app-service
        subset: v2 # From our DestinationRule
      weight: 10 # Send 10% of traffic to v2

That's it! You have now implemented an advanced canary deployment. You can monitor the v2 subset in Prometheus/Grafana. If it's healthy, you can edit this file to weight: 50 / weight: 50, and finally weight: 0 / weight: 100 to complete the rollout.

Part 5: Deep Dive - Security (mTLS)

As we discussed, traffic *inside* your cluster is (by default) unencrypted HTTP. A service mesh fixes this *automatically* with **mTLS (Mutual TLS)**.

This means that not only does the `frontend` verify the `api` (like a normal HTTPS certificate), but the `api` also verifies the `frontend`. Both sides must prove their identity. Istio's `istiod` (the control plane) acts as a private Certificate Authority (CA) and automatically generates and rotates these certificates for every Pod.

Enforcing `STRICT` mTLS

By default, Istio is in PERMISSIVE mode (it accepts both encrypted mTLS and plain-text HTTP). This is good for migrating. Once all your pods have sidecars, you should lock it down by creating a PeerAuthentication policy.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default-strict-mtls
  namespace: default # Apply to the 'default' namespace
spec:
  mtls:
    mode: STRICT # "STRICT" means: DENY all plain-text HTTP traffic

By applying this one file, you have just encrypted all traffic between all services in your namespace.

`AuthorizationPolicy` (The K8s Firewall)

mTLS encrypts traffic, but it doesn't *stop* it. The `frontend` can still talk to the `admin-service`.
An AuthorizationPolicy is a firewall for your Pods. It lets you define fine-grained "allow" and "deny" rules based on service identity.

Example: Deny all, then allow `frontend`

# 1. First, DENY all traffic to everything in this namespace
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  {} # An empty spec selector defaults to "DENY"
---
# 2. Now, explicitly ALLOW traffic to 'my-api-service'
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-api
  namespace: default
spec:
  # Apply this policy to the 'api-service'
  selector:
    matchLabels:
      app: my-api-service
  # Allow...
  action: ALLOW
  rules:
  - from:
    - source:
        # ...traffic that comes FROM the 'frontend-service'
        principals:
        - "cluster.local/ns/default/sa/frontend-service-account"
    to:
    - operation:
        # ...and is a GET or POST request.
        methods: ["GET", "POST"]

Part 7: Istio Observability

Because every single request goes through an Envoy proxy, Istio automatically generates a massive amount of high-quality **metrics, logs, and traces** for your entire cluster, without you writing *any* code.

When you install Istio's "demo" profile, it comes with a pre-configured stack of open-source tools to visualize this data.

1. Kiali (The Service Map)

Kiali is a dashboard that plugs into Istio and renders a **live service graph** of your cluster. You can see which services are talking to which, how many requests per second, and what the error rate is, all in real-time.

# Open the Kiali dashboard
$ istioctl dashboard kiali

2. Jaeger (Distributed Tracing)

Istio's sidecars also generate "traces." A trace follows a single request from the moment it enters the cluster (at the Gateway) through every microservice it touches (frontend, api, auth, db) and back out.
**Jaeger** is a tool that collects and visualizes these traces as a "flame graph." This is the *ultimate* tool for debugging performance. You can see *exactly* which service is the bottleneck.

# Open the Jaeger dashboard
$ istioctl dashboard jaeger

3. Prometheus & Grafana

Istio's Envoy proxies expose thousands of Prometheus metrics (like istio_requests_total) out of the box. The demo install includes a pre-configured Prometheus server to scrape them and a pre-built Grafana dashboard to view them.

# Open the Grafana dashboard
$ istioctl dashboard grafana