Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Menjalankan IPv6 EKS Cluster
EKS dalam mode IPv6 memecahkan tantangan kelelahan IPv4 yang sering dimanifestasikan dalam cluster EKS skala besar. Dukungan EKS untuk IPv6 difokuskan pada penyelesaian masalah kelelahan IPv4, yang berasal dari ukuran ruang alamat IPv4 yang terbatas. Ini adalah kekhawatiran signifikan yang diangkat oleh sejumlah pelanggan kami dan berbeda dari fitur dual-stack Kubernetes IPv4/IPv6 .
Dalam cluster EKS IPv6, Pod dan Layanan akan menerima alamat IPv6 sambil mempertahankan kompatibilitas dengan Endpoint IPv4 lama. Ini termasuk kemampuan untuk titik akhir IPv4 eksternal untuk mengakses layanan dalam cluster, dan Pod untuk mengakses titik akhir IPv4 eksternal.
Dukungan Amazon EKS IPv6 memanfaatkan kemampuan IPv6 VPC asli. Setiap VPC dialokasikan dengan awalan alamat IPv4 (ukuran blok CIDR dapat dari /16 hingga /28) dan awalan alamat IPv6 /56 unik (tetap) dari dalam GUA Amazon (Alamat Unicast Global); Anda dapat menetapkan awalan alamat /64 untuk setiap subnet di VPC Anda. Fitur IPv4, seperti Tabel Rute, Daftar Kontrol Akses Jaringan, Peering, dan resolusi DNS, bekerja dengan cara yang sama dalam VPC yang diaktifkan IPv6. VPC kemudian disebut sebagai VPC dual-stack, mengikuti subnet dual-stack, diagram berikut menggambarkan pola dasar VPC IPv4IPv6 yang mendukung cluster berbasis: EKS/IPv6
Di dunia IPv6, setiap alamat dapat dirutekan internet. Secara default, VPC mengalokasikan IPv6 CIDR dari rentang GUA publik. Namun sejak Agustus 2024
Diagram berikut menggambarkan aliran keluar Internet Pod IPv6 di dalam cluster: EKS/IPv6
Praktik terbaik untuk mengimplementasikan subnet IPv6 dapat ditemukan di panduan pengguna VPC.
Dalam cluster EKS IPv6, node dan Pod menerima alamat IPv6 publik. EKS menetapkan alamat IPv6 ke layanan berdasarkan Unique Local IPv6 Unicast Address (ULA). CIDR Layanan ULA untuk cluster IPv6 secara otomatis ditetapkan selama tahap pembuatan cluster dan tidak dapat ditentukan, tidak seperti IPv4. Diagram berikut menggambarkan pola EKS/IPv6 dasar rencana data bidang kontrol cluster berbasis:
Gambaran umum
EKS/IPv6 hanya didukung dalam mode awalan (mode VPC-CNI Plug-in penetapan IP ENI). Pelajari lebih lanjut tentang Mode Awalan.
Penetapan awalan hanya berfungsi pada instans Nitro-based EC2, karenanya hanya EKS/IPv6 didukung ketika bidang data cluster menggunakan instans EC Nitro-based 2.
Dengan kata sederhana awalan IPv6 dari /80 (Per node-pekerja) akan menghasilkan ~10^14 alamat IPv6, faktor pembatasnya tidak lagi IP tetapi kepadatan Pod (dari segi sumber daya).
Penetapan awalan IPv6 hanya terjadi pada waktu bootstrap node-pekerja EKS. Perilaku ini diketahui mengurangi skenario di mana EKS/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 mengalokasikan alamat IPv4 Pribadi secara tepat waktu. Hal ini juga dikenal untuk membuat penyetelan tombol lanj VPC-CNI utan plug-in WARM_IP/ENI, MINIMUM
Diagram berikut memperbesar ke Elastic Network Interface (ENI) node-pekerja IPv6:
Setiap node-pekerja EKS ditetapkan dengan alamat IPv4 dan IPv6, bersama dengan entri DNS yang sesuai. Untuk node pekerja tertentu, hanya satu alamat IPv4 dari subnet dual-stack yang dikonsumsi. Dukungan EKS untuk IPv6 memungkinkan Anda berkomunikasi dengan titik akhir IPv4 (AWS, on-premise, internet) melalui model IPv4 khusus egress yang sangat berpendapat. EKS mengimplementasikan plugin CNI host-lokal, sekunder dari plugin VPC CNI, yang mengalokasikan dan mengonfigurasi alamat IPv4 untuk Pod. Plugin CNI mengonfigurasi alamat IPv4 non-routable spesifik host untuk Pod dari 169.254.172. 0/22 jangkauan. Alamat IPv4 yang ditetapkan ke Pod adalah unik untuk node pekerja dan tidak diiklankan di luar simpul pekerja. 169.254.172. 0/22 menyediakan hingga 1024 alamat IPv4 unik yang dapat mendukung jenis instance besar.
Diagram berikut menggambarkan aliran Pod IPv6 yang terhubung ke titik akhir IPv4 di luar batas cluster (non-internet):
Dalam diagram di atas, Pod akan melakukan pencarian DNS untuk titik akhir dan, setelah menerima respons “A” IPv4, alamat IPv4 unik khusus node Pod diterjemahkan melalui terjemahan alamat jaringan sumber (SNAT) ke alamat IPv4 Pribadi (VPC) dari antarmuka jaringan utama yang dilampirkan ke EC2. Worker-node
catatan
Pola di atas mengharuskan DNS64 dinonaktifkan pada subnet tempat EKS/IPv6 Pod berjalan. Ketika DNS64 diaktifkan, DNS resolver mengembalikan alamat IPv6 yang disintesis untuk IPv4-only titik akhir bersama dengan alamat IPv4. Akibatnya, rute lalu lintas melalui fungsi NAT64 NAT Gateway (jika termasuk dalam arsitektur) alih-alih tetap berada di dalam VPC seperti yang ditunjukkan pada pola di atas. Hal ini dapat menyebabkan penggunaan NAT Gateway yang tidak terduga dan biaya terkait.
EKS/IPv6 Pod juga perlu terhubung ke titik akhir IPv4 melalui internet menggunakan Alamat IPv4 publik, untuk mencapai aliran serupa ada. Diagram berikut menggambarkan aliran Pod IPv6 yang terhubung ke titik akhir IPv4 di luar batas cluster (internet routable):
Dalam diagram di atas, Pod akan melakukan pencarian DNS untuk titik akhir dan, setelah menerima respons “A” IPv4, alamat IPv4 unik khusus node Pod diterjemahkan melalui terjemahan alamat jaringan sumber (SNAT) ke alamat IPv4 Pribadi (VPC) dari antarmuka jaringan utama yang dilampirkan ke EC2. Worker-node Alamat IPv4 Pod (Sumber IPv4: IP Utama EC2) kemudian dialihkan ke Gerbang NAT IPv4 di mana IP Primer EC2 diterjemahkan (SNAT) menjadi Alamat IP Publik IPv4 yang dapat dirutekan internet yang valid (NAT Gateway Assigned Public IP).
Setiap Pod-to-Pod komunikasi di seluruh node selalu menggunakan alamat IPv6. VPC CNI mengonfigurasi iptables untuk menangani IPv6 sambil memblokir koneksi IPv4 apa pun.
Layanan Kubernetes hanya akan menerima alamat IPv6 (ClusterIP) dari Unique Loc al IPv6 Unicast Address (ULA).
Layanan diekspos ke internet menggunakan penyeimbang beban AWS. Penyeimbang beban menerima alamat IPv4 dan IPv6 publik, alias penyeimbang beban dual-stack. Untuk klien IPv4 yang mengakses layanan kubernetes cluster IPv6, load balancer melakukan terjemahan IPv4 ke IPv6.
Amazon EKS merekomendasikan menjalankan node pekerja dan Pod di subnet pribadi. Anda dapat membuat penyeimbang beban publik di subnet publik yang menyeimbangkan lalu lintas ke Pod yang berjalan pada node yang berada di subnet pribadi. Diagram berikut menggambarkan pengguna IPv4 internet yang mengakses layanan berbasis EKS/IPv6 Ingress:
catatan
Pola di atas mengharuskan untuk menerapkan versi terbaru
EKS Kontrol Pesawat Data Komunikasi Pesawat
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 ke alamat IPv4 dan IPv6 yang melekat pada antarmuka jaringan utama dari sebuah node. Api-server Kubernetes berkomunikasi ke Pods dan komponen node melalui berbasis IPv6. X-ENIs Pod berkomunikasi dengan server api melalui X-ENIs, dan komunikasi Pod ke api-server selalu menggunakan mode IPv6.
Rekomendasi
Jadwal Berdasarkan Sumber Daya Komputasi
Awalan IPv6 tunggal cukup untuk menjalankan banyak Pod pada satu node. Ini juga secara efektif menghilangkan batasan ENI dan IP pada jumlah maksimum Pod pada node. Meskipun IPv6 menghilangkan ketergantungan langsung pada Max-pod, saat menggunakan lampiran awalan dengan jenis instans yang lebih kecil seperti m5.large, Anda cenderung menghabiskan sumber daya CPU dan 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 khusus.
Anda dapat menggunakan rumus berikut untuk menentukan jumlah maksimum Pod yang dapat Anda terapkan pada node untuk cluster EKS IPv6.
((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 yang direkomendasikan 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 dengan IPv6. Jika Anda memilih untuk menggunakan jaringan khusus untuk mengatasi masalah kehabisan IPv4, itu tidak lagi diperlukan dengan 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 dalam Cluster EKS/IPv6
EKS mendukung IPv6 untuk Pod yang berjalan di Fargate. Pod yang berjalan di Fargate akan menggunakan alamat IPv6 dan VPC Routable Private IPv4 yang diukir dari rentang VPC CIDR (). IPv4IPv6 Dengan kata sederhana kepadatan luas cluster EKS/Fargate Pod Anda akan terbatas pada alamat IPv4 dan IPv6 yang tersedia. Disarankan untuk mengukur CIDR dual-stack Anda untuk subnets/VPC pertumbuhan di masa mendatang. Anda tidak akan dapat menjadwalkan Pod Fargate baru jika subnet yang mendasarinya tidak berisi alamat IPv4 yang tersedia, terlepas dari alamat IPv6 yang tersedia.
Menyebarkan AWS Load Balancer Controller (LBC)
Pengontrol layanan Kubernetes dalam pohon hulu tidak mendukung IPv6. Sebaiknya gunakan add-on AWS Lo ad Balancer Controller versi "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
