Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Amazon VPC CNI

Amazon EKS mengimplementasikan jaringan cluster melalui plugin Amazon VPC Container Network Interface, juga dikenal sebagai VPC CNI. Plugin CNI memungkinkan Kubernetes Pod memiliki alamat IP yang sama seperti yang mereka lakukan di jaringan VPC. Lebih khusus lagi, semua kontainer di dalam Pod berbagi namespace jaringan, dan mereka dapat berkomunikasi satu sama lain menggunakan port lokal.

Amazon VPC CNI memiliki dua komponen:

Ketika sebuah instance dibuat, EC2 membuat dan melampirkan ENI primer yang terkait dengan subnet primer. Subnet utama dapat bersifat publik atau pribadi. Pod yang berjalan dalam mode HostNetwork menggunakan alamat IP utama yang ditetapkan ke ENI utama node dan berbagi namespace jaringan yang sama dengan host.

Plugin CNI mengelola E lastic Network Interfaces (ENI) pada node. Ketika sebuah node disediakan, plugin CNI secara otomatis mengalokasikan kumpulan slot (IP atau Awalan) dari subnet node ke ENI primer. Kumpulan ini dikenal sebagai kolam hangat, dan ukurannya ditentukan oleh jenis instance node. Tergantung pada pengaturan CNI, slot mungkin berupa alamat IP atau awalan. Ketika slot pada ENI telah ditetapkan, CNI dapat memasang ENI tambahan dengan kumpulan slot hangat ke node. ENI tambahan ini disebut ENI Sekunder. Setiap ENI hanya dapat mendukung sejumlah slot tertentu, berdasarkan jenis instance. CNI melampirkan lebih banyak ENI ke instance berdasarkan jumlah slot yang dibutuhkan, yang biasanya sesuai dengan jumlah Pod. Proses ini berlanjut sampai node tidak dapat lagi mendukung ENI tambahan. CNI juga melakukan pra-alokasi ENI dan slot “hangat” untuk startup Pod yang lebih cepat. Catatan setiap jenis instans memiliki jumlah maksimum ENI yang dapat dilampirkan. Ini adalah salah satu kendala pada kepadatan Pod (jumlah Pod per node), selain sumber daya komputasi.

Jumlah maksimum antarmuka jaringan, dan jumlah maksimum slot yang dapat Anda gunakan bervariasi menurut jenis Instans EC2. Karena setiap Pod menggunakan alamat IP pada slot, jumlah Pod yang dapat Anda jalankan pada Instans EC2 tertentu bergantung pada berapa banyak ENI yang dapat dilampirkan padanya dan berapa banyak slot yang didukung oleh setiap ENI. Kami menyarankan untuk mengatur Pod maksimum per panduan pengguna EKS untuk menghindari kehabisan sumber daya CPU dan memori instans. Penggunaan pod dik hostNetwork ecualikan dari perhitungan ini. Untuk informasi selengkapnya, lihat Bagaimana MaxPods ditentukan di Panduan Pengguna Amazon EKS.

Gambaran umum

Mode IP sekunder adalah mode default untuk VPC CNI. Panduan ini memberikan gambaran umum perilaku VPC CNI saat mode IP Sekunder diaktifkan. Fungsi ipamd (alokasi alamat IP) dapat bervariasi tergantung pada pengaturan konfigurasi untuk VPC CNI, sepertiMode Awalan untuk Linux,, dan. Grup Keamanan Per Pod Jaringan Kustom

Amazon VPC CNI digunakan sebagai Kubernetes Daemonset bernama aws-node pada node pekerja. Ketika node pekerja disediakan, ia memiliki ENI default, yang disebut ENI primer, yang dilampirkan padanya. CNI mengalokasikan kumpulan ENI hangat dan alamat IP sekunder dari subnet yang terpasang ke ENI utama node. Secara default, ipamd mencoba mengalokasikan ENI tambahan ke node. IPAMD mengalokasikan ENI tambahan ketika satu Pod dijadwalkan dan ditetapkan alamat IP sekunder dari ENI primer. ENI “hangat” ini memungkinkan jaringan Pod yang lebih cepat. Saat kumpulan alamat IP sekunder habis, CNI menambahkan ENI lain untuk menetapkan lebih banyak.

