Гидроликс спонсировал этот пост.
Kubernetes является мощным инструментом для развертывания, управления и масштабирования программного обеспечения, позволяет организациям принимать, хранить и анализировать данные журнала в масштабе Petabyte. За кулисами предприятия могут использовать шаблон оператора Kubernetes, чтобы расширить Kubernetes и облегчить автоматизация и встроить согласованность в свою инфраструктуру Kubernetes.
Этот пост предоставит высокоуровневый вид операторов Kubernetes, в том числе:
- Что такое оператор Kubernetes?
- Текущее состояние операторов Kubernetes в этой области.
- Почему мы используем шаблон оператора Kubernetes.
Если вы в начале своего путешествия, когда дело доходит до изучения Kubernetes, мы надеемся, что это даст вам лучшее понимание модели оператора. И даже если вы являетесь экспертом в Kubernetes, получая информацию о том, почему и как мы используем шаблон оператора, может быть полезным для планирования и разработки приложений Kubernetes.
Если вы заинтересованы в том, чтобы узнать больше об архитектуре того, как мы создали нашего пользовательского оператора, как мы использовали оператора для решения сложных проблем и того, как оператор влияет практически на каждый аспект жизненного цикла Kubernetes в Hydrolix, ознакомьтесь с «Smooth Operator: как Hydrolix использует оператор Kubernetes».
Что такое оператор Kubernetes?
Проще говоря, оператор — это кусок программного обеспечения, которая расширяет возможности Kubernetes для автоматического управления конкретным приложением. Другими словами, задачи, которые инженеры по надежности сайта или инженеры DevOps обычно могут выполнять вручную — например, развертывание приложения, его настройка, мониторинг его здоровья или обновление его — встроены в программу оператора, которая работает в кластере Kubernetes. Этот оператор непрерывно наблюдает за приложением и вносит коррективы в режиме реального времени, выступая в качестве автономного Sysadmin, который никогда не спит.
Вот как это работает на практике: Kubernetes имеет ориентированный на API взгляд на мир; Все это ресурс, который может быть создан или обновлен через API. Операторы пользуются преимуществами этого, введя новые типы ресурсов, называемые пользовательскими определениями ресурсов (CRD), которые представляют желаемое состояние приложения. Например, мы используем шаблон оператора Kubernetes, чтобы добавить CRD для кластера Kubernetes. Вы, пользователь, можете отправить один файл конфигурации кластера YAML, который описывает вашу идеальную настройку, например, указание того, сколько каждого компонента следует развернуть, какая конфигурация использовать и так далее.
Оператор, работающий в кластере, затем будет работать над примирением реальности, чтобы соответствовать этой спецификации. Он может создать развертывания для различных служб, настраивать конфигурации с предоставленной вами конфигурацией, убедиться, что работает правильное количество стручков и так далее. Если он обнаружит, что кластер уходит от спецификации (скажем, Струк, или кто-то настроил настройку вручную), он будет корректным, чтобы вернуть штат обратно в очередь. Этот цикл проверки и фиксирования известен как согласованная петля.
Полезно сравнить операторов с чем -то вроде диаграмм Helm, общий способ развертывания приложений на Kubernetes с использованием шаблонов. Диаграмма руля — это в основном статический план: вы устанавливаете его, и он создает ресурсы, но после этого контроллеры по умолчанию Kubernetes вступают во владение, и руководитель выходит из картины. Если вы хотите что -то изменить, вы настраиваете значения и запускаете обновление руля, но сам Хелм активно не смотрит ваше приложение.
Напротив, оператор является живым контроллером внутри кластера: он всегда работает, постоянно следя за тем, чтобы приложение было настроено в соответствии с задумами. Операторы также могут обрабатывать сложную логику, которую Helm не может. Например, оператор может организовать упорядоченные развертывание, следя за тем, чтобы стручки базы данных запустились перед приложениями.
Текущее состояние операторов Kubernetes в этой области
Операторы Kubernetes стали стандартным подходом для запуска сложных приложений на Kubernetes. Сегодня вы найдете операторов для всех видов систем: базы данных, таких как PostgreSQL, инструменты больших данных, такие как Kafka или Spark, и системы мониторинга, такие как Prometheus. Апелляция ясна: по мере роста принятия Kubernetes, так и необходимость автоматизировать операции 2 дня — не только начальные развертывания, но и масштабирование, исцеление, обновление и интеграция приложений.
Компании мигрируют из методов статического развертывания в операторы в масштабе. Операторы доказали, что могут справиться с корпоративными шкалами; Они следят за кластерами с тысячами узлов, принимая решения за считанные секунды или меньше. Важно отметить, что они расширяют возможности парадигмы «настроить и забыть». После того, как вы объявите желаемое состояние вашего приложения, оператор непрерывно заботится об остальных. Это становится все более важным, поскольку системы становятся слишком сложными для ручной настройки в производстве.
Наш пользовательский оператор Kubernetes очень сильно соответствует этим современным практикам. Мы создали его, чтобы быть облачным нативным и надежным, используя те же узоры Kubernetes, которые питают других успешных операторов. И это тоже развивается: мы постоянно улучшаем оператора, чтобы добавить больше автоматизации и интеллекта (например, предстоящие функции автоматического мастерства). В экосистеме Kubernetes 2025 года операторы больше не являются нишевой идеей; Они проверенный инструмент для надежности.
Почему мы используем шаблон оператора
Наше развертывание могло быть просто кучей графиков или сценариев руля, но мы решили построить нашего собственного оператора Kubernetes по ряду причин. В основе все сводится к автоматизации, устойчивости и простоте в управлении сложной распределенной системой. Hydrolix не единственная услуга; Это набор из более чем 30 микросервисов (например, проглатывание, запрос и слияние) плюс базы данных и сторонние компоненты. Орчестировать все это вручную было бы склонно к ошибкам и сложно масштабировать. Оператор Kubernetes позволяет нам кодировать все передовые практики и зависимости платформы в единый контроллер, который автоматически заботится о развертывании и повседневной корректировке.
Паттерн оператора позволяет нам кардинально упростить установку и конфигурацию кластеров. Вместо того, чтобы вручную развертывать каждый компонент, необходимо предоставить только одну спецификацию для кластера, а затем оператор запускает все.
Чтобы изменить настройку или масштабировать часть кластера, пользователю просто нужно обновить пользовательский ресурс, а оператор применяет изменения. Эта автоматизация распространяется на такие вещи, как обеспечение правильного порядка операций. Например, если наша услуга Intough зависит от брокера сообщения, оператор может убедиться, что брокер встал первым. Если определенные компоненты работают только при инициализации кластера (например, задание инициализации БД), оператор обрабатывает их, а затем очищает их после этого.
Устойчивость
В распределенной системе в масштабах, в которой мы работаем, все потерпит неудачу. Стручки будут сбой, или узлы могут упасть. Kubernetes само по себе перезапускает стручки, но шаблон «использования оператора» обеспечивает дополнительный уровень устойчивости, контролируя целостное состояние развертывания. Если что -то отклоняется от желаемого состояния, оператор замечает и действует.
Например, предположим, что кто -то случайно удалил проглатывание или изменил конфигурацию для выполнения развертывания. Оператор увидит, что фактическое состояние больше не соответствует спецификации и будет воссоздать стручок или вернуть конфигурацию, чтобы поддерживать согласованность.
Фактически, по умолчанию оператор будет перезаписать ручные изменения в управляемых ресурсах во время его следующего примирного цикла для предотвращения дрейфа. У него также есть флаг игнорирования, который вы можете установить на ресурс, если вы намеренно хотите отказаться от управления оператором. Результатом является система, которая самостоятельно исцеляется и остается верной для предполагаемой конфигурации, гарантируя, что кластер останется в хорошем состоянии.
Простота
Возможно, самая большая победа — насколько проще становится пользовательский опыт. Мы можем генерировать как конфигуратор оператора, так и конфигурация кластера, применить их и вуаля: у нас есть работающий кластер. Вся тяжелая работа-создание сервисов, установка правильных настройки межкомпонента, наблюдение за сбоями-абстрагируется оператором. Это означает, что пользователи могут сосредоточиться на потребностях высокого уровня, таких как «мне нужен кластер с X GB памятью для запросов и y Ingest узлов». Нет необходимости беспокоиться о низкоуровневых объектах Kubernetes, чтобы это произошло.
Короче говоря, оператор превращает процесс развертывания кластера из сложного контрольного списка в универсальную декларативную операцию. Используя оператор, даже не Kubernetes эксперты могут развернуть и запускать нашу платформу, будь то члены команды успеха клиентов, клиентов или других заинтересованных сторон.
Озеро потоковой передачи гидроликс обеспечивает наиболее быстро растущие продукты наблюдения и безопасность отрасли, трансформируя экономику управления высокой кардинальностью, данные журнала высокой размерности. Узнайте больше последних из Hydrolix Trending Stories YouTube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Никита Гуляев — старший инженер по инфраструктуре в Hydrolix. Подробнее от Никиты Гуляевой
