Service Mesh Architecture

The Two Planes of a Service Mesh

To achieve the "invisible networking" described in the previous chapter, almost all Service Meshes divide their architecture into two distinct components: the Data Plane and the Control Plane.

Understanding this separation is the absolute key to grasping how a service mesh functions.

The Data Plane (The Sidecar Proxies)

The Data Plane is responsible for actually touching, reading, encrypting, and moving the electrical network packets holding your data.

In Kubernetes, this is implemented using a pattern called the Sidecar Proxy.

How the Sidecar Works

When you deploy your application (e.g., Node.js Web App) inside a Kubernetes Pod, the Service Mesh system notices this deployment. It completely automatically injects a second, hidden container directly into the exact same Pod. This second container is the Sidecar Proxy (typically using the ultra-fast Envoy proxy software).

Because both containers live in the exact same Pod, they share the same physical localhost network space.

1. Egress (Outbound interception): When the Node.js app tries to make an HTTP call to the Payment Server, it sends the packet locally. The Sidecar proxy aggressively intercepts it via iptables. The Proxy encrypts it, decides which exact node to route it to, and physically sends it over the physical wire.
2. Ingress (Inbound interception): When the Payment Server responds, the packet hits the Node.js Pod. But it doesn't hit the Node app! It hits the Sidecar proxy. The proxy decrypts it, validates the security certificates, and passes the raw text to the Node.js application.

graph LR
    subgraph Pod A [Frontend Pod]
        A[Node.js App] <--> |Localhost| B(Sidecar Proxy)
    end
    
    subgraph Pod B [Backend Pod]
        C(Sidecar Proxy) <--> |Localhost| D[Database App]
    end
    
    B <==> |Encrypted Physical Network| C

Because of the sidecars, your applications never actually talk to each other. The Sidecars talk to each other on behalf of your applications.

The Control Plane (The Brain)

If you have 500 microservices running, you now have 500 individual Sidecar Proxies running alongside them.

How do all 500 proxies know which rules to follow?

• How do they know the secret encryption keys they need to use?
• How do they know if a developer requested 5% of traffic be dynamically rerouted to a new Canary deployment?

This is the job of the Control Plane.

The Control Plane does NOT touch the network packets. It does not look at your data.

The Control Plane is a global, central daemon (like Istio's istiod) that calculates policies, manages TLS certificates, aggregates telemetry data, and pushes configuration updates down to the 500 "dumb" proxies in the Data Plane.

The Feedback Loop

1. An administrator edits a Kubernetes YAML file to mandate that all internal traffic must be encrypted.
2. The Control Plane reads this YAML.
3. The Control Plane generates 500 unique SSL certificates.
4. The Control Plane pushes these certificates and the new "encryption required" rule down out to all 500 Data Plane proxies via a gRPC stream.
5. The Data Plane instantly begins encrypting all packets.