Jumlah ENI dan alamat IP dalam kumpulan dikonfigurasi melalui variabel lingkungan yang disebut WARM_ENI_TARGET, WARM_IP_TARGET, MINIMUM_IP_TARGET. aws-nodeDaemonset akan secara berkala memeriksa apakah jumlah ENI yang cukup terpasang. Sejumlah ENI yang cukup dilampirkan ketika semuaWARM_ENI_TARGET, atau WARM_IP_TARGET dan MINIMUM_IP_TARGET kondisi terpenuhi. Jika tidak ada cukup ENI yang terpasang, CNI akan membuat panggilan API ke EC2 untuk melampirkan lebih banyak sampai MAX_ENI batas tercapai.

Proyek ini mencakup Dokumen Excel Kalkulator Subnet. Dokumen kalkulator ini mensimulasikan konsumsi alamat IP dari beban kerja tertentu di bawah opsi konfigurasi ENI yang berbeda, seperti WARM_IP_TARGET danWARM_ENI_TARGET.

Ketika Kubelet menerima permintaan add Pod, biner CNI menanyakan ipamd untuk alamat IP yang tersedia, yang kemudian diberikan ipamd ke Pod. Biner CNI menghubungkan jaringan host dan Pod.

Pod yang digunakan pada node, secara default, ditugaskan ke grup keamanan yang sama dengan ENI utama. Atau, Pod dapat dikonfigurasi dengan grup keamanan yang berbeda.

Saat kumpulan alamat IP habis, plugin secara otomatis melampirkan antarmuka jaringan elastis lain ke instans dan mengalokasikan set alamat IP sekunder lainnya ke antarmuka itu. Proses ini berlanjut sampai simpul tidak dapat lagi mendukung antarmuka jaringan elastis tambahan.

Saat Pod dihapus, VPC CNI menempatkan alamat IP Pod dalam cache pendinginan 30 detik. IP dalam cache pendinginan tidak ditetapkan ke Pod baru. Ketika periode pendinginan berakhir, VPC CNI memindahkan IP Pod kembali ke kolam hangat. Periode pendinginan mencegah alamat IP Pod didaur ulang sebelum waktunya dan memungkinkan kube-proxy di semua node cluster untuk menyelesaikan pembaruan aturan iptables. Ketika jumlah IP atau ENI melebihi jumlah pengaturan kolam hangat, plugin ipamd mengembalikan IP dan ENI ke VPC.

Seperti dijelaskan di atas dalam mode IP Sekunder, setiap Pod menerima satu alamat IP pribadi sekunder dari salah satu ENI yang terpasang ke instance. Karena setiap Pod menggunakan alamat IP, jumlah Pod yang dapat Anda jalankan pada Instans EC2 tertentu bergantung pada berapa banyak ENI yang dapat dilampirkan padanya dan berapa banyak alamat IP yang didukungnya. VPC CNI memeriksa file batas untuk mengetahui berapa banyak ENI dan alamat IP yang diizinkan untuk setiap jenis instance.

Anda dapat menggunakan rumus berikut untuk menentukan jumlah maksimum Pod yang dapat Anda terapkan pada node.

(Number of network interfaces for the instance type * (the number of IP addresses per network interface - 1)) + 2

+2 menunjukkan Pod yang memerlukan jaringan host, seperti kube-proxy dan VPC CNI. Amazon EKS memerlukan kube-proxy dan VPC CNI untuk beroperasi pada setiap node, dan persyaratan ini diperhitungkan ke dalam nilai max-pods. Jika Anda ingin menjalankan pod jaringan host tambahan, pertimbangkan untuk memperbarui nilai max-pods. Anda dapat menentukan --kubelet-extra-args "—max-pods=110" sebagai data pengguna di template peluncuran.

Sebagai contoh, pada cluster dengan 3 node c5.large (3 ENI dan maks 10 IP per ENI), ketika cluster dimulai dan memiliki 2 pod CoreDNS, CNI akan menggunakan 50 alamat IP dan menyimpan 43 IP di kolam hangat. Kolam hangat memungkinkan peluncuran Pod lebih cepat saat aplikasi digunakan.

Node 1 (dengan pod CoreDNS): 2 ENI, 20 IP ditetapkan

Node 2 (dengan pod CoreDNS): 2 ENI, 20 IP ditetapkan

Node 3 (tanpa Pod): 1 ENI. 10 IP ditetapkan.

Untuk Node 1 dan Node 2 (konfigurasi identik):

