k-cloud-labs

代码在线跑，知识轻松学

Python精品学习库

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

博客搬家 | 分享价值百万资源包

往期视频·干货材料·成员作品 最新动态

技术创作特训营·精选知识专栏

新邀入驻腾讯云开发者社区，福利多多！

如何运用「云、端融合的数智化安全体系」高效护航数据安全

左手AI，右手安全 —— 一汽丰田数字化转型之路

线上调度器触发资源使用量报警，在定位问题的过程中又系统性的看了最新的 scheduler framework 的实现，以及涉及到的一些用来优化性能的 PR，这里做一个系统性的总结，分享给有类似问题或者需求的同志们。

调度器性能调优系列

太长不看版：在拦截 pod 创建请求时，在业务逻辑中不要直接依赖 admission request 的 pod namespace 属性。可以使用 adminssion request 的 namespace，这个属性是有值的，从请求的 path 中解析得来的。

f**king k8s - pod namespace

v1.27 的 K8s，在 kube-apiserver 的日志中会看到 “etcd event received with PrevKv=nil” 的字样，资源对象被删除后在 Etcd 中已经不存在了但在 Reflector store 中仍然存在，可以在 Informer 或者 watchCache 中看到对应的对象，依赖 Informer 的组件也不会感知到资源对象被删除，通过 List API 设置 RV=“0” 去 kube-apiserver 的 watchCache 中获取的话也可以看到已经被删除的对象仍然存在。

k8s watch 丢事件 - 3

k8s watch 丢事件 - 2

Kube-apiserver 提供了 Watch API 来支持实时接收资源对象变化的功能，也是 Informer 实现的基础，那么我们通过 Watch 或者 Informer 本地缓存拿到的数据是否真的和 Etcd 中的数据一致呢？

k8s watch 丢事件 - 1

Kube-apiserver 在处理外部请求时发生不可恢复的报错，直接 Fatal 退出运行。看日志调用堆栈，会发现 concurrent map iteration and map write 的字样。这是 golang 检测到有对 map 的并发读写后返回的一个 fatal 报错的内容，无法通过 recover 捕捉并恢复。

kube-apiserver 又 Panic 了 - handler

这个约定存在的原因是为了保持开启 WatchCache 功能前后 list 请求返回结果的一致性。在关闭 WatchCache 功能的情况下，请求直接透传给 Etcd，此时返回的结果就是字母升序排列的。

k8s 越来越复杂了吗？

大家在对 2023 年诸多互联网公司故障的总结中多次提到了控制 “爆炸半径”，几乎都在说缩小集群规模，那除了缩小集群规模外还有没有其他办法呢？如果一出问题就通过缩小规模去解决，多少会显得有点不够专业（草台班子）。k8s 已经经历了九年半的发展，众多的终端用户在以什么样的方式使用 k8s，即便社区高手如云，也很难把所有使用场景都考虑到并且处理好，但也不至于差到连我们这群"草台班子"都能想到的一些最基本的问题（比如控制爆炸半径）都想不到。比起把集群搞大出问题的人，反而是在出问题后只会喊控制集群规模的那些 k8s 相关的云原生专家们，那些 k8s 集群管理员们，更像是草台班子。（并没有说 k8s 等于云原生的意思，但只要做的事情和 k8s 沾点边就号称云原生，这是事实）

k8s: 到底谁才是草台班子？

前面已经通过一个系列来介绍 kube-apiserver cache 相关内容，本篇旨在通过分析 Watch 请求的生命周期把前面涉及到的关键内容串联起来，系统的描述在每个阶段都涉及到哪些关键内容，方便更直观的了解之前每一篇在整个过程中的位置和作用。

一条 Watch 请求的一生

之前从资源对象的获取方式、序列化、深拷贝的角度分别分析了对 kube-apiserver 内存使用量的影响以及社区是如何进行优化的，这一篇围绕网络连接展开分析其对 kube-apiserver 内存的影响，以及这中间涉及到的其他相关问题。

kube-apiserver 连接数也会影响内存？

