Network & K8s.01-2 Across the Network

0. Contents

1. Overview

01-1 에서 이어지는 이번 편

• 01-1 은 컴퓨터 한 대 안에서 curl 을 뜯어본 이야기였다
• 이 글은 그 상자가 밖으로 나가는 이야기다
• 01-1 의 캡처는 루프백(lo0)이라 MAC 주소도 라우터도 없었다
• 이번엔 실제 와이파이에서 공유기, 통신사, 인터넷을 건너간다

볼 것 네 가지

• 노트북이 상대가 같은 동네인지 판단하는 방법
• 동네 밖으로 나간 패킷이 길을 찾는 방법
• 이번 칸에서 건넬 기기의 MAC 을 알아내는 방법
• 쿠버네티스가 이 모든 걸 다시 조합하는 방식

2. IP — 끝까지 바뀌지 않는 주소

IP 가 하는 일과 하지 않는 일

• IP 의 일은 상자에 주소를 붙여 목적지까지 보내는 것이다
• 다만 도착을 약속하지는 않는다
  • 잃어버려도, 순서가 바뀌어도 IP 는 신경 쓰지 않는다
  • 그 뒷수습은 TCP 가 한다

2.1 IPv4 헤더 — 캡처 값으로 읽기

IP 헤더 20바이트의 실제 모양

• 01-1 에서 뜯어본 IP 헤더 20바이트를 실제 모양대로 그렸다
• 색이 있는 칸만 보면 된다

TTL: 패킷의 수명

• TTL 은 라우터를 하나 지날 때마다 1씩 준다
• 0 이 되면 버려진다 → 길을 잃은 패킷이 영원히 떠도는 걸 막는 장치다
• 4장의 traceroute 가 이걸 이용한다

2.2 MTU — 짐칸보다 크면 사라진다

MTU 와 경로 중간의 작은 구간

• MTU 는 한 번에 보낼 수 있는 패킷의 최대 크기다
• 보통 1500바이트다
• 이보다 큰 데이터는 보통 TCP 가 처음부터 잘게 나눠 보낸다
• 문제는 경로 중간에 MTU 가 더 작은 구간이 있을 때다
  • 패킷이 버려진다
  • 원래는 “너무 크다” 는 ICMP 알림이 돌아온다

실무에서 자주 겪는 증상: 큰 응답만 멈춤

• 중간 방화벽이 그 ICMP 알림까지 막아 버리면 → 보내는 쪽은 패킷이 왜 사라지는지 모른다
• 작은 요청은 잘 되는데 큰 응답만 멈춘다
• 쿠버네티스에서 VXLAN 을 쓸 때 특히 자주 나온다 → 6.2 에서 다시 본다

2.3 NAT — 공유기는 출발 주소를 바꿔 쓴다

사설 주소와 NAT

• 집 안의 192.168.x.x 주소는 집 안에서만 쓰는 사설 주소다
• 이 주소로는 인터넷에 나갈 수 없다
• 그래서 공유기가 나가는 패킷의 출발 주소를 자기 공인 주소로 바꿔 쓴다 → 이게 NAT 다

답장이 돌아오는 길

• 공유기는 바꾼 내용을 장부에 적어 둔다
• 답장이 오면 다시 노트북의 주소로 돌려준다
• 도착 주소는 그대로다

기억할 것: 바뀔 수 있는 출발 주소

• 받는 서버는 노트북의 진짜 주소를 모른다
• 출발 주소는 중간에 바뀔 수 있다
• 7장에서 쿠버네티스 Service 가 이 NAT 를 반대 방향으로 쓴다

2.4 CIDR — 마스크는 패킷에 실리지 않는다

패킷마다 하는 판단

• 노트북은 패킷을 보낼 때마다 한 가지를 판단한다: 이 주소가 같은 동네인가, 아닌가
• 같은 동네면 직접 보내고, 아니면 공유기에 맡긴다
• 그 기준이 /24 다

ifconfig en0 | grep "inet "
# inet 192.168.0.112 netmask 0xffffff00 broadcast 192.168.0.255

