如何本地访问Google Cloud磁盘快照？GKE场景求替代方案

1. Mounting the disk.raw File Locally #

First, let's get that raw disk file usable on your local machine. The steps vary a bit by OS:

For Linux #

• Use losetup to attach the raw file to a loop device:

  sudo losetup -fP disk.raw
  

• Check which loop device it's attached to (e.g., /dev/loop0) with:

  losetup -a
  

• Mount the partition (replace /dev/loop0p1 with your actual partition—use fdisk -l /dev/loop0 to list partitions):

  sudo mount /dev/loop0p1 /mnt/gcp-disk
  

• When you're done, unmount and detach the loop device:

  sudo umount /mnt/gcp-disk
  sudo losetup -d /dev/loop0
  

For macOS #

• Use hdiutil to create a disk image from the raw file:

  hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount disk.raw
  

• This will output a device path (e.g., /dev/disk2). Mount it with:

  mkdir -p ~/mnt/gcp-disk
  sudo mount -t apfs /dev/disk2s1 ~/mnt/gcp-disk
  

  Note: Replace apfs with your filesystem type (ext4, etc.) if needed—you might need to install fuse-ext2 for ext filesystems on macOS.
• Cleanup when finished:

  sudo umount ~/mnt/gcp-disk
  hdiutil detach /dev/disk2
  

2. Streamlined Workflow for Snapshot to Local Files #

Your current workflow works, but we can trim a few steps and avoid unnecessary overhead:

• Chain commands with async flags to speed up processing, and skip storing the full tar.gz locally if you don't need it:

  # Create snapshot asynchronously
  gcloud compute disks snapshot mydrive --snapshot-names=mydrive-snapshot --async
  # Wait for snapshot completion, then create image
  gcloud compute images create mydrive-image --source-snapshot mydrive-snapshot --async
  # Export image to GCS, then pipe directly to tar to extract (skips local tar.gz file)
  gsutil cat gs://my-bucket/mydrive-image.tar.gz | tar xvf -
  

• Pro tip: If you only need specific database files (not the entire disk), mount the raw disk as shown above and copy just those files—no need to extract the whole volume.

3. Native K8s Volume-Level Operations (No Pod Required) #

Great question—K8s has built-in support for volume snapshots via the PersistentVolumeSnapshot API, letting you manage backups directly through cluster resources instead of manual gcloud commands. Here's how to set it up:

Step 1: Create a VolumeSnapshotClass #

First, define a snapshot class that ties to GCP's disk snapshot service. Save this as gcp-snapshot-class.yaml:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: gcp-snapshot-class
driver: pd.csi.storage.gke.io
deletionPolicy: Delete
parameters:
  storage-location: us-central1 # Match your cluster's region

Apply it with:

kubectl apply -f gcp-snapshot-class.yaml

Step 2: Create a VolumeSnapshot #

Next, create a snapshot of your target PersistentVolumeClaim (PVC). Save this as mydrive-snapshot.yaml:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mydrive-snapshot
spec:
  volumeSnapshotClassName: gcp-snapshot-class
  source:
    persistentVolumeClaimName: my-pvc-name # Replace with your PVC's name

Apply it with:

kubectl apply -f mydrive-snapshot.yaml

Check the snapshot status with:

kubectl get volumesnapshots

Step 3: Export the Snapshot to Local (Optional) #

The K8s VolumeSnapshot maps directly to a GCP Compute Engine snapshot. To retrieve the files locally, you can pull the GCP snapshot name from the cluster resources and run your export workflow:

# Get the linked VolumeSnapshotContent name
SNAPSHOT_CONTENT=$(kubectl get volumesnapshot mydrive-snapshot -o jsonpath='{.status.boundVolumeSnapshotContentName}')
# Extract the actual GCP snapshot ID
GCP_SNAPSHOT_ID=$(kubectl get volumesnapshotcontent $SNAPSHOT_CONTENT -o jsonpath='{.spec.source.snapshotHandle}')
# Use the ID to create an image and export it
gcloud compute images create mydrive-image --source-snapshot $GCP_SNAPSHOT_ID
# ... follow with your existing export/download steps

This keeps your backup workflow integrated with K8s, no extra Pods required.

内容的提问来源于stack exchange，提问作者Viktor Hedefalk