Автор | Тан Юнь (Tea Dry), старший инженер-разработчик Alibaba Организация | Чжан Чжуанчжуан (волонтер сообщества Flink)
Аннотация: Эта статья составлена на основе серии прямых трансляций Apache Flink и опубликована Тан Юном (Теа Ган), старшим инженером-разработчиком в Alibaba. Основное содержание следующее:
- Эволюция систем управления контейнерами
- Flink on K8S intro
- Flink о реальном бою K8S
- Demo
Советы: нажмите ниже, чтобы просмотреть больше видео в прямом эфире из серии 1.10~
** Серии 1.10 в прямом эфире: **
ver V Эрика Талант /разработчики/…
В первой части этой статьи будет кратко рассказано об эволюции системы управления контейнерами, во второй части представлено внедрение Flink на K8S, включая принцип планирования режима развертывания кластера и т. д., в третьей части мы поделимся нашим практическим опытом о Flink на K8S в этом году, чтобы представить проблемы, с которыми мы столкнулись, и ямы, на которые мы наступили; последняя часть — это демонстрация, которая продемонстрирует развертывание кластера, отправку задач и т. д.
Эволюция систем управления контейнерами
Во-первых, изучить взаимосвязь между ним и YARN с точки зрения разработчика, не связанного с ядром Kubernetes. Как мы все знаем, Apache Hadoop YARN может быть наиболее широко используемой системой планирования в Китае, основная причина в том, что Hadoop HDFS является наиболее широко используемой системой хранения в Китае или во всей индустрии больших данных. Поэтому основанный на нем YARN естественным образом стал широко используемой системой планирования, включая ранний Hadoop MapReduce. С открытием Framework после YARN 2.0 Spark на YARN и Flink на YARN также можно планировать на YARN.
Конечно, сам YARN имеет определенные ограничения.
- Например, изоляция ресурсов, поскольку YARN разработан на основе Java, его изоляция многих ресурсов несколько ограничена.
- Кроме того, поддержки графического процессора недостаточно.Конечно, текущий YARN 3.0 имеет некоторую поддержку планирования и управления графическим процессором, но предыдущая версия не очень хорошо поддерживала графический процессор.
Так за пределами Apache Foundation появился Kubernetes от CNCF Foundation, основанный на планировании Native Cloud.
С точки зрения разработчика, я думаю, что Kubernetes — это скорее операционная система, которая может многое. Конечно, это также означает, что Kubernetes более сложен, имеет более крутую кривую обучения, и вам нужно понимать множество определений и концепций. Напротив, YARN в основном управляет частью планирования ресурсов, которая намного меньше для всей операционной системы. Конечно, нельзя отрицать, что он также является пионером экологии больших данных. Далее я сосредоточусь на Kubernetes и расскажу об опыте и уроках, которые мы обобщили в ходе эволюции от контейнеров YARN к контейнерам Kubernetes (или POD).
Flink on K8S intro
Развернуть кластер
На приведенном выше рисунке показана блок-схема планирования автономного сеанса Flink на K8S.Синяя пунктирная рамка — это компоненты, работающие внутри кластера Kubernetes, а серая рамка — это команды или компоненты, изначально предоставляемые Kubernetes, включая kubectl и K8S Master. Слева перечислены пять файлов yaml, представленных в официальной документации Flink, которые можно использовать для развертывания простейшего автономного кластера сеансов Flink на K8S.
Команды kubectl, которые необходимо выполнить для запуска кластера, следующие:
kubectl create -f flink-configuration-configmap.yaml
kubectl create -f jobmanager-service.yaml
kubectl create -f jobmanager-deployment.yaml
kubectl create -f taskmanager-deployment.yaml
- во-первых, он будет применяться к K8S Master для создания Flink ConfigMap и предоставления конфигурации, необходимой для запуска кластера Flink в ConfigMap, например: flink-conf.yaml и log4j.properties;
- Второй, создайте службу Flink JobManager и используйте эту службу, чтобы открыть связь между TaskManager и JobManager;
- потом, чтобы создать развертывание Flink Jobmanager для запуска JobMaster, включая компоненты Dispatcher и Resource manager.
- Наконец, Создайте развертывание Flink TaskManager для запуска TaskManager, поскольку в официальном примере Flink taskmanager-deployment.yaml указано 2 копии, поэтому на рисунке показаны 2 узла TM.
Кроме того, существует необязательная операция по созданию службы REST JobManager, чтобы пользователи могли отправлять задания через службу REST.
Выше приведена концептуальная схема кластера автономных сеансов Flink.
отправка домашнего задания
На следующем рисунке показаны подробности процесса отправки задания в кластер Standalone Session с помощью клиента Flink.
Команда для отправки задания с помощью клиента Flink:
./bin/flink run -m : ./examples/streaming/WordCount.jar
Параметры public-node-IP и node-port, требуемые параметром -m, точно соответствуют IP-адресу и порту службы REST, предоставляемой jobmanager-service.yaml. Выполните эту команду, чтобы отправить задание Streaming WordCount в кластер. Этот процесс не имеет ничего общего со средой, в которой работает автономный кластер Flink.Независимо от того, запущен ли он на K8S или на физическом компьютере, процесс отправки заданий одинаков.
Преимущества и недостатки автономной сессии на K8S:
- Преимущество в том, что нет необходимости модифицировать исходный код Flink, достаточно заранее определить некоторые файлы yaml, и кластер можно запускать, а связь между ними вообще не идет через K8S Master;
- Недостатком является то, что ресурсы должны применяться заранее и не могут быть динамически настроены, в то время как Flink на YARN может объявлять ресурсы JM и TM, необходимые кластеру при отправке заданий.
Таким образом, в процессе Flink 1.10 сообщество также является нашим одноклассником, который отвечает за планирование в Ali, Flink на K8S, внесенный всем собственным режимом вычислений, также является Native Kubernetes, который мы суммировали в реальном бою в прошлом. год.
Самая большая разница заключается в том, что когда пользователь отправляет задание через клиент Flink, JobMaster всего кластера динамически запрашивает ресурсы у K8S Master через K8sResourceManager для создания POD, на котором работает TaskManager, а затем TaskManager связывается с JobMaster. Дополнительные сведения о Native Kubernetes см. в статье «Работа Flink в Kubernetes с исходным кодом», опубликованной Ван Яном.
В общем, мы можем использовать K8S точно так же, как YARN, и соответствующие элементы конфигурации должны быть максимально похожи на YARN. Однако для удобства объяснения я буду использовать кластер Standalone Session, чтобы показать его.Некоторые функции, описанные ниже, не были реализованы в Flink 1.10 и, как ожидается, будут завершены в Flink 1.11.
Flink о реальном бою K8S
сбор журналов
Когда мы запускаем задание на Flink на K8S, возникает функциональная проблема, которой нельзя избежать, а именно журнал. Если он работает на YARN, YARN сделает это за нас.Например, когда контейнер завершит работу, YARN соберет журналы и отправит их в HDFS для последующего просмотра. Однако K8S не обеспечивает сбор и хранение журналов, поэтому у нас может быть много вариантов для журналирования (сбора, отображения). В частности, когда задание выходит из POD из-за исключения, журнал будет потерян после выхода из POD, что очень затрудняет устранение неполадок исключения.
Если это YARN, мы можем использовать команду yarn logs -applicationId для просмотра соответствующих журналов. А как же на K8S?
В настоящее время нашей обычной практикой является использование fluentd для сбора журналов, и он использовался в некоторых производственных средах пользователей.
fluentd также является проектом CNCF.Настроив некоторые правила, такие как регулярное сопоставление, журналы *.log, *.out и *.gc в каталоге журналов можно регулярно загружать в HDFS или другие распределенные файловые системы хранения, чтобы Обращается к нашей функции сбора журналов. Это также означает, что во всем POD, помимо TM или JM, нам нужно запустить еще один Container (sidecar), запускающий процесс fluentd.
Конечно, есть и другие способы, например способ, не требующий дополнительных контейнеров: мы можем использовать logback-elasticsearch-appender для отправки логов в Elasticsearch. Принцип реализации заключается в прямой записи журналов в Elasticsearch с помощью метода потока scoket, поддерживаемого REST API Elasticsearch.
Преимущество по сравнению с предыдущим fluentd в том, что нет необходимости запускать другой контейнер для сбора логов, а при сбое соответствующие логи будут напрямую сбрасываться в System.out и System.err. С этой точки зрения использование logback-elasticsearch-appender для записи в Elasticsearch не так уж идеально. В отличие от этого, fluentd может свободно настраивать различные стратегии для сбора необходимой информации журнала.
Metrics
Журналы могут помочь нам наблюдать за работой всей работы, особенно после возникновения проблемы, помочь нам отследить сцену и выполнить некоторые действия по устранению неполадок и анализу. Еще один распространенный и очень важный вопрос — метрики и мониторинг. В отрасли уже существует множество решений для систем мониторинга, таких как Druid, InfluxDB с открытым исходным кодом или коммерческая кластерная версия InfluxDB, Prometheus CNCF или M3 с открытым исходным кодом Uber, который широко используется в Alibaba.
Затем мы напрямую обсуждаем Prometheus здесь, потому что и Prometheus, и Kubernetes принадлежат проектам CNCF и имеют неотъемлемые преимущества в области сбора индикаторов.В какой-то степени Prometheus является стандартной системой мониторинга и сбора данных Kubernetes. Prometheus может выполнять множество функций, не только для подачи сигналов тревоги, но и для установки некоторых правил для регулярного управления с высокой точностью.
Но мы обнаружили проблему в реальном производстве, поддержка горизонтального расширения Prometheus недостаточно хороша. Как вы можете видеть в правой части рисунка выше, так называемая федеративная распределенная архитектура Prometheus на самом деле представляет собой многоуровневую структуру, один слой за другим, а затем узлы над ней отвечают за маршрутизацию и пересылку результатов запроса. на следующий слой. Очевидно, что сколько бы слоев ни было развернуто, чем выше находится узел, тем больше вероятность, что он станет узким местом в производительности, а развертывание всего кластера также весьма хлопотно. Из пользователей, с которыми мы связались, когда масштаб не очень велик, одна точка Prometheus может нести большую часть давления мониторинга, но как только масштаб пользователей очень велик, например, кластер Flink с сотнями узлов, мы Обнаружено, что одна точка Prometheus станет очень большим узким местом в производительности и не сможет удовлетворить потребности мониторинга.
Как мы это делаем?
Сначала мы сделали непротиворечивый хэш метрик разных заданий Flink.Конечно, дело не в том, что метрики задания отправляют только один Prometheus, а в метриках разных масштабов в задании.Сила метрик Flink от больших к малым это: :
- JobManager/TaskManager metrics
- Метрики работы (время контрольных точек, размер и время сбоев)
- task metrics
- Метрики оператора (сколько записей обрабатывается в секунду, количество полученных байтов).
Теперь в планах сделать последовательное хеширование по разным скоупам, отправить их на разные Прометеи, а затем сотрудничать с Таносом (таносом, да, фермером, который пошел сажать дыни после того, как щелкнул пальцами в «Мстителях 3»). Насколько я понимаю, Thanos — это расширенный компонент, который может поддерживать распределенные запросы Prometheus. Таким образом, вся архитектура Prometheus, которая превратилась в контейнер, в котором находится единственный экземпляр Prometheus, будет нести коляску Thanos.
Конечно, вся архитектура приведет к некоторым ограничениям, это ограничение также является причиной того, что мы делаем последовательное хеширование, потому что, когда Thanos и Prometheus развернуты вместе, если есть часть данных метрик, по какой-то причине, это не только в Prometheus A, но и в Prometheus A. В Prometheus B, затем в запросе Thanos, он будет иметь определенные правила, и данные будут оставлены, то есть удалить одно, а другое будет превалировать, что приведет к тому, что строки График показателей в пользовательском интерфейсе будет прерывистым, что приведет к очень недружественному опыту, поэтому нам нужно последовательное хеширование и распределенные запросы через Thanos.
Тем не менее, в реальной работе всего решения все еще есть некоторые проблемы с производительностью.Почему Prometheus на самом деле хорошо работает по многим показателям бизнес-уровня, но на уровне Flink или этой работы он будет оказывать некоторое давление? На самом деле, очень важная причина заключается в том, что изменения показателей работы очень резкие. По сравнению с мониторингом HDFS и Hbase показатели этих компонентов ограничены, а размеры невысоки. Мы используем сценарий запроса, чтобы объяснить концепцию измерения. Например, мы хотим запросить все taskmanager_job_task_buffers_outPoolUsage в задаче задания хоста. Эти условия запроса, то есть, используют теги для запроса и фильтрации, тогда возникает проблема с тегом taskAttempId Flink, который является очень недружественным тегом, потому что это uuid, а taskAttempId изменяется каждый раз при сбое задания.
Если задание продолжает отказывать, а затем сохранять новые теги в Prometheus, если БД, следующей за Prometheus, необходимо построить индекс для тега, тогда давление на индекс будет очень высоким. Например, нагрузка на InfluxDB будет очень высокой, что может привести к тому, что весь ЦП памяти станет недоступным, а результат будет ужасным. Поэтому нам также необходимо использовать сообщество для фильтрации некоторых многомерных тегов на стороне отчета.Заинтересованные студенты могут обратить внимание на FLINK-15110.
представление
■ Производительность сети
Сначала мы представляем производительность сети. Независимо от того, используете ли вы CNI или сетевой плагин Kubernetes, потери производительности сети неизбежно. Более распространенная фланель будет иметь потерю производительности около 30% в некоторых тестовых образцах. Это также не очень стабильно.Когда мы его используем, мы обнаруживаем, что задание часто сообщает PartitionNotFoundException: Partition xx@host not found, то есть нижестоящий не может получить вышестоящий раздел.
Конечно, вы можете увеличить некоторую отказоустойчивость сети на уровне Flink, например, настроить taskmanager.network.request-backoff.max на 300 секунд, по умолчанию 10 секунд, а затем немного увеличить время ожидания akka.
Есть еще проблема, которая вызывает у нас особую головную боль:
Мы обнаружили, что проблема сброса соединения пиром часто возникает во время выполнения задания, поскольку Flink предъявляет высокие требования к стабильности сети при его разработке. Потому что для обеспечения Ровно один раз, если передача данных не удалась, то Flink завершит всю задачу и перезапустится, а затем мы обнаружим, что часто возникает проблема сброса соединения пиром, которая является головной болью.У нас есть несколько решений:
- Не иметь разнородной сетевой среды (старайтесь не подключаться к компьютерным комнатам)
- Машина поставщика облачных услуг настроена на использование нескольких очередей сетевых карт (распределение сетевых прерываний в экземпляре на различные процессоры, тем самым повышая производительность).
- Выбирайте высокопроизводительные сетевые подключаемые модули, предоставляемые поставщиками облачных услуг, например Aliyun's Terway.
- Хост-сеть в обход виртуализированной сети k8s (требует определенной доработки)
Первая проблема, которую необходимо проверить, заключается в том, что кластер не должен иметь гетерогенную сетевую среду, потому что возможно, что хосты Kubernetes находятся в разных компьютерных комнатах, и тогда доступ между компьютерными комнатами вызовет головную боль при обнаружении сетевого джиттера. Затем машина поставщика облачных услуг настраивается с несколькими очередями для сетевых карт.Из-за виртуальной машины ECS ей необходимо потреблять определенное количество ресурсов ЦП для виртуализации сети. Тогда, если сетевая карта не настроена как мульти-очередь, возможно, что сетевая карта использует только 1-2 ядра, и тогда виртуализация израсходует эти 2 ядра, что приведет к потере пакетов, и это сравнение также будет Головная боль, связанная со сбросом соединения из-за проблемы с одноранговым узлом.
Другим решением является выбор высокопроизводительных сетевых подключаемых модулей, предоставляемых поставщиками облачных услуг.Конечно, для этого требуется поддержка поставщиков облачных услуг, таких как Terway от Aliyun.Внешнее описание Terway заключается в том, что он может поддерживать ту же производительность, что и хост-сеть. , а не как фланель принесет некоторую потерю производительности.
Наконец, если Terway нельзя использовать, мы можем использовать хост-сеть, чтобы обойти виртуализированную сеть K8S. Тем не менее, это решение, во-первых, требует некоторых разработок для Flink, а во-вторых, если вы уже использовали Kubernetes, но также используете хост-сеть, в некотором смысле это немного странно и не соответствует стилю K8S. Конечно, у нас также есть некоторые машины, которые не могут использовать Terway, а затем столкнулись с этой головной болью.Мы также предоставляем соответствующие проекты и используем хост-сеть вместо схемы наложения фланели для развертывания.
■ Производительность диска
Далее поговорим о производительности дисков, как уже упоминалось ранее: все виртуализированные вещи принесут некоторую потерю производительности. Для сценария, где RocksDB необходимо читать и записывать на локальный диск, это головная боль, потому что файловая система оверлея будет иметь потерю производительности около 30%.
тогда что нам делать? Мы выбираем один способ — использовать hostPath. Проще говоря, POD может получить доступ к физическому диску хоста. HostPath определен в правой части рисунка выше.Конечно, необходимо убедиться, что пользователь зеркала Flink имеет разрешение на доступ к каталогу хоста, поэтому лучше всего изменить этот каталог на 777 или 775.
Если вы хотите использовать эту функцию, вы можете проверить Flink-15656, который предоставляет шаблон POD, что означает, что вы можете настроить его самостоятельно. Поскольку мы знаем, что K8S имеет много функций и очень сложен, Flink не может сделать адаптацию для каждой функции. Например, вы можете определить hostPath в шаблоне, а затем POD, который вы пишете, может получить доступ к каталогу на основе hostPath в шаблоне.
OOM killed
Убитый ООМ тоже головная боль. Потому что в контейнерной среде при развертывании сервисов нам необходимо предварительно установить ресурсы памяти и ЦП, необходимые для POD, а затем Kubernetes укажет конфигурацию, которая будет применяться для планирования ресурсов на соответствующем узле (хосте). В дополнение к настройке запроса на подачу заявки на ресурсы также будет ограничение — обычно ограничение будет включено — которое будет ограничивать применяемую память и ЦП.
Например, если физическая память узла составляет 64 ГБ, а затем подать заявку на 8 POD с памятью 8 ГБ, кажется, что проблемы нет, но если для этих 8 POD нет ограничений, если каждый из них использует 10 ГБ, это вызовет POD Между ними существует конкуренция за ресурсы, явление такое, что один POD работает нормально, а другой POD внезапно умирает, поэтому необходимо установить лимит памяти. Проблема, связанная с ограничением памяти, заключается в следующем: POD завершает работу по необъяснимым причинам, а затем проверяете событие Kubernetes и обнаруживаете, что POD был уничтожен OOM. Я считаю, что студенты, которые использовали Kubernetes, должны были столкнуться с похожими проблемами.
Как мы это исследовали?
Во-первых, мы можем включить отслеживание нативной памяти на стороне JVM, которую можно регулярно проверять, но мы можем видеть только нативную память, используемую JVM, включая Metaspace, которая не может быть проанализирована не-JVM; универсальный Jemalloc Делайте регулярные дампы памяти с помощью jeprof для анализа.
Честно говоря, мы можем меньше использовать вторую функцию, потому что мы использовали ее на YARN раньше, то есть мы обнаружили, что некоторые задания имеют много памяти, потому что JVM будет ограничивать максимальную память, поэтому она должна быть от нативная сторона.Вопрос,тогда какая нативная проблема,можно использовать Jemalloc+jeprof для анализа памяти. Например, мы сталкивались с тем, что пользователи раньше самостоятельно анализировали файл конфигурации, но им приходилось каждый раз распаковывать его и, наконец, разрывать память.
Конечно, это сценарий, который вызывает OOM, но более вероятно, что RocksDB вызовет OOM, Конечно, если используется бэкэнд состояния, сохраняющий собственную память, такой как RocksDB. Поэтому мы предоставили сообществу функцию в Flink 1.10, которая предназначена для управления памятью RocksDB Параметр state.backend.rocksdb.memory.managed определяет, следует ли управлять ею, и он включен по умолчанию.
Что изображено на картинке ниже?
Это связано с тем, что RocksDB не использует управление памятью. Всего существует 4 состояния: значение, список, карта и окно. Вы можете видеть, что верхняя строка — это использование блочного кеша плюс буфер записи RocksDB, который представляет собой текущее состояние RocksDB — размер всей используемой памяти. Вы можете видеть, что эти 4 в сумме составляют почти 400M.
Причина в том, что текущая версия RocksDB Flink не имеет ограничения на количество состояний: одно состояние — это семейство столбцов, а семейство столбцов будет дополнительно исключительно использовать буфер записи и кэш блоков. По умолчанию семейство столбцов имеет не более двух буферов записи по 64 МБ и одного блочного кэша по 8 МБ. Можно подсчитать, что одно состояние равно 136 МБ, а четыре состояния – 544 МБ.
Если мы включим state.backend.rocksdb.memory.managed, мы увидим, что полилинии кэша блоков, используемые четырьмя состояниями, в основном одинаковы:
Зачем? Это связано с тем, что реализована функция совместного использования кеша. То есть мы сначала создаем LRU-кэш в состоянии, а потом уже неважно какая ситуация будем распределять и планировать память из LRU-кэша, а потом уже с помощью LRU-кэша наименее использовавшуюся память Будет выпущен. Итак, после Flink 1.10 мы говорим, что включение state.backend.rocksdb.memory.managed может решить большинство проблем.
Но, конечно, все возможно, однако в процессе разработки мы обнаружили, что функция совместного использования кеша RocksDB не очень хороша. Это связано с некоторыми деталями реализации, такими как невозможность строгого кэширования.Если вы включите его, вы можете столкнуться со странными проблемами NPE, поэтому в некоторых конкретных сценариях это может быть не очень хорошо. В это время вам может потребоваться увеличить размер taskmanager.memory.task.off-heap.size соответствующим образом, чтобы обеспечить больше места в буфере.
Конечно, сначала нам нужно узнать, сколько памяти он использует. На диаграмме мониторинга памяти, которую мы только что показали, нам нужно открыть параметр state.backend.rocksdb.metrics.block-cache-usage:true После открытия мы можем получить соответствующие индикаторы мониторинга метрик и наблюдать за супериспользованием. .до скольки. Например, менеджер по умолчанию TM с состоянием 1 ГБ имеет размер 294 МБ.
Поэтому, если вы обнаружите, что можете много превысить, например, иногда он достигает 300 МБ или 310 МБ, вы можете рассмотреть параметр конфигурации taskmanager.memory.task.off-heap.size (по умолчанию — 0), чтобы увеличить часть память, например, добавить 64 МБ, что означает открытие дополнительного пространства во внешней куче, применяемой Flink, чтобы создать буфер для RocksDB, чтобы предотвратить его уничтожение OOM. Это решение, которое можно освоить в настоящее время, но фундаментальное решение, возможно, потребуется обработать вместе с сообществом RocksDB.
Мы также надеемся, что если какие-либо одноклассники столкнутся с подобными проблемами, они смогут связаться с нами, и мы также очень рады наблюдать и отслеживать связанные проблемы вместе с вами.
Demo
В последней части демонстрируется демонстрация с использованием hostPath. Большинство файлов yaml такие же, как и в примерах сообщества. Файл развертывания yaml диспетчера задач необходимо изменить, см. ниже:
apiVersion: apps/v1
kind: Deployment
metadata:
name: flink-taskmanager
spec:
replicas: 2
selector:
matchLabels:
app: flink
component: taskmanager
template:
metadata:
labels:
app: flink
component: taskmanager
spec:
containers:
- name: taskmanager
image: reg.docker.alibaba-inc.com/chagan/flink:latest
workingDir: /opt/flink
command: ["/bin/bash", "-c", "$FLINK_HOME/bin/taskmanager.sh start; \
while :;
do
if [[ -f $(find log -name '*taskmanager*.log' -print -quit) ]];
then tail -f -n +1 log/*taskmanager*.log;
fi;
done"]
ports:
- containerPort: 6122
name: rpc
livenessProbe:
tcpSocket:
port: 6122
initialDelaySeconds: 30
periodSeconds: 60
volumeMounts:
- name: flink-config-volume
mountPath: /opt/flink/conf/
- name: state-volume
mountPath: /dump/1/state
securityContext:
runAsUser: 9999 # refers to user _flink_ from official flink image, change if necessary
volumes:
- name: flink-config-volume
configMap:
name: flink-config
items:
- key: flink-conf.yaml
path: flink-conf.yaml
- key: log4j.properties
path: log4j.properties
- name: state-volume
hostPath:
path: /dump/1/state
type: DirectoryOrCreate
вопросы и ответы
1. Как Flink взаимодействует с HDFS в POD K8S?
Его взаимодействие с HDFS очень простое, если в образ введены соответствующие зависимости. То есть вы помещаете файл flink-shaded-hadoop-2-uber-{hadoopVersion}-{flinkVersion}.jar в каталог flink-home/lib, а затем добавляете некоторые конфигурации Hadoop, такие как hdfs-site.xml, core -site.xml и т. д. размещаются в доступном каталоге, и Flink, естественно, доступен. Фактически это то же самое, что и доступ к HDFS на узле кластера, отличного от HDFS.
2. Как Flink на K8S обеспечивает высокую доступность?
На самом деле HA кластера Flink не имеет ничего общего с тем, работает ли он на K8S.В версии сообщества HA кластера Flink требуется участие ZooKeeper. HA требуется ZooKeeper для реализации счетчика идентификаторов контрольных точек, ZooKeeper для реализации остановки контрольных точек и остановки графа потоковой передачи, поэтому ядром высокой доступности становится предоставление службы ZooKeeper поверх Flink на кластере K8S, а кластер ZooKeeper может быть развернут на K8S или физическом машина. В то же время сообщество также пыталось использовать etcd в K8S для поддержки и предоставления набора решений HA.В настоящее время единственным реальным HA промышленного уровня является zookeeper.
3. Flink на K8S и Flink на YARN, что лучше? Как выбрать?
Flink на YARN в настоящее время является относительно зрелой системой, но она немного тяжеловата и не предназначена для использования в облаке. В соответствии с общей тенденцией облачного сервиса у Flink на K8S большое будущее. Flink на YARN — это очень зрелая система в прошлом, но в ней могут отсутствовать некоторые контрмеры в связи с новыми требованиями и новыми вызовами. Например, для многих подробных графических процессоров, создания конвейеров и т. д. концептуально K8S не подходит.
Если вы просто запускаете задание, Flink на YARN может работать стабильно все время и является относительно зрелым, в отличие от Flink на K8S, который является новым, модным и легко повторяемым. Однако некоторые из известных проблем Flink на K8S, такие как крутая кривая обучения, требуют поддержки хорошей командой по эксплуатации и обслуживанию K8S. Кроме того, влияние на производительность, вызванное виртуализацией самого K8S, как было представлено ранее, будь то диск или сеть, трудно избежать определенной потери производительности, конечно, это может быть небольшим недостатком по сравнению с этими недостатками, виртуализация (контейнер), преимущества более очевидны.
4. Как настроен файл /etc/hosts? Я понимаю, что для взаимодействия с HDFS вам необходимо сопоставить IP-адрес узла HDFS и хост с файлом /etc/hosts.
Решается путем монтирования содержимого ConfigMap через Volume и сопоставления с /etc/hosts или использования CoDNS без изменения /etc/hosts.
5. Flink на K8S сложно устранить, как вы это решили?
Прежде всего, в чем разница между устранением неполадок Flink на K8S и Flink на YARN? В основном, могут быть проблемы с самим K8S, что немного хлопотно. K8S можно рассматривать как операционную систему, и в ней может быть много сложных компонентов. YARN — это планировщик ресурсов, реализованный на Java.В настоящее время более вероятно, что хост не сможет вызвать кластерные исключения. Перед лицом возможных проблем с K8S лично мне кажется, что его сложнее проверить, чем YARN. Поскольку он состоит из многих компонентов, при возникновении проблем с разрешением DNS необходимо проверить журнал CoDNS; при наличии проблем с сетью или диском необходимо проверить событие kube; при аварийном выходе POD необходимо чтобы проверить причину выхода POD по событию. Честно говоря, для этого нужен определенный порог, предпочтительно эксплуатация и техническое обслуживание.
Но если вы говорите об устранении неполадок Flink, это то же самое в K8S или YARN.
- Проверьте журнал, чтобы определить, есть ли исключение;
- Если это производительность, вам нужно использовать jstack, чтобы увидеть, где застрял процессор и стек вызовов;
- Если вы обнаружите, что всегда есть риск OOM, или старость всегда заполнена, или GC часто, или Full GC вызывает Stop the world, вам нужен jmap, чтобы проверить, какой блок занимает память, и проанализировать, есть ли утечка памяти.
Эти методы устранения неполадок не зависят от платформы и представляют собой универсальный процесс устранения неполадок. Конечно, следует отметить, что некоторые инструменты отладки могут отсутствовать в образе POD, поэтому рекомендуется создавать приватный образ при сборке Flink на кластере K8S и устанавливать соответствующий инструмент отладки в процессе сборки.