Kubernetes – Service Mesh

techhadoop

While Kubernetes Networking handles the “plumbing” (getting a packet from A to B), a Service Mesh handles the “logic” of that communication.

As you move from 5 microservices to 500, managing things like retries, security, and tracking where a request went becomes impossible to code into every app. A Service Mesh pulls that logic out of your code and moves it into the infrastructure.

1. The Core Concept: The Sidecar Pattern

A Service Mesh doesn’t change your application code. Instead, it “injects” a tiny, high-performance proxy (usually Envoy) into every Pod. This is called a Sidecar.

  • Before Service Mesh: App A talks directly to App B. If the connection fails, App A’s code must decide whether to retry.
  • With Service Mesh: App A talks to its local Sidecar. The Sidecar talks to App B’s Sidecar. The Sidecars handle the encryption, retries, and logging automatically.

2. Architecture: Data Plane vs. Control Plane

A Service Mesh is split into two functional parts:

  • The Data Plane: The collection of all the Sidecar proxies. They do the “heavy lifting” of intercepting every single packet moving between services.
  • The Control Plane: The “brain” (e.g., Istiod in Istio). It doesn’t touch the packets. Instead, it provides the UI and API for the administrator to say, “Ensure all traffic is encrypted,” and then it pushes those rules out to all the Sidecars.

3. What does it actually do? (The “Big Three”)

FeatureWhat it solves
ObservabilityProvides a “Service Graph” showing exactly which apps are talking, their error rates, and latency without adding a single line of logging code.
Security (mTLS)Automatically encrypts all internal traffic. Even if a hacker gets into the network, they can’t “sniff” the data because every pod has its own unique certificate.
Traffic ControlAllows for Canary Deployments (e.g., “Send 5% of users to version 2.0, and 95% to version 1.0”) and Circuit Breaking (stopping traffic to a failing pod so it doesn’t crash the whole system).

4. Service Mesh vs. Ingress

This is a very common point of confusion.

  • Ingress (North-South): Manages traffic coming into the cluster from the outside world (the Internet).
  • Service Mesh (East-West): Manages traffic moving between services already inside the cluster.

Note: Some modern meshes (like Istio) can actually do both, replacing your traditional Ingress Controller with an “Ingress Gateway.”

5. Popular Service Mesh Tools

  • Istio: The most powerful and feature-rich, but also the most complex to manage. (Used by OpenShift as “OpenShift Service Mesh”).
  • Linkerd: Focused on being incredibly fast, light, and “just working” out of the box.
  • Consul: Great if you have a mix of Kubernetes and traditional Virtual Machines (VMs) that need to talk to each other.

When do you actually need one?

You probably don’t need a Service Mesh if you only have 2 or 3 services. The “Service Mesh Tax” is the extra CPU and Memory each sidecar consumes. You should consider a mesh when:

  1. You have a strict security requirement for encryption (mTLS) everywhere.
  2. You are struggling to debug “where the latency is” in a long chain of microservices.
  3. You need advanced deployment strategies like A/B testing or Canary releases.

Since Mutual TLS (mTLS) is the “killer feature” of most service meshes, let’s look at how it turns your cluster into a fortress without you changing a single line of code.

1. How mTLS Works (The “Identity Card” Method)

In a standard cluster, Pod A talks to Pod B over plain text. If a hacker intercepts the traffic, they see everything. With a Service Mesh, the Control Plane acts as a Certificate Authority (CA).

  1. Identity: Every Pod is issued a unique SVID (SPIFFE Verifiable Identity Document) in the form of a certificate.
  2. The Handshake: When Pod A tries to talk to Pod B, their Sidecars (Envoy) step in.
  3. Mutual Trust: Pod A presents its “ID card” to Pod B, and Pod B presents its “ID card” to Pod A. They both verify that the certificates are valid and signed by the cluster’s CA.
  4. Encryption: Once they trust each other, they create an encrypted tunnel. The actual applications (the “App Containers”) still think they are talking plain HTTP, but the “wire” between them is fully encrypted.

2. The Service Graph (Visualizing the Mesh)

