Kubernetesのステートフルアプリケーション管理について話す

「Kubernetes ワークロード管理」では、主にステートレスアプリケーションの管理について紹介しました。当時はステートフルアプリケーションについても触れていましたが、データの永続化の方法については説明していなかったため、詳細な紹介は行っていませんでした。この章では、ステートフル アプリケーションを管理する方法に焦点を当てます。

ステートフルアプリケーションとは何ですか?

インスタンス間の関係が不均等で、外部データに依存するアプリケーションは、「ステートフル アプリケーション」と呼ばれます。

インスタンス間のいわゆる不平等な関係とは、分散アプリケーションの場合、各インスタンスと各アプリケーションの間に比較的大きな依存関係が存在することが多いことを意味します。たとえば、特定のアプリケーションは他のアプリケーションの前に起動する必要があります。そうしないと、他のアプリケーションを起動できなくなります。

外部データに依存する最も明白なアプリケーションは、データベース アプリケーションです。データベース アプリケーションの場合、データを永続化する必要があります。ステートレス アプリケーションの場合、データベースを再起動するとデータとアプリケーションの接続が失われます。これは明らかに当初の意図に反しており、生産することはできません。

したがって、Kubernetes でステートフル アプリケーションを効果的にサポートするために、Kubernetes は StatefulSet を使用してステートフル アプリケーションをオーケストレーションおよび管理します。 StatefulSet は ReplicaSet に似ていますが、Pod の起動順序を制御でき、各 Pod に一意の ID を設定できる点が異なります。以下の機能があります。

• 安定した一意のネットワーク識別子
• 安定した永続的なストレージ
• 秩序正しく、優雅な展開とスケーリング
• 順序付けられた自動ローリングアップデート

StatefulSet の設計は理解しやすいです。現実世界を次の2つの状況に抽象化します。(1) 位相的状態。これは、アプリケーション間に非対称の関係があることを意味します。アプリケーションは特定の順序で起動する必要があります。アプリケーションを再起動した場合でも、指定された順序で再起動する必要があり、再起動後のネットワーク識別子は元のものと同じである必要があります。これにより、元の訪問者が同じ方法で新しいポッドにアクセスできるようになります。 （２）保管状況これは、アプリケーションが保存されたデータにバインドされていることを意味します。いつ、どのような状況であっても、ストレージ内のデータが変更されない限り、アプリケーションによって読み取られるデータは同じになります。

したがって、StatefulSet のコア機能は、何らかの方法で Pod のステータスを記録し、Pod が再作成されたときに何らかの方法でそのステータスを復元することです。

StatefulSetの使い方

「Kubernetes アプリケーション アクセス管理」では、Pod のグループへの外部アクセスを提供する方法である Service を紹介しました。通常、Service を使用して Pod にアクセスする方法は 2 つあります: (1) Cluster IP 経由。このクラスター IP は VIP に相当します。この IP にアクセスすると、リクエストはバックエンド Pod に転送されます。 （２）DNSを通じてこのように、まず Kubernetes クラスターに DNS サービスがあることを確認する必要があります。現時点では、my-service という名前のサービスによってプロキシされるバックエンド Pod にアクセスするには、「my-service.my-namespace.svc,cluster.local」にアクセスするだけで済みます。

2番目の方法には、2つの処理方法があります: (1) 通常サービス、つまりドメイン名を解決してクラスターIPを取得し、方法1に従ってアクセスします。 （２）ヘッドレスサービス、つまりドメイン名を解決してバックエンドのポッドのIPアドレスを取得し、直接アクセスできるようにする。

StatefulSetを使用する場合は、主にHeadless Serviceが使用されます。ヘッドレス サービスがどのように定義されているか覚えていますか?

次のように ClusterIP を None に設定するだけです。

 APIバージョン: v1
種類:サービス
メタデータ:
 名前: nginx -ヘッドレス-サービス
 ラベル:
 名前: nginx -ヘッドレス-サービス
仕様:
 クラスターIP :なし
 セレクター:
 名前: nginx
 ポート:
 -ポート: 8000
 ターゲットポート: 80

ヘッドレス サービスを理解した後は、PV と PVC の使用方法も理解する必要があります。忘れてしまった場合は、「Kubernetes データ永続性管理」で確認できます。ここでは詳細には触れません。

次に、StatefulSet の使用を開始します。

まず、ステートフル アプリケーションのレプリカを 2 つ作成するため、次のように 2 つの PV を作成します。

 APIバージョン: v1
種類:永続ボリューム
メタデータ:
 名前: nginx - pv01
 ラベル:
 ストレージ: pv
