Bagaimana cara merilis aset data OCI secara aman dengan image volume Kubernetes?

Pertanyaan dan konteks

Anda mengelola layanan inferensi yang harus me-mount paket model, kosakata, atau aturan sebagai file read-only dari image OCI. Rancang pendekatan rilis dengan digest pinning, peluncuran bertahap (staged rollout), kegagalan startup yang dapat didiagnosis, dan rollback cepat. Jelaskan batasan-batasan dari image volume Kubernetes.

Hal yang dievaluasi pewawancara

• Apakah Anda memisahkan identitas artefak, kompatibilitas penjadwalan (scheduling), dan kontrol rollout.
• Apakah Anda menjelaskan reference, pullPolicy, resolusi startup, dan mount read-only secara akurat.
• Apakah Anda mencakup admisi, observabilitas, rollback, dan perilaku cache node alih-alih hanya menulis YAML.
• Apakah Anda mengidentifikasi versi, runtime, dan izin registri sebagai prasyarat.

Pertanyaan klarifikasi terlebih dahulu

Siklus hidup artefak

Siapa yang membangun, menandatangani, dan menyimpan paket model atau aturan? Apakah produksi harus menggunakan digest yang tidak dapat diubah (immutable), atau boleh mengikuti tag yang dapat diubah (mutable)? Berapa ukuran artefak, frekuensi pembaruan, dan volume startup konkuren?

Kluster dan runtime

Versi kluster, sistem operasi node, container runtime, dan kredensial registri apa yang tersedia? Apakah versi node yang berbeda dapat hadir bersamaan selama peningkatan (upgrade)?

Keamanan dan rollback

Siapa yang dapat mengubah reference Pod? Apakah registri menyediakan akses privat dan log audit? Apakah rollback hanya memerlukan digest sebelumnya, atau juga memerlukan tanda tangan yang dapat direproduksi, konfigurasi, dan bukti kompatibilitas?

Jawaban 30 detik

Saya akan membangun artefak OCI yang ditandatangani dan menyematkan (pin) digest-nya di manifes rilis. Pod me-mount-nya sebagai read-only melalui image volume, sementara kebijakan admisi menolak registri atau digest yang tidak disetujui. Pengontrol melakukan rollout Pod dalam batch yang dibatasi pada node yang kompatibel, mengamati metrik pull, mount, self-check aplikasi, dan metrik permintaan. Jika terjadi kegagalan, sistem akan memulihkan beban kerja dan digest sebelumnya. Artefak yang tidak direferensikan hanya akan di-garbage-collect setelah persyaratan retensi dan audit terpenuhi.

Solusi mendalam

1. Buat identitas artefak menjadi immutable

reference dapat mengarah ke referensi image OCI; produksi harus menggunakan digest daripada tag yang dapat diubah. Ikat tanda tangan, SBOM, dan asal-usul build (provenance) ke digest tersebut. Simpan digest, pipeline, matriks kompatibilitas, dan pemilik dalam catatan rilis. Digest pinning membuat rilis dapat direproduksi, tetapi tidak menggantikan pemindaian kerentanan atau verifikasi tanda tangan.

2. Tentukan mount Pod

Volume berikut di-mount sebagai read-only di dalam kontainer:

volumes:
  - name: model
    image:
      reference: registry.example.com/models/ranker@sha256:0123456789abcdef
      pullPolicy: IfNotPresent
containers:
  - name: api
    image: registry.example.com/services/ranker-api@sha256:abcdef0123456789
    volumeMounts:
      - name: model
        mountPath: /opt/model
        readOnly: true

Kubernetes mendokumentasikan image volume sebagai objek OCI yang disediakan pada host kubelet, dengan konten read-only. Always, Never, dan IfNotPresent menyatakan pull setiap saat, tidak pernah melakukan pull, dan pull jika tidak ada secara lokal. Produksi umumnya menggabungkan digest yang disematkan dengan IfNotPresent, sementara kontrol admisi dan node menentukan batasan rantai pasokan.

3. Tambahkan pemeriksaan admisi dan izin

Kebijakan admisi memeriksa domain registri, format digest, tanda tangan, ambang batas kerentanan, dan kompatibilitas layanan-ke-artefak. Service account hanya menerima izin registri yang dibutuhkannya; identitas node, pull secret, dan log audit tetap dikelola secara terpisah. Penolakan harus menjelaskan penyebabnya pada saat pembuatan Pod alih-alih menunggu kontainer aplikasi gagal.

4. Verifikasi kompatibilitas node dan runtime

Image volume memerlukan dukungan dari node, container runtime, dan versi kluster. Representasikan kemampuan dengan label node dan batasan penjadwalan, lalu uji batch kecil pada node yang kompatibel selama peningkatan versi. Control plane yang menerima bidang tersebut tidak membuktikan bahwa setiap node dapat me-mount-nya; kluster dengan versi campuran memerlukan kemampuan minimum yang eksplisit dan rencana downgrade.

5. Rencanakan rollout dan pemanasan cache (cache warming)

