Wawancara Desain Sistem: Bagaimana Cara Bermigrasi ke Native Sidecar Kubernetes Secara Aman?

Konteks dan arahan masalah

Anda bertanggung jawab atas beban kerja Kubernetes yang menjalankan agen log, proksi service-mesh, atau daemon cache lokal di samping aplikasi. Tim ingin memigrasikan pembantu (helper) tersebut dari kontainer reguler ke native sidecar Kubernetes. Aplikasi harus menunggu hingga helper siap, kegagalan helper memerlukan batasan ketersediaan yang jelas, dan desain harus mencakup Job, rilis bergulir (rolling release), kuota sumber daya, serta rollback. Usulkan rencana migrasi dan jelaskan perbedaan versi (version skew), probe, urutan terminasi, dan penanganan kegagalan.

Ini adalah pertanyaan desain sistem. Penilaian berfokus pada penalaran Anda tentang batasan dan kompromi (trade-offs), bukan sekadar mengingat potongan YAML. Cakup aspek siklus hidup, kompatibilitas, sumber daya, observabilitas, dan rollback.

Hal yang dinilai oleh pewawancara

• Mengubah Service-Level Objectives (SLO) menjadi kebijakan startup, kesiapan (readiness), terminasi, dan penanganan kegagalan.
• Menjelaskan batas pemisah antara native sidecar, kontainer reguler, Deployment terpisah, dan DaemonSet.
• Menemukan risiko perbedaan versi di seluruh server API, node, webhook, dan klien.
• Mengurangi risiko migrasi dengan anggaran sumber daya, peluncuran bertahap, metrik, dan rollback.
• Menangani contoh kasus khusus seperti penyelesaian Job, proksi yang macet, probe yang gagal, dan peningkatan versi (upgrade) node.

Materi persiapan SDE II Amazon mendeskripsikan evaluasi desain sistem berdasarkan kepraktisan, akurasi, efisiensi, keandalan, optimasi, dan skalabilitas. Pertanyaan ini meminta Anda untuk menerapkan tujuan-tujuan tersebut pada siklus hidup Pod dan kontrol rilis.

Pertanyaan klarifikasi

1. Apakah helper berjalan satu salinan per Pod atau satu salinan per node? Apakah ia harus berbagi namespace jaringan atau volume dengan aplikasi?
2. Bolehkah aplikasi menerima lalu lintas sebelum helper siap? Apakah kegagalan saat startup memblokir rilis, menurunkan fungsionalitas (degrade), atau mengizinkan bypass?
3. Apakah ini layanan yang berjalan terus-menerus (long-running), Job sekali jalan (one-shot), atau keduanya? Apakah ia harus melakukan flush log atau mengunggah data selama terminasi?
4. Apakah versi Kubernetes sudah selaras di seluruh klaster, server API, dan node? Mungkinkah admission webhook, template renderer, atau klien menghapus kolom yang tidak dikenali?
5. Berapa anggaran CPU, memori, penyimpanan efemeral, dan jaringan untuk helper? Apakah kegagalannya akan menghabiskan anggaran kesalahan (error budget) aplikasi?
6. Bisakah Anda melakukan canary berdasarkan namespace atau beban kerja sambil mempertahankan template kontainer reguler sebagai sakelar rollback?

Kerangka jawaban 30 detik

Mulailah dengan tujuan: pertahankan helper dan aplikasi dalam satu Pod, jalankan secara berurutan, buat perilakunya dapat diobservasi, dan pastikan rollback dapat dilakukan dengan cepat tanpa membiarkan helper memblokir proses secara tanpa batas. Terapkan native sidecar pada initContainers dengan restartPolicy: Always di tingkat kontainer, readiness probe yang bermakna, dan anggaran sumber daya yang eksplisit. Jaga kompatibilitas dengan pemeriksaan klaster dan admisi. Luncurkan dua template secara bertahap, bandingkan latensi startup dan tingkat kesalahan, kembalikan ke format lama jika ambang batas terlampaui, serta uji penyelesaian Job dan pembersihan saat terminasi secara terpisah.

