Kubernetes

背景 CPU 很低但请求队列越来越长时，仅靠 CPU 扩容可能不够。HPA 指标必须与实际瓶颈和单副本处理能力建立关系。 核心判断 CPU utilization 依赖合理的 requests，先确认分母与指标可用性。 队列型任务考虑 backlog 或处理延迟等业务信号。 设定扩缩容范围、稳定窗口和依赖容量，避免副本数增长压垮数据库。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 metrics: - type: Resource resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } } behavior: { scaleDown: { stabilizationWindowSeconds: 300 } } 边界与误区 配置是 HPA spec 片段，还需 scaleTargetRef 与副本范围。扩容不会即时完成，镜像拉取和启动预热都属于响应延迟。 验证方式 用阶梯流量观察期望副本、实际就绪数、队列与 p99；再撤掉负载，确认缩容没有导致反复抖动。 小结 选择与瓶颈和 SLO 相关的指标，设置稳定窗口和最大副本避免扩缩容震荡。

背景 把密码放进 Secret 比写进镜像更容易管理，但 base64 编码本身没有保密能力。真正的安全边界是访问控制与生命周期。 核心判断 限制读取 Secret 的 RBAC 与可访问的命名空间。 按需注入指定键，避免 envFrom 暴露无关凭据。 设计轮换流程，并确认应用如何重新加载新值。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 envFrom: - secretRef: { name: api-credentials } # 生产环境应结合外部密钥系统和最小 RBAC 边界与误区 环境变量不会随 Secret 轮换自动更新。卷投射的刷新也不是实时保证，subPath 挂载行为要单独确认；备份与 etcd 静态加密同样需要考虑。 验证方式 轮换一次测试密钥，检查应用何时生效、旧密钥何时撤销以及日志是否泄露值。权限演练要验证无关 ServiceAccount 不能读取它。 小结 Secret 的 base64 不是加密，权限、轮换、挂载方式和审计才是完整控制。

背景 滚动更新不是旧副本换成新副本这么简单：流量、节点余量和连接排空都会影响中间阶段的可用容量。 核心判断 用可承受的容量下降确定 maxUnavailable，用节点余量确定 maxSurge。 就绪时间、minReadySeconds 与退出宽限期一起评估。 保留版本级别的成功率和延迟指标，异常时暂停发布。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 strategy: type: RollingUpdate rollingUpdate: { maxUnavailable: 1, maxSurge: 1 } replicas: 4 边界与误区 副本数并不等于有效处理能力，新副本未预热时不能立即承担峰值流量。终止中的 Pod 仍可能占用资源，预算不能只按理想副本数计算。 验证方式 在接近峰值的负载下发布，检查待调度 Pod、就绪时间和错误率。节点余量不足时验证发布如何停住，以及回滚是否仍有资源可用。 小结 根据最低服务容量计算 maxUnavailable 和 maxSurge，而不是照抄默认值。

背景 服务进程活着，不等于已经完成缓存预热或可以稳定接流量。把这些状态混在同一个探针里，可能导致依赖故障时不断重启。 核心判断 readiness 只决定是否接收流量，liveness 判断是否需要重启。 启动较慢的服务使用 startupProbe，给初始化单独的时间预算。 检查保持轻量，依赖失效是否摘流量要结合降级能力决定。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 readinessProbe: httpGet: { path: /readyz, port: 8080 } periodSeconds: 5 failureThreshold: 3 边界与误区 配置片段应放在容器字段下。把数据库波动直接绑定 liveness，容易放大故障；把所有外部依赖绑定 readiness，也可能让整个服务同时摘除。 验证方式 分别模拟冷启动、依赖不可用和退出过程，观察探针结果、Service 端点和请求成功率，确认摘流量不会引发重启风暴。 小结 readiness 判断服务是否能接流量，liveness 只判断进程是否需要重启。

