Gesaan dan kes penggunaan
Platform kelompok (batch) mencipta beribu-ribu Pod sekaligus, tetapi imej, kuota, topologi, atau sumber luaran masih belum sedia. Reka bentuk mekanisme yang mencipta Pod tanpa menghantarnya serta-merta ke penjadual (scheduler) Kubernetes, kemudian melepaskannya apabila syarat dipenuhi. Terangkan cara mengelakkan pembaziran kerja scheduler dan Cluster Autoscaler pada Pod Pending yang tidak sah, serta cara mengendalikan gate timeout, kegagalan pengawal (controller), dan pengasingan penyewa (tenant).
Perkara yang diuji oleh penemu duga
- Memisahkan keadaan dicipta (created state) daripada keadaan boleh dijadualkan (schedulable state).
- Memahami penciptaan, pembuangan, dan kekangan tiada penambahan (no-addition constraint)
spec.schedulingGates. - Mereka bentuk aliran pelepasan idempoten, tamat masa, kebenaran, dan pemulihan.
- Membezakan SchedulingGated, Unschedulable, dan kegagalan masa jalan (runtime).
- Membuktikan bahawa sistem tidak boleh terhenti secara senyap (silently stall) dengan metrik, peristiwa, dan rekod audit.
Soalan untuk dijelaskan terlebih dahulu
- Siapa yang menambah setiap gate, dan siapa yang mengesahkan syaratnya?
- Adakah syarat tersebut berskop Pod, kelompok, atau penyewa, dan adakah penjadualan gang (gang scheduling) diperlukan?
- Apakah kependaman pelepasan, dasar luput, had keserentakan, dan sasaran kos?
- Bagaimanakah permulaan semula pengawal, percubaan semula API, penskalaan nod, dan kebenaran yang dibatalkan harus bertindak balas?
Jawapan tiga puluh saat
Saya akan mencipta Pod dengan schedulingGates berskop ruang nama (namespace) dan menjadikan pemanasan imej, kuota, dan ketersediaan sumber luaran sebagai syarat yang boleh diperhatikan. Pengawal hanya membuang gate miliknya dan tidak sekali-kali menambah gate baharu selepas penciptaan; ia menyemak semula kuota penyewa dan dasar kelompok sebelum melepaskannya. Metrik membezakan Pod yang dikenakan gate daripada Pod yang benar-benar tidak boleh dijadualkan, dan tempoh tamat akan memasuki keadaan kegagalan eksplisit atau semakan manusia dengan syarat berversi dan rekod audit.
Jawapan mendalam, langkah demi langkah
1. Tentukan mesin keadaan (state machine)
Pisahkan Created, SchedulingGated, ReadyToSchedule, Unschedulable, Running, dan Expired. API masih boleh membaca Pod, tetapi scheduler tidak akan mencuba Pod yang senarai gate-nya tidak kosong.
2. Pilih nama gate
Setiap gate ialah syarat rentetan, seperti batch.example.com/image-ready. Letakkan versi ruang nama, kelompok, dan pengawal dalam label atau anotasi; kekalkan nama gate sebagai penyataan syarat yang belum dipenuhi dan bukannya bekas untuk data dinamik.
3. Tetapkan gate semasa penciptaan
Gate boleh dimulakan semasa penciptaan Pod oleh klien atau mutator kemasukan (admission mutator). Gate sedia ada boleh dibuang dalam sebarang susunan selepas penciptaan, tetapi gate baharu tidak boleh ditambah, jadi setiap kemungkinan syarat yang menyekat mesti disenaraikan pada masa penciptaan.
4. Reka bentuk pengawal pelepasan
Pengawal memantau Pod, kuota, pemanasan imej, dan peristiwa sumber luaran, mengira set syarat, dan menggunakan tampalan berversi sumber (resource-versioned patch). Peristiwa pendua mesti menumpu kepada hasil yang sama; setiap pengawal hanya membuang gate miliknya sendiri supaya pengawal tidak saling menulis ganti antara satu sama lain.
5. Kendalikan kelompok dan keserentakan
Rekod sumber peringkat kelompok dalam objek yang berasingan, manakala gate Pod menunggu keputusan pengawal kelompok. Buang gate dalam kelompok yang mengambil kira penyewa, keutamaan, dan keserentakan supaya scheduler dan autoscaler tidak menerima lonjakan tekanan secara tiba-tiba.
6. Reka bentuk tempoh luput dan campur tangan manusia
Kekalkan masa penciptaan, kemajuan syarat terakhir, dan tarikh akhir (deadline). Apabila tamat tempoh, jangan buang gate secara senyap; rekodkan sebab, pancarkan peristiwa, dan pilih pembatalan, percubaan semula, atau giliran manusia. Percubaan semula memerlukan backoff dan had bilangan maksimum.
7. Perhatikan baris gilir sebenar
Kubernetes mendedahkan label gated pada scheduler_pending_pods untuk membezakan Pod yang secara eksplisit belum sedia daripada Pod yang telah dicuba dan didapati tidak boleh dijadualkan. Gabungkannya dengan syarat Pod, peristiwa, panjang baris gilir pengawal, persentil umur gate, dan aktiviti autoscaler untuk mengesan kesesakan (bottleneck).
8. Kekang kebenaran dan pulihkan
Dasar kemasukan mengehadkan siapa yang boleh mencipta gate, dan pengawal hanya boleh membuang gate dengan ruang nama dan awalan yang dibenarkan. Selepas dimulakan semula, bina semula keadaan daripada API; sekiranya berlaku konflik tampalan, baca semula dan bandingkan versi sumber. Jika pengawal masih tidak tersedia, kakitangan bertugas (on-call) memerlukan prosedur pembatalan atau pelepasan yang selamat yang disokong oleh jejak audit.
Pertukaran (trade-offs) dan sempadan
Scheduling gates mengawal sama ada Pod memasuki penjadualan; ia tidak menggantikan afiniti nod, permintaan sumber, kekangan topologi, atau kesediaan masa jalan. Terlalu banyak gate menyembunyikan masalah kapasiti sebenar dalam lapisan aplikasi; terlalu sedikit gate menghantar Pod yang tidak bersedia ke scheduler. Pastikan syarat yang belum dipenuhi dibezakan daripada kluster tanpa kapasiti, dan jangan anggap gate sebagai kunci transaksi rentas objek yang umum.
Pelan pelancaran dan bukti
- Rekod pemilik setiap gate, sumber syarat, tempoh luput, dan kebenaran pembuangan.
- Sahkan awalan gate, kuota penyewa, dan set syarat masa penciptaan yang lengkap semasa kemasukan.
- Lakukan ujian beban pada scheduler, autoscaler, pelayan API, dan konflik tampalan pengawal dengan kelompok kecil terlebih dahulu.
- Pantau
scheduler_pending_pods{queue="gated"}, umur gate, kadar luput, pemprosesan pelepasan (release throughput), dan keserentakan bagi setiap penyewa. - Uji permulaan semula pengawal, sekatan rangkaian, pembatalan kebenaran, pembatalan kelompok, dan tampalan pendua, kemudian sahkan log audit.
Kesilapan biasa dan susulan
Kesilapan 1: Menambah gate selepas penciptaan
API hanya membenarkan gate semasa penciptaan dan membenarkan pembuangan selepas itu. Syarat dinamik mesti diagregatkan sebelum penciptaan atau ditunggu melalui objek berasingan sebelum mencipta Pod.
Kesilapan 2: Memanggil SchedulingGated sebagai kegagalan penjadualan
Pod dengan gate yang tidak kosong belum dicuba oleh scheduler. Bezakan gated, Unschedulable, ImagePullBackOff, dan kesediaan aplikasi.
Kesilapan 3: Menggunakan pembuangan gate sebagai kawalan kuota
Membuang gate hanya membenarkan percubaan penjadualan; ia tidak menjamin sumber. Semak semula kuota, keutamaan, dan keserentakan kelompok sebelum pelepasan.
Kesilapan 4: Mengabaikan amaran umur gate dan tempoh luput
Tanpa persentil umur, proses yang terhenti secara senyap tidak dapat dikesan. Rekodkan syarat, pengawal yang bertanggungjawab, kemajuan terkini, dan laluan pembatalan yang jelas.
Kesilapan 5: Mengabaikan kos autoscaler
Kumpulan besar Pod yang tidak bersedia boleh mencetuskan penilaian peningkatan skala (scale-up) yang sia-sia. Gunakan metrik baris gilir ber-gate dan pendikit pelepasan (release throttling) untuk mengesahkan bahawa kos benar-benar berkurangan.