Merge pull request #40209 from bconfiden2/0322-outdated

[ko] Update outdated files in dev-1.26-ko.1 (M165-M173,M189-M196)
pull/41281/head
Kubernetes Prow Robot 2023-05-22 20:02:20 -07:00 committed by GitHub
commit 23d88ac47b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
16 changed files with 203 additions and 146 deletions

View File

@ -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

View File

@ -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
@ -285,6 +291,8 @@ Events:
14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-p17e0
```
모든 파드가 성공했다. 야호.

View File

@ -171,6 +171,7 @@ gcloud docker -- push gcr.io/<project>/job-wq-2
따라서, 잡 완료 횟수를 1로 설정했다. 잡 컨트롤러는 다른 파드도 완료될 때까지
기다린다.
## 잡 실행
이제 잡을 실행한다.
@ -207,9 +208,18 @@ 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
@ -217,7 +227,7 @@ Working on date
Working on lemon
```
시다시피, 사용자의 파드 중 하나가 여러 작업 단위에서 작업했다.
다시피, 파드 중 하나가 여러 작업 항목을 처리했다.
<!-- discussion -->

View File

@ -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
@ -182,4 +189,4 @@ kubectl logs indexed-job-fdhq5 # 잡에 속한 파드의 이름에 맞춰 변경
```
xuq
```
```

View File

@ -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
@ -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들을 포함하는 클러스터
@ -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 디바이스를 사용하고 있다면,
@ -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 타입을 파드 스펙에 명시할 수 있다.
@ -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 타입을 가진 노드에 파드가 스케줄 되도록
만든다.

View File

@ -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) 실행되는
@ -139,7 +162,7 @@ CPU를 스케일할 때, 파드가 아직 Ready되지 않았거나(여전히
기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지
않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로
않았고 시작 이후 짧은 시간 내에 파드가 준비 상태로
전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다.
이 값은 `--horizontal-pod-autoscaler-initial-readiness-delay` 플래그로 설정되며, 기본값은 30초
이다. 일단 파드가 준비되고 시작된 후 구성 가능한 시간 이내이면,

View File

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

View File

@ -120,13 +120,13 @@ card:
2. 구글 클라우드 공개 사이닝 키를 다운로드한다.
```shell
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
```
3. 쿠버네티스 `apt` 리포지터리를 추가한다.
```shell
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
```
4. 새 리포지터리의 `apt` 패키지 색인을 업데이트하고 kubectl을 설치한다.
@ -135,6 +135,10 @@ card:
sudo apt-get update
sudo apt-get install -y kubectl
```
{{< note >}}
Debian 12 또는 Ubuntu 22.04 이전 릴리스에서는 기본적으로 `/etc/apt/keyrings` 파일이 존재하지 않는다.
필요할 경우, 읽기 권한은 모두에게 부여되지만 쓰기 권한은 관리자만 갖도록 해당 디렉토리를 생성한다.
{{< /note >}}
{{% /tab %}}
@ -146,7 +150,7 @@ name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
sudo yum install -y kubectl
```

View File

@ -20,7 +20,7 @@ card:
다음과 같은 방법으로 윈도우에 kubectl을 설치할 수 있다.
- [윈도우에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-windows)
- [Chocolatey 또는 Scoop을 사용하여 윈도우에 설치](#install-on-windows-using-chocolatey-or-scoop)
- [Chocolatey, Scoop, 또는 winget을 사용하여 윈도우에 설치](#install-nonstandard-package-tools)
### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-windows}
@ -30,7 +30,7 @@ card:
또는 `curl` 을 설치한 경우, 다음 명령을 사용한다.
```powershell
curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe"
curl.exe -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe"
```
{{< note >}}
@ -42,7 +42,11 @@ card:
`kubectl` 체크섬 파일을 다운로드한다.
```powershell
<<<<<<< HEAD
curl -LO "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe.sha256"
=======
curl.exe -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256"
>>>>>>> e54c13c4a4 ([ko] Update outdated files in dev-1.26-ko.1 (M165-M173,M189-M196))
```
`kubectl` 바이너리를 체크섬 파일을 통해 검증한다.
@ -78,9 +82,9 @@ card:
도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 `PATH` 항목 앞에 `PATH` 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다.
{{< /note >}}
### Chocolatey 또는 Scoop을 사용하여 윈도우에 설치 {#install-on-windows-using-chocolatey-or-scoop}
### Chocolatey, Scoop, 또는 winget을 사용하여 윈도우에 설치 {#install-nonstandard-package-tools}
1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다.
1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자, [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램, [winget](https://learn.microsoft.com/en-us/windows/package-manager/winget/) 패키지 관리자를 사용할 수 있다.
{{< tabs name="kubectl_win_install" >}}
{{% tab name="choco" %}}
@ -93,9 +97,13 @@ card:
scoop install kubectl
```
{{% /tab %}}
{{% tab name="winget" %}}
```powershell
winget install -e --id Kubernetes.kubectl
```
{{% /tab %}}
{{< /tabs >}}
1. 설치한 버전이 최신 버전인지 확인한다.
```powershell
@ -152,7 +160,11 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제
1. 다음 명령으로 최신 릴리스를 다운로드한다.
```powershell
<<<<<<< HEAD
curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl-convert.exe"
=======
curl.exe -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe"
>>>>>>> e54c13c4a4 ([ko] Update outdated files in dev-1.26-ko.1 (M165-M173,M189-M196))
```
1. 바이너리를 검증한다. (선택 사항)
@ -160,7 +172,11 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제
`kubectl-convert` 체크섬(checksum) 파일을 다운로드한다.
```powershell
<<<<<<< HEAD
curl -LO "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl-convert.exe.sha256"
=======
curl.exe -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256"
>>>>>>> e54c13c4a4 ([ko] Update outdated files in dev-1.26-ko.1 (M165-M173,M189-M196))
```
`kubectl-convert` 바이너리를 체크섬 파일을 통해 검증한다.

View File

@ -152,7 +152,7 @@ container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>
kubectl get events | grep Created
```
```
22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-node-pool-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]apparmor=k8s-apparmor-example-deny-write]
22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-node-pool-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
```
컨테이너의 루트 프로세스가 올바른 프로파일로 실행되는지는 proc attr을 확인하여 직접 검증할 수 있다.

