Gemini is a Kubernetes CRD and operator for managing VolumeSnapshots
. This allows you
to create a snapshot of the data on your PersistentVolumes
on a regular schedule,
retire old snapshots, and restore snapshots with minimal downtime.
The Gemini Helm chart will install both the CRD and the operator into your cluster
kubectl create ns gemini
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install gemini fairwinds-stable/gemini --namespace gemini
You'll need to have the VolumeSnapshot
API available in your cluster. This API is in
beta as of Kubernetes 1.17,
and was introduced as alpha in 1.12.
To check if your cluster has VolumeSnapshots
available, you can run
kubectl api-resources | grep volumesnapshots
- To enable on v1.12-16, set the flag
--feature-gates=VolumeSnapshotDataSource=true
on the API server binary source - To enable VolumeSnapshots on kops, see our instructions here
- Depending on your environment, you may need to configure the VolumeSnapshot API as well as the CSI. Fortunately, some managed Kubernetes providers like DigitalOcean support VolumeSnapshots by default, even on older versions
Before getting started with Gemini, it's a good idea to make sure you're able to create a VolumeSnapshot manually.
Version 2.0 of Gemini updates the CRD from v1beta1
to v1
. There are no substantial
changes, but v1
adds better support for PersistentVolumeClaims on Kubernetes 1.25.
If you want to keep the v1beta1 CRD available, you can run:
kubectl apply -f https://raw.githubusercontent.com/FairwindsOps/gemini/main/pkg/types/snapshotgroup/v1beta1/crd-with-beta1.yaml
before upgrading, and add --skip-crds
when running helm install
.
Gemini can schedule snapshots for an existing PVC, or create a new PVC to back up.
The schedule
parameter tells Gemini how often to create snapshots, and how many historical snapshots to keep.
For example, the following schedule tells Gemini to create a snapshot every day, keeping two weeks worth of history:
apiVersion: gemini.fairwinds.com/v1beta1
kind: SnapshotGroup
metadata:
name: test-volume
spec:
persistentVolumeClaim:
claimName: postgres
schedule:
- every: day
keep: 14
For a more complex example, Gemini can create new snapshots every 10 minutes, always keep the last 3 snapshots, and preserve historical hourly, daily, monthly, and yearly snapshots.
apiVersion: gemini.fairwinds.com/v1beta1
kind: SnapshotGroup
metadata:
name: test-volume
spec:
persistentVolumeClaim:
claimName: postgres
schedule:
- every: 10 minutes
keep: 3
- every: hour
keep: 1
- every: day
keep: 1
- every: month
keep: 1
- every: year
keep: 1
Note that keep
specifies how many historical snapshots you want, in addition to the most recent snapshot.
This way the schedule
- every: 10 minutes
keep: 3
will always give you at least 30 minutes of snapshot coverage. But you will see four snapshots at any given time. E.g. right after a new snapshot is created, you'll see snapshots for
- 0m ago
- 10m ago
- 20m ago
- 30m ago
See the extended example The following example schedules snapshots every 10 minutes for a pre-existing PVC named
postgres
.
apiVersion: gemini.fairwinds.com/v1beta1
kind: SnapshotGroup
metadata:
name: test-volume
spec:
persistentVolumeClaim:
claimName: postgres
schedule:
- every: 10 minutes
keep: 3
You can also specify an entire PVC spec inside the SnapshotGroup if you'd like Gemini to create the PVC for you.
apiVersion: gemini.fairwinds.com/v1beta1
kind: SnapshotGroup
metadata:
name: test-volume
spec:
persistentVolumeClaim:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
schedule:
- every: 10 minutes
keep: 3
The PVC will have the same name as the SnapshotGroup, (in this example, test-volume
)
You can use the spec.template
field to set the template for any VolumeSnapshots
that get created,
most notably the name of the snapshot class
you want to use.
apiVersion: gemini.fairwinds.com/v1beta1
kind: SnapshotGroup
metadata:
name: test-volume
spec:
persistentVolumeClaim:
claimName: postgres
schedule:
- every: "10 minutes"
keep: 3
template:
spec:
volumeSnapshotClassName: test-snapshot-class
Caution: you cannot alter a PVC without some downtime! You can restore your PVC to a particular point in time using an annotation.
First, check out what VolumeSnapshots
are available:
$ kubectl get volumesnapshot
NAME AGE
test-volume-1585945609 15s
Next, you'll need to remove any Pods that are using the PVC:
$ kubectl scale all --all --replicas=0
Then, copy the timestamp from the first step, and use that to annotate the SnapshotGroup
:
$ kubectl annotate snapshotgroup/test-volume --overwrite \
"gemini.fairwinds.com/restore=1585945609"
Finally, you can scale your Pods back up:
$ kubectl scale all --all --replicas=1
To see gemini working end-to-end, check out the CodiMD example
- Like the VolumeSnapshot API it builds on, Gemini is currently in beta
- Be sure to test out both the snapshot and restore process to ensure Gemini is working properly
- VolumeSnapshots simply grab the current state of the volume, without respect for things like in-flight database transactions. You may find you need to stop the application in order to get a consistently usable VolumeSnapshot.
The goal of the Fairwinds Community is to exchange ideas, influence the open source roadmap, and network with fellow Kubernetes users. Chat with us on Slack join the user group to get involved!
Enjoying Gemini? Check out some of our other projects:
- Polaris - Audit, enforce, and build policies for Kubernetes resources, including over 20 built-in checks for best practices
- Goldilocks - Right-size your Kubernetes Deployments by compare your memory and CPU settings against actual usage
- Pluto - Detect Kubernetes resources that have been deprecated or removed in future versions
- Nova - Check to see if any of your Helm charts have updates available
- rbac-manager - Simplify the management of RBAC in your Kubernetes clusters