背景与问题界定 2023 年 Kubernetes 正式宣布废弃 Docker Shim 后，核心容器运行时可选方案聚焦在 containerd 和 CRI-O 之间。某团队在进行容器运行时切换时遇到了两类截然不同的问题：选择 containerd 的测试集群发现镜像拉取非常快但内存占用偏高；选择 CRI-O 的集群在 RHEL 上运行得很稳定，但在 Ubuntu 上遇到了一些 cgroup v2 兼容性问题。更深层次的分歧在于技术理念——containerd 由 Docker 捐赠给 CNCF，继承了 Docker 的镜像管理和 API 设计哲学，强调"兼容并包"；而 CRI-O 由 Red Hat 主导开发，遵循"专为 K8s 设计"的极简路线，去除了一切 K8s 不需要的功能。选择哪一个不仅仅是技术比对，更关乎团队的运维习惯和长期生态走向。 目标拆解与工程约束 OCI 规范兼容性：运行时必须严格遵循 OCI Runtime Spec 和 OCI Image Spec，支持所有标准 OCI 镜像格式和 runtime handler（runc、kata、gVisor），不能出现某个镜像在 dockerd 能跑但在新运行时无法运行的情况。 镜像拉取与管理效率：在大规模集群中（500+ 节点同时拉取镜像），运行时的镜像层缓存机制、并发拉取策略和 GC 效率直接影响 Pod 启动速度，目标是将 Pod 启动 P99 延迟保持在 30 秒以内。 安全特性支持：必须原生支持 Rootless 容器、User Namespace Remapping、Seccomp 和 AppArmor 等安全机制，同时不能因为安全加固而显著增加容器启动延迟和运行时开销。 运维可观测性：运行时需要提供清晰的 Metrics 指标（容器启动时间、镜像缓存命中率、GRPC 调用延迟等），方便通过 Prometheus 统一监控运行时健康状态，不能成为运维的"黑盒"。 方案设计 我们从架构、性能、生态三个维度对比。containerd 的架构分为三个主要组件：containerd（守护进程，管理镜像和容器生命周期）、containerd-shim（每个容器一个 shim 进程，负责容器运行时状态管理）、ctr/nerdctl（CLI 工具）。CRI-O 则采用单一守护进程 crio + conmon（容器监控进程）+ crictl CLI 的简化结构，不需要额外的 shim 管理。 ...

背景与问题界定 某 SaaS 平台在安全攻防演练中被第三方安全团队成功侵入——攻击者通过一个被攻陷的 CI Runner Pod，利用其绑定的 cluster-admin ServiceAccount 在 2 分钟内创建了后门 DaemonSet，持久化了集群的控制权。事后复盘发现三个致命问题：超过 30 个 ServiceAccount 绑定了 cluster-admin ClusterRole 但实际上只需要 namespace 级别的读写权限；所有 Pod 都以 privileged: true 运行导致容器可以直接访问宿主机内核；没有任何 Admission Controller 对 Pod 的安全性配置进行校验。Kubernetes 的安全模型是典型的"默认准许"模式——默认情况下任何 Pod 都可以做任何事，安全必须通过显式配置来实现。 目标拆解与工程约束 最小权限 RBAC 设计：所有 ServiceAccount 必须遵循"只为完成工作所需的最小权限"原则，彻底消除 cluster-admin 的过度授权，使用 Role/ClusterRole 的细粒度 verbs 控制（get vs list vs watch vs create vs update vs delete）。 Pod 安全合规：所有 Pod 必须遵循 Pod Security Standards（PSS）的 “baseline” 级别以上的安全策略——禁止特权容器、禁止 hostPath 挂载、禁止 hostNetwork、限制 Linux Capabilities。 运行时安全检测：在 Pod 运行时层面通过 RuntimeClass 和 seccomp/AppArmor 限制容器的系统调用能力，结合 Falco 进行异常行为检测，构建运行时安全的"最后一公里"。 密钥管理安全：避免通过 Secret 存储敏感信息导致的 Base64 编码假象（只要具备 etcd 读权限即可解密），集成 External Secrets Operator 或 Vault Provider 实现密钥的外部化管理。 方案设计 RBAC 重构采用"三层角色体系"：平台级（ClusterRole）、Namespace 级（Role）、应用级（ServiceAccount+RoleBinding）。废除了所有非必要的 cluster-admin 绑定，设计了四类标准化角色： ...

