kubectl 使用规范

kubectl 建议使用规范。

在可复用脚本中使用 kubectl

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

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

子资源

• 对于 kubectl 的子命令，例如 get、patch、edit、apply 和 replace，你可以使用 --subresource 参数来抓取和更新支持子资源的所有资源的子资源。在 Kubernetes 1.33 版本中，只支持 status、scale 和 resize 子资源。
  • 对于 kubectl edit，不支持 scale 子资源。如果你在 kubectl edit 中使用 --subresource 并将子资源指定为 scale，该命令将报错。
• 针对子资源的 API 约定与针对完整资源的 API 约定相同。在将 status 子资源更新到新值时，请记住该子资源可能会被控制器协调为不同的值。

最佳实践

kubectl run

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

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

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

kubectl apply

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