[IBM Cloud 강의번역 프로젝트] - ch2-2. Kubernetes Architecture

IBM Cloud 1기 활동 - 강의번역 프로젝트.

원본 강의

cognitiveclass.ai/courses/kubernetes-course

Kubernetes and containers on IBM Cloud - Free Kubernetes course by IBM Cognitive Class

강의의 한글자막 제공을 위해 srt 파일로 번역하는 프로젝트를 진행 중입니다.

문맥이 어색하거나 내용이 잘못되었다고 느껴지시면 댓글로 남겨주세요.

---

 

 

이 비디오에서는 Kubernetes 시스템의 아키텍처에 대해 알아봅니다.

 

 

Kubernetes 공식 문서에 있는 이 다이어그램은 Kubernetes의 주요 구성요소를 강조합니다. Kubernetes의 개별 배포단위를 "클러스터"라고 합니다.

 

다이어그램의 왼쪽은 Control plane입니다. 클러스터에 관련된 결정을 내리고 클러스터에서 발생하는 이벤트를 감지하고 응답하는 역할을 합니다.

• Control Plane에서 내리는 결정의 예는 워크로드 스케줄링입니다.
• 이벤트에 응답하는 예는 애플리케이션이 배포되었을 때 새 리소스를 생성하는 것입니다.

Control Plane은 몇 가지 구성요소로 이루어져 있습니다.

 

첫 번째로는 Kubernetes API 서버입니다. 클러스터의 모든 통신은 이 API를 사용합니다.

예컨대 Kubernetes API 서버는 클러스터의 상태를 조회하거나 상태를 변경하라는 명령어를 입력받습니다.

 

 

 

다음은 Etcd로, 클러스터의 모든 데이터를 저장하는 가용성 높은 key-value 저장소입니다. Kubernetes으로 애플리케이션을 배포하면, 배포에 관련된 모든 구성사항은 etcd에 저장됩니다. 따라서 Etcd는 클러스터의 상태를 저장하는 진실의 보고이며, Kubernetes는 클러스터의 상태가 etcd에 저장된 상태와 일치하도록 작동합니다.

 

 

Kubernetes 스케줄러는 새로 생성된 Pods을 노드에 할당합니다. 이는, 워크로드가 클러스터 내 어디에서 실행되어야 하는지를 스케줄러가 결정한다는 의미입니다. Pods와 노드는 곧 배우게 될 것입니다.

 

Kubernetes 컨트롤러 관리자는 클러스터의 상태를 확인하고, 현재 클러스터의 상태가 원하는 클러스터 상태와 일치하도록 하는 컨트롤러 프로세스를 실행합니다. 컨트롤러에 대해서도 곧 다룰 것입니다.

 

마지막으로, 클라우드 컨트롤러 관리자는 기반에 있는 클라우드 서비스 제공자와 상호작용할 수 있는 컨트롤러를 실행합니다. 이 컨트롤러는 클러스터와 클라우드 서비스 제공자의 API를 연결해 줍니다.

 

Kubernetes는 본질적으로 오픈 소스 소프트웨어이므로, 다양한 조직과 클라우드 서비스 제공자가 사용을 지원하는 것이 이상적인 그림입니다. 따라서 Kubernetes 자체는 특정 클라우드 서비스에 구애받지 않도록 노력하고 있습니다. 클라우드 컨트롤러 관리자는 Kubernetes와 클라우드 서비스 제공자 모두가 다른 의존성 없이 성공적으로 발전할 수 있도록 하는 역할입니다.

 

지금까지가 Control Plane의 내용이었습니다. 이제 오른쪽으로 넘어가서, worker 노드에 관련된 내용을 보겠습니다.

 

 

 

노드는 Kubernetes 클러스터에 있는 worker 머신입니다. 즉, 사용자의 애플리케이션은 노드에서 실행됩니다. 노드는 가상머신일 수도, 실제 머신일 수도 있습니다. 각각의 노드는 Control Planed이 관리하며, Pods를 실행할 수 있습니다. Pods는 다음 강의에서 더 자세히 배우게 됩니다.

 

