Temu duga Backend: Bagaimanakah anda menggunakan sidecar natif Kubernetes untuk kitaran hayat Job?

Kehendak soalan dan skop

Sebuah Pod Job mengandungi bekas kelompok, bekas pemajuan log dan bekas penyegerakan konfigurasi. Bekas kelompok telah selesai, tetapi bekas log terus berjalan dan Job kekal tidak selesai; bekas penyegerakan juga mesti menyediakan konfigurasi sebelum kelompok bermula. Terangkan bagaimana semantik sidecar natif Kubernetes menyelesaikan permulaan, penamatan, dan penyiapan Job sambil mengelakkan kehilangan log ekor (tail logs) serta tingkah laku yang bergantung pada versi.

Komponen dan pemasaan adalah andaian temu duga, bukan lalai untuk setiap kluster. Soalan ini sesuai untuk peranan platform backend, masa jalanan natif awan (cloud-native runtime), dan SRE. Kemahiran terasnya ialah kebolehpercayaan kitaran hayat Pod, jadi ia tergolong dalam backend.

Perkara yang dinilai oleh penemu duga

Pertama, bolehkah anda membezakan containers biasa, initContainers, dan sidecar natif? Sidecar natif dinyatakan dalam bahagian init-container dengan dasar mula semula yang membolehkannya terus berjalan selepas pemulaan.

Kedua, bolehkah anda menerangkan penyiapan Job? Sidecar natif ditamatkan selepas bekas biasa selesai dan tidak membiarkan Job terbuka seperti sidecar konvensional yang berjalan lama.

Ketiga, bolehkah anda mengendalikan kebergantungan dan isyarat? Sidecar penyegerakan mesti melaporkan kesediaan (readiness) sebelum bekas utama bermula; semasa penamatan ia harus menerima isyarat selepas bekas utama dan mempunyai laluan henti paksa yang terhad.

Keempat, bolehkah anda mengendalikan kegagalan? Kegagalan permulaan sidecar, gelung mula semula, backend log yang tidak tersedia, dan kegagalan awal bekas utama memerlukan peraturan percubaan semula (retry), degradasi, dan kebolehcerapan yang eksplisit.

Kelima, bolehkah anda merancang keserasian? Kluster yang tidak memahami semantik sidecar natif mungkin menolak manifes atau menjalankan tingkah laku lama. Gunakan pintu keupayaan (capability gates), semakan versi, dan manifes sandaran (fallback).

Soalan untuk dijelaskan terlebih dahulu

Apakah versi Kubernetes dan dasar kemasukan (admission policy) yang menyokong sidecar natif?
Adakah penyegerakan konfigurasi merupakan pemulaan sekali sahaja atau penyegaran berterusan semasa job berjalan?
Di manakah log mesti dihantar, dan berapa banyak kehilangan ekor log yang boleh diterima?
Bagaimanakah kod keluar bagi bekas utama, sidecar, dan percubaan semula Job ditakrifkan?
Adakah Pod menggunakan restartPolicy: Never atau OnFailure?
Adakah terdapat kebergantungan susunan atau pertembungan volum kongsi dalam kalangan sidecar?

Kerangka jawapan 30 saat

“Saya akan meletakkan bekas yang mesti bermula awal dan kekal hidup dalam initContainers, menetapkan dasar mula semula sidecar, dan meminta proses penyegerakan memberi isyarat apabila konfigurasi yang disahkan telah sedia. Selepas bekas utama selesai, pengawal menamatkan sidecar natif supaya Job boleh selesai; sidecar pengelogan mengendalikan SIGTERM dengan menghentikan input dan mengepam (flush) penimbal sebelum tamat masa paksa. Kluster yang lebih lama menggunakan pengesanan versi dan sandaran bekas konvensional. Saya akan mengesahkan susunan, kod keluar, kelengkapan log ekor, percubaan semula, dan kependaman penyiapan Job.”

Jawapan langkah demi langkah

Langkah 1: Sahkan sokongan sidecar natif

Kubernetes menyatakan sidecar natif dalam initContainers dengan restartPolicy: Always pada peringkat bekas, membolehkannya terus berjalan selepas pemulaan. Periksa versi pelayan API, feature gates, admission controllers, dan alatan pelaksanaan; versi klien kubectl sahaja tidak mencukupi.

