이전글에서 Kubernetes
의 기본 오브젝트 4개에 대해서 정리했습니다.
Kubernetes
는 4개의 기본 오브젝트에 여러가지 기능을 추가하여 더 효율적으로 사용할 수 있는 오브젝트들을 추가했습니다.
오늘은 그 중에서 가장 많이 사용되는 오브젝트들인 Replica Set
과 Deployment
에 대해 알아보겠습니다.
Kubernetes
시리즈의 글을 처음 작성할 때, Kubernetes
에 대해서
"컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 시스템"
이라고 정의했습니다.
그럼 Kubernetes
는 어떻게 배포할 Container
를 선택하고, 갯수를 선택하고 Deploy
와 Scaling
까지 관리해 주는걸까요?
Kubernetes 구조글을 보면 Kubernetes
는 여러 컴포넌트들의 상호작용을 통해 동작합니다.
그 중에서도 Cluster
의 Pod
들을 관찰하여 관리자가 선언한 Pod
의 갯수를 보장해주는 기능을 Controller
들이 수행해주고, 오늘 주제인 Replica Set
과 Deployment
가 이 Controller
의 한 종류입니다.
컨테이너를 감시하고 수를 보장해주는 Controller
에는 크게 4가지 역할이 있습니다.
Auto Healing
Pod
또는 Pod
이 실행되고 있는 Node
에 문제가 생겼을 경우 자동으로 복구하는 기능ReplicaSet
, DaemonSet
Software Update
Pod
을 업데이트 하는 기능, 롤백 기능도 제공Deployment
Auto Scaling
Pod
의 리소스가 부족할 때 Pod
을 추가적으로 생성하는 기능Job
Pod
을 만들었다가 삭제할 수 있는 기능job
, cron job
Replica Set
은 Pod
의 숫자를 보장해주는 Controller
입니다.
아래는 Kubernetes
백서의 Replica Set 문서에서 가져온 yaml파일 입니다.
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
코드를 보면 ReplicaSet
오브젝트를 선언하고 있으며,
ReplicaSet
은 3개의 Replicas
로 구성되어 있습니다.
이는 아래 template
에 정의한 Pod
가 3개 배포된다는 의미입니다.
template
을 보면 배포될 Pod
들은 tier:frontend
라는 Labels
을 가지고 있고,
Replica Set
은 spec.selector
을 통해 tier:frontend
라는 Labels
을 가지고 있는 Pod
들의 갯수를 보장해주게 됩니다.
Replica Set
을 이용하면 Pod
의 숫자가 보장되기 때문에 관리자가 원하는 어플리케이션을 안정적으로 배포할 수 있습니다.
하지만, 시간이 흐르게 되면 해당 어플리케이션을 업그레이드하여 배포해야하는 경우가 생기게 되는데, Replica Set
은 이런 업데이트에 관한 기능을 제공하지 않습니다.
이를 해결하기위해 사용하는 것이 Deployment
라는 오브젝트입니다.
Kubernetes
백서에는 Deployment
의 역할에 대해
"파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다"
라고 정의 되어있습니다.
이전에도 설명했듯이 Kubernetes
는 선언적으로 동작합니다.
스펙을 선언하면 해당 스펙에 맞는 상태로 변화시키려고 하는 특징이 있습니다.
Deployment
는 위와 같은 형태로 동작합니다.
Deployment
는 Pod
와 ReplicaSet
에 대한 선언적 업데이트를 제공합니다.
하위에 ReplicaSet
을 제어하고, ReplicaSet
이 하위의 Pod
을 제어하는 구조이며,
Deployment
가 ReplicaSet
을 제어하므로, 관리자는 Deployment
하단의 ReplicaSet
을 직접 관리하면 안됩니다.
어차피 Deployment
에 선언해놓은대로 돌아오기 때문입니다.
위의 사진에서 보다시피 Deployment
는 V1, V2, V3처럼 ReplicaSet
이 지원하지 못했던 업데이트에 관한 기능을 함께 지원합니다.
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
Deployment
를 생성하는 yaml코드를 보면 ReplicaSet
의 yaml코드와 매우 유사한 것을 알 수 있습니다.
Deployment
는 다양한 방법으로 업데이트를 지원합니다.
먼저 Rolling Update
는 별다른 설정을 하지 않을시 기본적으로 적용되는 방식입니다.
V1을 V2로 업데이트 할 때, V2를 하나 생성한 뒤 V1을 삭제하는 방식으로 Pod
를 하나씩 점진적으로 교체해나가는 방법입니다.
이 방법은 무중단배포가 가능하다는 장점이 있지만, V1과 V2의 Pod
이 공존하는 순간이 있다는 단점이 있습니다.
두번째는 Recreate
즉 재생성입니다.
그림에서 보다시피 기존의 Pod
을 모두 삭제한 뒤, 새로운 버전의 Pod
을 선언한 갯수만큼 생성해주는 방식입니다.
단점으로는 순간적으로 Pod
이 존재하지 않는 순간이 있다는 점입니다.
세번째는 Blue/Green
배포입니다.
Blue/Green
배포는 기존 버전의 Pod
을 유지한채로 새로운 버전의 Pod
을 선언한 갯수만큼 생성하고 Service
가 트래픽을 전달하는 대상을 교체한 뒤 기존의 Pod
을 삭제하는 방식입니다.
이 방법은 무중단 배포가 가능하고, 기존에 Rolling Update
가 가지고있던 V1, V2가 공존하는 순간이 있는 문제를 해결할 수 있지만, 배포시에 자원을 2배로 사용한다는 단점이 있습니다.
Canary
는 테스트라는 특징을 가지고 있는 업데이트 방법입니다.
구버전과 신버전 Pod
을 모두 구성한 뒤, 트래픽의 양을 조절하여 테스트를 진행한 다음 교체하는 방식입니다.