Mengatasi terbatasnya alamat IPv4 di Amazon EKS cluster menggunakan private NAT gateway

Perkenalan

Plugin Amazon VPC Container Network Interface (CNI) menciptakan banyak keuntungan untuk jaringan pod saat di-deploy pada Amazon Elastic Kubernetes Service (Amazon EKS) cluster. Pertama, ini memungkinkan kita menggunakan kembali jaringan Amazon Virtual Private Cloud (Amazon VPC) yang telah terbukti dan teruji dalam praktik terbaik keamanan untuk membangun Kubernetes cluster di AWS. Hal ini memungkinkan kita menggunakan VPC flow logs untuk troubleshooting dan audit compliance, menerapkan VPC routing policy untuk traffic engineering, dan menerapkan security group untuk mengetatkan isolasi dan memenuhi persyaratan peraturan. Anda mendapatkan kinerja dasar jaringan Amazon EC2, tanpa overlay tambahan.

Secara default, Amazon VPC CNI plugin menetapkan setiap pod sebuah routable IPv4 address dari blok CIDR VPC sehingga setiap pod diperlakukan sebagai first-class citizen di VPC. Hal ini memungkinkan komunikasi jaringan antar resources dalam skenario berikut: pod ke pod pada satu host, pod ke pod pada host yang berbeda, pod ke layanan AWS lainnya, pod ke on-premise data center, dan pod ke internet.

Pelanggan biasanya menggunakan private IPv4 address RFC1918 range untuk menyiapkan Amazon VPC, tempat workload di-deploy. Dalam organisasi besar, biasanya tim operasi dalam unit bisnis menyiapkan VPC khusus yang terpisah untuk memenuhi kebutuhan unit bisnis tersebut. Jika jaringan pribadi ini harus berkomunikasi dengan jaringan lain, baik di on-premise atau di VPC lain, maka mereka harus memastikan bahwa jaringan ini tidak memiliki CIDR range yang overlapping. Akibatnya, tim sering dipaksa untuk menggunakan CIDR range yang relatif lebih kecil untuk VPC mereka untuk menghindari potensi overlap. Ketika tim tersebut menggunakan platform orkestrasi container seperti Amazon EKS untuk menerapkan arsitektur microservices, mereka sering meluncurkan ratusan atau ribuan workload (pod) di cluster mereka.

Ketika Pod di-assign IPv4 address dari CIDR range VPC, ini sering menyebabkan habisnya jumlah IPv4 address yang tersedia di VPC mereka.

Menjelajahi solusi terbatasnya alamat IPV4

Jaringan custom pod adalah salah satu pendekatan untuk mengurangi terbatasnya alamat IPv4 (address exhaustion) saat menerapkan workload skala besar ke Amazon EKS cluster. Ini memungkinkan kita memperluas VPC kita dengan menambahkan secondary IPv4 address range dan kemudian menggunakan address range ini untuk meng-assign IPv4 address ke Pod. Amazon merekomendasikan penggunaan CIDR dari carrier grade-network address translation (CG-NAT) (yaitu, 100.64.0.0/10 atau 198.19.0.0/16) karena lebih kecil kemungkinannya untuk digunakan dalam pengaturan perusahaan daripada RFC1918 range lainnya. Namun, pendekatan ini menambahkan beberapa kompleksitas pada konfigurasi cluster. Masih belum ada jaminan bahwa penggunaan CG-NAT address space akan sepenuhnya menghilangkan kemungkinan jaringan yang overlapping. Jika opsi jaringan custom juga tidak layak, maka kita mungkin harus menggunakan plugin CNI berbeda yang menggunakan jaringan overlay yang non-routable untuk meng-assign IPv4 address ke pod. Kita mungkin harus menghiraukan semua keuntungan menggunakan jaringan Amazon VPC untuk pod di cluster. Solusi jangka panjang terbaik untuk masalah IPv4 exhaustion adalah dengan menggunakan IPv6. Namun, keputusan untuk mengadopsi IPv6 biasanya dilakukan di tingkat organisasi dibandingkan dengan tim operasi dalam unit bisnis individu.

Solusi private NAT gateway

Amazon VPC kini mendukung private NAT Gateway, yang dirancang untuk memungkinkan instances di private subnet VPC terhubung ke VPC lain dan jaringan on-premise dengan CIDR range yang overlapping tanpa menggunakan internet gateway. Fungsionalitas ini dapat diperluas untuk bekerja dengan Amazon EKS untuk mengatasi masalah IP exhaustion. Private NAT gateway juga mengatasi tantangan jaringan yang muncul ketika workload yang di-deploy ke Amazon EKS cluster di beberapa VPC dengan CIDR yang overlapping harus berkomunikasi satu sama lain.

