{"id":916,"date":"2024-10-25T06:57:22","date_gmt":"2024-10-25T06:57:22","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=916"},"modified":"2024-10-25T06:57:22","modified_gmt":"2024-10-25T06:57:22","slug":"backup-and-restore-eks-cluster-velero","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=916","title":{"rendered":"How To Backup and Restore EKS Cluster Using Velero"},"content":{"rendered":"

In this blog, we will look at step by step instructions to backup and restore EKS cluster<\/a> using Velero in Kubernetes.<\/p>

We all know the importance of backing up a Kubernetes cluster<\/a>. There are several solutions are available for Kubernetes cluster backup and restoration.<\/p>

However, Velero stands out because it can back up both cluster resources and the storage associated with the cluster.<\/p>

When backing up a cluster, there are two key aspects to keep in mind:<\/p>

  1. ETCD key-value store<\/a> that contains all the cluster-related configuration information.<\/li>
  2. Persistent storage solutions hold your applications’ data running inside the cluster.<\/li><\/ol>

    So, when performing a backup, both should be included.<\/p>

    To store the backup, I am using Amazon S3, a storage service from AWS.<\/p>

    Prerequisites<\/h3>
    1. EKS Cluster (v1.31)<\/li>
    2. EKSCTL (v0.191.0) should be available on the local machine<\/li>
    3. Kubectl (v1.31.0) should be available on the local machine<\/li>
    4. AWS CLI (v2.18.10) should be available on the local machine and configured with the required permissions.<\/li>
    5. Helm (v3.16.1) should be available on your local system.<\/li><\/ol>

      Velero Backup Workflow<\/h2>

      The following image shows Velero’s high-level workflow.<\/p>

      \"velero<\/figure>\n\n
        \n
      1. The Velero CLI is on the local machine, which can help initiate the backup\/restore using CLI commands.<\/li>\n\n\n
      2. The request will go through the Kubernetes API server to the Velero Pod, and the Velero Pod contains the Init Container, which is for the AWS scoped plugin for Velero and has the main Velero container.<\/li>\n\n\n
      3. The Init container provides the AWS-specific files to the main container before it starts. <\/li>\n\n\n
      4. Both containers get the AWS temporary credentials via Pod Identity Agent to access the AWS services. <\/li>\n\n\n
      5. The main container keeps watching the Velero Custom Resource Definitions (CRDs). If any changes happen on those resources, the Velero raises API calls to the Kubernetes API to make the changes. \n