協助改進此頁面

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的在 GitHub 上編輯此頁面連結。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

對 Amazon EKS 的 Kubernetes 網路政策進行故障診斷

這是 Amazon VPC CNI 的網路政策功能的故障診斷指南。

本指南涵蓋：

閱讀網路政策日誌並透過執行來自 eBPF SDK 的工具，藉此對使用網路政策的網路連線進行故障診斷與調查。

新的 policyendpoints CRD 和許可

對於網路政策，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 檔案中找到。具體而言，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"}

根據預設，網路政策日誌已停用。若要啟用網路政策日誌，請遵循下列步驟：

Amazon EKS 附加元件

下列螢幕擷取畫面展示了案例的範例。

自我管理附加元件

將網路政策日誌傳送到 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。

先決條件

Amazon EKS 附加元件

自我管理附加元件

透過 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 記載了這種行為。若要完全停用記錄，您可能需要調整其他記錄組態。

網路政策映射清除問題

問題：刪除 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 和許可 中的必要許可，請參閱上一節。

在嚴格模式下刪除政策後，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 連線問題、限流請求和分段錯誤：

解決方案：如果您在 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_thick 中的漏洞。

解決方案：更新至新版本的 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，則行為中可能會出現一些不一致。此頁面頂端、考量事項 中和 GitHub 上的 aws-network-policy-agent GitHub 問題 #327 中會記載這一情況。將 Pod 部署為 deployment 或 replicaset 的一部分，以實現一致的網路政策行為。