Learn Envoy Proxy - Envoy in Kubernetes & Service Mesh Ecosystems

#Introduction

Everything you've learned now meets the platform where Envoy is most widely used: Kubernetes and the service mesh ecosystem. Episode 19 covers how Envoy becomes a sidecar in Istio, the difference between using Envoy directly and using Envoy as a mesh data plane, and deployment patterns for Kubernetes workloads.

This is the unifying episode: the xDS, mTLS, routing, and observability concepts from earlier episodes all play a role here — but managed by a control plane, not manual configuration.

#Envoy Sidecar in Istio

#What istiod Does

Istio uses Envoy as its data plane and istiod as its control plane. You don't write Envoy bootstraps; you write Istio resources like VirtualService and DestinationRule, and istiod translates them into xDS config for every sidecar.

kubectl get pods -n prod -l app=orders -o jsonpath='{.items[0].spec.containers[*].name}'
kubectl exec -it deploy/orders -n prod -c istio-proxy -- curl -s localhost:15000/server_info

The kubectl exec ... -c istio-proxy command enters the sidecar container named istio-proxy. The Envoy inside exposes its admin interface on port 15000 — a different port than we usually use in the lab, but all admin endpoints stay the same.

#Istio Resources Translated to Envoy

Here's an example VirtualService that actually becomes Envoy routes:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: orders-route
  namespace: prod
spec:
  hosts:
    - orders
  http:
    - match:
        - uri:
            prefix: /api/orders
      route:
        - destination:
            host: orders
            subset: v2
          weight: 5
        - destination:
            host: orders
            subset: v1
          weight: 95
      retries:
        attempts: 3
        retryOn: connect-failure,retriable-status-codes

This VirtualService resource speaks a higher-level language: subset v1 and v2 defined in a DestinationRule, canary weights, and retries. istiod translates all of it into the weighted clusters and retry policies you already learned in episodes 18 and 10.

#Inspecting the Sidecar's Envoy Config

To see istiod's translation output:

kubectl exec -it deploy/orders -n prod -c istio-proxy -- curl -s localhost:15000/config_dump
kubectl exec -it deploy/orders -n prod -c istio-proxy -- curl -s localhost:15000/listeners

The config_dump endpoint in the sidecar shows the listeners and routes Envoy actually uses. This is the bridge of understanding: what you see in your static Envoy lab looks the same here — only the source is different.

#Envoy Direct vs Envoy as a Mesh Data Plane

#The Fundamental Difference

Two ways to use Envoy, two levels of control:

• Envoy directly: you write the bootstrap and config yourself, with full control and full responsibility.
• Envoy as a mesh data plane: the control plane (Istio, Gloo) writes the config; you manage high-level resources.

Both use the same Envoy. The difference is who manages the config and how deep the control you need goes.

#When to Choose Which

Choose Envoy directly if:

• Your architecture is simple or special-purpose.
• You need full control over every config field.
• You don't want to depend on an abstraction layer.

Choose a service mesh if:

• You have many services with consistent policies (mTLS, tracing, retries).
• You want centrally managed per-namespace policies.
• You need mesh-wide observability without touching every config.

#The Danger of Abstraction

Mesh abstractions hide details. When something fails, you still need to understand the Envoy underneath — that's why this series teaches Envoy from the ground up first. Troubleshooting a sidecar without understanding xDS, filters, and listeners would be very hard.

#Deployment Patterns for Kubernetes

#Automatic Sidecar Injection

Istio injects sidecars automatically into eligible pods:

kubectl label namespace prod istio-injection=enabled
kubectl rollout restart deployment/orders -n prod

The kubectl label namespace istio-injection=enabled command makes every new pod in that namespace get a sidecar. To see the sidecar template without applying it, run istioctl kube-inject -f deployment.yaml.

#Gateway and GatewayClass

For inbound traffic, modern service meshes use the Gateway resource:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: edge
  namespace: istio-system
spec:
  gatewayClassName: istio
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: edge-cert

The Gateway resource is the new generation of Kubernetes API gateway implemented by Istio, Gloo, and many others — all ultimately using Envoy as their engine.

#Monitoring the Sidecar

Complete the deployment pattern with observability:

kubectl logs deploy/orders -n prod -c istio-proxy --tail=20
kubectl port-forward -n istio-system svc/istiod 15014:15014

The kubectl logs ... -c istio-proxy command shows the sidecar Envoy's access logs. These logs record every request between services — the starting point for debugging mesh routing.

#Closing

Episode 19 positioned Envoy in its biggest ecosystem: as a sidecar in Istio managed by istiod, the difference between running Envoy directly versus as a mesh data plane, and the deployment and injection patterns in Kubernetes.

Key takeaways:

• In Istio, istiod is the control plane that translates resources into xDS.
• The Envoy sidecar exposes its admin on port 15000.
• VirtualService and DestinationRule become Envoy weighted clusters and retries.
• Envoy directly gives full control; a mesh gives centralized policy.
• Mesh troubleshooting still requires understanding the Envoy behind the abstraction.
• Automatic sidecar injection makes every pod ready with a proxy.

In the next episode, episode 20, we'll discuss GitOps, CI/CD and configuration management — managing Envoy config in a GitOps flow, validating config in CI/CD, and rolling updates with config change management.