Kubernetes 稳定性保障手册：洞察+预案

Kubernetes 稳定性保障手册：洞察+预案

《Kubernetes 稳定性保障手册》系列文章：​

Kubernetes 稳定性保障手册 -- 极简版 Kubernetes 稳定性保障手册 -- 日志专题 Kubernetes 稳定性保障手册 -- 可观测性专题 Kubernetes 稳定性保障手册 -- 洞察+预案（本文）

综述​

​稳定性保障是个复杂的话题，需要有效、可迭代、可持续保障集群的稳定性，系统性的方法或许可以解决该问题。​为了形成系统性的方法，可以梳理出稳定性保障复杂性的源头，制定数据模型来对其进行描述，然后在数据模型的基础上对集群的稳定性保障进行数字化和可视化，以数据模型为内核来持续迭代对稳定性保障的理解、实践以及经验的固化。​

稳定性复杂性源头

​稳定性保障的复杂性源头，一般会有如下维度：​

系统组件数量和交互关系：随着时间持续变化 系统组件和交互的动态行为特征：不易推导和观察 系统资源类型和数量：随着时间持续变化 系统资源的动态行为特征：不易推导和观察 集群的稳定性保障动作：不易规范和安全执行

总结下来，即：​

如何有效、全面洞察集群 如何通过预案安全执行稳定性保障动作

数据模型

​可以通过 4 张图和 3 张表对洞察和预案进行数据模型的抽象：​

4 张图

​

架构关系图：描述集群组件及其交互关系 架构运行图：描述集群组件及交互的动态特征 资源构成图：描述集群资源的构成 资源运行图：描述集群资源的动态使用特征

3 张表

​

事件列表：描述集群产生的需要关注的事件 操作列表：描述集群中可以执行的管理操作 预案列表：描述集群中事件和操作的关联关系

洞察

​集群的功能由集群架构提供，功能组件基于集群资源运行，故对于集群稳定性的洞察，核心在于把握集群架构和集群资源的特征。​

1. 架构关系图

可通过形如下的数据结构描述：

{ "nodes": [ { "_id": "0ce0e913f6e5516846c654dbd81db6ecab1f684e", "name": "kube-apiserver", "description": "XXX VPC 内", "type": "managed component", "dependencies": {} }, { "_id": "f0740d8bb67520857061a9b71d4a9e4fc50bfe3d", "name": "etcd", "description": "XXX VPC 内", "type": "managed component | storage", "dependencies": {} }, { "_id": "05952a825e91cb50a81cbaf23c6941d5c3bb2c89", "name": "eni-operator", "description": "XXX VPC 内，管理 ENI", "type": "component", "dependencies": { "serviceaccount": "enioperator", "clusterrole": "enioperator", "clusterrolebinding": "enioperator", "configmaps": ["eniconfig"], "secrets": ["enioperator"] } }, { "_id": "42699513a7561e89a5f99881d7b05653a1625c51", "name": "Network Service", "description": "提供 VPC/VSwitch 等云网络资源的管理服务", "type": "cloud service" } ], "edges": [ { "_id": "38bce9ca8a0cec6d8586d96298bd63b0523fc946", "source": "eni-operator", "target": "kube-apiserver", "description": "管理 ENI 请求" }, { "_id": "93f3c21247165f0be3a969fc80f72bc1a402e9f5", "source": "eni-operator", "target": "Network Service", "description": "访问阿里云 ECS OpenAPI，管理 VPC/VSwitch 等网络资源" } ] }

​

2. 架构运行图

其中的数字表征洞察数据，可以是「异常数量」「请求流量」等。除了通过数字进行洞察，还可以使用「颜色表征健康状态」「线条粗细表征流量大小」等。

可通过形如下的数据结构描述：

{ "nodes": [ { "_id": "ea4538dc0625d06b0dc93579998e04288656050f", "name": "mutatehook", "deploy": { "type": "K8s:Deployment", "namespace": "kube-system", "replicas": 3 }, "insight": [ { "source": { "vendor": "cloud:aliyun:sls", "log_project": "xxx", "log_store": "mutatehook", "log_url": "https://sls.console.aliyun.com/lognext/project/xxx" }, "signal": { "exception": { "fuzzy": "fail OR Fail OR error OR Error" } } } ] } ], "edges": [ { "_id": "38bce9ca8a0cec6d8586d96298bd63b0523fc946", "source": "eni-operator", "target": "kube-apiserver", "insight":[ { "source": { "vendor": "cloud:aliyun:sls", "log_project": "xxx", "log_store": "xxx", "log_url": "https://sls.console.aliyun.com/lognext/project/xxx" }, "signal": { "exception": { "unauthorized": "Unauthorized", "throttling": "'Throttling' OR 'throttling'" } } } ] } ] }

​

3. 资源构成图

