江苏龙网

  1. 首页 > 人文 > >

技术编程|TiDB on Kubernetes 最佳实践( 二 )


但是，TiDB 和 Kuberentes 都有大量的最佳实践，基本上你想快速看完是有点困难的 。那么，我们在 K8s 上部署 TiDB 的时候，应该怎样去遵守最佳实践呢？一个基本的办法就是把这些坑都了解清楚，并且写非常多的 run book 来告诉 SRE team，怎么去运维好它们 。run book 需要口口相传，需要不断的进行知识的交互、交流 。但其实大家都知道，程序员一般不喜欢做这个 。
我们更喜欢把这些知识写成代码，做自动化 。那么，我们怎么样把这些东西写成代码自动化呢？
TiDB on Kubernetes 运维专家：TiDB Operator
答案就是 TiDB Operator。TiDB Operator 是什么？本质就是利用 K8s 本身的扩展机制，把领域性的运维知识编写成代码，大家可以把 TiDB Operator 理解为在 K8s 上运行 TiDB 的运维专家，把一个专家型人物对 TiDB 和 K8s 的所有知识都编写成了代码 。
TiDB Operator 首先添加了一组自定义类型，比如说 TiDB Cluster，代表一个 TiDB 集群，可以在这些类型里描述你想要的 TiDB 长什么样；第二，TiDB Operator 添加了一组自定义控制器，这组自定义控制器就是这些运维知识的集合，它会用这些代码化的知识帮助你自动化的运维 K8s 上的 TiDB 集群 。
看一个例子：首先是自定义类型，当 TiDB Operator 把自定义类型添加到 K8s 中后，作为用户就可以提交资源定义到 K8s 里面，比如我们需要一个 TiDB 集群，这个集群要的版本是什么，要多少 PD，要多少 KV 。以及我们可以定义一个 TiDBMonitor 对象，用来监控 TiDB，在对象定义里则只需要定义我们要监控哪一个 TiDB 就可以了 。
那么，大家可以发现，我们在做这些资源定义时是遵循 K8s 本身的声明式定义的 。那这些的理想状态由谁来实现呢？——由自定义控制器 。自定义控制器会把所有的需求和 K8s 集群里的实际状态做一个对比，对比之后就能发现两者的不同，就需要把实际状态向期望状态转移 。比如说我们把刚刚的 TiDB 集群对象和 TiDB 监控对象提交到 K8s ，那么 TiDB Operator 的控制器就会帮助我们创建很多的容器以及监控 。
当然，仅仅只有创建是不够的，TiDB Operator 中还集成了 TiDB 运维专家的所有的领域知识，下面我分享几个运维知识 。
【技术编程|TiDB on Kubernetes 最佳实践】运维知识：部署
1. TiDB Operator 会为每个组件选择最佳的 K8s 原生对象；
2. 会自动地引导 PD 做 Peer Discovery，无需手工配置；
3. 最重要的，还会打散 TiKV 容器并自动添加 store-label ，辅助 PD 实现 Region 高可用拓扑 。
运维知识：升级
滚动升级 TiKV 的时候，给每个 TiKV 实例发个 SIGTEM，这时 TiKV 其实只会做一些基本的 Graceful Shutdown 操作 。那就有一个问题，TiKV 退出时并不会主动的把所有的 Raft Leader 都迁移出去 。假设我们有比较大的流量，滚动升级时让没有受影响的 Raft Group 被动地去做一个 leader 超时重新选举，那很可能会导致我们的数据库延迟会有一定的抖动 。
那么 TiDB Operator 怎么做升级呢？在每次升级一个 TiKV 的容器之前，Operator 会先调用 PD 接口，把 TiKV 上边的 leader 全部迁移完，不接收读写请求后才会去重建 TiKV 的容器 。依次往复，比如把 TiKV2 迁完了，就要把 TiKV2 重建， TiKV2 重建后，又可以把 leader 迁上去，接收请求，然后下一个就是把 TiKV1 的 leader 迁完，再往下 。实现一个优雅的滚动升级 。
运维知识：故障转移
技术编程|TiDB on Kubernetes 最佳实践
文章图片
比如，现在 TiKV1 运行的不正常，那么 Operator 的控制器就可以结合 PD 里的 TiKV1 对应的 store 状态信息和 K8s 里它所在容器的状态信息，来判断这一个 TiKV 的 store 是否异常 。判断逻辑大致是 store 处于异常状态，并且持续超过一定时间 。检测到异常后隔多久再做故障恢复以及怎么样判断是否发生异常，本身也是一种运维知识 。
技术编程|TiDB on Kubernetes 最佳实践
文章图片
那 Operator 有了这些知识并且把它代码化之后，就可以在检测到异常后，过一段合理的时间后再补充新的 store ，把副本数补齐 。这样即使我们接下来 TiKV2 再挂，那集群就不会受影响，这就是 Operator 帮助我们做的故障转移 。
技术编程|TiDB on Kubernetes 最佳实践
文章图片
Operator 在最新版里还提供了 on to scaling 的功能，我们去查看集群当中的所有的组件的监控信息，并且根据这些监控信息，做自动的扩缩容，可想而知就需要更多的支持了 。
大家可能会想，尽管 Operator 带来了这么多好处，但我还是担心假如用 Operator 上了 K8s 之后会有一些问题 。比如，上 K8s 会带来多少性能损耗？会影响我的稳定性吗？假如 K8s 挂了，我的数据库会不会受影响呢？一个 TiDB 和 K8s 的领域专家是可以解答这些问题的，因此，TiDB Operator 当然也可以 。


推荐阅读


上一篇：辽沈晚报朝阳时刻|朝阳新都黄金整体搬迁 改造项目全面建设中

下一篇：股票行情|业绩预增披露前大买443万股，和公司总裁频繁电话，看监管怎么罚他