kubectl 使用约定

kubectl 的推荐使用规范。

在可重用脚本中使用 kubectl

为了在脚本中获得稳定的输出

• 请求其中一种面向机器的输出格式，例如 -o name、-o json、-o yaml、-o go-template 或 -o jsonpath。
• 完全限定版本。例如，jobs.v1.batch/myjob。这将确保 kubectl 不使用其默认版本，该版本可能会随时间变化。
• 不要依赖上下文、偏好设置或其他隐式状态。

子资源

• 您可以使用 --subresource 参数来获取和更新支持它们的资源的 kubectl 子命令（例如 get、patch、edit、apply 和 replace）的子资源。在 Kubernetes 1.35 版本中，仅支持 status、scale 和 resize 子资源。
  • 对于 kubectl edit，不支持 scale 子资源。如果在使用 --subresource 与 kubectl edit 时指定 scale 作为子资源，则该命令将出错。
• 对子资源的 API 合同与完整资源相同。在更新 status 子资源的值时，请记住控制器可能会将该子资源重新协调到不同的值。

最佳实践

kubectl run

为了满足基础设施即代码的 kubectl run 要求

• 使用特定版本标签标记镜像，并且不要将该标签移动到新版本。例如，使用 :v1234、v1.2.3、r03062016-1-4，而不是 :latest（有关更多信息，请参阅 Kubernetes 配置最佳实践）。
• 检查脚本中是否存在高度参数化的镜像。
• 切换到签入源代码控制的配置文件，以实现通过 kubectl run 标志无法表达的功能。

您可以使用 --dry-run=client 标志来预览将发送到集群的对象，而无需实际提交它。

kubectl apply

• 您可以使用 kubectl apply 来创建或更新资源。有关使用 kubectl apply 更新资源的更多信息，请参阅 Kubectl Book。