技术编程|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 当然也可以 。
运维知识:性能
1. TiDB Operator 支持独享节点与混部 , 可以按照优先级权衡性能与成本;
2. 自动化运维知识考虑了本地盘 , 使用本地盘就可以消除远程存储的损耗;
3. 支持 K8s 的 HostNetwork 部署集群 , 消除二层网络开销 , 所以说在一定的配置下 , 用 TiDB Operator 部署 TiDB 其实是可以做到零 overhead 的 。
运维知识:稳定性
1. K8s Master 故障不会影响集群 , 因为只是控制节点故障 , 跑 TiDB 的节点并没有故障;
2. K8s Node 故障会帮我们做自动故障转移;
3. 假如 K8s 的整个集群所有节点都故障了怎么办?Operator 本身有一个默认配置是在这种情况下会保留所有的存储 , 首先先保证数据不丢;


推荐阅读