Merge pull request #30963 from jihoon-seo/211215_Outdated_M17

[ko] Update outdated files in dev-1.23-ko.1 (M17-M24)

content/ko/docs/concepts/overview/kubernetes-api.md

@@ -1,4 +1,6 @@
 ---
+
+
 title: 쿠버네티스 API
 content_type: concept
 weight: 30
@@ -35,36 +37,39 @@ card:
 
 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다.
 
-OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
-다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다.
+### OpenAPI V2
+
+쿠버네티스 API 서버는 `/openapi/v2` 엔드포인트를 통해 
+통합된(aggregated) OpenAPI v2 스펙을 제공한다. 
+요청 헤더에 다음과 같이 기재하여 응답 형식을 지정할 수 있다.
 
 <table>
-  <caption style="display:none">Valid request header values for OpenAPI v2 queries</caption>
+  <caption style="display:none"> OpenAPI v2 질의에 사용할 수 있는 유효한 요청 헤더 값</caption>
   <thead>
      <tr>
-        <th>Header</th>
-        <th style="min-width: 50%;">Possible values</th>
-        <th>Notes</th>
+        <th>헤더</th>
+        <th style="min-width: 50%;">사용할 수 있는 값</th>
+        <th>참고</th>
      </tr>
   </thead>
   <tbody>
      <tr>
         <td><code>Accept-Encoding</code></td>
         <td><code>gzip</code></td>
-        <td><em>not supplying this header is also acceptable</em></td>
+        <td><em>이 헤더를 제공하지 않는 것도 가능</em></td>
      </tr>
      <tr>
         <td rowspan="3"><code>Accept</code></td>
         <td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td>
-        <td><em>mainly for intra-cluster use</em></td>
+        <td><em>주로 클러스터 내부 용도로 사용</em></td>
      </tr>
      <tr>
         <td><code>application/json</code></td>
-        <td><em>default</em></td>
+        <td><em>기본값</em></td>
      </tr>
      <tr>
         <td><code>*</code></td>
-        <td><em>serves </em><code>application/json</code></td>
+        <td><code>JSON으로 응답</em></td>
      </tr>
   </tbody>
 </table>
@@ -75,6 +80,55 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
 IDL(인터페이스 정의 언어) 파일을 참고한다.
 
+### OpenAPI V3
+
+{{< feature-state state="alpha"  for_k8s_version="v1.23" >}}
+
+쿠버네티스 v1.23은 OpenAPI v3 API 발행(publishing)에 대한 초기 지원을 제공한다. 
+이는 알파 기능이며 기본적으로 비활성화되어 있다.
+kube-apiserver 구성 요소에 
+`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 
+이 알파 기능을 활성화할 수 있다.
+
+이 기능이 활성화되면, 쿠버네티스 API 서버는 
+통합된(aggregated) OpenAPI v3 스펙을 쿠버네티스 그룹 버전별로 
+`/openapi/v3/apis/<group>/<version>` 엔드포인트에 제공한다. 
+사용할 수 있는 요청 헤더는 아래의 표를 참고한다.
+
+<table>
+  <caption style="display:none"> OpenAPI v3 질의에 사용할 수 있는 유효한 요청 헤더 값</caption>
+  <thead>
+     <tr>
+        <th>헤더</th>
+        <th style="min-width: 50%;">사용할 수 있는 값</th>
+        <th>참고</th>
+     </tr>
+  </thead>
+  <tbody>
+     <tr>
+        <td><code>Accept-Encoding</code></td>
+        <td><code>gzip</code></td>
+        <td><em>이 헤더를 제공하지 않는 것도 가능</em></td>
+     </tr>
+     <tr>
+        <td rowspan="3"><code>Accept</code></td>
+        <td><code>application/com.github.proto-openapi.spec.v3@v1.0+protobuf</code></td>
+        <td><em>주로 클러스터 내부 용도로 사용</em></td>
+     </tr>
+     <tr>
+        <td><code>application/json</code></td>
+        <td><em>기본값</em></td>
+     </tr>
+     <tr>
+        <td><code>*</code></td>
+        <td><code>JSON으로 응답</em></td>
+     </tr>
+  </tbody>
+</table>
+
+`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든 
+그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다.
+
 ## 지속성
 
 쿠버네티스는 오브젝트의 직렬화된 상태를

content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
-* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기
+* [kube-scheduler 구성(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽기
 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기

content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md

@@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 마치 100을 설정한 것처럼 작동한다.
 
 값을 변경하려면,
-[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을
+[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta3/)을
 편집한 다음 스케줄러를 재시작한다.
 대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.
 
@@ -161,4 +161,4 @@ percentageOfNodesToScore: 50
 
 ## {{% heading "whatsnext" %}}
 
-* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인
+* [kube-scheduler 구성 레퍼런스(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 확인

content/ko/docs/concepts/services-networking/connect-applications-service.md

@@ -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/#쿠버네티스-네트워크-모델)을 자세히 읽어본다.
 
 ## 서비스 생성하기
 

content/ko/docs/concepts/services-networking/dns-pod-service.md

@@ -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)를 참고한다.
 

content/ko/docs/concepts/services-networking/dual-stack.md

@@ -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`에 저장한다.
 

content/ko/docs/concepts/services-networking/ingress-controllers.md

@@ -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/) 기반 인그레스 컨트롤러다.

content/ko/docs/concepts/services-networking/ingress.md

@@ -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/)