스터디에서 준비해야 할 내용 리스트
Kubernetes 에서 Blue/Green 배포하는 방법을 알아보자.
Container 이미지는 nginx 를 상속받아 쉽게 만들 수 있다. nginx 가 바라보는 web root 는 /usr/share/nginx/html 이므로 여기에 blue 버전을 표시할 수 있는 html 을 넣어준다.
<!DOCTYPE html>
<html>
<body style="background-color:blue;">
<h1>This is a blue webserver</h1>
</body>
</html>index-blue.html 을 index.html 로 변경하여 복사한다.
FROM nginx
COPY index-blue.html /usr/share/nginx/html/index.htmlseungkyua/nginx:blue 이름과 태그를 갖는 Container 이미지를 만든다.
$ docker build -t seungkyua/nginx:blue -f Dockerfile-blue . 이미지가 정확한지 test 해본다.
$ docker run --rm -d -p 8080:80 --name nginx-blue seungkyua/nginx:blue
$ curl localhost:8080
<!DOCTYPE html>
<html>
<body style="background-color:blue;">
<h1>This is a blue webserver</h1>
</body>
</html>이미지가 잘 확인되었으니 docker hub 에 push 한다.
$ docker login -u seungkyua
password:
$ docker push seungkyua/nginx:blue같은 방식으로 Green 이미지를 만들어서 docker hub 에 push 한다.
<!DOCTYPE html>
<html>
<body style="background-color:green;">
<h1>This is a green webserver</h1>
</body>
</html>$ cat Dockerfile-green
FROM nginx
COPY index-green.html /usr/share/nginx/html/index.html$ docker build -t seungkyua/nginx:green -f Dockerfile-green .
$ docker push seungkyua/nginx:green이미지가 준비되었으니 Blue 버전의 deployment 와 service yaml 을 만들어 배포한다.
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx-blue
name: nginx-blue
spec:
replicas: 2
selector:
matchLabels:
app: nginx-blue
version: blue
template:
metadata:
labels:
app: nginx-blue
version: blue
spec:
containers:
- image: seungkyua/nginx:blue
name: nginx$ kubectl apply -f nginx-blue-deploy.yamlService 를 배포할 때는 Blue pod 의 label 을 selector 로 지정해 줘야 한다.
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx-blue-green
name: nginx-blue-green-svc
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx-blue
version: blue
type: LoadBalancer$ kubectl apply -f nginx-blue-green-svc.yamlblue version 은 웹 브라우저에서 접속하기 위해서 Service 를 LoadBalancer 타입으로 생성하였다.
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.233.0.1 <none> 443/TCP 12d
nginx-blue-green-svc LoadBalancer 10.233.30.78 aa1d4e1994e454eb5aea607cfdfd3dcf-23761053.ap-northeast-2.elb.amazonaws.com 80:32234/TCP 5m18s웹브라우저에 접속하면 아래와 같이 blue 버전으로 접속이 된다.
이제 새로운 버전인 Green 버전을 배포해 보자. image 와 label 을 잘 확인해야 한다.
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx-green
name: nginx-green
spec:
replicas: 2
selector:
matchLabels:
app: nginx-green
version: green
template:
metadata:
labels:
app: nginx-green
version: green
spec:
containers:
- image: seungkyua/nginx:green
name: nginx$ kubectl apply -f nginx-green-deploy.yamlService 는 Green 배포가 잘 되었는지 확인하기 위해서 Service 를 NodeType 으로 적용하였다.
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx-green
name: nginx-green-svc
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
nodePort: 32080
selector:
app: nginx-green
version: green
type: NodePort$ kubectl apply -f nginx-green-svc.yamlgreen pod 가 떠 있는 노드를 확인한다.
여기서는 172.31.49.87 노드와 172.31.46.179 노드에 pod 가 생성되어 있다.
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-blue-69dd468cf4-nts5h 1/1 Running 0 6m7s 10.233.114.152 ip-172-31-49-87.ap-northeast-2.compute.internal <none> <none>
nginx-blue-69dd468cf4-xvxqz 1/1 Running 0 6m7s 10.233.110.80 ip-172-31-46-179.ap-northeast-2.compute.internal <none> <none>
nginx-green-7df845c6cf-mpj6b 1/1 Running 0 8s 10.233.114.153 ip-172-31-49-87.ap-northeast-2.compute.internal <none> <none>
nginx-green-7df845c6cf-pvmrc 1/1 Running 0 8s 10.233.110.81 ip-172-31-46-179.ap-northeast-2.compute.internal <none> <none>curl 명령어로 Green 이 정상적으로 배포되었는지 확인한다.
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.233.0.1 <none> 443/TCP 12d
nginx-blue-green-svc LoadBalancer 10.233.30.78 aa1d4e1994e454eb5aea607cfdfd3dcf-23761053.ap-northeast-2.elb.amazonaws.com 80:32234/TCP 5m18s
nginx-green-svc NodePort 10.233.33.157 <none> 80:32080/TCP 12s$ curl 172.31.49.87:32080
<!DOCTYPE html>
<html>
<body style="background-color:green;">
<h1>This is a green webserver</h1>
</body>
</html>이제 LoadBalancer 타입으로 생성된 nginx-blue-green-svc 가 Green Pod 로 연결되게 selector 를 Green pod 가 선택되게 변경한다.
$ kubectl patch svc nginx-blue-green-svc -p '{"spec": {"selector": {"app": "nginx-green", "version": "green"}}}'웹브라우저로 접속하면 Green 으로 변경된 것을 확인할 수 있다.
Argo rollout 은 Progressive Delivery 를 지원하는 툴이다.
아래의 그림에서 보듯이 Canary 배포를 진행할 때 일시적으로 배포를 홀딩한 상태에서 new version 에 대한 배포가 성공되었는지를 Metric 으로 판단하여 안전하게 배포를 완료할 수 있다. (metric 수집과 쿼리는 Prometheus 를 포함하여 다양한 모니터링 툴을 지원한다.)
Metric 을 통해 배포의 성공 여부를 판단하여 rollback 할 것인지, 계속 진행할 것인지를 결정할 수 있다는 것이 중요한 키 포인트다. 왜냐하면 쿠버네티스의 롤링 업데이트는 readiness 로 배포 성공여부를 판단하는데 이는 Metric 보다 판단하기에 부족할 수 있고, 중간에 에러가 발생하면 멈출 수 는 있지만 자동으로 rollback 되지는 않기 때문이다.
# kubectl create namespace argo-rollouts
# kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
# curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
# chmod +x ./kubectl-argo-rollouts-linux-amd64
# mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts
# kubectl argo rollouts version
# cd ~/argo-rollout-demo
# curl -Lo basic-rollout-blue.yaml https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
# curl -Lo basic-service.yaml https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml
# kubectl apply -f basic-rollout-blue.yaml
# kubectl apply -f basic-service.yaml
# kubectl patch svc rollouts-demo --patch \
'{"spec": { "type": "NodePort", "ports": [ { "nodePort": 31080, "port": 80, "protocol": "TCP", "targetPort": "http", "name": "http" } ] } }'
화면 접속
http://k2-master01:31080
콘솔 보기
# kubectl argo rollouts get rollout rollouts-demo --watch
# kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow
rollout 전략이 처음 step 은 20% 만 변경하는 것이기 때문에 5개의 replica 중에 1개만 old version(blue) 이고 4 개는 new version(yellow) 이다. 그리고 현재는 pause (일시멈춤) 상태로 더이상 rollout 배포가 진행되지 않고 있다.
# kubectl argo rollouts promote rollouts-demo
promote 로 계속 rollout 업그레이드를 진행하면 점차 new version 이 revision:2 영역인 canary 로 replica 개수를 증가시키는 것을 볼 수 있다. duration 을 10으로 주었기 때문에 10 초 단위로 20% 씩 자동으로 올려준다.
일정 시간이 다 지나면 전체가 전부 다 업그레이드 된다.
argo rollout 은 metric 으로 정의한 성공 여부에 따라 배포를 계속 진행할 것인지 아니면 abort 시킬 것인지를 자동으로 결정할 수 있다.
 Seungkyu Ahn's Blog, Kubernetes, Container, CNCF, OpenStack, Linux, Programming and so on by seungkyua@gmail.com |
||
|
