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

2022-08-16 12:51:09 +09:00 · 2022-08-16 12:51:09 +09:00 · abb9a42c50
parent b8f1812341
commit abb9a42c50
5 changed files with 165 additions and 106 deletions
--- a/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md
+++ b/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가 임계값을 초과할 때 즉시 알림을 받
 상태로 간주하고 노드가 메모리 압박을 겪고 있다고 테인트를 표시할 수 있으며, 이는 
 파드 축출을 유발한다.

-더 자세한 사항은 [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)를 참고한다.
+자세한 사항은 [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)를 참고한다.

 집중적인 I/O 작업을 수행할 가능성이 있는 컨테이너에 대해 메모리 제한량 및 메모리 
 요청량을 동일하게 설정하여 이 문제를 해결할 수 있다. 해당 컨테이너에 대한 최적의 
--- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/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/)에 대해 알아보기
--- a/content/ko/docs/concepts/security/controlling-access.md
+++ b/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 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다.
--- a/content/ko/docs/concepts/security/pod-security-policy.md
+++ b/content/ko/docs/concepts/security/pod-security-policy.md
@ -11,9 +11,13 @@ weight: 30

 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}}

-파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더 이상 사용되지 않으며, v1.25에서 제거될 예정이다. 
-파드시큐리티폴리시는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)으로 대체되었다.
-사용 중단에 대한 상세 사항은 [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
+{{< caution >}}
+파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더 이상 사용되지 않으며, **v1.25에서 제거될 예정**이다.
+[파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 혹은 써드파티 어드미션 플러그인으로 대체하는 것을 권장한다.
+상세 가이드는 [파드시큐리티폴리시를 파드 시큐리티 어드미션 컨트롤러로 대체하기](/docs/tasks/configure-pod-container/migrate-from-psp/)를 참조한다.
+사용 중단에 대한 상세 사항은
+[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
+{{< /caution >}}

 파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
 부여할 수 있다.
@ -23,10 +27,11 @@ weight: 30
 ## 파드 시큐리티 폴리시란?

 _Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 클러스터-레벨의
-리소스이다. [파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는
+리소스이다.
+[파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는
 관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는
-조건 셋을 정의한다. 관리자는
-다음을 제어할 수 있다.
+조건 셋을 정의한다.
+관리자는 다음을 제어할 수 있다.

 | 제어 측면                                            | 필드 이름                                 |
 | ----------------------------------------------------| ------------------------------------------- |
@ -150,14 +155,17 @@ RBAC 바인딩에 대한 자세한 예는,
 text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되고 있다.
 이 변경에 대한 상세사항은 
 [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
-다음 가이드라인을 참조하여 파드시큐리티폴리시를 새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다.
+다음 가이드라인을 참조하여 파드시큐리티폴리시를
+새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다.

-1. 파드시큐리티폴리시를 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다.
-    - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
-    - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
-    - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
+1. 파드시큐리티폴리시를
+   [파드 보안 표준](/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다.

-2. `system:serviceaccounts:<namespace>` (여기서 `<namespace>`는 타겟 네임스페이스) 그룹을 사용하여 
+   - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
+   - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
+   - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
+
+1. `system:serviceaccounts:<namespace>` (여기서 `<namespace>`는 타겟 네임스페이스) 그룹을 사용하여 
  파드시큐리티폴리시를 전체 네임스페이스에만 바인드한다. 예시는 다음과 같다.

    ```yaml
@ -182,16 +190,16 @@ text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되
 ### 문제 해결

 - [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는
-보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다.
-API 서버 접근 제어에 대한 자세한 내용은
-[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)를 참고하길 바란다.
-컨트롤러 관리자가 신뢰할 수 있는 API 포트(`localhost` 리스너라고도 함)를
-통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고,
-모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를
-만들 수 있는 권한을 부여할 수 있다.
+  보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다.
+  API 서버 접근 제어에 대한 자세한 내용은
+  [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)를 참고하길 바란다.
+  컨트롤러 관리자가 신뢰할 수 있는 API 포트(`localhost` 리스너라고도 함)를
+  통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고,
+  모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를
+  만들 수 있는 권한을 부여할 수 있다.

-컨트롤러 관리자 권한 구성에 대한 자세한 내용은
-[컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 참고하기 바란다.
+  컨트롤러 관리자 권한 구성에 대한 자세한 내용은
+  [컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 참고한다.

 ## 정책 순서

@ -206,6 +214,9 @@ API 서버 접근 제어에 대한 자세한 내용은
 2. 파드를 기본값으로 설정하거나 변경해야 하는 경우, 파드를 허용할 첫 번째 파드시큐리티폴리시
   (이름순)가 선택된다.

+파드시큐리티폴리시에 대해 파드의 유효성이 검증되면,
+파드시큐리티폴리시의 이름을 어노테이션 값으로 사용하는 [`kubernetes.io/psp` 어노테이션]이 파드에 추가된다.
+
 {{< note >}}
 업데이트 작업 중(파드 스펙에 대한 변경이 허용되지 않는 동안) 비-변이 파드시큐리티폴리시만
 파드의 유효성을 검사하는 데 사용된다.
@ -237,8 +248,7 @@ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n

 ### 정책과 파드 생성

-파일에서 예제 파드시큐리티폴리시 오브젝트를 정의한다. 이는 특권있는 파드를
-만들지 못하게 하는 정책이다.
+이는 특권있는 파드를 만들지 못하게 하는 정책이다.
 파드시큐리티폴리시 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다.

@ -247,7 +257,7 @@ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n
 그리고 kubectl로 생성한다.

 ```shell
-kubectl-admin create -f example-psp.yaml
+kubectl-admin create -f https://k8s.io/examples/policy/example-psp.yaml
 ```

 이제 권한이 없는 사용자로서 간단한 파드를 생성해보자.
@ -276,6 +286,11 @@ Error from server (Forbidden): error when creating "STDIN": pods "pause" is forb

 ```shell
 kubectl-user auth can-i use podsecuritypolicy/example
+```
+
+결과는 다음과 같다:
+
+```
 no
 ```

@ -292,14 +307,27 @@ kubectl-admin create role psp:unprivileged \
    --verb=use \
    --resource=podsecuritypolicy \
    --resource-name=example
-role "psp:unprivileged" created
+```

+```
+role "psp:unprivileged" created
+```
+
+```shell
 kubectl-admin create rolebinding fake-user:psp:unprivileged \
    --role=psp:unprivileged \
    --serviceaccount=psp-example:fake-user
-rolebinding "fake-user:psp:unprivileged" created
+```

+```
+rolebinding "fake-user:psp:unprivileged" created
+```
+
+```shell
 kubectl-user auth can-i use podsecuritypolicy/example
+```
+
+```
 yes
 ```

@ -324,7 +352,20 @@ EOF
 pod "pause" created
 ```

-예상대로 작동한다! 그러나 특권있는 파드를 만들려는 시도는 여전히
+예상대로 작동한다!
+새로 생성된 파드시큐리티폴리시에 대해서도 파드가 유효한지 검증한다:
+
+```shell
+kubectl-user get pod pause -o yaml | grep kubernetes.io/psp
+```
+
+결과는 다음과 같다:
+
+```
+kubernetes.io/psp: example
+```
+
+그러나 특권있는 파드를 만들려는 시도는 여전히
 거부되어야 한다.

 ```shell
@ -360,12 +401,24 @@ kubectl-user delete pod pause

 ```shell
 kubectl-user create deployment pause --image=k8s.gcr.io/pause
+```
+
+```none
 deployment "pause" created
-
+```
+```shell
 kubectl-user get pods
-No resources found.
+```

+```
+No resources found.
+```
+
+```shell
 kubectl-user get events | head -n 2
+```
+
+```
 LASTSEEN   FIRSTSEEN   COUNT     NAME              KIND         SUBOBJECT                TYPE      REASON                  SOURCE                                  MESSAGE
 1m         2m          15        pause-7774d79b5   ReplicaSet                            Warning   FailedCreate            replicaset-controller                   Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request
 ```
@ -386,6 +439,9 @@ forbidden: no providers available to validate pod request` 오류가
 kubectl-admin create rolebinding default:psp:unprivileged \
    --role=psp:unprivileged \
    --serviceaccount=psp-example:default
+```
+
+```none
 rolebinding "default:psp:unprivileged" created
 ```

@ -394,6 +450,9 @@ rolebinding "default:psp:unprivileged" created

 ```shell
 kubectl-user get pods --watch
+```
+
+```none
 NAME                    READY     STATUS    RESTARTS   AGE
 pause-7774d79b5-qrgcb   0/1       Pending   0         1s
 pause-7774d79b5-qrgcb   0/1       Pending   0         1s
@ -407,6 +466,9 @@ pause-7774d79b5-qrgcb   1/1       Running   0         2s

 ```shell
 kubectl-admin delete ns psp-example
+```
+
+```
 namespace "psp-example" deleted
 ```

@ -415,6 +477,9 @@ namespace "psp-example" deleted

 ```shell
 kubectl-admin delete psp example
+```
+
+```
 podsecuritypolicy "example" deleted
 ```

@ -431,7 +496,8 @@ podsecuritypolicy "example" deleted

 {{< codenew file="policy/restricted-psp.yaml" >}}

-더 많은 예제는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/#policy-instantiation)을 본다.
+더 많은 예제는
+[파드 보안 표준](/docs/concepts/security/pod-security-standards/#policy-instantiation)을 본다.

 ## 정책 레퍼런스

@ -511,7 +577,8 @@ podsecuritypolicy "example" deleted
     readOnly: true # 읽기 전용 마운트만 허용
 ```

-{{< warning >}}호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션
+{{< warning >}}
+호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션
 (다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할
 수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다.

@ -624,8 +691,7 @@ spec:

 **DefaultAddCapabilities** - 런타임 기본값 외에 기본적으로 컨테이너에 추가되는 기능이다.
 도커 런타임을 사용할 때 기본 기능 목록은
-[도커 문서](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)를
-참고하길 바란다.
+[도커 문서](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)를 참고한다.

 ### SELinux

@ -658,8 +724,9 @@ spec:

 쿠버네티스 v1.19부터 파드나 컨테이너의 `securityContext` 에서
 `seccompProfile` 필드를 사용하여 [seccomp 프로파일 사용을
-제어](/docs/tutorials/security/seccomp/)할 수 있다. 이전 버전에서는, 파드에
-어노테이션을 추가하여 seccomp를 제어했다. 두 버전에서 동일한 파드시큐리티폴리시를 사용하여
+제어](/docs/tutorials/security/seccomp/)할 수 있다.
+이전 버전에서는, 파드에 어노테이션을 추가하여 seccomp를 제어했다.
+두 버전에서 동일한 파드시큐리티폴리시를 사용하여
 이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다.

 **seccomp.security.alpha.kubernetes.io/defaultProfileName** - 컨테이너에
@ -692,11 +759,13 @@ spec:

 기본적으로 모든 안전한 sysctls가 허용된다.

- `forbiddenSysctls` - 특정 sysctls를 제외한다. 목록에서 안전한 것과 안전하지 않은 sysctls의 조합을 금지할 수 있다. 모든 sysctls 설정을 금지하려면 자체적으로 `*`를 사용한다.
- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.
+- `forbiddenSysctls` - 특정 sysctls를 제외한다.
+  목록에서 안전한 것과 안전하지 않은 sysctls의 조합을 금지할 수 있다.
+  모든 sysctls 설정을 금지하려면 자체적으로 `*`를 사용한다.
+- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한
+  기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.

-[Sysctl 문서](
-/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다.
+[Sysctl 문서](/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다.

 ## {{% heading "whatsnext" %}}

@ -706,4 +775,6 @@ spec:

 - 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다.

- API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
+- API 세부 정보는
+  [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
+
--- a/content/ko/docs/concepts/security/windows-security.md
+++ b/content/ko/docs/concepts/security/windows-security.md
@ -17,12 +17,13 @@ weight: 40

 ## 노드의 시크릿 데이터 보호

-윈도우에서, 시크릿에 있던 데이터는 노드의 로컬 스토리지에 
+윈도우에서는 시크릿 데이터가 노드의 로컬 스토리지에 
 평문으로 기록된다(리눅스는 tmpfs 또는 인메모리 파일시스템에 기록). 
 클러스터 운영자로서, 다음 2 가지의 추가 사항을 고려해야 한다.

 1. 파일 ACL을 사용하여 시크릿의 파일 위치를 보호한다.
-1. [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용하여 볼륨 수준의 암호화를 적용한다.
+1. [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용하여
+  볼륨 수준의 암호화를 적용한다.

 ## 컨테이너 사용자

@ -31,25 +32,31 @@ weight: 40
 해당 컨테이너 프로세스를 실행할 사용자를 지정할 수 있다. 
 이는 [RunAsUser](/ko/docs/concepts/security/pod-security-policy/#사용자-및-그룹)와 대략적으로 동등하다.

-윈도우 컨테이너는 ContainerUser와 ContainerAdministrator의 2 개의 기본 사용자 계정을 제공한다. 
+윈도우 컨테이너는 ContainerUser와 ContainerAdministrator라는 기본 사용자 계정을 2개 제공한다. 
 이 두 사용자 계정이 어떻게 다른지는 마이크로소프트의 _안전한 윈도우 컨테이너_ 문서 내의 
-[언제 ContainerAdmin 및 ContainerUser 사용자 계정을 사용해야 하는가](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts)를 참고한다.
+[언제 ContainerAdmin 및 ContainerUser 사용자 계정을 사용해야 하는가](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts)를
+참고한다.

 컨테이너 빌드 과정에서 컨테이너 이미지에 로컬 사용자를 추가할 수 있다.

 {{< note >}}

-* [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) 기반 이미지는 기본적으로 `ContainerUser`로 실행된다
-* [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) 기반 이미지는 기본적으로 `ContainerAdministrator`로 실행된다
+* [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) 기반 이미지는
+  기본적으로 `ContainerUser`로 실행된다
+* [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) 기반 이미지는
+  기본적으로 `ContainerAdministrator`로 실행된다

 {{< /note >}}

-[그룹 관리 서비스 어카운트](/ko/docs/tasks/configure-pod-container/configure-gmsa/)를 활용하여 윈도우 컨테이너를 Active Directory 사용자로 실행할 수도 있다.
+[그룹 관리 서비스 어카운트](/ko/docs/tasks/configure-pod-container/configure-gmsa/)를 활용하여
+윈도우 컨테이너를 Active Directory 사용자로 실행할 수도 있다.

 ## 파드-수준 보안 격리

 리눅스 특유의 파드 보안 컨텍스트 메커니즘(예: SELinux, AppArmor, Seccomp, 
 또는 커스텀 POSIX 기능)은 윈도우 노드에서 지원되지 않는다.

-특권을 가진(Privileged) 컨테이너는 윈도우에서 [지원되지 않는다](/ko/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext). 
-대신, 리눅스에서 권한 있는 컨테이너가 할 수 있는 작업 중 많은 부분을 윈도우에서 수행하기 위해 [HostProcess 컨테이너](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 사용할 수 있다.
+특권을 가진(Privileged) 컨테이너는
+윈도우에서 [지원되지 않는다](/ko/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext). 
+대신, 리눅스에서 권한 있는 컨테이너가 할 수 있는 작업 중 많은 부분을 윈도우에서 수행하기 위해
+[HostProcess 컨테이너](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 사용할 수 있다.