Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Cloud NAT のトラブルシューティング

このガイドは、ワークロード（Pod または VM）が Cloud NAT を使用して外部ネットワークにアクセスできない理由を診断するのに役立ちます。デベロッパーは主に CloudNatGateway リソースを操作します。このリソースのステータスは、デバッグの信頼できる主要な情報源です。

始める前に

Cloud NAT 構成のトラブルシューティングを行うには、次のものが必要です。

必要な ID とアクセスロール。次のロールのいずれかまたは両方を付与するよう IAM プロジェクト管理者に依頼します。
- Cloud NAT 閲覧者（cloud-nat-viewer）: このロールは、Cloud NAT リソースへの読み取り専用アクセス権を付与します。このロールにより、問題の診断を開始できます。
- Cloud NAT デベロッパー（cloud-nat-developer）: このロールは、アプリケーションオペレーターが割り当てられたプロジェクト内で Cloud NAT オブジェクトの作成、読み取り、更新、削除（CRUD）を行うために必要な権限を付与します。このロールを使用すると、このページで説明する修正の多くを実行できます。
- 特定の診断手段と修正には、追加のロールが必要になる場合があります。

初期診断

エラーコードを詳しく調べる前に、基本的なリソースが存在し、アクセス可能であることを確認してください。

コマンド:

kubectl get cloudnatgateway GATEWAY_NAME -n PROJECT_NAMESPACE -o yaml

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

GATEWAY_NAME: CloudNatGateway リソースの名前。
PROJECT_NAMESPACE: プロジェクトの Namespace。

ステータス条件を確認する: 正常なゲートウェイでは、次のすべての条件が True に設定されている必要があります。

Ready: グローバルな健全性ステータス。
SubnetsReady: IP プールの構成が有効です。
PerimeterConfigurationReady: アップストリームネットワークインフラストラクチャが構成されている。
EgressRoutesReady: Pod のルーティングポリシーが有効です。

いずれかが False の場合は、ステータス出力の reason フィールドと message フィールドを確認し、次のセクションの表を参照してください。

エラーコードリファレンスと修正

kubectl get cloudnatgateway から返されるエラーコードは、主に 3 つのカテゴリに分類されます。

サブネットエラー（`SubnetsReady` が False）

この状態は、ゲートウェイに割り当てられた IP アドレスプールに問題があることを示します。

エラーコード	具体的な内容	修復手順
`CloudNATSelectorFieldOverlapsCode`	構成の競合。このゲートウェイの `workloadSelector` は、プロジェクト内の別のゲートウェイと同じワークロードと一致します。トラフィックを決定論的にルーティングできない。	プロジェクト内のすべての Cloud NAT ゲートウェイを一覧表示します。`kubectl get cloudnatgateway` このゲートウェイの `workloadSelector` を他のゲートウェイと比較します。 1 つの Pod/VM が複数のゲートウェイによって選択されないようにラベルを変更します。
`CloudNATSubnetRefsFieldInvalidCode`	サブネットが無効です。`subnetRefs` で指定されたサブネットは使用できません。一般的な理由: サブネットが存在しません。サブネットが `Ready` 状態ではありません。サブネットのタイプが `Leaf` ではありません。	サブネットが存在することを確認します。`kubectl get subnet <SUBNET_NAME>` サブネットのステータスが `Ready` であることを確認します。サブネット `type` が `Leaf` であることを確認します（Cloud NAT はルートサブネットまたはループバックサブネットを使用できません）。
`CloudNATSubnetAlreadyInUseCode`	サブネットの競合。リクエストしたサブネットは、すでに別の Cloud NAT ゲートウェイによって「所有」されています。サブネットは一度に 1 つのゲートウェイにのみ接続できます。	このゲートウェイに別のサブネットを選択してください。または、最初に他のゲートウェイからサブネットを削除します。
`UNETAPIServerErrorCode`	システムエラー。コントローラが API サーバーと通信してサブネットを検証できない。	対応: これは一時的なプラットフォームの問題である可能性があります。問題が解決しない場合は、プラットフォーム管理者にお問い合わせください。

境界構成エラー（`PerimeterConfigurationReady` が False）

この条件は、境界ゲートウェイのステータスを反映します。

エラーコード	具体的な内容	修復手順
`NET-E0305`	構成の競合。（同上）。セレクタが重複していると、システムが正しいルーティンググループを計算できません。	プロジェクト内のすべての Cloud NAT ゲートウェイを一覧表示します。`kubectl get cloudnatgateway` このゲートウェイの `workloadSelector` を他のゲートウェイと比較します。 1 つの Pod/VM が複数のゲートウェイによって選択されないようにラベルを変更します。
`NET-E0301`	リソースの枯渇 / ノード障害。システムは構成を作成しましたが、下り（外向き）IP を正常な物理ノードに割り当てることができませんでした。これは通常、サブネットの IP が不足しているか、ゲートウェイノードがダウンしていることを意味します。	[サブネット](/distributed-cloud/hosted/docs/latest/gdcag/platform/pa-user/subnets-overview)の使用状況を確認します。満杯ですか？サブネットに空き IP があり、`Ready` の場合は、プラットフォーム側のインフラストラクチャ障害（正常なゲートウェイノードが使用できないなど）を示します。対応: プラットフォーム管理者に連絡します。
`NET-E0001`	システムエラー。コントローラの通信障害。	対応: プラットフォーム管理者に連絡します。