넷마스크 읽기

• netmask 0xffffff00 이 /24 다
• 뜻은 하나다: 주소의 앞 세 칸(192.168.0)이 같으면 같은 동네다
• 이 동네에는 기기를 254대까지 붙일 수 있다

꼭 기억할 것: 패킷에 없는 마스크

• 이 /24 는 패킷 어디에도 적혀 있지 않다
• 2.1 의 그림을 다시 보면, IP 헤더의 주소 칸은 출발과 도착 두 개뿐이다
• 마스크는 노트북 혼자 들고 있는 설정이다

그래서 생기는 일 두 가지

• 같은 IP 라도 마스크가 다르면 동네가 달라진다
  • 192.168.1.2/24 에게 192.168.5.9 는 다른 동네지만, /16 이면 같은 동네다
  • 그래서 같은 동네의 기기들은 마스크를 똑같이 맞춰야 한다
  • 한 기기만 틀리면 그 기기만 판단이 어긋나고, 패킷에는 흔적이 남지 않는다
  • 원인은 ifconfig 를 봐야 찾는다
• 마스크가 맞는지 장비가 스스로 검사하지는 않는다
  • 사람이 정하거나, 공유기가 DHCP 로 주소와 함께 나눠 준 값을 그대로 믿고 쓴다

쿠버네티스도 같은 방식

• Pod 전체에 /16 을 잡고, 노드마다 /24 씩 나눠 준다

2.5 LAN 과 서브넷 — 선이 정하는 범위, 주소가 정하는 범위

“같은 동네” 의 정확한 이름

• 지금까지 “같은 동네” 라고 부른 건 정확히는 같은 서브넷이다
• “같은 와이파이”, “같은 LAN” 과 비슷하게 쓰지만 둘은 다른 것이다
• 아래 그림의 브로드캐스트는 같은 LAN 의 모두에게 한 번에 보내는 것을 말한다(5.2)

둘을 짝짓는 DHCP

• 둘을 짝지어 주는 게 DHCP 다
• 와이파이에 막 붙은 노트북이 주소를 받는 과정을 보면 → LAN 이 IP 보다 먼저 있다는 것도 함께 보인다

DHCP 메시지의 모양

• 아직 IP 가 없는데도 IP 패킷으로 보낸다는 점이 재미있다
• 출발 주소를 0.0.0.0 으로 비워 둔다
• 도착을 255.255.255.255(이 LAN 의 모두)로 적는다

짝이 어긋날 때

• 짝이 맞아야 노트북의 판단(2.4)이 맞는다
• 어긋나면 아래처럼 된다
• 예시 주소는 모두 사설 대역이다

실무에서 가장 흔한 어긋남: VPN

• 공유기 기본값이 대개 192.168.0.x 나 192.168.1.x 다
• 그래서 집과 회사 내부가 같은 사설 대역을 쓰는 일이 잦다

3. Routing and BGP — 이정표는 누가 세우나

3.1 라우팅 테이블 — 가장 길게 맞는 줄

라우팅 테이블이라는 이정표

• 패킷은 스스로 길을 모른다
• 라우터마다 있는 라우팅 테이블을 보고 다음 칸으로 넘어갈 뿐이다 → 이정표라고 생각하면 된다
• 노트북에도 라우팅 테이블이 있다

netstat -rn -f inet           # Linux: ip -4 route show
route -n get 1.1.1.1          # Linux: ip route get 1.1.1.1

중요한 줄 세 개

• 주소 두 개를 넣어 보면 어느 줄을 타는지 보인다

줄을 고르는 규칙

• 어떤 주소가 여러 줄에 맞으면 → 가장 구체적인 줄을 따른다
• 아무 줄에도 안 맞으면 → default 로 간다
• 구글이든 네이버든 우리 동네가 아니면 전부 공유기로 가는 이유다

2.4 와 이어지는 부분: 숫자가 붙는 곳

