このページでは、GKE のネットワーク ポリシーを適用して、クラスタの Pod と Service 間の通信を制御する方法について説明します。
完全修飾ドメイン名（FQDN）ネットワーク ポリシーを使用して、クラスタ外のエンドポイントまたはサービスに対する Pod の下り（外向き）トラフィックを制御することもできます。詳細については、FQDN を使用して Pod と Service 間の通信を制御するをご覧ください。
GKE ネットワーク ポリシーの適用について
ネットワーク ポリシーを適用すると、クラスタ内に Kubernetes ネットワーク ポリシーを作成できます。デフォルトでは、クラスタ内のすべての Pod は自由に通信できます。ネットワーク ポリシーは、クラスタ内で相互にアクセスできる Pod と Service を決定する Pod レベルのファイアウォール ルールを作成します。
ネットワーク ポリシーを定義すると、クラスタがマルチレベルのアプリケーションを処理するときに多層防御のような機能を有効にすることができます。たとえば、アプリケーション内の不正使用されたフロントエンド サービスが数レベル下の課金サービスや会計サービスと直接通信できないようにするネットワーク ポリシーを作成することができます。
ネットワーク ポリシーを使用して、複数のユーザーが生成したデータを同時にホストするアプリケーションをより簡単に作成することもできます。たとえば、テナント単位の名前空間モデルを定義して、セキュアなマルチテナンシーを提供できます。このようなモデルでは、ネットワーク ポリシールールにより、特定の Namespace 内の Pod や Service が異なる Namespace 内の他の Pod や Service にアクセスできないようにできます。
GKE の NetworkPolicy プラグイン
ネットワーク ポリシーでは、適用を実装するためにネットワーク プラグインが必要です。GKE には、次の相互に排他的なネットワーク プラグインがあります。
- GKE Dataplane V2（Cilium ベース）。GKE Dataplane V2 は、すべてのクラスタで推奨されるネットワーク プラグインであり、Autopilot クラスタのデフォルトです。
- Calico ネットワーク ポリシー プラグイン。これは Standard クラスタでのみ使用できます。
クラスタがマネージド ネットワーク プラグインで構成されていない場合は、ネットワーク ポリシーを適用するためにセルフマネージド プラグインが必要です。ネットワーク プラグインが構成されていない場合、ネットワーク ポリシーは適用されません。
ネットワーク プラグインを使用してネットワーク ポリシーを適用しない場合は、クラスタからすべてのネットワーク ポリシーを削除することをおすすめします。これらのネットワーク ポリシーは、ネットワーク ポリシーを適用するネットワーク プラグインを後でインストールすると、予期しないトラフィック制限を引き起こす可能性があります。
始める前に
作業を始める前に、次のタスクが完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API を有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。gcloud CLI をインストール済みの場合は、
gcloud components updateコマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
要件と制限事項
次の要件と制限事項は Autopilot クラスタと Standard クラスタの両方に適用されます。
- メタデータ サーバーへの下り（外向き）を許可する必要があります。
- GKE Dataplane V2 クラスタの制限事項の詳細については、GKE Dataplane V2 の既知の問題のページをご覧ください。
次の要件と制限事項は Standard クラスタにのみ適用されます。
- GKE 用 Workload Identity 連携でネットワーク ポリシーを使用する場合は、メタデータ サーバーへの下り（外向き）を許可する必要があります。
- ネットワーク ポリシーの適用を有効にすると、
kube-systemプロセスのメモリ使用量が約 128 MB 増加し、約 300 ミリコアの CPU が必要になります。つまり、既存のクラスタに対してネットワーク ポリシーを有効にした場合、スケジュールされたワークロードの実行を継続するには、クラスタのサイズを大きくする必要があります。 - ネットワーク ポリシーの適用を有効にする場合、ノードの再作成が必要になります。クラスタのメンテナンスの時間枠が有効になっている場合、次のメンテナンスの時間枠でノードが自動的に再作成されます。必要に応じて、いつでも手動でクラスタをアップグレードできます。
- ネットワーク ポリシーを適用するために必要となるクラスタの最小サイズは 3 つの
e2-mediumインスタンスか、1 つ以上の割り当て可能な vCPU を持つ 1 つのマシンタイプ インスタンスです。詳細については、GKE の既知の問題をご覧ください。 - ノードが
f1-microインスタンスまたはg1-smallインスタンスであるクラスタでは、リソース要件が高すぎるため、ネットワーク ポリシーはサポートされません。 - GKE Dataplane V2 も Calico も、
spec.hostNetwork: true設定を使用する Pod のネットワーク ポリシーを適用しません。
ノードのマシンタイプと割り当て可能なリソースについて詳しくは、標準クラスタ アーキテクチャ - ノードをご覧ください。
ネットワーク ポリシーの適用を有効にする
クラスタで GKE Dataplane V2 を使用している場合は、ネットワーク ポリシーを作成するに進みます。
この変更を行うにはノードの再作成が必要になり、実行中のワークロードが中断する可能性があります。この変更について詳しくは、ノード アップグレード戦略に従ってノードを再作成し、メンテナンス ポリシーを遵守する手動変更の表で対応する行をご覧ください。ノードの更新の詳細については、ノードの更新による中断の計画をご覧ください。
続行する前に: ノードが再作成されると、ネットワーク ポリシーが適用されます。
gcloud
-
Google Cloud コンソールで Cloud Shell をアクティブにします。
Google Cloud コンソールの下部にある Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
クラスタでネットワーク ポリシーの適用を有効にするには、次のタスクを実行します。
次のコマンドを実行して、アドオンを有効にします。
gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLEDCLUSTER_NAMEは、クラスタの名前に置き換えます。次のコマンドを実行してクラスタでネットワーク ポリシーの適用を有効にします。これにより、ネットワーク ポリシーの適用が有効に設定されて、クラスタのノードプールが再作成されます。
gcloud container clusters update CLUSTER_NAME --enable-network-policy
コンソール
クラスタでネットワーク ポリシーの適用を有効にするには:
Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
クラスタのリストで、変更するクラスタの名前をクリックします。
[クラスタ ネットワーキング] の [Calico Kubernetes ネットワーク ポリシー] フィールドで、edit [ネットワーク ポリシーを編集] をクリックします。
[ネットワーク ポリシーを編集] ダイアログで、[コントロール プレーンの Calico Kubernetes ネットワーク ポリシーを有効にする] チェックボックスをオンにして、[変更を保存] をクリックします。
変更が適用されるまで待ちます。進行状況をモニタリングするには、コンソールの右上隅にある notifications [通知] をクリックします。
[Calico Kubernetes ネットワーク ポリシー] フィールドで、もう一度 edit [ネットワーク ポリシーを編集] をクリックします。
[ネットワーク ポリシーを編集] ダイアログで、[ノードの Calico Kubernetes ネットワーク ポリシーを有効にする] チェックボックスをオンにします。
[変更を保存] をクリックします。
API
ネットワーク ポリシーの適用を有効にするには、次のようにします。
projects.zones.clusters.create または projects.zones.clusters.update に渡す
clusterオブジェクト内にnetworkPolicyオブジェクトを指定します。networkPolicyオブジェクトには、使用するネットワーク ポリシー プロバイダを指定する列挙値と、ネットワーク ポリシーを有効にするかどうかを指定するブール値が必要です。ネットワーク ポリシーを有効にしてもプロバイダを設定しないと、createコマンドとupdateコマンドはエラーを返します。
Standard クラスタでネットワーク ポリシーの適用を無効にする
ネットワーク ポリシーの適用は、gcloud CLI、 Google Cloud コンソール、または GKE API を使用して無効にできます。Autopilot クラスタまたは GKE Dataplane V2 を使用するクラスタでネットワーク ポリシーの適用を無効にすることはできません。
この変更を行うにはノードの再作成が必要になり、実行中のワークロードが中断する可能性があります。この変更について詳しくは、ノード アップグレード戦略に従ってノードを再作成し、メンテナンス ポリシーを遵守する手動変更の表で対応する行をご覧ください。ノードの更新の詳細については、ノードの更新による中断の計画をご覧ください。
gcloud
-
Google Cloud コンソールで Cloud Shell をアクティブにします。
Google Cloud コンソールの下部にある Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
ネットワーク ポリシーの適用を無効にするには、次のタスクを行います。
- クラスタでネットワーク ポリシーの適用を無効にします。
gcloud container clusters update CLUSTER_NAME --no-enable-network-policyCLUSTER_NAMEは、クラスタの名前に置き換えます。このコマンドを実行すると、GKE はネットワーク ポリシーの適用を無効にしたクラスタ ノードプールを再作成します。
すべてのノードが再作成されたことを確認します。
kubectl get nodes -l projectcalico.org/ds-ready=trueオペレーションが成功すると、出力は次のようになります。
No resources found出力が次のような場合は、GKE がノードプールの更新を完了するまで待つ必要があります。
NAME STATUS ROLES AGE VERSION gke-calico-cluster2-default-pool-bd997d68-pgqn Ready,SchedulingDisabled <none> 15m v1.22.10-gke.600 gke-calico-cluster2-np2-c4331149-2mmz Ready <none> 6m58s v1.22.10-gke.600ネットワーク ポリシーの適用を無効にすると、構成されたメンテナンスの時間枠または除外がクラスタにある場合、GKE がすぐにはノードを更新しないことがあります。詳細については、クラスタの更新が遅いをご覧ください。
すべてのノードが再作成されたら、アドオンを無効にします。
gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
コンソール
既存のクラスタに対するネットワーク ポリシーの適用を無効にするには、次のようにします。
Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
クラスタのリストで、変更するクラスタの名前をクリックします。
[ネットワーキング] の [ネットワーク ポリシー] フィールドで、edit [ネットワーク ポリシーを編集] をクリックします。
[ノードのネットワーク ポリシーの有効化] チェックボックスをオフにして、[変更を保存] をクリックします。
変更が適用されるのを待ってから、edit [ネットワーク ポリシーを編集] を再度クリックします。
[マスターのネットワーク ポリシーの有効化] チェックボックスをオフにします。
[変更を保存] をクリックします。
API
既存のクラスタに対するネットワーク ポリシーの適用を無効にするには、次のようにします。
setNetworkPolicyAPI を使用して、networkPolicy.enabled: falseを使用するようにクラスタを更新します。gcloud CLI を使用して、すべてのノードが再作成されたことを確認します。
kubectl get nodes -l projectcalico.org/ds-ready=trueオペレーションが成功すると、出力は次のようになります。
No resources found出力が次のような場合は、GKE がノードプールの更新を完了するまで待つ必要があります。
NAME STATUS ROLES AGE VERSION gke-calico-cluster2-default-pool-bd997d68-pgqn Ready,SchedulingDisabled <none> 15m v1.22.10-gke.600 gke-calico-cluster2-np2-c4331149-2mmz Ready <none> 6m58s v1.22.10-gke.600ネットワーク ポリシーの適用を無効にすると、構成されたメンテナンスの時間枠または除外がクラスタにある場合、GKE がすぐにはノードを更新しないことがあります。詳細については、クラスタの更新が遅いをご覧ください。
updateClusterAPI を使用して、update.desiredAddonsConfig.NetworkPolicyConfig.disabled: trueを使用するようにクラスタを更新します。
ネットワーク ポリシーを作成する
ネットワーク ポリシーは、Kubernetes Network Policy API を使用して作成できます。
ネットワーク ポリシーの作成について詳しくは、Kubernetes ドキュメントの次のトピックをご覧ください。
ネットワーク ポリシーと GKE 用 Workload Identity 連携
GKE 用 Workload Identity 連携でネットワーク ポリシーを使用する場合は、Pod が GKE メタデータ サーバーと通信できるように、次の IP アドレスへの下り（外向き）を許可する必要があります。
- GKE バージョン 1.21.0-gke.1000 以降を実行しているクラスタでは、ポート
988と987で169.254.169.252/32への下り（外向き）を許可します。 - 1.21.0-gke.1000 より前の GKE バージョンを実行しているクラスタでは、ポート
988と987で127.0.0.1/32への下り（外向き）を許可します。 - GKE Dataplane V2 を実行しているクラスタでは、ポート
80と8080で169.254.169.254/32への下り（外向き）を許可します。
これらの IP アドレスとポートへの下り（外向き）を許可しない場合は、自動アップグレード中にサービスの中断が発生する可能性があります。
Calico から GKE Dataplane V2 への移行
ネットワーク ポリシーを Calico から GKE Dataplane V2 に移行する場合は、次の制限事項を考慮してください。
NetworkPolicyマニフェストのipBlock.cidrフィールドに Pod または Service の IP アドレスを使用することはできません。ワークロードはラベルを使用して参照する必要があります。たとえば、次の構成は無効です。- ipBlock: cidr: 10.8.0.6/32NetworkPolicyマニフェストで空のports.portフィールドを指定することはできません。プロトコルを指定する場合は、ポートも指定する必要があります。たとえば、次の構成は無効です。ingress: - ports: - protocol: TCP
アプリケーション ロードバランサの操作
HTTP(S) ロードバランサを構築するために Ingress が Service に適用される場合は、ネットワーク ポリシーで HTTP(S) アプリケーション ロードバランサのヘルスチェックの IP アドレス範囲からのトラフィックが許可されていることを確認する必要があります。
ネットワーク エンドポイント グループでコンテナネイティブのロード バランシングを使用しない場合は、Service のノードポートが他のノードの Pod に接続を転送する可能性があります。これを回避するには、Service の定義で externalTrafficPolicy を Local に設定します。externalTrafficPolicy が Local に設定されていない場合、ネットワーク ポリシーではクラスタ内の他のノード IP アドレスからの接続も許可する必要があります。
コンテナ ネイティブのロード バランシング（すべての GKE クラスタでデフォルトで有効）は、トラフィックを Pod エンドポイントに直接転送します。これを実現するために、GKE Service に cloud.google.com/neg: '{"ingress": true}' のアノテーションが自動的に付加されます。ただし、GKE ネットワーク ポリシーを有効にすると、コンテナ ネイティブ ロード バランシングがデフォルトで有効にならないという特定の条件の 1 つになります。ネットワーク ポリシーを使用しながらコンテナ ネイティブのロード バランシングのメリットを維持するには、次のアノテーションを Service マニフェストに手動で適用する必要があります。
kind: Service
...
annotations:
cloud.google.com/neg: '{"ingress": true}'
...
デフォルトの有効化条件の一覧については、コンテナ ネイティブのロード バランシングをご覧ください。
ipBlock ルールへの Pod IP 範囲の追加
特定の Pod のトラフィックを制御するには、NetworkPolicy の上り（内向き）ルールまたは下り（外向き）ルールで namespaceSelector フィールドと podSelector フィールドを使用して、Namespace または Pod ラベルごとに Pod を選択します。Pod の IP アドレス範囲を意図的に選択するために ipBlock.cidr フィールドを使用することは避けてください。これは本質的にエフェメラルです。Kubernetes プロジェクトで、Pod の IP アドレス範囲が含まれている場合の ipBlock.cidr フィールドの動作は明確に定義されていません。Pod の IP アドレス範囲を含めて、このフィールドに広い CIDR 範囲（0.0.0.0/0 など）を指定すると、NetworkPolicy のさまざまな実装で予期しない結果が生じる可能性があります。
以下のセクションでは、GKE における NetworkPolicy のさまざまな実装で、ipBlock.cidr フィールドで指定した IP アドレス範囲がどのように評価され、それらが幅広い CIDR 範囲に本質的に含まれる Pod IP アドレス範囲にどのように影響するかについて説明します。実装間の動作の違いを理解しておくと、別の実装に移行する際の結果に備えることができます。
GKE Dataplane V2 での ipBlock の動作
NetworkPolicy の GKE Dataplane V2 実装では、Pod のトラフィックは ipBlock ルールの対象外です。したがって、cidr: '0.0.0.0/0' などの広範なルールを定義しても、Pod トラフィックは含まれません。たとえば、これは、Pod からのトラフィックを許可せずに、Namespace 内の Pod がインターネットからのトラフィックを受信することを許可する場合に便利です。Pod トラフィックも含めるには、NetworkPolicy の上り（内向き）ルールまたは下り（外向き）ルールの定義で、追加の Pod または Namespace セレクタを使用して、Pod を明示的に選択します。
Calico での ipBlock の動作
NetworkPolicy の Calico 実装では、Pod トラフィックが ipBlock ルールの対象となります。この実装で、Pod トラフィックを許可せずに広範な CIDR 範囲を構成するには、次の例のように、クラスタの Pod CIDR 範囲を明示的に除外します。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-non-pod-traffic
spec:
ingress:
- from:
- ipBlock:
cidr: '0.0.0.0/0'
except: ['POD_IP_RANGE']
この例の POD_IP_RANGE は、クラスタの Pod の IPv4 アドレス範囲です（例: 10.95.0.0/17）。複数の IP 範囲がある場合は、配列に個別に含めることができます（例: ['10.95.0.0/17', '10.108.128.0/17']）。
externalTrafficPolicy を使用してネットワーク ポリシーの動作を制御する
Service の externalTrafficPolicy 設定は、Kubernetes がネットワーク ポリシーを適用する方法に影響します。この設定により、Pod が受信トラフィックに対して認識する送信元 IP アドレスが決まります。これは、Kubernetes が NetworkPolicy ルールを評価する方法に影響する可能性があります。
externalTrafficPolicy で使用可能な値は次の 2 つです。
Cluster:externalTrafficPolicyがClusterに設定されている場合、宛先 Pod は送信元 IP アドレスを、トラフィックが最初に受信されたノードの IP アドレスと見なします。クライアント IP アドレスに基づいてトラフィックを拒否する NetworkPolicy があり、リモートノードの IP アドレスが含まれていない場合、ポリシールールで指定された外部クライアントからの外部トラフィックが意図せずブロックされる可能性があります。これを回避するには、クラスタ内のすべてのノードからのトラフィックを許可するポリシーを作成します。ただし、このポリシーでは、任意の外部クライアントからのトラフィックが許可されます。Local:externalTrafficPolicyがLocalに設定されている場合、Pod は送信元 IP アドレスを元のクライアント IP アドレスと見なします。これにより、実際のクライアント IP アドレスに基づいてルールを定義できるため、ネットワーク ポリシーでよりきめ細かい制御が可能になります。
トラブルシューティング
Pod が Private Service Connect を使用するクラスタ上のコントロール プレーンと通信できない
コントロール プレーンの内部 IP アドレスへの Pod の下り（外向き）が下り（外向き）ネットワークで制限されている場合、Private Service Connect を使用する GKE クラスタの Pod でコントロール プレーンとの通信に問題が発生する可能性があります。
この問題には次のように対処してください。
クラスタで Private Service Connect を使用していることを確認します。Private Service Connect を使用するクラスタで、サブネットの作成時に
master-ipv4-cidrフラグを使用すると、GKE はmaster-ipv4-cidrで定義した値から各コントロール プレーンに内部 IP アドレスを割り当てます。それ以外の場合は、GKE はクラスタノード サブネットを使用して、各コントロール プレーンに内部 IP アドレスを割り当てます。コントロール プレーンの内部 IP アドレスへのトラフィックを許可するように、クラスタの下り（外向き）ポリシーを構成します。
コントロール プレーンの内部 IP アドレスを確認するには:
gcloud
privateEndpointを探すには、次のコマンドを実行します。gcloud container clusters describe CLUSTER_NAMECLUSTER_NAMEはクラスタの名前で置き換えます。このコマンドは、指定したクラスタの
privateEndpointを取得します。コンソール
Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
ナビゲーション パネルの [クラスタ] で、内部 IP アドレスを確認するクラスタをクリックします。
[クラスタの基本] で、内部 IP アドレスが表示されている
Internal endpointに移動します。
privateEndpointまたはInternal endpointが見つかったら、コントロール プレーンの内部 IP アドレスへのトラフィックを許可するようにクラスタの下り（外向き）ポリシーを構成します。詳細については、ネットワーク ポリシーを作成するをご覧ください。
クラスタの更新が遅い
既存のクラスタでネットワーク ポリシーの適用を有効または無効にすると、クラスタにメンテナンスの時間枠または除外が構成されている場合、GKE によってノードが直ちに更新されない場合があります。
ノードプールを手動でアップグレードするには、--cluster-version フラグを、コントロール プレーンが実行中のものと同じ GKE バージョンに設定します。この操作は、Google Cloud CLI で行う必要があります。詳細については、メンテナンス時間枠の注意点をご覧ください。
手動でデプロイした Pod のスケジューリングが解除される
既存のクラスタのコントロール プレーンでネットワーク ポリシーの適用を有効にすると、GKE は、手動でデプロイされた ip-masquerade-agent や calico ノードの Pod のスケジュールを解除します。
クラスタノードでネットワーク ポリシーの適用が有効になり、ノードが再作成されるまで、GKE はこれらの Pod の再スケジュールを行いません。
メンテナンスの時間枠または除外を構成している場合は、これによって中断が延長される可能性があります。
この中断期間を最小限に抑えるために、次のラベルをクラスタノードに手動で割り当てできます。
node.kubernetes.io/masq-agent-ds-ready=trueprojectcalico.org/ds-ready=true
ネットワーク ポリシーが機能しない
NetworkPolicy が有効でない場合は、次の手順でトラブルシューティングを行います。
ネットワーク ポリシーの適用が有効になっていることを確認します。使用するコマンドは、クラスタで GKE Dataplane V2 が有効かどうかによって異なります。
クラスタで GKE Dataplane V2 が有効になっている場合は、次のコマンドを実行します。
kubectl -n kube-system get pods -l k8s-app=cilium出力が空の場合、ネットワーク ポリシーの適用は有効になっていません。
クラスタで GKE Dataplane V2 が有効になっていない場合は、次のコマンドを実行します。
kubectl get nodes -l projectcalico.org/ds-ready=true出力が空の場合、ネットワーク ポリシーの適用は有効になっていません。
Pod のラベルを確認します。
kubectl describe pod POD_NAMEPOD_NAMEは、Pod の名前で置き換えます。出力は次のようになります。
Labels: app=store pod-template-hash=64d9d4f554 version=v1ポリシーのラベルが Pod のラベルと一致することを確認します。
kubectl describe networkpolicy出力は次のようになります。
PodSelector: app=storeこの出力では、
app=storeラベルは前の手順のapp=storeラベルと一致します。ワークロードを選択するネットワーク ポリシーがあるかどうかを確認します。
kubectl get networkpolicy出力が空の場合、Namespace に NetworkPolicy が作成されておらず、何もワークロードを選択していません。出力が空でない場合は、ポリシーでワークロードが選択されていることを確認します。
kubectl describe networkpolicy出力は次のようになります。
... PodSelector: app=nginx Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: PodSelector: app=store Not affecting egress traffic Policy Types: Ingress
既知の問題
Pod が containerCreating 状態で停止する
Calico ネットワーク ポリシーが有効になっている GKE クラスタで、Pod が containerCreating 状態のままになる可能性があります。
Pod の [イベント] タブに、次のようなメッセージが表示されます。
plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local
この問題を軽減するには、GKE クラスタの calico-ipam を使用するのではなく Calico のホストローカル ipam を使用します。
大規模クラスタでの 503 Calico readinessProbe の失敗
自動スケーリングを頻繁に行う大規模なクラスタでは、Calico が頻繁に再起動して中断を引き起こすことがあります。状況によっては、step フィールドの値を大きくして、垂直オートスケーラーの感度を下げることが必要な場合があります。
値を変更するには、calico-node-vertical-autoscaler ConfigMap を編集して、base フィールドと max フィールドに同じパラメータ値を使用します。このアプローチでは、動的な CPU リソース リクエストが無効になり、ノードのチャーンによる CPU リクエストの変動が停止します。
kind: ConfigMap
apiVersion: v1
metadata:
name: calico-node-vertical-autoscaler
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: EnsureExists
data:
node-autoscaler: |-
{
"calico-node": {
"requests": {
"cpu": {
"base": "200m",
"step": "100m",
"nodesPerStep": 50,
"max": "200m"
}
}
}
}
base フィールド（200m）の値を step フィールド（100m）の値よりも大きく設定すると、リクエストされた CPU はノード数に応じてスケーリングされなくなるため、オートスケーラーの式に従って、最大 60 個のノードのクラスタに対して calico-node Pod に十分な CPU リソースを確保できます。