Perintah dan cakupan
Sebuah Job Pod berisi kontainer batch, kontainer penerusan log, dan kontainer sinkronisasi konfigurasi. Kontainer batch selesai, tetapi kontainer log terus berjalan dan Job tetap tidak selesai; kontainer sinkronisasi juga harus menyiapkan konfigurasi sebelum batch dimulai. Jelaskan bagaimana semantik native sidecar Kubernetes menyelesaikan startup, terminasi, dan penyelesaian Job sambil menghindari hilangnya log bagian akhir (tail logs) dan perilaku yang bergantung pada versi.
Komponen dan waktu adalah asumsi wawancara, bukan default untuk setiap kluster. Pertanyaan ini cocok untuk peran platform backend, cloud-native runtime, dan SRE. Keterampilan intinya adalah keandalan siklus hidup Pod, sehingga termasuk dalam backend.
Hal yang dinilai pewawancara
Pertama, dapatkah Anda membedakan containers biasa, initContainers, dan native sidecar? Native sidecar dinyatakan di bagian init-container dengan kebijakan restart yang memungkinkannya terus berjalan setelah inisialisasi.
Kedua, dapatkah Anda menjelaskan penyelesaian Job? Native sidecar dihentikan setelah kontainer reguler selesai dan tidak membiarkan Job tetap terbuka seperti sidecar konvensional yang berjalan lama.
Ketiga, dapatkah Anda menangani dependensi dan sinyal? Sidecar sinkronisasi harus melaporkan kesiapan (readiness) sebelum kontainer utama dimulai; selama terminasi, sidecar tersebut harus menerima sinyal setelah kontainer utama dan memiliki jalur penghentian paksa yang dibatasi waktu.
Keempat, dapatkah Anda menangani kegagalan? Kegagalan startup sidecar, restart loop, backend log yang tidak tersedia, dan kegagalan kontainer utama yang terlalu dini memerlukan aturan retry, degradasi, dan observabilitas yang eksplisit.
Kelima, dapatkah Anda merencanakan kompatibilitas? Kluster yang tidak memahami semantik native sidecar dapat menolak manifes atau menjalankan perilaku lama. Gunakan capability gates, pemeriksaan versi, dan manifes fallback.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Versi Kubernetes dan kebijakan admisi mana yang mendukung native sidecar?
- Apakah sinkronisasi konfigurasi merupakan inisialisasi satu kali atau penyegaran berkelanjutan selama job berjalan?
- Ke mana log harus dikirimkan, dan berapa banyak kehilangan tail log yang dapat diterima?
- Bagaimana kode keluar kontainer utama, sidecar, dan Job retry didefinisikan?
- Apakah Pod menggunakan
restartPolicy: NeveratauOnFailure? - Apakah ada ketergantungan urutan atau perebutan shared-volume di antara sidecar?
Kerangka jawaban 30 detik
“Saya akan menempatkan kontainer yang harus mulai lebih awal dan tetap hidup di initContainers, menetapkan kebijakan restart sidecar, dan meminta proses sinkronisasi memberi sinyal ketika konfigurasi yang divalidasi sudah siap. Setelah kontainer utama selesai, controller menghentikan native sidecar sehingga Job dapat selesai; sidecar logging menangani SIGTERM dengan menghentikan input dan melakukan flush buffer sebelum batas waktu penghentian paksa. Kluster yang lebih lama menggunakan deteksi versi dan fallback kontainer konvensional. Saya akan memverifikasi urutan, kode keluar, kelengkapan tail-log, retry, dan latensi penyelesaian Job.”
Jawaban langkah demi langkah
Langkah 1: Verifikasi dukungan native-sidecar
Kubernetes menyatakan native sidecar dalam initContainers dengan restartPolicy: Always tingkat kontainer, memungkinkannya berlanjut setelah inisialisasi. Periksa versi API server, feature gates, admission controllers, dan tooling deployment; versi klien kubectl saja tidak cukup.
Langkah 2: Nyatakan urutan startup
Init container mulai secara berurutan; native sidecar dapat tetap berjalan setelah dimulai sementara inisialisasi berikutnya dan kontainer utama berjalan. Sidecar sinkronisasi harus menjadikan 'file ditulis, izin benar, versi divalidasi' sebagai kondisi kesiapannya. Kontainer utama harus memeriksa kondisi tersebut sebelum membaca shared volume.
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:v7Langkah 3: Rancang terminasi dan pembersihan (flush) log
Setelah kontainer utama selesai, sidecar logging menerima terminasi dan harus mengirim log yang di-buffer dalam jangka waktu yang dibatasi. Sidecar harus menangani SIGTERM, berhenti menerima input, melakukan flush, mengonfirmasi pengiriman, dan keluar. Atur terminationGracePeriodSeconds untuk mencakup flush terlama; SIGKILL setelahnya dapat menghilangkan tail logs, jadi catat dan beri peringatan untuk kondisi tersebut.
Langkah 4: Tentukan kegagalan dan retry
Jika sidecar sinkronisasi melakukan restart, kontainer utama tidak boleh membaca konfigurasi parsial. Kesiapan (readiness), kegagalan probe, dan penggantian shared-volume secara atomik bekerja bersama. Ketika kontainer utama gagal, Job controller menerapkan backoffLimit; restart sidecar tidak boleh dihitung sebagai upaya bisnis baru. Catat kode keluar utama, fase Pod, kondisi Job, dan status sidecar secara terpisah.
Langkah 5: Tangani semantik penyelesaian Job
Native sidecar dihentikan setelah semua kontainer reguler selesai, sehingga Job tidak tetap terbuka seperti yang dapat terjadi pada sidecar residen biasa. Jika sidecar gagal lebih awal, verifikasi perilaku kluster yang sebenarnya untuk kesiapan, restart, dan kondisi Job dengan uji integrasi daripada hanya mengandalkan diagram.
Langkah 6: Dukung kluster lama
Gunakan version gate: kluster yang tidak didukung menerima manifes containers konvensional, dan sebuah wrapper memberitahu proses logging untuk keluar ketika kontainer utama berakhir. Jaga agar manifes saling eksklusif (mutually exclusive). Selama migrasi, pantau waktu penyelesaian Job, alasan kegagalan, dan kelengkapan tail-log.
Langkah 7: Verifikasi sumber daya dan keamanan
Sidecar berbagi jaringan Pod, volume, dan kuota sumber daya. Berikan kontainer sinkronisasi dan logging alokasi requests dan limits terpisah sehingga lonjakan log tidak membuat proses batch kekurangan sumber daya; berikan hanya izin ServiceAccount yang diperlukan untuk membaca konfigurasi atau menulis log. Probe tidak boleh mengekspos kredensial, dan file sementara memerlukan izin yang membatasi.
Jawaban model
“Pertama-tama saya akan mengonfirmasi dukungan native-sidecar di API server dan rantai admisi. Proses sinkronisasi ditempatkan di initContainers dengan restartPolicy: Always; proses ini memvalidasi versi dan menulis konfigurasi secara atomik sebelum kontainer utama melanjutkan. Migrasi satu kali tetap berupa init container normal. Sidecar logging menangani terminasi setelah kontainer utama, menghentikan input, melakukan flush dan mengonfirmasi pengiriman dalam grace period yang dibatasi, lalu memperingatkan jika terjadi terminasi paksa.
Saya akan mencatat kode keluar utama, restart sidecar, kondisi Pod, Job backoff, dan kehilangan tail-log secara terpisah. Kluster yang lebih lama memilih manifes fallback kontainer konvensional, dengan wrapper yang memberi sinyal kepada logger untuk keluar. Pengujian canary memverifikasi urutan, latensi penyelesaian Job, retry, konfigurasi atomik, batas sumber daya, dan kelengkapan log.”
Kesalahan umum
- Menggunakan sidecar biasa di
containers→ Job dapat menunggu selamanya → gunakan semantik native atau koordinasi keluar eksplisit. - Membuat proses sinkronisasi berkelanjutan menjadi init sekali jalan → proses tidak dapat diperbarui selama job berjalan → tentukan persyaratan siklus hidup terlebih dahulu.
- Menggunakan readiness tanpa penulisan atomik → proses utama membaca status parsial → validasi file sementara, lalu ganti nama (rename).
- Mengabaikan jendela flush → SIGKILL menghilangkan tail logs → alokasikan waktu graceful termination untuk skenario pengiriman terburuk.
- Menghitung kegagalan sidecar sebagai kegagalan bisnis → metrik retry menjadi menyesatkan → pisahkan status kontainer dan Job.
- Mengasumsikan setiap kluster mendukung field tersebut → versi lama menolaknya atau mengubah perilaku → gunakan version gates dan manifes fallback.
- Membiarkan sumber daya sidecar tanpa batas → lonjakan log membuat beban batch kekurangan sumber daya → tetapkan requests, limits, dan peringatan independen.
- Memberikan izin berlebih pada shared volume → konfigurasi atau log dapat diubah → gunakan identitas hak istimewa terkecil (least-privilege) dan mode file yang ketat.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Mengapa native sidecar dinyatakan dalam initContainers?
Ini menjaga urutan inisialisasi sementara kebijakan restart tingkat kontainer memungkinkan sidecar tetap aktif setelah startup. Kontainer berikutnya menunggu kondisi inisialisasi yang diperlukan, dan controller menangani penghentian sidecar saat Job selesai.
Pertanyaan lanjutan 2: Bisakah sidecar selalu selesai mengirim log?
Tidak. Kegagalan jaringan, throttling, atau grace period yang singkat dapat menghilangkan data. Gunakan pembersihan (flush) yang dibatasi, buffering atau retry yang tahan lama (durable), dan ukur kelengkapan tail-log serta peringatan kehilangan log.
Pertanyaan lanjutan 3: Haruskah sinkronisasi berlanjut setelah kontainer utama gagal?
Itu tergantung pada semantik retry. Jika konfigurasi tidak dapat diubah (immutable) untuk suatu percobaan, hentikan penulisan baru dan pertahankan diagnostik. Jika setiap retry memerlukan versi baru, biarkan Pod baru atau kebijakan versi eksplisit menangani penyegaran tersebut; jangan mengubah satu percobaan secara diam-diam.
Pertanyaan lanjutan 4: Bagaimana Anda menguji urutan startup?
Tunda proses sinkronisasi, tulis status parsial, dan paksa kegagalan validasi; verifikasi bahwa kontainer utama tidak mulai. Kemudian tulis penanda penyelesaian dan verifikasi bahwa kontainer membaca versi lengkap. Uji restart, visibilitas shared-volume, dan race condition pada probe.
Pertanyaan lanjutan 5: Bagaimana Anda menjaga konsistensi fallback kluster lama?
Tempatkan pemilihan versi dalam delivery pipeline, buat manifes yang saling eksklusif, dan jalankan uji kontrak Job yang sama terhadap keduanya. Aplikasi tidak boleh menebak versi Kubernetes saat runtime.
Pertanyaan lanjutan 6: Bagaimana Anda mengetahui Job benar-benar selesai?
Periksa kondisi Job, kode keluar utama, fase Pod, alasan terminasi sidecar, dan penanda konfirmasi pengiriman log secara bersamaan. Pod dengan fase Succeeded saja dapat menyembunyikan tail logs yang hilang atau kegagalan sinkronisasi.