Autopilot の概要


はじめに

Autopilot は、Google Kubernetes Engine(GKE)の新しい運用モードで、クラスタの管理コストの削減、本番環境に合わせたクラスタの最適化、ワークロードの可用性の向上を目的として設計されています。運用モードとは、クラスタに対する柔軟性、権限、管理のレベルを意味します。GKE には、フルマネージドのコントロール プレーンとノードの自動化のメリットに加えて、2 つの運用モードが用意されています。

  • Autopilot: GKE は、ノードやノードプールなどのクラスタの基盤となるインフラストラクチャをプロビジョニングして管理します。また、ユーザーによる操作が不要な最適化されたクラスタを提供します。
  • Standard: クラスタの基盤となるインフラストラクチャはユーザーが管理します。ノードを柔軟に構成できます。

Autopilot を使用すると、ノードの健全性のモニタリングや、ワークロードに必要なコンピューティング容量の計算を行う必要がなくなります。Autopilot は、Kubernetes の API、ツール、豊かなエコシステムのほとんどをサポートしています。Standard モードのように Compute Engine API を介してノードにアクセスすることはできないため、ユーザーは GKE 内にとどまります。Compute Engine API、CLI、UI を使用する必要はありません。Pod が実行されている間、Pod がリクエストした CPU、メモリ、ストレージに対してのみ料金が発生します。

Autopilot クラスタは、本番環境ワークロード用に最適化されたクラスタ構成を使用して事前に構成されています。この単純な構成は、GKE のベスト プラクティスと推奨事項を遵守しています。組み込みの設定(詳細は以下のを参照)の中には変更できないものもありますが、それ以外のオプションの設定は有効 / 無効を切り替えることができます。

Autopilot には、コントロール プレーンと Pod の両方を網羅する SLA が定義されています。Autopilot を使用すると、基盤となるインフラストラクチャが抽象化されるため、Kubernetes API とデプロイに集中できます。Autopilot は、PodSpec で定義したリソース要件を使用して、デプロイ用のリソース(CPU、メモリ、永続ディスクなど)をプロビジョニングします。

次の 2 つのことに該当する場合は、Autopilot ではなく Standard モードを使用してください。

  • クラスタ構成をより細かく制御する必要がある。
  • クラスタで、Autopilot の制約を満たさないワークロードを実行する必要がある。

Autopilot と Standard モードの比較

Autopilot では、クラスタのライフサイクルにおける複雑な処理の多くは GKE によって管理されます。次の表に、クラスタの運用モード別に使用可能なオプションを示します。

  • 事前構成済み: この設定は組み込まれているもので、変更できません。
  • デフォルト: この設定は有効になっていますが、オーバーライドできます。
  • 省略可: この設定は無効になっていますが、有効にできます。
オプション Autopilot モード Standard モード
基本クラスタタイプ 利用可能なオプションとバージョン:

事前構成済み: リージョン
デフォルト: レギュラー リリース チャンネル
利用可能なオプションとバージョン:

省略可:
ノードとノードプール GKE による管理。 ユーザーによる管理、構成、指定。
リソースのプロビジョニング Pod 仕様に基づき、GKE がリソースを動的にプロビジョニングします。 ユーザーが追加のリソースを手動でプロビジョニングし、クラスタ全体のサイズを設定します。プロセスの自動化を簡単にするには、クラスタの自動スケーリングとノード自動プロビジョニングを構成します。
イメージタイプ 事前構成済み: Containerd を含む Container-Optimized OS 次のいずれかを選択します。
課金 Pod のリソース リクエスト(CPU、メモリ、エフェメラル ストレージ)ごとに課金 ノード(CPU、メモリ、ブートディスク)ごとに課金
セキュリティ 事前構成済み:
省略可:
ネットワーキング 事前構成済み:
デフォルト:
  • 一般公開クラスタ
  • 自動 CIDR 範囲
  • ネットワーク名 / サブネット
省略可:
省略可:
アップグレード、修復、メンテナンス 事前構成済み:
省略可:
認証情報 事前構成済み: Workload Identity省略可:
スケーリング 事前構成済み: ノードのスケーリングと構成は Autopilot によってすべて処理されます。

デフォルト:
省略可:
モニタリングとロギング 事前構成済み: Cloud Operations for GKE

デフォルト: システムとワークロードのロギング

省略可: システムのみのロギング
デフォルト:
省略可: システムのみのロギング
ルーティング 事前構成済み: Pod ベースのルーティング。ネットワーク エンドポイント グループ(NEG)が有効。 ノードベースのパケット ルーティング(デフォルト)か Pod ベースのルーティングを選択します。
クラスタ アドオン 事前構成済み:
デフォルト:
省略可:

1 クラスタで Cloud NAT を有効にする場合に必要な追加構成。

サポートされていないクラスタ機能

Autopilot クラスタでは、次の GKE クラスタ機能はサポートされていません。

Compute Engine インスタンス

セキュリティ

アドオンと統合

スケーリング

Autopilot は、Pod の仕様に基づいてクラスタのリソースを自動的にスケーリングするため、ユーザーは Pod に集中できます。Pod の数を自動的に増減させるには、Kubernetes 標準の CPU の指標やメモリの指標を使用するか、Cloud Monitoring のカスタム指標を使用して、水平 Pod 自動スケーリングを実装します。

使用可能なリソースの範囲

次の表に、Autopilot の Pod で使用できるリソースの範囲を示します。特に明記されていない限り、値はすべて Pod 内のコンテナ リソース リクエストの合計に適用されます。Pod の vCPU は 0.25 vCPU 単位で利用可能です。最小のメモリ容量に加え、CPU とメモリの比率は、1 vCPU:1 GiB~1 vCPU:6.5 GiB の範囲にする必要があります。許容範囲外の比率のリソースはスケールアップされます。詳細については、リソースの範囲と比率の管理リソース制限の例をご覧ください。

リソース 最小リソース 最大リソース
通常の Pod DaemonSet Pod すべての Pod
CPU 250 mCPU 10 mCPU vCPU 28 個2
メモリ 512 MiB 10 MiB 80 GiB2
エフェメラル ストレージ 10 MiB(コンテナあたり) 10 MiB(コンテナあたり) 10 GiB

2 すべての DaemonSet Pod のリソース リクエストの合計数により、通常の Pod の CPU とメモリの上限がさらに小さくなります。

デフォルトのコンテナ リソース リクエスト

Autopilot は、デプロイ構成の指定に従ってリソースをプロビジョニングします。Pod 内のコンテナにリソース リクエストを指定しない場合、Autopilot によってデフォルト値が適用されます。これらのデフォルトは、Pod 内のコンテナが平均リソース量を確保できるように設計されています。これは、多くの小規模なワークロードに適しています。

Autopilot は、これらのデフォルト値を Pod 仕様で定義されていないリソースに適用します。

リソース 通常の Pod 内のコンテナ DaemonSet のコンテナ
CPU 500 mCPU 50 mCPU
メモリ 2 GiB 100 MiB
エフェメラル ストレージ 1 GiB 100 MiB

Autopilot によるクラスタの上限の詳細については、割り当てと上限をご覧ください。

ワークロードの上限と制限事項

Autopilot は、アプリケーションを実行するほとんどのワークロードをサポートします。GKE でノード管理を行い、より効率的な運用を可能にするため、GKE Standard と比べると制限と上限が少なくなっています。この中には、セキュリティのベスト プラクティスによる制限もあれば、Autopilot クラスタを安全に管理するための制限もあります。ワークロードの制限は、Deployment、DaemonSet、ReplicaSet、ReplicationController、StatefulSet、Job、CronJob によって起動されるものを含め、すべての Pod に適用されます。

ホスト オプションの制限

ノード管理は GKE によって処理されるため、HostPort と hostNetwork は使用できません。書き込みモードでは hostPath ボリュームの使用が禁止されています。読み取りモードの場合、hostPath ボリュームの使用は /var/log/ パス接頭辞でのみ許可されます。ワークロードでのホスト名前空間の使用は禁止されています。

Linux ワークロードの制限

Autopilot は、ワークロードに関する次の Linux 機能のみをサポートします。

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER",
"FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP"

ノードセレクタとノード アフィニティ

ゾーン アフィニティ トポロジはサポートされています。ノード アフィニティノードセレクタは、topology.kubernetes.io/regiontopology.kubernetes.io/zonefailure-domain.beta.kubernetes.io/regionfailure-domain.beta.kubernetes.io/zonecloud.google.com/gke-os-distributionkubernetes.io/oskubernetes.io/arch キーでのみ使用できます。Autopilot では、OS と arch のすべての値がサポートされているわけではありません。

