**協助改進此頁面** 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 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 *部署*建立的 Pod。如需 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 作出的關於網路政策是否允許或拒絕連線的每項決策，都會記錄在*流程日誌*中。每個節點上的網路政策日誌均包含具有網路政策的每個 Pod 之流程日誌。網路政策日誌會儲存於 `/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` 容器額外配備 1 個 vCPU。 ### Amazon EKS 附加元件 ** AWS 管理主控台 ** 1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。 1. 在左側導覽窗格中，選取**叢集**，然後選取您要為其設定 Amazon VPC CNI 附加元件的叢集名稱。 1. 選擇**附加元件**索引標籤。 1. 選取附加元件方塊右上方的方塊，然後選擇 **Edit** (編輯)。 1. 在**設定 *Amazon VPC CNI* **頁面上： 1. 在**版本**下拉式清單中，選取 `v1.14.0-eksbuild.3` 或更高版本。 1. 展開**選用組態設定**。 1. 輸入最上層 JSON 金鑰 `"nodeAgent":`，且值為具有**組態值**中的金鑰 `"enablePolicyEventLogs":` 與 `"true"` 的值之物件。產生的文字必須是有效的 JSON 物件。下列範例顯示網路政策和網路政策日誌已啟用，並且網路政策日誌會傳送至 CloudWatch Logs： ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true" } } ``` 下列螢幕擷取畫面展示了案例的範例。 ![\[顯示選用組態中具有網路政策的 VPC CNI 附加元件和 CloudWatch 日誌的 。\]](http://docs.aws.amazon.com/zh_tw/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` 安裝 Kubernetes 專用 Amazon VPC CNI 外掛程式，您可以更新組態，以寫入網路政策日誌。 1. 執行下列命令以啟用網路政策。 ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` kubectl 如果您已透過 `kubectl` 安裝 Kubernetes 專用 Amazon VPC CNI 外掛程式，您可以更新組態，以寫入網路政策日誌。 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` 中的 `true` 取代 `false`。 ``` - 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/` 下。 #### 使用 Kubernetes 專用 Amazon VPC CNI 外掛程式傳送網路政策日誌 如果您啟用網路政策，系統會將第二個容器新增至*節點代理程式*的 `aws-node` Pod。此節點代理程式可以將網路政策日誌傳送到 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. 選取附加元件方塊右上方的方塊，然後選擇 **Edit** (編輯)。 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", } } ``` 下列螢幕擷取畫面展示了案例的範例。 ![\[顯示選用組態中具有網路政策的 VPC CNI 附加元件和 CloudWatch 日誌的 。\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.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", "enableCloudWatchLogs": "true"}}' ``` ##### 自我管理附加元件 **Helm** 如果您已透過 `helm` 安裝 Kubernetes 專用 Amazon VPC CNI 外掛程式，您可以更新組態，以傳送網路政策日誌至 CloudWatch 日誌。 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:` 中的兩個命令引數 `--enable-policy-event-logs=false` 和 `--enable-cloudwatch-logs=false` 中的 `true` 取代 `false`。 ``` - 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 Kubernetes 專用 Amazon VPC CNI 外掛程式會在節點上安裝 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/) 記載了這種行為。若要完全停用記錄，您可能需要調整其他記錄組態。 ### 網路政策映射清除問題 **問題**：刪除 Pod 後，網路 `policyendpoint` 仍然存在並且無法清除的問題。 **解決方案**：此問題是因 VPC CNI 附加元件版本 1.19.3-eksbuild.1 的問題所造成。更新至較新版本的 VPC CNI 附加元件來解決此問題。 ### 未套用網路政策 **問題**：Amazon VPC CNI 外掛程式中已啟用網路政策功能，但網路政策未正確套用。 如果您建立網路政策 `kind: NetworkPolicy`，但其不會影響 Pod，請檢查政策端點物件是否在與 Pod 相同的命名空間中建立。如果命名空間中沒有 `policyendpoint` 物件，則網路政策控制器 (EKS 叢集的一部分) 無法為要套用的網路政策代理程式 (VPC CNI 的一部分) 建立網路政策規則。 **解決方案**：解決方案是修正 VPC CNI (`ClusterRole`：`aws-node`) 和網路政策控制站 (`ClusterRole`：`eks:network-policy-controller`) 的許可，並在任何政策強制執行工具 (例如 Kyverno) 中允許這些動作。確保 Kyverno 政策不會封鎖 `policyendpoint` 物件的建立。如需了解 [新的 `policyendpoints` CRD 和許可](#network-policies-troubleshooting-permissions) 中的必要許可，請參閱上一節。 ### 在嚴格模式下刪除政策後，Pod 不會返回預設拒絕狀態 **問題**：在嚴格模式下啟用網路政策時，Pod 會從預設拒絕政策開始。套用政策後，允許流量到達指定的端點。不過，刪除政策時，Pod 不會返回預設拒絕狀態，而是進入預設允許狀態。 **解決方案**：此問題已在 VPC CNI 1.19.3 版中進行修正，其中包括網路政策代理程式 1.2.0 版。修正後，在啟用嚴格模式的情況下，只要移除政策，Pod 即會如預期返回到預設拒絕狀態。 ### Pod 啟動延遲的安全群組 **問題**：在 EKS 中使用 Pod 的安全群組功能時，Pod 啟動延遲會增加。 **解決方案**：延遲是因資源控制器中來自 `CreateNetworkInterface` API 上的 API 限流的速率限制所致，其中 VPC 資源控制器會用於為 Pod 建立分支 ENI。檢查您帳戶的此操作的 API 限制，並考慮視需要請求提高限制。 ### 由於 vpc.amazonaws.com/pod-eni 不足而導致 FailedScheduling **問題**：Pod 無法排程並出現錯誤：`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.` **解決方案**：與上一個問題一樣，將安全群組指派給 Pod 會增加 Pod 排程延遲，並且新增每個 ENI 的時間可能會超出 CNI 閾值，進而導致啟動 Pod 的失敗。這是使用 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 映像和新的網路政策控制器映像，它們沒有任何漏洞。可以更新掃描器，以解決先前版本中找到的漏洞。 ### 日誌中的流程資訊 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 移轉後的 Pod 至 pod 通訊問題 **問題**：將 EKS 叢集升級至版本 1.30 並針對網路政策從 Calico 切換到 Amazon VPC CNI 後，套用網路政策時 Pod 至 Pod 通訊即會失敗。刪除網路政策時，即會還原通訊。 **解決方案**：VPC CNI 中的網路政策代理程式指定的連接埠數量無法與 Calico 相比。請在網路政策中改用連接埠範圍。網路政策中每個通訊協定`ingress:`或`egress:`選擇器中每個通訊協定的唯一連接埠組合數目上限為 24。使用連接埠範圍來減少唯一的連接埠的數量，並避免此限制。 ### 網路政策代理程式不支援獨立 Pod **問題**：套用至獨立 Pod 的網路政策可能會有不一致的行為。 **解決方案**：網路政策代理程式目前僅支援部署為 deployment/replicaset 一部分的 Pod。如果將網路政策套用至獨立 Pod，則行為中可能會出現一些不一致。此頁面頂端、[考量事項](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) 中會記載這一情況。將 Pod 部署為 deployment 或 replicaset 的一部分，以實現一致的網路政策行為。