들어가며
마지막 포스트를 작성한지 약 1개월하고도 2주가 지났습니다. 원래 목표는 꾸준히 글을 작성하는 것인데… 역시나 “꾸준함”은 그 일이 작더라도 어려운 일인 것 같습니다. 회사 다니면서 기술 블로그도 운영하시는 분들에게 존경심을 갖게 되었습니다.
공부한 내용을 작성하지 않는 것은 아니고, 회사에서 꾸준히 작성 중입니다. 물론 회사 시스템 내부지만요.
업무에 필요한 내용을 공부하고 그에 대한 문서를 틈날 때마다 작성하고 있는데, 노션으로 옮길 때 내용을 다듬고 회사 관련된 내용을 제거해야하기에 생각보다 손이 많이 가는 것 같습니다.
아무튼, 어쩌다보니 올 해부터 팀의 많은 구성원에게 쿠버네티스의 기본기와 온보딩을 위해 세미나를 하고 있습니다. (벌써 2회차) 그러다보니 어렴풋이 알고 있던 내용도 전달을 위해 다시 공부하게 됐고, 정리할 수 있는 시간이 되었습니다.
역시, 남들에게 전달해야할 때 그 지식이 조금 더 깊이 흡수되는 것 같습니다. 이 포스트의 주제인 Rolling Update부터 세미나를 진행했던 내용도 차근차근 옮겨보도록 하겠습니다.
Rolling Update
Rolling Update는 쿠버네티스에서 업데이트 작업 방법 중 하나로, 새로운 버전의 애플리케이션을 배포하고, 기존 버전을 점진적으로 대체하는 과정으로 진행됩니다.
새로운 버전의 Pod로 트래픽이 전달되기 전까지 기존 버전이 유지되므로 무중단으로 애플리케이션을 업데이트 가능한 장점이 있습니다.
새로운 버전의 Pod와 기존 Pod가 함께 유지되는 시간이 존재하기 때문에, 업데이트 중에 리소스를 더 사용할 수 있다는 작은 단점도 있습니다.
Rolling Update을 수행하기 위해서는 기본적으로 Deployment, StatefulSet 등의 리소스로 배포해야합니다.
기본적으로 Rolling Update는 다음과 같은 단계로 이루어집니다.
1.
새로운 버전의 애플리케이션을 배포합니다. 이때 기존 버전은 유지된 상태로 새로운 버전의 Pod가 함께 생성됩니다.
2.
새로운 버전의 Pod이 정상적으로 동작하고, 준비 상태가 되면, 이전 버전의 Pod을 하나씩 종료합니다. 이때 제거되는 Pod은 사용자 요청을 처리하는 중인 경우, 일정 시간 동안 대기한 후에 제거됩니다. (Graceful Shutdown)
3.
이전 버전의 Pod이 모두 종료되면, 새로운 버전의 Pod만 남게 되고, 이제는 새로운 버전의 애플리케이션이 모든 트래픽을 처리하게 됩니다.
Rolling Update는 Deployment 등의 리소스 업데이트 시 Pod를 어떻게 교체할지에 대한 방법을 선택하는 것이며, Rolling Update 설정만으로는 무중단 배포를 설정했다고 말할 수 없습니다.
Rolling Update를 수행하면서, 요청에 대한 에러 발생을 최소화하기 위한 설정은 Container Probe와 Graceful Shutdown에 대한 설정이 추가적으로 필요합니다.
Rolling Update 전략
Rolling Update는 maxSurge/maxUnavailable 값을 적절히 설정하는 것이 중요합니다.
동시에 몇 개의 새로운 버전을 만들고, 몇 개의 기존 Pod를 삭제할지 서비스의 replica 수, 안정성을 고려해서 선택해야합니다.
또한 이 값에 따라 다음과 같은 Rolling Update 전략이 가능합니다.
새로운 버전 Pod 생성 후, 기존 버전 Pod 종료 방식
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
YAML
복사
•
maxSurge=1(또는 n), maxUnavailable=0으로 설정
•
maxUnavailable 값이 0이기 때문에 새로운 버전의 Pod가 생성되야만 종료가 발생합니다.
•
replica + maxSurge 만큼의 Pod가 동시에 유지될 수 있습니다.
•
위 예시에서는 새로운 Pod가 1개가 생성되고 난 후 1개의 기존 Pod가 종료됩니다.
◦
replica가 10개라면, 업데이트시 11개의 Pod가 동시에 유지될 수 있습니다.
◦
replica가 10개라면, 다음과 같이 업데이트 됩니다.
•
장점: 새로운 Pod가 생성되어야 기존 Pod가 삭제되므로 안정적
•
단점: 업데이트시 기존 replica보다 많은 Pod가 생성되는 순간이 있기 때문에 리소스와 노드의 허용 Pod 수를 고려 필요
기존 버전 Pod 종료 후, 새로운 버전 Pod 생성 방식
rollingUpdate:
maxSurge: 0
maxUnavailable: 1
YAML
복사
•
maxSurge=0, maxUnavailable=1(또는 n)으로 설정
•
maxSurge 값이 0이기 때문에 기존 버전의 Pod가 종료되어야만 새로운 버전의 Pod가 생성됩니다.
•
replica - maxUnavailable 만큼의 Pod가 동시에 유지될 수 있습니다.
•
위 예시에서는 기존 Pod가 1개가 종료되고 난 후 1개의 새로운 버전의 Pod가 생성됩니다.
◦
replica가 10개라면, 업데이트시 9개의 Pod가 동시에 유지될 수 있습니다.
◦
replica가 10개라면, 다음과 같이 업데이트 됩니다.
•
장점: 업데이트시 기존 설정 replica 수를 넘어가지 않으므로, 이미 배포가 되어있다면 리소스나 노드에 대해서 크게 고려하지 않아도 괜찮음
•
단점: 기존 Pod를 먼저 삭제하는 부분에서 안정성이 떨어질 수 있음
Example
apiVersion: apps/v1
kind: Deployment
metadata:
name: springapp
spec:
replicas: 3
revisionHistoryLimit: 1
selector:
matchLabels:
app: springapp
# -- Configure Deployment Strategy (Rolling Update)
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: springapp
spec:
containers:
- name: springapp
image: <image-url>
imagePullPolicy: Always
ports:
- containerPort: 8080
name: http
YAML
복사
