Using Ansible to Manage Kubernetes Data Protection

In this blog we will be sharing some information about Ansible and then diving into how you can use Ansible to deploy Kasten K10 in a desired state either at scale for many Kubernetes clusters or a repeatable way to automate the deployment removing the human error factor, or it could be both.

Pre reqs

1. You already have kubectl installed locally.
2. Your default ~/.kube/config points to a running Kubernetes cluster; otherwise set the K8S_AUTH_KUBECONFIG environment variable to the path to the correct kubeconfig).
3. You already have Helm installed locally. Instructions can be found here.
4. You already have Ansible installed locally. Instructions can be found here.

What is Ansible?

Before we get into specifics about Ansible we should understand that overarching use case for tools like Ansible is Configuration Management.

Configuration Management is the process of maintaining applications, systems and servers in the desired state.

Configuration management keeps you from making small or large changes that go undocumented.

For this we are going to use Ansible to deploy and keep Kasten K10 at our desired state. A few pointers though for what Ansible is capable of and a high level view of the tooling.

• Ansible is an IT automation tool that automates configuration management, cloud provisioning, deployment and orchestration.
• The core of Ansible playbooks is written in YAML.
• Ansible works well when there are environments that focus on getting things up and running fast.
• Works on playbooks which provide instructions to your servers.
• Pro – No agents are needed on remote nodes.
• Pro – YAML is easy to learn.\Architecture – Client Only
• Ease of setup – Very Easy
• Language – Procedural – Specify how to do a task

Ansible Playbooks

A playbook enables us to take our group of servers and perform configuration and installation tasks against that group.

Playbook format

Playbook > Plays > Tasks

For anyone that comes from a sports background you may have come across the term playbook, a playbook then tells the team how you will play made up of various plays and tasks if we think of the plays as the set pieces within the sport or game, and the tasks are associated to each play, you can have multiple tasks to make up a play and in the playbook, you may have multiple different plays.

Kasten K10 Playbook

Our goal is to create a Kasten K10 playbook which will enable us to not only deploy Kasten K10 into our Kubernetes cluster but also add some additional configuration to our deployment.

The first thing we are going to do in the playbook is define our “hosts” in this instance we will be using our localhost as we will be using kubectl and helm commands mostly to implement our desired state.

- hosts: localhost
  connection: local
  gather_facts: false

First of all we are going to create a number of tasks as per the list below:

Create Kasten-io namespace.

Using kubectl on our localhost we will create the kasten-io namespace, this is where our deployment will be created. If the namespace is already created then this task will be ignored.

- name: Create Kasten-io namespace.
      kubernetes.core.k8s:
        name: kasten-io
        api_version: v1
        kind: Namespace
        state: present

Add Kasten K10 chart repository.

Kasten K10 is deployed using Helm, for this we need to have helm installed on our localhost and we need to add the Kasten chart repository.

- name: Add Kasten K10 chart repository.
      kubernetes.core.helm_repository:
        name: k10
        repo_url: "https://charts.kasten.io/"

Deploy Kasten K10 Helm chart.

With the Kasten K10 helm chart there are many values for custom configuration that can be configured at installation, these can be viewed in the link shown in the task.

- name: Deploy Kasten K10 Helm chart.
      kubernetes.core.helm:
        name: k10
        chart_ref: kasten/k10
        #chart_version: 'latest'
        release_namespace: kasten-io
        state: present
        # the values shown below are related to helm chart values these can be found https://docs.kasten.io/latest/install/advanced.html#complete-list-of-k10-helm-options
        values:
          auth.tokenAuth.enabled: true 
          externalGateway.create: true
      tags:
        - deploy

Build Kasten K10 policy.

As part of the deployment we might also want to add some policies to define our data management strategy within the Kubernetes cluster. Here we are creating a policy that will be created to protect the namespace “mysql” we can also create policies here based on labels to be dynamic within many environments.

- name: Build Kasten K10 policy.
      kubernetes.core.k8s:
        apiVersion: actions.kio.kasten.io/v1alpha1
        kind: BackupAction
        metadata:
        generateName: backup-mysql-
        namespace: mysql
        labels:
          k10.kasten.io/appName: "mysql"
          k10.kasten.io/appNamespace: "mysql"
        spec:
        subject:
          name: mysql
          namespace: mysql
      tags:
        - policy

Get Kasten K10 Gateway address.

Coming to the end of the playbook, maybe we would like to know which IP address has been defined for the external gateway for Kasten K10, this gateway enables us to open the web UI to manage our Kasten K10 deployment.

   - name: Get Kasten K10 Gateway address.
      kubernetes.core.k8s_info:
        api_version: v1
        name: gateway-ext
        kind: Service
        namespace: kasten-io
        register: service

Print Kasten K10 Gateway address.

Getting and Printing are two different things, we now want to display this to our terminal in order for us to take that address and access.

    - name: Print Kasten K10 Gateway address.
      debug:
        msg: "Kasten K10 Gateway address: {{ service.resources[0].status.loadBalancer.ingress[0]}}"
      tags:
    - deploy

Just the start

The ability to set a desired state for any application and then to have a repeatable way of doing this is not only a time saver but it also removes the human mistake that is inevitable. Configuration Management tools such as Ansible provides us the ability to automate our application deployment to our environments.

This is a very simple Kasten K10 ansible playbook and there are many additional values and policies that could be added here. Full Playbook below

# Kasten K10 for Kubernetes backup via Ansible's Helm module.
#
# Run the playbook:
#
#     ansible-playbook ansible-kastenk10-playbook.yaml
---
- hosts: localhost
  connection: local
  gather_facts: false

  tasks:
    - name: Create Kasten-io namespace.
      kubernetes.core.k8s:
        name: kasten-io
        api_version: v1
        kind: Namespace
        state: present

    - name: Add Kasten K10 chart repository.
      kubernetes.core.helm_repository:
        name: k10
        repo_url: "https://charts.kasten.io/"

    - name: Deploy Kasten K10 Helm chart.
      kubernetes.core.helm:
        name: k10
        chart_ref: kasten/k10
        #chart_version: 'latest'
        release_namespace: kasten-io
        state: present
        # the values shown below are related to helm chart values these can be found https://docs.kasten.io/latest/install/advanced.html#complete-list-of-k10-helm-options
        values:
          auth.tokenAuth.enabled: true 
          externalGateway.create: true
      tags:
        - deploy 

    - name: Build Kasten K10 policy.
      kubernetes.core.k8s:
        apiVersion: actions.kio.kasten.io/v1alpha1
        kind: BackupAction
        metadata:
        generateName: backup-mysql-
        namespace: mysql
        labels:
          k10.kasten.io/appName: "mysql"
          k10.kasten.io/appNamespace: "mysql"
        spec:
        subject:
          name: mysql
          namespace: mysql
      tags:
        - policy 

    - name: Get Kasten K10 Gateway address.
      kubernetes.core.k8s_info:
        api_version: v1
        name: gateway-ext
        kind: Service
        namespace: kasten-io
        register: service
          
    - name: Print Kasten K10 Gateway address.
      debug:
        msg: "Kasten K10 Gateway address: {{ service.resources[0].status.loadBalancer.ingress[0]}}"
      tags:
        - deploy

Why don’t you see what else you can add to the playbook?