From f8c729f0b021474d03345b85715db2a95d194a9d Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Mon, 28 Oct 2024 18:05:11 +0800 Subject: [PATCH 01/11] docs: merge cn api docs --- ...t-to-database-in-production-environment.md | 186 ++++++++- ...nect-to-database-in-testing-environment.md | 112 ++++- .../overview-on-connect-databases.md | 13 +- .../handle-a-cluster-exception.md | 19 + .../backup-and-restore/_category_.yml | 2 +- .../backup-and-restore/backup/backup-repo.md | 269 +++++++++++- .../backup/configure-backup-policy.md | 67 ++- .../backup/on-demand-backup.md | 77 +++- .../backup/scheduled-backup.md | 45 ++ .../backup-and-restore/restore/pitr.md | 76 +++- .../restore/restore-data-from-backup-set.md | 76 +++- .../cross-k8s-deployment/_category_.yaml | 4 + .../cross-k8s-deployment.md | 346 ++++++++++++++++ .../in-place-update/_category_.yaml | 4 + .../in-place-update/ignore-vertical-scale.md | 13 + .../maintenance/in-place-update/overview.md | 55 +++ .../instance-template/_category_.yml | 4 + .../how-to-use-instance-template.md | 218 ++++++++++ .../instance-template/introduction.md | 27 ++ .../resource-scheduling.md | 167 +++++++- .../maintenance/scale/_category_.yaml | 4 + .../maintenance/scale/horizontal-scale.md | 385 ++++++++++++++++++ .../maintenance/scale/vertical-scale.md | 130 ++++++ .../observability/configure-alert.md | 12 +- .../observability/monitor-database.md | 212 +++++++++- 25 files changed, 2456 insertions(+), 67 deletions(-) create mode 100644 i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/_category_.yaml create mode 100644 i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md create mode 100644 i18n/zh-cn/user-docs/maintenance/in-place-update/_category_.yaml create mode 100644 i18n/zh-cn/user-docs/maintenance/in-place-update/ignore-vertical-scale.md create mode 100644 i18n/zh-cn/user-docs/maintenance/in-place-update/overview.md create mode 100644 i18n/zh-cn/user-docs/maintenance/instance-template/_category_.yml create mode 100644 i18n/zh-cn/user-docs/maintenance/instance-template/how-to-use-instance-template.md create mode 100644 i18n/zh-cn/user-docs/maintenance/instance-template/introduction.md create mode 100644 i18n/zh-cn/user-docs/maintenance/scale/_category_.yaml create mode 100644 i18n/zh-cn/user-docs/maintenance/scale/horizontal-scale.md create mode 100644 i18n/zh-cn/user-docs/maintenance/scale/vertical-scale.md diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md index 35aa25217e2..a52116a204f 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md @@ -2,23 +2,33 @@ title: 在生产环境中连接数据库 description: 如何在生产环境中连接数据库 keywords: [生产环境, 连接数据库] -sidebar_position: 4 +sidebar_position: 3 sidebar_label: 生产环境 --- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + # 在生产环境中连接数据库 在生产环境中，使用 CLI 和 SDK 客户端连接数据库是很常见的。主要有以下三种场景： -- 场景 1：Client1 和数据库位于同一个 Kubernetes 集群中。如果要连接 Client1 和数据库，请参考[方案 3](#方案-3-连接在同一个-kubernetes-集群中的客户端)。 -- 场景 2：Client2 在 Kubernetes 集群之外，但与数据库位于同一个 VPC 中。如果要连接 Client2 和数据库，请参考[方案 5](#方案-5-连接在-kubernetes-集群之外但与-kubernetes-集群位于同一-vpc-中的客户端)。 -- 场景 3：Client3 和数据库位于不同的 VPC，例如其他 VPC 或公共网络。如果要连接 Client3 和数据库，请参考[方案 4](#方案-4-连接在其他-vpc-或公共网络中的客户端)。 + +- 场景 1：Client1 和数据库位于同一个 Kubernetes 集群中。如果要连接 Client1 和数据库，请参考[使用 ClusterIP 方案](#场景-1-连接在同一个-kubernetes-集群中的客户端)。 +- 场景 2：Client2 在 Kubernetes 集群之外，但与数据库位于同一个 VPC 中。如果要连接 Client2 和数据库，请参考[暴露 VPC 私有地址方案](#场景-2-连接在-kubernetes-集群之外但与-kubernetes-集群位于同一-vpc-中的客户)。 +- 场景 3：Client3 和数据库位于不同的 VPC，例如其他 VPC 或公共网络。如果要连接 Client3 和数据库，请参考[暴露 VPC 公网地址方案](#场景-3-连接在其他-vpc-或公共网络中的客户端)。 参考下面的网络位置关系图。 ![Example](../img/../../img/connect-to-database-in-production-env-network-locations.jpg) -## 方案 3. 连接在同一个 Kubernetes 集群中的客户端 +## 场景 1. 连接在同一个 Kubernetes 集群中的客户端 + +你可以使用数据库的 ClusterIP 或域名进行连接。 + + -你可以使用数据库的 ClusterIP 或域名进行连接。使用 `kbcli cluster describe ${cluster-name}` 检查数据库的端口。 + + +使用 `kbcli cluster describe ${cluster-name}` 检查数据库的端口。 ```bash kbcli cluster describe x @@ -47,9 +57,21 @@ Events(last 5 warnings, see more:kbcli cluster list-events -n default x): TIME TYPE REASON OBJECT MESSAGE ``` -## 方案 4. 连接在其他 VPC 或公共网络中的客户端 + + + -你可以启用云厂商提供的外部负载均衡器。 +```bash +kubectl get service mycluster-mysql +``` + + + + + +## 场景 2. 连接在 Kubernetes 集群之外但与 Kubernetes 集群位于同一 VPC 中的客户 + +使用一个稳定的域名以实现长期连接。你可以使用云厂商提供的内部负载均衡器来实现这一目的。 :::note @@ -57,25 +79,93 @@ TIME TYPE REASON OBJECT MESSAGE ::: + + + + +```bash +kbcli cluster expose ${cluster-name} --type vpc --enable=true +``` + + + + + +```bash +kubectl apply -f - < + + + +如需禁用负载均衡器实例，请执行以下命令。 + + + + + ```bash -kbcli cluster expose ${cluster-name} --type internet --enable=true +kbcli cluster expose ${cluster-name} --type vpc --enable=false ``` -要禁用负载均衡器实例，请执行以下命令。 + + + ```bash -kbcli cluster expose ${cluster-name} --type internet --enable=false +kubectl apply -f - < + + + :::note 禁用负载均衡器实例后，实例将无法访问。 ::: -## 方案 5. 连接在 Kubernetes 集群之外但与 Kubernetes 集群位于同一 VPC 中的客户端 +## 场景 3. 连接在其他 VPC 或公共网络中的客户端 -使用一个稳定的域名以实现长期连接。你可以使用云厂商提供的内部负载均衡器来实现这一目的。 +您可开启云厂商的外部负载均衡器。 :::note @@ -83,11 +173,45 @@ kbcli cluster expose ${cluster-name} --type internet --enable=false ::: + + + + ```bash kbcli cluster expose ${cluster-name} --type vpc --enable=true ``` -要禁用负载均衡器实例，请执行以下命令。 + + + + +```bash +kubectl apply -f - < + + + +如需禁用负载均衡器实例，请执行以下命令。 :::note @@ -95,6 +219,40 @@ kbcli cluster expose ${cluster-name} --type vpc --enable=true ::: + + + + ```bash kbcli cluster expose ${cluster-name} --type vpc --enable=false ``` + + + + + +```bash +kubectl apply -f - < + + diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md index e21a756e456..755dc213aa2 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md @@ -2,12 +2,19 @@ title: 在测试环境中连接数据库 description: 如何在测试环境中连接数据库 keywords: [连接数据库, 测试环境] -sidebar_position: 3 +sidebar_position: 2 sidebar_label: 测试环境 --- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + # 在测试环境中连接数据库 + + + + ## 方案 1. 使用 kbcli cluster connect 命令 你可以使用 `kbcli cluster connect` 命令并指定要连接的集群名称。 @@ -40,3 +47,106 @@ kbcli cluster connect --show-example --show-password ${cluster-name} ::: ![testing env](../img/../../img/connect-to-database-in-testing-env.png) + + + + +## 步骤 1. 获取数据库凭证 + +在连接运行在 Kubernetes 集群内的 MySQL 数据库之前，您需要从 Kubernetes Secret 中获取用户名和密码。Kubernetes 中的 Secret 通常是经过 base64 编码的，因此您需要将其解码以获得实际的凭据。以下是使用 kubectl 获取凭据的方法。 + +1. 获取 `username`。 + + 使用 `kubectl get secrects` 命令，从 demo 命名空间中名为 `mycluster-conn-credential` 的 secret 中提取用户名。 + + ```bash + kubectl get secrets -n demo mycluster-conn-credential -o jsonpath='{.data.\username}' | base64 -d + > + root + ``` + + - 您可使用实际的集群名称替换命令中的 "mycluster"。 + - 您可使用实际的命名空间名称替换命令中的 "demo"。 + +2. 获取 `password`。 + + ```bash + kubectl get secrets -n demo mycluster-conn-credential -o jsonpath='{.data.\password}' | base64 -d + > + 2gvztbvz + ``` + + - 您可使用实际的集群名称替换命令中的 "mycluster"。 + - 您可使用实际的命名空间名称替换命令中的 "demo"。 + +:::note + +大多数 KubeBlocks v0.9 Addon 中，包含连接凭据的 secret 命名格式为 `{cluster.name}-conn-credential`。但是在新版本中，部分 Addon secret 的命名可能已更改为 `{cluster.name}-{component.name}-account-{account.name}`。为确保使用正确的 secret 名称，可执行以下命令罗列命名空间中的所有 secret，并查找与数据库集群相关的项。 + +```bash +kubectl get secrets -n demo | grep mycluster +``` + +::: + +## 步骤 2. 连接集群 + +获取凭证后，您可以通过以下两种方式连接至在 K8s 集群中运行的 MySQL 数据库。 + +- 使用 `kubectl exec` 直连 Pod。 +- 使用 `kubectl port-forward` 从本地连接数据库。 + +### 方式 1. 使用 kubectl exec 直连 Pod + +在某些情况下，您可能需要直接连接到 Kubernetes Pod 内运行的 MySQL 数据库，而无需依赖外部访问。这种情况下，您可以使用 `kubectl exec` 进入 Pod，直接在集群内与 MySQL 实例进行交互，避免使用外部数据库地址。 + +1. 指定需要连接的 Pod，并执行以下命令。 + + `kubectl exec` 命令在 MySQL Pod 中创建了交互式 shell 对话，您可以直接在 Pod 环境中使用以下命令。 + + ```bash + kubectl exec -ti -n demo mycluster-mysql-0 -- bash + ``` + + - `-ti`：打开交互式终端会话（`-t` 分配一个伪 TTY，`-i` 保持会话打开）。 + - `-n demo`：指定 Pod 所在的命名空间 demo。 + - `mycluster-mysql-0`：MySQL Pod 的名称。如果名称与您的实际情况不同，请确保替换为实际的 Pod 名称。 + - `--bash`：在 Pod 内打开一个 Bash shell。如果容器中没有 Bash，也可以使用 sh。 + +2. 连接集群。 + + 进入 Pod 后，您可使用 MySQL 客户端连接到同一 Pod 或集群内运行的数据库服务。由于您已经在 Pod 内，因此无需指定外部主机或地址。 + + ```bash + mysql -u root -p2gvztbvz + ``` + +### 方式 2. 使用 kubectl port-forward 连接 + +在 Kubernetes 集群中管理已部署的数据库时，可使用 `kubectl port-forward` 从本地安全地连接到数据库。该命令将本地端口的流量转发到 Kubernetes 集群中的端口，您可以像在本地运行数据库服务一样访问数据库集群。 + +以下为在本地使用 CLI 工具连接集群的示例。 + +1. 使用 `kubectl port-forward` 转发端口。 + + 首先，您需要从本地将端口转发至在 K8s 中运行的 MySQL 服务。如下命令将您本地的 3306 端口转发至集群中 MySQL 服务的同一端口。 + + ```bash + kubectl port-forward svc/mycluster-mysql 3306:3306 -n demo + ``` + + - `svc/mycluster-mysql`：代指您的 K8s 集群中的 MySQL 服务。 + - `3306:3306`：将本地 3306 端口与服务的 3306 端口绑定。 + - `-n demo`：指定 MySQL 服务所在的命名空间 demo。 + +2. 从本地连接数据库。 + + 端口转发完成后，您可以使用标准的 MySQL 客户端连接至 MySQL 数据库，这一操作与通过 127.0.0.1 连接客户端的体验一致。该连接将安全地通过这一通道转发到集群内部的服务。 + + ```bash + mysql -h 127.0.0.1 -P 3306 -u root -p2gvztbvz + ``` + + + + diff --git a/i18n/zh-cn/user-docs/connect-databases/overview-on-connect-databases.md b/i18n/zh-cn/user-docs/connect-databases/overview-on-connect-databases.md index effac7b065a..5356196a6b4 100644 --- a/i18n/zh-cn/user-docs/connect-databases/overview-on-connect-databases.md +++ b/i18n/zh-cn/user-docs/connect-databases/overview-on-connect-databases.md @@ -8,15 +8,6 @@ sidebar_label: 简介 # 简介 -在部署完 KubeBlocks 并创建集群之后，数据库在 Kubernetes 上以 Pod 的形式运行。 +部署 KubeBlocks 并创建集群后，对应的数据库会在 Kubernetes 上运行，每个副本都在 Pod 中运行，InstanceSet 将管理这些 Pod。您可以通过暴露的数据库服务地址（ClusterIP、LoadBalancer 或 NodePort），使用客户端工具或 SDK 连接到数据库。详见[在生产环境中连接数据库](./connect-to-database-in-production-environment.md)。 -在 KubeBlocks 上创建数据库只需运行以下命令（本章节以创建一个 MySQL 集群为例进行演示。创建其他数据库引擎的操作是类似的，细节上的差别请参加各引擎文档）。 - - ```bash - kbcli cluster create - ``` - -你可以通过客户端界面或 `kbcli` 连接到数据库。如下图所示，首先你需要明确连接数据库的目的是什么。 -- 如果你想试用 KubeBlocks、测试数据库功能或进行低流量基准测试，请参阅[在测试环境中连接数据库](./connect-to-database-in-testing-environment.md)。 -- 如果你想在生产环境中连接数据库或进行高流量压力测试，请参阅[在生产环境中连接数据库](./connect-to-database-in-production-environment.md)。 -![overview](./../../img/create-and-connect-databases-overview.jpg) \ No newline at end of file +如果您在 Playground 或测试环境中使用 KubeBlocks 创建数据库集群，也可以使用 `kubectl port-forward` 将数据库服务地址映射到本地机器的端口。然后，您可以使用客户端工具或集成在 `kbcli` 中的通用数据库客户端连接数据库。不过，请注意这种方法仅适用于测试和调试，不应在生产环境中使用。详见[在测试环境中连接数据库](./connect-to-database-in-testing-environment.md)。 diff --git a/i18n/zh-cn/user-docs/handle-an-exception/handle-a-cluster-exception.md b/i18n/zh-cn/user-docs/handle-an-exception/handle-a-cluster-exception.md index 471fb42ef17..498e3b6756a 100644 --- a/i18n/zh-cn/user-docs/handle-an-exception/handle-a-cluster-exception.md +++ b/i18n/zh-cn/user-docs/handle-an-exception/handle-a-cluster-exception.md @@ -6,6 +6,9 @@ sidebar_position: 1 sidebar_label: 异常处理 --- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + # 异常处理 发生异常时，你可以按照以下步骤解决问题。 @@ -14,10 +17,26 @@ sidebar_label: 异常处理 1. 检查集群状态。 + + + + ```bash kbcli cluster list mycluster ``` + + + + + ```bash + kubectl describe cluster mycluster + ``` + + + + + 2. 根据状态信息进行处理。 | **状态** | **信息** | diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/_category_.yml b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/_category_.yml index ac30fb6facd..b57b8031e6c 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/_category_.yml +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/_category_.yml @@ -1,4 +1,4 @@ -position: 5 +position: 2 label: 备份恢复 collapsible: true collapsed: true diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md index 65e0516b4fd..d6d03d66190 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md @@ -24,7 +24,7 @@ BackupRepo 是备份数据的存储仓库，支持配置 OSS（阿里云对象 * [安装 kbcli](./../../../installation/install-with-kbcli/install-kbcli.md)。 * [安装 kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)。 * [安装 Helm](https://helm.sh/docs/intro/install/)。 -* [安装 KubeBlocks](./../../../installation/install-with-kbcli/install-kubeblocks-with-kbcli.md)。 +* 安装 KubeBlocks。如果未安装，可通过 [kbcli](./../../../installation/install-with-kbcli/install-kubeblocks-with-kbcli.md) 或 [Helm](./../../../installation/install-with-kbcli/install-kubeblocks-with-kbcli.md) 进行安装。 ## 安装 MinIO @@ -126,6 +126,10 @@ BackupRepo 是备份数据的存储仓库，支持配置 OSS（阿里云对象 2. 安装 KubeBlocks 时指定配置文件。 + + + + ```bash kbcli kubeblocks install -f backuprepo.yaml ``` @@ -136,10 +140,32 @@ BackupRepo 是备份数据的存储仓库，支持配置 OSS（阿里云对象 kbcli backuprepo list ``` + + + + + ```bash + kubectl create -f backuprepo.yaml + ``` + + 安装完成后，可以执行命令查看 BackupRepo。 + + ```bash + kubectl get backuprepo + ``` + + + + + ### 手动配置 BackupRepo 如果在安装 KubeBlocks 时没有配置 BackupRepo 信息，你可以按照以下说明进行手动配置。 + + + + 1. 安装 S3 CSI driver （仅访问方式为 “Mount” 时需要安装）。 ```bash @@ -297,3 +323,244 @@ BackupRepo 是备份数据的存储仓库，支持配置 OSS（阿里云对象 ```bash kbcli backuprepo list ``` + + + + + +1. 安装 S3 CSI driver （仅访问方式为 “Mount” 时需要安装）。 + + ```bash + helm repo add kubeblocks https://jihulab.com/api/v4/projects/85949/packages/helm/stable + helm install csi-s3 kubeblocks/csi-s3 --version=0.7.0 -n kb-system + + # You can add flags to customize the installation of this addon + # CSI-S3 installs a daemonSet Pod on all nodes by default and you can set tolerations to install it on the specified node + --set-json tolerations='[{"key":"taintkey","operator":"Equal","effect":"NoSchedule","value":"taintValue"}]' + --set-json daemonsetTolerations='[{"key":"taintkey","operator":"Equal","effect":"NoSchedule","value":"taintValue"}]' + ``` + +2. 创建 BackupRepo。 + + + + + + ```bash + # 创建密码，用于存储 S3 连接密钥 + kubectl create secret generic s3-credential-for-backuprepo \ + -n kb-system \ + --from-literal=accessKeyId= \ + --from-literal=secretAccessKey= + + # 创建 BackupRepo 资源 + kubectl apply -f - <<-'EOF' + apiVersion: dataprotection.kubeblocks.io/v1alpha1 + kind: BackupRepo + metadata: + name: my-repo + annotations: + dataprotection.kubeblocks.io/is-default-repo: "true" + spec: + storageProviderRef: s3 + accessMethod: Tool + pvReclaimPolicy: Retain + volumeCapacity: 100Gi + config: + bucket: test-kb-backup + endpoint: "" + mountOptions: --memory-limit 1000 --dir-mode 0777 --file-mode 0666 + region: cn-northwest-1 + credential: + name: s3-credential-for-backuprepo + namespace: kb-system + EOF + ``` + + + + + + ```bash + # 创建密码，用于存储 OSS 连接密钥 + kubectl create secret generic oss-credential-for-backuprepo \ + -n kb-system \ + --from-literal=accessKeyId= \ + --from-literal=secretAccessKey= + + # 创建 BackupRepo 资源 + kubectl apply -f - <<-'EOF' + apiVersion: dataprotection.kubeblocks.io/v1alpha1 + kind: BackupRepo + metadata: + name: my-repo + annotations: + dataprotection.kubeblocks.io/is-default-repo: "true" + spec: + storageProviderRef: oss + accessMethod: Tool + pvReclaimPolicy: Retain + volumeCapacity: 100Gi + config: + bucket: test-kb-backup + mountOptions: "" + endpoint: "" + region: cn-zhangjiakou + credential: + name: oss-credential-for-backuprepo + namespace: kb-system + EOF + ``` + + + + + + ```bash + # 创建密码，用于存储 OBS 连接密钥 + kubectl create secret generic obs-credential-for-backuprepo \ + -n kb-system \ + --from-literal=accessKeyId= \ + --from-literal=secretAccessKey= + + # 创建 BackupRepo 资源 + kubectl apply -f - <<-'EOF' + apiVersion: dataprotection.kubeblocks.io/v1alpha1 + kind: BackupRepo + metadata: + name: my-repo + annotations: + dataprotection.kubeblocks.io/is-default-repo: "true" + spec: + storageProviderRef: obs + accessMethod: Tool + pvReclaimPolicy: Retain + volumeCapacity: 100Gi + config: + bucket: test-kb-backup + mountOptions: "" + endpoint: "" + region: cn-north-4 + credential: + name: obs-credential-for-backuprepo + namespace: kb-system + EOF + ``` + + + + + + ```bash + # 创建密码，用于存储 COS 连接密钥 + kubectl create secret generic cos-credential-for-backuprepo \ + -n kb-system \ + --from-literal=accessKeyId= \ + --from-literal=secretAccessKey= + + # 创建 BackupRepo 资源 + kubectl apply -f - <<-'EOF' + apiVersion: dataprotection.kubeblocks.io/v1alpha1 + kind: BackupRepo + metadata: + name: my-repo + annotations: + dataprotection.kubeblocks.io/is-default-repo: "true" + spec: + storageProviderRef: cos + accessMethod: Tool + pvReclaimPolicy: Retain + volumeCapacity: 100Gi + config: + bucket: test-kb-backup + mountOptions: "" + endpoint: "" + region: ap-guangzhou + credential: + name: cos-credential-for-backuprepo + namespace: kb-system + EOF + ``` + + + + + + ```bash + # 创建密码，用于存储 GCS 连接密钥 + kubectl create secret generic gcs-credential-for-backuprepo \ + -n kb-system \ + --from-literal=accessKeyId= \ + --from-literal=secretAccessKey= + + # 创建 BackupRepo 资源 + kubectl apply -f - <<-'EOF' + apiVersion: dataprotection.kubeblocks.io/v1alpha1 + kind: BackupRepo + metadata: + name: my-repo + annotations: + dataprotection.kubeblocks.io/is-default-repo: "true" + spec: + storageProviderRef: gcs + accessMethod: Tool + pvReclaimPolicy: Retain + volumeCapacity: 100Gi + config: + bucket: test-kb-backup + mountOptions: "" + endpoint: "" + region: auto + credential: + name: gcs-credential-for-backuprepo + namespace: kb-system + EOF + ``` + + + + + + ```bash + # 创建密码，用于存储 MinIO 连接密钥 + kubectl create secret generic minio-credential-for-backuprepo \ + -n kb-system \ + --from-literal=accessKeyId= \ + --from-literal=secretAccessKey= + + # 创建 BackupRepo 资源 + kubectl apply -f - <<-'EOF' + apiVersion: dataprotection.kubeblocks.io/v1alpha1 + kind: BackupRepo + metadata: + name: my-repo + annotations: + dataprotection.kubeblocks.io/is-default-repo: "true" + spec: + storageProviderRef: minio + accessMethod: Tool + pvReclaimPolicy: Retain + volumeCapacity: 100Gi + config: + bucket: test-kb-backup + mountOptions: "" + endpoint: + credential: + name: minio-credential-for-backuprepo + namespace: kb-system + EOF + ``` + + + + + +3. 查看 BackupRepo 及其状态。 如果 STATUS 为 `Ready`，说明 BackupRepo 已经准备就绪。 + + ```bash + kubectl get backuprepo + ``` + + + + diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/configure-backup-policy.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/configure-backup-policy.md index 1d1f66eb89b..c46cd76d00c 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/configure-backup-policy.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/configure-backup-policy.md @@ -15,7 +15,7 @@ import TabItem from '@theme/TabItem'; 为了确保恢复的集群能够正常访问，KubeBlocks 在备份集群时会将集群的连接密码加密，并将其安全地存储在 Backup 对象的 Annotation 中。因此，为了保障您的数据安全，强烈建议谨慎分配备份对象的 Get/List 权限，并在安装或升级 KubeBlocks 时，务必指定加密密钥。这些措施将有助于确保你的数据得到妥善保护。 -KubeBlocks v0.9.0 版本集成了 datasafed 的数据加密功能，目前已支持 AES-128-CFB、AES-192-CFB 和 AES-256-CFB 等加密算法。在写入存储之前，备份数据会被加密。您的加密密钥不仅可以用于加密连接密码，还可以备份数据。用户可以根据实际需要，直接引用已有的 secret 对象，或给数据库集群创建不同的密钥，从而进行备份加密。 +KubeBlocks v0.9.0 版本集成了 datasafed 的数据加密功能，目前已支持 `AES-128-CFB`、`AES-192-CFB` 和 `AES-256-CFB` 等加密算法。在写入存储之前，备份数据会被加密。您的加密密钥不仅可以用于加密连接密码，还可以备份数据。用户可以根据实际需要，直接引用已有的 secret 对象，或给数据库集群创建不同的密钥，从而进行备份加密。 ### 引用已有的 key @@ -30,11 +30,31 @@ kubectl create secret generic dp-encryption-key \ 您可以在安装或升级 KubeBlocks 时引用该密钥。 + + + + +```bash +kbcli kubeblocks install \ + --set dataProtection.encryptionKeySecretKeyRef.name="dp-encryption-key" \ + --set dataProtection.encryptionKeySecretKeyRef.key="encryptionKey" +# The above command is equivalent to: +# kbcli kubeblocks install --set dataProtection.encryptionKey='S!B\*d$zDsb=' +``` + + + + + ```bash helm install kubeblocks kubeblocks/kubeblocks --namespace kb-system --create-namespace --set dataProtection.encryptionKeySecretKeyRef.name="dp-encryption-key" \ --set dataProtection.encryptionKeySecretKeyRef.key="encryptionKey" ``` + + + + ### 创建新的 key 如果无需默认开启备份加密，或者需要使用独立的 encryptionKey，您可以按照以下步骤创建一个 Secret 对象，手动开启备份加密。 @@ -55,6 +75,20 @@ helm install kubeblocks kubeblocks/kubeblocks --namespace kb-system --create-nam -p '{"spec":{"encryptionConfig":{"algorithm":"AES-256-CFB","passPhraseSecretKeyRef":{"name":"backup-encryption","key":"secretKey"}}}}' ``` +:::note + +您也可以使用 `kbcli` 创建，操作更简单。 + +```bash +# 启用加密 +kbcli cluster edit-backup-policy --set encryption.algorithm=AES-256-CFB --set encryption.passPhrase="SECRET!" + +# 禁用加密 +kbcli cluster edit-backup-policy --set encryption.disabled=true +``` + +::: + 配置完成。然后就可以照常执行备份和恢复操作了。 :::warning @@ -92,6 +126,10 @@ kbcli backuprepo list 使用 KubeBlocks 创建数据库集群后，对于支持备份的数据库，会自动为其创建一个备份策略（BackupPolicy），可以执行如下命令查看集群的备份策略： + + + + ```bash kbcli cluster list-backup-policy mysql-cluster > @@ -100,8 +138,25 @@ mysql-cluster-mysql-backup-policy default true mysql-cluster mysql-cluster-mysql-backup-policy-hscale default false mysql-cluster Oct 30,2023 14:34 UTC+0800 Available ``` + + + + +kubectl get backuppolicy | grep mycluster +> +mycluster-mysql-backup-policy Available 35m +mycluster-mysql-backup-policy-hscale Available 35m + + + + + 备份策略中包含了该集群支持的备份方法，执行以下命令进行查看备份方法： + + + + ```bash kbcli cluster describe-backup-policy mysql-cluster > @@ -118,4 +173,14 @@ xtrabackup xtrabackup-for-apecloud-mysql false volume-snapshot volumesnapshot-for-apecloud-mysql true ``` + + + + +kubectl get backuppolicy mycluster-mysql-backup-policy -o yaml + + + + + 对于 MySQL 集群而言，默认支持两种备份方法：`xtrabackup` 和 `volume-snapshot`，前者使用备份工具 `xtrabackup` 将 MySQL 数据备份至对象存储中；后者则使用云存储的卷快照能力，通过快照方式对数据进行备份。创建备份时，可以指定要使用哪种备份方法进行备份。 diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/on-demand-backup.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/on-demand-backup.md index a60007f70f2..4b246b8e56e 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/on-demand-backup.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/on-demand-backup.md @@ -17,6 +17,10 @@ KubeBlocks 支持按需备份。你可以通过指定 `--method` 来自定义备 下面使用 `xtrabackup` 备份方法，创建名为 `mybackup` 的备份。 + + + + ```bash # 创建备份 kbcli cluster backup mysql-cluster --name mybackup --method xtrabackup @@ -31,10 +35,51 @@ NAME NAMESPACE SOURCE-CLUSTER METHOD STATUS TOTAL-SIZE DU mybackup default mysql-cluster xtrabackup Completed 4426858 2m8s Oct 30,2023 15:19 UTC+0800 Oct 30,2023 15:21 UTC+0800 ``` + + + + +```bash +# 创建备份 +kubectl apply -f - <<-'EOF' +apiVersion: dataprotection.kubeblocks.io/v1alpha1 +kind: Backup +metadata: + name: mybackup + namespace: default + annotations: + dataprotection.kubeblocks.io/connection-password: Bw1cR15mzfldc9hzGuK4m1BZQOzha6aBb1i9nlvoBdoE9to4 +spec: + backupMethod: xtrabackup + backupPolicyName: mysql-cluster-mysql-backup-policy +EOF + +# 查看备份 +kubectl get backup mybackup +> +NAME POLICY METHOD REPO STATUS TOTAL-SIZE DURATION CREATION-TIME COMPLETION-TIME EXPIRATION-TIME +mybackup mysql-cluster-mysql-backup-policy xtrabackup my-repo Completed 4426858 2m8s 2023-10-30T07:19:21Z 2023-10-30T07:21:28Z + +``` + +:::note + +annotations 中的 `dataprotection.kubeblocks.io/connection-password` 使用原集群的密码。 + +::: + + + + + ## 卷快照备份 使用云盘快照创建备份的方式与以上命令类似，只需将对应 YAML 中的 `backupMethod` 或者 kbcli 命令中的 `--method` 参数设置为 `volume-snapshot` 即可。 + + + + ```bash # 创建备份 kbcli cluster backup mysql-cluster --name mybackup --method volume-snapshot @@ -49,10 +94,40 @@ NAME NAMESPACE SOURCE-CLUSTER METHOD STATUS TOTAL-SIZE mybackup default mysql-cluster volume-snapshot Completed 4426858 2m8s Oct 30,2023 15:19 UTC+0800 Oct 30,2023 15:21 UTC+0800 ``` + + + + +将对应 YAML 中的 `backupMethod` 参数设置为 `volume-snapshot`。 + +```bash +# 创建备份 +kubectl apply -f - <<-'EOF' +apiVersion: dataprotection.kubeblocks.io/v1alpha1 +kind: Backup +metadata: + name: mybackup + namespace: default +spec: + backupMethod: volume-snapshot + backupPolicyName: mycluster-mysql-backup-policy +EOF + +# 查看备份 +kubectl get backup mybackup +> +NAME POLICY METHOD REPO STATUS TOTAL-SIZE DURATION CREATION-TIME COMPLETION-TIME EXPIRATION-TIME +mybackup mycluster-mysql-backup-policy volume-snapshot my-repo Completed 4426858 2m8s 2023-10-30T07:19:21Z 2023-10-30T07:21:28Z +``` + + + + + :::warning 1. 使用云盘快照创建备份时，请确保使用的存储支持快照功能，否则会导致备份失败。 -2. 通过 kbcli 手动创建的备份，不会自动删除，需要用户手动删除。 +2. 通过 `kbcli` 手动创建的备份，不会自动删除，需要用户手动删除。 ::: diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/scheduled-backup.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/scheduled-backup.md index 937584ae5bd..956d5222840 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/scheduled-backup.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/scheduled-backup.md @@ -13,6 +13,10 @@ import TabItem from '@theme/TabItem'; KubeBlocks 支持为集群配置自动备份。 + + + + ```bash kbcli cluster update mysql-cluster --backup-enabled=true \ --backup-method=xtrabackup --backup-repo-name=my-repo \ @@ -25,6 +29,47 @@ kbcli cluster update mysql-cluster --backup-enabled=true \ - `--backup-retention-period` 指定备份保留时长。以上示例中为 7 天。 - `--backup-cron-expression` 指定自动备份的备份周期。表达式格式与 linux 系统中的定时任务保持一致，时区为 UTC，参考 [Cron](https://en.wikipedia.org/wiki/Cron)。 + + + + +用 kubectl 命令修改 Cluster 中的 backup 字段，命令如下： + +```bash +kubectl edit cluster -n default mycluster +> +spec: + ... + backup: + # 开启自动备份 + enabled: true + # UTC 时区, 下面示例是每周一凌晨 2 点 + cronExpression: 0 18 * * * + # 使用 xtrabackup 进行备份，如果存储支持快照，可以指定为 volume-snapshot + method: xtrabackup + # 是否开启 PITR + pitrEnabled: false + # 备份集保留时长 + retentionPeriod: 7d + # BackupRepo + repoName: my-repo +``` + +您可在以上 YAML 文件中按需设置是否开启自动备份和 PITR，也可以指定备份方式、仓库名称、保留时长等。 + + + + + +开启自动备份后，可以执行如下命令查看是否有 CronJob 对象被创建： + +```bash +kubectl get cronjob +> +NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE +96523399-mycluster-default-xtrabackup 0 18 * * * False 0 57m +``` + 也可以执行如下命令，查看集群信息，其中 `Data Protection:` 部分会显示自动备份的配置信息。 ```bash diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/pitr.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/pitr.md index 5e17041dc74..157205b816d 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/pitr.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/pitr.md @@ -2,10 +2,13 @@ title: PITR description: PITR keywords: [备份恢复, 恢复, PITR, 按时间点恢复] -sidebar_position: 1 +sidebar_position: 2 sidebar_label: PITR --- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + # PITR ### PITR 是什么？ @@ -18,6 +21,10 @@ KubeBlocks 已支持对 MySQL 和 PostgreSQL 等数据库的 PITR 功能。 1. 查看可以将集群恢复到的时间戳。 + + + + ```bash kbcli cluster describe pg-cluster ... @@ -26,23 +33,86 @@ KubeBlocks 已支持对 MySQL 和 PostgreSQL 等数据库的 PITR 功能。 minio Enabled */5 * * * * archive-wal 8d May 07,2024 15:29:46 UTC+0800 ~ May 07,2024 15:48:47 UTC+080 ``` -`RECOVERABLE-TIME` 表示可以将恢复集群到的时间范围。 + + + + + ```bash + # 1. Get all backup objects for the current cluster + kubectl get backup -l app.kubernetes.io/instance=pg-cluster + + # 2. Get the backup time range for Continuous Backup + kubectl get backup -l app.kubernetes.io/instance=pg-cluster -l dataprotection.kubeblocks.io/backup-type=Continuous -o yaml + ... + status: + timeRange: + end: "2024-05-07T10:47:14Z" + start: "2024-05-07T10:07:45Z" + ``` -可以看到当前持续日志备份的时间范围是 `May 07,2024 15:29:46 UTC+0800 ~ May 07,2024 15:48:47 UTC+0800`。但是还得需要一个基础全量备份才能恢复数据，并且这个全部备份完成时间需要落在日志备份的时间范围内才是有效的基础备份。 + + + + + `RECOVERABLE-TIME` 表示可以将恢复集群到的时间范围。 + + 可以看到当前持续日志备份的时间范围是 `May 07,2024 15:29:46 UTC+0800 ~ May 07,2024 15:48:47 UTC+0800`。但是还得需要一个基础全量备份才能恢复数据，并且这个全部备份完成时间需要落在日志备份的时间范围内才是有效的基础备份。 2. 将集群恢复到指定的时间点。 + + + + ```bash kbcli cluster restore pg-cluster-pitr --restore-to-time 'May 07,2024 15:48:47 UTC+080' --backup ``` + + + + + ```bash + apiVersion: apps.kubeblocks.io/v1alpha1 + kind: OpsRequest + metadata: + name: pg-cluster-pitr + spec: + clusterName: pg-cluster-pitr + restore: + backupName: 818aa0e0-pg-kubeblocks-cloud-n-archive-wal + restorePointInTime: "2024-05-07T10:07:45Z" + volumeRestorePolicy: Parallel + type: Restore + ``` + + + + + 3. 查看新集群的状态。 集群状态为 `Running` 时，表示恢复成功。 + + + + ```bash kbcli cluster list pg-cluster-pitr > NAME NAMESPACE CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS CREATED-TIME pg-cluster-pitr default apecloud-mysql ac-mysql-8.0.30 Delete Running Jul 25,2023 19:42 UTC+0800 ``` + + + + + + ```bash + kubectl get cluster pg-cluster-pitr + ``` + + + + diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/restore-data-from-backup-set.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/restore-data-from-backup-set.md index 669e3af5fd9..7fe18aaf51a 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/restore-data-from-backup-set.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/restore-data-from-backup-set.md @@ -15,20 +15,40 @@ KubeBlocks 支持从备份集中恢复数据。 1. 查看备份。 - 对已有的集群，执行： + - ```shell - kbcli cluster list-backups mysql-cluster - ``` + - 如果集群已经被删除，执行： + 对已有的集群，执行： - ```bash - kbcli dataprotection list-backups - ``` + ```shell + kbcli cluster list-backups mysql-cluster + ``` + + 如果集群已经被删除，执行： + + ```bash + kbcli dataprotection list-backups + ``` + + + + + + ```bash + kubectl get backups + ``` + + + + 2. 从特定的备份中恢复集群。 + + + + ```bash # 恢复集群 kbcli cluster restore myrestore --backup mybackup @@ -41,10 +61,44 @@ KubeBlocks 支持从备份集中恢复数据。 myrestore default apecloud-mysql ac-mysql-8.0.30 Delete Running Oct 30,2023 16:26 UTC+0800 ``` -3. 连接被恢复集群，进行验证。 + + + - 当集群状态为 `Running` 后，执行以下命令连接到集群并进行验证： + 可使用原集群的 connection password 作为恢复的集群的 `connectionPassword.annotations` 值。可从备份 YAML 文件中的 `dataprotection.kubeblocks.io/connection-password` annotation 中获取原集群的 connection password。 ```bash - kbcli cluster connect myrestore + kubectl apply -f - <<-'EOF' + apiVersion: apps.kubeblocks.io/v1alpha1 + kind: Cluster + metadata: + name: myrestore + namespace: default + annotations: + kubeblocks.io/restore-from-backup: '{"mysql":{"name":"mybackup","namespace":"default","connectionPassword": "Bw1cR15mzfldc9hzGuK4m1BZQOzha6aBb1i9nlvoBdoE9to4"}}' + spec: + clusterDefinitionRef: apecloud-mysql + clusterVersionRef: ac-mysql-8.0.30 + terminationPolicy: WipeOut + componentSpecs: + - name: mysql + componentDefRef: mysql + replicas: 1 + volumeClaimTemplates: + - name: data + spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 20Gi + EOF ``` + + + + + +3. 连接被恢复集群，进行验证。 + + 当集群状态为 `Running` 后，[连接集群](./../../../kubeblocks-for-apecloud-mysql/cluster-management/create-and-connect-a-mysql-cluster.md#连接集群)进行验证。 diff --git a/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/_category_.yaml b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/_category_.yaml new file mode 100644 index 00000000000..4d27cb3ecc0 --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/_category_.yaml @@ -0,0 +1,4 @@ +position: 5 +label: 多 k8s 部署 +collapsible: true +collapsed: true \ No newline at end of file diff --git a/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md new file mode 100644 index 00000000000..7320387b964 --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md @@ -0,0 +1,346 @@ +--- +title: 多 k8s 部署 +description: 如何使用 KubeBlocks 实现多 k8s 部署 +keywords: [cross k8s deployment] +sidebar_position: 1 +sidebar_label: 使用 KubeBlocks 实现多 k8s 部署 +--- + +# 使用 KubeBlocks 实现多 k8s 部署 + +KubeBlocks 支持管理多个 Kubernetes 集群，为用户在实例容灾、k8s 集群管理等方面提供新的选项。为支持多 K8s 管理，KubeBlocks 引入了 control plane 和 data plane。 + +* Control plane：一个独立的 k8s 集群，KubeBlocks operator 运行在该集群当中，KubeBlocks 定义的相关对象大都存放在这个集群（比如 definition、cluster、backup、ops 等）。用户通过跟这个集群的 API 进行交互来实现对多集群实例的管理。 +* Data plane：用于运行最终 workload 的 k8s 集群，数量可以是一到多个。这些集群当中会 hosting 实例相关的计算、存储、网络等资源，如 pod、pvc、service、sa、cm、secret、jobs 等，而 KubeBlocks operator 目前（v0.9.0）不会运行在当中。 + +实际物理部署上，control plane 可以选择部署在单个 AZ，简单灵活；也可以选择部署在多个不同 AZ，提供更高的可用性保证；也可以复用某个 data plane 集群，以更低成本的方式运行。 + +## 环境准备 + +准备 K8s 集群，并准备部署 KubeBlocks 所需的配置信息。本文示例准备了三个 data plane 集群，context 分别命名为：k8s-1、k8s-2、k8s-3。 + +* 准备 K8s 集群：1 个设定为 control plane，其他几个设定为 data plane，确保这些 data plane 集群的 API server 在 control plane 集群中可以联通。这里的联通包含两个层面：一是网络连通，二是访问配置。 +* 准备 KubeBlocks operator 访问 data plane 所需的配置信息，以 secret 形式放置在 control plane 集群当中，部署 KubeBlocks operator 时需要传入。其中，secret key 要求为 “kubeconfig”，value 为标准 kubeconfig 内容格式。示例如下： + + ```bash + apiVersion: v1 + kind: Secret + metadata: + namespace: kb-system + name: + type: kubernetes.kubeconfig + stringData: + kubeconfig: | + apiVersion: v1 + clusters: + ... + contexts: + ... + kind: Config + users: + ... + ``` + +## 部署多 K8s 集群 + +### 部署 Kubeblocks operator + +在 control plane 安装 KubeBlocks。 + +1. 安装 KubeBlocks. + + ```bash + # multiCluster.kubeConfig 指定存放 data plane k8s kubeconfig 信息的 secret + # multiCluster.contexts 指定 data plane K8s contexts + kbcli kubeblocks install --version=0.9.0 --set multiCluster.kubeConfig= --set multiCluster.contexts= + ``` + +2. 查看安装状态，确保 KubeBlocks 安装完成。 + + ```bash + kbcli kubeblocks status + ``` + +### RBAC + +实例 workload 在 data plane 中运行时，需要特定的 RBAC 资源进行管理动作，因此需要预先在各 data plane 集群单独安装 KubeBlocks 所需的 RBAC 资源。 + +```bash +# 1. 从 control plane dump 所需的 clusterrole 资源：kubeblocks-cluster-pod-role +kubectl get clusterrole kubeblocks-cluster-pod-role -o yaml > /tmp/kubeblocks-cluster-pod-role.yaml + +# 2. 编辑文件内容，去除不必要的 meta 信息（比如 UID、resource version），保留其他内容 + +# 3. Apply 文件内容到其他 data plane 集群 +kubectl apply -f /tmp/kubeblocks-cluster-pod-role.yaml --context=k8s-1 +kubectl apply -f /tmp/kubeblocks-cluster-pod-role.yaml --context=k8s-2 +kubectl apply -f /tmp/kubeblocks-cluster-pod-role.yaml --context=k8s-3 +``` + +### 网络 + +KubeBlocks 基于 K8s service 抽象来提供内外部的服务访问。对于 service 的抽象，集群内的访问 K8s 一般会有默认的实现，对于来自集群外的流量通常需要用户自己提供方案。而在多 K8s 形态下，无论是实例间的复制流量、还是客户端的访问流量，基本都属于“集群外流量”。因此为了让跨集群实例能够正常工作，网络部分一般需要进行一些额外的处理。 + +这里会以一组可选的方案为例，用来完整描述整个流程。实际使用中，用户可以根据自身集群和网络环境，选择适合的方案进行部署。 + +#### 东西向流量 + +##### 云上方案 + +云厂商提供的 K8s 服务一般都提供了内/外网 load balancer service 可供使用，这样可以直接基于 LB service 来构建副本之间的互访，简单易用。 + +##### 自建方案 + +东西向互访的自建方案以 Cillium Cluster Mesh 为例来进行说明，Cillium 的部署选择 overlay 模式，各 data plane 集群配置如下： + +| Cluster | Context | Name | ID | CIDR | +|:-------:|:-------:|:-----:|:--:|:-----------:| +| 1 | k8s-1 | k8s-1 | 1 | 10.1.0.0/16 | +| 2 | k8s-2 | k8s-2 | 2 | 10.2.0.0/16 | +| 3 | k8s-3 | k8s-3 | 3 | 10.3.0.0/16 | + +:::note + +这里的 CIDR 是 Cilium Overlay 网络的地址，具体设置时要跟主机网络地址段区分开。 + +::: + +***步骤：*** + +下述操作步骤相关命令，可以在各个集群分别执行（不需要指定 `--context` 参数），也可以在有三个 context 信息的环境里统一执行（分别指定 `--context` 参数）。 + +1. 安装 cilium，指定 cluster ID/name 和 cluster pool pod CIDR。可参考官方文档：[Specify the Cluster Name and ID](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#specify-the-cluster-name-and-id)。 + + ```bash + cilium install --set cluster.name=k8s-1 --set cluster.id=1 --set ipam.operator.clusterPoolIPv4PodCIDRList=10.1.0.0/16 —context k8s-1 + cilium install --set cluster.name=k8s-2 --set cluster.id=2 --set ipam.operator.clusterPoolIPv4PodCIDRList=10.2.0.0/16 —context k8s-2 + cilium install --set cluster.name=k8s-3 --set cluster.id=3 --set ipam.operator.clusterPoolIPv4PodCIDRList=10.3.0.0/16 —context k8s-3 + ``` + +2. 开启 Cilium Cluster Mesh，并等待其状态为 ready。这里以 NodePort 方式提供对 cluster mesh control plane 的访问，其他可选方式及具体信息请参考官方文档：[Enable Cluster Mesh](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#enable-cluster-mesh)。 + + ```bash + cilium clustermesh enable --service-type NodePort —context k8s-1 + cilium clustermesh enable --service-type NodePort —context k8s-2 + cilium clustermesh enable --service-type NodePort —context k8s-3 + cilium clustermesh status —wait —context k8s-1 + cilium clustermesh status —wait —context k8s-2 + cilium clustermesh status —wait —context k8s-3 + ``` + +3. 打通各集群，并等待集群状态为 ready。具体可参考官方文档：[Connect Clusters](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#connect-clusters)。 + + ```bash + cilium clustermesh connect --context k8s-1 --destination-context k8s-2 + cilium clustermesh connect --context k8s-1 --destination-context k8s-3 + cilium clustermesh connect --context k8s-2 --destination-context k8s-3 + cilium clustermesh status —wait —context k8s-1 + cilium clustermesh status —wait —context k8s-2 + cilium clustermesh status —wait —context k8s-3 + ``` + +4. （可选）可以通过 cilium-dbg 工具检查跨集群的 tunnel 情况。具体可参考官方文档：[cilium dbg](https://docs.cilium.io/en/stable/cmdref/cilium-dbg/)。 + + ```bash + cilium-dbg bpf tunnel list + ``` + +5. （可选）集群连通性测试，可参考官方文档：[Test Pod Connectivity Between Clusters](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#test-pod-connectivity-between-clusters)。 + +#### 南北向流量 + +南北向流量为客户端提供服务，需要每个 data plane 的 Pod 都有对外的连接地址，这个地址的实现可以是 NodePort、LoadBalancer 或者其他方案，我们以 NodePort 和 LoadBalancer 为例介绍。 + +如果客户端不具备读写路由能力，那在 Pod 地址之上，还需要提供读写分离地址，实现上可以用七层的 Proxy，四层的 SDN VIP，或者纯粹的 DNS。为了简化问题，此处先假设客户端具备读写路由能力，可以直接配置所有 Pod 连接地址。 + +##### NodePort + +为每个 data plane 集群的 Pod 创建 NodePort Service，客户端使用用主机网络 IP 和 NodePort 即可连接。 + +##### LoadBalancer + +此处以 MetalLB 提供 LoadBalancer Service 为例。 + +1. 准备 data plane 的 LB 网段，该网段需要跟客户端路由可达，并且不同 K8s 集群要错开 + + | Cluster | Context | Name | ID | CIDR | + |:-------:|:-------:|:-----:|:--:|:-----------:| + | 1 | k8s-1 | k8s-1 | 1 | 10.4.0.0/16 | + | 2 | k8s-2 | k8s-2 | 2 | 10.5.0.0/16 | + | 3 | k8s-3 | k8s-3 | 3 | 10.6.0.0/16 | + +2. 在所有 data plane 部署 MetalLB。 + + ```bash + helm repo add metallb https://metallb.github.io/metallb + helm install metallb metallb/metallb + ``` + +3. 等待相关 Pod 状态变为 ready。 + + ```bash + kubectl wait --namespace metallb-system --for=condition=ready pod --selector=app=metallb --timeout=90s + ``` + +4. 在三个 K8s 集群执行以下 YAML 文件，请注意替换 `spec.addresses` 为对应 K8s 集群的 LB 网段。 + + ```yaml + apiVersion: metallb.io/v1beta1 + kind: IPAddressPool + metadata: + name: example + namespace: metallb-system + spec: + addresses: + - x.x.x.x/x + --- + apiVersion: metallb.io/v1beta1 + kind: L2Advertisement + metadata: + name: empty + namespace: metallb-system + ``` + +5. 为每个data plane 集群的 Pod 创建 LoadBalancer Service，拿到所有 VIP，即可供客户端连接。 + +## 验证 + +多集群实例的运行，各个副本之间的访问地址不能直接简单使用原 domain 内的地址（比如 Pod FQDN），需要显式的创建并配置使用跨集群的服务地址来进行通信，因此需要对引擎进行适配。 + +这里以社区版 etcd 为例来进行演示，相关适配的结果可以参考 [etcd 引擎](https://github.com/apecloud/kubeblocks-addons/blob/release-0.9/addons/etcd/templates/componentdefinition.yaml)。 + +### 创建实例 + +由于不同网络要求的配置不同，这里分别以云上和自建两种方式为例说明如果创建一个三副本的跨集群 etcd 实例。 + +#### 云上方案 + +这里以阿里云为例，其他厂商的配置可以参考官方文档。 + +```yaml +apiVersion: apps.kubeblocks.io/v1alpha1 +kind: Cluster +metadata: + namespace: default + generateName: etcd + annotations: + # 可选：可以用该 annotation 显式指定当前实例要求分布的集群 + apps.kubeblocks.io/multi-cluster-placement: "k8s-1,k8s-2,k8s-3" +spec: + terminationPolicy: WipeOut + componentSpecs: + - componentDef: etcd-0.9.0 + name: etcd + replicas: 3 + resources: + limits: + cpu: 100m + memory: 100M + requests: + cpu: 100m + memory: 100M + volumeClaimTemplates: + - name: data + spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 20Gi # 云上 provisioning 要求的最小 size + - name: peer + serviceType: LoadBalancer + annotations: + # 如果运行在基于 LoadBalancer service 提供的互访方案上，这个 annotation key 为必填项 + apps.kubeblocks.io/multi-cluster-service-placement: unique + # ACK LoadBalancer service 要求的 annotation key + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet + podService: true +``` + +如下示例展示了如何跨云厂商部署。 + +```yaml +apiVersion: apps.kubeblocks.io/v1alpha1 +kind: Cluster +metadata: + namespace: default + generateName: etcd + annotations: + # 可选：可以用该 annotation 显式指定当前实例要求分布的集群 + apps.kubeblocks.io/multi-cluster-placement: "k8s-1,k8s-2,k8s-3" +spec: + terminationPolicy: WipeOut + componentSpecs: + - componentDef: etcd-0.9.0 + name: etcd + replicas: 3 + resources: + limits: + cpu: 100m + memory: 100M + requests: + cpu: 100m + memory: 100M + volumeClaimTemplates: + - name: data + spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 20Gi # 云上 provisioning 要求的最小 size + services: + - name: peer + serviceType: LoadBalancer + annotations: + # 如果运行在基于 LoadBalancer service 提供的互访方案上，这个 annotation key 为必填项 + apps.kubeblocks.io/multi-cluster-service-placement: unique + # ACK LoadBalancer service 要求的 annotation key。因为要跨云访问，因此需要配置为公网类型 + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet + # VKE LoadBalancer service 要求的 annotation keys。因为要跨云访问，因此需要配置为公网类型 + service.beta.kubernetes.io/volcengine-loadbalancer-subnet-id: + service.beta.kubernetes.io/volcengine-loadbalancer-address-type: "PUBLIC" + podService: true +``` + +#### 自建方案 + +该示例展示了如何在自建环境创建实例。 + +```yaml +apiVersion: apps.kubeblocks.io/v1alpha1 +kind: Cluster +metadata: + namespace: default + generateName: etcd + annotations: + # 可选：可以用该 annotation 显式指定当前实例要求分布的集群 + apps.kubeblocks.io/multi-cluster-placement: "k8s-1,k8s-2,k8s-3" +spec: + terminationPolicy: WipeOut + componentSpecs: + - componentDef: etcd-0.9.0 + name: etcd + replicas: 3 + resources: + limits: + cpu: 100m + memory: 100M + requests: + cpu: 100m + memory: 100M + volumeClaimTemplates: + - name: data + spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + services: + - name: peer + serviceType: ClusterIP + annotations: + service.cilium.io/global: "true" # cilium clustermesh global service + podService: true +``` diff --git a/i18n/zh-cn/user-docs/maintenance/in-place-update/_category_.yaml b/i18n/zh-cn/user-docs/maintenance/in-place-update/_category_.yaml new file mode 100644 index 00000000000..fe179cec82a --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/in-place-update/_category_.yaml @@ -0,0 +1,4 @@ +position: 3 +label: 原地更新 +collapsible: true +collapsed: true \ No newline at end of file diff --git a/i18n/zh-cn/user-docs/maintenance/in-place-update/ignore-vertical-scale.md b/i18n/zh-cn/user-docs/maintenance/in-place-update/ignore-vertical-scale.md new file mode 100644 index 00000000000..2c8237e8484 --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/in-place-update/ignore-vertical-scale.md @@ -0,0 +1,13 @@ +--- +title: 启用原地更新 +description: 如何启用原地更新 +keywords: [原地更新] +sidebar_position: 2 +sidebar_label: 启用原地更新 +--- + +# 启用原地更新 + +Resources 的原地更新一直以来有比较强的需求，在低于 1.27 版本的 Kubernetes 中，我们可以看到很多 Kubernetes 的发行版中支持了 Resources 的原地更新能力，不同的发行版可能采用了不同的方案去实现这一特性。 + +为了兼容这些 Kubernetes 发行版，KubeBlocks 中增加了 `IgnorePodVerticalScaling` 特性开关。当该特性打开后，KubeBlocks 在做实例更新时，会忽略 Resources 中 CPU 和 Memory 的更新，从而使得最终渲染的 Pod 的 Resources 跟当前在运行 Pod 的 Resources 配置保持一致。\ diff --git a/i18n/zh-cn/user-docs/maintenance/in-place-update/overview.md b/i18n/zh-cn/user-docs/maintenance/in-place-update/overview.md new file mode 100644 index 00000000000..ee22bee3ade --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/in-place-update/overview.md @@ -0,0 +1,55 @@ +--- +title: 概述 +description: 原地更新概述 +keywords: [原地更新, 概述] +sidebar_position: 1 +sidebar_label: 概述 +--- + +# 概述 + +早期的版本中，KubeBlocks 最终生成的 Workload 是 StatefulSet。StatefulSet 通过 PodTemplate 渲染最终的 Pod，当 PodTemplate 中有任何字段发生了改变，都会导致所有 Pod 被更新，而 StatefulSet 采用的更新方式是 `Recreate`，即首先删除现有的 Pod，然后再新建一个 Pod。对于数据库等对可用性要求很高的系统，这样的方式显然不是最佳选择。 + +为了解决这个问题，KubeBlocks 从 v0.9 开始，新增实例原地更新特性，降低实例更新时对系统可用性的影响。 + +## 实例（Instance）哪些字段支持原地更新 + +从原理上来讲，KubeBlocks 实例原地更新复用了 [Kubernetes Pod API 原地更新能力](https://kubernetes.io/docs/concepts/workloads/pods/#pod-update-and-replacement)。所以具体支持的字段如下： + +* `annotations` +* `labels` +* `spec.activeDeadlineSeconds` +* `spec.initContainers[*].image` +* `spec.containers[*].image` +* `spec.tolerations (only supports adding Toleration)` + +Kubernetes 从 1.27 版本开始，通过 `InPlacePodVerticalScaling` 特性开关可进一步开启对 CPU 和 Memory 的原地更新支持。KubeBlocks 同样增加了 `InPlacePodVerticalScaling` 特性开关，以便进一步支持如下能力： + +对于大于等于 1.27 且 InPlacePodVerticalScaling 已开启的 Kubernetes，支持如下字段的原地更新： + +* `spec.containers[*].resources.requests["cpu"]` +* `spec.containers[*].resources.requests["memory"]` +* `spec.containers[*].resources.limits["cpu"]` +* `spec.containers[*].resources.limits["memory"]` + +需要注意的是，当 resource resize 成功后，有的应用可能需要重启才能感知到新的资源配置，此时需要在 ClusterDefinition 或 ComponentDefinition 中进一步配置 container `restartPolicy`。 + +对于 PVC，KubeBlocks 同样复用 PVC API 的能力，仅支持 Volume 的扩容，当因为某些原因扩容失败时，支持缩容回原来的容量值。而 StatefulSet 中的 VolumeClaimTemplate 一经声明，便不能修改，目前官方正在[开发相关能力](https://github.com/kubernetes/enhancements/pull/4651)，但至少需要等到 K8s 1.32 版本了。 + +## 从上层 API 视角，哪些字段更新后使用的是原地更新 + +KubeBlocks 跟实例相关的上层 API 包括 Cluster、ClusterDefinition、ClusterVersion、ComponentDefinition 和 ComponentVersion。这些 API 中有若干字段最终会直接或间接用来渲染实例对象，从而可能会触发实例原地更新。 + +这些字段非常多，这里对这些字段进行罗列和简单描述。 + +:::note + +API 中标记为 deprecated 的字段不在列表内，immutable 的字段不在列表内。 + +::: + +| API | 字段名称 | 描述 | +|:-----|:-------|:-----------| +|Cluster| `annotations`,

`labels`,

`spec.tolerations`,

`spec.componentSpecs[*].serviceVersion`,

`spec.componentSpecs[*].tolerations`,

`spec.componentSpecs[*].resources`,

`spec.componentSpecs[*].volumeClaimTemplates`,

`spec.componentSpecs[*].instances[*].annotations`,

`spec.componentSpecs[*].instances[*].labels`,

`spec.componentSpecs[*].instances[*].image`,

`spec.componentSpecs[*].instances[*].tolerations`,

`spec.componentSpecs[*].instances[*].resources`,

`spec.componentSpecs[*].instances[*].volumeClaimTemplates`,

`spec.shardingSpecs[*].template.serviceVersion`,

`spec.shardingSpecs[*].template.tolerations`,

`spec.shardingSpecs[*].template.resources`,

`spec.shardingSpecs[*].template.volumeClaimTemplates`

| Resources 相关字段都指的是：

`requests["cpu"]`,

`requests["memory"]`,

`limits["cpu"]`,

`limits["memory"]` | +| ComponentVersion | `spec.releases[*].images` | 是否会触发实例原地更新取决于最终匹配的 Image 是否有变化。 | +| KubeBlocks Built-in | `annotations`, `labels` | | diff --git a/i18n/zh-cn/user-docs/maintenance/instance-template/_category_.yml b/i18n/zh-cn/user-docs/maintenance/instance-template/_category_.yml new file mode 100644 index 00000000000..f9bb125ecf6 --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/instance-template/_category_.yml @@ -0,0 +1,4 @@ +position: 6 +label: 实例模板 +collapsible: true +collapsed: true \ No newline at end of file diff --git a/i18n/zh-cn/user-docs/maintenance/instance-template/how-to-use-instance-template.md b/i18n/zh-cn/user-docs/maintenance/instance-template/how-to-use-instance-template.md new file mode 100644 index 00000000000..833abcb0d72 --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/instance-template/how-to-use-instance-template.md @@ -0,0 +1,218 @@ +--- +title: 应用实例模板 +description: 应用实例模板 +keywords: [应用实例模板, 实例模板] +sidebar_position: 2 +sidebar_label: 应用实例模板 +--- + +# 应用实例模板 + +实例模板可用于多种场景。本章节以 RisingWave 为实例。 + +KubeBlocks 中支持管理 RisingWave 集群，RisingWave 引擎由 RisingWave 官方贡献。RisingWave 需要一个外部存储来作为自己的存储后端（state backend），这个外部存储可以是 AWS S3、阿里云 OSS 等。RisingWave 集群在创建时需要配置外部存储的 Credential 等信息，以便能够正常工作，而这些信息对每个集群来说可能都不同。 + +在 RisingWave 的官方镜像中，这些信息可以通过环境变量（Env）方式注入，所以在 KubeBlocks v0.9 中，我们可以通过在实例模板中配置相应的环境变量，在每次创建集群时设置这些环境变量的值，以便将 Credential 等信息注入到 RisingWave 的容器中。 + +## 示例 + +在 RisingWave 引擎的默认模板中，[环境变量相关配置](https://github.com/apecloud/kubeblocks-addons/blob/main/addons/risingwave/templates/cmpd-compute.yaml#L26)如下： + +```yaml +apiVersion: apps.kubeblocks.io/v1alpha1 +kind: ComponentDefinition +metadata: + name: risingwave +# ... +spec: +#... + runtime: + containers: + - name: compute + securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - ALL + privileged: false + command: + - /risingwave/bin/risingwave + - compute-node + env: + - name: RUST_BACKTRACE + value: "1" + - name: RW_CONFIG_PATH + value: /risingwave/config/risingwave.toml + - name: RW_LISTEN_ADDR + value: 0.0.0.0:5688 + - name: RW_ADVERTISE_ADDR + value: $(KB_POD_FQDN):5688 + - name: RW_META_ADDR + value: load-balance+http://$(metaSvc)-headless:5690 + - name: RW_METRICS_LEVEL + value: "1" + - name: RW_CONNECTOR_RPC_ENDPOINT + value: $(connectorSvc):50051 + - name: RW_PROMETHEUS_LISTENER_ADDR + value: 0.0.0.0:1222 +# ... +``` + +在 [Cluster 资源](https://github.com/apecloud/kubeblocks-addons/blob/main/addons-cluster/risingwave/templates/cluster.yaml)中添加实例模板后如下： + +```yaml +apiVersion: apps.kubeblocks.io/v1alpha1 +kind: Cluster +metadata: + name: {{ include "risingwave-cluster.name" . }} + namespace: {{ .Release.Namespace }} +# ... +spec: + componentSpecs: + - componentDef: compute + name: compute + replicas: {{ .Values.risingwave.compute.replicas }} + instances: + - name: instance + replicas: {{ .Values.risingwave.compute.replicas }} + env: + - name: RW_STATE_STORE + value: "hummock+s3://{{ .Values.risingwave.stateStore.s3.bucket }}" + - name: AWS_REGION + value: "{{ .Values.risingwave.stateStore.s3.region }}" + {{- if eq .Values.risingwave.stateStore.s3.authentication.serviceAccountName "" }} + - name: AWS_ACCESS_KEY_ID + value: "{{ .Values.risingwave.stateStore.s3.authentication.accessKey }}" + - name: AWS_SECRET_ACCESS_KEY + value: "{{ .Values.risingwave.stateStore.s3.authentication.secretAccessKey }}" + {{- end }} + - name: RW_DATA_DIRECTORY + value: "{{ .Values.risingwave.stateStore.dataDirectory }}" + {{- if .Values.risingwave.stateStore.s3.endpoint }} + - name: RW_S3_ENDPOINT + value: "{{ .Values.risingwave.stateStore.s3.endpoint }}" + {{- end }} + {{- if .Values.risingwave.metaStore.etcd.authentication.enabled }} + - name: RW_ETCD_USERNAME + value: "{{ .Values.risingwave.metaStore.etcd.authentication.username }}" + - name: RW_ETCD_PASSWORD + value: "{{ .Values.risingwave.metaStore.etcd.authentication.password }}" + {{- end }} + - name: RW_ETCD_ENDPOINTS + value: "{{ .Values.risingwave.metaStore.etcd.endpoints }}" + - name: RW_ETCD_AUTH + value: "{{ .Values.risingwave.metaStore.etcd.authentication.enabled}}" +# ... +``` + +在上面的例子中，我们通过 `instances` 字段新增了一个实例模板，该实例模板的名字为 `instance`。模板中定义了 `RW_STATE_STORE`、`AWS_REGION` 等若干环境变量，这些环境变量会被 KubeBlocks append 到默认模板中定义的环境变量列表后面，最终渲染的实例中将包含默认模板和在该实例模板中定义的所有环境变量。 + +另外，实例模板中 `replicas` 与 `componentSpec` 中相同（都为 `{{ .Values.risingwave.compute.replicas }}`），意味着在覆盖默认模板后，该实例模板将用来渲染该 Component 中的所有实例。 + +## 实例模板详细说明 + +- `Name` 字段：每个 Component 中可以定义多个实例模板。每个模板都需要通过 `Name` 字段设置模板名称，同一个 Component 中的实例模板名字必须保持唯一。 +- `Replica` 字段：每个模板可以通过 `Replicas` 字段设置基于该模板渲染的实例数量，Replicas 默认为 1。同一个 Component 中的所有实例模板的 `Replicas` 相加后必须小于或等于 Component 的 `Replicas` 值。若基于实例模板渲染的实例数量小于 Component 需要的总的实例数量，剩余的实例将使用默认模板进行渲染。 + +基于实例模板渲染的实例名称的模式（Pattern）为 `$(cluster name)-$(component name)-$(instance template name)-ordinal`。比如在上文 RisingWave 示例中， Cluster 名字为 `risingwave`，Component 名字为 `compute`，实例模板名称为 `instance`，实例数量 `Replicas` 为 3。那么最终渲染出的实例名称为：`risingwave-compute-instance-0`,`risingwave-compute-instance-1`,`risingwave-compute-instance-2`。 + +实例模板在集群创建阶段可以使用，并可以在后续运维中对实例模板进行更新，具体包括添加实例模板、删除实例模板或更新实例模板。实例模板更新可能会引起实例的更新、删除或重建，在更新前建议仔细分析最终的变化是否符合预期。 + +### Annotations + +实例模板中的 `annotations` 用于覆盖默认模板中的 `annotations` 字段，若实例模板 `annotations` 中的某个 Key 在默认模板中已存在，该 Key 对应的值（Value）将使用实例模板中的值；若该 Key 在默认模板中不存在，该 Key 和 Value 将被添加到最终的 `annotations` 中。 + +***示例*** + +默认模板中 `annotations` 为： + +```yaml +annotations: + "foo0": "bar0" + "foo1": "bar" +``` + +实例模板中 `annotations` 为： + +```yaml +annotations: + "foo1": "bar1" + "foo2": "bar2" +``` + +则最终被渲染出的实例的 `annotations` 为： + +```yaml +annotations: + "foo0": "bar0" + "foo1": "bar1" + "foo2": "bar2" +``` + +:::note + +KubeBlocks 会添加一些系统 `annotations`，需要避免对这些 `annotations` 造成覆盖。 + +::: + +### Labels + +您也可以通过实例模板设置 `Labels`。 + +与 `Annotations` 类似，实例模板中的 `Labels` 采用相同的覆盖逻辑应用到已有的 `Labels` 上，并形成最终的 `Labels`。 + +:::note + +KubeBlocks 添加了系统 `Labels`，请勿覆盖这些 `Labels`。 + +::: + +### Image + +实例模板中的 `Image` 用于覆盖默认模板中第一个 Container 的 `Image` 字段。 + +:::warning + +该字段需慎用：在数据库等有状态应用中，`Image` 改变通常涉及数据格式等的兼容性，使用该字段时请确认实例模板的镜像版本与默认模板中的完全兼容。 + +::: + +同时 KubeBlocks 从 v0.9 开始，通过 `ComponentVersion` 对镜像版本进行了详细设计，建议通过 `ComponentVersion` 进行版本管理。 + +### NodeName + +该字段用于覆盖默认模板中的 `NodeName` 字段。 + +### NodeSelector + +该字段用于覆盖默认模板中的 `NodeSelector` 字段，覆盖逻辑与 `Annotations` 和 `Labels` 相同。 + +### Tolerations + +该字段用于覆盖默认模板中的 `Tolerations` 字段。 + +若实例模板中的 `Toleration` 与默认模板中的某个 `Toleration` 完全相同（`Key`、`Operator`、`Value`、`Effect` 和 `TolerationSeconds` 都相同），则该 `Toleration` 会被忽略；否则，追加到默认模板中的 `Tolerations` 列表中。 + +### RuntimeClassName + +该字段用于覆盖默认模板中的 `RuntimeClassName` 字段。 + +### Resources + +在实例模板中可以进一步覆盖 `Resources` 的值，其优先级高于 `Component`。 + +### Env + +实例模板中定义的 `Env` 将覆盖除 KubeBlocks 系统默认 `Env` 外的其他 `Env`。覆盖逻辑与 `Annotations` 和 `Labels` 类似，即若 `Env Name` 相同，则用实例模板中的 `Value` 或 `ValueFrom`；不同，则添加为新的 `Env`。 + +### Volumes + +用于覆盖默认模板第一个 Container 的 `Volumes` 字段。覆盖逻辑与 `Env` 类似，即若 `Volume Name` 相同，则用实例模板中的 `VolumeSource`；否则，添加为新的 `Volume`。 + +### VolumeMounts + +用于覆盖默认模板第一个 Container 的 `VolumeMounts` 字段。覆盖逻辑与 `Volumes` 类似，即若 VolumeMount `Name` 相同，则用实例模板中的 `MountPath` 等值；否则，添加为新的 `VolumeMount`。 + +### VolumeClaimTemplates + +用于覆盖 Component 中通过 `ClusterComponentVolumeClaimTemplate` 生成的 `VolumeClaimTemplates`。覆盖逻辑与 Volumes 类似，即若 `PersistentVolumeClaim Name` 相同，则用实例模板中的 `PersistentVolumeClaimSpec` 值；否则，添加为新的 `PersistentVolumeClaim`。 diff --git a/i18n/zh-cn/user-docs/maintenance/instance-template/introduction.md b/i18n/zh-cn/user-docs/maintenance/instance-template/introduction.md new file mode 100644 index 00000000000..0e4a372928a --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/instance-template/introduction.md @@ -0,0 +1,27 @@ +--- +title: 简介 +description: 实例模板简介 +keywords: [实例模板] +sidebar_position: 1 +sidebar_label: 简介 +--- + +# 简介 + +## 什么是实例模板 + +***实例（Instance）***是 KubeBlocks 中的基本单元，它由一个 Pod 和若干其它辅助对象组成。为了容易理解，你可以先把它简化为一个 Pod，下文中将统一使用“实例”这个名字。 + +从 0.9 开始，我们可以为一个 Cluster 中的某个 Component 设置若干实例模板（Instance Template），实例模板中包含 Name、Replicas、Annotations、Labels、Env、Tolerations、NodeSelector 等多个字段（Field），这些字段最终会覆盖（Override）默认模板（也就是在 ClusterDefinition 和 ComponentDefinition 中定义的 PodTemplate）中相应的字段，并生成最终的模板以便用来渲染实例。 + +## 为什么采用实例模板 + +在 KubeBlocks 中，一个 *Cluster* 由若干个 *Component* 组成，一个 *Component* 最终管理若干 *Pod* 和其它对象。 + +在 0.9 版本之前，这些 Pod 是从同一个 PodTemplate 渲染出来的（该 PodTemplate 在 ClusterDefinition 或 ComponentDefinition 中定义）。这样的设计不能满足如下需求： + + - 对于从同一个引擎中渲染出来的 Cluster，为其设置单独的 *NodeName*、*NodeSelector* 或 *Tolerations* 等调度相关配置。 + - 对于从同一个引擎中渲染出来的 Component，为它所管理的 Pod 添加自定义 *Annotation*、*Label* 或 *ENV* + - 对于被同一个 Component 管理的 Pod，为它们配置不同的 *CPU*、*Memory* 等 *Resources Requests* 和 *Limits* + +类似的需求还有很多，所以从 0.9 版本开始，Cluster API 中增加了实例模板特性，以满足上述需求。 diff --git a/i18n/zh-cn/user-docs/maintenance/resource-scheduling/resource-scheduling.md b/i18n/zh-cn/user-docs/maintenance/resource-scheduling/resource-scheduling.md index 13de360f261..9c99b0dc8f2 100644 --- a/i18n/zh-cn/user-docs/maintenance/resource-scheduling/resource-scheduling.md +++ b/i18n/zh-cn/user-docs/maintenance/resource-scheduling/resource-scheduling.md @@ -5,11 +5,18 @@ keywords: [pod 亲和性] sidebar_position: 1 --- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + # 为集群配置 Pod 亲和性 亲和性控制了 Pod 在节点上的分配逻辑。合理地将 Kubernetes 的 Pod 分配到不同的节点上，可以提高业务的可用性、资源使用率和稳定性。 -可以通过 `kbcli` 件来设置亲和性和容忍度。`kbcli` 仅支持集群级别的配置，如需实现集群级别和组件级别的配置，可使用 CR YAML 文件，具体操作可参考[API 文档](./../../../api-docs/maintenance/resource-scheduling/resource-scheduling.md)。 +可以通过 `kbcli` 件来设置亲和性和容忍度。`kbcli` 仅支持集群级别的配置，如需实现集群级别和组件级别的配置，可通过 CR YAML 文件配置。 + + + + 执行 `kbcli cluster create -h` 命令查看示例，并配置亲和性及容忍度的参数。 @@ -56,9 +63,65 @@ Options: ....... ``` + + + + +你可以在集群配置文件或组件配置文件中配置 Pod 亲和性和容忍度。 + +集群级配置是所有组件的默认配置；如果组件中存在 Pod 亲和性配置，组件级配置将生效，并覆盖默认的集群级配置。 + +```yaml +spec: + affinity: + podAntiAffinity: Preferred + topologyKeys: + - kubernetes.io/hostname + nodeLabels: + topology.kubernetes.io/zone: us-east-1a + tolerations: + - key: EngineType + operator: Equal + value: mysql + effect: NoSchedule + componentSpecs: + - name: mysql + componentDefRef: mysql + affinity: + podAntiAffinity: Required + topologyKeys: + - kubernetes.io/hostname + ...... +``` + +**YAML 文件中的参数** + +* 亲和性 + + 与 Pod 亲和性相关的参数位于集群的 CR YAML 文件的 `spec.affinity` 对象下。 + + Pod 亲和性配置可以应用于集群或组件，组件级配置将覆盖集群级配置。 + +* 容忍度 + + 与容忍度相关的参数位于集群 CR YAML 文件的 `spec.tolerations` 对象下，使用 Kubernetes 的原生语义。有关容忍度参数配置，请参考 Kubernetes 官方文档[污点和容忍度](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)。 + + 与亲和性配置类似，容忍度也支持组件级和集群级配置。默认使用集群级配置，组件级别的配置会覆盖集群级别的配置。 + +| **参数** | **值** | **描述** | +| :-- | :-- | :-- | +| podAntiAffinity | - Required
- Preferred (default) |

