First Japanese l10n work for release-1.14 (#16115)
* Translate concepts/workloads/pods/pod/ in Japanese (#13671) * [ja] Copy en/docs/concepts/workloads/pods/pod.md into ja/ * [ja] Translate docs/concepts/workloads/pods/pod/ * [ja] Modify translation of docs/concepts/workloads/pods/pod/ Reflect review - add trailing 'ー' to some technical terms * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * Translated cron-jobs.md in Japanese (#13937) * Translate cron-jobs.md in Japanese (#13392) * Update cron-jobs.md * Create automated-tasks-with-cron-jobs.md in Japanese directory * Fix translation (#13392) * Translate cron-jobs.md in Japanese (#13392) * Update cron-jobs.md * Create automated-tasks-with-cron-jobs.md in Japanese directory * Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory" This reverts commit 739b01489634d749279c38b6ed5b90534bf7d29d. * Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory" This reverts commit 739b01489634d749279c38b6ed5b90534bf7d29d. * Fix conflict (#13392) * Revert "Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory"" This reverts commit c5fc9d93d6d789a13a0a28ec4b85f9e7aeb81e38. * Revert "Revert "Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory""" This reverts commit 095e760c6deb620da548d06a851c8f7ade71a15d. * Fix that as it was pointed out (#13392) * Delete double same sesntence (#13392) * copy includes directory (#14020) * Translate docs/home/_index.md into Japanese (#14068) (#14074) * Translate concepts/overview/components.md into Japanese (#14067) * Translate glossaries used in concepts/overview/components.md into Japanese (#14044) * Translate concepts/overview/components.md into Japanese (#14044) * Translate tasks/run-application/run-single-instance-stateful-application/ in Japanese (#13668) * Translate tasks/run-application/run-single-instance-stateful-application/ in Japanese * Apply suggestions from code review Co-Authored-By: sotoiwa <sotoiwa@gmail.com> * Better translation from code review * Translate tasks/access-application-cluster/service-access-application-cluster/ in Japanese (#13701) * Update fluentd image (#13661) Signed-off-by: ialidzhikov <i.alidjikov@gmail.com> * update zh kubelet-config-file doc (#13495) * update zh kubelet-config-file doc * change kubelet config types address * add space between en words and zh words * revert en version change * correct container hyperlinks in init container (#12387) * correct container hyperlinks in init container * correct zh trans and update anchor inside page * Incorrect details about startingDeadlineSeconds.. (#13530) On this page, the default value of startingDeadlineSeconds is mentioned as 100 seconds which is not true. So removing this statement. * Fix typos (#13376) * add Nokia case study (#13676) * Fix typo in API page (#13687) Associated with #13686 * fix typo in pod-lifecycle (#13689) Asscociated with #13688 * issue 13383 * modify the link part * Revert "modify the link part" This reverts commit 2ae91dca574b54a14d255320721df4313346de28. * Revert "Revert "modify the link part"" This reverts commit e5b80b6258ce2210fc9a4b46e08fb8c000fe6330. * Revert "Revert "Revert "modify the link part""" This reverts commit 427916e7c6c4d6423222ff76b5fd8c12dc913ce1. * Revert "Merge remote-tracking branch 'origin/master' into issue_13383" This reverts commit 98099d805c7377826cb4d84bd0fece0f6362cb40, reversing changes made to 969e7f3f5cf63622e24137a2e374b0ab9e272514. * modify the link part * Translate /concepts/overview/working-with-objects/kubernetes-objects/ into Japanese (#14025) * Translate /concepts/overview/working-with-objects/kubernetes-objects/ into Japanese (#13952) * Apply suggestions to /concepts/overview/working-with-objects/kubernetes-objects/ from code review Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate concepts/overview/working-with-objects/names.md into Japanese (#14066) * Translate content/ja/docs/concepts/overview/working-with-objects/names.md into Japanese * Translate docs/reference/glossary/name.md into Japanese * Translate docs/reference/glossary/uid.md into Japanese * Apply suggestions to concepts/overview/working-with-objects/names.md from review comments * Translate concepts/overview/kubernetes-api.md into Japanese (#14343) * Translate concepts/overview/kubernetes-api.md into Japanese * Update translations for concepts/overview/kubernetes-api.md * Translate overview/working-with-objects/labels.md in Japanese (#14183) (#14319) * Translate overview/working-with-objects/labels.md in Japanese (#14183) * Update translations for concepts/overview/working-with-objects/labels.md. * Translate concepts/workloads/pods/pod-overview/ in Japanese (#14426) (#14494) * Translate concepts/workloads/pods/pod-overview/ in Japanese (#14426) * Update translation for concepts/workloads/pods/pod-overview.md. * Translate overview/working-with-objects/field-selectors.md in Japanese (#14350) (#14535) * Translate overview/working-with-objects/field-selectors.md in Japanese (#14350) * Update translations for concepts/overview/working-with-objects/field-selectors.md. * Update translation for concepts/overview/working-with-objects/field-selectors.md * Translate overview/working-with-objects/common-labels/ in Japanese (#14397) (#14403) * Translate overview/working-with-objects/common-labels/ in Japanese (#14397) * Update translation for concepts/overview/working-with-objects/common-labels.md * Translate concepts/storage/volume-snapshot-classes/ in Japanese (#14846) (#14849) * ja-trans: tasks/run-application/run-stateless-application-deployment/ (#14955) * ja-trans: tasks/run-application/run-stateless-application-deployment/ * modify "exploring" translation * ja-trans: concepts/containers/container-environment-variables/ (#14116) * ja-trans: concepts/containers/container-environment-variables/ * removed redundant expressions * ja-trans: Translate tasks/debug-application-cluster/get-shell-running… (#14146) * ja-trans: Translate tasks/debug-application-cluster/get-shell-running-container/ #13381 * Update content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md Fix typo Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * ja-trans: concepts/containers/container-lifecycle-hooks/ (#14169) * ja-trans: tasks/debug-application-cluster/debug-init-containers/ (#14488) * ja-trans: tasks/debug-application-cluster/debug-init-containers/ * modified traslation of should * Translate concepts/workloads/controllers/replicaset/ in Japanese (#14634) (#14641) * Translate concepts/workloads/controllers/replicaset.md in Japanese (#14634) * Improve japanese translation in concepts/workloads/controllers/replicaset.md (#14634) * Improve japanese translation in concepts/workloads/controllers/replicaset.md (#14634) * Translate concepts/overview/working-with-objects/annotations/ in Japanese (#13382) (#14396) * Translate overview/working-with-objects/annotations.md in Japanese (#13382) * Delete a empty line in concepts/overview/working-with-objects/annotations.md (#13382) * Update translation for concepts/overview/working-with-objects/anotations.md * ja-trans: tasks/run-application/scale-stateful-set/ (#15289) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/run-application/scale-stateful-set/ * Update content/ja/docs/tasks/run-application/scale-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/scale-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * added postpositional particle * ja-trans: tasks/debug-application-cluster/debug-stateful-set/ (#15282) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/debug-application-cluster/debug-stateful-set/ * ja-trans: tasks/debug-application-cluster/determine-reason-pod-failure/ (#14939) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/debug-application-cluster/determine-reason-pod-failure/ * ja-trans: unify the ending of sentences * follow the master branch update * reflect a suggestion and modify translation of container * ja-trans: tasks/run-application/delete-stateful-set/ (#15293) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/run-application/delete-stateful-set/ * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * modified traslation of backing * ja-trans: tasks/configure-pod-container/attach-handler-lifecycle-event/ (#14328) * Translate overview/working-with-objects/namespaces.md in Japanese (#14045) (#14161) * Translate overview/working-with-objects/namespaces.md in Japanese (#14045) * Update translations for concepts/overview/working-with-objects/namespaces.md * ja-trans: fix Japanese Translation in concepts/overview/working-with-objects/namespaces.md (#14045) * ja-trans: includes/default-storage-class-prereqs.md (#15376) * ja-trans: includes/default-storage-class-prereqs.md * Update content/ja/includes/default-storage-class-prereqs.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate tasks/run-application/run-replicated-stateful-application/ in Japanese (#15368) * Translate tasks/run-application/run-replicated-stateful-application/ in Japanese * add a base document in english * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * small fixs 「複製」という言葉を使わず「レプリケーション」と「クローン」に使い分けるように変更。 「ステートフルなアプリケーション」を「ステートフルアプリケーション」に変更。 * small fix * Translate concepts/workloads/pods/init-containers.md in Japanese (#14543) (#14576) * Translate concepts/workloads/pods/init-containers.md in Japanese (#14543) * Improve japanese translation in concepts/workloads/pods/init-containers.md (#14543) * Add new line in ja/concepts/workloads/pods/init-containers.md (#14543) * Add new line in ja/concepts/workloads/pods/init-containers.md (#14543) * translate contribute/_index.md to japanese. (#15406) * translate contribute/_index.md to japanese. * trim spaces. * Add missing translation. * Translate concepts/workloads/controllers/daemonset/ in Japanese #14761 (#14767) * Translate concepts/workloads/controllers/daemonset/ in Japanese (#14761) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/daemonset.md (#14767) * Translate concepts/workloads/controllers/garbage-collection/ in Japanese (#14718) (#14720) * Translate concepts/workloads/controllers/garbage-collection/ in Japanese (#14718) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/garbage-collection.md (#14718) * Translate concepts/workloads/pods/podpreset/ in Japanese (#14544) (#14581) * Translate concepts/workloads/pods/podpreset.md in Japanese (#14544) * Update translation for concepts/workloads/pods/podpreset.md. * ja-trans: Improve Japanese translation in concepts/workloads/pods/podpreset (#14544) * ja-trans: Improve Japanese translation in concepts/workloads/pods/podpreset (#14544) * ja-trans: Delete translated sentence in concepts/workloads/pods/podpreset (#14544) * ja-trans: Delete duplicated sentence in concepts/workloads/pods/podpreset (#14544) * Translate concepts/containers/runtime-class/ in Japanese (#14670) (#14673) * Translate concepts/containers/runtime-class.md in Japanese (#14670) * ja-trans: Improve Japanese translation in concepts/containers/runtime-class.md (#14670) * Translate concepts/services-networking/dns-pod-service/ in Japanese #14777 (#14805) * Translate concepts/services-networking/dns-pod-service/ in Japanese (#14777) * ja-trans: Improve Japanese translation in concepts/services-networking/dns-pod-service.md (#14777) * Translate concepts/workloads/controllers/statefulset/ in Japanese #14679 (#14696) * Translate concepts/workloads/controllers/statefulset.md in Japanese (#14679) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/statefulset.md (#14679) * ja-trans: Improve some Japanese translation in concepts/workloads/controllers/statefulset.md (#14679) * ja-trans: Improve some titles in concepts/workloads/controllers/statefulset.md (#14679) * ja-trans: Improve some Japanese translations in concepts/workloads/controllers/statefulset.md (#14679) * Translate concepts/workloads/controllers/ttlafterfinished/ in Japanese #14734 (#14735) * Translate concepts/workloads/controllers/ttlafterfinished/ in Japanese (#14734) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/ttlafterfinished.md (#14734) * ja-trans: Delete some Japanese words in concepts/workloads/controllers/ttlafterfinished.md (#14734) * ja-trans: Fix typo in concepts/workloads/controllers/ttlafterfinished.md (#14734) * Translate concepts/storage/dynamic-provisioning/ in Japanese #14847 (#14916) * Translate concepts/storage/dynamic-provisioning/ in Japanese (#14847) * ja-trans: Improve Japanese translation in concepts/storage/dynamic-provisioning.md (#14847) * ja-trans: Improve some Japanese translation in concepts/storage/dynamic-provisioning.md (#14847) * ja-trans: Improve some Japanese translations in concepts/storage/dynamic-provisioning.md (#14847)
This commit is contained in:
Takuya Tokuda
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
6c4a4d8152
commit
abde921399
+142
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: Serviceを利用したクラスター内のアプリケーションへのアクセス
|
||||
content_template: templates/tutorial
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
ここでは、クラスター内で稼働しているアプリケーションに外部からアクセスするために、KubernetesのServiceオブジェクトを作成する方法を紹介します。
|
||||
例として、2つのインスタンスから成るアプリケーションへのロードバランシングを扱います。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
* 2つのHellow Worldアプリケーションを稼働させる。
|
||||
* Nodeのポートを公開するServiceオブジェクトを作成する。
|
||||
* 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
## 2つのPodから成るアプリケーションのServiceを作成
|
||||
|
||||
1. クラスタでHello Worldアプリケーションを稼働させます:
|
||||
```shell
|
||||
kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080
|
||||
```
|
||||
このコマンドは
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
オブジェクトとそれに紐付く
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの
|
||||
[Pod](/docs/concepts/workloads/pods/pod/)
|
||||
から構成されます。
|
||||
|
||||
1. Deploymentの情報を表示します:
|
||||
```shell
|
||||
kubectl get deployments hello-world
|
||||
kubectl describe deployments hello-world
|
||||
```
|
||||
|
||||
1. ReplicaSetオブジェクトの情報を表示します:
|
||||
```shell
|
||||
kubectl get replicasets
|
||||
kubectl describe replicasets
|
||||
```
|
||||
|
||||
1. Deploymentを公開するServiceオブジェクトを作成します:
|
||||
```shell
|
||||
kubectl expose deployment hello-world --type=NodePort --name=example-service
|
||||
```
|
||||
|
||||
1. Serviceに関する情報を表示します:
|
||||
```shell
|
||||
kubectl describe services example-service
|
||||
```
|
||||
出力例は以下の通りです:
|
||||
```shell
|
||||
Name: example-service
|
||||
Namespace: default
|
||||
Labels: run=load-balancer-example
|
||||
Annotations: <none>
|
||||
Selector: run=load-balancer-example
|
||||
Type: NodePort
|
||||
IP: 10.32.0.16
|
||||
Port: <unset> 8080/TCP
|
||||
TargetPort: 8080/TCP
|
||||
NodePort: <unset> 31496/TCP
|
||||
Endpoints: 10.200.1.4:8080,10.200.2.5:8080
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```
|
||||
NodePortの値を記録しておきます。上記の例では、31496です。
|
||||
|
||||
1. Hello Worldアプリーションが稼働しているPodを表示します:
|
||||
```shell
|
||||
kubectl get pods --selector="run=load-balancer-example" --output=wide
|
||||
```
|
||||
出力例は以下の通りです:
|
||||
```shell
|
||||
NAME READY STATUS ... IP NODE
|
||||
hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1
|
||||
hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2
|
||||
```
|
||||
1. Hello World podが稼働するNodeのうち、いずれか1つのパブリックIPアドレスを確認します。
|
||||
確認方法は、使用している環境により異なります。
|
||||
例として、Minikubeの場合は`kubectl cluster-info`、Google Compute Engineの場合は`gcloud compute instances list`によって確認できます。
|
||||
|
||||
1. 選択したノード上で、NodePortの値でのTCP通信を許可するファイヤーウォールを作成します。
|
||||
NodePortの値が31568の場合、31568番のポートを利用したTCP通信を許可するファイヤーウォールを作成します。
|
||||
クラウドプロバイダーによって設定方法が異なります。
|
||||
|
||||
1. Hello World applicationにアクセスするために、Nodeのアドレスとポート番号を使用します:
|
||||
```shell
|
||||
curl http://<public-node-ip>:<node-port>
|
||||
```
|
||||
ここで `<public-node-ip>` はNodeのパブリックIPアドレス、
|
||||
`<node-port>` はNodePort Serviceのポート番号の値を表しています。
|
||||
リクエストが成功すると、下記のメッセージが表示されます:
|
||||
```shell
|
||||
Hello Kubernetes!
|
||||
```
|
||||
|
||||
## service configuration fileの利用
|
||||
|
||||
`kubectl expose`コマンドの代わりに、
|
||||
[service configuration file](/docs/concepts/services-networking/service/)
|
||||
を使用してServiceを作成することもできます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture cleanup %}}
|
||||
|
||||
Serviceを削除するには、以下のコマンドを実行します:
|
||||
|
||||
kubectl delete services example-service
|
||||
|
||||
Hello Worldアプリケーションが稼働しているDeployment、ReplicaSet、Podを削除するには、以下のコマンドを実行します:
|
||||
|
||||
kubectl delete deployment hello-world
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
詳細は
|
||||
[serviceを利用してアプリケーションと接続する](/docs/concepts/services-networking/connect-applications-service/)
|
||||
を確認してください。
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: コンテナライフサイクルイベントへのハンドラー紐付け
|
||||
content_template: templates/task
|
||||
weight: 140
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、コンテナのライフサイクルイベントにハンドラーを紐付けする方法を説明します。KubernetesはpostStartとpreStopイベントをサポートしています。Kubernetesはコンテナの起動直後にpostStartイベントを送信し、コンテナの終了直前にpreStopイベントを送信します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## postStartハンドラーとpreStopハンドラーを定義する
|
||||
|
||||
この課題では、1つのコンテナを持つPodを作成します。コンテナには、postStartイベントとpreStopイベントのハンドラーがあります。
|
||||
|
||||
これがPodの設定ファイルです:
|
||||
|
||||
{{< codenew file="pods/lifecycle-events.yaml" >}}
|
||||
|
||||
設定ファイルでは、postStartコマンドが`message`ファイルをコンテナの`/usr/share`ディレクトリに書き込むことがわかります。preStopコマンドはnginxを適切にシャットダウンします。これは、障害のためにコンテナが終了している場合に役立ちます。
|
||||
|
||||
Podを作成します:
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/pods/lifecycle-events.yaml
|
||||
|
||||
Pod内のコンテナが実行されていることを確認します:
|
||||
|
||||
kubectl get pod lifecycle-demo
|
||||
|
||||
Pod内で実行されているコンテナでシェルを実行します:
|
||||
|
||||
kubectl exec -it lifecycle-demo -- /bin/bash
|
||||
|
||||
シェルで、`postStart`ハンドラーが`message`ファイルを作成したことを確認します:
|
||||
|
||||
root@lifecycle-demo:/# cat /usr/share/message
|
||||
|
||||
出力は、postStartハンドラーによって書き込まれたテキストを示しています。
|
||||
|
||||
Hello from the postStart handler
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## 議論
|
||||
|
||||
コンテナが作成された直後にKubernetesはpostStartイベントを送信します。
|
||||
ただし、コンテナのエントリーポイントが呼び出される前にpostStartハンドラーが呼び出されるという保証はありません。postStartハンドラーはコンテナのコードに対して非同期的に実行されますが、postStartハンドラーが完了するまでコンテナのKubernetesによる管理はブロックされます。postStartハンドラーが完了するまで、コンテナのステータスはRUNNINGに設定されません。
|
||||
|
||||
Kubernetesはコンテナが終了する直前にpreStopイベントを送信します。
|
||||
コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/docs/user-guide/pods/#termination-of-pods)を参照してください。
|
||||
|
||||
{{< note >}}
|
||||
Kubernetesは、Podが *終了* したときにのみpreStopイベントを送信します。
|
||||
これは、Podが *完了* したときにpreStopフックが呼び出されないことを意味します。
|
||||
この制限は[issue #55087](https://github.com/kubernetes/kubernetes/issues/55807)で追跡されています。
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [コンテナライフサイクルフック](/docs/concepts/containers/container-lifecycle-hooks/)の詳細
|
||||
* [Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)の詳細
|
||||
|
||||
|
||||
### 参照
|
||||
|
||||
* [ライフサイクル](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lifecycle-v1-core)
|
||||
* [コンテナ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)の`terminationGracePeriodSeconds`
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
title: Init Containerのデバッグ
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、Init Containerの実行に関連する問題を調査する方法を説明します。以下のコマンドラインの例では、Podを`<pod-name>`、Init Containerを`<init-container-1>`および`<init-container-2>`として参照しています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* [Init Container](/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。
|
||||
* [Init Containerを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Init Containerのステータスを確認する
|
||||
|
||||
Podのステータスを表示します:
|
||||
|
||||
```shell
|
||||
kubectl get pod <pod-name>
|
||||
```
|
||||
|
||||
たとえば、`Init：1/2`というステータスは、2つのInit Containerのうちの1つが正常に完了したことを示します。
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
<pod-name> 0/1 Init:1/2 0 7s
|
||||
```
|
||||
|
||||
ステータス値とその意味の例については、[Podのステータスを理解する](#understanding-pod-status)を参照してください。
|
||||
|
||||
## Init Containerの詳細を取得する
|
||||
|
||||
Init Containerの実行に関する詳細情報を表示します:
|
||||
|
||||
```shell
|
||||
kubectl describe pod <pod-name>
|
||||
```
|
||||
|
||||
たとえば、2つのInit Containerを持つPodでは、次のように表示されます:
|
||||
|
||||
```
|
||||
Init Containers:
|
||||
<init-container-1>:
|
||||
Container ID: ...
|
||||
...
|
||||
State: Terminated
|
||||
Reason: Completed
|
||||
Exit Code: 0
|
||||
Started: ...
|
||||
Finished: ...
|
||||
Ready: True
|
||||
Restart Count: 0
|
||||
...
|
||||
<init-container-2>:
|
||||
Container ID: ...
|
||||
...
|
||||
State: Waiting
|
||||
Reason: CrashLoopBackOff
|
||||
Last State: Terminated
|
||||
Reason: Error
|
||||
Exit Code: 1
|
||||
Started: ...
|
||||
Finished: ...
|
||||
Ready: False
|
||||
Restart Count: 3
|
||||
...
|
||||
```
|
||||
|
||||
また、Pod Specの`status.initContainerStatuses`フィールドを読むことでプログラムでInit Containerのステータスにアクセスすることもできます。:
|
||||
|
||||
|
||||
```shell
|
||||
kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
|
||||
```
|
||||
|
||||
|
||||
このコマンドは生のJSONで上記と同じ情報を返します。
|
||||
|
||||
## Init Containerのログにアクセスする
|
||||
|
||||
ログにアクセスするには、Init Container名とPod名を渡します。
|
||||
|
||||
```shell
|
||||
kubectl logs <pod-name> -c <init-container-2>
|
||||
```
|
||||
|
||||
シェルスクリプトを実行するInit Containerは、実行時にコマンドを出力します。たとえば、スクリプトの始めに`set -x`を実行することでBashで同じことができます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## Podのステータスを理解する
|
||||
|
||||
`Init：`で始まるPodステータスはInit Containerの実行ステータスを要約します。以下の表は、Init Containerのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。
|
||||
|
||||
ステータス | 意味
|
||||
------ | -------
|
||||
`Init:N/M` | Podは`M`個のInit Containerを持ち、これまでに`N`個完了しました。
|
||||
`Init:Error` | Init Containerが実行に失敗しました。
|
||||
`Init:CrashLoopBackOff` | Init Containerが繰り返し失敗しました。
|
||||
`Pending` | PodはまだInit Containerの実行を開始していません。
|
||||
`PodInitializing` or `Running` | PodはすでにInit Containerの実行を終了しています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: StatefulSetのデバッグ
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このタスクでは、StatefulSetをデバッグする方法を説明します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* Kubernetesクラスターが必要です。また、kubectlコマンドラインツールがクラスターと通信するように設定されている必要があります。
|
||||
* 調べたいStatefulSetを実行しておきましょう。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## StatefulSetのデバッグ
|
||||
|
||||
StatefulSetに属し、ラベル`app=myapp`が設定されているすべてのPodを一覧表示するには、以下のコマンドを利用できます。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=myapp
|
||||
```
|
||||
|
||||
Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/manage-stateful-set/delete-pods/)タスクを参照してください。
|
||||
[Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
[Init Containerのデバッグ](/docs/tasks/debug-application-cluster/debug-init-containers/)の詳細
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
title: Pod障害の原因を特定する
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、コンテナ終了メッセージの読み書き方法を説明します。
|
||||
|
||||
終了メッセージは、致命的なイベントに関する情報を、ダッシュボードや監視ソフトウェアなどのツールで簡単に取得して表示できる場所にコンテナが書き込むための手段を提供します。 ほとんどの場合、終了メッセージに入力した情報も一般的な[Kubernetesログ](/docs/concepts/cluster-administration/logging/)に書き込まれるはずです。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 終了メッセージの書き込みと読み取り
|
||||
|
||||
この課題では、1つのコンテナを実行するPodを作成します。
|
||||
設定ファイルには、コンテナの開始時に実行されるコマンドを指定します。
|
||||
|
||||
{{< codenew file="debug/termination.yaml" >}}
|
||||
|
||||
1. YAML設定ファイルに基づいてPodを作成します:
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/debug/termination.yaml
|
||||
|
||||
YAMLファイルの`cmd`フィールドと`args`フィールドで、コンテナが10秒間スリープしてから`/dev/termination-log`ファイルに「Sleep expired」と書いているのがわかります。コンテナが「Sleep expired」メッセージを書き込んだ後、コンテナは終了します。
|
||||
|
||||
1. Podに関する情報を表示します:
|
||||
|
||||
kubectl get pod termination-demo
|
||||
|
||||
Podが実行されなくなるまで、上記のコマンドを繰り返します。
|
||||
|
||||
1. Podに関する詳細情報を表示します:
|
||||
|
||||
kubectl get pod termination-demo --output=yaml
|
||||
|
||||
出力には「Sleep expired」メッセージが含まれています:
|
||||
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
...
|
||||
lastState:
|
||||
terminated:
|
||||
containerID: ...
|
||||
exitCode: 0
|
||||
finishedAt: ...
|
||||
message: |
|
||||
Sleep expired
|
||||
...
|
||||
|
||||
1. Goテンプレートを使用して、終了メッセージのみが含まれるように出力をフィルタリングします:
|
||||
|
||||
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
|
||||
|
||||
## 終了メッセージのカスタマイズ
|
||||
|
||||
Kubernetesは、コンテナの`terminationMessagePath`フィールドで指定されている終了メッセージファイルから終了メッセージを取得します。デフォルト値は`/dev/termination-log`です。このフィールドをカスタマイズすることで、Kubernetesに別のファイルを使うように指示できます。Kubernetesは指定されたファイルの内容を使用して、成功と失敗の両方についてコンテナのステータスメッセージを入力します。
|
||||
|
||||
次の例では、コンテナはKubernetesが取得するために終了メッセージを`/tmp/my-log`に書き込みます:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: msg-path-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: msg-path-demo-container
|
||||
image: debian
|
||||
terminationMessagePath: "/tmp/my-log"
|
||||
```
|
||||
|
||||
さらに、ユーザーは追加のカスタマイズをするためにContainerの`terminationMessagePolicy`フィールドを設定できます。このフィールドのデフォルト値は`File`です。これは、終了メッセージが終了メッセージファイルからのみ取得されることを意味します。`terminationMessagePolicy`を`FallbackToLogsOnError`に設定することで、終了メッセージファイルが空でコンテナがエラーで終了した場合に、コンテナログ出力の最後のチャンクを使用するようにKubernetesに指示できます。ログ出力は、2048バイトまたは80行のどちらか小さい方に制限されています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [コンテナ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)の`terminationMessagePath`フィールド参照
|
||||
* [ログ取得](/docs/concepts/cluster-administration/logging/)について
|
||||
* [Goテンプレート](https://golang.org/pkg/text/template/)について
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: 実行中のコンテナへのシェルを取得する
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
このページは`kubectl exec`を使用して実行中のコンテナへのシェルを取得する方法を説明します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## コンテナへのシェルの取得
|
||||
|
||||
このエクササイズでは、1つのコンテナを持つPodを作成します。
|
||||
コンテナはnginxのイメージを実行します。以下がそのPodの設定ファイルです:
|
||||
|
||||
{{< codenew file="application/shell-demo.yaml" >}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/shell-demo.yaml
|
||||
```
|
||||
|
||||
コンテナが実行中であることを確認します:
|
||||
|
||||
```shell
|
||||
kubectl get pod shell-demo
|
||||
```
|
||||
|
||||
実行中のコンテナへのシェルを取得します:
|
||||
|
||||
```shell
|
||||
kubectl exec -it shell-demo -- /bin/bash
|
||||
```
|
||||
{{< note >}}
|
||||
|
||||
ダブルダッシュの記号 "--" はコマンドに渡す引数とkubectlの引数を分離します。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
シェル内で、ルートディレクトリーのファイル一覧を表示します:
|
||||
|
||||
```shell
|
||||
root@shell-demo:/# ls /
|
||||
```
|
||||
|
||||
シェル内で、他のコマンドを試しましょう。以下がいくつかの例です:
|
||||
|
||||
```shell
|
||||
root@shell-demo:/# ls /
|
||||
root@shell-demo:/# cat /proc/mounts
|
||||
root@shell-demo:/# cat /proc/1/maps
|
||||
root@shell-demo:/# apt-get update
|
||||
root@shell-demo:/# apt-get install -y tcpdump
|
||||
root@shell-demo:/# tcpdump
|
||||
root@shell-demo:/# apt-get install -y lsof
|
||||
root@shell-demo:/# lsof
|
||||
root@shell-demo:/# apt-get install -y procps
|
||||
root@shell-demo:/# ps aux
|
||||
root@shell-demo:/# ps aux | grep nginx
|
||||
```
|
||||
|
||||
## nginxのルートページへの書き込み
|
||||
|
||||
Podの設定ファイルを再度確認します。Podは`emptyDir`ボリュームを持ち、
|
||||
コンテナは`/usr/share/nginx/html`ボリュームをマウントします。
|
||||
|
||||
シェル内で、`/usr/share/nginx/html`ディレクトリに`index.html`を作成します。
|
||||
|
||||
```shell
|
||||
root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html
|
||||
```
|
||||
|
||||
シェル内で、nginxサーバーにGETリクエストを送信します:
|
||||
|
||||
```shell
|
||||
root@shell-demo:/# apt-get update
|
||||
root@shell-demo:/# apt-get install curl
|
||||
root@shell-demo:/# curl localhost
|
||||
```
|
||||
|
||||
出力に`index.html`ファイルに書き込んだ文字列が表示されます:
|
||||
|
||||
```shell
|
||||
Hello shell demo
|
||||
```
|
||||
|
||||
シェルを終了する場合、`exit`を入力します。
|
||||
|
||||
## コンテナ内での各コマンドの実行
|
||||
|
||||
シェルではない通常のコマンドウインドウ内で、実行中のコンテナの環境変数の一覧を表示します:
|
||||
|
||||
```shell
|
||||
kubectl exec shell-demo env
|
||||
```
|
||||
|
||||
他のコマンドを試します。以下がいくつかの例です:
|
||||
|
||||
```shell
|
||||
kubectl exec shell-demo ps aux
|
||||
kubectl exec shell-demo ls /
|
||||
kubectl exec shell-demo cat /proc/1/mounts
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## Podが1つ以上のコンテナを持つ場合にシェルを開く
|
||||
|
||||
Podが1つ以上のコンテナを持つ場合、`--container`か`-c`を使用して、`kubectl exec`コマンド内でコンテナを指定します。
|
||||
例えば、my-podという名前のPodがあり、そのPodがmain-appとhelper-appという2つのコンテナを持つとします。
|
||||
以下のコマンドはmain-appのコンテナへのシェルを開きます。
|
||||
|
||||
```shell
|
||||
kubectl exec -it my-pod --container main-app -- /bin/bash
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: StatefulSetの削除
|
||||
content_template: templates/task
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このタスクでは、StatefulSetを削除する方法を説明します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* このタスクは、クラスター上で、StatefulSetで表現されるアプリケーションが実行されていることを前提としています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## StatefulSetの削除
|
||||
|
||||
Kubernetesで他のリソースを削除するのと同じ方法でStatefulSetを削除することができます。つまり、`kubectl delete`コマンドを使い、StatefulSetをファイルまたは名前で指定します。
|
||||
|
||||
```shell
|
||||
kubectl delete -f <file.yaml>
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl delete statefulsets <statefulset-name>
|
||||
```
|
||||
|
||||
StatefulSet自体が削除された後で、関連するヘッドレスサービスを個別に削除する必要があるかもしれません。
|
||||
|
||||
```shell
|
||||
kubectl delete service <service-name>
|
||||
```
|
||||
|
||||
kubectlを使ってStatefulSetを削除すると0にスケールダウンされ、すべてのPodが削除されます。PodではなくStatefulSetだけを削除したい場合は、`--cascade=false`を使用してください。
|
||||
|
||||
```shell
|
||||
kubectl delete -f <file.yaml> --cascade=false
|
||||
```
|
||||
|
||||
`--cascade=false`を`kubectl delete`に渡すことで、StatefulSetオブジェクト自身が削除された後でも、StatefulSetによって管理されていたPodは残ります。Podに`app=myapp`というラベルが付いている場合は、次のようにして削除できます:
|
||||
|
||||
```shell
|
||||
kubectl delete pods -l app=myapp
|
||||
```
|
||||
|
||||
### 永続ボリューム
|
||||
|
||||
StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/docs/concepts/workloads/pods/pod/#termination-of-pods)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。
|
||||
|
||||
{{< note >}}
|
||||
データを損失する可能性があるため、PVCを削除するときは注意してください。
|
||||
{{< /note >}}
|
||||
|
||||
### StatefulSetの完全削除
|
||||
|
||||
関連付けられたPodを含むStatefulSet内のすべてのものを単純に削除するには、次のような一連のコマンドを実行します:
|
||||
|
||||
```shell
|
||||
grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
|
||||
kubectl delete statefulset -l app=myapp
|
||||
sleep $grace
|
||||
kubectl delete pvc -l app=myapp
|
||||
|
||||
```
|
||||
|
||||
上の例では、Podは`app=myapp`というラベルを持っています。必要に応じてご利用のラベルに置き換えてください。
|
||||
|
||||
### StatefulSet Podの強制削除
|
||||
|
||||
StatefulSet内の一部のPodが長期間`Terminating`または`Unknown`状態のままになっていることが判明した場合は、手動でapiserverからPodを強制的に削除する必要があります。これは潜在的に危険な作業です。詳細は[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)の詳細
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,490 @@
|
||||
---
|
||||
title: レプリカを持つステートフルアプリケーションを実行する
|
||||
content_template: templates/tutorial
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、[StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
コントローラーを使用して、レプリカを持つステートフルアプリケーションを実行する方法を説明します。
|
||||
ここでの例は、非同期レプリケーションを行う複数のスレーブを持つ、単一マスターのMySQLです。
|
||||
|
||||
**この例は本番環境向けの構成ではない**ことに注意してください。
|
||||
具体的には、MySQLの設定が安全ではないデフォルトのままとなっています。
|
||||
これはKubernetesでステートフルアプリケーションを実行するための一般的なパターンに焦点を当てるためです。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* {{< include "default-storage-class-prereqs.md" >}}
|
||||
* このチュートリアルは、あなたが[PersistentVolume](/docs/concepts/storage/persistent-volumes/)
|
||||
と[StatefulSet](/docs/concepts/workloads/controllers/statefulset/)、
|
||||
さらには[Pod](/docs/concepts/workloads/pods/pod/)、
|
||||
[Service](/docs/concepts/services-networking/service/)、
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)などの
|
||||
他のコアな概念に精通していることを前提としています。
|
||||
* MySQLに関する知識は記事の理解に役立ちますが、
|
||||
このチュートリアルは他のシステムにも役立つ一般的なパターンを提示することを目的としています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
* StatefulSetコントローラーを使用して、レプリカを持つMySQLトポロジーをデプロイします。
|
||||
* MySQLクライアントトラフィックを送信します。
|
||||
* ダウンタイムに対する耐性を観察します。
|
||||
* StatefulSetをスケールアップおよびスケールダウンします。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
## MySQLをデプロイする
|
||||
|
||||
このMySQLのデプロイの例は、1つのConfigMap、2つのService、および1つのStatefulSetから構成されます。
|
||||
|
||||
### ConfigMap
|
||||
|
||||
次のYAML設定ファイルからConfigMapを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
|
||||
```
|
||||
|
||||
{{< codenew file="application/mysql/mysql-configmap.yaml" >}}
|
||||
|
||||
このConfigMapは、MySQLマスターとスレーブの設定を独立して制御するために、
|
||||
それぞれの`my.cnf`を上書きする内容を提供します。
|
||||
この場合、マスターはスレーブにレプリケーションログを提供するようにし、
|
||||
スレーブはレプリケーション以外の書き込みを拒否するようにします。
|
||||
|
||||
ConfigMap自体に特別なことはありませんが、ConfigMapの各部分は異なるPodに適用されます。
|
||||
各Podは、StatefulSetコントローラーから提供される情報に基づいて、
|
||||
初期化時にConfigMapのどの部分を見るかを決定します。
|
||||
|
||||
### Services
|
||||
|
||||
以下のYAML設定ファイルからServiceを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
|
||||
```
|
||||
|
||||
{{< codenew file="application/mysql/mysql-services.yaml" >}}
|
||||
|
||||
ヘッドレスサービスは、StatefulSetコントローラーが
|
||||
StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。
|
||||
この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスタの
|
||||
同じ名前空間内の他のPodは、`<pod-name>.mysql`を名前解決することでPodにアクセスできます。
|
||||
|
||||
`mysql-read`と呼ばれるクライアントサービスは、独自のクラスタIPを持つ通常のServiceであり、
|
||||
Ready状態のすべてのMySQL Podに接続を分散します。
|
||||
Serviceのエンドポイントには、MySQLマスターとすべてのスレーブが含まれる可能性があります。
|
||||
|
||||
読み込みクエリーのみが、負荷分散されるクライアントサービスを使用できることに注意してください。
|
||||
MySQLマスターは1つしかいないため、クライアントが書き込みを実行するためには、
|
||||
(ヘッドレスサービス内のDNSエントリーを介して)MySQLのマスターPodに直接接続する必要があります。
|
||||
|
||||
### StatefulSet
|
||||
|
||||
最後に、次のYAML設定ファイルからStatefulSetを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
|
||||
```
|
||||
|
||||
{{< codenew file="application/mysql/mysql-statefulset.yaml" >}}
|
||||
|
||||
次のコマンドを実行して起動の進行状況を確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=mysql --watch
|
||||
```
|
||||
|
||||
しばらくすると、3つのPodすべてがRunning状態になるはずです。
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mysql-0 2/2 Running 0 2m
|
||||
mysql-1 2/2 Running 0 1m
|
||||
mysql-2 2/2 Running 0 1m
|
||||
```
|
||||
|
||||
**Ctrl+C**を押してウォッチをキャンセルします。
|
||||
起動が進行しない場合は、[始める前に](#始める前に)で説明されているように、
|
||||
PersistentVolumeの動的プロビジョニング機能が有効になっていることを確認してください。
|
||||
|
||||
このマニフェストでは、StatefulSetの一部としてステートフルなPodを管理するためにさまざまな手法を使用しています。
|
||||
次のセクションでは、これらの手法のいくつかに焦点を当て、StatefulSetがPodを作成するときに何が起こるかを説明します。
|
||||
|
||||
## ステートフルなPodの初期化を理解する
|
||||
|
||||
StatefulSetコントローラーは、序数インデックスの順にPodを一度に1つずつ起動します。
|
||||
各PodがReady状態を報告するまで待機してから、その次のPodの起動が開始されます。
|
||||
|
||||
さらに、コントローラーは各Podに `<statefulset-name>-<ordinal-index>`という形式の一意で不変の名前を割り当てます。
|
||||
この例の場合、Podの名前は`mysql-0`、`mysql-1`、そして`mysql-2`となります。
|
||||
|
||||
上記のStatefulSetマニフェスト内のPodテンプレートは、これらのプロパティーを利用して、
|
||||
MySQLレプリケーションの起動を順序正しく実行します。
|
||||
|
||||
### 構成を生成する
|
||||
|
||||
Podスペック内のコンテナを起動する前に、Podは最初に
|
||||
[初期化コンテナ](/docs/concepts/workloads/pods/init-containers/)を定義された順序で実行します。
|
||||
|
||||
最初の初期化コンテナは`init-mysql`という名前で、序数インデックスに基づいて特別なMySQL設定ファイルを生成します。
|
||||
|
||||
スクリプトは、`hostname`コマンドによって返されるPod名の末尾から抽出することによって、自身の序数インデックスを特定します。
|
||||
それから、序数を(予約された値を避けるために数値オフセット付きで)MySQLの`conf.d`ディレクトリーの`server-id.cnf`というファイルに保存します。
|
||||
これは、StatefulSetコントローラーによって提供される一意で不変のIDを、同じ特性を必要とするMySQLサーバーIDの領域に変換します。
|
||||
|
||||
さらに、`init-mysql`コンテナ内のスクリプトは、`master.cnf`または`slave.cnf`のいずれかを、
|
||||
ConfigMapから内容を`conf.d`にコピーすることによって適用します。
|
||||
このトポロジー例は単一のMySQLマスターと任意の数のスレーブで構成されているため、
|
||||
スクリプトは単に序数の`0`がマスターになるように、それ以外のすべてがスレーブになるように割り当てます。
|
||||
StatefulSetコントローラーによる
|
||||
[デプロイ順序の保証](/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees/)と組み合わせると、
|
||||
スレーブが作成される前にMySQLマスターがReady状態になるため、スレーブはレプリケーションを開始できます。
|
||||
|
||||
### 既存データをクローンする
|
||||
|
||||
一般に、新しいPodがセットにスレーブとして参加するときは、
|
||||
MySQLマスターにはすでにデータがあるかもしれないと想定する必要があります。
|
||||
また、レプリケーションログが期間の先頭まで全て揃っていない場合も想定する必要があります。
|
||||
これらの控えめな仮定は、実行中のStatefulSetのサイズを初期サイズに固定するのではなく、
|
||||
時間の経過とともにスケールアップまたはスケールダウンできるようにするために重要です。
|
||||
|
||||
2番目の初期化コンテナは`clone-mysql`という名前で、スレーブPodが空のPersistentVolumeで最初に起動したときに、
|
||||
クローン操作を実行します。
|
||||
つまり、実行中の別のPodから既存のデータをすべてコピーするので、
|
||||
そのローカル状態はマスターからレプリケーションを開始するのに十分な一貫性があります。
|
||||
|
||||
MySQL自体はこれを行うためのメカニズムを提供していないため、この例ではPercona XtraBackupという人気のあるオープンソースツールを使用しています。
|
||||
クローンの実行中は、ソースとなるMySQLサーバーのパフォーマンスが低下する可能性があります。
|
||||
MySQLマスターへの影響を最小限に抑えるために、スクリプトは各Podに序数インデックスが自分より1低いPodからクローンするように指示します。
|
||||
StatefulSetコントローラーは、`N+1`のPodを開始する前には必ず`N`のPodがReady状態であることを保証するので、この方法が機能します。
|
||||
|
||||
### レプリケーションを開始する
|
||||
|
||||
初期化コンテナが正常に完了すると、通常のコンテナが実行されます。
|
||||
MySQLのPodは実際に`mysqld`サーバーを実行する`mysql`コンテナと、
|
||||
[サイドカー](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
|
||||
として機能する`xtrabackup`コンテナから成ります。
|
||||
|
||||
`xtrabackup`サイドカーはクローンされたデータファイルを見て、
|
||||
スレーブ上でMySQLレプリケーションを初期化する必要があるかどうかを決定します。
|
||||
もし必要がある場合、`mysqld`が準備できるのを待ってから、
|
||||
XtraBackupクローンファイルから抽出されたレプリケーションパラメーターで`CHANGE MASTER TO`と`START SLAVE`コマンドを実行します。
|
||||
|
||||
スレーブがレプリケーションを開始すると、スレーブはMySQLマスターを記憶し、
|
||||
サーバーが再起動した場合または接続が停止した場合に、自動的に再接続します。
|
||||
また、スレーブはその不変のDNS名(`mysql-0.mysql`)でマスターを探すため、
|
||||
再スケジュールされたために新しいPod IPを取得したとしても、自動的にマスターを見つけます。
|
||||
|
||||
最後に、レプリケーションを開始した後、`xtrabackup`コンテナはデータのクローンを要求する他のPodからの接続を待ち受けます。
|
||||
StatefulSetがスケールアップした場合や、次のPodがPersistentVolumeClaimを失ってクローンをやり直す必要がある場合に備えて、
|
||||
このサーバーは無期限に起動したままになります。
|
||||
|
||||
## クライアントトラフィックを送信する
|
||||
|
||||
テストクエリーをMySQLマスター(ホスト名 `mysql-0.mysql`)に送信するには、
|
||||
`mysql:5.7`イメージを使って一時的なコンテナーを実行し、`mysql`クライアントバイナリーを実行します。
|
||||
|
||||
```shell
|
||||
kubectl run mysql-client --image=mysql:5.7 -i --rm --restart=Never --\
|
||||
mysql -h mysql-0.mysql <<EOF
|
||||
CREATE DATABASE test;
|
||||
CREATE TABLE test.messages (message VARCHAR(250));
|
||||
INSERT INTO test.messages VALUES ('hello');
|
||||
EOF
|
||||
```
|
||||
|
||||
Ready状態を報告したいずれかのサーバーにテストクエリーを送信するには、ホスト名`mysql-read`を使用します。
|
||||
|
||||
```shell
|
||||
kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
|
||||
mysql -h mysql-read -e "SELECT * FROM test.messages"
|
||||
```
|
||||
|
||||
次のような出力が得られるはずです。
|
||||
|
||||
```
|
||||
Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
|
||||
+---------+
|
||||
| message |
|
||||
+---------+
|
||||
| hello |
|
||||
+---------+
|
||||
pod "mysql-client" deleted
|
||||
```
|
||||
|
||||
`mysql-read`サービスがサーバー間で接続を分散させることを実証するために、
|
||||
ループで`SELECT @@server_id`を実行することができます。
|
||||
|
||||
```shell
|
||||
kubectl run mysql-client-loop --image=mysql:5.7 -i -t --rm --restart=Never --\
|
||||
bash -ic "while sleep 1; do mysql -h mysql-read -e 'SELECT @@server_id,NOW()'; done"
|
||||
```
|
||||
|
||||
接続の試行ごとに異なるエンドポイントが選択される可能性があるため、
|
||||
報告される`@@server_id`はランダムに変更されるはずです。
|
||||
|
||||
```
|
||||
+-------------+---------------------+
|
||||
| @@server_id | NOW() |
|
||||
+-------------+---------------------+
|
||||
| 100 | 2006-01-02 15:04:05 |
|
||||
+-------------+---------------------+
|
||||
+-------------+---------------------+
|
||||
| @@server_id | NOW() |
|
||||
+-------------+---------------------+
|
||||
| 102 | 2006-01-02 15:04:06 |
|
||||
+-------------+---------------------+
|
||||
+-------------+---------------------+
|
||||
| @@server_id | NOW() |
|
||||
+-------------+---------------------+
|
||||
| 101 | 2006-01-02 15:04:07 |
|
||||
+-------------+---------------------+
|
||||
```
|
||||
|
||||
ループを止めたいときは**Ctrl+C**を押すことができますが、別のウィンドウで実行したままにしておくことで、
|
||||
次の手順の効果を確認できます。
|
||||
|
||||
## PodとNodeのダウンタイムをシミュレーションする
|
||||
|
||||
単一のサーバーではなくスレーブのプールから読み取りを行うことによって可用性が高まっていることを実証するため、
|
||||
Podを強制的にReadyではない状態にする間、上記の`SELECT @@server_id`ループを実行したままにしてください。
|
||||
|
||||
### Readiness Probeを壊す
|
||||
|
||||
`mysql`コンテナに対する
|
||||
[readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)
|
||||
は、`mysql -h 127.0.0.1 -e 'SELECT 1'`コマンドを実行することで、サーバーが起動していてクエリーが実行できることを確認します。
|
||||
|
||||
このreadiness probeを失敗させる1つの方法は、そのコマンドを壊すことです。
|
||||
|
||||
```shell
|
||||
kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql /usr/bin/mysql.off
|
||||
```
|
||||
|
||||
ここでは、`mysql-2` Podの実際のコンテナのファイルシステムにアクセスし、
|
||||
`mysql`コマンドの名前を変更してreadiness probeがコマンドを見つけられないようにしています。
|
||||
数秒後、Podはそのコンテナの1つがReadyではないと報告するはずです。以下を実行して確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get pod mysql-2
|
||||
```
|
||||
|
||||
`READY`列の`1/2`を見てください。
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mysql-2 1/2 Running 0 3m
|
||||
```
|
||||
|
||||
この時点で、`SELECT @@server_id`ループは実行され続け、しかしもう`102`が報告されないことが確認できるはずです。
|
||||
`init-mysql`スクリプトが`server-id`を`100+$ordinal`として定義したことを思い出して下さい。
|
||||
そのため、サーバーID`102`はPodの`mysql-2`に対応します。
|
||||
|
||||
それではPodを修復しましょう。すると数秒後にループ出力に再び現れるはずです。
|
||||
|
||||
```shell
|
||||
kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql.off /usr/bin/mysql
|
||||
```
|
||||
|
||||
### Podを削除する
|
||||
|
||||
StatefulSetは、Podが削除された場合にPodを再作成します。
|
||||
これはReplicaSetがステートレスなPodに対して行うのと同様です。
|
||||
|
||||
```shell
|
||||
kubectl delete pod mysql-2
|
||||
```
|
||||
|
||||
StatefulSetコントローラーは`mysql-2` Podがもう存在しないことに気付き、
|
||||
同じ名前で同じPersistentVolumeClaimにリンクされた新しいPodを作成します。
|
||||
サーバーID`102`がしばらくの間ループ出力から消えて、また元に戻るのが確認できるはずです。
|
||||
|
||||
### ノードをdrainする
|
||||
|
||||
Kubernetesクラスタに複数のノードがある場合は、
|
||||
[drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)を発行して
|
||||
ノードのダウンタイム(例えばノードのアップグレード時など)をシミュレートできます。
|
||||
|
||||
まず、あるMySQL Podがどのノード上にいるかを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pod mysql-2 -o wide
|
||||
```
|
||||
|
||||
ノード名が最後の列に表示されるはずです。
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
mysql-2 2/2 Running 0 15m 10.244.5.27 kubernetes-minion-group-9l2t
|
||||
```
|
||||
|
||||
その後、次のコマンドを実行してノードをdrainします。
|
||||
これにより、新しいPodがそのノードにスケジュールされないようにcordonされ、そして既存のPodは強制退去されます。
|
||||
`<node-name>`は前のステップで確認したノードの名前に置き換えてください。
|
||||
|
||||
この操作はノード上の他のアプリケーションに影響を与える可能性があるため、
|
||||
**テストクラスタでのみこの操作を実行**するのが最善です。
|
||||
|
||||
```shell
|
||||
kubectl drain <node-name> --force --delete-local-data --ignore-daemonsets
|
||||
```
|
||||
|
||||
Podが別のノードに再スケジュールされる様子を確認しましょう。
|
||||
|
||||
```shell
|
||||
kubectl get pod mysql-2 -o wide --watch
|
||||
```
|
||||
|
||||
次のような出力が見られるはずです。
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
mysql-2 2/2 Terminating 0 15m 10.244.1.56 kubernetes-minion-group-9l2t
|
||||
[...]
|
||||
mysql-2 0/2 Pending 0 0s <none> kubernetes-minion-group-fjlm
|
||||
mysql-2 0/2 Init:0/2 0 0s <none> kubernetes-minion-group-fjlm
|
||||
mysql-2 0/2 Init:1/2 0 20s 10.244.5.32 kubernetes-minion-group-fjlm
|
||||
mysql-2 0/2 PodInitializing 0 21s 10.244.5.32 kubernetes-minion-group-fjlm
|
||||
mysql-2 1/2 Running 0 22s 10.244.5.32 kubernetes-minion-group-fjlm
|
||||
mysql-2 2/2 Running 0 30s 10.244.5.32 kubernetes-minion-group-fjlm
|
||||
```
|
||||
|
||||
また、サーバーID`102`が`SELECT @@server_id`ループの出力からしばらくの消えて、
|
||||
そして戻ることが確認できるはずです。
|
||||
|
||||
それでは、ノードをuncordonして正常な状態に戻しましょう。
|
||||
|
||||
```shell
|
||||
kubectl uncordon <node-name>
|
||||
```
|
||||
|
||||
## スレーブの数をスケーリングする
|
||||
|
||||
MySQLレプリケーションでは、スレーブを追加することで読み取りクエリーのキャパシティーをスケールできます。
|
||||
StatefulSetを使用している場合、単一のコマンドでこれを実行できます。
|
||||
|
||||
```shell
|
||||
kubectl scale statefulset mysql --replicas=5
|
||||
```
|
||||
|
||||
次のコマンドを実行して、新しいPodが起動してくるのを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=mysql --watch
|
||||
```
|
||||
|
||||
新しいPodが起動すると、サーバーID`103`と`104`が`SELECT @@server_id`ループの出力に現れます。
|
||||
|
||||
また、これらの新しいサーバーが、これらのサーバーが存在する前に追加したデータを持っていることを確認することもできます。
|
||||
|
||||
```shell
|
||||
kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
|
||||
mysql -h mysql-3.mysql -e "SELECT * FROM test.messages"
|
||||
```
|
||||
|
||||
```
|
||||
Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
|
||||
+---------+
|
||||
| message |
|
||||
+---------+
|
||||
| hello |
|
||||
+---------+
|
||||
pod "mysql-client" deleted
|
||||
```
|
||||
|
||||
元の状態へのスケールダウンもシームレスに可能です。
|
||||
|
||||
```shell
|
||||
kubectl scale statefulset mysql --replicas=3
|
||||
```
|
||||
|
||||
ただし、スケールアップすると新しいPersistentVolumeClaimが自動的に作成されますが、
|
||||
スケールダウンしてもこれらのPVCは自動的には削除されないことに注意して下さい。
|
||||
このため、初期化されたPVCをそのまま置いておいくことで再スケールアップを速くしたり、
|
||||
PVを削除する前にデータを抽出するといった選択が可能になります。
|
||||
|
||||
次のコマンドを実行してこのことを確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get pvc -l app=mysql
|
||||
```
|
||||
|
||||
StatefulSetを3にスケールダウンしたにもかかわらず、5つのPVCすべてがまだ存在しています。
|
||||
|
||||
```
|
||||
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
|
||||
data-mysql-0 Bound pvc-8acbf5dc-b103-11e6-93fa-42010a800002 10Gi RWO 20m
|
||||
data-mysql-1 Bound pvc-8ad39820-b103-11e6-93fa-42010a800002 10Gi RWO 20m
|
||||
data-mysql-2 Bound pvc-8ad69a6d-b103-11e6-93fa-42010a800002 10Gi RWO 20m
|
||||
data-mysql-3 Bound pvc-50043c45-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m
|
||||
data-mysql-4 Bound pvc-500a9957-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m
|
||||
```
|
||||
|
||||
余分なPVCを再利用するつもりがないのであれば、削除することができます。
|
||||
|
||||
```shell
|
||||
kubectl delete pvc data-mysql-3
|
||||
kubectl delete pvc data-mysql-4
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture cleanup %}}
|
||||
|
||||
1. `SELECT @@server_id`ループを実行している端末で**Ctrl+C**を押すか、
|
||||
別の端末から次のコマンドを実行して、ループをキャンセルします。
|
||||
|
||||
```shell
|
||||
kubectl delete pod mysql-client-loop --now
|
||||
```
|
||||
|
||||
1. StatefulSetを削除します。これによってPodの終了も開始されます。
|
||||
|
||||
```shell
|
||||
kubectl delete statefulset mysql
|
||||
```
|
||||
|
||||
1. Podが消えたことを確認します。
|
||||
Podが終了処理が完了するのには少し時間がかかるかもしれません。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=mysql
|
||||
```
|
||||
|
||||
上記のコマンドから以下の出力が戻れば、Podが終了したことがわかります。
|
||||
|
||||
```
|
||||
No resources found.
|
||||
```
|
||||
|
||||
1. ConfigMap、Services、およびPersistentVolumeClaimを削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete configmap,service,pvc -l app=mysql
|
||||
```
|
||||
|
||||
1. PersistentVolumeを手動でプロビジョニングした場合は、それらを手動で削除し、
|
||||
また、下層にあるリソースも解放する必要があります。
|
||||
動的プロビジョニング機能を使用した場合は、PersistentVolumeClaimを削除すれば、自動的にPersistentVolumeも削除されます。
|
||||
一部の動的プロビジョナー(EBSやPDなど)は、PersistentVolumeを削除すると同時に下層にあるリソースも解放します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* その他のステートフルアプリケーションの例は、[Helm Charts repository](https://github.com/kubernetes/charts)を見てください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,181 @@
|
||||
---
|
||||
title: 単一レプリカのステートフルアプリケーションを実行する
|
||||
content_template: templates/tutorial
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、PersistentVolumeとDeploymentを使用して、Kubernetesで単一レプリカのステートフルアプリケーションを実行する方法を説明します。アプリケーションはMySQLです。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
* 自身の環境のディスクを参照するPersistentVolumeを作成します。
|
||||
* MySQLのDeploymentを作成します。
|
||||
* MySQLをDNS名でクラスター内の他のPodに公開します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* {{< include "default-storage-class-prereqs.md" >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
## MySQLをデプロイする
|
||||
|
||||
Kubernetes Deploymentを作成し、PersistentVolumeClaimを使用して既存のPersistentVolumeに接続することで、ステートフルアプリケーションを実行できます。
|
||||
たとえば、以下のYAMLファイルはMySQLを実行し、PersistentVolumeClaimを参照するDeploymentを記述しています。
|
||||
このファイルは/var/lib/mysqlのボリュームマウントを定義してから、20Gのボリュームを要求するPersistentVolumeClaimを作成します。
|
||||
この要求は、要件を満たす既存のボリューム、または動的プロビジョナーによって満たされます。
|
||||
|
||||
注：パスワードはYAMLファイル内に定義されており、これは安全ではありません。安全な解決策については[Kubernetes Secret](/docs/concepts/configuration/secret/)を参照してください 。
|
||||
|
||||
{{< codenew file="application/mysql/mysql-deployment.yaml" >}}
|
||||
{{< codenew file="application/mysql/mysql-pv.yaml" >}}
|
||||
|
||||
1. YAMLファイルに記述されたPVとPVCをデプロイします。
|
||||
|
||||
kubectl create -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
|
||||
|
||||
1. YAMLファイルの内容をデプロイします。
|
||||
|
||||
kubectl create -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
|
||||
|
||||
1. 作成したDeploymentの情報を表示します。
|
||||
|
||||
kubectl describe deployment mysql
|
||||
|
||||
Name: mysql
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 01 Nov 2016 11:18:45 -0700
|
||||
Labels: app=mysql
|
||||
Annotations: deployment.kubernetes.io/revision=1
|
||||
Selector: app=mysql
|
||||
Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable
|
||||
StrategyType: Recreate
|
||||
MinReadySeconds: 0
|
||||
Pod Template:
|
||||
Labels: app=mysql
|
||||
Containers:
|
||||
mysql:
|
||||
Image: mysql:5.6
|
||||
Port: 3306/TCP
|
||||
Environment:
|
||||
MYSQL_ROOT_PASSWORD: password
|
||||
Mounts:
|
||||
/var/lib/mysql from mysql-persistent-storage (rw)
|
||||
Volumes:
|
||||
mysql-persistent-storage:
|
||||
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
|
||||
ClaimName: mysql-pv-claim
|
||||
ReadOnly: false
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available False MinimumReplicasUnavailable
|
||||
Progressing True ReplicaSetUpdated
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: mysql-63082529 (1/1 replicas created)
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
33s 33s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
|
||||
|
||||
1. Deploymentによって作成されたPodを一覧表示します。
|
||||
|
||||
kubectl get pods -l app=mysql
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mysql-63082529-2z3ki 1/1 Running 0 3m
|
||||
|
||||
1. PersistentVolumeClaimを確認します。
|
||||
|
||||
kubectl describe pvc mysql-pv-claim
|
||||
|
||||
Name: mysql-pv-claim
|
||||
Namespace: default
|
||||
StorageClass:
|
||||
Status: Bound
|
||||
Volume: mysql-pv-volume
|
||||
Labels: <none>
|
||||
Annotations: pv.kubernetes.io/bind-completed=yes
|
||||
pv.kubernetes.io/bound-by-controller=yes
|
||||
Capacity: 20Gi
|
||||
Access Modes: RWO
|
||||
Events: <none>
|
||||
|
||||
## MySQLインスタンスにアクセスする
|
||||
|
||||
前述のYAMLファイルは、クラスター内の他のPodがデータベースにアクセスできるようにするServiceを作成します。
|
||||
Serviceのオプションで`clusterIP: None`を指定すると、ServiceのDNS名がPodのIPアドレスに直接解決されます。
|
||||
このオプションは、ServiceのバックエンドのPodが1つのみであり、Podの数を増やす予定がない場合に適しています。
|
||||
|
||||
MySQLクライアントを実行してサーバーに接続します。
|
||||
|
||||
```
|
||||
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword
|
||||
```
|
||||
|
||||
このコマンドは、クラスター内にMySQLクライアントを実行する新しいPodを作成し、Serviceを通じてMySQLサーバーに接続します。
|
||||
接続できれば、ステートフルなMySQLデータベースが稼働していることが確認できます。
|
||||
|
||||
```
|
||||
Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
|
||||
mysql>
|
||||
```
|
||||
|
||||
## アップデート
|
||||
|
||||
イメージまたはDeploymentの他の部分は、`kubectl apply`コマンドを使用して通常どおりに更新できます。
|
||||
ステートフルアプリケーションに固有のいくつかの注意事項を以下に記載します。
|
||||
|
||||
* アプリケーションをスケールしないでください。このセットアップは単一レプリカのアプリケーション専用です。
|
||||
下層にあるPersistentVolumeは1つのPodにしかマウントできません。
|
||||
クラスター化されたステートフルアプリケーションについては、[StatefulSetのドキュメント](/docs/concepts/workloads/controllers/statefulset/)を参照してください。
|
||||
* Deploymentを定義するYAMLファイルでは`strategy: type: Recreate`を使用して下さい。
|
||||
この設定はKubernetesにローリングアップデートを使用 _しない_ ように指示します。
|
||||
同時に複数のPodを実行することはできないため、ローリングアップデートは使用できません。
|
||||
`Recreate`戦略は、更新された設定で新しいPodを作成する前に、最初のPodを停止します。
|
||||
|
||||
## Deploymentの削除
|
||||
|
||||
名前を指定してデプロイしたオブジェクトを削除します。
|
||||
|
||||
```
|
||||
kubectl delete deployment,svc mysql
|
||||
kubectl delete pvc mysql-pv-claim
|
||||
kubectl delete pv mysql-pv-volume
|
||||
```
|
||||
|
||||
PersistentVolumeを手動でプロビジョニングした場合は、PersistentVolumeを手動で削除し、また、下層にあるリソースも解放する必要があります。
|
||||
動的プロビジョニング機能を使用した場合は、PersistentVolumeClaimを削除すれば、自動的にPersistentVolumeも削除されます。
|
||||
一部の動的プロビジョナー(EBSやPDなど)は、PersistentVolumeを削除すると同時に下層にあるリソースも解放します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Deploymentオブジェクト](/docs/concepts/workloads/controllers/deployment/)についてもっと学ぶ
|
||||
|
||||
* [アプリケーションのデプロイ](/docs/user-guide/deploying-applications/)についてもっと学ぶ
|
||||
|
||||
* [kubectl runのドキュメント](/docs/reference/generated/kubectl/kubectl-commands/#run)
|
||||
|
||||
* [Volumes](/docs/concepts/storage/volumes/)と[Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,150 @@
|
||||
---
|
||||
title: Deploymentを使用してステートレスアプリケーションを実行する
|
||||
min-kubernetes-server-version: v1.9
|
||||
content_template: templates/tutorial
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、Kubernetes Deploymentオブジェクトを使用してアプリケーションを実行する方法を説明します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
* nginx deploymentを作成します。
|
||||
* kubectlを使ってdeploymentに関する情報を一覧表示します。
|
||||
* deploymentを更新します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
## nginx deploymentの作成と探検
|
||||
|
||||
Kubernetes Deploymentオブジェクトを作成することでアプリケーションを実行できます。また、YAMLファイルでDeploymentを記述できます。例えば、このYAMLファイルはnginx:1.7.9 Dockerイメージを実行するデプロイメントを記述しています:
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
|
||||
|
||||
1. YAMLファイルに基づいてDeploymentを作成します:
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
|
||||
|
||||
1. Deploymentに関する情報を表示します:
|
||||
|
||||
kubectl describe deployment nginx-deployment
|
||||
|
||||
出力はこのようになります:
|
||||
|
||||
user@computer:~/website$ 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.7.9
|
||||
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. Deploymentによって作成されたPodを一覧表示します:
|
||||
|
||||
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. Podに関する情報を表示します:
|
||||
|
||||
kubectl describe pod <pod-name>
|
||||
|
||||
ここで`<pod-name>`はPodの1つの名前を指定します。
|
||||
|
||||
## Deploymentの更新
|
||||
|
||||
新しいYAMLファイルを適用してDeploymentを更新できます。このYAMLファイルは、Deploymentを更新してnginx 1.8を使用するように指定しています。
|
||||
|
||||
{{< codenew file="application/deployment-update.yaml" >}}
|
||||
|
||||
1. 新しいYAMLファイルを適用します:
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
|
||||
|
||||
1. Deploymentが新しい名前でPodを作成し、古いPodを削除するのを監視します:
|
||||
|
||||
kubectl get pods -l app=nginx
|
||||
|
||||
## レプリカ数を増やすことによるアプリケーションのスケール
|
||||
|
||||
新しいYAMLファイルを適用することで、Deployment内のPodの数を増やすことができます。このYAMLファイルは`replicas`を4に設定します。これはDeploymentが4つのPodを持つべきであることを指定します:
|
||||
|
||||
{{< codenew file="application/deployment-scale.yaml" >}}
|
||||
|
||||
1. 新しいYAMLファイルを適用します:
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
|
||||
|
||||
1. Deploymentに4つのPodがあることを確認します:
|
||||
|
||||
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
|
||||
|
||||
## Deploymentの削除
|
||||
|
||||
Deploymentを名前を指定して削除します:
|
||||
|
||||
kubectl delete deployment nginx-deployment
|
||||
|
||||
## ReplicationControllers -- 昔のやり方
|
||||
|
||||
複製アプリケーションを作成するための好ましい方法はDeploymentを使用することです。そして、DeploymentはReplicaSetを使用します。 DeploymentとReplicaSetがKubernetesに追加される前は、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を使用して複製アプリケーションを構成していました。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Deploymentオブジェクト](/docs/concepts/workloads/controllers/deployment/)の詳細
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: StatefulSetのスケール
|
||||
content_template: templates/task
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
このタスクは、StatefulSetをスケールする方法を示します。StatefulSetをスケーリングするとは、レプリカの数を増減することです。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* StatefulSetはKubernetesバージョン1.5以降でのみ利用可能です。
|
||||
Kubernetesのバージョンを確認するには、`kubectl version`を実行してください。
|
||||
|
||||
* すべてのステートフルアプリケーションがうまくスケールできるわけではありません。StatefulSetがスケールするかどうかわからない場合は、[StatefulSetの概念](/docs/concepts/workloads/controllers/statefulset/)または[StatefulSetのチュートリアル](/docs/tutorials/stateful-application/basic-stateful-set/)を参照してください。
|
||||
|
||||
* ステートフルアプリケーションクラスターが完全に健全であると確信できる場合にのみ、スケーリングを実行してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## StatefulSetのスケール
|
||||
|
||||
### kubectlを使用したStatefulSetのスケール
|
||||
|
||||
まず、スケールしたいStatefulSetを見つけます。
|
||||
|
||||
```shell
|
||||
kubectl get statefulsets <stateful-set-name>
|
||||
```
|
||||
|
||||
StatefulSetのレプリカ数を変更します:
|
||||
|
||||
```shell
|
||||
kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas>
|
||||
```
|
||||
|
||||
### StatefulSetのインプレースアップデート
|
||||
|
||||
コマンドライン上でレプリカ数を変更する代わりに、StatefulSetに[インプレースアップデート](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources)が可能です。
|
||||
|
||||
StatefulSetが最初に `kubectl apply`で作成されたのなら、StatefulSetマニフェストの`.spec.replicas`を更新してから、`kubectl apply`を実行します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f <stateful-set-file-updated>
|
||||
```
|
||||
|
||||
そうでなければ、`kubectl edit`でそのフィールドを編集してください:
|
||||
|
||||
```shell
|
||||
kubectl edit statefulsets <stateful-set-name>
|
||||
```
|
||||
|
||||
あるいは`kubectl patch`を使ってください:
|
||||
|
||||
```shell
|
||||
kubectl patch statefulsets <stateful-set-name> -p '{"spec":{"replicas":<new-replicas>}}'
|
||||
```
|
||||
|
||||
## トラブルシューティング
|
||||
|
||||
### スケールダウンがうまくいかない
|
||||
|
||||
管理するステートフルPodのいずれかが異常である場合、StatefulSetをスケールダウンすることはできません。それらのステートフルPodが実行され準備ができた後にのみ、スケールダウンが行われます。
|
||||
|
||||
spec.replicas > 1の場合、Kubernetesは不健康なPodの理由を判断できません。それは、永続的な障害または一時的な障害の結果である可能性があります。一時的な障害は、アップグレードまたはメンテナンスに必要な再起動によって発生する可能性があります。
|
||||
|
||||
永続的な障害が原因でPodが正常でない場合、障害を修正せずにスケーリングすると、StatefulSetメンバーシップが正しく機能するために必要な特定の最小レプリカ数を下回る状態になる可能性があります。これにより、StatefulSetが利用できなくなる可能性があります。
|
||||
|
||||
一時的な障害によってPodが正常でなくなり、Podが再び使用可能になる可能性がある場合は、一時的なエラーがスケールアップまたはスケールダウン操作の妨げになる可能性があります。一部の分散データベースでは、ノードが同時に参加および脱退するときに問題があります。このような場合は、アプリケーションレベルでスケーリング操作を考えることをお勧めします。また、ステートフルアプリケーションクラスタが完全に健全であることが確実な場合にのみスケーリングを実行してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [StatefulSetの削除](/docs/tasks/run-application/delete-stateful-set/)の詳細
|
||||
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user