Как попасть в Hell из-за Helm, но ухватиться за соломинку

в 0:03, , рубрики: devops, helm, kubernetes, системное администрирование, юмор

Как попасть в Hell из-за Helm, но ухватиться за соломинку - 1 — Усталым хипстерам глаголим истину.

Все мы (то есть я) любим тянуть всё новое и блестящее в продакшн, чтобы, наконец-то, заменить одни проблемы другими. Нам (то есть мне) и посвящается эта история.

Чтобы понять и простить дальнейший текст вам понадобятся поверхностные знания как работать с Kubernetes на уровне пользователя и какие-нибудь слухи про Helm.

Давайте сначала абстрагируемся, а потом пусть кто-нибудь с этим разбирается. Представьте себе на минуточку, что мы — эдакий Колумб в мире смузи, электросамокатов и Kubernetes. Наш народ толпится в перенаселённой старушке Европе в одном из её мелких бесконечных государств, разворачивает деплойменты с кронджобами on daily basis под хруст квадрокоптеров. Но астрономы уже обнаружили объяснение подозрительному искривлению горизонта. И вот прям появляется ощущение, что мы — тот самый Чузен Ван современности. (А ведь не просил никто.) И где-то там, за полукруглым океаном — кратчайший путь в Индию! Бескрайние просторы, свобода от бремени рутины и много бесплатных ароматных специй. Нужно просто привести туда наших людей и, наконец, освободить их! Раздвигать океаны перед собой — это чересчур даже для такого великолепия как мы. Поэтому нужно строить корабли, паковать в них наши деплойменты, кронджобы и прочих демонов, поднимать сервисы вместо парусов и рулить прямо в светлое туда. Чтобы рулить нужен штурвал, то есть Helm. Он же — шлем. Шлем точно бы пригодился, знай мы наперёд что нас ждёт впереди. Но есть только штурвал. Строить корабли — дело непростое, поэтому нам как бы нужна помощь, но наш народ вечно занят чем-то очень бесполезным. Поэтому приходится как бы самому и как всегда. Потихоньку начинаем, строим маленькую лодочку, гребём в Индию, видим своими глазами бескрайние просторы, берём одну специю, плывём обратно, показываем людям. Людям нравится, они благословляют наши потуги. Затем готовим великий исход, приводим в порядок конфигурации, строим уже много кораблей. Люди подходят, интересуются. Показываем, рассказываем, просвещаем, обещаем, обещаем, обещаем… Чем больше кораблей — тем больше интерес. Кто-то присоединяется, помогает. Чтобы зря всё это не простаивало, плаваем в staging неподалёку, специй там ещё нет, жить там невозможно, но туристам нравится. И вот, спустя недели/месяцы/лучшие-годы/рукава он, ТОТ САМЫЙ ДЕНЬ, настал! Пора выпустить флотилию и покорить заветную terra incognita. С трепетом в душе плывём наш народ в Индию, а там, нутыпонел, Америка. И всё вроде очень похоже, но вот это предчувствие… Наши люди конечно сразу входят во вкус (ха-ха, им вообще всё-равно, на самом деле), начинают осваивать территорию, домики там, капуста, сервисы всякие разворачивают. Но то тут, то там что-то периодически пропадает, как сквозь землю. То этаж исчезнет, то кокос не родит. И мы такие бормочем с нарастающим гулом “погодите, постойте, я ещё не готов, дайте только день…”. А ещё так прищуриваемся внимательно, а там, впереди, за каждым кустом ВНЕЗАПНО проявляются индейцы с томагавками и смотрят так… недобро что ли… И холодок вот прям холодный пробегает по межушному ганглию. А народ такой: — «А чё это там? А этаж мой где?» А мы такие: — “Мой народ! Не то, чтобы я 40 лет вводил вас в заблуждение, да и назад никто, конечно, не погребёт, но вот прям срочно, *****, НАДО СТРОИТЬ ЧАСТОКОЛ!!!!!!” А они такие: — «А, ну понятно, как всегда опять».

Вот примерно так я себя почувствовал, когда перевёл энное количество сервисов в production с чистого Kubernetes на Helm, а потом напоролся на это.

Ну и в конце обещанная спасительная соломинка. Сначала лайт-версия, зато с объяснением вышесказанного бреда. Вот демонстрационный сценарий:

  1. Допустим, я разворачиваю chart для project:1.5. Впервые с Helm, а до этого был просто Kubernetes.
  2. Затем обнаруживаю, что в релизе есть бага, а в версии 1.4 её не было. И надо бы откатиться, но для неё и Helm чарта тоже не было. Поэтому решаю сделать по старинке: kubectl set image deployment/project project=registry.project.com/project:1.4 --record. Для этого и для пачки других сервисов, которые разворачивались вместе.
  3. Затем обнаруживается, что бага как бы не в этом сервисе, а в соседнем, а с этим всё хорошо и надо вернуть 1.5. Вот если вызвать helm upgrade --install, то ждёт большой сюрприз (больше деталей): image будет всё ещё от 1.4, а labels — от 1.5. И Helm показывает, что всё хорошо, там вообще-то 1.5 развёрнут и даже pods перезапущены были (CI-билд зелёный).

Как этого избежать? Если делается какое-либо изменение любого ресурса K8s, подконтрольного Helm, чистыми командами kubectl поверх развёрнутого Helm Chart, то отменять эти изменения нужно тоже командами kubectl. Helm может развернуть новый чарт. Но он сравнивает новый чарт с предыдущим, но не с актуальным состоянием ресурсов. И если вы отредактировали image, то будущая версия Chart, вероятно, будет содержать другой image и всё будет хорошо. Но вот если вы отредактировали переменную окружения, или аргументы запуска, или ещё что-то, то новая версия Chart скорее всего не отличается от предыдущей. И ваши ручные изменения останутся на месте после обновления.

А на закуску, тяжелая версия спасительной соломинки для тех, кто не может согласиться с подобной непредсказуемостью состояния.

Новые технологии — источник новых печалей.

Автор: Евгений Глотов

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js