Alibaba Cloud Container Service の Kubernetes クラスターにより、Web インターフェイスから、 StatefulSet タイプのアプリケーションの作成がスピーディに行えます。 この例では、StatefulSet Nginx アプリケーションの作成および、StatefulSet アプリケーションの機能を紹介します。

始める前に

このタスクについて

StatefulSet 機能は以下のようになります。
シナリオ 説明
ポッドの一貫性 順序 (開始、停止) およびネットワークの一貫性を含みます。 この一貫性はポッドに関連しており、ポッドがどのノードーにスケジュールされているかには関係しません。
安定した永続ストレージ VolumeClaimTemplate を使用して、各ポッドに PV を作成します。 レプリカの削除または縮小では、関連するボリュームは削除されません。
安定したネットワークマーカー ポッドの Hostname モードは、(statefulset 名)-(順序番号) です。
安定した順序 N 個のレプリカの StatefulSet に関して、各ポッドに 0～N までの固有の順序番号が割り当てられます。

手順

  1. Container Service コンソール にログインします。
  2. Container Service-Kubernetes の左側のナビゲーションウィンドウで、[アプリケーション] > [ステーフルセット] を選択します。 次に、右上隅の [イメージによる作成] をクリックします。
  3. 基本パラメーターを設定し、[次へ] をクリックします。
    • [名前]: アプリケーションの名前を入力します。
    • クラスター: アプリケーションをデプロイするクラスターを選択します。
    • 名前空間: アプリケーションのデプロイがある名前空間を選択します。 デフォルトでは、"default" 名前空間が使用されます。
    • レプリカ: アプリケーションに含まれるポッドの数を設定します。
    • タイプ: デプロイのタイプおよび StatefulSet のタイプが利用可能です。
      注 この例では、StatefulSet タイプを選択します。
    • ラベル：アプリケーションにラベルを追加します。
    • アノテーション ：アノテーションをアプリケーションに追加します。
  4. コンテナーの設定
    注 アプリケーションのポッドに対して複数のコンテナーを設定することができます。
    1. アプリケーションに関する一般的な設定を行います。
      • イメージ名: [イメージの選択] をクリックし、表示されたダイアログボックスでイメージを選択して、[OK] をクリックします。 この例では、Nginx イメージを選択します。

        domainname/namespace/imagename:tag の形式で、プライベートレジストリを入力して、イメージを指定することもできます。

      • イメージバージョン: バージョンを選択するには、[イメージバージョンの選択] をクリックします。 イメージバージョンが指定されていない場合、デフォルトで最新バージョンが使用されます。
      • 常にイメージをプル: デプロイ効率を向上させるため、Container Service によりイメージがキャッシュされます。 デプロイ中、検索されたイメージのタグがローカルキャッシュのイメージのタグと一致した場合、ローカルキャッシュのイメージが再利用され、再度プルされることはありません。 そのため、上位層の業務への利便性のために、コードおよびイメージを変更した際に、イメージタグを変更しなかった場合、ローカルキャッシュ内の一番最初のイメージがアプリケーションのデプロイに使用されます。 [常にイメージをプル] チェックボックスがオンのとき、Container Service では、アプリケーションのデプロイの際に、確実に最新のイメージおよびコードを常に使用するため、キャッシュ内のイメージを無視し、リポジトリ内のイメージを再度プルします。
      • リソース制限：リソース (CPU およびメモリー) に関する上限を設定します。これにより、アプリケーションによるリソースの過度の占有を防ぐことができます。 CPU はミリコア単位 、1 コアの 1000 分の 1 で計測されます。 メモリーはバイト単位で計測され、Gi、Mi、または Ki となります。
      • リソースリクエスト: アプリケーションに対して確保するリソース (CPU およびメモリー) 量を指定します。ここで指定するリソースはコンテナーに対して占有する量です。 リソースが不足している場合は、他のサービスやプロセスとリソースの競合が発生します。 リソースリクエストを指定することで、リソース不足のためにアプリケーションが使用できなくなることがありません。
      • Init Container: このチェックボックスをオンにすると、便利なツールを含んだ Init Container が作成されます。 詳細は、『https://kubernetes.io/docs/concepts/workloads/pods/init-containers/』をご参照ください。
    2. オプション: 環境を設定します。

      キーと値のペアを使用したポッドの環境変数を設定できます。 環境変数は、環境ラベルの追加または、ポッドに関する設定を渡すために使われます。 詳しい情報は、『ポッド変数』をご参照ください。

    3. オプション: ヘルスチェックを設定します。

      ヘルスチェック機能には、Liveness プローブおよび Readiness プローブが含まれます。 Liveness プローブは、コンテナーの再起動時刻を検出します。 Readiness プローブは、コンテナーがトラフィックを受信できる状態かどうかを判定します。 ヘルスチェックに関する詳しい情報は、『https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes』をご参照ください。

      リクエストメソッド 説明
      HTTP リクエスト HTTP GET リクエストはコンテナーへ送信されます。 以下のパラメーターがサポートされます。
      • プロトコル: HTTP または HTTPS。
      • パス: HTTP サーバーのアクセスパスです。
      • ポート: コンテナーで開放されるポートの番号または名前です。 ポート番号は 1〜65535 である必要があります。
      • HTTP ヘッダー: HTTP リクエストのカスタムヘッダーです。 HTTP は複数のヘッダーを同時に送信できます。 キーと値の正確な設定をサポートしています。
      • 初期遅延 (秒): "initialDelaySeconds" です。 コンテナーが起動してから、最初のプローブの待機時間を秒単位で設定します。 デフォルトでは、3 です。
      • 期間 (秒): "periodseconds" です。 プローブの実行間隔です。 デフォルト値は 10 です。 最小値は 1 です。
      • タイムアウト (秒): "timeoutSeconds" です。 プローブのタイムアウトまでの時間です。 デフォルト値は 1 で、最小値は 1 です。
      • 成功しきい値: 失敗したプローブの発生後、成功したとみなされる連続して成功したプローブの最少の数です。 デフォルトは 1 で、最小値は 1 です。 Liveness プローブでは 1 である必要があります。
      • 失敗しきい値: 成功したプローブの発生後、失敗したとみなされる連続して失敗したプローブの最少の数です。 デフォルト値は 3 です。 最小値は 1 です。
      TCP 接続 TCP ソケットはコンテナーに送信されます。 kubelet は、指定されたポートで、コンテナーへのソケットの作成を試みます。 接続が確立された場合、コンテナーは正常であるとみなされます。 接続が確立されなかった場合、失敗とみなされます。 以下のパラメーターをサポートしています。
      • ポート: コンテナーにより開放されるポートの番号または名称です ポート番号は 1〜65535 である必要があります。
      • 初期遅延 (秒): initialDelaySeconds です。 コンテナーが起動してから、最初の Liveness プローブまたは Readiness プローブの待機時間を秒単位で設定します。 デフォルトは 15 です。
      • 期間 (秒): periodseconds です。 プローブの実行間隔です。 デフォルト値は 10 です。 最小値は 1 です。
      • タイムアウト (秒): "timeoutSeconds" です。 プローブのタイムアウトまでの時間です。 デフォルト値は 1 で、最小値は 1 です。
      • 成功しきい値: 失敗したプローブの発生後、成功したとみなされる連続して成功したプローブの最少の数です。 デフォルトは 1 で、最小値は 1 です。 Liveness プローブでは 1 である必要があります。
      • 失敗しきい値: 成功したプローブの発生後、失敗したとみなされる連続して失敗したプローブの最少の数です。 デフォルト値は 3 です。 最小値は 1 です。
      コマンドライン コンテナーでプローブ検出コマンドを実行して、コンテナーのヘルスステータスを検出します。 以下のパラメーターをサポートしています。
      • コマンド: コンテナーのヘルスステータスを検出するためのプローブコマンドです。
      • 初期遅延 (秒): initialDelaySeconds です。 コンテナーの起動後、最初の Liveness プローブまたは Readiness プローブの待機時間を秒単位で設定します。 デフォルトは 5 です。
      • 期間 (秒): periodseconds です。 プローブの実行間隔です。 デフォルト値は 10 です。 最小値は 1 です。
      • タイムアウト (秒): timeoutSeconds です。 プローブのタイムアウトまでの時間です。 デフォルト値は 1 で、最小値は 1 です。
      • 成功しきい値: 失敗したプローブの発生後、成功したとみなされる連続して成功したプローブの最少の数です。 デフォルトは 1 で、最小値は 1 です。 Liveness プローブでは 1 である必要があります。
      • 失敗しきい値: 成功したプローブの発生後、失敗したとみなされる連続して失敗したプローブの最少の数です。 デフォルト値は 3 です。 最小値は 1 です。
    4. オプション: ライフサイクルルールを設定します。

      コンテナーのライフサイクルに関して、開始、開始後および停止前のパラメーターを設定できます。 詳しい情報は、『https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/』をご参照ください。

      • 開始 : コンテナーの開始前コマンドおよびパラメーターを設定します。
      • 開始後: コンテナーの開始後のコマンドを設定します。
      • 停止前: コンテナーの停止前コマンドを設定します。
    5. データボリュームを設定します。

      ローカルストレージおよびクラウドストレージの設定ができます。

      • ローカルストレージ: ホストパス (hostPath)、コンフィグマップ (configmap)、シークレット (secret) および一時ディレクトリをサポートしています。 ローカルデータボリュームは、対応するマウントソースを、コンテナーパスにマウントします。 詳しい情報は、『ボリューム』をご参照ください。
      • クラウドストレージ: 3 種類のクラウドストレージ、クラウドディスク、NAS (Network Attached Storage) および OSS (Object Storage Service) をサポートしています。
      この例では、"disk-ssd" という名前のデータボリュームクレームをクラウドディスクタイプで設定し、 /data パスにマウントします。
    6. オプション: Log Service を設定します。 ログの収集方法および、このサービスのカスタムタグを設定します。
      注 Kubernetes クラスターがデプロイされ、クラスターにログプラグインがインストールされていることをご確認ください。

      ログの収集方法の設定は以下のようになります。

      • Log Store: 収集されたログを保存するために使用される、 Log Service で生成された Logstore を設定します。
      • コンテナー上のログパス: stdout およびテキストログをサポートします。
        • stdout: コンテナーの標準出力ログを収集します。
        • テキストログ: コンテナーの指定したパスでログを収集します。 このページの例では、パス "/var/log/nginx" にあるテキストログを収集します。 ワイルドカードもサポートされます。

      カスタムタグの設定もできます。 カスタムタグは、コンテナー出力ログへ収集されます。 カスタムタグは、コンテナーログのタグ付けに有用で、ログ統計やフィルタリングなどのログ解析を効率的に行うことができます。

  5. 設定が完了したら、[次へ] をクリックします。
  6. 詳細設定を行います。 このページの例では、アクセス設定のみ行います。
    1. [アクセス制御] を設定します。
      アプリケーションポッドを公開するメソッドを設定し、[作成] をクリックします。 この例では、[Cluster IP サービス] および [Ingress] を選択し、インターネットにアクセス可能な Nginx アプリケーションを作成します。
      注

      アプリケーションの通信要求に従って、アクセスメソッドを設定できます。

      • 内部アプリケーション：クラスター内でのみ実行されるアプリケーションです。 内部通信のためのクラスター IP またはノードポートに関するサービスを作成できます。
      • 外部アプリケーション：インターネットに公開される必要のあるアプリケーションです。 次の 2 つの方法のどちらかを使用して、アプリケーションにアクセスする方法を設定できます。
        • Server Load Balancer サービスを作成します。 Alibaba Cloud Server Load Balancer (SLB) を使用して、アプリケーションのインターネットアクセスを可能にします。
        • クラスター IP サービス、またはノードポートサービスを作成し、Ingress を作成します。 Ingress を使用して、インターネットアクセスを可能にします。 詳しくは、『Ingress』をご参照ください。
      1. サービスの右側にある [作成] をクリックします。 表示されたダイアログボックスでサービスを設定し、[作成] をクリックします。
        • 名前: サービス名を入力します。 デフォルトは、applicationname-svc です。
        • タイプ：サービスタイプを 1 つ選択します。
          • クラスター IP: クラスターの内部 IP アドレスを使用して、サービスを公開します。 このサービスタイプを選択すると、サービスはクラスター内でのみアクセス可能になります。
          • ノードポート: 各ノードの IP アドレスと静的ポート (NodePort) を使用して、サービスを公開します。 ノードポートサービスは、クラスター IP サービスへルーティングされます。これは自動的に作成されます。 <NodeIP>:<NodePort> をリクエスすることで、クラスターの外部から、ノードポートサービスにアクセスできます。
          • Server Load Balancer：Alibaba Cloud Server Load Balancer (SLB) サービス。 このタイプのサービスを使用して、アプリケーションのインターネットまたはイントラネットのアクセス方法を設定できます。 SLB インスタンスは、ノードポートサービスとクラスター IP サービスにルーティングできます。
        • ポートマッピング：サービスポートとコンテナーポートを追加し、TCP と UDP プロトコルを選択します。 ノードポート タイプ を選択した場合、ポートの競合を避けるためノードポートを設定する必要があります。
        • アノテーション: サービスにアノテーションを追加します。 SLB パラメーターを設定できます。 詳細は、「Server Load Balancer によるサービスへのアクセス」をご参照ください。
        • タグ：サービスを識別するために、サービスにタグを追加します。
      2. [Ingress] の右側にある [作成] をクリックします。 表示されたダイアログボックスで、アプリケーションポッドの Ingress ルールを設定し、[作成] をクリックします。 詳細は、「Ingress の設定」をご参照ください。
        注 イメージを使用してアプリケーションを作成した際、1 つのサービスにのみ Ingress ルールを作成できます。 このページの例では、仮想ホスト名をテスト用のドメイン名として使用します。 ホストへレコードの追加が必要です。 アプリケーションを作成する際、申請されたドメイン名を使用する必要があります。 
        101.37.224.146   foo.bar.com    # Ingress の IP アドレスです。
      3. アクセス制御エリアに、作成されたサービスと Ingress が表示されます。 [更新] または [削除] をクリックして、さらに設定を実行できます。
    2. オプション: HPA (Horizontal Pod Autoscaling) を設定します。
      有効にする チェックボックスをオンにして、HPA を有効化します。 Alibaba Cloud Container Service for Kubernetes では、さまざまなアプリケーション負荷に対応するため、ポッドの自動スケーリングを備えています。 そのため、コンテナー CPU およびメモリー使用量に応じて、ポッドの数を変更できます。
      注 この機能を使用するには、ポッドに必要なリソースを設定する必要があります。 設定しない場合、ポッドの自動スケーリングは有効になりません。 詳細は、一般的なコンテナー設定をご参照ください。
      • メトリック：リソースタイプです。 CPU またはメモリーが使用可能です。 このパラメーターには、必要なリソースタイプと同じリソースタイプを指定する必要があります。
      • 条件: リソース使用率のパーセンテージの値です。 リソースの使用量がこの値を超えると、コンテナーの数が増加します。
      • レプリカの最大数：StatefulSet アプリケーションが含むことができる、コンテナーの最大数です。
      • レプリカの最小数：StatefulSet アプリケーションが含むことができる、コンテナーの最小数です。
    3. オプション: スケジューリング を設定します。

      更新方法、ノードアフィニティ、ポッドアフィニティおよびポッドアンチアフィニティを設定できます。 詳細は、『Affinity and anti-affinity』をご参照ください。

      注 アフィニティスケジューリングは、タグおよびポッドタグに依存します。 ノードやポッドのスケジューリングには、ビルトインタグ、またはカスタムタグを使用できます。
      1. 更新方法 を設定します。

        RollingUpdate または 再作成(OnDelete) メソッドを選択して、古いポッドを新しいポッドに置き換えることができます。 詳細は、『Deployments』をご参照ください。

      2. ノードタグを使用して、[ノードアフィニティ] を設定します。
        必須ルールと推奨ルールをサポートしています。使用可能な演算子は、In、NotIn、Exists、DoesNotExist、Gt、および Lt です。
        • 必須ルールが満たされ、requiredDuringSchedulingIgnoredDuringExecution に対応している必要があります。 必須ルールは NodeSelector と同様の影響があります。 このページの例では、指定されたタグのあるモードにのみ、ポッドはスケジューリング可能です。

          複数の必須ルールーを追加できますが、ポッドのスケジューリングに必要なルールは 1 つだけです。

        • 推奨ルールは必ずしも満たされなくてもよく、preferredDuringSchedulingIgnoredDuringExecution に対応している必要があります。 この例のスケジューリング設定では、システムは、指定されたタグのあるノードにポッドをスケジューリングしないようにします。

          各推奨ルールには [ウェイト] を設定することもできます。 複数のノードが推奨ルールの条件を満たす場合、システムは、最も高いウェイトのあるノードにポッドをスケジューリングします。

          複数の推奨ルールを追加できますが、すべてのルールがポッドのスケジューリングの条件を満たしている必要があります。

      3. [ポッドアフィニティ] を設定し、他のポッドと共にトポロジドメインに、アプリケーションのポッドをデプロイします。 たとえば、互いに通信するサービス間のネットワーク遅延を減らすため、それらのポッドをトポロジドメイン (例：ホスト) にデプロイできます。

        ノードで実行中のポッドのタグに基づき、ポッドのスケージューリングを実行できます。 必須ルールおよび推奨ルールをサポートしています。使用可能な演算子は、In、NotIn、Exists、DoesNotExistです。

        • 必須 ルールが満たされ、requiredDuringSchedulingIgnoredDuringExecution に対応している必要があります。 必須ルールのすべての指定した条件は、ポッドアフィニティスケジューリングの条件を満たしている必要があります。
          • 名前空間：名前空間を設定します。 スケジューリングポリシーは、ポッドのタグに基づくため、このパラメーターは必須です。
          • トポロジキー：ポッドがスケジューリングされるトポロジドメインを設定します。 このパラメーターは、ノードタグによって有効になります。 たとえば、kubernetes.io/hostname をトポロジキーとして設定した場合、ノードはトポロジの特定に使用されます。 beta.kubernetes.io/os をトポロジとして指定した場合、ノードのオペレーティングシステムがトポロジの特定に使用されます。
          • セレクター：このボタンをクリックして、必須ルールを追加します。
          • アプリケーションリストの表示: [アプリケーションリストの表示] をクリックすると、ダイアログボックスが表示されます。 ダイアログボックスでは、各名前空間にアプリケーションを表示でき、ポッドアフィニティを設定するダイアログボックスに、アプリケーションタグをエクスポートできます。
          • 必須ルールタグ：既存のアプリケーションのタグ名、演算子、およびタグ値を設定します。 この例では、app：nginx でタグ付けされたアプリケーションが実行されるホストに対して、作成されるアプリケーションをスケジューリングします。
        • 推奨ルールは必ずしも満たされなくてもよく、preferredDuringSchedulingIgnoredDuringExecution に対応している必要があります。 ポッドアフィニティスケジューリングでは、必須ルールの指定された条件は、可能な限り満たされます。

          各推奨ルールに、ウェイトを設定できます。 ウェイト値の範囲は 1〜100 です。 複数のノードが推奨ルールの条件を満たす場合、システムは、最も高いウェイトのノードにポッドをスケジューリングします。 その他のパラメーターは、必須ルール設定と同じです。

      4. ポッドアンチアフィニティを設定し、他のポッドを除外するトポロジドメインにアプリケーションポッドをデプロイします。 ポッドアンチアフィニティスケジューリングを使用するシナリオ:
        • サービスの安定性を向上させるため、サービスのポッドをさまざまなトポロジドメイン (例：異なるホスト) に分配します。
        • ポッドに対し、ノードへの排他的なアクセスを許可し、ノードのリソースを他のポッドが使用しないようにします。
        • お互いに影響しあうサービスに関するポッドを異なるホストに分配します。
        注 ポッドアフィニティスケジューリングの設定と同じ方法を使用して、ポッドアンチアフィニティスケジューリングを設定できます。 ただし、同じスケジューリングルールでも、ポッドアンチアフィニティスケジューリングでは違う意味を持ちます。 必要に応じて、適切なスケジューリングルールを選択しなければなりません。
  7. [作成]をクリックします。
  8. アプリケーションの作成後、デフォルトで作成成功ページが表示され、アプリケーションに含まれるオブジェクトがリストされます。 [詳細の表示] をクリックし、デプロイの詳細を参照できます。

    デフォルトでは、[ステーフルセット] ページが表示されます。

  9. 左上隅の [リストに戻る] をクリックして、[ステーフルセットリスト] ページで作成した StatefulSet アプリケーションを参照できます。
  10. オプション: サービスの拡張性を確認するには、対象となる Nginx アプリケーションの右側の [スケール] をクリックします。
    1. 表示されたダイアログボックスで、ポッド数を 3 に設定します。 ポッドを拡張した際はポッドが増加順になり、ポッドを縮小した際はポッドが減少順になることがわかります。 これは、StatefulSet でのポッドの順序安定性を表しています。
    2. 左側のナビゲーションウィンドウで、[アプリケーション] > [ボリュームクレーム] をクリックすると、アプリケーションが拡張された場合、ポッドで新しいクラウドディスクボリュームが作成され、アプリケーションが縮小された場合、作成された PV または PVC は削除されないことがわかります。

次のタスク

マスターノードに接続し、以下のコマンドを実行して、永続ストレージの機能を確認します。

クラウドディスク上に一時ファイルを作成します。 
# kubectl exec nginx-1 ls /tmp           # このディレクトリのファイルのリストを表示します。
lost+found

# kubectl exec nginx-1 touch /tmp/statefulset         # "statefulset" という名前の一時ファイルを追加します。

# kubectl exec nginx-1 ls /tmp
lost+found
statefulset

ポッドを削除し、データの永続化を確認します。

# kubectl delete pod nginx-1
pod"nginx-1" deleted

# kubectl exec nginx-1 ls /tmp                         # データ永続ストレージ
lost+found
statefulset
さらに、ポッドを削除した後、ポッドがしばらくすると自動的に再起動することがわかります。これは、StatefulSet アプリケーションの高可用性を示しています。