반응형
Update 방식
Recreate
기존 Pod들을 전체 삭제하고 새로운 Pod들을 만든 후 트래픽을 연결하는 방식
- 특징
- 삭제 후 새로운 버전의 Pod생성까지 시간만큼 Down Time 발생하는 단점
- 방법
- 기존 버전의 Pod를 삭제하고 새로운 버전의 Pod를 생성
Rolling Update
새로운 Pod을 한번에 설정한 갯수만큼 만들어 연결한 후 기존 Pod을 삭제하는 방식
- 특징
- 업데이트 중에 기존 Pod, 새로운 Pod 모두에 트래픽이 요청되기 때문에 구버전과 새버전이 공존하는 시간이 발생하는 단점
- 한번에 업데이트할 Pod의 갯수만큼 업데이트 하는 순간 자원을 추가 사용
- Down Time 없음
- 방법
- 먼저 새로운 Pod를 생성한 후 트래픽을 연결
- 연결 후 기존 Pod을 삭제
- 기존 Pod 갯수만큼 위 방식 반복하여 기존 Pod으로 가던 모든 트래픽을 새로운 Pod으로 연결
Blue / Green
기존 Pod들과 동일한 갯수의 새로운 Pod을 만들어 순간적으로 전체 트래픽을 연결하는 방식
- 특징
- Deployment가 아니어도 replicas를 관리하는 모든 Controller를 사용하여 구현 가능
- 전체 Pod의 갯수만큼 업데이트 하는 순간 자원을 추가 사용
- Rollback하고 싶을 때 Service의 selector를 기존 라벨로 다시 연결시키면 됨
- 구버전과 새버전이 공존하는 시간이 없는 장점
- Down Time 없음
- 방법
- 기존과 다른 라벨을 사용하여 새로운 버전의 Pod들을 관리하는 Controller 생성
- 새로운 Pod들이 생성되면 Service의 selector를 새로운 라벨로 변경
- 문제가 없을 시 기존 Controller 삭제
Canary
위험이 있는지 확인하고 없다는 판단이 들면 정식 배포하는 방식
- 특징
- 테스트시 연결한 Pod의 갯수만큼 자원을 추가 사용
- Down Time 없음
- 방법 1 (불특정 다수 대상 테스트)
- Service와 기존 Pod이 연결된 라벨과 같은 라벨을 가진 새로운 Controller 생성
- 새로운 Pod과 기존 Pod을 모두 Service로 연결하여 테스트
- 문제 발생시 새로운 Controller의 replicas를 0으로 만듬
- 문제 없을시 새로운 Controller의 replicas를 늘리고, 기존 Controller의 replicas를 0으로 만듬
- 방법 2 (특정 대상 테스트)
- 새로운 버전의 Controller 생성
- 새로운 Service를 생성한 후 새로운 Controller와 연결
- Ingress Controller에 기존 Service와 새로운 Service를 모두 연결
- 각 Service마다 요청 Path를 다르게 두어 새로운 Pod을 테스트
- 테스트 완료되면 새로운 Controller의 replicas를 늘리고 Service와 연결된 path 변경
구현 방법
ReCreate
- Deployment의 Template을 새로운 버전으로 업데이트
- Deployment는 자신이 만든 ReplicaSet의 replicas를 0으로 변경
- 기존 Pod 제거 → 이때 Down Time 발생
- 새로운 Template을 적용한 ReplicaSet 생성
- Pod 생성 및 Service 재연결
apiVersion: apps/v1
kind: Deployment
metadata:
name: dep-1
spec:
selector:
matchLabels:
type: app
replicas: 2
**strategy:
type: Recreate
revisionHistoryLimit: 1 # 과거의 ReplicaSet을 몇개 살려놓을지**
template:
metadata:
labels:
type: app
spec:
containers:
- name: container
image: something
RollingUpdate
- Deployment의 Template을 새로운 버전으로 업데이트
- 새로운 Template을 적용한 ReplicaSet 생성
- 새로운 ReplicaSet의 replicas를 maxSurge만큼 증가
- 새로운 Pod과 Service 연결
- 기존 ReplicaSet의 replicas를 maxUnavailable만큼 감소
- 기존 Pod 제거
- 기존 ReplicaSet의 replicas가 0이 될 때까지 반복
apiVersion: apps/v1
kind: Deployment
metadata:
name: dep-2
spec:
selector:
matchLabels:
type: app
replicas: 2
**strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # 동시에 생성할 수 있는 Pod의 최대 갯수 (%로도 가능, 기본값: replicas 25%)
maxUnavailable: 1 # 동시에 삭제할 수 있는 Pod의 최대 갯수 (%로도 가능, 기본값: replicas 25%)
minReadySeconds: 10 # 10초 간격으로 생성 및 삭제 반복**
template:
metadata:
labels:
type: app
spec:
containers:
- name: container
image: something
Blue / Green
1. 새로운 버전의 이미지를 가진 Deployment를 만든다.
2. 기존 Service의 selector 를 새로 만든 Deployment의 라벨로 변경한다.
3.
$ kubectl patch svc test-service -p '{"spec": {"selector": {"color": "green"}}}'
4.모니터링 후 이상 없으면 blue 버전의 Deployment 삭제 or replicas 를 0으로 만듬
새로운 ReplicaSet은 기존 Pod과 연결되는 상황을 방지하기 위해 기존 라벨 이외에 새로운 라벨(pod-template-hash: {hash값})도 함께 만들어 연결
# blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dep-1
spec:
replicas: 2
selector:
matchLabels:
app: test-pod
color: blue
template:
metadata:
labels:
app: test-pod
color: blue
spec:
containers:
- name: test-pod
image: something:0.1 # 구버전
ports:
- containerPort: 8080
# test-service.yaml
apiVersion: v1
kind: Service
metadata:
name: test-service
spec:
ports:
- port: 80
targetPort: 8080
selector:
app: test-pod
color: blue
# green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dep-1
spec:
replicas: 2
selector:
matchLabels:
app: test-pod
color: green
template:
metadata:
labels:
app: test-pod
color: green
spec:
containers:
- name: test-pod
image: something:0.2 # 신버전
ports:
- containerPort: 8080
반응형
'Kubernetes' 카테고리의 다른 글
StatefulSet (0) | 2023.02.08 |
---|---|
DaemonSet, Job, CronJob (0) | 2023.02.08 |
ReplicaSet, Replication Controller (0) | 2023.02.08 |
Namespace / ResourceQuota / LimitRange (0) | 2023.02.08 |
ConfigMap / Secret (0) | 2023.02.08 |