본 포스팅은 https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests 강의와 https://kodekloud.com/의 내용을 공부하며 기록한 내용입니다.

• 92 Rolling Updates and Rollbacks
• 96 Commands
• 97 Commands and Arguments
• 101 Configuring ConfigMaps in Applications
• 104 Configure Secrets in Applications
• 110 Multi Container Pods
• 114 Init Containers

92 Rolling Updates and Rollbacks

Application은 지속적으로 개발되고, 이에따라 배포전략도 수립해야한다. 운영중인 service라면 Service down time을 없애기 위해서 Recreate 보다는 Rolling Update 전략을 많이 채택한다. 새로운 version의 applycation을 배포하는 것을 rollout이라 하고, 이상이 생겼을 때 되돌리는 작업을 rollback이라 한다.

Kubernetes Deployment에서는 Rolling Update Strategy가 Default 이다.

rollout Command를 활용하면 deployment의 rollout history를 확인할 수 있다.

Replicaset의 경우, 새로운 Replicaset을 만들어서 기존 replcaset (Replica Set - 1)에 있는 pod를 지우면서 곧바로 새로운 replicaset (Replica Set - 2)에 Pod를 띄우는 방식이다.

만약 Rollback 을 하고싶다면 싶다면, kubectl rollout undo <deployment name> 을 통해 돌아갈 수 있다.

96 Commands

일반적으로 Docker File에 CMD 라는 곳에 process의 시작에 필요한 명령어를 기입한다.

docker run 명령어 뒤에 Argument 를 받고 싶다면, 뒤에 command parameter를 append하는 ENTRYPOINT 를 사용한다. 아래 예제처럼 sleep 뒤에 시간이 고정된 것이 아니라 컨테이너 실행 시점에 인자로 변경 가능하다.

argument가 없을 경우 애러가 발생하는데, CMD를 정의하면 Argument 가 없을 경우 대치되어 문제없이 실행하도록 docker file을 만들 수 있다. 또한 entrypoint는 docker run 시에 재정의할 수도 있다.

97 Commands and Arguments

해당 docker file을 Kubernetes에서 pod로 실행하는 방법은 아래와 같다.

혼동해선 안되는 점은 Docker File에서의 Command와 pod definition에서의 command는 다른 것이다.

환경변수를 정의하려면 아래와 같이 key value 를 정의 할 수 있다.

spec:
  containers:
    env:
      - name: APP_COLOR
        value: pink

또는 ConfigMap이나 Secret으로 부터 ENV value를 가져올 수 있다.

101 Configuring ConfigMaps in Applications

ConfigMap이란 말그대로 Configuration에 필요한 데이터를 key,value 쌍으로 저장한 것이다. configmap을 생성하려면 아래와 같이 imperative하게 생성할 수 있다.

kubectl create configmap my-config --from-literal=APP_COLOR=blue \
                                   --from-literal=APP_ENV=prod

또는 아래와 같이 declarative 하게 정의할 수 있다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  APP_COLOR: blue
  APP_ENV: prod

configmap는 kubectl get configmaps나 kubectl describe configmaps 명령어로 확인할 수 있다.

config map을 이용해서 환경변수를 주입(Inject)하기 위해서는 envFrom과 configMapRef를 사용한다.

spec:
  containers:
  - name:
    envFrom:
    - configMapRef:
      name: my-config

104 Configure Secrets in Applications

configMap은 plantext를 그대로 저장하기 떄문에 secret을 저장하기에 부적합하다. 암호화하여 저장하는 것이 중요한데 kubernetes에서는 secret이 그 역할을 한다.

kubectl create secret generic my-secret --from-literal=DB_Host=mysql
kubectl create secret generic my-secret --from-file=<file_path>

declarative 하게 저장하기 위해서는 base64로 incoding하여 저장해야한다.

$ echo -n "mysql" | base64
bXlzcWw=

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
data:
  DB_Host: bXlzcWw= 

데이터를 decoding 하려면 아래명령어로 진행할 수 있다.

$ echo -n 'bXlzcWw=' | base64 --decode
mysql

secret을 통해 환경변수를 주입하려면 spec.continer 아래에 secret 이름을 지정하면 된다.

envFrom:
  - secretRef:
    name: my-secret

secret을 volume으로 저장하면 container안 파일에 secret key,value들이 파일 형태로 남게된다.

Secret은 encrypted 된 것이 아니다. 단지 encoded된 것이다. git hub 같은 곳에 업로드하지 않도록 주의해야한다.

110 Multi Container Pods

기존의 하나의 application에 모두 통합되어있는 구조인 Monolithic한 architecture와 달리 Micro Service 는 각각의 기능을 서비스로 분리한 구조이다.

각각의 pod 안에서도 lifecycle을 함께 유지되어야하는 container들이 있을 것이다.(ex Log agent) 따라서 하나의 pod에 여러개의 container가 실행되는 경우도 있다. 이 경우 Lifecycle 뿐만 아니라 Network, Storage도 함께 공유하기 때문에 효율적이다.

114 Init Containers

init container는 multiple container pod에서 , 컨테이너 중에 반드시 먼저 실행되어야 하는 container를 지정하는데 사용된다.

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:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']