Kasten K10 by Veeam backs up your Kubernetes applications by capturing the content of your namespace as a single unit, including:
- Configuration (Secrets, configmap, roles, rolebinding …)
- Workload (Deployment, Statefulset, DaemonSet … )
- Custom resource used by your operators
- Data PV, PVC and their contents
But there is one thing we don’t capture: the container image. That’s because images are built on pipelines that are not in your target Kubernetes cluster. In general, they are stored in image registries outside your target Kubernetes cluster. Fortunately, Red Hat’s OpenShift with imagestream provides an alternative approach.
What Brought This About?
Red Hat saw that developers were good at producing code, but not good at building robust images. Building and testing images frequently require good resource management and a container-friendly environment. OpenShift is able to provide both.
To reduce time to market, it was important to reduce the time between image building and application deployment. For many teams that were starting their journey in containers, maintaining and coordinating a CI/CD tool to build the image and a docker registry to store the images — with a container orchestration like Kubernetes to deploy them — was too complicated, and they needed an all-in-one solution that was easy to launch.
For all of those reasons, Red Hat created imagestream, which abstracts the referencing container images from within the OpenShift Container Platform. It works on top of an internal docker registry and is fed by an OpenShift build process called BuildConfig. The best part? It’s provided out of the box when you deploy OpenShift.
Here is an overview of the process starting from developer code to application deployment:
- The developer creates a build config with a reference to his code.
- The build config knows how to build an image that transforms this code into an image, and this image is automatically pushed to the internal registry and represented as an imagestream.
- A deployment that references this imagestream automatically rolls out if changes happen in the imagestream — and that’s easy to detect, because the registry is internal.
For many companies this new approach accelerates agility in a very cost-effective way.
The Caveats
Of course there are some caveats:
- The image registry is meant to be internal, so it’s impossible to pull the image from another OpenShift or Kubernetes cluster.
- If you lose your OpenShift cluster, you also lose your images. That’s the issue with “all in one”.
- You keep the developer code and the buildconfig in GIT, but there is no guarantee that you’ll rebuild the same image or build at all, because dependencies in a build process are not stable (libraries are updated or removed, build tools are updated, and so on). Freezing all kinds of dependencies is just impossible.
As a result of these drawbacks, migrations, complete backup or multi-cluster deployments are impossible (or very difficult) when using buildconfig and imagestreams.
Extending Kasten K10 to Include Imagestream in the Backup Process
Kasten K10 uses Kanister to extend any backup operation. Simply annotate any API Object with a reference to a blueprint, and the blueprint executes taking the annotated object as an input parameter.
To solve the backup and migration issue, we can annotate the imagestream with a blueprint that sends all of the images in this imagestream to an external registry. When restoring the whole application in the same OpenShift cluster or in another OpenShift cluster, the images are pulled back from the external registry to the OpenShift internal registry, hence recreating an identical imagestream.
The Imagestream Blueprint
A classic backup without a blueprint will backup data and specifications. Imagestream is a specification that points to real images, just as PV is a specification that points to real files. But, that won’t create a backup of the images.
A backup with the imagestreams annotated with the blueprint will create a backup of the image and will also allow the mobility of the app to export the image in the internal registry of the OpenShift destination cluster.
Refer to this guide on github to install and use this blueprint.
Click here for information about Kasten K10 or using Kanister for app-level data management.
