Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Jaringan Kustom
Secara default, Amazon VPC CNI akan menetapkan Pod alamat IP yang dipilih dari subnet utama. Subnet primer adalah subnet CIDR yang melekat pada ENI primer, biasanya subnet dari node/host.
Jika subnet CIDR terlalu kecil, CNI mungkin tidak dapat memperoleh cukup alamat IP sekunder untuk ditetapkan ke Pod Anda. Ini adalah tantangan umum untuk IPv4 kluster EKS.
Jaringan khusus adalah salah satu solusi untuk masalah ini.
Jaringan khusus mengatasi masalah kelelahan IP dengan menetapkan node dan Pod dari ruang alamat VPC IPs sekunder (CIDR). Dukungan jaringan khusus mendukung sumber daya ENIConfig khusus. ENIConfig Termasuk rentang CIDR subnet alternatif (diukir dari CIDR VPC sekunder), bersama dengan grup keamanan yang akan dimiliki oleh Pod. Saat jaringan khusus diaktifkan, CNI VPC membuat sekunder ENIs di subnet yang ditentukan di bawah. ENIConfig CNI memberikan Pod alamat IP dari rentang CIDR yang ditentukan dalam CRD. ENIConfig
Karena ENI primer tidak digunakan oleh jaringan kustom, jumlah maksimum Pod yang dapat Anda jalankan pada sebuah node lebih rendah. Pod jaringan host terus menggunakan alamat IP yang ditetapkan ke ENI primer. Selain itu, ENI primer 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, kami menyarankan Anda menggunakan CIDRs (/16) dari ruang CG-NAT, yaitu 100.64.0.0/10 atau 198.19.0.0/16 karena cenderung tidak digunakan dalam pengaturan perusahaan daripada rentang lainnya. RFC1918 Untuk informasi tambahan tentang asosiasi blok CIDR yang diizinkan dan dibatasi yang dapat Anda gunakan dengan VPC Anda, IPv4 lihat Pembatasan asosiasi blok CIDR di bagian ukuran VPC dan subnet dari dokumentasi VPC.
Seperti yang ditunjukkan pada diagram di bawah ini, Antarmuka Jaringan Elastis primer (ENI) dari node pekerja masih menggunakan rentang CIDR VPC primer (dalam hal ini 10.0.0.0/16) tetapi sekunder menggunakan ENIs Rentang CIDR VPC sekunder (dalam hal ini 100.64.0.0/16). Sekarang, agar Pod menggunakan rentang CIDR 100.64.0.0/16, Anda harus mengkonfigurasi plugin CNI untuk menggunakan jaringan kustom. Anda dapat mengikuti langkah-langkah seperti yang didokumentasikan di sini.