Jawaban mendalam langkah demi langkah

1. Tentukan batas siklus hidup terlebih dahulu

Native sidecar Kubernetes adalah init container khusus: restartPolicy: Always di tingkat kontainer memungkinkannya mulai berjalan selama inisialisasi dan terus berjalan. Kontainer ini tetap mengikuti urutan init container, sehingga init container berikutnya dan kontainer aplikasi akan menunggu hingga sidecar siap digunakan. "Proksi siap terlebih dahulu" menjadi jaminan struktural di tingkat Pod, bukan lagi melalui polling loop di aplikasi.

Aplikasi dan sidecar berbagi namespace jaringan dan penyimpanan Pod. Hal ini berguna untuk soket Unix, volume log, atau port proksi lokal. Jika helper hanya menyediakan fungsionalitas tingkat node, evaluasi penggunaan DaemonSet daripada membayar biayanya satu per satu untuk setiap Pod.

2. Definisikan kesiapan (readiness) dan kebijakan kegagalan

Berikan readinessProbe pada helper yang mencerminkan kapabilitas sebenarnya: konfigurasi control-plane telah dimuat, port pendengar telah tersedia, dan sertifikat penting valid. Kesiapan sidecar dapat memengaruhi kesiapan Pod, sehingga kegagalan probe dapat mengeluarkan seluruh Pod dari layanan. Probe hanya melaporkan status; ia tidak menggantikan mekanisme retry, pembatasan laju (rate limits), atau graceful degradation.

Pisahkan antara kegagalan startup, crash saat berjalan, dan dependensi yang tidak tersedia untuk sementara. Kegagalan startup biasanya membuat Pod tetap berada di luar layanan. Crash saat berjalan akan di-restart oleh Always, tetapi jumlah restart, waktu pemulihan, dan tingkat kesalahan harus menunjukkan apakah SLO telah terlanggar. Helper opsional dapat memiliki mekanisme bypass; proksi keamanan atau otorisasi harus bersifat fail-closed dan segera menghentikan peluncuran jika error budget-nya terlampaui.

3. Tangani terminasi, Job, dan pembersihan data (flushing)

Native sidecar berhenti setelah kontainer aplikasi berhenti, dan beberapa sidecar akan dimatikan dalam urutan terbalik. Oleh karena itu, agen log dapat mengosongkan buffer setelah aplikasi keluar, tetapi periode tenggang terminasi (termination grace period) memerlukan batas atas yang tegas. Catat jumlah data yang hilang saat flushing mengalami timeout; jangan pernah menunggu tanpa batas waktu.

Untuk Job, pastikan pengontrol memperlakukan selesainya kontainer utama sebagai penyelesaian Job, alih-alih menunggu sidecar tanpa henti. Sidecar mungkin terus melakukan restart sebelum Job selesai, jadi tampilkan hasil tugas, hasil pembersihan sidecar, dan integritas data akhir sebagai sinyal dan peringatan terpisah.

4. Periksa versi dan jalur mutasi

Native sidecar sudah stabil dan diaktifkan secara default di Kubernetes v1.33; kapabilitas ini berstatus beta dan diaktifkan secara default sejak v1.29. Sebelum migrasi, tetap periksa kubelet, server API, komponen admisi, dan feature gate yang sebenarnya di setiap node pool.

Mutating webhook, alat templating, atau klien versi lama mungkin tidak mengenali restartPolicy di tingkat kontainer dan menghapusnya saat menulis ulang objek. Validasi objek akhir di CI, catat struktur sidecar di log admisi, dan jalankan probe Pod untuk memastikan urutan runtime. Jika rangkaian tersebut tidak dapat dipercaya, pertahankan fallback kontainer reguler atau tunda migrasi.

5. Hitung dampak sumber daya dan penjadwalan (scheduling)

