[ko] Update outdated files in dev-1.24-ko.3 (M14-M18)

Author: bconfiden2

content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md

@@ -13,7 +13,7 @@ kubelet은 하나 이상의 파드를 능동적으로 중단시켜
 자원을 회수하고 고갈 상황을 방지할 수 있다.
 
 노드-압박 축출 과정에서, kubelet은 축출할 파드의 `PodPhase`를 
-`Failed`로 설정한다. 이로써 파드가 종료된다.
+`Failed`로 설정함으로써 파드가 종료된다.
 
 노드-압박 축출은 
 [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)과는 차이가 있다.
@@ -32,7 +32,7 @@ kubelet은 이전에 설정된 `eviction-max-pod-grace-period` 값을 따른다.
 {{<note>}}
 kubelet은 최종 사용자 파드를 종료하기 전에 
 먼저 [노드 수준 자원을 회수](#reclaim-node-resources)하려고 시도한다. 
-예를 들어, 디스크 자원이 부족하면 먼저 사용하지 않는 컨테이너 이미지를 제거한다.
+예를 들어, 디스크 자원이 부족하면 사용하지 않는 컨테이너 이미지를 먼저 제거한다.
 {{</note>}}
 
 kubelet은 축출 결정을 내리기 위해 다음과 같은 다양한 파라미터를 사용한다.
@@ -44,11 +44,11 @@ kubelet은 축출 결정을 내리기 위해 다음과 같은 다양한 파라
 ### 축출 신호 {#eviction-signals}
 
 축출 신호는 특정 시점에서 특정 자원의 현재 상태이다. 
-Kubelet은 노드에서 사용할 수 있는 리소스의 최소량인 
+kubelet은 노드에서 사용할 수 있는 리소스의 최소량인 
 축출 임계값과 축출 신호를 비교하여 
 축출 결정을 내린다.
 
-Kubelet은 다음과 같은 축출 신호를 사용한다.
+kubelet은 다음과 같은 축출 신호를 사용한다.
 
 | 축출 신호      | 설명                                                                           |
 |----------------------|---------------------------------------------------------------------------------------|
@@ -61,7 +61,7 @@ Kubelet은 다음과 같은 축출 신호를 사용한다.
 
 이 표에서, `설명` 열은 kubelet이 축출 신호 값을 계산하는 방법을 나타낸다. 
 각 축출 신호는 백분율 또는 숫자값을 지원한다. 
-Kubelet은 총 용량 대비 축출 신호의 백분율 값을 
+kubelet은 총 용량 대비 축출 신호의 백분율 값을 
 계산한다.
 
 `memory.available` 값은 `free -m`과 같은 도구가 아니라 cgroupfs로부터 도출된다. 
@@ -82,13 +82,18 @@ kubelet은 다음과 같은 파일시스템 파티션을 지원한다.
 1. `imagefs`: 컨테이너 런타임이 컨테이너 이미지 및 
    컨테이너 쓰기 가능 레이어를 저장하는 데 사용하는 선택적 파일시스템이다.
 
-Kubelet은 이러한 파일시스템을 자동으로 검색하고 다른 파일시스템은 무시한다. 
-Kubelet은 다른 구성은 지원하지 않는다.
+kubelet은 이러한 파일시스템을 자동으로 검색하고 다른 파일시스템은 무시한다. 
+kubelet은 다른 구성은 지원하지 않는다.
 
-{{<note>}}
-일부 kubelet 가비지 수집 기능은 더 이상 사용되지 않으며 축출로 대체되었다.
-사용 중지된 기능의 목록은 [kubelet 가비지 수집 사용 중단](/ko/docs/concepts/architecture/garbage-collection/#containers-images)을 참조한다.
-{{</note>}}
+아래의 kubelet 가비지 수집 기능은 더 이상 사용되지 않으며 축출로 대체되었다.
+
+| 기존 플래그 | 새로운 플래그 | 이유 |
+| ------------- | -------- | --------- |
+| `--image-gc-high-threshold` | `--eviction-hard` 또는 `--eviction-soft` | 기존의 축출 신호가 이미지 가비지 수집을 트리거할 수 있음 |
+| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 축출 회수도 동일한 작업을 수행 |
+| `--maximum-dead-containers` | - | 오래된 로그들이 컨테이너의 컨텍스트 외부에 저장된 이후로 사용되지 않음 |
+| `--maximum-dead-containers-per-container` | - | 오래된 로그들이 컨테이너의 컨텍스트 외부에 저장된 이후로 사용되지 않음 |
+| `--minimum-container-ttl-duration` | - | 오래된 로그들이 컨테이너의 컨텍스트 외부에 저장된 이후로 사용되지 않음 |
 
 ### 축출 임계값
 
@@ -396,7 +401,7 @@ kubelet의 `memcg` 알림 API가 임계값을 초과할 때 즉시 알림을 받
 상태로 간주하고 노드가 메모리 압박을 겪고 있다고 테인트를 표시할 수 있으며, 이는 
 파드 축출을 유발한다.
 
-더 자세한 사항은 [http://github.com/kubernetes/kubernetes/issues/43916](http://github.com/kubernetes/kubernetes/issues/43916)를 참고한다.
+자세한 사항은 [http://github.com/kubernetes/kubernetes/issues/43916](http://github.com/kubernetes/kubernetes/issues/43916)를 참고한다.
 
 집중적인 I/O 작업을 수행할 가능성이 있는 컨테이너에 대해 메모리 제한량 및 메모리 
 요청량을 동일하게 설정하여 이 문제를 해결할 수 있다. 해당 컨테이너에 대한 최적의 

content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -13,15 +13,16 @@ weight: 40
 [_노드 어피니티_](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)는
 {{< glossary_tooltip text="노드" term_id="node" >}} 셋을
 (기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다.
-_테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다.
+_테인트_ 는 그 반대로, 노드가 파드 셋을 제외시킬 수 있다.
 
-_톨러레이션_ 은 파드에 적용된다. 톨러레이션을 통해 스케줄러는 그와 일치하는 테인트가 있는 파드를 스케줄할 수 있다. 톨러레이션은 스케줄을 허용하지만 보장하지는 않는다. 스케줄러는 그 기능의 일부로서 [다른 매개변수를](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) 고려한다.
+_톨러레이션_ 은 파드에 적용된다. 톨러레이션을 통해 스케줄러는 그와 일치하는 테인트가 있는 파드를 스케줄할 수 있다.
+톨러레이션은 스케줄을 허용하지만 보장하지는 않는다.
+스케줄러는 그 기능의 일부로서
+[다른 매개변수를](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) 고려한다.
 
 테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지
-않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은
-노드가 테인트를 용인하지 않는 파드를 수용해서는 안 되는 것을 나타낸다.
-
-
+않게 한다. 하나 이상의 테인트가 노드에 적용되는데, 이것은
+노드가 테인트를 용인하지 않는 파드를 수용해서는 안 된다는 것을 나타낸다.
 
 <!-- body -->
 
@@ -37,7 +38,7 @@ kubectl taint nodes node1 key1=value1:NoSchedule
 `node1` 노드에 테인트을 배치한다. 테인트에는 키 `key1`, 값 `value1` 및 테인트 이펙트(effect) `NoSchedule` 이 있다.
 이는 일치하는 톨러레이션이 없으면 파드를 `node1` 에 스케줄할 수 없음을 의미한다.
 
-위의 명령으로 추가한 테인트를 제거하려면, 다음을 실행한다.
+위에서 추가했던 테인트를 제거하려면, 다음을 실행한다.
 ```shell
 kubectl taint nodes node1 key1=value1:NoSchedule-
 ```
@@ -67,7 +68,7 @@ tolerations:
 
 지정하지 않으면 `operator` 의 기본값은 `Equal` 이다.
 
-톨러레이션은 키가 동일하고 이펙트가 동일한 경우, 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다.
+톨러레이션은, 키와 이펙트가 동일한 경우에 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다.
 
 * `operator` 가 `Exists` 인 경우(이 경우 `value` 를 지정하지 않아야 함), 또는
 * `operator` 는 `Equal` 이고 `value` 는 `value` 로 같다.
@@ -266,7 +267,8 @@ tolerations:
 ## 컨디션(condition)을 기준으로 노드 테인트하기
 
 컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여 
-[노드 컨디션](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
+[노드 컨디션](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한
+`NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
 
 스케줄러는 스케줄링 결정을 내릴 때 노드 컨디션을 확인하는 것이 아니라 테인트를 확인한다. 
 이렇게 하면 노드 컨디션이 스케줄링에 직접적인 영향을 주지 않는다.
@@ -297,5 +299,6 @@ tolerations:
 
 ## {{% heading "whatsnext" %}}
 
-* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 어떻게 구성하는지에 대해 알아보기
+* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과
+어떻게 구성하는지에 대해 알아보기
 * [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기

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

@@ -23,14 +23,15 @@ weight: 50
 
 ## 전송 보안
 
-일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다.
+기본적으로 쿠버네티스 API 서버는 TLS에 의해 보호되는 첫번째 non-localhost 네트워크 인터페이스의 6443번 포트에서 수신을 대기한다. 일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다. 포트번호는 `--secure-port` 플래그를 통해, 수신 대기 IP 주소는 `--bind-address` 플래그를 통해 변경될 수 있다.
+
 API 서버는 인증서를 제시한다.
-이 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 `$USER/.kube/config`는
-API 서버의 인증서에 대한 루트 인증서를 포함하며,
-시스템 기본 루트 인증서 대신 사용된다.
-`kube-up.sh`을 사용하여 클러스터를 직접 생성할 때
-이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
-클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
+이러한 인증서는 사설 인증 기관(CA)에 기반하여 서명되거나, 혹은 공인 CA와 연결된 공개키 인프라스트럭처에 기반한다.
+인증서와 그에 해당하는 개인키는 각각 `--tls-cert-file`과 `--tls-private-key-file` 플래그를 통해 지정한다.
+
+만약 클러스터가 사설 인증 기관을 사용한다면,
+해당 CA 인증서를 복사하여 클라이언트의 `~/.kube/config` 안에 구성함으로써
+연결을 신뢰하고 누군가 중간에 가로채지 않았음을 보장해야 한다.
 
 클라이언트는 이 단계에서 TLS 클라이언트 인증서를 제시할 수 있다.
 
@@ -137,34 +138,6 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
 
 더 많은 정보는 [감사](/docs/tasks/debug/debug-cluster/audit/)를 참고한다.
 
-## API 서버 포트와 IP
-
-이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
-API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
-
-기본적으로, 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
-
-  1. `로컬호스트 포트`:
-
-      - 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소
-        (스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
-      - TLS가 없다.
-      - 기본 포트는 8080이다.
-      - 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다.
-      - 요청이 인증 및 인가 모듈을 **우회한다**.
-      - 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
-      - 호스트 접근 요구로부터 보호를 받는다.
-
-  2. `보안 포트`:
-
-      - 가능한 항상 사용하는 것이 좋다.
-      - TLS를 사용한다. `--tls-cert-file` 플래그로 인증서를 지정하고 `--tls-private-key-file` 플래그로 키를 지정한다.
-      - 기본 포트는 6443이며, `--secure-port` 플래그를 사용하여 변경한다.
-      - 기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, `--bind-address` 플래그를 사용하여 변경한다.
-      - 요청이 인증 및 인가 모듈에 의해 처리된다.
-      - 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
-      - 인증 및 인가 모듈을 실행한다.
-
 ## {{% heading "whatsnext" %}}
 
 인증 및 인가 그리고 API 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다.