Комментарии 27
А ваши кубер-кластеры тоже с СА на пять лет?
Вообще, уже на этапе "Архитектура" должна напрячься вся команда разработчиков, потому как куб - это явный запрет синглтонов и ещё пары вредных шаблонов проектирования, который появляется и потом "просто есть", и до тех пор, пока чей-то код полностью не примет как данность, что он будет в кубе и каждый сервис должен уметь внезапно падать, быстро вставать, работать годами, хранить данные в нигде (или, если должен их хранить, должен уметь синхронизировать состояние хранимых данных с соседями по deployment) и ещё с десяток требований, вот тогда куб с этим ПО будет хорошим решением. Но на это всё нужно куда больше, чем х*впродакшн, а времени всегда отрицательное значение.
С другой стороны, кубернетес - это и отказоустойчивость, и масштабируемость практически "из коробки", а также много третьестороннего ПО, которое умеет (или "научили") работать в условиях куба, и которое можно хватать и использовать как готовые компоненты своего программного комплекса, что опять-таки позволяет сэкономить время разработчику. Если он может без каких-либо сложностей обратиться к условному redis, и знать, что он "не сломается", а если сломается, то пусть код падает, всё равно куб его поднимет потом, это сэкономит на этапе как прототипирования, так и релизной разработки приличное количество человекочасов. Вот и выходит, что в использовании или не-использовании куба есть баланс, который может смещаться в обе стороны в зависимости от бизнес-требований и внутренней архитектуры, а вот его учесть, тем более заранее - проблема в себе похлеще, чем описано в статье.
А ваши кубер-кластеры тоже с СА на пять лет?
Мы запускаем и грохаем свои кластеры так часто, что это не имеет значения)))
А всё о чем вы говорите просится как продолжение статьи, ведь в этой мы говорим как раз о моменте до. До того, как кластер запущен. И после этого момента начинается совсем другая жизнь.
Minikube - хорошая тема для "потыкать/попробовать через руки".
Неплохой обзор того, что должно получиться в итоге, когда сервис развивается в миллион пользователей, кластер в 100 нод, c high-availability и деплоями микросервисов каждый день.
Но это не всегда юзкейс. Если у приложения не планируется сразу куча клиентов, или это вообще какой-то пет-проект на одну ноду, то ИМХО стоит подумать, нужно ли в самом начале прикручивать GitOps, пять пайплайнов для CI и автоскелинг, если в ближайшие полгода там будет максимум 1 RPS и два девелопера c релизами раз в неделю. Но помнить о существовании этих разумеется вещей стоит, чтобы точно знать куда идти дальше.
Я когда решил использовать k8s, начал проектировать идельный кластер: c пайплайнами на Argo Workflow, GitOps, виртуальными кластерами для stage/prod. Не так давно кстати узнал про проект kubefirst, который заимплементил практически всё то что я хотел. Но на тот момент я осознал, что сложность инфраструктуры на порядок превышает сложность сервисов которые там будут крутиться, выкинул всё и с тех пор деплою ручным пушем в private registry и kubectl apply поскольку сервис так и не вырос во что-то большое. Поначалу сервис вообще был доступен только в приватной сети через ClusterIP service + externalIP, но когда мне понадобилось открыть его в интернет - пошёл и за день раскурил как поставить Ingress и генерацию сертификатов через Lets Encrypt.
Так что тезиз "Даже не влезайте" немножко ультимативен. Влезайте, имейте в виду как индустрия решает те или иные проблемы и разбиратесь с ними по мере необходимости :)
А по поводу, что почитать: если есть в целом понимание жизненного цикла облачных систем, но нет именно опыта работы с k8s, то рекомендую бесплатную Kubernetes Patterns. Минимум воды, чисто описания realworld проблемы - как она в кубере решается - плюсы/минусы решений.
Базовое решение Ceph — очень популярное, мощное и надёжное распределённое хранилище.
... В целом нет ничего хуже, чем развал кластера. В этой ситуации придётся долго и весело танцевать с бубном, если у вас не настроены итеративные бэкапы.
Ceph - это всегда танцы с бубном. Даже если настроены бэкапы
Норм статья. Когда автор понимает о чем пишет. Недавно тыкал Helm...ммм...кайф, создал ручками кастомный чартик и смотришь как подики разворачиваются. По моим ощущениям Ingress для чего-то маленького в категориях k8s, а вот Traefik такой мужичок.
Вообще прикольная статья, хотя она больше пугает в некоторых местах.
Кубер он же различается в зависимости от «зачем». Например если у вас свой проект и нет сотни отдельных пользователей кластера, то многое можно отложить на потом.
Создание кластера: Не упомянули RKE. Создает кластер из yaml конфига со списком год по сути. По мне так самый простой вариант из всех. Умеет обновлять и все такое.
Persistent Volumes: кидаться сразу в Ceph может быть излишне. Нет ничего плохого в локальных volume, как по мне. Нудно просто понимать что и зачем мы делаем. На Baremetal годы обычно не появляются/умирают пачками просто так.
Helm почему-то не упомянули. А весть это удобнее чем вручную apply файлов.
OpenShift тоже обошли стороной, хотя в каких-то местах он даже превосходит managed-сервисы.
Во всех историях про кубер «зачем» всегда выходит на первое место. И там, где нет нагрузки / отказоустойчивости / автомасштабирования / частого деплоя / команды разработчиков /CI-CD-пайплайна и т. д., явной потребности в кубере нет. Тогда можно докер на виртуалке или тот же L1veStack.
Мы всё же обсуждаем ситуации, когда она есть, но тогда ручками вместо AutoProvisioning — это прям тяжело. Локальные PV — не лучший вариант для продакшена, даже маленького.
Странно обозвать talos "экзотикой", а кубспрей на ансибле (тфу) "выбором". Попробуйте хотя бы первый.
Ну и вообще кубер после пары лет ковыряния - это как дышать. По другому уже очень странно. "Можно, на нафига, если можно нормально в кубернетес сделать".
С каких пор kubevirt, который является "решением для запуска виртуалок из кубера", и вы это указываете в том же предложении, превратился в CRI?
А Docker Swarm легко поднять же?
Легко поднять много чего, вопрос в том что дальше с этим делать.
Можно, но зачем? Кубер легко ставится - виртуалки с талосом (от одной до сколько нужно), потом запускаем talosctl с его конфигом - и вот у вас кластер кубера. Обновляемый как угодно потом. Есть еще Cozystack, боюсь там еще проще, но я не пробовал его совсем.
Наверняка можно взять готовый терраформ и раскатать кластер на Талосе например в herzner.
Kubespray, Flannel, Docker для рантайма. Все это было норм года три назад. Сейчас это всё антипаттерны уже. После kubespray будут проблемы с kubeadm, flannel не поддерживает сетевые политики, docker - этот комбайн для полноценной работы с контейнерами (build-push-pull-run) а вам только pull и run надо. Талос совсем не страшен и вместе с Омни - вполне подходит для начинающих. Также отбивает желание ковыряться руками в ОС, превращая ноды из pet в cattle.
Статья хорошая, видно что в теме разбираетесь. Но сайт ваш - это какой-то маркетинговый булшит непонятно для кого. У меня не возникло желания регистрироваться только чтобы посмотреть описание того, что вы делаете. Хотя, возможно, делаете годную вещь. Дружеский совет - расскажите на сайте подробнее для целевой аудитории - что там у вас :)
Раньше их звали Master, но сейчас это слово немодное, так что Control Plane
Дело не моде а в избежании путаницы.
Во-первых, когда человек слышит "master" он по умолчанию подразумевает, что он один.
Во-вторых, даже если использовать термины вроде мультимастер, они тоже не вмещают всю широту понятия Control plane, которое в облачном мире довольно глубоко укоренилось.
Иногда это даже не отдельные ноды, а слой управляющих сущностей, которые вполне могут соседствовать на одних нодах с компонентами data plane (компоненты, которые выполняют обработк и хранение "пользовательских" данных).
Ну и в больших Kubernetes кластерах разные компонеты control plane могут жить на отдельных друг от друга нодах. Что в данном случае будет "мастером"? API? Хранилище управляющих данных вроде etcd? Ноды, где живёт планировщик?
Эти правила хранятся в etcd, а Control Plane следит за их исполнением
Вот, собственно, и пример недопонимания. Etcd -- часть control plane
Потому что более-менее доступные условия «из коробки» — это, например, «Если нагрузка на процессор больше 80 % 10 секунд подряд», а не «Если я записываю в базу данных быстрее чем за 0,1 секунды, и очередь — меньше 1 000 событий».
Почему это должно быть "из коробки"? Есть множество экзотических сценариев масштабирования, в чём смысл их пихать в базовые дистрибутивы?
Если коротко, для сложных формул масштабирования можно использовать KEDA или external metrics + prometheus adapter + X_exporter
Если рядом нет опытного DevOps, который проведёт за ручку, то это просто взрыв мозга и боль
Но тут кроется корень непонимания назначения Kubernetes. Он затевался не как "готовая платформа с батарейками", а как "инструмент для создания платформ". И есть множество инструментов, которые предлагают "готовые платформы с батарейками" на основе Kubernetes вроде DeckHouse.
Kong Gateway. Да, у него есть красивый UI, что подкупает в мире консольного Кубера. Но он ломает саму идеологию Кубера с его декларативными манифестами в etcd
Чем он отличается в этом смысле от ArgoCD? Да, есть UI из коробки, но он точно так же конфигурируется привычными манифестами.
смешные лимиты на максимальное количество нод в одном Managed-кластере: где-то — 100 (привет, ТаймВеб), где-то — вообще 32 (Яндекс
Рекомендую прочитать, чем квоты отличаются от лимитов
https://yandex.cloud/ru/docs/managed-kubernetes/concepts/limits
Хотя зачем я это пишу? Суть статьи -- прорекламировать managed kubernetes в hello cloud. Мы поняли, что он есть и что лучше идти в managed kubernetes, чем пытаться админить самому, если нет явных противопоказаний.
Ну Etcd то можно развернуть вообще отдельно от кубера, и вообще без него и использовать как KV базу.
Можно. И что из этого следует? https://kubernetes.io/docs/concepts/architecture/
Статья сгенерирована нейронкой :(
Не люблю этот "развязный" стиль чатагпт, когда ему говоришь писать более живые тексты.
типа такого:
Начинаешь с Kubernetes — вроде всё понятно по верхам, курс прошёл, потыкал. Гугл и AI помогают. Но потом лезешь глубже: драйверы для хранилищ, autoprovisioning, сети… и это просто стена! Понять базово — это одно, а настроить под себя — совсем другое. Нужны или огромный опыт, или куча времени, чтобы просто сидеть и ковыряться. Настроить выход наружу? Тоже целая история с кучей нюансов: часто просто копируешь решения, не до конца понимая.
Даже не влезайте в Kubernetes без этого