下り（外向き）ルートエラー（`EgressRoutesReady` が False）

この条件は、クラスタ内のルーティングポリシーのステータスを反映します。

エラーコード具体的な内容修復手順

エラーコード	具体的な内容	修復手順
`NET-E0305`	構成の競合。（同上）。	プロジェクト内のすべての Cloud NAT ゲートウェイを一覧表示します。`kubectl get cloudnatgateway` このゲートウェイの `workloadSelector` を他のゲートウェイと比較します。 1 つの Pod/VM が複数のゲートウェイによって選択されないようにラベルを変更します。
`NET-E0304`	プログラミングの失敗。システムが特定のゲートウェイ IP のルーティングルール（BPF）をプログラムできませんでした。	対応策: これは内部プログラミングエラーまたは状態の不整合です。 Gateway に簡単な更新（ラベルの編集など）を加えて、調整をトリガーしてみてください。問題が解決しない場合は、プラットフォーム管理者にお問い合わせください。

NET-E0305

構成の競合。（同上）。

プロジェクト内のすべての Cloud NAT ゲートウェイを一覧表示します。kubectl get cloudnatgateway
このゲートウェイの workloadSelector を他のゲートウェイと比較します。
1 つの Pod/VM が複数のゲートウェイによって選択されないようにラベルを変更します。

NET-E0304

プログラミングの失敗。システムが特定のゲートウェイ IP のルーティングルール（BPF）をプログラムできませんでした。

対応策: これは内部プログラミングエラーまたは状態の不整合です。

Gateway に簡単な更新（ラベルの編集など）を加えて、調整をトリガーしてみてください。
問題が解決しない場合は、プラットフォーム管理者にお問い合わせください。

その他の一般的な問題

Gateway のステータスが Ready: True であるにもかかわらず、トラフィックが失敗する場合は、次の一般的な構成ミスを確認してください。

プロジェクトレベルの権限がありません

プロジェクトは、外向きトラフィックを明示的に承認されている必要があります。

確認: プロジェクトリソースに networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" ラベルが付いているか。
修正: このラベルを適用するようプロジェクト管理者に依頼します。

VM アノテーションがない（仮想マシンのみ）

VM は標準の Pod 下り（外向き）パスをバイパスするため、Cloud NAT を使用するように明示的に指示する必要があります。

確認: VM の VirtualMachineExternalAccess（VMEA）オブジェクトにアノテーション egress.networking.gke.io/use-cloud-nat: "true" がありますか？
修正: VMEA オブジェクトにアノテーションを追加します。

Standard クラスタノードの下り（外向き）

Standard クラスタを実行している場合は、ノード自体に下り（外向き）の権限が必要です。

確認: Cluster オブジェクトにラベル cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true" が付いているか。
修正: プラットフォーム管理者に Cluster オブジェクトにラベルを付けるよう依頼します。

デフォルトの Egress NAT と Cloud NAT の競合

一般的な構成エラーは、ワークロードが以前のデフォルトの下り（外向き）NAT メカニズムを使用するように構成されていると同時に、Cloud NAT ゲートウェイによって選択されている場合に発生します。この組み合わせにより、データプレーンが競合するルーティング指示を受け取り、パケットロスや非決定的なルーティング動作が発生します。

Pod の競合を診断する

Pod の場合、デフォルトの下り（外向き）NAT は通常、特定のラベルを追加することで有効になります。Cloud NAT ゲートウェイのターゲットになっている Pod にこのラベルを付けることはできません。

ターゲット Pod を特定する: 接続の問題が発生している Pod のラベルを取得します。
```
kubectl get pod <POD_NAME> -n <NAMESPACE> --show-labels
```
競合するラベルを確認する:
- Cloud NAT の選択: Pod のラベルが Namespace 内の CloudNatGateway の workloadSelector と一致するかどうか。
- デフォルトの下り（外向き）ラベル: Pod に egress.networking.gke.io/enabled: "true" ラベルが付いているかどうか。
条件: 両方が true の場合、衝突が発生しています。
解決策: Pod（またはその親 Deployment/StatefulSet）から以前のデフォルトの下り（外向き）ラベルを削除して、Cloud NAT が排他的に制御できるようにします。

VM の競合を診断する

仮想マシンの場合、メカニズムは異なります。VirtualMachineExternalAccess（VMEA）オブジェクトを含む VM は、多くの場合、デフォルトアクセス用に構成されます。Cloud NAT を使用するには、デフォルトのパスを無効にして Cloud NAT パスを有効にするアノテーションを追加して、明示的にオプトインする必要があります。

VMEA を特定する: VM に関連付けられている VirtualMachineExternalAccess オブジェクトを見つけます。
```
kubectl get vmea -n <NAMESPACE>
```
注釈の欠落チェック:
- Cloud NAT の選択: VM のラベルが CloudNatGateway と一致するか？
- オプトインアノテーション: VMEA でアノテーション egress.networking.gke.io/use-cloud-nat: "true" を確認します。
条件: VM がゲートウェイと一致するが、このアノテーションがない場合、トラフィックはデフォルトの下り（外向き）システムと競合します。

解決策: VMEA オブジェクトにアノテーションを追加します。

kubectl annotate vmea <VMEA_NAME> -n <NAMESPACE> egress.networking.gke.io/use-cloud-nat="true"

Cloud NAT のトラブルシューティング コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。