Как «kubectl применяется» проверяет изменение в образе docker?

#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, чтобы узнать, какое имя изображения они используют.