새 policyendpoints CRD 및 권한 네트워크 정책 로그 eBPF SDK 포함 알려진 문제 및 해결 방법

Amazon EKS에 대한 Kubernetes 네트워크 정책 문제 해결

Amazon VPC CNI의 네트워크 정책 기능에 대한 문제 해결 가이드입니다.

이 가이드에서는 다음을 다룹니다.

설치 정보, CRD 및 RBAC 권한 새 policyendpoints CRD 및 권한
네트워크 정책 문제 네트워크 정책 로그 진단 시 검사할 로그
문제 해결을 위한 eBPF SDK 도구 모음 실행
알려진 문제 및 해결 방법 알려진 문제 및 해결 방법

참고

네트워크 정책은 Kubernetes 배포에서 만든 포드에만 적용됩니다. VPC CNI의 네트워크 정책에 대한 추가 제한 사항은 고려 사항 섹션을 참조하세요.

네트워크 정책을 사용하는 네트워크 연결의 문제를 해결하고 조사하려면 네트워크 정책 로그를 읽고 eBPF SDK의 도구를 실행하여 문제를 해결할 수 있습니다.

새 `policyendpoints` CRD 및 권한

CRD: policyendpoints.networking.k8s.aws
Kubernetes API: v1.networking.k8s.io라는 apiservice
Kubernetes 리소스: Kind: NetworkPolicy
RBAC: aws-node(VPC CNI)라는 ClusterRole, eks:network-policy-controller(EKS 클러스터 컨트롤 플레인의 네트워크 정책 컨트롤러)라는 ClusterRole

네트워크 정책의 경우 VPC CNI는 policyendpoints.networking.k8s.aws라는 새 CustomResourceDefinition(CRD)을 생성합니다. VPC CNI에 CRD를 생성하고 VPC CNI(eniconfigs.crd.k8s.amazonaws.com)가 설치한 이 CRD와 다른 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가 네트워크 정책에 따라 연결을 허용할지 거부할지에 대한 각각의 결정은 흐름 로그에 기록됩니다. 각 노드의 네트워크 정책 로그에는 네트워크 정책이 있는 모든 포드의 흐름 로그가 포함됩니다. 네트워크 정책 로그는 /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 Management Console

Amazon EKS 콘솔을 엽니다.
왼쪽 탐색 창에서 클러스터를 선택한 다음 Amazon VPC CNI 추가 기능을 구성할 클러스터의 이름을 선택합니다.
추가 기능 탭을 선택합니다.
추가 기능 상자의 오른쪽 상단에 있는 상자를 선택한 다음에 편집을 선택합니다.
Amazon VPC CNI 구성 페이지에서
1. 버전 드롭다운 목록에서 v1.14.0-eksbuild.3 이상 버전을 선택합니다.
2. 선택적 구성 설정을 확장합니다.
3. 최상위 JSON 키 "nodeAgent":를 입력하고 값은 키 "enablePolicyEventLogs":와 구성 값의 "true" 값이 포함된 객체입니다. 결과 텍스트는 유효한 JSON 객체여야 합니다. 다음 예시는 네트워크 정책과 네트워크 정책 로그가 활성화되어 있으며 CloudWatch Logs로 전송된 것을 보여줍니다.
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true"
    }
}
```

다음 스크린샷은 이 시나리오의 예를 보여줍니다.

선택적 구성에서 네트워크 정책 및 CloudWatch 로그가 포함된 VPC CNI 애드온을 보여주는 <shared id=“consolelong”/>입니다.

AWS CLI

다음 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 플러그인을 설치한 경우 구성을 업데이트하여 네트워크 정책을 쓸 수 있습니다.

다음 명령을 실행하여 네트워크 정책을 활성화합니다.


helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni

kubectl

kubectl을 통해 Kubernetes용 Amazon VPC CNI 플러그인을 설치한 경우 구성을 업데이트하여 네트워크 정책을 쓸 수 있습니다.

편집기에서 aws-node DaemonSet를 엽니다.


kubectl edit daemonset -n kube-system aws-node

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/ 아래에 있습니다.

Kubernetes용 Amazon VPC CNI 플러그인을 사용하여 네트워크 정책 로그 전송

네트워크 정책을 활성화하면 두 번째 컨테이너가 노드 에이전트용 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 Management Console

Amazon EKS 콘솔을 엽니다.
왼쪽 탐색 창에서 클러스터를 선택한 다음 Amazon VPC CNI 추가 기능을 구성할 클러스터의 이름을 선택합니다.
추가 기능 탭을 선택합니다.
추가 기능 상자의 오른쪽 상단에 있는 상자를 선택한 다음에 편집을 선택합니다.
Amazon VPC CNI 구성 페이지에서
1. 버전 드롭다운 목록에서 v1.14.0-eksbuild.3 이상 버전을 선택합니다.
2. 선택적 구성 설정을 확장합니다.
3. 최상위 JSON 키 "nodeAgent":를 입력하고 값은 키 "enableCloudWatchLogs":와 구성 값의 "true" 값이 포함된 객체입니다. 결과 텍스트는 유효한 JSON 객체여야 합니다. 다음 예시는 네트워크 정책과 네트워크 정책 로그가 활성화되어 있으며 로그가 CloudWatch Logs로 전송된 것을 보여줍니다.
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true",
        "enableCloudWatchLogs": "true",
    }
}
```

다음 스크린샷은 이 시나리오의 예를 보여줍니다.

AWS CLI

다음 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 Logs로 전송할 수 있습니다.

다음 명령을 실행하여 네트워크 정책 로그를 활성화하고 CloudWatch Logs로 전송합니다.


helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni

kubectl

편집기에서 aws-node DaemonSet를 엽니다.


kubectl edit daemonset -n kube-system aws-node

VPC CNI aws-node DaemonSet 매니페스트의 aws-network-policy-agent 컨테이너에 있는 args:에서 두 명령 인수 --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 포함

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에 설명되어 있습니다. 로깅을 완전히 비활성화하려면 다른 로깅 구성을 조정해야 할 수 있습니다.

네트워크 정책 맵 정리 문제

문제: 네트워크 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 및 권한에서 필요한 권한은 이전 섹션을 참조하세요.

엄격한 모드에서 정책 삭제 후 포드가 기본 거부 상태로 돌아가지 않음

문제: 네트워크 정책이 엄격한 모드에서 활성화되면 포드가 기본 거부 정책으로 시작합니다. 정책이 적용된 후 지정된 엔드포인트로 트래픽이 허용됩니다. 그러나 정책가 삭제되면 포드가 기본 거부 상태로 돌아가지 않고 대신 기본 허용 상태로 전환됩니다.

해결 방법: 이 문제는 네트워크 정책 에이전트 1.2.0 릴리스가 포함된 VPC CNI 릴리스 1.19.3에서 수정되었습니다. 엄격한 모드가 활성화된 상태에서 수정 후 정책이 제거되면 포드는 예상대로 기본 거부 상태로 돌아갑니다.

포드 시작 지연 시간을 위한 보안 그룹

문제: 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 임곗값을 초과하여 포드를 시작하지 못할 수 있습니다. 포드에 보안 그룹을 사용할 때 예상되는 동작입니다. 워크로드 아키텍처를 설계할 때 예약에 미치는 영향을 고려하세요.

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_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에서 마이그레이션 후 포드 간 통신 문제

문제: EKS 클러스터를 버전 1.30으로 업그레이드하고 네트워크 정책을 위해 Calico에서 Amazon VPC CNI로 전환한 후 네트워크 정책 적용 시 포드 간 통신이 실패합니다. 네트워크 정책이 삭제되면 통신이 복원됩니다.

해결 방법: VPC CNI의 네트워크 정책 에이전트는 Calico만큼 많은 포트를 지정할 수 없습니다. 대신 네트워크 정책에서 포트 범위를 사용하세요. 네트워크 정책의 각 ingress: 또는 egress: 선택기에서 각 프로토콜의 고유한 포트 조합 최대 수는 24입니다. 포트 범위를 사용하여 고유한 포트 수를 줄이고 이러한 제한을 방지하세요.

네트워크 정책 에이전트는 독립 실행형 포드를 지원하지 않습니다.

문제: 독립 실행형 포드에 적용된 네트워크 정책에 일관되지 않은 동작이 있을 수 있습니다.

해결 방법: 네트워크 정책 에이전트는 현재 배포/replicaset의 일부로 배포된 포드만 지원합니다. 네트워크 정책이 독립 실행형 포드에 적용되는 경우 동작에 일부 불일치가 있을 수 있습니다. 이는 이 페이지 상단의 고려 사항과 GitHub의 aws-network-policy-agent GitHub 이슈 #327에 문서화되어 있습니다. 일관된 네트워크 정책 동작을 위해 배포 또는 replicaset의 일부로 포드를 배포하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

비활성화

Stars Policy 데모

Amazon EKS에 대한 Kubernetes 네트워크 정책 문제 해결

참고

새 policyendpoints CRD 및 권한

네트워크 정책 로그

참고

Amazon EKS 추가 기능

자체 관리형 추가 기능

네트워크 정책 로그를 Amazon CloudWatch Logs로 전송

Kubernetes용 Amazon VPC CNI 플러그인을 사용하여 네트워크 정책 로그 전송

참고

사전 조건

Amazon EKS 추가 기능

자체 관리형 추가 기능

Fluent Bit DaemonSet로 네트워크 정책 로그 전송

eBPF SDK 포함

알려진 문제 및 해결 방법

enable-policy-event-logs가 false로 설정되어 있음에도 불구하고 네트워크 정책 로그가 생성됨

네트워크 정책 맵 정리 문제

네트워크 정책이 적용되지 않음

엄격한 모드에서 정책 삭제 후 포드가 기본 거부 상태로 돌아가지 않음

포드 시작 지연 시간을 위한 보안 그룹

vpc.amazonaws.com/pod-eni 부족으로 인한 FailedScheduling

IPAM 연결 문제 및 세분화 결함

이름 오류로 디바이스를 찾을 수 없음

Multus CNI 이미지의 CVE 취약성

로그의 흐름 정보 DENY 판정

Calico에서 마이그레이션 후 포드 간 통신 문제

네트워크 정책 에이전트는 독립 실행형 포드를 지원하지 않습니다.

새 `policyendpoints` CRD 및 권한

Fluent Bit `DaemonSet`로 네트워크 정책 로그 전송