20250718-6-Kubernetes 调度-Pod对象：环境变量，初始容器，静态_笔记
一、重启策略和健康检查
1. 重启策略
- Always: 当容器终止退出后总是重启容器，是默认策略
- OnFailure: 当容器异常退出（退出状态码非0）时才重启容器
- Never: 当容器终止退出后从不重启容器
- 实现差异:
- 重启会保持容器IP不变，实际上是使用原镜像重新创建容器
- 重建（recreate）会改变容器IP
- 主要差异体现在网络状态是否保持
2. 健康检查
- livenessProbe(存活检查):
- 检查失败会杀死容器，根据Pod的restartPolicy操作
- 示例：删除nginx容器的index.html文件会导致HTTP检查返回404，触发重启
- readinessProbe(就绪检查):
- 检查失败会将Pod从service endpoints中剔除
- 示例：删除index.html后Pod会被暂时移出负载均衡
- startupProbe(启动检查):
- 检查成功后才由存活检查接手，用于保护慢启动容器
- httpGet: 发送HTTP请求，返回200-400范围状态码为成功
- exec: 执行Shell命令返回状态码是0为成功
- tcpSocket: 发起TCP Socket建立成功
- 检查频率:
- 默认每10秒检查一次（periodSeconds:10）
- 首次检查延迟3秒（initialDelaySeconds:3）
- 超时时间1秒（timeout:1s）
- 优先级顺序: HTTP Get > exec > tcpSocket
3. 应用案例
1）例题:配置文件定义重启策略和健康检查
- 配置要点:
- livenessProbe和readinessProbe使用相同参数结构
- 可独立配置不同检查方式和参数
- 通常两者会同时定义但可调整不同行为
- 验证方法:
- kubectl get pods查看RESTARTS列计数
- kubectl get ep -w实时观察endpoints变化
- kubectl describe pod查看检查日志
- 典型场景:
- 模拟应用故障：删除index.html触发404
- 观察现象：容器重启计数+1，短暂从负载均衡移除
- 恢复过程：重建容器后自动重新加入服务
二、环境变量
1. 创建Pod时设置环境变量
- 应用场景：
- 容器内应用程序获取Pod信息
- 通过用户定义变量改变容器内应用程序的默认行为
- 定义方式：
- 自定义变量值：直接指定键值对，如示例中的ABC=123456
- 从Pod属性获取：通过fieldRef引用Pod元数据，包括：
- spec.nodeName：Pod所在节点名称
- metadata.name：Pod名称
- metadata.namespace：Pod命名空间
- status.podIP：Pod IP地址
- 从Secret/ConfigMap获取：后续会讲解的配置方式
1）例题:环境变量配置方法
- 与Docker对比：
- Docker仅支持自定义变量（通过-e参数）
- Kubernetes环境变量功能更强大，支持从Pod属性和配置资源获取
- 实现机制：
- 通过Pod定义中的env字段配置
- 变量注入到容器系统环境变量中
- 应用程序通过标准方式（如Python的os.environ）获取
- 使用场景：
- 替代部分配置文件功能，作为程序参数开关
- 获取Pod运行时信息（如节点分布、IP等）
2）例题:测试环境变量
- 测试步骤：
- 创建包含环境变量的Pod（如示例中的pod-envars）
- 进入容器执行env命令查看系统变量
- 使用grep过滤特定变量（如env | grep MY）
- 验证结果：
- 应能看到所有定义的变量（MY_NODE_NAME、MY_POD_NAME等）
- 自定义变量（如ABC=123456）也会出现在环境变量中
- 程序使用方式：
- Python：通过os.environ.get('VAR_NAME')获取
- Java：使用System.getenv("VAR_NAME")方法
- Shell脚本：直接通过$VAR_NAME引用
三、Init容器
1. Init容器的特点
- 基本概念：Init Container是用于初始化工作的容器，执行完成后就会结束，可以理解为一次性任务。
- 配置特性：
- 支持大部分应用容器配置
- 不支持健康检查功能
- 执行顺序：优先于应用容器执行
- 典型应用场景：
- 环境检查：确保应用容器依赖的服务（如数据库）先启动
- 初始化配置：为应用容器准备配置文件等资源
- 生命周期：与边车容器(Sidecar)的主要区别在于，Init容器是临时性的，完成任务后即退出；而边车容器是持久运行的。
- 依赖关系：如果Init容器未成功执行，主容器将不会被启动，这种机制保证了初始化工作的强制性。
1）例题:Init容器应用示例
- 典型场景：
- 数据库依赖检查：Web服务需要确保数据库先启动，Init容器可循环检查数据库状态
- 动态资源获取：从代码仓库拉取网站程序或配置文件
- 实现原理：
- 使用共享存储卷(emptyDir)实现Init容器与主容器的数据交换
- Init容器将下载的文件存放在共享目录，主容器从同一目录读取
- 执行状态标识：在Pod状态中会显示"Init:0/1"等标记，明确指示Init容器的执行进度
- 退出机制：Init容器执行完毕后，状态会变为Completed，此时主容器才会启动
- 技术实现要点：
- 共享卷必须正确挂载到两个容器的对应路径
- Init容器的命令需要确保能够正确退出（返回0状态码）
- 对于检查类任务，需要实现重试机制直到条件满足
- 容器分类：
- Infrastructure Container：基础容器，维护Pod网络空间
- InitContainers：初始化容器，先于业务容器执行
- Containers：业务容器，可并行启动多个
四、静态Pod
1. 静态Pod特点
- 管理方式：由特定节点上的kubelet直接管理，不经过API Server
- 控制器限制：不能使用Deployment等控制器进行管理
- 命名规则：Pod名称会自动包含当前节点名称作为标识
- 配置路径：通过kubelet配置文件中的staticPodPath指定（默认路径为/etc/kubernetes/manifests）
- 创建方式：只需将Pod的yaml文件放入指定目录，kubelet会自动创建
2. 应用场景
- 核心用途：主要用于Kubernetes集群自身的搭建过程
- 启动顺序：
- 先启动kubelet
- kubelet加载静态Pod配置
- 启动etcd、kube-apiserver等核心组件
- 最终完成集群搭建
- 工作机制：解决"集群未启动时如何运行核心组件"的鸡生蛋问题
- 生产环境：工作中通常不会直接使用静态Pod，主要用于理解集群启动原理
3. 静态Pod管理
- 验证方法：
- 将Pod yaml文件移动到staticPodPath目录
- 无需kubectl apply，kubelet会自动检测并创建Pod
- 通过kubectl get pods可查看自动创建的Pod
- 节点标识：Pod名称会附加节点名称（如pod-static-k8s-master）
- 删除方式：需要从静态目录中移除yaml文件，kubelet会自动删除对应Pod
- 重建测试：演示了移动yaml文件后Pod自动重建的过程
- 基础容器(Infrastructure Container)：
- 维护整个Pod的网络空间
- 典型代表是pause容器
- 初始化容器(InitContainers)：
- 先于业务容器执行
- 执行完成后立即退出
- 不支持健康检查（因为是一次性任务）
- 业务容器(Containers)：
- 并行启动
- 持续运行的主业务容器
- 顺序控制：普通容器无法控制启动顺序，需用init容器解决依赖问题
五、知识小结
知识点 | 核心内容 | 考试重点/易混淆点 | 难度系数 |
健康检查机制 | 存活检查(livenessProbe)和就绪检查(readinessProbe)的配置与区别 | 存活检查失败会重启容器，就绪检查失败会从Service端点移除 | ⭐⭐⭐⭐ |
环境变量注入 | 通过env字段定义变量，支持从Pod属性/自定义值/Secret获取 | valueFrom.fieldRef获取Pod元数据 vs 直接value定义 | ⭐⭐⭐ |
初始化容器 | 先于主容器执行的一次性任务，用于依赖检查/配置初始化 | 与边车容器的核心区别：初始化容器执行完即退出 | ⭐⭐⭐⭐ |
静态Pod | 由kubelet直接管理，用于集群核心组件部署 | 特征：名称包含节点名、无控制器管理 | ⭐⭐⭐⭐ |
数据卷共享 | 通过emptyDir实现初始化容器与主容器的文件共享 | 典型应用场景：配置文件下载/网页资源预加载 | ⭐⭐⭐ |
服务暴露 | 通过Service的NodePort方式暴露Nginx服务 | 端口映射关系：NodePort:31242 → Pod:80 | ⭐⭐ |
故障模拟 | 删除index.html触发健康检查失败 | 观察RESTARTS计数和Endpoint变化 | ⭐⭐⭐⭐ |
容器重启策略 | 重建(IP变化) vs 重启(IP不变)的底层机制 | restartPolicy与recreate的实际差异 | ⭐⭐⭐⭐ |