Cluster API 프로젝트

Cluster API는 여러 Kubernetes 클러스터의 프로비저닝, 업그레이드 및 운영을 단순화하는 선언적 API 및 툴링을 제공하는 데 초점을 맞춘 Kubernetes 하위 프로젝트다.

Kubernetes Special Interest Group(SIG) Cluster Lifecycle에 의해 시작된 클러스터 API 프로젝트는 플랫폼 운영자의 클러스터 라이프사이클 관리를 자동화하기 위해 Kubernetes 스타일의 API와 패턴을 사용한다. 가상 시스템, 네트워크, 로드 밸런싱 장치 및 VPC와 같은 지원 인프라와 Kubernetes 클러스터 구성은 모두 애플리케이션 개발자가 워크로드를 배포하고 관리하는 방식으로 정의된다. 이를 통해 다양한 인프라 환경에서 일관되고 반복 가능한 클러스터를 구축할 수 있다.

클러스터 API를 빌드하는 이유

Kubernetes는 클러스터가 작동되도록 올바르게 구성되는 여러 구성 요소에 의존하는 복잡한 시스템이다. 이를 사용자의 잠재적인 걸림돌로 인식하면서 커뮤니티는 부트스트래핑 프로세스를 단순화하는 데 초점을 맞췄다. 현재 100개 이상의 Kubernets 배포 및 설치 프로그램이 생성되었으며 각각 클러스터 및 지원되는 인프라 공급자에 대한 기본 구성이 다르다. SIG Cluster Lifecycle은 공통적으로 겹치는 설치 문제를 해결하기 위해 단일 도구가 필요하다고 보고 Kubeadm을 시작했다.

Kubeadm은 Best Practice Kubernetes 클러스터를 부트스트래핑하는 데 중점을 둔 도구로 설계되었다. kubeadm 프로젝트의 핵심은 다른 설치 관리자가 활용할 수 있는 도구를 만들고 궁극적으로 개별 설치 관리자가 유지해야 하는 구성의 양을 줄이는 것이었다. 이 프로그램이 시작된 이후, kubeadm은 kubespray, Minukube, kind 등을 포함한 몇몇 다른 응용 프로그램의 기본 부트스트래핑 도구가 되었다.

그러나 kubeadm 및 기타 부트스트랩 공급자는 설치 복잡성을 줄이지만, 일상적인 클러스터 관리 방법이나 Kubernetes 환경을 장기적으로 관리하는 방법은 다루지 않는다. 프로덕션 환경을 설정할 때 다음과 같은 몇 가지 질문에 직면할 수 있다.

  • 여러 인프라 제공자 및 위치에서 시스템, 로드 밸런싱 장치, VPC 등을 일관되게 프로비저닝하려면 어떻게 해야 합니까?
  • 업그레이드 및 클러스터 삭제와 같은 클러스터 라이프사이클 관리를 자동화하는 방법은 무엇입니까?
  • 이러한 프로세스를 확장하여 원하는 수의 클러스터를 관리할 수 있는 방법은 무엇입니까?

SIG Cluster Lifecycle은 클러스터 생성, 구성 및 관리를 자동화하는 선언적 Kubernetes 스타일의 API를 구축하여 이러한 격차를 해소하기 위한 방법으로 클러스터 API 프로젝트를 시작했다. 이 모델을 사용하면 클러스터 API를 확장하여 필요한 모든 인프라 공급자(AWS, Azure, vSphere 등) 또는 부트스트랩 공급자(쿠베드가 기본값임)를 지원할 수도 있다. 사용 가능한 공급자의 증가 목록을 참조하기 바란다.

목표

  • 선언적 API를 사용하여 Kubernetes 호환 클러스터의 수명 주기(생성, 확장, 업그레이드, 파괴)를 관리한다.
  • 사내와 클라우드 모두에서 다양한 환경에서 작업한다.
  • 공통 작업을 정의하려면 기본 구현을 제공하고 대체 작업에 대해 구현을 스왑 아웃할 수 있는 기능을 제공한다.
  • 기능(예: 노드 문제 감지기, 클러스터 자동 확장기, SIG-멀티 클러스터)을 복제하지 않고 기존 에코시스템 구성요소를 재사용하고 통합한다.
  • 쿠버네티스 라이프사이클 제품이 Cluster API를 점진적으로 채택할 수 있는 전환 경로를 제공한다. 특히 기존 클러스터 라이프사이클 관리 툴은 여러 릴리스의 과정에서 단계적 방식으로 Cluster API를 채택하거나 심지어 Cluster API의 하위 집합을 채택할 수 있어야 한다.

비목표

  • API를 Kubernetes 코어(Kubernetes/Kubernetes)에 추가한다.
  • API는 코어 외부의 네임스페이스에 살아야 하며 api-reviewers에 의해 정의된 모범 사례를 따라야 하지만 코어-api 제약의 영향을 받지 않는다.
  • Kubernetes 호환 클러스터 실행과 관련 없는 인프라의 라이프사이클을 관리한다.
  • 모든 Kubernetes 라이프사이클 제품(kops, kubespray, GKE, AKS, EKS, IKS 등)이 이러한 API를 지원하거나 사용하도록 강제한다.
  • 비클러스터 API 프로비저닝된 Kubernetes 호환 클러스터를 관리한다.
  • 여러 인프라 공급자에 걸쳐 단일 클러스터를 관리한다.
  • 생성 또는 업그레이드 이외의 시간에 시스템을 구성한다.
  • 존재하는 기능 또는 다른 툴링(예: 동적 kubelet 구성)을 복제하거나 클러스터 배포 후 apiserver, controller-manager, 스케줄러 구성(c.f. component-config 작업)을 업데이트하는 기능

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

You May Also Like

1.4 MachineHealthCheck 구성

전제조건 MachinehealthCheck를 구성하기 전에 하나 이상의 MachineDeployment 또는 MachineSet가 배포된 작업 관리 클러스터가 있어야 한다. MachineHealthCheck란 무엇입니까? MachineHealthCheck는…

1.6 Machine Template 변경

인프라 Machine Template 변경 Cluster API의 여러 구성 요소는 KubeadmControlPlane, Machine Deployment 및 MachineSet을 비롯한 인프라 시스템 템플릿을…

1.7.2 ClusterResourceSet

실험 기능: ClusterResourceSet (알파) ClusterResourceSet 기능은 사용자가 정의한 리소스 세트(예: CNI/CSI)를 새로 생성된 클러스터와 일치시키는 데 자동으로 적용할…