쿠버네티스의 대표적인 워크로드 리소스인 Deployment(디플로이먼트), Replicaset(레플리카셋)를 살펴보는 섹션입니다 :)
해당 섹션에서 사용하는 Kubernetes 중요한 개념 중 하나인 "선언형 접근"에 대해서 먼저 살펴보겠습니다.
"선언형 접근"과 반대되는 개념인 "명령형 접근"이 있습니다. kubectl 명령어를 통해서 구분하자면 "kubectl apply" vs "kubectl create"의 차이점입니다. !
"선언형 접근 (kubectl apply)"는 프로그램에게 무엇을 요구하는지에 초점이 맞춰져 있습니다. yaml 파일에 필요한 리소스와 리소스의 속성 등 사용자가 무엇을 원하는지 시스템 상태를 정의하면, 프로그램은 해당 상태를 유지하기 위해 스스로 구성을 변경하거나 설정합니다.
"명령형 접근 (kubectl create)"는 프로그램에게 어떻게 요구하는지에 초점이 맞춰져 있습니다. 선언형 접근과 마찬가지로 yaml 파일에 필요한 리소스와 리소스 속성 등을 정의하면, 프로그램은 해당 yaml 파일에 정의된 내용을 수행하는데 초점이 맞추어져 있습니다.
간단한 예시로 nginx.yaml 파일을 "kubectl create" 명령으로 수행하고, 해당 yaml 파일에 특정 상태 값을 변경하여 "kubectl create" 명령을 수행하면 "already exists" 에러가 발생하는 것을 확인할 수 있습니다 :)
정리하면 "선언형 접근 (kubectl apply)"는 특정한 동작을 지시하는 것이 아닌, 특정한 상태의 유지를 선언하는 것으로 시스템 구성을 요청하는 것입니다.
Replicaset - 레플리카셋
먼저 쿠버네티스 공식문서에 따르면 Replicaset은 다음과 같이 정의되어 있습니다.
"레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다. 이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다."
해당 내용을 조금 더 풀어서 해석하자면, 레플리카셋(ReplicaSet)은 파드들의 배포를 정의하고 이를 관리하면서, 정의된 수 만큼의 파드가 언제나 정상 구동될 수 있도록 보장하는 역할(선언형 접근)을 합니다.
만약 Replicaset 구성에 Pod 개수를 정의했는데, 특정 Node의 장애가 발생하거나 Pod가 삭제된다면 선언된 상태를 유지하기 위해 해당 Pod를 복제하여 다른 Node에 가용하는 등 상태 유지를 위해 시스템이 자동으로 수행하게 됩니다.
레플리카셋 생성하기
쿠버네티스 공식 문서를 참고하여 yaml 파일을 생성합니다. (https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicaset/)
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# 케이스에 따라 레플리카를 수정한다.
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
- apiVersion : apps/v1 으로 설정해주세요 !
- spec.selector.matchLabels, spec.template.metadata.labels : 키-값 쌍은 동일하게 설정해주세요 !
- spec.replicas : Replicaset이 유지하려는 Pod의 개수입니다 !
- spec.selector : Replicaset이 관리하고자 하는 Pod를 선택하기 위한 조건을 정의하는 필드입니다. 위 예제에서는 "spec.selector.matchLabels"를 사용해서 "tier: frontend" 레이블을 가진 Pod를 관리하도록 조건을 설정하였습니다 !
- spec.template : Replicaset을 통해서 생성되고 관리하고자 하는 Pod를 정의하는 필드입니다. spec.template.metadata, spec.template.spec 필드는 https://kubernetes.io/ko/docs/concepts/workloads/pods/ 에서 metadata, spec 섹션과 동일합니다 :)
레플리카셋 배포하기
kubectl apply -f replicaset.yaml -n journalctl
레플리카셋 상태 확인하기
$ kubectl get pod -n journalctl
NAME READY STATUS RESTARTS AGE
frontend-2pln6 1/1 Running 0 31s
frontend-fb4d4 1/1 Running 0 31s
frontend-gqsdv 1/1 Running 0 31s
$ kubectl get rs -n journalctl
NAME DESIRED CURRENT READY AGE
frontend 3 3 3 58s
$ kubectl describe replicaset/frontend -n journalctl
Name: frontend
Namespace: journalctl
Selector: tier=frontend
Labels: app=guestbook
tier=frontend
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: tier=frontend
Containers:
php-redis:
Image: gcr.io/google_samples/gb-frontend:v3
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 104s replicaset-controller Created pod: frontend-2pln6
Normal SuccessfulCreate 104s replicaset-controller Created pod: frontend-gqsdv
Normal SuccessfulCreate 104s replicaset-controller Created pod: frontend-fb4d4
Deployment - 디플로이먼트
쿠버네티스 공식문서에 따르면 Deployment는 다음과 같이 정의되어 있습니다.
"디플로이먼트(Deployment) 는 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다."
"디플로이먼트에서 의도하는 상태 를 설명하고, 디플로이먼트 컨트롤러(Controller)는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다."
해당 내용을 조금 풀어서 해석하자면, Deployment는 위에 살펴본 Replicaset을 포함하는 상위 오브젝트로서 배포 정책(Rolling Update...)을 비롯하여 배포 관리에 주로 사용됩니다. 간단하게 이해하면 Replicaset이 Pod의 개수를 조절한다면 Deployment는 상위 오브젝트로서 Replicaset + 배포 정책 + 버전 관리를 수행하게 됩니다 :)
디플로이먼트 생성하기
쿠버네티스 공식 문서를 참고하여 yaml 파일을 생성합니다.
(https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/)
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
- spec.replicas : Replicaset이 유지하려고 하는 Pod의 개수입니다 !
- spec.template : Replicaset과 마찬가지로 Replicaset을 통해서 생성되고 관리하고자 하는 Pod를 정의하는 필드입니다.
- spec.selector.matchLabels, spec.template.metadata.labels 키-값 쌍은 동일하게 유지해주세요 ! 해당 부분을 통해서 관리하는 Pod를 결정하게 됩니다.
디플로이먼트 배포하기
kubectl apply -f deployment.yaml -n journalctl
디플로이먼트 상태 확인하기
$ kubectl get pod -n journalctl
NAME READY STATUS RESTARTS AGE
nginx-deployment-85996f8dbd-qpqqw 1/1 Running 0 61s
nginx-deployment-85996f8dbd-tgwfh 1/1 Running 0 61s
nginx-deployment-85996f8dbd-xdxc9 1/1 Running 0 61s
$ kubectl get rs -n journalctl
NAME DESIRED CURRENT READY AGE
nginx-deployment-85996f8dbd 3 3 3 78s
$ kubectl get deployment -n journalctl
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 89s
$ kubectl describe deployment -n journalctl
Name: nginx-deployment
Namespace: journalctl
CreationTimestamp: Mon, 27 Nov 2023 22:07:41 +0900
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.14.2
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-85996f8dbd (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 102s deployment-controller Scaled up replica set nginx-deployment-85996f8dbd to 3
앞서 설명한대로 Deployment는 Replicaset을 포함한 상위 오브젝트라고 설명했습니다.
Deployment.yaml 파일을 배포하고 Replicaset을 확인하면 Deployment에 의해서 Replicaset이 배포된 것을 확인할 수 있습니다 :)
Replicaset 과 Deployment를 describe 명령어를 통해서 확인하면 Replicaset에는 관리되지 않던 "StrategyType", "Annotation.revision" 등 배포 정책과 이력 관리과 새롭게 추가된 것을 확인할 수 있습니다 !
디플로이먼트 스케일링
CLI 환경에서 간단하게 스케일을 조절하는 방법은 scale 명령어를 통해서 가능합니다. 이 방법은 yaml 파일에 설정된 내용과 무관하게 명시적으로 적용되는 방법입니다. yaml 파일의 replicas 값을 수정 후 "kubectl apply" 명령어를 통해서도 스케일 조절이 가능합니다 :)
$ kubectl scale deployment/nginx-deployment --replicas=6 -n journalctl
deployment.apps/nginx-deployment scaled
디플로이먼트 상태 확인하기
$ kubectl get pod -n journalctl
NAME READY STATUS RESTARTS AGE
nginx-deployment-85996f8dbd-8vkx9 1/1 Running 0 5m44s
nginx-deployment-85996f8dbd-hzxmc 1/1 Running 0 5m44s
nginx-deployment-85996f8dbd-qpqqw 1/1 Running 0 15m
nginx-deployment-85996f8dbd-tgwfh 1/1 Running 0 15m
nginx-deployment-85996f8dbd-tk92x 1/1 Running 0 5m44s
nginx-deployment-85996f8dbd-xdxc9 1/1 Running 0 15m
$ kubectl get rs -n journalctl
NAME DESIRED CURRENT READY AGE
nginx-deployment-85996f8dbd 6 6 6 15m
$ kubectl describe deployment -n journalctl
Name: nginx-deployment
Namespace: journalctl
CreationTimestamp: Mon, 27 Nov 2023 22:07:41 +0900
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=nginx
Replicas: 6 desired | 6 updated | 6 total | 6 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.14.2
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Progressing True NewReplicaSetAvailable
Available True MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-85996f8dbd (6/6 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 15m deployment-controller Scaled up replica set nginx-deployment-85996f8dbd to 3
Normal ScalingReplicaSet 6m17s deployment-controller Scaled up replica set nginx-deployment-85996f8dbd to 6 from 3
replicas 값을 6으로 수정 후 다시 살펴보면 정상적으로 Pod의 개수는 6개로 잘 배포된 것을 확인할 수 있습니다 :)
Deployment를 describe 명령어를 통해서 Event를 살펴보면 "Scaled up replica set nginx-deployment-85996fdbd to 6 from 3"을 확인할 수 있습니다 !

다음 섹션은 대표적인 워크로드 리소스인 Statefulset, Daemonset에 대해서 살펴보겠습니다.
'Kubernetes' 카테고리의 다른 글
인증서를 무료로 관리해보자(Cert-manager + Let’s Encrypt) (0) | 2025.01.12 |
---|---|
VKE - Vultr Kubernetes Engine (3) | 2025.01.12 |
kind(Kubernetes in Docker) (4) | 2025.01.12 |
Kubernetes Workload Resources(Daemonset) (7) | 2023.12.03 |
Kubernetes Workload Resources(Statefulset) (62) | 2023.12.03 |