Config Controller にサードパーティのワークロードをデプロイする

このページでは、Config Controller クラスタに独自のワークロードをデプロイする方法について説明します。

このページは、基盤となる技術インフラストラクチャのライフサイクル管理と、容量の計画を行い、アプリとサービスを本番環境にデプロイする IT 管理者とオペレーターを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーロールとタスクをご覧ください。

始める前に

開始にあたり、次の作業が完了していることを確認してください。

  1. Config Controller を設定する。
  2. 1.27 より前のバージョンの GKE で Config Controller クラスタが動作している場合、バージョン 1.27 以降にクラスタをアップグレードする。

Standard クラスタでノード自動プロビジョニングを有効にする

Config Controller クラスタに独自のワークロードをデプロイするには、ノード自動プロビジョニングを有効にする必要があります。そうすることで、ご利用のワークロードと、Config Controller クラスタにデフォルトでインストールされている Google マネージド ワークロードの間のワークロードを分離できます。

Autopilot クラスタを使用する場合は、GKE でノードのスケーリングとプロビジョニングが自動的に管理されるため、ノード自動プロビジョニングを有効にする必要はありません。

gcloud

ノード自動プロビジョニング機能を有効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --min-cpu MINIMUM_CPU \
    --min-memory MIMIMUM_MEMORY \
    --max-cpu MAXIMUM_CPU \
    --max-memory MAXIMUM_MEMORY \
    --autoprovisioning-scopes=https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/devstorage.read_only

次のように置き換えます。

  • CLUSTER_NAME: Config Controller クラスタの名前。
  • MINIMUM_CPU: クラスタの最小コア数。
  • MINIMUM_MEMORY: クラスタの最小メモリ量（GB）。
  • MAXIMUM_CPU: クラスタの最大コア数。
  • MAXIMUM_MEMORY: クラスタの最大メモリ量（GB）。

コンソール

ノードの自動プロビジョニングを有効にするには、次の操作を行います。

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. クラスタの名前をクリックします。

  3. [自動化] セクションの [ノード自動プロビジョニング] で、[編集] をクリックします。

  4. [ノード自動プロビジョニングを有効にする] チェックボックスをオンにします。

  5. クラスタの CPU およびメモリ使用量の最小値と最大値を設定します。

  6. [変更内容を保存] をクリックします。

デフォルトの設定など、ノード自動プロビジョニングの構成について詳しくは、ノードの自動プロビジョニングの構成についてのページをご覧ください。

ワークロードをデプロイする

ワークロードをデプロイすると、Config Controller は GKE Sandbox を自動的に有効にして、信頼できないコードがクラスタノードのホストカーネルに影響を与えないようにセキュリティを強化します。詳細については、GKE Sandbox の概要についてのページをご覧ください。

ワークロードをデプロイするには、ワークロード マニフェスト ファイルを作成し、次のコマンドを実行します。

kubectl apply -f WORKLOAD_FILE

WORKLOAD_FILE は、マニフェスト ファイル（my-app.yaml など）で置き換えます。

自動プロビジョニングされたノードでワークロードが実行されていることを確認します。

  1. ワークロード用に作成されたノードのリストを取得します。

    kubectl get nodes

  2. 特定のノードを検査します。

    kubectl get nodes NODE_NAME -o yaml

    NODE_NAME は、検査するノードの名前に置き換えます。

制限事項

  • GKE Sandbox: GKE Sandbox は多くのアプリケーションで動作していますが、すべてのアプリケーションに対応しているわけではありません。詳細については、GKE Sandbox の制限事項をご覧ください。
  • コントロール プレーンのセキュリティ: ワークロード関する権限を付与する場合は、最小権限の原則に従って、必要な権限のみを付与します。ワークロードが侵害された場合、そのワークロードは過度に緩い権限を使って Kubernetes リソースを変更または削除できます。
  • コントロール プレーンの可用性: ワークロードによってトラフィックが短期間で増加すると、トラフィックが減少するまでクラスタ コントロール プレーンが使用できなくなる可能性があります。
  • コントロール プレーンのサイズ変更: GKE は必要に応じてコントロール プレーンのサイズを自動的に変更します。ワークロードによって負荷が大幅に増加する場合（数千の CRD オブジェクトをインストールする場合など）、GKE の自動サイズ変更では負荷の増加に対応できない場合があります。
  • 割り当て: ワークロードをデプロイする際は、GKE の割り当てと上限に注意し、それを超えないようにする必要があります。
  • コントロール プレーンとノードへのネットワーク アクセス: Config Controller は、マスター承認済みネットワークが有効、プライベート エンドポイントが有効、パブリック アクセスが無効になっているプライベート ノードを使用します。詳細については、GKE のネットワーク セキュリティについてのページをご覧ください。

次のステップ