From 17d7486cd93e6cc61687197c2c3dffbd70cdd207 Mon Sep 17 00:00:00 2001 From: DanielZhangQD <36026334+DanielZhangQD@users.noreply.github.com> Date: Thu, 5 Aug 2021 19:27:13 +0800 Subject: [PATCH] en, zh: update docs for canary upgrade (#1345) --- en/canary-upgrade-tidb-operator.md | 9 +++++++-- en/deploy-multiple-tidb-operator.md | 9 +++++++-- zh/canary-upgrade-tidb-operator.md | 9 +++++++-- zh/deploy-multiple-tidb-operator.md | 9 +++++++-- 4 files changed, 28 insertions(+), 8 deletions(-) diff --git a/en/canary-upgrade-tidb-operator.md b/en/canary-upgrade-tidb-operator.md index 93c48ab47b..cad574ef35 100644 --- a/en/canary-upgrade-tidb-operator.md +++ b/en/canary-upgrade-tidb-operator.md @@ -9,7 +9,7 @@ This document describes how to perform a canary upgrade on TiDB Operator. Using > **Note:** > -> - You can perform a canary upgrade only on `tidb-controller-manager` and `tidb-scheduler`. +> - You can perform a canary upgrade only on `tidb-controller-manager` and `tidb-scheduler`. AdvancedStatefulSet controller and `tidb-admission-webhook` do not support the canary upgrade. > - Canary upgrade is supported since v1.1.10. The version of your current TiDB Operator should be >= v1.1.10. ## Related parameters @@ -32,7 +32,7 @@ To support canary upgrade, some parameters are added to the `values.yaml` file i 2. Deploy the canary TiDB Operator: - Refer to [Deploy TiDB Operator](deploy-tidb-operator.md). Add the following configuration in the `values.yaml` file, and deploy the canary TiDB Operator **in a different namespace** (such as `tidb-admin-canary`): + Refer to [Deploy TiDB Operator](deploy-tidb-operator.md). Add the following configuration in the `values.yaml` file, and deploy the canary TiDB Operator in **a different namespace** (such as `tidb-admin-canary`) with a **different [Helm Release Name](https://helm.sh/docs/intro/using_helm/#three-big-concepts)** (such as `helm install tidb-operator-canary ...`): ```yaml controllerManager: @@ -41,6 +41,10 @@ To support canary upgrade, some parameters are added to the `values.yaml` file i appendReleaseSuffix: true #scheduler: # create: false + advancedStatefulset: + create: false + admissionWebhook: + create: false ``` > **Note:** @@ -49,6 +53,7 @@ To support canary upgrade, some parameters are added to the `values.yaml` file i > * Set `appendReleaseSuffix` to `true`. > * If you do not need to perform a canary upgrade on `tidb-scheduler`, configure `scheduler.create: false`. > * If you configure `scheduler.create: true`, a scheduler named `{{ .scheduler.schedulerName }}-{{.Release.Name}}` will be created. To use this scheduler, configure `spec.schedulerName` in the `TidbCluster` CR to the name of this scheduler. + > * You need to set `advancedStatefulset.create: false` and `admissionWebhook.create: false`, because AdvancedStatefulSet controller and `tidb-admission-webhook` do not support the canary upgrade. 3. To test the canary upgrade of `tidb-controller-manager`, set labels for a TiDB cluster by running the following command: diff --git a/en/deploy-multiple-tidb-operator.md b/en/deploy-multiple-tidb-operator.md index c93e792351..082e5a4d69 100644 --- a/en/deploy-multiple-tidb-operator.md +++ b/en/deploy-multiple-tidb-operator.md @@ -9,7 +9,7 @@ This document describes how to deploy multiple sets of TiDB Operator to manage d > **Note:** > -> - Currently, you can only deploy multiple `tidb-controller-manager`s and `tidb-scheduler`s. +> - Currently, you can only deploy multiple sets of `tidb-controller-manager` and `tidb-scheduler`. Deploying multiple sets of AdvancedStatefulSet controller and `tidb-admission-webhook` is not supported. > - If you have deployed multiple sets of TiDB Operator and only some of them enable [Advanced StatefulSet](advanced-statefulset.md), the same TidbCluster Custom Resource (CR) cannot be switched among these TiDB Operator. > - This feature is supported since v1.1.10. @@ -93,7 +93,7 @@ To support deploying multiple sets of TiDB Operator, the following parameters ar 3. Deploy the second TiDB Operator. - Refer to [Deploy TiDB Operator](deploy-tidb-operator.md) to deploy the second TiDB Operator without `tidb-scheduler`. Add the following configuration in the `values.yaml` file, and deploy the second TiDB Operator (without `tidb-scheduler`) **in a different namespace** (such as `tidb-admin-qa`): + Refer to [Deploy TiDB Operator](deploy-tidb-operator.md) to deploy the second TiDB Operator without `tidb-scheduler`. Add the following configuration in the `values.yaml` file, and deploy the second TiDB Operator (without `tidb-scheduler`) in **a different namespace** (such as `tidb-admin-qa`) with a **different [Helm Release Name](https://helm.sh/docs/intro/using_helm/#three-big-concepts)** (such as `helm install tidb-operator-qa ...`): ```yaml controllerManager: @@ -102,6 +102,10 @@ To support deploying multiple sets of TiDB Operator, the following parameters ar appendReleaseSuffix: true scheduler: create: false + advancedStatefulset: + create: false + admissionWebhook: + create: false ``` > **Note:** @@ -109,6 +113,7 @@ To support deploying multiple sets of TiDB Operator, the following parameters ar > * It is recommended to deploy the new TiDB Operator in a separate namespace. > * Set `appendReleaseSuffix` to `true`. > * If you configure `scheduler.create: true`, a `tidb-scheduler` named `{{ .scheduler.schedulerName }}-{{.Release.Name}}` is created. To use this `tidb-scheduler`, you need to configure `spec.schedulerName` in the `TidbCluster` CR to the name of this scheduler. + > * You need to set `advancedStatefulset.create: false` and `admissionWebhook.create: false`, because deploying multiple sets of AdvancedStatefulSet controller and `tidb-admission-webhook` is not supported. 4. Deploy the TiDB cluster. diff --git a/zh/canary-upgrade-tidb-operator.md b/zh/canary-upgrade-tidb-operator.md index 695ad871d5..d9e68cedb9 100644 --- a/zh/canary-upgrade-tidb-operator.md +++ b/zh/canary-upgrade-tidb-operator.md @@ -9,7 +9,7 @@ summary: 介绍如何灰度升级 TiDB Operator。 > **注意：** > -> - 目前仅支持灰度升级 tidb-controller-manager 和 tidb-scheduler。 +> - 目前仅支持灰度升级 tidb-controller-manager 和 tidb-scheduler，不支持灰度升级 AdvancedStatefulSet controller 和 AdmissionWebhook。 > - v1.1.10 开始支持此项功能，所以当前 TiDB Operator 版本需 >= v1.1.10。 ## 相关参数 @@ -32,7 +32,7 @@ summary: 介绍如何灰度升级 TiDB Operator。 2. 部署灰度 TiDB Operator。 - 参考[部署 TiDB Operator 文档](deploy-tidb-operator.md)，在 `values.yaml` 中添加如下配置，**在不同的 namespace** 中（例如 `tidb-admin-canary`）部署灰度 TiDB Operator： + 参考[部署 TiDB Operator 文档](deploy-tidb-operator.md)，在 `values.yaml` 中添加如下配置，在**不同的 namespace** 中（例如 `tidb-admin-canary`）使用**不同的 [Helm Release Name](https://helm.sh/docs/intro/using_helm/#three-big-concepts)**（例如 `helm install tidb-operator-canary ...`）部署灰度 TiDB Operator： ```yaml controllerManager: @@ -41,6 +41,10 @@ summary: 介绍如何灰度升级 TiDB Operator。 appendReleaseSuffix: true #scheduler: # create: false + advancedStatefulset: + create: false + admissionWebhook: + create: false ``` > **注意：** @@ -49,6 +53,7 @@ summary: 介绍如何灰度升级 TiDB Operator。 > * `appendReleaseSuffix` 需要设置为 `true`。 > * 如果不需要灰度升级 tidb-scheduler，可以设置 `scheduler.create: false`。 > * 如果配置 `scheduler.create: true`，会创建一个名字为 `{{ .scheduler.schedulerName }}-{{.Release.Name}}` 的 scheduler，要使用这个 scheduler，需要配置 TidbCluster CR 中的 `spec.schedulerName` 为这个 scheduler。 + > * 由于不支持灰度升级 AdvancedStatefulSet controller 和 AdmissionWebhook，需要配置 `advancedStatefulset.create: false` 和 `admissionWebhook.create: false`。 3. 如果需要测试 tidb-controller-manager 灰度升级，通过如下命令为某个 TiDB 集群设置 label： diff --git a/zh/deploy-multiple-tidb-operator.md b/zh/deploy-multiple-tidb-operator.md index 311296b987..72c73de609 100644 --- a/zh/deploy-multiple-tidb-operator.md +++ b/zh/deploy-multiple-tidb-operator.md @@ -10,7 +10,7 @@ aliases: ['/zh/tidb-in-kubernetes/dev/canary-deployment-tidb-operator/'] > **注意：** > -> - 目前仅支持部署多套 tidb-controller-manager 和 tidb-scheduler。 +> - 目前仅支持部署多套 tidb-controller-manager 和 tidb-scheduler，不支持部署多套 AdvancedStatefulSet controller 和 AdmissionWebhook。 > - 如果部署了多套 TiDB Operator，有的开启了 [`Advanced StatefulSet`](advanced-statefulset.md)，有的没有开启，那么同一个 TidbCluster Custom Resource (CR) 不能在这些 TiDB Operator 之间切换。 > - v1.1.10 开始支持此项功能 @@ -90,7 +90,7 @@ aliases: ['/zh/tidb-in-kubernetes/dev/canary-deployment-tidb-operator/'] 3. 部署第二套 TiDB Operator。 - 参考[部署 TiDB Operator 文档](deploy-tidb-operator.md)，在 `values.yaml` 中添加如下配置，**在不同的 namespace** 中（例如 `tidb-admin-qa`）部署第二套 TiDB Operator (没有部署 `tidb-scheduler`)： + 参考[部署 TiDB Operator 文档](deploy-tidb-operator.md)，在 `values.yaml` 中添加如下配置，在**不同的 namespace** 中（例如 `tidb-admin-qa`）使用**不同的 [Helm Release Name](https://helm.sh/docs/intro/using_helm/#three-big-concepts)**（例如 `helm install tidb-operator-qa ...`）部署第二套 TiDB Operator (没有部署 `tidb-scheduler`)： ```yaml controllerManager: @@ -99,6 +99,10 @@ aliases: ['/zh/tidb-in-kubernetes/dev/canary-deployment-tidb-operator/'] appendReleaseSuffix: true scheduler: create: false + advancedStatefulset: + create: false + admissionWebhook: + create: false ``` > **注意：** @@ -106,6 +110,7 @@ aliases: ['/zh/tidb-in-kubernetes/dev/canary-deployment-tidb-operator/'] > * 建议在单独的 namespace 部署新的 TiDB Operator。 > * `appendReleaseSuffix` 需要设置为 `true`。 > * 如果配置 `scheduler.create: true`，会创建一个名字为 `{{ .scheduler.schedulerName }}-{{.Release.Name}}` 的 scheduler，要使用这个 scheduler，需要配置 TidbCluster CR 中的 `spec.schedulerName` 为这个 scheduler。 + > * 由于不支持部署多套 AdvancedStatefulSet controller 和 AdmissionWebhook，需要配置 `advancedStatefulset.create: false` 和 `admissionWebhook.create: false`。 4. 部署 TiDB 集群。