컨테이너 네트워크 인터페이스 선택

가상 사설 클라우드

컨테이너 네트워크 인터페이스(CNI)를 선택하기 위해 다음 정보를 확인하십시오.

IBM Cloud Kubernetes Service 버전 4.20 및 이후 버전에서는 Calico 가 기본 CNI로 설정되어 있지만, RHCOS 워커 노드를 사용하는 VPC 클러스터의 경우 클러스터 CNI로 Open Virtual Network(OVN)를 선택할 수 있습니다.

Calico 기본값: Calico 클라우드, 온프레미스 또는 엣지 환경에 구축된 모든 Kubernetes 배포 환경을 위한 네트워킹, 네트워크 보안 및 가시성을 제공하는 단일 플랫폼입니다. Kubernetes 를 막 시작하셨든, 대규모로 운영 중이시든 상관없이, Calico 의 오픈 소스, 엔터프라이즈 및 클라우드 에디션은 여러분이 필요로 하는 네트워킹, 보안 및 가시성을 제공합니다. 자세한 내용은 Calico 문서를 참조하십시오.
OVN- Kubernetes (OVN) 4.20 및 이후 버전 RHCOS 워커 노드 전용: OVN- Kubernetes 는 Open Virtual Network(OVN)를 기반으로 하며, 오버레이 기반의 네트워킹 구현을 제공합니다. OVN- Kubernetes 플러그인을 사용하는 클러스터는 각 노드에서 Open vSwitch (OVS)도 실행합니다. OVN은 선언된 네트워크 구성을 구현하기 위해 각 노드에서 OVS를 구성합니다. 자세한 내용은 ‘ Red Hat ’ 문서를 참조하십시오

Calico 와 OVN 비교

다음 표를 참고하여 Calico 와 OVN의 특징 및 기능을 비교해 보십시오.

OVN을 사용할 때는 VPC 서브넷이 다음 표에 명시된 추가 서브넷과 중복되지 않도록 해야 합니다. 서브넷이 중복되는 경우, 포드 간 네트워킹이 실패합니다.

Layer2 또한 layer3 사용자 정의 네트워크(UDN)는 OpenShift 가상화 가상 머신(VM)과 같이 DHCP를 사용하는 워크로드에서는 지원되지 않습니다.

Calico 및 OVN 비교표
컴포넌트	Calico	OVN- Kubernetes
캡슐화	IP-in-IP 프로토콜( UDP 나 TCP 이 아님) 서로 다른 서브넷에 속한 노드에서 실행 중인 포드 간 트래픽만을 캡슐화합니다.	제네바: UDP, 6081번 포트 프로토콜 모든 포드 간 트래픽을 캡슐화합니다
기본 클러스터 네트워크/포드 MTU	기본값은 1480바이트(20바이트 IPinIP 헤더)입니다. 이 부분은 변경할 수 있습니다.	기본값은 1400바이트(100바이트 Geneve 헤더 포함)입니다. 이 부분은 변경할 수 있습니다. Daemonset은 단순히 ip link set dev ens3 mtu``를 실행하는 대신 `NetworkManager` 파일을 생성해야 합니다. 또한 새로운 워커 노드도 다시 시작해야 합니다.
Pod IPAM	Calico 처음에는 각 새 노드에 /26 서브넷(64개의 IP 주소, 일반적으로 최소 한 개는 tunl0 IP로 사용되며, 나머지는 포드에 할당 가능)을 할당합니다. /26 범위의 모든 포드 IP가 사용된 경우, Calico 는 해당 노드에 두 번째 /26 서브넷을 할당하며, 필요에 따라 추가 서브넷도 할당합니다. `calicoctl ipam check` 를 사용하면 각 노드에 할당된 서브넷을 확인할 수 있습니다.	OVN은 처음에 각 새로운 클러스터 노드에 /24 포드 서브넷(256개의 IP)을 할당합니다. 더 이상 Pod 서브넷을 추가할 수 있는 옵션이 없습니다. 또한 각 새 노드에 조인 서브넷 IP를 할당하며, 이 IP는 OVN에서 내부적으로 사용됩니다
포드 간 라우팅	리눅스 라우팅을 사용합니다. BGP를 사용하여 경로를 배포합니다. 캡슐화를 위해 각 노드에 `tunl0` 인터페이스가 있습니다.	각 노드에서 Open vSwitch (OVS)가 실행되며, 포드 간 트래픽을 라우팅합니다. OVN은 OVS 플로우를 구성하여 포드 간 라우팅을 정의합니다. 각 노드에는 `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, `br-ex` 등과 같은 여러 다른 인터페이스가 생성되며, 이러한 인터페이스는 OVN과 OVS에서 사용됩니다
Kubernetes 네트워크 정책	`calico-node` 에서 iptables 규칙을 추가하여 구현했습니다. 네트워크 정책에 의해 차단된 트래픽을 로깅하는 것은 가능하지만, 절차가 복잡합니다. 이를 위해서는 “로그(Log)” 작업을 사용하는 추가적인 Calico 정책이 필요하며, 이러한 로그 작업을 어디에, 언제 배치할지에 대한 신중한 고려와 계획이 필요합니다. 워커 노드의 `syslog` 에 로그가 기록되는데, 이 로그를 검색하기가 어려울 수 있습니다. 로그에는 어떤 정책이 트래픽을 허용하거나 차단했는지에 대한 정보가 포함되지 않습니다.	OVS에서 논리 포트에 대한 ACL(iptables가 아님)을 사용하여 구현됩니다. 어노테이션을 사용하면 네트워크 정책에 따른 트래픽 차단 및/또는 허용 내역을 훨씬 쉽게 로깅할 수 있습니다. 정책 활동 로깅을 원하는 네임스페이스에 어노테이션을 지정하고, 허용, 차단 또는 둘 다 로깅할지 여부를 설정합니다. 로그는 `ovnkube-node` 포드 내의 `/var/log/ovn/acl-audit-log.log` 파일에 기록됩니다. 이러한 로그를 다른 로그 대상에 전송하도록 설정할 수 있는 구성 옵션이 있습니다. 정책은 허용 전용이므로, 로그에는 트래픽을 허용한 정책만 포함되며, 거부한 정책은 포함되지 않습니다. 허용된 트래픽이 기록되려면 적어도 하나의 정책이 설정되어 있어야 합니다.
호스트 네트워크 정책	Calico GlobalNetworkPolicies	없음
추가 서브넷	없음	가입할 서브넷: `100.64.0.0/16` ( OpenShift 기본값). 마스커레이드 서브넷: `169.254.64.0/18`. 이는 OpenShift 의 기본값인 `169.254.0.0/17` 과는 다릅니다. 이러한 차이는 로컬 레지스트리 HAProxy에 사용되는 `169.254.2.0/24` IP와 충돌을 피하기 위한 것입니다. 트랜짓 서브넷:`100.88.0.0/16` ( OpenShift 기본값).
API 서버 모니터링	`calico-typha` 는 리소스 감시 기능을 등록하고, `calico-node` 포드에 대한 프록시 역할을 수행하여 변경 사항을 알립니다. `calico-node` 는 `calico-typha` 포드 중 하나에 연결하여 리소스 변경 알림을 수신하도록 등록합니다.	제어 평면의 ovnkube-cluster-manager 컨테이너는 새로운 노드가 추가되는지 감시합니다. 각 클러스터 노드에 있는 ovnkube-controller 컨테이너는 리소스를 감시하고, 이를 nbdb의 OVN 논리 항목으로 변환합니다.
CNI	`calico` 및 `calico-ipam` CNI 바이너리는 `calico-node` 포드에 있는 `install-cni` initContainer 에 의해 각 노드로 복사됩니다.	`ovnkube-node` 포드의 `ovnkube-controller` 컨테이너는 add 및 delete 호출을 위해 CNI 바이너리를 실행합니다.
리소스가 작성됨	`calico-apiserver` 네임스페이스 `calico-apiserver` (디플로이먼트, 2개의 포드) `calico-system` 네임스페이스 `calico-node` (각 노드) `calico-typha` (디플로이먼트, 2~10개의 포드). `calico-kube-controllers` (1개 노드). `openshift-kube-proxy` 네임스페이스. `openshift-kube-proxy` (각 노드). `tigera-operator` 네임스페이스. `tigera-operator` (데플로이먼트, 1개 파드). `calico` CNI 바이너리, `calico-ipam` CNI 바이너리 및 기타 다양한 CNI 바이너리는 `calico-node` 에서 `install-cni` initContainer 에 의해 각 노드로 복사됩니다.	`openshift-ovn-kubernetes` 네임스페이스, 각 노드마다 8개의 컨테이너가 포함된 `ovnkube-node`, `ovnkube-controller` 는 리소스를 모니터링하고, 포드 IP를 할당하며, 리소스를 `nbdb` 의 OVN 논리 항목으로 변환합니다. 또한 CNI 추가 및 삭제 기능도 처리합니다. `nbdb` 는 논리적 항목을 저장합니다. `northd` 는 `nbdb` 의 논리적 항목을 `sbdb` 의 논리적 흐름으로 변환합니다. `sbdb` 는 논리적 흐름을 저장합니다. `ovn-controller` 는 `sbdb` 의 논리적 흐름을 변환하고 OVS 스위치를 프로그래밍합니다. `ovn-acl-logging`. `kube-rbac-proxy-node` 는 노드 메트릭을 보호하여 승인된 사용자만 해당 메트릭을 수집할 수 있도록 합니다. `kube-rbac-proxy-ovn-metrics` 는 OVN 메트릭을 보호하여 승인된 사용자만 해당 메트릭을 수집할 수 있도록 합니다.
포드 간의 연결	`calico-node` 포드는 처음에 TCP 172.20.0.1:2040 에서 리스닝 중인 프록시 포드의 로컬 haproxy를 통해 kube apiserver에 연결하여 `calico-typha` 의 포드 목록을 가져옵니다. `calico-node` 포드는 TCP 의 5473번 포트에서 `calico-typha` 포드 중 하나에 연결하여 클러스터 리소스 업데이트를 수신 대기합니다. `calico-node` 포드는 TCP 의 179번 포트에서 다른 모든 `calico-node` bird BGP 데몬과 풀 메쉬(full mesh) 방식으로 연결되는 bird BGP 데몬을 실행합니다. 동일한 서브넷에 있는 노드의 포드 간 트래픽은 직접 발생합니다. 서로 다른 서브넷에 있는 노드의 파드 간 트래픽은 IPinIP 캡슐화(또는 Satellite 클러스터의 경우 VxLAN )를 사용하여 캡슐화됩니다.	각 노드의 ovnkube-controller 컨테이너는 리소스 감시(resource watches)를 위해 TCP 에서 리스닝하는 프록시 파드의 로컬 haproxy를 통해 kube apiserver에 연결됩니다. `172.20.0.1:2040` 모든 파드 간 트래픽은 Geneve를 사용하여 캡슐화되며, UDP 의 6081번 포트를 통해 전송됩니다. 자세한 내용은 ‘방화벽 구성’을 참조하십시오.