Merge pull request #29931 from seokho-son/outdate-ko-1.22-sh01

[ko] Update outdated files in dev-1.22-ko.1 (M1-M18)

Author: k8s-ci-robot

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/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;
 }
 
 ```

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

@@ -45,7 +45,7 @@ sitemap:
 * 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
 * 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
 * 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
-* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
+* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
 * 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
 * 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
 * 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.

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

@@ -30,6 +30,11 @@ weight: 50
 }
 ```
 
+{{<note>}}
+맵의 키와 값은 문자열이어야 한다. 다르게 말해서, 숫자,
+불리언(boolean), 리스트 등의 다른 형식을 키나 값에 사용할 수 없다.
+{{</note>}}
+
 다음은 어노테이션에 기록할 수 있는 정보의 예제이다.
 
 * 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은

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

@@ -42,23 +42,21 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
    * `"partition" : "customerA"`, `"partition" : "customerB"`
    * `"track" : "daily"`, `"track" : "weekly"`
 
-이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
+이 예시는 [일반적으로 사용하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
 
 ## 구문과 캐릭터 셋
 
 _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(`/`)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야 하며, 점(`.`)과 전체 253자 이하, 슬래시(`/`)로 구분되는 DNS 레이블이다.
 
 접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
 
-`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
+`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다.
 
 유효한 레이블 값은 다음과 같다.
 * 63 자 이하여야 하고 (공백일 수도 있음),
 * (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
 * 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다.
 
-유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
-
 다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
 
 ```yaml

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

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 오브젝트 이름과 ID
 content_type: concept
 weight: 20
@@ -25,7 +28,7 @@ weight: 20
 물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
 {{< /note >}}
 
-다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
+다음은 리소스에 일반적으로 사용되는 네 가지 유형의 이름 제한 조건이다.
 
 ### DNS 서브도메인 이름
 
@@ -38,7 +41,7 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
 - 영숫자로 시작한다.
 - 영숫자로 끝난다.
 
-### DNS 레이블 이름
+### RFC 1123 레이블 이름 {#dns-label-names}
 
 일부 리소스 유형은 [RFC 1123](https://tools.ietf.org/html/rfc1123)에
 정의된 대로 DNS 레이블 표준을 따라야 한다.
@@ -49,6 +52,17 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
 - 영숫자로 시작한다.
 - 영숫자로 끝난다.
 
+### RFC 1035 레이블 이름
+
+몇몇 리소스 타입은 자신의 이름을 [RFC 1035](https://tools.ietf.org/html/rfc1035)에
+정의된 DNS 레이블 표준을 따르도록 요구한다.
+이것은 이름이 다음을 만족해야 한다는 의미이다.
+
+- 최대 63개 문자를 포함
+- 소문자 영숫자 또는 '-'만 포함
+- 알파벳 문자로 시작
+- 영숫자로 끝남
+
 ### 경로 세그먼트 이름
 
 일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수

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

@@ -442,7 +442,7 @@ pods        0     10
 
 ### 네임스페이스 간 파드 어피니티 쿼터
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를
 제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의
@@ -493,9 +493,9 @@ plugins:
 해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만
 파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다.
 
-이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
+이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
+`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
 
 ## 요청과 제한의 비교 {#requests-vs-limits}
 

content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -271,16 +271,16 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
 연관된 `matchExpressions` 가 모두 충족되어야 한다.
 
 #### 네임스페이스 셀렉터
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다.
 어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다.
 빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과
 null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다.
 
-이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
+이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
+`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
 
 #### 더 실용적인 유스케이스