Menjalankan Kluster IPv6 EKS

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

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

EKS dalam IPv6 mode memecahkan tantangan IPv4 kelelahan yang sering dimanifestasikan dalam kelompok EKS skala besar. Dukungan EKS untuk IPv6 difokuskan pada penyelesaian masalah IPv4 kelelahan, yang berasal dari ukuran ruang alamat yang terbatas. IPv4 Ini adalah kekhawatiran signifikan yang diangkat oleh sejumlah pelanggan kami dan berbeda dari fitur IPv4IPv6 Kubernetes/dual-stack. EKS/ juga IPv6 akan memberikan fleksibilitas untuk menghubungkan batas-batas jaringan menggunakan IPv6 CIDRs sehingga meminimalkan peluang untuk menderita CIDR tumpang tindih, sehingga memecahkan masalah 2-Fold (In-Cluster, Cross-Cluster). Saat menerapkan cluster EKS dalam IPv6 mode (--ip-family ipv6), tindakannya tidak dapat dibalik. Dengan kata sederhana IPv6 dukungan EKS diaktifkan untuk seluruh masa hidup cluster Anda.

Dalam klaster IPv6 EKS, Pod dan Layanan akan menerima IPv6 alamat sambil mempertahankan kompatibilitas dengan IPv4 Endpoint lama. Ini termasuk kemampuan IPv4 endpoint eksternal untuk mengakses layanan in-cluster, dan Pod untuk mengakses endpoint eksternal IPv4 .

IPv6 Dukungan Amazon EKS memanfaatkan kemampuan IPv6 VPC asli. Setiap VPC dialokasikan dengan awalan IPv4 alamat (ukuran blok CIDR dapat dari /16 hingga /28) dan awalan alamat/56 unik (tetap) dari dalam GUA Amazon ( IPv6 Alamat Unicast Global); Anda dapat menetapkan awalan alamat/64 ke setiap subnet di VPC Anda. IPv4 fitur, seperti Tabel Rute, Daftar Kontrol Akses Jaringan, Peering, dan resolusi DNS, bekerja dengan cara yang sama di IPv6 VPC yang diaktifkan. VPC kemudian disebut sebagai VPC dual-stack, mengikuti subnet dual-stack, diagram berikut menggambarkan pola pondasi VPC yang mendukung cluster berbasis IPV4 IPv6 EKS/: IPv6

Di IPv6 dunia, setiap alamat dapat dirutekan melalui internet. Secara default, VPC mengalokasikan IPv6 CIDR dari jangkauan GUA publik. Namun sejak Agustus 2024 Anda juga dapat menggunakan IPv6 pengalamatan pribadi untuk VPCs dan subnet dengan Amazon VPC IP Address Manager (IPAM). Silakan lihat posting blog AWS Networking dan dokumentasi VPC ini untuk informasi lebih lanjut.

Diagram berikut menggambarkan aliran keluar IPv6 Internet Pod di dalam EXS/cluster: IPv6

Praktik terbaik untuk menerapkan IPv6 subnet dapat ditemukan di panduan pengguna VPC.

Dalam klaster IPv6 EKS, node dan Pod menerima IPv6 alamat publik. EKS memberikan IPv6 alamat ke layanan berdasarkan Alamat IPv6 Unicast Lokal Unik (ULA). CIDR Layanan ULA untuk IPv6 cluster secara otomatis ditetapkan selama tahap pembuatan cluster dan tidak dapat ditentukan, tidak seperti IPv4. Diagram berikut menggambarkan pola dasar rencana data bidang kontrol cluster IPv6 berbasis EKS/:

Gambaran Umum

EKS/ hanya IPv6 didukung dalam mode awalan (mode penetapan IP ENI Plug-in VPC-CNI Plug-in). Pelajari lebih lanjut tentang Mode Awalan.

Penetapan awalan hanya berfungsi pada EC2 instance berbasis Nitro, oleh karena itu EKS/ hanya didukung ketika bidang IPv6 data cluster menggunakan instance berbasis Nitro. EC2

Dengan kata sederhana IPv6 awalan /80 (Per worker-node) akan menghasilkan ~10^14 IPv6 alamat, faktor pembatasnya tidak lagi adalah kepadatan Pod (Dari segi sumber daya). IPs