Untuk Node 3:

Total perhitungan kolam hangat: - 17 (Node 1) + 17 (Node 2) + 9 (Node 3) = 43 IP

Perlu diingat bahwa pod infrastruktur, sering berjalan sebagai set daemon, masing-masing berkontribusi pada jumlah max-pod. Ini dapat mencakup:

Kami menyarankan Anda merencanakan infrastruktur Anda dengan menggabungkan kapasitas Pod ini. Untuk daftar jumlah maksimum Pod yang didukung oleh setiap jenis instans, lihat eni-max-pods.txt on GitHub.

Rekomendasi

Terapkan klaster EKS dengan Mode Otomatis

Saat Anda menggunakan Mode Otomatis EKS untuk membuat cluster, AWS mengelola konfigurasi VPC Container Network Interface (CNI) untuk cluster Anda. Dengan Mode Otomatis Amazon EKS, Anda tidak perlu menginstal atau meningkatkan add-on jaringan. Namun, pastikan beban kerja Anda kompatibel dengan konfigurasi VPC CNI terkelola.

Terapkan VPC CNI Managed Add-On

Saat Anda menyediakan cluster, Amazon EKS menginstal VPC CNI secara otomatis. Namun Amazon EKS mendukung add-on terkelola yang memungkinkan cluster berinteraksi dengan sumber daya AWS yang mendasarinya seperti komputasi, penyimpanan, dan jaringan. Kami sangat menyarankan Anda menerapkan cluster dengan add-on terkelola termasuk VPC CNI.

Add-on terkelola Amazon EKS menawarkan instalasi dan pengelolaan VPC CNI untuk cluster Amazon EKS. Add-on Amazon EKS menyertakan tambalan keamanan terbaru, perbaikan bug, dan divalidasi oleh AWS untuk bekerja dengan Amazon EKS. Add-on VPC CNI memungkinkan Anda untuk terus memastikan keamanan dan stabilitas cluster Amazon EKS Anda dan mengurangi jumlah upaya yang diperlukan untuk menginstal, mengonfigurasi, dan memperbarui add-on. Selain itu, add-on terkelola dapat ditambahkan, diperbarui, atau dihapus melalui Amazon EKS API, AWS Management Console, AWS CLI, dan eksctl.

Anda dapat menemukan bidang terkelola VPC CNI menggunakan --show-managed-fields flag dengan perintahkubectl get.

kubectl get daemonset aws-node --show-managed-fields -n kube-system -o yaml

Add-on terkelola mencegah penyimpangan konfigurasi dengan secara otomatis mengganti konfigurasi setiap 15 menit. Ini berarti bahwa setiap perubahan pada add-on terkelola, yang dibuat melalui API Kubernetes setelah pembuatan add-on, akan diganti oleh proses pencegahan drift-prevention otomatis dan juga diatur ke default selama proses pembaruan add-on.

Bidang yang dikelola oleh EKS terdaftar di bawah ManagedFields dengan manajer sebagai EKS. Bidang yang dikelola oleh EKS termasuk akun layanan, gambar, url gambar, probe keaktifan, probe kesiapan, label, volume, dan dudukan volume.

Kami menyarankan untuk menguji perilaku add-on di cluster non-produksi Anda untuk konfigurasi tertentu sebelum memperbarui cluster produksi. Selain itu, ikuti langkah-langkah dalam panduan pengguna EKS untuk konfigurasi add-on.

Bermigrasi ke Terkelola Add-On

Anda akan mengelola kompatibilitas versi dan memperbarui patch keamanan VPC CNI yang dikelola sendiri. Untuk memperbarui add-on yang dikelola sendiri, Anda harus menggunakan API Kubernetes dan instruksi yang diuraikan dalam panduan pengguna EKS. https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#updating-vpc-cni-add-on Sebaiknya migrasi ke add-on terkelola untuk cluster EKS yang ada dan sangat menyarankan untuk membuat cadangan pengaturan CNI Anda saat ini sebelum migrasi. Untuk mengonfigurasi add-on terkelola, Anda dapat menggunakan Amazon EKS API, AWS Management Console, atau AWS Command Line Interface.

kubectl apply view-last-applied daemonset aws-node -n kube-system  aws-k8s-cni-old.yaml

