Основные инструменты Kubernetes в 2021 году

Введение

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

В основе этого списка — мой личный опыт, и чтобы избежать предвзятости, я расскажу и об альтернативных инструментах, чтобы вы могли всё сравнить и принять решение, исходя из своих потребностей. Постараюсь дать информацию сжато и привести источники, чтобы при желании вы могли изучить всё самостоятельно. Описывая инструменты для различных задач разработки ПО, я хотел ответить на вопрос: «Как я могу сделать X в Kubernetes?»

K3D

K3D — мой любимый способ запуска кластеров Kubernetes (K8s) на ноутбуке. Этот инструмент чрезвычайно легковесный и быстрый, и представляет собой обертку вокруг K3S, использующую Docker. Для его запуска нужен только Docker, и задействует он очень мало ресурсов. Единственная проблема в том, что он не полностью соответствует стандартам K8s, но для локальной разработки это не критично, а для тестовых сред можно использовать другие решения. K3D быстрее, чем Kind, но Kind полностью соответствует стандартам.

Похожие инструменты

• K3S для IoT или Edge

• Kind — как полностью совместимый вариант

• MicroK8s

• MiniKube

Krew

Krew — важный инструмент для управления плагинами Kubectl, который необходим каждому пользователю K8s. Не буду подробно останавливаться на более чем 145 доступных плагинах, но вот как минимум kubens и kubectx установить стоит.

Lens

Lens — это IDE для K8s для SRE, Ops и Dev. Он работает с любым дистрибутивом Kubernetes, локально или в облаке. Этот инструмент быстр, прост в использовании и обеспечивает наблюдаемость в реальном времени. Lens позволяет легко и просто управлять множеством кластеров, и если вы оператор кластера, то без него не обойтись.

Похожие инструменты

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

Helm

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

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

Похожие инструменты

• Kustomize — новая и отличная альтернатива Helm, которая использует не шаблонизатор, а механизм наложения, и где есть базовые определения и наложения поверх них.

ArgoCD

Я убежден, что GitOps — это одна из лучших идей последнего десятилетия. При разработке ПО мы должны использовать единый источник истины (SSOT) для отслеживания всех «движущихся частей», необходимых для создания софта, и Git — идеальный инструмент для этого. Суть в том, чтобы иметь Git-репозиторий, содержащий код приложения, а также декларативные описания инфраструктуры (IaC), которые представляют собой желаемое состояние производственной среды, и автоматизированный процесс для приведения желаемой среды в соответствие с описанным состоянием в репозитории.

GitOps: версионный CI/CD поверх декларативной инфраструктуры. Перестаньте скриптовать и начните отгружать.

Келси Хайтауэр

Хотя с помощью Terraform или других инструментов и можно создать инфраструктуру как код (IaC), этого недостаточно, чтобы синхронизировать желаемое состояние в Git с продакшеном. Нужен способ непрерывного мониторинга окружения, чтобы убедиться в отсутствии дрейфа конфигурации. С Terraform придется писать сценарии, которые запускают terraform apply и проверяют, соответствует ли статус состоянию Terraform. Но это утомительно и сложно в сопровождении.

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

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

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

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

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

Похожие инструменты

• Flux — доступна новая улучшенная версия со схожими фичами.

Argo Workflows и Argo Events

Периодически в Kubernetes нужно выполнять пакетные задания или сложные рабочие процессы. Это может быть частью конвейера данных, асинхронных процессов или даже CI/CD. Кроме того, может понадобиться запустить даже управляемые микросервисы, которые реагируют на определенные события, например, загрузку файла или отправку сообщения в очередь. Для всего этого есть Argo Workflows и Argo Events.

Несмотря на то, что это отдельные проекты, как правило их развертывают вместе.

Argo Workflows — это механизм оркестровки, похожий на Apache Airflow, но нативный для Kubernetes. Он использует пользовательские CRD для определения сложных рабочих процессов с помощью шагов или DAG с использованием YAML, что кажется более естественным в K8s. Он имеет приятный интерфейс, механизмы повторных попыток, задания cron, привязку входов и выходов и многое другое. Его можно использовать для оркестровки конвейеров данных, пакетных заданий и многого другого.

