[CKA] Application Lifecycle Management

Rolling Updates & Rollbacks

• deployment를 생성할 때, 이게 rollout을 trigger한다.
• 새로운 rollout은 새로운 버전의 deployment를 생성한다.
• 이것은 deployment가 변경사항을 추적하고자 할 때와 이전 버전으로 rollback 하고자 할 때 도움을 준다.

rollout command

• rollout status check

kubectl rollout status deployment/myapp-deploy

• rollout history check

kubectl rollout history deployment/myapp-deployment

Deployment Strategy

• recreate strategy
  • 기존 배포된 application을 모두 삭제하고, 새 버전의 application을 다시 생성
  • 삭제 후 새 버전을 만드는 사이에 application에 접근이 불가한 시간이 발생할 수 있다.
  • not default deployment strategy
• rolling update
  • 하나씩 이전 버전을 down → 새로운 버전을 up 하는 방식
  • 어플리케이션이 down되지 않고 원활하게 새 버전을 배포할 수 있다
  • default deployment strategy

how

• yaml, docker, code 등 어떠한 변화가 생겼을 때

kubectl apply -f deployment-definition.yaml

• rolling update 방식으로 새 버전이 배포된다.

kubectl set image deployment/myapp-deployment nginx=nginx:1.9.1

• set 명령어를 통해 yaml을 수정하지 않고 image version에 수정사항이 발생하게 할 수 있지만 이럴 경우 yaml file 내의 image는 이 버전을 가르키게 되지 않고 배포된 버전과 yaml file의 내용은 차이가 발생하게 된다.

차이점

두 배포 전략의 차이점은 detail 화면에서도 확인할 수 있다.

Rollback

kubectl rollout undo <이전 버전으로 돌리고 싶은 리소스>

Command & Argument

dockerfile의 ENTRYPOINT 는 Kubernetes의 command 필드와 대응되며,

CMD 는 kubernetes의 args 필드와 대응된다.

# Dockerfile
ENTRYPOINT ["sleep"]
CMD ["5"]

# kubernetes yaml file
containers:
  - name:
    image:
    command: ["sleep"]
    args: ["5"]
# 혹은 이런 방식도 사용된다
containers:
  - name:
    image:
    command:
      - "sleep"
      - "5"

ConfigMap

환경변수를 pod의 매니페스트 파일에 정의할 수 있지만 환경변수를 각 pod별로 관리하는 것 보다 ConfigMap을 통하여 하나의 파일에서 모든 환경변수를 관리하는 것이 효율적으로 관리할 수 있는 방법이다.

configmap 생성하기

기본적으로 pod를 생성할 때 환경변수는 다음과 같이 설정한다.

# kind: Pod
spec:
  containers:
  - name:
    image:
    env:
    - name: APP_COLOR
      value: blue

이를 Configmap 리소스를 사용하면 다음과 같이 사용할 수 있다.

• 먼저 ConfigMap 리소스를 생성한다.

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

• 그 후 생성한 configmap의 환경 변수를 사용하고자 하는 pod에 다음과 같이 작성하여 환경변수를 매칭시킨다.

# kind: pod
spec:
  containers:
  - name:
    image:
    envFrom: 
    - configMapRef:
        name: app-config  # ConfigMap resource name

• 참고) 이를 명령형 방식으로 사용하면 다음과 같다.
  • 중복하여 사용할 수 있지만 많은 인자 중복은 복잡함을 초래한다.

kubectl create configmap <configmap-name> --from-literal=<key>=<value>

e.g) kubectl create configmap app-config --from-literal=APP_COLOR=blue --from-literal=APP_MOD=prod

생성한 configmap 조회

kubectl get configmaps
kubectl describe configmaps

Configure Secrets in Applications

config map은 문자열 그대로 저장하기 때문에 민감한 정보(패스워드, 키)등은 이대로 저장되면 노출의 위험이 있어 안된다.

이런 경우에 secret을 사용하면 해당 정보가 인코딩 또는 해쉬 상태로 저장되기 때문에 보다 보안을 강화시킬 수 있다.

Secret 생성

Configmap 생성 과정과 같다. 먼저 Secret을 생성하고, pod에 매칭시켜주면 된다.

secret 생성에도 명령형과 선언적 방식이 있다.

• 명령형 방식

kubectl create secret generic <secret-name> --from-literal=<key>=<value>
e.g) kubectl create secret generic app-secret --from-literal=DB_HOST=mysql

• 선언형 방식

# secret-data.yaml

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
 DB_HOST: mysql
 DB_User: root
---
# kubectl create(apply) -f secret-data.yaml

• 위의 방식은 그대로 plain text 형식이기 때문에 이를 hashed file 형태로 저장하는것이 옳다.

# secret-data.yaml

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
 DB_HOST: bXlzcWw=
 DB_User: cm9vdA==
---
# kubectl create(apply) -f secret-data.yaml

• 그럼 명령형 방식에서는 인코딩 된 문자열을 어떻게 얻을 수 있을까?

echo -n 'mysql' | base64

Secret Injection to Pod

resource name matching으로 injection

# pod yaml
spec:
  containers:
  - name:
    image:
    envFrom:
      - secretRef:
          name: app-secret # 매칭하고자 하는 secret resource name

injection with volume

volumes:
- name: app-secret-volume
  secret:
    secretName: app-secret

• 볼륨 사용했을 때 사용된 볼륨의 secret 확인하기

ls /opt/app-secret-volumes

cat /opt/app-secret-volumes/DB_Password

Secret 조회

kubectl get secrets
kubectl describe secrets

• describe를 해도 실제로 어떤 값이 저장되어 있는지는 볼 수 없다. 그럼 어떻게 봐야할까? -o 옵션을 사용하여 yaml file로 추출한 뒤 파일을 확인하면 된다.

Secret Decode

인코딩된 값은 디코딩하여 원래의 값을 확인할 수 있다.

echo -n 'bXlzcWw=' | base63 --decode

Init Containers

• pod 컨테이너가 실행될 때, main process 컨테이너 실행 전에 선행 작업이 필요한 경우
  • e.g) 원격 저장소로부터 소스코드나 바이너라 파일을 받아 메인 어플리케이션에 사용하고자 할 경우
  • pod이 실행될 때 한번만 실행되는 container
• 위와 같은 경우에 init container를 사용하면 pod가 실행될 때 init container가 먼저 실행된다.
• application container가 실행되기 전에 init container 실행이 완료되어야 한다.
• init container는 여러개 정의할 수 있고, 이 여러개의 init container는 순차적으로 실행된다.
• init container가 실패하면 kubernetes는 init container가 성공할 때 까지 pod를 재실행한다.