KubeCon2024 - Cluster API Deep Dive - Roadmap to API Graduation

• Cluster API Deep Dive - Roadmap to API Graduation
  • Vision
  • How does it Work?
  • Transition to v1beta2 API
  • Changes in CAPI v1.9
  • in-place upgrade
  • Q&A

https://www.youtube.com/watch?v=F2iO_cKKPuI

 

• Christian Schlotter: Apple SW Engineer. Cluster API maintainer
• Vince Prignano: Broadcom Engineer. Cluster API maintainer

Vision

7년쯤 전 Meta Cloud 라는 목표를 위함.

• production-ready, declarative API가 있는 상황에서 managing the clusters as Easy as Possible.
• cluster as a Service 형태의 솔루션 / usecase 에 유용하도록.
• extension points
  • 포럼에서 새로운 기능 관련해서 토론 -> 최대한 Generic한 feature일 경우 도입.
  • Not fit in Core -> extension 형태로 제공. (build outside)

Cluster API?

• k8s Style API와 패턴을 사용해서 Cluster Manages itself.
  • automates create, configuration, management for platform operators.
  • 기본적으로 kubeadm을 사용한 cluster management. create / upgrade 등의 작업을 safely하게 수행함.
• cluster lifecycle에 필요한 노력을 최소화한다. (make it boring)
• Extensibility: 다양한 provider를 지원한다. (AWS, Azure, GCP 외에도 BareMetal)
• production-Ready 상태. community 활성화 잘 되어 있다.

How does it Work?

Management Cluster를 하나 두고, 얘가 다양한 provider의 cluster를 관리하는 것. (agnostic)

• 모든 컴포넌트는 plugable.
  • Core Controller에서 관리하는 리소스 조합은 k8s Deployment - pod 구조와 동일하다. (MachineDeployment -> MachineSet -> Machine). Actual Machine을 관리하는 역할.
  • infra Controller: provider 역할. 예컨대 AWS 인프라라면 AWS Controllers.
  • bootStrap Controllers: provisioned machine을 k8s 노드로 전환.

Transition to v1beta2 API

최종 목적은 Managing the lifecycle of cluster, using Declarative API.

• Huge Umbrella issue가 있음. (v1 론칭을 못하는 이유)

v1beta2 API의 목적: improve Status of Cluster API resources.

• cluster api 내부 동작을 모르더라도 뭐가 일어나고 있는지는 알 수 있어야 한다.
• v1beta1 때 필드를 넣고, 사용자 피드백 받은 뒤 v1beta2 에서 개선하는 형태.

Changes in CAPI v1.9

• Controller-runtime이 지원하는 retry 로직을 Drain에 도입.
  • 예전에는 Pod 1개당 goroutine 1개 - 대규모 cluster의 경우 scale 문제가 있었음
  • controller-runtime 활용한 retry에도 뭔가 문제가 있어서 아무튼 수정했다는 듯
• 커뮤니티 요청으로 MachineDrainRule 이라는 CR 추가.

in-place upgrade

• Immutable Infrastructure: 예측 가능하고, 안정적이며, 동일한 configuration을 유지해야 한다.
• MachineDeployment의 label을 수정하는 등 inplace 변경사항이 생기면, 대응하는 k8s Object에만 영향을 준다.
  • 불필요하게 하위 인프라 (VM 등)에서 rollout 되는 것을 방지함.

하지만, usecase 중에서는 복잡한 것들이 있다.

• VM의 cpu나 memory scale up 요청이라던가
• scale down은 scale up과는 완전히 다른 영역.

얘네는 지금 cluster API에서 지원하지 않고 있음.

 

 

Q&A

Q. 대규모 클러스터 운영하는 상황에서 cluster API로 Migration을 위한 path가 있는지?

• control plane 같은 중요한 것부터 순차적으로 옮기고, 기존 클러스터의 컴포넌트를 scale down하는 식으로.
• 2.5년 정도 전? kubeCon에서 openstack Provider로 migration한 사례가 있었던걸로 기억함