개요
지속적인 배포, 블루-그린 배포, 카나리아 배포 등과 같은 애플리케이션 배포 시나리오를 관리하기 위해 정기적으로 여러 배포를 사용합니다. 이 실습에서는 여러 이기종 배포가 사용되는 이러한 일반적인 시나리오를 수행할 수 있도록 컨테이너 확장 및 관리에 대한 실습을 제공합니다.
배포 소개
이기종 배포에는 일반적으로 특정 기술 또는 운영 요구 사항을 해결하기 위해 둘 이상의 별개의 인프라 환경 또는 지역을 연결하는 작업이 포함됩니다. 이기종 배포는 배포의 세부 사항에 따라 하이브리드, 멀티 클라우드 또는 퍼블릭-프라이빗이라고 합니다. 이 실습의 목적에 따라 이기종 배포에는 단일 클라우드 환경, 여러 퍼블릭 클라우드 환경(멀티 클라우드) 또는 온프레미스와 퍼블릭 클라우드 환경의 조합(하이브리드 또는 퍼블릭-프라이빗) 내의 지역에 걸친 배포가 포함됩니다.
단일 환경 또는 지역으로 제한된 배포에서는 다양한 비즈니스 및 기술 문제가 발생할 수 있습니다.
- 최대 리소스 : 모든 단일 환경, 특히 온프레미스 환경에서는 프로덕션 요구 사항을 충족하는 컴퓨팅, 네트워킹 및 스토리지 리소스가 없을 수 있습니다.
- 제한된 지리적 범위 : 단일 환경에 배포하려면 지리적으로 멀리 떨어져 있는 사람들이 하나의 배포에 액세스해야 합니다. 트래픽은 전 세계의 중앙 위치로 이동할 수 있습니다.
- 제한된 가용성 : 웹 규모의 트래픽 패턴은 애플리케이션이 내결함성과 탄력성을 유지하도록 요구합니다.
- 공급업체 종속 : 공급업체 수준 플랫폼 및 인프라 추상화로 인해 애플리케이션을 이식할 수 없습니다.
- 유연하지 않은 리소스 : 리소스가 특정 컴퓨팅, 스토리지 또는 네트워킹 오퍼링 세트로 제한될 수 있습니다.
이기종 배포는 이러한 문제를 해결하는 데 도움이 될 수 있지만 프로그래밍 방식의 결정론적 프로세스와 절차를 사용하여 설계해야 합니다. 일회성 또는 임시 배포 절차로 인해 배포 또는 프로세스가 취약해지고 장애를 견딜 수 없게 될 수 있습니다. 임시 프로세스는 데이터를 손실하거나 트래픽을 삭제할 수 있습니다. 좋은 배포 프로세스는 반복 가능해야 하며 프로비저닝, 구성 및 유지 관리를 위해 입증된 접근 방식을 사용해야 합니다. 이기종 배포에 대한 세 가지 일반적인 시나리오는 다중 클라우드 배포, 온프레미스 데이터 프론팅 및 CI/CD(지속적 통합/지속적 전달) 프로세스입니다.
1. 배포
gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"5개의 노드가 있는 클러스터를 만듭니다.
kubectl explain deploymentdeployment에 대한 설명을 보여주는 명령어입니다.
kubectl explain deployment --recursive--recursive 옵션을 사용하면 모든 필드에 대한 doployment 내용을 확인할 수 있습니다.
deployments/auth.yaml구성 파일을 업데이트합니다.
spec:
container:
image: "kelseyhightower/auth:1.0.0""kelseyhightower/auth:2.0.0"을 "kelseyhightower/auth:1.0.0"으로 업데이트를 해줍니다.
kubectl create -f deployments/auth.yamlkubectl create 인증 배포를 생성하기 위해 명령을 실행하면 배포 매니페스트의 데이터를 준수하는 하나의 포드가 생성됩니다. 이는 replicas필드에 지정된 수를 변경하여 Pod 수를 확장할 수 있음을 의미합니다.
kubectl get deployments배포를 생성한 후에는 생성되었는지 확인할 수 있습니다.
kubectl get replicasets배포가 생성되면 Kubernetes는 배포용 ReplicaSet을 생성합니다. 배포를 위해 ReplicaSet이 생성되었는지 확인할 수 있습니다.
kubectl get pods마지막으로 배포의 일부로 생성된 파드를 볼 수 있습니다. ReplicaSet이 생성될 때 Kubernetes에 의해 단일 Pod가 생성됩니다.
kubectl create -f services/auth.yaml이제 인증 배포를 위한 서비스를 만들 차례입니다. 위의 명령어를 사용해서 인증 서비스를 만듭니다.
kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yamlhello Deployment를 만들고 expose 합니다.
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.yamlfrontend 배포를 만들고 노출합니다.
kubectl get services frontendcurl -ks https://<EXTERNAL-IP>외부 IP에 curl 명령을 치면 Hello라고 잘 나오는 것을 확인하실 수 있습니다.
2. 확장
이제 배포가 생성되었으므로 확장할 수 있습니다.
kubectl scale deployment hello --replicas=5kubectl scale의 replicas 필드는 위의 명령어를 사용하여 쉽게 업데이트할 수 있습니다.
kubectl get pods | grep hello- | wc -l
kubectl scale deployment hello --replicas=3
kubectl get pods | grep hello- | wc -ldeployment가 업데이트되면 Kubernetes는 연결된 ReplicaSet을 자동으로 업데이트하고 새 Pod를 시작하여 총 Pod 수가 5가 되도록 한다. 이제 5개의 helloPod가 실행 중인지 확인합니다. 확인하는 명령어는 kubectl get pods | grep hello- | wc -l입니다. kubectl scale deployment hello --replicas=3은 애플리케이션의 replicas를 3으로 축소하는 명령어입니다.
롤링 업데이트
배포는 롤링 업데이트 메커니즘을 통해 이미지를 새 버전으로 업데이트하는 것을 지원합니다. Deployment가 새 버전으로 업데이트되면 새 ReplicaSet을 생성하고 이전 ReplicaSet의 복제본이 감소함에 따라 새 ReplicaSet의 복제본 수를 천천히 늘립니다.
deployments/auth.yaml구성 파일을 업데이트합니다.
spec:
container:
image: "kelseyhightower/auth:2.0.0""kelseyhightower/auth:1.0.0"을 "kelseyhightower/auth:2.0.0"으로 업데이트를 해줍니다.
편집기에서 저장하면 업데이트된 배포가 클러스터에 저장되고 Kubernetes가 롤링 업데이트를 시작합니다.
kubectl get replicaset
kubectl rollout history deployment/hello
실행 중인 롤아웃에서 문제가 감지되면 일시 중지하여 업데이트를 중지합니다.
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}'1번째 명령어는 중지시키는 명령어입니다. 2번째 명령어는 deployment의 상태를 확인하는 명령어입니다.
3번째 명령어는 Pod에서 확인하기 위한 명령어입니다.
kubectl rollout resume deployment/hello
kubectl rollout status deployment/hello롤아웃이 일시 중지되어 일부 포드는 새 버전이고 일부 포드는 이전 버전입니다. resume명령 을 사용하여 롤아웃을 계속할 수 있습니다.
status롤아웃이 완료되면 위의 status 명령어를 실행할 때 "hello" 성공적으로 롤아웃이 되었습니다라고 출력되어야 합니다.
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}'새 버전에서 버그가 감지되었다고 가정합니다. 새 버전에는 문제가 있는 것으로 추정되므로 새 Pod에 연결된 모든 사용자는 이러한 문제를 겪을 것입니다.
조사한 다음 제대로 수정된 버전을 릴리스할 수 있도록 이전 버전으로 롤백하고 싶을 것입니다.
다음 명령을 사용 rollout하여 이전 버전으로 롤백합니다.
카나리아 배포
사용자의 하위 집합을 사용하여 프로덕션에서 새 배포를 테스트하려는 경우 카나리아 배포를 사용합니다. Canary 배포를 사용하면 소규모 사용자 하위 집합에 대한 변경 사항을 릴리스하여 새 릴리스와 관련된 위험을 완화할 수 있습니다.
카나리아 배포는 새 버전이 포함된 별도의 배포와 정상적인 안정적인 배포와 카나리아 배포를 모두 대상으로 하는 서비스로 구성됩니다.
kubectl create -f deployments/hello-canary.yaml
kubectl get deploymentsCanary 배포가 생성된 후에는 hello 하고 hello-canary의 두 개의 배포가 있어야 한다.
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/versionhello요청에 의해 제공되는 버전을 확인할 수 있습니다. 이것을 여러 번 실행하면 일부 요청이 hello 1.0.0에서 제공되고 작은 하위 집합(1/4 = 25%)이 2.0.0에서 제공되는 것을 볼 수 있습니다.
블루 - 그린 배포
롤링 업데이트는 오버헤드를 최소화하고 성능에 미치는 영향을 최소화하며 가동 중지 시간을 최소화하면서 애플리케이션을 천천히 배포할 수 있기 때문에 이상적입니다. 새 버전이 완전히 배포된 후에만 해당 새 버전을 가리키도록 로드 밸런서를 수정하는 것이 유리한 경우가 있습니다. 이 경우 블루-그린 배포가 올바른 방법입니다.
Kubernetes는 두 개의 개별 배포를 생성하여 이를 달성합니다. 하나는 이전 "파란색" 버전용이고 다른 하나는 새 "녹색" 버전용입니다. hello"파란색" 버전에 대해 기존 배포를 사용합니다. 배포는 라우터 역할을 하는 서비스를 통해 액세스 됩니다.새로운 "그린" 버전이 실행되고 나면 서비스를 업데이트하여 해당 버전을 사용하도록 전환합니다.
블루-그린 배포의 주요 단점은 애플리케이션을 호스팅 하는 데 필요한 클러스터에 최소 2배의 리소스가 필요하다는 것입니다. 한 번에 두 버전의 애플리케이션을 모두 배포하기 전에 클러스터에 충분한 리소스가 있는지 확인하십시오.
kubectl apply -f services/hello-blue.yaml먼저 서비스를 업데이트합니다.
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녹색 배포가 있고 제대로 시작되면 현재 버전 1.0.0이 여전히 사용 중인지 확인합니다. 이제 새 버전을 가리키도록 서비스를 업데이트합니다. 서비스가 업데이트되면 "그린" 배포가 즉시 사용됩니다. 이제 새 버전이 항상 사용 중인지 확인할 수 있습니다.
kubectl apply -f services/hello-blue.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version필요한 경우 동일한 방식으로 이전 버전으로 롤백할 수 있습니다. "파란색" 배포가 계속 실행되는 동안 서비스를 이전 버전으로 다시 업데이트하기만 하면 됩니다. 서비스를 업데이트하면 롤백이 성공한 것입니다. 다시 한 번 올바른 버전이 사용 중인지 확인합니다.