Perintah dan konteks
Sebuah batch Job memerlukan Sidecar untuk logging, proxy, atau sinkronisasi file. Setelah kontainer utama selesai, Job tidak boleh tetap berstatus Pending karena helper berjalan selamanya; selama terminasi Pod, Sidecar harus tetap memiliki kesempatan untuk melakukan flush sebelum keluar. Jelaskan siklus hidup Sidecar Kubernetes, sumber daya bersama, dan perilaku kegagalan.
Pertanyaan ini cocok untuk peran system-design, platform-engineering, dan cloud-native. Kuncinya adalah memisahkan kondisi penyelesaian Pod, Job, kontainer utama, dan Sidecar sambil merancang batasan yang dapat diobservasi dan dapat dicoba ulang.
Apa yang dievaluasi oleh pewawancara
Jawaban yang kuat mencatat bahwa model Sidecar yang stabil dapat dinyatakan sebagai init container dengan restartPolicy: Always; ini berjalan secara konkuren dengan kontainer utama, berbagi jaringan dan secara opsional volume, memungkinkan Job selesai setelah kontainer utama selesai, dan diterminasi setelah aplikasi utama dalam urutan deklarasi terbalik. Jawaban tersebut juga harus mencakup probe, anggaran sumber daya, percobaan ulang, idempotensi, dan sinyal.
Klarifikasi yang perlu ditanyakan terlebih dahulu
- Apakah Sidecar menyediakan logging, proxying, sinkronisasi, atau keamanan, dan apakah harus siap sebelum tugas utama dimulai?
- Data apa yang harus bertahan dari keberhasilan, kegagalan, batas waktu (timeout), dan percobaan ulang kontainer utama?
- Berapa ukuran volume bersama, laju penulisan, izin, dan jendela pembersihan?
- Apakah penyelesaian Job didasarkan pada keluarnya kontainer utama, pengosongan (drain) Sidecar yang eksplisit, atau keduanya?
- Metrik, peristiwa (events), log, dan trace mana yang menemukan kegagalan di antara kedua kontainer?
Jawaban 30 detik
“Saya akan memodelkan Sidecar sebagai layanan pendukung yang berjalan konkuren dengan kontrak kesiapan (readiness), kegagalan, dan drain yang eksplisit. Saya akan menggunakan semantik Sidecar Kubernetes sehingga Job dapat selesai ketika kontainer utama selesai sambil mempertahankan jalur volume bersama dan drain log. Setiap kontainer mendapatkan probe, anggaran sumber daya, dan observabilitas; batas waktu, percobaan ulang, SIGTERM, dan pembersihan idempoten telah ditentukan. Saya akan menguji keberhasilan, kegagalan, crash pada Sidecar, dan penggusuran (eviction) node.”
Solusi langkah demi langkah
Langkah 1: Tentukan peran dan penyelesaian
Kontainer utama memiliki hasil bisnis; Sidecar menyediakan dukungan. Keberhasilan Job harus berpusat pada tugas utama sambil menentukan apa yang harus dikosongkan (drain) oleh Sidecar dalam batas waktu tertentu. Jangan pernah menjadikan helper tanpa batas sebagai satu-satunya kondisi penyelesaian.
Langkah 2: Pilih representasi Sidecar
Model Kubernetes yang stabil menggunakan init container dengan restartPolicy: Always. Kontainer ini berpartisipasi dalam kesiapan startup Pod dan kemudian berjalan bersama kontainer utama, cocok untuk layanan logging atau proxy yang memerlukan siklus hidupnya sendiri.
initContainers:
- name: log-shipper
image: example/log-shipper:1.0
restartPolicy: Always
volumeMounts:
- name: shared-data
mountPath: /var/appLangkah 3: Rancang volume bersama dan anggaran
Sidecar dan kontainer utama berbagi namespace jaringan dan dapat berbagi volume bila diperlukan. Batasi volume penulisan, rotasi, izin, penyimpanan efemeral, CPU, dan memori agar lonjakan log tidak membuat tugas kekurangan sumber daya atau mendistorsi perilaku eviction.
Langkah 4: Tetapkan probe dan kesiapan (readiness)
Kesiapan Sidecar berarti ia dapat melayani, bukan berarti tugas utama berhasil; kegagalan liveness memerlukan kebijakan restart dan backoff. Jika kontainer utama harus menunggunya, ekspos sinyal kesiapan yang dapat diobservasi alih-alih menebak dengan jeda tidur (sleep) tetap.
Langkah 5: Tangani keberhasilan, kegagalan, dan percobaan ulang
Setelah kontainer utama berhasil, Sidecar harus membaca dan mengirim output yang tersisa, lalu keluar berdasarkan sinyal drain eksplisit atau batas waktu. Setelah kontainer utama gagal, pertahankan diagnostik. Percobaan ulang harus membuat pembersihan volume, pengiriman jarak jauh, dan penulisan bisnis menjadi idempoten untuk menghindari tagihan atau unggahan duplikat.
Langkah 6: Rancang terminasi dan sinyal
Pada terminasi Pod, kubelet menunggu kontainer aplikasi utama berhenti sebelum menghentikan Sidecar, lalu mematikan Sidecar dalam urutan terbalik dari kemunculannya di spesifikasi Pod. Aplikasi tetap memerlukan penanganan SIGTERM yang benar, batas waktu tenggang terminasi yang terbatas, dan fallback SIGKILL; penghentian yang anggun (graceful exit) tidak dijamin.
Langkah 7: Hubungkan status Job dan observabilitas
Catat kode keluar kontainer utama, status drain Sidecar, kondisi Job, jumlah percobaan ulang, watermark volume, dan latensi pengiriman. Peringatan harus membedakan kegagalan utama, Sidecar yang tidak pernah siap, batas waktu drain, dan eviction node alih-alih mengandalkan satu sinyal Pod Ready.
Langkah 8: Validasi matriks kegagalan
Uji keberhasilan utama yang cepat, kegagalan bisnis, crash pada Sidecar, backend log yang tidak tersedia, volume bersama yang penuh, batas waktu Job, eviction node, dan rolling upgrade. Verifikasi penyelesaian Job, output yang dapat dilacak, percobaan ulang yang idempoten, dan pelestarian segmen log akhir.
Pertukaran (trade-offs) dan batasan
Sidecar cocok untuk fungsi pendukung yang terhubung erat dengan tugas yang berbagi jaringan atau file dan memerlukan siklus hidup independen. Menempatkan setiap kebutuhan platform dalam Sidecar melipatgandakan konsumsi sumber daya, peningkatan versi, dan permukaan kegagalan; DaemonSet tingkat node, logging terkelola, atau layanan terpisah mungkin menjadi batasan yang lebih baik.
Urutan terminasi Kubernetes mengurangi risiko kehilangan data tetapi tidak menjamin ketersediaan jaringan eksternal atau menggantikan logika flush, percobaan ulang, dan konsistensi aplikasi. Hubungkan keberhasilan Job dan drain Sidecar melalui kontrak yang eksplisit.
Rencana peluncuran dan bukti
Mulailah dengan satu Job logging: kontainer utama, Sidecar, volume bersama, probe, batas sumber daya, dan batas waktu drain. Catat kondisi penyelesaian dan setiap jalur keluar sebelum menambahkan percobaan ulang dan peringatan.
Dokumentasikan versi Sidecar, sumber gambar, izin volume, probe, jendela terminasi, kondisi Job, dan idempotensi. Gunakan volume log realistis dan eksperimen eviction node untuk memverifikasi watermark sumber daya dan keterlacakan output akhir.
Kesalahan umum dan tindak lanjut
Memperlakukan init container reguler sebagai Sidecar konkuren
Init container reguler keluar sebelum kontainer utama dan tidak dapat menyediakan proxy atau logger yang berkelanjutan. Gunakan semantik Sidecar yang stabil bila konkurensi diperlukan.
Menunggu Sidecar selamanya
Beri Sidecar sinyal drain dan batas waktu. Pusatkan keberhasilan Job pada tugas utama dan verifikasi bahwa pengontrol selesai setelahnya.
Hanya membatasi kontainer utama
CPU, memori, dan penyimpanan efemeral Sidecar memengaruhi penjadwalan dan penggusuran (eviction). Tetapkan dan pantau requests dan limits untuk kedua peran.
Hanya mengandalkan Pod Ready
Ready tidak membuktikan keberhasilan bisnis atau log yang terkirim. Gabungkan kondisi Job, kode keluar, status drain, watermark antrean, dan latensi pengiriman.
Bagaimana jika segmen log terakhir masih hilang?
Periksa flush volume, percobaan ulang pengiriman, pensinyalan drain, batas waktu tenggang terminasi, dan ketersediaan backend; putar ulang matriks kegagalan daripada hanya memperpanjang jeda tidur (sleep).