[k8s] Application Lifecycle Management

Deployment starategy

 

Rolling Updates & Rollbacks

deployment는 rollout을 trigger하고, 새 rollout은 새 deployment revision을 생성하게 됨

• 이를 통해 변경을 추적할 수 있고, deployment를 이전 버전으로 롤백할 수 있도록 함

참고: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment

Deployment Strategy

recreate strategy

• 기존 배포된 application을 모두 삭제하고, 새 버전의 application을 다시 생성하는 방식
• 삭제 후 새 버전이 생성되는 사이, application이 접근 불가능한 텀이 생길 수 있음

rolling update

• 모든 app을 동시에 지우지 않음
• 이전 버전을 하나씩 삭제하고, 새로운 버전을 하나씩 띄워 교체하는 방식
  • → 한번에 삭제되는 pod의 수(비율은) RollingUpdate Strategy 로 설정/확인

  spec:
    strategy:
      type: RollingUpdate
      rollingUpdate:
        maxUnavailable: 25% # 업데이트 프로세스 중에 사용할 수 없는 최대 pod수를 지정
        maxSurge: 25% # 의도한 pod수에 대해 생성할 수 있는 최대 pod의 수를 지정
  

• application이 사용 불가한 상태가 되지 않고 seamless하게 업그레이드됨
• 새로운 replica set 을 띄워 pod을 생성하는 동시에 기존 replica set의 pod을 삭제하는 방식
  • kubectl get replicasets

Command

• deployment을 정의했던 manifest file을 수정하고, kubectl apply 를 적용하면 새 rollout 이 트리거되고, 새 revision이 생성됨
  • kubectl apply -f deployment-definition.yaml
• set을 통해서 update할 수 있지만, deployment를 정의한 file은 수정되지 않을 것
  • kubectl set image deployment/myapp-deployment nginx=nginx:1.9.1
• kubectl edit deployments.apps myapp-deployment
• rollout 상태 및 기록 확인
  • kubectl rollout status deployment/myapp-deployment
  • kubectl rollout history deployment/myapp-deployment
• rollback
  • kubectl rollout undo deployment/myapp-deployment
  • kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2

Commands & Arguments

• 시험 커리큘럼에 필수 항목으로 있지는 않지만 중요한 파트라 여겨져 포함

Commands

container를 시작하기 위한 command 정의

• docker run command에 command를 append → image에 정의된 default command를 override함
  • docker run ubuntu sleep 5
  • 영구적으로 override → 새로 command 정의/빌드
  • FROM Ubuntu CMD sleep 5 #["sleep", "5"]
  • sleep 10 으로 실행하려면 docker run ubuntu-sleeper sleep 10 으로 실행해, command line parameter를 전체 대체 시켜야함
• entrypoint
  • FROM Ubuntu ENTRYPOINT ["sleep"]
  • docker run ubuntu-sleeper 10 실행시 command가 sleep 10 으로 append 되어 실행 됨
  • (command line parameter가 append 됨)
  • → 즉, ENTRYPOINT는 시작시 실행되는 command, CMD는 COMMAND로 넘어가는 default parameter
• 실행시 parameter를 받을 수도 있고, default parameter도 지정하고 싶다면
  • FROM Ubuntu ENTRYPOINT ["sleep"] CMD ["5"]
  • docker run ubuntu-sleeper → sleep 5
  • docker run ubuntu-sleeper 10 → sleep 10
• runtime에서 entrypoint를 바꾸고 싶다면
  • ex) entrypoint를 sleep → sleep2.0
  • docker run —entrypoint sleep2.0 ubuntu-sleeper 10→ sleep2.0 10 실행

Commands & Arguments

참고 : https://kubernetes.io/ko/docs/tasks/inject-data-application/define-command-argument-container/

• docker run command에 이어 argument를 추가하고 싶으면, args 필드 사용 → dockerfile의 CMD 를 override함

apiVersion: v1
kind: Pod
metadata
  name: ubuntu-sleepr-pod
spec:
  containers:
  - name: ubuntu-sleeper
    image: ubuntu-sleeper
    args: ["10"]

• entrypoint를 override하고 싶으면 command 필드 사용

spec:
  containers:
  - name: ubuntu-sleeper
    image: ubuntu-sleeper
    command: ["sleep2.0"]
    args: ["10"]

docker ENTRYPOINT = k8s command

docker CMD = k8s args

참고

• 컨테이너를 위한 command 또는 args 를 정의하지 않으면, 도커 이미지의 기본 값들이 사용됨
• 컨테이너를 위한 command 를 정의하고, args 를 정의하지 않으면, command 값만 사용되고, 도커 이미지의 entrypoint와 cmd 는 덮어씌워짐
• 컨테이너 args 만 정의하면, 도커 이미지의 entrypoint 와 컨테이너 args 가 함께 실행
• command 와 args 를 동시에 정의시, 도커 이미지의 entrypoint 와 cmd 는 덮어씌워짐

