whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #35115 from bconfiden2/220716_Update_outdated_dev-1.24-ko.2_M65-M70

Browse Source 
[ko] Update outdated files in dev-1.24-ko.2 (M65-M70)
This commit is contained in:
Kubernetes Prow Robot
2022-07-25 22:55:53 -07:00
committed by GitHub
parent 6285db24bc 578c2e815d
commit f4959d31d9
6 changed files with 262 additions and 202 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/setup/_index.md
+9 -1
View File
@@ -27,6 +27,13 @@ card:
[쿠버네티스를 다운로드](/releases/download/)하여
로컬 머신에, 클라우드에, 데이터센터에 쿠버네티스 클러스터를 구축할 수 있다.
`kube-apiserver`나 `kube-proxy`와 같은 몇몇 [쿠버네티스 컴포넌트](/releases/download/)들은
클러스터 내에서 [컨테이너 이미지](/releases/download/#container-images)를 통해 배포할 수 있다.
쿠버네티스 컴포넌트들은 가급적 컨테이너 이미지로 실행하는 것을 **추천**하며,
이를 통해 쿠버네티스가 해당 컴포넌트들을 관리하도록 한다.
컨테이너를 구동하는 컴포넌트(특히 kubelet)는 여기에 속하지 않는다.
쿠버네티스 클러스터를 직접 관리하고 싶지 않다면, [인증된 플랫폼](/ko/docs/setup/production-environment/turnkey-solutions/)과
같은 매니지드 서비스를 선택할 수도 있다.
광범위한 클라우드 또는 베어 메탈 환경에 걸쳐 사용할 수 있는
@@ -60,4 +67,5 @@ card:
쿠버네티스의 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}}은
리눅스에서 실행되도록 설계되었다. 클러스터 내에서는 리눅스 또는
다른 운영 체제(예: 윈도우)에서 애플리케이션을 실행할 수 있다.
- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/setup/production-environment/windows/)를 살펴본다.
- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/concepts/windows/)를 살펴본다.
content/ko/docs/setup/best-practices/certificates.md
+1 -1
View File
@@ -23,7 +23,7 @@ weight: 40
* kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서
* API 서버가 kubelet과 통신하기 위한
kubelet [서버 인증서](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client-and-serving-certificates)
kubelet [서버 인증서](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates)
* API 서버 엔드포인트를 위한 서버 인증서
* API 서버에 클러스터 관리자 인증을 위한 클라이언트 인증서
* API 서버에서 kubelet과 통신을 위한 클라이언트 인증서
content/ko/docs/setup/production-environment/_index.md
+156 -141
View File
@@ -28,29 +28,29 @@ no_list: true
다음 이슈에 의해 어떻게 영향을 받는지 고려해야 한다.
- *가용성*: 단일 머신 쿠버네티스 [학습 환경](/ko/docs/setup/#학습-환경)은 SPOF(Single Point of Failure, 단일 장애 지점) 이슈를 갖고 있다.
고가용성 클러스터를 만드는 것에는 다음과 같은 고려 사항이 있다.
고가용성 클러스터를 만드는 것에는 다음과 같은 고려 사항이 있다.
- 컨트롤 플레인과 워크 노드를 분리
- 컨트롤 플레인 구성요소를 여러 노드에 복제
- 클러스터의 {{< glossary_tooltip term_id="kube-apiserver" text="API 서버" >}}로 가는 트래픽을 로드밸런싱
- 워커 노드를 충분히 운영하거나, 워크로드 변경에 따라 빠르게 제공할 수 있도록 보장
- *스케일링*: 프로덕션 쿠버네티스 환경에 들어오는 요청의 양의
일정할 것으로 예상된다면, 필요한 만큼의 용량(capacity)을 증설하고
마무리할 수도 있다. 하지만, 요청의 양이 시간에 따라 점점 증가하거나
계절, 이벤트 등에 의해 극적으로 변동할 것으로 예상된다면,
컨트롤 플레인과 워커 노드로의 요청 증가로 인한 압박을 해소하기 위해 스케일 업 하거나
잉여 자원을 줄이기 위해 스케일 다운 하는 것에 대해 고려해야 한다.
일정할 것으로 예상된다면, 필요한 만큼의 용량(capacity)을 증설하고
마무리할 수도 있다. 하지만, 요청의 양이 시간에 따라 점점 증가하거나
계절, 이벤트 등에 의해 극적으로 변동할 것으로 예상된다면,
컨트롤 플레인과 워커 노드로의 요청 증가로 인한 압박을 해소하기 위해 스케일 업 하거나
잉여 자원을 줄이기 위해 스케일 다운 하는 것에 대해 고려해야 한다.
- *보안 및 접근 관리*: 학습을 위한 쿠버네티스 클러스터에는
완전한 관리 권한을 가질 수 있다. 하지만 중요한 워크로드를 실행하며
두 명 이상의 사용자가 있는 공유 클러스터에는 누가, 그리고 무엇이 클러스터 자원에
접근할 수 있는지에 대해서 보다 정교한 접근 방식이 필요하다.
역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/)) 및
기타 보안 메커니즘을 사용하여, 사용자와 워크로드가 필요한 자원에
액세스할 수 있게 하면서도 워크로드와 클러스터를 안전하게 유지할 수 있다.
[정책](/ko/docs/concepts/policy/)과
[컨테이너 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)를
관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다.
완전한 관리 권한을 가질 수 있다. 하지만 중요한 워크로드를 실행하며
두 명 이상의 사용자가 있는 공유 클러스터에는 누가, 그리고 무엇이 클러스터 자원에
접근할 수 있는지에 대해서 보다 정교한 접근 방식이 필요하다.
역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/)) 및
기타 보안 메커니즘을 사용하여, 사용자와 워크로드가 필요한 자원에
액세스할 수 있게 하면서도 워크로드와 클러스터를 안전하게 유지할 수 있다.
[정책](/ko/docs/concepts/policy/)과
[컨테이너 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)를
관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다.
쿠버네티스 프로덕션 환경을 직접 구축하기 전에, 이 작업의 일부 또는 전체를
[턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/)
@@ -59,16 +59,16 @@ no_list: true
다음과 같은 옵션이 있다.
- *서버리스*: 클러스터를 전혀 관리하지 않고
타사 장비에서 워크로드를 실행하기만 하면 된다.
CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금이 부과된다.
타사 장비에서 워크로드를 실행하기만 하면 된다.
CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금이 부과된다.
- *관리형 컨트롤 플레인*: 쿠버네티스 서비스 공급자가
클러스터 컨트롤 플레인의 확장 및 가용성을 관리하고 패치 및 업그레이드를 처리하도록 한다.
클러스터 컨트롤 플레인의 확장 및 가용성을 관리하고 패치 및 업그레이드를 처리하도록 한다.
- *관리형 워커 노드*: 필요에 맞는 노드 풀을 정의하면,
쿠버네티스 서비스 공급자는 해당 노드의 가용성 및
필요 시 업그레이드 제공을 보장한다.
쿠버네티스 서비스 공급자는 해당 노드의 가용성 및
필요 시 업그레이드 제공을 보장한다.
- *통합*: 쿠버네티스를 스토리지, 컨테이너 레지스트리,
인증 방법 및 개발 도구와 같이
사용자가 필요로 하는 여러 서비스를 통합 제공하는 업체도 있다.
인증 방법 및 개발 도구와 같이
사용자가 필요로 하는 여러 서비스를 통합 제공하는 업체도 있다.
프로덕션 쿠버네티스 클러스터를 직접 구축하든 파트너와 협력하든,
요구 사항이 *컨트롤 플레인*, *워커 노드*,
@@ -99,52 +99,52 @@ CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금
다음 사항들을 고려한다.
- *배포 도구 선택*: kubeadm, kops, kubespray와 같은 도구를 이용해
컨트롤 플레인을 배포할 수 있다.
[배포 도구로 쿠버네티스 설치하기](/ko/docs/setup/production-environment/tools/)에서
여러 배포 도구를 이용한 프로덕션 수준 배포에 대한 팁을 확인한다.
배포 시, 다양한
[컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 사용할 수 있다.
컨트롤 플레인을 배포할 수 있다.
[배포 도구로 쿠버네티스 설치하기](/ko/docs/setup/production-environment/tools/)에서
여러 배포 도구를 이용한 프로덕션 수준 배포에 대한 팁을 확인한다.
배포 시, 다양한
[컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 사용할 수 있다.
- *인증서 관리*: 컨트롤 플레인 서비스 간의 보안 통신은 인증서를 사용하여 구현된다.
인증서는 배포 중에 자동으로 생성되거나, 또는 자체 인증 기관을 사용하여 생성할 수 있다.
[PKI 인증서 및 요구 조건](/ko/docs/setup/best-practices/certificates/)에서
상세 사항을 확인한다.
인증서는 배포 중에 자동으로 생성되거나, 또는 자체 인증 기관을 사용하여 생성할 수 있다.
[PKI 인증서 및 요구 조건](/ko/docs/setup/best-practices/certificates/)에서
상세 사항을 확인한다.
- *apiserver를 위한 로드밸런서 구성*: 여러 노드에서 실행되는 apiserver 서비스 인스턴스에
외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다.
[외부 로드밸런서 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)에서
상세 사항을 확인한다.
외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다.
[외부 로드밸런서 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)에서
상세 사항을 확인한다.
- *etcd 서비스 분리 및 백업*: etcd 서비스는
다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나,
또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다.
etcd는 클러스터 구성 데이터를 저장하므로
필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다.
[etcd FAQ](https://etcd.io/docs/v3.4/faq/)에서 etcd 구성 및 사용 상세를 확인한다.
[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와
[kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서
상세 사항을 확인한다.
다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나,
또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다.
etcd는 클러스터 구성 데이터를 저장하므로
필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다.
[etcd FAQ](https://etcd.io/docs/v3.4/faq/)에서 etcd 구성 및 사용 상세를 확인한다.
[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와
[kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서
상세 사항을 확인한다.
- *다중 컨트롤 플레인 시스템 구성*: 고가용성을 위해,
컨트롤 플레인은 단일 머신으로 제한되지 않아야 한다.
컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행되는 경우,
각 서비스는 최소 3대의 머신에서 실행되어야 한다.
그러나, 컨트롤 플레인 서비스를 쿠버네티스 상의 파드 형태로 실행하면
각 서비스 복제본 요청이 보장된다.
스케줄러는 내결함성이 있어야 하고, 고가용성은 필요하지 않다.
일부 배포 도구는 쿠버네티스 서비스의 리더 선출을 수행하기 위해
[Raft](https://raft.github.io/) 합의 알고리즘을 설정한다.
리더를 맡은 서비스가 사라지면 다른 서비스가 스스로 리더가 되어 인계를 받는다.
컨트롤 플레인은 단일 머신으로 제한되지 않아야 한다.
컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행되는 경우,
각 서비스는 최소 3대의 머신에서 실행되어야 한다.
그러나, 컨트롤 플레인 서비스를 쿠버네티스 상의 파드 형태로 실행하면
각 서비스 복제본 요청이 보장된다.
스케줄러는 내결함성이 있어야 하고, 고가용성은 필요하지 않다.
일부 배포 도구는 쿠버네티스 서비스의 리더 선출을 수행하기 위해
[Raft](https://raft.github.io/) 합의 알고리즘을 설정한다.
리더를 맡은 서비스가 사라지면 다른 서비스가 스스로 리더가 되어 인계를 받는다.
- *다중 영역(zone)으로 확장*: 클러스터를 항상 사용 가능한 상태로 유지하는 것이 중요하다면
여러 데이터 센터(클라우드 환경에서는 '영역'이라고 함)에서 실행되는
클러스터를 만드는 것이 좋다.
영역의 그룹을 지역(region)이라고 한다.
동일한 지역의 여러 영역에 클러스터를 분산하면
하나의 영역을 사용할 수 없게 된 경우에도 클러스터가 계속 작동할 가능성을 높일 수 있다.
[여러 영역에서 실행](/ko/docs/setup/best-practices/multiple-zones/)에서 상세 사항을 확인한다.
여러 데이터 센터(클라우드 환경에서는 '영역'이라고 함)에서 실행되는
클러스터를 만드는 것이 좋다.
영역의 그룹을 지역(region)이라고 한다.
동일한 지역의 여러 영역에 클러스터를 분산하면
하나의 영역을 사용할 수 없게 된 경우에도 클러스터가 계속 작동할 가능성을 높일 수 있다.
[여러 영역에서 실행](/ko/docs/setup/best-practices/multiple-zones/)에서 상세 사항을 확인한다.
- *구동 중인 기능 관리*: 클러스터를 계속 유지하려면,
상태 및 보안을 유지하기 위해 수행해야 하는 작업이 있다.
예를 들어 kubeadm으로 클러스터를 생성한 경우,
[인증서 관리](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)와
[kubeadm 클러스터 업그레이드하기](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)에 대해 도움이 되는 가이드가 있다.
[클러스터 운영하기](/ko/docs/tasks/administer-cluster/)에서
더 많은 쿠버네티스 관리 작업을 볼 수 있다.
상태 및 보안을 유지하기 위해 수행해야 하는 작업이 있다.
예를 들어 kubeadm으로 클러스터를 생성한 경우,
[인증서 관리](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)와
[kubeadm 클러스터 업그레이드하기](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)에 대해 도움이 되는 가이드가 있다.
[클러스터 운영하기](/ko/docs/tasks/administer-cluster/)에서
더 많은 쿠버네티스 관리 작업을 볼 수 있다.
컨트롤 플레인 서비스를 실행할 때 사용 가능한 옵션에 대해 보려면,
[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/),
@@ -166,39 +166,36 @@ etcd 백업 계획을 세우려면
워커 노드(간단히 *노드*라고도 함)를 어떤 방법으로 관리할지 고려해야 한다.
- *노드 구성하기*: 노드는 물리적 또는 가상 머신일 수 있다.
직접 노드를 만들고 관리하려면 지원되는 운영 체제를 설치한 다음
적절한 [노드 서비스](/ko/docs/concepts/overview/components/#노드-컴포넌트)를 추가하고 실행한다.
다음을 고려해야 한다.
직접 노드를 만들고 관리하려면 지원되는 운영 체제를 설치한 다음
적절한 [노드 서비스](/ko/docs/concepts/overview/components/#노드-컴포넌트)를 추가하고 실행한다.
다음을 고려해야 한다.
- 워크로드의 요구 사항 (노드가 적절한 메모리, CPU, 디스크 속도, 저장 용량을 갖도록 구성)
- 일반적인 컴퓨터 시스템이면 되는지, 아니면 GPU, 윈도우 노드, 또는 VM 격리를 필요로 하는 워크로드가 있는지
- *노드 검증하기*: [노드 구성 검증하기](/ko/docs/setup/best-practices/node-conformance/)에서
노드가 쿠버네티스 클러스터에 조인(join)에 필요한 요구 사항을
만족하는지 확인하는 방법을 알아본다.
노드가 쿠버네티스 클러스터에 조인(join)에 필요한 요구 사항을
만족하는지 확인하는 방법을 알아본다.
- *클러스터에 노드 추가하기*: 클러스터를 자체적으로 관리하는 경우,
머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나
또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다.
이러한 방식으로 노드를 추가하는 방법을 보려면 [노드](/ko/docs/concepts/architecture/nodes/) 섹션을 확인한다.
- *클러스터에 윈도우 노드 추가하기*: 윈도우 컨테이너로 구현된 워크로드를
실행할 수 있도록, 쿠버네티스는 윈도우 워커 노드를 지원한다.
[쿠버네티스에서의 윈도우](/ko/docs/setup/production-environment/windows/)에서 상세 사항을 확인한다.
머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나
또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다.
이러한 방식으로 노드를 추가하는 방법을 보려면 [노드](/ko/docs/concepts/architecture/nodes/) 섹션을 확인한다.
- *노드 스케일링*: 클러스터가 최종적으로 필요로 하게 될 용량만큼
확장하는 것에 대한 계획이 있어야 한다.
실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면
[대형 클러스터에 대한 고려 사항](/ko/docs/setup/best-practices/cluster-large/)을 확인한다.
만약 노드를 직접 관리한다면, 직접 물리적 장비를 구입하고 설치해야 할 수도 있음을 의미한다.
확장하는 것에 대한 계획이 있어야 한다.
실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면
[대형 클러스터에 대한 고려 사항](/ko/docs/setup/best-practices/cluster-large/)을 확인한다.
만약 노드를 직접 관리한다면, 직접 물리적 장비를 구입하고 설치해야 할 수도 있음을 의미한다.
- *노드 자동 스케일링*: 대부분의 클라우드 공급자는
비정상 노드를 교체하거나 수요에 따라 노드 수를 늘리거나 줄일 수 있도록
[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)를 지원한다.
[자주 묻는 질문](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)에서
오토스케일러가 어떻게 동작하는지,
[배치](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) 섹션에서
각 클라우드 공급자별로 어떻게 구현했는지를 확인한다.
온프레미스의 경우, 필요에 따라 새 노드를 가동하도록
스크립트를 구성할 수 있는 가상화 플랫폼이 있다.
비정상 노드를 교체하거나 수요에 따라 노드 수를 늘리거나 줄일 수 있도록
[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)를 지원한다.
[자주 묻는 질문](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)에서
오토스케일러가 어떻게 동작하는지,
[배치](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) 섹션에서
각 클라우드 공급자별로 어떻게 구현했는지를 확인한다.
온프레미스의 경우, 필요에 따라 새 노드를 가동하도록
스크립트를 구성할 수 있는 가상화 플랫폼이 있다.
- *노드 헬스 체크 구성*: 중요한 워크로드의 경우,
해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다.
[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/)
데몬을 사용하면 노드가 정상인지 확인할 수 있다.
해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다.
[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/)
데몬을 사용하면 노드가 정상인지 확인할 수 있다.
## 프로덕션 사용자 관리
@@ -215,39 +212,51 @@ etcd 백업 계획을 세우려면
다음과 같은 전략을 선택해야 한다.
- *인증*: apiserver는 클라이언트 인증서, 전달자 토큰, 인증 프록시 또는
HTTP 기본 인증을 사용하여 사용자를 인증할 수 있다.
사용자는 인증 방법을 선택하여 사용할 수 있다.
apiserver는 또한 플러그인을 사용하여
LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다.
쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은
[인증](/docs/reference/access-authn-authz/authentication/)을 참조한다.
- *인가*: 일반 사용자 인가를 위해, RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서 사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를 확인할 수 있다.
- *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게 특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다. 특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다. 그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을 특정 사용자에게 연결할 수 있다.
- *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의 리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다. 정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류), 그리고 '대상(사용자 또는 그룹)', '리소스 속성', '비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다. 자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다.
HTTP 기본 인증을 사용하여 사용자를 인증할 수 있다.
사용자는 인증 방법을 선택하여 사용할 수 있다.
apiserver는 또한 플러그인을 사용하여
LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다.
쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은
[인증](/docs/reference/access-authn-authz/authentication/)을 참조한다.
- *인가*: 일반 사용자 인가를 위해,
RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서
사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를
확인할 수 있다.
- *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게
특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다.
특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다.
그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을
특정 사용자에게 연결할 수 있다.
- *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의
리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다.
정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류),
그리고 '대상(사용자 또는 그룹)', '리소스 속성',
'비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다.
자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다.
프로덕션 쿠버네티스 클러스터에 인증과 인가를 설정할 때, 다음의 사항을 고려해야 한다.
- *인가 모드 설정*: 쿠버네티스 API 서버([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때,
*`--authorization-mode`* 플래그를 사용하여 인증 모드를 설정해야 한다.
예를 들어, (*`/etc/kubernetes/manifests`*에 있는)
*`kube-adminserver.yaml`* 파일 안의 플래그를 `Node,RBAC`으로 설정할 수 있다.
이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다.
- *인가 모드 설정*: 쿠버네티스 API 서버
([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때,
*`--authorization-mode`* 플래그를 사용하여 인증 모드를 설정해야 한다.
예를 들어, *`kube-adminserver.yaml`* 파일(*`/etc/kubernetes/manifests`*에 있는) 안의 플래그를 `Node,RBAC`으로 설정할 수 있다.
이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다.
- *사용자 인증서와 롤 바인딩 생성(RBAC을 사용하는 경우)*: RBAC 인증을 사용하는 경우,
사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다.
그 뒤에 각 사용자에게 역할 및 ClusterRoles를 바인딩할 수 있다.
자세한 내용은
[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/)을 참조한다.
사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다.
그 뒤에 각 사용자에게 역할 및 ClusterRoles를 바인딩할 수 있다.
자세한 내용은
[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/)을 참조한다.
- *속성을 포함하는 정책 생성(ABAC을 사용하는 경우)*: ABAC 인증을 사용하는 경우,
속성의 집합으로 정책을 생성하여, 인증된 사용자 또는 그룹이
특정 리소스(예: 파드), 네임스페이스, 또는 apiGroup에 접근할 수 있도록 한다.
[예시](/docs/reference/access-authn-authz/abac/#examples)에서
더 많은 정보를 확인한다.
속성의 집합으로 정책을 생성하여, 인증된 사용자 또는 그룹이
특정 리소스(예: 파드), 네임스페이스, 또는 apiGroup에 접근할 수 있도록 한다.
[예시](/docs/reference/access-authn-authz/abac/#examples)에서
더 많은 정보를 확인한다.
- *어드미션 컨트롤러 도입 고려*:
[웹훅 토큰 인증](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)은
API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추가적인 방법이다.
웹훅 및 다른 인가 형식을 사용하려면 API 서버에
[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를
추가해야 한다.
[웹훅 토큰 인증](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)은
API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추가적인 방법이다.
웹훅 및 다른 인가 형식을 사용하려면 API 서버에
[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를
추가해야 한다.
## 워크로드에 자원 제한 걸기
@@ -256,38 +265,44 @@ API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추
워크로드의 요구 사항을 충족하도록 클러스터를 구성할 때 다음 항목을 고려한다.
- *네임스페이스 제한 설정*: 메모리, CPU와 같은 자원의 네임스페이스 별 쿼터를 설정한다.
[메모리, CPU 와 API 리소스 관리](/ko/docs/tasks/administer-cluster/manage-resources/)에서
상세 사항을 확인한다.
[계층적 네임스페이스](/blog/2020/08/14/introducing-hierarchical-namespaces/)를 설정하여
제한을 상속할 수도 있다.
[메모리, CPU 와 API 리소스 관리](/ko/docs/tasks/administer-cluster/manage-resources/)에서
상세 사항을 확인한다.
[계층적 네임스페이스](/blog/2020/08/14/introducing-hierarchical-namespaces/)를 설정하여
제한을 상속할 수도 있다.
- *DNS 요청에 대한 대비*: 워크로드가 대규모로 확장될 것으로 예상된다면,
DNS 서비스도 확장할 준비가 되어 있어야 한다.
[클러스터의 DNS 서비스 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다.
DNS 서비스도 확장할 준비가 되어 있어야 한다.
[클러스터의 DNS 서비스 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다.
- *추가적인 서비스 어카운트 생성*: 사용자 계정은 *클러스터*에서 사용자가 무엇을 할 수 있는지 결정하는 반면에,
서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다.
기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다.
[서비스 어카운트 관리하기](/ko/docs/reference/access-authn-authz/service-accounts-admin/)에서
새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다.
- 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다. [파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서 예시를 확인한다.
- 서비스 어카운트에 RBAC 권한을 할당한다. [서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서 상세 사항을 확인한다.
서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다.
기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다.
[서비스 어카운트 관리하기](/ko/docs/reference/access-authn-authz/service-accounts-admin/)에서
새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다.
- 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다.
[파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서
예시를 확인한다.
- 서비스 어카운트에 RBAC 권한을 할당한다.
[서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서
상세 사항을 확인한다.
## {{% heading "whatsnext" %}}
- 프로덕션 쿠버네티스를 직접 구축할지,
아니면 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 또는
[쿠버네티스 파트너](/ko/partners/)가 제공하는 서비스를 이용할지 결정한다.
아니면 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 또는
[쿠버네티스 파트너](/ko/partners/)가 제공하는 서비스를 이용할지 결정한다.
- 클러스터를 직접 구축한다면,
[인증서](/ko/docs/setup/best-practices/certificates/)를 어떻게 관리할지,
[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)와
[API 서버](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/)
등의 기능에 대한 고가용성을
어떻게 보장할지를 계획한다.
- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/), [Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중
하나를 선택한다.
[인증서](/ko/docs/setup/best-practices/certificates/)를 어떻게 관리할지,
[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)와
[API 서버](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/)
등의 기능에 대한 고가용성을
어떻게 보장할지를 계획한다.
- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/),
[kops](/ko/docs/setup/production-environment/tools/kops/),
[Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중
하나를 선택한다.
- [인증](/docs/reference/access-authn-authz/authentication/) 및
[인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여
사용자 관리 방법을 구성한다.
[인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여
사용자 관리 방법을 구성한다.
- [자원 제한](/ko/docs/tasks/administer-cluster/manage-resources/),
[DNS 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/),
[서비스 어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)를 설정하여
애플리케이션 워크로드의 실행에 대비한다.
[DNS 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/),
[서비스 어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)를 설정하여
애플리케이션 워크로드의 실행에 대비한다.
content/ko/docs/setup/production-environment/container-runtimes.md
+91 -34
View File
@@ -36,7 +36,7 @@ _dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접
더 이상 쿠버네티스에 포함되지 않는다(이 제거는
v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다).
이 제거가 어떻게 영향을 미치는지 알아보려면
[Dockershim 사용 중단이 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다.
[dockershim 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다.
dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면,
[dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다.
@@ -46,6 +46,41 @@ v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고
<!-- body -->
## 필수 요소들 설치 및 구성하기
다음 단계에서는 리눅스의 쿠버네티스 노드를 위한 일반적인 설정들을 적용한다.
만약 필요하지 않다고 생각한다면 몇몇 설정들은 넘어가도 무방하다.
더 자세한 정보는, [네트워크 플러그인 요구사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements)이나 각자 사용 중인 컨테이너 런타임에 해당하는 문서를 확인한다.
### IPv4를 포워딩하여 iptables가 브리지된 트래픽을 보게 하기
`lsmod | grep br_netfilter`를 실행하여 `br_netfilter` 모듈이 로드되었는지 확인한다.
명시적으로 로드하려면, `sudo modprobe br_netfilter`를 실행한다.
리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables`가 1로 설정되어 있는지 확인한다. 예를 들어,
```bash
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# 필요한 sysctl 파라미터를 설정하면, 재부팅 후에도 값이 유지된다.
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
# 재부팅하지 않고 sysctl 파라미터 적용하기
sudo sysctl --system
```
## cgroup 드라이버
@@ -132,45 +167,22 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된
{{% thirdparty-content %}}
### containerd
이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계를 간략하게 설명한다.
다음 명령을 사용하여 시스템에 containerd를 설치한다.
1. 필수 구성 요소를 설치 및 구성한다.
[containerd 시작하기](https://github.com/containerd/containerd/blob/main/docs/getting-started.md)의 지침에 따라, 유효한 환경 설정 파일(`config.toml`)을 생성한다.
(이 지침은 리눅스 노드에만 적용된다)
```shell
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# 필요한 sysctl 파라미터를 설정하면 재부팅 후에도 유지된다.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
# 재부팅하지 않고 sysctl 파라미터 적용
sudo sysctl --system
```
1. containerd를 설치한다.
[containerd 시작하기](https://github.com/containerd/containerd/blob/main/docs/getting-started.md)
문서를 확인하고,
유효한 환경 설정 파일(`config.toml`)을 작성하는 부분까지의
가이드를 따른다.
리눅스에서, 이 파일은 `/etc/containerd/config.toml`에 존재한다.
윈도우에서, 이 파일은 `C:\Program Files\containerd\config.toml`에 존재한다.
{{< tabs name="Finding your config.toml file" >}}
{{% tab name="Linux" %}}
`/etc/containerd/config.toml` 경로에서 파일을 찾을 수 있음.
{{% /tab %}}
{{< tab name="Windows" >}}
`C:\Program Files\containerd\config.toml` 경로에서 파일을 찾을 수 있음.
{{< /tab >}}
{{< /tabs >}}
리눅스에서, containerd를 위한 기본 CRI 소켓은 `/run/containerd/containerd.sock`이다.
윈도우에서, 기본 CRI 엔드포인트는 `npipe://./pipe/containerd-containerd`이다.
@@ -185,6 +197,14 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
```
{{< note >}}
만약 containerd를 패키지(RPM, `.deb` 등)를 통해 설치하였다면,
CRI integration 플러그인은 기본적으로 비활성화되어 있다.
쿠버네티스에서 containerd를 사용하기 위해서는 CRI support가 활성화되어 있어야 한다.
`cri`가 `/etc/containerd/config.toml` 파일 안에 있는 `disabled_plugins` 목록에 포함되지 않도록 주의하자.
만약 해당 파일을 변경하였다면, `containerd`를 다시 시작한다.
{{< /note >}}
이 변경 사항을 적용하려면, containerd를 재시작한다.
@@ -193,7 +213,19 @@ sudo systemctl restart containerd
```
kubeadm을 사용하는 경우,
[kubelet용 cgroup 드라이버](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#컨트롤-플레인-노드에서-kubelet이-사용하는-cgroup-드라이버-구성)를 수동으로 구성한다.
[kubelet용 cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver)를 수동으로 구성한다.
#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-containerd}
[containerd 설정](https://github.com/containerd/cri/blob/master/docs/config.md)에서
아래와 같이 샌드박스 이미지를 덮어쓸 수 있다.
```toml
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "k8s.gcr.io/pause:3.2"
```
설정 파일을 변경하는 경우 역시 `systemctl restart containerd`를 통해 `containerd`를 재시작해야 한다.
### CRI-O
@@ -221,6 +253,19 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로
CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-o}
[CRI-O 설정](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md)에서
아래와 같이 샌드박스 이미지를 덮어쓸 수 있다.
```toml
[crio.image]
pause_image="registry.k8s.io/pause:3.6"
```
이 옵션은 `systemctl reload crio` 혹은 `crio` 프로세스에 `SIGHUP`을 보내 변경사항을 적용하기 위한
live configuration reload 기능을 지원한다.
### 도커 엔진 {#docker}
{{< note >}}
@@ -237,6 +282,12 @@ CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
`cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다.
#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd}
`cri-dockerd` 어댑터는,
파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다.
해당 커맨드라인 인자는 `--pod-infra-container-image`이다.
### 미란티스 컨테이너 런타임 {#mcr}
[미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며
@@ -251,6 +302,12 @@ CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
CRI 소켓의 경로를 찾으려면
`cri-docker.socket`라는 이름의 systemd 유닛을 확인한다.
#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd-mcr}
`cri-dockerd` 어댑터는,
파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다.
해당 커맨드라인 인자는 `--pod-infra-container-image`이다.
## {{% heading "whatsnext" %}}
컨테이너 런타임과 더불어, 클러스터에는
content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+1 -22
View File
@@ -45,26 +45,6 @@ card:
네트워크 어댑터가 두 개 이상이고, 쿠버네티스 컴포넌트가 디폴트 라우트(default route)에서 도달할 수 없는
경우, 쿠버네티스 클러스터 주소가 적절한 어댑터를 통해 이동하도록 IP 경로를 추가하는 것이 좋다.
## iptables가 브리지된 트래픽을 보게 하기
`br_netfilter` 모듈이 로드되었는지 확인한다. `lsmod | grep br_netfilter` 를 실행하면 된다. 명시적으로 로드하려면 `sudo modprobe br_netfilter` 를 실행한다.
리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables` 가 1로 설정되어 있는지 확인해야 한다. 다음은 예시이다.
```bash
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system
```
자세한 내용은 [네트워크 플러그인 요구 사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#네트워크-플러그인-요구-사항) 페이지를 참고한다.
## 필수 포트 확인 {#check-required-ports}
[필수 포트들](/ko/docs/reference/ports-and-protocols/)은
쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야
@@ -74,7 +54,7 @@ sudo sysctl --system
nc 127.0.0.1 6443
```
사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도
사용자가 사용하는 파드 네트워크 플러그인은 특정 포트를 열어야 할 수도
있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한
플러그인 문서를 참고한다.
@@ -202,7 +182,6 @@ name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF
content/ko/docs/setup/production-environment/tools/kubespray.md
+4 -3
View File
@@ -6,7 +6,7 @@ weight: 30
<!-- overview -->
이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Packet(베어메탈), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal(전 Packet), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
@@ -46,7 +46,7 @@ Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은
* 아래 클라우드 제공 업체를 위한 [Terraform](https://www.terraform.io/) 스크립트:
* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
* [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
* [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
* [Equinix Metal](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/metal)
### (2/5) 인벤토리 파일 구성하기
@@ -93,7 +93,8 @@ Kubespray는 클러스터를 관리하기 위한 추가적인 플레이북, _sca
### 클러스터 스케일링하기
scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자. remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자.
scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자.
remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자.
### 클러스터 업그레이드 하기