K8s的概念比较多，很多初学者容易混淆，本节将拆解K8s最核心的概念，用通俗的语言解释每个概念的作用，以及它们之间的关系，帮你快速掌握K8s的核心术语。

1. 集群（Cluster）

集群是K8s的核心部署单元，是由一组服务器（节点）组成的集合，K8s通过集群来管理这些节点和节点上的容器。一个K8s集群至少包含一个控制平面节点（Master Node）和多个工作节点（Worker Node），所有的容器都部署在工作节点上，控制平面节点负责管理整个集群的运行。

简单来说，集群就相当于一个“大机房”，里面有很多服务器（节点），K8s就是这个机房的“管理员”，负责分配任务、监控状态、处理故障。

2. 节点（Node）

节点是集群中的单个服务器，分为控制平面节点（Master Node）和工作节点（Worker Node），每个节点都运行着K8s的相关组件，承担着不同的角色。

- 控制平面节点（Master Node）：集群的“大脑”，负责管理整个集群的决策和控制，比如接收用户的部署请求、调度容器、监控集群状态、处理故障等。一个集群可以有多个控制平面节点（用于高可用），但通常至少有一个。

- 工作节点（Worker Node）：集群的“手脚”，负责运行容器，执行具体的应用任务。工作节点会接收控制平面节点的指令，部署和运行容器，并向控制平面节点汇报自身的状态（如CPU使用率、内存使用率、容器运行状态）。一个集群可以有多个工作节点，节点数量越多，集群的承载能力越强。

3. Pod：K8s的最小部署单元

Pod是K8s中最小的部署单元，也是K8s管理的最小对象，它是一个或多个容器的集合，这些容器共享网络命名空间、存储资源和运行环境。简单来说，Pod就相当于一个“容器组”，里面可以包含一个或多个关系密切的容器，这些容器一起部署、一起启动、一起停止。

举个例子：一个web应用，可能需要一个web容器（如Nginx）和一个应用容器（如Java应用），这两个容器关系密切，需要共享网络（web容器接收请求，转发给应用容器），此时就可以将它们部署在同一个Pod中，K8s会将这个Pod作为一个整体进行管理。

需要注意的是：K8s不直接管理容器，而是通过管理Pod来管理容器；Pod是临时的，当Pod故障或被删除后，K8s会重新创建一个新的Pod，而不是修复原来的Pod；每个Pod都有一个唯一的IP地址，Pod之间可以通过IP地址相互通信。

4. 控制器（Controller）：Pod的“管理者”

Pod是临时的，一旦故障就会被删除，而控制器的作用就是确保Pod的数量和状态符合用户的预期，相当于Pod的“管理者”。K8s提供了多种控制器，每种控制器都有不同的作用，最常用的控制器有以下几种：

- Deployment：最常用的控制器，用于部署无状态应用（如web服务、API服务），可以定义Pod的副本数量、镜像版本、更新策略等，支持滚动更新、回滚等功能，确保Pod的数量始终符合预期，故障时自动重启Pod。

- StatefulSet：用于部署有状态应用（如数据库、缓存服务），这类应用需要稳定的网络标识（如固定的主机名、IP地址）和持久化存储，StatefulSet可以保证Pod的有序部署、有序删除、有序更新，确保有状态应用的稳定性。

- DaemonSet：用于在集群中的每个节点上部署一个Pod，比如监控插件、日志收集插件等，确保每个节点都运行相同的Pod，用于集群级别的监控和运维。

- Job/CronJob：用于运行一次性任务（Job）或定时任务（CronJob），比如数据备份、定时计算等，任务完成后，Pod会自动终止，无需长期运行。

5. 服务（Service）：Pod的“访问入口”