Sidecar tidak gratis. Permintaan CPU, memori, dan penyimpanan efemeralnya ikut serta dalam perhitungan sumber daya efektif Pod, yang memengaruhi QoS, kuota, dan penjadwalan. Gunakan beban puncak aplikasi, beban puncak startup helper, dan batas buffer untuk menghitung requests dan limits; pantau fragmentasi node, penggusuran (eviction), OOM, dan waktu antrean startup.

Jika helper memerlukan penskalaan independen, siklus rilis terpisah, atau domain kegagalan yang lebih luas, Deployment terpisah mungkin lebih cocok. Native sidecar memberikan keuntungan berbagi sumber daya lokal dan urutan siklus hidup, tetapi menggabungkan penjadwalan, sumber daya, dan rilis ke dalam satu unit.

6. Rancang canary, observabilitas, dan rollback

Siapkan dua template Pod: native sidecar dan format kontainer reguler lama. Luncurkan berdasarkan namespace, label, atau beban kerja, dengan kondisi berhenti otomatis untuk setiap batch. Lacak setidaknya latensi pembuatan-Pod-hingga-Ready, kegagalan kesiapan sidecar, jumlah restart, kesalahan permintaan aplikasi, kedalaman buffer, data yang hilang saat flush, lonjakan CPU dan memori, serta latensi penyelesaian Job.

Selama migrasi, catat struktur yang diharapkan dan struktur yang teramati; objek Deployment yang sukses saja tidak cukup. Jika webhook menghapus kolom, latensi Ready memburuk, atau restart helper melampaui ambang batas, hentikan ekspansi dan beralihlah ke template lama. Rollback juga harus memastikan bahwa template lama tidak mewarisi konfigurasi baru, format volume, atau asumsi port baru.

7. Terapkan keamanan dan observabilitas di dalam batasan

Karena sidecar berbagi jaringan dan volume Pod, ia memiliki bidang akses yang sama dengan Pod. Berikan hak akses terendah (least privilege), sistem file root hanya-baca (read-only), service account eksplisit, dan kebijakan jaringan. Jangan melewati kontrol audit hanya karena ia "hanya sebuah helper". Tambahkan label Pod, kontainer, dan versi rilis pada log, metrik, dan trace agar kegagalan aplikasi dapat dipisahkan dari kegagalan helper.

Contoh jawaban berkualitas tinggi

Pertama, saya akan mengklasifikasikan helper sebagai dependensi per-Pod dan memastikan apakah ia benar-benar membutuhkan jaringan atau penyimpanan bersama. Jika ini merupakan kemampuan tingkat node, saya akan memilih DaemonSet. Template migrasi menggunakan native sidecar: letakkan helper di dalam initContainers dan tetapkan restartPolicy: Always di tingkat kontainer. Helper akan mulai sesuai urutan init, readinessProbe-nya memastikan konfigurasi dan port siap digunakan, dan barulah aplikasi mulai melayani lalu lintas.

Saya akan membagi kegagalan menjadi kegagalan startup, crash saat runtime, dan dependensi yang tidak tersedia sementara. Proksi keamanan bersifat fail-closed; fungsionalitas opsional mempertahankan bypass. Selama terminasi, urutan shutdown sidecar yang dilakukan setelah aplikasi memungkinkan pembersihan data (flushing) dengan batas waktu tertentu. Untuk Job, saya akan memverifikasi penyelesaian kontainer utama dan pembersihan sidecar secara terpisah agar helper yang berjalan terus-menerus tidak memblokir status Job.

Sebelum peluncuran, saya akan memeriksa server API, setiap node pool, feature gate, webhook, dan klien template karena alat lama dapat menghapus restartPolicy. CI akan memvalidasi objek akhir, dan peluncuran canary akan memvalidasi urutan serta kesiapan Pod yang sebenarnya. Anggaran sumber daya mencakup beban puncak helper dalam perhitungan QoS, kuota, dan penjadwalan; dasbor menampilkan latensi Ready, restart, error, buffer, dan kehilangan data. Dua template diluncurkan secara bertahap, di mana setiap pelanggaran ambang batas akan menghentikan ekspansi dan melakukan rollback ke format lama. Pendekatan ini memanfaatkan jaminan siklus hidup bawaan sambil mengubah batasan versi, sumber daya, dan kegagalan menjadi gerbang rilis yang dapat diobservasi.

Kesalahan umum

• Menempelkan YAML tanpa menjelaskan mengapa native sidecar diperlukan atau kapan kontainer reguler atau beban kerja terpisah lebih baik digunakan.
• Menulis restartPolicy: Always di tingkat Pod, bukan di dalam definisi kontainer sidecar.
• Hanya mengonfigurasi livenessProbe dan mengabaikan bagaimana kegagalan readiness mengubah lalu lintas dan perilaku peluncuran.
• Mengasumsikan versi Kubernetes sudah memadai tanpa memeriksa perbedaan versi pada node, webhook, dan klien.
• Menganggap sidecar tidak memakan biaya dan mengabaikan dampaknya terhadap kuota sumber daya, lonjakan startup, buffering, dan QoS.
• Hanya menguji layanan yang berjalan terus-menerus dan melupakan penyelesaian Job, batas waktu flushing, serta urutan terminasi terbalik.
• Hanya me-rollback image tanpa memeriksa template lama, port, volume, dan output admisi.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika ada node lama yang tidak mendukung native sidecar?

Hentikan peluncuran dan lakukan isolasi berdasarkan node pool. Jika objek tidak dapat dipastikan mempertahankan kebijakan tingkat kontainer, gunakan template kontainer reguler atau tingkatkan versi (upgrade) node; menghapus kolom yang tidak dikenal secara diam-diam bukanlah bentuk kompatibilitas.

Apa yang terjadi jika readiness sidecar terus-menerus gagal?

Pod harus tetap berada di luar status Ready dan pengontrol peluncuran harus menghentikan ekspansi. Bedakan antara kesalahan konfigurasi, dependensi yang tidak tersedia, dan bug pada probe, lalu perbaiki atau lakukan rollback. Jangan menyembunyikan ketidaktersediaan yang sebenarnya dengan membuat probe terlalu permisif.

Apakah sidecar tetap berjalan setelah kontainer utama pada Job selesai?

Native sidecar mungkin terus berjalan dan melakukan restart, sementara pengontrol Job dapat mengenali penyelesaian kontainer utama. Beri batas waktu pada pembersihan data (flushing) dan catat hasil tugas secara terpisah dari integritas data agar aktivitas helper yang berjalan lama tidak disalahartikan sebagai kegagalan tugas.

Mengapa tidak menggunakan Deployment terpisah untuk proksi?

Pilih pemisahan jika proksi membutuhkan penskalaan independen, siklus rilis mandiri, atau domain kegagalan yang lebih luas. Pilih native sidecar jika soket lokal, jaringan bersama, dan urutan startup yang ketat sangat penting. Keputusan didasarkan pada tingkat kopling dan SLO.

Bagaimana cara mendiagnosis peningkatan tekanan sumber daya setelah migrasi?

Bandingkan permintaan sumber daya Pod yang efektif, lonjakan startup, fragmentasi node, penggusuran (eviction), dan OOM sebelum dan sesudah migrasi; periksa buffer dan konkurensi helper. Jika helper hanya menyediakan fungsionalitas tingkat node, evaluasi DaemonSet. Jika harus tetap berada di dalam Pod, sesuaikan anggaran atau kurangi ukuran canary.

Bagaimana Anda membuktikan bahwa rollback aman dilakukan?

Simpan hash template lama. Selama rollback, validasi struktur kontainer, port, volume, service account, dan output webhook, lalu pantau batch canary untuk latensi Ready, tingkat kesalahan, dan kehilangan data saat flush. Lanjutkan ekspansi hanya setelah sinyal-sinyal tersebut kembali normal.