CKA 공부 12일차

in Devops on Kubernetes

Rolling Updates and Rollbacks

  • 이번 시간에는 Deployement Update와 Rollback에 대하여 알아본다.

  • k8s의 파드 기본 배포 전략은 Rolling Update이다. 순차적으로 파드를 내려가면서 업데이트하는 방식이다.

  • kubectl rollout deployment 명령어를 사용하여 업데이트가 가능하다.

  • kubectl rollout undo 명령어를 사용하면 이전 버전으로 롤백도 가능하다.

  • Rolling Update 말고도 Recreate라는 옵션을 제공하는데, 이름 그대로 업데이트할 때 모든 파드가 동시에 내려갔다가 올라오는 방식이다. ( 쓰일 일이 있을까 싶은 업데이트 전략 )

Command And Argument

  • k8s의 YAML 정의 파일에 도커 컨테이너를 실행할 때 명령어를 주입해줄 수 있다.

  • 가령 Dockerfile에 CMD를 정의해서 외부에서 명령어를 오버라이딩할 수 있게 해뒀다면 아래와 같은 정의파일 작성이 가능하다.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: ubuntu
      image: ubuntu-sleeper
      args: ['10']
  • EntryPoint를 재작성하고 싶다면 아래와 같이 command key로 재정의할 수 있다.
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: ubuntu
      image: ubuntu-sleeper
      command: ['sleep2.0']
      args: ['10']

Configure Environment Variables in Applications

  • k8s에서는 도커 컨테이너에서 사용될 ENV를 k8s 정의 파일에 설정할 수 있다.
env:
  - name: APP_COLOR
    value: pink
  • 이 외에도 k8s에서 관리하는 Configure Map과 Secret에 있는 값도 사용이 가능하다.

ConfigMap 생성과 사용

  • ConfigMap은 Pod와 마찬가지로 선언적으로 사용이 가능하다.
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_COLOR: blue
  APP_MODE: prod
  • k8s 정의 파일에 다음과 같이 ConfigMap의 이름을 주면 해당 변수들이 적용되는 방식이다.
envFrom:
  - configMapRef:
      nmae: app-color

Configure Secrets

  • ConfigMap과 거의 동일하나, 필드를 base64로 인코딩 하여 저장한다.

  • 즉, 중요한 정보를 저장하는 목적으로 사용되지만 base 64로 디코딩이 되니까 엥 이거 완전 쉽게 정보 가져갈 수 있는거 아냐?라고 생각할 수 있다.

  • 맞는 말이다. Secret은 어디까지나 소스코드에 저장될 중요 정보들을 k8s에서 관리하는 용도로써의 보안이지 더 높은 수준의 보안을 제공하지는 않는다. (암호화를 따로 하지는 않으니까)

  • 또한 k8s에서는 이 시크릿을 안전하게 관리하기 위해 해당 노드의 Pod가 Secret의 정보를 필요로 할 경우에만 노드에 전송되며, kubelet은 이 비밀을 tmpfs에 저장하여 시크릿이 디스크 저장소에 저장되지 않도록 해준다.

  • 또한 Pod가 제거되면 kubelet은 비밀 데이터의 로컬 사본도 삭제해준다.

  • 즉 비밀 자체의 암호화 보다는, 쿠버네티스에서 이 시크릿을 좀 더 안전하게 다루기 위한 여러 방책들을 제공해주고 있다고 보는게 맞을 것이다.

  • 더 수준높은 보안을 위해 Helm Secrets이나 HashiCorp Vault와 같은 도구를 사용해볼 수도 있을 것이다.

  • 어쨌든 k8s의 Secret은 그 자체의 안전성 보다는, k8s가 시크릿을 더 안전하게 다루고 있다는 사실을 기억하자.

다중 컨테이너

  • k8s의 파드에는 다중 컨테이너가 배포될 수 있다.

  • 가장 흔한 사이드카 패턴의 예시를 들어보자면, 하나의 컨테이너는 웹 애플리케이션을, 하나의 컨테이너는 로깅 에이전트를 배포할 수 있다.

  • 이렇게 하나의 파드에 여러 컨테이너를 배포하면 컨테이너끼리 상호 협력하여 하나의 동작을 수행하는 파드를 개발할 수 있다. ( 파드 내의 MSA )

  • 또한 다중 컨테이너 파드에서 하나의 컨테이너가 구동에 실패하면 전체 파드가 재시작하게 되는데, 이는 파드라는 최소 단위 내에서 모든 컨테이너가 활성상태여야지만 파드가 정상 동작함을 k8s가 보장해준다.

init Container

  • 파드가 실행될 때 단 한 번만 실행되는 컨테이너가 있을 수 있다.

  • 이 때 initContainers 옵션을 파드에 명시해줄 수 있다.

  • 이 initContainer는 파드가 처음 생성될 때 initContainer에 명시된 컨테이너가 실행되고 나서 컨테이너가 구동된다.

  • 만약 initContainer들 중 하나라도 완료되지 않으면 initContainer가 성공할 때 까지 반복적으로 파드를 재시작 한다.

Application LifeCycle Management 종료




© 2022. by minkuk

Powered by minkuk