Kubernetes实战：使用kubectl patch命令原地更新API对象

Kubernetes实战：使用kubectl patch命令原地更新API对象

website Kubernetes website and documentation repo: 项目地址: https://gitcode.com/gh_mirrors/webs/website

概述

在Kubernetes集群管理过程中，我们经常需要对已部署的资源对象进行修改。kubectl patch命令提供了一种高效的方式来对API对象进行部分更新，而无需重新部署整个资源。本文将深入探讨如何使用kubectl patch命令进行战略合并补丁(Strategic Merge Patch)和JSON合并补丁(JSON Merge Patch)操作。

准备工作

在开始之前，请确保您已经：

1. 安装并配置了Kubernetes集群
2. 安装了kubectl命令行工具
3. 拥有足够的权限来管理Deployment等资源对象

战略合并补丁实战

基础部署示例

首先，我们创建一个简单的Deployment，该部署包含2个副本，每个Pod运行一个nginx容器：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: patch-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: patch-demo-ctr
        image: nginx

应用这个Deployment后，我们可以通过kubectl get pods看到两个运行中的Pod。

添加新容器

现在，我们想要在不重新部署整个Deployment的情况下，为每个Pod添加一个redis容器。我们可以创建一个补丁文件patch-file.yaml：

spec:
  template:
    spec:
      containers:
      - name: patch-demo-ctr-2
        image: redis

应用补丁：

kubectl patch deployment patch-demo --patch-file patch-file.yaml

补丁机制解析

这种补丁方式称为"战略合并补丁"。关键点在于：

1. 对于PodSpec中的containers字段，Kubernetes使用"merge"策略
2. 补丁不是简单地替换整个列表，而是将新容器合并到现有列表中
3. 合并的依据是每个容器的"name"字段（由patchMergeKey指定）

我们可以通过查看Kubernetes源码中的相关结构体定义来理解这一行为：

type PodSpec struct {
  Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name"`
}

列表替换场景

并非所有列表都使用合并策略。例如，PodSpec中的tolerations字段就没有指定patchStrategy，因此默认使用"replace"策略，会完全替换现有列表。

JSON合并补丁实战

基本概念

JSON合并补丁与战略合并补丁的主要区别在于：

1. 更新列表时必须指定完整的新列表
2. 新列表会完全替换现有列表
3. 使用--type=merge参数指定补丁类型

实际操作

创建补丁文件patch-file-2.yaml：

spec:
  template:
    spec:
      containers:
      - name: patch-demo-ctr-3
        image: gcr.io/google-samples/hello-app:2.0

应用JSON合并补丁：

kubectl patch deployment patch-demo --type merge --patch-file patch-file-2.yaml

这次更新后，原有的containers列表被完全替换，只包含新指定的容器。

retainKeys策略高级用法

使用场景

当我们需要更新一个对象的某个字段，同时需要清除该对象中其他相关字段时，可以使用retainKeys策略。这在修改Deployment的更新策略时特别有用。

示例演示

假设我们有一个使用RollingUpdate策略的Deployment，现在要改为Recreate策略：

1. 直接尝试修改会失败，因为保留了rollingUpdate配置
2. 使用retainKeys策略可以解决这个问题

补丁文件示例：

spec:
  strategy:
    $retainKeys:
    - type
    type: Recreate

应用补丁：

kubectl patch deployment retainkeys-demo --type strategic --patch-file patch-file-retainkeys.yaml

扩展应用技巧

多种补丁格式支持

kubectl patch支持多种格式的补丁：

1. YAML文件
2. JSON文件
3. 直接在命令行中指定补丁内容

子资源更新

从Kubernetes 1.24开始，可以使用--subresource参数直接更新特定子资源，如scale：

kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":3}}'

这种方式特别适合自动化脚本和CI/CD流程中调整副本数量。

最佳实践建议

1. 对于核心资源（如Deployment、Service等），优先使用战略合并补丁
2. 自定义资源(CRD)不支持战略合并补丁，只能使用JSON合并补丁
3. 复杂的更新操作可以考虑结合使用kubectl edit或kubectl apply
4. 生产环境中建议先在测试环境验证补丁效果
5. 重要的变更应该记录在版本控制系统中，而不仅是通过命令行操作

总结

kubectl patch命令是Kubernetes管理员工具箱中一个非常强大的工具，它允许我们对运行中的资源进行精确的、最小化的修改。通过理解战略合并补丁和JSON合并补丁的区别，以及retainKeys等高级策略，我们可以更高效地管理Kubernetes集群中的各种资源。

掌握这些技巧后，您将能够在不中断服务的情况下，对生产环境进行精细化的配置调整，这对于实现真正的GitOps和持续部署流程至关重要。

website Kubernetes website and documentation repo: 项目地址: https://gitcode.com/gh_mirrors/webs/website