Posting ini memfokuskan keuntungan menerapkan arsitektur jaringan dengan private NAT gateway untuk men-deploy Amazon EKS cluster. Kami menunjukkan kasus penggunaan di mana workload yang di-deploy dalam Amazon EKS cluster yang disediakan dalam VPC (VPC-A) dibuat untuk berkomunikasi, menggunakan private NAT gateway, dengan workload yang di-deploy ke Amazon EKS cluster lain di VPC (VPC-B) yang berbeda dengan CIDR range yang overlapping.

Arsitektur jaringan

Arsitektur jaringan yang digunakan dalam implementasi ini mengikuti rekomendasi di bawah Aktifkan komunikasi antara jaringan yang overlapping dalam dokumentasi Amazon VPC. Address range yang routable (address range yang tidak overlap) yang dipilih di sini adalah 192.168.0.0/16 dan address range yang non-routable (address range yang dapat overlap) adalah 100.64.0.0/16.

Mari asumsikan bahwa tim IP Address Management (IPAM) telah memberikan routable address range 192.168.16.0/20 untuk menyiapkan VPC. Address range 100.64.0.0/16 ditambahkan sebagai secondary CIDR untuk VPC ini. Subnet disiapkan di dua Availability Zone (AZ). Diagram jaringan berikut merincikan berbagai subnet di VPC-A, yang disiapkan menggunakan template CloudFormation dari repositori Git. Berikut adalah aspek yang menonjol dari arsitektur jaringan ini:

• Dua subnet private, masing-masing dengan 16 IP address (/28 blok) diatur dalam range yang non-routable. Sesuai rekomendasi di bawah Persyaratan dan pertimbangan subnet, subnet ini digunakan saat membuat Amazon EKS cluster. Cross-account elastic network interface (ENI) yang dibuat oleh Amazon EKS untuk mengelola komunikasi antara Amazon EKS control plane dan data plane ditempatkan di subnet ini.
• Dua subnet private lainnya, masing-masing dengan 4096 IP address (/20), diatur dalam range yang non-routable. Kubernetes Worker node dan pod di-deploy ke subnet ini dan akan di-assign IP address dari range ini saat menggunakan plugin CNI Amazon VPC. Perhatikan bahwa ukuran subnet ini (/20) dipilih sebagai contoh representatif. Subnet ini dapat dihapus dan dibuat ulang dengan ukuran yang lebih besar, jika perlu, memanfaatkan hampir seluruh address dalam range yang non-routable.
• Dua subnet private dan dua subnet public, masing-masing dengan 256 IP address (/24) diatur dalam range yang routable. Sekali lagi, ukuran subnet ini (/24) dipilih sebagai contoh yang representatif.
• Private NAT gateway ditempatkan di subnet private /24 yang routable di setiap AZ. Gateway ini me-route traffic dari Amazon EKS resource (worker node dan pod) di AZ masing-masing dan ditujukan untuk jaringan private yang routable lainnya, baik on-premise atau di VPC lainnya. Setiap private NAT gateway terlebih dahulu melakukan source NAT pada permintaan yang berasal dari resource ini sebelum me-routing ke tujuan mereka.
• Public NAT gateway ditempatkan di subnet public /24 yang routable di setiap AZ dan dikaitkan dengan internet gateway untuk memungkinkan resource di Amazon EKS cluster mengakses resource di internet.
• Untuk mengaktifkan traffic routing seperti yang dijelaskan sebelumnya, route table untuk subnet disiapkan seperti yang ditunjukkan dalam tabel berikut (keberadaan Transit gateway dalam entri route table akan segera dibahas). Perhatikan bahwa subnet /28 tidak memiliki rute apa pun untuk berkomunikasi dengan resource di luar VPC. Subnet ini hanya digunakan untuk menempatkan cross-account ENI yang dikelola Amazon EKS, yang memungkinkan komunikasi antara control plane dan kubelet pada worker node. Oleh karena itu, hanya rute lokal untuk komunikasi dalam VPC sudah cukup.
• Route table untuk subnet private /20 dalam range yang non-routable menunjukkan bahwa traffic yang ditujukan untuk address range 192.168.32.0/20 diteruskan ke private NAT gateway. Address range ini sesuai dengan VPC kedua (dibahas di bagian berikut) yang digunakan dalam implementasi ini. Secara umum, setiap traffic yang berasal dari subnet ini yang ditujukan untuk private routable address range yang bukan milik VPC-A, akan ditangani oleh private NAT gateway di AZ masing-masing.

Gambar 1. Arsitektur jaringan dengan private NAT gateway

Pembuatan Cluster

