From 8fee2a9ae917553a626c6d97fe40c3f3641dd9e4 Mon Sep 17 00:00:00 2001 From: Hoon Jo Date: Sat, 5 Jun 2021 22:56:33 +0900 Subject: [PATCH 01/11] Update assign-pod-node.md Typo issue in Korean --- content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index da30c01ab2b6b..8a7f2ccc7b7ce 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -402,7 +402,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 `nodeName` 은 PodSpec의 필드이다. 만약 비어있지 않으면, 스케줄러는 파드를 무시하고 명명된 노드에서 실행 중인 kubelet이 파드를 실행하려고 한다. 따라서 만약 PodSpec에 `nodeName` 가 -제공된 경우, 노드 선텍을 위해 위의 방법보다 우선한다. +제공된 경우, 노드 선택을 위해 위의 방법보다 우선한다. `nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다. From 1e50590bc4d35139f2da27cf09cbd20d2cfeeedb Mon Sep 17 00:00:00 2001 From: Jerry Park Date: Wed, 9 Jun 2021 18:29:18 +0900 Subject: [PATCH 02/11] [ko] Update outdated files in dev-1.21-ko.4 (p2) --- .../container-runtimes.md | 22 +++-- .../windows/user-guide-windows-containers.md | 93 ++++++++++++++----- .../kubeadm/kubeadm-certs.md | 2 +- 3 files changed, 85 insertions(+), 32 deletions(-) diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index d2638f4433624..7f9885faa0b8d 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -97,7 +97,10 @@ containerd를 설치한다. {{< tabs name="tab-cri-containerd-installation" >}} {{% tab name="Linux" %}} -1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다. 각 리눅스 배포한에 대한 도커 리포지터리를 설정하고 `containerd.io` 패키지를 설치하는 방법은 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다. +1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다. +각 리눅스 배포판에 대한 도커 리포지터리를 설정하고 +`containerd.io` 패키지를 설치하는 방법은 +[도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다. 2. containerd 설정 @@ -115,7 +118,8 @@ containerd를 설치한다. {{% /tab %}} {{% tab name="Windows (PowerShell)" %}} -PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로 설정한 후 다음 명령을 실행한다. +PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로 +설정한 후 다음 명령을 실행한다. 1. containerd 다운로드 @@ -242,7 +246,8 @@ sudo apt-get install cri-o cri-o-runc {{% tab name="Ubuntu" %}} -다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 아래의 표에서 적절한 필드로 설정한다. +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 +아래의 표에서 적절한 필드로 설정한다. | 운영 체제 | `$OS` | | ---------------- | ----------------- | @@ -277,7 +282,8 @@ apt-get install cri-o cri-o-runc {{% tab name="CentOS" %}} -다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 아래의 표에서 적절한 필드로 설정한다. +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 +아래의 표에서 적절한 필드로 설정한다. | 운영 체제 | `$OS` | | ---------------- | ----------------- | @@ -357,7 +363,10 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로 ### 도커 -1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라 리눅스 배포판용 도커를 설치한다. 이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서 검증된 최신 버전의 도커를 찾을 수 있다. +1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라 +리눅스 배포판용 도커를 설치한다. +이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서 +검증된 최신 버전의 도커를 찾을 수 있다. 2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다. @@ -376,7 +385,8 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로 ``` {{< note >}} - `overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다. + `overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL + 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다. {{< /note >}} 3. 도커 재시작과 부팅시 실행되게 설정 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 aabc838ea56ab..3567d287f4d18 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 @@ -6,7 +6,8 @@ weight: 75 -많은 조직에서 실행하는 서비스와 애플리케이션의 상당 부분이 윈도우 애플리케이션으로 구성된다. 이 가이드는 쿠버네티스에서 윈도우 컨테이너를 구성하고 배포하는 단계를 안내한다. +많은 조직에서 실행하는 서비스와 애플리케이션의 상당 부분이 윈도우 애플리케이션으로 구성된다. +이 가이드는 쿠버네티스에서 윈도우 컨테이너를 구성하고 배포하는 단계를 안내한다. @@ -19,12 +20,18 @@ weight: 75 ## 시작하기 전에 -* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다. -* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다. +* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 +포함한 쿠버네티스 클러스터를 생성한다. +* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 +모두 비슷한 방식이라는 것이 중요하다. +[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. +아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다. ## 시작하기: 윈도우 컨테이너 배포하기 -쿠버네티스에서 윈도우 컨테이너를 배포하려면, 먼저 예시 애플리케이션을 생성해야 한다. 아래 예시 YAML 파일은 간단한 웹서버 애플리케이션을 생성한다. 아래 내용으로 채운 서비스 스펙을 `win-webserver.yaml`로 생성하자. +쿠버네티스에서 윈도우 컨테이너를 배포하려면, 먼저 예시 애플리케이션을 생성해야 한다. +아래 예시 YAML 파일은 간단한 웹서버 애플리케이션을 생성한다. +아래 내용으로 채운 서비스 스펙을 `win-webserver.yaml`로 생성하자. ```yaml apiVersion: v1 @@ -71,7 +78,8 @@ spec: ``` {{< note >}} -포트 매핑도 지원하지만, 간략한 예시를 위해 컨테이너 포트 80을 직접 서비스로 노출한다. +포트 매핑도 지원하지만, 간략한 예시를 위해 +컨테이너 포트 80을 직접 서비스로 노출한다. {{< /note >}} 1. 모든 노드가 건강한지 확인한다. @@ -93,51 +101,85 @@ spec: * 윈도우 노드에 파드당 두 컨테이너, `docker ps`를 사용한다. * 리눅스 마스터에서 나열된 두 파드, `kubectl get pods`를 사용한다. - * 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다. - * 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 핑(ping)한다(윈도우 노드를 여럿가지고 있다면 호스트를 달리하며). - * 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 IP 주소(`kubectl get services`로 보여지는)로 실행한다. + * 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을 + 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다. + * 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 + 핑(ping)한다(윈도우 노드를 여럿 가지고 있다면 호스트를 달리하며). + * 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 + IP 주소(`kubectl get services`로 보여지는)로 실행한다. * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다. * 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다. * 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다. {{< note >}} -윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다. +윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. +윈도우 파드만 서비스 IP 주소로 접근할 수 있다. {{< /note >}} ## 가시성 ### 워크로드에서 로그 캡쳐하기 -로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을 파악할 수 있도록 하며 문제 해결의 핵심 요소이다. 윈도우 컨테이너와 워크로드 내의 윈도우 컨테이너가 리눅스 컨테이너와는 다르게 동작하기 때문에, 사용자가 로그를 수집하는 데 어려움을 겪었기에 운영 가시성이 제한되었다. 예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나 애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다. Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)는 윈도우 컨테이너 안에 구성된 로그 소스를 모니터링하는 권장하는 방법이다. LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고 `kubectl logs ` 에 의한 사용을 위해 STDOUT으로 파이프한다. +로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을 +파악할 수 있도록 하며 문제 해결의 핵심 요소이다. +윈도우 컨테이너와 워크로드 내의 윈도우 컨테이너가 리눅스 컨테이너와는 다르게 동작하기 때문에, +사용자가 로그를 수집하는 데 어려움을 겪었기에 운영 가시성이 제한되었다. +예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나 +애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다. +Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)는 +윈도우 컨테이너 안에 구성된 로그 소스를 모니터링하는 권장하는 방법이다. +LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고 +`kubectl logs ` 에 의한 사용을 위해 STDOUT으로 파이프한다. -LogMonitor Github 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고, LogMonitor에 필요한 입력 지점을 추가해서 로그를 STDOUT으로 푸시한다. +LogMonitor Github 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고, +LogMonitor에 필요한 입력 지점을 추가해서 로그를 STDOUT으로 푸시한다. ## 설정 가능한 컨테이너 username 사용하기 -쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. [여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다. +쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 +실행하도록 설정할 수 있다. +이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. +[여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다. ## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기 -쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. 윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자. +쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. +그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, +단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. +GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. +윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자. ## 테인트(Taint)와 톨러레이션(Toleration) -오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와 노드 셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. +오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와 +노드 셀렉터(nodeSelector)의 조합을 이용해야 한다. +이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, +이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. ### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기 -사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다. 오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다. +사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다. +오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다. * kubernetes.io/os = [windows|linux] * kubernetes.io/arch = [amd64|arm64|...] -파드 사양에 노드 셀렉터를 `"kubernetes.io/os": windows`와 같이 지정하지 않았다면, 그 파드는 리눅스나 윈도우, 아무 호스트에나 스케줄링될 수 있다. 윈도우 컨테이너는 윈도우에서만 운영될 수 있고 리눅스 컨테이너는 리눅스에서만 운영될 수 있기 때문에 이는 문제를 일으킬 수 있다. 가장 좋은 방법은 노드 셀렉터를 사용하는 것이다. +파드 사양에 노드 셀렉터를 `"kubernetes.io/os": windows`와 같이 지정하지 않았다면, +그 파드는 리눅스나 윈도우, 아무 호스트에나 스케줄링될 수 있다. +윈도우 컨테이너는 윈도우에서만 운영될 수 있고 리눅스 컨테이너는 리눅스에서만 운영될 수 있기 때문에 이는 문제를 일으킬 수 있다. +가장 좋은 방법은 노드 셀렉터를 사용하는 것이다. -그러나 많은 경우 사용자는 이미 존재하는 대량의 리눅스 컨테이너용 디플로이먼트를 가지고 있을 뿐만 아니라, 헬름(Helm) 차트 커뮤니티 같은 상용 구성의 에코시스템이나, 오퍼레이터(Operator) 같은 프로그래밍 방식의 파드 생성 사례가 있음을 알고 있다. 이런 상황에서는 노드 셀렉터를 추가하는 구성 변경을 망설일 수 있다. 이에 대한 대안은 테인트를 사용하는 것이다. Kubelet은 등록하는 동안 테인트를 설정할 수 있기 때문에, 윈도우에서만 운영할 때에 자동으로 테인트를 추가하기 쉽다. +그러나 많은 경우 사용자는 이미 존재하는 대량의 리눅스 컨테이너용 디플로이먼트를 가지고 있을 뿐만 아니라, +헬름(Helm) 차트 커뮤니티 같은 상용 구성의 에코시스템이나, 오퍼레이터(Operator) 같은 프로그래밍 방식의 파드 생성 사례가 있음을 알고 있다. +이런 상황에서는 노드 셀렉터를 추가하는 구성 변경을 망설일 수 있다. +이에 대한 대안은 테인트를 사용하는 것이다. Kubelet은 등록하는 동안 테인트를 설정할 수 있기 때문에, +윈도우에서만 운영할 때에 자동으로 테인트를 추가하기 쉽다. 예를 들면, `--register-with-taints='os=windows:NoSchedule'` -모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). 윈도우 파드가 윈도우 노드에 스케줄링되려면, 윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다. +모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). +윈도우 파드가 윈도우 노드에 스케줄링되려면, +윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다. ```yaml nodeSelector: @@ -155,11 +197,11 @@ tolerations: 파드에서 사용하는 윈도우 서버 버전은 노드 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우 서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야만 한다. -쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가 한다. 만약 이전 버전을 -실행 중인 경우 이 레이블을 윈도우 노드에 수동으로 추가하는 것을 권장한다. +쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가 한다. +만약 이전 버전을 실행 중인 경우, 이 레이블을 윈도우 노드에 수동으로 추가하는 것을 권장한다. -이 레이블은 호환성을 일치해야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다. 여기에 현재 -사용하는 각 윈도우 서버 버전이 있다. +이 레이블은 호환성을 일치해야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다. +여기에 현재 사용하는 각 윈도우 서버 버전이 있다. | 제품 이름 | 빌드 번호 | |--------------------------------------|------------------------| @@ -170,11 +212,12 @@ tolerations: ### RuntimeClass로 단순화 -[RuntimeClass] 를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다. 클러스터 관리자는 -이 테인트와 톨러레이션을 캡슐화하는데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다. +[RuntimeClass]를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다. +클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다. -1. 이 파일을 `runtimeClasses.yml` 로 저장한다. 여기에는 윈도우 OS, 아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되었다. +1. 이 파일을 `runtimeClasses.yml` 로 저장한다. 여기에는 윈도우 OS, +아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되었다. ```yaml apiVersion: node.k8s.io/v1 diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 02b2b1330f95d..40e05d0f5c126 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -238,7 +238,7 @@ serverTLSBootstrap: true `serverTLSBootstrap: true` 필드는 kubelet 인증서를 이용한 부트스트랩을 `certificates.k8s.io` API에 요청함으로써 활성화할 것이다. 한 가지 알려진 제약은 이 인증서들에 대한 CSR(인증서 서명 요청)들이 kube-controller-manager - -[`kubernetes.io/kubelet-serving`](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)의 +[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)의 기본 서명자(default signer)에 의해서 자동으로 승인될 수 없다는 점이다. 이것은 사용자나 제 3의 컨트롤러의 액션을 필요로 할 것이다. From 94b1fd0c11eac546dd78d630ff9d5ef520b2b677 Mon Sep 17 00:00:00 2001 From: Hyungseok Lee Date: Wed, 9 Jun 2021 17:34:44 +0900 Subject: [PATCH 03/11] Translate concept/policy/node-resource-managers.md into Korean(Fix Squash Task) --- .../concepts/policy/node-resource-managers.md | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 content/ko/docs/concepts/policy/node-resource-managers.md diff --git a/content/ko/docs/concepts/policy/node-resource-managers.md b/content/ko/docs/concepts/policy/node-resource-managers.md new file mode 100644 index 0000000000000..fb3e5f46f563a --- /dev/null +++ b/content/ko/docs/concepts/policy/node-resource-managers.md @@ -0,0 +1,22 @@ +--- + + + +title: 노드 리소스 매니저 +content_type: 개념 +weight: 50 +--- + + + +쿠버네티스는 지연 시간에 민감하고 처리량이 많은 워크로드를 지원하기 위해 리소스 매니저 세트를 제공한다. 매니저는 CPU, 장치 및 메모리 (hugepages) 리소스와 같은 특정한 요구 사항으로 구성된 파드를 위해 노드의 리소스 할당을 조정하고 최적화하는 것을 목표로 한다. + + + +주 매니저인 토폴로지 매니저는 [정책](/docs/tasks/administer-cluster/topology-manager/)을 통해 전체 리소스 관리 프로세스를 조정하는 Kubelet 컴포넌트이다. + +개별 매니저의 구성은 다음의 문서에 자세히 기술되어 있다. + +- [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/) +- [장치 매니저](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#토폴로지-관리자와-장치-플러그인-통합) +- [메모리 관리 정책](/docs/tasks/administer-cluster/memory-manager/) From 38291299bef71915868ea24c5fb71188fde8d33e Mon Sep 17 00:00:00 2001 From: kiyeongkil Date: Wed, 9 Jun 2021 23:36:27 +0900 Subject: [PATCH 04/11] Translate concepts/scheduling-eviction/api-eviction into Korean --- .../scheduling-eviction/api-eviction.md | 18 +++++++++++++++ .../docs/reference/glossary/api-eviction.md | 23 +++++++++++++++++++ 2 files changed, 41 insertions(+) create mode 100644 content/ko/docs/concepts/scheduling-eviction/api-eviction.md create mode 100644 content/ko/docs/reference/glossary/api-eviction.md diff --git a/content/ko/docs/concepts/scheduling-eviction/api-eviction.md b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md new file mode 100644 index 0000000000000..53724320b010a --- /dev/null +++ b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md @@ -0,0 +1,18 @@ +--- +title: API를 이용한 축출(Eviction) +content_type: concept +weight: 70 +--- + +{{< glossary_definition term_id="api-eviction" length="short" >}}
+ +`kubectl drain` 명령과 같은 kube-apiserver의 클라이언트를 사용하여, +축출 API를 직접 호출해 축출 요청을 할 수 있다. +그러면 API 서버가 파드를 종료하는 `Eviction` 오브젝트가 생성된다. + +API를 이용한 축출은 구성된 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 [`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 준수한다. + +## {{% heading "whatsnext" %}} + +- [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기 +- [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 더 배우기 diff --git a/content/ko/docs/reference/glossary/api-eviction.md b/content/ko/docs/reference/glossary/api-eviction.md new file mode 100644 index 0000000000000..f8a65c606eb49 --- /dev/null +++ b/content/ko/docs/reference/glossary/api-eviction.md @@ -0,0 +1,23 @@ +--- +title: API를 이용한 축출(Eviction) +id: api-eviction +date: 2021-04-27 +full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction +short_description: > + API를 이용한 축출은 축출 API를 사용하여 파드의 정상 종료를 트리거하는 + 축출 오브젝트를 만드는 프로세스이다 +aka: +tags: + - operation +--- + +API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core)를 사용하여 +생성된 `Eviction` 오브젝트로 파드를 정상 종료한다. + + + +`kubectl drain` 명령과 같은 kube-apiserver의 클라이언트를 사용하여 +축출 API를 직접 호출해 축출 요청을 할 수 있다. +`Eviction` 오브젝트가 생성되면, API 서버가 파드를 종료한다. + +API를 이용한 축출은 [노드-압박 축출](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)과 동일하지 않다. From 858e73a417daee200f9436bc37ba349eb8405cec Mon Sep 17 00:00:00 2001 From: Jerry Park Date: Fri, 11 Jun 2021 19:23:00 +0900 Subject: [PATCH 05/11] Apply suggestions from code review Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> --- .../container-runtimes.md | 4 +- .../windows/user-guide-windows-containers.md | 52 +++++++++---------- 2 files changed, 28 insertions(+), 28 deletions(-) diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 7f9885faa0b8d..fb749a23464e5 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -118,8 +118,8 @@ containerd를 설치한다. {{% /tab %}} {{% tab name="Windows (PowerShell)" %}} -PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로 -설정한 후 다음 명령을 실행한다. +PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로 +설정(예: `$Version:1.4.3`)한 후 다음 명령을 실행한다. 1. containerd 다운로드 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 3567d287f4d18..9875b8426ef16 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 @@ -25,7 +25,7 @@ weight: 75 * 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. -아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다. +아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다. ## 시작하기: 윈도우 컨테이너 배포하기 @@ -99,17 +99,17 @@ spec: 1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자. - * 윈도우 노드에 파드당 두 컨테이너, `docker ps`를 사용한다. - * 리눅스 마스터에서 나열된 두 파드, `kubectl get pods`를 사용한다. - * 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을 + * 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다. + * 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다. + * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다. - * 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 - 핑(ping)한다(윈도우 노드를 여럿 가지고 있다면 호스트를 달리하며). - * 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 - IP 주소(`kubectl get services`로 보여지는)로 실행한다. - * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다. - * 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다. - * 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다. + * 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 + 핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다). + * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 + IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다. + * 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다. + * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다. + * 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다. {{< note >}} 윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. @@ -122,8 +122,8 @@ spec: 로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을 파악할 수 있도록 하며 문제 해결의 핵심 요소이다. -윈도우 컨테이너와 워크로드 내의 윈도우 컨테이너가 리눅스 컨테이너와는 다르게 동작하기 때문에, -사용자가 로그를 수집하는 데 어려움을 겪었기에 운영 가시성이 제한되었다. +윈도우 컨테이너, 그리고 윈도우 컨테이너 내의 워크로드는 리눅스 컨테이너와는 다르게 동작하기 때문에, +사용자가 로그를 수집하기 어려웠고 이로 인해 운영 가시성이 제한되어 왔다. 예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나 애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다. Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)는 @@ -131,8 +131,8 @@ Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/w LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고 `kubectl logs ` 에 의한 사용을 위해 STDOUT으로 파이프한다. -LogMonitor Github 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고, -LogMonitor에 필요한 입력 지점을 추가해서 로그를 STDOUT으로 푸시한다. +LogMonitor GitHub 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고, +LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리포인트를 추가한다. ## 설정 가능한 컨테이너 username 사용하기 @@ -151,14 +151,14 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동 ## 테인트(Taint)와 톨러레이션(Toleration) -오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와 -노드 셀렉터(nodeSelector)의 조합을 이용해야 한다. +오늘날 사용자는 리눅스와 윈도우 워크로드를 (동일한 OS를 실행하는) 적절한 노드에 할당되도록 하기 위해 테인트와 +노드셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. ### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기 -사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다. +사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다. 오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다. * kubernetes.io/os = [windows|linux] @@ -194,14 +194,14 @@ tolerations: ### 동일 클러스터에서 여러 윈도우 버전을 조작하는 방법 -파드에서 사용하는 윈도우 서버 버전은 노드 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우 -서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야만 한다. +파드에서 사용하는 윈도우 서버 버전은 노드의 윈도우 서버 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우 +서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야 한다. -쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가 한다. +쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가한다. 만약 이전 버전을 실행 중인 경우, 이 레이블을 윈도우 노드에 수동으로 추가하는 것을 권장한다. -이 레이블은 호환성을 일치해야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다. -여기에 현재 사용하는 각 윈도우 서버 버전이 있다. +이 레이블은 호환성을 위해 일치시켜야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다. +각 윈도우 서버 버전에 대해 현재 사용하고 있는 빌드 번호는 다음과 같다. | 제품 이름 | 빌드 번호 | |--------------------------------------|------------------------| @@ -212,12 +212,12 @@ tolerations: ### RuntimeClass로 단순화 -[RuntimeClass]를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다. -클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다. +[런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다. +클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는 데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다. 1. 이 파일을 `runtimeClasses.yml` 로 저장한다. 여기에는 윈도우 OS, -아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되었다. +아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되어 있다. ```yaml apiVersion: node.k8s.io/v1 From cacad0e02e421113b2f548d2682aa5badc965184 Mon Sep 17 00:00:00 2001 From: seokho-son Date: Sat, 12 Jun 2021 18:02:48 +0900 Subject: [PATCH 06/11] Update outdated files in dev-1.21-ko.4 (p1) --- .../compute-storage-net/device-plugins.md | 6 ++++-- .../concepts/services-networking/network-policies.md | 5 +++-- .../ko/docs/concepts/workloads/pods/disruptions.md | 1 + .../command-line-tools-reference/kube-proxy.md | 2 +- content/ko/docs/reference/scheduling/config.md | 12 ++++++------ 5 files changed, 15 insertions(+), 11 deletions(-) diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 3596c9f72e411..13313adf581a1 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -192,6 +192,7 @@ kubelet은 gRPC 서비스를 제공하여 사용 중인 장치를 검색하고, // PodResourcesLister는 kubelet에서 제공하는 서비스로, 노드의 포드 및 컨테이너가 // 사용한 노드 리소스에 대한 정보를 제공한다. service PodResourcesLister { + rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {} rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {} } ``` @@ -252,7 +253,7 @@ message AllocatableResourcesResponse { `ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다. NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은 -[kubelet에 등록할 때](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) 장치 플러그인이 보고하는 것과 일치한다. +[kubelet에 등록할 때](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#토폴로지-관리자로-장치-플러그인-통합) 장치 플러그인이 보고하는 것과 일치한다. gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 소켓을 통해 제공된다. @@ -264,8 +265,9 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 {{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다. `PodResourcesLister service` 를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +이것은 쿠버네티스 1.15부터 기본으로 활성화되어 있으며, 쿠버네티스 1.20부터는 v1 상태이다. -## 토폴로지 관리자와 장치 플러그인 통합 +## 토폴로지 관리자로 장치 플러그인 통합 {{< feature-state for_k8s_version="v1.18" state="beta" >}} diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index c68d6f2862d82..5a9b16a3097bf 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -212,9 +212,10 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ## SCTP 지원 -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.20" state="stable" >}} -베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다. +안정된 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다. +해당 기능 게이트가 활성화되어 있는 경우, 네트워크폴리시의 `protocol` 필드를 `SCTP`로 지정할 수 있다. {{< note >}} SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index 02730d4306d33..e9263d6461897 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -89,6 +89,7 @@ weight: 60 파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/configuration/pod-priority-preemption/)와 같은 특정 환경설정 옵션 또한 자발적(+ 비자발적) 중단을 유발할 수 있다. + ## 파드 disruption budgets {{< feature-state for_k8s_version="v1.21" state="stable" >}} diff --git a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md index eab89638dbe6f..29e9deee83e94 100644 --- a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md @@ -424,7 +424,7 @@ kube-proxy [flags] --show-hidden-metrics-for-version string -

숨겨진 메트릭을 표시할 이전 버전. 이전 마이너 버전만 인식하며, 다른 값은 허용하지 않는다. '1.16' 형태로 사용한다. 이 옵션의 존재 목적은, 다음 릴리스에서 추가적인 메트릭을 숨기는지에 대한 여부를 사용자가 알게 하여, 그 이후 릴리스에서 메트릭이 영구적으로 삭제됐을 때 사용자가 놀라지 않도록 하기 위함이다.

+

숨겨진 메트릭을 표시하려는 이전 버전. 이전 마이너 버전만 인식하며, 다른 값은 허용하지 않는다. 포멧은 <메이저>.<마이너> 와 같으며, 예를 들면 '1.16' 과 같다. 이 포멧의 목적은, 다음 릴리스가 숨길 추가적인 메트릭을 사용자에게 공지하여, 그 이후 릴리스에서 메트릭이 영구적으로 삭제됐을 때 사용자가 놀라지 않도록 하기 위함이다.

diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md index 5da54ed813bba..2f46c78d8bd1b 100644 --- a/content/ko/docs/reference/scheduling/config.md +++ b/content/ko/docs/reference/scheduling/config.md @@ -18,9 +18,9 @@ weight: 20 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다. -[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) -구조에 맞게 파일을 작성하고, -`kube-scheduler --config `을 실행하여 +[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +구조에 맞게 파일을 작성하고, +`kube-scheduler --config `을 실행하여 스케줄링 프로파일을 지정할 수 있다. 최소 구성은 다음과 같다. @@ -149,8 +149,8 @@ profiles: 또는 바인딩할 수 있는지 확인한다. 익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`. {{< note >}} - `Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이 - 활성화되어 있어야 활성화되며, + `Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이 + 활성화되어 있어야 활성화되며, 요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매긴다. {{< /note >}} - `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한 @@ -250,6 +250,6 @@ profiles: ## {{% heading "whatsnext" %}} -* [kube-scheduler 레퍼런스](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 +* [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기 * [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기 From 191506a9f8d60b7df383f844898d519a03726258 Mon Sep 17 00:00:00 2001 From: seokho-son Date: Sun, 13 Jun 2021 01:50:28 +0900 Subject: [PATCH 07/11] Fix ko extend-kubernetes --- content/ko/docs/concepts/extend-kubernetes/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index f93537bf6253a..95c61079dd12a 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -21,7 +21,7 @@ no_list: true 조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다. 잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 어떤 익스텐션(extension) 포인트와 패턴이 있는지, -그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다. +그리고 그것의 트레이드오프와 제약을 이해하는 데 도움이 될 것이다. @@ -143,7 +143,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ### 인가 -[인가](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. +[인가](/docs/reference/access-authn-authz/webhook/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. ### 동적 어드미션 컨트롤 From 6a3ea501e02541c678412b8f5d6e60bcbda4bd4b Mon Sep 17 00:00:00 2001 From: seokho-son Date: Sun, 13 Jun 2021 02:18:28 +0900 Subject: [PATCH 08/11] Enhance ko/docs/setup/../certificates translation --- content/ko/docs/setup/best-practices/certificates.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index 77665edbe27fa..e567e90b22448 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -1,23 +1,23 @@ --- -title: PKI 인증서 및 요구 조건 +title: PKI 인증서 및 요구 사항 content_type: concept weight: 40 --- -쿠버네티스는 TLS 위에 인증을 위해 PKI 인증서가 필요하다. -만약 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 쿠버네티스를 설치했다면, 클러스터에 필요한 인증서는 자동으로 생성된다. +쿠버네티스는 TLS를 통한 인증을 위해서 PKI 인증서가 필요하다. +만약 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 쿠버네티스를 설치한다면, 클러스터에 필요한 인증서는 자동으로 생성된다. 또한 더 안전하게 자신이 소유한 인증서를 생성할 수 있다. 이를 테면, 개인키를 API 서버에 저장하지 않으므로 더 안전하게 보관할 수 있다. -이 페이지는 클러스터에 필요한 인증서를 설명한다. +이 페이지는 클러스터가 필요로 하는 인증서에 대해서 설명한다. -## 클러스터에서 인증서는 어떻게 이용되나? +## 클러스터에서 인증서가 이용되는 방식 -쿠버네티스는 다음 작업에서 PKI가 필요하다. +쿠버네티스는 다음 작업에서 PKI를 필요로 한다. * kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서 * API 서버 엔드포인트를 위한 서버 인증서 From fa912fe62e8e5b8e6f31a6c1482328f9bc248723 Mon Sep 17 00:00:00 2001 From: mylovepooh Date: Mon, 7 Jun 2021 17:55:27 +0900 Subject: [PATCH 09/11] Translate concepts/services-networking/service-traffic-policy in Korean --- .../service-traffic-policy.md | 73 +++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 content/ko/docs/concepts/services-networking/service-traffic-policy.md diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md new file mode 100644 index 0000000000000..5f9d394718b46 --- /dev/null +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -0,0 +1,73 @@ +--- + + +title: 서비스 내부 트래픽 정책 +content_type: concept +weight: 45 +--- + + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +_서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이 트래픽이 시작된 +노드 내의 엔드포인트로만 내부 트래픽을 라우팅하도록 한다. +여기서 "내부" 트래픽은 현재 클러스터의 파드로부터 시작된 트래픽을 지칭한다. +이를 통해 비용을 절감하고 성능을 개선할 수 있다. + + + +## 서비스 내부 트래픽 정책 사용 + + +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서 +`ServiceInternalTrafficPolicy`를 활성화한 후에 +{{< glossary_tooltip text="서비스" term_id="service" >}}의 +`.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다. +이것은 kube-proxy가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다. + +{{< note >}} +지정된 서비스에 대한 엔드포인트가 없는 노드의 파드인 경우에 +서비스는 다른 노드에 엔드포인트가 있더라도 엔드포인트가 없는 것처럼 작동한다. +(이 노드의 파드에 대해서) +{{< /note >}} + +다음 예제는 서비스의 `.spec.internalTrafficPolicy`를 `Local`로 +설정하는 것을 보여 준다: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + internalTrafficPolicy: Local +``` + +## 작동 방식 + +kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되는 +엔드포인트를 필터링한다. +이것을 `Local`로 설정하면, 노드 내부 엔드포인트만 고려한다. +이 설정이 `Cluster`이거나 누락되었다면 모든 엔드포인트를 고려한다. +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 +`ServiceInternalTrafficPolicy`를 활성화한다면, `spec.internalTrafficPolicy`는 기본값 "Cluster"로 설정된다. + +## 제약조건 + +* 같은 서비스에서 `externalTrafficPolicy` 가 `Local`로 설정된 경우 +서비스 내부 트래픽 정책이 사용되지 않는다. +클러스터에서 동일하지 않은 다른 서비스에서 이 두 가지 기능은 동시에 사용할 수 있다. + +## {{% heading "whatsnext" %}} + +* [토폴로지 인식 힌트 활성화](/docs/tasks/administer-cluster/enabling-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/) 읽기 From 80a84f68a0ce0a1f9ec7111592b1a836c19b6603 Mon Sep 17 00:00:00 2001 From: seokho-son Date: Sun, 13 Jun 2021 03:04:26 +0900 Subject: [PATCH 10/11] Enhance ko/services/source-ip translation --- .../ko/docs/tutorials/services/source-ip.md | 23 +++++++++---------- 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 6874d6669b858..7300b0661556b 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -6,10 +6,10 @@ min-kubernetes-server-version: v1.5 -쿠버네티스 클러스터에서 실행 중인 애플리케이션은 서로 간에 외부 세계와 -서비스 추상화를 통해 찾고 통신한다. 이 문서는 -다른 종류의 서비스로 보내진 패킷의 소스 IP 주소에 어떤 일이 벌어지는지와 -이 동작을 요구에 따라 토글할 수 있는지 설명한다. +쿠버네티스 클러스터에서 실행 중인 애플리케이션은 서비스 추상화를 통해서 +서로를, 그리고 외부 세계를 찾고 통신한다. 이 문서는 +다른 종류의 서비스로 전송된 패킷의 소스 IP에 어떤 일이 벌어지는지와 +이 동작을 필요에 따라 어떻게 전환할 수 있는지 설명한다. @@ -29,16 +29,16 @@ min-kubernetes-server-version: v1.5 : 네트워크 주소 변환 [소스 NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT) -: 패킷 상의 소스 IP 주소를 변경함, 보통 노드의 IP 주소 +: 패킷 상의 소스 IP 주소를 변경하는 것. 이 페이지에서는 일반적으로 노드 IP 주소로의 변경을 의미함. [대상 NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT) -: 패킷 상의 대상 IP 주소를 변경함, 보통 파드의 IP 주소 +: 패킷 상의 대상 IP 주소를 변경하는 것. 이 페이지에서는 일반적으로 {{< glossary_tooltip term_id="pod" text="파드" >}} IP 주소로의 변경을 의미함. [VIP](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시) -: 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은 +: 쿠버네티스의 모든 {{< glossary_tooltip text="서비스" term_id="service" >}}에 할당되어 있는 것과 같은, 가상 IP 주소. [Kube-proxy](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시) -: 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다. +: 모든 노드에서 서비스 VIP 관리를 조율하는 네트워크 데몬. ### 전제 조건 @@ -80,7 +80,7 @@ deployment.apps/source-ip-app created ```console kubectl get nodes ``` -출력은 다음과 유사하다 +출력은 다음과 유사하다. ``` NAME STATUS ROLES AGE VERSION kubernetes-node-6jst Ready 2h v1.13.0 @@ -220,7 +220,6 @@ graph LR; class client plain; {{}} - 이를 피하기 위해 쿠버네티스는 [클라이언트 소스 IP 주소를 보존](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)하는 기능이 있다. `service.spec.externalTrafficPolicy` 의 값을 `Local` 로 하면 @@ -439,5 +438,5 @@ kubectl delete deployment source-ip-app ## {{% heading "whatsnext" %}} -* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 더 자세히 본다. -* 어떻게 [외부 로드밸런서 생성](/docs/tasks/access-application-cluster/create-external-load-balancer/)하는지 본다. +* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 더 자세히 본다. +* [외부 로드밸런서 생성](/docs/tasks/access-application-cluster/create-external-load-balancer/) 방법을 본다. From 620cdbb677aec8727a26d6f659847535f11daacd Mon Sep 17 00:00:00 2001 From: seokho-son Date: Sun, 13 Jun 2021 01:08:12 +0900 Subject: [PATCH 11/11] Add setup/pro../turnkey-solutions.md to Korean --- .../production-environment/turnkey-solutions.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 content/ko/docs/setup/production-environment/turnkey-solutions.md diff --git a/content/ko/docs/setup/production-environment/turnkey-solutions.md b/content/ko/docs/setup/production-environment/turnkey-solutions.md new file mode 100644 index 0000000000000..2feb5de30a15c --- /dev/null +++ b/content/ko/docs/setup/production-environment/turnkey-solutions.md @@ -0,0 +1,14 @@ +--- +title: 턴키 클라우드 솔루션 +content_type: concept +weight: 30 +--- + + +이 페이지는 인증된 쿠버네티스 솔루션 제공자 목록을 제공한다. 각 제공자 +페이지를 통해서, 프로덕션에 준비된 클러스터를 설치 및 설정하는 방법을 +학습할 수 있다. + + + +{{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}}