Dalam dunia aplikasi asli awan, Kubernetes telah menjadi piawaian de facto untuk orkestra kontena. Walau bagaimanapun, satu cabaran berterusan ialah ketidakupayaan penjadual untuk memahami topologi rangkaian di luar kluster. Batasan ini menjadi sangat bermasalah apabila aplikasi perlu berkomunikasi dengan perkhidmatan luaran seperti pangkalan data, di mana latensi antara zon boleh memberi kesan ketara terhadap prestasi dan kos. Satu penyelesaian baharu bernama Automatic Zone Placement sedang mencipta buzz dalam komuniti Kubernetes dengan menangani masalah ini secara tepat.
Masalah Prestasi Rentas Zon
Apabila Kubernetes menjadualkan pod tanpa kesedaran tentang lokasi sumber luaran, aplikasi mungkin berakhir dengan komunikasi merentasi zon ketersediaan tanpa perlu. Ini mencipta dua isu utama: peningkatan latensi dan kos pemindahan data yang lebih tinggi. Trafik rangkaian antara AZ dalam persekitaran awan seperti AWS dikenakan caj, dan latensi antara zon, walaupun kelihatan kecil, boleh terkumpul dengan ketara dalam aplikasi yang membuat banyak panggilan rangkaian.
Perbincangan komuniti mendedahkan bahawa ini bukan hanya kebimbangan teori. Seorang pengulas menyatakan bahawa trafik antara zon adalah kos kedua terbesar pada bil AWS kami, lebih daripada kos EC2/EKS kami, berjumlah angka pertengahan enam digit setiap tahun. Peserta lain memerhatikan bahawa latensi antara AZ biasanya diukur sekitar 0.7ms tetapi boleh melonjak kepada 3-4ms dalam beberapa kes - perbezaan magnitud yang menjadi kritikal apabila aplikasi membuat puluhan RPC untuk memenuhi satu permintaan.
Kebanyakan orang menerima peningkatan latensi kecil untuk ketersediaan lebih tinggi, tetapi saya rasa dalam kes ini, itu tidak boleh diterima.
Perbandingan Impak Prestasi
- Kependaman AZ yang sama: 0.119-0.187ms
- Kependaman merentas AZ: 0.548-0.658ms
- Peningkatan prestasi: Peningkatan 175-375% TPS
- Kos pemindahan data: ~$0.01/GB antara AZ dalam AWS
Cara Automatic Zone Placement Berfungsi
Penyelesaian ini menggunakan seni bina dua komponen yang pintar yang berfungsi dalam infrastruktur Kubernetes sedia ada. Satu perkhidmatan carian ringan bertindak sebagai otak, mengambil nama domain dan memetakannya kepada zon ketersediaan tertentu berdasarkan julat alamat IP. Perkhidmatan ini kemudiannya bersepadu dengan Kubernetes melalui webhook mutasi yang dikuasakan oleh Kyverno, yang memintas permintaan penciptaan pod dan secara automatik menyuntik peraturan afiniti nod.
Apa yang menjadikan pendekatan ini sangat elegan ialah kesederhanaan dan automasinya. Daripada memerlukan pembangun mengkonfigurasi peraturan afiniti nod secara manual yang mungkin menjadi lapuk apabila sumber luaran berpindah semasa peristiwa penyelenggaraan, sistem ini menentukan penempatan optimum secara dinamik pada masa penciptaan pod. Penyelesaian ini menggunakan peraturan afiniti preferredDuringSchedulingIgnoredDuringExecution, bermakna pod akan cuba dijadualkan dalam zon optimum tetapi masih boleh berjalan di tempat lain jika perlu.
Komponen Penyelesaian
- Perkhidmatan Carian: API berasaskan Python yang memetakan IP kepada zon
- Mutating Webhook: Enjin dasar berasaskan Kyverno
- Jenis Afiniti: preferredDuringSchedulingIgnoredDuringExecution
- Keperluan: FQDN rekod A tunggal, pemetaan subnet yang diketahui
Soalan dan Pertimbangan Komuniti
Perbincangan sekitar alat ini mendedahkan beberapa pertimbangan penting untuk penggunaan pengeluaran. Satu soalan utama yang ditimbulkan ialah tentang menangani senario limpahan: Bagaimana anda mengendalikan limpahan RDS? Mutating Webhook hanya dicetuskan apabila Pod dicipta jadi jika zon AZ tidak gagal, tiada pod untuk dicipta dan peraturan afiniti untuk diubah.
Pencipta alat itu mengakui batasan ini dalam pelaksanaan semasa, mencadangkan bahawa dasar pengimbasan latar belakang boleh ditambah untuk memeriksa dan mengemas kini penyebaran secara berkala apabila lokasi sumber luaran berubah. Ini menyerlahkan sifat dinamik persekitaran awan di mana lokasi sumber tidak statik.
Pengulas lain mempersoalkan keperluan asas untuk alat sedemikian, mencadangkan bahawa penyebaran zon tunggal mungkin memadai untuk banyak organisasi. Walau bagaimanapun, data prestasi yang dibentangkan menceritakan kisah yang menarik - penanda aras menunjukkan peningkatan 175% hingga 375% dalam transaksi sesaat apabila pod diletakkan bersama dengan pangkalan data mereka dalam zon ketersediaan yang sama.
Implikasi Lebih Luas dan Arah Masa Depan
Konsep di sebalik Automatic Zone Placement mempunyai implikasi melampaui hanya senario AWS RDS. Pengulas menyatakan bahawa pendekatan serupa boleh berfungsi untuk penyebaran di premis, di mana beban kerja boleh dijadualkan berdasarkan kedekatan fizikal dengan sumber dalam rak, baris, atau pusat data tertentu. Pencipta alat itu menyebut bekerja pada sambungan untuk perkhidmatan multi-AZ dan pengoptimuman penghalaan trafik.
Seorang ahli komuniti menegaskan bahawa penyelesaian semasa memerlukan pemetaan statik maklumat subrangkaian, mencadangkan bahawa versi masa depan boleh mengumpul data ini secara automatik melalui API pembekal awan. Ini akan menjadikan alat lebih mudah menyesuaikan diri dengan persekitaran dinamik di mana konfigurasi rangkaian berubah dengan kerap.
Metrik Latensi AWS (rantau eu-central-1)
- AZ yang sama: 0.164ms (az1), 0.119ms (az2), 0.187ms (az3)
- Merentas AZ: 0.556ms (az1-az2), 0.548ms (az1-az3), 0.658ms (az2-az3)
Kesimpulan
Automatic Zone Placement mewakili langkah penting ke hadapan dalam menjadikan Kubernetes lebih bijak tentang kesedaran infrastruktur. Dengan merapatkan jurang antara penjadualan kluster dan lokasi sumber luaran, ia menangani kebimbangan prestasi dan kos dunia sebenar yang dihadapi oleh banyak organisasi dalam persekitaran pengeluaran. Walaupun penyelesaian ini mempunyai batasan sekitar pengendalian limpahan dan memerlukan beberapa konfigurasi manual, konsep itu menunjukkan bagaimana Kubernetes boleh berkembang untuk lebih memahami dan mengoptimumkan ekosistem infrastruktur yang lebih luas yang dioperasikannya. Apabila teknologi asli awan matang, alat seperti ini menyerlahkan keperluan berterusan untuk penempatan sumber yang lebih pintar dan pengoptimuman rangkaian dalam sistem teragih.
Rujukan: Automatic zone placement service