Service稳定访问网关集群核心专门解决 Pod IP 频繁变动的痛点提供永久不变的访问入口拥有固定服务名集群内 DNS 可直接解析拥有固定虚拟 ClusterIP 固定端口终身不变化内置负载均衡、故障 Pod 自动剔除能力通过标签选择器自动绑定一批拥有相同 Label 的 Pod 作为后端。Pod最小运行单元容器不能直接被 K8s 调度管理必须封装进 PodPod 是 K8s 调度、部署的最小单位。一个 Pod 内包含业务容器、配套网络 / 存储 / 隔离资源。致命缺点Pod 生命周期短暂重启、扩容、故障迁移后IP 一定会变无法作为稳定访问地址。Label标签匹配的桥梁本质是给 Pod 打的自定义贴纸keyvalue作用是分类筛选 Pod。 示例namemysql envprod versionv1.0单独标签无作用配合 Service 的标签选择器才能建立关联。三者联动完整工作流程步骤 1部署业务 Pod 并打标签部署 2 个 MySQL 实例 Pod配置标签namemysql Pod1IP10.244.1.10标签namemysqlPod2IP10.244.1.11标签namemysql步骤 2创建 Service配置标签选择器新建 Service名称mysql-server选择器规则匹配所有namemysql的 Pod。 K8s 会自动扫描全集群所有 Pod把符合标签的 Pod 收集为后端节点Endpoint。此时 Service 生成固定虚拟 IP10.96.0.10:3306。步骤 3业务客户端访问 Service订单服务、后台服务不需要写 MySQL 真实 Pod IP只访问mysql-server:3306流量逻辑 客户端 → Service 虚拟 IP → K8s 负载均衡 → 分发到任意正常 MySQL Pod步骤 4各种变化场景下的表现体现 Service 价值某个 Pod 崩溃K8s 检测 Pod 故障自动从 Service 后端列表移除流量不再发给故障实例同时自动重建新 Pod新 Pod 依旧携带namemysqlService 自动识别加入后端。 客户端全程无感知不用改任何配置。扩容新增 3 个 MySQL Pod新 Pod 同样携带namemysqlService 自动纳入负载均衡池请求自动分摊到新节点。Pod 漂移到其他服务器Pod 换机器重启IP 改变但标签不变Service 依旧识别访问地址不变。Pod 底层原理Pause 容器、Node 节点1. Node 节点Pod 运行在 Node 上Node 可以是物理服务器、云虚拟机一台 Node 能跑几百个 Pod。2. Pause 容器每个 Pod 标配一个 Pod 里可以放好几个程序容器比如主服务 日志收集工具。 K8s 会先启动一个极小的 Pause 容器所有业务容器全部共用它共享同一套网络栈同一个 Pod 内多个容器互相访问直接用本地端口不用跨机器网络通信极快共享挂载存储卷 Volume多个容器能读写同一份文件。 适用场景把紧密配合的多个程序放进同一个 Pod比如主程序 日志采集器。3. Pod 和 Service 的关系补充不是所有 Pod 都需要绑定 Service对外 / 对内需要被其他服务调用的 Pod才创建 Service 统一入口只内部后台执行、不需要别人访问的 Pod不用配 Service。K8s 集群两大角色Master 控制节点 Node 工作节点1. Master管理大脑集群的控制中心不跑业务运行 3 个核心管理进程全权管控整个集群kube-apiserver集群统一入口所有操作都走它kube-controller-manager负责资源自愈、副本维持kube-scheduler负责把 Pod 调度到空闲 Node 机器。 能力资源管理、Pod 调度、弹性扩缩容、权限、监控、故障自动修复全部自动化。2. Node干活机器干活的机器专门跑业务 Pod真正跑业务 Pod运行两个核心代理程序kubelet管本机所有 Pod创建、重启、监控、删除kube-proxy实现 Service 的负载均衡转发请求。传统系统扩容、升级有多麻烦以前没有 K8s 的时候 想多开几个服务实例、升级新版本全部靠人工操作手动选机器、手动部署程序、手动启动程序崩了没人管不会自动重启步骤多、耗时间还容易操作失误出事故。RCReplicationController副本控制器是专门管一批一模一样 Pod 的工具RC 就是专门看管一批相同 Pod 的自动管家。 Pod 是跑你项目的容器Pod 会崩、会消失人工盯着很累RC 24 小时自动值守彻底解放人工自动完成扩容、故障自愈、版本升级。 只要给对应业务创建 RC扩容、升级难题全部自动解决。写 RC 配置文件必须写三样核心内容少一个都不行Pod 模板规定你的程序镜像、环境、资源告诉 K8s 怎么创建 Podreplicas 副本数你希望同时稳定运行多少个 Pod 实例比如 3 个RC 会实时清点数量现在只有 2 个 → 自动新建 1 个。现在有 4 个 → 自动删掉多余 1 个标签选择器靠 Label 标签让 RC 识别哪些 Pod 归自己管理。你有一个网站程序打包成容器运行在 Pod 里创建 Service给网站一个固定访问地址新建 RC 配置模板网站镜像副本数3标签匹配appwebRC 自动创建 3 个网站 Pod实时盯着数量崩掉 1 个 → RC 自动新建 1 个补到 3 个流量暴涨改副本数为 5 → RC 自动多开 2 个要升级新版本修改镜像 → RC 自动替换旧 Pod。RC 和 Pod、Service 的关系Pod真正跑业务RC管控 Pod 数量、自动重建 / 扩容Service给 Pod 提供固定访问地址屏蔽 Pod 多变 IP 一套业务标准组合RC管控 Pod运行 Service访问入口使用 K8s 两大核心好处好处 1大幅缩减人力小团队就能搞定复杂分布式系统传统分布式系统需要大量资深开发、运维分工做负载均衡、部署、故障处理、扩容 用上 K8s 后 只需要少量人1 名架构师 几名开发 1 名运维底层调度、自愈、扩缩容全部由 K8s 自动实现不用人工重复造轮子降低人力成本。好处 2完美适配微服务架构微服务思想把一个庞大单体项目拆成很多独立小服务微服务痛点实例扩容、独立升级、多实例高可用很难手动维护K8s 原生配套能力支持每个服务独立扩缩容流量高自动多开实例各个服务独立开发、独立升级、互不影响不限开发语言Java/Go/Python 等全部能统一托管大厂谷歌、亚马逊、Netflix都在用微服务K8s 直接内置这套底层基础设施开箱即用。