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容器解决依赖问题

五、知识小结