Discovering StatefulSets

Deployments および ReplicaSets を使用してすでにクラスタにアプリケーションをデプロイしていますが、これらのリソースはデータベースなどのステートフルアプリケーションには適していません。ステートフルアプリケーションの詳細について学び、それらを Kubernetes にデプロイする方法を確認します。

Kubernetes では、ステートレスアプリケーションのデプロイが簡単です。Deployment を使用して ReplicaSet を作成し、ReplicaSet によって Pod が作成されます。1 つの Pod が失敗すると、ReplicaSet によって新しい Pod が作成されます。これらの Pod は、その仕様および適用されたラベルに基づいて識別されます。ただし、ReplicaSet によって作成された Pod には、名前の末尾にランダムなハッシュが割り当てられます (例: hello-kyma-59fd556764-fkr6d)。これは、Pod がステートレスであり、同じ仕様およびラベルを持つ他の Pod に置き換えることができるためです。

代わりに、ステートフルアプリケーションには、安定したホスト名など、一意で整合性のある識別子が必要になることがよくあります。これにより、ReplicaSets はランダムに新しい名前が割り当てられるため、Pod を識別して接続することが困難になるため、ReplicaSets の性質が問題になります。このため、Kubernetes では StatefulSets が提供されます。

ワークロードで以下の 1 つまたは複数の機能が必要な場合は、正式な Kubernetes 文書に基づいて StatefulSets を使用できます。

• 安定したユニークなネットワーク識別子
• 安定かつ永続的なストレージ
• オーダー済み、適切なデプロイメント、およびスケーリング
• 自動ローリング更新の順序付け

そのため、StatefulSet は、再スケジュール全体で Kubernetes が維持する一意の永続的な ID と安定したホスト名を持つ Pod のグループを管理します。

StatefulSet を作成すると、Pod は順番に作成されます。つまり、最初の Pod は my-stateful-app-0 という名前で作成され、2 つ目の Pod は my-stateful-app-1 という名前で作成され、以下同様に続きます。最大数は、StatefulSet で指定したレプリカの数と同じです。この動作は、Pod がランダムな順序で同時に作成される ReplicaSet とは異なります。

StatefulSet は、最も小さいインデックスの Pod を開始することから開始し、準備が完了するまで待機します。その後でのみ、次の Pod の作成に進み、Pod が順次作成され、次のポッドが開始される前に各 Pod の準備が整っていることを確認します。さらに、永続ストレージをステートフル Pod に添付して、Pod が削除された場合のデータ損失を防ぐことができます。これは、データを永続化する必要があるデータベースなどのアプリケーションで特に役立ちます。データベース Pod がクラッシュするか、または削除された場合、データは永続ストレージで引き続き使用可能です。

StatefulSet のマニフェストの例を参照してください。

123456789101112131415161718192021
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-stateful-app
spec:
  selector:
    matchLabels:
      app: my-stateful-app
  serviceName: my-stateful-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-stateful-app
    spec:
      containers:
      - name: my-stateful-app
        image: ghcr.io/sap-samples/kyma-runtime-learning-journey/hello-kyma:1.0.0
        ports:
        - containerPort: 8080
          name: web

考慮すべき重要なのは、いわゆるヘッドレスサービスとしての StatefulSet のサービス定義です。ReplicaSet によって管理される Pod にトラフィックをロードするサービスを使用する場合、サービスではラベルによって Pod が特定されます。これは、Pod に名前の最後にランダムなハッシュが割り当てられているためです。一方、StatefulSets では、Pod は安定した名前 (my-stateful-app-1 など) で識別されます。このコンテキストでは、トラフィックをランダムな Pod に負荷分散するために、サービスとして 1 つの IP アドレスを持つロードバランサは必要ありません。

headless サービスマニフェストの例を参照してください。

1234567891011
apiVersion: v1
kind: Service
metadata:
  name: my-stateful-app
spec:
  clusterIP: None
  selector:
    app: my-stateful-app
  ports:
  - name: web
    port: 80