쿠버네티스 네트워킹을 위한 Antrea 배포

개요

Antrea는 Kubernetes 중심적이고 Kubernetes-native로 설계되었다. Kubernetes 클러스터의 네트워킹 및 보안에 중점을 두고 최적화되었다. 이 솔루션의 구현은 가능한 한 쿠버네티스와 쿠버네티스 고유의 솔루션을 활용한다.

Antrea는 OVS(Open vSwitch)를 네트워킹 데이터 평면으로 활용합니다. Open vSwitch는 Linux 및 윈도우즈를 지원하는 고성능 프로그래밍 가능한 가상 스위치다. Antrea는 Open vSwitch를 사용하여 Kubernetes 네트워크 정책을 고성능 및 효율적인 방식으로 구현할 수 있습니다. Open vSwitch의 프로그래밍 가능한 특성 덕분에 Antrea는 Open vSwitch를 기반으로 광범위한 네트워킹 및 보안 기능 및 서비스를 구현할 수 있다.

특히 Antrea Agent에 관한 이 백서의 일부 정보는 Linux 노드에서 Antrea를 실행하는 것으로 한정된다. Windows 노드에서 Antrea를 실행하는 방법에 대한 자세한 내용은 windows-design.md을 참조한다.

구성 요소

Kubernetes 클러스터에서 Antrea는 Antrea 컨트롤러를 실행하는 배포와 모든 노드에서 각각 Antrea 에이전트와 OVS 데몬을 실행하는 두 개의 컨테이너를 포함하는 데몬 세트를 생성한다. DaemonSet에는 설치되는 init 컨테이너도 포함된다. 노드의 컨테이너 네트워크 인터페이스(CNI) 플러그인, Antrea-cni는 OVS 커널 모듈이 로드되고 포트 맵 CNI 플러그인과 체인으로 연결되도록 보장한다. Antrea Controller, Agent, OVS 데몬 및 antrea-cni가 단일 Docker 이미지에 포함된다. Antrea에는 antctl이라는 명령줄 도구와 Octant UI 플러그인도 있다.

Antrea Controller

앤트레아 컨트롤러는 Kubernetes API에서 네트워크 정책, 포드 및 네임스페이스 리소스를 감시하고 네트워크 정책을 계산하고 계산된 정책을 모든 Antrea 에이전트에 배포한다. 현재 Antrea 컨트롤러는 단일 복제본만 지원하며 주로 네트워크 정책 구현을 위해 존재한다. 네트워크 정책 지원이 아닌 포드 간의 연결에만 관심이 있는 경우 Antrea 컨트롤러를 전혀 배포하지 않도록 선택할 수 있다.
그러나 향후 Antrea는 Antrea 컨트롤러가 필요한 더 많은 기능을 지원할 수 있다.

Antrea Controller는 쿠버네티스 apiserver 라이브러리를 활용하여 Antrea Agent에 통신 채널을 구현한다. 각 Antrea 에이전트는 컨트롤러 API 서버에 연결하여 계산된 네트워크 정책 개체를 감시한다. 또한 컨트롤러는 동일한 HTTP 끝점에 antctl용 REST API를 표시한다. 컨트롤러 API 서버 구현에 대한 자세한 내용은 컨트롤러 API 서버 섹션을 참조한다.

컨트롤러 API 서버

Antrea Controller는 자체 API 서버를 구현하기 위해 Kubernetes piserver 라이브러리를 활용한다. API 서버 구현은 계산된 네트워크 정책을 에이전트에 게시하기 위해 사용자 정의되고 최적화된다.

• API 서버는 모든 상태를 메모리 내 캐시에 보관하며 데이터를 보존하는 데 데이터스토어가 필요 없다.
• 네트워크 정책을 로컬로 적용해야 하는 노드에만 네트워크 정책 개체를 보낸다. 네트워크 정책이 노드의 하나 이상의 포드에 적용되는 경우에만 노드가 네트워크 정책을 수신한다.
• NetworkPolicy 개체에 대한 증분 업데이트를 에이전트에 보낼 수 있다.
• 컨트롤러와 에이전트 사이의 메시지는 Protobuf 형식을 사용하여 직렬화되므로 크기가 줄어들고 효율성이 향상된다.

Antrea Controller API 서버는 또한 다음과 같은 용도로 Kubernetes 서비스를 활용한다.
• 서비스 발견
• 인증 및 승인

Controller API 엔드포인트는 쿠버네티스 ClusterIP 유형 서비스로 노출된다. Antrea 에이전트가 서비스 환경 변수에서 서비스의 ClusterIP를 가져오고, ClusterIP를 사용해서 Controller API 서버에 연결한다. 컨트롤러 API 서버는 인증 및 인증을 Kubernetes API로 위임합니다. Antrea 에이전트는 Kubernetes Service Account 토큰을 사용하여 컨트롤러에 인증하고 컨트롤러 API 서버는 서비스 계정이 Kubernetes API를 사용하여 API 요청에 대해 인증되었는지 확인한다.

Antrea 컨트롤러는 또한 API 서버 HTTP 끝점을 사용하여 antctl용 REST API를 표시한다.

쿠버네티스 API 집계를 활용하여 쿠버네티스 API를 통해 antctl이 Antrea Controller API에 도달할 수 있다. antctl은 쿠버네티스 API에 연결하여 인증하며, 이 API 요청은 Antrea Controller에 프록시된다. 이러한 방식으로, antctl은 Kubernetes API에 도달할 수 있는 모든 머신에서 실행될 수 있으며, Kubecconfig 파일(kubecconfig 파일)을 활용하여 Kubernetes API와 인증 정보를 발견할 수 있다. antctl 섹션을 참조한다.

앤트레아 에이전트

Antrea 에이전트는 OVS 브리지 및 포드 인터페이스를 관리하고 모든 Kubernetes 노드에서 OVS와 포드 네트워킹을 구현한다.

Antrea 에이전트는 gRPC 서비스(CNI 서비스)를 노출하며, 이 서비스는 CNI 작업을 수행하기 위해 antrea-cni 바이너리에 의해 호출된다. 노드에 생성될 각 새 포드에 대해 에이전트에서는 antrea-cni에서 CNI ADD 호출을 받은 후 포드의 네트워크 인터페이스를 생성하고, IP 주소를 할당하고, OVS 브리지에 인터페이스를 연결하고 필요한 흐름을 OVS에 설치한다. OVS 흐름에 대한 자세한 내용은 OVS 파이프라인 문서를 참조한다.

Antrea 에이전트에는 두 개의 Kubernetes 컨트롤러가 포함되어 있다.

• 노드 컨트롤러는 Kubernetes API 서버에서 새 노드를 감시하고, 각 원격 노드에 대한 OVS(Generve/VXLAN/GRE/STT) 터널을 생성한다.
• NetworkPolicy 컨트롤러는 Antrea 컨트롤러 API에서 계산된 네트워크 정책을 감시하고 OVS 흐름을 설치하여 로컬 포드에 대한 네트워크 정책을 구현한다.

또한 Antrea 에이전트는 antctl의 로컬 HTTP 끝점에 REST API를 표시합니다.

OVS 데몬

ovsds-server와 ovs-vswitched의 두 OVS 데몬은 Antrea 에이전트 데몬 세트의 별도의 컨테이너에서 실행된다.

antrea-cni

Antrea-cni는 Antrea의 CNI 플러그인 바이너리다. 각 CNI 명령에 대해 큐블릿으로 실행됩니다. 각 CNI 명령에 대해 RPC를 Antrea 에이전트에 발급하는 간단한 gRPC 클라이언트다. 에이전트가 실제 작업(포드에 대한 네트워킹 설정)을 수행하고 결과 또는 오류를 antrea-cni로 반환한다.

antctl

antctl은 Antrea의 코맨드라인 도구다. 현재 Antrea 컨트롤러 및 Antrea 에이전트의 기본 런타임 정보를 디버깅 목적으로 표시할 수 있다.

