이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

이론으로 레플리카셋의 역할과 명세를 살펴보았으니, 이제 직접 레플리카셋을 생성하고 그 동작을 눈으로 확인해볼 차례입니다. 클라우드 네이티브 환경에서 리소스를 관리하는 가장 기본적인 방법은 YAML(Yet Another Markup Language) 형식의 매니페스트 파일을 작성하여 쿠버네티스 API 서버에 전달하는 것입니다. 이 실습에서는 간단한 웹 서버 컨테이너를 실행하는 레플리카셋을 YAML 파일로 정의하고, 이를 클러스터에 배포한 뒤, kubectl scale 명령어를 사용하여 파드의 수를 동적으로 조절해보겠습니다.

본 실습을 진행하기 위해서는 쿠버네티스 클러스터가 준비되어 있어야 하며, kubectl 명령어를 사용할 수 있도록 환경이 설정되어 있어야 합니다. Minikube, kind, Docker Desktop에 포함된 쿠버네티스 또는 클라우드 제공업체의 관리형 쿠버네티스 서비스(예: AWS EKS, Google GKE, Azure AKS) 어떤 것이든 괜찮습니다.

자, 그럼 레플리카셋의 강력한 기능을 직접 경험하러 떠나볼까요?

쿠버네티스에서 오브젝트를 생성하거나 관리할 때는 대부분 YAML 형식의 파일을 사용합니다. YAML은 사람이 읽고 쓰기 쉬운 데이터 직렬화 언어로, 들여쓰기를 통해 계층 구조를 표현합니다. 레플리카셋을 생성하기 위한 YAML 파일에는 앞서 “7.2.2 레플리카셋 명세 (Spec) 분석”에서 다룬 apiVersion, kind, metadata, 그리고 spec 필드가 포함되어야 합니다.

특히 spec 필드 안에는 레플리카셋의 핵심 동작을 정의하는 replicas, selector, template 필드가 정확하게 기술되어야 합니다. template 필드는 파드의 청사진 역할을 하므로, 어떤 컨테이너 이미지를 사용할지, 어떤 포트를 노출할지 등을 상세히 명시해야 합니다.

이제 간단한 Nginx 웹 서버를 2개의 복제본으로 실행하는 레플리카셋을 위한 YAML 파일을 함께 작성해 보겠습니다. 이 웹 서버 컨테이너는 80번 포트로 서비스합니다. 아래 내용을 my-replicaset.yaml과 같은 이름의 파일로 저장해 주세요. (주석을 통해 각 필드의 의미를 다시 한번 되새겨 보세요.)

위 YAML 파일을 잠시 자세히 살펴보겠습니다.

• apiVersion: apps/v1 과 kind: ReplicaSet 은 이 YAML 파일이 apps/v1 API 그룹에 속한 ReplicaSet 오브젝트를 정의한다는 것을 명시합니다.
• metadata.name 은 my-nginx-rs로 레플리카셋의 이름을 지정합니다.
• spec.replicas: 2 는 이 레플리카셋이 항상 2개의 파드 복제본을 유지하도록 설정합니다.
• spec.selector.matchLabels 에는 tier: frontend 와 app-version: “1.0” 이라는 레이블이 정의되어 있습니다. 이는 이 레플리카셋이 tier가 frontend이고 app-version이 “1.0”인 레이블을 가진 파드들을 관리 대상으로 삼겠다는 의미입니다.
• spec.template.metadata.labels 에도 tier: frontend 와 app-version: “1.0” 레이블이 동일하게 정의되어 있는 것을 반드시 확인해야 합니다. 이것이 selector와 일치하지 않으면 레플리카셋은 자신이 생성한 파드를 자신의 관리 대상으로 인식하지 못하는 심각한 문제가 발생합니다. 여기서는 추가로 project: book-example 라는 레이블도 파드에 부여했습니다.
• spec.template.spec.containers 에는 nginx-web-container 라는 이름의 컨테이너가 정의되어 있고, nginx:1.25 이미지를 사용하며 80번 포트를 노출하도록 설정되어 있습니다.

이렇게 작성된 YAML 파일은 마치 쿠버네티스에게 “이 설계도(template)를 따라서, tier: frontend, app-version: “1.0” 이름표를 단 파드를 2개(replicas) 만들어주고, 이들이 항상 2개 유지되도록 관리해줘!” 라고 요청하는 것과 같습니다.

YAML 파일 작성이 완료되었다면, 이제 kubectl apply 명령어를 사용하여 이 레플리카셋을 클러스터에 생성할 차례입니다. 터미널에서 my-replicaset.yaml 파일이 저장된 디렉토리로 이동한 후 다음 명령어를 실행합니다.

명령어가 성공적으로 실행되면 “replicaset.apps/my-nginx-rs created” 와 같은 메시지가 출력될 것입니다. 이제 레플리카셋과 파드가 정말로 생성되었는지 확인해 보겠습니다.

위 명령어를 실행하면 my-nginx-rs라는 이름의 레플리카셋이 보이고, DESIRED, CURRENT, READY 상태가 각각 2, 2, 2로 표시되는 것을 확인할 수 있습니다. 이는 우리가 replicas: 2로 설정한 대로 2개의 파드가 요청되었고(DESIRED), 현재 2개가 실행 중이며(CURRENT), 그중 2개가 요청을 받을 준비가 되었음(READY)을 의미합니다.

생성된 파드들을 직접 확인하려면 다음 명령어를 사용합니다. selector에 정의된 레이블을 사용하여 필터링할 수 있습니다.

