Wawancara umum: Bagaimana cara Anda melakukan migrasi setelah Kubernetes v1.36 menonaktifkan volume gitRepo secara permanen?

Pertanyaan dan ruang lingkup

Sebuah tim menggunakan volume gitRepo agar repositori di-clone ke dalam sebuah mount saat Pod dimulai. Kubernetes v1.36 menonaktifkan plugin volume ini secara permanen dan tidak menyediakan feature gate sebagai jalan keluar darurat. Rancang migrasinya: inventarisasi beban kerja dan dependensi repositori, pilih init container, sinkronisasi eksternal, atau pengemasan saat build, serta verifikasi integritas commit, kredensial, perilaku jaringan, semantik pembaruan, dan rollback.

Dokumentasi Kubernetes menyatakan bahwa gitRepo telah didepresiasi selama bertahun-tahun dan implementasi lama tersebut dapat memungkinkan penyerang mengeksekusi kode sebagai root pada sebuah node. Setelah v1.36 menonaktifkan plugin ini, menjadwalkan ulang Pod lama tidak akan memulihkan kompatibilitas. Pisahkan perubahan API, rilis image, dan jalur pengambilan saat runtime.

Konteks dan batasan

Fokuskan pada siklus hidup plugin volume, urutan startup Pod, kepercayaan supply chain, dan verifikasi migrasi. Git hosting, registry image, network egress, dan manajemen secret merupakan dependensi platform; nyatakan pin commit, kredensial dengan hak akses paling minim (least-privilege), kebijakan kegagalan jaringan, dan target kebaruan data (freshness).

Hal yang diuji oleh pewawancara

Apakah Anda mengenali gitRepo sebagai plugin volume alih-alih layer image atau ConfigMap.
Apakah Anda membandingkan pengemasan saat build, init container, dan sinkronisasi kontinu berdasarkan reproduktibilitas, kebaruan data, dan semantik kegagalan.
Apakah Anda menangani repositori privat, known hosts, token, proxy, dan integritas commit.
Apakah Anda merancang pemindaian pra-upgrade, pemblokiran admission, canary node, dan rollback.
Apakah Anda menjelaskan berbagi empty-directory, izin mount, konsumsi read-only, dan dependensi startup.

Jawaban 30 detik

“Saya akan memindai Pod, template, dan generator untuk gitRepo, mencatat repositori, revisi, jalur mount, kredensial, dan kebutuhan kebaruan data. Konten statis harus dikemas ke dalam image immutable pada saat build. Jika pengambilan saat runtime diperlukan, init container dengan hak akses minimal akan menulis commit yang telah di-pin ke emptyDir, dan kontainer utama akan me-mount-nya secara read-only. Pembaruan kontinu memerlukan sinkronisasi terkontrol dengan peralihan versi atomik, penyimpanan versi lama, dan pemeriksaan integritas. Sebelum peningkatan versi, sebuah kebijakan akan memblokir penggunaan baru; restart canary menguji kegagalan jaringan dan rollback sebelum template lama dihapus.”

Solusi langkah demi langkah

Inventarisasi dependensi yang sebenarnya. Cari Pod, Deployment, StatefulSet, Job, Helm chart, Kustomize, generator, dan mutasi admission untuk gitRepo. Catat repositori, revisi, jalur, pembacaan saat startup, ukuran repositori, interval pembaruan, sumber kredensial, dan jalur egress.

Klasifikasikan semantik kebaruan. Kemas konfigurasi atau template statis pada saat build. Gunakan init container untuk konten yang dibutuhkan saat startup. Pertimbangkan sinkronisasi hanya untuk konten yang harus berubah saat aplikasi berjalan. “Mengambil di setiap startup” dan “hot update” adalah dua persyaratan yang berbeda.

Kemas pada saat build. Dalam jaringan CI yang tepercaya, ambil berdasarkan commit digest, pindai konten, bangun image immutable, dan sertakan provenance. Deploy berdasarkan image digest sehingga proses startup tidak bergantung pada ketersediaan Git; rollback akan memulihkan digest sebelumnya.

Gunakan penggantian dengan init container. Berikan init container sebuah ServiceAccount atau Secret khusus, mount kredensial secara read-only, dan tulis commit yang telah di-pin ke dalam emptyDir. Kontainer utama me-mount direktori yang sama secara read-only. Kegagalan pengambilan mencegah Pod beralih ke status Ready alih-alih mengekspos konten parsial.

yaml

volumes:
- name: repo-data
  emptyDir: {}
initContainers:
- name: fetch-repo
  image: platform/git-sync:approved
  volumeMounts:
  - name: repo-data
    mountPath: /work
containers:
- name: app
  volumeMounts:
  - name: repo-data
    mountPath: /app/config
    readOnly: true

Ini hanya merupakan panduan struktural. Image, proyeksi kredensial, kebijakan jaringan, perintah validasi, dan perintah pengambilan harus distandarisasi oleh platform sebelum digunakan di lingkungan produksi.

Operasikan sinkronisasi jika diperlukan. Untuk hot update, gunakan sidecar terkontrol atau sinkronisasi eksternal. Ambil ke dalam direktori sementara, verifikasi commit, manifes berkas, dan izin, lalu alihkan direktori versi secara atomik. Jika terjadi kegagalan, pertahankan versi yang saat ini valid. Aplikasi harus mendukung reload atau jendela restart yang telah ditentukan.

Lindungi supply chain. Jangan pernah menaruh token jangka panjang di dalam spesifikasi Pod atau log. Batasi repositori, branch, dan egress; validasi TLS, known hosts, tanda tangan commit, atau digest tepercaya. Sinkronisasi tidak boleh memodifikasi host path sebagai root; mount aplikasi harus bersifat read-only.

Canary, blokir, dan rollback. Sebelum melakukan peningkatan versi, pindai output CI dan gunakan ValidatingAdmissionPolicy untuk memblokir Pod gitRepo baru sambil tetap mempertahankan allowlist migrasi. Restart beban kerja pada sekumpulan kecil node dan uji cold start, kehilangan jaringan, rotasi kredensial repositori privat, penjadwalan ulang, serta penskalaan. Hapus template lama hanya setelah image baru terbukti stabil. Rollback akan memulihkan image atau sinkronisasi lama, bukan mengembalikan plugin v1.36 yang telah dinonaktifkan.

Contoh jawaban

Saya akan menginventarisasi gitRepo pada objek API dan template Pod yang telah di-render, kemudian mengklasifikasikan setiap beban kerja sebagai konten statis, pengambilan saat startup, atau hot update. Konten statis dimasukkan ke dalam image immutable yang dibangun melalui CI dan di-deploy berdasarkan digest. Konten startup menggunakan init container dengan hak akses minimal untuk menulis commit yang di-pin ke emptyDir, yang di-mount secara read-only oleh kontainer utama. Hot update menggunakan sinkronisasi yang memvalidasi versi baru di direktori sementara dan mengalihkannya secara atomik, dengan mempertahankan versi lama jika terjadi kegagalan.

Setiap jalur mengikat batasan repositori, commit, kredensial, jaringan, dan izin. Token dijauhkan dari spesifikasi dan log; konten yang diambil diperiksa terhadap TLS, known hosts, serta provenance commit atau image. Sebelum melakukan peningkatan versi, pindai template dan blokir gitRepo baru; kemudian lakukan restart canary dan penjadwalan ulang sambil mengamati waktu startup, kegagalan pengambilan, content digest, status Ready, dan keberhasilan rollback. Karena v1.36 menonaktifkan plugin secara permanen, rollback harus menggunakan mekanisme pengganti atau versi kluster yang lebih lama, bukan melalui feature gate.

Kesalahan umum

