Lesson 34.1 · Kubernetes: Ingress, Gateway API & Service Mesh · 10 min read

North-south and east-west: the traffic map

Q: What is the difference between north-south and east-west traffic, and which tools handle each?

North-south traffic enters or leaves the cluster: users calling shop.lab from outside. It goes through an edge proxy: a LoadBalancer Service at L4 and then an ingress controller or a Gateway at L7, which routes by host and path and usually terminates TLS. East-west traffic flows between Services inside the cluster; by default it is plain Service-to-Service networking, and a service mesh adds a proxy next to every pod for mTLS, retries, timeouts and uniform telemetry. When something fails, the first question is which of those hops answered.

In plain words

Picture a city with a ring road around it and streets inside. Cars coming from outside enter through a few big gates in the ring road; cars inside the city drive from street to street. The gates have guards, signs and toll booths; the inner streets usually have none.

Traffic into a cluster is north-south: it comes from users through a small number of entry points, the edge proxies. Traffic between Services inside the cluster is east-west. This lesson draws that map, explains the difference between an L4 proxy (it only sees TCP connections) and an L7 proxy (it reads HTTP: hosts, paths, headers), where TLS can end, and which tool in this chapter owns which part of the road.

Two directions of traffic

Chapter 16 built the basics: a Service gives pods a stable address (16.1), an Ingress plus a controller routes HTTP from outside to Services (16.19), and Gateway API splits that job across objects owned by different teams (16.26). This chapter goes one level down, into the parts that page you at night.

What you need to know already: Services and EndpointSlices (16.1), LoadBalancer and MetalLB (16.6), Ingress, the controller and IngressClass (16.19), TLS termination and SNI (16.22, 9.15), Gateway API's GatewayClass, Gateway and HTTPRoute (16.26), NetworkPolicy (16.29), HTTP status codes and proxies (9.21-9.23).

Platform people sort traffic by where it comes from:

