**Bantu tingkatkan halaman ini**
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Untuk berkontribusi pada panduan pengguna ini, pilih **Edit halaman ini pada GitHub** tautan yang terletak di panel kanan setiap halaman.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah kebijakan jaringan Kubernetes Untuk Amazon EKS
Ini adalah panduan pemecahan masalah untuk fitur kebijakan jaringan Amazon VPC CNI.
Panduan ini mencakup:
+ Instal informasi, izin CRD dan RBAC [`policyendpoints`CRD dan izin baru](#network-policies-troubleshooting-permissions)
+ Log untuk memeriksa saat mendiagnosis masalah kebijakan jaringan [Log kebijakan jaringan](#network-policies-troubleshooting-flowlogs)
+ Menjalankan koleksi alat eBPF SDK untuk memecahkan masalah
+ Masalah dan solusi yang diketahui [Masalah dan solusi yang diketahui](#network-policies-troubleshooting-known-issues)
**catatan**
*Perhatikan bahwa kebijakan jaringan hanya diterapkan pada pod yang dibuat oleh Deployment Kubernetes.* Untuk batasan lebih lanjut dari kebijakan jaringan di VPC CNI, lihat. [Pertimbangan-pertimbangan](cni-network-policy.md#cni-network-policy-considerations)
[Anda dapat memecahkan masalah dan menyelidiki koneksi jaringan yang menggunakan kebijakan jaringan dengan membaca [log kebijakan Jaringan](#network-policies-troubleshooting-flowlogs) dan dengan menjalankan alat dari SDK eBPF.](#network-policies-ebpf-sdk)
## `policyendpoints`CRD dan izin baru
+ CRD: `policyendpoints.networking.k8s.aws`
+ Kubernetes API: dipanggil `apiservice` `v1.networking.k8s.io`
+ Sumber daya Kubernetes: `Kind: NetworkPolicy`
+ RBAC: `ClusterRole` disebut (`aws-node`VPC CNI), `ClusterRole` disebut `eks:network-policy-controller` (pengontrol kebijakan jaringan di bidang kontrol cluster EKS)
Untuk kebijakan jaringan, VPC CNI membuat baru `CustomResourceDefinition` (CRD) yang disebut. `policyendpoints.networking.k8s.aws` VPC CNI harus memiliki izin untuk membuat CRD dan membuat CustomResources (CR) ini dan CRD lainnya yang diinstal oleh VPC CNI (). `eniconfigs.crd.k8s.amazonaws.com` Keduanya CRDs tersedia dalam [`crds.yaml`file](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml) di GitHub. Secara khusus, CNI VPC harus memiliki izin kata kerja “get”, “list”, dan “watch” untuk. `policyendpoints`
*Kebijakan Jaringan* Kubernetes adalah bagian dari `apiservice` panggilan`v1.networking.k8s.io`, dan ini ada `apiversion: networking.k8s.io/v1` dalam file YAMM kebijakan Anda. VPC CNI `DaemonSet` harus memiliki izin untuk menggunakan bagian Kubernetes API ini.
Izin VPC CNI berada dalam panggilan. `ClusterRole` `aws-node` Perhatikan bahwa `ClusterRole` objek tidak dikelompokkan dalam ruang nama. Berikut ini `aws-node` menunjukkan cluster:
```
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
```
Juga, pengontrol baru berjalan di bidang kontrol setiap cluster EKS. Pengontrol menggunakan izin yang `ClusterRole` dipanggil`eks:network-policy-controller`. Berikut ini `eks:network-policy-controller` menunjukkan cluster:
```
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
```
## Log kebijakan jaringan
*Setiap keputusan oleh VPC CNI apakah koneksi diizinkan atau ditolak oleh kebijakan jaringan dicatat dalam log aliran.* Log kebijakan jaringan pada setiap node menyertakan log aliran untuk setiap pod yang memiliki kebijakan jaringan. Log kebijakan jaringan disimpan di`/var/log/aws-routed-eni/network-policy-agent.log`. Contoh berikut adalah dari sebuah `network-policy-agent.log` file:
```
{"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"}
```
Log kebijakan jaringan dinonaktifkan secara default. Untuk mengaktifkan log kebijakan jaringan, ikuti langkah-langkah berikut:
**catatan**
Log kebijakan jaringan memerlukan 1 vCPU tambahan untuk `aws-network-policy-agent` wadah dalam manifes VPC CNI. `aws-node` `DaemonSet`
### Pengaya Amazon EKS
** Konsol Manajemen AWS **
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi kiri, pilih **Cluster**, lalu pilih nama cluster yang ingin Anda konfigurasikan untuk add-on Amazon VPC CNI.
1. Pilih tab **Add-ons**.
1. Pilih kotak di kanan atas kotak add-on dan kemudian pilih **Edit**.
1. Pada *Amazon VPC CNI* halaman **Konfigurasi**:
1. Pilih versi `v1.14.0-eksbuild.3` atau yang lebih baru dalam daftar dropdown **Versi**.
1. Perluas **pengaturan konfigurasi opsional**.
1. Masukkan kunci JSON tingkat atas `"nodeAgent":` dan nilai adalah objek dengan kunci `"enablePolicyEventLogs":` dan nilai `"true"` dalam nilai **Konfigurasi**. Teks yang dihasilkan harus berupa objek JSON yang valid. Contoh berikut menunjukkan kebijakan jaringan dan log kebijakan jaringan diaktifkan, dan log kebijakan jaringan dikirim ke CloudWatch Log:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true"
}
}
```
Screenshot berikut menunjukkan contoh skenario ini.
![\[menampilkan add-on VPC CNI dengan kebijakan jaringan dan CloudWatch Log dalam konfigurasi opsional.\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/console-cni-config-network-policy-logs.png)
AWS CLI
1. Jalankan perintah AWS CLI berikut. Ganti `my-cluster` dengan nama cluster Anda dan ganti peran IAM ARN dengan peran yang Anda gunakan.
```
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"}}'
```
### Add-on yang dikelola sendiri
Helm
Jika Anda telah menginstal plugin Amazon VPC CNI untuk Kubernetes`helm`, Anda dapat memperbarui konfigurasi untuk menulis log kebijakan jaringan.
1. Jalankan perintah berikut untuk mengaktifkan kebijakan jaringan.
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
kubectl
Jika Anda telah menginstal plugin Amazon VPC CNI untuk Kubernetes`kubectl`, Anda dapat memperbarui konfigurasi untuk menulis log kebijakan jaringan.
1. Buka `aws-node` `DaemonSet` di editor Anda.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Ganti `false` dengan `true` dalam argumen perintah `--enable-policy-event-logs=false` di dalam `aws-network-policy-agent` wadah `args:` dalam manifes VPC `aws-node` `DaemonSet` CNI.
```
- args:
- --enable-policy-event-logs=true
```
### Kirim log kebijakan jaringan ke Amazon CloudWatch Logs
Anda dapat memantau log kebijakan jaringan menggunakan layanan seperti Amazon CloudWatch Logs. Anda dapat menggunakan metode berikut untuk mengirim log kebijakan jaringan ke CloudWatch Log.
Untuk kluster EKS, log kebijakan akan ditempatkan di bawah `/aws/eks/cluster-name/cluster/` dan untuk klaster K8S yang dikelola sendiri, log akan ditempatkan di bawah. `/aws/k8s-cluster/cluster/`
#### Kirim log kebijakan jaringan dengan plugin Amazon VPC CNI untuk Kubernetes
Jika Anda mengaktifkan kebijakan jaringan, kontainer kedua akan ditambahkan ke `aws-node` pod untuk *agen node*. Agen node ini dapat mengirim log kebijakan jaringan ke CloudWatch Log.
**catatan**
Hanya log kebijakan jaringan yang dikirim oleh agen node. Log lain yang dibuat oleh VPC CNI tidak disertakan.
##### Prasyarat
+ Tambahkan izin berikut sebagai bait atau kebijakan terpisah ke peran IAM yang Anda gunakan untuk CNI VPC.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
##### Pengaya Amazon EKS
** Konsol Manajemen AWS **
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi kiri, pilih **Cluster**, lalu pilih nama cluster yang ingin Anda konfigurasikan untuk add-on Amazon VPC CNI.
1. Pilih tab **Add-ons**.
1. Pilih kotak di kanan atas kotak add-on dan kemudian pilih **Edit**.
1. Pada *Amazon VPC CNI* halaman **Konfigurasi**:
1. Pilih versi `v1.14.0-eksbuild.3` atau yang lebih baru dalam daftar dropdown **Versi**.
1. Perluas **pengaturan konfigurasi opsional**.
1. Masukkan kunci JSON tingkat atas `"nodeAgent":` dan nilai adalah objek dengan kunci `"enableCloudWatchLogs":` dan nilai `"true"` dalam nilai **Konfigurasi**. Teks yang dihasilkan harus berupa objek JSON yang valid. Contoh berikut menunjukkan kebijakan jaringan dan log kebijakan jaringan diaktifkan, dan log dikirim ke CloudWatch Log:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true",
"enableCloudWatchLogs": "true",
}
}
```
Screenshot berikut menunjukkan contoh skenario ini.
![\[menampilkan add-on VPC CNI dengan kebijakan jaringan dan CloudWatch Log dalam konfigurasi opsional.\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png)
** AWS CLI**
1. Jalankan perintah AWS CLI berikut. Ganti `my-cluster` dengan nama cluster Anda dan ganti peran IAM ARN dengan peran yang Anda gunakan.
```
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"}}'
```
##### Add-on yang dikelola sendiri
**Helm**
Jika Anda telah menginstal plugin Amazon VPC CNI untuk Kubernetes`helm`, Anda dapat memperbarui konfigurasi untuk mengirim log kebijakan jaringan ke Log. CloudWatch
1. Jalankan perintah berikut untuk mengaktifkan log kebijakan jaringan dan mengirimkannya ke CloudWatch Log.
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
**kubectl**
1. Buka `aws-node` `DaemonSet` di editor Anda.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Ganti `false` dengan `true` dalam dua argumen perintah `--enable-policy-event-logs=false` dan `--enable-cloudwatch-logs=false` di dalam `aws-network-policy-agent` wadah `args:` di manifes VPC `aws-node` `DaemonSet` CNI.
```
- args:
- --enable-policy-event-logs=true
- --enable-cloudwatch-logs=true
```
#### Kirim log kebijakan jaringan dengan Fluent Bit `DaemonSet`
Jika Anda menggunakan Fluent Bit dalam a `DaemonSet` untuk mengirim log dari node Anda, Anda dapat menambahkan konfigurasi untuk menyertakan log kebijakan jaringan dari kebijakan jaringan. Anda dapat menggunakan konfigurasi contoh berikut:
```
[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
```
## Termasuk eBPF SDK
Plugin Amazon VPC CNI untuk Kubernetes menginstal koleksi alat eBPF SDK pada node. Anda dapat menggunakan alat SDK eBPF untuk mengidentifikasi masalah dengan kebijakan jaringan. Misalnya, perintah berikut mencantumkan program yang berjalan pada node.
```
sudo /opt/cni/bin/aws-eks-na-cli ebpf progs
```
Untuk menjalankan perintah ini, Anda dapat menggunakan metode apa pun untuk terhubung ke node.
## Masalah dan solusi yang diketahui
Bagian berikut menjelaskan masalah yang diketahui dengan fitur kebijakan jaringan Amazon VPC CNI dan solusinya.
### Log kebijakan jaringan yang dihasilkan meskipun enable-policy-event-logs disetel ke false
**Masalah**: EKS VPC CNI menghasilkan log kebijakan jaringan bahkan ketika `enable-policy-event-logs` pengaturan disetel ke. `false`
**Solusi**: `enable-policy-event-logs` Pengaturan hanya menonaktifkan log “keputusan” kebijakan, tetapi tidak akan menonaktifkan semua pencatatan agen Kebijakan Jaringan. Perilaku ini didokumentasikan dalam [aws-network-policy-agent README](https://github.com/aws/aws-network-policy-agent/) pada GitHub. Untuk sepenuhnya menonaktifkan logging, Anda mungkin perlu menyesuaikan konfigurasi logging lainnya.
### Masalah pembersihan peta kebijakan jaringan
**Masalah**: Masalah dengan jaringan `policyendpoint` masih ada dan tidak dibersihkan setelah pod dihapus.
**Solusi**: Masalah ini disebabkan oleh masalah dengan add-on VPC CNI versi 1.19.3-eksbuild.1. Perbarui ke versi yang lebih baru dari add-on VPC CNI untuk mengatasi masalah ini.
### Kebijakan jaringan tidak diterapkan
**Masalah**: Fitur kebijakan jaringan diaktifkan di plugin Amazon VPC CNI, tetapi kebijakan jaringan tidak diterapkan dengan benar.
Jika Anda membuat kebijakan jaringan `kind: NetworkPolicy` dan tidak mempengaruhi pod, periksa apakah objek policyendpoint dibuat di namespace yang sama dengan pod. Jika tidak ada `policyendpoint` objek di ruang nama, pengontrol kebijakan jaringan (bagian dari kluster EKS) tidak dapat membuat aturan kebijakan jaringan untuk diterapkan oleh agen kebijakan jaringan (bagian dari CNI VPC).
**Solusi**: Solusinya adalah memperbaiki izin VPC CNI `ClusterRole` (`aws-node`:) dan pengontrol `ClusterRole` kebijakan jaringan (:) dan mengizinkan tindakan ini di alat penegakan kebijakan apa pun seperti Kyverno. `eks:network-policy-controller` Pastikan bahwa kebijakan Kyverno tidak menghalangi pembuatan objek. `policyendpoint` Lihat bagian sebelumnya untuk izin izin yang diperlukan di. [`policyendpoints`CRD dan izin baru](#network-policies-troubleshooting-permissions)
### Pod tidak kembali ke status penolakan default setelah penghapusan kebijakan dalam mode ketat
**Masalah**: Saat kebijakan jaringan diaktifkan dalam mode ketat, pod dimulai dengan kebijakan penolakan default. Setelah kebijakan diterapkan, lalu lintas diizinkan ke titik akhir yang ditentukan. Namun, ketika kebijakan dihapus, pod tidak kembali ke status penolakan default dan sebaliknya pergi ke status izinkan default.
**Solusi**: Masalah ini telah diperbaiki dalam rilis VPC CNI 1.19.3, yang mencakup rilis agen kebijakan jaringan 1.2.0. Setelah perbaikan, dengan mode ketat diaktifkan, setelah kebijakan dihapus, pod akan kembali ke status penolakan default seperti yang diharapkan.
### Grup Keamanan untuk latensi startup Pod
**Masalah**: Saat menggunakan fitur Grup Keamanan untuk Pod di EKS, ada peningkatan latensi startup pod.
**Solusi**: Latensi disebabkan oleh pembatasan laju pada pengontrol sumber daya dari pembatasan API pada `CreateNetworkInterface` API, yang digunakan oleh pengontrol sumber daya VPC untuk membuat cabang untuk pod. ENIs Periksa batas API akun Anda untuk operasi ini dan pertimbangkan untuk meminta peningkatan batas jika diperlukan.
### FailedScheduling karena vpc.amazonaws.com/pod-eni tidak mencukupi
**Masalah**: Pod gagal menjadwalkan dengan kesalahan: `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.`
**Solusi**: Seperti masalah sebelumnya, menetapkan Grup Keamanan ke pod meningkatkan latensi penjadwalan pod dan dapat meningkat melampaui ambang batas CNI untuk waktu untuk menambahkan setiap ENI, menyebabkan kegagalan untuk memulai pod. Ini adalah perilaku yang diharapkan saat menggunakan Grup Keamanan untuk Pod. Pertimbangkan implikasi penjadwalan saat merancang arsitektur beban kerja Anda.
### Masalah konektivitas IPAM dan kesalahan segmentasi
**Masalah**: Beberapa kesalahan terjadi termasuk masalah konektivitas IPAM, permintaan pembatasan, dan kesalahan segmentasi:
+ `Checking for IPAM connectivity …`
+ `Throttling request took 1.047064274s`
+ `Retrying waiting for IPAM-D`
+ `panic: runtime error: invalid memory address or nil pointer dereference`
**Solusi**: Masalah ini terjadi jika Anda menginstal `systemd-udev` pada AL2 023, karena file ditulis ulang dengan kebijakan yang melanggar. Ini dapat terjadi ketika memperbarui ke yang berbeda `releasever` yang memiliki paket yang diperbarui atau memperbarui paket itu sendiri secara manual. Hindari menginstal atau memperbarui `systemd-udev` pada AL2 023 node.
### Gagal menemukan kesalahan nama perangkat
**Masalah**: Pesan kesalahan: `{"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})"}`
**Solusi**: Masalah ini telah diidentifikasi dan diperbaiki di versi terbaru agen kebijakan jaringan Amazon VPC CNI (v1.2.0). Perbarui ke versi terbaru dari VPC CNI untuk mengatasi masalah ini.
### Kerentanan CVE dalam gambar Multus CNI
**Masalah**: Laporan EKS ImageScan CVE yang Ditingkatkan mengidentifikasi kerentanan dalam versi gambar Multus CNI v4.1.4-eksbuild.2\$1thick.
**Solusi**: Perbarui ke versi baru gambar Multus CNI dan gambar Network Policy Controller baru, yang tidak memiliki kerentanan. Pemindai dapat diperbarui untuk mengatasi kerentanan yang ditemukan di versi sebelumnya.
### Info Alur MENOLAK putusan di log
**Masalah**: Log kebijakan jaringan menunjukkan putusan 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"}`
**Solusi**: Masalah ini telah diselesaikan dalam versi baru dari Network Policy Controller. Perbarui ke versi platform EKS terbaru untuk menyelesaikan masalah logging.
### Pod-to-pod masalah komunikasi setelah bermigrasi dari Calico
**Masalah**: Setelah memutakhirkan kluster EKS ke versi 1.30 dan beralih dari Calico ke Amazon VPC CNI untuk kebijakan jaringan, pod-to-pod komunikasi gagal saat kebijakan jaringan diterapkan. Komunikasi dipulihkan ketika kebijakan jaringan dihapus.
**Solusi**: Agen kebijakan jaringan di VPC CNI tidak dapat memiliki banyak port yang ditentukan seperti yang dilakukan Calico. Sebagai gantinya, gunakan rentang port dalam kebijakan jaringan. Jumlah maksimum kombinasi unik port untuk setiap protokol di masing-masing `ingress:` atau `egress:` pemilih dalam kebijakan jaringan adalah 24. Gunakan rentang port untuk mengurangi jumlah port unik dan hindari batasan ini.
### Agen kebijakan jaringan tidak mendukung pod mandiri
**Masalah**: Kebijakan jaringan yang diterapkan pada pod mandiri mungkin memiliki perilaku yang tidak konsisten.
**Solusi**: Agen Kebijakan Jaringan saat ini hanya mendukung pod yang di-deploy sebagai bagian dari deployment/replicaset. Jika kebijakan jaringan diterapkan ke pod mandiri, mungkin ada beberapa ketidakkonsistenan dalam perilaku tersebut. Ini didokumentasikan di bagian atas halaman ini, di[Pertimbangan-pertimbangan](cni-network-policy.md#cni-network-policy-considerations), dan di [aws-network-policy-agent GitHub edisi \$1327](https://github.com/aws/aws-network-policy-agent/issues/327) di GitHub. Menerapkan pod sebagai bagian dari penerapan atau replika untuk perilaku kebijakan jaringan yang konsisten.