카테고리 없음

CKA 자격증 준비 자료 정리 1 (Core Concepts)

minminit 2022. 3. 3. 19:49

Cluster Architecture

쿠버네티스의 구조에 대한 내용으로, 구성 요소에 대한 간략한 설명 포함

ETCD

정보를 key-value 형태로 저장하는 데이터베이스 (컨테이너가 어떤 ship에 있는지, 언제 load되었는지 등 각 다른 ship들에 대한 정보를 저장)

 

ETCD in K8S

  • nodes, pods, configs, secrets, accounts, roles, bindings .. 등 cluster에 관한 정보 저장
  • kubectl의 모든 정보들은 ETCD 서버에서 오는 것
  • 모든 변화(노드 추가, 파드 배포 등) 또한 ETCD 서버에 업데이트

ETCD pod

  • kubeadm으로 설치했다면 kube-system에 etcd-master라는 이름으로 배포됨
  • 저장된 key들 확인 가능
    • $ kubectl exec etcd-master -n kube-system etcdctl get / --prefix -keys-only

ETCD in High Availability Environment

  • 여러 master 노드 -> 여러 instance 존재
  • 각 ETCD instance가 서로를 알 수 있도록 etcd.service에 올바른 파라미터를 지정해야 함

Kube-API server

클러스터 내 변화를 수행하기 위한 모든 다양한 작업들의 중심 역할

  1. Authenticate User
  2. Validate Request
  3. Retrieve data
  4. Update ETCD
  5. Scheduler
  6. Kubelet

 

Kube API server work pattern

  • kubectl 사용시
    • kube-api 서버는 request를 인증/확인 후 etcd cluster에서 데이터를 검색해 반환
  • pod 생성시
    • api 서버는 pod object 생성 (노드 할당X)
    • etcd 서버에 pod가 생성되었음을 업데이트
    • scheduler는 api 서버를 모니터링 하고 있으므로, 새로운 pod 인지, 배포 노드 확인
    • api 서버는 etcd에 정보 업데이트
    • api 서버가 해당 정보를 적합한 노드의 kubectl에 전달
    • kubelet이 노드에 pod 생성, container runtime engine에 application image를 배포하도록 지시
    • kubelet은 api 서버에 상태 업데이트, api 서버는 data를 etcd에 저장

=> 모든 변화가 이러한 패턴을 따름

  • kubeadm으로 설치했다면 kube-system에 kube-apiserver-master
    • apiserver 정의 파일 => /etc/kubernetes/manifests/kube-apiserver.yaml
  • non-kubeadm 설치시 /etc/systemd/system/kube-apiserver.service.yaml
  • ps-aux | grep kube-apiserver
    • master node process의 kube-apiserver를 통해 실행중인 process 확인 및 effective option 확인

Kube Controller Manager

  • 시스템 내 다양한 구성 요소의 상태를 지속적으로 모니터링하고, 전체 시스템을 원하는 상태로 만들기 위해 작동하는 프로세스
  • 여러 Controller가 하나의 프로세스로 패키징되어 실행되는 형태 => Kube Controller Manager
    • Node Controller, Namespace-Controller, Replication-Controller ... 등등

Node Controller

  • 노드들의 상태를 모니터링, application이 계속 실행될 수 있도록 필요한 조치를 수행
  • node-monitor-periods=5s : 노드 컨트롤러가 5초마다 노드의 상태를 체크
  • node-monitor-grace-period=40s : 노드가 정상적이지 않은 경우, 40초를 기다린후 unreachble 상태로 표기
  • pod-eviction-time=5m0s : 노드가 5분안에 정상화 되지 않을 경우, 해당 노드에 할당된 pod을 삭제하고 다른 정상 노드에 생성할 수 있도록 함

Replication Controller

  • replica set의 상태를 모니터링하고, 의도된 수의 pod이 available한지 확인하는 역할
  • pod가 하나 삭제되면, 하나 더 생성

Kube Controller Managed pod

  • kubeadm으로 설치했다면 kube-system 에 kube-controller-manager-master
    • apiserver 정의 파일 => /etc/kubernetes/manifests/kube-controller-manager.yaml
  • non-kubeadm 설치시 /etc/systemd/system/kube-controller-manager.service
  • ps -aux | grep kube-controller-manag
  •  

Kube Scheduler

  • pod이 어떤 노드로 갈 것인지 결정하는 역할 (실제로 노드에 pod를 배치하는것 X -> kubelet)
  • 노드 선정 방식
    • pod가 요구하는 리소스를 보고 필터링
    • pod를 배치하고 해당 노드에 더 많은 리소스가 남는 경우를 상위로 rank 지정

Kube Scheduler pod

  • kube-scheduler 라는 이름으로 위와 동일

Kubelet

  • master의 scheduler의 지시에 따라, 컨테이너를 load/unload하는 역할
  • 컨테이너의 상태를 일정 간격에 따라 report
  • kubelet은 worker 노드에 pod을 생성하기 위해 container runtime(ex..docker)에 요청을 전달
  • kubelet은 pod과 컨테이너의 상태를 지속적으로 모니터링하고 결과를 kube-apiserver에 주기적으로 전송

 

kubelet 설치

  • kubeadm으로 worker 노드를 구성할 경우, kubelet이 자동으로 설치하지 않으므로 별도로 kubelet을 설치해야함

Kube Proxy

  • 쿠버네티스 클러스터의 모든 pod은 서로 다른 pod과 통신할 수 있음
    • 클러스터 내 pod 네트워크를 담당하는 기능이 배포되어 있음
    • pod 네트워크는 모든 pod가 통신할 수 있도록 클러스터의 모든 노드에 생성되는 가상 네트워크ㅡ
  • 특정 pod에서 다른 pod에 접근하기 위한 가장 좋은 방법은 service를 이용하는 것
    • service도 ip를 할당 받으며, pod이 이 ip로 서비스에 접근하고자하면, traffic이 pod로 foward 됨
    • 서비스란 무엇이며, ip는 어떻게 얻는 것인가..
      • service는 실제로 존재하는 것이 아님
      • 쿠버네티스 메모리 상에 존재하는 가상 컴포넌트 개념
      • 서비스 접근은 kube-proxy를 통해 가능
  • Kube Proxy
    • 쿠버네티스 클러스터 내 모든 노드에서 실행되는 프로세스
    • 새로운 서비스를 찾는 역할
      • 서비스가 생성되면 어떤 서비스에 대해 어떤 pod로 traffic을 fowrd할 지에 대한 rule 생성
      • 네트워크 룰 생성 -> IPTABLES 사용
        • 모든 노드에 service의 ip로 들어오는 트래픽에 대해 해당 pod로 보낼 수 있는 규칙을 IPTABLES에 만들어줌

Kube proxy pod

  • kubeadm은 모든 노드에 kube-proxy를 배포하며, daemon set으로 배포된다.
    • 모든 클러스터의 노드마다 오직 하나의 kube-proxy pod이 실행될 수 있음
  • kubectl get daemonset -n kube-system