Update outdated files in the dev-1.19-ko.7 branch

2020-12-10 03:47:54 +00:00
parent 958c5bd7b8
commit 09708662cc
14 changed files with 105 additions and 97 deletions
@@ -55,11 +55,12 @@ weight: 50
 주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고
 프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다.

-쿠버네티스의 IP 주소는 그것의 IP 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
+쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
 컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두
 `localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한
 `Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도
-VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다.
+VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 
+한다.

 이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다.

@@ -103,7 +103,7 @@ kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVID

 액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. 공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 컨테이너를 제공해야 한다.

-[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text= DisableAcceleratorUsageMetrics,-false)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다.
+[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다.

 ## 컴포넌트 메트릭

@@ -134,7 +134,7 @@ data:
 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면
 서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다.
 또한 파드에서 서비스 어카운트를 참조하는 방법을
-[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)의
+[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)의
 `automountServiceAccountToken` 필드와 `serviceAccountName`
 필드를 통해 확인할 수 있다.

@@ -152,7 +152,7 @@ data:
 인코딩된 `~/.dockercfg` 파일의 콘텐츠를 값으로 가지는 `.dockercfg` 키를 포함하고 있는지
 확실히 확인해야 한다.

-`kubernetes/dockerconfigjson` 타입은 `~/.dockercfg` 의
+`kubernetes.io/dockerconfigjson` 타입은 `~/.dockercfg` 의
 새로운 포맷인 `~/.docker/config.json` 파일과 동일한 포맷 법칙을
 따르는 직렬화 된 JSON의 저장을 위해 디자인되었다.
 이 시크릿 타입을 사용할 때는, 시크릿 오브젝트의 `data` 필드가 `.dockerconfigjson` 키를
@@ -347,22 +347,21 @@ data:
  usage-bootstrap-signing: dHJ1ZQ==
 ```

-부트스트랩 타입은 `data` 아래 명시된 다음의 키들을 가진다.
+부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다.

 - `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
 - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
- `description1`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
+- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
  문자열. 선택 사항.
 - `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를
  사용하는 절대 UTC 시간. 선택 사항.
 - `usage-bootstrap-<usage>`: 부트스트랩 토큰의 추가적인 사용처를 나타내는
  불리언(boolean) 플래그.
- `auth-extra-groups`: system:bootstrappers 그룹에 추가로 인증될
+- `auth-extra-groups`: `system:bootstrappers` 그룹에 추가로 인증될
  쉼표로 구분된 그룹 이름 목록.

 위의 YAML은 모두 base64로 인코딩된 문자열 값이므로 혼란스러워 보일
-수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿 오브젝트 결과를 만드는
-동일한 시크릿을 생성할 수 있다.
+수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿을 생성할 수 있다.

 ```yaml
 apiVersion: v1
@@ -138,10 +138,11 @@ partition
 !partition
 ```

-첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
-두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
-세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다.
-네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다.
+* 첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
+* 두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
+* 세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다.
+* 네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다.
+
 마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다.
 _집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production`과 `environment in (production)`을 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다.

@@ -13,8 +13,8 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
 클러스터와 함께 자동으로 실행되지 않는다.
 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.

-프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와
-  [nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다.
+프로젝트로써 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와
+  [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) 인그레스 컨트롤러를 지원하고 유지한다.



@@ -24,31 +24,31 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의

 {{% thirdparty-content %}}

-* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
-* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의
-  [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는
-  [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
-* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
-* [AWS 로드 밸런서 컨트롤러](https://github.com/kubernetes-sigs/aws-load-balancer-controller)(이전의 AWS ALB 인그레스 컨트롤러)는 [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)을 사용하여 인그레스를 활성화한다.
-* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
-  VMware에서 제공하고 지원한다.
-* Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다.
-* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨테이너 인그레스 서비스](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한
-  [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다.
-* [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다.
-* [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다.
-* [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다.
-* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로
-  [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/).
-* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한
-  [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는
-  [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다.
-* [NGINX, Inc.](https://www.nginx.com/)는
-  [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다.
-* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
-* [Traefik](https://github.com/traefik/traefik)은
-  모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로,
-  [Traefik Labs](https://traefik.io)에서 상업적인 지원을 제공한다.
+* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
+* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
+  컨트롤러다.
+* [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
+  Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
+* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
+* 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) 기반의
+  오픈소스 인그레스 컨트롤러다.
+* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](http://www.haproxy.org/#desc)의
+  인그레스 컨트롤러다.
+* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](http://www.haproxy.org/#desc) 용
+  인그레스 컨트롤러이기도 하다.
+* [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/)
+  기반 인그레스 컨트롤러다.
+* [쿠버네티스 용 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller#readme)는 [Kong 게이트웨이](https://konghq.com/kong/)를
+  구동하는 인그레스 컨트롤러다.
+* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)는 [NGINX](https://www.nginx.com/resources/glossary)
+  웹서버(프록시로 사용)와 함께 작동한다.
+* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
+* [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
+  [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.
+* [Voyager](https://appscode.com/products/voyager)는
+  [HAProxy](http://www.haproxy.org/#desc)의 인그레스 컨트롤러다.

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

@@ -73,3 +73,4 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의

 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
 * [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
+
@@ -304,26 +304,35 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마

 퍼시스턴트볼륨 유형은 플러그인으로 구현된다. 쿠버네티스는 현재 다음의 플러그인을 지원한다.

-* GCEPersistentDisk
-* AWSElasticBlockStore
-* AzureFile
-* AzureDisk
-* CSI
-* FC (파이버 채널)
-* FlexVolume
-* Flocker
-* NFS
-* iSCSI
-* RBD (Ceph Block Device)
-* CephFS
-* Cinder (OpenStack 블록 스토리지)
-* Glusterfs
-* VsphereVolume
-* Quobyte Volumes
-* HostPath (단일 노드 테스트 전용 – 로컬 스토리지는 어떤 방식으로도 지원되지 않으며 다중-노드 클러스터에서 작동하지 않음)
-* Portworx Volumes
-* ScaleIO Volumes
-* StorageOS
+* [`awsElasticBlockStore`](/ko/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store(EBS)
+* [`azureDisk`](/ko/docs/concepts/sotrage/volumes/#azuredisk) - Azure Disk
+* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File
+* [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨
+* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder(OpenStack 블록 스토리지)
+  (**사용 중단됨**)
+* [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스(CSI)
+* [`fc`](/ko/docs/concepts/storage/volumes/#fc) - 파이버 채널(FC) 스토리지
+* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexvolume) - FlexVolume
+* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
+* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE 영구 디스크
+* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
+* [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨
+  (단일 노드 테스트 전용임. 다중-노드 클러스터에서는 동작하지 않음!
+  대신 `local` 볼륨을 사용하는 것을 고려할 것)
+* [`iscsi`](/ko/docs/concepts/storage/volumes/#iscsi) - iSCSI(SCSI over IP) 스토리지
+* [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
+  로컬 스토리지 디바이스.
+* [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - Network File System(NFS) 스토리지
+* `photonPersistentDisk` - Photon 컨트롤러 영구 디스크.
+  (해당 클라우드 제공자 삭제로 인해 이 볼륨 타입은 더이상
+  동작하지 않음.)
+* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨
+* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
+* [`rbd`](/ko/docs/concepts/storage/volumes/#rbd) - Rados Block Device(RBD) 볼륨
+* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
+  (**사용 중단됨**)
+* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
+* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨

 ## 퍼시스턴트 볼륨

@@ -81,12 +81,6 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다.

-또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로
-레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋
-{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을
-막지 못한다. 사용자가 이와 같은 일을 하게 되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을
-수동으로 생성하는 것이다.
-
 ### 오직 일부 노드에서만 파드 실행

 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는