Kubernetes 포드는 어떻게 IP 주소를 얻나요?

메모. 번역: LinkedIn의 SRE 엔지니어가 작성한 이 기사에서는 다음 Pod에 IP 주소를 할당해야 할 때 발생하는 Kubernetes의 내부 마법, 더 정확하게는 CRI, CNI 및 kube-apiserver의 상호 작용에 대해 자세히 설명합니다.

기본 요구 사항 중 하나 Kubernetes 네트워크 모델 각 포드에는 자체 IP 주소가 있어야 하며 클러스터의 다른 포드는 해당 주소로 연결할 수 있어야 합니다. 이 네트워크 모델을 구현하는 데 도움이 되는 많은 네트워크 "공급자"(Flannel, Calico, Canal 등)가 있습니다.

처음 Kubernetes 작업을 시작했을 때 포드가 IP 주소를 정확히 어떻게 얻는지 완전히 명확하지 않았습니다. 개별 구성 요소가 어떻게 작동하는지 이해하더라도 이들이 함께 작동하는 것을 상상하기는 어려웠습니다. 예를 들어, CNI 플러그인이 무엇인지는 알았지만 정확히 어떻게 호출되는지는 몰랐습니다. 따라서 저는 다양한 네트워크 구성 요소에 대한 지식과 이러한 구성 요소가 Kubernetes 클러스터에서 어떻게 함께 작동하는지 공유하기 위해 이 기사를 작성하기로 결정했습니다. 이를 통해 각 포드는 고유한 IP 주소를 얻을 수 있습니다.

컨테이너에 다양한 런타임 옵션이 있는 것처럼 Kubernetes에서 네트워킹을 구성하는 방법도 다양합니다. 이 간행물은 플란넬 클러스터에서 네트워크를 구성하고 실행 가능한 환경으로 - 컨테이너. 또한 여러분이 컨테이너 간 네트워킹이 어떻게 작동하는지 알고 있다고 가정하고 있으므로 맥락에 맞게 간단히 다루겠습니다.

몇 가지 기본 개념

컨테이너와 네트워크: 간략한 개요

컨테이너가 네트워크를 통해 서로 통신하는 방법을 설명하는 훌륭한 출판물이 인터넷에 많이 있습니다. 따라서 기본 개념에 대한 일반적인 개요만 제공하고 Linux 브리지 생성 및 패키지 캡슐화와 관련된 한 가지 접근 방식으로 제한하겠습니다. 컨테이너 네트워킹 주제 자체는 별도의 기사로 다루어야 하므로 자세한 내용은 생략합니다. 특히 통찰력 있고 교육적인 출판물에 대한 링크가 아래에 제공됩니다.

하나의 호스트에 있는 컨테이너

동일한 호스트에서 실행되는 컨테이너 간에 IP 주소를 통한 통신을 구성하는 한 가지 방법은 Linux 브리지를 만드는 것입니다. 이를 위해 Kubernetes(및 Docker)에 가상 장치가 생성됩니다. veth (가상 이더넷). veth 장치의 한쪽 끝은 컨테이너의 네트워크 네임스페이스에 연결되고 다른 쪽 끝은 리눅스 브리지 호스트 네트워크에서.

동일한 호스트의 모든 컨테이너에는 veth의 한쪽 끝이 브리지에 연결되어 있으며 이를 통해 IP 주소를 통해 서로 통신할 수 있습니다. Linux 브리지에는 IP 주소도 있으며 다른 노드로 향하는 포드의 송신 트래픽에 대한 게이트웨이 역할을 합니다.

다른 호스트의 컨테이너

패킷 캡슐화는 서로 다른 노드에 있는 컨테이너가 IP 주소를 사용하여 서로 통신할 수 있도록 하는 한 가지 방법입니다. Flannel에서는 기술이 이러한 기회를 담당합니다. vxlan, 원본 패킷을 UDP 패킷으로 "패키지"한 다음 대상으로 보냅니다.

Kubernetes 클러스터에서 Flannel은 vxlan 장치를 생성하고 그에 따라 각 노드의 경로 테이블을 업데이트합니다. 다른 호스트의 컨테이너로 향하는 각 패킷은 vxlan 장치를 통과하고 UDP 패킷에 캡슐화됩니다. 목적지에서는 중첩된 패킷이 추출되어 원하는 포드로 전달됩니다.

참고: 이는 컨테이너 간의 네트워크 통신을 구성하는 한 가지 방법일 뿐입니다.

CRI란 무엇입니까?

CRI(컨테이너 런타임 인터페이스) kubelet이 다양한 컨테이너 런타임 환경을 사용할 수 있게 해주는 플러그인입니다. CRI API는 다양한 런타임에 내장되어 있으므로 사용자는 원하는 런타임을 선택할 수 있습니다.

CNI란 무엇인가요?

프로젝트 CNI ~이다. 사양 Linux 컨테이너를 위한 범용 네트워크 솔루션을 구성합니다. 또한, 여기에는 다음이 포함됩니다. 플러그인, Pod 네트워크 설정 시 다양한 기능을 담당합니다. CNI 플러그인은 사양을 준수하는 실행 파일입니다(아래에서 일부 플러그인에 대해 설명합니다).

