[ko] Update outdated files in dev-1.23-ko.1 M17-24

2021-12-15 15:10:23 +09:00
parent 0a2da8cb46
commit 1d1928e173
8 changed files with 172 additions and 35 deletions
@@ -1,4 +1,8 @@
 ---
+
+
+
+
 title: 서비스와 애플리케이션 연결하기
 content_type: concept
 weight: 30
@@ -50,7 +54,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP

 클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.

-만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다.
+만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다.

 ## 서비스 생성하기

@@ -39,7 +39,7 @@ DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다

 DNS 쿼리는 파드의 `/etc/resolv.conf` 를 사용하여 확장될 수 있을 것이다. Kubelet은
 각 파드에 대해서 파일을 설정한다. 예를 들어, `data` 만을 위한 쿼리는
-`data.test.cluster.local` 로 확장된다. `search` 옵션의 값은
+`data.test.svc.cluster.local` 로 확장된다. `search` 옵션의 값은
 쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우,
 [`resolv.conf` 설명 페이지.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)를 참고한다.

@@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: IPv4/IPv6 이중 스택
 feature:
  title: IPv4/IPv6 이중 스택
@@ -11,7 +16,7 @@ weight: 70

 <!-- overview -->

-{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}

 IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다.

@@ -42,8 +47,6 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음

 ## IPv4/IPv6 이중 스택 구성

-IPv4/IPv6 이중 스택을 사용하려면, 클러스터의 관련 구성 요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. (1.21부터 IPv4/IPv6 이중 스택이 기본적으로 활성화된다.)
-
 IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다.

   * kube-apiserver:
@@ -60,9 +63,6 @@ IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도

 IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.)

-1.21부터, IPv4/IPv6 이중 스택은 기본적으로 활성화된다.
-필요한 경우 kube-apiserver, kube-controller-manager, kubelet 및 kube-proxy 커맨드 라인에
-`--feature-gates="IPv6DualStack=false"` 를 지정하여 비활성화할 수 있다.
 {{< /note >}}

 ## 서비스
@@ -76,7 +76,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서

 * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
 * `PreferDualStack`:
-  * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. (클러스터에 `--feature-gates="IPv6DualStack=false"` 가 있는 경우, 이 설정은 `SingleStack` 과 동일한 동작을 따른다.)
+  * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다.
 * `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다.
  * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.

@@ -119,7 +119,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서

 #### 기존 서비스의 이중 스택 기본값

-이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (`--feature-gates="IPv6DualStack=false"` 가 설정되지 않은 경우 기존 클러스터를 1.21로 업그레이드하면 이중 스택이 활성화된다.)
+이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.)

 1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.

@@ -28,6 +28,7 @@ weight: 40
  컨트롤러다.
 * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
 * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다.
+* [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe)는 [BFE](https://www.bfe-networks.net) 기반 인그레스 컨트롤러다.
 * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
  Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
 * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
@@ -51,7 +51,7 @@ graph LR;
 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.

 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
-[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는
+[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 또는
 [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다.

 ## 전제 조건들
@@ -219,20 +219,98 @@ Events:       <none>

 {{< codenew file="service/networking/external-lb.yaml" >}}

-IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
-추가 구현 별 구성을 참조하는데 사용할 수 있다.
+인그레스클래스의 `.spec.parameters` 필드를 사용하여 
+해당 인그레스클래스와 연관있는 환경 설정을 제공하는 다른 리소스를 참조할 수 있다.

-#### 네임스페이스 범위의 파라미터
+사용 가능한 파라미터의 상세한 타입은 
+인그레스클래스의 `.spec.parameters` 필드에 명시한 인그레스 컨트롤러의 종류에 따라 다르다.

-{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+### 인그레스클래스 범위

-`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데
-사용할 수 있는 `scope` 및 `namespace` 필드가 있다.
-`Scope` 필드의 기본값은 `Cluster` 이다. 즉, 기본값은 클러스터 범위의
-리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를
-설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다.
+인그레스 컨트롤러의 종류에 따라, 클러스터 범위로 설정한 파라미터의 사용이 가능할 수도 있고, 
+또는 한 네임스페이스에서만 사용 가능할 수도 있다.

