whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Second Korean l10n work for release 1.18

Browse Source 
* Translate /concepts/cluster-administration/kubelet-garbage-collection in Korean (#20274)
* Translate cluster-administration/logging.md in Korean (#20409)
* Translate tasks/configure-pod-container/assign-memory-resource.md in … (#20167)
* Translate community/_index.html in Korean. (#20317)
* Translate storage/storage-classes.md in Korean. (#20310)
* Translate configuration/resource-bin-packing.md in Korean. (#20276)
* Translate extend-kubernetes/compute-storage-net/device-plugins.md (#20406)
* Translate compute-storage-net/network-plugins.md in Korean (#20407)
* Translate concepts/cluster-administration/certificates.md (#20330)
* Translate assign-pods-nodes-using-node-affinity to Korean (#20307)
* Translate cluster-administration/manage-deployment.md in Korean (#20366)
* Translate configuration/taint-and-toleration.md in Korean (#20404)
* Translate logging-elasticsearch-kibana.md in Korean (#20300)
* add anchors of subtitle in ko/docs/concepts/policy/pod-security-policy (#20399)
* Translate task/scheduling-gpus in Korean (#20212)
* Translate conceps/storage/volume-snapshots in Korean (#19955)
* Translate network/validate-dual-stack.md in Korean (#20271)
* Update to Outdated files in the dev-1.18-ko.2 branch. (#20244)
* Update to a link to the newly translated document. (#20247)

Co-Authored-By: bluefriday <bluefriday86@gmail.com>
Co-Authored-By: cometrojan <d.gweon@samsung.com>
Co-Authored-By: coolguyhong <podolsmith@naver.com>
Co-Authored-By: DongMoon Kim <dmoons.kim@gmail.com>
Co-Authored-By: Jerry Park <jaehwa@gmail.com>
Co-Authored-By: jmyung <jesang.myung@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
Co-Authored-By: seokho-son <shsongist@gmail.com>
Co-Authored-By: sunminjeon <sunmin.jeon@samsung.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
This commit is contained in:
June Yi
2020-04-24 00:07:32 +09:00
parent dc3ce88f55
commit c74ce882ec
76 changed files with 4892 additions and 614 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+10 -9
View File
@@ -149,17 +149,17 @@ users:
username: exp
```
위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로를 위한
위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한
플레이스홀더(placeholder)이다.
당신의 환경에 맞게 이들을 실제 인증서 경로로 변경해줘야 한다.
만약 당신이 인증서 파일들의 경로 대신에 base64로 인코딩된 데이터를 여기에 사용하려고 한다면
키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`,
만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면
이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`,
`client-certificate-data`, `client-key-data` 같이 사용할 수 있다.
컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어
`dev-frontend` 컨텍스트는 `development` 클러스터의 `frontend` 네임스페이스에 접근하는데
`developer` 사용자 자격증명을 사용하라고 알려준다.
`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데
`developer` 사용자 자격증명을 사용하라고 알려준다."
현재 컨텍스트를 설정한다.
@@ -275,7 +275,7 @@ Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으
`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
익숙해지길 바란다.
다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자.<br>
다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자.
### Linux
```shell
@@ -359,11 +359,13 @@ kubectl config view
## 정리
`KUBECONFIG` 환경 변수를 원래 값으로 되돌려 놓자. 예를 들면:<br>
Linux:
### Linux
```shell
export KUBECONFIG=$KUBECONFIG_SAVED
```
Windows PowerShell
### Windows PowerShell
```shell
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
```
@@ -378,4 +380,3 @@ Windows PowerShell
{{% /capture %}}
content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md
+356
View File
@@ -0,0 +1,356 @@
---
title: 컨테이너 및 파드 메모리 리소스 할당
content_template: templates/task
weight: 10
---
{{% capture overview %}}
이 페이지는 메모리 *요청량* 과 메모리 *상한* 을 컨테이너에 어떻게 지정하는지 보여준다.
컨테이너는 요청량 만큼의 메모리 확보가 보장되나
상한보다 더 많은 메모리는 사용할 수 없다.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
클러스터의 각 노드에 최소 300 MiB 메모리가 있어야 한다.
이 페이지의 몇 가지 단계를 수행하기 위해서는 클러스터 내
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면
다음 단계를 건너뛸 수 있다.
Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 활성화 할 수 있다.
```shell
minikube addons enable metrics-server
```
metric-server가 실행 중인지 확인하거나 다른 제공자의 리소스 메트릭 API (`metrics.k8s.io`)를 확인하기 위해
다음의 명령어를 실행한다.
```shell
kubectl get apiservices
```
리소스 메트릭 API를 사용할 수 있다면 출력에
`metrics.k8s.io`에 대한 참조가 포함되어 있다.
```shell
NAME
v1beta1.metrics.k8s.io
```
{{% /capture %}}
{{% capture steps %}}
## 네임스페이스 생성
이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 네임스페이스를 생성한다.
```shell
kubectl create namespace mem-example
```
## 메모리 요청량 및 상한을 지정
컨테이너에 메모리 요청량을 지정하기 위해서는 컨테이너의 리소스 매니페스트에
`resources:requests` 필드를 포함한다. 리소스 상한을 지정하기 위해서는
`resources:limits` 필드를 포함한다.
이 예제에서 하나의 컨테이너를 가진 파드를 생성한다. 생성된 컨테이너는
100 MiB 메모리 요청량과 200 MiB 메모리 상한을 갖는다. 이 것이 파드 구성 파일이다.
{{< codenew file="pods/resource/memory-request-limit.yaml" >}}
구성 파일 내 `args` 섹션은 컨테이너가 시작될 때 아규먼트를 제공한다.
`"--vm-bytes", "150M"` 아규먼트는 컨테이너가 150 MiB 할당을 시도 하도록 한다.
파드 생성:
```shell
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
```
파드 컨테이너가 실행 중인지 확인:
```shell
kubectl get pod memory-demo --namespace=mem-example
```
파드에 대한 자세한 정보 보기:
```shell
kubectl get pod memory-demo --output=yaml --namespace=mem-example
```
출력은 파드 내 하나의 컨테이너에 100MiB 메모리 요청량과
200 MiB 메모리 상한이 있는 것을 보여준다.
```yaml
...
resources:
limits:
memory: 200Mi
requests:
memory: 100Mi
...
```
`kubectl top`을 실행하여 파드 메트릭 가져오기:
```shell
kubectl top pod memory-demo --namespace=mem-example
```
출력은 파드가 약 150MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다.
이는 파드의 100 MiB 요청 보다 많으나 파드의 200 MiB 상한보다는 적다.
```
NAME CPU(cores) MEMORY(bytes)
memory-demo <something> 162856960
```
파드 삭제:
```shell
kubectl delete pod memory-demo --namespace=mem-example
```
## 컨테이너의 메모리 상한을 초과
노드 내 메모리가 충분하다면 컨테이너는 지정한 요청량보다 많은 메모리를 사용 할 수 있다. 그러나
컨테이너는 지정한 메모리 상한보다 많은 메모리를 사용할 수 없다. 만약 컨테이너가 지정한 메모리 상한보다
많은 메모리를 할당하면 해당 컨테이너는 종료 대상 후보가 된다. 만약 컨테이너가 지속적으로
지정된 상한보다 많은 메모리를 사용한다면, 해당 컨테이너는 종료된다. 만약 종료된 컨테이너가
재실행 가능하다면 다른 런타임 실패와 마찬가지로 kubelet에 의해 재실행된다.
이 예제에서는 상한보다 많은 메모리를 할당하려는 파드를 생성한다.
이 것은 50 MiB 메모리 요청량과 100 MiB 메모리 상한을 갖는
하나의 컨테이너를 갖는 파드의 구성 파일이다.
{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
구성 파일의 'args' 섹션에서 컨테이너가
100 MiB 상한을 훨씬 초과하는 250 MiB의 메모리를 할당하려는 것을 볼 수 있다.
파드 생성:
```shell
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example
```
파드에 대한 자세한 정보 보기:
```shell
kubectl get pod memory-demo-2 --namespace=mem-example
```
이 시점에 컨테이너가 실행되거나 종료되었을 수 있다. 컨테이너가 종료될 때까지 이전의 명령을 반복한다.
```shell
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 24s
```
컨테이너 상태의 상세 상태 보기:
```shell
kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
```
컨테이너가 메모리 부족 (OOM) 으로 종료되었음이 출력된다.
```shell
lastState:
terminated:
containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
exitCode: 137
finishedAt: 2017-06-20T20:52:19Z
reason: OOMKilled
startedAt: null
```
이 예제에서 컨테이너는 재실행 가능하여 kubelet에 의해 재실행된다.
컨테이너가 종료되었다 재실행되는 것을 보기 위해 다음 명령을 몇 번 반복한다.
```shell
kubectl get pod memory-demo-2 --namespace=mem-example
```
출력은 컨테이너의 종료, 재실행, 재종료, 재실행 등을 보여준다.
```
kubectl get pod memory-demo-2 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 37s
```
```
kubectl get pod memory-demo-2 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-2 1/1 Running 2 40s
```
파드 내역에 대한 상세 정보 보기:
```
kubectl describe pod memory-demo-2 --namespace=mem-example
```
컨테이너가 반복적으로 시작하고 실패 하는 출력을 보여준다.
```
... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
... Warning BackOff Back-off restarting failed container
```
클러스터 노드에 대한 자세한 정보 보기:
```
kubectl describe nodes
```
출력에는 컨테이너가 메모리 부족으로 종료된 기록이 포함된다.
```
Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child
```
파드 삭제:
```shell
kubectl delete pod memory-demo-2 --namespace=mem-example
```
## 노드에 비해 너무 큰 메모리 요청량의 지정
메모리 요청량과 상한은 컨테이너와 관련있지만, 파드가 가지는
메모리 요청량과 상한으로 이해하면 유용하다. 파드의 메모리 요청량은
파드 내 모든 컨테이너의 메모리 요청량의 합이다. 마찬가지로
파드의 메모리 상한은 파드 내 모든 컨테이너의 메모리 상한의 합이다.
파드는 요청량을 기반하여 스케줄링된다. 노드에 파드의 메모리 요청량을 충족하기에 충분한 메모리가 있는
경우에만 파드가 노드에서 스케줄링된다.
이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다.
다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는
컨테이너를 갖는 파드의 구성 파일이다.
{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
파드 생성:
```shell
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
```
파드 상태 보기:
```shell
kubectl get pod memory-demo-3 --namespace=mem-example
```
파드 상태가 PENDING 상태임이 출력된다. 즉 파드는 어떤 노드에서도 실행되도록 스케줄 되지 않고 PENDING가 계속 지속된다.
```
kubectl get pod memory-demo-3 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-3 0/1 Pending 0 25s
```
이벤트를 포함한 파드 상세 정보 보기:
```shell
kubectl describe pod memory-demo-3 --namespace=mem-example
```
출력은 노드 내 메모리가 부족하여 파드가 스케줄링될 수 없음을 보여준다.
```shell
Events:
... Reason Message
------ -------
... FailedScheduling No nodes are available that match all of the following predicates:: Insufficient memory (3).
```
## 메모리 단위
메모리 리소스는 byte 단위로 측정된다. 다음 접미사 중 하나로 정수 또는 고정 소수점으로
메모리를 표시할 수 있다. E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki.
예를 들어 다음은 거의 유사한 값을 나타낸다.
```shell
128974848, 129e6, 129M , 123Mi
```
파드 삭제:
```shell
kubectl delete pod memory-demo-3 --namespace=mem-example
```
## 메모리 상한을 지정하지 않으면
컨테이너에 메모리 상한을 지정하지 않으면 다음 중 하나가 적용된다.
* 컨테이너가 사용할 수 있는 메모리 상한은 없다. 컨테이너가
실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행 될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이
없는 컨테이너가 종료될 가능성이 크다.
* 기본 메모리 상한을 갖는 네임스페이스 내에서 실행중인 컨테이너는
자동으로 기본 메모리 상한이 할당된다. 클러스터 관리자들은
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)를
사용해 메모리 상한의 기본 값을 지정 가능하다.
## 메모리 요청량과 상한 동기부여
클러스터에서 실행되는 컨테이너에 메모리 요청량과 상한을 구성하여
클러스터 내 노드들의 메모리 리소스를 효율적으로 사용할 수 있게 할 수 있다.
파드의 메모리 요청량을 적게 유지하여 파드가 높은 확률로 스케줄링 될 수 있도록 한다.
메모리 상한이 메모리 요청량보다 크면 다음 두 가지가 수행된다.
* 가용한 메모리가 있는 경우 파드가 이를 사용할 수 있는 버스트(burst) 활동을 할 수 있다.
* 파드가 버스트 중 사용 가능한 메모리 양이 적절히 제한된다.
## 정리
네임스페이스를 지운다. 이 작업을 통해 네임스페이스 내 생성했던 모든 파드들은 삭제된다.
```shell
kubectl delete namespace mem-example
```
{{% /capture %}}
{{% capture whatsnext %}}
### 앱 개발자들을 위한
* [CPU 리소스를 컨테이너와 파드에 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [파드에 서비스 품질 설정](/docs/tasks/configure-pod-container/quality-service-pod/)
### 클러스터 관리자들을 위한
* [네임스페이스에 기본 메모리 요청량 및 상한을 구성](/docs/tasks/administer-cluster/memory-default-namespace/)
* [네임스페이스에 기본 CPU 요청량 및 상한을 구성](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [네임스페이스에 최소 및 최대 메모리 제약 조건 구성](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [네임스페이스에 최소 및 최대 CPU 제약 조건 구성](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [네임스페이스에 메모리 및 CPU 할당량 구성](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [네임스페이스에 파드 할당량 구성](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [API 오브젝트에 할당량 구성 ](/docs/tasks/administer-cluster/quota-api-object/)
{{% /capture %}}
content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md
+120
View File
@@ -0,0 +1,120 @@
---
title: 노드 어피니티를 사용해 노드에 파드 할당
min-kubernetes-server-version: v1.10
content_template: templates/task
weight: 120
---
{{% capture overview %}}
이 문서는 쿠버네티스 클러스터의 특정 노드에 노드 어피니티를 사용해 쿠버네티스 파드를 할당하는
방법을 설명한다.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 노드에 레이블 추가
1. 클러스터의 노드를 레이블과 함께 나열하자.
```shell
kubectl get nodes --show-labels
```
결과는 아래와 같다.
```shell
NAME STATUS ROLES AGE VERSION LABELS
worker0 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker0
worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1
worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
```
1. 노드 한 개를 선택하고, 레이블을 추가하자.
```shell
kubectl label nodes <your-node-name> disktype=ssd
```
`<your-node-name>` 는 선택한 노드의 이름이다.
1. 선택한 노드가 `disktype=ssd` 레이블을 갖고 있는지 확인하자.
```shell
kubectl get nodes --show-labels
```
결과는 아래와 같다.
```
NAME STATUS ROLES AGE VERSION LABELS
worker0 Ready <none> 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0
worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1
worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
```
위의 결과에서, `worker0` 노드에 `disktype=ssd` 레이블이 있는 것을
확인할 수 있다.
## 필수적인 노드 어피니티를 사용해 파드 스케줄하기
이 매니페스트는 `disktype: ssd` 라는 `requiredDuringSchedulingIgnoredDuringExecution` 노드 어피니티를 가진 파드를 설명한다.
파드가 `disktype=ssd` 레이블이 있는 노드에만 스케줄될 것이라는 것을 의미한다.
{{< codenew file="pods/pod-nginx-required-affinity.yaml" >}}
1. 매니페스트를 적용하여 선택한 노드에 스케줄된 파드를
생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml
```
1. 파드가 선택한 노드에서 실행 중인지 확인하자.
```shell
kubectl get pods --output=wide
```
결과는 아래와 같다.
```
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```
## 선호하는 노드 어피니티를 사용해 파드 스케줄하기
이 매니페스트는 `disktype: ssd` 라는 `preferredDuringSchedulingIgnoredDuringExecution` 노드 어피니티를 가진 파드를 설명한다.
파드가 `disktype=ssd` 레이블이 있는 노드를 선호한다는 것을 의미한다.
{{< codenew file="pods/pod-nginx-preferred-affinity.yaml" >}}
1. 매니페스트를 적용하여 선택한 노드에 스케줄된 파드를
생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml
```
1. 파드가 선택한 노드에서 실행 중인지 확인하자.
```shell
kubectl get pods --output=wide
```
결과는 아래와 같다.
```
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```
{{% /capture %}}
{{% capture whatsnext %}}
[노드 어피니티](/ko/docs/concepts/configuration/assign-pod-node/#node-affinity)에
대해 더 알아보기.
{{% /capture %}}
content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+121
View File
@@ -0,0 +1,121 @@
---
content_template: templates/concept
title: 엘라스틱서치(Elasticsearch) 및 키바나(Kibana)를 사용한 로깅
---
{{% capture overview %}}
Google 컴퓨트 엔진(Compute Engine, GCE) 플랫폼에서, 기본 로깅 지원은
[스택드라이버(Stackdriver) 로깅](https://cloud.google.com/logging/)을 대상으로 한다. 이는
[스택드라이버 로깅으로 로깅하기](/docs/user-guide/logging/stackdriver)에 자세히 설명되어 있다.
이 문서에서는 GCE에서 운영할 때 스택드라이버 로깅의 대안으로,
[엘라스틱서치](https://www.elastic.co/products/elasticsearch)에 로그를 수집하고
[키바나](https://www.elastic.co/products/kibana)를 사용하여 볼 수 있도록
클러스터를 설정하는 방법에 대해 설명한다.
{{< note >}}
Google 쿠버네티스 엔진(Kubernetes Engine)에서 호스팅되는 쿠버네티스 클러스터에는 엘라스틱서치 및 키바나를 자동으로 배포할 수 없다. 수동으로 배포해야 한다.
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
클러스터 로깅에 엘라스틱서치, 키바나를 사용하려면 kube-up.sh를 사용하여
클러스터를 생성할 때 아래와 같이 다음의 환경 변수를
설정해야 한다.
```shell
KUBE_LOGGING_DESTINATION=elasticsearch
```
또한 `KUBE_ENABLE_NODE_LOGGING=true`(GCE 플랫폼의 기본값)인지 확인해야 한다.
이제, 클러스터를 만들 때, 각 노드에서 실행되는 Fluentd 로그 수집 데몬이
엘라스틱서치를 대상으로 한다는 메시지가 나타난다.
```shell
cluster/kube-up.sh
```
```
...
Project: kubernetes-satnam
Zone: us-central1-b
... calling kube-up
Project: kubernetes-satnam
Zone: us-central1-b
+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
Looking for already existing resources
Starting master and configuring firewalls
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
NAME ZONE SIZE_GB TYPE STATUS
kubernetes-master-pd us-central1-b 20 pd-ssd READY
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
+++ Logging using Fluentd to elasticsearch
```
노드별 Fluentd 파드, 엘라스틱서치 파드 및 키바나 파드는
클러스터가 활성화된 직후 kube-system 네임스페이스에서 모두 실행되어야
한다.
```shell
kubectl get pods --namespace=kube-system
```
```
NAME READY STATUS RESTARTS AGE
elasticsearch-logging-v1-78nog 1/1 Running 0 2h
elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h
kibana-logging-v1-bhpo8 1/1 Running 0 2h
kube-dns-v3-7r1l9 3/3 Running 0 2h
monitoring-heapster-v4-yl332 1/1 Running 1 2h
monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
```
`fluentd-elasticsearch` 파드는 각 노드에서 로그를 수집하여
`elasticsearch-logging` 파드로 전송한다. 이 로그는 `elasticsearch-logging` 이라는
[서비스](/ko/docs/concepts/services-networking/service/)의 일부이다. 이
엘라스틱서치 파드는 로그를 저장하고 REST API를 통해 노출한다.
`kibana-logging` 파드는 엘라스틱서치에 저장된 로그를 읽기 위한 웹 UI를
제공하며, `kibana-logging` 이라는 서비스의 일부이다.
엘라스틱서치 및 키바나 서비스는 모두 `kube-system` 네임스페이스에
있으며 공개적으로 접근 가능한 IP 주소를 통해 직접 노출되지 않는다. 이를 위해,
[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에 대한 지침을 참고한다.
브라우저에서 `elasticsearch-logging` 서비스에 접근하려고 하면,
다음과 같은 상태 페이지가 표시된다.
![엘라스틱서치 상태](/images/docs/es-browser.png)
원할 경우, 이제 엘라스틱서치 쿼리를 브라우저에 직접 입력할 수
있다. 수행 방법에 대한 자세한 내용은 [엘라스틱서치의 문서](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)를
참조한다.
또는, 키바나를 사용하여 클러스터의 로그를 볼 수도 있다(다시
[클러스터에서 실행되는 서비스에 접근하기 위한 지침](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)을 참고).
키바나 URL을 처음 방문하면 수집된 로그 보기를
구성하도록 요청하는 페이지가 표시된다. 시계열 값에
대한 옵션을 선택하고 `@timestamp` 를 선택한다. 다음 페이지에서
`Discover` 탭을 선택하면 수집된 로그를 볼 수 있다.
로그를 정기적으로 새로 고치려면 새로 고침 간격을 5초로
설정할 수 있다.
키바나 뷰어에서 수집된 로그의 일반적인 보기는 다음과 같다.
![키바나 로그](/images/docs/kibana-logs.png)
{{% /capture %}}
{{% capture whatsnext %}}
키바나는 로그를 탐색하기 위한 모든 종류의 강력한 옵션을 제공한다! 이를 파헤치는 방법에 대한
아이디어는 [키바나의 문서](https://www.elastic.co/guide/en/kibana/current/discover.html)를 확인한다.
{{% /capture %}}
content/ko/docs/tasks/manage-gpus/scheduling-gpus.md
+219
View File
@@ -0,0 +1,219 @@
---
content_template: templates/concept
title: GPU 스케줄링
---
{{% capture overview %}}
{{< feature-state state="beta" for_k8s_version="1.10" >}}
쿠버네티스는 AMD 및 NVIDIA GPU(그래픽 프로세싱 유닛)를 노드들에 걸쳐 관리하기 위한 **실험적인**
지원을 포함한다.
이 페이지는 다른 쿠버네티스 버전 간에 걸쳐 사용자가 GPU들을 소비할 수 있는 방법과
현재의 제약 사항을 설명한다.
{{% /capture %}}
{{% capture body %}}
## 디바이스 플러그인 사용하기
쿠버네티스는 {{< glossary_tooltip text="디바이스 플러그인" term_id="device-plugin" >}}을 구현하여
파드가 GPU와 같이 특별한 하드웨어 기능에 접근할 수 있게 한다.
관리자는 해당하는 하드웨어 벤더의 GPU 드라이버를 노드에
설치해야 하며, GPU 벤더가 제공하는 디바이스 플러그인을
실행해야 한다.
* [AMD](#amd-gpu-디바이스-플러그인-배치하기)
* [NVIDIA](#nvidia-gpu-디바이스-플러그인-배치하기)
위의 조건이 만족되면, 쿠버네티스는 `amd.com/gpu` 또는
`nvidia.com/gpu` 를 스케줄 가능한 리소스로써 노출시킨다.
사용자는 이 GPU들을 `cpu` 나 `memory` 를 요청하는 방식과 동일하게
`<vendor>.com/gpu` 를 요청함으로써 컨테이너를 통해 소비할 수 있다.
그러나 GPU를 사용할 때는 리소스 요구 사항을 명시하는 방식에 약간의
제약이 있다.
- GPU는 `limits` 섹션에서만 명시되는 것을 가정한다. 그 의미는 다음과 같다.
* 쿠버네티스는 limits를 requests의 기본 값으로 사용하게 되므로
사용자는 GPU `limits` 를 명시할 때 `requests` 명시하지 않아도 된다.
* 사용자는 `limits` 과 `requests` 를 모두 명시할 수 있지만, 두 값은
동일해야 한다.
* 사용자는 `limits` 명시 없이는 GPU `requests` 를 명시할 수 없다.
- 컨테이너들(그리고 파드들)은 GPU를 공유하지 않는다. GPU에 대한 초과 할당(overcommitting)은 제공되지 않는다.
- 각 컨테이너는 하나 이상의 GPU를 요청할 수 있다. GPU의 일부(fraction)를 요청하는 것은
불가능하다.
다음은 한 예제를 보여준다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cuda-vector-add
spec:
restartPolicy: OnFailure
containers:
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1 # GPU 1개 요청하기
```
### AMD GPU 디바이스 플러그인 배치하기
[공식 AMD GPU 디바이스 플러그인](https://github.com/RadeonOpenCompute/k8s-device-plugin)에는
다음의 요구 사항이 있다.
- 쿠버네티스 노드들에는 AMD GPU 리눅스 드라이버가 미리 설치되어 있어야 한다.
클러스터가 실행 중이고 위의 요구 사항이 만족된 후, AMD 디바이스 플러그인을 배치하기 위해서는
아래 명령어를 실행한다.
```shell
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/v1.10/k8s-ds-amdgpu-dp.yaml
```
[RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)에 이슈를 로깅하여
해당 서드 파티 디바이스 플러그인에 대한 이슈를 리포트할 수 있다.
### NVIDIA GPU 디바이스 플러그인 배치하기
현재는 NVIDIA GPU에 대한 두 개의 디바이스 플러그인 구현체가 있다.
#### 공식 NVIDIA GPU 디바이스 플러그인
[공식 NVIDIA GPU 디바이스 플러그인](https://github.com/NVIDIA/k8s-device-plugin)은
다음의 요구 사항을 가진다.
- 쿠버네티스 노드에는 NVIDIA 드라이버가 미리 설치되어 있어야 한다.
- 쿠버네티스 노드에는 [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)이 미리 설치되어 있어야 한다.
- Kubelet은 자신의 컨테이너 런타임으로 도커를 사용해야 한다.
- 도커는 runc 대신 `nvidia-container-runtime` 이 [기본 런타임](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)으로
설정되어야 한다.
- NVIDIA 드라이버의 버전은 조건 ~= 361.93 을 만족해야 한다.
클러스터가 실행 중이고 위의 요구 사항이 만족된 후, NVIDIA 디바이스 플러그인을 배치하기 위해서는
아래 명령어를 실행한다.
```shell
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta4/nvidia-device-plugin.yml
```
[NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)에 이슈를 로깅하여
해당 서드 파티 디바이스 플러그인에 대한 이슈를 리포트할 수 있다.
#### GCE에서 사용되는 NVIDIA GPU 디바이스 플러그인
[GCE에서 사용되는 NVIDIA GPU 디바이스 플러그인](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)은
nvidia-docker의 사용이 필수가 아니며 컨테이너 런타임 인터페이스(CRI)에
호환되는 다른 컨테이너 런타임을 사용할 수 있다. 해당 사항은
[컨테이너에 최적화된 OS](https://cloud.google.com/container-optimized-os/)에서 테스트되었고,
우분투 1.9 이후 버전에 대한 실험적인 코드를 가지고 있다.
사용자는 다음 커맨드를 사용하여 NVIDIA 드라이버와 디바이스 플러그인을 설치할 수 있다.
```shell
# 컨테이너에 최적회된 OS에 NVIDIA 드라이버 설치:
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml
# 우분투에 NVIDIA 드라이버 설치(실험적):
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml
# 디바이스 플러그인 설치:
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.14/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
```
[GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators)에 이슈를 로깅하여
해당 서드 파티 디바이스 플러그인에 대한 이슈를 리포트할 수 있다.
Google은 GKE에서 NVIDIA GPU 사용에 대한 자체 [설명서](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)를 게재하고 있다.
## 다른 타입의 GPU들을 포함하는 클러스터
만약 클러스터의 노드들이 서로 다른 타입의 GPU를 가지고 있다면, 사용자는
파드를 적합한 노드에 스케줄 하기 위해서
[노드 레이블과 노드 셀렉터](/docs/tasks/configure-pod-container/assign-pods-nodes/)를 사용할 수 있다.
예를 들면,
```shell
# 노드가 가진 가속기 타입에 따라 레이블을 단다.
kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
```
## 노드 레이블링 자동화 {#node-labeller}
만약 AMD GPU 디바이스를 사용하고 있다면,
[노드 레이블러](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller)를 배치할 수 있다.
노드 레이블러는 GPU 디바이스의 속성에 따라서 노드에 자동으로 레이블을 달아 주는
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}이다.
현재 이 컨트롤러는 다음의 속성에 대해 레이블을 추가할 수 있다.
* 디바이스 ID (-device-id)
* VRAM 크기 (-vram)
* SIMD 개수 (-simd-count)
* 계산 유닛 개수 (-cu-count)
* 펌웨어 및 기능 버전 (-firmware)
* GPU 계열, 두 개 문자 형태의 축약어 (-family)
* SI - Southern Islands
* CI - Sea Islands
* KV - Kaveri
* VI - Volcanic Islands
* CZ - Carrizo
* AI - Arctic Islands
* RV - Raven
```shell
kubectl describe node cluster-node-23
```
```
Name: cluster-node-23
Roles: <none>
Labels: beta.amd.com/gpu.cu-count.64=1
beta.amd.com/gpu.device-id.6860=1
beta.amd.com/gpu.family.AI=1
beta.amd.com/gpu.simd-count.256=1
beta.amd.com/gpu.vram.16G=1
beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/hostname=cluster-node-23
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
node.alpha.kubernetes.io/ttl: 0
…
```
노드 레이블러가 사용된 경우, GPU 타입을 파드 스펙에 명시할 수 있다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cuda-vector-add
spec:
restartPolicy: OnFailure
containers:
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100 # 또는 nvidia-tesla-k80 등.
```
이것은 파드가 사용자가 지정한 GPU 타입을 가진 노드에 스케줄 되도록
만든다.
{{% /capture %}}
content/ko/docs/tasks/network/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: "네트워크"
weight: 160
---
content/ko/docs/tasks/network/validate-dual-stack.md
+158
View File
@@ -0,0 +1,158 @@
---
min-kubernetes-server-version: v1.16
title: IPv4/IPv6 이중 스택 검증
content_template: templates/task
---
{{% capture overview %}}
이 문서는 IPv4/IPv6 이중 스택이 활성화된 쿠버네티스 클러스터들을 어떻게 검증하는지 설명한다.
{{% /capture %}}
{{% capture prerequisites %}}
* 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
* 이중 스택을 지원하는 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico)
* IPVS 모드로 구동되는 Kube-proxy
* [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터
{{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 어드레싱 검증
### 노드 어드레싱 검증
각각의 이중 스택 노드는 단일 IPv4 블록 및 단일 IPv6 블록을 할당받아야 한다. IPv4/IPv6 파드 주소 범위를 다음 커맨드를 실행하여 검증한다. 샘플 노드 이름을 클러스터 내 검증된 이중 스택 노드로 대체한다. 본 예제에서, 노드 이름은 `k8s-linuxpool1-34450317-0` 이다.
```shell
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}'
```
```
10.244.1.0/24
a00:100::/24
```
단일 IPv4 블록과 단일 IPv6 블록이 할당되어야 한다.
노드가 IPv4 및 IPv6 인터페이스를 가지고 있는지 검증한다. (노드 이름을 클러스터의 검증된 노드로 대체한다. 본 예제에서 노드 이름은 k8s-linuxpool1-34450317-0) 이다.
```shell
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s \n" .type .address}}{{end}}'
```
```
Hostname: k8s-linuxpool1-34450317-0
InternalIP: 10.240.0.5
InternalIP: 2001:1234:5678:9abc::5
```
### 파드 어드레싱 검증
파드가 IPv4 및 IPv6 주소를 할당받았는지 검증한다. (파드 이름을 클러스터에서 검증된 파드로 대체한다. 본 예제에서 파드 이름은 pod01 이다.)
```shell
kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s \n" .ip}}{{end}}'
```
```
10.244.1.4
a00:100::4
```
`status.podIPs` fieldPath를 통한 다운워드(downward) API로 파드 IP들을 검증할 수도 있다. 다음 스니펫은 컨테이너 내 `MY_POD_IPS` 라는 환경 변수를 통해 파드 IP들을 어떻게 노출시킬 수 있는지 보여준다.
```
env:
- name: MY_POD_IPS
valueFrom:
fieldRef:
fieldPath: status.podIPs
```
다음 커맨드는 컨테이너 내 `MY_POD_IPS` 환경 변수의 값을 출력한다. 해당 값은 파드의 IPv4 및 IPv6 주소를 나타내는 쉼표로 구분된 목록이다.
```shell
kubectl exec -it pod01 -- set | grep MY_POD_IPS
```
```
MY_POD_IPS=10.244.1.4,a00:100::4
```
파드의 IP 주소는 또한 컨테이너 내 `/etc/hosts` 에 적힐 것이다. 다음 커맨드는 이중 스택 파드의 `/etc/hosts` 에 cat을 실행시킨다. 출력 값을 통해 파드의 IPv4 및 IPv6 주소 모두 검증할 수 있다.
```shell
kubectl exec -it pod01 -- cat /etc/hosts
```
```
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.244.1.4 pod01
a00:100::4 pod01
```
## 서비스 검증
`ipFamily` 필드 세트 없이 다음 서비스를 생성한다. 필드가 구성되지 않았으면 서비스는 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 설정된 범위 내 첫 IP를 할당받는다.
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
해당 서비스의 YAML을 보면, 서비스의 `ipFamily` 필드가 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 첫 번째 설정된 범위의 주소 패밀리를 반영하도록 설정되어 있음을 확인할 수 있다.
```shell
kubectl get svc my-service -o yaml
```
```yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2019-09-03T20:45:13Z"
labels:
app: MyApp
name: my-service
namespace: default
resourceVersion: "485836"
selfLink: /api/v1/namespaces/default/services/my-service
uid: b6fa83ef-fe7e-47a3-96a1-ac212fa5b030
spec:
clusterIP: 10.0.29.179
ipFamily: IPv4
ports:
- port: 80
protocol: TCP
targetPort: 9376
selector:
app: MyApp
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
```
`ipFamily` 필드를 `IPv6`로 설정하여 다음의 서비스를 생성한다.
{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
서비스가 IPv6 주소 블록에서 클러스터 IP 주소를 할당받는 것을 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
```
kubectl get svc -l app=MyApp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service ClusterIP fe80:20d::d06b <none> 80/TCP 9s
```
### 이중 스택 로드 밸런싱 서비스 생성
만약 클라우드 제공자가 IPv6 기반 외부 로드 밸런서 구성을 지원한다면 `ipFamily` 필드를 `IPv6`로, `type` 필드를 `LoadBalancer` 로 설정하여 다음의 서비스를 생성한다.
{{< codenew file="service/networking/dual-stack-ipv6-lb-svc.yaml" >}}
서비스가 IPv6 주소 블록에서 `CLUSTER-IP` 주소 및 `EXTERNAL-IP` 주소를 할당받는지 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
```
kubectl get svc -l app=MyApp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:31868/TCP 30s
```
{{% /capture %}}
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+1 -2
View File
@@ -199,8 +199,7 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
## 롤링 업데이트 중 오토스케일링
현재 쿠버네티스에서는 레플리케이션 컨트롤러를 직접 관리하거나,
기본 레플리카 셋를 관리하는 디플로이먼트 오브젝트를 사용하여 [롤링 업데이트](/docs/tasks/run-application/rolling-update-replication-controller/)를 수행 할 수 있다.
현재 쿠버네티스에서는 기본 레플리카 셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카 셋의 크기를 결정한다.