什么是k8s的原地修改
<p>Kubernetes中的<strong>原地修改</strong>（In-Place Update）是一种<strong>不重建Pod对象</strong>，仅更新Pod内部容器配置（如镜像、环境变量等）的变更方式。相比传统的重建升级（删除旧Pod、创建新Pod），原地修改通过复用现有Pod资源（IP、存储卷、调度位置等），大幅提升发布效率并减少业务中断风险。以下是核心要点：</p><hr>
<h3 id="-一原地修改的核心原理">🔧 一、原地修改的核心原理</h3>
<ol>
<li>
<p><strong>Pod对象复用</strong><br>
当仅修改Pod中容器的<code>image</code>、<code>env</code>、<code>resources</code>等字段时，Kubernetes不会删除并重建整个Pod，而是由<strong>kubelet</strong>检测到容器配置变化后，原地重启对应容器。</p>
<ul>
<li><strong>示例</strong>：若Pod包含业务容器<code>app</code>和日志容器<code>log-agent</code>，仅更新<code>app</code>的镜像时，<code>log-agent</code>会保持运行不受影响。</li>
</ul>
</li>
<li>
<p><strong>技术依赖</strong></p>
<ul>
<li><strong>kubelet的容器管理</strong>：kubelet为每个容器计算哈希值，检测到变化时触发容器重建。</li>
<li><strong>API限制</strong>：K8s仅允许修改Pod的特定字段（如<code>image</code>、<code>resources</code>），其他字段变更会被拒绝。</li>
</ul>
</li>
</ol>
<hr>
<h3 id="-二原地修改-vs-传统重建升级">🚀 二、原地修改 vs 传统重建升级</h3>
<table>
<thead>
<tr>
<th><strong>特性</strong></th>
<th><strong>原地修改</strong></th>
<th><strong>传统重建升级（如Deployment）</strong></th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Pod重建</strong></td>
<td>❌ 无需重建Pod</td>
<td>✅ 删除旧Pod，创建新Pod</td>
</tr>
<tr>
<td><strong>IP变化</strong></td>
<td>❌ 保持不变</td>
<td>✅ 重新分配IP</td>
</tr>
<tr>
<td><strong>存储卷挂载</strong></td>
<td>❌ 复用现有卷（无需卸载/重挂）</td>
<td>✅ 重新挂载（可能触发延迟）</td>
</tr>
<tr>
<td><strong>调度开销</strong></td>
<td>❌ 无需重新调度</td>
<td>✅ 需调度到新节点</td>
</tr>
<tr>
<td><strong>镜像拉取速度</strong></td>
<td>✅ 仅下载差异层（节省80%时间）</td>
<td>❌ 完整拉取新镜像</td>
</tr>
</tbody>
</table>
<hr>
<h3 id="️-三实现原地修改的条件">⚙️ 三、实现原地修改的条件</h3>
<ol>
<li>
<p><strong>需特定控制器支持</strong></p>
<ul>
<li>K8s原生<code>Deployment</code>、<code>StatefulSet</code><strong>不支持</strong>原地升级。</li>
<li>需使用扩展组件：
<ul>
<li><strong>OpenKruise的CloneSet</strong>：通过<code>InPlaceIfPossible</code>策略优先原地更新。</li>
<li><strong>KubeBlocks的InstanceSet</strong>：支持数据库等有状态应用原地更新。</li>
<li><strong>TKE的TApp/StatefulSetPlus</strong>：腾讯云的扩展实现。</li>
</ul>
</li>
</ul>
</li>
<li>
<p><strong>可修改字段范围</strong></p>
<ul>
<li><strong>默认支持</strong>：<code>image</code>、<code>env</code>、<code>tolerations</code>、<code>activeDeadlineSeconds</code>。</li>
<li><strong>K8s ≥1.27新增</strong>：CPU/内存资源的原地调整（需开启<code>InPlacePodVerticalScaling</code>特性门控）。</li>
</ul>
</li>
</ol>
<hr>
<h3 id="-四原地修改的核心优势">✅ 四、原地修改的核心优势</h3>
<ol>
<li><strong>发布效率提升</strong>
<ul>
<li>省去调度、IP分配、存储挂载等环节，升级速度提升80%以上（阿里实测数据）。</li>
</ul>
</li>
<li><strong>业务影响最小化</strong>
<ul>
<li><strong>Sidecar容器独立更新</strong>：如日志采集器升级不影响业务容器。</li>
<li><strong>流量无损</strong>：通过标记Pod为<code>NotReady</code>摘除流量，升级后恢复（需结合就绪探针）。</li>
</ul>
</li>
<li><strong>集群稳定性增强</strong>
<ul>
<li>避免大规模Pod重建导致的调度风暴和中心组件（API Server、Scheduler）压力。</li>
</ul>
</li>
</ol>
<hr>
<h3 id="️-五注意事项与限制">⚠️ 五、注意事项与限制</h3>
<ol>
<li><strong>兼容性要求</strong>
<ul>
<li>应用需容忍容器重启（例如：进程需支持优雅退出）。</li>
<li>资源调整（如内存扩容）后，部分应用需重启容器才能生效。</li>
</ul>
</li>
<li><strong>流量摘除依赖</strong>
<ul>
<li>若未使用K8s Service，需集成服务发现组件手动摘流。</li>
</ul>
</li>
<li><strong>版本限制</strong>
<ul>
<li>资源原地调整需K8s ≥1.27，且需显式启用特性门控。</li>
</ul>
</li>
</ol>
<hr>
<h3 id="-总结">💎 总结</h3>
<p>原地修改是K8s中<strong>平衡效率与稳定性</strong>的高级变更策略，适用于对发布速度和业务连续性要求高的场景（如在线服务、数据库）。其核心价值在于<strong>复用Pod底层资源</strong>，通过容器级重启避免重建开销，但需配合扩展控制器（如OpenKruise）和流量管理机制实现完整能力。</p>
</div>
<div id="MySignature" role="contentinfo">
<p>本文来自博客园，作者：dashery，转载请注明原文链接：https://www.cnblogs.com/ydswin/p/18940638</p><br><br>
来源：https://www.cnblogs.com/ydswin/p/18940638
頁:
[1]