Открыть список
Как стать автором
Обновить
Флант
DevOps-as-a-Service, Kubernetes, обслуживание 24×7

Kubernetes — это как океанариум

Блог компании ФлантDevOpsМикросервисыKubernetes
Перевод
Автор оригинала: Anne LoVerso

Прим. перев.: в конце прошлого года Anne LoVerso — инженер из VMware Pivotal Labs — опубликовала развернутое сравнение Kubernetes с… океанариумом. Эта небольшая статья с наглядными иллюстрациями и аналогиями ориентирована на тех, кто впервые знакомится с K8s, и призвана упростить их самое первое погружение в дебри океана… оркестратора.

Знакомьтесь: это приложение.

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

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


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

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

В океане у нашей рыбки нет собственного выделенного пространства и ресурсов.


И тут на выручку приходят контейнеры.

С помощью инструментов вроде Docker мы можем предоставить контейнеры приложениям и обеспечить им персональную среду.


Это pod, базовый элемент Kubernetes.

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

Теперь, когда наша рыбка надежно помещена в коробку (pod), Kubernetes-океанариум может ей управлять.


Иногда приложениям требуются ресурсы вроде памяти и вычислительных мощностей процессора.

Например, в нашем случае контейнеру с рыбкой необходимы 60 Вт для аквафильтра.


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

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


Во второй комнате имеются свободные розетки, но предупреждение на стене гласит, что их максимальная мощность — 40 Вт (а нам, как вы помните, нужны 60 Вт).

Комнаты соответствуют узлам в кластере Kubernetes — это так называемые worker'ы, на которых работают pod'ы.


Сам Kubernetes выступает в роли управляющего океанариумом.

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

Если бы ограничений не существовало, то аквариумы были бы равномерно распределены по всем комнатам.


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

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

Такая экспозиция — это Deployment.


При планировании выставки мы задаем инструкции по созданию каждого ее элемента.

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


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

Его работа — следить за тем, чтобы в выставке всегда было представлено верное число аквариумов. На языке Kubernetes такой стажер, создаваемый вместе с Deployment'ом, называется ReplicaSet.



Посетителям аквариума не важно, смотрят ли они на медузу Fred или медузу Pearl. Все, что они хотят, — это увидеть живую медузу.

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

В мире Kubernetes ReplicaSet следит за тем, чтобы на смену «уставшему» pod'у всегда приходил новый, и их число соответствовало заданному.


Есть еще одно важное соображение при проектировании выставки.

До сих пор (для иллюстрации) мы представляли pod в виде этакой открытой коробки, в которую помещается приложение «в аквариуме».


Это более точное представление pod'а. Со стороны он выглядит как закрытая коробка с привязанными лейблами.

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


Нам нужен способ, позволяющий посетителям заглянуть в pod.

Другими словами, нам нужно организовать окно, через которое они смогут увидеть рыбку внутри.


В Kubernetes за это отвечает сервис (Service). У сервисов несколько различных предназначений, но главное — пробросить порт контейнера наружу, чтобы тот был доступен извне.

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


Сервисы также позволяют pod'ам и контейнерам взаимодействовать друг с другом.

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


Еще нам пригодится так называемая сетевая политика (Network Policy).

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


ConfigMap — это набор переменных или параметров, необходимых pod'у для работы.

Рыбе для жизни необходима корзина с едой. Поэтому она монтируется на контейнер.

Как видно, корзина с ConfigMap'ами может быть прозрачной или непрозрачной. Это связано с тем, что она может содержать как обычные, так и секретные значения.


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

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

Пример типичной схемы с понятиями, изложенными в этой статье.
Пример типичной схемы с понятиями, изложенными в этой статье.

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

P.S. от переводчика

В тему этого материала нельзя не напомнить про легендарный «The Illustrated Children's Guide to Kubernetes».

А также читайте в нашем блоге:

Теги:Kubernetesконтейнеры
Хабы: Блог компании Флант DevOps Микросервисы Kubernetes
Всего голосов 55: ↑53 и ↓2 +51
Просмотры9.4K

Комментарии 1

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Похожие публикации

Лучшие публикации за сутки