Seventh Korean l10n work for release 1.18
- Translate reference/command-line-tools-reference/feature-gates.md int… (#22240) - Fix issue of broken links to translated docs (#22105) - Fix issue of document link in some ko documents (#22379) - Translate tasks/administer-cluster/access-cluster-services.md into Ko… (#21776) - Fix issue with 'Linux' and 'Windows' notation in Korean docs (#22362) - Fix issue of broken links to translated docs #2 (#22270) - Fix issue with k8s.io/ko/docs/concepts/overview/kubernetes-api.md (#22261) - Fix issue with k8s.io/ko/docs/concepts/overview/working-with-objects/ (#22263) - Fix incorrect notation of 'directory' into Korean (#22155) - Fix issue with k8s.io/ko/docs/concepts/overview/components.md (#22232) - Update outdated files in dev-1.18-ko.7 (#22128) - Modify spacing term ReplicaSet in Korean (#22148) - Translate tasks/administer-cluster/extended-resource-node.md into Korean (#21849) - Translate tasks/administer-cluster/access-cluster-api.md into Korean (#21730) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: woopyoung <ywp041@gmail.com> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: Ian Y. Choi <ianyrchoi@gmail.com>
This commit is contained in:
June Yi
@@ -5,9 +5,9 @@ content_type: concept
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성,
|
||||
클러스터의 마스터와 워커 노드들의 업그레이드,
|
||||
노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
|
||||
이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성,
|
||||
클러스터의 마스터와 워커 노드들의 업그레이드,
|
||||
노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
|
||||
쿠버네티스 API 버전 업그레이드.
|
||||
|
||||
|
||||
@@ -25,17 +25,17 @@ content_type: concept
|
||||
|
||||
### Azure Kubernetes Service (AKS) 클러스터 업그레이드
|
||||
|
||||
Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는
|
||||
Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는
|
||||
현재 사용자가 직접 시작하는 방식이며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)에 설명되어 있다.
|
||||
|
||||
### Google Compute Engine 클러스터 업그레이드
|
||||
|
||||
Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고
|
||||
재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해
|
||||
Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고
|
||||
재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해
|
||||
동일한 Persistent Disk(PD)를 유지한다.
|
||||
|
||||
GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는
|
||||
순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은
|
||||
GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는
|
||||
순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은
|
||||
레플리케이션 컨트롤러에 의해서 제어되거나, 롤 아웃 후에 수작업으로 재생성되어야 한다.
|
||||
|
||||
open source Google Compute Engine(GCE) 클러스터 업그레이드는 `cluster/gce/upgrade.sh` 스크립트로 제어한다.
|
||||
@@ -81,7 +81,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레
|
||||
|
||||
## 클러스터 크기 재조정
|
||||
|
||||
[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
|
||||
[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
|
||||
[Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
|
||||
|
||||
```shell
|
||||
@@ -99,23 +99,23 @@ Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터
|
||||
|
||||
### 클러스터 오토스케일링
|
||||
|
||||
GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
|
||||
GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
|
||||
재조정하도록 클러스터를 구성할 수 있다.
|
||||
|
||||
[컴퓨트 리소스](/docs/concepts/configuration/manage-compute-resources-container/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
|
||||
이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
|
||||
여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
|
||||
[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
|
||||
이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
|
||||
여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
|
||||
다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다.
|
||||
|
||||
Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를
|
||||
Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를
|
||||
추가하는 것이 도움이 되는지를 체크한다. 만약 도움이 된다면 대기중인 파드들을 수용하기 위해 클러스터의 크기를 재조정한다.
|
||||
|
||||
Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안
|
||||
Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안
|
||||
더 이상 필요하지 않다는 것을 확인했을 때 클러스터를 스케일 다운하기도 한다.
|
||||
|
||||
Cluster autoscaler는 인스턴스 그룹(GCE)이나 노드 풀(Google Kubernetes Engine) 단위로 구성된다.
|
||||
|
||||
GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다.
|
||||
GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다.
|
||||
cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설정해야 한다.
|
||||
|
||||
* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - true로 설정되면 cluster autoscaler를 활성화한다.
|
||||
@@ -128,8 +128,8 @@ cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설
|
||||
KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의
|
||||
생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을
|
||||
Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의
|
||||
생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을
|
||||
전달하여 cluster autoscaler를 구성할 수 있다.
|
||||
|
||||
예제:
|
||||
@@ -144,17 +144,17 @@ gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=
|
||||
|
||||
**Cluster autoscaler는 노드가 수작업으로 변경(예. kubectl을 통해 레이블을 추가)되는 경우를 예상하지 않는데, 동일한 인스턴스 그룹 내의 신규 노드들에 이 속성들이 전파되지 않을 것이기 때문이다.**
|
||||
|
||||
cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은
|
||||
autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
|
||||
cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은
|
||||
autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
|
||||
문서를 참조하기를 바란다.
|
||||
|
||||
## 노드 유지보수
|
||||
|
||||
(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면,
|
||||
Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면
|
||||
(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.)
|
||||
노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는
|
||||
레플리카 셋 (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이
|
||||
(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면,
|
||||
Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면
|
||||
(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.)
|
||||
노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는
|
||||
레플리카셋(ReplicaSet) (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이
|
||||
복제된 상황에서 모든 노드들이 동시에 다운되지 않는다고 가정했을 때, 별다른 조작없이 업데이트를 진행할 수 있다.
|
||||
|
||||
만약 업그레이드 과정을 상세하게 통제하기를 원한다면, 다음 워크플로우를 사용할 수 있다.
|
||||
@@ -167,9 +167,9 @@ kubectl drain $NODENAME
|
||||
|
||||
이렇게하면 파드가 종료되는 동안 신규 파드들이 해당 노드에 스케줄되는 것을 방지한다.
|
||||
|
||||
레플리카 셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.
|
||||
레플리카셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.
|
||||
|
||||
레플리카 셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.
|
||||
레플리카셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.
|
||||
|
||||
해당 노드에 유지보수 작업을 수행한다.
|
||||
|
||||
@@ -179,8 +179,8 @@ kubectl drain $NODENAME
|
||||
kubectl uncordon $NODENAME
|
||||
```
|
||||
|
||||
해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
|
||||
자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
|
||||
해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
|
||||
자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
|
||||
이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
|
||||
|
||||
## 고급 주제들
|
||||
@@ -199,15 +199,15 @@ kubectl uncordon $NODENAME
|
||||
|
||||
### 클러스터에서 API 버전을 ON/OFF 하기
|
||||
|
||||
특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
|
||||
전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다.
|
||||
예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다.
|
||||
특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
|
||||
전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다.
|
||||
예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다.
|
||||
이 플래그들을 위해 레거시 API들은 명확하게 사용중단된 API들이다.(예. `v1beta3`)
|
||||
|
||||
### 클러스터에서 스토리지 API 버전을 변경
|
||||
|
||||
클러스터 내에서 활성화된 쿠버네티스 리소스들의 클러스터의 내부 표현을 위해 디스크에 저장된 객체들은 특정 버전의 API를 사용하여 작성된다.
|
||||
지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이
|
||||
지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이
|
||||
쿠버네티스 API 서버에서 더 이상 해독되거나 사용할 수 없게 될 것이다.
|
||||
|
||||
### 구성 파일을 신규 API 버전으로 변경
|
||||
@@ -219,5 +219,3 @@ kubectl convert -f pod.yaml --output-version v1
|
||||
```
|
||||
|
||||
옵션에 대한 상세 정보는 [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) 커맨드의 사용법을 참조하기를 바란다.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user