Static Pod

Kubernetes 컴포넌트 By Kubeadm

Kubeadm으로 설치 시, 각 컴포넌트는 다음과 같은 형태로 설치된다

컴포넌트	형태	Node
Api Server	Static Pod	Master Node
Kube Scheduler	Static Pod	Master Node
Controller Manager	Static Pod	Master Node
ETCD	Static Pod	Master Node
Kubelet	Linux Daemon	Master Node, Worker Node
KubeProxy	DaemonSet	Master Node, Worker Node

• Kubelet은 Pod를 관리해주는 Agent이기에 Daemon으로 존재해야 한다. Kubelet이 Pod 형태로 존재하면, 해당 Pod를 관리해줄 것이 없기 때문이다

물론 Kubeadm을 통해 클러스터를 구성할 때, Daemon으로 설치한 컴포넌트를 사용하는 방법도 있다

• Kubeadm init 시 --control-plane-endpoint 옵션을 통해 직접 설치한 Kube Api Server의 엔드포인트를 지정하면 된다.

Api Server , Kube Scheduler 등 Master Node의 컴포넌트들은 Static Pod로 배포되어지는데, Static Pod란 무엇일까

---

Static Pod

Pod는 Kube-ApiServer를 통해 실행된다. 하지만 Kube-ApiServer도 Pod로 실행된다. 그렇다면 이 Kube-ApiServer는 누가 실행시켜주는 것일까?

• Kube-ApiServer, ETCD 등 Master Node의 컴포넌트들은 Kube-ApiServer가 아닌, Linux Daemon인 Kubelet에 의해 실행되고, 관리되는 Static Pod이다

Static Pod의 경로 값을 나타내는 staticPodPath는 /var/lib/kubelet/config.yaml에 정의되어 있으며, 기본 값은 /etc/Kubernetes/manifests이다

• Master Node 컴포넌트들은 기본 Static Pod로 /etc/Kubernetes/manifests에 있다

Kubelet이 실행되면 자신의 config.yaml을 참조하는데, config.yaml에 정의된 staticPodPath에 있는 모든 것들을 배포하고, 정상 실행되도록 관리한다

• Static Pod는 Error가 발생하면, 바로 재시작한다

---

Static Pod Life Cycle

생성

• staticPodPath에 Yaml 파일이 존재하면, 자동으로 Static Pod 생성

유지

• staticPodPath에 Yaml 파일이 존재하면, Static Pod가 정상 작동하도록 유지한다
• Static Pod가 삭제되어도 재생성
• Static Pod에 오류가 발생해도 재시작

수정

• Static Pod는 조회는 가능하지만 Edit이 불가능하다
• 수정하려면 staticPodPatH에 있는 Yaml 파일을 수정해야 한다. 수정하면 자동으로 기존 Static Pod는 삭제되고, 새로운 Static Pod가 생성된다

삭제

• Static Pod를 삭제하려면, 해당 Node의 staticPodPath에 있는 Yaml 파일을 삭제해야 한다

---

Process & Daemon & Service

Kubelet은 Linux Daemon으로 설치되는데, Daemon은 무엇일까?

• 참고 : https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=nahejae533&logNo=221082116166&parentCategoryNo=&categoryNo=92&viewDate=&isShowPopularPosts=false&from=postView
• 참고 : https://velog.io/@dahara3/서비스-Service-데몬-Daemon#서비스--데몬

• 프로세스 : 실행중인 프로그램, 눈에 보이는 건 포어그라운드, 뒤에서 돌아가는건 백그라운드. 작업이 완료 되면 사라진다

• 서비스 , 데몬 : 부팅 때 자동으로 켜지고, 게속해서 백그라운드에서 실행되는 프로세스. 윈도우에선 서비스, 리눅스에서 데몬이라 했었지만, 사실상 같은 말로 취급한다

  서비스와 데몬의 차이

  • 윈도우는 서비스 등록을 위해 .exe 와 같은 프로그램으로 윈도우 api 함수를 이용해 등록한다
  • 리눅스의 경우 서비스 스크립트에 실행 권한을 주고, 리눅스의 최초 프로세스인 Init or Systemd가 부팅할 때 실행하는 스크립트 디렉토리에 넣어두면 된다

    • Init : centos 6.9 이하 일때, 서비스 관리 명령어 - service
    • Systemd : centos 7 이상, 유닛 관리 명령어 - systemctl
    • Systemd는 init오 다르게 병렬로 실행되어 속도가 더 빠르다. 이외에도 다양한 기능 제공. systemd = ini + @

  • 서버 프로그램들은 꺼지지 않고 실시간으로 클라이언트와 통신을 계속 해야 하므로 데몬이라 불린다

Systemd란?

• 리눅스에서 데몬들은 service 파일로 설정되며, systemd 프로세스를 통해 관리된다. systemd는 os 부팅 시 최초로 실행되는 프로세스로 1번 pid를 가진다. systemd는 부팅 시 시스템 초기화 및 환경 설정을 해주며, 시스템을 총 관리해준다