Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>15 июн 2022</li>

3 <li>0</li>

4 </ul>Сертифицированный системный администратор рассказывает, из каких компонентов состоит Kubernetes и как стать специалистом по этой технологии.

5 Иллюстрация: Катя Павловская для Skillbox Media

6 Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес. Сайт:<a>darovska.com</a>.

7 Kubernetes - это оркестратор для контейнеров, написанный на языке Go в Google. Раньше уже существовали решения для создания и развёртывания виртуальных машин - такие как Microsoft Hyper-V или продукты от VMware.

8 Для контейнеров был тот же Docker - он позволял администрировать по несколько контейнеров одновременно. Однако для развёртывания больших многокомпонентных продуктов для сервисов и приложений, использующих контейнеры в своей архитектуре, технологий не было.

9 Поэтому появился Kubernetes: он позволяет автоматизировать развёртывание целых кластеров с контейнерами, гибко задавать различные политики и настройки и пользоваться подходом Infrastructure as Code.

10 При этом Kubernetes позволяет распределять ресурсы серверов более эффективно благодаря лёгкости контейнеров. Виртуальные машины, каждая из которых запускает отдельную копию операционной системы, работают очень медленно и потребляют кучу ресурсов. А Kubernetes может крутить контейнеры на одном сервере, не требуя для каждого из них отдельной ОС.

11 <ul><li><a>Зачем нужен Kubernetes</a></li>

12 <li><a>Как появился Kubernetes</a></li>

13 <li><a>Принцип работы Kubernetes</a></li>

14 <li><a>Как стать специалистом по Kubernetes</a></li>

15 <li><a>Какие вопросы задают на собеседовании</a></li>

16 </ul><ul><li><a>Риски использования Kubernetes и облачной инфраструктуры</a></li>

17 <li><a>Отличия между решениями разных облачных провайдеров</a></li>

18 <li><a>Недостатки Kubernetes</a></li>

19 <li><a>Альтернативы Kubernetes</a></li>

20 </ul>С Kubernetes работают преимущественно SRE-инженеры и те, кто занимается<a>DevOps</a>-эффективностью разработчиков, пакетированием приложений. Например, разработчики написали код, собрали бинарник программы. После этого кто-то должен подготовить образы, в которые поместят приложение, и создать пайплайн.

21 А теперь представьте, что у нашего приложения довольно много пользователей и ему требуются серьёзные ресурсы. Понятно, что мы не будем собирать под него суперкомпьютер - современная IT-индустрия выбрала путь распределённых систем, когда какое-то количество относительно слабых серверов собираются в единую распределённую систему и дают необходимые мощность, быстродействие и ресурсы. Это удобно: их количество можно наращивать постепенно, масштабируя ресурсы под требования приложения, а отдельные серверы можно легко заменять, если они вдруг выйдут из строя.

22 Итак, у нас есть приложение, которое должно крутиться на распределённой системе из десятков или даже сотен серверов. Если мы возьмём Docker или любой другой инструмент для работы с контейнером внутри системы, то каждый сервер придётся настраивать и администрировать отдельно: мы не сможем применить единые конфигурации сразу для всей группы - это будет полуручной труд. И даже если мы напишем набор скриптов для автоматизации, они не станут универсальным решением - в любом другом кейсе придётся писать их снова.

23 Тут на помощь и приходит Kubernetes. Мы просто описываем необходимые характеристики инфраструктуры (ресурсы для приложения, дизайн сети и так далее), а Kubernetes выполняет указания и управляет серверами, которые к нему подключены. Так он экономит время администраторам и разработчикам.

24 В книге<a>Site Reliability Engineering</a>описан внутренний проект Google - система управления кластерами Borg. В 2014 году Google опубликовал исходные коды этого проекта, а уже в 2015 году в партнёрстве с Linux Foundation организовал фонд<a>Cloud Native Computing Foundation (CNCF)</a>, которому и передал сорцы Kubernetes в качестве своего технического вклада. Этот фонд развивает open-source-проекты по разработке утилит и библиотек, которые позволяют создавать приложения ориентированные на облачные модели архитектур.

