什么是k8s的原地修改

Kubernetes中的原地修改（In-Place Update）是一种不重建Pod对象，仅更新Pod内部容器配置（如镜像、环境变量等）的变更方式。相比传统的重建升级（删除旧Pod、创建新Pod），原地修改通过复用现有Pod资源（IP、存储卷、调度位置等），大幅提升发布效率并减少业务中断风险。以下是核心要点：

???? 一、原地修改的核心原理

1. Pod对象复用
   当仅修改Pod中容器的image、env、resources等字段时，Kubernetes不会删除并重建整个Pod，而是由kubelet检测到容器配置变化后，原地重启对应容器。

   • 示例：若Pod包含业务容器app和日志容器log-agent，仅更新app的镜像时，log-agent会保持运行不受影响。

2. 技术依赖

   • kubelet的容器管理：kubelet为每个容器计算哈希值，检测到变化时触发容器重建。
   • API限制：K8s仅允许修改Pod的特定字段（如image、resources），其他字段变更会被拒绝。

???? 二、原地修改 vs 传统重建升级

⚙️ 三、实现原地修改的条件

1. 需特定控制器支持

   • K8s原生Deployment、StatefulSet不支持原地升级。
   • 需使用扩展组件：
     • OpenKruise的CloneSet：通过InPlaceIfPossible策略优先原地更新。
     • KubeBlocks的InstanceSet：支持数据库等有状态应用原地更新。
     • TKE的TApp/StatefulSetPlus：腾讯云的扩展实现。

2. 可修改字段范围

   • 默认支持：image、env、tolerations、activeDeadlineSeconds。
   • K8s ≥1.27新增：CPU/内存资源的原地调整（需开启InPlacePodVerticalScaling特性门控）。

✅ 四、原地修改的核心优势

1. 发布效率提升
   • 省去调度、IP分配、存储挂载等环节，升级速度提升80%以上（阿里实测数据）。
2. 业务影响最小化
   • Sidecar容器独立更新：如日志采集器升级不影响业务容器。
   • 流量无损：通过标记Pod为NotReady摘除流量，升级后恢复（需结合就绪探针）。
3. 集群稳定性增强
   • 避免大规模Pod重建导致的调度风暴和中心组件（API Server、Scheduler）压力。

⚠️ 五、注意事项与限制

1. 兼容性要求
   • 应用需容忍容器重启（例如：进程需支持优雅退出）。
   • 资源调整（如内存扩容）后，部分应用需重启容器才能生效。
2. 流量摘除依赖
   • 若未使用K8s Service，需集成服务发现组件手动摘流。
3. 版本限制
   • 资源原地调整需K8s ≥1.27，且需显式启用特性门控。

???? 总结

原地修改是K8s中平衡效率与稳定性的高级变更策略，适用于对发布速度和业务连续性要求高的场景（如在线服务、数据库）。其核心价值在于复用Pod底层资源，通过容器级重启避免重建开销，但需配合扩展控制器（如OpenKruise）和流量管理机制实现完整能力。

本文来自博客园，作者：dashery，转载请注明原文链接：https://www.cnblogs.com/ydswin/p/18940638