11. CKA udemy 강의 정리 - Section 5 [Application Lifecycle Management]

0. 디플로이먼트 업데이트 전략 (Recreate, RollingUpdate)

업데이트를 지정하는 spec.strategy.type의 기본값은 RollingUpdate이나, 또 다른 방법으로는 Recreate가 있다. 

먼저 디플로이먼트는 여러 레플리카셋을 관리하여 롤링 업데이트나 롤백 등을 구현하는 리소스이다.

디플로이먼트가 레플리카셋을 생성하고 레플리카셋이 파드를 생성하는 순으로 동작한다.

---

Recreate

recreate는 모든 파드를 한번 삭제하고 다시 생성하기 때문에 다운타임이 발생하지만,
추가 리소스를 사용하지 않고 전환이 빠른 장점이 있다.

deployment.yaml 파일의 spec.strategy.type: Recreate로 지정해주면 된다. 

 

업데이트 구조) 기존의 레플리카셋을 0으로 바꾼 뒤, 리소스를 반환한 후 신규 레플리카 셋을 생성하고 레플리카 수를 늘리게 된다.

# 레플리카셋을 확인해보면 연결된 모든 파드가 존재하지 않는 기간을 확인할 수 있다.
kubectl get replicasets --watch # 몇 초 정도 파드가 존재하지 않아 일시적인 서비스 중단 발생

리소스에 상태변화가 있으면 계속 출력됨

---

RollingUpdate

업데이트 중에 동시에 정지 가능한 최대 파드 수(maxUnavailable)와 업데이트 중에 동시에 생성할 수 있는 최대 파드 수(maxSurge)를 설정할 수 있다. 이 설정을 사용하면 추가 리소스를 사용하지 않도록 하거나 많은 리소스를 소비하지 안혹 빠르게 전환하는 등 업데이트를 하면서 동작을 제어할 수 있다. (maxUnavailable과 maxSurge가 동시에 0은 안된다. 또한 백분율로도 지정 가능 default는 25%)

deployment.yaml 파일의 spec.strategy.rollingUpdate를 설정해주면 되고
spec.strategy.type:을 RollingUpdate로 지정하는건 필수는 아니다.

 

maxUnavailable=0/maxSurge=1 설정의 RollingUpdate. maxSurge 수만큼 추가 레플리카 수를 늘려 파드를 이동시킴

업데이트 적용하기

# 매니페스트를 업데이트하고 k apply명령어를 사용 (권장)
k apply -f deployment-definition.yaml  
# 매니페스트와의 설정값이 다르기 때문에 (권장x)
k set image deployment/myapp-deployment nginx=nginx:1.9.1

---

Recreate & RollingUpdate 차이

kubectl describe deployments #Get details of your Deployment

recreate의 경우 ReplicaSet는 한 번에 하나씩 축소되었지만, rollingupdate는 새로운 ReplicaSet을 한 번에 하나씩 확장하는 것을 확인할 수 있다.

---

Rollback

현재 사용 중인 레플리카셋의 전환가 동일한 의미이다. 롤백한 뒤에는 이전 레플리카셋의 파드가 기동된다.

실제 환경에서는 롤백 기능보다 이전 매니페스트를 다시 apply하는 명령어를 많이 씀. 호환성 면에서 더 좋기 때문에

#변경이력 확인
kubectl rollout history
#해당 수정버전에 대한 상세한 정보 가져오려면 --revision 옵션 지정
kubectl rollout history deployment sample-deployment --revision 1 #한번 업뎃된건 2로
#롤백하기, 바로 이전버전으로 롤백하는 경우 0이 디폴트여서 --to이하 안써도 된다.
kubectl rollout undo deployment sample-deployment --to-revision 1

#작업 중단(pause), 일시정지 해제(resume)
kubectl rollout pause deployment sample-deployment
- 작업 둥단 상태에서는 업데이트가 즉시 반영되지 않으며, 롤백(undo)도 되지 않는다.

---

1. Commands(ENTRYPOINT/command, CMD/args)

도커 파일로 이미지 생성할때는 ENTRYPOINT명령과 CMD명령을 사용하여 컨테이너 실행 시 명령어를 정의한다. 

쿠버네티스에서는 도커용 용어와 조금 다르게 ENTRYPOINT를 command, CMD를 args로 부른다.

컨테이너 실행 할 때 도커 이미지의 ENTRYPOINT,CMD를 덮어쓰기 하려면
파드 내용 중 spec.containers[].command와 spec.containers[].args를 지정하면 된다.

#컨테이너는 실행을 완료하고 종료됨
docker run ubuntu
#종료된 컨테이너 확인
docker ps -a #이미 exit한 컨테이너 확인 가능

VM과 달리 Container는 OS호스팅을 하지 않기 때문에 프로세스(프로세스 가상화 개념)가 끝나는 순간 컨테이너도 종료되어야한다. 

nginx나 mysql 이미지의 명령어를 확인해보면, 이미지 맨 마지막 CMD에서 [nginx]/[mysqld]와 같이 프로그램을 실행하는 명령어가 있다.

ubuntu의 경우 cmd에 bash(사용자에게서 input을 받는 프로세스)가 들어가 있다.

위와 같이 우분투 이미지를 docker run하면 내부적으로는 bash 터미널이 생성되어 명령어를 받을 준비가 된 상태가 된다. 

도커 이미지에 기본적으로 세팅된 명령어를 override하고 싶으면 

docker run 이미지명 [run-command]

만약 매번 프로그램이 실행될 때마다 같은 명령어를 overrride하고 싶다면 새로운 도커 파일을 생성하는 경우가 일반적이다.

만일 이 숫자 값을 하드코딩하지 않고 파라미터로 받아서 매번 변경하고자 한다면, 위에서 말한 docker run ubuntu sleep 5

형태로 직접 입력할수도 있지만 

도커 이미지에 CMD대신 ENTRYPOINT를 사용하면 된다. ENTRYPOINT명령어만 넣고 파라미터는 사용자가 실행할 때 추가 할 수 있기 때문에 

 

kubernetes의 yaml파일 수정 

apiVersion: v1
kind: pod 
#### ----------------------
metadata:
  name: sleep-test
spec:
  containers:
  - name: sleep-test-container
    image: sleep_test
    command:       #commands 아님
      - "sleep"
    args:
      - "50000"    #쌍따옴표 필수
#### --------
가능한 방법 2
command:       
      - "sleep"
      - "50000"
가능한 방법 3
command: [ "sleeps", "50000" ]

---

2. CofingMaps 구성하기 

컨피그맵(configmap)은 컨테이너에서 필요한 환경설정 내용을 컨테이너와 분리해서 제공해 주기 위한 기능이다.

파드 정의 파일이 많으면 쿼리의 파일에 저장된 환경 데이터를 관리하는 것이 어려워진다. 따라서 이 정보를 pods 정의 파일에서 가져와 구성 맵을 사용하여 중앙에서 관리할 수 있게 된다. 

컨피그맵을 컨테이너에서 사용하는 경우

• 환경 변수로 전달
  • 컨피그맵 특정 키만/ 전체 키
• 볼륨으로 마운트
  • 컨피그맵 특정 키만/ 전체 키

---

컨피그맵 생성

• 명령형 선언
  • kubectl로 파일에서 값을 참조하여 생성(--from--file)
    예) $ kubectl create configmap my-config --from-file=/path/to/dir
  • kubectl로 직접 값 전달하여 생성 (--from--literal)
    예) $ kubectl create configmap sample-config --from-literal=sleep-interval=10
• 선언적 방법
  • 매니페스트로 생성(-f)

# sample-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: sample-config
data:
  sleep-interval: '10'

---

3.  Secret

시크릿과 컨피그맵은 비슷한 리소스들이지만, 둘의 가장 큰 차이는 보안을 유지해야 하는 데이터를 전달해야 한다면 컨피그맵이 아닌 시크릿(Secret)을 사용해야한다는 점에 있다.

---

시크릿 생성

$ openssl genrsa -out https.key  2048
$ openssl req -new -x509 -key https.key -out https.cert -days 3650 -subj /CN=www.kubia-example.com
$ kubectl create secret generic fortune-https --from-file=https.key --from-file=https.cert

---

4.  Multi Container PODs

pod란?

• 컨테이너를 표현하는 K8S API의 최소 단위
• Pod에는 하나 또는 여러 개의 컨테이너가 포함될 수 있다. (ex: apache만 있는 pod, nginx만 있는 pod, apache, nginx 두개의 컨테이너가 들어가 있는 pod를 만들 수 있다.)

pod 생성하기 

• 명령형 접근법 : kubectl run [Pod 명] --imange=[이미지:태그]
• 선언형 접근법 : pod yaml , (실행) kubectl create -f .yaml

#pod 확인(3)
kubectl get pods
kubectl get pods -o wide #wide 대신 yaml하면 yaml파일 형식으로 출력
kubectl describe pods

multiple container pod 생성

apiVersion: v1
kind: Pod
metadata:
 name: simple-webapp
 label:
  name: simple-webapp
spec:
 containers:      
 - name: simple-webapp	 #container 1
   image: simple-webapp
   ports:
   - containerPort: 8080 
 - name: log-agent #container 2
   image: log-agent

파드 로그 확인

• kubectl logs multipod -c [컨테이너명]

 

---

참고

• 헷갈리니까 확실히 알고쓰자! docker의 entrypoint, cmd와 k8s
• 쿠버네티스 컨피그맵(Configmap)과 시크릿(Secret)을 알아보자