**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.
# Pelajari tentang mode dan konfigurasi VPC CNI
Plugin Amazon VPC CNI untuk Kubernetes menyediakan jaringan untuk Pod. Gunakan tabel berikut untuk mempelajari lebih lanjut tentang fitur jaringan yang tersedia.
| Fitur jaringan | Pelajari selengkapnya |
| --- | --- |
| Konfigurasikan klaster Anda untuk menetapkan IPv6 alamat ke cluster, Pod, dan layanan | [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md) |
| Menggunakan Terjemahan Alamat Jaringan IPv4 Sumber untuk Pod | [Aktifkan akses internet keluar untuk Pod](external-snat.md) |
| Membatasi lalu lintas jaringan ke dan dari Pod | [Batasi lalu lintas jaringan Pod dengan kebijakan jaringan Kubernetes](cni-network-policy-configure.md) |
| Sesuaikan antarmuka jaringan sekunder di node | [Menerapkan Pod di subnet alternatif dengan jaringan khusus](cni-custom-network.md) |
| Tingkatkan alamat IP untuk node Anda | [Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md) |
| Menggunakan grup keamanan untuk lalu lintas jaringan Pod | [Menetapkan grup keamanan ke Pod individual](security-groups-for-pods.md) |
| Menggunakan beberapa antarmuka jaringan untuk Pod | [Lampirkan beberapa antarmuka jaringan ke Pod](pod-multiple-network-interfaces.md) |
# Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan
**Berlaku untuk**: Pod dengan EC2 instans Amazon dan Pod Fargate
Secara default, Kubernetes memberikan `IPv4` alamat ke Pod dan layanan Anda. Alih-alih menetapkan `IPv4` alamat ke Pod dan layanan Anda, Anda dapat mengonfigurasi klaster untuk menetapkan `IPv6` alamat ke Pod dan layanan Anda. Amazon EKS tidak mendukung Pod atau layanan bertumpuk ganda, meskipun Kubernetes melakukannya. Akibatnya, Anda tidak dapat menetapkan keduanya `IPv4` dan `IPv6` alamat ke Pod dan layanan Anda.
Anda memilih keluarga IP mana yang ingin Anda gunakan untuk cluster Anda saat Anda membuatnya. Anda tidak dapat mengubah keluarga setelah membuat cluster.
Untuk tutorial menerapkan `IPv6` kluster Amazon EKS, lihat[Menyebarkan `IPv6` kluster Amazon EKS dan mengelola node Amazon Linux](deploy-ipv6-cluster.md).
Berikut ini adalah pertimbangan untuk menggunakan fitur ini:
## `IPv6`Dukungan fitur
+ **Tidak ada dukungan Windows**: Pod dan layanan Windows tidak didukung.
+ **Diperlukan EC2 node berbasis Nitro**: Anda hanya dapat menggunakan `IPv6` dengan node AWS Amazon atau EC2 Fargate berbasis Nitro.
+ **EC2 dan node Fargate didukung**: Anda dapat menggunakan `IPv6` dengan dengan EC2 node [Menetapkan grup keamanan ke Pod individual](security-groups-for-pods.md) Amazon dan node Fargate.
+ **Outposts tidak didukung**: Anda tidak dapat menggunakan `IPv6` dengan. [Menerapkan Amazon EKS lokal dengan Outposts AWS](eks-outposts.md)
+ **FSx untuk Lustre tidak didukung**: Tidak [Gunakan penyimpanan aplikasi berkinerja tinggi dengan Amazon FSx untuk Lustre](fsx-csi.md) didukung.
+ **Jaringan khusus tidak didukung**: Jika sebelumnya Anda digunakan [Menerapkan Pod di subnet alternatif dengan jaringan khusus](cni-custom-network.md) untuk membantu mengurangi kelelahan alamat IP, Anda dapat menggunakannya sebagai gantinya. `IPv6` Anda tidak dapat menggunakan jaringan khusus dengan`IPv6`. Jika Anda menggunakan jaringan khusus untuk isolasi jaringan, maka Anda mungkin perlu terus menggunakan jaringan khusus dan `IPv4` keluarga untuk cluster Anda.
## Penugasan alamat IP
+ Layanan **Kubernetes: Layanan** Kubernetes hanya diberi alamat. `IPv6` Mereka tidak diberi IPv4 alamat.
+ **Pod**: Pod diberi IPv6 alamat dan alamat host-lokal IPv4 . IPv4 Alamat host-lokal ditetapkan dengan menggunakan plugin CNI host-lokal yang dirantai dengan VPC CNI dan alamatnya tidak dilaporkan ke bidang kontrol Kubernetes. Ini hanya digunakan ketika pod perlu berkomunikasi dengan IPv4 sumber daya eksternal di VPC Amazon lain atau internet. IPv4 Alamat host-lokal mendapat SNATed (oleh VPC CNI) ke IPv4 alamat utama ENI primer dari node pekerja.
+ **Pod dan layanan**: Pod dan layanan hanya menerima `IPv6` alamat, bukan `IPv4` alamat. Ketika Pod perlu berkomunikasi dengan `IPv4` endpoint eksternal, mereka menggunakan NAT pada node itu sendiri. Kemampuan NAT bawaan ini menghilangkan kebutuhan untuk [DNS64 dan NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-nat64-dns64). Untuk lalu lintas yang membutuhkan akses internet publik, lalu lintas Pod adalah alamat jaringan sumber yang diterjemahkan ke alamat IP publik.
+ **Alamat perutean**: Ketika sebuah Pod berkomunikasi di luar VPC, `IPv6` alamat aslinya dipertahankan (tidak diterjemahkan ke alamat node). `IPv6` Lalu lintas ini diarahkan langsung melalui gateway internet atau gateway internet khusus egres.
+ **Node**: Semua node diberi `IPv6` alamat `IPv4` dan.
+ **Pod Fargate**: Setiap Pod Fargate menerima `IPv6` alamat dari CIDR yang ditentukan untuk subnet yang digunakan. Unit perangkat keras dasar yang menjalankan Fargate Pods mendapatkan `IPv6` alamat unik `IPv4` dan dari CIDRs yang ditetapkan ke subnet tempat unit perangkat keras digunakan.
## Cara menggunakan `IPv6` EKS
+ **Buat cluster baru**: Anda harus membuat cluster baru dan menentukan bahwa Anda ingin menggunakan `IPv6` keluarga untuk cluster itu. Anda tidak dapat mengaktifkan `IPv6` keluarga untuk klaster yang Anda perbarui dari versi sebelumnya. Untuk petunjuk tentang cara membuat klaster baru, lihat Pertimbangan.
+ **Gunakan VPC CNI terbaru: Terapkan versi Amazon VPC CNI** atau yang lebih baru. `1.10.1` Versi ini atau yang lebih baru digunakan secara default. Setelah menerapkan add-on, Anda tidak dapat menurunkan versi add-on Amazon VPC CNI ke versi yang lebih rendah daripada `1.10.1` tanpa terlebih dahulu menghapus semua node di semua grup node di cluster Anda.
+ **Konfigurasikan CNI VPC untuk `IPv6`**: Jika Anda menggunakan EC2 node Amazon, Anda harus mengonfigurasi add-on Amazon VPC CNI dengan delegasi awalan IP dan. `IPv6` Jika Anda memilih `IPv6` keluarga saat membuat cluster Anda, `1.10.1` versi add-on default ke konfigurasi ini. Ini adalah kasus untuk add-on Amazon EKS yang dikelola sendiri atau Amazon. Untuk informasi selengkapnya tentang delegasi awalan IP, lihat. [Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md)
+ **Konfigurasi `IPv4` dan `IPv6` alamat**: Saat Anda membuat cluster, VPC dan subnet yang Anda tentukan harus memiliki blok `IPv6` CIDR yang ditetapkan ke VPC dan subnet yang Anda tentukan. Mereka juga harus memiliki blok `IPv4` CIDR yang ditugaskan untuk mereka. Ini karena, meskipun Anda hanya ingin menggunakan`IPv6`, VPC masih memerlukan blok `IPv4` CIDR untuk berfungsi. Untuk informasi selengkapnya, lihat [Mengaitkan blok IPv6 CIDR dengan VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr) di Panduan Pengguna Amazon VPC.
+ **Tetapkan IPv6 alamat otomatis ke node:** Saat Anda membuat node, Anda harus menentukan subnet yang dikonfigurasi untuk menetapkan alamat secara otomatis. `IPv6` Jika tidak, Anda tidak dapat menyebarkan node Anda. Secara default, konfigurasi ini dinonaktifkan. Untuk informasi selengkapnya, lihat [Memodifikasi atribut IPv6 pengalamatan untuk subnet Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) di Panduan Pengguna Amazon VPC.
+ **Atur tabel rute yang akan digunakan `IPv6`**: Tabel rute yang ditetapkan ke subnet Anda harus memiliki rute untuk `IPv6` alamat. Untuk informasi selengkapnya, lihat [Memigrasi ke IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) dalam Panduan Pengguna Amazon VPC.
+ **Tetapkan grup keamanan untuk `IPv6`**: Grup keamanan Anda harus mengizinkan `IPv6` alamat. Untuk informasi selengkapnya, lihat [Memigrasi ke IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) dalam Panduan Pengguna Amazon VPC.
+ **Mengatur load balancer**: Gunakan versi `2.3.1` atau yang lebih baru dari AWS Load Balancer Controller untuk memuat keseimbangan aplikasi HTTP menggunakan [Rute aplikasi dan lalu lintas HTTP dengan Application Load Balancers](alb-ingress.md) [Rute lalu lintas TCP dan UDP dengan Network Load Balancers](network-load-balancing.md) lalu lintas jaringan atau `IPv6` ke Pod dengan penyeimbang beban dalam mode IP, tetapi bukan mode instance. Untuk informasi selengkapnya, lihat [Rute lalu lintas internet dengan AWS Load Balancer Controller](aws-load-balancer-controller.md).
+ **Tambahkan kebijakan `IPv6` IAM**: Anda harus melampirkan kebijakan `IPv6` IAM ke node IAM atau peran IAM CNI Anda. Di antara keduanya, kami sarankan Anda melampirkannya ke peran IAM CNI. Untuk informasi selengkapnya, lihat [Buat kebijakan IAM untuk cluster yang menggunakan keluarga `IPv6`](cni-iam-role.md#cni-iam-role-create-ipv6-policy) dan [Langkah 1: Buat plugin Amazon VPC CNI untuk peran IAM Kubernetes](cni-iam-role.md#cni-iam-role-create-role).
+ **Evaluasi semua komponen**: Lakukan evaluasi menyeluruh terhadap aplikasi, add-on Amazon EKS, dan AWS layanan yang Anda integrasikan sebelum menerapkan cluster`IPv6`. Ini untuk memastikan bahwa semuanya berfungsi seperti yang diharapkan`IPv6`.
# Menyebarkan `IPv6` kluster Amazon EKS dan mengelola node Amazon Linux
Dalam tutorial ini, Anda menerapkan VPC `IPv6` Amazon, cluster Amazon EKS bersama keluarga, dan `IPv6` grup node terkelola dengan node Amazon EC2 Amazon Linux. Anda tidak dapat menyebarkan node Amazon EC2 Windows dalam sebuah `IPv6` cluster. Anda juga dapat menerapkan node Fargate ke cluster Anda, meskipun instruksi tersebut tidak disediakan dalam topik ini untuk kesederhanaan.
## Prasyarat
Selesaikan yang berikut ini sebelum Anda memulai tutorial:
Instal dan konfigurasikan alat dan sumber daya berikut yang Anda perlukan untuk membuat dan mengelola klaster Amazon EKS.
+ Kami menyarankan Anda membiasakan diri dengan semua pengaturan dan menyebarkan cluster dengan pengaturan yang memenuhi kebutuhan Anda. Untuk informasi lebih lanjut, lihat [Buat kluster Amazon EKS](create-cluster.md)[Sederhanakan siklus hidup node dengan grup node terkelola](managed-node-groups.md),, dan [Pertimbangan](cni-ipv6.md) untuk topik ini. Anda hanya dapat mengaktifkan beberapa pengaturan saat membuat cluster Anda.
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Versinya bisa sama dengan atau hingga satu versi minor lebih awal atau lebih lambat dari versi Kubernetes dari klaster Anda. Misalnya, jika versi cluster Anda`1.29`, Anda dapat menggunakan `kubectl` versi`1.28`,`1.29`, atau `1.30` dengan itu. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ Prinsip keamanan IAM yang Anda gunakan harus memiliki izin untuk bekerja dengan peran Amazon EKS IAM, peran terkait layanan,, VPC, AWS CloudFormation dan sumber daya terkait. Untuk informasi selengkapnya, lihat [Tindakan](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) dan [Menggunakan peran terkait layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) di Panduan Pengguna IAM.
+ Jika Anda menggunakan eksctl, instal versi `0.215.0` atau yang lebih baru di komputer Anda. Untuk menginstal atau memperbaruinya, lihat [Instalasi](https://eksctl.io/installation) di `eksctl` dokumentasi.
+ Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Versi AWS CLI yang diinstal AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di * AWS CloudShell Panduan Pengguna*. Jika Anda menggunakan AWS CloudShell, Anda mungkin perlu [menginstal versi 2.12.3 atau yang lebih baru atau 1.27.160 atau yang lebih baru dari CLI AWS , karena versi AWS CLI](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) default yang diinstal di mungkin versi sebelumnya. AWS CloudShell
Anda dapat menggunakan eksctl atau CLI untuk menyebarkan cluster. `IPv6`
## Menyebarkan IPv6 cluster dengan eksctl
1. Buat file `ipv6-cluster.yaml`. Salin perintah yang mengikuti ke perangkat Anda. Buat modifikasi berikut pada perintah sesuai kebutuhan dan kemudian jalankan perintah yang dimodifikasi:
+ Ganti *my-cluster* dengan nama untuk cluster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil) dan tanda hubung. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat cluster.
+ Ganti *region-code* dengan AWS Wilayah apa pun yang didukung oleh Amazon EKS. Untuk daftar AWS Wilayah, lihat [titik akhir dan kuota Amazon EKS di panduan](https://docs.aws.amazon.com/general/latest/gr/eks.html) Referensi AWS Umum.
+ Nilai untuk `version` dengan versi cluster Anda. Untuk informasi selengkapnya, lihat [versi yang didukung Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Ganti *my-nodegroup* dengan nama untuk grup node Anda. Nama grup node tidak boleh lebih dari 63 karakter. Itu harus dimulai dengan huruf atau digit, tetapi juga dapat menyertakan tanda hubung dan garis bawah untuk karakter yang tersisa.
+ Ganti *t3.medium* dengan [jenis instans Sistem AWS Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) apa pun.
```
cat >ipv6-cluster.yaml <
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Konfirmasikan bahwa layanan default adalah `IPv6` alamat yang ditetapkan.
```
kubectl get services -n kube-system -o wide
```
Contoh output adalah sebagai berikut.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Opsional) [Menerapkan aplikasi sampel](sample-deployment.md) atau menerapkan [Load AWS Balancer](aws-load-balancer-controller.md) Controller dan aplikasi sampel untuk memuat aplikasi HTTP [Rute aplikasi dan lalu lintas HTTP dengan Application Load Balancers](alb-ingress.md) dengan atau lalu lintas [Rute lalu lintas TCP dan UDP dengan Network Load Balancers](network-load-balancing.md) jaringan dengan Pod. `IPv6`
1. Setelah Anda selesai dengan cluster dan node yang Anda buat untuk tutorial ini, Anda harus membersihkan sumber daya yang Anda buat dengan perintah berikut.
```
eksctl delete cluster my-cluster
```
## Menerapkan IPv6 cluster dengan CLI AWS
**penting**
Anda harus menyelesaikan semua langkah dalam prosedur ini sebagai pengguna yang sama. Untuk memeriksa pengguna saat ini, jalankan perintah berikut:
```
aws sts get-caller-identity
```
Anda harus menyelesaikan semua langkah dalam prosedur ini di shell yang sama. Beberapa langkah menggunakan variabel yang diatur dalam langkah sebelumnya. Langkah-langkah yang menggunakan variabel tidak akan berfungsi dengan baik jika nilai variabel diatur dalam shell yang berbeda. Jika Anda menggunakan [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)untuk menyelesaikan prosedur berikut, ingatlah bahwa jika Anda tidak berinteraksi dengannya menggunakan keyboard atau pointer selama kurang lebih 20-30 menit, sesi shell Anda berakhir. Proses yang berjalan tidak dihitung sebagai interaksi.
Instruksi ditulis untuk cangkang Bash, dan mungkin perlu disesuaikan dengan cangkang lainnya.
Ganti semua nilai contoh dalam langkah-langkah prosedur ini dengan nilai Anda sendiri.
1. Jalankan perintah berikut untuk mengatur beberapa variabel yang digunakan dalam langkah-langkah selanjutnya. Ganti *region-code* dengan AWS Wilayah tempat Anda ingin menyebarkan sumber daya Anda. Nilainya dapat berupa AWS Wilayah apa pun yang didukung oleh Amazon EKS. Untuk daftar AWS Wilayah, lihat [titik akhir dan kuota Amazon EKS di panduan](https://docs.aws.amazon.com/general/latest/gr/eks.html) Referensi AWS Umum. Ganti *my-cluster* dengan nama untuk cluster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil) dan tanda hubung. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat cluster. Ganti *my-nodegroup* dengan nama untuk grup node Anda. Nama grup node tidak boleh lebih dari 63 karakter. Itu harus dimulai dengan huruf atau digit, tetapi juga dapat menyertakan tanda hubung dan garis bawah untuk karakter yang tersisa. Ganti *111122223333* dengan ID akun Anda.
```
export region_code=region-code
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
```
1. Buat VPC Amazon dengan subnet publik dan pribadi yang memenuhi Amazon EKS dan persyaratan. `IPv6`
1. Jalankan perintah berikut untuk mengatur variabel untuk nama AWS CloudFormation tumpukan Anda. Anda dapat mengganti *my-eks-ipv6-vpc* dengan nama apa pun yang Anda pilih.
```
export vpc_stack_name=my-eks-ipv6-vpc
```
1. Buat `IPv6` VPC menggunakan template. AWS CloudFormation
```
aws cloudformation create-stack --region $region_code --stack-name $vpc_stack_name \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-ipv6-vpc-public-private-subnets.yaml
```
Tumpukan membutuhkan waktu beberapa menit untuk membuatnya. Jalankan perintah berikut. Jangan melanjutkan ke langkah berikutnya sampai output dari perintah tersebut`CREATE_COMPLETE`.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name --query Stacks[].StackStatus --output text
```
1. Ambil subnet publik yang dibuat. IDs
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text
```
Contoh output adalah sebagai berikut.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE
```
1. Aktifkan opsi `IPv6` alamat tetapkan otomatis untuk subnet publik yang dibuat.
```
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-0a1a56c486EXAMPLE --assign-ipv6-address-on-creation
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-099e6ca77aEXAMPLE --assign-ipv6-address-on-creation
```
1. Ambil nama subnet dan grup keamanan yang dibuat oleh template dari AWS CloudFormation tumpukan yang digunakan dan simpan dalam variabel untuk digunakan di langkah selanjutnya.
```
security_groups=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SecurityGroups`].OutputValue' --output text)
public_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text)
private_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPrivate`].OutputValue' --output text)
subnets=${public_subnets},${private_subnets}
```
1. Membuat IAM role klaster dan lampirkan kebijakan terkelola Amazon EKS IAM ke dalam peran itu. Cluster Kubernetes yang dikelola oleh Amazon EKS melakukan panggilan ke AWS layanan lain atas nama Anda untuk mengelola sumber daya yang Anda gunakan dengan layanan.
1. Jalankan perintah berikut untuk membuat `eks-cluster-role-trust-policy.json` file.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Jalankan perintah berikut untuk menetapkan variabel untuk nama peran Anda. Anda dapat mengganti *myAmazonEKSClusterRole* dengan nama apa pun yang Anda pilih.
```
export cluster_role_name=myAmazonEKSClusterRole
```
1. Buat peran.
```
aws iam create-role --role-name $cluster_role_name --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Ambil ARN dari peran IAM dan simpan dalam variabel untuk langkah selanjutnya.
```
CLUSTER_IAM_ROLE=$(aws iam get-role --role-name $cluster_role_name --query="Role.Arn" --output text)
```
1. Lampirkan kebijakan terkelola IAM Amazon EKS yang diperlukan untuk peran tersebut.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name $cluster_role_name
```
1. Buat cluster Anda.
```
aws eks create-cluster --region $region_code --name $cluster_name --kubernetes-version 1.XX \
--role-arn $CLUSTER_IAM_ROLE --resources-vpc-config subnetIds=$subnets,securityGroupIds=$security_groups \
--kubernetes-network-config ipFamily=ipv6
```
1. CATATAN: Anda mungkin menerima kesalahan bahwa salah satu Availability Zone dalam permintaan Anda tidak memiliki kapasitas yang cukup untuk membuat klaster Amazon EKS. Jika hal ini terjadi, output galat berisi Availability Zones yang dapat mendukung klaster baru. Cobalah untuk kembali membuat klaster dengan setidaknya dua subnet yang terletak di Availability Zones yang didukung untuk akun Anda. Untuk informasi selengkapnya, lihat [Kapasitas tidak mencukupi](troubleshooting.md#ice).
Cluster membutuhkan beberapa menit untuk membuatnya. Jalankan perintah berikut. Jangan melanjutkan ke langkah berikutnya sampai output dari perintah`ACTIVE`.
```
aws eks describe-cluster --region $region_code --name $cluster_name --query cluster.status
```
1. Buat atau perbarui `kubeconfig` file untuk cluster Anda sehingga Anda dapat berkomunikasi dengan cluster Anda.
```
aws eks update-kubeconfig --region $region_code --name $cluster_name
```
Secara default, `config` file dibuat `~/.kube` atau konfigurasi cluster baru ditambahkan ke `config` file yang ada di`~/.kube`.
1. Buat peran IAM node.
1. Jalankan perintah berikut untuk membuat `vpc-cni-ipv6-policy.json` file.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Buat kebijakan IAM.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Jalankan perintah berikut untuk membuat `node-role-trust-relationship.json` file.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Jalankan perintah berikut untuk menetapkan variabel untuk nama peran Anda. Anda dapat mengganti *AmazonEKSNodeRole* dengan nama apa pun yang Anda pilih.
```
export node_role_name=AmazonEKSNodeRole
```
1. Buat peran IAM.
```
aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Lampirkan kebijakan IAM ke peran IAM.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name $node_role_name
```
**penting**
Untuk kesederhanaan dalam tutorial ini, kebijakan dilampirkan ke peran IAM ini. Namun, dalam klaster produksi, kami merekomendasikan untuk melampirkan kebijakan ke peran IAM yang terpisah. Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).
1. Lampirkan dua kebijakan yang dikelola IAM yang diperlukan ke peran IAM.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name $node_role_name
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name $node_role_name
```
1. Ambil ARN dari peran IAM dan simpan dalam variabel untuk langkah selanjutnya.
```
node_iam_role=$(aws iam get-role --role-name $node_role_name --query="Role.Arn" --output text)
```
1. Buat grup node terkelola.
1. Lihat subnet yang Anda buat pada langkah sebelumnya. IDs
```
echo $subnets
```
Contoh output adalah sebagai berikut.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE,subnet-0377963d69EXAMPLE,subnet-0c05f819d5EXAMPLE
```
1. Buat grup node. Ganti *0a1a56c486EXAMPLE**099e6ca77aEXAMPLE*,*0377963d69EXAMPLE*,, dan *0c05f819d5EXAMPLE* dengan nilai yang dikembalikan dalam output dari langkah sebelumnya. Pastikan untuk menghapus koma antara subnet IDs dari output sebelumnya dalam perintah berikut. Anda dapat mengganti *t3.medium* dengan [jenis instans Sistem AWS Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) apa pun.
```
aws eks create-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--subnets subnet-0a1a56c486EXAMPLE subnet-099e6ca77aEXAMPLE subnet-0377963d69EXAMPLE subnet-0c05f819d5EXAMPLE \
--instance-types t3.medium --node-role $node_iam_role
```
Grup node membutuhkan waktu beberapa menit untuk membuatnya. Jalankan perintah berikut. Jangan lanjutkan ke langkah berikutnya sampai output yang dikembalikan`ACTIVE`.
```
aws eks describe-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--query nodegroup.status --output text
```
1. Konfirmasikan bahwa Pod default adalah `IPv6` alamat yang ditetapkan di `IP` kolom.
```
kubectl get pods -n kube-system -o wide
```
Contoh output adalah sebagai berikut.
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
aws-node-rslts 1/1 Running 1 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Konfirmasikan bahwa layanan default diberikan `IPv6` alamat di `IP` kolom.
```
kubectl get services -n kube-system -o wide
```
Contoh output adalah sebagai berikut.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Opsional) [Menerapkan aplikasi sampel](sample-deployment.md) atau menerapkan [Load AWS Balancer](aws-load-balancer-controller.md) Controller dan aplikasi sampel untuk memuat aplikasi HTTP [Rute aplikasi dan lalu lintas HTTP dengan Application Load Balancers](alb-ingress.md) dengan atau lalu lintas [Rute lalu lintas TCP dan UDP dengan Network Load Balancers](network-load-balancing.md) jaringan dengan Pod. `IPv6`
1. Setelah Anda selesai dengan cluster dan node yang Anda buat untuk tutorial ini, Anda harus membersihkan sumber daya yang Anda buat dengan perintah berikut. Pastikan Anda tidak menggunakan sumber daya apa pun di luar tutorial ini sebelum menghapusnya.
1. Jika Anda menyelesaikan langkah ini di shell yang berbeda dari saat Anda menyelesaikan langkah sebelumnya, tetapkan nilai semua variabel yang digunakan pada langkah sebelumnya, ganti nilai contoh dengan nilai yang Anda tentukan saat Anda menyelesaikan langkah sebelumnya. Jika Anda menyelesaikan langkah ini di shell yang sama dengan tempat Anda menyelesaikan langkah sebelumnya, lewati ke langkah berikutnya.
```
export region_code=region-code
export vpc_stack_name=my-eks-ipv6-vpc
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
export node_role_name=AmazonEKSNodeRole
export cluster_role_name=myAmazonEKSClusterRole
```
1. Hapus grup node Anda.
```
aws eks delete-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name
```
Penghapusan membutuhkan waktu beberapa menit. Jalankan perintah berikut. Jangan melanjutkan ke langkah berikutnya jika ada output yang dikembalikan.
```
aws eks list-nodegroups --region $region_code --cluster-name $cluster_name --query nodegroups --output text
```
1. Hapus klaster .
```
aws eks delete-cluster --region $region_code --name $cluster_name
```
Cluster membutuhkan beberapa menit untuk menghapus. Sebelum melanjutkan pastikan bahwa cluster dihapus dengan perintah berikut.
```
aws eks describe-cluster --region $region_code --name $cluster_name
```
Jangan melanjutkan ke langkah berikutnya sampai output Anda mirip dengan output berikut.
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.
```
1. Hapus sumber daya IAM yang Anda buat. Ganti *AmazonEKS\$1CNI\$1IPv6\$1Policy* dengan nama yang Anda pilih, jika Anda memilih nama yang berbeda dari yang digunakan pada langkah sebelumnya.
```
aws iam detach-role-policy --role-name $cluster_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-policy --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-role --role-name $cluster_role_name
aws iam delete-role --role-name $node_role_name
```
1. Hapus AWS CloudFormation tumpukan yang membuat VPC.
```
aws cloudformation delete-stack --region $region_code --stack-name $vpc_stack_name
```
# Aktifkan akses internet keluar untuk Pod
**Berlaku untuk**: Node `IPv4` Fargate Linux, node Linux dengan instans Amazon EC2
Jika Anda menerapkan klaster menggunakan `IPv6` keluarga, maka informasi dalam topik ini tidak berlaku untuk klaster Anda, karena `IPv6` alamat tidak diterjemahkan jaringan. Untuk informasi selengkapnya tentang penggunaan `IPv6` dengan cluster Anda, lihat[Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md).
Secara default, setiap Pod di klaster Anda diberi `IPv4` alamat [pribadi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) dari blok classless inter-domain routing (CIDR) yang terkait dengan VPC tempat Pod digunakan. Pod dalam VPC yang sama berkomunikasi satu sama lain menggunakan alamat IP pribadi ini sebagai titik akhir. [Ketika sebuah Pod berkomunikasi ke `IPv4` alamat apa pun yang tidak berada dalam blok CIDR yang terkait dengan VPC Anda, plugin Amazon VPC CNI (untuk [Linux](https://github.com/aws/amazon-vpc-cni-k8s#amazon-vpc-cni-k8s) atau [Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge)) menerjemahkan alamat Pod ke `IPv4` alamat pribadi utama dari elastic network interface primer dari node tempat `IPv4` Pod [berjalan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics), secara default\$1.](#snat-exception)
**catatan**
Untuk node Windows, ada detail tambahan yang perlu dipertimbangkan. Secara default, [plugin VPC CNI untuk Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge) didefinisikan dengan konfigurasi jaringan di mana lalu lintas ke tujuan dalam VPC yang sama dikecualikan untuk SNAT. Ini berarti bahwa komunikasi VPC internal telah dinonaktifkan SNAT dan alamat IP yang dialokasikan ke Pod dapat dirutekan di dalam VPC. Tetapi lalu lintas ke tujuan di luar VPC memiliki sumber IP Pod yang diambil ke alamat IP utama ENI instance. Konfigurasi default untuk Windows ini memastikan bahwa pod dapat mengakses jaringan di luar VPC Anda dengan cara yang sama seperti instance host.
Karena perilaku ini:
+ Pod Anda dapat berkomunikasi dengan sumber daya internet hanya jika node yang mereka jalankan memiliki alamat IP [publik](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) atau [elastis](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html) yang ditetapkan untuk itu dan berada dalam [subnet publik](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics). [Tabel rute](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) terkait subnet publik memiliki rute ke gateway internet. Kami merekomendasikan untuk menyebarkan node ke subnet pribadi, bila memungkinkan.
+ Untuk versi plugin sebelumnya`1.8.0`, sumber daya yang ada di jaringan atau VPCs yang terhubung ke VPC klaster Anda menggunakan [peering VPC, VPC transit[,](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html)](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) atau Direct [AWS Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) tidak dapat memulai komunikasi ke Pod Anda di belakang antarmuka jaringan elastis sekunder. Pod Anda dapat memulai komunikasi ke sumber daya tersebut dan menerima tanggapan darinya.
Jika salah satu dari pernyataan berikut benar di lingkungan Anda, maka ubah konfigurasi default dengan perintah berikut.
+ Anda memiliki sumber daya di jaringan atau VPCs yang terhubung ke VPC klaster Anda menggunakan VPC [peering, VPC transit[,](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html)](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) atau Direct [AWS Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) yang perlu memulai komunikasi dengan Pod Anda menggunakan `IPv4` alamat dan versi plugin Anda lebih awal dari itu. `1.8.0`
+ Pod Anda berada dalam [subnet pribadi](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics) dan perlu berkomunikasi keluar ke internet. Subnet memiliki rute ke gateway [NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
```
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
```
**catatan**
Variabel konfigurasi `AWS_VPC_K8S_CNI_EXTERNALSNAT` dan `AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS` CNI tidak berlaku untuk node Windows. Menonaktifkan SNAT tidak didukung untuk Windows. Adapun untuk mengecualikan daftar `IPv4` CIDRs dari SNAT, Anda dapat menentukan ini dengan menentukan `ExcludedSnatCIDRs` parameter dalam skrip bootstrap Windows. Untuk informasi selengkapnya tentang penggunaan parameter ini, lihat[Parameter konfigurasi skrip bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Jaringan host
\$1 Jika spesifikasi Pod berisi `hostNetwork=true` (default is`false`), maka alamat IP-nya tidak diterjemahkan ke alamat yang berbeda. Ini adalah kasus untuk plugin Amazon VPC CNI untuk Kubernetes Pods yang berjalan di klaster Anda, secara default. `kube-proxy` Untuk Pod ini, alamat IP sama dengan alamat IP utama node, sehingga alamat IP Pod tidak diterjemahkan. Untuk informasi selengkapnya tentang `hostNetwork` pengaturan Pod, lihat [inti PodSpec v1 di referensi](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) API Kubernetes.
# Batasi lalu lintas Pod dengan kebijakan jaringan Kubernetes
## Gambaran umum
Secara default, tidak ada batasan di Kubernetes untuk alamat IP, port, atau koneksi antara Pod apa pun di klaster Anda atau antara Pod Anda dan sumber daya di jaringan lain mana pun. Anda dapat menggunakan *kebijakan jaringan* Kubernetes untuk membatasi lalu lintas jaringan ke dan dari Pod Anda. Untuk informasi selengkapnya, lihat [Kebijakan Jaringan](https://kubernetes.io/docs/concepts/services-networking/network-policies/) dalam dokumentasi Kubernetes.
## Kebijakan jaringan standar
Anda dapat menggunakan standar `NetworkPolicy` untuk mengelompokkan pod-to-pod lalu lintas di cluster. Kebijakan jaringan ini beroperasi pada lapisan 3 dan 4 dari model jaringan OSI, memungkinkan Anda untuk mengontrol arus lalu lintas di alamat IP atau tingkat port dalam cluster Amazon EKS Anda. Kebijakan jaringan standar dicakup ke tingkat namespace.
### Kasus penggunaan
+ Segmentasikan lalu lintas jaringan antar beban kerja untuk memastikan bahwa hanya aplikasi terkait yang dapat berbicara satu sama lain.
+ Isolasi penyewa di tingkat namespace menggunakan kebijakan untuk menegakkan pemisahan jaringan.
### Contoh
Dalam kebijakan di bawah ini, lalu lintas keluar dari pod *webapp* di namespace *matahari dibatasi*.
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: webapp-egress-policy
namespace: sun
spec:
podSelector:
matchLabels:
role: webapp
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: moon
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
- to:
- namespaceSelector:
matchLabels:
name: stars
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
```
Kebijakan ini berlaku untuk pod dengan label `role: webapp` di `sun` namespace.
+ Lalu lintas yang diizinkan: Pod dengan label `role: frontend` di `moon` namespace pada port TCP `8080`
+ Lalu lintas yang diizinkan: Pod dengan peran label: frontend di `stars` namespace pada port TCP `8080`
+ Lalu lintas yang diblokir: Semua lalu lintas keluar lainnya dari `webapp` pod ditolak secara implisit
## Kebijakan jaringan admin (atau cluster)
![\[llustrasi urutan evaluasi untuk kebijakan jaringan di EKS\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/evaluation-order.png)
Anda dapat menggunakan `ClusterNetworkPolicy` untuk menegakkan standar keamanan jaringan yang berlaku untuk seluruh cluster. Alih-alih mendefinisikan dan mempertahankan kebijakan yang berbeda secara berulang untuk setiap namespace, Anda dapat menggunakan satu kebijakan untuk mengelola kontrol akses jaringan secara terpusat untuk beban kerja yang berbeda di klaster, terlepas dari namespace mereka.
### Kasus penggunaan
+ Kelola kontrol akses jaringan secara terpusat untuk semua (atau sebagian dari) beban kerja di kluster EKS Anda.
+ Tentukan postur keamanan jaringan default di seluruh cluster.
+ Memperluas standar keamanan organisasi ke ruang lingkup cluster dengan cara yang lebih efisien secara operasional.
### Contoh
Dalam kebijakan di bawah ini, Anda dapat secara eksplisit memblokir lalu lintas klaster dari ruang nama lain untuk mencegah akses jaringan ke namespace beban kerja yang sensitif.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Catatan penting
Kebijakan jaringan di plugin Amazon VPC CNI untuk Kubernetes didukung dalam konfigurasi yang tercantum di bawah ini.
+ Versi 1.21.0 (atau yang lebih baru) plugin Amazon VPC CNI untuk kebijakan jaringan standar dan admin.
+ Cluster dikonfigurasi untuk `IPv4` atau `IPv6` alamat.
+ Anda dapat menggunakan kebijakan jaringan dengan [grup keamanan untuk Pod](security-groups-for-pods.md). Dengan kebijakan jaringan, Anda dapat mengontrol semua komunikasi dalam cluster. Dengan grup keamanan untuk Pod, Anda dapat mengontrol akses ke AWS layanan dari aplikasi di dalam Pod.
+ Anda dapat menggunakan kebijakan jaringan dengan *jaringan kustom* dan *delegasi awalan*.
## Pertimbangan-pertimbangan
**Arsitektur **
+ Saat menerapkan plugin Amazon VPC CNI untuk kebijakan jaringan Kubernetes ke klaster Anda dengan plugin Amazon VPC CNI untuk Kubernetes, Anda hanya dapat menerapkan kebijakan tersebut ke node Amazon Linux. EC2 Anda tidak dapat menerapkan kebijakan ke Fargate atau Windows node.
+ Kebijakan jaringan hanya berlaku salah satu `IPv4` atau `IPv6` alamat, tetapi tidak keduanya. Dalam sebuah `IPv4` klaster, VPC CNI memberikan `IPv4` alamat ke pod dan menerapkan kebijakan. `IPv4` Dalam sebuah `IPv6` klaster, VPC CNI memberikan `IPv6` alamat ke pod dan menerapkan kebijakan. `IPv6` Aturan kebijakan `IPv4` jaringan apa pun yang diterapkan pada `IPv6` klaster akan diabaikan. Aturan kebijakan `IPv6` jaringan apa pun yang diterapkan pada `IPv4` klaster akan diabaikan.
**Kebijakan Jaringan**
+ Kebijakan Jaringan hanya diterapkan pada Pod yang merupakan bagian dari Deployment. Pod mandiri yang tidak memiliki `metadata.ownerReferences` satu set tidak dapat memiliki kebijakan jaringan yang diterapkan padanya.
+ Anda dapat menerapkan beberapa kebijakan jaringan ke Pod yang sama. Ketika dua atau lebih kebijakan yang memilih Pod yang sama dikonfigurasi, semua kebijakan diterapkan ke Pod.
+ Jumlah maksimum kombinasi port dan protokol untuk rentang alamat IP tunggal (CIDR) adalah 24 di semua kebijakan jaringan Anda. Selektor seperti `namespaceSelector` menyelesaikan satu atau lebih CIDRs. Jika beberapa penyeleksi menyelesaikan ke CIDR tunggal atau Anda menentukan CIDR langsung yang sama beberapa kali dalam kebijakan jaringan yang sama atau berbeda, semua ini dihitung dalam batas ini.
+ Untuk salah satu layanan Kubernetes Anda, port layanan harus sama dengan port kontainer. Jika Anda menggunakan port bernama, gunakan nama yang sama dalam spesifikasi layanan juga.
**Kebijakan Jaringan Admin**
1. **Kebijakan tingkat admin (dievaluasi terlebih dahulu)**: Semua tingkat Admin ClusterNetworkPolicies dievaluasi sebelum kebijakan lainnya. Dalam tingkat Admin, kebijakan diproses dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). Jenis tindakan menentukan apa yang terjadi selanjutnya.
+ **Tindakan tolak (prioritas tertinggi)**: Ketika kebijakan Admin dengan tindakan Tolak cocok dengan lalu lintas, lalu lintas tersebut segera diblokir terlepas dari kebijakan lainnya. Tidak ada lebih lanjut ClusterNetworkPolicy atau NetworkPolicy aturan yang diproses. Ini memastikan bahwa kontrol keamanan di seluruh organisasi tidak dapat diganti oleh kebijakan tingkat ruang nama.
+ **Izinkan tindakan**: Setelah aturan Tolak dievaluasi, kebijakan Admin dengan tindakan Izinkan diproses dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). Ketika tindakan Izinkan cocok, lalu lintas diterima dan tidak ada evaluasi kebijakan lebih lanjut yang terjadi. Kebijakan ini dapat memberikan akses di beberapa ruang nama berdasarkan pemilih label, memberikan kontrol terpusat atas beban kerja mana yang dapat mengakses sumber daya tertentu.
+ **Lulus tindakan**: Melewati tindakan dalam kebijakan tingkat Admin mendelegasikan pengambilan keputusan ke tingkat yang lebih rendah. Ketika lalu lintas cocok dengan aturan Pass, evaluasi melewatkan semua aturan tingkat Admin yang tersisa untuk lalu lintas tersebut dan melanjutkan langsung ke tingkat. NetworkPolicy Hal ini memungkinkan administrator untuk secara eksplisit mendelegasikan kontrol untuk pola lalu lintas tertentu ke tim aplikasi. Misalnya, Anda dapat menggunakan aturan Pass untuk mendelegasikan manajemen lalu lintas intra-namespace ke administrator namespace sambil mempertahankan kontrol ketat atas akses eksternal.
1. **Tingkat kebijakan jaringan**: Jika tidak ada kebijakan tingkat Admin yang cocok dengan Tolak atau Izinkan, atau jika tindakan Pass dicocokkan, sumber daya cakupan ruang nama akan dievaluasi NetworkPolicy berikutnya. Kebijakan ini memberikan kontrol halus dalam ruang nama individu dan dikelola oleh tim aplikasi. Kebijakan dengan cakupan ruang nama hanya bisa lebih ketat daripada kebijakan Admin. Mereka tidak dapat mengesampingkan keputusan Tolak kebijakan Admin, tetapi mereka dapat membatasi lalu lintas yang diizinkan atau disahkan oleh kebijakan Admin.
1. **Kebijakan Admin tingkat dasar: Jika tidak ada kebijakan** dengan cakupan Admin atau ruang nama yang cocok dengan lalu lintas, tingkat dasar akan dievaluasi. ClusterNetworkPolicies Ini memberikan postur keamanan default yang dapat diganti dengan kebijakan cakupan ruang nama, memungkinkan administrator untuk menetapkan default di seluruh organisasi sambil memberi tim fleksibilitas untuk menyesuaikan sesuai kebutuhan. Kebijakan dasar dievaluasi dalam urutan prioritas (nomor prioritas terendah terlebih dahulu).
1. **Penyangkalan default (jika tidak ada kebijakan yang cocok)**: deny-by-default Perilaku ini memastikan bahwa hanya koneksi yang diizinkan secara eksplisit yang diizinkan, mempertahankan postur keamanan yang kuat.
**Migrasi**
+ Jika klaster Anda saat ini menggunakan solusi pihak ketiga untuk mengelola kebijakan jaringan Kubernetes, Anda dapat menggunakan kebijakan yang sama dengan plugin Amazon VPC CNI untuk Kubernetes. Namun Anda harus menghapus solusi yang ada sehingga tidak mengelola kebijakan yang sama.
**Awas**
Kami menyarankan bahwa setelah Anda menghapus solusi kebijakan jaringan, maka Anda mengganti semua node yang memiliki solusi kebijakan jaringan diterapkan pada mereka. Ini karena peraturan lalu lintas mungkin tertinggal oleh pod solusi jika keluar tiba-tiba.
**Instalasi**
+ Fitur kebijakan jaringan membuat dan memerlukan `PolicyEndpoint` Custom Resource Definition (CRD) yang disebut`policyendpoints.networking.k8s.aws`. `PolicyEndpoint`objek Sumber Daya Kustom dikelola oleh Amazon EKS. Anda tidak boleh memodifikasi atau menghapus sumber daya ini.
+ Jika Anda menjalankan pod yang menggunakan kredensial IAM peran instance atau terhubung ke EC2 IMDS, berhati-hatilah untuk memeriksa kebijakan jaringan yang akan memblokir akses ke IMDS. EC2 Anda mungkin perlu menambahkan kebijakan jaringan untuk mengizinkan akses ke EC2 IMDS. Untuk informasi selengkapnya, lihat [Metadata instans dan data pengguna](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) di EC2 Panduan Pengguna Amazon.
Pod yang menggunakan *peran IAM untuk akun layanan* atau *EKS Pod Identity* tidak mengakses EC2 IMDS.
+ Plugin Amazon VPC CNI untuk Kubernetes tidak menerapkan kebijakan jaringan ke antarmuka jaringan tambahan untuk setiap pod, hanya antarmuka utama untuk setiap pod (). `eth0` Ini mempengaruhi arsitektur berikut:
+ `IPv6`pod dengan `ENABLE_V4_EGRESS` variabel disetel ke`true`. Variabel ini memungkinkan fitur `IPv4` keluar untuk menghubungkan IPv6 pod ke `IPv4` titik akhir seperti yang berada di luar cluster. Fitur `IPv4` jalan keluar bekerja dengan membuat antarmuka jaringan tambahan dengan alamat IPv4 loopback lokal.
+ Saat menggunakan plugin jaringan berantai seperti Multus. Karena plugin ini menambahkan antarmuka jaringan ke setiap pod, kebijakan jaringan tidak diterapkan ke plugin jaringan yang dirantai.
# Batasi lalu lintas jaringan Pod dengan kebijakan jaringan Kubernetes
Anda dapat menggunakan kebijakan jaringan Kubernetes untuk membatasi lalu lintas jaringan ke dan dari Pod Anda. Untuk informasi selengkapnya, lihat [Kebijakan Jaringan](https://kubernetes.io/docs/concepts/services-networking/network-policies/) dalam dokumentasi Kubernetes.
Anda harus mengkonfigurasi berikut ini untuk menggunakan fitur ini:
1. Siapkan penegakan kebijakan saat startup Pod. Anda melakukan ini dalam `aws-node` wadah VPC CNI. `DaemonSet`
1. Aktifkan parameter kebijakan jaringan untuk add-on.
1. Konfigurasikan klaster Anda untuk menggunakan kebijakan jaringan Kubernetes
Sebelum Anda mulai, tinjau pertimbangannya. Untuk informasi selengkapnya, lihat [Pertimbangan-pertimbangan](cni-network-policy.md#cni-network-policy-considerations).
## Prasyarat
Berikut ini adalah prasyarat untuk fitur ini:
### Versi cluster minimum
Sebuah klaster Amazon EKS yang sudah ada. Untuk menyebarkan satu, lihat[Memulai dengan Amazon EKS](getting-started.md). Cluster harus menjalankan salah satu versi Kubernetes dan versi platform yang tercantum dalam tabel berikut. Perhatikan bahwa versi Kubernetes dan platform yang lebih lambat dari yang terdaftar juga didukung. Anda dapat memeriksa versi Kubernetes Anda saat ini dengan mengganti *my-cluster* perintah berikut dengan nama cluster Anda dan kemudian menjalankan perintah yang dimodifikasi:
```
aws eks describe-cluster --name my-cluster --query cluster.version --output text
```
| Versi Kubernetes | Versi Platform |
| --- | --- |
| `1.27.4` | `eks.5` |
| `1.26.7` | `eks.6` |
### Versi VPC CNI minimum
Untuk membuat kebijakan jaringan Kubernetes standar dan kebijakan jaringan admin, Anda perlu menjalankan versi `1.21` plugin VPC CNI. Anda dapat melihat versi mana yang saat ini Anda miliki dengan perintah berikut.
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Jika versi Anda lebih awal dari`1.21`, lihat [Perbarui Amazon VPC CNI (add-on Amazon EKS)](vpc-add-on-update.md) untuk meningkatkan ke versi `1.21` atau yang lebih baru.
### Versi kernel Linux minimum
Node Anda harus memiliki versi kernel Linux `5.10` atau yang lebih baru. Anda dapat memeriksa versi kernel Anda dengan`uname -r`. Jika Anda menggunakan versi terbaru Amazon EKS yang dioptimalkan Amazon Linux, Amazon EKS mengoptimalkan Amazon Linux yang dipercepat AMIs, dan Bottlerocket AMIs, mereka sudah memiliki versi kernel yang diperlukan.
Amazon EKS mengoptimalkan versi AMI Amazon Linux yang dipercepat `v20231116` atau yang lebih baru memiliki versi kernel`5.10`.
## Langkah 1: Siapkan penegakan kebijakan saat startup Pod
Plugin Amazon VPC CNI untuk Kubernetes mengonfigurasi kebijakan jaringan untuk pod secara paralel dengan penyediaan pod. Sampai semua kebijakan dikonfigurasi untuk pod baru, container di pod baru akan dimulai dengan *kebijakan allow default*. Ini disebut *mode standar*. Kebijakan allow default berarti bahwa semua lalu lintas masuk dan keluar diizinkan ke dan dari pod baru. Misalnya, pod tidak akan memiliki aturan firewall yang diberlakukan (semua lalu lintas diizinkan) sampai pod baru diperbarui dengan kebijakan aktif.
Dengan `NETWORK_POLICY_ENFORCING_MODE` variabel disetel ke`strict`, pod yang menggunakan VPC CNI dimulai dengan kebijakan penolakan *default, kemudian kebijakan* dikonfigurasi. Ini disebut *mode ketat*. Dalam mode ketat, Anda harus memiliki kebijakan jaringan untuk setiap titik akhir yang perlu diakses Pod di klaster Anda. Perhatikan bahwa persyaratan ini berlaku untuk pod CoreDNS. Kebijakan penolakan default tidak dikonfigurasi untuk pod dengan jaringan Host.
Anda dapat mengubah kebijakan jaringan default dengan menyetel variabel lingkungan `NETWORK_POLICY_ENFORCING_MODE` ke `strict` dalam `aws-node` wadah CNI VPC. `DaemonSet`
```
env:
- name: NETWORK_POLICY_ENFORCING_MODE
value: "strict"
```
## Langkah 2: Aktifkan parameter kebijakan jaringan untuk add-on
Fitur kebijakan jaringan menggunakan port `8162` pada node untuk metrik secara default. Selain itu, fitur ini menggunakan port `8163` untuk pemeriksaan kesehatan. Jika Anda menjalankan aplikasi lain di node atau di dalam pod yang perlu menggunakan port ini, aplikasi gagal dijalankan. Dari versi VPC CNI `v1.14.1` atau yang lebih baru, Anda dapat mengubah port ini.
Gunakan prosedur berikut untuk mengaktifkan parameter kebijakan jaringan untuk add-on.
### 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 **Versi**.
1. Perluas **pengaturan konfigurasi opsional**.
1. Masukkan kunci `"enableNetworkPolicy":` dan nilai JSON `"true"` dalam **nilai Konfigurasi**. Teks yang dihasilkan harus berupa objek JSON yang valid. Jika kunci dan nilai ini adalah satu-satunya data dalam kotak teks, kelilingi kunci dan nilai dengan kurawal kurawal. `{ }`
Contoh berikut ini mengaktifkan fitur kebijakan jaringan dan metrik serta probe kesehatan disetel ke nomor port default:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"healthProbeBindAddr": "8163",
"metricsBindAddr": "8162"
}
}
```
### Helm
Jika Anda telah menginstal plugin Amazon VPC CNI untuk Kubernetes`helm`, Anda dapat memperbarui konfigurasi untuk mengubah port.
1. Jalankan perintah berikut untuk mengubah port. Tetapkan nomor port dalam nilai untuk kunci `nodeAgent.metricsBindAddr` atau kunci`nodeAgent.healthProbeBindAddr`, masing-masing.
```
helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 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 nomor port dalam argumen perintah berikut di dalam `aws-network-policy-agent` wadah dalam `args:` manifes daemonset VPC CNI`aws-node`.
```
- args:
- --metrics-bind-addr=:8162
- --health-probe-bind-addr=:8163
```
## Langkah 3: Konfigurasikan klaster Anda untuk menggunakan kebijakan jaringan Kubernetes
Anda dapat mengatur ini untuk add-on Amazon EKS atau add-on yang dikelola sendiri.
### Pengaya Amazon EKS
Dengan menggunakan AWS CLI, Anda dapat mengonfigurasi cluster untuk menggunakan kebijakan jaringan Kubernetes dengan menjalankan perintah berikut. Ganti `my-cluster` dengan nama cluster Anda dan 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 '{"enableNetworkPolicy": "true"}'
```
Untuk mengonfigurasinya menggunakan AWS Management Console, ikuti langkah-langkah di bawah ini:
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 **Versi**.
1. Perluas **pengaturan konfigurasi opsional**.
1. Masukkan kunci `"enableNetworkPolicy":` dan nilai JSON `"true"` dalam **nilai Konfigurasi**. Teks yang dihasilkan harus berupa objek JSON yang valid. Jika kunci dan nilai ini adalah satu-satunya data dalam kotak teks, kelilingi kunci dan nilai dengan kurawal kurawal. `{ }` Contoh berikut menunjukkan kebijakan jaringan diaktifkan:
```
{ "enableNetworkPolicy": "true" }
```
Screenshot berikut menunjukkan contoh skenario ini.
![\[menampilkan add-on VPC CNI dengan kebijakan jaringan dalam konfigurasi opsional.\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/console-cni-config-network-policy.png)
### Add-on yang dikelola sendiri
Jika Anda telah menginstal plugin Amazon VPC CNI untuk Kubernetes`helm`, Anda dapat memperbarui konfigurasi untuk mengaktifkan kebijakan jaringan.
1. Jalankan perintah berikut untuk mengaktifkan kebijakan jaringan.
```
helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
1. Buka `amazon-vpc-cni` `ConfigMap` di editor Anda.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Tambahkan baris berikut ke `data` dalam`ConfigMap`.
```
enable-network-policy-controller: "true"
```
Setelah Anda menambahkan baris, Anda `ConfigMap` akan terlihat seperti contoh berikut.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Buka `aws-node` `DaemonSet` di editor Anda.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Ganti `false` dengan `true` dalam argumen perintah di `--enable-network-policy=false` dalam `aws-network-policy-agent` wadah `args:` dalam manifes daemonset VPC CNI`aws-node`.
```
- args:
- --enable-network-policy=true
```
## Langkah 4. Langkah selanjutnya
Setelah Anda menyelesaikan konfigurasi, konfirmasikan bahwa `aws-node` pod berjalan di klaster Anda.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
Contoh output adalah sebagai berikut.
```
aws-node-gmqp7 2/2 Running 1 (24h ago) 24h
aws-node-prnsh 2/2 Running 1 (24h ago) 24h
```
Ada 2 kontainer di `aws-node` pod dalam versi `1.14` dan yang lebih baru. Di versi sebelumnya dan jika kebijakan jaringan dinonaktifkan, hanya ada satu kontainer di `aws-node` pod.
Anda sekarang dapat menerapkan kebijakan jaringan Kubernetes ke klaster Anda.
Untuk menerapkan kebijakan jaringan Kubernetes, Anda dapat membuat Kubernetes `NetworkPolicy` atau `ClusterNetworkPolicy` objek dan menerapkannya ke klaster Anda. `NetworkPolicy`objek dicakup ke namespace, sementara `ClusterNetworkPolicy` objek dapat dicakup ke seluruh cluster atau beberapa ruang nama. Anda menerapkan kebijakan untuk mengizinkan atau menolak lalu lintas antar Pod berdasarkan pemilih label, ruang nama, dan rentang alamat IP. Untuk informasi selengkapnya tentang membuat `NetworkPolicy` objek, lihat [Kebijakan Jaringan](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) dalam dokumentasi Kubernetes.
Penegakan `NetworkPolicy` objek Kubernetes diimplementasikan menggunakan Extended Berkeley Packet Filter (eBPF). Sehubungan dengan implementasi `iptables` berbasis, ia menawarkan karakteristik latensi dan kinerja yang lebih rendah, termasuk pengurangan pemanfaatan CPU dan menghindari pencarian berurutan. Selain itu, probe eBPF menyediakan akses ke data kaya konteks yang membantu men-debug masalah tingkat kernel yang kompleks dan meningkatkan observabilitas. Amazon EKS mendukung eksportir berbasis EBPF yang memanfaatkan probe untuk mencatat hasil kebijakan pada setiap node dan mengekspor data ke pengumpul log eksternal untuk membantu debugging. Untuk informasi selengkapnya, lihat dokumentasi [eBPF](https://ebpf.io/what-is-ebpf/#what-is-ebpf).
# Nonaktifkan kebijakan jaringan Kubernetes untuk lalu lintas jaringan Amazon EKS Pod
Nonaktifkan kebijakan jaringan Kubernetes untuk berhenti membatasi lalu lintas jaringan Amazon EKS Pod
1. Daftar semua kebijakan jaringan Kubernetes.
```
kubectl get netpol -A
```
1. Hapus setiap kebijakan jaringan Kubernetes. Anda harus menghapus semua kebijakan jaringan sebelum menonaktifkan kebijakan jaringan.
```
kubectl delete netpol
```
1. Buka aws-node DaemonSet di editor Anda.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Ganti `true` dengan `false` dalam argumen perintah di `--enable-network-policy=true` dalam `aws-network-policy-agent` wadah `args:` dalam manifes daemonset VPC CNI`aws-node`.
```
- args:
- --enable-network-policy=true
```
# 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.
# Bintang demo kebijakan jaringan untuk Amazon EKS
Demo ini membuat layanan front-end, back-end, dan klien di cluster Amazon EKS Anda. Demo ini juga menciptakan antarmuka pengguna grafis manajemen yang menunjukkan jalur masuk dan keluar yang tersedia di antara setiap layanan. Kami menyarankan Anda menyelesaikan demo di klaster tempat Anda tidak menjalankan beban kerja produksi.
Sebelum Anda membuat kebijakan jaringan apa pun, semua layanan dapat berkomunikasi dua arah. Setelah Anda menerapkan kebijakan jaringan, Anda dapat melihat bahwa klien hanya dapat berkomunikasi dengan layanan front-end, dan back-end hanya menerima lalu lintas dari front-end.
1. Menerapkan layanan antarmuka pengguna front-end, back-end, klien, dan manajemen:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
```
1. Lihat semua Pod di klaster.
```
kubectl get pods -A
```
Contoh output adalah sebagai berikut.
Dalam output Anda, Anda akan melihat pod di namespace yang ditunjukkan pada output berikut. Pod Anda dan jumlah pod di `READY` kolom berbeda dari yang ada di output berikut. *NAMES* Jangan lanjutkan sampai Anda melihat pod dengan nama yang mirip dan semuanya ada `Running` di `STATUS` kolom.
```
NAMESPACE NAME READY STATUS RESTARTS AGE
[...]
client client-xlffc 1/1 Running 0 5m19s
[...]
management-ui management-ui-qrb2g 1/1 Running 0 5m24s
stars backend-sz87q 1/1 Running 0 5m23s
stars frontend-cscnf 1/1 Running 0 5m21s
[...]
```
1. Untuk terhubung ke antarmuka pengguna manajemen, sambungkan ke layanan `EXTERNAL-IP` yang berjalan di klaster Anda:
```
kubectl get service/management-ui -n management-ui
```
1. Buka browser ke lokasi dari langkah sebelumnya. Anda harus melihat antarmuka pengguna manajemen. Node **C** adalah layanan klien, simpul **F** adalah layanan front-end, dan simpul **B** adalah layanan back-end. Setiap node memiliki akses komunikasi penuh ke semua node lain, seperti yang ditunjukkan oleh garis tebal berwarna.
![\[Buka kebijakan jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/stars-default.png)
1. Terapkan kebijakan jaringan berikut di ruang nama `stars` dan `client` ruang nama untuk mengisolasi layanan satu sama lain:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny
spec:
podSelector:
matchLabels: {}
```
Anda dapat menggunakan perintah berikut untuk menerapkan kebijakan ke kedua ruang nama:
```
kubectl apply -n stars -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
```
1. Segarkan peramban Anda. Anda melihat bahwa antarmuka pengguna manajemen tidak dapat lagi menjangkau salah satu node, sehingga tidak muncul di antarmuka pengguna.
1. Terapkan kebijakan jaringan yang berbeda berikut untuk memungkinkan antarmuka pengguna manajemen mengakses layanan. Terapkan kebijakan ini untuk mengizinkan UI:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Terapkan kebijakan ini untuk mengizinkan klien:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: client
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Anda dapat menggunakan perintah berikut untuk menerapkan kedua kebijakan:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml
```
1. Segarkan peramban Anda. Anda melihat bahwa antarmuka pengguna manajemen dapat mencapai node lagi, tetapi node tidak dapat berkomunikasi satu sama lain.
![\[Kebijakan jaringan akses UI\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/stars-no-traffic.png)
1. Terapkan kebijakan jaringan berikut untuk mengizinkan lalu lintas dari layanan front-end ke layanan back-end:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: backend-policy
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
```
1. Segarkan peramban Anda. Anda melihat bahwa front-end dapat berkomunikasi dengan back-end.
![\[Kebijakan front-end ke back-end\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/stars-front-end-back-end.png)
1. Terapkan kebijakan jaringan berikut untuk mengizinkan lalu lintas dari klien ke layanan front-end:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: frontend-policy
spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- namespaceSelector:
matchLabels:
role: client
ports:
- protocol: TCP
port: 80
```
1. Segarkan peramban Anda. Anda melihat bahwa klien dapat berkomunikasi dengan layanan front-end. Layanan front-end masih dapat berkomunikasi dengan layanan back-end.
![\[Kebijakan jaringan akhir\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/stars-final.png)
1. (Opsional) Setelah selesai dengan demo, Anda dapat menghapus sumber dayanya.
```
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
```
Bahkan setelah menghapus sumber daya, masih ada titik akhir kebijakan jaringan pada node yang mungkin mengganggu jaringan di cluster Anda dengan cara yang tidak terduga. Satu-satunya cara pasti untuk menghapus aturan ini adalah dengan me-reboot node atau menghentikan semua node dan mendaur ulangnya. Untuk mengakhiri semua simpul, atur jumlah Grup Auto Scaling yang diinginkan ke 0, lalu buat cadangan ke jumlah yang diinginkan, atau cukup hentikan simpul.
# Menerapkan Pod di subnet alternatif dengan jaringan khusus
**Berlaku untuk**: Node `IPv4` Fargate Linux, node Linux dengan instance Amazon EC2
![\[Diagram node dengan beberapa antarmuka jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/cn-image.png)
Secara default, ketika plugin Amazon VPC CNI untuk Kubernetes membuat antarmuka [jaringan elastis sekunder (antarmuka jaringan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)) untuk EC2 node Amazon Anda, itu membuatnya dalam subnet yang sama dengan antarmuka jaringan utama node. Ini juga mengaitkan kelompok keamanan yang sama ke antarmuka jaringan sekunder yang terkait dengan antarmuka jaringan utama. Untuk satu atau beberapa alasan berikut, Anda mungkin ingin plugin membuat antarmuka jaringan sekunder di subnet yang berbeda atau ingin mengaitkan grup keamanan yang berbeda ke antarmuka jaringan sekunder, atau keduanya:
+ Ada sejumlah `IPv4` alamat terbatas yang tersedia di subnet tempat antarmuka jaringan utama berada. Ini mungkin membatasi jumlah Pod yang dapat Anda buat di subnet. Dengan menggunakan subnet yang berbeda untuk antarmuka jaringan sekunder, Anda dapat menambah jumlah `IPv4` alamat yang tersedia untuk Pod.
+ Untuk alasan keamanan, Pod Anda mungkin perlu menggunakan subnet atau grup keamanan yang berbeda dari antarmuka jaringan utama node.
+ Node dikonfigurasi dalam subnet publik, dan Anda ingin menempatkan Pod di subnet pribadi. Tabel rute yang terkait dengan subnet publik mencakup rute ke gateway internet. Tabel rute yang terkait dengan subnet pribadi tidak menyertakan rute ke gateway internet.
**Tip**
Anda juga dapat menambahkan subnet baru atau yang sudah ada langsung ke Amazon EKS Cluster Anda, tanpa menggunakan jaringan khusus. Untuk informasi selengkapnya, lihat [Tambahkan Subnet VPC yang ada ke cluster Amazon EKS dari konsol manajemen](eks-networking.md#add-existing-subnet).
## Pertimbangan
Berikut ini adalah pertimbangan untuk menggunakan fitur ini.
+ Dengan mengaktifkan jaringan khusus, tidak ada alamat IP yang ditetapkan ke antarmuka jaringan utama yang ditetapkan ke Pod. Hanya alamat IP dari antarmuka jaringan sekunder yang ditetapkan ke Pod.
+ Jika klaster Anda menggunakan `IPv6` keluarga, Anda tidak dapat menggunakan jaringan khusus.
+ Jika Anda berencana untuk menggunakan jaringan khusus hanya untuk membantu mengurangi kelelahan `IPv4` alamat, Anda dapat membuat klaster menggunakan keluarga sebagai gantinya. `IPv6` Untuk informasi selengkapnya, lihat [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md).
+ Meskipun Pod yang di-deploy ke subnet yang ditentukan untuk antarmuka jaringan sekunder dapat menggunakan subnet dan grup keamanan yang berbeda dari antarmuka jaringan utama node, subnet dan grup keamanan harus berada dalam VPC yang sama dengan node.
+ Untuk Fargate, subnet dikendalikan melalui profil Fargate. Untuk informasi selengkapnya, lihat [Tentukan Pod mana yang menggunakan AWS Fargate saat diluncurkan](fargate-profile.md).
# Sesuaikan antarmuka jaringan sekunder di node Amazon EKS
Selesaikan yang berikut ini sebelum Anda memulai tutorial:
+ Tinjau pertimbangannya
+ Keakraban dengan bagaimana plugin Amazon VPC CNI untuk Kubernetes membuat antarmuka jaringan sekunder dan menetapkan alamat IP ke Pod. Untuk informasi lebih lanjut, lihat [Alokasi ENI](https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation) di GitHub.
+ Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Versi AWS CLI yang diinstal AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di * AWS CloudShell Panduan Pengguna*.
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ Kami menyarankan Anda menyelesaikan langkah-langkah dalam topik ini di shell Bash. Jika Anda tidak menggunakan shell Bash, beberapa perintah skrip seperti karakter kelanjutan baris dan cara variabel diatur dan digunakan memerlukan penyesuaian untuk shell Anda. Selain itu, aturan mengutip dan melarikan diri untuk shell Anda mungkin berbeda. Untuk informasi selengkapnya, lihat [Menggunakan tanda kutip dengan string di AWS CLI di](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) Panduan Pengguna Antarmuka Baris AWS Perintah.
Untuk tutorial ini, kami sarankan menggunakan nilai contoh, kecuali jika dicatat untuk menggantinya. Anda dapat mengganti nilai contoh apa pun saat menyelesaikan langkah-langkah untuk klaster produksi. Kami merekomendasikan untuk menyelesaikan semua langkah di terminal yang sama. Ini karena variabel diatur dan digunakan di seluruh langkah dan tidak akan ada di terminal yang berbeda.
Perintah dalam topik ini diformat menggunakan konvensi yang tercantum dalam [Menggunakan contoh CLI AWS](https://docs.aws.amazon.com/cli/latest/userguide/welcome-examples.html). Jika Anda menjalankan perintah dari baris perintah terhadap sumber daya yang berada di AWS Wilayah yang berbeda dari AWS Wilayah default yang ditentukan dalam [profil AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-profiles) CLI yang Anda gunakan, maka Anda perlu menambahkan `--region us-west-2` perintah, menggantinya `us-west-2` dengan wilayah Anda AWS .
Saat Anda ingin menerapkan jaringan khusus ke kluster produksi Anda, lewati ke[Langkah 2: Konfigurasikan VPC Anda](#custom-networking-configure-vpc).
## Langkah 1: Buat tes VPC dan cluster
Prosedur berikut membantu Anda membuat pengujian VPC dan cluster dan mengkonfigurasi jaringan khusus untuk cluster itu. Kami tidak menyarankan penggunaan klaster pengujian untuk beban kerja produksi karena beberapa fitur yang tidak terkait yang mungkin Anda gunakan pada klaster produksi tidak tercakup dalam topik ini. Untuk informasi selengkapnya, lihat [Buat kluster Amazon EKS](create-cluster.md).
1. Jalankan perintah berikut untuk menentukan `account_id` variabel.
```
account_id=$(aws sts get-caller-identity --query Account --output text)
```
1. Buat sebuah VPC.
1. Jika Anda menerapkan ke sistem pengujian, buat VPC menggunakan template Amazon AWS CloudFormation EKS.
```
aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
--parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27
```
1. AWS CloudFormation Tumpukan membutuhkan waktu beberapa menit untuk membuatnya. Untuk memeriksa status penyebaran tumpukan, jalankan perintah berikut.
```
aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus --output text
```
Jangan melanjutkan ke langkah berikutnya sampai output dari perintah tersebut`CREATE_COMPLETE`.
1. Tentukan variabel dengan nilai subnet pribadi yang IDs dibuat oleh template.
```
subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
```
1. Tentukan variabel dengan Availability Zones dari subnet yang diambil pada langkah sebelumnya.
```
az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)
```
1. Buat peran IAM cluster.
1. Jalankan perintah berikut untuk membuat file JSON kebijakan kepercayaan IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Buat peran IAM cluster Amazon EKS. Jika perlu, kata pengantar `eks-cluster-role-trust-policy.json` dengan jalur di komputer Anda tempat Anda menulis file pada langkah sebelumnya. Perintah tersebut mengaitkan kebijakan kepercayaan yang Anda buat pada langkah sebelumnya dengan peran tersebut. Untuk membuat peran IAM, [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang membuat peran harus diberi `iam:CreateRole` tindakan (izin).
```
aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Lampirkan kebijakan terkelola Amazon EKS bernama [EKSClusterKebijakan Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) ke peran tersebut. Untuk melampirkan kebijakan IAM ke kepala sekolah [IAM, prinsipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang melampirkan kebijakan harus diberikan salah satu tindakan IAM berikut (izin): atau. `iam:AttachUserPolicy` `iam:AttachRolePolicy`
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Buat kluster Amazon EKS dan konfigurasikan perangkat Anda untuk berkomunikasi dengannya.
1. Buat sebuah klaster.
```
aws eks create-cluster --name my-custom-networking-cluster \
--role-arn arn:aws: iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
--resources-vpc-config subnetIds="$subnet_id_1","$subnet_id_2"
```
**catatan**
Anda mungkin menerima kesalahan bahwa salah satu Availability Zone dalam permintaan Anda tidak memiliki kapasitas yang cukup untuk membuat klaster Amazon EKS. Jika hal ini terjadi, output galat berisi Availability Zones yang dapat mendukung klaster baru. Cobalah untuk kembali membuat klaster dengan setidaknya dua subnet yang terletak di Availability Zones yang didukung untuk akun Anda. Untuk informasi selengkapnya, lihat [Kapasitas tidak mencukupi](troubleshooting.md#ice).
1. Cluster membutuhkan waktu beberapa menit untuk membuatnya. Untuk memeriksa status penyebaran cluster, jalankan perintah berikut.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status
```
Jangan melanjutkan ke langkah berikutnya sampai output dari perintah tersebut`"ACTIVE"`.
1. Konfigurasikan `kubectl` untuk berkomunikasi dengan cluster Anda.
```
aws eks update-kubeconfig --name my-custom-networking-cluster
```
## Langkah 2: Konfigurasikan VPC Anda
Tutorial ini membutuhkan VPC yang dibuat di. [Langkah 1: Buat tes VPC dan cluster](#custom-networking-create-cluster) Untuk cluster produksi, sesuaikan langkah-langkah yang sesuai untuk VPC Anda dengan mengganti semua nilai contoh dengan milik Anda sendiri.
1. Konfirmasikan bahwa plugin Amazon VPC CNI Anda yang saat ini diinstal untuk Kubernetes adalah versi terbaru. Untuk menentukan versi terbaru untuk jenis add-on Amazon EKS dan memperbarui versi Anda ke sana, lihat[Perbarui add-on Amazon EKS](updating-an-add-on.md). Untuk menentukan versi terbaru untuk jenis add-on yang dikelola sendiri dan memperbarui versi Anda ke sana, lihat. [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md)
1. Ambil ID VPC cluster Anda dan simpan dalam variabel untuk digunakan di langkah selanjutnya.
```
vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
```
1. Kaitkan blok Classless Inter-Domain Routing (CIDR) tambahan dengan VPC klaster Anda. Blok CIDR tidak dapat tumpang tindih dengan blok CIDR terkait yang ada.
1. Lihat blok CIDR saat ini yang terkait dengan VPC Anda.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id \
--query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Contoh output adalah sebagai berikut.
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
+-----------------+--------------+
```
1. Kaitkan blok CIDR tambahan ke VPC Anda. Ganti nilai blok CIDR dalam perintah berikut. Untuk informasi selengkapnya, lihat [Mengaitkan blok IPv4 CIDR tambahan dengan VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#add-ipv4-cidr) di Panduan Pengguna Amazon VPC.
```
aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
```
1. Konfirmasikan bahwa blok baru dikaitkan.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Contoh output adalah sebagai berikut.
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
| 192.168.1.0/24 | associated |
+-----------------+--------------+
```
Jangan lanjutkan ke langkah berikutnya sampai blok CIDR baru Anda selesai`State`. `associated`
1. Buat subnet sebanyak yang ingin Anda gunakan di setiap Availability Zone tempat subnet Anda ada. Tentukan blok CIDR yang ada di dalam blok CIDR yang Anda kaitkan dengan VPC Anda di langkah sebelumnya.
1. Buat subnet baru. Ganti nilai blok CIDR dalam perintah berikut. Subnet harus dibuat di blok CIDR VPC yang berbeda dari subnet yang ada, tetapi di Availability Zone yang sama dengan subnet yang ada. Dalam contoh ini, satu subnet dibuat di blok CIDR baru di setiap Availability Zone tempat subnet pribadi saat ini ada. Subnet IDs yang dibuat disimpan dalam variabel untuk digunakan dalam langkah-langkah selanjutnya. `Name`Nilai cocok dengan nilai yang ditetapkan ke subnet yang dibuat menggunakan template Amazon EKS VPC pada langkah sebelumnya. Nama tidak diperlukan. Anda dapat menggunakan nama yang berbeda.
```
new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
```
**penting**
[Secara default, subnet baru Anda secara implisit terkait dengan tabel rute utama VPC Anda.](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#RouteTables) Tabel rute ini memungkinkan komunikasi antara semua sumber daya yang digunakan di VPC. Namun, itu tidak memungkinkan komunikasi dengan sumber daya yang memiliki alamat IP yang berada di luar blok CIDR yang terkait dengan VPC Anda. Anda dapat mengaitkan tabel rute Anda sendiri ke subnet Anda untuk mengubah perilaku ini. Untuk informasi selengkapnya, lihat [Tabel rute subnet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#subnet-route-tables) di Panduan Pengguna Amazon VPC.
1. Lihat subnet saat ini di VPC Anda.
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
--query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
--output table
```
Contoh output adalah sebagai berikut.
```
----------------------------------------------------------------------
| DescribeSubnets |
+------------------+--------------------+----------------------------+
| AvailabilityZone | CidrBlock | SubnetId |
+------------------+--------------------+----------------------------+
| us-west-2d | 192.168.0.0/27 | subnet-example1 |
| us-west-2a | 192.168.0.32/27 | subnet-example2 |
| us-west-2a | 192.168.0.64/27 | subnet-example3 |
| us-west-2d | 192.168.0.96/27 | subnet-example4 |
| us-west-2a | 192.168.1.0/27 | subnet-example5 |
| us-west-2d | 192.168.1.32/27 | subnet-example6 |
+------------------+--------------------+----------------------------+
```
Anda dapat melihat subnet di blok `192.168.1.0` CIDR yang Anda buat berada di Availability Zone yang sama dengan subnet di blok CIDR. `192.168.0.0`
## Langkah 3: Konfigurasikan sumber daya Kubernetes
1. Atur variabel `AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG` lingkungan ke `true` dalam `aws-node` DaemonSet.
```
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
```
1. Ambil ID [grup keamanan klaster](sec-group-reqs.md) Anda dan simpan dalam variabel untuk digunakan pada langkah berikutnya. Amazon EKS secara otomatis membuat grup keamanan ini saat Anda membuat klaster.
```
cluster_security_group_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
```
1. Buat sumber daya `ENIConfig` khusus untuk setiap subnet yang ingin Anda gunakan untuk menerapkan Pod.
1. Buat file unik untuk setiap konfigurasi antarmuka jaringan.
Perintah berikut membuat `ENIConfig` file terpisah untuk dua subnet yang dibuat pada langkah sebelumnya. Nilai untuk `name` harus unik. Namanya sama dengan Availability Zone tempat subnet berada. Grup keamanan cluster ditugaskan ke file`ENIConfig`.
```
cat >$az_1.yaml <$az_2.yaml <
1. Buat peran IAM node.
1. Jalankan perintah berikut untuk membuat file JSON kebijakan kepercayaan IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Buat peran IAM dan simpan Amazon Resource Name (ARN) yang dikembalikan dalam variabel untuk digunakan di langkah selanjutnya.
```
node_role_arn=$(aws iam create-role --role-name myCustomNetworkingNodeRole --assume-role-policy-document file://"node-role-trust-relationship.json" \
--query Role.Arn --output text)
```
1. Lampirkan tiga kebijakan yang dikelola IAM yang diperlukan ke peran IAM.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name myCustomNetworkingNodeRole
```
**penting**
Untuk kesederhanaan dalam tutorial ini, kebijakan [Amazoneks\$1CNI\$1Policy dilampirkan ke peran](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) IAM node. Namun, dalam cluster produksi, kami merekomendasikan untuk melampirkan kebijakan ke peran IAM terpisah yang hanya digunakan dengan plugin Amazon VPC CNI untuk Kubernetes. Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).
1. Buat salah satu jenis grup node berikut. Untuk menentukan jenis instance yang ingin Anda terapkan, lihat[Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md). Untuk tutorial ini, selesaikan **template **Managed**, Without a launch atau dengan template peluncuran tanpa opsi yang ditentukan ID AMI**. Jika Anda akan menggunakan grup node untuk beban kerja produksi, maka sebaiknya Anda membiasakan diri dengan semua grup node [terkelola dan opsi grup node](create-managed-node-group.md) yang [dikelola sendiri sebelum menerapkan grup node](worker.md).
+ **Dikelola** - Terapkan grup node Anda menggunakan salah satu opsi berikut:
+ **Tanpa template peluncuran atau dengan template peluncuran tanpa ID AMI yang ditentukan** - Jalankan perintah berikut. Untuk tutorial ini, gunakan nilai contoh. Untuk grup node produksi, ganti semua nilai contoh dengan milik Anda sendiri. Nama grup node tidak boleh lebih dari 63 karakter. Itu harus dimulai dengan huruf atau digit, tetapi juga dapat menyertakan tanda hubung dan garis bawah untuk karakter yang tersisa.
```
aws eks create-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup \
--subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
```
+ **Dengan template peluncuran dengan ID AMI yang ditentukan**
1. Tentukan jumlah maksimum Pod yang direkomendasikan Amazon EKS untuk node Anda. Ikuti petunjuk di , tambahkan `--cni-custom-networking-enabled` ke langkah 3 dalam topik tersebut. Perhatikan output untuk digunakan pada langkah berikutnya.
1. Di template peluncuran Anda, tentukan ID AMI Amazon EKS yang dioptimalkan, atau AMI kustom yang dibuat dari AMI Amazon EKS yang dioptimalkan, lalu [terapkan grup node menggunakan templat peluncuran](launch-templates.md) dan berikan data pengguna berikut di template peluncuran. Data pengguna ini meneruskan argumen ke dalam `NodeConfig` spesifikasi. Untuk informasi selengkapnya NodeConfig, lihat [referensi NodeConfig API](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfig). Anda dapat mengganti `20` dengan nilai dari langkah sebelumnya (disarankan) atau nilai Anda sendiri.
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
...
kubelet:
config:
maxPods: 20
```
Jika Anda telah membuat AMI khusus yang tidak dibangun dari AMI Amazon EKS yang dioptimalkan, maka Anda perlu membuat konfigurasi sendiri.
+ **Dikelola sendiri**
1. Tentukan jumlah maksimum Pod yang direkomendasikan Amazon EKS untuk node Anda. Ikuti instruksi di, tambahkan `--cni-custom-networking-enabled` ke langkah 3 dalam topik itu. Perhatikan output untuk digunakan pada langkah berikutnya.
1. Menyebarkan grup node menggunakan instruksi di[Buat node Amazon Linux yang dikelola sendiri](launch-workers.md).
**catatan**
Jika Anda ingin node dalam klaster produksi mendukung jumlah Pod yang jauh lebih tinggi, jalankan skrip lagi. Juga, tambahkan `--cni-prefix-delegation-enabled` opsi ke perintah. Misalnya, `110` dikembalikan untuk tipe `m5.large` instance. Untuk petunjuk tentang cara mengaktifkan kemampuan ini, lihat[Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md). Anda dapat menggunakan kemampuan ini dengan jaringan khusus.
1. Pembuatan grup node membutuhkan waktu beberapa menit. Anda dapat memeriksa status pembuatan grup node terkelola dengan perintah berikut.
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
Jangan melanjutkan ke langkah berikutnya sampai output yang dikembalikan`ACTIVE`.
1. Untuk tutorialnya, Anda dapat melewati langkah ini.
Untuk cluster produksi, jika Anda tidak memberi nama yang sama `ENIConfigs` dengan Availability Zone yang Anda gunakan untuk mereka, maka Anda harus membubuhi anotasi node Anda dengan `ENIConfig` nama yang harus digunakan dengan node. Langkah ini tidak diperlukan jika Anda hanya memiliki satu subnet di setiap Availability Zone dan Anda menamai Anda `ENIConfigs` dengan nama yang sama dengan Availability Zones Anda. [Ini karena plugin Amazon VPC CNI untuk Kubernetes secara otomatis mengaitkan yang benar `ENIConfig` dengan node untuk Anda ketika Anda mengaktifkannya untuk melakukannya pada langkah sebelumnya.](#custom-networking-automatically-apply-eniconfig)
1. Dapatkan daftar node di cluster Anda.
```
kubectl get nodes
```
Contoh output adalah sebagai berikut.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-0-126.us-west-2.compute.internal Ready 8m49s v1.22.9-eks-810597c
ip-192-168-0-92.us-west-2.compute.internal Ready 8m34s v1.22.9-eks-810597c
```
1. Tentukan Availability Zone mana setiap node berada. Jalankan perintah berikut untuk setiap node yang dikembalikan pada langkah sebelumnya, mengganti alamat IP berdasarkan output sebelumnya.
```
aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
--query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'
```
Contoh output adalah sebagai berikut.
```
[
{
"AvailabilityZone": "us-west-2d",
"SubnetId": "subnet-Example5"
}
]
```
1. Anotasi setiap node dengan `ENIConfig` yang Anda buat untuk subnet ID dan Availability Zone. Anda hanya dapat membuat anotasi node dengan satu`ENIConfig`, meskipun beberapa node dapat dianotasi dengan yang sama. `ENIConfig` Ganti Contoh nilai dengan nilai Anda sendiri.
```
kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
```
1. Jika Anda memiliki node di klaster produksi dengan menjalankan Pod sebelum beralih menggunakan fitur jaringan kustom, selesaikan tugas-tugas berikut:
1. Pastikan Anda memiliki node yang tersedia yang menggunakan fitur jaringan khusus.
1. Cordon dan tiriskan node untuk mematikan Pod dengan anggun. Untuk informasi selengkapnya, lihat [Menguras Node dengan Aman](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) di dokumentasi Kubernetes.
1. Mengakhiri node. Jika node berada dalam grup node terkelola yang ada, Anda dapat menghapus grup node. Jalankan perintah berikut.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
Hanya simpul-simpul baru yang terdaftar dengan label `k8s.amazonaws.com/eniConfig` yang menggunakan fitur jaringan kustom.
1. Konfirmasikan bahwa Pod diberi alamat IP dari blok CIDR yang terkait dengan salah satu subnet yang Anda buat pada langkah sebelumnya.
```
kubectl get pods -A -o wide
```
Contoh output adalah sebagai berikut.
```
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-system aws-node-2rkn4 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system aws-node-k96wp 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
kube-system coredns-657694c6f4-smcgr 1/1 Running 0 56m 192.168.1.23 ip-192-168-0-92.us-west-2.compute.internal
kube-system coredns-657694c6f4-stwv9 1/1 Running 0 56m 192.168.1.28 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-jgshq 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
```
Anda dapat melihat bahwa Pod coredns diberi alamat IP dari blok `192.168.1.0` CIDR yang Anda tambahkan ke VPC Anda. Tanpa jaringan khusus, mereka akan diberi alamat dari blok `192.168.0.0` CIDR, karena itu adalah satu-satunya blok CIDR yang awalnya terkait dengan VPC.
Jika sebuah Pod `spec` berisi`hostNetwork=true`, itu akan diberikan alamat IP utama dari node. Itu tidak diberikan alamat dari subnet yang Anda tambahkan. Secara default, nilai ini diatur ke `false`. Nilai ini ditetapkan `true` untuk plugin Amazon VPC CNI `kube-proxy` dan Amazon untuk Pod Kubernetes (`aws-node`) yang berjalan di klaster Anda. Inilah sebabnya mengapa `aws-node` Pod `kube-proxy` dan plugin tidak diberi alamat 192.168.1.x pada output sebelumnya. Untuk informasi selengkapnya tentang `hostNetwork` pengaturan Pod, lihat [inti PodSpec v1 di referensi](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) API Kubernetes.
## Langkah 5: Hapus sumber daya tutorial
Setelah Anda menyelesaikan tutorial, kami sarankan Anda menghapus sumber daya yang Anda buat. Anda kemudian dapat menyesuaikan langkah-langkah untuk mengaktifkan jaringan khusus untuk klaster produksi.
1. Jika grup node yang Anda buat hanya untuk pengujian, maka hapuslah.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
1. Bahkan setelah output AWS CLI mengatakan bahwa cluster dihapus, proses penghapusan mungkin tidak benar-benar lengkap. Proses penghapusan memakan waktu beberapa menit. Konfirmasikan bahwa itu selesai dengan menjalankan perintah berikut.
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
Jangan lanjutkan sampai output yang dikembalikan mirip dengan output berikut.
```
An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
```
1. Jika grup node yang Anda buat hanya untuk pengujian, maka hapus peran IAM node.
1. Lepaskan kebijakan dari peran.
```
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy
```
1. Hapus peran.
```
aws iam delete-role --role-name myCustomNetworkingNodeRole
```
1. Hapus klaster .
```
aws eks delete-cluster --name my-custom-networking-cluster
```
Konfirmasikan cluster dihapus dengan perintah berikut.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status --output text
```
Ketika output yang mirip dengan berikut ini dikembalikan, cluster berhasil dihapus.
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-custom-networking-cluster.
```
1. Hapus peran IAM cluster.
1. Lepaskan kebijakan dari peran.
```
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
1. Hapus peran.
```
aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Hapus subnet yang Anda buat pada langkah sebelumnya.
```
aws ec2 delete-subnet --subnet-id $new_subnet_id_1
aws ec2 delete-subnet --subnet-id $new_subnet_id_2
```
1. Hapus VPC yang Anda buat.
```
aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc
```
# Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan
**Berlaku untuk**: Node Linux dan Windows dengan EC2 instans Amazon
**Berlaku untuk**: Subnet publik dan pribadi
Setiap EC2 instans Amazon mendukung jumlah maksimum antarmuka jaringan elastis dan jumlah maksimum alamat IP yang dapat ditetapkan untuk setiap antarmuka jaringan. Setiap node membutuhkan satu alamat IP untuk setiap antarmuka jaringan. Semua alamat IP lain yang tersedia dapat ditetapkan`Pods`. Masing-masing `Pod` membutuhkan alamat IP sendiri. Akibatnya, Anda mungkin memiliki node yang memiliki sumber daya komputasi dan memori yang tersedia, tetapi tidak dapat mengakomodasi tambahan `Pods` karena node telah kehabisan alamat IP untuk ditetapkan. `Pods`
Anda dapat meningkatkan jumlah alamat IP yang dapat ditetapkan `Pods` oleh node dengan menetapkan awalan IP, daripada menetapkan alamat IP sekunder individual ke node Anda. Setiap awalan mencakup beberapa alamat IP. Jika Anda tidak mengonfigurasi klaster untuk penetapan awalan IP, klaster Anda harus membuat lebih banyak panggilan antarmuka pemrograman EC2 aplikasi Amazon (API) untuk mengonfigurasi antarmuka jaringan dan alamat IP yang diperlukan untuk konektivitas Pod. Seiring pertumbuhan cluster ke ukuran yang lebih besar, frekuensi panggilan API ini dapat menyebabkan waktu peluncuran Pod dan instance yang lebih lama. Hal ini mengakibatkan penundaan penskalaan untuk memenuhi permintaan beban kerja yang besar dan runcing, dan menambah biaya dan overhead manajemen karena Anda perlu menyediakan cluster tambahan dan untuk memenuhi persyaratan penskalaan. VPCs Untuk informasi selengkapnya, lihat Ambang batas [skalabilitas Kubernetes pada](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md). GitHub
## Kompatibilitas dengan plugin Amazon VPC CNI untuk fitur Kubernetes
Anda dapat menggunakan awalan IP dengan fitur-fitur berikut:
+ IPv4 Terjemahan Alamat Jaringan Sumber - Untuk informasi lebih lanjut, lihat[Aktifkan akses internet keluar untuk Pod](external-snat.md).
+ IPv6 alamat ke klaster, Pod, dan layanan - Untuk informasi selengkapnya, lihat[Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md).
+ Membatasi lalu lintas menggunakan kebijakan jaringan Kubernetes - Untuk informasi selengkapnya, lihat. [Batasi lalu lintas Pod dengan kebijakan jaringan Kubernetes](cni-network-policy.md)
Daftar berikut memberikan informasi tentang pengaturan plugin Amazon VPC CNI yang berlaku. Untuk informasi selengkapnya tentang setiap setelan, lihat [amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) di GitHub.
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## Pertimbangan
Pertimbangkan hal berikut saat Anda menggunakan fitur ini:
+ Setiap jenis EC2 instans Amazon mendukung jumlah maksimum Pod. Jika grup node terkelola Anda terdiri dari beberapa tipe instans, jumlah Pod maksimum terkecil untuk sebuah instance di klaster diterapkan ke semua node dalam klaster.
+ Secara default, jumlah maksimum `Pods` yang dapat Anda jalankan pada node adalah 110, tetapi Anda dapat mengubah nomor itu. Jika Anda mengubah nomor dan memiliki grup node terkelola yang sudah ada, AMI berikutnya atau update template peluncuran grup node Anda akan menghasilkan node baru yang muncul dengan nilai yang diubah.
+ Saat beralih dari menetapkan alamat IP ke menetapkan awalan IP, kami menyarankan Anda membuat grup node baru untuk meningkatkan jumlah alamat IP yang tersedia, daripada melakukan penggantian bergulir node yang ada. Menjalankan Pod pada node yang memiliki alamat IP dan prefiks yang ditetapkan dapat menyebabkan ketidakkonsistenan dalam kapasitas alamat IP yang diiklankan, yang berdampak pada beban kerja future pada node. Untuk cara yang disarankan dalam melakukan transisi, lihat [Mode Delegasi Awalan untuk Linux di Panduan](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html) *Praktik Terbaik Amazon EKS*.
+ Cakupan grup keamanan berada pada tingkat simpul - Untuk informasi selengkapnya, lihat Grup [keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
+ Awalan IP yang ditetapkan ke antarmuka jaringan mendukung kepadatan Pod yang tinggi per node dan memiliki waktu peluncuran terbaik.
+ Awalan IP dan alamat IP dikaitkan dengan antarmuka jaringan EC2 elastis Amazon standar. Pod yang membutuhkan grup keamanan tertentu diberi alamat IP utama dari antarmuka jaringan cabang. Anda dapat mencampur Pod yang mendapatkan alamat IP, atau alamat IP dari awalan IP dengan Pod yang mendapatkan antarmuka jaringan cabang pada node yang sama.
+ Untuk cluster dengan node Linux saja.
+ Setelah Anda mengonfigurasi add-on untuk menetapkan awalan ke antarmuka jaringan, Anda tidak dapat menurunkan versi plugin Amazon VPC CNI untuk add-on Kubernetes ke versi yang `1.9.0` lebih rendah dari (`1.10.1`atau) tanpa menghapus semua node di semua grup node di cluster Anda.
+ Jika Anda juga menggunakan grup keamanan untuk Pod, dengan `POD_SECURITY_GROUP_ENFORCING_MODE` = `standard` dan `AWS_VPC_K8S_CNI_EXTERNALSNAT` =`false`, ketika Pod Anda berkomunikasi dengan titik akhir di luar VPC Anda, grup keamanan node akan digunakan, bukan grup keamanan apa pun yang telah Anda tetapkan ke Pod Anda.
Jika Anda juga menggunakan [grup keamanan untuk Pod](security-groups-for-pods.md), dengan `POD_SECURITY_GROUP_ENFORCING_MODE` =`strict`, saat `Pods` berkomunikasi dengan titik akhir di luar VPC, grup keamanan `Pod’s` akan digunakan.
# Tingkatkan alamat IP yang tersedia untuk node Amazon EKS Anda
Anda dapat meningkatkan jumlah alamat IP yang dapat ditetapkan node ke Pod dengan menetapkan awalan IP, daripada menetapkan alamat IP sekunder individual ke node Anda.
## Prasyarat
+ Anda membutuhkan cluster yang ada. Untuk menyebarkan satu, lihat[Buat kluster Amazon EKS](create-cluster.md).
+ Subnet tempat node Amazon EKS Anda berada harus memiliki blok yang cukup berdekatan `/28` (untuk `IPv4` cluster) atau (untuk cluster) Classless Inter-Domain `IPv6` Routing `/80` (CIDR). Anda hanya dapat memiliki node Linux dalam sebuah `IPv6` cluster. Menggunakan awalan IP dapat gagal jika alamat IP tersebar di seluruh subnet CIDR. Sebaiknya lakukan hal berikut:
+ Menggunakan reservasi CIDR subnet sehingga meskipun ada alamat IP dalam rentang cadangan masih digunakan, setelah dirilis, alamat IP tidak dipindahkan. Ini memastikan bahwa awalan tersedia untuk alokasi tanpa segmentasi.
+ Gunakan subnet baru yang secara khusus digunakan untuk menjalankan beban kerja yang awalan IP ditetapkan. Beban kerja Windows dan Linux dapat berjalan di subnet yang sama saat menetapkan awalan IP.
+ Untuk menetapkan awalan IP ke node Anda, node Anda harus berbasis Nitro. AWS Instans yang tidak berbasis Nitro terus mengalokasikan alamat IP sekunder individual, tetapi memiliki jumlah alamat IP yang jauh lebih rendah untuk ditetapkan ke Pod daripada instans berbasis Nitro.
+ **Untuk cluster dengan node Linux saja** - Jika cluster Anda dikonfigurasi untuk `IPv4` keluarga, Anda harus memiliki versi `1.9.0` atau yang lebih baru dari plugin Amazon VPC CNI untuk add-on Kubernetes diinstal. Anda dapat memeriksa versi Anda saat ini dengan perintah berikut.
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
Jika cluster Anda dikonfigurasi untuk `IPv6` keluarga, Anda harus menginstal `1.10.1` versi add-on. Jika versi plugin Anda lebih awal dari versi yang diperlukan, Anda harus memperbaruinya. Untuk informasi selengkapnya, lihat bagian update [Assign IPs to Pod dengan Amazon VPC CNI](managing-vpc-cni.md).
+ **Untuk cluster dengan node Windows saja**
+ Anda harus mengaktifkan dukungan Windows untuk cluster Anda. Untuk informasi selengkapnya, lihat [Menerapkan node Windows pada kluster EKS](windows-support.md).
## Tetapkan awalan alamat IP ke node
Konfigurasikan cluster Anda untuk menetapkan awalan alamat IP ke node. Selesaikan prosedur yang cocok dengan sistem operasi node Anda.
### Linux
1. Aktifkan parameter untuk menetapkan awalan ke antarmuka jaringan untuk Amazon VPC CNI. DaemonSet Saat Anda menerapkan klaster, versi `1.10.1` atau yang lebih baru dari plugin Amazon VPC CNI untuk add-on Kubernetes akan di-deploy dengannya. Jika Anda membuat cluster dengan `IPv6` keluarga, pengaturan ini disetel ke secara `true` default. Jika Anda membuat cluster dengan `IPv4` keluarga, pengaturan ini disetel ke secara `false` default.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**penting**
Bahkan jika subnet Anda memiliki alamat IP yang tersedia, jika subnet tidak memiliki `/28` blok yang berdekatan, Anda akan melihat kesalahan berikut di plugin Amazon VPC CNI untuk log Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Hal ini dapat terjadi karena fragmentasi alamat IP sekunder yang ada tersebar di subnet. Untuk mengatasi kesalahan ini, buat subnet baru dan luncurkan Pod di sana, atau gunakan reservasi CIDR EC2 subnet Amazon untuk memesan ruang di dalam subnet untuk digunakan dengan penetapan awalan. Untuk informasi selengkapnya, lihat [Reservasi CIDR Subnet](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) di Panduan Pengguna Amazon VPC.
1. Jika Anda berencana untuk menerapkan grup node terkelola tanpa template peluncuran, atau dengan template peluncuran yang belum Anda tentukan ID AMI, dan Anda menggunakan versi plugin Amazon VPC CNI untuk Kubernetes pada atau lebih baru dari versi yang tercantum dalam prasyarat, lalu lewati ke langkah berikutnya. Grup node terkelola secara otomatis menghitung jumlah maksimum Pod untuk Anda.
Jika Anda menerapkan grup node yang dikelola sendiri atau grup node terkelola dengan template peluncuran yang telah Anda tentukan ID AMI, Anda harus menentukan jumlah maksimum Pod yang direkomendasikan Amazon EKS untuk node Anda. Ikuti petunjuk di , tambahkan `--cni-prefix-delegation-enabled` ke langkah 3. Perhatikan output untuk digunakan di langkah selanjutnya.
**penting**
Grup node terkelola memberlakukan jumlah maksimum pada nilai. `maxPods` Untuk contoh dengan kurang dari 30 v CPUs jumlah maksimum adalah 110 dan untuk semua contoh lainnya jumlah maksimum adalah 250. Jumlah maksimum ini diterapkan apakah delegasi awalan diaktifkan atau tidak.
1. Jika Anda menggunakan cluster yang dikonfigurasi`IPv6`, lewati ke langkah berikutnya.
Tentukan parameter di salah satu opsi berikut. Untuk menentukan opsi mana yang tepat untuk Anda dan nilai apa yang akan diberikan untuknya, lihat [WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET, dan MINIMUM\$1IP\$1TARGET aktif](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md). GitHub
Anda dapat mengganti nilai contoh dengan nilai lebih besar dari nol.
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET`atau `MINIMUM_IP_TARGET` — Jika salah satu nilai ditetapkan, itu akan menggantikan nilai yang ditetapkan untuk. `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. Buat salah satu jenis grup node berikut dengan setidaknya satu jenis instans Amazon EC2 Nitro Amazon Linux 2023. Untuk daftar jenis instans Nitro, lihat [Instans yang dibangun di Sistem Nitro di Panduan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) Pengguna Amazon EC2 . Kemampuan ini tidak didukung pada Windows. Untuk opsi yang disertakan*110*, ganti dengan nilai dari langkah 3 (disarankan), atau nilai Anda sendiri.
+ **Dikelola sendiri** — Menerapkan grup node menggunakan instruksi di [Buat node Amazon Linux yang dikelola](launch-workers.md) sendiri. Sebelum membuat CloudFormation tumpukan, buka file template dan sesuaikan `UserData` di `NodeLaunchTemplate` menjadi seperti berikut
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
Jika Anda menggunakan `eksctl` untuk membuat grup node, Anda dapat menggunakan perintah berikut.
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **Dikelola** - Terapkan grup node Anda menggunakan salah satu opsi berikut:
+ **Tanpa template peluncuran atau dengan template peluncuran tanpa ID AMI yang ditentukan** — Selesaikan prosedur di [Buat grup node terkelola untuk klaster Anda](create-managed-node-group.md). Grup node terkelola secara otomatis menghitung `max-pods` nilai yang direkomendasikan Amazon EKS untuk Anda.
+ **Dengan template peluncuran dengan ID AMI tertentu** — Dalam template peluncuran Anda, tentukan ID AMI Amazon EKS yang dioptimalkan, atau AMI kustom yang dibuat dari AMI Amazon EKS yang dioptimalkan, lalu [terapkan grup node menggunakan template peluncuran](launch-templates.md) dan berikan data pengguna berikut di template peluncuran. Data pengguna ini melewati `NodeConfig` objek yang akan dibaca oleh `nodeadm` alat pada node. Untuk informasi selengkapnya`nodeadm`, lihat [dokumentasi nodeadm](https://awslabs.github.io/amazon-eks-ami/nodeadm).
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
Jika Anda menggunakan `eksctl` untuk membuat grup node, Anda dapat menggunakan perintah berikut.
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
Jika Anda telah membuat AMI kustom yang tidak dibangun dari AMI Amazon EKS yang dioptimalkan, maka Anda perlu membuat konfigurasi sendiri.
**catatan**
Jika Anda juga ingin menetapkan alamat IP ke Pod dari subnet yang berbeda dari instans, maka Anda perlu mengaktifkan kapabilitas pada langkah ini. Untuk informasi selengkapnya, lihat [Menerapkan Pod di subnet alternatif dengan jaringan khusus](cni-custom-network.md).
### Windows
1. Aktifkan penugasan awalan IP.
1. Buka `amazon-vpc-cni` `ConfigMap` untuk mengedit.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Tambahkan baris berikut ke `data` bagian.
```
enable-windows-prefix-delegation: "true"
```
1. Simpan file dan tutup editor.
1. Konfirmasikan bahwa baris telah ditambahkan ke`ConfigMap`.
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
Jika output yang dikembalikan tidak`true`, maka mungkin ada kesalahan. Coba selesaikan langkahnya lagi.
**penting**
Bahkan jika subnet Anda memiliki alamat IP yang tersedia, jika subnet tidak memiliki `/28` blok yang berdekatan, Anda akan melihat kesalahan berikut di plugin Amazon VPC CNI untuk log Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Hal ini dapat terjadi karena fragmentasi alamat IP sekunder yang ada tersebar di subnet. Untuk mengatasi kesalahan ini, buat subnet baru dan luncurkan Pod di sana, atau gunakan reservasi CIDR EC2 subnet Amazon untuk memesan ruang di dalam subnet untuk digunakan dengan penetapan awalan. Untuk informasi selengkapnya, lihat [Reservasi CIDR Subnet](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) di Panduan Pengguna Amazon VPC.
1. (Opsional) Tentukan konfigurasi tambahan untuk mengontrol perilaku pra-penskalaan dan penskalaan dinamis untuk klaster Anda. Untuk informasi selengkapnya, lihat [Opsi konfigurasi dengan mode Delegasi Awalan di Windows](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md) aktif. GitHub
1. Buka `amazon-vpc-cni` `ConfigMap` untuk mengedit.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Ganti nilai contoh dengan nilai lebih besar dari nol dan tambahkan entri yang Anda butuhkan ke `data` bagian`ConfigMap`. Jika Anda menetapkan nilai untuk salah satu `warm-ip-target` atau`minimum-ip-target`, nilai akan menggantikan nilai yang ditetapkan untuk. `warm-prefix-target`
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. Simpan file dan tutup editor.
1. Buat grup node Windows dengan setidaknya satu jenis instans Amazon EC2 Nitro. Untuk daftar jenis instans Nitro, lihat [Instans yang dibangun di Sistem Nitro di Panduan](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) Pengguna Amazon EC2 . Secara default, jumlah maksimum Pod yang dapat Anda deploy ke sebuah node adalah 110. Jika Anda ingin menambah atau mengurangi angka itu, tentukan yang berikut ini dalam data pengguna untuk konfigurasi bootstrap. Ganti *max-pods-quantity* dengan nilai pod maks Anda.
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
Jika Anda menerapkan grup node terkelola, konfigurasi ini perlu ditambahkan dalam template peluncuran. Untuk informasi selengkapnya, lihat [Sesuaikan node terkelola dengan templat peluncuran](launch-templates.md). Untuk informasi selengkapnya tentang parameter konfigurasi untuk skrip bootstrap Windows, lihat[Parameter konfigurasi skrip bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Tentukan Pod maksimal dan alamat IP yang tersedia
1. Setelah node Anda di-deploy, lihat node di cluster Anda.
```
kubectl get nodes
```
Contoh output adalah sebagai berikut.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. Jelaskan salah satu node untuk menentukan nilai `max-pods` untuk node dan jumlah alamat IP yang tersedia. Ganti *192.168.30.193* dengan `IPv4` alamat atas nama salah satu node Anda yang dikembalikan pada output sebelumnya.
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
Contoh output adalah sebagai berikut.
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
Pada output sebelumnya, `110` adalah jumlah maksimum Pod yang Kubernetes akan deploy ke node, meskipun *144* alamat IP tersedia.
# Menetapkan grup keamanan ke Pod individual
**Berlaku untuk**: Node Linux dengan EC2 instans Amazon
**Berlaku untuk**: Subnet pribadi
Grup keamanan untuk Pod mengintegrasikan grup EC2 keamanan Amazon dengan Kubernetes Pods. Anda dapat menggunakan grup EC2 keamanan Amazon untuk menentukan aturan yang memungkinkan lalu lintas jaringan masuk dan keluar ke dan dari Pod yang Anda terapkan ke node yang berjalan di banyak jenis EC2 instans Amazon dan Fargate. Untuk penjelasan rinci tentang kemampuan ini, lihat posting blog [Introducing security groups for Pods](https://aws.amazon.com/blogs/containers/introducing-security-groups-for-pods).
## Kompatibilitas dengan plugin Amazon VPC CNI untuk fitur Kubernetes
Anda dapat menggunakan grup keamanan untuk Pod dengan fitur berikut:
+ IPv4 Terjemahan Alamat Jaringan Sumber - Untuk informasi lebih lanjut, lihat[Aktifkan akses internet keluar untuk Pod](external-snat.md).
+ IPv6 alamat ke klaster, Pod, dan layanan - Untuk informasi selengkapnya, lihat[Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md).
+ Membatasi lalu lintas menggunakan kebijakan jaringan Kubernetes - Untuk informasi selengkapnya, lihat. [Batasi lalu lintas Pod dengan kebijakan jaringan Kubernetes](cni-network-policy.md)
## Pertimbangan-pertimbangan
Sebelum menerapkan grup keamanan untuk Pod, pertimbangkan batasan dan ketentuan berikut:
+ Grup keamanan untuk Pod tidak dapat digunakan dengan node Windows atau Mode Otomatis EKS.
+ Grup keamanan untuk Pod dapat digunakan dengan cluster yang dikonfigurasi untuk `IPv6` keluarga yang berisi EC2 node Amazon dengan menggunakan plugin Amazon VPC CNI versi 1.16.0 atau yang lebih baru. Anda dapat menggunakan grup keamanan untuk Pod dengan cluster yang mengonfigurasi `IPv6` keluarga yang hanya berisi node Fargate dengan menggunakan plugin Amazon VPC CNI versi 1.7.7 atau yang lebih baru. Untuk informasi selengkapnya, lihat [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md)
+ Grup keamanan untuk Pod didukung oleh sebagian besar keluarga EC2 instans Amazon [berbasis Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances), meskipun tidak oleh semua generasi keluarga. Misalnya, keluarga dan generasi `m5` `c5``r5`, `m6g``c6g`,,,, dan `r6g` contoh didukung. Tidak ada jenis instance dalam `t` keluarga yang didukung. Untuk daftar lengkap jenis instans yang didukung, lihat file [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/v1.5.0/pkg/aws/vpc/limits.go) di. GitHub Node Anda harus menjadi salah satu jenis instance terdaftar yang ada `IsTrunkingCompatible: true` di file itu.
+ Jika Anda menggunakan jaringan kustom dan grup keamanan untuk Pod bersama-sama, grup keamanan yang ditentukan oleh grup keamanan untuk Pod akan digunakan sebagai ganti grup keamanan yang ditentukan dalam`ENIConfig`.
+ Jika Anda menggunakan versi `1.10.2` atau versi sebelumnya dari plugin Amazon VPC CNI dan Anda menyertakan `terminationGracePeriodSeconds` setelan dalam spesifikasi Pod Anda, nilai untuk setelan tidak bisa nol.
+ Jika Anda menggunakan versi `1.10` atau sebelumnya dari plugin Amazon VPC CNI, atau versi `1.11` dengan `POD_SECURITY_GROUP_ENFORCING_MODE` =, yang merupakan setelan default`strict`, maka jenis layanan Kubernetes `NodePort` dan `LoadBalancer` menggunakan target instance dengan `externalTrafficPolicy` set to `Local` tidak didukung dengan Pod yang Anda tetapkan ke grup keamanan. Untuk informasi selengkapnya tentang cara menggunakan penyeimbang beban dengan target instans, lihat [Rute lalu lintas TCP dan UDP dengan Network Load Balancers](network-load-balancing.md).
+ Jika Anda menggunakan versi `1.10` atau versi sebelumnya dari plugin Amazon VPC CNI atau versi `1.11` dengan `POD_SECURITY_GROUP_ENFORCING_MODE` =`strict`, yang merupakan pengaturan default, NAT sumber dinonaktifkan untuk lalu lintas keluar dari Pod dengan grup keamanan yang ditetapkan sehingga aturan grup keamanan keluar diterapkan. Untuk mengakses internet, Pod dengan grup keamanan yang ditetapkan harus diluncurkan pada node yang digunakan dalam subnet pribadi yang dikonfigurasi dengan gateway atau instance NAT. Pod dengan grup keamanan yang ditugaskan dan di-deploy ke subnet publik tidak dapat mengakses internet.
Jika Anda menggunakan versi `1.11` atau versi yang lebih baru dari plugin dengan `POD_SECURITY_GROUP_ENFORCING_MODE` =`standard`, lalu lintas Pod yang ditujukan untuk di luar VPC diterjemahkan ke alamat IP antarmuka jaringan utama instans. Untuk lalu lintas ini, aturan dalam grup keamanan untuk antarmuka jaringan utama digunakan, bukan aturan dalam grup keamanan Pod.
+ Untuk menggunakan kebijakan jaringan Calico dengan Pod yang memiliki grup keamanan terkait, Anda harus menggunakan versi `1.11.0` atau yang lebih baru dari plugin Amazon VPC CNI dan set =. `POD_SECURITY_GROUP_ENFORCING_MODE` `standard` Jika tidak, arus lalu lintas ke dan dari Pod dengan grup keamanan terkait tidak dikenakan penegakan kebijakan jaringan Calico dan terbatas pada penegakan kelompok EC2 keamanan Amazon saja. Untuk memperbarui versi CNI VPC Amazon Anda, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md)
+ Pod yang berjalan di EC2 node Amazon yang menggunakan grup keamanan dalam klaster yang [NodeLocal DNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)digunakan hanya didukung dengan versi `1.11.0` atau yang lebih baru dari plugin Amazon VPC CNI dan dengan =. `POD_SECURITY_GROUP_ENFORCING_MODE` `standard` Untuk memperbarui versi plugin Amazon VPC CNI Anda, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md)
+ Grup keamanan untuk Pod dapat menyebabkan latensi startup Pod yang lebih tinggi untuk Pod dengan churn tinggi. Hal ini disebabkan pembatasan tingkat dalam pengontrol sumber daya.
+ Cakupan grup EC2 keamanan berada di tingkat POD - Untuk informasi selengkapnya, lihat Grup [keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
Jika Anda menetapkan `POD_SECURITY_GROUP_ENFORCING_MODE=standard` dan`AWS_VPC_K8S_CNI_EXTERNALSNAT=false`, lalu lintas yang ditujukan untuk titik akhir di luar VPC menggunakan grup keamanan node, bukan grup keamanan Pod.
# Konfigurasikan plugin Amazon VPC CNI untuk Kubernetes untuk grup keamanan untuk Pod Amazon EKS
Jika Anda menggunakan Pod dengan EC2 instans Amazon, Anda perlu mengonfigurasi plugin Amazon VPC CNI untuk Kubernetes untuk grup keamanan
Jika Anda hanya menggunakan Pod Fargate, dan tidak memiliki EC2 node Amazon di klaster Anda, lihat. [Menggunakan kebijakan grup keamanan untuk Amazon EKS Pod](sg-pods-example-deployment.md)
1. Periksa plugin Amazon VPC CNI Anda saat ini untuk versi Kubernetes dengan perintah berikut:
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Contoh output adalah sebagai berikut.
```
v1.7.6
```
Jika plugin Amazon VPC CNI Anda untuk versi Kubernetes lebih awal dari`1.7.7`, maka perbarui plugin ke versi atau yang lebih baru. `1.7.7` Untuk informasi selengkapnya, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md)
1. Tambahkan kebijakan IAM terkelola [Amazon EKSVPCResource Controller](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSVPCResourceController) ke [peran klaster](cluster-iam-role.md#create-service-role) yang terkait dengan kluster Amazon EKS Anda. Kebijakan ini memungkinkan peran untuk mengelola antarmuka jaringan, alamat IP pribadi mereka, dan lampiran serta detasemen mereka ke dan dari instance jaringan.
1. Ambil nama peran IAM cluster Anda dan simpan dalam variabel. Ganti *my-cluster* dengan nama klaster Anda.
```
cluster_role=$(aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2)
```
1. Lampirkan kebijakan pada peran tersebut.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
```
1. Aktifkan add-on Amazon VPC CNI untuk mengelola antarmuka jaringan untuk Pod dengan menyetel variabel ke dalam`ENABLE_POD_ENI`. `true` `aws-node` DaemonSet Setelah pengaturan ini diatur ke`true`, untuk setiap node di cluster add-on membuat sumber daya `cninode` khusus. Pengendali sumber daya VPC membuat dan melampirkan satu antarmuka jaringan khusus yang disebut *antarmuka jaringan trunk* dengan deskripsi `aws-k8s-trunk-eni`.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true
```
**catatan**
Antarmuka jaringan trunk termasuk dalam jumlah maksimum antarmuka jaringan yang didukung oleh tipe instans. Untuk daftar jumlah maksimum antarmuka jaringan yang didukung oleh setiap jenis instans, lihat [alamat IP per antarmuka jaringan per jenis instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) di *Panduan EC2 Pengguna Amazon*. Jika simpul Anda sudah memiliki jumlah maksimum antarmuka jaringan standar yang terlampir padanya, maka pengendali sumber daya VPC akan menyimpan sebuah ruang. Anda harus menurunkan skala Pod yang sedang berjalan agar pengontrol dapat melepaskan dan menghapus antarmuka jaringan standar, membuat antarmuka jaringan trunk, dan melampirkannya ke instance.
1. Anda dapat melihat node mana yang memiliki sumber daya `CNINode` khusus dengan perintah berikut. Jika `No resources found` dikembalikan, maka tunggu beberapa detik dan coba lagi. Langkah sebelumnya memerlukan restart plugin Amazon VPC CNI untuk Kubernetes Pods, yang membutuhkan waktu beberapa detik.
```
kubectl get cninode -A
NAME FEATURES
ip-192-168-64-141.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
ip-192-168-7-203.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
```
Jika Anda menggunakan versi VPC CNI yang lebih lama dari`1.15`, label node digunakan sebagai pengganti sumber daya khusus. `CNINode` Anda dapat melihat node mana yang memiliki label node `aws-k8s-trunk-eni` diatur `true` dengan perintah berikut. Jika `No resources found` dikembalikan, maka tunggu beberapa detik dan coba lagi. Langkah sebelumnya memerlukan restart plugin Amazon VPC CNI untuk Kubernetes Pods, yang membutuhkan waktu beberapa detik.
```
kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true
```
Setelah antarmuka jaringan trunk dibuat, Pod diberi alamat IP sekunder dari trunk atau antarmuka jaringan standar. Antarmuka trunk secara otomatis dihapus jika simpul dihapus.
Saat Anda menerapkan grup keamanan untuk Pod di langkah selanjutnya, pengontrol sumber daya VPC membuat antarmuka jaringan khusus yang disebut antarmuka *jaringan cabang dengan* deskripsi `aws-k8s-branch-eni` dan mengaitkan grup keamanan ke Pod tersebut. Antarmuka jaringan cabang dibuat sebagai tambahan dari antarmuka jaringan standar dan trunk yang terlampir pada simpul.
Jika Anda menggunakan probe keaktifan atau kesiapan, maka Anda juga perlu menonaktifkan *demux awal TCP*, sehingga `kubelet` dapat terhubung ke Pod pada antarmuka jaringan cabang menggunakan TCP. Untuk menonaktifkan *TCP demux awal*, jalankan perintah berikut:
```
kubectl patch daemonset aws-node -n kube-system \
-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
```
**catatan**
Jika Anda menggunakan `1.11.0` atau yang lebih baru dari plugin Amazon VPC CNI untuk Kubernetes add-on dan set `POD_SECURITY_GROUP_ENFORCING_MODE` =`standard`, seperti yang dijelaskan pada langkah berikutnya, maka Anda tidak perlu menjalankan perintah sebelumnya.
1. Jika klaster Anda menggunakan`NodeLocal DNSCache`, atau Anda ingin menggunakan kebijakan jaringan Calico dengan Pod yang memiliki grup keamanan sendiri, atau Anda memiliki jenis layanan Kubernetes `NodePort` dan `LoadBalancer` menggunakan target instans dengan `externalTrafficPolicy` set ke Pod yang ingin Anda tetapkan ke `Local` grup keamanan, maka Anda harus menggunakan `1.11.0` versi atau yang lebih baru dari plugin Amazon VPC CNI untuk add-on Kubernetes, dan Anda harus mengaktifkan pengaturan berikut:
```
kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
```
PENTING: **Aturan grup keamanan Pod tidak diterapkan pada lalu lintas antar Pod atau antara Pod dan layanan, seperti `kubelet` atau`nodeLocalDNS`, yang berada di node yang sama. Pod yang menggunakan grup keamanan berbeda pada node yang sama tidak dapat berkomunikasi karena mereka dikonfigurasi dalam subnet yang berbeda, dan routing dinonaktifkan di antara subnet ini.** Lalu lintas keluar dari Pod ke alamat di luar VPC adalah alamat jaringan yang diterjemahkan ke alamat IP antarmuka jaringan utama instans (kecuali jika Anda juga `AWS_VPC_K8S_CNI_EXTERNALSNAT=true` telah menyetelnya). Untuk lalu lintas ini, aturan dalam grup keamanan untuk antarmuka jaringan utama digunakan, bukan aturan dalam grup keamanan Pod. \$1\$1 Agar pengaturan ini diterapkan pada Pod yang ada, Anda harus me-restart Pod atau node tempat Pod berjalan.
1. Untuk melihat cara menggunakan kebijakan grup keamanan untuk Pod Anda, lihat[Menggunakan kebijakan grup keamanan untuk Amazon EKS Pod](sg-pods-example-deployment.md).
# Menggunakan kebijakan grup keamanan untuk Amazon EKS Pod
Untuk menggunakan grup keamanan untuk Pod, Anda harus memiliki grup keamanan yang sudah ada. Langkah-langkah berikut menunjukkan cara menggunakan kebijakan grup keamanan untuk sebuah Pod. Kecuali dinyatakan lain, selesaikan semua langkah dari terminal yang sama karena variabel digunakan dalam langkah-langkah berikut yang tidak bertahan di seluruh terminal.
Jika Anda memiliki Pod dengan instans Amazon EC2, Anda harus mengonfigurasi plugin sebelum menggunakan prosedur ini. Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk Kubernetes untuk grup keamanan untuk Pod Amazon EKS](security-groups-pods-deployment.md).
1. Buat namespace Kubernetes untuk menyebarkan sumber daya. Anda dapat mengganti *my-namespace* dengan nama namespace yang ingin Anda gunakan.
```
kubectl create namespace my-namespace
```
1. Menerapkan Amazon EKS `SecurityGroupPolicy` ke cluster Anda.
1. Salin konten berikut ke perangkat Anda. Anda dapat mengganti *podSelector* dengan `serviceAccountSelector` jika Anda lebih suka memilih Pod berdasarkan label akun layanan. Anda harus menentukan satu selektor atau yang lainnya. Sebuah kosong `podSelector` (contoh:`podSelector: {}`) memilih semua Pod di namespace. Anda dapat *my-role* mengubah nama peran Anda. `serviceAccountSelector` yang kosong memilih semua akun layanan di namespace. Anda dapat mengganti *my-security-group-policy* dengan nama untuk Anda `SecurityGroupPolicy` dan *my-namespace* dengan namespace yang ingin Anda buat. `SecurityGroupPolicy`
Anda harus mengganti *my\$1pod\$1security\$1group\$1id* dengan ID grup keamanan yang ada. Jika Anda tidak memiliki grup keamanan yang ada, maka Anda harus membuatnya. Untuk informasi selengkapnya, lihat [Grup Keamanan Amazon EC2 untuk instans Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) di [Panduan Pengguna Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/). Anda dapat menentukan 1-5 grup IDs keamanan. Jika Anda menentukan lebih dari satu ID, maka kombinasi semua aturan di semua grup keamanan akan efektif untuk Pod yang dipilih.
```
cat >my-security-group-policy.yaml <sample-application.yaml <
my-deployment-5df6f7687b-j9fl4 1/1 Running 0 7m51s 192.168.70.145 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-rjxcz 1/1 Running 0 7m51s 192.168.73.207 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-zmb42 1/1 Running 0 7m51s 192.168.63.27 ip-192-168-33-28.region-code.compute.internal
```
**catatan**
Coba tips ini jika ada Pod yang macet.
Jika ada Pod yang macet dalam `Waiting` status, maka jalankan`kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace `. Jika Anda melihatnya`Insufficient permissions: Unable to create Elastic Network Interface.`, konfirmasikan bahwa Anda menambahkan kebijakan IAM ke peran klaster IAM di langkah sebelumnya.
Jika ada Pod yang terjebak dalam `Pending` status, konfirmasikan bahwa jenis instance node Anda terdaftar di [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/aws/vpc/limits.go) dan bahwa produk dari jumlah maksimum antarmuka jaringan cabang yang didukung oleh tipe instance dikalikan kali jumlah node dalam grup node Anda belum terpenuhi. Misalnya, sebuah instans `m5.large` mendukung sembilan antarmuka jaringan cabang. Jika grup simpul Anda memiliki lima simpul, maka maksimum 45 antarmuka jaringan cabang dapat dibuat untuk grup simpul. Pod ke-46 yang Anda coba gunakan akan berada dalam `Pending` status sampai Pod lain yang memiliki grup keamanan terkait dihapus.
Jika Anda menjalankan `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace ` dan melihat pesan yang serupa dengan pesan berikut, maka dapat diabaikan dengan aman. Pesan ini mungkin muncul ketika plugin Amazon VPC CNI untuk Kubernetes mencoba mengatur jaringan host dan gagal saat antarmuka jaringan sedang dibuat. Plugin mencatat peristiwa ini sampai antarmuka jaringan dibuat.
```
Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "e24268322e55c8185721f52df6493684f6c2c3bf4fd59c9c121fd4cdc894579f" network for Pod "my-deployment-5df6f7687b-4fbjm": networkPlugin
cni failed to set up Pod "my-deployment-5df6f7687b-4fbjm-c89wx_my-namespace" network: add cmd: failed to assign an IP address to container
```
Anda tidak dapat melebihi jumlah maksimum Pod yang dapat dijalankan pada tipe instans. Untuk daftar jumlah maksimum Pod yang dapat Anda jalankan pada setiap jenis instance, lihat [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) di. GitHub Saat Anda menghapus Pod yang memiliki grup keamanan terkait, atau menghapus node tempat Pod berjalan, pengontrol sumber daya VPC akan menghapus antarmuka jaringan cabang. Jika Anda menghapus klaster dengan Pod menggunakan Pod untuk grup keamanan, pengontrol tidak akan menghapus antarmuka jaringan cabang, jadi Anda harus menghapusnya sendiri. Untuk informasi tentang cara menghapus antarmuka jaringan, lihat [Menghapus antarmuka jaringan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#delete_eni) di Panduan Pengguna Amazon EC2.
1. Di terminal terpisah, tempelkan ke salah satu Pod. Untuk sisa topik ini, terminal ini disebut sebagai`TerminalB`. Ganti *5df6f7687b-4fbjm* dengan ID salah satu Pod yang dikembalikan dalam output Anda dari langkah sebelumnya.
```
kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
```
1. Dari shell masuk`TerminalB`, konfirmasikan bahwa aplikasi sampel berfungsi.
```
curl my-app
```
Contoh output adalah sebagai berikut.
```
Welcome to nginx!
[...]
```
Anda menerima output karena semua Pod yang menjalankan aplikasi dikaitkan dengan grup keamanan yang Anda buat. Grup tersebut berisi aturan yang memungkinkan semua lalu lintas di antara semua Pod yang terkait dengan grup keamanan. Lalu lintas DNS diizinkan keluar dari grup keamanan tersebut ke grup keamanan klaster, yang terkait dengan node Anda. Node menjalankan Pod CoreDNS, yang mana Pod Anda melakukan pencarian nama.
1. Dari`TerminalA`, hapus aturan grup keamanan yang memungkinkan komunikasi DNS ke grup keamanan klaster dari grup keamanan Anda. Jika Anda tidak menambahkan aturan DNS ke grup keamanan klaster pada langkah sebelumnya, ganti *\$1my\$1cluster\$1security\$1group\$1id* dengan ID grup keamanan tempat Anda membuat aturan.
```
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_tcp_rule_id
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_udp_rule_id
```
1. Dari`TerminalB`, coba akses aplikasi lagi.
```
curl my-app
```
Contoh output adalah sebagai berikut.
```
curl: (6) Could not resolve host: my-app
```
Upaya gagal karena Pod tidak lagi dapat mengakses Pod CoreDNS, yang memiliki grup keamanan klaster yang terkait dengannya. Grup keamanan klaster tidak lagi memiliki aturan grup keamanan yang memungkinkan komunikasi DNS dari grup keamanan yang terkait dengan Pod Anda.
Jika Anda mencoba mengakses aplikasi menggunakan alamat IP yang dikembalikan untuk salah satu Pod pada langkah sebelumnya, Anda masih menerima respons karena semua port diizinkan di antara Pod yang memiliki grup keamanan yang terkait dengannya dan pencarian nama tidak diperlukan.
1. Setelah selesai bereksperimen, Anda dapat menghapus contoh kebijakan grup keamanan, aplikasi, dan grup keamanan yang Anda buat. Jalankan perintah berikut dari`TerminalA`.
```
kubectl delete namespace my-namespace
aws ec2 revoke-security-group-ingress --group-id $my_pod_security_group_id --security-group-rule-ids $my_inbound_self_rule_id
wait
sleep 45s
aws ec2 delete-security-group --group-id $my_pod_security_group_id
```
# Lampirkan beberapa antarmuka jaringan ke Pod
Secara default, plugin Amazon VPC CNI memberikan satu alamat IP ke setiap pod. Alamat IP ini dilampirkan ke *elastic network interface* yang menangani semua lalu lintas masuk dan keluar untuk pod. Untuk meningkatkan kinerja bandwidth dan paket per detik, Anda dapat menggunakan *fitur Multi-NIC* dari VPC CNI untuk mengonfigurasi pod multi-homed. Pod multi-homed adalah pod Kubernetes tunggal yang menggunakan beberapa antarmuka jaringan (dan beberapa alamat IP). Dengan menjalankan pod multi-homed, Anda dapat menyebarkan lalu lintas aplikasinya di beberapa antarmuka jaringan dengan menggunakan koneksi bersamaan. Ini sangat berguna untuk kasus penggunaan Artificial Intelligence (AI), Machine Learning (ML), dan High Performance Computing (HPC).
Diagram berikut menunjukkan pod multi-homed yang berjalan pada node pekerja dengan beberapa kartu antarmuka jaringan (NICs) yang digunakan.
![\[Pod multi-homed dengan dua antarmuka jaringan terpasang satu antarmuka jaringan dengan ENA dan satu antarmuka jaringan dengan ENA dan EFA\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/multi-homed-pod.png)
## Latar Belakang
Di Amazon EC2, *elastic network interface* adalah komponen jaringan logis dalam VPC yang mewakili kartu jaringan virtual. Untuk banyak jenis EC2 contoh, antarmuka jaringan berbagi kartu antarmuka jaringan tunggal (NIC) dalam perangkat keras. NIC tunggal ini memiliki bandwidth maksimum dan paket per detik.
Jika fitur Multi-NIC diaktifkan, VPC CNI tidak menetapkan alamat IP secara massal, yang dilakukan secara default. Sebagai gantinya, VPC CNI memberikan satu alamat IP ke antarmuka jaringan pada setiap kartu jaringan sesuai permintaan ketika pod baru dimulai. Perilaku ini mengurangi tingkat kehabisan alamat IP, yang ditingkatkan dengan menggunakan pod multi-homed. Karena VPC CNI menetapkan alamat IP sesuai permintaan, pod mungkin membutuhkan waktu lebih lama untuk memulai instance dengan fitur Multi-NIC diaktifkan.
## Pertimbangan-pertimbangan
+ Pastikan klaster Kubernetes Anda menjalankan versi VPC CNI dan yang lebih baru. `1.20.0` Fitur Multi-NIC hanya tersedia dalam versi `1.20.0` VPC CNI atau yang lebih baru.
+ Aktifkan variabel `ENABLE_MULTI_NIC` lingkungan di plugin VPC CNI. Anda dapat menjalankan perintah berikut untuk mengatur variabel dan memulai penyebaran. DaemonSet
+ `kubectl set env daemonset aws-node -n kube-system ENABLE_MULTI_NIC=true`
+ Pastikan Anda membuat node pekerja yang memiliki beberapa kartu antarmuka jaringan (NICs). Untuk daftar EC2 instance yang memiliki beberapa kartu antarmuka jaringan, lihat [Kartu jaringan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) di **Panduan EC2 Pengguna Amazon**.
+ Jika fitur Multi-NIC diaktifkan, VPC CNI tidak menetapkan alamat IP secara massal, yang dilakukan secara default. Karena VPC CNI menetapkan alamat IP sesuai permintaan, pod mungkin membutuhkan waktu lebih lama untuk memulai instance dengan fitur Multi-NIC diaktifkan. Untuk informasi lebih lanjut, lihat bagian sebelumnya[Latar Belakang](#pod-multi-nic-background).
+ Dengan fitur Multi-NIC diaktifkan, pod tidak memiliki beberapa antarmuka jaringan secara default. Anda harus mengkonfigurasi setiap beban kerja untuk menggunakan Multi-NIC. Tambahkan `k8s.amazonaws.com/nicConfig: multi-nic-attachment` anotasi ke beban kerja yang seharusnya memiliki beberapa antarmuka jaringan.
### Pertimbangan `IPv6`
+ **Kebijakan IAM khusus** - Untuk `IPv6` cluster, buat dan gunakan kebijakan IAM kustom berikut untuk CNI VPC. Kebijakan ini khusus untuk Multi-NIC. Untuk informasi lebih umum tentang menggunakan VPC CNI dengan `IPv6` cluster, lihat. [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md)
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSCNIPolicyIPv6MultiNIC",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeInstances",
"ec2:AssignIpv6Addresses",
"ec2:DetachNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeTags",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DeleteNetworkInterface",
"ec2:DescribeInstanceTypes",
"ec2:UnassignIpv6Addresses",
"ec2:AttachNetworkInterface",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Sid": "AmazonEKSCNIPolicyENITagIPv6MultiNIC",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:network-interface/*"
}
]
}
```
+ `IPv6`**mekanisme transisi tidak tersedia** - Jika Anda menggunakan fitur Multi-NIC, VPC CNI tidak menetapkan alamat ke pod di `IPv4` klaster. `IPv6` Jika tidak, VPC CNI memberikan `IPv4` alamat host-lokal ke setiap pod sehingga pod dapat berkomunikasi dengan sumber daya eksternal di VPC Amazon `IPv4` lain atau internet.
## Penggunaan
Setelah fitur Multi-NIC diaktifkan di VPC CNI dan `aws-node` pod telah dimulai ulang, Anda dapat mengonfigurasi setiap beban kerja menjadi multi-homed. Contoh konfigurasi YAMM berikut dengan anotasi yang diperlukan:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-deployment
namespace: ecommerce
labels:
app: orders
spec:
replicas: 3
selector:
matchLabels:
app: orders
template:
metadata:
annotations:
k8s.amazonaws.com/nicConfig: multi-nic-attachment
labels:
app: orders
spec:
...
```
## Pertanyaan yang Sering Diajukan
### **1. Apa itu kartu antarmuka jaringan (NIC)?**
Kartu antarmuka jaringan (NIC), juga disebut kartu jaringan, adalah perangkat fisik yang memungkinkan konektivitas jaringan untuk perangkat keras komputasi awan yang mendasarinya. Di EC2 server modern, ini mengacu pada kartu jaringan Nitro. Elastic Network Interface (ENI) adalah representasi virtual dari kartu jaringan yang mendasarinya.
Beberapa jenis EC2 contoh memiliki beberapa NICs untuk bandwidth yang lebih besar dan kinerja packet rate. Untuk contoh seperti itu, Anda dapat menetapkan sekunder ENIs ke kartu jaringan tambahan. Misalnya, ENI \$11 dapat berfungsi sebagai antarmuka untuk NIC yang terpasang pada indeks kartu jaringan 0, sedangkan ENI \$12 dapat berfungsi sebagai antarmuka untuk NIC yang terpasang pada indeks kartu jaringan terpisah.
### **2. Apa itu pod multi-homed?**
Pod multi-homed adalah pod Kubernetes tunggal dengan beberapa antarmuka jaringan (dan implikasinya beberapa alamat IP). Setiap antarmuka jaringan pod dikaitkan dengan [Elastic Network Interface (ENI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html), dan ini ENIs adalah representasi logis dari terpisah NICs pada node pekerja yang mendasarinya. Dengan beberapa antarmuka jaringan, pod multi-homed memiliki kapasitas transfer data tambahan, yang juga meningkatkan kecepatan transfer datanya.
**penting**
VPC CNI hanya dapat mengonfigurasi pod multi-homed pada tipe instance yang memiliki multiple. NICs
### **3. Mengapa saya harus menggunakan fitur ini?**
Jika Anda perlu menskalakan kinerja jaringan di beban kerja berbasis Kubernetes, Anda dapat menggunakan fitur Multi-NIC untuk menjalankan pod multi-homed yang berinteraksi dengan semua yang mendasarinya yang memiliki perangkat ENA NICs yang terpasang padanya. Memanfaatkan kartu jaringan tambahan meningkatkan kapasitas bandwidth dan kinerja laju paket dalam aplikasi Anda dengan mendistribusikan lalu lintas aplikasi di beberapa koneksi bersamaan. Ini sangat berguna untuk kasus penggunaan Artificial Intelligence (AI), Machine Learning (ML), dan High Performance Computing (HPC).
### **4. Bagaimana cara menggunakan fitur ini?**
1. Pertama, Anda harus memastikan bahwa cluster Kubernetes Anda menggunakan VPC CNI versi 1.20 atau yang lebih baru. Untuk langkah-langkah memperbarui VPC CNI sebagai add-on EKS, lihat. [Perbarui Amazon VPC CNI (add-on Amazon EKS)](vpc-add-on-update.md)
1. Kemudian, Anda harus mengaktifkan dukungan Multi-NIC di VPC CNI dengan menggunakan `ENABLE_MULTI_NIC` variabel lingkungan.
1. Kemudian, Anda harus memastikan bahwa Anda membuat dan bergabung dengan node yang memiliki beberapa kartu jaringan. Untuk daftar jenis EC2 instans yang memiliki beberapa kartu jaringan, lihat [Kartu jaringan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) di *Panduan EC2 Pengguna Amazon*.
1. Terakhir, Anda mengonfigurasi setiap beban kerja untuk menggunakan beberapa antarmuka jaringan (pod multi-homed) atau menggunakan antarmuka jaringan tunggal.
### **5. Bagaimana cara mengonfigurasi beban kerja saya untuk menggunakan beberapa NICs pada node pekerja yang didukung?**
Untuk menggunakan pod multi-homed, Anda perlu menambahkan anotasi berikut:. `k8s.amazonaws.com/nicConfig: multi-nic-attachment` Ini akan melampirkan ENI dari setiap NIC dalam instance yang mendasarinya ke pod (satu ke banyak pemetaan antara pod dan pod NICs).
Jika anotasi ini tidak ada, VPC CNI mengasumsikan bahwa pod Anda hanya memerlukan 1 antarmuka jaringan dan memberinya IP dari ENI pada NIC yang tersedia.
### **6. Adaptor antarmuka jaringan apa yang didukung dengan fitur ini?**
Anda dapat menggunakan adaptor antarmuka jaringan apa pun jika Anda memiliki setidaknya satu ENA yang terpasang ke kartu jaringan yang mendasarinya untuk lalu lintas IP. Untuk informasi selengkapnya tentang ENA, lihat [Elastic Network Adapter (ENA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) di *Panduan EC2 Pengguna Amazon*.
Konfigurasi perangkat jaringan yang didukung:
+ Antarmuka **ENA** menyediakan semua jaringan IP tradisional dan fitur routing yang diperlukan untuk mendukung jaringan IP untuk VPC. Untuk informasi selengkapnya, lihat [Mengaktifkan jaringan yang disempurnakan dengan ENA pada EC2 instans Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html).
+ Antarmuka **EFA** **(EFA** **dengan ENA)** menyediakan perangkat ENA untuk jaringan IP dan perangkat EFA untuk komunikasi latensi rendah dan throughput tinggi.
**penting**
Jika kartu jaringan hanya memiliki adaptor khusus **EFA** yang terpasang padanya, VPC CNI akan melewatinya saat menyediakan konektivitas jaringan untuk pod multi-homed. Namun, jika Anda menggabungkan adaptor **khusus EFA** dengan adaptor **ENA** pada kartu jaringan, maka VPC CNI akan mengelola ENIs pada perangkat ini juga. Untuk menggunakan antarmuka khusus EFA dengan kluster EKS, lihat. [Jalankan pelatihan pembelajaran mesin di Amazon EKS dengan Adaptor Kain Elastis](node-efa.md)
### **7. Dapatkah saya melihat apakah sebuah node di cluster saya memiliki dukungan ENA?**
Ya, Anda dapat menggunakan AWS CLI atau EC2 API untuk mengambil informasi jaringan tentang EC2 instance di cluster Anda. Ini memberikan rincian tentang apakah instans memiliki dukungan ENA atau tidak. Dalam contoh berikut, ganti `` dengan ID EC2 instance dari sebuah node.
AWS Contoh CLI:
```
aws ec2 describe-instances --instance-ids --query "Reservations[].Instances[].EnaSupport"
```
Contoh output:
```
[ true ]
```
### **8. Dapatkah saya melihat berbagai alamat IP yang terkait dengan pod?**
Tidak, tidak mudah. Namun, Anda dapat menggunakan `nsenter` dari node untuk menjalankan alat jaringan umum seperti `ip route show` dan melihat alamat IP dan antarmuka tambahan.
### **9. Dapatkah saya mengontrol jumlah antarmuka jaringan untuk pod saya?**
Tidak. Ketika beban kerja Anda dikonfigurasi untuk menggunakan multiple NICs pada instance yang didukung, satu pod secara otomatis memiliki alamat IP dari setiap kartu jaringan pada instance. Atau, pod single-homed akan memiliki satu antarmuka jaringan yang terpasang ke satu NIC pada instance.
**penting**
Kartu jaringan yang *hanya* memiliki perangkat khusus **EFA** yang terpasang padanya dilewati oleh VPC CNI.
### **10. Bisakah saya mengonfigurasi pod saya untuk menggunakan NIC tertentu?**
Tidak, ini tidak didukung. Jika sebuah pod memiliki anotasi yang relevan, maka VPC CNI secara otomatis mengonfigurasinya untuk menggunakan setiap NIC dengan adaptor ENA pada node pekerja.
### **11. Apakah fitur ini berfungsi dengan fitur jaringan VPC CNI lainnya?**
Ya, fitur Multi-NIC di VPC CNI bekerja dengan jaringan *khusus *dan** penemuan subnet yang disempurnakan. Namun, pod multi-homed tidak menggunakan subnet khusus atau grup keamanan. Sebagai gantinya, VPC CNI memberikan alamat IP dan antarmuka jaringan ke pod multi-homed dengan konfigurasi subnet dan grup keamanan yang sama dengan node. Untuk informasi selengkapnya tentang jaringan khusus, lihat[Menerapkan Pod di subnet alternatif dengan jaringan khusus](cni-custom-network.md).
Fitur Multi-NIC di VPC CNI tidak berfungsi dan tidak dapat digabungkan *dengan grup keamanan* untuk pod.
### **12. Dapatkah saya menggunakan kebijakan jaringan dengan fitur ini?**
Ya, Anda dapat menggunakan kebijakan jaringan Kubernetes dengan Multi-NIC. Kebijakan jaringan Kubernetes membatasi lalu lintas jaringan ke dan dari pod Anda. Untuk informasi selengkapnya tentang penerapan kebijakan jaringan dengan VPC CNI, lihat. [Batasi lalu lintas Pod dengan kebijakan jaringan Kubernetes](cni-network-policy.md)
### **13. Apakah dukungan Multi-NIC diaktifkan dalam Mode Otomatis EKS?**
Multi-NIC tidak didukung untuk kluster Mode Otomatis EKS.