Storage options in kubernetes deployment and backup

Various backup options are used in modern systems. Hear i will discuss some possible methods to be used for backing up a email server with group officer .

First Lets discuss how to do a manual backup. Lets see how to copy important data from a Kubernetes storage to another backup location. (another pod)

Manual copy for backups

user@localhost ~ $ kubectl cp --help
Copy files and directories to and from containers.

# !!!Important Note!!!
# Requires that the 'tar' binary is present in your container
# image. If 'tar' is not present, 'kubectl cp' will fail.

# Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the default namespace
kubectl cp /tmp/foo_dir <some-pod>:/tmp/bar_dir

# Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific container
kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

# Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace <some-namespace>
kubectl cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar

# Copy /tmp/foo from a remote pod to /tmp/bar locally
kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar

-c, --container='': Container name. If omitted, the first container in the pod will be chosen

kubectl cp <file-spec-src> <file-spec-dest> [options]

Use "kubectl options" for a list of global command-line options (applies to all commands).

For any manual backup we have to use internal folders or volumes. Most of time we can built those important data folders as volumes. Then we have easy access and deployment wise there are some advantages to accessing those data when we use volumes. Few data storage options are discussed bellow and you may find more using the link bellow.

On-disk files in a Container are ephemeral, which presents some problems for non-trivial applications when running in Containers. First, when a Container crashes, kubelet will restart it, but the files will be lost — the Container starts with a clean state. Second, when running Containers together in a Pod it is often necessary to share files between those Containers. The Kubernetes Volume abstraction solves both of these problems.

A gcePersistentDisk volume mounts a Google Compute Engine (GCE) Persistent Disk into your Pod. Unlike emptyDir, which is erased when a Pod is removed, the contents of a PD are preserved and the volume is merely unmounted. This means that a PD can be pre-populated with data, and that data can be “handed off” between Pods. Caution: You must create a PD using gcloud or the GCE API or UI before you can use it.

There are some restrictions when using a gcePersistentDisk:

  • the nodes on which Pods are running must be GCE VMs
  • those VMs need to be in the same GCE project and zone as the PD

A hostPath volume mounts a file or directory from the host node’s filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications.

For example, some uses for a hostPath are:

  • running a Container that needs access to Docker internals; use a hostPath of /var/lib/docker
  • running cAdvisor in a Container; use a hostPath of /sys
  • allowing a Pod to specify whether a given hostPath should exist prior to the Pod running, whether it should be created, and what it should exist as

In addition to the required path property, user can optionally specify a type for a hostPath volume.

Using Kubernetes CronJob to Backup MySQL on GKE

Kubernetes backup solutions

Instead of all above cases there are sophisticated backup solutions for Kubernetes. Velero is such solution and i will update more about velero soon.