노드는 Kubernetes가 생성하는 게 아니라, 클라우드 서비스 제공자가 생성합니다. 이 특징 때문에, Kubernetes는 다양한 인프라에서 실행될 수 있습니다. 노드는 Control Plane이 제어합니다.

 

노드가 Pods를 실행할 수 있도록 하는, 노드의 몇 가지 구성요소들이 있습니다.

 

첫 번째는 가장 중요한 구성 요소 인 "kubelet"입니다. kubelet은 Kubernetes API 서버와 통신해서 새 Pod 정보를 받아옵니다. 그리고 해당 Pods와 관련 컨테이너들이 의도한 대로 작동하는지 확인합니다. Control Plane에 상태를 보고하는 일도 담당합니다.

 

 

Kubelet은 Pod을 시작하기 위해 Container runtime을 사용합니다. Container runtime은 이미지를 다운받고, 컨테이너를 실행하는 역할을 합니다. 단일 Container runtime을 제공하는 대신, Kubernetes는 Container runtime과 착탈식으로 연결할 수 있는 인터페이스를 제공합니다. 도커가 가장 유명한 runtime이고, rkt나 CRI-O도 자주 쓰이는 Container runtime입니다.

 

 

 

마지막으로 Kubernetes proxy는 클러스터 내 각각의 노드에서 실행되는 네트워크 프록시입니다. 이 프록시는 노드에서 실행되는 Pods의 통신 - 다시 말해, 클러스터에서 실행되는 워크로드 간 통신 - 을 통제합니다. 이런 통신은 클러스터 내부 또는 외부에서 발생할 수 있습니다.

 

 

 

지금까지 컨트롤러를 몇 번 언급했습니다. 컨트롤러의 역할은 현재 상태가 원하는 상태와 일치하도록 만드는 것이었습니다. 보다 쉽게 이해하기 위해, Kubernetes 공식 문서는 다음과 같은 훌륭한 정의와 비유를 들었습니다. Control loop는 시스템 상태를 통제하는 무한 루프입니다. 온도 조절기에 비유할 수 있습니다. 온도 조절기에서, 원하는 온도를 세팅하는 것처럼요. 예컨대 70°F로 설정했다면, 방에 설치된 온도 조절기는 실제 상태를 (방의 온도) 원하는 상태에 근접하도록 (온도 조절기에 설정된 온도) 끊임없이 동작하는 것과 같습니다. Kubernetes의 컨트롤러도 이와 같습니다. Kubernetes 클러스터의 상태를 관찰하고, 현재 상태가 목표한 상태에 도달하도록 작업하는 것이죠.

 

 

 

일반적으로, 컨트롤러는 현재 상태와 원하는 상태를 맞추는 작업을 시작하기 위해 API 서버에 메시지를 보냅니다. 또한 Kubernetes 컨트롤러는 Kubernetes 객체를 추적합니다.

 

만약 세 개의 애플리케이션 인스턴스가 Kubernetes에서 실행되도록 설정했다면, 컨트롤러는 클러스터의 상태를 확인하고, 제약조건 하에서 세 개의 인스턴스가 어느 때라도 정상적으로 작동할 수 있도록 최선을 다합니다. Kubernetes 객체와 컨트롤러에 관해서는 다음 강의에서 더 자세히 알아봅니다.

 

 

이제 여러분은 Kubernetes 클러스터의 아키텍처에 어느 정도 익숙해졌을 것입니다. 여러 개의 구성요소로 이루어진 Control Plane은 클러스터에 관련된 전역 결정을 내리는 역할을 합니다. 또한, Kubernetes의 중요한 구성요소를 실행하는 노드가 있고 사용자가 배포한 워크로드를 클러스터에서 수행하는 노드가 있다는 것을 배웠습니다. 마지막으로, 컨트롤러가 무엇이며 Kubernetes가 최적 상태를 찾아가기 위해 컨트롤러를 어떻게 사용하는지 보았습니다. 다음 강의에서는 Kubernetes 객체가 무엇인지, 클러스터에서 생성되는 리소스에는 어떤 것들이 있는지 보겠습니다.