포드에 IP 주소를 할당하기 위해 노드에 서브넷 할당

클러스터의 각 포드에는 IP 주소가 있어야 하므로 이 주소가 고유한지 확인하는 것이 중요합니다. 이는 각 노드에 고유한 서브넷을 할당하고 해당 노드의 포드에 IP 주소를 할당함으로써 달성됩니다.

노드 IPAM 컨트롤러

언제 nodeipam 플래그 매개변수로 전달됨 --controllers kube-컨트롤러-관리자, 클러스터 CIDR(즉, 클러스터 네트워크의 IP 주소 범위)의 각 노드에 별도의 서브넷(podCIDR)을 할당합니다. 이러한 podCIDR은 겹치지 않으므로 각 Pod에 고유한 IP 주소가 할당될 수 있습니다.

Kubernetes 노드는 클러스터에 처음 등록될 때 podCIDR이 할당됩니다. 노드의 podCIDR을 변경하려면 노드를 등록 취소한 다음 다시 등록하고 그 사이에 Kubernetes 제어 계층 구성을 적절하게 변경해야 합니다. 다음 명령을 사용하여 노드의 podCIDR을 표시할 수 있습니다.

$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24

Kubelet, 컨테이너 런타임 및 CNI 플러그인: 모든 작동 방식

노드당 포드를 예약하려면 많은 준비 단계가 필요합니다. 이 섹션에서는 포드 네트워크 설정과 직접적으로 관련된 항목에만 중점을 둘 것입니다.

특정 노드에 대한 Pod를 예약하면 다음과 같은 이벤트 체인이 트리거됩니다.

FAQ : Containerd CRI 플러그인 아키텍처.

컨테이너 런타임과 CNI 플러그인 간의 상호 작용

각 네트워크 제공업체에는 자체 CNI 플러그인이 있습니다. 컨테이너의 런타임은 이를 실행하여 포드가 시작될 때 네트워크를 구성합니다. Containerd의 경우 플러그인에 의해 CNI 플러그인이 실행됩니다. 컨테이너드 CRI.

또한 각 공급자에는 자체 에이전트가 있습니다. 모든 Kubernetes 노드에 설치되며 Pod의 네트워크 구성을 담당합니다. 이 에이전트는 CNI 구성에 포함되거나 노드에 독립적으로 생성됩니다. 구성은 CRI 플러그인이 호출할 CNI 플러그인을 설정하는 데 도움이 됩니다.

CNI 구성의 위치는 사용자 정의할 수 있습니다. 기본적으로는 /etc/cni/net.d/<config-file>. 클러스터 관리자는 각 클러스터 노드에 CNI 플러그인을 설치하는 일도 담당합니다. 위치도 맞춤 설정할 수 있습니다. 기본 디렉토리 - /opt/cni/bin.

Containerd를 사용하는 경우 플러그인 구성 및 바이너리의 경로를 섹션에서 설정할 수 있습니다. [plugins.«io.containerd.grpc.v1.cri».cni] в 컨테이너 구성 파일.

Flannel을 네트워크 공급자로 사용하고 있으므로 Flannel 설정에 대해 조금 이야기해 보겠습니다.

• Flanneld(Flannel의 데몬)는 일반적으로 다음을 사용하여 클러스터에 DaemonSet으로 설치됩니다. install-cni 으로 컨테이너 초기화.
• Install-cni 창조 CNI 구성 파일 (/etc/cni/net.d/10-flannel.conflist) 각 노드에.
• Flanneld는 vxlan 장치를 생성하고, API 서버에서 네트워크 메타데이터를 검색하고, Pod 업데이트를 모니터링합니다. 생성되면 클러스터 전체의 모든 포드에 경로를 배포합니다.
• 이러한 경로를 통해 포드는 IP 주소를 통해 서로 통신할 수 있습니다.

Flannel 작업에 대한 자세한 내용을 보려면 기사 끝 부분에 있는 링크를 사용하는 것이 좋습니다.

다음은 Containerd CRI 플러그인과 CNI 플러그인 간의 상호 작용에 대한 다이어그램입니다.

위에서 볼 수 있듯이 kubelet은 Containerd CRI 플러그인을 호출하여 포드를 생성한 다음 CNI 플러그인을 호출하여 포드의 네트워크를 구성합니다. 이를 통해 네트워크 공급자의 CNI 플러그인은 다른 핵심 CNI 플러그인을 호출하여 네트워크의 다양한 측면을 구성합니다.

CNI 플러그인 간의 상호 작용

호스트의 컨테이너 간 네트워크 통신을 설정하는 데 도움을 주는 다양한 CNI 플러그인이 있습니다. 이 기사에서는 그 중 세 가지를 다룰 것입니다.

CNI 플러그인 플란넬

Flannel을 네트워크 공급자로 사용하는 경우 Containerd CRI 구성 요소는 다음을 호출합니다. CNI 플러그인 플란넬CNI 구성 파일 사용 /etc/cni/net.d/10-flannel.conflist.

