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 %}}
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: 컨트롤 플레인-노드 간 통신
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
aliases:
|
||||
- master-node-communication
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 문서는 컨트롤 플레인(실제로는 API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 노드에서 컨트롤 플레인으로의 통신
|
||||
노드에서 컨트롤 플레인까지의 모든 통신 경로는 API 서버에서 종료된다(다른 마스터 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). 일반적인 배포에서 API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(443)에서 원격 연결을 수신하도록 구성된다.
|
||||
특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
|
||||
|
||||
노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
|
||||
|
||||
API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다.
|
||||
`kubernetes` 서비스(모든 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
|
||||
|
||||
컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다.
|
||||
|
||||
결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다.
|
||||
|
||||
## 컨트롤 플레인에서 노드로의 통신
|
||||
컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다.
|
||||
|
||||
### API 서버에서 kubelet으로의 통신
|
||||
API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
|
||||
|
||||
* 파드에 대한 로그를 가져온다.
|
||||
* 실행 중인 파드에 (kubectl을 통해) 연결한다.
|
||||
* kubelet의 포트-포워딩 기능을 제공한다.
|
||||
|
||||
이 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 서빙(serving) 인증서를 확인하지 않으므로, 연결이 중간자(man-in-the-middle) 공격의 대상이 되며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** .
|
||||
|
||||
이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여 API 서버에 kubelet의 서빙 인증서를 확인하는 데 사용할 루트 인증서 번들을 제공한다.
|
||||
|
||||
이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/control-plane-node-communication/#ssh-터널)을
|
||||
사용한다.
|
||||
|
||||
마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다.
|
||||
|
||||
### API 서버에서 노드, 파드 및 서비스로의 통신
|
||||
|
||||
API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않으므로 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
|
||||
|
||||
### SSH 터널
|
||||
|
||||
쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
|
||||
이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.
|
||||
|
||||
SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
|
||||
|
||||
### Konnectivity 서비스
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 연결을 유지한다.
|
||||
그런 다음 컨트롤 플레인에서 노드로의 모든 트래픽은 이 연결을 통과한다.
|
||||
|
||||
클러스터에서 설정하는 방법에 대해서는 [Konnectivity 서비스 설정](/docs/tasks/setup-konnectivity/)을 참조한다.
|
||||
@@ -52,7 +52,7 @@ weight: 30
|
||||
작업을 수행한 다음 중지하는
|
||||
쿠버네티스 리소스 이다.
|
||||
|
||||
(일단 [스케줄되면](/ko/docs/concepts/scheduling/), 파드 오브젝트는 kubelet
|
||||
(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet
|
||||
의 의도한 상태 중 일부가 된다.)
|
||||
|
||||
잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서
|
||||
|
||||
Reference in New Issue
Block a user