И снова про Kubernetes | OTUS

И снова про Kubernetes

Kubernetes – это runtime для для написания распределенных инфраструктурных приложений с использованием Operator pattern, плюс оркестратор контейнеров.

Ключевые составляющие:

  1. Хранилище описаний объектов.
  2. Модель нотификаций об изменениях как описаний, так и самих объектов.
  3. Готовые простые инструменты для работы с хранилищем и событиями.
  4. Мутноватый, но в целом неплохой stdlib для того, чтобы это было применимо к реальным вещам (запуск контейнеров, модель прав доступа и ограничений ресурсов и т.д.).
  5. Встроенный оркестратор контейнеров, за счет которого появляется возможность через эти механизмы достраивать самого себя.

Иными словами, это state-machine, интегрированная с оркестратором. За счет этого у него появляются свойства, которые по-отдельности отсутствуют как у оркестраторов, так и у state-machine.

CvXb4PyW8AAkf31_1-1801-fafe56.jpg

Из этого сразу вытекает много особенностей:

  1. Этот рантайм нужно уметь запускать и поддерживать, и это не очень тривиально.
  2. Много внутренностей рантайма видны пользователю, хотя никогда не будут использованы (повышенная когнитивная нагрузка).
  3. Достаточно сложный пользовательский интерфейс – интерфейс к рантайму/API, а не к пользовательской функциональности (повышенная когнитивная нагрузка).
  4. Средства программирования под него достаточно скудные – наиболее распространены препроцессоры/шаблонизаторы (повышенная когнитивная нагрузка и вероятность ошибок). Высокоуровневые есть (Operator pattern), но их мало кто "умеет".
  5. Большое число "знающих кубер" умеют лишь работать с его API и писать под него только на препроцессоре.
  6. Чаще всего интерфейс для команд разработки к нему останется на уровне "сложные и непонятные API, завернутые в протекающую абстракцию", либо "обратитесь к своему девопс-инженеру и он вам все сделает".

1_6rrEO8xrzT4cSEDkle9_SA_1-1801-eb8707.png

Из плюсов:

  1. Сейчас много инфраструктурного софта разрабатывается с расчетом того, что будет ставиться в кубер (это минус софту, но плюс куберу).
  2. Есть managed варианты (для других оркестраторов это далеко не всегда так).
  3. Оркестратор мощнее, чем аналоги.
  4. Модульный и его можно расширять, наверное, бесконечно (если вам это нужно и вы это умеете).
  5. Большое сообщество как в плане найма, так и поддержки.
  6. В него нативно интегрируются Открытые стандарты.

Главные условия использования Kubernetes:

1.Оценить в числах экономику использования (в т.ч. продуктивности использования программистами и поддержки) – как затраты, так и преимущества/ 2.Спроектировать платформу, которая на нем будет строиться, или заложить точки расширения для ее строительства в будущем: a) Инфраструктурные слои: - инструменты управления для каждого слоя; - расположение кода для каждого слоя; - способы раскатки каждого слоя; - зоны ответственности команд за тот или иной слой. 3.Доработать процессы разработки продуктовых команд под использование кубера: - интерфейсы к платформе для команд (деплой, отладка, мониторинг логирование). Не путать интерфейсы и инструменты; - процесс разворачивания песочниц для команд; - прочие рабочие процессы команд (обновление приложения в песочнице, отладка приложения в песочнице, хотфиксы приложения в песочнице и т.д.).

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

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

Больше полезных материалов смотрите в моем блоге.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться