안녕하세요 Humanscape Software Engineer david 입니다.
쿠버네티스 운영시 여러 클러스터의 프로비저닝, 업그레이드 및 운영 단순화, 클러스터 수명주기 관리를 자동화하고 다양한 환경에서 일관되고 반복 가능한 클러스터의 배포를 도와주는 Cluster api에 대해 공부한 내용을 공유드리려합니다.
쿠버네티스의 클러스터를 구성하는 데는 설치 과정에서의 중복이 많이 있습니다. 이를 해결하기 위해 kubeadm이 탄생하였고, kubespray, minikube, kind 등 쿠버네티스 클러스터를 부트스트랩을 도와주는 여러 도구들이 있습니다.
그러나 kubeadm은 설치 복잡성은 줄여주지만 클러스터의 일상적인 관리나 쿠버네티스 환경을 장기적으로 관리하는 방법을 다루지는 않습니다.
다음과 같은 질문이 있을 수 있습니다.
- 여러 인프라에서 머신, 로드 벨런서, VPC 을 일관되게 프로비저닝 하려면 어떻게 해야하나요?
- 업그레이드 및 클러스터 삭제와 같은 것을 포함하여 클러스터 수명주기 관리를 자동화 하려면 어떻게 해야하나요?
- 클러스터 수에 관계없이 이러한 프로세스를 확장하려면 어떻게 해야하나요?
그래서 SIG에서는 Cluster Lifecycle은 클러스터 생성, 구성 및 관리를 자동화하는 선언적 Kubernetes 스타일 API를 구축하는 컨셉으로 Cluster API 프로젝트를 시작하게 되었습니다.
SIG?
SIG Docs는 쿠버네티스 프로젝트의 분과회(special interest group) 중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다.
Bootstrap Controller
- 클러스터 Bootstrap
- 머신 Bootstrap, 클러스터 내에서 역할 수행
Bootstrap을 체계화해주는 Bootstrap Provider는 다음과 같이 3가지가 있습니다.
- CABPK (Cluster API bootstrap provider Kubeadm)
- CABPT(Cluster API Bootstrap Provider Talos)
- CABPE(Cluster API Bootstrap Provider EKS)
[참고] 다양한 약어들, 네이밍 가이드
CAEP(Cluster API Enhancement Proposal) / CAPI(Core Cluster API) / CAPA( Cluster API Provider AWS) / CAPD(Cluster API Provider Docker) / CAPG( Cluster API Google Cloud Provider) / CAPIB(Cluster API Provider IBM Cloud) / CAPO(Cluster API Provider OpenStack) / CAPV(Cluster API Provider vSphere) / CAPZ(Cluster API Provider Azure)
공식 가이드에는 CABPK으로 진행되어있습니다.
Bootstrap 수행시 상태 변화
- Pending
- Bootstrap Providers(Kubeadm, Talos, EKS)는 ‘pending’ ‘상태의 시스템을 보다가 BootstrapConfig.Status.BootstrapData를 생성하고 BootstrapConfig.Status.Ready = true를 설정
- Machine Controller는 BootstrapConfig.Status.BootstrapData에서 Machine.Spec.Bootstrap.Data를 설정
- Machine Controller는 다음 상태로 전환
2. Provisioning
- Infrastructure provider는 “provisioning”상태의 머신을 보다가 해당 머신에 대한 인프라 생성
- MachineInfrastructure가 준비되면 MachineInfrastructure.Status.Ready = true로 설정
- Machine controller는 MachineInfrastructure.Status.Addresses에서 Machines.Status.Addresses를 설정
3. Provisioned
- Machine controller “provisioning” 상태 와 MachineInfrastructure.Status.Ready = true인 Machines을 봄
- Machine controller가 Machine.Status.Phase = “provisioned” 설정
4. Running
- Machine controller는 Machine.ProviderID가 설정되고 동일한 ProviderID를 가진 K8s 노드가 발견되고 준비 상태에있을 때 전환
Cluster Controller
- Cluster.Spec.InfrastructureRef 참조 인프라 객체에서 OwnerReference 설정
- 삭제 후 모든 소유 객체 Cleanup
- 클러스터의 상태와 인프라 클러스터의 상태 동기화
- 워크로드 클러스터에 대한 kubeconfig secret 생성
Q. Terraform 과의 호환
kops 이외에도 kubeadm, kubespray, kube-aws, kubicorn , Kubernetes the hard way 등 K8s Cluster를 셋업하는 다양한 방법이 있지만, kops를 사용하기로 결정한 이유는 kops는 terraform을 통해 프로비저닝 할 수 있기 때문이다. terraform을 처음 써본 뒤로 가능하면 AWS 인프라는 Terraform을 통해서 생성/관리하려고 하고 있다. [출처]
- 위과 같은 블로그의 글과 해당 발표자료를 보고 kops외에는 terraform 과 호환이 잘 되지 않은지 궁금증이 생겼습니다.
- kops를 사용해보신 분은 효율적이 측면에서 좋았고 single cluster를 운영할 때는 좋은 선택일 수 있다는 의견을 주시기도 했습니다.
Cluster Controller 흐름도
Cluster Controller 구성
Required fields
- spec > controlPlaneEndpoint: 대상 클러스터의 apiserver에 연결하는 데 사용되는 endpoint
- status > ready: 인프라 준비 상태
Optional fields
- status > failureReason: 오류가 발생한 이유 문자열 설명
- status > failureMessage: 오류에 포함 된 문자열 메시지
Secret
Kubeadm는 필요한 모든 CA(Certificate Authorities)를 생성, provider가 제공하는 CA가 아닌 사용자 지정 CA도 사용 가능하다고 합니다.
감사합니다.
Walk with us!
기술이 세상을 더 아름답게 할 수 있다고 믿으신다면, 휴먼스케이프와 함께 소중한 뜻을 펼칠 수 있습니다.함께 걸어가며 성장하실 분, 언제든지 연락해주세요 :)