Иногда может понадобиться интегрировать пайплайны с асинхронными сервисами, такими как потоковые механизмы (например, Kafka), очереди, вебхуки или сервисы глубокого хранения данных. Например, у вас может быть потребность реагировать на такие события, как загрузка файла на S3. Для подобного используйте Argo Events.

Вместе эти инструменты являются простым и мощным решением для всех нужд пайплайна, включая CI/CD-пайплайны, которые позволят запускать CI/CD-пайплайны нативно в Kubernetes.

Похожие инструменты

• Для ML-пайплайнов используйте Kubeflow — он как раз предназначен для этого.

• Для CI/CD-пайплайнов подойдет Tekton.

Kaniko

Выше я рассказал, как можно запускать CI/CD-пайплайны на базе Kubernetes с помощью рабочих процессов Argo. Одной из распространенных задач является сборка образов Docker, что в Kubernetes обычно утомительно, так как процесс сборки фактически выполняется на самом контейнере, и нужны обходные пути для использования Docker-движка хоста.

Поэтому для создания образов используйте не Docker, а Kaniko. Этот инструмент не зависит от демона Docker и каждую команду в Dockerfile полностью выполняет в пространстве пользователя. Это позволяет создавать образы контейнеров в средах, которые не могут легко или безопасно запустить демон Docker, например, в стандартном кластере Kubernetes. Kaniko устраняет все проблемы, связанные с созданием образов внутри кластера K8s.

Istio

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

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

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

Похожие инструменты

• Linkerd — это более легковесное и, возможно, более быстрое сервисное сито. Оно создано для обеспечения безопасности с нуля, в том числе для таких функций, как включенный по умолчанию mTLS, плоскость данных, построенная на безопасном для памяти языке Rust, и регулярные аудиты безопасности.

• Consul — сервисное сито, созданное для любой среды выполнения и облачного провайдера, поэтому оно отлично подходит для гибридных развертываний с использованием K8s и облачных провайдеров. Это отличный выбор, если не все ваши рабочие нагрузки работают на Kubernetes.

от переводчика: про Istio не раз рассказывали на нашей конференции DevOops. В 2017 году Крэйг Бокс рассказывал, как управлять микросервисами с помощью Kubernetes и Istio, а в 2018 году Антон Вайс выступил с докладом «Тупые сервисы в умных сетях: деплоим как ниндзя при помощи Istio».

Argo Rollouts

Я уже говорил, что вы можете использовать Kubernetes для запуска CI/CD-пайплайна с помощью Argo Workflows или аналогичных инструментов вроде Kaniko для создания образов. Следующий логический шаг — продолжать и делать непрерывное развертывание. В реальном сценарии сделать это чрезвычайно сложно из-за высокого риска, поэтому большинство компаний просто выполняют непрерывную доставку. У них предполагается автоматизация, но при этом они всё апрувят и проверяют вручную — это говорит о том, что команда не может полностью положиться на автоматизацию.

Как же добиться такого доверия системе, чтобы можно было избавиться от всех скриптов и автоматизировать совсем всё — от исходного кода до продакшена? Ответ: наблюдаемость. Нужно сосредоточить ресурсы на метриках и собрать все данные, необходимые для точного отображения состояния вашего приложения. Суть в том, чтобы использовать набор метрик для создания доверия. Если у вас есть все данные в Prometheus, то можно автоматизировать развертывание, так как вы можете автоматизировать постепенное развертывание приложения на основе этих метрик.

Поэтому нужны более продвинутые методы развертывания, чем те, которые K8s предлагает из коробки, а именно Rolling Updates. Нужна прогрессивная доставка с канареечным развертыванием. Мы постепенно направляем трафик на новую версию приложения, ждем, пока будут собраны метрики, анализируем их и сопоставляем с заранее определенными правилами. Если всё в порядке, то увеличиваем трафик; если возникают проблемы — откатываем развертывание.

В случае с Kubernetes для этого можно использовать Argo Rollouts, где предлагаются канареечные релизы и многое другое.

Argo Rollouts — это контроллер Kubernetes и набор CRD, предоставляющий расширенные возможности развертывания, такие как сине-зеленые и канареечные раскатки, канареечный анализ, эксперименты и функции прогрессивной доставки в Kubernetes.

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

Фичи Argo Rollouts:

• Стратегия сине-зеленого обновления.

• Стратегия канареечного обновления.

• Мелкомодульное взвешенное перераспределение трафика.

• Автоматизированные откатки и продвижение или ручное вмешательство.

• Настраиваемые метрические запросы и анализ KPI.

• Интеграция контроллеров на входе: NGINX, ALB.

• Интеграция сервисных сит: Istio, Linkerd, SMI.

• Интеграция провайдеров меток: Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs.

Похожие инструменты

• Istio как сервисное сито для канареечных релизов. Istio — это гораздо больше, чем инструмент постепенной доставки, это полноценное сервисное сито. Istio не автоматизирует развертывание, для этого с Istio может интегрироваться Argo Rollouts.

• Flagger весьма похож на Argo Rollouts и очень хорошо интегрирован с Flux, поэтому если вы используете Flux, подумайте и о Flagger.

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

Crossplane

Crossplane — мой новый любимый инструмент K8s, который очень меня радует, так как привносит в Kubernetes критически важный недостающий элемент: управление сторонними сервисами, как если бы они были ресурсами K8s. Это означает, что вы можете предоставлять базы данных облачных провайдеров вроде AWS RDS или GCP Cloud SQL, как если бы предоставляли базу данных в K8s, используя ресурсы K8s, определенные в YAML.

С Crossplane нет необходимости разделять инфраструктуру и код, используя различные инструменты и методологии. Вы можете определить всё, используя ресурсы K8s. Нет нужды изучать новые инструменты вроде Terraform и держать их отдельно.

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

Crossplane расширяет ваш кластер Kubernetes, предоставляя CRD для любой инфраструктуры или управляемого облачного сервиса. Более того, он позволяет полностью реализовать непрерывное развертывание, поскольку в отличие от других инструментов вроде Terraform, использует существующие возможности K8s — контуры управления для непрерывного наблюдения за вашим кластером и обнаружения любого дрейфа конфигурации, действуя при этом автоматически. Например, если вы определите управляемый экземпляр базы данных и кто-то вручную изменит его, Crossplane автоматически обнаружит это и вернет его к предыдущему значению. Это обеспечивает соблюдение принципов GitOps и «инфраструктуры как кода». Crossplane отлично работает с Argo CD, который следит за исходным кодом, проверяет, что ваш репозиторий кода является единым источником истины и любые изменения в коде распространяются на кластер, а также на внешние облачные сервисы. Без Crossplane реализовать GitOps удалось бы только в собственных сервисах K8s, но не в облачных без отдельного процесса. А с этим инструментом всё реально.

Похожие инструменты

• Terraform — самый известный инструмент IaC, но не нативный для K8s, требует новых навыков и не следит автоматически за дрейфом конфигурации.

• Pulumi — альтернатива Terraform, работающая с использованием языков программирования, которые могут быть протестированы и понятны разработчикам.

Knative

Если вы разрабатываете свои приложения в облаке, то скорее всего использовали некоторые serverless-технологии, например AWS Lambda, которая представляет собой парадигму, управляемую событиями — FaaS.

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

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

Фичи:

• Ориентированный API с абстракциями более высокого уровня для распространенных случаев использования.

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

• Слабо связанные функции позволяют использовать те части, которые вам нужны.

• Подключаемые компоненты позволяют создавать собственные системы регистрации и мониторинга, сети и сервисные сита.

• Knative переносим: используйте его везде, где работает Kubernetes, и не беспокойтесь о привязке к поставщику.

• Идиоматический опыт разработчика, поддерживающий такие общие паттерны, как GitOps, DockerOps, ManualOps.

• Knative можно использовать с Django, Ruby on Rails, Spring и т. д.

Похожие инструменты

• Argo Events предоставляет управляемый событиями механизм рабочих процессов для Kubernetes, который может интегрироваться с облачными механизмами вроде AWS Lambda. Он не является FaaS, но предоставляет архитектуру Kubernetes, управляемую событиями.

• OpenFaas

kyverno

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

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

Политика Kyverno — это набор правил. Каждое правило состоит из условия соответствия, необязательного условия исключения и одного из условий проверки, изменения или генерации. Определение правила может содержать только один дочерний узел validate, mutate или generate.

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

Похожие инструменты

• Open Policy Agent — известный облачный механизм управления на основе политик. Он использует собственный декларативный язык и работает во многих средах, не только в Kubernetes. Он сложнее в управлении, чем Kyverno, но более мощный.

Kubevela

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

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

