Menskalakan Kubernetes agar dapat menggunakan ribuan CRD

Crossplane buatan Upbound menyediakan control plane cloud di Kubernetes. Karena itu, ada ratusan CRD (Custom Resource Definition) untuk merepresentasikan resource cloud seperti AWS, Azure, dan GCP. Di Crossplane, ini disebut MR (Managed Resource).

Bahkan pengguna Kubernetes tingkat lanjut pun biasanya mengelola jumlah CR yang wajar, sekitar puluhan, tetapi di Crossplane perlu menggunakan ratusan MR, sehingga mulai diteliti batas seberapa banyak CRD yang dapat ditangani Kubernetes.

Ini dapat dibagi menjadi masalah sisi klien dan masalah sisi server.

Masalah sisi klien

• Di sisi klien, proses discovery menjadi masalah.
• Saat klien seperti kubectl melakukan discovery untuk mencari API apa yang disediakan server, ia harus menelusuri semua API endpoint satu kali.
• CR disediakan sebagai API endpoint.
• Untuk melihat MR seperti https://example.org/apis/rds.aws.upbound.io/v1/instances/cool-db, klien harus mencari grup API yang didukung di https://example.org/apis/, lalu versi yang didukung di https://example.org/apis/rds.aws.upbound.io, lalu CR yang didukung di https://example.org/apis/rds.aws.upbound.io/v1.
• Crossplane MR yang menyediakan cloud provider AWS, Azure, dan GCP berjumlah sekitar 2.000 dan dibagi ke dalam 300 grup API dan versi.
• Klien akan mengirim 300 permintaan HTTP untuk discovery.
• Dalam kondisi jaringan modern ini bukan masalah besar, tetapi masalah yang ditemukan adalah rate limit dan cache.

Rate limit klien

• Diterapkan rate limit rata-rata 5 permintaan per detik (burst hingga 100), dan cache discovery dinonaktifkan setiap 10 menit.
• Ini bisa diatasi dengan menaikkan rate limit; saat ini tetap 5 permintaan per detik secara default, tetapi kini bisa dinaikkan hingga 300.
• Pada kubectl v1.22 diajukan issue untuk menaikkan batas ini, dan cache discovery juga diubah dari 10 menit menjadi 5 jam, sehingga pada Kubernetes v1.25 dapat memanfaatkan batas klien yang ditingkatkan.

Cache klien

• Bahkan setelah rate limit dimatikan untuk pengujian, tetap butuh hampir 20 detik untuk melihat 300 grup API.
• Awalnya diduga masalah jaringan, tetapi ternyata penyebabnya adalah proses pembacaan file cache.
• Ini diperbaiki di Kubernetes 1.25 sehingga menjadi 25 kali lebih cepat di macOS dan 2 kali lebih cepat di Linux.

Peningkatan klien selanjutnya

• Menerapkan rate limit di klien memang masuk akal, tetapi sebenarnya tidak benar-benar melindungi server.
• API Priority and Fairness (AP&F), yang diperkenalkan di Kubernetes 1.20, menyediakan queue dan traffic shaping di sisi server untuk melindungi API server.
• Satu HTTP endpoint teragregasi untuk discovery telah disetujui dalam KEP dan dijadwalkan didukung sebagai alpha di 1.26.

Masalah sisi server

Perhitungan skema OpenAPI

• Setelah mendaftarkan ratusan CRD, ditemukan bahwa permintaan API menjadi lambat selama hampir satu jam.
• Melalui profiling, diketahui bahwa masalah ini disebabkan oleh logika perhitungan skema OpenAPI v2.
• Saat CRD ditambahkan atau diperbarui, OpenAPI controller membangun spesifikasi swagger untuk CR, menggabungkannya dengan swagger semua CR menjadi satu spesifikasi besar, lalu men-serialisasinya ke JSON dan menyediakannya di /openapi/v2.
• Ini diperbaiki dengan membuat /openapi/v2 dihitung secara lazy, sehingga baru dihitung saat endpoint untuk CR yang sebenarnya diminta.
• Perbaikan ini masuk ke v1.24.0, dan di-backport ke 1.20.13, 1.21.7, dan 1.22.4.

Klien etcd

• Ini adalah bottleneck baru yang ditemukan setelah masalah OpenAPI diselesaikan.
• Diketahui bahwa API server menggunakan memori 4MiB per CRD.
• Ini lebih bermasalah pada managed Kubernetes seperti GKE dan EKS, karena CPU dan memori API server dibatasi. Jika butuh resource tambahan, API server akan diskalakan otomatis, tetapi sayangnya penambahan CRD bukan faktor yang dipakai untuk memutuskan scaling. Jadi, kecuali API server berulang kali terkena OOM killed, ia tidak akan diskalakan.
• Saat diuji di GKE, AKE, dan EKS, auto-healing memang terjadi, tetapi API server tidak dapat digunakan selama 5 detik hingga 1 jam. Cluster tidak benar-benar berhenti total, tetapi semua reconciliation berhenti.
• Melalui profiling diketahui bahwa Zap, library logging, memakan 20% dari memori.
• API server membuat satu klien etcd untuk setiap versi CR, dan setiap klien etcd membuat logger Zap.
• Akibatnya, bukan hanya memori meningkat karena logger yang duplikat, tetapi juga muncul koneksi TCP yang tidak perlu antara API server dan etcd.
• Maintainer juga setuju bahwa seharusnya satu klien etcd digunakan untuk semua endpoint CR, tetapi karena rilis Kubernetes 1.25 sudah dekat, sulit memperbaiki semuanya sekaligus, sehingga dilakukan perubahan yang lebih kecil agar semua klien etcd berbagi satu logger.
  -Ini dijadwalkan masuk ke 1.25 dan akan di-backport ke 1.22, 1.23, dan 1.24. Ini akan mengurangi penggunaan memori sebesar 20%.

Peningkatan sisi server selanjutnya

• Klien etcd yang sebelumnya dibuat untuk setiap versi CR akan diubah menjadi satu per transport (satu per cluster etcd).
• Tim engineering GKE, EKS, dan AKE juga diajak bekerja sama untuk menangani instalasi banyak CRD Crossplane.

[roxie]

digratiskan -> dibatalkan

[roxie]

klaiyent -> klien