StatefulSet は、ステートフル アプリケーションの管理に使用される Kubernetes の API オブジェクトです。 Kubernetes には、ステートフル アプリケーションとステートレス アプリケーションという 2 種類のアプリケーションがあります。これらのアプリケーションをデプロイするには 2 つの方法があります:
何らかの形式の永続的な状態またはデータを維持するアプリケーションは、ステートフル アプリケーションと呼ばれます。これらのアプリケーションをステートレス アプリケーションと区別する主な特徴は、これらのアプリケーションがデータをローカルに保存することに依存しておらず、各リクエストを独立したものとして扱わないことです。インタラクション間のデータを管理します。場合によっては、ステートレス アプリケーションがステートフル アプリケーションに接続して、リクエストをデータベースに転送することがあります。
いかなる形式の永続的な状態やデータもローカルに維持しないアプリケーションは、ステートレス アプリケーションと呼ばれます。ステートレス アプリケーションでは、各リクエストまたは対話は独立して処理されます。これらのアプリケーションは、ステートフル アプリケーションとは異なり、過去のインタラクションやリクエストを追跡する必要がないため、拡張性が高く、管理が容易で、フォールト トレラントであるように設計されています。
ステートレス アプリケーションは、デプロイメント コンポーネントを使用してデプロイされます。デプロイメントはポッドの抽象化であり、アプリケーションを複製できるようになります。つまり、同じステートレス アプリケーションの 1、5、10、または n 個の同一のポッドを実行できるようになります。
最も簡単に言うと、StatefulSet はステートフル アプリケーション専用に使用される Kubernetes コンポーネントです。これらは、ステートフル アプリケーションを管理するために使用されるワークロード API オブジェクトです。 StatefulSet は、一連の Pod のデプロイメントとスケーリング (追加のレプリカの作成または削除) を管理し、StatefulSet はこれらの Pod の順序と一意性にも責任を負います。 StatefulSet は、Kubernetes 1.9 リリースでリリースされました。
StatefulSet は、異なる (一意の) 永続的な ID と柔軟なホスト名 (安定した) を持つポッドのセットを表します。これにより、スケーリングとデプロイメントの順序を確実に行うことができます。 StatefulSet を理解する前に、Kubernetes のデプロイメントを理解する必要があります。
これは、web という名前の StatefulSet の例です。
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 4
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.k8s.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
Kubernetes の StatefulSet は、安定した一意のネットワーク識別子、永続ストレージ、順序付けられた適切なデプロイメントとスケーリングを必要とするステートフル アプリケーションのデプロイメントに最適です。これらは、一貫した ID とストレージを必要とするデータベース、キー/値ストア、メッセージング キューなどのアプリケーションに適しています。
MongoDB データベースに接続された Node.js アプリケーションを考えてみましょう。リクエストがnode.jsアプリケーションに届くと、アプリケーションはリクエストを独立して処理し、以前のデータに依存しません。リクエスト自体のペイロードに基づいてリクエストを処理します。このnode.jsアプリケーションはステートレスアプリケーションの例です。ここで、リクエストはデータベース内の一部のデータを更新するか、データベースの一部のデータをクエリします。 node.js がそのリクエストを MongoDB に転送すると、MongoDB はデータの以前の状態に基づいてデータを更新するか、ストレージからデータをクエリします。リクエストごとにデータを処理する必要があり、それは利用可能な最新のデータまたは状態に依存しますが、node.js はデータ更新またはクエリの単なるパススルーであり、コードを処理するだけです。したがって、node.js アプリケーションはステートレス アプリケーションである必要があり、MongoDB アプリケーションはステートフル アプリケーションである必要があります。
ステートレス アプリケーションがステートフル アプリケーションに接続して、リクエストをデータベースに転送することがあります。これは、ステートレス アプリケーションがステートフル アプリケーションにリクエストを転送する良い例です。
ここでは、StatefulSet の使用方法と、StatefulSet でのいくつかの基本操作に関するステップバイステップのチュートリアルを示します。
ステップ 1. StatefulSet ファイルを作成します。これを行うには、次のコマンドを入力します:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 4
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.k8s.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
ステップ 2. コードエディターでこのファイルを開き、次のコードを書き込みます。
touch example-statefulset.yaml
ステップ 3. 次に、サービス ファイルと Persistent VolumeClaim ファイルを作成する必要があります。
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: gfg-example-statefulset
annotations:
description: "This is an example statefulset"
spec:
selector:
matchLabels:
app: nginx
serviceName: "gfg-example-service"
replicas: 3 # remember this, we will have 3 identical pods running
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumes:
- name: www
persistentVolumeClaim:
claimName: myclaim
ステップ 4. サービス ファイルに次のコードを入力します。
touch example-service.yaml touch example-persistentVolumeChain.yaml
ステップ 5. 次のコードを PersistentVolumeClaim ファイルに入力します。
apiVersion: v1
kind: Service
metadata:
name: gfg-example-service
annotations:
description: "this is an example service"
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
次に、これらの変更を適用しましょう。
ステップ 6. 端末に次のコマンドを入力して、gfg-example-statefulset を作成します。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 8Gi # This means we are requesting for 8 GB of storage
これにより gfg-example-statefulset が作成され、同様の結果が得られます。
ここで、コマンドを使用してターミナルで StatefulSet を検索するとします
kubectl create -f example-statefulset.yaml
リスト内で gfg-example-statefulset が見つかります。
ステップ 7. 端末に次のコマンドを入力して、gfg-example-service を作成します。
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 4
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.k8s.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
これにより、「gfg-example-service」という名前のサービスが作成されます
ステップ 8. ポッドとサービスを確認しましょう。ポッドのリストを取得するには、ターミナルで次のコマンドを入力します。
touch example-statefulset.yaml
example-stateful-set.yaml ファイルで 3 つのレプリカを定義することで、作成した 3 つの gfg-pod のリストが取得されます。同様の出力が得られます:
サービスのリストを確認するには、ターミナルに次のコマンドを入力します:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: gfg-example-statefulset
annotations:
description: "This is an example statefulset"
spec:
selector:
matchLabels:
app: nginx
serviceName: "gfg-example-service"
replicas: 3 # remember this, we will have 3 identical pods running
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumes:
- name: www
persistentVolumeClaim:
claimName: myclaim
これにより、同様の出力が得られます:
StatefulSet の追加: Kubernetes クラスターに StatefulSet を追加するには、コマンド kubectl create -f [StatefulSet ファイル名] を使用し、[StatefulSet ファイル名] を名前に置き換えます。 StatefulSet マニフェスト ファイルの。
touch example-service.yaml touch example-persistentVolumeChain.yaml
StatefulSet の削除: Kubernetes で StatefulSet を削除するには、kubectl delete statefulset [name] コマンドを使用できます。ここで、[name] は必要な StatefulSet の名前です。削除します。
apiVersion: v1
kind: Service
metadata:
name: gfg-example-service
annotations:
description: "this is an example service"
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
StatefulSet の編集: コマンド kubectl edit statefulset [name] を使用すると、エディタを開いてコマンド ラインから直接 StatefulSet の構成を変更できます。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 8Gi # This means we are requesting for 8 GB of storage
レプリカのスケーリング: kubectlscale コマンドは、[StatefulSet 名] という名前の StatefulSet 内のレプリカの数を、指定された [レプリカの数] までスケーリングします。
kubectl create -f example-statefulset.yaml
ステップ 9. それでは、ポッドをスケールアップして、機能するかどうかを確認してみましょう。ポッドを 6 つのポッドにスケールアップするには、次のコマンドを入力します。
kubectl get statefulsets
これにより、さらに 3 つのポッドが作成され、ポッドの数は 6 になりました。ポッドのリストを取得するには、次のコマンドを入力します。
kubectl apply -f example-service.yaml
同様の出力が得られます:
ステップ 10. 次に、ポッドを 3 にスケールダウンしましょう。そのためには、同じコマンドを入力し、レプリカの数を 3 に戻すだけです。
kubectl get pods
ここで、
によってポッドのリストを確認します。
kubectl get services
実行中のポッドは 3 つだけ表示されます:
このようにして、StatefulSet を作成し、スケールアップしたり、スケールダウンしたりすることができます。ターミナルを閉じる前に、必ず StatefulSet とサービスを削除してください。kubectl のコマンドの詳細については、Kubectl コマンド チートシートを参照してください。
MySQL のようなステートフル アプリケーションでは、データの不整合を避けるために、複数のポッドが同時にデータの読み取りと書き込みを行うことはできません。
1 つのポッドはマスター ポッドとして指定され、データの書き込みと変更を担当します。一方、他のポッドはスレーブ ポッドとして指定され、データの読み取りのみが許可されます。
各ポッドにはデータ ストレージの独自のレプリカがあり、データの分離と独立性が確保されます。
すべてのポッドが同じデータ状態になるように同期メカニズムが採用されており、マスター ポッドがデータを変更するとスレーブ ポッドがデータ ストレージを更新します。
ステートフル アプリケーション内のすべてのポッド間でデータの一貫性を維持するには、継続的な同期が必要です。
例:
MySQL のマスター ポッドが 1 つとスレーブ ポッドが 2 つあるとします。新しいポッド レプリカが既存のセットアップに参加するとどうなるでしょうか?新しいポッドも独自のストレージを作成して同期する必要があるため、最初に前のポッドからデータのクローンを作成し、次にマスター ポッドによる更新をリッスンするために継続的な同期を開始します。各ポッドには、同期されたデータとポッドの状態を含む独自の物理ストレージによってバックアップされる独自のデータ ストレージ (永続ボリューム) があるためです。各ポッドには、マスター ポッドであるかスレーブ ポッドであるか、およびその他の個別の特性に関する情報が含まれる独自の状態があります。これらはすべてポッド自体のストレージに保存されます。したがって、ポッドが停止すると、永続ポッドが置き換えられます。識別子により、ストレージ ボリュームが交換ポッドに確実に再接続されます。このようにして、クラスターがクラッシュした場合でも、データが失われることはありません。
この記事では、Kubernetes StatefulSet の使用方法について説明しました。 StatefulSet は、ステートフル アプリケーションをデプロイするために使用される Kubenetes コンポーネントです。ステートフル アプリケーションは、何らかの形式の永続的な状態またはデータを維持するアプリケーションです。良い例としては、データベースを備えたアプリケーションが挙げられます。 StatefulSet を使用してステートフル アプリケーションをデプロイする方法について説明しました。その後、ステートフル アプリケーションがどのように機能するかについて話し合いました。最後に、StatefulSet とデプロイメントの違いについて説明しました。基本的に、デプロイメントはステートレス アプリケーションのデプロイに使用され、StatefulSet はステートフル アプリケーションのデプロイに使用されるという点を中心に進みます。いくつかの FAQ を取り上げてこの記事を終了します。
Kubernetes でボリューム サイズを増やすには、ストレージ サイズを変更して Persistent VolumeClaim (PVC) 仕様を変更する必要があります。その後、基盤となるストレージ クラスが動的プロビジョニングをサポートしている場合、Kubernetes は新しいサイズ要件を満たすために追加のストレージを自動的にプロビジョニングします。
Kubernetes の hostPath ボリューム タイプは、ポッド内でノードのファイル システム上のファイルまたはディレクトリに直接アクセスする必要があるシナリオに適しています。これは通常、ノード固有のリソースにアクセスするため、または同じノード上のコンテナ間でデータを共有するために使用されます。
StatefulSet の PersistentVolumeClaims (PVC) は、個々のポッドに安定した永続ストレージを提供するために使用され、ポッドの再起動後のデータの永続性と ID を確保します。対照的に、デプロイメントでは通常、一時的なボリュームが使用され、データの永続性が要件ではないステートレス アプリケーションに適しています。
技術的には可能ですが、StatefulSet を使用してステートレス アプリケーションをデプロイすることはお勧めできません。 StatefulSet は、安定した一意の識別子と永続的なストレージを必要とするステートフル アプリケーション向けに特別に設計されています。 StatefulSet を使用してステートレス アプリケーションをデプロイすると、不必要な複雑さとリソースのオーバーヘッドが生じる可能性があります。
それはアプリケーションの特定の要件によって異なります。ステートレス アプリケーションは管理と水平方向の拡張が簡単ですが、ステートフル アプリケーションはデータの整合性を維持し、データベースやメッセージング システムなどの特定のワークロードに適しています。
以上がKubernetes Statefulsets の初心者ガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