背景与问题界定 某在线教育平台的实时录制系统需要在 Kubernetes 上运行——录制器 Pod 必须将音视频切片直接写入持久化存储，同时后端的转码 Worker 要读取这些文件进行 HLS 格式转换。起初团队采用了 StatefulSet 配 emptyDir 的方案，结果 Pod 因节点故障重建后所有录制数据丢失，用户端出现大面积的"回放缺失"投诉。更麻烦的是，跨 AZ 部署时，一个 AZ 中写入的 PV 无法被另一个 AZ 的 Pod 挂载，导致转码系统只能在本地读取而无法负载均衡。Kubernetes 的存储体系从 ephemeral 到持久化、从静态绑定到动态供给、从本地磁盘到分布式存储，是一套分层和扩展性极强的设计，但每个阶梯都有不同的故障模型和性能特征。 目标拆解与工程约束 存储生命周期与 Pod 生命周期解耦：Pod 重建后必须能自动挂载到之前写入数据的存储卷，保证有状态服务的"状态"不随 Pod 死亡而消失，同时支持 StatefulSet 的 volumeClaimTemplate 自动创建和绑定 PVC。 跨可用区访问与快照：存储后端必须支持跨 AZ 的 ReadWriteMany（RWX）访问模式——视频文件在一个 AZ 写入后需要被其他 AZ 的 Worker 立即读取，同时支持 CSI Snapshot 机制进行小时级定期快照防止数据损坏。 性能 Predictability：不同业务对存储 IOPS 和 Throughput 的要求差异极大——MySQL 需要低延迟（< 1ms）的块存储，日志系统需要高吞吐的顺序写，AI 训练则需要大带宽的并行文件系统。存储类（StorageClass）必须提供明确的性能分层。 存储成本可视化管理：无限制的 PVC 动态供给可能导致存储成本失控，需要利用 ResourceQuota 和 LimitRange 限制 namespace 级别的存储请求上限，同时通过标签追踪每块 PV 的归属项目。 方案设计 我们设计了四层存储性能分层模型，通过 StorageClass 的参数差异实现不同性能级别的选择： ...

背景与问题界定 某 SaaS 创业公司的早期技术栈完全构建在 Docker Compose 之上：一台 32C/128G 的裸机服务器运行着 20 多个容器，通过 depends_on 控制启动顺序，所有数据卷挂载在 NFS 共享存储上，服务发现依赖静态 links 和 network_mode: host。随着业务增长到日处理 100 万请求，这台"胖单体"服务器成了漂移的单点故障——一次 Docker daemon OOM 导致全站宕机 45 分钟。更糟糕的是，由于所有服务共用一个网络命名空间，端口冲突频发，版本升级无法滚动更新，回滚必须在 10 分钟内重装所有容器。Kubernetes 迁移势在必行，但需要一套渐进式、可回滚的迁移方案。 目标拆解与工程约束 零停机迁移：迁移过程中不能有超过 30 秒的服务中断窗口，用户请求必须在 Docker Compose 和 Kubernetes 两个"世界"之间平滑切换，支持新旧基础设施并行的灰度过渡期。 配置无感知适配：现有的 .env 文件、Compose 中的 environment 变量和 volumes 绑定挂载必须在 Kubernetes 中以等效语义运行，不能要求开发团队大量修改应用代码来适配新的运行环境。 有状态服务平滑迁移：MySQL、Redis 和 RabbitMQ 等有状态服务的数据不能丢失，需要在 Kubernetes 的 StatefulSet 中重建并同步数据，同时保证混合运行期间数据一致性。 成本可控性：从单机 Compose 到多节点 K8s 集群，基础设施成本预期会增加，必须通过合理的 namespace 规划、节点池划分和资源 requests/limits 策略控制溢出成本增长在 30% 以内。 方案设计 采用"绞杀者模式"（Strangler Fig Pattern）分阶段迁移。第一阶段是网络和数据平面的打通：在 Compose 服务器和 K8s 集群之间通过 WireGuard 组建扁平化 overlay 网络，利用 CoreDNS 的双向 DNS 解析让双方服务能互相发现。K8s 集群中的 Service 通过 externalIPs 或 metallb 暴露，Compose 服务通过 extra_hosts 指向 K8s Service IP。 ...

