Kubectl set image vs. apply from CI - 最佳实践

Question

考虑一下这个名为 myapp 的基本 rest 应用程序的部分 k8s 部署清单

spec:
  replicas: 1
     ...
      containers:
        name: myapp
        image: us.gcr.io/my-org/myapp.3
      ...
      resources:
        limits:
          cpu: 1000m
          memory: 1.5Gi

我们将增量构建存储在 Google Container Registry (GCR) 中，例如 (myapp.1, myapp.2, myapp.3)。在当前设置中，我们的 CI 系统 (Jenkins) 执行以下操作：

• Docker 构建新镜像myapp.4 并上传到 GCR
• 运行 kubectl set image myapp.4 以更新部署。

这适用于大多数部署，但部署清单本身的更改呢？例如，如果我们将resource > cpu 更改为 1500m，我们现在必须手动运行kubectl apply。 这一步需要自动化，这让我明白了我的观点： 除了使用kubectl set image，构建系统本身不能每次都运行kubectl apply 吗？在 CI/CD 管道中何时使用 kubectl set image 与 kubectl apply 比较合适？

只要提供了新图像，kubectly apply 不会同时处理图像更新和其他配置更改吗？如果是这样，仅kubcetl set image 的优点/缺点是什么？

PS - 我们的部署很简单，主要依赖于单个副本，不一定需要 100% 的正常运行时间。

Answer 1

使用kubectl set image，您只需修补部署中部署的映像。要修补其他值（CPU、内存、副本...），您可以使用其他命令，例如 path 或 set repiclas

问题在于您失去了与原始 YAML 定义的一致性。如果您的集群崩溃并且您想重新创建一个，您将不会有完全相同的部署，因为您的 YAML 文件将过时（“补丁”将不为人所知）

---

使用kubectl apply，您可以覆盖现有的控制平面配置并设置 YAML 的确切内容。当您处于 GitOps 模式时，它更加一致并且是一种常见的做法。

---

使用哪一个？一切都取决于您需要什么以及您想要实现什么。我更喜欢kubectl apply 模式，因为它的一致性和可重玩性，但这取决于你！

Answer 2

使用最适合您的情况。请记住，当涉及到资源等的应用位置时，CI 将是“事实的来源”。如果您在其他地方更改它并运行 CI 作业，它会再次更新它。

大多数 CI 引擎只能在文件更改的情况下触发特定作业。 这样，您可以在清单未更改的情况下修补映像，并在清单已更改的情况下运行完整应用。

我个人通常使用图像补丁方法，因为我更喜欢将我的 Kube 文件与我的源代码分开，但如前所述，任何适合你的情况都是最好的！

Answer 3

每次更改应用程序代码或 Kubernetes 配置时，您都有两个选项来更新集群：kubectl apply 或 kubectl set image。

您可以使用kubectl set 更改对象的image、resources（CPU 和内存等计算资源）或selector 字段。

您可以使用kubectl apply 通过应用新的或更新的配置来更新资源