**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **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`(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` 파일](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 Management Console **
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/ko_kr/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`에서 `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 **
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/ko_kr/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`을 통해 Kubernetes용 Amazon VPC CNI 플러그인을 설치한 경우 구성을 업데이트하여 네트워크 정책 로그를 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:`에서 두 명령 인수 `--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](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)에서 필요한 권한은 이전 섹션을 참조하세요.
### 엄격한 모드에서 정책 삭제 후 포드가 기본 거부 상태로 돌아가지 않음
**문제**: 네트워크 정책이 엄격한 모드에서 활성화되면 포드가 기본 거부 정책으로 시작합니다. 정책이 적용된 후 지정된 엔드포인트로 트래픽이 허용됩니다. 그러나 정책가 삭제되면 포드가 기본 거부 상태로 돌아가지 않고 대신 기본 허용 상태로 전환됩니다.
**해결 방법**: 이 문제는 네트워크 정책 에이전트 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\$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에서 마이그레이션 후 포드 간 통신 문제
**문제**: EKS 클러스터를 버전 1.30으로 업그레이드하고 네트워크 정책을 위해 Calico에서 Amazon VPC CNI로 전환한 후 네트워크 정책 적용 시 포드 간 통신이 실패합니다. 네트워크 정책이 삭제되면 통신이 복원됩니다.
**해결 방법**: VPC CNI의 네트워크 정책 에이전트는 Calico만큼 많은 포트를 지정할 수 없습니다. 대신 네트워크 정책에서 포트 범위를 사용하세요. 네트워크 정책의 각 `ingress:` 또는 `egress:` 선택기에서 각 프로토콜의 고유한 포트 조합 최대 수는 24입니다. 포트 범위를 사용하여 고유한 포트 수를 줄이고 이러한 제한을 방지하세요.
### 네트워크 정책 에이전트는 독립 실행형 포드를 지원하지 않습니다.
**문제**: 독립 실행형 포드에 적용된 네트워크 정책에 일관되지 않은 동작이 있을 수 있습니다.
**해결 방법**: 네트워크 정책 에이전트는 현재 배포/replicaset의 일부로 배포된 포드만 지원합니다. 네트워크 정책이 독립 실행형 포드에 적용되는 경우 동작에 일부 불일치가 있을 수 있습니다. 이는 이 페이지 상단의 [고려 사항](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)에 문서화되어 있습니다. 일관된 네트워크 정책 동작을 위해 배포 또는 replicaset의 일부로 포드를 배포하세요.