[k8s] 42. Networking

Networking - Pod / Service Network (Calico), Pause Container

Networking

Pod Network

• 파드가 생성되면 파드 네트워크 범위내에서 고유 아이피를 가지는 인터페이스가 생성됨
• 이 인터페이스를 통해 여러 컨테이너간 통신
• 파드끼리의 통신은 Network Plugin으로 통신(쿠버네티스 기본 plugin은 kubnet)

CNI

• Container Network Interface
• 오픈소스 네트워크 플러그인들이 있음

Service Network

• Node2의 파드에 서비스를 붙이면 Master의 kube-dns에 서비스의 이름과 아이피에 대한 도메인이 등록됨
• api-server가 워커 노드들마다 파드 형태로 띄워진 kube-proxy에 서비스의 아이피가 어느 파드의 아이피와 연결되어있는지 보여줌

NAT

• 서비스 아이피를 파드 아이피로 바꾸는 기능
• kube-proxy가 iptables, IPVS를 어떻게 이용하는가에 따라 세 가지의 Proxy Mode 존재

파드가 서비스 이름으로 호출할 때의 과정

1. kube-dns로 가서 서비스의 아이피 파악
2. 서비스 아이피로 kube-proxy에서 서비스와 연결된 파드 아이피 확인
3. 트래픽은 네트워크 플러그인을 통해 해당 파드로 감

서비스를 삭제하면

1. api-server가 이를 감지
2. kube-proxy에 설정을 지우라고 함

1. Pod Network (with Calico)

• 파드의 네트워크를 담당하는 Pause Container와 클러스터의 네트워크를 담당하는 Network Plugin으로 나뉨

Pause Container

• 파드를 만들면 Pause Container가 생김
• Pause Container에는 인터페이스가 있고 아이피도 있음
• 쿠버네티스는 Pause Container의 네트워크 네임스페이스를 파드 내의 컨테이너가 모두 쓸 수 있도록 구성해줌
• 컨테이너간의 구분은 포트를 통해 할 수 있게 됨

Host Network Namespace

• Worker Node안에 존재
• Host Network Namespace에는 호스트 아이피 인터페이스가 있음
• Pause Container가 생기면 Host Network Namespace에 가상 인터페이스가 생성돼 Pause Container와 연결됨
• 다른 파드들이 생성될 때마다 계속 가상 인터페이스가 생성되고 그 파드의 Pause Container가 연결됨
• Worker Node에서 20.111.156.66:8000 아이피와 포트를 날리면 calid12로 가고 Pod A와 연결

이처럼 외부에서 파드로 들어오는 트래픽을 받는 것과 특정 컨테이너로 트래픽을 전달하는 건 Pause Container가 리눅스에 Network Namespace를 별도로 생성해서 가상의 인터페이스를 만들고 그것을 관련 컨테이너들에게 공유하기 때문에 가능하다.

Network Plugin

• Pause Container의 구조에 이어서, Network Plugin에 Bridge와 Router가 있음

Kubenet

Bridge

• Bridge 네트워크 대역은 파드 네트워크 대역을 참고해서 낮게 설정
• Bridge 내에서 생성되는 파드 아이피는 Bridge의 CIDR 범위내에서 만들어짐 --> 255개(Kubenet이 안 좋은 이유)

Router

• NAT를 통해 기능 제공
• 아이피가 파드 아이피 대역이면 해당 트래픽을 Bridge로 내려주고 그외는 위(eth0)로 올려줌

calico

• calico의 호스트 네트워크에 생성된 가상 인터페이스는 Router에 바로 연결되어 있음
• 두 파드간의 통신은 Router가 담당
• Router의 CIDR은 kubenet보다 더 큰 범위를 가져서 한 노드에서 파드에게 더 많은 아이피를 부여할 수 있음
• firewall 제공
• 라우터 위에는 Overlay 네트워크를 제공함
• Overlay 네트워크 제공 방식으로는 IPIP, VXLAN이 있음
• Overlay 네트워크가 하는 일은 한 노드 위의 파드가 다른 노드 위의 파드와 통신이 가능하게 해줌
  • 그림 중 맨 위 검정색 막대기 해당