Kesalahan: Menaruh URL repositori di ConfigMap dan mengharapkan pembaruan → Mengapa gagal: ConfigMap tidak mengambil Git atau memverifikasi versi → Perbaikan: serahkan tanggung jawab ke pengemasan saat build, init container, atau sinkronisasi.
Kesalahan: Membiarkan init container mengambil default branch → Mengapa gagal: restart tidak dapat direproduksi dan rollback tidak dapat dibuktikan → Perbaikan: lakukan pin pada commit dan catat digest serta provenance-nya.
Kesalahan: Menjalankan sinkronisasi sebagai root terhadap jalur yang dibagikan oleh host → Mengapa gagal: ini memperluas attack surface node dan melewati isolasi Pod → Perbaikan: gunakan volume lokal Pod, eksekusi non-root, hak akses paling minim, dan konsumsi read-only.
Kesalahan: Menimpa direktori yang sedang dibaca oleh aplikasi → Mengapa gagal: aplikasi dapat melihat struktur tree parsial → Perbaikan: validasi di direktori sementara dan alihkan versi secara atomik.
Kesalahan: Mengaktifkan kembali GitRepoVolumeDriver setelah v1.36 → Mengapa gagal: plugin dinonaktifkan secara permanen dan risiko keamanan tetap ada → Perbaikan: lakukan rollback pada pengganti atau versi kluster sembari melanjutkan migrasi.

Pertanyaan lanjutan dan jawaban

Mengapa perlu memvalidasi konten jika commit sudah di-pin?

Pin commit membuat referensi menjadi stabil tetapi tidak membuktikan bahwa repositori, dependensi, atau lingkungan build dapat dipercaya. CI harus tetap memverifikasi tanda tangan, provenance, manifes berkas, pemindaian malware, dan digest image, serta mengikat bukti-bukti tersebut ke dalam rilis.

Di mana kredensial repositori privat harus disimpan?

Gunakan Secret khusus atau penyedia secret eksternal yang dibatasi ke namespace dan repositori target. Masukkan melalui variabel lingkungan atau berkas yang di-mount, jangan pernah melalui image, anotasi, atau log, serta dukung rotasi dan pencabutan.

Apa yang terjadi jika init container gagal?

Pod tidak akan menjadi siap (available) dan kontainer utama tidak akan dimulai secara normal. Tampilkan alasannya, terapkan retry dan backoff, serta tentukan apakah image lama atau cache yang sudah hangat dapat memberikan fallback bisnis yang valid.

Bagaimana cara hot update menghindari konten parsial?

Ambil ke dalam direktori versi baru, selesaikan pemeriksaan commit, manifes, dan izin, lalu ganti nama atau alihkan symlink secara atomik. Aplikasi memerlukan kontrak reload atau kebijakan restart; peralihan yang gagal akan mempertahankan versi saat ini.

Bagaimana cara menemukan penggunaan gitRepo yang terlewat?

Pindai objek API, kode sumber Helm/Kustomize, output yang di-render, dan mutasi admission. Pantau error depresiasi atau unknown-field setelah peningkatan versi, dan pertahankan pemindaian di CI sehingga template baru tidak dapat memperkenalkan kembali plugin tersebut.

Sumber

Bocoran Singkat Kubernetes v1.36 (Blog Kubernetes)
Dokumentasi Volume (Dokumentasi Kubernetes)
Konfigurasi Projected Volume (Dokumentasi Kubernetes)
Kebijakan Depresiasi Kubernetes (Dokumentasi Kubernetes)

Daftar periksa wawancara

Pisahkan semantik konten statis, pengambilan saat startup, dan hot update, lalu rancang image, init container, sinkronisasi, izin, validasi, canary, dan rollback untuk masing-masing bagian.

Kesimpulan satu kalimat

Migrasi gitRepo menggantikan proses kloning Git implisit di sisi node dengan rantai pengiriman konten yang dapat direproduksi, berhak akses minimal, dan dapat diverifikasi.

Terus berlatih

Jika repositori berisi model berukuran multi-gigabyte dan konfigurasi yang sering berubah, bandingkan layer image, object storage, init container, dan sinkronisasi berdasarkan biaya dan konsistensi.