Stop 09 · Containers & OrchestrationTopics · 8/9

Container Networking in the Cloud

In short

Pods get new IP addresses every time they restart. So how does your frontend find the API, and how does the internet find your frontend? Kubernetes networking answers both.

How containers get IP addresses and communicate with each other and the outside world within a managed Kubernetes or container service — building on Phase 2's VPC networking fundamentals.

The blob character smiles while using a wall-mounted intercom phone in a flat.

Think of it like this

The apartment intercom

Flat 304's tenant changes every year, but dialling 304 on the intercom always reaches whoever lives there. Visitors at the gate don't dial flats directly; the guard connects them. Services are the extension numbers; the load balancer is the guard.

Watch it happen

A request finds its way in

Browser

Load balancer

web pod

api Service

GET shop.example.com

1/5DNS points to a cloud load balancer created by your Ingress or a LoadBalancer Service.

The big ideas

What you need to know

Service

A stable name and virtual IP in front of a changing set of pods, chosen by labels.

Ingress or Gateway

Routes outside HTTP traffic by host and path to Services, usually through one cloud load balancer.

VPC-native pods

Cloud CNIs give pods IPs from your VPC subnets. Plan subnet sizes, or you'll run out of addresses.

Network policies

By default any pod can talk to any pod. NetworkPolicy rules restrict that, if your CNI supports them.

See it in code

Walk through the code

yaml

1apiVersion: v12kind: Service3metadata:4  name: api5spec:6  type: ClusterIP7  selector:8    app: api9  ports:10    - port: 8011      targetPort: 8080

1/4A Service named api. That name becomes a DNS entry inside the cluster.

Inside the same namespace, other pods reach this at http://api. From another namespace use api.<namespace>.svc.cluster.local.

Save yourself the pain

Common mistakes

Oops

Calling another pod by its IP address copied from kubectl get pods.

Do this instead

Pod IPs change on every restart. Always call the Service name.

Oops

Creating a separate LoadBalancer Service for every microservice.

Do this instead

Each one can create a paid cloud load balancer. Use one Ingress or Gateway to route to many Services.

Your mission

Find the API by name

~30 min

Quick check

Why do pods talk to each other through Services instead of pod IPs?

Go deeper

1Deploy 2 containers/pods and verify they can communicate with each other by service name.
2Learn how your managed orchestration service's networking model maps onto the underlying VPC.
3Understand why container networking adds a layer of abstraction on top of standard VPC networking.