[ko] Update outdated files in dev-1.22-ko.4 M12-26

2021-12-10 17:23:34 +09:00
parent 37e625e28c
commit 2ee31ae39c
13 changed files with 46 additions and 164 deletions
@@ -145,7 +145,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치

 ### 인가

-[인가](/docs/reference/access-authn-authz/webhook/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
+[인가](/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.


 ### 동적 어드미션 컨트롤
@@ -146,9 +146,9 @@ CRD 오브젝트의 이름은 유효한

 일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.

-[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 독립형 API 서버를
+[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를
 작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
-기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 사용자에게 위임하여
+기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 자체 API 서버에게 위임하여
 모든 클라이언트가 사용할 수 있게 한다.

 ## 커스텀 리소스를 추가할 방법 선택
@@ -31,9 +31,7 @@ weight: 30
 및 실행을 자동화할 수 있고, *또한* 쿠버네티스가 수행하는 방식을
 자동화할 수 있다.

-쿠버네티스의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}
-개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을
-확장할 수 있다.
+쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}} 개념을 통해, {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 커스텀 리소스와 연계시켜 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을 확장할 수 있다.
 오퍼레이터는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)의
 컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다.

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

@@ -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/) 기반 인그레스 컨트롤러다.
@@ -56,12 +57,11 @@ weight: 40

 ## 여러 인그레스 컨트롤러 사용

