What is a Kubernetes operator and do we protect them?


Userlevel 1
Badge +2

Some continuing on with our discovery and discovery in the weird and wonderful world of containers - we come to Operators (if you haven’t checked out our previous discussion on applications -  What is a Kubernetes application? and do we protect it for part I) - but today - we are going to look at Operators

 

Let's check what the Kubernetes manual says about Operators

 

Kubernetes is designed for automation. Out of the box, you get lots of built-in automation from the core of Kubernetes. You can use Kubernetes to automate deploying and running workloads, and you can automate how Kubernetes does that.

Kubernetes' controllers concept lets you extend the cluster's behaviour without modifying the code of Kubernetes itself. Operators are clients of the Kubernetes API that act as controllers for a Custom Resource.

 

 

Errr ok - what does that mean...  how about an example (again from the manual)

 

Some of the things that you can use an operator to automate include:

  • deploying an application on demand
  • taking and restoring backups of that application's state
  • handling upgrades of the application code alongside related changes such as database schemas or extra configuration settings
  • publishing a Service to applications that don't support Kubernetes APIs to discover them
  • simulating failure in all or part of your cluster to test its resilience
  • choosing a leader for a distributed application without an internal member election process

 

Ok, so let's get going and deploy one...

 

# kubectl create ns operators
namespace/operators created

 

# helm install stable/vault-operator --namespace operators --generate-name
WARNING: This chart is deprecated
W0429 23:20:58.908933 2211435 warnings.go:70] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
W0429 23:20:58.930606 2211435 warnings.go:70] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
NAME: vault-operator-1619752856
LAST DEPLOYED: Thu Apr 29 23:20:58 2021
NAMESPACE: operators
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. vault-operator deployed.

Check the vault-operator logs

export POD_NAME=$(kubectl get pods --namespace operators -l "app=vault-operator,release=vault-operator-1619752856" -o jsonpath="{.items[0].metadata.name}")
kubectl logs $POD_NAME --namespace=operators

 

Ok, so lets check if our operator is running:

 

# kubectl get pods --namespace operators
NAME READY STATUS RESTARTS AGE
vault-operator-1619752856-6494df4cbb-k5xvw 1/1 Running 0 38s

 

Ok, so let's see if Commvault can see our new operator and protect it...

 

 

Commvault can see our new operator, and select it for protection.

 

In fact, if we check out cluster - we now have a new custom resource definition (CRD) as well - which will be protected when we protect our vault-operator-1619752856 app

 

# kubectl api-resources | grep -i vault
vaultservices vault vault.security.coreos.com/v1alpha1 true VaultService

 

And if we log back in to check our backup status...

 

 

Successfully protected.

 

So what actually makes up our Operator backup, let's do a restore now...

 

 

 

We can see that Commvault discovered all the following kubernetes api-resources as related to our vault operator

 

  • operators`Deployment`vault-operator-1619752856.yaml
  • operators`Namespace`operators.yaml
  • operators`Role`vault-operator-1619752856.yaml
  • operators`RoleBinding`vault-operator-1619752856.yaml
  • operators`ServiceAccount`vault-operator-1619752856.yaml

 

Now commvault has prefixed each of these YAML manifests (think 'config file') with the text operators, this is because our operator is sitting inside the 'Operators' namespace.

 

Basically we discovered a:

  • Deployment
  • Namespace
  • Role
  • RoleBinding
  • ServiceAccount

 

If we download these, we can see the source code (YAML manifest) for each of these protected api-resources...

 

Deployment

 

apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: 1
meta.helm.sh/release-name: vault-operator-1619752856
meta.helm.sh/release-namespace: operators
generation: 1
labels:
app: vault-operator
app.kubernetes.io/managed-by: Helm
chart: vault-operator-0.1.4
heritage: Helm
release: vault-operator-1619752856
name: vault-operator-1619752856
namespace: operators
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: vault-operator
release: vault-operator-1619752856
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
labels:
app: vault-operator
release: vault-operator-1619752856
spec:
containers:
- command:
- vault-operator
env:
- name: MY_POD_NAMESPACE
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
- name: MY_POD_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
image: quay.io/coreos/vault-operator:0.1.9
imagePullPolicy: IfNotPresent
name: vault-operator
resources:
{}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext:
{}
serviceAccount: vault-operator-1619752856
serviceAccountName: vault-operator-1619752856
terminationGracePeriodSeconds: 30

 

Namespace

 

apiVersion: v1
kind: Namespace
metadata:
labels:
kubernetes.io/metadata.name: operators
name: operators
spec:
finalizers:
- kubernetes

 

Role

 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
annotations:
meta.helm.sh/release-name: vault-operator-1619752856
meta.helm.sh/release-namespace: operators
labels:
app: vault-operator
app.kubernetes.io/managed-by: Helm
chart: vault-operator-0.1.4
heritage: Helm
release: vault-operator-1619752856
name: vault-operator-1619752856
namespace: operators
rules:
- apiGroups:
- etcd.database.coreos.com
resources:
- etcdclusters
- etcdbackups
- etcdrestores
verbs:
- "*"
- apiGroups:
- vault.security.coreos.com
resources:
- vaultservices
verbs:
- "*"
- apiGroups:
- storage.k8s.io
resources:
- storageclasses
verbs:
- "*"
- apiGroups:
- ""
resources:
- pods
- services
- endpoints
- persistentvolumeclaims
- events
- configmaps
- secrets
verbs:
- "*"
- apiGroups:
- apps
resources:
- deployments
verbs:
- "*"

 

Rolebinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
annotations:
meta.helm.sh/release-name: vault-operator-1619752856
meta.helm.sh/release-namespace: operators
labels:
app: vault-operator
app.kubernetes.io/managed-by: Helm
chart: vault-operator-0.1.4
heritage: Helm
release: vault-operator-1619752856
name: vault-operator-1619752856
namespace: operators
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: vault-operator-1619752856
subjects:
- kind: ServiceAccount
name: vault-operator-1619752856
namespace: operators

 

Serviceaccount

apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
meta.helm.sh/release-name: vault-operator-1619752856
meta.helm.sh/release-namespace: operators
labels:
app: vault-operator
app.kubernetes.io/managed-by: Helm
chart: vault-operator-0.1.4
heritage: Helm
release: vault-operator-1619752856
name: vault-operator-1619752856
namespace: operators

 

The service account is particularly important - as this is where we stored the HELM chart protection information, allowing us to not only recover the "operator" but also the HELM package information - which is crucial to recovery of the HELM chart information (which chart, which chart version, etc.)

 

So rest assured - Commvault protects Operators Custom Resource Definitions (CRDs) and HELM charts...

 

All tests and output was performed on Commvault 11.23.3 release..


0 replies

Be the first to reply!

Reply