このページでは、Config Controller クラスタに独自のワークロードをデプロイする方法について説明します。
このページは、基盤となる技術インフラストラクチャのライフサイクル管理と、容量の計画を行い、アプリとサービスを本番環境にデプロイする IT 管理者とオペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
始める前に
開始にあたり、次の作業が完了していることを確認してください。
- Config Controller を設定する。
- 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)。
コンソール
ノードの自動プロビジョニングを有効にするには、次の操作を行います。
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
クラスタの名前をクリックします。
[自動化] セクションの [ノードの自動プロビジョニング] で、[
編集] をクリックします。[ノードの自動プロビジョニングを有効にする] チェックボックスをオンにします。
クラスタの CPU およびメモリ使用量の最小値と最大値を設定します。
[変更内容を保存] をクリックします。
デフォルトの設定など、ノードの自動プロビジョニングの構成について詳しくは、ノードの自動プロビジョニングの構成についてのページをご覧ください。
ワークロードをデプロイする
ワークロードをデプロイすると、Config Controller は GKE Sandbox を自動的に有効にして、信頼できないコードがクラスタノードのホストカーネルに影響を与えないようにセキュリティを強化します。詳細については、GKE Sandbox の概要についてのページをご覧ください。
ワークロードをデプロイするには、ワークロード マニフェスト ファイルを作成し、次のコマンドを実行します。
kubectl apply -f WORKLOAD_FILE
WORKLOAD_FILE
は、マニフェスト ファイル(my-app.yaml
など)で置き換えます。
自動プロビジョニングされたノードでワークロードが実行されていることを確認します。
ワークロード用に作成されたノードのリストを取得します。
kubectl get nodes
特定のノードを検査します。
kubectl get nodes
NODE_NAME
-o yamlNODE_NAME
は、検査するノードの名前に置き換えます。
制限事項
- GKE Sandbox: GKE Sandbox は多くのアプリケーションで動作していますが、すべてのアプリケーションに対応しているわけではありません。詳細については、GKE Sandbox の制限事項をご覧ください。
- コントロール プレーンのセキュリティ: ワークロード関する権限を付与する場合は、最小権限の原則に従って、必要な権限のみを付与します。ワークロードが侵害された場合、そのワークロードは過度に緩い権限を使って Kubernetes リソースを変更または削除できます。
- コントロール プレーンの可用性: ワークロードによってトラフィックが短期間で増加すると、トラフィックが減少するまでクラスタ コントロール プレーンが使用できなくなる可能性があります。
- コントロール プレーンのサイズ変更: GKE は必要に応じてコントロール プレーンのサイズを自動的に変更します。ワークロードによって負荷が大幅に増加する場合(数千の CRD オブジェクトをインストールする場合など)、GKE の自動サイズ変更では負荷の増加に対応できない場合があります。
- 割り当て: ワークロードをデプロイする際は、GKE の割り当てと上限に注意し、それを超えないようにする必要があります。
- コントロール プレーンとノードへのネットワーク アクセス: Config Controller は、マスター承認済みネットワークが有効、プライベート エンドポイントが有効、パブリック アクセスが無効になっているプライベート ノードを使用します。詳細については、GKE のネットワーク セキュリティについてのページをご覧ください。
次のステップ
- Config Controller のベスト プラクティスの詳細を確認する: Config Controller のスケーラビリティ、Config Controller のシャーディング、高可用性のために Config Controller を構成する
- Config Controller のトラブルシューティング
- Config Controller をモニタリングする