kubernetes CKA study (28) - Cluster Networking, Pod Networking, CNI in Kubernetes, CNI weave
kubernetes CKA study
Cluster Networking
IP & FQDN
각 노드에는 네트워크에 연결된 인터페이스가 하나 이상 있어야 합니다. 각 인터페이스에는 주소가 있어야 합니다. 호스트에는 고유한 호스트 이름 집합과 고유한 MAC 주소가 있어야 합니다. 특히 기존 VM에서 replication하여 VM을 생성한 경우에는 이 점에 유의해야 합니다.
Ports
몇 개의 포트도 열려야 합니다. 이들은 controlplane의 다양한 컴포넌트에 의해 사용됩니다. 마스터는 API 서버에 대해 6443의 연결을 허용해야 합니다. 워커 노드, Kube 제어 도구, 외부 사용자 및 기타 모든 제어부 config요소는 이 포트를 통해 Kube API 서버에 액세스합니다. 마스터 및 워커 노드의 큐블릿은 포트 10250에서 수신합니다. 네, 이에 대해 논의하지 않은 경우 마스터 노드에도 쿠벨렛이 있을 수 있습니다. Kube 스케줄러를 사용하려면 포트 10259가 열려 있어야 합니다. Kube 컨트롤러 관리자를 사용하려면 포트 10257이 열려 있어야 합니다. 워커 노드는 포트 30000-32767에서 외부 액세스를 위한 서비스를 노출하므로 이 또한 열려 있어야 합니다. 마지막으로, etcd 서버는 포트 2379에서 수신합니다.
마스터 노드가 여러 개 있는 경우에는 이러한 모든 포트도 해당 포트에서 열어야 합니다. 그리고 당신은 etcd 클라이언트가 서로 통신할 수 있도록 추가 포트 2380이 열려 있어야 합니다.
테스트 문제 기록
What is the network interface configured for cluster connectivity on the controlplane node? (컨트롤플레인 노드의 클러스터 연결을 위해 구성된 네트워크 인터페이스)
테스트는 통과했지만 네트워크와 DNS 기본 개념에 대해서는 복습이 필요할 것 같다.
Pod Networking
지금까지 우리는 여러 개의 Kubernetes 마스터 및 워커 노드를 설정하고, 이들 노드 간의 네트워킹을 구성하여 이들은 모두 서로 연결할 수 있는 네트워크에 있습니다. 또한 Kubernetes controlplane 컴포넌트가 서로 도달할 수 있도록 방화벽 및 네트워크 보안 그룹이 올바르게 구성되었는지 확인했습니다. 우리가 또한 kube-apiserver, etcd 서버, kubelet, 등과 같은 모든 Kubernetes 제어 평면 컴포넌트를 설정했고 마침내 애플리케이션을 배포할 준비가 되었다고 가정합니다. 하지만 그러기 전에, 우리가 해결해야 할 것이 있습니다. 우리는 노드를 함께 연결하는 네트워크에 대해 이야기했지만, 클러스터가 작동하는 데 중요한 또 다른 네트워킹 계층인 파드 계층의 네트워킹에 대해서도 이야기해야 합니다.
우리의 Kubernetes 클러스터는 곧 많은 수의 파드와 서비스를 실행할 것입니다. 파드는 어떻게 처리됩니까? 그들은 어떻게 서로 의사소통을 할까요? 클러스터 내에서뿐만 아니라 클러스터 외부에서도 이러한 파드에서 실행되는 서비스에 액세스하려면 어떻게 해야 합니까? 이것들은 쿠버네티스가 여러분이 해결하기를 기대하는 과제들입니다. 오늘날, 쿠버네티스는 이것에 대한 기본 제공 솔루션을 제공하지 않습니다. 그것은 당신이 이러한 과제를 해결하는 네트워킹 솔루션을 구현하기를 기대합니다. 그러나 Kubernetes는 파드 네트워킹에 대한 요구 사항을 명확하게 제시했습니다. 그것들이 무엇인지 살펴봅시다.
Kubernetes는 모든 파드가 고유한 IP 주소를 가질 것으로 예상하며, 모든 파드는 해당 IP 주소를 사용하여 동일한 노드 내의 다른 모든 파드에 도달할 수 있습니다. 또한 모든 Pod는 동일한 IP 주소를 사용하여 다른 노드의 모든 Pod에 연결할 수 있습니다. IP 주소가 어떤 IP 주소이고 어떤 범위 또는 서브넷에 속하는지는 중요하지 않습니다. IP 주소를 자동으로 할당하고 노드의 파드와 다른 노드의 부품 간 연결을 설정하는 솔루션을 구현할 수 있다면 네트워크 rule을 구성할 필요가 없습니다. 그렇다면 이러한 요구사항을 해결하는 모델을 어떻게 구현할 수 있을까요?
이러한 기능을 제공하는 네트워킹 솔루션은 여러 가지가 있지만 네트워킹 개념, 라우팅, IP 주소 관리, 네임스페이스 및 CNI에 대해서는 이미 배웠습니다. 그래서 그 지식을 이용해서 먼저 우리 스스로 이 문제를 해결해 봅시다.
3개의 노드 클러스터가 있습니다. 어느 쪽이 주인이고 노동자인지는 중요하지 않다. 관리 또는 워크로드 목적으로 모두 파드를 실행합니다. 네트워킹에 관한 한, 우리는 그것들을 모두 동일하게 고려할 것이다. 그래서 먼저, 우리가 무엇을 할지 계획해 봅시다. 노드는 외부 네트워크의 일부이며 192.168.1. 시리즈의 IP 주소를 가집니다. 노드 1은 11, 노드 2는 12, 노드 3은 13이 할당됩니다. 다음 단계에서 컨테이너가 생성되면 Kubernetes는 컨테이너에 대한 네트워크 네임스페이스를 생성합니다. 이들 간의 통신을 가능하게 하기 위해, 우리는 이러한 네임스페이스를 네트워크에 연결한다. 하지만 어떤 네트워크일까요? 네임스페이스를 연결하기 위해 노드 내에 생성할 수 있는 브리지 네트워크에 대해 배웠습니다. 그래서 우리는 각 노드에 브리지 네트워크를 만들고 그들을 불러옵니다.
브리지 인터페이스 또는 네트워크에 IP 주소를 할당할 때입니다. 그런데 IP 주소가 뭐죠? 우리는 각 브리지 네트워크가 자체 서브넷에 있을 것이라고 결정한다. 개인 주소 범위(예: 10.244.1, 10.244.1 및 10.244.3)를 선택합니다. 다음으로 브리지 인터페이스의 IP 주소를 설정합니다.
나머지 단계는 새 컨테이너가 생성될 때마다 각 컨테이너에 대해 수행됩니다. 그래서 우리는 그것을 위한 스크립트를 작성합니다. 이제 복잡한 스크립팅을 알 필요가 없습니다. 이 파일은 앞으로 사용할 모든 커맨드가 포함된 파일이며, 앞으로 각 컨테이너에 대해 여러 번 실행할 수 있습니다.
컨테이너를 네트워크에 연결하려면 파이프 또는 가상 네트워크 케이블이 필요합니다. ip link add 커맨드를 사용하여 생성합니다. 옵션에 집중하지 마세요. 이전 강의에서 본 것과 비슷하니까요. 입력에 따라 다르다고 가정합니다. 그런 다음 ip link set 커맨드를 사용하여 한쪽 끝을 컨테이너에 부착하고 다른 쪽 끝을 브리지에 부착합니다. 그런 다음 ip addr 커맨드를 사용하여 IP 주소를 할당하고 default 게이트웨이에 route를 추가합니다. 하지만 어떤 IP를 추가해야 할까요? 우리는 그 정보를 스스로 관리하거나 일종의 데이터베이스에 저장합니다. 현재로서는 서브넷에서 사용 가능한 IP인 10.244.1.2라고 가정합니다. 우리는 다음 강의 중 하나에서 IP 주소 관리에 대해 자세히 논의합니다. 마지막으로, 우리는 인터페이스를 불러옵니다. 그런 다음 두 번째 컨테이너에 대해 동일한 스크립트를 실행하고 해당 컨테이너를 네트워크에 연결합니다. 이제 두 컨테이너가 서로 통신할 수 있습니다. 스크립트를 다른 노드에 복사하고 스크립트를 실행하여 IP 주소를 할당하고 해당 컨테이너를 자체 내부 네트워크에 연결합니다. 그래서 우리는 과제의 첫 부분을 해결했습니다. 파드들은 모두 고유한 IP 주소를 얻으며, 각자의 노드에서 서로 통신할 수 있다. 다음 부분은 다른 노드의 다른 파드에 도달할 수 있도록 하는 것입니다. 예를 들어 10.244.1.2에 있는 Pod(노드 1)가 Pod 10.244.2.2 또는 노드 2를 ping하려고 한다고 가정합니다.
현재 첫 번째 주소는 주소 10.244.2.2가 자신의 네트워크와 다른 네트워크에 있기 때문에 주소가 어디에 있는지 알지 못합니다. 따라서 default 게이트웨이로 설정되어 있으므로 노드의 IP로 라우팅됩니다. 10.244.2.2는 노드 2의 전용 네트워크이므로 노드 1도 알 수 없습니다. 노드 1의 라우팅 테이블에 경로를 추가하여 트래픽을 10.244.2.2로 라우팅합니다. 여기서 두 번째 노드의 IP는 192.168.1.12입니다. 경로가 추가되면 blue 파드가 핑을 통과할 수 있습니다.
마찬가지로, 우리는 내부의 각 네트워크에 대한 정보를 사용하여 모든 호스트에서 다른 모든 호스트로의 route를 구성합니다. 이 간단한 설정에서는 잘 작동하지만 default 네트워크 아키텍처가 복잡해질 때는 훨씬 더 많은 configuration이 필요합니다. 각 서버에서 route를 구성할 필요가 없는 대신 네트워크에 라우터가 있는 경우 라우터에서 route를 구성하고 모든 호스트가 이를 default 게이트웨이로 사용하도록 지정하는 것이 더 나은 솔루션입니다. 이렇게 하면 라우터의 라우팅 테이블에 있는 모든 네트워크에 대한 경로를 쉽게 관리할 수 있습니다. 이를 통해 각 노드에서 주소가 10.244.1.0/24인 개별 가상 네트워크가 이제 주소가 10.244.0.0/16인 단일 대규모 네트워크를 형성합니다.
정리해봅시다. 브리지 네트워크와 라우팅 테이블을 사용하여 환경을 준비하기 위해 여러 가지 수동 단계를 수행했습니다. 그런 다음 각 컨테이너를 네트워크에 연결하는 데 필요한 단계를 수행하는 각 컨테이너에 대해 실행할 수 있는 스크립트를 작성하고 스크립트를 수동으로 실행했습니다. 물론, 매분 수천 개의 파드가 생성되는 대규모 환경에서와 같이, 우리는 그렇게 하고 싶지 않습니다. 그렇다면 쿠버네티스에서 파드이 생성될 때 어떻게 자동으로 스크립트를 실행할 수 있을까요? 거기서 중간자 역할을 하는 CNI가 나옵니다.
CNI는 컨테이너를 생성하는 즉시 스크립트를 호출하는 방법을 Kubernetes에 알려줍니다. 그리고 CNI는 우리에게 당신의 스크립트가 이렇게 보여야 한다고 말합니다. 그래서 우리는 CNI 기준에 맞게 스크립트를 조금 수정해야 합니다. 네트워크에 컨테이너를 추가하는 추가 섹션과 네트워크에서 컨테이너 인터페이스를 삭제하고 IP 주소를 해제하는 삭제 섹션이 있어야 합니다.
이렇게 스크립트가 준비되었습니다. 각 노드의 kubelet은 컨테이너 생성을 담당합니다. 컨테이너가 생성될 때마다 kubelet은 CNI configuration을 보고 실행 시 커맨드라인 arguments로 전달되며 스크립트의 이름을 식별합니다. 그런 다음 CNI의 bin 디렉토리를 검색하여 스크립트를 찾은 다음 add 커맨드과 컨테이너의 이름 및 네임스페이스 ID로 스크립트를 실행합니다. 그리고 나머지는 우리 스크립트가 알아서 합니다.
CNI in Kubernetes
이 강의에서는 Kubernetes의 CNI에 대해 논의할 것입니다. prerequisite 강의에서는 네트워크 네임스페이스의 완전 기초 부터 시작했습니다. 그리고 우리는 도커에서 그것이 어떻게 이루어지는지 보았습니다. 그런 다음 네트워킹 컨테이너에 대한 표준이 필요한 이유와, 컨테이너 네트워크 인터페이스가 어떻게 나오게 되었는지에 대해 논의했습니다. 그리고 CNI에서 사용할 수 있는 지원되는 플러그인 목록을 살펴보았습니다.
이 강의에서는 이러한 네트워크 플러그인을 사용하도록 Kubernetes가 어떻게 구성되어 있는지 알아보겠습니다. prerequisite 강의에서 논의한 바와 같이, CNI는 CNI 컨테이너 run times에 따른 컨테이너 run times의 책임을 정의합니다.(?) 이 경우, Kubernetes는 컨테이너 네트워크 네임스페이스를 생성하고 올바른 네트워크 플러그인을 호출하여 해당 네임스페이스를 식별하고 올바른 네트워크에 연결합니다.
Configuring CNI
그렇다면 쿠버네티스가 사용할 CNI 플러그인을 어디에 지정해야 할까요? 컨테이너를 생성한 후 해당 컴포넌트가 적절한 네트워크 플러그인을 호출해야 하므로 컨테이너 생성을 담당하는 Kubernetes 내의 컴포넌트에서 CNI 플러그인을 호출해야 합니다. CNI 플러그인은 클러스터의 각 노드에 있는 kubelet.service에서 구성됩니다. kubelet.service 파일을 보면 네트워크 플러그인이라는 옵션이 CNI로 설정된 것을 볼 수 있습니다.
View Kubelet Options
실행 중인 kubelet.service를 보아도 동일한 정보를 볼 수 있습니다.
네트워크 플러그인이 CNI로 설정되어 있고 CNI bin 디렉토리 및 CNI conflict 디렉토리와 같이 CNI와 관련된 몇 가지 다른 옵션을 볼 수 있습니다. CNI bin 디렉토리에는 bridge, dscp, flanel 등의 실행 파일로 지원되는 모든 CNA 플러그인이 있습니다. CNI conflict 디렉토리에는 configuration 파일 집합이 있습니다. 여기서 kubelet는 어떤 플러그인을 사용해야 하는지 알아봅니다.
이 경우 bridge configuration 파일을 찾습니다. 여기에 여러 개의 파일이 있으면 알파벳 순서로 파일을 선택합니다. bridge.conf 파일을 보시면 이렇게 나옵니다.
플러그인 configuration 파일에 대해 CNI 표준에서 정의한 형식입니다. 이름은 mynet입니다. 유형은 bridge입니다. 또한 bridging routing 및 masquerading에 대한 사전 prerequisite 강의에서 논의한 개념과 관련될 수 있는 일련의 다른 configurations이 있습니다. isGateway는 브리지 네트워크가 게이트웨이 역할을 할 수 있도록 IP 주소를 할당받아야 하는지 여부를 정의합니다. ipMasq은 IP 위장을 위해 NAT rule을 추가해야 하는지 여부를 정의합니다. ipam 섹션은 IPAM configuration을 정의합니다. 여기서 파드 및 필요한 로드에 할당할 서브넷 또는 IP 주소 범위를 지정합니다. host local 유형은 IP 주소가 DSCP 서버와 달리 이 호스트에서 로컬로 관리되고 원격으로 유지 관리됨을 나타냅니다. 유형을 DSCP로 설정하여 외부 DHCP 서버를 구성할 수도 있습니다.
CNI weave
이 강의에서 우리는 CNI, 특히 Weaveworks를 기반으로 한 하나의 솔루션에 대해 논의할 것입니다. Weaveworks는 CNI 플러그인과 함께 작동합니다. 이전 연습 테스트에서는 구성 방식을 확인했습니다. 이제 우리는 그것이 어떻게 작동하는지에 대해 더 자세히 볼 것입니다.
파드 네트워킹 개념 섹션에서 우리가 중단한 부분부터 시작하겠습니다. 우리는 자체적으로 CNI 스크립트를 구축하고 CNI를 통해 kubelet에 통합했습니다. 이전 강의에서는 자체 custom 스크립트 대신 Weave 플러그인을 통합하는 방법을 보았습니다. 이제 Weave 솔루션이 어떻게 작동하는지 알아보겠습니다. 하나 이상의 솔루션을 잘 이해하는 것이 중요하기 때문입니다. 그러면 이 문제를 다른 솔루션과도 연결할 수 있습니다. 따라서 수동으로 설정한 네트워킹 솔루션에는 어떤 네트워크가 어떤 호스트에 있는지 매핑하는 라우팅 테이블이 있었습니다. 패킷이 한 파드에서 다른 파드로 전송될 때, 패킷은 네트워크, 라우터로 전송되고 그 파드를 호스트하는 노드로 전송됩니다.
이는 소규모 환경과 단순한 네트워크에서 작동하지만 클러스터에 수백 개의 노드가 있고 각 노드에 수백 개의 파드가 있는 대규모 환경에서는 실용적이지 않습니다. 라우팅 테이블은 너무 많은 항목을 지원하지 않을 수 있으므로 창의적으로 다른 솔루션을 찾아야 합니다. Kubernetes 클러스터를 우리 회사로, 노드를 서로 다른 사무실 사이트로 생각해봅시다.
사이트마다 부서가 다르고 부서마다 사무실이 다릅니다. 1번 사무실에 있는 누군가가 3번 사무실로 소포를 보내서 사무실 직원에게 넘기길 원합니다. 그가 아는 것은 그것이 3번 사무실로 가야 한다는 것이고, 그는 그것이 누구에게 어떻게 운반되는지 신경 쓰지 않습니다. 사무실 직원은 소포를 들고, 차에 올라타서 GPS로 대상 사무실의 주소를 보고, 길을 안내받고, 목적지로 가는 길을 찾아서, 급여 부서에 소포를 전달하고, 그 다음에 3번 사무실로 소포를 전달합니다. 이것은 현재로서는 아주 잘 작동합니다. 이것을 다른 지역이나 국가로 확장하면 이 과정은 더 이상 작동하지 않습니다. 사무실 직원이 여러 나라에 걸쳐 이렇게 많은 사무실로 가는 많은 route를 추적하는 것은 어려운 일이며, 물론 그는 혼자서 이 사무실로 운전해서 갈 수도 없습니다. 그래서 우리는 모든 우편 및 배송 활동을 가장 잘 하는 회사에 아웃소싱하기로 결정했습니다.
일단 운송 회사가 계약되면, 그들이 가장 먼저 하는 일은 그들의 에이전트들을 우리 회사의 각 사이트에 배치하는 것입니다. 이러한 에이전트는 사이트 간의 모든 배송 작업을 관리합니다. 그들은 또한 서로 계속 이야기하고 잘 연결되어 있습니다. 그래서 그들은 서로의 사이트, 그 안에 있는 부서, 그리고 그 안에 있는 사무실에 대해 모두 알고 있습니다. 그래서 10번 사무실에서 3번 사무실로 소포를 보내면, 그 사이트의 운송업자가 소포를 가로채서 대상 사무실 이름을 봅니다. 그는 다른 사이트의 동료들과의 작은 내부 네트워크를 통해 그 사무실이 어느 사이트와 부서에 있는지 정확히 알고 나서, 대상 사이트의 위치에 목적지 주소가 설정된 자신의 새 패키지에 이 패키지를 넣은 다음 패키지를 통해 보냅니다. 패키지가 해당 사이트의 에이전트에 의해 다시 차단되는 대상에 도착하면, 그는 패킷을 열고 원래 패킷을 검색하여 올바른 부서로 전달합니다.
Weeve CNI 플러그인이 클러스터에 배포되는 원래 세계로 돌아갑니다.
각 노드에 에이전트 또는 서비스를 배포합니다. 이들은 서로 통신하여 노드와 노드 내의 네트워크 및 파드에 대한 정보를 교환합니다. 각 에이전트 또는 피어는 다른 노드에서 파드와 자신의 IP를 알 수 있는 방식으로 전체 설정을(별도로) 저장합니다. 위브는 노드와 이름에 자체 브리지를 만듭니다. 위브는 각 네트워크에 IP 주소를 할당합니다. 여기에 표시된 IP는 예시일 뿐입니다.
다가오는 연습에서 위브가 각 노드에 할당하는 IP 주소의 정확한 범위를 파악할 것입니다. 우리는 다음 강의에서 IP 주소 관리와 IP 주소가 파드과 컨테이너에 어떻게 분배되는지에 대해 이야기할 것입니다. 하나의 파드가 여러 브리지 네트워크에 연결될 수 있음을 기억하세요. 예를 들어, Docker에서 만든 Docker Bridge 뿐만 아니라 Weave Bridge에도 파드를 부착할 수 있습니다. 패킷이 대상에 도달하기 위해 사용하는 경로는 컨테이너에 config된 경로에 따라 다릅니다. 파드가 에이전트에 도달하도록 config된 올바른 경로를 확보하고 에이전트가 다른 파드를 처리하도록 했습니다. 이제 패킷이 한 파드에서 다른 노드의 다른 파드로 전송되면 위브는 패킷을 가로채고 별도의 네트워크에 있음을 식별합니다. 그런 다음 이 패킷을 새 소스 및 대상이 있는 새 패킷으로 캡슐화하고 네트워크를 통해 전송합니다. 반대쪽에 있는 다른 위브 에이전트는 패킷을 검색하여 캡슐을 해제하고 패킷을 오른쪽 파드로 라우팅합니다.
Deploy Weave
그렇다면 어떻게 Kubernetes 클러스터에 Weave를 배포할 수 있을까요? Weave 와 weave peers는 수동으로 클러스터의 각 노드에 서비스 또는 데몬으로 배포할 수 있으며, 쿠버네티스가 이미 설정되어 있는 경우, 클러스터의 파드로 배포하는 것이 더 쉬운 방법입니다. base Kubernetes 시스템이 노드로 준비되고 노드와 basic 컨트롤 플레인 컴포넌트 사이에 올바르게 구성된 네트워킹이 배포되면 단일 kubectl apply 커맨드로 클러스터에 Weeve를 배포할 수 있습니다.
이렇게 하면 Weeve에 필요한 모든 컴포넌트가 클러스터에 배포됩니다. 가장 중요한 것은 위브 피어가 데몬 세트로 배포된다는 것입니다. 데몬 세트는 지정된 kind의 한 부분이 클러스터의 모든 노드에 배포되도록 합니다. 이것은 Weave peer들에게 완벽하게 작동합니다.
kubeadm 도구와 Weeve 플러그인을 사용하여 클러스터를 배포한 경우, Weeve 피어를 각 노드에 배포된 부품으로 볼 수 있습니다. 문제 해결을 위해 kube control logs 커맨드를 사용하여 로그를 봅니다.
테스트 문제 기록
Inspect the kubelet service and identify the container runtime endpoint value is set for Kubernetes.
What is the path configured with all binaries of CNI supported plugins?
/opt/cni/bin
What is the CNI plugin configured to be used on this kubernetes cluster?
ls /etc/cni/net.d/
