イメージを利用したデプロイアプリケーションの作成

Container Service コンソールにログインします。

Kubernetes で、左側のナビゲーションウィンドウから [アプリケーション] > [デプロイ] のクリックの後、右上角の [イメージから作成] をクリックします。

名前、クラスター、名前空間、レプリカおよびタイプを設定します。設定したレプリカパラメーターの値は、アプリケーションに含まれるポッドの数を示します。 [次へ] をクリックします。

注この例では、[デプロイ] タイプを選択します。

[名前空間] を設定していない場合、デフォルトではシステムによりデフォルトの名前空間が使われます。

コンテナーを設定します。

注アプリケーションのポッドに対して複数のコンテナーを設定できます。

アプリケーションに関する一般設定を行います。
- イメージ名: [イメージの選択] をクリックして表示されたダイアログボックス内のイメージを選択し、[OK] をクリックします。この例では、Nginx イメージを選択します。
  さらに、イメージの指定のため、プライベートレジストリを domainname/namespace/imagename:tag の形式で入力します。
- イメージバージョン: バージョンを選択するため、[イメージバージョンの選択] をクリックします。イメージバージョンを選択しない場合、デフォルトでシステムにより最新のバージョンが使用されます。
- 常にイメージをプルする: Container Service によりデプロイ効率を向上させるためイメージがキャッシュされます。デプロイ中、新しく設定されたイメージのタグがキャッシュのイメージのタグと一致した場合、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/をご参照ください。
オプション: 環境変数を設定します。

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

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

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


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

ライフサイクルルールを設定します。
コンテナーのライフサイクルに関する以下のパラメーターを設定できます: コンテナー設定スタート、ポストスタートおよびプレストップ。詳しい情報は、『https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/』をご参照ください。
- コンテナー設定: [stdin] チェックボックスをオンにすると、コンテナーへの標準入力が有効になります。 [tty] チェックボックスをオンにすると、コンテナーへの仮想ターミナルを割り当てます。これにより、コンテナーへシグナルを送ることができます。通常、これら 2 つのオプションは併用されます。これは、ターミナル (tty) をコンテナー標準入力 (stdin) にバインドすることを示します。たとえば、対話型プログラムは、ユーザーから標準入力を取得し、取得した標準入力をターミナルに表示します。
- スタート: コンテナーへの開始前コマンドおよびパラメーターを設定します。
- ポストスタート: コンテナーへの開始後のコマンドを設定します。
- プレストップ: コンテナーへの終了前コマンドを設定します。
オプション: データボリュームを設定します。
ローカルストレージおよびクラウドストレージの設定ができます。
- ローカルストレージ: ホストパス、コンフィグマップ、シークレットおよび一時ディレクトリをサポートします。ローカルデータボリュームはコンテナーパスの対応するマウントソースにマウントされます。詳しい情報は、『ボリューム』をご参照ください。
- クラウドストレージ: 3 つの種類のクラウドストレージをサポートします: クラウドディスク、NAS (Network Attached Storage) および OSS (Object Storage Service) です。
このページの例では、クラウドディスクをデータボリュームとして設定し、クラウドディスクをコンテナーパス /tmp にマウントします。このパスで生成されたコンテナーデータはクラウドディスクに保存されます。
オプション: Log Service を設定します。ログの収集方法および、このサービスへのカスタムタグを設定します。
注 Kubernetes クラスターがデプロイされ、クラスターにログプラグインがインストールされていることを確認してください。

ログの収集方法の設定は以下のようになります:
- Log Store: 収集されたログを保存するために使用される Log Service で生成された Logstore を設定します。
- コンテナー上のログパス: stdout およびテキストログをサポートします。
  - stdout: コンテナーの標準出力ログを収集します。
  - テキストログ: コンテナー上の指定したパスでのログを収集します。このページの例では、パス "/var/log/nginx" にあるテキストログを収集します。ワイルドカードもサポートされます。
カスタムタグの設定もできます。カスタムタグはコンテナー出力ログへ収集されます。カスタムタグはコンテナーログのタグ付けに有用で、ログ統計やフィルタリングなどのログ解析を効率的に行うことができます。

設定が完了したら、[次へ] をクリックします。

詳細設定を行います。

アクセス制御を設定します。
バックエンドポッドの公開方法を設定できます。[作成] をクリックします。この例では、[Cluster IP サービス] および [Ingress] を選択し、インターネットにアクセス可能な nginx アプリケーションを作成します。
注
アプリケーションの通信要件を満たすため、ニーズに応じたアクセス制御を設定できます:
- 内部アプリケーション: クラスター内でのみ実行されるアプリケーションで、必要に応じて内部通信のためのクラスター IP またはノードポートに関するサービスを作成できます。
- 外部アプリケーション: インターネットに公開される必要のあるアプリケーションで、以下の方法のうち 1 つを使ってアクセス制御を設定できます。
  
  Server Load Balancer サービスの作成: Alibaba Cloud による SLB (Server Load Balancer) サービスを使用します。これにより、アプリケーションによるインターネットへのアクセスが可能にします。
  
  ClusterIP または NodePort の作成および Ingress の作成: この方法では Ingress を通じてインターネットへのアクセスを提供します。詳細については、https://kubernetes.io/docs/concepts/services-networking/ingress/をご参照ください。
1. サービスの右側にある [作成] をクリックします。表示されたダイアログボックスでサービスを設定し、[作成] をクリックします。
  - 名前: カスタマイズ名を入力できます。デフォルトでは、applicationname-svc となっています。
  - タイプ: 以下の 3 つのサービスタイプから 1 つを選びます。
    - ClusterIP: クラスターの内部 IP アドレスを使用してサービスを公開します。このタイプを選択すると、サービスはクラスター内でのみアクセスできます。
    - NodePort: それぞれのノードで IP アドレスおよび静的ポート (NodePort) を使用してサービスを公開します。 NodePort サービスは ClusterIP サービスへルーティングされます。これは自動的に作成されます。 <NodeIP>:<NodePort> リクエストによりクラスター外部の NodePort サービスへアクセスできます。
    - Server Load Balancer: Server Load Balancer サービスです。これは Alibaba Cloud により提供されます。このタイプのサービスを使用して、インターネットアクセスまたはイントラネットアクセスを設定できます。 Server Load Balancer は NodePort サービスおよび ClusterIP サービスへルーティングされます。
  - ポートマッピング: サービスポートおよびコンテナーポートを追加します。タイプに [NodePort] を選択した場合、ポートの競合を避けるためノードポートを設定する必要があります。 TCP プロトコルおよび UDP プロトコルがサポートされます。
  - アノテーション: サービスへアノテーションを追加します。 Server Load Balancer 設定パラメーターがサポートされます。詳しくは、Server Load Balancer によるサービスへのアクセスをご参照ください。
  - ラベル: サービスへラベルを追加し、サービスを識別できます。
2. イングレスの右側にある [作成] をクリックします。表示されたダイアログボックスで、バックエンドポッドへのルートに関するルールを設定し、[作成] をクリックします。ルートの設定に関する詳しい情報は、Ingress の設定を参照してください。
  注イメージを使用してアプリケーションを作成した際、1 つのサービスにのみイングレスを作成できます。このページの例では仮想ホスト名をテスト用のドメイン名として使用します。ホストへレコードの追加が必要です。実際の作業シナリオでは、登録されたドメイン名を使用します。
  101.37.224.146 foo.bar.com # Ingress の IP アドレス
3. 作成されたサービスおよび Ingress がアクセス制御セクションに表示されます。サービスおよび Ingress を再度設定するには、[更新] および [削除] をクリックします。
オプション: HPA (Horizontal Pod Autoscaling) を設定します。
HPA を有効化するかどうか選択することができます。さまざまな負荷状況でアプリケーションの要求を満たすために、Container Service によりコンテナーのオートスケーリングがサポートされます。これにより、コンテナーの CPU およびメモリーの使用率に応じて、コンテナーの数を自動的に調整します。

注オートスケーリングを有効化するために、デプロイに関して必要なリソースを設定する必要があります。設定しない場合、コンテナーオートスケーリングは有効になりません。コンテナーの基本設定をご参照ください。
- 測定: CPU およびメモリーです。必要に応じてリソースタイプを設定します。
- 条件: リソース使用率のパーセンテージでの値です。リソース使用率がこの値を超えたとき、コンテナーの拡張が始まります。
- レプリカの最大数: デプロイが拡張することができるレプリカの最大数です。
- レプリカの最小数: デプロイが縮小させることができるレプリカの最少数です。
オプション: スケジューリングアフィニティを設定します。
ノードアフィニティ、ポッドアフィニティおよびポッドアンチアフィニティを設定できます。詳しくは、『https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity』をご参照ください。

