**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Amazon EKS の Kubernetes ネットワークポリシーのトラブルシューティング
これは、Amazon VPC CNI のネットワークポリシー機能のトラブルシューティングガイドです。
このガイドでは、以下について説明します。
+ インストール情報、CRD、RBAC アクセス許可 [新しい `policyendpoints` CRD とアクセス許可](#network-policies-troubleshooting-permissions)
+ ネットワークポリシーの問題の診断時に調べるログ [ネットワークポリシーのログ](#network-policies-troubleshooting-flowlogs)
+ トラブルシューティング用の eBPF SDK ツール群の実行
+ 既知の問題と解決策 [既知の問題と解決策](#network-policies-troubleshooting-known-issues)
**注記**
ネットワークポリシーは、Kubernetes *デプロイメント*によって作成されたポッドにのみ適用されることに注意してください。VPC CNI のネットワークポリシーにおける他の制限事項については、「[考慮事項](cni-network-policy.md#cni-network-policy-considerations)」を参照してください。
[ネットワークポリシーのログ](#network-policies-troubleshooting-flowlogs)を読み、[eBPF SDK](#network-policies-ebpf-sdk) のツールを実行することにより、ネットワークポリシーを使用するネットワーク接続をトラブルシューティングおよび調査できます。
## 新しい `policyendpoints` CRD とアクセス許可
+ CRD: `policyendpoints.networking.k8s.aws`
+ Kubernetes API: `v1.networking.k8s.io` と呼ばれる `apiservice`
+ Kubernetes リソース: `Kind: NetworkPolicy`
+ RBAC: `aws-node` と呼ばれる `ClusterRole` (VPC CNI)、`eks:network-policy-controller` と呼ばれる `ClusterRole` (EKS クラスターコントロールプレーンのネットワークポリシーコントローラー)
ネットワークポリシーの場合、VPC CNI は `policyendpoints.networking.k8s.aws` と呼ばれる新しい `CustomResourceDefinition` (CRD) を作成します。VPC CNI には CRD を作成し、この CRD および VPC CNI (`eniconfigs.crd.k8s.amazonaws.com`) によってインストールされたその他の CRD の CustomResources (CR) を作成するアクセス許可が必要です。両方の CRD は GitHub の [`crds.yaml` ファイル](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml)で利用できます。具体的には、VPC CNI には `policyendpoints` の「get」、「list」、「watch」動詞のアクセス許可が必要です。
Kubernetes *ネットワークポリシー*は、`v1.networking.k8s.io` と呼ばれる `apiservice` の一部であり、これはポリシー YAML ファイル内では `apiversion: networking.k8s.io/v1` となります。VPC CNI `DaemonSet` には、Kubernetes API のこの部分を使用するアクセス許可が必要です。
VPC CNI アクセス許可は、`aws-node` と呼ばれる `ClusterRole` にあります。`ClusterRole` オブジェクトは、名前空間にグループ化されないことに注意してください。次の内容では、クラスターの `aws-node` が示されます。
```
kubectl get clusterrole aws-node -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/instance: aws-vpc-cni
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: aws-node
app.kubernetes.io/version: v1.19.4
helm.sh/chart: aws-vpc-cni-1.19.4
k8s-app: aws-node
name: aws-node
rules:
- apiGroups:
- crd.k8s.amazonaws.com
resources:
- eniconfigs
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- namespaces
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- pods
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- list
- watch
- get
- apiGroups:
- ""
- events.k8s.io
resources:
- events
verbs:
- create
- patch
- list
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- apiGroups:
- vpcresources.k8s.aws
resources:
- cninodes
verbs:
- get
- list
- watch
- patch
```
また、新しいコントローラーは各 EKS クラスターのコントロールプレーンで実行されます。コントローラーは、`eks:network-policy-controller` と呼ばれる `ClusterRole` のアクセス許可を使用します。次の内容では、クラスターの `eks:network-policy-controller` が示されます。
```
kubectl get clusterrole eks:network-policy-controller -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/name: amazon-network-policy-controller-k8s
name: eks:network-policy-controller
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/finalizers
verbs:
- update
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- patch
- update
- apiGroups:
- networking.k8s.io
resources:
- networkpolicies
verbs:
- get
- list
- patch
- update
- watch
```
## ネットワークポリシーのログ
ネットワークポリシーによって接続が許可されるか拒否されるかについての VPC CNI による各判定は、*フローログ*に記録されます。各ノードのネットワークポリシーログにはネットワークポリシーが設定されているすべてのポッドのフローログが含まれます。ネットワークポリシーログは `/var/log/aws-routed-eni/network-policy-agent.log` に保存されます。次の例は `network-policy-agent.log` ファイルからのものです。
```
{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}
```
ネットワークポリシーログはデフォルトで無効になっています。ネットワークポリシーログを有効にするには次の手順に従います。
**注記**
ネットワークポリシーログには、VPC CNI `aws-node` `DaemonSet` マニフェストの `aws-network-policy-agent` コンテナ用に vCPU をさらに 1 つ追加する必要があります。
### Amazon EKS アドオン
** AWS マネジメントコンソール **
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、 Amazon VPC CNI アドオンを設定するクラスターの名前を選択してください。
1. **[アドオン]** タブを選択してください。
1. アドオンボックスの右上にあるボックスを選択し、次に **[編集]** を選択してください。
1. ***Amazon VPC CNI *の設定**ページで、次の手順に従います。
1. **[バージョン]** ドロップダウンリストで `v1.14.0-eksbuild.3` 以降のバージョンを選択してください。
1. **[オプションの構成設定]** を展開します。
1. 最上位の JSON キー `"nodeAgent":` を入力してください。値は **[設定値]** にキー `"enablePolicyEventLogs":` と `"true"` の値を持つオブジェクトです。結果のテキストは有効な JSON オブジェクトでなければなりません。次の例はネットワークポリシーとネットワークポリシーログが有効になっており、ネットワークポリシーログが CloudWatch Logs に送信されていることを示しています。
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true"
}
}
```
次のスクリーンショットはこのシナリオの例を示しています。
![\[オプション設定でネットワークポリシーおよび CloudWatch ログが設定されている VPC CNI アドオンを示す 。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/console-cni-config-network-policy-logs.png)
AWS CLI
1. 次の AWS CLI コマンドを実行してください。`my-cluster` をクラスターの名前に置き換え、IAM 役割 ARN を使用する役割に置き換えます。
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'
```
### セルフマネージド型アドオン
Helm
`helm` を通して Amazon VPC CNI plugin for Kubernetes をインストールしている場合、設定を更新してネットワークポリシーログを記述できます。
1. 次のコマンドを実行してネットワークポリシーを有効にします。
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
kubectl
`kubectl` を通して Amazon VPC CNI plugin for Kubernetes をインストールしている場合、設定を更新してネットワークポリシーログを記述できます。
1. エディターで `aws-node``DaemonSet` を開きます。
```
kubectl edit daemonset -n kube-system aws-node
```
1. VPC CNI `aws-node` `DaemonSet` マニフェストの `aws-network-policy-agent` コンテナで、`args:` のコマンド引数 `--enable-policy-event-logs=false` で `false` を `true` に置き換えます。
```
- args:
- --enable-policy-event-logs=true
```
### ネットワークポリシーログを Amazon CloudWatch Logs に送信する
Amazon CloudWatch Logs などのサービスを使用して、ネットワークポリシーログをモニタリングできます。次の方法を使用して、ネットワークポリシーログを CloudWatch Logs に送信できます。
EKS クラスターの場合、ポリシー ログは `/aws/eks/cluster-name/cluster/` の下に配置され、セルフマネージド K8S クラスターの場合、ログは `/aws/k8s-cluster/cluster/` の下に配置されます。
#### Amazon VPC CNI plugin for Kubernetes によるネットワークポリシーログの送信
ネットワークポリシーを有効にすると、2 つ目のコンテナが*ノードエージェント*の `aws-node` ポッドに追加されます。このノードエージェントはネットワークポリシーログを CloudWatch Logs に送信できます。
**注記**
ノードエージェントはネットワークポリシーログのみを送信します。VPC CNI によって作成された他のログは含まれません。
##### 前提条件
+ VPC CNI に使用している IAM 役割に、次の権限をスタンザまたは個別のポリシーとして追加します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
##### Amazon EKS アドオン
** AWS マネジメントコンソール **
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、 Amazon VPC CNI アドオンを設定するクラスターの名前を選択してください。
1. **[アドオン]** タブを選択してください。
1. アドオンボックスの右上にあるボックスを選択し、次に **[編集]** を選択してください。
1. ***Amazon VPC CNI *の設定**ページで、次の手順に従います。
1. **[バージョン]** ドロップダウンリストで `v1.14.0-eksbuild.3` 以降のバージョンを選択してください。
1. **[オプションの構成設定]** を展開します。
1. 最上位の JSON キー `"nodeAgent":` を入力してください。値は **[設定値]** にキー `"enableCloudWatchLogs":` と `"true"` の値を持つオブジェクトです。結果のテキストは有効な JSON オブジェクトでなければなりません。次の例はネットワークポリシーとネットワークポリシーログが有効になっており、ログが CloudWatch Logs に送信されていることを示しています。
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true",
"enableCloudWatchLogs": "true",
}
}
```
次のスクリーンショットはこのシナリオの例を示しています。
![\[オプション設定でネットワークポリシーおよび CloudWatch ログが設定されている VPC CNI アドオンを示す 。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png)
** AWSCLI**
1. 次の AWS CLI コマンドを実行してください。`my-cluster` をクラスターの名前に置き換え、IAM 役割 ARN を使用する役割に置き換えます。
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'
```
##### セルフマネージド型アドオン
**Helm**
`helm` を通して Amazon VPC CNI plugin for Kubernetes をインストールしている場合、設定を更新してネットワークポリシーログを CloudWatch Logs に送信できます。
1. 次のコマンドを実行してネットワークポリシーログを有効にし、CloudWatch Logs に送信します。
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
**kubectl**
1. エディターで `aws-node``DaemonSet` を開きます。
```
kubectl edit daemonset -n kube-system aws-node
```
1. VPC CNI `aws-node` `DaemonSet` マニフェストの `aws-network-policy-agent` コンテナで、`args:` の 2 つのコマンド引数 `--enable-policy-event-logs=false` および `--enable-cloudwatch-logs=false` の `false` を `true` に置き換えます。
```
- args:
- --enable-policy-event-logs=true
- --enable-cloudwatch-logs=true
```
#### Fluent Bit `DaemonSet`と一緒にネットワークポリシーログの送信
`DaemonSet` で Fluent Bit を使用してノードからログを送信する場合、ネットワークポリシーのネットワークポリシーログを含めるように設定を追加できます。次の設定例を使用できます。
```
[INPUT]
Name tail
Tag eksnp.*
Path /var/log/aws-routed-eni/network-policy-agent*.log
Parser json
DB /var/log/aws-routed-eni/flb_npagent.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Refresh_Interval 10
```
## eBPF SDK の内容
Amazon VPC CNI plugin for Kubernetes は、複数のツールをまとめた eBPF SDK コレクションをノードにインストールします。eBPF SDK ツールを使用して、ネットワークポリシーの問題を特定できます。例えば、次のコマンドはノードで実行されているプログラムを一覧表示します。
```
sudo /opt/cni/bin/aws-eks-na-cli ebpf progs
```
このコマンドを実行するために、任意の方法を使用してノードに接続できます。
## 既知の問題と解決策
次のセクションでは、Amazon VPC CNI ネットワークポリシーの機能に関する既知の問題とその解決策について説明します。
### enable-policy-event-logs が「false」に設定されているにも関わらず、ネットワークポリシーログが生成される
**問題**: `enable-policy-event-logs` 設定が `false` に設定されている場合でも、EKS VPC CNI によってネットワークポリシーログが生成される。
**解決策**: `enable-policy-event-logs` 設定はポリシー「決定」ログのみを無効にしますが、すべてのネットワークポリシーエージェントのログ記録が無効になるわけではありません。この動作については、GitHub の「[aws-network-policy-agent README](https://github.com/aws/aws-network-policy-agent/)」に記載されています。ログ記録を完全に無効にするには、他のログ記録設定の調整が必要な場合があります。
### ネットワークポリシーマップのクリーンアップ問題
**問題**: ポッドが削除された後も、ネットワーク `policyendpoint` が残り続けてクリーンアップされない問題。
**解決策**: この問題は、VPC CNI アドオンバージョン 1.19.3-eksbuild.1 による問題で発生しました。この問題を解決するには、VPC CNI アドオンの新しいバージョンに更新してください。
### ネットワークポリシーが適用されない
**問題**: Amazon VPC CNI プラグインでネットワークポリシー機能が有効になっているが、ネットワークポリシーが正しく適用されない。
ネットワークポリシー `kind: NetworkPolicy` を作成してもポッドに影響を与えない場合、ポリシーエンドポイントオブジェクトがポッドと同じ名前空間で作成されていることを確認します。名前空間に `policyendpoint` オブジェクトがない場合、ネットワークポリシーコントローラー (EKS クラスターの一部) が、ネットワークポリシーエージェント (VPC CNI の一部) が適用するためのネットワークポリシールールを作成できなかったということです。
**解決策**: この解決策は、VPC CNI (`ClusterRole`: `aws-node`) およびネットワークポリシーコントローラー (`ClusterRole`: `eks:network-policy-controller`) のアクセス許可を修正し、Kyverno などのポリシー実施ツールでこれらのアクションを許可することです。Kyverno ポリシーが `policyendpoint` オブジェクトの作成をブロックしていないことを確認してください。必要なアクセス許可については、「[新しい `policyendpoints` CRD とアクセス許可](#network-policies-troubleshooting-permissions)」で前のセクションを参照してください。
### strict モードでポリシーを削除してもポッドがデフォルトの拒否状態に戻らない
**問題**: ネットワークポリシーが strict モードで有効になっている場合、ポッドはデフォルト拒否ポリシーで開始されます。ポリシーが適用されると、指定されたエンドポイントへのトラフィックが許可されます。しかし、ポリシーが削除されても、ポッドがデフォルト拒否状態に戻らず、代わりにデフォルト許可状態になってしまいます。
**解決策**: この問題は、ネットワークポリシーエージェント 1.2.0 のリリースを含む VPC CNI リリース 1.19.3 で修正されました。修正後は、strict モードを有効にすると、ポリシーが削除されるとポッドは期待どおりにデフォルト拒否状態に戻ります。
### ポッドの起動レイテンシーのセキュリティグループ
**問題**: EKS でポッド機能のセキュリティグループを使用すると、ポッドの起動レイテンシーが増加する。
**解決策**: レイテンシーは、VPC リソースコントローラーがポッドのブランチ ENI を作成するために使用する `CreateNetworkInterface` API の API スロットリングによるリソースコントローラーのレート制限によるものです。このオペレーションのアカウントの API 制限を確認し、必要に応じて上限の引き上げをリクエストすることを検討してください。
### vpc.amazonaws.com/pod-eni の不足による FailedScheduling
**問題**: 以下のエラーにより、ポッドのスケジューリングが失敗する: `FailedScheduling 2m53s (x28 over 137m) default-scheduler 0/5 nodes are available: 5 Insufficient vpc.amazonaws.com/pod-eni. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.`
**解決策**: 前の問題と同様に、ポッドにセキュリティグループを割り当てると、ポッドスケジューリングのレイテンシーが増加し、各 ENI を追加する時間の CNI しきい値を超えて増加するため、ポッド起動が失敗する原因になります。これは、Podのセキュリティグループを使用するときに予期される動作です。ワークロードアーキテクチャを設計する際、スケジューリングの影響を考慮してください。
### IPAM の接続問題とセグメンテーション障害
**問題**: IPAM の接続問題、スロットリングのリクエスト、セグメンテーションの障害など、複数のエラーが発生する。
+ `Checking for IPAM connectivity …`
+ `Throttling request took 1.047064274s`
+ `Retrying waiting for IPAM-D`
+ `panic: runtime error: invalid memory address or nil pointer dereference`
**解決策**: AL2023 で `systemd-udev` をインストールすると、破損を引き起こすポリシーでファイルが書き換えられるため、この問題が発生します。パッケージが更新された別の `releasever` に更新する場合、またはパッケージ自体を手動で更新する場合に発生する可能性があります。AL2023 ノードでは、`systemd-udev` をインストールまたは更新しないでください。
### デバイス名による検索失敗エラー
**問題**: エラーメッセージ: `{"level":"error","ts":"2025-02-05T20:27:18.669Z","caller":"ebpf/bpf_client.go:578","msg":"failed to find device by name eni9ea69618bf0: %!w(netlink.LinkNotFoundError={0xc000115310})"}`
**解決策**: この問題は、Amazon VPC CNI ネットワークポリシーエージェント (v1.2.0) の最新バージョンで特定されて修正されています。この問題を解決するには、VPC CNI の最新バージョンに更新してください。
### Multus CNI イメージの CVE 脆弱性
**問題**: 拡張された EKS ImageScan CVE レポートで、Multus CNI イメージバージョン v4.1.4-eksbuild.2\$1thick の脆弱性が特定されている。
**解決策**: 脆弱性のない Multus CNI イメージの新しいバージョンおよび新しい Network Policy Controller イメージに更新します。スキャナーを更新することで、以前のバージョンで見つかった脆弱性に対処できます。
### ログのフロー情報の「DENY」判定
**問題**: ネットワークポリシーログに次の DENY 判定が表示される: `{"level":"info","ts":"2024-11-25T13:34:24.808Z","logger":"ebpf-client","caller":"events/events.go:193","msg":"Flow Info: ","Src IP":"","Src Port":9096,"Dest IP":"","Dest Port":56830,"Proto":"TCP","Verdict":"DENY"}`
**解決策**: この問題は、ネットワークポリシーコントローラーの新しいバージョンで解決されています。ログ記録の問題を解決するには、最新の EKS プラットフォームバージョンに更新してください。
### Calico から移行後のポッド間の通信問題
**問題**: EKS クラスターをバージョン 1.30 にアップグレードし、ネットワークポリシーを Calico から Amazon VPC CNI に切り替えた後、ネットワークポリシーが適用されるとポッド間の通信が失敗する。ネットワークポリシーを削除すると通信は回復する。
**解決策**: VPC CNI のネットワークポリシーエージェントには、Calico ほど多くのポートを指定することができません。代わりに、ネットワークポリシーでポート範囲を使用します。ネットワークポリシーの各 `ingress:` または `egress:` セレクターの各プロトコルにおけるポートの一意の組み合わせの最大数は 24 です。ポート範囲を使用して一意のポート数を減らし、この制限を回避します。
### ネットワークポリシーエージェントがスタンドアロンポッドをサポートしない
**問題**: スタンドアロンポッドに適用されるネットワークポリシーは、一貫性のない動作を示す可能性がある。
**解決策**: 現在、ネットワークポリシーエージェントは、デプロイメント/レプリカセットの一部としてデプロイされたポッドのみをサポートしています。ネットワークポリシーがスタンドアロンポッドに適用された場合、一貫性のない動作を示す可能性があります。これは、このページの上部の「[考慮事項](cni-network-policy.md#cni-network-policy-considerations)」および GitHub の「[aws-network-policy-agent の GitHub 問題 \$1327](https://github.com/aws/aws-network-policy-agent/issues/327)」に記載されています。整合性のあるネットワークポリシーの動作のため、デプロイまたはレプリカセットの一部としてポッドをデプロイします。