Mengoptimalkan Pemanfaatan Alamat IP

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.

Lingkungan kontainer tumbuh dalam skala dengan cepat, berkat modernisasi aplikasi. Ini berarti semakin banyak node dan pod pekerja yang sedang di-deploy.

Plugin Amazon VPC CNI memberikan setiap pod alamat IP dari CIDR (s) VPC. Pendekatan ini memberikan visibilitas penuh dari alamat Pod dengan alat seperti VPC Flow Logs dan solusi pemantauan lainnya. Bergantung pada jenis beban kerja Anda, hal ini dapat menyebabkan sejumlah besar alamat IP dikonsumsi oleh pod.

Saat mendesain arsitektur jaringan AWS Anda, penting untuk mengoptimalkan konsumsi IP Amazon EKS di VPC dan di tingkat node. Ini akan membantu Anda mengurangi masalah kelelahan IP dan meningkatkan kepadatan pod per node.

Pada bagian ini, kita akan membahas teknik yang dapat membantu Anda mencapai tujuan ini.

Optimalkan konsumsi IP tingkat node

Delegasi awalan adalah fitur Amazon Virtual Private Cloud (Amazon VPC) yang memungkinkan Anda menetapkan atau IPv4 awalan IPv6 ke instans Amazon Elastic Compute Cloud (Amazon) Anda. EC2 Ini meningkatkan alamat IP per antarmuka jaringan (ENI), yang meningkatkan kepadatan pod per node dan meningkatkan efisiensi komputasi Anda. Delegasi awalan juga didukung dengan Custom Networking.

Untuk informasi lebih lanjut, silakan lihat Delegasi Awalan dengan node Linux dan Delegasi Awalan dengan bagian node Windows.

Mengurangi kelelahan IP

Untuk mencegah cluster Anda mengkonsumsi semua alamat IP yang tersedia, kami sangat menyarankan untuk mengukur ukuran VPCs dan subnet Anda dengan mempertimbangkan pertumbuhan.

Mengadopsi IPv6adalah cara yang bagus untuk menghindari masalah ini sejak awal. Namun, untuk organisasi yang kebutuhan skalabilitasnya melebihi perencanaan awal dan tidak dapat mengadopsi IPv6, meningkatkan desain VPC adalah respons yang disarankan terhadap kelelahan alamat IP. Teknik yang paling umum digunakan di antara pelanggan Amazon EKS adalah menambahkan Secondary non-routable CIDRs ke VPC dan mengonfigurasi VPC CNI untuk menggunakan ruang IP tambahan ini saat mengalokasikan alamat IP ke Pod. Ini biasanya disebut sebagai Custom Networking.

Kami akan membahas variabel mana dari Amazon VPC CNI yang dapat Anda gunakan untuk mengoptimalkan kumpulan hangat yang IPs ditugaskan ke node Anda. Kami akan menutup bagian ini dengan beberapa pola arsitektur lain yang tidak intrinsik untuk Amazon EKS tetapi dapat membantu mengurangi kelelahan IP.

Gunakan IPv6 (disarankan)

Mengadopsi IPv6 adalah cara termudah untuk mengatasi RFC1918 keterbatasan; kami sangat menyarankan Anda mempertimbangkan mengadopsi IPv6 sebagai opsi pertama Anda ketika memilih arsitektur jaringan. IPv6 menyediakan total ruang alamat IP yang jauh lebih besar, dan administrator cluster dapat fokus pada migrasi dan penskalaan aplikasi tanpa mencurahkan upaya untuk mengatasi batas. IPv4

Cluster Amazon EKS mendukung keduanya IPv4 dan IPv6. Secara default, kluster EKS menggunakan ruang IPv4 alamat. Menentukan ruang alamat IPv6 berbasis pada waktu pembuatan cluster akan memungkinkan penggunaan. IPv6 Dalam klaster IPv6 EKS, pod dan layanan menerima IPv6 alamat sambil mempertahankan kemampuan IPv4 endpoint lama untuk terhubung ke layanan yang berjalan di IPv6 cluster dan sebaliknya. Semua pod-to-pod komunikasi dalam sebuah cluster selalu terjadi IPv6. Dalam VPC (/56), ukuran blok IPv6 CIDR untuk IPv6 subnet ditetapkan pada /64. Ini menyediakan 2 ^ 64 (sekitar 18 triliun) IPv6 alamat yang memungkinkan untuk menskalakan penerapan Anda di EKS.

Untuk informasi terperinci, silakan lihat bagian Menjalankan Kluster IPv6 EKS dan untuk pengalaman langsung, silakan lihat bagian Memahami tentang IPv6 Amazon EKS dari lokakarya Dapatkan langsung dengan. IPv6

Optimalkan konsumsi IP dalam IPv4 cluster

Bagian ini didedikasikan untuk pelanggan yang menjalankan aplikasi lama, dan/atau tidak siap untuk bermigrasi. IPv6 Meskipun kami mendorong semua organisasi untuk bermigrasi IPv6 sesegera mungkin, kami menyadari bahwa beberapa mungkin masih perlu melihat pendekatan alternatif untuk meningkatkan beban kerja kontainer mereka. IPv4 Untuk alasan ini, kami juga akan memandu Anda melalui pola arsitektur untuk mengoptimalkan IPv4 (RFC1918) mengatasi konsumsi ruang dengan cluster Amazon EKS.

Rencana untuk Pertumbuhan

Sebagai garis pertahanan pertama terhadap kelelahan IP, kami sangat menyarankan untuk mengukur subnet Anda IPv4 VPCs dan dengan mempertimbangkan pertumbuhan, untuk mencegah cluster Anda mengkonsumsi semua alamat IP yang tersedia. Anda tidak akan dapat membuat Pod atau node baru jika subnet tidak memiliki cukup alamat IP yang tersedia.

Sebelum membangun VPC dan subnet, disarankan untuk bekerja mundur dari skala beban kerja yang diperlukan. Misalnya, ketika cluster dibangun menggunakan eksctl (alat CLI sederhana untuk membuat dan mengelola cluster di EKS) /19 subnet dibuat secara default. Netmask dari /19 cocok untuk sebagian besar jenis beban kerja yang memungkinkan lebih dari 8000 alamat dialokasikan.

Selain itu, Amazon EKS, dapat membuat hingga 4 antarmuka jaringan elastis (X-ENI) yang diperlukan untuk memungkinkan komunikasi menuju bidang kontrol (info lebih lanjut di sini). Selama upgrade cluster, Amazon EKS membuat X- baru ENIs dan menghapus yang lama ketika upgrade berhasil. Untuk alasan ini kami merekomendasikan netmask minimal /28 (16 alamat IP) untuk subnet yang terkait dengan cluster EKS.

Anda dapat menggunakan contoh spreadsheet EKS Subnet Calculator untuk merencanakan jaringan Anda. Spreadsheet menghitung penggunaan IP berdasarkan beban kerja dan konfigurasi VPC ENI. Penggunaan IP dibandingkan dengan IPv4 subnet untuk menentukan apakah konfigurasi dan ukuran subnet cukup untuk beban kerja Anda. Perlu diingat bahwa, jika subnet di VPC Anda kehabisan alamat IP yang tersedia, kami sarankan untuk membuat subnet baru menggunakan blok CIDR asli VPC. Perhatikan bahwa sekarang Amazon EKS sekarang memungkinkan modifikasi subnet cluster dan grup keamanan.

Jaringan Kustom

Jika Anda akan menghabiskan ruang RFC1918 IP, Anda dapat menggunakan pola Custom Networking untuk menghemat routable IPs dengan menjadwalkan Pod di dalam subnet tambahan khusus. Meskipun jaringan khusus akan menerima rentang VPC yang valid untuk rentang CIDR sekunder, kami menyarankan Anda menggunakan CIDRs (/16) dari ruang CG-NAT, yaitu 100.64.0.0/10 atau 198.19.0.0/16 karena mereka cenderung tidak digunakan dalam pengaturan perusahaan daripada rentang. RFC1918

