복제된 컨트롤 플레인을 Cloud Controller Manager 사용으로 마이그레이션하기
복제된 컨트롤 플레인을 Cloud Controller Manager 사용으로 마이그레이션하기 (Migrate Replicated Control Plane To Use Cloud Controller Manager)
cloud-controller-manager는 클라우드 특정 제어 로직을 내장한 쿠버네티스 컨트롤 플레인 컴포넌트예요. cloud controller manager는 클러스터를 클라우드 제공업체의 API에 연결할 수 있게 하고, 그 클라우드 플랫폼과 상호작용하는 컴포넌트를 클러스터와만 상호작용하는 컴포넌트에서 분리해 줘요.
쿠버네티스와 기본 클라우드 인프라 사이의 상호운용성 로직을 분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 제공업체가 메인 쿠버네티스 프로젝트와 다른 속도로 기능을 릴리스할 수 있게 해 줘요.
출처: 문서
본문
배경 (Background)
클라우드 제공업체 추출 작업의 일환으로, 모든 클라우드 특정 컨트롤러는 kube-controller-manager에서 이동해야 해요. kube-controller-manager에서 클라우드 컨트롤러를 실행하는 모든 기존 클러스터는 대신 클라우드 제공업체 특정 cloud-controller-manager에서 컨트롤러를 실행하도록 마이그레이션해야 해요.
Leader Migration은 HA 클러스터가 복제된 컨트롤 플레인을 업그레이드하는 동안 두 컴포넌트 간의 공유 리소스 잠금을 통해 kube-controller-manager와 cloud-controller-manager 사이에서 "클라우드 특정" 컨트롤러를 안전하게 마이그레이션할 수 있는 메커니즘을 제공해요. 단일 노드 컨트롤 플레인의 경우, 또는 업그레이드 중 컨트롤러 매니저의 사용 불가를 허용할 수 있다면 Leader Migration은 필요하지 않으며 이 가이드를 무시해도 돼요.
Leader Migration은 kube-controller-manager 또는 cloud-controller-manager에 --enable-leader-migration을 설정해 활성화할 수 있어요. Leader Migration은 업그레이드 중에만 적용되며, 업그레이드 완료 후 안전하게 비활성화하거나 켜둘 수 있어요.
이 가이드는 내장 클라우드 제공업체가 있는 kube-controller-manager에서 kube-controller-manager와 cloud-controller-manager를 모두 실행하는 것으로 컨트롤 플레인을 업그레이드하는 수동 과정을 안내해요. 클러스터를 배포하고 관리하는 도구를 사용한다면 마이그레이션에 대한 특정 지침은 해당 도구와 클라우드 제공업체의 문서를 참고하세요.
시작하기 전에 (Before you begin)
컨트롤 플레인이 쿠버네티스 버전 N을 실행 중이고 N + 1로 업그레이드할 것이라고 가정해요. 같은 버전 내에서 마이그레이션하는 것도 가능하지만, 이상적으로는 구성 변경이 각 릴리스에 맞춰질 수 있도록 업그레이드의 일부로 마이그레이션을 수행해야 해요. N과 N + 1의 정확한 버전은 각 클라우드 제공업체에 따라 달라요. 예를 들어 클라우드 제공업체가 Kubernetes 1.24와 작동하는 cloud-controller-manager를 만든다면, N은 1.23이고 N + 1은 1.24가 될 수 있어요.
컨트롤 플레인 노드는 기본값인 Leader Election이 활성화된 kube-controller-manager를 실행해야 해요. N 버전 기준으로 in-tree 클라우드 제공업체가 --cloud-provider 플래그로 설정되어야 하고 cloud-controller-manager는 아직 배포되지 않아야 해요.
out-of-tree 클라우드 제공업체는 Leader Migration 구현이 있는 cloud-controller-manager를 만들어야 해요. 클라우드 제공업체가 v0.21.0 이상 버전의 k8s.io/cloud-provider와 k8s.io/controller-manager를 임포트하면 Leader Migration을 사용할 수 있어요. 하지만 v0.22.0 이전 버전에서는 Leader Migration이 알파이며 cloud-controller-manager에서 ControllerManagerLeaderMigration 기능 게이트를 활성화해야 해요.
이 가이드는 각 컨트롤 플레인 노드의 kubelet이 매니페스트로 정의된 정적 파드로 kube-controller-manager와 cloud-controller-manager를 시작한다고 가정해요. 컴포넌트가 다른 설정으로 실행된다면 단계를 그에 맞게 조정하세요.
인가를 위해 이 가이드는 클러스터가 RBAC를 사용한다고 가정해요. 다른 인가 모드가 kube-controller-manager와 cloud-controller-manager 컴포넌트에 권한을 부여한다면, 해당 모드에 맞는 방식으로 필요한 접근을 부여하세요.
Migration Lease에 접근 부여하기 (Grant access to Migration Lease)
컨트롤러 매니저의 기본 권한은 자신의 기본 Lease에만 접근하는 것을 허용해요. 마이그레이션이 동작하려면 다른 Lease에 대한 접근이 필요해요.
system::leader-locking-kube-controller-manager 역할을 수정해 kube-controller-manager에 leases API의 전체 접근을 부여할 수 있어요. 이 작업 가이드는 마이그레이션 리스 이름이 cloud-provider-extraction-migration이라고 가정해요.
kubectl patch -n kube-system role 'system::leader-locking-kube-controller-manager' -p '{"rules": [ {"apiGroups":[ "coordination.k8s.io"], "resources": ["leases"], "resourceNames": ["cloud-provider-extraction-migration"], "verbs": ["create", "list", "get", "update"] } ]}' --type=merge
비슷하게 cloud-controller-manager에도 접근을 부여해야 해요. kube-controller-manager의 기본 권한은 자신의 기본 Lease에만 접근을 허용하지만, cloud-controller-manager는 다른 Lease에 대한 접근도 필요해요. cloud-controller-manager에 leases API의 전체 접근을 부여하려면 클라우드 제공업체의 RBAC 구성에 따라 적절한 ClusterRole/역할을 수정해 cloud-provider-extraction-migration 리스에 대한 create, list, get, update 동사를 추가해야 해요.
이후의 단계는 kube-controller-manager와 cloud-controller-manager 모두에서 리더 선출이 활성화된 상태로, 사용 여부에 따라 컨트롤러 구성을 변경해 가며 업그레이드를 수행하는 과정을 다뤄요.