Udemy CKA course 2. Core Concepts (핵심 개념 요약): ETCD, API Server, Controller Manager, Scheduler, Kubelet, Proxy

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

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

Cluster Architecture

• 쿠버네티스의 목적
  • 응용 프로그램(application)을 컨테이너의 형식으로 호스팅 (자동화된 방식)
  • 필요한 만큼 쉽게 배포, 여러 서비스 간 통신 지원
• 아키텍처
  • worker node: 컨테이너의 형식의 응용 프로그램을 호스트
    • kubelet: 각 노드에 존재, kube-apiserver와 통신
    • kube-proxy: 클러스터 내 서비스 간 통신
  • master node: 노드의 관리, 계획, 스케줄링, 감시 담당
    • ETCD cluster: 키-값 형식으로 정보를 저장하는 데이터베이스
    • kube-scheduler: 컨테이너를 적재할 노드를 식별, 스케줄링
    • controller-manager
      • node-controller: 노드 관리
      • replication-controller: replication group 내 컨테이너 (개수) 관리
    • kube-apiserver: 클러스터 내 모든 작동(operation)을 조정(orchestration)
  • 컨테이너 런타임 엔진: 클러스터 내 모든 노드에 다운로드 필요 (e.g. docker, containerD, rocket)

Docker vs. ContainerD

• 초반에는 docker가 가장 지배적인 container runtime engine이었고 쿠버네티스도 docker를 지원하는 방향으로 만들어짐
• 추후 다른 런타임 엔진들이 쿠버네티스 생태계에 포함되고 싶어함
  • Open Container Initivative (OCI) 표준을 만족한다면, 쿠버네티스의 Container Runtime Interface (CRI)를 통해 통합 가능
• docker는 CRI 표준을 만족하지 못하기 때문에 쿠버네티스는 dockershim을 통해 도커를 지속적으로 지원
  • v1.24에서는 dockershim 없어짐
• docker는 CLI, API, BUILD, VOLUMES, AUTH, SECURITY, ContainerD (컨테이너 런타임을 관리하는 daemon) 등으로 구성
• ContinaerD는 CRI 표준을 지원하기 때문에 도커와 별개로 쿠버네티스에서 사용할 수 있음
  • ctr (CLI): 사용자 친화적이지 않음, 디버깅 목적의 제한적 지원 (containerD)
  • nerdctl (CLI): 도커와 유사, 신규 기능까지 지원 (contaierD)
  • crictl (CLI): CRI를 사용하는 컨테이너 런타임을 위한 CLI 제공, 디버깅 목적으로 주로 사용 (생성 목적 X) (rocket, containerD)

ETCD

• distributed, reliable key-value store

key-value store

• 문서 혹은 페이지의 형태로 정보를 저장
• 각 개인마다 하나의 파일(문서, 페이지)을 가짐
  • 한 문서의 수정이 다른 문서에 영향을 미치지 않음
• JSON, YAML 파일 형태 주로 사용

ETCD 다운로드

• 바이너리 파일 다운로드
  curl -L .. tar.gz
• 파일 추출
  tar xzvf ... tar.gz
• ETCD 서비스 실행
  • ./etcd
  • 기본적으로는 2379 포트 사용
  • ETCD 컨트롤 클라이언트
    • 명령행 (command line) 클라이언트
    • key-value 저장
      ./etcdctl set key1 value1 (v.2)
./etcdctl put key1 value1 (v.3)
    • 키로 값 가져오기
      ./etcdctl get key1
    • 백업
      etcdctl backup (v.2)
etcdctl snapshot save (v.3)
    • 상태 체크
      etcdctl cluster-health (v.2)
etcdctl endpoint health (v.3)

ETCD 버전

• v0.1: 2013.8
• v0.5: 2014.12
• v2.0: 2015.2
• v3.1: 2017.1
  • Version 2와 Version 3 사이에 많은 변화가 존재
• CNCF Incubation: 2018.11
• 버전 확인
  ./etcdctl --version
• 각 명령어 실행 전 환경변수 설정
  ETCDCTL_API=3 ./etcdctl version
• 세션 전체에 대해 환경변수 설정
  export ETCDCTL_API=3 ./etcdctl version

ETCD in Kubernetes

• kubectl get 명령어 실행 시 보는 모든 정보는 ETCD 서버로부터 가져옴
• 모든 변경 정보 또한 ETCD 서버에 업데이트됨
  • ETCD에 업데이트가 완료되어야 변화가 완료되었다고 여겨짐
• 쿠버네티스 배포(deployment) 타입에 따라 ETCD 배포 방식이 달라짐
  • from scratch
    wget -q --https-only "[file_name]"
    • --advertise-client-urls의 경우 ETCD의 주소 (default port: 2379)
    • kubeapi 서버가 etcd 서버에 닿기 위해서는 해당 URL이 설정되어 있어야 함
  • kubeadm tool
    • etcd 서버가 pod의 형태로 배포되어짐
      kubectl get pods -n kube-system
    • 모든 키들의 리스트를 보고 싶을 때
      kubectl exec etcd-master -n kube-system etcdctl get / --prefix -keys-only
• ETCD in high availability environment
  • 클러스터 내에 여러 개의 마스터 노드가 있는 경우
  • 여러 개의 ETCD 인스턴스가 마스터 노드들에 존재함
    • --initial-cluster에 인스턴스 명기해야 함

kubectl exec etcd-master -n kube-system -- sh -c 
"ETCDCTL_API=3 etcdctl get / --prefix --keys-only --limit=10 
--cacert /etc/kubernetes/pki/etcd/ca.crt 
--cert /etc/kubernetes/pki/etcd/server.crt  
--key /etc/kubernetes/pki/etcd/server.key" 

Kube-apiserver

• 쿠버네티스의 주요 관리 요소
• kubectl 명령어 사용 시 kube-apiserver에 도달
  • 사용자 확인 (authenticate)
  • 요청 확인 (validate)
  • 요청 수행
    • e.g. ETCD에서 정보 가져오기
    • e.g. ETCD 업데이트
    • e.g. 스케줄러에서 api-server 모니터링, 새로운 pod 생성 확인 (노드 배포 요청)
    • e.g. kubelet을 통해 node에 pod 배포
• 클러스터 내 변화가 있을 때 다양한 태스크를 수행하는 중심에 위치
  • ETCD와 직접적으로 소통하는 유일한 구성요소
  • 다른 구성요소들은 kube-apiserver를 통해 소통

kube-apiserver.service 내 옵션들

• SSL/TSL 관련 인증서 (certificates)
• etcd 서버 위치

명령어

• kubeadm으로 설치 시 api-server 확인
  kubectl get pods -n kube-system
• kubeadm으로 설치 시 api-server 옵션 확인
  cat /etc/kubernetes/manifests/kube-apiserver.yaml
• kubeadm으로 미설치 시 api-server 옵션 확인
  cat /etc/systemd/system/kube-apiserver.service
• 실행 중인 프로세스에서 옵션 확인
  ps -aux | grep kube-apiserver

Kube Controller Manager

• 쿠버네티스 내 다양한 컨트롤러 관리
• 컨트롤러란 일종의 프로세스
  • 연속적으로 시스템 내 다양한 구성요소들의 상태를 모니터링
  • 전체적인 시스템이 원하는 기능을 수행할 수 있는 상태로 유지되도록

node-controller

• 노드 모니터링 및 응용 프로그램 실행 여부 관리
• kube-apiserver를 통해 관리
• 5초마다 노드 모니터링 (--node-monitor-period)
• 40초 기준으로 unreachable로 명명 (--node-monitor-grace-period)
• 5분이 지나도 unreachable 상태라면 pod 삭제 (--pod-eviction-timeout)

replication-controller

• replica set 관리
• 세트 안에 언제나 원하는 만큼의 pod 수가 유지되는지 관리
• pod가 죽으면 새로운 pod 생성

명령어

• kube-controller manager 다운로드
  wget .../kube-controller-manager
  • kube-controller-manager.service에서 option의 형태로 제공
    • --node-monitor-period
    • --node-monitor-grace-period
    • -- pod-eviction-timeout
  • 사용할 controller들 선택 가능 (기본: 전체)
• kubeadm으로 설치 시 kube-controller-manager 확인
  kubectl get pods -n kube-system
• kubeadm으로 설치 시 kube-controller-manager options 확인
  cat /etc/kubernetes/manifests/kube-controller-manager.yaml
• kubeadm으로 미설치 시 kube-controller-manager options 확인
  cat /etc/systemd/system/kube-controller-manager.service
• 실행 중인 프로세스에서 options 확인
  ps -aux | grep kube-controller-manager

Kube Scheduler

• node에 pod를 스케줄링하는 역할
• 어떤 pod가 어떤 node에 갈지 결정할 뿐, 실제로 pod를 node에 위치시키지는 않음
  • pod를 node에 위치시키는 역할은 kubelet의 역할
• pod는 CPU, 메모리 요구사항을 가지며 이에 맞는 node로 가야함
  • 1. 노드를 필터링 (요구사항을 만족하는 노드만 남김)
  • 2. 노드에 순위를 매김 (순위를 위한 점수 기준은 별도 설정 가능)

명령어

• kube-scheduler 다운로드
  wget .../kube-scheduler
• kubeadm으로 설치 시 kube-scheduler option 확인
  cat /etc/kubernetes/manifests/kube-scheduler.yaml
• 실행 중인 프로세스를 통해 option 확인
  ps -aux | grep kube-scheduler

Kubelet

• 컨테이너로 응용 프로그램(application)을 호스팅하는 worker node의 선장 역할
  • node 등록 (register)
  • pod 생성 (런타임 엔진으로 하여금 이미지를 pull해서 인스턴스를 실행하도록 지시)
  • node와 pod의 상태를 모니터링, kube-apiserver에 전달

명령어

• kubelet 다운로드
  • kubeadm은 kubelet을 배포(deploy)하지 않음
    • 다른 구성요소들과의 차이점, 항상 수동으로 설치해야 함
      wget .../kubelet
• 실행 중인 프로세스를 통해 option 확인
  ps -aux | grep kubelet

Kube-proxy

• 모든 pod는 다른 pod와 소통할 수 있음
  • pod 네트워킹 솔루션을 배포함으로써 가능
  • IP를 통해서 소통 가능하나, IP가 언제나 동일할 것이라는 보장이 없음
    • 서비스(Service)를 통해 응용 프로그램을 노출시키는 것이 안전
    • 서비스는 쿠버네티스 메모리상 존재하는 가상의 요소이기 때문에 pod network에 참여할 수 없음
• kube-proxy는 각 노드에서 실행되는 프로세스
  • 새로운 서비스를 찾고, 트래픽을 서비스로 전송하기 위해 노드에 규칙을 생성하는 역할
  • e.g. iptable rule을 사용할 수도 있음

명령어

• kube-proxy 다운로드
  wget .../kube-proxy
• kubeadm을 통해 설치 시 kube-proxy 확인
  kubectl get pods -n kube-system
kubectl get daemonset -n kube-system