👋 Hi! I’m Bibin Wilson. In each edition, I share practical tips, guides, and the latest trends in DevOps and MLOps to make your day-to-day DevOps tasks more efficient. If someone forwarded this email to you, you can subscribe here to never miss out!
🔥 Complete Kubernetes & CKA Course
Master Kubernetes and crack CKA with my Kubernertes + CKA preparation course bundle.
Deep-dive explanations, real-world examples, and rich illustrations- all in text format. No more wasting hours on videos. Learn faster, revisit concepts instantly
What is xDS protocol?
Envoy uses the xDS protocol for dynamic configuration.
When it comes to Ingress and Gateway API controllers, whenever you apply routing rules, the changes take effect almost immediately.
Classic Ingress controllers and NGINX Gateway Fabric reload the NGINX configuration whenever there is an update in routing rules.
This is similar to how service discovery updates are handled in non-Kubernetes environments.
But proxies like Envoy, which can be used as Ingress or Gateway API controllers, work differently. They use the xDS protocol.
And xDS does not require a reload. This means configuration changes, such as adding or updating a route, are applied directly in memory. There is no need to restart or reload the proxy process.
Core Components of xDS
The "x" in xDS stands for a variety of different discovery services that handle specific parts of the networking stack.
Following are the key discovery service that are part of xDS.
LDS (Listener Discovery Service): Defines "where" Envoy should listen (e.g., Port 80, 443) and which filter chains to apply.
RDS (Route Discovery Service): Defines "how" to route traffic based on HTTP headers, paths, or domains to specific virtual clusters. For example,
/apito backend service and/loginto backend service BCDS (Cluster Discovery Service): Defines the upstream "clusters" (logical groups of backend services) that Envoy can send traffic to.
EDS (Endpoint Discovery Service): Defines the "who", the actual IP addresses and ports of the individual pods or instances currently running.
How xDS Works with Envoy
The following image illustrates the xDS workflow in Envoy proxy.
Here is how it works.
State Change: An administrator updates a Kubernetes resource, such as an
HTTPRouteor aService.Translation: The Envoy Gateway Control Plane watches these changes and translates the high-level Kubernetes constructs into the specific Envoy configuration (xDS).
The Push: The Envoy Control Plane pushes these updates over a gRPC stream to the Envoy Proxy Pods.
Instant Application: The Envoy proxies receive the update and apply it in-memory immediately. This means active user requests (Step 1 in the diagram) are never dropped because the proxy never needs to stop to "re-read" a file.
Envoy’s xDS protocol has become the standard way to configure Istio service mesh and cloud-native proxies.
In Istio service mesh, xDS is the protocol that the control plane uses to talk to the data plane. When Istio watches Kubernetes resources like services, routes, or traffic rules, it turns them into Envoy configurations and pushes them to the Envoy proxies using xDS APIs
📦 Keep Yourself Updated
EKS Production-Grade Pain: shares real-world lessons from the engineering team at Probo as they scaled their applications using Amazon EKS
Docker MCP Catalog: Docker launched a solution that simplifies finding and using MCP‑based AI tools
agntcy.org: AGNTCY is an open-source project (now managed by the Linux Foundation) created by Cisco. It’s designed to help AI agents from different companies and tools work together easily and safely.
Agentic DevOps: The blog looks at how DevOps is changing. Instead of just automating fixed tasks, it is now moving toward AI-powered systems that can learn on the fly, adapt to new situations, and take action in real time
🛠️ DevOps Tools
warp.dev: An AI‑powered terminal that generates commands, explains errors, executes tasks with your permission, and understands natural language commands
Temporal: It is a tool that helps you build reliable and long-running apps. Apps often break due to server crashes, network issues, or bugs. Temporal remembers what your app was doing, and lets it continue from where it stopped, without starting over.
