课程名称：301+ 3.2k8s部署TIDB集群监控&K8s 部署的 TiDB 集群运维
学习时长：30
课程收获：
- k8s部署TIDB集群监控
- K8s 部署的 TiDB 集群运维
- K8s 部署的 TiDB 集群升级指南
课程内容：
k8s部署TIDB集群监控
tidb-monitor：
https://github.com/pingcap/tidb-operator/blob/master/examples/basic/tidb-monitor.yaml
- spec.cluster.name 要监控的集群名称
- tidb-monitor 的namespace需要和欲监控的集群在同一个namespace下
- 默认监控数据不持久化保存，持久化数据需要配置PV
kube-promethus 监控K8s集群：并且可以复用kube-promethus 的alert-manager 进行告警，并可以整合grafana提供TIDB的监控数据展现。
K8s 部署的 TiDB 集群运维
配置：
TOML直接写到config下，Operator负责生产configmap
升级过程：
通过statefulset的partion参数控制，实现，每次讲partion-1 完成迁移升级后再加回。
TIDB升级需要client具备重试等能力，减小用户影响
扩容
水平扩容
TIKV扩容过程需要检查扩容后是否使用就有的PVC或数据，避免数据影响；缩容需要delete store后删除POD
垂直扩容
自动Failover
Operator将记录失败实例，然后重新生成实例
恢复后，对于PD和TIDB会自动删除新实例；但是TIKV和TIFLASH不会，
重启
组件annotations指定重启时间实现
状态
kubectl get tc ”tc-name“ -n namespace -o format
更底层状态可以通过statefulset实现
服务通过get service和get endpoint 实现
日志
备份恢复
后续使用的使用CR进行处理更加原生
dumping&lighting / BR 独立体系
组件无法直通S3需要通过PV中装
importer可以实现直接导入TIKV方式，比逻辑导入方式更快
监控
参考3.2.1中监控方式
K8s 部署的 TiDB 集群升级指南
不停机滚动升级到4.0以上版本，4.0版本以后可以通过TIUP进行管理
学习过程中遇到的问题或延伸思考：
- 延伸思考 1：
因为是基于K8S的实现，大部分功能可以通过对K8S的理解使用，并使用对应生态系统的工具。
因为tIDB 的组件系统对于状态和顺序的需求，对K8S原生机制之上增加了调度过程，使用过程需要注意这些过程的实现机制。
对于K8S上TIDB组件体系比较松散，需要集中界面更好维护