1) About
kubectl 명령어를 치면 Kube API Server가 받게 되고, 절차에 따라 명령어를 처리하게 됨
GET, POST 두 종류의 명령어가 있다고 할 수 있고, GET은 조회 POST는 그 외의 작업들을 말함
GET의 경우 명령어를 날리게 되었을 때 인증 → 검증 → ETCD 조회의 순서로 처리되고, 여기서 알 수 있듯이 뭔가를 조회할 때는 마스터 노드에서의 ETCD 데이터베이스 내에서 모든 정보를 얻음
POST의 경우 인증 → 검증 → ETCD 까진 동일하고 그 이후엔 명령어에 따라 달라지나, 대체로 비슷
예를 들어 Pod 생성을 하면 인증 → 검증 → Pod를 노드에 할당하지 않고 생성 → ETCD에 Pod 생성 기록 → Pod 생성됨을 반환 → Kube Scheduler를 통해 노드에 할당되지 않은 Pod를 찾고 노드 배정 → ETCD에 반영 → 마스터 노드로부터 노드 배치 요청을 Kubelet이 받음 → Kubelet에 의해 노드에 배치된 Pod에서 이미지에 해당되는 컨테이너 생성의 순서로 이뤄짐
2) System
쿠버네티스를 구성하는 요소들은 서로 통신할 때 SSL/TLS를 기반으로 소통하고 연결성을 보장 받음 (따라서 Kube API Server를 설정할 때 인증서와 관련된 값들도 들어감)
마스터 노드 내에 존재하는 Kube API Server만이 ETCD와 통신하고 ETCD를 읽고 쓰는 작업을 수행할 수 있는데, 따라서 Kube API 를 설정할 때는 ETCD를 연결하기 위한 소켓 정보도 받음
클러스터 내에서 Kube API Server가 어떻게 설정되었는지 보고 싶다면 확인할 수 있음 (단, 클러스터를 어떻게 구성했는지에 달려 있는데 kubeadmin을 사용한 경우와 그렇지 않은 경우로 나뉨)
kubeadmin을 사용한 경우엔 Kube API Server를 마스터 노드 내에 kube-system 네임스페이스의 Pod로써 배포하게 되는데, /etc/kubernetes/manifests/kube-apiserver.yaml 라는 Pod 정의 파일을 보면 Kube API Server 설정 값들을 확인할 수 있음
kubeadmin을 사용하지 않은 경우엔 Kube API Server를 Pod가 아닌 별도의 데몬으로 구동되기 때문에 /etc/systemd/system/kube-apiserver.service 경로의 서비스 정의 파일을 통해 설정 값을 확인할 수 있음
*혹은 마스터 노드 내에서 ps -aux | grep kube-apiserver를 통해 Kube API Server를 구동한 옵션들을 확인할 수 있음