Merge pull request #29998 from kubernetes/dev-1.22-ko.1

[ko] 1st Korean localization work for v1.22
This commit is contained in:
Kubernetes Prow Robot
2021-10-09 06:54:36 -07:00
committed by GitHub
105 changed files with 3053 additions and 648 deletions
@@ -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/)에 대해 알아본다.
@@ -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)를 참조한다.
## {{% heading "whatsnext" %}}
## 임시 컨테이너 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
```
* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
@@ -290,8 +290,9 @@ myapp-pod 1/1 Running 0 9m
초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
다음의 규칙이 적용된다.
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
높은 것은 *유효 초기화 요청량/상한* 이다.
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중
가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는
이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다.
* 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
* 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
* 리소스에 대한 유효한 초기화 요청량/상한
@@ -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초의 작은 일회성 유예 기간 연장을
요청한다.