Third Korean l10n work for release 1.18
- Translate cluster-administration/networking.md in Korean - Fix issue with concepts/storage/volumes.md - Translate /concepts/configuration/pod-overhead in Korean - Update to Outdated files in the dev-1.18-ko.3 branch. - Translate concepts/configuration/configmap.md in Korean - Translate contribute/review/reviewing-prs/ in Korean - Translate concepts/configuration/pod-priority-preemption.md in Korean - Translate tasks/configure-pod-container/configure-volume-storage in Korean - Translate contribute/new-content/new-content/ in Korean - Translate concepts/architecture/control-plane-node-communication.md in Korean - Restore the deleted master-node-communication.md file - Translate concepts/cluster-administration/addons.md in Korean - Translate contribute/new-content/overview/ in Korean - Translate tasks/tools/install-kubectl.md in Korean - Translate concepts/configuration/manage-resources-containers.md in Korean - Translate tasks/administer-cluster/kubeadm/kubeadm-upgrade/ in Korean - add new words to Korean glossary and fix minor - Translate contribute/style/_index.md in Korean - Translate concepts/cloud-administration/cloud-providers.md in Korean - Translate contribute/review/for-approvers.md in Korean Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com> Co-authored-by: SangshikLee <neolss@gmail.com>
This commit is contained in:
Jerry Park
committed by
Claudia J.Kang
Claudia J.Kang
parent
c74ce882ec
commit
ca62e21766
@@ -1,20 +1,21 @@
|
||||
---
|
||||
title: 클라우트 컨트롤러 매니저 기반에 관한 개념
|
||||
title: 클라우드 컨트롤러 매니저
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
클라우드 컨트롤러 매니저(CCM) 개념(바이너리와 혼동하지 말 것)은 본래 클라우드 벤더에 특화된 코드와 쿠버네티스 코어가 상호 독립적으로 진화할 수 있도록 해주기 위해 생성되었다. 클라우드 컨트롤러 매니저는 쿠버네티스 컨트롤러 매니저, API 서버, 그리고 스케줄러와 같은 다른 마스터 컴포넌트와 함께 동작된다. 또한 쿠버네티스 위에서 동작하는 경우에는, 쿠버네티스 애드온으로서 구동된다.
|
||||
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
|
||||
|
||||
클라우드 컨트롤러 매니저의 디자인은 새로운 클라우드 제공사업자가 플러그인을 이용하여 쉽게 쿠버네티스와 함께 통합하도록 허용해 주는 플러그인 메커니즘을 토대로 한다. 쿠버네티스에 새로운 클라우드 제공사업자를 적응시키기 위한 그리고 기존 모델에서 새로운 CCM 모델로 클라우드 제공사업자들이 전환을 이루기 위한 준비된 계획들이 있다.
|
||||
클라우드 인프라스트럭쳐 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다.
|
||||
쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭쳐를
|
||||
신뢰한다.
|
||||
|
||||
이 문서는 클라우드 컨트롤러 매니저 이면상의 개념들을 논의하고 그것과 연관된 기능들에 대한 세부적인 사항들을 제시한다.
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="클라우드 컨트롤러 매니저는">}}
|
||||
|
||||
다음은 클라우드 컨트롤러 매니저가 존재하지 않는 형태의 쿠버네티스 클러스터 아키텍처이다.
|
||||
|
||||
|
||||
클라우드 컨트롤러 매니저는 다양한 클라우드 공급자가 자신의
|
||||
플랫폼에 쿠버네티스를 통합할 수 있도록 하는 플러그인 메커니즘을 사용해서 구성된다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -23,91 +24,69 @@ weight: 40
|
||||
|
||||
## 디자인
|
||||
|
||||
이전 다이어그램에서, 쿠버네티스와 클라우드 제공사업자는 여러 상이한 컴포넌트들을 통해 통합되었다.
|
||||
|
||||
|
||||
* Kubelet
|
||||
* 쿠버네티스 컨트롤러 매니저
|
||||
* 쿠버네티스 API 서버
|
||||
|
||||
CCM은 앞의 세 컴포넌트가 가진 클라우드 의존적인 로직을 한 곳에 모아서 클라우드 통합을 위한 단일 포인트를 만들었다. CCM을 활용한 새로운 아키텍처는 다음과 같다.
|
||||
|
||||
|
||||
|
||||
## CCM의 컴포넌트
|
||||
|
||||
CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시키고 분리된 프로세스로서 그것을 작동시킨다. 특히, 클라우드 종속적인 KCM 내 컨트롤러들을 독립시킨다. KCM은 다음과 같은 클라우드 종속적인 컨트롤러 루프를 가진다.
|
||||
|
||||
* 노드 컨트롤러
|
||||
* 볼륨 컨트롤러
|
||||
* 라우트 컨트롤러
|
||||
* 서비스 컨트롤러
|
||||
|
||||
버전 1.9 에서, CCM은 이전 리스트로부터 다음의 컨트롤러를 작동시킨다.
|
||||
|
||||
* 노드 컨트롤러
|
||||
* 라우트 컨트롤러
|
||||
* 서비스 컨트롤러
|
||||
클라우드 컨트롤러 매니저는 컨트롤 플레인에서 복제된 프로세스의 집합으로 실행된다(일반적으로,
|
||||
파드의 컨테이너). 각 클라우드 컨트롤러 매니저는 단일
|
||||
프로세스에 여러 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를
|
||||
구현한다.
|
||||
|
||||
{{< note >}}
|
||||
볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다.
|
||||
또한 사용자는 클라우드 컨트롤러 매니저를 컨트롤 플레인의 일부가 아닌 쿠버네티스
|
||||
{{< glossary_tooltip text="애드온" term_id="addons" >}}으로
|
||||
실행할 수도 있다.
|
||||
{{< /note >}}
|
||||
|
||||
CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 [Flex](/ko/docs/concepts/storage/volumes/#flexVolume) 볼륨을 사용하기 위한 것이었다. 그러나, [CSI](/ko/docs/concepts/storage/volumes/#csi)라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
|
||||
## 클라우드 컨트롤러 매니저의 기능 {#functions-of-the-ccm}
|
||||
|
||||
이러한 역동성을 고려하여, CSI가 준비될 때까지 차이점에 대한 측정은 도중에 중지하기로 결정하였다.
|
||||
|
||||
## CCM의 기능
|
||||
|
||||
CCM은 클라우드 제공사업자에 종속적인 쿠버네티스 컴포넌트로부터 그 속성을 상속받는다. 이번 섹션은 그러한 컴포넌트를 근거로 구성되었다.
|
||||
|
||||
### 1. 쿠버네티스 컨트롤러 매니저
|
||||
|
||||
CCM의 주요 기능은 KCM으로부터 파생된다. 이전 섹션에서 언급한 바와 같이, CCM은 다음의 컨트롤러 루프를 작동시킨다.
|
||||
|
||||
* 노드 컨트롤러
|
||||
* 라우트 컨트롤러
|
||||
* 서비스 컨트롤러
|
||||
|
||||
#### 노드 컨트롤러
|
||||
|
||||
노드 컨트롤러는 클라우드 제공사업자의 클러스터에서 동작중인 노드에 대한 정보를 얻음으로써 노드를 초기화할 책임을 가진다. 노드 컨트롤러는 다음 기능을 수행한다.
|
||||
|
||||
1. 클라우드 특유의 영역/지역 레이블을 이용한 노드를 초기화한다.
|
||||
2. 클라우드 특유의 인스턴스 세부사항, 예를 들어, 타입 그리고 크기 등을 이용한 노드를 초기화한다.
|
||||
3. 노드의 네트워크 주소와 호스트네임을 취득한다.
|
||||
4. 노드가 무응답일 경우, 클라우드로부터 해당 노드가 삭제된 것인지 확인한다. 클라우드로부터 삭제된 것이라면, 쿠버네티스 노드 오브젝트를 삭제한다.
|
||||
|
||||
#### 라우트 컨트롤러
|
||||
|
||||
라우트 컨트롤러는 클라우드에서 적합하게 경로를 구성하는 책임을 가지며 쿠버네티스 클러스터 내 상이한 노드 상의 컨테이너들이 상호 소통할 수 있도록 해준다. 라우트 컨트롤러는 오직 Google Compute Engine 클러스터에서만 적용가능 하다.
|
||||
|
||||
#### 서비스 컨트롤러
|
||||
|
||||
서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB, Google LB, Oracle Cloud Infrastrucuture LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다.
|
||||
|
||||
### 2. Kubelet
|
||||
|
||||
노드 컨트롤러는 kubelet의 클라우드 종속적인 기능을 포함한다. CCM이 도입되기 이전에는, kubelet 이 IP 주소, 지역/영역 레이블 그리고 인스턴스 타입 정보와 같은 클라우드 특유의 세부사항으로 노드를 초기화하는 책임을 가졌다. CCM의 도입으로 kubelet에서 CCM으로 이 초기화 작업이 이전되었다.
|
||||
|
||||
이 새로운 모델에서, kubelet은 클라우드 특유의 정보 없이 노드를 초기화 해준다. 그러나, kubelet은 새로 생성된 노드에 taint를 추가해서 CCM이 클라우드에 대한 정보를 가지고 노드를 초기화하기 전까지는 스케줄되지 않도록 한다. 그러고 나서 이 taint를 제거한다.
|
||||
|
||||
## 플러그인 메커니즘
|
||||
|
||||
클라우드 컨트롤러 매니저는 어떠한 클라우드에서든지 플러그 인 되어 구현될 수 있도록 Go 인터페이스를 이용한다. 구체적으로, [여기](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)에 정의된 CloudProvider 인터페이스를 이용한다.
|
||||
|
||||
위에서 강조되었던 4개의 공유 컨트롤러의 구현, 그리고 공유 cloudprovider 인터페이스와 더불어 일부 골격은 쿠버네티스 코어 내에 유지될 것이다. 클라우드 제공사업자 특유의 구현은 코어의 외부에 탑재되어 코어 내에 정의된 인터페이스를 구현할 것이다.
|
||||
|
||||
개발 중인 플러그인에 대한 보다 자세한 정보는, [클라우드 컨트롤러 매니저 개발하기](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)를 참고한다.
|
||||
|
||||
## 인가
|
||||
|
||||
이 섹션은 CCM에 의해 작업을 수행하기 위해 다양한 API 오브젝트에서 요구되는 접근에 대해 구분해 본다.
|
||||
클라우드 컨틀롤러 매니저의 내부 컨트롤러에는 다음 컨트롤러들이 포함된다.
|
||||
|
||||
### 노드 컨트롤러
|
||||
|
||||
노드 컨트롤러는 오직 노드 오브젝트와 동작한다. 노드 오브젝트를 get, list, create, update, patch, watch, 그리고 delete 하기 위한 모든 접근을 요한다.
|
||||
노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 {{< glossary_tooltip text="노드" term_id="node" >}}
|
||||
오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자
|
||||
테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다.
|
||||
|
||||
v1/Node:
|
||||
1. 컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다.
|
||||
2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를
|
||||
사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다.
|
||||
3. 노드의 호스트 이름과 네트워크 주소를 가져온다.
|
||||
4. 노드의 상태를 확인한다. 노드가 응답하지 않는 경우, 이 컨트롤러는 사용자가
|
||||
이용하는 클라우드 공급자의 API를 통해 서버가 비활성화됨 / 삭제됨 / 종료됨인지 확인한다.
|
||||
노드가 클라우드에서 삭제된 경우, 컨트롤러는 사용자의 쿠버네티스 클러스터에서 노드
|
||||
오브젝트를 삭제한다.
|
||||
|
||||
일부 클라우드 공급자의 구현에서는 이를 노드 컨트롤러와 별도의 노드
|
||||
라이프사이클 컨트롤러로 분리한다.
|
||||
|
||||
### 라우트 컨트롤러
|
||||
|
||||
라우트 컨트롤러는 사용자의 쿠버네티스 클러스터의 다른 노드에
|
||||
있는 각각의 컨테이너가 서로 통신할 수 있도록 클라우드에서
|
||||
라우트를 적절히 구성해야 한다.
|
||||
|
||||
클라우드 공급자에 따라 라우트 컨트롤러는 파드 네트워크
|
||||
IP 주소 블록을 할당할 수도 있다.
|
||||
|
||||
### 서비스 컨트롤러
|
||||
|
||||
{{< glossary_tooltip text="서비스" term_id="service" >}} 는 관리형 로드 밸런서,
|
||||
IP 주소, 네트워크 패킷 필터링 그리고 대상 상태 확인과 같은
|
||||
클라우드 인프라스트럭처 컴포넌트와 통합된다. 서비스 컨트롤러는 사용자의 클라우드
|
||||
공급자 API와 상호 작용해서 필요한 서비스 리소스를 선언할 때
|
||||
로드 밸런서와 기타 인프라스트럭처 컴포넌트를 설정한다.
|
||||
|
||||
## 인가
|
||||
|
||||
이 섹션에서는 클라우드 컨트롤러 매니저가 작업을 수행하기 위해
|
||||
다양한 API 오브젝트에 필요한 접근 권한을 세분화한다.
|
||||
|
||||
### 노드 컨트롤러 {#authorization-node-controller}
|
||||
|
||||
노드 컨트롤러는 노드 오브젝트에서만 작동한다. 노드 오브젝트를 읽고,
|
||||
수정하려면 전체 접근 권한이 필요하다.
|
||||
|
||||
`v1/Node`:
|
||||
|
||||
- Get
|
||||
- List
|
||||
@@ -117,23 +96,24 @@ v1/Node:
|
||||
- Watch
|
||||
- Delete
|
||||
|
||||
### 라우트 컨트롤러
|
||||
### 라우트 컨트롤러 {#authorization-route-controller}
|
||||
|
||||
라우트 컨트롤러는 노드 오브젝트 생성에 대해 귀기울이고 적절하게 라우트를 구성한다. 노드 오브젝트에 대한 get 접근을 요한다.
|
||||
라우트 컨트롤러가 노드 오브젝트의 생성을 수신하고 적절하게
|
||||
라우트를 구성한다. 노드 오브젝트에 대한 접근 권한이 필요하다.
|
||||
|
||||
v1/Node:
|
||||
`v1/Node`:
|
||||
|
||||
- Get
|
||||
|
||||
### 서비스 컨트롤러
|
||||
### 서비스 컨트롤러 {#authorization-service-controller}
|
||||
|
||||
서비스 컨트롤러는 서비스 오브젝트 create, update 그리고 delete에 대해 귀기울이고, 서비스를 위해 적절하게 엔드포인트를 구성한다.
|
||||
서비스 컨트롤러는 서비스 오브젝트 생성, 업데이트 그리고 삭제 이벤트를 수신한 다음 해당 서비스에 대한 엔드포인트를 적절하게 구성한다.
|
||||
|
||||
서비스에 접근하기 위해, list, 그리고 watch 접근을 요한다. 서비스 update를 위해 patch와 update 접근을 요한다.
|
||||
서비스에 접근하려면, 목록과 감시 접근 권한이 필요하다. 서비스를 업데이트하려면, 패치와 업데이트 접근 권한이 필요하다.
|
||||
|
||||
서비스에 대한 엔드포인트 설정을 위해, create, list, get, watch, 그리고 update를 하기위한 접근을 요한다.
|
||||
서비스에 대한 엔드포인트 리소스를 설정하려면 생성, 목록, 가져오기, 감시 그리고 업데이트에 대한 접근 권한이 필요하다.
|
||||
|
||||
v1/Service:
|
||||
`v1/Service`:
|
||||
|
||||
- List
|
||||
- Get
|
||||
@@ -141,21 +121,22 @@ v1/Service:
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
### 그 외의 것들
|
||||
### 그 외의 것들 {#authorization-miscellaneous}
|
||||
|
||||
CCM의 코어에 대한 구현은 이벤트를 create 하고, 보안 작업을 보장하기 위한 접근을 요하며, ServiceAccount를 create 하기 위한 접근을 요한다.
|
||||
클라우드 컨트롤러 매니저의 핵심 구현을 위해 이벤트 오브젝트를 생성하고, 안전한 작동을 보장하기 위해 서비스어카운트(ServiceAccounts)를 생성해야 한다.
|
||||
|
||||
v1/Event:
|
||||
`v1/Event`:
|
||||
|
||||
- Create
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
v1/ServiceAccount:
|
||||
`v1/ServiceAccount`:
|
||||
|
||||
- Create
|
||||
|
||||
CCM에 대한 RBAC ClusterRole은 다음과 같다.
|
||||
클라우드 컨트롤러 매니저의 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}
|
||||
클러스터롤(ClusterRole)은 다음과 같다.
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
@@ -219,24 +200,16 @@ rules:
|
||||
- update
|
||||
```
|
||||
|
||||
## 벤더 구현사항
|
||||
|
||||
다음은 클라우드 제공사업자들이 구현한 CCM들이다.
|
||||
|
||||
* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)
|
||||
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
|
||||
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
|
||||
* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager)
|
||||
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
|
||||
* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)
|
||||
|
||||
## 클러스터 관리
|
||||
|
||||
CCM을 구성하고 작동하기 위한 전체 안내는 [여기](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)에서 제공된다.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
[클라우드 컨트롤러 매니저 관리](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)에는
|
||||
클라우드 컨트롤러 매니저의 실행과 관리에 대한 지침이 있다.
|
||||
|
||||
자체 클라우드 컨트롤러 매니저를 구현하거나 기존 프로젝트를 확장하는 방법을 알고 싶은가?
|
||||
|
||||
클라우드 컨트롤러 매니저는 Go 인터페이스를 사용해서 모든 클라우드 플러그인을 구현할 수 있다. 구체적으로, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)에 정의된 `CloudProvider` 인터페이스를 사용한다.
|
||||
|
||||
이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다.
|
||||
|
||||
플러그인 개발에 대한 자세한 내용은 [클라우드 컨트롤러 매니저 개발하기](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)를 참조한다.
|
||||
{{% /capture %}}
|
||||
|
||||
Reference in New Issue
Block a user