[ko] Update outdated files in dev-1.23-ko.3 (M17-M43)

2022-06-13 16:23:15 +09:00
parent d81ac28907
commit 848f6a180e
26 changed files with 616 additions and 459 deletions
@@ -323,17 +323,6 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화
 쿠버네티스는 최대 32개의 탐색 도메인과 
 최대 2048자의 탐색 도메인 목록을 허용한다.

-### 기능 가용성
-
-파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다.
-
-| 쿠버네티스 버전 | 기능 지원 |
-| :---------: |:-----------:|
-| 1.14 | 안정 |
-| 1.10 | 베타 (기본값으로 켜져 있음)|
-| 1.9 | 알파 |
-
-
 ## {{% heading "whatsnext" %}}


@@ -1,4 +1,6 @@
 ---
+
+
 title: 엔드포인트슬라이스
 content_type: concept
 weight: 45
@@ -144,12 +146,12 @@ endpoints:
 v1 API에서는, 전용 필드 `nodeName` 및 `zone` 을 위해 엔드 포인트별
 `topology` 가 효과적으로 제거되었다.

-`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를
-설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신,
-v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 이러한
-필드는 API 버전 간에 자동으로 번역된다. 예를 들어,
-v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
-키 값은 v1 API의 `zone` 필드로 접근할 수 있다.
+`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를 설정하는 것은 
+더 이상 사용되지 않으며 v1 API에서 지원되지 않는다. 
+대신, v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 
+이러한 필드는 API 버전 간에 자동으로 번역된다. 
+예를 들어, v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"` 키 값은 
+v1 API의 `zone` 필드로 접근할 수 있다.
 {{< /note >}}

 ### 관리
@@ -23,7 +23,7 @@ weight: 40

 {{% thirdparty-content %}}

-* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
+* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com/azure/application-gateway/overview)를 구성하는 인그레스 컨트롤러다.
 * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
  컨트롤러다.
 * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
@@ -48,6 +48,7 @@ weight: 40
  구동하는 인그레스 컨트롤러다.
 * [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/)
  웹서버(프록시로 사용)와 함께 작동한다.