前一篇中介绍了大规模容器平台的资源预算、精算、核算，本篇围绕容器调度开展。容器调度旨在有效地协调和管理系统中的有限资源，在保障服务 SLO 的前提下，满足任务和服务的需求。对于从事过容器调度相关工作的朋友来说，对超卖一定不陌生。容器平台一般都会对运行在其中的服务做一定程度的超卖，来达成平台本身的盈利目标。

从容器调度到降本增效

近期互联网故障频发，各大公众号各抒己见，指点江山，激扬文字，颇有百花齐放，百家争鸣的味道。一众吃瓜群众也是对此乐此不疲，津津乐道。

让子弹飞一会儿

前面我们已经对 kube-apiserver 内存消耗 进行了阐述，文中最后提到了使用流式的请求来支持 List 的效果，从而实现对于单个请求来说，空间复杂度从 O(n) 转换成 O(1)，也讲述了其原理和流程。本篇从更细节的角度分析其在内存分配，序列化等方面做的进一步优化。

kube-apiserver 内存优化进阶

继阿里云之后，滴滴崩了上了热搜，故障原因了解了一些，会在文章最后谈到。近期国内多个公司发生了 P0 事故，当然也包括我司，只不过可能不出名，很多人不知道而已。本文聊一聊我对这些故障的理解。首先做个声明，下文都是根据个人所了解到的信息以及个人的认知所写，并没有消遣的意思，可能会有一些偏激，如果问题，欢迎互喷。

从故障中我们学到了什么？

前面我们已经对 kube-apiserver 内存消耗进行了阐述，文中最后提到了使用流式的请求来支持 List 的效果，从而实现对于单个请求来说，空间复杂度从 O(n) 转换成 O(1)，这篇主要就分析描述其实现原理。

从 ListWatch 到 WatchList

前两篇已经介绍过 Informer 和 Cacher 的实现，也介绍了其中存在的一些问题，本篇主要针对 Stale read 问题展开，分析新版 Informer & Kube-apiserver 中是如何解决这个问题的。

Kubernetes 陈年老 bug - Stale Read

前一篇已经介绍了 Informer 的实现，Informer 对 kube-apiserver 发起了 list 和 watch 请求。我们知道大规模集群下，kube-apiserver 会成为瓶颈，尤其在内存方面，相信很多人也遇到过 kube-apiserver OOM 等问题（碰巧的是最近线上连续出现两次 kube-apiserver OOM 的问题）。本篇主要讲 kube-apiserver 中 Informer 需要用到的两个接口 list 和 watch 的实现。

kube-apiserver 又 OOM 了？

Informer 作为 client-go 的核心，网上有众多的源码分析，原理解析相关文章，可以教给大家如何"正确"的使用 Informer。当然其前提是在 Informer 本身逻辑没问题的前提下，本篇旨在为大家指出几个 Informer 里面长期存在甚至现在仍然存在的问题。

你真的搞懂 Informer 了吗？

最近遇到一个线上问题，使用了 lxcfs 的容器，跑在 cgroup v2 的机器上时，在容器内使用 top 或者 htop 看到的核数和 cpu 使用率有问题。虽然根本问题在 lxcfs 的实现，但问题最终的触发与 cpuset 和 cpu.max 的设置有关。这里并不会去介绍这个问题本身，而是由问题引发的思考，我们真的了解 k8s 里面的绑核行为吗，你以为你以为的就是你以为的吗？

Kubernetes 陈年老 bug - 绑核

线上 k8s 集群 kube-apiserver 的 ConfigMap Get 操作 QPS 较高，且同时间段 Etcd 中 ConfigMap 资源的 Get 操作 QPS 也较高，看日志多数请求的发起方是 kubelet。对应 k8s v1.22.13 版本代码，同时在 v1.28.0 测试现象相同。kube-apiserver 日志大致如下：

high QPS for configmap GET requests in kube-apiserver - 3

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

腾讯云开发者社区推出了k-cloud-labs专栏，为你提供了k-cloud-labs的相关文章，致力于帮助开发者快速成长与发展。

k-cloud-labs

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