(Notice) Kubernetes Cluster API 프로젝트 진척상황

얼마전 CNCF 에서 아래와 같은 발표가 있었다. Kubernetes 프로젝트 일환인 Cluster API 프로젝트에서 곧 API를 운영환경에 릴리즈 할 계획이라는 발표였다. 현재 버전 1.0까지 완료된 상황이고...

 

발표링크

https://www.cncf.io/blog/2021/10/06/kubernetes-cluster-api-reaches-production-readiness-with-version-1-0/?fbclid=IwAR111peW7IH4GMcMJhiF5LI9vBzgK0UzMLP74C1DkuP2dhU8TYfcmHZYUkc

Kubernetes Cluster API reaches production readiness with version 1.0 | Cloud Native Computing Foundation

 

Kubernetes Cluster API 프로젝트가 어떤것인지 궁금해져 찾아보니 아래와 같았다.

 

Cluster API is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.

Started by the Kubernetes Special Interest Group (SIG) Cluster Lifecycle, the Cluster API project uses Kubernetes-style APIs and patterns to automate cluster lifecycle management for platform operators. The supporting infrastructure, like virtual machines, networks, load balancers, and VPCs, as well as the Kubernetes cluster configuration are all defined in the same way that application developers operate deploying and managing their workloads. This enables consistent and repeatable cluster deployments across a wide variety of infrastructure environments.

 

왜 이러한 프로젝트를 진행하게 되었나?

Why build Cluster API?

Kubernetes is a complex system that relies on several components being configured correctly to have a working cluster. Recognizing this as a potential stumbling block for users, the community focused on simplifying the bootstrapping process. Today, over 100 Kubernetes distributions and installers have been created, each with different default configurations for clusters and supported infrastructure providers. SIG Cluster Lifecycle saw a need for a single tool to address a set of common overlapping installation concerns and started kubeadm.

Kubeadm was designed as a focused tool for bootstrapping a best-practices Kubernetes cluster. The core tenet behind the kubeadm project was to create a tool that other installers can leverage and ultimately alleviate the amount of configuration that an individual installer needed to maintain. Since it began, kubeadm has become the underlying bootstrapping tool for several other applications, including Kubespray, Minikube, kind, etc.

However, while kubeadm and other bootstrap providers reduce installation complexity, they don’t address how to manage a cluster day-to-day or a Kubernetes environment long term. You are still faced with several questions when setting up a production environment, including:

• How can I consistently provision machines, load balancers, VPC, etc., across multiple infrastructure providers and locations? → 다양한 Iaas를 포용할수 있는 호환성을 위해
• How can I automate cluster lifecycle management, including things like upgrades and cluster deletion? → k8s 클러스터 라이프사이클을 자동화 하기 위해  → IaC와의 호환성을 이야기 하는 것 같음
• How can I scale these processes to manage any number of clusters? → 멀티 클러스터의 관리, 페더레이션까지 생각하는 것 같음

SIG Cluster Lifecycle began the Cluster API project as a way to address these gaps by building declarative, Kubernetes-style APIs, that automate cluster creation, configuration, and management. Using this model, Cluster API can also be extended to support any infrastructure provider (AWS, Azure, vSphere, etc.) or bootstrap provider (kubeadm is default) you need. See the growing list of available providers.

 

Goals

• To manage the lifecycle (create, scale, upgrade, destroy) of Kubernetes-conformant clusters using a declarative API.
• To work in different environments, both on-premises and in the cloud.
• To define common operations, provide a default implementation, and provide the ability to swap out implementations for alternative ones.
• To reuse and integrate existing ecosystem components rather than duplicating their functionality (e.g. node-problem-detector, cluster autoscaler, SIG-Multi-cluster).
• To provide a transition path for Kubernetes lifecycle products to adopt Cluster API incrementally. Specifically, existing cluster lifecycle management tools should be able to adopt Cluster API in a staged manner, over the course of multiple releases, or even adopting a subset of Cluster API.

Non-goals

• To add these APIs to Kubernetes core (kubernetes/kubernetes).
  • This API should live in a namespace outside the core and follow the best practices defined by api-reviewers, but is not subject to core-api constraints. → Kubernetes Core(KubeAPI를 말하는듯)이 아닌 클러스터 상위 계층에서 동작.
• To manage the lifecycle of infrastructure unrelated to the running of Kubernetes-conformant clusters. → 기존 Kubernetes Core 기반 Lifecycle 운영 환경들도 관리할 수 있도록 호환성을 가지고 있음
• To force all Kubernetes lifecycle products (kops, kubespray, GKE, AKS, EKS, IKS etc.) to support or use these APIs.
• To manage non-Cluster API provisioned Kubernetes-conformant clusters.
• To manage a single cluster spanning multiple infrastructure providers.
• To configure a machine at any time other than create or upgrade.
• To duplicate functionality that exists or is coming to other tooling, e.g., updating kubelet configuration (c.f. dynamic kubelet configuration), or updating apiserver, controller-manager, scheduler configuration (c.f. component-config effort) after the cluster is deployed.