ここでは、イメージを使用して NGINX アプリケーションを作成し、サンドボックスコンテナーでインターネットにアクセスできるようにする方法について説明します。

始める前に

サンドボックスコンテナーをサポートする Kubernetes クラスターを作成していること。 詳細については、「 サンドボックス化コンテナーをサポートする Kubernetes クラスターの作成」をご参照ください。

このタスクについて

サンドボックスコンテナーでアプリケーションを作成するには、下記の表で必要に応じて次のパラメーターを指定する必要があります。
パラメーター 説明
クラスター クラスターがサンドボックスコンテナーをサポートしていることをご確認ください。
ラベル アプリケーションがサンドボックスコンテナーで実行されることを示すラベルを追加します。

手順

  1. 次に、左側のナビゲーションペインで、[アプリケーション] > [デプロイメント] を選択し、右上隅の [イメージによる作成] をクリックします。
  2. 次のパラメーターを指定します。 名前クラスター名前空間レプリカタイプコンテナーランタイム注釈、および ラベル。 [レプリカ] パラメーターは、アプリケーションに含まれるポッドの数を示します。 [次へ] をクリックします。
    • この例では、アプリケーションの種類として [デプロイメント] を選択します。
    • コンテナーランタイムruncrunvのいずれかを選択できます。 デフォルトはruncです。

    [名前空間] パラメーターを指定しない場合、デフォルトの名前空間が使用されます。

  3. コンテナーの設定
    ポッドで実行する複数のコンテナーを設定できます。
    1. 一般的な設定を行います。
      • イメージ名[イメージの選択] を選択し、表示されるダイアログボックスでイメージを選択します。 この例では、NGINXを選択して [OK] をクリックします。

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

      • イメージバージョン: バージョンを選択するには、[イメージバージョンの選択] をクリックします。 イメージバージョンを指定しない場合、デフォルトで最新バージョンが使用されます。
      • 常にイメージをプル:読み込み効率を向上させるために、Container Serviceはイメージをキャッシュします。 Container Serviceがアプリケーションをデプロイするときに、指定されたイメージバージョンがキャッシュされたイメージバージョンと同じである場合、キャッシュされたイメージは再利用されます。 したがって、コードを更新するときに、上位層のビジネスをサポートするなどの理由でイメージバージョンを同じままにすると、以前にキャッシュされたイメージが使用されます。 このチェックボックスがオンの場合、Container Serviceは常にアプリケーションをデプロイするためにリポジトリからイメージをプルします。 これにより、最新のイメージとコードが使用されます。
      • イメージの秘密鍵の設定[イメージの秘密鍵の設定]をクリックし、イメージの秘密鍵を設定します。 プライベートリポジトリにアクセスする必要がある場合は、シークレットを設定する必要があります。イメージシークレットの利用
      • リソース制限:このアプリケーションで使用できるCPUおよびメモリリソースの上限。 これにより、アプリケーションが過剰なリソースを使用するのを防ぎます。 CPU使用率はコアで測定されます。 メモリ使用量はMiBで測定されます。
      • 必要リソース:このアプリケーション用に予約されているCPUおよびメモリリソースの量。 これらのリソースはコンテナー専用です。 これにより、他のサービスまたはプロセスがリソースをめぐって競合する場合に、アプリケーションが使用できなくなることを防ぎます。
      • コンテナー初期化 :このオプションを選択すると、システムは便利なツールを含む初期化コンテナを作成します。 詳細については、「https://kubernetes.io/docs/concepts/workloads/pods/init-containers/」をご参照ください。
      一般的な設定
    2. オプション: 環境変数を設定します。

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

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

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

      ヘルスチェック
      リクエストタイプ 説明
      HTTP リクエスト HTTP GETリクエストをコンテナに送信します。 パラメーターは次のとおりです。
      • プロトコル: HTTP または HTTPS。
      • パス:サーバー上の要求されたパス。
      • ポート: サービスで開放されるポートです。 ポート番号は 1〜65535 である必要があります。
      • HTTP ヘッダー: HTTP リクエストでのカスタマイズされたヘッダーです。 ヘッダーの重複は許可されています。 キーと値のペアがサポートされています。
      • 遅延検出時間 (秒): initialDelaySecondsフィールド。 コンテナの起動後、最初のプローブを実行する前に待機する時間(秒単位)。 デフォルトは3です。
      • 実行検出周期 (秒): periodSecondsフィールド。 プローブを実行する頻度(秒単位)。 デフォルトは10です。 最小値は1です。
      • タイムアウト時間 (秒): timeoutSecondsフィールド。 プローブがタイムアウトするまでの時間(秒単位)。 デフォルトは1です。 最小値は1です。
      • 正常のしきい値:プローブが失敗した後に成功したと見なされるために発生する必要がある連続した成功の最小数。 デフォルトは1です。 最小値は1です。 有効性チェックの場合、このパラメーターは1に設定する必要があります。
      • 異常のしきい値:成功した後にプローブが失敗したと見なされるために発生する必要がある連続した失敗の最小数。 デフォルトは 3 です。 最小値は 1 です。
      TCP 接続 コンテナにTCPソケットを送信します。 kubelet は、指定されたポートで、コンテナーへのソケットの作成を試みます。 接続が確立された場合、コンテナーは正常とみなされます。 接続されなかった場合、異常であるとみなされます。 パラメーターは次のとおりです。
      • ポート: サービスで開放されるポートです。 ポート番号は 1〜65535 である必要があります。
      • 遅延検出時間 (秒): initialDelaySecondsフィールド。 コンテナの起動後、最初のプローブを実行する前に待機する時間(秒単位)。 デフォルトは15です。
      • 実行検出周期 (秒): periodSecondsフィールド。 プローブを実行する頻度(秒単位)。 デフォルトは10です。 最小値は1です。
      • タイムアウト時間 (秒): timeoutSecondsフィールド。 プローブがタイムアウトするまでの時間(秒単位)。 デフォルトは1です。 最小値は1です。
      • 正常のしきい値:プローブが失敗した後に成功したと見なされるために発生する必要がある連続した成功の最小数。 デフォルトは1です。 最小値は1です。 有効性チェックの場合、このパラメーターは1に設定する必要があります。
      • 異常のしきい値:成功した後にプローブが失敗したと見なされるために発生する必要がある連続した失敗の最小数。 デフォルトは3です。 最小値は1です。
      コマンドライン コンテナでプローブコマンドを実行して、ヘルスステータスを確認します。 パラメーターは次のとおりです。
      • コマンド:コンテナーの正常性状態を確認するために使用されるプローブコマンド。
      • 遅延検出時間 (秒): initialDelaySecondsフィールド。 コンテナの起動後、最初のプローブを実行する前に待機する時間(秒単位)。 デフォルトは5です。
      • 実行検出周期 (秒): periodSecondsフィールド。 プローブを実行する頻度(秒単位)。 デフォルトは10です。 最小値は1です。
      • タイムアウト時間 (秒): timeoutSecondsフィールド。 プローブがタイムアウトするまでの時間(秒単位)。 デフォルトは1です。 最小値は1です。
      • 正常のしきい値:プローブが失敗した後に成功したと見なされるために発生する必要がある連続した成功の最小数。 デフォルトは 1 です。 最小値は 1 です。 有効性チェックの場合、このパラメーターは1に設定する必要があります。
      • 異常のしきい値:成功した後にプローブが失敗したと見なされるために発生する必要がある連続した失敗の最小数。 デフォルトは 3 です。 最小値は 1 です。
    4. ライフサイクルイベントを設定します。

      次のパラメーターを指定して、コンテナーのライフサイクルを設定します:Start、postStart、および preStop。 詳しい情報は、『https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/』をご参照ください。

      • 開始:Start コマンドとパラメーター。
      • 開始後:postStart コマンド。
      • 停止前 :preStop コマンド。
      ライフサイクルの設定
    5. オプション: ボリュームを設定します。

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

      • ローカルストレージ: ホストパス (hostPath)、コンフィグマップ (configmap)、シークレット (secret) および一時ディレクトリをサポートしています。 対応するボリュームをコンテナーのパスにマウントする必要があります。 詳しい情報は、『Volumes』をご参照ください。
      • クラウドストレージ:クラウドディスク、NAS、OSSの3種類のPVをサポートします。
      この例では、クラウドディスクタイプのPVを選択し、PVをコンテナー内の /tmpパスにマウントします。 このパスで生成されたデータはクラウドディスクに保存されます。
      ボリュームの設定
  4. 必要に応じて、他のパラメーターを指定し、[次へ]をクリックします。
  5. 詳細設定を行います。
    1. アクセス制御を設定します。
      ポッドを公開する方法を設定し、 [作成]をクリックし、アプリケーションを作成します。 この例では、ClusterIPタイプのサービスとIngressを作成して、アプリケーションがインターネットにアクセスできるようにします。

      必要に応じてアクセス制御を設定できます。

      • 内部アプリケーション: クラスター内でのみ実行されるアプリケーションで、必要に応じて内部通信のためのClusterIP または NodePort に関するサービスを作成できます。
      • 外部アプリケーション: インターネットに公開される必要のあるアプリケーションで、以下の方法のうち 1 つを使ってアクセス制御を設定できます。
        • Server Load Balancerタイプのサービスを作成し、SLBインスタンスを介してアプリケーションをインターネットに公開します。
        • ClusterIPまたはNodePortタイプのサービスを作成し、Ingressを作成し、Ingressを介してアプリケーションをインターネットに公開します。 詳細については、「https://kubernetes.io/docs/concepts/services-networking/ingress/」をご参照ください。
      アプリケーションを作成1
      1. サービスを作成するには、 [アクセス制御]セクションで[作成]をクリックします。 表示されるダイアログボックスでサービスを設定し、[作成]をクリックします。
        アプリケーション2 の作成
        • 名前: サービス名を入力します。 デフォルトは、applicationname-svc です。
        • タイプ: 以下の 3 つのサービスタイプから 1 つを選びます。
          • ClusterIP: クラスターの内部 IP アドレスを使用して、サービスを公開します。 このタイプを選択すると、サービスはクラスター内からのみアクセスできます。
          • NodePort: それぞれのノードで IP アドレスおよび静的ポート (NodePort) を使用してサービスを公開します。 NodePort サービスは、システムによって自動的に作成される ClusterIP サービスにリクエストをルーティングできます。 <NodeIP>:<NodePort> をリクエスすることで、クラスターの外部から NodePort サービスへアクセスできます。
          • Server Load Balancer:インターネットアクセスまたは内部アクセスをサポートするSLBインスタンスを介してサービスを公開します。 SLBインスタンスは、リクエストを NodePort および ClusterIP サービスにルーティングできます。
        • ポートマッピング: サービスポートおよびコンテナーポートを追加します。 もしタイプパラメーターが NodePort に設定されている場合、ポートの競合を避けるためにノードポートを設定する必要があります。 TCP プロトコルおよび UDP プロトコルがサポートされます。
        • 注釈:注釈をアプリケーションに追加します。 SLBパラメーターがサポートされています。 詳細については、「Server Load Balancer を使用してサービスにアクセスする」をご参照ください。
        • タグ: ボリュームにタグを追加します。
      2. Ingress を作成するには、[アクセス制御] セクションで、[作成]をクリックします。 表示されるダイアログボックスで Ingress ルールを設定し、[作成]をクリックします。 Ingress の設定について詳しくは、「Ingress の設定」をご参照ください。
        イメージを使用してアプリケーションを作成した際、1 つのサービスにのみ Ingress ルールを作成できます。 この例では仮想ホスト名をテスト用のドメイン名として使用します。 ホストへレコードの追加が必要です。 実際のシナリオでは、ICP 登録を取得したドメインを使用します。
        101.37.224.146   foo.bar.com    #The IP address of the Ingress
        ルーティングルールの設定
      3. [アクセス制御] セクションで、新しく作成されたサービスとIngressを見つけることができます。 [更新]もしくは[削除]をクリックし、変更を行います。
        ルーティングルールの変更と削除
    2. オプション: HPA (Horizontal Pod Autoscaling) を設定します。
      HPAを有効にし、 CPUとメモリの使用率に基づいてポッドの数を自動的にスケーリングします。 これにより、アプリケーションをさまざまな負荷レベルでスムーズに実行できます
      HPAの設定
      HPAを有効にするには、コンテナのスケーリングをサポートするリソースを設定する必要があります。 そうでない場合、HPAは有効になりません。 詳細は、一般設定のセクションをご参照ください。
      • メトリック:CPUとメモリをサポートします。 リソースタイプは、[必要なリソース]フィールドで指定したものと同じでなければなりません。
      • 条件 :リソース使用量のしきい値を指定します。 HPAは、しきい値を超えるとクラスターのスケールアップを開始します。
      • 最大 レプリカ数: デプロイメントが拡張できるレプリカの最大数。
      • 最小 レプリカ数:デプロイメントが実行し続けられるレプリカの最小数。
    3. オプション: [スケジューリング]の設定。

      次のパラメーターを指定できます:更新方法、ノードアフィニティ、ポッドアフィニティ、およびポッドアンチアフィニティ。 詳しくは、『https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity』をご参照ください。

      アフィニティ機能により、ノードラベルとポッドラベルに基づいたスケジューリングが容易になります。 組み込みのラベルを使用するか、ニーズに基づいてカスタムラベルを追加できます。
      1. [更新方法] を設定します。

        ローリングアップデート (RollingUpdate) と 再作成 (Recreate) から選択できます。 詳細については、「https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/」をご参照ください。

      2. [ノードアフィニティ] ルールを設定します。
        ノードアフィニティを設定する
        ノードスケジューリングは、必須 (Required) ルールと推奨 (Preferred) ルール、ならびに In、NotIn、Exists、DoesNotExist、GT および LT のようなさまざまな演算子のどちらもサポートしています。
        • [必須] は満たさなければならないもので、nodeAffinity のrequiredDuringSchedulingIgnoredDuringExecution フィールドで指定されます。 必須ルールは NodeSelector と同様の影響を持ちます。 この例では、ポッドは特定のラベルを持つノードにのみスケジュールできます。 必須ルールを1つだけ満たすように、複数の必要なルールを作成できます。
        • [推奨] は満たされない可能性があるもので、nodeAffinity. のpreferredDuringSchedulingIgnoredDuringExecution フィールドで指定されます。 この例では、スケジューラーは、特定のラベルを持つノードにポッドをスケジュールしないようにしています。 推奨ルールには重み付けをすることができます。 複数のノードがルールに一致する場合、重みが最も高いノードが優先されます。 ポッドをスケジュールする前に、すべてのルールが満たされるように、複数の推奨ルールを作成できます。
      3. [ポッドアフィニティ] ルールを設定します。 これらのルールは、同じトポロジードメイン内の他のポッドに関連してポッドをデプロイする方法を指定します。 たとえば、ポッドアフィニティルールを使用して、相互に通信するサービスをホストなどの同じトポロジードメインに展開できます。 これにより、これらのサービス間のネットワーク遅延を削減できます。
        ポッドアフィニティを設定する

        ポッドアフィニティを使用すると、他のポッドのラベルに基づいて、ポッドをスケジュールできるノードを指定できます。 この機能は、必須および推奨ルール、および次の演算子をサポートしています。 In, NotIn, Exists, DoesNotExist

        • [必須] ルールは満たさなければならず、podAffinity のrequiredDuringSchedulingIgnoredDuringExecution フィールドで指定されます。 ポッドをノードにスケジュールする前に、必須ルールを満たす必要があります。
          • 名前空間:ルールはポッドのラベルに基づいて定義されているため、名前空間にスコープする必要があります。
          • トポロジードメイン:topologyKey を指定します。これは、システムがトポロジードメインを示すために使用するノードラベルのキーです。 たとえば、パラメーターを kubernetes.io/hostname に設定した場合 、ノードはトポロジーを決定するために使用されます。 beta.kubernetes.io/osに設定した場合、ノードのオペレーティングシステムを使用してトポロジーを決定します。
          • セレクター:[追加] をクリックして、複数の必須ルールを追加します。
          • アプリケーションリストを表示する:表示されるダイアログボックスで[アプリケーションリストを表示する] をクリックし、名前空間とアプリケーションを指定します。 選択したアプリケーションのラベルを表示して、ルール設定ページに追加できます。
          • 必須:既存のアプリケーションのラベル、演算子、およびラベル値を指定します。 この例では、app: nginx ラベルのあるアプリケーションを実行するホストに対しアプリケーションを作成するようスケジューリングします。
        • [推奨] ルールは満たされない可能性があり、 podAffinity のpreferredDuringSchedulingIgnoredDuringExecution フィールドで指定されます。 必須ルールは、ルールが満たされた場合、スケジューラーがルールの強制を試みることを指定します。 必須ルールには重み付けをすることができます。 他のパラメーターは、必須ルールのパラメーターと同じです。

          ウェイト:必須ルールの重みを 1〜100 の値に設定します。 スケジューラーは、アルゴリズムに基づいてルールを満たす各ノードの重みを計算し、ポッドを最大の重みを持つノードにスケジュールします。

      4. ポッドアンチアフィニティ ルールを設定し、特定のラベルを持つ他のポッドがすでにデプロイされている同じトポロジーにポッドをスケジュールしないようにします。 ポッドアンチアフィニティルールは、次のシナリオで使用できます。
        • サービスのポッドを、異なるトポロジードメイン (複数ホストなど) へ分配し、サービスの安定性を向上させます。
        • ノードへのポッドの排他的アクセスを許可します。 これにより、リソースが分離され、他のポッドが指定されたノードを共有できないことが保証されます。
        • これらのポッドが相互に干渉する可能性がある場合は、サービスのポッドを異なるホストにスケジュールします。
        ポッドアンチアフィニティルールのパラメーターは、ポッドアフィニティルールのパラメーターと同じです。 さまざまなシナリオに基づいてルールを作成します。
  6. [作成] をクリックします。
  7. アプリケーションが作成されると、完了ページにリダイレクトされます。 アプリケーションの下でリソースオブジェクトを見つけて、[詳細の表示] をクリックし、アプリケーションの詳細を確認します。
    詳細の確認

    nginx-deployment の詳細ページが表示されます。

    詳細を表示 2
    次のようにIngressとサービスを作成することもできます。前のページで、 [アクセス方法] タブをクリックします。
    • [サービス] のとなりの[作成]をクリックします。 6.a.i. で紹介されている手順に従って、サービスを作成します。
    • Ingress のとなりの[作成]をクリックします。 6.a.ii. で紹介した手順に従って、Ingressを作成します。
  8. 左側のナビゲーションペインで、[ディスカバリとロードバランシング] > [Ingress] を選択します。 新しく作成された Ingress は、このページで参照できます。
    ルーティングルール
  9. ブラウザにテストドメインを入力し、Enter キーを押します。 NGINXの Welcome ページが表示されます。
    NGINXウェルカムページ