このドキュメントでは、イメージを使用して、デプロイアプリケーションを作成する方法について説明します。 ここでは、インターネットにアクセス可能な Nginx アプリケーションを作成します。

始める前に

Kubernetes クラスターを ACK で作成します。 詳細は、「Kubernetes クラスターの作成」をご参照ください。

手順

  1. Container Service コンソール にログインします。
  2. Kubernetes の左側のナビゲーションウィンドウで、[アプリケーション] > [デプロイメント] を選択し、右上隅の [イメージから作成] をクリックします。
  3. [名前][クラスター][名前空間][レプリカ][タイプ][タグ]、および [アノテーション] を設定します。 レプリカパラメーターは、アプリケーションに含まれるポッドの数を示します。 続いて、[次へ] をクリックします。
    このページの例では、[デプロイメント] タイプを選択します。
    [名前空間] を設定しない場合、システムは自動的にデフォルトの名前空間を使用します。
  4. コンテナーの設定
    アプリケーションのポッドに対して複数のコンテナーを設定することができます。
    1. 一般的なコンテナーパラメーターを設定します。
      • イメージ名: 表示されたダイアログボックスで [イメージの選択] をクリックし、イメージを選択して、[OK] をクリックします。 この例では、Nginx イメージを選択します。

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

      • イメージバージョン: バージョンを選択するには、[イメージバージョンの選択] をクリックします。 イメージバージョンを選択しない場合、デフォルトでシステムにより最新のバージョンが使用されます。
      • [常にイメージをプル]: Container Service によりデプロイ効率を向上させるためイメージがキャッシュされます。 デプロイ中、新しく指定されたイメージのタグがキャッシュのイメージのタグと一致した場合、Container Service により、同じイメージを再度プルするよりも、キャッシュのイメージを再利用することが優先されます。 そのため、コードおよびイメージを変更する際に、イメージタグを変更しなかった場合、ローカルキャッシュ内の一番最初のイメージがアプリケーションのデプロイに使用されます。 [常にイメージをプル] チェックボックスをオンにすると、Container Service では、アプリケーションのデプロイの際に、確実に最新のイメージおよびコードが常に使用されるよう、キャッシュ内のイメージが無視され、イメージが再度プルされます。
      • イメージプルシークレット:イメージのシークレットを作成します。 シークレットは、プライベートイメージレポジトリからイメージをプルするために必要です。 詳細は、「イメージシークレットの利用」をご参照ください。
      • リソース制限: リソース (CPU とメモリ) の上限を指定します。これにより、アプリケーションによる過度のリソース占有を防ぐことができます。 CPU は、コアの数で計測されます。 メモリはバイト単位で計測され、MiB になります。
      • リソースリクエスト:アプリケーション用に予約するリソース (CPU とメモリ) の数を指定します 。 これらのリソースは、このパラメーターを使用して、コンテナーに排他的に設定することが可能です。 このパラメーターを設定しない場合、その他のサービスまたは、プロセスがリソースと競合します。 そのため、アプリケーションがリソース不足のために、使用できなくなる可能性があります。
      • Init Container: このチェックボックスをオンにすると、便利なツールを含んだ Init Container が作成されます。 詳しくは、『Init containers』 をご参照ください。
    2. オプション: 環境変数の設定

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

    3. オプション: ヘルスチェック設定

      Liveness プローブおよび Readiness プローブを設定できます。 Liveness プローブは、コンテナーの再起動時刻を検出します。 Readiness プローブは、コンテナーがトラフィックの受信が可能な状態かを判断します。 ヘルスチェックについての詳細は、『Configure Liveness, Readiness and Startup Probes』をご参照ください。

      リクエストメソッド 説明
      HTTP リクエスト このヘルスチェック方法で、HTTP GET リクエストをコンテナーへ送信できます。 以下のパラメーターがサポートされます。
      • プロトコル: HTTP または HTTPS です。
      • パス: HTTP サーバーへアクセスするパスです。
      • ポート: コンテナーにより開放されるアクセスポートの番号または名称です ポート番号は 1〜65535 である必要があります。
      • HTTP ヘッダー: 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. ライフサイクルルールを設定します。

      コンテナーのライフサイクルに、以下のパラメーター:開始、開始後および停止前を設定できます。 詳細についてついては、『Attach handlers to container lifecycle events』をご参照ください。

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

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

      • ローカルストレージ: HostPath、ConfigMap、シークレットおよび EmptyDir をサポートします。 ローカルストレージのタイプを設定することで、コンテナーパスへマウントソースをマウントできます。 詳しい情報は、『Volumes』をご参照ください。
      • クラウドストレージ: サポートしているクラウドストレージは、ディスク、NAS (Network Attached Storage) および OSS (Object Storage Service) です。
      この例では、ディスクをボリュームとして設定し、ディスクを /tmp コンテナーパスにマウントします。 このパスで生成されたコンテナーデータは、クラウドディスクに保存されます。
    6. オプション: Log Service を設定します。 収集パラメーターおよびカスタムタグを設定できます。
      Kubernetes クラスターがデプロイされ、クラスターにログプラグインがインストールされていることを確認してください。

      以下のログ収集パラメーターを設定します。

      • Log Store: Logstore を設定します。 Logstore 名を設定後、Log Service に Logstore が生成され、収集したログが保存されます。
      • コンテナー上のログパス: このパラメーターを "stdout" に設定、またはログパスを設定できます。
        • 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-nginx』をご参照ください。
      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) を設定します。
      [有効にする] チェックボックスをオンにして、HPA を有効化します。 Alibaba Cloud Container Service for Kubernetes では、さまざまなアプリケーション負荷に対応するため、ポッドの自動スケーリングを備えています。 そのため、コンテナー CPU およびメモリ使用量に応じて、ポッドの数を変更できます。
      この機能を使用するには、ポッドに必要なリソースを設定する必要があります。 設定しない場合、コンテナーの自動スケーリングは有効になりません。 詳細は、一般的なコンテナー設定をご参照ください。
      • メトリック:リソースタイプです。 CPU またはメモリが使用可能です。 このパラメーターには、必要なリソースタイプと同じリソースタイプを指定する必要があります。
      • 条件: リソース使用率のパーセンテージの値です。 リソースの使用量がこの値を超えると、コンテナーの数が増加します。
      • 最大レプリカ: デプロイに含めることができるコンテナーの最大数です。
      • 最小レプリカ: デプロイに含めることができるコンテナーの最小数です。
    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. アプリケーションを作成後、デフォルトで新しいページが表示され、アプリケーションを作成したこと、およびアプリケーションに含まれるオブジェクトが一覧表示されることを確認できます。[詳細] をクリックすると、デプロイの詳細を表示できます。

    デフォルトでは、[nginx-deployment] ページが表示されます。

  9. [ディスカバリとロードバランシング] > [Ingress] を選択し、ルールが Ingress リストに表示されていることを確認します。
  10. お使いのブラウザでテストドメイン名にアクセスし、 Nginx ウェルカムページにアクセスできることを確認します。