Comments 22
Статья не для начинающих. Начинается плавно и хорошо, но с раздела Deployment возникают вопросы "кто на ком стоял" и "как все-таки нарисовать сову". Слишком сжато? Бессвязная статья.
Статья норм, спасибо
До прочтения статьи, я думал, что что-то знаю о Kubernetes. Но оказалось, что это не так. На книгу из серии для чайников статья не подходит.
Спасибо за статью, но после прочтения появились вопросы. Все рассказывают про роли, процессы кубера, ноды итд, но никто не пишет про железо. Как правильно обеспечить хранение подов (схд / nfs/ сетевая фс) ? Фс должна быть shared или достаточно рейд массива на серверах? Какая скорость сети необходима для функционирования кластера? А если внутри пода бд? Как обеспечить её скалирование и консистентность данных?
Не подов, а их данных, и изначально все поды были эфемерные - хранилище выделялось на нодах без какой-либо персистентности. А потом какие-то умные головы начали пихать в куб СУБД, которые затребовали постоянное хранение, кубу пришлось городить PVC/PV инфраструктуру - и вы спрашиваете коркретно про неё, а она вообще говоря кубо-независимая, и под её капотом может сидеть и NFS, и локальные рейды, и какой-нибудь Ceph, и ХЗ что ещё, вплоть до физического NAS'a, который научили выделять пространство мелкими кусочками по запросу. Остальные ваши запросы уже третий уровень, из-за этого и порождаемой сложности управления (а куб непрозрачно работает с statefulset'ами БД) я лично предпочитаю держать БД вне куба.
Для разработчика кубернетес - это API, предоставляющий интерфейс доступа для развертывания разрабатываемого контейнерного приложения в некоем облаке.
Для системного администратора кубернетес - это оркестратор контейнерной инфраструктуры.
Для архитектора кубернетес - это фреймворк для построения микросервисной архитектуры распределенного приложения.
Если располагать сервисы на одном сервере, не будет отказоустойчивости. Падает один сервер и падает все приложение.
А далее
Следующая задача — распределить нагрузку. Для этого используем балансировщик.
Стоп... Балансировщик - ОДИН. Посему первая цитата относится к нему в полный рост - падает сервер с балансировщиком, и падает всё приложение. Ну и где профит?
Есть мастер-нода (master node) — центр управления, мозг Kubernetes. Он управляет всем остальным.
И снова - одна точка. Падает сервер... и далее по тексту. Гм...
А, нет, дальше есть ещё
Чтобы быть отказоустойчивым, Kubernetes использует три мастер-ноды.
Отлично... Три ноды, и вероятно, на трёх разных серверах (иначе зачем вообще нафига козе баян). Так ведь, ну правда же?
Но тогда снова возникает вопрос - а где у нас балансировщик для этих трёх нод?
---------------
В общем, как-то вопрос балансирования и надёжности совершенно не раскрыт...
Отказоустойчивость это глубокая тема
Если говорить про балансировщики в отрыве от куба, по старинке, на виртуалках, то есть как минимум два "дешёвых" способа (не идентичны, можно совмещать, есть плюсы/минусы, особенности и прочие нюансы, я только про возможные способы):
Сервер "на подхвате" (virtual IP, floating IP): имеется балансировщик и полная его копия. На них устанавливается сервис keepalived, выбирается VIP (Virtual IP), выбираются приоритеты серверов для роли мастер-бэкап. В dns заносится A-запись, указывающая на этот VIP. keepalived вместе со своим соседом решают, у кого какая роль и мастер устанавливает VIP на свой сетевой интерфейс. В случае выхода сервера из строя, бэкап-сервер заметив это, становится мастером и вешает VIP на себя. Дальше чуть-чуть сетевой магии (arp) и пакеты начинают идти к работающему серверу. Когда первый сервер вернётся, сервисы keepalived снова договорятся, кто есть кто, и адрес будет оставлен на новоизбранном мастере
"Балансировка" при помощи dns: в зоне делаются две или больше A-записи с одинаковым именем, каждая содержит IP адрес балансировщика. Клиенты при подключении будут резолвить адрес из этого имени и могут получить случайный адрес из списка. Если вдруг балансировщик по этому адресу не доступен, то (в зависимости от поведения клиента) клиент может выбрать следующий адрес/попытаться отрезовлить имя снова и так попадет на доступный балансировщик. Пример:
nslookup ya.ru
Есть вариант с (i)bgp, он же применим и к кубам.
Кто-то может поделиться ещё работающими вариантами?)
Вы правильно сформулировали в самом начале основную проблему отказоустойчивости - одна точка входа. Именно в этом и есть проблема, остальное - следствия. Но дальше вы пытаетесь сказать, что Kubernetes каким-то мистическим способом более надёжен, хотя одна точка входа ну никуда не делась. Дополнительной информации, в каком месте и за счёт чего именно, нет - и утверждение о бОльшей надёжности повисло в воздухе.
KeepAlive и RoundRobin - это для Kubernetes балансировщики, как я понимаю, ну совсем внешние (уж второй-то точно). И RoundRobin тут выглядит куда как предпочтительнее, потому что он на самом деле устраняет проблему единой точки входа. Правда, тут обязательно нужна поддержка на стороне клиента, чтобы, обнаружив, что нода не отвечает, он инициативно шёл на альтернативный адрес, а не выкидывал тупое "сайт недоступен" (увы, на операционную систему в этом вопросе надежды нет ну вообще никакой). И (тут уже совместно с сервером) умел определить момент разрыва и восстановить сессию, не начиная всё с самого начала.
Про одну точку входа формулировал не я.
Кубы, в рамках статьи, да и в целом, в своей базе, предлагают отказоустойчивость и масштабирование приложения, резервирование своих жизненно необходимых компонентов, но они не обеспечивают защиту от всего: это не волшебная пилюля (хотя некоторые и пытаются подать его именно так). Это лишь часть инфраструктуры. А есть ещё сервера, сети, электричество - все это требует своего подхода.
Вопрос от "чайника": что такое K8s и как оно соотносится с Kubernetes? Как-то неожиданно оно появляется в тексте..
На ютубе эти картинки давно видел. Кто у кого плагиатил?
О божественный кубер на волшебных технологиях. И вот прям тошнит от примеров на всяких магазинах и платежном говне.
Кубер появился из-за того, что в Гугле желали утилизацией ресурсов управлять гибко, и днём крутить SeRP, а ночью отчёты на том же железе; а не из-за того, что никто отказоустойчивость не смог приготовить.
>>На каждом сервере, на каждой ноде есть программа. Она называется kube-proxy. Именно она принимает запрос от условного Nginx. И уже он балансирует нагрузку и понимает, в какой под нужно отправить запрос.
Всегда думал, что kube-proxy отвечает за реализацию абстракции service и нарезает правила iptables под это дело. И ни в коем случае не принимает никакой трафик. А вот за реализацию overlay-сети между подами отвечает CNI (который опять же сам непосредственно трафик не принимает)
>>Еще один нюанс, на каждой ноде есть еще один процесс — kubelet. Он отвечает за то, чтобы было развернуто ровно столько подов, сколько попросили, определенное количество реплик приложения.
Тут тоже есть небольшой вопрос. Технически kubelet выкачивает себе манифест пода, в который шедулер прописал его имя. Поднимает его и тыкает кочергой на предмет того жив он или нет. При этом он не знает, что творится на соседней ноде и про количество реплик подов в кластере. Согласно доков как раз-таки kube-controller-manager следил за количеством реплик и нарезает манифесты подов в нужном количестве.
Если я выучу всё, что написано в статье, то я буду получать 300к в секунду деняг?
Kubernetes на пальцах: самое простое объяснение, что это такое