Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Your laptop terminal
You curled the Pod's IP from your laptop. Nothing. A Pod is the unit that runs your app in Kubernetes. Here, web-7d4f9-x2kq shows Running, one of one ready, with IP 10.244.1.15. Everything looks healthy, yet the curl on port 8080 just hangs, then times out.
$ kubectl get pods -o wide
NAME READY STATUS IP
web-7d4f9-x2kq 1/1 Running 10.244.1.15
$ curl http://10.244.1.15:8080
... (hangs, then times out)Same IP, different network
The IP is fine. The network is the problem. In most setups, Pod IPs live on a private cluster network. Your laptop sits outside that boundary and has no route in, so the request goes nowhere. A test Pod inside the cluster reaches 10.244.1.15 on port 8080 without trouble.
Quick test: tunnel in with port-forward
The quickest fix is kubectl port-forward. It opens a tunnel from port 8080 on your laptop's localhost, through kubectl, to port 8080 on the Pod. In a second terminal, curl localhost works and returns Hello from web. It's great for debugging, but the tunnel closes when the command ends.
$ kubectl port-forward pod/web-7d4f9-x2kq 8080:8080
Forwarding from 127.0.0.1:8080 -> 8080
# in another terminal
$ curl http://localhost:8080
Hello from webReal access: a Service in front of Pods
For real access, put a Service in front of the Pods. A Service is a stable address for a group of Pods. Pod IPs change when Pods restart, but the Service name and address stay put. Here, the laptop hits the LoadBalancer's public IP, which forwards to Service web, then on to Pod A or Pod B on port 8080.
Inside the cluster: Pod IP. Outside: port-forward or Service.
Inside the cluster, a Pod IP works. From outside, you need a way in. Use port-forward to test quickly, and a Service to expose it.