顾静, 阿里云 邓隽, 阿里云 Kubernetes 异常配置检测框架 我们来自阿里云容器服务 • 顾静，研发工程师 • 邓隽，技术专家 我们参与打造 • 容器服务（ACK/ASK） • 容器镜像服务（ACR） • 服务网格（ASM） • … 1 Kubernetes 典型异常 2 检测框架演进 3 生产实践 4 总结 Kubernetes 使用日常 • 应用部署 • • 集群扩容 • 组件升级 • … • 找出集群不正常工作的原因 : ( Kubernetes 典型异常 组件异常 • API Server Load Balancer 异常 • API Server Pod 异常 影响 • 通过 API Server 访问集群概率失败 • 升级集群失败 Load Balancer Service Master API Server Pod Server Pod Kubernetes 典型异常 网络异常 • 安全组、路由表配置错误 • 节点防火墙软件等修改 iptables、内核参数 • 网络链路长，手动排查成本高 异常影响 • 应用间无法正常通信 • 集群内 Controller 无法正常工作 YUM 安装自动运维工具 自动安装依赖 firewalld 网络未知原因导致异常 Node Pod eth0 调用 iptables

Insomnia 58. IntelliJ HTTP 客户端插件 59. KEDA 60. Kubeconform 61. mob 62. MobSF 63. Mocks Server 64. Prisma 运行时防护 65. Terratest 66. Thanos 67. Yalc 评估 68. ChatGPT 69. Codeium 70. GitHub 合并队列 71. Google Bard 72 Docker Desktop 的首选方案。我们持续在几个项目中使用它来提供 Docker 容器运行时的 Lima VM，在 macOS 上配置 Docker CLI，并处理端口转发和挂载卷。Colima 可以配置 为使用 containerd 作为其运行时，这也是大多数托管的 Kubernetes 服务上的运行时，可以提高重要的开发到 生产环境的一致性。 25. CloudEvents 试验 编写的一个零依赖的 WebAssembly（WASM）运行时。尽管运行时本身与语言无关，我们 仍想对 Go 开发者们强调 wazero，因为它提供了一种很方便的方式， 使用任何 符合标准的语言 编写的 wasm 模 块来扩展你的 Go 应用程序。它不依赖于 CGO，所以你可以很容易地将你的 Go 应用程序交叉编译到其他平台。 尽管在选择 WASM 运行时 的时候你有很多候选项，但我们仍认为 wazero

组件自身HA机制，如docker； • 多地域多可用区的容灾设计 • 管理机挂掉：对应用无影响 • 计算节点挂掉：跨机迁移 • 健康探针 ① 存活探针 ② 就绪探针 • 负载均衡 • 重启机制 ① 区分异常原因 ② 本地重启/跨机重启 • 黑名单机制 • 集群核心数据的备份和恢复 ① Etcd ② 核心数据库 • 云盘机制保护应用数据 • 举例：1.4升级1.9版本 • Pod Hash发生变化 • cluster1。该应用有25个实例，每个实例需要2个GPU卡。用 来提供图片识别的OCR服务。 • 当该服务要升级新的版本时，如果对所有实例停止，则会造 成服务中断；如果采用滚动升级，无法保证升级过程是否有 异常，以及无法充分验证新版本的可用性（即使经过了测试 阶段的测试）。 • 通常采用灰度升级的方式：即选择某一个或N个实例先升级到 新版本，在充分稳定验证后，再考虑升级其他实例，而该灰 度的过程可以分为任意批次。有时为了验证多个版本，一个 GPU上的多个VM，GPUvm将物理GPU分成几个部分，并将每个 部分分配给单个VM。 NVIDIA GRID 在硬件层面实现GPU虚拟化，每个容器可以绑定一个虚拟GPU NVIDIA Docker 通过将GPU设备及运行时的库转为volume挂载到容器中实现了容 器与驱动的解耦。但是一个GPU设备仅能挂载到一个容器中，不 支持容器间共享GPU设备 ConvGPU 仅支持内存资源的共享且仅处理单个GPU 容器使用GPU的问题：

风险识别自愈能力升级 • 传统运维体系的效率问题 - 应用启动流程复杂 - 决策链路较长 - 状态一致性风险 容器平台 监控 VIP 服务注册 配置中心 运维平台 观察者 异常消费 基础设施 异常来源• 统一容器与应用实例的生命周期 • 下沉应用的冗余度信息 容器即应用 运维平台 监控 VIP 服务注册 配置中心 启动完成 应用实例的生命周期 API Server Eviction • UnitedDeployment (coming soon) https://openkruise.iok8s 规模及性能优化实践性能优化 RT/QPS 资源使用率 链路RT/QPS 服务异常 队列长度 gRPC监控 长连接分布 请求分布 限流 Authorization Authenticatio n 序列化 压缩 版本转换 Admission Cache Storage Filter

• 硬件配置需要运行时去指定 OCI (Open Container Initiative) • From Linux Foundation • 旨在为 Container 格式和运行时创建开放行业标准。 • 该组织于2015年6月22日由Docker，CoreOS等 Container 行 业的领导人推出。 • OCI目前包含两个规范： • 运行时规范（runtime-spec

各 模块之间依赖关系错综复杂，给服务性能分析、故障定位、根因分 析等带来了诸多困难；云上系统故障率随设备数量的增加而呈指数 级增长，单一节点问题可能会被无限放大，日常运行过程中一定会 伴随“异常”发生；同时，节点分布范围更广，节点数量更多，对 日常运维过程中的日志采集、变更升级等都带来了新的挑战。基于 以上挑战，系统稳定性保障领域呈现以下特点：一是“稳保体系” 创新促进业务稳定运行。稳定的业务系统保障了企业的连续运营、 性提供了实时监测 和系统分析的能力，完善的系统可观测性相当于人体的“神经系统”， 感知系统状态、定位系统故障，协助进行容量治理及性能调优，并 通过建立基线模型和监测系统的行为模式，来检测和预测异常情况， 实现自动化运维和自愈能力。三是机器学习与人工智能提升稳定性 保障的建设成效。人工智能和机器学习技术将在系统稳定性保障技 术体系中发挥越来越重要的作用，并进一步提升落地成效。通过对 云计算白皮书（2023 算力资源也从最初的 物理机部署发展为容器化部署，实现了算力分发从命令式到声明式 的转变，即以分发结果为核心，分发过程交付给容器化部署技术自 动执行，一方面在保证分发结果的同时排除人为操作引入的异常， 极大降低出错概率与人力成本；另一方面将用户的精力从资源运维 集中到业务开发，进一步降低了云计算的使用门槛和时间成本。阿 里云公开数据显示，其云上容器服务产品基于开源的声明式算力分 发方式进行改进，可以实现几十秒内完成

Prometheus，⽀支持对集群、节点、Pod、Container 的全⽅方位监控和告警；内置 EFK、Loki ⽇日志⽅方案；内置 Grafana 作为监控和⽇日志展示； ⽀支持消息中⼼心，通过钉钉、微信通知各种集群异常事件（X-Pack）； 升级 ⽀支持集群升级； 伸缩 ⽀支持增加或者减少 Worker 节点； 备份 ⽀支持 etcd 定期备份和⽴立即备份； 恢复 ⽀支持 etcd 备份策略略⽂文件恢复和本地⽂文件恢复； 经验、使⽤用技 巧等相关知识。 KubeOperator X-Pack 增强包功能 增强功能持续增加中 对接 LDAP/AD 界⾯面⾃自定义 消息中⼼心， 通过钉钉、微信通知各种 集群异常事件 集群健康评分 通过 F5 Big IP 对外暴暴露露服务 多集群配置管理理 多云时代技术领先的企业级软件提供商 www.fit2cloud.com THANK YOU www.fit2cloud

# reboot ★第1章、部署k8s版本<=1.23 k8s在1.23及之前版本默认是调用docker作为底层的容器运行时，从1.24版本开 始移除了dockerShim组件，不再支持docker，从而默认使用containerd作为底层 的容器运行时。 k8s 1.23及之前版本： kubelet→dockerShim→dockerd→containerd→runC 默认调用的cri-socket： nerd的命令行工具为ctr，而k8s v1.24之后版本又新 增额外的辅助工具crictl crictl是遵循CRI接口规范的一个命令行工具，通常用它来检查和管理kubelet节点 上的容器运行时和镜像。（支持containerd/docker/crio） ★安装crictl工具 默认随kubeadm一起安装了，在cri-tools-xxxx.x86_64.rpm这个包里，如果想单独 安 resourceQuota-testxx.yaml ★第7章、pod控制器 pod控制器是由kube-controller-manager组件提供的一些资源，负责控制pod的创 建、删除、重新调度、运行时间等。常用的pod控制器有ReplicaSet, Deployment, DaemonSet, Job, CronJob等，如果pod被删除，则可以重新拉起一个 ★通过kind: Pod创建的容器组，在kubectl

Failed。这个状态下，Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。这个状态的出现，意味着你得想办 法 Debug 这个容器的应用，比如查看 Pod 的 Events 和日志。 5.Unknown。这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver，这很有可能是主从 节点（Master 和 Kubelet）间的通信出现了问题。 更进一步地，Pod 对象的 Unschedulable，这就意味着它的调度出现了问题。 Pod 的这些状态信息，是我们判断应用运行情况的重要标准，尤其是 Pod 进入了非“Running”状态后，你一定要能迅速 做出反应，根据它所代表的异常情况开始跟踪和定位，而不是去手忙脚乱地查阅文档。 16 www.h3c.com Confidential 秘密 16 16 K8s基本概念和术语介绍（Label） Label（标签）： La

完成调度，或正在拉 取镜像等。 Succeeded：Pod中所有容器都已成功终⽌，并且不会被重启。 Failed：Pod中所有容器都已经终⽌，且⾄少有⼀个容器异常终⽌。 Unknow：k8s的master节点与worker可能存在通信故障，⽆法确定Pod状态。 iii. Deployment(⽆状态应⽤，可在左侧功能栏应⽤/⽆状态查看详细信息) Tru Unknown：Deployment状态未知的个数 iv. Statefulset（有状态应⽤，可在左侧功能栏应⽤/有状态查看详细信息） True:有状态应处于正常的个数 False:有状态应⽤处于异常的个数 节点状态（可在左侧功能栏集群/节点查看详细信息） 56 i. 就绪：当前处于就绪（可⽤）状态的节点(包括master节点和worker节点)。 ii