Traffic Management & mTLS

Sidecars & Injection

# Every pod in this namespace automatically gets an Envoy sidecar added —
# no per-deployment YAML edits needed
kubectl label namespace my-app istio-injection=enabled

# The app just talks to localhost; the sidecar intercepts and manages
# all inbound/outbound traffic transparently, with no app code changes.

Canary Rollouts with VirtualService & DestinationRule

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts: [reviews]
  http:
    - route:
        - destination: { host: reviews, subset: v1 }
          weight: 90
        - destination: { host: reviews, subset: v2 }
          weight: 10   # canary — gradually increase as confidence grows

# A typo in a subset label selector can route traffic to an EMPTY pool
# (widespread errors) or send full production traffic to the unvalidated
# canary — roll out routing changes gradually and monitored, like a deploy.

mTLS Migration

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: my-app
spec:
  mtls:
    mode: PERMISSIVE  # accepts BOTH mTLS and plaintext — essential while
                       # some callers still lack sidecars during migration
# mode: STRICT once every service has a sidecar — switching too early
# breaks any caller that can't yet originate mTLS traffic.