在脚本中处理 kubectl 上下文有哪些良好实践？

Question

我的 bash 脚本kubectl有时会在更改上下文时引起麻烦。运行脚本后，用户可能会意外地在错误的集群中进行更改。我想探讨一下您在处理脚本中的上下文方面的智慧。

脚本是否可以保存旧上下文并在完成后恢复旧上下文？（我考虑过运行kubectl config get-contexts查找当前上下文并在脚本完成后将其设置回来。但是如果用户尚未保存上下文，这可能会失败）

我想到的其他方法是保存 KUBECONFIG env var 的值，将其更改为临时文件，获取凭据并在脚本完成时恢复该值。

在我重新发明轮子之前，我想了解一下高级用户是如何处理这样的情况的？你能分享你的想法/想法吗？

Answer 1

一般来说，我认为隐式依赖可能被其他进程和用户任意更新的全局状态是有问题的。

即使有多个配置文件，对于使用哪个集群、用户、命名空间、上下文仍然不透明。

对于单个用户来说，kubectl配置文件提供了不必为每个命令重新输入标志的便利，我认为这应该是它的唯一目的。

在脚本中，我认为最好（更清晰|自我记录）明确并每次都包含--contextor --cluster, --user（可能还有）。--namespace

也就是说，建议使用变量而不是硬编码值，这样仍然存在出错的空间。

kubectl delete deployment/primary-service

# vs

KUBECONFIG=sam-monday-morning-config.yaml \
kubectl delete deplopyment/primary-service

# vs

kubectl delete deployment/primary-service \
--cluster=test-cluster \
--namespace=test-namespace \
--user=test-user