Update to Outdated files in dev-1.20-ko.5 branch (3)
This commit is contained in:
Yuk, Yongsu
@@ -32,7 +32,7 @@ content_type: task
|
||||
수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
|
||||
하여 스토리지의 동적 프로비저닝을 방지할 수 있다.
|
||||
|
||||
단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인
|
||||
기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동 중인
|
||||
애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자
|
||||
및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자.
|
||||
|
||||
|
||||
@@ -9,18 +9,13 @@ weight: 100
|
||||
이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을
|
||||
사용하는 파드를 생성하는 방법을 보여준다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* 이 실습을 수행하기 위해,
|
||||
[도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 도커 로그인
|
||||
@@ -106,7 +101,8 @@ kubectl create secret docker-registry regcred --docker-server=<your-registry-ser
|
||||
|
||||
아래의 각 항목에 대한 설명을 참고한다.
|
||||
|
||||
* `<your-registry-server>` 은 프라이빗 도커 저장소의 FQDN 주소이다. (도커허브(DockerHub)의 경우, https://index.docker.io/v1/)
|
||||
* `<your-registry-server>` 은 프라이빗 도커 저장소의 FQDN 주소이다.
|
||||
도커허브(DockerHub)는 `https://index.docker.io/v2/` 를 사용한다.
|
||||
* `<your-name>` 은 도커 사용자의 계정이다.
|
||||
* `<your-pword>` 은 도커 사용자의 비밀번호이다.
|
||||
* `<your-email>` 은 도커 사용자의 이메일 주소이다.
|
||||
@@ -192,7 +188,8 @@ your.private.registry.example.com/janedoe/jdoe-private:v1
|
||||
```
|
||||
|
||||
프라이빗 저장소에서 이미지를 받아오기 위하여, 쿠버네티스에서 자격 증명이 필요하다.
|
||||
구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가 `regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다.
|
||||
구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가
|
||||
`regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다.
|
||||
|
||||
시크릿을 사용해서 파드를 생성하고, 파드가 실행되는지 확인하자.
|
||||
|
||||
@@ -201,16 +198,11 @@ kubectl apply -f my-private-reg-pod.yaml
|
||||
kubectl get pod private-reg
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
|
||||
* [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기.
|
||||
* [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기.
|
||||
* [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기.
|
||||
* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기.
|
||||
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기.
|
||||
|
||||
|
||||
|
||||
@@ -22,6 +22,7 @@ Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버
|
||||
생성하려고 자동으로 시도한다.
|
||||
즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만,
|
||||
API 서버에서 제어될 수는 없다.
|
||||
파드 이름에는 노드 호스트 이름 앞에 하이픈을 붙여 접미사로 추가된다.
|
||||
|
||||
{{< note >}}
|
||||
만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여
|
||||
|
||||
@@ -1,121 +0,0 @@
|
||||
---
|
||||
content_type: concept
|
||||
title: 엘라스틱서치(Elasticsearch) 및 키바나(Kibana)를 사용한 로깅
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Google 컴퓨트 엔진(Compute Engine, GCE) 플랫폼에서, 기본 로깅 지원은
|
||||
[스택드라이버(Stackdriver) 로깅](https://cloud.google.com/logging/)을 대상으로 한다. 이는
|
||||
[스택드라이버 로깅으로 로깅하기](/docs/tasks/debug-application-cluster/logging-stackdriver)에 자세히 설명되어 있다.
|
||||
|
||||
이 문서에서는 GCE에서 운영할 때 스택드라이버 로깅의 대안으로,
|
||||
[엘라스틱서치](https://www.elastic.co/products/elasticsearch)에 로그를 수집하고
|
||||
[키바나](https://www.elastic.co/products/kibana)를 사용하여 볼 수 있도록
|
||||
클러스터를 설정하는 방법에 대해 설명한다.
|
||||
|
||||
{{< note >}}
|
||||
Google 쿠버네티스 엔진(Kubernetes Engine)에서 호스팅되는 쿠버네티스 클러스터에는 엘라스틱서치 및 키바나를 자동으로 배포할 수 없다. 수동으로 배포해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
클러스터 로깅에 엘라스틱서치, 키바나를 사용하려면 kube-up.sh를 사용하여
|
||||
클러스터를 생성할 때 아래와 같이 다음의 환경 변수를
|
||||
설정해야 한다.
|
||||
|
||||
```shell
|
||||
KUBE_LOGGING_DESTINATION=elasticsearch
|
||||
```
|
||||
|
||||
또한 `KUBE_ENABLE_NODE_LOGGING=true`(GCE 플랫폼의 기본값)인지 확인해야 한다.
|
||||
|
||||
이제, 클러스터를 만들 때, 각 노드에서 실행되는 Fluentd 로그 수집 데몬이
|
||||
엘라스틱서치를 대상으로 한다는 메시지가 나타난다.
|
||||
|
||||
```shell
|
||||
cluster/kube-up.sh
|
||||
```
|
||||
```
|
||||
...
|
||||
Project: kubernetes-satnam
|
||||
Zone: us-central1-b
|
||||
... calling kube-up
|
||||
Project: kubernetes-satnam
|
||||
Zone: us-central1-b
|
||||
+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
|
||||
+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
|
||||
+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
|
||||
Looking for already existing resources
|
||||
Starting master and configuring firewalls
|
||||
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
|
||||
NAME ZONE SIZE_GB TYPE STATUS
|
||||
kubernetes-master-pd us-central1-b 20 pd-ssd READY
|
||||
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
|
||||
+++ Logging using Fluentd to elasticsearch
|
||||
```
|
||||
|
||||
노드별 Fluentd 파드, 엘라스틱서치 파드 및 키바나 파드는
|
||||
클러스터가 활성화된 직후 kube-system 네임스페이스에서 모두 실행되어야
|
||||
한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
elasticsearch-logging-v1-78nog 1/1 Running 0 2h
|
||||
elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
|
||||
fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h
|
||||
fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h
|
||||
fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h
|
||||
fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h
|
||||
kibana-logging-v1-bhpo8 1/1 Running 0 2h
|
||||
kube-dns-v3-7r1l9 3/3 Running 0 2h
|
||||
monitoring-heapster-v4-yl332 1/1 Running 1 2h
|
||||
monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
|
||||
```
|
||||
|
||||
`fluentd-elasticsearch` 파드는 각 노드에서 로그를 수집하여
|
||||
`elasticsearch-logging` 파드로 전송한다. 이 로그는 `elasticsearch-logging` 이라는
|
||||
[서비스](/ko/docs/concepts/services-networking/service/)의 일부이다. 이
|
||||
엘라스틱서치 파드는 로그를 저장하고 REST API를 통해 노출한다.
|
||||
`kibana-logging` 파드는 엘라스틱서치에 저장된 로그를 읽기 위한 웹 UI를
|
||||
제공하며, `kibana-logging` 이라는 서비스의 일부이다.
|
||||
|
||||
엘라스틱서치 및 키바나 서비스는 모두 `kube-system` 네임스페이스에
|
||||
있으며 공개적으로 접근 가능한 IP 주소를 통해 직접 노출되지 않는다. 이를 위해,
|
||||
[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에
|
||||
대한 지침을 참고한다.
|
||||
|
||||
브라우저에서 `elasticsearch-logging` 서비스에 접근하려고 하면,
|
||||
다음과 같은 상태 페이지가 표시된다.
|
||||
|
||||
|
||||
|
||||
원할 경우, 이제 엘라스틱서치 쿼리를 브라우저에 직접 입력할 수
|
||||
있다. 수행 방법에 대한 자세한 내용은 [엘라스틱서치의 문서](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)를
|
||||
참조한다.
|
||||
|
||||
또는, 키바나를 사용하여 클러스터의 로그를 볼 수도 있다(다시
|
||||
[클러스터에서 실행되는 서비스에 접근하기 위한 지침](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)을 참고).
|
||||
키바나 URL을 처음 방문하면 수집된 로그 보기를
|
||||
구성하도록 요청하는 페이지가 표시된다. 시계열 값에
|
||||
대한 옵션을 선택하고 `@timestamp` 를 선택한다. 다음 페이지에서
|
||||
`Discover` 탭을 선택하면 수집된 로그를 볼 수 있다.
|
||||
로그를 정기적으로 새로 고치려면 새로 고침 간격을 5초로
|
||||
설정할 수 있다.
|
||||
|
||||
키바나 뷰어에서 수집된 로그의 일반적인 보기는 다음과 같다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
키바나는 로그를 탐색하기 위한 모든 종류의 강력한 옵션을 제공한다! 이를 파헤치는 방법에 대한
|
||||
아이디어는 [키바나의 문서](https://www.elastic.co/guide/en/kibana/current/discover.html)를 확인한다.
|
||||
@@ -22,7 +22,7 @@ content_type: task
|
||||
|
||||
## kubectl 플러그인 설치
|
||||
|
||||
플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 간단히 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다.
|
||||
플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다.
|
||||
|
||||
[Krew](https://krew.dev/)를 사용하여 오픈소스에서 사용 가능한
|
||||
kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네티스 SIG CLI 커뮤니티에서 관리하는
|
||||
@@ -57,9 +57,9 @@ Krew [플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를 통해 사
|
||||
|
||||
플러그인 설치 또는 사전 로딩이 필요하지 않다. 플러그인 실행 파일은
|
||||
`kubectl` 바이너리에서 상속된 환경을 받는다.
|
||||
플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다. 예를
|
||||
들어, 새로운 명령인 `kubectl foo` 를 제공하려는 플러그인은 단순히 이름이
|
||||
`kubectl-foo` 이고, `PATH` 의 어딘가에 있다.
|
||||
플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다.
|
||||
예를 들어, `kubectl-foo` 라는 플러그인은 `kubectl foo` 명령을 제공한다.
|
||||
`PATH` 어딘가에 플러그인 실행 파일을 설치해야 한다.
|
||||
|
||||
### 플러그인 예제
|
||||
|
||||
@@ -85,30 +85,31 @@ echo "I am a plugin named kubectl-foo"
|
||||
|
||||
### 플러그인 사용
|
||||
|
||||
위의 플러그인을 사용하려면, 간단히 실행 가능하게 만든다.
|
||||
플러그인을 사용하려면, 실행 가능하게 만든다.
|
||||
|
||||
```
|
||||
```shell
|
||||
sudo chmod +x ./kubectl-foo
|
||||
```
|
||||
|
||||
그리고 `PATH` 의 어느 곳에나 옮겨 놓는다.
|
||||
|
||||
```
|
||||
```shell
|
||||
sudo mv ./kubectl-foo /usr/local/bin
|
||||
```
|
||||
|
||||
이제 플러그인을 `kubectl` 명령으로 호출할 수 있다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl foo
|
||||
```
|
||||
|
||||
```
|
||||
I am a plugin named kubectl-foo
|
||||
```
|
||||
|
||||
모든 인수와 플래그는 그대로 실행 파일로 전달된다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl foo version
|
||||
```
|
||||
```
|
||||
@@ -120,6 +121,7 @@ kubectl foo version
|
||||
```bash
|
||||
export KUBECONFIG=~/.kube/config
|
||||
kubectl foo config
|
||||
|
||||
```
|
||||
```
|
||||
/home/<user>/.kube/config
|
||||
@@ -128,6 +130,7 @@ kubectl foo config
|
||||
```shell
|
||||
KUBECONFIG=/etc/kube/config kubectl foo config
|
||||
```
|
||||
|
||||
```
|
||||
/etc/kube/config
|
||||
```
|
||||
@@ -373,11 +376,8 @@ kubectl 플러그인의 배포 패키지를
|
||||
컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가
|
||||
더 쉬워진다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Go로 작성된 플러그인의
|
||||
[자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는
|
||||
샘플 CLI 플러그인 리포지터리를 확인한다.
|
||||
|
||||
@@ -35,7 +35,7 @@ weight: 30
|
||||
|
||||
## 메시지 대기열 서비스 시작
|
||||
|
||||
이 문서의 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 타입의 메시지 서비스에 적용하는데 문제가 없을 것이다.
|
||||
이 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 유형의 메시지 서비스를 사용하도록 예시를 조정할 수 있다.
|
||||
|
||||
실제로 사용할 때는, 클러스터에 메시지 대기열 서비스를 한 번
|
||||
구축하고서, 여러 많은 잡이나 오래 동작하는 서비스에 재사용할 수 있다.
|
||||
|
||||
@@ -12,7 +12,7 @@ weight: 20
|
||||
있다.
|
||||
|
||||
이 예에는 _apple_, _banana_ 그리고 _cherry_ 세 항목만 있다.
|
||||
샘플 잡들은 단순히 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.
|
||||
샘플 잡들은 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.
|
||||
|
||||
이 패턴이 보다 실질적인 유스케이스에 어떻게 부합하는지 알아 보려면
|
||||
[실제 워크로드에서 잡 사용하기](#실제-워크로드에서-잡-사용하기)를 참고한다.
|
||||
|
||||
@@ -60,7 +60,7 @@ PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
|
||||
|
||||
### 스테이트풀셋의 완벽한 삭제
|
||||
|
||||
연결된 파드를 포함해서 스테이트풀셋의 모든 것을 간단히 삭제하기 위해 다음과 같이 일련의 명령을 실행 한다.
|
||||
연결된 파드를 포함해서 스테이트풀셋의 모든 것을 삭제하기 위해 다음과 같이 일련의 명령을 실행한다.
|
||||
|
||||
```shell
|
||||
grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
|
||||
|
||||
@@ -190,7 +190,7 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
|
||||
`kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다.
|
||||
마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.
|
||||
|
||||
또한 Horizontal Pod Autoscaler를 쉽게 생성 할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
|
||||
또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
|
||||
예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
|
||||
실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
|
||||
그리고 2와 5 사이의 레플리카 개수로 설정된다.
|
||||
@@ -220,9 +220,10 @@ v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의
|
||||
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
|
||||
필요성을 제거하였다.
|
||||
|
||||
- `--horizontal-pod-autoscaler-downscale-delay` : 이 옵션 값은
|
||||
오토스케일러가 현재의 작업이 완료된 후에 다른 다운스케일 작업을
|
||||
수행하기까지 기다려야 하는 시간을 지정하는 지속 시간이다.
|
||||
- `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이
|
||||
안정화되기까지의 시간 간격을 지정한다.
|
||||
Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고,
|
||||
이 시간 간격에서의 가장 큰 크기에서만 작동한다.
|
||||
기본값은 5분(`5m0s`)이다.
|
||||
|
||||
{{< note >}}
|
||||
@@ -382,7 +383,12 @@ behavior:
|
||||
periodSeconds: 60
|
||||
```
|
||||
|
||||
파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다.
|
||||
`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
|
||||
첫 번째 정책은 _(파드들)_ 이 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
|
||||
두 번째 정책은 _비율_ 로 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
|
||||
|
||||
기본적으로 가장 많은 변경을 허용하는 정책이 선택되기에 두 번째 정책은
|
||||
파드의 레플리카 수가 40개를 초과하는 경우에만 사용된다. 레플리카가 40개 이하인 경우 첫 번째 정책이 적용된다.
|
||||
예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는
|
||||
경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때
|
||||
다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의
|
||||
@@ -390,10 +396,6 @@ behavior:
|
||||
미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에
|
||||
4개의 레플리카가 줄어든다.
|
||||
|
||||
`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
|
||||
첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
|
||||
두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
|
||||
|
||||
확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
|
||||
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
|
||||
값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
|
||||
@@ -440,7 +442,7 @@ behavior:
|
||||
periodSeconds: 15
|
||||
selectPolicy: Max
|
||||
```
|
||||
안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된
|
||||
안정화 윈도우의 스케일링 다운의 경우 _300_ 초 (또는 제공된
|
||||
경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재
|
||||
실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링
|
||||
대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다.
|
||||
|
||||
@@ -65,6 +65,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
|
||||
|
||||
kubectl describe deployment mysql
|
||||
|
||||
출력은 다음과 유사하다.
|
||||
|
||||
Name: mysql
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 01 Nov 2016 11:18:45 -0700
|
||||
@@ -105,6 +107,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
|
||||
|
||||
kubectl get pods -l app=mysql
|
||||
|
||||
출력은 다음과 유사하다.
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mysql-63082529-2z3ki 1/1 Running 0 3m
|
||||
|
||||
@@ -112,6 +116,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
|
||||
|
||||
kubectl describe pvc mysql-pv-claim
|
||||
|
||||
출력은 다음과 유사하다.
|
||||
|
||||
Name: mysql-pv-claim
|
||||
Namespace: default
|
||||
StorageClass:
|
||||
|
||||
Reference in New Issue
Block a user