[Google Cloud 실습] Kubenetes Engine으로 배포 관리

Photo by Joao Branco on Unsplash

 

원제 - Managing Deployments Using Kubernetes Engine

이 문서는 아래의 링크에 있는 Lab(실습내용)을 진행하며 관련 내용을 정리하는 차원에서 작성하였다.

https://www.cloudskillsboost.google/focuses/639?parent=catalog

이 Lab은 Google Cloud의 Kubernetes(Kubernetes in Google Cloud) 퀘스트 내부에 있는 네 번째 Lab에 해당한다.

https://www.cloudskillsboost.google/quests/29

개요

Dev Ops 방식에서는 정기적으로 여러 배포를 사용하여 ‘지속적 배포', ‘Blue/Green 배포’, ‘Canary 배포'와 같은 애플리케이션 배포 시나리오를 관리한다. 이 실습에서는 여러 이기종 배포가 사용되는 일반적인 시나리오를 처리할 수 있도록 컨테이너를 확장 및 관리하는 연습이 제공된다.

DevOps(데브옵스)란?

DevOps는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말함. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며, 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

실습내용

• kubectl 도구 사용 연습
• 배포 yaml 파일 만들기
• 배포 시작, 업데이트 및 확장
• 배포 및 배포 스타일 업데이트 연습

 

과정

1단계 - 영역 설정, 샘플코드 가져오기

gcloud config set compute/zone us-central1-a

gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes .
cd orchestrate-with-kubernetes/kubernetes

# bootcamp라는 이름으로 5개의 노드를 갖는 클러스터를 만드는 작업 수행
gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

노드 생성시 시간이 다소 소요되며, 아래와 같은 결과로 잘 설정됨을 볼 수 있음

• gsutil
  • gsutil은 명령줄에서 Cloud Storage에 액세스하는 데 사용할 수 있는 Python 애플리케이션이다. gsutils로 다음과 같은 광범위한 버킷 및 객체 관리작업을 수행할 수 있다.
  • 버킷 생성 및 삭제, 객체 업로드, 다운로드, 삭제, 버킷 및 객체 나열, 객체 이동, 복사 및 이름 바꾸기, 객체 및 버킷 ACL 수정
  • https://cloud.google.com/storage/docs/gsutil?hl=ko
• gcloud container
  • 실행중인 컨테이너를 위한 머신의 클러스터를 배포하고 관리하는 명령어
  • scopes는 full uri나 alias로 사용이 가능하다.
    https://cloud.google.com/sdk/gcloud/reference/container/clusters/create
    
    

2단계 - 배포 객체에 대해 알아보고 배포 만들기

1) 배포 객체에 대해 알아보기

# 배포 객체에 대해 1 depth 설명 보기
kubectl explain deployment

# 하위의 모든 객체까지도 포함되어 볼 수 있음(목록위주)
kubectl explain deployment --recursive

# 반대로 특정 객체에 대해 상세히 알 수 있음
kubectl explain deployment.metadata.name

2) 배포 만들기

vi deployments/auth.yaml

kubectl create -f deployments/auth.yaml

kubectl get deployments

kubectl get replicasets

kubectl get pods

# 서비스 매니페스트 파일로 서비스 배포
kubectl create -f services/auth.yaml

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

# frontend 배포를 만들고 노출
kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

# 외부 IP를 얻어와서 frontend와 연결시킴
kubectl get services frontend

curl -ks https://<EXTERNAL-IP>

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

3단계 - 배포 확장

spec.replicas 필드를 업데이트 하면 확장이 가능하다. 이 필드에 대한 설명을 참고하면 자세히 알 수 있다.

kubectl explain deployment.spec.replicas

# pod을 5개 실행하도록 확장
kubectl scale deployment hello --replicas=5

# pod이 5개 실행되고 있는지 체크하고, 3개로 변경하여 확인 진행
kubectl get pods | grep hello- | wc -l

kubectl scale deployment hello --replicas=3

kubectl get pods | grep hello- | wc -l

4단계 - 순차적 업데이트

replica: 복제품

roll-out: 출시

1) replicaset 롤아웃

kubectl edit deployment hello

# 아래 명령어는 kubectl get rs로 줄여서도 표현 가능
kubectl get replicaset

kubectl rollout history deployment/hello

2) 순차적 업데이트 일시 중지 및 재개하기

kubectl rollout pause deployment/hello

kubectl rollout status deployment/hello

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

# 업데이트 재개
kubectl rollout resume deployment/hello

kubectl rollout status deployment/hello

3) 업데이트 롤백하기

