[Kubernetes] (18). Application Lifecycle Management

1. 개요

워크로드는 쿠버네티스에서 구동되는 애플리케이션이다. 워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의 Pod 집합 내에서 실행한다. 쿠버네티스에서 Pod 는 클러스터에서 실행 중인 Container 집합을 나타낸다.

 

쿠버네티스 파드에는 LifeCycle이 있다. 예를 들어, pod가 클러스터에서 실행되고 나서 해당 파드가 동작 중인 노드에 

심각한 오류를 발생시키면 해당 노드의 모든 파드가 실패한다.

 

쿠버네티스는 이 수준의 실패를 최종으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관없이 Pod를 새로 생성해야 한다. 그러나, 이 작업이 훨씬 쉽도록 각 Pod를 직접 관리하지 않고 워크로드 리소스를 통해 관리하는데

 

• Deployment 및 ReplicaSet : Deployment는 해당 리소스의 모든 Pod가 필요시 교체 또는 상호 교체 가능할 경우 클러스터의 스테이트리스 어플리케이션 워크로드를 관리하는 용도
• StatefulSet: 어떻게든 state를 추적하는 하나 이상의 파드를 동작하게 해준다. 사용자는 Pod와 PV을 연계하는 용도로 사용할수 있다. 전체적인 회복력 향상을 위해서 , StatefulSet의 Pods에서 동작 중인 코드는 동일한 StatefulSet의 다른 Pods로 데이터를 복제할수 있다.
• DaemonSet은 노드-로컬기능을 제공하는 StaticPods를 정의한다. 예를들어, 네트워크 cni나 add-on등이 있다.
• Job 및 CronJob은 실행 완료 후 중단되는 작업을 정의한다.

2. Rolling Updates & Rollbacks

: deployment는 pod와 replicaSet에 대한 선언적 업데이트를 제공한다.

 

Strategy

- recreate : 새파드가 생성되기전에 죽는다. 이렇게 업그레이드 하면 파드를 모두 종료한다.

- RollingUpdate : 새파드가 생성되기전까지 정해둔 파드의 개수를 유지한다.

• Max Unavailable : 최대 의도한 파드의 수의 70% 이상을 유지하도록 한다.
• Max Surge : 최대 의도한 파드의 수의 130%를 넘지 않도록 한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

 

# StrategyType: RollingUpdate

   해당부분을 kubectl edit를 통해 수정한다.

   - Recreate 로 수정하면, pod를 일시적으로 모두 죽인 후에 deployment 내부에 존재하는 Pods를 재생성한다.

# kubectl edit deployments.app frontend

 

### 검색을 통해 Strategy: 부분 확인

### yaml파일

  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
      
      
      ## 다음과 같이 구성할 경우 pod개수가 4개일경우 
      ## 최소 75% 최대 125% 로 rolling Update를 하는데
      ## 총 개수는 5개의 pod가 유지되며 
      ## 그중 1개는 terminating , 1개는 Creating 상태를 가진다.

 

3. Commands and Arguments

파드를 생성할때, 너는 부팅 후 실행할 명령어와 파라미터를 yaml 파일에 선입력 할수 있다.

커맨드를 정의하기 전에, pod definition file의 예시를 보자.

apiVersion: v1
kind: Pod
metadata:
  name: command-demo
  labels:
    purpose: demonstrate-command
spec:
  containers:
  - name: command-demo-container
    image: debian
    command: ["printenv"]
    args: ["HOSTNAME", "KUBERNETES_PORT"]
  restartPolicy: OnFailure

컨테이너 image 의 이미지 생성할때 도커파일을 작성하듯이 

Dockerfile의 작성방법과 유사하다.

 

 

Pod definition 파일의 command와 argument는 컨테이너 이미지를 생성할때 default로 오버라이딩 되어있는

bash, shell , python 과 같은 명령어를 그대로 사용하기 때문에 dockerfile을 확인할 필요가 있다.

 

FROM python:3.6-alpine

RUN pip install flask

COPY . /opt/
EXPOSE 8080
WORKDIR /opt
ENTRYPOINT ["python", "app.py"]

ENTRYPOINT가 app.py 로 설정되어 있는경우 

