소개

30대 미경험에서 엔지니어를 목표로 공부중인 YN이라고 합니다.
인프라 초학자의 저이지만, Kubernetes the hard way를 진행함에 있어서, 인프라에 관한 기본적인 지식을 체계적으로 배울 수 있었습니다.
거기서, 초학자 시선에서의 배움등을 본 기사에 정리해 두고 싶습니다.

목차

여기를 참조하십시오.

전체 이미지 이해

LAN 구성

Vagrant를 사용하여 온프레 환경에 5개의 Ubuntu 인스턴스를 시작합니다.
우분투 인스턴스와 LAN 구성은 다음과 같습니다.

클러스터 구성 요소 구성

API-server 나 kubelet 등의 kube-system 컴퍼넌트는 Pod 를 사용하는 것이 일반적입니다만, 이번은 systemdのservice 로서 쓰는 노드에 배치합니다. 반면에 core-DNS 또는 Weave와 같은 추가 기능은 Pod로 배치됩니다.

master 노드가 2개 있으므로 각 API-server에 대한 액세스는 HA-proxy에서 로드 밸런스됩니다. etcd 또한 두 가지가 있지만 클러스터링하여 한 쪽을 read replica 방식으로 동작시켜 중복을 수행합니다. 또한 scheduler 및 controller-manager의 경우 한쪽만 리더로 실행하고 있습니다.
(※ Pod 가 아니고 systemd 로 가동시키고 있기 때문에, 정말로 리더만이 움직이고 있는지는 미확인입니다...)

반면에 작업자 노드의 경우 Pod 이름 확인을 위해 core-DNS를 사용하고 CNI로 Weave 플러그인을 사용하기 때문에 둘 다 Pod로 실행됩니다.

이것이 베스트 프랙티스인가라고 묻는다면 그래도 없는 생각이 듭니다만, github 의 내용에 준해 진행해 갑니다. Kubernetes 클러스터의 마스터 중복을 위한 모범 사례는 여기을 참조하십시오.

외부에서 Pod에 액세스

응용 프로그램 사용자 시선에서 위의 클러스터 다이어그램을 보면 Pod에 액세스하는 방법은 다음과 같습니다.
두 작업자 노드의 IP 주소 NodePort에 액세스하여 두 작업자 노드의 Pod에 액세스합니다.
여기서 주목해야 할 것은 worker-1/worker-2 중 어느 것에 액세스하더라도 어느 Pod에 액세스할지 모르겠다는 것입니다.

이것은 Weave가 노드를 가로 지르는 네트워크를 구축하고, kube-proxy가 어느 포드로 나누는지 결정하고, core-DNS에서 포드의 IP 주소를 확인한다는 협력으로 이루어집니다.

상기 네트워크에 대해서는, 아래의 기사를 알기 쉬웠습니다.

Kubernetes 네트워크 철저 해설

구성 요소 간의 협력

컴퍼넌트의 제휴에 대해서, 이번 구축하는 클러스터의 최종형을 아래 그림으로 해 보았습니다.
(※ scheduler 와 controller-manager 가, 왜 LB 가 아니고 localhost 앞으로 통신하고 있는지 확실하지 않습니다만, github 의 내용에 준해 진행해 갑니다..)