Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Jaringan Kustom
**Tip**
[Jelaj ](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) ahi praktik terbaik melalui lokakarya Amazon EKS.
Secara default, Amazon VPC CNI akan menetapkan Pods alamat IP yang dipilih dari subnet utama. Subnet utama adalah subnet CIDR yang dilampirkan oleh ENI primer, biasanya subnet dari. node/host
Jika subnet CIDR terlalu kecil, CNI mungkin tidak dapat memperoleh alamat IP sekunder yang cukup untuk ditetapkan ke Pod Anda. Ini adalah tantangan umum untuk cluster EKS IPv4.
Jaringan khusus adalah salah satu solusi untuk masalah ini.
Jaringan khusus mengatasi masalah kehabisan IP dengan menetapkan node dan IP Pod dari ruang alamat VPC sekunder (CIDR). Dukungan jaringan khusus mendukung sumber daya kustom ENIconfig. ENIconfig menyertakan rentang CIDR subnet alternatif (diukir dari CIDR VPC sekunder), bersama dengan grup keamanan yang akan dimiliki Pod. Ketika jaringan khusus diaktifkan, VPC CNI membuat ENI sekunder di subnet yang ditentukan di bawah ENIconfig. CNI menetapkan Pods alamat IP dari rentang CIDR yang ditentukan dalam ENIConfig CRD.
Karena ENI primer tidak digunakan oleh jaringan khusus, jumlah maksimum Pod yang dapat Anda jalankan pada node lebih rendah. Pod jaringan host terus menggunakan alamat IP yang ditetapkan ke ENI utama. Selain itu, ENI utama digunakan untuk menangani terjemahan jaringan sumber dan merutekan lalu lintas Pod di luar node.
## Contoh Konfigurasi
Meskipun jaringan khusus akan menerima rentang VPC yang valid untuk rentang CIDR sekunder, sebaiknya gunakan CIDR dari ruang alamat `100.64.0.0/10` bersama (RFC 6598) karena cenderung tidak digunakan dalam pengaturan perusahaan dibandingkan rentang RFC1918 lainnya. Misalnya, Anda dapat menggunakan `100.64.0.0/16` sebagai CIDR sekunder untuk VPC Anda. Untuk informasi tambahan tentang asosiasi blok CIDR yang diizinkan dan dibatasi yang dapat Anda gunakan dengan VPC Anda, lihat pembatasan asosiasi blok CIDR [ IPv4 ](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#add-cidr-block-restrictions) di bagian ukuran VPC dan subnet dari dokumentasi VPC.
Seperti yang ditunjukkan pada diagram di bawah ini, Elastic Network Interface ([ENI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)) primer dari node pekerja masih menggunakan rentang VPC CIDR primer (dalam hal ini 10.0.0. 0/16) tetapi ENI sekunder menggunakan Rentang CIDR VPC sekunder (dalam hal ini 100.64.0. 0/16). Sekarang, agar Pod menggunakan 100.64.0. 0/16 Rentang CIDR, Anda harus mengkonfigurasi plugin CNI untuk menggunakan jaringan khusus. Anda dapat mengikuti langkah-langkah seperti yang didokumentasikan [ di sini](https://docs.aws.amazon.com/eks/latest/userguide/cni-custom-network-tutorial.html).
Jika Anda ingin CNI menggunakan jaringan khusus, atur variabel `AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG` lingkungan ke`true`.
```
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
```
Kapan`AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true`, CNI akan menetapkan alamat IP Pod dari subnet yang ditentukan di. `ENIConfig` Sumber daya `ENIConfig` khusus digunakan untuk menentukan subnet tempat Pod akan dijadwalkan.
```
apiVersion : crd.k8s.amazonaws.com/v1alpha1
kind : ENIConfig
metadata:
name: us-west-2a
spec:
securityGroups:
- sg-0dff111a1d11c1c11
subnet: subnet-011b111c1f11fdf11
```
Setelah membuat sumber daya `ENIconfig` khusus, Anda perlu membuat node pekerja baru dan menguras node yang ada. Node dan Pod pekerja yang ada akan tetap tidak terpengaruh.
## Rekomendasi
### Gunakan Jaringan Kustom Saat
Kami menyarankan Anda untuk mempertimbangkan jaringan khusus jika Anda berurusan dengan kehabisan IPv4 dan belum dapat menggunakan IPv6. Dukungan Amazon EKS untuk [ ruang ](https://datatracker.ietf.org/doc/html/rfc6598) RFC6598 memungkinkan Anda menskalakan Pod melampaui [ RFC ](https://datatracker.ietf.org/doc/html/rfc1918) 1918 mengatasi tantangan kelelahan. Harap pertimbangkan untuk menggunakan delegasi awalan dengan jaringan khusus untuk meningkatkan kepadatan Pod pada node.
Anda dapat mempertimbangkan jaringan khusus jika Anda memiliki persyaratan keamanan untuk menjalankan Pod di jaringan yang berbeda dengan persyaratan grup keamanan yang berbeda. Ketika jaringan kustom diaktifkan, pod menggunakan subnet atau grup keamanan yang berbeda seperti yang didefinisikan dalam ENIconfig daripada antarmuka jaringan utama node.
Jaringan khusus memang merupakan pilihan ideal untuk menyebarkan beberapa cluster EKS dan aplikasi untuk menghubungkan layanan pusat data lokal. Anda dapat meningkatkan jumlah alamat pribadi (RFC1918) yang dapat diakses oleh EKS di VPC Anda untuk layanan seperti Amazon Elastic Load Balancing dan NAT-GW, sambil menggunakan CG-NAT ruang yang tidak dapat dirutekan untuk Pod Anda di beberapa cluster. Jaringan kustom dengan gateway [ transit ](https://aws.amazon.com/transit-gateway/) dan VPC Layanan Bersama (termasuk gateway NAT di beberapa Zona Ketersediaan untuk ketersediaan tinggi) memungkinkan Anda memberikan alur lalu lintas yang dapat diskalakan dan dapat diprediksi. Post [ ing blog ini ](https://aws.amazon.com/blogs/containers/eks-vpc-routable-ip-address-conservation/) menjelaskan pola arsitektur yang merupakan salah satu cara yang paling direkomendasikan untuk menghubungkan EKS Pod ke jaringan pusat data menggunakan jaringan khusus.
### Hindari Jaringan Khusus Saat
#### Siap Menerapkan IPv6
Jaringan khusus dapat mengurangi masalah kelelahan IP, tetapi memerlukan overhead operasional tambahan. Jika saat ini Anda menerapkan VPC dual-stack (IPv4/IPv6) atau jika paket Anda menyertakan dukungan IPv6, sebaiknya terapkan cluster IPv6 sebagai gantinya. Anda dapat mengatur cluster EKS IPv6 dan memigrasikan aplikasi Anda. Dalam cluster EKS IPv6, baik Kubernetes dan Pod mendapatkan alamat IPv6 dan dapat berkomunikasi masuk dan keluar ke titik akhir IPv4 dan IPv6. Silakan tinjau praktik terbaik untuk Men [ jalankan IPv6 EKS Cluster](ipv6.md).
#### CG-NAT Ruang yang habis
Selain itu, jika Anda saat ini menggunakan CIDR dari CG-NAT ruang atau tidak dapat menghubungkan CIDR sekunder dengan VPC cluster Anda, Anda mungkin perlu menjelajahi opsi lain, seperti menggunakan CNI alternatif. Kami sangat menyarankan agar Anda mendapatkan dukungan komersial atau memiliki pengetahuan internal untuk men-debug dan mengirimkan patch ke proyek plugin CNI open source. Lihat panduan [ pengguna Plugin CNI ](https://docs.aws.amazon.com/eks/latest/userguide/alternate-cni-plugins.html) Alternatif untuk detail selengkapnya.
#### Gunakan Gerbang NAT Pribadi
Amazon VPC sekarang menawarkan [ kemampuan gateway NAT ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) pribadi. NAT Gateway pribadi Amazon memungkinkan instans di subnet pribadi untuk terhubung ke VPC lain dan jaringan lokal dengan CIDR yang tumpang tindih. Pertimbangkan untuk menggunakan metode yang dijelaskan pada posting [ blog ini ](https://aws.amazon.com/blogs/containers/addressing-ipv4-address-exhaustion-in-amazon-eks-clusters-using-private-nat-gateways/) untuk menggunakan gateway NAT pribadi untuk mengatasi masalah komunikasi untuk beban kerja EKS yang disebabkan oleh CIDR yang tumpang tindih, keluhan signifikan yang diungkapkan oleh klien kami. Jaringan khusus tidak dapat mengatasi kesulitan CIDR yang tumpang tindih dengan sendirinya, dan itu menambah tantangan konfigurasi.
Arsitektur jaringan yang digunakan dalam implementasi posting blog ini mengikuti rekomendasi di bawah [ Aktifkan komunikasi antara jaringan yang tumpang tindih ](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#private-nat-overlapping-networks) dalam dokumentasi Amazon VPC. Seperti yang ditunjukkan dalam posting blog ini, Anda dapat memperluas penggunaan Gerbang NAT pribadi bersama dengan alamat RFC6598 untuk mengelola masalah kehabisan IP pribadi pelanggan. Cluster EKS, node pekerja dikerahkan di 100.64.0 yang tidak dapat dirutekan. 0/16 Rentang CIDR sekunder VPC, sedangkan gateway NAT pribadi, gateway NAT dikerahkan ke rentang CIDR RFC1918 yang dapat dirutekan. Blog menjelaskan bagaimana gateway transit digunakan untuk menghubungkan VPC untuk memfasilitasi komunikasi di seluruh VPC dengan rentang CIDR yang tidak dapat dirutekan yang tumpang tindih. Untuk kasus penggunaan di mana sumber daya EKS dalam rentang alamat VPC yang tidak dapat dirutekan perlu berkomunikasi dengan VPC lain yang tidak memiliki rentang alamat yang tumpang tindih, pelanggan memiliki opsi untuk menggunakan VPC Peering untuk menghubungkan VPC tersebut. Metode ini dapat memberikan penghematan biaya potensial karena semua transit data dalam Availability Zone melalui koneksi peering VPC sekarang gratis.
#### Jaringan unik untuk node dan Pod
Jika Anda perlu mengisolasi node dan Pod ke jaringan tertentu untuk alasan keamanan, sebaiknya gunakan node dan Pod ke subnet dari blok CIDR sekunder yang lebih besar (misalnya 100.64.0. 0/8). Setelah instalasi CIDR baru di VPC Anda, Anda dapat menerapkan grup node lain menggunakan CIDR sekunder dan menguras node asli untuk secara otomatis menyebarkan ulang pod ke node pekerja baru. Untuk informasi lebih lanjut tentang cara menerapkan ini, lihat [ posting ](https://aws.amazon.com/blogs/containers/optimize-ip-addresses-usage-by-pods-in-your-amazon-eks-cluster/) blog ini.
Jaringan khusus tidak digunakan dalam pengaturan yang diwakili dalam diagram di bawah ini. Sebaliknya, node pekerja Kubernetes digunakan pada subnet dari rentang VPC CIDR sekunder VPC Anda, seperti 100.64.0. 0/10. Anda dapat menjaga cluster EKS tetap berjalan (bidang kontrol akan tetap pada aslinya subnet/s), tetapi node dan Pod akan dipindahkan ke sekunder subnet/s. Ini adalah teknik lain, meskipun tidak konvensional, untuk mengurangi bahaya kelelahan IP dalam VPC. Kami mengusulkan pengeringan node lama sebelum menyebarkan ulang pod ke node pekerja baru.
### Otomatisasi Konfigurasi dengan Label Zona Ketersediaan
Anda dapat mengaktifkan Kubernetes untuk secara otomatis menerapkan ENIconfig yang sesuai untuk Zona Ketersediaan node pekerja (AZ).
Kubernetes secara otomatis menambahkan tag [`topology.kubernetes.io/zone`](http://topology.kubernetes.io/zone) ke node pekerja Anda. Amazon EKS merekomendasikan penggunaan zona ketersediaan sebagai nama konfigurasi ENI jika Anda hanya memiliki satu subnet sekunder (CIDR alternatif) per AZ. Anda kemudian dapat mengatur label yang digunakan untuk menemukan nama konfigurasi ENI ke`topology.kubernetes.io/zone`. Perhatikan bahwa tag `failure-domain.beta.kubernetes.io/zone` tidak digunakan lagi dan diganti dengan tag. `topology.kubernetes.io/zone`
1. Set `name` el bidang ke Zona Ketersediaan VPC Anda.
1. Aktifkan konfigurasi otomatis melalui perintah berikut
1. Atur label konfigurasi melalui perintah berikut
```
kubectl set env daemonset aws-node -n kube-system "AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true"
kubectl set env daemonset aws-node -n kube-system "ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone"
```
Jika Anda memiliki beberapa subnet sekunder per zona ketersediaan, Anda perlu membuat subnet tertentu`ENI_CONFIG_LABEL_DEF`. Anda dapat mempertimbangkan untuk mengonfigurasi node `ENI_CONFIG_LABEL_DEF` as [`k8s.amazonaws.com/eniConfig`](http://k8s.amazonaws.com/eniConfig) dan memberi label dengan nama ENIconfig kustom, seperti [`k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1`](http://k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1) dan. [`k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2`](http://k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2)
### Ganti Pod saat Mengkonfigurasi Jaringan Sekunder
Mengaktifkan jaringan kustom tidak mengubah node yang ada. Jaringan khusus adalah tindakan yang mengganggu. Daripada melakukan penggantian bergulir semua node pekerja di cluster Anda setelah mengaktifkan jaringan khusus, sebaiknya perbarui CloudFormation template AWS di Panduan Memulai [ EKS ](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) dengan sumber daya khusus yang memanggil fungsi Lambda untuk memperbarui `aws-node` Daemonset dengan variabel lingkungan untuk mengaktifkan jaringan khusus sebelum node pekerja disediakan.
Jika Anda memiliki node di cluster Anda dengan Pod yang menjalankan sebelum Anda beralih ke fitur jaringan CNI khusus, Anda harus menutup dan [ menguras node ](https://aws.amazon.com/premiumsupport/knowledge-center/eks-worker-node-actions/) untuk mematikan Pod dengan anggun dan kemudian menghentikan node. Hanya node baru yang cocok dengan label atau anotasi ENIconfig yang menggunakan jaringan khusus, dan karenanya Pod yang dijadwalkan pada node baru ini dapat diberi IP dari CIDR sekunder.
### Hitung Max Pod per Node
Karena ENI utama node tidak lagi digunakan untuk menetapkan alamat IP Pod, ada penurunan jumlah Pod yang dapat Anda jalankan pada jenis instans EC2 tertentu. Untuk mengatasi batasan ini, Anda dapat menggunakan penetapan awalan dengan jaringan khusus. Dengan penetapan awalan, setiap IP sekunder diganti dengan awalan /28 pada ENI sekunder.
Pertimbangkan jumlah maksimum Pod untuk instance m5.large dengan jaringan khusus.
Jumlah maksimum Pod yang dapat Anda jalankan tanpa penetapan awalan adalah 29
+ ` 3 ENIs - 1) * (10 secondary IPs per ENI - 1 + 2 = 20`
Mengaktifkan lampiran awalan meningkatkan jumlah Pod menjadi 290.
+ `(3 ENIs - 1) * ((10 secondary IPs per ENI - 1) * 16 + 2 = 290`
Namun, kami menyarankan untuk mengatur max-pod ke 110 daripada 290 karena instance memiliki jumlah CPU virtual yang agak kecil. Pada instans yang lebih besar, EKS merekomendasikan nilai pod maksimal 250. Saat menggunakan lampiran awalan dengan tipe instance yang lebih kecil (misalnya m5.large), ada kemungkinan bahwa Anda akan menghabiskan sumber daya CPU dan memori instans jauh sebelum alamat IP-nya.
**catatan**
Ketika awalan CNI mengalokasikan awalan /28 ke ENI, itu harus menjadi blok alamat IP yang berdekatan. Jika subnet tempat awalan dihasilkan sangat terfragmentasi, lampiran awalan mungkin gagal. Anda dapat mengurangi hal ini agar tidak terjadi dengan membuat VPC khusus baru untuk cluster atau dengan memesan subnet satu set CIDR khusus untuk lampiran awalan. Kunjungi reserv [ asi Subnet CIDR ](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) untuk informasi lebih lanjut tentang topik ini.
### Identifikasi Penggunaan CG-NAT Ruang yang Ada
Jaringan khusus memungkinkan Anda untuk mengurangi masalah kelelahan IP, namun tidak dapat menyelesaikan semua tantangan. Jika Anda sudah menggunakan CG-NAT ruang untuk cluster Anda, atau tidak memiliki kemampuan untuk mengaitkan CIDR sekunder dengan VPC cluster Anda, kami sarankan Anda untuk menjelajahi opsi lain, seperti menggunakan CNI alternatif atau pindah ke cluster IPv6.