Container Service for Kubernetes:StatefulSetを使用してステートフルアプリケーションを作成する

前提条件

イメージからStatefulSetを作成する前に、次の手順を実行してください。

• ACK管理クラスターの作成

• クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続します。

• PVCの作成

背景情報

StatefulSetを使用してステートフルアプリケーションを作成する

ステップ1: 基本設定の設定

1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[ワークロード] > [StatefulSets] を選択します。

3. StatefulSetsページの右上隅にある [画像から作成] をクリックします。

4. [基本情報] ウィザードページで、基本設定を行います。 TypeパラメーターをStatefulSetに設定します。

   パラメーター	説明
   名前	アプリケーションの名前。
   レプリカ	アプリケーションに対してプロビジョニングするポッドの数。 デフォルト値：2
   タイプ	作成するリソースオブジェクトのタイプ。 有効な値: Deployment、StatefulSet、Job、CronJob、およびDaemonSet。
   ラベル	アプリケーションを識別する、アプリケーションに追加されるラベル。
   アノテーション	アプリケーションに追加される注釈。
   タイムゾーンの同期	ノードとコンテナ間のタイムゾーンを同期するかどうかを指定します。

5. クリック次へに進みます。コンテナウィザードページ。

手順2: コンテナーの設定

1. では、一般セクションで、コンテナーの基本設定を構成します。

   パラメーター	説明
   イメージ名	セレクト画像 [画像の選択] をクリックして画像を選択できます。 次のタイプの画像がサポートされています。 Container Registry Enterprise Edition: Container Registry Enterprise Editionインスタンスに保存されているイメージを選択します。 イメージが属するリージョンとContainer Registryインスタンスを選択する必要があります。 Container Registryの詳細については、Container Registryとは Container Registry Personal Edition: Container Registry Personal Editionインスタンスに保存されているイメージを選択します。 イメージが属するリージョンとContainer Registryインスタンスを選択する必要があります。 アーティファクトセンター: アーティファクトセンターには、基本オペレーティングシステムイメージ、基本言語イメージ、およびアプリケーションコンテナ化用のAIおよびビッグデータ関連イメージが含まれています。 この例では、NGINX画像が選択されている。 詳細については、「アーティファクトセンターの概要」をご参照ください。 説明 Container Registryのアーティファクトセンターには、Alibaba CloudまたはOpenAnolisによって更新およびパッチ適用される基本イメージがあります。 他の要件や質問がある場合は、DingTalkグループ (ID 33605007047) に参加してテクニカルサポートをリクエストしてください。 プライベートレジストリに保存されている画像のアドレスを入力することもできます。 イメージアドレスは、domainname/namespace/imagename:tagの形式で指定する必要があります。 画像プルポリシー 画像を取得するためのポリシー。 有効な値： IfNotPresent: プルするイメージがオンプレミスマシンで見つかった場合、オンプレミスマシンのイメージが使用されます。 それ以外の場合、ACKはイメージレジストリからイメージをプルします。 常に: ACKは、アプリケーションが展開または展開されるたびに、Container Registryからイメージを取得します。 Never: ACKは、オンプレミスマシン上の画像のみを使用します。 説明 [イメージプルポリシー] を選択した場合、デフォルトでイメージプルポリシーは適用されません。 Set Image Pull Secret [イメージプルシークレットの設定] をクリックすると、プライベートレジストリからイメージをプルするためのシークレットを設定できます。 Secretsを使用して、Container Registry Personal Editionインスタンスからイメージをプルできます。 シークレットの設定方法の詳細については、「シークレットの管理」トピックのシークレットの作成セクションを参照してください。 Container Registry Enterprise EditionインスタンスからSecretsを使用せずにイメージをプルできます。 詳細については、「aliyun-acr-credential-helperコンポーネントを使用して、シークレットを使用せずにイメージをプルする」をご参照ください。
   リソース制限	アプリケーションが使用できるCPU、メモリ、および一時的なストレージリソースの最大量。 リソース制限は、アプリケーションが過剰な量のリソースを占有することを防止する。 リソース制限の設定方法の詳細については、「リソースプロファイリング」をご参照ください。
   必要なリソース	アプリケーション用に予約されているCPU、メモリ、および一時的なストレージリソースの量。 これらのリソースは、アプリケーションのポッド専用であり、他のアプリケーションによってプリエンプトすることはできません。 リソースを予約する方法の詳細については、「リソースプロファイリング」をご参照ください。
   コンテナー開始パラメーター	stdin: 開始パラメーターを標準入力 (stdin) としてコンテナーに送信することを指定します。 tty: 仮想ターミナルで定義された開始パラメーターをコンテナーに送信することを指定します。 2つのオプションは通常一緒に使用されます。 この場合、仮想端末 (tty) は、コンテナのstdinに関連付けられる。 例えば、対話型プログラムは、ユーザからstdinを受信し、端末にコンテンツを表示する。
   特権コンテナ	[特権コンテナ] を選択すると、コンテナに特権=trueが設定され、特権モードが有効になります。 [特権コンテナ] を選択しない場合、特権=falseがコンテナに設定され、特権モードが無効になります。
   コンテナー初期化	initコンテナを作成するには、このオプションを選択します。 Initコンテナーを使用して、アプリケーションコンテナーの起動をブロックまたは延期できます。 initコンテナーの起動後にのみ、ポッド内のアプリケーションコンテナーが同時に起動します。 たとえば、initコンテナーを使用して、アプリケーションが依存するサービスの可用性を確認できます。 アプリケーションイメージによって提供されていないツールまたはスクリプトをinitコンテナーで実行して、アプリケーションコンテナーのランタイム環境を初期化できます。 たとえば、ツールやスクリプトを実行して、カーネルパラメーターを設定したり、設定ファイルを生成したりできます。 詳細については、次をご参照ください： Initコンテナー。

2. オプション: [ポート] セクションで、[追加] をクリックしてコンテナーポートを追加します。

   パラメーター	説明
   名前	コンテナーポートの名前。
   コンテナポート	公開するコンテナーポートの番号または名前。 ポート番号の有効値: 1 ~ 65535
   プロトコル	有効な値: TCPおよびUDP。

3. オプション: [環境] セクションで、[追加] をクリックして環境変数を追加します。

   環境変数は、キーと値のペアで設定できます。 環境変数は、コンテナーにポッド構成を適用するために使用されます。 詳細については、「ポッド変数」をご参照ください。

   パラメーター	説明
   タイプ	追加する環境変数の型。 有効な値： カスタム 設定マップ 秘密 値 /ValueFrom ResourceFieldRef ConfigMapsまたはSecretsを選択した場合、選択したConfigMapまたはSecretのすべてのデータをコンテナー環境変数に渡すことができます。 この例では、Secretsが選択されています。 [タイプ] ドロップダウンリストから [秘密] を選択し、[値] /[値] ドロップダウンリストから秘密を選択します。 デフォルトでは、選択したシークレットのすべてのデータが環境変数に渡されます。 この場合、アプリケーションのデプロイに使用されるYAMLファイルには、選択したシークレットのすべてのデータを参照する設定が含まれています。 ResourceFieldRefを選択した場合、resourceFieldRefパラメーターが指定され、ポッド仕様からリソース値を参照し、リソース値を環境変数としてコンテナーに渡します。 次のYAMLファイルに例を示します。
   変数キー	環境変数の名前。
   値 /ValueFrom	環境変数の値。

4. オプション: [ヘルスチェック] セクションで、[ライブネス] 、[準備完了] 、[オンデマンドでの起動] を有効にします。

   詳細については、「Liveness、Readiness、Startup Probesの設定」をご参照ください。

   パラメーター	リクエストタイプ	説明
   Liveness: Livenessプローブを使用して、コンテナをいつ再起動するかを判断します。 Readiness: Readinessプローブを使用して、コンテナがトラフィックを受信する準備ができているかどうかを判断します。 スタートアップ: スタートアッププローブは、コンテナをいつ開始するかを決定するために使用されます。 説明 スタートアッププローブは、Kubernetes 1.18以降でのみサポートされます。	HTTP	HTTP GETリクエストをコンテナに送信します。 以下のパラメーターを設定できます。 プロトコル: 要求が送信されるプロトコル。 有効な値: HTTPおよびHTTPS。 パス: サーバー上で要求されたHTTPパス。 ポート: 公開するコンテナーポートの番号または名前。 ポート番号の有効値: 1 ~ 65535 HTTPヘッダー: HTTPリクエストのカスタムヘッダー。 ヘッダーの重複は許可されています。 HTTPヘッダーは、キーと値のペアで指定できます。 初期遅延: YAMLファイルのinitialDelaySecondsフィールド。 このフィールドは、コンテナが開始されてから最初のプローブが実行されるまでの待機時間を指定します。 デフォルト値: 3。 単位は秒です。 Period (s): YAMLファイルのperiodSecondsフィールド。 このフィールドは、プローブが実行される間隔を指定します。 デフォルト値は 10 です。 最小値：1 単位は秒です。 Timeout (s): YAMLファイルのtimeoutSecondsフィールド。 このフィールドは、プローブがタイムアウトするまでの期間を指定します。 デフォルト値は 1 です。 最小値：1 単位は秒です。 Healthy Threshold: 失敗したプローブの後にコンテナーが正常と見なされる前に発生する必要がある連続成功の最小数。 デフォルト値は 1 です。 最小値：1 有効性チェックの場合、このパラメーターは1に設定する必要があります。 異常しきい値: コンテナが成功した後に異常と見なされる前に発生しなければならない連続した失敗の最小数。 デフォルト値：3 最小値：1
   	TCP	コンテナにTCPソケットを送信します。 kubeletは指定されたポートでソケットを開こうとします。 接続が確立された場合、コンテナーは正常とみなされます。 さもなければ、容器は不健康とみなされる。 以下のパラメーターを設定できます。 ポート: 開くコンテナポートの番号または名前。 ポート番号の有効値: 1 ~ 65535 初期遅延: YAMLファイルのinitialDelaySecondsフィールド。 このフィールドは、コンテナが開始されてから最初のプローブが実行されるまでの待機時間を指定します。 デフォルト値: 15。 単位は秒です。 Period (s): YAMLファイルのperiodSecondsフィールド。 このフィールドは、プローブが実行される間隔を指定します。 デフォルト値は 10 です。 最小値：1 単位は秒です。 Timeout (s): YAMLファイルのtimeoutSecondsフィールド。 このフィールドは、プローブがタイムアウトするまでの時間を指定します。 デフォルト値は 1 です。 最小値：1 単位は秒です。 Healthy Threshold: 失敗したプローブの後にコンテナーが正常と見なされる前に発生する必要がある連続成功の最小数。 デフォルト値は 1 です。 最小値：1 有効性チェックの場合、このパラメーターは1に設定する必要があります。 異常しきい値: コンテナが成功した後に異常と見なされる前に発生しなければならない連続した失敗の最小数。 デフォルト値：3 最小値：1
   	コマンド	コンテナーでプローブコマンドを実行し、コンテナーのヘルスステータスを確認します。 以下のパラメーターを設定できます。 Command: コンテナーのヘルスステータスを確認するために実行されるプローブコマンドです。 初期遅延: YAMLファイルのinitialDelaySecondsフィールド。 このフィールドは、コンテナが開始されてから最初のプローブが実行されるまでの待機時間を指定します。 既定値：5 単位は秒です。 Period (s): YAMLファイルのperiodSecondsフィールド。 このフィールドは、プローブが実行される間隔を指定します。 デフォルト値は 10 です。 最小値：1 単位は秒です。 Timeout (s): YAMLファイルのtimeoutSecondsフィールド。 このフィールドは、プローブがタイムアウトするまでの時間を指定します。 デフォルト値は 1 です。 最小値：1 単位は秒です。 Healthy Threshold: 失敗したプローブの後にコンテナーが正常と見なされる前に発生する必要がある連続成功の最小数。 デフォルト値は 1 です。 最小値：1 有効性チェックの場合、このパラメーターは1に設定する必要があります。 異常しきい値: コンテナが成功した後に異常と見なされる前に発生しなければならない連続した失敗の最小数。 デフォルト値：3 最小値：1

