Kubernetes - (5) Application Lifecycle Management

1. Rolling Updates and Rollbacks

1) Rollout

• 첫번째 deployment 생성 시, rollout이 발생되며, 새로운 deloyment revision이 생성된다.
• 어플리케이션 업데이트 후(컨테이너 버전 변경), rollout이 발생되며 새로운 revision이 생성되어 변화를 추적할 수 있고, 필요에 따라 이전 버전으로 roll back 가능

// rollout 상태 체크
kubectl rollout status deployment/deployment명

// rollout history 체크
kubectl rollout history deployment/deployment명

2) Deployment Startegy

(1) Recreate

• 새로운 버전으로 변경 시, 이전 버전을 모두 삭제하고 새로운 버전의 인스턴스를 생성
• 이전 버전 다운되고 새로운 버전 생성되는 과정에서 유저의 접근이 차단될 수 있다.

(2) Rolling Update

• 한번에 모든 이전 버전을 삭제하는 것이 아닌 하나씩 삭제, 새로운 버전 생성 진행
• 디폴트 deployment strategy
• update 시, 새로운 Replica Set이 생성되고 이전 Replica Set의 POD이 하나 다운되면서 새로운 Replica Set에 POD이 생성

// rolling update & roll back 체크
kubectl get replicasets

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-rs
  labels:
    app: myapp
    tier: frontend
spec:
  template: 
    metadata:
    name: nginx
    labels:
      app: myapp
      tier: frontend
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.7.1	// 버전 변경
replicas: 3
selector:
   matchLabels:
     type: frontend

kubectl edit deployment deployment명
or
kubectl apply -f deployment.yaml

// 아래 커맨드 실행 시, defenition file에 자동 적용 안되므로 반영해줘야 한다.
kubectl set image deployment/deployment명 nginx=nginx:1.7.1

(3) Rollback

kubectl rollout updo deployment/deployment명

2. Application Commands

• 컨테이너는 os 호스팅을 하는것이 아니라, 특정한 task or process를 실행하며 해당 임무가 완료되면 종료된다.따라서 docker ps로 현재 정보를 받아올 수 없다.
• 컨테이너 내 어떤 프로세스가 실행되야하는지 정의가 필요하며 이는 CMD를 통해 가능하다.

• ENTRYPOINT를 통해 동작 정의 후 CMD에 기본값 설정할 수 있다.

POD defenition file에 ENTRYPOINT & CMD 적용

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper-3
spec:
  containers:
  - name: ubuntu
    image: ubuntu
    command:
      - "sleep"
      - "1200"          

3. Environment Variables in App

1) Plain Key Value

• POD Defenition File에 key & value로 전달

2) ConfigMaps

(1) Create ConfigMap

Imperative : defintion file 사용 x

kubectl create configmap <config-name> --from-literal=<key>=<value>
ex) kubectl create configmap app-config --from-literal=App_COLOR=blue

kubectl create configmap <config-name> --from-file=<path-to-file>
ex) kubectl create configmap app-config --from-file=app_config.properties

Declarative : defintion file 사용

confg-map.yaml

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

kubectl create -f config-map.yaml

POD Definition File 적용

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper-3
spec:
  containers:
  - name: ubuntu
    image: ubuntu
  - envFrom:
    - configMapRef:
        name: app-config

kubectl get configmaps
kubectl describe configmaps

POD Definition File ENV 변경

// 실행중인 POD에 대한 yaml 파일 생성
kubectl get pod POD명 -o yaml > 파일명.yaml
kubectl delete pod 기존POD명
// 변경 후 실행
kubectl create -f 파일명.yaml

3) Secrets

• configsMap에 환경변수 저장은 Plain text로 기록되므로 중요정보 노출 위험 존재
• secret 생성 시 해당 value는 base64 인코딩

Imperative

kubectl create secret generic <secret-name> --from-literal=<key>=<value>
ex) kubectl create secret generic app-secret --from-literal=DB_Host=mysql
kubetl create secret generic <secret-name> --from-file=<path-to-file>

Declarative

secret-map.yaml

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
  DB_Host: mysql
  DB_User: root
  DB_Password: password

kubectl get secrets
kubectl describe secrets

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper-3
spec:
  containers:
  - name: ubuntu
    image: ubuntu
    envFrom:
    - secretRef:
        name: app-secret

4. Multi Container PODs

• 웹서버 & 로깅 에이전트 그룹핑 필요 시, mutli 컨테이너를 하나의 POD에 설정할 수 있으며 두개의 컨테이너는 라이프사이클을 공유하므로 함께 생성 삭제 된다. 또한, 같은 네트워크, 스토리지 볼륨에 접근 가능

mutlipod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp
spec:
  containers:
  - name: simple-webapp
    image: simple-webapp
  - name: log-agent
    image: log-agent

// 특정 네임스페이스의 POD yaml 파일 생성
kubectl -n 네임스페이스명 get pod POD명 -o yaml > app.yaml