Kubernetes Day-2 Operations — Часть III

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

[Часть I — Управление манифестами, обновление жизненного цикла приложений и управление томами] (https://hackernoon.com/kubernetes-day-2-operations-part-i) и Часть II — Динамические параметры, загрузка кластера Kubernetes и Kubernetes RBAC уже подробно обсуждали некоторые унаследованные проблемы и проблемы безопасности при использовании Kubernetes в производственной среде. Высокая производительность и беспрецедентная масштабируемость — две основные причины, по которым предприятия переходят на Kubernetes.

Тем не менее, простота управления и высокий уровень безопасности не всегда обеспечивают бескомпромиссную производительность в любом масштабе. Часть III этой серии описывает некоторые основные узкие места производительности, с которыми сталкиваются кластеры Kubernetes при масштабной работе.

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

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

Сеть и управление трафиком

Работоспособность и производительность облачного приложения зависят от различных параметров сети и трафика. Эти параметры иногда непредсказуемы и чаще всего выходят из строя. Эти параметры не должны быть проблемой, когда вы находитесь на Netflix, а новый сезон «Ходячих мертвецов» только что вышел.

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

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

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

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

Автомасштабирование Kubernetes

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

Kubernetes не поддерживает автоматическое масштабирование «из коробки», и разработчикам приходится активировать надстройку Kubernetes под названием Metrics Server (и, возможно, другие инструменты). Настройка сервера метрик не должна быть сложной задачей, за исключением того, что у каждого поставщика общедоступного облака есть уникальный набор параметров конфигурации.

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

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

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

Связывание модулей с узлами

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

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

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

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

Чтобы дать вам подсказку, это конфигурация, необходимая для связывания модуля с узлом с возможностями графического процессора. 1: Добавление меток к объектам узла 2: Используйте эти метки в селекторах узлов 3: Пометьте все узлы, у которых есть GPU.

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

Интеграция со службами виртуальных машин (устаревшие)

Когда вы перенесете свои рабочие нагрузки в облако и решите использовать Kubernetes, вы обязательно воспользуетесь одной из стратегий миграции, известной как 6 R. Используете ли вы повторный хостинг, переплатформирование, рефакторинг или другие стратегии, вы можете в определенное время принять решение о сохранении одних рабочих нагрузок на ваших виртуальных машинах, а других — на контейнерах.

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

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

CloudPlex решает проблемы операций Kubernetes второго дня

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

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

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

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

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

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

Вы можете проверить, как CloudPlex упрощает решение этих проблем здесь.

Асад Файзи

Генеральный директор

CloudPlex.io, Inc

asad@cloudplex.io

Также опубликовано [здесь] (https://medium.com/@asad_5112/kubernetes-day-2-operations-part-iii-network-traffic-management-auto-scaling-associating-fec6a4d366ff)