参照官方文档都部署不了,tidb v2.0部署TIDB集群

Billmay表妹 · 2025 年9 月 22 日 10:17

你确认一下一下的几个版本号：

TiDB Operator 的版本
TiDB 的版本
K8s 的版本

Billmay表妹 · 2025 年9 月 22 日 10:18

你的报错中有 cannot get cluster: Cluster.core.pingcap.com ‘basic’ not found" 的错误

根据日志信息，PDGroup 控制器在 “db” 命名空间中尝试协调名为 “pd” 的 PDGroup 资源时，无法找到名为 “basic” 的 Cluster 资源。这表明 TiDB Operator 期望找到一个名为 “basic” 的 TiDB 集群定义，但该资源不存在或无法访问。

问题原因分析

这个错误通常由以下几种情况导致：

集群资源定义不存在：名为 “basic” 的 TiDB 集群资源（Cluster.core.pingcap.com）未在 Kubernetes 中创建或已被删除
命名空间不匹配：集群资源可能存在于其他命名空间，而非 PDGroup 所在的 “db” 命名空间
资源引用错误：PDGroup 配置中引用了错误的集群名称
TiDB Operator 权限问题：TiDB Operator 可能没有足够权限访问集群资源
CRD 版本不兼容：自定义资源定义(CRD)版本可能与 TiDB Operator 版本不兼容

解决步骤

1. 检查集群资源是否存在

首先，检查 “basic” 集群资源是否存在于 Kubernetes 中：

kubectl get tc -n db basic
# 或检查所有命名空间
kubectl get tc --all-namespaces

如果找不到名为 “basic” 的集群资源，则需要创建它或修正引用。

2. 检查 PDGroup 资源配置

检查 PDGroup 资源的配置，确认它引用的集群名称是否正确：

kubectl get pdgroup pd -n db -o yaml

在输出中查找 spec.cluster 或类似字段，确认它是否正确引用了 “basic” 集群。如果引用错误，需要修改 PDGroup 资源配置。

3. 修正集群引用关系

根据您的实际情况，选择以下方法之一：

方法 A：创建缺失的集群资源

如果确实需要名为 “basic” 的集群，创建一个新的集群资源：

# 创建基本的 TiDB 集群配置文件 basic.yaml
cat > basic.yaml << EOF
apiVersion: pingcap.com/v1alpha1
kind: Cluster
metadata:
  name: basic
  namespace: db
spec:
  version: v8.5.0
  # 添加其他必要配置...
EOF

# 应用配置
kubectl apply -f basic.yaml

方法 B：修改 PDGroup 引用

如果应该引用其他现有集群，修改 PDGroup 配置：

kubectl edit pdgroup pd -n db

在编辑器中找到集群引用部分，将 “basic” 改为正确的集群名称。

4. 检查 TiDB Operator 权限

确保 TiDB Operator 有足够权限访问集群资源：

# 检查 TiDB Operator 的 ServiceAccount 权限
kubectl describe clusterrole tidb-operator
kubectl describe clusterrolebinding tidb-operator

如果发现权限问题，可能需要更新 RBAC 配置。

5. 检查 CRD 版本兼容性

确认 TiDB Operator 和 CRD 版本兼容：

# 检查 TiDB Operator 版本
kubectl get deployment -n tidb-admin tidb-controller-manager -o jsonpath='{.spec.template.spec.containers[0].image}'

# 检查 CRD 版本
kubectl get crd | grep pingcap.com

如果版本不兼容，可能需要更新 TiDB Operator 或重新安装匹配的 CRD。

6. 重启 TiDB Operator

如果上述步骤未解决问题，尝试重启 TiDB Operator：

kubectl rollout restart deployment -n tidb-admin tidb-controller-manager

7. 检查 PD 集群状态

如果您正在恢复已有的 PD 集群，可能需要检查 PD 集群的状态：

# 检查 PD Pod 状态
kubectl get pods -n db -l app.kubernetes.io/component=pd

# 查看 PD Pod 日志
kubectl logs -n db -l app.kubernetes.io/component=pd

如果 PD 集群出现问题，可能需要使用 pd-recover 工具进行恢复。

预防措施

为避免类似问题再次发生，建议：

在创建 PDGroup 资源前，确保引用的集群资源已存在
使用一致的命名空间管理相关资源
定期备份 Kubernetes 资源定义
遵循 TiDB Operator 的版本兼容性指南
实施变更前进行充分测试

TiDBer_2oqWWtfV · 2025 年9 月 22 日 10:19

按照官方文档来的，
TiDB Operator 的版本： v2.0.0-beta.0
TiDB 的版本： v8.5.2
`K8s 的版本：1.3.1

Billmay表妹 · 2025 年9 月 22 日 10:19

也就是 TiDB 开放，你要是在别的论坛这样子写估计要给你删帖、拉黑了

Billmay表妹 · 2025 年9 月 22 日 10:21

你照着检查

TiDBer_2oqWWtfV · 2025 年9 月 22 日 10:27

你要是能把我想问的问题，怎么反映给写这个文档的人，那我非常感谢

Lucien-卢西恩 · 2025 年9 月 22 日 10:41

TiDB Operator 部署成功了吗？看报错是 TiDB Operator 部署问题。所以现在部署 TiDB 集群报错。可以看一下 https://docs.pingcap.com/zh/tidb-in-kubernetes/v2.0/deploy-tidb-operator/#部署-tidb-operator-crd 操作，另外别用 v2.0.0-beta.0 版本，这个版本是 beta，不是 GA。

Lucien-卢西恩 · 2025 年9 月 22 日 10:48

TiDB Operator 开源社区在这里哈，如果想要反馈问题，可以直接在这里找到 TiDB Operator 的 Group 反馈问题。https://github.com/pingcap/tidb-operator ，这里是 TiDB 的互助问答社区，大家可以开诚布公的解决问题，反馈相关问题。如果咱们实在不好解决问题，欢迎联系商业化团队协助解决问题。

TiDBer_2oqWWtfV · 2025 年9 月 22 日 10:50

好的，谢谢

srstack · 2025 年9 月 22 日 11:29

我没懂有什么问题？你的 operator 报错也是告诉你没有找到 cluster
operator v2 的设计逻辑本身就将 pd/tidb/tikv 等作为单独的 cr 资源来进行描述，所以需要一个统一的上层资源 cluster 来控制。

Billmay表妹 · 2025 年9 月 22 日 11:30

用1.6的版本
2.0 还是 beta 版

yiduoyunQ · 2025 年9 月 22 日 11:54

2.0 没 GA

TiDBer_HErMeXDz · 2025 年9 月 23 日 02:39

感觉这个哥们来踢馆的。

Billmay表妹 · 2025 年9 月 23 日 02:42

在 k8s 上装 tidb 会比直接用 tiup 装困难一点，另外 tidb 在高版本也有资源管控的功能，能满足你按需求分资源。

TiDB Operator v1.6 适合上生产：
https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/tidb-operator-overview/

所以尽量用 1.6

如果你不怕困难，想尝鲜一下 2.0 那么你要了解清楚

随着 TiDB 和 Kubernetes 生态的快速发展，TiDB Operator 发布了与 v1 不兼容的 v2 版本。关于 v2 与 v1 的详细差异，请参考 TiDB Operator v2 与 v1 版本对比。

TiDB Operator v2 对 TiDB Operator v1 进行了大幅重构：

TiDB Operator v2 的核心变更

拆分 `TidbCluster` CRD

最初 TiDB 集群只有 3 个核心组件：PD、TiKV、TiDB。为了尽可能简化部署，降低用户心智负担，最初的设计将所有 TiDB 集群的组件定义在了同一个 CRD TidbCluster 中。然而，随着 TiDB 的发展，这种设计迎来了一些挑战。

TiDB 集群的组件不断增加，目前已经有 8 个组件定义在 TidbCluster CRD 中
为了实现状态展示，所有节点的状态都定义在了 TidbCluster CRD 中
缺乏原生对异构集群对支持，只能通过引入额外的 TidbCluster CR 实现异构集群
无法支持 /scale API，无法与 Kubernetes 的 HorizontalPodAutoscaler (HPA) 生态集成
一个巨大的 CR/CRD 可能带来难以解决的性能问题

为解决上述问题，TiDB Operator v2 将 TidbCluster CRD 按组件拆分为多个独立的 CRD。

移除 StatefulSet 依赖，直接管理 Pod

由于 TiDB 集群本身的复杂性，Kubernetes 原生的 Deployment 和 StatefulSet 控制器无法完美适配 TiDB 的部署和运维需求。TiDB Operator v1 通过 StatefulSet 管理所有 TiDB 组件，然而 StatefulSet 的一些限制无法最大化 Kubernetes 能够提供的能力，比如：

StatefulSet 限制了 VolumeClaimTemplate 的修改，无法原生支持扩容
StatefulSet 限制了缩容和滚动更新的顺序，导致 leader 的反复调度
StatefulSet 限制了同一个控制器下的 Pod 配置必须相同，不得不通过复杂的启动脚本来差异化同一组 Pod 的启动参数
没有 API 提供 Raft member 的定义，导致重启 Pod 和移除 Raft member 的语义冲突，没有直观的方法可以移除某一个 TiKV 节点

TiDB Operator v2 移除了对 StatefulSet 的依赖，并引入了以下 CRD：

Cluster
ComponentGroup
Instance

这三层 CRD 可以直接管理 Pod。TiDB Operator v2 通过 ComponentGroup CRD 来管理具有共同特性的节点，降低复杂度，通过 Instance CRD 来方便对单个有状态实例进行管理，提供实例级别的运维操作，保证了灵活性。

这带来了如下好处：

能够更好的支持 Volume 的变更
能够支持更合理的滚动更新顺序，比如最后重启 leader，防止 leader 的反复迁移
能够支持非核心组件（例如 log tail 和 istio）的原地升级，降低 TiDB Operator 升级以及 infra 变更对 TiDB 集群的影响
能够通过 kubectl delete ${pod} 优雅重启 Pod，也能通过 kubectl delete ${instance} 重建特定的 TiKV 节点
更加直观的状态展示

引入 Overlay 机制，不再直接管理 TiDB 无关的 Kubernetes 字段

每个 Kubernetes 的新版本都可能会引入一些用户需要的新字段，然而这些字段可能 TiDB Operator 并不关心。TiDB Operator v1 的开发过程中花了大量的时间在支持快速发展的 Kubernetes 的新功能，包括手动在 TidbCluster CRD 中添加新字段，并将新字段层层下发。TiDB Operator v2 引入了 Overlay 机制，通过统一的方式支持所有 Kubernetes 资源（尤其是 Pod）上的新字段，详情见 Overlay。

其他 TiDB Operator v2 的新特性

增强验证能力

TiDB Operator v2 通过合法性检查规则 (Validation Rule) 和验证准入策略 (Validating Admission Policy) 增强配置校验能力，提高了系统的易用性与健壮性。

支持 `/status` 和 `/scale` 子资源

TiDB Operator v2 支持 CRD 子资源，可与 Kubernetes 提供的 HPA 集成，实现自动化扩缩容。

移除 `tidb scheduler` 组件并支持 Evenly Spread Policy

TiDB Operator v2 支持配置 Evenly Spread Policy 来将组件按需均匀分布到不同的 Region 和 Zone 上，并移除了 tidb scheduler 组件。

TiDB Operator v2 暂不支持的组件和功能

组件

`Binlog` (Pump + Drainer)

Binlog 组件已经废弃，详见 TiDB Binlog 简介。

Dumpling + TiDB Lightning

TiDB Operator 不再提供对 Dumpling 和 TiDB Lightning 的直接支持，建议使用 Kubernetes 原生 Job 的方式运行。

`TidbInitializer`

TiDB Operator v2 不再支持 TidbInitializer CRD，你可以使用 BootstrapSQL 的方式运行初始化的 SQL。

`TidbMonitor`

TiDB Operator v2 不再支持 TidbMonitor CRD。由于用户的监控系统通常比较复杂并且方案众多，TidbMonitor 往往无法很好地集成到生产级别的监控系统中。TiDB 通过更灵活的方式直接为你提供集成常用监控系统的方案，不再通过 CRD 的方式运行 Prometheus + Grafana + Alert-Manager 的组合。详情请参阅 TiDB 集群的监控与告警。

`TidbNgMonitoring`

暂不支持 TidbNgMonitoring。

`TidbDashboard`

暂不支持通过 CRD 部署 TidbDashboard。你可以使用内置的 Dashboard 或者通过 Deployment 自行部署。

功能

跨 Namespace 部署

考虑到跨 Namespace 可能带来的安全性问题以及尚不明确的用户场景，暂不支持。

跨 Kubernetes 集群部署

考虑到跨 Kubernetes 集群可能带来的安全性问题以及尚不明确的用户场景，暂不支持。

基于 EBS 卷快照的备份恢复

基于 EBS 卷快照的备份存在以下难以解决的问题：

成本过高：EBS 卷快照的成本非常高。
RTO 过长：从 EBS 卷快照恢复的时间非常长。

随着持续的优化，TiDB BR 的性能提升显著，基于 EBS 卷快照的备份恢复不再是必需的。因此，TiDB Operator v2 不再支持该功能。

TiDB Operator 2.0.0-beta.0 特性介绍： https://docs.pingcap.com/zh/tidb-in-kubernetes/v2.0/release-2.0.0-beta.0/
此版本为 beta 版本，建议在生产环境中部署前进行充分测试 。

ziri0623 · 2025 年9 月 24 日 01:36

应该用那个版本

Kongdom · 2025 年9 月 24 日 06:02

尽量用 1.6