[Kubernetes 입문] Managing Deployments Using Kubernetes Engine

Managing Deployments Using Kubernetes Engine

---

Managing Deployments Using Kubernetes Engine

Kubernetes Engine으로 배포 관리 | Google Cloud Skills Boost

 

1. 개요

- Dev Ops는 "Continuous Deployment", "Blue-Green Deployments", "Canary Deployments" 등과 같은 애플리케이션 배포 시나리오를 관리하기 위해 정기적으로 여러 배포를 사용

2. Introduction to deployments

- Heterogeneous 배포에는 일반적으로 특정 기술 또는 운영 요구 사항을 해결하기 위해 둘 이상의 별개의 인프라 환경 또는 지역을 연결하는 작업이 포함됨

- 배포의 세부사항에 따라

• hybrid
• multi-cloud
• public-private

- 단일 환경 또는 지역으로 제한된 배포에서는 다양한 비즈니스 및 기술 문제가 발생

• 최대 리소스: 모든 단일 환경, 특히 온프레미스 환경에서는 프로덕션 요구 사항을 충족하는 컴퓨팅, 네트워킹 및 스토리지 리소스가 없을 수 있음
• 제한된 지리적 범위: 단일 환경에 배포하려면 지리적으로 멀리 떨어져 있는 사람들이 하나의 배포에 액세스함. 트래픽은 전 세계의 중앙 위치로 이동 가능
• 제한된 가용성: 웹 규모의 트래픽 패턴은 애플리케이션이 내결함성과 탄력성을 유지하도록 요구
• 공급업체 종속: 공급업체 수준 플랫폼 및 인프라 추상화로 인해 애플리케이션을 이식할 수 없음
• 유연하지 않은 리소스: 리소스가 특정 컴퓨팅, 스토리지 또는 네트워킹 오퍼링 세트로 제한될 수 있음

- Heterogeneous 배포는 이러한 문제를 해결하는 데 도움이 될 수 있지만 프로그래밍 방식의 결정론적 프로세스와 절차를 사용하여 설계해야 함

• 임시 프로세스는 데이터를 손실하거나 트래픽을 삭제할 수 있음
• 좋은 배포 프로세스는 반복 가능해야 하며 프로비저닝, 구성 및 유지 관리를 위해 입증된 접근 방식을 사용해야 함

- Heterogeneous 배포에 대한 세 가지 일반적인 시나리오

• 다중 클라우드 배포
• 온프레미스 데이터 프론팅
• CI/CD(지속적 통합/지속적 전달) 프로세스

3. Setup

 - Google Cloud Platform(GCP) 환경 설정

1) 샘플 코드 받기

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

 

2) 5개의 노드가 있는 클러스터 생성

gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

4. Learn about the deployment object

1) Deployment 개체 확인

kubectl explain deployment

 

2) 모든 필드 확인

kubectl explain deployment --recursive

kubectl explain deployment.metadata.name

5. Create a deployment

1) deployments/auth.yaml 구성 파일 업데이트

vi deployments/auth.yaml

 

2) image배포의 컨테이너 섹션 변경

...
containers:
- name: auth
  image: "kelseyhightower/auth:1.0.0"
...

 

3) 배포 구성 파일 검사

cat deployments/auth.yaml

 - Output

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth
spec:
  replicas: 1
  selector:
    matchLabels:
      app: auth
  template:
    metadata:
      labels:
        app: auth
        track: stable
    spec:
      containers:
        - name: auth
          image: "kelseyhightower/auth:1.0.0"
          ports:
            - name: http
              containerPort: 80
            - name: health
              containerPort: 81
...

 - 인증 배포를 생성하기 위해 kubectl create 명령을 실행하면, 배포 매니페스트의 데이터를 준수하는 하나의 포드가 생성

 - replicas 필드에 지정된 수를 변경하여 파드 수를 확장할 수 있음을 의미

 

4) 배포 개체 생성

kubectl create -f deployments/auth.yaml

 

5) 생성된 배포 확인

kubectl get deployments

 - 배포가 생성되면 Kubernetes는 배포용 ReplicaSet을 생성

 

6) ReplicaSet 생성 확인

kubectl get replicasets

 - auth-xxxxxxx와 같은 이름의 ReplicaSet이 표시되어야 함

 

7) 배포의 일부로 생성된 Pod 확인

kubectl get pods

-  ReplicaSet이 생성될 때 Kubernetes에 의해 단일 Pod가 생성됨

 

8) 인증 서비스 생성

kubectl create -f services/auth.yaml

 

9) hello Deployment를 생성하고 노출

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

 

10) 프론트엔드 배포를 생성하고 노출

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

 

11) 프론트엔드와 상호작용

kubectl get services frontend

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

 

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

 

12) 배포 확장

 (1) spec.replicas 필드 업데이트

kubectl explain deployment.spec.replicas

 

 (2) replicas 필드 업데이트

kubectl scale deployment hello --replicas=5

- 배포가 업데이트되면 Kubernetes는 연결된 ReplicaSet을 자동으로 업데이트하고

- 새 Pod를 시작하여 총 Pod 수가 5가 되도록 함

 

 (3) 5개의 hello Pod가 실행 중인지 확인

kubectl get pods | grep hello- | wc -l

 

 

 (4) 애플리케이션 축소

kubectl scale deployment hello --replicas=3

 

 (5) Pod 개수 확인

kubectl get pods | grep hello- | wc -l

6. Rolling update

- 배포는 롤링 업데이트 메커니즘을 통해 이미지를 새 버전으로 업데이트하는 것을 지원

- 배포가 새 버전으로 업데이트되면 새 ReplicaSet을 생성하고 이전 ReplicaSet의 복제본이 감소함에 따라 새 ReplicaSet의 복제본 수를 천천히 늘림

 

