cloud controller manager
개요
쿠버네티스를 클라우드 환경에 구축할 때 관련한 서비스와 연동을 편리하게, 설정을 도와주는 컨트롤러들이 있다.
이것들은 쿠버네티스에 내장되어 있는데, 이 컨트롤러 묶음 파드가 바로 클라우드 컨트롤러 매니저이다.
기본적인 kube-controller-manager와 같이 컨트롤러들이 들어있는 형식인데, 그냥 각 클라우드 사에서 사용할 때 조금 특화된 기능을 제공해주는 역할을 한다.
동작 구조
별 게 있는 게 아니다.
그냥 컨트롤러 매니저 파드가 돌아가고 있는데, 설치된 클라우드 환경에 따라 각 클라우드에서 제공하는 api를 호출하여 사용하는 방식이다.
이 api를 호출해 정보를 가져오거나 필요한 명령을 내리는 식으로 동작한다.
컨트롤러 종류
그럼 어떤 컨트롤러들이 안 속에서 돌아가고 있을까?
노드 컨트롤러
클라우드 인프라에 구축된 노드들을 업데이트하는데 사용된다.
EKS도 그렇고, 각 클라우드들은 대체로 자동으로 노드를 스케일링하는 등의 작업을 수행해준다.
이때 이 정보들이 적합하게 클러스터에 반영되도록 도와주는 것이 바로 노드 컨트롤러이다.
구체적으로는 다음의 과정을 거친다고 한다.
- api에서 서버 식별자를 가져와 노드 오브젝트를 업데이트
- 리소스, 지역 등의 각종 정보를 라벨과 어노테이션으로 추가
- 노드의 호스트명과 네트워크 주소 확보
- 해당 노드 헬스체크 진행
- 노드가 정상적이지 않다면 클라우드 api로 해당 노드의 상태를 확인해본다.
- api로 노드가 지워진 것이 확인되면 이것을 클러스터에 반영한다.
닭과 달걀 문제
점차 벤더 종속성을 줄여나가는 기조에 따라, 조만간 이 매니저는 삭제될 예정이다(어쩌면 1.33).[1]
클러스터가 초기화될 때, 온프레미스 환경과 달리 클라우드 환경에서는 클라우드 컨트롤러 매니저가 노드의 업데이트를 담당한다.
온프레미스 환경에서 이뤄지는 동작은 이렇다.
- 마스터 노드의 kubelet이 시작된다.
- kube-apiserver를 동작시킨다.
- kubelet이 Node 오브젝트를 api 서버에 등록한다.
- 이제 api 서버는 노드의 상태를 클러스터에서 확인하고 관리할 수 있다!
그러나 위의 그림처럼, 클라우드 환경에서는 kubelet은 노드를 등록하자마자 node.cloudprovider.kubernets.io/uninitialized
테인트, 톨러레이션를 걸고 여타 필요한 기타 세팅을 하지 않는다.
(참고로 kubelet에 --cloud-provider=external
이란 인자를 주면 이렇게 동작한다.)
이러면 클라우드 컨트롤러 매니저가 본격적으로 작업을 진행하며 노드의 주소, 라벨, 리전 등 각종 벤더 종속적인 라벨과 설정을 진행한다.
이로 인해 일단 노드가 동작할 수 있도록 등록되는데 있어 한 홉이 생겨 지연이 발생한다.
또 여기에 더불어 클라우드 컨트롤러 매니저 역시 보통 컨테이너로서 동작하기에, 컨테이너를 띄우기 위한 노드를 초기화하는데 컨테이너가 띄워져 있어야 하는, 닭과 달걀의 문제가 발생하게 되는 것이다.
보통 클라우드사들은 정적 파드, 바이너리, 톨러레이션 등을 통해 이 이슈를 대응한다.
이렇게 대응한다고 하더라도 결국 의존성 문제는 남는다.
처음 걸린 테인트를 제거하는 것은 클컨매의 몫인데, 이걸 안 해버린다면?
거기에 노드는 cni 활성이 안 돼서 not ready 테인트까지 붙어있을 수도 있는데 이걸 톨러레이션 걸지 않는다면?
뭐.. 구태여 그런 상황까지 가정하냐 싶겠지만 이런 불필요한 수고로움이 발생한다는 것이 요지이다.
라우트 컨트롤러
클라우드에서 라우팅이 제대로 일어날 수 있도록 도와주는 컨트롤러.
서비스 컨트롤러
서비스 관련 컨트롤러로, 클라우드에 클러스터를 구축하는 것만으로도 로드밸런서를 쓸 수 있는데 이게 이 컨트롤러 덕분이다.
ip 주소 관리, 패킷 필터링, 헬스체크 등의 작업을 수행해준다고 한다.
근데 이게 재밌는 지점이 있는데, 이 놈은 정말 서비스만 관리한다.
하위의 엔드포인트슬라이스에 대해서는 관리를 하지도 않고 애초에 권한조차 가지고 있지 않다.
그래서 엔포슬에 대한 것은 서비스와 파드를 관찰하는 kube-controller-manager의 엔포슬 컨트롤러가 추적하고 관리한다.
매니저 권한
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
- patch
- update
- watch
- apiGroups:
- ""
resources:
- serviceaccounts
verbs:
- create
- apiGroups:
- ""
resources:
- persistentvolumes
verbs:
- get
- list
- update
- watch
- apiGroups:
- ""
resources:
- endpoints
verbs:
- create
- get
- list
- watch
- update
이 컨트롤러 매니저가 가지고 있는 RBAC에 대한 정보도 문서에 나와 있기에 올려본다.
그냥 위에 말했던 기능들과 관련된 권한만 가지고 있다.
관련 문서
이름 | noteType | created |
---|---|---|
cloud controller manager | knowledge | 2025-02-04 |