그림(참고2)
쿠버네티스는 여러 대의 물리서버(참고1, 참고5)에 걸쳐 퍼진 컨테이너들(from1:쿠버네티스의 등장배경)이 의도한 상태(desired state)를 유지하도록 만드는 도구이다(참고2). 여기서 말하는 의도된 상태가 무엇인지는 잠시 후에 이해하도록 하자.
그림(참고3)
쿠버네티스는 여러 개의 물리서버 어디에든 컨테이너가 실행되도록 돕기때문에 하나의 컴퓨터처럼 느껴진다.
컨테이너를 어느 서버에나 띄울 수 있도록 돕는 하나의 추상화 레이어처럼 작동하는 덕분에 컨테이너를 실행하는 서버가 한 개의 물리 서버에만 머물러 있을 필요가 없다는 점이 특히 재미있다(참고3). 그래서 가성비 좋은 라즈베리파이를 잔뜩 연결해두고 쿠버네티스로 묶어 슈퍼컴퓨터 클러스터를 만드는 변태들도 있다. 물론 클라우드 환경에서도 여러 개의 컴퓨팅 인스턴스를 묶어 하나의 거대한 클러스터처럼 사용할 수 있다(참고4).
컴퓨팅 인스턴스를 하나의 노드(Node)라고 한다. 만약 나의 노트북 한 대에서 쿠버네티스를 구동한다면 노드는 1개이다. 만약 AWS EC2 4개를 구매하고 이들 각각에 쿠버네티스를 설치하여 묶는다면 노드는 4개이다. 실습을 위해 로컬 컴퓨터에 가상환경 2개를 동시에 구동하고 이들 각각에 쿠버네티스를 설치하여 묶는다면 노드는 2개이다. 라즈베리파이4를 10개 구매하고 이들 각각에 VM을 2개씩 설치한 뒤 각각의 가상환경에 쿠버네티스를 설치하여 묶는다면 노드는 20개이다. 이 노드들을 쿠버네티스라는 소프트웨어를 이용해 묶은 것을 쿠버네티스 클러스터라고 부른다. 굉장히 직관적인 이름이다. 클러스터는 컨트롤 플레인(마스터)이 컨트롤한다.
컨트롤 플레인에서 내려오는 명령에 맞게 일사분란히 움직인 노드의 파드들
함선의 핸들이라고도 할 수 있는 키를 메인로고로 삼는 쿠버네티스의 이름에 걸맞게 이순신 장군의 함선에 비유를 해 보도록 하자(from2). 12척에 이르는 함선들의 클러스터에서 이순신 장군(컨트롤 플레인)은 함선(노드)들을 적절한 목적에 맞게 활용한다. 당연히 각 배들에도 각 배를 통솔하는 장군들이 있을테다. 이순신장군은 이 장군들과만 소통한다. 이 장군들에게 붙은 별명은 큐블렛(Kublet)이다.
누군가는 눈치채었겠지만 지금 이 논의에 컨테이너라는 개념이 아직 등장하지 않았다. 컨테이너 개념을 설명하기 위해서는 포드(Pod)라는 개념이 필요하다. 흔히들 포드는 쿠버네티스 환경에서의 최소단위라고 부른다. 이를 이해하기 위해 이순신 장군과 함선의 이야기를 다시 해 보자. 함선에는 사람들이 타고 있다. 함선은 수십 개의 거대한 대포를 붙이고 있다. 이 대포를 쏘려면 포를 고정하는 사람 하나, 포에 불을 지피는 사람 하나, 포에 탄환을 넣는 사람 하나, 총 세 명이 필요하다. 포를 쏘기 위한 최소 구성원 세명 중 한명이라도 없으면 포를 발사시킬 수 없을 것이다. 사람 각각을 컨테이너라고 한다면, 컨테이너 여럿이 묶여 포를 발사하는 기능을 수행할 수 있는 최소 단위가 포드이다. 이 세 가지의 역할을 하는 사람의 집합은 포드라는 단위로 묶어 다룬다면, 이들이 제각기 흩어져 다른 함선(워커 노드)에 배정되는 불상사를 막을 수 있다.
그냥 용어만 냅다 들여다보는 것은 하등 도움이 안 되지만 이제 쿠버네티스 클러스터의 구성 요소들에 대해 더욱 재미있게 이해할 수 있다. 이를 쿠버네티스 컴포넌트(참고11)라고 한다. 쿠버네티스 실행에 필수적인 컴포넌트를 제외한 것들은 애드온(참고13)이라고 부른다. 이들 중 일부는 쿠버네티스 설치 시 기본적으로 설치된다(참고12).
•
각 군함들의 장군: 큐블렛
각 군함(워커 노드)에서 일어나는 일을 관장하는 장군의 별명은 큐블렛이다.
장군(큐블렛): 장군함(컨트롤 플레인)에서 우리 배(노드)의 방향을 돌리라는 신호를 보내고 있다! 배를 돌려라!(참고6)
장군(큐블렛): 좌현(실행 중인 포드)은 계속 사격에 대비하라! 대기 중이던 포병(새로 생성되는 포드)은 모두 나와 우현에 사격을 준비하라!(참고7,8)
•
대내외 통신 대장: 큐브-API서버
이순신 장군의 몸은 열 개가 아니다. 이순신 장군이 탑승하고 있는 장군함(컨트롤 플레인)에 함께 탑승하고 있는 통신 담당자의 별명은 큐브-API서버이다(참고7).
장군(큐블렛): 이순신 장군님이 계신 함선 쪽으로 우리쪽 진영이 위험하다고 깃발을 들어 보여라! 통신대장님께서 확인하실 것이다.
통신대장(큐브-API서버): 책모(큐브-스케줄러)와 상의한 후, 그쪽(노드)에 명을 전하겠다고 하라.
조선 조정: 이순신 장군님이 계신 장군선의 통신 대장을 통해 서한을 전하라!
통신대장(큐브-API서버): 정말 이 서한이 폐하께서 보낸 것이 맞느냐? 서체가 다르지 않느냐!
조금 더 기술적으로 이야기하면, 큐브-API 서버는 사용자가 쿠버네티스 클러스터와 상호작용하는 다양한 방법 중 하나는 명령줄의 kubectl 을 이용하는 것이다. kubectl 명령어, 혹은 이를 통해 전달된 yaml/json 파일 등을 잘 읽어들이고 적절한 명령을 조달하는 일을 수행한다(참고14).
•
이외에도 다음과 같은 구성 요소들이 있고, 재미있게 풀어 설명할 수 있다.
◦
책모: 큐브-스케줄러
◦
이순신 장군: 큐브-컨트롤러-매니저(kube-controller-manager)
◦
이순신 장군의 일기장: 엣시디(etcd)(참고10)
이쯤이 되면 쿠버네티스의 각 컴포넌트들이 무섭거나 외워야 할 것으로 느껴지지 않고, 각 요소들이 어떤 역할을 가지고 임무를 수행하는 조직체의 일원들처럼 느껴질 것이다. 이런 내막을 이해하고 나면, 저마다의 명확한 역할을 가지고 쿠버네티스 클러스터에서 일어나는 다양한 일들을 제어하는 것이 컴포넌트라는 말이 이해되기 시작한다.
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료들.
이제 의도된 상태가 무엇인지 이해해볼 차례이다. … 노를 젓는 사람이 필요할수도 있잖아.
2.
“Kubernetes cluster” includes “Control-plane(master node)” and “Node(s)”
3.
Them what is control-plane?
4.
Then what is node(s)?
5.
Kubelet
6.
서비스
7.
DNS 파드
8.
KubeDNS: 서비스와 DNS파드를 관리함. it works like 수많은 컨테이너들이 서로를 찾을 때 필요한 DNS server. Even if container’s IP would be different because of running container flickering, KubeDNS automatically save ID. We don’t have to remember each container’s IPs.
•
개발 관점의 워크플로
1.
개발자가 도커파일을 작성해서 컨테이너를 업로드한다.
2.
개발자가 yaml 이나 kubectl CLI 를 이용해서 쿠버네티스의 컨트롤플레인(마스터)에게 보낸다.
3.
컨트롤플레인의 API 서버가 쿠버네티스의 요청을 받는다.
a.
API 서버는 요청에 대한 문법이 합당한지, 권한이 합당한지 등을 검사한다.
4.
API 서버는 컨테이너를 어느 위치에 배포할지 결정하는 일을 스케줄러에게 질의한다.
5.
스케줄러가 특정 노드를 API 서버에게 제안한다.
6.
어느 노드에서 실행하면 가장 좋을지 큐블렛에게 응답한다.
7.
그럼 API 서버는 특정 노드의 노드의 큐블렛에 요청을 보낸다. 큐블렛은 요청을 받고, 도커 명령으로 변경하여 도커 컨테이너를 실행한다.
◦
누군가 쿠버네티스의 본질적인 기능이라고 했었던, ‘컨테이너가 계속 떠있는지 아닌지를 지속적으로 추적하는 행위’ 는 어느 컴포넌트의 역할에 들어가는 것일까?
•
…
from : 과거의 어떤 생각이 이 생각을 만들었는가?
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는가?
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는가?
1.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되고 이어지는가?
1.
참고 : 레퍼런스