• /24 같은 숫자는 패킷이 아니라 이 테이블의 줄에 붙어 있다
• 패킷의 도착 주소는 처음부터 끝까지 그대로다
• 라우터마다 자기 테이블과 비교할 뿐이다
• 편지 봉투와 같다
  • 봉투의 주소는 그대로다
  • 먼 우체국은 “서울” 까지만 보고, 가까운 우체국은 “역삼동” 까지 본다

공인 IP 하나, 여러 크기의 덩어리

• 그래서 공인 IP 하나가 여러 크기의 덩어리에 동시에 속하는 것도 정상이다
• 멀리 있는 라우터는 /16 같은 큰 덩어리로 알고 있다
• 가까운 라우터는 /24 로 알고 있다

3.2 default 의 사슬 — 통신사가 공유기에, 공유기가 노트북에

default 줄을 적은 쪽

• 노트북의 default 줄은 공유기가 알려 줬다
• 공유기의 default 는 통신사가 알려 줬다

아래는 한 줄, 맨 위는 전 세계 경로

• 아래쪽 기기들은 “모르면 위로 넘긴다” 한 줄이면 충분하다
• 진짜 길을 아는 건 맨 위의 통신사 라우터들이다
• 통신사의 큰 라우터는 전 세계 경로를 들고 있다
  • IPv4 만 약 100만 줄이다
  • 주소가 43억 개인데 100만 줄로 되는 건 → 주소를 큰 덩어리로 묶어서 적기 때문이다

3.3 BGP — 대역의 도달 경로를 광고한다

100만 줄을 채우는 방법

• 통신사 라우터의 100만 줄은 사람이 쓰지 않는다
• 라우터끼리 서로 알려 줘서 채운다
• 그 방법이 BGP(Border Gateway Protocol)다

알려 줘야 하는 이유: 주소의 주인만 아는 정보

• KT 라우터에는 케이블이 여러 개 꽂혀 있다
• 142.250.1.1 로 가는 패킷이 오면 어느 케이블로 보내야 할지 정해야 한다
• 그런데 그 주소가 구글 것이라는 걸 KT 는 원래 모른다
• 주소의 주인인 구글이 알려 줘야 이정표에 적을 수 있다

소식이 퍼지는 방식

• 이 소식이 이웃에서 이웃으로 퍼지면서 전 세계 이정표가 채워진다
• 받은 라우터는 여러 길 중 하나를 골라 테이블에 적는다
• 사용자 패킷 안에 BGP 가 들어 있는 건 아니다
  • BGP 는 이정표를 미리 세워 두는 일만 한다
  • 사용자 패킷은 세워진 이정표만 보고 지나간다

KT 와 구글이 “이어져 있다” 는 것의 실제 모습

연결의 정체: 라우터 포트 사이의 광케이블

• 말 그대로 라우터 포트끼리 광케이블을 꽂아 둔 것이다
• 여러 회사가 한 건물(IX)에 라우터를 모아 두고 서로 케이블을 연결한다
• 그 케이블 위에서 TCP 179 번으로 BGP 대화를 한다

무선은 짧은 구간뿐

• 무선은 생각보다 아주 짧은 구간에만 쓰인다
  • 노트북에서 공유기까지
  • 폰에서 기지국까지
• 나머지는 전부 광케이블이다
• 그래서 온프레미스로 서버를 운영하는 회사도 무선이 아니라 고정 IP 가 붙은 기업용 회선을 쓰거나, 서버를 데이터센터에 맡긴다

BGP 를 쓰는 곳

• 통신사만이 아니다
• 여러 망과 직접 이어진 곳, 구글 같은 큰 서비스나 클라우드도 쓴다
• 집은 길이 하나뿐이다 → BGP 없이 DHCP 로 받은 default 한 줄이면 된다

3.4 Kubernetes 에서 — 알리거나 감싸거나

쿠버네티스의 같은 문제: 바깥이 모르는 Pod 주소

• Pod 주소(10.244.x.x)는 쿠버네티스가 만든 주소라서, 바깥 라우터들은 모른다
• 다른 노드에 있는 Pod 에게 보내는 방법은 크게 둘이다

방법을 고르는 쪽: CNI

• 어느 방법을 쓸지는 CNI 플러그인이 정한다
• 감싸기는 6장에서 뜯어본다

4. ICMP — IP 계층의 진단과 오류 통지

ICMP 의 역할

• ICMP 는 네트워크 상태를 알려 주는 짧은 메시지다
• 01-1 의 6.2 에서 닫힌 UDP 포트의 거절을 전해 준 게 ICMP 였다

IP 안에 바로 들어가는 별도 프로토콜

• ICMP 는 TCP 나 UDP 를 거치지 않고 IP 안에 바로 들어간다
• TCP, UDP 와 나란히 있는 별도의 프로토콜이다
• 포트가 없어서 → 프로그램이 아니라 OS 가 답한다

자주 보는 종류 세 가지

4.1 ping — 포트가 없어서 OS 가 답한다

공유기로 보낸 ping

• ping 은 상대 주소까지 패킷이 갔다 오는지 확인한다
• 공유기에 보내 봤다

ping -c 3 192.168.0.1
# 3 packets transmitted, 3 packets received, 0.0% packet loss
# round-trip avg = 9.2 ms

9ms 의 원인: 와이파이 구간

• 바로 옆 공유기인데 9ms 다
• 와이파이 구간 때문이다
• 유선이면 보통 1ms 도 안 걸린다

ping 해석 때 주의할 두 가지

• 답이 없다고 서버가 죽은 건 아니다
  • 방화벽이 ICMP 만 막았을 수 있다
• 답이 와도 웹 서버가 살아 있다는 뜻은 아니다
  • ping 은 주소까지만 확인한다
  • 포트는 TCP 로 직접 확인해야 한다

nc -zv 127.0.0.1 8080   # 8080 포트에 TCP 연결만 시도해 본다

4.2 traceroute — TTL 을 하나씩 늘려 길을 그린다

traceroute 의 원리: 2.1 의 TTL

• traceroute 는 목적지까지 거쳐 가는 라우터를 보여 준다
• TTL 을 1 로 보내면 첫 라우터에서 수명이 다해 Time Exceeded 가 돌아온다 → 그걸로 첫 칸이 누군지 안다
• TTL 을 2, 3 으로 늘려 가면 경로 전체가 그려진다

traceroute -n -q 1 -w 2 1.1.1.1

실제로 찍힌 경로

• 3장에서 그림으로 본 “집 → 통신사 → … → 목적지” 가 실제로 이렇게 찍힌다

결과를 읽을 때 볼 두 가지

• 3~6번의 * 는 길이 끊긴 게 아니다
  • 패킷은 잘 넘겨 주면서 Time Exceeded 답만 안 보내는 라우터다
  • 9번까지 도착한 게 그 증거다
• 1.1.1.1 은 미국 회사 주소인데 16ms 만에 답이 왔다
  • 미국까지 다녀오면 150ms 는 걸려야 한다
  • 같은 주소를 세계 여러 곳에서 동시에 알리는 방식(애니캐스트, BGP) 덕분에 가까운 서버가 답한 것이다

5. Ethernet and ARP — 이번 한 칸의 주소

5.1 MAC 과 IP — 최종 주소와 이번 칸

패킷에 붙는 두 종류의 주소

• IP 주소와 MAC 주소
• 둘의 차이를 알면 이 장은 끝이다
• 노트북에서 구글까지 가는 동안 두 주소가 어떻게 되는지 보자

IP 는 끝까지, MAC 은 칸마다

• IP 는 최종 목적지라 끝까지 같다
• MAC 은 이번 한 칸에서 받을 옆 기기라 칸마다 바뀐다
• 택배로 치면
  • IP 는 송장에 적힌 최종 받는 사람이다
  • MAC 은 지금 이 구간에서 상자를 넘겨받을 사람이다

Ethernet: MAC 주소를 붙이는 규칙

• MAC 주소를 붙이는 규칙이 Ethernet 이다
• IP 가 하나의 프로토콜인 것처럼 Ethernet 도 IP 한 층 아래의 프로토콜이다
• Ethernet 헤더가 IP 헤더에 해당한다
• 프레임 모양은 아래와 같다