IPv6 penetapan awalan hanya terjadi pada waktu bootstrap worker-node EKS. Perilaku ini diketahui dapat mengurangi skenario di mana EX/ IPv4 cluster Pod churn tinggi sering tertunda dalam penjadwalan Pod karena panggilan API yang dibatasi yang dihasilkan oleh plug-in VPC CNI (ipamd) yang bertujuan untuk mengalokasikan alamat Private secara tepat waktu. IPv4 Hal ini juga dikenal untuk membuat kenop canggih plug-in VPC-CNI menyetel WARM_IP/ENI, MINIMUM_IP tidak perlu.

Diagram berikut memperbesar ke IPv6 Worker-node Elastic Network Interface (ENI):

Setiap node pekerja EKS ditugaskan dengan IPv4 dan IPv6 alamat, bersama dengan entri DNS yang sesuai. Untuk node pekerja tertentu, hanya satu IPv4 alamat dari subnet dual-stack yang digunakan. Dukungan EKS untuk IPv6 memungkinkan Anda berkomunikasi dengan IPv4 titik akhir (AWS, on-premise, internet) melalui model egress-only yang sangat berpendirian tinggi. IPv4 EKS mengimplementasikan plugin CNI host-lokal, sekunder dari plugin VPC CNI, yang mengalokasikan dan mengonfigurasi alamat untuk sebuah Pod. IPv4 Plugin CNI mengonfigurasi IPv4 alamat non-routable khusus host untuk Pod dari rentang 169.254.172.0/22. IPv4 Alamat yang ditetapkan ke Pod adalah unik untuk worker-node dan tidak diiklankan di luar worker-node. 169.254.172.0/22 menyediakan hingga 1024 alamat unik yang dapat mendukung tipe instance besar. IPv4

Diagram berikut menggambarkan aliran IPv6 Pod yang terhubung ke IPv4 titik akhir di luar batas cluster (non-internet):

Pada diagram di atas, Pod akan melakukan pencarian DNS untuk titik akhir dan, setelah menerima respons IPv4 “A”, IPv4 alamat unik khusus node Pod diterjemahkan melalui terjemahan alamat jaringan sumber (SNAT) ke alamat Private ( IPv4 VPC) dari antarmuka jaringan utama yang dilampirkan ke Worker-Node. EC2

EKS/ IPv6 Pod juga perlu terhubung ke IPv4 titik akhir melalui internet menggunakan IPv4 Alamat publik, untuk mencapai bahwa aliran serupa ada. Diagram berikut menggambarkan aliran IPv6 Pod yang terhubung ke IPv4 titik akhir di luar batas cluster (internet routable):

Pada diagram di atas, Pod akan melakukan pencarian DNS untuk titik akhir dan, setelah menerima respons IPv4 “A”, IPv4 alamat unik khusus node Pod diterjemahkan melalui terjemahan alamat jaringan sumber (SNAT) ke alamat Private ( IPv4 VPC) dari antarmuka jaringan utama yang dilampirkan ke Worker-Node. EC2 IPv4 Alamat Pod (Sumber IPv4: IP EC2 Primer) kemudian dirutekan ke IPv4 NAT Gateway di mana IP EC2 Primer diterjemahkan (SNAT) ke dalam Alamat IP Publik (NAT Gateway IPv4 Assigned Public IP) yang valid.

Setiap Pod-to-Pod komunikasi di seluruh node selalu menggunakan IPv6 alamat. VPC CNI mengonfigurasi iptables untuk ditangani IPv6 sambil memblokir koneksi apa pun. IPv4

Layanan Kubernetes hanya akan menerima alamat IPv6 (ClusterIP) dari Unique Local Unicast Address (ULA). IPv6 CIDR Layanan ULA untuk IPv6 cluster secara otomatis ditetapkan selama tahap pembuatan klaster EKS dan tidak dapat dimodifikasi. Diagram berikut menggambarkan alur Pod ke Kubernetes Service:

Layanan diekspos ke internet menggunakan penyeimbang beban AWS. Penyeimbang beban menerima publik IPv4 dan IPv6 alamat, alias penyeimbang beban tumpukan ganda. Untuk IPv4 klien yang mengakses layanan IPv6 cluster kubernetes, load balancer melakukan penerjemahan. IPv4 IPv6

Amazon EKS merekomendasikan untuk menjalankan node pekerja dan Pod dalam subnet pribadi. Anda dapat membuat penyeimbang beban publik di subnet publik yang memuat lalu lintas keseimbangan ke Pod yang berjalan pada node yang berada di subnet pribadi. Diagram berikut menggambarkan IPv4 pengguna internet yang mengakses layanan berbasis IPv6 EKS/Ingress:

EKS Kontrol Pesawat Data Pesawat Komunikasi

EKS akan menyediakan Cross-Account ENIs (X-ENIs) dalam mode tumpukan ganda (IPv4/IPv6). Komponen node Kubernetes seperti kubelet dan kube-proxy dikonfigurasi untuk mendukung dual stack. Kubelet dan kube-proxy berjalan dalam mode HostNetwork dan mengikat keduanya IPv4 dan IPv6 alamat yang dilampirkan ke antarmuka jaringan utama dari sebuah node. Api-server Kubernetes berkomunikasi dengan Pod dan komponen node melalui X- berbasis. ENIs IPv6 Pod berkomunikasi dengan api-server melalui X-ENIs, dan komunikasi Pod ke api-server selalu menggunakan mode. IPv6

Rekomendasi

Jadwal Berdasarkan Sumber Daya Komputasi

Sebuah IPv6 awalan tunggal cukup untuk menjalankan banyak Pod pada satu node. Ini juga secara efektif menghilangkan batasan ENI dan IP pada jumlah maksimum Pod pada sebuah node. Meskipun IPv6 menghapus ketergantungan langsung pada Max-pod, saat menggunakan lampiran awalan dengan tipe instans yang lebih kecil seperti m5.large, Anda cenderung menghabiskan CPU dan sumber daya memori instans jauh sebelum Anda menghabiskan alamat IP-nya. Anda harus menetapkan nilai Pod maksimum yang direkomendasikan EKS dengan tangan jika Anda menggunakan grup node yang dikelola sendiri atau grup node terkelola dengan ID AMI kustom.

Anda dapat menggunakan rumus berikut untuk menentukan jumlah maksimum Pod yang dapat Anda gunakan pada sebuah node untuk klaster IPv6 EKS.

((Number of network interfaces for instance type (number of prefixes per network interface-1)* 16) + 2

((3 ENIs)_((10 secondary IPs per ENI-1)_ 16)) + 2 = 460 (real)

Grup node terkelola secara otomatis menghitung jumlah maksimum Pod untuk Anda. Hindari mengubah nilai rekomendasi EKS untuk jumlah maksimum Pod untuk menghindari kegagalan penjadwalan Pod karena keterbatasan sumber daya.

Mengevaluasi Tujuan Jaringan Kustom yang Ada

Jika jaringan khusus saat ini diaktifkan, Amazon EKS merekomendasikan untuk mengevaluasi kembali kebutuhan Anda untuk itu. IPv6 Jika Anda memilih untuk menggunakan jaringan khusus untuk mengatasi masalah IPv4 kelelahan, itu tidak lagi diperlukan. IPv6 Jika Anda menggunakan jaringan khusus untuk memenuhi persyaratan keamanan, seperti jaringan terpisah untuk node dan Pod, Anda disarankan untuk mengirimkan permintaan peta jalan EKS.

Pod Fargate di EKS/ Cluster IPv6

EKS mendukung IPv6 Pod yang berjalan di Fargate. Pod yang berjalan di Fargate akan menggunakan dan alamat IPv6 VPC Routable Private yang IPv4 diukir dari rentang CIDR VPC (). IPv4 IPv6 Dengan kata sederhana Anda EKS/Fargate Pods cluster wide density will be limited to the available IPv4 and IPv6 addresses. It is recommended to size your dual-stack subnets/VPC CIDRs untuk pertumbuhan masa depan. Anda tidak akan dapat menjadwalkan Pod Fargate baru jika subnet yang mendasarinya tidak berisi alamat yang tersedia, terlepas dari IPv4 alamat yang tersedia. IPv6

Menerapkan AWS Load Balancer Controller (LBC)

Pengontrol layanan Kubernetes in-tree upstream tidak mendukung. IPv6 Sebaiknya gunakan add-on AWS Load Balancer Controller versi terbaru. LBC hanya akan menerapkan NLB dual-stack atau ALB dual-stack setelah menggunakan definisi service/ingress kubernetes terkait yang dianotasi dengan: dan "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"

AWS Network Load Balancer tidak mendukung tipe alamat protokol UDP dual-stack. Jika Anda memiliki persyaratan kuat untuk latensi rendah, streaming real-time, game online, dan IoT, kami sarankan menjalankan cluster. IPv4 Untuk mempelajari lebih lanjut tentang mengelola pemeriksaan kesehatan untuk layanan UDP, silakan merujuk ke “Cara merutekan lalu lintas UDP ke Kubernetes”.