Cluster API는 쿠버네티스 클러스터 라이프사이클에 선언적 관리를 도입하여, 사용자와 플랫폼 팀이 클러스터의 원하는 상태를 정의하고, 컨트롤러가 지속적으로 해당 상태로 조정하도록 합니다.
쿠버네티스에서 StatefulSet이나 Deployment를 사용하여 Pod 그룹을 관리하는 것과 유사하게, Cluster API에서는 KubeadmControlPlane을 사용하여 컨트롤 플레인 머신 세트를 관리하거나, MachineDeployment를 사용하여 워커 노드 그룹을 관리할 수 있습니다.
Cluster API v1.12.0 릴리스는 인플레이스 업데이트와 연쇄 업그레이드를 도입함으로써 Cluster API에서 가능한 기능을 확장하고 일반적인 라이프사이클 작업의 마찰을 줄입니다.
단순성과 사용성에 대한 강조
v1.12.0을 통해 Cluster API 프로젝트는 커뮤니티가 Cluster API 사용자에게 미치는 영향을 최소화하면서도 엄청난 양의 혁신을 제공할 수 있음을 다시 한번 보여줍니다.
실제로 이것은 무엇을 의미할까요?
사용자는 이전 Cluster API 릴리스와 마찬가지로 Cluster 또는 Machine 사양을 변경하기만 하면, Cluster API는 가능하고 권장될 때 자동으로 인플레이스 업데이트 또는 연쇄 업그레이드를 트리거합니다.
인플레이스 업데이트
쿠버네티스가 Deployment의 Pod에 대해 그러하듯, Machine 사양이 변경되면 Cluster API도 새 Machine을 생성하고 이전 Machine을 삭제하여 롤아웃을 수행합니다.
불변 인프라(immutable infrastructure) 원칙에서 영감을 받은 이 접근 방식은 다음과 같은 상당한 이점을 가집니다:
- 사용자와 엔지니어에게 설명하기 쉽고, 예측 가능하며, 일관성 있고, 이해하기 쉽습니다.
- 생성 및 삭제라는 두 가지 핵심 기본 기능에만 의존하므로 구현이 간단합니다.
- 구현이 OS, 부트스트랩 메커니즘 등 Machine별 선택 사항에 의존하지 않습니다.
결과적으로, Machine 롤아웃은 노드를 호스팅하는 호스트 서버의 라이프사이클을 관리할 때 고려해야 할 변수의 수를 획기적으로 줄입니다.
그러나 불변성의 이점에는 이견이 없지만, 쿠버네티스와 Cluster API 모두 가능한 한 워크로드 중단을 최소화할 수 있도록 변경 사항을 도입하는 유사한 여정을 겪고 있습니다.
시간이 지남에 따라 Cluster API 또한 불변 롤아웃에 여러 개선 사항을 도입했으며, 다음을 포함합니다:
- 쿠버네티스 리소스에만 영향을 미치는 변경 사항의 인플레이스 전파(propagation) 지원을 통해 불필요한 롤아웃 방지
- 오래된 노드에 PreferNoSchedule 테인트를 적용하는 방법을 제공하여, 롤아웃 중 Pod가 재스케줄링되는 방식을 최적화함으로써 Pod 이탈(churn)을 줄임.
- 먼저 삭제(delete first) 롤아웃 전략 지원을 통해 베어 메탈 / 리소스 제약이 있는 환경에서 불변 롤아웃을 더 쉽게 수행할 수 있도록 함.
Cluster API의 새로운 인플레이스 업데이트 기능은 이 여정의 다음 단계입니다.
v1.12.0 릴리스와 함께 Cluster API는 업데이트 확장(update extensions)을 지원하여 사용자가 기존 Machine을 삭제하고 다시 생성하지 않고도 그 자리에서(in-place) 변경할 수 있도록 합니다.
KubeadmControlPlane과 MachineDeployment 모두 새로운 업데이트 확장을 기반으로 하는 인플레이스 업데이트를 지원하며, 이는 Cluster API에서 가능한 범위가 이제 상당한 방식으로 변경되었음을 의미합니다.
인플레이스 업데이트는 어떻게 작동할까요?
가장 간단하게 설명하자면, 사용자가 Machine의 원하는 상태를 변경하여 업데이트를 트리거하면, Cluster API는 원하는 상태를 달성하기 위한 최적의 도구를 선택합니다.
새로운 점은 이제 Cluster API가 필요한 변경 사항을 수행하기 위해 불변 롤아웃과 인플레이스 업데이트 확장 중에서 선택할 수 있다는 것입니다.
중요한 것은 이것이 불변 롤아웃 대 인플레이스 업데이트가 아니라는 점입니다. Cluster API는 둘 다 유효한 옵션으로 간주하며 주어진 변경에 가장 적합한 메커니즘을 선택합니다.
Cluster API 관리자의 관점에서 볼 때, 인플레이스 업데이트는 노드 드레인이나 Pod 재시작을 별도로 필요로 하지 않는 변경 사항, 예를 들어 Machine의 사용자 자격 증명 변경과 같은 경우에 가장 유용합니다. 반면에 워크로드가 어차피 중단될 경우에는 롤아웃을 수행하는 것이 좋습니다.
그럼에도 불구하고 Cluster API는 확장 가능한 본질에 충실하며, 누구나 자신만의 업데이트 확장을 생성하고 불변 롤아웃의 일부 이점을 감수하면서 인플레이스 업데이트를 언제 어떻게 사용할지 결정할 수 있습니다.
이 기능에 대한 심층적인 내용은 암스테르담 KubeCon EU에서 열리는 Cluster API를 통한 인플레이스 업데이트: 불변 인프라와 가변 인프라의 스위트 스폿 세션을 꼭 확인하세요!
연쇄 업그레이드
ClusterClass와 Cluster API의 관리형 토폴로지(managed topologies)는 Kubernetes-as-a-Service를 제공하는 많은 플랫폼을 위한 빌딩 블록 역할을 하는 강력하고 효과적인 프레임워크를 공동으로 제공했습니다.
이제 v1.12.0에서는 이 기능이 또 다른 중요한 진전을 이루며, 단일 작업으로 하나 이상의 쿠버네티스 마이너 버전을 업그레이드할 수 있도록 합니다. 이를 일반적으로 연쇄 업그레이드라고 합니다.
이를 통해 사용자는 대상 쿠버네티스 버전을 선언하고, Cluster API가 각 마이너 업그레이드를 수동으로 관리하는 대신 필요한 중간 단계를 안전하게 오케스트레이션하도록 할 수 있습니다.
연쇄 업그레이드가 작동하는 가장 간단한 방법은 사용자가 Cluster의 원하는 버전을 변경하여 업데이트를 트리거하면, Cluster API가 업그레이드 계획을 계산하고 이를 실행하기 시작한다는 것입니다. 예를 들어, Cluster를 v1.33.0으로 업데이트한 다음 v1.34.0, v1.35.0으로 각 단계에서 진행 상황을 확인하는 대신, 연쇄 업그레이드는 v1.35.0으로 직접 이동할 수 있도록 합니다.
업그레이드 계획을 실행한다는 것은 컨트롤 플레인 및 워커 머신을 엄격하게 통제된 순서로 업그레이드하는 것을 의미하며, 원하는 상태에 도달하는 데 필요한 만큼 이 과정을 반복합니다. Cluster API는 이제 이 모든 것을 사용자를 위해 관리할 수 있습니다.
Cluster API는 워커 머신에 대한 업그레이드 단계를 최적화하고 최소화하며, 실제로 워커 머신은 쿠버네티스 버전 스큐 정책(version skew policies)이 허용하는 한 중간 쿠버네티스 마이너 릴리스로의 업그레이드를 건너뛸 것입니다.
이 경우에도 확장성은 이 기능의 핵심이며, 업그레이드 계획 런타임 확장(runtime extensions)을 사용하여 업그레이드 계획이 계산되는 방식에 영향을 줄 수 있습니다. 마찬가지로, 라이프사이클 훅(lifecycle hooks)은 업그레이드 중에 수행해야 하는 다른 작업, 예를 들어 컨트롤 플레인 업데이트가 완료된 후 애드온(addon) 업그레이드와 같은 작업을 자동화하는 데 사용될 수 있습니다.
저희 관점에서 볼 때, 연쇄 업그레이드는 쿠버네티스 마이너 릴리스를 따라잡기 어려워하는 사용자에게 가장 유용합니다. 예를 들어, 일년에 한 번만 업그레이드하고 세 가지 버전(n-3 → n)을 한 번에 업그레이드하려는 경우입니다. 하지만 주의하세요: 이제 여러 마이너 버전을 쉽게 업그레이드할 수 있다는 사실이 클러스터를 자주 패치하지 않는 변명이 될 수는 없습니다!
릴리스 팀
모든 기여자, 관리자, 그리고 릴리스 팀에 자원해 주신 모든 엔지니어분들께 감사드립니다.
Cluster API 릴리스의 신뢰성과 예측 가능성은 사용자들로부터 가장 높이 평가받는 기능 중 하나이며, 이는 커뮤니티의 지원, 헌신 및 노고가 있어야만 가능합니다.
v1.12.0 릴리스와 2025년에 출시된 모든 훌륭한 릴리스를 위해 전체 Cluster API 커뮤니티에 찬사를 보냅니다! 참여에 관심이 있다면 Cluster API 기여 가이드라인을 알아보세요.
다음은 무엇인가요?
Cluster API 선언문(manifesto)을 읽어보면, Cluster API 서브프로젝트가 미완성으로 남을 권리를 주장하며, Cluster API 사용자 및 더 넓은 클라우드 네이티브 생태계의 변화하는 요구에 지속적으로 진화, 개선 및 적응해야 할 필요성을 인식하고 있음을 알 수 있습니다.
쿠버네티스 자체가 계속 진화함에 따라, Cluster API 서브프로젝트는 더 안전한 업그레이드, 중단 감소, 그리고 대규모로 쿠버네티스를 관리하는 플랫폼을 위한 더욱 강력한 빌딩 블록에 중점을 두며 함께 발전해 나갈 것입니다.
혁신은 Cluster API의 핵심에 남아있으며, 2026년에도 흥미로운 소식을 기대해주세요!
유용한 링크: