Развертывание, эксплуатация и мониторинг IoTeX кластера с Kubernetes
Kubernetes — это система с открытым исходным кодом для автоматического развертывания, масштабирования и управления контейнерными приложениями. Контейнеризация — это упрощенная альтернатива полной машинной виртуализации (VM), которая включает инкапсуляцию приложения в контейнер с собственной операционной средой. Контейнеризация очень развилась за последние несколько лет и привела к более широкому внедрению Kubernetes в технологической отрасли.
Kubernetes значительно расширяет возможности пользователя по тестированию и моделированию. Если вкратце, он позволяет пользователям расширять свои технические ресурсы за пределами их традиционных границ; например, пользователи могут имитировать блокчейн-кластер с 101 узлом без необходимости владения 101 физическими машинами. Это идеально подходит для быстрого тестирования и создания определенных сред для блокчейн-кластера. Это также особенно полезно для моделирования блокчейн сетей с такими консенсусными механизмами как доказательство доли (PoS) или делегированного доказательства доли (DPO), которые имеют ограниченное число (например, 101) географически распределенных узлов производства/проверки блоков.
Начиная с бета-версии “Epik” тестовой сети, IoTeX начал использовать Kubernetes для развертывания и оптимизации инфраструктуры тестовой сети. В целом, Kubernetes значительно улучшил нашу работу — в этом блоге, мы делимся своим опытом и некоторыми советами по запуску собственных контейнерных приложений и сред на Kubernetes.
Настройка кластера IoTeX на Kubernetes
Начнем с определения двух типов сервисов Kubernetes:
- bootnode service: используется для загрузки всего кластера IoTeX. Это точка входа для любых новых узлов iotex и помогает новым узлам присоединиться к сети P2P. Все узлы идентифицируют друг друга по IP-адресу внутреннего модуля.
- iotex service: выявляет JRPC API из всех iotex узлов. Интерфейс JRPC используется нашим IoTeX Explorer и нашим инструментом инъекции действий.
<table class=”image”><caption align=”bottom”>A new node join network</caption><tr><td><img src=”./joinNetwork.png” alt=”A new node join network”/></td></tr></table>
<table class=”image”><caption align=”bottom”>network</caption><tr><td><img src=”./network.png” alt=”network”/></td></tr></table>
Все конфигурации узлов развертываются через Kubernetes ConfigMap, включая genesis блок. Это позволяет повторно развернуть новый кластер, не дожидаясь создания нового docker image.
<table class=”image”><caption align=”bottom”>our 101 nodes cluster</caption><tr><td><img src=”./101.png” alt=”101 nodes cluster”/></td></tr></table>
Приложения, работающие в Kubernetes Pods, по умолчанию не имеют состояний, что означает, что сохраненные данные из любых приложений не будут доступны после повторного развертывания. Чтобы противодействовать этому, мы используем следующий процесс установки. В нашем сценарии, каждый узел IoTeX будет использовать одну и ту же копию данных (т. е. распределенный реестр), поэтому нет необходимости сохранять данные каждого узла. Поэтому, мы монтируем Kubernetes Persistent Volume только на один узел iotex— в нашем случае мы смонтировали его на наш загрузочный узел. Мы также создаем резервные копии сохраненных данных в S3 и DigitalOcean. Поскольку все узлы, кроме загрузочного, не будут иметь сохраненных данных после повторного развертывания, перед запуском потребуется сначала загрузить резервную копию. Для этого мы используем контейнер init. Этот процесс позволяет перезапустить кластер после сбоя, не беспокоясь о потере предыдущих данных.
Мониторинг кластера
Нетривиально отслеживать состояние 21 узлов, и это становится более сложным с большим количеством узлов. Чтобы обеспечить лучшую наблюдаемость в кластере IoTeX, мы настроили возможности мониторинга в Kubernetes, который состоит из стека записей/реестра, стека метрик и диспетчера предупреждений.
Для стека записей/реестра, мы используем Fluentd + Elastic Search + Kibana + Elastic Search Curator. Fluentd отправляет записи с каждого узла клиенту ElasticSearch, а главный сервер, Elastic Search, индексирует записи, которые могут запрашиваться через Kibana. И наконец, мы используем Elastic Search Curator для очистки устаревших записей.
<table class=”image”><caption align=”bottom”>Refer from <a herf=”https://medium.com/@carlosedp/log-aggregation-with-elasticsearch-fluentd-and-kibana-stack-on-arm64-kubernetes-cluster-516fb64025f9">Log aggregation with ElasticSearch, Fluentd and Kibana stack on ARM64 Kubernetes cluster</a></caption><tr><td><img src=”https://cdn-images-1.medium.com/max/2000/1*eNDJDq_eWIef-XfK4llMRg.png" alt=”network”/></td></tr></table>
Для стека метрик, мы используем оператор Prometheus + Prometheus Operator + Grafana.CoreOS Prometheus Operator предоставляет простой способ настройки Prometheus, работающего в кластере Kubernetes. Мы можем подключить клиент Prometheus узла IoTeX, к серверу Prometheus, просто выявив службу метрик.
<table class=”image”><caption align=”bottom”>Refer from <a herf=”https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html">CoreOS: Prometheus Operator</a></caption><tr><td><img src=”https://coreos.com/operators/prometheus/docs/latest/user-guides/images/architecture.png" alt=”network”/></td></tr></table>
<table class=”image”><caption align=”bottom”>our grafana dashboard</caption><tr><td><img src=”./grafana.png” alt=”our grafana dashboard”/></td></tr></table>
Мы также работаем над созданием оповещений с помощью Prometheus Alert Manager для отправки оповещений нашему инженеру, когда у нас есть аномальные показатели.
Использование Helm для управления несколькими конфигурациями
Использование конфигурации yaml для развертывания различных типов приложений на Kubernetes достаточно просто для одной среды. Однако, при наличии нескольких сред (например, тестовая, промежуточная, рабочая) и различных конфигураций узлов (например, 21 делегат или 101 делегат) пользователи сталкиваются с более высокими накладными расходами и избыточностью для управления различными конфигурациями Kubernetes yaml для одного приложения. Для решения этого вопроса мы используем Helm.
<table class=”image”><caption align=”bottom”>duplicated kube config for different environments</caption><tr><td><img src=”./duplicatex.png” alt=”duplicated kube config for different environments”/></td></tr></table>
Helm — это менеджер пакетов для приложений Kubernetes. Он позволяет нам создавать наш кластер IoTeX в виде пакета диаграмм с версиями и значениями по умолчанию. С Helm нам не нужно управлять дубликатами файлов Kubernetes yaml; нам нужно только управлять меньшим подмножеством конфигураций для разных сред и поворотов, которые перезаписывают значение по умолчанию. Это также упрощает выполнение команды, необходимой для запуска нового кластера IoTeX в одну команду:
```bashhelm install charts/iotex — name iotex```
Helm также позволяет нам легко публиковать диаграммы. В будущем, мы опубликуем нашу IoTeX Helm схему для сообщества, чтобы вы могли настроить IoTeX кластер в течение нескольких минут.
Но это еще не все!
Благодаря мощи Kubernetes и других операционных инструментов, команда разработчиков IoTeX не только экономит время на работе кластера, но и решает проблемы быстрее и итерирует еще быстрее, чем раньше. Мы с нетерпением ждем возможностей поделится с вами другими технические перспективами в будущем — еслиу вас возникнут вопросы, не стесняйтесь и пишите нам на support@iotex.io.
О компании IoTeX
IoTeX — авто-масштабируемая блокчейн инфраструктура, ориентированная на безопасность для Интернета Вещей (IoT). Команда IoTeX состоит из кандидатов наук в области Криптографии, Распределенных Систем и Машинного Обучения, инженеров высшего уровня и опытных разработчиков экосистем. IoTeX разрабатывает несколько собственных инноваций, чтобы продвигать границы блокчейна 3.0, используя архитектуру блокчейн-в-блокчейне для гетерогенных вычислений, молниеносный консенсусный механизм Roll-DPoS и самые облегченные техники сохранения конфиденциальности. IoTeX обеспечивает автономную координацию устройств для массового использования путем “подключения физического мира, блок за блоком”.
Website: https://iotex.io/
Twitter: https://twitter.com/iotex_io
Telegram Announcement Channel: https://t.me/iotexchannel
Telegram Group: https://t.me/IoTeXGroup
Medium: https://medium.com/@iotex
Reddit: https://www.reddit.com/r/IoTeX/
Join us: https://iotex.io/careers
