[IBM Cloud 강의번역 프로젝트] - ch2-4. Basic Kubernetes Objects

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

원본 강의

cognitiveclass.ai/courses/kubernetes-course

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

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

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

---

 

 

지금까지 Kubernetes 객체가 무엇인지 관련된 개념들과 함께 설명했습니다. kubernetes에서 사용 가능한 기본 객체들을 알아보겠습니다.

 

첫 번째 객체는 Pod입니다. Kubernetes에 배포할 수 있는 가장 간단한 단위입니다. Pod는 클러스터에서 실행되는 하나의 프로세스를 의미합니다; 또는 클러스터에서 애플리케이션이 실행되는 인스턴스 하나를 뜻합니다. 보통 Pod는 컨테이너 하나를 래핑하지만, 리소스를 공유하며 강하게 결합해 있는 여러 개의 컨테이너를 캡슐화하기도 합니다. 여러 개의 컨테이너를 캡슐화하는 건 수준 높은 예시입니다. 일반적으로, Pod는 단일 컨테이너의 래퍼로 간주하는 편입니다.

 

Pod가 애플리케이션의 단일 인스턴스를 의미하므로, Pod의 복제본을 만드는 건 애플리케이션을 수평적으로 확장하는 것과 같습니다. Kubernetes 아키텍처에서 설명했던 것처럼, Pod에 있는 컨테이너를 실행하려면 container runtime이 필요합니다. kubectl CLI로 객체를 생성하려면, 생성할 객체의 내용을 정의한 yaml 파일이 필요합니다.

 

간단한 Pod를 정의한 yaml 파일의 예시를 보겠습니다. 예시 파일에 있는 필드를 설명하자면, kind 필드는 말 그대로, 생성할 객체의 종류를 지정합니다. 이 경우 Pod를 생성합니다. 다음 필드는 spec입니다. 이 필드는 어떤 종류의 객체를 만들 것인지 구분하는 부분이므로, 정의할 객체에 맞는 적절한 필드값을 입력해야 합니다. 이 경우, Pod를 실행할 컨테이너를 정의했습니다. Pod spec에서는 최소한 하나의 컨테이너 설정이 필요합니다. 물론 여러 개의 컨테이너를 설정할 수도 있지만, 보통은 하나를 설정합니다.

 

컨테이너의 name 필드를 보면, nginx라고 쓰여 있습니다. image 필드는 어떤 종류의 이미지를 pod에서 실행할 것인지 명시합니다. IBM Cloud Container Registry 같은 비공개 레포지토리를 사용할 경우, 도메인과 레포지토리 이름, 태그가 포함되는 만큼 이미지 필드 내용이 길어질 수 있습니다. 마지막으로, ports는 컨테이너가 외부에 노출할 포트 번호들을 의미합니다.

 

 

다음으로 소개할 객체는 ReplicaSet입니다. 이름에서 알 수 있듯, ReplicaSet은 동일한 Pods의 그룹입니다. Pod의 복제본을 실행하여 애플리케이션을 수평적으로 확장할 수 있다고 언급했던 바 있습니다. 이 작업을 수행하는 객체가 ReplicaSet입니다. ReplicaSet을 생성하려면, Pod 한 개를 정의하기 위한 필드명에 비해 몇 가지 값이 다릅니다.

 

ReplicaSet을 생성해야 하므로 kind 필드명이 ReplicaSet으로 바뀝니다. ReplicaSet은 Pod와 다르기 때문에, 객체에 정의할 spec도 필요한 필드값이 다릅니다. 여기서 가장 중요한 필드는 "replicas" 필드입니다. 정의한 Pod의 복제본을 몇 개 만들어 구동할 것인지 정의하는 필드입니다. 이 필드가 수정되면, ReplicaSet은 이 필드에서 정의한 값에 맞추어 Pod를 생성하거나 삭제합니다.

 

template 필드도 ReplicaSet에서 설정합니다. 이 필드는 ReplicaSet에서 생성할 Pod 개수를 정의하기 때문에 매우 중요한 필드입니다. replica의 개수를 변경하면, 변경된 개수만큼 Pods을 어떻게 생성할 것인지 이 필드의 값을 토대로 결정합니다. 예시의 경우, ReplicaSet에서 Pod의 정의내용을 캡슐화하고 복제에 필요한 정보를 추가했습니다.

 

