Memecahkan masalah snapshot Pod

Dokumen ini menunjukkan cara menyelesaikan masalah umum terkait GKE Snapshot pod dan resource terkaitnya.

Informasi ini penting bagi Developer aplikasi serta Admin dan operator platform yang menggunakan snapshot Pod untuk melakukan checkpoint dan memulihkan workload. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami rujuk dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

Risiko mutasi pasca-checkpoint dengan PVC

Jika Pod Anda menggunakan Persistent Volume Claim (PVC), risiko signifikan terjadi selama alur kerja "checkpoint dan lanjutkan": jika Anda mengonfigurasi workload untuk dilanjutkan segera setelah checkpoint (dengan menggunakan kolom postCheckpoint: resume), aplikasi tetap aktif dan dapat mengubah PVC setelah checkpoint.

  • Masalah penghentian normal: setelah siklus checkpoint dan melanjutkan, saat Anda menghapus Pod, Kubernetes memulai urutan penghentian normal dengan mengirimkan sinyal SIGTERM ke proses utama dalam container. Banyak aplikasi menerapkan logika penghentian normal selama aplikasi tersebut mungkin memicu rutin pembersihan untuk menghapus atau memperbarui file sementara di PVC.
  • Kegagalan pemulihan: jika perubahan ini terjadi pada PVC setelah snapshot Pod diambil, prosedur pemulihan akan mengharapkan status PVC seperti yang ada pada saat checkpoint, sehingga berpotensi menyebabkan kegagalan pemulihan atau inkonsistensi data.
  • Mitigasi yang direkomendasikan: jika penggunaan PVC diperlukan untuk workload, jangan lanjutkan workload setelah checkpoint. Gunakan konfigurasi postCheckpoint: stop di PodSnapshotPolicy Anda. Konfigurasi ini membantu memastikan bahwa proses tidak memiliki peluang untuk melakukan penulisan tambahan atau perubahan status setelah fase checkpointing selesai.

Pemasangan ConfigMap dan masking direktori

Saat mengintegrasikan data konfigurasi ke dalam container, metode pemasangan dapat memengaruhi integritas snapshot.

Jika ConfigMap di-mount menggunakan pemasangan volume standar, Kubernetes memperlakukan seluruh direktori target sebagai pemasangan eksternal. Karena pemasangan eksternal dilewati selama snapshot, seluruh direktori akan dikecualikan dari snapshot.

Dalam contoh berikut, setiap perubahan di direktori /etc/my-app/ tidak dicatat dalam snapshot karena seluruh direktori adalah pemasangan eksternal:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  config.json: |
    {
      "mode": "local"
    }
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  runtimeClassName: gvisor
  containers:
    - name: my-app-container
      image: my-app-image
      volumeMounts:
        - mountPath: /etc/my-app
          name: config-volume
  volumes:
    - name: config-volume
      configMap:
        name: my-config

Untuk mengatasi masalah ini, gunakan subPath. subPath membantu memastikan bahwa hanya file konfigurasi tertentu yang diperlakukan sebagai pemasangan eksternal. Konfigurasi ini menargetkan file yang tepat, sehingga file dan struktur yang tersisa dalam direktori induk tetap menjadi bagian dari sistem file lokal penampung, yang diambil dengan benar selama proses pembuatan titik pemeriksaan.

Contoh berikut menunjukkan konfigurasi volumeMounts yang menggunakan subPath:

      volumeMounts:
        - mountPath: /etc/my-app/config.json
          name: config-volume
          subPath: config.json

Volume anonim implisit

Image container tertentu menentukan volume dalam metadatanya melalui instruksi VOLUME dalam Dockerfile. Meskipun spesifikasi Pod Anda tidak menentukan volume, Kubernetes akan otomatis membuat volume anonim untuk jalur apa pun yang ditentukan sebagai volume dalam image dasar. Misalnya, gambar alpine/git menentukan /git sebagai volume implisit.

Volume anonim ini diperlakukan sebagai pemasangan eksternal dan, seperti PVC, tidak di-checkpoint. Periksa image dasar Anda untuk memastikan bahwa data penting tidak disimpan dalam volume implisit.