Merge pull request #30749 from kubernetes/dev-1.22-ko.3
[ko] 3rd Korean localization work for v1.22
This commit is contained in:
Kubernetes Prow Robot
@@ -2,6 +2,7 @@
|
||||
title: NGINX 인그레스(Ingress) 컨트롤러로 Minikube에서 인그레스 설정하기
|
||||
content_type: task
|
||||
weight: 100
|
||||
min-kubernetes-server-version: 1.19
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -17,23 +18,21 @@ API 객체이다. [인그레스 컨트롤러](/ko/docs/concepts/services-network
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
만약 이보다 더 이전 버전의 쿠버네티스를 사용하고 있다면,
|
||||
해당 쿠버네티스 버전의 문서를 참고한다.
|
||||
|
||||
|
||||
### Minikube 클러스터 생성하기
|
||||
|
||||
Katacoda 활용하기
|
||||
: {{< kat-button >}}
|
||||
|
||||
로컬에서 생성하기
|
||||
: 이미 로컬에 [Minikube를 설치](/ko/docs/tasks/tools/#minikube)했다면,
|
||||
`minikube start`를 실행하여 클러스터를 생성한다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Minikube 클러스터 생성하기
|
||||
|
||||
1. **터미널 실행**을 클릭한다.
|
||||
|
||||
{{< kat-button >}}
|
||||
|
||||
1. (선택 사항) Minikube를 로컬로 설치한 경우 다음 명령을 실행한다.
|
||||
|
||||
```shell
|
||||
minikube start
|
||||
```
|
||||
|
||||
## 인그레스 컨트롤러 활성화
|
||||
|
||||
1. NGINX 인그레스 컨트롤러를 활성화하기 위해 다음 명령을 실행한다.
|
||||
@@ -45,14 +44,14 @@ API 객체이다. [인그레스 컨트롤러](/ko/docs/concepts/services-network
|
||||
1. NGINX 인그레스 컨트롤러가 실행 중인지 확인한다.
|
||||
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="minikube v1.19 or later" %}}
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="minikube v1.19 or later" %}}
|
||||
```shell
|
||||
kubectl get pods -n ingress-nginx
|
||||
```
|
||||
{{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}}
|
||||
{{< note >}}파드가 정상적으로 실행되기까지 1분 정도 소요될 수 있다.{{< /note >}}
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
@@ -60,15 +59,14 @@ ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m
|
||||
ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m
|
||||
ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="minikube v1.18.1 or earlier" %}}
|
||||
{{% /tab %}}
|
||||
{{% tab name="minikube v1.18.1 or earlier" %}}
|
||||
```shell
|
||||
kubectl get pods -n kube-system
|
||||
```
|
||||
{{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}}
|
||||
{{< note >}}파드가 정상적으로 실행되기까지 1분 정도 소요될 수 있다.{{< /note >}}
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
@@ -79,133 +77,121 @@ kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m
|
||||
nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m
|
||||
storage-provisioner 1/1 Running 0 2m
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
|
||||
```shell
|
||||
kubectl get pods -n ingress-nginx
|
||||
```
|
||||
|
||||
{{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}}
|
||||
|
||||
Output:
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
ingress-nginx-admission-create-2tgrf 0/1 Completed 0 3m28s
|
||||
ingress-nginx-admission-patch-68b98 0/1 Completed 0 3m28s
|
||||
ingress-nginx-controller-59b45fb494-lzmw2 1/1 Running 0 3m28s
|
||||
```
|
||||
|
||||
`nginx-ingress-controller-`로 시작하는 파드가 있는지 확인한다.
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## hello, world 앱 배포하기
|
||||
|
||||
1. 다음 명령을 사용하여 디플로이먼트(Deployment)를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
|
||||
```
|
||||
```shell
|
||||
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
deployment.apps/web created
|
||||
```
|
||||
```
|
||||
deployment.apps/web created
|
||||
```
|
||||
|
||||
1. 디플로이먼트를 노출시킨다.
|
||||
|
||||
```shell
|
||||
kubectl expose deployment web --type=NodePort --port=8080
|
||||
```
|
||||
```shell
|
||||
kubectl expose deployment web --type=NodePort --port=8080
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
service/web exposed
|
||||
```
|
||||
```
|
||||
service/web exposed
|
||||
```
|
||||
|
||||
1. 서비스(Service)가 생성되고 노드 포트에서 사용할 수 있는지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get service web
|
||||
```
|
||||
```shell
|
||||
kubectl get service web
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m
|
||||
```
|
||||
|
||||
1. 노드포트(NodePort)를 통해 서비스에 접속한다.
|
||||
|
||||
```shell
|
||||
minikube service web --url
|
||||
```
|
||||
```shell
|
||||
minikube service web --url
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
http://172.17.0.15:31637
|
||||
```
|
||||
```
|
||||
http://172.17.0.15:31637
|
||||
```
|
||||
|
||||
{{< note >}}Katacoda 환경만 해당: 터미널 패널 상단에서 더하기 기호를 클릭한 다음 **Select port to view on Host 1**을 클릭한다. 노드포트(이 경우 '31637')를 입력한 다음 **Display Port**를 클릭한다.{{< /note >}}
|
||||
{{< note >}}Katacoda 환경만 해당: 터미널 패널 상단에서 더하기 기호를 클릭한 다음 **Select port to view on Host 1**을 클릭한다. 노드포트(이 경우 '31637')를 입력한 다음 **Display Port**를 클릭한다.{{< /note >}}
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
Hostname: web-55b8c6998d-8k564
|
||||
```
|
||||
```
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
Hostname: web-55b8c6998d-8k564
|
||||
```
|
||||
|
||||
이제 Minikube IP 주소와 노드포트를 통해 샘플 앱에 액세스할 수 있다. 다음 단계에서는
|
||||
인그레스 리소스를 사용하여 앱에 액세스할 수 있다.
|
||||
이제 Minikube IP 주소와 노드포트를 통해 샘플 앱에 액세스할 수 있다. 다음 단계에서는
|
||||
인그레스 리소스를 사용하여 앱에 액세스할 수 있다.
|
||||
|
||||
## 인그레스 리소스 생성하기
|
||||
## 인그레스 생성하기
|
||||
|
||||
다음 파일은 hello-world.info를 통해 서비스로 트래픽을 보내는 인그레스 리소스다.
|
||||
다음 매니페스트는 hello-world.info를 통해 서비스로 트래픽을 보내는 인그레스를 정의한다.
|
||||
|
||||
1. 다음 파일을 통해 `example-ingress.yaml`을 만든다.
|
||||
|
||||
{{< codenew file="service/networking/example-ingress.yaml" >}}
|
||||
|
||||
1. 다음 명령어를 실행하여 인그레스 리소스를 생성한다.
|
||||
1. 다음 명령어를 실행하여 인그레스 오브젝트를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
ingress.networking.k8s.io/example-ingress created
|
||||
```
|
||||
```
|
||||
ingress.networking.k8s.io/example-ingress created
|
||||
```
|
||||
|
||||
1. IP 주소가 설정되었는지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get ingress
|
||||
```
|
||||
```shell
|
||||
kubectl get ingress
|
||||
```
|
||||
|
||||
{{< note >}}이 작업은 몇 분 정도 소요될 수 있다.{{< /note >}}
|
||||
{{< note >}}이 작업은 몇 분 정도 소요될 수 있다.{{< /note >}}
|
||||
|
||||
```shell
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
example-ingress <none> hello-world.info 172.17.0.15 80 38s
|
||||
```
|
||||
다음 예시와 같이, ADDRESS 열에서 IPv4 주소를 확인할 수 있다.
|
||||
|
||||
1. `/etc/hosts` 파일의 맨 아래에 다음 행을 추가한다.
|
||||
```
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
example-ingress <none> hello-world.info 172.17.0.15 80 38s
|
||||
```
|
||||
|
||||
{{< note >}}Minikube를 로컬에서 실행하는 경우 'minikube ip'를 사용하여 외부 IP를 가져온다. 인그레스 목록에 표시되는 IP 주소는 내부 IP가 된다.{{< /note >}}
|
||||
1. 호스트 컴퓨터의 `/etc/hosts` 파일 맨 아래에
|
||||
다음 행을 추가한다 (관리자 권한 필요).
|
||||
|
||||
```
|
||||
172.17.0.15 hello-world.info
|
||||
```
|
||||
|
||||
이것은 hello-world.info에서 Minikube로 요청을 보낸다.
|
||||
{{< note >}}Minikube를 로컬에서 실행하는 경우 'minikube ip'를 사용하여 외부 IP를 가져온다. 인그레스 목록에 표시되는 IP 주소는 내부 IP가 된다.{{< /note >}}
|
||||
|
||||
이렇게 하면, 웹 브라우저가
|
||||
hello-world.info URL에 대한 요청을 Minikube로 전송한다.
|
||||
|
||||
1. 인그레스 컨트롤러가 트래픽을 전달하는지 확인한다.
|
||||
|
||||
@@ -213,9 +199,9 @@ storage-provisioner 1/1 Running 0 2m
|
||||
curl hello-world.info
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
```
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
Hostname: web-55b8c6998d-8k564
|
||||
@@ -225,32 +211,33 @@ storage-provisioner 1/1 Running 0 2m
|
||||
|
||||
## 두 번째 디플로이먼트 생성하기
|
||||
|
||||
1. 다음 명령을 사용하여 v2 디플로이먼트를 생성한다.
|
||||
1. 다음 명령을 사용하여 두 번째 디플로이먼트를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
|
||||
```
|
||||
Output:
|
||||
```shell
|
||||
kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
|
||||
```
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
deployment.apps/web2 created
|
||||
```
|
||||
```
|
||||
deployment.apps/web2 created
|
||||
```
|
||||
|
||||
1. 디플로이먼트를 노출시킨다.
|
||||
1. 두 번째 디플로이먼트를 노출시킨다.
|
||||
|
||||
```shell
|
||||
kubectl expose deployment web2 --port=8080 --type=NodePort
|
||||
```
|
||||
```shell
|
||||
kubectl expose deployment web2 --port=8080 --type=NodePort
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
service/web2 exposed
|
||||
```
|
||||
```
|
||||
service/web2 exposed
|
||||
```
|
||||
|
||||
## 인그레스 수정하기
|
||||
## 기존 인그레스 수정하기 {#edit-ingress}
|
||||
|
||||
1. 기존 `example-ingress.yaml`을 편집하여 다음 줄을 추가한다.
|
||||
1. 기존 `example-ingress.yaml` 매니페스트를 편집하고,
|
||||
하단에 다음 줄을 추가한다.
|
||||
|
||||
```yaml
|
||||
- path: /v2
|
||||
@@ -264,47 +251,47 @@ storage-provisioner 1/1 Running 0 2m
|
||||
|
||||
1. 변경 사항을 적용한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f example-ingress.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl apply -f example-ingress.yaml
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
ingress.networking/example-ingress configured
|
||||
```
|
||||
```
|
||||
ingress.networking/example-ingress configured
|
||||
```
|
||||
|
||||
## 인그레스 테스트하기
|
||||
|
||||
1. Hello World 앱의 첫 번째 버전에 액세스한다.
|
||||
|
||||
```shell
|
||||
curl hello-world.info
|
||||
```
|
||||
```shell
|
||||
curl hello-world.info
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
Hostname: web-55b8c6998d-8k564
|
||||
```
|
||||
```
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
Hostname: web-55b8c6998d-8k564
|
||||
```
|
||||
|
||||
1. Hello World 앱의 두 번째 버전에 액세스한다.
|
||||
|
||||
```shell
|
||||
curl hello-world.info/v2
|
||||
```
|
||||
```shell
|
||||
curl hello-world.info/v2
|
||||
```
|
||||
|
||||
Output:
|
||||
결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
Hello, world!
|
||||
Version: 2.0.0
|
||||
Hostname: web2-75cd47646f-t8cjk
|
||||
```
|
||||
```
|
||||
Hello, world!
|
||||
Version: 2.0.0
|
||||
Hostname: web2-75cd47646f-t8cjk
|
||||
```
|
||||
|
||||
{{< note >}}Minikube를 로컬에서 실행하는 경우 브라우저에서 hello-world.info 및 hello-world.info/v2에 접속할 수 있다.{{< /note >}}
|
||||
{{< note >}}Minikube를 로컬에서 실행하는 경우 브라우저에서 hello-world.info 및 hello-world.info/v2에 접속할 수 있다.{{< /note >}}
|
||||
|
||||
|
||||
|
||||
@@ -315,5 +302,3 @@ storage-provisioner 1/1 Running 0 2m
|
||||
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 더 보기.
|
||||
* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 보기.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ card:
|
||||
대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다.
|
||||
|
||||
```
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml
|
||||
```
|
||||
|
||||
## 대시보드 UI 접근
|
||||
@@ -182,7 +182,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
|
||||
특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
|
||||
|
||||
- **환경 변수**: 쿠버네티스 서비스를
|
||||
[환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다.
|
||||
[환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다.
|
||||
환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다.
|
||||
애플리케이션들이 서비스를 찾는데 사용된다.
|
||||
값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
|
||||
|
||||
@@ -80,7 +80,7 @@ content_type: task
|
||||
최대 1개의 스토리지클래스를 기본값으로 표시할 수 있다는 것을 알아두자. 만약
|
||||
2개 이상이 기본값으로 표시되면, 명시적으로 `storageClassName` 가 지정되지 않은 `PersistentVolumeClaim` 은 생성될 수 없다.
|
||||
|
||||
1. 사용자가 선택한 스토리지클래스가 기본값으로 되어있는지 확인한다.
|
||||
1. 사용자가 선택한 스토리지클래스가 기본값으로 되어 있는지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl get storageclass
|
||||
|
||||
@@ -88,8 +88,8 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
|
||||
* [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 배워 보기.
|
||||
* [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)에 대해 더 배워 보기.
|
||||
|
||||
### Reference
|
||||
### 레퍼런스 {#reference}
|
||||
|
||||
* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
|
||||
* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
|
||||
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기.
|
||||
* {{< api-reference page="config-and-storage-resources/persistent-volume-v1" >}}
|
||||
* Pay attention to the 퍼시스턴트볼륨의 `.spec.persistentVolumeReclaimPolicy` [필드](docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec)에 주의한다.
|
||||
* {{< api-reference page="config-and-storage-resources/persistent-volume-claim-v1" >}}
|
||||
|
||||
@@ -156,7 +156,7 @@ sysctl 설정이 필요한 노드에만 파드를 예약하는 것이 좋다.
|
||||
두 _unsafe_ sysctl을 명시적으로 활성화하지 않은 노드에서 _unsafe_ sysctl을 사용하는
|
||||
파드가 시작되지 않는다. _node-level_ sysctl과 마찬가지로
|
||||
[_테인트와 톨러레이션_ 특징](/docs/reference/generated/kubectl/kubectl-commands/#taint) 또는
|
||||
[노드 테인트](/docs/concepts/scheduling-eviction/taint-and-toleration/)를
|
||||
[노드 테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를
|
||||
사용하여 해당 파드를 오른쪽 노드에
|
||||
스케줄하는 것을 추천한다.
|
||||
|
||||
|
||||
@@ -122,5 +122,5 @@ ContainerAdministrator
|
||||
|
||||
* [쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/)
|
||||
* [그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/#그룹-매니지드-서비스-어카운트를-이용하여-워크로드-신원-관리하기)
|
||||
* [윈도우 파드와 컨테이너의 GMSA 구성](/docs/tasks/configure-pod-container/configure-gmsa/)
|
||||
* [윈도우 파드와 컨테이너의 GMSA 구성](/ko/docs/tasks/configure-pod-container/configure-gmsa/)
|
||||
|
||||
|
||||
@@ -91,7 +91,7 @@ kubectl describe pods ${POD_NAME}
|
||||
|
||||
### 파드가 손상(crashing)되었거나 양호하지 않을(unhealthy) 경우
|
||||
|
||||
일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/docs/tasks/debug-application-cluster/debug-running-pod/)에
|
||||
일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/)에
|
||||
기술된 메서드를 디버깅에 사용할 수 있다.
|
||||
|
||||
|
||||
|
||||
@@ -69,7 +69,7 @@ kubectl exec -it cassandra -- sh
|
||||
```
|
||||
|
||||
더욱 상세한 내용은 다음 [동작중인 컨테이너의 쉘에 접근하기](
|
||||
/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라.
|
||||
/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라.
|
||||
|
||||
## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container}
|
||||
|
||||
@@ -87,7 +87,7 @@ kubectl exec -it cassandra -- sh
|
||||
|
||||
{{< note >}}
|
||||
이 섹션에서 소개하는 예시를 사용하기 위해서는
|
||||
여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
|
||||
여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
|
||||
활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ kubectl get pods -l app=myapp
|
||||
|
||||
만약 오랜 시간동안 `Unknown`이나 `Terminating` 상태에 있는
|
||||
파드들을 발견하였다면, 이러한 파드들을 어떻게 다루는지 알아보기 위해
|
||||
[스테이트풀셋 파드 삭제하기](/docs/tasks/run-application/delete-stateful-set/)를 참고하길 바란다.
|
||||
[스테이트풀셋 파드 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)를 참고하길 바란다.
|
||||
스테이트풀셋에 포함된 개별 파드들을 디버깅하기 위해서는
|
||||
[파드 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) 가이드를 참고하길 바란다.
|
||||
|
||||
|
||||
@@ -152,5 +152,5 @@ EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값
|
||||
|
||||
|
||||
* [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다.
|
||||
* [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다.
|
||||
* [컨테이너 안에서 커맨드를 실행하는 방법](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다.
|
||||
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다.
|
||||
|
||||
+1
-1
@@ -110,6 +110,6 @@ spec:
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
|
||||
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
|
||||
* [시크릿을 환경 변수로 사용하기](/ko/docs/concepts/configuration/secret/#시크릿을-환경-변수로-사용하기)에 대해 알아본다.
|
||||
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
|
||||
|
||||
+1
-1
@@ -72,6 +72,6 @@ weight: 20
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
|
||||
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
|
||||
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
|
||||
|
||||
|
||||
+4
-4
@@ -25,7 +25,7 @@ weight: 40
|
||||
|
||||
실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 방법에는 두 가지가 있다.
|
||||
|
||||
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
|
||||
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api)
|
||||
* 볼륨 파일
|
||||
|
||||
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
|
||||
@@ -134,7 +134,7 @@ total 8
|
||||
원자적(atomic)으로 갱신한다.
|
||||
|
||||
{{< note >}}
|
||||
다운워드 API를 [subPath](/docs/concepts/storage/volumes/#using-subpath)
|
||||
다운워드 API를 [subPath](/ko/docs/concepts/storage/volumes/#using-subpath)
|
||||
볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -200,8 +200,8 @@ kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
|
||||
* 컨테이너의 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/)가 활성화된 경우)
|
||||
* 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
|
||||
* 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
|
||||
* 컨테이너의 임시-스토리지 한도(limit)
|
||||
* 컨테이너의 임시-스토리지 요청(request)
|
||||
|
||||
|
||||
+2
-2
@@ -27,7 +27,7 @@ weight: 30
|
||||
파드 및 컨테이너 필드를 실행 중인 컨테이너에 노출하는 두 가지 방법이 있다.
|
||||
|
||||
* 환경 변수
|
||||
* [볼륨 파일](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
|
||||
* [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#다운워드-downward-api)
|
||||
|
||||
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
|
||||
|
||||
@@ -145,7 +145,7 @@ kubectl logs dapi-envars-resourcefieldref
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [컨테이너를 위한 환경 변수 정의하기](/docs/tasks/inject-data-application/define-environment-variable-container/)
|
||||
* [컨테이너를 위한 환경 변수 정의하기](/ko/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)
|
||||
|
||||
@@ -132,7 +132,7 @@ kubectl delete cronjob hello
|
||||
## 크론 잡 명세 작성
|
||||
|
||||
다른 모든 쿠버네티스 구성과 마찬가지로, 크론 잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 구성 파일
|
||||
작업에 대한 일반적인 정보는 [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)와
|
||||
작업에 대한 일반적인 정보는 [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와
|
||||
[kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
|
||||
|
||||
크론 잡 구성에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
|
||||
|
||||
@@ -147,7 +147,7 @@ daemonset "fluentd-elasticsearch" successfully rolled out
|
||||
#### 일부 노드에 리소스가 부족하다
|
||||
|
||||
적어도 하나의 노드에서 새 데몬셋 파드를 스케줄링할 수 없어서 롤아웃이
|
||||
중단되었다. 노드에 [리소스가 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때
|
||||
중단되었다. 노드에 [리소스가 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때
|
||||
발생할 수 있다.
|
||||
|
||||
이 경우, `kubectl get nodes` 의 출력 결과와 다음의 출력 결과를 비교하여
|
||||
|
||||
@@ -80,11 +80,11 @@ kubectl delete pvc -l app=myapp
|
||||
|
||||
### 스테이트풀셋 파드의 강제 삭제
|
||||
|
||||
스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
|
||||
스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기.
|
||||
[스테이트풀셋 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기.
|
||||
|
||||
@@ -91,6 +91,6 @@ kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[스테이트풀셋 디버깅하기](/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기.
|
||||
[스테이트풀셋 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기.
|
||||
|
||||
|
||||
|
||||
@@ -82,8 +82,8 @@ service/php-apache created
|
||||
다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를
|
||||
1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다.
|
||||
간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다.
|
||||
(kubectl run으로 각 파드는 200 밀리코어까지 요청할 수 있고,
|
||||
따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다).
|
||||
kubectl run으로 각 파드는 200 밀리코어를 요청하므로,
|
||||
여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다.
|
||||
이에 대한 자세한 알고리즘은 [여기](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고하기 바란다.
|
||||
|
||||
```shell
|
||||
@@ -447,7 +447,7 @@ Events:
|
||||
이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다.
|
||||
첫 번째 `AbleToScale`는 HPA가 스케일을 가져오고 업데이트할 수 있는지,
|
||||
백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다.
|
||||
두 번째 `ScalingActive`는 HPA가 활성화되어있는지(즉 대상 레플리카 개수가 0이 아닌지),
|
||||
두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 개수가 0이 아닌지),
|
||||
원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우,
|
||||
일반적으로 메트릭을 가져오는데 문제가 있다.
|
||||
마지막으로, 마지막 조건인 `ScalingLimited`는
|
||||
|
||||
@@ -398,7 +398,7 @@ behavior:
|
||||
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
|
||||
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
|
||||
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
|
||||
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어있다.
|
||||
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어 있다.
|
||||
|
||||
```yaml
|
||||
scaleDown:
|
||||
|
||||
@@ -196,7 +196,7 @@ kubectl delete pv mysql-pv-volume
|
||||
|
||||
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워 보기
|
||||
|
||||
* [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해 더 배워보기
|
||||
* [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해 더 배워보기
|
||||
|
||||
* [kubectl run 문서](/docs/reference/generated/kubectl/kubectl-commands/#run)
|
||||
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "서비스 카탈로그"
|
||||
description: 서비스 카탈로그 익스텐션(extension) API를 설치한다.
|
||||
weight: 150
|
||||
---
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: SC로 서비스 카탈로그 설치하기
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}}
|
||||
|
||||
GCP [서비스 카탈로그 설치 프로그램](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)
|
||||
도구로 쿠버네티스 클러스터에 서비스 카탈로그를 쉽게 설치하거나 제거하여
|
||||
Google Cloud 프로젝트에 연결할 수 있다.
|
||||
|
||||
서비스 카탈로그는 Google Cloud뿐 아니라 모든 종류의 관리형 서비스와 함께 작동할 수 있다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* [서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)의 핵심 개념을 이해한다.
|
||||
* [Go 1.6+](https://golang.org/dl/)를 설치하고 `GOPATH`를 설정한다.
|
||||
* SSL 아티팩트 생성에 필요한 [cfssl](https://github.com/cloudflare/cfssl) 도구를 설치한다.
|
||||
* 서비스 카탈로그에는 Kubernetes 버전 1.7 이상이 필요하다.
|
||||
* [kubectl 설치 및 설정](/ko/docs/tasks/tools/)을 사용하여 Kubernetes 버전 1.7 이상의 클러스터에 연결하도록 구성한다.
|
||||
* kubectl 사용자는 서비스 카탈로그를 설치하기 위해 *cluster-admin* 역할에 바인딩되어야 한다. 이것이 사실인지 확인하려면 다음 명령을 실행한다.
|
||||
|
||||
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
## 로컬 환경에 `sc` 설치하기
|
||||
|
||||
설치 프로그램은 로컬 컴퓨터에서 `sc`라는 CLI 도구로 실행된다.
|
||||
|
||||
`go get`을 사용하여 설치한다.
|
||||
|
||||
```shell
|
||||
go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
|
||||
```
|
||||
|
||||
`sc`는 이제 `GOPATH/bin` 디렉토리에 설치되어야 한다.
|
||||
|
||||
## 쿠버네티스 클러스터에 서비스 카탈로그 설치하기
|
||||
|
||||
먼저 명령을 실행하여 모든 종속성이 설치되었는지 확인한다.
|
||||
|
||||
```shell
|
||||
sc check
|
||||
```
|
||||
|
||||
확인에 성공하면 다음을 반환해야 한다.
|
||||
|
||||
```
|
||||
Dependency check passed. You are good to go.
|
||||
```
|
||||
|
||||
그런 다음 설치 명령을 실행하고 백업에 사용할 `storageclass`를 지정한다.
|
||||
|
||||
```shell
|
||||
sc install --etcd-backup-storageclass "standard"
|
||||
```
|
||||
|
||||
## 서비스 카탈로그 제거하기
|
||||
|
||||
`sc` 도구를 사용하여 쿠버네티스 클러스터에서 서비스 카탈로그를 제거하려면 다음을 실행한다.
|
||||
|
||||
```shell
|
||||
sc uninstall
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
|
||||
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
|
||||
|
||||
|
||||
@@ -12,8 +12,8 @@ card:
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다.
|
||||
최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew currentVersion >}} 클라이언트는 v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersion >}}, v{{< skew currentVersionAddMinor 1 >}}의 컨트롤 플레인과 연동될 수 있다.
|
||||
호환되는 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
|
||||
## 리눅스에 kubectl 설치
|
||||
|
||||
|
||||
@@ -12,8 +12,8 @@ card:
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다.
|
||||
최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew currentVersion >}} 클라이언트는 v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersion >}}, v{{< skew currentVersionAddMinor 1 >}}의 컨트롤 플레인과 연동될 수 있다.
|
||||
호환되는 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
|
||||
## macOS에 kubectl 설치
|
||||
|
||||
|
||||
@@ -12,8 +12,8 @@ card:
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다.
|
||||
최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew currentVersion >}} 클라이언트는 v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersion >}}, v{{< skew currentVersionAddMinor 1 >}}의 컨트롤 플레인과 연동될 수 있다.
|
||||
호환되는 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
|
||||
## 윈도우에 kubectl 설치
|
||||
|
||||
|
||||
Reference in New Issue
Block a user