[ko] Update outdate files in dev-1.25-ko.1 (M74-M89)

Author: bconfiden2

content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md

@@ -37,7 +37,7 @@ card:
 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다.
 
 ```
-kubectl apply -f http://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml
+kubectl apply -f http://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml
 ```
 
 ## 대시보드 UI 접근

content/ko/docs/tasks/administer-cluster/namespaces.md

@@ -192,12 +192,12 @@ kubectl delete namespaces <insert-some-namespace-name>
 
     하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 내용을 볼 수 없다.
 
-    이를 보여주기 위해 `development` 네임스페이스에서 간단히 디플로이먼트와 파드를 생성하자.
+    이를 보여주기 위해 `development` 네임스페이스에 간단한 디플로이먼트와 파드를 생성하자.
 
     ```shell
-    kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname  -n=development --replicas=2
+    kubectl create deployment snowflake --image=registry.k8s.io/serve_hostname  -n=development --replicas=2
     ```
-    호스트 이름을 제공하는 기본 컨테이너로 `snowflake`라는 이름의 파드를 실행하는 레플리카 사이즈 2의 디플로이먼트를 생성했다.
+    단순히 호스트명을 제공해주는 `snowflake`라는 파드의 개수를 2개로 유지하는 디플로이먼트를 생성하였다.
 
     ```shell
     kubectl get deployment -n=development
@@ -226,10 +226,10 @@ kubectl delete namespaces <insert-some-namespace-name>
     kubectl get pods -n=production
     ```
 
