[퀵랩] 고급 - 쿠버네티스 솔루션 01/08

안녕하세요, 오늘은 쿠버네티스 솔루션입니다.

공부할수록 쿠버네티스가 담고 있는 깊이가 깊다는 생각이 듭니다.

 

쿠버네티스가 낯선 분들께는 쿠버네티스 솔루션 핸즈온 랩을 통해서 실무에 대한 감을 익히시길 바라고,

현업에서 사용하시는 분들께는 조금이라도 도움이 되셨으면 하는 바람입니다.

 

이번 랩에서는 배포 시나리오에 대해서 다룹니다.

롤링 업데이트, 카나리 배포, 블루 그린이 그 시나리오들입니다.

추후 한번 같이 살펴보시고, 이종 배포에는 어떤 것이 있는지 알아보겠습니다.

(이종 배포는 다른 인프라 환경 혹은 리전에서 특정한 기술적, 운영적 필요에 의한 연결을 포함하는 것을 뜻합니다.)

 

싱글 클라우드를 통해서 싱글 리전에 클라우드를 구축하면 생길 수 있는 문제점은 다음과 같습니다.

 

1. 최대 리소스 제한

2. 지리적 범위 제한

3. 제한된 가용성

4. 벤더 락인

5. 유연성 없는 리소스

 

이 내용을 말하는 이유가 뭘까요?

 

 

바로 이기종 배포가 이를 해결할 수 있기 때문입니다.

임시방편으로 일회성/ 특수 목적의 애드혹 배포를 사용할 수 있지만,

이 같은 옵션은 장애, 트래픽 감소나 데이터 손실도 초래할 수 있습니다.

 

 

이번 랩에서는 다루는 내용이 많기 때문에 셋업 하기에 대한 내용은 제외하였습니다.

 

1) 먼저 존을 us-central1-a로 지정합니다.

gcloud config compute/zone us-central1-a

 

2) git code를 pull 해 옵니다.

git clone https://github.com/googlecodelabs/orchestrate-with-Kubernetes.git

cd orchestrate-with-kubernetes/kubernetes

 

3) 클러스터를 생성합니다.

gcloud container clusters create bootcamp --num-nodes 5 --scopes

“https://www.googleapis.com/auth/projectshooting, storage-rw”

 

--num-nodes 태그는 노드의 수를 5개로 설정하겠다는 내용이고,

--scopes는 인스턴스의 스코프를 지정해주는 태그입니다.

 

 

이제 배포를 알아보도록 합시다.

리소스에 대해 알아보기 위해서

kubectl explain deployment

를 실행하면, 배포에 대한 설명을 볼 수 있습니다.

kubeclt explain deployment.metadata.name

해당 명령을 수행하면 배포에 대한 메타 데이터를 확인할 수 있습니다.

vi deployments/auth.yaml

명령어를 실행하여, auth.yaml 파일에 접근합니다.

 

 

i를 눌러 배포에 대한 버저닝을 해줍니다.

배포 버전이 2.0.0으로 되어 있는 내용을 1.0.0으로 변경합니다.

:wq

를 통해서 파일을 쓰고 나옵니다.

cat deployments/auth.yaml

을 통해서 변경된 것을 확인합니다.

 

 

이제 본격적으로 디플로이먼트를 만들어 봅시다.

 

kubectl create -f deployments/auth.yaml

-f 태그는 파일 위치를 deployments 폴더 아래의 auth.yaml 파일을 통해 디플로이먼트를 만듭니다.

kubectl get deployments

디플로이먼트가 만들어졌는지 확인합니다.

kubectl get replicasets

레플리카셋을 가져와 봅시다.

kubectl get pods

파드를 확인합니다.

kubectl create -f services/auth.yaml

services 폴더 밑에 있는 auth.yaml 파일을 통해서 서비스를 만들어 봅시다.

kubectl create -f deployments/hello.yaml

이번엔 deployments 폴더 밑에 있는 hello.yaml 파일을 통해서 디플로이먼트를 만들어 봅니다.

kubectl create -f services/hello.yaml

hello.yaml 파일을 통해서 서비스를 만듭니다.

 

 

kubectl create secret generic tls-certs --from-file tls/

를 통해서 시크릿을 만듭니다.

 

시크릿은 비밀번호, OAuth 등의 민감정보를 저장하는 공간입니다.

https://cloud.google.com/kubernetes-engine/docs/concepts/secret?hl=ko

보안 비밀  |  Kubernetes Engine 문서  |  Google Cloud

kubectl create configmap nginx—frontend-conf --from-file=nginx/frontend.conf

를 통해서 configmap을 만듭니다.

 

다음으로 configmap을 만듭니다.

configmap은 구성 파일, 환경 변수, 포트 번호, 기타 구성 등을 컨테이너와 별도로 저장하는 공간입니다.

configmap과 시크릿은 비슷하지만, 시크릿은 비밀 정보 등을 저장하는 공간이고

configmap은 환경 변수와 구성 파일 등 보안적인 필요성이 상대적으로 적은 공간입니다.

https://cloud.google.com/kubernetes-engine/docs/concepts/configmap

ConfigMap  |  Kubernetes Engine 문서  |  Google Cloud

kubectl create -f deployments/frontend.yaml

다음으로 frontend.yaml 파일을 통해서 디플로이먼트 객체를 생성하겠습니다.

kubectl create -f services/frontend.yaml

그러고 나서 서비스를 생성해보겠습니다.

kubectl get services frontend

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

