소개
이전 실습에서는 단일 Pod 를 생성했습니다. Pod 는 Kubernetes 의 기본 구성 요소이지만, 수동으로 관리하면 번거롭습니다. Pod 가 종료되면 직접 다시 시작해야 합니다. Pod 를 더 많이 실행하려면 직접 Pod 를 추가로 생성해야 합니다.
이때 Deployment를 사용합니다.
Deployment 는 ReplicaSet 과 Pod 를 대신 관리하는 상위 수준의 컨트롤러입니다. 실행할 레플리카 수와 사용할 Pod 템플릿을 선언하면 Kubernetes 가 실제 상태를 선언한 상태와 일치하도록 유지합니다.
여기서 중요한 변화는 개별 Pod 가 아니라 반복해서 실행할 수 있는 워크로드를 관리한다는 점입니다. 단일 Pod 는 하나의 인스턴스일 뿐이므로 장애에 취약합니다. Deployment 는 Pod 를 생성하는 방식과 실행할 Pod 의 목표 개수를 정의합니다. 이 방식 덕분에 확장과 자동 복구가 가능합니다.
이 실습에서는 다음을 수행합니다.
- 특정 목표인 3 개의 레플리카를 가진 엄격한 관리자 (Deployment) 를 생성합니다.
- 관리자가 작업자 (Pod) 를 생성하는 과정을 확인합니다.
- 작업자 하나를 "종료"하여 관리자의 반응 (자동 복구) 을 테스트합니다.
- 관리자에게 작업자를 더 생성하도록 요청합니다 (확장).
Deployment YAML 작성
이 단계에서는 관리자에게 전달할 작업 설명서를 작성합니다. 이 YAML 파일은 실행할 이미지와 원하는 복사본 수 (레플리카) 를 정의합니다.
일반적인 Pod 매니페스트와 비교하면 구조가 더 복잡합니다. Deployment 에는 selector와 template이 포함됩니다. selector 는 어떤 Pod 가 이 Deployment 에 속하는지 Kubernetes 에 알려 주고, template 은 새 Pod 를 생성하는 방법을 정의합니다. 이 두 부분은 서로 일치해야 합니다. 그렇지 않으면 Deployment 가 의도한 Pod 를 올바르게 관리하지 못합니다.
먼저 프로젝트 디렉터리에 있는지 확인합니다.
cd ~/project
nano를 사용하여 deployment.yaml이라는 새 파일을 생성합니다.
nano deployment.yaml
다음 설정을 파일에 붙여 넣습니다. replicas: 3 줄에 주의하세요. 이 줄에서 팀의 인원 수를 정의합니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
저장하려면 Ctrl+X를 누른 다음 Y, Enter를 차례로 누릅니다.
이 파일은 Kubernetes 에 다음을 지시합니다. "nginx-deployment라는 Deployment 를 생성합니다. nginx:1.14.2 이미지를 실행하는 Pod 를 항상 3 개 유지합니다. 이 Pod 를 찾을 때는 app: nginx 레이블이 있는 Pod 를 확인합니다."
적용하고 확인하기
작업 설명서를 작성했으므로 이제 관리자 (Deployment) 를 생성합니다. 클러스터에 설정을 적용합니다.
Deployment 를 생성하면 Kubernetes 는 일반적으로 내부적으로 ReplicaSet이라는 객체도 생성합니다. ReplicaSet 은 요청된 수의 Pod 가 계속 실행되도록 직접 관리하는 구성 요소입니다. 아직 초보자가 ReplicaSet 을 직접 관리할 필요는 없지만, 명령 출력에서 자주 볼 수 있으므로 ReplicaSet 이 존재한다는 점을 알아 두면 좋습니다.
kubectl apply -f deployment.yaml
Kubernetes 는 다음과 같이 생성되었음을 확인합니다: deployment.apps/nginx-deployment created.
Deployment(관리자) 는 즉시 3 개의 Pod 를 생성하기 시작합니다. Pod 를 빠르게 확인하려면 다음 명령을 실행합니다.
kubectl get pods
이름이 모두 nginx-deployment-로 시작하는 서로 다른 Pod 3 개가 표시되어야 합니다.
NAME READY STATUS RESTARTS AGE
nginx-deployment-66b6c48dd5-8j64w 1/1 Running 0 5s
nginx-deployment-66b6c48dd5-d95l2 1/1 Running 0 5s
nginx-deployment-66b6c48dd5-lzr5w 1/1 Running 0 5s
Deployment 자체의 상태도 확인할 수 있습니다.
kubectl get deployments
READY 3/3이 표시되어야 합니다. 이는 요청한 레플리카 3 개가 모두 실행 중임을 의미합니다.
자동 복구 테스트
Kubernetes 의 가장 강력한 기능 중 하나는 **자동 복구 (Self-Healing)**입니다. Deployment 는 실제 Pod 수가 항상 원하는 Pod 수 (3 개) 와 일치하도록 보장합니다. Pod 하나가 사라지면 즉시 새 Pod 로 교체합니다.
이는 Kubernetes 가 실제 상태와 원하는 상태를 계속 비교하기 때문에 가능합니다. Pod 하나를 삭제해도 Deployment 에 저장된 원하는 레플리카 수는 변경되지 않습니다. 따라서 시스템은 삭제를 상태 불일치로 판단하고 대체 Pod 를 생성합니다.
Pod 하나를 직접 삭제하여 이 기능을 테스트합니다.
먼저 Pod 목록을 다시 확인합니다.
kubectl get pods
Pod 중 하나의 전체 이름을 복사합니다 (예: nginx-deployment-66b6c48dd5-8j64w).
이제 해당 Pod 를 삭제합니다.
kubectl delete pod <paste-pod-name-here>
Kubernetes 에서 Pod 가 삭제되었다는 메시지가 표시됩니다. 즉시 kubectl get pods를 다시 실행합니다.
kubectl get pods
다음과 같은 현상을 확인할 수 있습니다.
- 기존 Pod 가 종료 중이거나 목록에서 사라집니다.
- 이름이 다르고 Age 가 매우 짧은 (예: 2 초) 새 Pod가 이미 나타납니다.
Deployment 는 작업자 하나가 사라진 것을 감지하고 팀 규모를 3 개로 유지하기 위해 즉시 새 작업자를 생성했습니다. 따라서 개별 서버나 컨테이너에 장애가 발생해도 애플리케이션을 계속 온라인 상태로 유지할 수 있습니다.
확장
웹사이트가 인기를 얻고 있다고 가정해 보겠습니다. 웹 서버 3 개로는 더 이상 충분하지 않아 5 개가 필요합니다. 새 파일을 직접 만들거나 Pod 를 급하게 생성해야 할까요?
Deployment 를 확장하면 현재 실행 중인 프로세스 집합만 바꾸는 것이 아니라, 선언된 원하는 Pod 수가 변경됩니다. 따라서 한 번의 수동 작업으로 끝나지 않고 새로운 규모가 유지됩니다. 컨트롤러는 다시 변경할 때까지 업데이트된 레플리카 수를 기준으로 계속 관리합니다.
그럴 필요가 없습니다. 관리자에게 수를 늘리라고 지시하면 됩니다.
kubectl scale 명령을 사용하면 실행 중인 상태에서 레플리카 수를 변경할 수 있습니다.
레플리카 수를 3 개에서 5 개로 변경합니다.
kubectl scale deployment/nginx-deployment --replicas=5
이제 변경 사항을 확인합니다.
kubectl get pods
이제 실행 중인 Pod 가 5 개 표시됩니다. 새로운 요구 사항을 충족하기 위해 Pod 2 개가 추가로 시작되었습니다.
규모를 줄일 수도 있습니다. 트래픽이 감소하면 Pod 수를 줄여 리소스를 절약할 수 있습니다.
kubectl scale deployment/nginx-deployment --replicas=2
kubectl get pods를 다시 실행하면 Kubernetes 가 초과 Pod 를 종료하여 2 개만 남기는 것을 확인할 수 있습니다.
이처럼 동적으로 확장할 수 있기 때문에 기업에서 Kubernetes 를 선호합니다.
요약
이 실습에서는 애플리케이션이 계속 실행되도록 관리하는 지능형 관리자 Deployment를 배웠습니다.
다음 작업을 완료했습니다.
- 작업자 Pod 3 개를 가진 Deployment 를 생성했습니다.
- Deployment 가 장애가 발생한 Pod 를 자동으로 교체하는지 확인했습니다 (자동 복구).
- 단일 명령으로 레플리카 수를 늘리고 줄였습니다 (확장).
이제 독립 실행형 Pod 를 직접 생성하는 경우가 드문 이유를 이해할 수 있습니다. Deployment 는 스케줄링과 재시작 같은 복잡한 작업을 대신 관리하여 애플리케이션에 안정성과 유연성을 제공합니다.