-    프로덕션은 마치 가축을 키우는 것과 같다. 그래서 우리도 cattle(가축)이라는 이름의 파드들을 생성하도록 하겠다.
+    프로덕션이 가축 키우는 것을 좋아하듯이, 우리도 `production` 네임스페이스에 cattle(가축)이라는 이름의 파드를 생성한다.
 
     ```shell
-    kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production
+    kubectl create deployment cattle --image=registry.k8s.io/serve_hostname -n=production
     kubectl scale deployment cattle --replicas=5 -n=production
 
     kubectl get deployment -n=production

content/ko/docs/tasks/administer-cluster/sysctl-cluster.md

@@ -15,14 +15,13 @@ content_type: task
 
 {{< note >}}
 쿠버네티스 버전 1.23부터, kubelet은 `/` 또는 `.`를 
-sysctl 이름의 구분자로 사용하는 것을 지원한다. 
+sysctl 이름의 구분자로 사용하는 것을 지원한다.
+쿠버네티스 1.25 버전부터, 파드에 대해서도 sysctl을 설정할 때 슬래시 구분자를 지원하기 시작하였다.
 예를 들어, 동일한 sysctl 이름을 `kernel.shm_rmid_forced`와 같이 마침표를 구분자로 사용하여 나타내거나 
 `kernel/shm_rmid_forced`와 같이 슬래시를 구분자로 사용하여 나타낼 수 있다. 
 sysctl 파라미터 변환에 대한 세부 사항은 
 리눅스 맨페이지 프로젝트의 
-[sysctl.d(5)](http://man7.org/linux/man-pages/man5/sysctl.d.5.html) 페이지를 참고한다. 
-파드와 파드시큐리티폴리시(PodSecurityPolicy)에 대해 sysctl을 설정하는 기능에서는 
-아직 슬래시 구분자를 지원하지 않는다.
+[sysctl.d(5)](http://man7.org/linux/man-pages/man5/sysctl.d.5.html) 페이지를 참고한다.
 {{< /note >}}
 ## {{% heading "prerequisites" %}}
 
@@ -176,55 +175,3 @@ sysctl 설정이 필요한 노드에만 파드를 예약하는 것이 좋다.
 [노드 테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 
 사용하여 해당 파드를 오른쪽 노드에 
 스케줄하는 것을 추천한다.
-
-## 파드시큐리티폴리시(PodSecurityPolicy)
-
-{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
-
-또한 파드시큐리티폴리시의 `forbiddenSysctls` 및/또는 `allowedUnsafeSysctls` 필드에 
-sysctl 또는 sysctl 패턴 목록을 지정하여 파드에서 설정할 
-수 있는 sysctl를 제어할 수 있다. sysctl 패턴은 `kernel.*`과 같은 `*` 
-문자로 끝난다. `*` 문자 자체는 
-모든 sysctl와 일치한다.
-
-기본적으로 모든 safe sysctl은 허용된다.
-
-`forbiddenSysctls`와 `allowedUnsafeSysctls`는 모두 단순한 sysctl 이름 또는 
-sysctl 패턴 목록이다(`*`로 끝남). `*` 문자는 모든 sysctl과 일치한다.
-
-`forbiddenSysctls` 필드에는 특정 sysctl이 제외된다. 
-목록에서 safe sysctl과 unsafe sysctl의 조합을 금지할 수 있다.
-sysctl 설정을 금지하기 위해서는 `*`를 사용한다.
-
-`allowedUnsafeSysctls` 필드에 unsafe sysctl을 지정하고 `forbiddenSysctls` 필드가 
-존재하지 않는 경우, 파드시큐리티폴리시를 사용하여 
-sysctl을 파드에서 사용할 수 있다. 
-파드시큐리티폴리시의 모든 unsafe sysctl을 설정하려면 `*`를 사용한다.
-
-이 두 필드를 겹치도록 구성하지 않는다. 
-이는 지정된 sysctl이 허용 및 금지됨을 의미한다.
-
-{{< warning >}}
-파드시큐리티폴리시의 'allowedUnsafeSysctls' 필드를 통해 unsafe sysctl을 
-허용하는 경우, 해당 노드에서 sysctl이 
-'--allowed-unsafe-sysctls' kubelet 플래그를 통해 허용되지 않으면, 
-sysctl을 사용하는 모든 파드가 시작에 실패한다.
-{{< /warning >}}
-
-이 예에서는 `kernel.msg` 접두사가 붙은 unsafe sysctl을 설정할 수 있으며, 
-`kernel.shm_rmid_forced` sysctl의 설정을 허용하지 않는다.
-
-```yaml
-apiVersion: policy/v1beta1
-kind: PodSecurityPolicy
-metadata:
-  name: sysctl-psp
-spec:
-  allowedUnsafeSysctls:
-  - kernel.msg*
-  forbiddenSysctls:
-  - kernel.shm_rmid_forced
- ...
-```
-
-

content/ko/docs/tasks/configure-pod-container/static-pod.md

@@ -182,7 +182,7 @@ static-web   1/1     Running   0               2m
 ```
 
 {{< note >}}
-Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 및 [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/)를 확인한다.
+API 서버에서 미러 파드를 생성할 수 있는 권한이 kubelet에게 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다.
 {{< /note >}}
 
 스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은

content/ko/docs/tasks/debug/debug-application/debug-running-pod.md

@@ -378,7 +378,7 @@ kubectl exec -it cassandra -- sh
 
 ## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container}
 
