From fdde76a4ce75bf13afac24a9b9c42c445c7033fc Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 20 Dec 2021 16:02:29 +0900 Subject: [PATCH 01/18] [ko] Update outdated files in dev-1.23-ko.1 M62-70 --- .../container-runtimes.md | 2 +- .../tools/kubeadm/install-kubeadm.md | 2 +- .../production-environment/tools/kubespray.md | 4 +- .../windows/user-guide-windows-containers.md | 19 +++ .../access-cluster.md | 112 +----------------- .../list-all-running-container-images.md | 4 +- .../access-cluster-services.md | 12 +- 7 files changed, 38 insertions(+), 117 deletions(-) diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 18c8a9cbb1..97be57a3c4 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -79,7 +79,7 @@ systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명 # dnf install -y grubby && \ sudo grubby \ --update-kernel=ALL \ - --args=”systemd.unified_cgroup_hierarchy=1" + --args="systemd.unified_cgroup_hierarchy=1" ``` 구성을 적용하려면 노드를 재부팅해야 한다. diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 999bfd192e..a1f9ea18ab 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -243,7 +243,7 @@ sudo mkdir -p $DOWNLOAD_DIR crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 필요) ```bash -CRICTL_VERSION="v1.17.0" +CRICTL_VERSION="v1.22.0" ARCH="amd64" curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ``` diff --git a/content/ko/docs/setup/production-environment/tools/kubespray.md b/content/ko/docs/setup/production-environment/tools/kubespray.md index 6e7d9c8185..598ad32609 100644 --- a/content/ko/docs/setup/production-environment/tools/kubespray.md +++ b/content/ko/docs/setup/production-environment/tools/kubespray.md @@ -38,8 +38,8 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h * 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다 * **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다 -* **방화벽은 관리되지 않는다**. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다 -* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다 +* **방화벽은 kubespray에 의해 관리되지 않는다**. 사용자는 필요에 따라 적절한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다 +* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 하며, `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다 Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다: diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index aaa96a4fcf..7e0ac5763b 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -1,4 +1,9 @@ --- + + + + + title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드 content_type: concept weight: 75 @@ -155,7 +160,21 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동 노드셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. + {{< note >}} +`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면, +파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다). +리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다. +윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을 +`windows`로 설정한다. +스케줄러는 파드를 노드에 할당할 때 `.spec.os.name` 필드의 값을 사용하지 않는다. +컨트롤 플레인이 파드를 적절한 운영 체제가 실행되고 있는 노드에 배치하도록 하려면, +[파드를 노드에 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)하는 +일반적인 쿠버네티스 메카니즘을 사용해야 한다. +`.spec.os.name` 필드는 윈도우 파드의 스케줄링에는 영향을 미치지 않기 때문에, +윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면 테인트, +톨러레이션 및 노드 셀렉터가 여전히 필요하다. + {{< /note >}} ### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기 사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다. diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 9e7c9b4fc7..810259621a 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -214,117 +214,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. ## 클러스터에서 실행되는 서비스로 접근 -이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 -쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. +이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다. -쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), -[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 -고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 -클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 접근을 -할 수 없을 것이다. - -### 통신을 위한 방식들 - -클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다. - - - 공인 IP를 통해 서비스에 접근. - - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 - 서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와 - [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - - 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며, - 인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. - 해당 서비스는 자체적으로 인증을 수행하는가? - - 파드는 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 - 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택하는 신규 서비스를 생성한다. - - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 - 접근할 필요는 없다. - - Proxy Verb를 사용하여 서비스, 노드, 파드에 접근. - - 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다. - 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 포트에 - 접근을 하려고 하거나 debugging을 하려면 이를 사용한다. - - 어떤 web 애플리케이션에서는 프록시가 문제를 일으킬 수 있다. - - HTTP/HTTPS에서만 동작한다. - - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다. - - 클러스터 내 노드 또는 파드에서 접근. - - 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. - 해당 셸에서 다른 노드, 파드, 서비스에 연결한다. - - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 - 클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 - 다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다. - -### 빌트인 서비스 검색 - -일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다. -`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다. - -```shell -kubectl cluster-info -``` - -결괏값은 다음과 같을 것이다. - -``` -Kubernetes master is running at https://104.197.5.247 -elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy -kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy -kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy -grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy -heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy -``` - -이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다. -예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 -`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 접근할 수 있다. 예를 들어 kubectl proxy로 -`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다. -(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.) - -#### 수작업으로 apiserver proxy URL을 구축 - -위에서 언급한 것처럼 서비스의 proxy URL을 검색하는 데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에 -`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. - -당신이 포트에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, *port_name* 이 들어갈 자리에 포트 번호를 기재할 수도 있다. - -기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다. -`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy` - -URL의 네임 부분에 지원되는 양식은 다음과 같다. - -* `` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. -* `:` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. -* `https::` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론:에 주의) -* `https::` - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. - -##### 예제들 - - * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 접근하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다. - * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 접근하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다. - -```json -{ - "cluster_name" : "kubernetes_logging", - "status" : "yellow", - "timed_out" : false, - "number_of_nodes" : 1, - "number_of_data_nodes" : 1, - "active_primary_shards" : 5, - "active_shards" : 5, - "relocating_shards" : 0, - "initializing_shards" : 0, - "unassigned_shards" : 5 -} -``` - -### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 접근 - -브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만 - - - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, - 당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다. - - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 - 구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다. - -## 요청 redirect +## redirect 요청하기 redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다. diff --git a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md index f777d192cd..a6f4f086d2 100644 --- a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -70,7 +70,7 @@ jsonpath에서 `.items[*]` 부분은 생략해야 하는데, 이는 명령어가 반복하여 출력할 수 있다. ```shell -kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort ``` @@ -80,7 +80,7 @@ sort 명령어 결과값은 `app=nginx` 레이블에 일치하는 파드만 출력한다. ```shell -kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` ## 파드 네임스페이스로 필터링된 컨테이너 이미지 목록 보기 diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md index 8019e46c25..ab083d3690 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md @@ -86,7 +86,17 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi 위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 서비스의 프록시 URL에 추가하면 된다. `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy` -포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. +포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. 또한, 이름이 지정된 포트와 지정되지 않은 포트 모두에 대해, *port_name* 자리에 포트 번호를 기재할 수도 있다. + +기본적으로, API 서버는 서비스로의 프록시를 HTTP로 제공한다. HTTPS를 사용하려면, 서비스 이름 앞에 `https:`를 추가한다. +`http://<쿠버네티스_컨트롤_플레인_주소>/api/v1/namespaces/<네임스페이스_이름>/services/<서비스_이름>/proxy` + +URL에서 `<서비스_이름>`이 지원하는 형식은 다음과 같다. + +* `<서비스_이름>` - 기본 포트 또는 이름이 지정되지 않은 포트로 http를 사용하여 프록시 +* `<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 http를 사용하여 프록시 +* `https:<서비스_이름>:` - 기본 포트 또는 이름이 지정되지 않은 포트로 https를 사용하여 프록시(맨 끝의 콜론에 유의) +* `https:<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 https를 사용하여 프록시 ##### 예제 From aa161ad833280433eeb09c875a00b25bd38a8cce Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Tue, 14 Dec 2021 19:47:42 +0900 Subject: [PATCH 02/18] [ko] Update outdated files in dev-1.23-ko.1 M1-M12 --- content/ko/_index.html | 6 +- content/ko/community/_index.html | 1 + .../concepts/architecture/cloud-controller.md | 4 +- .../ko/docs/concepts/architecture/nodes.md | 117 +++++++++++++++--- .../concepts/cluster-administration/addons.md | 7 +- .../cluster-administration/networking.md | 57 +-------- .../manage-resources-containers.md | 14 +-- .../ko/docs/concepts/configuration/secret.md | 2 +- content/ko/docs/concepts/containers/images.md | 85 ++++++++++++- 9 files changed, 205 insertions(+), 88 deletions(-) diff --git a/content/ko/_index.html b/content/ko/_index.html index c6350f1559..3e21fbde45 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -30,7 +30,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 {{% blocks/feature image="suitcase" %}} #### K8s를 어디서나 실행 -쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. +쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는 데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. {{% /blocks/feature %}} @@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준

- Attend KubeCon North America on October 11-15, 2021 + KubeCon Europe (2022년 5월 17~20일) 참가하기



