본문 바로가기
CNCF/Kubernetes

Antrea Overview

해당 문서는  https://github.com/vmware-tanzu/antrea 기반으로 번역된 문서입니다.

Antrea Architecture

Antrea는 Kubernetes 중심 및 Kubernetes 네이티브가 되도록 설계되어있다.  Kubernetes 클러스터의 네트워킹 및 보안에 중점을 두고 최적화되었다. 구현은 가능한 한 Kubernetes 및 Kubernetes 기본 설루션을 활용한다.

Antrea는 Open vSwitch를 네트워킹 data plane.으로 사용된다. Open vSwitch는 Linux 및 Windows를 모두 지원하는 고성능 프로그래밍 가능 가상 스위치이다. Antrea는 Open vSwitch를 사용하여 Kubernetes 네트워크 정책을 고성능으로 효율적으로 구현할 수 있다. Antrea는 Open vSwitch의 "programmable"특성으로 인해 Open vSwitch 위에 광범위한 네트워킹 및 보안 기능과 서비스를 구현할 수 있다.

Components

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

Antrea Controller

Antrea Controller는 Kubernetes API의 NetworkPolicy, Pod 및 네임 스페이스 리소스를 감시하고 NetworkPolicies를 계산하고 계산된 정책을 모든 Antrea 에이전트에 배포한다. 현재 Antrea Controller는 단일 복제본만 지원한다. 현재 Antrea Controller는 주로 NetworkPolicy 구현을 위해 존재한다. 포드 간의 연결 만 신경 쓰지만 NetworkPolicy 지원은 신경 쓰지 않으면 Antrea Controller를 전혀 배포하지 않도록 선택할 수 있다. 

Antrea Controller는 Kubernetes apiserver 라이브러리를 활용하여 Antrea Agent에 대한 통신 채널을 구현한다. 각 Antrea Agent는 Controller API 서버에 연결하고 계산된 NetworkPolicy 오브젝트를 감시한다. 또한 컨트롤러는 동일한 HTTP 엔드 포인트에서 antctl에 대한 REST API를 제공한다. 

Controller API server

Antrea Controller는 Kubernetes apiserver 라이브러리를 활용하여 자체 API 서버를 구현한다. API 서버 구현은 계산 된 NetworkPolicies를 에이전트에 공개하기 위해 사용자 정의되고 최적화된다.

  • API 서버는 모든 상태를 in-memory 캐시에 보관하며 데이터를 유지하기 위해 데이터 스토어가 필요하지 않는다.
  • NetworkPolicy 개체를 로컬로 적용해야 하는 노드에만 NetworkPolicy 개체를 보낸다. NetworkPolicy가 노드의 하나 이상의 포드에 적용된 경우에만 노드가 NetworkPolicy를 받는다.
  • NetworkPolicy 개체에 대한 증분 업데이트를 에이전트에 보내는 것을 지원한다.
  • 컨트롤러와 에이전트 사이의 메시지는 크기를 줄이고 효율성을 높이기 위해 Protobuf 형식을 사용하여 직렬화된다.

Antrea Controller API 서버는 Kubernetes Service를 활용하여 다음을 수행한다.

  • service discovery, and
  • authentication and authorization.

Controller API 엔드 포인트는 Kubernetes ClusterIP 유형 서비스를 통해 노출된다. Antrea Agent는 서비스 환경 변수에서 서비스의 ClusterIP를 가져오고 ClusterIP를 사용하여 Controller API 서버에 연결한다. Controller API 서버는 Kubernetes API에 인증 및 권한을 위임한다. Antrea Agent는 Kubernetes ServiceAccount 토큰을 사용하여 Controller를 인증하고 Controller API 서버는 토큰 및 ServiceAccount가 Kubernetes API의 API 요청에 대한 권한이 있는지 여부를 확인한다.

 

Antrea Controller는 API 서버 HTTP 엔드 포인트를 사용하여 antctl에 대한 REST API도 노출한다. Kubernetes API aggregation를 활용하여 antctl이 Kubernetes API를 통해 Antrea Controller API에 도달할 수 있도록 한다. antctl은 Kubernetes API에 연결하고 인증한다. 그러면 Antctl API 요청이 Antrea Controller에 프락시 된다. 이런 식으로 Kubernetes API에 연결할 수 있는 모든 컴퓨터에서 antctl을 실행할 수 있으며 kubectl 구성 (kubeconfig 파일)을 활용하여 Kubernetes API 및 인증 정보를 검색할 수도 있다.