Langkah 2: Nyatakan susunan permulaan

Bekas init bermula mengikut urutan; sidecar natif boleh kekal berjalan selepas ia bermula manakala pemulaan seterusnya dan bekas utama diteruskan. Sidecar penyegerakan harus menjadikan 'fail ditulis, kebenaran betul, versi disahkan' sebagai syarat kesediaannya. Bekas utama mesti menyemak syarat tersebut sebelum membaca volum kongsi.

yaml

initContainers:
- name: config-sync
  image: example/config-sync:v2
  restartPolicy: Always
  readinessProbe:
    exec:
      command: ["/bin/sh", "-c", "test -f /work/config.ready"]
- name: migrate
  image: example/migrate:v4
  command: ["/bin/sh", "-c", "./migrate && touch /work/migrate.done"]
containers:
- name: batch
  image: example/batch:v7

Langkah 3: Reka bentuk penamatan dan pengepaman log

Selepas bekas utama selesai, sidecar pengelogan menerima penamatan dan mesti menghantar log yang ditimbal dalam tempoh masa yang terhad. Ia harus mengendalikan SIGTERM, berhenti menerima input, mengepam (flush), mengesahkan penghantaran, dan keluar. Tetapkan terminationGracePeriodSeconds untuk menampung pengepaman paling lama; SIGKILL yang terkemudian boleh menghilangkan log ekor, jadi rekod dan beri amaran tentang keadaan tersebut.

Langkah 4: Takrifkan kegagalan dan percubaan semula

Jika sidecar penyegerakan dimulakan semula, bekas utama tidak boleh membaca konfigurasi separa. Kesediaan, kegagalan prob (probe), dan penggantian volum kongsi secara atomik berfungsi bersama. Apabila bekas utama gagal, pengawal Job menggunakan backoffLimit; pemulaan semula sidecar tidak boleh dikira sebagai percubaan perniagaan baharu. Rekod kod keluar utama, fasa Pod, syarat Job, dan keadaan sidecar secara berasingan.

Langkah 5: Kendalikan semantik penyiapan Job

Sidecar natif ditamatkan selepas semua bekas biasa selesai, jadi Job tidak kekal terbuka seperti yang boleh berlaku dengan sidecar pemastautin biasa. Jika sidecar gagal lebih awal, sahkan tingkah laku kluster sebenar untuk kesediaan, pemulaan semula, dan syarat Job dengan ujian integrasi dan bukannya bergantung pada rajah semata-mata.

Langkah 6: Sokong kluster lama

Gunakan pagar versi: kluster yang tidak disokong menerima manifes containers konvensional, dan pembungkus (wrapper) memberitahu proses pengelogan untuk keluar apabila bekas utama tamat. Pastikan manifes bersifat saling eksklusif (mutually exclusive). Semasa migrasi, perhatikan masa penyiapan Job, sebab kegagalan, dan kelengkapan log ekor.

Langkah 7: Sahkan sumber dan keselamatan

Sidecar berkongsi rangkaian Pod, volum, dan kuota sumber. Berikan bekas penyegerakan dan pengelogan requests dan limits yang berasingan supaya lonjakan log tidak melumpuhkan kelompok; berikan hanya kebenaran ServiceAccount yang diperlukan untuk membaca konfigurasi atau menulis log. Prob tidak boleh mendedahkan kelayakan, dan fail sementara memerlukan kebenaran yang terhad.

Jawapan model

“Mula-mula saya akan mengesahkan sokongan sidecar natif dalam pelayan API dan rantai kemasukan. Proses penyegerakan dimasukkan ke dalam initContainers dengan restartPolicy: Always; ia mengesahkan versi dan menulis konfigurasi secara atomik sebelum bekas utama diteruskan. Migrasi sekali sahaja kekal sebagai bekas init biasa. Sidecar pengelogan mengendalikan penamatan selepas bekas utama, menghentikan input, mengepam dan mengesahkan penghantaran dalam tempoh tangguh yang terhad, kemudian memberi amaran jika penamatan paksa berlaku.

