在 K8s（Kubernetes）日常运维和项目部署中，理解资源分类、精通 YAML 配置语法、掌握核心字段含义是入门的关键。本文结合实际部署 Go TodoList 项目的实战经验，详细拆解 K8s 资源分类、YAML 核心语法及常用字段，帮你彻底搞懂 K8s 配置的底层逻辑。
一、K8s 集群资源分类
K8s 的资源是对集群中各类功能实体的抽象，按作用范围 和功能属性可分为以下核心类别，不同类别资源的管理方式、生效范围差异显著。
1. 名称空间级别资源（Namespace-scoped）
这类资源属于 "局部资源"，仅在指定的 Namespace（名称空间）内生效，不同 Namespace 下的同名资源相互隔离，是日常部署应用最常接触的类型。
| 资源类型 | 核心作用 | 典型示例 |
|---|---|---|
| 工作负载型资源 | 定义应用的运行方式，是 Pod 的上层管理抽象 | Deployment、Pod、StatefulSet、DaemonSet、Job/CronJob |
| 服务发现 & 负载均衡型资源 | 为 Pod 提供稳定的访问入口，实现服务发现和流量分发 | Service、Ingress |
| 配置与存储型资源 | 管理应用的配置信息和存储需求，解耦配置与代码 | ConfigMap、Secret、PersistentVolumeClaim（PVC） |
| 特殊类型存储卷 | 为 Pod 提供临时 / 共享存储，生命周期与 Pod 绑定 | EmptyDir、HostPath、ConfigMapVolume（基于 ConfigMap 的存储卷） |
实战场景：部署 TodoList 项目时，我们创建的 Deployment（工作负载型）、Service（服务发现型）都属于名称空间级别资源，默认在
default命名空间下生效。
2. 集群级别资源（Cluster-scoped）
这类资源属于 "全局资源"，不隶属于任何 Namespace，作用范围覆盖整个 K8s 集群，通常用于集群级别的配置和管理。
| 典型资源 | 核心作用 |
|---|---|
| Node | 集群中的节点（物理机 / 虚拟机），是 Pod 的运行载体 |
| PersistentVolume（PV） | 集群级别的存储资源，与 PVC 配合为应用提供持久化存储（PVC 是命名空间级别） |
| ClusterRole/ClusterRoleBinding | 集群级别的权限控制，用于授予跨 Namespace 的权限 |
| Namespace | 命名空间本身是集群级别资源，用于隔离名称空间级别资源 |
实战场景：部署 TodoList 时，我们通过
kubectl get nodes查看的 Node 资源、创建的 PV（若需持久化存储）都属于集群级别资源。
3. 元数据型资源
这类资源主要用于存储集群的元数据、状态信息或扩展 K8s 功能，是 K8s 内部运行的 "辅助型资源"，日常开发部署中较少直接操作，但对集群稳定运行至关重要。
| 典型资源 | 核心作用 |
|---|---|
| Event | 记录集群内的事件（如 Pod 启动失败、Service 创建成功），用于故障排查 |
| Endpoints | 对应 Service 的后端 Pod 地址列表，Service 通过 Endpoints 实现流量转发 |
| CustomResourceDefinition（CRD） | 自定义资源定义，扩展 K8s 的资源类型（如 ETCD、Ingress-NGINX 的自定义资源） |
实战场景：排查 TodoList Pod 重启问题时，可通过
kubectl get events查看 Event 资源，快速定位健康检查失败、端口不匹配等问题。
二、K8s 核心配置：YAML 语法全解析
K8s 的所有资源都通过 YAML（或 JSON）文件定义，YAML 以 "简洁、易读" 成为主流，掌握其语法是编写 K8s 配置的基础。
1. YAML 基本语法
YAML 是一种层级化的配置语言，核心语法规则需严格遵守：
- 缩进 ：用空格（禁止 Tab）表示层级，通常 2 个空格为一级，缩进错误会直接导致配置解析失败（如部署 TodoList 时曾因缩进问题报错）；
- 注释 ：以
#开头，注释内容不会被解析，可用于标注配置含义； - 键值对分隔 ：键和值之间用
:分隔，冒号后必须加空格 （如name: todo-list，而非name:todo-list）； - 字符串 ：默认无需引号，若包含特殊字符（如空格、冒号）需用单 / 双引号包裹（如
name: "todo-list:v1.0"）。
2. YAML 核心数据结构
K8s 配置中主要用到 3 种数据结构，几乎所有配置都基于这 3 种结构组合：
（1）对象（映射 / 字典）
键值对的集合，对应 JSON 中的object，是 K8s 配置的核心结构（如定义 Deployment 的元数据、规格）。
yaml
# 示例：Deployment的元数据对象
metadata:
name: todo-list-deploy # 键：name，值：todo-list-deploy
namespace: default # 键：namespace，值：default（2）数组（列表 / 序列）
一组有序的值，对应 JSON 中的array，用于定义多个同类型元素（如 Pod 的容器列表、Service 的端口列表）。
yaml
# 示例：Pod的容器数组（包含1个容器）
containers:
- name: todo-list # 数组元素1：容器名称
image: todo-list:v1.0 # 容器镜像
ports:
- containerPort: 8000 # 嵌套数组：容器端口注意：数组元素以
-开头，-后需加空格，多个元素按顺序排列。
（3）纯量（基本数据类型）
单个的、不可再分的值，是键值对中的 "值"，常见类型：
| 纯量类型 | 示例 | 说明 |
|---|---|---|
| 字符串 | name: todo-list |
默认无需引号 |
| 数字 | replicas: 2 |
整数；浮点数如cpu: 0.5 |
| 布尔值 | enabled: true |
true/false（小写） |
| 空值 | empty: null |
表示无值 |
3. 数据结构的组合使用（实战示例）
K8s 配置文件本质是 "对象 + 数组 + 纯量" 的嵌套组合，以下是 TodoList 项目的 Deployment 配置示例，清晰体现三种结构的配合：
yaml
apiVersion: apps/v1 # 纯量：API版本
kind: Deployment # 纯量：资源类型
metadata: # 对象：元数据
name: todo-list-deploy # 纯量：资源名称
spec: # 对象：规格定义
replicas: 2 # 纯量：副本数
selector: # 对象：标签选择器
matchLabels: # 对象：匹配标签
app: todo-list # 纯量：标签键值对
template: # 对象：Pod模板
metadata: # 对象：Pod元数据
labels: # 对象：Pod标签
app: todo-list # 纯量：标签值
spec: # 对象：Pod规格
containers: # 数组：容器列表
- name: todo-list # 纯量：容器名称
image: todo-list:v1.0 # 纯量：镜像地址
ports: # 数组：端口列表
- containerPort: 8000 # 纯量：容器端口三、K8s 配置常用字段解析
K8s 配置文件中有一批 "高频通用字段"，无论部署 Deployment、Service 还是 Pod，都会反复用到，掌握这些字段的含义是读懂配置的关键。
1. 顶层通用字段（所有资源必选 / 高频）
| 字段名 | 含义 | 示例值 |
|---|---|---|
| apiVersion | 资源对应的 API 版本，不同资源版本不同（如 Deployment 用 apps/v1，Service 用 v1） | apps/v1、v1 |
| kind | 资源类型，指定当前配置定义的是哪种 K8s 资源 | Deployment、Service、Pod |
| metadata | 资源的元数据，包含名称、命名空间、标签等核心信息 | 见下方元数据子字段 |
| spec | 资源的规格定义，不同资源的 spec 内容差异极大（核心配置区） | 见下方资源专属字段 |
2. metadata（元数据）子字段
| 子字段 | 含义 | 实战说明 |
|---|---|---|
| name | 资源名称，同一 Namespace 下资源名称唯一 | 如 todo-list-deploy、todo-list-svc |
| namespace | 资源所属的命名空间，默认值为 default | 可通过kubectl create ns todo-ns创建专属命名空间 |
| labels | 资源的标签（键值对），用于资源筛选、关联（如 Service 关联 Pod） | app: todo-list（核心标签，用于匹配） |
| annotations | 资源的注解（键值对），用于存储非标识性信息（如备注、版本） | version: v1.0、description: "TodoList服务" |
3. Deployment（工作负载）spec 核心字段
Deployment 是部署无状态应用的核心资源，其 spec 字段是配置重点：
| 子字段 | 含义 | 实战说明 |
|---|---|---|
| replicas | 期望的 Pod 副本数，K8s 会自动维持该数量的 Pod 运行 | 设为 2 实现高可用，Pod 故障时自动重建 |
| selector.matchLabels | 标签选择器，匹配需要管理的 Pod（需与 Pod 模板的 labels 一致） | 若不一致，Deployment 无法管理 Pod |
| template | Pod 模板，定义要创建的 Pod 的规格（核心嵌套字段） | 所有 Pod 都基于该模板创建 |
| template.spec.containers | Pod 内的容器列表（数组），定义容器的镜像、端口、资源限制等 | 需指定镜像名称、容器端口（如 TodoList 的 8000 端口） |
| template.spec.containers.ports.containerPort | 容器监听的端口 | 必须与应用实际监听端口一致（曾因配成 8080 导致 Pod 重启） |
| template.spec.containers.resources | 容器的资源限制 / 请求 | limits.cpu: 0.5（最大 0.5 核），避免占用过多节点资源 |
| template.spec.containers.livenessProbe | 存活探针，检测容器是否存活 | 失败则重启 Pod，需与应用实际接口匹配（可临时注释） |
4. Service（服务发现）spec 核心字段
Service 为 Pod 提供稳定的访问入口，其 spec 字段核心配置：
| 子字段 | 含义 | 实战说明 |
|---|---|---|
| type | Service 类型，决定访问方式 | NodePort（集群外访问）、ClusterIP（集群内）、LoadBalancer（云厂商） |
| selector | 标签选择器，匹配要关联的 Pod（需与 Pod 的 labels 一致） | 若不一致，Service 无法转发流量到 Pod |
| ports.port | Service 的内部端口（集群内访问的端口） | 可自定义，如 8000 |
| ports.targetPort | 容器的端口（需与 Pod 的 containerPort 一致） | 核心字段，曾因配错导致访问失败 |
| ports.nodePort | 节点端口（仅 type=NodePort 时生效），范围 30000-32767 | 如 30001，对外访问地址：节点 IP:nodePort |
四、实战总结：配置避坑关键点
- 资源分类层面：区分名称空间 / 集群级别资源，避免在集群级别资源中指定 namespace（如 Node、PV 无需指定）；
- YAML 语法层面 ：严格遵守缩进（空格）、冒号后加空格，数组元素以
-开头，避免低级语法错误； - 字段配置层面 ：
- 标签匹配是核心：Deployment 的 selector、Service 的 selector 必须与 Pod 的 labels 一致；
- 端口匹配是关键：容器端口、Service 的 targetPort、应用实际监听端口三者必须统一；
- 健康检查需适配：存活探针的路径 / 端口需与应用实际接口匹配，否则会导致 Pod 无故重启。
通过理解 K8s 资源分类、精通 YAML 语法、掌握核心字段含义，能大幅降低部署应用时的 "踩坑概率"。本文结合 TodoList 项目实战，拆解了 K8s 配置的核心知识点，希望能帮助你从 "会用" K8s 到 "懂" K8s 配置的底层逻辑。