1. k8s architecture
master node = control plane
- 제어 영역
- 모든 작업이 예약되는 시기와 라우팅되는 노드의 위치를 결정
worker node = data plane
- 실제 작업(pod)이 실행되는 영역
( pod : container를 포함하고 application을 실행 )
-> pod > container > application
2. k8s 작동 순서
위 사진의 번호 대로 아래의 작업이 실행됩니다 !!
1) 사용자가 pod.yaml을 실행하면
- master node에서 보안(인증+인가) 검사
작업1) 보안 검사를 위해 TLS 암호화로 전달
작업2) Authentication(인증) check
작업3) Authorization(인가) check
작업4) Admission controller (verifying)
2) apiserver가 요청을 받음
- apiserver : k8s cluster 중앙제어시스템
apiserver가 가장먼저 요청을 REST API 기법으로 받음
3) etcd라는 DB에 사용자 요청 정보를 기록
- etcd
- key-value 구조의 DB이자 B*tree index 구조로 저장
- cluster의 상태정보를 저장하는 database
- etcd는 하나의 pod로 container 형태로 DB를 운영
- etcd는 master node에서 관리하지 않고 별도로 관리하는 것이 좋다
- 사용자 요청 정보를 기록
- DB 에 기록 후 회신(ack)
4) apiserver
- 작업1) apiserver가 etcd로 부터 회신받음
- 작업2) kube-scheduler-k8s-master에게 배치(placement) 요청
- kube-scheduler-k8s-master 스케줄러는 요청된 pod를 어떤 노드에 배치할지 결정하는 계산하는 방법인 알고리즘을 가지고 있음
kube-scheduler-k8s-master은 점수제로 스케줄 결정
ex) master(), node1(4), node2(8) : 점수가 높은 2번 노드에 감
- 작업3) 스케줄러가 apiserver에게 배치될 노드를 지정해줌
- 작업4) master의 kubelet에게 작업요청을 apiserver가 전달
- 작업5) kubelet이 해당 작업노드의 kubelet에게 전달
5) kubelet으로 전달된 작업 수행(pod 생성)
- worker node에서 요청 받음
- docker의 containered or crl-o
6) pod 생성
- container runtime 이 docker-ce engine을 통해 container 생성
- pod 생성 및 작업
7) apiserver에게 작업됨을 알림
- '실행과 동시에 사용자에게는 생성되었습니다.' 라는 메시지를 우선적으로 전달
- kubectl get pod 를 통해 조회하면 '생성중~' -> running
- 동시에 etcd에 기록
3. 추가 개념
1) 상위 object 작동 순서
- 상위 object : Deployment, Replication controller. ReplicaSet, DaemonSet, Cronjob, Job ..
if, Deployment와 같은 상위 object를 생성하게 되면 controller가 관리
(controller : kube-controller-manage-k8s-master)
- pod 생성
- replicas : 복제(3)
- 사용자 요청 pod수를 유지하면서 장애 시 관리
2) pod
kubectl get pod -o wide : 어떤 노드에 pod 생성됨을 확인
- IP -> --pod-network-cidr
- pod ip는 cluster에 포함된 모든 노드에서 조회할 수 있지만 외부 연결은 X
curl PodIP:8000 : 모든 노드에서 조회 가능
why? 그이유는 calico가 모든 node에 다 있기 때문에 calico 끼리 통신하고 있음 (즉, BIRD가 있기 때문에 가능) - 외부에서 연결을 허용하려면 service object를 생성하여 pod와 연결
Data Engineer