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 RFC6598ruang memungkinkan Anda menskalakan Pod di luar RFC1918mengatasi tantangan kelelahan. Harap pertimbangkan untuk menggunakan delegasi awalan dengan jaringan khusus untuk meningkatkan kepadatan Pod pada sebuah 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 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 dan VPC Layanan Bersama (termasuk gateway NAT di beberapa Availability Zone untuk ketersediaan tinggi) memungkinkan Anda memberikan arus lalu lintas yang terukur dan dapat diprediksi. Posting blog ini menjelaskan pola arsitektur yang merupakan salah satu cara yang paling direkomendasikan untuk menghubungkan Pod EKS ke jaringan pusat data menggunakan jaringan kustom.

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 ini untuk menggunakan gateway NAT pribadi untuk mengatasi masalah komunikasi untuk beban kerja EKS yang disebabkan oleh tumpang tindih CIDRs, 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 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 ini.

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/zoneke node pekerja Anda. Amazon EKS merekomendasikan penggunaan zona ketersediaan sebagai nama konfigurasi ENI Anda ketika Anda hanya memiliki satu subnet sekunder (CIDR alternatif) per AZ. Perhatikan bahwa tag failure-domain.beta.kubernetes.io/zone tidak digunakan lagi dan diganti dengan tag. topology.kubernetes.io/zone

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/eniConfigdan memberi label node dengan nama eniconFig khusus, seperti dan. k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1k8s.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 untuk mematikan Pod dengan anggun dan kemudian menghentikan node. Hanya node baru yang cocok dengan ENIConfig label atau anotasi yang menggunakan jaringan kustom, dan karenanya Pod yang dijadwalkan pada node baru ini dapat diberi IP dari CIDR sekunder.

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

Mengaktifkan lampiran awalan meningkatkan jumlah Pod menjadi 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.

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