25 Сейчас Kubernetes - alumni, или по-русски "выпускник", Cloud Native Computing Foundation. Его довели до стабильной версии, и он получил статус Graduated Project (завершённый проект) в терминологии CNCF.

26 Первые версии Kubernetes были более монолитными и заточенными под работу с Docker в фоне. В программе CNCF Kubernetes стал стабильным и расширяемым продуктом, и менять технологии стало возможно практически на каждом уровне виртуальной инфраструктуры. Сейчас Kubernetes поддаётся достаточно высокой кастомизации: любую технологию работы с контейнерами, работы с хранилищами или работы с сетью можно выбрать самому.

27 Такой подход к развитию сделал Kubernetes популярным решением для продакшен-систем и корпораций, у него появилось больше компонентов, связанных с безопасностью, и более стабильные алгоритмы управления ресурсами и процессами.

28 Kubernetes состоит из двух больших частей (см. изображение ниже):

29 <ul><li>Control Plane - оркестратор, API и база конфигурации.</li>

30 <li>Node Pools - серверы с доступными ресурсами.</li>

31 </ul>За Control Plane отвечает сервер Kubernetes Master Node. Kubernetes Worker Nodes группируются в Node Pool (пул узлов, нод). Как правило, один Node Pool соответствует группе серверов с одинаковыми заданными характеристиками. Например, пул серверов на базе Windows, пул серверов с Linux и пул серверов с GPU.

32 Изображение:<a>Wikimedia Commons</a>На каждой ноде (или узле, отдельном физическом сервере или виртуальной машине) устанавливается агент kubelet - он помогает получать инструкции от сервера Master Node, а также различные компоненты, драйверы и расширения для мониторинга безопасности сети. Всё это складывается в платформу для развёртывания приложения.

33 Итого: само приложение описывается через deployment-ресурс, который содержит несколько pod (далее - поды), в каждом из которых находится от одного до нескольких контейнеров. Поды как раз и являются единицами масштабирования системы в Kubernetes - своеобразными молекулами, из которых состоит система. Например, когда выбирают, на какой ноде будет запущен тот или иной компонент приложения, минимальной областью ресурсов считается именно под, а не отдельный контейнер или физический сервер.

34 Иерархия компонентов Kubernetes.Node Pool состоит из нод (Worker Node). Application состоит из Deployment, который в свою очередь состоит из подов, в которых содержатся контейнеры.

35 Принцип работы Kubernetes аналогичен классическим кластерам. Мозг системы - Kubernetes Master Node, который отвечает за Control Plane и содержит:

36 <ul><li>API для администраторов и разработчиков;</li>

37 <li>базу конфигурации с параметрами контейнеров, приложений, деплоймента, сети, хранилищ;</li>

38 <li>оркестратор или планировщик, которые запускают контейнеры.</li>

39 </ul>Напомню, что Kubernetes объединяет пулы из нод - то есть серверов, объединённых общими характеристиками. Например, пул из Windows-северов, пул из Linux-серверов, пул из серверов, на которых есть GPU. Ноды объединяются в пулы по определённым характеристикам. Потом администратор сообщает Kubernetes, что это за характеристики: вычислительная мощность, память, хранилище - а Kubernetes самостоятельно распределяет ресурсы, находит в кластере ноды, которые удовлетворяют этим характеристикам, и запускает поды приложения на них.

40 Можно установить минимальное и максимальное количество подов для приложения, и Kubernetes будет стараться поддерживать это их количество. А вот за поддержание и масштабирование количества нод (то есть отдельных физических серверов или виртуальных машин в составе поды) уже могут отвечать администратор, гипервизор или облачная платформа по типу Azure, GCP, AWS - но не сам Kubernetes.

41 А если какой-то из элементов инфраструктуры даёт сбой, Kubernetes автоматически пытается решить проблему: например, перезапустить одну поду или deployment, чтобы состояние системы в целом соответствовало конфигурациям, загруженным через API и сохранённым в Master Node. В результате приложение, компоненты которого поделены на поды и контейнеры, крутятся в пространстве ресурсов, объединённых в кластер Kubernetes - в своеобразное облако-контейнер.

42 Работать администратором Kubernetes достаточно сложно, потому что нужно хорошо ориентироваться в компонентах и всех аспектах ресурсов Kubernetes. Я представляю это для себя как облако в облаке. Возьмём в качестве примера облачные сервисы IaaS (Infrastructure as a Service) - в них всегда есть несколько слоёв: хранилище, сеть, вычислительные ресурсы и виртуализация. И нам нужно знать весь этот стек, чтобы дойти до возможности установки и настройки Kubernetes.

43 Но все те же слои будут отображаться ещё и внутри самого Kubernetes: там есть свои особенности организации виртуального хранилища, виртуальной сети и виртуальных вычислительных ресурсов. То есть у нас будет одновременно два стека: стек дата-центра или IaaS-облака + стек Kubernetes.

44 В результате всё, кроме "физической" сети и общих концепций, администратору придётся учить с нуля. Под общими концепциями я подразумеваю следующее:

45 <ul><li>что такое сеть,</li>

46 <li>как работать с распределёнными хранилищами,</li>

47 <li>как работать с распределёнными вычислительными ресурсами.</li>

48 </ul>Правда, с использованием этих концепций в реальной ежедневной работе с внутренними компонентами Kubernetes тоже придётся разбираться с нуля - что настраивать, чем пользоваться и так далее.

49 Я кручусь в мире больших компаний, где обращают особое внимание на сертификаты. И все сертификации по Kubernetes - практического характера. Чтобы их пройти, нужно не просто выбрать верные варианты ответов и расставить галочки - придётся написать конфигурации и команды за ограниченный отрезок времени прямо в командной строке. Например, за полтора часа создать 25 конфигураций - а это невозможно закончить вовремя, если не разбираешься в теме.

50 Поэтому всем, кто хочет стать специалистом по Kubernetes, я советую готовиться и проходить сертификации. Ничего сложнее заданий для сертификации у вас на собеседовании не спросят. Справитесь с сертификацией - сможете ответить и на вопросы интервью.

51 У меня уже есть сертификаты<a>Certified Kubernetes Administrator (CKA)</a>и<a>Certified Kubernetes Security Specialist (CKS)</a>, кроме того, существует<a>Certified Kubernetes Application Developer (CKAD)</a>. Это официальные программы от Linux Foundation. На то, чтобы получить сертификаты, мне понадобилось полгода - даже с учётом того, что я работаю с инфраструктурой уже более шести лет.

52 Для подготовки к CKS я проходил курс<a>Killer Shell Support Team</a>на Udemy. Также у меня есть подписка на Pluralsight, где тоже есть курсы, связанные с CKA, например<a>Certified Kubernetes Administrator (CKA)</a>. Есть и подготовительные<a>тренинги</a>от самой Linux Foundation. Правда, они состоят из текста и схем, поэтому мне показались очень скучными, а вот их офлайн-тренинги - очень интересные и живые. На них инструктор показывает всё необходимое буквально за несколько дней и отвечает на вопросы слушателей. А чтобы лучше разобраться в безопасности Kubernetes, рекомендую посмотреть<a>CIS Kubernetes Benchmarks</a>.

53 Ещё у меня лежат две книги издательства O’Reilly:

54 <ul><li><a>Site Reliability Engineering</a></li>

55 <li><a>Cloud Native DevOps with Kubernetes</a></li>

56 </ul>На YouTube тоже много полезного - особенно каналы амбассадоров Kubernetes (их <a>полный список</a>есть на сайте CNCF): они разбирают кейсы, показывают команды, предлагают делать домашние лаборатории - например, поднять микро-Kubernetes на Raspberry Pi. Я рекомендую посмотреть видео с <a>YouTube-канала</a>DevOps-консультанта<a>Nana Janashia</a>.