kubectl rollout undo deployment/hello

kubectl rollout history deployment/hello

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

5단계 - Canary 배포

프로덕션 환경에서 일부 사용자를 대상으로 새 배포를 테스트하려면 Canary 배포를 사용하면 된다. Canary 배포를 사용하면 작은 규모의 일부 사용자에게만 변경 사항을 릴리즈하여 새로운 릴리즈와 관련된 위험을 완화할 수 있다.

• Canary?

Canary는 카니리아라는 새를 일컫는 말이다. 이 새는 일산화탄소 및 유독가스에 매우 민감하다고 한다. 그래서 과거 광부들이 이 새를 옆에 두고 광산에서 일하다가 카나리아가 갑자기 죽게 되면 대피를 했다고 한다.

Canary 배포는 카나리아 새처럼 위험을 빠르게 감지할 수 있는 배포 기법이다. 구 버전의 서버와 신 버전의 서버들을 구성하고 일부 트래픽을 새 버전으로 분산하여 오류 여부를 판단한다. 이 기법으로 A/B 테스트도 가능하고, 오류율 및 성능 모니터링에 유용하게 사용이 가능하다. 트래픽을 분산시킬 라우팅은 랜덤으로 할 수도 있고, 사용자 프로필 등을 기반으로 분류할 수도 있다. 분산 후 결과에 따라 새 버전이 운영 환경을 대체할 수도 있고, 다시 구 버전으로 돌아갈 수도 있다.

1) Canary 배포

cat deployments/hello-canary.yaml

kubectl create -f deployments/hello-canary.yaml

kubectl get deployments

# Canary 배포 확인
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Canary 배포를 한 뒤, 여러 번 요청하면, 일부 요청은 hello 1.0.0에서 제공하며, 소규모로된 일부 하위 집합은 2.0.0으로 제공됨을 볼 수 있다.(1/4인 25퍼센트)

2) 프로덕션 환경의 Canary 배포시 - 세션 어피니티 사용

지금은 nginx서비스로 전송된 모든 요청이 Canary 배포에 노출된 상태이다. 하지만 어떤 사용자가 Canary 배포를 받지 못하게 하려면 해당 사용자를 지정한 배포로 고정시켜야 한다.

서비스와 함께 세션 어피니티를 만들면 동일한 사용자에게 항상 동일한 버전을 제공할 수 있다. 아래처럼 제공시 서비스는 이전과 동일하지만, sessionAffinity 필드가 추가되어 ClientIP로 설정하게 되는데, IP주소가 동일한 모든 클라이언트에서는 동일한 버전의 애플리케이션으로 요청을 보낸다.

kind: Service
apiVersion: v1
metadata:
  name: "hello"
spec:
  sessionAffinity: ClientIP
  selector:
    app: "hello"
  ports:
    - protocol: "TCP"
      port: 80
      targetPort: 80

6단계 - Blue/Green 배포

Blue/Green 배포는 구 버전에서 신 버전으로 일제히 전환하는 전략이다. 구 버전의 서버와 신 버전의 서버들을 동시에 나란히 구성하고 배포 시점이 되면 트래픽을 일제히 전환시킨다. 하나의 버전만 프로덕션 되므로 버전 관리 문제를 방지할 수 있고, 또한 빠른 롤백이 가능하다. 또 다른 장점으로 운영 환경에 영향을 주지 않고, 실제 서비스 환경으로 새 버전 테스트가 가능하다.

예를 들어 구 버전과 신 버전을 모두 구성하고 포트를 다르게 주거나 내부 트래픽일 경우 신 버전으로 접근하도록 설정하여 테스트를 진행해 볼 수 있다. 단, 시스템 자원이 두 배로 필요하고, 전체 플랫폼에 대한 테스트가 진행되어야 한다.

# Blue/Green 배포
kubectl create -f deployments/hello-green.yaml

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

kubectl apply -f services/hello-green.yaml

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

# Blue/Green 롤백
kubectl apply -f services/hello-blue.yaml

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

마치며

이 실습을 통해 Kubenetes를 이용하여 배포를 관리하였다. kubectl 커맨드라인 명령어, yaml 파일에 설정된 여러가지 배포 구성 스타일을 다양하게 사용하여 배포를 시작하고, 업데이트 및 확장해 볼 수 있다. 이를 기반으로 DevOps 작업에 이러한 기술을 손쉽게 적용할 수 있다.

참고자료

• DevOps 용어: https://ko.wikipedia.org/wiki/데브옵스
• Blue/Green, Canary 용어: https://onlywis.tistory.com/10