Configure Env & ConfigMaps in Application

Environment Variables

참고: https://kubernetes.io/ko/docs/tasks/inject-data-application/define-environment-variable-container/

환경 변수 정의 시 env 속성 사용

• name, value 로 구성된 배열

...
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
    - containerPort: 8080
    env:
    - name: APP_COLOR
      value: pink

환경 변수를 정의하는 또 다른 방법으로, ConfigMap, Secrets 사용 ⇒ valueFrom 사용

참고: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-container-environment-variables-using-configmap-data

    env:
    - name: APP_COLOR
      valueFrom:
        configMapKeyRef:

    env:
    - name: APP_COLOR
      valueFrom:
        secretKeyRef:

ConfigMaps

설정 데이터를 key-value 형태로 저장하는 object

• ConfigMap 을 생성하고, pod에 주입하는 방식으로 사용

참고: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-a-configmap

• Imperative 생성
  • kubectl create configmap --from-literal== --from-literal=...
  • kubectl create configmap --from-literal== --from-literal=...
• Declarative 생성

apiVersion: v1
kind: ConfigMap
metadata: app-config
data:
  APP_COLOR: blue
  APP_MODE: prod

• pod에 configmap 주입

...
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
    - containerPort: 8080
    envFrom:
    - configMapRef:
      name: app-config

• single env 주입

...
            env:
            - name: APP_COLOR
              valueFrom:
                configMapRef:
                  name: app-config
                  key: APP_COLOR

• volume을 통해 file로써 전체 데이터 주입

...
            volumes:
            - name: app-config-volume
              configMap:
                name: app-config

Configure Secrets in Application

password 또는 key 등 민감한 정보를 저장하기 위한 object

• configmap과 비슷하지만, encode 또는 hash 된 형태로 저장됨

참고: https://kubernetes.io/docs/concepts/configuration/secret/

• Imperative 생성
  • kubectl create secret generic <secret-name> --from-literal=<key>=<value>
  • kubectl create secret generic --from-file=
• Declarative 생성

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
  DB_Host: bXlzcWw= # manifest파일로 생성할 경우, encode된 형태로 저장해야함
  DB_User: cm9vdA==

• data encode 하는 방법(base64)
  • (-n : 개행문자 무시)
  • echo -n 'mysql' | base64
  • echo -n 'root' | base64
• decode
  • echo -n 'bXlzcWw=' | base64 --decode

kubectl describe secrets 는 value를 숨기므로, 확인하고 싶으면 kubectl get secret app-secret -o yaml 로 yaml 형태로 확인

• Pod에 Secret 주입

envFrom:
- secretRef:
  name: app-secret

• Pod에 하나의 Secret 값 주입

env:
- name: DB_Password
  valueFrom:
    secretKeyRef:
      name: app-secret
      key: DB_Password

• volume을 통해 file로써 전체 데이터 주입

spec:
  containers:
  - name: mypod
    image: app
    volumeMounts:
    - name: app-secret-volume
      mountPath: "/etc/app-secret"
volumes:
- name: app-secret-volume
  secret:
    secretName: app-secret

→ secret을 volume으로 pod에 mount하는 경우, 각 attribute가 파일로 생성되며, 내용이 value임

참고

k8s 속성 사용법 검색

• ex) kubectl explain pods --recursive | grep -A8 envFrom

Multi Container PODs

• 두 서비스가 함께 작동해야할때 (ex. 웹 서버와 로깅 서비스)
• 함께 생성, scale되고, 함께 삭제되는 등 같은 생명 주기를 가짐
• 같은 network space를 가지고, 같은 storage volume에 접근함
  • volume sharing 또는 pod간의 service 등을 따로 정의할 필요 없음
• containers 필드에 여러 container를 정의해서 사용

참고: volume mount를 이용한 container 통신

https://kubernetes.io/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

Init Containers

참고: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

• Pod의 컨테이너가 실행될 때, 선행 과정을 수행하고 싶은 경우
  • 원격 저장소로부터 소스코드나 바이너리 파일을 받아 메인 application에서 사용하고자 할 경우 (→ pod이 생성할때 한번만 실행되는 task)
  • 실제 application이 시작되기 전에 외부 서비스나 database가 뜨기를 기다리고자 할 경우

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'git clone <some-repository-that-will-be-used-by-application> ; done;']

• pod이 생성될 때 initContainer가 실행되며, 실제 container가 실행되기 전 initContainer가 완전히 실행되어야함
• initContainer 또한 여러개 정의할 수 있으며, 순서대로 각 1번 씩 실행됨
• initContainer 중 하나라도 실패하면, 쿠버네티스는 initContainer가 성공할 때까지 pod을 재실행함