Merge pull request #27133 from kubernetes/dev-1.20-ko.6

[ko] Sixth Korean l10n work for release-1.20

Author: k8s-ci-robot

content/ko/docs/concepts/architecture/controller.md

@@ -102,7 +102,7 @@ weight: 30
 온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가
 서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는
 [쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해
-IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API들 및
+IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API 및
 기타 서비스 등과 간접적으로 연동하여 이를 구현한다.
 
 ## 의도한 상태와 현재 상태 {#desired-vs-current}

content/ko/docs/concepts/architecture/nodes.md

@@ -57,7 +57,7 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
 정상적인지 확인한다.
 
 상태 확인을 중지하려면 사용자 또는 {{< glossary_tooltip term_id="controller" text="컨트롤러">}}에서
-노드 오브젝트를 명시적으로 삭제해야한다.
+노드 오브젝트를 명시적으로 삭제해야 한다.
 {{< /note >}}
 
 노드 오브젝트의 이름은 유효한

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

@@ -1,5 +1,8 @@
 ---
 title: 클러스터 관리
+
+
+
 weight: 100
 content_type: concept
 description: >
@@ -11,6 +14,7 @@ no_list: true
 클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다.
 핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다.
 
+
 <!-- body -->
 ## 클러스터 계획
 
@@ -41,7 +45,7 @@ no_list: true
 
 ## 클러스터 보안
 
-* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
+* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
 
 * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
 

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

@@ -4,247 +4,6 @@ content_type: concept
 weight: 20
 ---
 
-
 <!-- overview -->
 
-클라이언트 인증서로 인증을 사용하는 경우 `easyrsa`, `openssl` 또는 `cfssl`
-을 통해 인증서를 수동으로 생성할 수 있다.
-
-
-
-
-<!-- body -->
-
-### easyrsa
-
-**easyrsa** 는 클러스터 인증서를 수동으로 생성할 수 있다.
-
-1.  easyrsa3의 패치 버전을 다운로드하여 압축을 풀고, 초기화한다.
-
-        curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
-        tar xzf easy-rsa.tar.gz
-        cd easy-rsa-master/easyrsa3
-        ./easyrsa init-pki
-1.  새로운 인증 기관(CA)을 생성한다. `--batch` 는 자동 모드를 설정한다.
-    `--req-cn` 는 CA의 새 루트 인증서에 대한 일반 이름(Common Name (CN))을 지정한다.
-
-        ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
-1.  서버 인증서와 키를 생성한다.
-    `--subject-alt-name` 인수는 API 서버에 접근이 가능한 IP와 DNS
-    이름을 설정한다. `MASTER_CLUSTER_IP` 는 일반적으로 API 서버와
-    컨트롤러 관리자 컴포넌트에 대해 `--service-cluster-ip-range` 인수로
-    지정된 서비스 CIDR의 첫 번째 IP이다. `--days` 인수는 인증서가 만료되는
-    일 수를 설정하는데 사용된다.
-    또한, 아래 샘플은 기본 DNS 이름으로 `cluster.local` 을
-    사용한다고 가정한다.
-
-        ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
-        "IP:${MASTER_CLUSTER_IP},"\
-        "DNS:kubernetes,"\
-        "DNS:kubernetes.default,"\
-        "DNS:kubernetes.default.svc,"\
-        "DNS:kubernetes.default.svc.cluster,"\
-        "DNS:kubernetes.default.svc.cluster.local" \
-        --days=10000 \
-        build-server-full server nopass
-1.  `pki/ca.crt`, `pki/issued/server.crt` 그리고 `pki/private/server.key` 를 디렉터리에 복사한다.
-1.  API 서버 시작 파라미터에 다음 파라미터를 채우고 추가한다.
-
-        --client-ca-file=/yourdirectory/ca.crt
-        --tls-cert-file=/yourdirectory/server.crt
-        --tls-private-key-file=/yourdirectory/server.key
-
-### openssl
-
-**openssl** 은 클러스터 인증서를 수동으로 생성할 수 있다.
-
-1.  ca.key를 2048bit로 생성한다.
-
-        openssl genrsa -out ca.key 2048
-1.  ca.key에 따라 ca.crt를 생성한다(인증서 유효 기간을 사용하려면 -days를 사용한다).
-
-        openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
-1.  server.key를 2048bit로 생성한다.
-
-        openssl genrsa -out server.key 2048
-1.  인증서 서명 요청(Certificate Signing Request (CSR))을 생성하기 위한 설정 파일을 생성한다.
-    파일에 저장하기 전에 꺾쇠 괄호(예: `<MASTER_IP>`)로
-    표시된 값을 실제 값으로 대체한다(예: `csr.conf`).
-    `MASTER_CLUSTER_IP` 의 값은 이전 하위 섹션에서
-    설명한 대로 API 서버의 서비스 클러스터 IP이다.
-    또한, 아래 샘플에서는 `cluster.local` 을 기본 DNS 도메인
-    이름으로 사용하고 있다고 가정한다.
-
-        [ req ]
-        default_bits = 2048
-        prompt = no
-        default_md = sha256
-        req_extensions = req_ext
-        distinguished_name = dn
-
-        [ dn ]
-        C = <국가(country)>
-        ST = <도(state)>
-        L = <시(city)>
-        O = <조직(organization)>
-        OU = <조직 단위(organization unit)>
-        CN = <MASTER_IP>
-
-        [ req_ext ]
-        subjectAltName = @alt_names
-
-        [ alt_names ]
-        DNS.1 = kubernetes
-        DNS.2 = kubernetes.default
-        DNS.3 = kubernetes.default.svc
-        DNS.4 = kubernetes.default.svc.cluster
-        DNS.5 = kubernetes.default.svc.cluster.local
-        IP.1 = <MASTER_IP>
-        IP.2 = <MASTER_CLUSTER_IP>
-
-        [ v3_ext ]
-        authorityKeyIdentifier=keyid,issuer:always
-        basicConstraints=CA:FALSE
-        keyUsage=keyEncipherment,dataEncipherment
-        extendedKeyUsage=serverAuth,clientAuth
-        subjectAltName=@alt_names
-1.  설정 파일을 기반으로 인증서 서명 요청을 생성한다.
-
-        openssl req -new -key server.key -out server.csr -config csr.conf
-1.  ca.key, ca.crt 그리고 server.csr을 사용해서 서버 인증서를 생성한다.
-
-        openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-        -CAcreateserial -out server.crt -days 10000 \
-        -extensions v3_ext -extfile csr.conf
-1.  인증서를 본다.
-
-        openssl x509  -noout -text -in ./server.crt
-
-마지막으로, API 서버 시작 파라미터에 동일한 파라미터를 추가한다.
-
-### cfssl
-
-**cfssl** 은 인증서 생성을 위한 또 다른 도구이다.
-
-1.  아래에 표시된 대로 커맨드 라인 도구를 다운로드하여 압축을 풀고 준비한다.
-    사용 중인 하드웨어 아키텍처 및 cfssl 버전에 따라 샘플
-    명령을 조정해야 할 수도 있다.
-
-        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
-        chmod +x cfssl
-        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
-        chmod +x cfssljson
-        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
-        chmod +x cfssl-certinfo
-1.  아티팩트(artifact)를 보유할 디렉터리를 생성하고 cfssl을 초기화한다.
-
-        mkdir cert
-        cd cert
-        ../cfssl print-defaults config > config.json
-        ../cfssl print-defaults csr > csr.json
-1.  CA 파일을 생성하기 위한 JSON 설정 파일을 `ca-config.json` 예시와 같이 생성한다.
-
-        {
-          "signing": {
-            "default": {
-              "expiry": "8760h"
-            },
-            "profiles": {
-              "kubernetes": {
-                "usages": [
-                  "signing",
-                  "key encipherment",
-                  "server auth",
-                  "client auth"
-                ],
-                "expiry": "8760h"
-              }
-            }
-          }
-        }
-1.  CA 인증서 서명 요청(CSR)을 위한 JSON 설정 파일을
-    `ca-csr.json` 예시와 같이 생성한다. 꺾쇠 괄호로 표시된
-    값을 사용하려는 실제 값으로 변경한다.
-
-        {
-          "CN": "kubernetes",
-          "key": {
-            "algo": "rsa",
-            "size": 2048
-          },
-          "names":[{
-            "C": "<국가(country)>",
-            "ST": "<도(state)>",
-            "L": "<시(city)>",
-            "O": "<조직(organization)>",
-            "OU": "<조직 단위(organization unit)>"
-          }]
-        }
-1.  CA 키(`ca-key.pem`)와 인증서(`ca.pem`)을 생성한다.
-
-        ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
-1.  API 서버의 키와 인증서를 생성하기 위한 JSON 구성파일을
-    `server-csr.json` 예시와 같이 생성한다. 꺾쇠 괄호 안의 값을
-    사용하려는 실제 값으로 변경한다. `MASTER_CLUSTER_IP` 는
-    이전 하위 섹션에서 설명한 API 서버의 클러스터 IP이다.
-    아래 샘플은 기본 DNS 도메인 이름으로 `cluster.local` 을
-    사용한다고 가정한다.
-
-        {
-          "CN": "kubernetes",
-          "hosts": [
-            "127.0.0.1",
-            "<MASTER_IP>",
-            "<MASTER_CLUSTER_IP>",
-            "kubernetes",
-            "kubernetes.default",
-            "kubernetes.default.svc",
-            "kubernetes.default.svc.cluster",
-            "kubernetes.default.svc.cluster.local"
-          ],
-          "key": {
-            "algo": "rsa",
-            "size": 2048
-          },
-          "names": [{
-            "C": "<국가(country)>",
-            "ST": "<도(state)>",
-            "L": "<시(city)>",
-            "O": "<조직(organization)>",
-            "OU": "<조직 단위(organization unit)>"
-          }]
-        }
-1.  API 서버 키와 인증서를 생성하면, 기본적으로
-    `server-key.pem` 과 `server.pem` 파일에 각각 저장된다.
-
-        ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
-        --config=ca-config.json -profile=kubernetes \
-        server-csr.json | ../cfssljson -bare server
-
-
-## 자체 서명된 CA 인증서의 배포
-
-클라이언트 노드는 자체 서명된 CA 인증서를 유효한 것으로 인식하지 않을 수 있다.
-비-프로덕션 디플로이먼트 또는 회사 방화벽 뒤에서 실행되는
-디플로이먼트의 경우, 자체 서명된 CA 인증서를 모든 클라이언트에
-배포하고 유효한 인증서의 로컬 목록을 새로 고칠 수 있다.
-
-각 클라이언트에서, 다음 작업을 수행한다.
-
-```bash
-sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
-sudo update-ca-certificates
-```
-
-```
-Updating certificates in /etc/ssl/certs...
-1 added, 0 removed; done.
-Running hooks in /etc/ca-certificates/update.d....
-done.
-```
-
-## 인증서 API
-
-`certificates.k8s.io` API를 사용해서
-[여기](/docs/tasks/tls/managing-tls-in-a-cluster)에
-설명된 대로 인증에 사용할 x509 인증서를 프로비전 할 수 있다.
+클러스터를 위한 인증서를 생성하기 위해서는, [인증서](/ko/docs/tasks/administer-cluster/certificates/)를 참고한다.

content/ko/docs/concepts/containers/container-environment.md

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 컨테이너 환경 변수
 content_type: concept
 weight: 20
@@ -24,23 +27,24 @@ weight: 20
 ### 컨테이너 정보
 
 컨테이너의 *호스트네임* 은 컨테이너가 동작 중인 파드의 이름과 같다.
-그것은 `hostname` 커맨드 또는 libc의 
-[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 
+그것은 `hostname` 커맨드 또는 libc의
+[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html)
 함수 호출을 통해서 구할 수 있다.
 
-파드 이름과 네임스페이스는 
+파드 이름과 네임스페이스는
 [다운워드(Downward) API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
 
 Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
 파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.
 
 ### 클러스터 정보
 
-컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수 
+컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
 있다.
+이 목록은 새로운 컨테이너의 파드 및 쿠버네티스 컨트롤 플레인 서비스와 동일한 네임스페이스 내에 있는 서비스로 한정된다.
 이러한 환경 변수는 Docker 링크 구문과 일치한다.
 
-*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는, 
+*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는,
 다음의 형태로 변수가 정의된다.
 
 ```shell
@@ -58,5 +62,3 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
 * [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
 * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
   실제 경험 얻기.
-
-

content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md

@@ -1,5 +1,9 @@
 ---
 title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기
+
+
+
+
 content_type: concept
 weight: 10
 ---
@@ -25,8 +29,6 @@ Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮
 kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.
 
 extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다.
-`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃
-제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다.
 
 ## {{% heading "whatsnext" %}}
 

content/ko/docs/concepts/extend-kubernetes/operator.md

@@ -124,5 +124,5 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
     사용하여 직접 구현하기
   * [오퍼레이터 프레임워크](https://operatorframework.io) 사용하기
 * 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
-* 오퍼레이터 패턴을 소개한 [CoreOS 원본 기사](https://coreos.com/blog/introducing-operators.html) 읽기
+* 오퍼레이터 패턴을 소개한 [CoreOS 원본 글](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) 읽기 (이 링크는 원본 글에 대한 보관 버전임)
 * 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기

content/ko/docs/concepts/overview/what-is-kubernetes.md

@@ -55,7 +55,7 @@ sitemap:
 
 ## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do}
 
-컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
+컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
 
 그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.
 

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

@@ -52,6 +52,11 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
 
 `kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
 
+유효한 레이블 값은 다음과 같다.
+* 63 자 이하 여야 하고(공백이면 안 됨),
+* 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
+* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)를 중간에 포함할 수 있다.
+
 유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
 
 다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.

content/ko/docs/concepts/policy/resource-quotas.md

@@ -58,7 +58,7 @@ weight: 20
 ## 리소스 쿼터 활성화
 
 많은 쿠버네티스 배포판에 기본적으로 리소스 쿼터 지원이 활성화되어 있다.
-API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
+{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} `--enable-admission-plugins=` 플래그의 인수 중 하나로
 `ResourceQuota`가 있는 경우 활성화된다.
 
 해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에