Container Threat Detection は未サポート

Autopilot では、Container Threat Detection はサポートされていません。

特権 Pod は未サポート

ワークロード内のコンテナに対する特権モードは、kubelet やネットワーク設定の変更など、主にノードの変更で使用されます。Autopilot クラスタでは、ノードの変更が許可されないため、こうしたタイプの Pod は許可されません。この制限は、一部の管理ワークロードに影響を与える可能性があります。

Pod のアフィニティとアンチアフィニティ

Autopilot では GKE がノードを管理しますが、Pod のスケジューリングは可能です。Autopilot では Pod アフィニティがサポートされているため、1 つのノード上に複数の Pod を配置し、ネットワーク効率を高めることができます。たとえば、Pod アフィニティを使用して、バックエンド Pod のあるノードにフロントエンド Pod をデプロイできます。Pod アフィニティは、topology.kubernetes.io/regiontopology.kubernetes.io/zonefailure-domain.beta.kubernetes.io/regionfailure-domain.beta.kubernetes.io/zone キーでのみ使用できます。

Autopilot ではアンチアフィニティもサポートされているため、Pod を複数のノードに分散し、単一障害点を回避できます。たとえば、Pod のアンチアフィニティを使用すると、フロントエンド Pod とバックエンド Pod が同じ場所に配置されないように制御できます。

Pod のアンチアフィニティを使用する場合のデフォルトとリソースの制限

Autopilot では Pod のアンチアフィニティがサポートされているため、2 つの Pod が同じノード上に配置されないように制御できます。アンチアフィニティを使用する場合、Autopilot は、PodSpec の定義どおりに Pod の分離が適切に行われるように、追加のコンピューティング リソースを割り当てる必要があります。Pod のアンチアフィニティを使用すると、デフォルトと最小のリソース上限が増加します。PodSpec にあるすべてのコンテナに対する値は、次のとおりです。

リソース デフォルト値
CPU 0.75 vCPU
メモリ 2 GiB
エフェメラル ストレージ 1 GiB

Pod のアンチアフィニティを使用する場合は、同じリソース制限ルールとロジックが適用されますが、vCPU の増分は高くなります。Pod の vCPU は 0.5 vCPU から 0.5 vCPU 単位で提供されます(増分単位に切り上げ)。たとえば、アンチアフィニティを使用するすべてのコンテナで合計 0.66 vCPU をリクエストすると、アドミッション中に PodSpec が変更され、1 vCPU に設定されます。Pod には上位のリソースに対する完全アクセス権が付与され、追加のリソースは、すべてのコンテナのリソース リクエストの間で分割されます。

ワークロードの分離に対してのみ許容範囲をサポート

許容範囲は、ワークロードの分離に対してのみサポートされます。必要に応じて、ノードの自動プロビジョニングにより taint が自動的に追加されます。

リソース範囲と比率の管理

  • Pod の vCPU の増分: Pod の vCPU は 0.25 vCPU 単位(切り上げ)で利用可能です。たとえば、すべてのコンテナ全体で合計 0.66 vCPU をリクエストすると、アドミッション中に PodSpec が変更され、0.75 に設定されます。Pod には上位のリソースに対する完全アクセス権が付与され、追加のリソースは、すべてのコンテナのリソース リクエストの間で分割されます。最小値は 250 ミリ CPU(mCPU)です。DaemonSet vCPU は 10 mCPU 単位で提供されます(増分単位に切り上げ)。

  • メモリと CPU の比率範囲: メモリの vCPU に対する比率(GiB 単位)は、1~6.5 vCPU の範囲にする必要があります。たとえば、1 個の vCPU と 1 GiB のメモリを持つ Pod や、1 個の vCPU と 6.5 GiB のメモリを持つ Pod は作成できますが、1 個の vCPU と 7 GiB のメモリは割り当てられません。リソース リクエストに対応するため、GKE はどちらかのリソースが少なくなりすぎると、GKE がスケールアップします。たとえば、1 個の vCPU と 7 GiB のメモリをリクエストすると、アドミッション時に PodSpec が 1.25 vCPU と 7 GiB のメモリに変更されます。同様に、1 個の vCPU と 800 MiB のメモリをリクエストすると、PodSpec は 1 個 vCPU と 1 GiB の RAM に変更され、追加のリソースがコンテナ間で分割されます。

リソース リクエストがないコンテナにデフォルトが適用された後、CPU とメモリの増分と比率の要件、リソース リクエストによるスケールアップの予測が計算されます。

リソース リクエストがないコンテナの場合、500 mCPU と 1 GiB のメモリが標準の最小値として使用されます。CPU とメモリに対して、GKE がリソース リクエストをスケールアップする場合(最小要件や比率の要件を満たす場合など)、追加のリソースはコンテナ間で均等に割り当てられます。切り上げられた値はコンテナ間で均等に分配されます。たとえば、他のコンテナの 2 倍のメモリを持つコンテナには、他のメモリの 2 倍の容量が配分されます。

  • エフェメラル ストレージ: 使用可能な範囲は 10 MiB~10 GiB です。これは、コンテナの書き込み可能レイヤと emptyDir のマウントに影響します。

エフェメラル ストレージにはコンテナあたりの最小リクエストがあります。コンテナのエフェメラル ストレージ リクエストが最小値を下回る場合は、Autopilot によってリクエストが最小値に引き上げられます。エフェメラル ストレージに Pod あたりの最小リクエストはありません。エフェメラル トレージには、Pod あたりの最大リクエストが設定されています。これは、すべてのコンテナの累積値になります。累積値が最大値より大きい場合、Autopilot はリクエストを最大値までスケーリングし、コンテナ間のリクエストの比率を維持します。

リソース制限の例

例 1: 最小 CPU が 250 mCPU 未満の単一コンテナの場合:

コンテナ数 元のリソース リクエスト 変更されたリクエスト
1 CPU: 180 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 250 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
Pod リソースの合計 CPU: 250 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB

例 2: 合計の最小 CPU が 250 mCPU 未満の複数コンテナで、Autopilot により残りのリソース(最大 250 vCPU)が Pod 内のすべてのコンテナに均等配分される場合

コンテナ数 元のリソース リクエスト 変更されたリクエスト
1 CPU: 70 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 84 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
2 CPU: 70 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 83 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
3 CPU: 70 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 83 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
Pod リソースの合計 CPU: 250 mCPU
メモリ: 1.5 GiB
エフェメラル ストレージ: 30 MiB

例 3: リソース数が 250 mCPU 以上のコンテナが複数ある場合、CPU は 250 mCPU の倍数に丸められます。余分な CPU はすべてのコンテナに元のリクエストの比率で分散されます。この例では、元の累積 CPU は 320 mCPU で、合計 500 mCPU に変更されます。余剰分の 180 mCPU がコンテナ全体に分散されます。

コンテナ数 元のリソース リクエスト 変更されたリクエスト
1 CPU: 170 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 266 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
2 CPU: 80 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 125 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
3 CPU: 70 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 109 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
4 初期コンテナで、リソースが未定義 Pod リソースを受信
Pod リソースの合計 CPU: 320 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 30 MiB

例 4: CPU がメモリに対して少なすぎる単一コンテナの場合(最大比は 1 vCPU : 6.5 GiB)CPU とメモリの許容最大比は 1:6.5 です。これより大きい割合の場合は、CPU リクエストが引き上げられ、必要に応じて切り上げられます。

コンテナ数 元のリソース リクエスト 変更されたリクエスト
1 CPU: 250 mCPU
メモリ: 4 GiB
エフェメラル ストレージ: 10 MiB
CPU: 750 mCPU
メモリ: 4 GiB
エフェメラル ストレージ: 10 MiB
Pod リソースの合計 CPU: 750 mCPU
メモリ: 4 GiB
エフェメラル ストレージ: 10 MiB

例 5: メモリが CPU の量に対して少なすぎる場合(最小比は 1 vCPU : 1 GiB)CPU とメモリの許容最小比は 1:1 です。この値より小さい場合は、メモリ リクエストが引き上げられます。

コンテナ数 元のリソース リクエスト 変更されたリクエスト
1 CPU: 4 vCPU
メモリ: 1 GiB
エフェメラル ストレージ: 10 MiB
CPU: 4 vCPU
メモリ: 4 GiB
エフェメラル ストレージ: 10 MiB
Pod リソースの合計 CPU: 4 mCPU
メモリ: 4 GiB
エフェメラル ストレージ: 10 MiB

例 6: 最小の 250 mCPU 未満の単一コンテナで、調整後の CPU のメモリ容量が少なすぎる場合(最大比は 1 vCPU : 6.5 GiB)

コンテナ数 元のリソース リクエスト 変更されたリクエスト
1 CPU: 100 mCPU
メモリ: 50 MiB
エフェメラル ストレージ: 10 MiB
CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 10 MiB
Pod リソースの合計 CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 10 MiB

例 7: 1 つのコンテナでエフェメラル ストレージ リクエストが 10 GiB を超える場合(エフェメラル ストレージ リクエストの最大許容値は 10 GiB)リクエストが最大値を超えると、そのリクエストは 10 GiB にスケールダウンされます。

コンテナ数 元のリソース リクエスト 変更されたリクエスト
1 CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 11 GiB
CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 10 GiB
Pod リソースの合計 CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 10 GiB

例 8: 複数のコンテナでエフェメラル ストレージ リクエストが 10 GiB を超える場合(すべてのコンテナのエフェメラル ストレージ リクエストはスケールダウンされ、最終的な累積ストレージ リクエストは 10 GiB になります)

コンテナ数 元のリソース リクエスト 変更されたリクエスト
1 CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 5 GiB
CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 2.94 GiB
2 CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 6 GiB
CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 3.53 GiB
3 CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 6 GiB
CPU: 250 mCPU
メモリ: 256 MiB
エフェメラル ストレージ: 3.53 GiB
Pod リソースの合計 CPU: 750 mCPU
メモリ: 768 MiB
エフェメラル ストレージ: 10 GiB

セキュリティの制限

コンテナの分離

Autopilot は、強化された構成を Pod に適用し、改善されたセキュリティ分離を提供します。これにより、クラスタでのコンテナ エスケープの脆弱性による影響を軽減できます。

  • デフォルトでは、コンテナ ランタイムのデフォルト seccomp プロファイルがクラスタ内のすべての Pod に適用されます。
  • すべてのコンテナに対する CAP_NET_RAW コンテナ権限が失われます。通常、CAP_NET_RAW 権限は使用されません。これは、複数のコンテナ エスケープの脆弱性の対象でした。CAP_NET_RAW がないことにより、コンテナ内で ping がエラーになる可能性があります。
  • Workload Identity が適用され、基盤となる Compute Engine サービス アカウントと機密性の高いノード メタデータに対する Pod のアクセスが防止されます。
  • CVE-2020-8554 から保護するため、spec.ExternalIPs が設定されたサービスがブロックされます。これらのサービスはほとんど利用されません。
  • 次の StorageTypes を使用できます。他の StorageType はノードに対する権限を必要とするため、ブロックされます。

    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "hostPath",
    "nfs", "persistentVolumeClaim", "projected", "secret"
    

Pod のセキュリティ ポリシー

Autopilot は、コンテナで強化された分離を可能にする設定を適用します。Autopilot クラスタでは、Kubernetes PodSecurityPolicyOPA GatekeeperPolicy Controller はサポートされていません。

Autopilot のセキュリティ境界

Kubernetes レイヤにおいて、GKE Autopilot モードには Kubernetes API が用意されていますが、特権 Pod などの特権付き Kubernetes プリミティブを使用する権限が削除されます。これは、ノードの仮想マシン(VM)に対してアクセス、変更、または直接制御を行う機能を制限することを目的としています。

これらの制限は、ノード VM に対する低レベルのアクセス権を付与されたワークロードを制限します。また、Google Cloud でノードと Pod レベルの SLA を完全に管理できるようにするために GKE Autopilot モードに設定されています。

Google の目的は、ノード仮想マシンの意図しないアクセスを防ぐことです。Google では、脆弱性報奨金プログラム(VRP)でセキュリティ効果に関する報告を受け付けています。優れた報告に対しては Google VRP リワードパネルの裁量で報奨金を提供しています。

設計上、特権ユーザー(クラスタ管理者など)は GKE クラスタを完全に制御できます。セキュリティの観点から、Google のマルチテナンシーのガイダンスで説明されているように、強力な GKE / Kubernetes 権限を広範囲に付与せず、名前空間の管理権限の委譲を行うことをおすすめします。

Autopilot のワークロードは、GKE Standard モードと同じセキュリティを維持します。単一テナント VM はユーザー プロジェクトに排他的にプロビジョニングされます。また、Standard モードと同様に、個々の VM でクラスタ内の Autopilot ワークロードがセキュリティ強化されている共有カーネルと一緒に実行される可能性があります。

