Sixth Korean l10n work for release-1.19

- fix Korean translation of 'object' (#25370) - Update outdated files in the dev-1.19-ko.6 branch (2) (#25403) - Translate setup/release/version-skew-policy.md in Korean (#25345) - Translate tutorials/configuration/configure-java-microservice/configure-java-microservice/ into Korean (#24981) - Translate health-checks.md into Korean (#25342) - Translate reference/glossary/api-group.md in Korean (#25321) - Translate reference/glossary/object.md in Korean (#25318) - Translate tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/ into Korean (#24984) - switch New York Times case study to use youtube shortcode (ko) (#25287) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: mylovepooh <jun8414@gmail.com> Co-authored-by: jmkim <jm1223.kim@samsung.com> Co-authored-by: santachopa <santachopa@naver.com> Co-authored-by: Arhell <arhell333@gmail.com>
2020-11-28 02:58:25 +02:00
parent c4c17a9b8a
commit dd950df8bd
55 changed files with 760 additions and 545 deletions
@@ -93,8 +93,7 @@ weight: 30
 현재 상태를 보다 가깝게 만든다.

 (실제로 클러스터의 노드를 수평으로 확장하는
-컨트롤러가 있다.
-[클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 본다.)
+[컨트롤러](https://github.com/kubernetes/autoscaler/)가 있다.)

 여기서 중요한 점은 컨트롤러가 의도한 상태를 가져오기 위해 약간의 변화를 주고,
 현재 상태를 클러스터의 API 서버에 다시 보고한다는 것이다.
@@ -335,4 +335,3 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 * 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
  섹션을 읽어본다.
 * [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.
-* [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다.
@@ -35,8 +35,6 @@ no_list: true

 ## 클러스터 관리

-* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터 라이프사이클과 관련된 몇 가지 주제를 설명한다. 새로운 클러스터 생성, 클러스터의 마스터 및 워커 노드 업그레이드, 노드 유지 관리 수행(예: 커널 업그레이드) 및 실행 중인 클러스터의 쿠버네티스 API 버전 업그레이드
-
 * [노드 관리](/ko/docs/concepts/architecture/nodes/) 방법을 배운다.

 * 공유 클러스터에 대한 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 설정하고 관리하는 방법을 배운다.
@@ -25,6 +25,7 @@ content_type: concept
 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
 * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
 * [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다.
+* [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 플랫폼 간의 통합을 제공한다.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
@@ -156,6 +156,11 @@ VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브
 수 있다. 즉, cni-ipvlan-vpc-k8s는 AWS 내에서 쿠버네티스를
 대규모로 배포하는 데 필요한 네트워크 복잡성을 크게 줄인다.

+### Coil
+
+[Coil](https://github.com/cybozu-go/coil)은 통합이 용이하도록 설계된 CNI 플러그인으로 유연한 이그레스(egress) 네트워킹을 제공한다.
+Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네트워크에 대해 임의의 이그레스 NAT 게이트웨이를 정의할 수 있다.
+
 ### 콘티브(Contiv)

 [콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](https://contiv.io)는 모두 오픈소스이다.
@@ -88,7 +88,7 @@ data:
 컨피그맵을 사용하여 파드 내부에 컨테이너를 구성할 수 있는
 네 가지 방법이 있다.

-1. 컨테이너의 엔트리포인트에 대한 커맨드 라인 인수
+1. 컨테이너 커맨드와 인수 내에서
 1. 컨테이너에 대한 환경 변수
 1. 애플리케이션이 읽을 수 있도록 읽기 전용 볼륨에 파일 추가
 1. 쿠버네티스 API를 사용하여 컨피그맵을 읽는 파드 내에서 실행할 코드 작성
@@ -318,9 +318,7 @@ spec:
 선점자 대신 우선순위가 높은 파드를 스케줄링한다.

 이것은 예상된 동작이다. 우선순위가 높은 파드는 우선순위가 낮은 파드를
-대체해야 한다. [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)과
-같은 다른 컨트롤러 작업은,
-결국 보류 중인 파드를 스케줄링할 수 있는 용량을 제공할 수 있다.
+대체해야 한다.

 ### 우선순위가 높은 파드는 우선순위가 낮은 파드보다 우선함

@@ -14,7 +14,7 @@ card:
 <!-- body -->
 ## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects}

-*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다.
+*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.

 * 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
 * 그 애플리케이션이 이용할 수 있는 리소스
@@ -189,7 +189,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'

 #### 서비스와 레플리케이션 컨트롤러

-`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
+`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 오브젝트 그룹도 레이블 셀렉터로 정의한다.

 서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.

@@ -74,8 +74,7 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
 | `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음. |
 | `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음. |
 | `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음. |
-| `hugepages-<size>` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의
-휴즈 페이지 요청은 이 값을 초과하지 못함. |
+| `hugepages-<size>` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의 휴즈 페이지 요청은 이 값을 초과하지 못함. |
 | `cpu` | `requests.cpu` 와 같음. |
 | `memory` | `requests.memory` 와 같음. |

@@ -8,125 +8,146 @@ weight: 50

 {{< feature-state for_k8s_version="v1.16" state="alpha" >}}

-kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라 kube-scheduler를 미세 조정할 수 있다.
-
-
+kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서
+확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라
+kube-scheduler를 미세 조정할 수 있다.

 <!-- body -->

 ## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기

-쿠버네티스 1.15 이전에는 Kube-scheduler가 CPU 및 메모리와 같은 리소스의 용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용했다. 쿠버네티스 1.16은 우선 순위 기능에 새로운 파라미터를 추가해서 사용자가 용량 대비 요청 비율을 기반으로 노드에 점수를 매기도록 각 리소스의 가중치와 함께 리소스를 지정할 수 있다. 이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들수 있어 대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 `requestedToCapacityRatioArguments`라는 구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. 셰이프(shape)는 사용자가 `utilization`과 `score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. 리소스는
-점수를 매길 때 고려할 리소스를 지정하는 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로 구성된다.
+쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
+용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를
+통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
+대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
+`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의
+동작은 `requestedToCapacityRatioArguments`라는
+구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources`
+두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과
+`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을
+조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할
+리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로
+구성된다.

-다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 `requestedToCapacityRatioArguments` 를 빈 패킹 동작으로 설정하는 구성의 예시이다.
+다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한
+`requestedToCapacityRatioArguments` 를 빈 패킹 동작으로
+설정하는 구성의 예시이다.

-```json
-{
-    "kind" : "Policy",
-    "apiVersion" : "v1",
-
-    ...
-
-    "priorities" : [
-
-       ...
-
-      {
-        "name": "RequestedToCapacityRatioPriority",
-        "weight": 2,
-        "argument": {
-          "requestedToCapacityRatioArguments": {
-            "shape": [
-              {"utilization": 0, "score": 0},
-              {"utilization": 100, "score": 10}
-            ],
-            "resources": [
-              {"name": "intel.com/foo", "weight": 3},
-              {"name": "intel.com/bar", "weight": 5}
-            ]
-          }
-        }
-      }
-    ],
-  }
+```yaml
+apiVersion: v1
+kind: Policy
+# ...
+priorities:
+  # ...
+  - name: RequestedToCapacityRatioPriority
+    weight: 2
+    argument:
+      requestedToCapacityRatioArguments:
+        shape:
+          - utilization: 0
+            score: 0
+          - utilization: 100
+            score: 10
+        resources:
+          - name: intel.com/foo
+            weight: 3
+          - name: intel.com/bar
+            weight: 5
 ```

 **이 기능은 기본적으로 비활성화되어 있다.**

-### RequestedToCapacityRatioResourceAllocation 우선 순위 기능 튜닝하기
+### 우선 순위 기능 튜닝하기

-`shape` 는 `RequestedToCapacityRatioPriority` 기능의 동작을 지정하는 데 사용된다.
+`shape` 는 `RequestedToCapacityRatioPriority` 기능의
+동작을 지정하는 데 사용된다.

 ```yaml
- {"utilization": 0, "score": 0},
- {"utilization": 100, "score": 10}
+shape:
+ - utilization: 0
+   score: 0
+ - utilization: 100
+   score: 10
 ```

-위의 인수는 사용률이 0%인 경우 점수는 0, 사용률이 100%인 경우 10으로 하여, 빈 패킹 동작을 활성화한다. 최소 요청을 활성화하려면 점수 값을 다음과 같이 변경해야 한다.
+위의 인수는 `utilization` 이 0%인 경우 `score` 는 0, `utilization` 이
+100%인 경우 10으로 하여, 빈 패킹 동작을 활성화한다. 최소 요청을
+활성화하려면 점수 값을 다음과 같이 변경해야 한다.

 ```yaml
- {"utilization": 0, "score": 100},
- {"utilization": 100, "score": 0}
+shape:
+  - utilization: 0
+    score: 100
+  - utilization: 100
+    score: 0
 ```

 `resources` 는 기본적으로 다음과 같이 설정되는 선택적인 파라미터이다.

 ``` yaml
-"resources": [
-              {"name": "CPU", "weight": 1},
-              {"name": "Memory", "weight": 1}
-            ]
+resources:
+  - name: CPU
+    weight: 1
+  - name: Memory
+    weight: 1
 ```

 다음과 같이 확장된 리소스를 추가하는 데 사용할 수 있다.

 ```yaml
-"resources": [
-              {"name": "intel.com/foo", "weight": 5},
-              {"name": "CPU", "weight": 3},
-              {"name": "Memory", "weight": 1}
-            ]
+resources:
+  - name: intel.com/foo
+    weight: 5
+  - name: CPU
+    weight: 3
+  - name: Memory
+    weight: 1
 ```

-가중치 파라미터는 선택 사항이며 지정되지 않은 경우 1로 설정 된다. 또한, 가중치는 음수로 설정할 수 없다.
+`weight` 파라미터는 선택 사항이며 지정되지 않은 경우 1로 설정 된다. 또한,
+`weight` 는 음수로 설정할 수 없다.

-### RequestedToCapacityRatioResourceAllocation 우선 순위 기능이 노드에 점수를 매기는 방법
+### 용량 할당을 위해 노드에 점수 매기기

 이 섹션은 이 기능 내부의 세부적인 사항을 이해하려는 사람들을
 위한 것이다.
 아래는 주어진 값의 집합에 대해 노드 점수가 계산되는 방법의 예시이다.

-```
-Requested Resources
+요청된 리소스는 다음과 같다.

+```
 intel.com/foo : 2
 Memory: 256MB
 CPU: 2
+```

-Resource Weights
+리소스의 가중치는 다음과 같다.

+```
 intel.com/foo : 5
 Memory: 1
 CPU: 3
+```

 FunctionShapePoint {{0, 0}, {100, 10}}

-Node 1 Spec
+노드 1의 사양은 다음과 같다.

+```
 Available:
-intel.com/foo : 4
-Memory : 1 GB
-CPU: 8
+  intel.com/foo: 4
+  Memory: 1 GB
+  CPU: 8

 Used:
-intel.com/foo: 1
-Memory: 256MB
-CPU: 1
+  intel.com/foo: 1
+  Memory: 256MB
+  CPU: 1
+```

+노드 점수는 다음과 같다.

-Node Score:
-
+```
 intel.com/foo  = resourceScoringFunction((2+1),4)
               = (100 - ((4-3)*100/4)
               = (100 - 25)
@@ -148,24 +169,24 @@ CPU            = resourceScoringFunction((2+1),8)

 NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
            =  5
+```

+노드 2의 사양은 다음과 같다.

-Node 2 Spec
-
+```
 Available:
-intel.com/foo: 8
-Memory: 1GB
-CPU: 8
-
+  intel.com/foo: 8
+  Memory: 1GB
+  CPU: 8
 Used:
+  intel.com/foo: 2
+  Memory: 512MB
+  CPU: 6
+```

-intel.com/foo: 2
-Memory: 512MB
-CPU: 6
-
-
-Node Score:
+노드 점수는 다음과 같다.

+```
 intel.com/foo  = resourceScoringFunction((2+2),8)
               =  (100 - ((8-4)*100/8)
               =  (100 - 50)
@@ -189,3 +210,8 @@ NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
            =  7

 ```
+
+## {{% heading "whatsnext" %}}
+
+- [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)에 대해 더 읽어본다.
+- [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 대해 더 읽어본다.
@@ -28,15 +28,15 @@ _톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트
 예를 들면 다음과 같다.

 ```shell
-kubectl taint nodes node1 key=value:NoSchedule
+kubectl taint nodes node1 key1=value1:NoSchedule
 ```

-`node1` 노드에 테인트을 배치한다. 테인트에는 키 `key`, 값 `value` 및 테인트 이펙트(effect) `NoSchedule` 이 있다.
+`node1` 노드에 테인트을 배치한다. 테인트에는 키 `key1`, 값 `value1` 및 테인트 이펙트(effect) `NoSchedule` 이 있다.
 이는 일치하는 톨러레이션이 없으면 파드를 `node1` 에 스케줄할 수 없음을 의미한다.

 위의 명령으로 추가한 테인트를 제거하려면, 다음을 실행한다.
 ```shell
-kubectl taint nodes node1 key:NoSchedule-
+kubectl taint nodes node1 key1=value1:NoSchedule-
 ```

 PodSpec에서 파드에 대한 톨러레이션를 지정한다. 다음의 톨러레이션은
@@ -45,15 +45,15 @@ PodSpec에서 파드에 대한 톨러레이션를 지정한다. 다음의 톨러

 ```yaml
 tolerations:
- key: "key"
+- key: "key1"
  operator: "Equal"
-  value: "value"
+  value: "value1"
  effect: "NoSchedule"
 ```

 ```yaml
 tolerations:
- key: "key"
+- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"
 ```
@@ -76,7 +76,7 @@ tolerations:
 operator `Exists` 가 있는 비어있는 `key` 는 모든 키, 값 및 이펙트와 일치하므로
 모든 것이 톨러레이션 된다.

-비어있는 `effect` 는 모든 이펙트를 키 `key` 와 일치시킨다.
+비어있는 `effect` 는 모든 이펙트를 키 `key1` 와 일치시킨다.

 {{< /note >}}

@@ -110,7 +110,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
 어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.

 어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다.
-어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않는다.
+어드미션 컨트롤러는 단순히 오브젝트를 읽는 요청에는 작동하지 않는다.
 여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.

 이는 다이어그램에 **3**단계로 표시되어 있다.
@@ -152,7 +152,7 @@ spec:
 DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
 "`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.

-엔드포인트 객체는 `hostname` 필드를
+엔드포인트 오브젝트는 `hostname` 필드를
 임의의 엔드포인트 IP 주소로 지정할 수 있다.

 {{< note >}}
@@ -253,7 +253,7 @@ spec:
   값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다.
   병합 시 중복되는 도메인은 제거되며,
   쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다.
+- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 오브젝트들의 선택적 목록이다.
   이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다.
   이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며,
   병합 시 중복되는 항목은 제거된다.
@@ -22,12 +22,14 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의

 ## 추가 컨트롤러

+{{% thirdparty-content %}}
+
 * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
 * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의
  [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는
  [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
 * [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
-* [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다.
+* [AWS 로드 밸런서 컨트롤러](https://github.com/kubernetes-sigs/aws-load-balancer-controller)(이전의 AWS ALB 인그레스 컨트롤러)는 [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)을 사용하여 인그레스를 활성화한다.
 * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
  VMware에서 제공하고 지원한다.
 * Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다.
@@ -214,7 +214,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
 SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
 {{< /note >}}

-# 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
+## 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)

 쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다.

@@ -89,7 +89,7 @@ volumeBindingMode: Immediate
 등에 대한 완전한 재량권을 가진다. [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
 리포지터리에는 대량의 사양을 구현하는 외부 프로비저너를 작성하기
 위한 라이브러리가 있다. 일부 외부 프로비저너의 목록은
-[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns) 리포지터리에 있다.
+[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 리포지터리에 있다.

 예를 들어, NFS는 내부 프로비저너를 제공하지 않지만, 외부
 프로비저너를 사용할 수 있다. 타사 스토리지 업체가 자체 외부
@@ -28,7 +28,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및

 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다.

-* API 객체인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다.
+* API 오브젝트인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다.
 * `VolumeSnapshot` 은 CSI 드라이버에서만 사용할 수 있다.
 * 쿠버네티스 팀은 `VolumeSnapshot` 베타 버젼의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 동적 프로비저닝에서 `VolumeSnapshotContent` 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다.
 * CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다.
@@ -60,7 +60,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및
 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}
 API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에).

-퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 객체를 삭제한다면, 퍼시스턴트볼륨클레임 객체는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 객체 삭제는 스냅샷이 준비(readyTouse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.
+퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.

 ### 삭제

@@ -171,13 +171,17 @@ spec:
 ```

 파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는
-파드에는 영향을 주지 않는다. 파드는 템플릿 업데이트를 직접 받지 않는다. 대신,
-수정된 파드 템플릿과 일치하는 새로운 파드가 생성된다.
+파드에는 직접적인 영향을 주지 않는다. 워크로드 리소스의 파드 템플릿을
+변경하는 경우, 해당 리소스는 수정된 템플릿을 사용하는 대체 파드를 생성해야 한다.

-예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 각 디플로이먼트 오브젝트에 대한 현재
-파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트된 경우, 디플로이먼트는
-기존 파드를 제거하고 업데이트된 템플릿을 기반으로 새로운 파드를 생성해야 한다. 각 워크로드
-리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다.
+예를 들어, 스테이트풀셋 컨트롤러는 실행 중인 파드가 각 스테이트풀셋 오브젝트에 대한 현재
+파드 템플릿과 일치하는지 확인한다. 스테이트풀셋을 수정하여 파드 템플릿을
+변경하면, 스테이트풀셋이 업데이트된 템플릿을 기반으로 새로운 파드를 생성하기 시작한다.
+결국, 모든 이전의 파드가 새로운 파드로 교체되고, 업데이트가 완료된다.
+
+각 워크로드 리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다.
+스테이트풀셋에 대해 자세히 알아 보려면,
+스테이트풀셋 기본 튜토리얼에서 [업데이트 전략](/ko/docs/tutorials/stateful-application/basic-stateful-set/#스테이트풀셋-업데이트하기)을 읽어본다.

 노드에서 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}은
 파드 템플릿과 업데이트에 대한 상세 정보를 직접 관찰하거나 관리하지 않는다. 이러한
@@ -284,8 +284,6 @@ graph BT

 ### 클러스터 수준의 기본 제약 조건

-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-
 클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본
 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.