表示当前组件下 Pod 的反亲和性级别。

- Required 表示 Pod 必须均匀分布在由 `topologyKeys` 指定的故障域中。

- Preferred 表示 Pod 最好能够均匀分布在由 `topologyKeys` 指定的故障域中。

| +| topologyKeys | |

TopologyKey 是节点标签的 key。具有相同 key 值的节点属于相同的拓扑，即相同的故障域。

例如，如果 TopologyKey 是 `kubernetes.io/hostname`，每个节点都是该拓扑的一个域。如果 TopologyKey 是 `topology.kubernetes.io/zone`，每个可用的区域都是该拓扑的一个域。

| +| nodeLabels | | NodeLabels 指定 Pod 只能被调度到具有指定节点标签的节点上。 | +| tenancy |

- SharedNode (default)

- DedicatedNode

|

表示 Pod 的租户类型：

- SharedNode 表示多个 Pod 共享一个节点。

- DedicatedNode 表示一个节点专用于一个 Pod。

| + + + + + ## 示例 -以下示例使用 `kbcli` 创建集群实例，并展示了如何进行 Pod 亲和性和容忍度配置。 +以下示例展示了如何进行 Pod 亲和性和容忍度配置。 ### 默认配置 @@ -70,48 +133,148 @@ Options: 下面的示例创建了一个尽可能跨节点的集群。 + + + + ```bash kbcli cluster create --topology-keys kubernetes.io/hostname --pod-anti-affinity Preferred ``` + + + + +```yaml +spec: + affinity: + podAntiAffinity: Preferred +``` + + + + + ### 强制打散 如果集群的 Pod 必须部署在不同的拓扑域，以确保集群能够跨拓扑域具备容灾能力，你可以将 Pod 亲和性配置为“Required”。 下面的示例创建了一个必须跨节点部署的集群。 + + + + ```bash kbcli cluster create --topology-keys kubernetes.io/hostname --pod-anti-affinity Required ``` + + + + +```yaml +spec: + affinity: + podAntiAffinity: Required +``` + + + + + ### 在指定节点上部署 可以通过节点标签在指定的节点上部署集群。 下面的示例创建了一个在带有拓扑标签 `topology.kubernetes.io/zone=us-east-1a` 的节点上部署的集群。 + + + + ```bash kbcli cluster create --node-labels '"topology.kubernetes.io/zone=us-east-1a"' ``` + + + + +```yaml +spec: + affinity: + nodeLabels: + topology.kubernetes.io/zone: us-east-1a +``` + + + + + ### 独享主机组 如果想通过污点和节点标签来管理节点分组，并且需要将集群部署在独享的主机分组中，可以设置容忍度并指定一个节点标签。 例如，如果有一个用于部署数据库集群的主机分组，并且该主机添加了一个名为 `database=true:NoSchedule` 的污点和一个名为 `database=true` 的标签，那么可以按照以下命令创建一个集群。 + + + + ```bash kbcli cluster create --node-labels '"databa=true"' --tolerations '"key=database,value=true,operator=Equal,effect=NoSchedule" ``` + + + + +```yaml +spec: + affinity: + podAntiAffinity: Preferred + topologyKeys: + - kubernetes.io/hostname + nodeLabels: + database: true + tolerations: + - key: database + operator: Equal + value: true + effect: NoSchedule +``` + + + + + ### 集群 Pod 独占一个节点 如果需要一个仅用于线上核心业务的集群，并且需要确保该集群的每个 Pod 都有自己的节点以避免受到集群中其他 Pod 的影响，你可以将 `tenancy` 设置为“DedicatedNode”。 + + + + ```bash kbcli cluster create --tenancy=DedicatedNode ``` + + + + +```yaml +spec: + affinity: + tenancy: DedicatedNode +``` + + + + + :::note 只有为这些节点添加污点之后，命令才能成功执行。否则，未由 KubeBlocks 托管的业务仍然可以部署在这些节点上。 diff --git a/i18n/zh-cn/user-docs/maintenance/scale/_category_.yaml b/i18n/zh-cn/user-docs/maintenance/scale/_category_.yaml new file mode 100644 index 00000000000..051d3c34636 --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/scale/_category_.yaml @@ -0,0 +1,4 @@ +position: 1 +label: 扩缩容 +collapsible: true +collapsed: true \ No newline at end of file diff --git a/i18n/zh-cn/user-docs/maintenance/scale/horizontal-scale.md b/i18n/zh-cn/user-docs/maintenance/scale/horizontal-scale.md new file mode 100644 index 00000000000..5087329d3e9 --- /dev/null +++ b/i18n/zh-cn/user-docs/maintenance/scale/horizontal-scale.md @@ -0,0 +1,385 @@ +--- +title: 水平扩缩容 +description: 如何对集群和实例进行水平扩缩容 +keywords: [水平扩缩容, 水平伸缩] +sidebar_position: 2 +sidebar_label: 水平扩缩容 +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# 水平扩缩容 + +从 v0.9.0 开始，KubeBlocks 支持 ScaleIn 和 ScaleOut 两类操作，同时支持副本（replcia）和具体实例（instance）的扩缩容。 + +- ScaleIn：支持水平缩容指定副本及指定实例下线。 +- ScaleOut: 支持水平扩容指定副本及指定实例重新上线。 + +可通过声明式 API 或创建 OpsRequest 的方式执行水平扩缩容： + +- 以声明式 API 的方式修改集群 + + 通过声明式 API 方式，可直接修改 Cluster YAML 文件来指定每个组件的副本数量和实例模板。如果新的副本数量大于当前 Pod 的数量，则表示扩展（scale-out）；相反，如果新的副本数量少于当前 Pod 的数量，则表示缩容（scale-in）。 + +- 创建 OpsRequest + + 另一种方法是在 OpsRequest 中指定副本数量的增量。控制器（controller）将根据集群组件中当前 Pod 的数量和增量值计算所需的副本数量，并相应地执行扩缩容操作。 + +:::note + +- 在并发修改的情况下，例如多个控制器同时修改 Pod 的数量，计算出的 Pod 数量可能会不准确。你可以在客户端确保操作顺序，或者设置 `KUBEBLOCKS_RECONCILE_WORKERS=1`。 +- 如果正在使用声明式 API 进行扩缩容操作，该操作将被终止。 +- 从 v0.9.0 开始，MySQL 和 PostgreSQL 集群在进行水平扩缩容后，KubeBlocks 会根据新的规格自动匹配合适的配置模板。这因为 KubeBlocks 在 v0.9.0 中引入了动态配置功能。该功能简化了配置参数的过程，节省了时间和精力，并减少了由于配置错误引起的性能问题。有关详细说明，请参阅[配置](./../../kubeblocks-for-apecloud-mysql/configuration/configuration.md)。 + +::: + +## 为什么需要指定实例扩缩容 + +早期版本中，KubeBlocks 最终生成的 Workload 是 *StatefulSet*，这是一把双刃剑。一方面，KubeBlocks 可以借助 *StatefulSet* 实现对数据库等有状态应用的管理，另一方面，这也导致 KubeBlocks 继承了其局限性。 + +其中的局限性之一是，在水平缩容场景下，*StatefulSet* 会按照 *Ordinal* 顺序从大到小依次下线 Pod。当 *StatefulSet* 中运行的是数据库时，这个局限性会使得数据库的可用性降低。 + +另一个问题是，我们仍以上面的场景为例。某一天，Pod 所在 Node 因为物理机故障，导致磁盘损坏，最终导致数据无法正常读写。按照数据库运维最佳实践，我们需要将受损的 Pod 下线，并在其它健康 Node 上搭建新的副本，但基于 *StatefulSet* 来做这样的运维操作并不容易。在 Kubernetes 社区中，我们也可以看到[类似场景的讨论](https://github.com/kubernetes/kubernetes/issues/83224)。 + +为了解决上述局限性，KubeBlocks 从 0.9 版本开始使用 *InstanceSet* 替代 *StatefulSet*。*InstanceSet* 是一个通用 Workload API，负责管理一组实例。引入 *InstanceSet* 后，KubeBlocks 支持了“指定实例缩容”特性，以提升可用性。 + +## 开始之前 + +本文档以 Redis 为例进行演示，以下为原组件拓扑。 + +```yaml +apiVersion: apps.kubeblocks.io/v1alpha1 +kind: Cluster +metadata: + name: redis + namespace: kubeblocks-cloud-ns +spec: + componentSpecs: + - name: proxy + componentDef: redis-proxy + replicas: 10 + instances: + - name: proxy-2c + replicas: 3 + resources: + limits: + cpu: 2 + memory: 4Gi + resources: + limits: + cpu: 4 + memory: 8Gi + offlineInstances: + - redis-proxy-proxy-2c4g-0 + - redis-proxy-proxy-2c4g-1 +``` + +查看集群状态是否为 `Running`，否则，后续操作可能失败。 + +```bash +kubectl get cluster redis +``` + +## 水平缩容 + +### 示例 1 + +本示例演示了如何应用 OpsRequest 将副本数缩容至 8。本示例将按照默认规则删除 pod，未指定任何实例。 + +```yaml +kubectl apply -f - < + + + +```yaml +kubectl apply -f - < + + + +您也可通过修改集群 YAML 文件指定实例下线。 + +```yaml +kubectl edit cluster redis +> +apiVersion: apps.kubeblocks.io/v1alpha1 +kind: Cluster +metadata: + name: redis +spec: + componentSpecs: + - name: proxy + replicas: 9 + offlineInstances: ["redis-proxy-proxy-2c4g-2"] +# ... +``` + + + + +## 水平扩容 + +后续实例演示了如何对副本和实例进行水平扩容。如果您只想对副本进行扩容，仅需修改 `replicaChanges`，例如， + +```yaml +kubectl apply -f - < +NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE +mycluster mysql mysql-8.0.33 Delete Running 4d18h +``` + +## 步骤 + +可通过以下两种方式进行垂直扩缩容。 + + + + + +1. 对指定集群应用 OpsRequest，可按需修改参数值。 + + ```bash + kubectl apply -f - < + NAMESPACE NAME TYPE CLUSTER STATUS PROGRESS AGE + demo ops-vertical-scaling VerticalScaling mycluster Succeed 3/3 6m + ``` + + 如果有报错，可执行 `kubectl describe ops -n demo` 命令查看该运维操作的相关事件，协助排障。 + +3. 查看相应资源是否变更。 + + ```bash + kubectl describe cluster mycluster -n demo + ``` + + + + + +1. 修改 YAML 文件中 `spec.componentSpecs.resources` 的配置。`spec.componentSpecs.resources` 控制资源的请求值和限制值，修改参数值将触发垂直扩缩容。 + + ```yaml + kubectl edit cluster mycluster -n demo + > + apiVersion: apps.kubeblocks.io/v1alpha1 + kind: Cluster + metadata: + name: mycluster + namespace: demo + spec: + clusterDefinitionRef: apecloud-mysql + clusterVersionRef: ac-mysql-8.0.30 + componentSpecs: + - name: mysql + componentDefRef: mysql + replicas: 3 + resources: # 修改参数值 + requests: + memory: "2Gi" + cpu: "1" + limits: + memory: "4Gi" + cpu: "2" + volumeClaimTemplates: + - name: data + spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 20Gi + terminationPolicy: Delete + ``` + +2. 查看相应资源是否变更。 + + ```bash + kubectl describe cluster mycluster -n demo + ``` + + + + diff --git a/i18n/zh-cn/user-docs/observability/configure-alert.md b/i18n/zh-cn/user-docs/observability/configure-alert.md index f2ffe5387b8..2c73a0d7fa3 100644 --- a/i18n/zh-cn/user-docs/observability/configure-alert.md +++ b/i18n/zh-cn/user-docs/observability/configure-alert.md @@ -11,7 +11,7 @@ sidebar_position: 2 :::note -告警功能对所有数据库都是一样的。 +所有数据库的告警功能相同。 ::: @@ -37,15 +37,7 @@ alert: PostgreSQLTooManyConnections description: "PostgreSQL has too many connections and the value is {{ $value }}. (instance: {{ $labels.pod }})" ``` -你可以在 **Prometheus 仪表盘**的 **Alerts** 选项卡中查看所有的告警规则。执行以下命令打开 Prometheus 仪表盘： - -```bash -# 查看仪表盘列表 -kbcli dashboard list - -# 打开 Prometheus 仪表盘 -kbcli dashboard open kubeblocks-prometheus-server # 这是一个示例，请根据上述仪表盘列表中的实际名称填写 -``` +您可按需配置告警规则，详情可参考 [Prometheus 告警规则文档](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/#defining-alerting-rules)。 ## 通知 diff --git a/i18n/zh-cn/user-docs/observability/monitor-database.md b/i18n/zh-cn/user-docs/observability/monitor-database.md index 4598a56e544..6fbe3497908 100644 --- a/i18n/zh-cn/user-docs/observability/monitor-database.md +++ b/i18n/zh-cn/user-docs/observability/monitor-database.md @@ -5,22 +5,33 @@ keywords: [监控数据库, 监控集群, 监控] sidebar_position: 1 --- -# 监控数据库 +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; -KubeBlocks 提供了强大的可观测性能力。你可以实时观察数据库的健康状态，及时跟踪数据库，并优化数据库性能。本文档将展示 KubeBlocks 中的数据库监控工具以及它们该如何使用。 +# 监控数据库 -## Playground 演示场景 +KubeBlocks 提供了强大的可观测性能力。您可以实时观察数据库的健康状态，及时跟踪数据库，并优化数据库性能。本文档将展示 KubeBlocks 中的数据库监控工具以及它们该如何使用。 -KubeBlocks 以引擎形式集成了许多开源监控组件，如 Prometheus、AlertManager 和 Grafana，并采用定制的 `apecloud-otel-collector` 组件收集数据库和宿主机的监控指标。在部署 KubeBlocks Playground 时，所有监控组件都会默认启用。 +## Playground/演示场景 -KubeBlocks Playground 内置以下几个监控组件： +KubeBlocks 以 Addon 形式集成了许多开源监控组件，如 Prometheus、AlertManager 和 Grafana，并采用定制的 `apecloud-otel-collector` 组件收集数据库和宿主机的监控指标。您可以在测试或演示环境中使用以下监控引擎。 - `prometheus`：包括 Prometheus 和 AlertManager 两个监控组件。 - `grafana`：包括 Grafana 的监控组件。 +- `victoria-metrics`：从多个源收集指标并将其存储到 VictoriaMetrics 中。 +- `victoria-metrics-agent`：从多个源收集指标，重新标记和过滤收集到的指标，并通过 Prometheus `remote_write` 协议或 VictoriaMetrics `remote_write` 协议将其存储到 VictoriaMetrics 或其他存储系统中。 - `alertmanager-webhook-adaptor`：包括消息通知扩展组件，用于扩展 AlertManager 的通知能力。目前已经支持飞书、钉钉和企业微信的自定义机器人。 - `apecloud-otel-collector`：用于采集数据库和宿主机的指标。 -1. 查看所有支持的引擎，确保监控引擎已启用。 +如果您使用的是 KubeBlocks Playground，上述监控引擎默认启用。如需在测试环境中使用，可按照以下步骤操作。 + +### 步骤 + + + + + +1. 查看所有支持的引擎，确保监控引擎已启用。可参考[此文档](./../installation/install-with-kbcli/install-kbcli.md)，查看安装或启用引擎的详细说明。 ```bash # 查看内置支持的所有引擎 @@ -28,8 +39,17 @@ KubeBlocks Playground 内置以下几个监控组件： ... grafana Helm Enabled true alertmanager-webhook-adaptor Helm Enabled true - prometheus Helm Enabled alertmanager true ... + + # 如果监控引擎未列出，则表明该引擎未安装，可按照以下步骤安装引擎 + # 1. 检索引擎 + kbcli addon search prometheus + + # 2. 安装引擎 + kbcli addon install prometheus --index kubeblocks + + # 如果列表中有该引擎但显示为 Disabled，说明引擎未启用，可按照以下步骤启用引擎 + kbcli addon enable apecloud-otel-collector ``` 2. 查看集群监控功能是否已开启。如果输出结果显示 `disableExporter: false`，则说明监控功能已开启。 @@ -71,17 +91,128 @@ KubeBlocks Playground 内置以下几个监控组件： kbcli dashboard open kubeblocks-grafana ``` + + + + +:::note + +以下示例展示了启用 `prometheus` 引擎。您可以将 `prometheus` 替换为其他监控引擎的名称，以开启对应的引擎。 + +::: + +### 1. 启用监控引擎 + +1. （可选）添加 KubeBlocks 仓库。如果您通过 Helm 安装 KubeBlocks，可直接执行 `helm repo update`。 + + ```bash + helm repo add kubeblocks https://apecloud.github.io/helm-charts + helm repo update + ``` + +2. 查看引擎版本。 + + ```bash + helm search repo kubeblocks/prometheus --devel --versions + ``` + +3. 安装引擎。 + + ```bash + helm install prometheus kubeblocks/prometheus --namespace kb-system --create-namespace + ``` + +4. 验证该引擎是否安装成功。 + + 状态显示为 deployed 表明该引擎安装成功。 + + ```bash + helm list -A + > + 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 + ``` + +### 2. 开启集群监控功能 + +监控功能开启后，开源或自定义 Exporter 将会注入，Prometheus 服务器将自动发现该 Exporter，并定时抓取监控指标。 + +如果您在创建集群是关闭了监控功能，可执行以下命令再次开启。 + +```bash +kubectl patch cluster mycluster -n demo --type "json" -p '[{"op":"add","path":"/spec/componentSpecs/0/disableExporter","value":false}]' +``` + +您也可通过编辑 `cluster.yaml` 文件开启/停用监控功能。 + +```bash +kubectl edit cluster mycluster -n demo +...... +componentSpecs: + - name: mysql + componentDefRef: mysql + enabledLogs: + - error + - general + - slow + disableExporter: false # 修改该参数值 +``` + +（可选）如果您想要在使用后关闭监控功能，可执行以下命令停用该功能。 + +```bash +kubectl patch cluster mycluster -n namespace --type "json" -p '[{"op":"add","path":"/spec/componentSpecs/0/disableExporter","value":true}]' +``` + +### 3. 查看监控大盘 + +使用 KubeBlocks 提供的 Grafana 引擎查看监控大盘。 + +1. 获取 Grafana 引擎的用户名和密码。 + + ```bash + kubectl get secret grafana -n kb-system -o jsonpath='{.data.admin-user}' |base64 -d + + kubectl get secret grafana -n kb-system -o jsonpath='{.data.admin-password}' |base64 -d + ``` + +2. 执行以下命令连接 Grafana 大盘。 + + ```bash + kubectl port-forward svc/grafana -n kb-system 3000:80 + > + Forwarding from 127.0.0.1:3000 -> 3000 + Forwarding from [::1]:3000 -> 3000 + Handling connection for 3000 + ``` + +3. 打开浏览器，输入 `127.0.0.1:3000`，跳转至大盘界面。 +4. 输入第 1 步中获取的用户名和密码，即可访问。 + +:::note + +如果大盘中无数据，您可以检查界面中的 job 是否为 `kubeblocks-service`。如果不是，可在 job 框中输入 `kubeblocks-service`，回车后再次查看。 + +![monitoring](./../../img/api-monitoring.png) + +::: + + + + + ## 生产环境 在生产环境中，强烈建议搭建独立的监控系统或购买第三方监控服务。 -### 集成监控大盘和告警规则 +### 1. 集成监控大盘和告警规则 KubeBlocks 为主流数据库引擎提供了 Grafana 监控大盘和 Prometheus 告警规则，您可通过[该仓库](https://github.com/apecloud/kubeblocks-mixin)获取，或者按需转化或定制。 具体导入方法，可参考您使用的第三方监控服务的相关文档。 -### 开启数据库监控功能 +### 2. 开启数据库监控功能 查看集群监控功能是否已开启。如果输出结果显示 `disableExporter: false`，则说明监控功能已开启。 @@ -101,20 +232,61 @@ spec: 如果输出结果中未显示 `disableExporter: false`，则说明集群监控功能未开启，可执行以下命令，开启监控功能。 + + + + ```bash kbcli cluster update mycluster --disable-exporter=false ``` -### 查看大盘 + + + + +```bash +kubectl patch cluster mycluster -n demo --type "json" -p '[{"op":"add","path":"/spec/componentSpecs/0/disableExporter","value":false}]' +``` + +您也可通过编辑 `cluster.yaml` 文件开启/停用监控功能。 + +```bash +kubectl edit cluster mycluster -n demo +...... +componentSpecs: + - name: mysql + componentDefRef: mysql + enabledLogs: + - error + - general + - slow + disableExporter: false # 修改该参数值 +``` + +（可选）如果您想要在使用后关闭监控功能，可执行以下命令停用该功能。 + +```bash +kubectl patch cluster mycluster -n namespace --type "json" -p '[{"op":"add","path":"/spec/componentSpecs/0/disableExporter","value":true}]' +``` + + + + + +### 3. 查看大盘 您可通过 Grafana 网页控制台查看对应集群的大盘。具体信息，可查看 [Grafana 大盘文档](https://grafana.com/docs/grafana/latest/dashboards/)。 -### （可选）开启远程写（Remote Write） +### 4. （可选）开启远程写（Remote Write） 远程写为可选操作，您可根据实际需要开启。 KubeBlocks 支持 victoria-metrics-agent 引擎，支持用户将数据远程写入虚拟机中，相较于 Prometheus 原生应用，[vmagent](https://docs.victoriametrics.com/vmagent.html) 更轻量。 + + + + 1. 开启数据推送。 你只需要提供支持 Prometheus Remote Write 协议的终端节点（可以支持多个终端节点）。关于获取方式，请参考第三方监控系统的文档。 @@ -155,3 +327,21 @@ KubeBlocks 支持 victoria-metrics-agent 引擎，支持用户将数据远程写 ```bash kbcli addon disable victoria-metrics-agent ``` + + + + + +KubeBlocks 支持 `victoria-metrics-agent` 引擎，使您可以将数据远程写入您的 VM。与原生 Prometheus 相比，[vmgent](https://docs.victoriametrics.com/vmagent.html) 更轻量并且支持水平扩展。 + +执行以下命令，安装 `victoria-metrics-agent` 引擎。 + +```bash +helm install vm kubeblocks/victoria-metrics-agent --set remoteWriteUrls={http://:/} +``` + +有关详细设置，您可以参考 [Victoria Metrics 文档](https://artifacthub.io/packages/helm/victoriametrics/victoria-metrics-agent)。 + + + + From 9994d7394dff3315a9c771c4cfa810aacfb841fe Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Thu, 31 Oct 2024 12:04:19 +0800 Subject: [PATCH 02/11] docs: update docs --- .../_category_.yml | 0 .../prepare-a-local-k8s-cluster.md | 0 ...t-to-database-in-production-environment.md | 1 + .../user-docs/create_database/_category_.yml | 2 +- .../overview-of-create-database.md | 2 +- .../install-with-helm/uninstall-kubeblocks.md | 2 +- .../_category_.yml | 0 .../prepare-a-local-k8s-cluster.md | 0 .../backup-and-restore/backup/backup-repo.md | 2 +- .../backup/configure-backup-policy.md | 4 + .../backup/scheduled-backup.md | 4 +- .../backup-and-restore/restore/pitr.md | 4 +- .../cross-k8s-deployment.md | 74 ++++++++++--------- .../in-place-update/ignore-vertical-scale.md | 2 +- .../resource-scheduling.md | 6 +- .../observability/configure-alert.md | 4 +- .../observability/monitor-database.md | 2 +- .../overview/database-engines-supported.md | 11 +-- .../overview/kubernetes_and_operator_101.md | 4 +- 19 files changed, 69 insertions(+), 55 deletions(-) rename docs/user_docs/installation/{prerequisite => prepare-a-local-k8s-cluster}/_category_.yml (100%) rename docs/user_docs/installation/{prerequisite => prepare-a-local-k8s-cluster}/prepare-a-local-k8s-cluster.md (100%) rename i18n/zh-cn/user-docs/installation/{prerequisite => prepare-a-local-k8s-cluster}/_category_.yml (100%) rename i18n/zh-cn/user-docs/installation/{prerequisite => prepare-a-local-k8s-cluster}/prepare-a-local-k8s-cluster.md (100%) diff --git a/docs/user_docs/installation/prerequisite/_category_.yml b/docs/user_docs/installation/prepare-a-local-k8s-cluster/_category_.yml similarity index 100% rename from docs/user_docs/installation/prerequisite/_category_.yml rename to docs/user_docs/installation/prepare-a-local-k8s-cluster/_category_.yml diff --git a/docs/user_docs/installation/prerequisite/prepare-a-local-k8s-cluster.md b/docs/user_docs/installation/prepare-a-local-k8s-cluster/prepare-a-local-k8s-cluster.md similarity index 100% rename from docs/user_docs/installation/prerequisite/prepare-a-local-k8s-cluster.md rename to docs/user_docs/installation/prepare-a-local-k8s-cluster/prepare-a-local-k8s-cluster.md diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md index a52116a204f..5a3284534af 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md @@ -18,6 +18,7 @@ import TabItem from '@theme/TabItem'; - 场景 3：Client3 和数据库位于不同的 VPC，例如其他 VPC 或公共网络。如果要连接 Client3 和数据库，请参考[暴露 VPC 公网地址方案](#场景-3-连接在其他-vpc-或公共网络中的客户端)。 参考下面的网络位置关系图。 + ![Example](../img/../../img/connect-to-database-in-production-env-network-locations.jpg) ## 场景 1. 连接在同一个 Kubernetes 集群中的客户端 diff --git a/i18n/zh-cn/user-docs/create_database/_category_.yml b/i18n/zh-cn/user-docs/create_database/_category_.yml index 5476392286c..023b4982026 100644 --- a/i18n/zh-cn/user-docs/create_database/_category_.yml +++ b/i18n/zh-cn/user-docs/create_database/_category_.yml @@ -1,4 +1,4 @@ position: 5 -label: Create Database +label: 创建数据库集群 collapsible: true collapsed: true \ No newline at end of file diff --git a/i18n/zh-cn/user-docs/create_database/overview-of-create-database.md b/i18n/zh-cn/user-docs/create_database/overview-of-create-database.md index d4175a46bae..625879df95a 100644 --- a/i18n/zh-cn/user-docs/create_database/overview-of-create-database.md +++ b/i18n/zh-cn/user-docs/create_database/overview-of-create-database.md @@ -3,7 +3,7 @@ title: 如何创建数据库集群 description: 如何创建数据库集群 keywords: [创建数据库, KubeBlocks] sidebar_position: 1 -sidebar_label: Overview +sidebar_label: 概览 --- # 创建数据库集群 diff --git a/i18n/zh-cn/user-docs/installation/install-with-helm/uninstall-kubeblocks.md b/i18n/zh-cn/user-docs/installation/install-with-helm/uninstall-kubeblocks.md index 2f8289fbe06..06d96c78c43 100644 --- a/i18n/zh-cn/user-docs/installation/install-with-helm/uninstall-kubeblocks.md +++ b/i18n/zh-cn/user-docs/installation/install-with-helm/uninstall-kubeblocks.md @@ -9,7 +9,7 @@ sidebar_label: 卸载 KubeBlocks import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -# Uninstall KubeBlocks +# 卸载 KubeBlocks 卸载顺序： diff --git a/i18n/zh-cn/user-docs/installation/prerequisite/_category_.yml b/i18n/zh-cn/user-docs/installation/prepare-a-local-k8s-cluster/_category_.yml similarity index 100% rename from i18n/zh-cn/user-docs/installation/prerequisite/_category_.yml rename to i18n/zh-cn/user-docs/installation/prepare-a-local-k8s-cluster/_category_.yml diff --git a/i18n/zh-cn/user-docs/installation/prerequisite/prepare-a-local-k8s-cluster.md b/i18n/zh-cn/user-docs/installation/prepare-a-local-k8s-cluster/prepare-a-local-k8s-cluster.md similarity index 100% rename from i18n/zh-cn/user-docs/installation/prerequisite/prepare-a-local-k8s-cluster.md rename to i18n/zh-cn/user-docs/installation/prepare-a-local-k8s-cluster/prepare-a-local-k8s-cluster.md diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md index d6d03d66190..b3e0d7185c4 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md @@ -24,7 +24,7 @@ BackupRepo 是备份数据的存储仓库，支持配置 OSS（阿里云对象 * [安装 kbcli](./../../../installation/install-with-kbcli/install-kbcli.md)。 * [安装 kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)。 * [安装 Helm](https://helm.sh/docs/intro/install/)。 -* 安装 KubeBlocks。如果未安装，可通过 [kbcli](./../../../installation/install-with-kbcli/install-kubeblocks-with-kbcli.md) 或 [Helm](./../../../installation/install-with-kbcli/install-kubeblocks-with-kbcli.md) 进行安装。 +* 安装 KubeBlocks。如果未安装，可通过 [kbcli](./../../../installation/install-with-kbcli/install-kubeblocks-with-kbcli.md) 或 [Helm](./../../../installation/install-with-helm/install-kubeblocks.md) 进行安装。 ## 安装 MinIO diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/configure-backup-policy.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/configure-backup-policy.md index c46cd76d00c..a6c34fc9956 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/configure-backup-policy.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/configure-backup-policy.md @@ -142,10 +142,12 @@ mysql-cluster-mysql-backup-policy-hscale default false mysql-cluster +```bash kubectl get backuppolicy | grep mycluster > mycluster-mysql-backup-policy Available 35m mycluster-mysql-backup-policy-hscale Available 35m +``` @@ -177,7 +179,9 @@ volume-snapshot volumesnapshot-for-apecloud-mysql true +```bash kubectl get backuppolicy mycluster-mysql-backup-policy -o yaml +``` diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/scheduled-backup.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/scheduled-backup.md index 956d5222840..77b397adf73 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/scheduled-backup.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/scheduled-backup.md @@ -19,8 +19,8 @@ KubeBlocks 支持为集群配置自动备份。 ```bash kbcli cluster update mysql-cluster --backup-enabled=true \ ---backup-method=xtrabackup --backup-repo-name=my-repo \ ---backup-retention-period=7d --backup-cron-expression="0 18 * * *" + --backup-method=xtrabackup --backup-repo-name=my-repo \ + --backup-retention-period=7d --backup-cron-expression="0 18 * * *" ``` - `--backup-enabled` 表示是否开启自动备份。 diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/pitr.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/pitr.md index 157205b816d..bce84b5bbc6 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/pitr.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/restore/pitr.md @@ -38,10 +38,10 @@ KubeBlocks 已支持对 MySQL 和 PostgreSQL 等数据库的 PITR 功能。 ```bash - # 1. Get all backup objects for the current cluster + # 1. 获取当前集群的全部备份对象（backup objects） kubectl get backup -l app.kubernetes.io/instance=pg-cluster - # 2. Get the backup time range for Continuous Backup + # 2. 获取持续备份的备份实践范围 kubectl get backup -l app.kubernetes.io/instance=pg-cluster -l dataprotection.kubeblocks.io/backup-type=Continuous -o yaml ... status: diff --git a/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md index 7320387b964..5e3bc7ed4f1 100644 --- a/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md +++ b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md @@ -1,28 +1,28 @@ --- -title: 多 k8s 部署 -description: 如何使用 KubeBlocks 实现多 k8s 部署 +title: 多 K8s 部署 +description: 如何使用 KubeBlocks 实现多 K8s 部署 keywords: [cross k8s deployment] sidebar_position: 1 -sidebar_label: 使用 KubeBlocks 实现多 k8s 部署 +sidebar_label: 使用 KubeBlocks 实现多 K8s 部署 --- -# 使用 KubeBlocks 实现多 k8s 部署 +# 使用 KubeBlocks 实现多 K8s 部署 -KubeBlocks 支持管理多个 Kubernetes 集群，为用户在实例容灾、k8s 集群管理等方面提供新的选项。为支持多 K8s 管理，KubeBlocks 引入了 control plane 和 data plane。 +KubeBlocks 支持管理多个 Kubernetes 集群，为用户在实例容灾、K8s 集群管理等方面提供新的选项。为支持多 K8s 管理，KubeBlocks 引入了控制面（control plane ）和数据面（data plane）。 -* Control plane：一个独立的 k8s 集群，KubeBlocks operator 运行在该集群当中，KubeBlocks 定义的相关对象大都存放在这个集群（比如 definition、cluster、backup、ops 等）。用户通过跟这个集群的 API 进行交互来实现对多集群实例的管理。 -* Data plane：用于运行最终 workload 的 k8s 集群，数量可以是一到多个。这些集群当中会 hosting 实例相关的计算、存储、网络等资源，如 pod、pvc、service、sa、cm、secret、jobs 等，而 KubeBlocks operator 目前（v0.9.0）不会运行在当中。 +* 控制面：一个独立的 K8s 集群，KubeBlocks operator 运行在该集群当中，KubeBlocks 定义的相关对象大都存放在这个集群（比如 Definition、Cluster、Backup、Ops 等）。用户通过跟这个集群的 API 进行交互来实现对多集群实例的管理。 +* 数据面：用于运行最终工作负载的 K8s 集群，数量可以是一到多个。这些集群当中会 hosting 实例相关的计算、存储、网络等资源，如 Pod、PVC、Service、SA、CM、Secret、Jobs 等，而 KubeBlocks operator 目前（v0.9.0）不会在这些集群中运行。 -实际物理部署上，control plane 可以选择部署在单个 AZ，简单灵活；也可以选择部署在多个不同 AZ，提供更高的可用性保证；也可以复用某个 data plane 集群，以更低成本的方式运行。 +实际物理部署上，控制面可以选择部署在单个 AZ，简单灵活；也可以选择部署在多个不同 AZ，提供更高的可用性保证；也可以复用某个数据面集群，以更低成本的方式运行。 ## 环境准备 -准备 K8s 集群，并准备部署 KubeBlocks 所需的配置信息。本文示例准备了三个 data plane 集群，context 分别命名为：k8s-1、k8s-2、k8s-3。 +准备 K8s 集群，并准备部署 KubeBlocks 所需的配置信息。本文示例准备了三个数据面集群，context 分别命名为：`k8s-1`、`k8s-2`、`k8s-3`。 -* 准备 K8s 集群：1 个设定为 control plane，其他几个设定为 data plane，确保这些 data plane 集群的 API server 在 control plane 集群中可以联通。这里的联通包含两个层面：一是网络连通，二是访问配置。 -* 准备 KubeBlocks operator 访问 data plane 所需的配置信息，以 secret 形式放置在 control plane 集群当中，部署 KubeBlocks operator 时需要传入。其中，secret key 要求为 “kubeconfig”，value 为标准 kubeconfig 内容格式。示例如下： +* 准备 K8s 集群：1 个设定为控制面，其他几个设定为数据面，确保这些数据面集群的 API server 在控制面集群中可以联通。这里的联通包含两个层面：一是网络连通，二是访问配置。 +* 准备 KubeBlocks 访问数据面所需的配置信息，以 secret 形式放置在控制面集群当中，部署 KubeBlocks 时需要传入。其中，secret key 要求为 “kubeconfig”，value 为标准 kubeconfig 内容格式。示例如下： - ```bash + ```yaml apiVersion: v1 kind: Secret metadata: @@ -43,15 +43,15 @@ KubeBlocks 支持管理多个 Kubernetes 集群，为用户在实例容灾、k8s ## 部署多 K8s 集群 -### 部署 Kubeblocks operator +### 部署 Kubeblocks -在 control plane 安装 KubeBlocks。 +在控制面安装 KubeBlocks。 -1. 安装 KubeBlocks. +1. 安装 KubeBlocks。 ```bash - # multiCluster.kubeConfig 指定存放 data plane k8s kubeconfig 信息的 secret - # multiCluster.contexts 指定 data plane K8s contexts + # multiCluster.kubeConfig 指定存放数据面 k8s kubeconfig 信息的 secret + # multiCluster.contexts 指定数据面 K8s contexts kbcli kubeblocks install --version=0.9.0 --set multiCluster.kubeConfig= --set multiCluster.contexts= ``` @@ -59,19 +59,27 @@ KubeBlocks 支持管理多个 Kubernetes 集群，为用户在实例容灾、k8s ```bash kbcli kubeblocks status + > + KubeBlocks is deployed in namespace: kb-system,version: 0.9.0 + + KubeBlocks Workloads: + NAMESPACE KIND NAME READY PODS CPU(CORES) MEMORY(BYTES) CREATED-AT + kb-system Deployment kb-addon-snapshot-controller 1/1 N/A N/A Oct 25,2024 15:18 UTC+0800 + kb-system Deployment kubeblocks 1/1 N/A N/A Oct 25,2024 15:18 UTC+0800 + kb-system Deployment kubeblocks-dataprotection 1/1 N/A N/A Oct 25,2024 15:18 UTC+0800 ``` ### RBAC -实例 workload 在 data plane 中运行时，需要特定的 RBAC 资源进行管理动作，因此需要预先在各 data plane 集群单独安装 KubeBlocks 所需的 RBAC 资源。 +实例工作负载在数据面中运行时，需要特定的 RBAC 资源进行管理动作，因此需要预先在各数据面集群单独安装 KubeBlocks 所需的 RBAC 资源。 ```bash -# 1. 从 control plane dump 所需的 clusterrole 资源：kubeblocks-cluster-pod-role +# 1. 从控制面 dump 所需的 clusterrole 资源：kubeblocks-cluster-pod-role kubectl get clusterrole kubeblocks-cluster-pod-role -o yaml > /tmp/kubeblocks-cluster-pod-role.yaml # 2. 编辑文件内容，去除不必要的 meta 信息（比如 UID、resource version），保留其他内容 -# 3. Apply 文件内容到其他 data plane 集群 +# 3. 将文件内容应用到其他数据面集群 kubectl apply -f /tmp/kubeblocks-cluster-pod-role.yaml --context=k8s-1 kubectl apply -f /tmp/kubeblocks-cluster-pod-role.yaml --context=k8s-2 kubectl apply -f /tmp/kubeblocks-cluster-pod-role.yaml --context=k8s-3 @@ -91,9 +99,9 @@ KubeBlocks 基于 K8s service 抽象来提供内外部的服务访问。对于 s ##### 自建方案 -东西向互访的自建方案以 Cillium Cluster Mesh 为例来进行说明，Cillium 的部署选择 overlay 模式，各 data plane 集群配置如下： +东西向互访的自建方案以 Cillium Cluster Mesh 为例来进行说明，Cillium 的部署选择 overlay 模式，各数据面集群配置如下： -| Cluster | Context | Name | ID | CIDR | +| 集群 | Context | 名称 | ID | CIDR | |:-------:|:-------:|:-----:|:--:|:-----------:| | 1 | k8s-1 | k8s-1 | 1 | 10.1.0.0/16 | | 2 | k8s-2 | k8s-2 | 2 | 10.2.0.0/16 | @@ -109,7 +117,7 @@ KubeBlocks 基于 K8s service 抽象来提供内外部的服务访问。对于 s 下述操作步骤相关命令，可以在各个集群分别执行（不需要指定 `--context` 参数），也可以在有三个 context 信息的环境里统一执行（分别指定 `--context` 参数）。 -1. 安装 cilium，指定 cluster ID/name 和 cluster pool pod CIDR。可参考官方文档：[Specify the Cluster Name and ID](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#specify-the-cluster-name-and-id)。 +1. 安装 Cilium，指定集群 ID/名称和 Pool Pod CIDR。可参考官方文档：[指定集群名称和 ID](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#specify-the-cluster-name-and-id)。 ```bash cilium install --set cluster.name=k8s-1 --set cluster.id=1 --set ipam.operator.clusterPoolIPv4PodCIDRList=10.1.0.0/16 —context k8s-1 @@ -117,7 +125,7 @@ KubeBlocks 基于 K8s service 抽象来提供内外部的服务访问。对于 s cilium install --set cluster.name=k8s-3 --set cluster.id=3 --set ipam.operator.clusterPoolIPv4PodCIDRList=10.3.0.0/16 —context k8s-3 ``` -2. 开启 Cilium Cluster Mesh，并等待其状态为 ready。这里以 NodePort 方式提供对 cluster mesh control plane 的访问，其他可选方式及具体信息请参考官方文档：[Enable Cluster Mesh](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#enable-cluster-mesh)。 +2. 开启 Cilium Cluster Mesh，并等待其状态为 `ready`。这里以 NodePort 方式提供对 Cluster Mesh 控制面的访问，其他可选方式及具体信息请参考官方文档：[启用 Cluster Mesh](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#enable-cluster-mesh)。 ```bash cilium clustermesh enable --service-type NodePort —context k8s-1 @@ -128,7 +136,7 @@ KubeBlocks 基于 K8s service 抽象来提供内外部的服务访问。对于 s cilium clustermesh status —wait —context k8s-3 ``` -3. 打通各集群，并等待集群状态为 ready。具体可参考官方文档：[Connect Clusters](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#connect-clusters)。 +3. 打通各集群，并等待集群状态为 `ready`。具体可参考官方文档：[连接集群](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#connect-clusters)。 ```bash cilium clustermesh connect --context k8s-1 --destination-context k8s-2 @@ -145,38 +153,38 @@ KubeBlocks 基于 K8s service 抽象来提供内外部的服务访问。对于 s cilium-dbg bpf tunnel list ``` -5. （可选）集群连通性测试，可参考官方文档：[Test Pod Connectivity Between Clusters](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#test-pod-connectivity-between-clusters)。 +5. （可选）集群连通性测试，可参考官方文档：[测试集群间 Pod 连通性](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#test-pod-connectivity-between-clusters)。 #### 南北向流量 -南北向流量为客户端提供服务，需要每个 data plane 的 Pod 都有对外的连接地址，这个地址的实现可以是 NodePort、LoadBalancer 或者其他方案，我们以 NodePort 和 LoadBalancer 为例介绍。 +南北向流量为客户端提供服务，需要每个数据面的 Pod 都有对外的连接地址，这个地址的实现可以是 NodePort、LoadBalancer 或者其他方案，我们以 NodePort 和 LoadBalancer 为例介绍。 如果客户端不具备读写路由能力，那在 Pod 地址之上，还需要提供读写分离地址，实现上可以用七层的 Proxy，四层的 SDN VIP，或者纯粹的 DNS。为了简化问题，此处先假设客户端具备读写路由能力，可以直接配置所有 Pod 连接地址。 ##### NodePort -为每个 data plane 集群的 Pod 创建 NodePort Service，客户端使用用主机网络 IP 和 NodePort 即可连接。 +为每个数据面集群的 Pod 创建 NodePort Service，客户端使用用主机网络 IP 和 NodePort 即可连接。 ##### LoadBalancer 此处以 MetalLB 提供 LoadBalancer Service 为例。 -1. 准备 data plane 的 LB 网段，该网段需要跟客户端路由可达，并且不同 K8s 集群要错开 +1. 准备数据面的 LB 网段，该网段需要跟客户端路由可达，并且不同 K8s 集群要错开。 - | Cluster | Context | Name | ID | CIDR | + | 集群 | Context | 名称 | ID | CIDR | |:-------:|:-------:|:-----:|:--:|:-----------:| | 1 | k8s-1 | k8s-1 | 1 | 10.4.0.0/16 | | 2 | k8s-2 | k8s-2 | 2 | 10.5.0.0/16 | | 3 | k8s-3 | k8s-3 | 3 | 10.6.0.0/16 | -2. 在所有 data plane 部署 MetalLB。 +2. 在所有数据面部署 MetalLB。 ```bash helm repo add metallb https://metallb.github.io/metallb helm install metallb metallb/metallb ``` -3. 等待相关 Pod 状态变为 ready。 +3. 等待相关 Pod 状态变为 `ready`。 ```bash kubectl wait --namespace metallb-system --for=condition=ready pod --selector=app=metallb --timeout=90s @@ -201,7 +209,7 @@ KubeBlocks 基于 K8s service 抽象来提供内外部的服务访问。对于 s namespace: metallb-system ``` -5. 为每个data plane 集群的 Pod 创建 LoadBalancer Service，拿到所有 VIP，即可供客户端连接。 +5. 为每个数据面集群的 Pod 创建 LoadBalancer Service，拿到所有 VIP，即可供客户端连接。 ## 验证 diff --git a/i18n/zh-cn/user-docs/maintenance/in-place-update/ignore-vertical-scale.md b/i18n/zh-cn/user-docs/maintenance/in-place-update/ignore-vertical-scale.md index 2c8237e8484..76586b1feb2 100644 --- a/i18n/zh-cn/user-docs/maintenance/in-place-update/ignore-vertical-scale.md +++ b/i18n/zh-cn/user-docs/maintenance/in-place-update/ignore-vertical-scale.md @@ -10,4 +10,4 @@ sidebar_label: 启用原地更新 Resources 的原地更新一直以来有比较强的需求，在低于 1.27 版本的 Kubernetes 中，我们可以看到很多 Kubernetes 的发行版中支持了 Resources 的原地更新能力，不同的发行版可能采用了不同的方案去实现这一特性。 -为了兼容这些 Kubernetes 发行版，KubeBlocks 中增加了 `IgnorePodVerticalScaling` 特性开关。当该特性打开后，KubeBlocks 在做实例更新时，会忽略 Resources 中 CPU 和 Memory 的更新，从而使得最终渲染的 Pod 的 Resources 跟当前在运行 Pod 的 Resources 配置保持一致。\ +为了兼容这些 Kubernetes 发行版，KubeBlocks 中增加了 `IgnorePodVerticalScaling` 特性开关。当该特性打开后，KubeBlocks 在做实例更新时，会忽略 Resources 中 CPU 和 Memory 的更新，从而使得最终渲染的 Pod 的 Resources 跟当前在运行 Pod 的 Resources 配置保持一致。 diff --git a/i18n/zh-cn/user-docs/maintenance/resource-scheduling/resource-scheduling.md b/i18n/zh-cn/user-docs/maintenance/resource-scheduling/resource-scheduling.md index 9c99b0dc8f2..1eab6591d43 100644 --- a/i18n/zh-cn/user-docs/maintenance/resource-scheduling/resource-scheduling.md +++ b/i18n/zh-cn/user-docs/maintenance/resource-scheduling/resource-scheduling.md @@ -129,7 +129,7 @@ spec: ### 尽量打散 -如果你希望集群的 Pod 部署在不同的拓扑域，但是不希望在节点资源充足的时候，因为不满足分布条件而部署失败，那么可以配置尽量打散，可以将 Pod 亲和性配置为“Preferred”。 +如果你希望集群的 Pod 部署在不同的拓扑域，但是不希望在节点资源充足的时候，因为不满足分布条件而部署失败，那么可以配置尽量打散，可以将 Pod 亲和性配置为 “Preferred”。 下面的示例创建了一个尽可能跨节点的集群。 @@ -157,7 +157,7 @@ spec: ### 强制打散 -如果集群的 Pod 必须部署在不同的拓扑域，以确保集群能够跨拓扑域具备容灾能力，你可以将 Pod 亲和性配置为“Required”。 +如果集群的 Pod 必须部署在不同的拓扑域，以确保集群能够跨拓扑域具备容灾能力，你可以将 Pod 亲和性配置为 “Required”。 下面的示例创建了一个必须跨节点部署的集群。 @@ -251,7 +251,7 @@ spec: ### 集群 Pod 独占一个节点 -如果需要一个仅用于线上核心业务的集群，并且需要确保该集群的每个 Pod 都有自己的节点以避免受到集群中其他 Pod 的影响，你可以将 `tenancy` 设置为“DedicatedNode”。 +如果需要一个仅用于线上核心业务的集群，并且需要确保该集群的每个 Pod 都有自己的节点以避免受到集群中其他 Pod 的影响，你可以将 `tenancy` 设置为 “DedicatedNode”。 diff --git a/i18n/zh-cn/user-docs/observability/configure-alert.md b/i18n/zh-cn/user-docs/observability/configure-alert.md index 2c73a0d7fa3..64dc592c722 100644 --- a/i18n/zh-cn/user-docs/observability/configure-alert.md +++ b/i18n/zh-cn/user-docs/observability/configure-alert.md @@ -7,7 +7,7 @@ sidebar_position: 2 # 配置告警 -告警主要用于日常故障响应，以提高系统的可用性。KubeBlocks 内置了一组通用的告警规则，并集成了多个通知渠道，可满足生产级线上集群的运维需求。 +告警主要用于日常故障响应，以提高系统可用性。KubeBlocks 使用开源版本的 Prometheus 配置警报规则和多个通知渠道。KubeBlocks 的告警功能能够满足生产级在线集群的运维需求。 :::note @@ -17,7 +17,7 @@ sidebar_position: 2 ## 告警规则 -KubeBlocks 内置的告警系统可以满足各种数据产品的需求，并提供了开箱即用的体验，无需进一步配置。这些告警规则为集群运维提供了最佳实践，通过经验总结的平滑窗口、告警阈值、告警级别和告警指标，进一步提高了告警的准确性，降低了误报率和漏报率。 +KubeBlocks 使用开源版本的 Prometheus 来满足各种数据产品的需求。这些警报规则提供了集群运维的最佳实践，通过经验总结的平滑窗口、告警阈值、告警级别和告警指标，进一步提高了告警的准确性，降低了误报率和漏报率。 以 PostgreSQL 为例，告警规则中内置了常见的异常事件，例如实例宕机、实例重启、慢查询、连接数、死锁和缓存命中率等。 diff --git a/i18n/zh-cn/user-docs/observability/monitor-database.md b/i18n/zh-cn/user-docs/observability/monitor-database.md index 6fbe3497908..650514177f9 100644 --- a/i18n/zh-cn/user-docs/observability/monitor-database.md +++ b/i18n/zh-cn/user-docs/observability/monitor-database.md @@ -14,7 +14,7 @@ KubeBlocks 提供了强大的可观测性能力。您可以实时观察数据库 ## Playground/演示场景 -KubeBlocks 以 Addon 形式集成了许多开源监控组件，如 Prometheus、AlertManager 和 Grafana，并采用定制的 `apecloud-otel-collector` 组件收集数据库和宿主机的监控指标。您可以在测试或演示环境中使用以下监控引擎。 +KubeBlocks 以插件（Addon）形式集成了许多开源监控组件，如 Prometheus、AlertManager 和 Grafana，并采用定制的 `apecloud-otel-collector` 组件收集数据库和宿主机的监控指标。您可以在测试或演示环境中使用以下监控引擎。 - `prometheus`：包括 Prometheus 和 AlertManager 两个监控组件。 - `grafana`：包括 Grafana 的监控组件。 diff --git a/i18n/zh-cn/user-docs/overview/database-engines-supported.md b/i18n/zh-cn/user-docs/overview/database-engines-supported.md index e69bd1eca4c..5a79e172506 100644 --- a/i18n/zh-cn/user-docs/overview/database-engines-supported.md +++ b/i18n/zh-cn/user-docs/overview/database-engines-supported.md @@ -78,11 +78,12 @@ MySQL 和 PostgreSQL 是两大最受欢迎的开源关系型数据库，有诸 **功能列表** -| 引擎（v0.9.0） | 已支持的版本 | 变配 | 水平伸缩 | 磁盘扩容 | 停止/启动集群 | 重启集群 | 服务暴露 | 备份恢复 | 日志 | 配置 | 升级（数据库引擎版本） | 账号管理 | 故障恢复 | Switchover | 监控 |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:----------------:|:----------------:|:------------:|:----------------:|:----------------:|:------:|:--------------:|:----:|:------:|:---------------------------:|:-------:|:--------:|:----------:|:-------:| -| mongodb |