컨트롤러에 액세스할 때 antctl은 컨트롤러 API를 호출하여 필요한 정보를 쿼리한다. 앞에서 설명한 것처럼 antctl은 Kubernetes API를 통해 컨트롤러 API에 도달할 수 있으며, Kubernetes API가 API 요청을 인증, 승인 및 프록시로 컨트롤러에 전송할 수 있다. antctl은 또한 kubectl 플러그인으로 kubectl을 통해 실행될 수 있다.

에이전트에 액세스할 때 antctl은 에이전트의 로컬 REST 끝점에 연결되며 에이전트 컨테이너에서만 로컬로 실행할 수 있다.

Octant UI 플러그인

Antrea는 또한 Octant UI에서 컨트롤러와 에이전트의 상태 및 기본 런타임 정보를 표시할 수 있는 Octant 플러그인을 구현한다. Octant 플러그인은 Kubernetes API의 AntreaControllerInfo 및 AntreaAgentInfo CRD(Custom Resource Definition)에서 컨트롤러 및 에이전트의 정보를 가져온다. CRD는 Antrea Controller와 각 Antrea Agent에 의해 생성되어 상태 및 런타임 정보를 채운다.

파드 네트워킹

파드 인터페이스 구성과 IP 주소관리(IPAM)

모든 노드에서 Antrea 에이전트는 OVS 브리지(기본적으로 br-int라는 이름)를 생성하고 각 포드에 대해 veth 쌍을 생성한다. 한 쪽 끝은 파드의 네트워크 네임스페이스에 있고 다른 쪽 끝은 OVS 브리지에 연결된다. 또한 OVS 브리지에서 Antrea 에이전트는 기본적으로 노드 서브넷의 게이트웨이로 내부 포트(antrea-gw0)를 생성하고 다른 노드에 오버레이 터널을 만들기 위한 터널 포트(antrea-tun0)를 생성한다.

각 노드에는 단일 서브넷이 할당되고, 노드의 모든 포드는 서브넷에서 IP를 가져온다. Antrea는 노드 서브넷 할당을 위해 Kubernetes NodeIPAMController를 활용한다. Kubernetes 노드 사양의 podCIDR 필드를 할당된 서브넷으로 설정한다. Antrea 에이전트는 podCIDR 필드에서 노드의 서브넷을 검색한다. 로컬 노드의 첫 번째 IP를 게이트웨이 IP로 예약하여 antrea-gw0 포트에 할당하고, 호스트-로컬 IPAM 플러그인을 호출하여 서브넷에서 모든 로컬 포드로 IP를 할당한다. 로컬 포드에는 해당 포드에 대해 CNI ADD 명령이 수신되면 IP가 할당된다.

트래픽 이동

모든 원격 노드에 대해 Antrea 에이전트는 적절한 터널을 통해 해당 노드에 트래픽을 전송하는 OVS 흐름을 추가한다. 흐름이 패킷의 대상 IP와 각 노드의 서브넷과 일치한다.

• Intra-node traffic – 두 로컬 포드 사이의 패킷은 OVS 브리지를 통해 직접 전달된다.
• Inter-node traffic – 다른 노드의 포드로의 패킷은 먼저 antrea-tun0 포트로 전달되고, 캡슐화되어 터널을 통해 대상 노드로 전송된다. 그런 다음 캡슐을 분리하여 antrea-tun0 포트를 통해 OVS 브리지로 주입하고, 최종적으로 대상 포드로 전달된다.
• Pod to external traffic – 외부 IP 또는 노드의 네트워크로 전송된 패킷은 다음과 같습니다. antrea-gw0 포트(로컬 포드 서브넷의 게이트웨이이므로), 노드의 적절한 네트워크 인터페이스(예: 베어 메탈 노드의 물리적 네트워크 인터페이스)로 라우팅되고, 거기서 노드 네트워크로 전송된다. Antrea 에이전트는 포드의 패킷에서 SNAT을 수행하는 iptables(MASQUERADE) 규칙을 만들어 해당 소스 IP를 노드의 IP로 다시 쓴다.

ClusterIP 서비스