5.2 ARP — 같은 링크에서 IP 를 MAC 으로

IP 를 MAC 으로 바꾸는 ARP

• 노트북이 공유기에게 보내려면 공유기의 MAC 을 알아야 한다
• 그런데 노트북이 아는 건 IP(192.168.0.1)뿐이다
• 이걸 MAC 으로 바꿔 주는 게 ARP 다

방법: 동네 전체에 묻는 브로드캐스트

• 방법은 단순하다: 같은 동네 전체에 물어보고, 해당 기기만 답한다
• 이렇게 같은 LAN 의 모두에게 한 번에 보내는 걸 브로드캐스트라고 한다
• 받는 MAC 칸에 ff:ff:ff:ff:ff:ff 를 적으면 된다

알아낸 MAC 의 보관

• 한 번 알아낸 MAC 은 한동안 저장해 두고(ARP 캐시) 다시 묻지 않는다
• arp -a 로 볼 수 있다

ARP 메시지의 핵심 네 칸

• 보내는 쪽 MAC 과 IP, 찾는 쪽 MAC 과 IP
• 질문할 때는 찾는 쪽 MAC 이 빈칸이다 → 답하는 기기가 그 빈칸을 채워 돌려준다
• 안에 IP 주소가 들어 있지만 배달 주소가 아니라 질문 내용이다

IP 헤더 없이 Ethernet 에 실리는 ARP

• 그래서 ARP 는 IP 헤더 없이 Ethernet 에 바로 실린다
• 보통 L2(링크 계층)로 분류하고, IP 주소를 다루니 L2 와 L3 사이라고도 한다
• IP 헤더가 없다는 게 중요하다
  • 라우터는 IP 헤더를 보고 넘겨 주는 장비다 → ARP 는 라우터를 넘어가지 못한다
  • ARP 질문은 항상 같은 동네 안에서만 들린다

실제 와이파이에서 한 캡처

sudo tcpdump -i en0 -nn arp
# ARP, Request who-has 192.168.0.35 tell (집의 다른 PC), length 46
# ARP, Request who-has 192.168.0.35 tell (집의 다른 PC), length 46
# … 약 1초 간격으로 계속, 답은 없음

캡처에서 알 수 있는 두 가지

• 첫째, 노트북과 상관없는 다른 PC 의 질문도 다 보인다
  • 동네 전체에 묻는 방식이라서다
• 둘째, 답이 없으니 그 PC 는 계속 묻는다
  • .35 기기가 꺼져 있는 것으로 보인다
  • MAC 을 모르면 패킷을 보낼 수 없어서, 그 PC 의 통신은 시작도 못 하고 있다

이 장에서 가장 중요한 내용: 구글이 아니라 공유기의 MAC

• 노트북이 구글로 보낼 때, ARP 로 찾는 건 구글 서버의 MAC 이 아니다
• 공유기의 MAC 이다
• 5.1 의 그림에서 첫 칸의 MAC 이 “노트북 → 공유기” 였던 이유다
• MAC 은 이번 한 칸에서만 쓰는 주소다
  • 멀리 있는 기기의 MAC 은 알아도 쓸 데가 없다
• ARP 질문은 라우터를 넘어가지 못한다
  • 동네 밖으로는 물어볼 방법이 없다

장비마다 아는 범위: 바로 옆 이웃

• 각 장비는 바로 옆 이웃의 MAC 만 안다
• 공유기도 구글 MAC 은 모르고 통신사 라우터의 MAC 만 안다
• 같은 동네면 상대의 MAC 을, 다른 동네면 공유기의 MAC 을 찾는다
• 여기서 세 절이 하나로 이어진다
  • 2.4(같은 동네인지 판단)
  • 3.1(default 는 공유기)
  • 5.2(공유기 MAC 찾기)

5.3 라우터 한 칸 — 벗기고, 보고, 새로 붙인다

공유기가 패킷을 다음 칸으로 넘기는 과정

공유기가 한 칸에서 하는 일

