Комментарии 30
А ваши кубер-кластеры тоже с СА на пять лет?
Вообще, уже на этапе "Архитектура" должна напрячься вся команда разработчиков, потому как куб - это явный запрет синглтонов и ещё пары вредных шаблонов проектирования, который появляется и потом "просто есть", и до тех пор, пока чей-то код полностью не примет как данность, что он будет в кубе и каждый сервис должен уметь внезапно падать, быстро вставать, работать годами, хранить данные в нигде (или, если должен их хранить, должен уметь синхронизировать состояние хранимых данных с соседями по 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 — не лучший вариант для продакшена, даже маленького.
Я бы сказал, что кубер нужен, если у вас действительно больше одной ноды в системе по любым причинам.
В базовом варианте он разворачивается просто и управляется тоже просто. Все что дальше - по желанию и потребностям.
Swarm целом хватает для десятка нод., если не нужно супер гибко раскладывать. Странно, что его избегают. По факту l1vestack это аналог swarm, если правильно понял
Странно обозвать 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, сети… и это просто стена! Понять базово — это одно, а настроить под себя — совсем другое. Нужны или огромный опыт, или куча времени, чтобы просто сидеть и ковыряться. Настроить выход наружу? Тоже целая история с кучей нюансов: часто просто копируешь решения, не до конца понимая.
Если позволите, немного добавлю коментариев и внесу небольшую ясность в некоторые вопросы?
Есть ноды управляющие (Control Plane). Раньше их звали Master, но сейчас это слово немодное, так что Control Plane. А есть ноды рабочие (Worker Nodes)
Control Plane и сейчас в некоторой литературе зовут master nodes (мастер нодами). А рабочие ноды раньше звались миньонами))
Рядом с Control Plane живёт etcd
Не совсем корректная формулировка. ETCD - это одна из основных частей мастер нод. Иногда можно встретить ироничное высказывание, что если убрать авторизацию и валидацию запросов, то вполне можно обойтись ETCD без Kube API server)).
В этой базе данных с довольно хорошо работающим механизмом консенсуса хранится ообще всё: от настроек всего кластера кубернетес до конфигураций и секретов непосредственно исполняемых приложений. При всей своей простоте, живучести, согласованности и быстродействии она обладает одним существенным недостатком, о котором некоторые не знают, а кто-то не вспоминает - максимальный размер этой базы составляет 8 ГБ. Поэтому когда хочется запихнуть всего и больше в виде конфигураций и секретов тем более на большом кластере, можно внезапно получить не всегда понятный сбой.
Для полной надёжности её ставят отдельно (речь про ETCD)
Это довольно редкий паттерн, когда пытаются разнести CP-часть (Consistent & Partition-tolerant) и AP-часть (eventual consistency) в случаях больших кластеров. Большинство же облачных провайдеров использует запуск запуск ETCD на одних машинах с остальными компанентами Control Plane.
Чтобы прописать нормальные условия для работы кластера, придётся вытащить наружу кучу метрик изнутри ваших приложений. Потому что более-менее доступные условия «из коробки» — это, например, «Если нагрузка на процессор больше 80 % 10 секунд подряд», а не «Если я записываю в базу данных быстрее чем за 0,1 секунды, и очередь — меньше 1 000 событий»
Довольно странный кейс. Приложение можно преспокойно запустить без указания в манифестах (чартах): limits/request, healthcheck, pod distribution budget, QoS, HPA/VPA. Например, nginx взлетает на самом минимальном конфиге без всяких условий. Наверное поэтому его часто используеют в качестве примера в официальной документации.
То есть вам надо будет продумать внешнюю сигнализацию своим приложениям, чтобы отдельные контейнеры могли сообщать внешнему миру о своём состоянии. Например, когда они перегружены, недогружены или что-то ещё.
Здесь хочется внести небольшую правку: не контейнеры, а поды, потому что они являются единственной и основной единицей работы в кластере кубернтес и в одном поде может быть много контейнеров.
Случай, когда кубернетес следит за загруженностью (перегружены, недогружены) обычно связан с темой горизонтального, реже вертикального масштабирования и обычно рассматривается отдельно по итогам нагрузочных тестов или хаос инжиниринга.
Вторая особенность — вам надо обеспечить правильное поведение приложения при добавлении-убавлении контейнеров
Повторная неточность/ошибка. Kubernetes не оперирует контейнерами, Kubernetes работает с подами. Если речь идёт о добавлении новых контейнеров в под, то это лишь часть описания манифеста, и там главное не запороть формат yaml-файла. В остальном процедура довольно простая.
Что касается правильного поведения приложения при его горизонтальном масштабировании, то это вообще никак не коррелирует со средой исполнения. Если приложение не заточено под Partition-tolerant, то ждать чудес, а потом поносить на чём свет стоит кубы, облака, девопсов/СРЕ, ну знаете - сами себе злобные буратины.
Если у вас планируется реально большой нагруженный кластер, то Control Plane и особенно etcd лучше выносить на отдельные выделенные ноды. Не надо на них вешать рабочую нагрузку, пусть они занимаются только управлением. У себя на деве или стейдже мы можем и совмещать, чтобы экономить ресурсы, но на проде лучше делить. В наших собственных продуктах на dev-части мы совмещаем узлы, а на прод-части создаём два отдельных контура.
Ну знаете, при том количестве ресурсов (особенно дисковых), которых требуется мастер-узлам, экономить, уже кажется проявлением скаредности. Даже такие продукты как Kind и K0s (кубы на максимальных минималках) предполагают, что у вас будет выделенный сервер (виртуалка) для мастер-ноды и отдельные рабочие ноды. Да, они поддерживают режим single-node, но его нужно дополнительно переопределять.
Сразу забудьте про использование локальных дисков на нодах для хранения важных данных в продакшене! Нода умерла — данные пропали.
Ну это рабочая нода должна очень быстро отдать концы. В случае правильной остановке ноды, все поды будут переселены на другие ноды. Согласен, не всегда и корректно это работает особенно у облачных (отечественных) провайдеров. А так в кубах довольно рабочие механизмы переселения подов на другие ноды со всеми данными на дисках.
Базовое решение Ceph — очень популярное, мощное и надёжное распределённое хранилище. Наш опыт показывает, что это отличный выбор. Его можно развернуть отдельно, а можно прямо внутри Кубера с помощью специального оператора Rook. Rook сам поднимает все компоненты Ceph (мониторы, OSD на дисках нод) в виде подов и делает его доступным для Кубера через CSI. Мы у себя часто используем именно связку Ceph + Rook.
Правильно понимаю, что это базовое решение лично у вас, а не во всей индустрии? Проводились ли оценки наработки на отказ такой схемы? Потому что по своей парадигме Kubernetes это история про высокую доступность (СА) и консистентность с непротиворичивостью (СР) не его конёк. Про консенсус голова болит только у ETCD.
Т. е. если надо обеспечить доступность сервиса, ожмдания перевыборов лидера или завершения транзакций проводиться не будут.
С другой стороны, Ceph использует механизм консенсуса Paxos только в сервисе Ceph Monitors для согласования карты кластера, когда согласуется информация о состоянии хранилищ и пульсов для всех узлов кластера. На этом всё.
Также не стоит забывать, что созданное хранилище для пода будет размазано по всему кластеру и когда таких приложений много (что нередко при нынешней моде всё тащить в кубы), возможен неплохой over head по использованию диского пространства (базы на несколько терабайт на раз-два закидывают).
Сеть в Кубере — это, пожалуй, одна из самых сложных тем. Вам точно понадобятся хотя бы базовые знания сетей (IP-адресация, маршрутизация, файрволы).
Отчего же? Сетевая модель Kubernetes основана на плоском адресном пространстве. Все поды в кластере способны видеть друг друга. Нет нужды в настройке NAT. В основе сетевого устройства Kubernetes лежит архитектурный принцип: «У каждого пода свой уникальный IP». Всё как раз очень просто.
В зависимости от выбранного CNI и вашей инфраструктуры вам может потребоваться разбираться с BGP, VXLAN, IPIP-туннелями, настройкой маршрутов и файрволов. Сеть — это то место, где можно застрять надолго.
В каком моменте вдруг может понадобиться разбираться с BGP, VXLAN, IPIP-туннелями? Установили понравившийся плагин на рабочие ноды, дальше организация сетевого взаимодействия целиком и полностью на плечах Kubernetes.
В Кубере есть специальная штука — Service. Это абстракция, которая даёт постоянный IP-адрес и DNS-имя для группы подов
Не совсем так. Это именованная точка входа для доступа к приложению в поде (группа подов совсем не обязательна). Позволяет обращаться по доменному имени к соответствующему поду в кластере. Постоянный IP-адрес уже дело десятое как и забота внутреннего или внешнего сервера имён о преобразовании доменного имени в IP-адрес.
Ingress — стандарт для публикации веб-приложений (HTTP/HTTPS) в продакшене
Ingress можно и даже нужно запускать, если это требуется на любом стенде, а не только на проде.
Работать с кластером Kubernetes без настроенной системы мониторинга и логирования — это посадить админом слепого котёнка.
В чём проблема? Сам кластер Kubernetes довольно живуч и неприхотлив. То что в нём могут устроить лютое мракобесие запущенные приложения, это отдельная история.
Родной Metrics Server ставится легко и работает незаметно в отличие от некоторых систем мониторинга и логирования. Всё остальное из разряда Observabilyties довольно легко и быстро ставится готовыми чартами или операторами - больше дело вкуса и личных предпочтений.
Кстати, тут надо передать пламенный привет некоторым российским облакам. У них часто есть довольно смешные лимиты на максимальное количество нод в одном Managed-кластере
Это довольно не самая большая боль для передачи приветов облакоделам. После AWS, GCP наши облака действительно как на Жигули пересел после хорощей иномарки.
Короткий анонс. Приложения должны быть готовыми жить в динамичной эфемерной среде Кубера. Почитайте про 12-factor app — это мастхэв
Вообще это должно быть первым шагом! Это должен быть первый эпат, после корректного завершения которого можно начинать обдумывать переезд в кубы. Но никак не наоборот (из неоднократного личного опыта).
В идеальном розовом мире единорогов ваши разработчики вообще не должны знать слова «Kubernetes». Они просто пишут код, коммитят в Git, а дальше некая «платформа» сама всё собирает, тестирует и выкатывает куда надо. Нажал кнопку — получил фичу в проде. Достичь такого уровня абстракции — это Грааль платформенного инжиниринга.
Типичная работа Devops-инженера. При настроенных CI и CD даже кнопку нажимать не надо. Само протестируется, просканируется, соберётся отправится куда надо (если требуется, дополнительно проверится), задеплоится на нужном стенде с необходимыми проверками, если что-то пойдёт не так или не туда, откатится обратно старую рабочую версию.
P. S. Не сочтите за трудность, вычитывайте, пожалуйста, внимательно текст после нейронок. Проявите уважение к читателям.
Даже не влезайте в Kubernetes без этого