K8s 新手必看：10 分钟搞懂核心概念，告别一头雾水

如果你刚踏入云原生领域，大概率会被 Kubernetes（简称 K8s）的各种术语绕晕 ——“Pod 是什么？”“Service 和 Ingress 有啥区别？”“控制平面到底管啥？”。其实不用慌，K8s 的核心逻辑很清晰，今天就用 “人话 + 场景” 的方式，帮你梳理最关键的概念，帮你搭建起 K8s 的知识框架。

一、先搞懂 K8s 的 “骨架”：架构基础

想学好 K8s，先得知道它的 “身体结构”。K8s 集群就像一个 “工厂”，分为两部分：负责指挥的 “大脑”，和负责干活的 “工人”。

1. 控制平面（Control Plane）：集群的 “大脑”

控制平面是 K8s 的指挥中心，决定 “哪个任务交给哪个工人干”“出问题了怎么补救”。它由几个核心组件组成：

• API Server：所有操作的 “入口”。不管你用kubectl命令行、可视化界面，还是其他工具操作集群，都必须通过它传递指令（比如 “创建一个应用”“扩缩容”）。

• etcd：集群的 “账本”。一个高可用的数据库，记录着集群所有的配置信息（比如 “哪个 Pod 在哪个节点”“存储资源有多少”），是集群的 “唯一真相源”。

• Scheduler：“调度员”。当你要新建一个应用（Pod），它会根据规则（比如 “这个应用需要 2G 内存”“不能和某个应用在同一台机器”），找一个最合适的 “工人”（节点）来运行它。

• Controller Manager：“督查员”。负责盯着集群状态，确保实际状态和你期望的一致。比如你说 “要跑 3 个应用副本”，如果其中一个挂了，它会立刻新建一个补上。

• Cloud Controller Manager（可选）：如果你的 K8s 跑在阿里云、AWS 等云平台上，它就是 “云平台联络员”，负责对接云服务商的资源（比如创建云负载均衡、云存储）。

2. 节点（Node）：集群的 “工人”

节点是实际运行应用的服务器（物理机或虚拟机），相当于工厂里的 “工人”。每个节点上都有三个必装组件：

• Kubelet：“监工”。每个节点上都有一个，负责和 API Server 通信，确保节点上的应用（Pod）按照要求运行（比如 “容器有没有启动”“资源够不够用”）。

• Kube-proxy：“网络管家”。负责节点的网络规则，比如 “外部请求怎么找到这个节点上的应用”“多个应用之间怎么通信”，是实现 “负载均衡” 的关键。

• 容器运行时：“工具箱”。比如 Docker、containerd，负责实际启动和运行容器 —— 没有它，应用就没法跑起来。

二、K8s 的 “最小工作单元”：核心资源

知道了 “骨架”，接下来看 K8s 里 “具体干活的单元”。你日常部署、管理应用，都绕不开这些核心资源。

1. Pod：最小部署单元，像 “一个快递盒”

Pod 是 K8s 里最小的部署单位，可以理解为 “一个装着容器的快递盒”—— 里面可能装 1 个容器（最常见），也可能装多个 “关系特别近” 的容器（比如一个跑应用，一个跑日志收集）。

⚠️ 注意：Pod 是 “一次性” 的！如果 Pod 所在节点故障，或者容器崩溃，Pod 不会自己恢复。所以我们很少直接创建 Pod，而是用 “控制器” 来管理它。

2. 控制器（Controllers）：Pod 的 “管理员”

控制器的作用是 “管理 Pod 的生命周期”，确保 Pod 始终符合你的期望。常用的有 5 种，对应不同场景：

• Deployment：最常用的 “管理员”，适合无状态应用（比如 Web 服务、API）。支持 “滚动更新”（更新应用时不中断服务）和 “回滚”（更新出问题了能退回到上一版本）。比如你部署一个 Nginx，用 Deployment 设置 “3 个副本”，就算其中 1 个 Pod 挂了，它会立刻补一个新的。

• StatefulSet：给 “有状态应用” 用的（比如 MySQL 集群、Redis 集群）。这类应用需要固定的名字、存储和网络标识 —— 比如 MySQL 主从节点，不能随便换名字，否则从节点找不到主节点了。StatefulSet 就负责保证这些 “稳定性”。

• DaemonSet：让 “所有节点都跑同一个 Pod”。比如日志收集工具（Fluentd）、监控代理（Prometheus Node Exporter），需要每个节点都有一个，就用 DaemonSet。

• Job：跑 “一次性任务”。比如数据备份、脚本执行，任务完成后 Pod 就自动退出。

• CronJob：跑 “周期性任务”，相当于 Linux 的cron。比如每天凌晨 3 点执行数据备份，就用 CronJob。

三、应用怎么访问？服务发现与负载均衡

Pod 是动态变化的 —— 可能会扩缩容、故障重建，IP 地址也会变。那其他应用或外部用户怎么稳定访问它？这就需要 “服务发现” 和 “负载均衡”。

1. Service：Pod 的 “固定门牌号”

Service 相当于给一组相同功能的 Pod（比如 3 个 Nginx Pod）分配一个固定的 IP 地址（ClusterIP），不管 Pod 怎么变，这个 “门牌号” 始终不变。

它的工作逻辑很简单：

1. 用 “标签选择器”（Label Selector）找到背后的 Pod（比如给所有 Nginx Pod 打 “app=nginx” 的标签，Service 就选带这个标签的 Pod）；

