Backup and Restore of Kubernetes applications using RWX volumes – MayaData Help Center

Topics covered in this article:

Prerequisites
Creating DMaaS schedules
Restoring from DMaaS schedules
Conclusion

This article is a step-by-step guide for protecting stateful applications running on Kubernetes and their data. We will be focussing on containers which use RWX (ReadWriteMany access mode) persistent volumes using Kubera Director's DMaaS feature.

We are using an NFS server to provision an RWX volume. This volume is consumed by a WordPress deployment in a 3-replica HA setup. The NFS server is backed by an OpenEBS volume, however, this guide is compatible with all Kubernetes persistent volumes -- OpenEBS or otherwise.

Click here to read more about about configuring an NFS server provisioner using OpenEBS.

DMaaS (Data Migration as a Service) is used to create backups of stateful (and stateless) Kubernetes applications. These backups can be conveniently restored into a remote Kubernetes cluster. DMaaS is a part of Kubera Director. To learn more about DMaaS, click here.

Prerequisites

You will need a Kubera Standard or Kubera Enterprise subscription plan to use DMaaS. To know more about different Kubera subscription plans, click here.

If you already have a Kubera account, you can check for the Kubera subscription plan you are using at director.mayadata.io/subscriptions.

DMaaS backup and restore requires one 'source cluster' and one 'destination cluster'. Essentially, the same Kubernetes cluster may act as both the source and the destination.

A Kubernetes cluster running Kubernetes v1.12 or above:
This is a prerequisite for Kubera Director Online. You will also need to have the kubectl tool configured for this cluster.
The cluster must not have the pod-network CIDR set as 169.254.0.0/16:
This is a prerequisite for Kubera Director Online.
A Kubernetes Deployment or StatefulSet object:
To create a DMaaS backup schedule, the application has to be created as a Deployment or a StatefulSet. The application can be stateful (with dynamically provisioned persistent storage) or stateless (no persistent storage). You can check for Deployments and StatefulSets in the application's namespace using the command kubectl get deployment,statefulset -n <application-namespace>

We are using a 3-node source cluster -- let's call it 'cluster-1'.

We have an ‘nfs’ namespace which contains the NFS server provisioner statefulset. The provisioner is backed by a dynamically provisioned OpenEBS Local PV volume.

niladri@cluster-1-master:~$ kubectl -n nfs get statefulset,service,persistentvolumeclaim
NAME                                          READY   AGE
statefulset.apps/nfs-nfs-server-provisioner   1/1     2d19h

NAME                                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                                                     AGE
service/nfs-nfs-server-provisioner   ClusterIP   10.104.71.25   <none>        2049/TCP,2049/UDP,32803/TCP,32803/UDP,20048/TCP,20048/UDP,875/TCP,875/UDP,111/TCP,111/UDP,662/TCP,662/UDP   2d19h

NAME                                                      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
persistentvolumeclaim/data-nfs-nfs-server-provisioner-0   Bound    pvc-eaf0b3c7-5a7e-4362-bd33-cb6d7d703acb   15Gi       RWO            openebs-hostpath   2d19h

niladri@cluster-1-master:~$ kubectl get storageclass wp-nfs-sc
NAME        PROVISIONER                        RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
wp-nfs-sc   wordpress-nfs-server-provisioner   Delete          Immediate           true                   3d1h

We have a 'wordpress' namespace with a 3-replica WordPress deployment backed by MariaDB statefulsets. The WordPress pods together consume the RWX NFS volume. The MariaDB database is configured for high-availability with 1 master and 2 slaves. The MariaDB pods consume OpenEBS Local PV volumes. The WordPress webpage is made available at the domain https://wordpress.mayalabs.io.

niladri@cluster-1-master:~$ kubectl -n wordpress get deployment,statefulset,pod,service,secret,ingress,persistentvolumeclaim -o wide
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES                                            SELECTOR
deployment.apps/wordpress   3/3     3            3           2d14h   wordpress    docker.io/bitnami/wordpress:5.4.2-debian-10-r26   app.kubernetes.io/instance=wordpress,app.kubernetes.io/name=wordpress

NAME                                        READY   AGE     CONTAINERS   IMAGES
statefulset.apps/wordpress-mariadb-master   1/1     2d14h   mariadb      docker.io/bitnami/mariadb:10.3.23-debian-10-r44
statefulset.apps/wordpress-mariadb-slave    2/2     2d14h   mariadb      docker.io/bitnami/mariadb:10.3.23-debian-10-r44

NAME                             READY   STATUS    RESTARTS   AGE     IP             NODE               NOMINATED NODE   READINESS GATES
pod/wordpress-5f75df99f-d2p76    1/1     Running   0          112s    192.168.3.87   cluster-1-node-3   <none>           <none>
pod/wordpress-5f75df99f-s9zf9    1/1     Running   0          112s    192.168.2.90   cluster-1-node-2   <none>           <none>           
pod/wordpress-5f75df99f-v5f2s    1/1     Running   0          112s    192.168.1.89   cluster-1-node-1   <none>           <none>           
pod/wordpress-mariadb-master-0   1/1     Running   1          2d4h    192.168.2.85   cluster-1-node-2   <none>           <none>           
pod/wordpress-mariadb-slave-0    1/1     Running   2          2d14h   192.168.3.82   cluster-1-node-3   <none>           <none>           
pod/wordpress-mariadb-slave-1    1/1     Running   2          2d14h   192.168.1.85   cluster-1-node-1   <none>           <none>           

NAME                              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE     SELECTOR
service/wordpress                 ClusterIP   10.103.62.15    <none>        80/TCP,443/TCP   2d14h   app.kubernetes.io/instance=wordpress,app.kubernetes.io/name=wordpress
service/wordpress-mariadb         ClusterIP   10.96.247.158   <none>        3306/TCP         2d14h   app=mariadb,component=master,release=wordpress
service/wordpress-mariadb-slave   ClusterIP   10.99.92.212    <none>        3306/TCP         2d14h   app=mariadb,component=slave,release=wordpress

NAME                                     TYPE                                  DATA   AGE
secret/default-token-8w7fb               kubernetes.io/service-account-token   3      2d14h
secret/sh.helm.release.v1.wordpress.v1   helm.sh/release.v1                    1      2d14h
secret/wordpress                         Opaque                                1      2d14h
secret/wordpress-mariadb                 Opaque                                3      2d14h
secret/wordpress.mayalabs.io-tls         kubernetes.io/tls                     2      2d14h

NAME                           CLASS    HOSTS                   ADDRESS                               PORTS     AGE
ingress.extensions/wordpress   <none>   wordpress.mayalabs.io   10.63.10.55,10.63.10.56,10.63.10.57   80, 443   2d14h

NAME                                                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE     VOLUMEMODE
persistentvolumeclaim/data-wordpress-mariadb-master-0   Bound    pvc-13813791-99e3-43c5-a53c-bf57d68767cc   8Gi        RWO            openebs-hostpath   2d14h   Filesystem
persistentvolumeclaim/data-wordpress-mariadb-slave-0    Bound    pvc-b3ed8b86-1664-4b58-b03f-3472d5f7427b   8Gi        RWO            openebs-hostpath   2d14h   Filesystem
persistentvolumeclaim/data-wordpress-mariadb-slave-1    Bound    pvc-100d7d7e-e0ce-4d58-aadb-7eecf88bd0d6   8Gi        RWO            openebs-hostpath   2d14h   Filesystem
persistentvolumeclaim/wordpress-pvc                     Bound    pvc-e45d253f-753f-44b3-9881-94dbf05295bf   8Gi        RWX            wp-nfs-sc          2d14h   Filesystem

We also have a MinIO deployment in 'bucket' namespace which is also consuming an RWX NFS volume. It is also configured for high-availability with 3 replicas spread across 3 nodes.

niladri@cluster-1-master:~$ kubectl -n bucket get pods,persistentvolumeclaim -o wide
NAME                         READY   STATUS    RESTARTS   AGE   IP             NODE               NOMINATED NODE   READINESS GATES
pod/minio-68755645b5-4bjdm   1/1     Running   0          10m   192.168.3.88   cluster-1-node-3   <none>           <none>
pod/minio-68755645b5-lg87f   1/1     Running   0          10m   192.168.2.91   cluster-1-node-2   <none>           <none>
pod/minio-68755645b5-tszt8   1/1     Running   0          10m   192.168.1.90   cluster-1-node-1   <none>           <none>

NAME                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE    VOLUMEMODE
persistentvolumeclaim/minio-pvc   Bound    pvc-87982b4d-9e46-4462-bc8b-db576996a0f0   4Gi        RWX            wp-nfs-sc      2d3h   Filesystem

A Kubernetes cluster running Kubernetes v1.12 or above:
This is a prerequisite for Kubera Director Online. You will also need to have the kubectl tool configured for this cluster.
The cluster must not have the pod-network CIDR set as 169.254.0.0/16:
This is a prerequisite for Kubera Director Online.
The application's Namespace must be present:
The namespace used by the application (Deployment/StatefulSet and PersistentVolumeClaim) in the source cluster must also be present in the destination cluster.
The Service Account used by the pods of your application must be present:
The service account used by the pods in their namespace in the source cluster, must be present in the destination cluster. The Role/ClusterRole and RoleBinding/ClusterRoleBinding objects for the service account must also be present. To check for the service accounts in your application's namespace in the source cluster, use the command kubectl get serviceaccount -n <application-namespace>.
- To check for RoleBindings for your applications's service account (<service-account-name>), in your application's namespace (<application-namespace>) execute the following in your source cluster:
```
kubectl -n <application-namespace> get rolebinding $(kubectl -n <application-namespace> get rolebinding -o=go-template --template='{{range .items}}{{$result:=.metadata.name}}{{range .subjects}}{{if eq .kind "ServiceAccount"}}{{if eq .name "<service-account-name>"}}{{printf $result}}{{" "}}{{end}}{{end}}{{end}}{{end}}') -o wide
```
  You also have to copy the corresponding Role/ClusterRole objects in <application-namespace>.
- To check for ClusterRoleBindings for your applications's service account (<service-account-name>), execute the following in your source cluster:
```
kubectl get clusterrolebinding $(kubectl get clusterrolebinding -o=go-template --template='{{range .items}}{{$result:=.metadata.name}}{{range .subjects}}{{if eq .kind "ServiceAccount"}}{{if eq .namespace "<application-namespace>"}}{{if eq .name "<service-account-name>"}}{{printf $result}}{{" "}}{{end}}{{end}}{{end}}{{end}}{{end}}') -o wide
```
  You also have to copy the corresponding ClusterRole objects.
The StorageClasses used to provision the volume must be present:
The storageclasses used to provision the persistent volumes in the source cluster, must be present in the destination cluster.
The image registry used to pull the container images for the application pods must be present:
An image registry must be configured at the exact domain/IP address as the one used by the pods in the source cluster. Also, it has to be able to authenticate using the same ImagePullSecret (if present) as the registry in the source cluster.

You can skip this if you do not use a private registry, or if the images are already present in the kubelet's local cache and the spec.containers[].ImagePullPolicy in the Deployment/StatefulSet is set to IfNotPresent.
The external load balancer/ingress controller must be configured manually:
If the application was exposed by an ingress controller in the source cluster, then an ingress controller is required in the destination for the applications service to be exposed. The annotations in the ingress object must be changed based on the ingress controller type and configuration. The service/endpoints/ingress/TLS certificates may be changed manually using kubectl commands as desired after the DMaaS operation also, in case the setup in the destination cluster is different from that of the source cluster.
TLS certificates and certificate management must be handled manually:
If the application uses TLS, the TLS secret must be created in the application's namespace before proceeding with DMaaS.

In case the application used a certificate management controller service, the relevant Kubernetes objects of said management controller must be present in the destination cluster before the DMaaS restore operation is started. E.g.: If the TLS certificate for the application was issued by cert-manager in the source cluster, the cert-manager namespace, the cert-manager webhook, the cert-manager service, the Issuer/ClusterIssuer object (metadata.name must be the same) must be present in the destination cluster. The TLS certificate secret will be generated during the DMaaS restore.

We are using a 3-node destination cluster -- let's call it 'cluster-2'.

We have manually created the application namespace using the command:

kubectl create ns wordpress

niladri@cluster-2-master:~$ kubectl get ns 
NAME              STATUS   AGE
default           Active   9d
ingress-nginx     Active   4d14h
kube-node-lease   Active   9d
kube-public       Active   9d
kube-system       Active   9d
metallb-system    Active   9d
nfs               Active   4d14h
openebs           Active   9d
wordpress         Active   4d3h

The WordPress and MariaDB pods use the 'default' service account in the wordpress namespace, with no additional RoleBinding or ClusterRoleBinding. For our use-case, the service account and the RoleBinding/ClusterRoleBinding objects need not be manually created.

The storageclass used by MariaDB in the source cluster is 'openebs-hostpath'. We have installed OpenEBS on the destination cluster to acquire this storageclass. The RWX NFS volume for the WordPress pods were created using a storageclass named 'wp-nfs-sc'. We have createn an NFS provisioner in the destination cluster and we have kept the name of the storageclass the same -- wp-nfs-sc.

niladri@cluster-2-master:~$ kubectl get sc openebs-hostpath wp-nfs-sc
NAME               PROVISIONER                        RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
openebs-hostpath   openebs.io/local                   Delete          WaitForFirstConsumer   false                  9d
wp-nfs-sc          wordpress-nfs-server-provisioner   Delete          Immediate              true                   4d13h

We are not using a private registry, so, for our use-case, we can pull the container images from Quay.

We are using an ingress controller to expose our services in cluster-2, hence, we can accommodate the ingress Kubernetes objects that will be created during the DMaaS restore. We have an external load balancer, but the configuration on it need not be changed, as we are using an ingress.

We are not using a certificate management controller. We have to manually create the TLS secret on the destination cluster. We have used our signed TLS certificate (wordpress.crt) and private key (wordpress.key) with the following command:

kubectl create secret tls wordpress.mayalabs.io-tls --cert=wordpress.crt --key=wordpress.key --namespace=wordpress

Note: To use the source cluster as the destination cluster for a DMaaS restore, you have to remove the application deployment/statefulset, secrets, ingress, services, volumes, PVCs. TLS secrets maintained by cert-manager, and also the Certificate object of the same name, must also be removed. After removing these resources, you may follow the DMaaS restore steps.

DMaaS backup and restore involves 2 major operations:

Creating a backup schedule:
You will create a backup schedule for the application. You will have to decide on the frequency of backup operations, the object store you want to use for the backup files (AWS S3/GCP Cloud Storage/MinIO/Cloudian HyperStore), and the number of full backups you want to maintain.
Restoring from a backup schedule:
You will restore a 'Completed' backup linked to your previously-created backup schedule from your object store.

Creating DMaaS schedules

STEP 1

Note:

If you are sitting behind a proxy server, you can configure Kubera Director for it by using the 'Advanced' option when you are adding a cluster. Click here for detailed instructions.

If you are using Red Hat OpenShift Container Platform or OpenShift Enterprise, you might have to add the cstorpoolauto service account to the 'privileged' SCC. Use the command oc adm policy add-scc-to-user privileged system:serviceaccount:maya-system:cstorpoolauto.

STEP 2

Select your cluster from the 'Clusters' option from your Project pane.

STEP 3

Click on the 'Applications' option in your Cluster pane.

STEP 4

Click on the name of the application that you want to create a backup schedule for. In our case, we will go with the 'wordpress-mariadb-master' StatefulSet. We will create schedules for the other deployments/statefulsets in the steps below.

STEP 5

Select the DMaaS tab and click on ‘New schedule’.

STEP 6

In this step, you will create the backup schedule.

Select your object store of choice -- AWS S3 / GCP Cloud Storage / MinIO / Cloudian HyperStore
Select the credentials for the object store from the 'Provider credentials' drop-down list.
Set the backup frequency from the drop-down lists under 'Time Interval'.
In the 'Backup retention count' box, enter the number of full backups (the remaining backups will be incremental) you would like to maintain.
Click on 'Schedule now'.

In our case, we have selected AWS S3 object store, a half-hour backup frequency, and have chosen to maintain 5 full backups.

Note: If you don’t have credentials listed in the drop-down, you’ll have to add them. Click on ‘Add Credentials’ to add the credentials for your data store (e.g. add the Access Key ID and the Secret Access Key of your AWS account, if you want to use your S3 bucket as the data store for your DMaaS backups).

STEP 7

Follow steps 3 through 6 to create backup schedules for your remaining applications/micro-services. In our case, we have created schedules for 'wordpress-mariadb-master' StatefulSet, 'wordpress-mariadb-slave' StatefulSet and 'wordpress' Deployment.

You can check get the status of the backup schedules by clicking on the 'DMaaS' option in the Project pane.

Restoring from DMaaS schedules

Before continuing with the restoration, please make sure that your destination cluster satisfies the requirements in the 'Prerequisites for destination cluster' section.

STEP 1

Connect the destination cluster to Kubera Director -- director.mayadata.io

STEP 2

Click on the 'DMaaS' option in the Project pane.

STEP 3

Click on the restore option next to the name of the schedule which you want to restore. In our case, we will go with the 'wordpress-mariadb-master' schedule first.

STEP 4

Select the name of the destination cluster from the drop-down list and click on 'Start restore'. We have selected 'cluster-2-tmva8'.

STEP 5

Click on the 'Restore' link on the pop-up to check the status of the on-going restore.

STEP 6

Follow steps 2 through 5 again to restore other application/micro-services. After restoring from the schedule for 'wordpress-maridb-master', we have restored from the schedules for 'wordpress-mariadb-slave' and 'wordpress'.

Conclusion

We can go to the 'Applications' section in cluster-2 and see the WordPress deployment and the MariaDB statefulsets.

We can verify this through the CLI as well.

niladri@cluster-2-master:~$ kubectl -n wordpress get deployment,statefulset,pod,service,secret,ingress,persistentvolumeclaim -o wide
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                            SELECTOR
deployment.apps/wordpress   3/3     3            3           8h    wordpress    docker.io/bitnami/wordpress:5.4.2-debian-10-r26   app.kubernetes.io/instance=wordpress,app.kubernetes.io/name=wordpress

NAME                                        READY   AGE     CONTAINERS   IMAGES
statefulset.apps/wordpress-mariadb-master   1/1     8h      mariadb      docker.io/bitnami/mariadb:10.3.23-debian-10-r44
statefulset.apps/wordpress-mariadb-slave    2/2     8h      mariadb      docker.io/bitnami/mariadb:10.3.23-debian-10-r44

NAME                             READY   STATUS    RESTARTS   AGE     IP             NODE               NOMINATED NODE   READINESS GATES
pod/wordpress-5f75df99f-d2p76    1/1     Running   3          8h      192.168.1.54   cluster-2-node-1   <none>           <none>
pod/wordpress-5f75df99f-s9zf9    1/1     Running   6          8h      192.168.2.59   cluster-2-node-2   <none>           <none>
pod/wordpress-5f75df99f-v5f2s    1/1     Running   7          8h      192.168.3.59   cluster-2-node-3   <none>           <none>
pod/wordpress-mariadb-master-0   1/1     Running   0          8h      192.168.2.69   cluster-2-node-2   <none>           <none>
pod/wordpress-mariadb-slave-0    1/1     Running   0          8h      192.168.1.69   cluster-2-node-1   <none>           <none>
pod/wordpress-mariadb-slave-1    1/1     Running   0          8h      192.168.3.68   cluster-2-node-3   <none>           <none>

NAME                              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE     SELECTOR
service/wordpress                 ClusterIP   10.96.72.225     <none>        80/TCP,443/TCP   8h      app.kubernetes.io/instance=wordpress,app.kubernetes.io/name=wordpress
service/wordpress-mariadb         ClusterIP   10.107.188.170   <none>        3306/TCP         8h      app=mariadb,component=master,release=wordpress
service/wordpress-mariadb-slave   ClusterIP   10.111.245.140   <none>        3306/TCP         8h      app=mariadb,component=slave,release=wordpress

NAME                               TYPE                                  DATA   AGE
secret/default-token-vx9j9         kubernetes.io/service-account-token   3      4d14h
secret/wordpress                   Opaque                                1      8h
secret/wordpress-mariadb           Opaque                                3      8h
secret/wordpress.mayalabs.io-tls   kubernetes.io/tls                     2      8h

NAME                           CLASS    HOSTS                   ADDRESS                               PORTS     AGE
ingress.extensions/wordpress   <none>   wordpress.mayalabs.io   10.63.10.51,10.63.10.52,10.63.10.53   80, 443   8h

NAME                                                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE     VOLUMEMODE
persistentvolumeclaim/data-wordpress-mariadb-master-0   Bound    pvc-c312202f-e75d-4810-b84f-d3b2f8f93fca   8Gi        RWO            openebs-hostpath   8h      Filesystem
persistentvolumeclaim/data-wordpress-mariadb-slave-0    Bound    pvc-52f80751-6b39-4f36-8820-ecb8f6538e2a   8Gi        RWO            openebs-hostpath   8h      Filesystem
persistentvolumeclaim/data-wordpress-mariadb-slave-1    Bound    pvc-aacb68cd-a10f-433d-af1c-0101bdb39e7a   8Gi        RWO            openebs-hostpath   8h      Filesystem
persistentvolumeclaim/wordpress-pvc                     Bound    pvc-68985f30-4d43-4dce-90cc-8555886f9f3e   8Gi        RWX            wp-nfs-sc          8h      Filesystem

Also, we can see that the MinIO application in the source cluster's 'bucket' namespace is absent from the destination cluster.

niladri@cluster-2-master:~$ kubectl -n bucket get pods
No resources found in bucket namespace.
niladri@cluster-2-master:~$ kubectl get ns
NAME              STATUS   AGE
default           Active   9d
ingress-nginx     Active   5d1h
kube-node-lease   Active   9d
kube-public       Active   9d
kube-system       Active   9d
maya-system       Active   9h
metallb-system    Active   9d
nfs               Active   5d1h
openebs           Active   9d
wordpress         Active   4d14h

HOSTING BOTH SEPARATELY

The two WordPress services are exposed using the same domain name.
Source cluster:

niladri@cluster-1-master:~$ kubectl get ingress --all-namespaces
NAMESPACE   NAME        CLASS    HOSTS                   ADDRESS                               PORTS     AGE
bucket      minio       <none>   minio.mayalabs.io       10.63.10.55,10.63.10.56,10.63.10.57   80, 443   4d12h
wordpress   wordpress   <none>   wordpress.mayalabs.io   10.63.10.55,10.63.10.56,10.63.10.57   80, 443   5d2h
niladri@cluster-1-master:~$ kubectl get service -n ingress-nginx
NAME                                               TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-ingress-controller                   LoadBalancer   10.109.21.135   10.63.10.58   80:30324/TCP,443:30714/TCP   6d
ingress-nginx-ingress-controller-default-backend   ClusterIP      10.111.57.166   <none>        80/TCP                       6d
niladri@cluster-1-master:~$ kubectl get secret -n wordpress wordpress.mayalabs.io-tls
NAME                        TYPE                DATA   AGE
wordpress.mayalabs.io-tls   kubernetes.io/tls   2      5d2h

Destination cluster:

niladri@cluster-2-master:~$ kubectl get ingress --all-namespaces
NAMESPACE   NAME        CLASS    HOSTS                   ADDRESS                               PORTS     AGE
wordpress   wordpress   <none>   wordpress.mayalabs.io   10.63.10.51,10.63.10.52,10.63.10.53   80, 443   9h
niladri@cluster-2-master:~$ kubectl get service -n ingress-nginx
NAME                                               TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-ingress-controller                   LoadBalancer   10.107.127.98   10.63.10.59   80:31248/TCP,443:32178/TCP   5d1h
ingress-nginx-ingress-controller-default-backend   ClusterIP      10.103.103.84   <none>        80/TCP                       5d1h
niladri@cluster-2-master:~$ kubectl get secret -n wordpress wordpress.mayalabs.io-tls 
NAME                        TYPE                DATA   AGE
wordpress.mayalabs.io-tls   kubernetes.io/tls   2      10h

If the services are hosted in isolated networks (or they use different DNS), then the WordPress webpages in the two clusters will be accessible separately within their separate networks. No changes are required for this use-case.

If both the services are in the same network (or using the the same DNS), you will have to assign a unique domain name to either of these, for them to be separately reachable. In our use-case, both of our clusters are inside the same subnet and we are using the same DNS.

To mitigate this, we will use a different domain name (https://wordpress1.mayalabs.io) for the destination cluster's service. We will also add a DNS entry to our nameserver for this newly created domain name. To change the domain name, we will edit the manifest YAML of the 'wordpress' ingress (this is being done in the destination cluster).

kubectl -n wordpress edit ingress wordpress

Initial:

spec:
  rules:
  - host: wordpress.mayalabs.io
    http:
      paths:
      - backend:
          serviceName: wordpress
          servicePort: http
        path: /
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - wordpress.mayalabs.io
    secretName: wordpress.mayalabs.io-tls

Final:

spec:
  rules:
  - host: wordpress1.mayalabs.io
    http:
      paths:
      - backend:
          serviceName: wordpress
          servicePort: http
        path: /
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - wordpress1.mayalabs.io
    secretName: wordpress1.mayalabs.io-tls

We are using TLS encryption for the webpage. Our present TLS certificate is generated for the previous domain name (wordpress.mayalabs.io). So, we will delete the previous TLS secret...

kubectl -n wordpress delete secret wordpress.mayalabs.io-tls

... and create the new one using the new certificate (wordpress1.crt) and private key (wordpress1.key).

kubectl create secret tls wordpress1.mayalabs.io-tls --cert=wordpress1.crt --key=wordpress1.key --namespace=wordpress

After this, we can verify that the service is available at https://wordpress1.mayalabs.io (destination cluster).

Let's add a post to the source cluster webpage...

As you can see, the service on the destination cluster is unaffected!

Related articles

Articles in this section