Merge pull request #25598 from pjhwa/outdated2-25522

Update outdated kubernetes-api.md file in the dev-1.19-ko.7

config.toml

@@ -138,12 +138,12 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.19"
+latest = "v1.20"
 
-fullversion = "v1.19.0"
+fullversion = "v1.19.4"
 version = "v1.19"
-githubbranch = "master"
+githubbranch = "v1.19.4"
-docsbranch = "master"
+docsbranch = "release-1.19"
 deprecated = false
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
@@ -183,40 +183,40 @@ js = [
 ]
 
 [[params.versions]]
-fullversion = "v1.19.0"
+fullversion = "v1.20.0"
-version = "v1.19"
+version = "v1.20"
-githubbranch = "v1.19.0"
+githubbranch = "v1.20.0"
 docsbranch = "master"
 url = "https://kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.18.8"
+fullversion = "v1.19.4"
+version = "v1.19"
+githubbranch = "v1.19.4"
+docsbranch = "release-1.19"
+url = "https://v1-19.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.18.12"
 version = "v1.18"
-githubbranch = "v1.18.8"
+githubbranch = "v1.18.12"
 docsbranch = "release-1.18"
 url = "https://v1-18.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.17.11"
+fullversion = "v1.17.14"
 version = "v1.17"
-githubbranch = "v1.17.11"
+githubbranch = "v1.17.14"
 docsbranch = "release-1.17"
 url = "https://v1-17.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.16.14"
+fullversion = "v1.16.15"
 version = "v1.16"
-githubbranch = "v1.16.14"
+githubbranch = "v1.16.15"
 docsbranch = "release-1.16"
 url = "https://v1-16.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.15.12"
-version = "v1.15"
-githubbranch = "v1.15.12"
-docsbranch = "release-1.15"
-url = "https://v1-15.docs.kubernetes.io"
-
 
 # User interface configuration
 [params.ui]

content/ko/docs/concepts/cluster-administration/networking.md

@@ -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)" 모델이라고 
+한다.
 
 이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다.
 

content/ko/docs/concepts/cluster-administration/system-metrics.md

@@ -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에서 수집한 메트릭을 비활성화한다.
 
 ## 컴포넌트 메트릭
 

content/ko/docs/concepts/configuration/secret.md

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

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

@@ -75,19 +75,10 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
 IDL(인터페이스 정의 언어) 파일을 참고한다.
 
-## API 변경 사항
+## 지속성
 