Dengan menggunakan arsitektur jaringan sebelumnya, kita sekarang siap untuk menyediakan Amazon EKS cluster di subnet VPC yang non-routable. Langkah ini tidak berbeda dengan penyediaan Amazon EKS cluster di VPC yang terdiri dari single routable address range dengan akses keluar ke internet. Ini dapat dilakukan dengan menggunakan salah satu pendekatan yang diuraikan di bawah Membuat Amazon EKS cluster .

Dua subnet /28 yang non-routable digunakan untuk pembuatan cluster. Selanjutnya, worker node disediakan dalam dua subnet /20 yang non-routable. Implementasi saat ini menggunakan template AWS CloudFormation dari repositori Git untuk pembuatan cluster dan penyediaan managed node group. Cluster memiliki perilaku default di mana endpoint server API dapat diakses dari internet. Dalam mode ini, permintaan API Kubernetes yang berasal dari dalam VPC (seperti node untuk komunikasi control plane) meninggalkan VPC tetapi bukan jaringan Amazon. Sesuai route table di atas, subnet /20 yang non-routable (dan worker node yang di-deploy di dalamnya) memiliki akses keluar ke internet melalui public NAT Gateway dan dengan demikian memiliki akses ke endpoint server API cluster. Arsitektur jaringan yang disajikan di sini berfungsi untuk cluster dengan private endpoint juga.

Selanjutnya, mari kita lihat bagaimana mengizinkan komunikasi antara VPC (VPC-A) di atas dan VPC lainnya (VPC-B) dengan address range yang routable 192.168.32.0/20 dan address range yang non-routable 100.64.0.0/16. Di VPC-B, kita membuat Amazon EKS cluster tambahan menggunakan arsitektur jaringan yang sama dengan VPC-A. Koneksi peering VPC tidak dapat digunakan antara VPC dengan CIDR yang overlapping. Oleh karena itu, transit gateway di-deploy untuk memungkinkan komunikasi antara dua VPC. transit gateway diatur dengan transit gateway attachment ke dua VPC. Attachment masing-masing diberi subnet routable pribadi /24 di VPC masing-masing.

Silakan merujuk ke Panduan Transit Gateway untuk detil tentang cara bekerja dengan transit gateway.

Gambar 2. Menghubungkan VPC dengan overlapping CIDR range menggunakan transit gateway

Saat membuat attachment VPC untuk transit gateway, blok CIDR VPC akan diberikan ke transit gateway route table secara default. Ini termasuk address range yang non-routable juga. Untuk menghindari hal ini, pemberian rute default dinonaktifkan saat membuat transit gateway. Static route ditambahkan ke route table, seperti yang ditunjukkan pada Gambar 2, setelah membuat gateway. Rute dalam transit gateway route table, bersama dengan yang ada di route table untuk subnet private yang non-routable dan routable di setiap VPC, memungkinkan resource di subnet private yang non-routable untuk mengakses resource di VPC lainnya.

Untuk panduan terperinci tentang aliran paket jaringan di seluruh VPC menggunakan jenis arsitektur jaringan ini, silakan lihat posting ini: Cara mengatasi Private IP exhaustion dengan Private NAT Solution.

Gambaran umum solusi

kita menggunakan arsitektur jaringan sebelumnya dan mendemonstrasikan kasus penggunaan dunia nyata, yang terdiri dari komponen-komponen berikut:

• Amazon EKS cluster di-deploy ke subnet yang non-routable di VPC-A.
• Layanan web HTTP di-deploy ke cluster ini sebagai resource Deployment Kubernetes dan di-expose ke internet melalui HTTP menggunakan Application Load Balancer yang dikelola oleh AWS Load Balancer Controller. Untuk memastikan bahwa load balancer ditempatkan di subnet public yang routable di VPC-A, subnet tersebut telah diberi tag kubernetes.io/role/elb=1. Atau, subnet dapat ditentukan secara eksplisit menggunakan anotasi alb.ingress.kubernetes.io/subnets diatur pada Ingress resource yang di-deploy bersama dengan layanan web.
• Amazon EKS cluster di-deploy ke subnet yang non-routable di VPC-B.
• Service web TCP di-deploy ke cluster di VPC-B sebagai Deployment Kubernetes dan di-expose secara internal ke jaringan private lainnya yang routable melalui TCP/IP menggunakan Network Load Balancer yang dikelola oleh AWS Load Balancer Controller. Ini dilakukan dengan mengatur anotasi beta.kubernetes.io/aws-load-balancer-type=external pada resource Service yang di-deploy. AWS Load balancer controller menyediakan NLB internal secara default. Subnet routable private di VPC telah diberi tag kubernetes.io/role/internal-elb=1 dan oleh karena itu, load balancer internal ditempatkan pada subnet tersebut.
• Database Amazon Aurora PostgreSQL di-deploy ke subnet private yang routable di VPC-B.

