hamburger icon close icon
Kubernetes Data Management

Astra now supports Kubernetes operators!

We are excited to announce Astra Control support for the use of Kubernetes operators with your application. You can now deploy your application with a custom manifest, a helm chart, or an operator with Custom Resource Definitions (CRDs) and Custom Resource (CR) objects. No matter which method you choose, Astra Control will provide the same application data management functionality, whether it is snapshots, backups or clones of your application resources, its associated persistent volumes, and even its operator if applicable. If an operator is used, Astra Control will also snapshot and backup/restore or clone necessary CRDs and CRs along with that relationship between the operator and its associated CR on the new cluster or namespace.   


What are Kubernetes operators and why are they used?   

Kubernetes operators are one way of installing and monitoring applications and their resources with Kubernetes. They are often used to help extend automation, by allowing the operator itself to install and manage the application as a whole by ensuring the application is deployed and running properly. The operator must maintain a relationship with the application at all times in order to achieve the benefits.

The operator itself usually consists of a controller deployed in a pod with a Kubernetes deployment object to provide resiliency. Depending upon the operator and the application, the operator may be deployed in the same namespace as the application or it may be deployed in its own namespace. If an operator is deployed in the same namespace as the application it is managing, it may not require a cluster role, thereby heightening security. Astra Control requires operators be deployed in the same namespace as the application to perform application-data management.

An operator generally uses a set of CustomResourceDefinitions (CRDs) that must be deployed in the Kubernetes cluster. When we deploy a manifest file with a custom object defined by a CRD, the operator creates and manages a Custom Resource (CR) as an application. For example, a CR may consist of several Kubernetes objects, such as a deployment of loadbalancers and a statefulSet with database instances that are seen and managed as one Kubernetes entity by the operator. As seen below, the Percona XtradB operator deployed a Percona XtraDB cluster consisting of three XtraDB database instances and three HAProxy instances (as well as some other objects) and is managing it as one entity.

$ kubectl get pxc -n test
NAME           ENDPOINT                         STATUS   PXC  PROXYSQL   HAPROXY   AGE
cluster1  cluster1-haproxy.test                 ready    3                3        59m

In the above example, cluster1 is the name of the CR, and pxc is the short name for the CRD.

Can you give me an example of Astra cloning an application with an operator and a CR?

Sure thing. We will show Astra Control Service (ACS), but the same applies to Astra Control Center (ACC). We use the Percona XtradB operator with CR version 1.7 for the operator example and a wordpress frontend in the same namespace. We made a few changes to Percona's default cr.yaml file for deployment. The operator is deployed in the same namespace as the CR.

After the Kubernetes cluster is added to Astra Control, we can deploy the Percona operator with the CRDs and then the CR called xtradbcluster1 in the same wordpress namespace. We can see the Percona operator deploys our CR (xtradbcluster1), which is the PerconaXtraDB cluster.

$ kubectl get pxc -n wordpress
NAME             ENDPOINT                           STATUS   PXC   PROXYSQL   HAPROXY   AGE
xtradbcluster1   xtradbcluster1-haproxy.wordpress   ready    3                3         40m

We then deploy the wordpress application in the same namespace. After ACS discovers the application, we manage the entire namespace in Astra Control as shown below.


Within the application on Astra Control, you can see the CRDs and the CR along with the operator being managed together as part of the managed unit.


When Astra Control backs up our application or clones our application to a new namespace or cluster, the CRDs, the CR, and the operator get backed up or cloned too. This maintains the relationship with the operator as the operator brings back the CR to the new cluster or namespace. Let's see.

Let's clone our managed namespace to a different cluster, cluster-2-patd, that does not currently have the CRDs installed.


After the clone completes, we can change context to cluster-2-patd  and see the CR is still there and ready, brought back by the operator. Of course, the CRDs are there as well.

$ kubectl get pxc -n wordpress-clone
NAME             ENDPOINT                                 STATUS   PXC   PROXYSQL   HAPROXY   AGE
xtradbcluster1   xtradbcluster1-haproxy.wordpress-clone   ready    3                3         11m

We can also see it on Astra Control looking at the new cluster and namespace.


Now, we are ready to go, the new operator is ready to continue its work with the custom resource on the new cluster!

This is cool, how can I try out Astra Control with Kubernetes operators?

Download the new version of the self-managed Astra Control Center using the free trial, or sign up for the fully managed Astra Control Service free plan. If you'd like to try with the Percona XtraDB operator v1.7, you can find it here.  Install it in your lab or try it out in the cloud to provide application data management for all your Kubernetes applications. Please let us know how it goes. You can reach us at We'd love to hear from you!

Technical Marketing Engineer - NetApp Cloud Services