资源管理是个复杂的话题，通过分析集群中资源的构成关系，也可以尝试通过图结构来表征集群的资源构成，节点表征资源，边表征资源的从属或绑定关系。​可通过形如下的数据结构描述：

{ "kinds": ["vpc", "vswitch", "securitygroup", "ecs", "clb", "rds", "nat", "eip"], "tags": { "cluster/product": "xxx", "cluster/id": "2736f42d4e882ad6825d6364545a3f1cb5136859", "cluster/name": "xxx", "cluster/env": "staging" }, "nodes": [ { "kind": "vpc", "nodes": [ { "_id": "c505f21871bac7385c1387988cf226310af0831e", "id": "vpc-xxx", "description": "", "ipv4": "xxx", "tags": { "resource/creator": "product", "resource/role": "" }, "url": "https://vpc.console.aliyun.com/vpc/xxx" } ] }, { "kind": "ecs", "nodes": [ { "_id": "47c4fe5cc2585a49f07798a0b8b69cda7f8d4a23", "id": "xxx", "az": "xxx", "interfaces": { "primary": { "ip": "xxx", "eni": "xxx", "mac": "xxx" } }, "instance-type-family": "xxx", "instance-type": "xxx", "tags": { "resource/creator": "product", "resource/role": "worker", "node/container-runtime": "xxx", "node/user-networking": "xxx", "node/system-networking": "xxx" }, "status": "", "condition": "", "url": "https://ecs.console.aliyun.com/#/server/xxx" } ] } ], "edges": [ { "_id": "a754c748b2723a25c017421dd0969d00df3c000b", "source": "vsw-xxx", "target": "vpc-xxx", "description": "" }, { "_id": "c34b164eba2897cfb2b574a576672d8aa441d709", "source": "eip-xxx", "target": "ngw-xxx", "description": "" } ] }

​

4. 资源运行图

​资源使用过程中，也可以对资源及资源间的关系通过外部观测数据推测内部状态，如 log/metrics/event。与资源构成图结合，可以在静态资源的基础上叠加动态的洞察数据，直观把握集群资源的使用状态。​可通过形如下的数据结构描述：

{ "nodes": [ { "_id": "35103ac62d4ef0a314e2a5128f44c684205bea2f", "id": "vpc", "insight": [ { "source": { "vendor": "cloud:aliyun:vpc", "type": "OpenAPI" }, "signal": { "vpc/exist": "DescribeVpcs", "vswitch/count": "DescribeVSwitches" } }, { "source": { "vendor": "cloud:aliyun:ecs", "type": "OpenAPI" }, "signal": { "ecs/count": "DescribeInstances", "securitygroup/count": "DescribeSecurityGroups" } } ] }, { "_id": "6450e07dc67027f76f29fbfcb841e57200855196", "id": "ecs", "insight": [ { "source": { "vendor": "cloud:aliyun:ecs", "type": "OpenAPI" }, "signal": { "ecs/exist": "DescribeInstances", "ecs/count": "DescribeInstances", "ecs/usage": "DescribeInstanceMonitorData" } }, { "source": { "vendor": "cloud:aliyun:ecs", "type": "auto" }, "signal": { "ecs/state_change": "" } } ] } ], "edges": [ { "_id": "caa1e395c713f47766ca7bcfc20419c0be0f0803", "source": "i-xxx", "target": "sg-xxx", "insight": [ { "source": { "vendor": "cloud:aliyun:ecs", "type": "OpenAPI" }, "signal": { "exist": "DescribeInstances" } } ] }, { "_id": "537dc478d95714792b3694674d6164f72b361bb0", "source": "eip-xxx", "target": "ngw-xxx", "insight": [ { "source": { "vendor": "cloud:aliyun:vpc", "type": "OpenAPI" }, "signal": { "exist": "DescribeEipAddresses" } } ] } ] }

预案

​集群出现异常是不可避免的，需要在出现异常时安全、有效处理。​异常可以通过事件来表征，安全、有效的操作是经过评审、演练过的操作，将异常与操作结合，由异常触发操作，形成经过评审、演练的预案，可以安全有效处理集群异常。​

1. 事件列表

​集群运行过程中会产生需要关注的事件，事件自身的格式可基于社区 CloudEvents标准来使用：https://github.com/cloudevents/spec/blob/v1.0.1/spec.md。​可通过形如下的数据结构描述：

{ "events": [ { "_id": "a1ab5b61857be35a5c5b203dd84b49248161c823", "description": "restart workload manually", "event": { "id": "restart-workload", "source": "xxx", "specversion": "1.0", "type": "com.aliyun.trigger.manual", "datacontenttype": "application/json", "data": "{\"NAMESPACE\": \"\", \"NAME\": \"\", \"TYPE\": \"\"}" } } ] }

​

2. 操作列表

​为了降低误操作的可能性，同时避免异常发生时执行未经审核、验证的操作，需要定义集群中可以进行的操作列表。​可通过形如下的数据结构描述：

