Kubernetes亲和力入门:概念、分类、场景与配置详解
亲和力与反亲和力是 Kubernetes 精细化调度的核心能力之一,可以控制 Pod 更倾向于落在哪类节点,或避免与哪些工作负载靠得太近。本文先把 Affinity 的概念、分类、场景和配置方法讲清楚。
共找到 320 篇相关文章
亲和力与反亲和力是 Kubernetes 精细化调度的核心能力之一,可以控制 Pod 更倾向于落在哪类节点,或避免与哪些工作负载靠得太近。本文先把 Affinity 的概念、分类、场景和配置方法讲清楚。
理解了拓扑扩散约束的概念之后,更关键的是把它真正落到业务部署上。本文通过一个副本均匀分布的实操案例,演示如何借助拓扑域约束提升服务容灾能力。
当我们希望副本在不同节点或不同可用区尽量均匀分布时,topologySpreadConstraints 是最直接的调度手段。本文围绕该能力的工作机制、YAML 写法和关键参数做一次系统拆解。
拓扑域是 Kubernetes 调度体系里非常重要的一层抽象,用来描述节点之间的物理或逻辑边界。理解拓扑域、拓扑键以及不同划分方式,是后续实现跨节点和跨机房高可用调度的基础。
Kubernetes 中的高可用并不只是多副本这么简单,更关键的是让 Pod 在节点、机房与资源层面做到合理分布。本文从典型调度失衡场景切入,梳理服务高可用的风险来源与优化思路。
当服务已经通过 Kubernetes 原生能力完成通信之后,Eureka 就不再是必须组件。把注册中心缩容下线并完成最终访问验证,才意味着这次 SpringCloud 到 Kubernetes 的迁移真正完成。
升级镜像准备好之后,下一步就是把服务在 Kubernetes 中切换到新的配置和新镜像。重新部署的关键在于验证服务已经真正按新模式运行,而不是仅仅 Pod 变成 Running。
代码改完还不够,最终上线依赖的仍然是新的镜像版本。把升级后的 receive 和 handler 分别完成构建、打包、制镜和推送,才算为后续灰度替换做好准备。
真正的去中心化改造,最终还是要落回代码配置层。把 receive 和 handler 从依赖 Eureka 的配置切换到 Kubernetes 原生通信模式,才意味着架构替换迈出了实质性一步。
去掉 Eureka 不能一上来就删注册中心,而要先给现有服务准备好 Kubernetes 原生的替代路径。先为 handler 创建稳定的 Service,是去中心化改造里最关键的过渡动作。