--- tags: - k8s - l1 - flashcard-deck - service-mesh --- [Portal](../../../../library/portal/index.md) | **Level:** [L1: Foundations](../../../../library/portal/levels.md) | **Topics:** [Service Mesh](../../../../library/portal/topics.md) | **Domain:** Kubernetes id category difficulty tags question answer source_path service-mesh/a1b2c3d4e5f1 service-mesh easy service-mesh, architecture What is a service mesh and what are its two main components? "A service mesh is a dedicated infrastructure layer for managing service-to-service communication. Its two main components are the data plane (sidecar proxies intercepting all traffic between pods) and the control plane (configures proxies, issues certificates, collects telemetry).\n\nRemember: ""Service mesh = infrastructure layer for service-to-service communication."" It handles mTLS, retries, circuit breaking, and observability.\n\nName origin: The term ""service mesh"" was coined by Buoyant (Linkerd creators) in 2017. William Morgan wrote the original blog post defining it.\n\nFun fact: The concept was inspired by Twitter\'s internal Finagle library, which handled similar concerns in their JVM microservices." training/library/topics/service-mesh/primer.md service-mesh/b2c3d4e5f1a2 service-mesh easy service-mesh, sidecar, injection How does sidecar injection work in Istio and Linkerd? Both use a Kubernetes mutating admission webhook to automatically inject a proxy container into pods. In Istio, you label the namespace (kubectl label namespace myapp istio-injection=enabled). In Linkerd, you annotate it (linkerd.io/inject=enabled). Each pod then has two containers: the app and the proxy.\n\nUnder the hood: The mutating webhook intercepts Pod creation API calls and patches the Pod spec to add the proxy container before the Pod is scheduled. training/library/topics/service-mesh/primer.md service-mesh/c3d4e5f1a2b3 service-mesh easy service-mesh, observability What four golden signals does a service mesh provide for free without application instrumentation? "Request rate (RPS per service/route), error rate (4xx/5xx percentages), latency (p50/p95/p99 per route), and topology (live service dependency graph).\n\nRemember: ""Sidecar = proxy container next to your app."" It intercepts all network traffic transparently. Your app doesn't need code changes.\n\nExample: Envoy is the most common sidecar proxy, used by Istio and others.\n\nName origin: The four golden signals come from Google\'s SRE book (2016): latency, traffic, errors, saturation. A mesh gives you three of four automatically." training/library/topics/service-mesh/primer.md service-mesh/d4e5f1a2b3c4 service-mesh medium service-mesh, mtls How does mutual TLS (mTLS) work in a service mesh? The control plane acts as a Certificate Authority. Each proxy gets a short-lived TLS certificate tied to its ServiceAccount identity. Every connection between services is encrypted and mutually authenticated. Certificates rotate automatically (24h default in Istio). No application code changes required. training/library/topics/service-mesh/primer.md service-mesh/e5f1a2b3c4d5 service-mesh medium service-mesh, istio, traffic-management How do you implement a canary deployment in Istio using VirtualService and DestinationRule? "Define subsets in a DestinationRule (v1 and v2 with label selectors), then create a VirtualService that routes traffic by weight (e.g., 90% to subset v1, 10% to subset v2). Adjust weights to shift traffic gradually.\n\nRemember: ""Control plane = brain, Data plane = muscle."" Control plane configures the proxies; data plane (sidecars) handles actual traffic.\n\nExample: Start at 95/5 (5% canary), monitor error rate, then 90/10, 75/25, 50/50, 0/100. Shift back to 100/0 if errors spike." training/library/topics/service-mesh/primer.md service-mesh/f1a2b3c4d5e6 service-mesh medium service-mesh, istio, linkerd, comparison What are the key differences between Istio and Linkerd in terms of proxy technology and resource overhead? "Istio uses Envoy (C++) as its sidecar proxy with ~100MB per sidecar overhead. Linkerd uses linkerd2-proxy (Rust) with ~20MB per sidecar. Istio offers more features and configuration options; Linkerd is simpler and more opinionated with lower resource usage.\n\nRemember: ""mTLS in mesh = zero-trust networking."" Every service proves its identity. No plaintext between services.\n\nGotcha: mTLS adds latency — measure the overhead before enabling mesh-wide.\n\nNumber anchor: Envoy (Istio) uses ~100MB per sidecar. linkerd2-proxy (Rust) uses ~20MB. For a cluster with 1000 pods, that\'s 100GB vs 20GB of overhead." training/library/topics/service-mesh/primer.md service-mesh/02a3b4c5d6e7 service-mesh medium service-mesh, istio, mtls What is the difference between Permissive and Strict mTLS modes in Istio? "Permissive mode (the default) accepts both plaintext and mTLS connections, allowing gradual migration. Strict mode requires mTLS for all connections and rejects plaintext traffic. You enforce strict mode with a PeerAuthentication resource setting mtls.mode to STRICT.\n\nRemember: ""Permissive = migration mode (accepts both). Strict = enforced (mTLS only)."" Always start permissive, then switch to strict." training/library/topics/service-mesh/primer.md service-mesh/13b4c5d6e7f8 service-mesh hard service-mesh, istio, retries How do you configure retries and timeouts in an Istio VirtualService, and what is the retryOn field used for? "In the VirtualService http route, set timeout (e.g., 5s), retries.attempts (e.g., 3), retries.perTryTimeout (e.g., 2s), and retries.retryOn (e.g., ""5xx,reset,connect-failure"") to specify which response codes or conditions trigger a retry. This prevents wasting retries on non-transient errors.\n\nGotcha: Retries can amplify load during an outage. Always set retries.retryOn to specific error codes (5xx, reset) — never retry on 4xx (client errors)." training/library/topics/service-mesh/primer.md service-mesh/24c5d6e7f8a9 service-mesh hard service-mesh, linkerd, smi How does Linkerd implement traffic splitting, and how does it differ from Istio's approach? Linkerd uses the SMI (Service Mesh Interface) TrafficSplit CRD, which specifies a root service and weighted backends (e.g., my-service-v1 at 900m, my-service-v2 at 100m). Istio uses its own VirtualService and DestinationRule CRDs with subset-based routing. Linkerd's approach uses a vendor-neutral standard; Istio's is more feature-rich but proprietary.\n\nName origin: SMI = Service Mesh Interface. A CNCF project that defines vendor-neutral CRDs for traffic management across different meshes. training/library/topics/service-mesh/primer.md service-mesh/35d6e7f8a9b0 service-mesh hard service-mesh, pitfalls, operations Why can Istio's port naming requirement cause silent failures, and what must you do to avoid it? Istio requires Service ports to be named with a protocol prefix (e.g., http-web, grpc-api). Unnamed ports are treated as opaque TCP, which means L7 features like retries, traffic splitting, and observability silently stop working for those ports. Always name ports with the correct protocol prefix.\n\nGotcha: This is the #1 gotcha when adopting Istio. Unnamed ports silently lose L7 features. Add `name: http-web` or `name: grpc-api` to every Service port. training/library/topics/service-mesh/primer.md --- ## Wiki Navigation ### Related Content - [Interview: Service Mesh 503s](../../../../library/interview-scenarios/15-service-mesh-503s.md) (Scenario, L3) — Service Mesh - [Runbook: Istio 503 Errors](../../../../library/runbooks/kubernetes/istio_503_errors.md) (Runbook, L3) — Service Mesh - [Service Mesh](../../../../library/topics/service-mesh/index.md) (Topic Pack, L3) — Service Mesh - [Service Mesh Drills](../../../../library/drills/service_mesh_drills.md) (Drill, L3) — Service Mesh - [Skillcheck: Service Mesh](../../../../library/skillchecks/service-mesh.skillcheck.md) (Assessment, L3) — Service Mesh