1. 받은 MAC 라벨을 뗀다
2. IP 를 보고 다음 칸을 정한다
3. 다음 칸의 MAC 을 ARP 로 찾아 새 라벨을 붙여 내보낸다

모든 라우터의 반복

• 인터넷의 모든 라우터가 칸마다 이 일을 반복한다

바뀌는 칸과 그대로인 칸

• 그림에서 주황색이 바뀐 칸이다
• MAC 은 매번 바뀐다
• NAT 때문에 출발 IP 와 포트도 바뀐다
• 도착 IP 와 HTTP 내용은 끝까지 그대로다

라벨 종류의 변화

• 라벨 종류 자체가 바뀌기도 한다
  • 노트북에서 공유기까지는 와이파이 라벨
  • 공유기에서 통신사까지는 Ethernet 라벨
• IP 는 아래가 무엇이든 신경 쓰지 않는다
• 층끼리 서로의 속을 몰라도 된다는 게 바로 이것이다

5.4 라우터의 두 표 — 길은 크게, 이웃은 작게

라우터가 기억하는 범위

• 패킷마다 ARP 를 하지는 않는다
• 인터넷 라우터가 전 세계 MAC 을 기억하는 것도 아니다
• 내 패킷이 건너는 라우터는 열몇 개다(4.2 의 traceroute 는 9칸)
• 각 라우터 안에는 크기가 전혀 다른 표가 두 개 있다

6. VLAN and VXLAN — 나누는 것과 잇는 것

6.1 VLAN — 라벨 사이의 4바이트 스티커

VLAN 이 치는 칸막이

• VLAN 은 스위치 하나를 여러 동네로 나누는 기술이다
• 5.2 에서 본 것처럼, 같은 스위치에 꽂힌 기기들은 서로의 ARP 질문이 다 들린다
• 회사에서 직원 PC 와 서버를 섞어 두면 곤란하다 → 그래서 칸막이를 친다

방법: 4바이트 표시 끼우기

• 새 상자를 씌우는 게 아니다
• Ethernet 라벨 중간에 4바이트 표시를 끼워 넣는다

알아 둘 두 가지

• 다른 VLAN 으로 가려면 라우터를 거쳐야 한다 → 다른 동네가 되기 때문이다
• 이 표시는 보통 스위치가 붙이고 뗀다
  • PC 쪽에서는 거의 안 보인다
  • 쿠버네티스가 직접 쓰지도 않는다

6.2 VXLAN — 프레임을 UDP 봉투에 통째로

VXLAN: 떨어진 네트워크 잇기

• VXLAN 은 반대로 떨어져 있는 네트워크를 하나처럼 잇는 기술이다
• 쿠버네티스에서 중요한 쪽은 이것이다

3.4 의 문제와 봉투라는 해법

• 노드 1 의 Pod A 가 노드 2 의 Pod B 에게 보내고 싶다
• 그런데 중간 네트워크는 Pod 주소를 모른다
• 해법은 봉투다 → Pod 패킷을 통째로, 노드 주소가 적힌 봉투에 넣어 보낸다

봉투의 배달과 개봉

• 중간 네트워크는 봉투에 적힌 노드 주소만 보고 배달한다
• 받은 노드가 봉투를 뜯어 Pod B 에게 넘긴다
• 봉투를 싸고 뜯는 일은 CNI 가 노드마다 만들어 둔 가상 장치(flannel.1 같은)가 한다

봉투는 IP 와 UDP, 안쪽은 TCP

• 표준 포트는 4789 이고, Flannel 은 8472 를 쓰는 경우가 많다
• 바깥이 UDP 라고 Pod 끼리의 통신이 UDP 가 되는 건 아니다
  • 안쪽은 원래대로 TCP 다
  • 봉투 하나를 잃어버리면 안쪽 TCP 가 알아채고 다시 보낸다
• 바깥까지 TCP 로 싸면 같은 확인을 두 번 하게 된다 → 바깥은 가벼운 UDP 로 운반만 한다
• 그래서 노드에서 캡처하면, Pod 끼리 HTTP 를 주고받아도 바깥에는 UDP 로 보인다

