docs: add 0.9 cn docs and fix en docs bugs (#7983)

apecloud · Aug 19, 2024 · 400d86d · 400d86d
1 parent dbcca57
commit 400d86d
Show file tree

Hide file tree

Showing 384 changed files with 20,752 additions and 6,778 deletions.
diff --git a/docs/api_docs/installation/uninstall-kubeblocks.md b/docs/api_docs/installation/uninstall-kubeblocks.md
@@ -16,7 +16,7 @@ Uninstallation order:
 1. Delete your cluster if you have created a cluster.
 
    ```bash
-   kbcli cluster delete <name>
+   kubebctl delete cluster <clustername> -n namespace
    ```
 
 2. Uninstall KubeBlocks.

diff --git a/docs/api_docs/installation/upgrade/upgrade-kubeblocks-to-0.8.md b/docs/api_docs/installation/upgrade/upgrade-kubeblocks-to-0.8.md
@@ -2,7 +2,7 @@
 title: Upgrade to KubeBlocks v0.8
 description: Upgrade to KubeBlocks v0.8, operation, tips and notes
 keywords: [upgrade, 0.8]
-sidebar_position: 1
+sidebar_position: 2
 sidebar_label: Upgrade to KubeBlocks v0.8
 ---
 
@@ -15,7 +15,7 @@ In this tutorial, you will learn how to upgrade to KubeBlocks v0.8.
 
 :::note
 
-Execute `kbcli version` to check the current KubeBlocks version you are running, and then upgrade it.
+Execute `helm -n kb-system list | grep kubeblocks` to check the current KubeBlocks version you are running, and then upgrade it.
 
 :::
 

diff --git a/docs/api_docs/installation/upgrade/upgrade-kubeblocks-to-0.9.md b/docs/api_docs/installation/upgrade/upgrade-kubeblocks-to-0.9.md
@@ -12,7 +12,7 @@ In this tutorial, you will learn how to upgrade to KubeBlocks v0.9.
 
 :::note
 
-Execute `kbcli version` to check the current KubeBlocks version you are running, and then upgrade.
+Execute `helm -n kb-system list | grep kubeblocks` to check the current KubeBlocks version you are running, and then upgrade.
 
 :::
 

diff --git a/docs/api_docs/instance-template/how-to-use-instance-template.md b/docs/api_docs/instance-template/how-to-use-instance-template.md
@@ -16,20 +16,18 @@ In the official image of RisingWave, this information can be injected via enviro
 
 ## An example
 
-In the default template of RisingWave addon, the environment variables are configured as follows:
+In the default template of RisingWave addon, [the environment variables](https://github.com/apecloud/kubeblocks-addons/blob/main/addons/risingwave/templates/cmpd-compute.yaml#L26) are configured as follows:
 
 ```yaml
 apiVersion: apps.kubeblocks.io/v1alpha1
-kind: ClusterDefinition
+kind: ComponentDefinition
 metadata:
   name: risingwave
 # ...
 spec:
-  componentDefs:
-  - name: compute
-# ...
-    podSpec:
-      containers:
+#...
+  runtime:
+    containers:
       - name: compute
         securityContext:
           allowPrivilegeEscalation: false
@@ -60,7 +58,7 @@ spec:
 # ...
 ```
 
-After adding an instance template to the cluster resources:
+After adding an instance template to the [cluster resources](https://github.com/apecloud/kubeblocks-addons/blob/main/addons-cluster/risingwave/templates/cluster.yaml):
 
 ```yaml
 apiVersion: apps.kubeblocks.io/v1alpha1
@@ -71,7 +69,7 @@ metadata:
 # ...
 spec:
   componentSpecs:
-  - componentDefRef: compute
+  - componentDef: compute
     name: compute
     replicas: {{ .Values.risingwave.compute.replicas }}
     instances:

diff --git a/docs/api_docs/instance-template/introduction.md b/docs/api_docs/instance-template/introduction.md
@@ -14,7 +14,7 @@ An *instance* serves as the fundamental unit in KubeBlocks, comprising a Pod alo
 
 Starting from version 0.9, we're able to establish multiple instance templates for a particular component within a cluster. These instance templates include several fields such as Name, Replicas, Annotations, Labels, Env, Tolerations, NodeSelector, etc. These fields will ultimately override the corresponding ones in the default template (originating from ClusterDefinition and ComponentDefinition) to generate the final template for rendering the instance.
 
-## Why do we the instance template
+## Why do we introduce the instance template
 
 In KubeBlocks, a *Cluster* is composed of several *Components*, where each *Component* ultimately oversees multiple *Pods* and auxiliary objects.
 

diff --git a/docs/api_docs/kubeblocks-for-apecloud-mysql/cluster-management/expand-volume.md b/docs/api_docs/kubeblocks-for-apecloud-mysql/cluster-management/expand-volume.md
@@ -58,7 +58,7 @@ There are two ways to apply volume expansion.
    EOF
    ```
 
-2. For alidate the volume expansion operation.
+2. Validate the volume expansion operation.
 
    ```bash
    kubectl get ops -n demo

diff --git a/docs/api_docs/kubeblocks-for-elasticsearch/manage-elasticsearch.md b/docs/api_docs/kubeblocks-for-elasticsearch/manage-elasticsearch.md
@@ -98,7 +98,7 @@ EOF
 | `spec.affinity.topologyKeys`          | It represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints.   |
 | `spec.tolerations`                    | It is an array that specifies tolerations attached to the cluster's Pods, allowing them to be scheduled onto nodes with matching taints.  |
 | `spec.componentSpecs`                 | It is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster.   |
-| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition apecloud-mysql -o json \| jq '.spec.componentDefs[].name'`.   |
+| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition elasticsearch -o json \| jq '.spec.componentDefs[].name'`.   |
 | `spec.componentSpecs.name`            | It specifies the name of the component.     |
 | `spec.componentSpecs.disableExporter` | It defines whether the monitoring function is enabled. |
 | `spec.componentSpecs.replicas`        | It specifies the number of replicas of the component.  |

diff --git a/docs/api_docs/kubeblocks-for-kafka/cluster-management/create-a-kafka-cluster.md b/docs/api_docs/kubeblocks-for-kafka/cluster-management/create-a-kafka-cluster.md
@@ -11,7 +11,7 @@ import TabItem from '@theme/TabItem';
 
 # Create a Kafka cluster
 
-This document shows how to create a Kafka cluster.
+This document shows how to create a Kafka cluster by `kubectl` or a YAML file.
 
 ## Before you start
 

diff --git a/docs/api_docs/kubeblocks-for-milvus/manage-milvus.md b/docs/api_docs/kubeblocks-for-milvus/manage-milvus.md
@@ -241,7 +241,7 @@ EOF
 | `spec.affinity.topologyKeys`          | It represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints.   |
 | `spec.tolerations`                    | It is an array that specifies tolerations attached to the cluster's Pods, allowing them to be scheduled onto nodes with matching taints.  |
 | `spec.componentSpecs`                 | It is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster.   |
-| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition apecloud-mysql -o json \| jq '.spec.componentDefs[].name'`.   |
+| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition milvus -o json \| jq '.spec.componentDefs[].name'`.   |
 | `spec.componentSpecs.name`            | It specifies the name of the component.     |
 | `spec.componentSpecs.disableExporter` | It defines whether the monitoring function is enabled. |
 | `spec.componentSpecs.replicas`        | It specifies the number of replicas of the component.  |

diff --git a/...locks-for-mongodb/cluster-management/create-and-connect-to-a-mongodb-cluster.md b/...locks-for-mongodb/cluster-management/create-and-connect-to-a-mongodb-cluster.md
@@ -106,7 +106,7 @@ EOF
 | `spec.affinity.topologyKeys`          | It represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints.   |
 | `spec.tolerations`                    | It is an array that specifies tolerations attached to the cluster's Pods, allowing them to be scheduled onto nodes with matching taints.  |
 | `spec.componentSpecs`                 | It is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster.   |
-| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition apecloud-mysql -o json \| jq '.spec.componentDefs[].name'`.   |
+| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition mongodb -o json \| jq '.spec.componentDefs[].name'`.   |
 | `spec.componentSpecs.name`            | It specifies the name of the component.     |
 | `spec.componentSpecs.disableExporter` | It defines whether the monitoring function is enabled. |
 | `spec.componentSpecs.replicas`        | It specifies the number of replicas of the component.  |

diff --git a/docs/api_docs/kubeblocks-for-mongodb/cluster-management/switchover.md b/docs/api_docs/kubeblocks-for-mongodb/cluster-management/switchover.md
@@ -23,9 +23,9 @@ You can initiate a switchover for a MongoDB ReplicaSet. Then KubeBlocks modifies
    >
    probes:
      roleProbe:
-       failureThreshold: 2
+       failureThreshold: 3
        periodSeconds: 2
-       timeoutSeconds: 1
+       timeoutSeconds: 2
    ```
 
 ## Initiate the switchover

diff --git a/docs/api_docs/kubeblocks-for-mongodb/configuration/configuration.md b/docs/api_docs/kubeblocks-for-mongodb/configuration/configuration.md
@@ -140,7 +140,7 @@ You can also view the details of this configuration file and parameters.
   kbcli cluster explain-config mycluster --param=systemLog.verbosity --config-specs=mongodb-config -n demo
   ```
 
-  `--config-specs` is required to specify a configuration template since ApeCloud MySQL currently supports multiple templates. You can run `kbcli cluster describe-config mycluster` to view the all template names.
+  `--config-specs` is required to specify a configuration template if there are multiple templates. You can run `kbcli cluster describe-config mycluster` to view the all template names.
 
   <details>
 

diff --git a/...ysql-community-edition/cluster-management/create-and-connect-a-mysql-cluster.md b/...ysql-community-edition/cluster-management/create-and-connect-a-mysql-cluster.md
@@ -103,7 +103,7 @@ EOF
 | `spec.affinity.topologyKeys`          | It represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints.   |
 | `spec.tolerations`                    | It is an array that specifies tolerations attached to the cluster's Pods, allowing them to be scheduled onto nodes with matching taints.  |
 | `spec.componentSpecs`                 | It is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster.   |
-| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition apecloud-mysql -o json \| jq '.spec.componentDefs[].name'`.   |
+| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition mysql -o json \| jq '.spec.componentDefs[].name'`.   |
 | `spec.componentSpecs.name`            | It specifies the name of the component.     |
 | `spec.componentSpecs.disableExporter` | It defines whether the monitoring function is enabled. |
 | `spec.componentSpecs.replicas`        | It specifies the number of replicas of the component.  |

diff --git a/...cks-for-mysql-community-edition/cluster-management/scale-for-mysql-community.md b/...cks-for-mysql-community-edition/cluster-management/scale-for-mysql-community.md
@@ -74,7 +74,7 @@ There are two ways to apply vertical scaling.
    demo        ops-vertical-scaling   VerticalScaling   mycluster   Succeed   3/3        6m
    ```
 
-   If an error occurs to the vertical scaling operation, you can troubleshoot with `kubectl describe ops -n demo` command to view the events of this operation.
+   If an error occurs, you can troubleshoot with `kubectl describe ops -n demo` command to view the events of this operation.
 
 3. Check whether the corresponding resources change.
 

diff --git a/...s/kubeblocks-for-mysql-community-edition/high-availability/high-availability.md b/...s/kubeblocks-for-mysql-community-edition/high-availability/high-availability.md
@@ -63,7 +63,7 @@ The faults here are all simulated by deleting pods. When there are sufficient re
 
    ***How the automatic recovery works***
 
-   After the primary pod is deleted, the MySQL Replication Cluster elects a new primary pod. In this example, `mycluster-mysql-0` is elected as the new primary pod. KubeBlocks detects that the primary pod has changed, and sends a notification to update the access link. The original exception node automatically rebuilds and recovers to the normal Replication Cluster state. It normally takes 30 seconds from exception to recovery.
+   After the primary pod is deleted, the MySQL Replication Cluster elects a new primary pod. In this example, `mycluster-mysql-1` is elected as the new primary pod. KubeBlocks detects that the primary pod has changed, and sends a notification to update the access link. The original exception node automatically rebuilds and recovers to the normal Replication Cluster state. It normally takes 30 seconds from exception to recovery.
 
 ### Secondary pod exception
 

diff --git a/...ks-for-postgresql/cluster-management/create-and-connect-a-postgresql-cluster.md b/...ks-for-postgresql/cluster-management/create-and-connect-a-postgresql-cluster.md
@@ -101,7 +101,7 @@ EOF
 | `spec.affinity.topologyKeys`          | It represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints.   |
 | `spec.tolerations`                    | It is an array that specifies tolerations attached to the cluster's Pods, allowing them to be scheduled onto nodes with matching taints.  |
 | `spec.componentSpecs`                 | It is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster.   |
-| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition apecloud-mysql -o json \| jq '.spec.componentDefs[].name'`.   |
+| `spec.componentSpecs.componentDefRef` | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition postgresql -o json \| jq '.spec.componentDefs[].name'`.   |
 | `spec.componentSpecs.name`            | It specifies the name of the component.     |
 | `spec.componentSpecs.disableExporter` | It defines whether the monitoring function is enabled. |
 | `spec.componentSpecs.replicas`        | It specifies the number of replicas of the component.  |

diff --git a/...ocs/kubeblocks-for-postgresql/cluster-management/delete-a-postgresql-cluster.md b/...ocs/kubeblocks-for-postgresql/cluster-management/delete-a-postgresql-cluster.md
@@ -8,14 +8,14 @@ sidebar_label: Delete protection
 
 # Delete a PostgreSQL Cluster
 
+## Termination policy
+
 :::note
 
 The termination policy determines how a cluster is deleted.
 
 :::
 
-## Termination policy
-
 | **terminationPolicy** | **Deleting Operation**                                                                     |
 |:----------------------|:-------------------------------------------------------------------------------------------|
 | `DoNotTerminate`      | `DoNotTerminate` blocks delete operation.                                                  |

diff --git a/...cs/kubeblocks-for-postgresql/cluster-management/restart-a-postgresql-cluster.md b/...cs/kubeblocks-for-postgresql/cluster-management/restart-a-postgresql-cluster.md
@@ -11,12 +11,6 @@ sidebar_label: Restart
 
 You can restart all pods of the cluster. When an exception occurs in a database, you can try to restart it.
 
-:::note
-
-Restarting a PostgreSQL cluster triggers a concurrent restart and the primary may change after the cluster restarts.
-
-:::
-
 ## Steps
 
 1. Restart a cluster.

diff --git a/docs/api_docs/kubeblocks-for-postgresql/high-availability/high-availability.md b/docs/api_docs/kubeblocks-for-postgresql/high-availability/high-availability.md
@@ -101,7 +101,7 @@ KubeBlocks integrates [the open-source Patroni solution](https://patroni.readthe
 
    ![PostgreSQL replication info](./../../../img/api-ha-pg-replication-info.png)
 
-   From the output, `pg-cluster-postgresql-0` has been assigned as the secondary pod.
+   From the output, `mycluster-postgresql-0` has been assigned as the secondary pod.
 
 5. View the status of the PostgreSQL cluster and pods again.
 
@@ -113,4 +113,4 @@ KubeBlocks integrates [the open-source Patroni solution](https://patroni.readthe
 
    ![PostgreSQL cluster status after HA](./../../../img/api-ha-pg-after.png)
 
-   After the failover, `mycluster-postgresql-0` becomes the secondary pod and `pg-cluster-postgresql-1` becomes the primary pod.
+   After the failover, `mycluster-postgresql-0` becomes the secondary pod and `mycluster-postgresql-1` becomes the primary pod.
diff --git a/...kubeblocks-for-pulsar/cluster-management/create-pulsar-cluster-on-kubeblocks.md b/...kubeblocks-for-pulsar/cluster-management/create-pulsar-cluster-on-kubeblocks.md
@@ -6,6 +6,8 @@ sidebar_position: 1
 sidebar_label: Create
 ---
 
+# Create a Pulsar Cluster
+
 ## Introduction
 
 KubeBlocks can quickly integrate new engines through good abstraction. KubeBlocks supports Pulsar operations, including basic lifecycle operations such as cluster creation, deletion, and restart, as well as advanced operations such as horizontal and vertical scaling, volume expansion, configuration changes, and monitoring.

diff --git a/docs/api_docs/kubeblocks-for-pulsar/cluster-management/scale-for-pulsar.md b/docs/api_docs/kubeblocks-for-pulsar/cluster-management/scale-for-pulsar.md
@@ -151,6 +151,14 @@ From v0.9.0, besides replicas, KubeBlocks also supports scaling in and out insta
 
 - It is recommended to keep 3 nodes without scaling for Zookeeper, and other components can scale horizontally for multiple or single components
 - The scaling of the Bookies node needs to be cautious. The data copy is related to the EnsembleSize, Write Quorum, and Ack Quorum configurations, scaling may cause data loss. Check [Pulsar official document](https://pulsar.apahe.org/docs/3.0.x/administration-zk-bk/#decommission-bookies-cleanly) for detailed information.
+- Check whether the cluster status is `Running`. Otherwise, the following operations may fail.
+
+   ```bash
+   kubectl get cluster mycluster -n demo
+   >
+   NAME        CLUSTER-DEFINITION   VERSION        TERMINATION-POLICY     STATUS    AGE
+   mycluster   pulsar               pulsar-3.0.2   Delete                 Running   47m
+   ```
 
 ### Steps
 

diff --git a/docs/api_docs/kubeblocks-for-pulsar/configuration/configuration.md b/docs/api_docs/kubeblocks-for-pulsar/configuration/configuration.md
@@ -2,12 +2,13 @@
 title: Configure cluster parameters
 description: Configure cluster parameters
 keywords: [pulsar, parameter, configuration, reconfiguration]
-sidebar_position: 4
+sidebar_position: 1
+sidebar_label: Configuration
 ---
 
 # Configure cluster parameters
 
-This guide shows how to configure cluster parameters by creating an opsRequest.
+This guide shows how to configure cluster parameters.
 
 For Pulsar, there are 3 types of parameters:
 
@@ -46,7 +47,7 @@ Using kubectl to configure pulsar cluster requires modifying the configuration f
 
 ## Configure cluster parameters with OpsRequest
 
-1. Define an OpsRequest file and configure the parameters in the OpsRequest in a yaml file named `mycluster-configuring-demo.yaml`. In this example, `max_connections` is configured as `600`.
+1. Define an OpsRequest file and configure the parameters in the OpsRequest in a yaml file named `mycluster-configuring-demo.yaml`. In this example, `lostBookieRecoveryDelay` is configured as `1000`.
 
    ```bash
    apiVersion: apps.kubeblocks.io/v1alpha1