57 Если у вас уже есть сертификаты, то сложность на собеседовании может возникнуть разве что с System Design Interview: каким должно быть приложение, паттерны, Service Mesh, микросервисы (рекомендую<a>отличную презентацию</a>от Netflix). Но эти вопросы относятся уже к проектированию распределённых приложений, а не к самому Kubernetes.

58 Также компании могут задавать вопросы, связанные со спецификой конкретного провайдера, на котором будет крутиться Kubernetes. Например, в случае<a>Azure</a>, на котором я специализируюсь, помимо Kubernetes есть и своя экосистема - тот же<a>Application Gateway</a>от Microsoft (вот, например,<a>описание кейса</a>по работе с Azure Kubernetes Service).

59 То есть это специфичные вопросы о том, как Kubernetes будет существовать в конкретном контексте: каком-то дата-центре или облаке. И тут важно становится всё: драйверы, типы хранилищ, которые есть у облачных провайдеров, и как они интегрируются с Kubernetes. Конечно, таких вопросов в сертификации нет, да и нужны они далеко не всем. Рядовому DevOps-инженеру, который будет просто деплоить приложения, это ни к чему. Здорово, если администратор будет это знать, но даже если нет, в команде обычно есть специалист по конкретному облаку, который всегда поможет.

60 Работая с Kubernetes все стараются придерживаться стандартов, поэтому все кейсы в своей основе похожи, а нетипичные кейсы встречаются крайне редко. Более того, в той же Европе Kubernetes ещё очень редкое решение: компании там довольно консервативны и чаще выбирают решения на базе виртуальных машин - потому, что у них больше специалистов, которые умеют с ними работать. Те, кто выбирает Kubernetes в Европе, уже рискуют - то есть сам этот выбор является нетипичным сценарием.

61 Самый частый кейс использования Kubernetes во Франции - попытка вырваться из тисков привязки к конкретному вендору (vendor lock).

62 Достоинство любых облачных сервисов - Platform as a service, то есть приложение можно сразу же развернуть и заниматься более высоким уровнем абстракции, не думая о реализации уровня middleware, наподобие LAMP-stack (Linux/Apache/MySQL/PHP). Но если мы хотим, чтобы наше приложение могло одинаково работать на разных облачных платформах, решением может быть Kubernetes и запаковка приложения в контейнеры. Однако когда наше приложение привязывается к особенностям того или иного PaaS, переход от одного облачного провайдера к другому с технической точки зрения усложняется.

63 Хотя и при выборе Platform as a Service есть определённый риск стать Vendor locked - ведь существует не так много облачных решений. По сути, мы выбираем между Microsoft, Amazon, Alibaba или "Яндексом". А ведь делать темплейты приходится под конкретную конфигурацию конкретного облачного провайдера.

64 Именно поэтому сейчас многие компании боятся, что из-за санкций их облачный провайдер перестанет работать в тех странах, где они ведут свой бизнес, а значит, их веб-приложения станут там недоступны и оперативно перенести приложения на другой сервис не выйдет: все скрипты, весь код - всё заточено под конкретного облачного провайдера.

65 А в случае не с IT-бизнесом мы имеем ещё одну проблему: для таких компаний IT-инфраструктура не является основной, профильной деятельностью (то, что называется Core Business) - они рассматривают её лишь как внутренний сервис для удовлетворения потребностей бизнеса, а значит, команда IT-специалистов у них будет маленькой и поддерживать режим Multicloud будет практически нереально.

66 Типичный кейс Multicloud - когда покупают сервера Azure и Amazon и разворачивают Kubernetes-кластер на каждом из них. Один из облачных провайдеров становится главным, а второй используют для бэкапа и на случай, если что-то произойдёт с первым. Приложение контейнизируют и делают конфигурацию под Kubernetes, а компания может переходить из одного облака на другое без дополнительных инвестиций (кроме затрат на постоянную поддержку этого режима и стартовую конфигурацию под два облака).