仕様:
 アクセスモード:
 -一度だけ読み書き可能
 容量：
 ストレージ: 1 Gi
 persistentVolumeReclaimPolicy :リサイクル
 ファイルシステム:
 パス: / data / k8s
 サーバー: 192.168.205.128
 ---
 APIバージョン: v1
種類:永続ボリューム
メタデータ:
 名前: nginx - pv02
 ラベル:
 ストレージ: pv
仕様:
 アクセスモード:
 -一度だけ読み書き可能
 容量：
 ストレージ: 1 Gi
 persistentVolumeReclaimPolicy :リサイクル
 ファイルシステム:
 パス: / data / k8s
 サーバー: 192.168.205.128

次に、StatefulSet に必要な YAML ファイルを次のように記述します。

 APIバージョン: v1
種類:サービス
メタデータ:
 名前: nginx
仕様:
 ポート:
 -ポート: 80
 名前:ウェブ
 クラスターIP :なし
 セレクター:
 アプリ: nginx
 役割:ステートフル

---
 apiバージョン:アプリ/ v1
種類:ステートフルセット
メタデータ:
 名前:ウェブ
仕様:
 サービス名: "nginx"
 レプリカ： 2
 セレクター:
 マッチラベル:
 アプリ: nginx
 テンプレート：
 メタデータ:
 ラベル:
 アプリ: nginx
 役割:ステートフル
 仕様:
 コンテナ:
 -名前: nginx
 画像: nginx
 ポート:
 -コンテナポート: 80
 名前:ウェブ
 ボリュームマウント:
 -名前: www
 マウントパス: / usr / share / nginx / html
 ボリュームクレームテンプレート:
 -メタデータ:
 名前: www
 仕様:
 アクセスモード: [ "ReadWriteOnce" ]
 リソース：
 リクエスト:
 ストレージ: 1 Gi

上記の YAML ファイルでは、volumeMounts が新しいプロパティ volumeClaimTemplates に関連付けられており、管理用の pvc オブジェクトと pv を自動的に宣言していること、また、serviceName: "nginx" は、制御ループの実行時に Pod の解決可能な ID を保存するためにヘッドレス サービス nginx が使用されることを示していることに注意してください。

作成が完了すると、2 つの Pod が起動していることがわかります。

ポッドを取得します| grepウェブ
ウェブ- 0 1 / 1ランニング0 2分45秒
ウェブ- 1 1 / 1ランニング0 2分41秒

これら 2 つの Pod のコマンドから、その名前が Deployment のようなランダムに生成された文字列ではなく、0 や 1 などのシリアル番号であることがわかります。これは、StatefulSet が各 Pod の順序を確認し、再起動または更新のたびに各 Pod が以前のデータを混乱なく保持し続けるようにする必要があるためです。したがって、StatefulSet は [statefulset-name]-[index] ルールに従って名前が付けられ、インデックスは 0 から始まります。また、各 Pod は順番に作成されます。たとえば、web-1 は web-0 が実行状態になった後にのみ作成されます。

両方の Pod が実行状態の場合、それぞれのネットワーク ID を表示できます。次のように、kubectl exec を通じてそれらを表示できます。

 $ kubectl exec web - 0 --sh -c 'ホスト名'
ウェブ- 0
 $ kubectl exec web - 1 --sh -c 'ホスト名'
ウェブ- 1

2 つのポッドのホスト名とポッド名が一致しており、対応する番号が割り当てられていることがわかります。次に、DNS を使用してヘッドレス サービスにアクセスします。

次のようにデバッグ Pod を起動しましょう。

 APIバージョン: v1
種類:ポッド
メタデータ:
 名前: dnsutils
 名前空間:デフォルト
仕様:
 コンテナ:
 -名前: dnsutils
 画像: lansible / dnstools
 指示：
 -寝る
- 「3600」
 imagePullPolicy : IfNotPresent
 再起動ポリシー:常に

次に、解析のために dnsutils コンテナを入力します。

 $ kubectl exec -it dnsutils -- /bin/sh
 / # nslookup ウェブ- 0.nginx
サーバー: 10.96.0.10
住所: 10.96.0.10 # 53

名前: web - 0 .nginx .default .svc .cluster .local
住所: 172.16 .51 .247

 / # nslookup ウェブ- 1.nginx
サーバー: 10.96.0.10
住所: 10.96.0.10 # 53

名前: web - 1 .nginx .default .svc .cluster .local
住所： 172.16.51.251

 / #

nslookup の結果を分析すると、web-0.nginx にアクセスすると web-0 Pod の IP アドレスが解決され、その逆も同様です。つまり、アプリケーションで web-0.nginx を構成すると、web-0 Pod のみが呼び出されます。 Zookeeper などのステートフル アプリケーションを構成する場合は、構成ファイルで zkServer を指定する必要があります。現時点では、zk-0.zookeeper、zk-1.zookeeper のように指定できます。