프런트엔드 서비스에서 외부 아이피를 가져와 봅시다.

curl -ks https://`kubectl get svc frontend

     -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

위의 명령어로 불러올 수도 있고, 이 명령어를 통해 가져올 수도 있습니다.

 

 

다음으로 디플로이먼트 스케일링을 해보도록 하겠습니다.

kubectl explain deployment.spec.replicas

다음의 명령어를 통해서 디플로이먼트의 레플리카 타겟 상태가 여기에 표기됩니다.

kubectl scale deployment hello --replicas=5

scale을 통해서 deployment 객체를 5개로 늘리는 작업을 합니다.

파드를 새로 실행하기까지 시간이 걸립니다.

kubectl get pods | grep hello- | wc -l

grep 명령어를 통해 hello로 시작하는 파드의 워드 카운트를 셉니다.

kubectl scale deployment hello --replicas=3

레플리카 3개로 스케일을 통해 돌려놓아 봅시다.

kubectl get pods | grep hello- | wc -l

다시, 5-> 3개로 줄어들었는지 확인해 봅시다.

 

이번엔 이기종 배포 방식의 하나인 롤링 업데이트입니다.

롤링 업데이트는 하루에도 여러 번 새 버전의 배포가 필요한 유저와 개발자 모두를 만족시키기 위한 메커니즘입니다.

 

롤링 업데이트는 파드 인스턴스 수를 늘려서 배포의 업데이트를 가능하게 하고, 새 버전으로 업데이트를 진행합니다.

신 버전의 레플리카를 만들고, 점차적으로 레플리카 수를 늘려나가는 반면 구버전의 레플리카는 줄여나가는 식으로 진행됩니다.

 

 

#1. 실행 하기

 

kubectl edit deployment hello

명령어를 실행해서 디플로이먼트의 내용을 업데이트해 봅시다.

containers 오브젝트의 image라는 내용을 1.0.0에서 2.0.0으로 업데이트합니다.

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}'

파드를 왼쪽의 명령어를 통해서도 직접 확인이 가능합니다.

 

#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}'

파드를 왼쪽의 명령어를 통해서도 직접 확인이 가능합니다.

 

 

카나리 배포는 적은 위험 부담으로도 새로운 배포에 대한 테스트를 가능하게 합니다.

서브셋을 나누어서 배포를 진행할 수 있는데,  구버전의 배포는 유지하고 신버전의 배포는 서브셋의 크기를

적게 해서 진행할 수 있습니다.

 

새 버전을 위한 카나리를 만들기 위해

cat deployments/hello-canary.yaml

을 실행해 줍시다.

 

 

kubectl create -f deployments/hello-canary.yaml

해당 명령어를 실행해서 hello-canary에 대한 디플로이먼트를 만듭니다.

kubectl get deployments

잘 만들어졌는지 확인해 봅시다.

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

해당 명령어를 통해서 hello에 대한 디플로이먼트를 확인해 봅니다.

hello 1.0.0(구 버전)은 100%, hello 2.0.0(신 버전)은 25%만 가지고 구동이 되는 것을 확인할 수 있습니다.

 

세션 

이번 랩에서는 Nginx로 전송된 요청들은 카나리 배포가 제공되었습니다..

만약에  카나리아 배포를 사용하길 원치 않는다면?

애플리케이션의 UI가 바뀔 것이고, 유저를 혼동시키는 결과를 초래할 수 있는데, 이런 방법을 원하지는 않을 것입니다.

그래서 추가하는 옵션이 sessionAffinity입니다.

이 방식으로 유저들이 접근할 버전을 정해줄 수가 있습니다.

ClientIp로 지정했는데, 같은 IP를 지닌 모든 클라이언트들은

리퀘스트를 hello로 날리게 됩니다.

 

sessionAffinity라는 것을 직역해보면 세션 친화성이라고 할 수 있는데,

특정 클라이언트가 접속하면 동일한 파드로 라우팅 해주는 서비스입니다.

기본 sessionAffinity는 none으로 설정되어 있습니다.

 

블루 그린 배포에 대해서 설명드리겠습니다. 구버전과 신버전 모두 같이 사용하여 배포하는 경우가 되겠는데,

신버전, 구버전을 동시에 똑같이 배포합니다. 컴퓨팅 리소스 공간 역시 2배로 차지되는 것이 특징입니다.

 

 

 

kubectl apply -f services/hello-blue.yaml

블루 버전의 서비스를 적용해 봅시다.

kubectl apply -f services/hello-green.yaml

이 명령어를 실행해서 그린 버전으로 만듭니다.

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

서비스의 업데이트가 진행됨과 동시에 “그린” 배포가 바로 사용될 것입니다.

왼쪽의 명령어를 통해 언제든 확인할 수 있습니다.

 

 

kubectl apply -f services/hello-blue.yaml

다음의 명령어를 통해서 다시 블루 버전을 적용할 수 있습니다.

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

다시 해당 명령어를 통해 블루 버전이 적용됐는지 확인해 봅시다.

 

 

이번 랩을 통해서 쿠버네티스를 통한 배포관리를 배웠습니다.

kubectl 커맨드 라인을 더 다뤄볼 수 있었고,

YAML 파일의 실행을  통한 셋업으로 다양한 배포 스타일,

업데이트, 스케일링하는 방법들을 익힐 수 있었습니다.

이번 기초 랩을 통해서 DevOps 감을 편히 익히는데 도움이 되셨을 것입니다.