One of the coolest parts of using a service mesh (like Istio in OpenShift) is Kiali. Kiali is a management console that draws a real-time map of your microservices.

  • Green Lines: Traffic is flowing perfectly (200 OK).
  • Red/Yellow Lines: High error rates (500 errors) or high latency.
  • Circles: These represent your versions. You can see, for example, that v1 is getting 90% of traffic and v2 is getting 10%.

3. Traffic Shifting (The “Canary” Deployment)

Imagine you have a new version of your Backend (v2) and you’re nervous about a full rollout. Instead of a “Big Bang” update, you can use a VirtualService to shift traffic slowly.

The Logic:

  • Send 90% of traffic to v1.
  • Send 10% of traffic to v2.
  • If the error rate for v2 stays low, move to 50/50, then 100%.

YAML

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend-weights
spec:
  hosts:
  - backend-service
  http:
  - route:
    - destination:
        host: backend-service
        subset: v1
      weight: 90
    - destination:
        host: backend-service
        subset: v2
      weight: 10

4. Summary: Why do developers love (and hate) Service Mesh?

ProsCons
Security: Instant encryption for compliance (HIPAA/PCI).Complexity: It’s “another thing” to manage and debug.
Retries: The mesh handles timeouts and retries automatically.Resource Heavy: Each sidecar takes ~50MB RAM and some CPU.
Traceability: You can see exactly where a request slowed down.Latency: Every packet has to hop through two proxies (Sidecars).

Is it right for you?

If you are running OpenShift, the “OpenShift Service Mesh” (based on Istio) is built-in and supported. It’s the easiest way to try it out because the installation is handled by an Operator.

In OpenShift (and standard Istio), “Sidecar Injection” is the magic moment where your Pod stops being a single container and becomes part of the Mesh. Instead of manually adding the proxy to your YAML, the Control Plane watches for new Pods and “mutates” them on the fly.

Here is how to enable it and verify it’s working.

1. Label the Namespace

The Service Mesh is polite; it won’t touch your Pods unless you ask it to. You must label your namespace to tell the Sidecar Injector to pay attention.

Bash

# Replace 'my-app-project' with your namespace
oc label namespace my-app-project istio-injection=enabled

Note for OpenShift Users: If you are using the official OpenShift Service Mesh (OSSM), you instead add your namespace to a resource called a ServiceMeshMemberRoll (SMMR) in the istio-system namespace.

2. Trigger the Injection

The Mesh cannot inject a sidecar into a Pod that is already running. You must restart your pods so the “Mutating Admission Webhook” can intercept the creation process.

Bash

oc rollout restart deployment/frontend -n my-app-project

3. Verify the “2/2” Status

Once the pods restart, look at the READY column in your pod list. This is the clearest sign of a Service Mesh in action.

Bash

oc get pods -n my-app-project

What you should see:

Plaintext

NAME                        READY   STATUS    RESTARTS   AGE
frontend-7f8d9b6d-x4z2      2/2     Running   0          30s
  • 1/1: Standard Kubernetes (Just your app).
  • 2/2: Service Mesh Active (Your app + the Envoy Proxy sidecar).

4. Inspecting the Sidecar

If you want to see what is actually inside that second container, you can describe the pod:

Bash

oc describe pod <pod-name>

You will see a new container named istio-proxy. This container is the one handling all the mTLS encryption, telemetry, and routing rules we discussed.

5. Troubleshooting Injection

If your pod still says 1/1 after a restart, check these three things:

  1. Labels: Ensure the namespace label istio-injection=enabled is exactly right.
  2. Resource Requests: If your cluster is very low on memory, the sidecar might fail to start (it usually needs about 50Mi to 128Mi of RAM).
  3. Privileged Pods: In OpenShift, pods running as root or with high privileges sometimes have security policies (SCCs) that conflict with the sidecar’s network interception.

Summary Checklist

  • [ ] Label the Namespace.
  • [ ] Restart the Deployment.
  • [ ] Check for 2/2 Ready status.
  • [ ] Open Kiali to see the traffic start flowing!

Leave a comment