1. Rolling Stratege
아래와 같은 일반 Deployment 구분에서 특별한 spec을 정의하지 않으면 Default로 Rolling 전략으로 배포된다.
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080
strategy라는 파라미터를 추가로 주어서 명시적으로 정의할 수 도 있다.
- spec.strategy.rollingUpdate.maxUnavilable : Rolling Update중 Unavailable한 최대 Pod의 갯수
- spec.strategy.rollingUpdate.maxSurge : Rolling Update중 정해진 Pod 수 이상으로 만들 수 있는 Pod의 최대 개수
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
관련 kubectl
kubectl set image deployment/gs-spring-boot-docker-deployment gs-spring-boot-docker=nara0617/gs-spring-boot-docker:2.0 --record
//새로운 이미지로 Deployments를 업데이트 하는것, -recording중
kubectl rollout history deployment/gs-spring-boot-docker-deployment
//버전 변경에 대한 History는 다음과 같이 kubectl rollout history 명령어로 확인이 가능
kubectl rollout history deployment/gs-spring-boot-docker-deployment --revision=2
//수행된 Revision에 대한 명령어 상세 기록을 확인.
kubectl rollout undo deployment/gs-spring-boot-docker-deployment
//과거 버전으로 롤백할 때
2. Recreate
spec:
replicas: 3
strategy:
type: Recreate
template:
...
3. Blue/Green
아래의 순서로 진행된다.
1) 02버전의 Deployment를 생성
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"
2) 02버전의 Deployment의 서비스가 완전히 생성되고 서비스가 괜찮아 보이면 frontend 역할인 Service의 라우팅을 02버전 Deployment로 변경
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...
위 과정을 자동화 하기위한 Jenkins 스크립트도 있다. 아래 링크를 참고바람
스크립트 파일 : https://github.com/powerupcloud/TaxiCabApplication/blob/master/Jenkinsfile
4. Canary
적용순서는 다음과 같다.
1) Blue Deployment 생성
2) Ingress를 다이렉트 Traffic으로 Blue Deployment의 Service로 향하게 함
3) Green Deployment 생성
4) canary ingress로 10%만 Green Deployment의 Service로 향하게 함
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: canary-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
rules:
- host: kubesphere.io
http:
paths:
- backend:
serviceName: green-service
servicePort: 80
적절하게 로드벨런싱 되는지 테스트
for i in $(seq 1 10); do curl -s --resolve kubesphere.io:30205:192.168.0.88 kubesphere.io:30205 | grep "Hostname"; done
5) Green Deployment 에서 돌아가는 애플리케이션이 정상적이라고 판단되면 Ingress를 100% Green Deployment의 Service로 향하게함
= canary 옵션을 날려버리고 green-service로 향하게 ingress를 수정한다.
위 과정을 자동화 하기 위해서는Flagger, Istio and GitOps Pipelines 등으로 리소스를 만들어야 하는데 아래 링크를 참고하기 바란다.(추후 실제 구축과정을 상세히 설명하겠음)
'PaaS > Kubernetes' 카테고리의 다른 글
(Kubernetes) AWS Linux에 MasterNode 설치하기(Linux배포판 동일) (0) | 2021.08.18 |
---|---|
(Kubernetes) kubernetes 10.96.0.1 no route to host --DEBUG (0) | 2021.07.21 |
(Kubernetes) Kube-proxy, Kube-dns, core-dns (0) | 2021.04.13 |
Kubernetes Master/WorkerNode Server 설치하기(CentOS+Docker) (0) | 2021.04.11 |
(Kubernetes) 클러스터 디자인 하기 (0) | 2021.04.11 |