주의: 봉투만큼 줄어드는 크기

• 봉투를 씌운 만큼(약 50바이트) 안에 담을 수 있는 크기가 줄어든다
• 그래서 CNI 는 Pod 의 MTU 를 1450 정도로 낮춰 둔다
• 이게 어긋나면 → 2.2 에서 말한 “작은 요청은 되는데 큰 응답만 멈추는” 증상이 나온다

7. Kubernetes — 새 네트워크가 아니라 조합

7.1 회사로 보는 부품 — 대표 번호와 교환원

회사 비유로 보는 네트워크 부품

• 쿠버네티스의 네트워크 부품을 회사에 비유하면 한 번에 정리된다
• 그림은 주문 Pod 가 결제 서비스에 전화를 거는 장면이다

부품별 역할

• Pod 는 직원이다
  • 내선 번호(Pod IP)가 있고 자주 바뀐다
• Service 는 부서 대표 번호다
  • 직원이 바뀌어도 그대로다
• EndpointSlice 는 대표 번호 뒤의 담당자 명단이다
• 노드 커널(kube-proxy 가 설정)은 교환원이다
  • 대표 번호로 온 전화를 명단을 보고 담당자에게 돌린다
• CoreDNS 는 전화번호부다
• CNI 는 내선 번호를 주고 건물 사이 선을 까는 공사 업체다

하나만 기억할 것: yaml 은 주문서

• Service 를 만드는 건 “대표 번호를 만들어 달라” 는 신청서를 내는 것이다
• 실제로 전화를 돌리는 건 각 노드의 리눅스 커널이다
• 3.3 에서 BGP 가 이정표를 세우고 패킷은 이정표만 보고 지나간 것과 같은 구조다

7.2 Service IP — 어떤 기기에도 없는 주소

Service IP 의 특이한 점: 붙어 있는 기기가 없다

• Service IP 는 어떤 기기에도 붙어 있지 않다
• 동작 방식: 2.3 의 NAT 를 반대 방향으로 쓴다
  • 공유기는 나가는 패킷의 출발 주소를 바꿨다
  • 노드 커널은 Pod 가 보낸 패킷의 도착 주소를, Service IP 에서 실제 Pod IP 로 바꾼다
• 받을 기기가 없으니 Service IP 로 ping 을 하면 보통 답이 없다

대표 번호가 필요한 이유: 자주 바뀌는 Pod

• Pod 가 죽고 다시 뜨면 IP 도 바뀐다
• 그래서 바뀌지 않는 번호를 앞에 둔다
• 뒤의 명단(EndpointSlice)만 쿠버네티스가 자동으로 고친다

클러스터 안의 번호와 바깥 길

• Service IP 는 클러스터 안에서 쓰는 번호다
• 바깥과 통하는 길은 따로 있다

7.3 요청 하나 — 앞의 장들이 일곱 단계에

요청 한 번의 일곱 단계

• Pod 하나가 my-svc 에 요청할 때 일어나는 일이다
• 오른쪽이 앞에서 본 절이다

일곱 단계에 담긴 1장

• 1장에서 배운 거의 모든 것이 이 일곱 단계에 들어 있다
• 책이 1장을 네트워크 기초에 통째로 쓴 이유다

8. Discussion

8.1 층은 디버깅 도구다

남는 것: 고장 난 층을 묻는 질문

• 1장을 다 읽고 남는 건 일곱 층의 이름이 아니라 질문 하나다: 지금 몇 층이 고장 났나
• 두 편에서 직접 본 장면들을 그 질문으로 다시 묶었다

핵심 메시지

쿠버네티스는 새로운 네트워크를 만들지 않는다. Service 는 NAT 이고, Pod 사이의 길은 라우팅이나 봉투이고, 그 아래는 여전히 TCP 와 ARP 다. 추상화는 평소 일을 덜어 주지만, 장애의 원인까지 감춰 주지는 않는다. curl 한 번을 끝까지 따라가 본 경험이 yaml 몇 장을 더 외우는 것보다 오래 쓸모 있는 이유다.

9. References