Jika Anda ingin CNI menggunakan jaringan khusus, atur variabel AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG
lingkungan ketrue
.
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
KapanAWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
, CNI akan menetapkan alamat IP Pod dari subnet yang ditentukan dalam. ENIConfig
Sumber daya ENIConfig
kustom digunakan untuk menentukan subnet di mana 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 IPv4 kelelahan dan belum dapat menggunakannya IPv6 . Dukungan Amazon EKS untuk RFC6598
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 ENIConfig didefinisikan dalam antarmuka jaringan utama node.
Jaringan khusus memang merupakan pilihan ideal untuk menyebarkan beberapa kluster dan aplikasi EKS untuk menghubungkan layanan pusat data di lokasi. Anda dapat menambah jumlah alamat pribadi (RFC1918) yang dapat diakses EKS di VPC Anda untuk layanan seperti Amazon Elastic Load Balancing dan NAT-GW, sambil menggunakan ruang CG-NAT yang tidak dapat dirutekan untuk Pod Anda di beberapa cluster. Jaringan khusus dengan gateway transit
Hindari Jaringan Khusus Saat
Siap Implementasi IPv6
Jaringan khusus dapat mengurangi masalah kelelahan IP, tetapi membutuhkan overhead operasional tambahan. Jika saat ini Anda sedang menerapkan IPv6 VPC dual-stack (/IPv4) atau jika paket Anda menyertakan IPv6 dukungan, sebaiknya implementasikan cluster sebagai gantinya. IPv6 Anda dapat mengatur kluster IPv6 EKS dan memigrasikan aplikasi Anda. Dalam kluster IPv6 EKS, Kubernetes dan Pod mendapatkan IPv6 alamat dan dapat berkomunikasi masuk dan keluar ke keduanya IPv4 dan titik akhir. IPv6 Harap tinjau praktik terbaik untuk Menjalankan Kluster IPv6 EKS.
Ruang CG-NAT yang Lelah
Selain itu, jika saat ini Anda menggunakan CIDRs dari ruang CG-NAT atau tidak dapat menautkan 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 tambalan ke proyek plugin CNI open source. Lihat panduan pengguna Plugin CNI Alternatif untuk detail selengkapnya.
Gunakan Gateway NAT Pribadi
Amazon VPC sekarang menawarkan kemampuan gateway NAT pribadi. Gateway NAT pribadi Amazon memungkinkan instance di subnet pribadi untuk terhubung ke jaringan lain VPCs dan lokal dengan tumpang tindih. CIDRs Pertimbangkan untuk menggunakan metode yang dijelaskan pada posting blog
Arsitektur jaringan yang digunakan dalam implementasi posting blog ini mengikuti rekomendasi di bawah Aktifkan komunikasi antara jaringan yang tumpang tindih dalam dokumentasi Amazon VPC. Seperti yang ditunjukkan dalam posting blog ini, Anda dapat memperluas penggunaan Gateway NAT pribadi bersama dengan RFC6598 alamat untuk mengelola masalah kelelahan IP pribadi pelanggan. Kluster EKS, node pekerja dikerahkan dalam rentang CIDR sekunder VPC 100.64.0.0/16 yang tidak dapat dirutekan, sedangkan gateway NAT pribadi, gateway NAT diterapkan ke rentang CIDR yang dapat dirutekan. RFC1918 Blog menjelaskan bagaimana gateway transit digunakan untuk terhubung untuk memfasilitasi komunikasi lintas VPCs dengan rentang VPCs CIDR yang tidak dapat dirutekan yang tumpang tindih. Untuk kasus penggunaan di mana sumber daya EKS dalam rentang alamat non-routable VPC perlu berkomunikasi dengan orang lain yang tidak memiliki rentang alamat VPCs yang tumpang tindih, pelanggan memiliki opsi untuk menggunakan VPC Peering untuk menghubungkannya. VPCs Metode ini dapat memberikan potensi penghematan biaya 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 Anda menyebarkan node dan Pod ke subnet dari blok CIDR sekunder yang lebih besar (mis. 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 menerapkan ulang pod ke node pekerja baru. Untuk informasi lebih lanjut tentang cara menerapkan ini, lihat posting blog
Jaringan khusus tidak digunakan dalam pengaturan yang diwakili dalam diagram di bawah ini. Sebaliknya, node pekerja Kubernetes di-deploy pada subnet dari rentang CIDR VPC sekunder VPC Anda, seperti 100.64.0.0/10. Anda dapat menjaga cluster EKS tetap berjalan (bidang kontrol akan tetap pada aslinyasubnet/s), but the nodes and Pods will be moved to a secondary subnet/s. Ini adalah teknik lain, meskipun tidak konvensional, untuk mengurangi bahaya kelelahan IP dalam VPC. Kami mengusulkan untuk menguras node lama sebelum memindahkan pod ke node pekerja baru.

Otomatiskan Konfigurasi dengan Label Availability Zone
Anda dapat mengaktifkan Kubernetes untuk secara otomatis menerapkan yang sesuai ENIConfig untuk node pekerja Availability Zone (AZ).
Kubernetes secara otomatis menambahkan tag topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/zone
tidak digunakan lagi dan diganti dengan tag. topology.kubernetes.io/zone
-
Setel
name
bidang ke Availability Zone dari VPC Anda. -
Aktifkan konfigurasi otomatis dengan perintah ini:
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
jika Anda memiliki beberapa subnet sekunder per zona ketersediaan, Anda perlu membuat yang spesifikENI_CONFIG_LABEL_DEF
. Anda dapat mempertimbangkan untuk mengonfigurasi ENI_CONFIG_LABEL_DEF
as k8s.amazonaws.com/eniConfig
k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1
k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2
Ganti Pod saat Mengonfigurasi Jaringan Sekunder
Mengaktifkan jaringan kustom tidak mengubah node yang ada. Jaringan khusus adalah tindakan yang mengganggu. Daripada melakukan penggantian bergulir dari semua node pekerja di cluster Anda setelah mengaktifkan jaringan khusus, kami sarankan memperbarui CloudFormation template AWS di Panduan Memulai EKS 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 klaster dengan menjalankan Pod sebelum beralih ke fitur jaringan CNI kustom, Anda harus mem-cordon dan menguras node
Hitung Pod Maks per Node
Karena ENI primer node tidak lagi digunakan untuk menetapkan alamat IP Pod, ada penurunan jumlah Pod yang dapat Anda jalankan pada jenis EC2 instance tertentu. Untuk mengatasi batasan ini, Anda dapat menggunakan penetapan awalan dengan jaringan khusus. Dengan penugasan awalan, setiap IP sekunder diganti dengan awalan /28 pada sekunder. ENIs
Pertimbangkan jumlah maksimum Pod untuk instance m5.large dengan jaringan kustom.
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 pengaturan max-pod ke 110 daripada 290 karena instance memiliki jumlah virtual yang agak kecil. CPUs Pada instance yang lebih besar, EKS merekomendasikan nilai pod maksimal 250. Saat menggunakan lampiran awalan dengan tipe instans yang lebih kecil (misalnya m5.large), Anda mungkin akan menghabiskan CPU dan sumber daya memori instans jauh sebelum alamat IP-nya.
catatan
Ketika awalan CNI mengalokasikan awalan /28 ke ENI, itu harus berupa blok alamat IP yang berdekatan. Jika subnet tempat awalan dihasilkan sangat terfragmentasi, lampiran awalan mungkin gagal. Anda dapat mengurangi hal ini terjadi dengan membuat VPC khusus baru untuk cluster atau dengan memesan subnet satu set CIDR secara eksklusif untuk lampiran awalan. Kunjungi reservasi Subnet CIDR untuk informasi lebih lanjut tentang topik ini.
Identifikasi Penggunaan Ruang CG-NAT yang Ada
Jaringan khusus memungkinkan Anda untuk mengurangi masalah kelelahan IP, namun tidak dapat menyelesaikan semua tantangan. Jika Anda sudah menggunakan ruang CG-NAT 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