Stackbook Logo
← Back to Tools

Istio Service Mesh Essentials

Get started with Istio: install, sidecar injection, traffic routing, mutual TLS, authorization policy, gateways and operational pitfalls on Kubernetes.

4 min read

What it is and when to use it

Istio is an open source service mesh for Kubernetes. It adds a uniform layer for traffic management, security and observability between services without changing application code. Under the hood it programs Envoy proxies, either as sidecars beside each pod or, in ambient mode, through shared node-level and optional waypoint proxies.

Use Istio when you have many services and need mutual TLS everywhere, fine-grained canary releases, retries and timeouts managed centrally, authorization between workloads, or consistent telemetry. For a handful of services, the operational overhead may outweigh the benefit; a simple ingress controller could be enough.

Quick start

Install with istioctl, using the demo or default profile, then enable injection for a namespace.

curl -L https://istio.io/downloadIstio | sh -
cd istio-*/ && export PATH=$PWD/bin:$PATH

istioctl install --set profile=default -y
kubectl label namespace demo istio-injection=enabled
kubectl rollout restart deployment -n demo

istioctl analyze -n demo
istioctl proxy-status

Pods in the demo namespace now start with an istio-proxy sidecar container. Helm charts for base, istiod and the gateway are also available if you prefer a GitOps flow.

Core concepts

Control plane and data plane. The istiod component distributes configuration, certificates and service discovery. Envoy proxies form the data plane and enforce policy.

Gateway. Handles traffic entering the mesh.

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: web-gateway
  namespace: demo
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "app.example.com"

VirtualService defines routing rules, and DestinationRule defines subsets and per-destination policy such as load balancing and circuit breaking.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
  namespace: demo
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 90
        - destination:
            host: reviews
            subset: v2
          weight: 10
      timeout: 3s
      retries:
        attempts: 2
        perTryTimeout: 1s
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
  namespace: demo
spec:
  host: reviews
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Pods need a version label matching the subset selectors for the split to work. Istio also supports the Kubernetes Gateway API, which is the direction of the project for new installs.

Security. PeerAuthentication controls mutual TLS, and AuthorizationPolicy controls who can call what.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: demo
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/demo/sa/frontend"]
      to:
        - operation:
            methods: ["GET"]

Observability. Sidecars emit request metrics, access logs and trace spans. Prometheus scrapes them, Grafana shows dashboards, Jaeger visualizes traces, and Kiali draws the service graph. Applications must still propagate trace headers between incoming and outgoing calls.

Pitfalls

  • Roll out mTLS gradually: begin with PERMISSIVE mode, verify, then move to STRICT. Jumping straight to strict breaks non-mesh clients and health probes from outside.
  • Sidecars add CPU, memory and a little latency to every pod. Set resource requests and measure.
  • Pods must be restarted after labeling a namespace for injection, and again after upgrades so they pick up the new proxy.
  • Service ports must be named or declare appUseProtocol correctly, otherwise Istio treats traffic as plain TCP and loses HTTP features.
  • Overlapping VirtualServices for the same host merge unpredictably. Keep one owner per host.
  • Retries combined with timeouts at several layers can amplify load. Set them deliberately.
  • Use istioctl analyze and istioctl proxy-config to debug, and upgrade with canary revisions rather than in place.
  • Jobs and init containers can hang because the sidecar is not ready or never exits; use native sidecar support in recent Kubernetes versions.

How it fits an architecture

Istio sits between services inside the cluster. Terraform creates the cluster, Helm or Argo CD installs the mesh and its configuration from Git, and CI promotes versions by editing routing weights in a pull request, giving auditable canary deployments. The ingress gateway replaces or complements an edge Nginx or HAProxy tier, while internal east-west traffic is secured and measured by Envoy.

Key takeaways

  • Istio provides mTLS, traffic shaping and telemetry without application changes.
  • Learn the core resources: Gateway, VirtualService, DestinationRule, PeerAuthentication and AuthorizationPolicy.
  • Adopt incrementally, moving mTLS from permissive to strict.
  • Budget for sidecar overhead and operational complexity, or evaluate ambient mode.
  • Manage mesh configuration through Git and validate with istioctl analyze.