Kubernetes 将skaffold配置文件连接到群集

基于我的另一个问题，是否有一种方法将概要文件绑定到集群

我发现现在有几次，当我当前的kubernetes上下文指向

docker desktop

时，我意外地运行了类似于

skaffold run-p local-n skeleton

的命令。我想防止我自己和我团队的其他人犯同样的错误

我发现有一种方法，但是如果开发人员使用自定义上下文，比如

kubeclt set context custom--user=custom--cluster=custom

，那么这种方法就不能很好地发挥作用。我在

skaffold.yaml

参考中也找到了一个，但它似乎不能满足我的需要，因为它不允许我指定集群名称。

在深入研究并执行了几项测试之后，我终于找到了您的问题的部分解决方案，可能不是最优雅的，但仍然可以正常工作。如果我找到更好的方法，我会编辑我的答案

让我们从头开始：

正如我们所看到的：

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

这是非常重要的一点，因为我们实际上是从

kube上下文开始的，基于它，我们能够触发特定的概要文件，而不是oposite

记住这一点很重要：
kube-context
不会根据
配置文件激活，但情况正好相反：特定的
配置文件
会根据当前上下文触发（由
kubectl-config-use-context
选择）

虽然我们可以通过修补（）覆盖
skaffold.yaml
config文件中的默认设置，但无法基于选定的
配置文件来覆盖
当前上下文
，例如，在您的命令中手动：

skaffold -p prod

在这里，您可以手动选择特定的
配置文件
。这样你就绕过了自动控制。正如文件所说：

在skaffold.yaml中激活：您可以基于


kubecontext（可以是字符串或regexp:前缀为
！
将否定匹配）
环境变量值
skaffold命令（dev/run/build/deploy）

假设我们想基于当前
kube上下文激活我们的配置文件，只是为了使其简单化，但是我们可以通过AND和OR将不同的条件连接在一起

解决方案
我想确保如果我运行skaffold-p prod，skaffold将失败
如果我的kubecontext指向我的产品以外的集群
集群

我很吃惊，这件事不能这样做。如果您已经通过
-p prod
手动选择了
prod profile
，那么您将绕过基于当前上下文的概要文件选择，因此您已经选择了可以执行的操作，无论在何处执行（当前选择的
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
-
命名为“不存在的Dockerfile”
之前，每个管道都将在其
构建
阶段失败。因此，默认情况下，无论选择什么
kube上下文
，所有构建都注定会失败。我们可以通过在
配置文件
部分中对
skaffold.yaml
的特定片段进行修补
并再次将
Dockerfile
设置为其标准名称来覆盖此默认行为。通过这种方式，每个：

skaffold run

或

仅当当前
kube上下文设置为
minikube
时，命令才会成功。否则它将失败

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

skaffold run --render-only

之前，我们将当前的
kube上下文设置为与我们的
profile
定义的
activation
部分相匹配的上下文

我发现有几次我不小心运行了如下命令
skaffold运行-p local-n骨架
正在指向docker桌面
。我想阻止我自己和其他人
我的团队成员不会犯同样的错误

我理解您的观点，即最好有一些内置机制，防止通过命令行选项覆盖在
skaffold.yaml
中配置的自动配置文件激活，但目前看来这是不可能的。如果未指定
-p local
，
skaffold
将始终根据当前
上下文选择正确的配置文件。嗯，它看起来像是功能请求的好材料。你能解释一下你想要达到什么样的状态吗？我想确保如果我运行
skaffold-p prod
skaffold，如果我的kubecontext指向生产集群以外的集群，那么skaffold将失败。这也发生在我身上-很多次！激活是解决此问题的好方法，但仍然不理想。你看过DevSpace吗？它与斯卡福德非常相似，但它能记住你的库伯背景和原则
skaffold run --render-only