Udemy CKA course 5. Application Lifecycle Management (응용 프로그램 생애주기 관리): Rolling Updates and Rollbacks, Application Configuration (commands, arguments, ConfigMaps, Secrets), Multi-Container Pods

Certified Kubernetes Administrator (CKA) with Practice Tests (강의 링크, 레퍼런스 노트)

• 평소 강의 할인도 많이 하고, 연습문제도 풀어볼 수 있으니 실제 강의 수강을 추천
• 아래는 강의 내용 번역 및 정리본 (문제 시 댓글로 알려주세요)

Rolling Updates and Rollbacks

Rollout (롤아웃)

• 새로운 배포는 새로운 롤아웃을 만들어내고, 새로운 배포 수정(deployment revision)을 만듦
• Deployment에 발생하는 변화를 추적하고, 필요 시 이전 버전으로 원복 가능
• kubectl rollout status deployment/[deployment명]
• kubectl rollout history deployment/[deployment명]

Deployment 전략

• Recreate 전략
  • 실행 중인 인스턴스들 삭제, 새로운 인스턴스들 배포
  • 이전 버전이 다 삭제되고 새로운 버전이 생성되기 이전에 응용 프로그램이 다운됨 (서비스 불가)
• Rolling Update 전략
  • 인스턴스들을 하나씩 삭제하고 생성
  • 응용 프로그램이 다운되는 현상 없음 (seamless)
• kubectl apply -f [deployment파일명].yaml
  • yaml 파일을 수정하고 apply 명령어 실행
• kubectl set image deployment/[deployment명] [container명]=[image명]
  • 이미지를 변경할 때 사용 가능한 명령어
  • yaml 파일은 자동으로 수정되지 않음에 주의

Upgrade & Rollback (롤백)

• 업그레이드 시, Deployment 하위에 Replica Set을 새로 생성하고 pod를 하나씩 생성
  • 새로운 Replica Set에 pod를 하나씩 생성할 때, 기존 Replica Set의 pod를 하나씩 다운
• 이전 버전으로 원복(롤백)하고 싶을 때, 이전 Replica Set에 있던 pod를 깨움
  • 새로운 Replica Set에 있는 pod는 하나씩 다운
  • kubectl(k) rollout undo deployment/[deployment명]

• 응용 프로그램 환경설정(Configuration)을 위해서는 아래 세 개를 확인해야 함
  • 명령어(Command)와 인수(argument)
  • 환경변수(Environment Variables)
  • Secrets

Commands and Arguments Configuration

도커와 컨테이너

• 컨테이너는 가상머신과는 다르게 OS(운영체제)를 호스팅하지 않음
  • 특정 태스크 혹은 프로세스를 실행
  • e.g. 웹서버, 응용 프로그램 서버, 데이터베이스 인스턴스를 호스팅
• 태스크가 끝나면 컨테이너는 종료(exit)
  • docker run ubuntu : 우분투 이미지 파일 실행 시 바로 종료
• 도커 파일에서 CMD ["명령어"] 형태로 기본 명령어를 정의
  • e.g. CMD ["bash"] : 터미널로부터 들어오는 인풋을 듣는 쉘(shell), 터미널이 없으면 종료
• 컨테이너 시작 시 다른 명령어를 사용하려면
  • 1. docker run 명령어 뒤에 사용할 명령어 붙임
    • 이미지 내에 있는 기본 명령어를 오버라이드(override)
    • e.g. docker run ubuntu sleep 5
  • 2. 이미지 내에 기본 명령어로 지정 (영구적 사용 시)
    • CMD command param1 (e.g. CMD sleep 5)
    • CMD ["command", "param1"] (e.g. CMD ["sleep", "5"])
    • docker build -t [도커명] 형태로 새로운 도커 이미지 만들 수 있음
    • ENTRYPOINT ["sleep"]
      • docker run [도커명] 10 : sleep 10 명령어가 실행됨
      • CMD를 ENTRYPOINT와 함께 사용하면 기본값도 지정 가능 (e.g. CMD ["5"])
      • docker run --entrypoint [새로운 명령어] [도커명] : entrypoint 명령어 오버라이드 가능

도커와 POD