4.0.28

4.2.24

4.4.29

5.0.28

6.0.16

7.0.12

| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | N/A | N/A | ✔️ | ✔️ | ✔️ | -| redis |

redis-7.0.6

redis-7.2.4

redis-cluster-7.0.6

redis-cluster-7.2.4

redis-sentinel-7.0.6

redis-sentinel-7.2.4

redis-twemproxy-0.5.0

| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | N/A | ✔️ | ✔️ | N/A | ✔️ | -| etcd |

3.5.15

3.5.6

| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | -| zookeeper |

3.4.14

3.6.4

3.7.2

3.8.4

3.9.2

| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | N/A | N/A | ✔️ | ✔️ | N/A | N/A | N/A | N/A | N/A | +| 引擎（v0.9.0） | 已支持的版本 | 变配 | 水平伸缩 | 磁盘扩容 | 停止/启动集群 | 重启集群 | 服务暴露 | 备份恢复 | 日志 | 配置 | 升级（数据库引擎版本） | 账号管理 | 故障恢复 | Switchover | 监控 | +|:-------------------:|:----------------------------:|:-------------:|:-----------------:|:-------:|:-----------:|:----------------:|:------:|:-------:|:----:|:----:|:----------------:|:-------:|:------:|:----------:|:----:| +| mongodb |