calico에서 파드 통신 과정

1. Pod D에서 Pod B로 트래픽을 날린다고 하면
2. Pod D가 Pod B 아이피 20.111.156.7 호출
3. 20.111.156.7은 Router의 CIDR 범위에 없기 때문에 트래픽은 Overlay로 올라감
4. calico는 이 아이피가 어느 노드에 있는지 알고 있어, Overlay에서 아이피를 192.168.59.22로 변경하고 실제 파드의 아이피 20.111.156.7은 encapsulation
5. 해당 노드로 흘러간 트래픽은 그 노드의 Overlay 층에서 decapsulation되어 원래의 파드 아이피로 변환
6. 이 아이피 대역이 있는 라우터로 트래픽이 전해지고, 라우터에서 해당 아이피에 해당하는 가상 인터페이스를 지나 파드로 전달

2. Service Network (with Calico) (feat. 어려움)

Proxy Mode

• Proxy Mode는 세 가지가 있음
• Userspace Mode와 Iptables/IPVS Mode 두 가지로 나눠서 살펴보겠음

전제 상황

1. 파드를 만들고 서비스를 붙임
2. 정상적인 상황이면 서비스에 앤드포인트도 있음
3. 서비스의 아이피는 Service Network CIDR 범위 내에서 생성됨
4. api-server는 앤드포인트를 감시하다가 생성된 것을 발견하면
5. 모든 노드의 kube-proxy에 서비스의 아이피는 파드 아이피에 포워딩 된다는 정보를 줌

Userspace Mode

• 리눅스 Worker Node에 기본적으로 설치되어 있는 iptables
• iptables에 Service CIDR로 들어오는 트래픽은 모두 kube-proxy에 주도록 되어있음
• 파드에서 서비스 아이피를 호출할 경우 iptables를 거쳐 kube-proxy에 가게됨
• kube-proxy는 자신이 갖고 있는 매핑정보를 갖고 트래픽을 파드 아이피로 바꿔줌
• 파드 아이피로 바뀐 트래픽은 Pod Network Area로 통신이 돼서 해당 파드로 트래픽 전달
• 단점: 서비스를 향한 모든 트래픽이 kube-proxy를 지나야 돼서 부담이 큼 --> 그래서 잘 안 쓰임

Iptables/IPVS Mode

• kube-proxy가 아이피 매핑정보를 iptables에 직접 등록
• 파드에서 보내는 서비스 아이피는 iptables에서 직접 파드 ip로 변환 --> 쿠버네티스 기본 모드
• 리눅스에서는 IPVS를 제공하는데 iptables와 비슷한 역할을 하는데, 부하가 클 수록 iptables보다 성능이 좋다고 함

Service Type - calico 구조

• 서비스를 만들 때 CusterIP, NodePort 타입에 따라 트래픽 흐름이 다름
• Pod D에서 Pod B로 아이피 날리는 상황에 대해 각각 어떻게 다른지 설명할 예정
• 라우터 부분에 서비스 아이피를 파드 아이피로 변환시켜주는 NAT 기능하는게 있음

ClusterIP 타입

1. 파드 B에 클러스터 아이피 타입의 서비스 연결
2. 파드 D에서 서비스 아이피 트래픽을 NAT으로 보내면 NAT에서 서비스와 매칭되는 파드 아이피 변환
3. Overlay에서 아이피가 캡슐화되고 파드 아이피와 통신

NodePort 타입

1. 모든 노드에 있는 kube-proxy가 자신의 노드에 30000번대의 포트를 열어둠
2. 외부에서 HostIP의 노드포트로 트래픽이 들어오면 iptables에서 노드 아이피를 서비스 아이피로 변환한 후 이 트래픽을 calico 네트워크 플러그인의 NAT으로 보냄
3. NAT 기능을 통해 서비스와 매핑되는 파드 아이피로 변환되어 파드 네트워크 영역으로 넘어감

출처

인프런 - 대세는 쿠버네티스