Используйте Karpenter (разработанный командой AWS) вместо Cluster autoscaler и ваша жизнь особенно со spot instances станет значительно легче! Никаких node pools не нужно, никаких заморочек с availability zone specific EBS volumes, ноды ровно такие, как нужны под нагрузки, а не какие заданы в node pool и т.д.
Однако мой главный посыл был не только про AWS, а про любые облака в целом.
2019 и 2023 это огромная разница и опубликовав статью в 2023 нужно понимать, что деплоить k8s в AWS не Terraform/Terragrunt, а kops'ом - это дичь. Также касается Azure и GCP.
После нескольких попыток мы так и не смогли начать использовать эту функциональность kops: как оказалось, мигрировать существующие кластера на нее без простоя невозможно.
Потому что не нужно использовать kops :) Хотя он не делает ничего магического и мигрировать существующие кластера с kiam на "IAM roles for service accounts" вам вероятно не удалось всё же не по вине kops или просто не докрутили.
По-хорошему нужно просто написать Terraform/Terragrunt и воспользоваться import или создать новый EKS и мигрировать приложения в него.
Не нужно городить огород, в облаках с одним аккаунтом нужно использовать просто Terraform, с мультиаккаунтами Terragrunt, а не kops.
Цена managed k8s cluster'a на AWS - 0.1$ в час, итого за месяц использования выходит - 0.1$ * 730 часов = 73$, то есть 12 k8s кластеров стоят 876$ в месяц.
К чему эти подсчёты? Если ваш k8s не cloud provider managed, то вам вообще-то нужно 3 мастера и всякая обвязка, что не бесплатно. В итоге cloud managed k8s выйдет вам дешевле + не нужно обслуживать некоторые компоненты, а это время команды, т.е. $$$.
использование k8s это уже vendor agnostic
Зачем стремиться быть vendor agnostic, если AWS предоставляет невероятно крутую экосистему сервисов? Не используя всё это, вы просто ограничиваете себя и свою команду в возможностях и тратите кучу $$$ на оплату лишних часов команды.
в случае чего без проблем переехать с одного на другой, если возникает такая необходимость
В случае чего?
В случае необходимости резко сократить бюджет лучше изначально правильно планировать архитектуру именно с учётом специфики использования AWS , а не просто использовать всякие вещи вроде spot instances, Karpenter, keda & etc , хотя и это делают не все.
Или нужно начать оказывать услуги клиентам там, где нет AWS (таких мест, помимо России, в мире всё меньше)? Такое, конечно, бывает, но часто (не всегда) можно обойтись proxy / cdn и т.д.
В остальном, если у вас не какой-то серо чёрный бизнес и сам AWS вас не выгоняет, то смысла переезжать с него почти никогда нет.
За счёт максимальной простоты для новичков популяризировался как родительский проект Rancher, так и K3s. И я считаю, что это прекрасно, т.к. многие (к которым себя, кстати не отношу, т.к. прошёл всё the hard way) смогли пощупать кубер и создать что-то не имея возможности потратить на его освоение довольно значительное время.
Для тех, кто "подрос" можно уже и в GitHub заглянуть.
K3s вполне серьёзный и зрелый проект ( #1 кубер для iot уже несколько лет как) и с безопасностью у него всё хорошо.
K3s + Gitlab мне нравится больше, т.к. облачный Gitlab содержит в себе кучу всего вроде container registry, pip registry, git repository, variables storage & etc и в 99% его можно использовать бесплатно, он yaml based.
7) Закомитьте ваш код и если вы правильно написали .gitlab-ci.yml, то ваша сборка начнется в вашем gitlab-runner в вашем локальном K3s кластере, а в случае сборки докер образа, он будет загружен в приватный репозиторий контейнеров Gitlab.
P.S. Используя такой setup вы можете практиковаться в условиях максимально приближенным к боевым и никаких 127.0.0.1 :)
@artemiyokulov поделитесь как именно реализовали интеграцию Backstage + Gitlab? Выглядит достаточно интересно в т.ч. для реализации выкатки новых репозиториев из шаблонов для разработчиков.
Я достаточно внимательно прочёл вашу статью и мой комментарий выше остаётся в силе.
Цель всех этих заморочек с виртуалками - чтобы хотя бы формально ваш демо-стенд был приближен к реальности, в которой будут работать приложения.
Приложения работающие в кубере работают в контейнерах. Контейнеры обрели такую популярность в том числе потому, что они, упрощённо говоря, максимально приближенно работают и на локальной машине в докере и в Kubernetes в облаке. Ваш локальный демо стенд может отличаться от облака только количеством памяти (может и нет), скоростью дисков (может и нет) и т.п. и естественно отсутствием таких облачных ресурсов как elastic load balancer & etc.
Используя K3D вы можете поднять несколько master и worker нод в docker контейнерах и даже несколько кластеров одновременно и играться с их конфигурацией сколько угодно (да, даже с сетью), только с K3D вы можете себе позволить больше чем с виртуалка и значительно проще, т.к., в отличие от виртуалки, докер контейнер не тратит столько ресурсов системы для запуска полноценной ОС и настройка крайне проста.
Официальная документация рекомендует использовать для этого minikube. Canonical продвигает свой MicroK8s. Есть ещё k0s, k3s, kind — в общем, инструменты на любой вкус.
Все эти игрушечные кластеры подходят максимум для целей разработки или проверки концепций.
Игрушечные? Конечно же нет. Когда слышу, что K3s подходит только для локальной машины и не серьёзных задач, то сразу понимаю, что серьезного опыта работы у вас с ним нет.
Тут выход один — поднять нормальный кластер на виртуалках.
Виртуалки - это прекрасная возможность потратить кучу системных ресурсов на ОС каждой из виртуалок и в целом много лишних действий, но зачем это делать, если есть, например, K3D (не путать с K3s) где можно прекрасно запустить сколько хотите master'ов и worker'ов в docker контейнерах? Говорю про Linux, где для docker не нужна никакая виртуализация.
Можно даже поднять рядом в виртуалке, допустим, Gitlab CE, подцепить к нему ваш кластер и обкатывать CI/CD.
Для этого достаточно поставить Gitlab runner в ваш кластер Helm'ом и это 2 строчки кода и никаких виртуалок. Впрочем, если хотите поставить целый self hosted Gitlab, то это тот же helm install в тот же кубер.
В целом статьи на Хабре всё больше разочаровывают тем, что они про каких-то сферических коней в вакууме и совершенно не понятно в какие же такие ограничения дистрибутива того или иного кубера кто-то вообще упирается со своим hello world?
Перечитав свой коммент понял, что как-то он слишком в общем про виртуалки получился, а не про в контексте работы Vagrant + K8s :)
Повторюсь, что конечно на винде и маке докер под капотом использует виртуализацию, но Vagrant тут совершенно лишний, т.к. есть, например, docker desktop.
Для Karpenter+ EKS уже какое-то время существует нормальный сабмодуль в известном Terraform EKS модуле, рекомендую https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest/submodules/karpenter
Чтобы не деплоить node group для Karpenter рекомендую посмотреть на пример с Fargate. Отлично работает.
Используйте Karpenter (разработанный командой AWS) вместо Cluster autoscaler и ваша жизнь особенно со spot instances станет значительно легче! Никаких node pools не нужно, никаких заморочек с availability zone specific EBS volumes, ноды ровно такие, как нужны под нагрузки, а не какие заданы в node pool и т.д.
https://www.npmjs.com/package/@waylaidwanderer/chatgpt-api
2019 и 2023 это огромная разница и опубликовав статью в 2023 нужно понимать, что деплоить k8s в AWS не Terraform/Terragrunt, а kops'ом - это дичь. Также касается Azure и GCP.
Потому что не нужно использовать kops :) Хотя он не делает ничего магического и мигрировать существующие кластера с kiam на "IAM roles for service accounts" вам вероятно не удалось всё же не по вине kops или просто не докрутили.
По-хорошему нужно просто написать Terraform/Terragrunt и воспользоваться import или создать новый EKS и мигрировать приложения в него.
Плохой пример и регионов всё больше и больше
https://aws.amazon.com/blogs/aws/now-open-aws-region-in-the-united-arab-emirates-uae/
Но чаще всего необходимости иметь инфру именно в том регионе реально нет.
Технически AWS самоё надёжное облако, которое по уровню доступности лучше, чем любое, что может запилить любая другая команда.
Большинство software бизнеса никакого отношения к России не имеет.
Не нужно городить огород, в облаках с одним аккаунтом нужно использовать просто Terraform, с мультиаккаунтами Terragrunt, а не kops.
К чему эти подсчёты? Если ваш k8s не cloud provider managed, то вам вообще-то нужно 3 мастера и всякая обвязка, что не бесплатно. В итоге cloud managed k8s выйдет вам дешевле + не нужно обслуживать некоторые компоненты, а это время команды, т.е. $$$.
Зачем стремиться быть vendor agnostic, если AWS предоставляет невероятно крутую экосистему сервисов? Не используя всё это, вы просто ограничиваете себя и свою команду в возможностях и тратите кучу $$$ на оплату лишних часов команды.
В случае чего?
В случае необходимости резко сократить бюджет лучше изначально правильно планировать архитектуру именно с учётом специфики использования AWS , а не просто использовать всякие вещи вроде spot instances, Karpenter, keda & etc , хотя и это делают не все.
Или нужно начать оказывать услуги клиентам там, где нет AWS (таких мест, помимо России, в мире всё меньше)? Такое, конечно, бывает, но часто (не всегда) можно обойтись proxy / cdn и т.д.
В остальном, если у вас не какой-то серо чёрный бизнес и сам AWS вас не выгоняет, то смысла переезжать с него почти никогда нет.
-
Ой да не будьте вы таким занудой.
За счёт максимальной простоты для новичков популяризировался как родительский проект Rancher, так и K3s. И я считаю, что это прекрасно, т.к. многие (к которым себя, кстати не отношу, т.к. прошёл всё the hard way) смогли пощупать кубер и создать что-то не имея возможности потратить на его освоение довольно значительное время.
Для тех, кто "подрос" можно уже и в GitHub заглянуть.
K3s вполне серьёзный и зрелый проект ( #1 кубер для iot уже несколько лет как) и с безопасностью у него всё хорошо.
Заходим на https://k3s.io и видим :)
За 5 лет мог и на нормальный кубер переехать с мезоса :)
Спасибо! Хорошая статья.
Приятно удивлен функционалом Yandex Cloud.
K3s + Gitlab мне нравится больше, т.к. облачный Gitlab содержит в себе кучу всего вроде container registry, pip registry, git repository, variables storage & etc и в 99% его можно использовать бесплатно, он yaml based.
Для новичков:
1) Установить K3s:
curl -sfL https://get.k3s.io | sh -sleep 30k3s kubectl get nodesmkdir $HOME/.kubesudo cp /etc/rancher/k3s/k3s.yaml $HOME/.kube/configsudo chown $USER:$USER $HOME/.kube/configchmod 600 $HOME/.kube/config2) Установить Helm
https://helm.sh/docs/intro/install/
3) Зарегистрироваться в Gitlab https://gitlab.com, создать Group и скопировать Registration token из (замените название группы на свою)
https://gitlab.com/groups/your_group_name/-/runners
4) Использовать helm для установки Gitlab runner в ваш K3s:
helm repo add gitlab https://charts.gitlab.iohelm repo updatehelm fetch gitlab/gitlab-runner --version=0.42.0 --untarcd gitlab-runnerОтредактируйте
values.yaml:Раскомментируйте gitlabUrl и используйте значение
https://gitlab.com/https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/v0.42.0/values.yaml#L51
Раскомментируйте runnerRegistrationToken и вставьте значение токена скопированное в пункте 2)
https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/v0.42.0/values.yaml#L57
Сохраните и установите Gitlab runner (обратите внимание на точку, она необходима :)
helm -n gitlab upgrade -i gitlab-runner . --values=values.yaml --create-namespace5) Создайте Project (репозиторий) внутри ранее созданной Group.
6) Добавьте ваш код и файл
.gitlab-ci.ymlв котором настройте pipeline в соответствии с вашими требованиями.https://docs.gitlab.com/ce/ci/examples/#cicd-templates
https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates
7) Закомитьте ваш код и если вы правильно написали .gitlab-ci.yml, то ваша сборка начнется в вашем gitlab-runner в вашем локальном K3s кластере, а в случае сборки докер образа, он будет загружен в приватный репозиторий контейнеров Gitlab.
P.S. Используя такой setup вы можете практиковаться в условиях максимально приближенным к боевым и никаких 127.0.0.1 :)
Удачи!
Столько много букв вместо
https://k3s.io
Или мультикластер K3s в докере:
https://k3d.io
Если очень хочется разобраться, то https://github.com/kelseyhightower/kubernetes-the-hard-way
Для AWS (то, что реально используется в работе в проде): https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest
@artemiyokulov поделитесь как именно реализовали интеграцию Backstage + Gitlab? Выглядит достаточно интересно в т.ч. для реализации выкатки новых репозиториев из шаблонов для разработчиков.
Отличная работа!
Я достаточно внимательно прочёл вашу статью и мой комментарий выше остаётся в силе.
Приложения работающие в кубере работают в контейнерах. Контейнеры обрели такую популярность в том числе потому, что они, упрощённо говоря, максимально приближенно работают и на локальной машине в докере и в Kubernetes в облаке. Ваш локальный демо стенд может отличаться от облака только количеством памяти (может и нет), скоростью дисков (может и нет) и т.п. и естественно отсутствием таких облачных ресурсов как elastic load balancer & etc.
Используя K3D вы можете поднять несколько master и worker нод в docker контейнерах и даже несколько кластеров одновременно и играться с их конфигурацией сколько угодно (да, даже с сетью), только с K3D вы можете себе позволить больше чем с виртуалка и значительно проще, т.к., в отличие от виртуалки, докер контейнер не тратит столько ресурсов системы для запуска полноценной ОС и настройка крайне проста.
Игрушечные? Конечно же нет. Когда слышу, что K3s подходит только для локальной машины и не серьёзных задач, то сразу понимаю, что серьезного опыта работы у вас с ним нет.
Виртуалки - это прекрасная возможность потратить кучу системных ресурсов на ОС каждой из виртуалок и в целом много лишних действий, но зачем это делать, если есть, например, K3D (не путать с K3s) где можно прекрасно запустить сколько хотите master'ов и worker'ов в docker контейнерах? Говорю про Linux, где для docker не нужна никакая виртуализация.
Для этого достаточно поставить Gitlab runner в ваш кластер Helm'ом и это 2 строчки кода и никаких виртуалок. Впрочем, если хотите поставить целый self hosted Gitlab, то это тот же helm install в тот же кубер.
В целом статьи на Хабре всё больше разочаровывают тем, что они про каких-то сферических коней в вакууме и совершенно не понятно в какие же такие ограничения дистрибутива того или иного кубера кто-то вообще упирается со своим hello world?
https://habr.com/ru/post/599039/comments/#comment_23897073Да :)
Перечитав свой коммент понял, что как-то он слишком в общем про виртуалки получился, а не про в контексте работы Vagrant + K8s :)
Повторюсь, что конечно на винде и маке докер под капотом использует виртуализацию, но Vagrant тут совершенно лишний, т.к. есть, например, docker desktop.