Antrea Agent

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

Antrea Agent는 antrea-cni binary에 의해 호출된 gRPC 서비스 (Cni 서비스)를 노출시켜 CNI 조작을 수행한다. 에이전트는 antrea-cni로부터 CNI ADD 호출을 받은 후 노드에 생성될 각 새 pod에 대해 포드의 네트워크 인터페이스를 생성하고 IP 주소를 할당하며 인터페이스를 OVS 브리지에 연결하고 OVS에 필요한 flows를 추가한다

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

  • 노드 컨트롤러는 Kubernetes API 서버에서 새 노드를 감시하고 각 원격 노드에 OVS (Geneve / VXLAN / GRE / STT) 터널을 생성
  • NetworkPolicy 컨트롤러는 Antrea Controller API에서 계산된 NetworkPolicies를 감시하고 OVS flow를 생성하여 local pod에 대한 NetworkPolicies를 구현

Antrea Agent는 또한 antctl에 대한 로컬 HTTP 엔드 포인트에서 REST API를 노출한다.

OVS daemons

두 개의 OVS 데몬 인 ovsdb-server 및 ovs-vswitchd는 Antrea Agent DaemonSet의 별도 컨테이너 (antrea-ovs)에서 실행된다.

antrea-cni

antrea-cni는 Antrea의 CNI 플러그인 바이너리이다. 각 CNI 명령마다 kubelet에 의해 실행된다. 각 CNI 명령에 대해 Antrea Agent에 RPC를 발행하는 간단한 gRPC 클라이언트이다. 에이전트는 실제 작업을 수행하고 (Pod에 대한 네트워킹을 설정) 결과 또는 오류를 antrea-cni에 반환한다.

antctl

antctl은 Antrea의 명령 행 도구로 현재 디버깅 목적으로 Antrea Controller 및 Antrea Agent 모두에 대한 기본 런타임 정보를 표시할 수 있다. 

Controller에 액세스 할 때 antctl은 Controller API를 호출하여 필요한 정보를 조회한다. 앞에서 설명한 것처럼 antctl은 Kubernetes API를 통해 Controller API에 도달할 수 있으며 Kubernetes API가 API 요청을 Controller에 인증, 권한 부여 및 프락시 하도록 할 수 있다. antctl은 kubectl을 통해 kubectl 플러그인으로 실행할 수 있다.

 

에이전트에 액세스 할 때 antctl은 에이전트의 로컬 REST 엔드 포인트에 연결하며 에이전트 컨테이너에서 로컬로만 실행할 수 있다.

Octant UI plugin

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

 

Pod Networking

Pod interface configuration and IPAM

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

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

모든 원격 노드에 대해 Antrea Agent는 OVS flow를 추가하여 적절한 터널을 통해 해당 노드로 트래픽을 보낸다. flow는 각 노드의 서브넷에 대한 패킷의 대상 IP와 일치한다.

Traffic walk

 

Intra-node traffic : 두 로컬 포드 사이의 패킷은 OVS 브리지에서 직접 전달

Inter-node traffic : 다른 노드의 포드에 대한 패킷은 먼저 antrea-tun0 포트로 전달되고 캡슐화되어 터널을 통해 대상 노드로 전송되며,  캡슐을 제거하고 antrea-tun0 포트를 통해 OVS 브리지로 주입 한 다음 최종적으로 대상 포드로 전달

Pod to external traffic: 외부 IP 또는 노드의 네트워크로 전송된 패킷은 antrea-gw0 포트 (로컬 포드 서브넷의 게이트웨이이므로)로 전달되고 (노드에 구성된 경로를 기반으로) 적절한 네트워크로 라우팅 된다. 노드의 인터페이스 (예 : 베어 메탈 노드의 실제 네트워크 인터페이스)를 통해 노드 네트워크로 전송된다. Antrea Agent는 포드의 패킷에 대해 SNAT를 수행하기 위해 iptables (MASQUERADE) 규칙을 작성하므로, 나가기 전에 소스 IP가 노드의 IP에 다시 쓰인다.

ClusterIP Service

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

kube-proxy는 사용자 공간 iptables 또는 IPVS와 같은 모든 지원 모드에서 사용할 수 있다.

향후 Antrea는 OVS와 함께 ClusterIP Service를 구현하고 구성 가능한 옵션으로 만들 것이다. 이는 사용자 공간 또는 iptables 모드에서 kube-proxy를 사용할 때 kube-proxy보다 나은 성능을 달성하는 데 도움이 될 것이다.

 

 

반응형