[ko] 1st Korean localization work for v1.22

content/ko/community/_index.html

@@ -12,8 +12,8 @@
 
 <div class="intro">
 <br class="mobile">
-<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화로 구성된 쿠버네티스 커뮤니티는 이 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장 하고 변화함에 따라 우리의 문화와 가치관이 계속 성장하고 변화하고 있습니다. 우리 모두는 프로젝트의 지속적인 개선과 작업 방식을 위해 함께 노력합니다.
-<br><br>우리는 이슈를 제기하고 풀 리퀘스트하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고 채택과 혁신을 옹호하며, <code>kubectl get pods</code> 을 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 여러분이 어떻게 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
+<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화를 통해 구성된 쿠버네티스 커뮤니티는 본 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장하고 변화함에 따라 우리의 문화와 가치관 또한 지속적으로 성장하고 변화하고 있습니다. 우리 모두는 프로젝트와 작업 방식을 지속적으로 개선하기 위해 함께 노력합니다.
+<br><br>우리는 이슈(issue)와 풀 리퀘스트(pull request)를 제출하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고, 도입(adoption)과 혁신(innovation)을 지지하며, <code>kubectl get pods</code> 를 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 어떻게 하면 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
 <br class="mobile">
 </div>
 

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

@@ -392,6 +392,49 @@ Message:        Node is shutting, evicting pods
 이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다.
 {{< /note >}}
 
