From ba8a267e48d828cb31afc819588f127a8ba255c6 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Thu, 15 Jan 2026 13:07:58 +0600 Subject: [PATCH 01/51] kafka gitops Signed-off-by: Bonusree --- docs/guides/kafka/gitops/_index.md | 10 + docs/guides/kafka/gitops/gitops.md | 908 +++++++++++++++++++++++++++ docs/guides/kafka/gitops/overview.md | 50 ++ 3 files changed, 968 insertions(+) create mode 100644 docs/guides/kafka/gitops/_index.md create mode 100644 docs/guides/kafka/gitops/gitops.md create mode 100644 docs/guides/kafka/gitops/overview.md diff --git a/docs/guides/kafka/gitops/_index.md b/docs/guides/kafka/gitops/_index.md new file mode 100644 index 0000000000..165e948d79 --- /dev/null +++ b/docs/guides/kafka/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: Gitops Kafka +menu: + docs_{{ .version }}: + identifier: kf-gitops-kafka + name: Gitops + parent: kf-kafka-guides + weight: 25 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/kafka/gitops/gitops.md b/docs/guides/kafka/gitops/gitops.md new file mode 100644 index 0000000000..d9cd087f1a --- /dev/null +++ b/docs/guides/kafka/gitops/gitops.md @@ -0,0 +1,908 @@ +--- +title: GitOps KafkaQL +menu: + docs_{{ .version }}: + identifier: kf-using-gitops + name: GitOps KafkaQL + parent: kf-gitops-Kafka + weight: 15 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Kafka using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create Kafka database and manage updates using GitOps workflow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/kafka](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/kafka) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create Kafka Database using GitOps + +### Create a Kafka GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: Standard + controller: + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── Kafka.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is created in your cluster. + +Our `gitops` operator will create an actual `Kafka` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get kafka.gitops.kubedb.com,kafka.kubedb.com -n demo +NAME AGE +kafka.gitops.kubedb.com/kafka-prod 2m56s + +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 2m56s +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` Kafka. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=kafka-prod' +NAME AGE +petset.apps.k8s.appscode.com/kafka-prod-broker 4m49s +petset.apps.k8s.appscode.com/kafka-prod-controller 4m47s + +NAME READY STATUS RESTARTS AGE +pod/kafka-prod-broker-0 1/1 Running 0 4m48s +pod/kafka-prod-broker-1 1/1 Running 0 4m42s +pod/kafka-prod-controller-0 1/1 Running 0 4m47s +pod/kafka-prod-controller-1 1/1 Running 0 4m40s + +NAME TYPE DATA AGE +secret/kafka-prod-auth kubernetes.io/basic-auth 2 4m51s + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/kafka-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/kafka-prod kubedb.com/kafka 3.9.0 4m47s +``` + +## Update Kafka Database using GitOps + +### Scale Kafka Database Resources + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut + ``` + +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `KafkaOpsRequest` to update the `Kafka` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ $ kubectl get kf,kafka,kfops -n demo +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +kafka.gitops.kubedb.com/kafka-prod 22h + +NAME TYPE STATUS AGE +Kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo Kafka-prod-broker-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +``` + +### Scale Kafka Replicas +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` KafkaOpsRequest to update the `Kafka` database replicas. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,kafka,kfops -n demo +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +kafka.gitops.kubedb.com/kafka-prod 22h + +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=kafka-prod' +NAME READY STATUS RESTARTS AGE +kafka-prod-broker-0 1/1 Running 0 34m +kafka-prod-broker-1 1/1 Running 0 33m +kafka-prod-broker-2 1/1 Running 0 33m +kafka-prod-controller-0 1/1 Running 0 32m +kafka-prod-controller-1 1/1 Running 0 31m +kafka-prod-controller-2 1/1 Running 0 31m +``` + +We can also scale down the replicas by updating the `replicas` fields. + +### Expand Kafka Volume + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` KafkaOpsRequest to update the `Kafka` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,kafka,kfops -n demo +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 23m + +NAME AGE +kafka.gitops.kubedb.com/kafka-prod 23m + +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=kafka-prod' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +kafka-prod-data-kafka-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +kafka-prod-data-kafka-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +kafka-prod-data-kafka-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +kafka-prod-data-kafka-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m + +``` + +## Reconfigure Kafka + +At first, we will create a secret containing `user.conf` file with required configuration settings. +To know more about this configuration file, check [here](/docs/guides/kafka/configuration/kafka-combined.md) +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: new-kf-combined-custom-config + namespace: demo +stringData: + server.properties: |- + log.retention.hours=125 +``` + +Now, we will add this file to `kubedb /kf-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ └── Kafka.yaml +1 directories, 2 files +``` + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-prod + namespace: demo +spec: + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` KafkaOpsRequest to update the `Kafka` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,kafka,kfops -n demo +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 74m + +NAME AGE +kafka.gitops.kubedb.com/kafka-prod 74m + +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 24m +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m + +``` + + + +> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. + +### Rotate Kafka Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, + +```bash +kubectl create secret generic kf-rotate-auth -n demo \ +--type=kubernetes.io/basic-auth \ +--from-literal=username=kafka \ +--from-literal=password=kafka-secret +secret/kf-rotate-auth created + +``` + + + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-prod + namespace: demo +spec: + authSecret: + kind: Secret + name: kf-rotate-auth + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` KafkaOpsRequest to update the `Kafka` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,kafka,kfops -n demo +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 7m11s + +NAME AGE +kafka.gitops.kubedb.com/kafka-prod 7m11s + +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 17h +kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 28m +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h + +``` + + +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Kafka. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating a ca certificates using openssl. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +Generating a RSA private key +................+++++ +........................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls kafka-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/Kafka-ca created +``` + +Now, Let's create an `Issuer` using the `Kafka-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: kf-issuer + namespace: demo +spec: + ca: + secretName: kafka-ca +``` + +Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ ├── kf-issuer.yaml +│ └── Kafka.yaml +1 directories, 4 files +``` + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` KafkaOpsRequest to update the `Kafka` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,kafka,kfops,pods -n demo +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 41m + +NAME AGE +kafka.gitops.kubedb.com/kafka-prod 75m + +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 5d18h +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h + +``` + + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Kafka. + +### Update Version + +List Kafka versions using `kubectl get Kafkaversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/kafka/update-version/versionupgrading/index.md). + +Let's choose `4.0.0` in this example. + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` KafkaOpsRequest to update the `Kafka` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,kafka,kfops -n demo +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-prod kubedb.com/v1 4.0.0 Ready 3h47m + +NAME AGE +kafka.gitops.kubedb.com/kafka-prod 3h47m + +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 5d22h +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h +kafkaopsrequest.ops.kubedb.com/kafka-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +``` + + +Now, we are going to verify whether the `Kafka`, `PetSet` and it's `Pod` have updated with new image. Let's check, + +```bash +$ kubectl get Kafka -n demo kafka-prod -o=jsonpath='{.spec.version}{"\n"}' +4.0.0 + +$ kubectl get petset -n demo kafka-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 + +$ kubectl get pod -n demo kafka-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +``` + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9091 + serviceMonitor: + labels: + release: prometheus + interval: 10s + deletionPolicy: WipeOut +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` KafkaOpsRequest to add the `Kafka` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get Kafkaes.gitops.kubedb.com,Kafkaes.kubedb.com,Kafkaopsrequest -n demo +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-prod kubedb.com/v1 4.0.0 Ready 5h12m + +NAME AGE +kafka.gitops.kubedb.com/kafka-prod 5h12m + +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 6d +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +kafkaopsrequest.ops.kubedb.com/kafka-prod-restart-ljpqih Restart Successful 3m51s +kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h +kafkaopsrequest.ops.kubedb.com/kafka-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d + +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `.spec.leaderElection` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + +## Next Steps + +[//]: # (- Learn Kafka [GitOps](/docs/guides/kafka/concepts/Kafka-gitops.md)) +- Learn Kafka Scaling + - [Horizontal Scaling](/docs/guides/kafka/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/kafka/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/kafka/update-version/overview.md) +- Monitor your KafkaQL database with KubeDB using [built-in Prometheus](/docs/guides/kafka/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/kafka/gitops/overview.md b/docs/guides/kafka/gitops/overview.md new file mode 100644 index 0000000000..c041506597 --- /dev/null +++ b/docs/guides/kafka/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: Kafka GitOps Overview +description: Kafka GitOps Overview +menu: + docs_{{ .version }}: + identifier: kf-gitops-overview + name: Overview + parent: kf-gitops-kafka + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for Kafka + +This guide will give you an overview of how KubeDB `gitops` operator works with Kafka databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Kafka databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [Kafka](/docs/guides/kafka/concepts/kafka.md) + - [KafkaOpsRequest](/docs/guides/kafka/concepts/kafkaopsrequest.md) + + + +## Workflow GitOps with Kafka + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + + +
+ + GitOps Flow + +
Fig: GitOps process of Kafka
+ +
+ +1. **Define GitOps Kafka**: Create Custom Resource (CR) of kind `Kafka` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Kafka CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the KafkaGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing Kafka databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running Kafka using GitOps. From b700d346ffaaaef376554119407c3e53ae3708b0 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Thu, 15 Jan 2026 13:20:14 +0600 Subject: [PATCH 02/51] url fixed Signed-off-by: Bonusree --- docs/guides/kafka/gitops/gitops.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guides/kafka/gitops/gitops.md b/docs/guides/kafka/gitops/gitops.md index d9cd087f1a..509243a7dc 100644 --- a/docs/guides/kafka/gitops/gitops.md +++ b/docs/guides/kafka/gitops/gitops.md @@ -707,7 +707,7 @@ kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansi ### Update Version -List Kafka versions using `kubectl get Kafkaversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/kafka/update-version/versionupgrading/index.md). +List Kafka versions using `kubectl get Kafkaversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/kafka/update-version/update-version.md). Let's choose `4.0.0` in this example. From 0e5956c6ad69ee3e49a21f51845c0db381be75dd Mon Sep 17 00:00:00 2001 From: Bonusree Date: Thu, 15 Jan 2026 17:16:44 +0600 Subject: [PATCH 03/51] title Signed-off-by: Bonusree --- docs/guides/kafka/gitops/gitops.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/guides/kafka/gitops/gitops.md b/docs/guides/kafka/gitops/gitops.md index 509243a7dc..bfcb9ef602 100644 --- a/docs/guides/kafka/gitops/gitops.md +++ b/docs/guides/kafka/gitops/gitops.md @@ -1,15 +1,17 @@ --- -title: GitOps KafkaQL +title: Kafka GitOps Guides +description: Kafka GitOps menu: docs_{{ .version }}: - identifier: kf-using-gitops - name: GitOps KafkaQL - parent: kf-gitops-Kafka - weight: 15 + identifier: kf-gitops-guides + name: Gitops Kafka + parent: kf-gitops-kafka + weight: 20 menu_name: docs_{{ .version }} section_menu_id: guides --- + > New to KubeDB? Please start [here](/docs/README.md). # GitOps Kafka using KubeDB GitOps Operator @@ -889,7 +891,6 @@ There are some other fields that will trigger `Restart` ops request. - `.spec.monitor` - `.spec.spec.archiver` - `.spec.remoteReplica` -- `.spec.leaderElection` - `spec.replication` - `.spec.standbyMode` - `.spec.streamingMode` From 7055724b589f7f30937d96fe60f14415bd1ebddf Mon Sep 17 00:00:00 2001 From: Bonusree Date: Thu, 15 Jan 2026 17:53:50 +0600 Subject: [PATCH 04/51] changed weight Signed-off-by: Bonusree --- docs/guides/kafka/autoscaler/_index.md | 2 +- docs/guides/kafka/cli/_index.md | 2 +- docs/guides/kafka/clustering/_index.md | 2 +- docs/guides/kafka/configuration/_index.md | 2 +- docs/guides/kafka/connectcluster/_index.md | 2 +- docs/guides/kafka/gitops/_index.md | 4 ++-- docs/guides/kafka/migration/_index.md | 2 +- docs/guides/kafka/monitoring/_index.md | 2 +- docs/guides/kafka/reconfigure-tls/_index.md | 2 +- docs/guides/kafka/reconfigure/_index.md | 2 +- docs/guides/kafka/restart/_index.md | 2 +- docs/guides/kafka/restproxy/_index.md | 2 +- docs/guides/kafka/rotate-auth/_index.md | 2 +- docs/guides/kafka/scaling/_index.md | 2 +- docs/guides/kafka/schemaregistry/_index.md | 2 +- docs/guides/kafka/tls/_index.md | 2 +- docs/guides/kafka/update-version/_index.md | 2 +- docs/guides/kafka/volume-expansion/_index.md | 2 +- 18 files changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/guides/kafka/autoscaler/_index.md b/docs/guides/kafka/autoscaler/_index.md index 22a1e3830d..c6d7e89abd 100644 --- a/docs/guides/kafka/autoscaler/_index.md +++ b/docs/guides/kafka/autoscaler/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-auto-scaling name: Autoscaling parent: kf-kafka-guides - weight: 46 + weight: 90 menu_name: docs_{{ .version }} --- \ No newline at end of file diff --git a/docs/guides/kafka/cli/_index.md b/docs/guides/kafka/cli/_index.md index 155f42086b..e879f4f433 100755 --- a/docs/guides/kafka/cli/_index.md +++ b/docs/guides/kafka/cli/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-cli-kafka name: CLI parent: kf-kafka-guides - weight: 100 + weight: 95 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/clustering/_index.md b/docs/guides/kafka/clustering/_index.md index 21b81a7433..6cab222d4f 100755 --- a/docs/guides/kafka/clustering/_index.md +++ b/docs/guides/kafka/clustering/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-clustering name: Clustering parent: kf-kafka-guides - weight: 20 + weight: 25 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/configuration/_index.md b/docs/guides/kafka/configuration/_index.md index 81167c2af8..1ef769c0de 100644 --- a/docs/guides/kafka/configuration/_index.md +++ b/docs/guides/kafka/configuration/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-configuration name: Custom Configuration parent: kf-kafka-guides - weight: 30 + weight: 35 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/connectcluster/_index.md b/docs/guides/kafka/connectcluster/_index.md index 7d833caaad..44991d14d8 100644 --- a/docs/guides/kafka/connectcluster/_index.md +++ b/docs/guides/kafka/connectcluster/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-connectcluster-guides name: ConnectCluster parent: kf-kafka-guides - weight: 25 + weight: 40 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/gitops/_index.md b/docs/guides/kafka/gitops/_index.md index 165e948d79..098093afa8 100644 --- a/docs/guides/kafka/gitops/_index.md +++ b/docs/guides/kafka/gitops/_index.md @@ -2,9 +2,9 @@ title: Gitops Kafka menu: docs_{{ .version }}: - identifier: kf-gitops-kafka + identifier: kf-gitops name: Gitops parent: kf-kafka-guides - weight: 25 + weight: 30 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/migration/_index.md b/docs/guides/kafka/migration/_index.md index 0f8b4d2e11..84e3194925 100644 --- a/docs/guides/kafka/migration/_index.md +++ b/docs/guides/kafka/migration/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-migration-kafka name: Migration parent: kf-kafka-guides - weight: 27 + weight: 60 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/monitoring/_index.md b/docs/guides/kafka/monitoring/_index.md index 05429b728c..16cc76ef21 100755 --- a/docs/guides/kafka/monitoring/_index.md +++ b/docs/guides/kafka/monitoring/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-monitoring-kafka name: Monitoring parent: kf-kafka-guides - weight: 50 + weight: 60 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/reconfigure-tls/_index.md b/docs/guides/kafka/reconfigure-tls/_index.md index 5b2552a6df..e4f77b4897 100644 --- a/docs/guides/kafka/reconfigure-tls/_index.md +++ b/docs/guides/kafka/reconfigure-tls/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-reconfigure-tls name: Reconfigure TLS/SSL parent: kf-kafka-guides - weight: 46 + weight: 55 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/reconfigure/_index.md b/docs/guides/kafka/reconfigure/_index.md index 86d8888b6b..7a9181a21e 100644 --- a/docs/guides/kafka/reconfigure/_index.md +++ b/docs/guides/kafka/reconfigure/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-reconfigure name: Reconfigure parent: kf-kafka-guides - weight: 46 + weight: 45 menu_name: docs_{{ .version }} --- \ No newline at end of file diff --git a/docs/guides/kafka/restart/_index.md b/docs/guides/kafka/restart/_index.md index d0d4240b4d..1199fe4aee 100644 --- a/docs/guides/kafka/restart/_index.md +++ b/docs/guides/kafka/restart/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-restart name: Restart parent: kf-kafka-guides - weight: 46 + weight: 75 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/restproxy/_index.md b/docs/guides/kafka/restproxy/_index.md index b02df6b52b..1e1e168204 100644 --- a/docs/guides/kafka/restproxy/_index.md +++ b/docs/guides/kafka/restproxy/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-rest-proxy-guides name: RestProxy parent: kf-kafka-guides - weight: 25 + weight: 60 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/rotate-auth/_index.md b/docs/guides/kafka/rotate-auth/_index.md index 8409073897..ed2cf8a38f 100644 --- a/docs/guides/kafka/rotate-auth/_index.md +++ b/docs/guides/kafka/rotate-auth/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-rotate-auth name: Rotate Authentication parent: kf-kafka-guides - weight: 45 + weight: 85 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/scaling/_index.md b/docs/guides/kafka/scaling/_index.md index 98b83c7106..48781a47d3 100644 --- a/docs/guides/kafka/scaling/_index.md +++ b/docs/guides/kafka/scaling/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-scaling name: Scaling parent: kf-kafka-guides - weight: 43 + weight: 70 menu_name: docs_{{ .version }} --- \ No newline at end of file diff --git a/docs/guides/kafka/schemaregistry/_index.md b/docs/guides/kafka/schemaregistry/_index.md index 31f884753c..64a1212659 100644 --- a/docs/guides/kafka/schemaregistry/_index.md +++ b/docs/guides/kafka/schemaregistry/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-schema-registry-guides name: SchemaRegistry parent: kf-kafka-guides - weight: 25 + weight: 60 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/tls/_index.md b/docs/guides/kafka/tls/_index.md index 1b5fe9d947..d923206728 100755 --- a/docs/guides/kafka/tls/_index.md +++ b/docs/guides/kafka/tls/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-tls name: TLS/SSL Encryption parent: kf-kafka-guides - weight: 45 + weight: 50 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/kafka/update-version/_index.md b/docs/guides/kafka/update-version/_index.md index 08f8af5d4f..2581cfd25e 100644 --- a/docs/guides/kafka/update-version/_index.md +++ b/docs/guides/kafka/update-version/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-update-version name: UpdateVersion parent: kf-kafka-guides - weight: 42 + weight: 65 menu_name: docs_{{ .version }} --- \ No newline at end of file diff --git a/docs/guides/kafka/volume-expansion/_index.md b/docs/guides/kafka/volume-expansion/_index.md index 27c8e1f8ba..dddfb1563b 100644 --- a/docs/guides/kafka/volume-expansion/_index.md +++ b/docs/guides/kafka/volume-expansion/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-volume-expansion name: Volume Expansion parent: kf-kafka-guides - weight: 44 + weight: 80 menu_name: docs_{{ .version }} --- \ No newline at end of file From d8cf4ced282f5aec3881aed614823c623b69f5aa Mon Sep 17 00:00:00 2001 From: Bonusree Date: Fri, 16 Jan 2026 15:33:51 +0600 Subject: [PATCH 05/51] organize front Signed-off-by: Bonusree --- docs/guides/druid/gitops/_index.md | 11 + docs/guides/druid/gitops/gitops.md | 906 +++++++++++++++++++++++++++ docs/guides/druid/gitops/overview.md | 50 ++ docs/guides/kafka/gitops/gitops.md | 1 - docs/guides/kafka/gitops/overview.md | 6 +- 5 files changed, 970 insertions(+), 4 deletions(-) create mode 100644 docs/guides/druid/gitops/_index.md create mode 100644 docs/guides/druid/gitops/gitops.md create mode 100644 docs/guides/druid/gitops/overview.md diff --git a/docs/guides/druid/gitops/_index.md b/docs/guides/druid/gitops/_index.md new file mode 100644 index 0000000000..c7207d6eb4 --- /dev/null +++ b/docs/guides/druid/gitops/_index.md @@ -0,0 +1,11 @@ +--- +title: Druid Gitops +menu: + docs_{{ .version }}: + identifier: guides-druid-gitops + name: Gitops + parent: guides-druid + weight: 45 +menu_name: docs_{{ .version }} +--- + diff --git a/docs/guides/druid/gitops/gitops.md b/docs/guides/druid/gitops/gitops.md new file mode 100644 index 0000000000..e974f667ef --- /dev/null +++ b/docs/guides/druid/gitops/gitops.md @@ -0,0 +1,906 @@ +--- +title: Druid Gitops Guide +menu: + docs_{{ .version }}: + identifier: druid-gitops-guide + name: Druid Gitops + parent: guides-druid-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Druid using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create Druid database and manage updates using GitOps workflow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/druid](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/druid) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create Druid Database using GitOps + +### Create a Druid GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Druid +metadata: + name: Druid-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: Standard + controller: + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── Druid.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is created in your cluster. + +Our `gitops` operator will create an actual `Druid` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get Druid.gitops.kubedb.com,Druid.kubedb.com -n demo +NAME AGE +Druid.gitops.kubedb.com/Druid-prod 2m56s + +NAME TYPE VERSION STATUS AGE +Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 2m56s +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` Druid. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=Druid-prod' +NAME AGE +petset.apps.k8s.appscode.com/Druid-prod-broker 4m49s +petset.apps.k8s.appscode.com/Druid-prod-controller 4m47s + +NAME READY STATUS RESTARTS AGE +pod/Druid-prod-broker-0 1/1 Running 0 4m48s +pod/Druid-prod-broker-1 1/1 Running 0 4m42s +pod/Druid-prod-controller-0 1/1 Running 0 4m47s +pod/Druid-prod-controller-1 1/1 Running 0 4m40s + +NAME TYPE DATA AGE +secret/Druid-prod-auth kubernetes.io/basic-auth 2 4m51s + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/Druid-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/Druid-prod kubedb.com/Druid 3.9.0 4m47s +``` + +## Update Druid Database using GitOps + +### Scale Druid Database Resources + +Update the `Druid.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Druid +metadata: + name: Druid-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut + ``` + +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `DruidOpsRequest` to update the `Druid` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ $ kubectl get kf,Druid,kfops -n demo +NAME TYPE VERSION STATUS AGE +Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +Druid.gitops.kubedb.com/Druid-prod 22h + +NAME TYPE STATUS AGE +Druidopsrequest.ops.kubedb.com/Druid-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo Druid-prod-broker-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +``` + +### Scale Druid Replicas +Update the `Druid.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Druid +metadata: + name: Druid-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` DruidOpsRequest to update the `Druid` database replicas. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Druid,kfops -n demo +NAME TYPE VERSION STATUS AGE +Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +Druid.gitops.kubedb.com/Druid-prod 22h + +NAME TYPE STATUS AGE +Druidopsrequest.ops.kubedb.com/Druid-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Druidopsrequest.ops.kubedb.com/Druid-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=Druid-prod' +NAME READY STATUS RESTARTS AGE +Druid-prod-broker-0 1/1 Running 0 34m +Druid-prod-broker-1 1/1 Running 0 33m +Druid-prod-broker-2 1/1 Running 0 33m +Druid-prod-controller-0 1/1 Running 0 32m +Druid-prod-controller-1 1/1 Running 0 31m +Druid-prod-controller-2 1/1 Running 0 31m +``` + +We can also scale down the replicas by updating the `replicas` fields. + +### Expand Druid Volume + +Update the `Druid.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Druid +metadata: + name: Druid-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` DruidOpsRequest to update the `Druid` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Druid,kfops -n demo +NAME TYPE VERSION STATUS AGE +Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 23m + +NAME AGE +Druid.gitops.kubedb.com/Druid-prod 23m + +NAME TYPE STATUS AGE +Druidopsrequest.ops.kubedb.com/Druid-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Druidopsrequest.ops.kubedb.com/Druid-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=Druid-prod' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +Druid-prod-data-Druid-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +Druid-prod-data-Druid-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +Druid-prod-data-Druid-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +Druid-prod-data-Druid-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m + +``` + +## Reconfigure Druid + +At first, we will create a secret containing `user.conf` file with required configuration settings. +To know more about this configuration file, check [here](/docs/guides/Druid/configuration/Druid-combined.md) +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: new-kf-combined-custom-config + namespace: demo +stringData: + server.properties: |- + log.retention.hours=125 +``` + +Now, we will add this file to `kubedb /kf-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ └── Druid.yaml +1 directories, 2 files +``` + +Update the `Druid.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Druid +metadata: + name: Druid-prod + namespace: demo +spec: + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` DruidOpsRequest to update the `Druid` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Druid,kfops -n demo +NAME TYPE VERSION STATUS AGE +Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 74m + +NAME AGE +Druid.gitops.kubedb.com/Druid-prod 74m + +NAME TYPE STATUS AGE +Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 24m +Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m + +``` + + + +> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. + +### Rotate Druid Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, + +```bash +kubectl create secret generic kf-rotate-auth -n demo \ +--type=kubernetes.io/basic-auth \ +--from-literal=username=Druid \ +--from-literal=password=Druid-secret +secret/kf-rotate-auth created + +``` + + + +Update the `Druid.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Druid +metadata: + name: Druid-prod + namespace: demo +spec: + authSecret: + kind: Secret + name: kf-rotate-auth + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` DruidOpsRequest to update the `Druid` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Druid,kfops -n demo +NAME TYPE VERSION STATUS AGE +Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 7m11s + +NAME AGE +Druid.gitops.kubedb.com/Druid-prod 7m11s + +NAME TYPE STATUS AGE +Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 17h +Druidopsrequest.ops.kubedb.com/Druid-prod-rotate-auth-43ris8 RotateAuth Successful 28m +Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h + +``` + + +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Druid. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating a ca certificates using openssl. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +Generating a RSA private key +................+++++ +........................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls Druid-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/Druid-ca created +``` + +Now, Let's create an `Issuer` using the `Druid-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: kf-issuer + namespace: demo +spec: + ca: + secretName: Druid-ca +``` + +Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ ├── kf-issuer.yaml +│ └── Druid.yaml +1 directories, 4 files +``` + +Update the `Druid.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Druid +metadata: + name: Druid-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` DruidOpsRequest to update the `Druid` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Druid,kfops,pods -n demo +NAME TYPE VERSION STATUS AGE +Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 41m + +NAME AGE +Druid.gitops.kubedb.com/Druid-prod 75m + +NAME TYPE STATUS AGE +Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 5d18h +Druidopsrequest.ops.kubedb.com/Druid-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +Druidopsrequest.ops.kubedb.com/Druid-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h +Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h + +``` + + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Druid. + +### Update Version + +List Druid versions using `kubectl get Druidversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Druid/update-version/update-version.md). + +Let's choose `4.0.0` in this example. + +Update the `Druid.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Druid +metadata: + name: Druid-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` DruidOpsRequest to update the `Druid` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Druid,kfops -n demo +NAME TYPE VERSION STATUS AGE +Druid.kubedb.com/Druid-prod kubedb.com/v1 4.0.0 Ready 3h47m + +NAME AGE +Druid.gitops.kubedb.com/Druid-prod 3h47m + +NAME TYPE STATUS AGE +Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 5d22h +Druidopsrequest.ops.kubedb.com/Druid-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +Druidopsrequest.ops.kubedb.com/Druid-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h +Druidopsrequest.ops.kubedb.com/Druid-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m +Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +``` + + +Now, we are going to verify whether the `Druid`, `PetSet` and it's `Pod` have updated with new image. Let's check, + +```bash +$ kubectl get Druid -n demo Druid-prod -o=jsonpath='{.spec.version}{"\n"}' +4.0.0 + +$ kubectl get petset -n demo Druid-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Druid:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 + +$ kubectl get pod -n demo Druid-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Druid:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +``` + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `Druid.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Druid +metadata: + name: Druid-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Druid + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9091 + serviceMonitor: + labels: + release: prometheus + interval: 10s + deletionPolicy: WipeOut +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` DruidOpsRequest to add the `Druid` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get Druides.gitops.kubedb.com,Druides.kubedb.com,Druidopsrequest -n demo +NAME TYPE VERSION STATUS AGE +Druid.kubedb.com/Druid-prod kubedb.com/v1 4.0.0 Ready 5h12m + +NAME AGE +Druid.gitops.kubedb.com/Druid-prod 5h12m + +NAME TYPE STATUS AGE +Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 6d +Druidopsrequest.ops.kubedb.com/Druid-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +Druidopsrequest.ops.kubedb.com/Druid-prod-restart-ljpqih Restart Successful 3m51s +Druidopsrequest.ops.kubedb.com/Druid-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h +Druidopsrequest.ops.kubedb.com/Druid-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m +Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d + +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + +## Next Steps + +[//]: # (- Learn Druid [GitOps](/docs/guides/Druid/concepts/Druid-gitops.md)) +- Learn Druid Scaling + - [Horizontal Scaling](/docs/guides/Druid/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/Druid/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/Druid/update-version/overview.md) +- Monitor your DruidQL database with KubeDB using [built-in Prometheus](/docs/guides/Druid/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/druid/gitops/overview.md b/docs/guides/druid/gitops/overview.md new file mode 100644 index 0000000000..05e8c54337 --- /dev/null +++ b/docs/guides/druid/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: Druid GitOps Overview +description: Druid GitOps Overview +menu: + docs_{{ .version }}: + identifier: kf-gitops-overview + name: Overview + parent: kf-gitops-Druid + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for Druid + +This guide will give you an overview of how KubeDB `gitops` operator works with Druid databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Druid databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [Druid](/docs/guides/druid/concepts/druid.md) + - [DruidOpsRequest](/docs/guides/druid/concepts/druidopsrequest.md) + + + +## Workflow GitOps with Druid + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + + +
+ + GitOps Flow + +
Fig: GitOps process of Druid
+ +
+ +1. **Define GitOps Druid**: Create Custom Resource (CR) of kind `Druid` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Druid CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the DruidGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing Druid databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running Druid using GitOps. diff --git a/docs/guides/kafka/gitops/gitops.md b/docs/guides/kafka/gitops/gitops.md index bfcb9ef602..e5b5b2d964 100644 --- a/docs/guides/kafka/gitops/gitops.md +++ b/docs/guides/kafka/gitops/gitops.md @@ -1,6 +1,5 @@ --- title: Kafka GitOps Guides -description: Kafka GitOps menu: docs_{{ .version }}: identifier: kf-gitops-guides diff --git a/docs/guides/kafka/gitops/overview.md b/docs/guides/kafka/gitops/overview.md index c041506597..cf959a479f 100644 --- a/docs/guides/kafka/gitops/overview.md +++ b/docs/guides/kafka/gitops/overview.md @@ -1,11 +1,11 @@ --- -title: Kafka GitOps Overview -description: Kafka GitOps Overview +title: Kafka Gitops Overview +description: Kafka Gitops Overview menu: docs_{{ .version }}: identifier: kf-gitops-overview name: Overview - parent: kf-gitops-kafka + parent: kf-gitops weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides From 4d2906690cfe3c09b98058c84febc38cdae1498a Mon Sep 17 00:00:00 2001 From: Bonusree Date: Wed, 21 Jan 2026 15:05:03 +0600 Subject: [PATCH 06/51] Signed-off-by: Bonusree --- docs/guides/druid/gitops/_index.md | 11 - docs/guides/elasticsearch/gitops/_index.md | 10 + .../{druid => elasticsearch}/gitops/gitops.md | 360 +++++++++--------- .../gitops/overview.md | 30 +- 4 files changed, 206 insertions(+), 205 deletions(-) delete mode 100644 docs/guides/druid/gitops/_index.md create mode 100644 docs/guides/elasticsearch/gitops/_index.md rename docs/guides/{druid => elasticsearch}/gitops/gitops.md (71%) rename docs/guides/{druid => elasticsearch}/gitops/overview.md (63%) diff --git a/docs/guides/druid/gitops/_index.md b/docs/guides/druid/gitops/_index.md deleted file mode 100644 index c7207d6eb4..0000000000 --- a/docs/guides/druid/gitops/_index.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Druid Gitops -menu: - docs_{{ .version }}: - identifier: guides-druid-gitops - name: Gitops - parent: guides-druid - weight: 45 -menu_name: docs_{{ .version }} ---- - diff --git a/docs/guides/elasticsearch/gitops/_index.md b/docs/guides/elasticsearch/gitops/_index.md new file mode 100644 index 0000000000..a13bc58303 --- /dev/null +++ b/docs/guides/elasticsearch/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: Elasticsearch Gitops +menu: + docs_{{ .version }}: + identifier: es-gitops + name: Elasticsearch Gitops + parent: es-elasticsearch-guides + weight: 65 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/druid/gitops/gitops.md b/docs/guides/elasticsearch/gitops/gitops.md similarity index 71% rename from docs/guides/druid/gitops/gitops.md rename to docs/guides/elasticsearch/gitops/gitops.md index e974f667ef..e5b5b2d964 100644 --- a/docs/guides/druid/gitops/gitops.md +++ b/docs/guides/elasticsearch/gitops/gitops.md @@ -1,19 +1,21 @@ --- -title: Druid Gitops Guide +title: Kafka GitOps Guides menu: - docs_{{ .version }}: - identifier: druid-gitops-guide - name: Druid Gitops - parent: guides-druid-gitops - weight: 10 + docs_{{ .version }}: + identifier: kf-gitops-guides + name: Gitops Kafka + parent: kf-gitops-kafka + weight: 20 menu_name: docs_{{ .version }} section_menu_id: guides --- + + > New to KubeDB? Please start [here](/docs/README.md). -# GitOps Druid using KubeDB GitOps Operator +# GitOps Kafka using KubeDB GitOps Operator -This guide will show you how to use `KubeDB` GitOps operator to create Druid database and manage updates using GitOps workflow. +This guide will show you how to use `KubeDB` GitOps operator to create Kafka database and manage updates using GitOps workflow. ## Before You Begin @@ -30,7 +32,7 @@ This guide will show you how to use `KubeDB` GitOps operator to create Druid dat $ kubectl create ns demo namespace/demo created ``` -> Note: YAML files used in this tutorial are stored in [docs/examples/druid](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/druid) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). +> Note: YAML files used in this tutorial are stored in [docs/examples/kafka](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/kafka) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). @@ -52,14 +54,14 @@ argocd app create kubedb --repo --path kubedb --dest-server https://k argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa ``` -## Create Druid Database using GitOps +## Create Kafka Database using GitOps -### Create a Druid GitOps CR +### Create a Kafka GitOps CR ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Druid +kind: Kafka metadata: - name: Druid-prod + name: kafka-prod namespace: demo spec: version: 3.9.0 @@ -90,58 +92,58 @@ Create a directory like below, ```bash $ tree . ├── kubedb - └── Druid.yaml + └── Kafka.yaml 1 directories, 1 files ``` -Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is created in your cluster. +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is created in your cluster. -Our `gitops` operator will create an actual `Druid` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. +Our `gitops` operator will create an actual `Kafka` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get Druid.gitops.kubedb.com,Druid.kubedb.com -n demo +$ kubectl get kafka.gitops.kubedb.com,kafka.kubedb.com -n demo NAME AGE -Druid.gitops.kubedb.com/Druid-prod 2m56s +kafka.gitops.kubedb.com/kafka-prod 2m56s NAME TYPE VERSION STATUS AGE -Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 2m56s +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 2m56s ``` -List the resources created by `kubedb` operator created for `kubedb.com/v1` Druid. +List the resources created by `kubedb` operator created for `kubedb.com/v1` Kafka. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=Druid-prod' +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=kafka-prod' NAME AGE -petset.apps.k8s.appscode.com/Druid-prod-broker 4m49s -petset.apps.k8s.appscode.com/Druid-prod-controller 4m47s +petset.apps.k8s.appscode.com/kafka-prod-broker 4m49s +petset.apps.k8s.appscode.com/kafka-prod-controller 4m47s NAME READY STATUS RESTARTS AGE -pod/Druid-prod-broker-0 1/1 Running 0 4m48s -pod/Druid-prod-broker-1 1/1 Running 0 4m42s -pod/Druid-prod-controller-0 1/1 Running 0 4m47s -pod/Druid-prod-controller-1 1/1 Running 0 4m40s +pod/kafka-prod-broker-0 1/1 Running 0 4m48s +pod/kafka-prod-broker-1 1/1 Running 0 4m42s +pod/kafka-prod-controller-0 1/1 Running 0 4m47s +pod/kafka-prod-controller-1 1/1 Running 0 4m40s NAME TYPE DATA AGE -secret/Druid-prod-auth kubernetes.io/basic-auth 2 4m51s +secret/kafka-prod-auth kubernetes.io/basic-auth 2 4m51s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/Druid-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s +service/kafka-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/Druid-prod kubedb.com/Druid 3.9.0 4m47s +appbinding.appcatalog.appscode.com/kafka-prod kubedb.com/kafka 3.9.0 4m47s ``` -## Update Druid Database using GitOps +## Update Kafka Database using GitOps -### Scale Druid Database Resources +### Scale Kafka Database Resources -Update the `Druid.yaml` with the following, +Update the `Kafka.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Druid +kind: Kafka metadata: - name: Druid-prod + name: kafka-prod namespace: demo spec: version: 3.9.0 @@ -150,7 +152,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1540Mi @@ -169,7 +171,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1540Mi @@ -188,25 +190,25 @@ spec: deletionPolicy: WipeOut ``` -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. -Now, `gitops` operator will detect the resource changes and create a `DruidOpsRequest` to update the `Druid` database. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the resource changes and create a `KafkaOpsRequest` to update the `Kafka` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ $ kubectl get kf,Druid,kfops -n demo +$ $ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 22h +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 22h NAME AGE -Druid.gitops.kubedb.com/Druid-prod 22h +kafka.gitops.kubedb.com/kafka-prod 22h NAME TYPE STATUS AGE -Druidopsrequest.ops.kubedb.com/Druid-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +Kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo Druid-prod-broker-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo Kafka-prod-broker-0 -o json | jq '.spec.containers[0].resources' { "limits": { "memory": "1536Mi" @@ -218,13 +220,13 @@ $ kubectl get pod -n demo Druid-prod-broker-0 -o json | jq '.spec.containers[0]. } ``` -### Scale Druid Replicas -Update the `Druid.yaml` with the following, +### Scale Kafka Replicas +Update the `Kafka.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Druid +kind: Kafka metadata: - name: Druid-prod + name: kafka-prod namespace: demo spec: version: 3.9.0 @@ -233,7 +235,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1540Mi @@ -252,7 +254,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1540Mi @@ -271,44 +273,44 @@ spec: deletionPolicy: WipeOut ``` -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` DruidOpsRequest to update the `Druid` database replicas. List the resources created by `gitops` operator in the `demo` namespace. +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` KafkaOpsRequest to update the `Kafka` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Druid,kfops -n demo +$ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 22h +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 22h NAME AGE -Druid.gitops.kubedb.com/Druid-prod 22h +kafka.gitops.kubedb.com/kafka-prod 22h NAME TYPE STATUS AGE -Druidopsrequest.ops.kubedb.com/Druid-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Druidopsrequest.ops.kubedb.com/Druid-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +kafkaopsrequest.ops.kubedb.com/kafka-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=Druid-prod' +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=kafka-prod' NAME READY STATUS RESTARTS AGE -Druid-prod-broker-0 1/1 Running 0 34m -Druid-prod-broker-1 1/1 Running 0 33m -Druid-prod-broker-2 1/1 Running 0 33m -Druid-prod-controller-0 1/1 Running 0 32m -Druid-prod-controller-1 1/1 Running 0 31m -Druid-prod-controller-2 1/1 Running 0 31m +kafka-prod-broker-0 1/1 Running 0 34m +kafka-prod-broker-1 1/1 Running 0 33m +kafka-prod-broker-2 1/1 Running 0 33m +kafka-prod-controller-0 1/1 Running 0 32m +kafka-prod-controller-1 1/1 Running 0 31m +kafka-prod-controller-2 1/1 Running 0 31m ``` We can also scale down the replicas by updating the `replicas` fields. -### Expand Druid Volume +### Expand Kafka Volume -Update the `Druid.yaml` with the following, +Update the `Kafka.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Druid +kind: Kafka metadata: - name: Druid-prod + name: kafka-prod namespace: demo spec: version: 3.9.0 @@ -317,7 +319,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -336,7 +338,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -355,39 +357,39 @@ spec: deletionPolicy: WipeOut ``` -Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. -Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` DruidOpsRequest to update the `Druid` database volume. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` KafkaOpsRequest to update the `Kafka` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Druid,kfops -n demo +$ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 23m +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 23m NAME AGE -Druid.gitops.kubedb.com/Druid-prod 23m +kafka.gitops.kubedb.com/kafka-prod 23m NAME TYPE STATUS AGE -Druidopsrequest.ops.kubedb.com/Druid-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Druidopsrequest.ops.kubedb.com/Druid-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +kafkaopsrequest.ops.kubedb.com/kafka-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=Druid-prod' +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=kafka-prod' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -Druid-prod-data-Druid-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -Druid-prod-data-Druid-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -Druid-prod-data-Druid-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -Druid-prod-data-Druid-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m +kafka-prod-data-kafka-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +kafka-prod-data-kafka-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +kafka-prod-data-kafka-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +kafka-prod-data-kafka-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m ``` -## Reconfigure Druid +## Reconfigure Kafka At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/Druid/configuration/Druid-combined.md) +To know more about this configuration file, check [here](/docs/guides/kafka/configuration/kafka-combined.md) ```yaml apiVersion: v1 kind: Secret @@ -405,16 +407,16 @@ Now, we will add this file to `kubedb /kf-configuration.yaml`. $ tree . ├── kubedb │ ├── kf-configuration.yaml -│ └── Druid.yaml +│ └── Kafka.yaml 1 directories, 2 files ``` -Update the `Druid.yaml` with the following, +Update the `Kafka.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Druid +kind: Kafka metadata: - name: Druid-prod + name: kafka-prod namespace: demo spec: configSecret: @@ -425,7 +427,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -444,7 +446,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -463,21 +465,21 @@ spec: deletionPolicy: WipeOut ``` -Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. -Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` DruidOpsRequest to update the `Druid` database configuration. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` KafkaOpsRequest to update the `Kafka` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Druid,kfops -n demo +$ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 74m +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 74m NAME AGE -Druid.gitops.kubedb.com/Druid-prod 74m +kafka.gitops.kubedb.com/kafka-prod 74m NAME TYPE STATUS AGE -Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 24m -Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 24m +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m ``` @@ -485,7 +487,7 @@ Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansi > We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. -### Rotate Druid Auth +### Rotate Kafka Auth To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. @@ -494,20 +496,20 @@ We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the fo ```bash kubectl create secret generic kf-rotate-auth -n demo \ --type=kubernetes.io/basic-auth \ ---from-literal=username=Druid \ ---from-literal=password=Druid-secret +--from-literal=username=kafka \ +--from-literal=password=kafka-secret secret/kf-rotate-auth created ``` -Update the `Druid.yaml` with the following, +Update the `Kafka.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Druid +kind: Kafka metadata: - name: Druid-prod + name: kafka-prod namespace: demo spec: authSecret: @@ -521,7 +523,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -540,7 +542,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -559,22 +561,22 @@ spec: deletionPolicy: WipeOut ``` -Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. +Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. -Now, `gitops` operator will detect the auth changes and create a `RotateAuth` DruidOpsRequest to update the `Druid` database auth. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` KafkaOpsRequest to update the `Kafka` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Druid,kfops -n demo +$ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 7m11s +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 7m11s NAME AGE -Druid.gitops.kubedb.com/Druid-prod 7m11s +kafka.gitops.kubedb.com/kafka-prod 7m11s NAME TYPE STATUS AGE -Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 17h -Druidopsrequest.ops.kubedb.com/Druid-prod-rotate-auth-43ris8 RotateAuth Successful 28m -Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 17h +kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 28m +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h ``` @@ -583,7 +585,7 @@ Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansi We can add, rotate or remove TLS configuration using `gitops`. -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Druid. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Kafka. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. - Start off by generating a ca certificates using openssl. @@ -599,14 +601,14 @@ writing new private key to './ca.key' - Now we are going to create a ca-secret using the certificate files that we have just generated. ```bash -$ kubectl create secret tls Druid-ca \ +$ kubectl create secret tls kafka-ca \ --cert=ca.crt \ --key=ca.key \ --namespace=demo -secret/Druid-ca created +secret/Kafka-ca created ``` -Now, Let's create an `Issuer` using the `Druid-ca` secret that we have just created. The `YAML` file looks like this: +Now, Let's create an `Issuer` using the `Kafka-ca` secret that we have just created. The `YAML` file looks like this: ```yaml apiVersion: cert-manager.io/v1 @@ -616,7 +618,7 @@ metadata: namespace: demo spec: ca: - secretName: Druid-ca + secretName: kafka-ca ``` Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, @@ -625,16 +627,16 @@ $ tree . ├── kubedb │ ├── kf-configuration.yaml │ ├── kf-issuer.yaml -│ └── Druid.yaml +│ └── Kafka.yaml 1 directories, 4 files ``` -Update the `Druid.yaml` with the following, +Update the `Kafka.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Druid +kind: Kafka metadata: - name: Druid-prod + name: kafka-prod namespace: demo spec: version: 3.9.0 @@ -643,7 +645,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -662,7 +664,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -681,41 +683,41 @@ spec: deletionPolicy: WipeOut ``` -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` DruidOpsRequest to update the `Druid` database tls. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` KafkaOpsRequest to update the `Kafka` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Druid,kfops,pods -n demo +$ kubectl get kf,kafka,kfops,pods -n demo NAME TYPE VERSION STATUS AGE -Druid.kubedb.com/Druid-prod kubedb.com/v1 3.9.0 Ready 41m +kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 41m NAME AGE -Druid.gitops.kubedb.com/Druid-prod 75m +kafka.gitops.kubedb.com/kafka-prod 75m NAME TYPE STATUS AGE -Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 5d18h -Druidopsrequest.ops.kubedb.com/Druid-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -Druidopsrequest.ops.kubedb.com/Druid-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h -Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 5d18h +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h ``` -> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Druid. +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Kafka. ### Update Version -List Druid versions using `kubectl get Druidversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Druid/update-version/update-version.md). +List Kafka versions using `kubectl get Kafkaversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/kafka/update-version/update-version.md). Let's choose `4.0.0` in this example. -Update the `Druid.yaml` with the following, +Update the `Kafka.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Druid +kind: Kafka metadata: - name: Druid-prod + name: kafka-prod namespace: demo spec: version: 4.0.0 @@ -724,7 +726,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -743,7 +745,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -762,50 +764,50 @@ spec: deletionPolicy: WipeOut ``` -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` DruidOpsRequest to update the `Druid` database version. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` KafkaOpsRequest to update the `Kafka` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Druid,kfops -n demo +$ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -Druid.kubedb.com/Druid-prod kubedb.com/v1 4.0.0 Ready 3h47m +kafka.kubedb.com/kafka-prod kubedb.com/v1 4.0.0 Ready 3h47m NAME AGE -Druid.gitops.kubedb.com/Druid-prod 3h47m +kafka.gitops.kubedb.com/kafka-prod 3h47m NAME TYPE STATUS AGE -Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 5d22h -Druidopsrequest.ops.kubedb.com/Druid-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -Druidopsrequest.ops.kubedb.com/Druid-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h -Druidopsrequest.ops.kubedb.com/Druid-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m -Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 5d22h +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h +kafkaopsrequest.ops.kubedb.com/kafka-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h ``` -Now, we are going to verify whether the `Druid`, `PetSet` and it's `Pod` have updated with new image. Let's check, +Now, we are going to verify whether the `Kafka`, `PetSet` and it's `Pod` have updated with new image. Let's check, ```bash -$ kubectl get Druid -n demo Druid-prod -o=jsonpath='{.spec.version}{"\n"}' +$ kubectl get Kafka -n demo kafka-prod -o=jsonpath='{.spec.version}{"\n"}' 4.0.0 -$ kubectl get petset -n demo Druid-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Druid:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get petset -n demo kafka-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 -$ kubectl get pod -n demo Druid-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Druid:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get pod -n demo kafka-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 ``` ### Enable Monitoring If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). -Update the `Druid.yaml` with the following, +Update the `Kafka.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Druid +kind: Kafka metadata: - name: Druid-prod + name: kafka-prod namespace: demo spec: version: 4.0.0 @@ -814,7 +816,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -833,7 +835,7 @@ spec: podTemplate: spec: containers: - - name: Druid + - name: kafka resources: limits: memory: 1536Mi @@ -861,24 +863,24 @@ spec: deletionPolicy: WipeOut ``` -Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Druid` CR is updated in your cluster. +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. -Now, `gitops` operator will detect the monitoring changes and create a `Restart` DruidOpsRequest to add the `Druid` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the monitoring changes and create a `Restart` KafkaOpsRequest to add the `Kafka` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get Druides.gitops.kubedb.com,Druides.kubedb.com,Druidopsrequest -n demo +$ kubectl get Kafkaes.gitops.kubedb.com,Kafkaes.kubedb.com,Kafkaopsrequest -n demo NAME TYPE VERSION STATUS AGE -Druid.kubedb.com/Druid-prod kubedb.com/v1 4.0.0 Ready 5h12m +kafka.kubedb.com/kafka-prod kubedb.com/v1 4.0.0 Ready 5h12m NAME AGE -Druid.gitops.kubedb.com/Druid-prod 5h12m +kafka.gitops.kubedb.com/kafka-prod 5h12m NAME TYPE STATUS AGE -Druidopsrequest.ops.kubedb.com/Druid-prod-reconfigure-ukj41o Reconfigure Successful 6d -Druidopsrequest.ops.kubedb.com/Druid-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -Druidopsrequest.ops.kubedb.com/Druid-prod-restart-ljpqih Restart Successful 3m51s -Druidopsrequest.ops.kubedb.com/Druid-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h -Druidopsrequest.ops.kubedb.com/Druid-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m -Druidopsrequest.ops.kubedb.com/Druid-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 6d +kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +kafkaopsrequest.ops.kubedb.com/kafka-prod-restart-ljpqih Restart Successful 3m51s +kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h +kafkaopsrequest.ops.kubedb.com/kafka-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m +kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d ``` @@ -897,10 +899,10 @@ There are some other fields that will trigger `Restart` ops request. ## Next Steps -[//]: # (- Learn Druid [GitOps](/docs/guides/Druid/concepts/Druid-gitops.md)) -- Learn Druid Scaling - - [Horizontal Scaling](/docs/guides/Druid/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/Druid/scaling/vertical-scaling/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/Druid/update-version/overview.md) -- Monitor your DruidQL database with KubeDB using [built-in Prometheus](/docs/guides/Druid/monitoring/using-builtin-prometheus.md). +[//]: # (- Learn Kafka [GitOps](/docs/guides/kafka/concepts/Kafka-gitops.md)) +- Learn Kafka Scaling + - [Horizontal Scaling](/docs/guides/kafka/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/kafka/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/kafka/update-version/overview.md) +- Monitor your KafkaQL database with KubeDB using [built-in Prometheus](/docs/guides/kafka/monitoring/using-builtin-prometheus.md). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/druid/gitops/overview.md b/docs/guides/elasticsearch/gitops/overview.md similarity index 63% rename from docs/guides/druid/gitops/overview.md rename to docs/guides/elasticsearch/gitops/overview.md index 05e8c54337..cf959a479f 100644 --- a/docs/guides/druid/gitops/overview.md +++ b/docs/guides/elasticsearch/gitops/overview.md @@ -1,11 +1,11 @@ --- -title: Druid GitOps Overview -description: Druid GitOps Overview +title: Kafka Gitops Overview +description: Kafka Gitops Overview menu: docs_{{ .version }}: identifier: kf-gitops-overview name: Overview - parent: kf-gitops-Druid + parent: kf-gitops weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides @@ -13,20 +13,20 @@ section_menu_id: guides > New to KubeDB? Please start [here](/docs/README.md). -# GitOps Overview for Druid +# GitOps Overview for Kafka -This guide will give you an overview of how KubeDB `gitops` operator works with Druid databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for -managing Druid databases in Kubernetes. +This guide will give you an overview of how KubeDB `gitops` operator works with Kafka databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Kafka databases in Kubernetes. ## Before You Begin - You should be familiar with the following `KubeDB` concepts: - - [Druid](/docs/guides/druid/concepts/druid.md) - - [DruidOpsRequest](/docs/guides/druid/concepts/druidopsrequest.md) + - [Kafka](/docs/guides/kafka/concepts/kafka.md) + - [KafkaOpsRequest](/docs/guides/kafka/concepts/kafkaopsrequest.md) -## Workflow GitOps with Druid +## Workflow GitOps with Kafka The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. @@ -35,16 +35,16 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y GitOps Flow -
Fig: GitOps process of Druid
+
Fig: GitOps process of Kafka
-1. **Define GitOps Druid**: Create Custom Resource (CR) of kind `Druid` using the `gitops.kubedb.com/v1alpha1` API. +1. **Define GitOps Kafka**: Create Custom Resource (CR) of kind `Kafka` using the `gitops.kubedb.com/v1alpha1` API. 2. **Store in Git**: Push the CR to a Git repository. 3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. -4. **Create Database**: The GitOps operator creates a corresponding KubeDB Druid CR in the Kubernetes cluster to deploy the database. -5. **Handle Updates**: When you update the DruidGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Kafka CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the KafkaGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. -This flow makes managing Druid databases efficient, reliable, and fully integrated with GitOps practices. +This flow makes managing Kafka databases efficient, reliable, and fully integrated with GitOps practices. -In the next doc, we are going to show a step by step guide on running Druid using GitOps. +In the next doc, we are going to show a step by step guide on running Kafka using GitOps. From 0de03267dfaa2aa4f940a6a04440e9ca6b0bb9d5 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 27 Jan 2026 17:16:47 +0600 Subject: [PATCH 07/51] elasticsearch without tls Signed-off-by: Bonusree --- docs/guides/elasticsearch/gitops/_index.md | 2 +- docs/guides/elasticsearch/gitops/gitops.md | 957 ++++++++----------- docs/guides/elasticsearch/gitops/overview.md | 32 +- docs/guides/kafka/gitops/gitops.md | 6 +- docs/guides/mariadb/gitops/_index.md | 10 + docs/guides/mariadb/gitops/gitops.md | 910 ++++++++++++++++++ docs/guides/mariadb/gitops/overview.md | 50 + docs/guides/mongodb/gitops/_index.md | 10 + docs/guides/mongodb/gitops/gitops.md | 900 +++++++++++++++++ docs/guides/mongodb/gitops/overview.md | 50 + docs/guides/mssqlserver/gitops/_index.md | 10 + docs/guides/mssqlserver/gitops/gitops.md | 900 +++++++++++++++++ docs/guides/mssqlserver/gitops/overview.md | 50 + 13 files changed, 3317 insertions(+), 570 deletions(-) create mode 100644 docs/guides/mariadb/gitops/_index.md create mode 100644 docs/guides/mariadb/gitops/gitops.md create mode 100644 docs/guides/mariadb/gitops/overview.md create mode 100644 docs/guides/mongodb/gitops/_index.md create mode 100644 docs/guides/mongodb/gitops/gitops.md create mode 100644 docs/guides/mongodb/gitops/overview.md create mode 100644 docs/guides/mssqlserver/gitops/_index.md create mode 100644 docs/guides/mssqlserver/gitops/gitops.md create mode 100644 docs/guides/mssqlserver/gitops/overview.md diff --git a/docs/guides/elasticsearch/gitops/_index.md b/docs/guides/elasticsearch/gitops/_index.md index a13bc58303..cc82b5f6bc 100644 --- a/docs/guides/elasticsearch/gitops/_index.md +++ b/docs/guides/elasticsearch/gitops/_index.md @@ -5,6 +5,6 @@ menu: identifier: es-gitops name: Elasticsearch Gitops parent: es-elasticsearch-guides - weight: 65 + weight: 70 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/elasticsearch/gitops/gitops.md b/docs/guides/elasticsearch/gitops/gitops.md index e5b5b2d964..e3a2e57d22 100644 --- a/docs/guides/elasticsearch/gitops/gitops.md +++ b/docs/guides/elasticsearch/gitops/gitops.md @@ -1,29 +1,34 @@ --- -title: Kafka GitOps Guides +title: Elasticsearch Gitops Overview +description: Elasticsearch Gitops Overview menu: docs_{{ .version }}: - identifier: kf-gitops-guides - name: Gitops Kafka - parent: kf-gitops-kafka - weight: 20 + identifier: es-gitops-overview + name: Overview + parent: es-gitops + weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides --- + > New to KubeDB? Please start [here](/docs/README.md). -# GitOps Kafka using KubeDB GitOps Operator +# GitOps Elasticsearch using KubeDB GitOps Operator -This guide will show you how to use `KubeDB` GitOps operator to create Kafka database and manage updates using GitOps workflow. +This guide will show you how to use `KubeDB` GitOps operator to create Elasticsearch database and manage updates using GitOps woreslow. ## Before You Begin -- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, +you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). -- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation +process to enable `GitOps` operator. -- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes +cluster with the desired state defined in Git. ```bash $ kubectl create ns monitoring @@ -32,7 +37,7 @@ This guide will show you how to use `KubeDB` GitOps operator to create Kafka dat $ kubectl create ns demo namespace/demo created ``` -> Note: YAML files used in this tutorial are stored in [docs/examples/kafka](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/kafka) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). +> Note: YAML files used in this tutorial are stored in [docs/examples/elasticsearch](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/elasticsearch) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). @@ -54,37 +59,27 @@ argocd app create kubedb --repo --path kubedb --dest-server https://k argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa ``` -## Create Kafka Database using GitOps +## Create Elasticsearch Database using GitOps -### Create a Kafka GitOps CR +### Create a Elasticsearch GitOps CR ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Kafka +kind: Elasticsearch metadata: - name: kafka-prod + name: es-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: Standard - controller: - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: Standard + version: xpack-8.2.3 + enableSSL: true + replicas: 2 storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi deletionPolicy: WipeOut ``` @@ -92,492 +87,383 @@ Create a directory like below, ```bash $ tree . ├── kubedb - └── Kafka.yaml + └── Elasticsearch.yaml 1 directories, 1 files ``` -Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is created in your cluster. +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is created in your cluster. -Our `gitops` operator will create an actual `Kafka` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. +Our `gitops` operator will create an actual `Elasticsearch` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kafka.gitops.kubedb.com,kafka.kubedb.com -n demo -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 2m56s +$ kubectl get Elasticsearch.gitops.kubedb.com,Elasticsearch.kubedb.com -n demo +NAME AGE +elasticsearch.gitops.kubedb.com/es-gitops 20m -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 2m56s +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 20m ``` -List the resources created by `kubedb` operator created for `kubedb.com/v1` Kafka. +List the resources created by `kubedb` operator created for `kubedb.com/v1` Elasticsearch. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=kafka-prod' -NAME AGE -petset.apps.k8s.appscode.com/kafka-prod-broker 4m49s -petset.apps.k8s.appscode.com/kafka-prod-controller 4m47s +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=es-gitops' +NAME AGE +petset.apps.k8s.appscode.com/es-gitops 20m + +NAME READY STATUS RESTARTS AGE +pod/es-gitops-0 1/1 Running 0 20m +pod/es-gitops-1 1/1 Running 0 19m + +NAME TYPE DATA AGE +secret/es-gitops-a1d7d4 Opaque 1 13m +secret/es-gitops-apm-system-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-auth kubernetes.io/basic-auth 2 20m +secret/es-gitops-beats-system-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-ca-cert kubernetes.io/tls 2 20m +secret/es-gitops-client-cert kubernetes.io/tls 3 20m +secret/es-gitops-config Opaque 1 20m +secret/es-gitops-http-cert kubernetes.io/tls 3 20m +secret/es-gitops-kibana-system-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-logstash-system-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-remote-monitoring-user-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-transport-cert kubernetes.io/tls 3 20m + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/es-gitops ClusterIP 10.43.235.79 9200/TCP 20m +service/es-gitops-master ClusterIP None 9300/TCP 20m +service/es-gitops-pods ClusterIP None 9200/TCP 20m + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/es-gitops kubedb.com/elasticsearch 8.2.3 20m +``` + +## Update Elasticsearch Database using GitOps +### Scale Elasticsearch Replicas +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.2.3 + enableSSL: true + replicas: 3 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` -NAME READY STATUS RESTARTS AGE -pod/kafka-prod-broker-0 1/1 Running 0 4m48s -pod/kafka-prod-broker-1 1/1 Running 0 4m42s -pod/kafka-prod-controller-0 1/1 Running 0 4m47s -pod/kafka-prod-controller-1 1/1 Running 0 4m40s +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Elasticsearch` database replicas. List the +resources created by `gitops` operator in the `demo` namespace. -NAME TYPE DATA AGE -secret/kafka-prod-auth kubernetes.io/basic-auth 2 4m51s +```bash +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 64m -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/kafka-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-32p116 HorizontalScaling Successful 39m +``` -NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/kafka-prod kubedb.com/kafka 3.9.0 4m47s +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=es-gitops' +NAME READY STATUS RESTARTS AGE +es-gitops-0 1/1 Running 0 36m +es-gitops-1 1/1 Running 0 16m +es-gitops-2 1/1 Running 0 15m ``` -## Update Kafka Database using GitOps -### Scale Kafka Database Resources +We can also scale down the replicas by updating the `replicas` fields. +### Scale Elasticsearch Database Resources -Update the `Kafka.yaml` with the following, +Update the `Elasticsearch.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Kafka +kind: Elasticsearch metadata: - name: kafka-prod + name: es-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path - controller: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path + version: xpack-8.2.3 + enableSSL: true + replicas: 3 + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 500m + memory: 1Gi + requests: + cpu: 100m + memory: 1Gi storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi deletionPolicy: WipeOut ``` -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Resource Requests and Limits are updated to `500m` CPU and `1Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the resource changes and create a `KafkaOpsRequest` to update the `Kafka` database. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Elasticsearch` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ $ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 22h +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 64m -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 22h +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-injx1l HorizontalScaling Successful 15m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-x5mfy0 VerticalScaling Successful 39m -NAME TYPE STATUS AGE -Kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo Kafka-prod-broker-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo es-gitops-0 -o json | jq '.spec.containers[0].resources' { "limits": { - "memory": "1536Mi" + "cpu": "500m", + "memory": "1Gi" }, "requests": { - "cpu": "500m", - "memory": "1536Mi" + "cpu": "100m", + "memory": "1Gi" } } -``` -### Scale Kafka Replicas -Update the `Kafka.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Kafka -metadata: - name: kafka-prod - namespace: demo -spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 3 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path - controller: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 3 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path - storageType: Durable - deletionPolicy: WipeOut ``` -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` KafkaOpsRequest to update the `Kafka` database replicas. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 22h -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 22h +### Expand Elasticsearch Volume -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -``` - -After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, -```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=kafka-prod' -NAME READY STATUS RESTARTS AGE -kafka-prod-broker-0 1/1 Running 0 34m -kafka-prod-broker-1 1/1 Running 0 33m -kafka-prod-broker-2 1/1 Running 0 33m -kafka-prod-controller-0 1/1 Running 0 32m -kafka-prod-controller-1 1/1 Running 0 31m -kafka-prod-controller-2 1/1 Running 0 31m -``` - -We can also scale down the replicas by updating the `replicas` fields. - -### Expand Kafka Volume - -Update the `Kafka.yaml` with the following, +Update the `Elasticsearch.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Kafka +kind: Elasticsearch metadata: - name: kafka-prod + name: es-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + version: xpack-8.2.3 + enableSSL: true + replicas: 3 + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 500m + memory: 1Gi + requests: + cpu: 100m + memory: 1Gi storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut ``` -Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` KafkaOpsRequest to update the `Kafka` database volume. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `Elasticsearch` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 23m +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 3h1m -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 23m +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-32p116 HorizontalScaling Successful 157m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-x5mfy0 VerticalScaling Successful 157m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-sata37 VolumeExpansion Successful 38m -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=kafka-prod' -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -kafka-prod-data-kafka-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -kafka-prod-data-kafka-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -kafka-prod-data-kafka-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -kafka-prod-data-kafka-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m - +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=es-gitops' +NAME READY STATUS RESTARTS AGE +es-gitops-0 1/1 Running 0 36m +es-gitops-1 1/1 Running 0 16m +es-gitops-2 1/1 Running 0 15m ``` -## Reconfigure Kafka +## Reconfigure Elasticsearch At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/kafka/configuration/kafka-combined.md) +To know more about this configuration file, check [here](/docs/guides/elasticsearch/configuration/combined-cluster/index.md) ```yaml apiVersion: v1 +stringData: + user.conf: | + max_connections=200 + shared_buffers=256MB kind: Secret metadata: - name: new-kf-combined-custom-config + name: es-configuration namespace: demo -stringData: - server.properties: |- - log.retention.hours=125 +type: Opaque ``` -Now, we will add this file to `kubedb /kf-configuration.yaml`. +Now, we will add this file to `kubedb /es-configuration.yaml`. ```bash $ tree . ├── kubedb -│ ├── kf-configuration.yaml -│ └── Kafka.yaml +│ ├── es-configuration.yaml +│ └── Elasticsearch.yaml 1 directories, 2 files ``` -Update the `Kafka.yaml` with the following, +Update the `Elasticsearch.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Kafka +kind: Elasticsearch metadata: - name: kafka-prod + name: es-gitops namespace: demo spec: - configSecret: - name: new-kf-combined-custom-config - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + version: xpack-8.2.3 + enableSSL: true + replicas: 3 + configuration: + secretName: es-configuration + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 500m + memory: 1Gi + requests: + cpu: 100m + memory: 1Gi storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut ``` -Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` KafkaOpsRequest to update the `Kafka` database configuration. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `Elasticsearch` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 74m - -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 74m - -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 24m -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 3h53m +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-32p116 HorizontalScaling Successful 3h29m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-wj5qyx Reconfigure Successful 3m42s +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-lvh38k VerticalScaling Successful 99m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-sata37 VolumeExpansion Successful 90m ``` -> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. - -### Rotate Kafka Auth +### Rotate Elasticsearch Auth To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. -We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, +We will generate a secret named `es-rotate-auth` with the following content, ```bash -kubectl create secret generic kf-rotate-auth -n demo \ ---type=kubernetes.io/basic-auth \ ---from-literal=username=kafka \ ---from-literal=password=kafka-secret -secret/kf-rotate-auth created +$ kubectl create secret generic es-rotate-auth -n demo \ + --type=kubernetes.io/basic-auth \ + --from-literal=username=elastic \ + --from-literal=password=elasticsearch-secret +secret/es-rotate-auth created ``` -Update the `Kafka.yaml` with the following, +Update the `Elasticsearch.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Kafka +kind: Elasticsearch metadata: - name: kafka-prod + name: es-gitops namespace: demo spec: + version: xpack-8.2.3 + enableSSL: true + replicas: 3 authSecret: kind: Secret - name: kf-rotate-auth - configSecret: - name: new-kf-combined-custom-config - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + name: es-rotate-auth + configuration: + secretName: es-configuration + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 500m + memory: 1Gi + requests: + cpu: 100m + memory: 1Gi storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut ``` -Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Change the `authSecret` field to `es-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the auth changes and create a `RotateAuth` KafkaOpsRequest to update the `Kafka` database auth. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `Elasticsearch` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 7m11s - -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 7m11s - -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 17h -kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 28m -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-9.1.9 Ready 18m +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-wiezxp HorizontalScaling Successful 13m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-i9puam Reconfigure Successful 13m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-xisot8 RotateAuth Successful 4m38s +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-7dyz6e VerticalScaling Successful 13m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-pptef3 VolumeExpansion Successful 13m ``` @@ -585,7 +471,7 @@ kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansi We can add, rotate or remove TLS configuration using `gitops`. -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Kafka. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Elasticsearch. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. - Start off by generating a ca certificates using openssl. @@ -601,42 +487,42 @@ writing new private key to './ca.key' - Now we are going to create a ca-secret using the certificate files that we have just generated. ```bash -$ kubectl create secret tls kafka-ca \ +$ kubectl create secret tls Elasticsearch-ca \ --cert=ca.crt \ --key=ca.key \ --namespace=demo -secret/Kafka-ca created +secret/Elasticsearch-ca created ``` -Now, Let's create an `Issuer` using the `Kafka-ca` secret that we have just created. The `YAML` file looks like this: +Now, Let's create an `Issuer` using the `Elasticsearch-ca` secret that we have just created. The `YAML` file looks like this: ```yaml apiVersion: cert-manager.io/v1 kind: Issuer metadata: - name: kf-issuer + name: es-issuer namespace: demo spec: ca: - secretName: kafka-ca + secretName: Elasticsearch-ca ``` -Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, +Let's add that to our `kubedb /es-issuer.yaml` file. File structure will look like this, ```bash $ tree . ├── kubedb -│ ├── kf-configuration.yaml -│ ├── kf-issuer.yaml -│ └── Kafka.yaml +│ ├── es-configuration.yaml +│ ├── es-issuer.yaml +│ └── Elasticsearch.yaml 1 directories, 4 files ``` -Update the `Kafka.yaml` with the following, +Update the `Elasticsearch.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Kafka +kind: Elasticsearch metadata: - name: kafka-prod + name: es-gitops namespace: demo spec: version: 3.9.0 @@ -645,7 +531,7 @@ spec: podTemplate: spec: containers: - - name: kafka + - name: Elasticsearch resources: limits: memory: 1536Mi @@ -664,7 +550,7 @@ spec: podTemplate: spec: containers: - - name: kafka + - name: Elasticsearch resources: limits: memory: 1536Mi @@ -683,204 +569,175 @@ spec: deletionPolicy: WipeOut ``` -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` KafkaOpsRequest to update the `Kafka` database tls. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Elasticsearch` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,kafka,kfops,pods -n demo +$ kubectl get es,Elasticsearch,esops,pods -n demo NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 41m +Elasticsearch.kubedb.com/es-gitops kubedb.com/v1 3.9.0 Ready 41m NAME AGE -kafka.gitops.kubedb.com/kafka-prod 75m +Elasticsearch.gitops.kubedb.com/es-gitops 75m NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 5d18h -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +Elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h +Elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +Elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h +Elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h ``` -> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Kafka. +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Elasticsearch. ### Update Version -List Kafka versions using `kubectl get Kafkaversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/kafka/update-version/update-version.md). +List Elasticsearch versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/elasticsearch/update-version/update-version.md). Let's choose `4.0.0` in this example. -Update the `Kafka.yaml` with the following, +Update the `Elasticsearch.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Kafka +kind: Elasticsearch metadata: - name: kafka-prod + name: es-gitops namespace: demo spec: - version: 4.0.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + version: xpack-9.2.3 + replicas: 3 + authSecret: + kind: Secret + name: es-rotate-auth + configuration: + secretName: es-configuration + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 500m + memory: 1Gi + requests: + cpu: 100m + memory: 1Gi storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut ``` -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` KafkaOpsRequest to update the `Kafka` database version. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Elasticsearch` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 4.0.0 Ready 3h47m +$ kubectl get es,Elasticsearch,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-9.2.3 Ready 64m -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 3h47m +NAME AGE +elasticsearch.gitops.kubedb.com/es-gitops 64m + +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-os8fon HorizontalScaling Successful 58m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-hrbrs1 Reconfigure Successful 58m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-s0tkka RotateAuth Successful 58m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-versionupdate-bn3rk4 UpdateVersion Successful 31m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-vhzkxl VerticalScaling Successful 58m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-bzqd4r VolumeExpansion Successful 58m -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 5d22h -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h -kafkaopsrequest.ops.kubedb.com/kafka-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h ``` -Now, we are going to verify whether the `Kafka`, `PetSet` and it's `Pod` have updated with new image. Let's check, +Now, we are going to verify whether the `Elasticsearch`, `PetSet` and it's `Pod` have updated with new image. Let's check, ```bash -$ kubectl get Kafka -n demo kafka-prod -o=jsonpath='{.spec.version}{"\n"}' -4.0.0 +$ kubectl get Elasticsearch -n demo es-gitops -o=jsonpath='{.spec.version}{"\n"}' +xpack-9.2.3 -$ kubectl get petset -n demo kafka-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get petset -n demo es-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/elastic:9.2.3@sha256:714f35c53d333fef7e673079d05ce80440caf2c20ca3dc9b3e366728527760bb -$ kubectl get pod -n demo kafka-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get pod -n demo es-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/elastic:9.2.3@sha256:714f35c53d333fef7e673079d05ce80440caf2c20ca3dc9b3e366728527760bb ``` ### Enable Monitoring If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). -Update the `Kafka.yaml` with the following, +Update the `Elasticsearch.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Kafka +kind: Elasticsearch metadata: - name: kafka-prod + name: es-gitops namespace: demo spec: - version: 4.0.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: kafka - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + version: xpack-9.2.3 + replicas: 3 + authSecret: + kind: Secret + name: es-rotate-auth + configuration: + secretName: es-configuration + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 500m + memory: 1Gi + requests: + cpu: 100m + memory: 1Gi storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut monitor: agent: prometheus.io/operator prometheus: - exporter: - port: 9091 serviceMonitor: labels: release: prometheus interval: 10s - deletionPolicy: WipeOut ``` -Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the monitoring changes and create a `Restart` KafkaOpsRequest to add the `Kafka` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Elasticsearch` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get Kafkaes.gitops.kubedb.com,Kafkaes.kubedb.com,Kafkaopsrequest -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 4.0.0 Ready 5h12m +$ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo +NAME AGE +elasticsearch.gitops.kubedb.com/es-gitops 106m -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 5h12m +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-9.2.3 Ready 106m -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 6d -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -kafkaopsrequest.ops.kubedb.com/kafka-prod-restart-ljpqih Restart Successful 3m51s -kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h -kafkaopsrequest.ops.kubedb.com/kafka-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-os8fon HorizontalScaling Successful 101m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-hrbrs1 Reconfigure Successful 101m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-restart-7v0e29 Restart Successful 15m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-s0tkka RotateAuth Successful 101m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-versionupdate-bn3rk4 UpdateVersion Successful 73m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-vhzkxl VerticalScaling Successful 101m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-bzqd4r VolumeExpansion Successful 101m ``` @@ -899,10 +756,10 @@ There are some other fields that will trigger `Restart` ops request. ## Next Steps -[//]: # (- Learn Kafka [GitOps](/docs/guides/kafka/concepts/Kafka-gitops.md)) -- Learn Kafka Scaling - - [Horizontal Scaling](/docs/guides/kafka/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/kafka/scaling/vertical-scaling/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/kafka/update-version/overview.md) -- Monitor your KafkaQL database with KubeDB using [built-in Prometheus](/docs/guides/kafka/monitoring/using-builtin-prometheus.md). -- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). +[//]: # (- Learn Elasticsearch [GitOps](/docs/guides/elasticsearch/concepts/Elasticsearch-gitops.md)) +- Learn Elasticsearch Scaling + - [Horizontal Scaling](/docs/guides/elasticsearch/scaling/horizontal/combined.md) + - [Vertical Scaling](/docs/guides/elasticsearch/scaling/vertical/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/elasticsearch/update-version/overview.md) +- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/elasticsearch/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md) \ No newline at end of file diff --git a/docs/guides/elasticsearch/gitops/overview.md b/docs/guides/elasticsearch/gitops/overview.md index cf959a479f..bfa01c2fff 100644 --- a/docs/guides/elasticsearch/gitops/overview.md +++ b/docs/guides/elasticsearch/gitops/overview.md @@ -1,11 +1,11 @@ --- -title: Kafka Gitops Overview -description: Kafka Gitops Overview +title: Elasticsearch Gitops Overview +description: Elasticsearch Gitops Overview menu: docs_{{ .version }}: - identifier: kf-gitops-overview + identifier: es-gitops-overview name: Overview - parent: kf-gitops + parent: es-gitops weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides @@ -13,20 +13,20 @@ section_menu_id: guides > New to KubeDB? Please start [here](/docs/README.md). -# GitOps Overview for Kafka +# GitOps Overview for Elasticsearch -This guide will give you an overview of how KubeDB `gitops` operator works with Kafka databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for -managing Kafka databases in Kubernetes. +This guide will give you an overview of how KubeDB `gitops` operator works with Elasticsearch databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Elasticsearch databases in Kubernetes. ## Before You Begin - You should be familiar with the following `KubeDB` concepts: - - [Kafka](/docs/guides/kafka/concepts/kafka.md) - - [KafkaOpsRequest](/docs/guides/kafka/concepts/kafkaopsrequest.md) + - [Elasticsearch](/docs/guides/elasticsearch/concepts/elasticsearch/index.md) + - [ElasticsearchOpsRequest](/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md) -## Workflow GitOps with Kafka +## Workflow GitOps with Elasticsearch The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. @@ -35,16 +35,16 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y GitOps Flow -
Fig: GitOps process of Kafka
+
Fig: GitOps process of Elasticsearch
-1. **Define GitOps Kafka**: Create Custom Resource (CR) of kind `Kafka` using the `gitops.kubedb.com/v1alpha1` API. +1. **Define GitOps Elasticsearch**: Create Custom Resource (CR) of kind `Elasticsearch` using the `gitops.kubedb.com/v1alpha1` API. 2. **Store in Git**: Push the CR to a Git repository. 3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. -4. **Create Database**: The GitOps operator creates a corresponding KubeDB Kafka CR in the Kubernetes cluster to deploy the database. -5. **Handle Updates**: When you update the KafkaGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Elasticsearch CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. -This flow makes managing Kafka databases efficient, reliable, and fully integrated with GitOps practices. +This flow makes managing Elasticsearch databases efficient, reliable, and fully integrated with GitOps practices. -In the next doc, we are going to show a step by step guide on running Kafka using GitOps. +In the next doc, we are going to show a step by step guide on running Elasticsearch using GitOps. diff --git a/docs/guides/kafka/gitops/gitops.md b/docs/guides/kafka/gitops/gitops.md index e5b5b2d964..881efb1dd7 100644 --- a/docs/guides/kafka/gitops/gitops.md +++ b/docs/guides/kafka/gitops/gitops.md @@ -491,7 +491,7 @@ kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansi To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. -We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, +We will create a secret named `kf-rotate-auth ` with the following content, ```bash kubectl create secret generic kf-rotate-auth -n demo \ @@ -515,8 +515,8 @@ spec: authSecret: kind: Secret name: kf-rotate-auth - configSecret: - name: new-kf-combined-custom-config + configuration: + secretName: new-kf-combined-custom-config version: 3.9.0 topology: broker: diff --git a/docs/guides/mariadb/gitops/_index.md b/docs/guides/mariadb/gitops/_index.md new file mode 100644 index 0000000000..cc82b5f6bc --- /dev/null +++ b/docs/guides/mariadb/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: Elasticsearch Gitops +menu: + docs_{{ .version }}: + identifier: es-gitops + name: Elasticsearch Gitops + parent: es-elasticsearch-guides + weight: 70 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md new file mode 100644 index 0000000000..ec2fdd8f51 --- /dev/null +++ b/docs/guides/mariadb/gitops/gitops.md @@ -0,0 +1,910 @@ +--- +title: MariaDB Gitops Overview +description: MariaDB Gitops Overview +menu: + docs_{{ .version }}: + identifier: es-gitops-overview + name: Overview + parent: es-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + + + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps MariaDB using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create MariaDB database and manage updates using GitOps workflow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/MariaDB](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/MariaDB) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create MariaDB Database using GitOps + +### Create a MariaDB GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: mariadb-gitops + namespace: demo +spec: + version: "10.5.23" + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── MariaDB.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is created in your cluster. + +Our `gitops` operator will create an actual `MariaDB` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get MariaDB.gitops.kubedb.com,MariaDB.kubedb.com -n demo +NAME AGE +mariadb.gitops.kubedb.com/mariadb-gitops 2m + +NAME VERSION STATUS AGE +mariadb.kubedb.com/mariadb-gitops 10.5.23 Ready 2m + +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` MariaDB. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=mariadb-gitops' +NAME AGE +petset.apps.k8s.appscode.com/mariadb-gitops 2m45s + +NAME READY STATUS RESTARTS AGE +pod/mariadb-gitops-0 1/1 Running 0 2m45s + +NAME TYPE DATA AGE +secret/mariadb-gitops-auth kubernetes.io/basic-auth 2 2m47s + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/mariadb-gitops ClusterIP 10.43.132.16 3306/TCP 2m47s +service/mariadb-gitops-pods ClusterIP None 3306/TCP 2m47s + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/mariadb-gitops kubedb.com/mariadb 10.5.23 2m45s + +``` + +## Update MariaDB Database using GitOps + +### Scale MariaDB Database Resources + +```shell +$ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[].resources' +{ + "limits": { + "memory": "1Gi" + }, + "requests": { + "cpu": "500m", + "memory": "1Gi" + } +} + +``` +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: MariaDB-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut + ``` + +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `MariaDBOpsRequest` to update the `MariaDB` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ $ kubectl get kf,MariaDB,kfops -n demo +NAME TYPE VERSION STATUS AGE +MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +MariaDB.gitops.kubedb.com/MariaDB-prod 22h + +NAME TYPE STATUS AGE +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo MariaDB-prod-broker-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +``` + +### Scale MariaDB Replicas +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: MariaDB-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` MariaDBOpsRequest to update the `MariaDB` database replicas. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,MariaDB,kfops -n demo +NAME TYPE VERSION STATUS AGE +MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +MariaDB.gitops.kubedb.com/MariaDB-prod 22h + +NAME TYPE STATUS AGE +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=MariaDB-prod' +NAME READY STATUS RESTARTS AGE +MariaDB-prod-broker-0 1/1 Running 0 34m +MariaDB-prod-broker-1 1/1 Running 0 33m +MariaDB-prod-broker-2 1/1 Running 0 33m +MariaDB-prod-controller-0 1/1 Running 0 32m +MariaDB-prod-controller-1 1/1 Running 0 31m +MariaDB-prod-controller-2 1/1 Running 0 31m +``` + +We can also scale down the replicas by updating the `replicas` fields. + +### Expand MariaDB Volume + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: MariaDB-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` MariaDBOpsRequest to update the `MariaDB` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,MariaDB,kfops -n demo +NAME TYPE VERSION STATUS AGE +MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 23m + +NAME AGE +MariaDB.gitops.kubedb.com/MariaDB-prod 23m + +NAME TYPE STATUS AGE +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=MariaDB-prod' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +MariaDB-prod-data-MariaDB-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +MariaDB-prod-data-MariaDB-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +MariaDB-prod-data-MariaDB-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +MariaDB-prod-data-MariaDB-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m + +``` + +## Reconfigure MariaDB + +At first, we will create a secret containing `user.conf` file with required configuration settings. +To know more about this configuration file, check [here](/docs/guides/MariaDB/configuration/MariaDB-combined.md) +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: new-kf-combined-custom-config + namespace: demo +stringData: + server.properties: |- + log.retention.hours=125 +``` + +Now, we will add this file to `kubedb /kf-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ └── MariaDB.yaml +1 directories, 2 files +``` + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: MariaDB-prod + namespace: demo +spec: + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` MariaDBOpsRequest to update the `MariaDB` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,MariaDB,kfops -n demo +NAME TYPE VERSION STATUS AGE +MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 74m + +NAME AGE +MariaDB.gitops.kubedb.com/MariaDB-prod 74m + +NAME TYPE STATUS AGE +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 24m +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m + +``` + + + +> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. + +### Rotate MariaDB Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, + +```bash +kubectl create secret generic kf-rotate-auth -n demo \ +--type=kubernetes.io/basic-auth \ +--from-literal=username=MariaDB \ +--from-literal=password=MariaDB-secret +secret/kf-rotate-auth created + +``` + + + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: MariaDB-prod + namespace: demo +spec: + authSecret: + kind: Secret + name: kf-rotate-auth + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MariaDBOpsRequest to update the `MariaDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,MariaDB,kfops -n demo +NAME TYPE VERSION STATUS AGE +MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 7m11s + +NAME AGE +MariaDB.gitops.kubedb.com/MariaDB-prod 7m11s + +NAME TYPE STATUS AGE +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 17h +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-rotate-auth-43ris8 RotateAuth Successful 28m +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h + +``` + + +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in MariaDB. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating a ca certificates using openssl. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +Generating a RSA private key +................+++++ +........................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls MariaDB-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/MariaDB-ca created +``` + +Now, Let's create an `Issuer` using the `MariaDB-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: kf-issuer + namespace: demo +spec: + ca: + secretName: MariaDB-ca +``` + +Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ ├── kf-issuer.yaml +│ └── MariaDB.yaml +1 directories, 4 files +``` + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: MariaDB-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` MariaDBOpsRequest to update the `MariaDB` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,MariaDB,kfops,pods -n demo +NAME TYPE VERSION STATUS AGE +MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 41m + +NAME AGE +MariaDB.gitops.kubedb.com/MariaDB-prod 75m + +NAME TYPE STATUS AGE +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 5d18h +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h + +``` + + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for MariaDB. + +### Update Version + +List MariaDB versions using `kubectl get MariaDBversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/MariaDB/update-version/update-version.md). + +Let's choose `4.0.0` in this example. + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: MariaDB-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` MariaDBOpsRequest to update the `MariaDB` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,MariaDB,kfops -n demo +NAME TYPE VERSION STATUS AGE +MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 4.0.0 Ready 3h47m + +NAME AGE +MariaDB.gitops.kubedb.com/MariaDB-prod 3h47m + +NAME TYPE STATUS AGE +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 5d22h +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +``` + + +Now, we are going to verify whether the `MariaDB`, `PetSet` and it's `Pod` have updated with new image. Let's check, + +```bash +$ kubectl get MariaDB -n demo MariaDB-prod -o=jsonpath='{.spec.version}{"\n"}' +4.0.0 + +$ kubectl get petset -n demo MariaDB-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/MariaDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 + +$ kubectl get pod -n demo MariaDB-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/MariaDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +``` + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: MariaDB-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: MariaDB + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9091 + serviceMonitor: + labels: + release: prometheus + interval: 10s + deletionPolicy: WipeOut +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` MariaDBOpsRequest to add the `MariaDB` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get MariaDBes.gitops.kubedb.com,MariaDBes.kubedb.com,MariaDBopsrequest -n demo +NAME TYPE VERSION STATUS AGE +MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 4.0.0 Ready 5h12m + +NAME AGE +MariaDB.gitops.kubedb.com/MariaDB-prod 5h12m + +NAME TYPE STATUS AGE +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 6d +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-restart-ljpqih Restart Successful 3m51s +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m +MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d + +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + +## Next Steps + +[//]: # (- Learn MariaDB [GitOps](/docs/guides/MariaDB/concepts/MariaDB-gitops.md)) +- Learn MariaDB Scaling + - [Horizontal Scaling](/docs/guides/MariaDB/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/MariaDB/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/MariaDB/update-version/overview.md) +- Monitor your MariaDBQL database with KubeDB using [built-in Prometheus](/docs/guides/MariaDB/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mariadb/gitops/overview.md b/docs/guides/mariadb/gitops/overview.md new file mode 100644 index 0000000000..80ab6a2fc9 --- /dev/null +++ b/docs/guides/mariadb/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: MariaDB Gitops Overview +description: MariaDB Gitops Overview +menu: + docs_{{ .version }}: + identifier: es-gitops-overview + name: Overview + parent: es-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for MariaDB + +This guide will give you an overview of how KubeDB `gitops` operator works with MariaDB databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing MariaDB databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MariaDB](/docs/guides/mariadb/concepts/mariadb/index.md) + - [MariaDBOpsRequest](/docs/guides/mariadb/concepts/opsrequest/index.md) + + + +## Workflow GitOps with MariaDB + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + + +
+ + GitOps Flow + +
Fig: GitOps process of MariaDB
+ +
+ +1. **Define GitOps MariaDB**: Create Custom Resource (CR) of kind `MariaDB` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB MariaDB CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the MariaDBGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing MariaDB databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running MariaDB using GitOps. diff --git a/docs/guides/mongodb/gitops/_index.md b/docs/guides/mongodb/gitops/_index.md new file mode 100644 index 0000000000..cc82b5f6bc --- /dev/null +++ b/docs/guides/mongodb/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: Elasticsearch Gitops +menu: + docs_{{ .version }}: + identifier: es-gitops + name: Elasticsearch Gitops + parent: es-elasticsearch-guides + weight: 70 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/mongodb/gitops/gitops.md b/docs/guides/mongodb/gitops/gitops.md new file mode 100644 index 0000000000..332c4f29d9 --- /dev/null +++ b/docs/guides/mongodb/gitops/gitops.md @@ -0,0 +1,900 @@ +--- +title: Elasticsearch Gitops Overview +description: Elasticsearch Gitops Overview +menu: + docs_{{ .version }}: + identifier: es-gitops-overview + name: Overview + parent: es-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + + + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Elasticsearch using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create Elasticsearch database and manage updates using GitOps workflow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/Elasticsearch](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/Elasticsearch) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create Elasticsearch Database using GitOps + +### Create a Elasticsearch GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.2.3 + enableSSL: true + replicas: 2 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── Elasticsearch.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is created in your cluster. + +Our `gitops` operator will create an actual `Elasticsearch` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get Elasticsearch.gitops.kubedb.com,Elasticsearch.kubedb.com -n demo +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 2m56s + +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 2m56s +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` Elasticsearch. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +NAME AGE +petset.apps.k8s.appscode.com/Elasticsearch-prod-broker 4m49s +petset.apps.k8s.appscode.com/Elasticsearch-prod-controller 4m47s + +NAME READY STATUS RESTARTS AGE +pod/Elasticsearch-prod-broker-0 1/1 Running 0 4m48s +pod/Elasticsearch-prod-broker-1 1/1 Running 0 4m42s +pod/Elasticsearch-prod-controller-0 1/1 Running 0 4m47s +pod/Elasticsearch-prod-controller-1 1/1 Running 0 4m40s + +NAME TYPE DATA AGE +secret/Elasticsearch-prod-auth kubernetes.io/basic-auth 2 4m51s + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/Elasticsearch-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/Elasticsearch-prod kubedb.com/Elasticsearch 3.9.0 4m47s +``` + +## Update Elasticsearch Database using GitOps + +### Scale Elasticsearch Database Resources + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut + ``` + +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Elasticsearch` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ $ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 22h + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +``` + +### Scale Elasticsearch Replicas +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Elasticsearch` database replicas. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 22h + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +NAME READY STATUS RESTARTS AGE +Elasticsearch-prod-broker-0 1/1 Running 0 34m +Elasticsearch-prod-broker-1 1/1 Running 0 33m +Elasticsearch-prod-broker-2 1/1 Running 0 33m +Elasticsearch-prod-controller-0 1/1 Running 0 32m +Elasticsearch-prod-controller-1 1/1 Running 0 31m +Elasticsearch-prod-controller-2 1/1 Running 0 31m +``` + +We can also scale down the replicas by updating the `replicas` fields. + +### Expand Elasticsearch Volume + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `Elasticsearch` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 23m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 23m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +Elasticsearch-prod-data-Elasticsearch-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +Elasticsearch-prod-data-Elasticsearch-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +Elasticsearch-prod-data-Elasticsearch-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +Elasticsearch-prod-data-Elasticsearch-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m + +``` + +## Reconfigure Elasticsearch + +At first, we will create a secret containing `user.conf` file with required configuration settings. +To know more about this configuration file, check [here](/docs/guides/Elasticsearch/configuration/Elasticsearch-combined.md) +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: new-kf-combined-custom-config + namespace: demo +stringData: + server.properties: |- + log.retention.hours=125 +``` + +Now, we will add this file to `kubedb /kf-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ └── Elasticsearch.yaml +1 directories, 2 files +``` + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `Elasticsearch` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 74m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 74m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 24m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m + +``` + + + +> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. + +### Rotate Elasticsearch Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, + +```bash +kubectl create secret generic kf-rotate-auth -n demo \ +--type=kubernetes.io/basic-auth \ +--from-literal=username=Elasticsearch \ +--from-literal=password=Elasticsearch-secret +secret/kf-rotate-auth created + +``` + + + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + authSecret: + kind: Secret + name: kf-rotate-auth + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `Elasticsearch` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 7m11s + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 7m11s + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 17h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 28m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h + +``` + + +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Elasticsearch. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating a ca certificates using openssl. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +Generating a RSA private key +................+++++ +........................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls Elasticsearch-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/Elasticsearch-ca created +``` + +Now, Let's create an `Issuer` using the `Elasticsearch-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: kf-issuer + namespace: demo +spec: + ca: + secretName: Elasticsearch-ca +``` + +Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ ├── kf-issuer.yaml +│ └── Elasticsearch.yaml +1 directories, 4 files +``` + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Elasticsearch` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops,pods -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 41m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 75m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 5d18h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h + +``` + + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Elasticsearch. + +### Update Version + +List Elasticsearch versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Elasticsearch/update-version/update-version.md). + +Let's choose `4.0.0` in this example. + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Elasticsearch` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 4.0.0 Ready 3h47m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 3h47m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 5d22h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +``` + + +Now, we are going to verify whether the `Elasticsearch`, `PetSet` and it's `Pod` have updated with new image. Let's check, + +```bash +$ kubectl get Elasticsearch -n demo Elasticsearch-prod -o=jsonpath='{.spec.version}{"\n"}' +4.0.0 + +$ kubectl get petset -n demo Elasticsearch-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Elasticsearch:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 + +$ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Elasticsearch:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +``` + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9091 + serviceMonitor: + labels: + release: prometheus + interval: 10s + deletionPolicy: WipeOut +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Elasticsearch` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 4.0.0 Ready 5h12m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 5h12m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 6d +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-restart-ljpqih Restart Successful 3m51s +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d + +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + +## Next Steps + +[//]: # (- Learn Elasticsearch [GitOps](/docs/guides/Elasticsearch/concepts/Elasticsearch-gitops.md)) +- Learn Elasticsearch Scaling + - [Horizontal Scaling](/docs/guides/Elasticsearch/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/Elasticsearch/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/Elasticsearch/update-version/overview.md) +- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/Elasticsearch/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mongodb/gitops/overview.md b/docs/guides/mongodb/gitops/overview.md new file mode 100644 index 0000000000..bfa01c2fff --- /dev/null +++ b/docs/guides/mongodb/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: Elasticsearch Gitops Overview +description: Elasticsearch Gitops Overview +menu: + docs_{{ .version }}: + identifier: es-gitops-overview + name: Overview + parent: es-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for Elasticsearch + +This guide will give you an overview of how KubeDB `gitops` operator works with Elasticsearch databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Elasticsearch databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [Elasticsearch](/docs/guides/elasticsearch/concepts/elasticsearch/index.md) + - [ElasticsearchOpsRequest](/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md) + + + +## Workflow GitOps with Elasticsearch + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + + +
+ + GitOps Flow + +
Fig: GitOps process of Elasticsearch
+ +
+ +1. **Define GitOps Elasticsearch**: Create Custom Resource (CR) of kind `Elasticsearch` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Elasticsearch CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing Elasticsearch databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running Elasticsearch using GitOps. diff --git a/docs/guides/mssqlserver/gitops/_index.md b/docs/guides/mssqlserver/gitops/_index.md new file mode 100644 index 0000000000..cc82b5f6bc --- /dev/null +++ b/docs/guides/mssqlserver/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: Elasticsearch Gitops +menu: + docs_{{ .version }}: + identifier: es-gitops + name: Elasticsearch Gitops + parent: es-elasticsearch-guides + weight: 70 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md new file mode 100644 index 0000000000..332c4f29d9 --- /dev/null +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -0,0 +1,900 @@ +--- +title: Elasticsearch Gitops Overview +description: Elasticsearch Gitops Overview +menu: + docs_{{ .version }}: + identifier: es-gitops-overview + name: Overview + parent: es-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + + + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Elasticsearch using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create Elasticsearch database and manage updates using GitOps workflow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/Elasticsearch](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/Elasticsearch) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create Elasticsearch Database using GitOps + +### Create a Elasticsearch GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.2.3 + enableSSL: true + replicas: 2 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── Elasticsearch.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is created in your cluster. + +Our `gitops` operator will create an actual `Elasticsearch` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get Elasticsearch.gitops.kubedb.com,Elasticsearch.kubedb.com -n demo +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 2m56s + +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 2m56s +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` Elasticsearch. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +NAME AGE +petset.apps.k8s.appscode.com/Elasticsearch-prod-broker 4m49s +petset.apps.k8s.appscode.com/Elasticsearch-prod-controller 4m47s + +NAME READY STATUS RESTARTS AGE +pod/Elasticsearch-prod-broker-0 1/1 Running 0 4m48s +pod/Elasticsearch-prod-broker-1 1/1 Running 0 4m42s +pod/Elasticsearch-prod-controller-0 1/1 Running 0 4m47s +pod/Elasticsearch-prod-controller-1 1/1 Running 0 4m40s + +NAME TYPE DATA AGE +secret/Elasticsearch-prod-auth kubernetes.io/basic-auth 2 4m51s + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/Elasticsearch-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/Elasticsearch-prod kubedb.com/Elasticsearch 3.9.0 4m47s +``` + +## Update Elasticsearch Database using GitOps + +### Scale Elasticsearch Database Resources + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut + ``` + +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Elasticsearch` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ $ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 22h + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +``` + +### Scale Elasticsearch Replicas +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: local-path + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Elasticsearch` database replicas. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 22h + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +NAME READY STATUS RESTARTS AGE +Elasticsearch-prod-broker-0 1/1 Running 0 34m +Elasticsearch-prod-broker-1 1/1 Running 0 33m +Elasticsearch-prod-broker-2 1/1 Running 0 33m +Elasticsearch-prod-controller-0 1/1 Running 0 32m +Elasticsearch-prod-controller-1 1/1 Running 0 31m +Elasticsearch-prod-controller-2 1/1 Running 0 31m +``` + +We can also scale down the replicas by updating the `replicas` fields. + +### Expand Elasticsearch Volume + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `Elasticsearch` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 23m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 23m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +Elasticsearch-prod-data-Elasticsearch-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +Elasticsearch-prod-data-Elasticsearch-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +Elasticsearch-prod-data-Elasticsearch-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +Elasticsearch-prod-data-Elasticsearch-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m + +``` + +## Reconfigure Elasticsearch + +At first, we will create a secret containing `user.conf` file with required configuration settings. +To know more about this configuration file, check [here](/docs/guides/Elasticsearch/configuration/Elasticsearch-combined.md) +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: new-kf-combined-custom-config + namespace: demo +stringData: + server.properties: |- + log.retention.hours=125 +``` + +Now, we will add this file to `kubedb /kf-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ └── Elasticsearch.yaml +1 directories, 2 files +``` + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `Elasticsearch` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 74m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 74m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 24m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m + +``` + + + +> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. + +### Rotate Elasticsearch Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, + +```bash +kubectl create secret generic kf-rotate-auth -n demo \ +--type=kubernetes.io/basic-auth \ +--from-literal=username=Elasticsearch \ +--from-literal=password=Elasticsearch-secret +secret/kf-rotate-auth created + +``` + + + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + authSecret: + kind: Secret + name: kf-rotate-auth + configSecret: + name: new-kf-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `Elasticsearch` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 7m11s + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 7m11s + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 17h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 28m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h + +``` + + +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Elasticsearch. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating a ca certificates using openssl. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +Generating a RSA private key +................+++++ +........................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls Elasticsearch-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/Elasticsearch-ca created +``` + +Now, Let's create an `Issuer` using the `Elasticsearch-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: kf-issuer + namespace: demo +spec: + ca: + secretName: Elasticsearch-ca +``` + +Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ ├── kf-issuer.yaml +│ └── Elasticsearch.yaml +1 directories, 4 files +``` + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Elasticsearch` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops,pods -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 41m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 75m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 5d18h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h + +``` + + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Elasticsearch. + +### Update Version + +List Elasticsearch versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Elasticsearch/update-version/update-version.md). + +Let's choose `4.0.0` in this example. + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Elasticsearch` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get kf,Elasticsearch,kfops -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 4.0.0 Ready 3h47m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 3h47m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 5d22h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +``` + + +Now, we are going to verify whether the `Elasticsearch`, `PetSet` and it's `Pod` have updated with new image. Let's check, + +```bash +$ kubectl get Elasticsearch -n demo Elasticsearch-prod -o=jsonpath='{.spec.version}{"\n"}' +4.0.0 + +$ kubectl get petset -n demo Elasticsearch-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Elasticsearch:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 + +$ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Elasticsearch:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +``` + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: Elasticsearch-prod + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Elasticsearch + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9091 + serviceMonitor: + labels: + release: prometheus + interval: 10s + deletionPolicy: WipeOut +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Elasticsearch` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo +NAME TYPE VERSION STATUS AGE +Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 4.0.0 Ready 5h12m + +NAME AGE +Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 5h12m + +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 6d +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-restart-ljpqih Restart Successful 3m51s +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m +Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d + +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + +## Next Steps + +[//]: # (- Learn Elasticsearch [GitOps](/docs/guides/Elasticsearch/concepts/Elasticsearch-gitops.md)) +- Learn Elasticsearch Scaling + - [Horizontal Scaling](/docs/guides/Elasticsearch/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/Elasticsearch/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/Elasticsearch/update-version/overview.md) +- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/Elasticsearch/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mssqlserver/gitops/overview.md b/docs/guides/mssqlserver/gitops/overview.md new file mode 100644 index 0000000000..bfa01c2fff --- /dev/null +++ b/docs/guides/mssqlserver/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: Elasticsearch Gitops Overview +description: Elasticsearch Gitops Overview +menu: + docs_{{ .version }}: + identifier: es-gitops-overview + name: Overview + parent: es-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for Elasticsearch + +This guide will give you an overview of how KubeDB `gitops` operator works with Elasticsearch databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Elasticsearch databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [Elasticsearch](/docs/guides/elasticsearch/concepts/elasticsearch/index.md) + - [ElasticsearchOpsRequest](/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md) + + + +## Workflow GitOps with Elasticsearch + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + + +
+ + GitOps Flow + +
Fig: GitOps process of Elasticsearch
+ +
+ +1. **Define GitOps Elasticsearch**: Create Custom Resource (CR) of kind `Elasticsearch` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Elasticsearch CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing Elasticsearch databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running Elasticsearch using GitOps. From d75bcb773f79b1083582bb2be3ad27e68b1ce9c5 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Mon, 16 Feb 2026 17:02:41 +0600 Subject: [PATCH 08/51] gitops demo Signed-off-by: Bonusree --- .../using-config-file.md.bak | 177 +++ docs/guides/mysql/gitops/_index.md | 10 + docs/guides/mysql/gitops/gitops.md | 1031 +++++++++++++++++ docs/guides/mysql/gitops/overview.md | 43 + docs/guides/redis/gitops/_index.md | 10 + docs/guides/redis/gitops/gitops.md | 886 ++++++++++++++ docs/guides/redis/gitops/overview.md | 50 + .../configuration/config-file/index.md.bak | 248 ++++ 8 files changed, 2455 insertions(+) create mode 100644 docs/guides/ignite/custom-configuration/using-config-file.md.bak create mode 100755 docs/guides/mysql/gitops/_index.md create mode 100644 docs/guides/mysql/gitops/gitops.md create mode 100644 docs/guides/mysql/gitops/overview.md create mode 100644 docs/guides/redis/gitops/_index.md create mode 100644 docs/guides/redis/gitops/gitops.md create mode 100644 docs/guides/redis/gitops/overview.md create mode 100644 docs/guides/singlestore/configuration/config-file/index.md.bak diff --git a/docs/guides/ignite/custom-configuration/using-config-file.md.bak b/docs/guides/ignite/custom-configuration/using-config-file.md.bak new file mode 100644 index 0000000000..68140892b8 --- /dev/null +++ b/docs/guides/ignite/custom-configuration/using-config-file.md.bak @@ -0,0 +1,177 @@ +--- +title: Run Ignite with Custom Configuration +menu: + docs_{{ .version }}: + identifier: ig-using-config-file-configuration + name: Customize Configurations + parent: ig-custom-configuration + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Using Custom Configuration File + +KubeDB supports providing custom configuration for Ignite. This tutorial will show you how to use KubeDB to run Ignite with custom configuration. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). + +- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. + + ```bash + $ kubectl create ns demo + namespace/demo created + + $ kubectl get ns demo + NAME STATUS AGE + demo Active 5s + ``` + +> Note: YAML files used in this tutorial are stored in [docs/examples/ignite](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/ignite) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +## Overview + +Ignite does not allow to configuration via any file. However, configuration parameters can be set as arguments while starting the ignite docker image. To keep similarity with other KubeDB supported databases which support configuration through a config file, KubeDB has added an additional executable script on top of the official ignite docker image. This script parses the configuration file then set them as arguments of ignite binary. + +To know more about configuring Ignite server see [here](https://ignite.apache.org/docs/ignite3/latest/administrators-guide/config/node-config). + +At first, you have to create a custom configuration file and provide its name in `spec.configuration.secretName`. The operator reads this Secret internally and applies the configuration automatically. + + +In this tutorial, we will enable Ignite's authentication via secret. + +Create a secret with custom configuration file: +```yaml +apiVersion: v1 +stringData: + node-configuration.xml: | + + + + + + + + +kind: Secret +metadata: + name: ignite-configuration + namespace: demo + resourceVersion: "4505" +``` +Here, `authenticationEnabled's` default value is `false`. In this secret, we make the value `true`. + +```bash + $ kubectl apply -f ignite-configuration.yaml +secret/ignite-configuration created +``` + +Let's get the ignite-configuration `secret` with custom configuration: + +```yaml +$ kubectl get secret -n demo ignite-configuration -o yaml +apiVersion: v1 +data: + node-configuration.xml: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGJlYW5zIHhtbG5zPSJodHRwOi8vd3d3LnNwcmluZ2ZyYW1ld29yay5vcmcvc2NoZW1hL2JlYW5zIgogICB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIgogICB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cuc3ByaW5nZnJhbWV3b3JrLm9yZy9zY2hlbWEvYmVhbnMKICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LnNwcmluZ2ZyYW1ld29yay5vcmcvc2NoZW1hL2JlYW5zL3NwcmluZy1iZWFucy0zLjAueHNkIj4KPCEtLSBZb3VyIElnbml0ZSBDb25maWd1cmF0aW9uIC0tPgo8YmVhbiBjbGFzcz0ib3JnLmFwYWNoZS5pZ25pdGUuY29uZmlndXJhdGlvbi5JZ25pdGVDb25maWd1cmF0aW9uIj4KCiAgICA8cHJvcGVydHkgbmFtZT0iYXV0aGVudGljYXRpb25FbmFibGVkIiB2YWx1ZT0idHJ1ZSIvPgoKPC9iZWFuPgo8L2JlYW5zPgo= +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{},"name":"ignite-configuration","namespace":"demo","resourceVersion":"4505"},"stringData":{"node-configuration.xml":"\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\n\u003cbeans xmlns=\"http://www.springframework.org/schema/beans\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n xsi:schemaLocation=\"http://www.springframework.org/schema/beans\n http://www.springframework.org/schema/beans/spring-beans-3.0.xsd\"\u003e\n\u003c!-- Your Ignite Configuration --\u003e\n\u003cbean class=\"org.apache.ignite.configuration.IgniteConfiguration\"\u003e\n\n \u003cproperty name=\"authenticationEnabled\" value=\"true\"/\u003e\n\n\u003c/bean\u003e\n\u003c/beans\u003e\n"}} + creationTimestamp: "2025-06-02T09:37:05Z" + name: ignite-configuration + namespace: demo + resourceVersion: "1391127" + uid: 57f2a44c-d6b1-4571-bb91-fd68b3048306 +type: Opaque +``` + +Now, create Ignite crd specifying `spec.configuration.secretName` field. + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/ignite/configuration/custom-ignite.yaml +ignite.kubedb.com/custom-ignite created +``` + +Below is the YAML for the Ignite crd we just created. + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: Ignite +metadata: + name: custom-ignite + namespace: demo +spec: + replicas: 3 + version: 2.17.0 + configuration: + secretName: ignite-configuration + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Now, wait a few minutes. KubeDB operator will create necessary petset, services etc. If everything goes well, we will see that a pod with the name `custom-ignite-0` has been created. + +Check if the database is ready + +```bash +$ kubectl get ig -n demo +NAME VERSION STATUS AGE +custom-ignite 2.17.0 Ready 17m +``` + +Now, we will check if the database has started with the custom configuration we have provided. +We will connect to `custom-ignite-0` pod: + +```bash +$ kubectl exec -it -n demo ignite-quickstart-0 -c ignite -- bash +[ignite@ignite-quickstart-0 config]$ cat /ignite/config/node-configuration.xml + + + + +... +... + + + +``` + +Here, we can see `authenticationEnabled's` value is `true`. + +## Cleaning up + +To cleanup the Kubernetes resources created by this tutorial, run: + +```bash +kubectl patch -n demo ig/custom-ignite -p '{"spec":{"deletionPolicy":"WipeOut"}}' --type="merge" +kubectl delete -n demo ig/custom-ignite + +kubectl delete -n demo secret ignite-configuration +kubectl delete ns demo +``` + +If you would like to uninstall KubeDB operator, please follow the steps [here](/docs/setup/README.md). + +## Next Steps + +- Learn how to use KubeDB to run a Ignite server [here](/docs/guides/ignite/README.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mysql/gitops/_index.md b/docs/guides/mysql/gitops/_index.md new file mode 100755 index 0000000000..80ccea8160 --- /dev/null +++ b/docs/guides/mysql/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: GitOps PostgreSQL +menu: + docs_{{ .version }}: + identifier: pg-gitops-postgres + name: GitOps + parent: pg-postgres-guides + weight: 40 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/mysql/gitops/gitops.md b/docs/guides/mysql/gitops/gitops.md new file mode 100644 index 0000000000..2f56baef23 --- /dev/null +++ b/docs/guides/mysql/gitops/gitops.md @@ -0,0 +1,1031 @@ +--- +title: GitOps MySQL +menu: + docs_{{ .version }}: + identifier: my-using-gitops + name: GitOps MySQL + parent: my-gitops-MySQL + weight: 15 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps MySQL using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create MySQL database and manage updates using GitOps workflow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/MySQL](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/MySQL) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create MySQL Database using GitOps + +### Create a MySQL GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + replicas: 3 + version: "16.6" + storageType: Durable + podTemplate: + spec: + containers: + - name: MySQL + resources: + limits: + memory: 1Gi + requests: + cpu: 500m + memory: 1Gi + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── MySQL.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is created in your cluster. + +Our `gitops` operator will create an actual `MySQL` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com -n demo +NAME AGE +mysql.gitops.kubedb.com/my-gitops 172m + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.1.0 Ready 172m +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` MySQL. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=my-gitops' +NAME AGE +petset.apps.k8s.appscode.com/my-gitops 174m + +NAME READY STATUS RESTARTS AGE +pod/my-gitops-0 2/2 Running 0 133m +pod/my-gitops-1 2/2 Running 0 129m +pod/my-gitops-2 2/2 Running 0 132m + +NAME TYPE DATA AGE +secret/my-gitops-auth kubernetes.io/basic-auth 2 174m + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/my-gitops ClusterIP 10.43.39.209 3306/TCP 174m +service/my-gitops-pods ClusterIP None 3306/TCP 174m +service/my-gitops-standby ClusterIP 10.43.212.101 3306/TCP 174m + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/my-gitops kubedb.com/mysql 9.1.0 174m +``` + +## Update MySQL Database using GitOps + +### Scale MySQL Database Resources + +Update the `MySQL.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + replicas: 3 + version: "16.6" + storageType: Durable + podTemplate: + spec: + containers: + - name: MySQL + resources: + limits: + memory: 2Gi + requests: + cpu: 700m + memory: 2Gi + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `MySQLOpsRequest` to update the `MySQL` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo +NAME AGE +mysql.gitops.kubedb.com/my-gitops 178m + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.1.0 Ready 178m + +NAME TYPE STATUS AGE +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-mw8s6j VerticalScaling Successful 144m +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo my-gitops-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "1", + "memory": "1536Mi" + }, + "requests": { + "cpu": "500m", + "memory": "1Gi" + } +} + +``` + +### Scale MySQL Replicas +Update the `MySQL.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + replicas: 5 + version: "16.6" + storageType: Durable + podTemplate: + spec: + containers: + - name: MySQL + resources: + limits: + memory: 2Gi + requests: + cpu: 700m + memory: 2Gi + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Update the `replicas` to `5`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` MySQLOpsRequest to update the `MySQL` database replicas. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo +NAME AGE +mysql.gitops.kubedb.com/my-gitops 178m + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.1.0 Ready 178m + +NAME TYPE STATUS AGE +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-s9lyzc HorizontalScaling Successful 117m +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-mw8s6j VerticalScaling Successful 144m + +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=my-gitops' +NAME READY STATUS RESTARTS AGE +my-gitops-0 2/2 Running 0 144m +my-gitops-1 2/2 Running 0 140m +my-gitops-2 2/2 Running 0 143m + +``` + +We can also scale down the replicas by updating the `replicas` fields. + +### Exapand MySQL Volume + +Update the `MySQL.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + replicas: 5 + version: "16.6" + storageType: Durable + podTemplate: + spec: + containers: + - name: MySQL + resources: + limits: + memory: 2Gi + requests: + cpu: 700m + memory: 2Gi + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi + deletionPolicy: WipeOut +``` + +Update the `storage.resources.requests.storage` to `10Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` MySQLOpsRequest to update the `MySQL` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo +NAME AGE +MySQL.gitops.kubedb.com/my-gitops 27m + +NAME VERSION STATUS AGE +MySQL.kubedb.com/my-gitops 16.6 Ready 27m + +NAME TYPE STATUS AGE +MySQLopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-wvxu5x HorizontalScaling Successful 6m +MySQLopsrequest.ops.kubedb.com/my-gitops-verticalscaling-i0kr1l VerticalScaling Successful 13m +MySQLopsrequest.ops.kubedb.com/my-gitops-volumeexpansion-2j5x5g VolumeExpansion Progressing 2s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=my-gitops' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +data-my-gitops-0 Bound pvc-061f3622-234f-4f91-b4d1-b81aa8739503 10Gi RWO standard 30m +data-my-gitops-1 Bound pvc-045fc563-fb4e-416c-a9c2-b20c96532978 10Gi RWO standard 30m +data-my-gitops-2 Bound pvc-a0f1d8fd-a677-4407-80b1-104b9f7b4cd1 10Gi RWO standard 30m +data-my-gitops-3 Bound pvc-060b6fab-0c2d-4935-b31b-2866be68dd6f 10Gi RWO standard 8m58s +data-my-gitops-4 Bound pvc-8149b579-a40f-4cd8-ac37-6a2401fd7807 10Gi RWO standard 8m23s +``` + +## Reconfigure MySQL + +Before, create opsrequest parameters were, +```shell +kubectl exec -it -n demo my-gitops-0 -- bash +Defaulted container "mysql" out of: mysql, mysql-coordinator, mysql-init (init) +bash-5.1$ mysql -uroot -p$MYSQL_ROOT_PASSWORD +mysql: [Warning] Using a password on the command line interface can be insecure. +Welcome to the MySQL monitor. Commands end with ; or \g. +Your MySQL connection id is 277 +Server version: 9.1.0 MySQL Community Server - GPL + +Copyright (c) 2000, 2024, Oracle and/or its affiliates. + +Oracle is a registered trademark of Oracle Corporation and/or its +affiliates. Other names may be trademarks of their respective +owners. + +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. + +mysql> show variables like 'max_connections'; ++-----------------+-------+ +| Variable_name | Value | ++-----------------+-------+ +| max_connections | 151 | ++-----------------+-------+ +1 row in set (0.01 sec) + +mysql> show variables like 'read_buffer_size'; ++------------------+--------+ +| Variable_name | Value | ++------------------+--------+ +| read_buffer_size | 131072 | ++------------------+--------+ +1 row in set (0.00 sec) + +``` +At first, we will create a secret containing `user.conf` file with required configuration settings. +To know more about this configuration file, check [here](/docs/guides/MySQL/configuration/using-config-file.md) +```yaml +apiVersion: v1 +stringData: + user.conf: | + max_connections=200 + shared_buffers=256MB +kind: Secret +metadata: + name: my-configuration + namespace: demo +type: Opaque +``` + +Now, we will add this file to `kubedb/my-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── my-configuration.yaml +│ └── MySQL.yaml +1 directories, 2 files +``` + +Update the `MySQL.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + configSecret: + name: my-configuration + replicas: 5 + version: "16.6" + storageType: Durable + podTemplate: + spec: + containers: + - name: MySQL + resources: + limits: + memory: 2Gi + requests: + cpu: 700m + memory: 2Gi + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi + deletionPolicy: WipeOut +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` MySQLOpsRequest to update the `MySQL` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo +NAME AGE +MySQL.gitops.kubedb.com/my-gitops 36m + +NAME VERSION STATUS AGE +MySQL.kubedb.com/my-gitops 16.6 Ready 36m + +NAME TYPE STATUS AGE +MySQLopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-wvxu5x HorizontalScaling Successful 15m +MySQLopsrequest.ops.kubedb.com/my-gitops-reconfigure-i4r23j Reconfigure Progressing 1s +MySQLopsrequest.ops.kubedb.com/my-gitops-verticalscaling-i0kr1l VerticalScaling Successful 23m +``` + +After Ops Request becomes `Succesful`, lets check these parameters, + +```bash +$ kubectl exec -it -n demo my-gitops-0 -- bash +Defaulted container "mysql" out of: mysql, mysql-coordinator, mysql-init (init) +bash-5.1$ mysql -uroot -p$MYSQL_ROOT_PASSWORD +mysql: [Warning] Using a password on the command line interface can be insecure. +Welcome to the MySQL monitor. Commands end with ; or \g. +Your MySQL connection id is 3115 +Server version: 9.1.0 MySQL Community Server - GPL + +Copyright (c) 2000, 2024, Oracle and/or its affiliates. + +Oracle is a registered trademark of Oracle Corporation and/or its +affiliates. Other names may be trademarks of their respective +owners. + +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. + +mysql> show variables like 'max_connections'; ++-----------------+-------+ +| Variable_name | Value | ++-----------------+-------+ +| max_connections | 200 | ++-----------------+-------+ +1 row in set (0.00 sec) + +mysql> show variables like 'read_buffer_size'; ++------------------+---------+ +| Variable_name | Value | ++------------------+---------+ +| read_buffer_size | 1048576 | ++------------------+---------+ +1 row in set (0.01 sec) +``` +You can check the other pods same way. +So we have configured custom parameters. + +> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. + +### Rotate MySQL Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will do that using gitops, create the file `kubedb/my-auth.yaml` with the following content, + +```yaml +apiVersion: v1 +data: + password: cGdwYXNzd29yZA== + username: cG9zdGdyZXM= +kind: Secret +metadata: + name: my-rotate-auth + namespace: demo +type: kubernetes.io/basic-auth +``` + +File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── my-auth.yaml +│ ├── my-configuration.yaml +│ └── MySQL.yaml +1 directories, 3 files +``` + +Update the `MySQL.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + version: "9.1.0" + replicas: 3 + authSecret: + kind: Secret + name: mysql-quickstart-auth-user + configuration: + secretName: my-configuration + topology: + mode: GroupReplication + group: + mode: Single-Primary + podTemplate: + spec: + containers: + - name: mysql + resources: + limits: + cpu: 1000m + memory: 1.5Gi + requests: + cpu: 500m + memory: 1Gi + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Change the `authSecret` field to `my-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MySQLOpsRequest to update the `MySQL` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo +NAME AGE +mysql.gitops.kubedb.com/my-gitops 5h2m + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.1.0 Ready 5h2m + +NAME TYPE STATUS AGE +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-s9lyzc HorizontalScaling Successful 4h1m +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfigure-q4yrg0 Reconfigure Successful 4h28m +mysqlopsrequest.ops.kubedb.com/my-gitops-rotate-auth-5lg5o3 RotateAuth Successful 10m +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-mw8s6j VerticalScaling Successful 4h28m + +``` + +After Ops Request becomes `Successful`, We can validate the changes connecting MySQL with new credentials. +```bash +$ kubectl exec -it -n demo my-gitops-0 -c mysql -- bash +bash-5.1$ mysql -uroot -p"Mysql2" +mysql: [Warning] Using a password on the command line interface can be insecure. +Welcome to the MySQL monitor. Commands end with ; or \g. +Your MySQL connection id is 347 +Server version: 9.1.0 MySQL Community Server - GPL + +Copyright (c) 2000, 2024, Oracle and/or its affiliates. + +Oracle is a registered trademark of Oracle Corporation and/or its +affiliates. Other names may be trademarks of their respective +owners. + +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. + +mysql> SHOW DATABASES; ++--------------------+ +| Database | ++--------------------+ +| information_schema | +| kubedb_system | +| mysql | +| performance_schema | +| sys | ++--------------------+ +5 rows in set (0.00 sec) + +``` + +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in MySQL. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating a ca certificates using openssl. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +Generating a RSA private key +................+++++ +........................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls mysql-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/mysql-ca created +``` + +Now, Let's create an `Issuer` using the `MySQL-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: my-issuer + namespace: demo +spec: + ca: + secretName: MySQL-ca +``` + +Let's add that to our `kubedb/my-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── my-auth.yaml +│ ├── my-configuration.yaml +│ ├── my-issuer.yaml +│ └── MySQL.yaml +1 directories, 4 files +``` + +Update the `MySQL.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + version: "9.1.0" + replicas: 3 + authSecret: + kind: Secret + name: mysql-quickstart-auth-user + configuration: + secretName: my-configuration + topology: + mode: GroupReplication + group: + mode: Single-Primary + requireSSL: true + tls: + issuerRef: + apiGroup: cert-manager.io + kind: Issuer + name: my-issuer + certificates: + - alias: server + subject: + organizations: + - kubedb:server + dnsNames: + - localhost + ipAddresses: + - "127.0.0.1" + podTemplate: + spec: + containers: + - name: mysql + resources: + limits: + cpu: 1000m + memory: 1.5Gi + requests: + cpu: 500m + memory: 1Gi + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` MySQLOpsRequest to update the `MySQL` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo +NAME AGE +mysql.gitops.kubedb.com/my-gitops 6h7m + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.1.0 Ready 6h7m + +NAME TYPE STATUS AGE +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-s9lyzc HorizontalScaling Successful 5h6m +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfigure-q4yrg0 Reconfigure Successful 5h33m +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfiguretls-39ir77 ReconfigureTLS Successful 4m39s +mysqlopsrequest.ops.kubedb.com/my-gitops-rotate-auth-5lg5o3 RotateAuth Successful 74m +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-mw8s6j VerticalScaling Successful 5h33m + +``` + +After Ops Request becomes `Successful`, We can validate the changes connecting MySQL with new credentials. +```bash +$ kubectl exec -it -n demo my-gitops-0 -c mysql -- bash +bash-5.1$ mysql -uroot -p"Mysql2" +mysql: [Warning] Using a password on the command line interface can be insecure. +Welcome to the MySQL monitor. Commands end with ; or \g. +Your MySQL connection id is 347 +Server version: 9.1.0 MySQL Community Server - GPL + +Copyright (c) 2000, 2024, Oracle and/or its affiliates. + +Oracle is a registered trademark of Oracle Corporation and/or its +affiliates. Other names may be trademarks of their respective +owners. + +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. + +mysql> SHOW DATABASES; ++--------------------+ +| Database | ++--------------------+ +| information_schema | +| kubedb_system | +| mysql | +| performance_schema | +| sys | ++--------------------+ +5 rows in set (0.00 sec) + +mysql> command terminated with exit code 137 +banusree@bonusree-datta-PC ~ [SIGKILL]> kubectl exec -it -n demo my-gitops-0 -c mysql -- bash +bash-5.1$ ls /etc/mysql/certs/ +ca.crt client.crt client.key server.crt server.key +bash-5.1$ mysql -u${MYSQL_ROOT_USERNAME} -p{MYSQL_ROOT_PASSWORD} +mysql: [Warning] Using a password on the command line interface can be insecure. +ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) +bash-5.1$ mysql -uroot -p"Mysql2" +mysql: [Warning] Using a password on the command line interface can be insecure. +Welcome to the MySQL monitor. Commands end with ; or \g. +Your MySQL connection id is 201 +Server version: 9.1.0 MySQL Community Server - GPL + +Copyright (c) 2000, 2024, Oracle and/or its affiliates. + +Oracle is a registered trademark of Oracle Corporation and/or its +affiliates. Other names may be trademarks of their respective +owners. + +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. + +mysql> SHOW VARIABLES LIKE '%ssl%'; ++---------------------------------------------------+-----------------------------+ +| Variable_name | Value | ++---------------------------------------------------+-----------------------------+ +| admin_ssl_ca | | +| admin_ssl_capath | | +| admin_ssl_cert | | +| admin_ssl_cipher | | +| admin_ssl_crl | | +| admin_ssl_crlpath | | +| admin_ssl_key | | +| clone_ssl_ca | /etc/mysql/certs/ca.crt | +| clone_ssl_cert | /etc/mysql/certs/server.crt | +| clone_ssl_key | /etc/mysql/certs/server.key | +| group_replication_recovery_ssl_ca | /etc/mysql/certs/ca.crt | +| group_replication_recovery_ssl_capath | | +| group_replication_recovery_ssl_cert | /etc/mysql/certs/server.crt | +| group_replication_recovery_ssl_cipher | | +| group_replication_recovery_ssl_crl | | +| group_replication_recovery_ssl_crlpath | | +| group_replication_recovery_ssl_key | /etc/mysql/certs/server.key | +| group_replication_recovery_ssl_verify_server_cert | OFF | +| group_replication_recovery_use_ssl | ON | +| group_replication_ssl_mode | VERIFY_CA | +| mysqlx_ssl_ca | | +| mysqlx_ssl_capath | | +| mysqlx_ssl_cert | | +| mysqlx_ssl_cipher | | +| mysqlx_ssl_crl | | +| mysqlx_ssl_crlpath | | +| mysqlx_ssl_key | | +| performance_schema_show_processlist | OFF | +| ssl_ca | /etc/mysql/certs/ca.crt | +| ssl_capath | /etc/mysql/certs | +| ssl_cert | /etc/mysql/certs/server.crt | +| ssl_cipher | | +| ssl_crl | | +| ssl_crlpath | | +| ssl_fips_mode | OFF | +| ssl_key | /etc/mysql/certs/server.key | +| ssl_session_cache_mode | ON | +| ssl_session_cache_timeout | 300 | ++---------------------------------------------------+-----------------------------+ +38 rows in set (0.00 sec) + +mysql> SHOW VARIABLES LIKE '%require_secure_transport%'; ++--------------------------+-------+ +| Variable_name | Value | ++--------------------------+-------+ +| require_secure_transport | OFF | ++--------------------------+-------+ +1 row in set (0.00 sec) + + +``` + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for MySQL. + +### Update Version + +List MySQL versions using `kubectl get MySQLversion` and choose desired version that is compatible for umyrade from current version. Check the version constraints and ops request [here](/docs/guides/MySQL/update-version/versionumyrading/index.md). + +Let's choose `17.4` in this example. + +Update the `MySQL.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + authSecret: + kind: Secret + name: my-rotate-auth + configSecret: + name: my-configuration + replicas: 5 + version: "17.4" + storageType: Durable + sslMode: verify-full + tls: + issuerRef: + apiGroup: cert-manager.io + name: my-issuer + kind: Issuer + certificates: + - alias: server + subject: + organizations: + - kubedb:server + dnsNames: + - localhost + ipAddresses: + - "127.0.0.1" + podTemplate: + spec: + containers: + - name: MySQL + resources: + limits: + memory: 2Gi + requests: + cpu: 700m + memory: 2Gi + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi + deletionPolicy: WipeOut +``` + +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` MySQLOpsRequest to update the `MySQL` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo +NAME AGE +MySQL.gitops.kubedb.com/my-gitops 3h25m + +NAME VERSION STATUS AGE +MySQL.kubedb.com/my-gitops 16.6 Ready 3h25m + +NAME TYPE STATUS AGE +MySQLopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-wvxu5x HorizontalScaling Successful 3h3m +MySQLopsrequest.ops.kubedb.com/my-gitops-reconfigure-i4r23j Reconfigure Successful 168m +MySQLopsrequest.ops.kubedb.com/my-gitops-reconfiguretls-91fseg ReconfigureTLS Successful 7m33s +MySQLopsrequest.ops.kubedb.com/my-gitops-rotate-auth-zot83x RotateAuth Successful 161m +MySQLopsrequest.ops.kubedb.com/my-gitops-versionupdate-1wxgt9 UpdateVersion Progressing 4s +MySQLopsrequest.ops.kubedb.com/my-gitops-verticalscaling-i0kr1l VerticalScaling Successful 3h11m +``` + + +Now, we are going to verify whether the `MySQL`, `PetSet` and it's `Pod` have updated with new image. Let's check, + +```bash +$ kubectl get MySQL -n demo my-gitops -o=jsonpath='{.spec.version}{"\n"}' +17.4 + +$ kubectl get petset -n demo my-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/MySQL:17.4-alpine + +$ kubectl get pod -n demo my-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/MySQL:17.4-alpine +``` + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `MySQL.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + authSecret: + kind: Secret + name: my-rotate-auth + configSecret: + name: my-configuration + replicas: 5 + version: "17.4" + storageType: Durable + sslMode: verify-full + tls: + issuerRef: + apiGroup: cert-manager.io + name: my-issuer + kind: Issuer + certificates: + - alias: server + subject: + organizations: + - kubedb:server + dnsNames: + - localhost + ipAddresses: + - "127.0.0.1" + podTemplate: + spec: + containers: + - name: MySQL + resources: + limits: + memory: 2Gi + requests: + cpu: 700m + memory: 2Gi + monitor: + agent: prometheus.io/operator + prometheus: + serviceMonitor: + labels: + release: prometheus + interval: 10s + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi + deletionPolicy: WipeOut +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` MySQLOpsRequest to add the `MySQL` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo +NAME AGE +MySQL.gitops.kubedb.com/my-gitops 3h34m + +NAME VERSION STATUS AGE +MySQL.kubedb.com/my-gitops 16.6 NotReady 3h34m + +NAME TYPE STATUS AGE +MySQLopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-wvxu5x HorizontalScaling Successful 3h13m +MySQLopsrequest.ops.kubedb.com/my-gitops-reconfigure-i4r23j Reconfigure Successful 177m +MySQLopsrequest.ops.kubedb.com/my-gitops-reconfiguretls-91fseg ReconfigureTLS Successful 16m +MySQLopsrequest.ops.kubedb.com/my-gitops-restart-nhjk9u Restart Progressing 2s +MySQLopsrequest.ops.kubedb.com/my-gitops-rotate-auth-zot83x RotateAuth Successful 170m +MySQLopsrequest.ops.kubedb.com/my-gitops-versionupdate-1wxgt9 UpdateVersion Successful 9m30s +MySQLopsrequest.ops.kubedb.com/my-gitops-verticalscaling-i0kr1l VerticalScaling Successful 3h21m +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `.spec.leaderElection` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + +## Next Steps + +- Learn MySQL [GitOps](/docs/guides/MySQL/concepts/MySQL-gitops.md) +- Learn MySQL Scaling + - [Horizontal Scaling](/docs/guides/MySQL/scaling/horizontal-scaling/overview/index.md) + - [Vertical Scaling](/docs/guides/MySQL/scaling/vertical-scaling/overview/index.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/MySQL/update-version/versionumyrading/index.md) +- Monitor your MySQL database with KubeDB using [built-in Prometheus](/docs/guides/MySQL/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mysql/gitops/overview.md b/docs/guides/mysql/gitops/overview.md new file mode 100644 index 0000000000..bccfd07fc7 --- /dev/null +++ b/docs/guides/mysql/gitops/overview.md @@ -0,0 +1,43 @@ +--- +title: MySQL GitOps Overview +description: MySQL GitOps Overview +menu: + docs_{{ .version }}: + identifier: my-gitops-overview + name: Overview + parent: my-gitops-MySQL + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for MySQL + +This guide will give you an overview of how KubeDB `gitops` operator works with MySQL databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for managing MySQL databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MySQL](/docs/guides/mysql/concepts/database/index.md) + - [MySQLOpsRequest](/docs/guides/mysql/concepts/opsrequest/index.md) + +## Workflow GitOps with MySQL + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + +
+ GitOps Flow +
Fig: GitOps process of MySQL
+
+ +1. **Define GitOps MySQL**: Create Custom Resource (CR) of kind `MySQL` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB MySQL CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the MySQLGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing MySQL databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running MySQL using GitOps. diff --git a/docs/guides/redis/gitops/_index.md b/docs/guides/redis/gitops/_index.md new file mode 100644 index 0000000000..098093afa8 --- /dev/null +++ b/docs/guides/redis/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: Gitops Kafka +menu: + docs_{{ .version }}: + identifier: kf-gitops + name: Gitops + parent: kf-kafka-guides + weight: 30 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/redis/gitops/gitops.md b/docs/guides/redis/gitops/gitops.md new file mode 100644 index 0000000000..1eafdcc0eb --- /dev/null +++ b/docs/guides/redis/gitops/gitops.md @@ -0,0 +1,886 @@ +--- +title: Redis GitOps Guides +menu: + docs_{{ .version }}: + identifier: rd-gitops-guides + name: Gitops Redis + parent: rd-gitops-Redis + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Redis using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create Redis database and manage updates using GitOps worrdlow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/Redis](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/Redis) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create Redis Database using GitOps + +### Create a Redis GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 2 + storageType: Durable + storage: + resources: + requests: + storage: "1Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + podTemplate: + spec: + containers: + - name: redis + resources: + requests: + cpu: "100m" + memory: "100Mi" + deletionPolicy: WipeOut +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── Redis.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is created in your cluster. + +Our `gitops` operator will create an actual `Redis` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get redis.gitops.kubedb.com,redis.kubedb.com -n demo +NAME AGE +redis.gitops.kubedb.com/rd-gitops 8m46s + +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 8m46s + +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` Redis. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=rd-gitops' +NAME AGE +petset.apps.k8s.appscode.com/rd-gitops-shard0 9m38s +petset.apps.k8s.appscode.com/rd-gitops-shard1 9m36s +petset.apps.k8s.appscode.com/rd-gitops-shard2 9m34s + +NAME READY STATUS RESTARTS AGE +pod/rd-gitops-shard0-0 1/1 Running 0 9m37s +pod/rd-gitops-shard0-1 1/1 Running 0 9m14s +pod/rd-gitops-shard1-0 1/1 Running 0 9m35s +pod/rd-gitops-shard1-1 1/1 Running 0 9m14s +pod/rd-gitops-shard2-0 1/1 Running 0 9m34s +pod/rd-gitops-shard2-1 1/1 Running 0 9m14s + +NAME TYPE DATA AGE +secret/rd-gitops-9a6ce0 Opaque 1 9m40s +secret/rd-gitops-auth kubernetes.io/basic-auth 2 65m + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/rd-gitops ClusterIP 10.43.193.228 6379/TCP 9m40s +service/rd-gitops-pods ClusterIP None 6379/TCP,16379/TCP 9m40s + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/rd-gitops kubedb.com/redis 8.0.4 9m34s + +``` + +## Update Redis Database using GitOps +### Scale Redis Replicas + + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 8.0.4 + mode: Cluster + cluster: + shards: 4 + replicas: 3 + storageType: Durable + storage: + resources: + requests: + storage: "1Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + podTemplate: + spec: + containers: + - name: redis + resources: + requests: + cpu: "100m" + memory: "100Mi" + deletionPolicy: WipeOut + ``` +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` RedisOpsRequest to update the `Redis` database replicas. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 12m + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 12m + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-1nblpl HorizontalScaling Successful 10m + +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=rd-gitops' +NAME READY STATUS RESTARTS AGE +rd-gitops-shard0-0 1/1 Running 0 16m +rd-gitops-shard0-1 1/1 Running 0 16m +rd-gitops-shard0-2 1/1 Running 0 13m +rd-gitops-shard1-0 1/1 Running 0 16m +rd-gitops-shard1-1 1/1 Running 0 16m +rd-gitops-shard1-2 1/1 Running 0 12m +rd-gitops-shard2-0 1/1 Running 0 16m +rd-gitops-shard2-1 1/1 Running 0 16m +rd-gitops-shard2-2 1/1 Running 0 12m +rd-gitops-shard3-0 1/1 Running 0 14m +rd-gitops-shard3-1 1/1 Running 0 14m +rd-gitops-shard3-2 1/1 Running 0 11m + +``` + +We can also scale down the replicas by updating the `replicas` fields. + +### Scale Redis Database Resources + +before Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo rd-gitops-shard0-0 -o json | jq '.spec.containers[0].resources' +{ + "requests": { + "cpu": "100m", + "memory": "100Mi" + } +} + +``` + + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 8.0.4 + mode: Cluster + cluster: + shards: 4 + replicas: 3 + storageType: Durable + storage: + resources: + requests: + storage: "1Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + podTemplate: + spec: + containers: + - name: redis + resources: + requests: + cpu: "200m" + memory: "200Mi" + deletionPolicy: WipeOut +``` + + +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `RedisOpsRequest` to update the `Redis` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 28m + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 28m + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-1nblpl HorizontalScaling Successful 26m +redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-or3shk VerticalScaling Successful 10m + +``` + + + +### Expand Redis Volume + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` RedisOpsRequest to update the `Redis` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME TYPE VERSION STATUS AGE +Redis.kubedb.com/rd-gitops kubedb.com/v1 3.9.0 Ready 23m + +NAME AGE +Redis.gitops.kubedb.com/rd-gitops 23m + +NAME TYPE STATUS AGE +Redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 19m +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=rd-gitops' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +rd-gitops-data-rd-gitops-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +rd-gitops-data-rd-gitops-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +rd-gitops-data-rd-gitops-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +rd-gitops-data-rd-gitops-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m + +``` + +## Reconfigure Redis + +At first, we will create a secret containing `user.conf` file with required configuration settings. +To know more about this configuration file, check [here](/docs/guides/Redis/configuration/Redis-combined.md) +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: new-rd-combined-custom-config + namespace: demo +stringData: + server.properties: |- + log.retention.hours=125 +``` + +Now, we will add this file to `kubedb /rd-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── rd-configuration.yaml +│ └── Redis.yaml +1 directories, 2 files +``` + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + configSecret: + name: new-rd-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` RedisOpsRequest to update the `Redis` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME TYPE VERSION STATUS AGE +Redis.kubedb.com/rd-gitops kubedb.com/v1 3.9.0 Ready 74m + +NAME AGE +Redis.gitops.kubedb.com/rd-gitops 74m + +NAME TYPE STATUS AGE +Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 24m +Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 70m + +``` + + + +> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. + +### Rotate Redis Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will create a secret named `rd-rotate-auth ` with the following content, + +```bash +kubectl create secret generic rd-rotate-auth -n demo \ +--type=kubernetes.io/basic-auth \ +--from-literal=username=Redis \ +--from-literal=password=Redis-secret +secret/rd-rotate-auth created + +``` + + + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + authSecret: + kind: Secret + name: rd-rotate-auth + configuration: + secretName: new-rd-combined-custom-config + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Change the `authSecret` field to `rd-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` RedisOpsRequest to update the `Redis` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME TYPE VERSION STATUS AGE +Redis.kubedb.com/rd-gitops kubedb.com/v1 3.9.0 Ready 7m11s + +NAME AGE +Redis.gitops.kubedb.com/rd-gitops 7m11s + +NAME TYPE STATUS AGE +Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 17h +Redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-43ris8 RotateAuth Successful 28m +Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 17h + +``` + + +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Redis. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating a ca certificates using openssl. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +Generating a RSA private key +................+++++ +........................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls Redis-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/Redis-ca created +``` + +Now, Let's create an `Issuer` using the `Redis-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: rd-issuer + namespace: demo +spec: + ca: + secretName: Redis-ca +``` + +Let's add that to our `kubedb /rd-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── rd-configuration.yaml +│ ├── rd-issuer.yaml +│ └── Redis.yaml +1 directories, 4 files +``` + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` RedisOpsRequest to update the `Redis` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,Redis,rdops,pods -n demo +NAME TYPE VERSION STATUS AGE +Redis.kubedb.com/rd-gitops kubedb.com/v1 3.9.0 Ready 41m + +NAME AGE +Redis.gitops.kubedb.com/rd-gitops 75m + +NAME TYPE STATUS AGE +Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h +Redisopsrequest.ops.kubedb.com/rd-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +Redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h +Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h + +``` + + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Redis. + +### Update Version + +List Redis versions using `kubectl get Redisversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Redis/update-version/update-version.md). + +Let's choose `4.0.0` in this example. + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` RedisOpsRequest to update the `Redis` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME TYPE VERSION STATUS AGE +Redis.kubedb.com/rd-gitops kubedb.com/v1 4.0.0 Ready 3h47m + +NAME AGE +Redis.gitops.kubedb.com/rd-gitops 3h47m + +NAME TYPE STATUS AGE +Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 5d22h +Redisopsrequest.ops.kubedb.com/rd-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +Redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-43ris8 RotateAuth Successful 5d6h +Redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-wyn2dp UpdateVersion Successful 3h51m +Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +``` + + +Now, we are going to verify whether the `Redis`, `PetSet` and it's `Pod` have updated with new image. Let's check, + +```bash +$ kubectl get Redis -n demo rd-gitops -o=jsonpath='{.spec.version}{"\n"}' +4.0.0 + +$ kubectl get petset -n demo rd-gitops-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Redis:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 + +$ kubectl get pod -n demo rd-gitops-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Redis:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +``` + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 4.0.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + controller: + podTemplate: + spec: + containers: + - name: Redis + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 2 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9091 + serviceMonitor: + labels: + release: prometheus + interval: 10s + deletionPolicy: WipeOut +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` RedisOpsRequest to add the `Redis` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get Redises.gitops.kubedb.com,Redises.kubedb.com,Redisopsrequest -n demo +NAME TYPE VERSION STATUS AGE +Redis.kubedb.com/rd-gitops kubedb.com/v1 4.0.0 Ready 5h12m + +NAME AGE +Redis.gitops.kubedb.com/rd-gitops 5h12m + +NAME TYPE STATUS AGE +Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 6d +Redisopsrequest.ops.kubedb.com/rd-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +Redisopsrequest.ops.kubedb.com/rd-gitops-restart-ljpqih Restart Successful 3m51s +Redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-43ris8 RotateAuth Successful 5d7h +Redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-wyn2dp UpdateVersion Successful 5h16m +Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 6d + +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + +## Next Steps + +[//]: # (- Learn Redis [GitOps](/docs/guides/Redis/concepts/Redis-gitops.md)) +- Learn Redis Scaling + - [Horizontal Scaling](/docs/guides/Redis/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/Redis/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/Redis/update-version/overview.md) +- Monitor your RedisQL database with KubeDB using [built-in Prometheus](/docs/guides/Redis/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/redis/gitops/overview.md b/docs/guides/redis/gitops/overview.md new file mode 100644 index 0000000000..cf959a479f --- /dev/null +++ b/docs/guides/redis/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: Kafka Gitops Overview +description: Kafka Gitops Overview +menu: + docs_{{ .version }}: + identifier: kf-gitops-overview + name: Overview + parent: kf-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for Kafka + +This guide will give you an overview of how KubeDB `gitops` operator works with Kafka databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Kafka databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [Kafka](/docs/guides/kafka/concepts/kafka.md) + - [KafkaOpsRequest](/docs/guides/kafka/concepts/kafkaopsrequest.md) + + + +## Workflow GitOps with Kafka + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + + +
+ + GitOps Flow + +
Fig: GitOps process of Kafka
+ +
+ +1. **Define GitOps Kafka**: Create Custom Resource (CR) of kind `Kafka` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Kafka CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the KafkaGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing Kafka databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running Kafka using GitOps. diff --git a/docs/guides/singlestore/configuration/config-file/index.md.bak b/docs/guides/singlestore/configuration/config-file/index.md.bak new file mode 100644 index 0000000000..5199faa008 --- /dev/null +++ b/docs/guides/singlestore/configuration/config-file/index.md.bak @@ -0,0 +1,248 @@ +--- +title: Run SingleStore with Custom Configuration +menu: + docs_{{ .version }}: + identifier: guides-sdb-configuration-using-config-file + name: Config File + parent: guides-sdb-configuration + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Using Custom Configuration File + +KubeDB supports providing custom configuration for SingleStore. This tutorial will show you how to use KubeDB to run a SingleStore database with custom configuration. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). + +- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. + + ```bash + $ kubectl create ns demo + namespace/demo created + + $ kubectl get ns demo + NAME STATUS AGE + demo Active 5s + ``` + +> Note: YAML files used in this tutorial are stored in [docs/guides/singlestore/configuration/config-file/yamls](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/guides/singlestore/configuration/config-file/yamls) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +## Overview + +SingleStore allows to configure database via configuration file. The default configuration for SingleStore can be found in `/var/lib/memsql/instance/memsql.cnf` file. When SingleStore starts, it will look for custom configuration file in `/etc/memsql/conf.d` directory. If configuration file exist, SingleStore instance will use combined startup setting from both `/var/lib/memsql/instance/memsql.cnf` and `*.cnf` files in `/etc/memsql/conf.d` directory. This custom configuration will overwrite the existing default one. To know more about configuring SingleStore see [here](https://docs.singlestore.com/db/v8.7/reference/configuration-reference/cluster-config-files/singlestore-server-config-files/). + +At first, you have to create a custom configuration file and provide its name in `spec.configuration.secretName`. The operator reads this Secret internally and applies the configuration automatically. + +In this tutorial, we will configure [max_connections](https://docs.singlestore.com/db/v8.7/reference/configuration-reference/engine-variables/list-of-engine-variables/#in-depth-variable-definitions) and [read_buffer_size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_read_buffer_size) via a custom config file. We will use configMap as volume source. + +## Create SingleStore License Secret + +We need SingleStore License to create SingleStore Database. So, Ensure that you have acquired a license and then simply pass the license by secret. + +```bash +$ kubectl create secret generic -n demo license-secret \ + --from-literal=username=license \ + --from-literal=password='your-license-set-here' +secret/license-secret created +``` + +## Custom Configuration + +At first, let's create `sdb-config.cnf` file setting `max_connections` and `read_buffer_size` parameters. + +```bash +cat < sdb-config.cnf +[server] +max_connections = 250 +read_buffer_size = 1048576 +EOF + +$ cat sdb-config.cnf +[server] +max_connections = 250 +read_buffer_size = 122880 +``` + +Now, create a secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo sdb-configuration --from-file=./sdb-config.cnf +configmap/sdb-configuration created +``` + +Verify the secret has the configuration file. + +```yaml +$ kubectl get secret -n demo sdb-configuration -o yaml +apiVersion: v1 +data: + sdb-config.cnf: W3NlcnZlcl0KbWF4X2Nvbm5lY3Rpb25zID0gMjUwCnJlYWRfYnVmZmVyX3NpemUgPSAxMjI4ODAK +kind: Secret +metadata: + creationTimestamp: "2024-10-02T12:54:35Z" + name: sdb-configuration + namespace: demo + resourceVersion: "99627" + uid: c2621d8e-ebca-4300-af05-0180512ce031 +type: Opaque + + +``` + +Now, create SingleStore crd specifying `spec.topology.aggregator.configSecret` and `spec.topology.leaf.configSecret` field. + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/singlestore/configuration/config-file/yamls/sdb-custom.yaml +singlestore.kubedb.com/custom-sdb created +``` + +Below is the YAML for the SingleStore crd we just created. + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: Singlestore +metadata: + name: custom-sdb + namespace: demo +spec: + version: "8.7.10" + topology: + aggregator: + replicas: 2 + configuration: + secretName: sdb-configuration + podTemplate: + spec: + containers: + - name: singlestore + resources: + limits: + memory: "2Gi" + cpu: "600m" + requests: + memory: "2Gi" + cpu: "600m" + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + leaf: + replicas: 2 + configuration: + secretName: sdb-configuration + podTemplate: + spec: + containers: + - name: singlestore + resources: + limits: + memory: "2Gi" + cpu: "600m" + requests: + memory: "2Gi" + cpu: "600m" + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi + licenseSecret: + kind: Secret + name: license-secret + storageType: Durable + deletionPolicy: WipeOut +``` + +Now, wait a few minutes. KubeDB operator will create necessary PVC, petset, services, secret etc. + +Check that the petset's pod is running + +```bash +$ kubectl get pod -n demo +NAME READY STATUS RESTARTS AGE +custom-sdb-aggregator-0 2/2 Running 0 94s +custom-sdb-aggregator-1 2/2 Running 0 88s +custom-sdb-leaf-0 2/2 Running 0 91s +custom-sdb-leaf-1 2/2 Running 0 86s + +$ kubectl get sdb -n demo +NAME TYPE VERSION STATUS AGE +custom-sdb kubedb.com/v1alpha2 8.7.10 Ready 4m29s + +``` + +We can see the database is in ready phase so it can accept conncetion. + +Now, we will check if the database has started with the custom configuration we have provided. + +> Read the comment written for the following commands. They contain the instructions and explanations of the commands. + +```bash +# Connceting to the database +$ kubectl exec -it -n demo custom-sdb-aggregator-0 -- bash +Defaulted container "singlestore" out of: singlestore, singlestore-coordinator, singlestore-init (init) +[memsql@custom-sdb-aggregator-0 /]$ memsql -uroot -p$ROOT_PASSWORD +singlestore-client: [Warning] Using a password on the command line interface can be insecure. +Welcome to the MySQL monitor. Commands end with ; or \g. +Your MySQL connection id is 208 +Server version: 5.7.32 SingleStoreDB source distribution (compatible; MySQL Enterprise & MySQL Commercial) + +Copyright (c) 2000, 2022, Oracle and/or its affiliates. + +Oracle is a registered trademark of Oracle Corporation and/or its +affiliates. Other names may be trademarks of their respective +owners. + +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. + +# value of `max_conncetions` is same as provided +singlestore> show variables like 'max_connections'; ++-----------------+-------+ +| Variable_name | Value | ++-----------------+-------+ +| max_connections | 250 | ++-----------------+-------+ +1 row in set (0.00 sec) + +# value of `read_buffer_size` is same as provided +singlestore> show variables like 'read_buffer_size'; ++------------------+--------+ +| Variable_name | Value | ++------------------+--------+ +| read_buffer_size | 122880 | ++------------------+--------+ +1 row in set (0.00 sec) + +singlestore> exit +Bye + +``` +## Cleaning up + +To cleanup the Kubernetes resources created by this tutorial, run: + +```bash +kubectl patch -n demo my/custom-sdb -p '{"spec":{"deletionPolicy":"WipeOut"}}' --type="merge" +kubectl delete -n demo my/custom-sdb +kubectl delete ns demo +``` + +If you would like to uninstall KubeDB operator, please follow the steps [here](/docs/setup/README.md). + +## Next Steps +- [Quickstart SingleStore](/docs/guides/singlestore/quickstart/quickstart.md) with KubeDB Operator. +- Detail concepts of [singlestore object](/docs/guides/singlestore/concepts/singlestore.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). From 114f857a85ff500cd9627cbaedb52d534366d0f4 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 24 Feb 2026 12:11:58 +0600 Subject: [PATCH 09/51] maria Signed-off-by: Bonusree --- .../reconfigure_tls/elasticsearch.md | 2 +- docs/guides/mariadb/gitops/gitops.md | 164 +++++---------- .../using-config-file.md.bak | 182 +++++++++++++++++ .../using-config-file/index.md.bak | 193 ++++++++++++++++++ 4 files changed, 432 insertions(+), 109 deletions(-) create mode 100644 docs/guides/memcached/custom-configuration/using-config-file.md.bak create mode 100644 docs/guides/percona-xtradb/configuration/using-config-file/index.md.bak diff --git a/docs/guides/elasticsearch/reconfigure_tls/elasticsearch.md b/docs/guides/elasticsearch/reconfigure_tls/elasticsearch.md index 73298cadb0..79a26ce00e 100644 --- a/docs/guides/elasticsearch/reconfigure_tls/elasticsearch.md +++ b/docs/guides/elasticsearch/reconfigure_tls/elasticsearch.md @@ -140,7 +140,7 @@ spec: Let's apply the `YAML` file: ```bash -$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/elasticsearch/reconfigure-tls/Elasticsearch-issuer.yaml +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/elasticsearch/reconficure-tls/Elasticsearch-issuer.yaml issuer.cert-manager.io/es-issuer created ``` diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index ec2fdd8f51..8d9125eea3 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -67,6 +67,7 @@ metadata: namespace: demo spec: version: "10.5.23" + replicas: 3 storageType: Durable storage: storageClassName: longhorn @@ -145,50 +146,30 @@ Update the `MariaDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MariaDB metadata: - name: MariaDB-prod + name: mariadb-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path - controller: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: "10.5.23" + replicas: 5 + storageType: Durable + podTemplate: + spec: + containers: + - name: mariadb resources: + limits: + cpu: 500m + memory: 1.2Gi requests: - storage: 1Gi - storageClassName: local-path - storageType: Durable + cpu: 100m + memory: 1.2Gi + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi deletionPolicy: WipeOut ``` @@ -197,29 +178,31 @@ Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit Now, `gitops` operator will detect the resource changes and create a `MariaDBOpsRequest` to update the `MariaDB` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ $ kubectl get kf,MariaDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 22h +$ kubectl get md,mariadbopsrequest -n demo +NAME VERSION STATUS AGE +mariadb.kubedb.com/mariadb-gitops 10.5.23 Ready 39m -NAME AGE -MariaDB.gitops.kubedb.com/MariaDB-prod 22h +NAME TYPE STATUS AGE +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-g0l4rg HorizontalScaling Successful 22m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-umbwjh VerticalScaling Successful 8m16s -NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo MariaDB-prod-broker-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[0].resources' { "limits": { - "memory": "1536Mi" + "cpu": "500m", + "memory": "1288490188800m" }, "requests": { - "cpu": "500m", - "memory": "1536Mi" + "cpu": "100m", + "memory": "1288490188800m" } } + + ``` ### Scale MariaDB Replicas @@ -228,50 +211,19 @@ Update the `MariaDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MariaDB metadata: - name: MariaDB-prod + name: mariadb-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 3 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path - controller: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 3 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path + version: "10.5.23" + replicas: 5 storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi deletionPolicy: WipeOut ``` @@ -279,28 +231,24 @@ Update the `replicas` to `3`. Commit the changes and push to your Git repository Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` MariaDBOpsRequest to update the `MariaDB` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MariaDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 22h +$ kubectl get md,mariadbopsrequest -n demo +NAME VERSION STATUS AGE +mariadb.kubedb.com/mariadb-gitops 10.5.23 Ready 26m -NAME AGE -MariaDB.gitops.kubedb.com/MariaDB-prod 22h +NAME TYPE STATUS AGE +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-g0l4rg HorizontalScaling Successful 9m2s -NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=MariaDB-prod' -NAME READY STATUS RESTARTS AGE -MariaDB-prod-broker-0 1/1 Running 0 34m -MariaDB-prod-broker-1 1/1 Running 0 33m -MariaDB-prod-broker-2 1/1 Running 0 33m -MariaDB-prod-controller-0 1/1 Running 0 32m -MariaDB-prod-controller-1 1/1 Running 0 31m -MariaDB-prod-controller-2 1/1 Running 0 31m +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=mariadb-gitops' +NAME READY STATUS RESTARTS AGE +mariadb-gitops-0 2/2 Running 0 26m +mariadb-gitops-1 2/2 Running 0 26m +mariadb-gitops-2 2/2 Running 0 26m +mariadb-gitops-3 2/2 Running 0 9m29s +mariadb-gitops-4 2/2 Running 0 8m29s ``` We can also scale down the replicas by updating the `replicas` fields. diff --git a/docs/guides/memcached/custom-configuration/using-config-file.md.bak b/docs/guides/memcached/custom-configuration/using-config-file.md.bak new file mode 100644 index 0000000000..5f1387bd23 --- /dev/null +++ b/docs/guides/memcached/custom-configuration/using-config-file.md.bak @@ -0,0 +1,182 @@ +--- +title: Run Memcached with Custom Configuration +menu: + docs_{{ .version }}: + identifier: mc-using-config-file-configuration + name: Customize Configurations + parent: custom-configuration + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Using Custom Configuration File + +KubeDB supports providing custom configuration for Memcached. This tutorial will show you how to use KubeDB to run Memcached with custom configuration. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). + +- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. + + ```bash + $ kubectl create ns demo + namespace/demo created + + $ kubectl get ns demo + NAME STATUS AGE + demo Active 5s + ``` + +> Note: YAML files used in this tutorial are stored in [docs/examples/memcached](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/memcached) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +## Overview + +Memcached does not allows to configuration via any file. However, configuration parameters can be set as arguments while starting the memcached docker image. To keep similarity with other KubeDB supported databases which support configuration through a config file, KubeDB has added an additional executable script on top of the official memcached docker image. This script parses the configuration file then set them as arguments of memcached binary. + +To know more about configuring Memcached server see [here](https://github.com/memcached/memcached/wiki/ConfiguringServer). + +At first, you have to create a custom configuration file and provide its name in `spec.configuration.secretName`. The operator reads this Secret internally and applies the configuration automatically. + +In this tutorial, we will configure [max_connections](https://github.com/memcached/memcached/blob/ee171109b3afe1f30ff053166d205768ce635342/doc/protocol.txt#L672) and [limit_maxbytes](https://github.com/memcached/memcached/blob/ee171109b3afe1f30ff053166d205768ce635342/doc/protocol.txt#L720) via secret. + +Create a secret with custom configuration file: +```yaml +apiVersion: v1 +stringData: + memcached.conf: | + --conn-limit=500 + --memory-limit=128 +kind: Secret +metadata: + name: mc-configuration + namespace: demo + resourceVersion: "4505" +``` +Here, --con-limit means max simultaneous connections which is default value is 1024. +and --memory-limit means item memory in megabytes which default value is 64. + +```bash + $ kubectl apply -f mc-configuration.yaml +secret/mc-configuration created +``` + +Let's get the mc-configuration `secret` with custom configuration: + +```yaml +$ kubectl get secret -n demo mc-configuration -o yaml +apiVersion: v1 +data: + memcached.conf: LS1jb25uLWxpbWl0PTUwMAotLW1lbW9yeS1saW1pdD01MTIK +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{},"name":"mc-configuration","namespace":"demo","resourceVersion":"4505"},"stringData":{"memcached.conf":"--conn-limit=500\n--memory-limit=512\n"}} + creationTimestamp: "2024-08-26T12:19:54Z" + name: mc-configuration + namespace: demo + resourceVersion: "4580860" + uid: 02d41fc0-590e-44d1-ae95-2ee8f9632d36 +type: Opaque +``` + +Now, create Memcached crd specifying `spec.configuration.secretName` field. + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/memcached/configuration/mc-custom.yaml +memcached.kubedb.com/custom-memcached created +``` + +Below is the YAML for the Memcached crd we just created. + +```yaml +apiVersion: kubedb.com/v1 +kind: Memcached +metadata: + name: custom-memcached + namespace: demo +spec: + replicas: 1 + version: "1.6.22" + configuration: + secretName: mc-configuration + podTemplate: + spec: + containers: + - name: memcached + resources: + limits: + cpu: 500m + memory: 128Mi + requests: + cpu: 250m + memory: 64Mi + deletionPolicy: WipeOut +``` + +Now, wait a few minutes. KubeDB operator will create necessary petset, services etc. If everything goes well, we will see that a pod with the name `custom-memcached-0` has been created. + +Check if the database is ready + +```bash +$ kubectl get mc -n demo +NAME VERSION STATUS AGE +custom-memcached 1.6.22 Ready 17m +``` + +Now, we will check if the database has started with the custom configuration we have provided. We will use [stats](https://github.com/memcached/memcached/wiki/ConfiguringServer#inspecting-running-configuration) command to check the configuration. + +We will connect to `custom-memcached-0` pod from local-machine using port-frowarding. + +```bash +$ kubectl port-forward -n demo custom-memcached-0 11211 +Forwarding from 127.0.0.1:11211 -> 11211 +Forwarding from [::1]:11211 -> 11211 +``` + +Now, connect to the memcached server from a different terminal through `telnet`. + +```bash +$ telnet 127.0.0.1 11211 +Trying 127.0.0.1... +Connected to 127.0.0.1. +Escape character is '^]'. +stats +... +STAT max_connections 500 +... +STAT limit_maxbytes 134217728 +... +END +``` + +Here, `limit_maxbytes` is represented in bytes. + +## Cleaning up + +To cleanup the Kubernetes resources created by this tutorial, run: + +```bash +kubectl patch -n demo mc/custom-memcached -p '{"spec":{"deletionPolicy":"WipeOut"}}' --type="merge" +kubectl delete -n demo mc/custom-memcached + +kubectl patch -n demo drmn/custom-memcached -p '{"spec":{"wipeOut":true}}' --type="merge" +kubectl delete -n demo drmn/custom-memcached + +kubectl delete -n demo secret mc-configuration + +kubectl delete ns demo +``` + +If you would like to uninstall KubeDB operator, please follow the steps [here](/docs/setup/README.md). + +## Next Steps + +- Learn how to use KubeDB to run a Memcached server [here](/docs/guides/memcached/README.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/percona-xtradb/configuration/using-config-file/index.md.bak b/docs/guides/percona-xtradb/configuration/using-config-file/index.md.bak new file mode 100644 index 0000000000..0f1d95a8e6 --- /dev/null +++ b/docs/guides/percona-xtradb/configuration/using-config-file/index.md.bak @@ -0,0 +1,193 @@ +--- +title: Run PerconaXtraDB with Custom Configuration +menu: + docs_{{ .version }}: + identifier: guides-perconaxtradb-configuration-usingconfigfile + name: Config File + parent: guides-perconaxtradb-configuration + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Using Custom Configuration File + +KubeDB supports providing custom configuration for PerconaXtraDB. This tutorial will show you how to use KubeDB to run a PerconaXtraDB database with custom configuration. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). + +- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. + + ```bash + $ kubectl create ns demo + namespace/demo created + + $ kubectl get ns demo + NAME STATUS AGE + demo Active 5s + ``` + +> Note: YAML files used in this tutorial are stored in [here](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/guides/percona-xtradb/configuration/using-config-file/examples) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +## Overview + +PerconaXtraDB allows to configure database via configuration file. The default configuration for PerconaXtraDB can be found in `/etc/my.cnf` file. KubeDB adds a new custom configuration directory `/etc/mysql/custom.conf.d` if it's enabled. When PerconaXtraDB starts, it will look for custom configuration file in `/etc/mysql/custom.conf.d` directory. If configuration file exist, PerconaXtraDB instance will use combined startup setting from both `/etc/my.cnf` and `*.cnf` files in `/etc/mysql/conf.d` and `/etc/mysql/custom.conf.d` directory. This custom configuration will overwrite the existing default one. + +At first, you have to create a custom configuration file and provide its name in `spec.configuration.secretName`. The operator reads this Secret internally and applies the configuration automatically. + +In this tutorial, we will configure [max_connections](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_connections/) and [read_buffer_size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_read_buffer_size) via a custom config file. We will use Secret. + +## Custom Configuration + +At first, let's create `px-config.cnf` file setting `max_connections` and `read_buffer_size` parameters. + +```bash +cat < px-config.cnf +[mysqld] +max_connections = 200 +read_buffer_size = 1048576 +EOF + +$ cat px-config.cnf +[mysqld] +max_connections = 200 +read_buffer_size = 1048576 +``` + +Here, `read_buffer_size` is set to 1MB in bytes. + +Now, create a Secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo px-configuration --from-file=./px-config.cnf +secret/md-configuration created +``` + +Verify the Secret has the configuration file. + +```bash +$ kubectl get secret -n demo px-configuration -o yaml +apiVersion: v1 +stringData: + px-config.cnf: | + [mysqld] + max_connections = 200 + read_buffer_size = 1048576 +kind: Secret +metadata: + name: px-configuration + namespace: demo + ... +``` + +Now, create PerconaXtraDB crd specifying `spec.configuration.secretName` field. + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/percona-xtradb/configuration/using-config-file/examples/px-custom.yaml +mysql.kubedb.com/custom-mysql created +``` + +Below is the YAML for the PerconaXtraDB crd we just created. + +```yaml +apiVersion: kubedb.com/v1 +kind: PerconaXtraDB +metadata: + name: sample-pxc + namespace: demo +spec: + version: "8.0.40" + configuration: + secretName: px-configuration + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut + +``` + +Now, wait a few minutes. KubeDB operator will create necessary PVC, petset, services, secret etc. If everything goes well, we will see that a pod with the name `sample-pxc-0` has been created. + +Check that the petset's pod is running + +```bash +$ kubectl get pod -n demo +NAME READY STATUS RESTARTS AGE +sample-pxc-0 2/2 Running 0 75m +sample-pxc-1 2/2 Running 0 95m +sample-pxc-2 2/2 Running 0 95m + +$ kubectl get perconaxtradb -n demo +NAME VERSION STATUS AGE +NAME VERSION STATUS AGE +sample-pxc 8.0.40 Ready 96m +``` + +We can see the database is in ready phase so it can accept connection. + +Now, we will check if the database has started with the custom configuration we have provided. + +> Read the comment written for the following commands. They contain the instructions and explanations of the commands. + +```bash +# Connecting to the database +$ kubectl exec -it -n demo sample-pxc-0 -- bash +Defaulted container "perconaxtradb" out of: perconaxtradb, px-coordinator, px-init (init) +bash-4.4$ mysql -u${MYSQL_ROOT_USERNAME} -p${MYSQL_ROOT_PASSWORD} +mysql: [Warning] Using a password on the command line interface can be insecure. +Welcome to the MySQL monitor. Commands end with ; or \g. +Your MySQL connection id is 1390 +Server version: 8.0.40-16.1 Percona XtraDB Cluster (GPL), Release rel16, Revision b141904, WSREP version 26.4.3 + +Copyright (c) 2009-2021 Percona LLC and/or its affiliates +Copyright (c) 2000, 2021, Oracle and/or its affiliates. + +Oracle is a registered trademark of Oracle Corporation and/or its +affiliates. Other names may be trademarks of their respective +owners. + +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. + +mysql> show variables like 'max_connections'; ++-----------------+-------+ +| Variable_name | Value | ++-----------------+-------+ +| max_connections | 200 | ++-----------------+-------+ +1 row in set (0.01 sec) + + +# value of `read_buffer_size` is same as provided +mysql> show variables like 'read_buffer_size'; ++------------------+---------+ +| Variable_name | Value | ++------------------+---------+ +| read_buffer_size | 1048576 | ++------------------+---------+ +1 row in set (0.001 sec) + +mysql> exit +Bye +``` + +## Cleaning up + +To cleanup the Kubernetes resources created by this tutorial, run: + +```bash +$ kubectl delete perconaxtradb -n demo sample-pxc +perconaxtradb.kubedb.com "sample-pxc" deleted +$ kubectl delete ns demo +namespace "demo" deleted +``` From 1c957fadc94daede69ea6b2986d46f881e1443ea Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 3 Mar 2026 17:24:20 +0600 Subject: [PATCH 10/51] mssql some changes Signed-off-by: Bonusree --- docs/guides/mssqlserver/gitops/gitops.md | 346 +++++++++++----------- docs/guides/mysql/rotate-auth/overview.md | 2 +- 2 files changed, 174 insertions(+), 174 deletions(-) diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md index 332c4f29d9..0e940cbe7f 100644 --- a/docs/guides/mssqlserver/gitops/gitops.md +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -1,6 +1,6 @@ --- -title: Elasticsearch Gitops Overview -description: Elasticsearch Gitops Overview +title: Mssqlserver Gitops Overview +description: Mssqlserver Gitops Overview menu: docs_{{ .version }}: identifier: es-gitops-overview @@ -15,9 +15,9 @@ section_menu_id: guides > New to KubeDB? Please start [here](/docs/README.md). -# GitOps Elasticsearch using KubeDB GitOps Operator +# GitOps Mssqlserver using KubeDB GitOps Operator -This guide will show you how to use `KubeDB` GitOps operator to create Elasticsearch database and manage updates using GitOps workflow. +This guide will show you how to use `KubeDB` GitOps operator to create Mssqlserver database and manage updates using GitOps workflow. ## Before You Begin @@ -34,7 +34,7 @@ This guide will show you how to use `KubeDB` GitOps operator to create Elasticse $ kubectl create ns demo namespace/demo created ``` -> Note: YAML files used in this tutorial are stored in [docs/examples/Elasticsearch](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/Elasticsearch) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). +> Note: YAML files used in this tutorial are stored in [docs/examples/Mssqlserver](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/Mssqlserver) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). @@ -56,12 +56,12 @@ argocd app create kubedb --repo --path kubedb --dest-server https://k argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa ``` -## Create Elasticsearch Database using GitOps +## Create Mssqlserver Database using GitOps -### Create a Elasticsearch GitOps CR +### Create a Mssqlserver GitOps CR ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: Mssqlserver metadata: name: es-gitops namespace: demo @@ -84,58 +84,58 @@ Create a directory like below, ```bash $ tree . ├── kubedb - └── Elasticsearch.yaml + └── Mssqlserver.yaml 1 directories, 1 files ``` -Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is created in your cluster. +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is created in your cluster. -Our `gitops` operator will create an actual `Elasticsearch` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. +Our `gitops` operator will create an actual `Mssqlserver` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get Elasticsearch.gitops.kubedb.com,Elasticsearch.kubedb.com -n demo +$ kubectl get Mssqlserver.gitops.kubedb.com,Mssqlserver.kubedb.com -n demo NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 2m56s +Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 2m56s NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 2m56s +Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 2m56s ``` -List the resources created by `kubedb` operator created for `kubedb.com/v1` Elasticsearch. +List the resources created by `kubedb` operator created for `kubedb.com/v1` Mssqlserver. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=Mssqlserver-prod' NAME AGE -petset.apps.k8s.appscode.com/Elasticsearch-prod-broker 4m49s -petset.apps.k8s.appscode.com/Elasticsearch-prod-controller 4m47s +petset.apps.k8s.appscode.com/Mssqlserver-prod-broker 4m49s +petset.apps.k8s.appscode.com/Mssqlserver-prod-controller 4m47s NAME READY STATUS RESTARTS AGE -pod/Elasticsearch-prod-broker-0 1/1 Running 0 4m48s -pod/Elasticsearch-prod-broker-1 1/1 Running 0 4m42s -pod/Elasticsearch-prod-controller-0 1/1 Running 0 4m47s -pod/Elasticsearch-prod-controller-1 1/1 Running 0 4m40s +pod/Mssqlserver-prod-broker-0 1/1 Running 0 4m48s +pod/Mssqlserver-prod-broker-1 1/1 Running 0 4m42s +pod/Mssqlserver-prod-controller-0 1/1 Running 0 4m47s +pod/Mssqlserver-prod-controller-1 1/1 Running 0 4m40s NAME TYPE DATA AGE -secret/Elasticsearch-prod-auth kubernetes.io/basic-auth 2 4m51s +secret/Mssqlserver-prod-auth kubernetes.io/basic-auth 2 4m51s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/Elasticsearch-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s +service/Mssqlserver-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/Elasticsearch-prod kubedb.com/Elasticsearch 3.9.0 4m47s +appbinding.appcatalog.appscode.com/Mssqlserver-prod kubedb.com/Mssqlserver 3.9.0 4m47s ``` -## Update Elasticsearch Database using GitOps +## Update Mssqlserver Database using GitOps -### Scale Elasticsearch Database Resources +### Scale Mssqlserver Database Resources -Update the `Elasticsearch.yaml` with the following, +Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: Mssqlserver metadata: - name: Elasticsearch-prod + name: Mssqlserver-prod namespace: demo spec: version: 3.9.0 @@ -144,7 +144,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1540Mi @@ -163,7 +163,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1540Mi @@ -182,25 +182,25 @@ spec: deletionPolicy: WipeOut ``` -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Elasticsearch` database. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Mssqlserver` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ $ kubectl get kf,Elasticsearch,kfops -n demo +$ $ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 22h +Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 22h NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 22h +Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 22h NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo Mssqlserver-prod-broker-0 -o json | jq '.spec.containers[0].resources' { "limits": { "memory": "1536Mi" @@ -212,13 +212,13 @@ $ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o json | jq '.spec.contai } ``` -### Scale Elasticsearch Replicas -Update the `Elasticsearch.yaml` with the following, +### Scale Mssqlserver Replicas +Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: Mssqlserver metadata: - name: Elasticsearch-prod + name: Mssqlserver-prod namespace: demo spec: version: 3.9.0 @@ -227,7 +227,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1540Mi @@ -246,7 +246,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1540Mi @@ -265,44 +265,44 @@ spec: deletionPolicy: WipeOut ``` -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Elasticsearch` database replicas. List the resources created by `gitops` operator in the `demo` namespace. +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Mssqlserver` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 22h +Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 22h NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 22h +Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 22h NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=Mssqlserver-prod' NAME READY STATUS RESTARTS AGE -Elasticsearch-prod-broker-0 1/1 Running 0 34m -Elasticsearch-prod-broker-1 1/1 Running 0 33m -Elasticsearch-prod-broker-2 1/1 Running 0 33m -Elasticsearch-prod-controller-0 1/1 Running 0 32m -Elasticsearch-prod-controller-1 1/1 Running 0 31m -Elasticsearch-prod-controller-2 1/1 Running 0 31m +Mssqlserver-prod-broker-0 1/1 Running 0 34m +Mssqlserver-prod-broker-1 1/1 Running 0 33m +Mssqlserver-prod-broker-2 1/1 Running 0 33m +Mssqlserver-prod-controller-0 1/1 Running 0 32m +Mssqlserver-prod-controller-1 1/1 Running 0 31m +Mssqlserver-prod-controller-2 1/1 Running 0 31m ``` We can also scale down the replicas by updating the `replicas` fields. -### Expand Elasticsearch Volume +### Expand Mssqlserver Volume -Update the `Elasticsearch.yaml` with the following, +Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: Mssqlserver metadata: - name: Elasticsearch-prod + name: Mssqlserver-prod namespace: demo spec: version: 3.9.0 @@ -311,7 +311,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -330,7 +330,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -349,39 +349,39 @@ spec: deletionPolicy: WipeOut ``` -Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `Elasticsearch` database volume. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `Mssqlserver` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 23m +Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 23m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 23m +Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 23m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=Mssqlserver-prod' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -Elasticsearch-prod-data-Elasticsearch-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -Elasticsearch-prod-data-Elasticsearch-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -Elasticsearch-prod-data-Elasticsearch-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -Elasticsearch-prod-data-Elasticsearch-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m +Mssqlserver-prod-data-Mssqlserver-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +Mssqlserver-prod-data-Mssqlserver-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +Mssqlserver-prod-data-Mssqlserver-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +Mssqlserver-prod-data-Mssqlserver-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m ``` -## Reconfigure Elasticsearch +## Reconfigure Mssqlserver At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/Elasticsearch/configuration/Elasticsearch-combined.md) +To know more about this configuration file, check [here](/docs/guides/Mssqlserver/configuration/Mssqlserver-combined.md) ```yaml apiVersion: v1 kind: Secret @@ -399,16 +399,16 @@ Now, we will add this file to `kubedb /kf-configuration.yaml`. $ tree . ├── kubedb │ ├── kf-configuration.yaml -│ └── Elasticsearch.yaml +│ └── Mssqlserver.yaml 1 directories, 2 files ``` -Update the `Elasticsearch.yaml` with the following, +Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: Mssqlserver metadata: - name: Elasticsearch-prod + name: Mssqlserver-prod namespace: demo spec: configSecret: @@ -419,7 +419,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -438,7 +438,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -457,21 +457,21 @@ spec: deletionPolicy: WipeOut ``` -Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `Elasticsearch` database configuration. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `Mssqlserver` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 74m +Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 74m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 74m +Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 74m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 24m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 24m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m ``` @@ -479,7 +479,7 @@ Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr > We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. -### Rotate Elasticsearch Auth +### Rotate Mssqlserver Auth To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. @@ -488,20 +488,20 @@ We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the fo ```bash kubectl create secret generic kf-rotate-auth -n demo \ --type=kubernetes.io/basic-auth \ ---from-literal=username=Elasticsearch \ ---from-literal=password=Elasticsearch-secret +--from-literal=username=Mssqlserver \ +--from-literal=password=Mssqlserver-secret secret/kf-rotate-auth created ``` -Update the `Elasticsearch.yaml` with the following, +Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: Mssqlserver metadata: - name: Elasticsearch-prod + name: Mssqlserver-prod namespace: demo spec: authSecret: @@ -515,7 +515,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -534,7 +534,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -553,22 +553,22 @@ spec: deletionPolicy: WipeOut ``` -Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `Elasticsearch` database auth. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `Mssqlserver` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 7m11s +Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 7m11s NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 7m11s +Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 7m11s NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 17h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 28m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 17h +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-rotate-auth-43ris8 RotateAuth Successful 28m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h ``` @@ -577,7 +577,7 @@ Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr We can add, rotate or remove TLS configuration using `gitops`. -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Elasticsearch. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Mssqlserver. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. - Start off by generating a ca certificates using openssl. @@ -593,14 +593,14 @@ writing new private key to './ca.key' - Now we are going to create a ca-secret using the certificate files that we have just generated. ```bash -$ kubectl create secret tls Elasticsearch-ca \ +$ kubectl create secret tls Mssqlserver-ca \ --cert=ca.crt \ --key=ca.key \ --namespace=demo -secret/Elasticsearch-ca created +secret/Mssqlserver-ca created ``` -Now, Let's create an `Issuer` using the `Elasticsearch-ca` secret that we have just created. The `YAML` file looks like this: +Now, Let's create an `Issuer` using the `Mssqlserver-ca` secret that we have just created. The `YAML` file looks like this: ```yaml apiVersion: cert-manager.io/v1 @@ -610,7 +610,7 @@ metadata: namespace: demo spec: ca: - secretName: Elasticsearch-ca + secretName: Mssqlserver-ca ``` Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, @@ -619,16 +619,16 @@ $ tree . ├── kubedb │ ├── kf-configuration.yaml │ ├── kf-issuer.yaml -│ └── Elasticsearch.yaml +│ └── Mssqlserver.yaml 1 directories, 4 files ``` -Update the `Elasticsearch.yaml` with the following, +Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: Mssqlserver metadata: - name: Elasticsearch-prod + name: Mssqlserver-prod namespace: demo spec: version: 3.9.0 @@ -637,7 +637,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -656,7 +656,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -675,41 +675,41 @@ spec: deletionPolicy: WipeOut ``` -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Elasticsearch` database tls. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Mssqlserver` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops,pods -n demo +$ kubectl get kf,Mssqlserver,kfops,pods -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 41m +Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 41m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 75m +Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 75m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 5d18h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 5d18h +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h ``` -> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Elasticsearch. +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Mssqlserver. ### Update Version -List Elasticsearch versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Elasticsearch/update-version/update-version.md). +List Mssqlserver versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Mssqlserver/update-version/update-version.md). Let's choose `4.0.0` in this example. -Update the `Elasticsearch.yaml` with the following, +Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: Mssqlserver metadata: - name: Elasticsearch-prod + name: Mssqlserver-prod namespace: demo spec: version: 4.0.0 @@ -718,7 +718,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -737,7 +737,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -756,50 +756,50 @@ spec: deletionPolicy: WipeOut ``` -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Elasticsearch` database version. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Mssqlserver` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 4.0.0 Ready 3h47m +Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 4.0.0 Ready 3h47m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 3h47m +Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 3h47m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 5d22h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 5d22h +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h ``` -Now, we are going to verify whether the `Elasticsearch`, `PetSet` and it's `Pod` have updated with new image. Let's check, +Now, we are going to verify whether the `Mssqlserver`, `PetSet` and it's `Pod` have updated with new image. Let's check, ```bash -$ kubectl get Elasticsearch -n demo Elasticsearch-prod -o=jsonpath='{.spec.version}{"\n"}' +$ kubectl get Mssqlserver -n demo Mssqlserver-prod -o=jsonpath='{.spec.version}{"\n"}' 4.0.0 -$ kubectl get petset -n demo Elasticsearch-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Elasticsearch:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get petset -n demo Mssqlserver-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Mssqlserver:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 -$ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Elasticsearch:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get pod -n demo Mssqlserver-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/Mssqlserver:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 ``` ### Enable Monitoring If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). -Update the `Elasticsearch.yaml` with the following, +Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: Mssqlserver metadata: - name: Elasticsearch-prod + name: Mssqlserver-prod namespace: demo spec: version: 4.0.0 @@ -808,7 +808,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -827,7 +827,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: Mssqlserver resources: limits: memory: 1536Mi @@ -855,24 +855,24 @@ spec: deletionPolicy: WipeOut ``` -Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Elasticsearch` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Mssqlserver` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 4.0.0 Ready 5h12m +Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 4.0.0 Ready 5h12m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 5h12m +Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 5h12m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 6d -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-restart-ljpqih Restart Successful 3m51s -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 6d +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-restart-ljpqih Restart Successful 3m51s +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m +Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d ``` @@ -891,10 +891,10 @@ There are some other fields that will trigger `Restart` ops request. ## Next Steps -[//]: # (- Learn Elasticsearch [GitOps](/docs/guides/Elasticsearch/concepts/Elasticsearch-gitops.md)) -- Learn Elasticsearch Scaling - - [Horizontal Scaling](/docs/guides/Elasticsearch/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/Elasticsearch/scaling/vertical-scaling/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/Elasticsearch/update-version/overview.md) -- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/Elasticsearch/monitoring/using-builtin-prometheus.md). +[//]: # (- Learn Mssqlserver [GitOps](/docs/guides/Mssqlserver/concepts/Mssqlserver-gitops.md)) +- Learn Mssqlserver Scaling + - [Horizontal Scaling](/docs/guides/Mssqlserver/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/Mssqlserver/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/Mssqlserver/update-version/overview.md) +- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/Mssqlserver/monitoring/using-builtin-prometheus.md). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mysql/rotate-auth/overview.md b/docs/guides/mysql/rotate-auth/overview.md index 51fd224097..37e6392a9e 100644 --- a/docs/guides/mysql/rotate-auth/overview.md +++ b/docs/guides/mysql/rotate-auth/overview.md @@ -4,7 +4,7 @@ menu: docs_{{ .version }}: identifier: guides-mysql-rotate-auth-overview name: Overview - parent: ms-rotate-auth + parent: guides-mysql-rotate-auth weight: 5 menu_name: docs_{{ .version }} section_menu_id: guides From cf73124cede2149f4c08a895a5c32826c2cc9650 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Thu, 12 Mar 2026 10:24:45 +0600 Subject: [PATCH 11/51] csi add Signed-off-by: Bonusree --- docs/guides/mssqlserver/gitops/gitops.md | 5 +++-- docs/guides/mssqlserver/reconfigure-tls/ag_cluster.md | 3 +++ docs/guides/mssqlserver/reconfigure-tls/standalone.md | 2 ++ 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md index 0e940cbe7f..87cb73f1db 100644 --- a/docs/guides/mssqlserver/gitops/gitops.md +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -187,7 +187,7 @@ Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Mssqlserver` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ $ kubectl get kf,Mssqlserver,kfops -n demo +$ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 22h @@ -577,7 +577,8 @@ Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr We can add, rotate or remove TLS configuration using `gitops`. -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Mssqlserver. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Mssqlserver. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. As well as we need to install [csi-driver-cacerts](https://github.com/kubeops/csi-driver-cacerts) which will be used to add self-signed ca certificates to the OS trusted certificate store (eg, /etc/ssl/certs/ca-certificates.crt) + - Start off by generating a ca certificates using openssl. diff --git a/docs/guides/mssqlserver/reconfigure-tls/ag_cluster.md b/docs/guides/mssqlserver/reconfigure-tls/ag_cluster.md index 7a17b63d4c..c5cf3af715 100644 --- a/docs/guides/mssqlserver/reconfigure-tls/ag_cluster.md +++ b/docs/guides/mssqlserver/reconfigure-tls/ag_cluster.md @@ -24,6 +24,9 @@ KubeDB supports reconfigure i.e. add, remove, update and rotation of TLS/SSL cer - To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). +- Install [csi-driver-cacerts](https://github.com/kubeops/csi-driver-cacerts) which will be used to add self-signed ca certificates to the OS trusted certificate store (eg, /etc/ssl/certs/ca-certificates.crt) + + - To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. ```bash diff --git a/docs/guides/mssqlserver/reconfigure-tls/standalone.md b/docs/guides/mssqlserver/reconfigure-tls/standalone.md index 19f46f300e..04903508c2 100644 --- a/docs/guides/mssqlserver/reconfigure-tls/standalone.md +++ b/docs/guides/mssqlserver/reconfigure-tls/standalone.md @@ -24,6 +24,8 @@ KubeDB supports reconfigure i.e. add, remove, update and rotation of TLS/SSL cer - To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). +- Install [csi-driver-cacerts](https://github.com/kubeops/csi-driver-cacerts) which will be used to add self-signed ca certificates to the OS trusted certificate store (eg, /etc/ssl/certs/ca-certificates.crt) + - To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. ```bash From 21262df5cd6130dcaf3695a585744fb4cccc2fc1 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 17 Mar 2026 13:01:28 +0600 Subject: [PATCH 12/51] mg Signed-off-by: Bonusree --- docs/guides/mongodb/gitops/_index.md | 10 +- docs/guides/mongodb/gitops/gitops.md | 378 +++++++++++++------------ docs/guides/mongodb/gitops/overview.md | 26 +- 3 files changed, 208 insertions(+), 206 deletions(-) diff --git a/docs/guides/mongodb/gitops/_index.md b/docs/guides/mongodb/gitops/_index.md index cc82b5f6bc..967af159f7 100644 --- a/docs/guides/mongodb/gitops/_index.md +++ b/docs/guides/mongodb/gitops/_index.md @@ -1,10 +1,10 @@ --- -title: Elasticsearch Gitops +title: MongoDB Gitops menu: docs_{{ .version }}: - identifier: es-gitops - name: Elasticsearch Gitops - parent: es-elasticsearch-guides - weight: 70 + identifier: mg-gitops-mongodb + name: Gitops + parent: mg-mongodb-guides + weight: 47 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mongodb/gitops/gitops.md b/docs/guides/mongodb/gitops/gitops.md index 332c4f29d9..7e12027a62 100644 --- a/docs/guides/mongodb/gitops/gitops.md +++ b/docs/guides/mongodb/gitops/gitops.md @@ -1,11 +1,11 @@ --- -title: Elasticsearch Gitops Overview -description: Elasticsearch Gitops Overview +title: MongoDB Gitops +description: MongoDB Gitops menu: docs_{{ .version }}: - identifier: es-gitops-overview - name: Overview - parent: es-gitops + identifier: es-gitops + name: MongoDB Gitops + parent: mg-gitops-mongodb weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides @@ -15,9 +15,9 @@ section_menu_id: guides > New to KubeDB? Please start [here](/docs/README.md). -# GitOps Elasticsearch using KubeDB GitOps Operator +# GitOps MongoDB using KubeDB GitOps Operator -This guide will show you how to use `KubeDB` GitOps operator to create Elasticsearch database and manage updates using GitOps workflow. +This guide will show you how to use `KubeDB` GitOps operator to create MongoDB database and manage updates using GitOps workflow. ## Before You Begin @@ -31,10 +31,11 @@ This guide will show you how to use `KubeDB` GitOps operator to create Elasticse $ kubectl create ns monitoring namespace/monitoring created + $ kubectl create ns demo namespace/demo created ``` -> Note: YAML files used in this tutorial are stored in [docs/examples/Elasticsearch](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/Elasticsearch) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). +> Note: YAML files used in this tutorial are stored in [docs/examples/MongoDB](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/MongoDB) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). @@ -56,86 +57,87 @@ argocd app create kubedb --repo --path kubedb --dest-server https://k argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa ``` -## Create Elasticsearch Database using GitOps +## Create MongoDB Database using GitOps -### Create a Elasticsearch GitOps CR +### Create a MongoDB GitOps CR ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: MongoDB metadata: - name: es-gitops + name: mg-gitops namespace: demo spec: - version: xpack-8.2.3 - enableSSL: true + version: "8.0.10" + replicaSet: + name: "replicaset" replicas: 2 storageType: Durable storage: storageClassName: longhorn accessModes: - - ReadWriteOnce + - ReadWriteOnce resources: requests: storage: 1Gi - deletionPolicy: WipeOut ``` Create a directory like below, ```bash $ tree . ├── kubedb - └── Elasticsearch.yaml + └── MongoDB.yaml 1 directories, 1 files ``` -Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is created in your cluster. +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is created in your cluster. -Our `gitops` operator will create an actual `Elasticsearch` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. +Our `gitops` operator will create an actual `MongoDB` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get Elasticsearch.gitops.kubedb.com,Elasticsearch.kubedb.com -n demo -NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 2m56s +$ kubectl get MongoDB.gitops.kubedb.com,MongoDB.kubedb.com -n demo +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 33m + +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 33m -NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 2m56s ``` -List the resources created by `kubedb` operator created for `kubedb.com/v1` Elasticsearch. +List the resources created by `kubedb` operator created for `kubedb.com/v1` MongoDB. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' -NAME AGE -petset.apps.k8s.appscode.com/Elasticsearch-prod-broker 4m49s -petset.apps.k8s.appscode.com/Elasticsearch-prod-controller 4m47s +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=mg-gitops' +NAME AGE +petset.apps.k8s.appscode.com/mg-gitops 34m + +NAME READY STATUS RESTARTS AGE +pod/mg-gitops-0 2/2 Running 0 34m +pod/mg-gitops-1 2/2 Running 0 33m -NAME READY STATUS RESTARTS AGE -pod/Elasticsearch-prod-broker-0 1/1 Running 0 4m48s -pod/Elasticsearch-prod-broker-1 1/1 Running 0 4m42s -pod/Elasticsearch-prod-controller-0 1/1 Running 0 4m47s -pod/Elasticsearch-prod-controller-1 1/1 Running 0 4m40s +NAME TYPE DATA AGE +secret/mg-gitops-auth kubernetes.io/basic-auth 2 34m +secret/mg-gitops-key Opaque 1 34m -NAME TYPE DATA AGE -secret/Elasticsearch-prod-auth kubernetes.io/basic-auth 2 4m51s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/mg-gitops ClusterIP 10.43.206.183 27017/TCP 34m +service/mg-gitops-pods ClusterIP None 27017/TCP 34m -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/Elasticsearch-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/mg-gitops kubedb.com/mongodb 8.0.10 34m -NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/Elasticsearch-prod kubedb.com/Elasticsearch 3.9.0 4m47s ``` -## Update Elasticsearch Database using GitOps +## Update MongoDB Database using GitOps -### Scale Elasticsearch Database Resources +### Scale MongoDB Database Resources -Update the `Elasticsearch.yaml` with the following, +Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: MongoDB metadata: - name: Elasticsearch-prod + name: MongoDB-prod namespace: demo spec: version: 3.9.0 @@ -144,7 +146,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1540Mi @@ -163,7 +165,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1540Mi @@ -182,25 +184,25 @@ spec: deletionPolicy: WipeOut ``` -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Elasticsearch` database. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `MongoDB` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ $ kubectl get kf,Elasticsearch,kfops -n demo +$ $ kubectl get kf,MongoDB,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 22h +MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 22h NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 22h +MongoDB.gitops.kubedb.com/MongoDB-prod 22h NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo mg-gitops-0 -o json | jq '.spec.containers[0].resources' { "limits": { "memory": "1536Mi" @@ -212,13 +214,13 @@ $ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o json | jq '.spec.contai } ``` -### Scale Elasticsearch Replicas -Update the `Elasticsearch.yaml` with the following, +### Scale MongoDB Replicas +Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: MongoDB metadata: - name: Elasticsearch-prod + name: MongoDB-prod namespace: demo spec: version: 3.9.0 @@ -227,7 +229,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1540Mi @@ -246,7 +248,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1540Mi @@ -265,44 +267,44 @@ spec: deletionPolicy: WipeOut ``` -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Elasticsearch` database replicas. List the resources created by `gitops` operator in the `demo` namespace. +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `MongoDB` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,MongoDB,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 22h +MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 22h NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 22h +MongoDB.gitops.kubedb.com/MongoDB-prod 22h NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=MongoDB-prod' NAME READY STATUS RESTARTS AGE -Elasticsearch-prod-broker-0 1/1 Running 0 34m -Elasticsearch-prod-broker-1 1/1 Running 0 33m -Elasticsearch-prod-broker-2 1/1 Running 0 33m -Elasticsearch-prod-controller-0 1/1 Running 0 32m -Elasticsearch-prod-controller-1 1/1 Running 0 31m -Elasticsearch-prod-controller-2 1/1 Running 0 31m +mg-gitops-0 1/1 Running 0 34m +mg-gitops-1 1/1 Running 0 33m +mg-gitops-2 1/1 Running 0 33m +MongoDB-prod-controller-0 1/1 Running 0 32m +MongoDB-prod-controller-1 1/1 Running 0 31m +MongoDB-prod-controller-2 1/1 Running 0 31m ``` We can also scale down the replicas by updating the `replicas` fields. -### Expand Elasticsearch Volume +### Expand MongoDB Volume -Update the `Elasticsearch.yaml` with the following, +Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: MongoDB metadata: - name: Elasticsearch-prod + name: MongoDB-prod namespace: demo spec: version: 3.9.0 @@ -311,7 +313,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -330,7 +332,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -349,39 +351,39 @@ spec: deletionPolicy: WipeOut ``` -Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `Elasticsearch` database volume. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `MongoDB` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,MongoDB,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 23m +MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 23m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 23m +MongoDB.gitops.kubedb.com/MongoDB-prod 23m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=Elasticsearch-prod' +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=MongoDB-prod' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -Elasticsearch-prod-data-Elasticsearch-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -Elasticsearch-prod-data-Elasticsearch-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -Elasticsearch-prod-data-Elasticsearch-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -Elasticsearch-prod-data-Elasticsearch-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m +MongoDB-prod-data-mg-gitops-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +MongoDB-prod-data-mg-gitops-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +MongoDB-prod-data-MongoDB-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +MongoDB-prod-data-MongoDB-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m ``` -## Reconfigure Elasticsearch +## Reconfigure MongoDB At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/Elasticsearch/configuration/Elasticsearch-combined.md) +To know more about this configuration file, check [here](/docs/guides/MongoDB/configuration/MongoDB-combined.md) ```yaml apiVersion: v1 kind: Secret @@ -399,16 +401,16 @@ Now, we will add this file to `kubedb /kf-configuration.yaml`. $ tree . ├── kubedb │ ├── kf-configuration.yaml -│ └── Elasticsearch.yaml +│ └── MongoDB.yaml 1 directories, 2 files ``` -Update the `Elasticsearch.yaml` with the following, +Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: MongoDB metadata: - name: Elasticsearch-prod + name: MongoDB-prod namespace: demo spec: configSecret: @@ -419,7 +421,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -438,7 +440,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -457,21 +459,21 @@ spec: deletionPolicy: WipeOut ``` -Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `Elasticsearch` database configuration. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `MongoDB` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,MongoDB,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 74m +MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 74m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 74m +MongoDB.gitops.kubedb.com/MongoDB-prod 74m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 24m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 24m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m ``` @@ -479,7 +481,7 @@ Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr > We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. -### Rotate Elasticsearch Auth +### Rotate MongoDB Auth To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. @@ -488,20 +490,20 @@ We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the fo ```bash kubectl create secret generic kf-rotate-auth -n demo \ --type=kubernetes.io/basic-auth \ ---from-literal=username=Elasticsearch \ ---from-literal=password=Elasticsearch-secret +--from-literal=username=MongoDB \ +--from-literal=password=MongoDB-secret secret/kf-rotate-auth created ``` -Update the `Elasticsearch.yaml` with the following, +Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: MongoDB metadata: - name: Elasticsearch-prod + name: MongoDB-prod namespace: demo spec: authSecret: @@ -515,7 +517,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -534,7 +536,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -553,22 +555,22 @@ spec: deletionPolicy: WipeOut ``` -Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `Elasticsearch` database auth. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `MongoDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,MongoDB,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 7m11s +MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 7m11s NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 7m11s +MongoDB.gitops.kubedb.com/MongoDB-prod 7m11s NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 17h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 28m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 17h +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-rotate-auth-43ris8 RotateAuth Successful 28m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h ``` @@ -577,7 +579,7 @@ Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr We can add, rotate or remove TLS configuration using `gitops`. -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Elasticsearch. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in MongoDB. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. - Start off by generating a ca certificates using openssl. @@ -593,14 +595,14 @@ writing new private key to './ca.key' - Now we are going to create a ca-secret using the certificate files that we have just generated. ```bash -$ kubectl create secret tls Elasticsearch-ca \ +$ kubectl create secret tls MongoDB-ca \ --cert=ca.crt \ --key=ca.key \ --namespace=demo -secret/Elasticsearch-ca created +secret/MongoDB-ca created ``` -Now, Let's create an `Issuer` using the `Elasticsearch-ca` secret that we have just created. The `YAML` file looks like this: +Now, Let's create an `Issuer` using the `MongoDB-ca` secret that we have just created. The `YAML` file looks like this: ```yaml apiVersion: cert-manager.io/v1 @@ -610,7 +612,7 @@ metadata: namespace: demo spec: ca: - secretName: Elasticsearch-ca + secretName: MongoDB-ca ``` Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, @@ -619,16 +621,16 @@ $ tree . ├── kubedb │ ├── kf-configuration.yaml │ ├── kf-issuer.yaml -│ └── Elasticsearch.yaml +│ └── MongoDB.yaml 1 directories, 4 files ``` -Update the `Elasticsearch.yaml` with the following, +Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: MongoDB metadata: - name: Elasticsearch-prod + name: MongoDB-prod namespace: demo spec: version: 3.9.0 @@ -637,7 +639,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -656,7 +658,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -675,41 +677,41 @@ spec: deletionPolicy: WipeOut ``` -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Elasticsearch` database tls. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `MongoDB` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops,pods -n demo +$ kubectl get kf,MongoDB,kfops,pods -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 3.9.0 Ready 41m +MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 41m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 75m +MongoDB.gitops.kubedb.com/MongoDB-prod 75m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 5d18h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 5d18h +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h ``` -> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Elasticsearch. +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for MongoDB. ### Update Version -List Elasticsearch versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Elasticsearch/update-version/update-version.md). +List MongoDB versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/MongoDB/update-version/update-version.md). Let's choose `4.0.0` in this example. -Update the `Elasticsearch.yaml` with the following, +Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: MongoDB metadata: - name: Elasticsearch-prod + name: MongoDB-prod namespace: demo spec: version: 4.0.0 @@ -718,7 +720,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -737,7 +739,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -756,50 +758,50 @@ spec: deletionPolicy: WipeOut ``` -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Elasticsearch` database version. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `MongoDB` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Elasticsearch,kfops -n demo +$ kubectl get kf,MongoDB,kfops -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 4.0.0 Ready 3h47m +MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 4.0.0 Ready 3h47m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 3h47m +MongoDB.gitops.kubedb.com/MongoDB-prod 3h47m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 5d22h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 5d22h +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h ``` -Now, we are going to verify whether the `Elasticsearch`, `PetSet` and it's `Pod` have updated with new image. Let's check, +Now, we are going to verify whether the `MongoDB`, `PetSet` and it's `Pod` have updated with new image. Let's check, ```bash -$ kubectl get Elasticsearch -n demo Elasticsearch-prod -o=jsonpath='{.spec.version}{"\n"}' +$ kubectl get MongoDB -n demo MongoDB-prod -o=jsonpath='{.spec.version}{"\n"}' 4.0.0 -$ kubectl get petset -n demo Elasticsearch-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Elasticsearch:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get petset -n demo mg-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/MongoDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 -$ kubectl get pod -n demo Elasticsearch-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Elasticsearch:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get pod -n demo mg-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/MongoDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 ``` ### Enable Monitoring If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). -Update the `Elasticsearch.yaml` with the following, +Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch +kind: MongoDB metadata: - name: Elasticsearch-prod + name: MongoDB-prod namespace: demo spec: version: 4.0.0 @@ -808,7 +810,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -827,7 +829,7 @@ spec: podTemplate: spec: containers: - - name: Elasticsearch + - name: MongoDB resources: limits: memory: 1536Mi @@ -855,24 +857,24 @@ spec: deletionPolicy: WipeOut ``` -Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Elasticsearch` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `MongoDB` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/Elasticsearch-prod kubedb.com/v1 4.0.0 Ready 5h12m +MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 4.0.0 Ready 5h12m NAME AGE -Elasticsearch.gitops.kubedb.com/Elasticsearch-prod 5h12m +MongoDB.gitops.kubedb.com/MongoDB-prod 5h12m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfigure-ukj41o Reconfigure Successful 6d -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-restart-ljpqih Restart Successful 3m51s -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m -Elasticsearchopsrequest.ops.kubedb.com/Elasticsearch-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 6d +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-restart-ljpqih Restart Successful 3m51s +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m +Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d ``` @@ -891,10 +893,10 @@ There are some other fields that will trigger `Restart` ops request. ## Next Steps -[//]: # (- Learn Elasticsearch [GitOps](/docs/guides/Elasticsearch/concepts/Elasticsearch-gitops.md)) -- Learn Elasticsearch Scaling - - [Horizontal Scaling](/docs/guides/Elasticsearch/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/Elasticsearch/scaling/vertical-scaling/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/Elasticsearch/update-version/overview.md) -- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/Elasticsearch/monitoring/using-builtin-prometheus.md). +[//]: # (- Learn MongoDB [GitOps](/docs/guides/MongoDB/concepts/MongoDB-gitops.md)) +- Learn MongoDB Scaling + - [Horizontal Scaling](/docs/guides/MongoDB/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/MongoDB/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/MongoDB/update-version/overview.md) +- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/MongoDB/monitoring/using-builtin-prometheus.md). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mongodb/gitops/overview.md b/docs/guides/mongodb/gitops/overview.md index bfa01c2fff..10a0e72b69 100644 --- a/docs/guides/mongodb/gitops/overview.md +++ b/docs/guides/mongodb/gitops/overview.md @@ -1,6 +1,6 @@ --- -title: Elasticsearch Gitops Overview -description: Elasticsearch Gitops Overview +title: MongoDB Gitops Overview +description: MongoDB Gitops Overview menu: docs_{{ .version }}: identifier: es-gitops-overview @@ -13,20 +13,20 @@ section_menu_id: guides > New to KubeDB? Please start [here](/docs/README.md). -# GitOps Overview for Elasticsearch +# GitOps Overview for MongoDB -This guide will give you an overview of how KubeDB `gitops` operator works with Elasticsearch databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for -managing Elasticsearch databases in Kubernetes. +This guide will give you an overview of how KubeDB `gitops` operator works with MongoDB databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing MongoDB databases in Kubernetes. ## Before You Begin - You should be familiar with the following `KubeDB` concepts: - - [Elasticsearch](/docs/guides/elasticsearch/concepts/elasticsearch/index.md) - - [ElasticsearchOpsRequest](/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md) + - [MongoDB](/docs/guides/MongoDB/concepts/MongoDB/index.md) + - [ElasticsearchOpsRequest](/docs/guides/MongoDB/concepts/MongoDB-ops-request/index.md) -## Workflow GitOps with Elasticsearch +## Workflow GitOps with MongoDB The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. @@ -35,16 +35,16 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y GitOps Flow -
Fig: GitOps process of Elasticsearch
+
Fig: GitOps process of MongoDB
-1. **Define GitOps Elasticsearch**: Create Custom Resource (CR) of kind `Elasticsearch` using the `gitops.kubedb.com/v1alpha1` API. +1. **Define GitOps MongoDB**: Create Custom Resource (CR) of kind `MongoDB` using the `gitops.kubedb.com/v1alpha1` API. 2. **Store in Git**: Push the CR to a Git repository. 3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. -4. **Create Database**: The GitOps operator creates a corresponding KubeDB Elasticsearch CR in the Kubernetes cluster to deploy the database. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB MongoDB CR in the Kubernetes cluster to deploy the database. 5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. -This flow makes managing Elasticsearch databases efficient, reliable, and fully integrated with GitOps practices. +This flow makes managing MongoDB databases efficient, reliable, and fully integrated with GitOps practices. -In the next doc, we are going to show a step by step guide on running Elasticsearch using GitOps. +In the next doc, we are going to show a step by step guide on running MongoDB using GitOps. From bd669b744783cb7b3a54dd14679ba5e8026bde4e Mon Sep 17 00:00:00 2001 From: Bonusree Date: Wed, 1 Apr 2026 11:24:48 +0600 Subject: [PATCH 13/51] rd Signed-off-by: Bonusree --- docs/guides/redis/gitops/_index.md | 8 +- docs/guides/redis/gitops/gitops.md | 236 ++++++++++++++------------- docs/guides/redis/gitops/overview.md | 30 ++-- 3 files changed, 139 insertions(+), 135 deletions(-) diff --git a/docs/guides/redis/gitops/_index.md b/docs/guides/redis/gitops/_index.md index 098093afa8..1189753691 100644 --- a/docs/guides/redis/gitops/_index.md +++ b/docs/guides/redis/gitops/_index.md @@ -1,10 +1,10 @@ --- -title: Gitops Kafka +title: Redis Gitops menu: docs_{{ .version }}: - identifier: kf-gitops + identifier: rd-gitops name: Gitops - parent: kf-kafka-guides - weight: 30 + parent: rd-redis-guides + weight: 170 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/redis/gitops/gitops.md b/docs/guides/redis/gitops/gitops.md index 1eafdcc0eb..d0d99726db 100644 --- a/docs/guides/redis/gitops/gitops.md +++ b/docs/guides/redis/gitops/gitops.md @@ -4,7 +4,7 @@ menu: docs_{{ .version }}: identifier: rd-gitops-guides name: Gitops Redis - parent: rd-gitops-Redis + parent: rd-gitops weight: 20 menu_name: docs_{{ .version }} section_menu_id: guides @@ -80,11 +80,14 @@ spec: podTemplate: spec: containers: - - name: redis - resources: - requests: - cpu: "100m" - memory: "100Mi" + - name: redis + resources: + requests: + memory: "300Mi" + cpu: "200m" + limits: + memory: "300Mi" + cpu: "200m" deletionPolicy: WipeOut ``` @@ -104,44 +107,43 @@ Our `gitops` operator will create an actual `Redis` database CR in the cluster. ```bash $ kubectl get redis.gitops.kubedb.com,redis.kubedb.com -n demo NAME AGE -redis.gitops.kubedb.com/rd-gitops 8m46s +redis.gitops.kubedb.com/rd-gitops 2m19s NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 8m46s - +redis.kubedb.com/rd-gitops 8.0.4 Ready 2m18s ``` List the resources created by `kubedb` operator created for `kubedb.com/v1` Redis. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=rd-gitops' +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=rd-gitops' NAME AGE -petset.apps.k8s.appscode.com/rd-gitops-shard0 9m38s -petset.apps.k8s.appscode.com/rd-gitops-shard1 9m36s -petset.apps.k8s.appscode.com/rd-gitops-shard2 9m34s +petset.apps.k8s.appscode.com/rd-gitops-shard0 5m53s +petset.apps.k8s.appscode.com/rd-gitops-shard1 5m51s +petset.apps.k8s.appscode.com/rd-gitops-shard2 5m49s NAME READY STATUS RESTARTS AGE -pod/rd-gitops-shard0-0 1/1 Running 0 9m37s -pod/rd-gitops-shard0-1 1/1 Running 0 9m14s -pod/rd-gitops-shard1-0 1/1 Running 0 9m35s -pod/rd-gitops-shard1-1 1/1 Running 0 9m14s -pod/rd-gitops-shard2-0 1/1 Running 0 9m34s -pod/rd-gitops-shard2-1 1/1 Running 0 9m14s +pod/rd-gitops-shard0-0 1/1 Running 0 5m52s +pod/rd-gitops-shard0-1 1/1 Running 0 5m35s +pod/rd-gitops-shard1-0 1/1 Running 0 5m50s +pod/rd-gitops-shard1-1 1/1 Running 0 5m31s +pod/rd-gitops-shard2-0 1/1 Running 0 5m49s +pod/rd-gitops-shard2-1 1/1 Running 0 5m31s NAME TYPE DATA AGE -secret/rd-gitops-9a6ce0 Opaque 1 9m40s -secret/rd-gitops-auth kubernetes.io/basic-auth 2 65m +secret/rd-gitops-auth kubernetes.io/basic-auth 2 5m55s +secret/rd-gitops-b3b686 Opaque 1 5m55s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/rd-gitops ClusterIP 10.43.193.228 6379/TCP 9m40s -service/rd-gitops-pods ClusterIP None 6379/TCP,16379/TCP 9m40s +service/rd-gitops ClusterIP 10.43.156.126 6379/TCP 5m55s +service/rd-gitops-pods ClusterIP None 6379/TCP,16379/TCP 5m55s NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/rd-gitops kubedb.com/redis 8.0.4 9m34s - +appbinding.appcatalog.appscode.com/rd-gitops kubedb.com/redis 8.0.4 5m49s ``` ## Update Redis Database using GitOps + ### Scale Redis Replicas @@ -156,7 +158,7 @@ spec: version: 8.0.4 mode: Cluster cluster: - shards: 4 + shards: 3 replicas: 3 storageType: Durable storage: @@ -169,11 +171,14 @@ spec: podTemplate: spec: containers: - - name: redis - resources: - requests: - cpu: "100m" - memory: "100Mi" + - name: redis + resources: + requests: + memory: "300Mi" + cpu: "200m" + limits: + memory: "300Mi" + cpu: "200m" deletionPolicy: WipeOut ``` Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. @@ -182,33 +187,28 @@ Now, `gitops` operator will detect the replica changes and create a `HorizontalS ```bash $ kubectl get rd,redis,redisopsrequest -n demo NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 12m +redis.kubedb.com/rd-gitops 8.0.4 Ready 55m NAME AGE -redis.gitops.kubedb.com/rd-gitops 12m +redis.gitops.kubedb.com/rd-gitops 55m NAME TYPE STATUS AGE -redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-1nblpl HorizontalScaling Successful 10m - +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-ule15j HorizontalScaling Successful 16m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=rd-gitops' +$ kkubectl get pod -n demo -l 'app.kubernetes.io/instance=rd-gitops' NAME READY STATUS RESTARTS AGE -rd-gitops-shard0-0 1/1 Running 0 16m -rd-gitops-shard0-1 1/1 Running 0 16m -rd-gitops-shard0-2 1/1 Running 0 13m -rd-gitops-shard1-0 1/1 Running 0 16m -rd-gitops-shard1-1 1/1 Running 0 16m -rd-gitops-shard1-2 1/1 Running 0 12m -rd-gitops-shard2-0 1/1 Running 0 16m -rd-gitops-shard2-1 1/1 Running 0 16m -rd-gitops-shard2-2 1/1 Running 0 12m -rd-gitops-shard3-0 1/1 Running 0 14m -rd-gitops-shard3-1 1/1 Running 0 14m -rd-gitops-shard3-2 1/1 Running 0 11m - +rd-gitops-shard0-0 1/1 Running 0 55m +rd-gitops-shard0-1 1/1 Running 0 55m +rd-gitops-shard0-2 1/1 Running 0 16m +rd-gitops-shard1-0 1/1 Running 0 55m +rd-gitops-shard1-1 1/1 Running 0 55m +rd-gitops-shard1-2 1/1 Running 0 16m +rd-gitops-shard2-0 1/1 Running 0 55m +rd-gitops-shard2-1 1/1 Running 0 55m +rd-gitops-shard2-2 1/1 Running 0 15m ``` We can also scale down the replicas by updating the `replicas` fields. @@ -219,12 +219,15 @@ before Ops Request becomes `Successful`, We can validate the changes by checking ```bash $ kubectl get pod -n demo rd-gitops-shard0-0 -o json | jq '.spec.containers[0].resources' { + "limits": { + "cpu": "200m", + "memory": "300Mi" + }, "requests": { - "cpu": "100m", - "memory": "100Mi" + "cpu": "200m", + "memory": "300Mi" } } - ``` @@ -239,7 +242,7 @@ spec: version: 8.0.4 mode: Cluster cluster: - shards: 4 + shards: 3 replicas: 3 storageType: Durable storage: @@ -252,12 +255,16 @@ spec: podTemplate: spec: containers: - - name: redis - resources: - requests: - cpu: "200m" - memory: "200Mi" + - name: redis + resources: + requests: + memory: "500Mi" + cpu: "500m" + limits: + memory: "500Mi" + cpu: "500m" deletionPolicy: WipeOut + ``` @@ -268,17 +275,27 @@ Now, `gitops` operator will detect the resource changes and create a `RedisOpsRe ```bash $ kubectl get rd,redis,redisopsrequest -n demo NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 28m +redis.kubedb.com/rd-gitops 8.0.4 Ready 17h NAME AGE -redis.gitops.kubedb.com/rd-gitops 28m +redis.gitops.kubedb.com/rd-gitops 17h NAME TYPE STATUS AGE -redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-1nblpl HorizontalScaling Successful 26m -redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-or3shk VerticalScaling Successful 10m - +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-ule15j HorizontalScaling Successful 16h +redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-lliwo8 VerticalScaling Successful 16h ``` +kubectl get pod -n demo rd-gitops-shard0-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "500m", + "memory": "500Mi" + }, + "requests": { + "cpu": "500m", + "memory": "500Mi" + } +} ### Expand Redis Volume @@ -291,47 +308,30 @@ metadata: name: rd-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + storage: + resources: + requests: + storage: "2Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + podTemplate: + spec: + containers: + - name: redis resources: requests: - storage: 2Gi - storageClassName: Standard - storageType: Durable + memory: "500Mi" + cpu: "500m" + limits: + memory: "500Mi" + cpu: "500m" deletionPolicy: WipeOut ``` @@ -341,27 +341,31 @@ Now, `gitops` operator will detect the volume changes and create a `VolumeExpans ```bash $ kubectl get rd,redis,redisopsrequest -n demo -NAME TYPE VERSION STATUS AGE -Redis.kubedb.com/rd-gitops kubedb.com/v1 3.9.0 Ready 23m +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 17h -NAME AGE -Redis.gitops.kubedb.com/rd-gitops 23m +NAME AGE +redis.gitops.kubedb.com/rd-gitops 17h -NAME TYPE STATUS AGE -Redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 19m +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-ule15j HorizontalScaling Successful 16h +redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-lliwo8 VerticalScaling Successful 16h +redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-3twy3x VolumeExpansion Successful 2m23s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash $ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=rd-gitops' -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -rd-gitops-data-rd-gitops-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -rd-gitops-data-rd-gitops-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -rd-gitops-data-rd-gitops-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -rd-gitops-data-rd-gitops-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m - +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +data-rd-gitops-shard0-0 Bound pvc-77634b30-7ccc-4391-a768-54d4e3c1907c 2Gi RWO longhorn 17h +data-rd-gitops-shard0-1 Bound pvc-e4b23a61-5de7-4e5c-b4b2-0722bffc7464 2Gi RWO longhorn 17h +data-rd-gitops-shard0-2 Bound pvc-c3ffc095-248b-4091-bfaa-a1de401e3e36 2Gi RWO longhorn 16h +data-rd-gitops-shard1-0 Bound pvc-62e7a6c0-ddd5-4281-8878-9ec42e68585d 2Gi RWO longhorn 17h +data-rd-gitops-shard1-1 Bound pvc-0e9ca41e-8b25-4ea1-865a-17aba48f619c 2Gi RWO longhorn 17h +data-rd-gitops-shard1-2 Bound pvc-c1e6806d-bb6c-4521-94c6-8e47ec6ad36e 2Gi RWO longhorn 16h +data-rd-gitops-shard2-0 Bound pvc-0954e736-e699-46f4-9dfb-33b23f65e351 2Gi RWO longhorn 17h +data-rd-gitops-shard2-1 Bound pvc-1fd1321a-ff04-4c81-b903-80473598ffac 2Gi RWO longhorn 17h +data-rd-gitops-shard2-2 Bound pvc-8458eb68-930b-4817-8577-24616079e9f7 2Gi RWO longhorn 16h ``` ## Reconfigure Redis diff --git a/docs/guides/redis/gitops/overview.md b/docs/guides/redis/gitops/overview.md index cf959a479f..00705eec81 100644 --- a/docs/guides/redis/gitops/overview.md +++ b/docs/guides/redis/gitops/overview.md @@ -1,11 +1,11 @@ --- -title: Kafka Gitops Overview -description: Kafka Gitops Overview +title: Redis Gitops Overview +description: Redis Gitops Overview menu: docs_{{ .version }}: - identifier: kf-gitops-overview + identifier: rd-gitops-overview name: Overview - parent: kf-gitops + parent: rd-gitops weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides @@ -13,20 +13,20 @@ section_menu_id: guides > New to KubeDB? Please start [here](/docs/README.md). -# GitOps Overview for Kafka +# GitOps Overview for Redis -This guide will give you an overview of how KubeDB `gitops` operator works with Kafka databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for -managing Kafka databases in Kubernetes. +This guide will give you an overview of how KubeDB `gitops` operator works with Redis databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Redis databases in Kubernetes. ## Before You Begin - You should be familiar with the following `KubeDB` concepts: - - [Kafka](/docs/guides/kafka/concepts/kafka.md) - - [KafkaOpsRequest](/docs/guides/kafka/concepts/kafkaopsrequest.md) + - [Redis](/docs/guides/redis/concepts/kafka.md) + - [KafkaOpsRequest](/docs/guides/redis/concepts/kafkaopsrequest.md) -## Workflow GitOps with Kafka +## Workflow GitOps with Redis The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. @@ -35,16 +35,16 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y GitOps Flow -
Fig: GitOps process of Kafka
+
Fig: GitOps process of Redis
-1. **Define GitOps Kafka**: Create Custom Resource (CR) of kind `Kafka` using the `gitops.kubedb.com/v1alpha1` API. +1. **Define GitOps Redis**: Create Custom Resource (CR) of kind `Redis` using the `gitops.kubedb.com/v1alpha1` API. 2. **Store in Git**: Push the CR to a Git repository. 3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. -4. **Create Database**: The GitOps operator creates a corresponding KubeDB Kafka CR in the Kubernetes cluster to deploy the database. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Redis CR in the Kubernetes cluster to deploy the database. 5. **Handle Updates**: When you update the KafkaGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. -This flow makes managing Kafka databases efficient, reliable, and fully integrated with GitOps practices. +This flow makes managing Redis databases efficient, reliable, and fully integrated with GitOps practices. -In the next doc, we are going to show a step by step guide on running Kafka using GitOps. +In the next doc, we are going to show a step by step guide on running Redis using GitOps. From 01c9af485bd217bfb78b318e6ee0ec5cb1ef357d Mon Sep 17 00:00:00 2001 From: Bonusree Date: Wed, 1 Apr 2026 17:08:30 +0600 Subject: [PATCH 14/51] rd Signed-off-by: Bonusree --- docs/guides/redis/gitops/gitops.md | 289 +++++++++++------------------ 1 file changed, 110 insertions(+), 179 deletions(-) diff --git a/docs/guides/redis/gitops/gitops.md b/docs/guides/redis/gitops/gitops.md index d0d99726db..fbe9eda4e2 100644 --- a/docs/guides/redis/gitops/gitops.md +++ b/docs/guides/redis/gitops/gitops.md @@ -374,13 +374,14 @@ At first, we will create a secret containing `user.conf` file with required conf To know more about this configuration file, check [here](/docs/guides/Redis/configuration/Redis-combined.md) ```yaml apiVersion: v1 +stringData: + redis.conf: | + maxclients 500 kind: Secret metadata: - name: new-rd-combined-custom-config + name: rd-new-configuration namespace: demo -stringData: - server.properties: |- - log.retention.hours=125 +type: Opaque ``` Now, we will add this file to `kubedb /rd-configuration.yaml`. @@ -401,49 +402,32 @@ metadata: name: rd-gitops namespace: demo spec: - configSecret: - name: new-rd-combined-custom-config - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + configuration: + secretName: rd-new-configuration + storage: + resources: + requests: + storage: "2Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + podTemplate: + spec: + containers: + - name: redis resources: requests: - storage: 2Gi - storageClassName: Standard - storageType: Durable + memory: "500Mi" + cpu: "500m" + limits: + memory: "500Mi" + cpu: "500m" deletionPolicy: WipeOut ``` @@ -452,23 +436,19 @@ Commit the changes and push to your Git repository. Your repository is synced wi Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` RedisOpsRequest to update the `Redis` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get rd,redis,redisopsrequest -n demo -NAME TYPE VERSION STATUS AGE -Redis.kubedb.com/rd-gitops kubedb.com/v1 3.9.0 Ready 74m - -NAME AGE -Redis.gitops.kubedb.com/rd-gitops 74m +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 22m -NAME TYPE STATUS AGE -Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 24m -Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 70m +NAME AGE +redis.gitops.kubedb.com/rd-gitops 22m +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-5v9956 Reconfigure Successful 15m ``` -> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. - ### Rotate Redis Auth To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. @@ -476,12 +456,11 @@ To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new use We will create a secret named `rd-rotate-auth ` with the following content, ```bash -kubectl create secret generic rd-rotate-auth -n demo \ ---type=kubernetes.io/basic-auth \ ---from-literal=username=Redis \ ---from-literal=password=Redis-secret +$ kubectl create secret generic rd-rotate-auth -n demo \ + --type=kubernetes.io/basic-auth \ + --from-literal=username=redis \ + --from-literal=password=redis-secret secret/rd-rotate-auth created - ``` @@ -494,52 +473,35 @@ metadata: name: rd-gitops namespace: demo spec: + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable authSecret: kind: Secret name: rd-rotate-auth configuration: - secretName: new-rd-combined-custom-config - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + secretName: rd-new-configuration + storage: + resources: + requests: + storage: "2Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + podTemplate: + spec: + containers: + - name: redis resources: requests: - storage: 2Gi - storageClassName: Standard - storageType: Durable + memory: "500Mi" + cpu: "500m" + limits: + memory: "500Mi" + cpu: "500m" deletionPolicy: WipeOut ``` @@ -548,18 +510,16 @@ Change the `authSecret` field to `rd-rotate-auth`. Commit the changes and push t Now, `gitops` operator will detect the auth changes and create a `RotateAuth` RedisOpsRequest to update the `Redis` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get rd,redis,redisopsrequest -n demo -NAME TYPE VERSION STATUS AGE -Redis.kubedb.com/rd-gitops kubedb.com/v1 3.9.0 Ready 7m11s - -NAME AGE -Redis.gitops.kubedb.com/rd-gitops 7m11s +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 33m -NAME TYPE STATUS AGE -Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 17h -Redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-43ris8 RotateAuth Successful 28m -Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 17h +NAME AGE +redis.gitops.kubedb.com/rd-gitops 33m +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-5v9956 Reconfigure Successful 26m +redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-oz83g9 RotateAuth Successful 7m39s ``` @@ -583,11 +543,11 @@ writing new private key to './ca.key' - Now we are going to create a ca-secret using the certificate files that we have just generated. ```bash -$ kubectl create secret tls Redis-ca \ - --cert=ca.crt \ - --key=ca.key \ - --namespace=demo -secret/Redis-ca created +$ kubectl create secret tls redis-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/redis-ca created ``` Now, Let's create an `Issuer` using the `Redis-ca` secret that we have just created. The `YAML` file looks like this: @@ -600,7 +560,7 @@ metadata: namespace: demo spec: ca: - secretName: Redis-ca + secretName: redis-ca ``` Let's add that to our `kubedb /rd-issuer.yaml` file. File structure will look like this, @@ -702,47 +662,35 @@ metadata: name: rd-gitops namespace: demo spec: - version: 4.0.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + authSecret: + kind: Secret + name: rd-rotate-auth + configuration: + secretName: rd-new-configuration + storage: + resources: + requests: + storage: "2Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + podTemplate: + spec: + containers: + - name: redis resources: requests: - storage: 2Gi - storageClassName: Standard - storageType: Durable + memory: "500Mi" + cpu: "500m" + limits: + memory: "500Mi" + cpu: "500m" deletionPolicy: WipeOut ``` @@ -752,34 +700,17 @@ Now, `gitops` operator will detect the version changes and create a `VersionUpda ```bash $ kubectl get rd,redis,redisopsrequest -n demo -NAME TYPE VERSION STATUS AGE -Redis.kubedb.com/rd-gitops kubedb.com/v1 4.0.0 Ready 3h47m +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 14m -NAME AGE -Redis.gitops.kubedb.com/rd-gitops 3h47m +NAME AGE +redis.gitops.kubedb.com/rd-gitops 14m -NAME TYPE STATUS AGE -Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 5d22h -Redisopsrequest.ops.kubedb.com/rd-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -Redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-43ris8 RotateAuth Successful 5d6h -Redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-wyn2dp UpdateVersion Successful 3h51m -Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-xvnekk UpdateVersion Successful 11m ``` -Now, we are going to verify whether the `Redis`, `PetSet` and it's `Pod` have updated with new image. Let's check, - -```bash -$ kubectl get Redis -n demo rd-gitops -o=jsonpath='{.spec.version}{"\n"}' -4.0.0 - -$ kubectl get petset -n demo rd-gitops-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Redis:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 - -$ kubectl get pod -n demo rd-gitops-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Redis:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 -``` - ### Enable Monitoring If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). From b07ab51ca1ecd0b4b97b41fb2313a7db64d21d44 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Mon, 6 Apr 2026 12:11:04 +0600 Subject: [PATCH 15/51] mg Signed-off-by: Bonusree --- docs/guides/mongodb/gitops/gitops.md | 782 +++++++++++---------------- 1 file changed, 321 insertions(+), 461 deletions(-) diff --git a/docs/guides/mongodb/gitops/gitops.md b/docs/guides/mongodb/gitops/gitops.md index 7e12027a62..281e8a2ced 100644 --- a/docs/guides/mongodb/gitops/gitops.md +++ b/docs/guides/mongodb/gitops/gitops.md @@ -132,72 +132,66 @@ appbinding.appcatalog.appscode.com/mg-gitops kubedb.com/mongodb 8.0.10 34 ### Scale MongoDB Database Resources +Before scaling database resouces: + +```shell +kubectl get pod -n demo mg-gitops-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "800m", + "memory": "1536Mi" + } +} +``` Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MongoDB metadata: - name: MongoDB-prod + name: mg-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path - controller: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 2 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi storageType: Durable - deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi ``` -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. +Resource Requests and Limits are updated from `800m` to `1000m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `MongoDB` database. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the resource changes and create a `MongoDBOpsRequest` to update the `MongoDB` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ $ kubectl get kf,MongoDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 22h +$kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 13m -NAME AGE -MongoDB.gitops.kubedb.com/MongoDB-prod 22h +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 13m -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 4m35s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, @@ -205,13 +199,14 @@ After Ops Request becomes `Successful`, We can validate the changes by checking $ kubectl get pod -n demo mg-gitops-0 -o json | jq '.spec.containers[0].resources' { "limits": { - "memory": "1536Mi" + "memory": "2Gi" }, "requests": { - "cpu": "500m", - "memory": "1536Mi" + "cpu": "1", + "memory": "2Gi" } } + ``` ### Scale MongoDB Replicas @@ -220,79 +215,56 @@ Update the `MongoDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MongoDB metadata: - name: MongoDB-prod + name: mg-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 3 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path - controller: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 3 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi storageType: Durable - deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi ``` Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `MongoDB` database replicas. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` MongoDBOpsRequest to update the `MongoDB` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MongoDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 22h +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 18m -NAME AGE -MongoDB.gitops.kubedb.com/MongoDB-prod 22h +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 18m -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 4m2s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 9m5s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=MongoDB-prod' -NAME READY STATUS RESTARTS AGE -mg-gitops-0 1/1 Running 0 34m -mg-gitops-1 1/1 Running 0 33m -mg-gitops-2 1/1 Running 0 33m -MongoDB-prod-controller-0 1/1 Running 0 32m -MongoDB-prod-controller-1 1/1 Running 0 31m -MongoDB-prod-controller-2 1/1 Running 0 31m +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=mg-gitops' +NAME READY STATUS RESTARTS AGE +mg-gitops-0 2/2 Running 0 8m37s +mg-gitops-1 2/2 Running 0 9m22s +mg-gitops-2 2/2 Running 0 4m34s ``` We can also scale down the replicas by updating the `replicas` fields. @@ -304,196 +276,145 @@ Update the `MongoDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MongoDB metadata: - name: MongoDB-prod + name: mg-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi storageType: Durable - deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi ``` Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `MongoDB` database volume. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` MongoDBOpsRequest to update the `MongoDB` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MongoDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 23m +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 21m -NAME AGE -MongoDB.gitops.kubedb.com/MongoDB-prod 23m +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 21m -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 7m24s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 12m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 2m10s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=MongoDB-prod' -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -MongoDB-prod-data-mg-gitops-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -MongoDB-prod-data-mg-gitops-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -MongoDB-prod-data-MongoDB-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -MongoDB-prod-data-MongoDB-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m - +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=mg-gitops' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +datadir-mg-gitops-0 Bound pvc-cea7fe6a-dd75-4e81-99d3-9ab2867c6650 2Gi RWO longhorn 22m +datadir-mg-gitops-1 Bound pvc-bcd63bd2-b3b8-4fb8-8c35-5f6e40031f61 2Gi RWO longhorn 21m +datadir-mg-gitops-2 Bound pvc-2535f213-28fb-41ef-bdfd-7fbe91859c81 2Gi RWO longhorn 7m56s ``` ## Reconfigure MongoDB -At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/MongoDB/configuration/MongoDB-combined.md) -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: new-kf-combined-custom-config - namespace: demo -stringData: - server.properties: |- - log.retention.hours=125 +At first, we will create `mongod.conf` file containing required configuration settings. + +```ini +$ cat mongod.conf +net: + maxIncomingConnections: 10000 ``` +Here, `maxIncomingConnections` is set to `10000`, whereas the default value is `65536`. -Now, we will add this file to `kubedb /kf-configuration.yaml`. +Now, we will create a secret with this configuration file. ```bash -$ tree . -├── kubedb -│ ├── kf-configuration.yaml -│ └── MongoDB.yaml -1 directories, 2 files +$ kubectl create secret generic -n demo mg-custom-config --from-file=./mongod.conf +secret/mg-custom-config created ``` + Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MongoDB metadata: - name: MongoDB-prod + name: mg-gitops namespace: demo spec: - configSecret: - name: new-kf-combined-custom-config - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi storageType: Durable - deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: mg-custom-config ``` Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `MongoDB` database configuration. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` MongoDBOpsRequest to update the `MongoDB` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MongoDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 74m - -NAME AGE -MongoDB.gitops.kubedb.com/MongoDB-prod 74m +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 32m -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 24m -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 32m +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 17m +mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 6m7s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 22m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 12m ``` - -> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. - ### Rotate MongoDB Auth To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. -We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, +We will do that using gitops, create the file `kubedb /mg-auth.yaml` with the following content, ```bash -kubectl create secret generic kf-rotate-auth -n demo \ ---type=kubernetes.io/basic-auth \ ---from-literal=username=MongoDB \ ---from-literal=password=MongoDB-secret -secret/kf-rotate-auth created - +kubectl create secret generic mgauth -n demo \ + --type=kubernetes.io/basic-auth \ + --from-literal=username=root \ + --from-literal=password=mongodb-secret +secret/mgauth created ``` @@ -503,75 +424,56 @@ Update the `MongoDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MongoDB metadata: - name: MongoDB-prod + name: mg-gitops namespace: demo spec: + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: mg-custom-config authSecret: kind: Secret - name: kf-rotate-auth - configSecret: - name: new-kf-combined-custom-config - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - storageType: Durable - deletionPolicy: WipeOut + name: mgauth ``` -Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. +Change the `authSecret` field to `mgauth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `MongoDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MongoDBOpsRequest to update the `MongoDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MongoDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 7m11s - -NAME AGE -MongoDB.gitops.kubedb.com/MongoDB-prod 7m11s +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 41m -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 17h -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-rotate-auth-43ris8 RotateAuth Successful 28m -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 41m +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 27m +mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 15m +mongodbopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-u75ihg RotateAuth Successful 3m10s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 32m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 22m ``` @@ -595,32 +497,32 @@ writing new private key to './ca.key' - Now we are going to create a ca-secret using the certificate files that we have just generated. ```bash -$ kubectl create secret tls MongoDB-ca \ +$ kubectl create secret tls mongo-ca\ --cert=ca.crt \ --key=ca.key \ --namespace=demo -secret/MongoDB-ca created +secret/mongo-ca created ``` -Now, Let's create an `Issuer` using the `MongoDB-ca` secret that we have just created. The `YAML` file looks like this: +Now, Let's create an `Issuer` using the `mongo-ca` secret that we have just created. The `YAML` file looks like this: ```yaml apiVersion: cert-manager.io/v1 kind: Issuer metadata: - name: kf-issuer + name: mg-issuer namespace: demo spec: ca: - secretName: MongoDB-ca + secretName: mongo-ca ``` -Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, +Let's add that to our `kubedb /mg-issuer.yaml` file. File structure will look like this, ```bash $ tree . ├── kubedb -│ ├── kf-configuration.yaml -│ ├── kf-issuer.yaml +│ ├── mg-configuration.yaml +│ ├── mg-issuer.yaml │ └── MongoDB.yaml 1 directories, 4 files ``` @@ -630,7 +532,7 @@ Update the `MongoDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MongoDB metadata: - name: MongoDB-prod + name: mg-gitops namespace: demo spec: version: 3.9.0 @@ -679,21 +581,21 @@ spec: Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `MongoDB` database tls. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` MongoDBOpsRequest to update the `MongoDB` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MongoDB,kfops,pods -n demo +$ kubectl get mg,MongoDB,kfops,pods -n demo NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 3.9.0 Ready 41m +MongoDB.kubedb.com/mg-gitops kubedb.com/v1 3.9.0 Ready 41m NAME AGE -MongoDB.gitops.kubedb.com/MongoDB-prod 75m +MongoDB.gitops.kubedb.com/mg-gitops 75m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 5d18h -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +Elasticsearchopsrequest.ops.kubedb.com/mg-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h +Elasticsearchopsrequest.ops.kubedb.com/mg-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +Elasticsearchopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h +Elasticsearchopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h ``` @@ -702,94 +604,69 @@ Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr Vol ### Update Version -List MongoDB versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/MongoDB/update-version/update-version.md). +List MongoDB versions using `kubectl get mgversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/mongodb/update-version/update-version.md). -Let's choose `4.0.0` in this example. +Let's choose `8.0.17` in this example. Update the `MongoDB.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MongoDB metadata: - name: MongoDB-prod - namespace: demo + name: mg-gitops + namespace: demo spec: - version: 4.0.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - storageType: Durable - deletionPolicy: WipeOut -``` - -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. - -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `MongoDB` database version. List the resources created by `gitops` operator in the `demo` namespace. + version: "8.0.17" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 1Gi + requests: + cpu: "1" + memory: 1Gi + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi +``` + +Update the `version` field to `8.0.17`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` MongoDBOpsRequest to update the `MongoDB` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MongoDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 4.0.0 Ready 3h47m +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.17 Ready 46m -NAME AGE -MongoDB.gitops.kubedb.com/MongoDB-prod 3h47m +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 46m -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 5d22h -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 31m +mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 20m +mongodbopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-u75ihg RotateAuth Successful 7m19s +mongodbopsrequest.ops.kubedb.com/mg-gitops-versionupdate-kkc2gc UpdateVersion Successful 2m38s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 36m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 26m ``` Now, we are going to verify whether the `MongoDB`, `PetSet` and it's `Pod` have updated with new image. Let's check, ```bash -$ kubectl get MongoDB -n demo MongoDB-prod -o=jsonpath='{.spec.version}{"\n"}' -4.0.0 - -$ kubectl get petset -n demo mg-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/MongoDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 - -$ kubectl get pod -n demo mg-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/MongoDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get MongoDB -n demo mg-gitops -o=jsonpath='{.spec.version}{"\n"}' +8.0.17 ``` ### Enable Monitoring @@ -801,81 +678,64 @@ Update the `MongoDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MongoDB metadata: - name: MongoDB-prod + name: mg-gitops namespace: demo spec: - version: 4.0.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + version: "8.0.17" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: mg-custom-config + authSecret: + kind: Secret + name: mgauth monitor: agent: prometheus.io/operator prometheus: - exporter: - port: 9091 serviceMonitor: labels: release: prometheus interval: 10s - deletionPolicy: WipeOut ``` Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `MongoDB` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the monitoring changes and create a `Restart` MongoDBOpsRequest to add the `MongoDB` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo -NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/MongoDB-prod kubedb.com/v1 4.0.0 Ready 5h12m - -NAME AGE -MongoDB.gitops.kubedb.com/MongoDB-prod 5h12m +$kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.17 Ready 52m -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfigure-ukj41o Reconfigure Successful 6d -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-restart-ljpqih Restart Successful 3m51s -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m -Elasticsearchopsrequest.ops.kubedb.com/MongoDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 52m +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 38m +mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 26m +mongodbopsrequest.ops.kubedb.com/mg-gitops-restart-ykgxj3 Restart Successful 3m45s +mongodbopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-u75ihg RotateAuth Successful 13m +mongodbopsrequest.ops.kubedb.com/mg-gitops-versionupdate-kkc2gc UpdateVersion Successful 9m15s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 43m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 32m ``` Verify the monitoring is enabled by checking the prometheus targets. @@ -893,10 +753,10 @@ There are some other fields that will trigger `Restart` ops request. ## Next Steps -[//]: # (- Learn MongoDB [GitOps](/docs/guides/MongoDB/concepts/MongoDB-gitops.md)) +[//]: # (- Learn MongoDB [GitOps](/docs/guides/mongodb/concepts/MongoDB-gitops.md)) - Learn MongoDB Scaling - - [Horizontal Scaling](/docs/guides/MongoDB/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/MongoDB/scaling/vertical-scaling/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/MongoDB/update-version/overview.md) -- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/MongoDB/monitoring/using-builtin-prometheus.md). + - [Horizontal Scaling](/docs/guides/mongodb/scaling/horizontal-scaling/combined.md) + - [Vertical Scaling](/docs/guides/mongodb/scaling/vertical-scaling/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/mongodb/update-version/overview.md) +- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/mongodb/monitoring/using-builtin-prometheus.md). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). From ee54e680c849c304026dc0f5db5bb4a6a8fbd9c9 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 7 Apr 2026 10:09:01 +0600 Subject: [PATCH 16/51] mariadb Signed-off-by: Bonusree --- docs/guides/mariadb/gitops/_index.md | 10 +- docs/guides/mariadb/gitops/gitops.md | 259 ++++++++++++------------- docs/guides/mariadb/gitops/overview.md | 4 +- docs/guides/redis/gitops/overview.md | 4 +- 4 files changed, 136 insertions(+), 141 deletions(-) diff --git a/docs/guides/mariadb/gitops/_index.md b/docs/guides/mariadb/gitops/_index.md index cc82b5f6bc..96d6c107ee 100644 --- a/docs/guides/mariadb/gitops/_index.md +++ b/docs/guides/mariadb/gitops/_index.md @@ -1,10 +1,10 @@ --- -title: Elasticsearch Gitops +title: Gitops MariaDB menu: docs_{{ .version }}: - identifier: es-gitops - name: Elasticsearch Gitops - parent: es-elasticsearch-guides - weight: 70 + identifier: guides-mariadb-gitops + name: Gitops + parent: guides-mariadb + weight: 170 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index 8d9125eea3..df808e9c73 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -1,12 +1,12 @@ --- -title: MariaDB Gitops Overview +title: MariaDB Gitops description: MariaDB Gitops Overview menu: docs_{{ .version }}: - identifier: es-gitops-overview - name: Overview - parent: es-gitops - weight: 10 + identifier: md-gitops + name: MariaDB Gitops + parent: guides-mariadb-gitops + weight: 20 menu_name: docs_{{ .version }} section_menu_id: guides --- @@ -66,9 +66,10 @@ metadata: name: mariadb-gitops namespace: demo spec: - version: "10.5.23" + version: "11.8.5" replicas: 3 storageType: Durable + deletionPolicy: WipeOut storage: storageClassName: longhorn accessModes: @@ -76,7 +77,6 @@ spec: resources: requests: storage: 1Gi - deletionPolicy: WipeOut ``` Create a directory like below, @@ -95,33 +95,33 @@ Our `gitops` operator will create an actual `MariaDB` database CR in the cluster ```bash $ kubectl get MariaDB.gitops.kubedb.com,MariaDB.kubedb.com -n demo NAME AGE -mariadb.gitops.kubedb.com/mariadb-gitops 2m +mariadb.gitops.kubedb.com/mariadb-gitops 22m NAME VERSION STATUS AGE -mariadb.kubedb.com/mariadb-gitops 10.5.23 Ready 2m - +mariadb.kubedb.com/mariadb-gitops 11.8.5 Ready 22m ``` List the resources created by `kubedb` operator created for `kubedb.com/v1` MariaDB. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=mariadb-gitops' +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=mariadb-gitops' NAME AGE -petset.apps.k8s.appscode.com/mariadb-gitops 2m45s +petset.apps.k8s.appscode.com/mariadb-gitops 22m NAME READY STATUS RESTARTS AGE -pod/mariadb-gitops-0 1/1 Running 0 2m45s +pod/mariadb-gitops-0 2/2 Running 0 22m +pod/mariadb-gitops-1 2/2 Running 0 22m +pod/mariadb-gitops-2 2/2 Running 0 22m NAME TYPE DATA AGE -secret/mariadb-gitops-auth kubernetes.io/basic-auth 2 2m47s +secret/mariadb-gitops-auth kubernetes.io/basic-auth 2 22m -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/mariadb-gitops ClusterIP 10.43.132.16 3306/TCP 2m47s -service/mariadb-gitops-pods ClusterIP None 3306/TCP 2m47s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/mariadb-gitops ClusterIP 10.43.215.232 3306/TCP 22m +service/mariadb-gitops-pods ClusterIP None 3306/TCP 22m NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/mariadb-gitops kubedb.com/mariadb 10.5.23 2m45s - +appbinding.appcatalog.appscode.com/mariadb-gitops kubedb.com/mariadb 11.8.5 22m ``` ## Update MariaDB Database using GitOps @@ -129,7 +129,7 @@ appbinding.appcatalog.appscode.com/mariadb-gitops kubedb.com/mariadb 10.5.23 ### Scale MariaDB Database Resources ```shell -$ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[].resources' +$ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[].resources' { "limits": { "memory": "1Gi" @@ -139,6 +139,15 @@ $ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[].reso "memory": "1Gi" } } +{ + "limits": { + "memory": "256Mi" + }, + "requests": { + "cpu": "200m", + "memory": "256Mi" + } +} ``` Update the `MariaDB.yaml` with the following, @@ -178,14 +187,12 @@ Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit Now, `gitops` operator will detect the resource changes and create a `MariaDBOpsRequest` to update the `MariaDB` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get md,mariadbopsrequest -n demo +$ kubectl get md,mariadbopsrequest -n demo NAME VERSION STATUS AGE -mariadb.kubedb.com/mariadb-gitops 10.5.23 Ready 39m - -NAME TYPE STATUS AGE -mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-g0l4rg HorizontalScaling Successful 22m -mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-umbwjh VerticalScaling Successful 8m16s +mariadb.kubedb.com/mariadb-gitops 11.8.5 Ready 39m +NAME TYPE STATUS AGE +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-rjs268 VerticalScaling Successful 9m17s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, @@ -214,9 +221,21 @@ metadata: name: mariadb-gitops namespace: demo spec: - version: "10.5.23" + version: "11.8.5" replicas: 5 + podTemplate: + spec: + containers: + - name: mariadb + resources: + requests: + memory: "1.2Gi" + cpu: "0.6" + limits: + memory: "1.2Gi" + cpu: "0.6" storageType: Durable + deletionPolicy: WipeOut storage: storageClassName: longhorn accessModes: @@ -224,31 +243,30 @@ spec: resources: requests: storage: 1Gi - deletionPolicy: WipeOut ``` -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. +Update the `replicas` to `5`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` MariaDBOpsRequest to update the `MariaDB` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get md,mariadbopsrequest -n demo NAME VERSION STATUS AGE -mariadb.kubedb.com/mariadb-gitops 10.5.23 Ready 26m +mariadb.kubedb.com/mariadb-gitops 11.8.5 Ready 107m NAME TYPE STATUS AGE -mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-g0l4rg HorizontalScaling Successful 9m2s - +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-m7iex7 HorizontalScaling Successful 63m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-rjs268 VerticalScaling Successful 76m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=mariadb-gitops' +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=mariadb-gitops' NAME READY STATUS RESTARTS AGE -mariadb-gitops-0 2/2 Running 0 26m -mariadb-gitops-1 2/2 Running 0 26m -mariadb-gitops-2 2/2 Running 0 26m -mariadb-gitops-3 2/2 Running 0 9m29s -mariadb-gitops-4 2/2 Running 0 8m29s +mariadb-gitops-0 2/2 Running 0 76m +mariadb-gitops-1 2/2 Running 0 75m +mariadb-gitops-2 2/2 Running 0 73m +mariadb-gitops-3 2/2 Running 0 63m +mariadb-gitops-4 2/2 Running 0 62m ``` We can also scale down the replicas by updating the `replicas` fields. @@ -260,51 +278,31 @@ Update the `MariaDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MariaDB metadata: - name: MariaDB-prod + name: mariadb-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: "11.8.5" + replicas: 5 + podTemplate: + spec: + containers: + - name: mariadb resources: requests: - storage: 2Gi - storageClassName: Standard + memory: "1.2Gi" + cpu: "0.6" + limits: + memory: "1.2Gi" + cpu: "0.6" storageType: Durable deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi ``` Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. @@ -312,28 +310,25 @@ Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` MariaDBOpsRequest to update the `MariaDB` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MariaDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 23m - -NAME AGE -MariaDB.gitops.kubedb.com/MariaDB-prod 23m +$ kubectl get md,mariadbopsrequest -n demo +NAME VERSION STATUS AGE +mariadb.kubedb.com/mariadb-gitops 11.8.5 Ready 111m -NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +NAME TYPE STATUS AGE +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-m7iex7 HorizontalScaling Successful 68m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-rjs268 VerticalScaling Successful 81m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-01m39b VolumeExpansion Successful 115s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=MariaDB-prod' -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -MariaDB-prod-data-MariaDB-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -MariaDB-prod-data-MariaDB-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -MariaDB-prod-data-MariaDB-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -MariaDB-prod-data-MariaDB-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m - +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=mariadb-gitops' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +data-mariadb-gitops-0 Bound pvc-f1a49c53-d095-43a7-b62f-e91a5a9f5496 2Gi RWO longhorn 116m +data-mariadb-gitops-1 Bound pvc-79d99636-e0d7-413f-a6a6-559e908ed817 2Gi RWO longhorn 116m +data-mariadb-gitops-2 Bound pvc-f66ccf56-63b6-4ac6-a7f9-09f573466266 2Gi RWO longhorn 116m +data-mariadb-gitops-3 Bound pvc-b7744652-611a-4c10-a06f-c93f030fb90f 2Gi RWO longhorn 72m +data-mariadb-gitops-4 Bound pvc-dee1c10d-0456-4935-9306-0d86c3db54d0 2Gi RWO longhorn 71m ``` ## Reconfigure MariaDB @@ -366,7 +361,7 @@ Update the `MariaDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MariaDB metadata: - name: MariaDB-prod + name: mariadb-gitops namespace: demo spec: configSecret: @@ -422,14 +417,14 @@ Now, `gitops` operator will detect the configuration changes and create a `Recon ```bash $ kubectl get kf,MariaDB,kfops -n demo NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 74m +MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 3.9.0 Ready 74m NAME AGE -MariaDB.gitops.kubedb.com/MariaDB-prod 74m +MariaDB.gitops.kubedb.com/mariadb-gitops 74m NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 24m -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 24m +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 70m ``` @@ -459,7 +454,7 @@ Update the `MariaDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MariaDB metadata: - name: MariaDB-prod + name: mariadb-gitops namespace: demo spec: authSecret: @@ -518,15 +513,15 @@ Now, `gitops` operator will detect the auth changes and create a `RotateAuth` Ma ```bash $ kubectl get kf,MariaDB,kfops -n demo NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 7m11s +MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 3.9.0 Ready 7m11s NAME AGE -MariaDB.gitops.kubedb.com/MariaDB-prod 7m11s +MariaDB.gitops.kubedb.com/mariadb-gitops 7m11s NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 17h -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-rotate-auth-43ris8 RotateAuth Successful 28m -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 17h +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-43ris8 RotateAuth Successful 28m +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 17h ``` @@ -586,7 +581,7 @@ Update the `MariaDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MariaDB metadata: - name: MariaDB-prod + name: mariadb-gitops namespace: demo spec: version: 3.9.0 @@ -640,16 +635,16 @@ Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ```bash $ kubectl get kf,MariaDB,kfops,pods -n demo NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 3.9.0 Ready 41m +MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 3.9.0 Ready 41m NAME AGE -MariaDB.gitops.kubedb.com/MariaDB-prod 75m +MariaDB.gitops.kubedb.com/mariadb-gitops 75m NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 5d18h -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h ``` @@ -667,7 +662,7 @@ Update the `MariaDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MariaDB metadata: - name: MariaDB-prod + name: mariadb-gitops namespace: demo spec: version: 4.0.0 @@ -721,30 +716,30 @@ Now, `gitops` operator will detect the version changes and create a `VersionUpda ```bash $ kubectl get kf,MariaDB,kfops -n demo NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 4.0.0 Ready 3h47m +MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 4.0.0 Ready 3h47m NAME AGE -MariaDB.gitops.kubedb.com/MariaDB-prod 3h47m +MariaDB.gitops.kubedb.com/mariadb-gitops 3h47m NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 5d22h -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 5d22h +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-43ris8 RotateAuth Successful 5d6h +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-versionupdate-wyn2dp UpdateVersion Successful 3h51m +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d23h ``` Now, we are going to verify whether the `MariaDB`, `PetSet` and it's `Pod` have updated with new image. Let's check, ```bash -$ kubectl get MariaDB -n demo MariaDB-prod -o=jsonpath='{.spec.version}{"\n"}' +$ kubectl get MariaDB -n demo mariadb-gitops -o=jsonpath='{.spec.version}{"\n"}' 4.0.0 -$ kubectl get petset -n demo MariaDB-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +$ kubectl get petset -n demo mariadb-gitops-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' ghcr.io/appscode-images/MariaDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 -$ kubectl get pod -n demo MariaDB-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +$ kubectl get pod -n demo mariadb-gitops-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' ghcr.io/appscode-images/MariaDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 ``` @@ -757,7 +752,7 @@ Update the `MariaDB.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: MariaDB metadata: - name: MariaDB-prod + name: mariadb-gitops namespace: demo spec: version: 4.0.0 @@ -819,18 +814,18 @@ Now, `gitops` operator will detect the monitoring changes and create a `Restart` ```bash $ kubectl get MariaDBes.gitops.kubedb.com,MariaDBes.kubedb.com,MariaDBopsrequest -n demo NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/MariaDB-prod kubedb.com/v1 4.0.0 Ready 5h12m +MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 4.0.0 Ready 5h12m NAME AGE -MariaDB.gitops.kubedb.com/MariaDB-prod 5h12m +MariaDB.gitops.kubedb.com/mariadb-gitops 5h12m NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfigure-ukj41o Reconfigure Successful 6d -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-restart-ljpqih Restart Successful 3m51s -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m -MariaDBopsrequest.ops.kubedb.com/MariaDB-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 6d +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-restart-ljpqih Restart Successful 3m51s +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-43ris8 RotateAuth Successful 5d7h +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-versionupdate-wyn2dp UpdateVersion Successful 5h16m +MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 6d ``` diff --git a/docs/guides/mariadb/gitops/overview.md b/docs/guides/mariadb/gitops/overview.md index 80ab6a2fc9..f4d74f96d1 100644 --- a/docs/guides/mariadb/gitops/overview.md +++ b/docs/guides/mariadb/gitops/overview.md @@ -3,9 +3,9 @@ title: MariaDB Gitops Overview description: MariaDB Gitops Overview menu: docs_{{ .version }}: - identifier: es-gitops-overview + identifier: md-gitops-overview name: Overview - parent: es-gitops + parent: guides-mariadb-gitops weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/redis/gitops/overview.md b/docs/guides/redis/gitops/overview.md index 00705eec81..7b5ed3a7c8 100644 --- a/docs/guides/redis/gitops/overview.md +++ b/docs/guides/redis/gitops/overview.md @@ -21,8 +21,8 @@ managing Redis databases in Kubernetes. ## Before You Begin - You should be familiar with the following `KubeDB` concepts: - - [Redis](/docs/guides/redis/concepts/kafka.md) - - [KafkaOpsRequest](/docs/guides/redis/concepts/kafkaopsrequest.md) + - [Redis](/docs/guides/redis/concepts/redis.md) + - [KafkaOpsRequest](/docs/guides/redis/concepts/redisopsrequest.md) From ca07b8ccdc8d0a3c96191695bc9d7b370f23f8c4 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 7 Apr 2026 12:32:35 +0600 Subject: [PATCH 17/51] md complete Signed-off-by: Bonusree --- docs/guides/mariadb/gitops/gitops.md | 556 ++++++++++++--------------- 1 file changed, 254 insertions(+), 302 deletions(-) diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index df808e9c73..af8d3de238 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -337,21 +337,24 @@ At first, we will create a secret containing `user.conf` file with required conf To know more about this configuration file, check [here](/docs/guides/MariaDB/configuration/MariaDB-combined.md) ```yaml apiVersion: v1 +stringData: + user.cnf: | + [mysqld] + max_connections = 200 + read_buffer_size = 1048576 kind: Secret metadata: - name: new-kf-combined-custom-config + name: md-configuration namespace: demo -stringData: - server.properties: |- - log.retention.hours=125 +type: Opaque ``` -Now, we will add this file to `kubedb /kf-configuration.yaml`. +Now, we will add this file to `kubedb /md-configuration.yaml`. ```bash $ tree . ├── kubedb -│ ├── kf-configuration.yaml +│ ├── md-configuration.yaml │ └── MariaDB.yaml 1 directories, 2 files ``` @@ -364,50 +367,30 @@ metadata: name: mariadb-gitops namespace: demo spec: - configSecret: - name: new-kf-combined-custom-config - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: "11.8.5" + replicas: 5 + podTemplate: + spec: + containers: + - name: mariadb resources: requests: - storage: 2Gi - storageClassName: Standard + memory: "1.2Gi" + cpu: "0.6" + limits: + memory: "1.2Gi" + cpu: "0.6" storageType: Durable deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: md-configuration ``` Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. @@ -415,36 +398,30 @@ Commit the changes and push to your Git repository. Your repository is synced wi Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` MariaDBOpsRequest to update the `MariaDB` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MariaDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 3.9.0 Ready 74m - -NAME AGE -MariaDB.gitops.kubedb.com/mariadb-gitops 74m - -NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 24m -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 70m +$ kubectl get md,mariadbopsrequest -n demo +NAME VERSION STATUS AGE +mariadb.kubedb.com/mariadb-gitops 11.8.5 Ready 17h +NAME TYPE STATUS AGE +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-m7iex7 HorizontalScaling Successful 19h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-1leaj8 Reconfigure Successful 17h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-rjs268 VerticalScaling Successful 19h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-01m39b VolumeExpansion Successful 18h ``` - -> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. - ### Rotate MariaDB Auth To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. -We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, +We will do that using gitops, create the file `kubedb /md-auth.yaml` with the following content, ```bash -kubectl create secret generic kf-rotate-auth -n demo \ ---type=kubernetes.io/basic-auth \ ---from-literal=username=MariaDB \ ---from-literal=password=MariaDB-secret -secret/kf-rotate-auth created - +$ kubectl create secret generic mdauth -n demo \ + --type=kubernetes.io/basic-auth \ + --from-literal=username=root \ + --from-literal=password=md-secret +secret/mdauth created ``` @@ -457,72 +434,50 @@ metadata: name: mariadb-gitops namespace: demo spec: - authSecret: - kind: Secret - name: kf-rotate-auth - configSecret: - name: new-kf-combined-custom-config - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: "11.8.5" + replicas: 5 + podTemplate: + spec: + containers: + - name: mariadb resources: requests: - storage: 2Gi - storageClassName: Standard + memory: "1.2Gi" + cpu: "0.6" + limits: + memory: "1.2Gi" + cpu: "0.6" storageType: Durable deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: md-configuration + authSecret: + kind: Secret + name: mdauth ``` -Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. +Change the `authSecret` field to `md-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MariaDBOpsRequest to update the `MariaDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MariaDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 3.9.0 Ready 7m11s - -NAME AGE -MariaDB.gitops.kubedb.com/mariadb-gitops 7m11s - -NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 17h -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-43ris8 RotateAuth Successful 28m -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 17h +$ kubectl get md,mariadbopsrequest -n demo +NAME VERSION STATUS AGE +mariadb.kubedb.com/mariadb-gitops 11.8.5 Ready 18h +NAME TYPE STATUS AGE +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-m7iex7 HorizontalScaling Successful 19h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-1leaj8 Reconfigure Successful 18h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-1xy3d7 RotateAuth Successful 12m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-rjs268 VerticalScaling Successful 19h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-01m39b VolumeExpansion Successful 18h ``` @@ -530,48 +485,54 @@ MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeE We can add, rotate or remove TLS configuration using `gitops`. -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in MariaDB. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, -- Start off by generating a ca certificates using openssl. +- Start off by generating our ca-certificates using openssl, ```bash -$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=mariadb/O=kubedb" Generating a RSA private key -................+++++ -........................+++++ +...........................................................................+++++ +........................................................................................................+++++ writing new private key to './ca.key' ------ ``` -- Now we are going to create a ca-secret using the certificate files that we have just generated. +- create a secret using the certificate files we have just generated, ```bash -$ kubectl create secret tls MariaDB-ca \ +kubectl create secret tls md-ca \ --cert=ca.crt \ --key=ca.key \ --namespace=demo -secret/MariaDB-ca created +secret/md-ca created ``` -Now, Let's create an `Issuer` using the `MariaDB-ca` secret that we have just created. The `YAML` file looks like this: +Now, we are going to create an `Issuer` using the `md-ca` secret that hols the ca-certificate we have just created. Below is the YAML of the `Issuer` cr that we are going to create, ```yaml apiVersion: cert-manager.io/v1 kind: Issuer metadata: - name: kf-issuer + name: md-issuer namespace: demo spec: ca: - secretName: MariaDB-ca + secretName: md-ca ``` -Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, +Let’s create the `Issuer` cr we have shown above, + +```bash +kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}//docs/guides/mariadb/reconfigure-tls/cluster/examples/issuer.yaml +issuer.cert-manager.io/md-issuer created +``` + +Let's add that to our `kubedb /md-issuer.yaml` file. File structure will look like this, ```bash $ tree . ├── kubedb -│ ├── kf-configuration.yaml -│ ├── kf-issuer.yaml +│ ├── md-configuration.yaml +│ ├── md-issuer.yaml │ └── MariaDB.yaml 1 directories, 4 files ``` @@ -584,48 +545,48 @@ metadata: name: mariadb-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: "11.8.5" + replicas: 5 + podTemplate: + spec: + containers: + - name: mariadb resources: requests: - storage: 2Gi - storageClassName: Standard + memory: "1.2Gi" + cpu: "0.6" + limits: + memory: "1.2Gi" + cpu: "0.6" storageType: Durable deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: md-configuration + authSecret: + kind: Secret + name: mdauth + requireSSL: true + tls: + issuerRef: + apiGroup: cert-manager.io + kind: Issuer + name: md-issuer + certificates: + - alias: server + subject: + organizations: + - kubedb:server + dnsNames: + - localhost + ipAddresses: + - "127.0.0.1" ``` Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. @@ -633,19 +594,17 @@ Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` MariaDBOpsRequest to update the `MariaDB` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MariaDB,kfops,pods -n demo -NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 3.9.0 Ready 41m - -NAME AGE -MariaDB.gitops.kubedb.com/mariadb-gitops 75m - -NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +$ kubectl get md,mariadbopsrequest -n demo +NAME VERSION STATUS AGE +mariadb.kubedb.com/mariadb-gitops 11.8.5 Ready 18h +NAME TYPE STATUS AGE +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-m7iex7 HorizontalScaling Successful 19h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-1leaj8 Reconfigure Successful 18h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-reconfiguretls-ftyfdq ReconfigureTLS Successful 8m20s +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-1xy3d7 RotateAuth Successful 35m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-rjs268 VerticalScaling Successful 20h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-01m39b VolumeExpansion Successful 18h ``` @@ -655,7 +614,7 @@ MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeE List MariaDB versions using `kubectl get MariaDBversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/MariaDB/update-version/update-version.md). -Let's choose `4.0.0` in this example. +Let's choose `11.8.5` in this example. Update the `MariaDB.yaml` with the following, ```yaml @@ -665,68 +624,67 @@ metadata: name: mariadb-gitops namespace: demo spec: - version: 4.0.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: "12.1.2" + replicas: 5 + podTemplate: + spec: + containers: + - name: mariadb resources: requests: - storage: 2Gi - storageClassName: Standard + memory: "1.2Gi" + cpu: "0.6" + limits: + memory: "1.2Gi" + cpu: "0.6" storageType: Durable deletionPolicy: WipeOut -``` - -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: md-configuration + authSecret: + kind: Secret + name: mdauth + requireSSL: true + tls: + issuerRef: + apiGroup: cert-manager.io + kind: Issuer + name: md-issuer + certificates: + - alias: server + subject: + organizations: + - kubedb:server + dnsNames: + - localhost + ipAddresses: + - "127.0.0.1" +``` + +Update the `version` field to `12.1.2`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. Now, `gitops` operator will detect the version changes and create a `VersionUpdate` MariaDBOpsRequest to update the `MariaDB` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,MariaDB,kfops -n demo -NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 4.0.0 Ready 3h47m - -NAME AGE -MariaDB.gitops.kubedb.com/mariadb-gitops 3h47m +$ kkubectl get md,mariadbopsrequest -n demo +NAME VERSION STATUS AGE +mariadb.kubedb.com/mariadb-gitops 12.1.2 Ready 18h -NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 5d22h -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-43ris8 RotateAuth Successful 5d6h -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-versionupdate-wyn2dp UpdateVersion Successful 3h51m -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +NAME TYPE STATUS AGE +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-m7iex7 HorizontalScaling Successful 20h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-1leaj8 Reconfigure Successful 18h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-reconfiguretls-ftyfdq ReconfigureTLS Successful 24m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-1xy3d7 RotateAuth Successful 51m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-versionupdate-ksli15 UpdateVersion Successful 10m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-rjs268 VerticalScaling Successful 20h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-01m39b VolumeExpansion Successful 19h ``` @@ -734,13 +692,11 @@ Now, we are going to verify whether the `MariaDB`, `PetSet` and it's `Pod` have ```bash $ kubectl get MariaDB -n demo mariadb-gitops -o=jsonpath='{.spec.version}{"\n"}' -4.0.0 - -$ kubectl get petset -n demo mariadb-gitops-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/MariaDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 - -$ kubectl get pod -n demo mariadb-gitops-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/MariaDB:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +12.1.2 +$ kubectl get petset -n demo mariadb-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/mariadb:12.1.2-noble@sha256:843852d8651b3f321896a4a91f8118605d988d70703e520927c8d2c9313aded4 +$ kubectl get pod -n demo mariadb-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/mariadb:12.1.2-noble@sha256:843852d8651b3f321896a4a91f8118605d988d70703e520927c8d2c9313aded4 ``` ### Enable Monitoring @@ -755,78 +711,74 @@ metadata: name: mariadb-gitops namespace: demo spec: - version: 4.0.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MariaDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce + version: "12.1.2" + replicas: 5 + podTemplate: + spec: + containers: + - name: mariadb resources: requests: - storage: 2Gi - storageClassName: Standard + memory: "1.2Gi" + cpu: "0.6" + limits: + memory: "1.2Gi" + cpu: "0.6" storageType: Durable + deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: md-configuration + authSecret: + kind: Secret + name: mdauth + requireSSL: true + tls: + issuerRef: + apiGroup: cert-manager.io + kind: Issuer + name: md-issuer + certificates: + - alias: server + subject: + organizations: + - kubedb:server + dnsNames: + - localhost + ipAddresses: + - "127.0.0.1" monitor: agent: prometheus.io/operator prometheus: - exporter: - port: 9091 serviceMonitor: labels: release: prometheus interval: 10s - deletionPolicy: WipeOut ``` Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. Now, `gitops` operator will detect the monitoring changes and create a `Restart` MariaDBOpsRequest to add the `MariaDB` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get MariaDBes.gitops.kubedb.com,MariaDBes.kubedb.com,MariaDBopsrequest -n demo -NAME TYPE VERSION STATUS AGE -MariaDB.kubedb.com/mariadb-gitops kubedb.com/v1 4.0.0 Ready 5h12m - -NAME AGE -MariaDB.gitops.kubedb.com/mariadb-gitops 5h12m - -NAME TYPE STATUS AGE -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-ukj41o Reconfigure Successful 6d -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-restart-ljpqih Restart Successful 3m51s -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-43ris8 RotateAuth Successful 5d7h -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-versionupdate-wyn2dp UpdateVersion Successful 5h16m -MariaDBopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-41xthr VolumeExpansion Successful 6d +$ kubectl get md,mariadbopsrequest -n demo +NAME VERSION STATUS AGE +mariadb.kubedb.com/mariadb-gitops 12.1.2 Ready 19h +NAME TYPE STATUS AGE +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-horizontalscaling-m7iex7 HorizontalScaling Successful 20h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-reconfigure-1leaj8 Reconfigure Successful 19h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-reconfiguretls-ftyfdq ReconfigureTLS Successful 40m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-restart-e7rv89 Restart Successful 8m26s +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-rotate-auth-1xy3d7 RotateAuth Successful 67m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-versionupdate-ksli15 UpdateVersion Successful 26m +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-verticalscaling-rjs268 VerticalScaling Successful 20h +mariadbopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-01m39b VolumeExpansion Successful 19h ``` Verify the monitoring is enabled by checking the prometheus targets. From 54991c22158335bb6ff64b9872789b077d0cd23a Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 7 Apr 2026 15:38:43 +0600 Subject: [PATCH 18/51] mssql Signed-off-by: Bonusree --- docs/guides/mssqlserver/gitops/_index.md | 10 +- docs/guides/mssqlserver/gitops/gitops.md | 347 +++++++++++---------- docs/guides/mssqlserver/gitops/overview.md | 8 +- 3 files changed, 191 insertions(+), 174 deletions(-) diff --git a/docs/guides/mssqlserver/gitops/_index.md b/docs/guides/mssqlserver/gitops/_index.md index cc82b5f6bc..41f601a279 100644 --- a/docs/guides/mssqlserver/gitops/_index.md +++ b/docs/guides/mssqlserver/gitops/_index.md @@ -1,10 +1,10 @@ --- -title: Elasticsearch Gitops +title: Gitops Microsoft SQL Server menu: docs_{{ .version }}: - identifier: es-gitops - name: Elasticsearch Gitops - parent: es-elasticsearch-guides - weight: 70 + identifier: mssqlserver-gitops + name: Gitops + parent: guides-mssqlserver + weight: 41 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md index 87cb73f1db..f59046bca3 100644 --- a/docs/guides/mssqlserver/gitops/gitops.md +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -1,11 +1,11 @@ --- -title: Mssqlserver Gitops Overview -description: Mssqlserver Gitops Overview +title: Mssqlserver Gitops +description: Mssqlserver Gitops menu: docs_{{ .version }}: - identifier: es-gitops-overview - name: Overview - parent: es-gitops + identifier: mssql-gitops + name: MSSQL Gitops + parent: mssqlserver-gitops weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides @@ -61,22 +61,42 @@ argocd app create kubedb --repo --path kubedb --dest-server https://k ### Create a Mssqlserver GitOps CR ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Mssqlserver +kind: MSSQLServer metadata: - name: es-gitops + name: mssql-gitops namespace: demo spec: - version: xpack-8.2.3 - enableSSL: true - replicas: 2 + version: "2022-cu12" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation # Change it storageType: Durable storage: - storageClassName: longhorn + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: requests: - storage: 1Gi + storage: 10Gi deletionPolicy: WipeOut ``` @@ -94,131 +114,127 @@ Our `gitops` operator will create an actual `Mssqlserver` database CR in the clu ```bash -$ kubectl get Mssqlserver.gitops.kubedb.com,Mssqlserver.kubedb.com -n demo -NAME AGE -Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 2m56s +$ kubectl get Mssqlserver.gitops.kubedb.com,Mssqlserver.kubedb.com -n demo +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 16m -NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 2m56s +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu12 Ready 16m ``` List the resources created by `kubedb` operator created for `kubedb.com/v1` Mssqlserver. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=Mssqlserver-prod' -NAME AGE -petset.apps.k8s.appscode.com/Mssqlserver-prod-broker 4m49s -petset.apps.k8s.appscode.com/Mssqlserver-prod-controller 4m47s +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=mssql-gitops' +NAME AGE +petset.apps.k8s.appscode.com/mssql-gitops 16m -NAME READY STATUS RESTARTS AGE -pod/Mssqlserver-prod-broker-0 1/1 Running 0 4m48s -pod/Mssqlserver-prod-broker-1 1/1 Running 0 4m42s -pod/Mssqlserver-prod-controller-0 1/1 Running 0 4m47s -pod/Mssqlserver-prod-controller-1 1/1 Running 0 4m40s +NAME READY STATUS RESTARTS AGE +pod/mssql-gitops-0 2/2 Running 0 16m +pod/mssql-gitops-1 2/2 Running 0 14m +pod/mssql-gitops-2 2/2 Running 0 14m -NAME TYPE DATA AGE -secret/Mssqlserver-prod-auth kubernetes.io/basic-auth 2 4m51s +NAME TYPE DATA AGE +secret/mssql-gitops-449c85 Opaque 1 17m +secret/mssql-gitops-auth kubernetes.io/basic-auth 2 17m +secret/mssql-gitops-client-cert kubernetes.io/tls 4 17m +secret/mssql-gitops-dbm-login kubernetes.io/basic-auth 1 17m +secret/mssql-gitops-endpoint-cert kubernetes.io/tls 3 17m +secret/mssql-gitops-master-key kubernetes.io/basic-auth 1 17m +secret/mssql-gitops-server-cert kubernetes.io/tls 3 17m -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/Mssqlserver-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/mssql-gitops ClusterIP 10.43.7.188 1433/TCP 17m +service/mssql-gitops-pods ClusterIP None 1433/TCP,5022/TCP 17m +service/mssql-gitops-secondary ClusterIP 10.43.186.58 1433/TCP 17m -NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/Mssqlserver-prod kubedb.com/Mssqlserver 3.9.0 4m47s +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/mssql-gitops kubedb.com/mssqlserver 2022-cu12 16m ``` ## Update Mssqlserver Database using GitOps -### Scale Mssqlserver Database Resources - +### Scale Mssqlserver Replicas Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Mssqlserver +kind: MSSQLServer metadata: - name: Mssqlserver-prod + name: mssql-gitops namespace: demo spec: - version: 3.9.0 + version: "2022-cu12" + replicas: 5 topology: - broker: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path - controller: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation # Change it storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi deletionPolicy: WipeOut - ``` - -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +``` -Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Mssqlserver` database. List the resources created by `gitops` operator in the `demo` namespace. +Update the `replicas` to `5`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Mssqlserver` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 22h +Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 22h NAME AGE -Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 22h +Mssqlserver.gitops.kubedb.com/mssql-gitops 22h -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s ``` -After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo Mssqlserver-prod-broker-0 -o json | jq '.spec.containers[0].resources' -{ - "limits": { - "memory": "1536Mi" - }, - "requests": { - "cpu": "500m", - "memory": "1536Mi" - } -} +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=mssql-gitops' +NAME READY STATUS RESTARTS AGE +mssql-gitops-broker-0 1/1 Running 0 34m +mssql-gitops-broker-1 1/1 Running 0 33m +mssql-gitops-broker-2 1/1 Running 0 33m +mssql-gitops-controller-0 1/1 Running 0 32m +mssql-gitops-controller-1 1/1 Running 0 31m +mssql-gitops-controller-2 1/1 Running 0 31m ``` -### Scale Mssqlserver Replicas +We can also scale down the replicas by updating the `replicas` fields. + +### Scale Mssqlserver Database Resources + Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: Mssqlserver metadata: - name: Mssqlserver-prod + name: mssql-gitops namespace: demo spec: version: 3.9.0 @@ -234,7 +250,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 3 + replicas: 2 storage: accessModes: - ReadWriteOnce @@ -253,7 +269,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 3 + replicas: 2 storage: accessModes: - ReadWriteOnce @@ -263,37 +279,38 @@ spec: storageClassName: local-path storageType: Durable deletionPolicy: WipeOut -``` + ``` -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Mssqlserver` database replicas. List the resources created by `gitops` operator in the `demo` namespace. +Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Mssqlserver` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 22h +Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 22h NAME AGE -Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 22h +Mssqlserver.gitops.kubedb.com/mssql-gitops 22h -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +NAME TYPE STATUS AGE +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-i0kr1l VerticalScaling Successful 2s ``` -After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=Mssqlserver-prod' -NAME READY STATUS RESTARTS AGE -Mssqlserver-prod-broker-0 1/1 Running 0 34m -Mssqlserver-prod-broker-1 1/1 Running 0 33m -Mssqlserver-prod-broker-2 1/1 Running 0 33m -Mssqlserver-prod-controller-0 1/1 Running 0 32m -Mssqlserver-prod-controller-1 1/1 Running 0 31m -Mssqlserver-prod-controller-2 1/1 Running 0 31m +$ kubectl get pod -n demo mssql-gitops-broker-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} ``` -We can also scale down the replicas by updating the `replicas` fields. ### Expand Mssqlserver Volume @@ -302,7 +319,7 @@ Update the `Mssqlserver.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Mssqlserver metadata: - name: Mssqlserver-prod + name: mssql-gitops namespace: demo spec: version: 3.9.0 @@ -356,25 +373,25 @@ Now, `gitops` operator will detect the volume changes and create a `VolumeExpans ```bash $ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 23m +Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 23m NAME AGE -Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 23m +Mssqlserver.gitops.kubedb.com/mssql-gitops 23m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 19m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=Mssqlserver-prod' +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=mssql-gitops' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -Mssqlserver-prod-data-Mssqlserver-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -Mssqlserver-prod-data-Mssqlserver-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -Mssqlserver-prod-data-Mssqlserver-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -Mssqlserver-prod-data-Mssqlserver-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m +mssql-gitops-data-mssql-gitops-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +mssql-gitops-data-mssql-gitops-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +mssql-gitops-data-mssql-gitops-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +mssql-gitops-data-mssql-gitops-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m ``` @@ -408,7 +425,7 @@ Update the `Mssqlserver.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Mssqlserver metadata: - name: Mssqlserver-prod + name: mssql-gitops namespace: demo spec: configSecret: @@ -464,14 +481,14 @@ Now, `gitops` operator will detect the configuration changes and create a `Recon ```bash $ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 74m +Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 74m NAME AGE -Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 74m +Mssqlserver.gitops.kubedb.com/mssql-gitops 74m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 24m -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 24m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 70m ``` @@ -501,7 +518,7 @@ Update the `Mssqlserver.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Mssqlserver metadata: - name: Mssqlserver-prod + name: mssql-gitops namespace: demo spec: authSecret: @@ -560,15 +577,15 @@ Now, `gitops` operator will detect the auth changes and create a `RotateAuth` El ```bash $ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 7m11s +Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 7m11s NAME AGE -Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 7m11s +Mssqlserver.gitops.kubedb.com/mssql-gitops 7m11s NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 17h -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-rotate-auth-43ris8 RotateAuth Successful 28m -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 17h +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-43ris8 RotateAuth Successful 28m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 17h ``` @@ -629,7 +646,7 @@ Update the `Mssqlserver.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Mssqlserver metadata: - name: Mssqlserver-prod + name: mssql-gitops namespace: demo spec: version: 3.9.0 @@ -683,16 +700,16 @@ Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ```bash $ kubectl get kf,Mssqlserver,kfops,pods -n demo NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 3.9.0 Ready 41m +Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 41m NAME AGE -Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 75m +Mssqlserver.gitops.kubedb.com/mssql-gitops 75m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 5d18h -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h ``` @@ -710,7 +727,7 @@ Update the `Mssqlserver.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Mssqlserver metadata: - name: Mssqlserver-prod + name: mssql-gitops namespace: demo spec: version: 4.0.0 @@ -764,30 +781,30 @@ Now, `gitops` operator will detect the version changes and create a `VersionUpda ```bash $ kubectl get kf,Mssqlserver,kfops -n demo NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 4.0.0 Ready 3h47m +Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 4.0.0 Ready 3h47m NAME AGE -Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 3h47m +Mssqlserver.gitops.kubedb.com/mssql-gitops 3h47m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 5d22h -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 5d22h +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-43ris8 RotateAuth Successful 5d6h +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-versionupdate-wyn2dp UpdateVersion Successful 3h51m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d23h ``` Now, we are going to verify whether the `Mssqlserver`, `PetSet` and it's `Pod` have updated with new image. Let's check, ```bash -$ kubectl get Mssqlserver -n demo Mssqlserver-prod -o=jsonpath='{.spec.version}{"\n"}' +$ kubectl get Mssqlserver -n demo mssql-gitops -o=jsonpath='{.spec.version}{"\n"}' 4.0.0 -$ kubectl get petset -n demo Mssqlserver-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +$ kubectl get petset -n demo mssql-gitops-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' ghcr.io/appscode-images/Mssqlserver:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 -$ kubectl get pod -n demo Mssqlserver-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +$ kubectl get pod -n demo mssql-gitops-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' ghcr.io/appscode-images/Mssqlserver:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 ``` @@ -800,7 +817,7 @@ Update the `Mssqlserver.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Mssqlserver metadata: - name: Mssqlserver-prod + name: mssql-gitops namespace: demo spec: version: 4.0.0 @@ -862,18 +879,18 @@ Now, `gitops` operator will detect the monitoring changes and create a `Restart` ```bash $ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/Mssqlserver-prod kubedb.com/v1 4.0.0 Ready 5h12m +Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 4.0.0 Ready 5h12m NAME AGE -Mssqlserver.gitops.kubedb.com/Mssqlserver-prod 5h12m +Mssqlserver.gitops.kubedb.com/mssql-gitops 5h12m NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfigure-ukj41o Reconfigure Successful 6d -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-restart-ljpqih Restart Successful 3m51s -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m -Elasticsearchopsrequest.ops.kubedb.com/Mssqlserver-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 6d +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-restart-ljpqih Restart Successful 3m51s +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-43ris8 RotateAuth Successful 5d7h +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-versionupdate-wyn2dp UpdateVersion Successful 5h16m +Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 6d ``` diff --git a/docs/guides/mssqlserver/gitops/overview.md b/docs/guides/mssqlserver/gitops/overview.md index bfa01c2fff..e148898936 100644 --- a/docs/guides/mssqlserver/gitops/overview.md +++ b/docs/guides/mssqlserver/gitops/overview.md @@ -1,16 +1,16 @@ --- -title: Elasticsearch Gitops Overview -description: Elasticsearch Gitops Overview +title: Gitops overview Microsoft SQL Server menu: docs_{{ .version }}: - identifier: es-gitops-overview + identifier: ms-overview name: Overview - parent: es-gitops + parent: mssqlserver-gitops weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides --- + > New to KubeDB? Please start [here](/docs/README.md). # GitOps Overview for Elasticsearch From 0c4a325e42fe11fa9a625ff2d2fe28575e9d8dfd Mon Sep 17 00:00:00 2001 From: Bonusree Date: Wed, 8 Apr 2026 13:04:04 +0600 Subject: [PATCH 19/51] mssql Signed-off-by: Bonusree --- docs/guides/mssqlserver/gitops/gitops.md | 136 +++++++++++++---------- 1 file changed, 75 insertions(+), 61 deletions(-) diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md index f59046bca3..b1450a49a5 100644 --- a/docs/guides/mssqlserver/gitops/gitops.md +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -116,40 +116,43 @@ Our `gitops` operator will create an actual `Mssqlserver` database CR in the clu ```bash $ kubectl get Mssqlserver.gitops.kubedb.com,Mssqlserver.kubedb.com -n demo NAME AGE -mssqlserver.gitops.kubedb.com/mssql-gitops 16m +mssqlserver.gitops.kubedb.com/mssql-gitops 19h NAME VERSION STATUS AGE -mssqlserver.kubedb.com/mssql-gitops 2022-cu12 Ready 16m +mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 19h ``` List the resources created by `kubedb` operator created for `kubedb.com/v1` Mssqlserver. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=mssql-gitops' -NAME AGE -petset.apps.k8s.appscode.com/mssql-gitops 16m - -NAME READY STATUS RESTARTS AGE -pod/mssql-gitops-0 2/2 Running 0 16m -pod/mssql-gitops-1 2/2 Running 0 14m -pod/mssql-gitops-2 2/2 Running 0 14m +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=mssql-gitops' +NAME AGE +petset.apps.k8s.appscode.com/mssql-gitops 19h +petset.apps.k8s.appscode.com/mssql-gitops-arbiter 19h + +NAME READY STATUS RESTARTS AGE +pod/mssql-gitops-0 2/2 Running 0 19h +pod/mssql-gitops-1 2/2 Running 0 19h +pod/mssql-gitops-2 2/2 Running 0 19h +pod/mssql-gitops-3 2/2 Running 0 19h +pod/mssql-gitops-arbiter-0 1/1 Running 0 19h NAME TYPE DATA AGE -secret/mssql-gitops-449c85 Opaque 1 17m -secret/mssql-gitops-auth kubernetes.io/basic-auth 2 17m -secret/mssql-gitops-client-cert kubernetes.io/tls 4 17m -secret/mssql-gitops-dbm-login kubernetes.io/basic-auth 1 17m -secret/mssql-gitops-endpoint-cert kubernetes.io/tls 3 17m -secret/mssql-gitops-master-key kubernetes.io/basic-auth 1 17m -secret/mssql-gitops-server-cert kubernetes.io/tls 3 17m - -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/mssql-gitops ClusterIP 10.43.7.188 1433/TCP 17m -service/mssql-gitops-pods ClusterIP None 1433/TCP,5022/TCP 17m -service/mssql-gitops-secondary ClusterIP 10.43.186.58 1433/TCP 17m +secret/mssql-gitops-218872 Opaque 1 19h +secret/mssql-gitops-auth kubernetes.io/basic-auth 2 19h +secret/mssql-gitops-client-cert kubernetes.io/tls 4 19h +secret/mssql-gitops-dbm-login kubernetes.io/basic-auth 1 19h +secret/mssql-gitops-endpoint-cert kubernetes.io/tls 3 19h +secret/mssql-gitops-master-key kubernetes.io/basic-auth 1 19h +secret/mssql-gitops-server-cert kubernetes.io/tls 3 19h + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/mssql-gitops ClusterIP 10.43.242.226 1433/TCP 19h +service/mssql-gitops-pods ClusterIP None 1433/TCP,5022/TCP 19h +service/mssql-gitops-secondary ClusterIP 10.43.53.184 1433/TCP 19h NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/mssql-gitops kubedb.com/mssqlserver 2022-cu12 16m +appbinding.appcatalog.appscode.com/mssql-gitops kubedb.com/mssqlserver 2022-cu19 19h ``` ## Update Mssqlserver Database using GitOps @@ -163,8 +166,8 @@ metadata: name: mssql-gitops namespace: demo spec: - version: "2022-cu12" - replicas: 5 + version: "2022-cu19" + replicas: 3 topology: mode: AvailabilityGroup availabilityGroup: @@ -193,42 +196,50 @@ spec: - ReadWriteOnce resources: requests: - storage: 10Gi + storage: 1Gi deletionPolicy: WipeOut ``` Update the `replicas` to `5`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Mssqlserver` database replicas. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` mssqlserverOpsRequest to update the `Mssqlserver` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Mssqlserver,kfops -n demo -NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 22h +$ kubectl get ms,Mssqlserver,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 19h -NAME AGE -Mssqlserver.gitops.kubedb.com/mssql-gitops 22h +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 19h -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +NAME TYPE STATUS AGE +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 15m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=mssql-gitops' -NAME READY STATUS RESTARTS AGE -mssql-gitops-broker-0 1/1 Running 0 34m -mssql-gitops-broker-1 1/1 Running 0 33m -mssql-gitops-broker-2 1/1 Running 0 33m -mssql-gitops-controller-0 1/1 Running 0 32m -mssql-gitops-controller-1 1/1 Running 0 31m -mssql-gitops-controller-2 1/1 Running 0 31m +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=mssql-gitops' +NAME READY STATUS RESTARTS AGE +mssql-gitops-0 2/2 Running 0 19h +mssql-gitops-1 2/2 Running 0 19h +mssql-gitops-2 2/2 Running 0 19h ``` We can also scale down the replicas by updating the `replicas` fields. ### Scale Mssqlserver Database Resources +```bash +$ kubectl get pod -n demo mssql-gitops-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "4Gi" + }, + "requests": { + "cpu": "1500m", + "memory": "2Gi" + } +} +``` Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 @@ -283,32 +294,35 @@ spec: Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Mssqlserver` database. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the resource changes and create a `mssqlserverOpsRequest` to update the `Mssqlserver` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Mssqlserver,kfops -n demo -NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 22h +$ kubectl get ms,Mssqlserver,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 19h -NAME AGE -Mssqlserver.gitops.kubedb.com/mssql-gitops 22h +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 19h -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-i0kr1l VerticalScaling Successful 2s +NAME TYPE STATUS AGE +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 25m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 5m2s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo mssql-gitops-broker-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo mssql-gitops-0 -o json | jq '.spec.containers[0].resources' { "limits": { - "memory": "1536Mi" + "cpu": "2", + "memory": "2Gi" }, "requests": { - "cpu": "500m", - "memory": "1536Mi" + "cpu": "700m", + "memory": "2Gi" } } + ``` @@ -368,7 +382,7 @@ spec: Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `Mssqlserver` database volume. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` mssqlserverOpsRequest to update the `Mssqlserver` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,Mssqlserver,kfops -n demo @@ -476,7 +490,7 @@ spec: Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `Mssqlserver` database configuration. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` mssqlserverOpsRequest to update the `Mssqlserver` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,Mssqlserver,kfops -n demo @@ -572,7 +586,7 @@ spec: Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `Mssqlserver` database auth. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` mssqlserverOpsRequest to update the `Mssqlserver` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,Mssqlserver,kfops -n demo @@ -695,7 +709,7 @@ spec: Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Mssqlserver` database tls. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` mssqlserverOpsRequest to update the `Mssqlserver` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,Mssqlserver,kfops,pods -n demo @@ -776,7 +790,7 @@ spec: Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Mssqlserver` database version. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` mssqlserverOpsRequest to update the `Mssqlserver` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,Mssqlserver,kfops -n demo @@ -875,7 +889,7 @@ spec: Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Mssqlserver` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the monitoring changes and create a `Restart` mssqlserverOpsRequest to add the `Mssqlserver` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo NAME TYPE VERSION STATUS AGE From d6d83f6183f27635267450f053bc229ff1401844 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Wed, 8 Apr 2026 18:07:27 +0600 Subject: [PATCH 20/51] mssql Signed-off-by: Bonusree --- docs/guides/mssqlserver/gitops/gitops.md | 705 +++++++++++------------ 1 file changed, 331 insertions(+), 374 deletions(-) diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md index b1450a49a5..a0c8ebaf49 100644 --- a/docs/guides/mssqlserver/gitops/gitops.md +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -331,52 +331,49 @@ $ kubectl get pod -n demo mssql-gitops-0 -o json | jq '.spec.containers[0].resou Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Mssqlserver +kind: MSSQLServer metadata: name: mssql-gitops namespace: demo spec: - version: 3.9.0 + version: "2022-cu19" + replicas: 3 topology: - broker: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation # Change it + resources: + requests: + memory: "2Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "2Gi" storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut ``` @@ -385,28 +382,26 @@ Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` mssqlserverOpsRequest to update the `Mssqlserver` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Mssqlserver,kfops -n demo -NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 23m +$ kubectl get ms,Mssqlserver,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 20h -NAME AGE -Mssqlserver.gitops.kubedb.com/mssql-gitops 23m +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 20h -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 19m +NAME TYPE STATUS AGE +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 51m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 30m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 15m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash $ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=mssql-gitops' -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -mssql-gitops-data-mssql-gitops-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -mssql-gitops-data-mssql-gitops-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -mssql-gitops-data-mssql-gitops-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -mssql-gitops-data-mssql-gitops-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m - +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +data-mssql-gitops-0 Bound pvc-481caac3-7849-422c-9d8f-704ef82b3bc6 2Gi RWO longhorn 20h +data-mssql-gitops-1 Bound pvc-49ea234d-e7e2-4a3b-9372-b430d72fee5e 2Gi RWO longhorn 19h +data-mssql-gitops-2 Bound pvc-c72d4562-81d2-405b-ae8d-52816e59767f 2Gi RWO longhorn 19h ``` ## Reconfigure Mssqlserver @@ -437,54 +432,51 @@ $ tree . Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Mssqlserver +kind: MSSQLServer metadata: name: mssql-gitops namespace: demo spec: - configSecret: - name: new-kf-combined-custom-config - version: 3.9.0 + version: "2022-cu19" + replicas: 3 topology: - broker: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation # Change it + resources: + requests: + memory: "2Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "2Gi" + configuration: + secretName: ms-custom-config storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut ``` @@ -493,17 +485,18 @@ Commit the changes and push to your Git repository. Your repository is synced wi Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` mssqlserverOpsRequest to update the `Mssqlserver` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Mssqlserver,kfops -n demo -NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 74m - -NAME AGE -Mssqlserver.gitops.kubedb.com/mssql-gitops 74m +$ kubectl get ms,Mssqlserver,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 20h -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 24m -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 70m +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 20h +NAME TYPE STATUS AGE +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 71m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfigure-6i2hvt Reconfigure Successful 6m24s +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 50m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 35m ``` @@ -517,12 +510,11 @@ To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new use We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, ```bash -kubectl create secret generic kf-rotate-auth -n demo \ ---type=kubernetes.io/basic-auth \ ---from-literal=username=Mssqlserver \ ---from-literal=password=Mssqlserver-secret -secret/kf-rotate-auth created - +$ kubectl create secret generic mssqlserver-auth -n demo \ + --type=kubernetes.io/basic-auth \ + --from-literal=username=sa \ + --from-literal=password=Mssqlserver2 +secret/mssqlserver-auth created ``` @@ -530,57 +522,54 @@ secret/kf-rotate-auth created Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Mssqlserver +kind: MSSQLServer metadata: name: mssql-gitops namespace: demo spec: + version: "2022-cu19" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation # Change it + resources: + requests: + memory: "2Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "2Gi" + configuration: + secretName: ms-custom-config authSecret: kind: Secret - name: kf-rotate-auth - configSecret: - name: new-kf-combined-custom-config - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + name: mssqlserver-auth storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut ``` @@ -589,125 +578,80 @@ Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push t Now, `gitops` operator will detect the auth changes and create a `RotateAuth` mssqlserverOpsRequest to update the `Mssqlserver` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Mssqlserver,kfops -n demo -NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 7m11s - -NAME AGE -Mssqlserver.gitops.kubedb.com/mssql-gitops 7m11s +$ kubectl get ms,Mssqlserver,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 21h -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 17h -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-43ris8 RotateAuth Successful 28m -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 17h +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 21h +NAME TYPE STATUS AGE +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 153m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfigure-6i2hvt Reconfigure Successful 88m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-otytes RotateAuth Successful 77m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 133m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 117m ``` ### TLS configuration -We can add, rotate or remove TLS configuration using `gitops`. - -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Mssqlserver. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. As well as we need to install [csi-driver-cacerts](https://github.com/kubeops/csi-driver-cacerts) which will be used to add self-signed ca certificates to the OS trusted certificate store (eg, /etc/ssl/certs/ca-certificates.crt) - - -- Start off by generating a ca certificates using openssl. - -```bash -$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" -Generating a RSA private key -................+++++ -........................+++++ -writing new private key to './ca.key' ------ -``` - -- Now we are going to create a ca-secret using the certificate files that we have just generated. - -```bash -$ kubectl create secret tls Mssqlserver-ca \ - --cert=ca.crt \ - --key=ca.key \ - --namespace=demo -secret/Mssqlserver-ca created -``` - -Now, Let's create an `Issuer` using the `Mssqlserver-ca` secret that we have just created. The `YAML` file looks like this: - -```yaml -apiVersion: cert-manager.io/v1 -kind: Issuer -metadata: - name: kf-issuer - namespace: demo -spec: - ca: - secretName: Mssqlserver-ca -``` - -Let's add that to our `kubedb /kf-issuer.yaml` file. File structure will look like this, -```bash -$ tree . -├── kubedb -│ ├── kf-configuration.yaml -│ ├── kf-issuer.yaml -│ └── Mssqlserver.yaml -1 directories, 4 files -``` Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Mssqlserver +kind: MSSQLServer metadata: name: mssql-gitops namespace: demo spec: - version: 3.9.0 + version: "2022-cu19" + replicas: 3 topology: - broker: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: true + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation # Change it + resources: + requests: + memory: "2Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "2Gi" + configuration: + secretName: ms-custom-config + authSecret: + kind: Secret + name: mssqlserver-auth storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut ``` -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +Convert `spec.tls.clientTLS` to `true`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` mssqlserverOpsRequest to update the `Mssqlserver` database tls. List the resources created by `gitops` operator in the `demo` namespace. @@ -739,52 +683,54 @@ Let's choose `4.0.0` in this example. Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Mssqlserver +kind: MSSQLServer metadata: name: mssql-gitops namespace: demo spec: - version: 4.0.0 + version: "2022-cu22" + replicas: 3 topology: - broker: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation # Change it + resources: + requests: + memory: "2Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "2Gi" + configuration: + secretName: ms-custom-config + authSecret: + kind: Secret + name: mssqlserver-auth storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut ``` @@ -793,19 +739,21 @@ Update the `version` field to `17.4`. Commit the changes and push to your Git re Now, `gitops` operator will detect the version changes and create a `VersionUpdate` mssqlserverOpsRequest to update the `Mssqlserver` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Mssqlserver,kfops -n demo -NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 4.0.0 Ready 3h47m +$ kubectl get ms,Mssqlserver,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 22h -NAME AGE -Mssqlserver.gitops.kubedb.com/mssql-gitops 3h47m +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 22h + +NAME TYPE STATUS AGE +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 3h21m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfigure-6i2hvt Reconfigure Successful 136m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-otytes RotateAuth Successful 125m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-versionupdate-mlq0kn UpdateVersion Successful 13m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 3h1m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 165m -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 5d22h -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-43ris8 RotateAuth Successful 5d6h -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-versionupdate-wyn2dp UpdateVersion Successful 3h51m -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d23h ``` @@ -813,13 +761,13 @@ Now, we are going to verify whether the `Mssqlserver`, `PetSet` and it's `Pod` h ```bash $ kubectl get Mssqlserver -n demo mssql-gitops -o=jsonpath='{.spec.version}{"\n"}' -4.0.0 +2022-cu22 -$ kubectl get petset -n demo mssql-gitops-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Mssqlserver:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get petset -n demo mssql-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU22-ubuntu-22.04@sha256:db9a8fe3098b7e8bbde41106bdc7caee942e97124e5fdb71b872ca208de3092d -$ kubectl get pod -n demo mssql-gitops-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/Mssqlserver:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +$ kubectl get pod -n demo mssql-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU22-ubuntu-22.04@sha256:db9a8fe3098b7e8bbde41106bdc7caee942e97124e5fdb71b872ca208de3092d ``` ### Enable Monitoring @@ -829,83 +777,92 @@ If you already don't have a Prometheus server running, deploy one following tuto Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Mssqlserver +kind: MSSQLServer metadata: name: mssql-gitops namespace: demo spec: - version: 4.0.0 + version: "2022-cu22" + replicas: 3 topology: - broker: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation # Change it + resources: + requests: + memory: "2Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "2Gi" + configuration: + secretName: ms-custom-config + authSecret: + kind: Secret + name: mssqlserver-auth storageType: Durable - monitor: - agent: prometheus.io/operator - prometheus: - exporter: - port: 9091 - serviceMonitor: - labels: - release: prometheus - interval: 10s + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi deletionPolicy: WipeOut + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9399 + securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - ALL + runAsGroup: 10001 + runAsNonRoot: true + runAsUser: 10001 + seccompProfile: + type: RuntimeDefault + serviceMonitor: + interval: 100s + labels: + release: prometheus ``` Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. Now, `gitops` operator will detect the monitoring changes and create a `Restart` mssqlserverOpsRequest to add the `Mssqlserver` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo -NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 4.0.0 Ready 5h12m - -NAME AGE -Mssqlserver.gitops.kubedb.com/mssql-gitops 5h12m - -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 6d -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-restart-ljpqih Restart Successful 3m51s -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-43ris8 RotateAuth Successful 5d7h -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-versionupdate-wyn2dp UpdateVersion Successful 5h16m -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 6d +$ kubectl get ms,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 11m +NAME TYPE STATUS AGE +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 5h9m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfigure-6i2hvt Reconfigure Successful 4h4m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-restart-hoi536 Restart Successful 6m8s +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-otytes RotateAuth Successful 3h53m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-versionupdate-mlq0kn UpdateVersion Successful 120m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 4h48m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 4h33m ``` Verify the monitoring is enabled by checking the prometheus targets. From d25eccb536704ed3670d8b6583941b7760513e20 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Fri, 10 Apr 2026 15:24:50 +0600 Subject: [PATCH 21/51] mysql Signed-off-by: Bonusree --- docs/guides/mariadb/gitops/gitops.md | 16 +- docs/guides/mongodb/gitops/_index.md | 2 +- docs/guides/mongodb/gitops/gitops.md | 103 ++-- docs/guides/mongodb/gitops/overview.md | 4 +- docs/guides/mssqlserver/gitops/gitops.md | 280 +++++------ docs/guides/mysql/gitops/_index.md | 8 +- docs/guides/mysql/gitops/gitops.md | 595 +++++++++++------------ docs/guides/mysql/gitops/overview.md | 2 +- 8 files changed, 478 insertions(+), 532 deletions(-) diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index af8d3de238..0bbd27da94 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -139,16 +139,6 @@ $ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[].res "memory": "1Gi" } } -{ - "limits": { - "memory": "256Mi" - }, - "requests": { - "cpu": "200m", - "memory": "256Mi" - } -} - ``` Update the `MariaDB.yaml` with the following, ```yaml @@ -463,7 +453,7 @@ spec: name: mdauth ``` -Change the `authSecret` field to `md-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. +Change the `authSecret` field to `mdauth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MariaDBOpsRequest to update the `MariaDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. @@ -589,7 +579,7 @@ spec: - "127.0.0.1" ``` -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. +Add `requireSSL` as `true` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` MariaDBOpsRequest to update the `MariaDB` database tls. List the resources created by `gitops` operator in the `demo` namespace. @@ -614,7 +604,7 @@ mariadbopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-01m39b Volum List MariaDB versions using `kubectl get MariaDBversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/MariaDB/update-version/update-version.md). -Let's choose `11.8.5` in this example. +Let's choose `12.1.2` in this example. Update the `MariaDB.yaml` with the following, ```yaml diff --git a/docs/guides/mongodb/gitops/_index.md b/docs/guides/mongodb/gitops/_index.md index 967af159f7..653e9e9e45 100644 --- a/docs/guides/mongodb/gitops/_index.md +++ b/docs/guides/mongodb/gitops/_index.md @@ -5,6 +5,6 @@ menu: identifier: mg-gitops-mongodb name: Gitops parent: mg-mongodb-guides - weight: 47 + weight: 147 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mongodb/gitops/gitops.md b/docs/guides/mongodb/gitops/gitops.md index 281e8a2ced..c4af6cc445 100644 --- a/docs/guides/mongodb/gitops/gitops.md +++ b/docs/guides/mongodb/gitops/gitops.md @@ -3,9 +3,9 @@ title: MongoDB Gitops description: MongoDB Gitops menu: docs_{{ .version }}: - identifier: es-gitops + identifier: mg-gitops name: MongoDB Gitops - parent: mg-gitops-mongodb + parent: mg-gitops-mongodb weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides @@ -402,6 +402,7 @@ mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalSc mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 12m ``` +We can also reconfigure the parameters creating another secret and reference the secret in the `configuration.secretName` field. Also you can remove the `configuration` field to use the default parameters. ### Rotate MongoDB Auth @@ -456,7 +457,7 @@ spec: name: mgauth ``` -Change the `authSecret` field to `mgauth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. +Add the secret name in `authSecret` field. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MongoDBOpsRequest to update the `MongoDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. @@ -535,58 +536,48 @@ metadata: name: mg-gitops namespace: demo spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: MongoDB - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi storageType: Durable - deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: mg-custom-config + authSecret: + kind: Secret + name: mgauth + tls: + issuerRef: + apiGroup: "cert-manager.io" + kind: Issuer + name: mg-issuer ``` -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. +Add `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` MongoDBOpsRequest to update the `MongoDB` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get mg,MongoDB,kfops,pods -n demo NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/mg-gitops kubedb.com/v1 3.9.0 Ready 41m +MongoDB.kubedb.com/mg-gitops kubedb.com/v1 8.0.17 Ready 41m NAME AGE MongoDB.gitops.kubedb.com/mg-gitops 75m @@ -686,15 +677,15 @@ spec: name: "replicaset" replicas: 3 podTemplate: - spec: - containers: - - name: mongodb - resources: - limits: - memory: 2Gi - requests: - cpu: 1000m - memory: 2Gi + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi storageType: Durable storage: storageClassName: longhorn @@ -721,7 +712,7 @@ Add `monitor` field in the spec. Commit the changes and push to your Git reposit Now, `gitops` operator will detect the monitoring changes and create a `Restart` MongoDBOpsRequest to add the `MongoDB` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$kubectl get mg,MongoDB,mgops -n demo +$ kubectl get mg,MongoDB,mgops -n demo NAME VERSION STATUS AGE mongodb.kubedb.com/mg-gitops 8.0.17 Ready 52m diff --git a/docs/guides/mongodb/gitops/overview.md b/docs/guides/mongodb/gitops/overview.md index 10a0e72b69..6e05b2f28a 100644 --- a/docs/guides/mongodb/gitops/overview.md +++ b/docs/guides/mongodb/gitops/overview.md @@ -3,9 +3,9 @@ title: MongoDB Gitops Overview description: MongoDB Gitops Overview menu: docs_{{ .version }}: - identifier: es-gitops-overview + identifier: mg-gitops-overview name: Overview - parent: es-gitops + parent: mg-gitops-mongodb weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md index a0c8ebaf49..0f42931110 100644 --- a/docs/guides/mssqlserver/gitops/gitops.md +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -67,7 +67,7 @@ metadata: namespace: demo spec: version: "2022-cu12" - replicas: 3 + replicas: 4 topology: mode: AvailabilityGroup availabilityGroup: @@ -200,7 +200,7 @@ spec: deletionPolicy: WipeOut ``` -Update the `replicas` to `5`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +Scale down the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` mssqlserverOpsRequest to update the `Mssqlserver` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash @@ -243,56 +243,53 @@ $ kubectl get pod -n demo mssql-gitops-0 -o json | jq '.spec.containers[0].resou Update the `Mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 -kind: Mssqlserver +kind: MSSQLServer metadata: name: mssql-gitops namespace: demo spec: - version: 3.9.0 + version: "2022-cu19" + replicas: 3 topology: - broker: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path - controller: - podTemplate: - spec: - containers: - - name: Mssqlserver - resources: - limits: - memory: 1540Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - storageClassName: local-path + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation # Change it + resources: + requests: + memory: "2Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "2Gi" storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi deletionPolicy: WipeOut ``` -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +Resource Requests and Limits are updated to `2` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. Now, `gitops` operator will detect the resource changes and create a `mssqlserverOpsRequest` to update the `Mssqlserver` database. List the resources created by `gitops` operator in the `demo` namespace. @@ -406,30 +403,23 @@ data-mssql-gitops-2 Bound pvc-c72d4562-81d2-405b-ae8d-52816e59767f 2Gi ## Reconfigure Mssqlserver -At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/Mssqlserver/configuration/Mssqlserver-combined.md) -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: new-kf-combined-custom-config - namespace: demo -stringData: - server.properties: |- - log.retention.hours=125 +Now, we will create `mssql.conf` file containing required configuration settings. + +```ini +$ cat mssql.conf +[memory] +memorylimitmb = 2048 ``` +Here, `memorylimitmb` is set to `2048`, whereas the default value is `12280`. -Now, we will add this file to `kubedb /kf-configuration.yaml`. +Now, we will create a secret with this configuration file. ```bash -$ tree . -├── kubedb -│ ├── kf-configuration.yaml -│ └── Mssqlserver.yaml -1 directories, 2 files +$ kubectl create secret generic -n demo ms-custom-config --from-file=./mssql.conf +secret/ms-custom-config created ``` -Update the `Mssqlserver.yaml` with the following, +Update the `Mssqlserver.yaml` with `spec.configuration.secretName` as the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer @@ -501,7 +491,7 @@ mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j Vol -> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. +> We can also reconfigure the parameters creating another secret and reference the secret in the `configuration.secretName` field. Also you can remove the `configuration` field to use the default parameters. ### Rotate Mssqlserver Auth @@ -519,7 +509,7 @@ secret/mssqlserver-auth created -Update the `Mssqlserver.yaml` with the following, +Update the `Mssqlserver.yaml` ading `authsecret` as the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer @@ -573,7 +563,7 @@ spec: deletionPolicy: WipeOut ``` -Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +Add the `authSecret.kind` and `authSecret.name` field to `mssqlserver-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. Now, `gitops` operator will detect the auth changes and create a `RotateAuth` mssqlserverOpsRequest to update the `Mssqlserver` database auth. List the resources created by `gitops` operator in the `demo` namespace. @@ -594,8 +584,11 @@ mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j Vol ``` -### TLS configuration +### Update Version + +List Mssqlserver versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Mssqlserver/update-version/update-version.md). +Let's choose `2022-cu22` in this example. Update the `Mssqlserver.yaml` with the following, ```yaml @@ -605,7 +598,7 @@ metadata: name: mssql-gitops namespace: demo spec: - version: "2022-cu19" + version: "2022-cu22" replicas: 3 topology: mode: AvailabilityGroup @@ -618,7 +611,7 @@ spec: name: mssqlserver-ca-issuer kind: Issuer apiGroup: "cert-manager.io" - clientTLS: true + clientTLS: false podTemplate: spec: containers: @@ -651,34 +644,45 @@ spec: deletionPolicy: WipeOut ``` -Convert `spec.tls.clientTLS` to `true`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +Update the `version` field to `2022-cu22`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` mssqlserverOpsRequest to update the `Mssqlserver` database tls. List the resources created by `gitops` operator in the `demo` namespace. +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` mssqlserverOpsRequest to update the `Mssqlserver` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,Mssqlserver,kfops,pods -n demo -NAME TYPE VERSION STATUS AGE -Mssqlserver.kubedb.com/mssql-gitops kubedb.com/v1 3.9.0 Ready 41m +$ kubectl get ms,Mssqlserver,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 22h -NAME AGE -Mssqlserver.gitops.kubedb.com/mssql-gitops 75m +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 22h -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h -Elasticsearchopsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +NAME TYPE STATUS AGE +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 3h21m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfigure-6i2hvt Reconfigure Successful 136m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-otytes RotateAuth Successful 125m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-versionupdate-mlq0kn UpdateVersion Successful 13m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 3h1m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 165m ``` -> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Mssqlserver. +Now, we are going to verify whether the `Mssqlserver`, `PetSet` and it's `Pod` have updated with new image. Let's check, -### Update Version +```bash +$ kubectl get Mssqlserver -n demo mssql-gitops -o=jsonpath='{.spec.version}{"\n"}' +2022-cu22 -List Mssqlserver versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Mssqlserver/update-version/update-version.md). +$ kubectl get petset -n demo mssql-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU22-ubuntu-22.04@sha256:db9a8fe3098b7e8bbde41106bdc7caee942e97124e5fdb71b872ca208de3092d -Let's choose `4.0.0` in this example. +$ kubectl get pod -n demo mssql-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU22-ubuntu-22.04@sha256:db9a8fe3098b7e8bbde41106bdc7caee942e97124e5fdb71b872ca208de3092d +``` + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). Update the `Mssqlserver.yaml` with the following, ```yaml @@ -732,47 +736,60 @@ spec: requests: storage: 2Gi deletionPolicy: WipeOut + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9399 + securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - ALL + runAsGroup: 10001 + runAsNonRoot: true + runAsUser: 10001 + seccompProfile: + type: RuntimeDefault + serviceMonitor: + interval: 100s + labels: + release: prometheus ``` -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. - -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` mssqlserverOpsRequest to update the `Mssqlserver` database version. List the resources created by `gitops` operator in the `demo` namespace. +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +Now, `gitops` operator will detect the monitoring changes and create a `Restart` mssqlserverOpsRequest to add the `Mssqlserver` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get ms,Mssqlserver,msops -n demo +$ kubectl get ms,msops -n demo NAME VERSION STATUS AGE -mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 22h - -NAME AGE -mssqlserver.gitops.kubedb.com/mssql-gitops 22h +mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 11m NAME TYPE STATUS AGE -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 3h21m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfigure-6i2hvt Reconfigure Successful 136m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-otytes RotateAuth Successful 125m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-versionupdate-mlq0kn UpdateVersion Successful 13m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 3h1m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 165m - +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 5h9m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfigure-6i2hvt Reconfigure Successful 4h4m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-restart-hoi536 Restart Successful 6m8s +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-otytes RotateAuth Successful 3h53m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-versionupdate-mlq0kn UpdateVersion Successful 120m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 4h48m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 4h33m ``` +Verify the monitoring is enabled by checking the prometheus targets. -Now, we are going to verify whether the `Mssqlserver`, `PetSet` and it's `Pod` have updated with new image. Let's check, - -```bash -$ kubectl get Mssqlserver -n demo mssql-gitops -o=jsonpath='{.spec.version}{"\n"}' -2022-cu22 - -$ kubectl get petset -n demo mssql-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -mcr.microsoft.com/mssql/server:2022-CU22-ubuntu-22.04@sha256:db9a8fe3098b7e8bbde41106bdc7caee942e97124e5fdb71b872ca208de3092d +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. -$ kubectl get pod -n demo mssql-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -mcr.microsoft.com/mssql/server:2022-CU22-ubuntu-22.04@sha256:db9a8fe3098b7e8bbde41106bdc7caee942e97124e5fdb71b872ca208de3092d -``` -### Enable Monitoring +### TLS configuration -If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). Update the `Mssqlserver.yaml` with the following, ```yaml @@ -795,7 +812,7 @@ spec: name: mssqlserver-ca-issuer kind: Issuer apiGroup: "cert-manager.io" - clientTLS: false + clientTLS: true podTemplate: spec: containers: @@ -812,11 +829,6 @@ spec: limits: cpu: 2 memory: "2Gi" - configuration: - secretName: ms-custom-config - authSecret: - kind: Secret - name: mssqlserver-auth storageType: Durable storage: storageClassName: "longhorn" @@ -847,36 +859,28 @@ spec: release: prometheus ``` -Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. +Convert `spec.tls.clientTLS` to `true`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Mssqlserver` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` mssqlserverOpsRequest to update the `Mssqlserver` database tls. List the resources created by `gitops` operator in the `demo` namespace. -Now, `gitops` operator will detect the monitoring changes and create a `Restart` mssqlserverOpsRequest to add the `Mssqlserver` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get ms,msops -n demo NAME VERSION STATUS AGE -mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 11m +mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 20m NAME TYPE STATUS AGE -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 5h9m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfigure-6i2hvt Reconfigure Successful 4h4m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-restart-hoi536 Restart Successful 6m8s -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-otytes RotateAuth Successful 3h53m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-versionupdate-mlq0kn UpdateVersion Successful 120m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 4h48m -mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 4h33m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-horizontalscaling-28njbi HorizontalScaling Successful 23h +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfigure-6i2hvt Reconfigure Successful 22h +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-reconfiguretls-hq78lx ReconfigureTLS Successful 12m +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-restart-hoi536 Restart Successful 18h +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-otytes RotateAuth Successful 22h +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-versionupdate-mlq0kn UpdateVersion Successful 20h +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 23h +mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 23h ``` -Verify the monitoring is enabled by checking the prometheus targets. - -There are some other fields that will trigger `Restart` ops request. -- `.spec.monitor` -- `.spec.spec.archiver` -- `.spec.remoteReplica` -- `spec.replication` -- `.spec.standbyMode` -- `.spec.streamingMode` -- `.spec.enforceGroup` -- `.spec.sslMode` etc. +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can change the value of the `.spec.tls.clientTLS` field for Mssqlserver. ## Next Steps diff --git a/docs/guides/mysql/gitops/_index.md b/docs/guides/mysql/gitops/_index.md index 80ccea8160..fd521c3014 100755 --- a/docs/guides/mysql/gitops/_index.md +++ b/docs/guides/mysql/gitops/_index.md @@ -1,10 +1,10 @@ --- -title: GitOps PostgreSQL +title: MySQL GitOps menu: docs_{{ .version }}: - identifier: pg-gitops-postgres + identifier: guides-mysql-gitops name: GitOps - parent: pg-postgres-guides - weight: 40 + parent: guides-mysql + weight: 140 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mysql/gitops/gitops.md b/docs/guides/mysql/gitops/gitops.md index 2f56baef23..5608038d97 100644 --- a/docs/guides/mysql/gitops/gitops.md +++ b/docs/guides/mysql/gitops/gitops.md @@ -1,10 +1,10 @@ --- -title: GitOps MySQL +title: GitOps MySQL menu: docs_{{ .version }}: - identifier: my-using-gitops + identifier: mysql-gitops name: GitOps MySQL - parent: my-gitops-MySQL + parent: guides-mysql-gitops weight: 15 menu_name: docs_{{ .version }} section_menu_id: guides @@ -63,26 +63,20 @@ metadata: name: my-gitops namespace: demo spec: + version: "9.4.0" replicas: 3 - version: "16.6" + topology: + mode: GroupReplication + group: + mode: Single-Primary storageType: Durable - podTemplate: - spec: - containers: - - name: MySQL - resources: - limits: - memory: 1Gi - requests: - cpu: 500m - memory: 1Gi storage: - storageClassName: "standard" + storageClassName: longhorn accessModes: - ReadWriteOnce resources: requests: - storage: 1Gi + storage: 2Gi deletionPolicy: WipeOut ``` @@ -100,12 +94,12 @@ Our `gitops` operator will create an actual `MySQL` database CR in the cluster. ```bash -$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com -n demo +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com -n demo NAME AGE -mysql.gitops.kubedb.com/my-gitops 172m +mysql.gitops.kubedb.com/my-gitops 76m NAME VERSION STATUS AGE -mysql.kubedb.com/my-gitops 9.1.0 Ready 172m +mysql.kubedb.com/my-gitops 9.4.0 Ready 76m ``` List the resources created by `kubedb` operator created for `kubedb.com/v1` MySQL. @@ -113,29 +107,30 @@ List the resources created by `kubedb` operator created for `kubedb.com/v1` MySQ ```bash $ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=my-gitops' NAME AGE -petset.apps.k8s.appscode.com/my-gitops 174m +petset.apps.k8s.appscode.com/my-gitops 78m NAME READY STATUS RESTARTS AGE -pod/my-gitops-0 2/2 Running 0 133m -pod/my-gitops-1 2/2 Running 0 129m -pod/my-gitops-2 2/2 Running 0 132m +pod/my-gitops-0 2/2 Running 0 78m +pod/my-gitops-1 2/2 Running 0 75m +pod/my-gitops-2 2/2 Running 0 75m NAME TYPE DATA AGE -secret/my-gitops-auth kubernetes.io/basic-auth 2 174m +secret/my-gitops-auth kubernetes.io/basic-auth 2 78m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/my-gitops ClusterIP 10.43.39.209 3306/TCP 174m -service/my-gitops-pods ClusterIP None 3306/TCP 174m -service/my-gitops-standby ClusterIP 10.43.212.101 3306/TCP 174m +service/my-gitops ClusterIP 10.43.236.155 3306/TCP 78m +service/my-gitops-pods ClusterIP None 3306/TCP 78m +service/my-gitops-standby ClusterIP 10.43.239.55 3306/TCP 78m NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/my-gitops kubedb.com/mysql 9.1.0 174m +appbinding.appcatalog.appscode.com/my-gitops kubedb.com/mysql 9.4.0 78m ``` ## Update MySQL Database using GitOps ### Scale MySQL Database Resources + Update the `MySQL.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 @@ -144,21 +139,25 @@ metadata: name: my-gitops namespace: demo spec: + version: "9.4.0" replicas: 3 - version: "16.6" + topology: + mode: GroupReplication + group: + mode: Single-Primary storageType: Durable podTemplate: spec: containers: - - name: MySQL + - name: mysql resources: limits: - memory: 2Gi + memory: 1.5Gi requests: cpu: 700m - memory: 2Gi + memory: 1.5Gi storage: - storageClassName: "standard" + storageClassName: longhorn accessModes: - ReadWriteOnce resources: @@ -167,7 +166,7 @@ spec: deletionPolicy: WipeOut ``` -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. +Resource Requests and Limits are updated to `700m` CPU and `1536Mi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. Now, `gitops` operator will detect the resource changes and create a `MySQLOpsRequest` to update the `MySQL` database. List the resources created by `gitops` operator in the `demo` namespace. @@ -177,7 +176,7 @@ NAME AGE mysql.gitops.kubedb.com/my-gitops 178m NAME VERSION STATUS AGE -mysql.kubedb.com/my-gitops 9.1.0 Ready 178m +mysql.kubedb.com/my-gitops 9.4.0 Ready 178m NAME TYPE STATUS AGE mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-mw8s6j VerticalScaling Successful 144m @@ -185,18 +184,16 @@ mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-mw8s6j VerticalScal After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo my-gitops-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo my-gitops-0 -o json | jq '.spec.containers[0].resources' { "limits": { - "cpu": "1", "memory": "1536Mi" }, "requests": { - "cpu": "500m", - "memory": "1Gi" + "cpu": "700m", + "memory": "1536Mi" } } - ``` ### Scale MySQL Replicas @@ -208,21 +205,25 @@ metadata: name: my-gitops namespace: demo spec: - replicas: 5 - version: "16.6" + version: "9.4.0" + replicas: 4 + topology: + mode: GroupReplication + group: + mode: Single-Primary storageType: Durable podTemplate: spec: containers: - - name: MySQL + - name: mysql resources: limits: - memory: 2Gi + memory: 1.5Gi requests: cpu: 700m - memory: 2Gi + memory: 1.5Gi storage: - storageClassName: "standard" + storageClassName: longhorn accessModes: - ReadWriteOnce resources: @@ -231,20 +232,20 @@ spec: deletionPolicy: WipeOut ``` -Update the `replicas` to `5`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. +Update the `replicas` to `4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` MySQLOpsRequest to update the `MySQL` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo +$ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo NAME AGE -mysql.gitops.kubedb.com/my-gitops 178m +mysql.gitops.kubedb.com/my-gitops 101m NAME VERSION STATUS AGE -mysql.kubedb.com/my-gitops 9.1.0 Ready 178m +mysql.kubedb.com/my-gitops 9.4.0 Ready 101m NAME TYPE STATUS AGE -mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-s9lyzc HorizontalScaling Successful 117m -mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-mw8s6j VerticalScaling Successful 144m +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-h542j4 HorizontalScaling Successful 5m1s +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-zbtqnv VerticalScaling Successful 19m ``` @@ -252,10 +253,10 @@ After Ops Request becomes `Successful`, We can validate the changes by checking ```bash $ kubectl get pod -n demo -l 'app.kubernetes.io/instance=my-gitops' NAME READY STATUS RESTARTS AGE -my-gitops-0 2/2 Running 0 144m -my-gitops-1 2/2 Running 0 140m -my-gitops-2 2/2 Running 0 143m - +my-gitops-0 2/2 Running 0 15m +my-gitops-1 2/2 Running 0 19m +my-gitops-2 2/2 Running 0 17m +my-gitops-3 2/2 Running 0 5m37s ``` We can also scale down the replicas by updating the `replicas` fields. @@ -270,56 +271,60 @@ metadata: name: my-gitops namespace: demo spec: - replicas: 5 - version: "16.6" + version: "9.4.0" + replicas: 4 + topology: + mode: GroupReplication + group: + mode: Single-Primary storageType: Durable podTemplate: spec: containers: - - name: MySQL + - name: mysql resources: limits: - memory: 2Gi + memory: 1.5Gi requests: cpu: 700m - memory: 2Gi + memory: 1.5Gi storage: - storageClassName: "standard" + storageClassName: longhorn accessModes: - ReadWriteOnce resources: requests: - storage: 10Gi + storage: 2Gi deletionPolicy: WipeOut ``` -Update the `storage.resources.requests.storage` to `10Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` MySQLOpsRequest to update the `MySQL` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo -NAME AGE -MySQL.gitops.kubedb.com/my-gitops 27m +NAME AGE +mysql.gitops.kubedb.com/my-gitops 104m + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.4.0 Ready 104m -NAME VERSION STATUS AGE -MySQL.kubedb.com/my-gitops 16.6 Ready 27m +NAME TYPE STATUS AGE +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-h542j4 HorizontalScaling Successful 8m23s +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-zbtqnv VerticalScaling Successful 22m +mysqlopsrequest.ops.kubedb.com/my-gitops-volumeexpansion-tzncw1 VolumeExpansion Successful 112s -NAME TYPE STATUS AGE -MySQLopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-wvxu5x HorizontalScaling Successful 6m -MySQLopsrequest.ops.kubedb.com/my-gitops-verticalscaling-i0kr1l VerticalScaling Successful 13m -MySQLopsrequest.ops.kubedb.com/my-gitops-volumeexpansion-2j5x5g VolumeExpansion Progressing 2s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash $ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=my-gitops' -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-my-gitops-0 Bound pvc-061f3622-234f-4f91-b4d1-b81aa8739503 10Gi RWO standard 30m -data-my-gitops-1 Bound pvc-045fc563-fb4e-416c-a9c2-b20c96532978 10Gi RWO standard 30m -data-my-gitops-2 Bound pvc-a0f1d8fd-a677-4407-80b1-104b9f7b4cd1 10Gi RWO standard 30m -data-my-gitops-3 Bound pvc-060b6fab-0c2d-4935-b31b-2866be68dd6f 10Gi RWO standard 8m58s -data-my-gitops-4 Bound pvc-8149b579-a40f-4cd8-ac37-6a2401fd7807 10Gi RWO standard 8m23s +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +data-my-gitops-0 Bound pvc-c926c69f-ff5e-4f93-be78-1fc1d39da25c 2Gi RWO longhorn 105m +data-my-gitops-1 Bound pvc-8bfcf4d8-37fb-4543-96c5-7a656270967a 2Gi RWO longhorn 101m +data-my-gitops-2 Bound pvc-238989bc-0a53-4db8-a3c2-2ce77aee4042 2Gi RWO longhorn 101m +data-my-gitops-3 Bound pvc-5345bc6a-baad-461a-a1fe-108e75c32a11 2Gi RWO longhorn 8m41s ``` ## Reconfigure MySQL @@ -364,9 +369,10 @@ To know more about this configuration file, check [here](/docs/guides/MySQL/conf ```yaml apiVersion: v1 stringData: - user.conf: | - max_connections=200 - shared_buffers=256MB + user.cnf: | + [mysqld] + max_connections = 200 + read_buffer_size = 1048575 kind: Secret metadata: name: my-configuration @@ -392,28 +398,32 @@ metadata: name: my-gitops namespace: demo spec: + version: "9.6.0" + replicas: 4 configSecret: - name: my-configuration - replicas: 5 - version: "16.6" + name: my-config + topology: + mode: GroupReplication + group: + mode: Single-Primary storageType: Durable podTemplate: spec: containers: - - name: MySQL + - name: mysql resources: limits: - memory: 2Gi + memory: 1.5Gi requests: cpu: 700m - memory: 2Gi + memory: 1.5Gi storage: - storageClassName: "standard" + storageClassName: longhorn accessModes: - ReadWriteOnce resources: requests: - storage: 10Gi + storage: 2Gi deletionPolicy: WipeOut ``` @@ -423,22 +433,23 @@ Now, `gitops` operator will detect the configuration changes and create a `Recon ```bash $ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo -NAME AGE -MySQL.gitops.kubedb.com/my-gitops 36m +NAME AGE +mysql.gitops.kubedb.com/my-gitops 126m -NAME VERSION STATUS AGE -MySQL.kubedb.com/my-gitops 16.6 Ready 36m +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.4.0 Ready 126m -NAME TYPE STATUS AGE -MySQLopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-wvxu5x HorizontalScaling Successful 15m -MySQLopsrequest.ops.kubedb.com/my-gitops-reconfigure-i4r23j Reconfigure Progressing 1s -MySQLopsrequest.ops.kubedb.com/my-gitops-verticalscaling-i0kr1l VerticalScaling Successful 23m +NAME TYPE STATUS AGE +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-h542j4 HorizontalScaling Successful 30m +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfigure-yskbt5 Reconfigure Successful 18m +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-zbtqnv VerticalScaling Successful 44m +mysqlopsrequest.ops.kubedb.com/my-gitops-volumeexpansion-tzncw1 VolumeExpansion Successful 23m ``` After Ops Request becomes `Succesful`, lets check these parameters, ```bash -$ kubectl exec -it -n demo my-gitops-0 -- bash +$ kubectl exec -it -n demo my-gitops-0 -- bash Defaulted container "mysql" out of: mysql, mysql-coordinator, mysql-init (init) bash-5.1$ mysql -uroot -p$MYSQL_ROOT_PASSWORD mysql: [Warning] Using a password on the command line interface can be insecure. @@ -466,14 +477,14 @@ mysql> show variables like 'read_buffer_size'; +------------------+---------+ | Variable_name | Value | +------------------+---------+ -| read_buffer_size | 1048576 | +| read_buffer_size | 1044480 | +------------------+---------+ -1 row in set (0.01 sec) + ``` You can check the other pods same way. So we have configured custom parameters. -> We can also reconfigure the parameters creating another secret and reference the secret in the `configSecret` field. Also you can remove the `configSecret` field to use the default parameters. +> We can also reconfigure the parameters creating another secret and reference the secret in the `configuration.secretName` field. Also you can remove the `configuration` field to use the default parameters. ### Rotate MySQL Auth @@ -484,11 +495,11 @@ We will do that using gitops, create the file `kubedb/my-auth.yaml` with the fol ```yaml apiVersion: v1 data: - password: cGdwYXNzd29yZA== - username: cG9zdGdyZXM= + password: bXlwYXNzd29yZA== + username: cm9vdA== kind: Secret metadata: - name: my-rotate-auth + name: myauth namespace: demo type: kubernetes.io/basic-auth ``` @@ -511,69 +522,68 @@ metadata: name: my-gitops namespace: demo spec: - version: "9.1.0" - replicas: 3 + version: "9.6.0" + replicas: 4 + configSecret: + name: my-config authSecret: kind: Secret - name: mysql-quickstart-auth-user - configuration: - secretName: my-configuration + name: myauth topology: mode: GroupReplication group: mode: Single-Primary + storageType: Durable podTemplate: spec: containers: - - name: mysql - resources: - limits: - cpu: 1000m - memory: 1.5Gi - requests: - cpu: 500m - memory: 1Gi - storageType: Durable + - name: mysql + resources: + limits: + memory: 1.5Gi + requests: + cpu: 700m + memory: 1.5Gi storage: storageClassName: longhorn accessModes: - ReadWriteOnce resources: requests: - storage: 1Gi + storage: 2Gi deletionPolicy: WipeOut ``` -Change the `authSecret` field to `my-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. +Change the `authSecret.name` field to `myauth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MySQLOpsRequest to update the `MySQL` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo NAME AGE -mysql.gitops.kubedb.com/my-gitops 5h2m +mysql.gitops.kubedb.com/my-gitops 19h NAME VERSION STATUS AGE -mysql.kubedb.com/my-gitops 9.1.0 Ready 5h2m +mysql.kubedb.com/my-gitops 9.4.0 Ready 19h NAME TYPE STATUS AGE -mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-s9lyzc HorizontalScaling Successful 4h1m -mysqlopsrequest.ops.kubedb.com/my-gitops-reconfigure-q4yrg0 Reconfigure Successful 4h28m -mysqlopsrequest.ops.kubedb.com/my-gitops-rotate-auth-5lg5o3 RotateAuth Successful 10m -mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-mw8s6j VerticalScaling Successful 4h28m - +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-h542j4 HorizontalScaling Successful 18h +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfigure-b5s92r Reconfigure Successful 60m +mysqlopsrequest.ops.kubedb.com/my-gitops-rotate-auth-q2z2vf RotateAuth Successful 24m +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-zbtqnv VerticalScaling Successful 18h +mysqlopsrequest.ops.kubedb.com/my-gitops-volumeexpansion-tzncw1 VolumeExpansion Successful 18h ``` After Ops Request becomes `Successful`, We can validate the changes connecting MySQL with new credentials. ```bash $ kubectl exec -it -n demo my-gitops-0 -c mysql -- bash -bash-5.1$ mysql -uroot -p"Mysql2" +bash-5.1$ mysql -uroot -p"mypassword" mysql: [Warning] Using a password on the command line interface can be insecure. Welcome to the MySQL monitor. Commands end with ; or \g. -Your MySQL connection id is 347 -Server version: 9.1.0 MySQL Community Server - GPL +Your MySQL connection id is 808 +Server version: 9.4.0 MySQL Community Server - GPL -Copyright (c) 2000, 2024, Oracle and/or its affiliates. +Copyright (c) 2000, 2025, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective @@ -581,7 +591,7 @@ owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. -mysql> SHOW DATABASES; +mysql> SHOW DATABASES; +--------------------+ | Database | +--------------------+ @@ -591,48 +601,49 @@ mysql> SHOW DATABASES; | performance_schema | | sys | +--------------------+ -5 rows in set (0.00 sec) - +5 rows in set (0.001 sec) ``` ### TLS configuration We can add, rotate or remove TLS configuration using `gitops`. -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in MySQL. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. +First, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, -- Start off by generating a ca certificates using openssl. +- Start off by generating our ca-certificates using openssl, ```bash -$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" -Generating a RSA private key -................+++++ -........................+++++ -writing new private key to './ca.key' ------ +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=mysql/O=kubedb" ``` -- Now we are going to create a ca-secret using the certificate files that we have just generated. +- create a secret using the certificate files we have just generated, ```bash -$ kubectl create secret tls mysql-ca \ - --cert=ca.crt \ - --key=ca.key \ - --namespace=demo -secret/mysql-ca created +kubectl create secret tls my-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/my-ca created ``` -Now, Let's create an `Issuer` using the `MySQL-ca` secret that we have just created. The `YAML` file looks like this: +Now, we are going to create an `Issuer` using the `my-ca` secret that hols the ca-certificate we have just created. Below is the YAML of the `Issuer` cr that we are going to create, ```yaml apiVersion: cert-manager.io/v1 kind: Issuer metadata: - name: my-issuer + name: mysql-issuer namespace: demo spec: ca: - secretName: MySQL-ca + secretName: my-ca +``` + +Let’s create the `Issuer` cr we have shown above, + +```bash +kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mysql/tls/configure/yamls/issuer.yaml +issuer.cert-manager.io/mysql-issuer created ``` Let's add that to our `kubedb/my-issuer.yaml` file. File structure will look like this, @@ -654,118 +665,74 @@ metadata: name: my-gitops namespace: demo spec: - version: "9.1.0" - replicas: 3 + version: "9.4.0" + replicas: 4 + configSecret: + name: my-config authSecret: kind: Secret - name: mysql-quickstart-auth-user - configuration: - secretName: my-configuration - topology: - mode: GroupReplication - group: - mode: Single-Primary - requireSSL: true + name: myauth tls: issuerRef: apiGroup: cert-manager.io kind: Issuer - name: my-issuer - certificates: - - alias: server - subject: - organizations: - - kubedb:server - dnsNames: - - localhost - ipAddresses: - - "127.0.0.1" + name: mysql-issuer + topology: + mode: GroupReplication + group: + mode: Single-Primary + storageType: Durable podTemplate: spec: containers: - - name: mysql - resources: - limits: - cpu: 1000m - memory: 1.5Gi - requests: - cpu: 500m - memory: 1Gi - storageType: Durable + - name: mysql + resources: + limits: + memory: 1.5Gi + requests: + cpu: 700m + memory: 1.5Gi storage: storageClassName: longhorn accessModes: - ReadWriteOnce resources: requests: - storage: 1Gi + storage: 2Gi deletionPolicy: WipeOut ``` -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. +Add `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` MySQLOpsRequest to update the `MySQL` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo NAME AGE -mysql.gitops.kubedb.com/my-gitops 6h7m +mysql.gitops.kubedb.com/my-gitops 20h NAME VERSION STATUS AGE -mysql.kubedb.com/my-gitops 9.1.0 Ready 6h7m +mysql.kubedb.com/my-gitops 9.4.0 Ready 20h NAME TYPE STATUS AGE -mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-s9lyzc HorizontalScaling Successful 5h6m -mysqlopsrequest.ops.kubedb.com/my-gitops-reconfigure-q4yrg0 Reconfigure Successful 5h33m -mysqlopsrequest.ops.kubedb.com/my-gitops-reconfiguretls-39ir77 ReconfigureTLS Successful 4m39s -mysqlopsrequest.ops.kubedb.com/my-gitops-rotate-auth-5lg5o3 RotateAuth Successful 74m -mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-mw8s6j VerticalScaling Successful 5h33m - +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-h542j4 HorizontalScaling Successful 18h +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfigure-b5s92r Reconfigure Successful 74m +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfiguretls-8kwaw9 ReconfigureTLS Successful 9m51s +mysqlopsrequest.ops.kubedb.com/my-gitops-rotate-auth-q2z2vf RotateAuth Successful 38m +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-zbtqnv VerticalScaling Successful 18h +mysqlopsrequest.ops.kubedb.com/my-gitops-volumeexpansion-tzncw1 VolumeExpansion Successful 18h ``` After Ops Request becomes `Successful`, We can validate the changes connecting MySQL with new credentials. ```bash -$ kubectl exec -it -n demo my-gitops-0 -c mysql -- bash -bash-5.1$ mysql -uroot -p"Mysql2" -mysql: [Warning] Using a password on the command line interface can be insecure. -Welcome to the MySQL monitor. Commands end with ; or \g. -Your MySQL connection id is 347 -Server version: 9.1.0 MySQL Community Server - GPL - -Copyright (c) 2000, 2024, Oracle and/or its affiliates. - -Oracle is a registered trademark of Oracle Corporation and/or its -affiliates. Other names may be trademarks of their respective -owners. - -Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. - -mysql> SHOW DATABASES; -+--------------------+ -| Database | -+--------------------+ -| information_schema | -| kubedb_system | -| mysql | -| performance_schema | -| sys | -+--------------------+ -5 rows in set (0.00 sec) - -mysql> command terminated with exit code 137 -banusree@bonusree-datta-PC ~ [SIGKILL]> kubectl exec -it -n demo my-gitops-0 -c mysql -- bash -bash-5.1$ ls /etc/mysql/certs/ -ca.crt client.crt client.key server.crt server.key -bash-5.1$ mysql -u${MYSQL_ROOT_USERNAME} -p{MYSQL_ROOT_PASSWORD} -mysql: [Warning] Using a password on the command line interface can be insecure. -ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) -bash-5.1$ mysql -uroot -p"Mysql2" +$ kubectl exec -it -n demo my-gitops-0 -c mysql -- bash +bash-5.1$ mysql -uroot -p$MYSQL_ROOT_PASSWORD mysql: [Warning] Using a password on the command line interface can be insecure. Welcome to the MySQL monitor. Commands end with ; or \g. -Your MySQL connection id is 201 -Server version: 9.1.0 MySQL Community Server - GPL +Your MySQL connection id is 505 +Server version: 9.4.0 MySQL Community Server - GPL -Copyright (c) 2000, 2024, Oracle and/or its affiliates. +Copyright (c) 2000, 2025, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective @@ -816,7 +783,7 @@ mysql> SHOW VARIABLES LIKE '%ssl%'; | ssl_session_cache_mode | ON | | ssl_session_cache_timeout | 300 | +---------------------------------------------------+-----------------------------+ -38 rows in set (0.00 sec) +38 rows in set (0.016 sec) mysql> SHOW VARIABLES LIKE '%require_secure_transport%'; +--------------------------+-------+ @@ -824,9 +791,7 @@ mysql> SHOW VARIABLES LIKE '%require_secure_transport%'; +--------------------------+-------+ | require_secure_transport | OFF | +--------------------------+-------+ -1 row in set (0.00 sec) - - +1 row in set (0.002 sec) ``` > We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for MySQL. @@ -835,7 +800,7 @@ mysql> SHOW VARIABLES LIKE '%require_secure_transport%'; List MySQL versions using `kubectl get MySQLversion` and choose desired version that is compatible for umyrade from current version. Check the version constraints and ops request [here](/docs/guides/MySQL/update-version/versionumyrading/index.md). -Let's choose `17.4` in this example. +Let's choose `9.6.0` in this example. Update the `MySQL.yaml` with the following, ```yaml @@ -845,68 +810,71 @@ metadata: name: my-gitops namespace: demo spec: + version: "9.6.0" + replicas: 4 + configSecret: + name: my-config authSecret: kind: Secret - name: my-rotate-auth - configSecret: - name: my-configuration - replicas: 5 - version: "17.4" - storageType: Durable - sslMode: verify-full + name: myauth tls: issuerRef: apiGroup: cert-manager.io - name: my-issuer kind: Issuer - certificates: - - alias: server - subject: - organizations: - - kubedb:server - dnsNames: - - localhost - ipAddresses: - - "127.0.0.1" + name: mysql-issuer + monitor: + agent: prometheus.io/operator + prometheus: + serviceMonitor: + labels: + release: prometheus + interval: 10s + topology: + mode: GroupReplication + group: + mode: Single-Primary + storageType: Durable podTemplate: spec: containers: - - name: MySQL + - name: mysql resources: limits: - memory: 2Gi + memory: 1.5Gi requests: cpu: 700m - memory: 2Gi + memory: 1.5Gi storage: - storageClassName: "standard" + storageClassName: longhorn accessModes: - ReadWriteOnce resources: requests: - storage: 10Gi + storage: 2Gi deletionPolicy: WipeOut ``` -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. +Update the `version` field to `9.6.0`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. Now, `gitops` operator will detect the version changes and create a `VersionUpdate` MySQLOpsRequest to update the `MySQL` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo -NAME AGE -MySQL.gitops.kubedb.com/my-gitops 3h25m - -NAME VERSION STATUS AGE -MySQL.kubedb.com/my-gitops 16.6 Ready 3h25m - -NAME TYPE STATUS AGE -MySQLopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-wvxu5x HorizontalScaling Successful 3h3m -MySQLopsrequest.ops.kubedb.com/my-gitops-reconfigure-i4r23j Reconfigure Successful 168m -MySQLopsrequest.ops.kubedb.com/my-gitops-reconfiguretls-91fseg ReconfigureTLS Successful 7m33s -MySQLopsrequest.ops.kubedb.com/my-gitops-rotate-auth-zot83x RotateAuth Successful 161m -MySQLopsrequest.ops.kubedb.com/my-gitops-versionupdate-1wxgt9 UpdateVersion Progressing 4s -MySQLopsrequest.ops.kubedb.com/my-gitops-verticalscaling-i0kr1l VerticalScaling Successful 3h11m +NAME AGE +mysql.gitops.kubedb.com/my-gitops 22h + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.6.0 Ready 22h + +NAME TYPE STATUS AGE +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-h542j4 HorizontalScaling Successful 20h +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfigure-b5s92r Reconfigure Successful 3h40m +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfiguretls-8kwaw9 ReconfigureTLS Successful 156m +mysqlopsrequest.ops.kubedb.com/my-gitops-rotate-auth-q2z2vf RotateAuth Successful 3h5m +mysqlopsrequest.ops.kubedb.com/my-gitops-versionupdate-bskr89 UpdateVersion Successful 142m +mysqlopsrequest.ops.kubedb.com/my-gitops-versionupdate-g2n3y9 UpdateVersion Successful 132m +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-zbtqnv VerticalScaling Successful 21h +mysqlopsrequest.ops.kubedb.com/my-gitops-volumeexpansion-tzncw1 VolumeExpansion Successful 20h ``` @@ -914,13 +882,11 @@ Now, we are going to verify whether the `MySQL`, `PetSet` and it's `Pod` have up ```bash $ kubectl get MySQL -n demo my-gitops -o=jsonpath='{.spec.version}{"\n"}' -17.4 - +9.6.0 $ kubectl get petset -n demo my-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/MySQL:17.4-alpine - +ghcr.io/appscode-images/mysql:9.6.0-oracle@sha256:16e6b7b93df8aa255d3886ff33c2d78093d1cd2346522d14bf1b9cc0ad03a460 $ kubectl get pod -n demo my-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/MySQL:17.4-alpine +ghcr.io/appscode-images/mysql:9.6.0-oracle@sha256:16e6b7b93df8aa255d3886ff33c2d78093d1cd2346522d14bf1b9cc0ad03a460 ``` ### Enable Monitoring @@ -935,39 +901,18 @@ metadata: name: my-gitops namespace: demo spec: + version: "9.6.0" + replicas: 4 + configSecret: + name: my-config authSecret: kind: Secret - name: my-rotate-auth - configSecret: - name: my-configuration - replicas: 5 - version: "17.4" - storageType: Durable - sslMode: verify-full + name: myauth tls: issuerRef: apiGroup: cert-manager.io - name: my-issuer kind: Issuer - certificates: - - alias: server - subject: - organizations: - - kubedb:server - dnsNames: - - localhost - ipAddresses: - - "127.0.0.1" - podTemplate: - spec: - containers: - - name: MySQL - resources: - limits: - memory: 2Gi - requests: - cpu: 700m - memory: 2Gi + name: mysql-issuer monitor: agent: prometheus.io/operator prometheus: @@ -975,13 +920,28 @@ spec: labels: release: prometheus interval: 10s + topology: + mode: GroupReplication + group: + mode: Single-Primary + storageType: Durable + podTemplate: + spec: + containers: + - name: mysql + resources: + limits: + memory: 1.5Gi + requests: + cpu: 700m + memory: 1.5Gi storage: - storageClassName: "standard" + storageClassName: longhorn accessModes: - ReadWriteOnce resources: requests: - storage: 10Gi + storage: 2Gi deletionPolicy: WipeOut ``` @@ -990,20 +950,21 @@ Add `monitor` field in the spec. Commit the changes and push to your Git reposit Now, `gitops` operator will detect the monitoring changes and create a `Restart` MySQLOpsRequest to add the `MySQL` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get mysql.gitops.kubedb.com,mysql.kubedb.com,MySQLopsrequest -n demo -NAME AGE -MySQL.gitops.kubedb.com/my-gitops 3h34m - -NAME VERSION STATUS AGE -MySQL.kubedb.com/my-gitops 16.6 NotReady 3h34m - -NAME TYPE STATUS AGE -MySQLopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-wvxu5x HorizontalScaling Successful 3h13m -MySQLopsrequest.ops.kubedb.com/my-gitops-reconfigure-i4r23j Reconfigure Successful 177m -MySQLopsrequest.ops.kubedb.com/my-gitops-reconfiguretls-91fseg ReconfigureTLS Successful 16m -MySQLopsrequest.ops.kubedb.com/my-gitops-restart-nhjk9u Restart Progressing 2s -MySQLopsrequest.ops.kubedb.com/my-gitops-rotate-auth-zot83x RotateAuth Successful 170m -MySQLopsrequest.ops.kubedb.com/my-gitops-versionupdate-1wxgt9 UpdateVersion Successful 9m30s -MySQLopsrequest.ops.kubedb.com/my-gitops-verticalscaling-i0kr1l VerticalScaling Successful 3h21m +NAME AGE +mysql.gitops.kubedb.com/my-gitops 22h + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.6.0 Ready 22h + +NAME TYPE STATUS AGE +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-h542j4 HorizontalScaling Successful 21h +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfigure-b5s92r Reconfigure Successful 3h57m +mysqlopsrequest.ops.kubedb.com/my-gitops-reconfiguretls-8kwaw9 ReconfigureTLS Successful 172m +mysqlopsrequest.ops.kubedb.com/my-gitops-restart-lb1wyu Restart Successful 9m36s +mysqlopsrequest.ops.kubedb.com/my-gitops-rotate-auth-q2z2vf RotateAuth Successful 3h21m +mysqlopsrequest.ops.kubedb.com/my-gitops-versionupdate-bskr89 UpdateVersion Successful 158m +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-zbtqnv VerticalScaling Successful 21h +mysqlopsrequest.ops.kubedb.com/my-gitops-volumeexpansion-tzncw1 VolumeExpansion Successful 21h ``` Verify the monitoring is enabled by checking the prometheus targets. diff --git a/docs/guides/mysql/gitops/overview.md b/docs/guides/mysql/gitops/overview.md index bccfd07fc7..1897251aa4 100644 --- a/docs/guides/mysql/gitops/overview.md +++ b/docs/guides/mysql/gitops/overview.md @@ -5,7 +5,7 @@ menu: docs_{{ .version }}: identifier: my-gitops-overview name: Overview - parent: my-gitops-MySQL + parent: guides-mysql-gitops weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides From 518d40cd71fce21721895f06441a77c6883d1f2e Mon Sep 17 00:00:00 2001 From: Bonusree Date: Thu, 16 Apr 2026 10:29:45 +0600 Subject: [PATCH 22/51] new gitops Signed-off-by: Bonusree --- docs/guides/elasticsearch/gitops/_index.md | 10 - docs/guides/elasticsearch/gitops/gitops.md | 765 ----------------- docs/guides/elasticsearch/gitops/overview.md | 50 -- docs/guides/kafka/gitops/_index.md | 2 +- docs/guides/redis/gitops/_index.md | 10 - docs/guides/redis/gitops/gitops.md | 821 ------------------- docs/guides/redis/gitops/overview.md | 50 -- 7 files changed, 1 insertion(+), 1707 deletions(-) delete mode 100644 docs/guides/elasticsearch/gitops/_index.md delete mode 100644 docs/guides/elasticsearch/gitops/gitops.md delete mode 100644 docs/guides/elasticsearch/gitops/overview.md delete mode 100644 docs/guides/redis/gitops/_index.md delete mode 100644 docs/guides/redis/gitops/gitops.md delete mode 100644 docs/guides/redis/gitops/overview.md diff --git a/docs/guides/elasticsearch/gitops/_index.md b/docs/guides/elasticsearch/gitops/_index.md deleted file mode 100644 index cc82b5f6bc..0000000000 --- a/docs/guides/elasticsearch/gitops/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Elasticsearch Gitops -menu: - docs_{{ .version }}: - identifier: es-gitops - name: Elasticsearch Gitops - parent: es-elasticsearch-guides - weight: 70 -menu_name: docs_{{ .version }} ---- diff --git a/docs/guides/elasticsearch/gitops/gitops.md b/docs/guides/elasticsearch/gitops/gitops.md deleted file mode 100644 index e3a2e57d22..0000000000 --- a/docs/guides/elasticsearch/gitops/gitops.md +++ /dev/null @@ -1,765 +0,0 @@ ---- -title: Elasticsearch Gitops Overview -description: Elasticsearch Gitops Overview -menu: - docs_{{ .version }}: - identifier: es-gitops-overview - name: Overview - parent: es-gitops - weight: 10 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - - - -> New to KubeDB? Please start [here](/docs/README.md). - -# GitOps Elasticsearch using KubeDB GitOps Operator - -This guide will show you how to use `KubeDB` GitOps operator to create Elasticsearch database and manage updates using GitOps woreslow. - -## Before You Begin - -- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, -you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). - -- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation -process to enable `GitOps` operator. - -- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes -cluster with the desired state defined in Git. - - ```bash - $ kubectl create ns monitoring - namespace/monitoring created - - $ kubectl create ns demo - namespace/demo created - ``` -> Note: YAML files used in this tutorial are stored in [docs/examples/elasticsearch](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/elasticsearch) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). - -We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). - -## Creating Apps via CLI - -### For Public Repository -```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace -``` - -### For Private Repository -#### Using HTTPS -```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password -``` - -#### Using SSH -```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa -``` - -## Create Elasticsearch Database using GitOps - -### Create a Elasticsearch GitOps CR -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch -metadata: - name: es-gitops - namespace: demo -spec: - version: xpack-8.2.3 - enableSSL: true - replicas: 2 - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - deletionPolicy: WipeOut -``` - -Create a directory like below, -```bash -$ tree . -├── kubedb - └── Elasticsearch.yaml -1 directories, 1 files -``` - -Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is created in your cluster. - -Our `gitops` operator will create an actual `Elasticsearch` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. - - -```bash -$ kubectl get Elasticsearch.gitops.kubedb.com,Elasticsearch.kubedb.com -n demo -NAME AGE -elasticsearch.gitops.kubedb.com/es-gitops 20m - -NAME VERSION STATUS AGE -elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 20m -``` - -List the resources created by `kubedb` operator created for `kubedb.com/v1` Elasticsearch. - -```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=es-gitops' -NAME AGE -petset.apps.k8s.appscode.com/es-gitops 20m - -NAME READY STATUS RESTARTS AGE -pod/es-gitops-0 1/1 Running 0 20m -pod/es-gitops-1 1/1 Running 0 19m - -NAME TYPE DATA AGE -secret/es-gitops-a1d7d4 Opaque 1 13m -secret/es-gitops-apm-system-cred kubernetes.io/basic-auth 2 20m -secret/es-gitops-auth kubernetes.io/basic-auth 2 20m -secret/es-gitops-beats-system-cred kubernetes.io/basic-auth 2 20m -secret/es-gitops-ca-cert kubernetes.io/tls 2 20m -secret/es-gitops-client-cert kubernetes.io/tls 3 20m -secret/es-gitops-config Opaque 1 20m -secret/es-gitops-http-cert kubernetes.io/tls 3 20m -secret/es-gitops-kibana-system-cred kubernetes.io/basic-auth 2 20m -secret/es-gitops-logstash-system-cred kubernetes.io/basic-auth 2 20m -secret/es-gitops-remote-monitoring-user-cred kubernetes.io/basic-auth 2 20m -secret/es-gitops-transport-cert kubernetes.io/tls 3 20m - -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/es-gitops ClusterIP 10.43.235.79 9200/TCP 20m -service/es-gitops-master ClusterIP None 9300/TCP 20m -service/es-gitops-pods ClusterIP None 9200/TCP 20m - -NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/es-gitops kubedb.com/elasticsearch 8.2.3 20m -``` - -## Update Elasticsearch Database using GitOps -### Scale Elasticsearch Replicas -Update the `Elasticsearch.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch -metadata: - name: es-gitops - namespace: demo -spec: - version: xpack-8.2.3 - enableSSL: true - replicas: 3 - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - deletionPolicy: WipeOut -``` - -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Elasticsearch` database replicas. List the -resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get es,esops -n demo -NAME VERSION STATUS AGE -elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 64m - -NAME TYPE STATUS AGE -elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-32p116 HorizontalScaling Successful 39m -``` - -After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, -```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=es-gitops' -NAME READY STATUS RESTARTS AGE -es-gitops-0 1/1 Running 0 36m -es-gitops-1 1/1 Running 0 16m -es-gitops-2 1/1 Running 0 15m -``` - - -We can also scale down the replicas by updating the `replicas` fields. -### Scale Elasticsearch Database Resources - -Update the `Elasticsearch.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch -metadata: - name: es-gitops - namespace: demo -spec: - version: xpack-8.2.3 - enableSSL: true - replicas: 3 - podTemplate: - spec: - containers: - - name: elasticsearch - resources: - limits: - cpu: 500m - memory: 1Gi - requests: - cpu: 100m - memory: 1Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - deletionPolicy: WipeOut - ``` - -Resource Requests and Limits are updated to `500m` CPU and `1Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. - -Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Elasticsearch` database. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get es,esops -n demo -NAME VERSION STATUS AGE -elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 64m - -NAME TYPE STATUS AGE -elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-injx1l HorizontalScaling Successful 15m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-x5mfy0 VerticalScaling Successful 39m - -``` - -After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, -```bash -$ kubectl get pod -n demo es-gitops-0 -o json | jq '.spec.containers[0].resources' -{ - "limits": { - "cpu": "500m", - "memory": "1Gi" - }, - "requests": { - "cpu": "100m", - "memory": "1Gi" - } -} - -``` - - -### Expand Elasticsearch Volume - -Update the `Elasticsearch.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch -metadata: - name: es-gitops - namespace: demo -spec: - version: xpack-8.2.3 - enableSSL: true - replicas: 3 - podTemplate: - spec: - containers: - - name: elasticsearch - resources: - limits: - cpu: 500m - memory: 1Gi - requests: - cpu: 100m - memory: 1Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - deletionPolicy: WipeOut -``` - -Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. - -Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `Elasticsearch` database volume. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get es,esops -n demo -NAME VERSION STATUS AGE -elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 3h1m - -NAME TYPE STATUS AGE -elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-32p116 HorizontalScaling Successful 157m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-x5mfy0 VerticalScaling Successful 157m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-sata37 VolumeExpansion Successful 38m - -``` - -After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, -```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=es-gitops' -NAME READY STATUS RESTARTS AGE -es-gitops-0 1/1 Running 0 36m -es-gitops-1 1/1 Running 0 16m -es-gitops-2 1/1 Running 0 15m -``` - -## Reconfigure Elasticsearch - -At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/elasticsearch/configuration/combined-cluster/index.md) -```yaml -apiVersion: v1 -stringData: - user.conf: | - max_connections=200 - shared_buffers=256MB -kind: Secret -metadata: - name: es-configuration - namespace: demo -type: Opaque -``` - -Now, we will add this file to `kubedb /es-configuration.yaml`. - -```bash -$ tree . -├── kubedb -│ ├── es-configuration.yaml -│ └── Elasticsearch.yaml -1 directories, 2 files -``` - -Update the `Elasticsearch.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch -metadata: - name: es-gitops - namespace: demo -spec: - version: xpack-8.2.3 - enableSSL: true - replicas: 3 - configuration: - secretName: es-configuration - podTemplate: - spec: - containers: - - name: elasticsearch - resources: - limits: - cpu: 500m - memory: 1Gi - requests: - cpu: 100m - memory: 1Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - deletionPolicy: WipeOut -``` - -Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. - -Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `Elasticsearch` database configuration. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get es,esops -n demo -NAME VERSION STATUS AGE -elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 3h53m - -NAME TYPE STATUS AGE -elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-32p116 HorizontalScaling Successful 3h29m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-wj5qyx Reconfigure Successful 3m42s -elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-lvh38k VerticalScaling Successful 99m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-sata37 VolumeExpansion Successful 90m -``` - - - -### Rotate Elasticsearch Auth - -To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. - -We will generate a secret named `es-rotate-auth` with the following content, - -```bash -$ kubectl create secret generic es-rotate-auth -n demo \ - --type=kubernetes.io/basic-auth \ - --from-literal=username=elastic \ - --from-literal=password=elasticsearch-secret -secret/es-rotate-auth created - -``` - - - -Update the `Elasticsearch.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch -metadata: - name: es-gitops - namespace: demo -spec: - version: xpack-8.2.3 - enableSSL: true - replicas: 3 - authSecret: - kind: Secret - name: es-rotate-auth - configuration: - secretName: es-configuration - podTemplate: - spec: - containers: - - name: elasticsearch - resources: - limits: - cpu: 500m - memory: 1Gi - requests: - cpu: 100m - memory: 1Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - deletionPolicy: WipeOut -``` - -Change the `authSecret` field to `es-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. - -Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `Elasticsearch` database auth. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get es,esops -n demo -NAME VERSION STATUS AGE -elasticsearch.kubedb.com/es-gitops xpack-9.1.9 Ready 18m - -NAME TYPE STATUS AGE -elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-wiezxp HorizontalScaling Successful 13m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-i9puam Reconfigure Successful 13m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-xisot8 RotateAuth Successful 4m38s -elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-7dyz6e VerticalScaling Successful 13m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-pptef3 VolumeExpansion Successful 13m -``` - - -### TLS configuration - -We can add, rotate or remove TLS configuration using `gitops`. - -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Elasticsearch. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. - -- Start off by generating a ca certificates using openssl. - -```bash -$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" -Generating a RSA private key -................+++++ -........................+++++ -writing new private key to './ca.key' ------ -``` - -- Now we are going to create a ca-secret using the certificate files that we have just generated. - -```bash -$ kubectl create secret tls Elasticsearch-ca \ - --cert=ca.crt \ - --key=ca.key \ - --namespace=demo -secret/Elasticsearch-ca created -``` - -Now, Let's create an `Issuer` using the `Elasticsearch-ca` secret that we have just created. The `YAML` file looks like this: - -```yaml -apiVersion: cert-manager.io/v1 -kind: Issuer -metadata: - name: es-issuer - namespace: demo -spec: - ca: - secretName: Elasticsearch-ca -``` - -Let's add that to our `kubedb /es-issuer.yaml` file. File structure will look like this, -```bash -$ tree . -├── kubedb -│ ├── es-configuration.yaml -│ ├── es-issuer.yaml -│ └── Elasticsearch.yaml -1 directories, 4 files -``` - -Update the `Elasticsearch.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch -metadata: - name: es-gitops - namespace: demo -spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: Elasticsearch - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Elasticsearch - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - storageType: Durable - deletionPolicy: WipeOut -``` - -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. - -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Elasticsearch` database tls. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get es,Elasticsearch,esops,pods -n demo -NAME TYPE VERSION STATUS AGE -Elasticsearch.kubedb.com/es-gitops kubedb.com/v1 3.9.0 Ready 41m - -NAME AGE -Elasticsearch.gitops.kubedb.com/es-gitops 75m - -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h -Elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -Elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h -Elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h - -``` - - -> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Elasticsearch. - -### Update Version - -List Elasticsearch versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/elasticsearch/update-version/update-version.md). - -Let's choose `4.0.0` in this example. - -Update the `Elasticsearch.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch -metadata: - name: es-gitops - namespace: demo -spec: - version: xpack-9.2.3 - replicas: 3 - authSecret: - kind: Secret - name: es-rotate-auth - configuration: - secretName: es-configuration - podTemplate: - spec: - containers: - - name: elasticsearch - resources: - limits: - cpu: 500m - memory: 1Gi - requests: - cpu: 100m - memory: 1Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - deletionPolicy: WipeOut -``` - -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. - -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Elasticsearch` database version. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get es,Elasticsearch,esops -n demo -NAME VERSION STATUS AGE -elasticsearch.kubedb.com/es-gitops xpack-9.2.3 Ready 64m - -NAME AGE -elasticsearch.gitops.kubedb.com/es-gitops 64m - -NAME TYPE STATUS AGE -elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-os8fon HorizontalScaling Successful 58m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-hrbrs1 Reconfigure Successful 58m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-s0tkka RotateAuth Successful 58m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-versionupdate-bn3rk4 UpdateVersion Successful 31m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-vhzkxl VerticalScaling Successful 58m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-bzqd4r VolumeExpansion Successful 58m - -``` - - -Now, we are going to verify whether the `Elasticsearch`, `PetSet` and it's `Pod` have updated with new image. Let's check, - -```bash -$ kubectl get Elasticsearch -n demo es-gitops -o=jsonpath='{.spec.version}{"\n"}' -xpack-9.2.3 - -$ kubectl get petset -n demo es-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/elastic:9.2.3@sha256:714f35c53d333fef7e673079d05ce80440caf2c20ca3dc9b3e366728527760bb - -$ kubectl get pod -n demo es-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/elastic:9.2.3@sha256:714f35c53d333fef7e673079d05ce80440caf2c20ca3dc9b3e366728527760bb -``` - -### Enable Monitoring - -If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). - -Update the `Elasticsearch.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Elasticsearch -metadata: - name: es-gitops - namespace: demo -spec: - version: xpack-9.2.3 - replicas: 3 - authSecret: - kind: Secret - name: es-rotate-auth - configuration: - secretName: es-configuration - podTemplate: - spec: - containers: - - name: elasticsearch - resources: - limits: - cpu: 500m - memory: 1Gi - requests: - cpu: 100m - memory: 1Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - deletionPolicy: WipeOut - monitor: - agent: prometheus.io/operator - prometheus: - serviceMonitor: - labels: - release: prometheus - interval: 10s -``` - -Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. - -Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Elasticsearch` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. -```bash -$ kubectl get Elasticsearches.gitops.kubedb.com,Elasticsearches.kubedb.com,Elasticsearchopsrequest -n demo -NAME AGE -elasticsearch.gitops.kubedb.com/es-gitops 106m - -NAME VERSION STATUS AGE -elasticsearch.kubedb.com/es-gitops xpack-9.2.3 Ready 106m - -NAME TYPE STATUS AGE -elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-os8fon HorizontalScaling Successful 101m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-hrbrs1 Reconfigure Successful 101m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-restart-7v0e29 Restart Successful 15m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-s0tkka RotateAuth Successful 101m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-versionupdate-bn3rk4 UpdateVersion Successful 73m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-vhzkxl VerticalScaling Successful 101m -elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-bzqd4r VolumeExpansion Successful 101m - -``` - -Verify the monitoring is enabled by checking the prometheus targets. - -There are some other fields that will trigger `Restart` ops request. -- `.spec.monitor` -- `.spec.spec.archiver` -- `.spec.remoteReplica` -- `spec.replication` -- `.spec.standbyMode` -- `.spec.streamingMode` -- `.spec.enforceGroup` -- `.spec.sslMode` etc. - - -## Next Steps - -[//]: # (- Learn Elasticsearch [GitOps](/docs/guides/elasticsearch/concepts/Elasticsearch-gitops.md)) -- Learn Elasticsearch Scaling - - [Horizontal Scaling](/docs/guides/elasticsearch/scaling/horizontal/combined.md) - - [Vertical Scaling](/docs/guides/elasticsearch/scaling/vertical/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/elasticsearch/update-version/overview.md) -- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/elasticsearch/monitoring/using-builtin-prometheus.md). -- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md) \ No newline at end of file diff --git a/docs/guides/elasticsearch/gitops/overview.md b/docs/guides/elasticsearch/gitops/overview.md deleted file mode 100644 index bfa01c2fff..0000000000 --- a/docs/guides/elasticsearch/gitops/overview.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Elasticsearch Gitops Overview -description: Elasticsearch Gitops Overview -menu: - docs_{{ .version }}: - identifier: es-gitops-overview - name: Overview - parent: es-gitops - weight: 10 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -> New to KubeDB? Please start [here](/docs/README.md). - -# GitOps Overview for Elasticsearch - -This guide will give you an overview of how KubeDB `gitops` operator works with Elasticsearch databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for -managing Elasticsearch databases in Kubernetes. - -## Before You Begin - -- You should be familiar with the following `KubeDB` concepts: - - [Elasticsearch](/docs/guides/elasticsearch/concepts/elasticsearch/index.md) - - [ElasticsearchOpsRequest](/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md) - - - -## Workflow GitOps with Elasticsearch - -The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. - - -
- - GitOps Flow - -
Fig: GitOps process of Elasticsearch
- -
- -1. **Define GitOps Elasticsearch**: Create Custom Resource (CR) of kind `Elasticsearch` using the `gitops.kubedb.com/v1alpha1` API. -2. **Store in Git**: Push the CR to a Git repository. -3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. -4. **Create Database**: The GitOps operator creates a corresponding KubeDB Elasticsearch CR in the Kubernetes cluster to deploy the database. -5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. - -This flow makes managing Elasticsearch databases efficient, reliable, and fully integrated with GitOps practices. - -In the next doc, we are going to show a step by step guide on running Elasticsearch using GitOps. diff --git a/docs/guides/kafka/gitops/_index.md b/docs/guides/kafka/gitops/_index.md index 098093afa8..234162a433 100644 --- a/docs/guides/kafka/gitops/_index.md +++ b/docs/guides/kafka/gitops/_index.md @@ -5,6 +5,6 @@ menu: identifier: kf-gitops name: Gitops parent: kf-kafka-guides - weight: 30 + weight: 130 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/redis/gitops/_index.md b/docs/guides/redis/gitops/_index.md deleted file mode 100644 index 1189753691..0000000000 --- a/docs/guides/redis/gitops/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Redis Gitops -menu: - docs_{{ .version }}: - identifier: rd-gitops - name: Gitops - parent: rd-redis-guides - weight: 170 -menu_name: docs_{{ .version }} ---- diff --git a/docs/guides/redis/gitops/gitops.md b/docs/guides/redis/gitops/gitops.md deleted file mode 100644 index fbe9eda4e2..0000000000 --- a/docs/guides/redis/gitops/gitops.md +++ /dev/null @@ -1,821 +0,0 @@ ---- -title: Redis GitOps Guides -menu: - docs_{{ .version }}: - identifier: rd-gitops-guides - name: Gitops Redis - parent: rd-gitops - weight: 20 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - - -> New to KubeDB? Please start [here](/docs/README.md). - -# GitOps Redis using KubeDB GitOps Operator - -This guide will show you how to use `KubeDB` GitOps operator to create Redis database and manage updates using GitOps worrdlow. - -## Before You Begin - -- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). - -- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. - -- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. - - ```bash - $ kubectl create ns monitoring - namespace/monitoring created - - $ kubectl create ns demo - namespace/demo created - ``` -> Note: YAML files used in this tutorial are stored in [docs/examples/Redis](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/Redis) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). - -We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). - -## Creating Apps via CLI - -### For Public Repository -```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace -``` - -### For Private Repository -#### Using HTTPS -```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password -``` - -#### Using SSH -```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa -``` - -## Create Redis Database using GitOps - -### Create a Redis GitOps CR -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Redis -metadata: - name: rd-gitops - namespace: demo -spec: - version: 8.0.4 - mode: Cluster - cluster: - shards: 3 - replicas: 2 - storageType: Durable - storage: - resources: - requests: - storage: "1Gi" - storageClassName: "longhorn" - accessModes: - - ReadWriteOnce - podTemplate: - spec: - containers: - - name: redis - resources: - requests: - memory: "300Mi" - cpu: "200m" - limits: - memory: "300Mi" - cpu: "200m" - deletionPolicy: WipeOut -``` - -Create a directory like below, -```bash -$ tree . -├── kubedb - └── Redis.yaml -1 directories, 1 files -``` - -Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is created in your cluster. - -Our `gitops` operator will create an actual `Redis` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. - - -```bash -$ kubectl get redis.gitops.kubedb.com,redis.kubedb.com -n demo -NAME AGE -redis.gitops.kubedb.com/rd-gitops 2m19s - -NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 2m18s -``` - -List the resources created by `kubedb` operator created for `kubedb.com/v1` Redis. - -```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=rd-gitops' -NAME AGE -petset.apps.k8s.appscode.com/rd-gitops-shard0 5m53s -petset.apps.k8s.appscode.com/rd-gitops-shard1 5m51s -petset.apps.k8s.appscode.com/rd-gitops-shard2 5m49s - -NAME READY STATUS RESTARTS AGE -pod/rd-gitops-shard0-0 1/1 Running 0 5m52s -pod/rd-gitops-shard0-1 1/1 Running 0 5m35s -pod/rd-gitops-shard1-0 1/1 Running 0 5m50s -pod/rd-gitops-shard1-1 1/1 Running 0 5m31s -pod/rd-gitops-shard2-0 1/1 Running 0 5m49s -pod/rd-gitops-shard2-1 1/1 Running 0 5m31s - -NAME TYPE DATA AGE -secret/rd-gitops-auth kubernetes.io/basic-auth 2 5m55s -secret/rd-gitops-b3b686 Opaque 1 5m55s - -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/rd-gitops ClusterIP 10.43.156.126 6379/TCP 5m55s -service/rd-gitops-pods ClusterIP None 6379/TCP,16379/TCP 5m55s - -NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/rd-gitops kubedb.com/redis 8.0.4 5m49s -``` - -## Update Redis Database using GitOps - -### Scale Redis Replicas - - -Update the `Redis.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Redis -metadata: - name: rd-gitops - namespace: demo -spec: - version: 8.0.4 - mode: Cluster - cluster: - shards: 3 - replicas: 3 - storageType: Durable - storage: - resources: - requests: - storage: "1Gi" - storageClassName: "longhorn" - accessModes: - - ReadWriteOnce - podTemplate: - spec: - containers: - - name: redis - resources: - requests: - memory: "300Mi" - cpu: "200m" - limits: - memory: "300Mi" - cpu: "200m" - deletionPolicy: WipeOut - ``` -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` RedisOpsRequest to update the `Redis` database replicas. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get rd,redis,redisopsrequest -n demo -NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 55m - -NAME AGE -redis.gitops.kubedb.com/rd-gitops 55m - -NAME TYPE STATUS AGE -redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-ule15j HorizontalScaling Successful 16m -``` - -After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, -```bash -$ kkubectl get pod -n demo -l 'app.kubernetes.io/instance=rd-gitops' -NAME READY STATUS RESTARTS AGE -rd-gitops-shard0-0 1/1 Running 0 55m -rd-gitops-shard0-1 1/1 Running 0 55m -rd-gitops-shard0-2 1/1 Running 0 16m -rd-gitops-shard1-0 1/1 Running 0 55m -rd-gitops-shard1-1 1/1 Running 0 55m -rd-gitops-shard1-2 1/1 Running 0 16m -rd-gitops-shard2-0 1/1 Running 0 55m -rd-gitops-shard2-1 1/1 Running 0 55m -rd-gitops-shard2-2 1/1 Running 0 15m -``` - -We can also scale down the replicas by updating the `replicas` fields. - -### Scale Redis Database Resources - -before Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, -```bash -$ kubectl get pod -n demo rd-gitops-shard0-0 -o json | jq '.spec.containers[0].resources' -{ - "limits": { - "cpu": "200m", - "memory": "300Mi" - }, - "requests": { - "cpu": "200m", - "memory": "300Mi" - } -} -``` - - -Update the `Redis.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Redis -metadata: - name: rd-gitops - namespace: demo -spec: - version: 8.0.4 - mode: Cluster - cluster: - shards: 3 - replicas: 3 - storageType: Durable - storage: - resources: - requests: - storage: "1Gi" - storageClassName: "longhorn" - accessModes: - - ReadWriteOnce - podTemplate: - spec: - containers: - - name: redis - resources: - requests: - memory: "500Mi" - cpu: "500m" - limits: - memory: "500Mi" - cpu: "500m" - deletionPolicy: WipeOut - -``` - - -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. - -Now, `gitops` operator will detect the resource changes and create a `RedisOpsRequest` to update the `Redis` database. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get rd,redis,redisopsrequest -n demo -NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 17h - -NAME AGE -redis.gitops.kubedb.com/rd-gitops 17h - -NAME TYPE STATUS AGE -redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-ule15j HorizontalScaling Successful 16h -redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-lliwo8 VerticalScaling Successful 16h -``` - -kubectl get pod -n demo rd-gitops-shard0-0 -o json | jq '.spec.containers[0].resources' -{ - "limits": { - "cpu": "500m", - "memory": "500Mi" - }, - "requests": { - "cpu": "500m", - "memory": "500Mi" - } -} - - -### Expand Redis Volume - -Update the `Redis.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Redis -metadata: - name: rd-gitops - namespace: demo -spec: - version: 8.0.4 - mode: Cluster - cluster: - shards: 3 - replicas: 3 - storageType: Durable - storage: - resources: - requests: - storage: "2Gi" - storageClassName: "longhorn" - accessModes: - - ReadWriteOnce - podTemplate: - spec: - containers: - - name: redis - resources: - requests: - memory: "500Mi" - cpu: "500m" - limits: - memory: "500Mi" - cpu: "500m" - deletionPolicy: WipeOut -``` - -Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. - -Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` RedisOpsRequest to update the `Redis` database volume. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get rd,redis,redisopsrequest -n demo -NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 17h - -NAME AGE -redis.gitops.kubedb.com/rd-gitops 17h - -NAME TYPE STATUS AGE -redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-ule15j HorizontalScaling Successful 16h -redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-lliwo8 VerticalScaling Successful 16h -redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-3twy3x VolumeExpansion Successful 2m23s -``` - -After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, -```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=rd-gitops' -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-rd-gitops-shard0-0 Bound pvc-77634b30-7ccc-4391-a768-54d4e3c1907c 2Gi RWO longhorn 17h -data-rd-gitops-shard0-1 Bound pvc-e4b23a61-5de7-4e5c-b4b2-0722bffc7464 2Gi RWO longhorn 17h -data-rd-gitops-shard0-2 Bound pvc-c3ffc095-248b-4091-bfaa-a1de401e3e36 2Gi RWO longhorn 16h -data-rd-gitops-shard1-0 Bound pvc-62e7a6c0-ddd5-4281-8878-9ec42e68585d 2Gi RWO longhorn 17h -data-rd-gitops-shard1-1 Bound pvc-0e9ca41e-8b25-4ea1-865a-17aba48f619c 2Gi RWO longhorn 17h -data-rd-gitops-shard1-2 Bound pvc-c1e6806d-bb6c-4521-94c6-8e47ec6ad36e 2Gi RWO longhorn 16h -data-rd-gitops-shard2-0 Bound pvc-0954e736-e699-46f4-9dfb-33b23f65e351 2Gi RWO longhorn 17h -data-rd-gitops-shard2-1 Bound pvc-1fd1321a-ff04-4c81-b903-80473598ffac 2Gi RWO longhorn 17h -data-rd-gitops-shard2-2 Bound pvc-8458eb68-930b-4817-8577-24616079e9f7 2Gi RWO longhorn 16h -``` - -## Reconfigure Redis - -At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/Redis/configuration/Redis-combined.md) -```yaml -apiVersion: v1 -stringData: - redis.conf: | - maxclients 500 -kind: Secret -metadata: - name: rd-new-configuration - namespace: demo -type: Opaque -``` - -Now, we will add this file to `kubedb /rd-configuration.yaml`. - -```bash -$ tree . -├── kubedb -│ ├── rd-configuration.yaml -│ └── Redis.yaml -1 directories, 2 files -``` - -Update the `Redis.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Redis -metadata: - name: rd-gitops - namespace: demo -spec: - version: 8.0.4 - mode: Cluster - cluster: - shards: 3 - replicas: 3 - storageType: Durable - configuration: - secretName: rd-new-configuration - storage: - resources: - requests: - storage: "2Gi" - storageClassName: "longhorn" - accessModes: - - ReadWriteOnce - podTemplate: - spec: - containers: - - name: redis - resources: - requests: - memory: "500Mi" - cpu: "500m" - limits: - memory: "500Mi" - cpu: "500m" - deletionPolicy: WipeOut -``` - -Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. - -Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` RedisOpsRequest to update the `Redis` database configuration. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get rd,redis,redisopsrequest -n demo -NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 22m - -NAME AGE -redis.gitops.kubedb.com/rd-gitops 22m - -NAME TYPE STATUS AGE -redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-5v9956 Reconfigure Successful 15m -``` - - - -### Rotate Redis Auth - -To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. - -We will create a secret named `rd-rotate-auth ` with the following content, - -```bash -$ kubectl create secret generic rd-rotate-auth -n demo \ - --type=kubernetes.io/basic-auth \ - --from-literal=username=redis \ - --from-literal=password=redis-secret -secret/rd-rotate-auth created -``` - - - -Update the `Redis.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Redis -metadata: - name: rd-gitops - namespace: demo -spec: - version: 8.0.4 - mode: Cluster - cluster: - shards: 3 - replicas: 3 - storageType: Durable - authSecret: - kind: Secret - name: rd-rotate-auth - configuration: - secretName: rd-new-configuration - storage: - resources: - requests: - storage: "2Gi" - storageClassName: "longhorn" - accessModes: - - ReadWriteOnce - podTemplate: - spec: - containers: - - name: redis - resources: - requests: - memory: "500Mi" - cpu: "500m" - limits: - memory: "500Mi" - cpu: "500m" - deletionPolicy: WipeOut -``` - -Change the `authSecret` field to `rd-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. - -Now, `gitops` operator will detect the auth changes and create a `RotateAuth` RedisOpsRequest to update the `Redis` database auth. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get rd,redis,redisopsrequest -n demo -NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 33m - -NAME AGE -redis.gitops.kubedb.com/rd-gitops 33m - -NAME TYPE STATUS AGE -redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-5v9956 Reconfigure Successful 26m -redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-oz83g9 RotateAuth Successful 7m39s -``` - - -### TLS configuration - -We can add, rotate or remove TLS configuration using `gitops`. - -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Redis. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. - -- Start off by generating a ca certificates using openssl. - -```bash -$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" -Generating a RSA private key -................+++++ -........................+++++ -writing new private key to './ca.key' ------ -``` - -- Now we are going to create a ca-secret using the certificate files that we have just generated. - -```bash -$ kubectl create secret tls redis-ca \ - --cert=ca.crt \ - --key=ca.key \ - --namespace=demo -secret/redis-ca created -``` - -Now, Let's create an `Issuer` using the `Redis-ca` secret that we have just created. The `YAML` file looks like this: - -```yaml -apiVersion: cert-manager.io/v1 -kind: Issuer -metadata: - name: rd-issuer - namespace: demo -spec: - ca: - secretName: redis-ca -``` - -Let's add that to our `kubedb /rd-issuer.yaml` file. File structure will look like this, -```bash -$ tree . -├── kubedb -│ ├── rd-configuration.yaml -│ ├── rd-issuer.yaml -│ └── Redis.yaml -1 directories, 4 files -``` - -Update the `Redis.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Redis -metadata: - name: rd-gitops - namespace: demo -spec: - version: 3.9.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - storageType: Durable - deletionPolicy: WipeOut -``` - -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. - -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` RedisOpsRequest to update the `Redis` database tls. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get rd,Redis,rdops,pods -n demo -NAME TYPE VERSION STATUS AGE -Redis.kubedb.com/rd-gitops kubedb.com/v1 3.9.0 Ready 41m - -NAME AGE -Redis.gitops.kubedb.com/rd-gitops 75m - -NAME TYPE STATUS AGE -Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h -Redisopsrequest.ops.kubedb.com/rd-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -Redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h -Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h - -``` - - -> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Redis. - -### Update Version - -List Redis versions using `kubectl get Redisversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Redis/update-version/update-version.md). - -Let's choose `4.0.0` in this example. - -Update the `Redis.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Redis -metadata: - name: rd-gitops - namespace: demo -spec: - version: 8.0.4 - mode: Cluster - cluster: - shards: 3 - replicas: 3 - storageType: Durable - authSecret: - kind: Secret - name: rd-rotate-auth - configuration: - secretName: rd-new-configuration - storage: - resources: - requests: - storage: "2Gi" - storageClassName: "longhorn" - accessModes: - - ReadWriteOnce - podTemplate: - spec: - containers: - - name: redis - resources: - requests: - memory: "500Mi" - cpu: "500m" - limits: - memory: "500Mi" - cpu: "500m" - deletionPolicy: WipeOut -``` - -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. - -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` RedisOpsRequest to update the `Redis` database version. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get rd,redis,redisopsrequest -n demo -NAME VERSION STATUS AGE -redis.kubedb.com/rd-gitops 8.0.4 Ready 14m - -NAME AGE -redis.gitops.kubedb.com/rd-gitops 14m - -NAME TYPE STATUS AGE -redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-xvnekk UpdateVersion Successful 11m -``` - - -### Enable Monitoring - -If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). - -Update the `Redis.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: Redis -metadata: - name: rd-gitops - namespace: demo -spec: - version: 4.0.0 - topology: - broker: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - controller: - podTemplate: - spec: - containers: - - name: Redis - resources: - limits: - memory: 1536Mi - requests: - cpu: 500m - memory: 1536Mi - replicas: 2 - storage: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: Standard - storageType: Durable - monitor: - agent: prometheus.io/operator - prometheus: - exporter: - port: 9091 - serviceMonitor: - labels: - release: prometheus - interval: 10s - deletionPolicy: WipeOut -``` - -Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. - -Now, `gitops` operator will detect the monitoring changes and create a `Restart` RedisOpsRequest to add the `Redis` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. -```bash -$ kubectl get Redises.gitops.kubedb.com,Redises.kubedb.com,Redisopsrequest -n demo -NAME TYPE VERSION STATUS AGE -Redis.kubedb.com/rd-gitops kubedb.com/v1 4.0.0 Ready 5h12m - -NAME AGE -Redis.gitops.kubedb.com/rd-gitops 5h12m - -NAME TYPE STATUS AGE -Redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-ukj41o Reconfigure Successful 6d -Redisopsrequest.ops.kubedb.com/rd-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -Redisopsrequest.ops.kubedb.com/rd-gitops-restart-ljpqih Restart Successful 3m51s -Redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-43ris8 RotateAuth Successful 5d7h -Redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-wyn2dp UpdateVersion Successful 5h16m -Redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-41xthr VolumeExpansion Successful 6d - -``` - -Verify the monitoring is enabled by checking the prometheus targets. - -There are some other fields that will trigger `Restart` ops request. -- `.spec.monitor` -- `.spec.spec.archiver` -- `.spec.remoteReplica` -- `spec.replication` -- `.spec.standbyMode` -- `.spec.streamingMode` -- `.spec.enforceGroup` -- `.spec.sslMode` etc. - - -## Next Steps - -[//]: # (- Learn Redis [GitOps](/docs/guides/Redis/concepts/Redis-gitops.md)) -- Learn Redis Scaling - - [Horizontal Scaling](/docs/guides/Redis/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/Redis/scaling/vertical-scaling/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/Redis/update-version/overview.md) -- Monitor your RedisQL database with KubeDB using [built-in Prometheus](/docs/guides/Redis/monitoring/using-builtin-prometheus.md). -- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/redis/gitops/overview.md b/docs/guides/redis/gitops/overview.md deleted file mode 100644 index 7b5ed3a7c8..0000000000 --- a/docs/guides/redis/gitops/overview.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Redis Gitops Overview -description: Redis Gitops Overview -menu: - docs_{{ .version }}: - identifier: rd-gitops-overview - name: Overview - parent: rd-gitops - weight: 10 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -> New to KubeDB? Please start [here](/docs/README.md). - -# GitOps Overview for Redis - -This guide will give you an overview of how KubeDB `gitops` operator works with Redis databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for -managing Redis databases in Kubernetes. - -## Before You Begin - -- You should be familiar with the following `KubeDB` concepts: - - [Redis](/docs/guides/redis/concepts/redis.md) - - [KafkaOpsRequest](/docs/guides/redis/concepts/redisopsrequest.md) - - - -## Workflow GitOps with Redis - -The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. - - -
- - GitOps Flow - -
Fig: GitOps process of Redis
- -
- -1. **Define GitOps Redis**: Create Custom Resource (CR) of kind `Redis` using the `gitops.kubedb.com/v1alpha1` API. -2. **Store in Git**: Push the CR to a Git repository. -3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. -4. **Create Database**: The GitOps operator creates a corresponding KubeDB Redis CR in the Kubernetes cluster to deploy the database. -5. **Handle Updates**: When you update the KafkaGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. - -This flow makes managing Redis databases efficient, reliable, and fully integrated with GitOps practices. - -In the next doc, we are going to show a step by step guide on running Redis using GitOps. From fd1b37ac928caefceb0fa83c1629e4a4e5076e5e Mon Sep 17 00:00:00 2001 From: Bonusree Date: Mon, 20 Apr 2026 12:22:51 +0600 Subject: [PATCH 23/51] link fix Signed-off-by: Bonusree --- .../using-config-file.md.bak | 177 ---- docs/guides/mariadb/gitops/gitops.md | 13 +- .../using-config-file.md.bak | 182 ----- docs/guides/mongodb/gitops/_index.md | 10 - docs/guides/mongodb/gitops/gitops.md | 753 ------------------ docs/guides/mongodb/gitops/overview.md | 50 -- docs/guides/mssqlserver/gitops/gitops.md | 52 +- docs/guides/mssqlserver/gitops/overview.md | 22 +- docs/guides/mysql/gitops/gitops.md | 14 +- 9 files changed, 48 insertions(+), 1225 deletions(-) delete mode 100644 docs/guides/ignite/custom-configuration/using-config-file.md.bak delete mode 100644 docs/guides/memcached/custom-configuration/using-config-file.md.bak delete mode 100644 docs/guides/mongodb/gitops/_index.md delete mode 100644 docs/guides/mongodb/gitops/gitops.md delete mode 100644 docs/guides/mongodb/gitops/overview.md diff --git a/docs/guides/ignite/custom-configuration/using-config-file.md.bak b/docs/guides/ignite/custom-configuration/using-config-file.md.bak deleted file mode 100644 index 68140892b8..0000000000 --- a/docs/guides/ignite/custom-configuration/using-config-file.md.bak +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: Run Ignite with Custom Configuration -menu: - docs_{{ .version }}: - identifier: ig-using-config-file-configuration - name: Customize Configurations - parent: ig-custom-configuration - weight: 10 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -> New to KubeDB? Please start [here](/docs/README.md). - -# Using Custom Configuration File - -KubeDB supports providing custom configuration for Ignite. This tutorial will show you how to use KubeDB to run Ignite with custom configuration. - -## Before You Begin - -- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). - -- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). - -- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. - - ```bash - $ kubectl create ns demo - namespace/demo created - - $ kubectl get ns demo - NAME STATUS AGE - demo Active 5s - ``` - -> Note: YAML files used in this tutorial are stored in [docs/examples/ignite](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/ignite) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). - -## Overview - -Ignite does not allow to configuration via any file. However, configuration parameters can be set as arguments while starting the ignite docker image. To keep similarity with other KubeDB supported databases which support configuration through a config file, KubeDB has added an additional executable script on top of the official ignite docker image. This script parses the configuration file then set them as arguments of ignite binary. - -To know more about configuring Ignite server see [here](https://ignite.apache.org/docs/ignite3/latest/administrators-guide/config/node-config). - -At first, you have to create a custom configuration file and provide its name in `spec.configuration.secretName`. The operator reads this Secret internally and applies the configuration automatically. - - -In this tutorial, we will enable Ignite's authentication via secret. - -Create a secret with custom configuration file: -```yaml -apiVersion: v1 -stringData: - node-configuration.xml: | - - - - - - - - -kind: Secret -metadata: - name: ignite-configuration - namespace: demo - resourceVersion: "4505" -``` -Here, `authenticationEnabled's` default value is `false`. In this secret, we make the value `true`. - -```bash - $ kubectl apply -f ignite-configuration.yaml -secret/ignite-configuration created -``` - -Let's get the ignite-configuration `secret` with custom configuration: - -```yaml -$ kubectl get secret -n demo ignite-configuration -o yaml -apiVersion: v1 -data: - node-configuration.xml: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGJlYW5zIHhtbG5zPSJodHRwOi8vd3d3LnNwcmluZ2ZyYW1ld29yay5vcmcvc2NoZW1hL2JlYW5zIgogICB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIgogICB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cuc3ByaW5nZnJhbWV3b3JrLm9yZy9zY2hlbWEvYmVhbnMKICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LnNwcmluZ2ZyYW1ld29yay5vcmcvc2NoZW1hL2JlYW5zL3NwcmluZy1iZWFucy0zLjAueHNkIj4KPCEtLSBZb3VyIElnbml0ZSBDb25maWd1cmF0aW9uIC0tPgo8YmVhbiBjbGFzcz0ib3JnLmFwYWNoZS5pZ25pdGUuY29uZmlndXJhdGlvbi5JZ25pdGVDb25maWd1cmF0aW9uIj4KCiAgICA8cHJvcGVydHkgbmFtZT0iYXV0aGVudGljYXRpb25FbmFibGVkIiB2YWx1ZT0idHJ1ZSIvPgoKPC9iZWFuPgo8L2JlYW5zPgo= -kind: Secret -metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{},"name":"ignite-configuration","namespace":"demo","resourceVersion":"4505"},"stringData":{"node-configuration.xml":"\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\n\u003cbeans xmlns=\"http://www.springframework.org/schema/beans\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n xsi:schemaLocation=\"http://www.springframework.org/schema/beans\n http://www.springframework.org/schema/beans/spring-beans-3.0.xsd\"\u003e\n\u003c!-- Your Ignite Configuration --\u003e\n\u003cbean class=\"org.apache.ignite.configuration.IgniteConfiguration\"\u003e\n\n \u003cproperty name=\"authenticationEnabled\" value=\"true\"/\u003e\n\n\u003c/bean\u003e\n\u003c/beans\u003e\n"}} - creationTimestamp: "2025-06-02T09:37:05Z" - name: ignite-configuration - namespace: demo - resourceVersion: "1391127" - uid: 57f2a44c-d6b1-4571-bb91-fd68b3048306 -type: Opaque -``` - -Now, create Ignite crd specifying `spec.configuration.secretName` field. - -```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/ignite/configuration/custom-ignite.yaml -ignite.kubedb.com/custom-ignite created -``` - -Below is the YAML for the Ignite crd we just created. - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: Ignite -metadata: - name: custom-ignite - namespace: demo -spec: - replicas: 3 - version: 2.17.0 - configuration: - secretName: ignite-configuration - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - deletionPolicy: WipeOut -``` - -Now, wait a few minutes. KubeDB operator will create necessary petset, services etc. If everything goes well, we will see that a pod with the name `custom-ignite-0` has been created. - -Check if the database is ready - -```bash -$ kubectl get ig -n demo -NAME VERSION STATUS AGE -custom-ignite 2.17.0 Ready 17m -``` - -Now, we will check if the database has started with the custom configuration we have provided. -We will connect to `custom-ignite-0` pod: - -```bash -$ kubectl exec -it -n demo ignite-quickstart-0 -c ignite -- bash -[ignite@ignite-quickstart-0 config]$ cat /ignite/config/node-configuration.xml - - - - -... -... - - - -``` - -Here, we can see `authenticationEnabled's` value is `true`. - -## Cleaning up - -To cleanup the Kubernetes resources created by this tutorial, run: - -```bash -kubectl patch -n demo ig/custom-ignite -p '{"spec":{"deletionPolicy":"WipeOut"}}' --type="merge" -kubectl delete -n demo ig/custom-ignite - -kubectl delete -n demo secret ignite-configuration -kubectl delete ns demo -``` - -If you would like to uninstall KubeDB operator, please follow the steps [here](/docs/setup/README.md). - -## Next Steps - -- Learn how to use KubeDB to run a Ignite server [here](/docs/guides/ignite/README.md). -- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index 0bbd27da94..dd8ed06cb2 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -324,7 +324,7 @@ data-mariadb-gitops-4 Bound pvc-dee1c10d-0456-4935-9306-0d86c3db54d0 2Gi ## Reconfigure MariaDB At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/MariaDB/configuration/MariaDB-combined.md) +To know more about this configuration file, check [here](/docs/guides/mariadb/reconfigure/overview/index.md) ```yaml apiVersion: v1 stringData: @@ -602,7 +602,7 @@ mariadbopsrequest.ops.kubedb.com/mariadb-gitops-volumeexpansion-01m39b Volum ### Update Version -List MariaDB versions using `kubectl get MariaDBversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/MariaDB/update-version/update-version.md). +List MariaDB versions using `kubectl get MariaDBversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/mariadb/update-version/overview/index.md). Let's choose `12.1.2` in this example. @@ -786,10 +786,9 @@ There are some other fields that will trigger `Restart` ops request. ## Next Steps -[//]: # (- Learn MariaDB [GitOps](/docs/guides/MariaDB/concepts/MariaDB-gitops.md)) - Learn MariaDB Scaling - - [Horizontal Scaling](/docs/guides/MariaDB/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/MariaDB/scaling/vertical-scaling/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/MariaDB/update-version/overview.md) -- Monitor your MariaDBQL database with KubeDB using [built-in Prometheus](/docs/guides/MariaDB/monitoring/using-builtin-prometheus.md). + - [Horizontal Scaling](/docs/guides/mariadb/scaling/horizontal-scaling/overview/index.md) + - [Vertical Scaling](/docs/guides/mariadb/scaling/vertical-scaling/overview/index.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/mariadb/update-version/overview/index.md) +- Monitor your MariaDBQL database with KubeDB using [built-in Prometheus](/docs/guides/mariadb/monitoring/prometheus-operator/index.md). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/memcached/custom-configuration/using-config-file.md.bak b/docs/guides/memcached/custom-configuration/using-config-file.md.bak deleted file mode 100644 index 5f1387bd23..0000000000 --- a/docs/guides/memcached/custom-configuration/using-config-file.md.bak +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: Run Memcached with Custom Configuration -menu: - docs_{{ .version }}: - identifier: mc-using-config-file-configuration - name: Customize Configurations - parent: custom-configuration - weight: 10 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -> New to KubeDB? Please start [here](/docs/README.md). - -# Using Custom Configuration File - -KubeDB supports providing custom configuration for Memcached. This tutorial will show you how to use KubeDB to run Memcached with custom configuration. - -## Before You Begin - -- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). - -- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). - -- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. - - ```bash - $ kubectl create ns demo - namespace/demo created - - $ kubectl get ns demo - NAME STATUS AGE - demo Active 5s - ``` - -> Note: YAML files used in this tutorial are stored in [docs/examples/memcached](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/memcached) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). - -## Overview - -Memcached does not allows to configuration via any file. However, configuration parameters can be set as arguments while starting the memcached docker image. To keep similarity with other KubeDB supported databases which support configuration through a config file, KubeDB has added an additional executable script on top of the official memcached docker image. This script parses the configuration file then set them as arguments of memcached binary. - -To know more about configuring Memcached server see [here](https://github.com/memcached/memcached/wiki/ConfiguringServer). - -At first, you have to create a custom configuration file and provide its name in `spec.configuration.secretName`. The operator reads this Secret internally and applies the configuration automatically. - -In this tutorial, we will configure [max_connections](https://github.com/memcached/memcached/blob/ee171109b3afe1f30ff053166d205768ce635342/doc/protocol.txt#L672) and [limit_maxbytes](https://github.com/memcached/memcached/blob/ee171109b3afe1f30ff053166d205768ce635342/doc/protocol.txt#L720) via secret. - -Create a secret with custom configuration file: -```yaml -apiVersion: v1 -stringData: - memcached.conf: | - --conn-limit=500 - --memory-limit=128 -kind: Secret -metadata: - name: mc-configuration - namespace: demo - resourceVersion: "4505" -``` -Here, --con-limit means max simultaneous connections which is default value is 1024. -and --memory-limit means item memory in megabytes which default value is 64. - -```bash - $ kubectl apply -f mc-configuration.yaml -secret/mc-configuration created -``` - -Let's get the mc-configuration `secret` with custom configuration: - -```yaml -$ kubectl get secret -n demo mc-configuration -o yaml -apiVersion: v1 -data: - memcached.conf: LS1jb25uLWxpbWl0PTUwMAotLW1lbW9yeS1saW1pdD01MTIK -kind: Secret -metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{},"name":"mc-configuration","namespace":"demo","resourceVersion":"4505"},"stringData":{"memcached.conf":"--conn-limit=500\n--memory-limit=512\n"}} - creationTimestamp: "2024-08-26T12:19:54Z" - name: mc-configuration - namespace: demo - resourceVersion: "4580860" - uid: 02d41fc0-590e-44d1-ae95-2ee8f9632d36 -type: Opaque -``` - -Now, create Memcached crd specifying `spec.configuration.secretName` field. - -```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/memcached/configuration/mc-custom.yaml -memcached.kubedb.com/custom-memcached created -``` - -Below is the YAML for the Memcached crd we just created. - -```yaml -apiVersion: kubedb.com/v1 -kind: Memcached -metadata: - name: custom-memcached - namespace: demo -spec: - replicas: 1 - version: "1.6.22" - configuration: - secretName: mc-configuration - podTemplate: - spec: - containers: - - name: memcached - resources: - limits: - cpu: 500m - memory: 128Mi - requests: - cpu: 250m - memory: 64Mi - deletionPolicy: WipeOut -``` - -Now, wait a few minutes. KubeDB operator will create necessary petset, services etc. If everything goes well, we will see that a pod with the name `custom-memcached-0` has been created. - -Check if the database is ready - -```bash -$ kubectl get mc -n demo -NAME VERSION STATUS AGE -custom-memcached 1.6.22 Ready 17m -``` - -Now, we will check if the database has started with the custom configuration we have provided. We will use [stats](https://github.com/memcached/memcached/wiki/ConfiguringServer#inspecting-running-configuration) command to check the configuration. - -We will connect to `custom-memcached-0` pod from local-machine using port-frowarding. - -```bash -$ kubectl port-forward -n demo custom-memcached-0 11211 -Forwarding from 127.0.0.1:11211 -> 11211 -Forwarding from [::1]:11211 -> 11211 -``` - -Now, connect to the memcached server from a different terminal through `telnet`. - -```bash -$ telnet 127.0.0.1 11211 -Trying 127.0.0.1... -Connected to 127.0.0.1. -Escape character is '^]'. -stats -... -STAT max_connections 500 -... -STAT limit_maxbytes 134217728 -... -END -``` - -Here, `limit_maxbytes` is represented in bytes. - -## Cleaning up - -To cleanup the Kubernetes resources created by this tutorial, run: - -```bash -kubectl patch -n demo mc/custom-memcached -p '{"spec":{"deletionPolicy":"WipeOut"}}' --type="merge" -kubectl delete -n demo mc/custom-memcached - -kubectl patch -n demo drmn/custom-memcached -p '{"spec":{"wipeOut":true}}' --type="merge" -kubectl delete -n demo drmn/custom-memcached - -kubectl delete -n demo secret mc-configuration - -kubectl delete ns demo -``` - -If you would like to uninstall KubeDB operator, please follow the steps [here](/docs/setup/README.md). - -## Next Steps - -- Learn how to use KubeDB to run a Memcached server [here](/docs/guides/memcached/README.md). -- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mongodb/gitops/_index.md b/docs/guides/mongodb/gitops/_index.md deleted file mode 100644 index 653e9e9e45..0000000000 --- a/docs/guides/mongodb/gitops/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: MongoDB Gitops -menu: - docs_{{ .version }}: - identifier: mg-gitops-mongodb - name: Gitops - parent: mg-mongodb-guides - weight: 147 -menu_name: docs_{{ .version }} ---- diff --git a/docs/guides/mongodb/gitops/gitops.md b/docs/guides/mongodb/gitops/gitops.md deleted file mode 100644 index c4af6cc445..0000000000 --- a/docs/guides/mongodb/gitops/gitops.md +++ /dev/null @@ -1,753 +0,0 @@ ---- -title: MongoDB Gitops -description: MongoDB Gitops -menu: - docs_{{ .version }}: - identifier: mg-gitops - name: MongoDB Gitops - parent: mg-gitops-mongodb - weight: 10 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - - - -> New to KubeDB? Please start [here](/docs/README.md). - -# GitOps MongoDB using KubeDB GitOps Operator - -This guide will show you how to use `KubeDB` GitOps operator to create MongoDB database and manage updates using GitOps workflow. - -## Before You Begin - -- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). - -- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. - -- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. - - ```bash - $ kubectl create ns monitoring - namespace/monitoring created - - - $ kubectl create ns demo - namespace/demo created - ``` -> Note: YAML files used in this tutorial are stored in [docs/examples/MongoDB](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/MongoDB) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). - -We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). - -## Creating Apps via CLI - -### For Public Repository -```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace -``` - -### For Private Repository -#### Using HTTPS -```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password -``` - -#### Using SSH -```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa -``` - -## Create MongoDB Database using GitOps - -### Create a MongoDB GitOps CR -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: MongoDB -metadata: - name: mg-gitops - namespace: demo -spec: - version: "8.0.10" - replicaSet: - name: "replicaset" - replicas: 2 - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi -``` - -Create a directory like below, -```bash -$ tree . -├── kubedb - └── MongoDB.yaml -1 directories, 1 files -``` - -Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is created in your cluster. - -Our `gitops` operator will create an actual `MongoDB` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. - - -```bash -$ kubectl get MongoDB.gitops.kubedb.com,MongoDB.kubedb.com -n demo -NAME AGE -mongodb.gitops.kubedb.com/mg-gitops 33m - -NAME VERSION STATUS AGE -mongodb.kubedb.com/mg-gitops 8.0.10 Ready 33m - -``` - -List the resources created by `kubedb` operator created for `kubedb.com/v1` MongoDB. - -```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=mg-gitops' -NAME AGE -petset.apps.k8s.appscode.com/mg-gitops 34m - -NAME READY STATUS RESTARTS AGE -pod/mg-gitops-0 2/2 Running 0 34m -pod/mg-gitops-1 2/2 Running 0 33m - -NAME TYPE DATA AGE -secret/mg-gitops-auth kubernetes.io/basic-auth 2 34m -secret/mg-gitops-key Opaque 1 34m - -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/mg-gitops ClusterIP 10.43.206.183 27017/TCP 34m -service/mg-gitops-pods ClusterIP None 27017/TCP 34m - -NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/mg-gitops kubedb.com/mongodb 8.0.10 34m - -``` - -## Update MongoDB Database using GitOps - -### Scale MongoDB Database Resources - -Before scaling database resouces: - -```shell -kubectl get pod -n demo mg-gitops-0 -o json | jq '.spec.containers[0].resources' -{ - "limits": { - "memory": "1536Mi" - }, - "requests": { - "cpu": "800m", - "memory": "1536Mi" - } -} -``` -Update the `MongoDB.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: MongoDB -metadata: - name: mg-gitops - namespace: demo -spec: - version: "8.0.10" - replicaSet: - name: "replicaset" - replicas: 2 - podTemplate: - spec: - containers: - - name: mongodb - resources: - limits: - memory: 2Gi - requests: - cpu: 1000m - memory: 2Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - ``` - -Resource Requests and Limits are updated from `800m` to `1000m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. - -Now, `gitops` operator will detect the resource changes and create a `MongoDBOpsRequest` to update the `MongoDB` database. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$kubectl get mg,MongoDB,mgops -n demo -NAME VERSION STATUS AGE -mongodb.kubedb.com/mg-gitops 8.0.10 Ready 13m - -NAME AGE -mongodb.gitops.kubedb.com/mg-gitops 13m - -NAME TYPE STATUS AGE -mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 4m35s -``` - -After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, -```bash -$ kubectl get pod -n demo mg-gitops-0 -o json | jq '.spec.containers[0].resources' -{ - "limits": { - "memory": "2Gi" - }, - "requests": { - "cpu": "1", - "memory": "2Gi" - } -} - -``` - -### Scale MongoDB Replicas -Update the `MongoDB.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: MongoDB -metadata: - name: mg-gitops - namespace: demo -spec: - version: "8.0.10" - replicaSet: - name: "replicaset" - replicas: 3 - podTemplate: - spec: - containers: - - name: mongodb - resources: - limits: - memory: 2Gi - requests: - cpu: 1000m - memory: 2Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi -``` - -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. -Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` MongoDBOpsRequest to update the `MongoDB` database replicas. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get mg,MongoDB,mgops -n demo -NAME VERSION STATUS AGE -mongodb.kubedb.com/mg-gitops 8.0.10 Ready 18m - -NAME AGE -mongodb.gitops.kubedb.com/mg-gitops 18m - -NAME TYPE STATUS AGE -mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 4m2s -mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 9m5s -``` - -After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, -```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=mg-gitops' -NAME READY STATUS RESTARTS AGE -mg-gitops-0 2/2 Running 0 8m37s -mg-gitops-1 2/2 Running 0 9m22s -mg-gitops-2 2/2 Running 0 4m34s -``` - -We can also scale down the replicas by updating the `replicas` fields. - -### Expand MongoDB Volume - -Update the `MongoDB.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: MongoDB -metadata: - name: mg-gitops - namespace: demo -spec: - version: "8.0.10" - replicaSet: - name: "replicaset" - replicas: 3 - podTemplate: - spec: - containers: - - name: mongodb - resources: - limits: - memory: 2Gi - requests: - cpu: 1000m - memory: 2Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi -``` - -Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. - -Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` MongoDBOpsRequest to update the `MongoDB` database volume. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get mg,MongoDB,mgops -n demo -NAME VERSION STATUS AGE -mongodb.kubedb.com/mg-gitops 8.0.10 Ready 21m - -NAME AGE -mongodb.gitops.kubedb.com/mg-gitops 21m - -NAME TYPE STATUS AGE -mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 7m24s -mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 12m -mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 2m10s -``` - -After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, -```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=mg-gitops' -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -datadir-mg-gitops-0 Bound pvc-cea7fe6a-dd75-4e81-99d3-9ab2867c6650 2Gi RWO longhorn 22m -datadir-mg-gitops-1 Bound pvc-bcd63bd2-b3b8-4fb8-8c35-5f6e40031f61 2Gi RWO longhorn 21m -datadir-mg-gitops-2 Bound pvc-2535f213-28fb-41ef-bdfd-7fbe91859c81 2Gi RWO longhorn 7m56s -``` - -## Reconfigure MongoDB - -At first, we will create `mongod.conf` file containing required configuration settings. - -```ini -$ cat mongod.conf -net: - maxIncomingConnections: 10000 -``` -Here, `maxIncomingConnections` is set to `10000`, whereas the default value is `65536`. - -Now, we will create a secret with this configuration file. - -```bash -$ kubectl create secret generic -n demo mg-custom-config --from-file=./mongod.conf -secret/mg-custom-config created -``` - - -Update the `MongoDB.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: MongoDB -metadata: - name: mg-gitops - namespace: demo -spec: - version: "8.0.10" - replicaSet: - name: "replicaset" - replicas: 3 - podTemplate: - spec: - containers: - - name: mongodb - resources: - limits: - memory: 2Gi - requests: - cpu: 1000m - memory: 2Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - configuration: - secretName: mg-custom-config -``` - -Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. - -Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` MongoDBOpsRequest to update the `MongoDB` database configuration. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get mg,MongoDB,mgops -n demo -NAME VERSION STATUS AGE -mongodb.kubedb.com/mg-gitops 8.0.10 Ready 32m - -NAME AGE -mongodb.gitops.kubedb.com/mg-gitops 32m - -NAME TYPE STATUS AGE -mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 17m -mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 6m7s -mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 22m -mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 12m -``` - -We can also reconfigure the parameters creating another secret and reference the secret in the `configuration.secretName` field. Also you can remove the `configuration` field to use the default parameters. - -### Rotate MongoDB Auth - -To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. - -We will do that using gitops, create the file `kubedb /mg-auth.yaml` with the following content, - -```bash -kubectl create secret generic mgauth -n demo \ - --type=kubernetes.io/basic-auth \ - --from-literal=username=root \ - --from-literal=password=mongodb-secret -secret/mgauth created -``` - - - -Update the `MongoDB.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: MongoDB -metadata: - name: mg-gitops - namespace: demo -spec: - version: "8.0.10" - replicaSet: - name: "replicaset" - replicas: 3 - podTemplate: - spec: - containers: - - name: mongodb - resources: - limits: - memory: 2Gi - requests: - cpu: 1000m - memory: 2Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - configuration: - secretName: mg-custom-config - authSecret: - kind: Secret - name: mgauth -``` - -Add the secret name in `authSecret` field. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. - -Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MongoDBOpsRequest to update the `MongoDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get mg,MongoDB,mgops -n demo -NAME VERSION STATUS AGE -mongodb.kubedb.com/mg-gitops 8.0.10 Ready 41m - -NAME AGE -mongodb.gitops.kubedb.com/mg-gitops 41m - -NAME TYPE STATUS AGE -mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 27m -mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 15m -mongodbopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-u75ihg RotateAuth Successful 3m10s -mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 32m -mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 22m -``` - - -### TLS configuration - -We can add, rotate or remove TLS configuration using `gitops`. - -To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in MongoDB. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. - -- Start off by generating a ca certificates using openssl. - -```bash -$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" -Generating a RSA private key -................+++++ -........................+++++ -writing new private key to './ca.key' ------ -``` - -- Now we are going to create a ca-secret using the certificate files that we have just generated. - -```bash -$ kubectl create secret tls mongo-ca\ - --cert=ca.crt \ - --key=ca.key \ - --namespace=demo -secret/mongo-ca created -``` - -Now, Let's create an `Issuer` using the `mongo-ca` secret that we have just created. The `YAML` file looks like this: - -```yaml -apiVersion: cert-manager.io/v1 -kind: Issuer -metadata: - name: mg-issuer - namespace: demo -spec: - ca: - secretName: mongo-ca -``` - -Let's add that to our `kubedb /mg-issuer.yaml` file. File structure will look like this, -```bash -$ tree . -├── kubedb -│ ├── mg-configuration.yaml -│ ├── mg-issuer.yaml -│ └── MongoDB.yaml -1 directories, 4 files -``` - -Update the `MongoDB.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: MongoDB -metadata: - name: mg-gitops - namespace: demo -spec: - version: "8.0.10" - replicaSet: - name: "replicaset" - replicas: 3 - podTemplate: - spec: - containers: - - name: mongodb - resources: - limits: - memory: 2Gi - requests: - cpu: 1000m - memory: 2Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - configuration: - secretName: mg-custom-config - authSecret: - kind: Secret - name: mgauth - tls: - issuerRef: - apiGroup: "cert-manager.io" - kind: Issuer - name: mg-issuer -``` - -Add `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. - -Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` MongoDBOpsRequest to update the `MongoDB` database tls. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get mg,MongoDB,kfops,pods -n demo -NAME TYPE VERSION STATUS AGE -MongoDB.kubedb.com/mg-gitops kubedb.com/v1 8.0.17 Ready 41m - -NAME AGE -MongoDB.gitops.kubedb.com/mg-gitops 75m - -NAME TYPE STATUS AGE -Elasticsearchopsrequest.ops.kubedb.com/mg-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h -Elasticsearchopsrequest.ops.kubedb.com/mg-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -Elasticsearchopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h -Elasticsearchopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h - -``` - - -> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for MongoDB. - -### Update Version - -List MongoDB versions using `kubectl get mgversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/mongodb/update-version/update-version.md). - -Let's choose `8.0.17` in this example. - -Update the `MongoDB.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: MongoDB -metadata: - name: mg-gitops - namespace: demo -spec: - version: "8.0.17" - replicaSet: - name: "replicaset" - replicas: 3 - podTemplate: - spec: - containers: - - name: mongodb - resources: - limits: - memory: 1Gi - requests: - cpu: "1" - memory: 1Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi -``` - -Update the `version` field to `8.0.17`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. - -Now, `gitops` operator will detect the version changes and create a `VersionUpdate` MongoDBOpsRequest to update the `MongoDB` database version. List the resources created by `gitops` operator in the `demo` namespace. - -```bash -$ kubectl get mg,MongoDB,mgops -n demo -NAME VERSION STATUS AGE -mongodb.kubedb.com/mg-gitops 8.0.17 Ready 46m - -NAME AGE -mongodb.gitops.kubedb.com/mg-gitops 46m - -NAME TYPE STATUS AGE -mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 31m -mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 20m -mongodbopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-u75ihg RotateAuth Successful 7m19s -mongodbopsrequest.ops.kubedb.com/mg-gitops-versionupdate-kkc2gc UpdateVersion Successful 2m38s -mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 36m -mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 26m -``` - - -Now, we are going to verify whether the `MongoDB`, `PetSet` and it's `Pod` have updated with new image. Let's check, - -```bash -$ kubectl get MongoDB -n demo mg-gitops -o=jsonpath='{.spec.version}{"\n"}' -8.0.17 -``` - -### Enable Monitoring - -If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). - -Update the `MongoDB.yaml` with the following, -```yaml -apiVersion: gitops.kubedb.com/v1alpha1 -kind: MongoDB -metadata: - name: mg-gitops - namespace: demo -spec: - version: "8.0.17" - replicaSet: - name: "replicaset" - replicas: 3 - podTemplate: - spec: - containers: - - name: mongodb - resources: - limits: - memory: 2Gi - requests: - cpu: 1000m - memory: 2Gi - storageType: Durable - storage: - storageClassName: longhorn - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - configuration: - secretName: mg-custom-config - authSecret: - kind: Secret - name: mgauth - monitor: - agent: prometheus.io/operator - prometheus: - serviceMonitor: - labels: - release: prometheus - interval: 10s -``` - -Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. - -Now, `gitops` operator will detect the monitoring changes and create a `Restart` MongoDBOpsRequest to add the `MongoDB` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. -```bash -$ kubectl get mg,MongoDB,mgops -n demo -NAME VERSION STATUS AGE -mongodb.kubedb.com/mg-gitops 8.0.17 Ready 52m - -NAME AGE -mongodb.gitops.kubedb.com/mg-gitops 52m - -NAME TYPE STATUS AGE -mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 38m -mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 26m -mongodbopsrequest.ops.kubedb.com/mg-gitops-restart-ykgxj3 Restart Successful 3m45s -mongodbopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-u75ihg RotateAuth Successful 13m -mongodbopsrequest.ops.kubedb.com/mg-gitops-versionupdate-kkc2gc UpdateVersion Successful 9m15s -mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 43m -mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 32m -``` - -Verify the monitoring is enabled by checking the prometheus targets. - -There are some other fields that will trigger `Restart` ops request. -- `.spec.monitor` -- `.spec.spec.archiver` -- `.spec.remoteReplica` -- `spec.replication` -- `.spec.standbyMode` -- `.spec.streamingMode` -- `.spec.enforceGroup` -- `.spec.sslMode` etc. - - -## Next Steps - -[//]: # (- Learn MongoDB [GitOps](/docs/guides/mongodb/concepts/MongoDB-gitops.md)) -- Learn MongoDB Scaling - - [Horizontal Scaling](/docs/guides/mongodb/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/mongodb/scaling/vertical-scaling/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/mongodb/update-version/overview.md) -- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/mongodb/monitoring/using-builtin-prometheus.md). -- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mongodb/gitops/overview.md b/docs/guides/mongodb/gitops/overview.md deleted file mode 100644 index 6e05b2f28a..0000000000 --- a/docs/guides/mongodb/gitops/overview.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: MongoDB Gitops Overview -description: MongoDB Gitops Overview -menu: - docs_{{ .version }}: - identifier: mg-gitops-overview - name: Overview - parent: mg-gitops-mongodb - weight: 10 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -> New to KubeDB? Please start [here](/docs/README.md). - -# GitOps Overview for MongoDB - -This guide will give you an overview of how KubeDB `gitops` operator works with MongoDB databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for -managing MongoDB databases in Kubernetes. - -## Before You Begin - -- You should be familiar with the following `KubeDB` concepts: - - [MongoDB](/docs/guides/MongoDB/concepts/MongoDB/index.md) - - [ElasticsearchOpsRequest](/docs/guides/MongoDB/concepts/MongoDB-ops-request/index.md) - - - -## Workflow GitOps with MongoDB - -The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. - - -
- - GitOps Flow - -
Fig: GitOps process of MongoDB
- -
- -1. **Define GitOps MongoDB**: Create Custom Resource (CR) of kind `MongoDB` using the `gitops.kubedb.com/v1alpha1` API. -2. **Store in Git**: Push the CR to a Git repository. -3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. -4. **Create Database**: The GitOps operator creates a corresponding KubeDB MongoDB CR in the Kubernetes cluster to deploy the database. -5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. - -This flow makes managing MongoDB databases efficient, reliable, and fully integrated with GitOps practices. - -In the next doc, we are going to show a step by step guide on running MongoDB using GitOps. diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md index 0f42931110..6752012107 100644 --- a/docs/guides/mssqlserver/gitops/gitops.md +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -88,7 +88,7 @@ spec: - name: ACCEPT_EULA value: "Y" - name: MSSQL_PID - value: Evaluation # Change it + value: Evaluation storageType: Durable storage: storageClassName: "longhorn" @@ -188,7 +188,7 @@ spec: - name: ACCEPT_EULA value: "Y" - name: MSSQL_PID - value: Evaluation # Change it + value: Evaluation storageType: Durable storage: storageClassName: "longhorn" @@ -228,6 +228,8 @@ We can also scale down the replicas by updating the `replicas` fields. ### Scale Mssqlserver Database Resources +Before the Ops Request reaches the `Successful` state, the configured memory limits are as follows: + ```bash $ kubectl get pod -n demo mssql-gitops-0 -o json | jq '.spec.containers[0].resources' { @@ -270,7 +272,7 @@ spec: - name: ACCEPT_EULA value: "Y" - name: MSSQL_PID - value: Evaluation # Change it + value: Evaluation resources: requests: memory: "2Gi" @@ -355,7 +357,7 @@ spec: - name: ACCEPT_EULA value: "Y" - name: MSSQL_PID - value: Evaluation # Change it + value: Evaluation resources: requests: memory: "2Gi" @@ -449,7 +451,7 @@ spec: - name: ACCEPT_EULA value: "Y" - name: MSSQL_PID - value: Evaluation # Change it + value: Evaluation resources: requests: memory: "2Gi" @@ -495,20 +497,16 @@ mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j Vol ### Rotate Mssqlserver Auth -To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. - -We will do that using gitops, create the file `kubedb /kf-auth.yaml` with the following content, - -```bash -$ kubectl create secret generic mssqlserver-auth -n demo \ - --type=kubernetes.io/basic-auth \ - --from-literal=username=sa \ - --from-literal=password=Mssqlserver2 -secret/mssqlserver-auth created +At first, we need to create a secret with kubernetes.io/basic-auth type using custom username and password. Below is the command to create a secret with kubernetes.io/basic-auth type, +> Note: The `username` must be fixed as `sa`. The `password` must include uppercase letters, lowercase letters, and numbers +```shell +$ kubectl create secret generic mssqlserver-quickstart-auth-user -n demo \ + --type=kubernetes.io/basic-auth \ + --from-literal=username=sa \ + --from-literal=password=Mssqlserver2 +secret/mssqlserver-quickstart-auth-user created ``` - - Update the `Mssqlserver.yaml` ading `authsecret` as the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 @@ -539,7 +537,7 @@ spec: - name: ACCEPT_EULA value: "Y" - name: MSSQL_PID - value: Evaluation # Change it + value: Evaluation resources: requests: memory: "2Gi" @@ -586,7 +584,7 @@ mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j Vol ### Update Version -List Mssqlserver versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/Mssqlserver/update-version/update-version.md). +List Mssqlserver versions using `kubectl get msversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/mssqlserver/update-version/overview.md). Let's choose `2022-cu22` in this example. @@ -620,7 +618,7 @@ spec: - name: ACCEPT_EULA value: "Y" - name: MSSQL_PID - value: Evaluation # Change it + value: Evaluation resources: requests: memory: "2Gi" @@ -663,7 +661,6 @@ mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-rotate-auth-otytes Rot mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-versionupdate-mlq0kn UpdateVersion Successful 13m mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-verticalscaling-yi3db5 VerticalScaling Successful 3h1m mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j VolumeExpansion Successful 165m - ``` @@ -714,7 +711,7 @@ spec: - name: ACCEPT_EULA value: "Y" - name: MSSQL_PID - value: Evaluation # Change it + value: Evaluation resources: requests: memory: "2Gi" @@ -821,7 +818,7 @@ spec: - name: ACCEPT_EULA value: "Y" - name: MSSQL_PID - value: Evaluation # Change it + value: Evaluation resources: requests: memory: "2Gi" @@ -884,10 +881,9 @@ mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j Vol ## Next Steps -[//]: # (- Learn Mssqlserver [GitOps](/docs/guides/Mssqlserver/concepts/Mssqlserver-gitops.md)) - Learn Mssqlserver Scaling - - [Horizontal Scaling](/docs/guides/Mssqlserver/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/Mssqlserver/scaling/vertical-scaling/combined.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/Mssqlserver/update-version/overview.md) -- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/Mssqlserver/monitoring/using-builtin-prometheus.md). + - [Horizontal Scaling](/docs/guides/mssqlserver/scaling/horizontal-scaling/overview.md) + - [Vertical Scaling](/docs/guides/mssqlserver/scaling/vertical-scaling/overview.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/mssqlserver/update-version/overview.md) +- Monitor your MSSQLServer database with KubeDB using [built-in Prometheus](/docs/guides/mssqlserver/monitoring/using-prometheus-operator.md). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mssqlserver/gitops/overview.md b/docs/guides/mssqlserver/gitops/overview.md index e148898936..acd58ce477 100644 --- a/docs/guides/mssqlserver/gitops/overview.md +++ b/docs/guides/mssqlserver/gitops/overview.md @@ -13,20 +13,20 @@ section_menu_id: guides > New to KubeDB? Please start [here](/docs/README.md). -# GitOps Overview for Elasticsearch +# GitOps Overview for MSSQLServer -This guide will give you an overview of how KubeDB `gitops` operator works with Elasticsearch databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for -managing Elasticsearch databases in Kubernetes. +This guide will give you an overview of how KubeDB `gitops` operator works with MSSQLServer databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing MSSQLServer databases in Kubernetes. ## Before You Begin - You should be familiar with the following `KubeDB` concepts: - - [Elasticsearch](/docs/guides/elasticsearch/concepts/elasticsearch/index.md) - - [ElasticsearchOpsRequest](/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md) + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) -## Workflow GitOps with Elasticsearch +## Workflow GitOps with MSSQLServer The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. @@ -35,16 +35,16 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y GitOps Flow -
Fig: GitOps process of Elasticsearch
+
Fig: GitOps process of MSSQLServer
-1. **Define GitOps Elasticsearch**: Create Custom Resource (CR) of kind `Elasticsearch` using the `gitops.kubedb.com/v1alpha1` API. +1. **Define GitOps MSSQLServer**: Create Custom Resource (CR) of kind `MSSQLServer` using the `gitops.kubedb.com/v1alpha1` API. 2. **Store in Git**: Push the CR to a Git repository. 3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. -4. **Create Database**: The GitOps operator creates a corresponding KubeDB Elasticsearch CR in the Kubernetes cluster to deploy the database. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB MSSQLServer CR in the Kubernetes cluster to deploy the database. 5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. -This flow makes managing Elasticsearch databases efficient, reliable, and fully integrated with GitOps practices. +This flow makes managing MSSQLServer databases efficient, reliable, and fully integrated with GitOps practices. -In the next doc, we are going to show a step by step guide on running Elasticsearch using GitOps. +In the next doc, we are going to show a step by step guide on running MSSQLServer using GitOps. diff --git a/docs/guides/mysql/gitops/gitops.md b/docs/guides/mysql/gitops/gitops.md index 5608038d97..8e73baf465 100644 --- a/docs/guides/mysql/gitops/gitops.md +++ b/docs/guides/mysql/gitops/gitops.md @@ -365,7 +365,7 @@ mysql> show variables like 'read_buffer_size'; ``` At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/MySQL/configuration/using-config-file.md) +To know more about this configuration file, check [here](/docs/guides/mysql/configuration/using-config-file.md) ```yaml apiVersion: v1 stringData: @@ -798,7 +798,7 @@ mysql> SHOW VARIABLES LIKE '%require_secure_transport%'; ### Update Version -List MySQL versions using `kubectl get MySQLversion` and choose desired version that is compatible for umyrade from current version. Check the version constraints and ops request [here](/docs/guides/MySQL/update-version/versionumyrading/index.md). +List MySQL versions using `kubectl get MySQLversion` and choose desired version that is compatible for umyrade from current version. Check the version constraints and ops request [here](/docs/guides/mysql/update-version/versionumyrading/index.md). Let's choose `9.6.0` in this example. @@ -983,10 +983,10 @@ There are some other fields that will trigger `Restart` ops request. ## Next Steps -- Learn MySQL [GitOps](/docs/guides/MySQL/concepts/MySQL-gitops.md) +- Learn MySQL [GitOps](/docs/guides/mysql/concepts/MySQL-gitops.md) - Learn MySQL Scaling - - [Horizontal Scaling](/docs/guides/MySQL/scaling/horizontal-scaling/overview/index.md) - - [Vertical Scaling](/docs/guides/MySQL/scaling/vertical-scaling/overview/index.md) -- Learn Version Update Ops Request and Constraints [here](/docs/guides/MySQL/update-version/versionumyrading/index.md) -- Monitor your MySQL database with KubeDB using [built-in Prometheus](/docs/guides/MySQL/monitoring/using-builtin-prometheus.md). + - [Horizontal Scaling](/docs/guides/mysql/scaling/horizontal-scaling/overview/index.md) + - [Vertical Scaling](/docs/guides/mysql/scaling/vertical-scaling/overview/index.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/mysql/update-version/versionumyrading/index.md) +- Monitor your MySQL database with KubeDB using [built-in Prometheus](/docs/guides/mysql/monitoring/using-builtin-prometheus.md). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). From f9e44e6da5681deaab5720bc0efc4c6aded60976 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Mon, 20 Apr 2026 13:07:40 +0600 Subject: [PATCH 24/51] change link Signed-off-by: Bonusree --- docs/guides/mariadb/gitops/gitops.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index dd8ed06cb2..0290ec2163 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -34,7 +34,7 @@ This guide will show you how to use `KubeDB` GitOps operator to create MariaDB d $ kubectl create ns demo namespace/demo created ``` -> Note: YAML files used in this tutorial are stored in [docs/examples/MariaDB](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/MariaDB) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). +> Note: YAML files used in this tutorial are stored in [docs/examples/mariadb](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/mariadb) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). From 2a5ddca91527f7aa70f6b673e5cee9ff4e54548a Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 21 Apr 2026 11:40:27 +0600 Subject: [PATCH 25/51] mariadb Signed-off-by: Bonusree --- docs/guides/mariadb/gitops/gitops.md | 56 ++++++++++++++-------------- 1 file changed, 27 insertions(+), 29 deletions(-) diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index 0290ec2163..689456926b 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -71,7 +71,7 @@ spec: storageType: Durable deletionPolicy: WipeOut storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -129,7 +129,7 @@ appbinding.appcatalog.appscode.com/mariadb-gitops kubedb.com/mariadb 11.8.5 ### Scale MariaDB Database Resources ```shell -$ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[].resources' +$ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[0].resources' { "limits": { "memory": "1Gi" @@ -148,31 +148,31 @@ metadata: name: mariadb-gitops namespace: demo spec: - version: "10.5.23" - replicas: 5 - storageType: Durable + version: "11.8.5" + replicas: 3 podTemplate: spec: containers: - name: mariadb resources: - limits: - cpu: 500m - memory: 1.2Gi requests: - cpu: 100m - memory: 1.2Gi + memory: "1.2Gi" + cpu: "0.6" + limits: + memory: "1.2Gi" + cpu: "0.6" + storageType: Durable + deletionPolicy: WipeOut storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - deletionPolicy: WipeOut ``` -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. +Resource Requests and Limits are updated to `600m` CPU and `1.2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MariaDB` CR is updated in your cluster. Now, `gitops` operator will detect the resource changes and create a `MariaDBOpsRequest` to update the `MariaDB` database. List the resources created by `gitops` operator in the `demo` namespace. @@ -190,16 +190,14 @@ After Ops Request becomes `Successful`, We can validate the changes by checking $ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[0].resources' { "limits": { - "cpu": "500m", + "cpu": "600m", "memory": "1288490188800m" }, "requests": { - "cpu": "100m", + "cpu": "600m", "memory": "1288490188800m" } } - - ``` ### Scale MariaDB Replicas @@ -227,7 +225,7 @@ spec: storageType: Durable deletionPolicy: WipeOut storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -287,7 +285,7 @@ spec: storageType: Durable deletionPolicy: WipeOut storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -314,11 +312,11 @@ After Ops Request becomes `Successful`, We can validate the changes by checking ```bash $ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=mariadb-gitops' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-mariadb-gitops-0 Bound pvc-f1a49c53-d095-43a7-b62f-e91a5a9f5496 2Gi RWO longhorn 116m -data-mariadb-gitops-1 Bound pvc-79d99636-e0d7-413f-a6a6-559e908ed817 2Gi RWO longhorn 116m -data-mariadb-gitops-2 Bound pvc-f66ccf56-63b6-4ac6-a7f9-09f573466266 2Gi RWO longhorn 116m -data-mariadb-gitops-3 Bound pvc-b7744652-611a-4c10-a06f-c93f030fb90f 2Gi RWO longhorn 72m -data-mariadb-gitops-4 Bound pvc-dee1c10d-0456-4935-9306-0d86c3db54d0 2Gi RWO longhorn 71m +data-mariadb-gitops-0 Bound pvc-f1a49c53-d095-43a7-b62f-e91a5a9f5496 2Gi RWO standard 116m +data-mariadb-gitops-1 Bound pvc-79d99636-e0d7-413f-a6a6-559e908ed817 2Gi RWO standard 116m +data-mariadb-gitops-2 Bound pvc-f66ccf56-63b6-4ac6-a7f9-09f573466266 2Gi RWO standard 116m +data-mariadb-gitops-3 Bound pvc-b7744652-611a-4c10-a06f-c93f030fb90f 2Gi RWO standard 72m +data-mariadb-gitops-4 Bound pvc-dee1c10d-0456-4935-9306-0d86c3db54d0 2Gi RWO standard 71m ``` ## Reconfigure MariaDB @@ -373,7 +371,7 @@ spec: storageType: Durable deletionPolicy: WipeOut storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -440,7 +438,7 @@ spec: storageType: Durable deletionPolicy: WipeOut storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -551,7 +549,7 @@ spec: storageType: Durable deletionPolicy: WipeOut storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -630,7 +628,7 @@ spec: storageType: Durable deletionPolicy: WipeOut storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -717,7 +715,7 @@ spec: storageType: Durable deletionPolicy: WipeOut storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: From 0eeaf7c61be3dbe9d475b2900760291df1ea735e Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 21 Apr 2026 17:59:52 +0600 Subject: [PATCH 26/51] topology combined Signed-off-by: Bonusree --- .../kafka/gitops/{gitops.md => topology.md} | 232 +++++++++--------- docs/guides/mariadb/gitops/gitops.md | 2 +- 2 files changed, 120 insertions(+), 114 deletions(-) rename docs/guides/kafka/gitops/{gitops.md => topology.md} (71%) diff --git a/docs/guides/kafka/gitops/gitops.md b/docs/guides/kafka/gitops/topology.md similarity index 71% rename from docs/guides/kafka/gitops/gitops.md rename to docs/guides/kafka/gitops/topology.md index 881efb1dd7..8b1284bf1b 100644 --- a/docs/guides/kafka/gitops/gitops.md +++ b/docs/guides/kafka/gitops/topology.md @@ -61,7 +61,7 @@ argocd app create kubedb --repo --path kubedb --dest-server https://k apiVersion: gitops.kubedb.com/v1alpha1 kind: Kafka metadata: - name: kafka-prod + name: kafka-gitops namespace: demo spec: version: 3.9.0 @@ -102,36 +102,36 @@ Our `gitops` operator will create an actual `Kafka` database CR in the cluster. ```bash -$ kubectl get kafka.gitops.kubedb.com,kafka.kubedb.com -n demo -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 2m56s +$ kubectl get kafka.gitops.kubedb.com,kafka.kubedb.com -n demo +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops-topo 62m -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 2m56s +NAME VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops-topo 3.9.0 Ready 62m ``` List the resources created by `kubedb` operator created for `kubedb.com/v1` Kafka. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=kafka-prod' -NAME AGE -petset.apps.k8s.appscode.com/kafka-prod-broker 4m49s -petset.apps.k8s.appscode.com/kafka-prod-controller 4m47s +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=kafka-gitops-topo' +NAME AGE +petset.apps.k8s.appscode.com/kafka-gitops-topo-broker 62m +petset.apps.k8s.appscode.com/kafka-gitops-topo-controller 62m -NAME READY STATUS RESTARTS AGE -pod/kafka-prod-broker-0 1/1 Running 0 4m48s -pod/kafka-prod-broker-1 1/1 Running 0 4m42s -pod/kafka-prod-controller-0 1/1 Running 0 4m47s -pod/kafka-prod-controller-1 1/1 Running 0 4m40s +NAME READY STATUS RESTARTS AGE +pod/kafka-gitops-topo-broker-0 1/1 Running 0 7m42s +pod/kafka-gitops-topo-broker-1 1/1 Running 0 6m52s +pod/kafka-gitops-topo-controller-0 1/1 Running 0 6m3s +pod/kafka-gitops-topo-controller-1 1/1 Running 0 5m13s -NAME TYPE DATA AGE -secret/kafka-prod-auth kubernetes.io/basic-auth 2 4m51s +NAME TYPE DATA AGE +secret/kafka-gitops-topo-auth kubernetes.io/basic-auth 2 62m -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/kafka-prod-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 4m51s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/kafka-gitops-topo-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 62m -NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/kafka-prod kubedb.com/kafka 3.9.0 4m47s +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/kafka-gitops-topo kubedb.com/kafka 3.9.0 62m ``` ## Update Kafka Database using GitOps @@ -143,7 +143,7 @@ Update the `Kafka.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Kafka metadata: - name: kafka-prod + name: kafka-gitops namespace: demo spec: version: 3.9.0 @@ -190,43 +190,54 @@ spec: deletionPolicy: WipeOut ``` -Resource Requests and Limits are updated to `700m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +The resource requests and limits for the topology broker have been updated to `1536Mi` of memory, and the controller’s memory allocation has also been increased accordingly. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. Now, `gitops` operator will detect the resource changes and create a `KafkaOpsRequest` to update the `Kafka` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ $ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 22h +$ kubectl get kf,kafka,kfops -n demo +NAME VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops-topo 3.9.0 Ready 64m -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 22h +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops-topo 64m -NAME TYPE STATUS AGE -Kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-i0kr1l VerticalScaling Successful 2s +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-gitops-topo-verticalscaling-c2ejz2 VerticalScaling Successful 10m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo Kafka-prod-broker-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo Kafka-gitops-topo-broker-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1717986918400m" + }, + "requests": { + "cpu": "600m", + "memory": "1717986918400m" + } +} +$ kubectl get pod -n demo Kafka-gitops-topo-controller-0 -o json | jq '.spec.containers[0].resources' { "limits": { - "memory": "1536Mi" + "memory": "1717986918400m" }, "requests": { - "cpu": "500m", - "memory": "1536Mi" + "cpu": "600m", + "memory": "1717986918400m" } } ``` ### Scale Kafka Replicas + Update the `Kafka.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: Kafka metadata: - name: kafka-prod + name: kafka-gitops namespace: demo spec: version: 3.9.0 @@ -273,32 +284,32 @@ spec: deletionPolicy: WipeOut ``` -Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Update the replicas count for both the broker and controller to 3. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` KafkaOpsRequest to update the `Kafka` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 22h +kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 22h NAME AGE -kafka.gitops.kubedb.com/kafka-prod 22h +kafka.gitops.kubedb.com/kafka-gitops 22h NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +kafkaopsrequest.ops.kubedb.com/kafka-gitops-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, ```bash -$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=kafka-prod' +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=kafka-gitops' NAME READY STATUS RESTARTS AGE -kafka-prod-broker-0 1/1 Running 0 34m -kafka-prod-broker-1 1/1 Running 0 33m -kafka-prod-broker-2 1/1 Running 0 33m -kafka-prod-controller-0 1/1 Running 0 32m -kafka-prod-controller-1 1/1 Running 0 31m -kafka-prod-controller-2 1/1 Running 0 31m +kafka-gitops-broker-0 1/1 Running 0 34m +kafka-gitops-broker-1 1/1 Running 0 33m +kafka-gitops-broker-2 1/1 Running 0 33m +kafka-gitops-controller-0 1/1 Running 0 32m +kafka-gitops-controller-1 1/1 Running 0 31m +kafka-gitops-controller-2 1/1 Running 0 31m ``` We can also scale down the replicas by updating the `replicas` fields. @@ -310,7 +321,7 @@ Update the `Kafka.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Kafka metadata: - name: kafka-prod + name: kafka-gitops namespace: demo spec: version: 3.9.0 @@ -357,32 +368,32 @@ spec: deletionPolicy: WipeOut ``` -Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Set the `storage.resources.requests.storage` for both the broker and controller to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` KafkaOpsRequest to update the `Kafka` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 23m +kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 23m NAME AGE -kafka.gitops.kubedb.com/kafka-prod 23m +kafka.gitops.kubedb.com/kafka-gitops 23m NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -kafkaopsrequest.ops.kubedb.com/kafka-prod-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 19m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-horizontalscaling-j0wni6 HorizontalScaling Successful 13m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 19m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=kafka-prod' +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=kafka-gitops' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -kafka-prod-data-kafka-prod-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -kafka-prod-data-kafka-prod-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -kafka-prod-data-kafka-prod-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -kafka-prod-data-kafka-prod-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m +kafka-gitops-data-kafka-gitops-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m +kafka-gitops-data-kafka-gitops-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m +kafka-gitops-data-kafka-gitops-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m +kafka-gitops-data-kafka-gitops-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m ``` @@ -394,7 +405,7 @@ To know more about this configuration file, check [here](/docs/guides/kafka/conf apiVersion: v1 kind: Secret metadata: - name: new-kf-combined-custom-config + name: kf-reconfig namespace: demo stringData: server.properties: |- @@ -416,11 +427,11 @@ Update the `Kafka.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Kafka metadata: - name: kafka-prod + name: kafka-gitops namespace: demo spec: configSecret: - name: new-kf-combined-custom-config + name: kf-reconfig version: 3.9.0 topology: broker: @@ -472,15 +483,14 @@ Now, `gitops` operator will detect the configuration changes and create a `Recon ```bash $ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 74m +kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 74m NAME AGE -kafka.gitops.kubedb.com/kafka-prod 74m +kafka.gitops.kubedb.com/kafka-gitops 74m NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 24m -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 70m - +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 24m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 70m ``` @@ -499,7 +509,6 @@ kubectl create secret generic kf-rotate-auth -n demo \ --from-literal=username=kafka \ --from-literal=password=kafka-secret secret/kf-rotate-auth created - ``` @@ -509,14 +518,14 @@ Update the `Kafka.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Kafka metadata: - name: kafka-prod + name: kafka-gitops namespace: demo spec: authSecret: kind: Secret name: kf-rotate-auth configuration: - secretName: new-kf-combined-custom-config + secretName: kf-reconfig version: 3.9.0 topology: broker: @@ -568,16 +577,15 @@ Now, `gitops` operator will detect the auth changes and create a `RotateAuth` Ka ```bash $ kubectl get kf,kafka,kfops -n demo NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 7m11s +kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 7m11s -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 7m11s +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 7m11s NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 17h -kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 28m -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 17h - +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 17h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-43ris8 RotateAuth Successful 28m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 17h ``` @@ -628,7 +636,7 @@ $ tree . │ ├── kf-configuration.yaml │ ├── kf-issuer.yaml │ └── Kafka.yaml -1 directories, 4 files +1 directories, 3 files ``` Update the `Kafka.yaml` with the following, @@ -636,7 +644,7 @@ Update the `Kafka.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Kafka metadata: - name: kafka-prod + name: kafka-gitops namespace: demo spec: version: 3.9.0 @@ -690,17 +698,16 @@ Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ```bash $ kubectl get kf,kafka,kfops,pods -n demo NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 3.9.0 Ready 41m +kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 41m -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 75m +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 75m NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 5d18h -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d1h -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d19h - +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h ``` @@ -708,7 +715,7 @@ kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansi ### Update Version -List Kafka versions using `kubectl get Kafkaversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/kafka/update-version/update-version.md). +List Kafka versions using `kubectl get kafkaversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/kafka/update-version/update-version.md). Let's choose `4.0.0` in this example. @@ -717,7 +724,7 @@ Update the `Kafka.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Kafka metadata: - name: kafka-prod + name: kafka-gitops namespace: demo spec: version: 4.0.0 @@ -764,37 +771,37 @@ spec: deletionPolicy: WipeOut ``` -Update the `version` field to `17.4`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Update the `version` field to `4.0.0`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. Now, `gitops` operator will detect the version changes and create a `VersionUpdate` KafkaOpsRequest to update the `Kafka` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 4.0.0 Ready 3h47m +NAME TYPE VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops kubedb.com/v1 4.0.0 Ready 3h47m -NAME AGE -kafka.gitops.kubedb.com/kafka-prod 3h47m +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 3h47m NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 5d22h -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d6h -kafkaopsrequest.ops.kubedb.com/kafka-prod-versionupdate-wyn2dp UpdateVersion Successful 3h51m -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 5d22h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-43ris8 RotateAuth Successful 5d6h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-versionupdate-wyn2dp UpdateVersion Successful 3h51m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d23h ``` Now, we are going to verify whether the `Kafka`, `PetSet` and it's `Pod` have updated with new image. Let's check, ```bash -$ kubectl get Kafka -n demo kafka-prod -o=jsonpath='{.spec.version}{"\n"}' +$ kubectl get Kafka -n demo kafka-gitops -o=jsonpath='{.spec.version}{"\n"}' 4.0.0 -$ kubectl get petset -n demo kafka-prod-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +$ kubectl get petset -n demo kafka-gitops-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 -$ kubectl get pod -n demo kafka-prod-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +$ kubectl get pod -n demo kafka-gitops-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 ``` @@ -807,7 +814,7 @@ Update the `Kafka.yaml` with the following, apiVersion: gitops.kubedb.com/v1alpha1 kind: Kafka metadata: - name: kafka-prod + name: kafka-gitops namespace: demo spec: version: 4.0.0 @@ -863,25 +870,24 @@ spec: deletionPolicy: WipeOut ``` -Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. +Add `monitor` field in the `spec`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Kafka` CR is updated in your cluster. Now, `gitops` operator will detect the monitoring changes and create a `Restart` KafkaOpsRequest to add the `Kafka` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash $ kubectl get Kafkaes.gitops.kubedb.com,Kafkaes.kubedb.com,Kafkaopsrequest -n demo NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-prod kubedb.com/v1 4.0.0 Ready 5h12m +kafka.kubedb.com/kafka-gitops kubedb.com/v1 4.0.0 Ready 5h12m NAME AGE -kafka.gitops.kubedb.com/kafka-prod 5h12m +kafka.gitops.kubedb.com/kafka-gitops 5h12m NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfigure-ukj41o Reconfigure Successful 6d -kafkaopsrequest.ops.kubedb.com/kafka-prod-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -kafkaopsrequest.ops.kubedb.com/kafka-prod-restart-ljpqih Restart Successful 3m51s -kafkaopsrequest.ops.kubedb.com/kafka-prod-rotate-auth-43ris8 RotateAuth Successful 5d7h -kafkaopsrequest.ops.kubedb.com/kafka-prod-versionupdate-wyn2dp UpdateVersion Successful 5h16m -kafkaopsrequest.ops.kubedb.com/kafka-prod-volumeexpansion-41xthr VolumeExpansion Successful 6d - +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 6d +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-restart-ljpqih Restart Successful 3m51s +kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-43ris8 RotateAuth Successful 5d7h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-versionupdate-wyn2dp UpdateVersion Successful 5h16m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 6d ``` Verify the monitoring is enabled by checking the prometheus targets. diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index 689456926b..18a3221ceb 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -522,7 +522,7 @@ $ tree . │ ├── md-configuration.yaml │ ├── md-issuer.yaml │ └── MariaDB.yaml -1 directories, 4 files +1 directories, 3 files ``` Update the `MariaDB.yaml` with the following, From 99265876574500d57989d604c13646c9f10c53ac Mon Sep 17 00:00:00 2001 From: Bonusree Date: Thu, 23 Apr 2026 15:06:10 +0600 Subject: [PATCH 27/51] topology Signed-off-by: Bonusree --- docs/guides/kafka/gitops/topology.md | 293 +++++++++++++++------------ 1 file changed, 169 insertions(+), 124 deletions(-) diff --git a/docs/guides/kafka/gitops/topology.md b/docs/guides/kafka/gitops/topology.md index 8b1284bf1b..ef6172f50a 100644 --- a/docs/guides/kafka/gitops/topology.md +++ b/docs/guides/kafka/gitops/topology.md @@ -1,9 +1,9 @@ --- -title: Kafka GitOps Guides +title: Topology menu: docs_{{ .version }}: - identifier: kf-gitops-guides - name: Gitops Kafka + identifier: kf-gitops-topology + name: Topology parent: kf-gitops-kafka weight: 20 menu_name: docs_{{ .version }} @@ -104,34 +104,34 @@ Our `gitops` operator will create an actual `Kafka` database CR in the cluster. ```bash $ kubectl get kafka.gitops.kubedb.com,kafka.kubedb.com -n demo NAME AGE -kafka.gitops.kubedb.com/kafka-gitops-topo 62m +kafka.gitops.kubedb.com/kafka-gitops 62m NAME VERSION STATUS AGE -kafka.kubedb.com/kafka-gitops-topo 3.9.0 Ready 62m +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 62m ``` List the resources created by `kubedb` operator created for `kubedb.com/v1` Kafka. ```bash -$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=kafka-gitops-topo' +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=kafka-gitops' NAME AGE -petset.apps.k8s.appscode.com/kafka-gitops-topo-broker 62m -petset.apps.k8s.appscode.com/kafka-gitops-topo-controller 62m +petset.apps.k8s.appscode.com/kafka-gitops-broker 62m +petset.apps.k8s.appscode.com/kafka-gitops-controller 62m NAME READY STATUS RESTARTS AGE -pod/kafka-gitops-topo-broker-0 1/1 Running 0 7m42s -pod/kafka-gitops-topo-broker-1 1/1 Running 0 6m52s -pod/kafka-gitops-topo-controller-0 1/1 Running 0 6m3s -pod/kafka-gitops-topo-controller-1 1/1 Running 0 5m13s +pod/kafka-gitops-broker-0 1/1 Running 0 7m42s +pod/kafka-gitops-broker-1 1/1 Running 0 6m52s +pod/kafka-gitops-controller-0 1/1 Running 0 6m3s +pod/kafka-gitops-controller-1 1/1 Running 0 5m13s NAME TYPE DATA AGE -secret/kafka-gitops-topo-auth kubernetes.io/basic-auth 2 62m +secret/kafka-gitops-auth kubernetes.io/basic-auth 2 62m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/kafka-gitops-topo-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 62m +service/kafka-gitops-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 62m NAME TYPE VERSION AGE -appbinding.appcatalog.appscode.com/kafka-gitops-topo kubedb.com/kafka 3.9.0 62m +appbinding.appcatalog.appscode.com/kafka-gitops kubedb.com/kafka 3.9.0 62m ``` ## Update Kafka Database using GitOps @@ -166,7 +166,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: local-path + storageClassName: standard controller: podTemplate: spec: @@ -185,7 +185,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: local-path + storageClassName: standard storageType: Durable deletionPolicy: WipeOut ``` @@ -197,35 +197,35 @@ Now, `gitops` operator will detect the resource changes and create a `KafkaOpsRe ```bash $ kubectl get kf,kafka,kfops -n demo NAME VERSION STATUS AGE -kafka.kubedb.com/kafka-gitops-topo 3.9.0 Ready 64m +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 64m NAME AGE -kafka.gitops.kubedb.com/kafka-gitops-topo 64m +kafka.gitops.kubedb.com/kafka-gitops 64m NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-gitops-topo-verticalscaling-c2ejz2 VerticalScaling Successful 10m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-c2ejz2 VerticalScaling Successful 10m ``` After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, ```bash -$ kubectl get pod -n demo Kafka-gitops-topo-broker-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo Kafka-gitops-broker-0 -o json | jq '.spec.containers[0].resources' { "limits": { - "memory": "1717986918400m" + "memory": "1540Mi" }, "requests": { - "cpu": "600m", - "memory": "1717986918400m" + "cpu": "500m", + "memory": "1536Mi" } } -$ kubectl get pod -n demo Kafka-gitops-topo-controller-0 -o json | jq '.spec.containers[0].resources' +banusree@bonusree-datta-PC ~> kubectl get pod -n demo Kafka-gitops-controller-0 -o json | jq '.spec.containers[0].resources' { "limits": { - "memory": "1717986918400m" + "memory": "1540Mi" }, "requests": { - "cpu": "600m", - "memory": "1717986918400m" + "cpu": "500m", + "memory": "1536Mi" } } ``` @@ -260,7 +260,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: local-path + storageClassName: standard controller: podTemplate: spec: @@ -279,7 +279,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: local-path + storageClassName: standard storageType: Durable deletionPolicy: WipeOut ``` @@ -374,33 +374,34 @@ Now, `gitops` operator will detect the volume changes and create a `VolumeExpans ```bash $ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 23m +NAME VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 6m51s -NAME AGE -kafka.gitops.kubedb.com/kafka-gitops 23m +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 6m51s -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-gitops-horizontalscaling-j0wni6 HorizontalScaling Successful 13m -kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-tfkvi8 VerticalScaling Successful 8m29s -kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 19m +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-gitops-horizontalscaling-i7l7rn HorizontalScaling Successful 112m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-mwqdzx VerticalScaling Successful 117m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-7aweww VolumeExpansion Successful 4m30s ``` After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, ```bash -$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=kafka-gitops' -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -kafka-gitops-data-kafka-gitops-broker-0 Bound pvc-2afd4835-5686-492b-be93-c6e040e0a6c6 2Gi RWO Standard 3h39m -kafka-gitops-data-kafka-gitops-broker-1 Bound pvc-aaf994cc-6b04-4c37-80d5-5e966dad8487 2Gi RWO Standard 3h39m -kafka-gitops-data-kafka-gitops-controller-0 Bound pvc-82d2b233-203d-4df2-a0fd-ecedbc0825b7 2Gi RWO Standard 3h39m -kafka-gitops-data-kafka-gitops-controller-1 Bound pvc-91852c29-ab1a-48ad-9255-a0b15d5a7515 2Gi RWO Standard 3h39m - +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=kafka-gitops' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +kafka-gitops-data-kafka-gitops-broker-0 Bound pvc-a00ef6d5-44a6-40ce-8131-680b9d24d982 2Gi RWO standard 7m20s +kafka-gitops-data-kafka-gitops-broker-1 Bound pvc-141798c5-9000-480f-a997-85a5743f63e2 2Gi RWO standard 7m4s +kafka-gitops-data-kafka-gitops-broker-2 Bound pvc-819ba56b-4fda-4361-9f3e-e18258e2de7e 2Gi RWO standard 6m46s +kafka-gitops-data-kafka-gitops-controller-0 Bound pvc-5a6cc06e-60ff-450a-875e-b84f75358f67 2Gi RWO standard 7m20s +kafka-gitops-data-kafka-gitops-controller-1 Bound pvc-7cae3a1d-0efc-48a2-8953-12f4338a9602 2Gi RWO standard 7m4s +kafka-gitops-data-kafka-gitops-controller-2 Bound pvc-22e0a63f-58c1-4a03-9493-e670498723db 2Gi RWO standard 6m46s ``` ## Reconfigure Kafka At first, we will create a secret containing `user.conf` file with required configuration settings. -To know more about this configuration file, check [here](/docs/guides/kafka/configuration/kafka-combined.md) +To know more about this configuration file, check [here](/docs/guides/kafka/configuration/kafka-topology.md) ```yaml apiVersion: v1 kind: Secret @@ -482,15 +483,17 @@ Now, `gitops` operator will detect the configuration changes and create a `Recon ```bash $ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 74m +NAME VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 19m -NAME AGE -kafka.gitops.kubedb.com/kafka-gitops 74m +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 19m -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 24m -kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 70m +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-gitops-horizontalscaling-i7l7rn HorizontalScaling Successful 124m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-fszhk8 Reconfigure Successful 8m44s +kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-mwqdzx VerticalScaling Successful 130m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-7aweww VolumeExpansion Successful 16m ``` @@ -504,7 +507,7 @@ To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new use We will create a secret named `kf-rotate-auth ` with the following content, ```bash -kubectl create secret generic kf-rotate-auth -n demo \ +$ kubectl create secret generic kf-rotate-auth -n demo \ --type=kubernetes.io/basic-auth \ --from-literal=username=kafka \ --from-literal=password=kafka-secret @@ -575,17 +578,19 @@ Change the `authSecret` field to `kf-rotate-auth`. Commit the changes and push t Now, `gitops` operator will detect the auth changes and create a `RotateAuth` KafkaOpsRequest to update the `Kafka` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 7m11s +$ kubectl get kf,kafka,kfops -n demo +NAME VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 17h -NAME AGE -kafka.gitops.kubedb.com/kafka-gitops 7m11s +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 17h -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 17h -kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-43ris8 RotateAuth Successful 28m -kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 17h +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-gitops-horizontalscaling-i7l7rn HorizontalScaling Successful 18h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-fszhk8 Reconfigure Successful 16h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-pkb3t1 RotateAuth Successful 13m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-mwqdzx VerticalScaling Successful 18h +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-7aweww VolumeExpansion Successful 17h ``` @@ -648,6 +653,17 @@ metadata: namespace: demo spec: version: 3.9.0 + authSecret: + kind: Secret + name: kf-rotate-auth + configSecret: + name: kf-reconfig-topo + enableSSL: true + tls: + issuerRef: + apiGroup: "cert-manager.io" + kind: Issuer + name: kf-issuer topology: broker: podTemplate: @@ -656,7 +672,7 @@ spec: - name: kafka resources: limits: - memory: 1536Mi + memory: 1540Mi requests: cpu: 500m memory: 1536Mi @@ -667,7 +683,7 @@ spec: resources: requests: storage: 2Gi - storageClassName: Standard + storageClassName: standard controller: podTemplate: spec: @@ -675,7 +691,7 @@ spec: - name: kafka resources: limits: - memory: 1536Mi + memory: 1540Mi requests: cpu: 500m memory: 1536Mi @@ -686,7 +702,7 @@ spec: resources: requests: storage: 2Gi - storageClassName: Standard + storageClassName: standard storageType: Durable deletionPolicy: WipeOut ``` @@ -696,18 +712,20 @@ Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` KafkaOpsRequest to update the `Kafka` database tls. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,kafka,kfops,pods -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 41m +$ kubectl get kf,kafka,kfops,pods -n demo +NAME VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 67m NAME AGE -kafka.gitops.kubedb.com/kafka-gitops 75m +kafka.gitops.kubedb.com/kafka-gitops 67m -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 5d18h -kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s -kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-43ris8 RotateAuth Successful 5d1h -kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d19h +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-gitops-horizontalscaling-rqmqe5 HorizontalScaling Successful 27m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-bqek6h Reconfigure Successful 27m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfiguretls-wkax2u ReconfigureTLS Successful 27m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-y2vwx4 RotateAuth Successful 27m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-c4llju VerticalScaling Successful 27m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-9e85tf VolumeExpansion Successful 27m ``` @@ -728,6 +746,17 @@ metadata: namespace: demo spec: version: 4.0.0 + authSecret: + kind: Secret + name: kf-rotate-auth + configSecret: + name: kf-reconfig-topo + enableSSL: true + tls: + issuerRef: + apiGroup: "cert-manager.io" + kind: Issuer + name: kf-issuer topology: broker: podTemplate: @@ -736,7 +765,7 @@ spec: - name: kafka resources: limits: - memory: 1536Mi + memory: 1540Mi requests: cpu: 500m memory: 1536Mi @@ -747,7 +776,7 @@ spec: resources: requests: storage: 2Gi - storageClassName: Standard + storageClassName: standard controller: podTemplate: spec: @@ -755,7 +784,7 @@ spec: - name: kafka resources: limits: - memory: 1536Mi + memory: 1540Mi requests: cpu: 500m memory: 1536Mi @@ -766,7 +795,7 @@ spec: resources: requests: storage: 2Gi - storageClassName: Standard + storageClassName: standard storageType: Durable deletionPolicy: WipeOut ``` @@ -776,19 +805,21 @@ Update the `version` field to `4.0.0`. Commit the changes and push to your Git r Now, `gitops` operator will detect the version changes and create a `VersionUpdate` KafkaOpsRequest to update the `Kafka` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-gitops kubedb.com/v1 4.0.0 Ready 3h47m +$ kubectl get kf,kafka,kfops,pods -n demo +NAME VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 4.0.0 Ready 72m -NAME AGE -kafka.gitops.kubedb.com/kafka-gitops 3h47m +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 72m -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 5d22h -kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 4h16m -kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-43ris8 RotateAuth Successful 5d6h -kafkaopsrequest.ops.kubedb.com/kafka-gitops-versionupdate-wyn2dp UpdateVersion Successful 3h51m -kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 5d23h +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-gitops-horizontalscaling-rqmqe5 HorizontalScaling Successful 32m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-bqek6h Reconfigure Successful 32m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfiguretls-wkax2u ReconfigureTLS Successful 32m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-y2vwx4 RotateAuth Successful 32m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-versionupdate-6z70bp UpdateVersion Successful 4m16s +kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-c4llju VerticalScaling Successful 32m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-9e85tf VolumeExpansion Successful 32m ``` @@ -797,12 +828,14 @@ Now, we are going to verify whether the `Kafka`, `PetSet` and it's `Pod` have up ```bash $ kubectl get Kafka -n demo kafka-gitops -o=jsonpath='{.spec.version}{"\n"}' 4.0.0 - $ kubectl get petset -n demo kafka-gitops-broker -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 - -$ kubectl get pod -n demo kafka-gitops-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -ghcr.io/appscode-images/kafka:4.0.0@sha256:42a79fe8f14b00b1c76d135bbbaf7605b8c66f45cf3eb749c59138f6df288b31 +ghcr.io/appscode-images/kafka:4.0.0@sha256:62fb3652bc7672a74582d8d0abb7d0090155a237b7cf21bdb3837c3dba107010 +$ kubectl get pod -n demo kafka-gitops-broker-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/kafka:4.0.0@sha256:62fb3652bc7672a74582d8d0abb7d0090155a237b7cf21bdb3837c3dba107010 +$ kubectl get pod -n demo kafka-gitops-controller-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/kafka:4.0.0@sha256:62fb3652bc7672a74582d8d0abb7d0090155a237b7cf21bdb3837c3dba107010 +$ kubectl get petset -n demo kafka-gitops-controller -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/kafka:4.0.0@sha256:62fb3652bc7672a74582d8d0abb7d0090155a237b7cf21bdb3837c3dba107010 ``` ### Enable Monitoring @@ -818,6 +851,26 @@ metadata: namespace: demo spec: version: 4.0.0 + authSecret: + kind: Secret + name: kf-rotate-auth + configSecret: + name: kf-reconfig-topo + enableSSL: true + tls: + issuerRef: + apiGroup: "cert-manager.io" + kind: Issuer + name: kf-issuer + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9091 + serviceMonitor: + labels: + release: prometheus + interval: 10s topology: broker: podTemplate: @@ -826,7 +879,7 @@ spec: - name: kafka resources: limits: - memory: 1536Mi + memory: 1540Mi requests: cpu: 500m memory: 1536Mi @@ -837,7 +890,7 @@ spec: resources: requests: storage: 2Gi - storageClassName: Standard + storageClassName: standard controller: podTemplate: spec: @@ -845,7 +898,7 @@ spec: - name: kafka resources: limits: - memory: 1536Mi + memory: 1540Mi requests: cpu: 500m memory: 1536Mi @@ -856,17 +909,8 @@ spec: resources: requests: storage: 2Gi - storageClassName: Standard + storageClassName: standard storageType: Durable - monitor: - agent: prometheus.io/operator - prometheus: - exporter: - port: 9091 - serviceMonitor: - labels: - release: prometheus - interval: 10s deletionPolicy: WipeOut ``` @@ -874,20 +918,22 @@ Add `monitor` field in the `spec`. Commit the changes and push to your Git repos Now, `gitops` operator will detect the monitoring changes and create a `Restart` KafkaOpsRequest to add the `Kafka` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get Kafkaes.gitops.kubedb.com,Kafkaes.kubedb.com,Kafkaopsrequest -n demo -NAME TYPE VERSION STATUS AGE -kafka.kubedb.com/kafka-gitops kubedb.com/v1 4.0.0 Ready 5h12m +$ kubectl get kf,kafka,kfops -n demo +NAME VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 4.0.0 Ready 90m -NAME AGE -kafka.gitops.kubedb.com/kafka-gitops 5h12m +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 90m -NAME TYPE STATUS AGE -kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-ukj41o Reconfigure Successful 6d -kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 5h42m -kafkaopsrequest.ops.kubedb.com/kafka-gitops-restart-ljpqih Restart Successful 3m51s -kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-43ris8 RotateAuth Successful 5d7h -kafkaopsrequest.ops.kubedb.com/kafka-gitops-versionupdate-wyn2dp UpdateVersion Successful 5h16m -kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-41xthr VolumeExpansion Successful 6d +NAME TYPE STATUS AGE +kafkaopsrequest.ops.kubedb.com/kafka-gitops-horizontalscaling-rqmqe5 HorizontalScaling Successful 49m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfigure-bqek6h Reconfigure Successful 49m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-reconfiguretls-wkax2u ReconfigureTLS Successful 49m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-restart-kzxwxa Restart Successful 12m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-rotate-auth-y2vwx4 RotateAuth Successful 49m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-versionupdate-6z70bp UpdateVersion Successful 22m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-c4llju VerticalScaling Successful 49m +kafkaopsrequest.ops.kubedb.com/kafka-gitops-volumeexpansion-9e85tf VolumeExpansion Successful 49m ``` Verify the monitoring is enabled by checking the prometheus targets. @@ -905,10 +951,9 @@ There are some other fields that will trigger `Restart` ops request. ## Next Steps -[//]: # (- Learn Kafka [GitOps](/docs/guides/kafka/concepts/Kafka-gitops.md)) - Learn Kafka Scaling - - [Horizontal Scaling](/docs/guides/kafka/scaling/horizontal-scaling/combined.md) - - [Vertical Scaling](/docs/guides/kafka/scaling/vertical-scaling/combined.md) + - [Horizontal Scaling](/docs/guides/kafka/scaling/horizontal-scaling/topology.md) + - [Vertical Scaling](/docs/guides/kafka/scaling/vertical-scaling/topology.md) - Learn Version Update Ops Request and Constraints [here](/docs/guides/kafka/update-version/overview.md) - Monitor your KafkaQL database with KubeDB using [built-in Prometheus](/docs/guides/kafka/monitoring/using-builtin-prometheus.md). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). From dc747e671e19cb017ffcce4c5a31b6ce3324aab0 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Thu, 23 Apr 2026 15:10:01 +0600 Subject: [PATCH 28/51] topology Signed-off-by: Bonusree --- docs/guides/kafka/gitops/topology.md | 30 ++++++++++++++-------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/docs/guides/kafka/gitops/topology.md b/docs/guides/kafka/gitops/topology.md index ef6172f50a..53df7475ee 100644 --- a/docs/guides/kafka/gitops/topology.md +++ b/docs/guides/kafka/gitops/topology.md @@ -197,10 +197,10 @@ Now, `gitops` operator will detect the resource changes and create a `KafkaOpsRe ```bash $ kubectl get kf,kafka,kfops -n demo NAME VERSION STATUS AGE -kafka.kubedb.com/kafka-gitops 3.9.0 Ready 64m +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 64m NAME AGE -kafka.gitops.kubedb.com/kafka-gitops 64m +kafka.gitops.kubedb.com/kafka-gitops 64m NAME TYPE STATUS AGE kafkaopsrequest.ops.kubedb.com/kafka-gitops-verticalscaling-c2ejz2 VerticalScaling Successful 10m @@ -289,7 +289,7 @@ Now, `gitops` operator will detect the replica changes and create a `HorizontalS ```bash $ kubectl get kf,kafka,kfops -n demo -NAME TYPE VERSION STATUS AGE +NAME TYPE VERSION STATUS AGE kafka.kubedb.com/kafka-gitops kubedb.com/v1 3.9.0 Ready 22h NAME AGE @@ -337,7 +337,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -356,7 +356,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -446,7 +446,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -465,7 +465,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -542,7 +542,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -561,7 +561,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -676,7 +676,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -695,7 +695,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -769,7 +769,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -788,7 +788,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -883,7 +883,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce @@ -902,7 +902,7 @@ spec: requests: cpu: 500m memory: 1536Mi - replicas: 2 + replicas: 3 storage: accessModes: - ReadWriteOnce From 37dadff2924f65008ca644debb6a761d9de9075c Mon Sep 17 00:00:00 2001 From: Bonusree Date: Fri, 24 Apr 2026 12:07:32 +0600 Subject: [PATCH 29/51] mongo added Signed-off-by: Bonusree --- docs/guides/mongodb/gitops/gitops.md | 640 ++++++++++++++++++ docs/guides/mongodb/gitops/overview.md | 50 ++ .../backup/application-level/index.md | 2 +- .../mssqlserver/backup/auto-backup/index.md | 2 +- .../mssqlserver/backup/logical/index.md | 2 +- docs/guides/mssqlserver/gitops/gitops.md | 24 +- docs/guides/mysql/gitops/gitops.md | 28 +- .../kubestash/application-level/index.md | 2 +- .../backup/kubestash/auto-backup/index.md | 2 +- .../backup/kubestash/logical/index.md | 2 +- .../clustering/proxysql-cluster/index.md | 2 +- docs/guides/proxysql/restart/index.md | 2 +- .../kubestash/application-level/index.md | 2 +- .../backup/kubestash/auto-backup/index.md | 2 +- .../redis/backup/kubestash/logical/index.md | 2 +- .../guides/singlestore/concepts/appbinding.md | 2 +- .../backup/kubestash/auto-backup/index.md | 2 +- .../backup/kubestash/logical/index.md | 2 +- 18 files changed, 730 insertions(+), 40 deletions(-) create mode 100644 docs/guides/mongodb/gitops/gitops.md create mode 100644 docs/guides/mongodb/gitops/overview.md diff --git a/docs/guides/mongodb/gitops/gitops.md b/docs/guides/mongodb/gitops/gitops.md new file mode 100644 index 0000000000..552f686d69 --- /dev/null +++ b/docs/guides/mongodb/gitops/gitops.md @@ -0,0 +1,640 @@ +--- +title: MongoDB Gitops +description: MongoDB Gitops +menu: + docs_{{ .version }}: + identifier: mg-gitops + name: MongoDB Gitops + parent: mg-gitops-mongodb + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + + + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps MongoDB using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create MongoDB database and manage updates using GitOps workflow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/MongoDB](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/mongodb) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create MongoDB Database using GitOps + +### Create a MongoDB GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MongoDB +metadata: + name: mg-gitops + namespace: demo +spec: + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 2 + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── MongoDB.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is created in your cluster. + +Our `gitops` operator will create an actual `MongoDB` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get MongoDB.gitops.kubedb.com,MongoDB.kubedb.com -n demo +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 33m + +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 33m + +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` MongoDB. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=mg-gitops' +NAME AGE +petset.apps.k8s.appscode.com/mg-gitops 34m + +NAME READY STATUS RESTARTS AGE +pod/mg-gitops-0 2/2 Running 0 34m +pod/mg-gitops-1 2/2 Running 0 33m + +NAME TYPE DATA AGE +secret/mg-gitops-auth kubernetes.io/basic-auth 2 34m +secret/mg-gitops-key Opaque 1 34m + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/mg-gitops ClusterIP 10.43.206.183 27017/TCP 34m +service/mg-gitops-pods ClusterIP None 27017/TCP 34m + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/mg-gitops kubedb.com/mongodb 8.0.10 34m + +``` + +## Update MongoDB Database using GitOps + +### Scale MongoDB Database Resources + +Before scaling database resouces: + +```shell +kubectl get pod -n demo mg-gitops-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "800m", + "memory": "1536Mi" + } +} +``` +Update the `MongoDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MongoDB +metadata: + name: mg-gitops + namespace: demo +spec: + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 2 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + ``` + +Resource Requests and Limits are updated from `800m` to `1000m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `MongoDBOpsRequest` to update the `MongoDB` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 13m + +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 13m + +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 4m35s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo mg-gitops-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "2Gi" + }, + "requests": { + "cpu": "1", + "memory": "2Gi" + } +} + +``` + +### Scale MongoDB Replicas +Update the `MongoDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MongoDB +metadata: + name: mg-gitops + namespace: demo +spec: + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi +``` + +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` MongoDBOpsRequest to update the `MongoDB` database replicas. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 18m + +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 18m + +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 4m2s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 9m5s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=mg-gitops' +NAME READY STATUS RESTARTS AGE +mg-gitops-0 2/2 Running 0 8m37s +mg-gitops-1 2/2 Running 0 9m22s +mg-gitops-2 2/2 Running 0 4m34s +``` + +We can also scale down the replicas by updating the `replicas` fields. + +### Expand MongoDB Volume + +Update the `MongoDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MongoDB +metadata: + name: mg-gitops + namespace: demo +spec: + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi +``` + +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` MongoDBOpsRequest to update the `MongoDB` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 21m + +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 21m + +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 7m24s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 12m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 2m10s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=mg-gitops' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +datadir-mg-gitops-0 Bound pvc-cea7fe6a-dd75-4e81-99d3-9ab2867c6650 2Gi RWO standard 22m +datadir-mg-gitops-1 Bound pvc-bcd63bd2-b3b8-4fb8-8c35-5f6e40031f61 2Gi RWO standard 21m +datadir-mg-gitops-2 Bound pvc-2535f213-28fb-41ef-bdfd-7fbe91859c81 2Gi RWO standard 7m56s +``` + +## Reconfigure MongoDB + +At first, we will create `mongod.conf` file containing required configuration settings. + +```ini +$ cat mongod.conf +net: + maxIncomingConnections: 10000 +``` +Here, `maxIncomingConnections` is set to `10000`, whereas the default value is `65536`. + +Now, we will create a secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo mg-custom-config --from-file=./mongod.conf +secret/mg-custom-config created +``` + + +Update the `MongoDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MongoDB +metadata: + name: mg-gitops + namespace: demo +spec: + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: mg-custom-config +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` MongoDBOpsRequest to update the `MongoDB` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 32m + +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 32m + +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 17m +mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 6m7s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 22m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 12m +``` + +We can also reconfigure the parameters creating another secret and reference the secret in the `configuration.secretName` field. Also you can remove the `configuration` field to use the default parameters. + +### Rotate Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will do that using gitops, create the file `kubedb /mg-auth.yaml` with the following content, + +```bash +kubectl create secret generic mgauth -n demo \ + --type=kubernetes.io/basic-auth \ + --from-literal=username=root \ + --from-literal=password=mongodb-secret +secret/mgauth created +``` + + + +Update the `MongoDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MongoDB +metadata: + name: mg-gitops + namespace: demo +spec: + version: "8.0.10" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: mg-custom-config + authSecret: + kind: Secret + name: mgauth +``` + +Add the secret name in `authSecret` field. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MongoDBOpsRequest to update the `MongoDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.10 Ready 41m + +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 41m + +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 27m +mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 15m +mongodbopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-u75ihg RotateAuth Successful 3m10s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 32m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 22m +``` + +### Update Version + +List MongoDB versions using `kubectl get mgversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/mongodb/update-version/replicaset.md). + +Let's choose `8.0.17` in this example. + +Update the `MongoDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MongoDB +metadata: + name: mg-gitops + namespace: demo +spec: + version: "8.0.17" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 1Gi + requests: + cpu: "1" + memory: 1Gi + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi +``` + +Update the `version` field to `8.0.17`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` MongoDBOpsRequest to update the `MongoDB` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.17 Ready 46m + +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 46m + +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 31m +mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 20m +mongodbopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-u75ihg RotateAuth Successful 7m19s +mongodbopsrequest.ops.kubedb.com/mg-gitops-versionupdate-kkc2gc UpdateVersion Successful 2m38s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 36m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 26m +``` + + +Now, we are going to verify whether the `MongoDB`, `PetSet` and it's `Pod` have updated with new image. Let's check, + +```bash +$ kubectl get MongoDB -n demo mg-gitops -o=jsonpath='{.spec.version}{"\n"}' +8.0.17 +$ kubectl get petset -n demo mg-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/mongo:8.0.17@sha256:b3e1ae71bd7df56b3497527f2b08549bfccb532d9e26df6d4a1331a71cd085db +$ kubectl get pod -n demo mg-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/mongo:8.0.17@sha256:b3e1ae71bd7df56b3497527f2b08549bfccb532d9e26df6d4a1331a71cd085db +``` + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `MongoDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MongoDB +metadata: + name: mg-gitops + namespace: demo +spec: + version: "8.0.17" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: mg-custom-config + authSecret: + kind: Secret + name: mgauth + monitor: + agent: prometheus.io/operator + prometheus: + serviceMonitor: + labels: + release: prometheus + interval: 10s +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` MongoDBOpsRequest to add the `MongoDB` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get mg,MongoDB,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.17 Ready 52m + +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 52m + +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-horizontalscaling-n8xx64 HorizontalScaling Successful 38m +mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfigure-djow20 Reconfigure Successful 26m +mongodbopsrequest.ops.kubedb.com/mg-gitops-restart-ykgxj3 Restart Successful 3m45s +mongodbopsrequest.ops.kubedb.com/mg-gitops-rotate-auth-u75ihg RotateAuth Successful 13m +mongodbopsrequest.ops.kubedb.com/mg-gitops-versionupdate-kkc2gc UpdateVersion Successful 9m15s +mongodbopsrequest.ops.kubedb.com/mg-gitops-verticalscaling-ojwxpm VerticalScaling Successful 43m +mongodbopsrequest.ops.kubedb.com/mg-gitops-volumeexpansion-8441ym VolumeExpansion Successful 32m +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + +## Next Steps + +- Learn MongoDB Scaling + - [Horizontal Scaling](/docs/guides/mongodb/scaling/horizontal-scaling/replicaset.md) + - [Vertical Scaling](/docs/guides/mongodb/scaling/vertical-scaling/replicaset.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/mongodb/update-version/replicaset.md) +- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/mongodb/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mongodb/gitops/overview.md b/docs/guides/mongodb/gitops/overview.md new file mode 100644 index 0000000000..cc9f14a7b4 --- /dev/null +++ b/docs/guides/mongodb/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: MongoDB Gitops Overview +description: MongoDB Gitops Overview +menu: + docs_{{ .version }}: + identifier: mg-gitops-overview + name: Overview + parent: mg-gitops-mongodb + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for MongoDB + +This guide will give you an overview of how KubeDB `gitops` operator works with MongoDB databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing MongoDB databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MongoDB](/docs/guides/mongodb/concepts/mongodb.md) + - [MongoDBOpsRequest](/docs/guides/mongodb/concepts/opsrequest.md) + + + +## Workflow GitOps with MongoDB + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + + +
+ + GitOps Flow + +
Fig: GitOps process of MongoDB
+ +
+ +1. **Define GitOps MongoDB**: Create Custom Resource (CR) of kind `MongoDB` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB MongoDB CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing MongoDB databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running MongoDB using GitOps. diff --git a/docs/guides/mssqlserver/backup/application-level/index.md b/docs/guides/mssqlserver/backup/application-level/index.md index b5c9c4f0b3..442c8af4da 100644 --- a/docs/guides/mssqlserver/backup/application-level/index.md +++ b/docs/guides/mssqlserver/backup/application-level/index.md @@ -43,7 +43,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/mssqlserver/backup/application-level/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mssqlserver/backup/application-level/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/mssqlserver/backup/application-level/examples](/docs/guides/mssqlserver/backup/application-level/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ## Backup Microsoft SQL Server diff --git a/docs/guides/mssqlserver/backup/auto-backup/index.md b/docs/guides/mssqlserver/backup/auto-backup/index.md index 168f4a9145..d3918aa655 100644 --- a/docs/guides/mssqlserver/backup/auto-backup/index.md +++ b/docs/guides/mssqlserver/backup/auto-backup/index.md @@ -42,7 +42,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/mssqlserver/backup/auto-backup/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mssqlserver/backup/auto-backup/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/mssqlserver/backup/auto-backup/examples](/docs/guides/mssqlserver/backup/auto-backup/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ### Prepare Backend diff --git a/docs/guides/mssqlserver/backup/logical/index.md b/docs/guides/mssqlserver/backup/logical/index.md index c9e124c6a2..455246e079 100644 --- a/docs/guides/mssqlserver/backup/logical/index.md +++ b/docs/guides/mssqlserver/backup/logical/index.md @@ -42,7 +42,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/mssqlserver/backup/logical/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mssqlserver/backup/logical/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/mssqlserver/backup/logical/examples](/docs/guides/mssqlserver/backup/logical/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ## Backup Microsoft SQL Server diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md index 6752012107..599031d1a7 100644 --- a/docs/guides/mssqlserver/gitops/gitops.md +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -91,7 +91,7 @@ spec: value: Evaluation storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -191,7 +191,7 @@ spec: value: Evaluation storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -282,7 +282,7 @@ spec: memory: "2Gi" storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -367,7 +367,7 @@ spec: memory: "2Gi" storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -398,9 +398,9 @@ After Ops Request becomes `Successful`, We can validate the changes by checking ```bash $ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=mssql-gitops' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-mssql-gitops-0 Bound pvc-481caac3-7849-422c-9d8f-704ef82b3bc6 2Gi RWO longhorn 20h -data-mssql-gitops-1 Bound pvc-49ea234d-e7e2-4a3b-9372-b430d72fee5e 2Gi RWO longhorn 19h -data-mssql-gitops-2 Bound pvc-c72d4562-81d2-405b-ae8d-52816e59767f 2Gi RWO longhorn 19h +data-mssql-gitops-0 Bound pvc-481caac3-7849-422c-9d8f-704ef82b3bc6 2Gi RWO standard 20h +data-mssql-gitops-1 Bound pvc-49ea234d-e7e2-4a3b-9372-b430d72fee5e 2Gi RWO standard 19h +data-mssql-gitops-2 Bound pvc-c72d4562-81d2-405b-ae8d-52816e59767f 2Gi RWO standard 19h ``` ## Reconfigure Mssqlserver @@ -463,7 +463,7 @@ spec: secretName: ms-custom-config storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -552,7 +552,7 @@ spec: name: mssqlserver-auth storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -633,7 +633,7 @@ spec: name: mssqlserver-auth storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -726,7 +726,7 @@ spec: name: mssqlserver-auth storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -828,7 +828,7 @@ spec: memory: "2Gi" storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mysql/gitops/gitops.md b/docs/guides/mysql/gitops/gitops.md index 8e73baf465..9d9e7a3333 100644 --- a/docs/guides/mysql/gitops/gitops.md +++ b/docs/guides/mysql/gitops/gitops.md @@ -71,7 +71,7 @@ spec: mode: Single-Primary storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -157,7 +157,7 @@ spec: cpu: 700m memory: 1.5Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -166,7 +166,7 @@ spec: deletionPolicy: WipeOut ``` -Resource Requests and Limits are updated to `700m` CPU and `1536Mi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. +Resource requests have been updated to `700m` CPU and `1536Mi` memory, and the memory limits have been set to `1.5Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MySQL` CR is updated in your cluster. Now, `gitops` operator will detect the resource changes and create a `MySQLOpsRequest` to update the `MySQL` database. List the resources created by `gitops` operator in the `demo` namespace. @@ -223,7 +223,7 @@ spec: cpu: 700m memory: 1.5Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -289,7 +289,7 @@ spec: cpu: 700m memory: 1.5Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -321,10 +321,10 @@ After Ops Request becomes `Successful`, We can validate the changes by checking ```bash $ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=my-gitops' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-my-gitops-0 Bound pvc-c926c69f-ff5e-4f93-be78-1fc1d39da25c 2Gi RWO longhorn 105m -data-my-gitops-1 Bound pvc-8bfcf4d8-37fb-4543-96c5-7a656270967a 2Gi RWO longhorn 101m -data-my-gitops-2 Bound pvc-238989bc-0a53-4db8-a3c2-2ce77aee4042 2Gi RWO longhorn 101m -data-my-gitops-3 Bound pvc-5345bc6a-baad-461a-a1fe-108e75c32a11 2Gi RWO longhorn 8m41s +data-my-gitops-0 Bound pvc-c926c69f-ff5e-4f93-be78-1fc1d39da25c 2Gi RWO standard 105m +data-my-gitops-1 Bound pvc-8bfcf4d8-37fb-4543-96c5-7a656270967a 2Gi RWO standard 101m +data-my-gitops-2 Bound pvc-238989bc-0a53-4db8-a3c2-2ce77aee4042 2Gi RWO standard 101m +data-my-gitops-3 Bound pvc-5345bc6a-baad-461a-a1fe-108e75c32a11 2Gi RWO standard 8m41s ``` ## Reconfigure MySQL @@ -418,7 +418,7 @@ spec: cpu: 700m memory: 1.5Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -545,7 +545,7 @@ spec: cpu: 700m memory: 1.5Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -693,7 +693,7 @@ spec: cpu: 700m memory: 1.5Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -845,7 +845,7 @@ spec: cpu: 700m memory: 1.5Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -936,7 +936,7 @@ spec: cpu: 700m memory: 1.5Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/postgres/backup/kubestash/application-level/index.md b/docs/guides/postgres/backup/kubestash/application-level/index.md index e1a85772c7..f3b305925d 100644 --- a/docs/guides/postgres/backup/kubestash/application-level/index.md +++ b/docs/guides/postgres/backup/kubestash/application-level/index.md @@ -42,7 +42,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/postgres/backup/kubestash/application-level/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/postgres/backup/kubestash/application-level/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/postgres/backup/kubestash/application-level/examples](/docs/guides/postgres/backup/kubestash/application-level/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ## Backup PostgreSQL diff --git a/docs/guides/postgres/backup/kubestash/auto-backup/index.md b/docs/guides/postgres/backup/kubestash/auto-backup/index.md index f7c4edde7c..1fece38734 100644 --- a/docs/guides/postgres/backup/kubestash/auto-backup/index.md +++ b/docs/guides/postgres/backup/kubestash/auto-backup/index.md @@ -42,7 +42,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/postgres/backup/kubestash/auto-backup/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/postgres/backup/kubestash/auto-backup/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/postgres/backup/kubestash/auto-backup/examples](/docs/guides/postgres/backup/kubestash/auto-backup/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ### Prepare Backend diff --git a/docs/guides/postgres/backup/kubestash/logical/index.md b/docs/guides/postgres/backup/kubestash/logical/index.md index 731a012df7..01c453a98c 100644 --- a/docs/guides/postgres/backup/kubestash/logical/index.md +++ b/docs/guides/postgres/backup/kubestash/logical/index.md @@ -43,7 +43,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/postgres/backup/kubestash/logical/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/postgres/backup/kubestash/logical/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/postgres/backup/kubestash/logical/examples](/docs/guides/postgres/backup/kubestash/logical/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ## Backup PostgreSQL diff --git a/docs/guides/proxysql/clustering/proxysql-cluster/index.md b/docs/guides/proxysql/clustering/proxysql-cluster/index.md index 0cd85bb50a..4c6828e375 100644 --- a/docs/guides/proxysql/clustering/proxysql-cluster/index.md +++ b/docs/guides/proxysql/clustering/proxysql-cluster/index.md @@ -311,7 +311,7 @@ root@proxy-server-1:/# chmod +x load.sh root@proxy-server-1:/# ./load.sh ``` -> You can find the load.sh file [here](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/proxysql/clustering/proxysql-cluster/examples/load.sh) +> You can find the load.sh file [here](/docs/guides/proxysql/clustering/proxysql-cluster/examples/load.sh) ```bash $ kubectl exec -it -n demo proxy-server-1 -- bash diff --git a/docs/guides/proxysql/restart/index.md b/docs/guides/proxysql/restart/index.md index b4fdb88fc9..516b603fa4 100644 --- a/docs/guides/proxysql/restart/index.md +++ b/docs/guides/proxysql/restart/index.md @@ -72,7 +72,7 @@ $ kubectl get my -n demo NAME VERSION STATUS AGE mysql-server 8.4.3 Ready 7m6s ``` -> Here you can use MariaDB or PerconXtraDB as well as backend. Have a look at other [ProxySQL backend examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/proxysql/backends/) +> Here you can use MariaDB or PerconXtraDB as well as backend. Have a look at other [ProxySQL backend examples](/docs/guides/proxysql/backends/) Now we are ready to deploy and test our ProxySQL server. diff --git a/docs/guides/redis/backup/kubestash/application-level/index.md b/docs/guides/redis/backup/kubestash/application-level/index.md index 15c0cdd0b2..240ab737d1 100644 --- a/docs/guides/redis/backup/kubestash/application-level/index.md +++ b/docs/guides/redis/backup/kubestash/application-level/index.md @@ -42,7 +42,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/application-level/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/application-level/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/application-level/examples](/docs/guides/redis/backup/kubestash/application-level/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ## Backup Redis diff --git a/docs/guides/redis/backup/kubestash/auto-backup/index.md b/docs/guides/redis/backup/kubestash/auto-backup/index.md index 1853c6cf8f..aa08c8e068 100644 --- a/docs/guides/redis/backup/kubestash/auto-backup/index.md +++ b/docs/guides/redis/backup/kubestash/auto-backup/index.md @@ -42,7 +42,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/auto-backup/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/auto-backup/examples](/docs/guides/redis/backup/kubestash/auto-backup/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ### Prepare Backend diff --git a/docs/guides/redis/backup/kubestash/logical/index.md b/docs/guides/redis/backup/kubestash/logical/index.md index 6dee943768..9374e6749c 100644 --- a/docs/guides/redis/backup/kubestash/logical/index.md +++ b/docs/guides/redis/backup/kubestash/logical/index.md @@ -43,7 +43,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/logical/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/logical/examples](/docs/guides/redis/backup/kubestash/logical/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ## Backup Redis diff --git a/docs/guides/singlestore/concepts/appbinding.md b/docs/guides/singlestore/concepts/appbinding.md index 6324b158c5..43e8b4aead 100644 --- a/docs/guides/singlestore/concepts/appbinding.md +++ b/docs/guides/singlestore/concepts/appbinding.md @@ -18,7 +18,7 @@ section_menu_id: guides An `AppBinding` is a Kubernetes `CustomResourceDefinition`(CRD) which points to an application using either its URL (usually for a non-Kubernetes resident service instance) or a Kubernetes service object (if self-hosted in a Kubernetes cluster), some optional parameters and a credential secret. To learn more about AppBinding and the problems it solves, please read this blog post: [The case for AppBinding](https://appscode.com/blog/post/the-case-for-appbinding). -If you deploy a database using [KubeDB](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/concepts/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database. +If you deploy a database using [KubeDB]/docs/concepts/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database. KubeDB uses [Stash](https://appscode.com/products/stash/) to perform backup/recovery of databases. Stash needs to know how to connect with a target database and the credentials necessary to access it. This is done via an `AppBinding`. diff --git a/docs/guides/zookeeper/backup/kubestash/auto-backup/index.md b/docs/guides/zookeeper/backup/kubestash/auto-backup/index.md index a21b7deb61..747edc1e58 100644 --- a/docs/guides/zookeeper/backup/kubestash/auto-backup/index.md +++ b/docs/guides/zookeeper/backup/kubestash/auto-backup/index.md @@ -42,7 +42,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/zookeeper/backup/kubestash/auto-backup/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/zookeeper/backup/kubestash/auto-backup/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/zookeeper/backup/kubestash/auto-backup/examples](/docs/guides/zookeeper/backup/kubestash/auto-backup/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ### Prepare Backend diff --git a/docs/guides/zookeeper/backup/kubestash/logical/index.md b/docs/guides/zookeeper/backup/kubestash/logical/index.md index 02be21a268..d53e2af5d5 100644 --- a/docs/guides/zookeeper/backup/kubestash/logical/index.md +++ b/docs/guides/zookeeper/backup/kubestash/logical/index.md @@ -43,7 +43,7 @@ $ kubectl create ns demo namespace/demo created ``` -> **Note:** YAML files used in this tutorial are stored in [docs/guides/zookeeper/backup/kubestash/logical/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/zookeeper/backup/kubestash/logical/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. +> **Note:** YAML files used in this tutorial are stored in [docs/guides/zookeeper/backup/kubestash/logical/examples](/docs/guides/zookeeper/backup/kubestash/logical/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. ## Backup ZooKeeper From 0a62afce8cde6ad762341f1c77839a881c0debc1 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Fri, 24 Apr 2026 17:58:57 +0600 Subject: [PATCH 30/51] redis without tls Signed-off-by: Bonusree --- docs/guides/kafka/gitops/topology.md | 4 +- docs/guides/mongodb/gitops/_index.md | 10 + docs/guides/redis/gitops/_index.md | 10 + docs/guides/redis/gitops/gitops.md | 670 +++++++++++++++++++++++++++ docs/guides/redis/gitops/overview.md | 50 ++ 5 files changed, 742 insertions(+), 2 deletions(-) create mode 100644 docs/guides/mongodb/gitops/_index.md create mode 100644 docs/guides/redis/gitops/_index.md create mode 100644 docs/guides/redis/gitops/gitops.md create mode 100644 docs/guides/redis/gitops/overview.md diff --git a/docs/guides/kafka/gitops/topology.md b/docs/guides/kafka/gitops/topology.md index 53df7475ee..74c8863955 100644 --- a/docs/guides/kafka/gitops/topology.md +++ b/docs/guides/kafka/gitops/topology.md @@ -1,10 +1,10 @@ --- -title: Topology +title: Topology Gitops menu: docs_{{ .version }}: identifier: kf-gitops-topology name: Topology - parent: kf-gitops-kafka + parent: kf-gitops weight: 20 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/mongodb/gitops/_index.md b/docs/guides/mongodb/gitops/_index.md new file mode 100644 index 0000000000..653e9e9e45 --- /dev/null +++ b/docs/guides/mongodb/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: MongoDB Gitops +menu: + docs_{{ .version }}: + identifier: mg-gitops-mongodb + name: Gitops + parent: mg-mongodb-guides + weight: 147 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/redis/gitops/_index.md b/docs/guides/redis/gitops/_index.md new file mode 100644 index 0000000000..1189753691 --- /dev/null +++ b/docs/guides/redis/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: Redis Gitops +menu: + docs_{{ .version }}: + identifier: rd-gitops + name: Gitops + parent: rd-redis-guides + weight: 170 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/redis/gitops/gitops.md b/docs/guides/redis/gitops/gitops.md new file mode 100644 index 0000000000..dbb3def2db --- /dev/null +++ b/docs/guides/redis/gitops/gitops.md @@ -0,0 +1,670 @@ +--- +title: Redis GitOps Guides +menu: + docs_{{ .version }}: + identifier: rd-gitops-guides + name: Gitops Redis + parent: rd-gitops + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Redis using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create Redis database and manage updates using GitOps worrdlow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/Redis](/docs/examples/redis) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create Redis Database using GitOps + +### Create a Redis GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 2 + storageType: Durable + storage: + resources: + requests: + storage: "1Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + deletionPolicy: WipeOut +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── Redis.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is created in your cluster. + +Our `gitops` operator will create an actual `Redis` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get redis.gitops.kubedb.com,redis.kubedb.com -n demo +NAME AGE +redis.gitops.kubedb.com/rd-gitops 8m37s + +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 8m37s +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` Redis. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=rd-gitops' +NAME AGE +petset.apps.k8s.appscode.com/rd-gitops-shard0 8m58s +petset.apps.k8s.appscode.com/rd-gitops-shard1 8m55s +petset.apps.k8s.appscode.com/rd-gitops-shard2 8m52s + +NAME READY STATUS RESTARTS AGE +pod/rd-gitops-shard0-0 1/1 Running 0 8m57s +pod/rd-gitops-shard0-1 1/1 Running 0 7m52s +pod/rd-gitops-shard1-0 1/1 Running 0 8m54s +pod/rd-gitops-shard1-1 1/1 Running 0 7m52s +pod/rd-gitops-shard2-0 1/1 Running 0 8m52s +pod/rd-gitops-shard2-1 1/1 Running 0 7m52s + +NAME TYPE DATA AGE +secret/rd-gitops-9aa2fa Opaque 1 9m4s +secret/rd-gitops-auth kubernetes.io/basic-auth 2 9m4s + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/rd-gitops ClusterIP 10.43.90.210 6379/TCP 9m +service/rd-gitops-pods ClusterIP None 6379/TCP,16379/TCP 9m4s + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/rd-gitops kubedb.com/redis 8.0.4 8m53s +``` + +## Update Redis Database using GitOps + +### Scale Redis Replicas + + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + storage: + resources: + requests: + storage: "1Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + deletionPolicy: WipeOut + ``` +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` RedisOpsRequest to update the `Redis` database replicas. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 19m + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 19m + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-4ecw03 HorizontalScaling Successful 4m2s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=rd-gitops' +NAME READY STATUS RESTARTS AGE +rd-gitops-shard0-0 1/1 Running 0 20m +rd-gitops-shard0-1 1/1 Running 0 19m +rd-gitops-shard0-2 1/1 Running 0 4m26s +rd-gitops-shard1-0 1/1 Running 0 20m +rd-gitops-shard1-1 1/1 Running 0 19m +rd-gitops-shard1-2 1/1 Running 0 4m6s +rd-gitops-shard2-0 1/1 Running 0 20m +rd-gitops-shard2-1 1/1 Running 0 19m +rd-gitops-shard2-2 1/1 Running 0 3m46s +``` + +We can also scale down the replicas by updating the `replicas` fields. + +### Scale Redis Database Resources + +before Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo rd-gitops-shard0-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1Gi" + }, + "requests": { + "cpu": "500m", + "memory": "1Gi" + } +} +``` + + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + storage: + resources: + requests: + storage: "1Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + deletionPolicy: WipeOut + podTemplate: + spec: + containers: + - name: redis + resources: + requests: + memory: "1.5Gi" + cpu: "1000m" + limits: + memory: "1.5Gi" + cpu: "1000m" +``` + + +Resource Requests and Limits are updated to `1000m` CPU and `1.5Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `RedisOpsRequest` to update the `Redis` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 17h + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 17h + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-ule15j HorizontalScaling Successful 16h +redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-lliwo8 VerticalScaling Successful 16h +``` + +```bash +$ kubectl get pod -n demo rd-gitops-shard0-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "1", + "memory": "1536Mi" + }, + "requests": { + "cpu": "1", + "memory": "1536Mi" + } +} +``` + + +### Expand Redis Volume + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + storage: + resources: + requests: + storage: "2Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + deletionPolicy: WipeOut + podTemplate: + spec: + containers: + - name: redis + resources: + requests: + memory: "1.5Gi" + cpu: "1000m" + limits: + memory: "1.5Gi" + cpu: "1000m" +``` + +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` RedisOpsRequest to update the `Redis` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 8.0.4 Ready 39m + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 39m + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-4ecw03 HorizontalScaling Successful 24m +redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-r0oosa VerticalScaling Successful 17m +redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-0ubdaw VolumeExpansion Successful 7m31s +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=rd-gitops' +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +data-rd-gitops-shard0-0 Bound pvc-97afbd7c-5887-4381-bef8-4584411b4ed5 2Gi RWO longhorn 39m +data-rd-gitops-shard0-1 Bound pvc-461c6122-94ba-4b96-805b-1bf2619a10d4 2Gi RWO longhorn 38m +data-rd-gitops-shard0-2 Bound pvc-90fc4131-a272-44bd-bfa2-3ffc5c093178 2Gi RWO longhorn 24m +data-rd-gitops-shard1-0 Bound pvc-38855b1c-4e1f-485f-93c5-5848eed1465d 2Gi RWO longhorn 39m +data-rd-gitops-shard1-1 Bound pvc-14b89fe8-8681-4aba-af37-035da020c3cb 2Gi RWO longhorn 38m +data-rd-gitops-shard1-2 Bound pvc-6d3d1e55-689e-4884-a3cc-ed6080e48cf0 2Gi RWO longhorn 23m +data-rd-gitops-shard2-0 Bound pvc-e6b9fa56-40b2-45aa-8ebd-ab360522a294 2Gi RWO longhorn 39m +data-rd-gitops-shard2-1 Bound pvc-6fdfd395-d2b8-45df-8369-f9897e3d678c 2Gi RWO longhorn 38m +data-rd-gitops-shard2-2 Bound pvc-1570c37b-63da-456c-af59-b60ed544e651 2Gi RWO longhorn 23m +``` + + +### Update Version + +List Redis versions using `kubectl get Redisversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/redis/update-version/update-version.md). + +Let's choose `7.4.1` in this example. + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 7.4.1 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + storage: + resources: + requests: + storage: "2Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + deletionPolicy: WipeOut + podTemplate: + spec: + containers: + - name: redis + resources: + requests: + memory: "1.5Gi" + cpu: "1000m" + limits: + memory: "1.5Gi" + cpu: "1000m" +``` + +Update the `version` field to `7.4.1`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` RedisOpsRequest to update the `Redis` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 7.4.1 Ready 21m + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 21m + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-4ecw03 HorizontalScaling Successful 144m +redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-wbsjct UpdateVersion Successful 12m +redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-r0oosa VerticalScaling Successful 137m +redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-0ubdaw VolumeExpansion Successful 127m +``` +## Reconfigure Redis + + +At first, we will create `redis.conf` file containing required configuration settings. + +```ini +$ cat redis.conf +maxclients 2000 +``` +Here, `maxclients` is set to `500`, whereas the default value is `10000`. + +Now, we will create a secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo rd-custom-config --from-file=./redis.conf +secret/rd-custom-config created +``` + +Now, we will create a secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo mg-custom-config --from-file=./mongod.conf +secret/mg-custom-config created +``` + + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 7.4.1 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + configuration: + secretName: rd-custom-config + storage: + resources: + requests: + storage: "2Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + deletionPolicy: WipeOut + podTemplate: + spec: + containers: + - name: redis + resources: + requests: + memory: "1.5Gi" + cpu: "1000m" + limits: + memory: "1.5Gi" + cpu: "1000m" +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` RedisOpsRequest to update the `Redis` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 7.4.1 Ready 51m + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 51m + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-4ecw03 HorizontalScaling Successful 3h42m +redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-uc97bo Reconfigure Successful 37m +redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-wbsjct UpdateVersion Successful 91m +redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-r0oosa VerticalScaling Successful 3h35m +redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-0ubdaw VolumeExpansion Successful 3h26m +``` + +We can also reconfigure the parameters creating another secret and reference the secret in the `configuration.secretName` field. Also you can remove the `configuration.secretName` field to use the default parameters. + + + +### Rotate Redis Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will create a secret named `rd-rotate-auth ` with the following content, + +```bash +$ kubectl create secret generic rd-rotate-auth -n demo \ + --type=kubernetes.io/basic-auth \ + --from-literal=username=redis \ + --from-literal=password=redis-secret +secret/rd-rotate-auth created +``` + + + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 8.0.4 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + authSecret: + kind: Secret + name: rd-rotate-auth + configuration: + secretName: rd-new-configuration + storage: + resources: + requests: + storage: "2Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + podTemplate: + spec: + containers: + - name: redis + resources: + requests: + memory: "500Mi" + cpu: "500m" + limits: + memory: "500Mi" + cpu: "500m" + deletionPolicy: WipeOut +``` + +Change the `authSecret` field to `rd-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` RedisOpsRequest to update the `Redis` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 7.4.1 Ready 77m + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 77m + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-4ecw03 HorizontalScaling Successful 4h9m +redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-uc97bo Reconfigure Successful 63m +redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-2l0psh RotateAuth Successful 22m +redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-wbsjct UpdateVersion Successful 117m +redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-r0oosa VerticalScaling Successful 4h2m +redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-0ubdaw VolumeExpansion Successful 3h52m +``` +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `Redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 7.4.1 + mode: Cluster + cluster: + shards: 3 + replicas: 3 + storageType: Durable + authSecret: + kind: Secret + name: rd-rotate-auth + configuration: + secretName: rd-custom-config + # tls: + # issuerRef: + # apiGroup: "cert-manager.io" + # kind: Issuer + # name: redis-ca-issuer + storage: + resources: + requests: + storage: "2Gi" + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + deletionPolicy: WipeOut + podTemplate: + spec: + containers: + - name: redis + resources: + requests: + memory: "1.5Gi" + cpu: "1000m" + limits: + memory: "1.5Gi" + cpu: "1000m" + monitor: + agent: prometheus.io/operator + prometheus: + serviceMonitor: + labels: + release: prometheus + interval: 10s +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Redis` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` RedisOpsRequest to add the `Redis` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 7.4.1 Ready 117m + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 117m + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-horizontalscaling-4ecw03 HorizontalScaling Successful 4h48m +redisopsrequest.ops.kubedb.com/rd-gitops-reconfigure-uc97bo Reconfigure Successful 103m +redisopsrequest.ops.kubedb.com/rd-gitops-restart-pj9zrj Restart Successful 8m56s +redisopsrequest.ops.kubedb.com/rd-gitops-rotate-auth-2l0psh RotateAuth Successful 62m +redisopsrequest.ops.kubedb.com/rd-gitops-versionupdate-wbsjct UpdateVersion Successful 157m +redisopsrequest.ops.kubedb.com/rd-gitops-verticalscaling-r0oosa VerticalScaling Successful 4h41m +redisopsrequest.ops.kubedb.com/rd-gitops-volumeexpansion-0ubdaw VolumeExpansion Successful 4h32m +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + +## Next Steps + + +- Learn Redis Scaling + - [Horizontal Scaling](/docs/guides/redis/scaling/horizontal-scaling/cluster.md) + - [Vertical Scaling](/docs/guides/redis/scaling/horizontal-scaling/cluster.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/redis/update-version/cluster.md) +- Monitor your RedisQL database with KubeDB using [built-in Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/redis/gitops/overview.md b/docs/guides/redis/gitops/overview.md new file mode 100644 index 0000000000..7b5ed3a7c8 --- /dev/null +++ b/docs/guides/redis/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: Redis Gitops Overview +description: Redis Gitops Overview +menu: + docs_{{ .version }}: + identifier: rd-gitops-overview + name: Overview + parent: rd-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for Redis + +This guide will give you an overview of how KubeDB `gitops` operator works with Redis databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Redis databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [Redis](/docs/guides/redis/concepts/redis.md) + - [KafkaOpsRequest](/docs/guides/redis/concepts/redisopsrequest.md) + + + +## Workflow GitOps with Redis + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + + +
+ + GitOps Flow + +
Fig: GitOps process of Redis
+ +
+ +1. **Define GitOps Redis**: Create Custom Resource (CR) of kind `Redis` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Redis CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the KafkaGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing Redis databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running Redis using GitOps. From 38cfd56425f7d32cb79cf5cf29d3c0d057e8c0da Mon Sep 17 00:00:00 2001 From: Bonusree Date: Mon, 27 Apr 2026 12:38:08 +0600 Subject: [PATCH 31/51] es Signed-off-by: Bonusree --- docs/guides/elasticsearch/gitops/_index.md | 10 + docs/guides/elasticsearch/gitops/gitops.md | 651 +++++++++++++++++++ docs/guides/elasticsearch/gitops/overview.md | 50 ++ docs/guides/kafka/gitops/topology.md | 2 +- docs/guides/mariadb/gitops/gitops.md | 2 + docs/guides/redis/gitops/gitops.md | 5 +- 6 files changed, 717 insertions(+), 3 deletions(-) create mode 100644 docs/guides/elasticsearch/gitops/_index.md create mode 100644 docs/guides/elasticsearch/gitops/gitops.md create mode 100644 docs/guides/elasticsearch/gitops/overview.md diff --git a/docs/guides/elasticsearch/gitops/_index.md b/docs/guides/elasticsearch/gitops/_index.md new file mode 100644 index 0000000000..6048eb2505 --- /dev/null +++ b/docs/guides/elasticsearch/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: Elasticsearch Gitops +menu: + docs_{{ .version }}: + identifier: es-gitops + name: Elasticsearch Gitops + parent: es-elasticsearch-guides + weight: 170 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/elasticsearch/gitops/gitops.md b/docs/guides/elasticsearch/gitops/gitops.md new file mode 100644 index 0000000000..e8f92ea478 --- /dev/null +++ b/docs/guides/elasticsearch/gitops/gitops.md @@ -0,0 +1,651 @@ +--- +title: Elasticsearch Gitops Overview +description: Elasticsearch Gitops Overview +menu: + docs_{{ .version }}: + identifier: es-gitops-overview + name: Overview + parent: es-gitops + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + + + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Elasticsearch using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create Elasticsearch database and manage updates using GitOps woreslow. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, +you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install `KubeDB` operator in your cluster following the steps [here](/docs/setup/README.md). Pass `--set kubedb-crd-manager.installGitOpsCRDs=true` in the kubedb installation +process to enable `GitOps` operator. + +- You need to install GitOps tools like `ArgoCD` or `FluxCD` and configure with your Git Repository to monitor the Git repository and synchronize the state of the Kubernetes +cluster with the desired state defined in Git. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` +> Note: YAML files used in this tutorial are stored in [docs/examples/elasticsearch](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/elasticsearch) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +We are going to use `ArgoCD` in this tutorial. You can install `ArgoCD` in your cluster by following the steps [here](https://argo-cd.readthedocs.io/en/stable/getting_started/). Also, you need to install `argocd` CLI in your local machine. You can install `argocd` CLI by following the steps [here](https://argo-cd.readthedocs.io/en/stable/cli_installation/). + +## Creating Apps via CLI + +### For Public Repository +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace +``` + +### For Private Repository +#### Using HTTPS +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --username --password +``` + +#### Using SSH +```bash +argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +``` + +## Create Elasticsearch Database using GitOps + +### Create a Elasticsearch GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.2.3 + enableSSL: false + replicas: 2 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Create a directory like below, +```bash +$ tree . +├── kubedb + └── Elasticsearch.yaml +1 directories, 1 files +``` + +Now commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is created in your cluster. + +Our `gitops` operator will create an actual `Elasticsearch` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get Elasticsearch.gitops.kubedb.com,Elasticsearch.kubedb.com -n demo +NAME AGE +elasticsearch.gitops.kubedb.com/es-gitops 20m + +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 20m +``` + +List the resources created by `kubedb` operator created for `kubedb.com/v1` Elasticsearch. + +```bash +$ kubectl get petset,pod,secret,service,appbinding -n demo -l 'app.kubernetes.io/instance=es-gitops' +NAME AGE +petset.apps.k8s.appscode.com/es-gitops 20m + +NAME READY STATUS RESTARTS AGE +pod/es-gitops-0 1/1 Running 0 20m +pod/es-gitops-1 1/1 Running 0 19m + +NAME TYPE DATA AGE +secret/es-gitops-a1d7d4 Opaque 1 13m +secret/es-gitops-apm-system-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-auth kubernetes.io/basic-auth 2 20m +secret/es-gitops-beats-system-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-ca-cert kubernetes.io/tls 2 20m +secret/es-gitops-client-cert kubernetes.io/tls 3 20m +secret/es-gitops-config Opaque 1 20m +secret/es-gitops-http-cert kubernetes.io/tls 3 20m +secret/es-gitops-kibana-system-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-logstash-system-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-remote-monitoring-user-cred kubernetes.io/basic-auth 2 20m +secret/es-gitops-transport-cert kubernetes.io/tls 3 20m + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/es-gitops ClusterIP 10.43.235.79 9200/TCP 20m +service/es-gitops-master ClusterIP None 9300/TCP 20m +service/es-gitops-pods ClusterIP None 9200/TCP 20m + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/es-gitops kubedb.com/elasticsearch 8.2.3 20m +``` + +## Update Elasticsearch Database using GitOps +### Scale Elasticsearch Replicas +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.2.3 + enableSSL: true + replicas: 3 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Update the `replicas` to `3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` ElasticsearchOpsRequest to update the `Elasticsearch` database replicas. List the +resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 64m + +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-32p116 HorizontalScaling Successful 39m +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the number of pods, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=es-gitops' +NAME READY STATUS RESTARTS AGE +es-gitops-0 1/1 Running 0 36m +es-gitops-1 1/1 Running 0 16m +es-gitops-2 1/1 Running 0 15m +``` + + +We can also scale down the replicas by updating the `replicas` fields. +### Scale Elasticsearch Database Resources + +Before scaling database resouces: +```bash +kubectl get pod -n demo es-gitops-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +``` + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.2.3 + enableSSL: false + replicas: 3 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 1000m + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + + ``` + +Resource Requests and Limits are updated to `1000m` CPU and `2Gi` Memory. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the resource changes and create a `ElasticsearchOpsRequest` to update the `Elasticsearch` database. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 64m + +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-injx1l HorizontalScaling Successful 15m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-x5mfy0 VerticalScaling Successful 39m + +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +```bash +$ kubectl get pod -n demo es-gitops-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "1", + "memory": "2Gi" + }, + "requests": { + "cpu": "1", + "memory": "2Gi" + } +} +``` + + +### Expand Elasticsearch Volume + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.2.3 + enableSSL: false + replicas: 3 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 1000m + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi +``` + +Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` ElasticsearchOpsRequest to update the `Elasticsearch` database volume. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 3h1m + +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-32p116 HorizontalScaling Successful 157m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-x5mfy0 VerticalScaling Successful 157m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-sata37 VolumeExpansion Successful 38m +``` + +After Ops Request becomes `Successful`, We can validate the changes by checking the pvc size, +```bash +$ kubectl get pod -n demo -l 'app.kubernetes.io/instance=es-gitops' +NAME READY STATUS RESTARTS AGE +es-gitops-0 1/1 Running 0 36m +es-gitops-1 1/1 Running 0 16m +es-gitops-2 1/1 Running 0 15m +``` + +## Reconfigure Elasticsearch + +At first, we will create a secret containing `user.conf` file with required configuration settings. +To know more about this configuration file, check [here](/docs/guides/elasticsearch/configuration/combined-cluster/index.md) +```yaml +apiVersion: v1 +stringData: + user.conf: | + max_connections=200 + shared_buffers=256MB +kind: Secret +metadata: + name: es-configuration + namespace: demo +type: Opaque +``` + +Now, we will add this file to `kubedb /es-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── es-configuration.yaml +│ └── Elasticsearch.yaml +1 directories, 2 files +``` + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.2.3 + enableSSL: true + replicas: 3 + configuration: + secretName: es-configuration + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 500m + memory: 1Gi + requests: + cpu: 100m + memory: 1Gi + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` ElasticsearchOpsRequest to update the `Elasticsearch` database configuration. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 3h53m + +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-32p116 HorizontalScaling Successful 3h29m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-wj5qyx Reconfigure Successful 3m42s +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-lvh38k VerticalScaling Successful 99m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-sata37 VolumeExpansion Successful 90m +``` + + + +### Rotate Elasticsearch Auth + +To do that, create a `kubernetes.io/basic-auth` type k8s secret with the new username and password. + +We will generate a secret named `es-rotate-auth` with the following content, + +```bash +$ kubectl create secret generic es-rotate-auth -n demo \ + --type=kubernetes.io/basic-auth \ + --from-literal=username=elastic \ + --from-literal=password=elasticsearch-secret +secret/es-rotate-auth created + +``` + + + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.2.3 + enableSSL: true + replicas: 3 + authSecret: + kind: Secret + name: es-rotate-auth + configuration: + secretName: es-configuration + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 500m + memory: 1Gi + requests: + cpu: 100m + memory: 1Gi + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut +``` + +Change the `authSecret` field to `es-rotate-auth`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the auth changes and create a `RotateAuth` ElasticsearchOpsRequest to update the `Elasticsearch` database auth. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get es,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.2.3 Ready 32m + +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-kn71nl HorizontalScaling Successful 28m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-x7ou3f Reconfigure Successful 7m24s +elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-8cgx3b RotateAuth Successful 2m34s +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-wyjx4l VerticalScaling Successful 21m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-z2e3qb VolumeExpansion Successful 17m +``` +### Update Version + +List Elasticsearch versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/elasticsearch/update-version/update-version.md). + +Let's choose `xpack-8.5.3` in this example. + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.5.3 + enableSSL: false + replicas: 3 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut + configuration: + secretName: es-configuration + authSecret: + kind: Secret + name: es-rotate-auth + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 1000m + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi +``` + +Update the `version` field to `xpack-8.5.3`. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Elasticsearch` database version. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get es,Elasticsearch,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.5.3 Ready 54m + +NAME AGE +elasticsearch.gitops.kubedb.com/es-gitops 54m + +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-kn71nl HorizontalScaling Successful 50m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-x7ou3f Reconfigure Successful 29m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-8cgx3b RotateAuth Successful 25m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-versionupdate-z92dz0 UpdateVersion Successful 17m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-wyjx4l VerticalScaling Successful 44m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-z2e3qb VolumeExpansion Successful 39m +``` + + +Now, we are going to verify whether the `Elasticsearch`, `PetSet` and it's `Pod` have updated with new image. Let's check, + +```bash +$ kubectl get Elasticsearch -n demo es-gitops -o=jsonpath='{.spec.version}{"\n"}' +xpack-8.5.3 +$ kubectl get petset -n demo es-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/elastic:8.5.3@sha256:705db3750fa6739ddf06e416b52788446b19f79b6b162c0238078790545898d0 +$ kubectl get pod -n demo es-gitops-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +ghcr.io/appscode-images/elastic:8.5.3@sha256:705db3750fa6739ddf06e416b52788446b19f79b6b162c0238078790545898d0 +``` + + + +### Enable Monitoring + +If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.5.3 + enableSSL: false + replicas: 3 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut + configuration: + secretName: es-configuration + authSecret: + kind: Secret + name: es-rotate-auth + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 1000m + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + monitor: + agent: prometheus.io/operator + prometheus: + serviceMonitor: + labels: + release: prometheus + interval: 10s +``` + +Add `monitor` field in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Elasticsearch` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. +```bash +$ kubectl get es,Elasticsearch,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.5.3 Ready 66m + +NAME AGE +elasticsearch.gitops.kubedb.com/es-gitops 66m + +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-kn71nl HorizontalScaling Successful 61m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-x7ou3f Reconfigure Successful 40m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-restart-sd2424 Restart Successful 4m10s +elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-8cgx3b RotateAuth Successful 36m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-versionupdate-z92dz0 UpdateVersion Successful 28m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-wyjx4l VerticalScaling Successful 55m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-z2e3qb VolumeExpansion Successful 50m +``` + +Verify the monitoring is enabled by checking the prometheus targets. + +There are some other fields that will trigger `Restart` ops request. +- `.spec.monitor` +- `.spec.spec.archiver` +- `.spec.remoteReplica` +- `spec.replication` +- `.spec.standbyMode` +- `.spec.streamingMode` +- `.spec.enforceGroup` +- `.spec.sslMode` etc. + + + +## Next Steps + +- Learn Elasticsearch Scaling + - [Horizontal Scaling](/docs/guides/elasticsearch/scaling/horizontal/combined.md) + - [Vertical Scaling](/docs/guides/elasticsearch/scaling/vertical/combined.md) +- Learn Version Update Ops Request and Constraints [here](/docs/guides/elasticsearch/update-version/elasticsearch.md) +- Monitor your ElasticsearchQL database with KubeDB using [built-in Prometheus](/docs/guides/elasticsearch/monitoring/using-builtin-prometheus.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md) \ No newline at end of file diff --git a/docs/guides/elasticsearch/gitops/overview.md b/docs/guides/elasticsearch/gitops/overview.md new file mode 100644 index 0000000000..bfa01c2fff --- /dev/null +++ b/docs/guides/elasticsearch/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: Elasticsearch Gitops Overview +description: Elasticsearch Gitops Overview +menu: + docs_{{ .version }}: + identifier: es-gitops-overview + name: Overview + parent: es-gitops + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Overview for Elasticsearch + +This guide will give you an overview of how KubeDB `gitops` operator works with Elasticsearch databases using the `gitops.kubedb.com/v1alpha1` API. It will help you understand the GitOps workflow for +managing Elasticsearch databases in Kubernetes. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [Elasticsearch](/docs/guides/elasticsearch/concepts/elasticsearch/index.md) + - [ElasticsearchOpsRequest](/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md) + + + +## Workflow GitOps with Elasticsearch + +The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version. + + +
+ + GitOps Flow + +
Fig: GitOps process of Elasticsearch
+ +
+ +1. **Define GitOps Elasticsearch**: Create Custom Resource (CR) of kind `Elasticsearch` using the `gitops.kubedb.com/v1alpha1` API. +2. **Store in Git**: Push the CR to a Git repository. +3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. +4. **Create Database**: The GitOps operator creates a corresponding KubeDB Elasticsearch CR in the Kubernetes cluster to deploy the database. +5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. + +This flow makes managing Elasticsearch databases efficient, reliable, and fully integrated with GitOps practices. + +In the next doc, we are going to show a step by step guide on running Elasticsearch using GitOps. diff --git a/docs/guides/kafka/gitops/topology.md b/docs/guides/kafka/gitops/topology.md index 74c8863955..c0c0717b79 100644 --- a/docs/guides/kafka/gitops/topology.md +++ b/docs/guides/kafka/gitops/topology.md @@ -3,7 +3,7 @@ title: Topology Gitops menu: docs_{{ .version }}: identifier: kf-gitops-topology - name: Topology + name: Kafka Gitops parent: kf-gitops weight: 20 menu_name: docs_{{ .version }} diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index 18a3221ceb..45f1f66166 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -128,6 +128,8 @@ appbinding.appcatalog.appscode.com/mariadb-gitops kubedb.com/mariadb 11.8.5 ### Scale MariaDB Database Resources +Before scaling database resouces: + ```shell $ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[0].resources' { diff --git a/docs/guides/redis/gitops/gitops.md b/docs/guides/redis/gitops/gitops.md index dbb3def2db..afde2b9b2f 100644 --- a/docs/guides/redis/gitops/gitops.md +++ b/docs/guides/redis/gitops/gitops.md @@ -193,7 +193,8 @@ We can also scale down the replicas by updating the `replicas` fields. ### Scale Redis Database Resources -before Ops Request becomes `Successful`, We can validate the changes by checking the one of the pod, +Before the Ops Request reaches the `Successful` state, the configured memory limits are as follows: + ```bash $ kubectl get pod -n demo rd-gitops-shard0-0 -o json | jq '.spec.containers[0].resources' { @@ -349,7 +350,7 @@ data-rd-gitops-shard2-2 Bound pvc-1570c37b-63da-456c-af59-b60ed544e651 2G ### Update Version -List Redis versions using `kubectl get Redisversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/redis/update-version/update-version.md). +List Redis versions using `kubectl get Redisversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/redis/update-version/cluster.md). Let's choose `7.4.1` in this example. From a69e8925308a9911eb65633b50372baacbd3e264 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Mon, 27 Apr 2026 13:21:46 +0600 Subject: [PATCH 32/51] link change Signed-off-by: Bonusree --- docs/guides/elasticsearch/gitops/gitops.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guides/elasticsearch/gitops/gitops.md b/docs/guides/elasticsearch/gitops/gitops.md index e8f92ea478..1df23c61d7 100644 --- a/docs/guides/elasticsearch/gitops/gitops.md +++ b/docs/guides/elasticsearch/gitops/gitops.md @@ -480,7 +480,7 @@ elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-z2e3qb Volu ``` ### Update Version -List Elasticsearch versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/elasticsearch/update-version/update-version.md). +List Elasticsearch versions using `kubectl get Elasticsearchversion` and choose desired version that is compatible for upgrade from current version. Check the version constraints and ops request [here](/docs/guides/elasticsearch/update-version/elasticsearch.md). Let's choose `xpack-8.5.3` in this example. From fd88cbc2a4eeb9569a2b6d2ce52a4adb3c4d434c Mon Sep 17 00:00:00 2001 From: Bonusree Date: Mon, 27 Apr 2026 17:43:43 +0600 Subject: [PATCH 33/51] review1 +es Signed-off-by: Bonusree --- docs/guides/elasticsearch/gitops/_index.md | 4 +- docs/guides/elasticsearch/gitops/gitops.md | 142 ++++++++++++++++++- docs/guides/elasticsearch/gitops/overview.md | 4 +- docs/guides/kafka/gitops/_index.md | 4 +- docs/guides/kafka/gitops/overview.md | 4 +- docs/guides/kafka/gitops/topology.md | 6 +- docs/guides/mariadb/gitops/_index.md | 4 +- docs/guides/mariadb/gitops/gitops.md | 6 +- docs/guides/mariadb/gitops/overview.md | 4 +- docs/guides/mongodb/gitops/_index.md | 4 +- docs/guides/mongodb/gitops/gitops.md | 6 +- docs/guides/mongodb/gitops/overview.md | 4 +- docs/guides/mssqlserver/gitops/_index.md | 4 +- docs/guides/mssqlserver/gitops/gitops.md | 76 +++++++--- docs/guides/mssqlserver/gitops/overview.md | 6 +- docs/guides/redis/gitops/_index.md | 4 +- docs/guides/redis/gitops/gitops.md | 2 +- docs/guides/redis/gitops/overview.md | 4 +- 18 files changed, 228 insertions(+), 60 deletions(-) diff --git a/docs/guides/elasticsearch/gitops/_index.md b/docs/guides/elasticsearch/gitops/_index.md index 6048eb2505..0e74d7193d 100644 --- a/docs/guides/elasticsearch/gitops/_index.md +++ b/docs/guides/elasticsearch/gitops/_index.md @@ -1,9 +1,9 @@ --- -title: Elasticsearch Gitops +title: Elasticsearch GitOps menu: docs_{{ .version }}: identifier: es-gitops - name: Elasticsearch Gitops + name: Elasticsearch GitOps parent: es-elasticsearch-guides weight: 170 menu_name: docs_{{ .version }} diff --git a/docs/guides/elasticsearch/gitops/gitops.md b/docs/guides/elasticsearch/gitops/gitops.md index 1df23c61d7..039eb96712 100644 --- a/docs/guides/elasticsearch/gitops/gitops.md +++ b/docs/guides/elasticsearch/gitops/gitops.md @@ -1,6 +1,6 @@ --- -title: Elasticsearch Gitops Overview -description: Elasticsearch Gitops Overview +title: Elasticsearch GitOps Overview +description: Elasticsearch GitOps Overview menu: docs_{{ .version }}: identifier: es-gitops-overview @@ -97,7 +97,7 @@ Our `gitops` operator will create an actual `Elasticsearch` database CR in the c ```bash -$ kubectl get Elasticsearch.gitops.kubedb.com,Elasticsearch.kubedb.com -n demo +$ kubectl get elasticsearch.gitops.kubedb.com,elasticsearch.kubedb.com -n demo NAME AGE elasticsearch.gitops.kubedb.com/es-gitops 20m @@ -527,7 +527,7 @@ Update the `version` field to `xpack-8.5.3`. Commit the changes and push to your Now, `gitops` operator will detect the version changes and create a `VersionUpdate` ElasticsearchOpsRequest to update the `Elasticsearch` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get es,Elasticsearch,esops -n demo +$ kubectl get es,elasticsearch,esops -n demo NAME VERSION STATUS AGE elasticsearch.kubedb.com/es-gitops xpack-8.5.3 Ready 54m @@ -610,7 +610,7 @@ Add `monitor` field in the spec. Commit the changes and push to your Git reposit Now, `gitops` operator will detect the monitoring changes and create a `Restart` ElasticsearchOpsRequest to add the `Elasticsearch` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get es,Elasticsearch,esops -n demo +$ kubectl get es,elasticsearch,esops -n demo NAME VERSION STATUS AGE elasticsearch.kubedb.com/es-gitops xpack-8.5.3 Ready 66m @@ -639,6 +639,138 @@ There are some other fields that will trigger `Restart` ops request. - `.spec.enforceGroup` - `.spec.sslMode` etc. +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +To add tls, we are going to create an example `Issuer` that will be used to enable SSL/TLS in Elasticsearch. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating a ca certificates using openssl. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +Generating a RSA private key +................+++++ +........................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls Elasticsearch-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/Elasticsearch-ca created +``` + +Now, Let's create an `Issuer` using the `Elasticsearch-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: es-issuer + namespace: demo +spec: + ca: + secretName: Elasticsearch-ca +``` + +Let's add that to our `kubedb /es-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── es-configuration.yaml +│ ├── es-issuer.yaml +│ └── Elasticsearch.yaml +1 directories, 3 files +``` + +Update the `Elasticsearch.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Elasticsearch +metadata: + name: es-gitops + namespace: demo +spec: + version: xpack-8.5.3 + tls: + issuerRef: + apiGroup: "cert-manager.io" + kind: Issuer + name: es-issuer + certificates: + - alias: http + subject: + organizations: + - kubedb.com + emailAddresses: + - abc@kubedb.com + enableSSL: true + replicas: 3 + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut + configuration: + secretName: es-configuration + authSecret: + kind: Secret + name: es-rotate-auth + podTemplate: + spec: + containers: + - name: elasticsearch + resources: + limits: + cpu: 1000m + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + monitor: + agent: prometheus.io/operator + prometheus: + serviceMonitor: + labels: + release: prometheus + interval: 10s +``` + +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Elasticsearch` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get es,elasticsearch,esops -n demo +NAME VERSION STATUS AGE +elasticsearch.kubedb.com/es-gitops xpack-8.5.3 Ready 66m + +NAME AGE +elasticsearch.gitops.kubedb.com/es-gitops 66m + +NAME TYPE STATUS AGE +elasticsearchopsrequest.ops.kubedb.com/es-gitops-horizontalscaling-kn71nl HorizontalScaling Successful 61m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfigure-x7ou3f Reconfigure Successful 40m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-restart-sd2424 Restart Successful 4m10s +elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-8cgx3b RotateAuth Successful 36m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-versionupdate-z92dz0 UpdateVersion Successful 28m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-wyjx4l VerticalScaling Successful 55m +elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-z2e3qb VolumeExpansion Successful 50m +Elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +``` + + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Elasticsearch. ## Next Steps diff --git a/docs/guides/elasticsearch/gitops/overview.md b/docs/guides/elasticsearch/gitops/overview.md index bfa01c2fff..233d51d1ca 100644 --- a/docs/guides/elasticsearch/gitops/overview.md +++ b/docs/guides/elasticsearch/gitops/overview.md @@ -1,6 +1,6 @@ --- -title: Elasticsearch Gitops Overview -description: Elasticsearch Gitops Overview +title: Elasticsearch GitOps Overview +description: Elasticsearch GitOps Overview menu: docs_{{ .version }}: identifier: es-gitops-overview diff --git a/docs/guides/kafka/gitops/_index.md b/docs/guides/kafka/gitops/_index.md index 234162a433..6beb0ba87a 100644 --- a/docs/guides/kafka/gitops/_index.md +++ b/docs/guides/kafka/gitops/_index.md @@ -1,9 +1,9 @@ --- -title: Gitops Kafka +title: GitOps Kafka menu: docs_{{ .version }}: identifier: kf-gitops - name: Gitops + name: GitOps parent: kf-kafka-guides weight: 130 menu_name: docs_{{ .version }} diff --git a/docs/guides/kafka/gitops/overview.md b/docs/guides/kafka/gitops/overview.md index cf959a479f..3bdefd3fed 100644 --- a/docs/guides/kafka/gitops/overview.md +++ b/docs/guides/kafka/gitops/overview.md @@ -1,6 +1,6 @@ --- -title: Kafka Gitops Overview -description: Kafka Gitops Overview +title: Kafka GitOps Overview +description: Kafka GitOps Overview menu: docs_{{ .version }}: identifier: kf-gitops-overview diff --git a/docs/guides/kafka/gitops/topology.md b/docs/guides/kafka/gitops/topology.md index c0c0717b79..cc0e774f38 100644 --- a/docs/guides/kafka/gitops/topology.md +++ b/docs/guides/kafka/gitops/topology.md @@ -1,9 +1,9 @@ --- -title: Topology Gitops +title: Topology GitOps menu: docs_{{ .version }}: identifier: kf-gitops-topology - name: Kafka Gitops + name: Kafka GitOps parent: kf-gitops weight: 20 menu_name: docs_{{ .version }} @@ -218,7 +218,7 @@ $ kubectl get pod -n demo Kafka-gitops-broker-0 -o json | jq '.spec.containers[0 "memory": "1536Mi" } } -banusree@bonusree-datta-PC ~> kubectl get pod -n demo Kafka-gitops-controller-0 -o json | jq '.spec.containers[0].resources' +$ kubectl get pod -n demo Kafka-gitops-controller-0 -o json | jq '.spec.containers[0].resources' { "limits": { "memory": "1540Mi" diff --git a/docs/guides/mariadb/gitops/_index.md b/docs/guides/mariadb/gitops/_index.md index 96d6c107ee..9a0a13cfd4 100644 --- a/docs/guides/mariadb/gitops/_index.md +++ b/docs/guides/mariadb/gitops/_index.md @@ -1,9 +1,9 @@ --- -title: Gitops MariaDB +title: GitOps MariaDB menu: docs_{{ .version }}: identifier: guides-mariadb-gitops - name: Gitops + name: GitOps parent: guides-mariadb weight: 170 menu_name: docs_{{ .version }} diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index 45f1f66166..832aa75edc 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -1,10 +1,10 @@ --- -title: MariaDB Gitops -description: MariaDB Gitops Overview +title: MariaDB GitOps +description: MariaDB GitOps Overview menu: docs_{{ .version }}: identifier: md-gitops - name: MariaDB Gitops + name: MariaDB GitOps parent: guides-mariadb-gitops weight: 20 menu_name: docs_{{ .version }} diff --git a/docs/guides/mariadb/gitops/overview.md b/docs/guides/mariadb/gitops/overview.md index f4d74f96d1..530fd42d89 100644 --- a/docs/guides/mariadb/gitops/overview.md +++ b/docs/guides/mariadb/gitops/overview.md @@ -1,6 +1,6 @@ --- -title: MariaDB Gitops Overview -description: MariaDB Gitops Overview +title: MariaDB GitOps Overview +description: MariaDB GitOps Overview menu: docs_{{ .version }}: identifier: md-gitops-overview diff --git a/docs/guides/mongodb/gitops/_index.md b/docs/guides/mongodb/gitops/_index.md index 653e9e9e45..262676332b 100644 --- a/docs/guides/mongodb/gitops/_index.md +++ b/docs/guides/mongodb/gitops/_index.md @@ -1,9 +1,9 @@ --- -title: MongoDB Gitops +title: MongoDB GitOps menu: docs_{{ .version }}: identifier: mg-gitops-mongodb - name: Gitops + name: GitOps parent: mg-mongodb-guides weight: 147 menu_name: docs_{{ .version }} diff --git a/docs/guides/mongodb/gitops/gitops.md b/docs/guides/mongodb/gitops/gitops.md index 552f686d69..dfa700e5be 100644 --- a/docs/guides/mongodb/gitops/gitops.md +++ b/docs/guides/mongodb/gitops/gitops.md @@ -1,10 +1,10 @@ --- -title: MongoDB Gitops -description: MongoDB Gitops +title: MongoDB GitOps +description: MongoDB GitOps menu: docs_{{ .version }}: identifier: mg-gitops - name: MongoDB Gitops + name: MongoDB GitOps parent: mg-gitops-mongodb weight: 10 menu_name: docs_{{ .version }} diff --git a/docs/guides/mongodb/gitops/overview.md b/docs/guides/mongodb/gitops/overview.md index cc9f14a7b4..f3af144f34 100644 --- a/docs/guides/mongodb/gitops/overview.md +++ b/docs/guides/mongodb/gitops/overview.md @@ -1,6 +1,6 @@ --- -title: MongoDB Gitops Overview -description: MongoDB Gitops Overview +title: MongoDB GitOps Overview +description: MongoDB GitOps Overview menu: docs_{{ .version }}: identifier: mg-gitops-overview diff --git a/docs/guides/mssqlserver/gitops/_index.md b/docs/guides/mssqlserver/gitops/_index.md index 41f601a279..d2c1fb589b 100644 --- a/docs/guides/mssqlserver/gitops/_index.md +++ b/docs/guides/mssqlserver/gitops/_index.md @@ -1,9 +1,9 @@ --- -title: Gitops Microsoft SQL Server +title: GitOps Microsoft SQL Server menu: docs_{{ .version }}: identifier: mssqlserver-gitops - name: Gitops + name: GitOps parent: guides-mssqlserver weight: 41 menu_name: docs_{{ .version }} diff --git a/docs/guides/mssqlserver/gitops/gitops.md b/docs/guides/mssqlserver/gitops/gitops.md index 599031d1a7..ad431ba5fe 100644 --- a/docs/guides/mssqlserver/gitops/gitops.md +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -1,10 +1,10 @@ --- -title: Mssqlserver Gitops -description: Mssqlserver Gitops +title: Mssqlserver GitOps +description: Mssqlserver GitOps menu: docs_{{ .version }}: identifier: mssql-gitops - name: MSSQL Gitops + name: GitOps MSSQLserver parent: mssqlserver-gitops weight: 10 menu_name: docs_{{ .version }} @@ -57,6 +57,42 @@ argocd app create kubedb --repo --path kubedb --dest-server https://k ``` ## Create Mssqlserver Database using GitOps +First, an issuer needs to be created, even if TLS is not enabled for SQL Server. The issuer will be used to configure the TLS-enabled Wal-G proxy server, which is required for the SQL Server backup and restore operations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/ag-cluster/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + +Now, we are going to deploy a `MSSQLServer` availability group with version `2022-cu12`. + ### Create a Mssqlserver GitOps CR ```yaml @@ -104,7 +140,7 @@ Create a directory like below, ```bash $ tree . ├── kubedb - └── Mssqlserver.yaml + └── mssqlserver.yaml 1 directories, 1 files ``` @@ -114,7 +150,7 @@ Our `gitops` operator will create an actual `Mssqlserver` database CR in the clu ```bash -$ kubectl get Mssqlserver.gitops.kubedb.com,Mssqlserver.kubedb.com -n demo +$ kubectl get mssqlserver.gitops.kubedb.com,mssqlserver.kubedb.com -n demo NAME AGE mssqlserver.gitops.kubedb.com/mssql-gitops 19h @@ -158,7 +194,7 @@ appbinding.appcatalog.appscode.com/mssql-gitops kubedb.com/mssqlserver 2022- ## Update Mssqlserver Database using GitOps ### Scale Mssqlserver Replicas -Update the `Mssqlserver.yaml` with the following, +Update the `mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer @@ -204,7 +240,7 @@ Scale down the `replicas` to `3`. Commit the changes and push to your Git reposi Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` mssqlserverOpsRequest to update the `Mssqlserver` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get ms,Mssqlserver,msops -n demo +$ kubectl get ms,mssqlserver,msops -n demo NAME VERSION STATUS AGE mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 19h @@ -242,7 +278,7 @@ $ kubectl get pod -n demo mssql-gitops-0 -o json | jq '.spec.containers[0].resou } } ``` -Update the `Mssqlserver.yaml` with the following, +Update the `mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer @@ -296,7 +332,7 @@ Resource Requests and Limits are updated to `2` CPU and `2Gi` Memory. Commit the Now, `gitops` operator will detect the resource changes and create a `mssqlserverOpsRequest` to update the `Mssqlserver` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get ms,Mssqlserver,msops -n demo +$ kubectl get ms,mssqlserver,msops -n demo NAME VERSION STATUS AGE mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 19h @@ -327,7 +363,7 @@ $ kubectl get pod -n demo mssql-gitops-0 -o json | jq '.spec.containers[0].resou ### Expand Mssqlserver Volume -Update the `Mssqlserver.yaml` with the following, +Update the `mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer @@ -381,7 +417,7 @@ Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` mssqlserverOpsRequest to update the `Mssqlserver` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get ms,Mssqlserver,msops -n demo +$ kubectl get ms,mssqlserver,msops -n demo NAME VERSION STATUS AGE mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 20h @@ -421,7 +457,7 @@ $ kubectl create secret generic -n demo ms-custom-config --from-file=./mssql.con secret/ms-custom-config created ``` -Update the `Mssqlserver.yaml` with `spec.configuration.secretName` as the following, +Update the `mssqlserver.yaml` with `spec.configuration.secretName` as the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer @@ -477,7 +513,7 @@ Commit the changes and push to your Git repository. Your repository is synced wi Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` mssqlserverOpsRequest to update the `Mssqlserver` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get ms,Mssqlserver,msops -n demo +$ kubectl get ms,mssqlserver,msops -n demo NAME VERSION STATUS AGE mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 20h @@ -507,7 +543,7 @@ $ kubectl create secret generic mssqlserver-quickstart-auth-user -n demo \ secret/mssqlserver-quickstart-auth-user created ``` -Update the `Mssqlserver.yaml` ading `authsecret` as the following, +Update the `mssqlserver.yaml` ading `authsecret` as the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer @@ -566,7 +602,7 @@ Add the `authSecret.kind` and `authSecret.name` field to `mssqlserver-auth`. Com Now, `gitops` operator will detect the auth changes and create a `RotateAuth` mssqlserverOpsRequest to update the `Mssqlserver` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get ms,Mssqlserver,msops -n demo +$ kubectl get ms,mssqlserver,msops -n demo NAME VERSION STATUS AGE mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 21h @@ -588,7 +624,7 @@ List Mssqlserver versions using `kubectl get msversion` and choose desired versi Let's choose `2022-cu22` in this example. -Update the `Mssqlserver.yaml` with the following, +Update the `mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer @@ -647,7 +683,7 @@ Update the `version` field to `2022-cu22`. Commit the changes and push to your G Now, `gitops` operator will detect the version changes and create a `VersionUpdate` mssqlserverOpsRequest to update the `Mssqlserver` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get ms,Mssqlserver,msops -n demo +$ kubectl get ms,mssqlserver,msops -n demo NAME VERSION STATUS AGE mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 22h @@ -667,7 +703,7 @@ mssqlserveropsrequest.ops.kubedb.com/mssql-gitops-volumeexpansion-rsa80j Vol Now, we are going to verify whether the `Mssqlserver`, `PetSet` and it's `Pod` have updated with new image. Let's check, ```bash -$ kubectl get Mssqlserver -n demo mssql-gitops -o=jsonpath='{.spec.version}{"\n"}' +$ kubectl get mssqlserver -n demo mssql-gitops -o=jsonpath='{.spec.version}{"\n"}' 2022-cu22 $ kubectl get petset -n demo mssql-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' @@ -681,7 +717,7 @@ mcr.microsoft.com/mssql/server:2022-CU22-ubuntu-22.04@sha256:db9a8fe3098b7e8bbde If you already don't have a Prometheus server running, deploy one following tutorial from [here](https://github.com/appscode/third-party-tools/blob/master/monitoring/prometheus/operator/README.md#deploy-prometheus-server). -Update the `Mssqlserver.yaml` with the following, +Update the `mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer @@ -788,7 +824,7 @@ There are some other fields that will trigger `Restart` ops request. ### TLS configuration -Update the `Mssqlserver.yaml` with the following, +Update the `mssqlserver.yaml` with the following, ```yaml apiVersion: gitops.kubedb.com/v1alpha1 kind: MSSQLServer diff --git a/docs/guides/mssqlserver/gitops/overview.md b/docs/guides/mssqlserver/gitops/overview.md index acd58ce477..e5be5d9be5 100644 --- a/docs/guides/mssqlserver/gitops/overview.md +++ b/docs/guides/mssqlserver/gitops/overview.md @@ -1,9 +1,9 @@ --- -title: Gitops overview Microsoft SQL Server +title: GitOps overview Microsoft SQL Server menu: docs_{{ .version }}: identifier: ms-overview - name: Overview + name: Gitops overview Microsoft SQL Server parent: mssqlserver-gitops weight: 10 menu_name: docs_{{ .version }} @@ -43,7 +43,7 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y 2. **Store in Git**: Push the CR to a Git repository. 3. **Automated Deployment**: Use a GitOps tool (like `ArgoCD` or `FluxCD`) to monitor the Git repository and synchronize the state of the Kubernetes cluster with the desired state defined in Git. 4. **Create Database**: The GitOps operator creates a corresponding KubeDB MSSQLServer CR in the Kubernetes cluster to deploy the database. -5. **Handle Updates**: When you update the ElasticsearchGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`. +5. **Handle Updates**: When you update the MSSqlGitOps CR, the operator generates an Ops Request to safely apply the update(e.g. `VerticalScaling`, `HorizontalScaling`, `VolumeExapnsion`, `Reconfigure`, `RotateAuth`, `ReconfigureTLS`, `VersionUpdate`, ans `Restart`). This flow makes managing MSSQLServer databases efficient, reliable, and fully integrated with GitOps practices. diff --git a/docs/guides/redis/gitops/_index.md b/docs/guides/redis/gitops/_index.md index 1189753691..8f0bca3244 100644 --- a/docs/guides/redis/gitops/_index.md +++ b/docs/guides/redis/gitops/_index.md @@ -1,9 +1,9 @@ --- -title: Redis Gitops +title: Redis GitOps menu: docs_{{ .version }}: identifier: rd-gitops - name: Gitops + name: GitOps parent: rd-redis-guides weight: 170 menu_name: docs_{{ .version }} diff --git a/docs/guides/redis/gitops/gitops.md b/docs/guides/redis/gitops/gitops.md index afde2b9b2f..16ffe098f1 100644 --- a/docs/guides/redis/gitops/gitops.md +++ b/docs/guides/redis/gitops/gitops.md @@ -3,7 +3,7 @@ title: Redis GitOps Guides menu: docs_{{ .version }}: identifier: rd-gitops-guides - name: Gitops Redis + name: GitOps Redis parent: rd-gitops weight: 20 menu_name: docs_{{ .version }} diff --git a/docs/guides/redis/gitops/overview.md b/docs/guides/redis/gitops/overview.md index 7b5ed3a7c8..e928f4f853 100644 --- a/docs/guides/redis/gitops/overview.md +++ b/docs/guides/redis/gitops/overview.md @@ -1,6 +1,6 @@ --- -title: Redis Gitops Overview -description: Redis Gitops Overview +title: Redis GitOps Overview +description: Redis GitOps Overview menu: docs_{{ .version }}: identifier: rd-gitops-overview From 2f8ac69b1a4b884b3090c0843d488e50fda13c14 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 28 Apr 2026 14:45:35 +0600 Subject: [PATCH 34/51] tls,standard Signed-off-by: Bonusree --- .../storage/cassandra-autoscale.yaml | 2 +- .../cassandra/volume-expansion/cassandra.yaml | 2 +- .../compute/clickhouse-autoscale.yaml | 2 +- .../storage/clickhouse-autoscale.yaml | 2 +- .../volume-expansion/clickhouse-cluster.yaml | 2 +- .../clickhouse-standalone.yaml | 2 +- .../hazelcast/autoscaler/hazelcast.yaml | 2 +- .../configuration/hazelcast-config.yaml | 2 +- .../volume-expansion/md-replication.yaml | 4 +- .../compute/mssqlserver-ag-cluster.yaml | 2 +- .../storage/mssqlserver-ag-cluster.yaml | 2 +- .../volume-expansion/mssql-standalone.yaml | 2 +- .../mssqlserver-ag-cluster.yaml | 2 +- .../mysql/migration/storage-migration.yaml | 2 +- .../postgres/migration/storage-migration.yaml | 2 +- docs/examples/solr/autoscaler/combined.yaml | 2 +- docs/examples/solr/autoscaler/topology.yaml | 6 +- .../solr/configuration/solr-combined.yaml | 2 +- .../solr/reconfigure/solr-combined.yaml | 2 +- .../zookeeper/monitoring/prom-zk.yaml | 2 +- .../autoscaler/storage/storage-autoscale.md | 32 ++-- .../cassandra/volume-expansion/topology.md | 30 ++-- .../autoscaler/compute/compute-autoscale.md | 2 +- .../autoscaler/storage/storage-autoscale.md | 40 ++--- .../clickhouse/volume-expansion/cluster.md | 36 ++--- docs/guides/druid/autoscaler/storage/guide.md | 22 +-- docs/guides/druid/volume-expansion/guide.md | 10 +- docs/guides/elasticsearch/gitops/gitops.md | 31 ++-- .../volume-expansion/combined.md | 4 +- .../guides/ferretdb/clustering/replication.md | 12 +- .../autoscaler/compute/hazelcast-compute.md | 2 +- .../autoscaler/storage/hazelcast-storage.md | 6 +- docs/guides/hazelcast/concepts/appbinding.md | 2 +- docs/guides/hazelcast/concepts/hazelcast.md | 4 +- .../configuration/hazelcast-config.md | 2 +- .../autoscaler/storage/kafka-combined.md | 8 +- .../autoscaler/storage/kafka-topology.md | 16 +- docs/guides/kafka/gitops/topology.md | 2 +- docs/guides/mariadb/gitops/gitops.md | 6 +- docs/guides/mariadb/pitr/nfs/index.md | 32 ++-- .../mariadb/pitr/nfs/yamls/mariadb.yaml | 2 +- .../pitr/nfs/yamls/mariadbarchiver.yaml | 2 +- .../pitr/nfs/yamls/mariadbrestore.yaml | 2 +- .../pitr/nfs/yamls/voluemsnapshotclass.yaml | 4 +- docs/guides/mariadb/pitr/overview/index.md | 20 +-- .../mariadb/pitr/overview/yamls/mariadb.yaml | 2 +- .../pitr/overview/yamls/mariadbarchiver.yaml | 2 +- .../pitr/overview/yamls/mariadbrestore.yaml | 2 +- .../overview/yamls/voluemsnapshotclass.yaml | 4 +- .../mariadb/volume-expansion/maxscale.md | 36 ++--- docs/guides/mongodb/gitops/gitops.md | 138 +++++++++++++++++- docs/guides/mongodb/pitr/pitr.md | 12 +- .../mssqlserver/autoscaler/compute/cluster.md | 2 +- .../mssqlserver/autoscaler/storage/cluster.md | 26 ++-- .../volume-expansion/ag_cluster.md | 22 +-- .../volume-expansion/standalone.md | 14 +- .../mysql/migration/storageMigration.md | 18 +-- .../mysql/pitr/volumesnapshot/archiver.md | 22 +-- .../volumesnapshot/yamls/mysql-restore.yaml | 2 +- .../pitr/volumesnapshot/yamls/mysql.yaml | 2 +- .../volumesnapshot/yamls/mysqlarchiver.yaml | 2 +- .../yamls/voluemsnapshotclass.yaml | 4 +- .../postgres/migration/storageMigration.md | 18 +-- docs/guides/postgres/pitr/archiver.md | 20 +-- .../postgres/pitr/yamls/postgresarchiver.yaml | 2 +- .../pitr/yamls/voluemsnapshotclass.yaml | 4 +- docs/guides/redis/gitops/gitops.md | 135 ++++++++++++++--- .../configuration/podtemplating/index.md | 10 +- .../yamls/sdb-custom-sidecar.yaml | 4 +- .../yamls/sdb-node-selector.yaml | 2 +- .../yamls/sdb-with-tolerations.yaml | 2 +- .../yamls/sdb-without-tolerations.yaml | 2 +- docs/guides/singlestore/restart/restart.md | 4 +- .../singlestore/restart/yamls/sdb-sample.yaml | 4 +- .../cluster/example/sample-sdb.yaml | 4 +- .../horizontal-scaling/cluster/index.md | 4 +- .../cluster/example/sample-sdb.yaml | 4 +- .../scaling/vertical-scaling/cluster/index.md | 4 +- .../examples/sample-sdb.yaml | 4 +- .../sdb update-version opsrequest/index.md | 4 +- .../example/sample-sdb.yaml | 4 +- .../sdb volume-expansion opsrequest/index.md | 24 +-- .../solr/autoscaler/compute/topology.md | 6 +- .../solr/autoscaler/storage/combined.md | 20 +-- .../solr/autoscaler/storage/topology.md | 34 ++--- docs/guides/solr/configuration/config-file.md | 2 +- docs/guides/solr/reconfigure/solr.md | 2 +- docs/guides/solr/volume-expansion/combined.md | 8 +- docs/guides/solr/volume-expansion/topology.md | 12 +- .../monitoring/using-prometheus-operator.md | 2 +- .../volume-expansion/volume-expansion.md | 18 +-- 91 files changed, 636 insertions(+), 412 deletions(-) diff --git a/docs/examples/cassandra/autoscaling/storage/cassandra-autoscale.yaml b/docs/examples/cassandra/autoscaling/storage/cassandra-autoscale.yaml index dd95bdd2d6..62b2a46791 100644 --- a/docs/examples/cassandra/autoscaling/storage/cassandra-autoscale.yaml +++ b/docs/examples/cassandra/autoscaling/storage/cassandra-autoscale.yaml @@ -12,7 +12,7 @@ spec: replicas: 2 storage: storageClassName: - longhorn + standard accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/cassandra/volume-expansion/cassandra.yaml b/docs/examples/cassandra/volume-expansion/cassandra.yaml index 2af300935b..99b9ebadfe 100644 --- a/docs/examples/cassandra/volume-expansion/cassandra.yaml +++ b/docs/examples/cassandra/volume-expansion/cassandra.yaml @@ -11,7 +11,7 @@ spec: replicas: 2 storage: storageClassName: - longhorn + standard accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/clickhouse/autoscaling/compute/clickhouse-autoscale.yaml b/docs/examples/clickhouse/autoscaling/compute/clickhouse-autoscale.yaml index a5fde19554..54962946c9 100644 --- a/docs/examples/clickhouse/autoscaling/compute/clickhouse-autoscale.yaml +++ b/docs/examples/clickhouse/autoscaling/compute/clickhouse-autoscale.yaml @@ -39,7 +39,7 @@ spec: cpu: 500m memory: 1Gi storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/clickhouse/autoscaling/storage/clickhouse-autoscale.yaml b/docs/examples/clickhouse/autoscaling/storage/clickhouse-autoscale.yaml index a5fde19554..54962946c9 100644 --- a/docs/examples/clickhouse/autoscaling/storage/clickhouse-autoscale.yaml +++ b/docs/examples/clickhouse/autoscaling/storage/clickhouse-autoscale.yaml @@ -39,7 +39,7 @@ spec: cpu: 500m memory: 1Gi storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/clickhouse/volume-expansion/clickhouse-cluster.yaml b/docs/examples/clickhouse/volume-expansion/clickhouse-cluster.yaml index 96ebabb9bf..34a52439cd 100644 --- a/docs/examples/clickhouse/volume-expansion/clickhouse-cluster.yaml +++ b/docs/examples/clickhouse/volume-expansion/clickhouse-cluster.yaml @@ -39,7 +39,7 @@ spec: cpu: 500m memory: 1Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/clickhouse/volume-expansion/clickhouse-standalone.yaml b/docs/examples/clickhouse/volume-expansion/clickhouse-standalone.yaml index 3e4cc70865..c001db0599 100644 --- a/docs/examples/clickhouse/volume-expansion/clickhouse-standalone.yaml +++ b/docs/examples/clickhouse/volume-expansion/clickhouse-standalone.yaml @@ -7,7 +7,7 @@ spec: version: 24.4.1 replicas: 1 storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/hazelcast/autoscaler/hazelcast.yaml b/docs/examples/hazelcast/autoscaler/hazelcast.yaml index 05a4046701..18d31af14b 100644 --- a/docs/examples/hazelcast/autoscaler/hazelcast.yaml +++ b/docs/examples/hazelcast/autoscaler/hazelcast.yaml @@ -24,6 +24,6 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard storageType: Durable deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/hazelcast/configuration/hazelcast-config.yaml b/docs/examples/hazelcast/configuration/hazelcast-config.yaml index 6f8a79573c..7dcd303dfc 100644 --- a/docs/examples/hazelcast/configuration/hazelcast-config.yaml +++ b/docs/examples/hazelcast/configuration/hazelcast-config.yaml @@ -16,6 +16,6 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard storageType: Durable deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/mariadb/volume-expansion/md-replication.yaml b/docs/examples/mariadb/volume-expansion/md-replication.yaml index c7574abbe3..84c329c6be 100644 --- a/docs/examples/mariadb/volume-expansion/md-replication.yaml +++ b/docs/examples/mariadb/volume-expansion/md-replication.yaml @@ -13,7 +13,7 @@ spec: enableUI: true storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -21,7 +21,7 @@ spec: storage: 50Mi storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml b/docs/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml index 831359f858..a8b602a12f 100644 --- a/docs/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml +++ b/docs/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml @@ -36,7 +36,7 @@ spec: memory: "1.6Gi" storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml b/docs/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml index 831359f858..a8b602a12f 100644 --- a/docs/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml +++ b/docs/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml @@ -36,7 +36,7 @@ spec: memory: "1.6Gi" storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/mssqlserver/volume-expansion/mssql-standalone.yaml b/docs/examples/mssqlserver/volume-expansion/mssql-standalone.yaml index b9392192c8..c647e19d82 100644 --- a/docs/examples/mssqlserver/volume-expansion/mssql-standalone.yaml +++ b/docs/examples/mssqlserver/volume-expansion/mssql-standalone.yaml @@ -29,7 +29,7 @@ spec: limits: memory: "2Gi" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/mssqlserver/volume-expansion/mssqlserver-ag-cluster.yaml b/docs/examples/mssqlserver/volume-expansion/mssqlserver-ag-cluster.yaml index e3f32586c1..510e1388f0 100644 --- a/docs/examples/mssqlserver/volume-expansion/mssqlserver-ag-cluster.yaml +++ b/docs/examples/mssqlserver/volume-expansion/mssqlserver-ag-cluster.yaml @@ -29,7 +29,7 @@ spec: value: Evaluation # Change it storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/mysql/migration/storage-migration.yaml b/docs/examples/mysql/migration/storage-migration.yaml index 01981ec7d9..00c18a4e55 100644 --- a/docs/examples/mysql/migration/storage-migration.yaml +++ b/docs/examples/mysql/migration/storage-migration.yaml @@ -8,6 +8,6 @@ spec: databaseRef: name: sample-mysql migration: - storageClassName: longhorn-custom + storageClassName: standard-custom oldPVReclaimPolicy: Delete \ No newline at end of file diff --git a/docs/examples/postgres/migration/storage-migration.yaml b/docs/examples/postgres/migration/storage-migration.yaml index 287ea3121f..8a9d0f57c4 100644 --- a/docs/examples/postgres/migration/storage-migration.yaml +++ b/docs/examples/postgres/migration/storage-migration.yaml @@ -8,5 +8,5 @@ spec: databaseRef: name: sample-postgres migration: - storageClassName: longhorn-custom + storageClassName: standard-custom oldPVReclaimPolicy: Delete diff --git a/docs/examples/solr/autoscaler/combined.yaml b/docs/examples/solr/autoscaler/combined.yaml index 6265d5f238..2bdf3705fd 100644 --- a/docs/examples/solr/autoscaler/combined.yaml +++ b/docs/examples/solr/autoscaler/combined.yaml @@ -15,4 +15,4 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn \ No newline at end of file + storageClassName: standard \ No newline at end of file diff --git a/docs/examples/solr/autoscaler/topology.yaml b/docs/examples/solr/autoscaler/topology.yaml index b3d6138c89..c9fb65c97b 100644 --- a/docs/examples/solr/autoscaler/topology.yaml +++ b/docs/examples/solr/autoscaler/topology.yaml @@ -12,7 +12,7 @@ spec: overseer: replicas: 1 storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -21,7 +21,7 @@ spec: data: replicas: 1 storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -29,7 +29,7 @@ spec: storage: 1Gi coordinator: storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/solr/configuration/solr-combined.yaml b/docs/examples/solr/configuration/solr-combined.yaml index 03c46f37fc..46d130a86e 100644 --- a/docs/examples/solr/configuration/solr-combined.yaml +++ b/docs/examples/solr/configuration/solr-combined.yaml @@ -17,4 +17,4 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard diff --git a/docs/examples/solr/reconfigure/solr-combined.yaml b/docs/examples/solr/reconfigure/solr-combined.yaml index 03c46f37fc..46d130a86e 100644 --- a/docs/examples/solr/reconfigure/solr-combined.yaml +++ b/docs/examples/solr/reconfigure/solr-combined.yaml @@ -17,4 +17,4 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard diff --git a/docs/examples/zookeeper/monitoring/prom-zk.yaml b/docs/examples/zookeeper/monitoring/prom-zk.yaml index de720d8b12..45201f7757 100644 --- a/docs/examples/zookeeper/monitoring/prom-zk.yaml +++ b/docs/examples/zookeeper/monitoring/prom-zk.yaml @@ -10,7 +10,7 @@ spec: resources: requests: storage: "100Mi" - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce deletionPolicy: WipeOut diff --git a/docs/guides/cassandra/autoscaler/storage/storage-autoscale.md b/docs/guides/cassandra/autoscaler/storage/storage-autoscale.md index aafae160a6..b1d2998fa5 100644 --- a/docs/guides/cassandra/autoscaler/storage/storage-autoscale.md +++ b/docs/guides/cassandra/autoscaler/storage/storage-autoscale.md @@ -49,11 +49,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 6h2m -longhorn (default) driver.longhorn.io Delete Immediate true 9m41s -longhorn-static driver.longhorn.io Delete Immediate true 9m24s +standard (default) driver.standard.io Delete Immediate true 9m41s +standard-static driver.standard.io Delete Immediate true 9m24s ``` -We can see from the output the `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. +We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. Now, we are going to deploy a `Cassandra` cluster using a supported version by `KubeDB` operator. Then we are going to apply `CassandraAutoscaler` to set up autoscaling. @@ -78,7 +78,7 @@ spec: replicas: 2 storage: storageClassName: - longhorn + standard accessModes: - ReadWriteOnce resources: @@ -124,12 +124,12 @@ $ kubectl get petset -n demo cassandra-autoscale-rack-r0 -o json | jq '.spec.vol $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-394fefad-d4ad-4dfa-ba11-df96e015da30 600Mi RWO Delete Bound demo/cassandra-autoscale-main-config-volume-cassandra-autoscale-rack-r0-1 longhorn 21m -pvc-86ece3c8-520a-4d41-834e-66108867ca36 600Mi RWO Delete Bound demo/cassandra-autoscale-data-cassandra-autoscale-rack-r0-1 longhorn 21m -pvc-c35bb138-9f13-4098-b2b0-cc151f013f6d 600Mi RWO Delete Bound demo/cassandra-autoscale-main-config-volume-cassandra-autoscale-rack-r0-0 longhorn 21m -pvc-cc932132-de53-425f-bd31-91af255a47e8 600Mi RWO Delete Bound demo/cassandra-autoscale-data-cassandra-autoscale-rack-r0-0 longhorn 21m -pvc-cd57fb5f-b2f3-48de-b9d2-03059b05113f 600Mi RWO Delete Bound demo/cassandra-autoscale-nodetool-cassandra-autoscale-rack-r0-1 longhorn 21m -pvc-e550c573-60c7-4ec0-9e01-cf22683c502c 600Mi RWO Delete Bound demo/cassandra-autoscale-nodetool-cassandra-autoscale-rack-r0-0 longhorn 21m +pvc-394fefad-d4ad-4dfa-ba11-df96e015da30 600Mi RWO Delete Bound demo/cassandra-autoscale-main-config-volume-cassandra-autoscale-rack-r0-1 standard 21m +pvc-86ece3c8-520a-4d41-834e-66108867ca36 600Mi RWO Delete Bound demo/cassandra-autoscale-data-cassandra-autoscale-rack-r0-1 standard 21m +pvc-c35bb138-9f13-4098-b2b0-cc151f013f6d 600Mi RWO Delete Bound demo/cassandra-autoscale-main-config-volume-cassandra-autoscale-rack-r0-0 standard 21m +pvc-cc932132-de53-425f-bd31-91af255a47e8 600Mi RWO Delete Bound demo/cassandra-autoscale-data-cassandra-autoscale-rack-r0-0 standard 21m +pvc-cd57fb5f-b2f3-48de-b9d2-03059b05113f 600Mi RWO Delete Bound demo/cassandra-autoscale-nodetool-cassandra-autoscale-rack-r0-1 standard 21m +pvc-e550c573-60c7-4ec0-9e01-cf22683c502c 600Mi RWO Delete Bound demo/cassandra-autoscale-nodetool-cassandra-autoscale-rack-r0-0 standard 21m ``` You can see the petset has 600Mi storage, and the capacity of all the persistent volume is also 600Mi. @@ -559,12 +559,12 @@ $ kubectl get petset -n demo cassandra-autoscale-rack-r0 -o json | jq '.spec.vol $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-394fefad-d4ad-4dfa-ba11-df96e015da30 600Mi RWO Delete Bound demo/cassandra-autoscale-main-config-volume-cassandra-autoscale-rack-r0-1 longhorn 45m -pvc-86ece3c8-520a-4d41-834e-66108867ca36 1148Mi RWO Delete Bound demo/cassandra-autoscale-data-cassandra-autoscale-rack-r0-1 longhorn 45m -pvc-c35bb138-9f13-4098-b2b0-cc151f013f6d 600Mi RWO Delete Bound demo/cassandra-autoscale-main-config-volume-cassandra-autoscale-rack-r0-0 longhorn 45m -pvc-cc932132-de53-425f-bd31-91af255a47e8 1148Mi RWO Delete Bound demo/cassandra-autoscale-data-cassandra-autoscale-rack-r0-0 longhorn 45m -pvc-cd57fb5f-b2f3-48de-b9d2-03059b05113f 600Mi RWO Delete Bound demo/cassandra-autoscale-nodetool-cassandra-autoscale-rack-r0-1 longhorn 45m -pvc-e550c573-60c7-4ec0-9e01-cf22683c502c 600Mi RWO Delete Bound demo/cassandra-autoscale-nodetool-cassandra-autoscale-rack-r0-0 longhorn 45m +pvc-394fefad-d4ad-4dfa-ba11-df96e015da30 600Mi RWO Delete Bound demo/cassandra-autoscale-main-config-volume-cassandra-autoscale-rack-r0-1 standard 45m +pvc-86ece3c8-520a-4d41-834e-66108867ca36 1148Mi RWO Delete Bound demo/cassandra-autoscale-data-cassandra-autoscale-rack-r0-1 standard 45m +pvc-c35bb138-9f13-4098-b2b0-cc151f013f6d 600Mi RWO Delete Bound demo/cassandra-autoscale-main-config-volume-cassandra-autoscale-rack-r0-0 standard 45m +pvc-cc932132-de53-425f-bd31-91af255a47e8 1148Mi RWO Delete Bound demo/cassandra-autoscale-data-cassandra-autoscale-rack-r0-0 standard 45m +pvc-cd57fb5f-b2f3-48de-b9d2-03059b05113f 600Mi RWO Delete Bound demo/cassandra-autoscale-nodetool-cassandra-autoscale-rack-r0-1 standard 45m +pvc-e550c573-60c7-4ec0-9e01-cf22683c502c 600Mi RWO Delete Bound demo/cassandra-autoscale-nodetool-cassandra-autoscale-rack-r0-0 standard 45m ``` diff --git a/docs/guides/cassandra/volume-expansion/topology.md b/docs/guides/cassandra/volume-expansion/topology.md index bb0da4d779..1eba8eaa9c 100644 --- a/docs/guides/cassandra/volume-expansion/topology.md +++ b/docs/guides/cassandra/volume-expansion/topology.md @@ -50,8 +50,8 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 5d22h -longhorn (default) driver.longhorn.io Delete Immediate true 6s -longhorn-static driver.longhorn.io Delete Immediate true 3s +standard (default) driver.standard.io Delete Immediate true 6s +standard-static driver.standard.io Delete Immediate true 3s ``` @@ -77,7 +77,7 @@ spec: replicas: 2 storage: storageClassName: - longhorn + standard accessModes: - ReadWriteOnce resources: @@ -126,12 +126,12 @@ $ kubectl get petset -n demo cassandra-prod-rack-r0 -o json | jq '.spec.volumeCl $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-623e4d80-f508-4bb1-a4cb-4ebdbcbd8495 1Gi RWO Delete Bound demo/data-cassandra-prod-rack-r0-0 longhorn 82s -pvc-76b5a0a7-d234-426c-a4cc-ec740d6456ba 1Gi RWO Delete Bound demo/data-cassandra-prod-rack-r0-1 longhorn 64s -pvc-84588238-9fea-4ac3-9cfa-f7b04640697c 1Gi RWO Delete Bound demo/nodetool-cassandra-prod-rack-r0-0 longhorn 82s -pvc-849d404c-d078-4802-a28f-6834d8c81998 1Gi RWO Delete Bound demo/nodetool-cassandra-prod-rack-r0-1 longhorn 64s -pvc-85a6902d-a596-45db-94f9-1ce355600323 1Gi RWO Delete Bound demo/main-config-volume-cassandra-prod-rack-r0-1 longhorn 64s -pvc-88d6586e-b502-481d-91fc-dd6381d9b1c0 1Gi RWO Delete Bound demo/main-config-volume-cassandra-prod-rack-r0-0 longhorn 82s +pvc-623e4d80-f508-4bb1-a4cb-4ebdbcbd8495 1Gi RWO Delete Bound demo/data-cassandra-prod-rack-r0-0 standard 82s +pvc-76b5a0a7-d234-426c-a4cc-ec740d6456ba 1Gi RWO Delete Bound demo/data-cassandra-prod-rack-r0-1 standard 64s +pvc-84588238-9fea-4ac3-9cfa-f7b04640697c 1Gi RWO Delete Bound demo/nodetool-cassandra-prod-rack-r0-0 standard 82s +pvc-849d404c-d078-4802-a28f-6834d8c81998 1Gi RWO Delete Bound demo/nodetool-cassandra-prod-rack-r0-1 standard 64s +pvc-85a6902d-a596-45db-94f9-1ce355600323 1Gi RWO Delete Bound demo/main-config-volume-cassandra-prod-rack-r0-1 standard 64s +pvc-88d6586e-b502-481d-91fc-dd6381d9b1c0 1Gi RWO Delete Bound demo/main-config-volume-cassandra-prod-rack-r0-0 standard 82s ``` You can see the petsets have 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -343,12 +343,12 @@ $ kubectl get petset -n demo cassandra-prod-rack-r0 -o json | jq '.spec.volumeCl $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-7efa007f-5fb2-4e64-aea0-233ec456703f 1Gi RWO Delete Bound demo/main-config-volume-cassandra-prod-rack-r0-1 longhorn 11m -pvc-88f8ec55-ae5b-48dd-9b3a-0dc113cdaa43 2Gi RWO Delete Bound demo/data-cassandra-prod-rack-r0-1 longhorn 11m -pvc-c455344e-0f17-42d2-8fd9-062fa2f1b0a1 1Gi RWO Delete Bound demo/main-config-volume-cassandra-prod-rack-r0-0 longhorn 11m -pvc-d19d62ac-b37b-406e-a7d6-a10f4f74d929 2Gi RWO Delete Bound demo/data-cassandra-prod-rack-r0-0 longhorn 11m -pvc-df152a7a-12ea-4690-b64e-ccb2decce8cd 1Gi RWO Delete Bound demo/nodetool-cassandra-prod-rack-r0-1 longhorn 11m -pvc-f8420d54-05f8-4ea2-b70c-11a3737e04e4 1Gi RWO Delete Bound demo/nodetool-cassandra-prod-rack-r0-0 longhorn 11m +pvc-7efa007f-5fb2-4e64-aea0-233ec456703f 1Gi RWO Delete Bound demo/main-config-volume-cassandra-prod-rack-r0-1 standard 11m +pvc-88f8ec55-ae5b-48dd-9b3a-0dc113cdaa43 2Gi RWO Delete Bound demo/data-cassandra-prod-rack-r0-1 standard 11m +pvc-c455344e-0f17-42d2-8fd9-062fa2f1b0a1 1Gi RWO Delete Bound demo/main-config-volume-cassandra-prod-rack-r0-0 standard 11m +pvc-d19d62ac-b37b-406e-a7d6-a10f4f74d929 2Gi RWO Delete Bound demo/data-cassandra-prod-rack-r0-0 standard 11m +pvc-df152a7a-12ea-4690-b64e-ccb2decce8cd 1Gi RWO Delete Bound demo/nodetool-cassandra-prod-rack-r0-1 standard 11m +pvc-f8420d54-05f8-4ea2-b70c-11a3737e04e4 1Gi RWO Delete Bound demo/nodetool-cassandra-prod-rack-r0-0 standard 11m ``` The above output verifies that we have successfully expanded the data related volume of the Cassandra. diff --git a/docs/guides/clickhouse/autoscaler/compute/compute-autoscale.md b/docs/guides/clickhouse/autoscaler/compute/compute-autoscale.md index ebcb7dba8d..55201db21b 100644 --- a/docs/guides/clickhouse/autoscaler/compute/compute-autoscale.md +++ b/docs/guides/clickhouse/autoscaler/compute/compute-autoscale.md @@ -85,7 +85,7 @@ spec: cpu: 500m memory: 1Gi storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/clickhouse/autoscaler/storage/storage-autoscale.md b/docs/guides/clickhouse/autoscaler/storage/storage-autoscale.md index 82aa69e179..54cbbf4379 100644 --- a/docs/guides/clickhouse/autoscaler/storage/storage-autoscale.md +++ b/docs/guides/clickhouse/autoscaler/storage/storage-autoscale.md @@ -49,11 +49,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 6h2m -longhorn (default) driver.longhorn.io Delete Immediate true 9m41s -longhorn-static driver.longhorn.io Delete Immediate true 9m24s +standard (default) driver.standard.io Delete Immediate true 9m41s +standard-static driver.standard.io Delete Immediate true 9m24s ``` -We can see from the output the `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. +We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. Now, we are going to deploy a `ClickHouse` cluster using a supported version by `KubeDB` operator. Then we are going to apply `ClickHouseAutoscaler` to set up autoscaling. @@ -103,7 +103,7 @@ spec: cpu: 500m memory: 1Gi storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -136,13 +136,13 @@ Let's check volume size from petset, and from the persistent volume, ➤ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-3a1cbeb5-ed56-4c20-9e29-960c202dd2f7 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-1 longhorn 3m52s -pvc-53e703b6-b5d5-46c2-97b6-f724f684a448 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-0 longhorn 4m3s -pvc-817d3ee6-922c-471e-889a-4529f8822ce2 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-0 longhorn 4m10s -pvc-892c1830-8521-4e84-80e8-fdd7995b0c03 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-1 longhorn 3m41s -pvc-a8027da7-92a7-4d70-9a12-6ea5e3280d16 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-1 longhorn 3m45s -pvc-e0722709-9674-4e41-b1be-756a6d77e330 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-2 longhorn 3m33s -pvc-f2666ae8-1f53-4d0b-869e-ac62ffde5d5e 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-0 longhorn 4m longhorn 21m +pvc-3a1cbeb5-ed56-4c20-9e29-960c202dd2f7 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-1 standard 3m52s +pvc-53e703b6-b5d5-46c2-97b6-f724f684a448 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-0 standard 4m3s +pvc-817d3ee6-922c-471e-889a-4529f8822ce2 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-0 standard 4m10s +pvc-892c1830-8521-4e84-80e8-fdd7995b0c03 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-1 standard 3m41s +pvc-a8027da7-92a7-4d70-9a12-6ea5e3280d16 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-1 standard 3m45s +pvc-e0722709-9674-4e41-b1be-756a6d77e330 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-2 standard 3m33s +pvc-f2666ae8-1f53-4d0b-869e-ac62ffde5d5e 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-0 standard 4m standard 21m ``` You can see the petset has 1Gi storage, and the capacity of all the persistent volume is also 600Mi. @@ -247,14 +247,14 @@ Let's exec into the database pod and fill the database volume(`var/lib/clickhous Defaulted container "clickhouse" out of: clickhouse, clickhouse-init (init) clickhouse@clickhouse-prod-appscode-cluster-shard-0-0:/$ df -h /var/lib/clickhouse Filesystem Size Used Avail Use% Mounted on -/dev/longhorn/pvc-53e703b6-b5d5-46c2-97b6-f724f684a448 974M 30M 929M 4% /var/lib/clickhouse +/dev/standard/pvc-53e703b6-b5d5-46c2-97b6-f724f684a448 974M 30M 929M 4% /var/lib/clickhouse clickhouse@clickhouse-prod-appscode-cluster-shard-0-0:/$ dd if=/dev/zero of=/var/lib/clickhouse/file.img bs=500M count=1 1+0 records in 1+0 records out 524288000 bytes (524 MB, 500 MiB) copied, 11.2442 s, 46.6 MB/s clickhouse@clickhouse-prod-appscode-cluster-shard-0-0:/$ df -h /var/lib/clickhouse Filesystem Size Used Avail Use% Mounted on -/dev/longhorn/pvc-53e703b6-b5d5-46c2-97b6-f724f684a448 974M 531M 428M 56% /var/lib/clickhouse +/dev/standard/pvc-53e703b6-b5d5-46c2-97b6-f724f684a448 974M 531M 428M 56% /var/lib/clickhouse ``` So, from the above output we can see that the storage usage is 56%, which exceeded the `usageThreshold` 40%. @@ -434,13 +434,13 @@ Now, we are going to verify from the `Petset`, and the `Persistent Volume` wheth shuvo@shuvo-pc:~ ➤ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-3a1cbeb5-ed56-4c20-9e29-960c202dd2f7 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-1 longhorn 38m -pvc-53e703b6-b5d5-46c2-97b6-f724f684a448 1462Mi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-0 longhorn 38m -pvc-817d3ee6-922c-471e-889a-4529f8822ce2 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-0 longhorn 38m -pvc-892c1830-8521-4e84-80e8-fdd7995b0c03 1462Mi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-1 longhorn 38m -pvc-a8027da7-92a7-4d70-9a12-6ea5e3280d16 1462Mi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-1 longhorn 38m -pvc-e0722709-9674-4e41-b1be-756a6d77e330 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-2 longhorn 38m -pvc-f2666ae8-1f53-4d0b-869e-ac62ffde5d5e 1462Mi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-0 longhorn 38m +pvc-3a1cbeb5-ed56-4c20-9e29-960c202dd2f7 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-1 standard 38m +pvc-53e703b6-b5d5-46c2-97b6-f724f684a448 1462Mi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-0 standard 38m +pvc-817d3ee6-922c-471e-889a-4529f8822ce2 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-0 standard 38m +pvc-892c1830-8521-4e84-80e8-fdd7995b0c03 1462Mi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-1 standard 38m +pvc-a8027da7-92a7-4d70-9a12-6ea5e3280d16 1462Mi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-1 standard 38m +pvc-e0722709-9674-4e41-b1be-756a6d77e330 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-2 standard 38m +pvc-f2666ae8-1f53-4d0b-869e-ac62ffde5d5e 1462Mi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-0 standard 38m ``` The above output verifies that we have successfully autoscaled the volume of the Clickhouse replicaset database. diff --git a/docs/guides/clickhouse/volume-expansion/cluster.md b/docs/guides/clickhouse/volume-expansion/cluster.md index 85151ba7f1..abb3037c7c 100644 --- a/docs/guides/clickhouse/volume-expansion/cluster.md +++ b/docs/guides/clickhouse/volume-expansion/cluster.md @@ -50,11 +50,11 @@ At first verify that your cluster has a storage class, that supports volume expa ➤ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 7d22h -longhorn (default) driver.longhorn.io Delete Immediate true 6d23h -longhorn-static driver.longhorn.io Delete Immediate true 6d23h +standard (default) driver.standard.io Delete Immediate true 6d23h +standard-static driver.standard.io Delete Immediate true 6d23h ``` -We can see from the output the `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. +We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. Now, we are going to deploy a `ClickHouse` combined cluster with version `24.4.1`. @@ -104,7 +104,7 @@ spec: cpu: 500m memory: 1Gi storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -137,13 +137,13 @@ Let's check volume size from petset, and from the persistent volume, ```bash ➤ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-03fe7758-fc16-4c77-8072-4948331386a4 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-1 longhorn 4m14s -pvc-348df1d0-037c-4284-9556-1bd2e2089a37 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-0 longhorn 4m22s -pvc-39d65c1d-86dc-4028-ad68-91a45a2d4be5 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-0 longhorn 4m19s -pvc-6bd28008-6fc4-4b24-b377-257268ae60b2 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-2 longhorn 4m -pvc-73abd357-2d97-4469-a34a-17ce41364fe1 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-0 longhorn 4m28s -pvc-7ab3ae88-bdd1-45c2-8aa4-dc58e50e0551 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-1 longhorn 4m8s -pvc-e4004397-b6f7-4a6b-bef6-a87e0f8c2014 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-1 longhorn 4m3s +pvc-03fe7758-fc16-4c77-8072-4948331386a4 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-1 standard 4m14s +pvc-348df1d0-037c-4284-9556-1bd2e2089a37 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-0 standard 4m22s +pvc-39d65c1d-86dc-4028-ad68-91a45a2d4be5 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-0 standard 4m19s +pvc-6bd28008-6fc4-4b24-b377-257268ae60b2 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-2 standard 4m +pvc-73abd357-2d97-4469-a34a-17ce41364fe1 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-0 standard 4m28s +pvc-7ab3ae88-bdd1-45c2-8aa4-dc58e50e0551 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-1 standard 4m8s +pvc-e4004397-b6f7-4a6b-bef6-a87e0f8c2014 1Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-1 standard 4m3s ``` You can see the petsets have 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -465,13 +465,13 @@ Now, we are going to verify from the `Petset`, and the `Persistent Volumes` whet ➤ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-03fe7758-fc16-4c77-8072-4948331386a4 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-1 longhorn 15m -pvc-348df1d0-037c-4284-9556-1bd2e2089a37 2Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-0 longhorn 16m -pvc-39d65c1d-86dc-4028-ad68-91a45a2d4be5 2Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-0 longhorn 16m -pvc-6bd28008-6fc4-4b24-b377-257268ae60b2 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-2 longhorn 15m -pvc-73abd357-2d97-4469-a34a-17ce41364fe1 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-0 longhorn 16m -pvc-7ab3ae88-bdd1-45c2-8aa4-dc58e50e0551 2Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-1 longhorn 15m -pvc-e4004397-b6f7-4a6b-bef6-a87e0f8c2014 2Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-1 longhorn 15m +pvc-03fe7758-fc16-4c77-8072-4948331386a4 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-1 standard 15m +pvc-348df1d0-037c-4284-9556-1bd2e2089a37 2Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-0 standard 16m +pvc-39d65c1d-86dc-4028-ad68-91a45a2d4be5 2Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-0 standard 16m +pvc-6bd28008-6fc4-4b24-b377-257268ae60b2 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-2 standard 15m +pvc-73abd357-2d97-4469-a34a-17ce41364fe1 1Gi RWO Delete Bound demo/data-clickhouse-prod-keeper-0 standard 16m +pvc-7ab3ae88-bdd1-45c2-8aa4-dc58e50e0551 2Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-0-1 standard 15m +pvc-e4004397-b6f7-4a6b-bef6-a87e0f8c2014 2Gi RWO Delete Bound demo/data-clickhouse-prod-appscode-cluster-shard-1-1 standard 15m ``` The above output verifies that we have successfully expanded the data related volume of the ClickHouse. diff --git a/docs/guides/druid/autoscaler/storage/guide.md b/docs/guides/druid/autoscaler/storage/guide.md index 02b3571625..383bdf5ac0 100644 --- a/docs/guides/druid/autoscaler/storage/guide.md +++ b/docs/guides/druid/autoscaler/storage/guide.md @@ -51,11 +51,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 28h -longhorn (default) driver.longhorn.io Delete Immediate true 28h -longhorn-static driver.longhorn.io Delete Immediate true 28h +standard (default) driver.standard.io Delete Immediate true 28h +standard-static driver.standard.io Delete Immediate true 28h ``` -We can see from the output the `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. +We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. Now, we are going to deploy a `Druid` topology using a supported version by `KubeDB` operator. Then we are going to apply `DruidAutoscaler` to set up autoscaling. @@ -182,8 +182,8 @@ $ kubectl get petset -n demo druid-cluster-middleManagers -o json | jq '.spec.vo "1Gi" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-2c0ef2aa-0438-4d75-9cb2-c12a176bae6a 1Gi RWO Delete Bound demo/druid-cluster-base-task-dir-druid-cluster-middlemanagers-0 longhorn 95s -pvc-5f4cea5f-e0c8-4339-b67c-9cb8b02ba49d 1Gi RWO Delete Bound demo/druid-cluster-segment-cache-druid-cluster-historicals-0 longhorn 96s +pvc-2c0ef2aa-0438-4d75-9cb2-c12a176bae6a 1Gi RWO Delete Bound demo/druid-cluster-base-task-dir-druid-cluster-middlemanagers-0 standard 95s +pvc-5f4cea5f-e0c8-4339-b67c-9cb8b02ba49d 1Gi RWO Delete Bound demo/druid-cluster-segment-cache-druid-cluster-historicals-0 standard 96s ``` You can see the petset for both historicals and middleManagers has 1GB storage, and the capacity of all the persistent volume is also 1GB. @@ -337,7 +337,7 @@ We are autoscaling volume for both historicals and middleManagers. So we need to $ kubectl exec -it -n demo druid-cluster-historicals-0 -- bash bash-5.1$ df -h /druid/data/segments Filesystem Size Used Available Use% Mounted on -/dev/longhorn/pvc-d4ef15ef-b1af-4a1f-ad25-ad9bc990a2fb 973.4M 92.0K 957.3M 0% /druid/data/segment +/dev/standard/pvc-d4ef15ef-b1af-4a1f-ad25-ad9bc990a2fb 973.4M 92.0K 957.3M 0% /druid/data/segment bash-5.1$ dd if=/dev/zero of=/druid/data/segments/file.img bs=600M count=1 1+0 records in @@ -346,7 +346,7 @@ bash-5.1$ dd if=/dev/zero of=/druid/data/segments/file.img bs=600M count=1 bash-5.1$ df -h /druid/data/segments Filesystem Size Used Available Use% Mounted on -/dev/longhorn/pvc-d4ef15ef-b1af-4a1f-ad25-ad9bc990a2fb 973.4M 600.1M 357.3M 63% /druid/data/segments +/dev/standard/pvc-d4ef15ef-b1af-4a1f-ad25-ad9bc990a2fb 973.4M 600.1M 357.3M 63% /druid/data/segments ``` 2. Let's exec into the middleManagers pod and fill the cluster volume using the following commands: @@ -355,14 +355,14 @@ Filesystem Size Used A $ kubectl exec -it -n demo druid-cluster-middleManagers-0 -- bash druid@druid-cluster-middleManagers-0:~$ df -h /var/druid/task Filesystem Size Used Available Use% Mounted on -/dev/longhorn/pvc-2c0ef2aa-0438-4d75-9cb2-c12a176bae6a 973.4M 24.0K 957.4M 0% /var/druid/task +/dev/standard/pvc-2c0ef2aa-0438-4d75-9cb2-c12a176bae6a 973.4M 24.0K 957.4M 0% /var/druid/task druid@druid-cluster-middleManagers-0:~$ dd if=/dev/zero of=/var/druid/task/file.img bs=600M count=1 1+0 records in 1+0 records out 629145600 bytes (629 MB, 600 MiB) copied, 3.39618 s, 185 MB/s druid@druid-cluster-middleManagers-0:~$ df -h /var/druid/task Filesystem Size Used Available Use% Mounted on -/dev/longhorn/pvc-2c0ef2aa-0438-4d75-9cb2-c12a176bae6a 973.4M 600.0M 357.4M 63% /var/druid/task +/dev/standard/pvc-2c0ef2aa-0438-4d75-9cb2-c12a176bae6a 973.4M 600.0M 357.4M 63% /var/druid/task ``` So, from the above output we can see that the storage usage is 63% for both nodes, which exceeded the `usageThreshold` 60%. @@ -870,8 +870,8 @@ $ kubectl get petset -n demo druid-cluster-middleManagers -o json | jq '.spec.vo "2041405440" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-2c0ef2aa-0438-4d75-9cb2-c12a176bae6a 1948Mi RWO Delete Bound demo/druid-cluster-base-task-dir-druid-cluster-middlemanagers-0 longhorn 19m -pvc-5f4cea5f-e0c8-4339-b67c-9cb8b02ba49d 1948Mi RWO Delete Bound demo/druid-cluster-segment-cache-druid-cluster-historicals-0 longhorn 19m +pvc-2c0ef2aa-0438-4d75-9cb2-c12a176bae6a 1948Mi RWO Delete Bound demo/druid-cluster-base-task-dir-druid-cluster-middlemanagers-0 standard 19m +pvc-5f4cea5f-e0c8-4339-b67c-9cb8b02ba49d 1948Mi RWO Delete Bound demo/druid-cluster-segment-cache-druid-cluster-historicals-0 standard 19m ``` The above output verifies that we have successfully autoscaled the volume of the Druid topology cluster for both historicals and middleManagers. diff --git a/docs/guides/druid/volume-expansion/guide.md b/docs/guides/druid/volume-expansion/guide.md index 96eed7eecc..ba33db8df0 100644 --- a/docs/guides/druid/volume-expansion/guide.md +++ b/docs/guides/druid/volume-expansion/guide.md @@ -51,11 +51,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 28h -longhorn (default) driver.longhorn.io Delete Immediate true 27h -longhorn-static driver.longhorn.io Delete Immediate true 27h +standard (default) driver.standard.io Delete Immediate true 27h +standard-static driver.standard.io Delete Immediate true 27h ``` -We can see from the output the `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. +We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. ### Create External Dependency (Deep Storage) @@ -177,8 +177,8 @@ $ kubectl get petset -n demo druid-cluster-middleManagers -o json | jq '.spec.vo $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-0bf49077-1c7a-4943-bb17-1dffd1626dcd 1Gi RWO Delete Bound demo/druid-cluster-segment-cache-druid-cluster-historicals-0 longhorn 10m -pvc-59ed4914-53b3-4f18-a6aa-7699c2b738e2 1Gi RWO Delete Bound demo/druid-cluster-base-task-dir-druid-cluster-middlemanagers-0 longhorn 10m +pvc-0bf49077-1c7a-4943-bb17-1dffd1626dcd 1Gi RWO Delete Bound demo/druid-cluster-segment-cache-druid-cluster-historicals-0 standard 10m +pvc-59ed4914-53b3-4f18-a6aa-7699c2b738e2 1Gi RWO Delete Bound demo/druid-cluster-base-task-dir-druid-cluster-middlemanagers-0 standard 10m ``` You can see the petsets have 1GB storage, and the capacity of all the persistent volumes are also 1GB. diff --git a/docs/guides/elasticsearch/gitops/gitops.md b/docs/guides/elasticsearch/gitops/gitops.md index 039eb96712..f51df343d0 100644 --- a/docs/guides/elasticsearch/gitops/gitops.md +++ b/docs/guides/elasticsearch/gitops/gitops.md @@ -1,10 +1,10 @@ --- -title: Elasticsearch GitOps Overview -description: Elasticsearch GitOps Overview +title: Elasticsearch GitOps Details +description: Elasticsearch GitOps menu: docs_{{ .version }}: - identifier: es-gitops-overview - name: Overview + identifier: gitops-elasticsearch + name: GitOps Elasticsearch parent: es-gitops weight: 20 menu_name: docs_{{ .version }} @@ -74,7 +74,7 @@ spec: replicas: 2 storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -154,7 +154,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -216,7 +216,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -283,7 +283,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -380,7 +380,7 @@ spec: memory: 1Gi storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -419,7 +419,6 @@ $ kubectl create secret generic es-rotate-auth -n demo \ --from-literal=username=elastic \ --from-literal=password=elasticsearch-secret secret/es-rotate-auth created - ``` @@ -453,7 +452,7 @@ spec: memory: 1Gi storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -497,7 +496,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -574,7 +573,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -714,7 +713,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -746,7 +745,7 @@ spec: interval: 10s ``` -Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. +Add `enableSSL: true` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Elasticsearch` database tls. List the resources created by `gitops` operator in the `demo` namespace. @@ -766,7 +765,7 @@ elasticsearchopsrequest.ops.kubedb.com/es-gitops-rotate-auth-8cgx3b Rota elasticsearchopsrequest.ops.kubedb.com/es-gitops-versionupdate-z92dz0 UpdateVersion Successful 28m elasticsearchopsrequest.ops.kubedb.com/es-gitops-verticalscaling-wyjx4l VerticalScaling Successful 55m elasticsearchopsrequest.ops.kubedb.com/es-gitops-volumeexpansion-z2e3qb VolumeExpansion Successful 50m -Elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s +elasticsearchopsrequest.ops.kubedb.com/es-gitops-reconfiguretls-r4mx7v ReconfigureTLS Successful 9m18s ``` diff --git a/docs/guides/elasticsearch/volume-expansion/combined.md b/docs/guides/elasticsearch/volume-expansion/combined.md index e3c9cf7f1f..fa2273acaa 100644 --- a/docs/guides/elasticsearch/volume-expansion/combined.md +++ b/docs/guides/elasticsearch/volume-expansion/combined.md @@ -106,7 +106,7 @@ $ kubectl get petset -n demo es-combined -o json | jq '.spec.volumeClaimTemplate "1Gi" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-edeeff75-9823-4aeb-9189-37adad567ec7 1Gi RWO Delete Bound demo/data-es-combined-0 longhorn 2m21s +pvc-edeeff75-9823-4aeb-9189-37adad567ec7 1Gi RWO Delete Bound demo/data-es-combined-0 standard 2m21s ``` @@ -343,7 +343,7 @@ $ kubectl get petset -n demo es-combined -o json | jq '.spec.volumeClaimTemplat $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-edeeff75-9823-4aeb-9189-37adad567ec7 4Gi RWO Delete Bound demo/data-es-combined-0 longhorn 13m +pvc-edeeff75-9823-4aeb-9189-37adad567ec7 4Gi RWO Delete Bound demo/data-es-combined-0 standard 13m ``` The above output verifies that we have successfully expanded the volume of the Elasticsearch. diff --git a/docs/guides/ferretdb/clustering/replication.md b/docs/guides/ferretdb/clustering/replication.md index f35bfdd437..cb807a1ba0 100644 --- a/docs/guides/ferretdb/clustering/replication.md +++ b/docs/guides/ferretdb/clustering/replication.md @@ -233,15 +233,15 @@ ferret-secondary-pods ClusterIP None 27017/TCP $ kubectl get pvc -n demo NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-ferret-pg-backend-0 Bound pvc-e26fdc37-a7e4-4567-bc2e-d2e5e4e52ad9 1Gi RWO longhorn 46m -data-ferret-pg-backend-1 Bound pvc-470d3d5a-b00e-4100-bb8e-8bad63369f7b 1Gi RWO longhorn 45m -data-ferret-pg-backend-2 Bound pvc-5a02705b-b389-413d-98bb-969b5f0b9128 1Gi RWO longhorn 45m +data-ferret-pg-backend-0 Bound pvc-e26fdc37-a7e4-4567-bc2e-d2e5e4e52ad9 1Gi RWO standard 46m +data-ferret-pg-backend-1 Bound pvc-470d3d5a-b00e-4100-bb8e-8bad63369f7b 1Gi RWO standard 45m +data-ferret-pg-backend-2 Bound pvc-5a02705b-b389-413d-98bb-969b5f0b9128 1Gi RWO standard 45m $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-470d3d5a-b00e-4100-bb8e-8bad63369f7b 1Gi RWO Delete Bound demo/data-ferret-pg-backend-1 longhorn 46m -pvc-5a02705b-b389-413d-98bb-969b5f0b9128 1Gi RWO Delete Bound demo/data-ferret-pg-backend-2 longhorn 46m -pvc-e26fdc37-a7e4-4567-bc2e-d2e5e4e52ad9 1Gi RWO Delete Bound demo/data-ferret-pg-backend-0 longhorn 46m +pvc-470d3d5a-b00e-4100-bb8e-8bad63369f7b 1Gi RWO Delete Bound demo/data-ferret-pg-backend-1 standard 46m +pvc-5a02705b-b389-413d-98bb-969b5f0b9128 1Gi RWO Delete Bound demo/data-ferret-pg-backend-2 standard 46m +pvc-e26fdc37-a7e4-4567-bc2e-d2e5e4e52ad9 1Gi RWO Delete Bound demo/data-ferret-pg-backend-0 standard 46m $ kubectl get secret -n demo NAME TYPE DATA AGE diff --git a/docs/guides/hazelcast/autoscaler/compute/hazelcast-compute.md b/docs/guides/hazelcast/autoscaler/compute/hazelcast-compute.md index f7150bcb18..7b3cd9a86e 100644 --- a/docs/guides/hazelcast/autoscaler/compute/hazelcast-compute.md +++ b/docs/guides/hazelcast/autoscaler/compute/hazelcast-compute.md @@ -81,7 +81,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard storageType: Durable deletionPolicy: WipeOut ``` diff --git a/docs/guides/hazelcast/autoscaler/storage/hazelcast-storage.md b/docs/guides/hazelcast/autoscaler/storage/hazelcast-storage.md index bb4e29719a..9e68b12afd 100644 --- a/docs/guides/hazelcast/autoscaler/storage/hazelcast-storage.md +++ b/docs/guides/hazelcast/autoscaler/storage/hazelcast-storage.md @@ -88,7 +88,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard storageType: Durable deletionPolicy: WipeOut ``` @@ -428,8 +428,8 @@ $ kubectl get statefulset -n demo hazelcast-dev -o json | jq '.spec.volumeClaimT "1531054080" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 1462Mi RWO Delete Bound demo/hazelcast-dev-data-hazelcast-dev-0 longhorn 30m5s -pvc-f068d245-718b-4561-b452-f3130bb260f6 1462Mi RWO Delete Bound demo/hazelcast-dev-data-hazelcast-dev-1 longhorn 30m1s +pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 1462Mi RWO Delete Bound demo/hazelcast-dev-data-hazelcast-dev-0 standard 30m5s +pvc-f068d245-718b-4561-b452-f3130bb260f6 1462Mi RWO Delete Bound demo/hazelcast-dev-data-hazelcast-dev-1 standard 30m1s ``` The above output verifies that we have successfully autoscaled the volume of the Hazelcast cluster. diff --git a/docs/guides/hazelcast/concepts/appbinding.md b/docs/guides/hazelcast/concepts/appbinding.md index a69ba02cd4..9f6a1f4946 100644 --- a/docs/guides/hazelcast/concepts/appbinding.md +++ b/docs/guides/hazelcast/concepts/appbinding.md @@ -34,7 +34,7 @@ kind: AppBinding metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"kubedb.com/v1alpha2","kind":"Hazelcast","metadata":{"annotations":{},"name":"hazelcast-sample","namespace":"demo"},"spec":{"deletionPolicy":"Halt","enableSSL":true,"licenseSecret":{"name":"hz-license-key"},"replicas":3,"storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"2Gi"}},"storageClassName":"longhorn"},"tls":{"certificates":[{"alias":"server","dnsNames":["localhost"],"ipAddresses":["127.0.0.1"],"subject":{"organizations":["kubedb"]}},{"alias":"client","dnsNames":["localhost"],"ipAddresses":["127.0.0.1"],"subject":{"organizations":["kubedb"]}}],"issuerRef":{"apiGroup":"cert-manager.io","kind":"ClusterIssuer","name":"self-signed-issuer"}},"version":"5.5.2"}} + {"apiVersion":"kubedb.com/v1alpha2","kind":"Hazelcast","metadata":{"annotations":{},"name":"hazelcast-sample","namespace":"demo"},"spec":{"deletionPolicy":"Halt","enableSSL":true,"licenseSecret":{"name":"hz-license-key"},"replicas":3,"storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"2Gi"}},"storageClassName":"standard"},"tls":{"certificates":[{"alias":"server","dnsNames":["localhost"],"ipAddresses":["127.0.0.1"],"subject":{"organizations":["kubedb"]}},{"alias":"client","dnsNames":["localhost"],"ipAddresses":["127.0.0.1"],"subject":{"organizations":["kubedb"]}}],"issuerRef":{"apiGroup":"cert-manager.io","kind":"ClusterIssuer","name":"self-signed-issuer"}},"version":"5.5.2"}} creationTimestamp: "2025-06-11T07:35:38Z" generation: 1 labels: diff --git a/docs/guides/hazelcast/concepts/hazelcast.md b/docs/guides/hazelcast/concepts/hazelcast.md index f592b22c2a..0ed2c5267f 100644 --- a/docs/guides/hazelcast/concepts/hazelcast.md +++ b/docs/guides/hazelcast/concepts/hazelcast.md @@ -28,7 +28,7 @@ kind: Hazelcast metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"kubedb.com/v1alpha2","kind":"Hazelcast","metadata":{"annotations":{},"name":"hazelcast-sample","namespace":"demo"},"spec":{"deletionPolicy":"Halt","enableSSL":true,"licenseSecret":{"name":"hz-license-key"},"replicas":3,"storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"2Gi"}},"storageClassName":"longhorn"},"tls":{"certificates":[{"alias":"server","dnsNames":["localhost"],"ipAddresses":["127.0.0.1"],"subject":{"organizations":["kubedb"]}},{"alias":"client","dnsNames":["localhost"],"ipAddresses":["127.0.0.1"],"subject":{"organizations":["kubedb"]}}],"issuerRef":{"apiGroup":"cert-manager.io","kind":"ClusterIssuer","name":"self-signed-issuer"}},"version":"5.5.2"}} + {"apiVersion":"kubedb.com/v1alpha2","kind":"Hazelcast","metadata":{"annotations":{},"name":"hazelcast-sample","namespace":"demo"},"spec":{"deletionPolicy":"Halt","enableSSL":true,"licenseSecret":{"name":"hz-license-key"},"replicas":3,"storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"2Gi"}},"storageClassName":"standard"},"tls":{"certificates":[{"alias":"server","dnsNames":["localhost"],"ipAddresses":["127.0.0.1"],"subject":{"organizations":["kubedb"]}},{"alias":"client","dnsNames":["localhost"],"ipAddresses":["127.0.0.1"],"subject":{"organizations":["kubedb"]}}],"issuerRef":{"apiGroup":"cert-manager.io","kind":"ClusterIssuer","name":"self-signed-issuer"}},"version":"5.5.2"}} creationTimestamp: "2025-06-11T07:35:38Z" finalizers: - kubedb.com @@ -118,7 +118,7 @@ spec: resources: requests: storage: 2Gi - storageClassName: longhorn + storageClassName: standard storageType: Durable tls: certificates: diff --git a/docs/guides/hazelcast/configuration/hazelcast-config.md b/docs/guides/hazelcast/configuration/hazelcast-config.md index 191cffd4fc..4b19ab2921 100644 --- a/docs/guides/hazelcast/configuration/hazelcast-config.md +++ b/docs/guides/hazelcast/configuration/hazelcast-config.md @@ -113,7 +113,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard storageType: Durable deletionPolicy: WipeOut ``` diff --git a/docs/guides/kafka/autoscaler/storage/kafka-combined.md b/docs/guides/kafka/autoscaler/storage/kafka-combined.md index 261a714329..7cb9c176f8 100644 --- a/docs/guides/kafka/autoscaler/storage/kafka-combined.md +++ b/docs/guides/kafka/autoscaler/storage/kafka-combined.md @@ -118,8 +118,8 @@ $ kubectl get petset -n demo kafka-dev -o json | jq '.spec.volumeClaimTemplates[ $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 1Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-0 longhorn 40s -pvc-f068d245-718b-4561-b452-f3130bb260f6 1Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-1 longhorn 35s +pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 1Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-0 standard 40s +pvc-f068d245-718b-4561-b452-f3130bb260f6 1Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-1 standard 35s ``` You can see the petset has 1GB storage, and the capacity of all the persistent volume is also 1GB. @@ -443,8 +443,8 @@ $ kubectl get petset -n demo kafka-dev -o json | jq '.spec.volumeClaimTemplates[ "1531054080" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 1462Mi RWO Delete Bound demo/kafka-dev-data-kafka-dev-0 longhorn 30m5s -pvc-f068d245-718b-4561-b452-f3130bb260f6 1462Mi RWO Delete Bound demo/kafka-dev-data-kafka-dev-1 longhorn 30m1s +pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 1462Mi RWO Delete Bound demo/kafka-dev-data-kafka-dev-0 standard 30m5s +pvc-f068d245-718b-4561-b452-f3130bb260f6 1462Mi RWO Delete Bound demo/kafka-dev-data-kafka-dev-1 standard 30m1s ``` The above output verifies that we have successfully autoscaled the volume of the Kafka combined cluster. diff --git a/docs/guides/kafka/autoscaler/storage/kafka-topology.md b/docs/guides/kafka/autoscaler/storage/kafka-topology.md index adb007cec8..fbab12e626 100644 --- a/docs/guides/kafka/autoscaler/storage/kafka-topology.md +++ b/docs/guides/kafka/autoscaler/storage/kafka-topology.md @@ -120,10 +120,10 @@ $ kubectl get petset -n demo kafka-prod-controller -o json | jq '.spec.volumeCla "1Gi" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-128d9138-64da-4021-8a7c-7ca80823e842 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-1 longhorn 33s -pvc-27fe9102-2e7d-41e0-b77d-729a82c64e21 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-0 longhorn 51s -pvc-3bb98ba1-9cea-46ad-857f-fc843c265d57 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-0 longhorn 50s -pvc-68f86aac-33d1-423a-bc56-8a905b546db2 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-1 longhorn 32s +pvc-128d9138-64da-4021-8a7c-7ca80823e842 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-1 standard 33s +pvc-27fe9102-2e7d-41e0-b77d-729a82c64e21 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-0 standard 51s +pvc-3bb98ba1-9cea-46ad-857f-fc843c265d57 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-0 standard 50s +pvc-68f86aac-33d1-423a-bc56-8a905b546db2 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-1 standard 32s ``` You can see the petset for both broker and controller has 1GB storage, and the capacity of all the persistent volume is also 1GB. @@ -656,10 +656,10 @@ $ kubectl get petset -n demo kafka-prod-controller -o json | jq '.spec.volumeCla "2041405440" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-128d9138-64da-4021-8a7c-7ca80823e842 1948Mi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-1 longhorn 33s -pvc-27fe9102-2e7d-41e0-b77d-729a82c64e21 1948Mi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-0 longhorn 51s -pvc-3bb98ba1-9cea-46ad-857f-fc843c265d57 1948Mi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-0 longhorn 50s -pvc-68f86aac-33d1-423a-bc56-8a905b546db2 1948Mi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-1 longhorn 32s +pvc-128d9138-64da-4021-8a7c-7ca80823e842 1948Mi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-1 standard 33s +pvc-27fe9102-2e7d-41e0-b77d-729a82c64e21 1948Mi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-0 standard 51s +pvc-3bb98ba1-9cea-46ad-857f-fc843c265d57 1948Mi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-0 standard 50s +pvc-68f86aac-33d1-423a-bc56-8a905b546db2 1948Mi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-1 standard 32s ``` The above output verifies that we have successfully autoscaled the volume of the Kafka topology cluster for both broker and controller. diff --git a/docs/guides/kafka/gitops/topology.md b/docs/guides/kafka/gitops/topology.md index cc0e774f38..29657e3af9 100644 --- a/docs/guides/kafka/gitops/topology.md +++ b/docs/guides/kafka/gitops/topology.md @@ -3,7 +3,7 @@ title: Topology GitOps menu: docs_{{ .version }}: identifier: kf-gitops-topology - name: Kafka GitOps + name: GitOps Kafka parent: kf-gitops weight: 20 menu_name: docs_{{ .version }} diff --git a/docs/guides/mariadb/gitops/gitops.md b/docs/guides/mariadb/gitops/gitops.md index 832aa75edc..78c4ea3678 100644 --- a/docs/guides/mariadb/gitops/gitops.md +++ b/docs/guides/mariadb/gitops/gitops.md @@ -1,10 +1,10 @@ --- title: MariaDB GitOps -description: MariaDB GitOps Overview +description: MariaDB GitOps menu: docs_{{ .version }}: identifier: md-gitops - name: MariaDB GitOps + name: GitOps MariaDB parent: guides-mariadb-gitops weight: 20 menu_name: docs_{{ .version }} @@ -93,7 +93,7 @@ Our `gitops` operator will create an actual `MariaDB` database CR in the cluster ```bash -$ kubectl get MariaDB.gitops.kubedb.com,MariaDB.kubedb.com -n demo +$ kubectl get mariaDB.gitops.kubedb.com,mariaDB.kubedb.com -n demo NAME AGE mariadb.gitops.kubedb.com/mariadb-gitops 22m diff --git a/docs/guides/mariadb/pitr/nfs/index.md b/docs/guides/mariadb/pitr/nfs/index.md index e8f8d1f2e9..f381a4d44a 100644 --- a/docs/guides/mariadb/pitr/nfs/index.md +++ b/docs/guides/mariadb/pitr/nfs/index.md @@ -42,16 +42,16 @@ Continuous archiving involves making regular copies (or "archives") of the Maria ```bash $ kubectl get volumesnapshotclasses NAME DRIVER DELETIONPOLICY AGE -longhorn-snapshot-vsc driver.longhorn.io Delete 7d22h +standard-snapshot-vsc driver.standard.io Delete 7d22h ``` -If not any, try using `longhorn` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). +If not any, try using `standard` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). ### Install Longhorn Longhorn is a distributed block storage system for Kubernetes that manages persistent storage. Add Longhorn chart repository. -`helm repo add longhorn https://charts.longhorn.io` +`helm repo add standard https://charts.standard.io` Update local Longhorn chart information from chart repository. @@ -59,22 +59,22 @@ Update local Longhorn chart information from chart repository. Install Longhorn chart. -With Helm 2, the following command will create the longhorn-system namespace and install the Longhorn chart together. +With Helm 2, the following command will create the standard-system namespace and install the Longhorn chart together. -`helm install longhorn/longhorn --name longhorn --namespace longhorn-system` +`helm install standard/standard --name standard --namespace standard-system` -With Helm 3, the following commands will create the longhorn-system namespace first, then install the Longhorn chart. +With Helm 3, the following commands will create the standard-system namespace first, then install the Longhorn chart. ```bash -kubectl create namespace longhorn-system -helm install longhorn longhorn/longhorn --namespace longhorn-system +kubectl create namespace standard-system +helm install standard standard/standard --namespace standard-system ``` -Create volumesnapshot class using longhorn +Create volumesnapshot class using standard ```yaml kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: - name: longhorn-snapshot-vsc -driver: driver.longhorn.io + name: standard-snapshot-vsc +driver: driver.standard.io deletionPolicy: Delete parameters: type: snap @@ -82,7 +82,7 @@ parameters: ```bash $ kubectl apply -f volumesnapshotclass.yaml - volumesnapshotclass.snapshot.storage.k8s.io/longhorn-snapshot-vsc unchanged + volumesnapshotclass.snapshot.storage.k8s.io/standard-snapshot-vsc unchanged ``` ### Install CSI driver for NFS @@ -311,7 +311,7 @@ spec: driver: "VolumeSnapshotter" task: params: - volumeSnapshotClassName: "longhorn-snapshot-vsc" + volumeSnapshotClassName: "standard-snapshot-vsc" scheduler: successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 1 @@ -359,7 +359,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -416,7 +416,7 @@ mariadb-backup-manifest-backup-1726549703 BackupConfiguration mariadb-bac kubectl get volumesnapshots -n demo NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT CREATIONTIME AGE -mariadb-1726549985 true data-mariadb-0 10Gi longhorn-snapshot-vsc snapcontent-317aaac9-ae4f-438b-9763-4eb81ff828af 11m 11m +mariadb-1726549985 true data-mariadb-0 10Gi standard-snapshot-vsc snapcontent-317aaac9-ae4f-438b-9763-4eb81ff828af 11m 11m ``` ## Data Insert and Switch Binlog File @@ -516,7 +516,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mariadb/pitr/nfs/yamls/mariadb.yaml b/docs/guides/mariadb/pitr/nfs/yamls/mariadb.yaml index 8698725585..7233d58808 100644 --- a/docs/guides/mariadb/pitr/nfs/yamls/mariadb.yaml +++ b/docs/guides/mariadb/pitr/nfs/yamls/mariadb.yaml @@ -10,7 +10,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mariadb/pitr/nfs/yamls/mariadbarchiver.yaml b/docs/guides/mariadb/pitr/nfs/yamls/mariadbarchiver.yaml index 0fe91a2294..96d09c7aba 100644 --- a/docs/guides/mariadb/pitr/nfs/yamls/mariadbarchiver.yaml +++ b/docs/guides/mariadb/pitr/nfs/yamls/mariadbarchiver.yaml @@ -29,7 +29,7 @@ spec: driver: "VolumeSnapshotter" task: params: - volumeSnapshotClassName: "longhorn-snapshot-vsc" + volumeSnapshotClassName: "standard-snapshot-vsc" scheduler: successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 1 diff --git a/docs/guides/mariadb/pitr/nfs/yamls/mariadbrestore.yaml b/docs/guides/mariadb/pitr/nfs/yamls/mariadbrestore.yaml index fefb1cc6e9..af31a8db65 100644 --- a/docs/guides/mariadb/pitr/nfs/yamls/mariadbrestore.yaml +++ b/docs/guides/mariadb/pitr/nfs/yamls/mariadbrestore.yaml @@ -17,7 +17,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mariadb/pitr/nfs/yamls/voluemsnapshotclass.yaml b/docs/guides/mariadb/pitr/nfs/yamls/voluemsnapshotclass.yaml index 1a67906612..af4aa5c343 100644 --- a/docs/guides/mariadb/pitr/nfs/yamls/voluemsnapshotclass.yaml +++ b/docs/guides/mariadb/pitr/nfs/yamls/voluemsnapshotclass.yaml @@ -1,8 +1,8 @@ kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: - name: longhorn-snapshot-vsc -driver: driver.longhorn.io + name: standard-snapshot-vsc +driver: driver.standard.io deletionPolicy: Delete parameters: type: snap \ No newline at end of file diff --git a/docs/guides/mariadb/pitr/overview/index.md b/docs/guides/mariadb/pitr/overview/index.md index 0cd0f90299..59a69a19dc 100644 --- a/docs/guides/mariadb/pitr/overview/index.md +++ b/docs/guides/mariadb/pitr/overview/index.md @@ -138,7 +138,7 @@ spec: driver: "VolumeSnapshotter" task: params: - volumeSnapshotClassName: "longhorn-snapshot-vsc" + volumeSnapshotClassName: "standard-snapshot-vsc" scheduler: successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 1 @@ -181,16 +181,16 @@ stringData: ```bash $ kubectl get volumesnapshotclasses NAME DRIVER DELETIONPOLICY AGE -longhorn-snapshot-vsc driver.longhorn.io Delete 7d22h +standard-snapshot-vsc driver.standard.io Delete 7d22h ``` -If not any, try using `longhorn` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). +If not any, try using `standard` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). ```yaml kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: - name: longhorn-snapshot-vsc -driver: driver.longhorn.io + name: standard-snapshot-vsc +driver: driver.standard.io deletionPolicy: Delete parameters: type: snap @@ -198,10 +198,10 @@ parameters: ``` ```bash -$ helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace +$ helm install standard standard/standard --namespace standard-system --create-namespace $ kubectl apply -f volumesnapshotclass.yaml - volumesnapshotclass.snapshot.storage.k8s.io/longhorn-snapshot-vsc unchanged + volumesnapshotclass.snapshot.storage.k8s.io/standard-snapshot-vsc unchanged ``` # Deploy MariaDB @@ -220,7 +220,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -277,7 +277,7 @@ mariadb-backup-manifest-backup-1726549703 BackupConfiguration mariadb-bac kubectl get volumesnapshots -n demo NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT CREATIONTIME AGE -mariadb-1726549985 true data-mariadb-0 10Gi longhorn-snapshot-vsc snapcontent-317aaac9-ae4f-438b-9763-4eb81ff828af 11m 11m +mariadb-1726549985 true data-mariadb-0 10Gi standard-snapshot-vsc snapcontent-317aaac9-ae4f-438b-9763-4eb81ff828af 11m 11m ``` ## Data Insert and Switch Binlog File @@ -377,7 +377,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mariadb/pitr/overview/yamls/mariadb.yaml b/docs/guides/mariadb/pitr/overview/yamls/mariadb.yaml index 8698725585..7233d58808 100644 --- a/docs/guides/mariadb/pitr/overview/yamls/mariadb.yaml +++ b/docs/guides/mariadb/pitr/overview/yamls/mariadb.yaml @@ -10,7 +10,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mariadb/pitr/overview/yamls/mariadbarchiver.yaml b/docs/guides/mariadb/pitr/overview/yamls/mariadbarchiver.yaml index 117819fec5..94adf7defb 100644 --- a/docs/guides/mariadb/pitr/overview/yamls/mariadbarchiver.yaml +++ b/docs/guides/mariadb/pitr/overview/yamls/mariadbarchiver.yaml @@ -24,7 +24,7 @@ spec: driver: "VolumeSnapshotter" task: params: - volumeSnapshotClassName: "longhorn-snapshot-vsc" + volumeSnapshotClassName: "standard-snapshot-vsc" scheduler: successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 1 diff --git a/docs/guides/mariadb/pitr/overview/yamls/mariadbrestore.yaml b/docs/guides/mariadb/pitr/overview/yamls/mariadbrestore.yaml index fefb1cc6e9..af31a8db65 100644 --- a/docs/guides/mariadb/pitr/overview/yamls/mariadbrestore.yaml +++ b/docs/guides/mariadb/pitr/overview/yamls/mariadbrestore.yaml @@ -17,7 +17,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mariadb/pitr/overview/yamls/voluemsnapshotclass.yaml b/docs/guides/mariadb/pitr/overview/yamls/voluemsnapshotclass.yaml index 1a67906612..af4aa5c343 100644 --- a/docs/guides/mariadb/pitr/overview/yamls/voluemsnapshotclass.yaml +++ b/docs/guides/mariadb/pitr/overview/yamls/voluemsnapshotclass.yaml @@ -1,8 +1,8 @@ kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: - name: longhorn-snapshot-vsc -driver: driver.longhorn.io + name: standard-snapshot-vsc +driver: driver.standard.io deletionPolicy: Delete parameters: type: snap \ No newline at end of file diff --git a/docs/guides/mariadb/volume-expansion/maxscale.md b/docs/guides/mariadb/volume-expansion/maxscale.md index f61bb82e62..61d55c966f 100644 --- a/docs/guides/mariadb/volume-expansion/maxscale.md +++ b/docs/guides/mariadb/volume-expansion/maxscale.md @@ -49,11 +49,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path rancher.io/local-path Delete WaitForFirstConsumer false 46h -longhorn driver.longhorn.io Delete Immediate true 2m27s -longhorn-static driver.longhorn.io Delete Immediate true 2m24s +standard driver.standard.io Delete Immediate true 2m27s +standard-static driver.standard.io Delete Immediate true 2m24s ``` -We can see from the output that `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. You can install longhorn from [here](https://longhorn.io/docs/1.9.0/deploy/install/install-with-kubectl/). +We can see from the output that `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. You can install standard from [here](https://standard.io/docs/1.9.0/deploy/install/install-with-kubectl/). Now, we are going to deploy a `MariaDB` database with `MaxScale` in replication mode. @@ -78,7 +78,7 @@ spec: enableUI: true storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -86,7 +86,7 @@ spec: storage: 50Mi storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -118,12 +118,12 @@ $ kubectl get petset -n demo md-replication-mx -o json | jq '.spec.volumeClaimTe $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-27e4f4b2-289b-44bb-97a2-729d9420f668 1Gi RWO Delete Bound demo/data-md-replication-2 longhorn 3m48s -pvc-2df9a141-5d32-4c92-b0ec-a8043975c2ae 1Gi RWO Delete Bound demo/data-md-replication-1 longhorn 3m48s -pvc-7609183e-f9a5-4177-b260-0d24796fb04c 1Gi RWO Delete Bound demo/data-md-replication-0 longhorn 3m48s -pvc-96449ed7-305e-4857-a2b6-6eda33c99207 50Mi RWO Delete Bound demo/data-md-replication-mx-2 longhorn 3m51s -pvc-c1424029-4a52-4ff4-9888-14d5e7b4fb61 50Mi RWO Delete Bound demo/data-md-replication-mx-0 longhorn 3m51s -pvc-d12d301c-58bd-4c59-bd5a-d9167df2b53d 50Mi RWO Delete Bound demo/data-md-replication-mx-1 longhorn 3m51s +pvc-27e4f4b2-289b-44bb-97a2-729d9420f668 1Gi RWO Delete Bound demo/data-md-replication-2 standard 3m48s +pvc-2df9a141-5d32-4c92-b0ec-a8043975c2ae 1Gi RWO Delete Bound demo/data-md-replication-1 standard 3m48s +pvc-7609183e-f9a5-4177-b260-0d24796fb04c 1Gi RWO Delete Bound demo/data-md-replication-0 standard 3m48s +pvc-96449ed7-305e-4857-a2b6-6eda33c99207 50Mi RWO Delete Bound demo/data-md-replication-mx-2 standard 3m51s +pvc-c1424029-4a52-4ff4-9888-14d5e7b4fb61 50Mi RWO Delete Bound demo/data-md-replication-mx-0 standard 3m51s +pvc-d12d301c-58bd-4c59-bd5a-d9167df2b53d 50Mi RWO Delete Bound demo/data-md-replication-mx-1 standard 3m51s ``` @@ -157,7 +157,7 @@ spec: Here, - `spec.type` specifies that we are performing `VolumeExpansion` on our database. - `spec.databaseRef.name` specifies that we are performing volume expansion operation on `md-replication` database. -- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `longhorn` supports `Online` volume expansion. +- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `standard` supports `Online` volume expansion. - `spec.volumeExpansion.maxscale` specifies the desired volume size of maxscale server. > **Note:** If the Storageclass you are using doesn't support `Online` Volume Expansion, Try offline volume expansion by using `spec.volumeExpansion.mode:"Offline"`. The pods need to be restarted during offline volume expansion. @@ -281,12 +281,12 @@ $ kubectl get petset -n demo md-replication-mx -o json | jq '.spec.volumeClaimTe $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-27e4f4b2-289b-44bb-97a2-729d9420f668 1Gi RWO Delete Bound demo/data-md-replication-2 longhorn 34m -pvc-2df9a141-5d32-4c92-b0ec-a8043975c2ae 1Gi RWO Delete Bound demo/data-md-replication-1 longhorn 34m -pvc-7609183e-f9a5-4177-b260-0d24796fb04c 1Gi RWO Delete Bound demo/data-md-replication-0 longhorn 34m -pvc-96449ed7-305e-4857-a2b6-6eda33c99207 100Mi RWO Delete Bound demo/data-md-replication-mx-2 longhorn 34m -pvc-c1424029-4a52-4ff4-9888-14d5e7b4fb61 100Mi RWO Delete Bound demo/data-md-replication-mx-0 longhorn 34m -pvc-d12d301c-58bd-4c59-bd5a-d9167df2b53d 100Mi RWO Delete Bound demo/data-md-replication-mx-1 longhorn 34m +pvc-27e4f4b2-289b-44bb-97a2-729d9420f668 1Gi RWO Delete Bound demo/data-md-replication-2 standard 34m +pvc-2df9a141-5d32-4c92-b0ec-a8043975c2ae 1Gi RWO Delete Bound demo/data-md-replication-1 standard 34m +pvc-7609183e-f9a5-4177-b260-0d24796fb04c 1Gi RWO Delete Bound demo/data-md-replication-0 standard 34m +pvc-96449ed7-305e-4857-a2b6-6eda33c99207 100Mi RWO Delete Bound demo/data-md-replication-mx-2 standard 34m +pvc-c1424029-4a52-4ff4-9888-14d5e7b4fb61 100Mi RWO Delete Bound demo/data-md-replication-mx-0 standard 34m +pvc-d12d301c-58bd-4c59-bd5a-d9167df2b53d 100Mi RWO Delete Bound demo/data-md-replication-mx-1 standard 34m ``` diff --git a/docs/guides/mongodb/gitops/gitops.md b/docs/guides/mongodb/gitops/gitops.md index dfa700e5be..9be8164cdd 100644 --- a/docs/guides/mongodb/gitops/gitops.md +++ b/docs/guides/mongodb/gitops/gitops.md @@ -183,7 +183,7 @@ Resource Requests and Limits are updated from `800m` to `1000m` CPU and `2Gi` Me Now, `gitops` operator will detect the resource changes and create a `MongoDBOpsRequest` to update the `MongoDB` database. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$kubectl get mg,MongoDB,mgops -n demo +$kubectl get mg,mongodb,mgops -n demo NAME VERSION STATUS AGE mongodb.kubedb.com/mg-gitops 8.0.10 Ready 13m @@ -246,7 +246,7 @@ Update the `replicas` to `3`. Commit the changes and push to your Git repository Now, `gitops` operator will detect the replica changes and create a `HorizontalScaling` MongoDBOpsRequest to update the `MongoDB` database replicas. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get mg,MongoDB,mgops -n demo +$ kubectl get mg,mongodb,mgops -n demo NAME VERSION STATUS AGE mongodb.kubedb.com/mg-gitops 8.0.10 Ready 18m @@ -308,7 +308,7 @@ Update the `storage.resources.requests.storage` to `2Gi`. Commit the changes and Now, `gitops` operator will detect the volume changes and create a `VolumeExpansion` MongoDBOpsRequest to update the `MongoDB` database volume. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get mg,MongoDB,mgops -n demo +$ kubectl get mg,mongodb,mgops -n demo NAME VERSION STATUS AGE mongodb.kubedb.com/mg-gitops 8.0.10 Ready 21m @@ -388,7 +388,7 @@ Commit the changes and push to your Git repository. Your repository is synced wi Now, `gitops` operator will detect the configuration changes and create a `Reconfigure` MongoDBOpsRequest to update the `MongoDB` database configuration. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get mg,MongoDB,mgops -n demo +$ kubectl get mg,mongodb,mgops -n demo NAME VERSION STATUS AGE mongodb.kubedb.com/mg-gitops 8.0.10 Ready 32m @@ -462,7 +462,7 @@ Add the secret name in `authSecret` field. Commit the changes and push to your G Now, `gitops` operator will detect the auth changes and create a `RotateAuth` MongoDBOpsRequest to update the `MongoDB` database auth. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get mg,MongoDB,mgops -n demo +$ kubectl get mg,mongodb,mgops -n demo NAME VERSION STATUS AGE mongodb.kubedb.com/mg-gitops 8.0.10 Ready 41m @@ -520,7 +520,7 @@ Update the `version` field to `8.0.17`. Commit the changes and push to your Git Now, `gitops` operator will detect the version changes and create a `VersionUpdate` MongoDBOpsRequest to update the `MongoDB` database version. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get mg,MongoDB,mgops -n demo +$ kubectl get mg,mongodb,mgops -n demo NAME VERSION STATUS AGE mongodb.kubedb.com/mg-gitops 8.0.17 Ready 46m @@ -600,7 +600,7 @@ Add `monitor` field in the spec. Commit the changes and push to your Git reposit Now, `gitops` operator will detect the monitoring changes and create a `Restart` MongoDBOpsRequest to add the `MongoDB` database monitoring. List the resources created by `gitops` operator in the `demo` namespace. ```bash -$ kubectl get mg,MongoDB,mgops -n demo +$ kubectl get mg,mongodb,mgops -n demo NAME VERSION STATUS AGE mongodb.kubedb.com/mg-gitops 8.0.17 Ready 52m @@ -630,6 +630,130 @@ There are some other fields that will trigger `Restart` ops request. - `.spec.sslMode` etc. +### TLS configuration + +We are going to create an example `Issuer` that will be used throughout the duration of this tutorial to enable SSL/TLS in MongoDB. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating you ca certificates using openssl. + +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=mongo/O=kubedb" +``` + +- Now create a ca-secret using the certificate files you have just generated. + +```bash +kubectl create secret tls mongo-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +``` + +Now, create an `Issuer` using the `ca-secret` you have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mongo-ca-issuer + namespace: demo +spec: + ca: + secretName: mongo-ca +``` + +Apply the `YAML` file: + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mongodb/tls/issuer.yaml +issuer.cert-manager.io/mongo-ca-issuer created +``` + +Let's add that to our `kubedb /mg-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── mg-configuration.yaml +│ ├── mg-issuer.yaml +│ └── mongodb.yaml +1 directories, 3 files +``` + +Update the `mongodb.yaml` with the following, + +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MongoDB +metadata: + name: mg-gitops + namespace: demo +spec: + version: "8.0.17" + replicaSet: + name: "replicaset" + replicas: 3 + podTemplate: + spec: + containers: + - name: mongodb + resources: + limits: + memory: 2Gi + requests: + cpu: 1000m + memory: 2Gi + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: mg-custom-config + authSecret: + kind: Secret + name: mgauth + monitor: + agent: prometheus.io/operator + prometheus: + serviceMonitor: + labels: + release: prometheus + interval: 10s + tls: + issuerRef: + name: mg-issuer + kind: Issuer + apiGroup: "cert-manager.io" + certificates: + - alias: client + subject: + organizations: + - mongo + organizationalUnits: + - client +``` +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `MongoDB` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `MongoDB` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get mg,mongodb,mgops -n demo +NAME VERSION STATUS AGE +mongodb.kubedb.com/mg-gitops 8.0.17 Ready 20m + +NAME AGE +mongodb.gitops.kubedb.com/mg-gitops 20m + +NAME TYPE STATUS AGE +mongodbopsrequest.ops.kubedb.com/mg-gitops-reconfiguretls-2pzvw4 ReconfigureTLS Successful 10m +``` + + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for MongoDB. + ## Next Steps - Learn MongoDB Scaling diff --git a/docs/guides/mongodb/pitr/pitr.md b/docs/guides/mongodb/pitr/pitr.md index 766a0132e8..4234d17b0d 100644 --- a/docs/guides/mongodb/pitr/pitr.md +++ b/docs/guides/mongodb/pitr/pitr.md @@ -124,16 +124,16 @@ retentionpolicy.storage.kubestash.com/mongodb-retention-policy created ```bash kubectl get volumesnapshotclasses NAME DRIVER DELETIONPOLICY AGE -longhorn-snapshot-vsc driver.longhorn.io Delete 7d22h +standard-snapshot-vsc driver.standard.io Delete 7d22h ``` -If not any, try using `longhorn` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). +If not any, try using `standard` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). ```bash -$ helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace +$ helm install standard standard/standard --namespace standard-system --create-namespace ... ... - kubectl get pod -n longhorn-system + kubectl get pod -n standard-system ```` @@ -141,8 +141,8 @@ $ helm install longhorn longhorn/longhorn --namespace longhorn-system --create-n kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: - name: longhorn-snapshot-vsc -driver: driver.longhorn.io + name: standard-snapshot-vsc +driver: driver.standard.io deletionPolicy: Delete parameters: type: snap diff --git a/docs/guides/mssqlserver/autoscaler/compute/cluster.md b/docs/guides/mssqlserver/autoscaler/compute/cluster.md index bfc19f8c4f..366f248730 100644 --- a/docs/guides/mssqlserver/autoscaler/compute/cluster.md +++ b/docs/guides/mssqlserver/autoscaler/compute/cluster.md @@ -120,7 +120,7 @@ spec: memory: "1.6Gi" storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mssqlserver/autoscaler/storage/cluster.md b/docs/guides/mssqlserver/autoscaler/storage/cluster.md index b48551aa4f..8cc60a1b21 100644 --- a/docs/guides/mssqlserver/autoscaler/storage/cluster.md +++ b/docs/guides/mssqlserver/autoscaler/storage/cluster.md @@ -51,11 +51,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 4d21h -longhorn (default) driver.longhorn.io Delete Immediate true 2d20h -longhorn-static driver.longhorn.io Delete Immediate true 2d20h +standard (default) driver.standard.io Delete Immediate true 2d20h +standard-static driver.standard.io Delete Immediate true 2d20h ``` -We can see from the output the `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. +We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. Now, we are going to deploy a `MSSQLServer` cluster using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerAutoscaler` to set up autoscaling. @@ -138,7 +138,7 @@ spec: memory: "1.6Gi" storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -170,9 +170,9 @@ $ kubectl get petset -n demo mssqlserver-ag-cluster -o json | jq '.spec.volumeCl $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-1497dd6d-9cbd-467a-8e0c-c3963ce09e1b 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 longhorn 8m -pvc-37a7bc8d-2c04-4eb4-8e53-e610fd1daaf5 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 longhorn 8m -pvc-817866af-5277-4d51-8d81-434e8ec1c442 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 longhorn 8m +pvc-1497dd6d-9cbd-467a-8e0c-c3963ce09e1b 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 standard 8m +pvc-37a7bc8d-2c04-4eb4-8e53-e610fd1daaf5 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 standard 8m +pvc-817866af-5277-4d51-8d81-434e8ec1c442 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 standard 8m ``` You can see the petset has 1GB storage, and the capacity of all the persistent volume is also 1GB. @@ -211,7 +211,7 @@ Here, - `spec.storage.mssqlserver.trigger` specifies that storage autoscaling is enabled for this database. - `spec.storage.mssqlserver.usageThreshold` specifies storage usage threshold, if storage usage exceeds `60%` then storage autoscaling will be triggered. - `spec.storage.mssqlserver.scalingThreshold` specifies the scaling threshold. Storage will be scaled to `50%` of the current amount. -- `spec.storage.mssqlserver.expansionMode` specifies the expansion mode of volume expansion `MSSQLServerOpsRequest` created by `MSSQLServerAutoscaler`, `longhorn` supports offline volume expansion so here `expansionMode` is set as "Offline". +- `spec.storage.mssqlserver.expansionMode` specifies the expansion mode of volume expansion `MSSQLServerOpsRequest` created by `MSSQLServerAutoscaler`, `standard` supports offline volume expansion so here `expansionMode` is set as "Offline". Let's create the `MSSQLServerAutoscaler` CR we have shown above, @@ -270,7 +270,7 @@ Lets exec into the database pod and fill the database volume(`/var/opt/mssql/`) $ kubectl exec -it -n demo mssqlserver-ag-cluster-0 -c mssql -- bash mssql@mssqlserver-ag-cluster-0:/$ df -h /var/opt/mssql Filesystem Size Used Avail Use% Mounted on -/dev/longhorn/pvc-37a7bc8d-2c04-4eb4-8e53-e610fd1daaf5 974M 274M 685M 29% /var/opt/mssql +/dev/standard/pvc-37a7bc8d-2c04-4eb4-8e53-e610fd1daaf5 974M 274M 685M 29% /var/opt/mssql mssql@mssqlserver-ag-cluster-0:/$ dd if=/dev/zero of=/var/opt/mssql/file.img bs=120M count=5 5+0 records in @@ -278,7 +278,7 @@ mssql@mssqlserver-ag-cluster-0:/$ dd if=/dev/zero of=/var/opt/mssql/file.img bs= 629145600 bytes (629 MB, 600 MiB) copied, 6.09315 s, 103 MB/s mssql@mssqlserver-ag-cluster-0:/$ df -h /var/opt/mssql Filesystem Size Used Avail Use% Mounted on -/dev/longhorn/pvc-37a7bc8d-2c04-4eb4-8e53-e610fd1daaf5 974M 874M 85M 92% /var/opt/mssql +/dev/standard/pvc-37a7bc8d-2c04-4eb4-8e53-e610fd1daaf5 974M 874M 85M 92% /var/opt/mssql ``` So, from the above output we can see that the storage usage is 92%, which exceeded the `usageThreshold` 60%. @@ -432,9 +432,9 @@ $ kubectl get petset -n demo mssqlserver-ag-cluster -o json | jq '.spec.volumeCl "1531054080" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-2ff83356-1bbc-44ab-99f1-025e3690a471 1462Mi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 longhorn 15m -pvc-a5cc0ae9-2c8d-456c-ace2-fc4fafc6784f 1462Mi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 longhorn 16m -pvc-e8ab47a4-17a6-45fb-9f39-e71a03498ab5 1462Mi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 longhorn 16m +pvc-2ff83356-1bbc-44ab-99f1-025e3690a471 1462Mi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 standard 15m +pvc-a5cc0ae9-2c8d-456c-ace2-fc4fafc6784f 1462Mi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 standard 16m +pvc-e8ab47a4-17a6-45fb-9f39-e71a03498ab5 1462Mi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 standard 16m ``` The above output verifies that we have successfully autoscaled the volume of the MSSQLServer cluster database. diff --git a/docs/guides/mssqlserver/volume-expansion/ag_cluster.md b/docs/guides/mssqlserver/volume-expansion/ag_cluster.md index fc8ba8a0fe..c74f72b43f 100644 --- a/docs/guides/mssqlserver/volume-expansion/ag_cluster.md +++ b/docs/guides/mssqlserver/volume-expansion/ag_cluster.md @@ -50,11 +50,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 2d -longhorn (default) driver.longhorn.io Delete Immediate true 3m25s -longhorn-static driver.longhorn.io Delete Immediate true 3m19s +standard (default) driver.standard.io Delete Immediate true 3m25s +standard-static driver.standard.io Delete Immediate true 3m19s ``` -We can see from the output that `longhorn (default)` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. +We can see from the output that `standard (default)` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. Now, we are going to deploy a `MSSQLServer` in `AvailabilityGroup` Mode with version `2022-cu12`. @@ -129,7 +129,7 @@ spec: value: Evaluation # Change it storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -161,9 +161,9 @@ $ kubectl get petset -n demo mssqlserver-ag-cluster -o json | jq '.spec.volumeCl $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-059f186a-01a4-441d-85f1-95aef34934be 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 longhorn 82s -pvc-87bea35f-4a55-4aa5-903a-e4da9f548241 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 longhorn 52s -pvc-9d1c3c9c-f928-4fa2-a2e1-becf2ab9c564 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 longhorn 35s +pvc-059f186a-01a4-441d-85f1-95aef34934be 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 standard 82s +pvc-87bea35f-4a55-4aa5-903a-e4da9f548241 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 standard 52s +pvc-9d1c3c9c-f928-4fa2-a2e1-becf2ab9c564 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 standard 35s ``` You can see the petset has 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -198,7 +198,7 @@ Here, - `spec.databaseRef.name` specifies that we are performing volume expansion operation on `mssqlserver-ag-cluster` database. - `spec.type` specifies that we are performing `VolumeExpansion` on our database. - `spec.volumeExpansion.mssqlserver` specifies the desired volume size. -- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `longhorn` supports `Offline` volume expansion. +- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `standard` supports `Offline` volume expansion. > **Note:** If the Storageclass you are using support `Online` Volume Expansion, Try Online volume expansion by using `spec.volumeExpansion.mode:"Online"`. @@ -234,9 +234,9 @@ $ kubectl get petset -n demo mssqlserver-ag-cluster -o json | jq '.spec.volumeCl $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-059f186a-01a4-441d-85f1-95aef34934be 2Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 longhorn 29m -pvc-87bea35f-4a55-4aa5-903a-e4da9f548241 2Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 longhorn 29m -pvc-9d1c3c9c-f928-4fa2-a2e1-becf2ab9c564 2Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 longhorn 29m +pvc-059f186a-01a4-441d-85f1-95aef34934be 2Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 standard 29m +pvc-87bea35f-4a55-4aa5-903a-e4da9f548241 2Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 standard 29m +pvc-9d1c3c9c-f928-4fa2-a2e1-becf2ab9c564 2Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 standard 29m ``` The above output verifies that we have successfully expanded the volume of the MSSQLServer database. diff --git a/docs/guides/mssqlserver/volume-expansion/standalone.md b/docs/guides/mssqlserver/volume-expansion/standalone.md index 8cc2596a8a..fefd1dee46 100644 --- a/docs/guides/mssqlserver/volume-expansion/standalone.md +++ b/docs/guides/mssqlserver/volume-expansion/standalone.md @@ -50,11 +50,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 2d -longhorn (default) driver.longhorn.io Delete Immediate true 3m25s -longhorn-static driver.longhorn.io Delete Immediate true 3m19s +standard (default) driver.standard.io Delete Immediate true 3m25s +standard-static driver.standard.io Delete Immediate true 3m19s ``` -We can see from the output that `longhorn (default)` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. +We can see from the output that `standard (default)` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. Now, we are going to deploy a `MSSQLServer` in `AvailabilityGroup` Mode with version `2022-cu12`. @@ -129,7 +129,7 @@ spec: limits: memory: "2Gi" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -161,7 +161,7 @@ $ kubectl get petset -n demo mssql-standalone -o json | jq '.spec.volumeClaimTem $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-7e7ed996-b682-4d84-8450-4c06fe92b11f 1Gi RWO Delete Bound demo/data-mssql-standalone-0 longhorn 5m29s +pvc-7e7ed996-b682-4d84-8450-4c06fe92b11f 1Gi RWO Delete Bound demo/data-mssql-standalone-0 standard 5m29s ``` You can see the petset has 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -196,7 +196,7 @@ Here, - `spec.databaseRef.name` specifies that we are performing volume expansion operation on `mssql-standalone` database. - `spec.type` specifies that we are performing `VolumeExpansion` on our database. - `spec.volumeExpansion.mssqlserver` specifies the desired volume size. -- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `longhorn` supports `Offline` volume expansion. +- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `standard` supports `Offline` volume expansion. > **Note:** If the Storageclass you are using support `Online` Volume Expansion, Try Online volume expansion by using `spec.volumeExpansion.mode:"Online"`. @@ -350,7 +350,7 @@ $ kubectl get petset -n demo mssql-standalone -o json | jq '.spec.volumeClaimTem $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-7e7ed996-b682-4d84-8450-4c06fe92b11f 2Gi RWO Delete Bound demo/data-mssql-standalone-0 longhorn 26m +pvc-7e7ed996-b682-4d84-8450-4c06fe92b11f 2Gi RWO Delete Bound demo/data-mssql-standalone-0 standard 26m ``` The above output verifies that we have successfully expanded the volume of the MSSQLServer Standalone database. diff --git a/docs/guides/mysql/migration/storageMigration.md b/docs/guides/mysql/migration/storageMigration.md index 05cca4d886..0d8877cfa9 100644 --- a/docs/guides/mysql/migration/storageMigration.md +++ b/docs/guides/mysql/migration/storageMigration.md @@ -43,12 +43,12 @@ At first verify that your cluster has at least two `StorageClass`. Let's check, ➤ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 12d -longhorn driver.longhorn.io Delete Immediate true 12d -longhorn-custom driver.longhorn.io Delete WaitForFirstConsumer true 2d20h -longhorn-static driver.longhorn.io Delete Immediate true 12d +standard driver.standard.io Delete Immediate true 12d +standard-custom driver.standard.io Delete WaitForFirstConsumer true 2d20h +standard-static driver.standard.io Delete Immediate true 12d ``` From the above output we can see that we have more than two `StorageClass` resources. We will now deploy a `MySQL` database using `local-path` StorageClass and insert some data into it. -After that, we will apply `MySQLOpsRequest` to migrate StorageClass from `local-path` to `longhorn-custom`. +After that, we will apply `MySQLOpsRequest` to migrate StorageClass from `local-path` to `standard-custom`. > Both the old and new PVCs should be on the same node. Therefore, the new StorageClass `VOLUMEBINDINGMODE` should be `WaitForFirstConsumer` if the old one uses `WaitForFirstConsumer`. If the old one uses `Immediate` any mode is allowed. @@ -189,7 +189,7 @@ spec: databaseRef: name: sample-mysql migration: - storageClassName: longhorn-custom + storageClassName: standard-custom oldPVReclaimPolicy: Delete ``` @@ -227,12 +227,12 @@ We can see from the above output that the `MySQLOpsRequest` has succeeded. Let's ``` bash $ kubectl get pvc -n demo NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-sample-mysql-0 Bound pvc-64cca3c6-85aa-426f-abc3-b300ecfe365a 1Gi RWO longhorn-custom 21m -data-sample-mysql-1 Bound pvc-1de36b06-8e32-4e9a-a01b-3b6d7c618688 1Gi RWO longhorn-custom 21m -data-sample-mysql-2 Bound pvc-a75bd538-8a71-4f62-8d38-3f4e42ffb225 1Gi RWO longhorn-custom 21m +data-sample-mysql-0 Bound pvc-64cca3c6-85aa-426f-abc3-b300ecfe365a 1Gi RWO standard-custom 21m +data-sample-mysql-1 Bound pvc-1de36b06-8e32-4e9a-a01b-3b6d7c618688 1Gi RWO standard-custom 21m +data-sample-mysql-2 Bound pvc-a75bd538-8a71-4f62-8d38-3f4e42ffb225 1Gi RWO standard-custom 21m ``` -The `PersistentVolumeClaim` StorageClass has changed to `longhorn-custom`. Now, we will verify that the data remains intact after the `StorageMigration` operation. Let's exec into one of the `MySQL` pod and perform read query. +The `PersistentVolumeClaim` StorageClass has changed to `standard-custom`. Now, we will verify that the data remains intact after the `StorageMigration` operation. Let's exec into one of the `MySQL` pod and perform read query. ```bash $ kubectl exec -it -n demo sample-mysql-0 -- bash diff --git a/docs/guides/mysql/pitr/volumesnapshot/archiver.md b/docs/guides/mysql/pitr/volumesnapshot/archiver.md index 897e82dd9a..221f6ee795 100644 --- a/docs/guides/mysql/pitr/volumesnapshot/archiver.md +++ b/docs/guides/mysql/pitr/volumesnapshot/archiver.md @@ -138,7 +138,7 @@ spec: driver: "VolumeSnapshotter" task: params: - volumeSnapshotClassName: "longhorn-snapshot-vsc" + volumeSnapshotClassName: "standard-snapshot-vsc" scheduler: successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 1 @@ -184,16 +184,16 @@ stringData: ```bash $ kubectl get volumesnapshotclasses NAME DRIVER DELETIONPOLICY AGE -longhorn-snapshot-vsc driver.longhorn.io Delete 7d22h +standard-snapshot-vsc driver.standard.io Delete 7d22h ``` -If not any, try using `longhorn` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). +If not any, try using `standard` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). ```yaml kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: - name: longhorn-snapshot-vsc -driver: driver.longhorn.io + name: standard-snapshot-vsc +driver: driver.standard.io deletionPolicy: Delete parameters: type: snap @@ -201,13 +201,13 @@ parameters: ``` ```bash -$ helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace +$ helm install standard standard/standard --namespace standard-system --create-namespace $ kubectl apply -f volumesnapshotclass.yaml - volumesnapshotclass.snapshot.storage.k8s.io/longhorn-snapshot-vsc unchanged + volumesnapshotclass.snapshot.storage.k8s.io/standard-snapshot-vsc unchanged ``` -Note: Ensure that the VolumeSnapshotClass is provisioned with the same storage class driver used for provisioning your MySQL database. In our case, we are using the `longhorn` storageclass as our database provisioner, with the driver set to `driver.longhorn.io`. +Note: Ensure that the VolumeSnapshotClass is provisioned with the same storage class driver used for provisioning your MySQL database. In our case, we are using the `standard` storageclass as our database provisioner, with the driver set to `driver.standard.io`. # Deploy MySQL We are now ready with the setup for continuous MySQL archiving. We will deploy a MySQL object that references the MySQL archiver object. @@ -227,7 +227,7 @@ spec: mode: GroupReplication storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -293,7 +293,7 @@ mysql-archiver-manifest-backup-1733206003 BackupConfiguration mysql-backu kubectl get volumesnapshots -n demo NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT CREATIONTIME AGE -mysql-1702388096 true data-mysql-1 1Gi longhorn-snapshot-vsc snapcontent-735e97ad-1dfa-4b70-b416-33f7270d792c 2m5s 2m5s +mysql-1702388096 true data-mysql-1 1Gi standard-snapshot-vsc snapcontent-735e97ad-1dfa-4b70-b416-33f7270d792c 2m5s 2m5s $ kubectl get repository.storage.kubestash.com -n demo NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE @@ -428,7 +428,7 @@ spec: mode: GroupReplication storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mysql/pitr/volumesnapshot/yamls/mysql-restore.yaml b/docs/guides/mysql/pitr/volumesnapshot/yamls/mysql-restore.yaml index fce3703974..41676f29a9 100644 --- a/docs/guides/mysql/pitr/volumesnapshot/yamls/mysql-restore.yaml +++ b/docs/guides/mysql/pitr/volumesnapshot/yamls/mysql-restore.yaml @@ -20,7 +20,7 @@ spec: mode: GroupReplication storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mysql/pitr/volumesnapshot/yamls/mysql.yaml b/docs/guides/mysql/pitr/volumesnapshot/yamls/mysql.yaml index 06fe8780e9..0ef5fdc1d6 100644 --- a/docs/guides/mysql/pitr/volumesnapshot/yamls/mysql.yaml +++ b/docs/guides/mysql/pitr/volumesnapshot/yamls/mysql.yaml @@ -12,7 +12,7 @@ spec: mode: GroupReplication storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mysql/pitr/volumesnapshot/yamls/mysqlarchiver.yaml b/docs/guides/mysql/pitr/volumesnapshot/yamls/mysqlarchiver.yaml index e12cd519bd..3a264518aa 100644 --- a/docs/guides/mysql/pitr/volumesnapshot/yamls/mysqlarchiver.yaml +++ b/docs/guides/mysql/pitr/volumesnapshot/yamls/mysqlarchiver.yaml @@ -24,7 +24,7 @@ spec: driver: "VolumeSnapshotter" task: params: - volumeSnapshotClassName: "longhorn-snapshot-vsc" + volumeSnapshotClassName: "standard-snapshot-vsc" scheduler: successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 1 diff --git a/docs/guides/mysql/pitr/volumesnapshot/yamls/voluemsnapshotclass.yaml b/docs/guides/mysql/pitr/volumesnapshot/yamls/voluemsnapshotclass.yaml index 1a67906612..af4aa5c343 100644 --- a/docs/guides/mysql/pitr/volumesnapshot/yamls/voluemsnapshotclass.yaml +++ b/docs/guides/mysql/pitr/volumesnapshot/yamls/voluemsnapshotclass.yaml @@ -1,8 +1,8 @@ kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: - name: longhorn-snapshot-vsc -driver: driver.longhorn.io + name: standard-snapshot-vsc +driver: driver.standard.io deletionPolicy: Delete parameters: type: snap \ No newline at end of file diff --git a/docs/guides/postgres/migration/storageMigration.md b/docs/guides/postgres/migration/storageMigration.md index e3fc494816..c42c80ee65 100644 --- a/docs/guides/postgres/migration/storageMigration.md +++ b/docs/guides/postgres/migration/storageMigration.md @@ -40,12 +40,12 @@ At first verify that your cluster has at least two `StorageClass`. Let's check, ➤ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 12d -longhorn driver.longhorn.io Delete Immediate true 12d -longhorn-custom driver.longhorn.io Delete WaitForFirstConsumer true 2d20h -longhorn-static driver.longhorn.io Delete Immediate true 12d +standard driver.standard.io Delete Immediate true 12d +standard-custom driver.standard.io Delete WaitForFirstConsumer true 2d20h +standard-static driver.standard.io Delete Immediate true 12d ``` From the above output we can see that we have more than two `StorageClass` resources. We will now deploy a `PostgreSQL` database using `local-path` StorageClass and insert some data into it. -After that, we will apply `PostgresOpsRequest` to migrate StorageClass from `local-path` to `longhorn-custom`. +After that, we will apply `PostgresOpsRequest` to migrate StorageClass from `local-path` to `standard-custom`. > Both the old and new PVCs should be on the same node. Therefore, the new StorageClass `VOLUMEBINDINGMODE` should be `WaitForFirstConsumer` if the old one uses `WaitForFirstConsumer`. If the old one uses `Immediate` any mode is allowed. @@ -129,7 +129,7 @@ spec: databaseRef: name: sample-postgres migration: - storageClassName: longhorn-custom + storageClassName: standard-custom oldPVReclaimPolicy: Delete ``` @@ -168,12 +168,12 @@ We can see from the above output that the `PostgresOpsRequest` has succeeded. Le ``` bash $ kubectl get pvc -n demo NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-sample-postgres-0 Bound pvc-64cca3c6-85aa-426f-abc3-b300ecfe365a 3Gi RWO longhorn-custom 21m -data-sample-postgres-1 Bound pvc-1de36b06-8e32-4e9a-a01b-3b6d7c618688 3Gi RWO longhorn-custom 21m -data-sample-postgres-2 Bound pvc-a75bd538-8a71-4f62-8d38-3f4e42ffb225 3Gi RWO longhorn-custom 21m +data-sample-postgres-0 Bound pvc-64cca3c6-85aa-426f-abc3-b300ecfe365a 3Gi RWO standard-custom 21m +data-sample-postgres-1 Bound pvc-1de36b06-8e32-4e9a-a01b-3b6d7c618688 3Gi RWO standard-custom 21m +data-sample-postgres-2 Bound pvc-a75bd538-8a71-4f62-8d38-3f4e42ffb225 3Gi RWO standard-custom 21m ``` -The `PersistentVolumeClaim` StorageClass has changed to `longhorn-custom`. Now, we will verify that the data remains intact after the `StorageMigration` operation. Let's exec into one of the `Postgres` pod and perform read query. +The `PersistentVolumeClaim` StorageClass has changed to `standard-custom`. Now, we will verify that the data remains intact after the `StorageMigration` operation. Let's exec into one of the `Postgres` pod and perform read query. ```bash $ kubectl exec -it -n demo sample-postgres-0 -- bash diff --git a/docs/guides/postgres/pitr/archiver.md b/docs/guides/postgres/pitr/archiver.md index 8dc96376dc..802a4a572f 100644 --- a/docs/guides/postgres/pitr/archiver.md +++ b/docs/guides/postgres/pitr/archiver.md @@ -139,7 +139,7 @@ spec: driver: "VolumeSnapshotter" task: params: - volumeSnapshotClassName: "longhorn-snapshot-vsc" + volumeSnapshotClassName: "standard-snapshot-vsc" scheduler: successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 1 @@ -182,16 +182,16 @@ stringData: ```bash $ kubectl get volumesnapshotclasses NAME DRIVER DELETIONPOLICY AGE -longhorn-snapshot-vsc driver.longhorn.io Delete 7d22h +standard-snapshot-vsc driver.standard.io Delete 7d22h ``` -If not any, try using `longhorn` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). +If not any, try using `standard` or any other [volumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/). ```yaml kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: - name: longhorn-snapshot-vsc -driver: driver.longhorn.io + name: standard-snapshot-vsc +driver: driver.standard.io deletionPolicy: Delete parameters: type: snap @@ -199,10 +199,10 @@ parameters: ``` ```bash -$ helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace +$ helm install standard standard/standard --namespace standard-system --create-namespace $ kubectl apply -f volumesnapshotclass.yaml - volumesnapshotclass.snapshot.storage.k8s.io/longhorn-snapshot-vsc unchanged + volumesnapshotclass.snapshot.storage.k8s.io/standard-snapshot-vsc unchanged ``` # Deploy PostgreSQL @@ -222,7 +222,7 @@ spec: standbyMode: Hot storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -270,7 +270,7 @@ demo-pg-backup-config-manifest-1702388088 BackupConfiguration demo-pg-bac kubectl get volumesnapshots -n demo NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT CREATIONTIME AGE -demo-pg-1702388096 true data-demo-pg-1 1Gi longhorn-snapshot-vsc snapcontent-735e97ad-1dfa-4b70-b416-33f7270d792c 2m5s 2m5s +demo-pg-1702388096 true data-demo-pg-1 1Gi standard-snapshot-vsc snapcontent-735e97ad-1dfa-4b70-b416-33f7270d792c 2m5s 2m5s ``` ## data insert and switch wal @@ -371,7 +371,7 @@ spec: standbyMode: Hot storageType: Durable storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/postgres/pitr/yamls/postgresarchiver.yaml b/docs/guides/postgres/pitr/yamls/postgresarchiver.yaml index 119df31067..7b97edc851 100644 --- a/docs/guides/postgres/pitr/yamls/postgresarchiver.yaml +++ b/docs/guides/postgres/pitr/yamls/postgresarchiver.yaml @@ -24,7 +24,7 @@ spec: driver: "VolumeSnapshotter" task: params: - volumeSnapshotClassName: "longhorn-snapshot-vsc" + volumeSnapshotClassName: "standard-snapshot-vsc" scheduler: successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 1 diff --git a/docs/guides/postgres/pitr/yamls/voluemsnapshotclass.yaml b/docs/guides/postgres/pitr/yamls/voluemsnapshotclass.yaml index 1a67906612..af4aa5c343 100644 --- a/docs/guides/postgres/pitr/yamls/voluemsnapshotclass.yaml +++ b/docs/guides/postgres/pitr/yamls/voluemsnapshotclass.yaml @@ -1,8 +1,8 @@ kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: - name: longhorn-snapshot-vsc -driver: driver.longhorn.io + name: standard-snapshot-vsc +driver: driver.standard.io deletionPolicy: Delete parameters: type: snap \ No newline at end of file diff --git a/docs/guides/redis/gitops/gitops.md b/docs/guides/redis/gitops/gitops.md index 16ffe098f1..92a1e57594 100644 --- a/docs/guides/redis/gitops/gitops.md +++ b/docs/guides/redis/gitops/gitops.md @@ -74,7 +74,7 @@ spec: resources: requests: storage: "1Gi" - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce deletionPolicy: WipeOut @@ -133,6 +133,107 @@ appbinding.appcatalog.appscode.com/rd-gitops kubedb.com/redis 8.0.4 8m53 ## Update Redis Database using GitOps + +### TLS configuration + + + +We are going to create an example `Issuer` that will be used throughout the duration of this tutorial to enable SSL/TLS in Redis. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating you ca certificates using openssl. + +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=redis/O=kubedb" +``` + +- Now create a ca-secret using the certificate files you have just generated. + +```bash +kubectl create secret tls redis-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +``` + +Now, create an `Issuer` using the `ca-secret` you have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: redis-ca-issuer + namespace: demo +spec: + ca: + secretName: redis-ca +``` + +Apply the `YAML` file: + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/redis/tls/issuer.yaml +issuer.cert-manager.io/redis-ca-issuer created +``` + +Let's add that to our `kubedb /rd-issuer.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── rd-configuration.yaml +│ ├── rd-issuer.yaml +│ └── redis.yaml +1 directories, 3 files +``` + +Update the `redis.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Redis +metadata: + name: rd-gitops + namespace: demo +spec: + version: 7.4.1 + mode: Cluster + cluster: + shards: 3 + replicas: 2 + storageType: Durable + tls: + issuerRef: + apiGroup: "cert-manager.io" + kind: Issuer + name: rd-issuer + storage: + resources: + requests: + storage: "1Gi" + storageClassName: "standard" + accessModes: + - ReadWriteOnce + deletionPolicy: WipeOut +``` + +Add `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD` and the `Elasticsearch` CR is updated in your cluster. + +Now, `gitops` operator will detect the tls changes and create a `ReconfigureTLS` ElasticsearchOpsRequest to update the `Elasticsearch` database tls. List the resources created by `gitops` operator in the `demo` namespace. + +```bash +$ kubectl get rd,redis,redisopsrequest -n demo +NAME VERSION STATUS AGE +redis.kubedb.com/rd-gitops 7.4.1 Ready 15m + +NAME AGE +redis.gitops.kubedb.com/rd-gitops 15m + +NAME TYPE STATUS AGE +redisopsrequest.ops.kubedb.com/rd-gitops-reconfiguretls-qcdjjd ReconfigureTLS Successful 9m47s +``` + + +> We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for Elasticsearch. + + ### Scale Redis Replicas @@ -154,7 +255,7 @@ spec: resources: requests: storage: "1Gi" - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce deletionPolicy: WipeOut @@ -227,7 +328,7 @@ spec: resources: requests: storage: "1Gi" - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce deletionPolicy: WipeOut @@ -297,7 +398,7 @@ spec: resources: requests: storage: "2Gi" - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce deletionPolicy: WipeOut @@ -336,15 +437,15 @@ After Ops Request becomes `Successful`, We can validate the changes by checking ```bash $ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=rd-gitops' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-rd-gitops-shard0-0 Bound pvc-97afbd7c-5887-4381-bef8-4584411b4ed5 2Gi RWO longhorn 39m -data-rd-gitops-shard0-1 Bound pvc-461c6122-94ba-4b96-805b-1bf2619a10d4 2Gi RWO longhorn 38m -data-rd-gitops-shard0-2 Bound pvc-90fc4131-a272-44bd-bfa2-3ffc5c093178 2Gi RWO longhorn 24m -data-rd-gitops-shard1-0 Bound pvc-38855b1c-4e1f-485f-93c5-5848eed1465d 2Gi RWO longhorn 39m -data-rd-gitops-shard1-1 Bound pvc-14b89fe8-8681-4aba-af37-035da020c3cb 2Gi RWO longhorn 38m -data-rd-gitops-shard1-2 Bound pvc-6d3d1e55-689e-4884-a3cc-ed6080e48cf0 2Gi RWO longhorn 23m -data-rd-gitops-shard2-0 Bound pvc-e6b9fa56-40b2-45aa-8ebd-ab360522a294 2Gi RWO longhorn 39m -data-rd-gitops-shard2-1 Bound pvc-6fdfd395-d2b8-45df-8369-f9897e3d678c 2Gi RWO longhorn 38m -data-rd-gitops-shard2-2 Bound pvc-1570c37b-63da-456c-af59-b60ed544e651 2Gi RWO longhorn 23m +data-rd-gitops-shard0-0 Bound pvc-97afbd7c-5887-4381-bef8-4584411b4ed5 2Gi RWO standard 39m +data-rd-gitops-shard0-1 Bound pvc-461c6122-94ba-4b96-805b-1bf2619a10d4 2Gi RWO standard 38m +data-rd-gitops-shard0-2 Bound pvc-90fc4131-a272-44bd-bfa2-3ffc5c093178 2Gi RWO standard 24m +data-rd-gitops-shard1-0 Bound pvc-38855b1c-4e1f-485f-93c5-5848eed1465d 2Gi RWO standard 39m +data-rd-gitops-shard1-1 Bound pvc-14b89fe8-8681-4aba-af37-035da020c3cb 2Gi RWO standard 38m +data-rd-gitops-shard1-2 Bound pvc-6d3d1e55-689e-4884-a3cc-ed6080e48cf0 2Gi RWO standard 23m +data-rd-gitops-shard2-0 Bound pvc-e6b9fa56-40b2-45aa-8ebd-ab360522a294 2Gi RWO standard 39m +data-rd-gitops-shard2-1 Bound pvc-6fdfd395-d2b8-45df-8369-f9897e3d678c 2Gi RWO standard 38m +data-rd-gitops-shard2-2 Bound pvc-1570c37b-63da-456c-af59-b60ed544e651 2Gi RWO standard 23m ``` @@ -372,7 +473,7 @@ spec: resources: requests: storage: "2Gi" - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce deletionPolicy: WipeOut @@ -453,7 +554,7 @@ spec: resources: requests: storage: "2Gi" - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce deletionPolicy: WipeOut @@ -533,7 +634,7 @@ spec: resources: requests: storage: "2Gi" - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce podTemplate: @@ -602,7 +703,7 @@ spec: resources: requests: storage: "2Gi" - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce deletionPolicy: WipeOut diff --git a/docs/guides/singlestore/configuration/podtemplating/index.md b/docs/guides/singlestore/configuration/podtemplating/index.md index 0660ce756b..730581231b 100644 --- a/docs/guides/singlestore/configuration/podtemplating/index.md +++ b/docs/guides/singlestore/configuration/podtemplating/index.md @@ -254,7 +254,7 @@ spec: configMap: name: nginx-config-map storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -274,7 +274,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -413,7 +413,7 @@ spec: kind: Secret name: license-secret storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -507,7 +507,7 @@ spec: kind: Secret name: license-secret storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -662,7 +662,7 @@ spec: kind: Secret name: license-secret storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-custom-sidecar.yaml b/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-custom-sidecar.yaml index b474eed2b3..ad84e6dbc2 100644 --- a/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-custom-sidecar.yaml +++ b/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-custom-sidecar.yaml @@ -31,7 +31,7 @@ spec: configMap: name: nginx-config-map storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -51,7 +51,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-node-selector.yaml b/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-node-selector.yaml index c4d5ee82ee..b4411992f3 100644 --- a/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-node-selector.yaml +++ b/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-node-selector.yaml @@ -14,7 +14,7 @@ spec: kind: Secret name: license-secret storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-with-tolerations.yaml b/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-with-tolerations.yaml index 965fdf1e95..a21a605a20 100644 --- a/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-with-tolerations.yaml +++ b/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-with-tolerations.yaml @@ -16,7 +16,7 @@ spec: kind: Secret name: license-secret storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-without-tolerations.yaml b/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-without-tolerations.yaml index 0320f1b4a6..732fec102b 100644 --- a/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-without-tolerations.yaml +++ b/docs/guides/singlestore/configuration/podtemplating/yamls/sdb-without-tolerations.yaml @@ -9,7 +9,7 @@ spec: kind: Secret name: license-secret storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/restart/restart.md b/docs/guides/singlestore/restart/restart.md index 2febd32fb6..e792768a0d 100644 --- a/docs/guides/singlestore/restart/restart.md +++ b/docs/guides/singlestore/restart/restart.md @@ -69,7 +69,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -89,7 +89,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/restart/yamls/sdb-sample.yaml b/docs/guides/singlestore/restart/yamls/sdb-sample.yaml index fcd9a408c1..dea9ec381e 100644 --- a/docs/guides/singlestore/restart/yamls/sdb-sample.yaml +++ b/docs/guides/singlestore/restart/yamls/sdb-sample.yaml @@ -20,7 +20,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -40,7 +40,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/scaling/horizontal-scaling/cluster/example/sample-sdb.yaml b/docs/guides/singlestore/scaling/horizontal-scaling/cluster/example/sample-sdb.yaml index 9d1928e1f5..173956db1e 100644 --- a/docs/guides/singlestore/scaling/horizontal-scaling/cluster/example/sample-sdb.yaml +++ b/docs/guides/singlestore/scaling/horizontal-scaling/cluster/example/sample-sdb.yaml @@ -20,7 +20,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -40,7 +40,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/scaling/horizontal-scaling/cluster/index.md b/docs/guides/singlestore/scaling/horizontal-scaling/cluster/index.md index a337119433..0f50e8e5c7 100644 --- a/docs/guides/singlestore/scaling/horizontal-scaling/cluster/index.md +++ b/docs/guides/singlestore/scaling/horizontal-scaling/cluster/index.md @@ -77,7 +77,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -97,7 +97,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/scaling/vertical-scaling/cluster/example/sample-sdb.yaml b/docs/guides/singlestore/scaling/vertical-scaling/cluster/example/sample-sdb.yaml index 9d1928e1f5..173956db1e 100644 --- a/docs/guides/singlestore/scaling/vertical-scaling/cluster/example/sample-sdb.yaml +++ b/docs/guides/singlestore/scaling/vertical-scaling/cluster/example/sample-sdb.yaml @@ -20,7 +20,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -40,7 +40,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/scaling/vertical-scaling/cluster/index.md b/docs/guides/singlestore/scaling/vertical-scaling/cluster/index.md index 7fa321a46c..5ac9babe91 100644 --- a/docs/guides/singlestore/scaling/vertical-scaling/cluster/index.md +++ b/docs/guides/singlestore/scaling/vertical-scaling/cluster/index.md @@ -77,7 +77,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -97,7 +97,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/update-version/sdb update-version opsrequest/examples/sample-sdb.yaml b/docs/guides/singlestore/update-version/sdb update-version opsrequest/examples/sample-sdb.yaml index 572336c17d..d3261193f5 100644 --- a/docs/guides/singlestore/update-version/sdb update-version opsrequest/examples/sample-sdb.yaml +++ b/docs/guides/singlestore/update-version/sdb update-version opsrequest/examples/sample-sdb.yaml @@ -20,7 +20,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -40,7 +40,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/update-version/sdb update-version opsrequest/index.md b/docs/guides/singlestore/update-version/sdb update-version opsrequest/index.md index e95a73484b..571d3aaaae 100644 --- a/docs/guides/singlestore/update-version/sdb update-version opsrequest/index.md +++ b/docs/guides/singlestore/update-version/sdb update-version opsrequest/index.md @@ -77,7 +77,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -97,7 +97,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/volume-expansion/sdb volume-expansion opsrequest/example/sample-sdb.yaml b/docs/guides/singlestore/volume-expansion/sdb volume-expansion opsrequest/example/sample-sdb.yaml index cf84dd4309..538af96b9e 100644 --- a/docs/guides/singlestore/volume-expansion/sdb volume-expansion opsrequest/example/sample-sdb.yaml +++ b/docs/guides/singlestore/volume-expansion/sdb volume-expansion opsrequest/example/sample-sdb.yaml @@ -20,7 +20,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -40,7 +40,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/volume-expansion/sdb volume-expansion opsrequest/index.md b/docs/guides/singlestore/volume-expansion/sdb volume-expansion opsrequest/index.md index 6d83c031b2..0bbd960366 100644 --- a/docs/guides/singlestore/volume-expansion/sdb volume-expansion opsrequest/index.md +++ b/docs/guides/singlestore/volume-expansion/sdb volume-expansion opsrequest/index.md @@ -59,11 +59,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get storageClass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 6d2h -longhorn (default) driver.longhorn.io Delete Immediate true 3d21h -longhorn-static driver.longhorn.io Delete Immediate true 42m +standard (default) driver.standard.io Delete Immediate true 3d21h +standard-static driver.standard.io Delete Immediate true 42m ``` -Here, we will use `longhorn` storageClass for this tuitorial. +Here, we will use `standard` storageClass for this tuitorial. Now, we are going to deploy a `SingleStore` database of 3 replicas with version `8.7.10`. @@ -94,7 +94,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -114,7 +114,7 @@ spec: memory: "2Gi" cpu: "600m" storage: - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce resources: @@ -154,9 +154,9 @@ $ kubectl get petset -n demo sample-sdb-leaf -o json | jq '.spec.volumeClaimTemp $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-41cb892c-99fc-4211-a8c2-4e6f8a16c661 10Gi RWO Delete Bound demo/data-sample-sdb-leaf-0 longhorn 90s -pvc-6e241724-6577-408e-b8de-9569d7d785c4 10Gi RWO Delete Bound demo/data-sample-sdb-leaf-1 longhorn 75s -pvc-95ecc525-540b-4496-bf14-bfac901d73c4 1Gi RWO Delete Bound demo/data-sample-sdb-aggregator-0 longhorn 94s +pvc-41cb892c-99fc-4211-a8c2-4e6f8a16c661 10Gi RWO Delete Bound demo/data-sample-sdb-leaf-0 standard 90s +pvc-6e241724-6577-408e-b8de-9569d7d785c4 10Gi RWO Delete Bound demo/data-sample-sdb-leaf-1 standard 75s +pvc-95ecc525-540b-4496-bf14-bfac901d73c4 1Gi RWO Delete Bound demo/data-sample-sdb-aggregator-0 standard 94s ``` @@ -196,7 +196,7 @@ Here, - `spec.databaseRef.name` specifies that we are performing volume expansion operation on `sample-sdb` database. - `spec.type` specifies that we are performing `VolumeExpansion` on our database. - `spec.volumeExpansion.aggregator` and `spec.volumeExpansion.leaf` specifies the desired volume size for `aggregator` and `leaf` nodes. -- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `longhorn` supports `Offline` volume expansion. +- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `standard` supports `Offline` volume expansion. > **Note:** If the Storageclass you are using doesn't support `Online` Volume Expansion, Try offline volume expansion by using `spec.volumeExpansion.mode:"Offline"`. @@ -464,9 +464,9 @@ $ kubectl get petset -n demo sample-sdb-leaf -o json | jq '.spec.volumeClaimTemp $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-0a4b35e6-988e-4088-ae41-852ad82c5800 2Gi RWO Delete Bound demo/data-sample-sdb-aggregator-0 longhorn 22m -pvc-f6df5743-2bb1-4705-a2f7-be6cf7cdd7f1 11Gi RWO Delete Bound demo/data-sample-sdb-leaf-0 longhorn 22m -pvc-f8fee59d-74dc-46ac-9973-ff1701a6837b 11Gi RWO Delete Bound demo/data-sample-sdb-leaf-1 longhorn 19m +pvc-0a4b35e6-988e-4088-ae41-852ad82c5800 2Gi RWO Delete Bound demo/data-sample-sdb-aggregator-0 standard 22m +pvc-f6df5743-2bb1-4705-a2f7-be6cf7cdd7f1 11Gi RWO Delete Bound demo/data-sample-sdb-leaf-0 standard 22m +pvc-f8fee59d-74dc-46ac-9973-ff1701a6837b 11Gi RWO Delete Bound demo/data-sample-sdb-leaf-1 standard 19m ``` The above output verifies that we have successfully expanded the volume of the SingleStore database. diff --git a/docs/guides/solr/autoscaler/compute/topology.md b/docs/guides/solr/autoscaler/compute/topology.md index e7d528e910..10bc69fe56 100644 --- a/docs/guides/solr/autoscaler/compute/topology.md +++ b/docs/guides/solr/autoscaler/compute/topology.md @@ -62,7 +62,7 @@ spec: overseer: replicas: 1 storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -71,7 +71,7 @@ spec: data: replicas: 1 storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -79,7 +79,7 @@ spec: storage: 1Gi coordinator: storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/solr/autoscaler/storage/combined.md b/docs/guides/solr/autoscaler/storage/combined.md index f2e3b979e3..1787bce4b3 100644 --- a/docs/guides/solr/autoscaler/storage/combined.md +++ b/docs/guides/solr/autoscaler/storage/combined.md @@ -49,11 +49,11 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 11d -longhorn (default) driver.longhorn.io Delete Immediate true 7d21h -longhorn-static driver.longhorn.io Delete Immediate true 7d21h +standard (default) driver.standard.io Delete Immediate true 7d21h +standard-static driver.standard.io Delete Immediate true 7d21h ``` -We can see from the output the `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. You can install longhorn from [here](https://longhorn.io/docs/1.7.2/deploy/install/install-with-kubectl/) +We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. You can install standard from [here](https://standard.io/docs/1.7.2/deploy/install/install-with-kubectl/) Now, we are going to deploy a `Solr` combined cluster using a supported version by the `KubeDB` operator. Then we are going to apply `SolrAutoscaler` to set up autoscaling. @@ -79,7 +79,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard ``` Let's create the `Solr` CRD we have shown above, @@ -111,8 +111,8 @@ $ kubectl get petset -n demo solr-combined -o json | jq '.spec.volumeClaimTempla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-ceee299c-5c50-4f5c-83d5-97e2423bf286 7332Mi RWO Delete Bound demo/solr-combined-data-solr-combined-1 longhorn 19m -pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7332Mi RWO Delete Bound demo/solr-combined-data-solr-combined-0 longhorn 19m +pvc-ceee299c-5c50-4f5c-83d5-97e2423bf286 7332Mi RWO Delete Bound demo/solr-combined-data-solr-combined-1 standard 19m +pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7332Mi RWO Delete Bound demo/solr-combined-data-solr-combined-0 standard 19m ``` You can see the PetSet has 1GB storage, and the capacity of the persistent volume is also 1GB. @@ -223,7 +223,7 @@ $ kubectl exec -it -n demo solr-combined-0 -- bash Defaulted container "solr" out of: solr, init-solr (init) solr@solr-combined-0:/opt/solr-9.6.1$ df -h /var/solr/data Filesystem Size Used Avail Use% Mounted on -/dev/longhorn/pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7.1G 601M 6.5G 9% /var/solr/data +/dev/standard/pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7.1G 601M 6.5G 9% /var/solr/data [root@es-combined-0 Solr]# dd if=/dev/zero of=/var/solrdata/file.img bs=300M count=2 1+0 records in @@ -232,7 +232,7 @@ Filesystem Size Used Avail Use% Mo [root@es-combined-0 Solr]# df -h /usr/share/Solr/data Filesystem Size Used Avail Use% Mounted on -/dev/longhorn/pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7.1G 601M 6.5G 63% /var/solr/data +/dev/standard/pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7.1G 601M 6.5G 63% /var/solr/data ``` So, from the above output, we can see that the storage usage is 64%, which exceeded the `usageThreshold` 60%. @@ -396,8 +396,8 @@ $ kubectl get petset -n demo solr-combined -o json | jq '.spec.volumeClaimTempla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-ceee299c-5c50-4f5c-83d5-97e2423bf286 7332Mi RWO Delete Bound demo/solr-combined-data-solr-combined-1 longhorn 26m -pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7332Mi RWO Delete Bound demo/solr-combined-data-solr-combined-0 longhorn +pvc-ceee299c-5c50-4f5c-83d5-97e2423bf286 7332Mi RWO Delete Bound demo/solr-combined-data-solr-combined-1 standard 26m +pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7332Mi RWO Delete Bound demo/solr-combined-data-solr-combined-0 standard ``` The above output verifies that we have successfully autoscaler the volume of the Solr combined cluster. diff --git a/docs/guides/solr/autoscaler/storage/topology.md b/docs/guides/solr/autoscaler/storage/topology.md index 0e4c23d0d7..1ed242be7c 100644 --- a/docs/guides/solr/autoscaler/storage/topology.md +++ b/docs/guides/solr/autoscaler/storage/topology.md @@ -49,12 +49,12 @@ At first verify that your cluster has a storage class, that supports volume expa $ kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 11d -longhorn (default) driver.longhorn.io Delete Immediate true 7d22h -longhorn-static driver.longhorn.io Delete Immediate true 7d22h +standard (default) driver.standard.io Delete Immediate true 7d22h +standard-static driver.standard.io Delete Immediate true 7d22h ``` -We can see from the output the `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. You can install topolvm from [here](https://github.com/topolvm/topolvm) +We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. You can install topolvm from [here](https://github.com/topolvm/topolvm) Now, we are going to deploy a `Solr` topology cluster using a supported version by the `KubeDB` operator. Then we are going to apply `SolrAutoscaler` to set up autoscaling. @@ -77,7 +77,7 @@ spec: overseer: replicas: 1 storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -86,7 +86,7 @@ spec: data: replicas: 1 storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -94,7 +94,7 @@ spec: storage: 1Gi coordinator: storage: - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce resources: @@ -131,9 +131,9 @@ $ kubectl get petset -n demo solr-cluster-data -o json | jq '.spec.volumeClaimTe $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-24431af2-8df5-4ad2-a6cd-795dcbdc6355 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-coordinator-0 longhorn 2m15s -pvc-5e3430da-545c-4234-a891-3385b100401d 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-overseer-0 longhorn 2m17s -pvc-aa75a15f-94cd-475a-a7ad-498023830020 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-data-0 longhorn 2m19s +pvc-24431af2-8df5-4ad2-a6cd-795dcbdc6355 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-coordinator-0 standard 2m15s +pvc-5e3430da-545c-4234-a891-3385b100401d 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-overseer-0 standard 2m17s +pvc-aa75a15f-94cd-475a-a7ad-498023830020 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-data-0 standard 2m19s ``` @@ -240,14 +240,14 @@ Let's exec into the data nodes and fill the database volume using the following Defaulted container "solr" out of: solr, init-solr (init) solr@solr-combined-0:/opt/solr-9.6.1$ df -h /var/solr/data Filesystem Size Used Avail Use% Mounted on -/dev/longhorn/pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7.1G 601M 6.5G 9% /var/solr/data +/dev/standard/pvc-d9c2f7c1-7c27-48bd-a87e-cb1935cc2e61 7.1G 601M 6.5G 9% /var/solr/data solr@solr-cluster-data-0:/opt/solr-9.6.1$ dd if=/dev/zero of=/var/solr/data/file.img bs=300M count=2 2+0 records in 2+0 records out 629145600 bytes (629 MB, 600 MiB) copied, 1.95395 s, 322 MB/s solr@solr-cluster-data-0:/opt/solr-9.6.1$ df -h /var/solr/data Filesystem Size Used Avail Use% Mounted on -/dev/longhorn/pvc-aa75a15f-94cd-475a-a7ad-498023830020 974M 601M 358M 63% /var/solr/data +/dev/standard/pvc-aa75a15f-94cd-475a-a7ad-498023830020 974M 601M 358M 63% /var/solr/data ``` @@ -422,15 +422,15 @@ $ kubectl get petset -n demo solr-cluster-data -o json | jq '.spec.volumeClaimTe $ kubectl get pvc -n demo NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -solr-cluster-data-solr-cluster-coordinator-0 Bound pvc-24431af2-8df5-4ad2-a6cd-795dcbdc6355 1Gi RWO longhorn 18m -solr-cluster-data-solr-cluster-data-0 Bound pvc-aa75a15f-94cd-475a-a7ad-498023830020 1948Mi RWO longhorn 18m -solr-cluster-data-solr-cluster-overseer-0 Bound pvc-5e3430da-545c-4234-a891-3385b100401d 1Gi RWO longhorn 18m +solr-cluster-data-solr-cluster-coordinator-0 Bound pvc-24431af2-8df5-4ad2-a6cd-795dcbdc6355 1Gi RWO standard 18m +solr-cluster-data-solr-cluster-data-0 Bound pvc-aa75a15f-94cd-475a-a7ad-498023830020 1948Mi RWO standard 18m +solr-cluster-data-solr-cluster-overseer-0 Bound pvc-5e3430da-545c-4234-a891-3385b100401d 1Gi RWO standard 18m $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-24431af2-8df5-4ad2-a6cd-795dcbdc6355 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-coordinator-0 longhorn 18m -pvc-5e3430da-545c-4234-a891-3385b100401d 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-overseer-0 longhorn 18m -pvc-aa75a15f-94cd-475a-a7ad-498023830020 1948Mi RWO Delete Bound demo/solr-cluster-data-solr-cluster-data-0 longhorn 18m +pvc-24431af2-8df5-4ad2-a6cd-795dcbdc6355 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-coordinator-0 standard 18m +pvc-5e3430da-545c-4234-a891-3385b100401d 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-overseer-0 standard 18m +pvc-aa75a15f-94cd-475a-a7ad-498023830020 1948Mi RWO Delete Bound demo/solr-cluster-data-solr-cluster-data-0 standard 18m ``` The above output verifies that we have successfully autoscaler the volume of the data nodes of this Solr topology cluster. diff --git a/docs/guides/solr/configuration/config-file.md b/docs/guides/solr/configuration/config-file.md index e8a9bd1aa9..eacfc70a4b 100644 --- a/docs/guides/solr/configuration/config-file.md +++ b/docs/guides/solr/configuration/config-file.md @@ -101,7 +101,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard ``` Let's create the `Solr` CR we have shown above, diff --git a/docs/guides/solr/reconfigure/solr.md b/docs/guides/solr/reconfigure/solr.md index 78610d283e..c77e036f4f 100644 --- a/docs/guides/solr/reconfigure/solr.md +++ b/docs/guides/solr/reconfigure/solr.md @@ -103,7 +103,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: longhorn + storageClassName: standard ``` Let's create the `Solr` CR we have shown above, diff --git a/docs/guides/solr/volume-expansion/combined.md b/docs/guides/solr/volume-expansion/combined.md index cfd1785c7f..d53cb2f1d4 100644 --- a/docs/guides/solr/volume-expansion/combined.md +++ b/docs/guides/solr/volume-expansion/combined.md @@ -104,8 +104,8 @@ $ kubectl get petset -n demo solr-combined -o json | jq '.spec.volumeClaimTempla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-02cddba5-1d6a-4f1b-91b2-a7e55857b6b7 1Gi RWO Delete Bound demo/solr-combined-data-solr-combined-1 longhorn 23m -pvc-61b8f97a-a588-4125-99f3-604f6a70d560 1Gi RWO Delete Bound demo/solr-combined-data-solr-combined-0 longhorn 24m +pvc-02cddba5-1d6a-4f1b-91b2-a7e55857b6b7 1Gi RWO Delete Bound demo/solr-combined-data-solr-combined-1 standard 23m +pvc-61b8f97a-a588-4125-99f3-604f6a70d560 1Gi RWO Delete Bound demo/solr-combined-data-solr-combined-0 standard 24m ``` You can see the petset has 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -335,8 +335,8 @@ $ kubectl get petset -n demo solr-combined -o json | jq '.spec.volumeClaimTempla "11Gi" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-02cddba5-1d6a-4f1b-91b2-a7e55857b6b7 11Gi RWO Delete Bound demo/solr-combined-data-solr-combined-1 longhorn 33m -pvc-61b8f97a-a588-4125-99f3-604f6a70d560 11Gi RWO Delete Bound demo/solr-combined-data-solr-combined-0 longhorn 33m +pvc-02cddba5-1d6a-4f1b-91b2-a7e55857b6b7 11Gi RWO Delete Bound demo/solr-combined-data-solr-combined-1 standard 33m +pvc-61b8f97a-a588-4125-99f3-604f6a70d560 11Gi RWO Delete Bound demo/solr-combined-data-solr-combined-0 standard 33m ``` The above output verifies that we have successfully expanded the volume of the Solr. diff --git a/docs/guides/solr/volume-expansion/topology.md b/docs/guides/solr/volume-expansion/topology.md index 16942a11e6..0d8373b684 100644 --- a/docs/guides/solr/volume-expansion/topology.md +++ b/docs/guides/solr/volume-expansion/topology.md @@ -125,9 +125,9 @@ $ kubectl get petset -n demo solr-cluster-coordinator -o json | jq '.spec.volume "1Gi" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-31538e3e-2d02-4ca0-9b76-5da7c63cea70 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-data-0 longhorn 44m -pvc-8c5b14ab-3da4-4492-abf4-edd7faa265ef 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-overseer-0 longhorn 44m -pvc-95522f35-52bd-4978-b66f-1979cec34982 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-coordinator-0 longhorn 44m +pvc-31538e3e-2d02-4ca0-9b76-5da7c63cea70 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-data-0 standard 44m +pvc-8c5b14ab-3da4-4492-abf4-edd7faa265ef 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-overseer-0 standard 44m +pvc-95522f35-52bd-4978-b66f-1979cec34982 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-coordinator-0 standard 44m ``` You can see the petsets have 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -392,9 +392,9 @@ $ kubectl get petset -n demo solr-cluster-coordinator -o json | jq '.spec.volume "1Gi" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-31538e3e-2d02-4ca0-9b76-5da7c63cea70 11Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-data-0 longhorn 52m -pvc-8c5b14ab-3da4-4492-abf4-edd7faa265ef 11Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-overseer-0 longhorn 52m -pvc-95522f35-52bd-4978-b66f-1979cec34982 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-coordinator-0 longhorn 52m +pvc-31538e3e-2d02-4ca0-9b76-5da7c63cea70 11Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-data-0 standard 52m +pvc-8c5b14ab-3da4-4492-abf4-edd7faa265ef 11Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-overseer-0 standard 52m +pvc-95522f35-52bd-4978-b66f-1979cec34982 1Gi RWO Delete Bound demo/solr-cluster-data-solr-cluster-coordinator-0 standard 52m ``` The above output verifies that we have successfully expanded the volume of the Solr. diff --git a/docs/guides/zookeeper/monitoring/using-prometheus-operator.md b/docs/guides/zookeeper/monitoring/using-prometheus-operator.md index 4943bea813..2fce40817e 100644 --- a/docs/guides/zookeeper/monitoring/using-prometheus-operator.md +++ b/docs/guides/zookeeper/monitoring/using-prometheus-operator.md @@ -181,7 +181,7 @@ spec: resources: requests: storage: "100Mi" - storageClassName: longhorn + storageClassName: standard accessModes: - ReadWriteOnce deletionPolicy: WipeOut diff --git a/docs/guides/zookeeper/volume-expansion/volume-expansion.md b/docs/guides/zookeeper/volume-expansion/volume-expansion.md index ae2bba9d6f..2165326769 100644 --- a/docs/guides/zookeeper/volume-expansion/volume-expansion.md +++ b/docs/guides/zookeeper/volume-expansion/volume-expansion.md @@ -49,8 +49,8 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -longhorn (default) driver.longhorn.io Delete Immediate true 93s -longhorn-static driver.longhorn.io Delete Immediate true 90s +standard (default) driver.standard.io Delete Immediate true 93s +standard-static driver.standard.io Delete Immediate true 90s ``` We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. @@ -75,7 +75,7 @@ spec: resources: requests: storage: "1Gi" - storageClassName: "longhorn" + storageClassName: "standard" accessModes: - ReadWriteOnce deletionPolicy: "WipeOut" @@ -104,9 +104,9 @@ $ kubectl get petset -n demo zk-quickstart -o json | jq '.spec.volumeClaimTempla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-3551d7c0-0df6-4f94-b1e0-21834319ecab 1Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-0 longhorn 92s -pvc-b5882e9e-3c61-4609-b5ba-0eb9f32edbbc 1Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-2 longhorn 58s -pvc-dccf2b12-d695-4792-8e4b-de4342e7fed4 1Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-1 longhorn 74s +pvc-3551d7c0-0df6-4f94-b1e0-21834319ecab 1Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-0 standard 92s +pvc-b5882e9e-3c61-4609-b5ba-0eb9f32edbbc 1Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-2 standard 58s +pvc-dccf2b12-d695-4792-8e4b-de4342e7fed4 1Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-1 standard 74s ``` You can see the PetSet has 1GB storage, and the capacity of the persistent volume is also 1GB. @@ -369,9 +369,9 @@ $ kubectl get petset -n demo zk-quickstart -o json | jq '.spec.volumeClaimTempla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-1b112414-6162-4e75-99c9-3e62cb4efb4a 2Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-1 longhorn 16m -pvc-3159b881-1954-4008-8594-599bee9fd11e 2Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-0 longhorn 17m -pvc-43ba80bd-9029-413e-b89c-1f373fd0cd3d 2Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-2 longhorn 16m +pvc-1b112414-6162-4e75-99c9-3e62cb4efb4a 2Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-1 standard 16m +pvc-3159b881-1954-4008-8594-599bee9fd11e 2Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-0 standard 17m +pvc-43ba80bd-9029-413e-b89c-1f373fd0cd3d 2Gi RWO Delete Bound demo/zk-quickstart-data-zk-quickstart-2 standard 16m ``` The above output verifies that we have successfully expanded the volume of the ZooKeeper standalone database. From a578a43f1191f605eaa9b4462e559a7850cbcc62 Mon Sep 17 00:00:00 2001 From: Bonusree Date: Tue, 28 Apr 2026 15:47:05 +0600 Subject: [PATCH 35/51] image added Signed-off-by: Bonusree --- docs/guides/elasticsearch/gitops/overview.md | 2 +- docs/guides/kafka/gitops/overview.md | 2 +- docs/guides/mariadb/gitops/overview.md | 2 +- .../mariadb/volume-expansion/maxscale.md | 2 +- docs/guides/mongodb/gitops/overview.md | 2 +- docs/guides/mssqlserver/gitops/overview.md | 2 +- docs/guides/mysql/gitops/overview.md | 2 +- docs/guides/postgres/gitops/overview.md | 2 +- docs/guides/redis/gitops/overview.md | 2 +- .../guides/solr/autoscaler/storage/combined.md | 3 +-- docs/images/gitops/gitops.jpg | Bin 0 -> 51028 bytes docs/images/gitops/gitops.png | Bin 316779 -> 0 bytes 12 files changed, 10 insertions(+), 11 deletions(-) create mode 100644 docs/images/gitops/gitops.jpg delete mode 100644 docs/images/gitops/gitops.png diff --git a/docs/guides/elasticsearch/gitops/overview.md b/docs/guides/elasticsearch/gitops/overview.md index 233d51d1ca..a2e2642a34 100644 --- a/docs/guides/elasticsearch/gitops/overview.md +++ b/docs/guides/elasticsearch/gitops/overview.md @@ -33,7 +33,7 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y
- GitOps Flow + GitOps Flow
Fig: GitOps process of Elasticsearch
diff --git a/docs/guides/kafka/gitops/overview.md b/docs/guides/kafka/gitops/overview.md index 3bdefd3fed..ffd2d0c3a6 100644 --- a/docs/guides/kafka/gitops/overview.md +++ b/docs/guides/kafka/gitops/overview.md @@ -33,7 +33,7 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y
- GitOps Flow + GitOps Flow
Fig: GitOps process of Kafka
diff --git a/docs/guides/mariadb/gitops/overview.md b/docs/guides/mariadb/gitops/overview.md index 530fd42d89..18ff944731 100644 --- a/docs/guides/mariadb/gitops/overview.md +++ b/docs/guides/mariadb/gitops/overview.md @@ -33,7 +33,7 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y
- GitOps Flow + GitOps Flow
Fig: GitOps process of MariaDB
diff --git a/docs/guides/mariadb/volume-expansion/maxscale.md b/docs/guides/mariadb/volume-expansion/maxscale.md index 61d55c966f..c842b00756 100644 --- a/docs/guides/mariadb/volume-expansion/maxscale.md +++ b/docs/guides/mariadb/volume-expansion/maxscale.md @@ -53,7 +53,7 @@ standard driver.standard.io Delete Immediate standard-static driver.standard.io Delete Immediate true 2m24s ``` -We can see from the output that `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. You can install standard from [here](https://standard.io/docs/1.9.0/deploy/install/install-with-kubectl/). +We can see from the output that `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. Now, we are going to deploy a `MariaDB` database with `MaxScale` in replication mode. diff --git a/docs/guides/mongodb/gitops/overview.md b/docs/guides/mongodb/gitops/overview.md index f3af144f34..9fd6d17e68 100644 --- a/docs/guides/mongodb/gitops/overview.md +++ b/docs/guides/mongodb/gitops/overview.md @@ -33,7 +33,7 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y
- GitOps Flow + GitOps Flow
Fig: GitOps process of MongoDB
diff --git a/docs/guides/mssqlserver/gitops/overview.md b/docs/guides/mssqlserver/gitops/overview.md index e5be5d9be5..923a1f0c3d 100644 --- a/docs/guides/mssqlserver/gitops/overview.md +++ b/docs/guides/mssqlserver/gitops/overview.md @@ -33,7 +33,7 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y
- GitOps Flow + GitOps Flow
Fig: GitOps process of MSSQLServer
diff --git a/docs/guides/mysql/gitops/overview.md b/docs/guides/mysql/gitops/overview.md index 1897251aa4..fbfc017841 100644 --- a/docs/guides/mysql/gitops/overview.md +++ b/docs/guides/mysql/gitops/overview.md @@ -28,7 +28,7 @@ This guide will give you an overview of how KubeDB `gitops` operator works with The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version.
- GitOps Flow + GitOps Flow
Fig: GitOps process of MySQL
diff --git a/docs/guides/postgres/gitops/overview.md b/docs/guides/postgres/gitops/overview.md index 54f485c9f6..33f53afb31 100644 --- a/docs/guides/postgres/gitops/overview.md +++ b/docs/guides/postgres/gitops/overview.md @@ -29,7 +29,7 @@ This guide will give you an overview of how KubeDB `gitops` operator works with The following diagram shows how the `KubeDB` GitOps Operator used to sync with your database. Open the image in a new tab to see the enlarged version.
- GitOps Flow + GitOps Flow
Fig: GitOps process of Postgres
diff --git a/docs/guides/redis/gitops/overview.md b/docs/guides/redis/gitops/overview.md index e928f4f853..ab46d7e565 100644 --- a/docs/guides/redis/gitops/overview.md +++ b/docs/guides/redis/gitops/overview.md @@ -33,7 +33,7 @@ The following diagram shows how the `KubeDB` GitOps Operator used to sync with y
- GitOps Flow + GitOps Flow
Fig: GitOps process of Redis
diff --git a/docs/guides/solr/autoscaler/storage/combined.md b/docs/guides/solr/autoscaler/storage/combined.md index 1787bce4b3..e22ec3dbdc 100644 --- a/docs/guides/solr/autoscaler/storage/combined.md +++ b/docs/guides/solr/autoscaler/storage/combined.md @@ -53,8 +53,7 @@ standard (default) driver.standard.io Delete Immediate standard-static driver.standard.io Delete Immediate true 7d21h ``` -We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. You can install standard from [here](https://standard.io/docs/1.7.2/deploy/install/install-with-kubectl/) - +We can see from the output the `standard` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. Now, we are going to deploy a `Solr` combined cluster using a supported version by the `KubeDB` operator. Then we are going to apply `SolrAutoscaler` to set up autoscaling. #### Deploy Solr Combined Cluster diff --git a/docs/images/gitops/gitops.jpg b/docs/images/gitops/gitops.jpg new file mode 100644 index 0000000000000000000000000000000000000000..51b6f10bc18f4acad9255488b7eb24d11c36a25d GIT binary patch literal 51028 zcmeFa1z40_w>LgClF}flbPwGiAl=>KFf+i=(jl#M2uO$$f(S@Sw@8BuC?Fu+NJ@A7 zhwyoP&Uv5ryze>R`L6GOU5wYw+=zq-EAP^z_lH=JK0Dzc&$*~Def^>DCea;g8Ia`)u zP*g|6gWtk)q$sRhY|Y^JRPb*InA-sazysX$0|4Fv1YbNvy2tEcmcrLRRPJ10%rD(zZW1lubTq|zM$rCcN~XwH-k)J19ib#=_nap0tI5RiF^qIX*2{(%$`hX)Qrc zmK+d}^EvsYu;{w2w08=4QGAz_0j04~6!82<=fY-LLEXVNE>7oA`e#6$oI#Gxq#w*} zpmr9{mSj>)5Ic}9)b6}Sa~fNa9n2g~0tVSwm^)d5xcT@Y=QZimc#GZP>B;V{rZzq? zp?sk_vEfCeWTdU|YV7vZJTuF&2iO4wQ8;hQ)dvytN(ROY8MwhVzxUXMUU7hJKrq|O z{z4c%Z)&y`%nsf@J1|t?o;#bnt%EQO1`!4Wph}DWp{M4aD_Uag8&6`!2h|yyNUyB zZ|4l}VUUZnCC53HsiV{7Q(ZX3QuM8}$ZDkbKY{ zHUa`R3IKSAiv~!Aill>#L_nei?@XAT1&so{w;gTI$CxveMp_a`MS{)E59Hn<9WY^d!aV$-P|Gp!j@7)ek}3cCW$@ z#5gn-b~pQS)^T}C25u&xK1!1a84$(2YmbfwyX_w6%w%u8!f3YcX5&0P#qstlN$XSz zKFGmy<<(2AzD^YY`+U$lYyO;@uhDLbOC(f3F~EpxFTpF5@uUEtNoA$IADw zI}$o-RO&?KpfX|`^{_hI+A}FfKirw|#Ni9&YYuPQ&?9sZrm5O1dWYGtx{PFVjBSD? zNhnQ@JVyTI2k&6kfLK^~$CIarQcJtXv87f9#g6f4XD%;@A)9_-5<|IDa*=5%)1eQh zldAKCD;w$UzeSI63xz&H8^^!(WbWf=2P#0>qQv`o*0+^c;>?RZZ+F&h$>;z>tve#^ zWAnVx^vP9o5fb{8Ci^`tDa*I9^oC%_+;6^eY5t6eshJGsZOBN-el{f4@GBgT(hRN~l-25?I4AA1s{6Ith8ewyg5ric~W5jx@9{h$&zBIj-W z;SFpdYj(#mL?i?NLZ&WI8;AqfA4*&VgfnDhBt$enAi;T>9vKUWfr`$GihzQGhJ<{f zgp>s5M2J8Dkoug27MT=C>_=!X?!KNJg>xg0sF#tOgSdKcBQp4R&4UjGxaJ`MVziwl z>-v0hLdbRN*J*K>ij$>Cmr%rf@8~LA^3hv@G=WtLoU*(=FlET`EkCWD%#}}BBHzucZB;^} z(HHP^X`un*p$d09@mfs^1|1s>a+0yqa$1saKSCZ$-Ci!tps}kW<8Ia(Xp3l(BE&6! zf(bitMEACvr@xtzr2>^+$RiKCF0oJ~vF;3H;!$CVvq=plGe(C~AFhr&Gp{FWE2WP} zERlit%XAcQ>2U?eFsC7RT2Og|>bX)-e042TO}mrr>nH=OI9Xji973!tDk|_zCDACi zX~c}1I{duZL!{LXna3)^JWe9Fr^O15XXku>s=G=0L!5{BR9CA4f+#m-LUco?G+S1< zqYiI7A|7x$93kzUb>~*#lJql&<@^*_yLl3+9rca2{MNXaz#@K@J9m2Vt=ff#k3t1^ zo+@LJ6+jI3=FwH7n7W?ey9svU6sgLv)!EJ!rduKyBt1WFbMgH$EAM#ZK+i5JhnX^} z%(dn2xtz^DOI6B32U5)gE_rD22SmOEvFd*4@#0s5ht?MOjH zR<|9+VD!_)IjE0#mMBJ32&McRIoyU0d(>~#QYCz@q-ymDbK?zM_h^_1g;**q4?cU40Qc^SWAX@odb1>mX)Rqeqc;no_p%NfU>TsPaB|L#n zfTXIW$At^0hNsX7P_;ZDc2Ey40wCUb1_lAfr7=`@w1;rrywGrDOaink+sFmi+jBA` z0^DDASz40joc5PJ<`Mw%@d)zqU)ke}q!2g1;lE_l|0~P;?)KK~p)^F8G=Ujdb4w$b z$|H5GF0fP4Q$80cD*7a2z;YsBYbCYn#&kMo^6tQv%YkLdbB?1Ii+sIPHwt|-V&?s0 zn7^ci{q(%iMeokQ8;$2*>e(92yMh&m_bQZDKENU4{wJQ1eYBz|r{hfRy)vgynum&3 z$*69ql~!D?pHsJ|h7_j;5|EjGWHlMvY7@Q7lEb3u?J$#O{Ne<3`$R~FTszkwfnyYR z=ToKoM$=Al%l_>=w)!7tF)1@|UIpc*Zn{L*0WZa0<{^A@zWcphCI%^Z8}3FYtePpNeRq&jRj4sKeGb}6s2|2TwdTu-v|<(O*&oOs zd_X<=Jki!adnkNoPFvRx(tmd*BxS+NdD|C#b)Hh)`8!sOZY5`6?w~Vk=&TBw97oDT zd$R*po0>mmML=L(?=l`%qNTkp)V*_#pLk=}N9k)rbpg6(tyo{KUO{;-v*ak4&RBF^ z1~UWOWvlUS22}THF=@6mHThbj;T@&4*YbJ8(fqgjWG*dl075G;0HN`())xU4h!5Ay zOGAqeM1|X1xa9;=p6B5p6C?j)WBa=`#?!HD&vvo=6e)MeDB@L!)@z6$1@s^MWyui` zko`Xb{o8@czjA;GL3huW5Kizlgo8DV1AM;JV27R0Q|v%C@cF4Nrz_X_6VA&g4)9^Z zX~V_obUCBpva+;fi1i7KSKz42@w;4Npk_~0&0fD&L zLHs;?W?)`E9w->h34uBS{r%3Np+@!qx&d9%ozfo$+5g|F9_(my(S+Y-eQ<+y;p$wb zyfjGKTY6kZwFbDCd^U=TVJv10$d4P2YRUMzu&ul2w4ujdvQQ_&*y(0z2{DR&fh2`{ zWgHWy;p}f{J~c)1OZ#QK_sss#5&)&$34i--EJCWz$2FqE^MGwuLG?exUN+JH1;n2-9D z(;=GK-1w;}cv(b;e&W9F(j~#JpXdej4vXC0#V(cA@<{(i?um-G3H(#5wpexHM@^H^uy&5~CY!oLbHyJ$ zyf+JI{>(mmJL0B4b$E^Egl|nA)p4cU{Ib>PtN2z~?D`#X^d4v8RY43JOq&4CN31id zREq1jd$E&7hMm-i}XO+b220>ia)&|ji$Z5GknECBWGi82C|`%Of&l!G5ArEo}{Ycn6-h?=1>&BJju zAAxrA(22F`f0n#=n@MkzVv2gxgPEo$qiZVYjG05_qcuZU$0)_>h{OFfy@QE|`CeYl zKW=*~e2{shUQ2BzmGi+%-@(?VDsqeZ0n_n{^zGnq!n)UJ$vQ}*9}P_^#zS)Il+$hT zJ*{}e`;q9$Cres189mTNKXQpw4-v8rjBeCqJTqk&0yiOt3klzq*rS*gj;~;s#{M}_ zmmcTcXs(7GZ$LN_ykb`WhWnnK>Pp_UpV84GEjk<09CQ6=S4xYrexGJ{O=q^dN=Fu| z#SQ+feZ<_aM(2u34BimYm3<@TStUME$I7355x^5dRz?#XBBQ(Rx9_2&GrAzLS0Uc% zv;hXsEpZfn4>L?n%olSdc(wH=Z05rX^kIh~+KI2koU7 zZ33lu?<0m^)I4ImYrCCfWXnMznqW9zb$dzZW99CPa>UMU%ri<(T1_Q^>RQFsOdyosORJ;?j@$e**e<`~$Cv@Rvo(qQX+r*h`qUccgFh zE1QmX=Gg+L-`wgy^qPNJ7a;@z%`RPy5zqjrm#&kp6{K;s^#)s zo)Ua)nmfWbb~x;y&Yb6d0tfRx7-e%$ycm6w=# z{EvqvKvRxPRKvpydK!X+c$MgG2vV>_En5JfPvE7++m?5O_q|c(vN|)<72kdDT3X2? z%+}=@SaB~9D}ScEhmVeq9@@F{V{HlD{}_~e9|6ZE{N@Q|9x=~hgBMXJFYyqJya)9N>r=?Z%n2 z&T&UUcQM?(F_Y_|gy9-dlFop+irn0E^YaMwS9U))pE@zp951FlWPJdfM#TBnx_7p( zANX{V*MGg+yE#R}C0Q5i^LR?YsZzmHDPD|En+CM;C2E0kU!<7J+Q~mVAronoL9Eug z1ApW`*DXk%e_!9+_Vw&ezx2v!16oI&jX;_rATsSuw$Q*QUFc_LvJ4MtbHcG#wRV&i`j|r@eGfmW_j=a~^2k5r36Og4X+dUiFdN_yWp)jl$ zHIh^!ug>>14VZrZ+Sa`OzDD30folY=5x7R+8i8vBt`WFK;2MEz1g;UdM&KHOYXq(l zxJKX_folY=5x7R+8i8vBt`WFK;2MEz1g;UdM&KHOYXq(lxJKX_folY=5x7R+8i8vB z{vSnP*8mZKJ<~5V)HZ3+tx?*7(%qeuH zYNcB0?9B!gikWwco(0XhS$xmtmJoF#ou4}l-PQcaFHqRX!E?(Br&%~%+xs-cXTi&9 zDQ5!zW2H7}E&0rZVTq4c}hUV*&rN2XXxRzy>26$9$r zyNcuBzN`gK5sjPA8D%Z9!X8XLUAKE-)#GWRP6Id&M<@e!-+ z;jk*&tw^FY@V*{D0p52J7n^Zt0~tn3@o+?JJFG_~wV) z+Nv~5i5QKH()RT|YjGd`A|OFMAI;2!O%REGNWYqLlhZ6Q z3W0R@Yznvh>NnPQP8=YJy&3f4g(P>711A>;kP{#(;qCweTSJ{`%%B!9J2A$ewGE6k zFo+nV9-j(O#X%Zs36uA9glc)JYJ)wk!9oy532_WjcVYO8{kBkN5RJR7jh&OQyBOmI zb7A=Xc{V2_oX8PkF06S^_KF0a5@Wn-i<_Gpha1mDqy;V^At6p6HzzkYJDh^u$pii> zzdO5~6D^zr2F(SJdr&8^BRn(%{JnpgbDkhGdlzRhMn(*pE7p?E&Wvhbi~N<1tQnjOA2%O2Kc5g6FPDH2pCIs$0v8YeO0RA20=7IyTAce2vOn`KXhk{C zJKqL&*=HAtt4{l)#AT0O68@$&|GFkg!{0f82lQ}~gvnh-p@2fpv*7V1F173Y9lwjW z_%5^x>h56g=zOVDe_vAg?;nX9K%GQ6|Ni+uD+(VR7a07v@@JGEA|d>VgFMfUa=G9{H><{fn*N9nVG+sJop2+SUgu^!BfJL@Q@+)j^a}G zb}mkiP$&(2G&qAqIe&ZfKf)MpA^!mRFD?0Hd@lh$kC1X{C`Kg{#=4X?cnQfH~0ek zYy=<;Kt)DDML|YIML|VFLq*59iGgwB1_mJxF4j#FLQ+x^LSo`ul=RfM$Z08viD}qq zXc-upS(wSF*@5g#Kzb%-rgJ6;XlQ5{=gtHa^H9Y(y3c|(b*X9>Ik|n&oXy`XEFyRE{HvxzUNJxmtNGK@C@Sv9n-sh1n zk?~OQZ*xha5@>+X?mQ&q_K$gmPAgU1NTm67osP%MG2jLUF$pQzEqVqr02;Q znXj|nWas3*Eh#N4uc)l5u4!s+X>Duo==|8**Z*x`aOnH+)bz~k-2B3i#ifnSt?ixN zz5Rp3bGZ-zNS9*4|6WS=ALPP=%Y_IJ^M#CdE*Ao#8~j4TLq@sHg^Dk!fd+a=aEIF; zolq*~RdM4DS{}`HA~VOY7{qkEQ}i3>qFqS#uL&0L-;(SP!TywM7=Q&2RfdR%ga?oS z9KH!-N=LlDt}(dQfomQ3|FaG}eTt5jyQrk>yAyMwwwaFhRfZ6t@i&)wM6bqO%w!$~ z82~$>x+NeZHVk0M%#@Cj5yk}gyDO9TmLkCT>qQxjyC{VJk6v77fC0H3iH~Xj5)ztb z31I*(8A5dg1x47OvZrgDBlAoh@lxE2n`GlJ2!~gkUEl zc53!O$RqkpY33MPhzmLOJ-qW1{a#-AW^F})M<)PZRRv&L zzhSJttn_+h*jUB&X#G>A)nje5cDje5C|V^OEy#DqjEo6o<+EzEb)r98B9C%R4-I=C z6xfP14XdU(RuZo(+7SwFnODW?i8KXun$ykR+1bv{4%*I{=4!P{CnL5YHYXq8x=BaS z(*bB#1cXa(;9HfbkrmfexEIV+BbsD;imz5RiXLZ&wFkFLt=V$flr75F)EU8u6>jq0 z&E!`MeCl&Q7`1R;t|>HK!F^RIX;g-ST=EeM!wN!mD7E`K4&VckIrR+~o_vW1Pu-_G ziY1*+tX0faOj!CU={(r=;^1~(1gVjBT{i&%{(;>@{IPpq-^xZr&i~{INw$NG8?hAMeE#ym~XsKt!%_R)0ZI65cg4iQ;l^+f2f4z z(ZO9ze*Tzq4HW@Q83}&)|DriY>AD=LvX%&znY`wIW!^C` z_uL|g$s(D6&XHr58Lrk2l0uZVo&)t@Yw#%pu^dQH@1P>LU3DR5--j2$Bza|lWGkXr zl*P>$ytYm0^L|t_xCWoqyT%LwxsU)2GlDv?dSQ9BRX7Y_MqWPh;wY%C`|ZosDoMfeFrnM$r(K$wkEL&U zNeAjHhpfHHC(3Wuk`8=>D|{*XpQ$5J77oR7E*QtUYtOJoc#n@=wF33XrUgQorA5KP z)i;<{R7v zR2+jEB+R~4__}o`N~B6;DV+gs)DOIr+#n8TFDTkD8CKX0=^G0|Liib|y{O_$uN}VR z`n-1Gl!1gIKz!*!Qc!!}M6%owm^P>1PP^h5sQqzG6g+oIHBks-=K$4JgiQ}kdbnjlJGVWv__NE(vbS!)Xx7b@Tb_GPVXCA3Q=6E`Oc7t2o~Sriws&ts zeO$oXhBl9x==R*7T>#iG)BeBltwntT@zpxc-EKbv7*O}00ayUu|COVqKle#m{X4AQ zLU?ORfCVHZz7%*j$)=nvO8g8olzlc^M94^2DFE}*B{`2ca#V_vd( zk#)|;MVrqCvNQ4RgjtFY^(=+rc$u;?N|_XyEz^-R;67E6C8&1y=gQ#er>gRbG+O69 z7K1y=$6aN3v8WGYQ9TbSdJwJLYAQko1%6U2FLWgAX|$Lb76G;ElL6coBd5+5m+ml@@zmls!8SP;-@mO(n1Z1T8dX|0~7M+6Dwx=4iR*0}A4 zkLoKY>?Y>D$=~cEgt0d^4r2m`U#U)a`8Oglh5^=?3aO|=5(I7$Sn;p7jGOcgtGqu% z4inJ9KCP-4KqhJvItaSk*ow3v`%R~4xJ@I2l4Vds;rUnNvduEf$Hc?p4^W-_92MZk z`^UDP(Bw~IgZ-DLS??k(N@BqAW>rznB8iSAHTdYFQ7t#!7gO(36S@cCqK~@2@z_2J zXSJ?F2cL@S=9y_HJ;Pd0Uy(I%5| z!EseEb~RBvIhLG8H#blG832>rrVcY>KUlx-v4m}3qIx_^Kl2kNavRVni5ZU6p@Y02 zGSXMeBC+Up68_|g5T8M)Sa+mFj-gRjKa}upT%(<=_S3H5XK|ybq}@P{Pa7C*ly(a$ z$-Q7+b>r?(tgkApAs!FRblI|kS#a+M!>0X23|Sw?P0OYc2jgV1aiJI5(NX; z63P89NHCa4Uk(CO)@#~}nJq%wqX)72@2Qv6P@9>!R&nAG*4OSW^@kpu2CK7Y+^$iMYKtUR9I~>Nir2vt7;VdUo*XBteadYiDz0 z&q6$XFf$+^)`FPDj-6`Vhh`tbA)AXQ?niN|pC1WsFE)|-@?%$zgku!dnd|mpDNfp5 z>z;-w!Q%E~&--V9S&37QT$O1BJ_K%<=c6LW&$noADm^5 zyw3rZz~%iZnw>=Tpb?djnyU(_w>E6@6#a(YR7FxH+btKEbj(;?TbHxzIDPLLXXI-) z+y##=J4~si$U6&;!L%@1G(RuB9<^zUQrsuxygICrx=mw53w4z;uzNI#q~o5P1F=7K z-<3wbuBr*uF`>0{Dt{i3Be)nVqad@y(lEkaAv<9iY!i&`7QwZCt5MnM_ z_bAO&5s+HA@2$8vM1wot;T~oE$@u@eiMq@fQ%YWtG|0mDEXMp_ZCEs}Qq%*)W?P1#7UEIH)ukhSOxv-6d>SzcX zvAfgF&0kc^H7s~oSb-g6f?XbkiBn=mhPT9Klb>1hr^nXOhZCFlxskScKk>9^BWEt! z#&ow0cz$nblB>-@@=hIO!s?b`;mdVkOjVGAnME>|^UZgnK16E|`cqI=hE?aeEBW7? z0Rneem&5a3C@t!0;IHYPa@Oe~Z=|Ni_Ybm8o^WsW&Rd7)r1H84FvXOtxLMG-E}Nic z+wHk(N|U3QHy)G*HKM`V1qB-q2c1WCKerYr2SW4h59|;TXv~_Vlp7pm2yjGL@`-2fj()2o z9RH0%Hp_^72ogN%v>GL$tS8oH0}Gh50g<$-bWjUvJyrDysKrG%1GMk-oH$W;S9#y* zUK)}gtW*)xR-0!1bSk!1fq2qnO8?ypg)^;v-*rY_N1#1fKzJcPSy86|O zGEvEU(b5@JMf-YR&H!J!rhgujcgh{J{_y=_vEg=#JzIpn1UD*SXMiW(xF=ZS9A|*W zx@W#k?}JZ+>`8nl#}xsqmW8aRMB5VEJnpq;0Mt#5GXTaR^&wfE2^?V$CM5gTQ>y5e zLmpV^__#q!FI~j$djrn0S=JkP-=00?&XO0yCCgs)l=&8GRM1wNJCOvjV0Wlko=2>e z0!Go1%W3%Gc*Y9mQ~&1%nqM?99g~C#{mEQyRGj9sKgL9G06)wUB=`Ii87rM8_o~vA zYizxANOteL3z*h$!sDZRPPUi(Oi$(@1H2V@Y4)wN8o`tqR=2Wa6Jov>-shH*V@@FM z{=631t-beQtmgGU;lJo?D{d=(gLql9uHQUnudGr8fdb))wvM{sif~-4^^3B7Z(9uS z1aEu&+OMa*d%oY}NRd&7wK#6bC&;R=s17*dO2;Vt75Bf^23WQSj7a)gJMh^mx5IL} za*d4UX=3WeEt0ZlKLruUbGN)h3lRRMvu^=O&@hn8Us^WjE&nBjXMn%$YZUm@263#=j`Pj8ax#}t zx*+X-jJvV2UvD7Z%p;XOFpp7y(gn4Xk}mP)2^5#;)7MqkKP5I#oy~Qli#w)aqL_s5 zjO(%gGoTQLHH=L!^#4-5GJjWXbu^gFL*MnHS7(4%FIp$|1!ALrHFW|$Ztha1XZ`cB zQ2q}`+La>X3>23?X4EdR4ZEv=0Dc)=+gG`ue^p!BMQu4&)VTd>H%#%}bJ~MOjr8M$ zW+>FrRONW93PnzD3Wn02;!6NT+-^5MQb(n3 zwb@#+WxX{f+Jx|ANV78vO|8CK8%JpqWX!}!bP|X*% zjL)&g0X^hYL_{@*>z)YPMQ<#T!uCHA^*7+~xx5R_s>a9 ztvj0|9fH+$8|Bm6)elIq+)hJ>1Bw3I3Zf!Y;bOubx&|{?z1&#L=4S0w-vtW|?ITXH z%f8w1c4_V|tM$`7ZKWd^u6_XDvUx{JZFB1&x3;r%A}SOUHkl&%fMKzK?wJ}4s1=$2 zRfJej8^I9=4SAz8r|=P8p0OHRiIVwu7DcWmd6_1qJsnh3!YDT?&%q4+F&S?dQCBIC zG)s_FhxSwN5M&=dG5H>W{$rB7`*JKTyAE>9F$r`u=wx9rK}@RR_rojWG{@WpG!v{# zk-xNJ70nZ}k$Y?*olHLmM9kth3w~(zq$EU$neyh_E?_eH0(NJJ}v&s73+s|J~_U+kWBEE?bSbcM)awa(FM*i$Q|9u%1E|FAo)IZ z21tdS0Um|DD(a|l4bHjWOsK+MU;EL2kS1PJ_Tflaf4=E0AQj#~^}-6=1pYvcGAHJM z`E!(w7=_-65G|&Cr!zx`)M{`fDzVii@iRuJ>~eB$09g5GocYZxFb_=ti zUtcSLFD&gM?Rr_#!}ZFZI1chJ_v#?!7th9wB|7emL=A^=w40H$=5Xdu)|NhJtVki2 z&x)8ck?)|{L)QM*@}2Yew&A9JOl7lS{=!P|zKz|>+2&P>$FZqVif8cuZg52NZ#SR+ zGRwlGH#@8=K~GAh@)AC5+M z`|&N_06<=1yxJvCcwe2MBI{(&X3krwqk|V0oy5X|qViKlU*r)x@%v2ZC%(>kd^ zM-Q!!pjdRh4I3Wa8=X+(2*gAT?z=yDG}TcdPD`;?M%d5r^li|(V5JOelT4%^_V}W6 zrSlru&?~=o>v#0fb-YcH{Wg^O5GmCSr*6SdxTbv|rFAD6afHm&0S6!^T%@({oQ_p5 zCtuNT5nvR`@l5V1IBKd_pl9zHm2ZkLHls>84*LpwoR__CoXCs*xc>gc!Gru#>%+Qpt6!S9`RD`ODvP0yqWoeG4!>} zi=Aqy8H9ef-8l-r2UlClHJeso33n-vk9o59&3c!x`NbNns$-XQKcJ)x#qHw+E*d?9 zA3gBJ>)-r<_d^E057!(eG|n!01}HAT*MC`1QfxW_5Tu)#>pUDteYx2QvZrsYs(2ow z)P&>8FJ!#es@>bm7p-x_a}c4Bj!mH_)`2^4@dS2CDc>jA*Na(EANt^KC7UCZ^r+=% zC)=So^S=Fb(UU{h+6|0PEs;qnwy9*vw8brfRK{<8>x3v4A}qqT!b&Kgy?K zK(yxCe3OR{604h|b~uVoTr^R(i)||+XU)XQWA30G2$qQaX9ze1a2vRO5#`=zvQQ&8IN|_0~bnMUWClw%*ija z@_+36>YydN?{f1h2Von2dICQg`R!7;JTHPDHX&*#{(0bzkKw1js?~ea?wJeN2;Y@(pyfQ?Yqg9cn#Do*`a{N$Yz9o zz4ZNT#p;1FSbqMF*XkXZu!(`q7RkuGR(l`Xm#_n*>9h}OA^dwzR$LQZ(?5dLQszsI z{eP0js(n@RWhXAJf3&Ek=VGqu%U3v1=e4U9JLPk8c<8<~ z8_6y2xz^fN79t4!@#mW!)XS_x@MFC{PV*qK?f4=cOCfa2i7~6=v`I4yD9FB7J9%YrW6Z^ipmBC60hfUbh9b0zu zUe%-lJdDr$@RL}if;u}Vaa0T6HLS-T3-m+Eo?*)h-e*V{Cw|i0<}*J?o|xXji_p(d zOVpO;dg(trzZ}uxjwid2j%jw8Qf)s$l0dM{@FN6qb{ z`ocB2LW#N9Qybs!d7PO;FnoQZ#forbc{(Ba#!kUb3kiO;<#9hQ-ZKD>=%96ud(^`m zQ>3J6B;wuij+CAwmALIildJuc3sa#}WcU7KF&=WCM=YCfjqz${+sukca;Xf!9Hwt+ zudh#TvQ^E}LM>8pdShArN1`&j^AWUnwk)E_?G6#wNW9>XyhMT+%e~&=t_&6Wsfr3% zvQfx)O#89UVMqR#C!WdG+4>`}ico7XMl&Mhv8kq`T7RsnC1Tgr{x|92n!oki)g<18 zn#ZO~_B0}ph%*2K)mum0EDPx(6U$9G+v(R)bY}QsiX1dgcX88pY`ph-q=##gqo&ad zAHQLl;>cS%@dHNvv7R`IDoz09IJ7S)D z={T`rlf1B>I}>Dvr04rj1Y)K(Xvf>Z_@grO-D^1-0+AzR{s_fiPK^f{_#%b3 z8sBr46%Q1Y-+B6ZBR+*b@zW5hanXHuvIWv2`Thb(UAd)Mb;7q!w5||l&>6rRku_n1 z>S?l?|09Ld7{1SgHx=k&yCULBDFFZn6o8AN{c&J{?{ci~ZCw^@iBrkl=F{h#n?zz4 zo{4DQhhe~l-AyC4UA{l7Z~K$0yG3e$(F?jT2W>922YVEQS;+?y2H)tu)Pbf^zuMbn zj^!x#9l#cv3XKGvyXE@9%O-+W_j_fDmK>EQP=e(tTtZDMmmu1R%f?_{lit<&sTzv>-ZAb{!_l^T zzE(Pdpm(XH5Grn5#;_GV3sY!mhle?{}UAiXa6LxFR`?Qg{tMesoj*#dJgw z-KMcAHs9wio*FUctePw|;0-#uJfc z9(+m@IEoeX^O!346dn@0b0v*&%SjPEC#PN+gwHEH-ULqO9ZBHjSAHDi-!SfBQ5?j` zA(m<}=O@$r0JwB^2 z_-4-oz<>Jj3sG8uHNPq!*f2O=v!jJAP6;U{r6 zXc%VzfoH11=SM1T$E@bX(1R~nR$k3Y2+8RtlS)_+P3zEowpd+{{<2>{3_om( z>=8-23g-*{)RL|4j*>)0-=JT5Mq0LO zSQGcXrf(ceW-9MBQCAEbixt;Pns<(wzyX&BowwHD(^QTN z=Dqqdw?01ixu@-J$VN8~dT?G(%ZP0a=CoPM7P|YMN{&gMtfUYn?)T(Mq^T+6Fd<*KHDhZ0? z&B2++k{i`jvPktYev0A=JxQr}1!FJR#_O?VS#_UP|JXdL$I70XH}!}=xzy^AQGqR` zQVsF2rTu60?v0*Tt9S9;O}gCx;t!Zs7v2jbk`kQd>gyzg5lUK*CYBNIi(PDt7|`KoD76&EQL=yH3*q&w2q z&YlC@&z==&?h(tNWqWI(+gzQe*dd*uTcLB>PYfrFFbEJOIS=1e$QgH!39AdieZ`vw z3q1AAKG{*6DW%WII8vtG`X=%7t#}{W@s8TjQuveS>_jBP58(R=xp1?pv702Z@YZ)i z+nBA>GUxpjQFK`&ykoUa4>P9Bm1Jao(RjbXJy=TH`$mGvZOFp;izagw=-ZaN}zj%|meiT=i&glnhZ4viixn%nOuF@(3{WtpBd*NDrtJ<}N zUpEzT?|yg~AS(ky@p=u`8SY9=`iM^BCs~Nw6n+x9foA$;mE@N5Q<JCvox`BPO)2B=a8uxs-ZX}en9Bso1(K1X48vXs!7@Y@kr8hX;8O?$Qp7V zUlfQ2uz2aH!bhC3ru;gK{-ayJMlvgHx*_~@^dJ6cPfub4>GWQT^=ZB7fu5xCUJLaB z{*JFZsXFSn;A8iZGr%C zs;<2lT#FmTZY(Niol&D2>IBc6xX#Fadsg2yo4@|?QT{to|5}#umov*IRYXV4aU|=6 zwrXL9q9Z1fq87;V1>}M4If(Fss03k|)W^K^8~a1~E*uEx}{^ zfbQ9|@0EMu(TSBlY7Fn=i=LkWEFw9)I74DbO-5gYho^|kI^MW_*X2X!?9T3?ULRbl zp6Sw&rZWIG+&~z&-~Ic!64bh8CnzN5q(qkIqieH0eqw^wkGDb+9qOpLGjYZRgQ0eO ztj}%g7?IsdTE>kBOYqs#A2`TP?G5?5cv8LA!R%NoS7+Gp9`#gBWHn>wqHpe~!}>fk zx|#Q3hRw-@Gsw{3Tr`&=#1@=a`?S?SVLkme_mCs|~JHq+YIe;Vn87gXPR5{p=CU>q}l z)5{kJ=u=I)myZ7Xo?+w0-f^h#nx}V|=?P%4I~ldXH_J%MS?NX9b{in$wbUl=Bc_AC zm$NvmKZ>Za_8Cp6x92!d{j6s<-ZY!*nsA(2i!~}f4@94(%8==3XUt)!r$E-K?`DG} zmq%+WQE@8n_H8vZeXj|iIyt6sX*arRvp47 zs=A(;wXOOZs&D)fxN`>3Q&BshMLI)()8{gQ0tGP&dh@%-JQ z@B81=FqcffXJHqO%%ZE$IuQDZ?)@~OOs#dJfBciK_+UAooSqbL;A05@4_ZhRI8h_M z@66g4(YJhAo>jk+?I03Gq$klaXoCGSc&`7}sTZW81`jh$e4d(<)$dgx)r~f^A{xE! zf&K5Rz594c@A+!4?sNQNy12doh2t*vZxewDth{MQydxhW zn@LZ&W^d{f^a(XCEF0V+Yj5*>hOdTIq0uE`VoZlf7!w>%Ji0dgdQGIg+%UM+t@1Gb zt&tIZefCIfw>=+x#ZlEfk5~Ebz;9=|f`g>Fbe!+?#P?N4CkHUSoAA~{qss?5n zCS!bVsB`PVF5Q7fFcPJ=)W-I1I!;uZhCX36jl;KW1HMd`xN}GrR~{a7&9OR^Se^vq#N(Z7lvGpYymf0?I%=7B4J( znpsQ~&bE6PxwI(GRBpnfSueCmN*AZO=YEo zs|5vh4kc^i`fg;db)r30^cxiy_w2or?q+oFp@DDF0d-1lxz@zM`uNuFl(~a7u|kMgtdrLh{m zFgoXuc_DGfez0EZpi#ni7u*sS!_Z6(+~@P+(?D6CA?H>lk}yiMxSqa3fe&{K!s3xW zyJ+G`3iW&zo*|kyNYRT1=Z;T|OQevWbIV8GpipqHNUSI|?1tb~Oy|E6mwX%3uqJC&OPjJi@&l@{aV&dZdSzgYSDWK1L; zkf8nn;pH}HIGigR?N#|j8x}<=UD)*G!zS2DP#$>95PcqiZ@!-aW)3G#Ykj5l6pq?R z%i{Sx*$FjFEF%88_xSrh)!0)CgA^T?<<4i+`4od36O+9a2nS@upq&uAp{G-gS!QHcMBSv00Dvrhi=?0xVyU( zq;YAixqZHw`R1ItW4C5*)xA~oqpQ1it#`k^*ILhdp4HbP(`DJeuRPf@$@9KY)9U>^ z8}X{5_?fXa^XiB9aX3j6AL=h-WNP6cu7vy0ZCzcJag7lsXswghbwuu@3rB&LMO|a! z?=U$!*8vU^Jb#UNK>rAOjibn`sbd#0g5~7kOD|ocxue=feP*ghfJ>{b;ss67y$rpr zkn5*d$tb%%M1Xd%{RpU*LqubU>St?|>-x#QRT<-(42qh#9xT{ugUjH)E;Na}M*t2hiu9pS zNTy}dOsWLqY4v5>mfW=PX74_87T9d#-E#k0iyRBB z44WoCm21bY{ni?uC^;F*OG#mTKPDezm~Zc=>L7uc;=1$9n_XM#C}DrpgiD6AG6&J; zh?|5QaSkH)eqB9#e8l~NXWRM+%%1@?!u`c%Od4^ivM;vV;%SgmjQ5RvqyO8d#FTSr zTSp9@MHC$m&jPi7?62IE9Mma|UhRpd?8q{f^tuN`^0d89 zpeKYI&mIAjt=_aM#bO?kI#p%rs0(qoSdPeXEsuO!r`MAv59it67azvc zzT`SbRebtu8LAVXkkBN6tE47XqNFD+qz=hXp_`C(9DH&hSw{A3Qh_p&G!i*m8*_-A zXP1mD;&(Gw=>c!+o5s2p$E3mCAlvax19fB`Wps!Be*RJN*O*7baHtOh}~v=UFA2QGU~+khUoPM)I_D4 zZ$vuV;ph;2q~AQeuRY9O42dPui>~o?Vn%;)<>so)NpgLbWfE`y#6aJ&Q9l^US`EY5 z%Cu!YwCTAqxki~3);K-ZSO`uZ-i~Z6h}wQ>QL&!rmGJGDtS^s}}btFMX*<%kD) zpkL3~1s&OOIRaAiAP2LP2OQ?*+JlBahwVthQdf^7k)6`Zgpb^NZ zs9P_VY!K7L5}b{)lzmaEi4g>}Uk?L}VT}6}R5ST)tq_`5ws4T$PVa!&5H zPLSS-m%HkdM6(!NHif)HaHS}1O3^<18MoPjcgS(Wd?07+v>xoO5%eQ z9J8&;X5B1RC}}hWLFIV)ycalV@WY_gn9i3Eq7}N{8<8DuB%6+I`JyC-TT;*=C}M2V zmvD7xU}2{|;-~k?-ih_7uuu;jTvWY)#f8*%{udd&_My~?l$1vE^Rm4-=|#PL^DmKt z-%$7{cJo|#MSxRBhs_Pg>oP`l+V0-|{b$>uaUDD{qybVtn%27`Mx-X#DbNuAocCxA&bZi2|MeiMP@4MKGUS>+yIk~f)Y)rVDM`tO3 zjb6LMTbsww690)x?xfWg%A+p=$y#DdD~c7`j9JntgfclZjE4>hJ9InO^uZ!jHiR`` zw&SDov`CjS>M+H#^4+`P)p6e(f4=N8-Y^^&B7gCntrt-ZWXO^i!s8XO_M8}C!JbFJ z8UDm0U^)2_U<#2w{bWH{LFYj8)4aI2m>q!P|HPv%hIF8H@|FGj4|Go|+8Kz4trDv% z;;b(YnAhbK){YwT%@y4vHr1L#W zHr6gWGM;$BN>O)J2blJyqJWwN_a1I`KBwp!^_3Z~p!6jqs1q2jCj z*&*qa&6j8H?R0SOX|E{UnRUCa5QU3bO|p<*YO0FQGUgVTvDM&%emE;{!cuWC>clPC zNT05H=$tn3?F}1iAE?(JkXPSA=5k}??mmiG7Fm!E*=HRcoCR+dLB7dkbf#*(bx{`~ zs%o0FV}0|vvEHgyGRe)JZXi}26@bPu=XpDIP4c3;vY$nHNxSc)8(^+as>WkfPuzR@ zBPiA?KDn!LazC!O!e-T_908eI67wnF^NuJCwHr4+SZ*z}Y>^1@@)Dh;fWf*iX}Th^ z-R_$*0ruz&bej>bMmsUaxn^whwBdMeXfHob9EwnBc ztd`!#$&f7eQVDVeoueEe_^cg*8+Ny3M}8;B*zi|P&zNrJGb^RSVF?P2h{{v9r(RiE zr|?mBUPtYuo`>rI%&m{OeUtVaf(QwNt&07|6hslM*>8TE`uh7Mx*<9E`tyrA(7RS= zOW3W6dJ=51V}-uHwYBEt5fFOM{6kzW38=kYG?oUyg8b-d|)_vCwK zT@`qsCpsK6_Ypv{-wK4O*M#g-Y0aNE$Ep=jlX=*7Q z5nnHhiLPEnvB0%RzLm_g96Q!#{jdzp6P2NQn%l>J9dim!gX5Jf^Ty!A6tpKl`5dH4 z_hj3mgMT}&`85YNxhNJBh(1FDke8&+2z^WAciR2!Cj5<}vk6@+op1^XOKP*s1*#`qz8@ zg7CN7tgPJ~QRBg%mG_4Tre&fA%GUyB`H^36by7#Jo&>|%^e0J>2}&V#y6;nfz=$o6 z2yC0uT<~jrPho=2hqm4Y1)@fgxD5>S`|3&C7eBi^Z&Xa5J_2fU5=CB_^Bh&c0=Ox$ zKFR}TShY~^U+vJsgaNJ>s$Qgvy6@)Mtl112>-?HnIMLN^ak@4BuEhpiAjltt*>(sn z%)w~GOPN=MBJ!G*SZMr*R(9%BW!32-R)h1X_FWA|ezDgOlqt5$H(`2A8abwsJnuQ0 zyeqP{5{|4gTKvp@x>#S>6H}Jf@i&Rtj(Sa8GRvtAvz0Q)WI4nR_BzloYbn zXAw}PJ{CJ1Ze+}9RCvo2-Bjpjx~EQ*p_!PAVu=zpBo7#!nubqnD^~_7SENqt$%->U z4Y07+yhs4MuTDSR>i({pWszz4MqNv&nLNxISBFka6=`xh;)v$(mV#sQ$QBCC3Oth8 zqHITL!y)ijJ><8};6G0N2IKl@ z!MZ$jIM%;wnn|DOU^Cw%Mt2@*;xOUQ;S32&ntkzH_qn>JP1m9g{W%3M8;-HVe7FIc z!`Kx;KAeA&koCaMi!Lr#cu1+U0h%cP)E*mx0vx3?LAERizZYJQBI@K-U-)M8A~-nf z9H^b7F(-iVl5ssg(#IMifFPOEU4NTP9}3OG-KIJ(j}B?{;U)x@#rLAGhfm}JX+dFQ znQ5h;E#E>7jSJviDQ`rFAdUZs25e0$ZAJ-t~~xNg)mDGZ)377lsuh* zj;dF0dn;>J;eAjLara+!s?1C9L^uBVxl}oll7S$nD($ zExs}9UN_FeAcf{6uRCMV)qudT6J4>d!LJ5uV*v>zsGKqPwLA}7ouE3Pjo zCT?Nf)u{2DQK3DO7i$LP#(mvxjaUhEjfClhi7W^~QDld}N=S{*crDGsTpdQtQRl0VjUq z!VRAeRz@4|Hf*Nb*vcaPUH?_ZGceb7AiBcFzDW9SC%095y))*vZ>(^{aj=U zDP?2W^kUH5ru3y;$tozp47s_6}L2zb`|B}iL?D^cM(M(ujD#`ywir}fPvAog%oOv6z!K3fJy z7aNtmk9*NQQ_=%+56e!qV|OYKh?%HB5Sw=&0h!F1cfb9Dodg_r8ihZ&7dr%g6}m;Z zX*DpEEsa+5g9p=(>_>qA)jjjG)sED@)*scir&6!D82R^pgL+!L?y&rB&KeMCOejq0 zAry3fqk{kp#P6BM@?yG`W0>M1;bpvDWE6?(aw7d*RVBJhexovQYajFvzYzsx%x6pR z&P=#B*zY(Sj_+rPkd26_gRT+knP;2D2WoC<4b2?*uS?#y$1`sCrjUpT*aEv%1xzcZ zDIOA>ho5x@1!jM$Af{+A)>XJ7djyz7K_DL@9y;WI1nds%!fz?prT#Lfo z#mBPp`_ue?K551)Wo)oA`|q;Re{t6o8!NFdHrIB8PK>5&9|2t4VB%Rr=*Qtx02LgTLEN-q)+MuYS z9q@)izQC-kToT_-cy0=z^pcIKVXRa(K2p2;SB=J)F0JYX^6BdMUwQ9{hQE2p(#m(n zOY3$y_XGJ#Q@kz8hAr|J<{GT}=^ABIGB9Fu->cxP=V8cT|0tor-&~wvt+wG@n9$bt z5t(4N@SAxb$EbcA=_GyoD(On*^Q}v+R`yc)cXi85MUEMNemk@St(CeG$l~Xkz!g$v zkGwzvTssf^t#Bk-TTxmdcqb=hg;<8Ylgz}wK@}xn%;$-$=o1O#n3N0T)%`N0@zyH7P8u-by4od4Z<^r_3`SBt zCoR{>$d*AxzyU&L$fIsH#d7%h3v2IYYb)YxRU?=x26JdGYHTb#uT>_qF8oHr9P;+yO2GT- zteduzH}mReEX|L;?r7xv@#;WMdyi7>V|1%qo0_Fm^5xRx1np8u^J(a|TO_}fwFoff zr(@R-Ts&I97~1z!yRhn3A*r>+ji4Z>oT0k$OrK1;ws?~9ac`e>pU=C8wVuPpD;Ib4 zBQ{6q50$aZ@Wk|-WmrC|E2&kVo5sK~OOybi^9#BH15;AuoUr!({{Dlw=v=L_i!#^6 z!`qoO(?YR_!9qesk$`}1fFp=pNW9oxVZHl0>@7cm-P@b8?S+E|6LF?oTI_ekchR}1 zpTYO6u;8EG?@uNyQ&kXG{02W`*@^7lc>%m3Yc-)=x^KFY7DfXugeBJ~|XW|j?Ba@2GW>XdGy_tMr{zr@H#7}W~p6iTg{P( zL_>oetD*dz6hCP9z;?64Vb65}7T+uFG9CGxX)kX^B2Zbx8mH5ye{Zi>DTZR&Mesr1 z4^hEN^&q112tB&>7gSGBy#w-3soNPJu$SL%^Nn}5YOvnbx?YLklN^WfTKUqJHzesK z5l)80g^>ej0e-=TdU?HH?#)<8UQ7)J1i@|1lN+eM$+cpfyR;E5@FFIGs6!nR_f9yDJu!cH(JVGI_81emvG<+|0@2Gj^^0OYD!05QUtG2`g72yryp z)qt#ay2yFA=z&1ZP`8bBR)@CeyJSIeGF;@$lm=n{JyD|QqGDK_--bNphY4aRe5_uP z{=4&#Qby4Dcc&?2rby4I(BK^#2B`|eLRn|(q@AmG@1y&hWmpPW7RyCNa>*RD|0rQltZcsy~@N<*ob*k=kE%rUgq-g zZ;hb~+vQtk(6`=sEiS*m#+AX-{W{c@G{htHA!R*?P3(D~DBTtKuJiUqekgti@+jR9 z`LaJbKoQxWKokLL2&lN2L!3vS%Mk{U$$8kJQLBrE&_V{-IVBy&J~xkOy0qbvnwNsP znTPqLM`B!XyXj67I|)n|B7V2~6FYz2q*6q;D|YW0TkOA*Y5vYz{lat2Cb$9lBSkT> zK}NbDN!Lk8z$>t}dQ;eYHa&4>J~mq;dxT`?Y%ff@X!CRw156YWD&h`R8>H&TTH5eo<}BPOuB%`m7fM zf9S$Dzhx3xtp_G#?WvqdZyarV#e5Q9ZNj!R>jJ&x&a2u>lB4->>QR@>@!HtT<_FiB zi}ASB)P;&B1#bNe%}m*PMYP)3c`X6bM>Lf9$e);j#b}O>nlXl=6v_W5c+P*;_Fp9) z{Ut0RVa!6!@B2!_DV-e`@~pg%CR36T1BvCjtb z(n67{7T#}doLdA|rBVoGpI5ozE-`X6PEJW8;e`O=qCyfn0RB9VFuou!4)4w8L+|ImUJ zF_OnOrBlhKICV*jX@J18^c?h$2;+p{YnEwc%99Ts3ZvOM*_B#Q_yTG!i;6?MDFJLFek_ zF69|md_8A=*>YgPW=bWD#`U}G_HwnEhi-{Luwe!<;fNSC;s8$g2BWXstj-{trI2MND*fD#$LY|0?T6nSxT)MCn%Jl&w*1omi3wDa!qw z`rE1lz1KPmH@B}MmtVOox(VDCXI_fl#x>2UwlH+^HOfhK5ixw4Mp`NztR)uCiOJc# z>t*q=`kD2Nge}fEXRa(i%{I2W3;rxbt88aVL&RoX~Yr_uS z&wy)!TnT{bZvi1K`OFusYG#p5Plake67o}vu1l3)lv?a2bmQ!&(vL1&q=n@Td|$O1 z#4sZGMUFziPw~SITw5YzY)5~=8%2Eg@k3ucN+3Z++z}r>lK8tcmDG+Y{ho@Y_rnAu zYf>q7R03YS=%;1OveGQ$6Ek$-x(jO0*q?I@QWnvrrv7v4_?I-2NZWv$^ra56+DEo4 z;NCs$HYi3OQEh5m3@DtZHUK8}QCI+bKtZ`aUWmR*NCm64%l zaGp)pQF4wkXEIfRhV@-si+MFn)XK>4kLhHQCKrDQo&4XHFn2X}n5P;q5ifX!&@g*B zgWgWmJqz0R%;;pOu~1;Ke|I*tA4h{o8vOzLR>ReIWm4TD?D2cl8fDbA!)elYdKg

IB-~ao z$0d^so_|f#c6ZUvB7ts*HZ5kh=+wijqVZseP-ILJK@4cwb zzb@BO$N&6hmX1ENxXqef*^pf}(U7uzS$5e{YC1{gYm3cws+rs zHb9Ndw{a@JTZtnkep`~1LW`|X4VFJTC1AjP1 z5e9_@^N5j``Zw>~L@2Fw@p(aVm!zETt|h5s?6(v(%znwf0VI~Z8c-uPDwKi5PdD}i8;F1kZmR{jp&MG} zC7j)UTqaMqs4BIQ`2fN6;m}|>)9*`RX4&aCtQ|`-c3xz3QuIH2c+V=4faL0YYuCk- zun((n9ER~SQyN=(B9+3pRC_lMFyE3aW?YX4In(i%dyvg~3pI<4o+du-;RL_k_p`at zWz?-TdoEED0iSOqF5h^P;%@BUWh*%^9Uctk;o=Y|?O?F09TQ(8zIz%C{cg@POsz|MdVUTZ5xH=kg=Q#;a^;>=GXQ$;i zsc^Sbf0q_!W8iUQDs71HJj6_emvmEFuDPZ~?Vl%)vKqq3h{8JoK76I{8j)YnpRQ35 zt(Sf?eyiNOzIfGBpHF7e^I-9=mE|>GL}w5gbSBwn8NPPVvVPahG&L2n0zm1q=!&Q= zZeniV(=_;}TCE}m>xN@oO?wW_xxwM%^f6d?}Gd3QigQk3@K7JrM z;xWi@E+Oy0ja*Jq^W*Y51BVE2Ggba4{m`HEjEn#T)xoK7E|amAP+`Sd znWzBBU_V;k3$a`%wXu0F~vl~2tX1g z)4zX3g8hJs2Z#Bc|zMDPrq=mn+TRJmT6%8ZHUu)p1U_;9_ommxqslzNvl& zle=7jwx{Pc)9~D4h3EUL7A+QGFD0YS;ynSmZQNrk?w~F;Pn-1ZEqjY{9i3hqGKS>A zUDSYfG9N2JahDk7lf}MYO198J4nBY_0pjh%6;d%Q?KU;eX6-5BPCr!VO5=-+2x}M} z;v40@n2V_D)2lxUCE6OVFvn##*ab(W(^_ZovR)jl+B(`@4E|lW%q` zSo0)JanncYfn>Alr|R8}ykYk^xO>T#v(McKVPrOOp1Vv|VJF$WG0tu7TZrCIa>lAY zX6XDg(S@nutkKs!aS2w2g1_j8^J=!7bh=51=mE5XQY)PV)?QxfuQ#68#@k4#O!&^* z7}IJjHkbDpdt^dU927+vFczIw`Jj4fN;-?;P9#51OL7|fkPZjL&`+pHV2RAc1;!(` zCe2n}ZI!DCRdBM^m1_eo{KCUeAX)#%tD~rcxV~-|5<$yrExB(;Gw5upC`uzD9EiRr+iyji?shG8^@mfEKgUUo%$=65qkD@QY=UoGOL=@m~KGl(g^ zsMuVgjgq%bxQMSctztc-u9v2c$X-w@P&OHFJ$NsXdE)Hpq7``*#o%>csW?##_HCF~ z(b|TAffXH0=d%fM3oTTMeL$da5ibLS3=}f1}yN$_L`G&ccASN#s7Hu0U{vb(81B;`E;4yCG{Z;tc&GXKMmG8+U{ z_bC~=rXZa*4jtlET5PrnrnN3@bv%yrr!;a``f>1uZ=>s#2b$m{5I zDJ9MDDmUO7iMMjZ`KM5Uv8_pdk0fv8&UU4`-&#l^q6%el+HQ16I8~VF?nA=>oSi3jO(zN`w?~VJwx+tOsSCA0L1jdsJlU=w#Im9>w6jn|-cl2b%5owBGxDJ!TC=M^P)AwV#g zJ2)WMr#)pbEiJ#(V$eF#tQTxk^AXUltpMjjm>3;cV&$6j7HV>waa_Qu+wVQEN+B?b znpQYJg7|$xG5H9HoDr#5_c3%K6<*<ds0U(Oucvm$48o))|H3P%2p(u!A%2a zs4(MsC4fB&S=V4MIF65YTjb?x2Qy+nntDtpJ>XWdsrSBgvzI^$G>K}Q1tX(QB!we) zbfL_TV`z{_HiM=K7KWNs{%o&BM+hkzs>j!{h>L`YR@D>UPVATNZ{#Z*XIyTsTDDuA z`?Q@!Z@v!Vtv)RISgqVkY~q;~$>f<|;q7bX0JPrTC~N4KACtBDETwRQ$bz_w_e*qf_pZ&uxn>mXUV;fz(o2D9@=1>Jpa znHNq0I^%$H6?A3Ai$eQH8C_EPgTkj1lLXmyT~=^hZrb5*pf&`Bz)9CN=KT}}57U7i zEi+0WhRU$Vp}=fp>5?T8<-EFD{7J3D2PERd(1!bi`jeFkyA8P)Z)n3x9gn0Uy+NBjwUiyWvc!-{+B2k@;IJ4d?18GDm&UAO#1hpkIYt#GUX9?# zB5zI-jOf$_z3oT)>h$WX6?0$wL%a+Q@W;cPw$mxK~;|U8_mR z*}x;f5i=eYcQGCS++-r&O^6uH?D3^(J83O&1KjbY$!44ZeMhSfhrS{t2!gOpKC;L= z_53%X7r|3))kJbNL``)b9UM)3Jx&M5O5H!rUEQK9=I6zo+)IJ)7%kLcA%f8!Sy-|< zQ`{{StMaW8chJ{vwjz^EojYOg*u+_=1E{~I4{=HoMQ=7u93@@L)ilcBs;1J%3Lq0y za>Ziv71vQvOt4u)p$wBYCbe~lC6!e2S?>j+p;fMQj`W6v^w<+sC4cm+EOhl=61T2{ z5(VP@R{UgWfo#Tl+2B02NAANx@*Fz9&0ODJWW*gsbHch?=tY_!X}bJM2kI0X_=v z+GeUs*d&JMMj##D(`1Tz8of5JY2GV7yD+8lRF}(g-_3p(D8+@Uli=LOU>$ZmZ?H%~HpDl{F1WihzOjlu z^3cc%+X-xGraY4u4i=^njR5tYmiS^BI&8M^uMLHh^pSrvdDFKn=j^H8xlYT{c)6&s zdU$eQ1k1>8vU>hpR|JP3vDscykY=O2clRv;!@Izi{%>F3DoJ>Urwr;oG)bS*KU@fy z_T)af;GlU(k9}*KR&R4CqS6GJIpaNV2_)P&^~TmLd9*HGu<(lsop~X-Y{gP8btPce zZ5D6U-F1f*cZPlt0y0=tAF zx(xq;aqcv`JOZfh-rPPQ-oo*(ni+)6H8DLabhW3%(WE75{$q5VK&99wg-L?CP3EWE zFL2Eb{MZabqfXPoKM6qJ33^}!%9W=qJgbYTuga{77VpcrW1}VPba2}@g(4&NJ3oD~ z1OCp`>lLBFP0S-7uQ^3NmJRCQCHzWfSFBSzHz~Mfml^HB*Pid5ada*{ea}#~f5KN$ z7i4mWwi7L>Ll&cO!aWRga3&{Jk5NpJJ0;($IQ#mR!+=u%GTo|bTFB++eiG;Ws=Jp~ z(u(TBfKkjNAlg9}w@W#H%J`Vo?)=c8a4OX?DRL~cM~|d3WK-$x6J}-M{B|KHfA2?^ z`+e-7q}g(q=Z1FukiE{*+Y@FVXh8#cqdE?z$cqS*Sa+)~*7A^rMGTPAj=CLX*H_|k zrMKiZs*-@0-R+Nnw!}os>Q7{^_4VMA--@Q3c8Vq|R@Kw?S4gKWSMl6yhvc4sll|=M zFe_!OP25O{d6O3XQO%0b(ZGHkgH?}!EQ*FlfG>iKx`}8C`_BV8h=If|my{}U8SZf9 z3!oJR&Q>MsRc5l>ANy6kwXJeitZ+km7hs9}%7jE-(in__fJqj{s3&C-{Q|q8BdX zp9c^jT`wa_GlU<8ctB{@9s!WF%m<2#gX6FX1=~{#62jc8I#MNYAf36745qxWe@Vv6 zask^=8|&egDcs>mTO%1`SiBs-2GPEY2g)lL{yq+1On4*)`=ze6Kk|FJywUum8E?`>=Rf6`X@@0`HD<1wYnR`OP`Pwx)M27J#k zPxrJwDO;{NW}ZYN8e)%5fvyoD`!mowSqp+>Rp@t|04JCpmrZmfV&YeTNxkvg-KV@m zir6AiiVE4D8G>90Mk zhoqALqX3azfCD1{yQm~zB2bf_I8{*%6aep*5w!11sOD&n&H&D$9Cez7>3PETpuzPa z|AWA+g#^HXHEStyQ=S13cQ>^a(oXIbZSI4%t&D(EHnOi`xY6!?R_<*d1ZQm!rV3f| zd9`!4zYIX0xm0Xo2TP|Pgh2cW78M;^FIJ2$7UTU;dJiU=J}{z$$B5P&G+jJ=IqWLRa&ofoW?D|Zg-e@psB?uBJlix81y9+F1;ZRn2Sf;@ku&!IpZ5S%x? zxC_!mDdzkn!yOxaZnQ(nN3Cee2f!9)%nF3Tm1A~t=Rsfw9EV>%f0(YRBYn?>(z6-VYi+zb10Mgs d`>#jD2+#9}_xYdC|6GIrc?SOfeg+=r{}-MqJ?;Pi literal 0 HcmV?d00001 diff --git a/docs/images/gitops/gitops.png b/docs/images/gitops/gitops.png deleted file mode 100644 index 5b89b72a2d98bba19834dfa081e12025019054d2..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 316779 zcmZU41z1$u_cn-vAf<>js3;&vNhys;NGsigbobB{@;EcICIW3XUE!Wul25Xt$DAeB1b|*ON4`iL-Jhy*-IQ8VhD{!ZX{lm=`i_Zrh;<~<+dx}%iOTP--T(*=_mcqd)i@J7Zas}t| zFwXO5QW~DP8&hNf^zMEb%;*LZjfrhIyL0(!(l)F7)#uTl$z=pTSC6r`jKCxb4~z>n zXZ4F`Vf1<}{#94($_|X5NbcKKk)P$u>;HI3iOIN!d+Cj&;Js)_0s@0MT^34DO+p}+ z4joVqTbR8U5~-=N|F#a!ieKiN7O*L7Vm>vSssnac=WTTxCMMB`!e_H^}_Zz?+5AQ>0_BkpuF1>bp z;W%AlY+QeOd=#Q27khS9H~y>2))mb~VZk^N<6#w83(WfRdF%|eb(`D78F!p`SvC96(D>=>FDCQ}XYZ>D zBVbeh+q!XncQpMdP7qw8f6(6+wg#(jsN%TpEX{Dm|CVy@-8)@+8k+sb5P#I}8DzR{ z@Z*{M|5=$e*FB(5(3#n5hSYWLGvCeE${n7K_O_WWa*B+{e6~L7Y=Z^t}%P6sHwmG5r=+S!TGmp zys6CB1po6oh<09~9e6@bW>h+#*_Q&6^Kg9hq6if7g0}ptNbuGoXAQ}BfN`8@OyVI1oz4* zh`|xkN)?%h;iI70*gnV|=rF%5`unwjveLbc(O&{e5~IS!E!OVRh?-t&-mU67jDOvo z=-NRps=27!kz^NNW)uF3l?QcU7Ntn?R4BvqWpxXk*v}GiDi2eP>FQQtHQE9jlcUU+ z7=QOI*=(1)`O@UfhRnnI_RWBN+bjgAUG0~OzOa%p#Zo?%FFn)67uDSE02_>xl>lsT zGy1@orzH|OZT71CHG}N)AEBb7L-B~CoW)dQqq@?kzSDn1^?lGL*WPKuqOOHpKe0e? zWegNTxWwN{vh=MSsh=!hoSRYT*RA!>2*hAOC~zw;N|EX9x3}&~n7(F+kJA;*SCH27 zlvCH=oiEgOBj5f#Zyc8J%}UkzP0bP_3DeuhPBifL}<)d)2 zN$XX~FswDh381kVAeaHx0MhHcEHW{To=DO6rVu(jWQkS3Gd9QJjK@ewvArUCv%qGo z2HLLs347GB@A)RRoJTxC@=+4m)k#H0(B_Sq#HX+`vhb5r<=hZ)YIxDEwf4gTDFmJO z&J_^Z1m9s}`MVd7F7|@$Bh^Oj>=H8VXT%g5{alyGHuM3ZZp?D>#0|Qc%0}1z!Ge>Y zTZEp!$HS3%#eUOnM=xuTb|F}lm}0xO*ETU3ygc3qiQwh`+jBuQc4}vJEs-8+7#WI< zm6a`3r8ZCql;2DS%wKh1!gFM|mm6xJb4MI=>37HT8B#$UQU;tt3xW9$xPCuVdP3{~ z$Xv4dQA;GLdRZ3tS$^a*$k*~5|NFHcqA92QhvJWp)+iZ_B|LybPfYy#t?-bPOEt=+ zrd33iBNYPvE#y9*s_lL3MaO9|?bKw|IUYaTM~;|$Fn-2%)j7RB-$#bLF_ELZ3Ewed z64T4iv7Ny0y#mnz*WDOGa3$>YH8=S1jpN3~ma1OzNeij*d;Jz>sVl!V8V7{1>qzbs zLR@#BNL8^toG5`0Jv4^)SEPbdYKq-JlS_vdb(FGpl)c0S%_Eb+FzC6d=-g&a@!1s9 z*!QZy#eVvzxvf*D5|W|{4qJ#rPkmoySMb<(c@$Y2eM*GzVPXmxGU9(3wbM&KSy6Gw zJcAlODLQZ&FEUNf!q6wnjme6)vyQqN6r0YVvivZY?bVQ|#o<8zY8RM9s7WpCI!0%# zwTQ_VEoeDKb>>5}c5ZN5!CNZPqkHNKlZBK#IP~#ndqMK4D>=k7yzt^^Bwo+y3BaCi zrDVWvZB9}7mKCz@=SQA5TfZn{PNCYCPbOlFd#}+WSIxBMax3>TR%SRjpQ-g4myDJD zzZ7;(x)2D-h15ZUMwOfvTyopuBq%_&4vD8(Mqwg=jqrFNVS!USzGcwoST!p6gCX3W zJ-O1#vxWWA!Sue0Bc1enZ{S<&{QJ)N+Q^nYcVRGQJ!Hi)$_Y|!+vHc!wUfBsWO0J{ zSQT~1Gg(zp9UJA#!8b>Y#I4Bb zO}7jSp59t-^y@&?9+eZgp0*^}RU_tKt{k=pJrQInjqWS6{y9|4AH8*IS1D-aRLVT+ z(@rn9XB1{*wzM@*NW!r3j;tT$ACYeBzA^I-LvJd4=!f`xc77<^x)J0h=9+r#m-L3J z#xX`Y0_8Iue_HQA{j0e)SUe%=eEqiyR8w~Y^A0d*3}sk`lvS|0nObH_SoZ{UIvT;5 zO)fE#gx!h@>-+Y5X_CBSx_g|h`(2EZGi<2PyqauU->Ydz^ynpo=e|#e-wxv{xVT zdr#6Mo0uc$eM{Z#67S~BVbU^b(mM}&Zm|A>0T=kx~IzU|L4h))Eqrz2NSy<;jq z%%frpm9$(dYzrwFg!3BHj-@Npo{0t*?wcG@ioBle6=yQTG~GH$gBb_)#qyH)8>0Ql z(pY;=XH_B`B`*LAPbBpZtk5#vq{dr8P{+m_NJ2||r+hbTagmL)OPv*LR?5iSIt1WYJBWk&tF zC}q(?$1MEF2%0zI!|cSDqnf;$UeV@llLO*1;=2=&F}=sTRTcyhc|pP?Z1Zy###*uI z-ib!JMF_#9+AJe=dCYzhkm&&`y0NUgQTo2P1>)+w#p~EtCXryf&D#LJIqC3Yq8ft| zPDc5HdCb3z3V3qu;a&Lf0PA;BcECcZ6YC>5etzAP`tl62->07p3S22x>yp z-s7RM+5>UA->3s8%Y1zd_q>cA{d(>i1;T1*yL%YvNYvZ&eL%a3rx?TS)I?CoqjU2nBpwL%1Snm;h zL(dH}Z=7cAV6Xf=pF5eq7TCYh0`GFj9TluGBaPr?<|MdGlK zB^3l!fQh&Jj|Cpv^81#yS{~lHWhH%uhl>c|pm82lSwRrC>^gj2i?5CTasPBoS*w;= zXAVxh617+s>1Ftx1H^NSmooQhyVI`Mv@;25;@FcDb6EN=i9A0W3>Hyl)tjZNEoz zJ;;^$I&*rwroN;pk?OKEuu4O>{Vp+}y3byDg@8ieUj;7IdQVwqol(q|xh3^S9aNES zpC~^J#G6?M?_6T+h_KbF=Kfio9AzglbYE!p4^HXUT8}f%e*ZZU!LdlzrcqLgw|5*& z{TiJ$ZSV8$RNH#n|EA*h8k#d}>@X|P{@LCN)9Aj5We?Sj$n7A~7d?z^q!pKEQpoan zj)Rqm`tt%ouaA9%TA=uKr-H+;MaS((N}lo=z&<~n*>jFCFlY6I+?l&>su;P6oi$Dl z;cxh?!ZLfkemSN>9pbz*LPhHFiJ{!W4$f@H?&<5<(|IU8p*1K8|8tmrB+#h&rUXOr zqs4wcP7fTa8>tDYm8dQHIV;~BC6bK0)8f7%dZKzDwJimn1&0yMpr*cB4SV&}D87AP zc=XCB%zLjI0S|%9WCe=Hw$MZK2IH+hUkaJojbk`u-xq^vwuW$(8;`DQ==|vIow$Xa zCMfxL*bq~T8`Z$18|Uq~pPy=P*wt#C&1w5xYg;~%h|y-+Xt>nTIO^&jUgrqJ#$>T*ltI?X|ML(D{;U0_^^w>!LeZFTRBOl?;)NgCAD+-xlya&TR|ij zfUDl`iEc_po#NLmzaQg4XS%d9K6!-A^-8FldR4akVujyuk-x!vKCJq}%M?;n1 z%x9@%yF--ytj1QG!W{RqIeUH(F`7_pAC>0MX4nfbjr->*YW$5Ke4TTrN&*YFCsi6$ zkhj--%?X|n@#+Q=>c8z`e8x1|echKqmg1Jq-S81LN)sa9X_F#ZXi_`xTtwa=*Faeu zn_aHhT%|j$IPpuiNo&;l*xI9%PltI3m^6&?RngY*6ZY^YPzOrvDnTQ+FJio>wUnaB zh}6`^NA-T%uA_x!Ju3lnUoVT23OGWsF^AmWcn@dBUZp_`5APH7Abyd^=v&27OHkRIn*+H zo|kGO;2q|HlMya`%57J*+sc=&`SmUD(a#4?uK%8#CiN%4>+|>kUf&z3sy*!sXp!dh znN=Nbl#ft)-M7o4{8@O6b4qYi;B1QgRd^h!@i<|n15%&F^Olws?ZR3{5=3M{X$zX} zQcrKaqx#616K=d+H9i3~E7V}JOO z$H<{8nOm#26`D6U`El9%7@zxB;PKO5)8j*u=8}pzzYC#U1%YS*Ic|_U>y@7t#0iZ& zTXQ(uuCrv4SA0NuXZFRbON_1sX^Po{d}6aPN88D9o4+IG$UhL4m~Z?11l~xa=C{s+ z-Xg-zx056#6`YH}9XKRM0SJX0l(kE7P`xfBvhH8eqXU}0tg~A@?QB2d+Z@!L8@mx8 zCEh-zb$%!5767332&3)Pb~sv- zCH$?O;QHhynx72xZuTdU{E79wlLW>FK|%D*Ddi&_mQH8Gx=}NEEq#7DJi}CgxbaCO z#>Ci#aH1V0zq8$we1+c{CFg0v{%GqM(8Hy=6jR&fl`YszdzMWIC#s2D^IR%;<8v>P z9$nr_yKH5)1K;#bbJREvVf%h6#xyv)7wsh~5_O#Mc$VUz(?-Cr^6bZR=f!PX>34)^BPdR+yO;fE5Hmx=lOL!WOpO$&S%d^5e+_Rh_v3` zyK2)hQSD{Ke1*3>$cQdvoC?#F#ElVS8v6XJc^TRdpZPd0x7W;w6s_y`u`@PkKcB*y zF`S&hcffxhb#s95+A=)O&pE8;KJ;uM#i&qhdm`n1R%rlN-^Z*OKWd!i%0C;^_-d+x zyV{NGntoD1NH$H*J+rsU@cCB2=`#&fCkJnaoDs2IbPU)X%00cIlqhe`_$(-)@KI2) zeO*vA-2y36PK^KI7queC@6LGfe_@U`!@SAi3>qedwDfOkDfu68nFZ~hkjeC3OKDfI$%!#^$4kN}tK|+M#VpTOU?P5j%ftSk5N77L$_}HF zGPf!mvhcrN<7MzMs_pUFnDqh$Ay8{0^rtQjE-=fAq|HRw`i^&B%K516=kjRGr=Gn~ z>+PNJwXuTR^9QsSsNp-!94QdTBy|*zIky$ik$QCRyk=a40qBnA0ha~?W7B6v13B*jBD1=wm*U?`ig$zLI<8|3B zmb@|f7H2H~mAGCIuPG=_pc}q?&{|~rlws7`)4%i^aS5rBl!S1%uyfsMqYPgVR%OOKP+t{h%Pzj7g{hK_ESOs6b47E2+^YC={m&sBPS9vA!yv%bAB zUm@W8^Ipl>d5NPsa{CR_rE6MII~b!NDeg&I=_a99E`7Mi!6M;1{(V9=v!d2MU9!Rn z$5Khk7kE!e5z8xratQH799Da;Z*0c_kmkd_CY49_RKQc6tYyvZcbp>j4vW2J!W9pT zY4ZMcMp!JtLfvX<`&)^+EqF;vhD`7c$fy!|f~pcaNwg}72m6?!9q^&cbRV|y7%iHP zc(99!cl^11N{*l!MA4GKxU6z6DGx}|p4uzp@nzgqa8|sYIF^N!h zf9Rsp&}|fT5~}jatq9u3hohdTshpkRyg=CcT=bZ9-YJ?%c-Z<=W5}ewWtEWQp?P5q69o;v&Ctrso~#CP&*)bV)t=}@ zB%XNbDv%h$>84MTlo{15bg;7KqZIMpB?TXyyj)$N*|Rw*@?p$>8FPsdtzF{dkBW&@ zm(HMJ*p|oA(8rzexdjqso02vE_-eR3(qqDV3#^m{O$+!cBfvXHN^BA7HPpaBvE_x8 znq)kd^5mgN3}tvf&7n23f-h2kjTB6seTSoQUf#$0q#z7Ubkiil=&NDl6CKX5hsWnHls3cN1Xncdv+k zo$*?z%-$<7R?6lZk4&Q9mUl1!;!)DSggcH!l>VaDJ)XG78=|A*iNhWhJhU%z#qOZS zj1!iHs|UG=y4&A8-ATL1kc3|Yl59AMy#NP>eJ8&LRb0KFA*I;9DBm zUrm!Mcqo(?J+zYKr*IG2=(!x$vzhy*xV!x)&9QFfALjpGks|{Bz&D)kXLO&ymLPFt zWmjtTeL0A_`7ga(0kh%?4YrR@;u{+Cp)J-zBo!(e$aQmqc!0<^eA*1~A*eIq#S;Hl zMobhNwOqCg(|Z?^G$lu3r;25gr#X7-=A7huIHzQY0ew&hH2aDGdc-hF<0vY(-xZHh z+hF%=7^l7BKb$u_{O3w#VMTn~r|J&t;z0AlCVzKbztQ(=*R!gO91h-nt{r6jIUCSJ z4|U`(+}iAf{UX5Ux3SwgcKs-V^P5gLZt5aBzCG28pNUOg;PNhK8>()=X@VGR|o2#cYPuKl>Zr z!Moj45TW#Mt(+$gTnIW%_m!;XwMa_7$B?NPn+EadH7;Mk1{t|pz_No*IxdSuo*j46 z`JAphAZbHF8O9qwKZPRwYwLAzqs}=p`?egn#5a#RU9vd~=NBVO(42nngG}D)scRL~ zKe{RI@Z50tt311=M_z+5!}~XbJ>@xr1UmmJPYj7m;mv1qE0*}RDWE_adM2vS7O-B> zAlG1-=H2qPPvF?R_?N_V-+V5(A+={0xxt(SrBc&Lrs9)@fr%%^!ehg+rA0d=;3LH6 zr|#+Qs3ir61iyDuKs%JnXlffxHD5Dz%h9@Hct_RNW(m_48p{=yri1AykYCvM+nmae z{$y#d9MxCe>#PVIW(pvul%D^;@k=+rrM4g~>hG2Mh7DGG58g5nO$4>u)U``^Zs;#E zq7tuCg%jxi6`bU6!8vh&i;TUpDDxZY@*701R~Hcy0y7MdQwCJCyUChvyLJ=zPxb(-oIsPrxp26v zcPKWj>V1bvVt#zmPp5H;-=+aO=BEKYp|vzm(Q-4Se)S>g^SQ zrV+y=BF3cI_bide#I{YX)-&j^Fci`rsgtN+c}pcEK6yn?7aRX-{K6M0(Q%hn zZ2zQRA3H^;IP#GMu(a4@?4Iq38=!~rbQ+02*lCw`UfOTft^CZWF7fUv&r$x-D&|l% z2Ni2BUSggkbMGh)xIj1mjFBi)E6f87Fa+eg+ziTgzb{4B>(>J=Ge@qp)rrHiGGUFI z3u&d(?3>w2$wF>o?{Ben%F(5mt6bW;&7OWwq7fTlbWv%9_O1NWDfR=;I*$`z&p|dn zE{k|W4Gucu4*`)pq7>n`f6dS=|AXj3OhLH)jQE3LR<6n2uThcQ9Gl9yaU=Y{0H%~> zw*MlV{|UgN|7jIOLEnK}7GsvN{!0IYh)qLx<27aFK2XT@m~6|)%4w?D8_Aw5KVzo* z2hRDr1}fEWl;6#H-Tqw&$d&)YP5$Yyo1K^%8#x*zf#fCu!@M&32}ryG%Sw)KA+mnnT zKYQVg{#hj-RZuH%!=l16R<^FH<@YGA==7D3vB%c|B_eQQCqvRQ#mK#r*}Bl7k8doy zoe$VO?*UxT@62)QMX2((D|mP-98lqa_t=!JVcA;nN%<3F8@`rE8qKoSMbVBQtg89Y zfqN76xi$`CM7qgR!169q_K1HnxqrG!bf&(EJ;vt%RzN2}>oZ_Jy__MZ-Z$=aB|8I> zic={x%rH-W1_7TT%XY8`5IB*C={*PTx)TJiJ_SLNPj@fI0q0oViq^~Z! zu7=gbdP#F*n_+ErP+wK}+&=jkRd+fn?XdZc#a-^%7#`d|YwY_!YlMTaYuqtq2j4q1 z0QZu-{|5Mph6ai|woCXT;mu~kesf>zwg&GBL;QOhywz8~SmXhTa$el1D5z0?zvSPX z_1~3Vr^Z%J@rWyxGJ9?BRygK8D6Y#c26RGqBpd**cNDdBpIh}Cr}1JgEB9LV$ag@_ zd|L)i*3LEbunf^(ULoMU#&YF>%H(WSUd>-vpCWSN zZQ zac|3>F?2>eRqkC@RxfL1N2?TdmJ}wFPy#ube+zg}l4VH+^d7?Y6)prK3sa*j2Nf3x z?(ZNs-(6Jnv;oy09n1;P6SK~O)0ei!+Fw5iG`wa=`)K;YaF|1L#?P&+aX#~Xf*0Z& z5G;O=a{KtUh{g~w9KeE(Y@-|tkAECW8v>O^Y7bE&_I@MfwS(0^Nct%R z)Kwtv&f?yN(4~%$Ckh2duBYDWTC?;)mykZ>^BcJcku11GY{kVp&}f`yXq)YRt^|5j z71Ocl2xM}dPX^P^W!A9}1r$t({kCZwA-Nm&R5hDT^)OV3j+yB6V!Tg3bnF)FMltHa z4xx+qA}q{0F!I=22vyQs0O z&a}5@sss7PT-W!zOCmdsGEnTY$Dz<%y{Foj;xQ2gL7`kEAT0c4h=6vnvVw1#{k=yq zCFMVfi)UZlAiAhp5o)&fvTSoav6VPBP|wYq#SNF$2!il8$TAxTmbO?^S%cvHvLp=n z*a-yCEEhZa6`~^?eOr6oF_|)9->Wd=mg!=-`T46WjrNo7u#;ivit(58-t`x#5Q(!p zmKbf|k^AZ4W)>vo#Mr6jitDePqyFRLz2#A{bfKHVR{`d znR-hW=dlOWa9E3B`kzpQO@rS_q~uJR*5k^EVR3$;3i3ROL%X+MGWtGHOr|o){`vth zFb9@q|@DxZ1c&H9OP_eFsEq$S%@g0A%KqeeF%{Ig{2EU zWd76*0w?ZfW{Y*oLh$XSo25pgPLoBpmYgYe7U|tq!Rw8at?xyOUpRp7b75scZC5k+ z%RmCNJ8T$FFjz-G>b)HHyB*^=Fao80;{Wt_39p6HHE&Pd*Q)DlqLrS12K@&Z?c zfaGwMqBFC(Gn&(;z06%Zsq!TghK9Oh>C_mzcvXct>6V@zBl+BzIe4ku{Z{AW)1+~lOPC-qB7@X^dpE#g$Qrzs~NGBT{vw*?>X*>?p2*6NB z!+?sV)6h5}7XD?$9x<`^(f407WW9PYJY(!c`QCO@=9(~O_XEqa#Zy}KHWH!Poz$LT z)=_P6t_2v*+?bUwZ~;^3fY4!na{|7poJ`v-E?~wP_QXDQFkX0*HrH@jnHv?KbXv~g z&hLr-XL#TP4=ME+b_VId3{au24pzv#hPpZ!tI73^M5mCGqG~grK12zsaqfv1E=h!u z1^UC*H=7MW07(qnSAp=05I9;U{h2O1Gq`Y1o;c18_?cm{Z}p%uhr~L2t_%{iI>VZ$P@c??q8tK-*DS@kCrCYJ^$3Of1yhnYw*!AGdyTE$E ze(tK?7TVhY%2>dH;>I8%M#(b6;+A1vS^;0rSDALb$wDR(lOH7pJq$<6_5bVt0y0e{ zselu+{fF}zL%i?+hztNl-W}uZ7$_egm~2ql0usKub+{2_jVwm+`IxoXb@m2JPar>i zi4j}cl9KO%~;55?X`j3t-Ay8{2J-?tU+@6$byb&+n+au|m}czVEYG zpepDwG=-3Ei_B*(R#S*4t@hwr_wJKnnT=7q&hGgUL072z(s(#E`4~6q4WTFhLp=?y z^AsHFFk6AgWBqq)24oCkw*aN8m8II)7Wm=k(0qVBNPnB;3*Km;au{UgP&yB&5Tir- zUbe$)2KAV@4{_o@`!aq}iym5hPK_ezO*o_CVe2dv=vRRA(jHN@y zt9JfqLQfsxv1u>8c0j{y;HJ+F&6kOxvp|X1MW}qf7g}#&ump){v zc_n9{9>!2>xM6dbv(=7ICyu!!P=T?(=yW%K+TjxXAM{)SVrb#uf`?cc&h zAWS26DMm<2l|E`c04fmFV}T-OMT#typr{u^DT19OEf3xGnmi`y8#12qF6pG84WWoQ zp3G@MWeI)tpiSi-an-g`tb^rY6nt#Iy5)~*NF1yLZ|VW!1lb`Qw#1YAv;d^D2UCv# z4jc}==<8=0;MU^rZtKXD(Lv4gj1tP6xe?zxK6%oe0Ym3uI};?!JlljT%z z=a#*=^7ML9KTsJxGi5M}nO=#BPisCo*}akNeG;{?s=8UgSw`B7m>vheQg(Ouxa;L> ze$Qq``YQO+Lr`DO3C&WH11zXZ=q>O2y;*pu>92AZdDw+4Dt}FzdBWQkhDd zS7Xu-8)O~Gnb~qOqGn_n^ba!I*4GK-v@FHa2&WR6p3HZqkE>_|MX4J&+>hzM%vUbW zNkN(OU;W`D#-qXotUx@?Hs&a$ukKDkK6^9WV(vK_~`6-AS z7FU{QAJ%w$8aS9<35%PFNX@)^S+p19U^iE_oVqiLVi0yh<#;OgO2HkApy{q{8XnXwiHQU_ki?CA*fB`e8MNbx?W*_+mTb=`m92r*82_Nmv8*%N^fKJ@%9ws zjLE-)Cn#vIh9pJ@jxWbwV(hy7oHlqB=KSWgqD{az+OkPV;B>X8RZn0y_pOFM!W#`~Wq$3V{3Hcx)Y8U&M2oh`}tKXEPiqX%{X1#K`i%3{s zCb8eXqRp9Pg=HqQ@;NV139Qk@~Dpsf4o= zdX26@c->)D1h4D)pd=&Xyu{E%cL zsbnE4DaI8Nc1eX?%3%R=KzYo+nJ*X<&z?DfNOu6{J}q@A)9`G|wtCF?vM0zt^U&ix z{+4tz*ENKL+IdFwBv9iYa5p(?Cb-CpVufc|pk#-!PXm{CF4eX1)VJDWM$K*!TwLSG zvcL0&sF3;*4H02_B5DA?uCM3J$L7*)tjYY_Bwz462Fy@5%Tk5vE_|}@yuqpVa4Fu1 zVxts5P#?D03bgs%lkTas%#pS}BCCcqxjtWRVC9^RanWOQL$$KX6#e8gSzp_YrM81@-8{ez~I0ZLc0R&Rd3 zAHKQc9d6fRN~P^TVp)s|*abe^xkZ7f?Eq|yu#0^k!b2N0UPUW><`g?BXuWV-(SW&d z5bpEKADV>HKir`q1CKNkRvz_n<{(ZTM{J`{g(UC)H^mSd&=L;V-fAA{RdrbX0-})P z?l8uwv_j;1`O!muU0KRLC((XCotU2wXzz1uo^65TmOqqu$a!d)>@}~2$*p-FX~Ovd*Y;Uh4&Rv0K1Bf?Q#zs0v!=-?@2DyTYOJP_jALU?`Qyq?Cg)qY{bT0R-AmtgWg(A`wMnwZr6`E)oi|A{tG{2TKr zD}&%58Ek!fn>?28F%8M&WIXhR!xcbr6rNdZL&P;7BenfCnSKRY zykS&cVBH5eu(3pCSh*s%(KHAJ8wd)wov)#L%;MT{FsSv1g~7me>Zc zcokAVtn;H%8{E1g@rpY>khetU-+mJM**SagB`qHZXEqtwjT7mMl4)RlFdK9Bz1eRn z0mhGNvRxYXt7(E74+a9{u&=tUOqU3E_%OP?FU!TawK5>7o!BMHt44^#8J0TStvR%I zY0sJRP^ZnJ+N%Mv9d!M`Au6Z*sr1O1+T;(?#!7Yxcdx?=0hgU8qr5 zsrZR&LL%SHlXV`?!KW(E53tRtXj(!9rjN4Q4vBN3%jsuwyA{ht_4_HCgS z9uREI{fb@k18XZTn-R~-U2hti+H4GHd+zar#PbW8yBnv2U!M$j&+&AYB7d3E^&9KC zKFQM_b2|qTYf4J7zH)jQ+QJPlw~V}hp=K~gz2=wH^6={@$&`3*=L8bnX|uS5%i^~C zY{YcZrIljGWJDlnf6Hy+1YTb2qJ3Uku{6(aU{DtoVocelq#SpX!doXZFqF~axP*RE z0F@M=pn>Fts+-KcJK{k_unfKW$_xfgH_DcooCtYOPHpr|y5RAUu#<`a+xS(WQ>@zm z>W@YsKR^=|%70v%3Qj_NRxoHQb^$_$fR^fHOpVQO!LX*LraN%JfoJfsBAv3QVN~2B ze0`!7*>!c}zU_j#GZk3(o_G(-w!*_v{evo^u;SeGP;+&qmv3|VjSOF8Ol!1Ukq9=u zKd4o&HR4Pwb3f*l=h|rB`9fbweJ$qgQsjr#U6u%)I~?>X>Hg^FRj!Uxli+7KL{%NO z^F73NLUEKx;)eiDo>)VskB3T{eKuq}-g2cPwKmv-z+rhU))r&8b?6irc8i2~Ad18p zQsSOPtDhYf<1bnTNQ`zo7;aAy{~jpuUo~YJM)1U{B_!?vler};O3Z)T$@R747 z^IhNNKr9{sNQCs${h!igNw;0FtPORA$d((dQ#p4qfm^SV?Sh4>AjKwzdFExPhU^{> z3|itNsfriySmY8yF?aPMS;=aqvO8iNoF-0!IHS5Byg%#z@EuEGriZef?l5j8dG21R$s{W{I^mK+7R4 z0Rh$f7L5QSYLu8Po3&&aw#~+FE?U^ievMLSnitmiOk!fvEsCXI6(uyKudSE4`h_Fr z=ap+q1}r#(frK7KvHIu?a^Bq3te8T@hlB_R&GXm8ikZS-(76txprs{JwyrPR$Uz{) zU7BA#^&WL1^#f580*7{i@`J!heGQ%M+wlT0J<|jR-v8jB zxJ`gf^n;cviWE#NRG}!@gm5MD(Uox*4y#0|Q}?W~5qsLayRZ1IK7W-5v$fjITox(0 z)-Bhx>eTY4c6VNaV1~kLAGJskp4T;zD@?-Vk_S{9${Cna6}i0F_}QY?*ELes5?PBF z9fxZCg5@Mw-_A3M3?y_S)*Lpk8kG?K=C|H-Ix)(8$=j{#)wU|L}*h z*gBMM&v;7Vk1DyUH*-F2vxPdHRX4Dr%hXzuqD`{fGpOY=dOv)yw%tW#sl`7nzQi-x zCcv{Io^C@dU1xy&41wHkEDl_|d;S@sFRk5NYt)XPIdmCLHY1zQ;mbsI?VmXp%Xx#TARFe*DYb-pfBo zKn5x9GixRzycy9tk*D3ec|wi_eu;2NgSsSfZA(tN5}4RG)5u^*TDN=2J|0oaDm&#e z!UlVs1;_7%Wkkv;Ie3}}p~gsP(+E8cZjBud3m+Z`Lf4-drH7SQ(-42SoUr)nBpGF_ z5mZ=v1dZ`3BG4EsBhr$)Lk`e+7RlX~IU$VRc_leHvK(4PYWDWUz>0aiRmBcI0$hHj z^Sta{(}&`~uoDy2Bllg;sJWFp_OVuY``7X(z4l)T-}<+w)h6fo}|JQ(}wA>tt>_Oa^; z`hG3@bV#|L6n=6f&oZ0qwDtZ-gip`mi2=h(3R$%!Dl1W=ql+C_Hu%yqwu(oHuv(9|Jq{l=mNW0sUO#z!kRu=CE6-zXaj zO*#7G^<-BrkWPZTxfBj&Y8!7_eAxo{oMOWUEnt<@O|~U-s?&NGgBS~?o1i z#J8-GHXbW)Bb?98UFBbUIvbUmf?z-wpooqKvNF6GgxB_=xlEuY5Oe z=O5)?zg8Z6AT1oyD|ltIzCLQZ-0M^51}gu`uqxCGg`nn|tu^&oboCjZpSO1@_pmeS z;{}06$($ihpqeD)$gHG1F98K!BJKB+nyK3;dVo1S7{b+b; zZx-!im`syjsI3b&MH|rr@Yt`?qJjb=VvJ&kuk0Tr0mXbRq!dIpLvY^wy=s8RjH7A= zPo%owG1i%B%Z*d&I52uN;lEbQ5lcR}!0*2o6`&i8t+h%dDf+&QIv=OZXR>Dw@$-}J<0?osw1U-MIjHl|(u%gs*E!?H zfivqmJkNCjCv!CL3mA411Lqkn=c6Foka@DpLh2OfV~ff`UAWy`5k`}@h1ANP;Vs{H zHG21CldEnyWLEO5Hh39Icd#VnS<~a9?!F?(;L~gUk?ztC0Xpg?>Grrwp&|k)W`X^& zv2%nGzpYQ1=m?>fd70}zFLZbq2$p*1fS<56RxxgM%DMw z7U8pU{B-0r*PJ!=s5wp%#fV(hyq>L^$6nLC-|c#huA0HhWl25x@km17zZ8d6N?K+ndF!WR2S&l=`14d$1GMi*Bs z88PSZGhyI2u#ml9Mi{LA>eqGEn=_Rj6@MG38;*gBRtysBk*3IamC%mn4ImS2psb6$i+dZnH%+mQ`& zpNdP2nM_l)us=M9xzgdSC+0sfTAG>keH!9EEnYl23t2wv)LfdWkfl642h;>7;CZY{ zu6arSf@;OV;bB2TgTAt|@{C-~)Fx9wReATVLD7ZVec(}zGH7AY1sA3uIH zTk7iUjI3T;TT=qGasW~1S_Nu(tt7JZjiSnF?kT5UrTpGdKP1Kly zqs)0j<=V_mh-dHjHY$&;$B4Asv%KhTXr6`*{VOUh`PFQJVaL$~Hre*eGqQA9~45us9MR+8y)3k~^d{I{MJb z;LCKFz?49{^{w*7mdE^fz8U>fF(4OHcKGz@@?6;x$@TZP9er*&z!6NW5mnmOP$>)> zv)82gQ>DFp)hQ)Oz%IE1+s5m?G|eaO*5eIu{_M6C$hYcu1r+>Oh6T5>k~!=5~pHC$RXohlb^;Lt-c^ZNNK?IqRBewvDDI zRQh1%gJ8l?uh@2{hPL)g=7U}dRJcW8sL{~ZVKK}dJ}?#Hveg&N_OPej^nqZJPa%T; zS#EJt_*kKE;qoyJ03d7H$I7cO6MR%ewEn3rcUgYz9t7n5(-$(=4Fd#DX`YK= zD3u*YoV+h;l9rb7KovT$Hx}wuIW_9ju^9|?v1KaF zK_Eq`xb@dH>mR|Zi9S7C2ku~$MC#)^a}Ik2*CQM7BW#eY8DM@CE~I#QFv0s{?{&>~ zthN!8rk79AQOua5zi`%kmrVQbd_+MN6+DA;8hz)NKB;u z*hc8d&06k~QZf$88*_Y&YYMi+AKBq!bj))-zPU|%cuq`AXN@#$xx{-gGgQajF#Z?F zZF>G1l$Z3ttyYnfmNxI-x#CQ<6DQ$%sJ*)PryAR2R)J=v0+J?3r5*NCFVFZv9ztc; z|0)o+p4k*(WnF~!Vp>C{qxRL7qYB37&hq1Oxbi*(yzEXXthSiwro)G_EOb*UUuD%k zY`wZ;u%_Ve_vP*7pf_p4r#}R)6Y&i}Ts;Piu3v0Apiwi{fc)eTy=?rR&YTE^Fy!+q zGq+nSYdDmDZj|$2yf|%DIGwWSyaZQz}R`oP2aV z;P;WwX`!@caDQg8>^@#f#0 z``>tW>P@G)HLM$mtml_K>Fna;?-u*FvEdcv`vBUrF3k{1EDk;AGu6o{nC#`f64tu; z8z?SsXO%}fd+PHT+%CN(JUEpiRG4;<0(I|%Ehn80%uHthdGnLz4;FaS?y5C8x#^L? zsaR+D;J4CkVXBRsFmFAyKt9l3#-{F!y_o13wDteqGDlTVIGe_@De?Vw11eE zAbhA>yz`LD&@*TtX7!lLhD*#LBuvlweJ*S{r?yhJ!inP+J6Wf9wDnPwce-^Z|BPD) z-ci^l6HC8^I~F9aGZFTQ49OUu@EjbQ&O92v%^=~dOp4y@>#TEITZ%ROlWfqt*2L*G zI6j#ng-F>mOU88apz`g!7wF@kS@hg(IO(<%|myFVcO+>^idTs#oN6RMz znd4Kl85pws=FlVRh>p2^x(va+U!DkO-9kUX9>gH1@IyAt99vHOsKM^pa6e zpn6SO|LXTk=6P{HT_v8Z+@QKj%dTwngSe`DVT|r%(&Rl&-`xq?P=n`C6vDOmJ`4KW zmX=Ka^@*qL8zD`5noHC0Kbq88U!KeBpQLnl!vXb?7qse@O|tzF*%5)=PT~^OznM?+ z))rb6@k+qEElP44bS*}EabL`*MjDSQYCZOsSNr97GzdLvmm!?CSv~0;4Ayy3r17x8 z4p}jTRmwK{ZjzxaZKm;AQQ}a;b7-unPbaT;1Zk06Ky^DMzvhaSx*?;AT}sqnx!fwj zg2rT=ycxyUuD@IIIeFfT+w5X>Hm=RyFOJSF;l$oEpDvTK$2bR^k0}Q8gy%aw7C*QUhf+q$* zok_GIB$`^Q&veqppN;U^PE88TN5_6#N!cl)d5kz&DrEeOa^^^?%vW31)S=uK@m{4z zlx$j%>rZlpQ{3Ie{7BR?Y_Mvc{7Iu*r+UAvkKMaQ0E{53%y{rNFcBh-50>V1y}rTL zXf#Agb*6nDEkl4ypGc-Gtl*!2jF!oh!@Hi+zP>_orOVgLDeQygBDwU~#7w52O zVhu4F5Hx*n4!7aZ$=9+)lWv83OfdDhDAoz^BEF*Im_s@Wl;`qB{;d4+#w=lk+D<3` zeD~vht-pm5AM5hEM{5L}urF^@_}S34ijRmCZM$?R>9?Y^Kqs^KBtxFBEiyvt(OW|YDE`Uog=UZFyCXI0PsNhF z*WPLjMIo~}3wn;=E^cTJAV{e0QSgUqyCxY%a>Z%CPgYWjP-fCFI8(D=@Acld{a7yS?e}@66m{DQR@Sw4QBG617a-1< zJ+@jBNcE<7PyNH0-eCqcdhIaNjXrC1mYWD66Zqj8)$K-nB-QO{=bZHH<+hl@03>-D zGI3q`LBS7)CF+RMHRhCp>h(A885TOPdVl`>r@hC@TzP|oqVTHf)k>0#$XP0qK)m~2#c<2Mt5c{rssiwlFt!6{LTBu`pk7~unCF| zCD+WaF?>gzZNtZaf(gE2bWuEaPT&{C;_h^x>-9r59xm+cU#C! zN2Gr+J$cKJVRD2UhGr25t56ADJNIAUX*6#Ix&t+Mr#hs3zhUsUHUvnAM4(hi-sE)oz{#(BB)BE2B zEuMZz(B?#U(R~dt|4Zj)>9LFH-9YJGxk&>m;INE zTf;|D`vdwSrV1y$(;*(<$4W}-PSM>@QJQ`LBuy{$TPe*cg2d$iw(4_DfmApXYIb-T zjcKMFkUutw6{O%M<@Ev+5#d85Q1zFj!k-dLPs477U7m*YpU8?-K6ulpxl%K&-RjnS zDDAnGRYcY{I=v|@d>W5Q_dA*D2rr1}os0DfZ!n8%q%UKHESJNA{@Qg?e6YUSmFU|p zoECYD5OXqtaD4y(Mj z37;!|-xii_KetdHzw$-)(a_LXyyY^j5L5uR*@no6_^fz7`pRyDnNmCbP1#s5+6&KV zC57&4bp;r8IUH1(Nb;|b6!iv(HG+g@&f#&4PBa0e4S1PfJNMlYM^f~JD+8FvKz)Z6 znvR^@_4~T4+l^&c_=j_G!zO&+U$4G_Gf6gEDOpR!b8o_mb9#4W?!=aK1@C#2-G$|* zXHA3Fblcx9fsw4UB3Mrt3+PiKI`)Qp^G|whfXFV~Xy}u67*GstTG?5>XOe5MwD;gU zo}jl?cF`vulBg6Z7)z|Y7(*OaL$`=4NPK~D4UzlQ2m$`7&iCbrT%5by5 zE7p;e;(arT-U%P}JvAgq)S{q&)Ku&ColuYDEIL{BbgJGGG0bk4iGJZ6F(V&E@9^vz z+j7O&mvlRQ;_YZr;&o{D8D~BS7$Lj91M_xX6BEN)>gt0-!^0rZy_LLFHR&kFGJ4~x z%W?B3`D13)v@6`6AE)QX#Q6E#1B%Yr;Cgb#2eT^P z|F;whVc^mqvMtd)Jux}KdMlXBH7c0%ffFp;yK+966>n%uBzC`x1^%n`C;^IP*1lu< z;NnY0^IAQB;`@R62223J>JepWGWy3Nt6wT_;Ms4isNL?C;1J!}ey=cHjp|Qs2Cv3Y z*mp^(FJ$DCba70Un4eg>%U@`#ye961j-lWAO;A4RZDU+^C=FMV&@DZM@>HdDDAOgm zx)@1t3u^EBz83ucov*k7Fc>~!BY=vadWXkh$5MQVy8eNGSb*Y|pw9c=tVi4Kc=#cMD>{Wf6Rqv$u9BT{jfY01D|-f;|yX|E(KSdfNtPr6Eiu!A5P7w`4@#- zM?HxaKN}%wIyeWYiQ*cLZ-e}LPY^QOR{?Sb)Y78&_?A1Z($-ZDIXRy#1M%J;ZLrL9^$G>6Ytl zIK1?e7I4*$q;KCpdv`BCa=n69v5W*q!AGr42fk|7trmu+4P(hmS&{){l=a@l3KiKY zSq(fcdD(d{A@!I<-O97O*x#blX)j4VhsGy!zmPFsU!xUp%BShd(}Y%5*0pS=ZKApe&3|J=uw(^^wp{bUIF zfo=X0d=BIPx_u$85I80-vQ!)Q2v<6i*4pl8HTwn&Q@(PtMtf3R(fw-ljRAc9EZ_FSYE-zkFjg80W(r9XUV%7NpEe^FOvL&+3C3yA ziNrb7jqqUVZ}gTZh{AA=HGaS^vpFU3qjtHzylrSm7*at``Y@pzgjmI zJZqxG(&*|Ti477j165)!+G6J7|6a$wZx*G(?ex~Qk>dyqFqp0P<=`8+RG}IHim2 zu3JwB*1`?#9Y_Af1lo!oeEmLQX}m3K$~O5O_+*>IGJKKuwFQ`C(!&e`OH8O5c{Zd581rotIcHyZ-0TA19l5HSd36dcw!W zAt+V)Vyng$_8mX;GQUdkWs0<}qu8)aA;l#3!&^7KCtnu<(Ol<{A4cK&(giSisB(|$ z>h!Dg`n&)5g&&Qf`-{GJ2k*>2{C#BC?}M5|n&O{VT>gY=RM*`H+6vCkIjhmc%coOz@GgrO`RheNkrJ5;6PKJ7bhpbFN%dl z#b{dVJ9(q`6*faIQ;V?}R{iJ=O6O-Ab=ZFPo&g-14)O2fE0jHz4a>ohJ>;m$WxZBP z-JVAB1_+ZiQC7^HBqiUH7R8TmPF*uz21Z^ZzY1)PNyks`u44eF?zkPyG|0PBp7VOT z2u$*7q=Owl<`&GjiLSJXTk%So{3Fdh(mAE2M|`2dC@?Fch2tDJrgdYPG=BdN7ze-3 zZ+yXNf;`Z9@sEU!*O>#C=(_&l;n8KPR&ORohcJYXnKqX}4=h5S4X3WZeLA7%Jf8dU zz%IpIj-|=?{oUn?CsjQ4JCd8@6><@mA;#xV&pWjP-3RYZOoH$+M&^D4yT~GU|SIhjF4(Y_IM>QQ5ov2T%N&dN) zbxI(8wfIs`NqMo8TLSoRZ+|S2JfnMBJ^rdPZt|XtcYwrhQ>DVY9|0_ME*rwF8?8wq z&tz^gy{*gIE}#=~qoCp41szDjaq6c>%m?URo0^^hoC#@m-c!d4P|xxTcUgR@E%Mof zx$G}@4`jv~<`OiKanm z&V9M%YM9<2>IQ3DA70(YVXID2h?9hLYO%ACZuOnxRV9RHc^awj>RdA^le(T>qHV+B zaObx%&6;S_lVn=3NO7-dKY>%D9QOm98hOzH4q$vx3i4p}jkhAvM& zk=_bFU>S9Z-NSf2^Es2f*QnQUd*C@y%kcB!uE#({TLW_ov$6YCJM}%HP2jpI=(;g^ zO%fFC2cLob5Y%n*E-Z_8uxBfflz1KBDI6{|;3OJIBy&C6i$x6%7wCm+Ze9*%?s=MO zH;sp7M$XB*6H#?aSgv zxC?etJJO&?loj6Vv*k2iW)WWFkyypX(nw4okIbphk5Ql;+&MQ%Nh)fkC!y!i`wTJ~amzOXa9z(mb1wV@8L7aJ;~uVbh$A_olKQHL_0ViClY>L1 zmr-s=XF)07ZN6*+Zoxmsq%qRLe<$V-eICG=g4SrRShrpswjSJBxvuBmtMW2%xsv2m z{~=*RtHqGnXvbuR`)rty2TH~p1)Bu|2N)%MUe2>S5Oy%{M2h@}kL*cF*!?F0smj{H zhGRueX*BDRoH#|w84QBIC>1lVbDD@cp(ju?@v@A|0)+Sj{xOsPbr7dtv!3*dy6NuA z%5gp`6mCrPCC#Fv+F+y9l3LafL}YCw+d!i*V=18w&mBym5eT;CTqc&|lEFk0kYBD} z{R)H&A+UQyZwp6Jorxs=_lUA+sKodYC<@1yRIbBVF2fXH8mvfl53@;VRN1c7u_&v; zk~(jAv>ep&!*tSvrhD^<*GC^X6INVahoImvgr6+Q^EO2fhp?vPh9huaJx@bG3_K?H zeiHC4Ha&YLz%Hzz7YuaXKa;DS|B3js4L@S2U>I{dX!OAxnHdg%!VK(b!vCZ6#( z>q%&!Tb(ec91zdu-wgj!Nw;IU=ru*m3h!uYYM6C%h8!TDFPWv5mhWHD95>c^iH*9{ zO5qwMy*vz(?AUpd^?=^oAYzF@P@l~aPC=`@mZiPfm$$_Nj&TpQH%+Pl?0ClRiv-47 zifJ4C-M5`suV?5JM3wm%3&l6syl^GWSNfe%TJ55~I)MOK{(1y$Xfh?Ak2XVrh|wIP6!IvrdCq z`#0l9veH?RGVlHt{Qy(+esLCfjAd>ox!)MJW%}cR{MYV_qJ$1Mq2nB#{m8T- zL*C?k>#E17phQm*< zvkiDi_`zB{+63-bbxbIE(yR`x<&2V*(S;diK42warWTI*WG^a$I9lh4KGR@R4zy}u@rws^L?)M@{nw96-fE1YQEP+IMI%R0h`V!* zhe9_@Pgj=%{133GhkSp*vws&N@Pc~(ITw*V0KUDczM~AN5BRa3F0`z*7K7-CqF>`h zJJ;7^$nD`pl;i0U%B}t;)OJ%uW^hhZfHz}Z(8Lh~kk>F@kv4u-< zT7)0TzuV~IdzKn#zv{*$UV#t&8xyN5swDz(p+Kyb-sw8=;ZaeuDx4cWyYrrbDCqjg z4snV9eM+j+oLD_>DCDyc2yw|15=+eo=GzG9Aa@ z93+b@@L%wCGE)`#eCV3i6OB(rPJDFBnK|57Rw=#eZgrsb?6RRE0z#im3`a~Oi$cNI z2Wgu7ymPvxwPzygwkBg~x%AU1e0$8H+GiNdbY@EuGgCZF{pH5QM|{%4p;*k!MzzCM zBUo9BF|ZRlc9ibbUy&})wg^^eUosP&c9zSo zo9?>N8q8Xso;v{A(+rt;JSV}hDwCV`6gBcazf=n2D*lM@Bt*PEH@3hZwno#|qs`&T z#>UX_Lh%}y^uPvi@bs_#Slx#`Sa*dumi`p91_sx&Ry#wHlQP)mmO(+%?=J#gxtVcB z(jL_hRP|gI%goSXmhTzba>M>18td|1AHD2z_F}wpWIsMmp$Y!0wR#D!ns%+$q?+R z5p7Z2TL0R|z+fEPwGC7W;FZO5UKlJe6L!^r^v#gm&os&X1mL{%;Zspb(jGe{U1dW$ zk9TOCoJooN@q>chXzLH{YBbzPIHtqHX$!W!E*KtbmwIZ+8LgStnEyc4u>1l3iO}8&pCRzp?XP zU$T;z@N7CcZ_>sNyCovN1I(}gX z-hO?2HZ-94(fi>2*SZGZ_D_@}EUK#qk+q=)W;56swIrSWbv0RnG{^vPbgFf9c*I~) z^CI|8=Scy#ih=G8cCre%`4+-<*PmfQgW(bp3lLuteL$XpGU3$k^IHx4FHj-=2d*UH z1St-vJED3c#Q*!te_DjCk-HFAQ}LIhQuDBg-`OzO%^&axw$KU1$mhI_LZ1a z*~DO>EK1~5%kCveCDFvaqEX|F$Tvyum|KP{DJ-gKD;Sk@_e@3S$D3lw2x&74zu)ov6qe-9at4E>M^s9_WW)Sq!^Dr!;SS|fmh<2NZTN}jDsUH-3K z_Bz*;(1*!eBqrTHv>;e+&n22!Mf!8s`0?$r(1M9=o53S4(pzC&$Lll-Y);j3EivEl zX1Oj;T^?%aC>N(gSy5KV#-l2&wOxEI`Y&vmdGdlh&q|V8^3lc^mA)xAoa$c~&fkvU z5&Q}LH!eI-so8B&6LkfxPS>Ds@cvho+AOhtOwY{5aUjcmnX@dYI7WHC!$rK#i^{CW zPLrSemoSlZpoL(uuE79; z6k+z?;cHnBscwSm`*aNJwz^f+pt4=ROx{qvU}S#h=g%KJT{NRZW?)PJYlRO&$=t)Z zIV>Oy>RF1zOe4S?EXkhrw=w6T&3E;qodI|Tme-~C83hN{2uBIvW|&V`-K8GODG5|S zX1f(lhr-gs(Fdt9_yjf8z2PYHIKTp%&B;8Bc-kDs^NYgu;U%J9xAPNjboR9mKPUR3 zj?>QdBfp2+d&@f!6849c@g2)?-$wa4s0Ka@=)xl8S)Le&@xaeGhPsdgdbkax!wXy9oGH~J4jb8&_cL*%~! zJjM2*>Tcf^#jWI!3*iZo#fRw)nC3BPMJI|77qSC zFOj0N7A*x^iqJhPb!Ygtr>!{})VW~DX56zZQ&@rzgKDT*ZEy=CjX;GZ$1kZHQrfSa z@l1bAdB0WKHj@6&a;ykZocCCBxMy}jhpvRmJl$pAxHXU=kW6;z6_|{gLW|yQ^5AG$mct;3XB}=c7>|r~bIUDDmrGT~ z%>|6HE#7S@{g9a~rR$Y|IdqgmnAhlNegJZn&O>}#=j-M7}8#U%Y#EtX@ z*s3BI`^n!c}(?!#W|&*%R* zso6&NJ{7Rs%TPiZxU((c#)Yu{U6zkJp>uG|QRw=HeRu;kIc!%LkrvB1bKX=E@rs|P;kdiMgWUC`q(^ zovKgbzfhASPj+53hGy%MRf^?q2V{Tv!%E!7h9;6AbrQV^?$ zsX!G#H^q_if70tS{_M!G_kzR;h6*`gZ;k+m=~_AVF~mn$qT~g5b;Z`M2P2# z)DXw7@XI@)ag2XV;b53ui{dPUY%_m)=~T2 zsy_cg2+w2s4}*{8CTw$Lt|uU&PAzNkb(XBOnPtv*n*+4eVlK ziVDK6YG3GnrYifu`d`=$WX|wuk+s^Uq~25yjL=g5ceV1B^Z!w;m?})jB|e(!jWx%! za(&pjwz9h}%N%hu4Oft}e6-fl8sQu+p>_B*81?;)L^6n)7XMI{+&KOJH@}3>Goma0 zR+L+(J7LzCR=?MSJ^j7H-Pg>3>QMj88~s4_4b@(8l+43}As%mew`l+gpm5vZp05UI zgnfwN*g#swfJIh-SXWtbJ+HLT!$a1AwZ96;8crm$B5d2`B~4}zcIif^9y5Yv&=}4b z=Qi&kn|*q?gKo@9f!DogFxZSYv1Od3aMg}qV+WHBcRr1*_Xh+e`lm~{_c6svW;o7_k(_H8ES0fno9%gcJReiGY8eFO2{j2GFuF*7^3WQYcxP-6K31NwjonA}sL>#C3cADf@O>B-#ZX~l}h{?sb? zDxdiN?8xD06>hwNhl*FmOp=VHsjqK3SI_SBL*o%;%AbkpeJ#%wOwmy35^G)qvc0BA zjV1Pr^G8*A50)RsX?MVcJj2)NBV#8$(^0x!k&1H2*7zgg&KAX$n=6TveIz3C_cBV& z!h zoM&Sq`P=8Ut(rg6PR`Q{;VYC?tPciwf!`kfYb`g&GkS0jrVv@d+AUgxmvj$omM81?Ee=x1Y0cBoMKu$skztI%Jqz z$7hOzLJyZKo7FGtks2;PX#7tL6P)^*Q>#AvuZvH+9{G2fByLFAJ;_XlS3QxofcD2{ zC7ndwWLGn2RSg*!k>`|strq=5Tycq7Bf&{OsaCZ1;0H5Ab%V6Z5`8pNi&@cFlkp;D zR^xiL)ss}b_c_!MV-VQ#$ZEX8AoY5y#Q77%u^$(CgYbf6rrOC-c$ixVt;#nM(cF2r zwmFa(o`^oeW4b!O-rlPAgb&qSQ>e0+)(u%Jwa*Y^7!z9YOQG5T#RCad+=p`^3`