KCNA — Service Mesh Basics

2 minute read

Service Mesh Basics

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It manages traffic, security, and observability between microservices.

Why Service Meshes Exist

In a microservices architecture, you might have hundreds of services communicating:

Challenge Without Service Mesh With Service Mesh
Traffic routing Application handles routing logic Mesh handles routing transparently
Encryption (mTLS) Each service implements its own TLS Automatic mutual TLS between all services
Retries/timeouts Application code handles failures Mesh automatically retries and times out
Observability Each service adds its own logging/metrics Mesh provides built-in metrics, traces, and logs
Load balancing Application-level load balancing Intelligent, service-aware load balancing

How a Service Mesh Works

The Sidecar Pattern

Most service meshes use the sidecar proxy pattern:

┌──────── Pod ────────────┐
│                          │
│  ┌──────────┐ ┌────────┐│
│  │   App    │ │ Sidecar ││
│  │Container │ │  Proxy  ││
│  │          │←│(Envoy)  ││
│  └──────────┘ └────┬───┘│
│                     │    │
└─────────────────────┼────┘
                      │
              ┌───────┴───────┐
              │  Data Plane   │
              │ (all proxies) │
              └───────┬───────┘
                      │
              ┌───────┴───────┐
              │ Control Plane │
              │ (mesh config) │
              └───────────────┘

Every pod gets a sidecar proxy that intercepts all network traffic. The application doesn’t need to know about the mesh.

Two Planes

Plane Components What It Does
Data Plane Sidecar proxies (Envoy) in every pod Handles actual traffic between services
Control Plane Mesh controller (Istiod, Linkerd control plane) Configures and manages the proxies

Key Service Mesh Features

Feature What It Does Why It Matters
Mutual TLS (mTLS) Encrypts all service-to-service traffic automatically Zero-trust security without code changes
Traffic management Canary deployments, A/B testing, traffic splitting Safe rollouts
Observability Automatic metrics, distributed tracing, access logs See exactly what’s happening between services
Retries and timeouts Automatically retries failed requests Improved reliability
Circuit breaking Stops sending traffic to unhealthy services Prevents cascade failures
Service Mesh Key Feature Proxy Complexity
Istio Most feature-rich; widely adopted Envoy High
Linkerd Lightweight, simple, Kubernetes-native linkerd2-proxy (Rust) Low
Cilium Service Mesh eBPF-based, no sidecars needed Embedded in kernel Medium
Consul Connect Multi-platform (not K8s-only) Envoy Medium

Envoy

Aspect Details
What it is High-performance L4/L7 proxy
CNCF status Graduated
Used by Istio, many API gateways, AWS App Mesh
Key feature Dynamic configuration via API (no restarts needed)

Envoy is the most important proxy to know for the KCNA — it’s the foundation of most service mesh implementations.

Service Mesh vs CNI vs Ingress

Technology Layer What It Handles
CNI Network (L3/L4) Pod IP assignment, basic routing
Service Mesh Application (L4/L7) Service-to-service traffic, mTLS, observability
Ingress Edge (L7) External traffic entering the cluster

When Do You Need a Service Mesh?

You Might Need One If You Probably Don’t Need One If
Many microservices (50+) Small number of services
Need mTLS everywhere Simple internal communication
Complex traffic routing requirements Basic load balancing is enough
Need deep observability into service communication Prometheus + basic logging suffices
Compliance requires encrypted service-to-service traffic No strict compliance requirements

Key Takeaways for the Exam

  • A service mesh manages service-to-service communication transparently
  • Most meshes use the sidecar proxy pattern (proxy container in every pod)
  • Two planes: data plane (proxies) and control plane (configuration)
  • Key features: mTLS, traffic management, observability, retries, circuit breaking
  • Envoy is the CNCF Graduated proxy used by Istio and others
  • Istio is the most feature-rich mesh; Linkerd is the simplest
  • Service mesh sits at a higher layer than CNI — CNI handles basic networking, mesh handles application-level traffic

What’s Next?

Let’s explore how containers handle persistent data.

Container Storage →

Updated:

You may also enjoy