1-Kubernets基础知识

Service（稳定访问网关，集群核心）

专门解决 Pod IP 频繁变动的痛点，提供永久不变的访问入口：

• 拥有固定服务名（集群内 DNS 可直接解析）
• 拥有固定虚拟 ClusterIP + 固定端口，终身不变化
• 内置负载均衡、故障 Pod 自动剔除能力
• 通过标签选择器，自动绑定一批拥有相同 Label 的 Pod 作为后端。

Pod（最小运行单元）

1. 容器不能直接被 K8s 调度管理，必须封装进 Pod，Pod 是 K8s 调度、部署的最小单位。
2. 一个 Pod 内包含业务容器、配套网络 / 存储 / 隔离资源。
3. 致命缺点：Pod 生命周期短暂，重启、扩容、故障迁移后，IP 一定会变，无法作为稳定访问地址。

Label（标签，匹配的桥梁）

本质是给 Pod 打的自定义贴纸key=value，作用是分类筛选 Pod。 示例：

name=mysql env=prod version=v1.0

单独标签无作用，配合 Service 的标签选择器才能建立关联。

三者联动完整工作流程

步骤 1：部署业务 Pod 并打标签

部署 2 个 MySQL 实例 Pod，配置标签name=mysql： Pod1：IP=10.244.1.10，标签name=mysqlPod2：IP=10.244.1.11，标签name=mysql

步骤 2：创建 Service，配置标签选择器

新建 Service，名称mysql-server，选择器规则：匹配所有name=mysql的 Pod。 K8s 会自动扫描全集群所有 Pod，把符合标签的 Pod 收集为后端节点（Endpoint）。

此时 Service 生成固定虚拟 IP：10.96.0.10:3306。

步骤 3：业务客户端访问 Service

订单服务、后台服务不需要写 MySQL 真实 Pod IP，只访问：mysql-server:3306流量逻辑： 客户端 → Service 虚拟 IP → K8s 负载均衡 → 分发到任意正常 MySQL Pod

步骤 4：各种变化场景下的表现（体现 Service 价值）

1. 某个 Pod 崩溃K8s 检测 Pod 故障，自动从 Service 后端列表移除，流量不再发给故障实例；同时自动重建新 Pod，新 Pod 依旧携带name=mysql，Service 自动识别加入后端。 客户端全程无感知，不用改任何配置。

2. 扩容新增 3 个 MySQL Pod新 Pod 同样携带name=mysql，Service 自动纳入负载均衡池，请求自动分摊到新节点。

3. Pod 漂移到其他服务器Pod 换机器重启，IP 改变，但标签不变，Service 依旧识别，访问地址不变。

Pod 底层原理（Pause 容器、Node 节点）

1. Node 节点

Pod 运行在 Node 上，Node 可以是物理服务器、云虚拟机；一台 Node 能跑几百个 Pod。

2. Pause 容器（每个 Pod 标配）

一个 Pod 里可以放好几个程序容器（比如主服务 + 日志收集工具）。 K8s 会先启动一个极小的 Pause 容器，所有业务容器全部共用它：

1. 共享同一套网络栈：同一个 Pod 内多个容器互相访问直接用本地端口，不用跨机器网络，通信极快；
2. 共享挂载存储卷 Volume：多个容器能读写同一份文件。 适用场景：把紧密配合的多个程序放进同一个 Pod（比如主程序 + 日志采集器）。

3. Pod 和 Service 的关系补充

不是所有 Pod 都需要绑定 Service：

• 对外 / 对内需要被其他服务调用的 Pod，才创建 Service 统一入口；
• 只内部后台执行、不需要别人访问的 Pod，不用配 Service。

K8s 集群两大角色：Master 控制节点 + Node 工作节点

1. Master（管理大脑）：集群的控制中心，不跑业务

运行 3 个核心管理进程，全权管控整个集群：

1. kube-apiserver：集群统一入口，所有操作都走它；
2. kube-controller-manager：负责资源自愈、副本维持；
3. kube-scheduler：负责把 Pod 调度到空闲 Node 机器。 能力：资源管理、Pod 调度、弹性扩缩容、权限、监控、故障自动修复，全部自动化。

2. Node（干活机器）：干活的机器，专门跑业务 Pod

真正跑业务 Pod，运行两个核心代理程序：

1. kubelet：管本机所有 Pod，创建、重启、监控、删除；
2. kube-proxy：实现 Service 的负载均衡，转发请求。

传统系统扩容、升级有多麻烦？

以前没有 K8s 的时候： 想多开几个服务实例、升级新版本，全部靠人工操作：

1. 手动选机器、手动部署程序、手动启动；
2. 程序崩了没人管，不会自动重启；
3. 步骤多、耗时间，还容易操作失误出事故。

RC=ReplicationController，副本控制器，是专门管一批一模一样 Pod 的工具；RC 就是专门看管一批相同 Pod 的自动管家。 Pod 是跑你项目的容器，Pod 会崩、会消失，人工盯着很累，RC 24 小时自动值守，彻底解放人工，自动完成扩容、故障自愈、版本升级。 只要给对应业务创建 RC，扩容、升级难题全部自动解决。

写 RC 配置文件，必须写三样核心内容，少一个都不行：

1. Pod 模板：规定你的程序镜像、环境、资源，告诉 K8s 怎么创建 Pod；
2. replicas 副本数：你希望同时稳定运行多少个 Pod 实例（比如 3 个）；RC 会实时清点数量：现在只有 2 个 → 自动新建 1 个。现在有 4 个 → 自动删掉多余 1 个
3. 标签选择器：靠 Label 标签，让 RC 识别哪些 Pod 归自己管理。

• 你有一个网站程序，打包成容器，运行在 Pod 里；
• 创建 Service，给网站一个固定访问地址；
• 新建 RC 配置：
  • 模板：网站镜像；
  • 副本数：3；
  • 标签匹配app=web；
• RC 自动创建 3 个网站 Pod，实时盯着数量；
  • 崩掉 1 个 → RC 自动新建 1 个补到 3 个；
  • 流量暴涨，改副本数为 5 → RC 自动多开 2 个；
  • 要升级新版本，修改镜像 → RC 自动替换旧 Pod。

RC 和 Pod、Service 的关系

1. Pod：真正跑业务；
2. RC：管控 Pod 数量、自动重建 / 扩容；
3. Service：给 Pod 提供固定访问地址，屏蔽 Pod 多变 IP； 一套业务标准组合：RC（管控）+ Pod（运行）+ Service（访问入口）

使用 K8s 两大核心好处

好处 1：大幅缩减人力，小团队就能搞定复杂分布式系统

传统分布式系统：需要大量资深开发、运维分工做负载均衡、部署、故障处理、扩容； 用上 K8s 后： 只需要少量人：1 名架构师 + 几名开发 + 1 名运维，底层调度、自愈、扩缩容全部由 K8s 自动实现，不用人工重复造轮子，降低人力成本。

好处 2：完美适配微服务架构

1. 微服务思想：把一个庞大单体项目拆成很多独立小服务；
2. 微服务痛点：实例扩容、独立升级、多实例高可用很难手动维护；
3. K8s 原生配套能力：
   • 支持每个服务独立扩缩容，流量高自动多开实例；
   • 各个服务独立开发、独立升级、互不影响；
   • 不限开发语言，Java/Go/Python 等全部能统一托管；
4. 大厂（谷歌、亚马逊、Netflix）都在用微服务，K8s 直接内置这套底层基础设施，开箱即用。