-성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
+쿠버네티스는 오브젝트의 직렬화된 상태를
-따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 기능을 설계했다.
+{{< glossary_tooltip term_id="etcd" >}}에 기록하여 저장한다.
-쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
-적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
-
-일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
-리소스 또는 필드를 제거하려면
-[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
-
-호환 가능한 변경 사항과 API 변경 방법은
-[API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에 자세히 설명되어 있다.
 
 ## API 그룹과 버전 규칙
 
@@ -105,29 +96,44 @@ API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를
 가능한 [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 구현한다.
 
 API 리소스는 API 그룹, 리소스 유형, 네임스페이스
-(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는
+(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 API 버전 간의
-여러 API 버전을 통해 동일한 기본 데이터를 제공하고 API 버전 간의
+변환을 투명하게 처리한다. 서로 다른 모든 버전은 실제로
-변환을 투명하게 처리할 수 있다. 이 모든 다른 버전은 실제로
+동일한 지속 데이터의 표현이다. API 서버는 여러 API 버전을 통해
-같은 리소스의 표현이다. 예를 들어 동일한 리소스에 대해
+동일한 기본 데이터를 제공할 수 있다.
-두 가지 버전 `v1`과 `v1beta1`이 있다고 가정해 보자.
-`v1beta1` 버전에서 생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서
-읽기, 업데이트 및 삭제할 수 있다.
 
-API 버전 수준 정의에 대한 자세한 내용은
+예를 들어, 동일한 리소스에 대해  `v1` 과 `v1beta1` 이라는 두 가지 API 버전이
-[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다.
+있다고 가정한다. 원래 API의 `v1beta1` 버전을 사용하여 오브젝트를
+만든 경우, 나중에 `v1beta1` 또는 `v1` API 버전을 사용하여 해당 오브젝트를
+읽거나, 업데이트하거나, 삭제할 수 있다.
 
-API 리소스는 해당 API 그룹, 리소스 유형, 네임스페이스
+## API 변경 사항
-(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 여러 API 버전을 통해 동일한
+
-기본 데이터를 제공하고 API 버전 간의 변환을 투명하게
+성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
-처리할 수 있다. 이 모든 다른 버전은 실제로
+따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 설계했다.
-동일한 리소스의 표현이다. 예를 들어, 동일한 리소스에 대해 두 가지
+쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
-버전 `v1` 과 `v1beta1` 이 있다고 가정한다. 그런 다음 `v1beta1` 버전에서
+적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
-생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서 읽고 업데이트하고
+
-삭제할 수 있다.
+일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
+리소스 또는 필드를 제거하려면
+[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
+
+쿠버네티스는 일반적으로 API 버전 `v1` 에서 안정 버전(GA)에 도달하면, 공식 쿠버네티스 API에
+대한 호환성 유지를 강력하게 이행한다. 또한,
+쿠버네티스는 가능한 경우 _베타_ API 버전에서도 호환성을 유지한다.
+베타 API를 채택하면 기능이 안정된 후에도 해당 API를 사용하여 클러스터와
+계속 상호 작용할 수 있다.
+
+{{< note >}}
+쿠버네티스는 또한 _알파_ API 버전에 대한 호환성을 유지하는 것을 목표로 하지만, 일부
+상황에서는 호환성이 깨진다. 알파 API 버전을 사용하는 경우, API가 변경된 경우 클러스터를
+업그레이드할 때 쿠버네티스에 대한 릴리스 정보를 확인한다.
+{{< /note >}}
 
 API 버전 수준 정의에 대한 자세한 내용은
 [API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
 
+
+
 ## API 확장
 
 쿠버네티스 API는 다음 두 가지 방법 중 하나로 확장할 수 있다.
@@ -145,3 +151,5 @@ API 버전 수준 정의에 대한 자세한 내용은
   클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다.
 - [API 레퍼런스](/docs/reference/kubernetes-api/)를
   읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기.
+- [API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에서
+  호환 가능한 변경 사항을 구성하고, API를 변경하는 방법에 대해 알아본다.

content/ko/docs/concepts/overview/working-with-objects/labels.md

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

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

@@ -13,8 +13,8 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
 클러스터와 함께 자동으로 실행되지 않는다.
 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
 
-프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/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) 컨트롤러를 지원하고 유지한다.
+  [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).
+* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
-* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의
+* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
-  [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는
+  컨트롤러다.
-  [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
+* [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
-* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
+  Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
-* [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/) 기반 인그레스 컨트롤러다.
-* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
+* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
-  VMware에서 제공하고 지원한다.
+  이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
-* 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)를 제공한다.
+* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
-* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨테이너 인그레스 서비스](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한
+  오픈소스 인그레스 컨트롤러다.
-  [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다.
+* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](http://www.haproxy.org/#desc)의
-* [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 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](http://www.haproxy.org/#desc) 용
-* [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/)는 인그레스 컨트롤러 기반으로
+* [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/)
-  [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/).
+  기반 인그레스 컨트롤러다.
-* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한
+* [쿠버네티스 용 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller#readme)는 [Kong 게이트웨이](https://konghq.com/kong/)를
-  [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는
+  구동하는 인그레스 컨트롤러다.
-  [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다.
+* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)는 [NGINX](https://www.nginx.com/resources/glossary)
-* [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 라우터 및 역방향 프록시다.
-* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
+* [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
-* [Traefik](https://github.com/traefik/traefik)은
+  [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.
-  모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로,
+* [Voyager](https://appscode.com/products/voyager)는
-  [Traefik Labs](https://traefik.io)에서 상업적인 지원을 제공한다.
+  [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).
+

content/ko/docs/concepts/storage/persistent-volumes.md

@@ -304,26 +304,35 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
 
 퍼시스턴트볼륨 유형은 플러그인으로 구현된다. 쿠버네티스는 현재 다음의 플러그인을 지원한다.
 
-* GCEPersistentDisk
+* [`awsElasticBlockStore`](/ko/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store(EBS)
-* AWSElasticBlockStore
+* [`azureDisk`](/ko/docs/concepts/sotrage/volumes/#azuredisk) - Azure Disk
-* AzureFile
+* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File
-* AzureDisk
+* [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨
-* CSI
+* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder(OpenStack 블록 스토리지)
-* FC (파이버 채널)
+  (**사용 중단됨**)
-* FlexVolume
+* [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스(CSI)
-* Flocker
+* [`fc`](/ko/docs/concepts/storage/volumes/#fc) - 파이버 채널(FC) 스토리지
-* NFS
+* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexvolume) - FlexVolume
-* iSCSI
+* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
-* RBD (Ceph Block Device)
+* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE 영구 디스크
-* CephFS
+* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
-* Cinder (OpenStack 블록 스토리지)
+* [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨
-* Glusterfs
+  (단일 노드 테스트 전용임. 다중-노드 클러스터에서는 동작하지 않음!
-* VsphereVolume
+  대신 `local` 볼륨을 사용하는 것을 고려할 것)
-* Quobyte Volumes
+* [`iscsi`](/ko/docs/concepts/storage/volumes/#iscsi) - iSCSI(SCSI over IP) 스토리지
-* HostPath (단일 노드 테스트 전용 – 로컬 스토리지는 어떤 방식으로도 지원되지 않으며 다중-노드 클러스터에서 작동하지 않음)
+* [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
-* Portworx Volumes
+  로컬 스토리지 디바이스.
-* ScaleIO Volumes
+* [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - Network File System(NFS) 스토리지
-* StorageOS
+* `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 볼륨
 
 ## 퍼시스턴트 볼륨
 

content/ko/docs/concepts/workloads/controllers/daemonset.md

@@ -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` 를 명시하면 데몬셋 컨트롤러는

content/ko/docs/reference/command-line-tools-reference/feature-gates.md

@@ -380,9 +380,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
    자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을
    참고한다.
 - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을
-   마이그레이션한다.
+   마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을
-   자세한 내용은 [서비스 어카운트 토큰 볼륨](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)을
+   사용하여 확장 토큰에 의존하는 워크로드를 모니터링할 수 있다. 이러한 워크로드가
-   확인한다.
+   없는 경우 `--service-account-extend-token-expiration=false` 플래그로 `kube-apiserver`를 시작하여 확장 토큰을 끈다.
+   [바인딩된 서비스 어카운트 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다.
 - `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다.
 - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
 - `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다.

content/ko/docs/reference/kubectl/cheatsheet.md

@@ -305,9 +305,10 @@ mynamespace                                         # 특정 네임스페이스
 kubectl run nginx --image=nginx                     # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
 --dry-run=client -o yaml > pod.yaml
 
-kubectl attach my-pod -i                            # 실행중인 컨테이너에 연결
+kubectl attach my-pod -i                            # 실행 중인 컨테이너에 연결
 kubectl port-forward my-pod 5000:6000               # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달
 kubectl exec my-pod -- ls /                         # 기존 파드에서 명령 실행(한 개 컨테이너 경우)
+kubectl exec --stdin --tty my-pod -- /bin/sh        # 실행 중인 파드로 대화형 셸 액세스(1 컨테이너 경우)
 kubectl exec my-pod -c my-container -- ls /         # 기존 파드에서 명령 실행(멀티-컨테이너 경우)
 kubectl top pod POD_NAME --containers               # 특정 파드와 해당 컨테이너에 대한 메트릭 표시
 ```

content/ko/docs/setup/production-environment/container-runtimes.md

@@ -119,7 +119,7 @@ sudo apt-get update && sudo apt-get install -y containerd.io
 ```shell
 # containerd 구성
 sudo mkdir -p /etc/containerd
-sudo containerd config default > /etc/containerd/config.toml
+sudo containerd config default | sudo tee /etc/containerd/config.toml
 ```
 
 ```shell

content/ko/examples/application/job/cronjob.yaml

@@ -11,6 +11,7 @@ spec:
           containers:
           - name: hello
             image: busybox
+            imagePullPolicy: IfNotPresent
             args:
             - /bin/sh
             - -c

content/ko/examples/application/mysql/mysql-configmap.yaml

@@ -5,12 +5,12 @@ metadata:
   labels:
     app: mysql
 data:
-  master.cnf: |
+  primary.cnf: |
-    # Apply this config only on the master.
+    # Primary에만 이 구성을 적용한다.
     [mysqld]
     log-bin
-  slave.cnf: |
+  replica.cnf: |
-    # Apply this config only on slaves.
+    # 레플리카에만 이 구성을 적용한다.
     [mysqld]
     super-read-only
 

content/ko/examples/application/mysql/mysql-services.yaml

@@ -1,4 +1,4 @@
-# Headless service for stable DNS entries of StatefulSet members.
+# 스테이트풀셋 멤버의 안정적인 DNS 엔트리를 위한 헤드리스 서비스.
 apiVersion: v1
 kind: Service
 metadata:
@@ -13,8 +13,8 @@ spec:
   selector:
     app: mysql
 ---
-# Client service for connecting to any MySQL instance for reads.
+# 읽기용 MySQL 인스턴스에 연결하기 위한 클라이언트 서비스.
-# For writes, you must instead connect to the master: mysql-0.mysql.
+# 쓰기용은 Primary인 mysql-0.mysql에 대신 연결해야 한다.
 apiVersion: v1
 kind: Service
 metadata:

content/ko/examples/application/mysql/mysql-statefulset.yaml

@@ -21,17 +21,17 @@ spec:
         - "-c"
         - |
           set -ex
-          # Generate mysql server-id from pod ordinal index.
+          # 파드의 원래 인덱스에서 mysql server-id를 생성.
           [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
           ordinal=${BASH_REMATCH[1]}
           echo [mysqld] > /mnt/conf.d/server-id.cnf
-          # Add an offset to avoid reserved server-id=0 value.
+          # 예약된 server-id=0 값을 피하기 위해 오프셋 추가.
           echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
-          # Copy appropriate conf.d files from config-map to emptyDir.
+          # config-map에서 emptyDir로 적당한 conf.d 파일들을 복사.
           if [[ $ordinal -eq 0 ]]; then
-            cp /mnt/config-map/master.cnf /mnt/conf.d/
+            cp /mnt/config-map/primary.cnf /mnt/conf.d/
           else
-            cp /mnt/config-map/slave.cnf /mnt/conf.d/
+            cp /mnt/config-map/replica.cnf /mnt/conf.d/
           fi
         volumeMounts:
         - name: conf
@@ -45,15 +45,15 @@ spec:
         - "-c"
         - |
           set -ex
-          # Skip the clone if data already exists.
+          # 데이터가 이미 존재하면 복제 생략. 
           [[ -d /var/lib/mysql/mysql ]] && exit 0
-          # Skip the clone on master (ordinal index 0).
+          # Primary에 복제 생략(ordinal index 0).
           [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
           ordinal=${BASH_REMATCH[1]}
           [[ $ordinal -eq 0 ]] && exit 0
-          # Clone data from previous peer.
+          # 이전 피어(peer)에서 데이터 복제.
           ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
-          # Prepare the backup.
+          # 백업 준비.
           xtrabackup --prepare --target-dir=/var/lib/mysql
         volumeMounts:
         - name: data
@@ -88,7 +88,7 @@ spec:
           timeoutSeconds: 5
         readinessProbe:
           exec:
-            # Check we can execute queries over TCP (skip-networking is off).
+            # TCP 상에서 쿼리를 실행할 수 있는지 확인(skip-networking은 off).
             command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
           initialDelaySeconds: 5
           periodSeconds: 2
@@ -105,22 +105,22 @@ spec:
           set -ex
           cd /var/lib/mysql
 
-          # Determine binlog position of cloned data, if any.
+          # 복제된 데이터의 binlog 위치를 확인.
           if [[ -f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then
-            # XtraBackup already generated a partial "CHANGE MASTER TO" query
+            # XtraBackup은 기존 레플리카에서 복제하기 때문에
-            # because we're cloning from an existing slave. (Need to remove the tailing semicolon!)
+            # 일부 "CHANGE MASTER TO" 쿼리는 이미 생성했음. (테일링 세미콜론을 제거해야 한다!)
             cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in
-            # Ignore xtrabackup_binlog_info in this case (it's useless).
+            # 이 경우에는 xtrabackup_binlog_info는 무시(필요없음).
             rm -f xtrabackup_slave_info xtrabackup_binlog_info
           elif [[ -f xtrabackup_binlog_info ]]; then
-            # We're cloning directly from master. Parse binlog position.
+            # Primary로부터 직접 복제함. binlog 위치를 파싱.
             [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
             rm -f xtrabackup_binlog_info xtrabackup_slave_info
             echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
                   MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
           fi
 
-          # Check if we need to complete a clone by starting replication.
+          # Replication을 시작하여 복제를 완료해야 하는지 확인.
           if [[ -f change_master_to.sql.in ]]; then
             echo "Waiting for mysqld to be ready (accepting connections)"
             until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done
@@ -133,11 +133,11 @@ spec:
                           MASTER_PASSWORD='', \
                           MASTER_CONNECT_RETRY=10; \
                         START SLAVE;" || exit 1
-            # In case of container restart, attempt this at-most-once.
+            # 컨테이너가 다시 시작하는 경우, 이 작업을 한번만 시도한다.
             mv change_master_to.sql.in change_master_to.sql.orig
           fi
 
-          # Start a server to send backups when requested by peers.
+          # 피어가 요청할 때 서버를 시작하여 백업을 보냄.
           exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \
             "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"
         volumeMounts: