Гайд по Kubernetes. Эпизод I: k8s для неразработчиков

История появления платформы оркестрации

Около 30 лет назад большинство программных приложений были огромными неповоротливыми монолитами. Они работали как единый процесс или же как несколько мелких процессов, распределенных по разным серверам. Все компоненты в них были взаимосвязаны и, когда требовалось изменить один из элементов, разработчикам приходилось заново выкладывать приложение.

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

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

Такие монолиты работают и сегодня, но постепенно они распадаются на мелкие самостоятельные элементы — микросервисы. Каждый микросервис можно разрабатывать, обновлять, развертывать и масштабировать по отдельности. Это помогает оперативно вносить изменения и поддерживать актуальность всего приложения.

Кажется, в этот момент жизнь разработчика должна была стать проще, но — нет: компонентов много, система разрастается. Управлять ею становится труднее. Но самое сложное — понять, где расположить элементы, чтобы инфраструктура работала максимально эффективно, но при этом не увеличить затраты на оборудование. Вручную это делать долго и тяжело: требовалась автоматизация.

Так появился Kubernetes — платформа для непрерывного автоматического развертывания контейнерных приложений, которая облегчила жизнь разработчикам, системным администраторам и легла в основу DevOps-подхода. Теперь разработчики могут развертывать приложения самостоятельно и так часто, как необходимо, даже не привлекая системных администраторов. А администраторам уже не приходится вручную переносить приложения, если случился аварийный сбой. Все, что им нужно — контролировать платформу Kubernetes, а о приложениях позаботится сама платформа.

Что делает Kubernetes

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

Когда необходимо развернуть многокомпонентное приложение, k8s сам выбирает сервер для каждого элемента и развертывает его. Каждый компонент взаимодействует с другими компонентами приложения, и его легко найти. При этом не нужно что-либо менять в коде приложения.

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

Как это работает?

Чтобы понять принципы работы Kubernetes, немного расскажем о микросервисах и контейнерах — основных элементах платформы.

Компоненты приложения

Микросервисы — части приложения, которые находятся в разных его блоках. Чаще всего в одном блоке находится только один компонент. Каждую часть можно разрабатывать, изменять или обновлять в любое время — на работу остальных частей это не повлияет.

Микросервис взаимодействует с другими компонентами через четко определенные интерфейсы — API и синхронные или асинхронные протоколы, — например, HTTP или AMQP. Такие протоколы не привязаны к конкретному языку программирования и понятны всем разработчикам. То есть каждый микросервис можно написать на том языке, который больше всего подходит для реализации определенного компонента.

Так как каждый микросервис — это автономный процесс, то можно разрабатывать и развертывать каждый компонент отдельно. Так, если изменить один элемент, то не нужно изменять или развертывать какой-то другой сервис. Правда, это работает только в том случае, если API не изменяется или изменяется только обратно совместимым образом.

Масштабирование тоже происходит отдельно для каждого сервиса. Можно масштабировать только тот сервис, который требует больше ресурсов, а остальные компоненты не трогать.

Часто работа IT-отделов устроена так, что компоненты приложения разрабатывают разные команды, и каждая из них может использовать разные библиотеки. Расхождение в библиотеках между компонентами — это неизбежность, которую надо просто принять как данность.

Для DevOps развертывание динамически связанных приложений с различными версиями совместно используемых библиотек — сложная задача. Ведь чем большее количество компонентов надо развернуть на одном хосте, тем сложнее управлять всеми зависимостями. Микросервисы спасают, хотя и у них есть свои недостатки, например:

• сложно решить, где развертывать каждый компонент, так как с каждым новым добавленным элементом становится больше взаимосвязей между компонентами;
• трудно настроить компоненты так, чтобы они свободно «общались» между собой и работали, как единая система;
• становится сложной отладка и трассировка вызовов выполнения, так как они охватывают несколько процессов и машин. Сейчас, правда, уже есть решение таких проблем с помощью систем распределенного сбора трассировок, — например, Zipkin.

Контейнеры — это способ упаковки кода, системных инструментов, библиотек и конфигураций. Когда приложение готово и протестировано, разработчик пакует его в специальную оболочку — контейнер, и передает на сервер, где оно будет работать. Контейнер нужен, чтобы по пути приложение не «сломалось» и работало точно так же, как и в компьютере разработчика, где угодно — на сервере, в облаке или на обычном компьютере пользователя.

Вместе с приложением в контейнер упаковывают и микросервисы, чтобы не переносить их отдельно из рабочей среды на сервис. Часто один контейнер представляет собой один микросервис.

Примечание

Контейнер — это изолированное приложение. На какой бы платформе его ни запустили, система внутри контейнера будет работать одинаково.

Принцип работы Kubernetes

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

Но k8s работает не один. Чтобы он мог запустить службы и приложения в контейнерах, каждый из них должен быть оснащен средой выполнения контейнеров. Это может быть Docker, rkt или runc.

Что дает использование Kubernetes бизнесу?

Технологию Kubernetes используют как в BigData-проектах (например, на нем работают приложения Tinder, BlaBlaCar, центр ядерных исследований CERN), так и для обработки маленьких объемов данных. По мере развития технологии она становится все более популярной и даже «модной». Это привело к тому, что почти каждый стартап теперь считает необходимым внедрение k8s, почти каждая компания проявляет к нему интерес. Однако исходить из принципа «все об этом говорят, — значит, нам тоже нужно» — неверно.

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

• Масштабируемость рабочей нагрузки. Успешность приложения во многом зависит от производительности и масштабируемости. Kubernetes как раз является системой управления, позволяющей масштабировать приложение и его инфраструктуру при увеличении рабочей нагрузки или уменьшать по мере снижения нагрузки.
• Оптимизация затрат на ИТ. Автоматическое масштабирование приложений минимизирует риски существования невостребованных ресурсов IT-инфраструктуры, расходы становятся прозрачными, а эффективность управления ими возрастает.
• Оперативность вывода продуктов на рынок. Разделив общий процесс на отдельные задачи и команды, гибко управляемые и легко взаимодействующие между собой, можно значительно сократить затраты времени на разработку, а процесс мониторинга исполнения — упростить.

Примечание

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

Как начать использовать Kubernetes?

Существует три способа внедрить k8s на предприятии:

1. Самостоятельно, что повлечет за собой расходы на обучение и, при необходимости, наем дополнительных сотрудников.
2. Использовать один из наших сервисов для автоматизации развертывания, масштабирования и управления приложениями на основе Kubernetes: Cloud Container Engine Cloud Container Engine или SberCloud K8S (SberCloud Managed Kubernetes).
3. Полностью передать управление на аутсорс поставщику ИТ-услуг.

Резюме

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

Во второй части мы углубимся в технические аспекты: архитектуру и компоненты, пространство имен и сеть в Kubernetes.

Источники

• Лукша М. Kubernetes в действии.
• Туториал Digitalocean.
• Руководство RedHat.
• Портянкин И. Программирование Cloud Native. Микросервисы, Docker и Kubernetes.
• CNCF.
• Официальный сайт Kubernetes.