1. 파드 배포 내부 동작 과정
참조: https://www.joinc.co.kr/w/man/12/kubernetes/overview
참조: https://jx2lee.github.io/cloud-pod-creation-process/
- 사용자가 pod 배포 요청 ( kubectl )
- api server 에서 해당 명령을 내린 사용자 인증 및 권한 확인
- api server는 etcd에 새로운 상태 저장
- 컨트롤러 매니저는 api server를 통해 etcd 상태 변경을 감지하고, 알맞은 컨트롤러를 이용하여 pod 생성을 api server에 요청
- etcd에 pod 정보 저장
- 스케줄러에서 apiserver를 통해 해당 pod 의 spec.nodeName이 비어있음을 확인하고, pod를 생성할 node를 선택
- node를 선택하면, pod와 노드를 바인딩하기 위한 binding-resource를 생성하기 위해 api server에 요청을 한다. ( binding resource는 개체를 다른 개체와 연결하는 것 )
- 스케줄러는 binding-resource를 생성하여 api server를 통해 etcd에 저장된 pod 의 spec.nodeName 필드를 채워서 업데이트
- pod의 노드 정보가 업데이트 되면, 해당 노드의 kubelet이 api server를 통해 생성할 pod 정보를 확인
- kubelet에서 runtime에게 cri ( grpc 프로토콜 )을 통해 pod 생성 요청
- 이후 kubelet이 생성된 파드를 모니터링하여 상태 정보를 api server에게 전달
- 전달된 정보는 ETCD에 기록되며, 컨트롤러가 상태 정보를 통해 Pod를 관리해준다
2. Kubectl Apply 란
참고: https://seongjin.me/kubernetes-imparative-vs-declarative/
명령형 접근법 & 선언형 접근법
-
명령형 접근법 : kubectl run,create 명령같이 어떻게 만들지 필요한 동작을 지시. 최신 적용 설정은 업데이트 되지 않고, 활성 객체 설정만 바뀐다.
-
선언형 접근법 : yaml 파일 같이 필요한 상태를 정의. 필요한 작업은 쿠버네티스 시스템이 알아서 동작. 명령형으로 구축된 객체와 다르게 활성 객체 설정의 어노테이션 안에 최신 적용 설정을 가지고 있다.
활성 객체 설정
-
활성 객체 설정은 클러스터 안에 구동중인 객체에 대한 정보를 담고 있는 데이터로 대개 etcd 에 저장된다.
-
선언형으로 만든 객체라면, 원본 객체 구성 파일인 yaml 파일의 내용이 json 포맷으로 변환되어 활성 객체 설정의 어노테이션 내부에 최신 적용 설정으로 삽입된다.
Kubectl Apply란?
-
kubectl apply 란 원본 객체 구성 파일의 내용을 json 포맷으로 변환되어 활성 객체 설정의 어노테이션 내부의 최신 적용 설정에 삽입하여 활동 객체 설정과 최신 적용 설정을 업데이트 하는 것.
-
만약, 추가나 수정의 경우 활성 객체 설정과 yaml 파일 내용을 대조하여, 일치하지 않는다면, 해당 파일 내용을 기준으로 활성 객체 설정과 최신 적용 설정을 업데이트합니다.
-
삭제의 경우 최신 적용 설정과 원본 객체 구성 파일을 비교하여 없는 부분을 활성 객체 설정에서 제거합니다. 이후 최신 적용 설정은 원본 객체 구성 파일 내용에 따라 업데이트 합니다.
Annotation이란?
-
메타데이터 : 데이터에 관한 구조화된 데이터. 데이터를 설명하는 데이터를 의미한다.
-
구조화된 데이터 : 다양한 정보를 담고 있는 콘텐츠를 논리적으로 조직화하여 가공된 데이터.
-
쿠버네티스에서 어노테이션은 쿠버네티스 시스템에서 필요한 정보들을 담고 있다. key value 형태이며, 시스템에서 인식 가능한 값을 key 로 사용. 검색이 불가하며 메타데이터 입력만 가능.
-
라벨은 클로스터 내부에 객체를 구분하기 위해 사용하는 값으로 key value 구조이며, 사용자가 메타데이터로 붙일 수 있다. 라벨 셀렉터를 통해 검색과 식별이 가능.
