20250712-3-Kubernetes 应用程序生命周期管理-服务编排（YAML）及编写技巧_笔记

一、K8s文件格式说明



• 

1. YAML基本语法

• 层级关系: 使用缩进表示层级关系，不支持制表符(

  tab\text{tab}tab

  )缩进，必须使用空格
• 缩进规则:
  • 通常开头缩进2个空格
  • 字符后缩进1个空格（如冒号、逗号等特殊字符后）
• 文件标识: "---"表示YAML格式文件的开始
• 注释方式: 使用"#"符号添加注释

2. YAML应用场景

• 主流配置格式: YAML是一种非常简洁的非标记性语言，已成为主流配置文件格式
• 典型应用案例:
  • Ansible Playbook配置文件
  • 微服务应用程序配置文件（如Spring Cloud）
  • Elasticsearch配置文件
• 通用性: 所有YAML文件（无论K8s、Ansible还是Spring Cloud）都遵循相同的语法规范

3. 使用注意事项

• 格式统一性: 不同系统的YAML文件格式要求完全一致，不区分具体应用场景
• 错误预防: 严格遵守缩进规则可避免大多数配置错误
• 跨平台兼容: 空格缩进确保在不同环境中的解析一致性

二、YAML文件创建资源对象

1. 部署应用

1）YAML文件创建资源对象



• 
• YAML结构：分为控制器定义（template以上部分）和被控制对象定义（template以下部分）
• 等效命令：等同于kubectl create deployment web --image=lisi/java-demo --replicas=3 -n default
• 字段对照：
  • apiVersion: API版本
  • kind: 资源类型（如Deployment）
  • metadata: 资源元数据（名称、命名空间等）
  • spec: 资源规格配置
  • replicas: 副本（实例）数量
  • selector: 标签选择器，需与Pod模板的labels匹配
  • template: Pod模板定义
  • containers: 容器配置（镜像、名称等）

2）控制器定义与被控制对象



• 控制器作用：管理被控制对象（如Pod）的生命周期
• 层级关系：
  • 控制器（如Deployment）→ Pod → 容器
  • Pod是抽象资源单位，实际运行的是容器
• 核心字段：所有控制器必须包含apiVersion、kind、metadata三个字段

3）API版本的重要性



• 
• 版本类型：
  • v1：稳定版（GA）
  • v1beta1等：测试版（可能变更）
• 查询方法：使用kubectl api-versions查看集群支持的API版本
• 版本变更：K8s迭代快，API可能调整，需注意：
  • 编写YAML时需确认当前有效版本
  • 可通过官方文档或示例获取正确版本号
• 请求流程：kubectl命令→API Server→对应版本接口处理

4）资源类型与常用资源



• 资源分类：
  • 通过kubectl api-resources可查看70+资源类型
  • 实际常用约20种（如Deployment、Service等）
• kind字段：指定要创建的资源功能类型
• 示例：apps/v1组包含Deployment等应用部署相关资源

5）元数据与命名空间



• metadata字段：
  • name：资源名称（同命名空间内必须唯一）
  • namespace：指定命名空间（默认default）
• 命名空间隔离：不同命名空间可存在同名资源
• 通用字段：所有资源定义都必须包含metadata配置

6）资源规格与副本数量



• 副本本质：相同镜像创建的完全相同的容器实例
• replicas字段：
  • 控制应用实例数量
  • 实际对应Pod数量
• 优势：
  • 提高应用可用性
  • 实现负载均衡
  • 支持弹性伸缩

2. 创建deployment示例



• 
• 基本命令格式: kubectl create deployment <名称> --image=<镜像名>
• 常用参数:
  • --replicas: 指定副本数量，默认为1
  • --port: 指定容器暴露的端口
  • --dry-run: 测试运行模式，可选"none"/"server"/"client"
• 创建多副本示例:
  • 该命令会创建名为web2的deployment，使用nginx镜像，并启动3个副本

