Merge pull request #35912 from having-dlrow/outdated_dev-1.24-ko.2_to_dev-1.24-ko.3-m1

[ko] update outdated korean files in dev-1.24-ko.3 (M1-M5)
2022-08-20 03:45:35 -07:00 · 2022-08-20 03:45:35 -07:00 · 71bd19d9da
parent ac1eb3f1d5 066fd716ce
commit 71bd19d9da
5 changed files with 124 additions and 59 deletions
--- a/content/ko/_index.html
+++ b/content/ko/_index.html
@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
        <button id="desktopShowVideoButton" onclick="kub.showVideo()">비디오 보기</button>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">KubeCon North America (2022년 10월 24~28일) 참가하기</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america" button id="desktopKCButton">KubeCon North America (2022년 10월 24~28일) 참가하기</a>
        <br>
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu23" button id="desktopKCButton">KubeCon Europe (2023년 4월 17~21일) 참가하기</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe" button id="desktopKCButton">KubeCon Europe (2023년 4월 17~21일) 참가하기</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
--- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md
+++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md
@ -1,4 +1,7 @@
 ---
+
+
+
 title: 컨트롤 플레인-노드 간 통신
 content_type: concept
 weight: 20
@ -8,29 +11,49 @@ aliases:

 <!-- overview -->

-이 문서는 API 서버와 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
-
+이 문서는 API 서버와 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 
+이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 
+클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.


 <!-- body -->

 ## 노드에서 컨트롤 플레인으로의 통신
-쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다. API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.

