Комментарии 28
В этой всей теме меня удивляет популярный миф, что эти дистрибутивы "легковесные" в плане потребляемых ресурсов. Кругом видны подобные заявления, но когда начинаешь искать реальные пруфы, то все оказывается чуть ли не наоборот
http://ceur-ws.org/Vol-2839/paper11.pdf
https://www.talos-systems.com/blog/is-vanilla-kubernetes-really-too-heavy-for-the-raspberry-pi/
k3s и прочие ничем не легче ванильного кубера. По сути, вся "легковесность" этих дистрибутивов ограничивается исключительно деплоем и администрированием. Все таки один бинарь сильно проще. Если же задача поднять что-нибудь на edge или IoT и страшно за ресурсы, то выбирать можно любой дистриб.
И наверное это не удивительно. Все эти дистрибы хоть и один бинарь, но в них вкомпилена вся та же самая кодовая база. k3s нынче имеет внутри еще и встроенный etcd.
Полностью поддержу. Помню свой шок, когда обнаружил, что в ванильном кубере на пустом кластере kube-api-server ест 600 метров оперативки и ощутимо потребляет CPU, и как еще больше офигел, когда попробовал k3s (как раз начитавшись про его легковесность) и увидел что его апи сервер жрёт не меньше, а если смотреть суммарно, то потребление памяти было даже больше, чем всеми сервисами контрол плейна ванильного кубера.
Disclaimer! Я понимаю, что на проектах со сколь-либо ощутимой нагрузкой серваки испольщуются уже такие, что оверхед на кубер малозаметен, если только это не что то наоборот огромное с тысячами узлов. Просто какой-то период чесались руки попробовать кубер на паре слабеньких домашних серваков (селероны, 4 гига оперативки), в итоге получил незабываемый опыт, и не сказать, что прям негативный - знаний после этого сильно прибавилось.
локально можно попробовать kubelet masterless
https://github.com/kelseyhightower/standalone-kubelet-tutorial
Как супервизор и возможность туда подкладывать ямлики - топ
С точки зрения эксплуатации, это потребует квалификации от сотрудников. Несколько лет наблюдаю недостаточную квалификацию на рынке труда, целесообразнее закрыть этот недостаток с помощью увеличения вычислительных ресурсов и использования k3s. Со временем квалификацию персонал поднимет, но в настоящий момент необходимы компромиссы.
а потом k3s ломается... и его не починить, потому что он хоть и проще с точки зрения внешнего наблюдателя, но напрямую на него опыт Kubernetes vanilla не переносится...
И если уж на то пошло - есть еще интересное решение - https://github.com/gravitational/gravity
@zevssneg
Но ведь он уже всё :(
The Gravity project is no longer under active development. The project's development has been limited to maintenance and support for our commercial customers until maintenance agreements expire.
Благодаря нашим обсуждениям, мы сможем предоставить выбор людям. Попробовав разные инструменты и зная выжимку информации другие специалисты смогут принять лучшие решения. А это улучшит квалификации, что хорошо для всех.
Спасибо, какой-то период я думал об этом варианте, но в итоге поставил nomad + consul - потому что хотелось полноценного шедулера, который может джобы раскидывать по нодам.
А почему не Кубер? Он тоже по сути раскидывает поды/джобы по нодам? Суть-то одна. Единственное преимущество Номада будто в том, что в нем есть не только контейнеры, но и виртуалки, системди юниты и пр
Так я и хотел кубер изначально, но см. мой коммент выше про потребление ресурсов контрол плейном. Связка nomad + consul кушает гораздо меньше и памяти, и cpu (по крайней мере в home lab). Голый kubelet конечно еще экономичней, но это уже не шедулер
Хм. Интересное наблюдение, надо будет проверить.
Ну это наблюдение исключительно на совсем маленьких сервачках с маленькой нагрузкой, так что тут осторожнее. На чем-нибудь побольше ресурсоёмкость кубера будет уже малозаметной, и еще неизвестно что на самом деле будет лучше масштабироваться. Плюс тулинг и комьюнити в кубере на голову выше.
k3s
CNI по умолчанию - flannel
traefik - Ingress Controller
kind ещё хорош, когда надо потестить что-то в разных версиях куба.
И вдруг кому-то пригодится, есть скрипт для запуска kind с локальным регистри и ингрессом. Там ничего необычного, всё взято из документации, просто объединено в скрипт, работающий на ubuntu и mac.
Почему в таблице для k3s указано что это не vanilla k8s? Вроде как он из ванильного делается исключением при сборке модулей, которые потом можно добавить.
Именно потому, что по умолчанию часть модулей исключена.
Из README проекта:
Is this a fork?
No, it's a distribution. A fork implies continued divergence from the original. This is not K3s's goal or practice. K3s explicitly intends not to change any core Kubernetes functionality. We seek to remain as close to upstream Kubernetes as possible. However, we maintain a small set of patches (well under 1000 lines) important to K3s's use case and deployment model.
Одна из крутых фишек k3D заключается в возможности одновременного запуска нескольких Kubernetes кластеров на одной машине.
Это, например, позволяет прогонять несколько полноценных e2e тестов одновременно на одном ci/cd runner'е (например для нескольких PR/MR одновременно) и полностью уйти от использования для этого dind docker-compose и ваши тесты становятся ещё ближе к реальной инфраструктуре.
А у k3S есть опция --flannel-backend=wireguard
https://rancher.com/docs/k3s/latest/en/installation/network-options/#flannel-options
Хотелось бы добавить, раз уж упоминается Windows: обычно при наличии этой ОС и WSL2 устанавливается Docker Desktop. В таком случае можно запустить Kubernetes кластер прямо из GUI Docker Desktop: в настройках можно выбрать "Enable Kubernetes" и остается нажать "Apply & Restart". Вот ссылка фичи на оф сайте: https://www.docker.com/products/kubernetes
на Маке тоже есть Docker Desktop и там тоже есть Кубер внутри ) причем достаточно свежей версии
а какая версия запустится? полная официальна или одна из версий из статьи?
Насколько урезанная эта версия будет? какие ограничения?
ну щас запустил, показывает что поднялся 1.22.5 в гуи, но kubectl get nodes показывает что запущен 1.21.2
основные компоненты все есть: etcd, coredns, kube-proxy, apiserver, controller-manager, scheduler, storage-provisionier
ингреса только нет, но мне например так даже удобнее, потому что пользуемся traefik'ом
CNI по умолчанию в k3s traefik в табличке, тогда как в описании корректно
"В качестве CNI используется Flannel"
Kubernetes в миниатюре для локального запуска: k0s, MicroK8s, kind, k3s и Minikube