Gambar 3. Arsitektur solusi dengan dua Amazon EKS cluster menggunakan range CIDR yang overlapping

Skenario request-response untuk kasus penggunaan yang ditunjukkan di sini adalah sebagai berikut (mengacu pada langkah-langkah bernomor pada Gambar 3 di atas):

1. Client membuat request ke endpoint API /data dan /time yang di-exposed oleh layanan web HTTP. Request pertama kali dikirim ke internet-facing Application Load Balancer di VPC-A.
2. Load balancer me-route request ke salah satu Pod yang di-deploy di subnet yang non-routable di VPC-A.
3. Memanggil endpoint /data men-trigger panggilan dari service web di VPC-A ke database Amazon Aurora di VPC-B. Memanggil endpoint /time men-trigger panggilan ke Network Load Balancer internal di VPC-B. Kedua komponen ini memiliki routable private IP address dari address range yang berbeda dari VPC-A. Oleh karena itu, per rute dalam route table yang terkait dengan subnet private yang non-routable di VPC-A (lihat tabel pada Gambar 1), permintaan dari pod diteruskan ke private NAT gateway di AZ yang sesuai.
4. Private NAT gateway source NAT ke request, mengatur IP address sumber mereka ke routable IP address sendiri. Selanjutnya, rute dalam route table yang terkait dengan subnet private yang routable di VPC-A (lihat tabel pada Gambar 1) menentukan hop berikutnya. Dalam kasus penggunaan ini, permintaan dikirim ke transit gateway.
5. Bergantung pada IP tujuan, transit gateway mengirimkan request ke instance database Amazon Aurora atau ke Network Load Balancer.
6. Load balancer me-route request ke salah satu Pod yang di-deploy di subnet yang non-routable di VPC-B.

Diagram berikut menunjukkan output dari pemanggilan endpoint layanan web HTTP menggunakan custom Domain Name System (DNS) name untuk Application Load Balancer yang menghadap internet. Panggilan ke endpoint /data mengembalikan objek JSON yang diambil dari database Amazon Aurora. Panggilan ke endpoint /time mengembalikan data/waktu saat ini yang dikembalikan oleh service web TCP.

Kode sumber

Kami telah menyediakan set lengkap artefak deployment di repositori Git. Selain itu, repositori mencakup instruksi untuk menerapkan arsitektur jaringan yang dijelaskan dalam posting ini, serta langkah-langkah untuk men-deploy Amazon EKS cluster dan contoh workload. Harap cek arsitektur jaringan dan desain Amazon EKS cluster dengan tim keamanan internal Anda sebelum menerapkan ke production. Instance PostgreSQL Amazon Aurora telah digunakan dalam implementasi ini hanya sebagai contoh workload database untuk menunjukkan konektivitas ke managed service AWS dari Amazon EKS workload saat menggunakan arsitektur jaringan ini. Ikuti panduan best practice Amazon RDS untuk menggunakan database terkelola dalam production dan ikuti database user dan access model seperti yang ditentukan oleh perusahaan Anda.

Kesimpulan

Dalam posting ini, kami menunjukkan kepada Anda desain jaringan yang memungkinkan komunikasi di seluruh Amazon EKS cluster yang di-deploy ke VPC dengan CIDR yang overlapping. Arsitektur ini diaktifkan oleh private NAT gateway yang memungkinkan resource komputasi dengan private IP address dari address range yang non-routable untuk berinteraksi dengan resource dengan private IP address dari address range yang routable.

Kami juga mengatasi IPv4 address exhaustion untuk pengguna Amazon EKS yang menggunakan plugin CNI Amazon VPC untuk jaringan pod dan menerapkan ribuan pod. Ketika VPC memiliki address range yang overlapping, kita perlu menggunakan transit gateway. Anda harus melakukan analisis biaya berdasarkan harga AWS Transit Gateway dan mempertimbangkan apakah skala operasi Anda memberikan alasan yang jelas terhadap biaya tambahan menggunakan transit gateway.

Untuk kasus penggunaan di mana Amazon EKS resource dalam address range VPC yang non-routable perlu berkomunikasi dengan VPC lain yang tidak memiliki address range yang overlapping, Anda memiliki opsi untuk menggunakan VPC Peering untuk menghubungkan VPC tersebut. Metode ini dapat memberikan potensi penghematan biaya, karena semua transit data dalam AZ melalui koneksi VPC peering sekarang gratis.

Artikel ini diterjemahkan dari artikel asli berjudul “Addressing IPv4 address exhaustion in Amazon EKS clusters using private NAT gateways” yang ditulis oleh Viji Sarathy and Sheetal Joshi.