K8s学习笔记(七) yaml

在 Kubernetes（K8s）中，YAML 文件是定义资源（如 Pod、Deployment、Service 等）的标准格式，它通过结构化的文本描述 K8s 资源的期望状态（Desired State），K8s 控制器会根据 YAML 中的配置将资源状态调整为期望状态。

一、K8s YAML 文件的核心作用

K8s 采用 “声明式 API” 设计，YAML 文件正是 “声明” 的载体，主要作用包括：

1. 定义资源属性：明确资源类型（如 Pod/Deployment）、名称、标签、容器配置、网络规则等。
2. 版本化管理：YAML 文件可纳入 Git 等版本控制系统，便于追溯资源配置的变更历史。
3. 批量部署与复用：相同配置的资源可通过 YAML 快速复用，配合kubectl命令实现批量部署。
4. 基础设施即代码（IaC）：将 K8s 资源配置以代码形式管理，实现自动化部署（如配合 CI/CD 流水线）。

二、K8s YAML 文件的基本结构

所有 K8s YAML 文件都遵循统一的顶层结构，核心字段为4 个必填项（部分资源有额外必填字段），其余为可选配置。

顶层字段	作用说明	取值示例
apiVersion	指定 K8s API 的版本（不同资源类型对应不同版本）	v1（Pod/Service）、apps/v1（Deployment）
kind	指定资源类型（K8s 支持的资源均有固定kind）	Pod、Deployment、Service、ConfigMap
metadata	资源的元数据（用于标识资源）	包含name（名称）、labels（标签）、namespace（命名空间）等
spec	资源的 “期望状态” 配置（核心字段，不同资源的spec结构差异极大）	如 Pod 的spec.containers、Deployment 的spec.replicas
status	资源的 “当前状态”（由 K8s 集群自动生成，不可手动配置）	如 Pod 的status.phase（Running/Pending）

关键子字段详解

1. metadata 常用子字段

   • name：资源的唯一名称（同一命名空间内不可重复），长度≤63 字符，只能包含字母、数字、-、_、.。
   • namespace：资源所属的命名空间（默认default），用于资源隔离，如namespace: prod。
   • labels：键值对形式的标签（用于资源筛选和关联，如app: nginx、env: test）。
   • annotations：非标识性的元数据（用于存储额外信息，如运维备注、工具配置），如annotations: author: dev-team。

2. spec 字段的差异性

   • spec是 YAML 文件中最灵活的部分，

     不同资源的spec结构完全不同：

     • 对于Pod：spec核心是containers（容器列表），包含容器镜像、端口、资源限制等。
     • 对于Deployment：spec核心是replicas（副本数）和template（Pod 模板，嵌套 Pod 的spec）。
     • 对于Service：spec核心是selector（关联 Pod 的标签）和ports（端口映射）。

三、常见 K8s 资源的 YAML 示例

以下是 3 个最常用资源的 YAML 示例，覆盖基础部署场景。

1. 示例 1：Pod（最基础的资源，运行单个容器或多个关联容器）

# Pod的YAML示例：运行一个Nginx容器
apiVersion: v1  # Pod属于v1版本API
kind: Pod       # 资源类型为Pod
metadata:name: nginx-pod  # Pod名称namespace: default  # 所属命名空间（默认可省略）labels:           # 标签（用于关联Service等资源）app: nginxenv: test
spec:containers:       # 容器列表（Pod可包含多个容器）- name: nginx-container  # 容器名称（Pod内唯一）image: nginx:1.24      # 容器镜像（指定版本，避免使用latest）ports:                 # 容器暴露的端口（仅声明，不映射到宿主机）- containerPort: 80    # 容器内Nginx的默认端口resources:             # 资源限制（可选，避免容器占用过多资源）requests:            # 最小资源需求cpu: "100m"        # 100毫核（1核=1000毫核）memory: "128Mi"    # 128兆内存limits:              # 最大资源限制cpu: "200m"memory: "256Mi"livenessProbe:         # 存活探针（可选，检测容器是否存活）httpGet:path: /port: 80initialDelaySeconds: 5  # 容器启动后5秒开始探测periodSeconds: 10       # 每10秒探测一次

2. 示例 2：Deployment（管理 Pod 的副本，实现自愈、扩缩容）

Deployment 是生产环境中最常用的资源，它通过Pod模板管理多个 Pod 副本，避免直接操作 Pod（Pod 删除后不会自动重建，Deployment 会自动补全副本）。

# Deployment的YAML示例：管理3个Nginx Pod副本
apiVersion: apps/v1  # Deployment属于apps/v1版本API
kind: Deployment
metadata:name: nginx-deploylabels:app: nginx-deploy
spec:replicas: 3  # 期望的Pod副本数（可通过kubectl scale调整）selector:    # 标签选择器（关联要管理的Pod，需与template.labels一致）matchLabels:app: nginx  # 匹配标签为app: nginx的Podtemplate:    # Pod模板（嵌套Pod的配置，结构与Pod的YAML一致）metadata:labels:app: nginx  # 必须与selector.matchLabels一致spec:containers:- name: nginx-containerimage: nginx:1.24ports:- containerPort: 80resources:requests:cpu: "100m"memory: "128Mi"limits:cpu: "200m"memory: "256Mi"

3. 示例 3：Service（暴露 Pod 的网络访问，实现负载均衡）

Pod 的 IP 是临时的（Pod 重建后 IP 会变），Service 通过标签关联 Pod，提供一个固定的访问地址，并实现 Pod 间的负载均衡。

# Service的YAML示例：暴露Nginx Deployment的Pod（ClusterIP类型，仅集群内访问）
apiVersion: v1
kind: Service
metadata:name: nginx-service
spec:type: ClusterIP  # Service类型（ClusterIP/NodePort/LoadBalancer/ExternalName）selector:        # 标签选择器（关联要暴露的Pod，与Deployment的template.labels一致）app: nginxports:           # 端口映射（Service端口 → Pod容器端口）- port: 8080     # Service暴露的端口（集群内访问时使用）targetPort: 80 # 映射到Pod容器的端口（需与Pod的containerPort一致）

四、K8s YAML 的语法规则（必知！避免配置错误）

YAML 语法对格式要求严格，以下是新手最易踩坑的规则：

1. 缩进规则：
   • 必须使用空格缩进（不能用 Tab 键），缩进深度不固定，但同一层级必须对齐。
   • 推荐使用 2 个或 4 个空格缩进（行业常用 2 个）。
2. 键值对格式：
   • 键和值之间用冒号 + 空格分隔（如name: nginx-pod，冒号后必须有空格）。
   • 字符串值默认无需引号（如image: nginx:1.24），但值包含空格或特殊字符时需用单 / 双引号（如annotations: note: "this is a test"）。
3. 列表（数组）表示：
   • 用- （横杠 + 空格）表示列表项，同一列表的项需对齐。
   • 示例：containers是列表，每个容器配置前加- 。
4. 注释写法：
   • 用#开头表示注释，注释内容会被 K8s 忽略（如# 这是一个Nginx Pod）。
5. 空值与布尔值：
   • 空值可写null或不写值（如key: null）。
   • 布尔值用true/false（小写，如restartPolicy: Always）。

五、YAML 文件的使用命令（kubectl 操作）

编写完 YAML 文件后，需通过kubectl命令提交到 K8s 集群，常用命令如下：

命令	作用说明
kubectl apply -f xxx.yaml	创建 / 更新资源（推荐！若资源已存在，会根据 YAML 更新配置）
kubectl create -f xxx.yaml	仅创建资源（若资源已存在，会报错，不支持更新）
kubectl delete -f xxx.yaml	删除 YAML 中定义的资源
kubectl get -f xxx.yaml	查看 YAML 中定义的资源状态
kubectl describe -f xxx.yaml	查看资源的详细信息（如事件、容器日志、关联资源等，排障常用）
kubectl edit -f xxx.yaml	在线编辑资源的 YAML 配置（修改后会自动提交，不推荐生产环境，建议修改本地文件后 apply）

六、YAML 配置的最佳实践

1. 避免使用latest镜像标签：latest标签会自动拉取最新镜像，可能导致版本不可控，应指定具体版本（如nginx:1.24）。
2. 使用ConfigMap/Secret存储配置：不要将配置文件（如 Nginx 的nginx.conf）或敏感信息（如密码）硬编码到 YAML 中，应通过ConfigMap（普通配置）或Secret（敏感信息）挂载。
3. 添加资源限制（resources）：通过requests和limits限制容器的 CPU / 内存使用，避免单个容器耗尽节点资源。
4. 配置健康探针（Probe）：通过livenessProbe（存活探针）和readinessProbe（就绪探针）检测容器状态，实现自愈（存活探针失败会重启容器，就绪探针失败会移除 Service 流量）。
5. 版本控制 YAML 文件：将所有 YAML 文件纳入 Git 管理，记录变更历史，便于回滚和协作。
6. 使用标签（Labels）和选择器（Selector）：通过标签关联资源（如 Deployment→Pod→Service），提高配置的灵活性和可维护性。

七、常用资源的 apiVersion 参考

不同资源的apiVersion不同，若版本错误会导致配置提交失败，以下是常用资源的正确版本：

资源类型	apiVersion
Pod/Service/ConfigMap/Secret	v1
Deployment/StatefulSet/DaemonSet	apps/v1
Ingress	networking.k8s.io/v1
CronJob	batch/v1

通过以上内容，可掌握 K8s YAML 文件的核心结构、语法和使用方法。实际配置时，可根据具体资源的需求（如 StatefulSet 需配置volumeClaimTemplates，Ingress 需配置rules）扩展 YAML 字段，建议参考K8s 官方文档获取各资源的完整配置说明。