Skip to content

Commit

Permalink
[ko] Update outdated files in dev-1.26-ko.1 (M165-M173,M189-M196)
Browse files Browse the repository at this point in the history
  • Loading branch information
bconfiden2 committed May 23, 2023
1 parent 56e300c commit 2c7b7ef
Show file tree
Hide file tree
Showing 16 changed files with 203 additions and 146 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ konnectivity-server에 대한 인증서 및 kubeconfig를 생성하거나 얻는
클러스터 CA 인증서 `/etc/kubernetes/pki/ca.crt`를 사용하여 X.509 인증서를 발급할 수 있다.

```bash
openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr
openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key
openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256
SERVER=$(kubectl config view -o jsonpath='{.clusters..server}')
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -244,7 +244,13 @@ gcloud docker -- push gcr.io/<project>/job-wq-1
kubectl apply -f ./job.yaml
```

이제 조금 기다린 다음, 잡을 확인한다.
아래와 같이 시간 제한(timeout)을 설정하고, 잡이 성공할 때까지 기다린다.
```shell
# 조건명은 대소문자를 구분하지 않는다.
kubectl wait --for=condition=complete --timeout=300s job/job-wq-1
```

잡을 확인한다.

```shell
kubectl describe jobs/job-wq-1
Expand Down Expand Up @@ -285,6 +291,8 @@ Events:
14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-p17e0
```



모든 파드가 성공했다. 야호.


Expand Down
12 changes: 11 additions & 1 deletion content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md
Original file line number Diff line number Diff line change
Expand Up @@ -171,6 +171,7 @@ gcloud docker -- push gcr.io/<project>/job-wq-2
따라서, 잡 완료 횟수를 1로 설정했다. 잡 컨트롤러는 다른 파드도 완료될 때까지
기다린다.


## 잡 실행

이제 잡을 실행한다.
Expand Down Expand Up @@ -207,17 +208,26 @@ Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
33s 33s 1 {job-controller } Normal SuccessfulCreate Created pod: job-wq-2-lglf8
```

아래와 같이 시간 제한(timeout)을 설정하고, 잡이 성공할 때까지 기다린다.
```shell
# 조건명은 대소문자를 구분하지 않는다.
kubectl wait --for=condition=complete --timeout=300s job/job-wq-2
```

```shell
kubectl logs pods/job-wq-2-7r7b2
```
```
Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f
Initial queue state: empty=False
Working on banana
Working on date
Working on lemon
```

보시다시피, 사용자의 파드 중 하나가 여러 작업 단위에서 작업했다.
보다시피, 파드 중 하나가 여러 작업 항목을 처리했다.

<!-- discussion -->

Expand Down
11 changes: 9 additions & 2 deletions content/ko/docs/tasks/job/indexed-parallel-processing-static.md
Original file line number Diff line number Diff line change
Expand Up @@ -107,7 +107,14 @@ kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml

`.spec.parallelism``.spec.completions`보다 작기 때문에, 컨트롤 플레인은 추가로 파드를 시작하기 전 최초 생성된 파드 중 일부가 완료되기를 기다린다.

잡을 생성했다면, 잠시 기다린 후 진행 상황을 확인한다.
아래와 ��이 시간 제한(timeout)을 설정하고, 잡이 성공할 때까지 기다린다.
```shell
# 조건명은 대소문자를 구분하지 않는다.
kubectl wait --for=condition=complete --timeout=300s job/indexed-job
```

잡의 상세 설명을 출력하여 성공적으로 수행되었는지 확인한다.


```shell
kubectl describe jobs/indexed-job
Expand Down Expand Up @@ -182,4 +189,4 @@ kubectl logs indexed-job-fdhq5 # 잡에 속한 파드의 이름에 맞춰 변경

```
xuq
```
```
174 changes: 54 additions & 120 deletions content/ko/docs/tasks/manage-gpus/scheduling-gpus.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,50 +8,46 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성

<!-- overview -->

{{< feature-state state="beta" for_k8s_version="v1.10" >}}

쿠버네티스는 AMD 및 NVIDIA GPU(그래픽 프로세��� 유닛)를 노드들에 걸쳐 관리하기 위한 **실험적인**
지원을 포함한다.

이 페이지는 여러 쿠버네티스 버전에서 사용자가 GPU를 활용할 수 있는 방법과
현재의 제약 사항을 설명한다.

{{< feature-state state="stable" for_k8s_version="v1.26" >}}

쿠버네티스는 {{< glossary_tooltip text="디바이스 플러그인" term_id="device-plugin" >}}을 사용하여
AMD 및 NVIDIA GPU(그래픽 프로세싱 유닛)를 여러 노드들에 걸쳐 관리하기 위한
**안정적인** 지원을 포함한다.

이 페이지는 사용자가 GPU를 활용할 수 있는 방법과,
몇 가지 제한 사항에 대하여 설명한다.

<!-- body -->

## 디바이스 플러그인 사용하기

쿠버네티스는 {{< glossary_tooltip text="디바이스 플러그인" term_id="device-plugin" >}}을 구현하여
파드가 GPU와 같이 특별한 하드웨어 기능에 접근할 수 있게 한다.
쿠버네티스는 디바이스 플러그인을 구현하여 파드가 GPU와 같이 특별한 하드웨어 기능에 접근할 수 있게 한다.

{{% thirdparty-content %}}

관리자는 해당하는 하드웨어 벤더의 GPU 드라이버를 노드에
설치해야 하며, GPU 벤더가 제공하는 디바이스 플러그인을
실행해야 한다.
실행해야 한다. 다음은 몇몇 벤더의 지침에 대한 웹페이지이다.

* [AMD](#amd-gpu-디바이스-플러그인-배치하기)
* [NVIDIA](#nvidia-gpu-디바이스-플러그인-배치하기)
* [AMD](https://github.com/RadeonOpenCompute/k8s-device-plugin#deployment)
* [Intel](https://intel.github.io/intel-device-plugins-for-kubernetes/cmd/gpu_plugin/README.html)
* [NVIDIA](https://github.com/NVIDIA/k8s-device-plugin#quick-start)

위의 조건이 만족되면, 쿠버네티스는 `amd.com/gpu` 또는
`nvidia.com/gpu` 를 스케줄 가���한 리소스로써 노출시킨다.
플러그인을 한 번 설치하고 나면, 클러스터는 `amd.com/gpu` 또는 `nvidia.com/gpu`를 스케줄 가능한 리소스로써 노출시킨다.

사용자는 이 GPU들을 `cpu` `memory` 를 요청하는 방식과 동일하게
`<vendor>.com/gpu` 요청함으로써 컨테이너에서 활용할 수 있다.
그러나 GPU를 사용할 때는 리소스 요구 사항을 명시하는 방식에 약간의
제약이 있다.
사용자는 이 GPU들을 `cpu``memory`를 요청하는 방식과 동일하게
GPU 자원을 요청함으로써 컨테이너에서 활용할 수 있다.
그러나 리소스의 요구 사항을 명시하는 방식에
약간의 제약이 있다.

- GPU는 `limits` 섹션에서만 명시되는 것을 가정한다. 그 의미는 다음과 같다.
* 쿠버네티스는 limits를 requests의 기본 값으로 사용하게 되므로
사용자는 GPU `limits` 를 명시할 때 `requests` 명시하지 않아도 된다.
* 사용자는 `limits``requests` 를 모두 명시할 수 있지만, 두 값은
동일해야 한다.
* 사용자는 `limits` 명시 없이는 GPU `requests` 를 명시할 수 없다.
- 컨테이너들(그리고 파드들)은 GPU를 공유하지 않는다. GPU에 대한 초과 할당(overcommitting)은 제공되지 않는다.
- 각 컨테이너는 하나 이상의 GPU를 요청할 수 있다. GPU의 일부(fraction)를 요청하는 것은
불가능하다.
GPU는 `limits` 섹션에서만 명시되는 것을 가정한다. 그 의미는 다음과 같다.
* 쿠버네티스는 limits를 requests의 기본 값으로 사용하게 되므로
사용자는 GPU `limits` 를 명시할 때 `requests` 명시하지 않아도 된다.
* 사용자는 `limits``requests` 를 모두 명시할 수 있지만, 두 값은
동일해야 한다.
* 사용자는 `limits` 명시 없이는 GPU `requests` 를 명시할 수 없다.

다음은 한 예제를 보여준다.
다음은 GPU를 요청하는 파드에 대한 예제 매니페스트를 보여준다.

```yaml
apiVersion: v1
Expand All @@ -61,81 +57,12 @@ metadata:
spec:
restartPolicy: OnFailure
containers:
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "registry.k8s.io/cuda-vector-add:v0.1"
- name: example-vector-add
image: "registry.example/example-vector-add:v42"
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 드라이버의 버전은 조건 ~= 384.81을 만족해야 한다.

클러스터가 실행 중이고 위의 요구 사항이 만족된 후, 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-vendor.example/example-gpu: 1 # 1 GPU 요청
```

## 다른 타입의 GPU들을 포함하는 클러스터

Expand All @@ -147,10 +74,13 @@ Google은 GKE에서 NVIDIA GPU 사용에 대한 자체 [설명서](https://cloud

```shell
# 노드가 가진 가속기 타입에 따라 레이블을 단다.
kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
kubectl label nodes node1 accelerator=example-gpu-x100
kubectl label nodes node2 accelerator=other-gpu-k915
```

`accelerator` 레이블 키를 `accelerator`로 지정한 것은 그저 예시일 뿐이며,
선호하는 다른 레이블 키를 사용할 수 있다.

## 노드 레이블링 자동화 {#node-labeller}

만약 AMD GPU 디바이스를 사용하고 있다면,
Expand Down Expand Up @@ -179,19 +109,18 @@ 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
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
kubernetes.io/arch=amd64
kubernetes.io/os=linux
kubernetes.io/hostname=cluster-node-23
Annotations: node.alpha.kubernetes.io/ttl: 0
```

노드 레이블러가 사용된 경우, GPU 타입을 파드 스펙에 명시할 수 있다.
Expand All @@ -210,9 +139,14 @@ spec:
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100 # 또는 nvidia-tesla-k80 등.
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
– matchExpressions:
– key: beta.amd.com/gpu.family.AI # Arctic Islands GPU family
operator: Exist
```

이것은 파드가 사용자가 지정한 GPU 타입을 가진 노드에 스케줄 되도록
이것은 사용자가 지정한 GPU 타입을 가진 노드에 파드가 스케줄 되도록
만든다.
27 changes: 25 additions & 2 deletions content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,30 @@ Horizontal Pod Autoscaling을 활용하는

## HorizontalPodAutoscaler는 어떻게 작동하는가?

{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다" class="diagram-medium">}}
{{< mermaid >}}
graph BT

hpa[Horizontal Pod Autoscaler] --> scale[Scale]

subgraph rc[RC / Deployment]
scale
end

scale -.-> pod1[Pod 1]
scale -.-> pod2[Pod 2]
scale -.-> pod3[Pod N]

classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
class hpa hpa;
class rc rc;
class scale scale;
class pod1,pod2,pod3 pod
{{< /mermaid >}}

그림 1. HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다.

쿠버네티스는 Horizontal Pod Autoscaling을
간헐적으로(intermittently) 실행되는
Expand Down Expand Up @@ -139,7 +162,7 @@ CPU를 스케일할 때, 파드가 아직 Ready되지 않았거나(여전히
기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는
특정 CPU 메트릭을 나중��� 사용할지 말지 결정할 때, 파드가 준비되는
시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지
않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로
않았고 시작 이후 짧은 시간 내에 파드가 준비 상태로
전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다.
이 값은 `--horizontal-pod-autoscaler-initial-readiness-delay` 플래그로 설정되며, 기본값은 30초
이다. 일단 파드가 준비되고 시작된 후 구성 가능한 시간 이내이면,
Expand Down
4 changes: 2 additions & 2 deletions content/ko/docs/tasks/tools/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,8 +35,8 @@ kind를 시작하고 실행하기 위해 수행해야 하는 작업을 보여준
## minikube

`kind` 와 마찬가지로, [`minikube`](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는
도구이다. `minikube` 는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서
단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을
도구이다. `minikube` 는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서 올인원 방식 또는
복수 개의 노드로 쿠버네티스 클러스터를 실행하여, 쿠버네티스를 사용해보거나 일상적인 개발 작업을
수행할 수 있다.

도구 설치에 중점을 두고 있다면 공식 사이트에서의
Expand Down
Loading

0 comments on commit 2c7b7ef

Please sign in to comment.