Read Your Own Pod's Network

Goal

Networking does not stick when you learn it from diagrams. You will read the network of the Pod you are using right now yourself.

This is not an example made for a textbook but a real production cluster, so things that never appear in books show up as they are: a /32 address, a path MTU that differs from the interface's, and search domains.

Where to look

ip -4 addr show eth0        # 내 주소
ip route                    # 어디로 나가나
ip route get 1.1.1.1        # 이 목적지로는 어떻게 가나
cat /sys/class/net/eth0/mtu # 인터페이스 MTU
cat /etc/resolv.conf        # 이름을 어떻게 푸나
ss -tan                     # 지금 연결 상태

Test server

python3 -m http.server 8080 --bind 127.0.0.1 &

Steps

Address and netmask → 01-addr.txt
Routing → 02-route.txt
MTU → 03-mtu.txt
DNS → 04-dns.txt
Port conflict → 05-port.txt
HTTP typed by hand → 06-http.txt
Connection states → 07-states.txt
Summary → 08-notes.md

Notes

This Pod cannot reach the outside Internet. Only DNS lookups are open. So do all the experiments against a server inside this Pod. You still learn everything there is to learn.

My address and netmask

Check this Pod's IP and netmask and save them to 01-addr.txt, and write one line on what that netmask means.

Use ip -4 addr show eth0. You should see /32.

/32 means I am alone on this network. Normally, as with /24, there are neighbors in the same range, but here there are none. How it gets out to the outside is the next step.

But how does it get out

Extract the routing table and save it to 02-route.txt, and write why it can reach the gateway even though it is a /32.

Use ip route. You should see two lines: default via <게이트웨이> and <게이트웨이> dev eth0 scope link (the gateway address goes where the Korean word is).

The second line is the answer. It tells the kernel that that address is reachable directly without routing (on-link). By the netmask it is not in the same range, but because this route exists, it can reach the gateway.

The MTU of the interface and the path differ

Check the MTU of eth0 and the MTU of the default route separately and save them to 03-mtu.txt. If they differ, write why as well.

For the interface, use cat /sys/class/net/eth0/mtu, and for the path, use ip route get 1.1.1.1.

The interface should be 1500 and the path smaller. This is because the tunnel adds headers: this cluster connects nodes with an encrypted tunnel, and the size that can be carried shrinks by that much.

If you set the MTU wrongly, the symptom is that small requests work but only large responses stall. It is the kind of problem whose cause is hardest to find.

How a short name gets resolved

Look at /etc/resolv.conf, actually look up one short name, and save it to 04-dns.txt.

cat /etc/resolv.conf has nameserver and search. Look up a short name such as getent hosts kubernetes.default.

The domains listed in search are tried appended in order. Like this: kubernetes.default → kubernetes.default.<네임스페이스>.svc.cluster.local → … (the namespace goes where the Korean word is). That is why it is found even when written short.

One program per port

Start a server on port 8080, then try to start one more on the same port, and save the error that appears to 05-port.txt.

Start one with python3 -m http.server 8080 --bind 127.0.0.1 &, and then try a bind to the same address from Python.

You get [Errno 98] Address already in use. Only one program can hold an address+port combination. This is the identity of the "port already in use" error.

Type HTTP by hand

Without a library, write the HTTP request string yourself over a TCP connection, receive the response, and save it to 06-http.txt.

Bash alone is enough.

exec 3<>/dev/tcp/127.0.0.1/8080
printf 'GET / HTTP/1.1\r\nHost: localhost\r\nConnection: close\r\n\r\n' >&3
timeout 3 head -8 <&3

Line endings must be \r\n, and there must be one more blank line at the end of the headers. HTTP is just exchanging agreed-upon text over TCP.

Connections have states

While creating and closing a connection, watch with ss how the state changes and save it to 07-states.txt. TIME-WAIT must be visible.

Look with ss -tan. While connected it is ESTAB, and after closing, TIME-WAIT remains for a while.

TIME-WAIT is not a bug. It holds the slot for a moment so that late-arriving packets do not get mixed into the next connection. If these pile up on a server that creates many short connections, ports run dry, which is why connections are reused (keep-alive).

Summarize three things

Write at least three lines in 08-notes.md: why communication works even with a /32, the symptom when the MTU is off, and why TIME-WAIT exists.

The text must contain 경로 (route), MTU, and TIME-WAIT.