Merge pull request #29834 from ClaudiaJKang/outdated-ko-1-22-p4

k8s-ci-robot · web-flow · commit 750c2e5894f5 · 2021-10-07T10:11:46.000-07:00
[ko] Update outdated files in dev-1.22-ko.1 (p4)
diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@@ -223,27 +223,31 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 
 ## 업데이트 전략
 
-쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
+스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
 파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를
-구성하거나 비활성화 할 수 있다.
+구성하거나 비활성화할 수 있다. 두 가지 가능한 전략이 있다.
 
-### 삭제 시(On Delete)
-
-`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의
-`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는
-스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의
+`OnDelete`(삭제시)
+: 스테이트풀셋의 `.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 
+스테이트풀셋 컨트롤러는 스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 
+사용자는 컨트롤러가 스테이트풀셋의
 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
 
-### 롤링 업데이트
+`RollingUpdate`(롤링 업데이트)
+: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
+구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.
+
+## 롤링 업데이트
+
+스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
+스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성한다. 이 과정에서 똑같이
+순차적으로 파드가 종료되고(가장 큰 순서 색인에서부터에서 작은 순서 색인쪽으로),
+각 파드의 업데이트는 한 번에 하나씩 한다.
 
-`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
-구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
-스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이
-순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지),
-각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될
-때까지 기다린다.
+쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다.
+`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
 
-#### 파티션(Partition)
+### 파티션 롤링 업데이트 {#partitions}
 
 `롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition`
 를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가
@@ -255,7 +259,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.
 
-#### 강제 롤백
+### 강제 롤백
 
 기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과
 함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우
@@ -273,8 +277,19 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 
 템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로
 실행하려고 시도한 모든 파드를 삭제해야 한다.
-그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다.
+그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다.
+
+### 최소 준비 시간 초 {#minimum-ready-seconds}
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록 
+컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
+기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
+파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
+[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
 
+이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.
 
 ## {{% heading "whatsnext" %}}
 
diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md
@@ -257,8 +257,12 @@ POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여
 
 ## 컨테이너에 대한 특권 모드
 
-파드의 모든 컨테이너는 컨테이너 명세의 [보안 콘텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
-특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다.
+리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
+클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다.
+
+파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다.
+
+HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.
 
 {{< note >}}
 이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다.
@@ -282,6 +286,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
 여기에서 제어할 수는 없다는 의미이다.
 
+## 컨테이너 프로브
+
+_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
+
+- `ExecAction` (컨테이너 런타임의 도움을 받아 수행)
+- `TCPSocketAction` (kubelet에 의해 직접 검사)
+- `HTTPGetAction` (kubelet에 의해 직접 검사)
+
+[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은
+파드 라이프사이클 문서를 참고한다.
+
 ## {{% heading "whatsnext" %}}
 
 * [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -6,15 +6,15 @@ weight: 80
 
 <!-- overview -->
 
-{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
+{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
 
-이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
-트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서
-임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시
-컨테이너를 사용한다.
+이 페이지는 임시 컨테이너에 대한 개요를 제공한다. 
+이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해 
+기존 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 임시적으로 실행된다. 
+임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다.
 
 {{< warning >}}
-임시 컨테이너는 초기 알파 상태이며,
+임시 컨테이너 기능은 알파 상태이며,
 프로덕션 클러스터에는 적합하지 않다.
 [쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
@@ -72,119 +72,8 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
 
 임시 컨테이너 사용 시 [프로세스 네임스페이스
 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
-활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다.
-
-임시 컨테이너를 사용해서 문제를 해결하는 예시는
-[임시 디버깅 컨테이너로 디버깅하기]
-(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다.
-
-## 임시 컨테이너 API
-
-{{< note >}}
-이 섹션의 예시는 `EphemeralContainers` [기능
-게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의
-활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
-{{< /note >}}
-
-이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
-보여준다. 일반적으로 `kubectl debug` 또는
-다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
-사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
-
-임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를
-사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저
-`EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다.
-
-```json
-{
-    "apiVersion": "v1",
-    "kind": "EphemeralContainers",
-    "metadata": {
-        "name": "example-pod"
-    },
-    "ephemeralContainers": [{
-        "command": [
-            "sh"
-        ],
-        "image": "busybox",
-        "imagePullPolicy": "IfNotPresent",
-        "name": "debugger",
-        "stdin": true,
-        "tty": true,
-        "terminationMessagePolicy": "File"
-    }]
-}
-```
-
-이미 실행중인 `example-pod` 에 임시 컨테이너를 업데이트 한다.
-
-```shell
-kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers  -f ec.json
-```
-
-그러면 새로운 임시 컨테이너 목록이 반환된다.
-
-```json
-{
-   "kind":"EphemeralContainers",
-   "apiVersion":"v1",
-   "metadata":{
-      "name":"example-pod",
-      "namespace":"default",
-      "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
-      "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
-      "resourceVersion":"15886",
-      "creationTimestamp":"2019-08-29T06:41:42Z"
-   },
-   "ephemeralContainers":[
-      {
-         "name":"debugger",
-         "image":"busybox",
-         "command":[
-            "sh"
-         ],
-         "resources":{
-
-         },
-         "terminationMessagePolicy":"File",
-         "imagePullPolicy":"IfNotPresent",
-         "stdin":true,
-         "tty":true
-      }
-   ]
-}
-```
-
-사용자는 `kubectl describe` 를 사용해서 새로 만든 임시 컨테이너의 상태를 볼 수 있다.
-
-```shell
-kubectl describe pod example-pod
-```
-
-```
-...
-Ephemeral Containers:
-  debugger:
-    Container ID:  docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
-    Image:         busybox
-    Image ID:      docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
-    Port:          <none>
-    Host Port:     <none>
-    Command:
-      sh
-    State:          Running
-      Started:      Thu, 29 Aug 2019 06:42:21 +0000
-    Ready:          False
-    Restart Count:  0
-    Environment:    <none>
-    Mounts:         <none>
-...
-```
-
-예시와 같이 `kubectl attach`, `kubectl exec`, 그리고 `kubectl logs` 를 사용해서
-다른 컨테이너와 같은 방식으로 새로운 임시 컨테이너와
-상호작용할 수 있다.
-
-```shell
-kubectl attach -it example-pod -c debugger
-```
+활성화하면 다른 컨테이너 안의 프로세스를 보는 데 도움이 된다.
+
+## {{% heading "whatsnext" %}}
+
+* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md
@@ -290,8 +290,9 @@ myapp-pod   1/1       Running   0          9m
 초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
 다음의 규칙이 적용된다.
 
-* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
-  높은 것은 *유효한 초기화 요청량/상한* 이다.
+* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 
+  가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는 
+  이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다.
 * 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
   * 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
   * 리소스에 대한 유효한 초기화 요청량/상한
diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -379,7 +379,7 @@ TERM 대신 이 값을 보낸다.
    확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료
    프로세스를 시작한다.
    1. 파드의 컨테이너 중 하나가 `preStop`
-      [훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은
+      [훅](/ko/docs/concepts/containers/container-lifecycle-hooks)을 정의한 경우, kubelet은
       컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이
       계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을
       요청한다.
diff --git a/content/ko/docs/contribute/generate-ref-docs/quickstart.md b/content/ko/docs/contribute/generate-ref-docs/quickstart.md
@@ -6,7 +6,7 @@ weight: 40
 
 <!-- overview -->
 
-이 문서에서는 `update-imported-docs` 스크립트를 사용하여 
+이 문서에서는 `update-imported-docs.py` 스크립트를 사용하여 
 쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다. 
 이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다.
 
@@ -39,7 +39,7 @@ git clone git@github.com:<your_github_username>/website.git
 
 ## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs}
 
-`update-imported-docs` 스크립트는 `<web-base>/update-imported-docs/` 
+`update-imported-docs.py` 스크립트는 `<web-base>/update-imported-docs/` 
 디렉터리에 존재한다.
 
 이 스크립트는 다음 레퍼런스를 생성한다.
@@ -48,7 +48,7 @@ git clone git@github.com:<your_github_username>/website.git
 * `kubectl` 명령어 레퍼런스
 * 쿠버네티스 API 레퍼런스
 
-`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를 
+`update-imported-docs.py` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를 
 생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를 
 생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와 
 `kubernetes-sigs/reference-docs` 저장소를 클론하며, 
@@ -69,7 +69,7 @@ git clone git@github.com:<your_github_username>/website.git
 `kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다.
 `K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다.
 
-`update-imported-docs` 스크립트는 다음의 과정을 수행한다.
+`update-imported-docs.py` 스크립트는 다음의 과정을 수행한다.
 
 1. 환경설정 파일에 있는 관련 저장소를 클론한다. 
    레퍼런스 문서 생성을 위해 
@@ -152,11 +152,11 @@ repos:
 
 ## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool}
 
-다음과 같이 `update-imported-docs` 도구를 실행할 수 있다.
+다음과 같이 `update-imported-docs.py` 도구를 실행할 수 있다.
 
 ```shell
 cd <web-base>/update-imported-docs
-./update-imported-docs <configuration-file.yml> <release-version>
+./update-imported-docs.py <configuration-file.yml> <release-version>
 ```
 
 예를 들면 다음과 같다.
@@ -254,4 +254,3 @@ static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fon
 * [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/)
 * [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/)
 
-
diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md
@@ -71,8 +71,10 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
 사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
 제공하지 않는다.
 
+* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
 * [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
 * [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
 * [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
 * [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
 * [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
@@ -82,6 +84,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
 ## kubeadm을 위한 API 설정
 
 * [v1beta2](/docs/reference/config-api/kubeadm-config.v1beta2/)
+* [v1beta3](/docs/reference/config-api/kubeadm-config.v1beta3/)
 
 ## 설계 문서
 
diff --git a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