5. オプション: [ライフサイクル] セクションで、コンテナーのライフサイクルを設定します。

   コンテナーのライフサイクルには、開始、開始後、停止前のパラメーターを設定できます。 詳細については、「Container Lifecycle Eventsへのハンドラのアタッチ」をご参照ください。

   パラメーター	説明
   開始	コンテナーが起動する前に有効になるコマンドとパラメーターを指定します。
   起動後	コンテナーの起動後に有効になるコマンドを指定します。
   停止前	コンテナーが停止する前に有効になるコマンドを指定します。

6. オプション: [ボリューム] セクションで、ローカルボリュームまたは永続ボリュームクレーム (PVC) を追加します。

   パラメーター	説明
   ローカルストレージの追加	[PVタイプ] ドロップダウンリストから、HostPath、ConfigMap、Secret、またはEmptyDirを選択できます。 次に、マウントソースとコンテナパスのパラメーターを設定して、ボリュームをコンテナにマウントします。 詳細については、「Volumes」をご参照ください。
   PVCを追加	永続ボリュームクレーム (PVC) を使用して永続ボリューム (PV) をマウントできます。 PVをマウントするPVCを選択する前に、PVCを作成する必要があります。 詳細については、「PVCの作成」をご参照ください。

   この例では、ディスクボリュームはコンテナーの /tmpパスにマウントされています。

7. オプション: [ログ] セクションで、ログ収集を設定し、カスタムタグを追加します。

   重要

   クラスターにSimple Log Serviceエージェントがインストールされていることを確認します。

   パラメーター	説明
   コレクションの設定	Logstore: 収集したログを保存するためにSimple Log ServiceにLogstoreを作成します。
   	コンテナー内のログパス: ログデータを収集するためのstdoutまたはコンテナーパスを指定します。 stdoutファイルの収集: stdoutを指定すると、stdoutファイルが収集されます。 Text Logs: コンテナの指定されたパスのログが収集されることを指定します。 この例では、パスとして /var/log/nginxが指定されています。 パスにはワイルドカード文字を使用できます。
   カスタムタグ	カスタムタグを追加することもできます。 タグは、ログが収集されるときにコンテナのログに追加されます。 カスタムタグは、収集したログのフィルタリングと分析に役立ちます。

8. クリック次へをクリックして [高度なウィザード] ページに移動します。

ステップ3: 詳細設定の設定

[詳細設定] ウィザードページで、アクセス制御、スケーリング、スケジューリング、アノテーション、ラベルの設定を行います。

