3. Managing Deployments Using Kubernetes Engine

 

실습 내용

- kubectl 학습

- 배포 yaml 파일 만들기

- 배포 시작 및 업데이트 확장

- 배포 및 배포 스타일 업데이트 학습

 

---

3가지 배포 전략

1. 순차적 배포

2. Canary 배포

3. Blue/Green 배포

 

 

실습에 사용할 컨테이너 불러오기

# gsutil 도구를 사용하여 이동
gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes .

cd orchestrate-with-kubernetes/kubernetes

# n1-standard-1 노드 5개로 클러스터를 만듭니다.
gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

# 배포 객체 확인하기
# explain 명령어를 통하여 배포할 객체를 확인할 수 있습니다.
kubectl explain deployment

# Optional --recursive 옵션을 통하여 모든 필드를 확인할 수 있습니다.
kubectl explain deployment --recursive

 

recursive 옵션 차이

--recursive 옵션을 안줬을 경우

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec <Object>
     Specification of the desired behavior of the Deployment.

   status       <Object>
     Most recently observed status of the Deployment.

 

-- recursive 옵션을 줬을 경우

FIELDS:
   apiVersion   <string>
   kind <string>
   metadata     <Object>
      annotations       <map[string]string>
      clusterName       <string>
      creationTimestamp <string>
      deletionGracePeriodSeconds        <integer>
      deletionTimestamp <string>
      finalizers        <[]string>
      generateName      <string>
      generation        <integer>
      labels    <map[string]string>
      managedFields     <[]Object>
         apiVersion     <string>
         fieldsType     <string>
         fieldsV1       <map[string]>
         manager        <string>
         operation      <string>
         subresource    <string>
         time   <string>
      name      <string>
      namespace <string>
      ownerReferences   <[]Object>
         apiVersion     <string>
         blockOwnerDeletion     <boolean>
            .
            .
            .

 

배포 파일 업데이트

# 배포할 yaml 파일 수정
vi deployments/auth.yaml

i
:wq

# 수정한 배포 파일 검사
cat deployments/auth.yaml

# 배포 파일 생성
kubectl create -f deployments/auth.yaml

# 배포 파일 가져오기 ( 위에서 정상적으로 생성이 되었는지 확인 )
kubectl get replicasets

# 쿠버네티스는 배포 파일을 생성할 때 replicasets도 함꼐 생성이 됩니다.
# 위에서 배포 파일이 정상적으로 생성되었다면 replicasets 또한 확인할 수 있습니다.
kubectl get replicasets

# 생성된 파일을 확인
kubectl get pods

 

레플리카셋(Replicaset) 이란?

---

레플리카셋은 실행되는 파드 개수에 대한 가용성을 보증하며 지정한 파드 개수만큼 항상 실행될 수 있도록 관리 해줍니다.

즉, 5개의 파드를 항상 실행 하도록 설정하면 이후 파드 1개가 삭제될 경우 다시 파드 1개가 실행되어 5개를 유지할 수 있도록 해줍니다.

 

레플리카셋을 만들기 위한 기본 Template

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

 

apiVersion : 사용할 API 버전
kind : 배포할 오브젝트 종류
metadata : 배포할 오브젝트 정보
metadata.name : 배포할 오브젝트 이름
spec : 배포할 오브젝트 상세 명세
spec.replicas : 항상 떠있길 원하는 Pod의 갯수(Desired)
spec.selector : 레플리카셋이 Pod을 찾기 위한 방법 명세
spec.selector.matchLabels : 해당 라벨을 가진 Pod를 컨트롤 할 것임을 명세
spec.template : 레플리카셋에 의해 배포될 Pod의 템플릿
spec.template.metadata.labels : 레플리카셋에 의해 생성될 팟이 자동으로 가지는 라벨
spec.spec.containers : 배포될 Pod 안에 들어갈 컨테이너 명세

 

# 인증을 배포하기 위한 서비스 파일 생성
kubectl create -f services/auth.yaml

#--------------------------------------------------------------

# 실습 파일 hello
# hello 배포 객체를 생성하고 서비스 또한 생성
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

# 생성한 frontend 에서 외부 IP를 가져와서 연결해 준다.
# 외부 IP 확인
kubectl get services frontend

# 외부 IP 연결
curl -ks https://<EXTERNAL-IP>

# kubectl의 출력 템플릿을 curl을 한줄로 표현
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

 

curl은 command line 또는 script에서 데이터 전송을 위해 사용하는 라이브러리

여러 프로토콜 지원 : HTTP/HTTPS, FTP, SFTPS, SMTP, TELNET 등,

Proxy, Header, Cookie 등 세부 옵션까지 쉽게 설정 가능

 

오픈 소스로 개발되어 윈도우와 리눅스에 기본으로 설치되어 있습니다.

 

 

배포 확장

# hello 파드가 정상적으로 실행되고 있는지 확인
kubectl get pods | grep hello- | wc -l

## 5개 실행중이면 정상

# 3개로 축소
kubectl scale deployment hello --replicas=3

# 재확인
kubectl get pods | grep hello- | wc -l

 

 

 

순차적 배포 (Rolling Update)

---

• 기본적인 배포 방법(deployment의 기본 속성)
• 배포된 전체 파드를 한꺼번에 교체하는 것이 아닌 일정 개수씩 교체하면서 배포하는 방식
• 파드를 하나씩 죽이고 새로운 파드를 띄우는 순차적인 교체 방법
• 업데이트 프로세스 동안 2가지 버전의 컨테이너가 동시에 실행되어서 버전 호환성 문제가 발생 가능

 

 

# hello 파일 수정
kubectl edit deployment hello

 

편집기에서 저장하면, 업데이트된 배포가 클러스터에 저장되고 Kubernetes에서 순차적 업데이트가 시작됩니다.

 

# 순차적 배포 중지
kubectl rollout pause deployment/hello

# 중지 되었는지 확인
kubectl rollout status deployment/hello

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

# 재배포 진행
kubectl rollout resume deployment/hello

# 재배포가 진행되었을 경우 satus를 통하여 확인 가능
kubectl rollout status deployment/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}'

 

 

Canary 배포

---

• 기본 버전을 유지한 채로 일부 버전만 신규 파드로 교체 (한꺼번에 전체 교체 X)
• 구버전과 신버전이 같이 존재
• 버그 확인, 사용자 반응을 확인할 때 유용

 

Canary 배포를 위한 새로운 배포 파일 생성

cat deployments/hello-canary.yaml

kubectl create -f deployments/hello-canary.yaml

 

hello-canary.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
        track: canary
        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

 

 

Blue/Green 배포

---

• 기존에 실행된 파드 개수만큼 신규 파드를 모두 실행
• 신규 파드가 정상적으로 실행되면 한꺼번에 트래픽을 옮기는 방식
• 신버전과 구버전이 같이 존재하는 시간 없이 순차적인 교체 가능
• 순차적 배포보다 필요한 리소스 양이 많음

blue -> green 으로 완전히 이전되면 blue 는 롤백에 대비하여 대기 상태 또는 다음 업데이트 템플릿으로 사용 가능하도록 준비

 

 

blue ( 이전 버전 )

# 기존의 hello:app을 사용
# 서비스 배포 (기존)
kubectl apply -f services/hello-blue.yaml

 

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

# 서비스가 업데이트되면 green 배포가 사용
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

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

 

 

 

---