青蛙小白

#Kubernetes

← 全部文章

Kubernetes cgroup v2 迁移：为什么新建集群比原地升级更靠谱

Kubernetes 1.35 带来了一个不小的变化：kubelet 默认拒绝在 cgroup v1 节点上启动。这可不是简单的功能弃用，而是整个 Linux 生态在资源管理架构上的一次集体转向。 生态系统的连锁反应 这次变化特殊在哪？它不是某个项目的孤立决定，而是整个生态在同步行动: systemd v256 开始默认拒绝 cgroup v1，v258 会完全移除支持。 RHEL 9.4 废弃 cgroup v1，RHEL 10 只支持 v2。 Fedora 的时间表更激进：41/42 版本默认不启动 v1，43 会完全移除。 Ubuntu 22.04 LTS 及更高版本默认使用 cgroup v2。 Debian Trixie 使用 systemd 257，默认不支持 v1。 这种同步性背后有技术原因。cgroup v1 的混合层级架构在设计上就存在复杂性问题：每个资源控制器（CPU、内存、IO）都有独立的层级树，同一个进程在不同控制器中可能处于不同位置。这种设计在容器密度增加、资源管理需求变复杂后，维护成本越来越高。

主机安全软件导致 Rook-Ceph OSD 容器启动失败的排查记录

最近在一个Kubernetes集群部署 Rook-Ceph 时遇到了一个问题：OSD Pod 的主容器能正常启动，但 sidecar 容器却一直报 RunContainerError。折腾了一番，最后发现是节点上装的终端安全软件导致的。 问题现象 部署完成后检查 Pod 状态，发现 node-1 上有几个 Pod 异常： kubectl get po -n rook-ceph -o wide | grep -v Running NAME READY STATUS RESTARTS AGE rook-ceph-osd-2-5bfd79754f-k8smh 0/2 RunContainerError 0 3m14s rook-ceph-tools-8bd944548-gh29z 0/1 RunContainerError 223 26h 查看 Pod 事件，得到的错误信息是：

使用Helm安装Cilium 1.13

Cilium是一个基于eBPF的数据平面的网络、观测和安全解决方案。它提供了一个简单的扁平化第三层网络，能够以本地路由或覆盖模式跨多个集群进行部署。 Cilium的基础是名为eBPF的Linux内核技术，它支持在Linux内核的各个集成点（如网络IO、应用程序套接字和跟踪点tracepoints）动态插入eBPF字节码，以实现安全、网络和可见性逻辑。eBPF具有高效和灵活的特性。 本文将介绍如何使用Helm安装Cilium。与Cilium快速安装相比，这需要进行一些额外的步骤，并要求你手动选择最适合你特定环境的数据路径(datapath)和IPAM模式(IPAM mode)。