From e32a587b44070e726720ae56f6ca87ea75adad9f Mon Sep 17 00:00:00 2001 From: Soto Sugita Date: Fri, 12 Jul 2019 16:41:06 +0900 Subject: [PATCH] Translate tasks/run-application/run-replicated-stateful-application/ in Japanese (#15368) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * 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 * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: nasa9084 * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: Kohei Ota * small fixs 「複製」という言葉を使わず「レプリケーション」と「クローン」に使い分けるように変更。 「ステートフルなアプリケーション」を「ステートフルアプリケーション」に変更。 * small fix --- .../run-replicated-stateful-application.md | 490 ++++++++++++++++++ 1 file changed, 490 insertions(+) create mode 100644 content/ja/docs/tasks/run-application/run-replicated-stateful-application.md diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md new file mode 100644 index 0000000000000..5711d1859b26c --- /dev/null +++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md @@ -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は、`.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に `-`という形式の一意で不変の名前を割り当てます。 +この例の場合、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 <`は前のステップで確認したノードの名前に置き換えてください。 + +この操作はノード上の他のアプリケーションに影響を与える可能性があるため、 +**テストクラスタでのみこの操作を実行**するのが最善です。 + +```shell +kubectl drain --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 kubernetes-minion-group-fjlm +mysql-2 0/2 Init:0/2 0 0s 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 +``` + +## スレーブの数をスケーリングする + +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 %}} + + +