Ориентированная на приложение, а не на контейнер или оркестратор, Open Application Model [OAM] представляет собой модульный, расширяемый и переносимый дизайн для моделирования развертывания приложений с высокоуровневым, но согласованным API.

Kubevela — это реализация модели OAM. Этот инструмент не зависит от времени выполнения, имеет расширяемость по умолчанию, но, что наиболее важно, ориентирован на приложения. Приложения в Kubevela — объекты первого класса, реализованные как ресурсы Kubernetes. Существует различие между операторами кластера (Platform Team) и разработчиками (Application Team). Операторы кластера управляют кластером и различными средами, определяя компоненты (развертываемые/настраиваемые сущности, которые составляют ваше приложение, например, чарты Helm) и трейты. Разработчики определяют приложения, собирая компоненты и трейты.

KubeVela — это проект песочницы Cloud Native Computing Foundation, и хотя он еще в зачаточном состоянии, он может изменить способ использования Kubernetes в ближайшем будущем, позволяя разработчикам, не являющимся экспертами в Kubernetes, сосредоточиться на приложениях. Но у меня есть некоторые сомнения относительно применимости OAM в реальном мире, поскольку сервисы вроде системных приложений, ML или процессов обработки больших данных, очень зависят от низкоуровневых деталей, которые сложно включить в модель OAM.

Похожие инструменты

• Shipa придерживается аналогичного подхода, позволяя командам разработчиков и платформы работать вместе и легко развертывать приложения в Kubernetes.

• Упростить жизнь разработчика пытается и Ketch, который использует очень простой интерфейс командной строки для развертывания приложений. Проблема в том, что он не следует принципам GitOps, а использует императивный подход, который проще для старта, но сложнее для больших проектов. Рекомендую Ketch для простых приложений или небольших команд, но не для крупных проектов.

Snyk

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

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

Похожие инструменты

• Falco — инструмент обнаружения потоков безопасности во время выполнения для Kubernetes.

DevSpace

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

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

Velero

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

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

SchemaHero

Другим распространенным процессом при разработке ПО является управление эволюцией схемы при использовании реляционных баз данных.

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

Похожие инструменты

• LiquidBase — сложнее в использовании, не является нативным для Kubernetes, но имеет больше возможностей.

Bitnami Sealed Secrets

Я уже рассказал о разных инструментах GitOps, например ArgoCD. Наша цель — хранить все в Git и использовать декларативную природу Kubernetes для синхронизации окружений. Мы только что увидели, как можем (и должны) хранить наш источник истины в Git и поручать автоматизированным процессам обрабатывать изменения конфигурации.

Git плохо подходит для хранения секретные объектов — паролей БД или ключей API. Не стоит хранить секреты в репозитории кода. Одним из распространенных решений является использование внешнего хранилища, например AWS Secret Manager или HashiCorp Vault для хранения секретов. Однако это создает много сложностей, поскольку для работы с секретами требуется отдельный процесс. В идеале хотелось бы иметь возможность безопасно хранить секреты в Git, как и любые другие ресурсы.

Sealed Secrets помогает решить эту проблему и позволяет хранить конфиденциальные данные в Git с помощью надежного шифрования. Bitnami Sealed Secrets интегрируется в Kubernetes, позволяя расшифровывать секреты только контроллеру Kubernetes, запущенному в Kubernetes, и больше никому. Контроллер расшифрует данные и создаст собственные секреты K8s, которые будут надежно сохранены. Это позволяет хранить абсолютно всё в виде кода в репозитории и выполнять непрерывное развертывание без каких-либо внешних зависимостей.

В Sealed Secrets два компонента:

• Контроллер на стороне кластера.

• Утилита на стороне клиента: kubeseal.

Утилита kubeseal использует асимметричную криптографию для шифрования секретов, которые может расшифровать только контроллер. Эти зашифрованные секреты кодируются в ресурсе SealedSecret K8s, который можно хранить в Git.

Похожие инструменты

• SOPS, похожий на Sealed Secrets инструмент.

• AWS Secret Manager

• Vault

Capsule