Untuk informasi rinci silahkan lihat bagian khusus untuk Custom Networking.

Penemuan Subnet yang Ditingkatkan

Enhanced Subnet Discovery menyediakan alternatif konfigurasi jaringan yang efisien untuk kelelahan IP, dengan menandai subnet baru sehingga dapat ditemukan oleh Amazon VPC CNI. Dengan Enhanced Subnet Discovery, beban kerja saat ini dapat terus berjalan pada subnet yang sama dan Amazon Elastic Kubernetes Service (Amazon EKS) sekarang dapat menjadwalkan pod tambahan pada “subnet yang dapat digunakan” baru.

Jika subnet klaster Anda saat ini kehabisan alamat IP, Anda cukup menambahkan subnet tambahan ke cluster Amazon EKS Anda sebagai berikut:

Setelah Enhanced Subnet Discovery diaktifkan pada kluster VPC dan Amazon EKS Anda, Elastic Network Interfaces ENIs () baru akan dilampirkan ke node Amazon EKS Anda seperti yang dijelaskan dalam diagram berikut:

Untuk informasi selengkapnya, lihat Amazon VPC CNI memperkenalkan Enhanced Subnet Discovery di blog AWS container.

Optimalkan kolam IPs hangat

Dengan konfigurasi default, VPC CNI menyimpan seluruh ENI (dan terkait IPs) di kolam hangat. Ini mungkin menghabiskan sejumlah besar IPs, terutama pada jenis instance yang lebih besar.

Jika subnet cluster Anda memiliki jumlah alamat IP terbatas yang tersedia, teliti variabel lingkungan konfigurasi VPC CNI ini:

Anda dapat mengonfigurasi nilai MINIMUM_IP_TARGET agar sesuai dengan jumlah Pod yang Anda harapkan untuk dijalankan di node Anda. Melakukannya akan memastikan bahwa saat Pod dibuat, dan CNI dapat menetapkan alamat IP dari kolam hangat tanpa memanggil API. EC2

Harap diperhatikan bahwa menyetel nilai WARM_IP_TARGET terlalu rendah, akan menyebabkan panggilan tambahan ke EC2 API, dan itu dapat menyebabkan pembatasan permintaan. Untuk cluster besar gunakan bersama dengan MINIMUM_IP_TARGET untuk menghindari pembatasan permintaan.

Untuk mengonfigurasi opsi ini, Anda dapat mengunduh aws-k8s-cni.yaml manifes dan mengatur variabel lingkungan. Pada saat penulisan, rilis terbaru terletak di sini. Periksa versi nilai konfigurasi yang cocok dengan versi VPC CNI yang diinstal.

Anda dapat menyesuaikan parameter CNI dengan cepat tanpa downtime untuk aplikasi yang ada, tetapi Anda harus memilih nilai yang akan mendukung kebutuhan skalabilitas Anda. Misalnya, jika Anda bekerja dengan beban kerja batch, sebaiknya update default WARM_ENI_TARGET agar sesuai dengan kebutuhan skala Pod. Pengaturan WARM_ENI_TARGET ke nilai tinggi selalu mempertahankan kumpulan IP hangat yang diperlukan untuk menjalankan beban kerja batch besar dan karenanya menghindari penundaan pemrosesan data.

Pantau Inventaris Alamat IP

Selain solusi yang dijelaskan di atas, penting juga untuk memiliki visibilitas melalui pemanfaatan IP. Anda dapat memantau inventaris alamat IP subnet menggunakan CNI Metrics Helper. Beberapa metrik yang tersedia adalah:

Anda juga dapat mengatur CloudWatch alarm untuk mendapatkan pemberitahuan jika subnet kehabisan alamat IP.

Pertimbangan lebih lanjut

Ada pola arsitektur lain yang tidak intrinsik untuk Amazon EKS yang dapat membantu mengatasi kelelahan IP. Misalnya, Anda dapat mengoptimalkan komunikasi di seluruh VPCs atau berbagi VPC di beberapa akun untuk membatasi alokasi IPv4 alamat.

Pelajari lebih lanjut tentang pola-pola ini di sini: