2024. 3. 17. 22:28ㆍBACKEND/Docker & Kubernetes
본 포스팅은 Kubernetes Core Concept 중, Deployment Object의 개념과 사용법을 익히도록 합니다.
🔗 Kubernetes Series
모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.
본 포스팅에서는 Kubernetes을 사용하며 반드시 알아야할 개념 중 하나인 Deployment를 살펴보고자 합니다.
Deployment?
A Deployment provides declarative updates for Pods and ReplicaSets
Deployment는 이름 그대로, 쿠버네티스에서 배포를 위한 객체입니다.
기능적으로는, Pod와 ReplicaSet를 배포를 관리합니다.
운영자가 Deployment에서 원하는 상태desired status를 설정하여 적용하면,
Deployment Controller가 현재 Pod 배포 상태를 변경하고자 하는 상태에 가까워 지도록 관리합니다.
--
현재는 대부분의 서비스를 운영함에 있어서
아래의 상황 등을 고려하여 안정적인 운영을 지향하곤 합니다.
✔️ 배포된 파드 업데이트
✔️ 새로운 애플리케이션 릴리즈
✔️ 무중단 배포
쿠버네티스에서는 각종 고려되는 상황들을 반영하여,
안정적인 배포 뿐만 아니라, 배포 과정을 한 번 선언해두면 항상 동일한 방식으로 배포가 진행되도록 합니다.
그럼, 쿠버네티스에서 배포는 어떻게 진행할 수 있을까요?
애플리케이션을 업데이트하고 싶을 때, 모든 Pod에 변경 사항을 쉽게 반영하기 위해
Pod의 상위 계층인 ReplicaSet 에 변경 사항을 적용할 수 있습니다.
ReplicaSets를 통해 안정적으로 파드 개수를 유지시키고,
하나의 파드에 장애가 발생했을 때, 트래픽을 정상 동작하는 파드로 조정하여 안정적인 파드 운영을 도와줍니다.
하지만 업데이트를 반영 시, 여러 ReplicaSet 모두에 반영을 하려고 할 땐 어떨까요?
가령, 공통 모듈 내 DB·서버·프론트와 같이 3개의 애플리케이션에 해당하는 ReplicaSet들을 하나씩 업데이트 하는 방법도 있을 텐데요.
문제는 서버 다음 프론트를 업데이트 한다고 했을 때,
서버가 v2인데 DB와 프론트는 아직 v1인 내용을 반영한다면 장애가 발생할 수도 있습니다.
위 방식이 아닌, 공통 모듈의 모든 구성요소가 한 번에 업데이트되고, 항상 동일한 조건의 배포를 통해 진행되는 것을 선호할 것입니다.
ReplicaSet보다 더 높은 계층인 Deployment 를 배포함으로써, 안정적인 업데이트를 진행할 수 있습니다.
쿠버네티스에서는, Deployment 정의 파일을 구성하는 방법이, 배포 방법과 동일하기 때문에,
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
Kubernetes는 .metadata.name를 참고하여 nginx-deployment를 생성합니다. 이 이름은 나중에 생성될 ReplicaSets 나 Pods 의 기초가 됩니다. 자세한 내용은 이후 Deployment Spec 을 설명할 때 다루겠습니다.
Deployment는 .spec.replicas 를 참고하여 ReplicaSet이 생성·관리할 Pod의 개수를 설정합니다. .spec.selector는 생성된 ReplicaSet이 어떤 Pod을 관리할지 지정합니다. 위 경우, 파드의 템플릿 app: nginx 로 정의된 레이블을 찾습니다. 파드 템플릿 규칙을 살펴보면, 조금 더 정교하게 규칙을 설정할 수 있습니다.
FYI. matchExpressions.spec.selector.matchLabels
필드는{key, value}
의 쌍으로 정의합니다. 비슷하게,matchExpressions
를 사용할 수 있는데요.matchExpressions
는 정교한 조건을 담아selector
를 설정할 수 있습니다.
이 때, matchLabels 에 정의된{key, value}
쌍은,matchExpressions
에{ key: ≪key≫, operator: In, values: ≪value≫}
를 입력하는 것과 동일합니다. 즉,key
필드는matchLabels
의 "key"값을,operator
는 "In",values
는matchLabels
의 "value"를 명시하는 것과 동일합니다.
❸ Template 정의
템플릿의 필드는 다음과 같은 하위 필드들을 포함합니다:
- ❸.①: Pod는 .metadata.labels를 통해 app: nginx로 라벨링됩니다.
- ❸.②: 파드 템플릿을 정의하거나 .spec.template.spec 필드에 명시한 내용들은 하나의 컨테이너에서 동작한다는 것을 의미합니다. 위 예시에서는 파드가 nginx:1.14.2 이미지를 사용하여, nginx 이름으로 Port 80에서 생성시키라는 설정입니다.
- ❸.③: .spec.template.spec.containers[0].name에 nginx을 설정함으로써,nginx 명의 컨테이너가 생성됩니다.
Deployment command
✔️ NGINX Pod 생성
❯ kubectl run nginx --image=nginx
✔️ POD Manifest YAML file 확인 (저장 x)
❯ kubectl run nginx --image=nginx --dry-run=client -o yaml
-o yaml
: POD Manifest YAML file 생성
--dry-run
: Don't create it
✔️ Deployment 생성
❯ kubectl create deployment --image=nginx nginx
--image
: 생성할 image 명시
✔️ Deployment Manifest YAML file 확인 (저장 x)
❯ kubectl create deployment --image=nginx nginx --dry-run=client -o yaml
-o yaml
: POD Manifest YAML file 생성
--dry-run
:Don't create it
--image
: 생성할 image 명시
✔️ Deployment Manifest YAML file 생성
❯ kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml
-o yaml
: POD Manifest YAML file 생성
--dry-run`
: Don't create it
--image
: 생성할 image 명시
>
: 다음 인자로 입력한 이름으로 파일 저장
✔️ Deployment 생성 with Yaml File
❯ kubectl create -f nginx-deployment.yaml
특정 Manifest 파일 생성/수정 후 생성
✔️ (k8s version 1.19+) Deployment 생성 with Yaml File
❯ kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml
--replicas
: replicas 개수 지정
Use Case
실제 Deployment는 어떤 식으로 사용하는지 사용 사례들을 알아보며 감을 익혀도록 하겠습니다.
✔️ ReplicaSet 배포
ReplicaSet는 내부에서(background) Pod를 생성하며, 배포 과정 상태를 체크할 수 있습니다.
✔️ 새로운 상태의 Pod 선언
Deployment의 PodTemplateSpec를 업데이트해서 새로운 상태를 선언합니다.
새로운 ReplicaSet가 생성되고 Deployment는 속도를 제어하며,
Pod가 이전 ReplicaSet에서 새로운 ReplicaSet 하위로의 이동을 관리합니다.
각각의 새로운 ReplicaSet은 Deployment의 수정을 반영합니다.
✔️ Rollback
현재 배포 상태가 안정적이지 않은 경우 이전 배포 개정판으로 롤백합니다.
각 롤백은 배포 수정 버전을 업데이트합니다.
✔ Deployment 스케일 업
더 많은 부하를 견디기 위해 Deployment를 스케일 업합니다.
✔️ 배포 진행 확인
Deployment의 상태를 통해, 배포가 정상인지를 나타내는 지표로써 사용합니다.
✔️ ReplicaSet 정리
더 이상 필요 없는 이전 버전의 ReplicaSet 세트를 정리합니다.
| Reference |
🔗 Kubernetes.io - Official Docs
🔗 Udemy: certified-kubernetes-administrator-with-practice-tests
'BACKEND > Docker & Kubernetes' 카테고리의 다른 글
Kubernetes Affinity, 제대로 이해하기 (0) | 2024.03.25 |
---|---|
Kubernetes Taints & Tolerations, 제대로 이해하기 (1) | 2024.03.24 |
Kubernetes Architecture, 제대로 이해하기 (0) | 2024.03.03 |
Kubernetes Architecture, 제대로 이해하기 - Control Plane (2) | 2023.11.22 |
Docker Swarm, 제대로 이해하기 - Swarm & Service (2) | 2023.10.30 |
Backend Software Engineer
𝐒𝐮𝐧 · 𝙂𝙮𝙚𝙤𝙣𝙜𝙨𝙪𝙣 𝙋𝙖𝙧𝙠