做者 | 悟鹏
来源 | 阿里巴巴云原生公众号node
《Kubernetes 稳定性保障手册》系列文章:
git
稳定性保障是个复杂的话题,须要有效、可迭代、可持续保障集群的稳定性,系统性的方法或许能够解决该问题。
为了造成系统性的方法,能够梳理出稳定性保障复杂性的源头,制定数据模型来对其进行描述,而后在数据模型的基础上对集群的稳定性保障进行数字化和可视化,以数据模型为内核来持续迭代对稳定性保障的理解、实践以及经验的固化。
github
稳定性保障的复杂性源头,通常会有以下维度:
json
总结下来,即:
api
能够经过 4 张图和 3 张表对洞察和预案进行数据模型的抽象:
安全
以下:
网络
集群的功能由集群架构提供,功能组件基于集群资源运行,故对于集群稳定性的洞察,核心在于把握集群架构和集群资源的特征。
数据结构
集群架构一般能够经过图来表征,其中节点表征组件,边表征交互关系,经过图结构能够直观把握集群的架构,形以下图:
架构
可经过形以下的数据结构描述:app
{ "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 等网络资源" } ] }
集群运行过程当中,组件及交互关系能够经过外部观测数据推测内部状态,如 log/metrics/trace。与集群架构图结合,能够在静态架构的基础上叠加动态的洞察数据,更直观把握集群的健康状态,以下图:
其中的数字表征洞察数据,能够是「异常数量」「请求流量」等。除了经过数字进行洞察,还可使用「颜色表征健康状态」「线条粗细表征流量大小」等。
可经过形以下的数据结构描述:
{ "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'" } } } ] } ] }
资源管理是个复杂的话题,经过分析集群中资源的构成关系,也能够尝试经过图结构来表征集群的资源构成,节点表征资源,边表征资源的从属或绑定关系。
可经过形以下的数据结构描述:
{ "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": "" } ] }
资源使用过程当中,也能够对资源及资源间的关系经过外部观测数据推测内部状态,如 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" } } ] } ] }
集群出现异常是不可避免的,须要在出现异常时安全、有效处理。
异常能够经过事件来表征,安全、有效的操做是通过评审、演练过的操做,将异常与操做结合,由异常触发操做,造成通过评审、演练的预案,能够安全有效处理集群异常。
集群运行过程当中会产生须要关注的事件,事件自身的格式可基于社区 CloudEvents标准来使用:_https://github.com/cloudevent...
可经过形以下的数据结构描述:
{ "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\": \"\"}" } } ] }
为了下降误操做的可能性,同时避免异常发生时执行未经审核、验证的操做,须要定义集群中能够进行的操做列表。
可经过形以下的数据结构描述:
{ "actions": [ { "_id": "47abc5cd9d64018ebf96dc5b2d6a4fbd35a3cb6d", "name": "Action Restart Workload", "exec": "restart-workload", "env": [ "NAMESPACE", "NAME", "TYPE" ] } ] }
在事件列表和操做列表基础上,能够将事件和操做关联起来,以事件驱动的方式处理异常,即预案。
可经过形以下的数据结构描述:
{ "plans": [ { "_id": "29a091c48d8992991ed69e8694b017a11abe3eec", "name": "Plan Restart Workload", "description": "重启 workload", "event": "a1ab5b61857be35a5c5b203dd84b49248161c823", "actions": ["47abc5cd9d64018ebf96dc5b2d6a4fbd35a3cb6d"] } ] }
基于上述4 张图和3 张表的数据模型,造成对集群稳定性保障的洞察+预案的内核,能够衍生出一种全局可视化的稳定性保障服务。
这样的服务具备以下关键点:
这种服务基于两种原理实现:
以平常生活中的交通图为例:
经过交通图,能够快速了解到一个区域的道路分布和关键节点,约定俗成的红黄绿颜色能够直观表达道路的拥堵情况。在更丰富的交通图上,还会观察到诸如修路、封路等重要事件。
这样,基于可视化的方式,就能够迅速理解一个区域的交通和地理状况。
底层的数据模型是基础,应用可视化的手段,使得数据的价值更易被发挥。
根据稳定性保障的最佳实践,将稳定性保障分为以下几个栏目:
运行链路图:
部署架构图
业务流程图
数据分析:该栏目服务两方面的数据需求
业务需求
稳定性保障需求
可观测性管理
该栏目用管理可观测性相关事宜,包括:
可控性管理
该栏目用于管理与控制相关的操做,包括:
系统正常运行期间:
在「可控性管理」栏目:
系统异常及恢复期间,在「运行链路图」中:
问题跟踪过程当中记录的主要内容有:
数据模型是稳定性保障最佳实践进行迭代、分享和应用的媒介,通用的洞察和预案能够造成标准化的服务,个性化的洞察和预案可经过固定的结构来描述,而后使用通用的控制器来落地。
以数据模型造成洞察+预案的稳定性保障服务,技术核心为:
洞察模型
关键问题:
数据模型
关键问题:
在技术核心的基础上,能够围绕以下的竞争力进行迭代:
洞察
效率
先进性
经过 Spec 规范 7 种数据模型,咱们能够基于结构化的描述来表征洞察+预案。以此为核心,不断迭代对稳定性保障的实践和理解,加速业务迭代。再扩展一步,也有可能基于该模型在发展方向反哺业务。若是你们感兴趣,欢迎在留言区进行交流。