KUBERNETES: FROM BASIC TO ADVANCED

Module 8: Helm, Operators & GitOps

xdev.asia

🎯 Lesson Objective_

Understand why Service Mesh is needed, compare 3 popular implementations in 2026 (Cilium Sidecarless, Istio Ambient, Linkerd), and know when to choose what for a specific use case.

1. Why do we need Service Mesh?

Microservices create many challenges:

• mTLS: encrypt traffic between services, authenticate identity
• Traffic management: canary, circuit breaking, retry, timeout
• Observability: distributed tracing, metrics per service-to-service
• Load balancing: L7 load balancing is smarter than kube-proxy

Service Mesh implements these features at the infrastructure level — application code does not need to be changed.

2. Sidecar vs Sidecarless Architecture

Traditional Mesh Service (Istio sidecar mode) injects Envoy proxy into each Pod:

Pod: [app container] + [Envoy sidecar proxy]
# Tất cả traffic đi qua Envoy → overhead về latency và resource
# Overhead: ~50MB memory/pod + ~2ms latency thêm

Sidecarless approach (Cilium, Istio Ambient): proxy located outside the Pod, at node level or kernel level.

3. Cilium Service Mesh — Sidecarless eBPF

Cilium implements Service Mesh at kernel level with eBPF — no need for sidecar proxy in Pod.

Advantages:

• 40-60% reduced network overhead compared to Istio sidecar
• Least Latency (kernel-space processing)
• No need to inject sidecar → simpler, easier to upgrade__HTMLTAG_117___
• Native integration with Cilium CNI (one stack for networking + policy + mesh)
• Hubble: L7 observability integrated__HTMLTAG_121___

Disadvantages:

• Fewer features than Istio full (no fault injection, advanced traffic management)
• Ask Cilium to be a CNI

# Enable Cilium Service Mesh
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set ingressController.enabled=true \
  --set ingressController.loadbalancerMode=shared
mTLS: enable mutual authentication
kubectl annotate namespace production 

"service.cilium.io/global=true"
Verify mTLS với Hubble
hubble observe --namespace production --protocol tcp --verdict FORWARDED

4. Istio Ambient Mode — Stable Istio 1.24+

Istio Ambient Mode (stable since Istio 1.24+) is an alternative that does not use sidecars.

Architecture:

• ztunnel: per-node L4 proxy, mTLS handling and basic routing for all workloads__HTMLTAG_145___
• Waypoint proxy: per-workload L7 proxy, optional — deploy only when needed L7 features

Node:
├── ztunnel (L4: mTLS, basic routing) ← tất cả workloads đi qua
│
Namespace "production":
├── app-a pod       → cần mTLS? → ztunnel handles it
├── app-b pod       → cần canary L7? → ztunnel + waypoint proxy
└── waypoint proxy  → L7: HTTP routing, header manipulation, metrics

# Cài Istio Ambient
istioctl install --set profile=ambient
Enable ambient cho namespace
kubectl label namespace production istio.io/dataplane-mode=ambient
Deploy waypoint cho L7 features
istioctl waypoint apply --namespace production --enroll-namespace
Verify
istioctl experimental waypoint status -n production

Advantages of Istio Ambient: Reduce resources by ~40% compared to sidecar mode. Full Istio features when needed (waypoint). Compatible with the Istio ecosystem.

5. Linkerd — Rust Micro-proxy

Linkerd uses linkerd2-proxy written in Rust — smallest, fastest of the service meshes with sidecars.

• Sidecar but extremely light: ~10MB memory/proxy (compared to Envoy ~50MB)
• Rust: memory-safe, zero-cost abstractions, ultra-fast
• Automatic mTLS without configuration
• HTTP/1.1, HTTP/2, gRPC support
• Simple retries and timeouts__HTMLTAG_171___
• Service profiles: per-route metrics and retries__HTMLTAG_173___

# Cài Linkerd
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
Inject sidecar
kubectl annotate namespace production linkerd.io/inject=enabled
Verify
linkerd check
linkerd viz install | kubectl apply -f -
linkerd viz dashboard   # mở browser

Linkerd vs Cilium vs Istio: Linkerd is suitable when you want the lightest, simplest sidecar model.

6. Compare Service Mesh 2026

Feature              Cilium Mesh    Istio Ambient    Linkerd
───────────────────────────────────────────────────────────────
Architecture         Sidecarless    Sidecarless*     Sidecar (Rust)
Memory overhead/pod  ~0             ~0**             ~10MB
mTLS                 ✅            ✅               ✅
L7 traffic mgmt      Limited        ✅ (waypoint)    Limited
Circuit breaking     ❌            ✅               ❌
Fault injection      ❌            ✅               ❌
Observability        ✅ (Hubble)   ✅               ✅
Gateway API          ✅ Native     ✅               ✅
Multi-cluster        Limited        ✅               ✅ (linkerd-multicluster)
Complexity           Low            Medium           Low
CNCF status          Graduated      Graduated        Graduated
Best for             Cilium clusters,  Enterprise,    Lightweight,
                     new clusters  full feature set  resource-constrained

Ambient không inject sidecar vào application pods
** ztunnel là shared per-node, không per-pod

7. Traffic Management with Istio

# VirtualService: canary deployment
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
  namespace: production
spec:
  hosts:
  - my-app
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: my-app
        subset: canary
  - route:
    - destination:
        host: my-app
        subset: stable
      weight: 90
    - destination:
        host: my-app
        subset: canary
      weight: 10
---
# DestinationRule: define subsets
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-app
spec:
  host: my-app
  trafficPolicy:
    connectionPool:
      http:
        http2MaxRequests: 1000
    outlierDetection:
      consecutive5xxErrors: 5       # circuit breaking
      interval: 30s
      baseEjectionTime: 30s
  subsets:
  - name: stable
    labels:
      version: stable
  - name: canary
    labels:
      version: canary

8. When to choose what?

• Cilium Service Mesh: used Cilium CNI, want sidecarless, priority performance, mTLS and basic traffic management is enough__HTMLTAG_189___
• Istio Ambient Mode: enterprise, needs full Istio features (circuit breaking, fault injection, advanced traffic), already has Istio expertise__HTMLTAG_193___
• Linkerd: want sidecar model but lightest, simplest, resource-constrained clusters
• Do not use Service Mesh: small cluster, few services, NetworkPolicy is enough isolation

Summary

• Service Mesh: mTLS, traffic management, observability at infrastructure level
• Cilium Sidecarless: eBPF kernel-level, lowest overhead, suitable for clusters used Cilium
• Istio Ambient: L4 ztunnel + optional L7 waypoint, most complete
• Linkerd: Rust micro-proxy, lightest sidecar model__HTMLTAG_213___
• Trend 2026: sidecarless is the way to go, but Istio sidecar is still used in enterprise