Saya akan merekodkan kod keluar utama, mula semula sidecar, syarat Pod, backoff Job, dan kehilangan log ekor secara berasingan. Kluster yang lebih lama memilih manifes sandaran bekas konvensional, dengan pembungkus yang memberi isyarat kepada pengelog untuk keluar. Pengujian kenari (canary) mengesahkan susunan, kependaman penyiapan Job, percubaan semula, konfigurasi atomik, had sumber, dan kelengkapan log.”

Kesilapan biasa

Menggunakan sidecar biasa dalam containers → Job boleh menunggu selama-lamanya → gunakan semantik natif atau penyelarasan keluar yang eksplisit.
Menjadikan proses penyegerakan berterusan sebagai init sekali sahaja → ia tidak boleh disegarkan semula semasa job berjalan → takrifkan keperluan kitaran hayat terlebih dahulu.
Menggunakan kesediaan tanpa penulisan atomik → proses utama membaca keadaan separa → sahkan fail sementara, kemudian namakan semula.
Mengabaikan tetingkap pengepaman (flush) → SIGKILL menghilangkan log ekor → peruntukkan penamatan anggun untuk senario penghantaran terburuk.
Mengira kegagalan sidecar sebagai kegagalan perniagaan → metrik percubaan semula menjadi mengelirukan → asingkan keadaan bekas dan Job.
Mengandaikan setiap kluster menyokong medan tersebut → versi lama menolaknya atau mengubah tingkah laku → gunakan pagar versi dan manifes sandaran.
Membiarkan sumber sidecar tanpa had → lonjakan log melumpuhkan tugas kelompok → tetapkan requests, limits, dan makluman bebas.
Memberikan kebenaran berlebihan pada volum kongsi → konfigurasi atau log boleh diubah → gunakan identiti keistimewaan paling sedikit (least-privilege) dan mod fail yang terhad.

Soalan susulan

Soalan susulan 1: Mengapakah sidecar natif dinyatakan dalam initContainers?

Ini mengekalkan susunan pemulaan sementara dasar mula semula peringkat bekas membolehkan sidecar kekal aktif selepas permulaan. Bekas terkemudian menunggu syarat pemulaan yang diperlukan, dan pengawal mengendalikan penamatan sidecar semasa penyiapan Job.

Soalan susulan 2: Bolehkah sidecar sentiasa selesai menghantar log?

Tidak. Kegagalan rangkaian, pendikit (throttling), atau tempoh tangguh yang singkat boleh menyebabkan kehilangan data. Gunakan pengepaman terhad, penimbalan tahan lama atau percubaan semula, dan ukur kelengkapan log ekor serta amaran kehilangan.

Soalan susulan 3: Patutkah penyegerakan diteruskan selepas bekas utama gagal?

Ia bergantung pada semantik percubaan semula. Jika konfigurasi tidak boleh diubah untuk sesuatu percubaan, hentikan penulisan baharu dan kekalkan diagnostik. Jika setiap percubaan semula memerlukan versi baharu, biarkan Pod baharu atau dasar versi yang eksplisit mengendalikan penyegaran tersebut; jangan ubah satu percubaan secara senyap.

Soalan susulan 4: Bagaimanakah anda menguji susunan permulaan?

Lewatkan proses penyegerakan, tulis keadaan separa, dan paksakan kegagalan pengesahan; sahkan bahawa bekas utama tidak bermula. Kemudian tulis penanda penyiapan dan sahkan bahawa ia membaca versi yang lengkap. Uji pemulaan semula, keterlihatan volum kongsi, dan keadaan perlumbaan (race condition) prob.

Soalan susulan 5: Bagaimanakah anda memastikan sandaran kluster lama kekal konsisten?

Letakkan pemilihan versi dalam saluran paip penghantaran, jana manifes yang saling eksklusif, dan jalankan ujian kontrak Job yang sama terhadap kedua-duanya. Aplikasi tidak sepatutnya meneka versi Kubernetes semasa masa jalanan.

Soalan susulan 6: Bagaimanakah anda tahu bahawa Job benar-benar selesai?

Semak syarat Job, kod keluar utama, fasa Pod, sebab penamatan sidecar, dan penanda pengesahan penghantaran log secara bersama. Pod Succeeded sahaja boleh menyembunyikan log ekor yang hilang atau kegagalan penyegerakan.