1. 外部请求访问 Service 的固定 IP，Kube-proxy 会把请求 “负载均衡” 到背后的 Pod 上（比如 3 个 Pod 轮流接请求，避免单个 Pod 压力太大）。

Service 有 4 种常用类型，对应不同访问场景：

• ClusterIP：默认类型，只能在集群内部访问（比如集群里的 A 应用访问 B 应用）。

• NodePort：在每个节点上开一个固定端口，外部可以通过 “节点 IP: 端口” 访问（比如你本地测试时，用192.168.1.100:30080访问 Nginx）。

• LoadBalancer：对接云平台的负载均衡器，自动分配公网 IP（生产环境常用，比如用户通过www.xxx.com访问你的应用）。

• ExternalName：把 Service 映射到外部域名（比如把service-nginx映射到www.baidu.com，访问这个 Service 就相当于访问百度）。

2. Ingress：集群的 “智能路由器”

如果用 Service 暴露多个应用，每个应用都要一个公网 IP，太浪费了。Ingress 就像 “一个总入口”，用一个公网 IP 和域名，把不同路径的请求转发到不同 Service。

比如：

• 访问www.xxx.com/nginx，转发到 Nginx 的 Service；

• 访问www.xxx.com/mysql，转发到 MySQL 的 Service。

⚠️ 注意：Ingress 需要 “Ingress Controller” 才能工作（比如 NGINX Ingress Controller）—— 它相当于 “路由器的硬件”，Ingress 则是 “路由器的配置规则”。

四、数据怎么存？K8s 的存储方案

容器是 “无状态” 的 —— 容器删除后，里面的数据就没了。那数据库、文件服务这类需要持久化数据的应用，怎么存数据？

1. Volume：Pod 的 “临时存储柜”

Volume 是给 Pod 挂载的一块存储区域，可以是临时的（Pod 删除后数据消失），也可以是持久的（数据存在外部存储里）。比如给 Pod 挂载一个 Volume，容器里的日志就可以写到 Volume 里，避免容器删了日志丢了。

2. PersistentVolume（PV）：集群的 “共享硬盘”

PV 是管理员提前创建的 “集群级存储资源”，相当于公司里的 “共享硬盘”，独立于 Pod 的生命周期 ——Pod 删了，PV 里的数据还在。比如管理员创建一个 100G 的 PV，用的是阿里云的云盘。

3. PersistentVolumeClaim（PVC）：用户的 “存储申请单”

普通用户（开发者）不用关心 PV 是怎么创建的，只需要提交 “申请单”（PVC），说明 “我需要 10G 存储，能读能写”。K8s 会自动找一个符合条件的 PV，和这个 PVC 绑定 —— 就像你向行政申请 “1 个 U 盘”，行政给你找一个符合要求的 U 盘。

4. StorageClass：存储的 “自动售货机”

如果没有现成的 PV，StorageClass 可以 “自动创建 PV”。比如用户提交一个 PVC，要求 “用阿里云云盘，10G”，StorageClass 会自动调用阿里云 API 创建云盘，再生成 PV 并绑定 PVC—— 不用管理员手动创建 PV，效率更高。

五、配置和敏感信息怎么管？配置与安全

应用运行时需要配置（比如数据库地址、端口）和敏感信息（比如密码、API 密钥），直接写在代码或容器里太不安全，也不方便修改。K8s 提供了专门的方案。

1. ConfigMap：非敏感配置的 “管理箱”

用来存非敏感的配置信息，比如环境变量、配置文件。比如把 Nginx 的nginx.conf存到 ConfigMap 里，修改配置时不用重新打包镜像，直接改 ConfigMap 就行。

2. Secret：敏感信息的 “保险箱”

用来存密码、API 密钥、证书等敏感信息。它和 ConfigMap 用法类似，但数据会用 Base64 编码（⚠️ 注意：Base64 是编码不是加密，生产环境建议配合加密插件使用，比如 Vault）。

3. Namespace：资源的 “隔离墙”

把集群分成多个 “虚拟子集群”，比如 “开发环境（dev）”“测试环境（test）”“生产环境（prod）”。不同 Namespace 的资源相互隔离 —— 比如 dev 的 Pod 看不到 prod 的 Pod，避免开发环境影响生产环境。

4. Label & Selector：资源的 “标签和筛选器”

• Label：给资源打 “标签”，比如给 Pod 打 “app=nginx”“env=dev”“version=v1” 的标签，标签是键值对，想怎么打就怎么打。

• Selector：根据标签 “筛选资源”，是 K8s 里 “关联资源” 的核心 —— 比如 Service 用 Selector 选带 “app=nginx” 的 Pod，Deployment 用 Selector 管理带 “app=nginx” 的 Pod。

总结：K8s 核心概念关系图

最后用一张 “关系图” 帮你串联所有概念：

1. 架构层：控制平面（API Server、etcd 等）指挥节点（Kubelet、Kube-proxy 等）干活；

1. 资源层：Deployment 等控制器管理 Pod，Pod 里跑容器；

1. 访问层：Service 给 Pod 分配固定 IP，Ingress 统一管理外部访问；

1. 存储层：PVC 申请 PV，PV 提供持久化存储；

1. 配置层：ConfigMap 存普通配置，Secret 存敏感信息，Namespace 隔离资源。

其实 K8s 不难，关键是先理解 “每个概念解决什么问题”，再结合实际操作（比如用kubectl创建一个 Deployment、Service），很快就能上手。如果还有哪个概念没搞懂，欢迎在评论区留言～