Когда вы просматриваете маркетинг вокруг Kubernetes, касающийся «этого продукта или того продукта» или бесчисленного количества «жужжащих» слов, которые сопровождают его, вы остаетесь с платформой. Платформа, которая, по мере того как вы погружаетесь все глубже и глубже, оказывается не такой простой и понятной, какой ее представляют сервисы на основе абстракции, такие как Kubernetes, работающие в облаке.
Kubernetes и все его внутренние компоненты, а также все, что находится под капотом таких сервисов, как AKS, EKS, GKE и т.д., чрезвычайно сложны.
Учитывая всю эту сложность, что же на самом деле пытается решить Kubernetes?
Цель этой статьи — объяснить, зачем вообще существует Kubernetes.
Технология вместо платформы
Kubernetes сама по себе является платформой.
Это чрезвычайно большая платформа. Ее называли по-разному:
- Дата-центр облака
- операционная система облака
и не зря — ведь под капотом происходит очень многое.
С учетом сказанного, давайте сделаем шаг назад и подумаем о том, что Kubernetes на самом деле делает для нас.
Kubernetes масштабирует и управляет Pods, которые состоят из контейнеров, а контейнеры запускают приложения. Приложения могут быть фронтенд-приложениями, бэкенд-приложениями, скриптами или практически всем, что вы захотите.
Kubernetes оркеструет Pods для нас путем:
- Планируя запуск Pods на определенных узлах.
- Автоматическое масштабирование вверх или вниз, по горизонтали или вертикали.
- Позволяет одному и тому же приложению работать в нескольких Pods с репликами.
- Выставление Pods в виде сервисов, чтобы пользователи и другие Pods, запущенные внутри кластера Kubernetes, могли получить к ним доступ.
Kubernetes, по сути, является оркестратором и менеджером приложений.
Основная проблема, которую решает Kubernetes, — это возможность управления контейнерными приложениями в масштабе.
Однако Kubernetes — не единственная платформа, делающая это. Помните, что «технология над платформой» чрезвычайно важна. Kubernetes не делает ничего такого, чего не делала бы раньше ни одна другая платформа. Он просто делает это, возможно, гораздо более эффективным способом.
Самое важное, что нужно помнить, думая о том, что Kubernetes пытается решить, — это не использование Kubernetes, а то, чем Kubernetes на самом деле является, а именно — оркестратор и менеджер приложений.
Сложности центра обработки данных
Когда в центре обработки данных работают виртуальные машины на пустом железе, получается нечто похожее на это:
- Сам центр обработки данных
- Стойки с серверами
- Сетевое оборудование (брандмауэры, маршрутизаторы, коммутаторы и т.д.)
- Множество кабелей
Если вы запускаете Kubernetes в локальной сети, у вас все равно будет центр обработки данных, стойки серверов, сетевое оборудование и кабели. У вас не будет приложений, работающих на виртуальном оборудовании, таком как ESXi, масштабируемом на бесчисленных серверах в центре обработки данных и за его пределами.
Вместо этого у вас будут кластеры Kubernetes, масштабируемые внутри и вне центра обработки данных.
Хотя вначале это может показаться таким же сложным, на самом деле это не так. Kubernetes позволяет вам управлять одной системой, затрачивая на это лишь часть времени по сравнению с управлением виртуализированным оборудованием. У вас также будет один API для взаимодействия, а не множество пользовательских интерфейсов, методологий автоматизации и конфигураций на бесчисленных серверах. Другая реальность заключается в том, что, скорее всего, вы не собираетесь запускать Kubernetes на пустом металлическом сервере. Скорее всего, вы будете использовать что-то вроде OpenStack или гибридную облачную модель, которая добавит еще один уровень абстракции, устраняющий непосредственное управление «голым» сервером.
Короче говоря, вы будете управлять своей средой с помощью API вместо того, чтобы нажимать на кнопки и использовать тонны различных скриптов для автоматизации.
Сложности облака
Когда вы переносите рабочие нагрузки в облако, основное различие между центром обработки данных и облаком заключается в том, что вы больше не управляете оборудованием. Все остальное, включая масштабирование приложений, по-прежнему остается на вашей совести:
- масштабирование приложений
- Реплики для приложений
- автоматическое восстановление приложений
- Как управлять приложениями и взаимодействовать с ними
- Как автоматизировать все, что входит в этот список
Облако определенно облегчило жизнь, но фактические сложности, за исключением управления аппаратным обеспечением, остаются такими же и в облаке.
Kubernetes призван сделать это немного проще. Возьмем облако в качестве примера. Если вы используете Kubernetes в облаке и вам нужно масштабировать узел, вы можете сделать это автоматически. Рабочий узел автоматически создается и автоматически подключается к вашему кластеру Kubernetes. Затем, если этот рабочий узел необходим для запуска Pods, это также происходит автоматически на основе планировщика Kubernetes.
Еще один важный и, возможно, самый важный аспект работы Kubernetes в облаке заключается в том, что плоскость управления абстрагирована для вас. Это еще один уровень абстракции и в целом еще одна сложность, о которой вам не нужно беспокоиться.
Без Kubernetes вы все еще можете иметь группы автоматического масштабирования для виртуальных машин в облаке, но вам все еще нужно создать автоматизацию и повторяющиеся процессы для передачи рабочих нагрузок на виртуальные машины.
Одним словом, использование Kubernetes в облаке и вне облака помогает решить проблемы масштабируемости инфраструктуры.
Сложности масштабирования серверов
Возможность масштабирования и обеспечения высокой доступности виртуализированных или пустых серверов — не самая простая задача в мире.
Существует два способа масштабирования серверов:
- Горячее
- Холодный
«Горячий» означает, что серверы работают, но находятся в режиме ожидания. Они готовы принять нагрузку по мере ее поступления.
«Холодный» означает, что на серверах, возможно, есть золотой образ приложения, двоичные файлы и необходимые зависимости, но они выключены.
В любом из этих сценариев вам придется беспокоиться об обновлениях этих серверов, управлять ими, платить за них и автоматизировать их обслуживание.
В Kubernetes вам практически достаточно добавить новый рабочий узел или новую плоскость управления. В зависимости от того, где вы развертываете рабочий узел или плоскость управления, вам все равно придется поддерживать сервер (обновления, управление, обслуживание и т.д.), но это гораздо меньше, чем управлять сервером, на котором работает приложение.
Масштабирование в целом — задача не из легких. Существует множество повторяющихся процессов, которые необходимо выполнить, чтобы приложение, двоичные файлы и зависимости были запущены на сервере, и чтобы он выглядел и чувствовал себя так же, как и другие серверы. В Kubernetes, когда вы устанавливаете новую плоскость управления или рабочий узел, скажем, с помощью Kubeadm, на сервере нужно выполнить команду из одной строки. Через несколько минут вы официально масштабируетесь.
Сложности масштабирования приложений
Kubernetes помогает создать среду, ориентированную на контейнеры.
В других средах у вас может быть несколько других компонентов, таких как:
- чистый металл
- Виртуальные машины
- Немного и того, и другого.
Однако с Kubernetes у вас есть один тип среды — контейнерная.
Контейнерная среда, конечно, сама по себе является сложной, но есть одна замечательная особенность — вам нужно создавать и планировать только один тип среды. Это относится и к таким сложностям, как масштабирование приложений.
В традиционной среде масштабирование приложения требует тщательного планирования. Существуют целые рабочие процессы, которые определяют, как приложение будет правильно работать, если нагрузка на сервер станет слишком высокой. Рабочий процесс (на высоком уровне) выглядит следующим образом:
- Новый сервер создается в группе автоматического масштабирования
- Сервер конфигурируется
- Сервер устанавливает все зависимости приложения
- Приложение развертывается
- Проводятся тесты, чтобы убедиться, что приложение работает должным образом.
Даже на высоком уровне эти шаги кажутся сложными. Один только код автоматизации, который используется для конфигурирования сервера, представляет собой целое чудовище.
В Kubernetes это практически все сделано за вас. Если Pod не может получить ресурсы на одном рабочем узле, он просто переходит на следующий рабочий узел. Если для Pod требуется больше копий, вы просто устанавливаете mincount и maxcount для того, сколько копий может быть развернуто. Если вы понимаете, что maxcount слишком мало, вы просто обновляете maxcount и повторно развертываете Kubernetes Manifest.
Kubernetes, безусловно, сложна, но то, насколько легко она позволяет масштабировать приложения, просто поражает.
Модернизация приложений
Вспоминая предыдущий раздел, можно сказать, что существует также необходимость обновления приложений. На сервере рабочий процесс (на высоком уровне) обычно выглядит следующим образом:
- SSH на сервере
- Скопируйте новый двоичный файл на сервер
- Выключить службу
- Добавьте новый двоичный файл
- Запустить службу
- Надеемся, что все пройдет хорошо
С Kubernetes вам не нужно этого делать. Большая часть этой работы выполняется за вас с помощью Rolling Updates.
Rolling Updates похожи на Canary Deployments. Допустим, у вас есть три реплики для развертывания. Обновление Rolling Update развернет новую версию на одном Pod, подтвердит ее работоспособность, а затем перейдет к следующему. Этот подход гораздо более прост, чем на обычной виртуальной машине или пустом сервере.
Сложности, связанные с ручным управлением
Ручные усилия означают:
- Замедление сборки и времени
- Вмешательство человека
- Отсутствие повторяемого процесса
Давайте разберем каждую из этих сложностей.
Если вы пытаетесь создать и развернуть приложение на сервере, это будет выглядеть примерно так: создание сервера, развертывание операционной системы, запуск обновлений, установка зависимостей приложения, развертывание приложения и устранение неполадок. Это не только часы, но и, возможно, дни усилий. Вместо этого имеет смысл контейнеризировать приложение, упаковать зависимости и развернуть его под управлением оркестратора. Обратная связь о том, что не так с приложением и что нужно исправить, происходит гораздо быстрее, чем первоначальные ручные усилия по развертыванию сервера.
Люди совершают ошибки, и это никогда не прекратится. Вмешательство человека при развертывании приложений ужасно, и, по правде говоря, для этого больше нет причин. 20 лет назад инженерам нужно было работать с клавиатурой, развертывая приложение. Сейчас существует так много платформ автоматизации и оркестров, что нет смысла тратить время на то, чтобы делать все вручную. Вместо этого обучите системы делать работу за вас. Kubernetes — одна из таких систем.
Если вы выполняете работу вручную, это означает, что не создаются повторяющиеся процессы. Это плохо не только для вас, поскольку вы тушите пожары вместо того, чтобы создавать работу, ориентированную на ценность, но и для вашей команды. Если вы в отпуске или уволились, остальная команда не имеет представления о том, что заставляет систему, над которой вы работали, «тикать». Платформы оркестровки и создание повторяющихся процессов помогают снизить этот риск. Это огромный груз с плеч любого инженера.
Короче говоря, Kubernetes — это управление конфигурацией ваших приложений, и одна из причин его существования — устранение сложности ручной настройки приложений.
Желаемое состояние
В любой среде есть два типа состояния:
- Текущее состояние
- Желаемое состояние
Иногда текущее состояние ваших платформ и приложений является желаемым состоянием. В большинстве случаев это не так. Это происходит потому, что развернутая среда не работает так, как ожидалось, или кто-то вошел в сервер по SSH вручную и что-то изменил. Затем, при повторном развертывании среды, состояние не будет соответствовать изменениям, сделанным вручную.
Kubernetes стремится решить эту проблему с помощью контроллеров, которые смотрят на текущее состояние и подтверждают, что оно соответствует желаемому. Например, возьмем контроллер развертывания. Контроллер развертывания, например, посмотрит на приложение, которое должно иметь три копии. Если по какой-то причине существует только две, контроллер развертывания примет меры и обеспечит приложению третью реплику (третий Pod).
Существуют и другие системы, ориентированные на Kubernetes, которые также делают это. Например, GitOps. GitOps берет идею контроллера Kubernetes и применяет тот же метод для того, чтобы репозиторий контроля исходных текстов перешел в желаемое состояние. Методологии GitOps «сверяются» с репозиторием контроля исходных текстов, чтобы подтвердить, что то, что развернуто в Kubernetes, соответствует тому, что находится в контроле исходных текстов. Если это не так, GitOps-контроллер (например, Flux) включается в работу и развертывает то, что необходимо для среды Kubernetes, чтобы соответствовать исходному контрольному хранилищу.
Продвижение микросервисов
Монолитные приложения — это приложения, которые тесно связаны друг с другом, что означает, что если в одной части приложения произойдет обновление, это повлияет на все остальное приложение.
Микросервисы — это отдельные части приложения. Например, допустим, у вас есть frontend, middleware и backend. В монолитной среде все эти три части будут находиться вместе в одной кодовой базе. В микросервисе они разделены на три разные части. Это означает, что если вы захотите обновить одну часть, это не повлияет на остальную часть приложения.
Из-за того, как работают Pods, по сути, нет смысла не разделять ваше приложение на микросервисы или, по крайней мере, разделять кодовую базу на отдельные репозитории и иметь образ контейнера для каждой кодовой базы.
Благодаря тому, насколько просто Kubernetes позволяет создать Pod, это очень помогло организациям получить толчок, необходимый для внедрения микросервисов.
Заключительные размышления
При внедрении Kubernetes главное помнить, что вначале она сложна, но по мере ее изучения вы поймете, что она сложна только потому, что это новый способ управления приложениями. Когда вы по-настоящему углубитесь в Kubernetes, вы поймете, что она устраняет многие сложности, с которыми сталкиваются стандартные среды, и, в свою очередь, позволяет вам сосредоточиться на более важной работе вместо того, чтобы тушить пожары или тратить массу времени на ручное вмешательство.