Merge pull request #24592 from kubernetes/dev-1.19-ko.3

Third Korean l10n work for release-1.19
2020-10-16 00:55:25 -07:00
parent 505cf30788 a6566dc277
commit 6d050e326b
56 changed files with 1389 additions and 844 deletions
@@ -16,7 +16,7 @@ aliases:

 ## 노드에서 컨트롤 플레인으로의 통신
 쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
-특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
+특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.

 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.

@@ -47,11 +47,11 @@ no_list: true

 * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.

-* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다.
+* [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다.

 * [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.

-* [인가](/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
+* [인가](/ko/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.

 * [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.

@@ -214,6 +214,7 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파
 지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).

+환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
 ## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}

 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
@@ -134,7 +134,6 @@ spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
-    env:
    resources:
      requests:
        memory: "64Mi"
@@ -8,7 +8,7 @@ weight: 70

 {{< feature-state for_k8s_version="v1.14" state="stable" >}}

-[파드](/ko/docs/concepts/workloads/pods/pod/)는 _우선순위_ 를 가질 수 있다. 우선순위는
+[파드](/ko/docs/concepts/workloads/pods/)는 _우선순위_ 를 가질 수 있다. 우선순위는
 다른 파드에 대한 상대적인 파드의 중요성을 나타낸다. 파드를 스케줄링할 수 없는 경우,
 스케줄러는 우선순위가 낮은 파드를 선점(축출)하여 보류 중인 파드를
 스케줄링할 수 있게 한다.
@@ -35,6 +35,12 @@ weight: 30
 - [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
 - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.

+시크릿 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
+
+`data` 와 `stringData` 의 키는 영숫자 및 `-`, `_` 또는 `.` 으로
+구성되어야 한다.
+
 ### 빌트인 시크릿

 #### 서비스 어카운트는 API 자격 증명으로 시크릿을 자동으로 생성하고 연결함
@@ -50,401 +56,15 @@ weight: 30
 서비스 어카운트 작동 방식에 대한 자세한 내용은
 [서비스어카운트(ServiceAccount)](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 참고한다.

-### 자신만의 시크릿 생성하기
+### 시크릿 생성하기

-#### `kubectl` 사용하여 시크릿 생성하기
+시크릿을 생성하기 위한 몇 가지 옵션이 있다.

-시크릿에는 파드가 데이터베이스에 접근하는 데 필요한 사용자 자격 증명이 포함될 수 있다.
-예를 들어, 데이터베이스 연결 문자열은
-사용자명(username)과 비밀번호(password)로 구성된다. 사용자명은 `./username.txt` 파일에
-저장하고 비밀번호는 로컬 시스템의 `./password.txt` 파일에 저장할 수 있다.
+- [`kubectl` 명령을 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)

-```shell
-# 예제를 위해서 필요한 파일들을 생성한다.
-echo -n 'admin' > ./username.txt
-echo -n '1f2d1e2e67df' > ./password.txt
-```
-
-`kubectl create secret` 명령은 이러한 파일을 시크릿으로 패키징하고
-API 서버에 오브젝트를 생성한다.
-시크릿 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
-
-```shell
-kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-secret "db-user-pass" created
-```
-
-기본 키 이름은 파일명(filename)이다. 선택적으로 `--from-file=[key=]source]` 를 사용하여 키 이름을 설정할 수 있다.
-
-```shell
-kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt
-```
-
-{{< note >}}
-`$`, `\`, `*`, `=`, 그리고 `!` 등의 특수 문자는 [셸](https://ko.wikipedia.org/wiki/셸)에 의해 해석되고 이스케이핑이 필요하다.
-대부분의 셸에서, 비밀번호를 이스케이프하는 가장 쉬운 방법은 작은 따옴표(`'`)로 묶는 것이다.
-예를 들어, 실제 비밀번호가 `S!B\*d$zDsb=` 이면, 다음과 같은 명령을 실행해야 한다.
-
-```shell
-kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
-```
-
-파일(`--from-file`)에서는 비밀번호의 특수 문자를 이스케이프할 필요가 없다.
-{{< /note >}}
-
-다음의 명령으로 시크릿이 생성되었는지 확인할 수 있다.
-
-```shell
-kubectl get secrets
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-NAME                  TYPE                                  DATA      AGE
-db-user-pass          Opaque                                2         51s
-```
-
-시크릿에 대한 설명을 볼 수 있다.
-
-```shell
-kubectl describe secrets/db-user-pass
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-Name:            db-user-pass
-Namespace:       default
-Labels:          <none>
-Annotations:     <none>
-
-Type:            Opaque
-
-Data
-====
-password.txt:    12 bytes
-username.txt:    5 bytes
-```
-
-{{< note >}}
-`kubectl get` 명령과 `kubectl describe` 명령은 기본적으로 시크릿의 내용을 표시하지
-않는다. 이는 시크릿이 우연히 다른 사람에게 노출되거나,
-터미널 로그에 저장되지 않도록 보호하기 위함이다.
-{{< /note >}}
-
-시크릿 내용을 보는 방법을 익히기 위해서는 [시크릿 디코딩하기](#시크릿-디코딩하기)를 참고한다.
-
-#### 수동으로 시크릿 생성하기
-
-먼저 JSON 또는 YAML 형식으로 파일에 시크릿을 생성한
-다음 해당 오브젝트를 생성할 수도 있다.
-시크릿 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
-[시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)은
-두 개의 맵(`data` 와 `stringData`)을
-포함한다. `data` 필드는 base64를 사용하여, 인코딩된 임의 데이터를 저장하는 데
-사용된다. `stringData` 필드는 편의를 위해 제공되며, 시크릿 데이터를 인코딩되지 않은
-문자열로 제공할 수 있다.
-
-예를 들어, `data` 필드를 사용하여 시크릿에 두 개의 문자열을 저장하려면, 다음과 같이
-문자열을 base64로 변환한다.
-
-```shell
-echo -n 'admin' | base64
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-YWRtaW4=
-```
-
-```shell
-echo -n '1f2d1e2e67df' | base64
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-MWYyZDFlMmU2N2Rm
-```
-
-다음과 같은 시크릿을 작성한다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: mysecret
-type: Opaque
-data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
-```
-
-이제 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)를 사용하여 시크릿을 생성한다.
-
-```shell
-kubectl apply -f ./secret.yaml
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-secret "mysecret" created
-```
-
-특정 시나리오의 경우, `stringData` 필드를 대신 사용할 수 있다. 이
-필드를 사용하면 base64로 인코딩되지 않은 문자열을 시크릿에 직접 넣을 수 있으며,
-시크릿이 생성되거나 업데이트될 때 문자열이 인코딩된다.
-
-이에 대한 실질적인 예는 애플리케이션 배포 시에
-구성 파일 저장을 위해서 시크릿을 사용하되, 배포 프로세스 중에 해당 구성 파일의
-일부를 채우려는 경우이다.
-
-예를 들어, 애플리케이션이 다음 구성 파일을 사용하는 경우,
-
-```yaml
-apiUrl: "https://my.api.com/api/v1"
-username: "user"
-password: "password"
-```
-
-다음 정의를 사용하여 이를 시크릿에 저장할 수 있다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: mysecret
-type: Opaque
-stringData:
-  config.yaml: |-
-    apiUrl: "https://my.api.com/api/v1"
-    username: {{username}}
-    password: {{password}}
-```
-
-그런 다음 `kubectl apply` 를 실행하기 전에 배포 도구로
-`{{username}}` 및 `{{password}}` 템플릿 변수를 바꿀 수 있다.
-
-`stringData` 필드는 쓰기 전용의 편의 필드이다. 이 내용은 시크릿을
-검색할 때 출력되지 않는다. 예를 들어, 다음 명령을 실행해본다.
-
-```shell
-kubectl get secret mysecret -o yaml
-```
-
-출력 결과는 다음과 비슷하다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2018-11-15T20:40:59Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "7225"
-  uid: c280ad2e-e916-11e8-98f2-025000000001
-type: Opaque
-data:
-  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
-```
-
-`username` 과 같은 필드가 `data` 와 `stringData` 모두에 지정되면,
-`stringData` 의 값이 사용된다. 예를 들어, 다음의 시크릿 정의를 보자.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: mysecret
-type: Opaque
-data:
-  username: YWRtaW4=
-stringData:
-  username: administrator
-```
-
-아래의 시크릿에서 결과는 다음과 같다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2018-11-15T20:46:46Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "7579"
-  uid: 91460ecb-e917-11e8-98f2-025000000001
-type: Opaque
-data:
-  username: YWRtaW5pc3RyYXRvcg==
-```
-
-위의 `YWRtaW5pc3RyYXRvcg==` 를 디코딩하면 `administrator` 가 된다.
-
-`data` 와 `stringData` 의 키는 영숫자,
-'-', '_' 또는 '.'로 구성되어야 한다.
-
-{{< note >}}
-시크릿 데이터의 직렬화된 JSON 및 YAML 값은
-base64 문자열로 인코딩된다. 줄바꿈은 이러한 문자열 내에서 유효하지 않으므로
-생략해야 한다. Darwin/macOS에서 `base64` 유틸리티를 사용할 때,
-사용자는 긴 라인을 분할하는 `-b` 옵션을 사용하면 안된다. 반대로, 리눅스 사용자는
-`-w` 옵션을 사용할 수 없는 경우 `base64` 명령이나 `base64 | tr -d '\n'` 파이프라인에
-`-w 0` 옵션을 추가 *해야 한다*.
-{{< /note >}}
-
-#### 생성기를 통해 시크릿 생성하기
-
-쿠버네티스 v1.14부터 `kubectl` 은 [Kustomize를 사용한 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)를 지원한다. Kustomize는 시크릿과 컨피그맵(ConfigMap)을 생성하기 위한
-리소스 생성기를 제공한다. Kustomize 생성기는 디렉터리 내의
-`kustomization.yaml` 파일에 지정되어야 한다. 시크릿을 생성한 후,
-`kubectl apply` 를 사용하여 API 서버에서 시크릿을 만들 수 있다.
-
-#### 파일을 통해 시크릿 생성하기
-
-./username.txt 와 ./password.txt 파일에서
-`secretGenerator` 를 정의하여 시크릿을 생성할 수 있다.
-
-```shell
-cat <<EOF >./kustomization.yaml
-secretGenerator:
- name: db-user-pass
-  files:
-  - username.txt
-  - password.txt
-EOF
-```
-
-`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
-
-```shell
-kubectl apply -k .
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-secret/db-user-pass-96mffmfh4k created
-```
-
-시크릿이 생성되었는지 다음의 명령으로 확인할 수 있다.
-
-```shell
-kubectl get secrets
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-NAME                             TYPE                                  DATA      AGE
-db-user-pass-96mffmfh4k          Opaque                                2         51s
-```
-
-시크릿에 대한 설명을 볼 수 있다.
-
-```shell
-kubectl describe secrets/db-user-pass-96mffmfh4k
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-Name:            db-user-pass
-Namespace:       default
-Labels:          <none>
-Annotations:     <none>
-
-Type:            Opaque
-
-Data
-====
-password.txt:    12 bytes
-username.txt:    5 bytes
-```
-
-#### 문자열 리터럴(literals)을 통해 시크릿 생성하기
-
-문자열 리터럴인 `username=admin` 과 `password=secret` 을
-`secretGenerator` 에 정의하여 시크릿을 만들 수 있다.
-
-```shell
-cat <<EOF >./kustomization.yaml
-secretGenerator:
- name: db-user-pass
-  literals:
-  - username=admin
-  - password=secret
-EOF
-```
-
-`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
-
-```shell
-kubectl apply -k .
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-secret/db-user-pass-dddghtt9b5 created
-```
-
-{{< note >}}
-시크릿이 생성될 때, 시크릿의 이름은 시크릿 데이터를
-해시하고, 해시된 값을 이름에 추가하는 방식으로 만들어진다. 이 방식은
-데이터가 수정될 때마다 새로운 시크릿이 생성되도록 만든다.
-{{< /note >}}
-
-#### 시크릿 디코딩하기
-
-`kubectl get secret` 을 실행하여 시크릿을 검색할 수 있다.
-예를 들어, 다음 명령을 실행하여 이전 섹션에서
-생성된 시크릿을 볼 수 있다.
-
-```shell
-kubectl get secret mysecret -o yaml
-```
-
-출력 결과는 다음과 비슷하다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2016-01-22T18:41:56Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "164619"
-  uid: cfee02d6-c137-11e5-8d73-42010af00002
-type: Opaque
-data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
-```
-
-`password` 필드를 디코딩한다.
-
-```shell
-echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-1f2d1e2e67df
-```
-
-#### 시크릿 편집하기
+### 시크릿 편집하기

 기존 시크릿은 다음 명령을 사용하여 편집할 수 있다.

@@ -1273,3 +893,10 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
   API 서버에서 _모든_ 시크릿을 읽을 수 있다. 단일 노드에 대한 루트 취약점 공격의
   영향을 제한하기 위해, 실제로 필요한 노드에만 시크릿을 보내는 것이 앞으로 계획된
   기능이다.
+
+
+## {{% heading "whatsnext" %}}
+
+- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
+- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
+- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
@@ -77,7 +77,7 @@ handler: myconfiguration  # 상응하는 CRI 설정의 이름임
 {{< note >}}
 런타임클래스 쓰기 작업(create/update/patch/delete)은
 클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
-더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
+더 자세한 정보는 [권한 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참고한다.
 {{< /note >}}

 ## 사용
@@ -126,7 +126,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치

 ### API 접근 익스텐션

-요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
+요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.

 이러한 각 단계는 익스텐션 포인트를 제공한다.

@@ -253,6 +253,6 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 * 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
 * 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
 * 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
-* [토폴로지 관리자](/docs/tasks/adminster-cluster/topology-manager/)에 대해 알아보기
+* [토폴로지 관리자](/docs/tasks/administer-cluster/topology-manager/)에 대해 알아보기


@@ -127,7 +127,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치

 ### API 접근 익스텐션

-요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
+요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.

 이러한 각 단계는 익스텐션 포인트를 제공한다.

@@ -3,7 +3,7 @@ title: 쿠버네티스 API
 content_type: concept
 weight: 30
 description: >
-  쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다. 
+  쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다.
  쿠버네티스 컨트롤 플레인의 핵심은 API 서버와 그것이 노출하는 HTTP API이다. 사용자와 클러스터의 다른 부분 및 모든 외부 컴포넌트는 API 서버를 통해 서로 통신한다.
 card:
  name: concepts
@@ -20,24 +20,17 @@ card:
 쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예:
 파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다.

-API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/ko/docs/reference)에 기술되어 있다.
+대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
+커맨드 라인 인터페이스 또는 API를 사용하는
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과
+같은 다른 커맨드 라인 도구를 통해 수행할 수 있다.
+그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다.
+
+쿠버네티스 API를 사용하여 애플리케이션을 작성하는 경우
+[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다.

 <!-- body -->

-## API 변경
-
-새로운 유스케이스가 등장하거나 기존 시스템이 변경됨에 따라 성공적인 시스템은 성장하고 변경될 필요가 있다.
-따라서, 쿠버네티스는 쿠버네티스 API를 지속적으로 변경하고 성장시킬 수 있는 디자인 기능을 가지고 있다.
-쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 중단하지 _않고_,
-다른 프로젝트가 적응할 수 있도록 오랫동안 호환성을 유지하는 것을 목표로 한다.
-
-일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다.
-리소스나 필드를 없애는 일은 다음의
-[API 사용 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따른다.
-
-호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은
-[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)을 참고한다.
-
 ## OpenAPI 명세 {#api-specification}

 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다.
@@ -76,96 +69,58 @@ OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
  <caption>Valid request header values for OpenAPI v2 queries</caption>
 </table>

-쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다.
+쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인
+Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
+자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 디자인 제안과
+API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
+IDL(인터페이스 정의 언어) 파일을 참고한다.

-## API 버전 규칙
+## API 변경 사항

-필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
-쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이
-각각 다른 API 경로에서 복수의 API 버전을 지원한다.
+성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
+따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 기능을 설계했다.
+쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
+적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.

-버전 관리는 API가 시스템 리소스와 동작에 대해 명확하고 일관된 보기를
-제공하고 수명 종료(end-of-life)와 실험적인 API에 대한 접근을 제어할 수 있도록
-리소스 또는 필드 수준이 아닌 API 수준에서 수행된다.
+일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
+리소스 또는 필드를 제거하려면
+[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.

-JSON과 Protobuf 직렬화 스키마는 스키마 변경에 대한 동일한 지침을 따르며 아래의 모든 설명은 두 형식을 모두 포함한다.
+호환 가능한 변경 사항과 API 변경 방법은
+[API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에 자세히 설명되어 있다.

-참고로 API 버전 관리와 소프트웨어 버전 관리는 간접적으로만 연관이 있다.
-[쿠버네티스 릴리스 버전 관리](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
-제안은 API 버전 관리와 소프트웨어 버전 관리 사이의 관계를 설명한다.
+## API 그룹과 버전 규칙

-API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은
-[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서
-상세히 다룬다. 요약하자면 다음과 같다.
+필드를 쉽게 제거하거나 리소스 표현을 재구성하기 위해,
+쿠버네티스는 각각 `/api/v1` 또는 `/apis/rbac.authorization.k8s.io/v1alpha1` 과
+같은 서로 다른 API 경로에서 여러 API 버전을 지원한다.

- 알파(Alpha) 수준:
-  - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
-  - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다.
-  - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
-  - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
-  - 버그의 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
- 베타(Beta) 수준:
-  - 버전 이름에 `beta`가 포함된다. (예: `v2beta3`).
-  - 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
-  - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
-  - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우,
-    다음 버전으로 이관할 수 있는 가이드를 제공할 것이다.
-    이 때 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
-  - 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다.
-    복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다.
-  - **베타 기능을 사용하고 피드백을 주기를 바란다! 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.**
- 안정화(stable) 수준:
-  - 버전 이름이 `vX`이고 `X` 는 정수다.
-  - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.
+버전 규칙은 리소스나 필드 수준이 아닌 API 수준에서 수행되어
+API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를 제공하고
+수명 종료 및/또는 실험적 API에 대한 접근을
+제어할 수 있도록 한다.

-## API 그룹
+API 버전 수준 정의에 대한 자세한 내용은
+[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.

-쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다.
-API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
+보다 쉽게 발전하고 API를 확장하기 위해, 쿠버네티스는
+[활성화 또는 비활성화](/ko/docs/reference/using-api/api-overview/#api-그룹-활성화-또는-비활성화-하기)가
+가능한 [API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 구현한다.

-클러스터에 다양한 API 그룹이 있다.
+## API 확장

-1. *레거시* 그룹이라고도 하는 *핵심* 그룹은 REST 경로인 `/api/v1/` 에 있고, `apiVersion: v1`을 사용한다.
-
-1. 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
-  (예: `apiVersion: batch/v1`). 사용 가능한 API 그룹의 전체의 목록은
-  [쿠버네티스 API 참조](/ko/docs/reference/)에 있다.
-
-
-[사용자 지정 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 두 가지 방법이 있다.
-
-1. [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)은
-   API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다.
-1. 또한, [자신의 확장 API 서버 구현](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/)과
-   [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를
-   사용해서 클라이언트를 원활하게 만들 수 있다.
-
-
-## API 그룹 활성화 또는 비활성화하기
-
-특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. kube-apiserver에서 커맨드 라인 옵션으로 `--runtime-config` 를
-설정해서 활성화하거나 비활성화할 수 있다.
-
-`--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화시키려면,
-`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화시키려면, `--runtime-config=batch/v2alpha1`을
-설정한다. 이 플래그는 API 서버의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
-
-{{< note >}}그룹이나 리소스를 활성화 또는 비활성화하려면 kube-apiserver와
-controller-manager를 재시작해서 `--runtime-config` 변경 사항을 반영해야 한다. {{< /note >}}
-
-## 지속성
-
-쿠버네티스는 API 리소스에 대한 직렬화된 상태를 {{< glossary_tooltip term_id="etcd" >}}에
-기록하고 저장한다.
+쿠버네티스 API는 다음 두 가지 방법 중 하나로 확장할 수 있다.

+1. [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를
+   사용하면 API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다.
+1. [애그리게이션 레이어(aggregation layer)](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
+   구현하여 쿠버네티스 API를 확장할 수도 있다.

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

-[API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)는 클러스터가
-API 접근에 대한 인증과 권한을 관리하는 방법을 설명한다.
-
-전체 API 규약은
-[API 규약](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
-문서에 설명되어 있다.
-
-API 엔드포인트, 리소스 타입과 샘플은 [API 참조](/docs/reference/kubernetes-api/)에 설명되어 있다.
+- 자체 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)을
+  추가하여 쿠버네티스 API를 확장하는 방법에 대해 배우기.
+- [API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)는
+  클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다.
+- [API 레퍼런스](/docs/reference/kubernetes-api/)를
+  읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기.
@@ -63,7 +63,7 @@ weight: 50

 ## 문법과 캐릭터 셋

-_어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(`/`)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자(`[a-z0-9A-Z]`)로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(`-`), 밑줄(`_`), 점(`.`)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 하위 도메인이어야 한다. 점(`.`)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(`/`)가 붙는다.
+_어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(`/`)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자(`[a-z0-9A-Z]`)로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(`-`), 밑줄(`_`), 점(`.`)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 서브도메인이어야 한다. 점(`.`)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(`/`)가 붙는다.

 접두사가 생략되면, 어노테이션 키는 사용자에게 비공개로 간주된다. 최종 사용자 오브젝트에 어노테이션을 추가하는 자동화된 시스템 구성 요소(예 :`kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, 또는 다른 써드파티 자동화)는 접두사를 지정해야 한다.

@@ -58,15 +58,15 @@ metadata:

 ## 애플리케이션과 애플리케이션 인스턴스

-애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에
-한번 또는 그 이상 설치할 수 있다. 예를 들어 워드프레스는 다른 워드프레스가
-설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다.
+애플리케이션은 동일한 쿠버네티스 클러스터에, 
+심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에
+워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.

-애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다.
-예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는 
-`app.kubernetes.io/instance` 에 `wordpress-abcxzy` 의 값을 가진다.
-이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다.
-모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
+애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. 
+예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며, 
+애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에 
+`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 
+식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.

 ## 예시

@@ -170,4 +170,3 @@ metadata:

 MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.

-
@@ -138,7 +138,7 @@ RBAC 바인딩에 대한 자세한 예는,
 ### 문제 해결

 - [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는
-[보안 API 포트](/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며,
+[보안 API 포트](/ko/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며,
 슈퍼유저 권한이 없어야 한다. 그렇지 않으면 요청이 인증 및 권한 부여 모듈을 우회하고,
 모든 파드시큐리티폴리시 오브젝트가 허용되며
 사용자는 특권있는 컨테이너를 만들 수 있다. 컨트롤러 관리자 권한 구성에 대한 자세한
@@ -206,6 +206,19 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.

 쿼터 스펙의 `scopeSelector`가 파드를 선택한 경우에만 쿼터가 일치하고 사용된다.

+`scopeSelector` 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면, 쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다.
+
+* `pods`
+* `cpu`
+* `memory`
+* `ephemeral-storage`
+* `limits.cpu`
+* `limits.memory`
+* `limits.ephemeral-storage`
+* `requests.cpu`
+* `requests.memory`
+* `requests.ephemeral-storage`
+
 이 예에서는 쿼터 오브젝트를 생성하여 특정 우선 순위의 파드와 일치시킨다.
 예제는 다음과 같이 작동한다.

@@ -69,17 +69,7 @@ spec:
 ## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels}

 [붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는
-표준 레이블 셋이 미리 채워져 있다. 이 레이블들은 다음과 같다.
-
-* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
-* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
-* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
-* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
-* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
-* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
-* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
+표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)를 참고한다.

 {{< note >}}
 이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다.
@@ -48,17 +48,10 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 이를 변경한 후에 다음을 실행해서

 ```bash
-kubectl get componentstatuses
+kubectl get pods -n kube-system | grep kube-scheduler
 ```

-kube-scheduler 컴포넌트가 정상인지 확인할 수 있다. 출력은 다음과 유사하다.
-
-```
-NAME                 STATUS    MESSAGE             ERROR
-controller-manager   Healthy   ok
-scheduler            Healthy   ok
-...
-```
+kube-scheduler 컴포넌트가 정상인지 확인할 수 있다.

 ## 노드 스코어링(scoring) 임계값 {#percentage-of-nodes-to-score}

@@ -147,7 +147,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
 * [파드 보안 표준](/docs/concepts/security/pod-security-standards/)
 * [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
 * [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)
-* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)
+* [API 접근 통제](/ko/docs/reference/access-authn-authz/controlling-access/)
 * 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
 * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
@@ -21,8 +21,8 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워

 엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
 간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
-{{< glossary_tooltip text="서비스" term_id="service" >}}가 점점 더
-커짐에 따라, 이 API의 한계가 더욱 눈에 띄게
+{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로
+더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
 되었다.
 특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
 어려움이 있었다.
@@ -27,15 +27,26 @@ weight: 40
 {{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.

-```none
-    internet
-        |
-   [ Ingress ]
-   --|-----|--
-   [ Services ]
-```
+다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.
+{{< mermaid >}}
+graph LR;
+  client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스];
+  ingress-->|라우팅 규칙|service[서비스];
+  subgraph 클러스터
+  ingress;
+  service-->pod1[파드];
+  service-->pod2[파드];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service,pod1,pod2 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}

-인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
+
+인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.

 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
 [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는
@@ -104,7 +115,7 @@ weight: 40

 ### 리소스 백엔드 {#resource-backend}

-`Resource` 백엔드는 인그레스 오브젝트의 동일한 네임스페이스 내에 있는
+`Resource` 백엔드는 인그레스 오브젝트와 동일한 네임스페이스 내에 있는
 다른 쿠버네티스 리소스에 대한 ObjectRef이다. `Resource` 는 서비스와
 상호 배타적인 설정이며, 둘 다 지정하면 유효성 검사에 실패한다. `Resource`
 백엔드의 일반적인 용도는 정적 자산이 있는 오브젝트 스토리지 백엔드로 데이터를
@@ -272,10 +283,25 @@ test-ingress   external-lb   *       203.0.113.123   80      59s
 트래픽을 라우팅 한다. 인그레스를 사용하면 로드 밸런서의 수를
 최소로 유지할 수 있다. 예를 들어 다음과 같은 설정을 한다.

-```
-foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
-                                 / bar    service2:8080
-```
+{{< mermaid >}}
+graph LR;
+  client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스, 178.91.123.132];
+  ingress-->|/foo|service1[서비스 service1:4200];
+  ingress-->|/bar|service2[서비스 service2:8080];
+  subgraph 클러스터
+  ingress;
+  service1-->pod1[파드];
+  service1-->pod2[파드];
+  service2-->pod3[파드];
+  service2-->pod4[파드];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}

 다음과 같은 인그레스가 필요하다.

@@ -319,11 +345,26 @@ Events:

 이름 기반의 가상 호스트는 동일한 IP 주소에서 여러 호스트 이름으로 HTTP 트래픽을 라우팅하는 것을 지원한다.

-```none
-foo.bar.com --|                 |-> foo.bar.com service1:80
-              | 178.91.123.132  |
-bar.foo.com --|                 |-> bar.foo.com service2:80
-```
+{{< mermaid >}}
+graph LR;
+  client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스, 178.91.123.132];
+  ingress-->|호스트: foo.bar.com|service1[서비스 service1:80];
+  ingress-->|호스트: bar.foo.com|service2[서비스 service2:80];
+  subgraph 클러스터
+  ingress;
+  service1-->pod1[파드];
+  service1-->pod2[파드];
+  service2-->pod3[파드];
+  service2-->pod4[파드];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
+

 다음 인그레스는 [호스트 헤더](https://tools.ietf.org/html/rfc7230#section-5.4)에 기반한 요청을
 라우팅 하기 위해 뒷단의 로드 밸런서를 알려준다.
@@ -22,8 +22,8 @@ weight: 10

 ## 동기

-쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 수명이 있다.
-파드는 생성되고, 소멸된 후 부활하지 않는다.
+쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 상태와
+일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다.
 만약 앱을 실행하기 위해 {{< glossary_tooltip term_id="deployment" text="디플로이먼트" >}}를 사용한다면,
 동적으로 파드를 생성하고 제거할 수 있다.

@@ -44,8 +44,8 @@ _서비스_ 로 들어가보자.
 정책을 정의하는 추상적 개념이다. (때로는 이 패턴을
 마이크로-서비스라고 한다.) 서비스가 대상으로 하는 파드 집합은 일반적으로
 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가 결정한다.
-(셀렉터가 _없는_ 서비스가 필요한 이유는 [아래](#셀렉터가-없는-서비스)를
-참조한다).
+서비스 엔드포인트를 정의하는 다른 방법에 대한 자세한 내용은
+[셀렉터가 _없는_ 서비스](#셀렉터가-없는-서비스)를 참고한다.

 예를 들어, 3개의 레플리카로 실행되는 스테이트리스 이미지-처리 백엔드를
 생각해보자. 이러한 레플리카는 대체 가능하다. 즉, 프론트엔드는 그것들이 사용하는 백엔드를
@@ -127,12 +127,12 @@ spec:
 다른 종류의 백엔드를 추상화할 수도 있다.
 예를 들면

-  * 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
-    테스트 환경에서는 자체 데이터베이스를 사용한다.
-  * 한 서비스에서 다른
-    {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 또는 다른 클러스터의 서비스를 지정하려고 한다.
-  * 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
-    쿠버네티스에서는 일정 비율의 백엔드만 실행한다.
+* 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
+  테스트 환경에서는 자체 데이터베이스를 사용한다.
+* 한 서비스에서 다른
+  {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 또는 다른 클러스터의 서비스를 지정하려고 한다.
+* 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
+  쿠버네티스에서는 일정 비율의 백엔드만 실행한다.

 이러한 시나리오 중에서 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다.
 예를 들면
@@ -150,7 +150,7 @@ spec:
 ```

 이 서비스에는 셀렉터가 없으므로, 해당 엔드포인트 오브젝트가 자동으로
-생성되지 *않는다*. 엔드포인트 오브젝트를 수동으로 추가하여, 서비스를 실행 중인 네트워크 주소 및 포트에
+생성되지 않는다. 엔드포인트 오브젝트를 수동으로 추가하여, 서비스를 실행 중인 네트워크 주소 및 포트에
 서비스를 수동으로 매핑할 수 있다.

 ```yaml
@@ -186,6 +186,7 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.

 ### 엔드포인트슬라이스
+
 {{< feature-state for_k8s_version="v1.17" state="beta" >}}

 엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
@@ -202,9 +203,8 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,

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

-AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프로토콜을
-지정하는 방법을 제공한다. 이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스에
-의해 미러링된다.
+`AppProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
+이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스 리소스에 의해 미러링된다.

 ## 가상 IP와 서비스 프록시

@@ -222,20 +222,19 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을

 서비스에 프록시를 사용하는 데는 몇 가지 이유가 있다.

- * 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를
-   캐싱하는 DNS 구현에 대한 오래된 역사가 있다.
- * 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다.
- * 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이
-   낮거나 0이면 DNS에 부하가 높아 관리하기가
-   어려워 질 수 있다.
+* 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를
+  캐싱하는 DNS 구현에 대한 오래된 역사가 있다.
+* 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다.
+* 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이
+  낮거나 0이면 DNS에 부하가 높아 관리하기가
+  어려워 질 수 있다.

 ### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace}

 이 모드에서는, kube-proxy는 쿠버네티스 마스터의 서비스, 엔드포인트 오브젝트의
 추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
 포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
-연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로
-프록시된다.
+연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로 프록시된다.
 kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
 `SessionAffinity` 설정을 고려한다.

@@ -296,12 +295,12 @@ IPVS 프록시 모드는 iptables 모드와 유사한 넷필터 후크 기능을
 IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을 제공한다.
 다음과 같다.

- `rr`: 라운드-로빈
- `lc`: 최소 연결 (가장 적은 수의 열려있는 연결)
- `dh`: 목적지 해싱
- `sh`: 소스 해싱
- `sed`: 최단 예상 지연 (shortest expected delay)
- `nq`: 큐 미사용 (never queue)
+* `rr`: 라운드-로빈
+* `lc`: 최소 연결 (가장 적은 수의 열려있는 연결)
+* `dh`: 목적지 해싱
+* `sh`: 소스 해싱
+* `sed`: 최단 예상 지연 (shortest expected delay)
+* `nq`: 큐 미사용 (never queue)

 {{< note >}}
 IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를
@@ -388,7 +387,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
 이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.

 예를 들어, TCP 포트 6379를 개방하고
-클러스터 IP 주소 10.0.0.11이 할당된 서비스 `"redis-master"`는,
+클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-master`는,
 다음 환경 변수를 생성한다.

 ```shell
@@ -421,18 +420,18 @@ CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위
 모든 파드는 DNS 이름으로 서비스를 자동으로
 확인할 수 있어야 한다.

-예를 들면, 쿠버네티스 네임스페이스 `"my-ns"`에 `"my-service"`라는
+예를 들면, 쿠버네티스 네임스페이스 `my-ns`에 `my-service`라는
 서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여
-`"my-service.my-ns"`에 대한 DNS 레코드를 만든다. `"my-ns"` 네임 스페이스의 파드들은
+`my-service.my-ns`에 대한 DNS 레코드를 만든다. `my-ns` 네임 스페이스의 파드들은
 간단히 `my-service`에 대한 이름 조회를 수행하여 찾을 수 있어야 한다
-(`"my-service.my-ns"` 역시 동작함).
+(`my-service.my-ns` 역시 동작함).

 다른 네임스페이스의 파드들은 이름을 `my-service.my-ns`으로 사용해야 한다. 이 이름은
 서비스에 할당된 클러스터 IP로 변환된다.

 쿠버네티스는 또한 알려진 포트에 대한 DNS SRV (서비스) 레코드를 지원한다.
-`"my-service.my-ns"` 서비스에 프로토콜이 `TCP`로 설정된 `"http"`라는 포트가 있는 경우,
-IP 주소와 `"http"`에 대한 포트 번호를 검색하기 위해 `_http._tcp.my-service.my-ns` 에 대한
+`my-service.my-ns` 서비스에 프로토콜이 `TCP`로 설정된 `http`라는 포트가 있는 경우,
+IP 주소와 `http`에 대한 포트 번호를 검색하기 위해 `_http._tcp.my-service.my-ns` 에 대한
 DNS SRV 쿼리를 수행할 수 있다.

 쿠버네티스 DNS 서버는 `ExternalName` 서비스에 접근할 수 있는 유일한 방법이다.
@@ -465,9 +464,9 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 `엔드포인트` 레코드를 생성하지 않는다. 그러나 DNS 시스템은 다음 중 하나를 찾고
 구성한다.

-  * [`ExternalName`](#externalname)-유형 서비스에 대한 CNAME 레코드
-  * 다른 모든 유형에 대해, 서비스의 이름을 공유하는 모든 `엔드포인트`에
-    대한 레코드
+* [`ExternalName`](#externalname)-유형 서비스에 대한 CNAME 레코드
+* 다른 모든 유형에 대해, 서비스의 이름을 공유하는 모든 `엔드포인트`에
+  대한 레코드

 ## 서비스 퍼블리싱 (ServiceTypes) {#publishing-services-service-types}

@@ -479,26 +478,26 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하

 `Type` 값과 그 동작은 다음과 같다.

-   * `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
-     클러스터 내에서만 서비스에 도달할 수 있다. 이것은
-     `ServiceTypes`의 기본 값이다.
-   * [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
-     노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가
-     자동으로 생성된다. `<NodeIP>:<NodePort>`를 요청하여,
-     클러스터 외부에서
-     `NodePort` 서비스에 접속할 수 있다.
-   * [`LoadBalancer`](#loadbalancer): 클라우드 공급자의 로드 밸런서를 사용하여
-     서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
-     `NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다.
-   * [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를
-     `externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에
-     매핑한다.
-     어떤 종류의 프록시도 설정되어 있지 않다.
-     {{< note >}}
-     `ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 CoreDNS 버전 1.7 이상이 필요하다.
-     {{< /note >}}
+* `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
+  클러스터 내에서만 서비스에 도달할 수 있다. 이것은
+  `ServiceTypes`의 기본 값이다.
+* [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
+  노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가
+  자동으로 생성된다. `<NodeIP>:<NodePort>`를 요청하여,
+  클러스터 외부에서
+  `NodePort` 서비스에 접속할 수 있다.
+* [`LoadBalancer`](#loadbalancer): 클라우드 공급자의 로드 밸런서를 사용하여
+  서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
+  `NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다.
+* [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를
+  `externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에
+  매핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.
+  {{< note >}}`ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는
+  CoreDNS 버전 1.7 이상이 필요하다.
+  {{< /note >}}

-[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
+[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를
+노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.

 ### NodePort 유형 {#nodeport}

@@ -507,7 +506,6 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
 서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다.

-
 포트를 프록시하기 위해 특정 IP를 지정하려면 kube-proxy의 `--nodeport-addresses` 플래그를 특정 IP 블록으로 설정할 수 있다. 이것은 쿠버네티스 v1.10부터 지원된다.
 이 플래그는 쉼표로 구분된 IP 블록 목록 (예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.

@@ -528,6 +526,7 @@ NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설
 `.spec.clusterIP:spec.ports[*].port`로 표기된다. (kube-proxy에서 `--nodeport-addresses` 플래그가 설정되면, <NodeIP>는 NodeIP를 필터링한다.)

 예를 들면
+
 ```yaml
 apiVersion: v1
 kind: Service
@@ -604,19 +603,21 @@ SCTP를 사용하는 경우, `LoadBalancer` 서비스 유형에 대한 아래의
 {{< /note >}}

 #### 내부 로드 밸런서 {#internal-load-balancer}
+
 혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
-라우팅해야하는 경우가 있다.
+라우팅해야 하는 경우가 있다.

 수평 분할 DNS 환경에서는 외부와 내부 트래픽을 엔드포인트로 라우팅 할 수 있는 두 개의 서비스가 필요하다.

-서비스에 다음 어노테이션 중 하나를 추가하여 이를 수행할 수 있다.
-추가할 어노테이션은 사용 중인 클라우드 서비스 공급자에 따라 다르다.
+내부 로드 밸런서를 설정하려면, 사용 중인 클라우드 서비스 공급자에 따라
+다음의 어노테이션 중 하나를 서비스에 추가한다.

 {{< tabs name="service_tabs" >}}
 {{% tab name="Default" %}}
 탭 중 하나를 선택
 {{% /tab %}}
 {{% tab name="GCP" %}}
+
 ```yaml
 [...]
 metadata:
@@ -625,8 +626,10 @@ metadata:
        cloud.google.com/load-balancer-type: "Internal"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="AWS" %}}
+
 ```yaml
 [...]
 metadata:
@@ -635,8 +638,10 @@ metadata:
        service.beta.kubernetes.io/aws-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Azure" %}}
+
 ```yaml
 [...]
 metadata:
@@ -645,8 +650,10 @@ metadata:
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="IBM Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -655,8 +662,10 @@ metadata:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="OpenStack" %}}
+
 ```yaml
 [...]
 metadata:
@@ -665,8 +674,10 @@ metadata:
        service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Baidu Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -675,8 +686,10 @@ metadata:
        service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Tencent Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -684,8 +697,10 @@ metadata:
    service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Alibaba Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -693,10 +708,10 @@ metadata:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
 [...]
 ```
+
 {{% /tab %}}
 {{< /tabs >}}

-
 #### AWS에서 TLS 지원 {#ssl-support-on-aws}

 AWS에서 실행되는 클러스터에서 부분적으로 TLS / SSL을 지원하기 위해, `LoadBalancer` 서비스에 세 가지
@@ -821,7 +836,6 @@ Classic ELB의 연결 드레이닝은
 사용하여 인스턴스를 해제하기 전에,
 기존 연결을 열어 두는 목적으로 최대 시간을 초 단위로 설정할 수도 있다.

-
 ```yaml
    metadata:
      name: my-service
@@ -989,6 +1003,7 @@ spec:
  type: ExternalName
  externalName: my.database.example.com
 ```
+
 {{< note >}}
 ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
 정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
@@ -1043,7 +1058,7 @@ spec:

 ## 단점

-VIP용으로 유저스페이스 프록시를 사용하면, 중소 급 스케일에서는 동작하지만, 수천 개의
+VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일에서는 동작하지만, 수천 개의
 서비스가 포함된 대규모 클러스터로는 확장되지 않는다.
 [포털에 대한 독창적인 설계 제안](https://github.com/kubernetes/kubernetes/issues/1107)에 이에 대한 자세한 내용이
 있다.
@@ -1171,7 +1186,7 @@ IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이

 {{< note >}}
 서비스 대신 {{< glossary_tooltip term_id="ingress" text="인그레스" >}} 를 사용하여
-HTTP / HTTPS 서비스를 노출할 수도 있다.
+HTTP/HTTPS 서비스를 노출할 수도 있다.
 {{< /note >}}

 ### PROXY 프로토콜
@@ -1187,6 +1202,7 @@ LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부
 ```
 PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
 ```
+
 클라이언트 데이터가 뒤따라온다.

 ### SCTP
@@ -1225,11 +1241,8 @@ SCTP는 윈도우 기반 노드를 지원하지 않는다.
 kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
 {{< /warning >}}

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

-
 * [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기
 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기
 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기
@@ -25,7 +25,7 @@ _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한

 퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.

-[실습 예제와 함께 상세한 내용](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.
+[실습 예제와 함께 상세한 내용](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.

 ## 볼륨과 클레임 라이프사이클

@@ -755,8 +755,8 @@ spec:
  ## {{% heading "whatsnext" %}}


-* [퍼시스턴트볼륨 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)에 대해 자세히 알아보기
-* [퍼시스턴트볼륨클레임 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)에 대해 자세히 알아보기
+* [퍼시스턴트볼륨 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)에 대해 자세히 알아보기
+* [퍼시스턴트볼륨클레임 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨클레임-생성하기)에 대해 자세히 알아보기
 * [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기

 ### 참고
@@ -410,6 +410,21 @@ parameters:

 ### vSphere

+vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다.
+
+- [CSI 프로비저닝 도구](#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)를 참조한다.
+
+#### vCP 프로비저닝 도구
+
+다음 예시에서는 VMware 클라우드 공급자(vCP) 스토리지클래스 프로비저닝 도구를 사용한다.
+
 1. 사용자 지정 디스크 형식으로 스토리지클래스를 생성한다.

    ```yaml
@@ -575,7 +590,7 @@ parameters:
  이 Quobyte 테넌트는 이미 Quobyte에 있어야 한다.
  기본값은 "DEFAULT".

-### Azure 디스크크
+### Azure 디스크

 #### Azure 비관리 디스크 스토리지 클래스 {#azure-unmanaged-disk-storage-class}

@@ -751,7 +751,7 @@ spec:
 ### persistentVolumeClaim {#persistentvolumeclaim}

 `persistentVolumeClaim` 볼륨은
-[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes)을 파드에 마운트하는데 사용한다.  퍼시스턴트볼륨은
+[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes)을 파드에 마운트하는데 사용한다. 퍼시스턴트볼륨클레임은
 사용자가 특정 클라우드 환경의 세부 내용을 몰라도 내구성이있는 스토리지 (GCE 퍼시스턴트디스크 또는
 iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다.

@@ -44,7 +44,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는

 {{< codenew file="application/job/cronjob.yaml" >}}

-([크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)는
+([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는
 이 예시를 더 자세히 설명한다.)

 ## 크론잡의 한계 {#cron-job-limitations}
@@ -85,4 +85,4 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
 크론잡 `schedule` 필드의 포맷을 문서화 한다.

 크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의
-예는 [크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
+예는 [크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
@@ -331,7 +331,7 @@ spec:
 - 각 작업 항목에 대한 하나의 잡 오브젝트 vs 모든 작업 항목에 대한 단일 잡 오브젝트.  후자는
  작업 항목 수가 많은 경우 더 적합하다.  전자는 사용자와 시스템이 많은 수의 잡 오브젝트를
  관리해야 하는 약간의 오버헤드를 만든다.
- 작업 항목과 동일한 개수의 파드 생성 vs 각 파드에서 다수의 작업 항목을 처리
+- 작업 항목과 동일한 개수의 파드 생성 vs 각 파드에서 다수의 작업 항목을 처리.
  전자는 일반적으로 기존 코드와 컨테이너를 거의 수정할 필요가 없다.  후자는
  이전 글 머리표(-)와 비슷한 이유로 많은 수의 작업 항목에 적합하다.
 - 여러 접근 방식이 작업 큐를 사용한다.  이를 위해서는 큐 서비스를 실행하고,
@@ -346,7 +346,7 @@ spec:
 | -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
 | [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/)            |                   |                             |          ✓          |          ✓          |
 | [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/)   |         ✓         |                             |      때때로      |          ✓          |
-| [가변 파드 수를 가진 큐](/docs/tasks/job/fine-parallel-processing-work-queue/)  |         ✓         |             ✓               |                     |          ✓          |
+| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)  |         ✓         |             ✓               |                     |          ✓          |
 | 정적 작업이 할당된 단일 잡                               |         ✓         |                             |          ✓          |                     |

 `.spec.completions` 로 완료를 지정할 때, 잡 컨트롤러에 의해 생성된 각 파드는
@@ -362,7 +362,7 @@ spec:
 | -------------------------------------------------------------------- |:-------------------:|:--------------------:|
 | [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/)           |          1          |     1이어야 함      |
 | [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/)   |          W          |        any           |
-| [가변 파드 수를 가진 큐](/docs/tasks/job/fine-parallel-processing-work-queue/)  |          1          |        any           |
+| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)  |          1          |        any           |
 | 정적 작업이 할당된 단일 잡                               |          W          |        any           |


@@ -120,7 +120,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
 {{< /note >}}

 파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한
-[DNS 하위 도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다.
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다.

 ### 파드와 컨트롤러

@@ -30,13 +30,23 @@ node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB

 그러면 클러스터는 논리적으로 다음과 같이 보이게 된다.

-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph TB
+    subgraph "zoneB"
+        n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        n1(Node1)
+        n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}

 레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/kubernetes-api/labels-annotations-taints/)을 재사용할 수 있다.

@@ -80,17 +90,25 @@ spec:

 ### 예시: 단수 토폴로지 분배 제약 조건

-4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다(`P`는 파드를 나타낸다).
+4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.

-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-|   P   |   P   |   P   |       |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}

 신규 파드가 기존 파드와 함께 영역에 걸쳐서 균등하게 분배되도록 하려면, 스펙(spec)은 다음과 같이 주어질 수 있다.

@@ -100,15 +118,46 @@ spec:

 만약 스케줄러가 이 신규 파드를 "zoneA"에 배치하면 파드 분포는 [3, 1]이 되며, 따라서 실제 차이(skew)는 2 (3 - 1)가 되어 `maxSkew: 1` 를 위반하게 된다. 이 예시에서는 들어오는 파드는 오직 "zoneB"에만 배치할 수 있다.

-```
-+---------------+---------------+      +---------------+---------------+
-|     zoneA     |     zoneB     |      |     zoneA     |     zoneB     |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |  OR  | node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-|   P   |   P   |   P   |   P   |      |   P   |   P   |  P P  |       |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+OR
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n3
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}

 사용자는 파드 스펙을 조정해서 다음과 같은 다양한 요구사항을 충족할 수 있다.

@@ -118,17 +167,26 @@ spec:

 ### 예시: 다중 토폴로지 분배 제약 조건

-4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다(`P`는 파드를 나타낸다).
+4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.

-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-|   P   |   P   |   P   |       |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}

 사용자는 2개의 TopologySpreadConstraints를 사용해서 영역과 노드에 파드를 분배하는 것을 제어할 수 있다.

@@ -138,15 +196,24 @@ spec:

 다중 제약 조건은 충돌로 이어질 수 있다. 3개의 노드를 가지는 클러스터 하나가 2개의 영역에 걸쳐 있다고 가정한다.

-```
-+---------------+-------+
-|     zoneA     | zoneB |
-+-------+-------+-------+
-| node1 | node2 | node3 |
-+-------+-------+-------+
-|  P P  |   P   |  P P  |
-+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p4(Pod) --> n3(Node3)
+        p5(Pod) --> n3
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n1
+        p3(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}

 만약 사용자가 "two-constraints.yaml" 을 이 클러스터에 적용하면, "mypod"가 `Pending` 상태로 유지되는 것을 알게 된다. 이러한 이유는, 첫 번째 제약 조건을 충족하기 위해 "mypod"는 오직 "zoneB"에만 놓을 수 있다. 두 번째 제약 조건에서는 "mypod"는 오직 "node2"에만 놓을 수 있다. 그러면 "zoneB"와 "node2"의 공동 결과는 아무것도 반환되지 않는다.

@@ -169,15 +236,37 @@ spec:

    zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.

-    ```
-    +---------------+---------------+-------+
-    |     zoneA     |     zoneB     | zoneC |
-    +-------+-------+-------+-------+-------+
-    | node1 | node2 | node3 | node4 | node5 |
-    +-------+-------+-------+-------+-------+
-    |   P   |   P   |   P   |       |       |
-    +-------+-------+-------+-------+-------+
-    ```
+    {{<mermaid>}}
+    graph BT
+        subgraph "zoneB"
+            p3(Pod) --> n3(Node3)
+            n4(Node4)
+        end
+        subgraph "zoneA"
+            p1(Pod) --> n1(Node1)
+            p2(Pod) --> n2(Node2)
+        end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+    {{< /mermaid >}}
+
+    {{<mermaid>}}
+    graph BT
+        subgraph "zoneC"
+            n5(Node5)
+        end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n5 k8s;
+    class zoneC cluster;
+    {{< /mermaid >}}

    그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다.