[Kubernetes] Control Plane 과 Data Plane 이 친구가 되는 방법 - kubeadm init 편

 

 

EKS 와 같은 클라우드가 제공해주는 쿠버네티스가 아닌, 온프레미스 환경에서 쿠버네티스를 설치한다고 하면 보통 kubeadm 이라는 툴을 이용해서 구성하게 됩니다.

 

Control Plane 은 kubeadm init 를 통해 구성되고, Data Plane 은 kubeadm join 을 통해 쿠버네티스에 조인하게 됩니다.

 

kubeadm 툴 하나면 API Server, Scheduler, Control Manager, ETCD 등 Control Plane 에 필요한 모든 것들이 마법처럼 자동으로 구성되죠.

 

물론 kubelet 그리고 containerd 와 같은 cri-구현체는 이미 실행되고 있어야 합니다!

 

 

자동이란 것이 확실히 편의성을 제공해주긴 하지만, 자동으로 구성되기 때문에 그 안에서 무슨 일이 일어나고 있는지는 파악하기 힘듭니다.

 

"Control Plane 은 Data Plane 가 누군지 알고, 껴주는거야?", "Control Plane 은 뭘 보고, Data Plane 상태가 괜찮다고 판단하는거야?" 라고 물어봤을 때 "kubeadm 이 다 알아서 해줘" 라고 답할 순 없잖아요.

 

 

 

그래서 Control Plane, Data Plane 의 생성과 조인까지 어떤 워크플로우로 진행이 되는 지, 알아보고자 합니다.

 

글은 여러 편으로 나누어 진행될 예정이며, 여기서는 Controler Plane 의 생성을 담당하는 kubeadm init 에 초점을 맞춥니다.

 

그럼 렛츠두더코드~

 

 

kubeadm init options

---

 

kubeadm init 은 아래에 명시되어 있는 것들을 전부 자동으로 생성해줍니다.

Control Plane 을 구성하는 컴포넌트에 대한 설치 및 필요한 환경을 구성해준다고 보면 됩니다.

preflight                    Run pre-flight checks
certs                        Certificate generation
  /ca                          Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components
  /apiserver                   Generate the certificate for serving the Kubernetes API
  /apiserver-kubelet-client    Generate the certificate for the API server to connect to kubelet
  /front-proxy-ca              Generate the self-signed CA to provision identities for front proxy
  /front-proxy-client          Generate the certificate for the front proxy client
  /etcd-ca                     Generate the self-signed CA to provision identities for etcd
  /etcd-server                 Generate the certificate for serving etcd
  /etcd-peer                   Generate the certificate for etcd nodes to communicate with each other
  /etcd-healthcheck-client     Generate the certificate for liveness probes to healthcheck etcd
  /apiserver-etcd-client       Generate the certificate the apiserver uses to access etcd
  /sa                          Generate a private key for signing service account tokens along with its public key
kubeconfig                   Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
  /admin                       Generate a kubeconfig file for the admin to use and for kubeadm itself
  /super-admin                 Generate a kubeconfig file for the super-admin
  /kubelet                     Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes
  /controller-manager          Generate a kubeconfig file for the controller manager to use
  /scheduler                   Generate a kubeconfig file for the scheduler to use
etcd                         Generate static Pod manifest file for local etcd
  /local                       Generate the static Pod manifest file for a local, single-node local etcd instance
control-plane                Generate all static Pod manifest files necessary to establish the control plane
  /apiserver                   Generates the kube-apiserver static Pod manifest
  /controller-manager          Generates the kube-controller-manager static Pod manifest
  /scheduler                   Generates the kube-scheduler static Pod manifest
kubelet-start                Write kubelet settings and (re)start the kubelet
upload-config                Upload the kubeadm and kubelet configuration to a ConfigMap
  /kubeadm                     Upload the kubeadm ClusterConfiguration to a ConfigMap
  /kubelet                     Upload the kubelet component config to a ConfigMap
upload-certs                 Upload certificates to kubeadm-certs
mark-control-plane           Mark a node as a control-plane
bootstrap-token              Generates bootstrap tokens used to join a node to a cluster
kubelet-finalize             Updates settings relevant to the kubelet after TLS bootstrap
  /experimental-cert-rotation  Enable kubelet client certificate rotation
addon                        Install required addons for passing conformance tests
  /coredns                     Install the CoreDNS addon to a Kubernetes cluster
  /kube-proxy                  Install the kube-proxy addon to a Kubernetes cluster
show-join-command            Show the join command for control-plane and worker node

 

 

실제로 생성되는 파일들입니다.

/etc/kubernetes

 

 

또한 kubeadm init 은 옵션을 통해 클러스터의 전반적인 설정을 할 수 있습니다.

 

예를 들면, --apiserver-bind-port=6443(default) 를 주어 API Server 의 포트를 지정할 수 있고, --service-dns-domain=cluster.local(default) 를 통해 클러스터 내 도메인을 설정할 수 있습니다.

 

--service-cidr=10.96.0.0/12(default) 를 통해 서비스들이 할당 받는 가상 IP 범위도 조절이 가능합니다.

10.96.0.0/12 CIDR 를 가진다면, 10.96.0.0 ~ 10.111.255.255 까지 IP 할당이 가능하며 총 1,048,576 개의 IP 를 쓸 수 있죠.

 

그리고 실제로 서비스의 IP 를 보면 범위 내에서만 할당된 걸 볼 수 있습니다.

service ips

 

 

이외에도 다양한 옵션들이 있으며 공식문서에서 직접 확인해 보시길 바랍니다.

 

그럼 본격적으로 kubeadm init 의 워크플로우를 알아보겠습니다.

 

kubeadm init workflow

---

 

1. 본격적인 프로세스 실행 전에 pre-flight 체크를 통해 시스템의 상태를 체크하게 됩니다. 현재 kubeadm 이 실행되는 호스트의 상태를 체크해 Control Plane 으로 쓸 수 있을지 확인합니다.

 

Warning 이 아닌 에러를 발견하게 된다면 kubeadm 은 프로세스를 곧 바로 중단하게 됩니다.

 

에러의 예로는 IsPrivilegedUser,Swap 등 이 있고 --ignore-preflight-errors 옵션을 통해 명시된 에러는 무시할 수 있습니다.

 

 

2. 쿠버네티스 컴포넌트끼리 안전한 TLS 통신을 위해 각 컴포넌트마다 필요한 crt, key 를 --cert-dir=/etc/kubernetes/pki(default) 에 생성하게 됩니다.

생성되는 crt, key 들

 

3. API Server 와 통신하기 위한 kubelet, controller manager, scheduler 의 kubeconfig 를 작성합니다.

또한 사용자가 API Server 와 통신할 수 있도록 admin.conf 도 생성합니다.

 

cp -i ./etc/kubernetes/admin.conf ~/.kube/config 를 통해 kubectl 명령어를 사용할 때 admin 유저로 API Server 에 접근하게 됩니다.

 

그리고 이렇게 생성된 kubeconfig 는 RBAC 에서 사용됩니다.

kubeconfig

 

아래는 scheduler 에 대한 kubeconfig 내용입니다.

scheduler kubeconfig

 

clusters[].cluster.certificate-authority-data 에 작성되어 있는 건 쿠버네티스 자체 ca.crt 입니다. 

디코딩 해서 내용을 보면 Issuer, Subject 모두 kubernetes 이므로 자체 사인한 CRT 라는 걸 알 수 있죠.

자체 사인한 ca.crt

 

 

그리고 kubelet, controller manager, scheduler 모두 Issuer 가 kubernetes 인 것을 보아 ca.crt 의 하위 crt 라는 걸 확인할 수 있습니다.

dkubelet, controller manager, scheduler 의 crt

kube-scheduler 가 본인의 Private Key 를 통해 CN 이 system:kube-scheduler 인 CertificateSigningRequest(CSR) 을 만들고, 이 CSR 은 CA 의 CRT 에 승인되어 CRT 가 생성됩니다. 그리고 scheduler.conf 에 작성되어 있는 내용이 이 CRT 입니다.

이 CRT 와 system:kube-scheduler cluster role 을 통해  API Server 와 통신을  할 수 있게 됩니다.
전형적인 RBAC 플로우를 따르고, 나머지 컴포넌트들도 같은 방식을 따릅니다.

 

 

4. API Server, Controller Manager, Scheduler, ETCD 에 대한 Static Pod Manifest 를 생성합니다. 

이로써 Control Plane 이 본격적으로 실행됩니다.

Static Pod 는 특정 경로 위에 manifest 를 작성해놓으면 API Server 가 아닌 kubelet 이 직접 관리하는 파드입니다.

manifests

 

아래는 kube-apiserver.yaml 의 내용인데, 우리가 아는 흔한 파드의 모습이죠.

kube-apiserver.yaml

 

kubeadm 은 4분 동안 API Server 의 Liveness Probe 가 localhost:6443/healthz 에서 200 ok 응답 코드가 오는 지 기다립니다.

그리고 교착 상태를 감지하기 위해 kubelet 의 Liveness Probe, Readiness Probe 를 각각 localhost:10255/healthz,
localhost:10255/healthz/syncloop 을 통해 체크하고 40~60 초 내에 응답이 오지 않으면 빠르게 실패처리하게 되죠.

Static Pod 인 API Server 가 Kubelet 에 의해 실행, 관리되고 해당 Kubelet 을 가지는 노드가 Control Plane 으로 등록되게 됩니다.

[참고자료] 

 

5. 레이블과 Taints 를 컨트롤 플레인에 추가함으로써 더 이상의 워크로드(ex. 디플로이먼트, 데몬셋) 등 이 실행되지 않도록 합니다.

추가되는 레이블과 테인트

 

6. 추가적인 Data Plane 이 Control Plane 에 스스로 등록될 수 있도록 토큰을 생성합니다.

수동으로 유저가 kubeadm token create --print-join-command --ttl 60 과 같은 명령어를 통해 직접 생성할 수 있습니다.

 

7. Bootstrap Tokens 와 TLS Bootstrap 메커니즘을 이용해서 Data Plane 조인을 허용하는 모든 구성을 수행합니다. 

이 부분은 다음 예정 글인 kubeadm join 섹션에서 더 자세히 다루겠습니다.

 

 

8. 추가적인 컴포넌트인 CoreDNS, Kube Proxy 를 설치합니다. 파드 간 통신에 필요한 CNI 는 따로 설치해야 합니다.

 

이러한 워크플로우를 통해 Control Plane 이 생성되고, Data Plane 을 조인할 수 있게끔 준비를 합니다.

(Data Plane 조인에 대해선 다음 글에서 다루겠습니다)

 

 

추가적으로 kubeadm init 를 통해 생성된 파일들 중 하나를 실수로 지웠다하더라도 kubeadm init phase 를 통해 하나하나 디테일하게 생성 및 커스텀이 가능합니다.

kubeadm init phase

 

 

 

다음 글로 이어집니다!

그럼 오늘은 여기까지!