После изучения документации skaffold и выполнения нескольких тестов мне наконец-то удалось найти хотя бы частичное решение вашей проблемы, возможно, не самое элегантное, но все же функциональное. Если я найду лучший способ, я отредактирую свой ответ.
Давайте начнем с начала:
Как мы можем прочитать здесь :
При взаимодействии с кластером Kubernetes, так же как и с любым другим нативным инструментом Kubernetes, Skaffold требует настройки действительного контекста Kubernetes. Выбранный kube-context определяет кластер Kubernetes, пользователя Kubernetes и пространство имен по умолчанию. По умолчанию Skaffold использует текущий контекст kube из вашего файла конфигурации kube.
Это довольно важный момент, так как мы фактически начинаем с kube-context и, основываясь на нем, мы можем вызвать определенные c профиль, никогда не опосите.
важно помнить : kube-context не активируется на основе profile, но верно обратное: спецификация c profile запускается в зависимости от текущего контекста (выбирается kubectl config use-context).
Хотя мы можем перезаписать настройки по умолчанию из нашего конфигурационного файла skaffold.yaml путем исправления ( сравнить связанный ответ ), это невозможно перезаписать current-context на основе устаревшего profile, например, вручную, как в вашей команде:
skaffold -p prod
Здесь вы вручную выбираете значение c profile. Таким образом, вы обходите автоматические c профили запуска . Как сказано в документации:
Активации в skaffold.yaml : Вы можете автоматически активировать профиль на основе
- kubecontext (может быть строка или регулярное выражение: префикс
! отменяет совпадение) - значение переменной среды
- команда skaffold (dev / run / build / deploy)
Допустим, мы хотим активировать наш профиль на основе текущего kube-context только для упрощения, однако мы можем объединить различные условия с помощью AND и OR, как в примере здесь .
решение
Я хочу убедиться, что при запуске skaffold -p prod skaffold не будет работать, если мой kubecontext будет указывать на кластер, отличный от моего производственного кластера.
I Я боюсь, что это не может быть сделано таким образом. Если вы уже вручную выбрали 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 специфицированного c фрагмента skaffold.yaml в нашем разделе profile и снова установив Dockerfile в его стандартное имя. Таким образом, каждая команда:
skaffold run
или
skaffold dev
будет успешной, только если для текущего kube-context установлено значение minikube. В противном случае он потерпит неудачу.
Мы можем проверить это с помощью:
skaffold run --render-only
, предварительно установив наш текущий kube-context на тот, который соответствует тому, что присутствует в разделе activation нашего profile определение.
Я обнаружил пару раз, что я случайно запускаю такие команды, как skaffold run -p local -n skeleton, когда мой текущий контекст kubernetes указывает на docker-desktop. Я бы хотел не допустить, чтобы я и другие члены моей команды совершили ту же ошибку.
Я понимаю вашу точку зрения, что было бы неплохо иметь какой-то встроенный механизм, который предотвращает переопределение этого автомата c активация профиля настроена в skaffold.yaml с помощью параметров командной строки, но, похоже, в настоящее время это невозможно. Если вы не укажете -p local, skaffold всегда выберет правильный профиль на основе текущего context. Ну, это похоже на хороший материал для запроса функции .