Merge pull request #33976 from jihoon-seo/220527_ko_Update_outdated_dev-1.24-ko.1_M34

[ko] Update outdated files in `dev-1.24-ko.1` (M34-M48)

Author: k8s-ci-robot

content/ko/docs/concepts/scheduling-eviction/pod-overhead.md

@@ -1,22 +1,21 @@
 ---
+
+
+
+
 title: 파드 오버헤드
 content_type: concept
 weight: 30
 ---
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.18" state="beta" >}}
-
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
-노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다.
+노드 상에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다.
 이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다.
-_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해
-소비되는 리소스를 계산하는 기능이다.
-
-
-
-
+쿠버네티스에서, _파드 오버헤드_ 는 리소스 요청 및 상한 외에도 
+파드의 인프라에 의해 소비되는 리소스를 계산하는 방법 중 하나이다.
 
 <!-- body -->
 
@@ -25,33 +24,30 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파
 [어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
 이 수행될 때 지정된다.
 
-파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에
-파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나
-파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다.
+파드를 노드에 스케줄링할 때, 컨테이너 리소스 요청의 합 뿐만 아니라 파드의 오버헤드도 함께 고려된다. 
+마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나 파드의 축출 등급을 부여할 때에도 
+파드의 오버헤드를 포함하여 고려한다.
 
-## 파드 오버헤드 활성화하기 {#set-up}
+## 파드 오버헤드 환경 설정하기 {#set-up}
 
-기능 활성화를 위해 클러스터에서
-`PodOverhead` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고(1.18 버전에서는 기본적으로 활성화),
 `overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다.
 
 ## 사용 예제
 
-파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다.
+파드 오버헤드를 활용하려면, `overhead` 필드를 정의하는 런타임클래스가 필요하다.
 예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는
 가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다.
 
 ```yaml
----
-kind: RuntimeClass
 apiVersion: node.k8s.io/v1
+kind: RuntimeClass
 metadata:
-    name: kata-fc
+  name: kata-fc
 handler: kata-fc
 overhead:
-    podFixed:
-        memory: "120Mi"
-        cpu: "250m"
+  podFixed:
+    memory: "120Mi"
+    cpu: "250m"
 ```
 
 `kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산,
@@ -68,7 +64,7 @@ spec:
   runtimeClassName: kata-fc
   containers:
   - name: busybox-ctr
-    image: busybox
+    image: busybox:1.28
     stdin: true
     tty: true
     resources:
@@ -88,13 +84,15 @@ spec:
 파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가
 `overhead` 를 포함하도록 변경한다.
 
-런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다.
+런타임클래스 어드미션 컨트롤러가 변경을 완료하면, 
+다음의 명령어로 업데이트된 파드 오버헤드 값을 확인할 수 있다.
 
 ```bash
 kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
 ```
 
 명령 실행 결과는 다음과 같다.
+
 ```
 map[cpu:250m memory:120Mi]
 ```
@@ -106,23 +104,26 @@ kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할
 해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는
 리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다.
 
-일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다.
+일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 
+파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다.
 기본 컨테이너 런타임이 만들어내는 컨테이너들은 이 파드 안에 존재한다.
 
-만약 각 컨테이너에 대하여 QoS가 보장되었거나 향상이 가능하도록 QoS 의 리소스 상한 제한이 걸려있으면,
-kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의
-cgroup 의 상한선을 설정한다. 이 상한선은 컨테이너 리소스 상한과 PodSpec에
-정의된 `overhead` 의 합에 기반한다.
+만약 각 컨테이너에 대하여 리소스 상한 제한이 걸려있으면 
+(제한이 걸려있는 보장된(Guaranteed) Qos 또는 향상 가능한(Burstable) QoS), 
+kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의 cgroup 의 상한선을 설정한다. 
+이 상한선은 컨테이너 리소스 상한과 PodSpec에 정의된 `overhead` 의 합에 기반한다.
 
-CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의
-리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다.
+CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, 
+kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의 리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다.
 
 다음의 예제를 참고하여, 워크로드에 대하여 컨테이너의 리소스 요청을 확인하자.
+
 ```bash
 kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
 ```
 
 컨테이너 리소스 요청의 합은 각각 CPU 2000m 와 메모리 200MiB 이다.
+
 ```
 map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
 ```
@@ -133,19 +134,21 @@ map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
 kubectl describe node | grep test-pod -B2
 ```
 
-CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 파드의 오버헤드를 포함한다.
+결과를 보면 2250 m의 CPU와 320 MiB의 메모리가 리소스로 요청되었다. 여기에는 파드 오버헤드가 포함되어 있다.
+
 ```
-  Namespace                   Name                CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE
-  ---------                   ----                ------------  ----------   ---------------  -------------  ---
-  default                     test-pod            2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m
+  Namespace    Name       CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE
+  ---------    ----       ------------  ----------   ---------------  -------------  ---
+  default      test-pod   2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m
 ```
 
 ## 파드 cgroup 상한 확인하기
 
-워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며,
-CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다.
-파드의 오버헤드 동작을 보여주는 좋은 예이며,
-사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다.
+워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인해 보자. 
+다음의 예제에서, 
+[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, 
+CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. 
+파드 오버헤드 동작을 보여주는 좋은 예이며, 사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다.
 
 먼저 특정 노드에서 파드의 식별자를 확인해 보자.
 
@@ -155,39 +158,41 @@ POD_ID="$(sudo crictl pods --name test-pod -q)"
 ```
 
 여기에서, 파드의 cgroup 경로를 확인할 수 있다.
+
 ```bash
 # 파드가 스케줄 된 노드에서 이것을 실행
 sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
 ```
 
 명령의 결과로 나온 cgroup 경로는 파드의 `pause` 컨테이너를 포함한다. 파드 레벨의 cgroup은 하나의 디렉터리이다.
+
 ```
-        "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
+  "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
 ```
 
-아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. 메모리의 파드 레벨 cgroup 설정을 확인하자.
+아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. 
+메모리의 파드 레벨 cgroup 설정을 확인하자.
+
 ```bash
 # 파드가 스케줄 된 노드에서 이것을 실행.
 # 또한 사용자의 파드에 할당된 cgroup 이름에 맞춰 해당 이름을 수정.
  cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
 ```
 
-예상대로 320 MiB 이다.
+예상한 것과 같이 320 MiB 이다.
+
 ```
 335544320
 ```
 
 ### 관찰성
-`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
-에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고,
-정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다.
-이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다.
-그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다.
-
 
+몇몇 `kube_pod_overhead` 메트릭은 
+[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 에서 사용할 수 있어, 
+파드 오버헤드가 사용되는 시기를 식별하고, 정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다.
 
 ## {{% heading "whatsnext" %}}
 
-
-* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)
-* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
+* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)에 대해 알아본다.
+* 더 자세한 문맥은 
+  [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) 향상 제안을 확인한다.

content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md

@@ -104,7 +104,7 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사
 
 ## 비-선점 프라이어리티클래스 {#non-preempting-priority-class}
 
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
 `preemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
 앞쪽에 배치되지만,
@@ -203,9 +203,11 @@ spec:
 정보를 제공한다.
 
 파드 P는 반드시 "지정된 노드"로 스케줄링되지는 않는다.
+The scheduler always tries the "nominated Node" before iterating over any other nodes.
+스케줄러는 다른 노드에 스케줄링을 시도하기 전에 항상 "지정된 노드"부터 시도한다.
 피해자 파드가 축출된 후, 그것은 정상적(graceful)으로 종료되는 기간을 갖는다.
 스케줄러가 종료될 피해자 파드를 기다리는 동안 다른 노드를 사용할 수
-있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용한다. 그 결과,
+있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용할 수 있다. 그 결과,
 파드 스펙의 `nominatedNodeName` 과 `nodeName` 은 항상 동일하지 않다. 또한,
 스케줄러가 노드 N에서 파드를 축출했지만, 파드 P보다 우선순위가 높은 파드가
 도착하면, 스케줄러가 노드 N에 새로운 우선순위가 높은 파드를 제공할 수 있다. 이러한

content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md

@@ -21,25 +21,24 @@ kube-scheduler를 미세 조정할 수 있다.
 
 ## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기
 
-쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
-용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를
-통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
-대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
-`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의
-동작은 `RequestedToCapacityRatioArgs`라는
-구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources`
-두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과
-`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을
-조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할
-리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로
-구성된다.
+쿠버네티스는 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여 
+용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 
+이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어 
+대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. 
+`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 
+`RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다. 
+이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. 
+`shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로 
+최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. 
+`resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과 
+각 리소스의 가중치를 지정하는 `weight` 로 구성된다.
 
 다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한
 `requestedToCapacityRatioArguments` 를 빈 패킹 동작으로
 설정하는 구성의 예시이다.
 
 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 profiles:
 # ...

content/ko/docs/concepts/security/controlling-access.md

@@ -1,7 +1,9 @@
 ---
+
+
+
 title: 쿠버네티스 API 접근 제어하기
 content_type: concept
-weight: 5
 ---
 
 <!-- overview -->
@@ -29,13 +31,16 @@ API 서버의 인증서에 대한 루트 인증서를 포함하며,
 이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
 클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
 
+클라이언트는 이 단계에서 TLS 클라이언트 인증서를 제시할 수 있다.
+
 ## 인증
 
 TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다.
 이는 다이어그램에 **1**단계로 표시되어 있다.
 클러스터 생성 스크립트 또는 클러스터 관리자는
 API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
-인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
+인증기에 대해서는 
+[인증](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
 
 인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
 일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.
@@ -46,8 +51,6 @@ JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
 여러 개의 인증 모듈을 지정할 수 있으며,
 이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.
 
-GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.
-
 요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다.
 이 외에는 사용자가 특정 `username`으로 인증되며,
 이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다.
@@ -126,6 +129,12 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
 요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후
 오브젝트 저장소에 기록(**4**단계)된다.
 
+## 감사(Auditing)
+
+쿠버네티스 감사는 클러스터에서 발생하는 일들의 순서를 문서로 기록하여, 보안과 관련되어 있고 시간 순서로 정리된 기록을 제공한다.
+클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션, 그리고 컨트롤 플레인 자신이 생성한 활동을 감사한다.
+
+더 많은 정보는 [감사](/docs/tasks/debug/debug-cluster/audit/)를 참고한다.
 
 ## API 서버 포트와 IP
 

content/ko/docs/concepts/services-networking/dns-pod-service.md

@@ -323,17 +323,6 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화
 쿠버네티스는 최대 32개의 탐색 도메인과 
 최대 2048자의 탐색 도메인 목록을 허용한다.
 
-### 기능 가용성
-
-파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다.
-
-| 쿠버네티스 버전 | 기능 지원 |
-| :---------: |:-----------:|
-| 1.14 | 안정 |
-| 1.10 | 베타 (기본값으로 켜져 있음)|
-| 1.9 | 알파 |
-
-
 ## {{% heading "whatsnext" %}}
 
 

content/ko/docs/concepts/services-networking/dual-stack.md

@@ -43,7 +43,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
      쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
      문서 참조
    * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
-   * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
+   * 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 
 ## IPv4/IPv6 이중 스택 구성