$ cat /etc/cni/net.d/10-flannel.conflist
{
  "name": "cni0",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
         "ipMasq": false,
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    }
  ]
}

Flannel CNI 플러그인은 Flanneld와 함께 작동합니다. 시작하는 동안 Flanneld는 API 서버에서 podCIDR 및 기타 네트워크 관련 세부 정보를 검색하여 파일에 저장합니다. /run/flannel/subnet.env.

FLANNEL_NETWORK=10.244.0.0/16 
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450 
FLANNEL_IPMASQ=false

Flannel CNI 플러그인은 다음의 데이터를 사용합니다. /run/flannel/subnet.env CNI 브리지 플러그인을 구성하고 호출합니다.

CNI 플러그인 브리지

이 플러그인은 다음 구성으로 호출됩니다.

{
  "name": "cni0",
  "type": "bridge",
  "mtu": 1450,
  "ipMasq": false,
  "isGateway": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24"
  }
}

처음 호출되면 다음을 사용하여 Linux 브리지를 생성합니다. «name»: «cni0», 이는 구성에 표시됩니다. 그런 다음 각 포드에 대해 veth 쌍이 생성됩니다. 한쪽 끝은 컨테이너의 네트워크 네임스페이스에 연결되고 다른 쪽 끝은 호스트 네트워크의 Linux 브리지에 포함됩니다. CNI 플러그인 브리지 모든 호스트 컨테이너를 호스트 네트워크의 Linux 브리지에 연결합니다.

veth 쌍 설정을 마친 후 Bridge 플러그인은 호스트-로컬 IPAM CNI 플러그인을 호출합니다. IPAM 플러그인 유형은 CRI 플러그인이 Flannel CNI 플러그인을 호출하는 데 사용하는 CNI 구성에서 구성할 수 있습니다.

호스트-로컬 IPAM CNI 플러그인

브리지 CNI 통화 호스트-로컬 IPAM 플러그인 CNI 다음 구성으로:

{
  "name": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24",
    "dataDir": "/var/lib/cni/networks"
  }
}

호스트-로컬 IPAM 플러그인 (IP A의 ddress M관리 - IP 주소 관리) 서브넷에서 컨테이너의 IP 주소를 반환하고 섹션에 지정된 디렉터리의 호스트에 할당된 IP를 저장합니다. dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. 이 파일에는 이 IP 주소가 할당된 컨테이너의 ID가 포함되어 있습니다.

호스트-로컬 IPAM 플러그인을 호출하면 다음 데이터가 반환됩니다.

{
  "ip4": {
    "ip": "10.244.4.2",
    "gateway": "10.244.4.3"
  },
  "dns": {}
}

개요

Kube-controller-manager는 각 노드에 podCIDR을 할당합니다. 각 노드의 Pod는 할당된 PodCIDR 범위의 주소 공간에서 IP 주소를 수신합니다. 노드의 podCIDR은 겹치지 않으므로 모든 Pod는 고유한 IP 주소를 받습니다.

Kubernetes 클러스터 관리자는 kubelet, 컨테이너 런타임, 네트워크 공급자 에이전트를 구성 및 설치하고 CNI 플러그인을 각 노드에 복사합니다. 시작하는 동안 네트워크 공급자 에이전트는 CNI 구성을 생성합니다. 포드가 노드에 예약되면 kubelet은 CRI 플러그인을 호출하여 포드를 생성합니다. 다음으로, Containerd를 사용하는 경우 Containerd CRI 플러그인은 CNI 구성에 지정된 CNI 플러그인을 호출하여 포드의 네트워크를 구성합니다. 결과적으로 포드는 IP 주소를 수신합니다.

이러한 모든 상호 작용의 모든 미묘함과 뉘앙스를 이해하는 데는 시간이 좀 걸렸습니다. 이 경험이 Kubernetes의 작동 방식을 더 잘 이해하는 데 도움이 되기를 바랍니다. 제가 틀린 부분이 있으면 저에게 연락주세요. 트위터 아니면 그 주소에서 [이메일 보호]. 이 기사의 내용이나 다른 내용에 대해 논의하고 싶다면 언제든지 연락해 주세요. 나는 당신과 이야기하고 싶습니다!

참조

컨테이너 및 네트워크

• 컨테이너 네트워킹 개요
• 컨테이너 네트워킹 이해하기

플란넬은 어떻게 작동하나요?

• 플란넬 네트워킹 Demystify
• 플란넬을 사용한 Kubernetes - 네트워킹 이해

CRI 및 CNI

• CRI 플러그인 아키텍처
• CNI 스펙
• CNI 플러그인

번역가의 추신

블로그에서도 읽어보세요.

• «Kubernetes 네트워킹을 위한 Calico: 소개 및 약간의 경험";
• "Kubernetes의 네트워킹에 대한 그림 가이드": 파트 1 및 2(네트워크 모델, 오버레이 네트워크), 3부(서비스 및 트래픽 처리);
• «CNI(컨테이너 네트워킹 인터페이스) - Linux 컨테이너용 네트워크 인터페이스 및 표준".

출처 : habr.com