마지막으로 설명할 필드는 selector입니다. 지난 강의에서 레이블은 고유성이 없으며, 선택자는 Kubernetes 그룹핑 기능의 핵심 요소였다고 설명했습니다. 레이블과 선택자가 어떻게 사용되는지 예시를 통해 볼 수 있습니다. 레이블은 ReplicaSet에 있는 Pod의 식별자를 입력하는 필드입니다. 간단히 말해, ReplicaSet이 생성한 Pods는 ReplicaSet의 참조값을 가지고 있습니다. 이 연결은 Pods의 상태 관련해서 필요한 정보를 ReplicaSet에 전달합니다. 레이블의 matchLabels 필드는 template 필드의 label값과 동일합니다. 둘 다 "app : nginx"입니다.

 

하지만, ReplicaSet을 직접 생성하는 방식은 추천하지 않습니다. 대신, ReplicaSet을 관리하는 더 추상화된 개념인 Deployment 객체가 관리하기 쉽고, 더 많은 기능을 제공합니다. 따라서 보통은 Deployment 객체를 사용자가 직접 생성합니다. 사실, 사용자가 ReplicaSet을 직접 조정하는 경우는 거의 없고, Deployment 객체가 대신 작업합니다. 그래도 ReplicaSet을 이해하면, 복제본이 어떻게 만들어지는지 알 수 있으므로, ReplicaSet 객체가 등장했을 때 금방 이해할 수 있을 것입니다.

 

Deployment 객체는 Pods와 ReplicaSet의 업데이트를 제공합니다. Deployment 객체는 ReplicaSet을 생성하고, ReplicaSet를 관리하며 애플리케이션의 복제본 여러 개를 실행하는 객체입니다. 특히, stateless한 애플리케이션을 다룰 때 효과적입니다. 그 외에도 다양한 상황에서 사용할 수 있습니다. 복제된 애플리케이션을 배포하거나, Deployment 객체가 관리하는 Pod을 업데이트하거나, 애플리케이션을 확장할 때 사용할 수 있습니다.

 

강의 슬라이드 오른쪽에 있는 Deployment 명세를 보면 특이한 점이 하나 있습니다. 간단한 이름 변경을 빼면, 정의 사항이 ReplicaSet과 동일합니다. 물론, Deployment와 ReplicaSet의 정의가 항상 동일하다는 것은 아닙니다; Deployment가 더 강력하고, 추가 개체를 제공합니다. 이 예시처럼 최소한의 설정만 놓고 보면, Deployment와 ReplicaSet이 동일한 것처럼 보일 수 있습니다.

 

kind 필드는 Deployment로 바뀌었습니다. 하지만 replicas의 개수, 생성할 Pods을 식별하기 위한 선택자와 Pod 템플릿은 동일합니다. 모두 ReplicaSet에서 다뤘던 개념들입니다. replicas 필드는 Deployment 객체에서 복제본을 생성하라는 의미이며, ReplicaSet이 생성됩니다.

Deployment에서는 제공하지만 ReplicaSet에서는 제공하지 않는 기능 중 하나가 무중단 배포 기능입니다. ReplicaSet은 단일 Pod 템플릿만을 지원합니다; 만약 애플리케이션의 새 버전을 배포하고 싶다면, Pod 템플릿을 정의한 새 Deployment 객체를 생성해야 합니다. 무중단 배포는 애플리케이션의 새 버전으로 복제본을 업데이트하고, 오래된 버전의 복제본 개수를 0으로 만듭니다. 따라서 ReplicaSet은 Pods의 개수를 관리하고 필요한 개수만큼의 Pods를 유지하도록 관리한다면, Deployment는 애플리케이션이 새로운 버전으로 무중단 배포될 수 있도록 조율하는 역할을 합니다.

 

이번 강의에서는 Kubernetes의 최소 단위인 Pods를 배웠습니다. 또한 ReplicaSet이 어떻게 Pods의 개수를 유지하는지, 애플리케이션을 어떻게 확장하는지 배웠습니다. 그리고 Deployment가 ReplicaSet보다 더 높은 수준의 구성이며, ReplicaSet과 Pods의 업데이트를 지원한다는 사실을 배웠습니다. 다음 강의에서는 Kubernetes의 CLI인 "kubectl"을 어떻게 사용하는지를 다루겠습니다.