0

建立我关于将配置文件绑定到名称空间的另一个问题，有没有办法将配置文件绑定到集群？

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

我发现有一种指定上下文的方法，但如果开发人员使用自定义上下文（如kubeclt set-context custom --user=custom --cluster=custom. 我还在参考资料中找到了一个集群字段，skaffold.yaml但它似乎不能满足我的需要，因为它不允许我指定集群名称。

4

1 回答 1

2

在挖掘了skaffold 文档并执行了几次测试之后，我终于设法找到了您问题的至少部分解决方案，可能不是最优雅的解决方案，但仍然可以使用。如果我找到更好的方法，我将编辑我的答案。

让我们从头开始：

我们可以在这里阅读：

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

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

重要的是要记住：kube-context不是根据 激活的，profile但相反的是：特定profile是根据当前上下文触发的（由 选择kubectl config use-context）。

skaffold.yaml虽然我们可以通过修补（比较相关答案）从我们的配置文件中覆盖默认设置，但无法像在您的命令中那样手动覆盖current-context基于选择的设置：profile

skaffold -p prod

在这里，您手动选择特定的profile. 这样您就可以绕过自动配置文件触发。正如文档所说：

skaffold.yaml 中的激活：您可以根据以下内容自动激活配置文件

  • kubecontext（可以是字符串或正则表达式：前缀 with!将否定匹配）
  • 环境变量值
  • skaffold 命令（开发/运行/构建/部署）

假设我们想根据当前激活我们的配置文件kube-context只是为了让它变得简单，但是我们可以通过 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.yamlprofileDockerfile

skaffold run

或者

skaffold dev

kube-context仅当电流设置为时，命令才会成功minikube。否则会失败。

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

skaffold run --render-only

之前将我们的电流设置为与我们定义部分中kube-context存在的内容相匹配的电流。activationprofile

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

我理解您的观点，如果有一些内置机制可以防止覆盖skaffold.yaml由命令行选项配置的自动配置文件激活，那会很好，但目前看来这是不可能的。如果不指定-p local，skaffold将始终根据当前选择正确的配置文件context。好吧，它看起来像是功能请求的好材料。

于 2020-02-07T05:19:23.783 回答