• ubuntu-sleeper라는 도커 이미지가 있다고 가정
  • e.g. docker run --name ubuntu-sleeper ubuntu-sleeper 10
  • e.g. docker run --name ubuntu-sleeper --entrypoint sleep2.0 ubuntu-sleeper 10
• pod yaml file
  • spec:
    • containers:
      • -name: ubuntu-sleeper
      • image: ubuntu-sleeper
      • command: ["sleep2.0"]
        • 도커 파일의 ENTRYPOINT에 해당
      • args: ["10"]
        • 추가적인 argument. 도커 파일의 CMD에 해당
• kubectl run [pod명] --image=[이미지명] -- [arg1] [arg2] ...
• kubectl run [pod명] --image=[이미지명] --command -- [cmd] [arg1] [arg2] ...
  • e.g. kubectl run [pod명] --image=[이미지명] --command -- color green

YAML 파일 작성법

• 리스트 형태로 표시
  • e.g. command: ["sleep", "5000"]
  • e.g. command: ["sleep 5000"]
• 대시로 나열하기
  • command:
    • -"sleep"
    • -"5000" (string 형태로 작성해야 함)
• 명령어와 인자를 분리해서 작성하기
  • command: ["sleep"]
  • args: ["5000"]

Environment Variables Configuration

• docker run -e [환경변수명]=[변수값] [도커명]
• pod yaml 파일
  • spec:
    • containers:
      • env:
        • -name: [환경변수명]
        • value: [변수값]

ENV 값 타입

• 일반적인 키-값
  • env:
    • -name: [환경변수명]
    • value: [변수값]
• ConfigMap
  • env:
    • -name: [환경변수명]
    • valueFrom:
      • configMapKeyRef:
• Secrets
  • env:
    • -name: [환경변수명]
    • valueFrom:
      • secretKeyRef:

ConfigMaps

• pod yaml 파일에 여러 개의 env를 관리하기 번거로울 수 있음
• ConfigMap으로 별도 관리 가능

1. ConfigMap 생성

• imperative 방식
  • 정의 파일 없이 생성
  • kubectl create configmap [config명] --from-literal=[key]=[value]
  • kubectl create configmap [config명] --from-file=[파일경로]
• declarative 방식
  • 정의 파일 이용해서 생성
  • yaml 파일 형식
    • apiVersion: v1
    • kind: ConfigMap
    • metadata:
      • name: [config명]
    • data:
      • [key]: [value]
  • kubectl create -f [파일명].yaml
• 관련 명령어
  • kubectl get configmaps(cm)
  • kubectl describe configmaps

2. Pod에 ConfigMap 연결

• pod yaml 파일에 아래와 같이 작성 가능
  • spec: containers 하위에 작성
• 1. ENV
  • envFrom: list 형태를 담을 수 있음
    • -configMapRef:
      • name: [config명]
• 2. SINGLE ENV
  • env:
    • -name: [key]
    • valueFrom:
      • configMapKeyRef:
        • name: [config명]
        • key: [key]
• 3. VOLUME
  • volumes:
    • -name:
    • configMap:
      • name:

Secrets Configuration

• ConfigMap과 유사
• 인코딩된 형태로 존재한다는 점이 차이점
  • 민감한 정보 등을 저장
  • 하지만 암호화(encrypt)된 게 아니라 단순히 인코딩되었다는 사실을 유의
  • ETCD에도 암호화되지 않은 상태로 저장되나, rest에서 암호화 가능함
    • AWS Provider, Azure Provider, GCP Provider, Vault Provider 등 secret을 암호화하여 저장하는 대안을 활용하는 방법도 존재
  • 동일 네임스페이스에서 pod/deployment를 생성할 수 있는 사람은 누구나 secret에 접근 가능

1. Secret 생성

• imperative 방식
  • kubectl create secret generic [secret명] --from-literal=[key]=[value]
  • kubectl create secret generic [secret명] --from-file=[파일경로]
• declarative 방식
  • yaml 파일 형식
    • apiVersion: v1
    • kind: Secret
    • metadata:
      • name: [secret명]
    • data:
      • [key]: [value]
  • kubectl create -f [파일명].yaml
  • 파일 내의 value를 인코딩된 형태로 저장해야 함
    • echo -n '[인코딩할 값]' | base64 : 리눅스 호스트에서 인코딩된 값 얻는 방법
      • -n 옵션은 값의 개행을 제거 (포함 여부에 따라 인코딩 결과 달라짐)
    • echo -n '[디코딩할 값]' | base64 --decode : 디코딩된 값 얻는 방법
