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

Mengoptimalkan Pemanfaatan Alamat IP

Lingkungan kontainer berkembang dalam skala dengan cepat, berkat modernisasi aplikasi. Ini berarti bahwa semakin banyak node dan pod pekerja yang digunakan.

Plugin Amazon VPC CNI menetapkan setiap pod sebuah alamat IP dari CIDR VPC. Pendekatan ini memberikan visibilitas penuh alamat Pod dengan alat seperti Log Aliran VPC dan solusi pemantauan lainnya. Tergantung pada jenis beban kerja Anda, hal ini dapat menyebabkan sejumlah besar alamat IP dikonsumsi oleh pod.

Saat merancang 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 awalan IPv4 atau IPv6 ke instans Amazon Elastic Compute Cloud (Amazon EC2) Anda. 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 terperinci, silakan lihat bagian Delegasi Awalan dengan node Linux dan Delegasi Awalan dengan node Windows.

Mengurangi kelelahan IP

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

Mengadopsi IPv6 adalah 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 kehabisan alamat IP. Teknik yang paling umum digunakan di antara pelanggan Amazon EKS adalah menambahkan CIDR Sekunder yang tidak dapat dirutekan ke VPC dan mengonfigurasi VPC CNI untuk menggunakan ruang IP tambahan ini saat mengalokasikan alamat IP ke Pod. Hal ini biasa disebut sebagai Custom Networking.

Kami akan membahas variabel Amazon VPC CNI mana yang dapat Anda gunakan untuk mengoptimalkan kumpulan IP hangat yang ditetapkan 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 batasan RFC1918; kami sangat menyarankan Anda mempertimbangkan untuk mengadopsi IPv6 sebagai opsi pertama Anda ketika memilih arsitektur jaringan. IPv6 menyediakan ruang alamat IP total 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 IPv4 dan IPv6. Secara default, klaster EKS menggunakan ruang alamat IPv4. Menentukan ruang alamat berbasis IPv6 pada waktu pembuatan cluster akan memungkinkan penggunaan IPv6. Dalam cluster EKS IPv6, pod dan layanan menerima alamat IPv6 sambil mempertahankan kemampuan titik akhir IPv4 lama untuk terhubung ke layanan yang berjalan pada cluster IPv6 dan sebaliknya. Semua komunikasi pod-to-pod dalam cluster selalu terjadi melalui IPv6. Dalam VPC (/56), ukuran blok IPv6 CIDR untuk subnet IPv6 ditetapkan pada /64. Ini menyediakan 2^64 (sekitar 18 quintillion) alamat IPv6 yang memungkinkan untuk menskalakan penerapan Anda di EKS.

Untuk informasi terperinci, silakan lihat bagian Menjalankan IPv6 EKS Cluster dan untuk pengalaman langsung, silakan lihat bagian Mem ahami IPv6 di Amazon EKS dari lokakarya Dapatkan praktik langsung dengan IPv6.

Optimalkan konsumsi IP di cluster IPv4

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

Rencana untuk Pertumbuhan

Sebagai garis pertahanan pertama terhadap kelelahan IP, kami sangat menyarankan untuk mengukur VPC dan subnet IPv4 Anda dengan mempertimbangkan pertumbuhan, untuk mencegah cluster Anda menggunakan 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 peningkatan cluster, Amazon EKS membuat yang baru X-ENIs dan menghapus yang lama ketika peningkatan berhasil. Untuk alasan ini kami merekomendasikan netmask setidaknya /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 subnet IPv4 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, sebaiknya buat sub net 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 IP RFC1918, Anda dapat menggunakan pola Jaringan K ustom untuk menghemat IP yang dapat dirutekan dengan menjadwalkan Pod di dalam subnet tambahan khusus. Meskipun jaringan khusus akan menerima rentang VPC yang valid untuk rentang CIDR sekunder, sebaiknya gunakan CIDR dari ruang alamat 100.64.0.0/10 bersama (RFC 6598) karena cenderung tidak digunakan dalam pengaturan perusahaan daripada rentang RFC1918. Misalnya, Anda dapat menggunakan 100.64.0.0/16 sebagai CIDR sekunder untuk VPC Anda. Lihat batasan asosiasi blok CIDR IPv4 untuk rentang CIDR sekunder yang diizinkan.

Untuk informasi terperinci, silakan lihat bagian khusus untuk Jaringan Kustom.

Penemuan Subnet yang Ditingkatkan

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

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

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

Untuk informasi selengkapnya, lihat Amazon VPC CNI memperkenalkan Penemuan Subnet yang Ditingkatkan di blog kontainer AWS.

Optimalkan kolam hangat iPS

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

Jika subnet cluster Anda memiliki sejumlah alamat IP 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 kumpulan hangat tanpa memanggil API EC2.

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

Untuk mengkonfigurasi 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 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 perbarui default agar WARM_ENI_TARGET 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 atas 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 kelelahan IP. Misalnya, Anda dapat mengoptimalkan komunikasi di seluruh VPC atau berbagi VPC di beberapa akun untuk membatasi alokasi alamat IPv4.

Pelajari lebih lanjut tentang pola-pola ini di sini: