Почему вы не должны упускать из виду Kubernetes второго дня

День 2 Kubernetes может быть сложным. Вот почему не стоит игнорировать его последствия. Фото: Alexandr Bormotin / Unsplash.


Принять решение о внедрении Kubernetes (день 0), а затем получить первое развертывание и запустить его (день 1) достаточно сложно. Но есть еще и все последующее, известное как День 2 Kubernetes. Многие организации упускают из виду этот этап, который чреват трудностями и проблемами.

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

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

Вот что я узнал:

Почему решение проблемы Kubernetes второго дня имеет решающее значение


День 2 Kubernetes часто может казаться головоломкой для большинства инженерных команд. Фото Markus Winkler / Unsplash

День 2 Kubernetes охватывает процессы DevOps — мониторинг, тестирование, runbooks и оповещение — которые поддерживают производительность и надежность ваших кластеров. Часто этим операциям не уделяется должного внимания при первоначальном стремлении развернуть Kubernetes как можно быстрее. В конце концов, существует огромное количество терминологии и концепций, которые необходимо изучить, чтобы освоить Kubernetes и просто понять основы, например, как преобразовать файл Docker Compose в производственный сервис K8s.

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

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

С какими проблемами сталкиваются организации, использующие Kubernetes второго дня?


Хотя это зависит от конкретной организации, проблемы второго дня работы Kubernetes можно разделить на следующие пять областей. Фото Rob Wicks / Unsplash

Проблемы, с которыми сталкиваются инженерные организации при управлении K8s, обычно делятся на эти пять областей:

Кривая обучения и передача знаний

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

Кроме того, необходимо не только освоить основной API Kubernetes, но и овладеть инструментальными цепочками для управления K8s. С таким количеством вариантов различных инструментов (Helm или Kustomize? Terraform или Ansible?), ваше решение часто оказывается очень специализированным, что делает болезненным привлечение новых инженеров или потерю знаний, имеющихся у нескольких инженеров в организации.

Видимость

В большинстве случаев, особенно если вы используете AWS, у вас не будет встроенной приборной панели для Kubernetes. Чтобы понять, какие у вас есть ресурсы, вам придется использовать интерфейс командной строки (kubectl) — и хотя некоторым людям это очень удобно, большинству это не подходит, и им нужен визуальный интерфейс.

Интеграция сторонних приложений

Часто проблемы, с которыми вы столкнетесь при использовании Day 2 Kubernetes, технически не являются проблемами Kubernetes. Скорее, головная боль возникает из-за особенностей работы других приложений, взаимодействующих с K8s. Например, если вы хотите развернуть Airflow на Kubernetes, вы можете не знать, как масштабировать базу данных под ним или как масштабировать рабочих, какие метрики визуализировать или какой компромисс между процессором и памятью выбрать.

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

Мониторинг, оповещение и аварийное восстановление

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

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

Безопасность и управление

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

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

Как выглядит решение Kubernetes Day 2


Решение Kubernetes Day 2 должно охватывать как минимум следующие шесть компонентов. Фото Antonio Janeski / Unsplash

По моему опыту, решение Kubernetes Day 2 должно иметь как минимум следующие компоненты:

  • Дашбординг: Визуальный интерфейс для управления ресурсами, для тех, кто не хочет использовать командную строку.
  • Набор интеграционных тестов: Когда вы выводите новую версию пакета на производство, вам нужен способ автоматически развернуть его на тестовых кластерах и выполнить проверку работоспособности, чтобы убедиться, что все работает идеально.
  • Контроль доступа: Должно быть легко установить контроль доступа для вашего кластера из центрального места, а пути аудита должны быть встроены.
  • Наблюдаемость и оповещение: Если что-то пойдет не так, вы должны иметь возможность быстро найти причину проблемы и оповестить нужных людей.
  • Runbooks для аварийного восстановления: При возникновении проблемы вам нужны рунные книги, чтобы любой сотрудник, приехавший по вызову, мог быстро устранить проблему. Что приводит к последнему пункту…
  • Автоматизация: Слишком часто при управлении Kubernetes команды вынуждены изобретать колесо. Когда вы хотите развернуть что-либо на K8s, вы должны быть в состоянии быстро найти все необходимые вам приборные панели, все крючки для масштабирования и интерактивные руководства, которые делают процесс повторяемым.

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

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

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

Оцените статью
devanswers.ru
Добавить комментарий