1. では、アクセス制御セクションでは、バックエンドポッドを公開するためのアクセス制御設定を構成できます。

   説明

   ビジネス要件に基づいて、次のアクセス制御設定を構成できます。

   • 内部アプリケーション: クラスター内でサービスを提供するアプリケーションの場合、ClusterIPまたはNodePortサービスを作成して内部通信を有効にできます。

   • 外部アプリケーション: インターネットに公開されているアプリケーションの場合、次のいずれかの方法を使用してアクセス制御を構成できます。

     • LoadBalancerサービスを作成します。 サービスを作成するときは、TypeパラメーターをServer Load Balancerに設定します。 サービスのServer Load Balancer (SLB) インスタンスを選択または作成し、サービスを使用してアプリケーションをインターネットに公開できます。

     • Ingressを作成し、それを使用してアプリケーションをインターネットに公開します。 詳しくは、『ingress-nginx』をご参照ください。

   バックエンドポッドをインターネットに公開する方法を指定することもできます。 この例では、NGINXアプリケーションをインターネットに公開するためにClusterIPサービスとIngressが作成されます。

   • サービスを作成するには、[サービス] の右側にある [作成] をクリックします。 [作成] ダイアログボックスで、パラメーターを設定します。

     パラメーター	説明
     名前	サービスの名前。
     サービスタイプ	サービスのタイプ。 このパラメータは、サービスへのアクセス方法を指定します。 有効な値： クラスターIP クラスターIPサービス。 このタイプのサービスは、クラスターの内部IPアドレスを使用して公開されます。 このタイプを選択すると、クラスター内でのみサービスにアクセスできます。 これはデフォルトのタイプです。 [Headless Service] を選択した場合、Kubernetesがデフォルトで提供するClusterIPベースのサービス検出および負荷分散機能に依存することなく、他のサービス検出メカニズムと対話できます。 Server Load Balancer 説明 LoadBalancerサービス。 SLBインスタンスの作成と既存のSLBインスタンスの使用機能はカナリアリリースにあります。 できます 機能の使用を申請するには、チケットを起票してください。 このタイプのサービスは、Classic Load Balancer (CLB) またはNetwork Load Balancer (NLB) インスタンスを使用して、クラスター内のアプリケーションを公開します。SLBとは何ですか? Node Portメソッドと比較して、このメソッドを使用して公開されるアプリケーションの可用性とパフォーマンスが大幅に向上します。 次のタイプがサポートされています。 CLB: 詳細については、「CLB」をご参照ください。 NLB: 詳細については、「NLB」をご参照ください。 ノードポート NodePortサービス。 このタイプのサービスを使用すると、外部ユーザーはノードのIPアドレスと指定されたポートを使用してクラスター内のサービスにアクセスできます。 <NodeIP >:< NodePort> 形式のアドレスにアクセスして、NodePortサービスに接続できます。 ただし、負荷分散のために手動で設定を完了する必要があります。
     外部トラフィックポリシー	[外部トラフィックポリシー] パラメーターは、サービスタイプパラメーターを [ノードポート] または [Server Load Balancer] に設定した場合にのみ使用できます。 外部トラフィックポリシーの詳細については、「はじめに」トピックの外部トラフィックポリシーの違いをご参照ください。 有効な値： Local: 現在のノードのポッドにのみトラフィックをルーティングします。 Cluster: トラフィックをクラスター内の他のノードのポッドにルーティングします。
     バックエンド	サービスに関連付けるバックエンドアプリケーション。 バックエンドアプリケーションを選択しない場合、Endpointオブジェクトは作成されません。 詳細については、「Services-without-selectors」をご参照ください。
     ポートマッピング	サービスポートとコンテナーポート。 サービスポートはYAMLファイルのportフィールドに対応し、コンテナーポートはYAMLファイルのtargetPortフィールドに対応します。 コンテナーポートは、バックエンドポッドで公開されているポートと同じである必要があります。
     注釈	SLBインスタンスを構成するためにサービスに追加されるアノテーション。 詳細については、「注釈を使用してCLBインスタンスを構成する」および「注釈を使用してNLBインスタンスを構成する」をご参照ください。 重要 クラスターのAPIサーバーのSLBインスタンスを再利用しないでください。 そうしないと、クラスターへのアクセスが異常になります。
     ラベル	サービスを識別する、サービスに追加されるラベル。

   • Ingressを作成するには、Ingressの右側にある [作成] をクリックします。 [作成] ダイアログボックスで、パラメーターを設定します。

     パラメーター	説明
     名前	Ingressの名前。
     ルール	Ingressルールは、クラスター内の指定されたサービスへのアクセスを有効にするために使用されます。 詳細については、「NGINX Ingressの作成」をご参照ください。 ドメイン名: Ingressのドメイン名を入力します。 パス: サービスURLを入力します。 デフォルトのパスはルートパス /です。 この例では、デフォルトのパスが使用されます。 各パスはバックエンドサービスに関連付けられています。 SLBは、インバウンドリクエストがドメイン名とパスと一致する場合にのみ、トラフィックをバックエンドサービスに転送します。 サービス: サービスとサービスポートを選択します。 TLS設定: TLSを有効にするには、このチェックボックスをオンにします。 詳細については、「高度なNGINX Ingress設定」をご参照ください。
     カナリアリリース	カナリアリリース機能を有効にするかどうかを指定します。 オープンソースソリューションを選択することを推奨します。
     Ingressクラス	Ingressのクラス。
     アノテーション	カスタム注釈を追加するか、既存の注釈を選択できます。 Ingressアノテーションの詳細については、「アノテーション」をご参照ください。 [注釈の追加] をクリックして注釈を追加します。 無制限の数の注釈を追加できます。
     ラベル	Ingressの特性を表すラベル。 [ラベルの追加] をクリックしてラベルを追加します。 無制限の数のラベルを追加できます。

   [アクセス制御] セクションで、既存のサービスとIngressを表示できます。 [更新] または [削除] をクリックして、サービスとIngressを更新または削除することもできます。

