Kubernetes

我越来越把 Kubernetes 看成一套”调度语义系统”，而不是一个单纯跑容器的平台。它真正难的地方，经常不是 YAML 能不能 apply，而是资源、调度、控制器和云基础设施之间的因果关系有没有被想清楚。

在这个 wiki 中的重要性

Kubernetes 目前在这份 wiki 里主要连接四条线。

第一条是 API 与资源定义。kubernetes-api-groups-and-schema-validation 让我把 apiVersion、core API、GVK 和编辑器 schema 假阳性拆开看，提醒我不要为了让工具安静而篡改 Kubernetes API 身份。

第二条是平台组件安装。clickhouse-operator-installation-on-shared-clusters 和 kubernetes-crd-recording-strategy 讨论的是共享集群里的 Operator、CRD、Helm、watch 范围和生命周期边界。这里的关键不是”怎么装”，而是集群级控制器会改变整个平台对某类资源的理解方式。

第三条是弹性伸缩。kubernetes-autoscaling-workloads 和 ack-node-scaling 把 Kubernetes 的伸缩拆成 workload 层与 node 层：HPA、VPA、KEDA 改变 Pod 或副本，节点伸缩则为不可调度 Pod 补充容量。

第四条是持久化存储。 kubernetes-persistent-storage 把静态卷、动态卷和快照放到同一个判断框架里，让我意识到选型难点不在”怎么挂载”，而在”谁管理云盘的生命周期”。StorageClass 的参数定义实际上是一套存储治理规则，从 volumeBindingMode 到 reclaimPolicy，每个选择都有长期的运维成本。cnpg-recovery-incident 又把这个判断落到数据库恢复现场：Retain 能给误删 PVC 留下云盘，但不能替代快照和备份。

我会保留的系统特征

资源身份由 GVK 决定：apiVersion 和 kind 是协议身份，不是编辑器提示。
控制器是持续调和循环：Operator、HPA、VPA、node autoscaler 都不是一次性脚本，而是长期改变系统状态的控制面。
调度是第一现场：Label、Taint、affinity、PDB、resource requests 会决定 Pod 能不能落到节点上。
弹性是分层的：工作负载伸缩和节点伸缩必须配合，单独打开某个控制器不能保证系统真的变得有弹性。
存储选型是架构决策：静态卷 vs 动态卷、RWO 约束、Snapshot 策略，这些选择应该在应用设计阶段就确定，而不是部署后修补。
有状态 Operator 不能替代数据判断：CloudNativePG 可以调和 PostgreSQL 实例，但恢复时仍要先确认权威数据、PV/PVC 生命周期和 WAL 复制状态。
共享集群需要收窄边界：CRD、Operator、watch namespace、证书和 RBAC 都应该被当成平台变更管理。

对我的提醒

Kubernetes 的抽象很强，但它不会替我消灭物理约束。Pod 需要资源，节点来自云厂商库存，镜像需要拉取，PDB 会阻止驱逐，CRD 会改变 API 面。云盘不能跨可用区挂载，RWO 卷不能让两个 Pod 同时读写，Snapshot 的 forceDelete 默认开启后不可关闭。越是依赖自动化控制器，越要把这些边界提前写清楚。

对我来说，Kubernetes 最值得学习的不是某个命令，而是这种工程直觉：声明式 API 只是入口，真正的系统行为发生在多个控制循环、调度约束和基础设施能力交汇的地方。

来源：kubernetes-autoscaling-workloads · ack-node-scaling · ack-static-disk-volume · ack-dynamic-disk-volumes · ack-disk-volume-snapshots · cnpg-recovery-incident

kaikai's wiki

探索

Kubernetes

在这个 wiki 中的重要性

我会保留的系统特征

对我的提醒

关系图谱

目录

反向链接