腾讯大规模云原生平台稳定性实践

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
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.

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-15 02:54
浙ICP备14020137号-1 $bản đồ khách truy cập$