{ "actions": [ { "_id": "47abc5cd9d64018ebf96dc5b2d6a4fbd35a3cb6d", "name": "Action Restart Workload", "exec": "restart-workload", "env": [ "NAMESPACE", "NAME", "TYPE" ] } ] }

3. 预案列表

​在事件列表和操作列表基础上，可以将事件和操作关联起来，以事件驱动的方式处理异常，即预案。​可通过形如下的数据结构描述：

{ "plans": [ { "_id": "29a091c48d8992991ed69e8694b017a11abe3eec", "name": "Plan Restart Workload", "description": "重启 workload", "event": "a1ab5b61857be35a5c5b203dd84b49248161c823", "actions": ["47abc5cd9d64018ebf96dc5b2d6a4fbd35a3cb6d"] } ] }

全局可视化稳定性保障

​基于上述4 张图和3 张表的数据模型，形成对集群稳定性保障的洞察+预案的内核，可以衍生出一种全局可视化的稳定性保障服务。​这样的服务具有如下关键点：​

全局视角 数字化 可视化

这种服务基于两种原理实现：​

人们对图像的处理效率远高于文字 全局视角可以提供「端到端理解系统」「精准定位问题」「安全处理问题」的能力

通过交通图，可以快速了解到一个区域的道路分布和关键节点，约定俗成的红黄绿颜色可以直观表达道路的拥堵状况。在更丰富的交通图上，还会观察到诸如修路、封路等重要事件。​这样，基于可视化的方式，就可以迅速理解一个区域的交通和地理情况。​底层的数据模型是基础，应用可视化的手段，使得数据的价值更易被发挥。​

一种实现

1）部署形态

​

Region 化部署 面向 Region 内单集群或多集群提供服务

2）使用体感

​根据稳定性保障的最佳实践，将稳定性保障分为如下几个栏目：

运行链路图： 该栏目是日常稳定性保障高频使用的区域，通过可视化的能力，直观感知异常的发生、异常范围和影响程度、白屏化+可视化方式处理异常 部署架构图 该栏目用于理解集群的部署架构，感知和处理部署维度的问题 容量管理 (包括节点管理、容量规划等) 在此栏目进行 业务流程图 该栏目沉淀业务的功能流程图，一方面协助业务控制功能复杂度，一方面协助业务理解业务功能现状，共同助力业务迭代 业务相关的数据分析可放在该栏目 数据分析：该栏目服务两方面的数据需求 业务需求 查看类：集群规模等 SLI 信息、集群稳定性等 SLO 信息 查询类：根据特征查询统计信息 (如根据 label 查询资源申请等) 稳定性保障需求 查看类：集群水位等 SLI 信息，集群稳定性保障效果等 SLO 信息 查询类：根据特征查询统计信息 (如根据 label 查询关联的所有资源信息、资源泄露信息等) 可观测性管理 该栏目用管理可观测性相关事宜，包括： 观测数据生成 观测数据采集 观测数据处理 观测数据消费 可控性管理 该栏目用于管理与控制相关的操作，包括： 发布管理 灾备管理 预案管理 资源管理 混沌工程 安全管理 定期体检

系统正常运行期间：​

通过「数据分析」栏目，确认集群在「可观测性」「可控性」方面的覆盖面和精确性 在「可观测性管理」栏目，进行可观测维度的管理，包括 数据源/监控/告警补齐、治理等 在「可控性管理」栏目: 根据观测数据发现的问题，进行预案配置、issue 管理等 根据混沌工程或演练发现的问题，进行预案配置等 在「运行链路图」「部署架构图」中，通过可视化方式，将已经配置的监控、告警、预案与组件或链路结合

系统异常及恢复期间，在「运行链路图」中：​

问题跟踪过程中记录的主要内容有：​

issue 异常发生的时刻 异常处理期间执行的动作 运行链路图 snapshot 异常恢复的时刻

数据模型及竞争力分析

​数据模型是稳定性保障最佳实践进行迭代、分享和应用的媒介，通用的洞察和预案可以形成标准化的服务，个性化的洞察和预案可通过固定的结构来描述，然后使用通用的控制器来落地。​以数据模型形成洞察+预案的稳定性保障服务，技术核心为：​

洞察模型 关键问题： 如何洞察集群稳定性？ 如何洞察业务迭代效率？ 数据模型 关键问题： 如何定义有效、可扩展的数据描述?

在技术核心的基础上，可以围绕如下的竞争力进行迭代：​

洞察 全局化 数字化 可视化 效率 最短操作路径 最小使用成本 先进性 流程化最佳实践

小结

​通过 Spec 规范 7 种数据模型，我们可以基于结构化的描述来表征洞察+预案。以此为核心，不断迭代对稳定性保障的实践和理解，加速业务迭代。再扩展一步，也有可能基于该模型在发展方向反哺业务。​如果大家感兴趣，欢迎在留言区进行交流。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。