Cloud Team：上能修 DB，下能改容器的云原生信仰者 ｜ PingCAP 招聘季

TiDB 从诞生之时就带着云原生的标签，并且底层存储引擎 TiKV 也在 2019 年成为了 CNCF （云原生计算基金会）的孵化项目。我们很早就认识到，云提供的基础设施可编程、按量付费等区别于传统数据中心的核心特质，正是释放 TiDB 弹性伸缩潜力的最佳载体。

而在另一方面，由于有状态应用天生的复杂性和数据资产不可估量的重要性，云原生革命的上半场仍聚焦在运维流程更易标准化、故障也相对可容忍的无状态应用上。随着 Kubernetes 与 Docker Swarm 的容器编排之战尘埃落定，无状态应用编排问题在几年内迅速得到解决后，如何在云上构建坚实可靠的数据层作为新的问题浮出了水面。相信很多有识之士早已看到了这些问题，准备“寻机而动”。不过，有那么一群人已经脚踏实地付诸行动了。

是的，有那么一群人，在他们眼中，TiDB 与云是天生互相吸引、互相需要的，用“佳偶天成”来形容二者的关系并不为过。这群人就是 PingCAP 的 Cloud 团队，一群义无反顾的云原生信仰者、一群“上能修 DB、下能改容器”的技术 Nerds、一群 TiDB 和云的忠实 “CP 粉”。我们就是这群人，而这篇文章就是希望能打动屏幕面前的你，加入我们 —— “不负韶华，共谱云与 TiDB 的和谐乐章”。好了，务虚到此结束，下面我们来点实在的。

TiDB Operator 是 Cloud 团队最早的项目，Operator 是一种为 Kubernetes 扩展编排知识的编程范式。而 TiDB Operator，顾名思义，就是将 TiDB 的运维知识写成代码，注入到 Kubernetes 中。而这些特定的运维知识，正是 Kubernetes 上的有状态应用所缺失的东西。2016 年 CoreOS 率先提出的 Operator 模式，我们也同期开始了 TiDB Operator 的开发。大家或许知道，Kubernetes 的成熟与稳定是近些年的事儿。单就计算，服务于有状态应用编排的 StatefulSet 直到 1.5 才出现。而对于要求高 IO 低延迟的数据库应用，其强需求的本地持久化存储（Local PV）在 1.10 (2018 年)才进入 Beta 阶段，直到 1.14 方才正式 GA。TiDB Operator  经历了一无所有的蛮荒时期，我们编写控制器去逐个编排 Pod 组成 TiDB 集群，通过 HostPath 实现了类似 Local PV 的本地存储管理体系。虽然这个“平地起高楼”的第一版 Operator 最后并未面世，但却为大家现在看到的 Operator 积累了相当多的经验。当我们看到 Kubernetes 对 StatefulSet 控制器的不断增强以及 Local PV 的推出时，那种“似曾相识”的熟悉感让我们放心地选择了 Upstream 的 in-tree 解决方案来更好地拥抱社区。在去年 7 月，我们 正式发布 TiDB Operator v1.0 GA ，完成了 TiDB 与云融合的第一个里程碑。

而在 GA 后的几个月，海内外多家用户进行了 TiDB Operator 的 PoC 并成功推向核心生产环境，TiDB Operator 也没有辜负期待，稳定支撑了包括公有云和 on-premise、混部和独占式部署各类集群形态的自动化管理运维。而今年，我们则着眼于社区与 DBaaS，期待让 TiDB 在更多的用户、更多的云、更多的生态中落地开花。

此外，作为连接 TiDB 和 Kubernetes 两大顶级开源项目的 TiDB Operator，本身也是一个开源项目，我们希望打造一个活跃的开源社区，带领志同道合的社区萌新们一路打怪升级，从跃跃欲试的 Contributor，到执掌一个模块的 Commiter  甚至  Maintainer。作为 Cloud 团队成员，你将有机会亲手构建并领导一个充满生命力的社区，并和来自不同背景、不同国家的贡献者一起为 TiDB Operator 添加更多酷炫的特性。

为了进一步降低用户使用 TiDB 的门槛与运维成本，我们构建了基于公有云的 DBaaS （Database as a Service）服务，提供全托管的数据库服务。我们希望用户不用关注分布式数据库自身的运维，将精力聚焦到自己的业务逻辑上。从开源的 TiDB Operator 到生产级的 DBaaS 服务，我们将和你一起解决这些有意思的事情：

对于 TiDB 这样的复杂分布式数据库，在调度 Pod 时我们既要考虑数据库内部数据分片（一段连续的数据，表现为一个Raft 复制组） 的调度，也要考虑外部进程沙箱的调度。在保证最大程度容灾的同时尽可能提高数据库整体性能。

对于云服务，性价比是可称得上是“决定生死”的关键因素。成本优化同样是一个复杂的命题。我们是否可以为 TiDB 引入冷热数据分离特性，将冷数据调度到低速的机械盘、网络盘甚至 S3 这样的对象存储上，以降低使用成本呢？假如可以，这又势必会为编排和调度又引入新的挑战：当我们弹性扩容时，我们是弹出几个使用 SSD 的 replica，还是几个使用 HDD 的 replica，抑或是混合？当热点过去，数据库的查询渐小，但存储空间仍然吃紧时，我们又该怎样将部分节点替换成性能稍差但存储空间庞大的冷存储节点呢？

K8s 自身的调度编排能力，在面对上述复杂的应用场景时显得捉襟见肘，当你拥有全集群的上帝视角时，你会如何对整个集群进行自动化合理的编排调度呢？在这里你不仅要成为 TiDB 和 K8s 领域专家，还要能够上能改 TiDB 代码，下能调 K8s 代码，让这两大项目能更好地结合在一起。

TiDB 作为一款分布式数据库，在云时代我们希望它能够跨地域（region）、跨云部署，用户可以自由选择自己喜欢的云平台，使用兼容 MySQL 协议的无限水平扩展的分布式数据库，只要用户愿意甚至可以选择跨云部署实现跨云容灾。

假如你：

• 优秀的发现和解决问题能力，良好的沟通能力和团队合作精神；

• 有三年以上相关领域开发经验，扎实的编程能力，熟悉 C/C++/Rust/Go/Python 中至少一种；

• 了解各种常见网络协议原理和虚拟化技术，对分布式系统有一定的了解；
  

• 熟悉 Docker 和 Kubernetes 原理，践行 Infrastructure as Code，了解常用的 IaC 工具（Terraform, Pulumi 等）。

那么，欢迎上船，cloud guys here！

关注公众号：拾黑（shiheibook）了解更多