현재 Antrea는 ClusterIP와 NodePort 유형의 서비스에 트래픽을 제공하기 위해 Kube-proxy를 활용한다. 포드에서 서비스 ClusterIP의 패킷은 antrea-gw0 포트를 통해 전달되며, kube-proxy는 하나의 서비스 백엔드 포드를 연결 대상으로 선택하고, DNAT는 패킷을 팟의 IP 및 포트로 전달한다. 대상 포드가 로컬 노드에 있으면 패킷이 직접 포드로 전달됩니다. 패킷이 다른 노드에 있으면 터널을 통해 해당 노드로 패킷이 전송됩니다.

kube-proxy는 사용자 공간 iptables 또는 IPVS와 같은 모든 지원 모드에서 사용할 수 있다. 자세한 내용은 Kubernetes Service 설명서를 참조한다. 향후 Antrea도 OVS가 포함된 ClusterIP 서비스와 구성 가능한 옵션으로 구현할 예정이다. 이는 사용자 공간 또는 iptables 모드에서 kube-proxy를 사용할 때 kube-proxy보다 더 나은 성능을 달성하는 데 도움이 될 것이다.

네트워크 정책

Antrea가 네트워크 정책 구현과 관련하여 취한 중요한 설계 선택은 중앙 집중식 정책 계산이다. Antrea 컨트롤러는 Kubernetes API에서 네트워크 정책, 포드 및 네임스페이스 리소스를 모니터링한다. 다음과 같이 PodSelector, 네임스페이스 Selector 및 ipBlock을 처리한다.

• NetworkPolicy 스펙 바로 아래의 PodSelector(NetworkPolicy가 적용되는 포드를 정의함)가 멤버 포드로 변환된다.
• 규칙의 Selector(podSelectors 및 namespaceSelectors) 및 ipBlocks(이 정책에서 허용하는 수신 및 송신 트래픽을 정의함)가 포드 IP 주소/IP 주소 범위에 매핑된다.

또한 Antrea 컨트롤러는 네트워크 정책을 수신해야 하는 노드를 계산한다. 각 Antrea 에이전트는 해당 노드에서 로컬로 실행되는 포드에 영향을 미치는 계산된 정책만 수신하고 컨트롤러에서 계산한 IP 주소를 직접 사용하여 지정된 네트워크 정책을 적용한다.

다음은 중앙 집중식 계산 접근 방식의 주요 이점이다.

• 하나의 Antrea 컨트롤러 인스턴스만 모든 네트워크 정책, 포드 및 네임스페이스 업데이트, 컴퓨팅 포드 선택기 및 네임스페이스 선택기를 수신 및 처리하면 된다. 이는 이러한 업데이트를 보고 모든 노드에서 동일한 복잡한 정책 계산을 수행하는 것에 비해 전체 비용이 훨씬 저렴하다.
• 여러 컨트롤러가 네트워크 정책 계산에서 함께 작동하는 컨트롤러의 확장을 지원할 수 있으며, 각 컨트롤러는 네트워크 정책의 하위 집합을 담당한다(비록 Antrea는 현재 단일 컨트롤러 인스턴스만 지원함).
• Antrea 컨트롤러는 네트워크 정책 계산의 단일 소스다. 노드 간의 일관성을 훨씬 쉽게 달성할 수 있고 네트워크 정책 구현을 디버깅하는 것이 더 쉽다.

앞에서 설명한 대로 Antrea Controller는 Kubernetes aisperver 라이브러리를 활용하여 에이전트에게 API 및 통신 채널을 구축한다.

IPsec 암호화

Antrea는 IPsec을 사용하여 보안 페이로드(ESP)를 캡슐화하는 GRE 터널 트래픽 암호화를 지원한다. IPsec 구현은 OVS IPsec를 활용하고 IKE 데몬으로 StrongSwan을 사용한다.

IPsec를 사용하도록 설정하려면 ovs-monitor-ipsec 및 strongSwan 데몬을 실행하는 추가 컨테이너(antrea-ovs-ipsec)를 Antrea Agent DaemonSet에 추가해야 한다. 이제 Antrea는 IKE 인증에 PSK(pre-shared key)만 사용할 수 있으며 PSK 문자열은 환경 변수를 사용하여 Antrea 에이전트에 전달해야 한다. – ANTREA_IPsec_PSK.
PSK 문자열은 Antrea IPsec 배포 yaml에 지정할 수 있으며, 이 yaml은 PSK 값을 저장하는 Kubernetes Secret을 생성하고 이를 Antrea 에이전트 컨테이너의 ANTREA_IPsec_PSK 환경 변수에 채운다.