Pengontrol memulai dengan canary kecil, memverifikasi kesiapan Pod, keberadaan artefak, pemeriksaan digest, dan self-check aplikasi, kemudian memperluas Deployment. Kegagalan pull memblokir startup kontainer dan mengikuti retry backoff normal, jadi bedakan kegagalan autentikasi registri, jaringan, disk node, dan artefak yang rusak. Menghangatkan cache node target dapat mengurangi latensi, tetapi tidak dapat melewati pemeriksaan admisi atau digest.

6. Amati startup dan hasil bisnis

Korelasikan beban kerja, Pod, node, digest artefak, dan batch rollout. Pantau latensi pull, startup backoff, kesalahan mount, penggunaan disk, self-check, dan tingkat kesalahan permintaan. Kubernetes juga mendokumentasikan bahwa Pod yang dibuat ulang akan me-resolve konten jarak jauh lagi, jadi catat digest yang sebenarnya digunakan oleh setiap Pod baru dan beri peringatan jika ada perbedaan.

7. Lakukan rollback dan garbage collection

Rollback beralih ke digest lama yang disetujui dan versi layanan yang cocok, mempertahankan tanda tangan, SBOM, dan konfigurasinya. Verifikasi bahwa artefak lama tetap dapat diambil; jangan berasumsi bahwa cache node bersifat permanen. Lakukan garbage collection hanya jika tidak ada referensi aktif, retensi telah berakhir, dan catatan audit telah diarsipkan. Lindungi digest yang terlibat dalam rollback atau investigasi.

Contoh jawaban yang kuat

Saya memperlakukan image model sebagai rilis yang immutable. Build menghasilkan SBOM, tanda tangan, dan digest; catatan rilis menyimpan digest tersebut dan matriks kompatibilitas layanan. Pod me-mount image volume sebagai read-only, dan admisi membatasi registri serta memverifikasi tanda tangan. Pengontrol berjalan berdasarkan kemampuan node dan batch canary. Kubernetes menyiapkan image volume selama startup Pod, dan kegagalan pull memblokir startup, jadi saya memisahkan sinyal autentikasi, jaringan, disk, dan backoff. Setiap Pod baru mencatat digest aktualnya; hanya self-check dan metrik permintaan yang sukses yang memajukan rollout. Kegagalan akan memulihkan digest sebelumnya, dan pembersihan menunggu hingga artefak tidak lagi direferensikan dan melewati masa retensi.

Kesalahan umum

• Hanya menggunakan tag image tanpa mendiskusikan mutabilitas dan digest pinning.
• Memperlakukan image volume sebagai disk bersama yang dapat ditulisi (writable).
• Mengasumsikan setiap node mendukung fitur tersebut tanpa mempertimbangkan versi kluster, runtime, atau node.
• Hanya memantau replika yang tersedia sambil mengabaikan pull backoff, kesalahan mount, dan pemeriksaan artefak.
• Menghangatkan cache sambil melewati kontrol tanda tangan, admisi, atau audit.
• Melakukan rollback image layanan tanpa memulihkan digest artefak yang kompatibel.

Pertanyaan lanjutan dan jawaban

Mengapa bukan ConfigMap atau persistent volume biasa?

Aset berukuran besar dan berversi yang membutuhkan kontrol rantai pasokan OCI cocok untuk image volume. ConfigMap cocok untuk konfigurasi kecil, sedangkan persistent volume cocok untuk data lintas-Pod yang dapat ditulisi atau tahan lama. Pilihan akhir tetap bergantung pada ukuran, metode pembaruan, izin, dan tujuan pemulihan.

Apakah Always lebih aman?

Always melakukan pull pada setiap startup, mengurangi risiko cache usang sembari meningkatkan latensi startup, ketergantungan pada registri, dan bidang kegagalan. Penyematan digest, admisi tanda tangan, dan rollback yang dapat diobservasi biasanya lebih penting daripada sekadar mengubah kebijakan pull saja.

Apa yang terjadi jika Pod dibuat ulang?

Pod yang dibuat ulang akan me-resolve referensi jarak jauh dan menyiapkan volume lagi. Catat referensi, digest yang di-resolve, dan peristiwa dalam data audit rilis; jangan berasumsi bahwa cache node lama menentukan konten Pod baru.

Kapan Anda akan menggunakan subPath?

Gunakan subPath ketika direktori di dalam artefak harus muncul pada jalur tertentu. Dokumentasi Kubernetes saat ini menyatakan bahwa dukungan subPath dan subPathExpr pada image volume dimulai di v1.33, jadi verifikasi versi kluster target.

Bagaimana Anda menangani perbedaan kemampuan digest-status?

Dalam dokumentasi Kubernetes saat ini, image volume berstatus stabil pada dokumentasi v1.36; bidang status ImageVolumeWithDigest masih ditandai sebagai alpha dan bergantung pada versi serta feature gate yang sesuai. Peluncuran tidak boleh memperlakukan bidang status tersebut sebagai sesuatu yang tersedia secara universal.