Amazon EKS akan mengganti pengaturan konfigurasi CNI jika bidang terdaftar sebagai dikelola dengan pengaturan default. Kami memperingatkan agar tidak memodifikasi bidang yang dikelola. Add-on tidak merekonsiliasi bidang konfigurasi seperti variabel lingkungan hangat dan mode CNI. Pod dan aplikasi akan terus berjalan saat Anda bermigrasi ke CNI terkelola.

Cadangkan Pengaturan CNI Sebelum Pembaruan

VPC CNI berjalan di bidang data pelanggan (node), dan karenanya Amazon EKS tidak secara otomatis memperbarui add-on (dikelola dan dikelola sendiri) saat versi baru dirilis atau setelah Anda memperbarui cluster ke versi minor Kubernetes baru. Untuk memperbarui add-on untuk cluster yang ada, Anda harus memicu pembaruan melalui update-addon API atau mengklik tautan perbarui sekarang di konsol EKS untuk add-on. Jika Anda telah menerapkan add-on yang dikelola sendiri, ikuti langkah-langkah yang disebutkan di bawah memperbarui add-on CNI VPC yang dikelola sendiri.

Kami sangat menyarankan Anda memperbarui satu versi minor pada satu waktu. Misalnya, jika versi minor Anda saat ini adalah 1.9 dan Anda ingin memperbaruinya1.11, Anda harus memperbarui ke versi patch terbaru 1.10 terlebih dahulu, lalu perbarui ke versi patch terbaru1.11.

Lakukan inspeksi pada aws-node Daemonset sebelum memperbarui Amazon VPC CNI. Ambil cadangan dari pengaturan yang ada. Jika menggunakan add-on terkelola, konfirmasikan bahwa Anda belum memperbarui pengaturan apa pun yang mungkin diganti oleh Amazon EKS. Kami merekomendasikan hook pasca pembaruan dalam alur kerja otomatisasi Anda atau langkah penerapan manual setelah pembaruan add-on.

kubectl apply view-last-applied daemonset aws-node -n kube-system  aws-k8s-cni-old.yaml

Untuk add-on yang dikelola sendiri, bandingkan cadangan dengan releases on GitHub untuk melihat versi yang tersedia dan biasakan diri Anda dengan perubahan dalam versi yang ingin Anda perbarui. Sebaiknya gunakan Helm untuk mengelola add-on yang dikelola sendiri dan memanfaatkan file nilai untuk menerapkan pengaturan. Setiap operasi pembaruan yang melibatkan penghapusan Daemonset akan mengakibatkan downtime aplikasi dan harus dihindari.

Memahami Konteks Keamanan

Kami sangat menyarankan Anda untuk memahami konteks keamanan yang dikonfigurasi untuk mengelola VPC CNI secara efisien. Amazon VPC CNI memiliki dua komponen CNI biner dan ipamd (aws-node) Daemonset. CNI berjalan sebagai biner pada node dan memiliki akses ke sistem file root node, juga memiliki akses istimewa karena berhubungan dengan iptables di tingkat node. Biner CNI dipanggil oleh kubelet saat Pod ditambahkan atau dihapus.

Aws-node Daemonset adalah proses yang berjalan lama yang bertanggung jawab untuk manajemen alamat IP di tingkat node. Aws-node berjalan dalam hostNetwork mode dan memungkinkan akses ke perangkat loopback, dan aktivitas jaringan pod lain pada node yang sama. Wadah init-container aws-node berjalan dalam mode istimewa dan memasang soket CRI yang memungkinkan Daemonset memantau penggunaan IP oleh Pod yang berjalan di node. Amazon EKS sedang bekerja untuk menghapus persyaratan istimewa dari wadah init aws-node. Selain itu, aws-node perlu memperbarui entri NAT dan memuat modul iptables dan karenanya berjalan dengan hak istimewa NET_ADMIN.

Amazon EKS merekomendasikan penerapan kebijakan keamanan seperti yang didefinisikan oleh manifes aws-node untuk manajemen IP untuk Pod dan pengaturan jaringan. Harap pertimbangkan untuk memperbarui ke versi terbaru VPC CNI. Selanjutnya, harap pertimbangkan untuk membuka GitHub masalah jika Anda memiliki persyaratan keamanan tertentu.

Gunakan peran IAM terpisah untuk CNI

