IT 공부/쿠버네티스

쿠버네티스 완벽 가이드 5장 - 1

수박한암살자 2022. 4. 20. 23:31

5.1 워크로드 API 카테고리 개요

워크로드 API 카테고리로 분류된 리소스는 클러스터에 컨테이너를 기동시키기 위해 사용되는 리소스다.

5.2 파드

워크로드 리소스의 최소단위는 '파드'라고 불리는 리소스다.
파드는 한 개 이상의 컨테이너로 구성되며, 같은 파드에 포함된 컨테이너끼리는
네트워크적으로 격리되어 있지 않고 IP 주소를 공유한다.

 

5.2.1 파드 디자인 패턴

  • 사이드카 패턴
    • 메인 컨테이너 외에 보조적인 기능을 추가하는 서브 컨테이너를 포함하는 패턴
  • 엠배서더 패턴
    • 메인 컨테이너가 외부 시스템과 접속할 때 대리로 중계해주는 서브 컨테이너를 포함하는 패턴
  • 어댑터 패턴
    • 서로 다른 데이터 형식을 변환해주는 컨테이너를 포함하는 패턴

5.2.2 ~ 5.2.3 생략

5.2.4 컨테이너 로그인과 명령어 실행

  • kubectl exec -it 파드명 -- /bin/bash
  • 해당 파드 내에서 다양한 명령어 실행 가능
    • 예시 
    • 패키지 설치 : apt update && apt -y install iproute2 procps
    • 컨테이너 내부에서 IP 주소 확인 : ip a | grep "inet "
    • 컨테이너 내부에서 프로세스 확인 : ps aux
    • 다수의 컨테이너를 포함한 경우, 특정 컨테이너 지정 : kubectl exec -it 파드명 -c 컨테이너명 -- /bin/ls
    • 옵션을 포함한 실행 : kubectl exec -it 파드명 -- /bin/bash -c "ls --all --classify | grep lib"

5.2.5 ENTRYPOINT 명령/CMD 명령과 command/args

  • Docker에서는 이미지 생성 시 ENTRYPOINT 명령과 CMD 명령을 사용하여 컨테이너 실행 시 명령어를 정의
    • 쿠버네티스에서는 각각 command, args라고 부름
  • kubectl apply -f sample-entrypoint.yaml
  • procps 패키지 설치 후 sleep 명령어 확인

5.2.6 파드명 제한

  • 이용 가능한 문자는 영문 소문자와 숫자
  • 이용 가능한 기호는 '-' 또는 '.'
  • 시작과 끝은 영문 소문자

5.2.7 호스트의 네트워크 구성을 사용한 파드 기동

  • 쿠버네티스에 기동하는 파드에 할당된 IP 주소는 쿠버네티스 노드의 호스트 IP 주소와 범위가 달라 외부에서 볼 수 없는 IP 주소가 할당됨
  • 호스트의 네트워크를 사용하는 설정(spec.hostNetwork)을 활성화하면 호스트상에서 프로세스를 기동하는 것과 같은 네트워크 구성(IP 주소, DNS 설정, host 설정 등)으로 파드를 기동시키는 것이 가능
  • kubectl apply -f sample-hostnetwork.yaml
  • kubectl get pod sample-hostnetwork -o wide
  • kubectl get node 노드명 -o wide
  • kubectl exec -it sample-hostnetwork -- hostname

5.2.8 파드 DNS 설정과 서비스 디스커버리

  • ClusterFirst : 클러스터 내부 DNS에 질의하여 해석되지 않으면 업스트림(upstream)에 질의한다.
    • dnsPolicy의 기본값
  • None : 파드 정의 내에서 정적으로 설정한다.
  • Default : 파드가 기동하는 쿠버네티스 노드의 /etc/resolv.conf를 상속받는다.
    • dnsPolicy의 기본값은 Default가 아니라는 것에 주의
  • ClusterFirstWithHostNet : ClusterFirst의 동작과 같다(hostNetwork 사용 시 설정).
    • hostNetwork를 사용한 파드에 클러스터 내부의 DNS를 참조하고 싶은 경우에 설정
    • hostNetwork를 사용한 경우, 기본값 ClusterFirst의 설정값은 무시되고 쿠버네티스 노드의 네트워크 설정(DNS 설정을 포함)이 사용되기 때문에 명시적으로 ClusterFirstWithHostNet을 지정하도록 하자.

5.2.9 정적 호스트명 해석 설정: /etc/host

  • spec.hostAliases로 파드 내부 모든 컨테이너의 /etc/hosts를 변경 가능
  • kubectl apply -f sample-hostaliases.yaml
  • kubectl exec -it sample-hostaliases -- cat /etc/hosts

5.2.10 작업 디렉터리 설정

  • 컨테이너에서 동작하는 애플리케이션의 작업 디렉터리는 도커 파일의 WORKDIR 명령 설정을 따르는게 기본
  • spec.containers[].workingDir로 덮어 쓸 수 있음

5.3 레플리카셋/레플리케이션 컨트롤러

- 레플리카셋(ReplicaSet)/레플리케이션 컨트롤러(ReplicationController)는 파드의 레플리카를 생성하고 지정한 파드 수를 유지하는 리소스