-특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
+쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의
+모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 
+설계되지 않았다. API 서버는 하나 이상의 클라이언트 
+[인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된
+보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
+특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 
+또는[서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우,
+하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 
+사용해야 한다.

-노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
+노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 
+클러스터에 대한 공개 루트 인증서(root certificate)로 프로비전해야 한다. 클라이언트 인증서(client certificate) 형식으로 
+kubelet의 클라이언트 자격 증명을 사용하는 것은 좋은 방법이다.
+kubelet 클라이언트 인증서(client certificate)의 자동 프로비저닝은
+[kubelet TLS 부트스트랩](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)을 참고한다.

-API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다.
-`kubernetes` 서비스(`default` 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
+API 서버에 연결하려는 파드는 서비스 어카운트를 활용하여 안전하게
+쿠버네티스가 공개 루트 인증서(root certificate)와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 
+파드에 자동으로 주입할 수 있다.
+`kubernetes` 서비스(`default` 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는
+가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.

 컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다.

-결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다.
+결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한
+기본 작동 모드는 기본적으로 보호되며 
+신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다.

 ## 컨트롤 플레인에서 노드로의 통신

-컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다.
+컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 
+첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다.
+두 번째는 API 서버의 _프록시_ 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 
+이르는 것이다.

 ### API 서버에서 kubelet으로의 통신

@ -40,33 +63,56 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
 * 실행 중인 파드에 (보통의 경우 kubectl을 통해) 연결한다.
 * kubelet의 포트-포워딩 기능을 제공한다.

-이 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 서빙(serving) 인증서를 확인하지 않으므로, 연결이 중간자(man-in-the-middle) 공격의 대상이 되며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** .
+위와 같은 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 
+제공(serving) 인증서를 확인하지 않는다. 이는 연결이 중간자 공격(man-in-the-middle)에 시달리게 하며,
+신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** .

-이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여 API 서버에 kubelet의 서빙 인증서를 확인하는 데 사용할 루트 인증서 번들을 제공한다.
+이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여
+API 서버에 kubelet의 제공(serving) 인증서를 확인하는데 사용할 루트 인증서 번들을 제공한다.

-이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을
+이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해
+필요한 경우, API 서버와 kubelet 간 [SSH 터널링](#ssh-터널)을
 사용한다.

-마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)를 활성화해야 한다.
+
+마지막으로, kubelet API를 보호하려면 
+[Kubelet 인증 및/또는 인가](/ko/docs/reference/access-authn-authz/kubelet-authn-authz/)를 활성화해야 한다.

 ### API 서버에서 노드, 파드 및 서비스로의 통신

-API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않는다. 그래서 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
+API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로
+인증되거나 암호화되지 않는다. 이 연결에서 URL을 노드, 파드 또는 서비스 이름에 접두어 `https:` 을 붙여
+보안 HTTPS 연결이 되도록 실행할 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않으며
+클라이언트 자격 증명도 제공하지 않는다. 
+그래서 연결이 암호화되는 동안 그 어떤 무결성도 보장되지 않는다.
+이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .

 ### SSH 터널

-쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
-이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.
+쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 
+이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고
+(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 
+kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
+이 터널은 노드가 실행 중인 네트워크의 외부로 트래픽이 
+노출되지 않도록 한다.

 {{< note >}}
-SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안 된다. [Konnectivity 서비스](#konnectivity-service)가 SSH 통신 채널을 대체한다.
+SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안 된다. 
+[Konnectivity 서비스](#konnectivity-service)가 SSH 통신 채널을 
+대체한다.
 {{< note >}}

 ### Konnectivity 서비스 {#konnectivity-service}

 {{< feature-state for_k8s_version="v1.18" state="beta" >}}

-SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
-Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
+SSH 터널을 대체로, Konnectivity 서비스는 컨트롤 플레인과 클러스터 간 통신에 TCP 레벨 프록시를 제공한다.
+Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 
+노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다.
+Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 
+네트워크 연결을 유지한다.
+Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 
+이 연결을 통과한다.

-[Konnectivity 서비스 태스크](/ko/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.
+[Konnectivity 서비스 태스크](/ko/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 
+클러스터에서 Konnectivity 서비스를 설정한다.
--- a/content/ko/docs/concepts/architecture/nodes.md
+++ b/content/ko/docs/concepts/architecture/nodes.md
@ -476,13 +476,11 @@ kubelet의 노드 셧다운 관리자(Node Shutdown Mananger)가
 기존의 셧다운된 노드가 정상으로 돌아오지 못하면, 
 이러한 파드는 셧다운된 노드에 '종료 중(terminating)' 상태로 영원히 고착될 것이다.

-위와 같은 상황을 완화하기 위해, 
-사용자가 `node.kubernetes.io/out-of-service` 테인트를 
+위와 같은 상황을 완화하기 위해, 사용자가 `node.kubernetes.io/out-of-service` 테인트를 
 `NoExecute` 또는 `NoSchedule` 값으로 추가하여 
 노드를 서비스 불가(out-of-service) 상태로 표시할 수 있다. 
-`kube-controller-manager`에 `NodeOutOfServiceVolumeDetach` 
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고, 
-노드가 이 테인트에 의해 서비스 불가 상태로 표시되어 있는 경우, 
+`kube-controller-manager`에 `NodeOutOfServiceVolumeDetach`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
+가 활성화되어 있고, 노드가 이 테인트에 의해 서비스 불가 상태로 표시되어 있는 경우, 
 노드에 매치되는 톨러레이션이 없다면 노드 상의 파드는 강제로 삭제될 것이고, 
 노드 상에서 종료되는 파드에 대한 볼륨 해제(detach) 작업은 즉시 수행될 것이다. 
 이를 통해 서비스 불가 상태 노드의 파드가 빠르게 다른 노드에서 복구될 수 있다.
@ -492,7 +490,6 @@ kubelet의 노드 셧다운 관리자(Node Shutdown Mananger)가
 1. 매치되는 `out-of-service` 톨러레이션이 없는 파드를 강제로 삭제한다.
 2. 이러한 파드에 대한 볼륨 해제 작업을 즉시 수행한다.

-
 {{< note >}}
 - `node.kubernetes.io/out-of-service` 테인트를 추가하기 전에, 
  노드가 완전한 셧다운 또는 전원 꺼짐 상태에 있는지 
@ -500,8 +497,6 @@ kubelet의 노드 셧다운 관리자(Node Shutdown Mananger)가
 - 사용자가 서비스 불가 상태 테인트를 직접 추가한 것이기 때문에, 
  파드가 다른 노드로 옮겨졌고 셧다운 상태였던 노드가 복구된 것을 확인했다면 
  사용자가 서비스 불가 상태 테인트를 수동으로 제거해야 한다.
-
-
 {{< /note >}}

 ### 파드 우선순위 기반 그레이스풀 노드 셧다운 {#pod-priority-graceful-node-shutdown}
--- a/content/ko/docs/concepts/cluster-administration/_index.md
+++ b/content/ko/docs/concepts/cluster-administration/_index.md
@ -11,31 +11,37 @@ no_list: true
 ---

 <!-- overview -->
+
 클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다.
 핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다.

-
 <!-- body -->
+
 ## 클러스터 계획

-쿠버네티스 클러스터를 계획, 설정 및 구성하는 방법에 대한 예는 [시작하기](/ko/docs/setup/)에 있는 가이드를 참고한다. 이 문서에 나열된 솔루션을 *배포판* 이라고 한다.
+쿠버네티스 클러스터를 계획, 설정 및 구성하는 방법에 대한 예는 [시작하기](/ko/docs/setup/)에 있는 가이드를 참고한다. 
+이 문서에 나열된 솔루션을 *배포판* 이라고 한다.

-   {{< note  >}}
-   모든 배포판이 활발하게 유지되는 것은 아니다. 최신 버전의 쿠버네티스에서 테스트된 배포판을 선택한다.
-   {{< /note >}}
+ {{< note  >}}
+ 모든 배포판이 활발하게 유지되는 것은 아니다. 최신 버전의 쿠버네티스에서 테스트된 
+ 배포판을 선택한다.
+ {{< /note >}}

 가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다.

- - 컴퓨터에서 쿠버네티스를 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다.
- - [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가?
- - 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다.
- - **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다.
- - 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가?
- - **클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약
-   후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만,
-   더 다양한 선택을 제공한다.
- - 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자.
-
+- 컴퓨터에서 쿠버네티스를 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 
+  사용자의 필요에 따라 가장 적합한 배포판을 선택한다.
+- [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 
+  아니면, **자체 클러스터를 호스팅** 할 것인가?
+- 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 
+  쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다.
+- **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 
+  어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다.
+- 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가?
+- **클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 
+  만약 후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만,
+  더 다양한 선택을 제공한다.
+- 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자.

 ## 클러스터 관리

@ -45,29 +51,43 @@ no_list: true

 ## 클러스터 보안

-* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)은 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
+* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)은 다른 툴 체인을 사용하여 
+  인증서를 생성하는 단계를 설명한다.

-* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
+* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 
+  쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.

-* [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)는 쿠버네티스가 자체 API에 대한 접근 제어를 구현하는 방법을 설명한다.
+* [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)는 
+  쿠버네티스가 자체 API에 대한 접근 제어를 구현하는 방법을 설명한다.

-* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.
+* [인증](/docs/reference/access-authn-authz/authentication/)은 
+  다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.

-* [인가](/ko/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
+* [인가](/ko/docs/reference/access-authn-authz/authorization/)는 
+  인증과는 별개로, HTTP 호출 처리 방법을 제어한다.

-* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
+* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 
+  인증과 권한 부여 후 
+  쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.

-* [쿠버네티스 클러스터에서 Sysctls 사용하기](/ko/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
+* [쿠버네티스 클러스터에서 Sysctls 사용하기](/ko/docs/tasks/administer-cluster/sysctl-cluster/)는 
+  관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다
+.

-* [감사(audit)](/docs/tasks/debug/debug-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
+* [감사(audit)](/docs/tasks/debug/debug-cluster/audit/)는 
+  쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.

 ### kubelet 보안
-  * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
-  * [TLS 부트스트래핑(bootstrapping)](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
-  * [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
+
+* [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
+* [TLS 부트스트래핑(bootstrapping)](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
+* [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)

 ## 선택적 클러스터 서비스

-* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름을 쿠버네티스 서비스로 직접 확인하는 방법을 설명한다.
+* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 
+  DNS 이름을 쿠버네티스 서비스로 직접 확인하는 방법을 설명한다.
+
+* [클러스터 액티비티 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 
+  쿠버네티스에서의 로깅이 어떻게 작동하는지와 구현 방법에 대해 설명한다.

-* [클러스터 액티비티 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스에서의 로깅이 어떻게 작동하는지와 구현 방법에 대해 설명한다.
--- a/content/ko/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md
@ -331,7 +331,7 @@ kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리 사용으
 * `spec.containers[].resources.requests.ephemeral-storage`

 `ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다. 
-E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
+E, P, T, G, M, k와 같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
 Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
 예를 들어, 다음은 거의 동일한 값을 나타낸다.

@ -340,6 +340,10 @@ Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
 - `129M`
 - `123Mi`

+접미사의 대소문자에 유의한다.
+`400m`의 메모리를 요청하면, 이는 0.4 바이트를 요청한 것이다.
+이 사람은 아마도 400 메비바이트(mebibytes) (`400Mi`) 또는 400 메가바이트 (`400M`) 를 요청하고 싶었을 것이다.
+
 다음 예에서, 파드에 두 개의 컨테이너가 있다. 
 각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다. 
 각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다.