[IBM Cloud 강의번역 프로젝트] - ch3-1. ReplicaSet

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

원본 강의

cognitiveclass.ai/courses/kubernetes-course

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

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

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

---

이 모듈에서는 Kubernetes 애플리케이션을 관리하는 핵심 기능을 알아볼 것입니다. ReplicaSets, AutoScaling, Rolling updates, ConfigMaps, secrets와 Service bindings 과 같은 개념을 말이죠.

 

 

이번 강의에서는 빨간 상자에 강조표시된 ReplicaSet을 다루겠습니다.

ReplicaSet은 애플리케이션의 수요가 증가할 때, 수요에 맞추어 애플리케이션을 확장할 수 있게 해줍니다. 시작합니다!

 

 

ReplicaSet이란 무엇일까요? 필요한 만큼의 pod가 항상 실행될 수 있도록 pod을 관리하는 역할을 합니다. 즉, 필요한 만큼 pod을 추가하거나 삭제할 수 있다는 것입니다. ReplicaSet은 pod을 복제하고, 재시작하며, 실행되던 pod에 문제가 있을 경우 재가동합니다. ReplicaSet은 기존 pod을 선택해서 배포하거나, 여분의 pod이 없으면 생성한 뒤 배포합니다.

 

Kubernetes API에 pod 목록을 요청한 뒤 라벨 값으로 필터링합니다. ReplicaSet은 ReplicationController를 대체하는 역할이므로, ReplicationController 대신 사용해야 합니다. IBM Cloud Kubernetes Service는 클러스터를 배포하려 할 경우 ReplicaSet을 생성합니다.

 

Kubernetes의 주요 설계철학 중 하나는 각각의 객체가 독립성을 지녀야 한다는 것입니다.

낮은 결합력이라는 철학을 위해, ReplicaSet은 pod을 소유하지 않습니다. 목표 상태값을 맞추기 위해 배포를 해야 할 때에는, pod의 라벨값을 토대로 필요한 pod을 찾아냅니다. yaml 파일에 있는 template metedata에 생성하거나 삭제할 pod 후보군의 라벨값이 정의되어 있습니다.

 

 

그러면, ReplicaSet은 어떻게 만들어야 할까요? 우선, Deployment를 생성할 때 자동으로 하나 만들어집니다. 이전 강의에서, "hello-Kubernetes"라는 Deployment를 생성했습니다. 표시된 "get replicaset" 명령어를 실행하면, "hello-Kubernetes-랜덤한 숫자" 형태로 자동으로 생성된 ReplicaSet을 확인할 수 있습니다.

 

현재는 한 개의 pod를 복제하고 있지만, 곧 바꿔볼 예정입니다. describe 명령어를 사용하면, 동일한 ReplicaSet이 이 pod을 "컨트롤하고" 있는 걸 확인할 수 있습니다. 앞서 설명했듯, pod의 라벨값을 활용해 낮은 결합력을 구현한 모습입니다.

 

 

처음부터 새로 만들려면, yaml 파일의 kind 항목에 ReplicaSet을 입력하면 됩니다. ReplicaSet의 개수가 1로 정의된 걸 확인할 수 있습니다. 따라서 이 경우 pod가 한 개 생성됩니다. replica 개수를 따로 정의하지 않으면 기본적으로 한 개가 생성됩니다. 물론 Deployment를 생성하지 않고도 ReplicaSet을 생성할 수 있지만, Deployment를 생성하는 편이 더 좋습니다. Deployment는 곧 살펴볼 몇 가지 추가 기능을 제공하기 때문입니다. kubectl은 ReplicaSet의 축약 표현으로 'rs' 를 사용합니다. 굳이 단어를 전부 입력할 필요는 없으니까요.

 

 

 

 

이미 Deployment가 있고 확장을 하고 싶다면, 'scale' 명령어를 사용하면 됩니다.

• 첫 번째 명령어는 Deployment를 생성합니다.
• 두 번째 명령어로는 생성된 pod을 조회합니다. "hello-Kubernetes-임의의 긴 숫자" 형태의 pod을 확인할 수 있습니다.
• 세 번째 명령어는 "hello-Kubernetes" Deployment를 조회합니다.
• 네 번째 명령어는 replicas 설정을 3으로 변경하는 명령어입니다.

다시 get pods 명령어를 실행하면, 세 개의 pod이 실행되고 있는 걸 확인할 수 있습니다. Deployment가 생성한 ReplicaSet이 두 개의 pod을 추가로 만든 거죠. 하나는 "flw"로 끝나는 이름이고, 다른 하나는 "b7v"로 끝나는 이름을 가지고 있습니다.

 

 

 

ReplicaSet이 의도한 대로 작동하는지 어떻게 확인할 수 있을까요? IKS(IBM Kubernetes Service)가 제대로 역할을 하고 있다고 그저 믿을 수도 있겠죠. 확인하는 방법 중 하나는, pod 하나를 삭제한 뒤 무슨 일이 일어나는지 보는 것입니다. 앞의 예시에서, ReplicaSet이 세 개의 pod을 관리하고 있었습니다. 세 개 전부 나열한 다음, 하나를 삭제해 보겠습니다. 보시다시피 "flw"로 끝나는 pod이 삭제되었고, 동시에 ReplicaSet은 "w4r"로 끝나는 새로운 pod을 하나 생성했습니다. pod 개수는 다시 3이 되었습니다.

 

 

 

정리해 봅시다. 이전까지는 애플리케이션을 확장하거나 중단해야 할 때 몇 가지 문제점이 있다는 걸 배웠었습니다. 특히, 트래픽이 갑자기 폭증하거나 크래시로 애플리케이션이 중단되었을 때 애플리케이션이 대응하지 못한다는 점을 보았습니다. 따라서 ReplicaSet을 활용해 복제본을 생성하는 방식으로 애플리케이션을 확장하고 배포했습니다. 다음 강의에서는 이런 애플리케이션 확장을 동적으로 조절하는 방법을 배우겠습니다. 고정된 숫자를 하드코딩하는 방식이 아니라, pod을 동적으로 배포하는 법을 다룰 예정입니다. 곧 뵙겠습니다!