<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[2401_84561124的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/2401_84561124</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; 2401_84561124]]></copyright><item><title><![CDATA[00-全景导读-一家会自动补货的工厂]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/169250978</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/169250978</guid><author>2401_84561124</author><pubDate>Thu, 05 Nov 2026 00:15:00 +0800</pubDate><description><![CDATA[Kubernetes 不是「帮你启动容器的工具」，而是一座会自动补货的工厂：你只在工单上写「要生产 3 箱、用这个配方」，工厂自己安排车间、工人和物流，并且一旦哪里出问题，会自己把人补上、把货重做。容器像租一个房间，水电（宿主机内核）是共享的，只是房间有门禁、有额度。一句话：LXC 提供了技术，Docker 提供了体验，containerd 提供了标准，K8s 提供了调度全局的大脑。地图有了，下一篇从最底层开始：容器这间「房间」的门禁和额度，究竟是怎么装上的。组件是「谁干活」，对象是「你要什么」。]]></description><category></category></item><item><title><![CDATA[口播稿-9分钟看懂Kubernetes底座]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/169450026</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/169450026</guid><author>2401_84561124</author><pubDate>Wed, 04 Nov 2026 06:00:00 +0800</pubDate><description><![CDATA[他的逻辑跟空调恒温器一模一样：读你设定的温度，读当前室温，比较，然后制冷或加热，过一会儿再看一次。你有没有想过：你在终端敲下 kubectl apply，屏幕上只跳出三个字——created，然后过了几秒，一个 Pod 变成 Running。因为决定权在过半：3 台能坏 1 台，5 台能坏 2 台，4 台也只能坏 1 台——多养一台，抗故障能力没变，不划算。所以看到容器的退出码是 137，别怀疑人生：137 就是 128 加 9，9 是 SIGKILL，翻译过来就是「被杀了」。最上面是主菜，你的程序。]]></description><category></category></item><item><title><![CDATA[一次 kubectl apply 到底发生了什么？六阶段全链路拆解（底座认知 08·讲解篇）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/169153335</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/169153335</guid><author>2401_84561124</author><pubDate>Wed, 04 Nov 2026 00:45:00 +0800</pubDate><description><![CDATA[03：kubectl apply 之后那几秒发生了什么？apiserver 三道关、控制器展开、调度绑定、kubelet 建容器、kube-proxy 写规则，六阶段逐段拆解，附按阶段定位的排障表。]]></description><category></category></item><item><title><![CDATA[第 08 篇：一次 kubectl apply 的完整旅程：从命令行到容器落地的六阶段链路（底座认知 08）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168442863</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168442863</guid><author>2401_84561124</author><pubDate>Tue, 03 Nov 2026 07:45:00 +0800</pubDate><description><![CDATA[建议实践：在实验集群上用 kubectl apply 创建 Deployment，结合 kubectl describe、kubectl get events、crictl ps 等命令，亲自观察每个阶段的状态流转。kube-scheduler 监听到新的未调度 Pod，执行 Filter → Score → Bind，把 Pod 绑定到选定节点，绑定结果写回 etcd。若 Pod 暴露了 Service，kube-proxy 会更新 iptables/ipvs 规则，使流量能够转发到新 Pod。]]></description><category></category></item><item><title><![CDATA[第 07 篇：数据面双雄：kubelet 管生命周期，kube-proxy 管网络转发（底座认知 07）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168441834</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168441834</guid><author>2401_84561124</author><pubDate>Tue, 03 Nov 2026 00:30:00 +0800</pubDate><description><![CDATA[在节点上修改 Service 后，iptables 或 ipvs 规则会随之更新，将发往 Service VIP（虚拟 IP）/ClusterIP 的流量转发到后端 Pod。kubelet 是运行在每个节点上的核心代理，负责把节点纳入集群并管理其上的 Pod 生命周期。它通过 CRI（容器运行时接口） 与容器运行时（containerd）通信。kube-proxy 运行在每个节点上，负责实现 Service 的流量转发与负载均衡，让集群内外的请求能够访问到后端的 Pod。]]></description><category></category></item><item><title><![CDATA[Pod 为什么是最小调度单元？pause 容器到底在干什么（底座认知 03·讲解篇）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/169153166</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/169153166</guid><author>2401_84561124</author><pubDate>Mon, 02 Nov 2026 07:30:00 +0800</pubDate><description><![CDATA[02：K8s 为什么不直接调度容器？Pod 里的 pause 容器到底在干什么？本文从共享网络与同生共死的需求讲起，拆解 pause 持有命名空间的原理、共享边界与四种协作模式。]]></description><category></category></item><item><title><![CDATA[第 06 篇：调度与收敛：kube-scheduler 两阶段调度与 controller-manager 的 Reconcile 循环（底座认知 06）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168437221</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168437221</guid><author>2401_84561124</author><pubDate>Mon, 02 Nov 2026 00:30:00 +0800</pubDate><description><![CDATA[scheduler（调度器）与 controller-manager（控制器管理器）同属控制面，但分工明确：调度器决定「新 Pod 放到哪个节点」，控制器管理器负责「持续把集群状态拉回期望状态」。排障常看：Pod 长时间 Pending，多半是 Filter 阶段没有可用节点，可用 kubectl describe pod 查看调度事件。K8s 的核心哲学是「声明式 + 控制器循环」：用户声明期望状态，控制器持续对比「期望」与「当前」，并采取行动使二者收敛。]]></description><category></category></item><item><title><![CDATA[第 05 篇：etcd 深入：Raft 共识、watch 机制与快照备份恢复实战（底座认知 05）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168436705</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168436705</guid><author>2401_84561124</author><pubDate>Sun, 01 Nov 2026 07:00:00 +0800</pubDate><description><![CDATA[etcd 是一个高可用的分布式键值存储，是 Kubernetes 集群的「唯一事实来源」（source of truth）。灾难恢复时，通过 snapshot restore 生成新 etcd 数据目录，再以恢复后的数据重新启动集群。etcd 支持事务操作（compare-and-swap），可对多个键做原子性读改写，避免竞态。etcd 提供租约（lease）与分布式锁能力，K8s 的 leader 选举（如 controller-manager 选主）即基于此实现。]]></description><category></category></item><item><title><![CDATA[第 04 篇：kube-apiserver：集群唯一网关的认证、授权与准入三道关卡（底座认知 04）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168436632</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168436632</guid><author>2401_84561124</author><pubDate>Sun, 01 Nov 2026 00:15:00 +0800</pubDate><description><![CDATA[kube-apiserver 是整个集群的「大脑中枢」与「唯一网关」。集群内所有组件的通信、所有用户/管理工具的请求，都必须经过它，不存在旁路。journalctl -u kube-apiserver -f：查看 apiserver 日志。etcd：只有 apiserver 能直接读写 etcd，其他组件均绕行 apiserver。任何请求进入 apiserver，都要依次通过三道关卡，全部通过才会真正作用于集群状态。正因如此，apiserver 是认证、授权、准入控制的集中执行点，也是安全加固的核心。]]></description><category></category></item><item><title><![CDATA[容器到底是什么？一个「被隔离的普通进程」，讲透 Namespace 与 cgroup（底座认知 01·讲解篇）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/169152994</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/169152994</guid><author>2401_84561124</author><pubDate>Sat, 31 Oct 2026 07:30:00 +0800</pubDate><description><![CDATA[01：容器不是小虚拟机，而是宿主机上一个被 Namespace 隔离、被 cgroup 限制的普通进程。本文讲透六种命名空间、cgroup v2 驱动坑、OOMKilled 137 与 QoS 排序，并给出可验证的命令。]]></description><category></category></item><item><title><![CDATA[一张图看懂 Kubernetes：控制面与数据面到底谁管什么（底座认知 00·讲解篇）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/169152915</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/169152915</guid><author>2401_84561124</author><pubDate>Sat, 31 Oct 2026 00:00:00 +0800</pubDate><description><![CDATA[00：K8s 组件太多记不住？先建立一张地图：控制面四组件各管什么、数据面各管什么、日常就那几个核心对象，以及一次部署里谁先谁后。看完再进细节，不容易迷路。]]></description><category></category></item><item><title><![CDATA[第 03 篇：为什么 K8s 的最小调度单元是 Pod 而不是容器：pause 容器与边车模式（底座认知 03）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168436525</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168436525</guid><author>2401_84561124</author><pubDate>Fri, 30 Oct 2026 07:00:00 +0800</pubDate><description><![CDATA[每个 Pod 都会有一个 pause（沙箱）容器，它是整个 Pod 的「骨架」：负责持有 Pod 级别的网络命名空间、IPC、UTS 等，业务容器共享它创建的这些资源。Pod 自身的状态包括 Pending（等待调度）、Running（运行）、Succeeded（正常退出）、Failed（异常退出）、Unknown（状态未知）。Pod 才是 K8s 的最小调度单元。在业务容器之前按顺序运行的初始化容器，用于做环境准备（等待依赖、初始化配置、权限校验），完成后退出。Pod 内承载实际业务的容器，是核心负载。]]></description><category></category></item><item><title><![CDATA[第 02 篇：镜像分层与 containerd 2.x 实战：SystemdCgroup 与 pause 镜像配置踩坑（底座认知 02）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168436398</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168436398</guid><author>2401_84561124</author><pubDate>Fri, 30 Oct 2026 00:15:00 +0800</pubDate><description><![CDATA[containerd 2.x 中，Pod 沙箱（pause）镜像配置在 pinned_images.sandbox 字段，而不是 1.x 的 sandbox_image 字段。K8s 1.24 起默认不再需要 Docker 作为运行时，主流运行时是 containerd 与 CRI-O。容器对文件系统的任何修改都写在这层，镜像本身保持不可变——这正是「一个镜像能同时启动多个互不影响容器」的关键。containerd 的职责分为两大块：一是管理镜像（拉取、存储、解包），二是通过 shim 管理容器生命周期。]]></description><category></category></item><item><title><![CDATA[第 01 篇：容器的本质：Namespace 隔离与 cgroup 限制，OOMKilled 137 的完整链路（底座认知 01）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168436199</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168436199</guid><author>2401_84561124</author><pubDate>Thu, 29 Oct 2026 06:15:00 +0800</pubDate><description><![CDATA[完整链路：容器内存使用量超过 cgroup 内存上限 → cgroup 无法再分配内存 → 内核 OOM Killer 介入，把超限容器进程杀掉（SIGKILL）→ K8s 检测到容器退出，状态记为 OOMKilled。它的本质是：一个运行在宿主机上的普通进程，只是被操作系统施加了两类机制，从而呈现出「独立」的外观。这意味着：隔离让容器「像独立机器」，限制让容器「吃不下超出的资源」，二者结合才形成可安全共存的资源环境。命名空间（Namespace）：让进程「看不到」宿主机的其他资源，实现隔离。]]></description><category></category></item><item><title><![CDATA[第 00 篇：一张地图看清容器与 Kubernetes：控制面、数据面与核心对象全景（底座认知 00）]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168436106</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168436106</guid><author>2401_84561124</author><pubDate>Thu, 29 Oct 2026 00:30:00 +0800</pubDate><description><![CDATA[今天 K8s 关注的已不只是「跑容器」，而是整个分布式应用的全生命周期：调度、弹性、存储、网络、安全、发布、自愈。容器是 K8s 承载的「最小积木」，但 K8s 的管理单元是更高一层的 Pod。容器通过操作系统层面的隔离，将应用连同其依赖打包成一个可移植的单元，从根源上解决了「在我机器上能跑」的难题。Kubernetes（常简称 K8s，因 K 与 s 之间有 8 个字母）是一个开源的容器编排平台，核心价值是：声明式地描述期望状态，并持续驱动实际状态向其收敛。控制面负责「决策」，数据面负责「执行」。]]></description><category></category></item><item><title><![CDATA[CDH第八篇：CDH 部署排错手册（系列收官）：一张表解决 7180 打不开、Parcel 失败、Kafka 起不来]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168024919</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168024919</guid><author>2401_84561124</author><pubDate>Wed, 28 Oct 2026 08:15:00 +0800</pubDate><description><![CDATA[目录一、为什么你的 CDH 总是装不好二、6 类高频故障排查表三、通用定位三步法四、三大易错细节（占故障大半）五、全系列回顾与索引六、结语一、为什么你的 CDH 总是装不好复盘大量部署案例后会发现：CDH 故障极少是"玄学"，几乎全部源于环境准备遗漏、介质细节出错、资源不足这三类人为因素。也就是说，绝大多数故障可以靠一张表 + 一个方法论定位。二、6 类高频故障排查表。]]></description><category></category></item><item><title><![CDATA[CDH第七篇：CDH 集成 Kafka 实战：CSD + Parcel 组合拳，先装 ZooKeeper 是铁律]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168024864</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168024864</guid><author>2401_84561124</author><pubDate>Wed, 28 Oct 2026 00:15:00 +0800</pubDate><description><![CDATA[目录一、为什么 Kafka 要"外挂"进 CDH二、集成前必懂：CSD 与 Parcel 的分工三、4 步完成 Kafka 集成四、小内存救命调参：Broker 堆改 256M五、功能验证：建 Topic 收发消息六、结语与系列预告一、为什么 Kafka 要"外挂"进 CDH在物联网架构案例里，海量设备上报数据先打进消息队列削峰，再落存储、进计算。Kafka 是这一层的标准选择。但CDH 5.9 的官方组件清单里没有 Kafka。]]></description><category></category></item><item><title><![CDATA[CDH第六篇：Web 向导装集群：手把手带你点出 HDFS/YARN/Hive/Oozie]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168024806</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168024806</guid><author>2401_84561124</author><pubDate>Tue, 27 Oct 2026 10:00:00 +0800</pubDate><description><![CDATA[目录一、向导总览：7 个页面走完一个集群二、逐屏实操详解三、安装慢/卡住的正确姿势四、装完后的第一轮健康检查五、常见问题速查六、结语与系列预告一、向导总览：7 个页面走完一个集群登录 http://192.168.9.233:7180（admin/admin），首次进入会自动弹出集群安装向导，流程为：欢迎页 → 集群命名 → 选节点 → 选存储库 → Parcel 分发激活→ 环境检查 → 选服务套件 → 数据库配置 → 审核 → 启动完成。]]></description><category></category></item><item><title><![CDATA[CDH第五篇：Cloudera Manager 5.14 离线安装全流程：从解压到打开 7180 控制台]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168024732</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168024732</guid><author>2401_84561124</author><pubDate>Tue, 27 Oct 2026 00:30:00 +0800</pubDate><description><![CDATA[目录一、离线安装的整体思路二、7 个步骤完整实操三、.sha1 改名 .sha：最著名的坑四、启动与控制台验证五、常见报错与排错六、结语与系列预告一、离线安装的整体思路CM 离线安装的逻辑链是：CM 主程序解压 → 告诉 CM 用哪个数据库（scm 库）→ 所有节点装 Agent→ master 搭 Parcel 本地仓库 → 启动 Server + Agent → 浏览器进 7180所有节点操作分工只有两类：master 全做，从节点只装 Agent。]]></description><category></category></item><item><title><![CDATA[CDH第四篇：CDH 元数据库实战：MySQL 5.7.22 二进制安装 + 三库三账号授权全记录]]></title><link>https://blog.youkuaiyun.com/2401_84561124/article/details/168024660</link><guid>https://blog.youkuaiyun.com/2401_84561124/article/details/168024660</guid><author>2401_84561124</author><pubDate>Mon, 26 Oct 2026 11:15:00 +0800</pubDate><description><![CDATA[目录一、CDH 为什么离不开 MySQL二、步骤 1：清理 MariaDB 冲突三、步骤 2：二进制方式安装 MySQL 5.7.22四、步骤 3：三库三账号授权五、常见报错与排错六、结语与系列预告一、CDH 为什么离不开 MySQLCM 体系里有三类元数据都要落库：元数据	存储库	访问账号CM Server 自身配置、主机清单、监控历史	cm 库	scmHive 元数据（表结构、分区、列）	hive 库	cdh。]]></description><category></category></item></channel></rss>