背景与问题界定 某跨国电商平台的 Kubernetes 集群同时承载了内部业务、第三方集成和面向公网的 API 网关，租户隔离仅靠 namespace 逻辑分隔。安全审计发现：一个被攻破的博客容器可以通过 Cluster IP 直接访问支付数据库 Pod 的 3306 端口，没有任何网络层面的访问控制。Kubernetes 原生的 NetworkPolicy 提供了五元组规则的抽象语义，但在实际生产环境中面临着性能瓶颈、策略粒度不够精细、日志审计缺失等多重挑战。随着 Cilium 基于 eBPF 的技术路线成为 CNCF 毕业项目，团队需要在 Calico 和 Cilium 之间做出符合长期技术架构方向的选择。 目标拆解与工程约束 高性能策略执行：网络策略的匹配和执行必须对 Pod 间的网络延迟产生小于 5% 的影响，在大规模集群（300+ 节点、5000+ 策略规则）下，策略更新的收敛时间不能超过 10 秒。 L7 层策略支持：除了传统的 IP:Port 五元组控制，需要支持基于 HTTP 方法、路径、gRPC 服务名、Kafka Topic 等七层协议粒度的访问控制，满足微服务粒度的最小权限原则。 日志审计与可视化：被拒绝的流量必须记录完整的客户端/服务端信息、协议类型和拒绝理由，通过标准接口导出到 SIEM 系统，同时提供可视化拓扑图用于策略编排和合规审计。 多云可移植性：网络策略的定义和 API 需要在 AWS、阿里云和自建机房之间保持语义一致，不依赖特定云厂商的网络 overlay 实现，策略即代码（Policy as Code）可版本化管理和 GitOps 化。 方案设计 我们对比了 Calico 和 Cilium 两种方案。Calico 采用基于 iptables 和 IPVS 的数据面，NetworkPolicy 通过 Felix Agent 转换为 iptables 规则链。优势是成熟稳定、社区支持广泛、对传统网络运维友好；但在大规模集群中，iptables 规则链的线性匹配导致性能退化明显，策略变更时需要全量刷新规则，5000 条规则的集群中策略收敛耗时达 30 秒以上。 ...

背景与问题界定 在大型 Kubernetes 集群中，Pod 调度直接影响应用性能和集群资源利用率。我们曾遇到一个典型场景：一个日活超千万的微服务集群，由于 Pod 被随机调度到不同可用区和机架，导致跨节点网络延迟增加 40%，P99 延迟从 50ms 飙升到 120ms。更严重的是，GPU 密集型任务被调度到没有 GPU 能力的工作节点，造成大量重调度和资源浪费。Kubernetes 调度器虽然有默认的 predicates 和 priorities 机制，但在超大规模集群（2000+ 节点）下，默认策略无法满足复杂拓扑约束和性能需求，必须通过精细化的调度策略来优化资源编排。 目标拆解与工程约束 多维度拓扑亲和性要求：Pod 需要优先调度到同一可用区（AZ）以降低跨 AZ 流量费用和延迟，同时避免将同一服务的多个副本聚集在同一故障域，防止单点故障导致整个服务不可用。 异构资源感知：集群混合部署了 CPU 密集型、内存密集型和 GPU 加速型工作负载，调度器必须能够感知节点上的 GPU 型号、本地 NVMe 磁盘等特殊资源，避免资源错配。 调度性能和稳定性：在 2000+ 节点的集群中，每个 Pod 的调度延迟需要控制在 100ms 以内，调度器高可用必须保证故障切换时不会丢失已有的调度决策和数据。 动态资源竞争：高峰期资源争抢严重，需要实现优先级抢占（Priority Preemption），确保关键业务 Pod 在资源不足时能够抢占低优先级 Pod 的资源，同时保证被抢占 Pod 的优雅终止。 方案设计 我们采用分层调度策略体系来应对上述挑战。第一层是基础的 nodeSelector 和 nodeAffinity，用于硬性约束——通过 nodeSelector 将 GPU 工作负载固定到带有 gpu=true 标签的节点池，避免调度到 CPU 节点。第二层引入 Pod 间亲和性（podAffinity）和反亲和性（podAntiAffinity），使用 topologyKey: topology.kubernetes.io/zone 将同服务的多个副本分散到不同的可用区，同时将缓存层和数据层调度到同一节点以降低延迟。 第三层是拓扑感知调度（Topology Aware Scheduling），这是 Kubernetes 1.27 进入 GA 的关键特性。我们利用 topologySpreadConstraints 实现跨拓扑域的最大均匀分布。例如对于日志采集 DaemonSet，配置 maxSkew: 1 确保每个可用区的 Pod 数量偏差不超过 1，避免单区过载。对于有状态服务 StatefulSet，通过 whenUnsatisfiable: ScheduleAnyway 配合 minDomains 实现软约束，保证节点滚动更新时调度器不会过度分散导致 Pod 创建失败。 ...