Миграция проекта из AWS на Bare Metal (часть 4)
ArgoCD
ArgoCD - это инструмент управления непрерывным развертыванием приложений, который позволяет автоматизировать процесс развертывания приложений в Kubernetes. Он может быть использован для управления приложениями на одной или нескольких кластерах Kubernetes и обеспечивает ресурсную автоматизацию, управление конфигурацией и версионность.
Одной из ключевых особенностей ArgoCD является то, что он работает на основе GitOps-подхода. Это означает, что все конфигурации и манифесты Kubernetes хранятся в репозитории Git, а ArgoCD использует этот репозиторий в качестве источника истины для развертывания приложений в Kubernetes. Это позволяет создавать версии приложений, управлять их состоянием и историей изменений, а также выполнять откаты в случае необходимости.
Другим преимуществом ArgoCD является его способность к автоматическому обнаружению изменений в репозитории и автоматическому развертыванию обновлений в Kubernetes. Это может значительно сократить время, затрачиваемое на ручное развертывание и обновление приложений, и обеспечить более быструю реакцию на изменения.
ArgoCD также поддерживает множество встроенных инструментов для управления приложениями, включая возможность создания мониторинга и журналирования, контроля доступа и управления ресурсами. Он также имеет поддержку множества платформ облачных вычислений и может быть использован с Kubernetes на практически любом провайдере облачных услуг.
В целом, ArgoCD - это мощный инструмент для управления непрерывным развертыванием приложений в Kubernetes, который позволяет ускорить процесс развертывания и обновления приложений, снизить вероятность ошибок и обеспечить более простое и удобное управление приложениями.
В старом кластере у нас тоже стоял ArgoCD и мы активно его использовали. Но вот манифесты пришлось переписать под новый кластер. Это упростило работу, не нужно было писать кучу патчей, чтоб приложения завелись на Bare Metal.
Деплой образов из реджистри AWS
Основной проблемой в этой части было то, что AWS меняет креденшалы для доступа к реджистри каждые 12 часов. В итоге мы не можем просто сохранить в секреты конфиг докера и наслаждаться жизнью. Жизнь - боль, организм должен страдать и вот это вот все, связанное с безопасностью...
Немного порывшись в интернете получаем такую схему:
- Создаем отдельного юзера в AWS с доступом к реджистри
- Сохраняем его ключи в секрете в кластере
- Ставим вот эту штуку
- Руками один раз создаем джобу, чтоб создался новый секрет с даннми доступа к реджистри
- Добавляем imagePullSecret в деплоймент приложения
- Деплоим само приложение
Эта утилитка раз в 6 часов (или как настроите) перезапрашивает логин и пароль у Амазона и сохраняет их в секрете. Этот секрет используется в деплойменте для скачивания образа при выкатке новых версий.
Все, счастье наступило и у нас все деплоится.
Доступ к приложениям из сети Интернет
Для отказоустойчивости доступа к приложениям мы заказали Floating IP у нашего хостера. Есть там своя специфика. Для того, чтоб он корректно работал, нужно указать на какой физической машине он поднят. Делать это можно руками, а можно через АПИ. Т.е. просто поднять в виртуалке этот IP не выйдет.
Как решить эту задачу?
Берем в руки старый и надежный как молоток Keepalived с реализацией VRRP протокола. Поднимаем это дело на всех хостовых машинах. В конфиге keepalived прописываем скрипт, который при переключении в мастер по API привяжет этот Floating IP к этой машине.
Дальше разворачиваем HAProxy на каждой хостовой машине, который просто проксирует чистые TCP соединения на IP MetalLB в кластер.
Как результат имеем переключение внешнего IP между машинами и отказоустойчивость.
Комментарии: