TiDB Operator 准入控制器

    TiDB Operator 准入控制器与大部分 Kubernetes 平台上产品的准入控制器较为不同，TiDB Operator 通过扩展 API-Server 与 的两个机制组合而成。所以需要 Kubernetes 集群启用聚合层功能，通常情况下这个功能已经默认开启。如需查看是否开启聚合层功能，请参考启用 Kubernetes Apiserver 标志。

    TiDB Operator 在默认安装情况下不会开启准入控制器，你需要手动开启:

    1. 修改 Operator 的

      开启 Operator Webhook 特性:

      默认情况下，如果你的 Kubernetes 集群版本大于等于 v1.13.0，你可以通过上述配置直接开启 Webhook 功能。

      如果你的 Kubernetes 集群版本小于 v1.13.0，你需要执行以下命令，将得到的返回值配置在 values.yaml 中的 admissionWebhook.cabundle：

      1. kubectl get configmap -n kube-system extension-apiserver-authentication -o=jsonpath='{.data.client-ca-file}' | base64 | tr -d '\n'
      1. admissionWebhook:
      2.   # 将上述命令的返回值填写到 admissionWebhook.cabundle 中
      3.   cabundle: ${cabundle}

    2. 配置失败策略

      在 Kubernetes 1.15 版本之前，动态准入机制的管理机制的粒度较粗并且并不方便去使用。所以为了防止 TiDB Operator 的动态准入机制影响全局集群，我们需要配置。

      对于 Kubernetes 1.15 以下的版本，我们推荐将 TiDB Operator 失败策略配置为 Ignore，从而防止 TiDB Operator 的 admission webhook 出现异常时影响整个集群。

      1. ......
      2. failurePolicy:
      3.     validation: Ignore
      4.     mutation: Ignore

      对于 Kubernetes 1.15 及以上的版本，我们推荐给 TiDB Operator 失败策略配置为 Failure，由于 Kubernetes 1.15 及以上的版本中，动态准入机制已经有了基于 Label 的筛选机制，所以不会由于 TiDB Operator 的 admission webhook 出现异常而影响整个集群。

      1. ......
      2. failurePolicy:
      3.     validation: Fail
      4.     mutation: Fail

    3. 安装/更新 TiDB Operator

      修改完 values.yaml 文件中的上述配置项以后，进行 TiDB Operator 部署或者更新。安装与更新 TiDB Operator 请参考在 Kubernetes 上部署 TiDB Operator。

    1. 生成自定义证书

      参考的第一步至第四步，生成自定义 CA 文件。对于 ca-config.json，我们使用如下配置:

      1. {
      2.     "signing": {
      3.         "default": {
      4.             "expiry": "8760h"
      5.         },
      6.         "profiles": {
      7.             "server": {
      8.                 "expiry": "8760h",
      9.                     "signing",
      10.                     "key encipherment",
      11.                     "server auth"
      12.                 ]
      13.             }
      15.     }
      16. }

      当执行至第四步以后，通过 ls 命令执行，cfssl 文件夹下应该有以下文件:

    2. 生成 TiDB Operator 准入控制器证书

      首先生成默认的 webhook-server.json 文件:

      1. cfssl print-defaults csr > webhook-server.json

      然后将 webhook-server.json 文件的内容修改如下:

      1. {
      2.     "CN": "TiDB Operator Webhook",
      3.     "hosts": [
      4.         "tidb-admission-webhook.${namespace}",
      5.         "tidb-admission-webhook.${namespace}.svc",
      6.         "tidb-admission-webhook.${namespace}.svc.cluster",
      7.         "tidb-admission-webhook.${namespace}.svc.cluster.local"
      8.     ],
      9.     "key": {
      10.         "algo": "rsa",
      11.         "size": 2048
      12.     },
      13.     "names": [
      14.         {
      15.             "C": "US",
      16.             "L": "CA",
      17.             "O": "PingCAP",
      18.             "ST": "Beijing",
      19.         }
      20.     ]
      21. }

      其中 ${namespace} 为 TiDB Operator 部署的命名空间。

      然后生成 TiDB Operator Webhook Server 端证书:

      1. cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server webhook-server.json | cfssljson -bare webhook-server

      执行完上述命令后，通过 ls | grep webhook-server 命令应该能查询到以下文件:

      1. webhook-server-key.pem
      3. webhook-server.json
      4. webhook-server.pem

    3. 在 Kubernetes 集群中创建 Secret

      1. kubectl create secret generic ${secret_name} --namespace=${namespace} --from-file=tls.crt=~/cfssl/webhook-server.pem --from-file=tls.key=~/cfssl/webhook-server-key.pem --from-file=ca.crt=~/cfssl/ca.pem

    4. 修改 values.yaml 并安装或升级 TiDB Operator

      获取 ca.crt 的值：

      1. admissionWebhook:
      2.   apiservice:
      3.     insecureSkipTLSVerify: false # 开启 TLS 验证
      4.     tlsSecret: "${secret_name}" # 将上文中所创建的 secret 的 name 填写在这里
      5.     caBundle: "${caBundle}" # 将上文中 ca.crt 的值填入此处

      修改完 values.yaml 文件中上述配置项以后进行 TiDB Operator 部署或者更新。安装 TiDB Operator 请参考在 Kubernetes 上部署 TiDB Operator，升级 TiDB Operator 请参考

    TiDB Operator 通过准入控制器的帮助实现了许多功能。我们将在这里介绍各个资源的准入控制器与其相对应的功能。

    • StatefulSet 验证准入控制器:

      StatefulSet 验证准入控制器帮助实现 TiDB 集群中 TiDB/TiKV 组件的灰度发布，该组件在准入控制器开启的情况下默认关闭。

      1. admissionWebhook:
      2.   validation:
      3.     statefulSets: false

      通过 tidb.pingcap.com/tikv-partition 和 tidb.pingcap.com/tidb-partition 这两个 annotation, 你可以控制 TiDB 集群中 TiDB 与 TiKV 组件的灰度发布。你可以通过以下方式对 TiDB 集群的 TiKV 组件设置灰度发布，其中 partition=2 的效果等同于 StatefulSet 分区

      1. $  kubectl annotate tidbcluster ${name} -n ${namespace} tidb.pingcap.com/tikv-partition=2
      2. tidbcluster.pingcap.com/${name} annotated

      执行以下命令取消灰度发布设置：

      1. $  kubectl annotate tidbcluster ${name} -n ${namespace} tidb.pingcap.com/tikv-partition-
      2. tidbcluster.pingcap.com/${name} annotated

      以上设置同样适用于 TiDB 组件。

    • TiDB Operator 资源验证准入控制器:

      TiDB Operator 资源验证准入控制器帮助实现针对 TidbCluster、TidbMonitor 等 TiDB Operator 自定义资源的验证，该组件在准入控制器开启的情况下默认关闭。

      1. admissionWebhook:
      2.   validation:
      3.     pingcapResources: false

      举个例子，对于 TidbCluster 资源，TiDB Operator 资源验证准入控制器将会检查其 spec 字段中的必要字段。如果在 TidbCluster 创建或者更新时发现检查不通过，比如同时没有定义 spec.pd.image 或者 spec.pd.baseImage 字段，TiDB Operator 资源验证准入控制器将会拒绝这个请求。