Quiz: Istio Service Mesh

← Back to quiz index

6 questions

L1 (3 questions)

1. What are the core components of Istio and what does each one do?

Show answer

Istiod (control plane): combines Pilot (traffic management, xDS config to Envoy), Citadel (certificate management, mTLS), and Galley (config validation). Envoy sidecar (data plane): injected into each pod, handles all inbound/outbound traffic. Key resources: VirtualService (routing rules), DestinationRule (load balancing, circuit breaking), Gateway (ingress), PeerAuthentication (mTLS policy), AuthorizationPolicy (access control). Istiod pushes config to Envoy sidecars via xDS APIs.

2. How do you configure traffic routing in Istio for a canary deployment?

Show answer

Create a VirtualService with weighted routing: route 95% to v1 subset and 5% to v2 subset. Define subsets in a DestinationRule using pod labels (version: v1, version: v2). Example: spec.http[0].route has two destinations with weight 95 and 5. Shift weight gradually (95/5 -> 80/20 -> 50/50 -> 0/100). Combine with header-based routing to force internal testers to v2 (match headers, route to v2 with weight 100). Monitor with Kiali dashboard or Prometheus metrics per-version.

3. What is an Istio Gateway and how does it differ from a Kubernetes Ingress?

Show answer

Istio Gateway configures an Envoy proxy at the edge of the mesh to handle inbound traffic. Unlike Kubernetes Ingress (which only supports basic HTTP routing), Gateway supports: TLS termination with SNI, HTTP/2 and gRPC, traffic shifting, fault injection, and fine-grained routing via VirtualService. The Gateway resource defines ports and TLS settings; the VirtualService defines routing rules and attaches to the Gateway. This separation of concerns is more flexible than Ingress's combined model.

L2 (3 questions)

1. How does Istio implement mutual TLS (mTLS) and what is the difference between STRICT and PERMISSIVE mode?

Show answer

Istio's Citadel issues SPIFFE-compliant x509 certificates to each workload via the SDS API. Envoy sidecars use these for mutual TLS. PERMISSIVE mode: accepts both plaintext and mTLS connections — use during migration when not all services have sidecars. STRICT mode: requires mTLS for all connections — rejects plaintext. Apply per-namespace or per-workload via PeerAuthentication. Migration path: start PERMISSIVE, verify all services have sidecars (istioctl analyze), then switch to STRICT. Monitor with istio_requests_total metric filtered by connection_security_policy.

2. What are the common causes of high latency introduced by Istio sidecars and how do you mitigate them?

Show answer

Causes:
1. Two extra network hops per request (source sidecar -> destination sidecar).
2. TLS handshake overhead (mitigated by connection pooling).
3. Large xDS config push (hundreds of services means MB of config).
4. Envoy filter chain processing. Mitigation: use Sidecar resource to limit the scope of config each proxy receives (exportTo, egress hosts). Enable protocol sniffing to avoid full HTTP parsing on TCP services. Tune concurrency (proxy CPU). Use mTLS connection pooling (h2_upgrade_policy). Typical added latency is 1-3ms per hop — if higher, check sidecar resource limits.

3. How do you troubleshoot an Istio configuration that is not taking effect?

Show answer

1. Run istioctl analyze to check for configuration errors (missing destinations, conflicting rules).
2. Check proxy config: istioctl proxy-config routes to verify routes are pushed to the sidecar.
3. Check istiod logs for config rejection or push failures.
4. Verify label selectors: VirtualService host must match the service name, DestinationRule subsets must match pod labels.
5. Check namespace: is the VirtualService in the right namespace or using exportTo correctly?
6. Use istioctl proxy-status to verify all proxies are in SYNCED state.