67 Это существенно снижает риски - да и дешевле решений на виртуальных машинах. Но перевести бизнес с виртуальных машин на Kubernetes тоже непросто - это означает полную смену технологии. Во Франции с этим сложно, потому что придётся пересобирать IT-команду или переучивать уже нанятых сотрудников. С точки зрения бизнеса это достаточно сложный организационный процесс, который займёт не меньше трёх-шести месяцев.

68 Альтернативный вариант - наём специалистов на аутстаффе, но это должна быть стабильная сертифицированная компания, потому что Kubernetes - относительно новая технология для мира больших корпораций и очень непросто найти хорошую внешнюю команду.

69 У каждого Kubernetes-провайдера есть свои особенности работы с сетью, хранилищем, вычислительными ресурсами. Например, у Azure есть GPU-серверы, и они добавили Confidential Computing, чтобы шифровать память при выполнении процессов - даже если для их выполнения нужен физический доступ к серверу.

70 Если у вас довольно специфическое приложение, то, возможно, вам придётся не просто выбрать Kubernetes в качестве основы для построения инфраструктуры, но и найти провайдера, который бы мог запустить ваш особенный код. Например, такая потребность может появиться, когда вам критично выполнять GPU Compute - то есть вычисления на графических картах. Это особенность приложений с искусственным интеллектом - как правило, они используют ресурсы графических карт, а следовательно, такую возможность предоставит далеко не каждый облачный провайдер.

71 Безопасность.В одной технологии много различных компонентов, за безопасностью которых приходится внимательно следить: как внешней, на уровне кластеров и нод, так и внутренней, на уровне конкретных образов. Уже появились специальные AntiMalware-решения под Kubernetes, которые сканируют всё, что происходит внутри контейнера.

72 В отличие от контейнеров, виртуальная машина полностью абстрагируется от машины сервера-хоста, которая её запускает: у неё своя операционная система, поэтому риск проникновения в сервер из виртуальный машины гораздо меньше, чем из контейнера.

73 Решить эту проблему можно сканированием активности, шифрованием сетевого трафика, установкой компонентов для безопасности, решений для аутентификации контейнеров и компонентов приложений. Это усложняет жизнь Kubernetes-администраторов, но с этим ничего не поделать - это часть нашей работы.

74 Kubernetes - это всё-таки не PaaS, поэтому приходится запаковывать в контейнеры ещё и middleware, а также зависимости для приложения. Но и эта задача упрощается благодаря огромному количеству уже готовых и преднастроенных образов для контейнеров, которые выложены в публичные реестры.

75 Требование к приложениям контейнеризироваться.Это ограничивает возможности для компаний, которые не разрабатывают приложения сами. Поэтому часто мы сталкиваемся с необходимостью поддерживать legacy-инфраструктуру параллельно с основной. Эта проблема решается постепенным замещением приложений: старые приложения переписываются под новые модели архитектур с поддержкой новых технологий для инфраструктуры или происходит полный переход на приложения типа SaaS, в которых нет необходимости управлять инфраструктурой.

76 Сложность администрирования.Решается использованием облачных сервисов. Я не рекомендую самостоятельно настраивать Kubernetes, потому что для этого нужны очень узкие специалисты, а поддерживать кластер самостоятельно очень сложно.

77 Есть огромное количество вариантов конфигурирования, и существует риск выбрать неправильные компоненты и настройки. В результате вы можете получить настолько кастомизированную инсталляцию Kubernetes, что в будущем вам никто не сможет помочь: не окажется ни консультантов, ни работников, которые могли бы решить ваши проблемы.

78 Возможное решение - самостоятельно пройти сертификацию своего IT-решения. То есть заказать аудит систем, сконфигурировать, выровнять и поддерживать решение по какому-то принятому в индустрии стандарту, а потом, от версии к версии, продолжать регулярно делать аудиты. Но, скорее всего, в этом случае вложенные инвестиции не окупятся.