今 StatefuleSet を更新する場合、更新順序はどうなりますか?

まず、新しいターミナルを開き、次のコマンドを入力して観察します。

 $ kubectl get pods -w -lロール=ステートフル
名前 準備完了 ステータス 再起動 年齢
ウェブ- 0 1 / 1ランニング0 67 m
ウェブ- 1 1 / 1ランニング0 67 m

次に、次のコマンドを使用してアプリケーションのイメージを更新します。

 $ kubectl イメージ statefulset / webを設定しますnginx = nginx : 1.8

次に、Web アプリケーションの更新順序を次のように確認します。

 $ kubectl get pods -w -lロール=ステートフル
名前 準備完了 ステータス 再起動 年齢
ウェブ- 0 1 / 1ランニング0 67 m
ウェブ- 1 1 / 1ランニング0 67 m
ウェブ- 1 1 / 1終了0 68 m
ウェブ- 1 1 / 1終了0 68 m
ウェブ- 1 0 / 1終了0 68 m
ウェブ- 1 0 / 1終了0 68 m
ウェブ- 1 0 / 1終了0 68 m
ウェブ- 1 0 / 1保留中0 0秒
ウェブ- 1 0 / 1保留中0 0秒
ウェブ- 1 0 / 1コンテナ作成0 0秒
ウェブ- 1 0 / 1コンテナ作成0 1秒
ウェブ- 1 1 / 1実行中0 10秒
ウェブ- 0 1 / 1終了0 69 m
ウェブ- 0 1 / 1終了0 69 m
ウェブ- 0 0 / 1終了0 69 m
ウェブ- 0 0 / 1終了0 69 m
ウェブ- 0 0 / 1終了0 69 m
ウェブ- 0 0 / 1保留中0 0秒
ウェブ- 0 0 / 1保留中0 0秒
ウェブ- 0 0 / 1コンテナ作成0 0秒
ウェブ- 0 0 / 1コンテナ作成0 1秒
ウェブ- 0 1 / 1実行中0 9秒

全体のシーケンスから、更新は後ろから前に向かって実行されていること、つまり、最初に web-1 ポッドが更新され、次に web-0 ポッドが更新されていることがわかります。この厳格な対応ルールを通じて、StatefulSet は Pod のネットワーク識別の安定性を保証します。この方法により、Pod のトポロジ状態を Pod 名 + 番号の形式で固定できます。さらに、Kubernetes は各 Pod に対して固定の一意のアクセス ポイント (Pod の DNS レコード) を提供します。

したがって、StatefulSetを次のようにまとめます。(1)StatefulSetはPodを直接管理します。これは、StatefulSet 内の Pod インスタンスが ReplicaSet 内の Pod インスタンスとまったく同じではないためです。各 Pod の名前やホスト名など、微妙な違いがあります。さらに、StatefulSet がこれらのインスタンスを区別する方法は、Pod に番号を追加することです。 （２）Kubernetesはヘッドレスサービスを通じて、番号付きポッドのDNSサーバーに同じ番号のレコードを生成します。 StatefulSet が Pod 番号が変更されないことを保証できる限り、web-0.nginx.default.svc.cluster.local などのサービス内の DNS レコードは変更されず、このレコードによって解決される Pod IP アドレスは Pod が再作成されると自動的に更新されます。 （３）StatefulSetは各Podに対してPodと同じ番号のPVCを割り当てて作成することもできます。このようにして、Kubernetes は永続ボリューム メカニズムを通じて対応する PV をこの PVC にバインドし、各ポッドに独立したボリュームがあることを保証できます。この場合、Pod が削除されても、対応する PVC と PV は保持されます。したがって、Pod が再作成されると、Kubernetes はそれと同じ番号の PVC を見つけて、その PVC に対応するボリュームをマウントし、以前のボリュームの以前のデータを取得します。

要約する

StatefulSet コントローラーの主な機能の 1 つは、Pod テンプレートを使用して Pod を作成するときに Pod に番号を付け、番号順に作業を完了することです。 StatefulSet 制御ループは、Pod の実際の状態が予想される状態と一致していないことを検出すると、Pod に対しても順番に操作を行います。

もちろん、StatefulSet には他の機能もあります。実際のプロジェクトでは、完全に処理できない限り、StatefulSet を介してステートフル サービスを直接デプロイすることはほとんどありません。特定のサービスについては、etcd-operator、prometheus-operator などのより高度な Operator を使用してデプロイする場合があります。これらのアプリケーションは、StatefulSet を使用して Pod をデプロイするだけでなく、ステートフル サービスを非常に適切に管理できます。これは、ステートフル アプリケーションにとって最も重要なことは、データの回復、フェイルオーバーなどであるためです。