• 관련 명령어
  • kubectl get secrets
  • kubectl describe secrets

2. Pod에 Secret 연결

• pod yaml 파일
  • spec: containers: 하위에 다음과 같이 작성
• 1. ENV
  • envFrom: list 형태를 담을 수 있음
    • -secretRef:
      • name: [secret명]
• 2. SINGLE ENV
  • env:
    • -name: [key]
    • valueFrom:
      • secretKeyRef:
        • name: [secret명]
        • key: [key]
• 3. VOLUME
  • volumes:
    • -name:
    • secret:
      • secretName:
  • secret 내의 attribute가 각각 파일의 형태로 저장됨 (내용=value)

Rest에서 Secret 암호화

• apt-get install etcd-client
  • etcdctl 명령어 사용하기 위해 필요
• ETCDCTL_API=3 etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server/crt --key=/etc/kubernetes/pki/etcd/server.key get /registry/secrets/default/[secret명] | hexdump -C
  • authetication을 위한 명령어
  • hexdump -C는 정리된 형태로 결과를 보기 위한 옵션
• ps -aux | grep kube-api
  • kube-apiserver 프로세스가 돌고 있는지 확인하는 명령어
• ps -aux | grep kube-api | grep "encryption-provider-config"
  • encryption-provider-config 해당 옵션이 설정되어 있는지 확인
  • 활성화 되어있어야 암호화 가능
• ls /etc/kubernetes/manifests/
  • kube-apiserver.yaml의 configuraiton 확인 가능
• head -c 32 /dev/urandom | base64
  • 32바이트의 랜덤한 키를 만들고 base64 인코딩을 진행 (리눅스, 맥 명령어)
• vim enc.yaml
  • EncryptionConfiguration yaml 파일
  • pod yaml에 작성할 hostPath: path 위치에 작성
• pod yaml 파일 수정 (/etc/kubernetes/manifests/kube-apiserver.yaml)
  • spec:
    • containers:
      • -command:
        • --encryption-provider-config=[mount될 경로]
      • volumeMounts: 로컬 파일이기 때문에 volume mount 필요
        • -name: [이름]
        • mountPath: [mount될 경로]
        • readonly: true
    • volumes:
      • -name: [이름]
      • hostPath:
        • path: [EncryptionConfiguration yaml 경로]
        • type: DirectoryOrCreate
• kubectl create secret generic [secret명] --from-literal=[key]=[value]
• kubectl get secret --all-namespaces -o json | kubectl replace -f -
  • 모든 secret이 암호화되도록 보장

yaml 파일

• apiVersion: apiserver.config.k7s.io/v1
• kind: EncryptionConfiguration
• resources:
  • -resources: 암호화하고 싶은 자원을 선택
    • secrets
  • providers: list 형태로 제공, 항상 가장 상단의 알고리즘 사용
    • -aesgcm: 암호화 알고리즘 (aescbc, secretbox 등 다양하게 존재)
      • keys:
        • -name: [키]
        • secret: [인코딩된 값]
    • -identity: {} 일반적인 텍스트로 저장 (암호화 X), 해당 값이 없을 경우 일반 텍스트를 읽을 수 없으므로 필요

참고하면 좋을 다른 게시글

• https://cwal.tistory.com/47

Multi-Container Pods

• 함께 사용하는 2개의 서비스가 있다고 가정
  • 기능은 함께 사용되어야 하지만 별도로 배포되어야 함
  • e.g. 웹서버와 로그 에이전트
  • multi-container pod를 활용하면 됨
• 3개의 디자인 패턴이 있음
  • sidecar, adapter, ambassador (CKAD 시험 범주)
• pod yaml 파일
  • spec:
    • containers: list 형태로 multi-container 작성 가능
      • -name: ...
      • image: ...
      • ports:
        • -containerPort: ../
      • -name: ...
      • image:

명령어

• kubectl -n [네임스페이스] exec -it [pod명] -- cat /log/app.log
  • pod를 iterative하게 실행 후 명령어 (log 파일 확인) 실행
• kubectl logs [pod명] -n [네임스페이스]
  • pod의 log를 바로 확인할 수 있음