Sixth Korean l10n work for release-1.13 (#12705)

* ko: Update outdated files in dev-1.13-ko.6 (#12456)

* Translate concepts/containers/runtime-class.md in Korean (#12459)

* Fix ko translation consistency for commandlinetool word (#12626)

* Added Korean localization guide (#12597)

* Translate containers/images.md in Korean (#12549)

* Translate container-lifecycle-hooks.md in Korean (#12534)

* Translate tasks/run-application/horizontal-pod-autoscale in Korean (#12565)

* Translate concepts/architecture/cloud-controller in Korean #11964 (#12483)

* ko-trans: add setup/certificate.md #12453 (#12520)

Co-authored-by:    Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by:    June Yi <june.yi@samsung.com>
Co-authored-by:    Seokho <shsongist@gmail.com>
Co-authored-by:    Jesang Myung <jesang.myung@gmail.com>
Co-authored-by:    Kim Young Dae <38598117+zer0big@users.noreply.github.com>
Co-authored-by:    Yoon <learder@gmail.com>

content/ko/docs/concepts/containers/container-lifecycle-hooks.md

@@ -0,0 +1,120 @@
+---
+title: 컨테이너 라이프사이클 훅(Hook)
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서 
+컨테이너 라이프사이클 훅 프레임워크를 사용하는 방법에 대해서 설명한다.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## 개요
+
+Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로그래밍 언어 프레임워크와 유사하게, 
+쿠버네티스도 컨테이너에 라이프사이클 훅을 제공한다.
+훅은 컨테이너가 관리 라이프사이클의 이벤트를 인지하고 상응하는 
+라이프사이클 훅이 실행될 때 핸들러에 구현된 코드를 실행할 수 있게 한다.
+
+## 컨테이너 훅
+
+컨테이너에 노출되는 훅은 두 가지가 있다.
+
+`PostStart`
+
+이 훅은 컨테이너가 생성된 직후에 실행된다.
+그러나, 훅이 컨테이너 엔트리포인트에 앞서서 실행된다는 보장은 없다.
+파라미터는 핸들러에 전달되지 않는다.
+
+`PreStop`
+
+이 훅은 컨테이너가 종료되기 직전에 호출된다.
+그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로, 
+컨테이너를 삭제하기 위한 호출이 전송되기 전에 완료되어야한다.
+파라미터는 핸들러에 전달되지 않는다.
+
+종료 동작에 더 자세한 대한 설명은 
+[파드의 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)에서 찾을 수 있다.
+
+### 훅 핸들러 구현
+
+컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
+구현될 수 있는 컨테이너의 훅 핸들러에는 두 가지 유형이 있다.
+
+* Exec - 컨테이너의 cgroups와 네임스페이스 안에서, `pre-stop.sh`와 같은, 특정 커맨드를 실행.
+커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
+* HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.
+
+### 훅 핸들러 실행
+
+컨테이너 라이프사이클 관리 훅이 호출되면, 
+쿠버네티스 관리 시스템은 해당 훅이 등록된 컨테이너에서 핸들러를 실행한다.
+
+훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 맥락과 동기적으로 동작한다. 
+이것은 `PostStart` 훅에 대해서, 
+훅이 컨테이너 엔트리포인트와는 비동기적으로 동작함을 의미한다.
+그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면, 
+컨테이너는 `running` 상태에 이르지 못한다.
+
+이러한 동작은 `PreStop` 훅에 대해서도 비슷하게 일어난다.
+만약 훅이 실행되던 도중에 매달려 있다면, 
+파드의 단계(phase)는 `Terminating` 상태에 머물고 해당 훅은 파드의 `terminationGracePeriodSeconds`가 끝난 다음에 종료된다.
+만약 `PostStart` 또는 `PreStop` 훅이 실패하면,
+그것은 컨테이너를 종료시킨다.
+
+사용자는 훅 핸들러를 가능한 한 가볍게 만들어야 한다.
+그러나, 컨테이너가 멈추기 전 상태를 저장하는 것과 같이, 
+오래 동작하는 커맨드가 의미 있는 경우도 있다.
+
+### 훅 전달 보장
+
+훅 전달은 *한 번 이상* 으로 의도되어 있는데, 
+이는 `PostStart` 또는 `PreStop`와 같은 특정 이벤트에 대해서, 
+훅이 여러 번 호출될 수 있다는 것을 의미한다.
+이것을 올바르게 처리하는 것은 훅의 구현에 달려 있다.
+
+일반적으로, 전달은 단 한 번만 이루어진다.
+예를 들어, HTTP 훅 수신기가 다운되어 트래픽을 받을 수 없는 경우에도, 
+재전송을 시도하지 않는다.
+그러나, 드문 경우로, 이중 전달이 발생할 수 있다.
+예를 들어, 훅을 전송하는 도중에 kubelet이 재시작된다면,
+Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
+
+### 디버깅 훅 핸들러
+
+훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다.
+만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다. 
+`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며, 
+`PreStop`의 경우, 이것은 `FailedPreStopHook` 이벤트이다.
+이 이벤트는 `kubectl describe pod <파드_이름>`를 실행하면 볼 수 있다.
+다음은 이 커맨드 실행을 통한 이벤트 출력의 몇 가지 예다.
+
+```
+Events:
+  FirstSeen    LastSeen    Count    From                            SubobjectPath        Type        Reason        Message
+  ---------    --------    -----    ----                            -------------        --------    ------        -------
+  1m        1m        1    {default-scheduler }                                Normal        Scheduled    Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
+  1m        1m        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Pulling        pulling image "test:1.0"
+  1m        1m        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Created        Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
+  1m        1m        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Pulled        Successfully pulled image "test:1.0"
+  1m        1m        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Started        Started container with docker id 5c6a256a2567
+  38s        38s        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Killing        Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
+  37s        37s        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Killing        Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
+  38s        37s        2    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}                Warning        FailedSync    Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
+  1m         22s         2     {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Warning        FailedPostStartHook
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [컨테이너 환경](/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기.
+* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
+  실습 경험하기.
+
+{{% /capture %}}

content/ko/docs/concepts/containers/images.md

@@ -0,0 +1,371 @@
+---
+title: Images
+content_template: templates/concept
+weight: 10
+---
+
+{{% capture overview %}}
+
+사용자 Docker 이미지를 생성하고 레지스트리에 푸시(push)하여 쿠버네티스 파드에서 참조되기 이전에 대비한다. 
+
+컨테이너의 `image` 속성은 `docker` 커맨드에서 지원하는 문법과 같은 문법을 지원한다. 이는 프라이빗 레지스트리와 태그를 포함한다.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## 이미지 업데이트
+
+기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은 Kubelet이 이미 
+존재하는 이미지에 대한 풀을 생략하게 한다. 만약 항상 풀을 강제하고 싶다면, 
+다음 중 하나를 수행하면 된다.
+
+- 컨테이너의 `imagePullPolicy`를 `Always`로 설정.
+- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용.
+- `imagePullPolicy`와 사용할 이미지의 태그를 생략.
+- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화.
+
+`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/docs/concepts/configuration/overview/#container-images)를 참고한다.
+
+## 매니페스트로 멀티-아키텍처 이미지 빌드
+
+Docker CLI는 현재 `docker manifest` 커맨드와 `create`, `annotate`, `push`와 같은 서브 커맨드를 함께 지원한다. 이 커맨드는 매니페스트를 빌드하고 푸시하는데 사용할 수 있다. 매니페스트를 보기 위해서는 `docker manifest inspect`를 사용하면 된다.
+
+다음에서 docker 문서를 확인하기 바란다.
+https://docs.docker.com/edge/engine/reference/commandline/manifest/
+
+이것을 사용하는 방법에 대한 예제는 빌드 하니스(harness)에서 참조한다. 
+https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=
+
+이 커맨드는 Docker CLI에 의존하며 그에 전적으로 구현된다. `$HOME/.docker/config.json` 편집 및 `experimental` 키를 `enabled`로 설정하거나, CLI 커맨드 호출 시 간단히  `DOCKER_CLI_EXPERIMENTAL` 환경 변수를 `enabled`로만 설정해도 된다.
+
+{{< note >}}
+Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전은 버그가 있거나 실험적인 명령줄 옵션을 지원하지 않는다. 예를 들어 https://github.com/docker/cli/issues/1135 는 containerd에서 문제를 일으킨다.
+{{< /note >}}
+
+오래된 매니페스트 업로드를 실행하는 데 어려움을 겪는다면, `$HOME/.docker/manifests`에서 오래된 매니페스트를 정리하여 새롭게 시작하면 된다.
+
+쿠버네티스의 경우, 일반적으로 접미사 `-$(ARCH)`가 있는 이미지를 사용해 왔다. 하위 호환성을 위해, 접미사가 있는 구형 이미지를 생성하길 바란다. 접미사에 대한 아이디어는 모든 아키텍처를 위한 매니페스트를 가졌다는 의미가 내포된 `pause` 이미지를 생성하고, 접미사가 붙은 이미지가 하드 코드되어 있을 오래된 구성 또는 YAML 파일에 대해 하위 호환된다는 의미가 내포되어 있는 `pause-amd64`를 생성하기 위한 것이다.
+
+## 프라이빗 레지스트리 사용
+
+프라이빗 레지스트리는 해당 레지스트리에서 이미지를 읽을 수 있는 키를 요구할 것이다.
+자격 증명(credential)은 여러 가지 방법으로 제공될 수 있다.
+
+  - Google 컨테이너 레지스트리 사용
+    - 각 클러스터에 대하여
+    - Google 컴퓨트 엔진 또는 Google 쿠버네티스 엔진에서 자동적으로 구성됨
+    - 모든 파드는 해당 프로젝트의 프라이빗 레지스트리를 읽을 수 있음
+  - AWS EC2 컨테이너 레지스트리(ECR) 사용
+    - IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함
+    - ECR 로그인 자격 증명은 자동으로 갱신됨
+  - Azure 컨테이너 레지스트리(ACR) 사용
+  - IBM 클라우드 컨테이너 레지스트리 사용
+  - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
+    - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음
+    - 클러스터 관리자에 의한 노드 구성 필요
+  - 미리 풀링(pre-pulling)된 이미지
+    - 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능
+    - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요
+  - 파드에 ImagePullSecrets을 명시
+    - 자신의 키를 제공하는 파드만 프라이빗 레지스트리에 접근 가능
+
+각 옵션은 아래에서 더 자세히 설명한다.
+
+
+### Google 컨테이너 레지스트리 사용
+
+쿠버네티스는 Google 컴퓨트 엔진(GCE)에서 동작할 때, [Google 컨테이너 
+레지스트리(GCR)](https://cloud.google.com/tools/container-registry/)를 자연스럽게 
+지원한다. 사용자의 클러스터가 GCE 또는 Google 쿠버네티스 엔진에서 동작 중이라면, 간단히 
+이미지의 전체 이름(예: gcr.io/my_project/image:tag)을 사용하면 된다.
+
+클러스터 내에서 모든 파드는 해당 레지스트리에 있는 이미지에 읽기 접근 권한을 가질 것이다.
+
+Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 GCR을 인증할 것이다.
+인스턴스의 서비스 계정은 `https://www.googleapis.com/auth/devstorage.read_only`라서,
+프로젝트의 GCR로부터 풀은 할 수 있지만 푸시는 할 수 없다.
+
+### AWS EC2 컨테이너 레지스트리 사용
+
+쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [AWS EC2 컨테이너 
+레지스트리](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다.
+
+간단히 이미지의 전체 이름(예: `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)을 
+파드 정의에 사용하면 된다.
+
+파드를 생성할 수 있는 클러스터의 모든 사용자는 ECR 레지스트리에 있는 어떠한 
+이미지든지 파드를 실행하는데 사용할 수 있다.
+
+kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다. 이것을 위해서는 다음에 대한 권한이 필요하다.
+
+- `ecr:GetAuthorizationToken`
+- `ecr:BatchCheckLayerAvailability`
+- `ecr:GetDownloadUrlForLayer`
+- `ecr:GetRepositoryPolicy`
+- `ecr:DescribeRepositories`
+- `ecr:ListImages`
+- `ecr:BatchGetImage`
+
+요구 사항:
+
+- Kubelet 버전 `v1.2.0` 이상을 사용해야 한다.  (예: `/usr/bin/kubelet --version=true`를 실행).
+- 노드가 지역 A에 있고 레지스트리가 다른 지역 B에 있다면, 버전 `v1.3.0` 이상이 필요하다.
+- 사용자의 지역에서 ECR이 지원되어야 한다.
+
+문제 해결:
+
+- 위의 모든 요구 사항을 확인한다.
+- 워크스테이션에서 $REGION (예: `us-west-2`)의 자격 증명을 얻는다. 그 자격 증명을 사용하여 해당 호스트로 SSH를 하고 Docker를 수동으로 실행한다. 작동하는가?
+- kubelet이 `--cloud-provider=aws`로 실행 중인지 확인한다.
+- kubelet 로그에서 (예: `journalctl -u kubelet`) 다음과 같은 로그 라인을 확인한다.
+  - `plugins.go:56] Registering credential provider: aws-ecr-key`
+  - `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider`
+
+### Azure 컨테이너 레지스트리(ACR) 사용
+[Azure 컨테이너 레지스트리](https://azure.microsoft.com/en-us/services/container-registry/)를 사용하는 경우 
+관리자 역할의 사용자나 서비스 주체(principal) 중 하나를 사용하여 인증할 수 있다.
+어느 경우라도, 인증은 표준 Docker 인증을 통해서 수행된다. 이러한 지침은 
+[azure-cli](https://github.com/azure/azure-cli) 명령줄 도구 사용을 가정한다.
+
+우선 레지스트리를 생성하고 자격 증명을 만들어야한다. 이에 대한 전체 문서는 
+[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다.
+
+컨테이너 레지스트리를 생성하고 나면, 다음의 자격 증명을 사용하여 로그인한다.
+
+   * `DOCKER_USER` : 서비스 주체 또는 관리자 역할의 사용자명
+   * `DOCKER_PASSWORD`: 서비스 주체 패스워드 또는 관리자 역할의 사용자 패스워드
+   * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io`
+   * `DOCKER_EMAIL`: `${some-email-address}`
+
+해당 변수에 대한 값을 채우고 나면 
+[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)할 수 있다.
+
+### IBM 클라우드 컨테이너 레지스트리 사용
+IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 Docker 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 
+프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, 레지스트리 네임스페이스에 접근을 승인하는 토큰을 생성할 수 있다.
+
+IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://console.bluemix.net/docs/services/Registry/index.html#index)를 참고한다.
+
+[IBM 클라우드 퍼블릭 이미지](https://console.bluemix.net/docs/services/RegistryImages/index.html#ibm_images) 및 사용자의 프라이빗 이미지로부터 컨테이너를 사용자의 IBM 클라우드 쿠버네티스 서비스 클러스터의 `default` 네임스페이스에 디플로이하기 위해서 IBM 클라우드 컨테이너 레지스트리를 사용하면 된다. 컨테이너를 다른 네임스페이스에 디플로이하거나, 다른 IBM 클라우드 컨테이너 레지스트리 지역 또는 IBM 클라우드 계정을 사용하기 위해서는, 쿠버네티스 `imagePullSecret`를 생성한다. 더 자세한 정보는, [이미지로부터 컨테이너 빌드하기](https://console.bluemix.net/docs/containers/cs_images.html#images)를 참고한다.
+
+### 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
+
+{{< note >}}
+Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
+{{< /note >}}
+
+{{< note >}}
+AWS EC2에서 동작 중이고 EC2 컨테이너 레지스트리(ECR)을 사용 중이라면, 각 노드의 kubelet은 
+ECR 로그인 자격 증명을 관리하고 업데이트할 것이다. 그렇다면 이 방법은 쓸 수 없다.
+{{< /note >}}
+
+{{< note >}}
+이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 
+GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대해서는 신뢰성 있게 작동하지 
+않을 것이다.
+{{< /note >}}
+
+Docker는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을 
+아래의 검색 경로 리스트에 넣으면, kubelete은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다.
+
+*   `{--root-dir:-/var/lib/kubelet}/config.json`
+*   `{cwd of kubelet}/config.json`
+*   `${HOME}/.docker/config.json`
+*   `/.docker/config.json`
+*   `{--root-dir:-/var/lib/kubelet}/.dockercfg`
+*   `{cwd of kubelet}/.dockercfg`
+*   `${HOME}/.dockercfg`
+*   `/.dockercfg`
+
+{{< note >}}
+아마도 kubelet을 위한 사용자의 환경 파일에 `HOME=/root`을 명시적으로 설정해야 할 것이다.
+{{< /note >}}
+
+프라이빗 레지스트리를 사용도록 사용자의 노드를 구성하기 위해서 권장되는 단계는 다음과 같다. 이 
+예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다.
+
+   1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 `$HOME/.docker/config.json`를 업데이트한다.
+   1. 편집기에서 `$HOME/.docker/config.json`를 보고 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다. 
+   1. 노드의 리스트를 구한다. 예를 들면 다음과 같다.
+      - 이름을 원하는 경우: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
+      - IP를 원하는 경우: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
+   1. 로컬의 `.docker/config.json`를 위의 검색 경로 리스트 중 하나에 복사한다.
+      - 예: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done`
+
+프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다.
+
+```yaml
+kubectl create -f - <<EOF
+apiVersion: v1
+kind: Pod
+metadata:
+  name: private-image-test-1
+spec:
+  containers:
+    - name: uses-private-image
+      image: $PRIVATE_IMAGE_NAME
+      imagePullPolicy: Always
+      command: [ "echo", "SUCCESS" ]
+EOF
+pod/private-image-test-1 created
+```
+
+만약 모든 것이 잘 작동한다면, 잠시 후에, 다음 메시지를 볼 것이다.
+
+```shell
+kubectl logs private-image-test-1
+SUCCESS
+```
+
+만약 실패했다면, 다음 메시지를 볼 것이다.
+
+```shell
+kubectl describe pods/private-image-test-1 | grep "Failed"
+  Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
+```
+
+클러스터의 모든 노드가 반드시 동일한 `.docker/config.json`를 가져야 한다. 그렇지 않으면, 파드가 
+일부 노드에서만 실행되고 다른 노드에서는 실패할 것이다. 예를 들어, 노드 오토스케일링을 사용한다면, 각 인스턴스 
+템플릿은 `.docker/config.json`을 포함하거나 그것을 포함한 드라이브를 마운트해야 한다.
+
+프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는 
+프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다.
+
+### 미리 풀링(pre-pulling)된 이미지
+
+{{< note >}}
+Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
+{{< /note >}}
+
+{{< note >}}
+이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 
+GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대해서는 신뢰성 있게 작동하지 
+않을 것이다.
+{{< /note >}}
+
+기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 할 것이다.
+그러나, 컨테이너의 `imagePullPolicy` 속성이 `IfNotPresent` 또는 `Never`으로 설정되어 있다면, 
+로컬 이미지가 사용된다(우선적으로 또는 배타적으로).
+
+레지스트리 인증의 대안으로 미리 풀 된 이미지에 의존하고 싶다면, 
+클러스터의 모든 노드가 동일한 미리 풀 된 이미지를 가지고 있는지 확인해야 한다.
+
+이것은 특정 이미지를 속도를 위해 미리 로드하거나 프라이빗 레지스트리에 대한 인증의 대안으로 사용될 수 있다.
+
+모든 파드는 미리 풀 된 이미지에 대해 읽기 접근 권한을 가질 것이다.
+
+### 파드에 ImagePullSecrets 명시
+
+{{< note >}}
+이 방법은 현재 Google 쿠버네티스 엔진, GCE 및 노드 생성이 자동화된 모든 클라우드 제공자에게 
+권장된다.
+{{< /note >}}
+
+쿠버네티스는 파드에 레지스트리 키를 명시하는 것을 지원한다.
+
+#### Docker 구성으로 시크릿 생성
+
+대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.
+
+```shell
+kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
+secret/myregistrykey created.
+```
+
+만약 다중 레지스트리에 접근이 필요하다면, 각 레지스트리에 대한 하나의 시크릿을 생성할 수 있다.
+Kubelet은 파드를 위한 이미지를 풀링할 때 `imagePullSecrets`를 단일의 가상 `.docker/config.json`
+에 병합할 것이다.
+
+파드는 이미지 풀 시크릿을 자신의 네임스페이스에서만 참조할 수 있다.
+따라서 이 과정은 네임스페이스 당 한 번만 수행될 필요가 있다.
+
+##### kubectl create secrets 우회
+
+어떤 이유에서 단일 `.docker/config.json`에 여러 항목이 필요하거나 
+위의 커맨드를 통해서는 주어지지 않는 제어가 필요한 경우, [json 또는 yaml로 
+시크릿 생성](/docs/user-guide/secrets/#creating-a-secret-manually)을 수행할 수 있다.
+
+다음 사항을 준수해야 한다.
+
+- `.dockerconfigjson`에 해당 데이터 항목의 이름을 설정
+- Docker 파일을 base64로 인코딩하여 해당 문자열을 붙여넣을 때,
+  `data[".dockerconfigjson"]` 필드의 값으로써 깨짐 방지
+- `kubernetes.io/dockerconfigjson`에 `type`을 설정
+
+예:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: myregistrykey
+  namespace: awesomeapps
+data:
+  .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
+type: kubernetes.io/dockerconfigjson
+```
+
+
+`error: no objects passed to create`라는 에러 메시지가 나오면, 그것은 base64 인코딩된 문자열이 유효하지 않다는 것을 뜻한다. 
+`Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`와 유사한 에러 메시지가 나오면, 그것은 
+데이터가 성공적으로 un-base64 인코딩되었지만, `.docker/config.json` 파일로는 파싱될 수 없었음을 의미한다.
+
+#### 파드의 imagePullSecrets 참조
+
+이제, `imagePullSecrets` 섹션을 파드의 정의에 추가함으로써 해당 시크릿을 
+참조하는 파드를 생성할 수 있다.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: foo
+  namespace: awesomeapps
+spec:
+  containers:
+    - name: foo
+      image: janedoe/awesomeapp:v1
+  imagePullSecrets:
+    - name: myregistrykey
+```
+
+이것은 프라이빗 레지스트리를 사용하는 각 파드에 대해서 수행될 필요가 있다.
+
+그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/user-guide/service-accounts) 리소스에 
+imagePullSecrets을 셋팅하여 자동화할 수 있다.
+자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다.
+
+이것은 노드 당 `.docker/config.json`와 함께 사용할 수 있다. 자격 증명은 
+병합될 것이다. 이 방법은 Google 쿠버네티스 엔진에서 작동될 것이다.
+
+### 유스케이스
+
+프라이빗 레지스트리를 구성하기 위한 많은 솔루션이 있다. 다음은 여러 가지 
+일반적인 유스케이스와 제안된 솔루션이다. 
+
+1. 비소유 이미지(예를 들어, 오픈소스)만 실행하는 클러스터의 경우. 이미지를 숨길 필요가 없다.
+   - Docker hub의 퍼블릭 이미지를 사용한다.
+     - 설정이 필요 없다.
+     - GCE 및 Google 쿠버네티스 엔진에서는, 속도와 가용성 향상을 위해서 로컬 미러가 자동적으로 사용된다. 
+1. 모든 클러스터 사용자에게는 보이지만, 회사 외부에는 숨겨야하는 일부 독점 이미지를 
+   실행하는 클러스터의 경우.
+   - 호스트 된 프라이빗 [Docker 레지스트리](https://docs.docker.com/registry/)를 사용한다.
+     - 그것은 [Docker Hub](https://hub.docker.com/signup)에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다.
+     - 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다.
+   - 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다.
+     - 쿠버네티스 구성은 필요 없다. 
+   - 또는, GCE 및 Google 쿠버네티스 엔진에서는, 프로젝트의 Google 컨테이너 레지스트리를 사용한다.
+     - 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다.
+   - 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다.
+1. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우.
+   - [AlwaysPullImages 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)가 활성화되어 있는지 확인한다. 그렇지 않으면, 모든 파드가 잠재적으로 모든 이미지에 접근 권한을 가진다.
+   - 민감한 데이터는 이미지 안에 포장하는 대신, "시크릿" 리소스로 이동한다. 
+1. 멀티-테넌트 클러스터에서 각 테넌트가 자신의 프라이빗 레지스트리를 필요로 하는 경우.
+   - [AlwaysPullImages 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)가 활성화되어 있는지 확인한다. 그렇지 않으면, 모든 파드가 잠재적으로 모든 이미지에 접근 권한을 가진다.
+   - 인가가 요구되도록 프라이빗 레지스트리를 실행한다. 
+   - 각 테넌트에 대한 레지스트리 자격 증명을 생성하고, 시크릿에 넣고, 각 테넌트 네임스페이스에 시크릿을 채운다.
+   - 테넌트는 해당 시크릿을 각 네임스페이스의 imagePullSecrets에 추가한다.
+
+{{% /capture %}}

content/ko/docs/concepts/containers/runtime-class.md

@@ -0,0 +1,116 @@
+---
+title: 런타임 클래스
+content_template: templates/concept
+weight: 20
+---
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+
+이 페이지는 런타임 클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## 런타임 클래스
+
+런타임 클래스는 파드의 컨테이너를 실행하는데 사용할 컨테이너 런타임 설정을 선택하기 위한 
+알파 특징이다.
+
+### 셋업
+
+초기 알파 특징이므로, 런타임 클래스 특징을 사용하기 위해서는 몇 가지 추가 셋업 
+단계가 필요하다.
+
+1. 런타임 클래스 특징 게이트 활성화(apiservers 및 kubelets에 대해서, 버전 1.12+ 필요)
+2. 런타임 클래스 CRD 설치
+3. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
+4. 상응하는 런타임 클래스 리소스 생성
+
+#### 1. 런타임 클래스 특징 게이트 활성화
+
+특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
+참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 
+한다.
+
+#### 2. 런타임 클래스 CRD 설치
+
+런타임 클래스 [CustomResourceDefinition][] (CRD)는 쿠버네티스 git 저장소의 애드온 디렉터리에서 찾을 수 
+있다. [kubernetes/cluster/addons/runtimeclass/runtimeclass_crd.yaml][runtimeclass_crd]
+
+`kubectl apply -f runtimeclass_crd.yaml`을 통해서 해당 CRD를 설치한다.
+
+[CustomResourceDefinition]: /docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
+[runtimeclass_crd]: https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/runtimeclass/runtimeclass_crd.yaml
+
+
+#### 3. CRI 구현을 노드에 설정
+
+런타임 클래스와 함께 선택할 설정은 CRI 구현에 의존적이다. 사용자의 CRI 
+구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다. 이것은 알파 
+특징이므로, 아직 모든 CRI가 다중 런타임 클래스를 지원하지는 않는다.
+
+{{< note >}}
+런타임 클래스는 클러스터 전체에 걸쳐 동질의 노드 설정
+(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한 
+설정)이라도 
+스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다([파드를 노드에 
+할당하기](/docs/concepts/configuration/assign-pod-node/) 참고).
+{{< /note >}}
+
+해당 설정은 상응하는 `RuntimeHandler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
+런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다.
+
+#### 4. 상응하는 런타임 클래스 리소스 생성
+
+3단계에서 셋업 한 설정은 연관된 `RuntimeHandler` 이름을 가져야 하며, 이를 통해서 
+설정을 식별할 수 있다. 각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 
+상응하는 런타임 클래스 오브젝트를 생성한다.
+
+현재 런타임 클래스 리소스는 런타임 클래스 이름(`metadata.name`)과 런타임 핸들러
+(`spec.runtimeHandler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
+
+```yaml
+apiVersion: node.k8s.io/v1alpha1  # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음
+kind: RuntimeClass
+metadata:
+  name: myclass  # 런타임 클래스는 해당 이름을 통해서 참조됨
+  # 런타임 클래스는 네임스페이스가 없는 리소스임
+spec:
+  runtimeHandler: myconfiguration  # 상응하는 CRI 설정의 이름임
+```
+
+
+{{< note >}}
+런타임 클래스 쓰기 작업(create/update/patch/delete)은
+클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한 
+개요](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)를 참고한다.
+{{< /note >}}
+
+### 사용
+
+클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 
+`runtimeClassName`를 명시한다. 예를 들면 다음과 같다.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  runtimeClassName: myclass
+  # ...
+```
+
+이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. 만약 지명된 
+런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 
+`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다. 에러 
+메시지를 위해서는 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 
+확인한다.
+
+만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용될 것이다. 기본 런타임 핸들러는 런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.
+
+{{% /capture %}}