-하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다.
-인그레스를 생성할 때,  클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우
-어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
-어노테이션을 각각의 인그레스에 달아야 한다.
+[인그레스 클래스](/ko/docs/concepts/services-networking/ingress/#인그레스-클래스)를 사용하여 하나의 클러스터 내에 여러 개의 인그레스 컨트롤러를 배포할 수 있다. 
+인그레스 클래스 리소스의 `.metadata.name`을 기록해 놓는다. 인그레스를 생성할 때, 인그레스 오브젝트의 `ingressClassName` 필드에 해당 값을 적어야 한다([IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec) 참조). `ingressClassName`은 예전 [어노테이션 메소드](/ko/docs/concepts/services-networking/ingress/#사용중단-deprecated-어노테이션)를 대체한다.

-만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다.
+인그레스에 대해 인그레스클래스를 명시하지 않고, 기본값으로 지정된 인그레스클래스가 클러스터에 단 하나만 있다면, 쿠버네티스는 해당 기본 인그레스클래스를 인그레스에 [적용한다](/ko/docs/concepts/services-networking/ingress/#default-ingress-class).
+인그레스클래스의 [`ingressclass.kubernetes.io/is-default-class` 어노테이션](/ko/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class)을 `"true"`로 지정하여 해당 인그레스클래스를 기본 인그레스클래스로 표시할 수 있다.

 이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만,
 다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
@@ -10,14 +10,13 @@ feature:
  title: 스토리지 오케스트레이션
  description: >
    로컬 스토리지, <a href="https://cloud.google.com/storage/">GCP</a>나 <a href="https://aws.amazon.com/products/storage/">AWS</a>와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다.
-
 content_type: concept
 weight: 20
 ---

 <!-- overview -->

-이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다.
+이 페이지에서는 쿠버네티스의 _퍼시스턴트 볼륨_ 에 대해 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다.

 <!-- body -->

@@ -7,7 +7,7 @@

 title: 스토리지 용량
 content_type: concept
-weight: 45
+weight: 70
 ---

 <!-- overview -->
@@ -16,7 +16,6 @@ weight: 45
 예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며,
 또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다.

-{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
 {{< feature-state for_k8s_version="v1.21" state="beta" >}}

 이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고
@@ -470,14 +470,14 @@ parameters:

 vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다.

- [CSI 프로비저닝 도구](#csi-프로비저닝-도구): `csi.vsphere.vmware.com`
+- [CSI 프로비저닝 도구](#vsphere-provisioner-csi): `csi.vsphere.vmware.com`
 - [vCP 프로비저닝 도구](#vcp-프로비저닝-도구): `kubernetes.io/vsphere-volume`

 인-트리 프로비저닝 도구는 [사용 중단](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)되었다. CSI 프로비저닝 도구에 대한 자세한 내용은 [쿠버네티스 vSphere CSI 드라이버](https://vsphere-csi-driver.sigs.k8s.io/) 및 [vSphereVolume CSI 마이그레이션](/ko/docs/concepts/storage/volumes/#csi-마이그레이션)을 참고한다.

 #### CSI 프로비저닝 도구 {#vsphere-provisioner-csi}

-vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml)를 참조한다.
+vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml)를 참조한다.

 #### vCP 프로비저닝 도구

@@ -1,7 +1,12 @@
 ---
+
+
+
+
+
 title: CSI 볼륨 복제하기
 content_type: concept
-weight: 30
+weight: 60
 ---

 <!-- overview -->
@@ -8,7 +8,7 @@

 title: 볼륨 스냅샷 클래스
 content_type: concept
-weight: 30
+weight: 41 # just after volume snapshots
 ---

 <!-- overview -->
@@ -1,7 +1,14 @@
 ---
+
+
+
+
+
+
+
 title: 볼륨 스냅샷
 content_type: concept
-weight: 20
+weight: 40
 ---

 <!-- overview -->
@@ -44,12 +44,21 @@ weight: 10

 볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고
 `.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다.
-컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템
-뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는
-파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에
-마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를
-가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로
-지정해야 한다.
+컨테이너의 프로세스는 
+{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}의 최초 내용물과 
+컨테이너 안에 마운트된 볼륨(정의된 경우에 한함)으로 구성된 파일시스템을 보게 된다.
+프로세스는 컨테이너 이미지의 최초 내용물에 해당되는 루트 파일시스템을 
+보게 된다.
+쓰기가 허용된 경우, 해당 파일시스템에 쓰기 작업을 하면 
+추후 파일시스템에 접근할 때 변경된 내용을 보게 될 것이다.
+볼륨은 이미지의 [특정 경로](#using-subpath)에 
+마운트된다.
+파드에 정의된 각 컨테이너에 대해, 
+컨테이너가 사용할 각 볼륨을 어디에 마운트할지 명시해야 한다.
+
+볼륨은 다른 볼륨 안에 마운트될 수 없다 
+(하지만, [서브패스 사용](#using-subpath)에서 관련 메커니즘을 확인한다). 
+또한, 볼륨은 다른 볼륨에 있는 내용물을 가리키는 하드 링크를 포함할 수 없다.

 ## 볼륨 유형들 {#volume-types}

@@ -802,142 +811,7 @@ spec:
 ### projected

 `Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다.
-
-현재, 다음 유형의 볼륨 소스를 프로젝티드한다.
-
-* [`secret`](#secret)
-* [`downwardAPI`](#downwardapi)
-* [`configMap`](#configmap)
-* `serviceAccountToken`
-
-모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은
-[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
-
-#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap}
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: volume-test
-spec:
-  containers:
-  - name: container-test
-    image: busybox
-    volumeMounts:
-    - name: all-in-one
-      mountPath: "/projected-volume"
-      readOnly: true
-  volumes:
-  - name: all-in-one
-    projected:
-      sources:
-      - secret:
-          name: mysecret
-          items:
-            - key: username
-              path: my-group/my-username
-      - downwardAPI:
-          items:
-            - path: "labels"
-              fieldRef:
-                fieldPath: metadata.labels
-            - path: "cpu_limit"
-              resourceFieldRef:
-                containerName: container-test
-                resource: limits.cpu
-      - configMap:
-          name: myconfigmap
-          items:
-            - key: config
-              path: my-group/my-config
-```
-
-#### 구성 예시: 기본값이 아닌 소유권 모드 설정의 시크릿 {#example-configuration-secrets-nondefault-permission-mode}
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: volume-test
-spec:
-  containers:
-  - name: container-test
-    image: busybox
-    volumeMounts:
-    - name: all-in-one
-      mountPath: "/projected-volume"
-      readOnly: true
-  volumes:
-  - name: all-in-one
-    projected:
-      sources:
-      - secret:
-          name: mysecret
-          items:
-            - key: username
-              path: my-group/my-username
-      - secret:
-          name: mysecret2
-          items:
-            - key: password
-              path: my-group/my-password
-              mode: 511
-```
-
-각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다.
-파라미터는 두 가지 예외를 제외하고 거의 동일하다.
-
-* 시크릿의 경우 `secretName` 필드는 컨피그맵 이름과 일치하도록
-  `name` 으로 변경되었다.
-* `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만
-  지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode`
-  를 명시적으로 설정할 수 있다.
-
-`TokenRequestProjection` 기능이 활성화 되면, 현재
-[서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에
-대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 예를 들면 다음과 같다.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: sa-token-test
-spec:
-  containers:
-  - name: container-test
-    image: busybox
-    volumeMounts:
-    - name: token-vol
-      mountPath: "/service-account"
-      readOnly: true
-  volumes:
-  - name: token-vol
-    projected:
-      sources:
-      - serviceAccountToken:
-          audience: api
-          expirationSeconds: 3600
-          path: token
-```
-
-예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이
-있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데
-사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을
-포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며,
-그렇지 않으면 토큰을 거부해야 한다. 이 필드는
-선택 사항이며 기본값은 API 서버의 식별자이다.
-
-`expirationSeconds` 는 서비스 어카운트 토큰의 예상 유효
-기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는
-API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정해서
-최대 값을 제한할 수도 있다. `path` 필드는 projected 볼륨의 마운트 위치에 대한
-상대 경로를 지정한다.
-
-{{< note >}}
-projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 
-해당 볼륨 소스의 업데이트를 수신하지 않는다.
-{{< /note >}}
+더 자세한 사항은 [projected volumes](/docs/concepts/storage/projected-volumes/)를 참고한다.

 ### quobyte (사용 중단됨) {#quobyte}