5.3.1 파드 정지와 자동화된 복구

  • 노드나 파드에 장애가 발생했을 때 지정한 파드 수를 유지하기 위해 다른 노드에서 파드를 기동시켜줌.
  • 장애 시 많은 영향을 받지 않으며 쿠버네티스의 중요 컨셉 중 하나. '자동화된 복구'

5.3.3 레플리카셋과 레이블

  • 레플리카셋은 k8s가 파드를 모니터링하여 파드 수를 조정.
  • 모니터링은 특정 label을 가진 파드 수를 계산하는 형태
  • spec.selector와 spec.template.metadata.labels의 label이 일치하지 않는다면?
    • 에러가 발생하여 생성할 수 없음
    • 에러가 발생하지 않는다면 레플리카 수를 늘리려고 파드가 계속 생성될 것
  • 같은 레이블을 가진 파드를 레플리카셋 밖에서 생성한다면?
    • 초과한 것으로 판단하고 다른 파드를 정지시킴
  • 쿠버네티스의 동작이 익숙해질 때까지 레이블은 유니크하게 붙이자

5.3.4 레플리카셋과 스케일링

  • 매니페스트를 수정하여 kubectl apply -f 명령어를 실행
  • kubectl scale 명령어를 사용하여 스케일 처리

5.3.5 일치성 기준 조건과 집합성 기준 조건

  • 일치성 기준 : 조건부에 일치 불일치(=, !=) 조건 지정
  • 집합성 기준 : 조건부에 일치 불일치(=, !=) 조건 지정과 집합(in, notit, exists) 조건 지정 가능

5.4 디플로이먼트

- 여러 레플리카셋을 관리하여 롤링 업데이트나 롤백 등을 구현하는 리소스

  1. 신규 레플리카셋을 생성
  2. 신규 레플리카셋의 레플리카 수(파드 수)를 단계적으로 늘림
  3. 이전 레플리카셋의 레플리카 수(파드 수)를 단계적으로 줄임
  4. 2~3을 반복
  5. 이전 레플리카셋은 레플리카 수를 0으로 유지
  • 신규 레플리카셋에 컨테이너가 기동되었는지, 헬스 체크는 통과했는지를 확인하며 전환 작업이 진행됨
  • 레플리카셋의 이행 과정에서 파드 수에 대한 상세한 지정도 가능
  • 하나의 파드를 기동하는 경우에도 디플로이먼트 사용을 권장
  • 파드로만 배포한 경우, 파드에 장애가 발생하면 자동으로 파드가 재생성되지 않음
  • 레플리카셋으로만 배포한 경우, 롤링 업데이트 등의 기능을 사용할 수 없음

5.4.2 디플로이먼트 업데이트(레플리카셋이 생성되는) 조건

  • spec.template의 내용 변경 -> 생성된 파드의 설정이 변경 -> 레플리카셋을 신규로 생성하고 롤링 업데이트

5.4.3 변경 롤백

  • 디플로이먼트가 생성한 기존 레플리카셋은 레플리카 수가 0인 상태로 남아 있기 때문에 레플리카 수를 변경시켜 다시 사용이 가능
  • 변경 이력 확인 : kubectl rollout history
  • 롤백 방법
    • 버전 번호 지정 : kubectl rollout undo deployment 디플로이먼트명 --to-revision 1
    • 바로 이전 버전 : kubectl rollout undo deployment 디플로이먼트명

5.4.4 디플로이먼트 변경 일시 정지

  • kubectl rollout pause -> 일시 정지
  • kubectl rollout resume -> 일시 정지 해제

5.4.5 디플로이먼트 업데이트 전략

  • spec.strategy.type 의 기본 값은 RollingUpdate
  • Recreate : 모든 파드를 한 번 삭제하고 다시 파드를 생성하기 때문에 다운 타임이 존재. 추가 리소스는 사용하지 않고 전환이 빠름
  • RollingUpdate : 업데이트 중 동시에 정지 가능한 최대 파드 수(maxUnvailable)와 업데이트 중 동시에 생성할 수 있는 최대 파드수(maxSurge) 설정 가능
  • 두 설정을 통해 추가 리소스를 사용하지 않도록 하거나 많은 리소스를 소비하지 않고 빠르게 전환하는 등의 동작 제어 가능
  • 두 값 모두 0으로 설정은 불가능

5.4.5 상세 업데이트 파라미터

  • minReadySeconds(최소 대기 시간(초))
    • 파드가 Ready 상태가 된 다음부터 디플로이먼트 리소스에서 파드 기동이 완료되었다고 판단(다음 파드의 교체가 가능하다고 판단)하기까지의 최소 시간(초)
  • revisionHistoryLimit(수정 버전 기록 제한)
    • 디플로이먼트가 유지할 레플리카셋 수
    • 롤백이 가능한 이력 수
  • progressDeadlineSeconds(진행 기한 시간(초))
    • Recreate/RollingUpdate 처리 타임아웃 시간
    • 타임아웃 시간이 경과하면 자동으로 롤백

5.4.7 디플로이먼트 스케일링

  • 디플로이먼트가 관리하는 레플리카셋의 레플리카 수는 레플리카셋과 같은 방법으로 kubectl apply -f 또는 kubectl scale을 사용하여 스케일 가능

5.4.8 매니페스트를 사용하지 않고 디플로이먼트 생성

  • kubectl create deployment sample-deployment-by-cli --image nginx:1.16
  • kubectl delete -n 네임스페이스명 deployment sampe-deployment-by-cli
반응형
저작자표시