Label 与 Selector 实战:Service 如何精准匹配 Pod
Service 能不能把流量转给正确的 Pod,核心不在 Service 名字,而在 Label 和 Selector。只要标签设计混乱,Service、Deployment、调度策略和运维筛选都会一起变乱。
共找到 320 篇相关文章
Service 能不能把流量转给正确的 Pod,核心不在 Service 名字,而在 Label 和 Selector。只要标签设计混乱,Service、Deployment、调度策略和运维筛选都会一起变乱。
Service 是 Kubernetes 网络模型里最关键的抽象之一。只要你不想让上游直接依赖 Pod 的临时 IP,就必须理解 Service、Endpoints 和服务发布架构之间的关系。
DaemonSet 的创建并不难,真正有技术含量的是更新和回滚。因为它管理的是分散在各个节点上的基础组件,一次镜像变更往往会影响整片集群,所以更新节奏和回退路径必须心里有数。
有些服务天然不是“按副本数”部署,而是“每个节点都要有一份”。日志采集、监控探针、存储代理之类的组件就是典型代表,而 DaemonSet 正是 Kubernetes 为这类节点级常驻服务准备的控制器。
StatefulSet 真正让人觉得“像状态集群”的地方,不是名字带序号,而是每个实例都能被稳定地找到、彼此通信并形成拓扑。把这件事搞明白,很多中间件为什么适合用 StatefulSet 就一目了然了。
StatefulSet 的难点从来不在“怎么创建”,而在“怎么改、怎么删、怎么灰度、怎么回退”。因为一旦对象背后带着真实数据和固定身份,任何一次操作都不只是副本数量变化,而是业务状态变化。
StatefulSet 不是“更高级的 Deployment”,而是 Kubernetes 专门为有状态应用准备的控制器。只要业务需要固定身份、稳定域名、持久化存储或者有序启动与停止,StatefulSet 才是更正确的建模方式。
把镜像跑在 Docker 里只是第一步,真正把服务搬进 Kubernetes,还要补齐副本策略、探针、资源边界、环境变量和服务验证。把这些模式整理清楚后,前端、Go、Java 乃至通用开源服务的迁移方法就会变得非常清晰。
同样是更新 Deployment,为什么有时会先删旧 Pod 再起新 Pod,有时却能一边上线一边保持服务可用?核心差别就在 `.spec.strategy`。把更新策略看明白,才能真正把 Deployment 用到生产级。
Deployment 是 Kubernetes 管理无状态应用最常用的对象。它真正解决的问题,不只是“拉起几个 Pod”,而是把副本管理、版本变更、回滚、扩缩容和上线过程可视化统一到了同一套工作流里。