腾讯大规模云原生平台稳定性实践
如果无法正常显示,请先停止浏览器的去广告插件。
1. 腾讯大规模云原生平台稳定性实践
唐聪
腾讯云TKE稳定性负责人,腾讯云技术专家
2. 自我介绍
• 2014年本科毕业加入腾讯,负责大规模qq后台
业务、redis平台开发
• 2018年加入腾讯云容器团队,负责大规模etcd
集群治理和优化,master组件稳定性优化
• etcd社区活跃贡献者,2021年热⻔极客时间专
栏《etcd实战课》作者
我们是如何走
出低谷的呢?
工单
投诉
半夜集群雪崩
时间轴
3. • k8s故障案例分析与最佳实践
• 大规模etcd集群治理
• Kubernetes其他master组件治理
• QA
4. k8s故障案例分析与最佳实践
5. 从故障案例说起-k8s稳定性为何不可
忽视?
故障案例1:
某大厂业务k8s集群因list请求多
次雪崩,其中某次故障6小时,
恢复过程中又决策失误,导致业
务数据面出现断网,造成最严重
的故障
如何保障k8s
的稳定性呢?
故障案例2:
某剧因太火爆,核心服务部署在
k8s集群中,业务自行开发的扩
容流程,在流量高峰自动扩容失
败,用户大量重试,服务雪崩,
最终导致大规模投诉
故障案例3:
某业务operator,因依赖方业务
变更,返回数据异常,operator
快速进行一致性协调操作中,删
除了用户的k8s某类资源,最终
导致大量用户访问集群异常。
6. Kubernetes核心架构
7. Kube-apiserver常见故障
8. Kubernetes稳定性最佳实践
9. 搞崩Kube-apiserver查询典型案例1-标签查询
A: 2个
default ns下当前有10w个pod,
其中apisix pod 2个,标签为
kubectl
get pod –l app=apisix
B: 10万个
app=apisix
C: 500个
GET api/v1/namespaces/default/pods?labelSelector=app%3Dapisix&limit=500
200 OK
10. 搞崩Kube-apiserver查询典型案例2-Describe Event查询
A: 6条
kube-system ns下当前有
10w条event, 以coredns
kubectl –n kube-system
describe pod/core-dns-xx
B: 10万条
pod-name开头的event 6条
C: 不确定
GET /api/v1/namespaces/kube-system/events?fieldSelector=involvedObject.name%3Dcoredns-5d4c6744bf-
88lr4%2CinvolvedObject.namespace%3Dkube-system%2CinvolvedObject.uid%3Dd7f81fbe-9133-46ca-ba22-
a5772ad2d6ae 200 OK
11. apiserver如何执行查询get/list等资源的请求呢?
• 鉴权/用户身份是否合法
• 审计/记录用户详细行为
• 限速/请求优先级及公平管理
• 授权/用户是否有权限对其访问的
资源进行操作
• 准入机制/提供在访问资源前拦截请求
的动态扩展能力
• 匹配resource handler
• 查询etcd存储
12. Kube-apiserver List查询资源简要流程
13. k8s数据是如何存储在etcd中
/registry/clusterrolebindings/system:coredns
/registry/clusterroles/system:coredns
/registry/configmaps/kube-system/coredns
/registry/deployments/kube-system/coredns
/registry/events/kube-system/coredns-7fcc6d65dc-6njlg.1662c287aabf742b
/registry/events/kube-system/coredns-7fcc6d65dc-6njlg.1662c288232143ae
/registry/pods/default/apisix-7fcc6d65dc-jvj26
/registry/pods/default/apisix-7fcc6d65dc-mgvtb
/registry/replicasets/kube-system/coredns-7fcc6d65dc
/registry/secrets/kube-system/coredns-token-hpqbt
/registry/serviceaccounts/kube-system/coredns
14. etcd收到apiserver查询pod请求是怎样的呢?
• Apiserver分页请求etcd server的
gRPCKV模块的Range接口(单
key、范围查询等),默认线性读
模式,强一致性
response type =
/etcdserverpb.KV/Range, request
count = 0, request size = 53,
response count = 500, response
size = 2505334, request content
= key:"/registry/pods/default/"
range_end:"/registry/pods/defaul
t0" limit:500
15. etcd读请求流程-kubernetes是如何从etcd查
询数据的
• etcd gRPC KV Server收到请求
后,则进入KV模块的Range接
口, etcd 3.1版本后线性读实现
是readIndex机制,它需要从
leader获取最新已提交的日志索
引号(commitedIndex)
• 等待本节点已经应用到状态机的
最高索引号大于等于leader返回
的commitedIndex后才能允许
读
• 从索引树中获取key对应的最新
版本号
• 然后再优先从cache中获取,若
未命中则从boltdb获取
16. etcd常见故障
17. 搞崩etcd典型案例分析-event大量写入
18. 搞崩etcd典型案例分析-大量list查询,流量内存暴涨
19. 如何发现更多影响etcd稳定性的隐患呢? - 多维度集群巡检
20. 如何保障及提高etcd稳定性? – 全景图
21. 大规模etcd集群治理
22. 大规模etcd集群治理挑战-业务背景
大规模的etcd集群
对外提供etcd产品
化服务,支撑腾讯
上百万开发者和企
业用户使用腾讯云
的TKE、EKS、
EDGE、Mesh等云
原生产品服务
数万的k8s全托管和
独立集群,总集群 和斗鱼、微盟等公
规模核数千万级 心等场景
司的网关、注册中
23. 大规模etcd集群治理挑战-运维
集群增
删改查
监控及
告警
巡检及
自愈
热迁移
备份及
恢复
24. 大规模etcd集群治理挑战-内核
数据不一致
内存泄露、死锁等
性能
QoS
跨城容灾
25. 设计目标
26. 方案选型
27. kstone架构
28. 可视化etcd管理平台
29. 可视化查看k8s对象
30. 基于operator的自动化集群管理
31. Kstone CRD资源之EtcdCluster Anno/Spec
•etcd集群/EtcdCluster,如右图,
•支持多种clusterType,VM集群、容器
化集群、存量集群等
•通过Anotation控制多个Feature开关,
一键开启监控、备份、健康巡检、一致
性检查等特性
32. Kstone CRD资源之EtcdCluster Status
•Status.FeatureGates,显示各个
特性开通状态
•Status.Member显示各个成员节详
细信息
33. Kstone CRD资源之EtcdInspection
•Etcd巡检任务/EtcdInspection,如右图
•支持多种巡检策略(监控、备份、健康巡
检、一致性检查),各个巡检策略支持多种
后端Prvoider实现
34. 巡检视图
35. kstone迁移任务实现
• 新增EtcdMigration迁移任务CRD,描述迁移源etcd、目的etcd集群、
迁移算法、一致性检测策略等。
• 迁移算法抽象化,支持多种Provider, 比如etcd v2->v3, v3->v3冷迁
移,v3-v3热迁移。
• 支持多种维度的数据一致性检查策略,比如etcd维度的数据一致性检
查,k8s应用层的资源对象一致性检查等。
• 针对k8s场景迁移etcd导致的client list-watch hang住问题(迁移后的
etcd版本号(apiserver resource version)小于原有etcd,修改k8s版本
源码,增加watch操作的timeout机制。
36. Kstone-etcd数据迁移任务可视化查看
某业务 1178个
节点的大规模集
群快速迁移etcd
效果(整个流程仅
耗时34s)
37. 数据冷备份-分钟级备份到cos等对象存储
38. 跨城数据热备份-方案一
优点:
• 各地域网络互通后,部署简单,无需运维额外
组件
• 数据跨城强一致同步,3 节点部署场景中,可
容忍任一城市故障,并且不丢失任何数据
缺点:
• 在 3 节点部署的场景下,任意写请求至少需要
两个节点应答确认,而不同节点部署在各地,
ping 延时会从几毫秒上升到 30ms 左右(深圳 -
上海),因此会导致写性能急剧下降。
• etcd 默认的读请求是线性读,当 Follower 节点
收到 Client 发起的读请求后,它也需要向
Leader 节点获取相关信息,确认本地数据追赶
上 Leader 后才能返回数据给 client,避免读取
到旧数据等,在这过程中也会导致 etcd 读延时
上升、吞吐量下降。
• 跨城网络质量抖动
39. 跨城数据热备份-方案二社区make-mirror机制
优点:
• 主 etcd 集群读写性能高,整体上
不受跨地域网络延时、网络质量波
动影响
• 若业务可容忍短暂不一致,可就近
访问距离最近的 etcd 集群
• 不依赖高版本 etcd
缺点:
• 当写请求较大的时候,备集群可能
存在一定的数据落后,可能读到脏
数据。
• 社区自带的 make-mirror 同步链路
中断后,退出重启会再次进入全量
同步模式,性能较差,无法满足生
产环境诉求。
• 社区自带的 make-mirror 工具缺少
leader 选举、数据一致性检测、日
志、metrics 等一系列特性,不具
备生产环境可用性。
• 不支持同步非 key-value 数据,如
auth 鉴权相关数据、lease 数据
等。
40. 跨城数据热备份-方案三learner
优点:
• 各地域网络互通后,部署简单,只需往
etcd 集群中添加一个 Learner 节点,无需运
维额外组件
• Learner 节点可同步任意类型数据,如 key-
value、auth 鉴权数据、lease 数据
缺点:
• Learner 节点只允许串行读,也就是业务如
果就近读,会读到旧数据。
• 依赖高版本 etcd,etcd 3.4 及以上版本才支
持 Learner 特性,并且只允许一个 Learner
节点 .
• 主集群全面故障后,无法快速将 Learner 节
点提升为可写的独立 etcd 集群。
41. 跨城数据热备份-etcd同步服务mirror-plus版本
mirror-plus方案make-mirror 的加强版,为了解决 make-mirror 的各种缺陷,它实现了以下特性、优
点:
• 支持多种同步模式,全量同步、断点续传,不再担忧专线、公网网络质量抖动
• 高可用,负责同一数据路径复制的实例支持多副本部署, 一副本故障后,其他副本将在 5 秒后获
得锁,在之前实例同步的进度基础上,进行快速恢复
• 支持一致性检查(全量数据检查、快照检查)
• 支持多实例并发复制提升性能(不同实例负责不同的路径),建议生产环境配置多实例,每个实
例负责不同路径
• 良好的运维能力,基于 k8s deployment 一键部署,丰富的 metrics、日志,完备的 e2e 测试用例覆
盖核心场景(http/https 场景,服务异常中断、网络异常等 )
42. 跨城数据热备份-etcd同步服务raft版本
优点:
• 具备 etcd-syncer 之 mirror-plus 版本的所
有特性和优点,同时不依赖 etcd mvcc 历
史数据。
• 基于 etcd 底层的 Raft 日志同步数据,可
以同步 key-value、auth、lease 等各种类
型的数据。
• 不依赖高版本的 etcd。
缺点:
• 一定的开发时间。
43. etcd QoS特性-保障etcd集群稳定性
44. etcd QoS特性-event分场景设置限速器
• etcdctl qos class add normal-event-read QDiscTokenBucketFilter 20
20
• etcdctl qos class add normal-event-write QDiscTokenBucketFilter 20
20
• etcdctl qos class add abnormal-event-read QDiscTokenBucketFilter
1 1
• etcdctl qos class add abnormal-event-write QDiscTokenBucketFilter
1 1
45. 案例-扫描key过多和db即将满异常场景严格限速
• etcdctl qos rule add rule-event-read normal-event-read 1
SubjectPrefix /,2 OpGet
• etcdctl qos rule add rule-event-write normal-event-write 1
SubjectPrefix /,2 OpPut,OpDelete
• etcdctl qos rule add rule-event-read-expensive abnormal-event-
read 5 SubjectPrefix /,2 OpGet '*' ConditionNumberOfScanKey 1000
• etcdctl qos rule add rule-event-db-quota abnormal-event-write 8
SubjectPrefix /,2 OpPut '*' ConditionPercentDBQuotaUsed 90
46. etcd QoS特性-限速效果
47. Kubernetes master组件治理
48. TKE 用户集群管理模式
两种管理模式
• Master 托管模式 —— 所有租户的托管集群的管理面(Master 、etcd)
全部作为服务由一个 Kubernetes 集群维护,稳定性更高、扩展更简单。
适合一般业务或集群规模变化比较频繁的场景;
• 独立集群模式 —— 集群的管理面运行在集群本身的 IaaS 资源上,集群隔
离性和独立性更好。适合对集群定制化更高的场景;
集群功能
• 自定义参数、多种运行时和发行版
• CVM、黑石节点、节点池、节点自动扩缩容
• 集群版本升级
• Addons机制
49. master组件治理挑战分析
• 如何解决数万集群的master组件运维问题(用户集群快速创建变更、节点
故障等)
• 如何按需扩缩容,实现成本与高可用平衡?(高负载自动扩容、低负载根
据画像缩容)
• 如何简化运维复杂度,实现高效运维?(管控集群节点安全下线、监控、
巡检、变更)
50. 大规模组件运维-k8s in k8s and master-operator
思路
k8s提供了完善的发布、自动扩缩容、监控等能力,是否可以用k8s来管理用户 k8s
Master,根本性的解决k8s Master运维问题
Master部署与运维
•利用k8s CRD机制编写插件 Master-operator
•声明式API解决一致性问题
•每个k8s集群在MetaCluster中占用一个namespace
•Deployment支持快速扩容、滚动升级和健康检查
•Pod Pending事件自动触发MetaCluster节点扩容
51. 整体架构
52. 可用性与成本优化-画像服务
• workload-controller负
责deployment、
statefulset等负载类型的
画像CRD生成
• workload-
recommender是基于
vpa扩展开发的资源推荐
组件,支持多种推荐算
法,各个workload支持
声明使用指定的推荐算
法
• 数据源支持metrics-
server、prometheus
53. 可用性与成本优化-autopilot组件架构
• ClusterScaler CRD
描述了集群各个组件
扩缩容触发的事件源
和指标、扩缩容冷静
期、扩缩容开关等
• 支持多种scaler, 比
如常用的cpu和内存
使用率、oom事件、
集群大小等
• 支持多种resource
estimator,如基于
oom时的内存预估、
画像服务推荐的资源
配置、集群大小等
54. 可用性与成本优化-基于真实负载的自动缩容
• 扩缩容过程可视化、结
果持久化
• 支持dry run
• 支持按用户、标签、组
件等配置不同缩容阈值
• 数千集群存在低负载
• 通过autopilot组件每年
节省大量成本费用
55. 可用性与成本优化-基于OOM事件快速自动扩容
• 支持多种扩容事件源、
scaler
•常用的cpu和内存使用
率、oom事件、限速等核
心metrics、黑盒连通性
测试等
•支持多种异常场景的根
因分析(root cause)
•扩容过程可视化并推送
到运维中心
•快速速响应扩容,缓慢
缩容
56. metacluster高效运维-kvass解决大集群监控稳定性、扩展
性
• 轻量,安装方便
• 支持数千万series规模 (数千k8s节
点)
• 无需修改Prometheus配置文件,
无需加入hash_mod
• target动态调度
• 根据target实际数据规模来进行分
片复杂均衡,而不是用hash_mod
• 支持多副本
57. metacluster高效运维-节点高效治理之缩容
• 支持通过多种策略获取
待缩容节点
• 检查及设置每个组件设
置pdb策略,确保节点
下线时服务可用性不受
影响
• 支持通过多种策略来驱
逐节点上的Pod
• 支持dry run和限速,节
点下线流程更加可靠
58. metacluster高效运维-节点高效治理之扩容
• 标准化,分组管理
(CPU、内存、GPU、
AMD/ARM)
• 模板化,自动化,降低
操作成本(弹性伸缩,
自动扩容)
• 统一的label,taint,
支持批量更新(快速扩
容,精准调度)
• 自动化、批量维护节点
(自动升级、自动恢
复)
59. metacluster高效运维-gitops云原生运维平台
• 基于gitops流程管理多
产品、多地域、多环
境、多版本、多种类型
组件
• 一键开区,高效部署支
撑集群与组件,极大避
免了人为操作失误
60.