pod definition file에서 COMMAND의 default값이 python 문법이 되는것임.

 

 

4. ConfigMaps

컨피그맵이란 ? 

API object 내부에서 사용되는 non-confidential data in key-value pairs

• command / arguments
• Environment data
• configuration files in a volume

 

 

 

# kubectl describe pod [ 파드이름 ] | grep -i3 Environment

 

- Environment:

    APP_COLOR: pink

 

# configMap을 사용하여 pod를 구성하는 방법

1. 컨피그맵을 만든다.

2. 컨피그맵을 pod에 할당한다

 

# kubectl create cm webapp-config-map --from-literal=APP_COLOR=darkblue

## 컨피그맵을 만듭니다.

# kubectl explain pods --recursive | grep envFrom -A3

- envFrom:
  - configMapRef:
            name: webapp-config-map
            
            ### name 위치 중요 ###

 

5. Secrets

 

secrets을 생성하는 방법

# kubectl create secret generic db-secret 
--from-literal=DB_Host=sql01 
--from-literal=DB_User=root 
--from-literal=DB_Password=password123

# echo -n 'mysql' | base64


# kubectl describe secrets

bytes 정보만 표현됨
(인코딩 되어 나타남)

# kubectl get secret db-secret -o yaml

인코딩 되어서 나타남

# kubectl create -f pod-definition.yaml

spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
    - containerPort: 8080
    envFrom:
    - secretRef:
       name: ### ( db-secret)

 

6. Multi Containers 

Multi Containers: 보통 컨테이너는 pod 한개 안에 하나 또는 여럿이 존재한다. 

 

그중 pod의 metric이나 log를 확인하기 위해 agent 역할로 sidecar 형식으로 심어지는 container들이 있는데 

이에 대해 구성하는 방법과 logging service가 어떤 방식으로 배포 되고 기능이 동작되는지 확인하는 예제를 보자

 

1. pod를 생성한다

 

# kubectl run yellow --image=busybox --restart=Never --dry-run -o yaml > pod.yaml

# kubectl run yellow --image=busybox --restart=Never --dry-run -o yaml > pod.yaml

위 파드는 yellow 라는 이름의 pod이고
컨테이너 이미지는 busybox 이며, 컨테이너의 이름은 yellow라고 생성될것이다.

## 해당 pod-definition file에 들어가서 yaml 파일을 수정하는데
## 이때, spec > containers >

- image: busybox
  name: lemon
- image: redis
  name: gold
  
  
  이런 형식으로 2개의 container을 한개 pod 안에 만들수 있다.

 

2.  app 이란 이름의 Pod의 definition-file을 수정하겠다.

 

# kubectl -n elastic-stack get app -o yaml > app.yaml

 

app 컨테이너와 sidecar 컨테이너는 동일한 volume을 쉐어 하며, pod의 lifecycle또한 공유한다.


spec > container > 아래에 이부분을 복사 붙여넣기 한다.

## 
##
##
- image: kodekloud/event-simulator
  name: app
  volumeMounts:
  - mountPath: /log
    name: log-volume
- image: kodekloud/filebeat-configured
  name: sidecar
  volumeMounts:
  - mountPath: /var/log/event-simulator/
    name: log-volume

 

 

3. # kubectl -n elastic-stack logs app

 

혹은 kibana에 접속하여 discover 페이지에서 확인( logging dashboard )

 

 

7. init Containers

멀티 컨테이너 pod 안에 각각의 컨테이너는 POD의 lifecycle을 공유한다.

예를들어, 멀티 컨테이너 파드 안에 웹 + 로깅 에이전트가 있다고 생각해보자, 각각 컨테이너들은 동시에 생성되길 기대받아진다. 그러나, 그들중 하나라도 어떤 Pod가 실패 했을경우, 그 pod는 재시작하게 설계되어 있다.

 

그렇지만, pod중에는 포드가 처음 생성될 때 한 번만 실행하는 프로세스도 있을것이다. 

• git clone으로 코드를 가져오는 경우 

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;']

 

 

• 어떤 프로세스가 진행되길 기다렸다가 진행하는 프로세스 ( nslookup 후에, sleep )

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