docs: fix 0.9 docs (#7664)

(cherry picked from commit f94336f)

docs/api_docs/alarm-and-monitor/observability/alert.md

@@ -1,14 +1,12 @@
 ---
 title: Configure alert
 description: How to enable alert
-keywords: [mysql, alert, alert message, email alert]
+keywords: [alert, alert message, email alert]
 sidebar_position: 2
 ---
 
 # Configure alert
 
-## Configure alert
-
 Alerts are mainly used for daily error response to improve system availability. KubeBlocks uses the open-source version of Prometheus to configure alert rules and multiple notification channels. The alert capability of KubeBlocks can meet the operation and maintenance requirements of production-level online clusters.
 
 :::note
@@ -17,7 +15,7 @@ The alert function is the same for all.
 
 :::
 
-### Alert rules
+## Alert rules
 
 KubeBlocks uses the open-source version of Prometheus to meet the needs of various data products. These alert rules provide the best practice for cluster operation and maintenance, which further improve alert accuracy and reduce the probability of false negatives and false positives by experience-based smoothing windows, alert thresholds, alert levels, and alert indicators.
 
@@ -41,7 +39,7 @@ alert: PostgreSQLTooManyConnections
 
 Configure alert rules as needed. For more details, please refer to [Prometheus alerting rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/#defining-alerting-rules).
 
-### Notifications
+## Notifications
 
 The alert message notification of KubeBlocks mainly adopts the AlertManager native capability. After receiving the Prometheus alert, KubeBlocks performs steps including deduplication, grouping, silence, suppression, and routing, and finally sends it to the corresponding notification channel.
 

docs/api_docs/alarm-and-monitor/observability/monitor-database.md

@@ -56,9 +56,9 @@ Here is an example of enabling the `prometheus` addon. You can enable other moni
    ```bash
    helm list -A
    >
-   NAME                          NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                           APP VERSION
+   NAME         NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                APP VERSION
    ......
-   prometheus                  	kb-system	1       	   2024-05-31 12:01:52.872584 +0800 CST    deployed	 prometheus-15.16.1          	   2.39.1 
+   prometheus   kb-system   1           2024-05-31 12:01:52.872584 +0800 CST    deployed    prometheus-15.16.1   2.39.1 
    ```
 
 ### Enable the monitoring function for a database
@@ -92,7 +92,7 @@ componentSpecs:
     monitor: false # Change this value
 ```
 
-### View the dashboardß
+### View the dashboard
 
 Use the `grafana` addon provided by KubeBlocks to view the dashboard.
 
@@ -117,6 +117,14 @@ Use the `grafana` addon provided by KubeBlocks to view the dashboard.
 3. Open the web browser and enter the address `127.0.0.1:3000` to visit the dashboard.
 4. Enter the username and password obtained from step 1.
 
+:::note
+
+If there is no data in the dashboard, you can check whether the job is `kubeblocks-service`. Enter `kubeblocks-service` in the job field and press the enter button.
+
+![monitoring](./../../img/api-monitoring.png)
+
+:::
+
 ### (Optional) Enable remote write
 
 KubeBlocks supports the `victoria-metrics-agent` addon to enable you to remotely write the data to your VM. Compared with the native Prometheus, [vmgent](https://docs.victoriametrics.com/vmagent.html) is lighter.

docs/api_docs/handle-an-exception/full-disk-lock.md

@@ -9,7 +9,7 @@ sidebar_label: Full disk lock
 
 The full disk lock function of KubeBlocks ensures the stability and availability of a database. This function triggers a disk lock when the disk usage reaches a set threshold, thereby pausing write operations and only allowing read operations. Such a mechanism prevents a database from being affected by disk space exhaustion.
 
-## Lock/unlock mechanism
+## Mechanism of lock/unlock
 
 When the space water level of any configured volume exceeds the defined threshold, the instance is locked (read-only). Meanwhile, the system sends a related warning event, including the specific threshold and space usage information of each volume.
 
@@ -19,7 +19,7 @@ When the space water level of all configured volumes falls below the defined thr
 
 1. The full disk lock function currently supports global (ClusterDefinition) enabling or disabling and does not support Cluster dimension control. Dynamically enabling or disabling this function may affect the existing Cluster instances that use this ClusterDefinition and cause them to restart. Please operate with caution.
 
-2. The full disk locking function relies on the read permission (get & list) of the two system resource nodes and nodes/stats. If you create an instance via kbcli, make sure to grant the controller administrative rights to the ClusterRoleBinding.
+2. The full disk lock function relies on the read permission (get & list) of the two system resource nodes and nodes/stats. If you create an instance via kbcli, make sure to grant the controller administrative rights to the ClusterRoleBinding.
 
 3. Currently, full disk lock is available for ApeCloud MySQL, PostgreSQL and MongoDB.
 

docs/api_docs/instance-template/how-to-use-instance-template.md

@@ -1,14 +1,24 @@
+---
+title: Apply instance template
+description: Apply instance template
+keywords: [apply instance template, instance template]
+sidebar_position: 2
+sidebar_label: Apply instance template
+---
+
 # Apply instance template
 
-Instance template can be applied to many scenarios. In this section, we take RisingWave cluster as an example.
-KubeBlocks supports the management of RisingWave clusters. The RisingWave addon is contributed by the RisingWave official team.  For RisingWave to function optimally, it relies on an external storage solution, such as AWS S3 or Alibaba Cloud OSS, to serve as its state backend. When creating a RisingWave cluster, it is necessary to configure credentials and other information for the external storage to ensure normal operation, and these information may vary for each cluster.
+Instance templates can be applied to many scenarios. In this section, we take a RisingWave cluster as an example.
+
+KubeBlocks supports the management of RisingWave clusters. The RisingWave addon is contributed by the RisingWave official team. For RisingWave to function optimally, it relies on an external storage solution, such as AWS S3 or Alibaba Cloud OSS, to serve as its state backend. When creating a RisingWave cluster, it is necessary to configure credentials and other information for the external storage to ensure normal operation, and this information may vary for each cluster.
 
-In the official image of RisingWave, these information can be injected via environment variables. Therefore, in KubeBlocks 0.9, we can configure corresponding environment variables in the instance template and set the values of these environment variables each time a cluster is created, so as to inject credential information into the container of RisingWave.
+In the official image of RisingWave, this information can be injected via environment variables. Therefore, in KubeBlocks 0.9, we can configure corresponding environment variables in the instance template and set the values of these environment variables each time a cluster is created, so as to inject credential information into the container of RisingWave.
 
 ## An example
 
-In the default template of RisingWave addon, the environment viriables are configured as follows:
-```
+In the default template of RisingWave addon, the environment variables are configured as follows:
+
+```yaml
 apiVersion: apps.kubeblocks.io/v1alpha1
 kind: ClusterDefinition
 metadata:
@@ -49,8 +59,10 @@ spec:
           value: 0.0.0.0:1222
 # ...
 ```
+
 After adding an instance template to the cluster resources:
-```
+
+```yaml
 apiVersion: apps.kubeblocks.io/v1alpha1
 kind: Cluster
 metadata:
@@ -94,59 +106,78 @@ spec:
         value: "{{ .Values.risingwave.metaStore.etcd.authentication.enabled}}"
 # ...
 ```
+
 In the example above, we added an instance template through the `instances` field, named `instance`. This template defines several environment variables such as `RW_STATE_STORE` and `AWS_REGION`. These environment variables will be appended by KubeBlocks to the list of environment variables defined in the default template. Consequently, the rendered instance will contain both the default template and all the environment variables defined in this instance template.
 
 Additionally, the `replicas` field in the instance template is identical to that in the `componentSpec` (both are `{{ .Values.risingwave.compute.replicas }}`), indicating that after overriding the default template, this instance template will be used to render all instances within this component.
 
-## Detailed information of instance template
+## Detailed information on instance template
 
-- `Name` field: For each component, multiple instance templates can be defined. Template name is configured with `Name` field, and must remain unique within the same component.
+- `Name` field: For each component, multiple instance templates can be defined. The template name is configured with the `Name` field and must remain unique within the same component.
 - `Replica` field: Each template can set the number of instances rendered based on that template via the `Replicas` field, of which the default value is 1. The sum of `Replicas` for all instance templates within the same component must be less than or equal to the `Replicas` value of the component. If the number of instances rendered based on the instance templates is less than the total number required by the component, the remaining instances will be rendered using the default template.
 
-The pattern for the names of instances rendered based on instance templates is `$(cluster name)-$(component name)-$(instance template name)-ordinal`. For example, in the above RisingWave cluster, the cluster name is `risingwave`, the component name is `compute`, the instance template name is `instance`, and the number of `Replicas` is 3. Therefore, the rendered instance names are: risingwave-compute-instance-0, risingwave-compute-instance-1, risingwave-compute-instance-2.
+The pattern for the names of instances rendered based on instance templates is `$(cluster name)-$(component name)-$(instance template name)-ordinal`. For example, in the above RisingWave cluster, the cluster name is `risingwave`, the component name is `compute`, the instance template name is `instance`, and the number of `Replicas` is 3. Therefore, the rendered instance names are risingwave-compute-instance-0, risingwave-compute-instance-1, and risingwave-compute-instance-2.
 
-Instance templates can be used during cluster creation and can be updated during operations period. Specifically, this includes adding, deleting, or updating instance templates. Updating instance templates may update, delete, or reconstruct instances. You are recommended to carefully evaluate whether the final changes meet expectations before performing updates.
+Instance templates can be used during cluster creation and can be updated during the operations period. Specifically, this includes adding, deleting, or updating instance templates. Updating instance templates may update, delete, or reconstruct instances. You are recommended to carefully evaluate whether the final changes meet expectations before performing updates.
 
 ### Annotations
-The `Annotations` in the instance template are used to override the `Annotations` field in the default template. If a Key in the `Annotations` of the instance template already exists in the default template, the `value` corresponding to the Key will use the value in the instance template; if the Key does not exist in the default template, the Key and Value will be added to the final `Annotations`. 
+
+The `Annotations` in the instance template are used to override the `Annotations` field in the default template. If a Key in the `Annotations` of the instance template already exists in the default template, the `value` corresponding to the Key will use the value in the instance template; if the Key does not exist in the default template, the Key and Value will be added to the final `Annotations`.
+
 ***Example:***
+
 The `annotations` in the default template are:
-```
+
+```yaml
 annotations:
   "foo0": "bar0"
   "foo1": "bar"
 ```
+
 And `annotations` in the instance templates are:
-```
+
+```yaml
 annotations:
   "foo1": "bar1"
   "foo2": "bar2"
 ```
+
 Then, after rendering, the actual annotations are:
-```
+
+```yaml
 annotations:
   "foo0": "bar0"
   "foo1": "bar1"
   "foo2": "bar2"
 ```
-...note
+
+:::note
+
 KubeBlocks adds system `Annotations`, and do not overwrite them.
-...
 
+:::
 
 ### Labels
-You can also set `Labels` with instance template.
+
+You can also set `Labels` with the instance template.
+
 Similar to `Annotations`, `Labels` in instance templates follow the same overriding logic applied to existing labels.
-...note
+
+:::note
+
 KubeBlocks adds system `Labels`, and do not overwrite them.
-...
+
+:::
 
 ### Image
+
 The `Image` field in the instance template is used to override the `Image` field of the first container in the default template.
 
-...note:
-`Image` field should be used with caution: for statefulset like databases, changing the `Image` often involves compatibility issues with data formats. When changing this field, please ensure that the image version in the instance template is fully compatible with that in the default template.
-...
+:::note
+
+`Image` field should be used with caution: for the StatefulSet like databases, changing the `Image` often involves compatibility issues with data formats. When changing this field, please ensure that the image version in the instance template is fully compatible with that in the default template.
+
+:::
 
 With KubeBlocks version 0.9 and above, detailed design for image versions is provided through `ComponentVersion`. It is recommended to manage versions using `ComponentVersion`.
 
@@ -186,4 +217,4 @@ Used to override the `VolumeMounts` field of the first container in the default
 
 ### VolumeClaimTemplates
 
-Used to override the `VolumeClaimTemplates` generated by `ClusterComponentVolumeClaimTemplate` within the Component. The overriding logic is similar to `Volumes`, meaning if the `PersistentVolumeClaim` `Name` is the same, the `PersistentVolumeClaimSpec` values from the instance template will be used; otherwise, it will be added as a new `PersistentVolumeClaim`.
+Used to override the `VolumeClaimTemplates` generated by `ClusterComponentVolumeClaimTemplate` within the Component. The overriding logic is similar to `Volumes`, meaning if the `PersistentVolumeClaim` `Name` is the same, the `PersistentVolumeClaimSpec` values from the instance template will be used; otherwise, it will be added as a new `PersistentVolumeClaim`.

docs/api_docs/instance-template/introduction.md

@@ -1,21 +1,27 @@
+---
+title: Introduction of Instance Template
+description: Introduction of Instance Template
+keywords: [instance template]
+sidebar_position: 1
+sidebar_label: Introduction of instance template
+---
 
-# Introduction of Instance Template
-
-## What is instance template
+# Introduction of instance template
 
+## What is an instance template
 
 An *instance* serves as the fundamental unit in KubeBlocks, comprising a Pod along with several auxiliary objects. To simplify, you can initially think of it as a Pod, and henceforth, we'll consistently refer to it as an "Instance."
 
 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 we design instance template
+## Why do we the instance template
 
 In KubeBlocks, a *Cluster* is composed of several *Components*, where each *Component* ultimately oversees multiple *Pods* and auxiliary objects.
 
 Prior to version 0.9, these pods were rendered from a shared PodTemplate, as defined in either ClusterDefinition or ComponentDefinition. However, this design can’t meet the following demands:
+
  - For Clusters rendered from the same addon, setting separate scheduling configurations such as *NodeName*, *NodeSelector*, or *Tolerations*.
  - For Components rendered from the same addon, adding custom *Annotations*, *Labels*, or ENV to the Pods they manage.
-- For Pods managed by the same Component, configuring different *CPU*, *Memory*, and other *Resource Requests* and *Limits*.
+ - For Pods managed by the same Component, configuring different *CPU*, *Memory*, and other *Resource Requests* and *Limits*.
 
-With various similar requirements emerging, the Cluster API introduced the Instance Template feature from version 0.9 onwards to cater to these needs.
+With various similar requirements emerging, the Cluster API introduced the Instance Template feature from version 0.9 onwards to cater to these needs.

docs/api_docs/kubeblocks-for-apecloud-mysql/cluster-management/create-and-connect-a-mysql-cluster.md

@@ -18,7 +18,7 @@ This tutorial shows how to create and connect to an ApeCloud MySQL cluster.
 * Make sure the `apecloud-mysql` cluster definition is installed. If the cluster definition is not available, refer to [this doc](./../../overview/supported-addons.md#install-addons) to enable it first.
 
   ```bash
-  kubectl get clusterdefinition mysql
+  kubectl get clusterdefinition apecloud-mysql
   >
   NAME             TOPOLOGIES   SERVICEREFS   STATUS      AGE
   apecloud-mysql                              Available   27m
@@ -49,7 +49,7 @@ cat <<EOF | kubectl apply -f -
 apiVersion: apps.kubeblocks.io/v1alpha1
 kind: Cluster
 metadata:
-  name: acmysql-cluster
+  name: mycluster
   namespace: default
 spec:
   clusterDefinitionRef: apecloud-mysql

docs/api_docs/kubeblocks-for-kafka/cluster-management/create-a-kafka-cluster.md

@@ -57,7 +57,7 @@ This document shows how to create a Kafka cluster.
     apiVersion: apps.kubeblocks.io/v1alpha1
     kind: Cluster
     metadata:
-      name: kafka-cluster
+      name: mycluster
       namespace: demo
       annotations:
         "kubeblocks.io/extra-env": '{"KB_KAFKA_ENABLE_SASL":"false","KB_KAFKA_BROKER_HEAP":"-XshowSettings:vm -XX:MaxRAMPercentage=100 -Ddepth=64","KB_KAFKA_CONTROLLER_HEAP":"-XshowSettings:vm -XX:MaxRAMPercentage=100 -Ddepth=64","KB_KAFKA_PUBLIC_ACCESS":"false", "KB_KAFKA_BROKER_NODEPORT": "false"}'

docs/api_docs/kubeblocks-for-redis/redis-cluster-mode.md

@@ -338,17 +338,7 @@ spec:
 
 ### Restart
 
-```yaml
-apiVersion: apps.kubeblocks.io/v1alpha1
-kind: OpsRequest
-metadata:
-  name: restart-redisc
-spec:
-  clusterName: redisc
-  restart:
-  - componentName: shard
-  type: Restart
-```
+Currently, restarting a Redis Cluster is not supported and it will be supported in the future.
 
 ### Stop/Start
 

docs/api_docs/maintenance/backup-and-restore/backup/configure-backuppolicy.md

@@ -44,15 +44,14 @@ If you do not need to enable backup encryption by default, or if you need to use
     --from-literal=secretKey='your secret key'
     ```
 
-2. Patch the BackupPolicy to enable encryption.
-Remember to reference the key created before.
+2. Patch the BackupPolicy to enable encryption. Remember to reference the key created before.
 
     ```bash
     kubectl --type merge patch backuppolicy mysqlcluster-mysql-backup-policy \
     -p '{"spec":{"encryptionConfig":{"algorithm":"AES-256-CFB","passPhraseSecretKeyRef":{"name":"backup-encryption","key":"secretKey"}}}}'
     ```
 
-Complete. Now you can perform backups and restores as usual.
+Now you can perform backups and restores as usual.
 
 :::note