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

Контейнер - это новый процесс

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

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

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

Контейнер - это новый процесс.

Масштаб: хорошая проблема

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

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

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

  • может быть запущено несколько копий (сборка для параллелизма),
  • контейнеры могут запускаться и останавливаться динамически на любом компьютере в кластере (предпочитают безгражданство, эфемерность), и что
  • компьютеры или процессы могут выйти из строя или быть недоступными в любое время, но вся система должна продолжать работать (построение для сбоя и восстановления).

При таком большом количестве компьютеров, которыми нужно управлять в кластере, мы сталкиваемся с некоторыми дополнительными проблемами.

  • Во-первых, нам нужно управлять ресурсами на компьютерах, такими как обработка и хранение. Это означает, что мы должны эффективно распределять и планировать процессы, которые их используют, на разных компьютерах.
  • Нам также нужны сходства или способы совместной работы связанных процессов для эффективного совместного использования ресурсов; и анти-сродства, чтобы гарантировать, что процессы, конкурирующие за одни и те же ресурсы, не выполняются на одном компьютере.
  • Например, если бы мы хотели запустить две копии процесса сервера приложений, чтобы обслуживать вдвое большее количество запросов, мы бы хотели, чтобы эти процессы выполнялись на разных компьютерах в кластере.
  • Поскольку множество процессов выполняется повсюду, нам нужен способ обнаруживать их все и общаться с ними. Мы можем взаимодействовать с процессом, если знаем IP-адрес компьютера, на котором он запущен.

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

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

Шаг в этом направлении - Fleet на CoreOS, который, по сути, представляет собой идею процесса инициализации на одном компьютере, расширенного до инициализации для всего кластера.

Проект Kubernetes, представленный Google, приближает нас к модели, которой мы хотим иметь один гигантский компьютер.

Kubernetes: The Pod - новый компьютер

Первое, что делает Kubernetes, - забирает ваши компьютеры и возвращает вам один гигантский компьютер в качестве кластера Kubernetes.

Модуль Kubernetes указывает набор контейнеров Docker или Rkt для запуска.

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

Раньше мы думали, какие процессы запускать вместе на одном компьютере. Теперь мы можем подумать, какие поды строить вокруг каких групп процессов; pod-модули становятся отличным способом моделирования функциональной единицы приложения. Мы даже можем просто добавить модули, созданные сообществом, и сразу же заставить их работать, например, для ведения журнала и мониторинга.

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

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

Подставка - это новый компьютер.

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

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

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

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

Полный круг и дорога впереди

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

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

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

Добавьте серверные API в свои приложения за считанные минуты с платформой Hasura. Попробуйте это здесь: https://hasura.io

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