dd

Локальное окружение в кубере с k3s

Написано

в

Когда я пришел в ферале на текущую работу, то все окружение разворачивалось в minikube.

Я уж не знаю какие именно проблемы с ним были (я их не заметил), но мой, на тот момент, тимлид принял решение переезжать на k3s, подсмотрев удачный опыт у одного из разрабов в компании.

Мне тогда было поручено локально поставить k3s и попробовать развернуть в нем пару сервисов, попутно обновив в них readme.

Собственно, с задачей я справился. Вот только выбранное решение было очень кривым, да еще и ломало dns при включенном корпоративном впне из-за того, что приходилось ставить dnsmasq. Зачем? На тот момент я думал, что общаться между сервисами очень надо через домены вида service-name.dev.loc (просто потому что по-другому я не знал как, а все примеры обращений из гугла не работали). И dnsmasq позволял это делать и оно даже работало в подах кубера. Но, как у любой задачи типа “было бы прикольно”, приоритет выполнения был минимальный и потому она быстро затерялась в недрах личного бэклога.

Прошло полгода, у меня честно говоря от кривости работы локального окружения уже порядком горела жопа. Более того, ко мне приходили разрабы и спрашивали — как вы локально разворачиваетесь? У вас то куча репозиториев с docker-compose’ами, то какой-то кубер, то еще что. И вот случился отпуск, а значит шанс снести к чертям собачим всю систему и начать с нуля.

В этот раз я решил вообще не использовать ничего, кроме самого k3s. И это помогло. Из коробки по прошлой инструкции у меня вообще не работал dns — из пода даже в гугл сходить нельзя было. Я начал копать и понял, что не использовал важную (в моем случае) опцию при установке k3s. А именно — --flannel-backend=wireguard-native . После указания опции все заработало. В гугл теперь можно было ходить, а самое главное — теперь поды могли общаться друг с другом просто через свои имена. Например, my-service-name.application.

Мне и в голову не приходило, что в кубере может быть удобный способ для общения между подами, как в docker compose, например (там можно обращаться к контейнеру по его имени внутри одной сети). Нет, я конечно видел и читал про CoreDNS, даже в конфиги какие-то лазил. Но почему-то в голове выключатель не щелкал.

После всего этого пришлось еще ставить сайдкар на базе нгинкса, чтобы поды могли обрабатывать запросы напрямую от других подов. Но там уже честно говоря не так интересно. Там просто мрак в виде go’шных шаблонов для helm.

Итого, я вроде как меньше стал бояться кубера. Теперь этот зверь кажется более-менее дружелюбным и начинает закрепляться реальное понимание того как там все работает.

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *