Question

以我关于tying profiles to namespaces的另一个问题为基础，是否有办法将配置文件绑定到群集？

由于我当前的kubernetes上下文指向skaffold run -p local -n skeleton时，我不小心运行了docker-desktop之类的命令，所以我发现了好几次。我想防止自己和团队中的其他人犯同样的错误。

我发现有一种specifying contexts的方法，但是如果开发人员使用kubeclt set-context custom --user=custom --cluster=custom之类的自定义上下文，这种方法就不能很好地发挥作用。我还在skaffold.yaml引用中找到了cluster field，但似乎不能满足我的需要，因为它不允许我指定集群名称。

Answer 1

在深入研究skaffold documentation并进行了几次测试之后，我终于设法找到了至少部分解决您的问题的方法，也许不是最优雅的方法，但仍然可以使用。如果我找到更好的方法，我将编辑我的答案。

让我们从头开始：

我们可以读到here：

与Kubernetes集群交互时，就像其他任何交互一样 Kubernetes原生工具Skaffold需要有效的Kubernetes上下文进行配置。所选的kube上下文确定Kubernetes 集群，Kubernetes用户和默认名称空间。默认， Skaffold使用您的kube-config文件中的当前kube-context。

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

重要的注意事项：kube-context未基于profile激活，但事实相反：特定的profile基于当前上下文触发（由kubectl config use-context选择）。

尽管我们可以通过修补（compare related answer）来覆盖skaffold.yaml配置文件中的默认设置，但无法基于选定的current-context覆盖profile，例如手动执行命令：

skaffold -p prod

在这里，您正在手动选择特定的profile。这样，您将绕过自动profile triggering。如文档所述：

skaffold.yaml中的激活：您可以基于以下条件自动激活配置文件

kubecontext（可以是字符串或正则表达式：以!为前缀将使匹配无效）

环境变量值

skaffold命令（dev / run / build / deploy）

假设我们要基于当前的kube-context来激活我们的个人资料，只是为了使其简单，但是我们可以像示例here一样通过AND和OR将不同的条件结合在一起。

解决方案

我想确保如果我运行skaffold -p prod skaffold将失败如果我的kubecontext指向我的作品以外的集群集群。

我很抱歉，这种方式无法做到。如果您已经通过prod profile手动选择了-p prod，那么您将绕过基于当前上下文的配置文件选择，因此无论如何，您都已经选择了可以做什么设置了可以完成的操作（当前选择为kube-context）。 在这种情况下，skaffold没有任何机制可以阻止您在错误的集群上运行某些东西。换句话说，您正在以这种方式强迫管道的某些行为。您已经通过选择配置文件同意了。如果您放弃使用-p或--profile标志，除非当前选择的kube-context自动执行，否则某些配置文件将永远不会被触发。 skaffold不会让这种事情发生。

让我们看下面的示例，展示如何使其工作：

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-context，所有构建都注定会失败。但是，我们可以通过在patching部分中skaffold.yaml的{{1}}的特定片段来覆盖此默认行为，并将profile再次设置为其标准名称。每个这样：

Dockerfile

或

skaffold run

仅当当前

skaffold dev

设置为kube-context时，

命令才会成功。否则它将失败。

我们可以使用以下方法进行检查：

minikube

先前将我们当前的skaffold run --render-only设置为与kube-context定义的activation部分中存在的匹配。

我偶然发现了几次命令，例如 profile当我当前的kubernetes上下文时指向skaffold run -p local -n skeleton。我想防止自己和其他人我们团队中的人犯了同样的错误。

我理解您的观点，最好有一些内置的机制来防止通过命令行选项覆盖docker-desktop中配置的此自动配置文件激活，但是看来目前尚不可能。如果您未指定skaffold.yaml，则-p local将始终根据当前的skaffold选择正确的配置文件。嗯，对于功能请求来说，它似乎是很好的材料。

将skaffold配置文件绑定到集群

1 个答案:

解决方案