3. 访问部署应用



1）创建NodePort服务

• 
• 命令格式:
• 参数说明:
  • --port: 服务对外暴露的端口
  • --target-port: 容器内部实际监听的端口
  • --type: 服务类型，NodePort表示会在每个节点上开放端口

2）验证服务访问

• 查看服务状态:
  • 输出会显示服务分配的NodePort端口(如31133)
• 访问验证:
  • 通过浏览器访问http://<节点IP>:<NodePort>
  • 多次刷新页面会轮询访问不同的pod副本
• 查看pod状态:
  • 可以观察各pod的READY状态和创建时间

4. 验证容器



1）容器访问日志分析



• 验证方法：通过kubectl get pods和kubectl logs命令验证三个容器的工作状态
• 日志特征：初始容器无访问日志，通过浏览器访问后生成Nginx访问记录（如10.244.36.64--[08/Nov/2021:12:44:16 +0000] "GET / HTTP/1.1"）
• 错误日志：记录缺失文件错误（如open() "/usr/share/nginx/html/favicon.ico" failed (2: No such file or directory)）

2）容器配置与启动过程



• 
• 启动流程：
  • 检查/docker-entrypoint.d/目录配置
  • 加载IPv6监听配置（10-listen-on-ipv6-by-default.sh）
  • 处理环境变量模板（20-envsubst-on-templates.sh）
  • 调优工作进程（30-tune-worker-processes.sh）
• 工作进程：每个容器启动2个worker进程（如start worker process 33）

3）浏览器访问与日志生成



• 访问机制：
  • 同一浏览器会复用TCP连接，请求可能集中在单个容器
  • 不同浏览器（如Chrome和360）会建立新连接，触发负载均衡
• 日志分布：通过kubectl logs可观察到不同容器分别记录各自处理的请求

4）容器分布与节点调度



• 
• 分布特点：
  • 使用kubectl get pods -o wide查看Pod分布节点
  • 默认调度算法考虑但不保证均匀分布（示例中3个Pod集中在node2）
• 高可用保障：即使单个节点故障，其他节点上的Pod仍可提供服务

5）高可用与并发处理



• 多副本优势：
  • 并发能力：单容器处理500请求→3容器理论1500并发
  • 负载均衡：类比"多人分食大西瓜"原理，分散处理压力
  • 最佳实践：生产环境建议至少2-3个副本保证可用性
• 服务暴露：通过kubectl expose deployment创建NodePort服务（如80:31133/TCP）

6）YAML文件配置解析



• 
• 核心字段：
  • replicas：副本数量（如replicas: 3）
  • selector：必须与template.metadata.labels匹配（如app: web）
  • template：定义Pod模板，包含容器镜像等配置
• 标签规范：
  • 建议包含项目和应用双标签（如project: ms和app: web）
  • 至少保证一个标签匹配用于控制器关联

7）容器规格与配置



• 配置对应关系：
  • docker run --name → YAML中containers.name
  • docker run --image → YAML中containers.image
  • 其他参数（网络、卷挂载、健康检查等）均在spec.containers下配置
• 扩展配置：支持定义启动命令、环境变量、资源限制等容器规格参数
• 配置层级：

三、答疑



1. YAML文件与资源对象

• 核心字段解析：
  • apiVersion: 定义API版本，如apps/v1
  • kind: 资源类型，如Deployment
  • metadata: 包含名称(name)和命名空间(namespace)等元数据
  • spec: 资源规格，包含副本数(replicas)、选择器(selector)和模板(template)
  • template: Pod模板，包含metadata和spec子字段
• 等效命令：示例YAML等同于kubectl create deployment web --image=lisi/java-demo --replicas=3 -n default

2. 调度策略与节点分配



• 调度特性：
  • 非强制性：默认调度策略不是强制性的，存在概率性分配
  • 影响因素：节点数量越少，Pod被分配到相同节点的概率越高
  • 实际表现：当集群机器较少时，可能出现多个Pod被调度到同一节点的情况

