쿠버네티스 네트워크

최근 업데이트일 2024-11-06

참고자료: Kubernetes 네트워크 이해하기 (1) : 컨테이너 네트워크부터 CNI까지

컨테이너 격리와 네트워크에 이어서 전체적인 쿠버네티스 네트워크 구조를 살펴보자.

1. 쿠버네티스 네트워크 구조

Kubernetes는 기본적으로 모든 Pod 간 NAT 없는 통신을 보장하며, 노드 간에도 직접 통신이 가능해야 하며 아래 조건을 전제로 한다.

1. Pod는 클러스터 전체에서 고유한 IP를 가짐.
2. 모든 Pod는 NAT 없이 통신 가능.
3. 노드의 시스템 데몬(e.g. kubelet)은 해당 노드의 모든 Pod와 통신 가능.
4. Pod 내부에서 보는 IP와 외부에서 접근하는 IP는 동일해야 함.

2. Network Namespace & veth

Kubernetes에서 Pod가 생성될 때, 각 컨테이너(Pod)는 고유한 Network Namespace안에 존재한다.

• 컨테이너 격리와 네트워크에서 살펴본 내용을 정리해보자.
  • 호스트 네트워크 네임스페이스와 Pod 네트워크를 연결하기 위해 veth 인터페이스 쌍이 생성된다.
  • 하나는 Pod 내부에, 다른 하나는 호스트 네임스페이스의 bridge에 연결된다.
• 결과적으로, kubelet이 Pod를 생성할 때 CNI 플러그인을 통해 veth pair를 만들어 Pod ↔ Host 간 네트워크 터널을 구성한다.

즉, veth는 Pod 간 통신의 최소 단위이며, Network Namespace 격리는 보안 및 멀티테넌시 측면에서 핵심 요소이다.

3. Bridge

Kubernetes는 단일 노드 내부에서의 Pod 간 통신을 위해 CNI 플러그인을 통해 각 노드에 bridge 네트워크를 생성하고, Pod는 veth 인터페이스를 통해 이 bridge에 연결된다.

• 이 방식은 Docker의 기본 네트워크 구성과 유사하지만, Kubernetes는 직접 Docker bridge를 사용하는 것은 아니며, CNI를 통해 독립적으로 구성된다.
• 예를 들어, Flannel이나 Weave 같은 CNI 플러그인은 내부적으로 bridge를 구성하고, 여기에 Pod의 veth를 연결한다.
• 컨테이너 간 통신은 이 bridge를 통해 L2 계층으로 이루어진다.

즉, CNI 플러그인 설정에 따라 각 노드에 bridge가 생성되며, Pod는 해당 bridge에 연결됨으로써 같은 노드 내에서 직접 통신한다.

4. Overlay Network

Kubernetes 클러스터는 여러 노드로 구성되어 있고, 기본적으로 모든 Pod는 다른 노드의 Pod와도 NAT 없이 통신이 가능해야 하고, 기본적인 네트워크는 노드끼리 단순한 IP routing만 하고, 각 Node 안의 Pod 네트워크는 외부에서 직접 도달할 수 없기 때문에 Overlay Network를 이용한다.

• 서로 다른 노드 간에는 물리적으로 L2 연결이 없다.
• 실제 물리 네트워크 위에 소프트웨어적으로 가상 네트워크를 하나 더 덧씌우는 방식으로 이 가상 네트워크에서는 모든 Pod가 서로 직접 연결된 것처럼 동작한다.
• 네트워크 인터페이스가 실제로 존재하는 것처럼 속이지만, 내부적으로는 패킷을 터널링(tunneling) 해서 전달한다.
  • 이를 위한 대표적인 방식이 VxLAN 기반 터널링이다.
• [Pod] --veth--> [Bridge] --[Overlay(VxLAN)]--> [Bridge] <--veth-- [Pod]

Flannel, Calico, Weave 같은 CNI 플러그인들은 Overlay 기술을 사용하여 노드 간 Pod 통신을 가능하게 한다.

VxLAN

• VxLAN은 Overlay Network 구현을 위한 대표 기술로, L2 Frame을 UDP로 캡슐화하여 다른 노드로 전달한다.
• L2 프레임(이더넷 프레임)은 L2 네트워크를 타야하지만 이를 UDP로 캡슐화해서 L3 네트워크(인터넷)를 통해 보낸다.
  • TCP 대신 가볍고 단순한 UDP를 사용한다.
  • 실제로는 L3 기반의 UDP 전송이지만, 내부적으로는 각 Pod가 마치 같은 L2 스위치에 물려 있는 것처럼 보여준다.
• e.g. Flannel은 VxLAN 백엔드를 사용하여 Pod-to-Pod 통신을 설정할 수 있다.
• 클러스터 전체에서 IP 충돌 없이 통신이 가능해진다.

5. VLAN (Virtual LAN)

Kubernetes에서 VLAN은 자주 사용되지는 않지만, 특정 네트워크 분리 요구사항이 있는 환경(e.g. on-premise 데이터센터)에서는 사용된다.