-{{< codenew file="service/networking/namespaced-params.yaml" >}}
+{{< tabs name="tabs_ingressclass_parameter_scope" >}}
+{{% tab name="클러스터" %}}
+인그레스클래스 파라미터의 기본 범위는 클러스터 범위이다.
+
+`.spec.parameters` 필드만 설정하고 `.spec.parameters.scope` 필드는 지정하지 않거나,
+`.spec.parameters.scope` 필드를 `Cluster`로 지정하면, 
+인그레스클래스는 클러스터 범위의 리소스를 참조한다.
+파라미터의 `kind`(+`apiGroup`)는 
+클러스터 범위의 API (커스텀 리소스일 수도 있음) 를 참조하며, 
+파라미터의 `name`은 
+해당 API에 대한 특정 클러스터 범위 리소스를 가리킨다.
+
+예시는 다음과 같다.
+```yaml
+---
+apiVersion: networking.k8s.io/v1
+kind: IngressClass
+metadata:
+  name: external-lb-1
+spec:
+  controller: example.com/ingress-controller
+  parameters:
+    # 이 인그레스클래스에 대한 파라미터는 "external-config-1" 라는
+    # ClusterIngressParameter(API 그룹 k8s.example.net)에 기재되어 있다.
+    # 이 정의는 쿠버네티스가 
+    # 클러스터 범위의 파라미터 리소스를 검색하도록 한다.
+    scope: Cluster
+    apiGroup: k8s.example.net
+    kind: ClusterIngressParameter
+    name: external-config-1
+```
+{{% /tab %}}
+{{% tab name="네임스페이스" %}}
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
+
+`.spec.parameters` 필드를 설정하고 
+`.spec.parameters.scope` 필드를 `Namespace`로 지정하면, 
+인그레스클래스는 네임스페이스 범위의 리소스를 참조한다. 
+사용하고자 하는 파라미터가 속한 네임스페이스를 
+`.spec.parameters` 의 `namespace` 필드에 설정해야 한다.
+
+파라미터의 `kind`(+`apiGroup`)는 
+네임스페이스 범위의 API (예: 컨피그맵) 를 참조하며, 
+파라미터의 `name`은 
+`namespace`에 명시한 네임스페이스의 특정 리소스를 가리킨다.
+
+네임스페이스 범위의 파라미터를 이용하여, 
+클러스터 운영자가 워크로드에 사용되는 환경 설정(예: 로드 밸런서 설정, API 게이트웨이 정의)에 대한 제어를 위임할 수 있다.
+클러스터 범위의 파라미터를 사용했다면 다음 중 하나에 해당된다.
+
+- 다른 팀의 새로운 환경 설정 변경을 적용하려고 할 때마다 
+  클러스터 운영 팀이 매번 승인을 해야 한다. 또는,
+- 애플리케이션 팀이 클러스터 범위 파라미터 리소스를 변경할 수 있게 하는 
+  [RBAC](/docs/reference/access-authn-authz/rbac/) 롤, 바인딩 등의 특별 접근 제어를 
+  클러스터 운영자가 정의해야 한다.
+
+인그레스클래스 API 자신은 항상 클러스터 범위이다.
+
+네임스페이스 범위의 파라미터를 참조하는 인그레스클래스 예시가 
+다음과 같다.
+```yaml
+---
+apiVersion: networking.k8s.io/v1
+kind: IngressClass
+metadata:
+  name: external-lb-2
+spec:
+  controller: example.com/ingress-controller
+  parameters:
+    # 이 인그레스클래스에 대한 파라미터는 
+    # "external-configuration" 환경 설정 네임스페이스에 있는
+    # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다.
+    scope: Namespace
+    apiGroup: k8s.example.com
+    kind: IngressParameter
+    namespace: external-configuration
+    name: external-config
+```
+
+{{% /tab %}}
+{{< /tabs >}}

 ### 사용중단(Deprecated) 어노테이션

@@ -565,6 +643,6 @@ Events:

 ## {{% heading "whatsnext" %}}

-* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
+* [인그레스](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API에 대해 배우기
 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/)