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
+2
-2
@@ -31,7 +31,7 @@ min-kubernetes-server-version: v1.10
|
||||
1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
|
||||
```
|
||||
|
||||
성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
|
||||
@@ -84,7 +84,7 @@ min-kubernetes-server-version: v1.10
|
||||
2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
|
||||
```
|
||||
|
||||
성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.
|
||||
|
||||
@@ -30,7 +30,7 @@ content_type: task
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
많은 [예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)는 kubectl 사용에 대한 소개를
|
||||
많은 [예제](https://github.com/kubernetes/examples/tree/master/)는 kubectl 사용에 대한 소개를
|
||||
제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다.
|
||||
|
||||
### REST API에 직접 접근
|
||||
|
||||
@@ -23,7 +23,7 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한
|
||||
|
||||
## 소개
|
||||
|
||||
DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을
|
||||
DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/master/cluster/addons/README.md)을
|
||||
사용하여 자동으로 시작되는 쿠버네티스
|
||||
내장 서비스이다.
|
||||
|
||||
|
||||
@@ -157,10 +157,10 @@ Install-WindowsFeature -Name containers
|
||||
|
||||
#### wins, kubelet 및 kubeadm 설치
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
|
||||
```
|
||||
```PowerShell
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
|
||||
```
|
||||
|
||||
#### `kubeadm` 실행하여 노드에 조인
|
||||
|
||||
@@ -201,7 +201,7 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates
|
||||
#### wins, kubelet 및 kubeadm 설치
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
|
||||
```
|
||||
|
||||
|
||||
@@ -126,7 +126,17 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서
|
||||
|
||||
`kubeadm certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.
|
||||
|
||||
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
|
||||
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
|
||||
|
||||
명령을 실행한 후에는 컨트롤 플레인 파드를 재시작해야 한다.
|
||||
이는 현재 일부 구성 요소 및 인증서에 대해 인증서를 동적으로 다시 로드하는 것이 지원되지 않기 때문이다.
|
||||
[스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)는 API 서버가 아닌 로컬 kubelet에서 관리되므로
|
||||
kubectl을 사용하여 삭제 및 재시작할 수 없다.
|
||||
스태틱 파드를 다시 시작하려면 `/etc/kubernetes/manifests/`에서 매니페스트 파일을 일시적으로 제거하고
|
||||
20초를 기다리면 된다 ([KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/)의 `fileCheckFrequency` 값을 참고한다).
|
||||
파드가 매니페스트 디렉터리에 더 이상 없는 경우 kubelet은 파드를 종료한다.
|
||||
그런 다음 파일을 다시 이동할 수 있으며 또 다른 `fileCheckFrequency` 기간이 지나면,
|
||||
kubelet은 파드를 생성하고 구성 요소에 대한 인증서 갱신을 완료할 수 있다.
|
||||
|
||||
{{< warning >}}
|
||||
HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 이 명령을 실행해야 한다.
|
||||
@@ -161,10 +171,10 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서
|
||||
|
||||
빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다.
|
||||
|
||||
새 클러스터를 생성하는 경우, kubeadm [구성 파일](/docs/reference/config-api/kubeadm-config.v1beta2/)을 사용할 수 있다.
|
||||
새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)을 사용할 수 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
@@ -223,7 +233,7 @@ TLS로 보안되지 않음을 의미한다.
|
||||
다음의 최소 구성을 `kubeadm init` 에 전달해야 한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
---
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
|
||||
+39
-24
@@ -22,44 +22,59 @@ weight: 20
|
||||
|
||||
실리움에 쉽게 친숙해지기 위해
|
||||
Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
|
||||
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
|
||||
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)를 따라 해볼 수 있다.
|
||||
|
||||
Minikube를 시작하려면 최소 버전으로 >= v1.3.1 이 필요하고,
|
||||
Minikube를 시작하려면 최소 버전으로 >= v1.5.2 이 필요하고,
|
||||
다음의 실행 파라미터로 실행한다.
|
||||
|
||||
```shell
|
||||
minikube version
|
||||
```
|
||||
```
|
||||
minikube version: v1.3.1
|
||||
minikube version: v1.5.2
|
||||
```
|
||||
|
||||
```shell
|
||||
minikube start --network-plugin=cni --memory=4096
|
||||
minikube start --network-plugin=cni
|
||||
```
|
||||
|
||||
BPF 파일시스템을 마운트한다
|
||||
minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다.
|
||||
실리움은 클러스터 구성을 자동으로 감지하고
|
||||
성공적인 설치를 위해 적절한 구성 요소를 설치한다.
|
||||
|
||||
```shell
|
||||
minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
|
||||
curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
|
||||
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
|
||||
rm cilium-linux-amd64.tar.gz
|
||||
cilium install
|
||||
```
|
||||
|
||||
Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함하는 필요한 구성을
|
||||
간단한 ``올인원`` YAML 파일로 배포할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
|
||||
```
|
||||
```
|
||||
configmap/cilium-config created
|
||||
serviceaccount/cilium created
|
||||
serviceaccount/cilium-operator created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium-operator created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
|
||||
daemonset.apps/cilium create
|
||||
deployment.apps/cilium-operator created
|
||||
🔮 Auto-detected Kubernetes kind: minikube
|
||||
✨ Running "minikube" validation checks
|
||||
✅ Detected minikube version "1.20.0"
|
||||
ℹ️ Cilium version not set, using default version "v1.10.0"
|
||||
🔮 Auto-detected cluster name: minikube
|
||||
🔮 Auto-detected IPAM mode: cluster-pool
|
||||
🔮 Auto-detected datapath mode: tunnel
|
||||
🔑 Generating CA...
|
||||
2021/05/27 02:54:44 [INFO] generate received request
|
||||
2021/05/27 02:54:44 [INFO] received CSR
|
||||
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
|
||||
2021/05/27 02:54:44 [INFO] encoded CSR
|
||||
2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
|
||||
🔑 Generating certificates for Hubble...
|
||||
2021/05/27 02:54:44 [INFO] generate received request
|
||||
2021/05/27 02:54:44 [INFO] received CSR
|
||||
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
|
||||
2021/05/27 02:54:44 [INFO] encoded CSR
|
||||
2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
|
||||
🚀 Creating Service accounts...
|
||||
🚀 Creating Cluster roles...
|
||||
🚀 Creating ConfigMap...
|
||||
🚀 Creating Agent DaemonSet...
|
||||
🚀 Creating Operator Deployment...
|
||||
⌛ Waiting for Cilium to be installed...
|
||||
```
|
||||
|
||||
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
|
||||
@@ -82,14 +97,14 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, H
|
||||
파드의 목록을 보려면 다음을 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
kubectl get pods --namespace=kube-system -l k8s-app=cilium
|
||||
```
|
||||
|
||||
다음과 유사한 파드의 목록을 볼 것이다.
|
||||
|
||||
```console
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-6rxbd 1/1 Running 0 1m
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-kkdhz 1/1 Running 0 3m23s
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
@@ -67,7 +67,7 @@ kubectl create secret generic db-user-pass \
|
||||
다음 커맨드를 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic dev-db-secret \
|
||||
kubectl create secret generic db-user-pass \
|
||||
--from-literal=username=devuser \
|
||||
--from-literal=password='S!B\*d$zDsb='
|
||||
```
|
||||
|
||||
@@ -0,0 +1,340 @@
|
||||
---
|
||||
|
||||
|
||||
|
||||
title: 동작 중인 파드 디버그
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 노드에서 동작 중인(혹은 크래시된) 파드를 디버그하는 방법에 대해 설명한다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* 여러분의 {{< glossary_tooltip text="파드" term_id="pod" >}}는 이미 스케줄링 되어
|
||||
동작하고 있을 것이다. 만약 파드가 아직 동작중이지 않다면, [애플리케이션
|
||||
트러블슈팅](/docs/tasks/debug-application-cluster/debug-application/)을 참고한다.
|
||||
* 일부 고급 디버깅 과정에서는 해당 파드가 어떤 노드에서 동작하고 있는지
|
||||
알아야 하고, 해당 노드에서 쉘 명령어를 실행시킬 수 있어야 한다.
|
||||
`kubectl`을 사용하는 일반적인 디버깅 과정에서는 이러한 접근 권한이 필요하지 않다.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 파드의 로그 확인하기 {#examine-pod-logs}
|
||||
|
||||
먼저, 확인하고자 하는 컨테이너의 로그를 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl logs ${POD_NAME} ${CONTAINER_NAME}
|
||||
```
|
||||
|
||||
만약 컨테이너가 이전에 크래시 되었다면, 다음의 명령을 통해 컨테이너의 크래시 로그를 살펴볼 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
|
||||
```
|
||||
|
||||
## exec를 통해 컨테이너 디버깅하기 {#container-exec}
|
||||
|
||||
만약 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
|
||||
디버깅 도구가 포함되어 있다면, `kubectl exec`을 통해 특정 컨테이너에서 해당 명령들을
|
||||
실행할 수 있다. (리눅스나 윈도우 OS를 기반으로 만들어진 이미지에는 대부분 디버깅 도구를 포함하고
|
||||
있다.)
|
||||
|
||||
```shell
|
||||
kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`-c ${CONTAINER_NAME}` 인자는 선택적이다. 만약 하나의 컨테이너만 포함된 파드라면 해당 옵션을 생략할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
예를 들어, 동작 중인 카산드라 파드의 로그를 살펴보기 위해서는 다음과 같은 명령을 실행할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl exec cassandra -- cat /var/log/cassandra/system.log
|
||||
```
|
||||
|
||||
`kubectl exec`에 `-i`와 `-t` 옵션을 사용해서 터미널에서 접근할 수 있는 쉘을 실행시킬 수도 있다.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl exec -it cassandra -- sh
|
||||
```
|
||||
|
||||
더욱 상세한 내용은 다음 [동작중인 컨테이너의 쉘에 접근하기](
|
||||
/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라.
|
||||
|
||||
## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container}
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
|
||||
|
||||
컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼
|
||||
컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아
|
||||
`kubectl exec`가 충분하지 않을 경우에는
|
||||
{{< glossary_tooltip text="임시(Ephemeral) 컨테이너" term_id="ephemeral-container" >}}를 사용하는 것이
|
||||
인터랙티브한 트러블슈팅에 유용하다. `kubectl` `v1.18`
|
||||
버전부터는 임시 컨테이너를 생성할 수 있는 알파 단계의
|
||||
명령어가 있다.
|
||||
|
||||
### 임시 컨테이너를 사용한 디버깅 예시 {#ephemeral-container-example}
|
||||
|
||||
{{< note >}}
|
||||
이 섹션에서 소개하는 예시를 사용하기 위해서는
|
||||
여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
|
||||
활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
`kubectl debug` 명령어를 사용해서 동작 중인 파드에 임시 컨테이너를 추가할 수 있다.
|
||||
먼저, 다음과 같이 파드를 추가한다.
|
||||
|
||||
```shell
|
||||
kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
|
||||
```
|
||||
|
||||
이 섹션의 예시에서는 디버깅 도구가 포함되지 않은 이미지의 사례를 보여드리기 위해
|
||||
`pause` 컨테이너 이미지를 사용했는데, 이 대신 어떠한 이미지를 사용해도
|
||||
될 것이다.
|
||||
|
||||
만약 `kubectl exec`을 통해 쉘을 생성하려 한다면 다음과 같은 에러를
|
||||
확인할 수 있을 텐데, 그 이유는 이 이미지에 쉘이 존재하지 않기 때문이다.
|
||||
|
||||
```shell
|
||||
kubectl exec -it ephemeral-demo -- sh
|
||||
```
|
||||
|
||||
```
|
||||
OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown
|
||||
```
|
||||
|
||||
이 명령어 대신 `kubectl debug`을 사용해서 디버깅 컨테이너를 생성할 수 있다.
|
||||
만약 `-i`/`--interactive` 인자를 사용한다면, `kubectl`은 임시
|
||||
컨테이너의 콘솔에 자동으로 연결할 것이다.
|
||||
|
||||
```shell
|
||||
kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
|
||||
```
|
||||
|
||||
```
|
||||
Defaulting debug container name to debugger-8xzrl.
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
/ #
|
||||
```
|
||||
|
||||
이 명령어는 새로운 busybox 컨테이너를 추가하고 해당 컨테이너로 연결한다. `--target`
|
||||
파라미터를 사용하면 다른 컨테이너의 프로세스 네임스페이스를 대상으로 하게 된다. 여기서는
|
||||
이 옵션이 꼭 필요한데, `kubectl run`이 생성하는 파드에 대해
|
||||
[프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
|
||||
활성화하지 않기 때문이다.
|
||||
|
||||
{{< note >}}
|
||||
`--target` 파라미터는 사용 중인 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}에서
|
||||
지원해야지만 사용할 수 있다. 만일 지원되지 않는다면,
|
||||
임시 컨테이너가 시작되지 않을 수 있거나 독립적인 프로세스
|
||||
네임스페이스를 가지고 시작될 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
`kubectl describe` 명령을 사용하면 새롭게 생성된 임시 컨테이너의 상태를 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl describe pod ephemeral-demo
|
||||
```
|
||||
|
||||
```
|
||||
...
|
||||
Ephemeral Containers:
|
||||
debugger-8xzrl:
|
||||
Container ID: docker://b888f9adfd15bd5739fefaa39e1df4dd3c617b9902082b1cfdc29c4028ffb2eb
|
||||
Image: busybox
|
||||
Image ID: docker-pullable://busybox@sha256:1828edd60c5efd34b2bf5dd3282ec0cc04d47b2ff9caa0b6d4f07a21d1c08084
|
||||
Port: <none>
|
||||
Host Port: <none>
|
||||
State: Running
|
||||
Started: Wed, 12 Feb 2020 14:25:42 +0100
|
||||
Ready: False
|
||||
Restart Count: 0
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
...
|
||||
```
|
||||
|
||||
디버깅이 다 끝나면 `kubectl delete`을 통해 파드를 제거할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl delete pod ephemeral-demo
|
||||
```
|
||||
|
||||
## 파드의 복제본을 이용해서 디버깅하기
|
||||
|
||||
때때로 파드의 설정 옵션에 따라 특정 상황에서 트러블슈팅을 하기가 어려울 수 있다.
|
||||
예를 들어, 만일 여러분의 컨테이너 이미지가 쉘을 포함하고 있지 않거나, 여러분의
|
||||
애플리케이션이 컨테이너 시작에서 크래시가 발생한다면 `kubectl exec`을 이용해서
|
||||
컨테이너를 트러블슈팅할 수 없을 수 있다. 이러한 상황에서는 `kubectl debug`을 사용해서
|
||||
파드의 복제본을 디버깅을 위한 추가적인 설정 옵션과 함께 생성할 수 있다.
|
||||
|
||||
### 새 컨테이너와 함께 파드의 복제본 생성하기
|
||||
|
||||
만일 여러분의 애플리케이션이 동작은 하고 있지만 예상과는 다르게 동작하는 경우,
|
||||
파드의 복제본에 새로운 컨테이너를 추가함으로써 추가적인 트러블슈팅 도구들을
|
||||
파드에 함께 추가할 수 있다.
|
||||
|
||||
가령, 여러분의 애플리케이션 컨테이너 이미지는 `busybox`를 기반으로 하고 있는데
|
||||
여러분은 `busybox`에는 없는 디버깅 도구를 필요로 한다고 가정해 보자. 이러한
|
||||
시나리오는 `kubectl run` 명령을 통해 시뮬레이션 해볼 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
|
||||
```
|
||||
|
||||
다음의 명령을 실행시켜 디버깅을 위한 새로운 우분투 컨테이너와 함께 `myapp-debug`이란
|
||||
이름의 `myapp` 컨테이너 복제본을 생성할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl debug myapp -it --image=ubuntu --share-processes --copy-to=myapp-debug
|
||||
```
|
||||
|
||||
```
|
||||
Defaulting debug container name to debugger-w7xmf.
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
root@myapp-debug:/#
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
* 만일 여러분이 새로 생성되는 컨테이너의 이름을 `--container` 플래그와 함께 지정하지 않는다면,
|
||||
`kubectl debug`는 자동으로 새로운 컨테이너 이름을 생성한다.
|
||||
* `-i` 플래그를 사용하면 `kubectl debug` 명령이 새로운 컨테이너에 기본적으로 연결되게 된다.
|
||||
이러한 동작은 `--attach=false`을 지정하여 방지할 수 있다. 만일 여러분의 세션이
|
||||
연결이 끊어진다면 `kubectl attach`를 사용해서 다시 연결할 수 있다.
|
||||
* `--share-processes` 옵션은 이 파드에 있는 컨테이너가 해당 파드에 속한 다른 컨테이너의
|
||||
프로세스를 볼 수 있도록 한다. 이 옵션이 어떻게 동작하는지에 대해 더 알아보기 위해서는
|
||||
다음의 [파드의 컨테이너 간 프로세스 네임스페이스 공유](
|
||||
/docs/tasks/configure-pod-container/share-process-namespace/)를 참고하라.
|
||||
{{< /note >}}
|
||||
|
||||
사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
|
||||
|
||||
```shell
|
||||
kubectl delete pod myapp myapp-debug
|
||||
```
|
||||
|
||||
### 명령어를 변경하며 파드의 복제본 생성하기
|
||||
|
||||
때때로 컨테이너의 명령어를 변경하는 것이 유용한 경우가 있는데, 예를 들면 디버그 플래그를 추가하기
|
||||
위해서나 애플리케이션이 크래시 되는 경우이다.
|
||||
|
||||
다음의 `kubectl run` 명령을 통해 즉각적으로 크래시가 발생하는 애플리케이션의
|
||||
사례를 시뮬레이션해 볼 수 있다.
|
||||
|
||||
```
|
||||
kubectl run --image=busybox myapp -- false
|
||||
```
|
||||
|
||||
`kubectl describe pod myapp` 명령을 통해 이 컨테이너에 크래시가 발생하고 있음을 확인할 수 있다.
|
||||
|
||||
```
|
||||
Containers:
|
||||
myapp:
|
||||
Image: busybox
|
||||
...
|
||||
Args:
|
||||
false
|
||||
State: Waiting
|
||||
Reason: CrashLoopBackOff
|
||||
Last State: Terminated
|
||||
Reason: Error
|
||||
Exit Code: 1
|
||||
```
|
||||
|
||||
이러한 경우에 `kubectl debug`을 통해 명령어를 지정함으로써 해당 파드의
|
||||
복제본을 인터랙티브 쉘로 생성할 수 있다.
|
||||
|
||||
```
|
||||
kubectl debug myapp -it --copy-to=myapp-debug --container=myapp -- sh
|
||||
```
|
||||
|
||||
```
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
/ #
|
||||
```
|
||||
|
||||
이제 인터랙티브 쉘에 접근할 수 있으니 파일 시스템 경로를 확인하거나
|
||||
동작 중인 컨테이너의 명령어를 직접 확인하는 등의 작업이 가능하다.
|
||||
|
||||
{{< note >}}
|
||||
* 특정 컨테이너의 명령어를 변경하기 위해서는 `--container` 옵션을 통해 해당 컨테이너의
|
||||
이름을 지정해야만 한다. 이름을 지정하지 않는다면 `kubectl debug`은 이전에 지정한 명령어를
|
||||
그대로 사용해서 컨테이너를 생성할 것이다.
|
||||
* 기본적으로 `-i` 플래그는 `kubectl debug` 명령이 컨테이너에 바로 연결되도록 한다.
|
||||
이러한 동작을 방지하기 위해서는 `--attach=false` 옵션을 지정할 수 있다. 만약 여러분이 세션이
|
||||
종료된다면 `kubectl attach` 명령을 통해 다시 연결할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
사용이 모두 끝나면, 디버깅에 사용된 파드들을 잊지 말고 정리한다.
|
||||
|
||||
```shell
|
||||
kubectl delete pod myapp myapp-debug
|
||||
```
|
||||
|
||||
### 컨테이너 이미지를 변경하며 파드의 복제본 생성하기
|
||||
|
||||
특정한 경우에 여러분은 제대로 동작하지 않는 파드의 이미지를
|
||||
기존 프로덕션 컨테이너 이미지에서 디버깅 빌드나 추가적인 도구를 포함한
|
||||
이미지로 변경하고 싶을 수 있다.
|
||||
|
||||
이 사례를 보여주기 위해 `kubectl run` 명령을 통해 파드를 생성하였다.
|
||||
|
||||
```
|
||||
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
|
||||
```
|
||||
|
||||
여기서는 `kubectl debug` 명령을 통해 해당 컨테이너 이미지를 `ubuntu`로 변경하며
|
||||
복제본을 생성하였다.
|
||||
|
||||
```
|
||||
kubectl debug myapp --copy-to=myapp-debug --set-image=*=ubuntu
|
||||
```
|
||||
|
||||
`--set-image`의 문법은 `kubectl set image`와 동일하게 `container_name=image`
|
||||
형식의 문법을 사용한다. `*=ubuntu`라는 의미는 모든 컨테이너의 이미지를 `ubuntu`로
|
||||
변경하겠다는 의미이다.
|
||||
|
||||
사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
|
||||
|
||||
```shell
|
||||
kubectl delete pod myapp myapp-debug
|
||||
```
|
||||
|
||||
## 노드의 쉘을 사용해서 디버깅하기 {#node-shell-session}
|
||||
|
||||
만약 위의 어떠한 방법도 사용할 수 없다면, 파드가 현재 동작 중인 노드를 찾아
|
||||
호스트의 네임스페이스로 동작하는 특권 파드를 생성할 수 있다.
|
||||
다음 `kubectl debug` 명령을 통해 해당 노드에서 인터랙티브한 쉘을 생성할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl debug node/mynode -it --image=ubuntu
|
||||
```
|
||||
|
||||
```
|
||||
Creating debugging pod node-debugger-mynode-pdx84 with container debugger on node mynode.
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
root@ek8s:/#
|
||||
```
|
||||
|
||||
노드에서 디버깅 세션을 생성할 때 유의해야 할 점은 다음과 같다.
|
||||
|
||||
* `kubectl debug`는 노드의 이름에 기반해 새로운 파드의 이름을
|
||||
자동으로 생성한다.
|
||||
* 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다.
|
||||
* 노드의 루트 파일시스템은 `/host`에 마운트된다.
|
||||
|
||||
사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
|
||||
|
||||
```shell
|
||||
kubectl delete pod node-debugger-mynode-pdx84
|
||||
```
|
||||
+77
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: 종속 환경 변수 정의하기
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
본 페이지는 쿠버네티스 파드의 컨테이너를 위한 종속 환경 변수를
|
||||
정의하는 방법에 대해 설명한다.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 컨테이너를 위한 종속 환경 변수 정의하기
|
||||
|
||||
파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다.
|
||||
종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다.
|
||||
|
||||
이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다.
|
||||
|
||||
{{< codenew file="pods/inject/dependent-envars.yaml" >}}
|
||||
|
||||
1. YAML 구성 파일을 활용해 파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
|
||||
```
|
||||
```
|
||||
pod/dependent-envars-demo created
|
||||
```
|
||||
|
||||
2. 실행 중인 파드의 목록을 조회한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods dependent-envars-demo
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
dependent-envars-demo 1/1 Running 0 9s
|
||||
```
|
||||
|
||||
3. 파드 안에서 동작 중인 컨테이너의 로그를 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl logs pod/dependent-envars-demo
|
||||
```
|
||||
```
|
||||
|
||||
UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
|
||||
SERVICE_ADDRESS=https://172.17.0.1:80
|
||||
ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
|
||||
```
|
||||
|
||||
위에서 보듯이, `SERVICE_ADDRESS`는 올바른 종속성 참조, `UNCHANGED_REFERENCE`는 잘못된 종속성 참조를 정의했으며 `ESCAPED_REFERENCE`는 종속성 참조를 건너뛴다.
|
||||
|
||||
환경 변수가 참조될 때 해당 환경 변수가 미리 정의되어 있으면 `SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다.
|
||||
|
||||
환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다.
|
||||
일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다.
|
||||
|
||||
`$(VAR_NAME)` 구문은 이중 $로 이스케이프될 수 있다. (예: `$$(VAR_NAME)`)
|
||||
이스케이프된 참조는 참조된 변수가 정의되었는지 여부에 관계없이 해석을 수행하지 않는다.
|
||||
이는 위의 `ESCAPED_REFERENCE`를 통해 확인할 수 있다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
|
||||
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
|
||||
|
||||
@@ -0,0 +1,256 @@
|
||||
---
|
||||
title: 시크릿(Secret)을 사용하여 안전하게 자격증명 배포하기
|
||||
content_type: task
|
||||
weight: 50
|
||||
min-kubernetes-server-version: v1.6
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
본 페이지는 암호 및 암호화 키와 같은 민감한 데이터를 파드에 안전하게
|
||||
주입하는 방법을 설명한다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
### 시크릿 데이터를 base-64 표현으로 변환하기
|
||||
|
||||
사용자 이름 `my-app`과 비밀번호 `39528$vdg7Jb`의 두 가지 시크릿 데이터가 필요하다고 가정한다.
|
||||
먼저 base64 인코딩 도구를 사용하여 사용자 이름과 암호를 base64 표현으로 변환한다. 다음은 일반적으로 사용 가능한 base64 프로그램을 사용하는 예제이다.
|
||||
|
||||
```shell
|
||||
echo -n 'my-app' | base64
|
||||
echo -n '39528$vdg7Jb' | base64
|
||||
```
|
||||
|
||||
사용자 이름의 base-64 표현이 `bXktYXBw`이고 암호의 base-64 표현이 `Mzk1MjgkdmRnN0pi`임을
|
||||
출력을 통해 확인할 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
사용자의 OS가 신뢰하는 로컬 툴을 사용하여 외부 툴의 보안 위험을 줄이자.
|
||||
{{< /caution >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 시크릿 생성하기
|
||||
|
||||
다음은 사용자 이름과 암호가 들어 있는 시크릿을 생성하는 데 사용할 수 있는
|
||||
구성 파일이다.
|
||||
|
||||
{{< codenew file="pods/inject/secret.yaml" >}}
|
||||
|
||||
1. 시크릿을 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml
|
||||
```
|
||||
|
||||
2. 시크릿에 대한 정보를 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get secret test-secret
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
test-secret Opaque 2 1m
|
||||
```
|
||||
|
||||
3. 시크릿에 대한 자세한 정보를 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl describe secret test-secret
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
```
|
||||
Name: test-secret
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password: 13 bytes
|
||||
username: 7 bytes
|
||||
```
|
||||
|
||||
### kubectl로 직접 시크릿 생성하기
|
||||
|
||||
Base64 인코딩 단계를 건너뛰려면 `kubectl create secret` 명령을 사용하여
|
||||
동일한 Secret을 생성할 수 있다. 다음은 예시이다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb'
|
||||
```
|
||||
|
||||
이와 같이 더 편리하게 사용할 수 있다. 앞에서 설명한 자세한 접근 방식은 각 단계를
|
||||
명시적으로 실행하여 현재 상황을 확인할 수 있다.
|
||||
|
||||
|
||||
## 볼륨을 통해 시크릿 데이터에 접근할 수 있는 파드 생성하기
|
||||
|
||||
다음은 파드를 생성하는 데 사용할 수 있는 구성 파일이다.
|
||||
|
||||
{{< codenew file="pods/inject/secret-pod.yaml" >}}
|
||||
|
||||
1. 파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml
|
||||
```
|
||||
|
||||
2. 파드가 실행중인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pod secret-test-pod
|
||||
```
|
||||
|
||||
Output:
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
secret-test-pod 1/1 Running 0 42m
|
||||
```
|
||||
|
||||
3. 파드에서 실행 중인 컨테이너의 셸을 가져오자.
|
||||
```shell
|
||||
kubectl exec -i -t secret-test-pod -- /bin/bash
|
||||
```
|
||||
|
||||
4. 시크릿 데이터는 `/etc/secret-volume`에 마운트된 볼륨을 통해
|
||||
컨테이너에 노출된다.
|
||||
|
||||
셸에서 `/etc/secret-volume` 디렉터리의 파일을 나열한다.
|
||||
```shell
|
||||
# 컨테이너 내부의 셸에서 실행하자
|
||||
ls /etc/secret-volume
|
||||
```
|
||||
두 개의 파일과 각 파일의 시크릿 데이터 조각을 확인할 수 있다.
|
||||
```
|
||||
password username
|
||||
```
|
||||
|
||||
5. 셸에서 `username` 및 `password` 파일의 내용을 출력한다.
|
||||
```shell
|
||||
# 컨테이너 내부의 셸에서 실행하자
|
||||
echo "$( cat /etc/secret-volume/username )"
|
||||
echo "$( cat /etc/secret-volume/password )"
|
||||
```
|
||||
사용자 이름과 비밀번호가 출력된다.
|
||||
```
|
||||
my-app
|
||||
39528$vdg7Jb
|
||||
```
|
||||
|
||||
## 시크릿 데이터를 사용하여 컨테이너 환경 변수 정의하기
|
||||
|
||||
### 단일 시크릿 데이터로 컨테이너 환경 변수 정의하기
|
||||
|
||||
* 환경 변수를 시크릿의 키-값 쌍으로 정의한다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
|
||||
```
|
||||
|
||||
* 시크릿에 정의된 `backend-username` 값을 파드 명세의 `SECRET_USERNAME` 환경 변수에 할당한다.
|
||||
|
||||
{{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}}
|
||||
|
||||
* 파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml
|
||||
```
|
||||
|
||||
* 셸에서 `SECRET_USERNAME` 컨테이너 환경 변수의 내용을 출력한다.
|
||||
|
||||
```shell
|
||||
kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
|
||||
```
|
||||
|
||||
출력은 다음과 같다.
|
||||
```
|
||||
backend-admin
|
||||
```
|
||||
|
||||
### 여러 시크릿 데이터로 컨테이너 환경 변수 정의하기
|
||||
|
||||
* 이전 예제와 마찬가지로 시크릿을 먼저 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
|
||||
kubectl create secret generic db-user --from-literal=db-username='db-admin'
|
||||
```
|
||||
|
||||
* 파드 명세에 환경 변수를 정의한다.
|
||||
|
||||
{{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}}
|
||||
|
||||
* 파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml
|
||||
```
|
||||
|
||||
* 셸에서 컨테이너 환경 변수를 출력한다.
|
||||
|
||||
```shell
|
||||
kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
|
||||
```
|
||||
출력은 다음과 같다.
|
||||
```
|
||||
DB_USERNAME=db-admin
|
||||
BACKEND_USERNAME=backend-admin
|
||||
```
|
||||
|
||||
|
||||
## 시크릿의 모든 키-값 쌍을 컨테이너 환경 변수로 구성하기
|
||||
|
||||
{{< note >}}
|
||||
이 기능은 쿠버네티스 v1.6 이상에서 사용할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
* 여러 키-값 쌍을 포함하는 시크릿을 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
|
||||
```
|
||||
|
||||
* envFrom을 사용하여 시크릿의 모든 데이터를 컨테이너 환경 변수로 정의한다. 시크릿의 키는 파드에서 환경 변수의 이름이 된다.
|
||||
|
||||
{{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}}
|
||||
|
||||
* 파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml
|
||||
```
|
||||
|
||||
* `username` 및 `password` 컨테이너 환경 변수를 셸에서 출력한다.
|
||||
|
||||
```shell
|
||||
kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'
|
||||
```
|
||||
|
||||
출력은 다음과 같다.
|
||||
```
|
||||
username: my-app
|
||||
password: 39528$vdg7Jb
|
||||
```
|
||||
|
||||
### 참고
|
||||
|
||||
* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
|
||||
* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
|
||||
* [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
|
||||
* [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 더 배워 보기.
|
||||
+259
@@ -0,0 +1,259 @@
|
||||
---
|
||||
title: 파일로 컨테이너에 파드 정보 노출하기
|
||||
content_type: task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
본 페이지는 파드가 DownwardAPIVolumeFile을 사용하여 파드에서 실행되는 컨테이너에
|
||||
자신에 대한 정보를 노출하는 방법에 대해 설명한다. DownwardAPIVolumeFile은 파드 필드와
|
||||
컨테이너 필드를 노출할 수 있다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 다운워드(Downward) API
|
||||
|
||||
실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 방법에는 두 가지가 있다.
|
||||
|
||||
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
|
||||
* 볼륨 파일
|
||||
|
||||
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
|
||||
|
||||
## 파드 필드 저장
|
||||
|
||||
이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다.
|
||||
다음은 파드에 대한 구성 파일이다.
|
||||
|
||||
{{< codenew file="pods/inject/dapi-volume.yaml" >}}
|
||||
|
||||
구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너가 `/etc/podinfo`에 볼륨을 마운트하는
|
||||
것을 확인할 수 있다.
|
||||
|
||||
`downwardAPI` 아래의 배열을 살펴보자. 배열의 각 요소는
|
||||
[DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)이다.
|
||||
첫 번째 요소는 파드의 `metadata.labels` 필드 값이 `labels`라는 파일에 저장되어야 함을 지정한다.
|
||||
두 번째 요소는 파드의 `annotations` 필드 값이 `annotations`라는 파일에 저장되어야 함을 지정한다.
|
||||
|
||||
{{< note >}}
|
||||
이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다.
|
||||
{{< /note >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행 중인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
컨테이너의 로그를 본다.
|
||||
|
||||
```shell
|
||||
kubectl logs kubernetes-downwardapi-volume-example
|
||||
```
|
||||
|
||||
출력은 `labels` 파일과 `annotations` 파일의 내용을 보여준다.
|
||||
|
||||
```shell
|
||||
cluster="test-cluster1"
|
||||
rack="rack-22"
|
||||
zone="us-est-coast"
|
||||
|
||||
build="two"
|
||||
builder="john-doe"
|
||||
```
|
||||
|
||||
파드에서 실행 중인 컨테이너의 셸을 가져오자.
|
||||
|
||||
```shell
|
||||
kubectl exec -it kubernetes-downwardapi-volume-example -- sh
|
||||
```
|
||||
|
||||
셸에서 `labels` 파일을 보자.
|
||||
|
||||
```shell
|
||||
/# cat /etc/podinfo/labels
|
||||
```
|
||||
|
||||
출력을 통해 모든 파드의 레이블이 `labels` 파일에 기록되었음을 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
cluster="test-cluster1"
|
||||
rack="rack-22"
|
||||
zone="us-est-coast"
|
||||
```
|
||||
|
||||
마찬가지로 `annotations` 파일을 확인하자.
|
||||
|
||||
```shell
|
||||
/# cat /etc/podinfo/annotations
|
||||
```
|
||||
|
||||
`etc/podinfo` 디렉터리에 파일을 확인하자.
|
||||
|
||||
```shell
|
||||
/# ls -laR /etc/podinfo
|
||||
```
|
||||
|
||||
출력에서 `labels` 및 `annotations` 파일이
|
||||
임시 하위 디렉터리에 있음을 알 수 있다. 이 예제에서는
|
||||
`..2982_06_02_21_47_53.299460680`이다. `/etc/podinfo` 디렉터리에서 `..data`는
|
||||
임시 하위 디렉토리에 대한 심볼릭 링크이다. `/etc/podinfo` 디렉토리에서
|
||||
`labels`와 `annotations` 또한 심볼릭 링크이다.
|
||||
|
||||
```
|
||||
drwxr-xr-x ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
|
||||
lrwxrwxrwx ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
|
||||
lrwxrwxrwx ... Feb 6 21:47 annotations -> ..data/annotations
|
||||
lrwxrwxrwx ... Feb 6 21:47 labels -> ..data/labels
|
||||
|
||||
/etc/..2982_06_02_21_47_53.299460680:
|
||||
total 8
|
||||
-rw-r--r-- ... Feb 6 21:47 annotations
|
||||
-rw-r--r-- ... Feb 6 21:47 labels
|
||||
```
|
||||
|
||||
심볼릭 링크를 사용하면 메타데이터의 동적(dynamic) 원자적(atomic) 갱신이 가능하다.
|
||||
업데이트는 새 임시 디렉터리에 기록되고, `..data` 심볼릭 링크는
|
||||
[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html)을 사용하여
|
||||
원자적(atomic)으로 갱신한다.
|
||||
|
||||
{{< note >}}
|
||||
다운워드 API를 [subPath](/docs/concepts/storage/volumes/#using-subpath)
|
||||
볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
셸을 종료한다.
|
||||
|
||||
```shell
|
||||
/# exit
|
||||
```
|
||||
|
||||
## 컨테이너 필드 저장
|
||||
|
||||
이전 연습에서는 파드 필드를 DownwardAPIVolumeFile에 저장하였다.
|
||||
이 다음 연습에서는 컨테이너 필드를 저장한다. 다음은 하나의 컨테이너를 가진 파드의 구성 파일이다.
|
||||
|
||||
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
|
||||
|
||||
구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너는 `/etc/podinfo`에 볼륨을
|
||||
마운트하는 것을 확인할 수 있다.
|
||||
|
||||
`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는 DownwardAPIVolumeFile이다.
|
||||
|
||||
첫 번째 요소는 `client-container`라는 컨테이너에서
|
||||
`1m`으로 지정된 형식의 `limits.cpu` 필드 값이
|
||||
`cpu_limit`이라는 파일에 저장되어야 함을 지정한다. `divisor` 필드는 선택 사항이며
|
||||
기본값인 `1`은 CPU에 대한 코어 및 메모리에 대한 바이트를 의미한다.
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml
|
||||
```
|
||||
|
||||
파드에서 실행 중인 컨테이너의 셸을 가져온다.
|
||||
|
||||
```shell
|
||||
kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
|
||||
```
|
||||
|
||||
셸에서 `cpu_limit` 파일을 확인한다.
|
||||
|
||||
```shell
|
||||
/# cat /etc/podinfo/cpu_limit
|
||||
```
|
||||
비슷한 명령을 통해 `cpu_request`, `mem_limit` 및
|
||||
`mem_request` 파일을 확인할 수 있다.
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## 다운워드 API의 기능
|
||||
|
||||
다음 정보는 환경 변수 및 `downwardAPI` 볼륨을 통해 컨테이너에서 사용할 수 있다.
|
||||
|
||||
* `fieldRef`를 통해 다음 정보를 사용할 수 있다.
|
||||
* `metadata.name` - 파드의 이름
|
||||
* `metadata.namespace` - 파드의 네임스페이스(Namespace)
|
||||
* `metadata.uid` - 파드의 UID
|
||||
* `metadata.labels['<KEY>']` - 파드의 레이블 `<KEY>` 값 (예를 들어, `metadata.labels['mylabel']`)
|
||||
* `metadata.annotations['<KEY>']` - 파드의 어노테이션 `<KEY>` 값 (예를 들어, `metadata.annotations['myannotation']`)
|
||||
* `resourceFieldRef`를 통해 다음 정보를 사용할 수 있다.
|
||||
* 컨테이너의 CPU 한도(limit)
|
||||
* 컨테이너의 CPU 요청(request)
|
||||
* 컨테이너의 메모리 한도(limit)
|
||||
* 컨테이너의 메모리 요청(request)
|
||||
* 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
|
||||
* 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
|
||||
* 컨테이너의 임시-스토리지 한도(limit)
|
||||
* 컨테이너의 임시-스토리지 요청(request)
|
||||
|
||||
`downwardAPI` 볼륨 `fieldRef`를 통해 다음 정보를 사용할 수 있다.
|
||||
|
||||
* `metadata.labels` - 한 줄에 하나의 레이블이 있는
|
||||
`label-key="escaped-label-value"` 형식의 모든 파드 레이블
|
||||
* `metadata.annotations` - 한 줄에 하나의 어노테이션이 있는 `annotation-key="escaped-annotation-value"` 형식의 모든 파드 어노테이션
|
||||
|
||||
환경 변수를 통해 다음 정보를 사용할 수 있다.
|
||||
|
||||
* `status.podIP` - 파드의 IP 주소
|
||||
* `spec.serviceAccountName` - 파드의 서비스 계정 이름, v1.4.0-alpha.3부터 사용 가능
|
||||
* `spec.nodeName` - 노드의 이름, v1.4.0-alpha.3부터 사용 가능
|
||||
* `status.hostIP` - 노드의 IP, v1.7.0-alpha.1 이후 사용 가능
|
||||
|
||||
{{< note >}}
|
||||
컨테이너에 대해 CPU 및 메모리 한도(limit)가 지정되지 않은 경우 다운워드 API는 기본적으로
|
||||
CPU 및 메모리에 대해 할당 가능한 노드 값으로 설정한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 특정 경로 및 파일 권한에 대한 프로젝트 키
|
||||
|
||||
키(key)를 파드 안의 특정 경로에, 특정 권한으로, 파일 단위로 투영(project)할 수 있다.
|
||||
자세한 내용은
|
||||
[시크릿(Secrets)](/ko/docs/concepts/configuration/secret/)을 참조한다.
|
||||
|
||||
## 다운워드 API에 대한 동기
|
||||
|
||||
컨테이너가 쿠버네티스에 과도하게 결합되지 않고 자체에 대한 정보를 갖는 것이 때때로 유용하다.
|
||||
다운워드 API를 사용하면 컨테이너가 쿠버네티스 클라이언트 또는 API 서버를 사용하지 않고
|
||||
자체 또는 클러스터에 대한 정보를 사용할 수 있다.
|
||||
|
||||
예를 들어 잘 알려진 특정 환경 변수에 고유 식별자가 있다고 가정하는
|
||||
기존 애플리케이션이 있다. 한 가지 가능성은 애플리케이션을 래핑하는 것이지만
|
||||
이는 지루하고 오류가 발생하기 쉬우며 낮은 결합 목표를 위반한다.
|
||||
더 나은 옵션은 파드의 이름을 식별자로 사용하고
|
||||
파드의 이름을 잘 알려진 환경 변수에 삽입하는 것이다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
|
||||
* [DownwardAPIVolumeSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core)
|
||||
* [DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
|
||||
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+157
@@ -0,0 +1,157 @@
|
||||
---
|
||||
title: 환경 변수로 컨테이너에 파드 정보 노출하기
|
||||
content_type: task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
본 페이지는 파드에서 실행 중인 컨테이너에게 파드가 환경 변수를 사용해서 자신의 정보를 노출하는 방법에
|
||||
대해 설명한다. 환경 변수는 파드 필드와 컨테이너 필드를 노출할 수 있다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 다운워드(Downward) API
|
||||
|
||||
파드 및 컨테이너 필드를 실행 중인 컨테이너에 노출하는 두 가지 방법이 있다.
|
||||
|
||||
* 환경 변수
|
||||
* [볼륨 파일](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
|
||||
|
||||
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
|
||||
|
||||
|
||||
## 파드 필드를 환경 변수의 값으로 사용하자
|
||||
|
||||
이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다. 다음은 파드에 대한 구성 파일이다.
|
||||
|
||||
{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
|
||||
|
||||
구성 파일에서 5개의 환경 변수를 확인할 수 있다. `env` 필드는
|
||||
[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_NODE_NAME` 환경 변수가 파드의 `spec.nodeName` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 파드 필드에서 이름을 가져온다.
|
||||
|
||||
{{< note >}}
|
||||
이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다.
|
||||
{{< /note >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행중인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
컨테이너의 로그를 본다.
|
||||
|
||||
```shell
|
||||
kubectl logs dapi-envars-fieldref
|
||||
```
|
||||
|
||||
출력은 선택된 환경 변수의 값을 보여준다.
|
||||
|
||||
```
|
||||
minikube
|
||||
dapi-envars-fieldref
|
||||
default
|
||||
172.17.0.4
|
||||
default
|
||||
```
|
||||
|
||||
이러한 값이 로그에 출력된 이유를 보려면 구성 파일의 `command` 및 `args` 필드를 확인하자.
|
||||
컨테이너가 시작되면 5개의 환경 변수 값을 stdout에 쓰며 10초마다 이를 반복한다.
|
||||
|
||||
다음으로 파드에서 실행 중인 컨테이너의 셸을 가져오자.
|
||||
|
||||
```shell
|
||||
kubectl exec -it dapi-envars-fieldref -- sh
|
||||
```
|
||||
|
||||
셸에서 환경 변수를 보자.
|
||||
|
||||
```shell
|
||||
/# printenv
|
||||
```
|
||||
|
||||
출력은 특정 환경 변수에 파드 필드 값이 할당되었음을 보여준다.
|
||||
|
||||
```
|
||||
MY_POD_SERVICE_ACCOUNT=default
|
||||
...
|
||||
MY_POD_NAMESPACE=default
|
||||
MY_POD_IP=172.17.0.4
|
||||
...
|
||||
MY_NODE_NAME=minikube
|
||||
...
|
||||
MY_POD_NAME=dapi-envars-fieldref
|
||||
```
|
||||
|
||||
## 컨테이너 필드를 환경 변수의 값으로 사용하기
|
||||
|
||||
이전 연습에서는 파드 필드를 환경 변수의 값으로 사용했다. 이 다음 연습에서는 컨테이너 필드를
|
||||
환경 변수의 값으로 사용한다. 다음은 하나의 컨테이너가 있는 파드의 구성 파일이다.
|
||||
|
||||
{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
|
||||
|
||||
구성 파일에서 4개의 환경 변수를 확인할 수 있다. `env` 필드는
|
||||
[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_CPU_REQUEST` 환경 변수가 `test-container`라는 컨테이너의
|
||||
`requests.cpu` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 컨테이너 필드에서
|
||||
값을 가져온다.
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행중인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
컨테이너의 로그를 본다.
|
||||
|
||||
```shell
|
||||
kubectl logs dapi-envars-resourcefieldref
|
||||
```
|
||||
|
||||
출력은 선택된 환경 변수의 값을 보여준다.
|
||||
|
||||
```
|
||||
1
|
||||
1
|
||||
33554432
|
||||
67108864
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [컨테이너를 위한 환경 변수 정의하기](/docs/tasks/inject-data-application/define-environment-variable-container/)
|
||||
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
|
||||
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)
|
||||
* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core)
|
||||
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
|
||||
|
||||
|
||||
|
||||
@@ -11,6 +11,8 @@ weight: 10
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 데몬셋 업데이트 전략
|
||||
@@ -33,9 +35,11 @@ weight: 10
|
||||
`.spec.updateStrategy.type` 에 `RollingUpdate` 를 설정해야 한다.
|
||||
|
||||
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/ko/docs/concepts/workloads/controllers/deployment/#최대-불가max-unavailable)
|
||||
(기본값은 1)과
|
||||
(기본값은 1),
|
||||
[`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초)
|
||||
(기본값은 0)으로
|
||||
(기본값은 0),
|
||||
[`.spec.maxSurge`](/ko/docs/concepts/workloads/controllers/deployment/#최대-서지-max-surge)
|
||||
(베타 기능, 기본값은 25%)를
|
||||
설정할 수도 있다.
|
||||
|
||||
### `RollingUpdate` 업데이트 전략으로 데몬셋 생성
|
||||
|
||||
@@ -113,9 +113,3 @@ spec:
|
||||
- 네임스페이스에서의 huge page 사용은 `hugepages-<size>` 토큰을 사용하는 `cpu` 또는 `memory` 와 같은
|
||||
다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수
|
||||
있다.
|
||||
- 다양한 크기의 huge page 지원이 기능 게이트로 제공된다.
|
||||
{{<glossary_tooltip text="kubelet" term_id="kubelet" >}} 및
|
||||
{{<glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}
|
||||
(`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
사용하여 비활성화할 수 있다.
|
||||
|
||||
@@ -16,7 +16,7 @@ content_type: task
|
||||
|
||||
|
||||
* 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
|
||||
* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico)
|
||||
* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예: Calico, Cilium 또는 Kubenet)
|
||||
* [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터
|
||||
|
||||
{{< version-check >}}
|
||||
|
||||
@@ -183,7 +183,7 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮
|
||||
첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
|
||||
kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
|
||||
```
|
||||
|
||||
에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다.
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
title: Horizontal Pod Autoscaler
|
||||
feature:
|
||||
title: Horizontal 스케일링
|
||||
@@ -9,10 +13,6 @@ content_type: concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Horizontal Pod Autoscaler는 CPU 사용량
|
||||
@@ -181,6 +181,7 @@ HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
|
||||
API 오브젝트에 대한 자세한 내용은
|
||||
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다.
|
||||
|
||||
|
||||
## kubectl에서 Horizontal Pod Autoscaler 지원
|
||||
|
||||
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
|
||||
@@ -197,14 +198,17 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
|
||||
|
||||
## 롤링 업데이트 중 오토스케일링
|
||||
|
||||
현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
|
||||
Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
|
||||
디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다.
|
||||
쿠버네티스는 디플로이먼트에 대한 롤링 업데이트를 지원한다.
|
||||
이 경우, 디플로이먼트가 기저 레플리카셋을 알아서 관리한다.
|
||||
디플로이먼트에 오토스케일링을 설정하려면,
|
||||
각 디플로이먼트에 대한 HorizontalPodAutoscaler를 생성한다.
|
||||
HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한다.
|
||||
디플로이먼트 컨트롤러는 기저 레플리카셋에 `replicas` 값을 적용하여
|
||||
롤아웃 과정 중/이후에 적절한 숫자까지 늘어나도록 한다.
|
||||
|
||||
Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다.
|
||||
즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`)
|
||||
작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때,
|
||||
Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다.
|
||||
오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면,
|
||||
스테이트풀셋이 직접 파드의 숫자를 관리한다(즉,
|
||||
레플리카셋과 같은 중간 리소스가 없다).
|
||||
|
||||
## 쿨-다운 / 지연에 대한 지원
|
||||
|
||||
|
||||
@@ -0,0 +1,160 @@
|
||||
---
|
||||
title: 디플로이먼트(Deployment)로 스테이트리스 애플리케이션 실행하기
|
||||
min-kubernetes-server-version: v1.9
|
||||
content_type: tutorial
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지에서는 쿠버네티스 디플로이먼트 오브젝트를 사용하여 애플리케이션을 실행하는 방법을 설명한다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
* nginx 디플로이먼트 생성하기
|
||||
* kubectl을 사용하여 디플로이먼트 정보 나열하기
|
||||
* 디플로이먼트 업데이트하기
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## nginx 디플로이먼트 생성하고 탐색하기
|
||||
|
||||
쿠버네티스 디플로이먼트 오브젝트를 생성하여 애플리케이션을 실행할 수 있으며,
|
||||
디플로이먼트에 대한 명세를 YAML 파일에 기술할 수 있다. 예를 들어 이 YAML 파일은
|
||||
nginx:1.14.2 도커 이미지를 실행하는 디플로이먼트에 대한 명세를 담고 있다.
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
|
||||
|
||||
1. YAML 파일을 기반으로 디플로이먼트를 생성한다.
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
|
||||
|
||||
1. 디플로이먼트에 대한 정보를 살펴본다.
|
||||
|
||||
kubectl describe deployment nginx-deployment
|
||||
|
||||
출력은 다음과 유사하다.
|
||||
|
||||
Name: nginx-deployment
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
|
||||
Labels: app=nginx
|
||||
Annotations: deployment.kubernetes.io/revision=1
|
||||
Selector: app=nginx
|
||||
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 1 max unavailable, 1 max surge
|
||||
Pod Template:
|
||||
Labels: app=nginx
|
||||
Containers:
|
||||
nginx:
|
||||
Image: nginx:1.14.2
|
||||
Port: 80/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created)
|
||||
No events.
|
||||
|
||||
1. 디플로이먼트에 의해 생성된 파드를 나열한다.
|
||||
|
||||
kubectl get pods -l app=nginx
|
||||
|
||||
출력은 다음과 유사하다.
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h
|
||||
nginx-deployment-1771418926-r18az 1/1 Running 0 16h
|
||||
|
||||
1. 파드에 대한 정보를 살펴본다.
|
||||
|
||||
kubectl describe pod <pod-name>
|
||||
|
||||
`<pod-name>`은 파드 중 하나의 이름이다.
|
||||
|
||||
## 디플로이먼트 업데이트하기
|
||||
|
||||
새 YAML 파일을 적용하여 디플로이먼트를 업데이트할 수 있다. 이 YAML 파일은
|
||||
nginx 1.16.1을 사용하도록 디플로이먼트를 업데이트해야 함을 명시하고 있다.
|
||||
|
||||
{{< codenew file="application/deployment-update.yaml" >}}
|
||||
|
||||
1. 새 YAML 파일을 적용한다.
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
|
||||
|
||||
1. 디플로이먼트가 새 이름으로 파드를 생성하고 이전 파드를 삭제하는 것을 확인한다.
|
||||
|
||||
kubectl get pods -l app=nginx
|
||||
|
||||
## 레플리카 수를 늘려 애플리케이션 확장하기
|
||||
|
||||
새 YAML 파일을 적용하여 디플로이먼트의 파드 수를 늘릴 수 있다.
|
||||
이 YAML 파일은 `replicas`를 4로 설정하여 디플로이먼트에
|
||||
4개의 파드가 있어야 함을 명시하고 있다.
|
||||
|
||||
{{< codenew file="application/deployment-scale.yaml" >}}
|
||||
|
||||
1. 새 YAML 파일을 적용한다.
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
|
||||
|
||||
1. 디플로이먼트에 4개의 파드가 있는지 확인한다.
|
||||
|
||||
kubectl get pods -l app=nginx
|
||||
|
||||
출력은 다음과 유사하다.
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-148880595-4zdqq 1/1 Running 0 25s
|
||||
nginx-deployment-148880595-6zgi1 1/1 Running 0 25s
|
||||
nginx-deployment-148880595-fxcez 1/1 Running 0 2m
|
||||
nginx-deployment-148880595-rwovn 1/1 Running 0 2m
|
||||
|
||||
## 디플로이먼트 삭제하기
|
||||
|
||||
이름으로 디플로이먼트를 삭제한다.
|
||||
|
||||
kubectl delete deployment nginx-deployment
|
||||
|
||||
## ReplicationControllers -- 예전 방식
|
||||
|
||||
애플리케이션을 복제하여 생성하는 기본적인 방법은 내부적으로 레플리카셋(ReplicaSet)을 활용하는 디플로이먼트를
|
||||
사용하는 것이다. 쿠버네티스에 디플로이먼트 및 레플리카셋이 도입되기 전에는
|
||||
[레플리케이션컨트롤러(ReplicationController)](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 사용하여 복제 애플리케이션을
|
||||
구성했었다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워보기
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -228,7 +228,7 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
|
||||
1. kubectl-convert 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다.
|
||||
|
||||
```bash
|
||||
sudo mv ./kubectl /usr/local/bin/kubectl-convert
|
||||
sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
|
||||
sudo chown root: /usr/local/bin/kubectl-convert
|
||||
```
|
||||
|
||||
|
||||
@@ -47,20 +47,20 @@ card:
|
||||
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
- 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다.
|
||||
- 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다.
|
||||
|
||||
```cmd
|
||||
CertUtil -hashfile kubectl.exe SHA256
|
||||
type kubectl.exe.sha256
|
||||
```
|
||||
|
||||
- `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다.
|
||||
- PowerShell을 사용하는 경우, `-eq` 연산자를 통해 `True` 또는 `False` 결과가 출력되는 자동 검증을 수행한다.
|
||||
|
||||
```powershell
|
||||
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
|
||||
```
|
||||
|
||||
1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다.
|
||||
1. `PATH`로 설정된 디렉터리 중 하나에 kubectl 바이너리를 추가한다.
|
||||
|
||||
1. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
|
||||
|
||||
@@ -160,20 +160,20 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
|
||||
|
||||
kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
- 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다.
|
||||
- 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다.
|
||||
|
||||
```cmd
|
||||
CertUtil -hashfile kubectl-convert.exe SHA256
|
||||
type kubectl-convert.exe.sha256
|
||||
```
|
||||
|
||||
- `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다.
|
||||
- PowerShell을 사용하는 경우, `-eq` 연산자를 통해 `True` 또는 `False` 결과가 출력되는 자동 검증을 수행한다.
|
||||
|
||||
```powershell
|
||||
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
|
||||
```
|
||||
|
||||
1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다.
|
||||
1. `PATH`로 설정된 디렉터리 중 하나에 kubectl-convert 바이너리를 추가한다.
|
||||
|
||||
1. 플러그인이 정상적으로 설치되었는지 확인한다.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user