https://youtu.be/UMNCKkdrfUo?si=lWR2HsEa7TnKQSM1
Jussi Nummelin
- Sr. Principal Engineer at Mirantis.
목적
Cluster API
k8s Sub-project, focused on providing declarative APIs and toolings to Simplify provisioning, upgrading, and operating multiple k8s clusters.
한두 개의 클러스터 관리라면 어떻게든 하면 되지만..
- multiple clusters with multiple infrastructure / cloud providers 라면?
- 각각의 provider마다 요구하는 tool이나 flavor가 다름.
목적: Centralized Place / Way to Manage Cluster
구성
Core Concepts
- Management Cluster: 여러 CRD와 operator를 사용해서 다른 클러스터를 관리함.
- Workload Cluster: management cluster가 관리하는 대상.
- Providers
- Custom Resources
모든 provider 기능을 하나의 시스템으로 관리하는 건 불가능했다. Extensibility가 필요함.
- k8s도 처음에 다 통합하다가, 관리가 안되니 싹 external feature로 빼버린 뒤 CSI, CNI와 같은 pluggable interface를 사용.
provider 타입은 크게 세 가지
- infrastructure: Openstack, AWS, Google, BareMetal 등 실제 인프라.
- Control Plane: 'how do we run the control plane for workload cluster'를 관장한다.
- kubeadm 지원. mirantis 솔루션인 kosmotron도 된다.
- bootstrap: running / configuring worker machines of workload clusters.
- kubeadm 지원. mirantis 솔루션인 kosmotron도 된다.
intrastructures & bootstrap providers: Contract between them. cloud init
- infra: "Where do we run the machines (VM)? How do we boot up the VMs?"
- bootstrap: "Once VM up, what do we actually run on the VM?"
bootstrap provider가 cloud init 실행: bootup할 때, 어떤 infrastructure provider 쓸 건지 정의한다.
cluster API는 내부적으로 Abstraction Model 구조를 많이 사용했음.
- OOP 느낌으로 이해하는 게 좋을 듯?
- 예컨대 Cluster 는 추상화한 개념이고 infrastructureCluster가 실제 implementation 중 하나.
Cluster를 어떻게 구현할 건가? -> infrastructureCluster 정보를 본다.
- AWS, Google, OpenStack, BareMetal...
Cluster의 Control Plane은 어떻게 구성할 건가? -> ControlPlane 모델을 본다.
- ControlPlane도 추상화 레벨. 실제 구현은 어떻게 할 건가? -> InfraMachineTemplate / CPConfig로 나뉨.
- InfraMachineTemplate: 어떤 인프라 사용할 건지
- CPConfig: 어떤 Config 사용할 건지. 예컨대 kubeadm을 쓴다? 그럼 kubeadm 설정이 있을 거다.
Worker가 구동할 Machine 정보는? -> Machine 모델을 본다.
- Machine의 실제 구현은? -> 인프라는 InfraMachine, configuration 정보는 K0sWorkerConfig 에서 확인한다.
이런 식으로, 수많은 Object와 object 간 relation으로 만들어진다.
k8s에서 workload를 띄울 때, 개별 pod 하나를 사용자가 직접 통제하는 경우는 잘 없다. Deployment 같은 리소스를 더 많이 씀.
CAPI도 마찬가지. MachineDeployment를 더 많이 쓴다. pod <-> Deployment 관계와 개념적으로 같다.
Example Code
가장 먼저 Cluster 라는 리소스를 yaml로 CRD로 정의한다.
- 복잡한 세부설정을 명시하는 대신, cidr 주소와 controlPlaneRef, infrastructureRef 만 명시함.
- control plane은 예시로 k0smotron (mirantis 프로덕트) 를 정의.
- infra는 Hetzner를 사용.
- 여기서 common infrastructure setting: Security Groups / VPC / subnets... 등등을 지정함.
Deployment 구조는 k8s의 그것과 익숙하다. Spec과 Template의 집합. 여기서 중요한 건
- bootstrap Configuration Ref 정보: 이 machine에서 뭘 실행할 건지
- 어떤 k8s 버전을 설치할 건지 - kubelet, containerd 등등... 필요한 모든 dependency
- intrastructure Ref 정보: 이 machine이 어디서 실행될 건지 (AWS? GCP? BareMetal? etc...)
- 여기서는 HCloud Template을 사용해서 명시 - 이 클라우드에서 지원하는 flavor, OS image 등등
Upgrade
모든 정보를 CR과 Operator로 Declarative하게 만들었기 때문에, CR 정보만 변경해주면 upgrade할 수 있다.
- 몇 가지 방어로직도 지원함.
- 예컨대 control plane node가 업그레이드 안됐는데 worker node가 업그레이드되는 상황을 방지.
- Version Skew Management.
- Orchestration이 쉬워진다.
Standardizing Clusters
CAPI core에서는 ClusterClass 라는 개념을 사용.
- 일종의 default option으로 구성된 cluster 리소스를 말하는 듯. 이걸 기반으로, 균일한 클러스터를 찍어내는 형태
- 다만 커스텀 작업을 위한 parameterize가 굉장히 어렵더라. json Patch 방식
k0rdent 오픈소스 프로젝트에서는 ClusterTemplate 개념을 사용중
- helm 스타일의 템플릿. helm 템플릿도 끔찍하지만, json patch보다는 approachable하니까..
Kyverno와 같은 Policy Engine을 활용
- 특정 팀이나 사용자가 배포할 수 있는 CR을 정의할 수 있다.
Health / remediation
cluster API에는 MachineHealthCheck 라는 CR이 있다.
- 특정 node(s) 와 healthCheck가 매칭될 경우 (예컨대 offline for 10 minutes), 해당 노드 제거하고 새로 만드는 식.
- k8s의 health check와 개념적으로 유사하다.
Workload Management
Workload 관리는 어떻게 하나: CAPI의 ClusterResourceSet 이라는 CR.
- CR을 사용해서 여러 cluster에 동일한 workload를 배포할 수 있다.
- 또는 GitOps 형태로, cluster API로 만들어진 k8s 클러스터는 git에서 필요한 config 받아서 workload를 배포할 수도 있음.
k0rdent / Sveltos (오픈소스 프로젝트) 에서는 Central Management 방식을 제공함.
- Management Cluster를 Source of Truth로 두는 것.
Review
CAPI: Declarative, Central Place to Manage your workload clusters
- with different Providers, abstracting away the infrastructure / control plane / bootstraping worker nodes
- driven By Custom Resources.