#github #kubernetes #kubectl
Вопрос:
Мы выполняем текущие обновления для изменения образа docker.
Средство развертывания(жгут проводов) запускает kubectl apply
команду для каждого изменения образа docker.
Скользящие обновления по умолчанию, т. е. Нам не нужно указывать ниже strategy
в YAML:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1 # this will ensure zero downtime
Что касается изменения в образе docker, является ли имя образа docker тем, которое решает kubectl apply
выполнить скользящее обновление? Потому что изображение докера, которое у нас есть, помечено как image-name:latest
Комментарии:
1. помимо имени, есть еще и хэш.
2. @Лэйян, ты имеешь в виду,
image-name:{github-sha}
3. можете ли вы также вставить пример файла(например, yaml развертывания), который вы применяете?
4.
kubectl apply
не выполняет скользящие обновления: он просто обновляет объекты на сервере API. Затем различные контроллеры действуют соответственно. Если в манифесте ничего не изменилось — ничего не будет обновляться.5. @zerkms После
kubectl apply
того , как при смене образа докера будут отключены модули старой версии, не дожидаясь закрытия активных подключений(браузер к модулям)?
Ответ №1:
kubectl apply
(см. Документы) ищет изменения только в спецификациях ресурсов Kubernetes (YAML), а не внутри образов Docker. Итак, если вы измените изображение Docker и опубликуете его с тем же именем и тегом (т. Е. ваш ресурс Kubernetes YAML не изменится), то kubectl apply
в одиночку ничего не получится.
Автоматическое перераспределение ресурсов при изменении образа докера, вероятно, реализовано в качестве функции жгута поверх kubectl apply
.
Комментарии:
1. Вы хотите сказать, что модуль старой версии будет внезапно отключен, и будут запущены модули новой версии(с обновленным именем образа docker)?
2. Не внезапно, а в соответствии со стратегией скользящего обновления, определенной в вашем развертывании. Я предполагаю, что жгут внутренне обновляет имя образа докера при его изменении, а затем выполняет
kubectl apply
. Таким образом, применяется обычная логика обновления, определенная в вашем развертывании. Вы можете сделатьkubectl get pods -o yaml
это в блоках, управляемых Harness, чтобы узнать, какое имя изображения они используют.