Udemy CKA 강의 정리 211: CNI weave

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이 강의에서 우리는 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 커맨드를 사용하여 로그를 봅니다.