Kubernetes: что это, где применяется и кому подходит

07.11.2022
Kubernetes: что это, где применяется и кому подходит

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

Прежде чем говорить о Kubernetes подробно, сначала нужно вспомнить, как развивалась среда исполнения приложений.Эволюция среды исполненияФизические серверы (bare metal)Исторически так сложилось, что для работы приложений применялись отдельные физические серверы (bare metal). Когда приложение обрабатывало небольшую нагрузку — это было вполне нормальным решением. По мере роста нагрузки необходимо было придумать механизмы масштабирования — стали использовать мощные блейд-серверы, формировать стойки из серверов. Плюсы использования серверов bare metal — это физическая защищенность данных (оборудование находится рядом и всегда доступно). Для запуска приложения достаточно одного сервера.Но есть и минусы. Поскольку мы имеем дело непосредственно с «железом», то его надо будет обслуживать и ремонтировать. Есть проблемы с масштабируемостью: если нагрузка на приложение возрастает до пределов физического сервера, нужно переносить данные на другой, более мощный сервер bare metal.  Кроме того, сроки восстановления данных занимают много времени. А для достижения отказоустойчивости нужно и использовать минимум два сервера, которые будут работать параллельно и хранить одни и те же данные.Следующий этап эволюции — VM Виртуальные машины — это имитация аппаратного сервера специальными программными методами с реализованной в современных процессорах поддержкой виртуализации. На одном физическом сервере можно создать несколько виртуальных машин поменьше и работать с ними как с самостоятельными серверами. VM имеют ряд преимуществ по сравнению bare metal. Использование VM обеспечивает более высокую утилизацию оборудования в соответствии с ресурсами конкретного сервера. Это особенно актуально, если у вас есть арендованные серверы и вы платите за оборудование, которое не используется на полную мощность. Восстановить работу виртуальной машины значительно быстрее, чем физический сервер. Но это при условии, что сам физический сервер, на котором работает VM, исправен. Виртуальные машины могут мигрировать между физическими серверами, в том числе в формате «живой миграции» (live migration) — продолжая работать (без их остановки для переноса). Это особенно удобно, если нужно обслужить какой-то конкретный сервер.VM имеют и свои минусы. Во-первых, возникают накладные расходы на механизмы управления виртуальными машинами. Возникает излишнее потребление ресурсов, т. к. для работы приложения в виртуальной машине ему требуется отдельная операционная система. Во-вторых, для обеспечения минимальной отказоустойчивости при использовании виртуализации необходимо иметь минимум два физических сервера, чтобы можно было запустить виртуальные машины на втором сервере при отказе первого. Кроме того, между этими серверами должно быть центральное сетевое хранилище, на котором будут находиться образы виртуальных машин — для проведения «живой миграции» и быстрого перезапуска виртуальных машин, если вдруг какой-то сервер выйдет из строя.Эра контейнеровКонтейнеры существуют достаточно давно. Самая удачная и наиболее распространенная реализация контейнеров — Docker. Этот механизм позволяет создавать контейнер, в котором «все включено». Разработчик создает для своего приложения максимально подходящую среду, версии библиотек — полный комплект, который затем упаковывает в Docker. Он представляет собой образ, куда уже изначально разработчиком зашит набор необходимого ПО и предварительных настроек. Нам достаточно просто запустить этот контейнер. Контейнеры — это не виртуальные машины, а специально разделенная программным способом среда, управляемая единым ядром. Каждый контейнер работает независимо друг от друга и не имеет лишних накладных расходов. Переключение между контейнерами достаточно быстрое. Запуск контейнеров происходит быстрее, чем запуск виртуальных машин, а место на диске и в памяти контейнеры занимают меньше, чем виртуальные машины. Преимущества контейнеров очевидны. Они обеспечивают высокую утилизацию оборудования: на одном и том же сервере можно запустить не десятки виртуальных машин, а сотни контейнеров. Запуск контейнеров быстрый, поскольку они меньше, следовательно, выше скорость восстановления сервисов. Контейнеры легко мигрируют: нужно только, чтобы образ, из которого «поднимался» контейнер, присутствовал на том сервере или был ему доступен по сети. Контейнеры легко масштабировать. Для минимальной работы с контейнерами (без отказоустойчивости) достаточно одного сервера. Недостатки у контейнеров тоже есть. Когда их становится очень много, появляются определенные сложности управления ими и обеспечения безопасности. Для обеспечения отказоустойчивого механизма в среде Kubernetes необходимо минимум три физических сервера. Среда исполнения может быть разной: физические серверы, виртуальные машины или контейнеры. При этом контейнеры дают нам быстрый процесс разработки, поскольку каждый разработчик работает с тем, с чем он привык, в той среде, в которой он привык. Еще один важный момент при работе с контейнерами Docker — это их воспроизводимость. Разработчик создает образ для запуска контейнеров — из этого образа будут запускаться контейнеры везде так же, как они работали у разработчика.  Как строить будем? Типы архитектур ПОСамо программное оборудование строится по разным моделям, в зависимости от того, какой вариант предпочтительнее для того или иного проекта. Но типы архитектур тоже имеют свою историю.Микроуровневая архитектура. Система состоит из нескольких уровней, и каждый из них взаимодействует только с двумя соседними. Она подходит для создания новых приложений, то есть если нужно что-то быстро создать — отработать какую-то модель, что-то проверить. Это быстро, просто и понятно. Многие корпоративные приложения строятся по этой модели. Здесь существует разделение компетенций: отдельно фронтенд, отдельно бэкенд. Событийно-ориентированная архитектура. Разработчик создает программы, в которых поведение, то есть их реакции возникают при появлении каких-либо событий. Событие — определенное изменение состояния. Как правило, приложение содержит два компонента: источники событий — агенты — и их потребители — стоки. Такая модель хорошо подходит для создания асинхронных систем, для создания пользовательских интерфейсов, где мы получаем реакцию в ответ на действия пользователя. Микроядерная архитектура. Ядро системы окружено набором плагинов, при этом каждый из них написан отдельно и отвечает за определенную логику. Ядро выполняет большую загрузку-выгрузку соответствующих компонентов. Микроядерная архитектура часто применяется для создания расширяемых приложений. Это система с постоянно меняющимся набором правил: есть ядро и набор плагинов, которые можно переделывать, менять, не переписывая все. Микросервисная архитектура. Она применяется, когда отдельные задачи приложения можно легко разделить на небольшие функциональные блоки — независимые сервисы. Эти сервисы могут быть написаны на разных языках программирования, поскольку они между собой «общаются» по сети. Очень часто микросервисная архитектура запускается в контейнерах. Каждый сервис выполняет свой функционал. Управляют набором контейнеров с помощью систем оркестровки контейнеров. Существует несколько их видов, но наиболее популярный — Kubernetes.Микросервисная архитектура — отличный вариант в том случае, если запланирован проект с высокой нагрузкой. Здесь используются системы с разномастным ресурсами, когда, например, одна часть приложения требует много ресурсов процессора, а другая — много памяти. В этом случае можно разместить части приложения в раздельные контейнеры, а сами контейнеры — на разные, наиболее подходящие по ресурсам серверы. Также обеспечивается определенная безопасность передаваемых данных, поскольку микросервисы «общаются» по API и передают только ту информацию, которая нужна тому или иному сервису.Микросервисы — это современно, удобно, в большинстве случаев универсально, но этим набором микросервисов нужно управлять. И для этого нам нужен Kubernetes.Оркестровка контейнеровKubernetes написан на языке Go и изначально был внутренним проектом компании Google, наследником другого внутреннего проекта — Borg, который применяли для системы управления кластерами. Но позже решили Kubernetes сделать общедоступным и все права были переданы в специально созданный фонд CNCF (Cloud Native Computing Foundation), который сейчас занимается развитием Kubernetes.Основные принципы работы Kubernetes заключаются в следующем. Деплоймент строится на основе подов. Под — это логически обособленная группа контейнеров, то есть Kubernetes работает не напрямую с контейнерами, а именно с подами. Под имеет свой внешний (внутренний для Kubernetes) IP-адрес, может иметь свои внутренние хранилища и контейнеризованные определенные приложения. Самый простой под может содержать один пользовательский контейнер или несколько контейнеров. Эти контейнеры внутри самого пода взаимодействуют между собой, видят друг друга по сети и могут общаться, не вылезая «наружу». Это нужно для того, чтобы создать атомарно функционирующие сервисы. В идеале дробление на микросервисы должно быть таким, чтобы каждый микросервис реализовывал свой минимальный функционал и состоял из одного или нескольких подов. Kubernetes осуществляет запуск подов на нодах своего кластера (ноды — это узлы, серверы), он обеспечивает поддержание заданной конфигурации. В Kubernetes создаются декларативные описания того состояния, которое должно быть по итогу. И если какой-то под перестал отвечать, система оркестровки его уничтожает и запускает аналогичный. Kubernetes может переносить поды с ноды на ноду, распределяя их в зависимости от свободных ресурсов на нодах и заданных параметров размещения. В Kubernetes используется именно декларативный подход: есть файлы описаний в формате YAML и там необходимо указать, что должно быть, какие именно ресурсы должны быть отведены тому или иному поду. Если под начинает потреблять больше ресурсов, чем ему было изначально отведено, такой под уничтожается и запускается его копия заново.Таким образом, нет проблемы утечки памяти отдельных приложений (в случае, если все правильно было описано при создании конфигурационных файлов). Преимущества такого подхода очевидны: система обслуживает себя самостоятельно. В случае выхода из строя физического сервера пропадают те поды, которые на нем работали. Kubernetes видит это и сам запускает на других серверах вышедшие из строя поды. Система становится повторяемой, то есть если удалось запустить приложение в тестовой версии, то, используя те же самые конфигурационные данные и образы, приложение гарантированно «раскатится» в продакшене. Кроме того, система становится версионируемой. И если что-то пошло не так, например деградировала работа каких-то сервисов, можно спокойно взять из Git’а более старую устойчивую конфигурацию и «разворачивать» уже из нее. Приложения могут быть stateless (которые не сохраняют свое состояние) и statefull (которые сохраняют свое состояние). Kubernetes в основном направлен на работу с приложениями stateless. То есть можно запустить какие-то контейнеры, в которых изначально сконфигурированный образ. Он обращается куда-то за данными и с ними работает. Например, браузер, который открывает сайт, получает те данные, которые контейнер взял из какой-то внешней базы. Пользователь отвечает, заполняет поля, контейнер, соответственно, отправляет эту информацию во внешнюю баз,у не храня данные в себе. В любой момент можно удалить такой контейнер, запустить его новую копию и продолжить работать дальше без потери данных. Архитектура Kubernetes включает в себя специальный механизм ETCD —  специализированную базу. Она хранит все данные о состоянии и конфигурации кластера. Каждая master-нода имеет у себя ETCD-базу, при этом она постоянно реплицируется с соседями. Все взаимодействие с непосредственно рабочими нодами происходит через API-сервер. В свою очередь внутри кластера присутствует локальная сеть, через которую управляющие master-ноды взаимодействует с рабочими worker-нодами. Приложения запускаются на worker-нодах. В некоторых случаях, когда серверов в кластере мало (3–5), функционал master- и worker-нод может быть совмещен. Оркестровка контейнеров. Управление Kubernetes можно осуществлять разными способами: через пользовательский интерфейс Kubernetes-dashboard. В нем видно, что где происходит и можно ли осуществлять какие-либо изменения. Можно управлять и из командной строки: есть специальное консольное приложение kubectl, с помощью которого нужно отдавать команды API и выполнять те или иные действия с кластером.Что в итоге дает Kubernetes? Во-первых, Kubernetes — это высокая надежность. Она обеспечивается большим количеством узлов (от трех и более) и алгоритмами для автоматического перезапуска подов, если они по какой-либо причине стали недоступны. Алгоритмы отслеживают состояние подов, занимаются выделением ресурсов, уничтожением подов, переездом подов в случае нехватки ресурсов. Это достаточно сложный самоуправляемый организм, который обеспечивает стабильную работу приложения. Kubernetes дает масштабируемость. Если возрастает нагрузка, можно как в ручном, так и в автоматическом режиме увеличивать (уменьшать) количество запущенных подов, тем самым обрабатывая разное число запросов и достигая оптимальной производительности, а для адаптированных мощностей — эксплуатационной стоимости.Удобство разработки. Kubernetes дает определенное удобство разработки. Используя изолированные окружения для разработки, тестирования, продакшена, можно поэтапно обновлять приложения. Здесь предусмотрены различные гибкие механизмы частичной выкатки новых версий (например, 10% всех подов будут в новой версии, а остальные — пока в старой). Переход на методологию CI/CD. Kubernetes хорошо интегрируется с Gitlab и помогает в переходе на практики CI/CD (непрерывная интеграция / непрерывное развертывание). Зачастую методология CI/CD позволяет совместно с Kubernetes реализовывать процесс от создания, тестирования до запуска приложений плавно непрерывно и удобно.Что мы в итоге получаем? Что дает применение Kubernetes? Это самовосстанавливающаяся система. Она удобна для разработки и управления, имеет высокую надежность, позволяет выстроить методологию CI/CD при разработке и управлять контейнерами.Kubernetes на базе разных сред. Kubernetes может работать на основе разных сред: его можно устанавливать на bare metal, на VM, поднятые самостоятельно или арендованные на серверах в data-центрах. Можно использовать облачные технологии, пользуясь уже преднастроенным Kubernetes и используя его у себя в работе. Любой из механизмов позволяет использовать Kubernetes. Kubernetes в облаках. На сегодняшний день почти все самые известные сервисы предоставляют те или иные контейнерные технологии: — Amazon (AWS Elastic Container Service)— Microsoft (Microsoft Azure Containers)— Google (Google Cloud Platform Kubernetes Engine)— Mail.Ru (MCS Cloud Containers)— Yandex (Yandex Managed Service for Kubernetes)— Selectel (Managed Kubernetes) 

 

Читать ещё