[CKA] CKA 자격증 준비 자료 정리 4 (Application Lifecycle Management)

본 포스팅은 CKA 자격증 준비를 위해 해당 강의를 보고 정리한 자료입니다.

일부 생략되었으니 꼭 강의를 수강하시고 내용 정리 용도로만 참고하시길 바랍니다. 

---

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을 삭제하는 방식

Command

deployment을 정의했던 manifest file을 수정하고, kubectl apply 를 적용하면 새 rollout 이 트리거되고, 새 revision이 생성됨

$ kubectl apply -f deployment-definition.yaml

set/edit 을 통해서 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

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

Docker Commands (참고)

container를 시작하기 위한 command 정의

 

CMD

docker run 실행 시 command 지정 -> docker image에 정의된 CMD를 override한다.

영구적으로 override 하려면, 새로 CMD를 정의/빌드 해야한다.

FROM Ubuntu
CMD sleep 5 #["sleep", "5"]

• 만약 command로 "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 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 생성

configmap 생성

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 속성 사용법 검색

$ kubectl explain pods --recursive | grep -A8 envFrom

---

Multi Container PODs

두 서비스가 함께 작동해야할때, 하나의 pod에 여러 container를 포함시킨다.(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을 재실행함

---

[DevOps/Kubernetes] - [CKA] CKA 자격증 준비 자료 정리 5 (Cluster Maintenance)

[CKA] CKA 자격증 준비 자료 정리 5 (Cluster Maintenance)