Pod是临时的，IP地址会随着Pod的重建而变化，这就导致一个问题：如果Pod的IP地址变化了，其他Pod或外部客户端如何访问这个Pod？Service就是为了解决这个问题而生的，它是Pod的“访问入口”，为一组Pod提供一个固定的访问地址（ClusterIP），无论Pod的IP地址如何变化，客户端都可以通过Service的固定地址访问到Pod。

Service通过标签选择器（Label Selector）关联Pod，只要Pod的标签与Service的标签选择器匹配，就会被纳入到Service的管理范围，Service会自动负载均衡到这些Pod上。例如，一个Deployment创建了3个Pod，每个Pod都有标签“app=web”，那么创建一个Service，标签选择器设置为“app=web”，Service就会为这3个Pod提供一个固定的ClusterIP，客户端访问这个ClusterIP时，Service会将请求分发到其中一个Pod上，实现负载均衡。

K8s的Service有多种类型，满足不同的访问需求：

- ClusterIP：默认类型，只能在集群内部访问，外部客户端无法访问，适用于集群内部的服务通信（如web服务访问数据库服务）；

- NodePort：在每个节点上开放一个固定端口，外部客户端可以通过“节点IP:NodePort”的方式访问Service，适用于测试环境或小型应用；

- LoadBalancer：结合云服务提供商的负载均衡器（如阿里云SLB、AWS ELB），为Service分配一个公网IP，外部客户端可以通过公网IP访问Service，适用于生产环境；

- ExternalName：将Service映射到外部域名（如www.baidu.com），适用于访问集群外部的服务。

6. 存储相关概念：PV、PVC、StorageClass

容器是临时的，容器内的数据会随着容器的删除而丢失，对于需要持久化数据的应用（如数据库），就需要使用K8s的存储机制。K8s提供了PV、PVC、StorageClass三种资源，用于管理持久化存储，三者的关系如下：

- PersistentVolume（PV）：持久化存储的“资源池”，由管理员创建，是集群中的一种资源，相当于一块“磁盘”，可以是本地磁盘、云存储（如阿里云OSS、AWS S3）等，PV具有固定的容量、存储类型、访问模式等属性。

- PersistentVolumeClaim（PVC）：用户对存储的“请求”，由用户创建，用户通过PVC声明自己需要的存储容量、存储类型等，K8s会自动从PV资源池中匹配一个符合条件的PV，将其绑定到PVC上，用户的Pod就可以通过PVC挂载存储，实现数据持久化。

- StorageClass：存储的“模板”，用于动态创建PV，当用户创建PVC时，如果没有合适的PV可以匹配，StorageClass会根据模板自动创建一个PV，并绑定到PVC上，无需管理员手动创建PV，简化了存储管理流程。

举个例子：管理员创建一个StorageClass，定义存储类型为云存储，容量默认100G，访问模式为读写，当用户创建一个PVC，请求100G的存储时，StorageClass会自动创建一个100G的云存储PV，并绑定到该PVC上，用户的数据库Pod就可以挂载这个PVC，实现数据持久化。

7. 配置相关概念：ConfigMap、Secret

应用的配置信息（如数据库地址、端口、日志级别）和敏感信息（如密码、密钥、Token），不适合硬编码到应用代码中，否则修改配置时需要重新打包镜像、部署应用，效率极低，且敏感信息会暴露在代码中，存在安全风险。K8s提供了ConfigMap和Secret两种资源，用于管理应用的配置信息和敏感信息。

- ConfigMap：用于存储非敏感配置信息，比如数据库地址、端口、环境变量等，ConfigMap可以通过环境变量注入、文件挂载的方式，将配置信息传递给Pod中的容器，修改ConfigMap后，Pod中的配置会自动更新（无需重启Pod）。

- Secret：用于存储敏感信息，比如密码、密钥、Token等，Secret会对敏感信息进行Base64编码（注意：Base64编码不是加密，只是编码，敏感信息依然需要做好权限控制），同样可以通过环境变量注入、文件挂载的方式传递给容器，避免了敏感信息硬编码到代码中。