Развертывание k8s - css из того же модуля - PullRequest
Новая
       14

Развертывание k8s - css из того же модуля

7 голосов
/ 04 июня 2019

У меня webapp работает в Kubernetes на 2-х модулях.

Я редактирую свое развертывание с новой версией образа, с webapp:v1 до webapp:v2.

Я рассчитываюпроблема во время развертывания ... 

podA is v2
podB is still v1

html is served from podA
with a <link> to styles.css

styles.css is served from podB
with v1 styles

=> html v2 + css v1 = ?

Как я могу гарантировать, что все последующие запросы будут обслуживаться с того же модуля или модуля с той же версией, что и HTML?

Ответы [ 4 ]

4 голосов
/ 10 июня 2019

Как я могу быть гарантированно, что все последующие запросы будут обслуживаться из того же модуля или модуля с той же версией, которую обслуживал html?

Даже если вы это сделаете, у вас все еще будут проблемы.Особенно, если ваше приложение представляет собой одностраничное приложение.Учтите это:

  • Пользователь заходит на ваш сайт, получает index.html v1
  • Вы выпускаете веб-приложение: v2.Через несколько минут все модули работают под управлением версии 2.
  • Пользователь по-прежнему имеет открытое веб-приложение с index.html v1
  • . Пользователь перемещается в приложении.Для этого нужно загрузить styles.css.Пользователь получает styles.css v2.Бум, ты смешиваешь версии, терпишь неудачу.

Я столкнулся с этой проблемой на производстве, и решить ее очень сложно.По моему опыту, лучшее решение:

  • Пометить все ресурсы (css, js, imgs и т. Д.) Суффиксом версии (например, styles.css -> styles-v1.css или хешемсодержимое файла styles-39cf1a0b.css).Многие инструменты, такие как webpack, gulp и т. Д., Могут сделать это автоматически.
  • index.html не помечен, но он ссылается на другие ресурсы с правильным тегом.
  • При развертывании не делайтеудалите ресурсы для старых версий, просто объедините их с новейшими.Убедитесь, что клиенты со старым index.html все еще могут успешно их получить.
  • Удаляйте старые ресурсы после нескольких версий или, что лучше, через некоторое время (может быть, через 1 неделю?).

При этом сценарий, описанный выше, теперь работает нормально!

  • Пользователь заходит на ваш сайт, получает index.html v1
  • Вы выпускаете webapp: v2.Это заменяет index.html, но оставляет все js / css на месте, добавляя новые с суффиксом новой версии.
  • У пользователя по-прежнему открыто веб-приложение с index.html v1
  • Пользователь перемещается в приложении.Это должно загрузить styles-v1.css, который загружается успешно и соответствует версии index.html.Нет смешивания версий = хорошо!
  • В следующий раз, когда пользователь перезагружает страницу, он получает index.html v2, что указывает на новый styles-v2.css и т. Д. Все еще нет смешивания версий!

Делать это с kubernetes немного сложно, вам нужно заставить свой процесс сборки изображений брать файлы из нескольких старых изображений и включать их в новый образ, что немного странно.

Другое решение -перестать обслуживать ваши html / css / js из модуля и вместо этого использовать его из хранилища больших двоичных объектов.(Amazon S3, Google Cloud Storage и т. Д.).Таким образом, развертывание просто копирует все файлы, которые объединяются со старыми файлами, давая вам желаемое поведение.

3 голосов
/ 11 июня 2019

Чувствуется, что ваши проблемы связаны с меткой и селекторами ... Это маловероятное поведение, которое вы описали (если только сам селектор не отвечает вашим потребностям).

Давайте возьмем в качестве примера этот поток (вход в этом объяснении одноразовый, просто чтобы изобразить доступ к приложению):

Ingress -> Service -> [endpoints] -> Pods

  1. Вход будет направлен к определенной службе;
  2. Служба имеет тип и селектор, который является правилом для генерации конечной точки на основе меток на ваших модулях, для которых вы хотите направить запросы;
  3. Конечная точка будет тогда представлять внутренний IP-адрес ваших модулей.

В пункте 2, я думаю, вы используете селектор для метки, которая существует в обеих версиях, например app: webapp, если вы просто добавите новую метку для ваших модулей, содержащую version, то вы можете изменить ваш сервис, чтобы выбрать только pods в указанной версии (version: v1 || version: v2), таким образом, вы больше не будете сообщать о несоответствии.

3 голосов
/ 05 июня 2019

Вот хорошая статья о стратегиях обновления развертывания, и вы можете рассмотреть возможность использования развертывания Blue / Green, а не Ramped.

Ramped - это медленное развертывание , которое после исправления развертывания с новым образом создаст новые репликационные наборы и, пока оно не достигнет нужного количества реплик, медленно завершит работу старых модулей репликатов, тогда это нормально, вы можетеживите с этой проблемой контроля версий, пока идёт обновление.

Синий / Зеленый , в отличие от ускоренной стратегии, Сервис для новой версии будет изменен, как только будет подтверждено, что новая версия исправна. Здесь вы можете найти пример развертывания для этой стратегии

Надеюсь, это поможет!

3 голосов
/ 05 июня 2019

Похоже, это не материал для обновления.Это не может быть решено самим kubernetes (при условии, что это самая чистая минимальная форма).

Тем не менее, если вы, например, используете входной контроллер nginx, вы можете посмотреть на https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#session-affinity, чтобы сохранить пользователя настолько же вверх по течению, сколько возможно.

...