2. オプション: [スケーリング] セクションで、HPAとCronHPAをオンデマンドで有効にして、さまざまなアプリケーションの要件を満たします。

   • HPAは、CPUおよびメモリ使用量メトリックに基づいて、ACKクラスター内のポッド数を自動的にスケーリングできます。

     説明

     HPAを有効にするには、各コンテナーに必要なリソースを設定する必要があります。 そうでない場合、HPAは有効になりません。

     パラメーター	説明
     メトリック	CPU使用率またはメモリ使用率を選択します。 選択したリソースタイプは、[必須リソース] フィールドで指定したものと同じである必要があります。
     Condition	リソース使用量のしきい値。 水平ポッド自動スケーリング (HPA) 機能は、しきい値を超えるとスケールアウトイベントをトリガーします。
     最大 レプリカ	アプリケーションをスケーリングできるレプリケートされたポッドの最大数。
     最小 レプリカ	実行する必要のあるレプリケートポッドの最小数。

   • CronHPAは、スケジュールされた時間にACKクラスタをスケーリングすることができる。 CronHPAを有効にする前に、ack-kubernetes-cronhpa-controllerをインストールする必要があります。 CronHPAの詳細については、「CronHPAジョブの作成」をご参照ください。

3. オプション: [スケジューリング] セクションでは、[更新方法] 、[ノードアフィニティ] 、[ポッドアフィニティ] 、および [ポッドアンチアフィニティ] のパラメーターを設定できます。 詳細については、「Affinity and anti-affinity」をご参照ください。

   説明

   ノードアフィニティとポッドアフィニティは、ノードラベルとポッドラベルに基づくポッドスケジューリングに影響します。 Kubernetesが提供するノードラベルとポッドラベルを追加して、ノードアフィニティとポッドアフィニティを設定できます。 ノードとポッドにカスタムラベルを追加し、これらのカスタムラベルに基づいてノードアフィニティとポッドアフィニティを構成することもできます。

   パラメーター	説明
   更新方法	ローリングアップデートまたはOnDeleteを選択します。 詳細については、「StatefulSets」をご参照ください。
   ノードのアフィニティ	ワーカーノードラベルをセレクターとして選択して、ノードアフィニティを設定します。 ノードアフィニティは、In、NotIn、Exists、DoesNotExist、Gt、Ltなどの必要な優先ルールとさまざまな演算子をサポートします。 必須: ポッドスケジューリングに一致する必要があるルールを指定します。 YAMLファイルでは、これらのルールはrequiredDuringSchedulingIgnoredDuringExecutionアフィニティによって定義されます。 これらのルールは、NodeSelectorパラメーターと同じ効果があります。 この例では、指定されたラベルを持つノードにのみポッドをスケジュールできます。 複数の必須ルールを作成できます。 ただし、そのうちの1つだけを満たす必要があります。 推奨: ポッドスケジューリングに一致する必要のないルールを指定します。 ポッドは、複数のノードが必要なルールに一致する場合、優先ルールに一致するノードにスケジュールされます。 YAMLファイルでは、これらのルールはpreferredDuringSchedulingIgnoredDuringExecutionアフィニティによって定義されます。 優先ルールを指定すると、スケジューラは優先ルールに一致するノードにポッドをスケジュールしようとします。 推奨ルールには重み付けをすることができます。 複数のノードがルールに一致する場合、重みが最も高いノードが優先されます。 複数の優先ルールを作成できます。 ただし、ポッドは、優先ルールのすべてに一致する場合にのみスケジュールされます。
   ポッドの親和性	ポッドアフィニティルールは、同じトポロジドメイン内の他のポッドに対してポッドをデプロイする方法を指定します。 たとえば、ポッドアフィニティを使用して、互いに通信するサービスをホストなどの同じトポロジカルドメインにデプロイできます。 これにより、これらのサービス間のネットワーク待ち時間が短縮されます。 ポッドアフィニティを使用すると、ポッドのラベルに基づいてポッドをスケジュールできるノードを指定できます。 ポッドアフィニティは、必須および優先ルール、および次の演算子をサポートします: In、NotIn、Exists、およびDoesNotExist。 必須: ポッドスケジューリングに一致する必要があるルールを指定します。 YAMLファイルでは、これらのルールはrequiredDuringSchedulingIgnoredDuringExecutionアフィニティによって定義されます。 ポッドをノードにスケジュールするには、ノードが必要なルールと一致する必要があります。 名前空間: 必要なルールを適用する名前空間を指定します。 ポッドアフィニティ規則は、ポッドに追加されるラベルに基づいて定義されるため、名前空間にスコープする必要があります。 トポロジカルドメイン: topologyKeyを設定します。 これは、システムがトポロジカルドメインを示すために使用するノードラベルのキーを指定します。 たとえば、パラメーターをkubernetes.io/hostnameに設定した場合、トポロジはノードによって決定されます。 パラメーターをbeta.kubernetes.io/osに設定した場合、トポロジはノードのオペレーティングシステムによって決定されます。 セレクター: セレクターの右側にあるプラスボタンをクリックして、ポッドラベルを追加します。 アプリケーションの表示: [アプリケーションの表示] をクリックして、各名前空間のアプリケーションを表示します。 選択したアプリケーションのラベルを [Pod Affinity] 設定ページに追加できます。 必須ルール: 既存のアプリケーションのラベル、演算子、およびラベル値を指定します。 この例では、必須ルールは、作成されるアプリケーションがapp:nginxラベルでアプリケーションを実行するホストにスケジュールされることを指定します。 推奨: ポッドスケジューリングに一致する必要のないルールを指定します。 ポッドは、複数のノードが必要なルールに一致する場合、優先ルールに一致するノードにスケジュールされます。 YAMLファイルでは、これらのルールはpreferredDuringSchedulingIgnoredDuringExecutionアフィニティによって定義されます。 スケジューラは、優先ルールに一致するノードにポッドをスケジュールしようとします。 必須ルールには重み付けをすることができます。 他のパラメーターは、必須ルールのパラメーターと同じです。 説明 重み: 優先ルールの重みを1〜100の値に設定します。 スケジューラは、アルゴリズムに基づいて優先ルールを満たす各ノードの重みを計算し、重みが最も高いノードにポッドをスケジュールします。
   ポッドのAnti-affinity	ポッドのアフィニティ防止ルールでは、ラベルが一致するポッドがデプロイされているトポロジカルドメインにポッドをスケジュールしないように指定しています。 Pod anti-affinityルールは、次のシナリオに適用されます。 アプリケーションのポッドを、複数のホストなどの異なるトポロジカルドメインにスケジュールします。 これにより、サービスの安定性を高めることができます。 ポッドにノードへの排他的アクセスを許可します。 これにより、リソースの分離が可能になり、指定されたノードのリソースを他のポッドが共有できなくなります。 ポッドが互いに干渉する可能性がある場合、アプリケーションのポッドを異なるホストにスケジュールします。 説明 ポッド対応ルールのパラメーターは、ポッド対応ルールのパラメーターと同じです。 実際のシナリオに基づいてルールを作成します。
   寛容	一致するテイントを持つノードにポッドをスケジュールできるように許容範囲を設定します。
   仮想ノードへのスケジュール	ポッドを仮想ノードにスケジュールするかどうかを指定します。 ACK Proクラスターのみがこのパラメーターをサポートしています。 クラスターに仮想ノードが含まれていない場合、このパラメーターは使用できません。 ポッドを仮想ノードにスケジュールする方法の詳細については、「ECSインスタンスとエラスティックコンテナインスタンスに基づくリソース割り当ての設定」をご参照ください。

4. オプション: [ラベル、注釈] セクションで、[追加] をクリックしてポッドにラベルと注釈を追加します。

   パラメーター	説明
   ポッドラベル	ポッドに追加するラベル。ポッドを識別します。
   ポッド注釈	ポッドに追加されるアノテーション。

5. [作成] をクリックします。

手順4: デプロイされたアプリケーションの表示

1. アプリケーションが作成されると、[完了] ウィザードページにリダイレクトされます。 アプリケーションに含まれるリソースオブジェクトを見つけ、[詳細の表示] をクリックしてアプリケーションの詳細を表示します。

2. ページの左上隅にある [戻る] アイコンをクリックして、StatefulSetsページに移動します。 [StatefulSets] ページで、作成したアプリケーションを表示できます。

次に何をすべきか