79 Лучше использовать решения, предоставляемые облачными провайдерами. Сегодня практически любой облачный провайдер подключает Kubernetes as a Service. Плюс существует понятие Certified Kubernetes - все облачные провайдеры сертифицируют своё Kubernetes-подключение в Cloud Native Computing Foundation, а фонд ведёт<a>список</a>сертифицированных провайдеров и постоянно обновляет его.

80 Если брать KaaS, то вы будете платить за выделенные вычислительные ресурсы и хранилища. Как правило, в стоимость также включена оплата за Master Node, который предоставляет API и распределяет ресурсы, а вот за Worker Nodes, на которых будут размещаться сами поды, надо будет платить отдельно.

81 Есть и другие подводные камни. На сегодняшний день у всех облачных провайдеров драйверы выровнены по одной версии Kubernetes и имеют стандартную сборку. Однако их хотят освободить от необходимости поддерживать только основную версию и дать больше свободы - а значит, каждый облачный провайдер сможет делать собственную сборку Kubernetes под свои специфичные драйверы.

82 Это развяжет руки провайдерам, но усложнит жизнь администраторам. Ведь, например, если я хочу поддерживать Kubernetes в Azure, мне нужно будет лучше понимать, что происходит внутри Azure и понадобится поддерживать знания по конкретному облаку.

83 У Kubernetes были конкуренты среди оркестраторов контейнеров. Например, есть кластеры<a>Apache Mesos</a>,<a>HashiCorp Consul</a>,<a>Windows Server</a>,<a>Docker Swarm</a> - они помогают удобно работать с виртуальными машинами и контейнерами. На решениях от этих непрямых конкурентов тоже можно строить инфраструктуру. Однако Kubernetes выиграл войну и стал стандартом де-факто, потому что у него есть много удобных инструментов для управления ролями, доступами, политиками безопасности и идентификацией.

84 Ещё одна альтернатива Kubernetes - FaaS Serverless-технологии. При таком варианте код приложения будет запускаться в момент запроса, а так как приложение делится на самостоятельные запускаемые функции (созданные под каждый тип запроса), то такие системы становятся более портабельными и интегрируемыми, чем целое приложение, созданное под конкретный PaaS. Подобные решения есть у разных провайдеров, но они обладают кастомным API - например, как у <a>Droplets</a>от DigitalOcean.

85 Однако использование виртуальных машин остаётся скорее более дорогой альтернативой использованию контейнеров. Такое решение просто будет сжирать больше ресурсов - хотя оно и может быть оправданно, если мы создаём архитектуру для микросервисов.

86 Кстати, помимо классического Kubernetes, существует и Kubernetes от RedHat -<a>Red Hat OpenShift</a>.

87 <ul><li>Kubernetes стоит использовать, если в вашем проекте счёт контейнеров идёт на десятки или сотни.</li>

88 <li>Kubernetes сам определяет, когда надо масштабировать ресурсы, когда подключить к проекту новые мощности и тому подобное - на основании конфигурации.</li>

89 <li>Несмотря на то, что Kubernetes даёт определённую свободу за счёт высокого уровня абстракции, вы всё ещё можете столкнуться с проблемой Vendor Lock. Привязка к специфике крупнейших облачных провайдеров делает решения непереносимыми.</li>

90 <li>Чтобы избежать рисков, связанных с блокировкой облачного провайдера, есть смысл разворачивать инфраструктуру на платформе двух провайдеров: один будет основным, а второй - резервным.</li>

91 <li>Поддержание Kubernetes-инфраструктуры - дорогое удовольствие, на это нужна крепкая команда специалистов. На внутреннюю команду будет уходить много денег, а на аутстаффе велик риск выбрать неподходящего подрядчика.</li>

92 <li>В Европе компании очень медленно переходят на Kubernetes и пока предпочитают более привычные и потому менее рисковые виртуальные машины.</li>

93 </ul><a>Бесплатный курс по Python ➞Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу</a>