自托管规模长到"不止一个 K8s 集群"（异地容灾、隔离的生产/测试、或给不同站点各起一丛）后，问题就变成：配置要在多集群间保持一致的复制粘贴、跨集群没法看一个全局视图、发布要逐集群操作。多集群管理与联邦（federation）解决的就是"多个 K8s 集群的...

etcd 是 K8s 的"大脑"——集群状态全在里面。前面提过它三节点、Raft 与健康排查的基础，这篇把它做深到"能长期稳着运维、坏了能救"的层面：数据膨胀与压缩（compact/defrag）、备份与恢复、节点替换、以及高负载/IO 与成员变更的坑。运维 ...

K8s 集群默认"Pod 之间所有流量全通"——这在一台机器里挺好调，但一旦被攻破或出误连，横向移动没有拦截。前面有文档引述过"网络策略（NetworkPolicy）+ CNI 能收口"的基本概念，这篇把 NetworkPolicy 做深：它到底怎么按"标签选...

应用流行"高可用 + 省资源"，靠"人半夜起来加副本"既不现实也容易手忙脚乱。Kubernetes 的 HPA（Horizontal Pod Autoscaler，水平 Pod 自动扩缩）就是让"副本数随负载自动涨落"的机制：依据指标（CPU/内存/自定义/外...

把有状态服务（数据库、文件存储、缓存）放进 K8s 后，最常见的坑是"手动 PVC 建盘、数据写进宿主机某目录、换节点/重建就丢或路径不对"。K8s 的存储抽象（StorageClass + PVC + PV + CSI 驱动）解决的是"让 Pod 申请"一块...

K8s 集群里，"该把 Pod 放到哪台机器"这件事，除运维手脚外还由调度器决定。默认调度只顾"资源够不够、合不合规则"，但常需要更细的"策略约束"：某关键 Pod 要"独占这台 GPU 机器"、某节点要"只给专用业务不让别的小 pod 来挤"、或在宕机维护时...

很多把应用丢进 K8s/Docker 的人会遇到两类"恐怖故事"：一个"装成小角色"的容器把整台宿主机的内存吃满、把别的工作全拖死；或者反过来，给容器开了根本不用的高配，导致宿主明明没多少实例却总觉得资源不够。根因是"没给容器/工作负载设定资源边界"。K8s ...

把应用放进 K8s 后，发版是一道高频且易翻车的工序：直接全量替换有"新旧不衔接"的停顿与回滚难，很多人只能"深夜窗口一把梭"。K8s 内置了"发布策略"（Deployment 的 rolling/Recreate，StatefulSet/Operator 的...

Kubernetes 集群里，权限管理往往是"看着不起眼、出事才追悔"的部分：很多人图省事用管理员账号（cluster-admin）干所有事，结果一个被攻破的 CI 令牌、一次误操作的 kubectl 就能把整个集群掀翻。K8s 的权限体系由 RBAC（基于角...

跑 K8s 的自托管，到了"数据库、Redis、有状态的中间件"这步就开始犯难：Deployment 假设 Pod 是无状态、可随时重建的，而像数据库这类服务天生是"有身份的、数据要跟着自己走的"——每次重启换一个名字、数据盘飘忽不定，完全没法跑。Kubern...