Kubernetes в наши дни становится все более популярным. Неудивительно! Это потрясающая технология, которая очень помогает в развертывании и оркестровке приложений в различных облачных средах, как частных, так и общедоступных.
Я, как человек, много работающий с Apache Ignite, почти ежедневно получаю вопросы о том, как его использовать вместе с Kubernetes. Ignite - это распределенная база данных, поэтому использование Kubernetes для ее развертывания кажется действительно привлекательным. Кроме того, многие компании в настоящее время находятся в процессе перевода всей своей инфраструктуры на Kubernetes, который иногда включает в себя несколько кластеров Ignite, а также десятки приложений, связанных с Ignite.
Я считаю, что Apache Ignite очень удобен для Kubernetes. Во-первых, он, как правило, не зависит от того, куда он бежит. По сути, это набор приложений Java, поэтому, если вы можете запускать JVM в своей среде, вы, скорее всего, запустите Ignite без каких-либо проблем. Во-вторых, Ignite поставляется с образами Docker и подробной документацией по их использованию в Kubernetes: https://apacheignite.readme.io/docs/kubernetes-deployment
В то же время есть несколько подводных камней, характерных для комбинации Ignite + Kubernetes, которыми я хотел бы с вами поделиться. Вот вопросы, на которые я постараюсь ответить:
- Cluster Discovery - как этого добиться в Kubernetes?
- Кластеры без сохранения состояния и с отслеживанием состояния - в чем разница и как она влияет на конфигурацию Kubernetes?
- Толстые клиенты против тонких клиентов - какие из них следует использовать при работе в Kubernetes?
Кластерное открытие
При развертывании Apache Ignite необходимо убедиться, что узлы соединяются друг с другом и образуют кластер. Это делается через протокол обнаружения: https://apacheignite.readme.io/docs/tcpip-discovery
Наиболее распространенный способ настройки обнаружения для Ignite - просто перечислить адреса сокетов серверов, на которых предполагается запускать узлы. Нравится:
Однако в Kubernetes это не работает. В такой динамической среде, где модули можно перемещать между базовыми серверами и где адреса могут изменяться во время перезапуска, невозможно обеспечить статическую конфигурацию.
Чтобы решить эту проблему, Ignite предоставляет Kubernetes IP Finder, который использует сервисный API Kubernetes для поиска в списке запущенных модулей. С помощью этой функции все, что вам нужно, - это указать имя службы, которая будет использоваться для обнаружения. Все узлы, которые работают в одном пространстве имен и указывают на одну и ту же службу, обнаруживают друг друга. Конфигурация становится очень простой:
Кластеры без сохранения состояния и с сохранением состояния
Есть два разных способа использования Ignite: как слой кэширования поверх существующих источников данных (реляционные базы данных и базы данных NoSQL, Hadoop и т. Д.) Или как фактическая база данных. В последнем случае Ignite использует хранилище Native Persistence, которое предоставляется из коробки.
Если Ignite действует как кеш, все данные сохраняются за его пределами, поэтому узлы Ignite непостоянны. Если узел перезагружается, он фактически запускается как новый, без каких-либо данных. Постоянного состояния не существует, и в этом случае мы говорим, что кластер не имеет состояния.
С другой стороны, если Ignite действует как база данных, он полностью отвечает за согласованность и надежность данных. Каждый узел хранит часть данных как в памяти, так и на диске, и в случае перезапуска теряются только данные в памяти. Однако данные на диске должны быть сохранены. Необходимо поддерживать постоянное состояние, поэтому кластер является с отслеживанием состояния.
В мире Kubernetes это означает разные контроллеры, которые вы должны использовать для разных типов кластеров. Вот простое правило:
- Для кластеров без сохранения состояния следует использовать контроллер Развертывание.
- Для кластеров с отслеживанием состояния следует использовать контроллер StatefulSet.
Следование этому правилу поможет вам не усложнить конфигурацию кластеров без сохранения состояния и в то же время убедиться, что кластеры с отслеживанием состояния ведут себя должным образом.
Толстые клиенты против тонких клиентов
Ignite предоставляет различные клиентские коннекторы, которые служат разным целям и совершенно различаются по своей конструкции. Подробно об этом я писал в одной из своих предыдущих статей: https://medium.com/swlh/apache-ignite-client-connectors-variety-41aed7c12361. Особенности среды Kubernetes добавляют дополнительные соображения в эту тему.
Kubernetes не предоставляет отдельные поды напрямую внешнему миру. Вместо этого обычно есть балансировщик нагрузки, который отвечает за прием всех внешних запросов и перенаправление их на модули. И серверные узлы Ignite, и клиентские приложения могут работать на любой стороне балансировщика нагрузки, что влияет на выбор между толстыми и тонкими клиентами.
Обычно вы увидите один из этих трех сценариев.
Сценарий 1. Все в Kubernetes
Под «всем» я подразумеваю как кластер Ignite, так и приложение, взаимодействующее с этим кластером. Они работают в одном пространстве имен одной среды Kubernetes.
В этом случае нет никаких ограничений - вы можете использовать любой тип клиентского коннектора. Если нет особой причины поступить иначе, я бы рекомендовал придерживаться здесь толстых клиентов, поскольку это наиболее эффективный и надежный вариант.
Сценарий 2: кластер вне Kubernetes
Это очень типично для компаний, которые переводят существующие кластеры и приложения с более традиционного развертывания на «голое железо» на развертывание Kubernetes.
Такие компании обычно предпочитают сначала переносить приложения, поскольку они гораздо более динамичны и часто обновляются большим количеством отдельных разработчиков. Это делает правильную оркестровку для приложений гораздо более важной, чем для кластеров Ignite, которые могут работать без сбоев в течение месяцев или даже лет и обычно обслуживаются небольшой группой людей.
Здесь у нас есть существенное ограничение: толстые клиенты не совместимы с этим сценарием. Причина в том, что серверный узел может попытаться создать TCP-соединение с конкретным толстым клиентом. Скорее всего, это не удастся из-за балансировщика нагрузки перед кластером Kubernetes.
Если вы окажетесь в такой ситуации, у вас сейчас есть два варианта:
- Используйте тонкие клиенты или драйверы JDBC / ODBC вместо толстых клиентов.
- Переместите кластер Ignite в среду Kubernetes (эффективно переходя к сценарию 1, который не имеет этих ограничений).
Хорошие новости: сообщество Apache Ignite осознает влияние этого ограничения и в настоящее время работает над улучшениями, которые позволят использовать толстые клиенты в таком развертывании. Следите за обновлениями!
Сценарий 3: приложения вне Kubernetes
Это противоположно предыдущему сценарию - кластер Ignite работает внутри Kubernetes, но приложения находятся за его пределами.
Хотя я видел это пару раз, этот сценарий чрезвычайно редок по сравнению с двумя другими. Если это ваш случай, я настоятельно рекомендую вам рассмотреть возможность переноса приложений в Kubernetes, поскольку вы уже его используете. Вы можете поблагодарить меня позже! 🙂
С точки зрения Ignite, этот тип развертывания допускает только тонкие клиенты и драйверы JDBC / ODBC. В этом сценарии вы не можете использовать толстые клиенты.
Выше я описал основные сложности, с которыми вы можете столкнуться при работе с Apache Ignite в средах Kubernetes.
В качестве следующего шага я предлагаю взглянуть на это репозиторий GitHub, куда я загрузил полные файлы конфигурации, которые можно использовать для развертывания кластера Ignite с отслеживанием состояния в Amazon EKS: https://github.com/vkulichenko/ignite-eks- config
И, конечно же, всегда смело обращайтесь к документации Ignite для получения более подробной информации: https://apacheignite.readme.io/docs/kubernetes-deployment