my-nginx-rs-xxxxx 와 같은 이름 (앞부분은 레플리카셋 이름, 뒷부분은 랜덤 문자열)을 가진 2개의 파드가 Running 상태로 표시될 것입니다. 각 파드의 상세 정보를 보고 싶다면 kubectl describe pod <파드이름> 명령어를 사용하면 됩니다.

이처럼 YAML 파일을 통해 우리는 선언적으로 원하는 상태를 정의하고, 쿠버네티스는 그 상태를 달성하기 위해 필요한 작업을 수행합니다. 이것이 바로 쿠버네티스 자원 관리의 핵심 원리입니다.

앞서 YAML 파일의 replicas 필드를 통해 원하는 파드 복제본 수를 지정했습니다. 하지만 운영 중에는 트래픽 변화나 시스템 부하에 따라 파드의 수를 동적으로 조절해야 할 필요가 생깁니다. 이때마다 YAML 파일을 수정하고 kubectl apply 명령어를 다시 실행하는 것은 다소 번거로울 수 있습니다.

쿠버네티스는 이러한 상황을 위해 kubectl scale 이라는 명령어를 제공합니다. 이 명령어는 레플리카셋(또는 디플로이먼트, 스테이트풀셋 등 스케일링이 가능한 다른 컨트롤러)의 replicas 필드 값을 직접 변경하여 파드의 수를 신속하게 늘리거나 줄일 수 있게 해줍니다. kubectl scale은 YAML 파일을 직접 수정하는 것이 아니라, 쿠버네티스 API 서버에 저장된 오브젝트의 현재 상태를 변경하는 명령형(imperative) 방식입니다.

파드 수 늘리기 (스케일 아웃, Scale-Out)

현재 my-nginx-rs 레플리카셋은 2개의 파드를 실행하고 있습니다. 만약 서비스에 대한 요청이 증가하여 더 많은 처리 용량이 필요하다고 가정해봅시다. kubectl scale 명령어를 사용하여 파드의 수를 2개에서 5개로 늘려보겠습니다.

명령어 형식은 kubectl scale <오브젝트타입> <오브젝트이름> –replicas=<원하는 복제본 수> 입니다. 위 명령어를 실행하면 “replicaset.apps/my-nginx-rs scaled” 라는 메시지가 출력됩니다.

잠시 후 다시 레플리카셋과 파드의 상태를 확인해 보겠습니다.

kubectl get rs 명령의 결과에서 DESIRED와 CURRENT 값이 모두 5로 변경된 것을 확인할 수 있을 것입니다. (READY는 파드가 완전히 준비되는 데 약간의 시간이 걸릴 수 있습니다.) 또한, kubectl get pods 명령을 실행하면 총 5개의 my-nginx-rs-xxxxx 파드가 Running 또는 ContainerCreating 상태로 표시되는 것을 볼 수 있습니다. 레플리카셋은 replicas 값이 5로 변경된 것을 감지하고, 부족한 3개의 파드를 template 명세에 따라 자동으로 추가 생성한 것입니다. 정말 편리하죠?

파드 수 줄이기 (스케일 인, Scale-In)

반대로, 서비스 부하가 줄어들어 5개의 파드가 더 이상 필요 없게 되었다고 가정해봅시다. 자원 효율성을 위해 파드의 수를 다시 1개로 줄여보겠습니다.

마찬가지로 “replicaset.apps/my-nginx-rs scaled” 메시지가 출력됩니다. 다시 상태를 확인해 보면,

DESIRED와 CURRENT 값이 1로 줄어들고, 실행 중인 파드도 1개만 남게 됩니다. 레플리카셋은 초과된 4개의 파드를 자동으로 선택하여 종료(Terminating)시킵니다. 어떤 파드가 종료될지는 특별히 지정하지 않는 한 쿠버네티스가 결정합니다.

kubectl scale 사용 시 주의사항

kubectl scale 명령어는 매우 유용하지만, 한 가지 기억해야 할 점이 있습니다. 이 명령어는 쿠버네티스 API 서버에 있는 오브젝트의 ‘실시간 상태’를 변경하는 것입니다. 만약 여러분이 처음에 사용했던 my-replicaset.yaml 파일의 replicas 필드를 수정하지 않고 그대로 둔다면 (예: replicas: 2 상태), 나중에 이 YAML 파일을 사용하여 kubectl apply -f my-replicaset.yaml 명령을 다시 실행하면 레플리카셋의 파드 수는 YAML 파일에 정의된 replicas: 2 로 다시 변경됩니다.

따라서, 장기적으로 원하는 상태를 관리하고 버전 관리를 위해서는 YAML 파일을 “신뢰할 수 있는 단일 출처(Single Source of Truth)”로 삼고, 변경 사항을 YAML 파일에 반영한 후 kubectl apply를 사용하는 것이 권장됩니다. kubectl scale은 임시적인 스케일 조정이나 자동화 스크립트에서 유용하게 사용될 수 있습니다.

이 실습을 통해 레플리카셋을 YAML로 정의하여 생성하고, kubectl scale 명령어를 통해 파드의 수를 동적으로 조절하는 방법을 직접 경험해 보았습니다. 이러한 스케일링 기능은 클라우드 네이티브 애플리케이션이 변화하는 요구사항에 유연하게 대응할 수 있도록 하는 핵심적인 요소입니다. 다음으로는 레플리카셋의 또 다른 중요한 기능인 자기 치유(Self-healing) 능력을 확인해보는 실습을 진행해 보겠습니다.