View File

@ -187,7 +187,7 @@ weight: 10
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1beta1
apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
enforce: "baseline"
@ -203,6 +203,13 @@ weight: 10
EOF
```
{{< note >}}
`pod-security.admission.config.k8s.io/v1` 설정은 쿠버네티스 v1.25 이상을 필요로 한다.
쿠버네티스 v1.23 과 v1.24의 경우, [v1beta1](https://v1-24.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)을 사용한다.
쿠버네티스 v1.22의 경우, [v1alpha1](https://v1-22.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)을 사용한다.
{{< /note >}}
1. API 서버가 클러스터 생성 과정에서 이 파일을 처리할 수 있도록 구성한다.
```

View File

@ -155,7 +155,7 @@ namespace/example created
## 정리하기
`kind delete cluster -name psa-ns-level` 명령을 실행하여 생성했던 클러스터를 삭제한다.
`kind delete cluster --name psa-ns-level` 명령을 실행하여 생성했던 클러스터를 삭제한다.
## {{% heading "whatsnext" %}}

View File

@ -2,6 +2,7 @@
title: 소스 IP 주소 이용하기
content_type: tutorial
min-kubernetes-server-version: v1.5
weight: 40
---
<!-- overview -->
@ -415,5 +416,5 @@ kubectl delete deployment source-ip-app
## {{% heading "whatsnext" %}}
* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 더 자세히 본다.
* [서비스를 통한 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)를 더 자세히 본다.
* [외부 로드밸런서 생성](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/) 방법을 본다.

View File

@ -131,6 +131,11 @@ web-1 1/1 Running 0 18s
_Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고)
_Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에는 시작되지 않음에 주의한다.
{{< note >}}
스테이트풀셋에서 각 파드에 할당되는 정수값의 순서를 설정하려면,
[시작 순서](/ko/docs/concepts/workloads/controllers/statefulset/#시작-순서)를 확인한다.
{{< /note >}}
## 스테이트풀셋 안에 파드
스테이트풀셋 안에 파드는 고유한 순번과 동일한 네트워크 신원을 가진다.
@ -1202,12 +1207,54 @@ web-3 0/1 Terminating 0 9m
kubectl delete svc nginx
```
이 튜토리얼에서 퍼시스턴트볼륨으로 사용했던 영구 스토리지를 삭제한다.
```shell
kubectl get pvc
```
```
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
www-web-0 Bound pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO standard 25m
www-web-1 Bound pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO standard 24m
www-web-2 Bound pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO standard 15m
www-web-3 Bound pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO standard 15m
www-web-4 Bound pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO standard 14m
```
```shell
kubectl get pv
```
```
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO Delete Bound default/www-web-3 standard 15m
pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO Delete Bound default/www-web-0 standard 25m
pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO Delete Bound default/www-web-4 standard 14m
pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO Delete Bound default/www-web-1 standard 24m
pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO Delete Bound default/www-web-2 standard 15m
```
```shell
kubectl delete pvc www-web-0 www-web-1 www-web-2 www-web-3 www-web-4
```
```
persistentvolumeclaim "www-web-0" deleted
persistentvolumeclaim "www-web-1" deleted
persistentvolumeclaim "www-web-2" deleted
persistentvolumeclaim "www-web-3" deleted
persistentvolumeclaim "www-web-4" deleted
```
```shell
kubectl get pvc
```
```
No resources found in default namespace.
```
{{< note >}}
이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한
퍼시스턴트 스토리지 미디어도 삭제해야 한다.
모든 스토리지를 반환하도록 환경, 스토리지 설정과
프로비저닝 방법에 따른 단계를 따르자.
{{< /note >}}
{{< /note >}}

View File

@ -174,5 +174,5 @@ kubectl delete deployment hello-world
## {{% heading "whatsnext" %}}
[애플리케이션과 서비스 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해
[애플리케이션과 서비스 연결하기](/ko/docs/tutorials/services/connect-applications-service/)에 대해
더 배워 본다.

View File

@ -418,5 +418,5 @@ Google Compute Engine 또는 Google Kubernetes Engine
* [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료
* [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기
* [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기
* [애플리케이션과 서비스 연결하기](/ko/docs/tutorials/services/connect-applications-service/)에 대해 더 알아보기
* [자원 관리](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)에 대해 더 알아보기