North-south traffic crosses the edge of the cluster: a customer's browser, a partner's API client, a webhook from a payment provider. It enters through an edge proxy (an ingress controller, a Gateway's data plane) that terminates TLS and routes by host and path.
East-west traffic stays inside: the web front end calling the cart service, the cart calling inventory. It used to be "just a ClusterIP" (16.3). A service mesh puts a proxy next to every pod, so east-west calls get the same things the edge has: TLS, identity, retries, timeouts, per-request logs.

                    north-south
  browser ──TLS──> [ edge proxy ] ──> web ──> cart ──> inventory
                    ingress-nginx       └──── east-west ────┘
                    or a Gateway        (ClusterIP, or a mesh)

The words are old data-centre slang: diagrams drew the internet at the top (north) and the servers in a row (east to west).

L4 and L7

A proxy works at one of two levels:

L4 (layer 4, TCP/UDP): it sees connections and ports. kube-proxy's rules (16.3), a NodePort, MetalLB and most cloud network load balancers are L4. They can spread connections but cannot read a URL or a header.
L7 (layer 7, HTTP): it parses each request. nginx, Envoy, HAProxy are L7. Only L7 can route /api and / to different Services, retry one failed request, or return 503 with a reason.

The cost of L7 is that the proxy must see the bytes - so it must hold the TLS key, or the traffic must be plaintext by the time it gets there.

Where TLS ends

Three patterns, all common:

edge termination   client ─TLS─> proxy ─HTTP─> pod       the proxy holds the cert (16.22)
re-encrypt         client ─TLS─> proxy ─TLS──> pod       the proxy also talks TLS to the pod
passthrough        client ─TLS──────────────> pod       the proxy routes by SNI only (L4-ish)

A mesh adds a fourth: mTLS between sidecars - the app talks plain HTTP to its own sidecar on localhost, and the two sidecars encrypt and authenticate the hop between them. No app change, every hop encrypted.

Who owns what in this chapter

piece              what it does                               team that usually owns it
ingress-nginx      L7 edge proxy driven by Ingress objects    platform (retired project!)
cert-manager       gets and renews TLS certificates           platform
external-dns       writes DNS records for your entry points   platform
Gateway API        the successor API for the edge             platform (Gateway) + apps (routes)
Istio (a mesh)     a proxy per pod: mTLS, policy, retries     platform + SRE

You will run all of them in the lab cluster, and break each one the way it breaks in production.

The status codes you will chase

Every edge or mesh proxy answers with a status code even when your app never saw the request. Knowing who produced a 503 is half the diagnosis:

404  the proxy found no route for this host/path (the app was never asked)
502  the proxy reached a pod, but the connection broke (refused, reset, bad TLS)
503  the proxy had nowhere to send it (no endpoints, no healthy upstream)
504  the proxy waited for an answer and gave up (a timeout you can configure)

The rest of the chapter adds the proxy's own evidence for each: nginx's error log line, Envoy's response flag in the access log, a Gateway's status condition.

Quick check

$ kubectl get svc -n ingress-nginx ingress-nginx-controller

The controller Service in this lab: which type is it?

ClusterIP: only reachable from inside
NodePort: ports 30080/30443 on every node
LoadBalancer with an EXTERNAL-IP

Answer

NodePort: ports 30080/30443 on every node - The lab installs the bare-metal flavour of ingress-nginx (16.20): a NodePort Service. Some missions switch it to LoadBalancer so it can listen on port 80.

What you can now do:

say whether a flow is north-south or east-west, and which proxy handles it
tell an L4 balancer from an L7 proxy by what it can see
name where TLS ends in edge termination, re-encrypt, passthrough and mesh mTLS

Why it helps

Every debugging session later in the chapter starts with "which hop failed?", and you cannot answer it without a map of the hops. Knowing whether a component works at L4 or L7 tells you what it can possibly do: a LoadBalancer Service cannot route by path, an ingress controller can.

The map also tells you whose problem a failure is. The edge belongs to the platform team, routes to app teams, the mesh to whoever runs it. Naming the owner quickly saves a lot of time in an incident channel. And the table of status codes at the end is the first thing you will look up when a 502, 503 or 504 shows up.

Commands in this lesson

kubectl

FAQ

Is a LoadBalancer Service an ingress?

No. A LoadBalancer Service works at L4: it forwards TCP connections to a Service's pods and knows nothing about hosts or paths. An ingress controller or a Gateway is an L7 proxy that usually sits behind such a LoadBalancer and does the HTTP routing, TLS and error pages.

What does "terminate TLS" mean?

The proxy that terminates TLS holds the certificate and private key, decrypts the request and sees plain HTTP. After it, traffic is plain unless something encrypts it again (re-encrypt) or the proxy never decrypted it at all (passthrough, where it routes only by the SNI name). Where TLS ends decides who can read headers and route by path.

Why would east-west traffic need encryption inside my own cluster?

Because "inside" is a big place: many teams, many workloads, and a node that one compromised pod shares with others. Encrypting and identifying every call between Services (mTLS) means a stolen network position is not enough to read or fake traffic, and policies can say exactly which workload may call which.

Are north-south and east-west official Kubernetes terms?

They are industry terms, not Kubernetes API names. You will meet them in design docs, vendor material and interviews. In Kubernetes objects the closest words are Ingress and Gateway for the edge, and Service for traffic inside the cluster.

Which status codes come from a proxy rather than my app?

Usually 502 (the proxy reached a backend and the connection broke), 503 (nowhere healthy to send it), 504 (it waited too long) and often 404 (no route matched). The proxy's error page, a server: nginx or server: envoy header and its own log line tell you the answer did not come from the app.

In an interview Mid

What is the difference between north-south and east-west traffic, and which tools handle each?

North-south traffic enters or leaves the cluster: users calling shop.lab from outside. It goes through an edge proxy: a LoadBalancer Service at L4 and then an ingress controller or a Gateway at L7, which routes by host and path and usually terminates TLS. East-west traffic flows between Services inside the cluster; by default it is plain Service-to-Service networking, and a service mesh adds a proxy next to every pod for mTLS, retries, timeouts and uniform telemetry. When something fails, the first question is which of those hops answered.

Also asked: What is the difference between an L4 and an L7 load balancer? · Where can TLS terminate, and what changes with passthrough? · Which status codes would make you suspect the proxy rather than the application?

Practise this lesson in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.