3. 标签选择器与标签冲突



• 标签规范：
  • 唯一性原则：不同应用的标签必须保持唯一性，避免冲突
  • 错误示例：创建第二个应用时若沿用相同标签(如app=web)，会导致选择器冲突
  • 命名建议：应采用项目名称+应用名称的复合标签(如project:ms + app:web1)

4. YAML文件中的横杠用途



• 语法含义：
  • 序列标识：横杠(-)表示YAML中的列表项开始
  • 容器定义：在containers字段下使用横杠定义多个容器
  • 类比说明：相当于Python中的列表数据结构，每个横杠项对应列表元素
• 格式对比：相同层级的字段应对齐排列，横杠项需保持统一缩进

5. YAML与JSON格式转换

• 格式互转：
  • 双向转换：YAML和JSON可以相互转换，保持数据等价性
  • 语法对应：YAML中的横杠列表对应JSON中的数组表示(方括号[])
  • 验证方法：可通过kubectl get deployment -o json命令查看JSON格式对照
• 数据结构：
  • 列表类型：containers字段使用横杠表示容器列表
  • 键值类型：metadata等字段使用缩进表示层级关系

6. 列表与字典数据结构

1）YAML基本结构

• 列表表示：在YAML中使用横杠"-"表示列表项，每个横杠代表一个独立的字典元素
• 字典嵌套：可以在列表中嵌套字典，字典使用花括号{}表示（在YAML中表现为缩进格式）
• 多元素特性：一个列表可以包含多个元素，例如容器配置中可以定义多个容器

2）数据格式规则

• 顺序无关性：字典中的键值对没有固定顺序要求，系统通过键名(key)来读取对应值
• 格式转换：YAML和JSON可以相互转换，因为它们遵循相同的数据结构规范
• 多容器定义：在containers列表中，每个容器定义都需要以"-"开头，例如：

3）语法标识方法

• 括号对应：
  • 花括号{}表示字典（对应JSON中的对象）
  • 中括号[]表示列表（对应JSON中的数组）
• 命名规则：同一个列表中可以有多个name字段，这通常用于定义多个容器
• 列表项特征：以"-"开头的行表示一个新的列表项，下面的缩进内容属于该列表项的属性

4）实际应用示例

• 
• 多容器配置：
• 字段说明：
  • imagePullPolicy：定义镜像拉取策略
  • terminationMessagePath：容器终止消息路径

5）Deployment核心字段

• 必填字段：
  • apiVersion：API版本（如apps/v1）
  • kind：资源类型（如Deployment）
  • metadata：资源元数据（包含name等）
• 规格字段：
  • replicas：副本数量（控制Pod实例数）
  • selector：标签选择器（需与template.metadata.labels匹配）
  • template：定义Pod模板
• 容器配置：
  • containers：必须为列表格式，可定义多个容器
  • 每个容器必须包含name和image字段

6）水平扩缩容

• 
• 扩缩方法：
  • 修改yaml中replicas值后重新apply
  • 使用命令：kubectl scale deployment web --replicas=10
• 注意事项：
  • replicas参数直接控制Pod副本数量
  • 实际运行实例数可能因资源不足而少于设定值
  • Deployment通过ReplicaSet来管理Pod副本

7. Service资源对象讲解



• 
• 核心配置项：
  • port: Service暴露的端口，用于集群内部通过ClusterIP访问
  • targetPort: 容器内应用实际监听的端口（如nginx默认80）
  • selector: 必须与Deployment中的Pod标签完全匹配
  • type: 服务类型，示例中使用NodePort类型
• 创建方式对比：
  • 命令式：kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort -n default
  • 声明式：通过YAML文件定义apiVersion、kind、metadata等字段
• 关联机制：
  • Service通过selector字段关联Deployment中定义的Pod标签（app: web）
  • 标签匹配是大小写敏感的，建议统一使用小写或下划线命名

8. 标签选择器的重要性



• 核心作用：
  • 资源筛选：支持按标签查询和过滤Kubernetes资源
  • 关联绑定：目前主要应用于Service与Pod之间的关联
• 配置要点：
  • Deployment中的spec.selector.matchLabels必须与template.metadata.labels完全一致
  • Service的selector必须与目标Pod的labels匹配
  • 命名规范建议使用小写字母，避免大写字符
• 实践技巧：
  • 关联资源时，标签相当于"服务发现"的锚点
  • 可通过kubectl get pods -l app=web验证标签选择器效果
  • 同一标签可被多个Service引用实现不同端口的暴露
  • 
• 实现原理：
  • Service控制器持续监听selector指定的标签变化
  • 当匹配标签的Pod发生变化时自动更新Endpoints对象
  • kube-proxy根据Endpoints更新iptables/ipvs规则

9. 创建Deployment与Service资源

1）Deployment资源定义

• API版本: 使用apps/v1版本API定义Deployment资源
• 资源类型: kind字段指定为Deployment类型资源
• 元数据配置: metadata中定义资源名称(name)和命名空间(namespace)
• 副本数量: spec.replicas字段指定需要创建的Pod副本数量为3个
• 标签选择器: selector.matchLabels需与template.metadata.labels保持一致，示例中使用app: web作为匹配标签
• Pod模板: template字段定义Pod的配置模板，包含容器镜像等配置
• 容器配置: containers字段定义容器名称(name)和镜像(image)，示例使用lisi/java-demo镜像

2）命令行等效操作

• 等效命令: 该YAML配置等同于命令kubectl create deployment web --image=lisi/java-demo --replicas=3 -n default
• 资源修改: 实际操作中修改了资源名称为web-c以避免与已有web资源冲突
• 标签变更: 演示中将标签从nginx改为ccc，service中相应修改selector为ccc以匹配Deployment

3）资源创建与验证

• 
• 部署操作: 使用kubectl apply命令部署修改后的Deployment和Service资源
• 资源查看:
  • kubectl get deployment查看Deployment状态，显示web-c有3个可用副本
  • kubectl get deployment,service同时查看Deployment和Service资源状态
• Service配置: 创建的Service类型为NodePort，自动分配了集群IP和节点端口(如30453/TCP)
• 标签验证: 特别检查了Pod标签是否与Service的selector匹配，确保服务发现正常工作

10. 查看资源标签与端点



1）查看Pod标签

• 
• 命令语法：使用kubectl get pods --show-labels查看Pod及其标签信息
• 标签示例：
  • app=java-demo：Java应用Pod的标签
  • ccc=nginx：Nginx相关Pod的自定义标签（老师特别强调的标签）
  • pod-template-hash：系统自动生成的部署模板哈希值
• 关键操作：通过--show-labels参数可以显示所有Pod的标签信息，这是查看标签的标准方法

2）查看Service关联的Pod

• 关联原理：Service通过标签选择器（Label Selector）关联具有特定标签的Pod
• 查看方法：
  • 完整命令：kubectl get endpoints（老师提到"get ep"是缩写形式）
  • 缩写形式：kubectl get ep（实际演示中使用的命令）
• 关键字段：
  • ENDPOINTS：显示Service关联的Pod IP地址和端口
  • AGE：显示资源创建时间

3）端点(Endpoints)详解

• 
• 端点组成：每个Service对应的端点由多个Pod的IP:端口组成
• 实际案例：
  • web-c服务关联了3个Pod：10.244.169.144:80,10.244.169.145:80,10.244.36.71:80
  • web2服务关联了3个Pod：10.244.169.141:80,10.244.169.142:80,10.244.169.143:80
• 工作原理：Service通过维护动态端点列表实现流量负载均衡到后端Pod

11. Service与Pod的关联机制



• 
• port字段: Service对外暴露的端口，通过ClusterIP访问时使用该端口
• targetPort字段: 容器内部实际服务端口，例如nginx镜像默认使用80端口
• selector字段: 标签选择器，必须与Deployment中定义的Pod标签完全匹配
• type字段: 定义Service类型，常见有ClusterIP、NodePort等
• 匹配机制: Service通过selector.app=web标签选择关联的Pod，这些Pod由Deployment控制器创建并维护
• 等价命令: 创建Service的kubectl命令为kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort -n default

12. 标签唯一性与规划



• 唯一性原则: 不同应用的标签必须保持唯一性，避免转发混乱
• 校验机制: Kubernetes仅校验标签是否存在，不校验是否与其他应用重复
• 后果说明: 如果多个应用使用相同标签，Service会将流量随机转发到这些Pod，导致代理错误
• 规划建议:
  • 为每个应用设计独特的标签组合
  • 建立统一的标签命名规范
  • 避免使用过于简单的通用标签如"app=web"
• 实际案例: 当Service正确关联三个Pod时，端点(ENDPOINTS)显示为10.244.36.71:80,10.244.169.144:80,10.244.169.145:80
• 错误示范: 如果标签冲突，端点可能包含不相关的Pod地址，导致流量被错误路由

13. 修改Service标签选择器的影响

1）Service与Pod的关联机制

• 
• 标签选择器原理: Service通过selector字段中的标签与Pod建立关联，不直接与Deployment产生绑定关系
• 配置示例:
• 动态响应特性: 修改selector后，Service会立即重新匹配符合新标签的Pod，旧关联的Pod会被自动解除

2）标签修改实验观察

• 
• 实验步骤:
  • 将selector从ccc: nginx改为app: web
  • 执行kubectl apply -f service.yaml
  • 通过kubectl get ep观察变化
• 现象记录:
  • 修改前关联3个Pod(10.244.169.144/145/36.71)
  • 修改后仅关联1个Pod(10.244.36.68)

3）标签验证

• 
• 关键验证命令:
• 验证结果:
  • 10.244.36.68的Pod确实具有app=web标签
  • 其他原关联Pod标签为ccc=nginx或app=web2

4）关联机制本质

• 核心规则:
  • Service与Pod之间仅通过标签匹配建立关联
  • 与Deployment无直接定义关系
• 配置要点:

5）恢复实验

• 恢复操作:
  • 将selector改回ccc: nginx
  • 再次apply配置文件
• 重要发现:
  • 关联关系立即恢复原状
  • 证明Service的标签选择是实时动态的

6）关键注意事项

• 访问隔离风险: 错误的标签选择会导致流量被错误路由到不相关的Pod
• 配置检查建议:
  • 修改selector前先用kubectl get pods --show-labels确认目标Pod标签
  • 修改后立即用kubectl get ep验证关联关系
• 生产环境建议:
  • 保持Service与Deployment中标签命名一致
  • 使用kubectl describe svc <name>查看关联状态

四、服务编排

1. YAML文件创建资源对象

• 
• 资源管理方法：
  • 部署：kubectl apply -f xxx.yaml
  • 卸载：kubectl delete -f xxx.yaml
• 文件合并技巧：
  • 多个资源定义可以合并到一个YAML文件中
  • 不同资源定义之间需要用---三个横杠分隔符隔开
  • 示例：cat deployment.yaml service.yaml > all.yaml
  • 
• 合并注意事项：
  • 不加分隔符会导致只执行最后一段资源定义
  • 正确添加分隔符后，kubectl会独立处理每个资源段
  • 合并文件后仍可使用kubectl apply -f all.yaml统一部署
• 删除特性：
  • 使用kubectl delete -f all.yaml可一键删除文件中定义的所有资源
  • 删除操作会同时移除deployment和service等相关资源

2. 资源字段太多记不住怎么办



• 辅助编写方法：
  • 使用create命令生成：kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > my-deploy.yaml
  • 使用get命令导出：kubectl get deployment nginx -o yaml > my-deploy.yaml
  • 字段查询：kubectl explain pods.spec.containers
  • 
• dry-run参数：
  • client：仅在客户端验证，不发送到服务器
  • server：发送到API server验证但不持久化
  • 配合-o yaml可生成标准YAML模板
• 模板优化建议：
  • 可删除creationTimestamp和status等系统自动生成的字段
  • 保留核心配置字段如metadata、spec等
  • 生成的模板可直接用于kubectl apply部署
• 开发建议：
  • 不需要死记硬背YAML字段
  • 善用命令行工具生成模板
  • 参考官方文档进行字段配置
  • YAML和JSON格式可以相互转换，但推荐使用YAML

五、YAML文件创建资源对象举例

• API版本: 必须指定apiVersion字段，如apps/v1，表示使用的Kubernetes API版本
• 资源类型: kind字段定义资源类型，如Deployment表示部署控制器
• 元数据配置:
  • metadata.name定义资源名称
  • metadata.namespace指定命名空间（默认为default）
• 规格配置:
  • spec.replicas定义Pod副本数量（如3个）
  • spec.selector.matchLabels必须与template.metadata.labels保持一致
  • spec.template定义Pod模板，包含容器镜像等配置

六、资源元数据和资源规格



• 标签匹配规则:
  • 强制匹配: selector.matchLabels必须与template.metadata.labels完全一致，否则会报错
  • 自动校验: Kubernetes会自动校验这两个标签的一致性
• 资源标签说明:
  • metadata.labels: 资源级别的标签，仅用于描述资源本身，与Pod选择无关
  • template.metadata.labels: Pod模板标签，用于控制器匹配和管理Pod
  • 区别: 这两个标签可以完全不同，资源标签通常用途有限，属于可选配置
• 修改建议:
  • 修改部署时只需调整需要变更的字段
  • 资源标签可以自由定义（如web2、abc等），不影响控制器工作
• 实践注意:
  • 资源标签与Pod标签是独立配置的
  • 资源标签主要用于资源分类和描述，实际业务中常省略
  • 必须确保selector.matchLabels与template.metadata.labels的键值对完全匹配
• 等效命令:
  • YAML配置等效于kubectl create deployment命令
  • 示例：kubectl create deployment web --image=lisi/java-demo --replicas=3 -n default

七、知识小结

知识点	核心内容	技术要点/易混淆点	应用场景
YAML格式特性	简洁的非标记性语言，广泛用于配置文件	与JSON可相互转换，使用缩进和横杠表示层级	Ansible Playbook、Kubernetes配置、微服务配置
Kubernetes Deployment结构	分为控制器定义和被控对象(Pod)定义	API版本必须与集群匹配，metadata需唯一命名	应用部署与管理
副本(Replica)机制	通过replicas字段指定相同容器的数量	多副本提供负载均衡和高可用性，副本分布有概率性	提高应用并发能力和容错性
标签(Label)系统	Selector用于关联Service与Pod，需保持严格一致	标签可多组但至少需一个匹配键值对，区分大小写	资源关联与服务发现
Service配置	通过expose命令或YAML暴露服务	port(Service端口)与targetPort(容器端口)映射需准确	服务访问入口
YAML编写技巧	使用--dry-run=client -o yaml生成模板	三个横杠---分隔多资源文件，字段层级需严格对齐	快速生成资源配置文件
资源关联原理	Deployment通过标签管理Pod组，Service通过标签选择Pod	错误标签会导致流量路由混乱，需确保唯一性	微服务架构部署
调试方法	kubectl logs查看容器日志，kubectl get ep验证Endpoint	多浏览器测试可验证负载均衡效果	部署问题排查
版本兼容性	API版本需通过kubectl api-versions验证	带beta的为测试版，v1为稳定版	集群升级适配