Kubernetes

The Kubernetes integration backs up cluster resources and persistent volumes. It provides two connectors accessible via two URI schemes:

Requirements

• Plakar v1.1.0-beta or later.
• kubectl proxy running and accessible.
• A CSI driver with snapshot support and a configured VolumeSnapshotClass for CSI-based PVC backups.

Typical use cases

• Namespace or resource-level restore from manifest snapshots.
• Incident investigation by browsing cluster state at a point in time.
• Persistent volume backup and cross-environment data portability.

$ plakar pkg add k8s

$ plakar pkg list

$ plakar pkg build k8s

$ plakar pkg add ./k8s_v1.0.0_darwin_arm64.ptar

$ plakar pkg list

To list, upgrade, or remove the package, see managing packages guide.

The k8s:// connector fetches all Kubernetes resources across the cluster and stores them as a Plakar snapshot. This enables browsing, diffing, and restoring cluster configuration at any level of granularity — full cluster, single namespace, or individual resource.

Snapshots include resource status metadata, making them useful for incident investigation — you can browse the Plakar UI to inspect the state of deployments, nodes, and other resources at any point in time.

flowchart LR

subgraph Source["Kubernetes Cluster"]
  API["API Server"]
end

Plakar["Plakar"]

Via["Fetch manifests via
kubectl proxy"]

Transform["Encrypt & deduplicate"]

Store["Kloset Store"]

API --> Via --> Plakar --> Transform --> Store

Start a proxy to the cluster:

$ kubectl proxy
Starting to serve on 127.0.0.1:8001

Back up all resources across the entire cluster:

$ plakar backup k8s://localhost:8001

Back up resources in a specific namespace:

$ plakar backup k8s://localhost:8001/foo

Restore all StatefulSet resources in the foo namespace:

$ plakar restore -to k8s://localhost:8001 abcd:/foo/apps/StatefulSet

The k8s+csi:// connector backs up the contents of persistent volumes by creating a VolumeSnapshot, mounting it in a temporary pod running a helper importer, and ingesting the data into a Kloset store. The snapshot is deleted from the cluster once ingestion completes.

Restore works in reverse: data is written into a target PVC using the same helper pod mechanism. The target can be an existing PVC or a freshly created one.

flowchart LR

subgraph Source["Kubernetes Cluster"]
  PVC["PVC"]
  Snap["VolumeSnapshot"]
  PVC --> Snap
end

Plakar["Plakar"]

Via["Ingest via
helper pod"]

Transform["Encrypt & deduplicate"]

Store["Kloset Store"]

Snap --> Via --> Plakar --> Transform --> Store

$ plakar backup -o volume_snapshot_class=my-snapclass k8s+csi://localhost:8001/storage/my-pvc

Restore into a new, empty PVC:

$ kubectl create -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pristine
  namespace: storage
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
    - ReadWriteOnce

$ plakar restore -to k8s+csi://localhost:8001/storage/pristine abcdef:

Restore into an existing PVC by referencing it in the same way. The target PVC must have sufficient capacity.

What is captured

• All Kubernetes resource manifests and status metadata (k8s://).
• Persistent volume contents for CSI-backed PVCs (k8s+csi://).

What is not captured

• Non-CSI volumes are not yet supported for PVC backups.
• Node-level configuration (OS, kubelet config, network setup).
• In-flight workload state (open connections, in-memory data).

Snapshot consistency

Manifest snapshots reflect the state of the API server at the time of backup. For PVCs, consistency depends on the CSI driver and whether the workload was quiesced before the snapshot was taken.

• Kubernetes integration demo
• etcd integration
• Kubernetes documentation — VolumeSnapshots