6 张图带你深入了解 kube-scheduler

本文目录：

• kube-scheduler 用途
• Scheduler Pod 调度流程
• 源码调用链路
• Scheduler Framework
• 如何扩展

kube-scheduler 用途

顾名思义：负责将 Pod 调度到 Node 上。

K8s 集群巡检

上次发文 K8s 无备份，不运维，文章开篇，插入了一张 K8s 集群巡检的图片，好多小伙伴私信留言，问我要开源地址。由于其通用性不高，大多数公司需要结合自身的架构情况进行不同的巡检，所以我没有开源。

今天发现有小伙伴还在群里讨论，有没有类似的工具/平台，虽然没有开源，我把其关键的 巡检指标 和 后端核心伪代码 分享出来，供各位同行参考。

K8s CPU Throttle 优化方案

CPU Throttle 问题详解

受内核调度控制周期（cfs_period）影响，容器的 CPU 利用率往往具有一定的欺骗性，下图展示了某容器一段时间的 CPU 使用情况（单位为0.01核），可以看到在 1s 级别的粒度下（图中紫色折线），容器的 CPU 用量较为稳定，平均在 2.5 核左右。根据经验，管理员会将 CPU Limit设置为 4 核。本以为这已经保留了充足的弹性空间，然而若我们将观察粒度放大到 100ms 级别（图中绿色折线），容器的 CPU 用量呈现出了严重的毛刺现象，峰值达到 4 核以上。此时容器会产生频繁的 CPU Throttle，进而导致应用性能下降、RT 抖动，但我们从常用的 CPU 利用率指标中竟然完全无法发现！

将 oVirt 虚拟机迁移到 KubeVirt

上篇，我们 从0开始装一套 KubeVirt 1.2.1

K8s 驱逐场景以及规避方案

Pod 驱逐场景总结

从一个 SRE 角度看， Pod 驱逐分为两种情况：

• 较安全驱逐 & 提高稳定性的良性驱逐
  • API 发起驱逐，典型案例：kubectl drain
  • Node Not Ready 时，Controller Manager 发起的驱逐
• 有风险的驱逐
  • 节点压力驱逐
    • 节点磁盘空间不足、内存不足 或 Pid 不足， kubelet 发起驱逐
    • 节点内存不足，内核发起 OOM
  • 节点打污点（NoExecute），导致 Pod 被驱逐，或者移除亲和性标签，导致 Pod 被驱逐， Controller Manager 发起的驱逐
  • Pod 超过自身 Limit 限制， 内核用满，临时存储用满等
  • 优先级抢占驱逐

从0开始装一套 KubeVirt 1.2.1

KubeVirt 架构

架构

• virt-api : 负责提供一些 KubeVirt 特有的 api，像是 console, vnc, startvm, stopvm 等。
• virt-controller : 管理和监控 VMI 对象及其关联的 Pod，对其状态进行更新。
• virt-hander : 以 DaemonSet 运行在每一个节点上，监听 VMI 的状态向上汇报，管理 VMI 的生命周期。
• virt-launcher : 以 Pod 方式运行，每个 VMI Object 都会对应一个 virt-launcher Pod，容器内有单独的 libvirtd，用于启动和管理虚拟机。

K8s 多集群思考、实践和探索

为什么需要多集群

• 多活建设：提高业务应用的可用性，避免单个集群或单个数据中心故障导致业务应用暂时不可用。
• 混合云建设：引入公有云弹性资源解决业务大促节假日资源洪峰
• 控制故障爆炸半径

建设多集群的前期准备

• 多集群生命周期管理（新建集群、新增节点等）

• 多集群应用的分发部署

• 多集群监控告警

• 南北流量如何管理

• 东西流量如何管理

• 多集群应用迁移

kube on kube 实现思路分享

这里的 kube on kube ， 是指建立 K8s 元集群，纳管其他业务 K8s 集群，通过声明式 API 管理集群的创建、增删节点等。

参考 https://github.com/kubean-io/kubean 源码进行编写，进行了裁剪。感谢 DaoCloud 开源！ 👍👍

背景

随着容器化覆盖率的逐步增加，越来越多的业务迁移到 K8s 集群中， 考虑到同城双活、不同业务的复杂性以及耦合度，需要部署维护多套 K8s 集群，如何高效、可靠的在数据中心管理多个 k8s 集群是我们面临的关键挑战。

我们的虚拟化变革之旅

译自：https://blog.taboola.com/our-journey-of-virtualization-change/

黑暗时代

我们最初采用oVirt作为我们的虚拟化平台，事实证明它是一个很好的产品，具有几个显着的优势。其开源性质使我们能够利用广泛的功能和定制选项。

然而，尽管它具有优势，我们还是遇到了一些缺点和问题，迫使我们寻求更好的虚拟化解决方案。两个主要缺点是它没有任何可用的 DFS 和库存管理问题。此外，我们偶尔会遇到 oVirt 的性能问题和稳定性问题。一些资源密集型工作负载出现延迟或意外行为，影响了虚拟化环境的整体性能。随着我们的基础设施的发展，这些问题变得更加明显，导致生产力和用户满意度下降。

Calico 异常重启问题复盘

集群内网络架构为，基于Calico BGP 的路由模式，直接与交互机建联。

影响范围和故障时间线

影响范围

线下环境 node-xx 物理机上 Pod 网络不可用

影响时间线（2023-07-23 22:09 ~ 22:14）

[22:13] 收到网工反馈 Peer Down