+## 스왑(swap) 메모리 관리 {#swap-memory}
+
+{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
+
+쿠버네티스 1.22 이전에는 노드가 스왑 메모리를 지원하지 않았다. 그리고 
+kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 실패하도록 되어 있었다.
+1.22부터는 스왑 메모리 지원을 노드 단위로 활성화할 수 있다.
+
+노드에서 스왑을 활성화하려면, `NodeSwap` 기능 게이트가 kubelet에서
+활성화되어야 하며, 명령줄 플래그 `--fail-swap-on` 또는
+[구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가
+false로 지정되어야 한다.
+
+사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며, 
+이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면,
+
+```yaml
+memorySwap:
+  swapBehavior: LimitedSwap
+```
+
+`swapBehavior`에 가용한 구성 옵션은 다음과 같다.
+
+- `LimitedSwap`: 쿠버네티스 워크로드는 스왑을 사용할 수 있는 만큼으로
+  제한된다. 쿠버네티스에 의해 관리되지 않는 노드의 워크로드는 여전히 스왑될 수 있다.
+- `UnlimitedSwap`: 쿠버네티스 워크로드는 요청한 만큼 스왑 메모리를 사용할 수 있으며,
+  시스템의 최대치까지 사용 가능하다.
+
+만약 `memorySwap` 구성이 명시되지 않았고 기능 게이트가 활성화되어 있다면, 
+kubelet은 `LimitedSwap` 설정과 같은 행동을
+기본적으로 적용한다.
+
+`LimitedSwap` 설정에 대한 행동은 노드가 ("cgroups"으로 알려진)
+제어 그룹이 v1 또는 v2 중에서 무엇으로 동작하는가에 따라서 결정된다. 
+
+- **cgroupsv1:** 쿠버네티스 워크로드는 메모리와 스왑의 조합을 사용할 수 있다.
+  파드의 메모리 제한이 설정되어 있다면 가용 상한이 된다.
+- **cgroupsv2:** 쿠버네티스 워크로드는 스왑 메모리를 사용할 수 없다.
+
+테스트를 지원하고 피드벡을 제공하기 위한 정보는
+[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) 및
+[디자인 제안](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)에서 찾을 수 있다.
+
 ## {{% heading "whatsnext" %}}
 
 * 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다.

content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md

@@ -6,6 +6,18 @@ weight: 70
 
 <!-- overview -->
 
+
+{{< note >}}
+이 한글 문서는 더 이상 관리되지 않습니다.
+
+이 문서의 기반이 된 영어 원문은 삭제되었으며,
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
+
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
+이 문서는 삭제될 수 있습니다.
+{{< /note >}}
+
+
 가비지 수집은 사용되지 않는 
 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 
 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 

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

@@ -80,7 +80,7 @@ kubectl logs counter
 로테이션하도록 컨테이너 런타임을 설정할 수도 있다.
 
 예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은
-[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
+[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)를 통해
 자세히 알 수 있다.
 
 **CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다.

content/ko/docs/concepts/cluster-administration/manage-deployment.md

@@ -160,7 +160,7 @@ persistentvolumeclaim/my-pvc created
 
 지금까지 사용한 예는 모든 리소스에 최대 한 개의 레이블만 적용하는 것이었다. 세트를 서로 구별하기 위해 여러 레이블을 사용해야 하는 많은 시나리오가 있다.
 
-예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
+예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/master/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
 
 ```yaml
      labels:

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

@@ -21,7 +21,7 @@ weight: 10
 
 - JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.
 
-- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
+- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
 
 - 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다.
 
@@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
 
 ## 레이블 사용하기
 
-- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
 
 릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
 

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

@@ -12,26 +12,33 @@ weight: 30
 
 <!-- overview -->
 
-쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
-민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이
-{{< glossary_tooltip term_id="pod" >}} 정의나
-{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}
-내에 그대로 두는 것보다 안전하고 유연하다.
-자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
-
 시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를
-포함하는 오브젝트이다. 그렇지 않으면  이러한 정보가 파드
-명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
-일부 시크릿을 만들 수 있다.
+포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 {{< glossary_tooltip text="파드" term_id="pod" >}}
+명세나 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
+포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를
+애플리케이션 코드에 넣을 필요가
+없음을 뜻한다.
+
+시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에,
+파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이
+노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스
+및 클러스터에서 실행되는 애플리케이션은 기밀 데이터를 비휘발성
+저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다.
+
+시크릿은 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}과 유사하지만
+특별히 기밀 데이터를 보관하기 위한 것이다.
 
 {{< caution >}}
-쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
-기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
-액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
-시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
+쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
+또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다. 
+
+시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.
 
 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
-2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
+2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
+   활성화 또는 구성.
+3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
+
 {{< /caution >}}
 
 <!-- body -->
@@ -47,6 +54,10 @@ weight: 30
 - [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
 - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
 
+쿠버네티스 컨트롤 플레인 또한 시크릿을 사용한다. 예를 들어,
+[부트스트랩 토큰 시크릿](#부트스트랩-토큰-시크릿)은
+노드 등록을 자동화하는 데 도움을 주는 메커니즘이다.
+
 시크릿 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
@@ -1236,7 +1247,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
    API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
    시크릿을 노출하는 파드를 실행할 수 있다.
 
-
 ## {{% heading "whatsnext" %}}
 
 - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기

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

@@ -52,7 +52,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
 FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
 ```
 
-서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
+서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/master/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
 
 
 

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

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 이미지
 content_type: concept
 weight: 10
@@ -16,9 +19,6 @@ weight: 10
 
 이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.
 
-
-
-
 <!-- body -->
 
 ## 이미지 이름
@@ -210,10 +210,6 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'
 
 ### 미리 내려받은 이미지
 
-{{< note >}}
-Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
-{{< /note >}}
-
 {{< note >}}
 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은
 클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로
@@ -334,4 +330,5 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.
 
 ## {{% heading "whatsnext" %}}
 
-* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기
+* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
+* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.

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

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 런타임클래스(RuntimeClass)
 content_type: concept
 weight: 20
@@ -115,7 +118,7 @@ dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
 유효한 핸들러는 runtimes 단락 아래에서 설정한다.
 
 ```
-[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
 ```
 
 더 자세한 containerd의 구성 문서를 살펴본다.

content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -197,31 +197,39 @@ service PodResourcesLister {
 }
 ```
 
-`List` 엔드포인트는 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
-이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보와 함께
-실행 중인 파드의 리소스에 대한 정보를 제공한다.
+`List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며,
+독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
+이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다.
 
 ```gRPC
-// ListPodResourcesResponse는 List 함수가 반환하는 응답이다
+// ListPodResourcesResponse는 List 함수가 반환하는 응답이다.
 message ListPodResourcesResponse {
     repeated PodResources pod_resources = 1;
 }
 
-// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다
+// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다.
 message PodResources {
     string name = 1;
     string namespace = 2;
     repeated ContainerResources containers = 3;
 }
 
-// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다
+// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다.
 message ContainerResources {
     string name = 1;
     repeated ContainerDevices devices = 2;
     repeated int64 cpu_ids = 3;
+    repeated ContainerMemory memory = 4;
 }
 
-// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다
+// ContainerMemory는 컨테이너에 할당된 메모리와 hugepage에 대한 정보를 포함한다.
+message ContainerMemory {
+    string memory_type = 1;
+    uint64 size = 2;
+    TopologyInfo topology = 3;
+}
+
+// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다.
 message TopologyInfo {
         repeated NUMANode nodes = 1;
 }
@@ -231,7 +239,7 @@ message NUMANode {
         int64 ID = 1;
 }
 
-// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다
+// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다.
 message ContainerDevices {
     string resource_name = 1;
     repeated string device_ids = 2;
@@ -247,6 +255,7 @@ kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다
 message AllocatableResourcesResponse {
     repeated ContainerDevices devices = 1;
     repeated int64 cpu_ids = 2;
+    repeated ContainerMemory memory = 3;
 }
 
 ```