whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Seventh Korean l10n work for release 1.18

Browse Source 
- Translate reference/command-line-tools-reference/feature-gates.md int… (#22240)
- Fix issue of broken links to translated docs (#22105)
- Fix issue of document link in some ko documents (#22379)
- Translate tasks/administer-cluster/access-cluster-services.md into Ko… (#21776)
- Fix issue with 'Linux' and 'Windows' notation in Korean docs (#22362)
- Fix issue of broken links to translated docs #2 (#22270)
- Fix issue with k8s.io/ko/docs/concepts/overview/kubernetes-api.md (#22261)
- Fix issue with k8s.io/ko/docs/concepts/overview/working-with-objects/ (#22263)
- Fix incorrect notation of 'directory' into Korean (#22155)
- Fix issue with k8s.io/ko/docs/concepts/overview/components.md (#22232)
- Update outdated files in dev-1.18-ko.7 (#22128)
- Modify spacing term ReplicaSet in Korean (#22148)
- Translate tasks/administer-cluster/extended-resource-node.md into Korean (#21849)
- Translate tasks/administer-cluster/access-cluster-api.md into Korean (#21730)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: woopyoung <ywp041@gmail.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>
Co-authored-by: PyungHo Yoon <learder@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: Ian Y. Choi <ianyrchoi@gmail.com>
This commit is contained in:
June Yi
2020-07-10 12:38:02 +09:00
parent 2a4923f49a
commit f604a4b60a
148 changed files with 2604 additions and 1350 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
+220 -74
View File
@@ -6,9 +6,9 @@ weight: 10
---
<!-- overview -->
이 튜토리얼은 스테이트풀셋([StatefulSets](/ko/docs/concepts/workloads/controllers/statefulset/))을 이용하여
애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드를 생성하고 삭제하며
스케일링하고 업데이트하는지 시연한다.
이 튜토리얼은 {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}}을 이용하여
애플리케이션을 관리하는 방법을 소개한다.
어떻게 스테이트풀셋의 파드를 생성하고, 삭제하며, 스케일링하고, 업데이트하는지 시연한다.
## {{% heading "prerequisites" %}}
@@ -22,13 +22,14 @@ weight: 10
* [퍼시스턴트볼륨(PersistentVolumes)](/ko/docs/concepts/storage/persistent-volumes/)
* [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
* [kubectl CLI](/docs/user-guide/kubectl/)
* [kubectl](/docs/reference/kubectl/kubectl/) 커맨드 라인 도구
{{< note >}}
이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록
설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면,
튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을
프로비저닝해야 한다.
{{< /note >}}
## {{% heading "objectives" %}}
@@ -46,7 +47,6 @@ weight: 10
* 스테이트풀셋은 어떻게 스케일링하는지
* 스테이트풀셋의 파드는 어떻게 업데이트하는지
<!-- lessoncontent -->
## 스테이트풀셋 생성하기
@@ -74,20 +74,24 @@ kubectl get pods -w -l app=nginx
```shell
kubectl apply -f web.yaml
```
```
service/nginx created
statefulset.apps/web created
```
상기 명령어는 [NGINX](https://www.nginx.com) 웹 서버를
실행하는 2개의 파드를 생성한다. `nginx` 서비스와
`web` 스테이트풀셋이 성공적으로 생성되었는지 알아보자.
실행하는 2개의 파드를 생성한다. `nginx` 서비스의 정보를 가져온다.
```shell
kubectl get service nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx ClusterIP None <none> 80/TCP 12s
```
그리고 `web` 스테이트풀셋 정보를 가져와서 모두 성공적으로 생성되었는지 확인한다.
```shell
kubectl get statefulset web
```
NAME DESIRED CURRENT AGE
web 2 1 20s
```
@@ -101,6 +105,8 @@ N개의 레플리카를 가진 스테이트풀셋은 배포 시에
```shell
kubectl get pods -w -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
@@ -112,8 +118,8 @@ web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 18s
```
`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에
시작하지 않음을 주의하자.
참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 참고)
및 _Ready_ ([파드의 조건](/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자.
## 스테이트풀셋 안에 파드
@@ -125,16 +131,17 @@ web-1 1/1 Running 0 18s
```shell
kubectl get pods -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 1m
web-1 1/1 Running 0 1m
```
[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서
언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다.
이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는
고유한 순번에 기인한다. 파드의 이름의 형식은
이 정체성은 스테이트풀셋 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}에서
각 파드에 주어지는 고유한 순번에 기인한다. 파드의 이름의 형식은
`<스테이트풀셋 이름>-<순번>` 이다. 앞서 `web` 스테이트풀셋은
2개의 레플리카를 가졌으므로 `web-0` 과 `web-1` 2개 파드를 생성한다.
@@ -145,7 +152,9 @@ web-1 1/1 Running 0 1m
[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 이용하자.
```shell
for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done
```
```
web-0
web-1
```
@@ -157,7 +166,14 @@ web-1
```shell
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm
```
위 명령으로 새로운 셸을 시작한다. 새 셸에서 다음을 실행한다.
```shell
# dns-test 컨테이너 셸에서 다음을 실행한다.
nslookup web-0.nginx
```
출력 결과는 다음과 비슷하다.
```
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
@@ -172,6 +188,8 @@ Name: web-1.nginx
Address 1: 10.244.2.6
```
(이제 `exit` 명령으로 컨테이너 셸에서 종료한다.)
헤드리스 서비스의 CNAME은 SRV 레코드를 지칭한다
(Running과 Ready 상태의 각 파드마다 1개).
SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지칭한다.
@@ -196,6 +214,8 @@ pod "web-1" deleted
```shell
kubectl get pod -w -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-0 0/1 ContainerCreating 0 0s
NAME READY STATUS RESTARTS AGE
@@ -207,15 +227,27 @@ web-1 1/1 Running 0 34s
```
파드의 호스트네임과 클러스터 내부 DNS 엔트리를 보기 위해
`kubectl exec`과 `kubectl run`을 이용하자.
`kubectl exec`과 `kubectl run`을 이용하자. 먼저, 파드의 호스트네임을 확인한다.
```shell
for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
```
```
web-0
web-1
```
그리고 다음을 실행한다.
```
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh
```
이 명령으로 새로운 셸이 시작된다.
새 셸에서 다음을 실행한다.
```shell
# dns-test 컨테이너 셸에서 이것을 실행한다.
nslookup web-0.nginx
```
출력 결과는 다음과 비슷하다.
```
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
@@ -230,6 +262,8 @@ Name: web-1.nginx
Address 1: 10.244.2.8
```
(이제 `exit` 명령으로 컨테이너 셸을 종료한다.)
파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만
파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나
다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로
@@ -255,12 +289,20 @@ Running과 Ready 상태의 모든 파드들을
```shell
kubectl get pvc -l app=nginx
```
출력 결과는 다음과 비슷하다.
```
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
```
스테이트풀셋 컨트롤러는 2개의 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에
묶인 2개의 퍼시스턴트볼륨클레임을 생성했다. 본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로
스테이트풀셋 컨트롤러는 2개의
{{< glossary_tooltip text="퍼시스턴트볼륨" term_id="persistent-volume" >}}에
묶인 2개의
{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}을 생성했다.
본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로
프로비저닝하도록 설정되었으므로 생성된 퍼시스턴트볼륨도 자동으로 묶인다.
NGINX 웹서버는 기본 색인 파일로
@@ -272,23 +314,23 @@ NGINX 웹서버는 기본 색인 파일로
NGINX 웹서버가 해당 호스트네임을 제공하는지 확인해보자.
```shell
for i in 0 1; do kubectl exec web-$i -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done
for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done
for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done
for i in 0 1; do kubectl exec -it "web-$i" -- curl localhost; done
```
```
web-0
web-1
```
{{< note >}}
위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면
`volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다
위에 curl 명령어로 **403 Forbidden** 아닌 응답을 보려면
다음을 실행해서 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다
([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함).
```shell
for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done
```
`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done`
위에 curl 명령을 재시도하기 전에
위에 `curl` 명령을 재시도하기 전에 위 명령을 실행해야 한다.
{{< /note >}}
첫째 터미널에서 스테이트풀셋의 파드를 감시하자.
@@ -301,6 +343,8 @@ kubectl get pod -w -l app=nginx
```shell
kubectl delete pod -l app=nginx
```
```
pod "web-0" deleted
pod "web-1" deleted
```
@@ -309,6 +353,8 @@ pod "web-1" deleted
```shell
kubectl get pod -w -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-0 0/1 ContainerCreating 0 0s
NAME READY STATUS RESTARTS AGE
@@ -322,7 +368,9 @@ web-1 1/1 Running 0 34s
웹서버에서 자신의 호스트네임을 계속 제공하는지 확인하자.
```
for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
```
```
web-0
web-1
```
@@ -334,6 +382,7 @@ web-1
각각의 퍼시스턴트볼륨은 적절하게 마운트된다.
## 스테이트풀셋 스케일링
스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 `replicas` 필드를 갱신하여 이뤄진다.
[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)이나
[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)을
@@ -352,6 +401,8 @@ kubectl get pods -w -l app=nginx
```shell
kubectl scale sts web --replicas=5
```
```
statefulset.apps/web scaled
```
@@ -360,6 +411,8 @@ statefulset.apps/web scaled
```shell
kubectl get pods -w -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 2h
web-1 1/1 Running 0 2h
@@ -392,18 +445,22 @@ web-4 1/1 Running 0 19s
kubectl get pods -w -l app=nginx
```
다른 터미널에서 `kubectl patch`으로 스테이트풀셋을 뒤로
3개의 레플리카로 스케일링하자.
다른 터미널에서 `kubectl patch`으로 스테이트풀셋을 다시
3개의 레플리카로 스케일링하자.
```shell
kubectl patch sts web -p '{"spec":{"replicas":3}}'
```
```
statefulset.apps/web patched
```
`web-4`와 `web-3`이 Terminating으로 전환되기까지 기다리자.
```
```shell
kubectl get pods -w -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 3h
web-1 1/1 Running 0 3h
@@ -428,6 +485,8 @@ web-3 1/1 Terminating 0 42s
```shell
kubectl get pvc -l app=nginx
```
```
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h
@@ -459,6 +518,8 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO
```shell
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
```
```
statefulset.apps/web patched
```
@@ -467,13 +528,18 @@ statefulset.apps/web patched
```shell
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]'
```
```
statefulset.apps/web patched
```
다른 터미널창에서 스테이트풀셋의 파드를 감시하자.
```shell
kubectl get po -l app=nginx -w
kubectl get pod -l app=nginx -w
```
출력 결과는 다음과 비슷하다.
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 7m
web-1 1/1 Running 0 7m
@@ -512,17 +578,20 @@ web-0 1/1 Running 0 10s
이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에
그것이 Running과 Ready 상태로 전환될 때까지 기다린다.
알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지
다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다.
다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면
복원한다는 것이다.
업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는
이전 버전으로 복원한다.
이런 식으로 컨트롤러는 간헐적인 오류가 발생해도
이전 버전으로 복원한다. 이런 식으로 컨트롤러는 간헐적인 오류가 발생해도
애플리케이션을 계속 건강하게 유지하고
업데이트도 일관되게 유지하려 한다.
컨테이너 이미지를 살펴보기 위해 파드를 가져오자.
```shell
for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
```
```
k8s.gcr.io/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
@@ -531,10 +600,13 @@ k8s.gcr.io/nginx-slim:0.8
스테이트풀셋의 모든 파드가 지금은 이전 컨테이너 이미지를 실행 중이이다.
**팁** 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/<name>`
{{< note >}}
스테이트풀셋의 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/<name>`
명령어도 사용할 수 있다.
{{< /note >}}
#### 단계적으로 업데이트 하기 {#staging-an-update}
`RollingUpdate` 업데이트 전략의 파라미터인 `partition`를 이용하여
스테이트풀셋의 단계적으로 업데이트할 수 있다.
단계적 업데이트는 스테이트풀셋의 모든 파드를 현재 버전으로 유지하면서
@@ -544,6 +616,8 @@ k8s.gcr.io/nginx-slim:0.8
```shell
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
```
```
statefulset.apps/web patched
```
@@ -551,20 +625,26 @@ statefulset.apps/web patched
```shell
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
```
```
statefulset.apps/web patched
```
스테이트풀셋의 파드를 삭제하자.
```shell
kubectl delete po web-2
kubectl delete pod web-2
```
```
pod "web-2" deleted
```
파드가 Running과 Ready 상태가 되기까지 기다리자.
```shell
kubectl get po -l app=nginx -w
kubectl get pod -l app=nginx -w
```
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 4m
web-1 1/1 Running 0 4m
@@ -572,12 +652,13 @@ web-2 0/1 ContainerCreating 0 11s
web-2 1/1 Running 0 18s
```
파드의 컨테이너를 가져오자.
파드의 컨테이너 이미지를 가져오자.
```shell
kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
```
```
k8s.gcr.io/nginx-slim:0.8
```
비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은
@@ -586,6 +667,7 @@ k8s.gcr.io/nginx-slim:0.8
`파티션`보다 작기 때문이다.
#### 카나리(Canary) 롤링 아웃
[위에서](#staging-an-update) 지정한 `partition`값을 차감시키면
변경사항을 테스트하기 위해 카나리 롤아웃을 할 수 있다.
@@ -593,13 +675,17 @@ k8s.gcr.io/nginx-slim:0.8
```shell
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'
```
```
statefulset.apps/web patched
```
`web-2` 파드가 Running과 Ready 상태가 되기까지 기다리자.
```shell
kubectl get po -l app=nginx -w
kubectl get pod -l app=nginx -w
```
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 4m
web-1 1/1 Running 0 4m
@@ -611,6 +697,8 @@ web-2 1/1 Running 0 18s
```shell
kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
```
```
k8s.gcr.io/nginx-slim:0.7
```
@@ -622,14 +710,19 @@ k8s.gcr.io/nginx-slim:0.7
`web-1` 파드를 삭제하자.
```shell
kubectl delete po web-1
kubectl delete pod web-1
```
```
pod "web-1" deleted
```
`web-1` 파드가 Running과 Ready 상태가 되기까지 기다리자.
```shell
kubectl get po -l app=nginx -w
kubectl get pod -l app=nginx -w
```
출력 결과는 다음과 비슷하다.
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 6m
web-1 0/1 Terminating 0 6m
@@ -643,12 +736,13 @@ web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 18s
```
`web-1` 파드의 컨테이너를 가져오자.
`web-1` 파드의 컨테이너 이미지를 가져오자.
```shell
kubectl get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
```
```
k8s.gcr.io/nginx-slim:0.8
```
`web-1` 는 원래 환경설정으로 복원되었는데
@@ -658,6 +752,7 @@ k8s.gcr.io/nginx-slim:0.8
종료되어 원래 환경설정으로 복원된다.
#### 단계적 롤아웃
[카나리 롤아웃](#카나리-canary-롤링-아웃)에서 했던 방법과 비슷하게
분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을
수행할 수 있다. 단계적 롤아웃을 수행하려면
@@ -668,13 +763,18 @@ partition은 현재 `2`이다. partition을 `0`으로 바꾸자.
```shell
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}'
```
```
statefulset.apps/web patched
```
스테이트풀셋의 모든 파드가 Running과 Ready 상태가 되기까지 기다리자.
```shell
kubectl get po -l app=nginx -w
kubectl get pod -l app=nginx -w
```
출력 결과는 다음과 비슷하다.
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 3m
web-1 0/1 ContainerCreating 0 11s
@@ -692,17 +792,19 @@ web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 3s
```
파드의 컨테이너를 가져오자.
스테이트풀셋에 있는 파드의 컨테이너 이미지 상세 정보를 가져오자.
```shell
for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
```
```
k8s.gcr.io/nginx-slim:0.7
k8s.gcr.io/nginx-slim:0.7
k8s.gcr.io/nginx-slim:0.7
```
`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서
`partition`을 `0`으로 이동하여 스테이트풀셋에서 계속해서
업데이트 처리를 하도록 허용하였다.
### 삭제 시 동작
@@ -733,6 +835,8 @@ kubectl get pods -w -l app=nginx
```shell
kubectl delete statefulset web --cascade=false
```
```
statefulset.apps "web" deleted
```
@@ -740,6 +844,8 @@ statefulset.apps "web" deleted
```shell
kubectl get pods -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 6m
web-1 1/1 Running 0 7m
@@ -751,6 +857,8 @@ web-2 1/1 Running 0 5m
```shell
kubectl delete pod web-0
```
```
pod "web-0" deleted
```
@@ -758,6 +866,8 @@ pod "web-0" deleted
```shell
kubectl get pods -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-1 1/1 Running 0 10m
web-2 1/1 Running 0 7m
@@ -777,17 +887,21 @@ kubectl get pods -w -l app=nginx
```shell
kubectl apply -f web.yaml
```
```
statefulset.apps/web created
service/nginx unchanged
```
이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도
nginx 헤드리스 서비스를 생성하려고 했음을 뜻한다.
_nginx_ 헤드리스 서비스를 생성하려고 했음을 뜻한다.
첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보자.
```shell
kubectl get pods -w -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-1 1/1 Running 0 16m
web-2 1/1 Running 0 2m
@@ -813,7 +927,9 @@ web-2 0/1 Terminating 0 3m
다른 관점으로 살펴보자.
```shell
for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
```
```
web-0
web-1
```
@@ -837,6 +953,8 @@ kubectl get pods -w -l app=nginx
```shell
kubectl delete statefulset web
```
```
statefulset.apps "web" deleted
```
첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고
@@ -844,6 +962,8 @@ statefulset.apps "web" deleted
```shell
kubectl get pods -w -l app=nginx
```
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 11m
web-1 1/1 Running 0 27m
@@ -864,12 +984,17 @@ web-1 0/1 Terminating 0 29m
스테이트풀 컨트롤러는 이전 파드가
완전히 종료되기까지 기다린다.
스테이트풀셋과 그 파드를 종속적으로 삭제하는 중에 연관된 헤드리스 서비스를
삭제하지 않음을 주의하자.
{{< note >}}
종속적 삭제는 파드와 함께 스테이트풀셋을 제거하지만,
스테이트풀셋과 관련된 헤드리스 서비스를 삭제하지 않는다.
꼭 `nginx` 서비스를 수동으로 삭제해라.
{{< /note >}}
```shell
kubectl delete service nginx
```
```
service "nginx" deleted
```
@@ -877,6 +1002,8 @@ service "nginx" deleted
```shell
kubectl apply -f web.yaml
```
```
service/nginx created
statefulset.apps/web created
```
@@ -885,22 +1012,30 @@ statefulset.apps/web created
`index.html` 파일 내용을 검색하자.
```shell
for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
```
```
web-0
web-1
```
스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로
다시 생성되고 `web-0`과 `web-1`은 여전히
다시 생성되고 `web-0`과 `web-1`은 계속
각 호스트네임을 제공한다.
최종적으로 `web` 스테이트풀셋과`nginx` 서비스를 삭제한다.
최종적으로 `web` 스테이트풀셋을 삭제한다.
```shell
kubectl delete service nginx
```
```
service "nginx" deleted
```
그리고 `nginx` 서비스를 삭제한다.
```shell
kubectl delete statefulset web
```
```
statefulset "web" deleted
```
@@ -934,13 +1069,15 @@ statefulset "web" deleted
터미널에서 스테이트풀셋의 파드를 감시하자.
```shell
kubectl get po -l app=nginx -w
kubectl get pod -l app=nginx -w
```
다른 터미널에서 매니페스트 안에 스테이트풀셋과 서비스를 생성하자.
```shell
kubectl apply -f web-parallel.yaml
```
```
service/nginx created
statefulset.apps/web created
```
@@ -948,7 +1085,9 @@ statefulset.apps/web created
첫째 터미널에서 실행했던 `kubectl get` 명령어의 출력을 살펴보자.
```shell
kubectl get po -l app=nginx -w
kubectl get pod -l app=nginx -w
```
```
NAME READY STATUS RESTARTS AGE
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
@@ -967,12 +1106,14 @@ web-1 1/1 Running 0 10s
```shell
kubectl scale statefulset/web --replicas=4
```
```
statefulset.apps/web scaled
```
`kubectl get` 명령어를 실행 중인 터미널의 출력을 살펴보자.
```shell
```
web-3 0/1 Pending 0 0s
web-3 0/1 Pending 0 0s
web-3 0/1 Pending 0 7s
@@ -982,18 +1123,24 @@ web-3 1/1 Running 0 26s
```
스테이트풀 컨트롤러는 두 개의 새 파드를 시작하였다.
스테이트풀셋은 두 개의 새 파드를 시작하였다.
두 번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 때까지 기다리지 않는다.
이 터미널을 열어 놓고 다른 터미널에서 `web` 스테이트풀셋을 삭제하자.
## {{% heading "cleanup" %}}
정리의 일환으로 `kubectl` 명령을 실행할 준비가 된 두 개의 터미널이 열려
있어야 한다.
```shell
kubectl delete sts web
# sts는 statefulset의 약자이다.
```
다시 한번 다른 터미널에서 실행 중인 `kubectl get`명령의 출력을 확인해보자.
`kubectl get` 명령으로 해당 파드가 삭제된 것을 확인할 수 있다.
```shell
kubectl get pod -l app=nginx -w
```
```
web-3 1/1 Terminating 0 9m
web-2 1/1 Terminating 0 9m
web-3 1/1 Terminating 0 9m
@@ -1019,7 +1166,7 @@ web-3 0/1 Terminating 0 9m
web-3 0/1 Terminating 0 9m
```
스테이트풀 컨트롤러는 모든 파드를 동시에 삭제한다. 파드를 삭제하기 전에
삭제하는 동안, 스테이트풀셋은 모든 파드를 동시에 삭제한다. 해당 파드를 삭제하기 전에
그 파드의 순서상 후계자를 기다리지 않는다.
`kubectl get` 명령어가 실행된 터미널을 닫고
@@ -1030,12 +1177,11 @@ kubectl delete svc nginx
```
## {{% heading "cleanup" %}}
{{< note >}}
이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한
퍼시스턴트 스토리지 미디어를 삭제해야 한다.
퍼시스턴트 스토리지 미디어도 삭제해야 한다.
모든 스토리지를 반환하도록 환경, 스토리지 설정과
프로비저닝 방법에 따른 단계를 따르자.
{{< /note >}}