4.0.28

4.2.24

4.4.29

5.0.28

6.0.16

7.0.12

| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | N/A | N/A | ✔️ | ✔️ | ✔️ | +| redis |

redis-7.0.6

redis-7.2.4

redis-cluster-7.0.6

redis-cluster-7.2.4

redis-sentinel-7.0.6

redis-sentinel-7.2.4

redis-twemproxy-0.5.0

| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | N/A | ✔️ | ✔️ | N/A | ✔️ | +| etcd |

3.5.15

3.5.6

| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | +| zookeeper |

3.4.14

3.6.4

3.7.2

3.8.4

3.9.2

| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | N/A | N/A | ✔️ | ✔️ | N/A | N/A | N/A | N/A | N/A | ## OLAP 系统 diff --git a/i18n/zh-cn/user-docs/overview/kubernetes_and_operator_101.md b/i18n/zh-cn/user-docs/overview/kubernetes_and_operator_101.md index 93865d3b8e7..384dfac74bb 100644 --- a/i18n/zh-cn/user-docs/overview/kubernetes_and_operator_101.md +++ b/i18n/zh-cn/user-docs/overview/kubernetes_and_operator_101.md @@ -1,6 +1,6 @@ --- -title: Kubernetes and Operator 101 -description: things about K8s you need to know +title: Kubernetes 及 Operator 入门 +description: K8s 入门知识 keywords: [K8s, operator, concept] sidebar_position: 3 --- From 070c50e99acc24c0c54d09651f957dfb33bdd169 Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Thu, 31 Oct 2024 12:12:28 +0800 Subject: [PATCH 03/11] docs: update docs --- .../user-docs/maintenance/cross-k8s-deployment/_category_.yaml | 2 +- i18n/zh-cn/user-docs/overview/kubernetes_and_operator_101.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/_category_.yaml b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/_category_.yaml index 4d27cb3ecc0..58d2c4722b1 100644 --- a/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/_category_.yaml +++ b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/_category_.yaml @@ -1,4 +1,4 @@ position: 5 -label: 多 k8s 部署 +label: 多 K8s 部署 collapsible: true collapsed: true \ No newline at end of file diff --git a/i18n/zh-cn/user-docs/overview/kubernetes_and_operator_101.md b/i18n/zh-cn/user-docs/overview/kubernetes_and_operator_101.md index 384dfac74bb..13891535bc5 100644 --- a/i18n/zh-cn/user-docs/overview/kubernetes_and_operator_101.md +++ b/i18n/zh-cn/user-docs/overview/kubernetes_and_operator_101.md @@ -1,7 +1,7 @@ --- title: Kubernetes 及 Operator 入门 description: K8s 入门知识 -keywords: [K8s, operator, concept] +keywords: [K8s, operator, 概念] sidebar_position: 3 --- From ee9f50e4aa859ef28201f621934a87b10a7ebaba Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Thu, 31 Oct 2024 13:47:23 +0800 Subject: [PATCH 04/11] docs: update docs --- .../connect-to-database-in-production-environment.md | 4 ++-- .../connect-to-database-in-testing-environment.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md index 5a3284534af..d7ad9a11fb2 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md @@ -23,7 +23,7 @@ import TabItem from '@theme/TabItem'; ## 场景 1. 连接在同一个 Kubernetes 集群中的客户端 -你可以使用数据库的 ClusterIP 或域名进行连接。 +您可以使用数据库的 ClusterIP 或域名进行连接。 @@ -72,7 +72,7 @@ kubectl get service mycluster-mysql ## 场景 2. 连接在 Kubernetes 集群之外但与 Kubernetes 集群位于同一 VPC 中的客户 -使用一个稳定的域名以实现长期连接。你可以使用云厂商提供的内部负载均衡器来实现这一目的。 +使用一个稳定的域名以实现长期连接。您可以使用云厂商提供的内部负载均衡器来实现这一目的。 :::note diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md index 755dc213aa2..fc24e63f697 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md @@ -17,7 +17,7 @@ import TabItem from '@theme/TabItem'; ## 方案 1. 使用 kbcli cluster connect 命令 -你可以使用 `kbcli cluster connect` 命令并指定要连接的集群名称。 +您可以使用 `kbcli cluster connect` 命令并指定要连接的集群名称。 ```bash kbcli cluster connect ${cluster-name} @@ -53,7 +53,7 @@ kbcli cluster connect --show-example --show-password ${cluster-name} ## 步骤 1. 获取数据库凭证 -在连接运行在 Kubernetes 集群内的 MySQL 数据库之前，您需要从 Kubernetes Secret 中获取用户名和密码。Kubernetes 中的 Secret 通常是经过 base64 编码的，因此您需要将其解码以获得实际的凭据。以下是使用 kubectl 获取凭据的方法。 +在连接运行在 Kubernetes 集群内的 MySQL 数据库之前，您需要从 Kubernetes Secret 中获取用户名和密码。Kubernetes 中的 Secret 通常是经过 base64 编码的，因此您需要将其解码以获得实际的凭据。以下是使用 kubectl 获取凭证的方法。 1. 获取 `username`。 From 51a162c2a58e59e2ec4f5554f28992a9279348e0 Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Mon, 4 Nov 2024 16:17:25 +0800 Subject: [PATCH 05/11] docs: fix bugs --- ...nect-database-in-production-environment.md | 38 +++++++++-------- ...connect-database-in-testing-environment.md | 6 +-- .../backup-and-restore/backup/backup-repo.md | 2 +- .../cross-k8s-deployment.md | 6 +-- .../cross-k8s-deployment.md | 2 +- ...t-to-database-in-production-environment.md | 42 +++++++++++-------- ...nect-to-database-in-testing-environment.md | 8 ++-- .../backup-and-restore/backup/backup-repo.md | 2 +- .../cross-k8s-deployment.md | 2 +- .../observability/monitor-database.md | 2 +- 10 files changed, 59 insertions(+), 51 deletions(-) diff --git a/docs/user_docs/connect_database/connect-database-in-production-environment.md b/docs/user_docs/connect_database/connect-database-in-production-environment.md index d602aa69560..90ce7cd78e7 100644 --- a/docs/user_docs/connect_database/connect-database-in-production-environment.md +++ b/docs/user_docs/connect_database/connect-database-in-production-environment.md @@ -88,6 +88,8 @@ kbcli cluster expose ${cluster-name} --type vpc --enable=true +This example uses a MySQL cluster to demonstrate how to expose a public access address on Alibaba Cloud. + ```yaml kubectl apply -f - < - ## Scenario 3. Connect database with clients in other VPCs or public networks -You can enable the External LoadBalancer of the cloud vendor. +If the client is in a different VPC and requires public access, you can enable the cloud vendor's External LoadBalancer. :::note @@ -177,32 +178,33 @@ kbcli cluster expose ${cluster-name} --type internet --enable=true +The example uses MySQL to demonstrate how to expose the VPC address on Alibaba Cloud. + ```yaml kubectl apply -f - < - To disable the LoadBalancer instance, execute the following command. @@ -220,14 +222,14 @@ kubectl apply -f - < root ``` @@ -70,7 +70,7 @@ Before connecting to the MySQL database running inside your Kubernetes cluster, 2. Retrieve the `password`: ```bash - kubectl get secrets -n demo mycluster-conn-credential -o jsonpath='{.data.\password}' | base64 -d + kubectl get secrets -n demo mycluster-conn-credential -o jsonpath='{.data.password}' | base64 -d > 2gvztbvz ``` @@ -109,7 +109,7 @@ In some cases, you may need to connect directly to a MySQL database running insi kubectl exec -ti -n demo mycluster-mysql-0 -- bash ``` - - `-ti`: Opens an interactive terminal session (-t allocates a pseudo-TTY, and -i keeps the session open). + - `-ti`: Opens an interactive terminal session (-t allocates a TTY, and -i passes stdin to the container). - `-n demo`: Specifies the demo namespace where your Pod is running. - `mycluster-mysql-0`: The name of the MySQL Pod. Make sure to replace this with the actual Pod name if it's different. - `-- bash`: Opens a Bash shell inside the Pod. You can also use sh if Bash is not available in the container. diff --git a/docs/user_docs/maintenance/backup-and-restore/backup/backup-repo.md b/docs/user_docs/maintenance/backup-and-restore/backup/backup-repo.md index dac3b814fe5..43322cd7253 100644 --- a/docs/user_docs/maintenance/backup-and-restore/backup/backup-repo.md +++ b/docs/user_docs/maintenance/backup-and-restore/backup/backup-repo.md @@ -499,7 +499,7 @@ If you do not configure the BackupRepo information when installing KubeBlocks, y annotations: dataprotection.kubeblocks.io/is-default-repo: "true" spec: - storageProviderRef: gcs + storageProviderRef: gcs-s3comp accessMethod: Tool pvReclaimPolicy: Retain volumeCapacity: 100Gi diff --git a/docs/user_docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md b/docs/user_docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md index da49171229c..ca7cf22bf0a 100644 --- a/docs/user_docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md +++ b/docs/user_docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md @@ -91,7 +91,7 @@ The K8s services provided by the cloud providers include both internal and exter ##### For the self-host environment -This tutorial takes Cillium Cluster Mesh as an example. Deploy Cillium as the overlay mode and the cluster configuration for each data plane clusters is as follows: +This tutorial takes Cilium Cluster Mesh as an example. Deploy Cilium as the overlay mode and the cluster configuration for each data plane clusters is as follows: | Cluster | Context | Name | ID | CIDR | |:-------:|:-------:|:-----:|:--:|:-----------:| @@ -109,7 +109,7 @@ The CIDR mentioned here refers to the address of the Cilium Overlay network. Whe The following steps can be performed separately in each cluster (without the `--context` parameter) or collectively in an environment with the information of three contexts (by specifying the `--context` parameter for each). -1. Install Cilium, specifying the cluster ID/name and the cluster pool pod CIDR. Refer to the Cillium doc for details: [Specify the Cluster Name and ID](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#specify-the-cluster-name-and-id). +1. Install Cilium, specifying the cluster ID/name and the cluster pool pod CIDR. Refer to the Cilium doc for details: [Specify the Cluster Name and ID](https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/#specify-the-cluster-name-and-id). ```bash cilium install --set cluster.name=k8s-1 --set cluster.id=1 --set ipam.operator.clusterPoolIPv4PodCIDRList=10.1.0.0/16 —context k8s-1 @@ -139,7 +139,7 @@ The following steps can be performed separately in each cluster (without the `-- cilium clustermesh status —wait —context k8s-3 ``` -4. (Optional) Check the status of the tunnels between cluster by using the cilliun-dbg tool. Refer to [the official doc](https://docs.cilium.io/en/stable/cmdref/cilium-dbg/) for details. +4. (Optional) Check the status of the tunnels between cluster by using the ciliun-dbg tool. Refer to [the official doc](https://docs.cilium.io/en/stable/cmdref/cilium-dbg/) for details. ```bash cilium-dbg bpf tunnel list diff --git a/i18n/zh-cn/api-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md b/i18n/zh-cn/api-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md index 7320387b964..c9e8fd1a138 100644 --- a/i18n/zh-cn/api-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md +++ b/i18n/zh-cn/api-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md @@ -91,7 +91,7 @@ KubeBlocks 基于 K8s service 抽象来提供内外部的服务访问。对于 s ##### 自建方案 -东西向互访的自建方案以 Cillium Cluster Mesh 为例来进行说明，Cillium 的部署选择 overlay 模式，各 data plane 集群配置如下： +东西向互访的自建方案以 Cilium Cluster Mesh 为例来进行说明，Cilium 的部署选择 overlay 模式，各 data plane 集群配置如下： | Cluster | Context | Name | ID | CIDR | |:-------:|:-------:|:-----:|:--:|:-----------:| diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md index d7ad9a11fb2..e3790fef528 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md @@ -23,6 +23,8 @@ import TabItem from '@theme/TabItem'; ## 场景 1. 连接在同一个 Kubernetes 集群中的客户端 +客户端和数据库在同一个 Kubernetes 集群内运行，客户端可以通过数据库 Endpoint 获取域名进行访问。 + 您可以使用数据库的 ClusterIP 或域名进行连接。 @@ -92,6 +94,8 @@ kbcli cluster expose ${cluster-name} --type vpc --enable=true +此处以 MySQL 集群为例，在阿里云上为集群暴露公网访问地址的方式如下： + ```bash kubectl apply -f - < + + + +客户端和数据库在不同的 VPC 中，需要走公网访问，您可使用云厂商的外部负载均衡器，开启方法如下： :::note @@ -174,18 +182,16 @@ EOF ::: - - - - ```bash -kbcli cluster expose ${cluster-name} --type vpc --enable=true +kbcli cluster expose ${cluster-name} --type internet --enable=true ``` +以 MySQL 集群为例，在阿里云上为集群暴露 VPC 访问地址的方式如下： + ```bash kubectl apply -f - < @@ -244,7 +250,7 @@ spec: - componentName: mysql services: - annotations: - service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet ipFamilyPolicy: PreferDualStack name: vpc serviceType: LoadBalancer diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md index fc24e63f697..99456b1e757 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-testing-environment.md @@ -60,7 +60,7 @@ kbcli cluster connect --show-example --show-password ${cluster-name} 使用 `kubectl get secrects` 命令，从 demo 命名空间中名为 `mycluster-conn-credential` 的 secret 中提取用户名。 ```bash - kubectl get secrets -n demo mycluster-conn-credential -o jsonpath='{.data.\username}' | base64 -d + kubectl get secrets -n demo mycluster-conn-credential -o jsonpath='{.data.username}' | base64 -d > root ``` @@ -71,7 +71,7 @@ kbcli cluster connect --show-example --show-password ${cluster-name} 2. 获取 `password`。 ```bash - kubectl get secrets -n demo mycluster-conn-credential -o jsonpath='{.data.\password}' | base64 -d + kubectl get secrets -n demo mycluster-conn-credential -o jsonpath='{.data.password}' | base64 -d > 2gvztbvz ``` @@ -108,10 +108,10 @@ kubectl get secrets -n demo | grep mycluster kubectl exec -ti -n demo mycluster-mysql-0 -- bash ``` - - `-ti`：打开交互式终端会话（`-t` 分配一个伪 TTY，`-i` 保持会话打开）。 + - `-ti`：打开交互式终端会话（`-t` 分配一个 TTY，`-i` 将伪 TTY 传输给容器）。 - `-n demo`：指定 Pod 所在的命名空间 demo。 - `mycluster-mysql-0`：MySQL Pod 的名称。如果名称与您的实际情况不同，请确保替换为实际的 Pod 名称。 - - `--bash`：在 Pod 内打开一个 Bash shell。如果容器中没有 Bash，也可以使用 sh。 + - `-- bash`：在 Pod 内打开一个 Bash shell。如果容器中没有 Bash，也可以使用 sh。 2. 连接集群。 diff --git a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md index b3e0d7185c4..6c781d86746 100644 --- a/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md +++ b/i18n/zh-cn/user-docs/maintenance/backup-and-restore/backup/backup-repo.md @@ -502,7 +502,7 @@ BackupRepo 是备份数据的存储仓库，支持配置 OSS（阿里云对象 annotations: dataprotection.kubeblocks.io/is-default-repo: "true" spec: - storageProviderRef: gcs + storageProviderRef: gcs-s3comp accessMethod: Tool pvReclaimPolicy: Retain volumeCapacity: 100Gi diff --git a/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md index 5e3bc7ed4f1..10a79c5df7b 100644 --- a/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md +++ b/i18n/zh-cn/user-docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md @@ -99,7 +99,7 @@ KubeBlocks 基于 K8s service 抽象来提供内外部的服务访问。对于 s ##### 自建方案 -东西向互访的自建方案以 Cillium Cluster Mesh 为例来进行说明，Cillium 的部署选择 overlay 模式，各数据面集群配置如下： +东西向互访的自建方案以 Cilium Cluster Mesh 为例来进行说明，Cilium 的部署选择 overlay 模式，各数据面集群配置如下： | 集群 | Context | 名称 | ID | CIDR | |:-------:|:-------:|:-----:|:--:|:-----------:| diff --git a/i18n/zh-cn/user-docs/observability/monitor-database.md b/i18n/zh-cn/user-docs/observability/monitor-database.md index 650514177f9..120adc69042 100644 --- a/i18n/zh-cn/user-docs/observability/monitor-database.md +++ b/i18n/zh-cn/user-docs/observability/monitor-database.md @@ -281,7 +281,7 @@ kubectl patch cluster mycluster -n namespace --type "json" -p '[{"op":"add","pat 远程写为可选操作，您可根据实际需要开启。 -KubeBlocks 支持 victoria-metrics-agent 引擎，支持用户将数据远程写入虚拟机中，相较于 Prometheus 原生应用，[vmagent](https://docs.victoriametrics.com/vmagent.html) 更轻量。 +KubeBlocks 支持 victoria-metrics-agent 引擎，支持用户将数据远程写入 VictoriaMetrics 中，相较于 Prometheus 原生应用，[vmagent](https://docs.victoriametrics.com/vmagent.html) 更轻量。 From 10084d67ae422c01e076a3563bf68a77a052bbfa Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Mon, 4 Nov 2024 17:02:23 +0800 Subject: [PATCH 06/11] docs: fix bugs --- .../maintenance/cross-k8s-deployment/cross-k8s-deployment.md | 2 +- .../connect-to-database-in-production-environment.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user_docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md b/docs/user_docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md index ca7cf22bf0a..b70a0c489dd 100644 --- a/docs/user_docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md +++ b/docs/user_docs/maintenance/cross-k8s-deployment/cross-k8s-deployment.md @@ -139,7 +139,7 @@ The following steps can be performed separately in each cluster (without the `-- cilium clustermesh status —wait —context k8s-3 ``` -4. (Optional) Check the status of the tunnels between cluster by using the ciliun-dbg tool. Refer to [the official doc](https://docs.cilium.io/en/stable/cmdref/cilium-dbg/) for details. +4. (Optional) Check the status of the tunnels between cluster by using the cilium-dbg tool. Refer to [the official doc](https://docs.cilium.io/en/stable/cmdref/cilium-dbg/) for details. ```bash cilium-dbg bpf tunnel list diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md index e3790fef528..68fa1799494 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md @@ -108,7 +108,7 @@ spec: - componentName: mysql services: - annotations: - service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet ipFamilyPolicy: PreferDualStack name: vpc serviceType: LoadBalancer From 610e5d023faf80bd51d448a5d3e76007d02bf9b0 Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Mon, 4 Nov 2024 17:25:26 +0800 Subject: [PATCH 07/11] docs: update docs --- .../connect-database-in-production-environment.md | 8 ++++---- .../connect-to-database-in-production-environment.md | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/user_docs/connect_database/connect-database-in-production-environment.md b/docs/user_docs/connect_database/connect-database-in-production-environment.md index 90ce7cd78e7..ecea9460e79 100644 --- a/docs/user_docs/connect_database/connect-database-in-production-environment.md +++ b/docs/user_docs/connect_database/connect-database-in-production-environment.md @@ -102,7 +102,7 @@ spec: - componentName: mysql services: - annotations: - service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet ipFamilyPolicy: PreferDualStack name: vpc serviceType: LoadBalancer @@ -145,7 +145,7 @@ spec: - componentName: mysql services: - annotations: - service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet ipFamilyPolicy: PreferDualStack name: vpc serviceType: LoadBalancer @@ -192,7 +192,7 @@ spec: - componentName: mysql services: - annotations: - service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet ipFamilyPolicy: PreferDualStack name: vpc serviceType: LoadBalancer @@ -229,7 +229,7 @@ spec: - componentName: mysql services: - annotations: - service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet ipFamilyPolicy: PreferDualStack name: vpc serviceType: LoadBalancer diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md index 68fa1799494..58a2f88a806 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md @@ -148,7 +148,7 @@ spec: - componentName: mysql services: - annotations: - service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet ipFamilyPolicy: PreferDualStack name: vpc serviceType: LoadBalancer @@ -204,7 +204,7 @@ spec: - componentName: mysql services: - annotations: - service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet ipFamilyPolicy: PreferDualStack name: vpc serviceType: LoadBalancer @@ -250,7 +250,7 @@ spec: - componentName: mysql services: - annotations: - service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intrernet ipFamilyPolicy: PreferDualStack name: vpc serviceType: LoadBalancer From 81042cfb808b6aa9646d71d49c518936ad85fe34 Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Mon, 4 Nov 2024 17:57:02 +0800 Subject: [PATCH 08/11] docs: update docs --- ...nect-database-in-production-environment.md | 20 +++++++++---------- ...t-to-database-in-production-environment.md | 20 +++++++++---------- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/user_docs/connect_database/connect-database-in-production-environment.md b/docs/user_docs/connect_database/connect-database-in-production-environment.md index ecea9460e79..8159317d4f5 100644 --- a/docs/user_docs/connect_database/connect-database-in-production-environment.md +++ b/docs/user_docs/connect_database/connect-database-in-production-environment.md @@ -14,7 +14,7 @@ import TabItem from '@theme/TabItem'; In the production environment, it is normal to connect a database with CLI and SDK clients. There are three scenarios. - Scenario 1: Client1 and the database are in the same Kubernetes cluster. To connect client1 and the database, see [Use ClusterIP](#scenario-1-connect-database-in-the-same-kubernetes-cluster). -- Scenario 2: Client2 is outside the Kubernetes cluster, but it is in the same VPC as the database. To connect client2 and the database, see [Expose VPC Private Address](#scenario-2-client-outside-the-kubernetes-cluster-but-in-the-same-vpc-as-the-kubernetes-cluster). +- Scenario 2: Client2 is outside the Kubernetes cluster, but it is in the same VPC as the database. To connect client2 and the database, see [Expose VPC Address](#scenario-2-client-outside-the-kubernetes-cluster-but-in-the-same-vpc-as-the-kubernetes-cluster). - Scenario 3: Client3 and the database are in different VPCs, such as other VPCs or the public network. To connect client3 and the database, see [Expose VPC Public Address](#scenario-3-connect-database-with-clients-in-other-vpcs-or-public-networks). See the figure below to get a clear image of the network location. @@ -88,14 +88,14 @@ kbcli cluster expose ${cluster-name} --type vpc --enable=true -This example uses a MySQL cluster to demonstrate how to expose a public access address on Alibaba Cloud. +This example uses a MySQL cluster to demonstrate how to expose a VPC address on Alibaba Cloud. ```yaml kubectl apply -f - < +s ```bash @@ -178,14 +178,14 @@ kbcli cluster expose ${cluster-name} --type internet --enable=true -The example uses MySQL to demonstrate how to expose the VPC address on Alibaba Cloud. +The example uses MySQL to demonstrate how to expose the public address on Alibaba Cloud. ```yaml kubectl apply -f - < -此处以 MySQL 集群为例，在阿里云上为集群暴露公网访问地址的方式如下： +此处以 MySQL 集群为例，在阿里云上为集群暴露 VPC 访问地址的方式如下： ```bash kubectl apply -f - < -以 MySQL 集群为例，在阿里云上为集群暴露 VPC 访问地址的方式如下： +以 MySQL 集群为例，在阿里云上为集群暴露公网访问地址的方式如下： ```bash kubectl apply -f - < ```bash -kbcli cluster expose ${cluster-name} --type vpc --enable=false +kbcli cluster expose ${cluster-name} --type internet --enable=false ``` @@ -243,16 +243,16 @@ kubectl apply -f - < Date: Mon, 4 Nov 2024 18:00:04 +0800 Subject: [PATCH 09/11] docs: update docs --- .../connect-to-database-in-production-environment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md index 3d2adc0e049..415b64ef410 100644 --- a/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md +++ b/i18n/zh-cn/user-docs/connect-databases/connect-to-database-in-production-environment.md @@ -14,7 +14,7 @@ import TabItem from '@theme/TabItem'; 在生产环境中，使用 CLI 和 SDK 客户端连接数据库是很常见的。主要有以下三种场景： - 场景 1：Client1 和数据库位于同一个 Kubernetes 集群中。如果要连接 Client1 和数据库，请参考[使用 ClusterIP 方案](#场景-1-连接在同一个-kubernetes-集群中的客户端)。 -- 场景 2：Client2 在 Kubernetes 集群之外，但与数据库位于同一个 VPC 中。如果要连接 Client2 和数据库，请参考[暴露 VPC 私有地址方案](#场景-2-连接在-kubernetes-集群之外但与-kubernetes-集群位于同一-vpc-中的客户)。 +- 场景 2：Client2 在 Kubernetes 集群之外，但与数据库位于同一个 VPC 中。如果要连接 Client2 和数据库，请参考[暴露 VPC 内网地址方案](#场景-2-连接在-kubernetes-集群之外但与-kubernetes-集群位于同一-vpc-中的客户)。 - 场景 3：Client3 和数据库位于不同的 VPC，例如其他 VPC 或公共网络。如果要连接 Client3 和数据库，请参考[暴露 VPC 公网地址方案](#场景-3-连接在其他-vpc-或公共网络中的客户端)。 参考下面的网络位置关系图。 From 6187f7ec23ebf5e618add36d21326e6e49b888a7 Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Mon, 4 Nov 2024 18:02:46 +0800 Subject: [PATCH 10/11] docs: fix bugs --- .../connect-database-in-production-environment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user_docs/connect_database/connect-database-in-production-environment.md b/docs/user_docs/connect_database/connect-database-in-production-environment.md index 8159317d4f5..c32798c7dc2 100644 --- a/docs/user_docs/connect_database/connect-database-in-production-environment.md +++ b/docs/user_docs/connect_database/connect-database-in-production-environment.md @@ -14,7 +14,7 @@ import TabItem from '@theme/TabItem'; In the production environment, it is normal to connect a database with CLI and SDK clients. There are three scenarios. - Scenario 1: Client1 and the database are in the same Kubernetes cluster. To connect client1 and the database, see [Use ClusterIP](#scenario-1-connect-database-in-the-same-kubernetes-cluster). -- Scenario 2: Client2 is outside the Kubernetes cluster, but it is in the same VPC as the database. To connect client2 and the database, see [Expose VPC Address](#scenario-2-client-outside-the-kubernetes-cluster-but-in-the-same-vpc-as-the-kubernetes-cluster). +- Scenario 2: Client2 is outside the Kubernetes cluster, but it is in the same VPC as the database. To connect client2 and the database, see [Expose VPC Private Address](#scenario-2-client-outside-the-kubernetes-cluster-but-in-the-same-vpc-as-the-kubernetes-cluster). - Scenario 3: Client3 and the database are in different VPCs, such as other VPCs or the public network. To connect client3 and the database, see [Expose VPC Public Address](#scenario-3-connect-database-with-clients-in-other-vpcs-or-public-networks). See the figure below to get a clear image of the network location. From c6319fd3468ea57a2cf8171e26c9d9e877746baa Mon Sep 17 00:00:00 2001 From: yuanyuan zhang Date: Mon, 4 Nov 2024 18:05:49 +0800 Subject: [PATCH 11/11] docs: fix bugs --- .../connect-database-in-production-environment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user_docs/connect_database/connect-database-in-production-environment.md b/docs/user_docs/connect_database/connect-database-in-production-environment.md index c32798c7dc2..1cb90a2ec47 100644 --- a/docs/user_docs/connect_database/connect-database-in-production-environment.md +++ b/docs/user_docs/connect_database/connect-database-in-production-environment.md @@ -168,7 +168,7 @@ The following command creates a LoadBalancer instance for the database instance, ::: -s + ```bash