IPsec을 사용하도록 설정하면 Antrea 에이전트는 각 원격 노드에 대해 OVS 브리지에 별도의 GRE 터널 포트를 생성하고 터널 인터페이스의 두 OVS 인터페이스 옵션에 PSK 문자열과 원격 노드 IP 주소를 기록한다. 그런 다음 ovs-monitor-ipsec은 원격 노드에 대한 PSK를 사용하여 터널을 감지하고 IPsec 보안 정책을 만들 수 있으며, strongSwan은 보안 정책에 따라 IPsec 보안 연결을 만들 수 있다. 이러한 추가 터널 포트는 트래픽을 원격 노드로 보내는 데 사용되지 않는다. 터널 트래픽은 여전히 OVS 흐름 기반 터널링을 통해 기본 터널 포트(antrea-tun0)로 출력됩니다. 그러나 원격 노드의 트래픽은 노드의 IPsec 터널 포트에서 수신된다.

Hybrid, NoEncap, NetworkPolicyOnly TrafficEncapModes

노드 간에 항상 오버레이 터널을 만들고 노드 간 포드 트래픽을 캡슐화하는 기본 encap 모드 외에도 Antrea는 Hybrid, NoEncap 및 NetworkPolicyOnly 모드를 비롯한 다른 TrafficEncap 모드도 지원합니다.

• Hybrid – 두 노드가 서로 다른 두 서브넷에 있으면 두 노드 간의 포드 트래픽이 캡슐화된다. 두 노드가 동일한 서브넷에 있을 때 두 노드 사이의 포드 트래픽이 캡슐화되지 않는다. 대신 트래픽이 한 노드에서 다른 노드로 라우팅된다. Antrea 에이전트는 노드에 경로를 추가하여 동일한 노드 서브넷 내에서 라우팅을 사용하도록 설정한다. 로컬 노드와 동일한 서브넷에 있는 모든 원격 노드에 대해 에이전트는 원격 노드 IP를 포드 서브넷의 다음 홉으로 사용하는 정적 경로 항목을 추가한다. 하이브리드 모드에서는 노드 네트워크가 포드 IP가 있는 패킷을 노드의 NIC에서 전송할 수 있어야 한다.
• NoEncap – 포드 트래픽은 캡슐화되지 않는다. Antrea는 단지 노드 네트워크가 노드 간 포드 트래픽 라우팅을 처리할 수 있다고 가정한다. 일반적으로, 이것은 노드 네트워크 라우터에 포드 서브넷의 경로를 추가하는 Kubernetes 클라우드 제공자 구현에 의해 달성된다. Antrea 에이전트는 여전히 동일한 서브넷의 원격 노드에 대해 각 노드에 정적 경로를 생성하며, 이는 노드 네트워크 라우터의 추가 홉을 거치지 않고 포드 트래픽을 대상 노드로 직접 라우팅하는 최적화다. 또한 Antrea 에이전트는 포드-투-외부 트래픽의 SNAT에 대한 iptables(MASQUERADE) 규칙을 생성한다. Antrea는 NoEncap 모드에서 Google Kubernetes Engine을 지원한다.
• NetworkPolicyOnly – 노드 간 포드 트래픽은 Antrea에 의해 터널링되거나 라우팅되지 않는다. Antrea는 단지 포드 트래픽에 대한 네트워크 정책을 구현하지만 다른 클라우드 CNI 및 클라우드 네트워크에 의존하여 포드 IPAM 및 크로스 노드 트래픽 전달을 구현한다. 자세한 내용은 NetworkPolicyOnly mode design doc를 참조한다. Antrea for the Azure Kubernetes Service engine과 Antrea support for the Amazon Elastic Kubernetes Service는 NetworkPolicyOnly 모드에서 동작한다.

참고 자료

• Securing and accelerating the Kubernetes CNI data plane with Project Antrea and NVIDIA Mellanox ConnectX SmartNICs