• VLAN은 하나의 물리적인 네트워크를 논리적으로 여러 개의 네트워크로 분리하는 기술이다.
  • 서로 다른 VLAN에 속한 장비는 기본적으로 통신이 불가능하며, 네트워크 격리 효과가 있다.
  • 예를 들어 VLAN 100은 내부 서비스용, VLAN 200은 외부 트래픽용 등 보안 도메인 분리에 활용된다.
  • VLAN은 이더넷 프레임에 802.1Q 태그를 삽입하는 방식으로 동작하며, 스위치나 라우터 같은 네트워크 장비가 이를 해석한다.

즉, VLAN은 같은 물리 네트워크 상에서 논리적으로 네트워크를 나누는 격리 메커니즘이다.

• 주로 Bare-metal 환경에서 Multus CNI와 함께 사용해, Pod마다 다른 VLAN에 붙일 때 사용된다.
• 다만, VLAN 기반 네트워크 분리는 일반 클라우드 환경에서는 사용이 어렵고, Bare-metal 기반의 직접 네트워크 구성이 가능한 환경에서만 적용할 수 있다.
• 하나의 Pod에 다중 네트워크 인터페이스(multus)를 연결하고, 각 인터페이스에 VLAN 할당이 가능하다.

이러한 공통된 절차의 컨테이너의 네트워킹에 대한 표준을 만들어서 하나의 프로그램으로 통합할 필요가 생겼다.

6. CNI (Container Network Interface)

Kubernetes에서 Pod의 네트워크 환경을 구성·제거하는 Spec 인터페이스

• Pod의 네트워크 인터페이스를 설정/해제하는 작업을 Container Runtime 대신 처리하기 위한 Spec이며, 다양한 플러그인 구현체를 통해 사용된다.
• 이 Spec은 다음과 같은 역할을 수행하는 컴포넌트를 정의한다:
  • Network Plugin: Pod를 가상 네트워크에 연결하거나 분리하는 역할.
  • IPAM (IP Address Management): Pod에 할당할 IP 주소를 관리. Pod 생성 시 IP 할당, 삭제 시 회수.
• 대표적인 CNI 플러그인: Flannel, Calico, WeaveNet, Cilium, AWS VPC CNI
• 단일 호스트에서 컨테이너 간 간단한 통신을 하려면 Bridge 모드를 사용하면 된다.

CNI 공식 홈페이지

CNI는 Runtime(예: kubelet)이 컨테이너 생성/삭제 시 네트워크를 어떻게 설정/해제해야 하는지를 정의한다.

• 네트워크 인터페이스를 구성하기 위해서 어떻게 플러그인이 개발되어야 하는지와 같은 상세한 내용과 라이브러리들로 구성되어 있다.
• CNI 동작 흐름
  1. Container Runtime은 컨테이너의 Network Namespace를 생성한다.
  2. 어떤 네트워크에 연결할지 식별한다.
  3. ADD 이벤트 시, 해당 네트워크 플러그인(예: bridge)을 호출해 Pod에 네트워크를 연결한다.
  4. DEL 이벤트 시, 플러그인을 통해 네트워크 연결을 해제한다.
  5. 네트워크 구성은 JSON 포맷으로 정의된다.
  6. 플러그인은 IPAM을 통해 IP를 할당하고, 결과를 특정 포맷으로 반환해야 한다.

• CNI는 BRIDGE, VLAN, IPVLAN, MACVLAN, WINDOWS, DHCP, host-local 등의 플러그인들이 준비되어 있다.
  • 기본 CNI 플러그인들은 간단한 네트워킹 요구사항을 충족시키는 데 충분하지만, 서드파티 플러그인은 추가적인 기능, 확장성, 보안, 그리고 복잡한 네트워크 환경에 대한 지원을 제공할 수 있다.
• Docker는 Docker 자체의 표준인 Container Network Model(CNM)을 구현하여 CNI로 구현할 수 없다.

CNI 플러그인에 대한 설정은 클러스터 내 각 노드의 kubelet.service에서 정의한다.

• --cni-bin-dir=/opt/cni/bin: CNI 플러그인 실행 파일이 위치하는 디렉토리 경로를 지정하는 옵션
• --cni-conf-dir=/etc/cni/net.d: CNI와 관련한 설정 파일들이 위치하며, bridge 네트워크 구성 정보도 여기에 포함된다.
  • type: CNI 플러그인은 다양한 타입으로 설정할 수 있다.
    • bridge: 단일 호스트에서 컨테이너 간 간단한 통신용 (기본값)
    • macvlan: 물리 네트워크와 직접 연결되는 고성능 통신을 위해 사용
    • ipvlan:복잡한 네트워크 격리 없이 IP 주소만 추가하는 경량 방식
  • isGateway: bridge 네트워크 인터페이스가 gateway로써 사용되기 위한 IP 주소 필요 여부를 정의한다.
  • ipMasq: IP Masquerade 기능에 대한 설정으로, 해당 네트워크로부터 외부로 나갈 때 IP Masquerade 기능을 사용할지 여부를 정의한다.
    • IP Masquerade: 내부 IP를 하나의 공인 IP로 변환하여 외부에 나가는 NAT 방식 중 하나
  • ipam: 파드에 할당될 서브넷, IP 주소 등 IPAM(IP Address Management)에 관한 설정

각 CNI 플러그인에 대해서는 추후 다뤄볼 것이다.