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 kluster EKS IPv4.

Jaringan khusus adalah salah satu solusi untuk masalah ini.

Jaringan khusus mengatasi masalah kelelahan IP dengan menetapkan node dan IP Pod dari ruang alamat VPC sekunder (CIDR). Dukungan jaringan khusus mendukung sumber daya khusus EniConfig. EniConfig menyertakan 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 ENI sekunder 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 CIDR (/16) dari ruang, yaitu 100.64.0. CG-NAT 0/10 atau 198.19.0. 0/16 karena mereka lebih kecil kemungkinannya untuk digunakan dalam pengaturan perusahaan daripada rentang RFC1918 lainnya. Untuk informasi tambahan tentang asosiasi blok CIDR yang diizinkan dan dibatasi yang dapat Anda gunakan dengan VPC Anda, lihat Pembatasan asosiasi blok IPv4 CIDR di bagian ukuran VPC dan subnet dari dokumentasi VPC.

Seperti yang ditunjukkan pada diagram di bawah ini, Antarmuka Jaringan Elastis (ENI) primer dari node pekerja masih menggunakan rentang CIDR VPC 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.

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 kelelahan IPv4 dan belum dapat menggunakan IPv6. Dukungan Amazon EKS untuk ruang RFC6598 memungkinkan Anda untuk menskalakan Pod di luar RFC1918 mengatasi 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 didefinisikan dalam EniConfig daripada 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 yang tidak CG-NAT 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 Kustom Saat

Siap Menerapkan IPv6

Jaringan khusus dapat mengurangi masalah kelelahan IP, tetapi membutuhkan overhead operasional tambahan. Jika saat ini Anda sedang menerapkan IPv4/IPv6 VPC dual-stack () atau jika paket Anda menyertakan dukungan IPv6, sebaiknya Anda mengimplementasikan cluster IPv6 sebagai gantinya. Anda dapat mengatur kluster IPv6 EKS dan memigrasikan aplikasi Anda. Dalam klaster IPv6 EKS, Kubernetes dan Pod mendapatkan alamat IPv6 dan dapat berkomunikasi masuk dan keluar ke titik akhir IPv4 dan IPv6. Harap tinjau praktik terbaik untuk Menjalankan Kluster EKS IPv6.

Ruang yang CG-NAT Habis

Selain itu, jika saat ini Anda menggunakan CIDR dari CG-NAT ruang 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 VPC lain dan jaringan lokal dengan CIDR yang tumpang tindih. 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 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 dalam dokumentasi Amazon VPC. Seperti yang ditunjukkan dalam posting blog ini, Anda dapat memperluas penggunaan Gateway NAT pribadi bersama dengan alamat RFC6598 untuk mengelola masalah kelelahan IP pribadi pelanggan. Kluster 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 non-routable yang tumpang tindih. Untuk kasus penggunaan di mana sumber daya EKS dalam rentang alamat non-routable VPC 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 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 klaster EKS tetap berjalan (control plane 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 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 EniConFig yang sesuai 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. Anda kemudian dapat mengatur label yang digunakan untuk menemukan nama konfigurasi ENI. topology.kubernetes.io/zone 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"
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 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 label atau anotasi EniConfig 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 instans EC2 tertentu. Untuk mengatasi batasan ini, Anda dapat menggunakan penetapan awalan dengan jaringan khusus. Dengan penugasan awalan, setiap IP sekunder diganti dengan awalan /28 pada ENI sekunder.

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 CPU virtual yang agak kecil. 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 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 hanya 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 klaster IPv6.