많은 사람이 Kubernetes 네트워크를 배우기 시작하자마자 다음을 접하게 됩니다:
- Pod
- Service
- Ingress
- CNI
- Flannel
- Calico
하지만 배워갈수록 오히려 더 혼란스러워집니다.
핵심 문제는 이렇습니다:
Kubernetes 네트워크는 독립적인 체계가 아니라 Linux 네트워크 위에 구축된 추상화 계층입니다.
Linux 네트워크를 이해하지 않으면 Pod, Service, VXLAN 같은 개념이 모두 블랙박스가 됩니다.
1. 네트워크 세계의 세 가지 핵심 개념
전체 네트워크는 세 가지로 추상화할 수 있습니다:
设备
地址
转发
구체적으로는 다음과 같습니다:
设备：
网卡
交换机
路由器
地址：
MAC
IP
转发：
交换
路由
NAT
2. MAC과 IP
MAC 주소
MAC은 2계층 주소입니다.
00:11:22:33:44:55
같은 LAN에서 장치를 식별하는 데 사용됩니다.
IP 주소
IP는 3계층 주소입니다.
192.168.1.10
10.244.1.2
8.8.8.8
서로 다른 네트워크에서 장치를 식별하는 데 사용됩니다.
3. 교환기, ARP, 라우터
교환기는 2계층에서 동작하며 MAC 주소만 확인하고 IP, TCP, HTTP는 보지 않습니다.
ARP의 역할은 다음과 같습니다:
IP -> MAC
라우터는 3계층에서 동작합니다:
查看目标 IP
↓
查路由表
↓
决定下一跳
라우팅 테이블 예시:
ip route
192.168.1.0/24 dev eth0
default via 192.168.1.1
이 의미는 다음과 같습니다:
同网段直接发送
其他流量交给默认网关
4. NAT
사설 주소는 공중망에서 직접 라우팅할 수 없습니다:
192.168.x.x
172.16.x.x
10.x.x.x
그래서 라우터는 SNAT을 수행합니다:
SRC 192.168.1.10
↓
SRC 公网 IP
또한 conntrack으로 연결 매핑을 기록하여 응답 패킷이 돌아올 때 연결을 복구합니다.
5. Linux Network Namespace
Namespace는 Linux의 격리 메커니즘입니다.
Network Namespace는 다음과 같은 전체 네트워크 스택을 격리합니다:
网卡
IP
路由表
ARP 表
iptables
端口空间
따라서 컨테이너는 가상 머신이 아니라 다음 요소로 구성됩니다:
普通 Linux 进程
+
Namespace 隔离
+
Cgroups 限制
+
RootFS 文件系统
6. veth 쌍
Namespace를 서로 연결하기 위해 Linux는 veth pair를 제공합니다.
vethA <====> vethB
가상 케이블과 같은 역할을 합니다:
从 vethA 发出的包，会从 vethB 出来
从 vethB 发出的包，会从 vethA 出来
7. Linux 브리지
브리지는 소프트웨어 스위치입니다.
ContainerA
|
Bridge
|
ContainerB
물리 스위치와 마찬가지로 다음 작업을 수행합니다:
学习 MAC
查 MAC 表
转发数据帧
8. Docker 네트워크
Docker의 기본 네트워크 구조는 다음과 같습니다:
Container
eth0
│
veth
│
docker0
│
Host
이 중 docker0은 Linux 브리지이며, Docker가 IP 주소도 설정합니다:
docker0 = 172.17.0.1
따라서 docker0은 스위치인 동시에 컨테이너의 기본 게이트웨이입니다.
Docker가 IPAM을 직접 관리합니다:
172.17.0.0/16
컨테이너 IP는 일반적으로 Docker가 할당합니다:
172.17.0.2
172.17.0.3
172.17.0.4
9. Pod란 무엇인가
Pod는 컨테이너가 아닙니다.
하나의 Pod에는 여러 컨테이너가 있을 수 있습니다:
Pod
├── app
└── sidecar
실제로 네트워크 Namespace를 보유하는 것은 pause container입니다.
pause container
└── Network Namespace
app
└── 加入 pause 的 Network Namespace
sidecar
└── 加入 pause 的 Network Namespace
따라서 같은 Pod에 속한 여러 컨테이너는 다음을 공유합니다:
IP
localhost
端口空间
10. Kubernetes 단일 노드 네트워크
많은 CNI는 노드에 docker0과 비슷한 브리지를 생성합니다. 예를 들면:
cni0
구조는 다음과 같습니다:
PodA
|
veth
|
cni0
|
veth
|
PodB
같은 노드의 Pod끼리 통신할 때:
PodA ARP 查询 PodB MAC
↓
cni0 广播
↓
PodB 回复
↓
cni0 根据 MAC 表转发
이 과정은 본질적으로 2계층 교환입니다.
11. CNI란 무엇인가
Kubernetes 자체는 네트워크를 직접 구현하지 않습니다.
Pod 네트워크는 CNI 플러그인을 통해 처리합니다.
흔히 사용하는 CNI는 다음과 같습니다:
Flannel
Calico
Cilium
CNI는 다음 작업을 담당합니다:
创建 veth
配置 IP
配置路由
接入 Bridge 或其他数据平面
维护跨节点通信
Pod IP는 일반적으로 Kubernetes나 Linux가 자동 할당하는 것이 아니라 CNI의 IPAM 모듈이 할당합니다.
12. 노드 간 Pod 통신
다음과 같이 가정해 봅시다:
Node1
PodA = 10.244.1.2
Node2
PodB = 10.244.2.2
PodA가 PodB에 접근하면:
10.244.1.2 -> 10.244.2.2
문제는 다음과 같습니다:
Node1 怎么知道 10.244.2.0/24 在 Node2？
이것이 CNI가 해결해야 하는 문제입니다.
13. VXLAN
VXLAN은 다음과 같습니다:
L2 Overlay over L3
그 의미는 다음과 같습니다:
把二层网络封装到三层 IP 网络里面
원본 Pod 패킷은 다음과 같습니다:
SRC 10.244.1.2
DST 10.244.2.2
VXLAN으로 캡슐화하면 다음과 같습니다:
Outer IP:
SRC Node1IP
DST Node2IP
UDP
VXLAN Header
Inner IP:
SRC 10.244.1.2
DST 10.244.2.2
패킷 구조는 다음과 같습니다:
Outer Ethernet
Outer IP
UDP
VXLAN
Inner Ethernet
Inner IP
TCP
HTTP
중간의 물리 네트워크는 다음 정보만 볼 수 있습니다:
Node1IP -> Node2IP
Node2는 패킷을 받은 뒤 VXLAN을 디캡슐화하고, 원래 Pod 패킷을 PodB로 전달합니다.
14. flannel.1이란 무엇인가
flannel.1은 프로세스가 아닙니다.
이것은 Linux VXLAN 네트워크 장치입니다.
다음 장치들과 비슷합니다:
eth0
docker0
cni0
vethxxx
라우팅 테이블에는 다음과 같이 표시됩니다:
10.244.2.0/24 dev flannel.1
이 의미는 다음과 같습니다:
去 10.244.2.0/24 的流量
交给 flannel.1 这个 VXLAN 设备处理
이후 Linux 커널이 VXLAN 캡슐화를 담당합니다.
flanneld가 실제 프로세스이며, 다음 작업을 담당합니다:
创建 flannel.1
写路由表
维护 Node 和 PodCIDR 的映射
15. Service의 본질
Service는 안정적인 액세스 엔드포인트를 제공합니다.
예를 들면:
Service IP = 10.96.0.10
하지만 이 IP는 일반적으로 실제 네트워크 인터페이스에 설정된 IP가 아닙니다.
Service의 본질은 다음과 같습니다:
虚拟 IP
+
iptables / IPVS 转发规则
16. kube-proxy
kube-proxy는 다음을 감시합니다:
Service
Endpoint / EndpointSlice
그런 다음 전달 규칙을 생성합니다.
예를 들면:
10.96.0.10:8080
↓ DNAT
10.244.1.2:8080
따라서 Service에 접속할 때 실제로는 다음 과정을 거칩니다:
访问 Service IP
↓
iptables / IPVS 命中规则
↓
DNAT 到某个后端 Pod IP
↓
通过 CNI 网络转发到目标 Pod
17. CoreDNS
Pod 내부에서 서비스 이름으로 접속하면:
curl user-service
조회 과정은 다음과 같습니다:
user-service
↓
CoreDNS
↓
Service ClusterIP
↓
kube-proxy
↓
Pod IP
18. Ingress
Ingress는 규칙일 뿐, 실제 게이트웨이 프로세스가 아닙니다.
실제로 트래픽을 처리하는 것은 Ingress Controller입니다. 예를 들면:
Nginx Ingress Controller
Traefik
APISIX
Kong
외부 요청의 전달 경로는 다음과 같습니다:
Browser
↓
LoadBalancer / NodePort
↓
Ingress Controller
↓
Service
↓
Pod
Ingress Controller는 일반적으로 7계층 역방향 프록시이며, 다음 정보를 파싱합니다:
Host
Path
TLS
HTTP Header
19. 전체 흐름 요약
Linux 네트워크의 기초:
MAC
↓
ARP
↓
交换机
↓
路由器
↓
路由表
↓
NAT
컨테이너 네트워크의 기초:
Namespace
↓
veth
↓
Bridge
↓
IPAM
↓
Docker 网络
Kubernetes 네트워크:
Pod
↓
CNI
↓
PodCIDR
↓
cni0 / route / eBPF
↓
VXLAN / BGP
↓
Service
↓
CoreDNS
↓
Ingress
20. 최종 결론
Kubernetes 네트워크는 갑자기 등장한 새로운 체계가 아닙니다.
그 본질은 다음과 같습니다:
Linux 网络能力
+
CNI 自动化
+
Kubernetes 声明式编排
더 구체적으로 말하면:
Kubernetes 网络
=
Namespace
+
veth
+
Bridge
+
Route
+
NAT
+
iptables / IPVS
+
VXLAN / BGP / eBPF
+
CNI
Kubernetes 네트워크를 이해하는 올바른 방법은 Pod, Service, Ingress를 먼저 외우는 것이 아니라, 먼저 다음을 이해하는 것입니다: