diff --git a/docs/examples/cassandra/volume-expansion/cassandra.yaml b/docs/examples/cassandra/volume-expansion/cassandra.yaml index 2af300935..99b9ebadf 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 a5fde1955..54962946c 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 a5fde1955..54962946c 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 96ebabb9b..34a52439c 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 3e4cc7086..c001db059 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 05a404670..18d31af14 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 6f8a79573..7dcd303df 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/kafka/volume-expansion/kafka-combined.yaml b/docs/examples/kafka/volume-expansion/kafka-combined.yaml index 8ceb48de5..8268029e1 100644 --- a/docs/examples/kafka/volume-expansion/kafka-combined.yaml +++ b/docs/examples/kafka/volume-expansion/kafka-combined.yaml @@ -12,6 +12,6 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn storageType: Durable deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/kafka/volume-expansion/kafka-topology.yaml b/docs/examples/kafka/volume-expansion/kafka-topology.yaml index 020952c1d..7a0613362 100644 --- a/docs/examples/kafka/volume-expansion/kafka-topology.yaml +++ b/docs/examples/kafka/volume-expansion/kafka-topology.yaml @@ -14,7 +14,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn controller: replicas: 2 storage: @@ -23,6 +23,6 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn storageType: Durable deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/mongodb/private-registry/demo-1.yaml b/docs/examples/mongodb/private-registry/demo-1.yaml index 961d88420..98fc98daf 100644 --- a/docs/examples/mongodb/private-registry/demo-1.yaml +++ b/docs/examples/mongodb/private-registry/demo-1.yaml @@ -6,7 +6,7 @@ metadata: spec: version: 4.4.26 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/mongodb/volume-expansion/mg-replicaset.yaml b/docs/examples/mongodb/volume-expansion/mg-replicaset.yaml index 267d7d20f..1b81b09ff 100644 --- a/docs/examples/mongodb/volume-expansion/mg-replicaset.yaml +++ b/docs/examples/mongodb/volume-expansion/mg-replicaset.yaml @@ -10,7 +10,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/examples/mongodb/volume-expansion/mg-shard.yaml b/docs/examples/mongodb/volume-expansion/mg-shard.yaml index fa31edde8..6ebaa4b50 100644 --- a/docs/examples/mongodb/volume-expansion/mg-shard.yaml +++ b/docs/examples/mongodb/volume-expansion/mg-shard.yaml @@ -12,7 +12,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn mongos: replicas: 2 shard: @@ -22,4 +22,4 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn diff --git a/docs/examples/mongodb/volume-expansion/mg-standalone.yaml b/docs/examples/mongodb/volume-expansion/mg-standalone.yaml index 3ca467d3e..622dd35b7 100644 --- a/docs/examples/mongodb/volume-expansion/mg-standalone.yaml +++ b/docs/examples/mongodb/volume-expansion/mg-standalone.yaml @@ -7,7 +7,7 @@ spec: version: "4.4.26" storageType: Durable storage: - storageClassName: "standard" + storageClassName: "longhorn" 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 831359f85..a8b602a12 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 831359f85..a8b602a12 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/solr/autoscaler/combined.yaml b/docs/examples/solr/autoscaler/combined.yaml index 6265d5f23..2bdf3705f 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 b3d6138c8..c9fb65c97 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 03c46f37f..46d130a86 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 03c46f37f..46d130a86 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 de720d8b1..45201f775 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/volume-expansion/topology.md b/docs/guides/cassandra/volume-expansion/topology.md index bb0da4d77..7b24c3c9a 100644 --- a/docs/guides/cassandra/volume-expansion/topology.md +++ b/docs/guides/cassandra/volume-expansion/topology.md @@ -55,7 +55,7 @@ longhorn-static driver.longhorn.io Delete Immediate ``` -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. +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. Now, we are going to deploy a `Cassandra` combined cluster with version `5.0.3`. diff --git a/docs/guides/elasticsearch/autoscaler/compute/combined/index.md b/docs/guides/elasticsearch/autoscaler/compute/combined/index.md index 047ae9f12..609035708 100644 --- a/docs/guides/elasticsearch/autoscaler/compute/combined/index.md +++ b/docs/guides/elasticsearch/autoscaler/compute/combined/index.md @@ -59,7 +59,7 @@ spec: storageType: Durable replicas: 3 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/elasticsearch/autoscaler/compute/combined/yamls/es-combined.yaml b/docs/guides/elasticsearch/autoscaler/compute/combined/yamls/es-combined.yaml index 905c8e86a..cb73c3ed3 100644 --- a/docs/guides/elasticsearch/autoscaler/compute/combined/yamls/es-combined.yaml +++ b/docs/guides/elasticsearch/autoscaler/compute/combined/yamls/es-combined.yaml @@ -9,7 +9,7 @@ spec: storageType: Durable replicas: 3 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/elasticsearch/autoscaler/compute/topology/yamls/es-topology.yaml b/docs/guides/elasticsearch/autoscaler/compute/topology/yamls/es-topology.yaml index 7252e0da0..53c8110ac 100644 --- a/docs/guides/elasticsearch/autoscaler/compute/topology/yamls/es-topology.yaml +++ b/docs/guides/elasticsearch/autoscaler/compute/topology/yamls/es-topology.yaml @@ -12,7 +12,7 @@ spec: suffix: master replicas: 1 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -22,7 +22,7 @@ spec: suffix: data replicas: 2 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -32,7 +32,7 @@ spec: suffix: ingest replicas: 1 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/elasticsearch/autoscaler/storage/combined/index.md b/docs/guides/elasticsearch/autoscaler/storage/combined/index.md index 8bd4ef23f..4a19920ba 100644 --- a/docs/guides/elasticsearch/autoscaler/storage/combined/index.md +++ b/docs/guides/elasticsearch/autoscaler/storage/combined/index.md @@ -48,7 +48,7 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h +longhorn (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h topolvm-provisioner topolvm.cybozu.com Delete WaitForFirstConsumer true 9h ``` diff --git a/docs/guides/elasticsearch/autoscaler/storage/topology/index.md b/docs/guides/elasticsearch/autoscaler/storage/topology/index.md index 4d2fc4fc0..4718d6051 100644 --- a/docs/guides/elasticsearch/autoscaler/storage/topology/index.md +++ b/docs/guides/elasticsearch/autoscaler/storage/topology/index.md @@ -48,7 +48,7 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h +longhorn (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h topolvm-provisioner topolvm.cybozu.com Delete WaitForFirstConsumer true 9h ``` @@ -75,7 +75,7 @@ spec: suffix: master replicas: 1 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -85,7 +85,7 @@ spec: suffix: data replicas: 2 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -95,7 +95,7 @@ spec: suffix: ingest replicas: 1 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/elasticsearch/gitops/_index.md b/docs/guides/elasticsearch/gitops/_index.md new file mode 100644 index 000000000..dff747a57 --- /dev/null +++ b/docs/guides/elasticsearch/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: Elasticsearch GitOps +menu: + docs_{{ .version }}: + identifier: es-gitops + name: 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 000000000..dd9ecc615 --- /dev/null +++ b/docs/guides/elasticsearch/gitops/gitops.md @@ -0,0 +1,805 @@ +--- +title: Elasticsearch GitOps Details +description: Elasticsearch GitOps +menu: + docs_{{ .version }}: + identifier: gitops-elasticsearch + name: Guides + 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 + +Registering a Git repository in Argo CD using SSH authentication + +```bash +argocd repo add \ + --ssh-private-key-path +``` +Creating an Argo CD Application to deploy resources from the repository into a Kubernetes cluster +```bash +argocd app create \ + --repo \ + --path \ + --dest-server \ + --dest-namespace +``` + +## 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`. THe reconfig file is created 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, + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: es-rotate-auth + namespace: demo +type: kubernetes.io/basic-auth +stringData: + username: elastic + password: elasticsearch-secret +``` + + +Now, we will add this file to `kubedb/es-rotateauth.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── es-configuration.yaml +│ ├── es-rotateauth.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.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`, the authentication file is created the `Elasticsearch` CR is updated and the authentication file is created 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/elasticsearch.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.enableSSL` 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 es-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/es-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-rotateauth.yaml +│ ├── es-secret.yaml +│ ├── es-issuer.yaml +│ └── Elasticsearch.yaml +1 directories, 5 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 `enableSSL: true` and `tls` fields in the spec. + Commit the changes and push to your Git repository. Your repository has been successfully synchronized with ArgoCD. The `Elasticsearch` CR has been updated, and both the `issuer` and the corresponding `secret` have been created in the 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 + +- 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 000000000..a2e2642a3 --- /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/elasticsearch/volume-expansion/combined.md b/docs/guides/elasticsearch/volume-expansion/combined.md index e3c9cf7f1..fa2273aca 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/elasticsearch/volume-expansion/topology.md b/docs/guides/elasticsearch/volume-expansion/topology.md index 45017e31c..65949ec03 100644 --- a/docs/guides/elasticsearch/volume-expansion/topology.md +++ b/docs/guides/elasticsearch/volume-expansion/topology.md @@ -50,10 +50,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `Elasticsearch` combined cluster with version `xpack-8.19.9`. @@ -75,7 +75,7 @@ spec: master: replicas: 3 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -85,7 +85,7 @@ spec: data: replicas: 3 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -94,7 +94,7 @@ spec: ingest: replicas: 3 storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -129,15 +129,15 @@ $ kubectl get petset -n demo es-cluster-ingest -o json | jq '.spec.volumeClaimTe "1Gi" $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-11b48c6e-d996-45a7-8ba2-f8d71a655912 1Gi RWO Delete Bound demo/data-es-cluster-ingest-2 standard 22h -pvc-1904104c-bbf2-4754-838a-8a647b2bd23e 1Gi RWO Delete Bound demo/data-es-cluster-data-2 standard 22h -pvc-19aa694a-29c0-43d9-a495-c84c77df2dd8 1Gi RWO Delete Bound demo/data-es-cluster-master-0 standard 22h -pvc-33702b18-7e98-41b7-9b19-73762cb4f86a 1Gi RWO Delete Bound demo/data-es-cluster-master-1 standard 22h -pvc-8604968f-f433-4931-82bc-8d240d6f52d8 1Gi RWO Delete Bound demo/data-es-cluster-data-0 standard 22h -pvc-ae5ccc43-d078-4816-a553-8a3cd1f674be 1Gi RWO Delete Bound demo/data-es-cluster-ingest-0 standard 22h -pvc-b4225042-c69f-41df-99b2-1b3191057a85 1Gi RWO Delete Bound demo/data-es-cluster-data-1 standard 22h -pvc-bd4b7d5a-8494-4ee2-a25c-697a6f23cb79 1Gi RWO Delete Bound demo/data-es-cluster-ingest-1 standard 22h -pvc-c9057b3b-4412-467f-8ae5-f6414e0059c3 1Gi RWO Delete Bound demo/data-es-cluster-master-2 standard 22h +pvc-11b48c6e-d996-45a7-8ba2-f8d71a655912 1Gi RWO Delete Bound demo/data-es-cluster-ingest-2 longhorn 22h +pvc-1904104c-bbf2-4754-838a-8a647b2bd23e 1Gi RWO Delete Bound demo/data-es-cluster-data-2 longhorn 22h +pvc-19aa694a-29c0-43d9-a495-c84c77df2dd8 1Gi RWO Delete Bound demo/data-es-cluster-master-0 longhorn 22h +pvc-33702b18-7e98-41b7-9b19-73762cb4f86a 1Gi RWO Delete Bound demo/data-es-cluster-master-1 longhorn 22h +pvc-8604968f-f433-4931-82bc-8d240d6f52d8 1Gi RWO Delete Bound demo/data-es-cluster-data-0 longhorn 22h +pvc-ae5ccc43-d078-4816-a553-8a3cd1f674be 1Gi RWO Delete Bound demo/data-es-cluster-ingest-0 longhorn 22h +pvc-b4225042-c69f-41df-99b2-1b3191057a85 1Gi RWO Delete Bound demo/data-es-cluster-data-1 longhorn 22h +pvc-bd4b7d5a-8494-4ee2-a25c-697a6f23cb79 1Gi RWO Delete Bound demo/data-es-cluster-ingest-1 longhorn 22h +pvc-c9057b3b-4412-467f-8ae5-f6414e0059c3 1Gi RWO Delete Bound demo/data-es-cluster-master-2 longhorn 22h ``` You can see the petsets have 1Gi storage, and the capacity of all the persistent volumes are also 1Gi. @@ -712,15 +712,15 @@ $ kubectl get petset -n demo es-cluster-ingest -o json | jq '.spec.volumeClaimTe $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -pvc-37f7398d-0251-4d3c-a439-d289b8cec6d2 5Gi RWO Delete Bound demo/data-es-cluster-master-2 standard 111m -pvc-3a5d2b3e-dd39-4468-a8da-5274992a6502 5Gi RWO Delete Bound demo/data-es-cluster-master-0 standard 111m -pvc-3cf21868-4b51-427b-b7ef-d0d26c753c8b 5Gi RWO Delete Bound demo/data-es-cluster-master-1 standard 111m -pvc-56e6ed8f-a729-4532-bdec-92b8101f7813 5Gi RWO Delete Bound demo/data-es-cluster-data-2 standard 111m -pvc-783d51f7-3bf2-4121-8f18-357d14d003ad 4Gi RWO Delete Bound demo/data-es-cluster-ingest-0 standard 111m -pvc-81d6c1d3-0aa6-4190-9ee0-dd4a8d62b6b3 4Gi RWO Delete Bound demo/data-es-cluster-ingest-2 standard 111m -pvc-942c6dce-4701-4e1a-b6f9-bf7d4ab56a11 5Gi RWO Delete Bound demo/data-es-cluster-data-1 standard 111m -pvc-b706647d-c9ba-4296-94aa-2f6ef2230b6e 4Gi RWO Delete Bound demo/data-es-cluster-ingest-1 standard 111m -pvc-c274f913-5452-47e1-ab42-ba584bdae297 5Gi RWO Delete Bound demo/data-es-cluster-data-0 standard 111m +pvc-37f7398d-0251-4d3c-a439-d289b8cec6d2 5Gi RWO Delete Bound demo/data-es-cluster-master-2 longhorn 111m +pvc-3a5d2b3e-dd39-4468-a8da-5274992a6502 5Gi RWO Delete Bound demo/data-es-cluster-master-0 longhorn 111m +pvc-3cf21868-4b51-427b-b7ef-d0d26c753c8b 5Gi RWO Delete Bound demo/data-es-cluster-master-1 longhorn 111m +pvc-56e6ed8f-a729-4532-bdec-92b8101f7813 5Gi RWO Delete Bound demo/data-es-cluster-data-2 longhorn 111m +pvc-783d51f7-3bf2-4121-8f18-357d14d003ad 4Gi RWO Delete Bound demo/data-es-cluster-ingest-0 longhorn 111m +pvc-81d6c1d3-0aa6-4190-9ee0-dd4a8d62b6b3 4Gi RWO Delete Bound demo/data-es-cluster-ingest-2 longhorn 111m +pvc-942c6dce-4701-4e1a-b6f9-bf7d4ab56a11 5Gi RWO Delete Bound demo/data-es-cluster-data-1 longhorn 111m +pvc-b706647d-c9ba-4296-94aa-2f6ef2230b6e 4Gi RWO Delete Bound demo/data-es-cluster-ingest-1 longhorn 111m +pvc-c274f913-5452-47e1-ab42-ba584bdae297 5Gi RWO Delete Bound demo/data-es-cluster-data-0 longhorn 111m ``` 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 f35bfdd43..cb807a1ba 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/ferretdb/concepts/catalog.md b/docs/guides/ferretdb/concepts/catalog.md index b28df36fb..d3b322bcd 100644 --- a/docs/guides/ferretdb/concepts/catalog.md +++ b/docs/guides/ferretdb/concepts/catalog.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is FerretDBVersion -`FerretDBVersion` is a Kubernetes `Custom Resource Definitions` (CRD). It provides a declarative configuration to specify the docker images to be used for [FerretDB](https://ferretdb.com/) server deployed with KubeDB in a Kubernetes native way. +`FerretDBVersion` is a Kubernetes `Custom Resource Definitions` (CRD). It provides a declarative configuration to specify the docker images to be used for [FerretDB](https://docs.ferretdb.io/) server deployed with KubeDB in a Kubernetes native way. When you install KubeDB, a `FerretDBVersion` custom resource will be created automatically for every supported FerretDB release versions. You have to specify the name of `FerretDBVersion` crd in `spec.version` field of [FerretDB](/docs/guides/ferretdb/concepts/ferretdb.md) crd. Then, KubeDB will use the docker images specified in the `FerretDBVersion` crd to create your expected FerretDB instance. diff --git a/docs/guides/ferretdb/concepts/ferretdb.md b/docs/guides/ferretdb/concepts/ferretdb.md index 6999d2c2e..0b490ef85 100644 --- a/docs/guides/ferretdb/concepts/ferretdb.md +++ b/docs/guides/ferretdb/concepts/ferretdb.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is FerretDB -`FerretDB` is a Kubernetes `Custom Resource Definitions` (CRD). It provides declarative configuration for [FerretDB](https://www.ferretdb.com/) in a Kubernetes native way. You only need to describe the desired configuration in a `FerretDB`object, and the KubeDB operator will create Kubernetes objects in the desired state for you. +`FerretDB` is a Kubernetes `Custom Resource Definitions` (CRD). It provides declarative configuration for [FerretDB](https://docs.ferretdb.io/) in a Kubernetes native way. You only need to describe the desired configuration in a `FerretDB`object, and the KubeDB operator will create Kubernetes objects in the desired state for you. ## FerretDB Spec diff --git a/docs/guides/hazelcast/autoscaler/storage/hazelcast-storage.md b/docs/guides/hazelcast/autoscaler/storage/hazelcast-storage.md index bb4e29719..1f5d83401 100644 --- a/docs/guides/hazelcast/autoscaler/storage/hazelcast-storage.md +++ b/docs/guides/hazelcast/autoscaler/storage/hazelcast-storage.md @@ -50,10 +50,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `Hazelcast` using a supported version by `KubeDB` operator. Then we are going to apply `HazelcastAutoscaler` to set up autoscaling. @@ -120,8 +120,8 @@ $ kubectl get statefulset -n demo hazelcast-dev -o json | jq '.spec.volumeClaimT $ 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/hazelcast-dev-data-hazelcast-dev-0 standard 40s -pvc-f068d245-718b-4561-b452-f3130bb260f6 1Gi RWO Delete Bound demo/hazelcast-dev-data-hazelcast-dev-1 standard 35s +pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 1Gi RWO Delete Bound demo/hazelcast-dev-data-hazelcast-dev-0 longhorn 40s +pvc-f068d245-718b-4561-b452-f3130bb260f6 1Gi RWO Delete Bound demo/hazelcast-dev-data-hazelcast-dev-1 longhorn 35s ``` You can see the statefulset has 1GB storage, and the capacity of all the persistent volume is also 1GB. @@ -236,14 +236,14 @@ Let's exec into the cluster pod and fill the cluster volume using the following $ kubectl exec -it -n demo hazelcast-dev-0 -- bash hazelcast@hazelcast-dev-0:~$ df -h /data/hazelcast Filesystem Size Used Avail Use% Mounted on -/dev/standard/pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 974M 168K 958M 1% /data/hazelcast +/dev/longhorn/pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 974M 168K 958M 1% /data/hazelcast hazelcast@hazelcast-dev-0:~$ dd if=/dev/zero of=/data/hazelcast/file.img bs=600M count=1 1+0 records in 1+0 records out 629145600 bytes (629 MB, 600 MiB) copied, 7.44144 s, 84.5 MB/s hazelcast@hazelcast-dev-0:~$ df -h /data/hazelcast Filesystem Size Used Avail Use% Mounted on -/dev/standard/pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 974M 601M 358M 63% /data/hazelcast +/dev/longhorn/pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 974M 601M 358M 63% /data/hazelcast ``` So, from the above output we can see that the storage usage is 63%, which exceeded the `usageThreshold` 1%. diff --git a/docs/guides/hazelcast/concepts/appbinding.md b/docs/guides/hazelcast/concepts/appbinding.md index a69ba02cd..9f6a1f494 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 f592b22c2..0ed2c5267 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 191cffd4f..4b19ab292 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/ignite/autoscaler/compute/compute-autoscale.md b/docs/guides/ignite/autoscaler/compute/compute-autoscale.md index 5c56c2a38..915eb2c04 100644 --- a/docs/guides/ignite/autoscaler/compute/compute-autoscale.md +++ b/docs/guides/ignite/autoscaler/compute/compute-autoscale.md @@ -58,7 +58,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn storageType: Durable deletionPolicy: WipeOut podTemplate: diff --git a/docs/guides/ignite/autoscaler/storage/storage-autoscale.md b/docs/guides/ignite/autoscaler/storage/storage-autoscale.md index 01cecd880..53db46cfc 100644 --- a/docs/guides/ignite/autoscaler/storage/storage-autoscale.md +++ b/docs/guides/ignite/autoscaler/storage/storage-autoscale.md @@ -48,7 +48,7 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) rancher.io/local-path Delete WaitForFirstConsumer false 79m +longhorn (default) rancher.io/local-path Delete WaitForFirstConsumer false 79m topolvm-provisioner topolvm.cybozu.com Delete WaitForFirstConsumer true 78m ``` diff --git a/docs/guides/ignite/volume-expansion/volume-expansion.md b/docs/guides/ignite/volume-expansion/volume-expansion.md index b78d9fd82..96e0a9407 100644 --- a/docs/guides/ignite/volume-expansion/volume-expansion.md +++ b/docs/guides/ignite/volume-expansion/volume-expansion.md @@ -49,10 +49,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `Ignite` standalone database with version `2.17.0`. @@ -70,7 +70,7 @@ spec: version: "2.17.0" storageType: Durable storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -101,7 +101,7 @@ $ kubectl get petset -n demo ig-standalone -o json | jq '.spec.volumeClaimTempla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-d0b07657-a012-4384-862a-b4e437774287 1Gi RWO Delete Bound demo/datadir-ig-standalone-0 standard 49s +pvc-d0b07657-a012-4384-862a-b4e437774287 1Gi RWO Delete Bound demo/datadir-ig-standalone-0 longhorn 49s ``` You can see the PetSet has 1GB storage, and the capacity of the persistent volume is also 1GB. @@ -227,7 +227,7 @@ $ kubectl get petset -n demo ig -o json | jq '.spec.volumeClaimTemplates[].spec. $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-d0b07657-a012-4384-862a-b4e437774287 2Gi RWO Delete Bound demo/datadir-ig-0 standard 4m29s +pvc-d0b07657-a012-4384-862a-b4e437774287 2Gi RWO Delete Bound demo/datadir-ig-0 longhorn 4m29s ``` The above output verifies that we have successfully expanded the volume of the Ignite database. diff --git a/docs/guides/kafka/autoscaler/_index.md b/docs/guides/kafka/autoscaler/_index.md index 22a1e3830..c6d7e89ab 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/autoscaler/compute/combined.md b/docs/guides/kafka/autoscaler/compute/combined.md index fc9c6a676..33e02d8f9 100644 --- a/docs/guides/kafka/autoscaler/compute/combined.md +++ b/docs/guides/kafka/autoscaler/compute/combined.md @@ -72,7 +72,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn storageType: Durable deletionPolicy: WipeOut ``` diff --git a/docs/guides/kafka/autoscaler/compute/topology.md b/docs/guides/kafka/autoscaler/compute/topology.md index 05dcb0814..3fec81c71 100644 --- a/docs/guides/kafka/autoscaler/compute/topology.md +++ b/docs/guides/kafka/autoscaler/compute/topology.md @@ -74,7 +74,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn controller: replicas: 2 podTemplate: @@ -93,7 +93,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn 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 261a71432..81e0d1f1c 100644 --- a/docs/guides/kafka/autoscaler/storage/kafka-combined.md +++ b/docs/guides/kafka/autoscaler/storage/kafka-combined.md @@ -50,10 +50,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `Kafka` combined using a supported version by `KubeDB` operator. Then we are going to apply `KafkaAutoscaler` to set up autoscaling. @@ -86,7 +86,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn storageType: Durable deletionPolicy: WipeOut ``` @@ -220,14 +220,14 @@ Let's exec into the cluster pod and fill the cluster volume using the following $ kubectl exec -it -n demo kafka-dev-0 -- bash kafka@kafka-dev-0:~$ df -h /var/log/kafka Filesystem Size Used Avail Use% Mounted on -/dev/standard/pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 974M 168K 958M 1% /var/log/kafka +/dev/longhorn/pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 974M 168K 958M 1% /var/log/kafka kafka@kafka-dev-0:~$ dd if=/dev/zero of=/var/log/kafka/file.img bs=600M count=1 1+0 records in 1+0 records out 629145600 bytes (629 MB, 600 MiB) copied, 7.44144 s, 84.5 MB/s kafka@kafka-dev-0:~$ df -h /var/log/kafka Filesystem Size Used Avail Use% Mounted on -/dev/standard/pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 974M 601M 358M 63% /var/log/kafka +/dev/longhorn/pvc-129be4b9-f7e8-489e-8bc5-cd420e680f51 974M 601M 358M 63% /var/log/kafka ``` So, from the above output we can see that the storage usage is 83%, which exceeded the `usageThreshold` 60%. diff --git a/docs/guides/kafka/autoscaler/storage/kafka-topology.md b/docs/guides/kafka/autoscaler/storage/kafka-topology.md index adb007cec..f9d6d8c1f 100644 --- a/docs/guides/kafka/autoscaler/storage/kafka-topology.md +++ b/docs/guides/kafka/autoscaler/storage/kafka-topology.md @@ -50,10 +50,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `Kafka` topology using a supported version by `KubeDB` operator. Then we are going to apply `KafkaAutoscaler` to set up autoscaling. @@ -78,7 +78,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn controller: replicas: 2 storage: @@ -87,7 +87,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn storageType: Durable deletionPolicy: WipeOut ``` @@ -238,14 +238,14 @@ We are autoscaling volume for both broker and controller. So we need to fill up $ kubectl exec -it -n demo kafka-prod-broker-0 -- bash kafka@kafka-prod-broker-0:~$ df -h /var/log/kafka Filesystem Size Used Avail Use% Mounted on -/dev/standard/pvc-27fe9102-2e7d-41e0-b77d-729a82c64e21 974M 256K 958M 1% /var/log/kafka +/dev/longhorn/pvc-27fe9102-2e7d-41e0-b77d-729a82c64e21 974M 256K 958M 1% /var/log/kafka kafka@kafka-prod-broker-0:~$ dd if=/dev/zero of=/var/log/kafka/file.img bs=600M count=1 1+0 records in 1+0 records out 629145600 bytes (629 MB, 600 MiB) copied, 5.58851 s, 113 MB/s kafka@kafka-prod-broker-0:~$ df -h /var/log/kafka Filesystem Size Used Avail Use% Mounted on -/dev/standard/pvc-27fe9102-2e7d-41e0-b77d-729a82c64e21 974M 601M 358M 63% /var/log/kafka +/dev/longhorn/pvc-27fe9102-2e7d-41e0-b77d-729a82c64e21 974M 601M 358M 63% /var/log/kafka ``` 2. Let's exec into the controller pod and fill the cluster volume using the following commands: @@ -254,14 +254,14 @@ Filesystem Size Used Avail Use% Mo $ kubectl exec -it -n demo kafka-prod-controller-0 -- bash kafka@kafka-prod-controller-0:~$ df -h /var/log/kafka Filesystem Size Used Avail Use% Mounted on -/dev/standard/pvc-3bb98ba1-9cea-46ad-857f-fc843c265d57 974M 192K 958M 1% /var/log/kafka +/dev/longhorn/pvc-3bb98ba1-9cea-46ad-857f-fc843c265d57 974M 192K 958M 1% /var/log/kafka kafka@kafka-prod-controller-0:~$ dd if=/dev/zero of=/var/log/kafka/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 kafka@kafka-prod-controller-0:~$ df -h /var/log/kafka Filesystem Size Used Avail Use% Mounted on -/dev/standard/pvc-3bb98ba1-9cea-46ad-857f-fc843c265d57 974M 601M 358M 63% /var/log/kafka +/dev/longhorn/pvc-3bb98ba1-9cea-46ad-857f-fc843c265d57 974M 601M 358M 63% /var/log/kafka ``` So, from the above output we can see that the storage usage is 63% for both nodes, which exceeded the `usageThreshold` 60%. diff --git a/docs/guides/kafka/cli/_index.md b/docs/guides/kafka/cli/_index.md index 155f42086..e879f4f43 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 21b81a743..6cab222d4 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 81167c2af..1ef769c0d 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 7d833caaa..44991d14d 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 new file mode 100644 index 000000000..6beb0ba87 --- /dev/null +++ b/docs/guides/kafka/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: GitOps Kafka +menu: + docs_{{ .version }}: + identifier: kf-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 new file mode 100644 index 000000000..ffd2d0c3a --- /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 + 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/kafka/gitops/topology.md b/docs/guides/kafka/gitops/topology.md new file mode 100644 index 000000000..bcbd542f4 --- /dev/null +++ b/docs/guides/kafka/gitops/topology.md @@ -0,0 +1,977 @@ +--- +title: Topology GitOps +menu: + docs_{{ .version }}: + identifier: kf-gitops-topology + name: Guides + parent: kf-gitops + 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 + +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 + +Registering a Git repository in Argo CD using SSH authentication + +```bash +argocd repo add \ + --ssh-private-key-path +``` +Creating an Argo CD Application to deploy resources from the repository into a Kubernetes cluster +```bash +argocd app create \ + --repo \ + --path \ + --dest-server \ + --dest-namespace +``` + +## Create Kafka Database using GitOps + +### Create a Kafka GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-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 + 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-gitops 62m + +NAME VERSION STATUS AGE +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' +NAME AGE +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-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-auth kubernetes.io/basic-auth 2 62m + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/kafka-gitops-pods ClusterIP None 9092/TCP,9093/TCP,29092/TCP 62m + +NAME TYPE VERSION AGE +appbinding.appcatalog.appscode.com/kafka-gitops kubedb.com/kafka 3.9.0 62m +``` + +## 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-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: longhorn + 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: longhorn + storageType: Durable + deletionPolicy: WipeOut + ``` + +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 VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 64m + +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 64m + +NAME TYPE STATUS AGE +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-broker-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1540Mi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +$ kubectl get pod -n demo Kafka-gitops-controller-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "1540Mi" + }, + "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-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: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: longhorn + 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: longhorn + storageType: Durable + deletionPolicy: WipeOut +``` + +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-gitops kubedb.com/v1 3.9.0 Ready 22h + +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 22h + +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 +``` + +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-gitops' +NAME READY STATUS RESTARTS AGE +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. + +### Expand Kafka Volume + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-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: 3 + 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: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: Standard + storageType: Durable + deletionPolicy: WipeOut +``` + +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 VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 6m51s + +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 6m51s + +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-a00ef6d5-44a6-40ce-8131-680b9d24d982 2Gi RWO longhorn 7m20s +kafka-gitops-data-kafka-gitops-broker-1 Bound pvc-141798c5-9000-480f-a997-85a5743f63e2 2Gi RWO longhorn 7m4s +kafka-gitops-data-kafka-gitops-broker-2 Bound pvc-819ba56b-4fda-4361-9f3e-e18258e2de7e 2Gi RWO longhorn 6m46s +kafka-gitops-data-kafka-gitops-controller-0 Bound pvc-5a6cc06e-60ff-450a-875e-b84f75358f67 2Gi RWO longhorn 7m20s +kafka-gitops-data-kafka-gitops-controller-1 Bound pvc-7cae3a1d-0efc-48a2-8953-12f4338a9602 2Gi RWO longhorn 7m4s +kafka-gitops-data-kafka-gitops-controller-2 Bound pvc-22e0a63f-58c1-4a03-9493-e670498723db 2Gi RWO longhorn 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-topology.md) +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: kf-reconfig + 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-gitops + namespace: demo +spec: + configSecret: + name: kf-reconfig + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + 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: 3 + 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`, the reconfiguration file is created 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 VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 19m + +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 19m + +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 +``` + + + +> 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 create a secret named `kf-rotate-auth ` with the following content, + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: kf-rotate-auth + namespace: demo +type: kubernetes.io/basic-auth +stringData: + username: kafka + password: kafka-secret +``` + + +Now, we will add this file to `kubedb/kf-rotateauth.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ ├── kf-rotateauth.yaml +│ └── Kafka.yaml +1 directories, 3 files +``` + + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-gitops + namespace: demo +spec: + authSecret: + kind: Secret + name: kf-rotate-auth + configuration: + secretName: kf-reconfig + version: 3.9.0 + topology: + broker: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1536Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + 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: 3 + 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`, the authentication file is created 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 VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 17h + +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 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 +``` + + +### 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 +``` + +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` and kubedb/kf-secret.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── kf-configuration.yaml +│ ├── kf-rotateauth.yaml +│ ├── kf-secret.yaml +│ ├── kf-issuer.yaml +│ └── Kafka.yaml +1 directories, 5 files +``` + +Update the `Kafka.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: Kafka +metadata: + name: kafka-gitops + 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: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: longhorn + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: longhorn + storageType: Durable + deletionPolicy: WipeOut +``` + +Add `sslMode` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository has been successfully synchronized with ArgoCD. The `Kafka` CR has been updated, and both the `issuer` and the corresponding `secret` have been created in the 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 VERSION STATUS AGE +kafka.kubedb.com/kafka-gitops 3.9.0 Ready 67m + +NAME AGE +kafka.gitops.kubedb.com/kafka-gitops 67m + +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 +``` + + +> 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/update-version.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-gitops + 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: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: longhorn + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: longhorn + storageType: Durable + deletionPolicy: WipeOut +``` + +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,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 72m + +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 +``` + + +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-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: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 + +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-gitops + 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: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: longhorn + controller: + podTemplate: + spec: + containers: + - name: kafka + resources: + limits: + memory: 1540Mi + requests: + cpu: 500m + memory: 1536Mi + replicas: 3 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + storageClassName: longhorn + storageType: Durable + 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 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 90m + +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. + + + +## Next Steps + +- Learn Kafka Scaling + - [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). diff --git a/docs/guides/kafka/migration/_index.md b/docs/guides/kafka/migration/_index.md index 0f8b4d2e1..84e319492 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 05429b728..16cc76ef2 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 5b2552a6d..e4f77b489 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 86d8888b6..7a9181a21 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 d0d4240b4..1199fe4ae 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 b02df6b52..1e1e16820 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 840907389..ed2cf8a38 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 98b83c710..48781a47d 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 31f884753..64a121265 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 1b5fe9d94..d92320672 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 08f8af5d4..2581cfd25 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 27c8e1f8b..dddfb1563 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 diff --git a/docs/guides/kafka/volume-expansion/combined.md b/docs/guides/kafka/volume-expansion/combined.md index e580ae644..4a90e5093 100644 --- a/docs/guides/kafka/volume-expansion/combined.md +++ b/docs/guides/kafka/volume-expansion/combined.md @@ -50,10 +50,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `Kafka` combined cluster with version `3.9.0`. @@ -76,7 +76,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn storageType: Durable deletionPolicy: WipeOut ``` @@ -108,8 +108,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-23778f6015324895 1Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-1 standard 33s -pvc-30b34f642f994e13 1Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-0 standard 58s +pvc-23778f6015324895 1Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-1 longhorn 33s +pvc-30b34f642f994e13 1Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-0 longhorn 58s ``` You can see the petset has 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -286,8 +286,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-23778f6015324895 2Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-1 standard 7m2s -pvc-30b34f642f994e13 2Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-0 standard 7m9s +pvc-23778f6015324895 2Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-1 longhorn 7m2s +pvc-30b34f642f994e13 2Gi RWO Delete Bound demo/kafka-dev-data-kafka-dev-0 longhorn 7m9s ``` The above output verifies that we have successfully expanded the volume of the Kafka. diff --git a/docs/guides/kafka/volume-expansion/topology.md b/docs/guides/kafka/volume-expansion/topology.md index e953b3eff..df227a0b5 100644 --- a/docs/guides/kafka/volume-expansion/topology.md +++ b/docs/guides/kafka/volume-expansion/topology.md @@ -50,10 +50,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `Kafka` combined cluster with version `3.9.0`. @@ -78,7 +78,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn controller: replicas: 2 storage: @@ -87,7 +87,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn storageType: Durable deletionPolicy: WipeOut ``` @@ -122,10 +122,10 @@ $ kubectl get petset -n demo kafka-prod-controller -o json | jq '.spec.volumeCla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-3f177a92721440bb 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-0 standard 106s -pvc-86ff354122324b1c 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-1 standard 78s -pvc-9fa35d773aa74bd0 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-1 standard 75s -pvc-ccf50adf179e4162 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-0 standard 106s +pvc-3f177a92721440bb 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-0 longhorn 106s +pvc-86ff354122324b1c 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-1 longhorn 78s +pvc-9fa35d773aa74bd0 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-1 longhorn 75s +pvc-ccf50adf179e4162 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-0 longhorn 106s ``` You can see the petsets have 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -329,10 +329,10 @@ $ kubectl get petset -n demo kafka-prod-controller -o json | jq '.spec.volumeCla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-3f177a92721440bb 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-0 standard 5m25s -pvc-86ff354122324b1c 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-1 standard 4m51s -pvc-9fa35d773aa74bd0 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-1 standard 5m1s -pvc-ccf50adf179e4162 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-0 standard 5m30s +pvc-3f177a92721440bb 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-0 longhorn 5m25s +pvc-86ff354122324b1c 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-1 longhorn 4m51s +pvc-9fa35d773aa74bd0 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-controller-1 longhorn 5m1s +pvc-ccf50adf179e4162 1Gi RWO Delete Bound demo/kafka-prod-data-kafka-prod-broker-0 longhorn 5m30s ``` The above output verifies that we have successfully expanded the volume of the Kafka. diff --git a/docs/guides/mariadb/autoscaler/compute/cluster/examples/sample-mariadb.yaml b/docs/guides/mariadb/autoscaler/compute/cluster/examples/sample-mariadb.yaml index 7cdc99fdf..8cff8465a 100644 --- a/docs/guides/mariadb/autoscaler/compute/cluster/examples/sample-mariadb.yaml +++ b/docs/guides/mariadb/autoscaler/compute/cluster/examples/sample-mariadb.yaml @@ -8,7 +8,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mariadb/autoscaler/compute/cluster/index.md b/docs/guides/mariadb/autoscaler/compute/cluster/index.md index 7f5c9d1a6..f349054e5 100644 --- a/docs/guides/mariadb/autoscaler/compute/cluster/index.md +++ b/docs/guides/mariadb/autoscaler/compute/cluster/index.md @@ -56,7 +56,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/mariadb/concepts/mariadb-version/index.md b/docs/guides/mariadb/concepts/mariadb-version/index.md index 547a1a18e..53ac44d05 100644 --- a/docs/guides/mariadb/concepts/mariadb-version/index.md +++ b/docs/guides/mariadb/concepts/mariadb-version/index.md @@ -130,5 +130,5 @@ The default value of this field is `false`. If `spec.deprecated` is set `true`, ### spec.stash -`spec.stash` is an optional field that specifies the name of the task for stash backup and restore. Learn more about [Stash MariaDB addon](https://stash.run/docs/v2021.03.08/addons/mariadb/) +`spec.stash` is an optional field that specifies the name of the task for stash backup and restore. Learn more about [Stash MariaDB addon](https://stash.run/docs/latest/addons/mariadb/) diff --git a/docs/guides/mariadb/gitops/_index.md b/docs/guides/mariadb/gitops/_index.md new file mode 100644 index 000000000..9a0a13cfd --- /dev/null +++ b/docs/guides/mariadb/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: GitOps MariaDB +menu: + docs_{{ .version }}: + 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 new file mode 100644 index 000000000..a03a6b0ad --- /dev/null +++ b/docs/guides/mariadb/gitops/gitops.md @@ -0,0 +1,812 @@ +--- +title: MariaDB GitOps +description: MariaDB GitOps +menu: + docs_{{ .version }}: + identifier: md-gitops + name: Guide + parent: guides-mariadb-gitops + weight: 20 +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 + +Registering a Git repository in Argo CD using SSH authentication + +```bash +argocd repo add \ + --ssh-private-key-path +``` +Creating an Argo CD Application to deploy resources from the repository into a Kubernetes cluster +```bash +argocd app create \ + --repo \ + --path \ + --dest-server \ + --dest-namespace +``` + +## 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: "11.8.5" + replicas: 3 + storageType: Durable + deletionPolicy: WipeOut + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi +``` + +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 22m + +NAME VERSION STATUS AGE +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' +NAME AGE +petset.apps.k8s.appscode.com/mariadb-gitops 22m + +NAME READY STATUS RESTARTS AGE +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 22m + +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 11.8.5 22m +``` + +## Update MariaDB Database using GitOps + +### Scale MariaDB Database Resources + +Before scaling database resouces: + +```shell +$ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[0].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-gitops + namespace: demo +spec: + version: "11.8.5" + replicas: 3 + 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: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + ``` + +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. + +```bash +$ kubectl get md,mariadbopsrequest -n demo +NAME VERSION STATUS AGE +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, +```bash +$ kubectl get pod -n demo mariadb-gitops-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "600m", + "memory": "1288490188800m" + }, + "requests": { + "cpu": "600m", + "memory": "1288490188800m" + } +} +``` + +### Scale MariaDB Replicas +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: mariadb-gitops + namespace: demo +spec: + 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: + - ReadWriteOnce + resources: + requests: + storage: 1Gi +``` + +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 11.8.5 Ready 107m + +NAME TYPE STATUS AGE +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' +NAME READY STATUS RESTARTS AGE +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. + +### Expand MariaDB Volume + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: mariadb-gitops + namespace: demo +spec: + 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: + - 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. + +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 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-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-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 + +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/reconfigure/overview/index.md) +```yaml +apiVersion: v1 +stringData: + user.cnf: | + [mysqld] + max_connections = 200 + read_buffer_size = 1048576 +kind: Secret +metadata: + name: md-configuration + namespace: demo +type: Opaque +``` + +Now, we will add this file to `kubedb/md-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├── md-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-gitops + namespace: demo +spec: + 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: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: md-configuration +``` + +Commit the changes and push to your Git repository. Your repository is synced with `ArgoCD`, the reconfiguration file is created 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 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 +``` + + +### 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/md-auth.yaml` with the following content, + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mdauth + namespace: demo +type: kubernetes.io/basic-auth +stringData: + username: root + password: md-secret +``` + +Let's add that to our `kubedb/md-auth.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── md-configuration.yaml +│ ├── md-auth.yaml +│ └── MariaDB.yaml +1 directories, 3 files +``` + + + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: mariadb-gitops + namespace: demo +spec: + 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: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + configuration: + secretName: md-configuration + authSecret: + kind: Secret + name: mdauth +``` + +Change the `authSecret` field to `mdauth`. Commit the changes and push to your Git repository. Your repository has been successfully synchronized with ArgoCD. The `MariaDB` CR has been updated, and the authentication file has been created in the 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 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 +``` + + +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +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=mariadb/O=kubedb" +Generating a RSA private key +...........................................................................+++++ +........................................................................................................+++++ +writing new private key to './ca.key' +``` + +- create a secret using the certificate files we have just generated, + +```bash +$ kubectl create secret tls md-ca \ + --cert=ca.crt \ + --key=ca.key \ + -n demo +``` + +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: md-issuer + namespace: demo +spec: + ca: + secretName: md-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/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 +│ ├── md-configuration.yaml +│ ├── md-auth.yaml +│ ├── md-secret.yaml +│ ├── md-issuer.yaml +│ └── MariaDB.yaml +1 directories, 5 files +``` + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: mariadb-gitops + namespace: demo +spec: + 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: + - 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 `requireSSL` as `true` and `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository has been successfully synchronized with ArgoCD. The `MariaDB` CR has been updated, and both the `issuer` and the corresponding `secret` have been created in the 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 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 +``` + + +> 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/overview/index.md). + +Let's choose `12.1.2` in this example. + +Update the `MariaDB.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MariaDB +metadata: + name: mariadb-gitops + namespace: demo +spec: + version: "12.1.2" + 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: + - 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 +$ 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-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 +``` + + +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-gitops -o=jsonpath='{.spec.version}{"\n"}' +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 + +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-gitops + namespace: demo +spec: + version: "12.1.2" + 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: + - 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: + 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 `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 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. + + + +## Next Steps + +- Learn MariaDB Scaling + - [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/mariadb/gitops/overview.md b/docs/guides/mariadb/gitops/overview.md new file mode 100644 index 000000000..18ff94473 --- /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: md-gitops-overview + name: Overview + parent: guides-mariadb-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/mariadb/volume-expansion/maxscale.md b/docs/guides/mariadb/volume-expansion/maxscale.md index f61bb82e6..c842b0075 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. 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/mariadb/volume-expansion/volume-expansion/index.md b/docs/guides/mariadb/volume-expansion/volume-expansion/index.md index 71c4bec62..a4f57e65b 100644 --- a/docs/guides/mariadb/volume-expansion/volume-expansion/index.md +++ b/docs/guides/mariadb/volume-expansion/volume-expansion/index.md @@ -47,7 +47,7 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) rancher.io/local-path Delete WaitForFirstConsumer false 69s +longhorn (default) rancher.io/local-path Delete WaitForFirstConsumer false 69s topolvm-provisioner topolvm.cybozu.com Delete WaitForFirstConsumer true 37s ``` diff --git a/docs/guides/mongodb/autoscaler/storage/replicaset.md b/docs/guides/mongodb/autoscaler/storage/replicaset.md index 2a4907574..ba1850945 100644 --- a/docs/guides/mongodb/autoscaler/storage/replicaset.md +++ b/docs/guides/mongodb/autoscaler/storage/replicaset.md @@ -50,7 +50,7 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h +longhorn (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h topolvm-provisioner topolvm.cybozu.com Delete WaitForFirstConsumer true 9h ``` diff --git a/docs/guides/mongodb/autoscaler/storage/sharding.md b/docs/guides/mongodb/autoscaler/storage/sharding.md index 403146e3f..8e7db825c 100644 --- a/docs/guides/mongodb/autoscaler/storage/sharding.md +++ b/docs/guides/mongodb/autoscaler/storage/sharding.md @@ -50,7 +50,7 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h +longhorn (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h topolvm-provisioner topolvm.cybozu.com Delete WaitForFirstConsumer true 9h ``` diff --git a/docs/guides/mongodb/autoscaler/storage/standalone.md b/docs/guides/mongodb/autoscaler/storage/standalone.md index 493648dab..6e7edb51c 100644 --- a/docs/guides/mongodb/autoscaler/storage/standalone.md +++ b/docs/guides/mongodb/autoscaler/storage/standalone.md @@ -50,7 +50,7 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h +longhorn (default) rancher.io/local-path Delete WaitForFirstConsumer false 9h topolvm-provisioner topolvm.cybozu.com Delete WaitForFirstConsumer true 9h ``` diff --git a/docs/guides/mongodb/gitops/_index.md b/docs/guides/mongodb/gitops/_index.md new file mode 100644 index 000000000..5e7447ebc --- /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: 170 +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 000000000..634ce9881 --- /dev/null +++ b/docs/guides/mongodb/gitops/gitops.md @@ -0,0 +1,783 @@ +--- +title: MongoDB GitOps +description: MongoDB GitOps +menu: + docs_{{ .version }}: + identifier: mg-gitops + name: Guide + parent: mg-gitops-mongodb + weight: 15 +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 + +Registering a Git repository in Argo CD using SSH authentication + +```bash +argocd repo add \ + --ssh-private-key-path +``` +Creating an Argo CD Application to deploy resources from the repository into a Kubernetes cluster +```bash +argocd app create \ + --repo \ + --path \ + --dest-server \ + --dest-namespace +``` + +## 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. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mg-custom-config + namespace: demo +type: Opaque +stringData: + mongod.conf: | + net: + maxIncomingConnections: 10000 +``` + +Add this file to `Kubedb\reconfig.yaml` repository. + + +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 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 +apiVersion: v1 +kind: Secret +metadata: + name: mgauth + namespace: demo +type: kubernetes.io/basic-auth +stringData: + username: root + password: mongodb-secret +``` + +Let's add that to our `kubedb/mg-auth.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── mg-configuration.yaml +│ ├── mg-auth.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.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 has been successfully synchronized with ArgoCD. The `MongoDB` CR has been updated, and the authentication file have been created in the 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: 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 +$ 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: 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. + + + +### 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-auth.yaml +│ ├── mg-issuer.yaml +│ ├── mg-secret.yaml +│ └── mongodb.yaml +1 directories, 5 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 has been successfully synchronized with ArgoCD. The `MongoDB` CR has been updated, and both the `issuer` and the corresponding `secret` have been created in the 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 + - [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 000000000..9fd6d17e6 --- /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/mongodb/volume-expansion/replicaset.md b/docs/guides/mongodb/volume-expansion/replicaset.md index 86de61287..80e80e43b 100644 --- a/docs/guides/mongodb/volume-expansion/replicaset.md +++ b/docs/guides/mongodb/volume-expansion/replicaset.md @@ -50,10 +50,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `MongoDB` replicaSet database with version `4.4.26`. @@ -74,7 +74,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -105,9 +105,9 @@ $ kubectl get sts -n demo mg-replicaset -o json | jq '.spec.volumeClaimTemplates $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-2067c63d-f982-4b66-a008-5e9c3ff6218a 1Gi RWO Delete Bound demo/datadir-mg-replicaset-0 standard 10m -pvc-9db1aeb0-f1af-4555-93a3-0ca754327751 1Gi RWO Delete Bound demo/datadir-mg-replicaset-2 standard 9m45s -pvc-d38f42a8-50d4-4fa9-82ba-69fc7a464ff4 1Gi RWO Delete Bound demo/datadir-mg-replicaset-1 standard 10m +pvc-2067c63d-f982-4b66-a008-5e9c3ff6218a 1Gi RWO Delete Bound demo/datadir-mg-replicaset-0 longhorn 10m +pvc-9db1aeb0-f1af-4555-93a3-0ca754327751 1Gi RWO Delete Bound demo/datadir-mg-replicaset-2 longhorn 9m45s +pvc-d38f42a8-50d4-4fa9-82ba-69fc7a464ff4 1Gi RWO Delete Bound demo/datadir-mg-replicaset-1 longhorn 10m ``` You can see the petset has 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -230,9 +230,9 @@ $ kubectl get sts -n demo mg-replicaset -o json | jq '.spec.volumeClaimTemplates $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-2067c63d-f982-4b66-a008-5e9c3ff6218a 2Gi RWO Delete Bound demo/datadir-mg-replicaset-0 standard 19m -pvc-9db1aeb0-f1af-4555-93a3-0ca754327751 2Gi RWO Delete Bound demo/datadir-mg-replicaset-2 standard 18m -pvc-d38f42a8-50d4-4fa9-82ba-69fc7a464ff4 2Gi RWO Delete Bound demo/datadir-mg-replicaset-1 standard 19m +pvc-2067c63d-f982-4b66-a008-5e9c3ff6218a 2Gi RWO Delete Bound demo/datadir-mg-replicaset-0 longhorn 19m +pvc-9db1aeb0-f1af-4555-93a3-0ca754327751 2Gi RWO Delete Bound demo/datadir-mg-replicaset-2 longhorn 18m +pvc-d38f42a8-50d4-4fa9-82ba-69fc7a464ff4 2Gi RWO Delete Bound demo/datadir-mg-replicaset-1 longhorn 19m ``` The above output verifies that we have successfully expanded the volume of the MongoDB database. diff --git a/docs/guides/mongodb/volume-expansion/sharding.md b/docs/guides/mongodb/volume-expansion/sharding.md index 5e4dd05b4..0b719237e 100644 --- a/docs/guides/mongodb/volume-expansion/sharding.md +++ b/docs/guides/mongodb/volume-expansion/sharding.md @@ -50,10 +50,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `MongoDB` standalone database with version `4.4.26`. @@ -76,7 +76,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn mongos: replicas: 2 shard: @@ -86,7 +86,7 @@ spec: resources: requests: storage: 1Gi - storageClassName: standard + storageClassName: longhorn ``` Let's create the `MongoDB` CR we have shown above, @@ -115,14 +115,14 @@ $ kubectl get sts -n demo mg-sharding-shard0 -o json | jq '.spec.volumeClaimTemp $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-194f6e9c-b9a7-4d00-a125-a6c01273468c 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard0-0 standard 68s -pvc-390b6343-f97e-4761-a516-e3c9607c55d6 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard1-1 standard 2m26s -pvc-51ab98e8-d468-4a74-b176-3853dada41c2 1Gi RWO Delete Bound demo/datadir-mg-sharding-configsvr-1 standard 2m33s -pvc-5209095e-561f-4601-a0bf-0c705234da5b 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard1-0 standard 3m6s -pvc-5be2ab13-e12c-4053-8680-7c5588dff8eb 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard2-1 standard 2m32s -pvc-7e11502d-13e0-4a84-9ebe-29bc2b15f026 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard0-1 standard 44s -pvc-7e20906c-462d-47b7-b4cf-ba0ef69ba26e 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard2-0 standard 3m7s -pvc-87634059-0f95-4595-ae8a-121944961103 1Gi RWO Delete Bound demo/datadir-mg-sharding-configsvr-0 standard 3m7s +pvc-194f6e9c-b9a7-4d00-a125-a6c01273468c 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard0-0 longhorn 68s +pvc-390b6343-f97e-4761-a516-e3c9607c55d6 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard1-1 longhorn 2m26s +pvc-51ab98e8-d468-4a74-b176-3853dada41c2 1Gi RWO Delete Bound demo/datadir-mg-sharding-configsvr-1 longhorn 2m33s +pvc-5209095e-561f-4601-a0bf-0c705234da5b 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard1-0 longhorn 3m6s +pvc-5be2ab13-e12c-4053-8680-7c5588dff8eb 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard2-1 longhorn 2m32s +pvc-7e11502d-13e0-4a84-9ebe-29bc2b15f026 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard0-1 longhorn 44s +pvc-7e20906c-462d-47b7-b4cf-ba0ef69ba26e 1Gi RWO Delete Bound demo/datadir-mg-sharding-shard2-0 longhorn 3m7s +pvc-87634059-0f95-4595-ae8a-121944961103 1Gi RWO Delete Bound demo/datadir-mg-sharding-configsvr-0 longhorn 3m7s ``` You can see the petsets have 1GB storage, and the capacity of all the persistent volumes are also 1GB. @@ -258,14 +258,14 @@ $ kubectl get sts -n demo mg-sharding-shard0 -o json | jq '.spec.volumeClaimTemp $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-194f6e9c-b9a7-4d00-a125-a6c01273468c 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard0-0 standard 3m38s -pvc-390b6343-f97e-4761-a516-e3c9607c55d6 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard1-1 standard 4m56s -pvc-51ab98e8-d468-4a74-b176-3853dada41c2 2Gi RWO Delete Bound demo/datadir-mg-sharding-configsvr-1 standard 5m3s -pvc-5209095e-561f-4601-a0bf-0c705234da5b 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard1-0 standard 5m36s -pvc-5be2ab13-e12c-4053-8680-7c5588dff8eb 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard2-1 standard 5m2s -pvc-7e11502d-13e0-4a84-9ebe-29bc2b15f026 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard0-1 standard 3m14s -pvc-7e20906c-462d-47b7-b4cf-ba0ef69ba26e 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard2-0 standard 5m37s -pvc-87634059-0f95-4595-ae8a-121944961103 2Gi RWO Delete Bound demo/datadir-mg-sharding-configsvr-0 standard 5m37s +pvc-194f6e9c-b9a7-4d00-a125-a6c01273468c 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard0-0 longhorn 3m38s +pvc-390b6343-f97e-4761-a516-e3c9607c55d6 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard1-1 longhorn 4m56s +pvc-51ab98e8-d468-4a74-b176-3853dada41c2 2Gi RWO Delete Bound demo/datadir-mg-sharding-configsvr-1 longhorn 5m3s +pvc-5209095e-561f-4601-a0bf-0c705234da5b 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard1-0 longhorn 5m36s +pvc-5be2ab13-e12c-4053-8680-7c5588dff8eb 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard2-1 longhorn 5m2s +pvc-7e11502d-13e0-4a84-9ebe-29bc2b15f026 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard0-1 longhorn 3m14s +pvc-7e20906c-462d-47b7-b4cf-ba0ef69ba26e 2Gi RWO Delete Bound demo/datadir-mg-sharding-shard2-0 longhorn 5m37s +pvc-87634059-0f95-4595-ae8a-121944961103 2Gi RWO Delete Bound demo/datadir-mg-sharding-configsvr-0 longhorn 5m37s ``` The above output verifies that we have successfully expanded the volume of the shard nodes and configServer nodes of the MongoDB database. diff --git a/docs/guides/mongodb/volume-expansion/standalone.md b/docs/guides/mongodb/volume-expansion/standalone.md index 95906c5f6..91e799fa3 100644 --- a/docs/guides/mongodb/volume-expansion/standalone.md +++ b/docs/guides/mongodb/volume-expansion/standalone.md @@ -49,10 +49,10 @@ At first verify that your cluster has a storage class, that supports volume expa ```bash $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -standard (default) kubernetes.io/gce-pd Delete Immediate true 2m49s +longhorn (default) kubernetes.io/gce-pd Delete Immediate true 2m49s ``` -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. +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. Now, we are going to deploy a `MongoDB` standalone database with version `4.4.26`. @@ -70,7 +70,7 @@ spec: version: "4.4.26" storageType: Durable storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -101,7 +101,7 @@ $ kubectl get petset -n demo mg-standalone -o json | jq '.spec.volumeClaimTempla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-d0b07657-a012-4384-862a-b4e437774287 1Gi RWO Delete Bound demo/datadir-mg-standalone-0 standard 49s +pvc-d0b07657-a012-4384-862a-b4e437774287 1Gi RWO Delete Bound demo/datadir-mg-standalone-0 longhorn 49s ``` You can see the petset has 1GB storage, and the capacity of the persistent volume is also 1GB. @@ -227,7 +227,7 @@ $ kubectl get petset -n demo mg-standalone -o json | jq '.spec.volumeClaimTempla $ kubectl get pv -n demo NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-d0b07657-a012-4384-862a-b4e437774287 2Gi RWO Delete Bound demo/datadir-mg-standalone-0 standard 4m29s +pvc-d0b07657-a012-4384-862a-b4e437774287 2Gi RWO Delete Bound demo/datadir-mg-standalone-0 longhorn 4m29s ``` The above output verifies that we have successfully expanded the volume of the MongoDB standalone database. diff --git a/docs/guides/mssqlserver/backup/application-level/index.md b/docs/guides/mssqlserver/backup/application-level/index.md index b5c9c4f0b..442c8af4d 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 168f4a914..d3918aa65 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 c9e124c6a..455246e07 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/_index.md b/docs/guides/mssqlserver/gitops/_index.md new file mode 100644 index 000000000..f42bf6f40 --- /dev/null +++ b/docs/guides/mssqlserver/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: GitOps Microsoft SQL Server +menu: + docs_{{ .version }}: + identifier: mssqlserver-gitops + name: GitOps + parent: guides-mssqlserver + weight: 180 +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 000000000..f009f3077 --- /dev/null +++ b/docs/guides/mssqlserver/gitops/gitops.md @@ -0,0 +1,956 @@ +--- +title: Mssqlserver GitOps +description: Mssqlserver GitOps +menu: + docs_{{ .version }}: + identifier: mssql-gitops + name: Guide + parent: mssqlserver-gitops + weight: 15 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + + + +> New to KubeDB? Please start [here](/docs/README.md). + +# GitOps Mssqlserver using KubeDB GitOps Operator + +This guide will show you how to use `KubeDB` GitOps operator to create Mssqlserver 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/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/). + +## 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 + +Registering a Git repository in Argo CD using SSH authentication + +```bash +argocd repo add \ + --ssh-private-key-path +``` +Creating an Argo CD Application to deploy resources from the repository into a Kubernetes cluster +```bash +argocd app create \ + --repo \ + --path \ + --dest-server \ + --dest-namespace +``` + +## 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 +``` +Create a directory like below, +```bash +$ tree . +├── kubedb + └── ms-issuer.yaml +1 directories, 1 files + +Now, we are going to deploy a `MSSQLServer` availability group with version `2022-cu12`. + + +### Create a Mssqlserver GitOps CR +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MSSQLServer +metadata: + name: mssql-gitops + namespace: demo +spec: + version: "2022-cu12" + replicas: 4 + 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 + storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi + deletionPolicy: WipeOut +``` + +Create a directory like below, + +```bash +$ tree . +├── kubedb +│ ├──ms-issuer.yaml +│ ├──mssql.yaml +1 directories, 2 files +``` +``` + +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 `Mssqlserver` database CR in the cluster. List the resources created by `gitops` operator in the `demo` namespace. + + +```bash +$ kubectl get mssqlserver.gitops.kubedb.com,mssqlserver.kubedb.com -n demo +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 19h + +NAME VERSION STATUS AGE +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 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-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-cu19 19h +``` + +## Update Mssqlserver Database using GitOps + +### Scale Mssqlserver Replicas +Update the `mssqlserver.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +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 + storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +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 +$ 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 19h + +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-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 + +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' +{ + "limits": { + "memory": "4Gi" + }, + "requests": { + "cpu": "1500m", + "memory": "2Gi" + } +} +``` +Update the `mssqlserver.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +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 + 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 `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. + +```bash +$ 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 19h + +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-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "2", + "memory": "2Gi" + }, + "requests": { + "cpu": "700m", + "memory": "2Gi" + } +} + +``` + + +### Expand Mssqlserver Volume + +Update the `mssqlserver.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +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 + resources: + requests: + memory: "2Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "2Gi" + 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 `Mssqlserver` CR is updated in your cluster. + +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 +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 20h + +NAME AGE +mssqlserver.gitops.kubedb.com/mssql-gitops 20h + +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 +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 + +At first, we create a configuration file +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: ms-custom-config + namespace: demo +type: Opaque +stringData: + mssql.conf: | + [memory] + memorylimitmb = 2048 +``` + + +Now, we will add this file to `kubedb/ms-configuration.yaml`. + +```bash +$ tree . +├── kubedb +│ ├──ms-issuer.yaml +│ ├──ms-configuration.yaml +│ └──mssql.yaml +1 directories, 3 files +``` + +Update the `mssqlserver.yaml` with `spec.configuration.secretName` as the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +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 + 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 +``` + +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` 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 +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 20h + +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 +``` + + + +> 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 + +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 +We will do that using gitops, create the file `kubedb/ms-auth.yaml` with the following content, + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mssqlserver-quickstart-auth-user + namespace: demo +type: kubernetes.io/basic-auth +stringData: + username: sa + password: Mssqlserver2 +``` +Let's add that to our `kubedb/md-auth.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├──ms-issuer.yaml +│ ├── ms-configuration.yaml +│ ├── ms-auth.yaml +│ └── mssql.yaml +1 directories, 4 files +``` + +Update the `mssql.yaml` ading `authsecret` as the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +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 + 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 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 and the authentication file is created in you 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. + +```bash +$ kubectl get ms,mssqlserver,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu19 Ready 21h + +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 +``` + + +### Update Version + +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. + +Update the `mssqlserver.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MSSQLServer +metadata: + name: mssql-gitops + namespace: demo +spec: + version: "2022-cu22" + 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 + 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 +``` + +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 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 +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 22h + +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 +``` + + +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 + +$ 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 +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MSSQLServer +metadata: + name: mssql-gitops + namespace: demo +spec: + version: "2022-cu22" + 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 + 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 + 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 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. + + +### TLS configuration + +First 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) +Update the `mssqlserver.yaml` with the following, +```yaml +apiVersion: gitops.kubedb.com/v1alpha1 +kind: MSSQLServer +metadata: + name: mssql-gitops + namespace: demo +spec: + version: "2022-cu22" + replicas: 3 + topology: + 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 + resources: + requests: + memory: "2Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "2Gi" + storageType: Durable + 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 +``` + +Convert `spec.tls.clientTLS` to `true`. Commit the changes and push to your Git repository. Your repository has been successfully synchronized with ArgoCD. The `MSSQLserver` CR has been updated in the 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. + +```bash +$ kubectl get ms,msops -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-gitops 2022-cu22 Ready 20m + +NAME TYPE STATUS AGE +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 +``` + + +> 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 + +- Learn Mssqlserver Scaling + - [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 new file mode 100644 index 000000000..8e537b114 --- /dev/null +++ b/docs/guides/mssqlserver/gitops/overview.md @@ -0,0 +1,50 @@ +--- +title: GitOps overview Microsoft SQL Server +menu: + docs_{{ .version }}: + identifier: ms-overview + name: Overview + 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 MSSQLServer + +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: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + + + +## 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. + + +
+ + GitOps Flow + +
Fig: GitOps process of MSSQLServer
+ +
+ +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 MSSQLServer CR in the Kubernetes cluster to deploy the database. +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. + +In the next doc, we are going to show a step by step guide on running MSSQLServer using GitOps. diff --git a/docs/guides/mssqlserver/reconfigure-tls/ag_cluster.md b/docs/guides/mssqlserver/reconfigure-tls/ag_cluster.md index 7a17b63d4..c5cf3af71 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 19f46f300..04903508c 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 diff --git a/docs/guides/mssqlserver/volume-expansion/ag_cluster.md b/docs/guides/mssqlserver/volume-expansion/ag_cluster.md index fc8ba8a0f..c74f72b43 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 8cc2596a8..fefd1dee4 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/gitops/_index.md b/docs/guides/mysql/gitops/_index.md new file mode 100755 index 000000000..d1bf1a8d9 --- /dev/null +++ b/docs/guides/mysql/gitops/_index.md @@ -0,0 +1,10 @@ +--- +title: MySQL GitOps +menu: + docs_{{ .version }}: + identifier: guides-mysql-gitops + name: GitOps + parent: guides-mysql + weight: 180 +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 000000000..94976a1ff --- /dev/null +++ b/docs/guides/mysql/gitops/gitops.md @@ -0,0 +1,992 @@ +--- +title: GitOps MySQL +menu: + docs_{{ .version }}: + identifier: mysql-gitops + name: Guide + parent: guides-mysql-gitops + 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 + +Registering a Git repository in Argo CD using SSH authentication + +```bash +argocd repo add \ + --ssh-private-key-path +``` +Creating an Argo CD Application to deploy resources from the repository into a Kubernetes cluster +```bash +argocd app create \ + --repo \ + --path \ + --dest-server \ + --dest-namespace +``` + + +## 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: + version: "9.4.0" + replicas: 3 + topology: + mode: GroupReplication + group: + mode: Single-Primary + storageType: Durable + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + 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 76m + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.4.0 Ready 76m +``` + +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 78m + +NAME READY STATUS RESTARTS AGE +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 78m + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +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.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 +kind: MySQL +metadata: + name: my-gitops + namespace: demo +spec: + version: "9.4.0" + replicas: 3 + 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: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +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. + +```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.4.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": { + "memory": "1536Mi" + }, + "requests": { + "cpu": "700m", + "memory": "1536Mi" + } +} +``` + +### 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: + version: "9.4.0" + replicas: 4 + 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: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +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 +NAME AGE +mysql.gitops.kubedb.com/my-gitops 101m + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.4.0 Ready 101m + +NAME TYPE STATUS AGE +mysqlopsrequest.ops.kubedb.com/my-gitops-horizontalscaling-h542j4 HorizontalScaling Successful 5m1s +mysqlopsrequest.ops.kubedb.com/my-gitops-verticalscaling-zbtqnv VerticalScaling Successful 19m + +``` + +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 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. + +### 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: + version: "9.4.0" + replicas: 4 + 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: 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 `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 104m + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.4.0 Ready 104m + +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 + +``` + +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-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 + +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.4.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.cnf: | + [mysqld] + max_connections = 200 + read_buffer_size = 1048575 +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: + version: "9.4.0" + replicas: 4 + configSecret: + name: my-configuration + 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: 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 `MySQL` CR is updated in your cluster and the configuration file is created 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 126m + +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-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 +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.4.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 | 1044480 | ++------------------+---------+ + +``` +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 `configuration.secretName` field. Also you can remove the `configuration` 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: bXlwYXNzd29yZA== + username: cm9vdA== +kind: Secret +metadata: + name: myauth + 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.4.0" + replicas: 4 + configSecret: + name: my-config + authSecret: + kind: Secret + name: myauth + 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: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut +``` + +Change the `authSecret.name` field to `myauth`. Commit the changes and push to your Git repository. Your repository has been successfully synchronized with ArgoCD. The `MySQL` CR has been updated, and the authentication file has been created in the 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 19h + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.4.0 Ready 19h + +NAME TYPE STATUS AGE +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"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 808 +Server version: 9.4.0 MySQL Community Server - GPL + +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 +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.001 sec) +``` + +### TLS configuration + +We can add, rotate or remove TLS configuration using `gitops`. + +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 our ca-certificates using openssl, + +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=mysql/O=kubedb" +``` + +- create a secret using the certificate files we have just generated, + +```bash +$ kubectl create secret generic my-ca \ + --from-file=ca.crt=ca.crt \ + -n demo +``` + +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: mysql-issuer + namespace: demo +spec: + 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, +```bash +$ tree . +├── kubedb +│ ├── my-auth.yaml +│ ├── my-configuration.yaml +│ ├── my-secret.yaml +│ ├── my-issuer.yaml +│ └── MySQL.yaml +1 directories, 5 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.4.0" + replicas: 4 + configSecret: + name: my-config + authSecret: + kind: Secret + name: myauth + tls: + issuerRef: + apiGroup: cert-manager.io + kind: Issuer + name: mysql-issuer + 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: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut +``` + +Add `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository has been successfully synchronized with ArgoCD. The `MySQL` CR has been updated, and both the `issuer` and the corresponding `secret` have been created in the 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 20h + +NAME VERSION STATUS AGE +mysql.kubedb.com/my-gitops 9.4.0 Ready 20h + +NAME TYPE STATUS AGE +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$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 505 +Server version: 9.4.0 MySQL Community Server - GPL + +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 +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.016 sec) + +mysql> SHOW VARIABLES LIKE '%require_secure_transport%'; ++--------------------------+-------+ +| Variable_name | Value | ++--------------------------+-------+ +| require_secure_transport | OFF | ++--------------------------+-------+ +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. + +### 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 `9.6.0` 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: + version: "9.6.0" + replicas: 4 + configSecret: + name: my-config + authSecret: + kind: Secret + name: myauth + tls: + issuerRef: + apiGroup: cert-manager.io + kind: Issuer + 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 + resources: + limits: + memory: 1.5Gi + requests: + cpu: 700m + memory: 1.5Gi + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + deletionPolicy: WipeOut +``` + +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 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 +``` + + +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"}' +9.6.0 +$ kubectl get petset -n demo my-gitops -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +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:9.6.0-oracle@sha256:16e6b7b93df8aa255d3886ff33c2d78093d1cd2346522d14bf1b9cc0ad03a460 +``` + +### 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: + version: "9.6.0" + replicas: 4 + configSecret: + name: my-config + authSecret: + kind: Secret + name: myauth + tls: + issuerRef: + apiGroup: cert-manager.io + kind: Issuer + 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 + resources: + limits: + memory: 1.5Gi + requests: + cpu: 700m + memory: 1.5Gi + storage: + storageClassName: longhorn + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi + 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 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. + + +## 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 000000000..fbfc01784 --- /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: guides-mysql-gitops + 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/mysql/migration/storageMigration.md b/docs/guides/mysql/migration/storageMigration.md index 05cca4d88..0d8877cfa 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/yamls/mysql-restore.yaml b/docs/guides/mysql/pitr/volumesnapshot/yamls/mysql-restore.yaml index fce370397..41676f29a 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 06fe8780e..0ef5fdc1d 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 e12cd519b..3a264518a 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 1a6790661..af4aa5c34 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/mysql/rotate-auth/overview.md b/docs/guides/mysql/rotate-auth/overview.md index 51fd22409..37e6392a9 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 diff --git a/docs/guides/percona-xtradb/concepts/perconaxtradb-version/index.md b/docs/guides/percona-xtradb/concepts/perconaxtradb-version/index.md index 32d955e53..16160dc1e 100644 --- a/docs/guides/percona-xtradb/concepts/perconaxtradb-version/index.md +++ b/docs/guides/percona-xtradb/concepts/perconaxtradb-version/index.md @@ -102,5 +102,5 @@ The default value of this field is `false`. If `spec.deprecated` is set `true`, ### spec.stash -`spec.stash` is an optional field that specifies the name of the task for stash backup and restore. Learn more about [Stash PerconaXtraDB addon](https://stash.run/docs/v2022.12.11/addons/percona-xtradb/) +`spec.stash` is an optional field that specifies the name of the task for stash backup and restore. Learn more about [Stash PerconaXtraDB addon](https://stash.run/docs/latest/addons/percona-xtradb/) 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 000000000..0f1d95a8e --- /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 +``` diff --git a/docs/guides/postgres/autoscaler/compute/cluster.md b/docs/guides/postgres/autoscaler/compute/cluster.md index 8cd786b40..8b227c9a2 100644 --- a/docs/guides/postgres/autoscaler/compute/cluster.md +++ b/docs/guides/postgres/autoscaler/compute/cluster.md @@ -55,7 +55,7 @@ spec: replicas: 3 storageType: Durable storage: - storageClassName: "standard" + storageClassName: "longhorn" 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 e1a85772c..f3b305925 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 f7c4edde7..1fece3873 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 731a012df..01c453a98 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/postgres/gitops/gitops.md b/docs/guides/postgres/gitops/gitops.md index 532554eb7..b2f254d01 100644 --- a/docs/guides/postgres/gitops/gitops.md +++ b/docs/guides/postgres/gitops/gitops.md @@ -49,8 +49,20 @@ argocd app create kubedb --repo --path kubedb --dest-server https://k ``` #### Using SSH + +Registering a Git repository in Argo CD using SSH authentication + ```bash -argocd app create kubedb --repo --path kubedb --dest-server https://kubernetes.default.svc --dest-namespace --ssh-private-key-path ~/.ssh/id_rsa +argocd repo add \ + --ssh-private-key-path +``` +Creating an Argo CD Application to deploy resources from the repository into a Kubernetes cluster +```bash +argocd app create \ + --repo \ + --path \ + --dest-server \ + --dest-namespace ``` ## Create Postgres Database using GitOps @@ -77,7 +89,7 @@ spec: cpu: 500m memory: 1Gi storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -158,7 +170,7 @@ spec: cpu: 700m memory: 2Gi storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -220,7 +232,7 @@ spec: cpu: 700m memory: 2Gi storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -282,7 +294,7 @@ spec: cpu: 700m memory: 2Gi storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -313,11 +325,11 @@ After Ops Request becomes `Successful`, We can validate the changes by checking ```bash $ kubectl get pvc -n demo -l 'app.kubernetes.io/instance=ha-postgres' NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -data-ha-postgres-0 Bound pvc-061f3622-234f-4f91-b4d1-b81aa8739503 10Gi RWO standard 30m -data-ha-postgres-1 Bound pvc-045fc563-fb4e-416c-a9c2-b20c96532978 10Gi RWO standard 30m -data-ha-postgres-2 Bound pvc-a0f1d8fd-a677-4407-80b1-104b9f7b4cd1 10Gi RWO standard 30m -data-ha-postgres-3 Bound pvc-060b6fab-0c2d-4935-b31b-2866be68dd6f 10Gi RWO standard 8m58s -data-ha-postgres-4 Bound pvc-8149b579-a40f-4cd8-ac37-6a2401fd7807 10Gi RWO standard 8m23s +data-ha-postgres-0 Bound pvc-061f3622-234f-4f91-b4d1-b81aa8739503 10Gi RWO longhorn 30m +data-ha-postgres-1 Bound pvc-045fc563-fb4e-416c-a9c2-b20c96532978 10Gi RWO longhorn 30m +data-ha-postgres-2 Bound pvc-a0f1d8fd-a677-4407-80b1-104b9f7b4cd1 10Gi RWO longhorn 30m +data-ha-postgres-3 Bound pvc-060b6fab-0c2d-4935-b31b-2866be68dd6f 10Gi RWO longhorn 8m58s +data-ha-postgres-4 Bound pvc-8149b579-a40f-4cd8-ac37-6a2401fd7807 10Gi RWO longhorn 8m23s ``` ## Reconfigure Postgres @@ -371,7 +383,7 @@ spec: cpu: 700m memory: 2Gi storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -479,7 +491,7 @@ spec: cpu: 700m memory: 2Gi storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -516,7 +528,6 @@ Password: psql (16.6) Type "help" for help. -postgres=# ``` ### TLS configuration @@ -612,7 +623,7 @@ spec: cpu: 700m memory: 2Gi storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -649,8 +660,6 @@ ha-postgres-0:/$ psql -h ha-postgres.demo.svc -U postgres -d "sslmode=verify-ful psql (13.13) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off) Type "help" for help. - -postgres=# ``` > We can also rotate the certificates updating `.spec.tls.certificates` field. Also you can remove the `.spec.tls` field to remove tls for postgres. @@ -703,7 +712,7 @@ spec: cpu: 700m memory: 2Gi storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -800,7 +809,7 @@ spec: release: prometheus interval: 10s storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/postgres/gitops/overview.md b/docs/guides/postgres/gitops/overview.md index 54f485c9f..33f53afb3 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/postgres/migration/storageMigration.md b/docs/guides/postgres/migration/storageMigration.md index e3fc49481..c42c80ee6 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/yamls/postgresarchiver.yaml b/docs/guides/postgres/pitr/yamls/postgresarchiver.yaml index 119df3106..7b97edc85 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 1a6790661..af4aa5c34 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/proxysql/clustering/proxysql-cluster/index.md b/docs/guides/proxysql/clustering/proxysql-cluster/index.md index 0cd85bb50..4c6828e37 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 b4fdb88fc..516b603fa 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 15c0cdd0b..240ab737d 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 1853c6cf8..aa08c8e06 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 6dee94376..9374e6749 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/redis/gitops/_index.md b/docs/guides/redis/gitops/_index.md new file mode 100644 index 000000000..8f0bca324 --- /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 000000000..e1f0b52bd --- /dev/null +++ b/docs/guides/redis/gitops/gitops.md @@ -0,0 +1,790 @@ +--- +title: Redis GitOps Guides +menu: + docs_{{ .version }}: + identifier: rd-gitops-guides + name: Guide + 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 + +Registering a Git repository in Argo CD using SSH authentication + +```bash +argocd repo add \ + --ssh-private-key-path +``` +Creating an Argo CD Application to deploy resources from the repository into a Kubernetes cluster +```bash +argocd app create \ + --repo \ + --path \ + --dest-server \ + --dest-namespace +``` + +## 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 + + +### 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-issuer.yaml +│ ├── rd-secret.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: "longhorn" + accessModes: + - ReadWriteOnce + deletionPolicy: WipeOut +``` + +Add `tls` fields in the spec. Commit the changes and push to your Git repository. Your repository has been successfully synchronized with ArgoCD. The `Redis` CR has been updated, and both the `issuer` and the corresponding `secret` have been created in the 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,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 Redis. + + +### 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 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' +{ + "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/cluster.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 a secret with this configuration file. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: ms-custom-config + namespace: demo +type: Opaque +stringData: + mssql.conf: | + [memory] + memorylimitmb = 2048 +``` + +Let's add that to `kubedb/rd_conf.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── rd-config.yaml +│ ├── rd-issuer.yaml +│ ├── rd-secret.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: 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`. The reconfiguration file is created 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 do that using gitops, create the file `kubedb/rd-auth.yaml` with the following content, + +```bash +apiVersion: v1 +kind: Secret +metadata: + name: rd-rotate-auth + namespace: demo +type: kubernetes.io/basic-auth +stringData: + username: redis + password: redis-secret +``` + +Let's add that to our `kubedb/rdauth.yaml` file. File structure will look like this, +```bash +$ tree . +├── kubedb +│ ├── rd-auth.yaml +│ ├── rd-config.yaml +│ ├── rd-issuer.yaml +│ ├── rd-secret.yaml +│ └── redis.yaml +1 directories, 5 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 + 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 + 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. + + + +## 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 000000000..ab46d7e56 --- /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. diff --git a/docs/guides/singlestore/autoscaler/compute/cluster.md b/docs/guides/singlestore/autoscaler/compute/cluster.md index e253a2b53..079819d3a 100644 --- a/docs/guides/singlestore/autoscaler/compute/cluster.md +++ b/docs/guides/singlestore/autoscaler/compute/cluster.md @@ -79,7 +79,7 @@ spec: memory: "2Gi" cpu: "0.7" storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: @@ -99,7 +99,7 @@ spec: memory: "2Gi" cpu: "0.7" storage: - storageClassName: "standard" + storageClassName: "longhorn" accessModes: - ReadWriteOnce resources: diff --git a/docs/guides/singlestore/concepts/appbinding.md b/docs/guides/singlestore/concepts/appbinding.md index 6324b158c..43e8b4aea 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/singlestore/configuration/config-file/index.md.bak b/docs/guides/singlestore/configuration/config-file/index.md.bak new file mode 100644 index 000000000..5199faa00 --- /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). diff --git a/docs/guides/singlestore/configuration/podtemplating/index.md b/docs/guides/singlestore/configuration/podtemplating/index.md index 0660ce756..730581231 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 b474eed2b..ad84e6dbc 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 c4d5ee82e..b4411992f 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 965fdf1e9..a21a605a2 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 0320f1b4a..732fec102 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 2febd32fb..e792768a0 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 fcd9a408c..dea9ec381 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 9d1928e1f..173956db1 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 a33711943..0f50e8e5c 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 9d1928e1f..173956db1 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 7fa321a46..5ac9babe9 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 572336c17..d3261193f 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 e95a73484..571d3aaaa 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 cf84dd430..538af96b9 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 6d83c031b..0bbd96036 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/storage/combined.md b/docs/guides/solr/autoscaler/storage/combined.md index f2e3b979e..5cfcc8596 100644 --- a/docs/guides/solr/autoscaler/storage/combined.md +++ b/docs/guides/solr/autoscaler/storage/combined.md @@ -53,8 +53,7 @@ longhorn (default) driver.longhorn.io Delete Immediate longhorn-static driver.longhorn.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 `longhorn` 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/guides/solr/configuration/config-file.md b/docs/guides/solr/configuration/config-file.md index e8a9bd1aa..eacfc70a4 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 78610d283..c77e036f4 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 cfd1785c7..d53cb2f1d 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 16942a11e..0d8373b68 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/backup/kubestash/auto-backup/index.md b/docs/guides/zookeeper/backup/kubestash/auto-backup/index.md index a21b7deb6..747edc1e5 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 02be21a26..d53e2af5d 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 diff --git a/docs/guides/zookeeper/monitoring/using-prometheus-operator.md b/docs/guides/zookeeper/monitoring/using-prometheus-operator.md index 4943bea81..2fce40817 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 ae2bba9d6..216532676 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. diff --git a/docs/images/gitops/gitops.jpg b/docs/images/gitops/gitops.jpg new file mode 100644 index 000000000..f51eb4456 Binary files /dev/null and b/docs/images/gitops/gitops.jpg differ diff --git a/docs/images/gitops/gitops.png b/docs/images/gitops/gitops.png deleted file mode 100644 index 5b89b72a2..000000000 Binary files a/docs/images/gitops/gitops.png and /dev/null differ diff --git a/docs/setup/upgrade/index.md b/docs/setup/upgrade/index.md index 5d58251b4..100465bf7 100644 --- a/docs/setup/upgrade/index.md +++ b/docs/setup/upgrade/index.md @@ -61,7 +61,7 @@ helm upgrade -i kubedb oci://ghcr.io/appscode-charts/kubedb \ #### 3. Install/Upgrade Stash Operator -Now, upgrade Stash if had previously installed Stash following the instructions [here](https://stash.run/docs/v2021.06.23/setup/upgrade/). If you had not installed Stash before, please install Stash following the instructions [here](https://stash.run/docs/v2021.06.23/setup/). +Now, upgrade Stash if had previously installed Stash following the instructions [here](https://stash.run/docs/latest/setup/upgrade/). If you had not installed Stash before, please install Stash following the instructions [here](https://stash.run/docs/latest/setup/). ## Upgrading KubeDB from `v2021.01.26`(`v0.16.x`) and older to `{{< param "info.version" >}}`