+* [Pomerium 인그레스 컨트롤러](https://www.pomerium.com/docs/k8s/ingress.html)는 [Pomerium](https://pomerium.com/) 기반 인그레스 컨트롤러이며, 상황 인지 접근 정책을 제공한다.
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
 * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
  [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.
@@ -74,7 +74,7 @@ graph LR;

 {{< codenew file="service/networking/minimal-ingress.yaml" >}}

-다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
+인그레스에는 `apiVersion`, `kind`, `metadata` 및 `spec` 필드가 명시되어야 한다.
 인그레스 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
@@ -118,8 +118,14 @@ graph LR;

 ### DefaultBackend {#default-backend}

-규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. `defaultBackend` 는 일반적으로
-[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
+규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송하며, 
+`.spec.defaultBackend`는 이와 같은 경우에 요청을 처리할 백엔드를 지정한다. 
+`defaultBackend` 는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 
+인그레스 리소스에 지정되어 있지 않다. 
+`.spec.rules` 가 명시되어 있지 않으면, 
+`.spec.defaultBackend` 는 반드시 명시되어 있어야 한다. 
+`defaultBackend` 가 설정되어 있지 않으면, 어느 규칙에도 해당되지 않는 요청의 처리는 인그레스 컨트롤러의 구현을 따른다(이러한 
+경우를 어떻게 처리하는지 알아보려면 해당 인그레스 컨트롤러 문서를 참고한다).

 만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
 기본 백엔드로 라우팅 된다.
@@ -309,7 +315,7 @@ spec:
  controller: example.com/ingress-controller
  parameters:
    # 이 인그레스클래스에 대한 파라미터는 
-    # "external-configuration" 환경 설정 네임스페이스에 있는
+    # "external-configuration" 네임스페이스에 있는
    # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다.
    scope: Namespace
    apiGroup: k8s.example.com
@@ -45,42 +45,7 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo

 네트워크폴리시 의 예시는 다음과 같다.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: test-network-policy
-  namespace: default
-spec:
-  podSelector:
-    matchLabels:
-      role: db
-  policyTypes:
-  - Ingress
-  - Egress
-  ingress:
-  - from:
-    - ipBlock:
-        cidr: 172.17.0.0/16
-        except:
-        - 172.17.1.0/24
-    - namespaceSelector:
-        matchLabels:
-          project: myproject
-    - podSelector:
-        matchLabels:
-          role: frontend
-    ports:
-    - protocol: TCP
-      port: 6379
-  egress:
-  - to:
-    - ipBlock:
-        cidr: 10.0.0.0/24
-    ports:
-    - protocol: TCP
-      port: 5978
-```
+{{< codenew file="service/networking/networkpolicy.yaml" >}}

 {{< note >}}
 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
@@ -281,7 +246,7 @@ API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을

 ## 이름으로 네임스페이스 지정

-{{< feature-state state="beta" for_k8s_version="1.21" >}}
+{{< feature-state for_k8s_version="1.22" state="stable" >}}

 쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName`
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우
@@ -24,7 +24,7 @@ weight: 10

 ## 동기

-쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 상태와
+쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 목표 상태(desired state)와
 일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다.
 만약 앱을 실행하기 위해 {{< glossary_tooltip term_id="deployment" text="디플로이먼트" >}}를 사용한다면,
 동적으로 파드를 생성하고 제거할 수 있다.
@@ -108,13 +108,46 @@ spec:
 필드와 같은 값으로 설정된다.
 {{< /note >}}

-파드의 포트 정의에는 이름이 있고, 서비스의 `targetPort` 속성에서 이 이름을
-참조할 수 있다. 이것은 다른 포트 번호를 통한 가용한 동일 네트워크 프로토콜이 있고,
-단일 구성 이름을 사용하는 서비스 내에
-혼합된 파드가 존재해도 가능하다.
-이를 통해 서비스를 배포하고 진전시키는데 많은 유연성을 제공한다.
-예를 들어, 클라이언트를 망가뜨리지 않고, 백엔드 소프트웨어의 다음
-버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
+파드의 포트 정의에 이름이 있으므로, 
+서비스의 `targetPort` 속성에서 이 이름을 참조할 수 있다. 
+예를 들어, 다음과 같은 방법으로 서비스의 `targetPort`를 파드 포트에 바인딩할 수 있다.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+  labels:
+    app.kubernetes.io/name: proxy
+spec:
+  containers:
+  - name: nginx
+    image: nginx:11.14.2
+    ports:
+      - containerPort: 80
+        name: http-web-svc
+        
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx-service
+spec:
+  selector:
+    app.kubernetes.io/name: proxy
+  ports:
+  - name: name-of-service-port
+    protocol: TCP
+    port: 80
+    targetPort: http-web-svc
+```
+
+
+이것은 서로 다른 포트 번호를 통해 가용한 동일 네트워크 프로토콜이 있고, 
+단일 구성 이름을 사용하는 서비스 내에 혼합된 파드가 존재해도 가능하다. 
+이를 통해 서비스를 배포하고 진전시키는 데 많은 유연성을 제공한다. 
+예를 들어, 클라이언트를 망가뜨리지 않고, 
+백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.

 서비스의 기본 프로토콜은 TCP이다. 다른
 [지원되는 프로토콜](#protocol-support)을 사용할 수도 있다.
@@ -125,9 +158,9 @@ spec:

 ### 셀렉터가 없는 서비스

-서비스는 일반적으로 쿠버네티스 파드에 대한 접근을 추상화하지만,
-다른 종류의 백엔드를 추상화할 수도 있다.
-예를 들면
+서비스는 일반적으로 셀렉터를 이용하여 쿠버네티스 파드에 대한 접근을 추상화하지만, 
+셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며, 
+여기에는 클러스터 외부에서 실행되는 것도 포함된다. 예시는 다음과 같다.

 * 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
  테스트 환경에서는 자체 데이터베이스를 사용한다.
@@ -19,6 +19,12 @@ _토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드
 예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해, 
 인접성을 고려하여 트래픽을 라우트할 수 있다.

+{{< note >}}
+"토폴로지 인지 힌트" 기능은 베타 단계이며 기본적으로 활성화되어 있지 **않다**. 
+이 기능을 사용해 보려면, 
+`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+{{< /note >}}
+
 <!-- body -->

 ## 동기(motivation)