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 kluster EKS skala besar. Dukungan EKS untuk IPv6 difokuskan pada penyelesaian masalah kelelahan IPv4, yang berasal dari ukuran terbatas ruang alamat IPv4. Ini adalah kekhawatiran signifikan yang diangkat oleh sejumlah pelanggan kami dan berbeda dari fitur dual-stack Kubernetes. IPv4/IPv6
Dalam klaster IPv6 EKS, Pod dan Layanan akan menerima alamat IPv6 sambil mempertahankan kompatibilitas dengan Endpoint IPv4 lama. Ini termasuk kemampuan endpoint IPv4 eksternal untuk mengakses layanan in-cluster, dan Pod untuk mengakses endpoint 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 yang unik (tetap) dari dalam GUA Amazon (Alamat Unicast Global); Anda dapat menetapkan awalan alamat/64 ke setiap subnet di VPC Anda. Fitur IPv4, seperti Route Tables, Network Access Control Lists, Peering, dan resolusi DNS, bekerja dengan cara yang sama dalam VPC berkemampuan IPv6. VPC kemudian disebut sebagai VPC dual-stack, mengikuti subnet dual-stack, diagram berikut menggambarkan pola pondasi VPC IPv4IPv6 yang mendukung cluster berbasis: EKS/IPv6
Di dunia IPv6, setiap alamat dapat dirutekan melalui internet. Secara default, VPC mengalokasikan IPv6 CIDR dari jangkauan GUA publik. Namun sejak Agustus 2024
Diagram berikut menggambarkan aliran keluar Internet Pod IPv6 di dalam sebuah cluster: EKS/IPv6
Praktik terbaik untuk menerapkan subnet IPv6 dapat ditemukan di panduan pengguna VPC.
Dalam klaster IPv6 EKS, node dan Pod menerima alamat IPv6 publik. EKS memberikan alamat IPv6 ke layanan berdasarkan Alamat Unicast IPv6 Lokal Unik (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:
Ikhtisar
EKS/IPv6 hanya didukung dalam mode awalan (mode penetapan IP VPC-CNI Plug-in ENI). Pelajari lebih lanjut tentang Mode Awalan.
Penetapan awalan hanya berfungsi pada instans Nitro-based EC2, oleh karena itu hanya EKS/IPv6 didukung ketika bidang data cluster menggunakan instans EC2. Nitro-based
Dengan kata sederhana awalan IPv6 dari /80 (Per worker-node) akan menghasilkan ~10^14 alamat IPv6, faktor pembatasnya bukan lagi IP tetapi kepadatan Pod (Dari segi sumber daya).
Penetapan awalan IPv6 hanya terjadi pada waktu bootstrap worker-node EKS. Perilaku ini diketahui dapat mengurangi skenario di mana EKS/IPv4 cluster churn Pod tinggi sering tertunda dalam penjadwalan Pod karena panggilan API yang dibatasi yang dihasilkan oleh plug-in VPC CNI (ipamd) yang bertujuan untuk mengalokasikan alamat IPv4 Pribadi secara tepat waktu. Hal ini juga dikenal untuk membuat VPC-CNI plug-in kenop lanjutan tuningWARM_IP/ENI, MINIMUM_IP tidak perlu.
Diagram berikut memperbesar IPv6 worker-node Elastic Network Interface (ENI):
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 egres yang sangat berpendirian. EKS mengimplementasikan plugin CNI host-lokal, sekunder dari plugin VPC CNI, yang mengalokasikan dan mengonfigurasi alamat IPv4 untuk sebuah Pod. Plugin CNI mengonfigurasi alamat IPv4 non-routable khusus host untuk sebuah Pod dari 169.254.172. 0/22 jangkauan. Alamat IPv4 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 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):
Pada diagram di atas, Pod akan melakukan pencarian DNS untuk titik akhir dan, setelah menerima respons IPv4 “A”, alamat IPv4 unik khusus node Pod diterjemahkan melalui terjemahan alamat jaringan sumber (SNAT) ke alamat Private IPv4 (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 titik akhir bersama dengan alamat IPv4. IPv4-only 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 bahwa aliran serupa ada. Diagram berikut menggambarkan aliran Pod IPv6 yang terhubung ke titik akhir IPv4 di luar batas cluster (internet routable):
Pada diagram di atas, Pod akan melakukan pencarian DNS untuk titik akhir dan, setelah menerima respons IPv4 “A”, alamat IPv4 unik khusus node Pod diterjemahkan melalui terjemahan alamat jaringan sumber (SNAT) ke alamat Private IPv4 (VPC) dari antarmuka jaringan utama yang dilampirkan ke EC2. Worker-node Alamat IPv4 Pod (Sumber IPv4: EC2 Primary IP) kemudian dirutekan ke IPv4 NAT Gateway di mana IP Utama EC2 diterjemahkan (SNAT) ke Internet routable IPv4 Public IP Address (NAT Gateway Assigned Public IP) yang valid.
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 Local IPv6 Unicast Address (ULA).
Layanan diekspos ke internet menggunakan penyeimbang beban AWS. Penyeimbang beban menerima alamat IPv4 dan IPv6 publik, alias penyeimbang beban tumpukan ganda. Untuk klien IPv4 yang mengakses layanan kubernetes cluster IPv6, load balancer melakukan terjemahan IPv4 ke 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 pengguna IPv4 internet yang mengakses layanan berbasis EKS/IPv6 Ingress:
catatan
Pola di atas memerlukan penerapan versi terbaru
EKS Kontrol Pesawat Data Pesawat 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 dilampirkan ke antarmuka jaringan utama dari sebuah node. Api-server Kubernetes berkomunikasi dengan Pod dan komponen node melalui berbasis IPv6. X-ENIs Pod berkomunikasi dengan api-server melalui X-ENIs, dan komunikasi Pod ke api-server selalu menggunakan mode IPv6.
Rekomendasi
Jadwal Berdasarkan Sumber Daya Komputasi
Satu awalan IPv6 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 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 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 dengan IPv6. Jika Anda memilih untuk menggunakan jaringan khusus untuk mengatasi masalah kelelahan 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 CIDR VPC (). IPv4IPv6 Dengan kata sederhana kepadatan luas cluster EKS/Fargate Pod Anda akan terbatas pada alamat IPv4 dan IPv6 yang tersedia. Disarankan untuk mengukur subnets/VPC CIDR tumpukan ganda Anda untuk pertumbuhan masa depan. Anda tidak akan dapat menjadwalkan Pod Fargate baru jika subnet yang mendasarinya tidak berisi alamat IPv4 yang tersedia, terlepas dari alamat IPv6 yang tersedia.
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"alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