- Attend KubeCon Europe on May 17-20, 2022 + KubeCon North America (2022년 10월 24~28일) 참가하기
diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 9666cd4a14..30ede236bc 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -19,6 +19,7 @@ cid: community
+기여자 커뮤니티      커뮤니티 가치      행동 강령       비디오      diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index e5e7d315c5..eccfe091ce 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -44,10 +44,10 @@ weight: 40 ### 노드 컨트롤러 노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 {{< glossary_tooltip text="노드" term_id="node" >}} -오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 +오브젝트를 업데이트하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다. -1. 컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다. +1. 클라우드 공급자 API를 통해 획득한 해당 서버의 고유 ID를 노드 오브젝트에 업데이트한다. 2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를 사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다. 3. 노드의 호스트 이름과 네트워크 주소를 가져온다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index c71462d9b3..86a9856b47 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -385,7 +385,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. -## 그레이스풀(Graceful) 노드 셧다운 {#graceful-node-shutdown} +## 그레이스풀(Graceful) 노드 셧다운(shutdown) {#graceful-node-shutdown} {{< feature-state state="beta" for_k8s_version="v1.21" >}} @@ -402,7 +402,7 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 제어된다. 기본적으로, 아래 설명된 두 구성 옵션, -`ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로, +`shutdownGracePeriod` 및 `shutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로, 그레이스풀 노드 셧다운 기능이 활성화되지 않는다. 기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다. @@ -412,32 +412,116 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다. 그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다. -* `ShutdownGracePeriod`: +* `shutdownGracePeriod`: * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다. -* `ShutdownGracePeriodCriticalPods`: - * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다. +* `shutdownGracePeriodCriticalPods`: + * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `shutdownGracePeriod` 보다 작아야 한다. -예를 들어, `ShutdownGracePeriod=30s`, -`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 +예를 들어, `shutdownGracePeriod=30s`, +`shutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의 유예 종료에 할당되고, 마지막 10초는 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다. {{< note >}} -그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다. -`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Shutdown`으로 표시된다. +그레이스풀 노드 셧다운 과정에서 축출된 파드는 셧다운(shutdown)된 것으로 표시된다. +`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Terminated`으로 표시된다. 그리고 `kubectl describe pod` 명령을 실행하면 노드 셧다운으로 인해 파드가 축출되었음을 알 수 있다. ``` -Status: Failed -Reason: Shutdown -Message: Node is shutting, evicting pods +Reason: Terminated +Message: Pod was terminated in response to imminent node shutdown. ``` -실패한 파드 오브젝트는 명시적으로 삭제하거나 [가비지 콜렉션에 의해 정리](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)되기 전까지는 보존된다. -이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다. {{< /note >}} +### 파드 우선순위 기반 그레이스풀 노드 셧다운 {#pod-priority-graceful-node-shutdown} + +{{< feature-state state="alpha" for_k8s_version="v1.23" >}} + +그레이스풀 노드 셧다운 시 파드 셧다운 순서에 더 많은 유연성을 제공할 수 있도록, +클러스터에 프라이어리티클래스(PriorityClass) 기능이 활성화되어 있으면 +그레이스풀 노드 셧다운 과정에서 파드의 프라이어리티클래스가 고려된다. +이 기능으로 그레이스풀 노드 셧다운 시 파드가 종료되는 순서를 클러스터 관리자가 +[프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스) +기반으로 명시적으로 정할 수 있다. + +위에서 기술된 것처럼, [그레이스풀 노드 셧다운](#graceful-node-shutdown) 기능은 파드를 +중요하지 않은(non-critical) 파드와 +중요한(critical) 파드 2단계(phase)로 구분하여 종료시킨다. +셧다운 시 파드가 종료되는 순서를 명시적으로 더 상세하게 정해야 한다면, +파드 우선순위 기반 그레이스풀 노드 셧다운을 사용할 수 있다. + +그레이스풀 노드 셧다운 과정에서 파드 우선순위가 고려되기 때문에, +그레이스풀 노드 셧다운이 여러 단계로 일어날 수 있으며, +각 단계에서 특정 프라이어리티 클래스의 파드를 종료시킨다. +정확한 단계와 단계별 셧다운 시간은 kubelet에 설정할 수 있다. + +다음과 같이 클러스터에 커스텀 파드 +[프라이어리티 클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)가 있다고 +가정하자. + +|파드 프라이어리티 클래스 이름|파드 프라이어리티 클래스 값| +|-------------------------|------------------------| +|`custom-class-a` | 100000 | +|`custom-class-b` | 10000 | +|`custom-class-c` | 1000 | +|`regular/unset` | 0 | + +[kubelet 환경 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 안의 +`shutdownGracePeriodByPodPriority` 설정은 다음과 같을 수 있다. + +|파드 프라이어리티 클래스 값|종료 대기 시간| +|------------------------|---------------| +| 100000 |10 seconds | +| 10000 |180 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + +이를 나타내는 kubelet 환경 설정 YAML은 다음과 같다. + +```yaml +shutdownGracePeriodByPodPriority: + - priority: 100000 + shutdownGracePeriodSeconds: 10 + - priority: 10000 + shutdownGracePeriodSeconds: 180 + - priority: 1000 + shutdownGracePeriodSeconds: 120 + - priority: 0 + shutdownGracePeriodSeconds: 60 +``` + +위의 표에 의하면 우선순위 값이 100000 이상인 파드는 종료까지 10초만 주어지며, +10000 이상 ~ 100000 미만이면 180초, +1000 이상 ~ 10000 미만이면 120초가 주어진다. +마지막으로, 다른 모든 파드는 종료까지 60초가 주어질 것이다. + +모든 클래스에 대해 값을 명시할 필요는 없다. +예를 들어, 대신 다음과 같은 구성을 사용할 수도 있다. + +|파드 프라이어리티 클래스 값|종료 대기 시간| +|------------------------|---------------| +| 100000 |300 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + + +위의 경우, custom-class-b에 속하는 파드와 custom-class-c에 속하는 파드는 +동일한 종료 대기 시간을 갖게 될 것이다. + +특정 범위에 해당되는 파드가 없으면, +kubelet은 해당 범위에 해당되는 파드를 위해 기다려 주지 않는다. +대신, kubelet은 즉시 다음 프라이어리티 클래스 값 범위로 넘어간다. + +기능이 활성화되어 있지만 환경 설정이 되어 있지 않으면, +순서 지정 동작이 수행되지 않을 것이다. + +이 기능을 사용하려면 `GracefulNodeShutdownBasedOnPodPriority` 기능 게이트를 활성화해야 하고, +kubelet 환경 설정의 `ShutdownGracePeriodByPodPriority`를 +파드 프라이어리티 클래스 값과 +각 값에 대한 종료 대기 시간을 명시하여 지정해야 한다. + ## 스왑(swap) 메모리 관리 {#swap-memory} {{< feature-state state="alpha" for_k8s_version="v1.22" >}} @@ -451,6 +535,11 @@ kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 [구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가 false로 지정되어야 한다. +{{< warning >}} +메모리 스왑 기능이 활성화되면, 시크릿 오브젝트의 내용과 같은 +tmpfs에 기록되었던 쿠버네티스 데이터가 디스크에 스왑될 수 있다. +{{< /warning >}} + 사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며, 이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면, diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 270063a737..fc605ae453 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -25,7 +25,7 @@ content_type: concept * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. -* [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다. +* Multus는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. @@ -45,6 +45,11 @@ content_type: concept ## 인프라스트럭처 * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어 메탈 클러스터에서 실행한다. +* [node problem detector](https://github.com/kubernetes/node-problem-detector)는 + 리눅스 노드에서 실행되며, + 시스템 이슈를 + [이벤트](/docs/reference/kubernetes-api/cluster-resources/event-v1/) 또는 + [노드 컨디션](/docs/concepts/architecture/nodes/#condition) 형태로 보고한다. ## 레거시 애드온 diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index 545c26f420..d916a09105 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -64,7 +64,7 @@ weight: 50 VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다. -이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. +이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. 비슷하게, 사용자가 선택한 네트워킹 옵션이 [IPv4/IPv6 이중 스택](/ko/docs/concepts/services-networking/dual-stack/)을 지원할 수도 있으며, 구현 방법은 다양할 수 있다. `Pod` 로 전달하는 `Node` 자체의 포트(호스트 포트라고 함)를 요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은 @@ -169,49 +169,6 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네 충족하는 매우 간단한 오버레이 네트워크이다. 많은 경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다. -### Google 컴퓨트 엔진(GCE) - -Google 컴퓨트 엔진 클러스터 구성 스크립트의 경우, [고급 -라우팅](https://cloud.google.com/vpc/docs/routes)을 사용하여 -각 VM에 서브넷을 할당한다(기본값은 `/24` - 254개 IP). 해당 서브넷에 바인딩된 -모든 트래픽은 GCE 네트워크 패브릭에 의해 VM으로 직접 라우팅된다. 이는 -아웃 바운드 인터넷 접근을 위해 NAT로 구성된 VM에 할당된 "기본" -IP 주소에 추가된다. 리눅스 브릿지(`cbr0`)는 해당 서브넷에 존재하도록 -구성되며, 도커의 `--bridge` 플래그로 전달된다. - -도커는 다음의 설정으로 시작한다. - -```shell -DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" -``` - -이 브릿지는 노드의 `.spec.podCIDR`에 따라 Kubelet(`--network-plugin=kubenet` -플래그로 제어되는)에 의해 생성된다. - -도커는 이제 `cbr-cidr` 블록에서 IP를 할당한다. 컨테이너는 `cbr0` 브릿지를 -통해 서로 `Node` 에 도달할 수 있다. 이러한 IP는 모두 GCE 프로젝트 네트워크 -내에서 라우팅할 수 있다. - -그러나, GCE 자체는 이러한 IP에 대해 전혀 알지 못하므로, 아웃 바운드 인터넷 트래픽을 위해 -IP를 NAT하지 않는다. 그것을 달성하기 위해 iptables 규칙을 사용하여 -GCE 프로젝트 네트워크(10.0.0.0/8) 외부의 IP에 바인딩된 트래픽을 -마스커레이드(일명 SNAT - 마치 패킷이 `Node` 자체에서 온 것처럼 -보이게 함)한다. - -```shell -iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE -``` - -마지막으로 커널에서 IP 포워딩이 활성화되어 있으므로, 커널은 브릿지된 컨테이너에 -대한 패킷을 처리한다. - -```shell -sysctl net.ipv4.ip_forward=1 -``` - -이 모든 것의 결과는 모든 `Pod` 가 서로에게 도달할 수 있고 인터넷으로 트래픽을 -송신할 수 있다는 것이다. - ### 재규어(Jaguar) [재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다. @@ -246,7 +203,7 @@ Lars Kellogg-Stedman이 제공하는 ### Multus(멀티 네트워크 플러그인) -[Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다. +Multus는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다. Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다. @@ -260,12 +217,6 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https:// [NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만 -오버레이 네트워크를 구축하는 복잡한 방법이다. 이것은 네트워킹 분야의 몇몇 -"대형 벤더"에 의해 승인되었다. - ### OVN(오픈 버추얼 네트워킹) OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 @@ -274,10 +225,6 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에 특정 쿠버네티스 플러그인 및 문서가 있다. -### 로마나 - -[로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다. - ### Weaveworks의 위브넷 [위브넷](https://www.weave.works/products/weave-net/)은 diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index fa7ec69fc9..78e7ecfba6 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -74,8 +74,7 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 수량이다. 이것은 [API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및 [서비스](/ko/docs/concepts/services-networking/service/)와 같은 API 리소스는 -쿠버네티스 API 서버를 통해 읽고 수정할 수 -있는 오브젝트이다. +쿠버네티스 API 서버를 통해 읽고 수정할 수 있는 오브젝트이다. ## 파드와 컨테이너의 리소스 요청 및 제한 @@ -100,9 +99,10 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다. 쿠버네티스의 CPU 1개는 클라우드 공급자용 **vCPU/Core 1개** 와 베어메탈 인텔 프로세서에서의 **1개 하이퍼스레드** 에 해당한다. -분수의 요청이 허용된다. -`0.5` 의 `spec.containers[].resources.requests.cpu` 요청을 가진 -컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은 +요청량을 소수점 형태로 명시할 수도 있다. 컨테이너의 +`spec.containers[].resources.requests.cpu`를 `0.5`로 설정한다는 것은, +`1.0` CPU를 요청했을 때와 비교하여 절반의 CPU 타임을 요청한다는 의미이다. +CPU 자원의 단위와 관련하여, `0.1` 이라는 표현은 "백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다. `0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며, @@ -115,12 +115,12 @@ CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다. ### 메모리의 의미 `memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다. -E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를 +E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메모리를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다. ```shell -128974848, 129e6, 129M, 123Mi +128974848, 129e6, 129M, 128974848000m, 123Mi ``` 다음은 예제이다. diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 73d48cd18b..d27faddc20 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -244,7 +244,7 @@ kubectl create secret docker-registry secret-tiger-docker \ `kubernetes.io/basic-auth` 타입은 기본 인증을 위한 자격 증명을 저장하기 위해 제공된다. 이 시크릿 타입을 사용할 때는 시크릿의 `data` 필드가 -다음의 두 키를 포함해야 한다. +다음의 두 키 중 하나를 포함해야 한다. - `username`: 인증을 위한 사용자 이름 - `password`: 인증을 위한 암호나 토큰 diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 5ab09dd64a..d0c1d4bf7a 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -54,13 +54,15 @@ weight: 10 컨테이너에 대한 `imagePullPolicy`와 이미지의 태그는 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다. -다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 효과이다. +다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 +효과이다. `IfNotPresent` : 이미지가 로컬에 없는 경우에만 내려받는다. `Always` -: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의 +: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 + 이미지 레지스트리에 이름과 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)가 있는지 질의한다. 일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다. 이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서 @@ -78,7 +80,8 @@ weight: 10 {{< note >}} 프로덕션 환경에서 컨테이너를 배포하는 경우 `:latest` 태그 사용을 지양해야 하는데, -이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 제대로 롤백하기 어렵게 되기 때문이다. +이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 +제대로 롤백하기 어렵게 되기 때문이다. 대신, `v1.42.0`과 같이 의미있는 태그를 명기한다. {{< /note >}} @@ -90,7 +93,8 @@ weight: 10 이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다. -파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 +파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 +태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 서드-파티 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)가 있다. 이는 레지스트리에서 태그가 변경되는 일이 발생해도 구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다. @@ -104,7 +108,9 @@ weight: 10 `:latest`인 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. - `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. -- `imagePullPolicy` 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. +- `imagePullPolicy` 필드를 생략하고, + 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, + `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. {{< note >}} 컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상 @@ -127,6 +133,7 @@ weight: 10 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다. - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다. + ### 이미지풀백오프(ImagePullBackOff) kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때, @@ -258,6 +265,73 @@ kubectl describe pods/private-image-test-1 | grep 'Failed' 프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다. +### config.json 파일 해석 {#config-json} + +`config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다. +도커에서는 `auths` 키에 특정 루트 URL만 기재할 수 있으나, +쿠버네티스에서는 glob URL과 접두사-매칭 경로도 기재할 수 있다. +이는 곧 다음과 같은 `config.json`도 유효하다는 뜻이다. + +```json +{ + "auths": { + "*my-registry.io/images": { + "auth": "…" + } + } +} +``` + +루트 URL(`*my-registry.io`)은 다음 문법을 사용하여 매치된다. + +``` +pattern: + { term } + +term: + '*' 구분자가 아닌 모든 문자와 매치됨 + '?' 구분자가 아닌 문자 1개와 매치됨 + '[' [ '^' ] { character-range } ']' + 문자 클래스 (비어 있으면 안 됨)) + c 문자 c에 매치됨 (c != '*', '?', '\\', '[') + '\\' c 문자 c에 매치됨 + +character-range: + c 문자 c에 매치됨 (c != '\\', '-', ']') + '\\' c 문자 c에 매치됨 + lo '-' hi lo <= c <= hi 인 문자 c에 매치됨 +``` + +이미지 풀 작업 시, 모든 유효한 패턴에 대해 크리덴셜을 CRI 컨테이너 런타임에 제공할 것이다. +예를 들어 다음과 같은 컨테이너 이미지 이름은 +성공적으로 매치될 것이다. + +- `my-registry.io/images` +- `my-registry.io/images/my-image` +- `my-registry.io/images/another-image` +- `sub.my-registry.io/images/my-image` +- `a.sub.my-registry.io/images/my-image` + +kubelet은 인식된 모든 크리덴셜을 순차적으로 이용하여 이미지 풀을 수행한다. 즉, +`config.json`에 다음과 같이 여러 항목을 기재할 수도 있다. + +```json +{ + "auths": { + "my-registry.io/images": { + "auth": "…" + }, + "my-registry.io/images/subpath": { + "auth": "…" + } + } +} +``` + +이제 컨테이너가 `my-registry.io/images/subpath/my-image` +이미지를 풀 해야 한다고 명시하면, +kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다. + ### 미리 내려받은 이미지 {#pre-pulled-images} {{< note >}} @@ -383,3 +457,4 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config. * [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기. * [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기. +* [프라이빗 레지스트리에서 이미지 받아오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry) From 1d1928e173e5734d9788e0f5cf622d6a5ab87251 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Wed, 15 Dec 2021 15:10:23 +0900 Subject: [PATCH 03/18] [ko] Update outdated files in dev-1.23-ko.1 M17-24 --- .../docs/concepts/overview/kubernetes-api.md | 74 +++++++++++-- .../scheduling-eviction/kube-scheduler.md | 2 +- .../scheduler-perf-tuning.md | 4 +- .../connect-applications-service.md | 6 +- .../services-networking/dns-pod-service.md | 2 +- .../services-networking/dual-stack.md | 16 +-- .../ingress-controllers.md | 1 + .../concepts/services-networking/ingress.md | 102 +++++++++++++++--- 8 files changed, 172 insertions(+), 35 deletions(-) diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 919d59b459..cc043139c4 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -1,4 +1,6 @@ --- + + title: 쿠버네티스 API content_type: concept weight: 30 @@ -35,36 +37,39 @@ card: 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. -OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. -다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다. +### OpenAPI V2 + +쿠버네티스 API 서버는 `/openapi/v2` 엔드포인트를 통해 +통합된(aggregated) OpenAPI v2 스펙을 제공한다. +요청 헤더에 다음과 같이 기재하여 응답 형식을 지정할 수 있다. - + - - - + + + - + - + - + - +
Valid request header values for OpenAPI v2 queries OpenAPI v2 질의에 사용할 수 있는 유효한 요청 헤더 값
HeaderPossible valuesNotes헤더사용할 수 있는 값참고
Accept-Encoding gzipnot supplying this header is also acceptable이 헤더를 제공하지 않는 것도 가능
Accept application/com.github.proto-openapi.spec.v2@v1.0+protobufmainly for intra-cluster use주로 클러스터 내부 용도로 사용
application/jsondefault기본값
*serves application/jsonJSON으로 응답
@@ -75,6 +80,55 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한 IDL(인터페이스 정의 언어) 파일을 참고한다. +### OpenAPI V3 + +{{< feature-state state="alpha" for_k8s_version="v1.23" >}} + +쿠버네티스 v1.23은 OpenAPI v3 API 발행(publishing)에 대한 초기 지원을 제공한다. +이는 알파 기능이며 기본적으로 비활성화되어 있다. +kube-apiserver 구성 요소에 +`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 +이 알파 기능을 활성화할 수 있다. + +이 기능이 활성화되면, 쿠버네티스 API 서버는 +통합된(aggregated) OpenAPI v3 스펙을 쿠버네티스 그룹 버전별로 +`/openapi/v3/apis//` 엔드포인트에 제공한다. +사용할 수 있는 요청 헤더는 아래의 표를 참고한다. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OpenAPI v3 질의에 사용할 수 있는 유효한 요청 헤더 값
헤더사용할 수 있는 값참고
Accept-Encodinggzip이 헤더를 제공하지 않는 것도 가능
Acceptapplication/com.github.proto-openapi.spec.v3@v1.0+protobuf주로 클러스터 내부 용도로 사용
application/json기본값
*JSON으로 응답
+ +`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든 +그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다. + ## 지속성 쿠버네티스는 오브젝트의 직렬화된 상태를 diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 1c4424a047..0ab5b4b76f 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 -* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기 +* [kube-scheduler 구성(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index e2fb1cdcf9..5fd12dc521 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해 마치 100을 설정한 것처럼 작동한다. 값을 변경하려면, -[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을 +[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta3/)을 편집한 다음 스케줄러를 재시작한다. 대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다. @@ -161,4 +161,4 @@ percentageOfNodesToScore: 50 ## {{% heading "whatsnext" %}} -* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인 +* [kube-scheduler 구성 레퍼런스(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 확인 diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index bb7a9154c3..b7e5b26056 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -1,4 +1,8 @@ --- + + + + title: 서비스와 애플리케이션 연결하기 content_type: concept weight: 30 @@ -50,7 +54,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP 클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다. -만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다. +만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다. ## 서비스 생성하기 diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 3544d7e745..c23556172b 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -39,7 +39,7 @@ DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다 DNS 쿼리는 파드의 `/etc/resolv.conf` 를 사용하여 확장될 수 있을 것이다. Kubelet은 각 파드에 대해서 파일을 설정한다. 예를 들어, `data` 만을 위한 쿼리는 -`data.test.cluster.local` 로 확장된다. `search` 옵션의 값은 +`data.test.svc.cluster.local` 로 확장된다. `search` 옵션의 값은 쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우, [`resolv.conf` 설명 페이지.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)를 참고한다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 821ca34989..c77bba06c8 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -1,4 +1,9 @@ --- + + + + + title: IPv4/IPv6 이중 스택 feature: title: IPv4/IPv6 이중 스택 @@ -11,7 +16,7 @@ weight: 70 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다. @@ -42,8 +47,6 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 ## IPv4/IPv6 이중 스택 구성 -IPv4/IPv6 이중 스택을 사용하려면, 클러스터의 관련 구성 요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. (1.21부터 IPv4/IPv6 이중 스택이 기본적으로 활성화된다.) - IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다. * kube-apiserver: @@ -60,9 +63,6 @@ IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도 IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.) -1.21부터, IPv4/IPv6 이중 스택은 기본적으로 활성화된다. -필요한 경우 kube-apiserver, kube-controller-manager, kubelet 및 kube-proxy 커맨드 라인에 -`--feature-gates="IPv6DualStack=false"` 를 지정하여 비활성화할 수 있다. {{< /note >}} ## 서비스 @@ -76,7 +76,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서 * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. * `PreferDualStack`: - * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. (클러스터에 `--feature-gates="IPv6DualStack=false"` 가 있는 경우, 이 설정은 `SingleStack` 과 동일한 동작을 따른다.) + * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. * `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다. * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다. @@ -119,7 +119,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서 #### 기존 서비스의 이중 스택 기본값 -이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (`--feature-gates="IPv6DualStack=false"` 가 설정되지 않은 경우 기존 클러스터를 1.21로 업그레이드하면 이중 스택이 활성화된다.) +이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.) 1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다. diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index c66a9b6e84..a8b2cf1d5f 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -28,6 +28,7 @@ weight: 40 컨트롤러다. * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다. * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다. +* [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe)는 [BFE](https://www.bfe-networks.net) 기반 인그레스 컨트롤러다. * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는 Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다. * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index bafb216014..bb78469e83 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -51,7 +51,7 @@ graph LR; 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 -[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는 +[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 또는 [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다. ## 전제 조건들 @@ -219,20 +219,98 @@ Events: {{< codenew file="service/networking/external-lb.yaml" >}} -IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한 -추가 구현 별 구성을 참조하는데 사용할 수 있다. +인그레스클래스의 `.spec.parameters` 필드를 사용하여 +해당 인그레스클래스와 연관있는 환경 설정을 제공하는 다른 리소스를 참조할 수 있다. -#### 네임스페이스 범위의 파라미터 +사용 가능한 파라미터의 상세한 타입은 +인그레스클래스의 `.spec.parameters` 필드에 명시한 인그레스 컨트롤러의 종류에 따라 다르다. -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +### 인그레스클래스 범위 -`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데 -사용할 수 있는 `scope` 및 `namespace` 필드가 있다. -`Scope` 필드의 기본값은 `Cluster` 이다. 즉, 기본값은 클러스터 범위의 -리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를 -설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다. +인그레스 컨트롤러의 종류에 따라, 클러스터 범위로 설정한 파라미터의 사용이 가능할 수도 있고, +또는 한 네임스페이스에서만 사용 가능할 수도 있다. -{{< codenew file="service/networking/namespaced-params.yaml" >}} +{{< tabs name="tabs_ingressclass_parameter_scope" >}} +{{% tab name="클러스터" %}} +인그레스클래스 파라미터의 기본 범위는 클러스터 범위이다. + +`.spec.parameters` 필드만 설정하고 `.spec.parameters.scope` 필드는 지정하지 않거나, +`.spec.parameters.scope` 필드를 `Cluster`로 지정하면, +인그레스클래스는 클러스터 범위의 리소스를 참조한다. +파라미터의 `kind`(+`apiGroup`)는 +클러스터 범위의 API (커스텀 리소스일 수도 있음) 를 참조하며, +파라미터의 `name`은 +해당 API에 대한 특정 클러스터 범위 리소스를 가리킨다. + +예시는 다음과 같다. +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-1 +spec: + controller: example.com/ingress-controller + parameters: + # 이 인그레스클래스에 대한 파라미터는 "external-config-1" 라는 + # ClusterIngressParameter(API 그룹 k8s.example.net)에 기재되어 있다. + # 이 정의는 쿠버네티스가 + # 클러스터 범위의 파라미터 리소스를 검색하도록 한다. + scope: Cluster + apiGroup: k8s.example.net + kind: ClusterIngressParameter + name: external-config-1 +``` +{{% /tab %}} +{{% tab name="네임스페이스" %}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +`.spec.parameters` 필드를 설정하고 +`.spec.parameters.scope` 필드를 `Namespace`로 지정하면, +인그레스클래스는 네임스페이스 범위의 리소스를 참조한다. +사용하고자 하는 파라미터가 속한 네임스페이스를 +`.spec.parameters` 의 `namespace` 필드에 설정해야 한다. + +파라미터의 `kind`(+`apiGroup`)는 +네임스페이스 범위의 API (예: 컨피그맵) 를 참조하며, +파라미터의 `name`은 +`namespace`에 명시한 네임스페이스의 특정 리소스를 가리킨다. + +네임스페이스 범위의 파라미터를 이용하여, +클러스터 운영자가 워크로드에 사용되는 환경 설정(예: 로드 밸런서 설정, API 게이트웨이 정의)에 대한 제어를 위임할 수 있다. +클러스터 범위의 파라미터를 사용했다면 다음 중 하나에 해당된다. + +- 다른 팀의 새로운 환경 설정 변경을 적용하려고 할 때마다 + 클러스터 운영 팀이 매번 승인을 해야 한다. 또는, +- 애플리케이션 팀이 클러스터 범위 파라미터 리소스를 변경할 수 있게 하는 + [RBAC](/docs/reference/access-authn-authz/rbac/) 롤, 바인딩 등의 특별 접근 제어를 + 클러스터 운영자가 정의해야 한다. + +인그레스클래스 API 자신은 항상 클러스터 범위이다. + +네임스페이스 범위의 파라미터를 참조하는 인그레스클래스 예시가 +다음과 같다. +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-2 +spec: + controller: example.com/ingress-controller + parameters: + # 이 인그레스클래스에 대한 파라미터는 + # "external-configuration" 환경 설정 네임스페이스에 있는 + # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다. + scope: Namespace + apiGroup: k8s.example.com + kind: IngressParameter + namespace: external-configuration + name: external-config +``` + +{{% /tab %}} +{{< /tabs >}} ### 사용중단(Deprecated) 어노테이션 @@ -565,6 +643,6 @@ Events: ## {{% heading "whatsnext" %}} -* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 +* [인그레스](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/) From 1badd802c3565ca0397e30e5586ca9bfc42b716e Mon Sep 17 00:00:00 2001 From: bang9211 Date: Fri, 17 Dec 2021 03:12:12 +0900 Subject: [PATCH 04/18] Translate tasks/run-application/scale-stateful-set.md in Korean --- .../run-application/scale-stateful-set.md | 100 ++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 content/ko/docs/tasks/run-application/scale-stateful-set.md diff --git a/content/ko/docs/tasks/run-application/scale-stateful-set.md b/content/ko/docs/tasks/run-application/scale-stateful-set.md new file mode 100644 index 0000000000..52fe7ac593 --- /dev/null +++ b/content/ko/docs/tasks/run-application/scale-stateful-set.md @@ -0,0 +1,100 @@ +--- + + + + + + + + +title: 스테이트풀셋(StatefulSet) 확장하기 +content_type: task +weight: 50 +--- + + +이 작업은 스테이트풀셋을 확장하는 방법을 보여준다. 스테이트풀셋 확장은 레플리카 수를 늘리거나 줄이는 것을 의미한다. + + +## {{% heading "prerequisites" %}} + + +* 스테이트풀셋은 쿠버네티스 버전 1.5 이상에서만 사용할 수 있다. + 쿠버네티스 버전을 확인하려면 `kubectl version`을 실행한다. + +* 모든 스테이트풀 애플리케이션이 제대로 확장되는 것은 아니다. 스테이트풀셋을 확장할지 여부가 확실하지 않은 경우에 자세한 내용은 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 또는 [스테이트풀셋 튜토리얼](/ko/docs/tutorials/stateful-application/basic-stateful-set/)을 참조한다. + +* 스테이트풀 애플리케이션 클러스터가 완전히 정상이라고 확신할 때만 + 확장을 수행해야 한다. + + + + + +## 스테이트풀셋 확장하기 + +### kubectl을 사용하여 스테이트풀셋 확장 + +먼저 확장하려는 스테이트풀셋을 찾는다. + +```shell +kubectl get statefulsets +``` + +스테이트풀셋의 레플리카 수를 변경한다. + +```shell +kubectl scale statefulsets --replicas= +``` + +### 스테이트풀셋 인플레이스(in-place) 업데이트 + +대안으로 스테이트풀셋에 [인플레이스 업데이트](/ko/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources)를 수행할 수 있다. + +스테이트풀셋이 처음에 `kubectl apply`로 생성된 경우, +스테이트풀셋 매니페스트의 `.spec.replicas`를 업데이트한 다음 `kubectl apply`를 수행한다. + +```shell +kubectl apply -f +``` + +그렇지 않으면 `kubectl edit`로 해당 필드를 편집한다. + +```shell +kubectl edit statefulsets +``` + +또는 `kubectl patch`를 사용한다. + +```shell +kubectl patch statefulsets -p '{"spec":{"replicas":}}' +``` + +## 트러블슈팅 + +### 축소가 제대로 작동하지 않음 + +스테이트풀셋에서 관리하는 스테이트풀 파드가 비정상인 경우에는 스테이트풀셋을 축소할 수 없다. 축소는 +스테이트풀 파드가 실행되고 준비된 후에만 발생한다. + +spec.replicas > 1인 경우 쿠버네티스는 비정상 파드의 원인을 결정할 수 없다. 영구적인 오류 또는 일시적인 오류의 결과일 수 있다. 일시적인 오류는 업그레이드 또는 유지 관리에 필요한 재시작으로 인해 발생할 수 있다. + +영구적인 오류로 인해 파드가 비정상인 경우 +오류를 수정하지 않고 확장하면 스테이트풀셋 멤버십이 올바르게 작동하는 데 필요한 +특정 최소 레플리카 수 아래로 떨어지는 상태로 이어질 수 있다. +이로 인해 스테이트풀셋을 사용할 수 없게 될 수 있다. + +일시적인 오류로 인해 파드가 비정상 상태이고 파드를 다시 사용할 수 있게 되면 +일시적인 오류가 확장 또는 축소 작업을 방해할 수 있다. 일부 분산 +데이터베이스에는 노드가 동시에 가입 및 탈퇴할 때 문제가 있다. 이러한 경우 +애플리케이션 수준에서 확장 작업에 대해 추론하고 스테이트풀 애플리케이션 클러스터가 +완전히 정상이라고 확신할 때만 확장을 수행하는 것이 좋다. + + + +## {{% heading "whatsnext" %}} + + +* [스테이트풀셋 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)에 대해 더 배워보기 + + From 022bf26ab20831f902a05e00c4c2db9619cd5e35 Mon Sep 17 00:00:00 2001 From: bang9211 Date: Fri, 31 Dec 2021 15:24:06 +0900 Subject: [PATCH 05/18] Translate tasks/run-application/scale-stateful-set.md in Korean --- .../debug-cluster.md | 124 ++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 content/ko/docs/tasks/debug-application-cluster/debug-cluster.md diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-cluster.md b/content/ko/docs/tasks/debug-application-cluster/debug-cluster.md new file mode 100644 index 0000000000..7fdd2d7c37 --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/debug-cluster.md @@ -0,0 +1,124 @@ +--- + + +title: 클러스터 트러블슈팅 +content_type: concept +--- + + + +이 문서는 클러스터 트러블슈팅에 대해 설명한다. 사용자가 겪고 있는 문제의 근본 원인으로서 사용자의 애플리케이션을 +이미 배제했다고 가정한다. +애플리케이션 디버깅에 대한 팁은 [애플리케이션 트러블슈팅 가이드](/docs/tasks/debug-application-cluster/debug-application/)를 참조한다. +자세한 내용은 [트러블슈팅 문서](/docs/tasks/debug-application-cluster/troubleshooting/)를 참조한다. + + + +## 클러스터 나열하기 + +클러스터에서 가장 먼저 디버그해야 할 것은 노드가 모두 올바르게 등록되었는지 여부이다. + +다음을 실행한다. + +```shell +kubectl get nodes +``` + +그리고 보일 것으로 예상되는 모든 노드가 존재하고 모두 `Ready` 상태인지 확인한다. + +클러스터의 전반적인 상태에 대한 자세한 정보를 얻으려면 다음을 실행할 수 있다. + +```shell +kubectl cluster-info dump +``` +## 로그 보기 + +현재로서는 클러스터를 더 깊이 파고들려면 관련 머신에서 로그 확인이 필요하다. 관련 로그 파일 +위치는 다음과 같다. (systemd 기반 시스템에서는 `journalctl`을 대신 사용해야 할 수도 있다.) + +### 마스터 + + * `/var/log/kube-apiserver.log` - API 서버, API 제공을 담당 + * `/var/log/kube-scheduler.log` - 스케줄러, 스케줄 결정을 담당 + * `/var/log/kube-controller-manager.log` - 레플리케이션 컨트롤러를 담당하는 컨트롤러 + +### 워커 노드 + + * `/var/log/kubelet.log` - Kubelet, 노드에서 컨테이너 실행을 담당 + * `/var/log/kube-proxy.log` - Kube Proxy, 서비스 로드밸런싱을 담당 + +## 클러스터 장애 모드의 일반적인 개요 + +아래에 일부 오류 상황 예시 및 문제를 완화하기 위해 클러스터 설정을 조정하는 방법을 나열한다. + +### 근본 원인 + + - VM(들) 종료 + - 클러스터 내 또는 클러스터와 사용자 간의 네트워크 분할 + - 쿠버네티스 소프트웨어의 충돌 + - 데이터 손실 또는 퍼시스턴트 스토리지 사용 불가 (e.g. GCE PD 또는 AWS EBS 볼륨) + - 운영자 오류, 예를 들면 잘못 구성된 쿠버네티스 소프트웨어 또는 애플리케이션 소프트웨어 + +### 특정 시나리오 + + - API 서버 VM 종료 또는 API 서버 충돌 + - 다음의 현상을 유발함 + - 새로운 파드, 서비스, 레플리케이션 컨트롤러를 중지, 업데이트 또는 시작할 수 없다. + - 쿠버네티스 API에 의존하지 않는 기존 파드 및 서비스는 계속 정상적으로 작동할 것이다. + - API 서버 백업 스토리지 손실 + - 다음의 현상을 유발함 + - API 서버가 구동되지 않을 것이다. + - kubelet에 도달할 수 없게 되지만, kubelet이 여전히 동일한 파드를 계속 실행하고 동일한 서비스 프록시를 제공할 것이다. + - API 서버를 재시작하기 전에, 수동으로 복구하거나 API서버 상태를 재생성해야 한다. + - 지원 서비스 (노드 컨트롤러, 레플리케이션 컨트롤러 매니저, 스케쥴러 등) VM 종료 또는 충돌 + - 현재 그것들은 API 서버와 같은 위치에 있기 때문에 API 서버와 비슷한 상황을 겪을 것이다. + - 미래에는 이들도 복제본을 가질 것이며 API서버와 별도로 배치될 수도 있다. + - 지원 서비스들은 상태(persistent state)를 자체적으로 유지하지는 않는다. + - 개별 노드 (VM 또는 물리적 머신) 종료 + - 다음의 현상을 유발함 + - 해당 노드의 파드가 실행을 중지 + - 네트워크 분할 + - 다음의 현상을 유발함 + - 파티션 A는 파티션 B의 노드가 다운되었다고 생각한다. 파티션 B는 API 서버가 다운되었다고 생각한다. (마스터 VM이 파티션 A에 있다고 가정) + - Kubelet 소프트웨어 오류 + - 다음의 현상을 유발함 + - 충돌한 kubelet은 노드에서 새 파드를 시작할 수 없다. + - kubelet이 파드를 삭제할 수도 있고 삭제하지 않을 수도 있다. + - 노드는 비정상으로 표시된다. + - 레플리케이션 컨트롤러는 다른 곳에서 새 파드를 시작한다. + - 클러스터 운영자 오류 + - 다음의 현상을 유발함 + - 파드, 서비스 등의 손실 + - API 서버 백업 저장소 분실 + - API를 읽을 수 없는 사용자 + - 기타 + +### 완화 + +- 조치: IaaS VM을 위한 IaaS 공급자의 자동 VM 다시 시작 기능을 사용한다. + - 다음을 완화할 수 있음: API 서버 VM 종료 또는 API 서버 충돌 + - 다음을 완화할 수 있음: 지원 서비스 VM 종료 또는 충돌 + +- 조치: API 서버+etcd가 있는 VM에 IaaS 제공자의 안정적인 스토리지(예: GCE PD 또는 AWS EBS 볼륨)를 사용한다. + - 다음을 완화할 수 있음: API 서버 백업 스토리지 손실 + +- 조치: [고가용성](/docs/setup/production-environment/tools/kubeadm/high-availability/) 구성을 사용한다. + - 다음을 완화할 수 있음: 컨트롤 플레인 노드 종료 또는 컨트롤 플레인 구성 요소(스케줄러, API 서버, 컨트롤러 매니저) 충돌 + - 동시에 발생하는 하나 이상의 노드 또는 구성 요소 오류를 허용한다. + - 다음을 완화할 수 있음: API 서버 백업 스토리지(i.e., etcd의 데이터 디렉터리) 손실 + - 고가용성 etcd 구성을 사용하고 있다고 가정 + +- 조치: API 서버 PD/EBS 볼륨의 주기적인 스냅샷 + - 다음을 완화할 수 있음: API 서버 백업 스토리지 손실 + - 다음을 완화할 수 있음: 일부 운영자 오류 사례 + - 다음을 완화할 수 있음: 일부 쿠버네티스 소프트웨어 오류 사례 + +- 조치: 파드 앞에 레플리케이션 컨트롤러와 서비스 사용 + - 다음을 완화할 수 있음: 노드 종료 + - 다음을 완화할 수 있음: Kubelet 소프트웨어 오류 + +- 조치: 예기치 않은 재시작을 허용하도록 설계된 애플리케이션(컨테이너) + - 다음을 완화할 수 있음: 노드 종료 + - 다음을 완화할 수 있음: Kubelet 소프트웨어 오류 + + From 208e4ed66c1170433c1fc6a6f029c5a1b8cb1870 Mon Sep 17 00:00:00 2001 From: "Claudia J. Kang" Date: Mon, 20 Dec 2021 21:54:29 +0900 Subject: [PATCH 06/18] [ko] Translate docs/tasks/debug-application-cluster/troubleshooting.md --- .../troubleshooting.md | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 content/ko/docs/tasks/debug-application-cluster/troubleshooting.md diff --git a/content/ko/docs/tasks/debug-application-cluster/troubleshooting.md b/content/ko/docs/tasks/debug-application-cluster/troubleshooting.md new file mode 100644 index 0000000000..de0629690b --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/troubleshooting.md @@ -0,0 +1,107 @@ +--- + + + +content_type: concept +title: 트러블슈팅하기 +--- + + + +때때로 문제가 발생할 수 있다. 이 가이드는 이러한 상황을 해결하기 위해 작성되었다. 문제 해결에는 +다음 두 가지를 참고해 볼 수 있다. + +* [애플리케이션 트러블슈팅하기](/docs/tasks/debug-application-cluster/debug-application/) - 쿠버네티스에 + 코드를 배포하였지만 제대로 동작하지 않는 사용자들에게 유용한 가이드이다. +* [클러스터 트러블슈팅하기](/docs/tasks/debug-application-cluster/debug-cluster/) - 쿠버네티스 클러스터에 + 문제를 겪고 있는 클러스터 관리자 혹은 기분이 나쁜 사람들에게 유용한 가이드이다. + +여러분이 현재 사용중인 릴리스에 대한 알려진 이슈들을 다음의 [릴리스](https://github.com/kubernetes/kubernetes/releases) +페이지에서 확인해 볼 수도 있다. + + + +## 도움 받기 + +여러분의 문제가 위에 소개된 어떠한 가이드로도 해결할 수 없다면, +쿠버네티스 커뮤니티로부터 도움을 받을 수 있는 다양한 방법들을 시도해 볼 수 있다. + +### 질문 + +이 사이트의 문서들은 다양한 질문들에 대한 답변을 제공할 수 있도록 구성되어 있다. +[개념](/ko/docs/concepts/)은 쿠버네티스의 아키텍처와 각 컴포넌트들이 어떻게 동작하는지에 대해 설명하고, +[시작하기](/ko/docs/setup/)는 쿠버네티스를 시작하는 데 유용한 지침들을 제공한다. +[태스크](/ko/docs/tasks/)는 흔히 사용되는 작업들을 수행하는 방법에 대해 소개하고, +[튜토리얼](/ko/docs/tutorials/)은 실무, 산업 특화 혹은 종단간 개발에 특화된 시나리오를 통해 차근차근 설명한다. +[레퍼런스](/ko/docs/reference/) 섹션에서는 +[쿠버네티스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)와 +[`kubectl`](/ko/docs/reference/kubectl/overview/)과 같은 커맨드 라인 인터페이스(CLI)에 대한 +상세한 설명을 다룬다. + +## 도와주세요! 내 질문이 다뤄지지 않았어요! 도움이 필요해요! + +### 스택 오버플로우 + +여러분들이 겪고 있는 문제와 동일한 문제에 대한 도움을 위해 커뮤니티의 다른 사람들이 이미 +질문을 올렸을 수 있다. 쿠버네티스 팀은 +[쿠버네티스 태그가 등록된 글](https://stackoverflow.com/questions/tagged/kubernetes)들을 모니터링하고 있다. +발생한 문제와 도움이 되는 질문이 없다면, +[새로운 질문](https://stackoverflow.com/questions/ask?tags=kubernetes)을 올려라! + +### 슬랙 + +쿠버네티스 슬랙의 `#kubernetes-users` 채널을 통해 쿠버네티스 커뮤니티의 여러 사람들을 접할 수도 있다. +쿠버네티스 슬랙을 사용하기 위해서는 등록이 필요한데, 다음을 통해 [채널 초대 요청](https://slack.kubernetes.io)을 할 수 있다. +(누구나 가입할 수 있다). 슬랙 채널은 여러분이 어떠한 질문을 할 수 있도록 언제나 열려있다. +가입하고 나면 여러분의 웹 브라우저나 슬랙 앱을 통해 [쿠버네티스 슬랙](https://kubernetes.slack.com) +에 참여할 수 있다. + +쿠버네티스 슬랙에 참여하게 된다면, 다양한 주제의 흥미와 관련된 여러 채널들에 대해 +살펴본다. 가령, 쿠버네티스를 처음 접하는 사람이라면 +[`#kubernetes-novice`](https://kubernetes.slack.com/messages/kubernetes-novice) 채널에 가입할 수 있다. 혹은, 만약 당신이 개발자라면 +[`#kubernetes-dev`](https://kubernetes.slack.com/messages/kubernetes-dev) 채널에 가입할 수 있다. + +또한 각 국가 및 사용 언어별 채널들이 여럿 존재한다. 사용하는 언어로 도움을 받거나 정보를 +얻기 위해서는 다음의 채널에 참가한다. + +{{< table caption="국가 / 언어별 슬랙 채널" >}} +국가 | 채널 +:---------|:------------ +China(중국) | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users), [`#cn-events`](https://kubernetes.slack.com/messages/cn-events) +Finland(핀란드) | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users) +France(프랑스) | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users), [`#fr-events`](https://kubernetes.slack.com/messages/fr-events) +Germany(독일) | [`#de-users`](https://kubernetes.slack.com/messages/de-users), [`#de-events`](https://kubernetes.slack.com/messages/de-events) +India(인도) | [`#in-users`](https://kubernetes.slack.com/messages/in-users), [`#in-events`](https://kubernetes.slack.com/messages/in-events) +Italy(이탈리아) | [`#it-users`](https://kubernetes.slack.com/messages/it-users), [`#it-events`](https://kubernetes.slack.com/messages/it-events) +Japan(일본) | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users), [`#jp-events`](https://kubernetes.slack.com/messages/jp-events) +Korea(한국) | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users) +Netherlands(네덜란드) | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users) +Norway(노르웨이) | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users) +Poland(폴란드) | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users) +Russia(러시아) | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users) +Spain(스페인) | [`#es-users`](https://kubernetes.slack.com/messages/es-users) +Sweden(스웨덴) | [`#se-users`](https://kubernetes.slack.com/messages/se-users) +Turkey(터키) | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-events`](https://kubernetes.slack.com/messages/tr-events) +{{< /table >}} + +### 포럼 + +공식 쿠버네티스 포럼에 참여하는 것도 추천되는 방법이다. [discuss.kubernetes.io](https://discuss.kubernetes.io). + +### 버그와 기능 추가 요청 + +만약 여러분이 버그처럼 보이는 것을 발견했거나, 기능 추가 요청을 하기 위해서는 +[GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 사용한다. + +이슈를 작성하기 전에는, 여러분의 이슈가 기존 이슈에서 이미 +다뤄졌는지 검색해 본다. + +버그를 보고하는 경우에는, 해당 문제를 어떻게 재현할 수 있는지에 관련된 상세한 정보를 포함한다. +포함되어야 하는 정보들은 다음과 같다. + +* 쿠버네티스 버전: `kubectl version` +* 클라우드 프로바이더, OS 배포판, 네트워크 구성, 및 도커 버전 +* 문제를 재현하기 위한 절차 + + + From afe43b34e1b2e263603044983345ec1c631acb13 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 3 Jan 2022 16:18:23 +0900 Subject: [PATCH 07/18] [ko] Update outdated files in dev-1.23-ko.1 M71-82 --- .../kubeadm/adding-windows-nodes.md | 5 + .../kubeadm/kubeadm-upgrade.md | 16 -- .../administer-cluster/sysctl-cluster.md | 25 ++- .../configure-persistent-volume-storage.md | 11 +- .../pull-image-private-registry.md | 33 ++-- .../debug-running-pod.md | 18 +- .../resource-metrics-pipeline.md | 12 ++ .../extend-kubernetes/setup-konnectivity.md | 19 +- .../job/parallel-processing-expansion.md | 10 +- .../docs/tasks/network/validate-dual-stack.md | 5 +- .../horizontal-pod-autoscale-walkthrough.md | 162 ++++++++++++------ .../examples/pods/storage/pv-duplicate.yaml | 20 +++ 12 files changed, 214 insertions(+), 122 deletions(-) create mode 100644 content/ko/examples/pods/storage/pv-duplicate.yaml diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index e7a1b8fb79..4ce00186a3 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -1,4 +1,9 @@ --- + + + + + title: 윈도우 노드 추가 min-kubernetes-server-version: 1.17 content_type: tutorial diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 0e76e46c93..440f9d5026 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -78,10 +78,6 @@ OS 패키지 관리자를 사용하여 쿠버네티스의 최신 패치 릴리 apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다. @@ -175,10 +171,6 @@ sudo kubeadm upgrade apply apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 @@ -218,10 +210,6 @@ sudo systemctl restart kubelet apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 @@ -256,10 +244,6 @@ sudo systemctl restart kubelet apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 diff --git a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md index 8adf5c4564..33bc3de55d 100644 --- a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md @@ -10,8 +10,20 @@ content_type: task {{< feature-state for_k8s_version="v1.21" state="stable" >}} 이 문서는 쿠버네티스 클러스터에서 {{< glossary_tooltip term_id="sysctl" >}} 인터페이스를 사용하여 -커널 파라미터를 어떻게 구성하고, 사용하는지를 설명한다. +커널 파라미터를 어떻게 구성하고, 사용하는지를 +설명한다. +{{< note >}} +쿠버네티스 버전 1.23부터, kubelet은 `/` 또는 `.`를 +sysctl 이름의 구분자로 사용하는 것을 지원한다. +예를 들어, 동일한 sysctl 이름을 `kernel.shm_rmid_forced`와 같이 마침표를 구분자로 사용하여 나타내거나 +`kernel/shm_rmid_forced`와 같이 슬래시를 구분자로 사용하여 나타낼 수 있다. +sysctl 파라미터 변환에 대한 세부 사항은 +리눅스 맨페이지 프로젝트의 +[sysctl.d(5)](https://man7.org/linux/man-pages/man5/sysctl.d.5.html) 페이지를 참고한다. +파드와 파드시큐리티폴리시(PodSecurityPolicy)에 대해 sysctl을 설정하는 기능에서는 +아직 슬래시 구분자를 지원하지 않는다. +{{< /note >}} ## {{% heading "prerequisites" %}} @@ -20,6 +32,7 @@ content_type: task 일부 단계에서는 실행 중인 클러스터의 kubelet에서 커맨드 라인 옵션을 재구성할 필요가 있다. + ## 모든 sysctl 파라미터 나열 @@ -52,12 +65,13 @@ sysctl은 _safe_ sysctl과 _unsafe_ sysctl로 구성되어 있다. _safe_ sysctl 허용하지 않아야 한다 아직까지 대부분 _네임스페이스된_ sysctl은 _safe_ sysctl로 고려되지 않았다. ->>> 다음 sysctl은 _safe_ 명령을 지원한다. +다음 sysctl은 _safe_ 명령을 지원한다. - `kernel.shm_rmid_forced`, - `net.ipv4.ip_local_port_range`, - `net.ipv4.tcp_syncookies`, -- `net.ipv4.ping_group_range` (Kubernetes 1.18 이후). +- `net.ipv4.ping_group_range` (쿠버네티스 1.18 이후), +- `net.ipv4.ip_unprivileged_port_start` (쿠버네티스 1.22 이후). {{< note >}} `net.ipv4.tcp_syncookies` 예시는 리눅스 커널 버전 4.4 또는 이하에서 네임스페이스되지 않는다. @@ -112,10 +126,13 @@ _네임스페이스_ sysctl만 이 방법을 사용할 수 있다. 이를 설정해야 한다면, 각 노드의 OS에서 수동으로 구성하거나 특권있는 컨테이너의 데몬셋을 사용하여야 한다. -네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. securityContext는 동일한 파드의 모든 컨테이너에 적용된다. +네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. +securityContext는 동일한 파드의 모든 컨테이너에 적용된다. 이 예시는 safe sysctl `kernel.shm_rmid_forced`와 두 개의 unsafe sysctl인 `net.core.somaxconn` 과 `kernel.msgmax` 를 설정하기 위해 파드 securityContext를 사용한다. +스펙에 따르면 _safe_ sysctl과 _unsafe_ sysctl 간 +차이는 없다. {{< warning >}} 파라미터의 영향을 파악한 후에만 운영체제가 diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 3461c57061..a2bac74f99 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -96,11 +96,10 @@ hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다. 설정 파일에 클러스터 노드의 `/mnt/data` 에 볼륨이 있다고 지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가 -읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 -지정한다. 여기서는 +읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 지정한다. 여기서는 퍼시스턴트볼륨클레임의 [스토리지클래스 이름](/ko/docs/concepts/storage/persistent-volumes/#클래스)을 `manual` 로 정의하며, 퍼시스턴트볼륨클레임의 요청을 -이 퍼시스턴트볼륨에 바인딩하는데 사용한다. +이 퍼시스턴트볼륨에 바인딩하는 데 사용한다. 퍼시스턴트볼륨을 생성한다. @@ -237,8 +236,14 @@ sudo rmdir /mnt/data 이제 사용자 노드에서 셸을 종료해도 된다. +## 하나의 퍼시스턴트볼륨을 두 경로에 마운트하기 +{{< codenew file="pods/storage/pv-duplicate.yaml" >}} +하나의 퍼시스턴트볼륨을 nginx 컨테이너의 두 경로에 마운트할 수 있다. + +`/usr/share/nginx/html` - 정적 웹사이트 용 +`/etc/nginx/nginx.conf` - 기본 환경 설정 용 diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md index bb14d1c0ac..3a33d7a5fc 100644 --- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -6,29 +6,36 @@ weight: 100 -이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 +이 페이지는 프라이빗 컨테이너 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 +{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을 사용하는 파드를 생성하는 방법을 보여준다. +{{% thirdparty-content single="true" %}} + ## {{% heading "prerequisites" %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* {{< include "task-tutorial-prereqs.md" >}} -* 이 실습을 수행하기 위해, -[도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다. +* 이 실습을 수행하기 위해, `docker` 명령줄 도구와 +[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다. -## 도커 로그인 +## 도커 허브 로그인 노트북에 프라이빗 이미지를 받아오기 위하여 레지스트리 인증을 필수로 수행해야 한다. +`docker` 도구를 사용하여 도커 허브에 로그인한다. 자세한 정보는 +[도커 ID 계정](https://docs.docker.com/docker-id/#log-in)의 _로그 인_ 섹션을 참조한다. + ```shell docker login ``` -프롬프트가 나타나면, 도커 사용자 이름(username)과 비밀번호(password)를 입력하자. +프롬프트가 나타나면, 도커 ID를 입력한 다음, 사용하려는 자격증명(액세스 토큰, +또는 도커 ID의 비밀번호)을 입력한다. -로그인 프로세스는 권한 토큰 정보를 가지고 있는 `config.json` 파일을 생성하거나 업데이트 한다. +로그인 프로세스를 수행하면 권한 토큰 정보를 가지고 있는 `config.json` 파일이 생성되거나 업데이트된다. [쿠버네티스가 이 파일을 어떻게 해석하는지](/ko/docs/concepts/containers/images#config-json) 참고한다. `config.json` 파일을 확인하자. @@ -171,14 +178,14 @@ janedoe:xxxxxxxxxxx ## 시크릿을 사용하는 파드 생성하기 -다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 파드의 구성 파일이다. +다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 예제 파드의 매니페스트이다. {{< codenew file="pods/private-reg-pod.yaml" >}} -아래의 파일을 다운로드받는다. +위 파일을 컴퓨터에 다운로드한다. ```shell -wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +curl -L -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml ``` `my-private-reg-pod.yaml` 파일 안에서, `` 값을 다음과 같은 프라이빗 저장소 안의 이미지 경로로 변경한다. @@ -200,9 +207,9 @@ kubectl get pod private-reg ## {{% heading "whatsnext" %}} -* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기. +* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기 + * 또는 {{< api-reference page="config-and-storage-resources/secret-v1" >}} API 레퍼런스 읽어보기 * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기. * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기. * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기. -* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기. -* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기. +* 파드의 [컨테이너 정의](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers)의 `imagePullSecrets` 필드에 대해 읽어보기 diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md index 1c2073a21b..cbd69454f5 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -73,24 +73,16 @@ kubectl exec -it cassandra -- sh ## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container} -{{< feature-state state="alpha" for_k8s_version="v1.18" >}} +{{< feature-state state="beta" for_k8s_version="v1.23" >}} -컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼 -컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아 -`kubectl exec`가 충분하지 않을 경우에는 +컨테이너가 크래시 됐거나 +[distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼 +컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아 `kubectl exec`로는 충분하지 않은 경우에는 {{< glossary_tooltip text="임시(Ephemeral) 컨테이너" term_id="ephemeral-container" >}}를 사용하는 것이 -인터랙티브한 트러블슈팅에 유용하다. `kubectl` `v1.18` -버전부터는 임시 컨테이너를 생성할 수 있는 알파 단계의 -명령어가 있다. +인터랙티브한 트러블슈팅에 유용하다. ### 임시 컨테이너를 사용한 디버깅 예시 {#ephemeral-container-example} -{{< note >}} -이 섹션에서 소개하는 예시를 사용하기 위해서는 -여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다. -{{< /note >}} - `kubectl debug` 명령어를 사용해서 동작 중인 파드에 임시 컨테이너를 추가할 수 있다. 먼저, 다음과 같이 파드를 추가한다. diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index e4bf6a1715..a4d64e016e 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -1,4 +1,7 @@ --- + + + title: 리소스 메트릭 파이프라인 content_type: concept --- @@ -62,3 +65,12 @@ kubelet은 비율 계산에 사용할 윈도우를 선택한다. [설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다. + +### 요약(Summary) API 소스 +[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)은 노드, 볼륨, 파드, 컨테이너 수준의 통계를 수집하며, +소비자(consumer)가 읽을 수 있도록 이를 +[요약 API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)에 기록한다. + +1.23 이전에는 이러한 자원들은 기본적으로 [cAdvisor](https://github.com/google/cadvisor)에 의해 수집되었다. +그러나, 1.23에서 `PodAndContainerStatsFromCRI` 기능 게이트가 추가되면서, 컨테이너 및 파드 수준 통계를 CRI 구현에서 수집할 수 있게 되었다. +참고: 이를 위해서는 CRI 구현에서도 이 기능을 지원해야 한다(containerd >= 1.6.0, CRI-O >= 1.23.0). diff --git a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md index fdf671a52a..5bc131af19 100644 --- a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md +++ b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md @@ -11,7 +11,11 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} +쿠버네티스 클러스터가 있어야 하며, kubectl 명령줄 도구가 +클러스터와 통신하도록 설정되어 있어야 한다. 컨트롤 플레인 호스트가 아닌 +두 개 이상의 노드로 구성된 클러스터에서 이 튜토리얼을 수행하는 것을 권장한다. +클러스터가 없다면, [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/)를 +이용하여 생성할 수 있다. @@ -24,16 +28,9 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T Konnectivity 서비스를 사용하고 네트워크 트래픽을 클러스터 노드로 보내도록 API 서버를 구성해야 한다. -1. `ServiceAccountTokenVolumeProjection` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어 있는지 -확인한다. kube-apiserver에 다음과 같은 플래그를 제공하여 -[서비스 어카운트 토큰 볼륨 보호](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)를 -활성화할 수 있다. - ``` - --service-account-issuer=api - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key - --api-audiences=system:konnectivity-server - ``` +1. [Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) +기능이 활성화되어 있는지 확인한다. +쿠버네티스 v1.20부터는 기본적으로 활성화되어 있다. 1. `admin/konnectivity/egress-selector-configuration.yaml`과 같은 송신 구성 파일을 생성한다. 1. API 서버의 `--egress-selector-config-file` 플래그를 API 서버 송신 구성 파일의 경로로 설정한다. diff --git a/content/ko/docs/tasks/job/parallel-processing-expansion.md b/content/ko/docs/tasks/job/parallel-processing-expansion.md index fbf105024d..5870b4b314 100644 --- a/content/ko/docs/tasks/job/parallel-processing-expansion.md +++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md @@ -178,13 +178,13 @@ kubectl delete job -l jobgroup=jobexample ```liquid -{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, +{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, { "name": "banana", "url": "http://dbpedia.org/resource/Banana", }, { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }] %} -{%- for p in params %} -{%- set name = p["name"] %} -{%- set url = p["url"] %} +{% for p in params %} +{% set name = p["name"] %} +{% set url = p["url"] %} --- apiVersion: batch/v1 kind: Job @@ -204,7 +204,7 @@ spec: image: busybox command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] restartPolicy: Never -{%- endfor %} +{% endfor %} ``` 위의 템플릿은 파이썬 딕셔너리(dicts)로 구성된 항목(1-4행)을 사용하여 각 잡 오브젝트에 대해 diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 97753165f1..6c14644db1 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -3,7 +3,7 @@ -min-kubernetes-server-version: v1.20 +min-kubernetes-server-version: v1.23 title: IPv4/IPv6 이중 스택 검증 content_type: task --- @@ -21,6 +21,9 @@ content_type: task {{< version-check >}} +{{< note >}} +v1.23 이전 버전에서도 검증을 수행할 수 있지만 GA 기능으로만 제공되며, v1.23부터 공식적으로 지원된다. +{{< /note >}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index a910dc5c48..d1e864476a 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -4,42 +4,59 @@ -title: Horizontal Pod Autoscaler 연습 +title: HorizontalPodAutoscaler 연습 content_type: task weight: 100 +min-kubernetes-server-version: 1.23 --- -Horizontal Pod Autoscaler는 -CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 -레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. +[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(약어: HPA)는 +워크로드 리소스(예: {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는 +{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를 +자동으로 업데이트하며, +워크로드의 크기를 수요에 맞게 +자동으로 스케일링하는 것을 목표로 한다. -이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. -Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 -[Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. +수평 스케일링은 부하 증가에 대해 +{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다. +이는 _수직_ 스케일링(쿠버네티스에서는, +해당 워크로드를 위해 이미 실행 중인 파드에 +더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다. + +부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우, +HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋, +또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다. + +이 문서는 예제 웹 앱의 크기를 자동으로 조절하도록 +HorizontalPodAutoscaler를 설정하는 예시를 다룬다. +이 예시 워크로드는 PHP 코드를 실행하는 아파치 httpd이다. ## {{% heading "prerequisites" %}} -이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다. -[메트릭 서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여 -[메트릭 API](https://github.com/kubernetes/metrics)를 통해 메트릭을 제공해야 한다. -Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 방법에 대해 배우려면, -[메트릭-서버 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다. +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} 이전 버전의 +쿠버네티스를 사용하고 있다면, 해당 버전의 문서를 +참고한다([사용 가능한 문서의 버전](/ko/docs/home/supported-doc-versions/) 참고). -Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, -버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 -사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. -마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우, -버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 -메트릭 API와 통신이 가능해야 한다. -자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#사용자-정의-메트릭을-위한-지원)를 참고하길 바란다. +이 예제를 실행하기 위해, 클러스터에 [Metrics Server](https://github.com/kubernetes-sigs/metrics-server#readme)가 +배포 및 구성되어 있어야 한다. 쿠버네티스 Metrics Server는 클러스터의 +{{}}으로부터 +리소스 메트릭을 수집하고, 수집한 메트릭을 +[쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 통해 노출시키며, +메트릭 수치를 나타내는 새로운 종류의 리소스를 추가하기 위해 +[APIService](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용할 수 있다. + +Metrics Server를 실행하는 방법을 보려면 +[metrics-server 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다. ## php-apache 서버 구동 및 노출 -Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. Dockerfile은 다음과 같다. +HorizontalPodAutoscaler 예시에서, +먼저 도커 허브의 `php-apache` 이미지를 베이스로 하는 커스텀 컨테이너 이미지를 만들어 시작점으로 삼을 것이다. +`Dockerfile`은 미리 준비되어 있으며, 내용은 다음과 같다. ```dockerfile FROM php:5-apache @@ -47,7 +64,8 @@ COPY index.php /var/www/html/index.php RUN chmod a+rx index.php ``` -index.php는 CPU 과부하 연산을 수행한다. +아래의 코드는 CPU 과부하 연산을 수행하는 간단한 `index.php` 페이지를 정의하며, +이를 이용해 클러스터에 부하를 시뮬레이트한다. ```php ``` -첫 번째 단계로, 다음 구성을 사용해서 실행 중인 이미지의 디플로이먼트를 -시작하고 서비스로 노출시킨다. +컨테이너 이미지를 만들었다면, +방금 만든 이미지로부터 컨테이너를 실행하는 디플로이먼트를 시작하고, 다음의 매니페스트를 사용하여 디플로이먼트를 +{{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다. {{< codenew file="application/php-apache.yaml" >}} -다음의 명령어를 실행한다. +이를 위해, 다음의 명령어를 실행한다. ```shell kubectl apply -f https://k8s.io/examples/application/php-apache.yaml @@ -75,16 +94,27 @@ deployment.apps/php-apache created service/php-apache created ``` -## Horizontal Pod Autoscaler 생성 +## HorizontalPodAutoscaler 생성 {#create-horizontal-pod-autoscaler} -이제 서비스가 동작중이므로, -[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)를 사용하여 오토스케일러를 생성한다. -다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 -1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다. -간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다. -kubectl run으로 각 파드는 200 밀리코어를 요청하므로, -여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다. -이에 대한 자세한 알고리즘은 [여기](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고하기 바란다. +이제 서비스가 동작중이므로, +`kubectl`을 사용하여 오토스케일러를 생성한다. 이를 위해 +[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 서브커맨드를 사용할 수 있다. + +아래에서는 첫 번째 단계에서 만든 php-apache +디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 +Horizontal Pod Autoscaler를 생성하는 명령어를 실행할 것이다. + +간단히 이야기하면, HPA {{}}는 +평균 CPU 사용량을 50%로 유지하기 위해 (디플로이먼트를 업데이트하여) 레플리카의 개수를 늘리고 줄인다. +그러면 디플로이먼트는 레플리카셋을 업데이트하며(이는 모든 쿠버네티스 디플로이먼트의 동작 방식 중 일부이다), +레플리카셋은 자신의 `.spec` 필드의 변경 사항에 따라 파드를 추가하거나 제거한다. + +`kubectl run`으로 각 파드는 200 밀리코어를 요청하므로, 평균 CPU 사용은 100 밀리코어이다. +알고리즘에 대한 세부 사항은 +[알고리즘 세부 정보](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고한다. + + +HorizontalPodAutoscaler를 생성한다. ```shell kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 @@ -94,47 +124,64 @@ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 horizontalpodautoscaler.autoscaling/php-apache autoscaled ``` -실행 중인 오토스케일러의 현재 상태를 확인해본다. +다음을 실행하여, 새로 만들어진 HorizontalPodAutoscaler의 현재 상태를 확인할 수 있다. ```shell +# "hpa" 또는 "horizontalpodautoscaler" 둘 다 사용 가능하다. kubectl get hpa ``` +출력은 다음과 같다. ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s ``` -아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다. -(``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다) +(HorizontalPodAutoscalers 이름이 다르다면, 이미 기존에 존재하고 있었다는 뜻이며, +보통은 문제가 되지 않는다.) -## 부하 증가 +아직 서버로 요청을 보내는 클라이언트가 없기 때문에, 현재 CPU 사용량이 0%임을 확인할 수 있다. +(``TARGET`` 열은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다) -이번에는 부하가 증가함에 따라 오토스케일러가 어떻게 반응하는지를 살펴볼 것이다. 먼저 컨테이너를 하나 실행하고, php-apache 서비스에 무한루프의 쿼리를 전송한다(다른 터미널을 열어 수행하기 바란다). +## 부하 증가시키기 {#increase-load} +다음으로, 부하가 증가함에 따라 오토스케일러가 어떻게 반응하는지를 살펴볼 것이다. +이를 위해, 클라이언트 역할을 하는 다른 파드를 실행할 것이다. +클라이언트 파드 안의 컨테이너가 php-apache 서비스에 쿼리를 보내는 무한 루프를 실행한다. ```shell +# 부하 생성을 유지하면서 나머지 스텝을 수행할 수 있도록, +# 다음의 명령을 별도의 터미널에서 실행한다. kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done" ``` -실행 후, 약 1분 정도 후에 CPU 부하가 올라가는 것을 볼 수 있다. - +이제 아래 명령을 실행한다. ```shell +# 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다. kubectl get hpa ``` +1분 쯤 지나면, 다음과 같이 CPU 부하가 올라간 것을 볼 수 있다. + ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 305% / 50% 1 10 1 3m ``` -CPU 소비가 305%까지 증가하였다. -결과적으로, 디플로이먼트의 레플리카 개수는 7개까지 증가하였다. +그리고 다음과 같이 레플리카의 수가 증가한 것도 볼 수 있다. +``` +NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE +php-apache Deployment/php-apache/scale 305% / 50% 1 10 7 3m +``` + +CPU 사용률이 305%까지 증가하였다. +결과적으로, 디플로이먼트의 레플리카 개수가 7개까지 증가하였다. ```shell kubectl get deployment php-apache ``` +HorizontalPodAutoscaler를 조회했을 때와 동일한 레플리카 수를 확인할 수 있다. ``` NAME READY UP-TO-DATE AVAILABLE AGE php-apache 7/7 7 7 19m @@ -146,24 +193,27 @@ php-apache 7/7 7 7 19m 최종 레플리카의 개수는 본 예제와 다를 수 있다. {{< /note >}} -## 부하 중지 +## 부하 발생 중지하기 {#stop-load} 본 예제를 마무리하기 위해 부하를 중단시킨다. -`busybox` 컨테이너를 띄운 터미널에서, +`busybox` 파드를 띄운 터미널에서, ` + C`로 부하 발생을 중단시킨다. 그런 다음 (몇 분 후에) 결과를 확인한다. ```shell -kubectl get hpa +# 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다. +kubectl get hpa php-apache --watch ``` +출력은 다음과 같다. ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m ``` +디플로이먼트도 스케일 다운 했음을 볼 수 있다. ```shell kubectl get deployment php-apache ``` @@ -173,7 +223,7 @@ NAME READY UP-TO-DATE AVAILABLE AGE php-apache 1/1 1 1 27m ``` -CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮췄다. +CPU 사용량이 0으로 떨어져서, HPA가 자동으로 레플리카의 개수를 1로 줄였다. {{< note >}} 레플리카 오토스케일링은 몇 분 정도 소요된다. @@ -184,9 +234,9 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮 ## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링 `php-apache` 디플로이먼트를 오토스케일링할 때, -`autoscaling/v2beta2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다. +`autoscaling/v2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다. -첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다. +첫 번째로, `autoscaling/v2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다. ```shell kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml @@ -195,7 +245,7 @@ kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml 에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다. ```yaml -apiVersion: autoscaling/v2beta2 +apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache @@ -287,7 +337,7 @@ HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수 `kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다. ```yaml -apiVersion: autoscaling/v2beta2 +apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache @@ -411,7 +461,7 @@ object: ## 부록: Horizontal Pod Autoscaler 상태 조건 -HorizontalPodAutoscaler의 `autoscaling/v2beta2` 형식을 사용하면, +HorizontalPodAutoscaler의 `autoscaling/v2` 형식을 사용하면, HorizontalPodAutoscaler에서 쿠버네티스가 설정한 *상태 조건* 을 확인할 수 있다. 이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지, 어떤 방식으로든 제한되어 있는지 여부를 나타낸다. @@ -449,12 +499,12 @@ Events: 백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다. 두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 개수가 0이 아닌지), 원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우, -일반적으로 메트릭을 가져오는데 문제가 있다. +일반적으로 메트릭을 가져오는 데 문제가 있다. 마지막으로, 마지막 조건인 `ScalingLimited`는 원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다. 이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다. -## 부록: 수량 +## 수량 HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 쿠버네티스에서 사용하는 @@ -464,16 +514,16 @@ HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 일반적으로 수량을 밀리단위로 반환한다. 10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다. -## 부록: 다른 가능한 시나리오 +## 다른 가능한 시나리오 ### 명시적으로 오토스케일러 만들기 HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 사용하지 않고, -명시적으로 다음 파일을 사용하여 만들 수 있다. +명시적으로 다음 매니페스트를 사용하여 만들 수 있다. {{< codenew file="application/hpa/php-apache.yaml" >}} -다음 명령어를 실행하여 오토스케일러를 생성할 것이다. +다음으로, 아래의 명령어를 실행하여 오토스케일러를 생성한다. ```shell kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml diff --git a/content/ko/examples/pods/storage/pv-duplicate.yaml b/content/ko/examples/pods/storage/pv-duplicate.yaml new file mode 100644 index 0000000000..15a48acbed --- /dev/null +++ b/content/ko/examples/pods/storage/pv-duplicate.yaml @@ -0,0 +1,20 @@ + +apiVersion: v1 +kind: Pod +metadata: + name: test +spec: + containers: + - name: test + image: nginx + volumeMounts: + - name: site-data + mountPath: /usr/share/nginx/html + subPath: html + - name: config + mountPath: /etc/nginx/nginx.conf + subPath: nginx.conf + volumes: + - name: config + persistentVolumeClaim: + claimName: test-nfs-claim \ No newline at end of file From e9fe604ce154f0349bb50f1bfe62f08cb6c333dd Mon Sep 17 00:00:00 2001 From: Jaeyeon Kim Date: Thu, 6 Jan 2022 11:31:56 +0900 Subject: [PATCH 08/18] [ko] Translate content/ko/docs/concepts/architecture/cri.md Signed-off-by: Jaeyeon Kim Co-authored-by: Jesang Myung Co-authored-by: Seokho Son --- content/ko/docs/concepts/architecture/cri.md | 50 +++++++++++++++++++ .../glossary/container-runtime-interface.md | 22 ++++++++ 2 files changed, 72 insertions(+) create mode 100644 content/ko/docs/concepts/architecture/cri.md create mode 100644 content/ko/docs/reference/glossary/container-runtime-interface.md diff --git a/content/ko/docs/concepts/architecture/cri.md b/content/ko/docs/concepts/architecture/cri.md new file mode 100644 index 0000000000..69175432d1 --- /dev/null +++ b/content/ko/docs/concepts/architecture/cri.md @@ -0,0 +1,50 @@ +--- +title: 컨테이너 런타임 인터페이스(CRI) +content_type: concept +weight: 50 +--- + + + +컨테이너 런타임 인터페이스(CRI)는 클러스터 컴포넌트를 다시 컴파일하지 않아도 Kubelet이 다양한 +컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스다. + +클러스터의 모든 노드에 동작 중인 +{{}}이 존재해야, +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 +{{< glossary_tooltip text="파드" term_id="pod" >}}들과 컨테이너들을 +구동할 수 있다. + +{{< glossary_definition term_id="container-runtime-interface" length="all" >}} + + + +## API {#api} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Kubelet은 gRPC를 통해 컨테이너 런타임과 연결할 때 클라이언트의 역할을 수행한다. +런타임과 이미지 서비스 엔드포인트는 컨테이너 런타임 내에서 사용 가능해야 하며, +이는 각각 Kubelet 내에서 `--image-service-endpoint`와 `--container-runtime-endpoint` +[커맨드라인 플래그](/docs/reference/command-line-tools-reference/kubelet) +를 통해 설정할 수 있다. + +쿠버네티스 v{{< skew currentVersion >}}에서는, Kubelet은 CRI `v1`을 사용하는 것을 권장한다. +컨테이너 런타임이 CRI `v1` 버전을 지원하지 않는다면, +Kubelet은 지원 가능한 이전 지원 버전으로 협상을 시도한다. +또한 v{{< skew currentVersion >}} Kubelet은 CRI `v1alpha2`버전도 협상할 수 있지만, +해당 버전은 사용 중단(deprecated)으로 간주한다. +Kubelet이 지원되는 CRI 버전을 협상할 수 없는 경우, +Kubelet은 협상을 포기하고 노드로 등록하지 않는다. + +## 업그레이드 + +쿠버네티스를 업그레이드할 때, Kubelet은 컴포넌트의 재시작 시점에서 최신 CRI 버전을 자동으로 선택하려고 시도한다. +이 과정이 실패하면 위에서 언급한 대로 이전 버전을 선택하는 과정을 거친다. +컨테이너 런타임이 업그레이드되어 gRPC 재다이얼이 필요하다면, +컨테이너 런타임도 처음에 선택된 버전을 지원해야 하며, +그렇지 못한 경우 재다이얼은 실패하게 될 것이다. 이 과정은 Kubelet의 재시작이 필요하다. + +## {{% heading "whatsnext" %}} + +- CRI [프로토콜 정의](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)를 자세히 알아보자. diff --git a/content/ko/docs/reference/glossary/container-runtime-interface.md b/content/ko/docs/reference/glossary/container-runtime-interface.md new file mode 100644 index 0000000000..c0d6155a4a --- /dev/null +++ b/content/ko/docs/reference/glossary/container-runtime-interface.md @@ -0,0 +1,22 @@ +--- +title: 컨테이너 런타임 인터페이스(Container Runtime Interface) +id: container-runtime-interface +date: 2022-01-10 +full_link: /ko/docs/concepts/architecture/cri/ +short_description: > + Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜이다. + +aka: +tags: + - cri +--- + +Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜이다. + + + +쿠버네티스 컨테이너 런타임 인터페이스(CRI)는 +[클러스터 컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트) +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}과 +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} 사이의 +통신을 위한 주요 [gRPC](https://grpc.io) 프로토콜을 정의한다. From d311fcecad73cc533834749755d92e0d7fb5cf83 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Wed, 15 Dec 2021 15:14:32 +0900 Subject: [PATCH 09/18] [ko] Update outdated files in dev-1.23-ko.1 M25-33 --- .../service-traffic-policy.md | 2 +- .../concepts/storage/persistent-volumes.md | 58 +++-- .../docs/concepts/storage/storage-capacity.md | 3 +- .../docs/concepts/storage/storage-classes.md | 4 +- .../concepts/storage/volume-pvc-datasource.md | 7 +- .../storage/volume-snapshot-classes.md | 2 +- .../docs/concepts/storage/volume-snapshots.md | 9 +- content/ko/docs/concepts/storage/volumes.md | 221 ++++++------------ 8 files changed, 136 insertions(+), 170 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md index f658cd6cfa..8088d05366 100644 --- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되 ## {{% heading "whatsnext" %}} -* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기 +* [토폴로지 인식 힌트](/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기 * [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기 * [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기 diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 4bc8926e3b..31f576daa5 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -10,14 +10,13 @@ feature: title: 스토리지 오케스트레이션 description: > 로컬 스토리지, GCP나 AWS와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다. - content_type: concept weight: 20 --- -이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. +이 페이지에서는 쿠버네티스의 _퍼시스턴트 볼륨_ 에 대해 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. @@ -221,19 +220,19 @@ spec: {{< feature-state for_k8s_version="v1.11" state="beta" >}} -이제 퍼시스턴트볼륨클레임(PVC) 확장 지원이 기본적으로 활성화되어 있다. 다음 유형의 +퍼시스턴트볼륨클레임(PVC) 확장 지원은 기본적으로 활성화되어 있다. 다음 유형의 볼륨을 확장할 수 있다. -* gcePersistentDisk +* azureDisk +* azureFile * awsElasticBlockStore -* Cinder +* cinder (deprecated) +* {{< glossary_tooltip text="csi" term_id="csi" >}} +* flexVolume (deprecated) +* gcePersistentDisk * glusterfs * rbd -* Azure File -* Azure Disk -* Portworx -* FlexVolumes -* {{< glossary_tooltip text="CSI" term_id="csi" >}} +* portworxVolume 스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다. @@ -270,7 +269,7 @@ CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확 경우에만 파일시스템의 크기가 조정된다. 파일시스템 확장은 파드가 시작되거나 파드가 실행 중이고 기본 파일시스템이 온라인 확장을 지원할 때 수행된다. -FlexVolumes는 `RequiresFSResize` 기능으로 드라이버가 `true`로 설정된 경우 크기 조정을 허용한다. +FlexVolumes(쿠버네티스 v1.23부터 사용 중단됨)는 드라이버의 `RequiresFSResize` 기능이 `true`로 설정된 경우 크기 조정을 허용한다. FlexVolume은 파드 재시작 시 크기를 조정할 수 있다. #### 사용 중인 퍼시스턴트볼륨클레임 크기 조정 @@ -299,6 +298,11 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 #### 볼륨 확장 시 오류 복구 +사용자가 기반 스토리지 시스템이 제공할 수 있는 것보다 더 큰 사이즈를 지정하면, 사용자 또는 클러스터 관리자가 조치를 취하기 전까지 PVC 확장을 계속 시도한다. 이는 바람직하지 않으며 따라서 쿠버네티스는 이러한 오류 상황에서 벗어나기 위해 다음과 같은 방법을 제공한다. + +{{< tabs name="recovery_methods" >}} +{{% tab name="클러스터 관리자 접근 권한을 이용하여 수동으로" %}} + 기본 스토리지 확장에 실패하면, 클러스터 관리자가 수동으로 퍼시스턴트 볼륨 클레임(PVC) 상태를 복구하고 크기 조정 요청을 취소할 수 있다. 그렇지 않으면, 컨트롤러가 관리자 개입 없이 크기 조정 요청을 계속해서 재시도한다. 1. 퍼시스턴트볼륨클레임(PVC)에 바인딩된 퍼시스턴트볼륨(PV)을 `Retain` 반환 정책으로 표시한다. @@ -307,6 +311,30 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 4. PV 보다 작은 크기로 PVC를 다시 만들고 PVC의 `volumeName` 필드를 PV 이름으로 설정한다. 이것은 새 PVC를 기존 PV에 바인딩해야 한다. 5. PV의 반환 정책을 복원하는 것을 잊지 않는다. +{{% /tab %}} +{{% tab name="더 작은 크기로의 확장을 요청하여" %}} +{{% feature-state for_k8s_version="v1.23" state="alpha" %}} + +{{< note >}} +PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 제공되는 알파 기능이다. 이 기능이 작동하려면 `RecoverVolumeExpansionFailure` 기능이 활성화되어 있어야 한다. 더 많은 정보는 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참조한다. +{{< /note >}} + +클러스터에 `ExpandPersistentVolumes`와 `RecoverVolumeExpansionFailure` +기능 게이트가 활성화되어 있는 상태에서 PVC 확장이 실패하면 +이전에 요청했던 값보다 작은 크기로의 확장을 재시도할 수 있다. +더 작은 크기를 지정하여 확장 시도를 요청하려면, +이전에 요청했던 값보다 작은 크기로 PVC의 `.spec.resources` 값을 수정한다. +이는 총 용량 제한(capacity constraint)으로 인해 큰 값으로의 확장이 실패한 경우에 유용하다. +만약 확장이 실패했다면, 또는 실패한 것 같다면, 기반 스토리지 공급자의 용량 제한보다 작은 값으로 확장을 재시도할 수 있다. +`.status.resizeStatus`와 PVC의 이벤트를 감시하여 리사이즈 작업의 상태를 모니터할 수 있다. + +참고: +이전에 요청했던 값보다 작은 크기를 요청했더라도, +새로운 값이 여전히 `.status.capacity`보다 클 수 있다. +쿠버네티스는 PVC를 현재 크기보다 더 작게 축소하는 것은 지원하지 않는다. +{{% /tab %}} +{{% /tabs %}} + ## 퍼시스턴트 볼륨의 유형 @@ -318,7 +346,6 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 * [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨 * [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI) * [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지 -* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume * [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk * [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨 * [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨 @@ -336,6 +363,8 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 * [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지) (v1.18에서 **사용 중단**) +* [`flexVolume`](/docs/concepts/storage/volumes/#flexvolume) - FlexVolume + (v1.23에서 **사용 중단**) * [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지 (v1.22에서 **사용 중단**) * [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨 @@ -417,9 +446,12 @@ spec: `ReadWriteOnce` : 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파트가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다. -`ReadWriteMany` +`ReadOnlyMany` : 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다. +`ReadWriteMany` +: 볼륨이 다수의 노드에서 읽기-쓰기로 마운트 될 수 있다. + `ReadWriteOncePod` : 볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다. diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md index 4aeb1ba8c1..86c95ae13a 100644 --- a/content/ko/docs/concepts/storage/storage-capacity.md +++ b/content/ko/docs/concepts/storage/storage-capacity.md @@ -7,7 +7,7 @@ title: 스토리지 용량 content_type: concept -weight: 45 +weight: 70 --- @@ -16,7 +16,6 @@ weight: 45 예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며, 또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다. -{{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< feature-state for_k8s_version="v1.21" state="beta" >}} 이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고 diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index c915b65fad..c47f053a31 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -470,14 +470,14 @@ parameters: vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다. -- [CSI 프로비저닝 도구](#csi-프로비저닝-도구): `csi.vsphere.vmware.com` +- [CSI 프로비저닝 도구](#vsphere-provisioner-csi): `csi.vsphere.vmware.com` - [vCP 프로비저닝 도구](#vcp-프로비저닝-도구): `kubernetes.io/vsphere-volume` 인-트리 프로비저닝 도구는 [사용 중단](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)되었다. CSI 프로비저닝 도구에 대한 자세한 내용은 [쿠버네티스 vSphere CSI 드라이버](https://vsphere-csi-driver.sigs.k8s.io/) 및 [vSphereVolume CSI 마이그레이션](/ko/docs/concepts/storage/volumes/#csi-마이그레이션)을 참고한다. #### CSI 프로비저닝 도구 {#vsphere-provisioner-csi} -vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml)를 참조한다. +vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml)를 참조한다. #### vCP 프로비저닝 도구 diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index e9857885d7..365f780230 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -1,7 +1,12 @@ --- + + + + + title: CSI 볼륨 복제하기 content_type: concept -weight: 30 +weight: 60 --- diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 862c900fee..594d100772 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -8,7 +8,7 @@ title: 볼륨 스냅샷 클래스 content_type: concept -weight: 30 +weight: 41 # just after volume snapshots --- diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index b01a8affa4..d54ed5c45c 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -1,7 +1,14 @@ --- + + + + + + + title: 볼륨 스냅샷 content_type: concept -weight: 20 +weight: 40 --- diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 5983c37647..a4245a7daa 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -44,12 +44,21 @@ weight: 10 볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고 `.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다. -컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 -뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는 -파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에 -마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 -가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로 -지정해야 한다. +컨테이너의 프로세스는 +{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}의 최초 내용물과 +컨테이너 안에 마운트된 볼륨(정의된 경우에 한함)으로 구성된 파일시스템을 보게 된다. +프로세스는 컨테이너 이미지의 최초 내용물에 해당되는 루트 파일시스템을 +보게 된다. +쓰기가 허용된 경우, 해당 파일시스템에 쓰기 작업을 하면 +추후 파일시스템에 접근할 때 변경된 내용을 보게 될 것이다. +볼륨은 이미지의 [특정 경로](#using-subpath)에 +마운트된다. +파드에 정의된 각 컨테이너에 대해, +컨테이너가 사용할 각 볼륨을 어디에 마운트할지 명시해야 한다. + +볼륨은 다른 볼륨 안에 마운트될 수 없다 +(하지만, [서브패스 사용](#using-subpath)에서 관련 메커니즘을 확인한다). +또한, 볼륨은 다른 볼륨에 있는 내용물을 가리키는 하드 링크를 포함할 수 없다. ## 볼륨 유형들 {#volume-types} @@ -802,142 +811,7 @@ spec: ### projected `Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다. - -현재, 다음 유형의 볼륨 소스를 프로젝티드한다. - -* [`secret`](#secret) -* [`downwardAPI`](#downwardapi) -* [`configMap`](#configmap) -* `serviceAccountToken` - -모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은 -[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다. - -#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap} - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: volume-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: all-in-one - mountPath: "/projected-volume" - readOnly: true - volumes: - - name: all-in-one - projected: - sources: - - secret: - name: mysecret - items: - - key: username - path: my-group/my-username - - downwardAPI: - items: - - path: "labels" - fieldRef: - fieldPath: metadata.labels - - path: "cpu_limit" - resourceFieldRef: - containerName: container-test - resource: limits.cpu - - configMap: - name: myconfigmap - items: - - key: config - path: my-group/my-config -``` - -#### 구성 예시: 기본값이 아닌 소유권 모드 설정의 시크릿 {#example-configuration-secrets-nondefault-permission-mode} - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: volume-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: all-in-one - mountPath: "/projected-volume" - readOnly: true - volumes: - - name: all-in-one - projected: - sources: - - secret: - name: mysecret - items: - - key: username - path: my-group/my-username - - secret: - name: mysecret2 - items: - - key: password - path: my-group/my-password - mode: 511 -``` - -각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다. -파라미터는 두 가지 예외를 제외하고 거의 동일하다. - -* 시크릿의 경우 `secretName` 필드는 컨피그맵 이름과 일치하도록 - `name` 으로 변경되었다. -* `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만 - 지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode` - 를 명시적으로 설정할 수 있다. - -`TokenRequestProjection` 기능이 활성화 되면, 현재 -[서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에 -대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 예를 들면 다음과 같다. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: sa-token-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: token-vol - mountPath: "/service-account" - readOnly: true - volumes: - - name: token-vol - projected: - sources: - - serviceAccountToken: - audience: api - expirationSeconds: 3600 - path: token -``` - -예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이 -있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데 -사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을 -포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며, -그렇지 않으면 토큰을 거부해야 한다. 이 필드는 -선택 사항이며 기본값은 API 서버의 식별자이다. - -`expirationSeconds` 는 서비스 어카운트 토큰의 예상 유효 -기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는 -API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정해서 -최대 값을 제한할 수도 있다. `path` 필드는 projected 볼륨의 마운트 위치에 대한 -상대 경로를 지정한다. - -{{< note >}} -projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 -해당 볼륨 소스의 업데이트를 수신하지 않는다. -{{< /note >}} +더 자세한 사항은 [projected volumes](/docs/concepts/storage/projected-volumes/)를 참고한다. ### quobyte (사용 중단됨) {#quobyte} @@ -975,6 +849,38 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다. 더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를 참고한다. +#### RBD CSI 마이그레이션 {#rbd-csi-migration} + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +`RBD`를 위한 `CSIMigration` 기능이 활성화되어 있으면, +사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을 +`rbd.csi.ceph.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} +드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 +[Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고 +`CSIMigration`, `CSIMigrationRBD` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. + +{{< note >}} + +스토리지를 관리하는 쿠버네티스 클러스터 관리자는, +RBD CSI 드라이버로의 마이그레이션을 시도하기 전에 +다음의 선행 사항을 완료해야 한다. + +* 쿠버네티스 클러스터에 Ceph CSI 드라이버 (`rbd.csi.ceph.com`) v3.5.0 + 이상을 설치해야 한다. +* CSI 드라이버가 동작하기 위해 `clusterID` 필드가 필수이지만 + 트리 내(in-tree) 스토리지클래스는 `monitors` 필드가 필수임을 감안하여, + 쿠버네티스 저장소 관리자는 monitors 값의 + 해시(예: `#echo -n '' | md5sum`) + 기반으로 clusterID를 CSI 컨피그맵 내에 만들고 + 이 clusterID 환경 설정 아래에 monitors 필드를 유지해야 한다. +* 또한, 트리 내(in-tree) 스토리지클래스의 + `adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의 + `adminSecretName` 값이 `adminId` 파라미터 값의 + base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. + ### secret `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 @@ -1144,6 +1050,16 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 `vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다. +#### Portworx CSI 마이그레이션 +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +Portworx를 위한 `CSIMigration` 기능이 쿠버네티스 1.23에 추가되었지만 +알파 상태이기 때문에 기본적으로는 비활성화되어 있다. +이 기능은 사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을 +`pxd.portworx.com` CSI 드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 [Portworx CSI 드라이버](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)가 +설치되어 있고, kube-controller-manager와 kubelet에 `CSIMigrationPortworx=true`로 설정해야 한다. + ## subPath 사용하기 {#using-subpath} 때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. @@ -1239,8 +1155,7 @@ spec: ## 아웃-오브-트리(out-of-tree) 볼륨 플러그인 아웃-오브-트리 볼륨 플러그인에는 -{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 -FlexVolume이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 +{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 FlexVolume(사용 중단됨)이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다. 이전에는 모든 볼륨 플러그인이 "인-트리(in-tree)"에 있었다. "인-트리" 플러그인은 쿠버네티스 핵심 바이너리와 @@ -1373,13 +1288,21 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트 ### flexVolume -FlexVolume은 버전 1.2(CSI 이전) 이후 쿠버네티스에 존재하는 -아웃-오브-트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 -접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드와 일부 경우에 컨트롤 플레인 노드의 -미리 정의된 볼륨 플러그인 경로에 설치해야 한다. +{{< feature-state for_k8s_version="v1.23" state="deprecated" >}} + +FlexVolume은 스토리지 드라이버와 인터페이싱하기 위해 exec 기반 모델을 사용하는 아웃-오브-트리 플러그인 인터페이스이다. +FlexVolume 드라이버 바이너리 파일은 각 노드의 미리 정의된 볼륨 플러그인 경로에 설치되어야 하며, +일부 경우에는 컨트롤 플레인 노드에도 설치되어야 한다. 파드는 `flexvolume` 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다. -더 자세한 내용은 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 예제를 참고한다. +더 자세한 내용은 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 문서를 참고한다. + +{{< note >}} +FlexVolume은 사용 중단되었다. 쿠버네티스에 외부 스토리지를 연결하려면 아웃-오브-트리 CSI 드라이버를 사용하는 것을 권장한다. + +FlexVolume 드라이버 메인테이너는 CSI 드라이버를 구현하고 사용자들이 FlexVolume 드라이버에서 CSI로 마이그레이트할 수 있도록 지원해야 한다. +FlexVolume 사용자는 워크로드가 동등한 CSI 드라이버를 사용하도록 이전해야 한다. +{{< /note >}} ## 마운트 전파(propagation) From b928e5c8de3f3fc3b668373577edc469737b8d64 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 16 Dec 2021 08:47:02 +0900 Subject: [PATCH 10/18] [ko] Update outdated files in dev-1.23-ko.1 M34-37 --- .../workloads/controllers/cron-jobs.md | 37 +++-- .../workloads/controllers/deployment.md | 39 +++-- .../concepts/workloads/controllers/job.md | 64 +++++++- .../workloads/controllers/statefulset.md | 144 +++++++++++++++--- 4 files changed, 228 insertions(+), 56 deletions(-) diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 3ae5659806..34ac547b73 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -17,8 +17,6 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text=" 하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. -추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=