-{{< feature-state state="beta" for_k8s_version="v1.23" >}}
+{{< feature-state state="stable" for_k8s_version="v1.25" >}}
 
 컨테이너가 크래시 됐거나 
 [distroless 이미지](http://github.com/GoogleContainerTools/distroless)처럼
@@ -392,7 +392,7 @@ kubectl exec -it cassandra -- sh
 먼저, 다음과 같이 파드를 추가한다.
 
 ```shell
-kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
+kubectl run ephemeral-demo --image=registry.k8s.io/pause:3.1 --restart=Never
 ```
 
 이 섹션의 예시에서는 디버깅 도구가 포함되지 않은 이미지의 사례를 보여드리기 위해
@@ -611,7 +611,7 @@ kubectl delete pod myapp myapp-debug
 ## 노드의 쉘을 사용해서 디버깅하기 {#node-shell-session}
 
 만약 위의 어떠한 방법도 사용할 수 없다면, 파드가 현재 동작 중인 노드를 찾아
-호스트의 네임스페이스로 동작하는 특권 파드를 생성할 수 있다.
+해당 노드에서 실행되는 파드를 생성할 수 있다.
 다음 `kubectl debug` 명령을 통해 해당 노드에서 인터랙티브한 쉘을 생성할 수 있다.
 
 ```shell
@@ -628,8 +628,9 @@ root@ek8s:/#
 
 * `kubectl debug`는 노드의 이름에 기반해 새로운 파드의 이름을
   자동으로 생성한다.
-* 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다.
 * 노드의 루트 파일시스템은 `/host`에 마운트된다.
+* 파드가 특권을 가지고 있지 않더라도, 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다. 따라서 몇몇 프로세스 정보를 읽어오거나, `chroot /host` 등의 작업은 수행될 수 없다.
+* 특권을 가진 파드가 필요한 경우에는 직접 생성한다.
 
 사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
 

content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md

@@ -25,7 +25,7 @@ weight: 15
 
 <!-- steps -->
 
-## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정
+## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정하기
 
 다음 단계는 확장 API 서버를 *높은 수준* 으로 설정하는 방법을 설명한다. 이 단계는 YAML 구성을 사용하거나 API를 사용하는 것에 상관없이 적용된다. 둘 사이의 차이점을 구체적으로 식별하려고 시도한다. YAML 구성을 사용하여 구현하는 방법에 대한 구체적인 예를 보려면, 쿠버네티스 리포지터리에서 [sample-apiserver](http://github.com/kubernetes/sample-apiserver/blob/master/README.md)를 참고할 수 있다.
 

content/ko/docs/tasks/inject-data-application/define-command-argument-container.md

@@ -46,33 +46,33 @@ weight: 10
 
 1. YAML 구성 파일을 활용해 파드를 생성한다.
 
-    ```shell
-    kubectl apply -f http://k8s.io/examples/pods/commands.yaml
-    ```
+   ```shell
+   kubectl apply -f http://k8s.io/examples/pods/commands.yaml
+   ```
 
 1. 실행 중인 파드들의 목록을 조회한다.
 
-    ```shell
-    kubectl get pods
-    ```
+   ```shell
+   kubectl get pods
+   ```
 
-    출력은 command-demo라는 파드 안에서 실행된 컨테이너가 완료되었다고 표시할
-    것이다.
+   command-demo라는 파드 안에서 실행된 컨테이너가 완료되었다고 출력될
+   것이다.
 
 1. 컨테이너 안에서 실행된 커맨드의 출력을 보기 위해, 파드의 로그를
 확인한다.
 
-    ```shell
-    kubectl logs command-demo
-    ```
+   ```shell
+   kubectl logs command-demo
+   ```
 
-    출력은 HOSTNAME과 KUBERNETES_PORT 환경 변수들의 값들을 표시할
-    것이다.
+   HOSTNAME과 KUBERNETES_PORT 환경 변수들의 값들이 출력될
+   것이다.
 
-    ```
-    command-demo
-    tcp://10.3.240.1:443
-    ```
+   ```
+   command-demo
+   tcp://10.3.240.1:443
+   ```
 
 ## 인자를 정의하기 위해 환경 변수를 사용하기
 

content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md

@@ -30,39 +30,39 @@ weight: 20
 
 1. YAML 구성 파일을 활용해 파드를 생성한다.
 
-    ```shell
-    kubectl apply -f http://k8s.io/examples/pods/inject/envars.yaml
-    ```
+   ```shell
+   kubectl apply -f http://k8s.io/examples/pods/inject/envars.yaml
+   ```
 
 1. 실행 중인 파드들의 목록을 조회한다.
 
-    ```shell
-    kubectl get pods -l purpose=demonstrate-envars
-    ```
+   ```shell
+   kubectl get pods -l purpose=demonstrate-envars
+   ```
 
-    출력은 아래와 비슷할 것이다.
+   결과는 다음과 같다.
 
-    ```
-    NAME            READY     STATUS    RESTARTS   AGE
-    envar-demo      1/1       Running   0          9s
-    ```
+   ```
+   NAME            READY     STATUS    RESTARTS   AGE
+   envar-demo      1/1       Running   0          9s
+   ```
 
 1. 파드의 컨테이너 환경 변수를 나열한다.
 
-    ```shell
-    kubectl exec envar-demo -- printenv
-    ```
+   ```shell
+   kubectl exec envar-demo -- printenv
+   ```
 
-    출력은 아래와 비슷할 것이다.
+   결과는 다음과 같다.
 
-    ```
-    NODE_VERSION=4.4.2
-    EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
-    HOSTNAME=envar-demo
-    ...
-    DEMO_GREETING=Hello from the environment
-    DEMO_FAREWELL=Such a sweet sorrow
-    ```
+   ```
+   NODE_VERSION=4.4.2
+   EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
+   HOSTNAME=envar-demo
+   ...
+   DEMO_GREETING=Hello from the environment
+   DEMO_FAREWELL=Such a sweet sorrow
+   ```
 
 {{< note >}}
 `env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지

content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md

@@ -20,50 +20,55 @@ weight: 20
 
 ## 컨테이너를 위한 종속 환경 변수 정의하기
 
-파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다. 
-종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다.
+파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다. 종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다.
 
-이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다.
+이 예제에서는 한 개의 컨테이너를 실행하는 파드를 생성한다.
+파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다.
+다음은 파드를 위한 구성 매니페스트 예시이다.
 
 {{< codenew file="pods/inject/dependent-envars.yaml" >}}
 
 1. YAML 구성 파일을 활용해 파드를 생성한다.
 
-    ```shell
-    kubectl apply -f http://k8s.io/examples/pods/inject/dependent-envars.yaml
-    ```
-    ```
-    pod/dependent-envars-demo created
-    ```
+   ```shell
+   kubectl apply -f http://k8s.io/examples/pods/inject/dependent-envars.yaml
+   ```
+   ```
+   pod/dependent-envars-demo created
+   ```
 
 2. 실행 중인 파드의 목록을 조회한다.
 
-    ```shell
-    kubectl get pods dependent-envars-demo
-    ```
-    ```
-    NAME                      READY     STATUS    RESTARTS   AGE
-    dependent-envars-demo     1/1       Running   0          9s
-    ```
+   ```shell
+   kubectl get pods dependent-envars-demo
+   ```
+   ```
+   NAME                      READY     STATUS    RESTARTS   AGE
+   dependent-envars-demo     1/1       Running   0          9s
+   ```
 
 3. 파드 안에서 동작 중인 컨테이너의 로그를 확인한다.
 
-    ```shell
-    kubectl logs pod/dependent-envars-demo
-    ```
-    ```
+   ```shell
+   kubectl logs pod/dependent-envars-demo
+   ```
+   ```
 
-    UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
-    SERVICE_ADDRESS=http://172.17.0.1:80
-    ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
-    ```
+   UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+   SERVICE_ADDRESS=http://172.17.0.1:80
+   ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+   ```
 
 위에서 보듯이, `SERVICE_ADDRESS`는 올바른 종속성 참조, `UNCHANGED_REFERENCE`는 잘못된 종속성 참조를 정의했으며 `ESCAPED_REFERENCE`는 종속성 참조를 건너뛴다.
 
-환경 변수가 참조될 때 해당 환경 변수가 미리 정의되어 있으면 `SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다.
+미리 정의된 환경 변수를 참조할 때는,
+`SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다.
 
-환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다. 
-일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다.
+`env` 목록 안에서의 순서가 영향을 준다는 것을 주의하자.
+목록에서 더 아래쪽에 명시된 환경 변수는, "정의된" 것으로 보지 않는다.
+이것이 바로 위의 예시에서 `UNCHANGED_REFERENCE`가 `$(PROTOCOL)`을 해석하지 못한 이유이다.
+
+환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다. 일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다.
 
 `$(VAR_NAME)` 구문은 이중 $로 이스케이프될 수 있다. (예: `$$(VAR_NAME)`)
 이스케이프된 참조는 참조된 변수가 정의되었는지 여부에 관계없이 해석을 수행하지 않는다.