Merge pull request #31637 from kubernetes/dev-1.23-ko.1

[ko] 1st Korean localization work for v1.23

Author: k8s-ci-robot

content/ko/_index.html

@@ -30,7 +30,7 @@
 {{% blocks/feature image="suitcase" %}}
 #### K8s를 어디서나 실행
 
-쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다.
+쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는 데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다.
 
 {{% /blocks/feature %}}
 

content/ko/community/_index.html

@@ -19,6 +19,7 @@
 
 <div class="community__navbar">
 
+<a href="https://www.kubernetes.dev/">기여자 커뮤니티</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#values">커뮤니티 가치</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#conduct">행동 강령 </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#videos">비디오</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

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. 노드의 호스트 이름과 네트워크 주소를 가져온다.

content/ko/docs/concepts/architecture/cri.md

@@ -0,0 +1,50 @@
+---
+title: 컨테이너 런타임 인터페이스(CRI)
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+
+컨테이너 런타임 인터페이스(CRI)는 클러스터 컴포넌트를 다시 컴파일하지 않아도 Kubelet이 다양한 
+컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스다.
+
+클러스터의 모든 노드에 동작 중인
+{{<glossary_tooltip text="컨테이너 런타임" term_id="container-runtime">}}이 존재해야, 
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이
+{{< glossary_tooltip text="파드" term_id="pod" >}}들과 컨테이너들을 
+구동할 수 있다.
+
+{{< glossary_definition term_id="container-runtime-interface" length="all" >}}
+
+<!-- body -->
+
+## 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)를 자세히 알아보자.

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`를 구성할 수 있으며, 
 이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면,
 

content/ko/docs/concepts/cluster-administration/addons.md

@@ -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/) 또는 
+  [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition) 형태로 보고한다.
 
 ## 레거시 애드온
 

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 주소를 제공한다.
@@ -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/)은