[ko] Update outdated files in dev-1.23-ko.2 M18-24

jihoon-seo · jihoon-seo · commit 13e4d2d37e11 · 2022-03-21T14:48:19.000+09:00
diff --git a/content/ko/docs/concepts/services-networking/_index.md b/content/ko/docs/concepts/services-networking/_index.md
@@ -5,8 +5,50 @@ description: >
   쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다.
 ---
 
+## 쿠버네티스 네트워크 모델
+
+모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다. 
+이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며 
+또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다. 
+이로 인해 포트 할당, 네이밍, 서비스 디스커버리, 
+[로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing), 
+애플리케이션 구성, 마이그레이션 관점에서 `파드`를 
+VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.
+
+쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다 
+(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)
+
+   * [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
+   * 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든 
+     파드와 통신할 수 있다
+
+참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는 
+다음의 요구사항도 존재한다.
+
+   * 한 노드의 호스트 네트워크에 있는 파드는 
+     NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
+
+이 모델은 전반적으로 덜 복잡할 뿐만 아니라, 
+무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다. 
+작업을 기존에는 VM에서 실행했었다면, VM은 IP주소를 가지며 프로젝트 내의 다른 VM과 통신할 수 있었을 것이다. 
+이는 동일한 기본 모델이다.
+
+쿠버네티스 IP 주소는 `파드` 범주에 존재하며, 
+`파드` 내의 컨테이너들은 IP 주소, MAC 주소를 포함하는 네트워크 네임스페이스를 공유한다. 
+이는 곧 `파드` 내의 컨테이너들이 각자의 포트에 `localhost`로 접근할 수 있음을 의미한다. 
+또한 `파드` 내의 컨테이너들이 포트 사용에 있어 서로 협조해야 하는데, 
+이는 VM 내 프로세스 간에도 마찬가지이다. 
+이러한 모델은 "파드 별 IP" 모델로 불린다.
+
+이것이 어떻게 구현되는지는 사용하는 컨테이너 런타임의 상세사항이다.
+
+`노드` 자체의 포트를 `파드`로 포워드하도록 요청하는 것도 가능하지만(호스트 포트라고 불림), 
+이는 매우 비주류적인(niche) 동작이다. 
+포워딩이 어떻게 구현되는지도 컨테이너 런타임의 상세사항이다. 
+`파드` 자체는 호스트 포트 존재 유무를 인지할 수 없다.
+
 쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다.
-- 파드 내의 컨테이너는 루프백(loopback)을 통한 네트워킹을 사용하여 통신한다.
+- 파드 내의 컨테이너는 루프백(loopback)을 통한 [네트워킹을 사용하여 통신](/ko/docs/concepts/services-networking/dns-pod-service/)한다.
 - 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다.
-- 서비스 리소스를 사용하면 파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근할 수 있다.
-- 또한 서비스를 사용하여 클러스터 내부에서 사용할 수 있는 서비스만 게시할 수 있다.
+- [서비스 리소스](/ko/docs/concepts/services-networking/service/)를 사용하면 [파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/concepts/services-networking/connect-applications-service/)할 수 있다.
+- 또한 서비스를 사용하여 [서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다.
diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md
@@ -13,11 +13,9 @@ weight: 30
 
 ## 컨테이너 연결을 위한 쿠버네티스 모델
 
-지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다. 쿠버네티스의 네트워킹 접근 방식을 논의하기 전에, 도커와 함께 동작하는 "일반적인" 네트워킹 방법과 대조해볼 가치가 있다.
+지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다.
 
-기본적으로 도커는 호스트-프라이빗 네트워킹을 사용하기에 컨테이너는 동일한 머신에 있는 경우에만 다른 컨테이너와 통신 할 수 있다. 도커 컨테이너가 노드를 통해 통신하려면 머신 포트에 IP 주소가 할당되어야 컨테이너에 전달되거나 프록시된다. 이것은 컨테이너가 사용하는 포트를 매우 신중하게 조정하거나 포트를 동적으로 할당해야 한다는 의미이다.
-
-컨테이너를 제공하는 여러 개발자 또는 팀에서 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
+쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트(localhost)에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
 
 이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다.
 
@@ -52,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
     podIP: 10.244.2.5
 ```
 
-클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.
+이제 클러스터의 모든 노드로 ssh 접속하거나 `curl`과 같은 도구를 사용하여 두 IP 주소에 질의를 전송할 수 있을 것이다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 `containerPort`를 사용하여 동일한 노드에서 여러 nginx 파드를 실행하는 것이 가능하고, 또한 서비스에 할당된 IP 주소를 사용하여 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 호스트 노드의 특정 포트를 배후(backing) 파드로 포워드하고 싶다면, 가능은 하지만 네트워킹 모델을 사용하면 그렇게 할 필요가 없어야 한다.
 
 만약 궁금하다면 [쿠버네티스 네트워킹 모델](/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
@@ -106,10 +106,9 @@ SRV 레코드는 노멀 서비스 또는
 
 `172-17-0-3.default.pod.cluster.local`.
 
-서비스에 의해 노출된 디플로이먼트(Deployment)나 데몬셋(DaemonSet)에 의해 생성된
-모든 파드는 다음과 같은 DNS 주소를 갖는다.
+서비스에 의해 노출된 모든 파드는 다음과 같은 DNS 주소를 갖는다.
 
-`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`.
+`pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`.
 
 ### 파드의 hostname 및 subdomain 필드
 
diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md
@@ -57,6 +57,14 @@ IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워
       * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
    * kube-proxy:
       * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
+   * kubelet:
+      * `--cloud-provider`가 명시되지 않았다면 
+        관리자는 해당 노드에 듀얼 스택 `.status.addresses`를 수동으로 설정하기 위해 
+        쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다.
+        해당 노드의 파드가 HostNetwork 모드로 실행된다면, 
+        파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다.
+        노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된 
+        IP 패밀리 선호사항을 만족한다.
 
 {{< note >}}
 IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도)
diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md
@@ -33,7 +33,7 @@ weight: 40
   Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
 * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
 * [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
-* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
+* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/reference/ingresscontroller.md)는 인그레스 컨트롤러로서 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
 * F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
   이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
 * [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [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
@@ -80,14 +80,23 @@ graph LR;
 설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
  인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
  그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
-다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
+서로 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 서로 다른 어노테이션을 지원한다.
  지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
 
 인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
 에는 로드 밸런서 또는 프록시 서버를 구성하는데 필요한 모든 정보가 있다. 가장 중요한 것은,
 들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을
 지시하는 규칙만 지원한다.
 
+`ingressClassName`을 생략하려면, [기본 인그레스 클래스](#default-ingress-class)가 
+정의되어 있어야 한다.
+
+몇몇 인그레스 컨트롤러는 기본 `IngressClass`가 정의되어 있지 않아도 동작한다. 
+예를 들어, Ingress-NGINX 컨트롤러는 `--watch-ingress-without-class` 
+[플래그](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)를 이용하여 구성될 수 있다. 
+하지만 [아래](#default-ingress-class)에 나와 있는 것과 같이 기본 `IngressClass`를 명시하는 것을 
+[권장](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do)한다.
+
 ### 인그레스 규칙
 
 각 HTTP 규칙에는 다음의 정보가 포함된다.
@@ -339,6 +348,14 @@ spec:
 기본값으로 표시하도록 해서 이 문제를 해결할 수 있다.
 {{< /caution >}}
 
+몇몇 인그레스 컨트롤러는 기본 `IngressClass`가 정의되어 있지 않아도 동작한다. 
+예를 들어, Ingress-NGINX 컨트롤러는 `--watch-ingress-without-class` 
+[플래그](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)를 이용하여 구성될 수 있다. 
+하지만 다음과 같이 기본 `IngressClass`를 명시하는 것을 
+[권장](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do)한다.
+
+{{< codenew file="service/networking/default-ingressclass.yaml" >}}
+
 ## 인그레스 유형들
 
 ### 단일 서비스로 지원되는 인그레스 {#single-service-ingress}
@@ -468,9 +485,7 @@ graph LR;
 트래픽을 일치 시킬 수 있다.
 
 예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을
-`service1`로, `second.bar.com`는 `service2`로, 호스트 이름이 정의되지
-않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든
-트래픽은 `service3`로 라우팅 한다.
+`service1`로, `second.bar.com`는 `service2`로, 그리고 요청 헤더가 `first.bar.com` 또는 `second.bar.com`에 해당되지 않는 모든 트래픽을 `service3`로 라우팅한다.
 
 {{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
 
diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md
diff --git a/content/ko/examples/service/networking/default-ingressclass.yaml b/content/ko/examples/service/networking/default-ingressclass.yaml