共有カーネルは単一のセキュリティ境界を表すため、高リスクのワークロードや信頼できないワークロードなどの強固な分離が必要な場合は、GKE が GKE Sandbox を使用して GKE Standard クラスタ上でワークロードを実行することを推奨します。これにより多層的セキュリティを確保できます。

その他の制限

証明書署名リクエスト

Autopilot 内で証明書署名リクエストを作成することはできません。

外部モニタリング ツール

ほとんどの外部モニタリング ツールでは、制限付きのアクセス権が必要になります。複数の Google Cloud パートナーが提供するソリューションを Autopilot で使用できますが、すべてがサポートされているわけではありません。また、Autopilot クラスタにカスタム モニタリング ツールをインストールすることはできません。

外部サービス

Autopilot クラスタでは、外部 IP サービスは許可されません。Service に外部 IP を設定するには、LoadBalancer タイプの Service を使用するか、Ingress を使用して、複数のサービス間で共有される外部 IP に Service を追加します。

初期コンテナ

アプリケーション コンテナを開始する前に、初期コンテナが順番に実行されます。デフォルトでは、GKE は、Pod で使用可能な完全なリソースを各初期コンテナに割り当てます。

他のコンテナとは異なり、GKE では、初期コンテナにはリソース リクエストを指定しないことをおすすめします。これにより、コンテナに十分なリソースが割り当てられます。リソース量を低く設定すると、初期コンテナが不必要に制限されます。また、リソースを多く設定すると、Pod の存続期間中の請求金額が大きくなる可能性があります。

マネージド名前空間

kube-system 名前空間はマネージドです。つまり、この名前空間内のすべてのリソースは変更できず、新しいリソースを作成することもできません。

ノードの変更不可

Autopilot クラスタの場合、ノードは GKE によって管理されるため、変更できません。

変換なし

標準クラスタを Autopilot モードに変更することはできません。Autopilot クラスタを Standard モードに変更することもできません。

外部からの限定公開クラスタへのダイレクトな受信接続は不可

プライベート ノードのある Autopilot クラスタには外部 IP がないため、受信接続を直接受け入れることはできません。NodePort にサービスをデプロイすると、これらのサービスにインターネットなどの VPC の外部からアクセスすることはできません。Autopilot クラスタでアプリケーションを外部に公開するには、Service を使用します。詳細については、サービスを使用したアプリケーションの公開をご覧ください。

Pod のバースト不可

標準クラスタでは、ノードで未使用の容量を集中利用するように Pod を構成できます。Autopilot クラスタでは、すべての Pod でリクエストに対する上限が設定されているため、リソース バースト機能は使用できません。Pod の仕様でリソース リクエストに十分なリソースを定義し、バースト機能に依存しないことが重要です。

SSH 不可

Autopilot ではノードのプロビジョニングや管理を行わないため、SSH アクセスは許可されません。ノードの健全性や、ノード上で実行されているすべての Kubernetes コンポーネントに関する処理など、ノードのすべての運用面は GKE によって処理されます。

リソースの上限

Autopilot クラスタでは、各 Pod は保証型の QoS クラス Pod として扱われ、リソース リクエストと同じ上限が設定されます。リソース上限が指定されていない場合、Autopilot はリソース リクエストと同じリソース上限を自動的に設定します。リソース上限を指定すると、上限がオーバーライドされ、リソース リクエストと同じ値に設定されます。

Webhook の制限事項

Autopilot クラスタにカスタムの変更用アドミッション Webhook を作成することはできませんが、カスタム検証 Webhook は作成できます。

トラブルシューティング

クラスタを作成できません。0 個のノードが登録されています

Autopilot クラスタを作成すると、次のエラーで失敗します。

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

この問題を解決するには:

  • デフォルトの Compute Engine を使用していない場合は、最小権限の Google サービス アカウントを使用するに記載されている権限を付与してください。

  • デフォルトの Compute Engine を使用している場合は、それが無効になっていないことを確認します。次のコマンドを実行して確認します。

    gcloud iam service-accounts describe SERVICE_ACCOUNT
    

    SERVICE_ACCOUNT は、数値形式のサービス アカウント ID またはサービス アカウントのメールアドレス(123456789876543212345my-iam-account@somedomain.com など)に置き換えます。

次のステップ