AWS VPC CNI memerlukan izin AWS Identity and Access Management (IAM). Kebijakan CNI perlu diatur sebelum peran IAM dapat digunakan. Anda dapat menggunakan AmazonEKS_CNI_Policy, yang merupakan kebijakan terkelola AWS untuk cluster IPv4. Kebijakan terkelola Amazoneks CNI hanya memiliki izin untuk cluster IPv4. Anda harus membuat kebijakan IAM terpisah untuk cluster IPv6 dengan izin yang tercantum di sini.

Secara default, VPC CNI mewarisi peran IAM simpul Amazon EKS (grup node yang dikelola dan dikelola sendiri).

Sangat disarankan untuk mengonfigurasi peran IAM terpisah dengan kebijakan yang relevan untuk Amazon VPC CNI. Jika tidak, pod Amazon VPC CNI mendapatkan izin yang ditetapkan ke peran IAM node dan memiliki akses ke profil instance yang ditetapkan ke node.

Plugin VPC CNI membuat dan mengonfigurasi akun layanan yang disebut aws-node. Secara default, akun layanan mengikat peran IAM simpul Amazon EKS dengan kebijakan Amazon EKS CNI terlampir. Untuk menggunakan peran IAM terpisah, sebaiknya buat akun layanan baru dengan kebijakan Amazon EKS CNI terlampir. Untuk menggunakan akun layanan baru, Anda harus menyebarkan ulang pod CNI. Pertimbangkan --service-account-role-arn untuk menentukan add-on yang dikelola VPC CNI saat membuat cluster baru. Pastikan Anda menghapus kebijakan Amazon EKS CNI untuk IPv4 dan IPv6 dari peran simpul Amazon EKS.

Disarankan agar Anda memblokir metadata instans akses untuk meminimalkan radius ledakan pelanggaran keamanan.

Tangani Liveness/Readiness kegagalan Probe

Kami menyarankan untuk meningkatkan nilai waktu tunggu probe keaktifan dan kesiapan (defaulttimeoutSeconds: 10) untuk EKS 1.20 dan cluster yang lebih baru untuk mencegah kegagalan probe menyebabkan Pod aplikasi Anda macet dalam status ContainerCreating. Masalah ini telah terlihat pada cluster data intensif dan pemrosesan batch. Penggunaan CPU yang tinggi menyebabkan kegagalan kesehatan probe aws-node, yang menyebabkan permintaan CPU Pod yang tidak terpenuhi. Selain memodifikasi batas waktu probe, pastikan permintaan sumber daya CPU (defaultCPU: 25m) untuk aws-node dikonfigurasi dengan benar. Kami tidak menyarankan memperbarui pengaturan kecuali node Anda mengalami masalah.

Kami sangat menyarankan Anda untuk menjalankan sudo bash /opt/cni/bin/aws-cni-support.sh pada node saat Anda menggunakan dukungan Amazon EKS. Script akan membantu dalam mengevaluasi log kubelet dan pemanfaatan memori pada node. Harap pertimbangkan untuk menginstal Agen SSM di node pekerja Amazon EKS untuk menjalankan skrip.

Konfigurasikan Kebijakan Penerusan IPtables pada Instans AMI yang Dioptimalkan Non-EKS

Jika Anda menggunakan AMI khusus, pastikan untuk mengatur kebijakan penerusan iptables ke ACCEPT di bawah ku belet.service. Banyak sistem mengatur kebijakan penerusan iptables ke DROP. Anda dapat membuat AMI khusus menggunakan HashiCorp Packer dan spesifikasi build dengan sumber daya dan skrip konfigurasi dari repositori Amazon EKS AMI di AWS GitHub. Anda dapat memperbarui kubelet.service dan mengikuti petunjuk yang ditentukan di sini untuk membuat AMI kustom.

Secara Rutin Upgrade Versi CNI

VPC CNI kompatibel ke belakang. Versi terbaru bekerja dengan semua versi Kubernetes yang didukung Amazon EKS. Selain itu, VPC CNI ditawarkan sebagai add-on EKS (lihat “Menyebarkan VPC CNI Managed Add-On” di atas). Sementara add-on EKS mengatur peningkatan add-on, itu tidak akan secara otomatis meningkatkan add-on seperti CNI karena mereka berjalan di bidang data. Anda bertanggung jawab untuk meningkatkan add-on VPC CNI setelah peningkatan node pekerja yang dikelola dan dikelola sendiri.