Serverless Kubernetes di AWS Fargate: Arsitektur Satu Pod, Satu Node

Serverless Kubernetes lewat Amazon EKS Fargate memakai pendekatan satu pod, satu node. Setiap pod mendapat lingkungan compute sendiri, jadi kamu tidak perlu membuat, mem-patch, men-scale, atau mengganti armada worker node. Kubernetes tetap mengharapkan sebuah node yang mendaftar ke control plane, melaporkan kapasitas, menjalankan Kubelet, menyediakan networking, dan menampung workload. Fargate yang mengurus semua perilaku itu.

Saat sebuah pod dipilih untuk berjalan di Fargate, EKS menyiapkan lingkungan compute khusus, menyalakan komponen Kubernetes yang dibutuhkan, lalu memberi pod sebuah Elastic Network Interface (ENI) di virtual private cloud (VPC) milikmu. Begitu pod hilang, lingkungan itu ikut dibongkar.

Cara serverless Kubernetes mengarahkan pod ke Fargate

Satu cluster EKS bisa memakai node Amazon EC2 dan Fargate sekaligus, jadi penempatan pod harus jelas sebelum proses scheduling biasa dimulai. Penentunya adalah Fargate profile, yaitu resource AWS yang memilih pod berdasarkan namespace dan, kalau perlu, label. Profile ini juga menentukan private subnet dan security group untuk ENI milik pod, sehingga lokasi dan akses jaringan dipilih bersamaan.

Di cluster dengan Fargate aktif, AWS mengelola sebuah admission webhook di dalam control plane. Kalau pod cocok dengan profile, mutating webhook menambahkan nama profile ke label pod dan mengubah nama scheduler-nya menjadi Fargate scheduler. Keputusan ini jatuh sebelum objek pod disimpan di etcd, sehingga default scheduler tidak sempat mengambilnya.

Profile juga menetapkan pod execution role, yaitu IAM role yang dipakai infrastruktur Fargate untuk mendaftarkan kubelet dan menarik image dari Amazon ECR. Role ini terpisah dari identitas aplikasi yang dipakai container. Karena sifatnya serverless, instance metadata EC2 tidak tersedia untuk pod Fargate. Aplikasi yang memanggil layanan AWS sebaiknya memakai IAM roles for service accounts.

Scheduler khusus yang meminta kapasitas baru

Fargate scheduler berjalan di control plane Kubernetes. Ia tidak mencari tempat di kumpulan node yang sudah ada, melainkan meminta kapasitas baru sesuai kebutuhan resource pod dan Fargate profile yang cocok. Setelah kapasitas diminta, scheduler mengaitkan pod dengan nominated node secara sementara agar retry atau resync tidak memicu lingkungan kedua untuk pod yang sama. Runtime Fargate mendaftarkan objek Node saat lingkungan siap, lalu scheduler melakukan bind terakhir setelah node melapor ready. Saat pod berhenti, runtime menghapus node dan melepas kapasitasnya. Kalau provisioning atau bind gagal, proses reconciliation membersihkan penugasan sementara dan mengambil kembali kapasitas sebelum mencoba lagi.

Satu pod, satu network interface

Fargate menghubungkan setiap pod ke VPC lewat ENI-nya. Aturan security group dan routing VPC berlaku langsung pada ENI pod, bukan pada worker node bersama yang kamu kelola sendiri. Dengan begitu pod punya tempat tersendiri di VPC: VPC flow logs bisa mengenali interface-nya, dan aturan security group bisa menggambarkan batas workload yang kamu inginkan. Jalur jaringannya harus melayani dua pihak. Platform Fargate butuh jalur untuk telemetri, kredensial, dan provisioning, sedangkan komponen Kubernetes butuh jalur ke API server dan pod butuh jalur ke VPC. Fargate memisahkan keduanya dengan tiga network namespace Linux logis:

• Platform: membawa layanan platform Fargate, termasuk telemetri, credential vending, dan provisioning.
• Node: membawa komponen data-plane inti Kubernetes dan ENI milik pelanggan.
• Workload: tempat workload kamu berjalan.

ENI pelanggan dipindahkan ke node namespace, menjadi jalur komunikasi dengan control plane Kubernetes sekaligus lalu lintas pod. Task metadata endpoint bisa dijangkau dari node namespace, sehingga runtime node bisa mengambil kredensial untuk mendaftarkan node ke API server. Dari workload namespace, akses ke endpoint itu diblokir. Implementasi di balik layar bisa berubah, tetapi pemisahan ini menjaga platform terkelola, komponen node Kubernetes, dan workload tetap di jalur masing-masing.

Buat tim kecil atau pemilik usaha yang menjalankan aplikasi di AWS, model ini berarti urusan patching dan scaling node bisa dilepas. Ada konsekuensinya: akses instance metadata EC2 tidak tersedia, jadi aplikasi yang memanggil layanan AWS perlu memakai IAM roles for service accounts.