클라우드 컨트롤러 매니저
클라우드 컨트롤러 매니저 (Cloud Controller Manager)
클라우드 인프라스트럭처 기술 덕분에 퍼블릭, 프라이빗, 하이브리드 클라우드에서 Kubernetes를 실행할 수 있어요. Kubernetes는 컴포넌트 간 강한 결합이 없는, 자동화되고 API 기반의 인프라스트럭처를 지향해요.
cloud-controller-manager는 클라우드 특화 제어 로직을 내장한 Kubernetes 컨트롤 플레인 컴포넌트예요. 클라우드 컨트롤러 매니저를 사용하면 클러스터를 클라우드 프로바이더의 API에 연결할 수 있고, 그 클라우드 플랫폼과 상호작용하는 컴포넌트를 클러스터와만 상호작용하는 컴포넌트에서 분리해요.
Kubernetes와 기반 클라우드 인프라스트럭처 사이의 상호운용 로직을 분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 프로바이더가 메인 Kubernetes 프로젝트와 다른 속도로 기능을 출시할 수 있게 해줘요.
cloud-controller-manager는 서로 다른 클라우드 프로바이더가 자기 플랫폼을 Kubernetes에 통합할 수 있게 하는 플러그인 메커니즘으로 구조화돼요.
출처: 문서
본문
설계 (Design)
클라우드 컨트롤러 매니저는 컨트롤 플레인에서 복제된 프로세스 묶음(보통 파드 안의 컨테이너)으로 실행돼요. 각 cloud-controller-manager는 단일 프로세스 안에서 여러 컨트롤러를 구현해요.
클라우드 컨트롤러 매니저 기능
클라우드 컨트롤러 매니저 안의 컨트롤러에는 다음이 있어요.
노드 컨트롤러 (Node controller)
노드 컨트롤러는 클라우드 인프라스트럭처에서 새 서버가 생성될 때 Node 객체를 업데이트하는 일을 담당해요. 노드 컨트롤러는 클라우드 프로바이더를 통해 테넌시(tenancy) 안에서 실행 중인 호스트에 대한 정보를 얻어요. 노드 컨트롤러는 다음 기능을 수행해요.
- 클라우드 프로바이더 API에서 얻은 해당 서버의 고유 식별자로 Node 객체 업데이트
- 노드가 배포된 리전과 가용한 리소스(CPU, 메모리 등) 같은 클라우드 특화 정보로 Node 객체에 어노테이션과 라벨 부여
- 노드의 호스트 이름과 네트워크 주소 얻기
- 노드의 상태 확인. 노드가 응답하지 않게 되면 이 컨트롤러는 클라우드 프로바이더의 API로 서버가 비활성화/삭제/종료되었는지 확인해요. 노드가 클라우드에서 삭제되었다면 컨트롤러는 Kubernetes 클러스터에서 해당 Node 객체를 삭제해요.
일부 클라우드 프로바이더 구현은 이를 노드 컨트롤러와 별도의 노드 수명주기(lifecycle) 컨트롤러로 나누기도 해요.
라우트 컨트롤러 (Route controller)
라우트 컨트롤러는 Kubernetes 클러스터의 서로 다른 노드에 있는 컨테이너들이 서로 통신할 수 있도록 클라우드에서 라우트를 적절히 구성하는 일을 담당해요.
클라우드 프로바이더에 따라 라우트 컨트롤러는 파드 네트워크용 IP 주소 블록을 할당하기도 해요.
서비스 컨트롤러 (Service controller)
서비스는 관리형 로드밸런서, IP 주소, 네트워크 패킷 필터링, 대상 상태 확인 같은 클라우드 인프라스트럭처 컴포넌트와 통합돼요. 서비스 컨트롤러는 클라우드 프로바이더의 API와 상호작용해, 이를 필요로 하는 Service 리소스를 선언하면 로드밸런서와 다른 인프라스트럭처 컴포넌트를 구성해요.
권한 (Authorization)
이 섹션은 cloud controller manager가 그 작업을 수행하기 위해 다양한 API 객체에 요구하는 접근 권한을 정리해요.
노드 컨트롤러
노드 컨트롤러는 Node 객체와만 작업해요. Node 객체에 대한 읽기·수정 권한 전체가 필요해요.
v1/Node:
- get
- list
- create
- update
- patch
- watch
- delete
라우트 컨트롤러
라우트 컨트롤러는 Node 객체 생성을 수신하고 라우트를 적절히 구성해요. Node 객체에 대한 Get 권한이 필요해요.
v1/Node:
- get
서비스 컨트롤러
서비스 컨트롤러는 Service 객체의 create, update, delete 이벤트를 감시하고 그 서비스들에 대해 로드밸런서를 적절히 구성해요.
Services에 접근하려면 list, watch 권한이, Services를 업데이트하려면 status 하위 리소스에 대한 patch, update 권한이 필요해요.
v1/Service:
- list
- get
- watch
- patch
- update
기타 (Others)
cloud controller manager 핵심 구현은 Event 객체 생성 권한이 필요하고, 안전한 운영을 보장하기 위해 ServiceAccount 생성 권한이 필요해요.
v1/Event:
- create
- patch
- update
v1/ServiceAccount:
- create
cloud controller manager용 RBAC ClusterRole은 다음과 같아요:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cloud-controller-manager
rules:
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- update
- apiGroups:
- ""
resources:
- nodes
verbs:
- '*'
- apiGroups:
- ""
resources:
- nodes/status
verbs:
- patch
- apiGroups:
- ""
resources:
- services
verbs:
- list
- watch
- apiGroups:
- ""
resources:
- services/status
verbs:
- patch
- update
- apiGroups:
- ""
resources:
- serviceaccounts
verbs:
- create
- apiGroups:
- ""
resources:
- persistentvolumes
verbs:
- get
- list
- update
- watch
다음 단계
- Cloud Controller Manager 관리 문서에 cloud controller manager 실행·관리 방법이 있어요.
- HA 컨트롤 플레인을 cloud controller manager를 사용하도록 업그레이드하려면 복제 컨트롤 플레인을 cloud controller manager 사용으로 마이그레이션 문서를 참고해요.
- 나만의 cloud controller manager를 구현하거나 기존 프로젝트를 확장하려면? cloud controller manager는 Go 인터페이스, 특히 cloud.go에 정의된
CloudProvider인터페이스를 사용해 어떤 클라우드든 구현을 플러그인으로 끼울 수 있게 해요. 이 문서에서 강조한 공유 컨트롤러(Node, Route, Service)의 구현과 공유 cloudprovider 인터페이스를 포함한 일부 스캐폴딩은 Kubernetes 코어의 일부예요. 클라우드 프로바이더 고유 구현은 Kubernetes 코어 밖에 있으며CloudProvider인터페이스를 구현해요. 플러그인 개발에 대한 자세한 내용은 Developing Cloud Controller Manager를 참고해요.