diff --git a/config.dev.yaml b/config.dev.yaml index 4b8e815f50..7e29483f56 100644 --- a/config.dev.yaml +++ b/config.dev.yaml @@ -24,7 +24,7 @@ params: domain_pharmer: https://pharmer-v1-hugo.web.app domain_stash: https://stashed-v1-hugo.web.app domain_voyagermesh: https://voyagermesh-v1-hugo.web.app - search_api_key: ee310e417cda9ef6db0e642af12875611bd6e7ad69fb08c80dbd8cef72d68ba4 + search_api_key: 8fd610038d901dd16a111e6f1568343bb969b084a1952dafdcb1545fd8c35e96 learn_url: https://appscode.com/learn docs_url: https://appscode.com/docs blog_url: https://appscode.com/blog diff --git a/config.yaml b/config.yaml index f6160d31e9..ce490bdb90 100644 --- a/config.yaml +++ b/config.yaml @@ -26,7 +26,7 @@ params: domain_pharmer: https://pharmer.dev domain_stash: https://stash.run domain_voyagermesh: https://voyagermesh.com - search_api_key: ee310e417cda9ef6db0e642af12875611bd6e7ad69fb08c80dbd8cef72d68ba4 + search_api_key: 8fd610038d901dd16a111e6f1568343bb969b084a1952dafdcb1545fd8c35e96 learn_url: https://appscode.com/learn docs_url: https://appscode.com/docs blog_url: https://appscode.com/blog diff --git a/content/docs/v2025.2.19/README.md b/content/docs/v2025.2.19/README.md index cf3844e1b5..ee566920eb 100644 --- a/content/docs/v2025.2.19/README.md +++ b/content/docs/v2025.2.19/README.md @@ -36,6 +36,6 @@ From here you can learn all about KubeDB's architecture and how to deploy and us - [Guides](/docs/v2025.2.19/guides/). Guides to show you how to perform tasks with KubeDB. -- [Reference](/docs/v2025.2.19/reference/). Detailed exhaustive lists of command-line options, configuration options, API definitions, and procedures. +- Detailed exhaustive lists of command-line options, configuration options, API definitions, and procedures. Specially, [CLI](/docs/v2025.2.19/reference/cli/), [operator](/docs/v2025.2.19/reference/operator/) & [webhook-server](/docs/v2025.2.19/reference/webhook-server/). We're always looking for help improving our documentation, so please don't hesitate to [file an issue](https://github.com/kubedb/project/issues/new) if you see some problem. Or better yet, submit your own [contributions](/docs/v2025.2.19/CONTRIBUTING) to help make our docs better. diff --git a/content/docs/v2025.2.19/guides/mariadb/scaling/vertical-scaling/cluster/index.md b/content/docs/v2025.2.19/guides/mariadb/scaling/vertical-scaling/cluster/index.md index 989bb06843..49a664e59e 100644 --- a/content/docs/v2025.2.19/guides/mariadb/scaling/vertical-scaling/cluster/index.md +++ b/content/docs/v2025.2.19/guides/mariadb/scaling/vertical-scaling/cluster/index.md @@ -110,7 +110,7 @@ $ kubectl get pod -n demo sample-mariadb-0 -o json | jq '.spec.containers[].reso } ``` -You can see the Pod has the default resources which is assigned by Kubedb operator. +You can see the Pod has the default resources which is assigned by KubeDB operator. We are now ready to apply the `MariaDBOpsRequest` CR to update the resources of this database. diff --git a/content/docs/v2025.2.19/guides/mongodb/concepts/mongodb.md b/content/docs/v2025.2.19/guides/mongodb/concepts/mongodb.md index b01670f9d6..eae5c5d3a5 100644 --- a/content/docs/v2025.2.19/guides/mongodb/concepts/mongodb.md +++ b/content/docs/v2025.2.19/guides/mongodb/concepts/mongodb.md @@ -535,7 +535,7 @@ The `spec.podTemplate.spec.containers[].name` field used to specify the name of Note that, KubeDB does not allow `MONGO_INITDB_ROOT_USERNAME` and `MONGO_INITDB_ROOT_PASSWORD` environment variables to set in `spec.podTemplate.spec.env`. If you want to use custom superuser and password, please use `spec.authSecret` instead described earlier. -If you try to set `MONGO_INITDB_ROOT_USERNAME` or `MONGO_INITDB_ROOT_PASSWORD` environment variable in MongoDB crd, Kubedb operator will reject the request with following error, +If you try to set `MONGO_INITDB_ROOT_USERNAME` or `MONGO_INITDB_ROOT_PASSWORD` environment variable in MongoDB crd, KubeDB operator will reject the request with following error, ```ini Error from server (Forbidden): error when creating "./mongodb.yaml": admission webhook "mongodb.validators.kubedb.com" denied the request: environment variable MONGO_INITDB_ROOT_USERNAME is forbidden to use in MongoDB spec diff --git a/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/replicaset.md b/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/replicaset.md index a5d69b8a4c..b6d2668225 100644 --- a/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/replicaset.md +++ b/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/replicaset.md @@ -112,7 +112,7 @@ $ kubectl get pod -n demo mg-replicaset-0 -o json | jq '.spec.containers[].resou } ``` -You can see the Pod has the default resources which is assigned by Kubedb operator. +You can see the Pod has the default resources which is assigned by KubeDB operator. We are now ready to apply the `MongoDBOpsRequest` CR to update the resources of this database. diff --git a/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/sharding.md b/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/sharding.md index e50d7067d5..02373e7808 100644 --- a/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/sharding.md +++ b/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/sharding.md @@ -143,7 +143,7 @@ $ kubectl get pod -n demo mg-sharding-shard0-0 -o json | jq '.spec.containers[]. } ``` -You can see all the Pod of mongos, configserver and shard has default resources which is assigned by Kubedb operator. +You can see all the Pod of mongos, configserver and shard has default resources which is assigned by KubeDB operator. We are now ready to apply the `MongoDBOpsRequest` CR to update the resources of mongos, configserver and shard nodes of this database. diff --git a/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/standalone.md b/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/standalone.md index d8d7a35ffd..ff4df6dcb6 100644 --- a/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/standalone.md +++ b/content/docs/v2025.2.19/guides/mongodb/scaling/vertical-scaling/standalone.md @@ -108,7 +108,7 @@ $ kubectl get pod -n demo mg-standalone-0 -o json | jq '.spec.containers[].resou } ``` -You can see the Pod has default resources which is assigned by the Kubedb operator. +You can see the Pod has default resources which is assigned by the KubeDB operator. We are now ready to apply the `MongoDBOpsRequest` CR to update the resources of this database. diff --git a/content/docs/v2025.2.19/guides/mssqlserver/clustering/arbiter.md b/content/docs/v2025.2.19/guides/mssqlserver/clustering/arbiter.md new file mode 100644 index 0000000000..b56780c2ee --- /dev/null +++ b/content/docs/v2025.2.19/guides/mssqlserver/clustering/arbiter.md @@ -0,0 +1,336 @@ +--- +title: Arbiter Node for MS SQL Server Cluster with Even Nodes +menu: + docs_v2025.2.19: + identifier: arbiter-guides + name: Arbiter Node for AG Cluster + parent: ms-arbiter + weight: 15 +menu_name: docs_v2025.2.19 +section_menu_id: guides +info: + autoscaler: v0.37.0 + cli: v0.52.0 + dashboard: v0.28.0 + installer: v2025.2.19 + ops-manager: v0.39.0 + provisioner: v0.52.0 + schema-manager: v0.28.0 + ui-server: v0.28.0 + version: v2025.2.19 + webhook-server: v0.28.0 +--- + +> New to KubeDB? Please start [here](/docs/v2025.2.19/README). + +# Arbiter Node Support for Microsoft SQL Server Cluster with Even Nodes + +## Arbiter Node Concepts +We use [Raft Consensus Algorithm](https://raft.github.io/) to determine the primary of SQL Server Availability Group cluster. Raft relies on a quorum-based voting system, which ideally requires an odd number of nodes to avoid split votes. However, many users prefer a two-replica setup for cost efficiency, a primary for write/read operations and a secondary for read queries. + +To resolve the potential split vote issue in a two-node deployment, we introduce an extra node known as an `Arbiter`. This lightweight node participates solely in leader election (voting) and does not store any database data. + +### Key Points: +**Voting-Only Role:** The Arbiter participates solely in the leader election process. It casts a vote to help achieve quorum but does not store or process any database data. +**Lightweight & Cost-Effective:** The Arbiter is deployed in its own PetSet with a dedicated PVC using minimal storage (default 2GB). This allows you to run a two-node cluster (one primary and one secondary) without extra expense. +**Automatic Inclusion:** When you deploy a SQL Server Availability Group cluster with an even number of replicas (e.g., two), KubeDB automatically adds the Arbiter node. This extra vote ensures that a clear primary is elected. + +**Implementation:** Along with each `mssql` container, we run a separate sidecar container named `mssql-coordinator` which determines the leader of the cluster both on bootstrap and in fail over scenarios. + +> Note: The arbiter node doesn't store any data related to sqlserver database. However, it needs a bare minimum of 1Gi~2Gi Storage for storing WAL and Snapshots that are generated by RAFT. But the generation of WAL are not very frequent. So storage space of 2Gi is more than enough for most of the clusters. + + +  +  + +Here we will show how to use KubeDB to provision a SQL Server even-sized Availability Group Cluster with Arbiter Node. +### Setup + +- 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/v2025.2.19/setup/README). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- 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/). + + +To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + + + +## Deploy Microsoft SQL Server Availability Group Cluster with even nodes. + +First, an issuer needs to be created, even if TLS is not enabled for SQL Server. The issuer will be used to configure the TLS-enabled Wal-G proxy server, which is required for the SQL Server backup and restore operations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/ag-cluster/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + + +Now, Let's apply the following YAML for a Two-Node Cluster (with Arbiter): + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: ms-even-cluster + namespace: demo +spec: + version: "2022-cu16" + replicas: 2 + 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: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +After applying the YAML: +- Two Replica Pods (e.g., ms-even-cluster-0 and ms-even-cluster-1) are created as the primary and secondary SQL Server nodes. +- A separate PetSet with the name `{{ dbName }}-arbiter` is automatically created for the arbiter (e.g., ms-even-cluster-arbiter). Which will eventually create a pod having name `{{ dbName }}-arbiter-0`. The arbiter pod runs a single container that participates only in leader election. + +You might see the resources are created like this: +```bash +kubectl get ms,petset,pods,secrets,issuer,pvc -n demo + +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/ms-even-cluster 2022-cu16 Ready 33m + +NAME AGE +petset.apps.k8s.appscode.com/ms-even-cluster 30m +petset.apps.k8s.appscode.com/ms-even-cluster-arbiter 29m + +NAME READY STATUS RESTARTS AGE +pod/ms-even-cluster-0 2/2 Running 0 30m +pod/ms-even-cluster-1 2/2 Running 0 30m +pod/ms-even-cluster-arbiter-0 1/1 Running 0 29m + +NAME TYPE DATA AGE +secret/ms-even-cluster-auth kubernetes.io/basic-auth 2 33m +secret/ms-even-cluster-client-cert kubernetes.io/tls 4 31m +secret/ms-even-cluster-config Opaque 1 31m +secret/ms-even-cluster-dbm-login kubernetes.io/basic-auth 1 31m +secret/ms-even-cluster-endpoint-cert kubernetes.io/tls 3 31m +secret/ms-even-cluster-master-key kubernetes.io/basic-auth 1 31m +secret/ms-even-cluster-server-cert kubernetes.io/tls 3 31m +secret/mssqlserver-ca kubernetes.io/tls 2 21d + +NAME READY AGE +issuer.cert-manager.io/mssqlserver-ca-issuer True 21d + +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE +persistentvolumeclaim/data-ms-even-cluster-0 Bound pvc-cf684a28-6840-4996-aecb-ac3f9d7b0961 1Gi RWO standard 31m +persistentvolumeclaim/data-ms-even-cluster-1 Bound pvc-6d9948e8-5e12-4409-90cc-57f6429037d9 1Gi RWO standard 31m +persistentvolumeclaim/data-ms-even-cluster-arbiter-0 Bound pvc-24f3a40f-ab24-4483-87d7-3d74010aaf75 2Gi RWO standard 30m +``` + +> Note: Your PVC size for data nodes might be 1000Gi, but for most of the cases you will never need more than 2Gi storage for arbiter node. + + +You can check arbiter pod has only one container by getting the pod yaml. +```bash +kubectl get pods -n demo ms-even-cluster-arbiter-0 -oyaml +``` + + + +## Connect to the database cluster + +KubeDB operator has created a new Secret called `ms-even-cluster-auth` *(format: {mssqlserver-object-name}-auth)* for storing the sa password for `sql server`. This secret contains a `username` key which contains the *username* for MSSQLServer SA and a `password` key which contains the *password* for MSSQLServer SA user. + +Now, we need `username` and `password` to connect to this database from `kubectl exec` command. In this example `ms-even-cluster-auth` secret holds username and password + +```bash +$ kubectl get secret -n demo ms-even-cluster-auth -o jsonpath='{.data.\username}' | base64 -d +sa + +$ kubectl get secret -n demo ms-even-cluster-auth -o jsonpath='{.data.\password}' | base64 -d +AgciggjkiIaSkDs1 +``` +We can exec into the pod `ms-even-cluster-0` using the following command: +```bash +$ kubectl exec -it -n demo ms-even-cluster-0 -c mssql -- bash +mssql@ms-even-cluster-0:/$ /opt/mssql-tools18/bin/sqlcmd -S localhost -U sa -P "AgciggjkiIaSkDs1" -No +1> select name from sys.databases +2> go +name +---------------------------------------------------------------------------------- +master +tempdb +model +msdb +agdb1 +agdb2 +kubedb_system + +(5 rows affected) +1> SELECT name FROM sys.availability_groups +2> go +name +---------------------------------------------------------------------------- +msevencluster + +(1 rows affected) +1> select replica_server_name from sys.availability_replicas; +2> go +replica_server_name +------------------------------------------------------------------------------------------- +ms-even-cluster-0 +ms-even-cluster-1 +(2 rows affected) +1> select database_name from sys.availability_databases_cluster; +2> go +database_name +------------------------------------------------------------------------------------------ +agdb1 +agdb2 + +(2 rows affected) + +``` + +See the pod roles: +```bash +$ kubectl get pods -n demo --selector=app.kubernetes.io/instance=ms-even-cluster -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.kubedb\.com/role}{"\n"}{end}' +ms-even-cluster-0 primary +ms-even-cluster-1 secondary +ms-even-cluster-arbiter-0 arbiter +``` + +From the output above, we can see that ms-even-cluster-0 is the primary node. To insert data, log into the primary MSSQLServer pod. Use the following command, + +```bash +$ kubectl exec -it ms-even-cluster-0 -c mssql -n demo -- bash +mssql@ms-even-cluster-0:/$ /opt/mssql-tools18/bin/sqlcmd -S localhost -U sa -P "AgciggjkiIaSkDs1" -No +1> SELECT database_name FROM sys.availability_databases_cluster +2> go +database_name +---------------------------------------------------------------------------------------------- +agdb1 +agdb2 + +(2 rows affected) +1> use agdb1 +2> go +Changed database context to 'agdb1'. +1> CREATE TABLE Data (ID INT, NAME NVARCHAR(255), AGE INT); +2> go +1> INSERT INTO Data(ID, Name, Age) VALUES (1, 'John Doe', 25), (2, 'Jane Smith', 30); +2> go +(2 rows affected) +1> Select * from data +2> go +ID NAME AGE +-------------------------------------------------------- +1 John Doe 25 +2 Jane Smith 30 + +(2 rows affected) +1> +``` +Now, Let's verify that the data inserted into the primary node has been replicated to the secondary node. + +### Access the inserted data from secondaries +Access the secondary node (Node 2) to verify that the data is present. + +```bash +$ kubectl exec -it ms-even-cluster-1 -c mssql -n demo -- bash +mssql@ms-even-cluster-1:/$ /opt/mssql-tools18/bin/sqlcmd -S localhost -U sa -P "AgciggjkiIaSkDs1" -No +1> SELECT database_name FROM sys.availability_databases_cluster +2> go +database_name +------------------------------------------------- +agdb1 +agdb2 + +(2 rows affected) +1> use agdb1 +2> go +Changed database context to 'agdb1'. +1> select * from data +2> go +ID NAME AGE +-------------------------------------------------------- +1 John Doe 25 +2 Jane Smith 30 + +(2 rows affected) +1> +``` + + +## Why do we need arbiter node? + +Few of our users don't want to run 3 node cluster as this was quite expensive for them, instead they wanted to use 2 node cluster, 1 primary and 1 replica. But due to raft implementation, there was chance of split voting. So we introduced this arbiter node so that they can still have 1 primary and 1 replica cluster and not have face potential split vote issue. + + +## Cleaning up + +```bash +kubectl delete ms -n demo ms-even-cluster +kubectl delete ns demo +``` + +## Next Steps +- Learn more about [Raft implementation](https://github.com/etcd-io/etcd/blob/main/contrib/raftexample/README.md) +- Learn about [backup and restore](/docs/v2025.2.19/guides/mssqlserver/backup/overview/) Microsoft SQL Server database using Stash. +- Want to set up Microsoft SQL Server cluster? Check how to [Configure Highly Available Microsoft SQL Server Cluster](/docs/v2025.2.19/guides/mssqlserver/clustering/ag_cluster) +- Monitor your Microsoft SQL Server database with KubeDB using [Prometheus operator](/docs/v2025.2.19/guides/mssqlserver/monitoring/using-prometheus-operator). +- Detail concepts of [MSSQLServer object](/docs/v2025.2.19/guides/mssqlserver/concepts/mssqlserver). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/v2025.2.19/CONTRIBUTING). \ No newline at end of file diff --git a/content/docs/v2025.2.19/guides/mssqlserver/scaling/_index.md b/content/docs/v2025.2.19/guides/mssqlserver/scaling/_index.md index 576673ffa6..fc10496e4c 100644 --- a/content/docs/v2025.2.19/guides/mssqlserver/scaling/_index.md +++ b/content/docs/v2025.2.19/guides/mssqlserver/scaling/_index.md @@ -3,7 +3,7 @@ title: Scaling Microsoft SQL Server menu: docs_v2025.2.19: identifier: ms-scaling - name: Scaling Microsoft SQL Server + name: Scaling SQL Server parent: guides-mssqlserver weight: 55 menu_name: docs_v2025.2.19 diff --git a/content/docs/v2025.2.19/guides/percona-xtradb/scaling/vertical-scaling/cluster/index.md b/content/docs/v2025.2.19/guides/percona-xtradb/scaling/vertical-scaling/cluster/index.md index 83c6cb53cb..ec1c2b98ae 100644 --- a/content/docs/v2025.2.19/guides/percona-xtradb/scaling/vertical-scaling/cluster/index.md +++ b/content/docs/v2025.2.19/guides/percona-xtradb/scaling/vertical-scaling/cluster/index.md @@ -110,7 +110,7 @@ $ kubectl get pod -n demo sample-pxc-0 -o json | jq '.spec.containers[].resource } ``` -You can see the Pod has the default resources which is assigned by Kubedb operator. +You can see the Pod has the default resources which is assigned by KubeDB operator. We are now ready to apply the `PerconaXtraDBOpsRequest` CR to update the resources of this database. diff --git a/content/docs/v2025.2.19/guides/postgres/arbiter/arbiter.md b/content/docs/v2025.2.19/guides/postgres/arbiter/arbiter.md index d1cb080533..6646612461 100644 --- a/content/docs/v2025.2.19/guides/postgres/arbiter/arbiter.md +++ b/content/docs/v2025.2.19/guides/postgres/arbiter/arbiter.md @@ -23,7 +23,7 @@ info: > New to KubeDB? Please start [here](/docs/v2025.2.19/README). -# Kubedb PostgreSQL - Arbiter node for PostgreSQL cluster with even nodes +# KubeDB PostgreSQL - Arbiter node for PostgreSQL cluster with even nodes Here we will show how to use KubeDB to provision a PostgreSQL DB with Arbiter Node. diff --git a/content/docs/v2025.2.19/guides/proxysql/scaling/vertical-scaling/cluster/index.md b/content/docs/v2025.2.19/guides/proxysql/scaling/vertical-scaling/cluster/index.md index e89a6f8d05..24025e90e1 100644 --- a/content/docs/v2025.2.19/guides/proxysql/scaling/vertical-scaling/cluster/index.md +++ b/content/docs/v2025.2.19/guides/proxysql/scaling/vertical-scaling/cluster/index.md @@ -144,7 +144,7 @@ $ kubectl get pod -n demo proxy-server-0 -o json | jq '.spec.containers[].resour } ``` -You can see the Pod has the default resources which is assigned by Kubedb operator. +You can see the Pod has the default resources which is assigned by KubeDB operator. We are now ready to apply the `ProxySQLOpsRequest` CR to update the resources of this server. diff --git a/content/docs/v2025.2.19/guides/rabbitmq/scaling/vertical-scaling/vertical-scaling.md b/content/docs/v2025.2.19/guides/rabbitmq/scaling/vertical-scaling/vertical-scaling.md index 9ef403f3b2..86b1088f89 100644 --- a/content/docs/v2025.2.19/guides/rabbitmq/scaling/vertical-scaling/vertical-scaling.md +++ b/content/docs/v2025.2.19/guides/rabbitmq/scaling/vertical-scaling/vertical-scaling.md @@ -108,7 +108,7 @@ $ kubectl get pod -n demo rm-standalone-0 -o json | jq '.spec.containers[].resou } ``` -You can see the Pod has default resources which is assigned by the Kubedb operator. +You can see the Pod has default resources which is assigned by the KubeDB operator. We are now ready to apply the `RabbitMQOpsRequest` CR to update the resources of this database. diff --git a/content/docs/v2025.2.19/guides/redis/backup/stash/standalone/index.md b/content/docs/v2025.2.19/guides/redis/backup/stash/standalone/index.md index eb6a50afd6..35343be385 100644 --- a/content/docs/v2025.2.19/guides/redis/backup/stash/standalone/index.md +++ b/content/docs/v2025.2.19/guides/redis/backup/stash/standalone/index.md @@ -116,7 +116,7 @@ Here, we have to use the service `sample-redis` and secret `sample-redis-auth` t ### Insert Sample Data -Now, we are going to exec into the database pod and create some sample data. Kubedb has created a secret with access credentials. Let's find out the credentials from the Secret, +Now, we are going to exec into the database pod and create some sample data. KubeDB has created a secret with access credentials. Let's find out the credentials from the Secret, ```yaml ❯ kubectl get secret -n demo sample-redis-auth -o yaml diff --git a/content/docs/v2025.2.19/guides/zookeeper/scaling/vertical-scaling/vertical-scaling.md b/content/docs/v2025.2.19/guides/zookeeper/scaling/vertical-scaling/vertical-scaling.md index 5107f00f61..2c159b4d9d 100644 --- a/content/docs/v2025.2.19/guides/zookeeper/scaling/vertical-scaling/vertical-scaling.md +++ b/content/docs/v2025.2.19/guides/zookeeper/scaling/vertical-scaling/vertical-scaling.md @@ -110,7 +110,7 @@ $ kubectl get pod -n demo zk-quickstart-0 -o json | jq '.spec.containers[].resou } ``` -You can see the Pod has default resources which is assigned by the Kubedb operator. +You can see the Pod has default resources which is assigned by the KubeDB operator. We are now ready to apply the `ZooKeeperOpsRequest` CR to update the resources of this database.