K8s学习笔记(七) yaml

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

一、K8s YAML 文件的核心作用

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

定义资源属性：明确资源类型（如 Pod/Deployment）、名称、标签、容器配置、网络规则等。
版本化管理：YAML 文件可纳入 Git 等版本控制系统，便于追溯资源配置的变更历史。
批量部署与复用 ：相同配置的资源可通过 YAML 快速复用，配合kubectl命令实现批量部署。
基础设施即代码（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）

关键子字段详解

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

yaml 复制代码

# Pod的YAML示例：运行一个Nginx容器
apiVersion: v1  # Pod属于v1版本API
kind: Pod       # 资源类型为Pod
metadata:
  name: nginx-pod  # Pod名称
  namespace: default  # 所属命名空间（默认可省略）
  labels:           # 标签（用于关联Service等资源）
    app: nginx
    env: 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: 80
      initialDelaySeconds: 5  # 容器启动后5秒开始探测
      periodSeconds: 10       # 每10秒探测一次

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

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

yaml 复制代码

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

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

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

yaml 复制代码

# 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: nginx
  ports:           # 端口映射（Service端口 → Pod容器端口）
  - port: 8080     # Service暴露的端口（集群内访问时使用）
    targetPort: 80 # 映射到Pod容器的端口（需与Pod的containerPort一致）

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

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

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

避免使用latest镜像标签 ：latest标签会自动拉取最新镜像，可能导致版本不可控，应指定具体版本（如nginx:1.24）。
使用ConfigMap/Secret存储配置 ：不要将配置文件（如 Nginx 的nginx.conf）或敏感信息（如密码）硬编码到 YAML 中，应通过ConfigMap（普通配置）或Secret（敏感信息）挂载。
添加资源限制（resources） ：通过requests和limits限制容器的 CPU / 内存使用，避免单个容器耗尽节点资源。
配置健康探针（Probe） ：通过livenessProbe（存活探针）和readinessProbe（就绪探针）检测容器状态，实现自愈（存活探针失败会重启容器，就绪探针失败会移除 Service 流量）。
版本控制 YAML 文件：将所有 YAML 文件纳入 Git 管理，记录变更历史，便于回滚和协作。
使用标签（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 官方文档获取各资源的完整配置说明。