将skaffold配置文件绑定到集群

挖过之后 skaffold documentation 通过执行几次测试,我终于设法找到了你问题的至少部分解决方案,也许不是最优雅的,但仍然有效。如果我找到更好的方法,我会编辑我的答案。

让我们从头开始:

正如我们所读到的 here :

与Kubernetes集群交互时,就像其他集群一样 Kubernetes原生工具,Skaffold需要有效的Kubernetes上下文 待配置。所选的kube上下文决定了Kubernetes 集群、Kubernetes用户和默认命名空间。默认情况下, Skaffold使用kube配置文件中的当前kube上下文。

这一点非常重要,因为我们实际上是从 kube-context 基于此,我们能够触发特定的配置文件,而不是oposite。

重要的是要记住 : kube上下文 未根据 profile 但事实恰恰相反:具体 轮廓 根据当前上下文触发(由选择 kubectl config use-context ).

虽然我们可以从我们的 skaffold.yaml 通过修补配置文件( compare related answer ),无法覆盖 current-context 基于选择 轮廓 例如,按照您的命令手动操作:

skaffold -p prod

在这里,您可以手动选择特定 轮廓 .这样你就可以绕过自动 profile triggering 如文件所述:

skaffold.yaml中的激活 :您可以根据以下条件自动激活配置文件

• kubecontext(可以是字符串或正则表达式:前缀为 ! 将取消比赛)
• 环境变量值
• skaffold命令(dev/run/build/deploy)

假设我们想根据当前状态激活我们的个人资料 kube上下文 只是为了简单起见,我们可以像示例中那样通过AND和OR将不同的条件连接在一起 here .

解决方案

我想确保如果我运行skaffold-p prod,skaffold会失败 如果我的kubecontext指向生产环境以外的集群 集群。

我很害怕不能这样做。如果您已经手动选择 prod profile 通过 -p prod 您正在绕过基于当前上下文的配置文件选择,因此您已经选择了 我们能做什么 不管怎样 在哪里可以做到 已设置(当前已选择 kube上下文 ). 在这种情况下 skaffold 没有任何机制可以防止您在错误的集群上运行某些东西 换句话说,你是在强迫你的管道的某些行为。您已经通过选择配置文件同意了。如果你放弃使用 -p 或 --profile 标志,除非当前选中,否则某些配置文件将永远不会被触发 kube上下文 它是自动完成的。 斯卡福德 只是不会让这种情况发生。

让我们看一下以下示例,展示如何使其工作:

apiVersion: skaffold/v2alpha3
kind: Config
metadata:
  name: getting-started
build:
  artifacts:
  - image: skaffold-example
    docker:
      dockerfile: NonExistingDockerfile # the pipeline will fail at build stage
  cluster:
deploy:
  kubectl:
    manifests:
    - k8s-pod.yaml
    flags:
      global: # additional flags passed on every command.
      - --namespace=default
  kubeContext: minikube
profiles:
- name: prod
  patches:
  - op: replace
    path: /build/artifacts/0/docker/dockerfile
    value: Dockerfile
  - op: replace
    path: /deploy/kubectl/flags/global/0
    value: --namespace=prod
  activation:
  - kubeContext: minikube
    command: run 
  - kubeContext: minikube
    command: dev 

一般来说,我们 skaffold.yaml 我们配置的配置:

dockerfile: NonExistingDockerfile # the pipeline will fail at build stage

直到我们说出我们的名字 Dockerfile - "NonExistingDockerfile" 每条管道都会发生故障 build 舞台。因此,默认情况下,无论发生什么,所有构建都是如此 kube上下文 被选中注定会失败。因此,我们可以通过以下方式覆盖此默认行为 patching 特定片段 skaffold.yaml 在我们的 轮廓 重新设置 Dockerfile 它的标准名称。这样每一个:

skaffold run

或

skaffold dev

只有当当前 kube上下文 设置为 minikube 否则,它将失败。

我们可以通过以下方式进行检查:

skaffold run --render-only

之前设置我们的当前 kube上下文 与中存在的内容相匹配 activation 我们的部分 轮廓 定义。

我发现有几次我不小心运行了这样的命令 skaffold run -p local -n skeleton 当我当前的kubernetes上下文 指向 docker-desktop .我想防止自己和他人 我团队中的人不会犯同样的错误。

我理解您的观点,即最好有一些内置机制来防止覆盖在中配置的自动配置文件激活 skaffold.yaml 通过命令行选项,但目前看来这是不可能的。如果您没有指定 -p local , 斯卡福德 将始终根据当前配置文件选择正确的配置文件 context 嗯,它看起来是很好的材料 功能请求 .

我能够通过以下两种方式锁定Skaffold的kubeContext:

skaffold dev --profile="dev-cluster-2" --kube-context="dev-cluster-2"

我还在skaffold.yaml中设置了:

profiles:
- name: dev-cluster-2
  activation:
    - kubeContext: dev-cluster-2
  deploy:
    kubeContext: dev-cluster-2

看起来 使用这种组合说明 skaffold 明确地不使用 currentContext 属于 $KUBECONFIG 通过这种组合,如果 --kube-context cli参数中缺少 activation 介入 skaffold.yaml 如果发生以下情况,将触发错误消息 当前上下文 在里面 $KUBECONFIG 与激活的Skaffold配置文件的预期kubeContext不同。

希望这能帮助那些在skaffold随机切换当前kubernetes集群时感到痛苦的开发人员,如果 当前上下文 在里面 $KUBECONFIG 作为副作用,例如另一个终端窗口。