Helm on Minikube: обновить локальный образ - PullRequest
Новая
       15

Helm on Minikube: обновить локальный образ

1 голос
/ 02 июня 2019

У меня есть Minikube (v1.1.0), работающий локально с инициализацией Helm (v2.13.1), и подключил демон локальной док-станции с Minikube, работающим eval $(minikube docker-env). В кодовой базе моего приложения я создал диаграмму с helm create chart. Первые несколько строк ./chart/values.yml я изменил на: 

image:
  repository: app-development
  tag: latest
  pullPolicy: Never

Я создаю образ локально и устанавливаю / обновляю диаграмму с помощью Helm: 

docker build . -t app-development
helm upgrade --install example ./chart

Теперь, это работает отлично с первого раза, но если я внесу изменения в приложение, я бы хотел запустить две вышеупомянутые команды для обновления образа. Есть ли способ заставить это работать?

Обойти

Чтобы получить ожидаемое поведение, я могу удалить график из Minikube и установить его снова: 

docker build . -t app-development
helm del --purge example
helm install example ./chart

1 Ответ

2 голосов
/ 02 июня 2019

Когда вы делаете такое изменение, Kubernetes ищет какое-то изменение в объекте Deployment.Если он видит, что вы хотите, чтобы 1 Pod выполнял app-development:latest, и у него уже есть 1 Pod, выполняющий изображение с именем app-development:latest, то он находится в правильном состоянии и ему ничего не нужно делать (даже если локальное изображение имеетэтот тег изменился).

Канонический совет: никогда не использовать тег :latest с Kubernetes.Каждый раз, когда вы строите изображение, используйте отдельный тег (отметка времени или текущий идентификатор подтверждения исходного кода - это простые уникальные вещи).С Helm достаточно просто внедрить это, основываясь на значении, которое вы передаете: 

image: app-development:{{ .Values.tag | default "latest" }}

Этот вид последовательности сборки будет выглядеть немного более как 

TAG=$(date +%Y%m%d-%H%m%S)
docker build -t "app-development:$TAG" .
helm upgrade --install --set "tag=$TAG"

Если вы активноРазрабатывая свой компонент, вы можете попытаться отделить «взлом кода» от «развертывания в Kubernetes» настолько, насколько это возможно.Некоторое количество этого, как правило, неизбежно, но Kubernetes действительно не предназначен для того, чтобы быть живой средой разработки.

...