注アフィニティスケジューリングは、タグおよびポッドタグよって行われます。ビルトインタグを使って、あらかじめ設定したノードおよびポッドへのタグと同様にスケジューリングすることができます。
1. ノードタグの設定で、ノードアフィニティを設定します。
  ノードスケジューリングは、必須ルールと優先ルール、および "In"、"NotIn"、"Exists"、"DoesNotExist"、"GT" および "LT" のようなさまざまな演算子のどちらもサポートしています。
  - 必須ルールが満たされ、requiredDuringSchedulingIgnoredDuringExecution に対応している必要があります。必須ルールは NodeSelector と同様の影響を持ちます。このページの例では、ポッドが対応するタグがあるノードのみスケジューリングされます。複数の必須ルールを追加できますが、そのうち 1 つにのみ合致する必要があります。
  - 優先ルールは必ずしも満たされなくてもよく、preferredDuringSchedulingIgnoredDuringExecution に対応している必要があります。この例では、スケジュールは、対応するタグがあるノードにはスケジューリングを行いません。優先ルールには重み付けをすることができます。条件を満たす複数のノードが存在する場合、最も大きな重みが付けられたノードが優先されたスケージューリングが行われます。複数の優先ルールを定義できますが、全てのルールはスケジューリングの前に満たされている必要があります。
2. ポッドアフィニティを設定し、他のポッドと共にトポロジドメイン上のアプリケーションのノードをデプロイします。たとえば、お互いに通信しあうサービスは、ポッドアフィニティスケジューリングの設定によりサービス間のネットワークの遅延が低減されるため、同じトポロジドメイン (ホストと同様) へデプロイされます。
  
  ノードで実行中のポッドのタグに基づいて、ポッドのスケージューリングが行われます。使用可能な式は、In、 NotIn、Exists、DoesNotExist です。
  - 必須ルールが満たされ、requiredDuringSchedulingIgnoredDuringExecution に対応している必要があります。ポッドアフィニティスケジューリングは設定されたルールを合致する必要があります。
    - 名前空間: スケジューリングポリシーはポッドタグに基づいており、名前空間に制約を受けます。
    - トポロジキー: ノードタグを通じてスケジューリングするドメインを指定します。たとえば、kubernetes.io/hostname をトポロジキーとして設定した場合、ノードはトポロジの定義に使用されます。 beta.kubernetes.io/osをトポロジとして指定した場合、ノードのオペレーティングシステムがトポロジの定義に使用されます。
    - セレクター: セレクターの右にある [追加] ボタンをクリックすると、強い制約を持つルールを追加できます。
    - アプリケーションリストの表示: [アプリケーションリストの表示] をクリックすると、ダイアログボックスが表示されます。ダイアログボックスで、それぞれの名前空間のアプリケーションを参照でき、アプリケーションのタグをアフィニティ設定ダイアログボックスにエクスポートできます。
    - 強い制約: 既存のアプリケーション、演算子およびタグの値に対するタグを設定できます。この例では、app: nginx タグのあるアプリケーションを実行するホストに対しアプリケーションを作成するようスケジューリングします。
  - 優先ルール、つまり、緩い制約を持ったルールは、preferredDuringSchedulingIgnoredDuringExecution に対応しています。ポッドアフィニティスケジューリングは設定したルールにできるだけ早く満たされます。緩い制約を持ったルールに関しては、それぞれのルールに重み付けすることができます。他の設定要件は、強い制約を持つルールと同様なものになります。
    
    注 Weight: 1 つの緩い制約を持つルールに対して 1 から 100 の範囲で weight を設定します。設定された緩い制約を持つルールを満足するノードの weight はアルゴリズムによって算出され、最も大きな weight を持つノードに対してポッドがスケジューリングされます。
3. ポッドアンチアフィニティを設定し、他のボッドを含むトポロジドメイン上でアプリケーションのポッドをデプロイします。ポッドアンチアフィニティスケジューリングを使用するシナリオ:
  - サービスのポッドを、異なるトポロジドメイン (ホストなど) へ分配し、サービスの安定性を向上させます。
  - ポッドに対し、ノードへの排他的なアクセスを承認し、ノードのリソースを他のポッドが使用しないことを保証します。
  - お互いに影響しあうサービスに関するポッドを異なるホストに分配します。
  注ポッドアンチアフィニティスケジューリングの設定方法は、ポッドアフィニティのスケジューリングと同様のものです。ただし、同じスケジューリングルールでもポッドアンチアフィニティスケジューリングでは違う意味を持ちます。シナリオをもとに適切なスケジューリングルールを選択します。