1) 롤링 업데이트 트리거

 (1) 배포 업데이트

kubectl edit deployment hello

 

 (2) 배포의 컨테이너 섹션에서 image 변경

...
containers:
  image: kelseyhightower/hello:2.0.0
...

  - 편집기에서 저장하면 업데이트된 배포가 클러스터에 저장되고 Kubernetes가 롤링 업데이트를 시작

 

 (3) Kubernetes가 생성하는 새로운 ReplicaSet 참조

kubectl get replicaset

 

 (4) rollout history

kubectl rollout history deployment/hello

 

2) 롤링 업데이트 재개

 (1) 롤아웃 재개

kubectl rollout resume deployment/hello

 

 (2) 롤아웃 완료 확인

kubectl rollout status deployment/hello

 

3) 업데이트 롤백

 (1) 이전 버전으로 롤백

kubectl rollout undo deployment/hello

 (2) 롤백 확인

kubectl rollout history deployment/hello

 (3) 모든 Pod가 이전 버전으로 롤백되었는지 확인

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

7. Canary deployments

- 사용자의 하위 집합을 사용하여 프로덕션에서 새 배포를 테스트하려는 경우 카나리아 배포 사용

- Canary 배포를 사용하면 소규모 사용자 하위 집합에 대한 변경 사항을 릴리스하여 새 릴리스와 관련된 위험을 완화

 

1) 카나리아 배포 만들기

 - 카나리아 배포는 새 버전이 포함된 별도의 배포와 정상적인 안정적인 배포와 카나리아 배포를 모두 대상으로 하는 서비스로 구성

 (1) 새 버전에 대한 새 카나리아 배포 생성

cat deployments/hello-canary.yaml

 

 (2) 카나리아 배포 생성

kubectl create -f deployments/hello-canary.yaml

 

 (3) 배포 생성 확인(hello, hello-canary)

kubectl get deployments

 - hello서비스에서 선택기는 제품 배포 및 카나리아 배포 모두에서 포드와 일치하는 선택기를 사용

 - 그러나 카나리아 배포에는 포드 수가 적기 때문에 더 적은 수의 사용자에게 표시

 

2) 카나리아 배포 확인

 - 제공되는 버전 확인

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

  - 여러 번 실행하면 일부 요청이 hello 1.0.0에서 제공되고, 작은 하위 집합(1/4 = 25%)이 2.0.0에서 제공되는 것 볼 수 있음

 

3) 프로덕션의 카나리아 배포 - 세션 선호도

- 세션 선호도가 있는 서비스를 만들면 동일한 사용자가 항상 동일한 버전에서 서비스를 받게 됨

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

 - 서비스는 이전과 동일하지만 새로운 sessionAffinity필드가 추가되어 ClientIP로 설정됨

 - 동일한 IP 주소를 가진 모든 클라이언트는 동일한 버전의 hello애플리케이션으로 요청을 보냄

8. Blue-green deployments

- 롤링 업데이트는 오버헤드를 최소화하고 성능에 미치는 영향을 최소화하며 가동 중지 시간을 최소화하면서 애플리케이션을 천천히 배포할 수 있기 때문에 이상적임

- 완전히 배포된 후에만 해당 새 버전을 가리키도록 로드 밸런서를 수정하는 것이 유리한 경우, 블루-그린 배포 사용

•  Kubernetes는 두 개의 개별 배포를 생성하여 이를 달성
• 하나는 이전 "파란색" 버전용이고 다른 하나는 새 "녹색" 버전용
• "파란색" 버전에 대해 기존 배포 사용
• 배포는 라우터 역할을 하는 서비스를 통해 액세스됨
• 새로운 "그린" 버전이 실행되고 나면 서비스를 업데이트하여 해당 버전을 사용하도록 전환

1) 서비스  업데이트

kubectl apply -f services/hello-blue.yaml

 - 기존의 hello 서비스를 사용하되 선택자 app:hello, version: 1.0.0를 갖도록 업데이트

 - 선택기는 기존 "파란색" 배포와 일치

 - 다른 버전을 사용하므로 "녹색" 배포와 일치하지 않음

 

2) 블루-그린 배포를 사용하여 업데이트

 - 블루-그린 배포 스타일을 지원하기 위해 새 버전에 대한 새로운 "그린" 배포 생성

 - 녹색 배포는 버전 레이블과 이미지 경로를 업데이트

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
        track: stable
        version: 2.0.0
    spec:
      containers:
        - name: hello
          image: kelseyhightower/hello:2.0.0
          ports:
            - name: http
              containerPort: 80
            - name: health
              containerPort: 81
          resources:
            limits:
              cpu: 0.2
              memory: 10Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 81
              scheme: HTTP
            initialDelaySeconds: 5
            periodSeconds: 15
            timeoutSeconds: 5
          readinessProbe:
            httpGet:
              path: /readiness
              port: 81
              scheme: HTTP
            initialDelaySeconds: 5
            timeoutSeconds: 1

 

 (1) 그린 배포 생성

kubectl create -f deployments/hello-green.yaml

 

 (2) 현재 버전 1.0.0 확인

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

 

 (3) 새 버전을 가리키도록 서비스 업데이트

kubectl apply -f services/hello-green.yaml

  - 서비스가 업데이트되면 "그린" 배포가 즉시 사용됨

 

 (4) 새 버전이 사용 중인지 확인

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

 

3) 블루-그린 롤백

 (1) "파란색" 배포가 계속 실행되는 동안 서비스를 이전 버전으로 다시 업데이트

kubectl apply -f services/hello-blue.yaml

  - 서비스를 업데이트하면 롤백이 성공한 것

 

 (2) 버전 확인

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

---