Многие компании используют мультиарендность, или мультитенантность (multi tenancy​​) для управления разными клиентами. В разработке ПО это распространено, но в Kubernetes подобное реализовать трудно. Пространства имен — отличный способ создания логических разделов кластера в виде изолированных фрагментов. Однако этого недостаточно, чтобы надежно изолировать клиентов — нужно обеспечить соблюдение сетевых политик, квот и многого другого. Можно создавать сетевые политики и правила для каждого пространства имен, но это утомительно и сложно масштабируемо. Кроме того, «арендаторы» не смогут использовать более одного пространства имен, что является большим ограничением.

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

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

Capsule — это инструмент, обеспечивающий встроенную поддержку Kubernetes для нескольких арендаторов в рамках одного кластера. С его помощью можно иметь единый кластер для всех арендаторов. Capsule обеспечит «почти» нативный опыт для арендаторов (с некоторыми незначительными ограничениями), которые смогут создавать несколько пространств имен и использовать кластер так, как если бы он был полностью доступен для них, хотя на самом деле кластер является общим.

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

Политики сети и безопасности, квоты ресурсов, диапазоны лимитов, RBAC и другие политики, определенные на уровне арендатора, автоматически наследуются всеми пространствами имен в арендаторе, подобно иерархическим пространствам имен. После этого пользователи могут свободно управлять своими арендаторами автономно, без вмешательства администратора кластера. Capsule готова к использованию в GitOps, поскольку декларативна и вся конфигурация может быть сохранена в Git.

vCluster

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

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

vCluster использует k3s в качестве API-сервера, что делает виртуальные кластеры легковесными и экономичными; а поскольку кластеры k3s на 100% соответствуют требованиям, то и виртуальные кластеры на 100% соответствуют требованиям. Vclusters сверхлегкие (1 под), потребляют очень мало ресурсов и работают на любом кластере Kubernetes, не требуя привилегированного доступа к базовому кластеру. По сравнению с Capsule, они потребляют немного больше ресурсов, но предлагают большую гибкость, поскольку многоарендный режим является лишь одним из вариантов использования.

Прочие инструменты

• KubeApps — веб-интерфейс для развертывания и управления приложениями в кластерах Kubernetes. У него красивый пользовательский интерфейс, в котором можно просматривать и устанавливать публичные или частные приложения (чарты Helm).

• KubeSphere — это огромный проект со множеством фич и приятным интерфейсом. Он позволяет управлять кластерами K8s, пользователями и приложениями, у него есть магазин приложений, как KubeApps. Он имеет множество интеграций. Я мог бы написать отдельную статью про этот инструмент, но у него есть несколько недостатков. Во-первых, он немного устарел и не поддерживает новейшие практики, например GitOps. Во-вторых, он очень требователен к ресурсам. Рекомендую ознакомиться с этим проектом, особенно если вы предпочитаете использовать пользовательский интерфейс и/или работаете в компании, где используют более традиционные инструменты.

• kube-burner используется для стресс-тестирования. Предоставляет метрики и предупреждения.

• Litmus для хаос-инжиниринга.

• kubewatch — используется для мониторинга, но в основном фокусируется на push-уведомлениях, основанных на событиях Kubernetes, таких как создание или удаление ресурсов. Может интегрироваться с разными инструментами типа Slack.

• BotKube — бот для обмена сообщениями для мониторинга и отладки кластеров Kubernetes. Похож на kubewatch, но поновее и с большим количеством фич.

• Mizu — программа для просмотра и отладки трафика API.

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

Заключение

В этой статье я рассказал о своих любимых инструментах Kubernetes и рассмотрел опенсорсные проекты, которые могут быть включены в любой дистрибутив Kubernetes. Я не брал коммерческие решения, такие как OpenShift или Cloud Providers Add-Ons, поскольку хотел сделать статью общей, но рекомендую изучить предложения вашего поставщика облачных услуг, если вы используете Kubernetes в облаке.

Я хотел показать вам, что в Kubernetes можно делать все то же самое, что и в локальной сети. Больше внимания я уделил менее известным инструментам, которые, как мне кажется, могут иметь большой потенциал, таким как Crossplane, Argo Rollouts или Kubevela. Инструменты, от которых я в восторге, это vCluster, Crossplane и ArgoCD/Workflows.

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

9 сентября (уже послезавтра!) мы поможем Luxoft провести TechFest #5: бесплатный митап из трёх докладов.
А 8-11 ноября сами проведём DevOops 2021: вот это уже целая четырёхдневная конференция (не бесплатная, но и масштаб куда больший, там десятки докладов).

Рады будем увидеть вас и там, и там!