쿠버네티스 배포(Kubernetes Deployment)
쿠버네티스의 서비스 배포 전략은 크게 중단 배포와 무중단 배포로 나눌 수 있다.
중단 배포방식은 트래픽이 없는 상황에서 업데이트가 진행되므로, 기존의 서버를 모두 종류한 후 새로운 서버를 배포하는 방식인 Recreate 전략이 가능하다. 하지만 이 방법은 사용자의 경험 측면에서 보면 좋지 않다. 그러므로 기존 서버와 새로운 서버 간의 공존할 수 없는 상황에서만 제한적으로 사용된다.
무중단 배포 방식은 말 그대로 서비스의 중단 없이 새로운 서버로 없데이트 하는 방식이다.
무중단 배포 방식에는 대표적으로 Rolling Update, Blue-Green, Canary 전략이 있다.
Rolling Update
가장 많이 사용되는 배포 방식 중의 하나로, 새 버전을 배포하면서, 새 버전 인스턴스를 하나씩 늘려나가고, 기존 버전을 하나씩 줄여나가는 방식이다. 이 배포 전략은 쿠버네티스에서 지원하는 배포 전략으로, maxSurge, maxUnavliable 파라미터 값을 통해 최대 생성 가능한 포드 수와 업데이트 도중 사용할 수 없는 최대 포드 수를 지정할 수 있다. 이 경우 기존 버전과 새버전이 동시에 존재할 수 있는 단점은 있지만, 시스템을 중단하지 않고 업데이트할 수 있다는 장점이 있다.
다음은 nginx 서버를 Rolling Update하기 위한 yaml 파일의 예시이다.
리플리카가 3개인데 maxSurge와 maxUnavalibale을 각각 50%로 설정하여 최대 5개의 포드가 생성될 수 있고, 업데이트 중 사용할 수 없는 최대 포드 수가 2개이다. 그래서 2개의 새 서버가 생성되고, 2개의 기존 서버가 사용중단되는 방식으로 업데이트가 진행된다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-nginx-update
annotations:
kubernetes.io/change-cause: version 1.16
spec:
replicas: 3
selector:
matchLabels:
app: web
strategy:
rollingUpdate:
maxSurge: 50%
maxUnavailable: 50%
type: RollingUpdate
template:
metadata:
name: nginx-pod
labels:
app: web
spec:
containers:
- name: nginx-container
image: nginx:1.16
Blue-Green
Rolling Update는 기존 버전과 새 버전의 서버가 공존한다는 단점이 있다. 이와 다르게 Blue-Green 전략은 기존 서버와 같은 스펙으로 새로운 서버를 띄운 후, 새로운 서버로 서비스를 연결하여 트래픽을 새 서버로 돌리는 전략이다. 이 전략은 기존 서버와 새 서버가 모두 떠 있어 새 서버에서 문제가 발생하는 경우 트래픽만 기존 서버로 전환을 할 수 있다. 그래서 Rollback이 쉽고, 업데이트 과정에서 소요되는 시간이 적다는 장점이 있다. 그러나 원래 서버 스펙의 2배로 서버를 띄워야 하고, 서버셋이 같이 뜰 수 있는 환경을 조성해야 한다는 단점이 있다.
Canary
카나리는 유독가스에 민감한 새로, 광산에서 유독가슨 누출을 확인하기 위해 카나리를 광산에 먼저 날려보냈다고 한다. 이와 비슷하게 일부 서버만 새 서버로 교체한 후 모니터링과 디버깅을 한 후, 문제가 없는 경우에 전체 서버를 교체하는 방식으로 이루어 지는 전략이다.
다음은 Canary 배포를 위한 yaml 파일의 예시이다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-canary
spec:
replicas: 1
selector:
matchLabels:
app: web
version: canary
template:
metadata:
labels:
app: web
version: canary
spec:
containers:
- name: nginx-container
image: nginx:1.15
ports:
- containerPort: 80