Команды управления зукипером. Команды управления Apache Kafka: полное руководство для администраторов — Производство и поставка электростанций, Бензиновые и дизельные генераторы от 1 до 100 кВт. Мини ТЭЦ на базе двигателя Стирлинга.

Как работать с топиками в Kafka. Как настроить продюсеров и консьюмеров. Как управлять брокерами и кластером Kafka. Основные команды для мониторинга и диагностики проблем в Kafka.

Содержание

Основные команды для работы с топиками в Apache Kafka

Apache Kafka — это распределенная система обмена сообщениями и потоковой передачи данных. Для эффективного управления Kafka необходимо знать основные команды для работы с топиками. Вот некоторые из наиболее важных:

Создание нового топика

Чтобы создать новый топик в Kafka, используйте следующую команду:

kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic my_topic

Здесь мы создаем топик с именем «my_topic», 1 разделом и коэффициентом репликации 1. Как правильно выбрать количество разделов и коэффициент репликации для топика.

Просмотр списка топиков

Чтобы увидеть список всех топиков в кластере Kafka, выполните:

kafka-topics.sh --list --bootstrap-server localhost:9092

Получение детальной информации о топике

Для просмотра подробной информации о конкретном топике используйте команду:

kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic my_topic

Эта команда покажет количество разделов, коэффициент репликации, расположение лидеров разделов и другие важные параметры топика.

Настройка продюсеров и консьюмеров в Kafka

Продюсеры и консьюмеры — ключевые компоненты для работы с данными в Kafka. Рассмотрим основные команды для их настройки и использования.

Запуск консольного продюсера

Чтобы отправить сообщения в топик с помощью консольного продюсера, выполните:

kafka-console-producer.sh --broker-list localhost:9092 --topic my_topic

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

Запуск консольного консьюмера

Для чтения сообщений из топика используйте консольный консьюмер:

kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic my_topic --from-beginning

Опция —from-beginning указывает читать сообщения с начала топика. Без нее будут читаться только новые сообщения.

Управление брокерами и кластером Kafka

Эффективное управление брокерами и кластером Kafka критически важно для обеспечения надежности и производительности системы. Рассмотрим основные команды для этих задач.

Просмотр информации о брокерах

Чтобы получить информацию о брокерах в кластере, используйте команду:

kafka-broker-api-versions.sh --bootstrap-server localhost:9092

Эта команда покажет список всех брокеров, их идентификаторы и поддерживаемые версии API.

Изменение конфигурации брокера

Для изменения конфигурации брокера в runtime используйте:

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config max.connections=10000

Здесь мы увеличиваем максимальное количество соединений для брокера с ID 0. Какие параметры брокера наиболее критичны для производительности.

Мониторинг и диагностика проблем в Kafka

Мониторинг и своевременная диагностика проблем — ключевые аспекты поддержки Kafka-кластера. Рассмотрим основные инструменты для этих задач.

Проверка состояния потребительской группы

Чтобы проверить состояние потребительской группы, выполните:

kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group

Эта команда покажет информацию о смещениях, отставании и активных членах группы.

Просмотр метрик JMX

Для просмотра метрик JMX брокера используйте инструмент JConsole или jmxterm. Например, чтобы посмотреть количество сообщений в секунду:

jmxterm -l localhost:9999
get -b kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec -a OneMinuteRate

Какие метрики JMX наиболее важны для мониторинга здоровья кластера Kafka.

Оптимизация производительности Kafka

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

Настройка параметров производительности

Для оптимизации производительности Kafka важно правильно настроить следующие параметры:

num.network.threads и num.io.threads для брокеров
batch.size и linger.ms для продюсеров
fetch.min.bytes и fetch.max.wait.ms для консьюмеров

Как подобрать оптимальные значения этих параметров для конкретной нагрузки.

Мониторинг задержек

Для мониторинга задержек в Kafka используйте инструмент kafka-producer-perf-test.sh:

kafka-producer-perf-test.sh --topic test-topic --num-records 1000000 --record-size 1000 --throughput 100000 --producer-props bootstrap.servers=localhost:9092

Эта команда проведет тест производительности, отправив 1 миллион сообщений размером 1KB с максимальной пропускной способностью 100000 сообщений в секунду.

Обеспечение безопасности в Kafka

Безопасность — критически важный аспект при работе с Kafka, особенно в производственной среде. Рассмотрим основные механизмы обеспечения безопасности.

Настройка SSL/TLS шифрования

Для настройки SSL/TLS шифрования в Kafka необходимо:

Создать сертификаты и ключи
Настроить SSL параметры в server.properties брокеров
Настроить SSL параметры для клиентов

Пример настройки SSL для брокера:

ssl.keystore.location=/path/to/kafka.server.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.truststore.location=/path/to/kafka.server.truststore.jks
ssl.truststore.password=test1234
security.inter.broker.protocol=SSL
ssl.client.auth=required

Настройка SASL аутентификации

Для настройки SASL аутентификации в Kafka:

Выберите механизм SASL (PLAIN, SCRAM, GSSAPI)
Настройте SASL параметры в server.properties брокеров
Настройте SASL параметры для клиентов

Пример настройки SASL PLAIN для брокера:

security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=PLAIN
sasl.enabled.mechanisms=PLAIN

Как выбрать оптимальный механизм аутентификации для конкретного сценария использования Kafka.

Резервное копирование и восстановление данных в Kafka

Регулярное резервное копирование и возможность быстрого восстановления данных критически важны для обеспечения надежности Kafka-кластера. Рассмотрим основные подходы к этим задачам.

Создание резервных копий

Для создания резервных копий данных в Kafka можно использовать следующие методы:

Копирование лог-файлов топиков

Использование инструмента MirrorMaker для репликации данных в другой кластер
Применение Kafka Connect для экспорта данных во внешнее хранилище

Пример использования MirrorMaker для создания резервной копии:

kafka-mirror-maker.sh
    --consumer.config consumer.properties
    --producer.config producer.properties
    --whitelist ".*"

Восстановление данных

Для восстановления данных в Kafka можно:

Восстановить лог-файлы топиков из резервной копии
Использовать MirrorMaker для репликации данных из резервного кластера
Применить Kafka Connect для импорта данных из внешнего хранилища

Какой метод резервного копирования и восстановления выбрать в зависимости от объема данных и требований к времени восстановления.

Работа с Kafka в Unix/Linux

Хотелось бы сделать себе заметку (что-то типа cheat-sheet) с командами для работе с Kafka. Сейчас я приведу готовые примеры использования команд на готовых примера можно будет увидеть работу самой кафки.

Установка Kafka скриптов в Unix/Linux

Чтобы использовать скрипты для работы с Кафка, выполним небольшую установку:

$ KAFKA_VERSION=2.12-2.2.1 && \
wget -q -O - https://www-us.apache.org/dist/kafka/2.2.1/kafka_${KAFKA_VERSION}.tgz | (cd /opt; tar -zxvf -) && cd /opt/kafka_${KAFKA_VERSION}

Для простоты использования, можно добавить PATH (в ~/.bashrc):

export KAFKA_VERSION=2.12-2.2.1
export KAFKA_HEAP_OPTS="-Xmx1g -Xms1g -XX:MetaspaceSize=96m -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80"
export PATH="$PATH:/opt/kafka_${KAFKA_VERSION}/bin"

После этого, стоит обновить файл:

$ . ~/.bashrc

Или:

$ source ~/.bashrc

Полезное чтиво:

Установка Kafka в Unix/Linux

Перейдем к работе!

Работа с Kafka в Unix/Linux

Вывести список топиков:

$ kafka-topics.sh --list \
    --zookeeper zookeeper_host:zookeeper_host_port

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Так же, можно использовать:

$ kafka-topics.sh --list \
    --zookeeper $(cat ZooKeeperList.txt)

Где:

ZooKeeperList.txt — это список хостов самого зукипера (zookeeper:port).

Получить информацию о топике:

$ kafka-topics.sh --describe \
     --zookeeper zookeeper_host:zookeeper_host_port \
     --topic test_topic

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Создание топика:

$ kafka-topics.sh --create \
    --zookeeper $(cat ZooKeeperList.txt) \
    --topic test_topic \
    --replication-factor 2 \
    --partitions 3

Вот небольшой скрипт для создания топиков:

ENV=nonprod


# 1: A name for the topic
# 2: A replication factor
# 3: A partition
KAFKA_TOPIC_LIST=(
    "MyKafkaTopic:3:1"
    "MyKafkaTopic2:3:1"
    )


for topic in "${KAFKA_TOPIC_LIST[@]}" ; do
    a_topic=$(echo "$topic"| cut -d ":" -f1)
    a_replication_factor=$(echo "$topic"| cut -d ":" -f2)
    a_partition=$(echo "$topic"| cut -d ":" -f3)

    kafka-topics.sh --create \
        --zookeeper $(cat /opt/kafka_2.12-2.2.1/mskkafkatest-${ENV}_ZooKeeperList.txt) \
        --topic $a_topic \
        --replication-factor $a_replication_factor \
        --partitions $a_partition
done;

Записать в топик меседжы:

$ kafka-console-producer.sh \
--broker-list $(cat BrokersList.txt) \
--producer.config producer.properties \
--topic topic_name_here

Прочитать с топика меседжы:

$ kafka-console-consumer.sh \
    --bootstrap-server $(cat BrokersList.txt) \
    --consumer.config producer.properties \
    --topic topic_name_here \
    --from-beginning

Удалить топик:

$ kafka-topics.sh --delete \
   --zookeeper zookeeper_host:zookeeper_host_port \
   --topic test_topic

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Так, написал небольшой скрипт для удаление:

#--------------
# Delete topics
#--------------
ENV=nonprod


KAFKA_TOPIC_LIST=(
    "MyKafkaTopic2"
    "test"
    "test2"
    )


for topic in "${KAFKA_TOPIC_LIST[@]}" ; do
    echo "Deleting ${topic} ....."
    kafka-topics.sh --delete \
        --zookeeper $(cat ZooKeeperList.txt) \
        -topic $topic
done;

Добавить партицию:

$ kafka-topics.sh --alter \
    --zookeeper zookeeper_host:zookeeper_host_port \
    --topic test_topic \
    --partitions 3

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Посмотреть конфиг для топика:

$ kafka-configs.sh --describe \
      --zookeeper zookeeper_host:zookeeper_host_port \
      --entity-type topics \
      --entity-name test_topic

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Установить время хранения (не рекомендуется) записей в топике:

$ kafka-topics.sh --alter \
    --zookeeper zookeeper_host:zookeeper_host_port \
    --topic test_topic \
    --config retention.ms=1000

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Установить время хранения (современный способ) записей в топике:

$ kafka-configs.sh --alter \
      --zookeeper zookeeper_host:zookeeper_host_port \
      --entity-type topics \
      --entity-name test_topic \
      --add-config retention.ms=1000

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Если вам нужно удалить все сообщения в теме, вы можете использовать данную проперти и задать время хранения. Сначала установите время хранения на очень низкое значение (1000 мс), подождите несколько секунд, а затем верните время хранения обратно к предыдущему значению.

Примечание: Время хранения по умолчанию составляет 24 часа (86400000 миллисекунд).

Можно вернуть все как и было:

$ kafka-topics.sh --alter \
     --zookeeper zookeeper_host:zookeeper_host_port \
     --topic mytopic \
     --delete-config retention.ms

Показать список сообщений для конкретного топика:

$ kafka-console-consumer.sh \
    --zookeeper zookeeper_host:zookeeper_host_port \
    --topic test_topic \
    --from-beginning

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Или:

$ kafka-console-consumer.sh \
    --bootstrap-server $(cat BrokersList.txt) \
    --consumer.config producer.properties \
    --topic jive_invoices_staging \
    --from-beginning

Чтобы просмотреть offset позиции для consumer группы (для каждой из партиций):

$ kafka-consumer-offset-checker.sh \
     --zookeeper zookeeper_host:zookeeper_host_port \
     --group group_ID_here \
     --topic your_topic_here

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Чтобы начать заново (сбросьте смещение на 0):

$ kafka-streams-application-reset.sh \
    --input-topics your_topic_here \
    --application-id group_ID_here \
    --bootstrap-servers bootstrap_host:bootstrap_port

Где:

your_topic_here — Топик.
group_ID_here — ИД группы.
bootstrap_host — Хост.
bootstrap_port — Порт.

Получить самое раннее смещение в топике:

$ kafka-run-class.sh kafka.tools.GetOffsetShell \
       --broker-list localhost:9092 \
       --topic mytopic \
       --time -2

Получить последнее смещение еще в топике:

$ kafka-run-class.sh kafka.tools.GetOffsetShell \
      --broker-list localhost:9092 \
      --topic mytopic \
      --time -1

Получить потребительские смещения (consumer offsets) для топика:

$ kafka-consumer-offset-checker.sh \
     --zookeeper=zookeeper_host:zookeeper_host_port \
     --topic=mytopic \
     --group=my_consumer_group

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Считать из __consumer_offsets:

$ kafka-console-consumer.sh \
      --consumer.config config/consumer.properties \
      --from-beginning \
      --topic __consumer_offsets \
      --zookeeper zookeeper_host:zookeeper_host_port \
      --formatter "kafka.coordinator.GroupMetadataManager\$OffsetsMessageFormatter"

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Вывести список consumer групп:

$ kafka-consumer-groups.sh --list \
     --zookeeper zookeeper_host:zookeeper_host_port

Или:

kafka-consumer-groups.sh --list \
      --new-consumer \
     --bootstrap-server localhost:9092

Просмотр сведений о consumer группе:

$ kafka-consumer-groups.sh --describe \
    --zookeeper zookeeper_host:zookeeper_host_port \
    --group group_name

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Посмотр сообщений в топике:

$ kafkacat -C -b localhost:9092 -t mytopic -p 0 -o -5 -e

Или:

$ kafka-console-consumer.sh \
    --bootstrap-server $(cat BrokersList.txt) \
    --consumer.config producer.properties \
    --topic test2 \
    --from-beginning

Чтобы записать в топик:

$ kafka-console-producer.sh \
    --broker-list $(cat BrokersList.txt) \
    --producer.config producer.properties \
    --topic test2

Запускаем Zookeeper shell:

$ zookeeper-shell.sh \
     zookeeper_host:zookeeper_host_port

Провести перформенс тесты:

$ kafka-producer-perf-test.sh \
  --topic topic_here \
  --num-records 1 \
  --record-size 2048 \
  --throughput -1 \
  --producer.config producer.properties \
  --producer-props \
    acks=1 \
    buffer.memory=67108864 \
    compression.type=none \
    batch.size=8196

Вот и все, статья «Работа с Kafka в Unix/Linux» завершена.

Почему нельзя просто уйти от Zookeeper в Kafka 2.8.0: план миграции

Спустя пару месяцев с выпуска Apache Kafka 2.7.0, Confluent анонсировал новый релиз этой платформы потоковой передачи событий, в котором, наконец, случится долгожданный отказ от Zookeeper. Читайте далее, как это облегчит жизнь администратору Kafka-кластера и разработчику распределенных приложений потоковой аналитики больших данных, а также как подготовить свою Big Data инфраструктуру к таким изменениям.

13 плюсов KIP-500 для администратора и разработчика Big Data

Уже совсем скоро, в марте 2021 года, ожидается новый релиз Apache Kafka 2.8.0 [1], главной фишкой которого будет долгожданный KIP-500 (Kafka Improvement Proposal) по отказу от Zookeeper, как обязательной части Кафка-кластера. Напомним, до сих пор Kafka использует сервис синхронизации распределенных систем Apache ZooKeeper для хранения метаданных, таких как расположение разделов и конфигурация топиков. Вопрос ухода от Зукипер был поднят еще в 2019 году, о чем мы писали здесь.

Удаление Зукипер из Kafka значительно упростит администрирование, благодаря сокращению объема настраиваемых служб и возможности развернуть контроллер и брокер в одной JVM. Кроме того, администратору Big Data кластера больше не придется [2]:

тратить время на изучение, конфигурирование, обновление и поддержку еще одной распределенной системы;
определять количества серверов для ансамбля Зукипер, чтобы сбалансировать емкость чтения и записи;
обеспечивать наличие отдельной конфигурации безопасности для Зукипер, которая отличается от остальной части Kafka-кластера;
обеспечивать совместное использование ансамбля Зукипер между приложениями Kafka и сторонними сервисами;
настраивать таймауты брокера на Зукипер через конфигурации connection.timeout.ms и zookeeper.session.timeout.ms;
изменять конфигурации Зукипер при добавлении новой функциональной возможности, например, для явного разрешения отдельных команд;
периодически перезапускать ансамбль Зукипер в рамках управления исправлениями и обновлениями;
подбирать оптимальный размер дорогих SSD-дисков для каждого сервера ZooKeeper;
настраивать политику для очистки старых данных Зукипер через purgeInterval и autopurge.snapRetainCount;
обеспечивать совместное использование путей к каталогам для журнала транзакций ZooKeeper и каталогов моментальных снимков (snapshot’ов).

С точки зрения разработчика Kafka-приложений при отказе новый релиз этой Big Data платформы принесет следующие преимущества [2]:

повышение скорости обработки данных за счет того, что брокеры будут хранить метаданные локально в журнале и считывать с контроллера только последний набор изменений, аналогично тому, как потребители Kafka могут читать самый конец журнала, а не весь журнал;
отсутствие ограничений на число разделов кластера Kafka – теперь масштабирование будет действительно бесконечным;
устранение причины потери сообщений в случае рассинхронизации Kafka и Зукипер из-за его перезапуска или сбоя.

Как отказаться от Zookeeper на практике: план перехода на Apache Kafka 2.8.0

Чтобы использовать все вышеназванные и другие преимущества отказа от Zookeeper в новом релизе Apache Kafka 2.8.0, необходимо подготовиться к переходу на новую версию. Для этого нужно внести следующие изменения, настроив [3]:

клиенты, сервисы и инструменты администрирования Kafka, о чем мы поговорим далее;
REST Proxy API – перейти с v1 на v2 или v3;
получить ID Кафка-кластера, что пригодится администратору в случае мониторинга, аудита, агрегирования журналов и устранения неполадок. Ранее получить идентификатора кластера можно было из Зукипер с помощью команды zookeeper-shell: zookeeper-shell zookeeper:2181 get /cluster/id. Теперь для этого придется использовать файл журнала брокера или файл metadata.properties. При отсутствии доступа к журналам брокера, можно использовать функцию descriptionCluster() в AdminClient или инструменты администрирования Кафка с включенным ведением журнала на уровне TRACE.

Настройка клиентов, сервисов и инструментов администрирование

Здесь идет речь о клиентских приложениях (потребители и продюссеры), приложения Kafka Streams и ksqlDB, сервисы платформs Confluent (Kafka Connect, Confluent Replicator, Confluent REST Proxy, Confluent Schema Registry, Confluent Control Center или Confluent Metrics Reporter), команды CLI-интерфейса. Все они нуждаются в новой конфигурации, которая указывает, как подключиться к кластеру Кафка. В старых версиях Кафка это делалось через соединение ZooKeeper. В более новых версиях появилась возможность подключаться к брокерам вместо Зукипер. Поэтому в production-развертываниях следует проверить наличие старых клиентов или сервисов, которые настроенные для подключения к Зукипер: zookeeper.connect = zookeeper: 2181.

При переходе на Кафка 2.8.0 рекомендуется выполнить аудит всех клиентских приложений и служб, чтобы заменить вышеуказанную конфигурацию для подключения к брокерам Kafka вместо Зукипер: bootstrap.servers = брокер: 9092.

Также потребуется замена в реестре схем (Schema Registry: вместо конфигурации kafkastore.connection.url = zookeeper: 2181 нужно задать kafkastore.bootstrap.servers = broker: 9092.

Аналогично, в инструментах командной строки вместо аргумента –zookeeper с информацией о подключении Зукипер, например,

kafka-themes –zookeeper zookeeper: 2181 –create –topic test1 –partitions 1 –replication-factor 1,

будет

kafka-themes –bootstrap-server broker: 9092 –create –topic test1 –partitions 1 –replication-factor 1 –command-config

В случае защищенных кластеров с использованием SSL или SASL_SSL, инструменты администрирования требуют дополнительных настроек безопасности для подключения к брокерам, в частности, аргумент –command-config, чтобы указать на файл свойств соединения AdminClient.

Краткий перечень мероприятий по отказу от Зукипер показан далее в таблице.

Действие	С ZooKeeper	Без ZooKeeper
Настройка клиентов и сервисов	zookeeper.connect=zookeeper:2181	bootstrap.servers=broker:9092
Конфигурирование Schema Registry	kafkastore.connection.url=zookeeper:2181	kafkastore.bootstrap.servers=broker:9092
Настройка инструментов администрирования	kafka-topics –zookeeper zookeeper:2181 …	kafka-topics –bootstrap-server broker:9092 … –command-config <properties to connect to brokers>
REST Proxy API	v1	v2 or v3
Получение идентификатора Кафка-кластера (Kafka cluster ID)	zookeeper-shell zookeeper:2181 get /cluster/id	kafka-metadata-quorum or view metadata.properties or confluent cluster describe –url http://broker:8090 –output json

Дополнительно к вышеотмеченным подготовительным мероприятиям по отказу от Зукипер, при развертывании Apache Kafka 2.8.0 администратору кластера нужно сделать следующее [3]:

проверить конфигурации и клиентские инструменты, чтобы определить все параметры и аргументы ZooKeeper;
определить возможные зависимости Зукипер в порядке запуска сервиса. Например, при использовании Docker, следует проверить конфигурацию depends_on, чтобы увидеть, где контейнер ZooKeeper является необходимым условием.
Найти косвенные зависимости ZooKeeper, такие как модули Runbook, которые используют Зукипер в качестве узла перехода для выполнения команд на другом узле.

Что еще нового вас ожидает в релизе Apache Kafka 2.8.0, читайте в нашей свежей статье.

Освойте администрирование кластера Apache Kafka и инструментарий этой платформы для разработки распределенных приложений потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=173081737
https://www.confluent.io/blog/42-ways-zookeeper-removal-improves-kafka/
https://www.confluent.io/blog/how-to-prepare-for-kip-500-kafka-zookeeper-removal-guide/

Как перейти на Apache Kafka без Zookeeper: готовимся к KIP-500 в релизе 2.8.0 | by Nick Komissarenko

13 плюсов KIP-500 для администратора и разработчика Big Data

Уже совсем скоро, в марте 2021 года, ожидается новый релиз Apache Kafka 2.8.0 [1], главной фишкой которого будет долгожданный KIP-500 (Kafka Improvement Proposal) по отказу от Zookeeper, как обязательной части Кафка-кластера. Напомним, до сих пор Kafka использует сервис синхронизации распределенных систем Apache ZooKeeper для хранения метаданных, таких как расположение разделов и конфигурация топиков. Вопрос ухода от Зукипер был поднят еще в 2019 году, о чем мы писали здесь.

тратить время на изучение, конфигурирование, обновление и поддержку еще одной распределенной системы;

определять количества серверов для ансамбля Зукипер, чтобы сбалансировать емкость чтения и записи;

обеспечивать наличие отдельной конфигурации безопасности для Зукипер, которая отличается от остальной части Kafka-кластера; обеспечивать совместное использование ансамбля Зукипер между приложениями Kafka и сторонними сервисами;

настраивать таймауты брокера на Зукипер через конфигурации connection.timeout.ms и zookeeper.session.timeout.ms;

изменять конфигурации Зукипер при добавлении новой функциональной возможности, например, для явного разрешения отдельных команд;

периодически перезапускать ансамбль Зукипер в рамках управления исправлениями и обновлениями;

подбирать оптимальный размер дорогих SSD-дисков для каждого сервера ZooKeeper; настраивать политику для очистки старых данных Зукипер через purgeInterval и autopurge.snapRetainCount;

обеспечивать совместное использование путей к каталогам для журнала транзакций ZooKeeper и каталогов моментальных снимков (snapshot’ов).

С точки зрения разработчика Kafka-приложений при отказе новый релиз этой Big Data платформы принесет следующие преимущества [2]:

повышение скорости обработки данных за счет того, что брокеры будут хранить метаданные локально в журнале и считывать с контроллера только последний набор изменений, аналогично тому, как потребители Kafka могут читать самый конец журнала, а не весь журнал;

отсутствие ограничений на число разделов кластера Kafka — теперь масштабирование будет действительно бесконечным;

устранение причины потери сообщений в случае рассинхронизации Kafka и Зукипер из-за его перезапуска или сбоя.

Как отказаться от Zookeeper на практике: план перехода на Apache Kafka 2.8.0

клиенты, сервисы и инструменты администрирования Kafka, о чем мы поговорим далее; REST Proxy API — перейти с v1 на v2 или v3; получить ID Кафка-кластера, что пригодится администратору в случае мониторинга, аудита, агрегирования журналов и устранения неполадок. Ранее получить идентификатора кластера можно было из Зукипер с помощью команды zookeeper-shell: zookeeper-shell zookeeper:2181 get /cluster/id. Теперь для этого придется использовать файл журнала брокера или файл metadata.properties. При отсутствии доступа к журналам брокера, можно использовать функцию descriptionCluster() в AdminClient или инструменты администрирования Кафка с включенным ведением журнала на уровне TRACE. Настройка клиентов, сервисов и инструментов администрирование

Аналогично, в инструментах командной строки вместо аргумента — zookeeper с информацией о подключении Зукипер, например,

kafka-themes — zookeeper zookeeper: 2181 — create — topic test1 — partitions 1 — replication-factor 1,

будет

kafka-themes — bootstrap-server broker: 9092 — create — topic test1 — partitions 1 — replication-factor 1 — command-config

В случае защищенных кластеров с использованием SSL или SASL_SSL, инструменты администрирования требуют дополнительных настроек безопасности для подключения к брокерам, в частности, аргумент — command-config, чтобы указать на файл свойств соединения AdminClient.

Краткий перечень мероприятий по отказу от Зукипер показан далее в таблице.

Дополнительно к вышеотмеченным подготовительным мероприятиям по отказу от Зукипер, при развертывании Apache Kafka 2.8.0 администратору кластера нужно сделать следующее [3]:

проверить конфигурации и клиентские инструменты, чтобы определить все параметры и аргументы ZooKeeper; определить возможные зависимости Зукипер в порядке запуска сервиса. Например, при использовании Docker, следует проверить конфигурацию depends_on, чтобы увидеть, где контейнер ZooKeeper является необходимым условием. Найти косвенные зависимости ZooKeeper, такие как модули Runbook, которые используют Зукипер в качестве узла перехода для выполнения команд на другом узле.

Apache Kafka для разработчиков

Администрирование кластера Kafka

Источники

1. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=173081737

2. https://www.confluent.io/blog/42-ways-zookeeper-removal-improves-kafka/

3. https://www.confluent.io/blog/how-to-prepare-for-kip-500-kafka-zookeeper-removal-guide/

Шпаргалка по командам кафки. Бложик переехал. На медиум писаться… | by Михаил Чугунков

Бложик переехал. На медиум писаться больше ничего не будет.

За полгода работы с кафкой накопился набор часто используемых команд. А из-за того, что CLI интерфейс кафки совершенно неудобный, держать команды в голове невозможно, и приходится писать очередную шпаргалку.

Больше всего раздражает разделение команд по нескольким утилитам. Получается, что для выполнения одного действия необходимо знать не только аргументы командной строки, но и название конкретной утилиты. А получилось так, потому что админские команды отправляются в кафку через однострочные баш-скрипты, запускающие Scala-классы. Пример содержимого такого скрипта:

$(dirname $0)/kafka-run-class kafka.admin.ConfigCommand “$@”

Поэтому приходится вести заметку с нужными командами.

kafka-consumer-groups --bootstrap-server kafka.dev.big-company.com:9092 --describe --group group.dev

Выводит оффсеты и лаги группы group.dev по всем топикам. Каждая партиция отдельно.

kafka-consumer-groups --bootstrap-server kafka.dev.big-company.com:9092 --reset-offsets --to-offset 340000 --group group.dev --topic actions --execute

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

kafka-consumer-groups --bootstrap-server kafka.dev.big-company.com:9092 --reset-offsets --to-latest --group group.dev — topic actions --execute

Выставляет оффсет топика actions на самое раннее возможное значение. Консьюмеры должны быть выключены.

Для предыдущих двух команд можно указать--all-topics вместо названия топика.

kafka-topics --zookeeper zk.dev.big-company.com --create --replication-factor 2 --partitions 2 --topic actions

Создаёт топик с указанным количеством реплик и партиций.

kafka-topics --zookeeper zk.dev.big-company.com --delete --topic actions

Удаление топика.

kafka-topics --zookeeper zk.dev.big-company.com --list

Выводит список всех топиков.

kafka-topics --zookeeper zk.dev.big-company.com --describe

Выводит всю информацию по топикам: кастомные конфиги, количество реплик и партиций, лидирующую партицию.

kafka-configs --zookeeper zk.dev.big-company.com --describe --entity-type topics --entity-name actions

Выводит кастомные конфиги топика, то есть параметры, которые перегружают основной конфигурационный файл кафки.

kafka-topics.sh --zookeeper zk.dev.big-company.com --alter --topic actions --config segment.bytes=104857600

Выставляет значение segment.bytes для топика actions .

kafka-topics.sh --zookeeper zk.dev.big-company.com --alter --topic actions --delete-config segment.bytes

Удаляет кастомный параметр. Для этого топика будет использоваться параметр из общего конфига.

Отдельной команды для этого нет, поэтому надо хитрить с таймаутом, после которого сообщения удаляются с жёсткого диска.

kafka-topics.sh --zookeeper zk.dev.big-company.com --alter --topic actions --config retention.ms=1000

Ждём 1000 миллисекунд…

kafka-topics.sh --zookeeper zk.dev.big-company.com --alter --topic mytopic --delete-config retention.ms

Работа с Kafka в Unix/Linux » BlogLinux.ru

Установка Kafka скриптов в Unix/Linux

Чтобы использовать скрипты для работы с Кафка, выполним небольшую установку:

$ KAFKA_VERSION=2.12-2.2.1 && 
wget -q -O - https://www-us.apache.org/dist/kafka/2.2.1/kafka_${KAFKA_VERSION}.tgz | (cd /opt; tar -zxvf -) && cd /opt/kafka_${KAFKA_VERSION}

Для простоты использования, можно добавить PATH (в ~/.bashrc):

export KAFKA_VERSION=2.12-2.2.1
export KAFKA_HEAP_OPTS="-Xmx1g -Xms1g -XX:MetaspaceSize=96m -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80"
export PATH="$PATH:/opt/kafka_${KAFKA_VERSION}/bin"

После этого, стоит обновить файл:

$ . ~/.bashrc

Или:

$ source ~/.bashrc

Полезное чтиво:

Установка Kafka в Unix/Linux

Перейдем к работе!

Работа с Kafka в Unix/Linux

Вывести список топиков:

$ kafka-topics.sh --list
--zookeeper zookeeper_host:zookeeper_host_port

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Так же, можно использовать:

$ kafka-topics.sh --list
--zookeeper $(cat ZooKeeperList.txt)

Где:

ZooKeeperList.txt — это список хостов самого зукипера (zookeeper:port).

Получить информацию о топике:

$ kafka-topics.sh --describe
--zookeeper zookeeper_host:zookeeper_host_port
--topic test_topic

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Создание топика:

$ kafka-topics.sh --create
--zookeeper $(cat ZooKeeperList.txt)
--topic test_topic
--replication-factor 2
--partitions 3

Вот небольшой скрипт для создания топиков:

ENV=nonprod
# 1: A name for the topic
# 2: A replication factor
# 3: A partition
KAFKA_TOPIC_LIST=(
"MyKafkaTopic:3:1"
"MyKafkaTopic2:3:1"
)
for topic in "${KAFKA_TOPIC_LIST[@]}" ; do
a_topic=$(echo "$topic"| cut -d ":" -f1)
a_replication_factor=$(echo "$topic"| cut -d ":" -f2)
a_partition=$(echo "$topic"| cut -d ":" -f3)
kafka-topics.sh --create
--zookeeper $(cat /opt/kafka_2.12-2.2.1/mskkafkatest-${ENV}_ZooKeeperList.txt)
--topic $a_topic
--replication-factor $a_replication_factor
--partitions $a_partition
done;

Записать в топик меседжы:

$ kafka-console-producer.sh 
--broker-list $(cat BrokersList.txt) 
--producer.config producer.properties 
--topic topic_name_here

Прочитать с топика меседжы:

$ kafka-console-consumer.sh
--bootstrap-server $(cat BrokersList.txt)
--consumer.config producer.properties
--topic topic_name_here
--from-beginning

Удалить топик:

$ kafka-topics.sh --delete
--zookeeper zookeeper_host:zookeeper_host_port
--topic test_topic

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Так, написал небольшой скрипт для удаление:

#--------------
# Delete topics
#--------------
ENV=nonprod
KAFKA_TOPIC_LIST=(
"MyKafkaTopic2"
"test"
"test2"
)
for topic in "${KAFKA_TOPIC_LIST[@]}" ; do
echo "Deleting ${topic} ....."
kafka-topics.sh --delete
--zookeeper $(cat ZooKeeperList.txt)
-topic $topic
done;

Добавить партицию:

$ kafka-topics.sh --alter
--zookeeper zookeeper_host:zookeeper_host_port
--topic test_topic
--partitions 3

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Посмотреть конфиг для топика:

$ kafka-configs.sh --describe
--zookeeper zookeeper_host:zookeeper_host_port
--entity-type topics
--entity-name test_topic

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Установить время хранения (не рекомендуется) записей в топике:

$ kafka-topics.sh --alter
--zookeeper zookeeper_host:zookeeper_host_port
--topic test_topic
--config retention.ms=1000

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Установить время хранения (современный способ) записей в топике:

$ kafka-configs.sh --alter
--zookeeper zookeeper_host:zookeeper_host_port
--entity-type topics
--entity-name test_topic
--add-config retention.ms=1000

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Примечание: Время хранения по умолчанию составляет 24 часа (86400000 миллисекунд).

Можно вернуть все как и было:

$ kafka-topics.sh --alter
--zookeeper zookeeper_host:zookeeper_host_port
--topic mytopic
--delete-config retention.ms

Показать список сообщений для конкретного топика:

$ kafka-console-consumer.sh
--zookeeper zookeeper_host:zookeeper_host_port
--topic test_topic
--from-beginning

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Или:

$ kafka-console-consumer.sh
--bootstrap-server $(cat BrokersList.txt)
--consumer.config producer.properties
--topic jive_invoices_staging
--from-beginning

Чтобы просмотреть offset позиции для consumer группы (для каждой из партиций):

$ kafka-consumer-offset-checker.sh
--zookeeper zookeeper_host:zookeeper_host_port
--group group_ID_here
--topic yourltopic_here

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Чтобы начать заново (сбросьте смещение на 0):

$ kafka-streams-application-reset.sh
--input-topics yourltopic_here
--application-id group_ID_here
--bootstrap-servers bootstrap_host:bootstrap_port

Где:

yourltopic_here — Топик.
group_ID_here — ИД группы.
bootstrap_host — Хост.
bootstrap_port — Порт.

Получить самое раннее смещение в топике:

$ kafka-run-class.sh kafka.tools.GetOffsetShell
--broker-list localhost:9092
--topic mytopic
--time -2

Получить последнее смещение еще в топике:

$ kafka-run-class.sh kafka.tools.GetOffsetShell
--broker-list localhost:9092
--topic mytopic
--time -1

Получить потребительские смещения (consumer offsets) для топика:

$ kafka-consumer-offset-checker.sh
--zookeeper=zookeeper_host:zookeeper_host_port
--topic=mytopic
--group=my_consumer_group

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Считать из __consumer_offsets:

$ kafka-console-consumer.sh
--consumer.config config/consumer.properties
--from-beginning
--topic __consumer_offsets
--zookeeper zookeeper_host:zookeeper_host_port
--formatter "kafka.coordinator.GroupMetadataManager$OffsetsMessageFormatter"

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Вывести список consumer групп:

$ kafka-consumer-groups.sh --list
--zookeeper zookeeper_host:zookeeper_host_port

Или:

kafka-consumer-groups.sh --list
--new-consumer
--bootstrap-server localhost:9092

Просмотр сведений о consumer группе:

$ kafka-consumer-groups.sh --describe
--zookeeper zookeeper_host:zookeeper_host_port
--group group_name

Где:

zookeeper_host — Хост зукипера, например, — это может быть localhost, 192.168.13.113 и так далее.
zookeeper_host_port — Порт зукипера, например по умолчанию — это 2181-й порт.

Посмотр сообщений в топике:

$ kafkacat -C -b localhost:9092 -t mytopic -p 0 -o -5 -e

Или:

$ kafka-console-consumer.sh
--bootstrap-server $(cat BrokersList.txt)
--consumer.config producer.properties
--topic test2
--from-beginning

Чтобы записать в топик:

$ kafka-console-producer.sh
--broker-list $(cat BrokersList.txt)
--producer.config producer.properties
--topic test2

Запускаем Zookeeper shell:

$ zookeeper-shell.sh
zookeeper_host:zookeeper_host_port

Провести перформенс тесты:

$ kafka-producer-perf-test.sh
--topic topic_here
--num-records 1
--record-size 2048
--throughput -1
--producer.config producer.properties
--producer-props
acks=1
buffer.memory=67108864
compression.type=none
batch.size=8196

Вот и все, статья «Работа с Kafka в Unix/Linux» завершена.

В чем польза ZooKeeper для админов и разработчиков. Семинар в Яндексе

Привет! Меня зовут Андрей Степачев. В конце прошлого года я выступил перед коллегами с небольшим рассказом о том, что такое ZooKeeper, и как его можно использовать. Доклад изначально был рассчитан на широкий круг аудитории и может быть полезен и разработчикам, и админам, желающим разобраться, как все это примерно работает.

Начнем, пожалуй, с истории появления ZooKeeper. Сначала, как известно, в Google написали сервис Chubby для управления своими серверами и их конфигурацией. Заодно решили задачу со взаимными блокировками. Но у Chubby была одна особенность: для захвата локов необходимо открывать объект, потом закрывать. От этого страдала производительность. В Yahoo посчитали, что им нужен инструмент, при помощи которого они могли бы строить различные системы для конфигураций своих кластеров. Именно в этом основная цель ZooKeeper — хранение и управление конфигурациями определенных систем, а локи получились как побочный продукт. В итоге вся эта система была создана для построения различных примитивных синхронизаций клиентским кодом. В самом ZooKeeper явных понятий подобных очередям нет, все это реализуется на стороне клиентских библиотек.

Основа ZooKeeper — виртуальная файловая система, которая состоит из взаимосвязанных узлов, которые представляют собой совмещенное понятие файла и директории. Каждый узел этого дерева может одновременно хранить данные и иметь подчиненные узлы. Помимо этого в системе существует два типа нод: есть так называемые persistent-ноды, которые сохраняются на диск и никогда не пропадают, и есть эфемерные ноды, которые принадлежат какой-то конкретной сессии и существуют, пока существует она.

На картинке буквами Р —обозначены клиенты. Они устанавливают сессии — активные соединения с ZooKeeper-сервером, в рамках которого происходят обмен heartbeat-пакетами. Если в течение одной трети от тайм-аута мы не услышали хартбита, по истечении двух третей тайм-аута, клиентская библиотека присоединится к другому ZooKeeper-серверу, пока сессия на сервере не успела пропасть. Если сессия пропадает, эфемерные ноды (на схеме обозначены синим) пропадают. У них обычно есть атрибут, который указывает, какая из сессий ими владеет. Такие узлы не могут иметь детей, это строго объект, в который можно сохранить какие-то данные, но нельзя сделать зависимые.

Разработчики ZooKeeper посчитали, что очень удобно было бы иметь это все в виде файловой системы.

Вторая базисная для ZooKeeper вещь — это так называемая синхронная реализация записи и FIFO-обработка сообщений. Идея заключается в том, что вся последовательность команд в ZooKeeper проходит строго упорядоченно т.е. данная система поддерживает total ordering.

Все операции в ZooKeeper превращается в эту идемпотентную операцию. Если мы хотим изменить какую-то ноду, то мы создаем запись о том, что мы ее изменили, при этом запоминаем ту версию ноды, которая была и которая будет. За счет этого мы можем много раз получать одно и то же сообщение, при этом мы будем точно знать, в какой момент можно его применить. Соответственно, любые операции на запись осуществляются строго последовательно в одном потоке, в одном сервере (мастере). Есть лидер, который выбирается между несколькими машинками, и только он выполняет все операции на запись. Чтения могут происходить с реплики. При этом у клиента выполняется строгая последовательность его операций. Т.е. если он послал операцию на запись и на чтение, то сначала выполнится запись. Даже несмотря на то, что операцию чтения можно было бы выполнить не блокируясь, операция на чтение будет выполнена только после того как выполнена предыдущая операция на запись. За счет этого можно реализовывать предсказуемые системы асинхронной работы с ZooKeeper. Сама система в основном ориентирована на асинхронную работу. То что клиентские библиотеки реализуют синхронный интерфейс — это для удобства программиста. На самом деле, высокую производительность ZooKeeper обеспечивает именно при асинхронной работе, как обычно и бывает.

Каким образом это все работает? Есть один лидер плюс несколько фолловеров. Изменения применяются с использованием двухфазного коммита. Оновное, на что ориентируется ZooKeeper — это то, что он работает по TСP плюс total ordering. В целом целом протокол ZAB (ZooKeeper Atomic Broadcast) — это упрощенная версия Паксоса, которая, как известно, переживает переупорядочивание сообщений, умеет с этим бороться. ZAB с этим бороться не умеет, он изначально ориентирован на полностью упорядоченный поток событий. Параллельной обработки нет, но часто она и не требуется, потому что система ориентирована больше на чтение, чем на запись.

Например, у нас есть такой кластер, есть клиенты. Если сейчас клиенты сделают чтение они увидят то значение, которое сейчас сейчас видят фолловеры, считают, что сейчас значение у некого поля сейчас 1. Если мы в каком-то клиенте запишем 2, то фолловер выполнит операцию через лидера и получит в результате новое состояние.

Лидеру для того чтобы запись считалась успешной, нужно, чтобы как минимум 2 из 3 машин подтвердили то, что они эти данные надежно сохранили. Представьте, что у нас вот тот фолловер, который с 1, сейчас, например в каком-нибудь Амстердаме или другом удаленном ДЦ. Он отстает от остальных фолловеров. Следовательно, локальные машины уже будут видеть 2, а тот удаленный фолловер, если клиент произведет с него чтение до того, как фолловер успеет догнать мастера, увидит отстающее значение. Для того чтобы ему прочитать правильное значение, нужно послать специальную команду, чтобы ZooKeeper принудительно синхронизировался с мастером. Т.е. как минимум на момент выполнения команды sync будет точно известно, что мы получили состояние достаточно свежее по отношению к мастеру. Это называется slow read — медленное чтение. Обычно мы читаем очень быстро, но если все будут пользоваться медленным чтением, то понятно, что весь кластер будут читать всегда с мастера. Соответственно, масштабирования не будет. Если мы читаем быстро, позволяем себе отставать, то мы можем масштабироваться на чтение довольно хорошо.

Рецепты применения

Управление конфигурацией

Первое и самое основное применение — это управление конфигурацией. Записываем в Zookeper какую-то настройку, например, URL коннекта с базой или просто флажок, который запрещает или разрешает работу какому-то сервису внутри нашего кластера. Соответственно, участники кластера подписываются на раздел с конфигурацией и отслеживают ее модификации.

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

Рандеву

Еще один вариант — так называемое рандеву. Идея заключается в том, что есть некий путь воркеров и дилер, который раздает им задачи.

Мы не знаем, заранее, сколько у нас воркеров, они могут подключаться и отключаться, мы этот процесс не контролируем. Для этого можно создать каталог workers. И когда у нас появляется новый воркер, он регистрирует эфемерную ноду, которая будет сообщать о том, что воркер все еще жив, и, например, свой каталог, куда будут попадать задания для него. Лидер будет отслеживать каталог workers. Он заметит, если один из воркеров отвалится в какой-то момент. Обнаружив это он может, например, перенести задачи из queue к другому воркеру. Таким образом, мы можем построить на ZooKeeper несложную систему обработки заданий.

Блокировки

Допустим, пришел один клиент. Он создает эфемерную ноду. Тут нужно оговориться, что в ZooKeeper помимо обычных есть sequential-ноды. К ним в конце может приписываться некий атомарно растущий сиквенс.

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

Почему не нужно вешать на сам каталог my-lock и ждать когда там все исчезнет? Потому что, если у вас много машин, которые пытаются что-то заблокировать, то когда пропадет lock–0001, у вас будет шторм уведомлений. Мастер будет просто занят рассылкой уведомлений об одном конкретном локе. Поэтому лучше их сцеплять именно таким образом — друг за другом, чтобы они следили только за предыдущей нодой. Они выстраиваются в цепочку.

Когда первый клиент отпускает лок, удаляет эту запись, второй клиент видит это и считает, что теперь он является владельцем лока, т.к. впереди никого нет. За счет сиквенса никто вперед него гарантированно не залезет. Соответственно, если первый клиент придет снова, он создаст ноду уже в конце цепочки.

Производительность

На графике ниже по оси x отображено отношение записи к чтению. Заметно, что с ростом количества операций записи в процентном отношении, производительность сильно проседает.

Это результаты работы в асинхронном режиме. Т.е. операции шлются по 100. Если бы они слались по одной, числа по оси y нужно поделить на 100. На чтение можно расти лучше. В ZooKeeper помимо возможности построить кворум из, скажем, пяти машин, которые будут гарантировать сохранение данных, можно еще делать неголосующие машины, которые работают как репитеры: просто читают события, но сами в записи не участвуют. За счет этого и получается преимущество в записи.

Servers	100% reads	0% reads
13	460k	8k
9	296k	12k
7	257k	14k
5	165k	18k
3	87k	21k

Таблица выше демонстрирует, как добавление серверов влияет на чтение и запись. Видно, что скорость чтения растет вместе с количеством, а если мы увеличиваем кворум на запись, производительность падает.

На картинке ниже можно посмотреть, как ZooKeeper реагирует на различные сбои. Первый случай — выпадение реплики. Второй — выпадение реплики, к которой мы не присоединены.

Падение лидера для зукипера условно критично. При хорошей сети ZooKeeper может восстановить его примерно за 200 мс. Иногда лидер может выбираться и несколько минут. И в этот момент если мы пытаемся захватить lock, любые попытки записи без активного лидера ни к чему не приведут, мы будем вынуждены ждать его появления.

Задержки

^severs / _workers	3	5	7	9
1	776	748	758	711
10	1831	1831	1572	1540
20	2470	2336	1934	1890

Время в таблице выше представлено в наносекундах. Соответственно по скорости чтения ZooKeeper приближается к in-memory-базам. Фактически это такой кэш, который всегда читает из памяти. Вообще у ZooKeeper база данных всегда находится в памяти. Запись происходит примерно так: ZooKeeper пишет лог событий, он в соответствии с настройками тика сбрасывается на диск и периодически система делает снэпшот всей базы. Соответственно, при слишком большой базе или слишком загруженных дисках задержки могут быть сравнимы с тайм-аутом. Этот тест моделирует создание некой конфигурации: у нас есть 1килобайт данных, сначала идет один синхронный create, потом асинхронный delete, все это повторяется 50 000 раз.

Автор: octo47

Источник

Серверу Apache ZooKeeper не удается сформировать кворум в Azure HDInsight

05/20/2020
Чтение занимает 3 мин

В этой статье

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

Симптомы

Оба диспетчера ресурсов переходят в режим ожидания
Узлы имен находятся в режиме ожидания
Не удается выполнить задания Spark, Hive и Yarn или запросы Hive из-за сбоев подключения Zookeeper
Управляющие программы LLAP не запускаются в защищенных кластерах Spark или безопасных интерактивных кластерах Hive

Пример журнала

Вы можете увидеть в логах yarn (/var/log/hadoop-yarn/yarn/yarn-yarn*.log on the headnodes) сообщение об ошибке следующего вида:

2020-05-05 03:17:18.3916720|Lost contact with Zookeeper. Transitioning to standby in 10000 ms if connection is not reestablished.
Message
2020-05-05 03:17:07.7924490|Received RMFatalEvent of type STATE_STORE_FENCED, caused by org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth
...
2020-05-05 03:17:08.3890350|State store operation failed 
2020-05-05 03:17:08.3890350|Transitioning to standby state

Существует множество причин, по которым службы высокого уровня доступности, такие как Yarn, NameNode и Livy, могут выйти из строя.
Обратитесь к журналам, связанным с подключениями Zookeeper
Убедитесь, что эта ошибка возникает систематически (не используйте эти решения для однократно возникающих проблем).
Задания могут временно завершаться со сбоем из-за проблем с подключением Zookeeper

Распространенные причины сбоев Zookeeper

Высокая загрузка ЦП на серверах Zookeeper
- Если в пользовательском интерфейсе Ambari отображается, что ресурсы ЦП на серверах Zookeeper длительное время используются почти на 100 %, то сеансы Zookeeper, открытые в течение этого времени, могут истечь.
Клиенты Zookeeper, которые сообщают о частом истечении времени ожидания
- В журналах диспетчера ресурсов, узла имен и других компонентов будут содержаться сведения о частом окончании времени ожидания подключения клиента.
- Это может привести к потере кворума, частой отработке отказа и другим проблемам.

Проверка состояния Zookeeper

Найдите серверы Zookeeper в файле /etc/hosts или в пользовательском интерфейсе Ambari.
Выполните следующую команду.
- echo stat | nc <ZOOKEEPER_HOST_IP> 2181 (или 2182)
- Порт 2181 является экземпляром Apache Zookeeper.
- Порт 2182 используется службой HDInsight Zookeeper (для обеспечения высокой доступности служб, которые не имеют собственного уровня высокой доступности).
- Если команда не отображает выходные данные, это означает, что серверы Zookeeper не работают.
- Если серверы работают, в результате будут содержаться статические подключения клиентов и другие статистические данные.

Zookeeper version: 3.4.6-8--1, built on 12/05/2019 12:55 GMT
Clients:
 /10.2.0.57:50988[1](queued=0,recved=715,sent=715)
 /10.2.0.57:46632[1](queued=0,recved=138340,sent=138347)
 /10.2.0.34:14688[1](queued=0,recved=264653,sent=353420)
 /10.2.0.52:49680[1](queued=0,recved=134812,sent=134814)
 /10.2.0.57:50614[1](queued=0,recved=19812,sent=19812)
 /10.2.0.56:35034[1](queued=0,recved=2586,sent=2586)
 /10.2.0.52:63982[1](queued=0,recved=72215,sent=72217)
 /10.2.0.57:53024[1](queued=0,recved=19805,sent=19805)
 /10.2.0.57:45126[1](queued=0,recved=19621,sent=19621)
 /10.2.0.56:41270[1](queued=0,recved=1348743,sent=1348788)
 /10.2.0.53:59097[1](queued=0,recved=72215,sent=72217)
 /10.2.0.56:41088[1](queued=0,recved=788,sent=802)
 /10.2.0.34:10246[1](queued=0,recved=19575,sent=19575)
 /10.2.0.56:40944[1](queued=0,recved=717,sent=717)
 /10.2.0.57:45466[1](queued=0,recved=19861,sent=19861)
 /10.2.0.57:59634[0](queued=0,recved=1,sent=0)
 /10.2.0.34:14704[1](queued=0,recved=264622,sent=353355)
 /10.2.0.57:42244[1](queued=0,recved=49245,sent=49248)

Latency min/avg/max: 0/3/14865
Received: 238606078
Sent: 239139381
Connections: 18
Outstanding: 0
Zxid: 0x1004f99be
Mode: follower
Node count: 133212

Пиковая загрузка ЦП наблюдается каждый час.

Войдите на сервер Zookeeper и проверьте файл /etc/crontab.
Если в данный момент выполняются какие-либо ежечасные задания, следует задать время начала для разных серверов Zookeeper.

Удаление старых моментальных снимков

Zookeeper настроен на автоматическую очистку старых моментальных снимков.
По умолчанию сохраняются последние 30 моментальных снимков.
Для управления количеством хранящихся моментальных снимков используется ключ конфигурации autopurge.snapRetainCount. Это свойство находится в следующих файлах:
- /etc/zookeeper/conf/zoo.cfg для Hadoop Zookeeper;
- /etc/hdinsight-zookeeper/conf/zoo.cfg для HDInsight Zookeeper.
Задайте для параметра autopurge.snapRetainCount значение 3 и перезапустите серверы Zookeeper.
- Обновить конфигурацию Hadoop Zookeeper и перезапустить службу можно с помощью Ambari.
- Остановите работу и перезапустите HDInsight Zookeeper вручную.
  - sudo lsof -i :2182 предоставит идентификатор процесса для завершения.
  - sudo python /opt/startup_scripts/startup_hdinsight_zookeeper.py
Не удаляйте моментальные снимки вручную, поскольку это может привести к утере данных.

CancelledKeyException в журнале сервера Zookeeper не требует удаления моментальных снимков.

Это исключение может проявляться на серверах zookeeper (/var/log/zookeeper/zookeeper-zookeeper-* или /var/log/hdinsight-zookeeper/zookeeper* files)
Это исключение обычно означает, что клиент больше не активен и серверу не удается отправить сообщение.
Это исключение также указывает, что клиент Zookeeper завершает сеансы преждевременно.
Определите, имеются ли другие симптомы, описанные в этом документе.

Дальнейшие действия

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

Получите ответы специалистов Azure на сайте поддержки сообщества пользователей Azure.
Подпишитесь на @AzureSupport — официальный канал Microsoft Azure для работы с клиентами. Вступайте в сообщество Azure для получения нужных ресурсов: ответов, поддержки и советов экспертов.
Если вам нужна дополнительная помощь, отправьте запрос в службу поддержки на портале Azure. Выберите Поддержка в строке меню или откройте центр Справка и поддержка. Дополнительные сведения см. в статье Создание запроса на поддержку Azure. Доступ к управлению подписками и поддержкой выставления счетов уже включен в вашу подписку Microsoft Azure, а техническая поддержка предоставляется в рамках одного из планов Службы поддержки Azure.

ZooKeeper CLI — интерфейс командной строки | Учебник Apache Zookeeper

Команды ZooKeeper

ZooKeeper Command Line Interface (CLI) используется для взаимодействия с ансамблем ZooKeeper, который позволяет выполнять простые операции, подобные файлам. Это полезно для отладки.

Для выполнения операций ZooKeeper CLI сначала запустите сервер ZooKeeper, а затем клиент ZooKeeper с помощью «bin / zkCli.sh». После запуска клиента в оболочке введите help, чтобы получить список команд, которые могут быть выполнены клиентом, например:

  [zk: localhost: 2181 (CONNECTED) 0] справка
ZooKeeper -server host: аргументы порта cmd
        подключить хост: порт
        получить путь [смотреть]
        ls path [смотреть]
        установить данные пути [версия]
        rmr путь
        delquota [-n | -b] путь
        покидать
        распечатки вкл | выкл
        создать [-s] [-e] путь к данным acl
        путь статистики [смотреть]
        Закрыть
        ls2 path [смотреть]
        история
        listquota путь
        setAcl путь acl
        getAcl путь
        путь синхронизации
        повторить cmdno
        аутентификация схемы addauth
        удалить путь [версия]
        setquota -n | -b val путь
[zk: localhost: 2181 (ПОДКЛЮЧЕНО) 1]

Отсюда вы можете попробовать несколько команд, чтобы почувствовать этот простой интерфейс командной строки.Сначала начните с ввода команды list, например ls:
.
```
  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 1] ls /
[работник зоопарка]
  
```
Затем создайте новый znode, запустив create / zk_test my_data. Это создает новый znode и связывает строку «my_data» с узлом. Вы должны увидеть:
```
  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 2] создать / zk_test my_data
Создано / zk_test
  
```
Выполните еще одну команду ls /, чтобы увидеть, как выглядит каталог:
```
  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 3] ls /
[zookeeper, zk_test]
  
```
Обратите внимание, что каталог zk_test создан.

Затем убедитесь, что данные были связаны с znode, выполнив команду get, например:

  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 4] get / zk_test
мои данные
cZxid = 0x8
ctime = Пн, 30 ноября, 18:41:06 IST 2015
mZxid = 0x8
mtime = Пн, 30 ноября, 18:41:06 IST 2015
pZxid = 0x8
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 7
numChildren = 0

Мы можем изменить данные, связанные с zk_test, выполнив команду set, например:

  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 5] установить / zk_test мусор
cZxid = 0x8
ctime = Пн, 30 ноября, 18:41:06 IST 2015
mZxid = 0x9
mtime = Пн, 30 ноября, 18:43:06 IST 2015
pZxid = 0x8
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0

Наконец, давайте удалим узел, введя:

  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 6] удалить / zk_test

Другие важные команды Zookeeper

Zookeeper Часы

Часы показывают уведомление при изменении данных указанного znode.Вы можете установить часы только в команде get, например:

  get / path-to-znode [смотреть] 1

Давайте запустим команду часов, например:

  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 7] get / zk_test 1
мои данные
cZxid = 0x8
ctime = Пн, 30 ноября, 18:41:06 IST 2015
mZxid = 0x8
mtime = Пн, 30 ноября, 18:41:06 IST 2015
pZxid = 0x8
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 7
numChildren = 0

Вывод аналогичен команде get, но будет ждать изменений znode в фоновом режиме.

Создать подузел

Вы создаете подчиненный узел таким же образом, как и новый z-узел. Единственная разница в том, что путь дочернего znode также будет иметь родительский путь. Давайте создадим дочерний элемент zk_test znode, как показано ниже:

  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 8] create / zk_test / Child1 «firstchild»
создано / zk_test / Child1
[zk: localhost: 2181 (ПОДКЛЮЧЕНО) 9] create / zk_test / Child2 «secondchild»
создано / zk_test / Child2

Список детей

Теперь, чтобы получить список всех дочерних элементов нашего типа znode ‘zk_test’, как показано ниже:

  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 10] ls / zk_test
[Child1, Child2]

Проверить статус

Метаданные znode содержат такие детали, как отметка времени, номер версии, ACL, длина данных и дочерний znode.Если вы хотите просмотреть метаданные, используйте команду проверки статуса, как показано ниже:

  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 11] stat / zk_test
cZxid = 0x8
ctime = Пн, 30 ноября, 18:41:06 IST 2015
mZxid = 0x8
mtime = Пн, 30 ноября, 18:41:06 IST 2015
pZxid = 0x8
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 7
numChildren = 0

Выйти из

Наконец, чтобы выйти из интерфейса командной строки, введите quit:

  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 12] выйти
Выход...
[[электронная почта защищена] корзина] $

Zookeeper метаданные znode

Используя команду get, мы можем просмотреть данные и метаданные, хранящиеся в нашем новом znode.

  [zk: localhost: 2181 (ПОДКЛЮЧЕНО) 13] get / zk_test
мои данные
cZxid = 0x8
ctime = Пн, 30 ноября, 18:41:06 IST 2015
mZxid = 0x8
mtime = Пн, 30 ноября, 18:41:06 IST 2015
pZxid = 0x8
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 7
numChildren = 0

Давайте рассмотрим возвращаемые данные и метаданные:

my_data : Эта строка текста — данные, которые мы сохранили в znode.
cZxid = 0x8 : zxid (идентификатор транзакции ZooKeeper) изменения, которое привело к созданию этого znode.
ctime = Mon Nov 30 18:41:06 IST 2015 : время, когда был создан этот znode.
mZxid = 0x8 : zxid изменения, которое последним изменило этот znode.
mtime = Mon Nov 30 18:41:06 IST 2015 : время последнего изменения этого znode.
pZxid = 0x8 : zxid изменения, которое последним изменило дочерние элементы этого znode.
cversion = 0 : количество изменений дочерних элементов этого znode.
dataVersion = 0 : количество изменений в данных этого znode.
aclVersion = 0 : количество изменений в ACL этого znode.
ephemeralOwner = 0x0 : идентификатор сеанса владельца этого znode, если znode является эфемерным узлом. Если это не эфемерный узел, он будет равен нулю.
dataLength = 7 : длина поля данных этого znode.
numChildren = 0 : количество потомков этого узла.

сливающихся местных служб zookeeper start

сливающихся местных служб zookeeper start | Конфлюентная документация

Дом
Справочник команд интерфейса командной строки Confluent
сливной местный
сливающиеся местные услуги
сливные местные службы zookeeper

Важно

Конфлюентные локальные команды предназначены для одноузловой среды разработки и не подходят для производственной среды.Производимые данные являются временными и предназначены для временный. Для рабочих процессов, готовых к работе, см. Confluent Platform.

Описание

Запустите Apache ZooKeeper ™.

 сливающиеся локальные службы zookeeper start [флаги]

Подсказка

Вы должны экспортировать путь как переменную среды для каждого сеанса терминала или установить путь к своей платформе Confluent. установка в вашем профиле оболочки. Например:

 cat ~ / .bash_profile
экспорт CONFLUENT_HOME = <путь-к-конфлюенту>
экспорт PATH = "$ {CONFLUENT_HOME} / bin: $ PATH"

Флаги

 -c, --config string Настройте Apache ZooKeeper ™ с помощью определенного файла свойств.

Глобальные флаги

 -h, --help Показать справку по этой команде.
-v, --verbose count Увеличить уровень детализации (-v для предупреждения, -vv для информации, -vvv для отладки, -vvvv для трассировки).

© Авторские права , Confluent, Inc. Политика конфиденциальности | Положения и условия.Apache, Apache Kafka, Kafka и логотип Kafka являются товарными знаками Фонд программного обеспечения Apache. Все остальные товарные знаки, знаки обслуживания и авторские права являются собственность их владельцев.

Подключиться к Apache ZooKeeper с помощью командной строки

zkCli.sh — это утилита для подключения к локальной или удаленной службе ZooKeeper и выполнения некоторых команд. В этой статье описывается, как можно использовать zkCli.sh для подключения к кластерам в Instaclustr. В этой статье мы предполагаем, что ваш кластер был правильно настроен и подготовлен, как показано в нашем предыдущем руководстве «Создание кластера».

Содержание

Предварительные требования

Вам также потребуются двоичные файлы ZooKeeper, которые можно загрузить с https://zookeeper.apache.org/releases.html. Мы рекомендуем версию двоичных файлов ZooKeeper, соответствующую вашему кластеру ZooKeeper.Вам не нужно устанавливать после загрузки и распаковки.

Общедоступный IP-адрес вашего компьютера должен быть добавлен к ZooKeeper Allowed Addresses на вкладке Settings вашего кластера в консоли Instaclustr (см. Эту статью поддержки).

Имя пользователя, пароль и файл сертификата можно найти на странице Connection Info вашего кластера. Файлы сертификатов необходимы для подключения к вашему кластеру с помощью SSL.

Аутентификация пользователя

Apache ZooKeeper не применяет аутентификацию.Пользователи всегда могут подключиться к серверам ZooKeeper как «мировой» пользователь. Однако доступ к данным (znodes) может быть ограничен ACL, которые связаны с аутентифицированным пользователем. Мы предоставляем пользователя по умолчанию, которого вы можете использовать при подключении к серверам ZooKeeper. Если вы решите это сделать, создайте файл, содержащий учетные данные (например, jaas.conf) со следующим содержимым

Клиент { org.apache.zookeeper.server.auth.DigestLoginModule требуется username = «iczookeeper» пароль = «<пароль>«; };

Клиент {

орг.apache.zookeeper.server.auth.DigestLoginModule требуется

username = «iczookeeper»

password = «<пароль>«;

};

и установите переменную среды перед подключением, как описано в следующих разделах.

`Подключение к Instaclustr без SSL`

Если в вашем кластере не включено шифрование, вы можете подключиться к нему с помощью zkCli.sh без SSL.

Для Mac / Linux откройте терминал и используйте следующую команду для подключения к кластеру.

bin / zkCli.sh -server : 2181

bin / zkCli.sh -server : 2181

den Если вы установите учетные данные следующая переменная среды.

export CLIENT_JVMFLAGS = "- Djava.security.auth.login.config = jaas.conf"

экспорт CLIENT_JVMFLAGS = "- Djava.security.auth.login.config = 9262

60 Connecting в Instaclustr с SSL Если в вашем кластере включено шифрование, SSL необходим для подключения к кластеру, и вам необходимо получить доверенный магазин.jks из сертификата кластера.
 Для Mac / Linux: откройте терминал и с помощью следующей команды установите переменную среды.
 экспорт CLIENT_JVMFLAGS = "
-Dzookeeper.clientCnxnSocket = org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure = true
-Dzookeeper.ssl.trustStore.location = truststore.jks
-Dzookeeper.ssl.trustStore.password = instaclustr "
 bin / zkCli.sh -server : 2182
 экспорт CLIENT_JVMFLAGS ="
 -Dzookeeper.clientCnxnSocket = org.apache.zookeeper.ClientCnxnSocketNetty
 -Dzookeeper.client.secure = true
 -Dzookeeper.ssl.trustStore.location = truststore.jks
 -Dzookeeper.ssl.trustStore.passrword
 bin / zkCli.sh -server : 2182
 Если вы добавите следующие учетные данные переменная перед подключением
 экспорт CLIENT_JVMFLAGS = "$ {CLIENT_JVMFLAGS} -Djava.security.auth.login.config = jaas.conf "
2 | Edge для частного облака v4.18.01  Edge для частного облака v4.18.01 
 Команды из четырех букв 
 Apache ZooKeeper имеет ряд «четырехбуквенных команд», которые могут быть полезны при определении
 текущий статус узлов избирателей и наблюдателей ZooKeeper.Эти команды можно вызывать с помощью
 "nc", "telnet" или другая утилита, имеющая
 возможность отправлять команды на определенный порт. Подробная информация о четырехбуквенных командах может быть
 Найдено по адресу:
 http://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_zkCommands.
 Удаление старых файлов моментальных снимков 
 Apache ZooKeeper автоматически выполняет периодическое обслуживание для удаления старых файлов моментальных снимков.
 которые накапливаются по мере обновления системы. Следующие настройки в / opt / apigee / apigee-zookeeper / conf / zoo.cfg
 контролировать этот процесс:
## Количество снимков для сохранения в dataDir:
autopurge.snapRetainCount = 5

# Интервал очистки задачи в часах.
# Установите на «0», чтобы отключить функцию автоматической очистки.
autopurge.purgeInterval = 120
 
 Чтобы установить для этих свойств разные значения:
 Изменить /opt/apigee/customer/application/zookeeper.properties
 для установки следующих свойств. Если этого файла не существует, создайте его.
 Установите следующие свойства в zookeeper.properties: 
 # Установить количество снимков. В этом
 Например, установите его на 10: 
 conf_zoo_autopurge.snapretaincount = 10 # Установите интервал очистки. В этом примере установлено значение 240 часов: 
 conf_zoo_autopurge.purgeinterval = 240
 Убедитесь, что файл принадлежит пользователю apigee: 
> chown
 apigee: apigee /opt/apigee/customer/application/zookeeper.properties
 Перезапустите ZooKeeper с помощью команды: 
 $.
 / opt / apigee / apigee-service / bin / apigee-service apigee-zookeeper restart
 Обслуживание файла журнала 
 Файлы журнала Apache Zookeeper хранятся в / opt / apigee / var / log / apache-zookeeper.Обычно журнал
 обслуживание файла не требуется, но если вы обнаружите, что существует чрезмерное количество
 Журналы ZooKeeper или что журналы очень большие, вы можете изменить свойства ZooKeeper log4j
 чтобы установить максимальный размер файла и количество файлов.
 Изменить /opt/apigee/customer/application/zookeeper.properties
 для установки следующих свойств. Если этого файла не существует, создайте его.
 Установите следующие свойства в zookeeper.properties: 
 conf_log4j_log4j.appender.rollingfile.maxfilesize = 10 МБ
 # максимальный размер файла 
 conf_log4j_log4j.appender.rollingfile.maxbackupindex = 50 # максимальное количество открытых файлов
 Убедитесь, что файл принадлежит пользователю apigee: 
> chown
 apigee: apigee /opt/apigee/customer/application/zookeeper.properties
 Перезапустите ZooKeeper с помощью команды: 
 $.
 / opt / apigee / apigee-service / bin / apigee-service apigee-zookeeper restart
 Running ZooKeeper, координатор распределенной системы 
 Это руководство демонстрирует запуск Apache Zookeeper на
Kubernetes с использованием StatefulSets,
PodDisruptionBudgets,
и PodAntiAffinity.
 Прежде чем начать 
 Перед тем, как приступить к этому руководству, вы должны быть знакомы со следующими
Концепции Kubernetes:
 У вас должен быть кластер как минимум с четырьмя узлами, и каждому узлу требуется как минимум 2 ЦП и 4 ГиБ памяти. В этом руководстве вы будете оцеплять и осушать узлы кластера.  Это означает, что кластер завершит работу и вытеснит все модули на своих узлах, и узлы временно станут неуправляемыми.  Для этого руководства следует использовать выделенный кластер или убедиться, что вызванное вами нарушение не повлияет на работу других клиентов.
 В этом руководстве предполагается, что вы настроили кластер для динамической подготовки.
PersistentVolumes. Если ваш кластер не настроен для этого, вы
придется вручную подготовить три тома по 20 ГиБ перед запуском этого
руководство.
 Цели 
 После этого урока вы узнаете следующее.
 Как развернуть ансамбль ZooKeeper с помощью StatefulSet.
 Как последовательно настроить ансамбль.
 Как распространить развертывание серверов ZooKeeper в ансамбле.
 Как использовать PodDisruptionBudgets для обеспечения доступности услуг во время планового обслуживания.
 ZooKeeper 
 Apache ZooKeeper - это
распределенная служба координации с открытым исходным кодом для распределенных приложений.
ZooKeeper позволяет вам читать, писать и наблюдать за обновлениями данных. Данные
организованы в файловую систему, например иерархию, и реплицируются на все ZooKeeper
серверов в ансамбле (набор серверов ZooKeeper). Все операции с данными
атомарны и последовательно согласованы.ZooKeeper обеспечивает это, используя
Заб
протокол консенсуса для репликации конечного автомата на всех серверах в ансамбле.
 Ансамбль использует протокол Zab для выбора лидера, и ансамбль не может записывать данные до тех пор, пока эти выборы не будут завершены. После завершения ансамбль использует Zab, чтобы гарантировать, что он реплицирует все записи в кворум, прежде чем он подтвердит и сделает их видимыми для клиентов. Без учета взвешенных кворумов кворум - это мажоритарный компонент ансамбля, в который входит текущий лидер.Например, если в ансамбле три сервера, компонент, содержащий ведущего, и еще один сервер составляет кворум. Если ансамбль не может достичь кворума, ансамбль не может записывать данные.
 Серверы ZooKeeper хранят весь свой конечный автомат в памяти и записывают каждую мутацию в долговечный WAL (Write Ahead Log) на носителе. Когда сервер выходит из строя, он может восстановить свое предыдущее состояние, воспроизведя WAL. Чтобы предотвратить неограниченный рост WAL, серверы ZooKeeper периодически делают снимки состояния их памяти на носители.Эти моментальные снимки могут быть загружены непосредственно в память, и все записи WAL, предшествующие моментальному снимку, могут быть отброшены.
 Создание ансамбля ZooKeeper 
 Приведенный ниже манифест содержит
Безголовый сервис,
услуга,
PodDisruptionBudget,
и StatefulSet.
 API  Версия: v1
вид: Сервис
метаданные:
  имя: zk-hs
  ярлыки:
    приложение: zk
спецификация:
  порты:
  - порт: 2888
    имя: сервер
  - порт: 3888
    имя: лидер-выборы
  clusterIP: Нет
  селектор:
    приложение: zk
---
apiVersion: v1
вид: Сервис
метаданные:
  имя: zk-cs
  ярлыки:
    приложение: zk
спецификация:
  порты:
  - порт: 2181
    имя: клиент
  селектор:
    приложение: zk
---
apiVersion: policy / v1
вид: PodDisruptionBudget
метаданные:
  имя: zk-pdb
спецификация:
  селектор:
    matchLabels:
      приложение: zk
  maxUnavailable: 1
---
apiVersion: apps / v1
вид: StatefulSet
метаданные:
  имя: zk
спецификация:
  селектор:
    matchLabels:
      приложение: zk
  serviceName: zk-hs
  реплик: 3
  updateStrategy:
    тип: RollingUpdate
  podManagementPolicy: OrderedReady
  шаблон:
    метаданные:
      ярлыки:
        приложение: zk
    спецификация:
      близость:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - ключ: «приложение»
                    оператор: In
                    значения:
                    - zk
              topologyKey: «кубернетес.io / имя хоста "
      контейнеры:
      - имя: kubernetes-zookeeper
        imagePullPolicy: Всегда
        изображение: "k8s.gcr.io/kubernetes-zookeeper:1.0-3.4.10"
        Ресурсы:
          Запросы:
            память: «1Gi»
            cpu: "0,5"
        порты:
        - порт контейнера: 2181
          имя: клиент
        - порт контейнера: 2888
          имя: сервер
        - порт контейнера: 3888
          имя: лидер-выборы
        команда:
        - ш
        - -c
        - "start-zookeeper \"
          --servers = 3 \
          --data_dir = / var / lib / zookeeper / data \
          --data_log_dir = / var / lib / zookeeper / data / log \
          --conf_dir = / opt / zookeeper / conf \
          --client_port = 2181 \
          --election_port = 3888 \
          --server_port = 2888 \
          --tick_time = 2000 \
          --init_limit = 10 \
          --sync_limit = 5 \
          --heap = 512M \
          --max_client_cnxns = 60 \
          --snap_retain_count = 3 \
          --purge_interval = 12 \
          --max_session_timeout = 40000 \
          --min_session_timeout = 4000 \
          --log_level = ИНФОРМАЦИЯ "
        готовность
          exec:
            команда:
            - ш
            - -c
            - «Зоопарк готов 2181»
          initialDelaySeconds: 10
          timeoutSeconds: 5
        livenessProbe:
          exec:
            команда:
            - ш
            - -c
            - «Зоопарк готов 2181»
          initialDelaySeconds: 10
          timeoutSeconds: 5
        объем
        - имя: datadir
          mountPath: / var / lib / zookeeper
      securityContext:
        runAsUser: 1000
        fsGroup: 1000
  volumeClaimTemplates:
  - метаданные:
      имя: datadir
    спецификация:
      accessModes: ["ReadWriteOnce"]
      Ресурсы:
        Запросы:
          хранилище: 10Gi
  
 Откройте терминал и используйте  kubectl apply  команда для создания
манифест.
  kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
  
 Это создает  zk-hs  Headless Service,  zk-cs  Service,  zk-pdb  PodDisruptionBudget и  zk  StatefulSet.
  сервис / zk-hs создан
сервис / zk-cs создан
poddisruptionbudget.policy / zk-pdb создан
statefulset.apps / zk создан
  
 Используйте  kubectl get  для просмотра
Контроллер StatefulSet создает поды StatefulSet.
  kubectl get pods -w -l app = zk
  
 После того, как под  zk-2  будет запущен и готов, используйте  CTRL-C  для завершения kubectl.
  НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗВРАЩАЕТСЯ ВОЗРАСТ
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Создание контейнера 0 0 с
zk-0 0/1 Бег 0 19 с
zk-0 1/1 Бег 0 40 с
zk-1 0/1 Ожидание 0 0 с
zk-1 0/1 Ожидание 0 0 с
zk-1 0/1 Создание контейнера 0 0 с
zk-1 0/1 Бег 0 18 с
zk-1 1/1 Бег 0 40 с
zk-2 0/1 Ожидание 0 0 с
zk-2 0/1 Ожидание 0 0 с
zk-2 0/1 Создание контейнера 0 0 с
zk-2 0/1 Бег 0 19 с
zk-2 1/1 Бег 0 40 с
  
 Контроллер StatefulSet создает три модуля, каждый из которых имеет контейнер с
сервер ZooKeeper.
 Содействие выборам лидера 
 Поскольку не существует алгоритма завершения для выбора лидера в анонимной сети, Zab требует явной конфигурации членства для выполнения выбора лидера. Каждый сервер в ансамбле должен иметь уникальный идентификатор, все серверы должны знать глобальный набор идентификаторов, и каждый идентификатор должен быть связан с сетевым адресом.
 Используйте  kubectl exec  для получения имен хостов
модулей в  zk  StatefulSet.
  для i в 0 1 2; do kubectl exec zk- $ i - имя хоста; сделано
  
 Контроллер StatefulSet предоставляет каждому модулю уникальное имя хоста на основе его порядкового индекса. Имена хостов имеют вид  <имя набора состояний> - <порядковый индекс> . Поскольку поле  replicas  в  zk  StatefulSet установлено на  3 , контроллер набора создает три модуля с их именами хостов, установленными на  zk-0 ,  zk-1  и  ЗК-2 .
  zk-0
zk-1
zk-2
  
 Серверы в ансамбле ZooKeeper используют натуральные числа в качестве уникальных идентификаторов и сохраняют идентификатор каждого сервера в файле с именем  myid  в каталоге данных сервера.
 Чтобы проверить содержимое файла  myid  для каждого сервера, используйте следующую команду.
  для i в 0 1 2; do echo "myid zk- $ i"; kubectl exec zk- $ i - cat / var / lib / zookeeper / data / myid; сделано
  
 Поскольку идентификаторы являются натуральными числами, а порядковые индексы - неотрицательными целыми числами, вы можете сгенерировать идентификатор, добавив 1 к порядковому номеру.
  myid zk-0
1
myid zk-1
2
myid zk-2
3
  
 Чтобы получить полное доменное имя (FQDN) каждого модуля в  zk  StatefulSet, используйте следующую команду.
  для i в 0 1 2; сделать kubectl exec zk- $ i - имя хоста -f; сделано
  
 Служба  zk-hs  создает домен для всех модулей,  zk-hs.default.svc.cluster.local .
  zk-0.zk-hs.default.svc.cluster.local
zk-1.zk-hs.default.svc.cluster.местный
zk-2.zk-hs.default.svc.cluster.local
  
 Записи A в Kubernetes DNS разрешают полные доменные имена в IP-адреса подов. Если Kubernetes изменит расписание модулей, он обновит записи A с новыми IP-адресами модулей, но имена записей A не изменятся.
 ZooKeeper сохраняет свою конфигурацию приложения в файле с именем  zoo.cfg . Используйте  kubectl exec  для просмотра содержимого файла  zoo.cfg  в модуле  zk-0 .
  kubectl exec zk-0 - cat / opt / zookeeper / conf / zoo.cfg
  
 На сервере .1 ,  server.2  и  server.3 Свойства  внизу
файла,  1 ,  2  и  3  соответствуют идентификаторам в
Файлы  myid  серверов ZooKeeper. Они настроены на полные доменные имена для модулей в
набор  zk  StatefulSet.
  clientPort = 2181
dataDir = / var / lib / zookeeper / данные
dataLogDir = / var / lib / zookeeper / журнал
tickTime = 2000
initLimit = 10
syncLimit = 2000
maxClientCnxns = 60
minSessionTimeout = 4000
maxSessionTimeout = 40000
автопромывка.snapRetainCount = 3
autopurge.purgeInterval = 0
server.1 = zk-0.zk-hs.default.svc.cluster.local: 2888: 3888
server.2 = zk-1.zk-hs.default.svc.cluster.local: 2888: 3888
server.3 = zk-2.zk-hs.default.svc.cluster.local: 2888: 3888
  
 Достижение консенсуса 
 Протоколы консенсуса требуют, чтобы идентификаторы каждого участника были уникальными. Никакие два участника протокола Zab не должны требовать один и тот же уникальный идентификатор. Это необходимо для того, чтобы процессы в системе могли согласовать, какие процессы передали какие данные.Если два модуля запускаются с одинаковым порядковым номером, два сервера ZooKeeper идентифицируют себя как один и тот же сервер.
  kubectl get pods -w -l app = zk
  
  НАЗВАНИЕ СОСТОЯНИЕ ГОТОВ ВОССТАНОВЛЕНИЕ ВОЗРАСТА
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Создание контейнера 0 0 с
zk-0 0/1 Бег 0 19 с
zk-0 1/1 Бег 0 40 с
zk-1 0/1 Ожидание 0 0 с
zk-1 0/1 Ожидание 0 0 с
zk-1 0/1 Создание контейнера 0 0 с
zk-1 0/1 Бег 0 18 с
zk-1 1/1 Бег 0 40 с
zk-2 0/1 Ожидание 0 0 с
zk-2 0/1 Ожидание 0 0 с
zk-2 0/1 Создание контейнера 0 0 с
zk-2 0/1 Бег 0 19 с
zk-2 1/1 Бег 0 40 с
  
 Записи A для каждого модуля вводятся, когда модуль становится готовым.Следовательно,
полные доменные имена серверов ZooKeeper разрешаются в одну конечную точку, и это
конечной точкой будет уникальный сервер ZooKeeper, претендующий на настроенную личность
в файле  myid .
  zk-0.zk-hs.default.svc.cluster.local
zk-1.zk-hs.default.svc.cluster.local
zk-2.zk-hs.default.svc.cluster.local
  
 Это гарантирует, что  серверов  свойства в  zoo.cfg  файлов ZooKeepers
представляет собой правильно настроенный ансамбль.
  сервер.1 = zk-0.zk-hs.default.svc.cluster.local: 2888: 3888
server.2 = zk-1.zk-hs.default.svc.cluster.local: 2888: 3888
server.3 = zk-2.zk-hs.default.svc.cluster.local: 2888: 3888
  
 Когда серверы используют протокол Zab, чтобы попытаться зафиксировать значение, они либо достигнут консенсуса и зафиксируют значение (если выборы лидера прошли успешно и по крайней мере два модуля находятся в рабочем состоянии и готовы), либо они не смогут сделайте это (если какое-либо из условий не выполняется). Не возникает состояния, в котором один сервер подтверждает запись от имени другого.
 Тестирование работоспособности ансамбля 
 Самый простой тест на работоспособность - это запись данных на один сервер ZooKeeper и
читать данные из другого.
 Приведенная ниже команда выполняет сценарий  zkCli.sh  для записи  world  в путь  / hello  на поде  zk-0  в ансамбле.
  kubectl exec zk-0 zkCli.sh создать / привет мир
  
  ДИСПЕТЧЕР ::

Состояние WatchedEvent: тип SyncConnected: нет путь: нуль
Создано / привет
  
 Чтобы получить данные из модуля  zk-1  Pod, используйте следующую команду.
  kubectl exec zk-1 zkCli.sh получить / привет
  
 Данные, созданные на  zk-0 , доступны на всех серверах в
ансамбль.
  ДИСПЕТЧЕР ::

Состояние WatchedEvent: тип SyncConnected: нет путь: нуль
Мир
cZxid = 0x100000002
ctime = Чт, 8 декабря, 15:13:30 UTC 2016
mZxid = 0x100000002
mtime = Чт, 8 декабря, 15:13:30 UTC 2016
pZxid = 0x100000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0
  
 Обеспечение длительного хранения 
 Как упоминалось в разделе "Основы ZooKeeper",
ZooKeeper фиксирует все записи в устойчивом WAL и периодически записывает моментальные снимки.
в состоянии памяти на носитель.Использование WAL для обеспечения долговечности - обычное дело.
метод для приложений, использующих протоколы консенсуса для достижения репликации
Государственный аппарат.
 Используйте команду  kubectl delete , чтобы удалить  zk  StatefulSet.
  kubectl удалить набор состояний zk
  
  statefulset.apps "zk" удален
  
 Наблюдайте за завершением работы модулей в StatefulSet.
  kubectl get pods -w -l app = zk
  
 Когда  zk-0  при полном завершении, используйте  CTRL-C  для завершения kubectl.
  zk-2 1/1 Концевой 0 9 м
zk-0 1/1 Завершение 0 11м
zk-1 1/1 Концевой 0 10м
zk-2 0/1 Завершение 0 9м
zk-2 0/1 Завершение 0 9м
zk-2 0/1 Завершение 0 9м
zk-1 0/1 Завершение 0 10 м
zk-1 0/1 Завершение 0 10 м
zk-1 0/1 Завершение 0 10 м
zk-0 0/1 Завершение 0 11м
zk-0 0/1 Завершение 0 11м
zk-0 0/1 Завершение 0 11м
  
 Повторно применить манифест в  zookeeper.yaml .
  kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
  
 Это создает объект  zk  StatefulSet, но другие объекты API в манифесте не изменяются, поскольку они уже существуют.
 Наблюдайте, как контроллер StatefulSet воссоздает поды StatefulSet.
  kubectl get pods -w -l app = zk
  
 После того, как под  zk-2  будет запущен и готов, используйте  CTRL-C  для завершения kubectl.
  НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗВРАЩАЕТСЯ ВОЗРАСТ
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Создание контейнера 0 0 с
zk-0 0/1 Бег 0 19 с
zk-0 1/1 Бег 0 40 с
zk-1 0/1 Ожидание 0 0 с
zk-1 0/1 Ожидание 0 0 с
zk-1 0/1 Создание контейнера 0 0 с
zk-1 0/1 Бег 0 18 с
zk-1 1/1 Бег 0 40 с
zk-2 0/1 Ожидание 0 0 с
zk-2 0/1 Ожидание 0 0 с
zk-2 0/1 Создание контейнера 0 0 с
zk-2 0/1 Бег 0 19 с
zk-2 1/1 Бег 0 40 с
  
 Используйте команду ниже, чтобы получить значение, которое вы ввели во время проверки работоспособности,
от  zk-2  Pod.
  kubectl exec zk-2 zkCli.sh получить / привет
  
 Несмотря на то, что вы завершили работу и воссоздали все модули в StatefulSet  zk , ансамбль по-прежнему имеет исходное значение.
  ДИСПЕТЧЕР ::

Состояние WatchedEvent: тип SyncConnected: нет путь: нуль
Мир
cZxid = 0x100000002
ctime = Чт, 8 декабря, 15:13:30 UTC 2016
mZxid = 0x100000002
mtime = Чт, 8 декабря, 15:13:30 UTC 2016
pZxid = 0x100000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0
  
 Поле  volumeClaimTemplates  в спецификации   StatefulSet  zk  StatefulSet указывает PersistentVolume, предоставленный для каждого модуля.
  объем
  - метаданные:
      имя: datadir
      аннотации:
        volume.alpha.kubernetes.io/storage-class: что угодно
    спецификация:
      accessModes: ["ReadWriteOnce"]
      Ресурсы:
        Запросы:
          хранение: 20Gi
  
 Контроллер  StatefulSet  генерирует  PersistentVolumeClaim  для каждого модуля в
набор  StatefulSet .
 Используйте следующую команду, чтобы получить  StatefulSet   PersistentVolumeClaims .
  kubectl get pvc -l app = zk
  
 Когда  StatefulSet  воссоздал свои поды, он перемонтирует их PersistentVolumes.
  НАИМЕНОВАНИЕ СОСТОЯНИЕ ОБЪЕМ ДОСТУП РЕЖИМЫ ВОЗРАСТ
datadir-zk-0 Связанный ПВХ-кровать742cd-bcb1-11e6-994f-42010a800002 20Gi RWO 1h
datadir-zk-1 Связанный ПВХ-bedd27d2-bcb1-11e6-994f-42010a800002 20Gi RWO 1h
datadir-zk-2 Связанный ПВХ-bee0817e-bcb1-11e6-994f-42010a800002 20Gi RWO 1h
  
 Раздел  volumeMounts  контейнера  StatefulSet . Шаблон   монтирует PersistentVolumes в каталогах данных серверов ZooKeeper.
  объем
- имя: datadir
  mountPath: / var / lib / zookeeper
  
 Когда Pod в  zk   StatefulSet  (переназначен) запланирован, он всегда будет иметь
тот же  PersistentVolume , подключенный к каталогу данных сервера ZooKeeper.
Даже при изменении графика работы модулей все записи, сделанные в ZooKeeper
WAL серверов и все их снимки остаются надежными.
 Обеспечение согласованной конфигурации 
 Как указано в Содействии выборам лидера и
Достигнув разделов Консенсуса, серверы в
Ансамблю ZooKeeper требуется согласованная конфигурация для выбора лидера
и сформировать кворум.Они также требуют согласованной настройки протокола Zab.
для правильной работы протокола в сети. В нашем примере мы
добиться согласованной конфигурации путем встраивания конфигурации непосредственно в
манифест.
 Получите  zk  StatefulSet.
  kubectl get sts zk -o yaml
  
 …
команда:
      - ш
      - -c
      - "start-zookeeper \"
        --servers = 3 \
        --data_dir = / var / lib / zookeeper / data \
        --data_log_dir = / var / lib / zookeeper / data / log \
        --conf_dir = / opt / zookeeper / conf \
        --client_port = 2181 \
        --election_port = 3888 \
        --server_port = 2888 \
        --tick_time = 2000 \
        --init_limit = 10 \
        --sync_limit = 5 \
        --heap = 512M \
        --max_client_cnxns = 60 \
        --snap_retain_count = 3 \
        --purge_interval = 12 \
        --max_session_timeout = 40000 \
        --min_session_timeout = 4000 \
        --log_level = ИНФОРМАЦИЯ "
…
  
 Команда, используемая для запуска серверов ZooKeeper, передала конфигурацию как параметр командной строки.Вы также можете использовать переменные среды для передачи конфигурации ансамблю.
 Настройка логирования 
 Один из файлов, сгенерированных сценарием  zkGenConfig.sh , контролирует ведение журнала ZooKeeper.
ZooKeeper использует Log4j и по умолчанию
он использует приложение для сменяющихся файлов на основе времени и размера для своей конфигурации ведения журнала.
 Используйте команду ниже, чтобы получить конфигурацию ведения журнала из одного из модулей в  zk   StatefulSet .
  kubectl exec zk-0 cat / usr / etc / zookeeper / log4j.характеристики
  
 Конфигурация журналирования ниже заставит процесс ZooKeeper записывать все
журналов в стандартный выходной файловый поток.
  zookeeper.root.logger = КОНСОЛЬ
zookeeper.console.threshold = ИНФОРМАЦИЯ
log4j.rootLogger = $ {zookeeper.root.logger}
log4j.appender.CONSOLE = org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold = $ {zookeeper.console.threshold}
log4j.appender.CONSOLE.layout = org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern =% d {ISO8601} [myid:% X {myid}] -% -5p [% t:% C {1} @% L] -% m% n
  
 Это самый простой способ безопасно войти в контейнер.Поскольку приложения записывают журналы в стандартный формат, Kubernetes выполнит ротацию журналов за вас.
Kubernetes также реализует разумную политику хранения, которая обеспечивает запись журналов приложений в
стандартный выход и стандартная ошибка не исчерпывают локальный носитель.
 Используйте  журналы kubectl , чтобы получить последние 20 строк журнала из одного из модулей.
  журналы kubectl zk-0 - хвост 20
  
 Вы можете просмотреть журналы приложений, записанные в стандартный выход или стандартную ошибку, с помощью  журналов kubectl  и из панели инструментов Kubernetes.
  06.12.2016 19: 34: 16,236 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxn @ 827] - Обработка команды ruok из /127.0.0.1:52740
2016-12-06 19: 34: 16,237 [myid: 1] - ИНФОРМАЦИЯ [Thread-1136: NIOServerCnxn @ 1008] - Закрытое соединение сокета для клиента /127.0.0.1:52740 (для клиента сеанс не установлен)
2016-12-06 19: 34: 26,155 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxnFactory @ 192] - Принято подключение к сокету от /127.0.0.1:52749
2016-12-06 19: 34: 26,155 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Заводская: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxn @ 827] - Обработка команды ruok из /127.0.0.1:52749
2016-12-06 19: 34: 26,156 [myid: 1] - ИНФОРМАЦИЯ [Thread-1137: NIOServerCnxn @ 1008] - Закрытое соединение сокета для клиента /127.0.0.1:52749 (для клиента сеанс не установлен)
2016-12-06 19: 34: 26,222 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxnFactory @ 192] - Принято подключение к сокету от /127.0.0.1:52750
2016-12-06 19: 34: 26,222 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxn @ 827] - Обработка команды ruok из / 127.0.0.1: 52750
2016-12-06 19: 34: 26,226 [myid: 1] - ИНФОРМАЦИЯ [Thread-1138: NIOServerCnxn @ 1008] - Закрытое соединение сокета для клиента /127.0.0.1:52750 (сеанс для клиента не установлен)
2016-12-06 19: 34: 36,151 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxnFactory @ 192] - Принято подключение к сокету от /127.0.0.1:52760
2016-12-06 19: 34: 36,152 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxn @ 827] - Обработка команды ruok из /127.0.0.1:52760
2016-12-06 19: 34: 36,152 [myid: 1] - ИНФОРМАЦИЯ [Thread-1139: NIOServerCnxn @ 1008] - Закрытое соединение сокета для клиента / 127.0.0.1: 52760 (для клиента сеанс не установлен)
2016-12-06 19: 34: 36,230 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxnFactory @ 192] - Принято подключение к сокету от /127.0.0.1:52761
2016-12-06 19: 34: 36,231 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxn @ 827] - Обработка команды ruok из /127.0.0.1:52761
2016-12-06 19: 34: 36,231 [myid: 1] - ИНФОРМАЦИЯ [Thread-1140: NIOServerCnxn @ 1008] - Закрытое соединение сокета для клиента /127.0.0.1:52761 (сеанс для клиента не установлен)
2016-12-06 19: 34: 46,149 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Заводская установка: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxnFactory @ 192] - разрешено соединение через сокет от /127.0.0.1:52767
2016-12-06 19: 34: 46,149 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxn @ 827] - Обработка команды ruok из /127.0.0.1:52767
2016-12-06 19: 34: 46,149 [myid: 1] - ИНФОРМАЦИЯ [Thread-1141: NIOServerCnxn @ 1008] - Закрытое соединение сокета для клиента /127.0.0.1:52767 (для клиента сеанс не установлен)
2016-12-06 19: 34: 46,230 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxnFactory @ 192] - Принято соединение сокета от / 127.0.0.1: 52768
2016-12-06 19: 34: 46,230 [myid: 1] - ИНФОРМАЦИЯ [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxn @ 827] - Обработка команды ruok из /127.0.0.1:52768
2016-12-06 19: 34: 46,230 [myid: 1] - ИНФОРМАЦИЯ [Thread-1142: NIOServerCnxn @ 1008] - Закрытое соединение сокета для клиента /127.0.0.1:52768 (для клиента сеанс не установлен)
  
 Kubernetes интегрируется со многими решениями для ведения журналов. Вы можете выбрать решение для ведения журнала
который лучше всего подходит для вашего кластера и приложений. Для ведения журнала и агрегирования на уровне кластера
рассмотрите возможность развертывания контейнера с коляской для поворота и отправки ваших журналов.
 Настройка непривилегированного пользователя 
 Лучшие практики, позволяющие запускать приложение как привилегированный
пользователь внутри контейнера является предметом обсуждения. Если вашей организации требуется
что приложения работают как непривилегированный пользователь, вы можете использовать
SecurityContext для управления пользователем, который
точка входа работает как.
  zk   StatefulSet  Шаблон Pod   содержит  SecurityContext .
  securityContext:
  runAsUser: 1000
  fsGroup: 1000
  
 В контейнерах подов UID 1000 соответствует пользователю zookeeper, а GID 1000
соответствует группе zookeeper.
 Получите информацию о процессе ZooKeeper из модуля  zk-0  Pod.
  kubectl exec zk-0 - ps -elf
  
 Поскольку поле  runAsUser  объекта  securityContext  установлено в 1000,
вместо того, чтобы запускаться от имени пользователя root, процесс ZooKeeper запускается от имени пользователя zookeeper.
  F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S zookeep + 1 0 0 80 0 - 1127 - 20:46? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
0 S zookeep + 27 1 0 80 0 - 1155556 - 20:46? 00:00:19 / usr / lib / jvm / java-8-openjdk-amd64 / bin / java -Dzookeeper.log.dir = / var / log / zookeeper -Dzookeeper.root.logger = ИНФОРМАЦИЯ, КОНСОЛЬ -cp / usr /bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin /../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/ zookeeper / netty-3.10.5.Final.jar: / usr / bin /../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*. jar: / usr / bin /../ etc / zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only = false org.apache.zookeeper.server.quorum. QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg
  
 По умолчанию, когда PersistentVolumes модуля монтируются в каталог данных сервера ZooKeeper, он доступен только пользователю root. Эта конфигурация предотвращает запись процесса ZooKeeper в свой WAL и сохранение его снимков.
 Используйте команду ниже, чтобы получить права доступа к файлам каталога данных ZooKeeper на модуле  zk-0  Pod.
  kubectl exec -ti zk-0 - ls -ld / var / lib / zookeeper / data
  
 Поскольку для поля  fsGroup  объекта  securityContext  установлено значение 1000, владельцем PersistentVolumes подов является группа zookeeper, и процесс ZooKeeper может читать и записывать свои данные.
  drwxr-sr-x 3 zookeeper zookeeper 4096 5 декабря 20:45 / var / lib / zookeeper / data
  
 Управление процессом ZooKeeper 
 Документация ZooKeeper
упоминает, что «вам нужно иметь надзорный процесс, который
управляет каждым из ваших серверных процессов ZooKeeper (JVM)."Использование сторожевого пса
(процесс наблюдения) для перезапуска сбойных процессов в распределенной системе является
общий образец. При развертывании приложения в Kubernetes вместо использования
внешнюю утилиту в качестве надзорного процесса, вы должны использовать Kubernetes в качестве
сторожевой таймер для вашего приложения.
 Обновление ансамбля 
  zk   StatefulSet  настроен для использования стратегии обновления  RollingUpdate .
 Вы можете использовать  kubectl patch  для обновления количества  cpus , выделенных серверам.
  kubectl patch sts zk --type = 'json' -p = '[{"op": "replace", "path": "/ spec / template / spec / container / 0 / resources / requests / cpu", "значение": "0,3"}] '
  
  statefulset.apps / zk исправлено
  
 Используйте  статус развертывания kubectl , чтобы следить за статусом обновления.
  статус развертывания kubectl sts / zk
  
  ожидает непрерывного обновления набора состояний для завершения 0 модулей в ревизии zk-5db4499664 ...
Ожидание готовности 1 стручка...
В ожидании готовности 1 капсулы ...
ожидание скользящего обновления с сохранением состояния для завершения 1 подов в ревизии zk-5db4499664 ...
В ожидании готовности 1 капсулы ...
В ожидании готовности 1 капсулы ...
ожидание непрерывного обновления statefulset, чтобы завершить 2 модуля в ревизии zk-5db4499664 ...
В ожидании готовности 1 капсулы ...
В ожидании готовности 1 капсулы ...
Последовательное обновление statefulset завершило 3 модуля на ревизии zk-5db4499664 ...
  
 Это завершает Pod по одному в обратном порядковом порядке и воссоздает их с новой конфигурацией.Это гарантирует сохранение кворума во время непрерывного обновления.
 Используйте команду  kubectl rollout history  для просмотра истории или предыдущих конфигураций.
  История развертывания kubectl sts / zk
  
  statefulsets "zk"
ПЕРЕСМОТР
1
2
  
 Используйте команду  kubectl rollout undo , чтобы откатить модификацию.
  kubectl rollout undo sts / zk
  
  statefulset.apps / zk откат
  
 Обработка сбоя в процессе 
 Политики перезапуска определяют, как
Kubernetes обрабатывает сбои процесса для точки входа контейнера в поде.Для подов в  StatefulSet  единственной подходящей политикой  RestartPolicy  является Always, и это
значение по умолчанию. Для приложений с отслеживанием состояния вы должны  никогда не переопределять  политика по умолчанию.
 Используйте следующую команду, чтобы проверить дерево процессов для сервера ZooKeeper, запущенного в модуле  zk-0  Pod.
  kubectl exec zk-0 - ps -ef
  
 Команда, используемая в качестве точки входа в контейнер, имеет PID 1, и
процесс ZooKeeper, дочерний процесс точки входа, имеет PID 27.
  UID PID PPID C STIME TTY TIME CMD
zookeep + 1 0 0 15:03? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
zookeep + 27 1 0 15:03? 00:00:03 / usr / lib / jvm / java-8-openjdk-amd64 / bin / java -Dzookeeper.log.dir = / var / log / zookeeper -Dzookeeper.root.logger = ИНФОРМАЦИЯ, КОНСОЛЬ -cp / usr /bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin /../share/zookeeper/slf4j-log4j12-1.6.1.jar: / usr / bin /../ share / zookeeper / slf4j-api-1.6.1.jar: / usr / bin /../ share / zookeeper / netty-3.10.5.Final.jar: / usr /bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/ lib / *. jar: / usr / bin /../ etc / zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only = false org.apache.zookeeper. server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg
  
 В другом терминале наблюдайте за модулями в  zk   StatefulSet  с помощью следующей команды.
  kubectl get pod -w -l app = zk
  
 В другом терминале завершите процесс ZooKeeper в Pod  zk-0  с помощью следующей команды.
  kubectl exec zk-0 - pkill java
  
 Завершение процесса ZooKeeper привело к завершению его родительского процесса. Поскольку  RestartPolicy  контейнера всегда, он перезапустил родительский процесс.
  НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗВРАЩАЕТСЯ ВОЗРАСТ
zk-0 1/1 Бег 0 21м
zk-1 1/1 Бег 0 20м
zk-2 1/1 Бег 0 19м
НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗВРАЩАЕТСЯ
zk-0 0/1 Ошибка 0 29м
zk-0 0/1 Бег 1 29м
zk-0 1/1 Бег 1 29м
  
 Если ваше приложение использует сценарий (например,  zkServer.sh ), чтобы запустить процесс
реализующий бизнес-логику приложения, сценарий должен заканчиваться
дочерний процесс. Это гарантирует, что Kubernetes перезапустит приложение
контейнер при сбое процесса, реализующего бизнес-логику приложения.
 Тест на живучесть 
 Настроить приложение для перезапуска неудачных процессов недостаточно, чтобы
поддерживать работоспособность распределенной системы. Есть сценарии, где
системные процессы могут быть как живыми, так и не отвечающими, или иным образом
нездоровый.Вы должны использовать зонды живучести для уведомления Kubernetes
что процессы вашего приложения неработоспособны, и его следует перезапустить.
 Шаблон  Pod  для  zk   StatefulSet  задает зонд живучести.
  живучесть
          exec:
            команда:
            - ш
            - -c
            - «Зоопарк готов 2181»
          initialDelaySeconds: 15
          timeoutSeconds: 5
  
 Зонд вызывает сценарий bash, который использует ZooKeeper  ruok  из четырех букв.
слово для проверки работоспособности сервера.
  OK = $ (echo ruok | nc 127.0.0.1 $ 1)
если ["$ OK" == "имок"]; потом
    выход 0
еще
    выход 1
фи
  
 В одном окне терминала используйте следующую команду для просмотра модулей в  zk  StatefulSet.
  kubectl get pod -w -l app = zk
  
 В другом окне с помощью следующей команды удалите сценарий  zookeeper-ready  из файловой системы Pod  zk-0 .
  kubectl exec zk-0 - rm / usr / bin / zookeeper-готово
  
 Когда зонд живучести для процесса ZooKeeper дает сбой, Kubernetes
автоматически перезапускать процесс для вас, гарантируя, что нездоровые процессы в
ансамбль перезапускается.
  kubectl get pod -w -l app = zk
  
  НАЗВАНИЕ СОСТОЯНИЕ ГОТОВ ВОССТАНОВЛЕНИЕ ВОЗРАСТА
zk-0 1/1 Бег 0 1ч
zk-1 1/1 Бег 0 1ч
zk-2 1/1 Бег 0 1ч
НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗВРАЩАЕТСЯ
zk-0 0/1 Бег 0 1ч
zk-0 0/1 Бег 1 1ч
zk-0 1/1 Бег 1 1ч
  
 Проверка на готовность 
 Готовность - это не то же самое, что живучесть.Если процесс жив, он запланирован
и здоровый. Если процесс готов, он может обрабатывать ввод. Живучесть
необходимое, но недостаточное условие готовности. Есть случаи,
особенно во время инициализации и завершения, когда процесс может быть
жив, но не готов.
 Если вы укажете тест готовности, Kubernetes обеспечит
процессы не будут получать сетевой трафик, пока не пройдут их проверки готовности.
 Для сервера ZooKeeper живучесть подразумевает готовность.Поэтому готовность
зонд из манифеста  zookeeper.yaml  идентичен зонду живучести.
  готовность Зонд:
    exec:
      команда:
      - ш
      - -c
      - «Зоопарк готов 2181»
    initialDelaySeconds: 15
    timeoutSeconds: 5
  
 Несмотря на то, что датчики живучести и готовности идентичны, это важно.
указать оба. Это гарантирует, что только исправные серверы в ZooKeeper
ансамбль получает сетевой трафик.
 Допуск отказа узла 
 ZooKeeper необходим кворум серверов для успешной фиксации мутаций
к данным.Для ансамбля из трех серверов два сервера должны быть исправны для
пишет, чтобы добиться успеха. В системах на основе кворума участники развертываются в случае сбоя.
домены для обеспечения доступности. Чтобы избежать простоя из-за потери
отдельная машина, передовой опыт не допускает одновременного размещения нескольких экземпляров
приложение на той же машине.
 По умолчанию Kubernetes может размещать поды в  StatefulSet  на том же узле.
Для созданного вами ансамбля из трех серверов, если два сервера находятся на одном узле, и этот узел выходит из строя,
клиенты вашего сервиса ZooKeeper будут отключены до тех пор, пока не будет перенесен хотя бы один из модулей.
 Вы всегда должны предоставлять дополнительную мощность, чтобы разрешить процессы критически важных
системы должны быть перепланированы в случае отказа узлов. Если вы это сделаете, то
отключение будет длиться только до тех пор, пока планировщик Kubernetes не изменит расписание одного из ZooKeeper
серверы. Однако, если вы хотите, чтобы ваша служба выдерживала сбои узлов без простоев,
вам следует установить  podAntiAffinity .
 Используйте команду ниже, чтобы получить узлы для подов в  zk   StatefulSet .
  для i в 0 1 2; do kubectl get pod zk- $ i --template {{.spec.nodeName}}; эхо ""; сделано
  
 Все поды в  zk   StatefulSet  развернуты на разных узлах.
  кубернетес-узел-cxpk
Кубернетес-узел-a5aq
кубернетес-узел-2g2d
  
 Это связано с тем, что для модулей в  zk   StatefulSet  указано значение  PodAntiAffinity .
  сходство:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - ключ: «приложение»
                    оператор: In
                    значения:
                    - zk
              topologyKey: «кубернетес.io / имя хоста "
  
 Поле  requiredDuringSchedulingIgnoredDuringExecution  сообщает
Kubernetes Scheduler: он никогда не должен совмещать два модуля с меткой  app  как  zk  в домене, определенном ключом топологии  . Топология  Ключ   kubernetes.io/hostname  указывает, что домен является отдельным узлом. С использованием
различные правила, метки и селекторы, вы можете расширить эту технику для распространения
ваш ансамбль в физическом и сетевом домене, а также в домене сбоя питания.
 Оставшееся содержание 
 В этом разделе вы будете оцеплять и осушать узлы. Если вы используете этот учебник
в общем кластере убедитесь, что это не повлияет отрицательно на других клиентов.
 В предыдущем разделе было показано, как распределить ваши поды по узлам, чтобы выжить.
незапланированные сбои узлов, но вам также необходимо спланировать временные сбои узлов
которые происходят из-за планового обслуживания.
 Используйте эту команду, чтобы получить узлы в кластере.
 Используйте  kubectl cordon  для
оцепите все, кроме четырех узлов в вашем кластере.
  kubectl cordon <имя-узла>
  
 Используйте эту команду, чтобы получить  zk-pdb   PodDisruptionBudget .
 Поле  max-unavailable  указывает Kubernetes, что не более одного модуля из  zk   StatefulSet  может быть недоступен в любое время.
  НАИМЕНОВАНИЕ МИН.-ДОСТУПНО МАКС.-НЕДОСТУПНО РАЗРЕШЕННЫЕ НАРУШЕНИЯ ВОЗРАСТ
zk-pdb НЕТ 1 1
  
 В одном терминале используйте эту команду для наблюдения за модулями в  zk   StatefulSet .
  kubectl get pods -w -l app = zk
  
 В другом терминале используйте эту команду, чтобы получить узлы, на которых в настоящее время запланированы поды.
  для i в 0 1 2; do kubectl get pod zk- $ i --template {{.spec.nodeName}}; эхо ""; сделано
  
  кубернетес-узел-pb41
кубернетес-узел-ixsl
Кубернетес-узел-i4c4
  
 Используйте слив  kubectl  для кордона и
опорожнить узел, на котором запланирован  zk-0  Pod.
  kubectl сток $ (kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
  
  узел «кубернетес-узел-пб41» оцеплен

ПРЕДУПРЕЖДЕНИЕ. Удаление модулей, не управляемых ReplicationController, ReplicaSet, Job или DaemonSet: fluentd-cloud-logging-kubernetes-node-pb41, kube-proxy-kubernetes-node-pb41; Игнорирование модулей, управляемых DaemonSet: узел-проблема-детектор-v0.1-o5elz
под "zk-0" удален
узел "кубернетес-узел-pb41" осушен
  
 Поскольку в вашем кластере четыре узла,  kubectl сток , выполняется успешно, а  zk-0  перенесено на другой узел.
  НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗВРАЩАЕТСЯ ВОЗРАСТ
zk-0 1/1 Бег 2 1ч
zk-1 1/1 Бег 0 1ч
zk-2 1/1 Бег 0 1ч
НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗВРАЩАЕТСЯ
zk-0 1/1 Завершение 2 2h
zk-0 0/1 Завершение 2 2h
zk-0 0/1 Завершение 2 2h
zk-0 0/1 Завершение 2 2h
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Создание контейнера 0 0 с
zk-0 0/1 Бег 0 51 с
zk-0 1/1 Бег 0 1м
  
 Продолжайте наблюдать за подами  StatefulSet  в первом терминале и опустошите узел, на котором
 Планируется  zk-1 .
  kubectl Drain $ (kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" оцеплен
  
  ПРЕДУПРЕЖДЕНИЕ. Удаление модулей, не управляемых ReplicationController, ReplicaSet, Job или DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Игнорирование модулей, управляемых DaemonSet: узел-проблема-детектор-v0.1-voice74
капсула "zk-1" удалена
узел "кубернетес-узел-ixsl" осушен
  
 Pod  zk-1  не может быть запланирован, потому что  zk   StatefulSet  содержит правило  PodAntiAffinity , запрещающее
совместное расположение модулей, и поскольку только два узла могут быть запланированы, модуль останется в состоянии ожидания.
  kubectl get pods -w -l app = zk
  
  НАЗВАНИЕ СОСТОЯНИЕ ГОТОВ ВОССТАНОВЛЕНИЕ ВОЗРАСТА
zk-0 1/1 Бег 2 1ч
zk-1 1/1 Бег 0 1ч
zk-2 1/1 Бег 0 1ч
НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗВРАЩАЕТСЯ
zk-0 1/1 Завершение 2 2h
zk-0 0/1 Завершение 2 2h
zk-0 0/1 Завершение 2 2h
zk-0 0/1 Завершение 2 2h
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Создание контейнера 0 0 с
zk-0 0/1 Бег 0 51 с
zk-0 1/1 Бег 0 1м
zk-1 1/1 Завершение 0 2h
zk-1 0/1 Завершение 0 2h
zk-1 0/1 Завершение 0 2h
zk-1 0/1 Завершение 0 2h
zk-1 0/1 Ожидание 0 0 с
zk-1 0/1 Ожидание 0 0 с
  
 Продолжить наблюдение за подами набора с отслеживанием состояния и очистить узел, на котором
 Планируется  zk-2 .
  kubectl Drain $ (kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
  
  узел «кубернетес-узел-i4c4» оцеплен

ПРЕДУПРЕЖДЕНИЕ. Удаление модулей, не управляемых ReplicationController, ReplicaSet, Job или DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Игнорирование модулей, управляемых DaemonSet: узел-проблема-детектор-v0.1-dyrog
ВНИМАНИЕ! Игнорирование модулей, управляемых DaemonSet: node-problem-Detector-v0.1-дырог; Удаление модулей, не управляемых ReplicationController, ReplicaSet, Job или DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4
Когда произошла ошибка, есть ожидающие модули: Невозможно выселить модуль, так как это нарушит бюджет на нарушение работы модуля.
pod / zk-2
  
 Используйте  CTRL-C  для завершения kubectl.
 Вы не можете осушить третий узел, потому что удаление  zk-2  нарушит  zk-budget . Однако узел останется оцепленным.
 Используйте  zkCli.sh , чтобы получить значение, введенное вами во время проверки работоспособности, из  zk-0 .
  kubectl exec zk-0 zkCli.sh получить / привет
  
 Услуга по-прежнему доступна, поскольку ее  PodDisruptionBudget  соблюдается.
  Состояние WatchedEvent: Тип SyncConnected: Нет путь: null
Мир
cZxid = 0x200000002
ctime = среда, 7 декабря, 00:08:59 UTC, 2016
mZxid = 0x200000002
mtime = среда, 7 декабря, 00:08:59 UTC, 2016
pZxid = 0x200000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0
  
 Используйте  kubectl uncordon , чтобы отсоединить первый узел.
  kubectl uncordon kubernetes-node-pb41
  
  узел "kubernetes-node-pb41" без проводов
  
  zk-1  переназначен на этом узле. Подождите, пока  zk-1  будет запущен и готов.
  kubectl get pods -w -l app = zk
  
  НАЗВАНИЕ СОСТОЯНИЕ ГОТОВ ВОССТАНОВЛЕНИЕ ВОЗРАСТА
zk-0 1/1 Бег 2 1ч
zk-1 1/1 Бег 0 1ч
zk-2 1/1 Бег 0 1ч
НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗВРАЩАЕТСЯ
zk-0 1/1 Завершение 2 2h
zk-0 0/1 Завершение 2 2h
zk-0 0/1 Завершение 2 2h
zk-0 0/1 Завершение 2 2h
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Ожидание 0 0 с
zk-0 0/1 Создание контейнера 0 0 с
zk-0 0/1 Бег 0 51 с
zk-0 1/1 Бег 0 1м
zk-1 1/1 Завершение 0 2h
zk-1 0/1 Завершение 0 2h
zk-1 0/1 Завершение 0 2h
zk-1 0/1 Завершение 0 2h
zk-1 0/1 Ожидание 0 0 с
zk-1 0/1 Ожидание 0 0 с
zk-1 0/1 В ожидании 0 12 мес.
zk-1 0/1 КонтейнерСоздание 0 12м
zk-1 0/1 Бег 0 13м
zk-1 1/1 Бег 0 13м
  
 Попытка осушить узел, на котором запланировано  zk-2 .
  kubectl Drain $ (kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
  
 Выход:
  Узел kubernetes-node-i4c4 уже оцеплен
ПРЕДУПРЕЖДЕНИЕ. Удаление модулей, не управляемых ReplicationController, ReplicaSet, Job или DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Игнорирование модулей, управляемых DaemonSet: узел-проблема-детектор-v0.1-dyrog
модуль "heapster-v1.2.0-2604621511-wht1r" удален
капсула "zk-2" удалена
узел "кубернетес-узел-i4c4" осушен
  
 На этот раз  kubectl сток  успешно.
 Отсоедините второй узел, чтобы разрешить перепланирование  zk-2 .
  kubectl uncordon kubernetes-node-ixsl
  
  узел "kubernetes-node-ixsl" без проводов
  
 Вы можете использовать  kubectl Drain  вместе с  PodDisruptionBudgets , чтобы ваши сервисы оставались доступными во время обслуживания.
Если дренаж используется для оцепления узлов и выселения контейнеров до перевода узла в автономный режим для обслуживания,
услуги, которые выражают бюджет нарушения, будут иметь этот бюджет.Вы всегда должны выделять дополнительную емкость для критически важных сервисов, чтобы их поды можно было немедленно перенести.
 Уборка 
 Используйте  kubectl uncordon , чтобы разъединить все узлы в кластере.
 Вы должны удалить постоянный носитель для PersistentVolumes, используемых в этом руководстве.
Выполните необходимые шаги в зависимости от вашей среды, конфигурации хранилища,
и метод предоставления, чтобы гарантировать, что все хранилище освобождено.
 Последнее изменение
 22 июля 2021 г., 20:27 по тихоокеанскому стандартному времени
 : Обновлен устаревший флаг kubectl delete-local-data (d095a148f) Что такое архитектура ZooKeeper 
 Что такое распределенная система? 
 Распределенное приложение - это приложение, которое может работать в нескольких системах в сети.Он работает одновременно, координируя свои действия для выполнения определенной задачи. Выполнение этих задач любым нераспределенным приложением может занять много часов.
 Что такое Zookeeper? 
  Apache Zookeeper  - это распределенная служба координации с открытым исходным кодом, которая помогает управлять большим набором хостов. Управление и координация в распределенной среде - непростая задача. Zookeeper автоматизирует этот процесс и позволяет разработчикам сосредоточиться на создании функций программного обеспечения, а не беспокоиться о его распределенном характере.
 Zookeeper помогает поддерживать информацию о конфигурации, именах и групповых службах для распределенных приложений. Он реализует различные протоколы в кластере, поэтому приложение не должно реализовываться самостоятельно. Он обеспечивает единое согласованное представление о нескольких машинах.
 В этом руководстве по Apache ZooKeeper вы узнаете:
 Почему Apache Zookeeper? 
 Вот важные причины популярности Zookeeper:
 Он допускает взаимное исключение и взаимодействие между серверными процессами.
 Он обеспечивает стабильную работу вашего приложения.
 Процесс транзакции никогда не завершается частично. Ему присваивается статус «Успех» или «Неудача». Распределенное состояние можно задержать, но это никогда не будет ошибкой
 Независимо от сервера, к которому он подключается, клиент сможет видеть то же представление службы
 Помогает вам кодировать данные в соответствии с определенным набором правила
 Это помогает поддерживать стандартное иерархическое пространство имен, подобное файлам и каталогам.
 Компьютеры, которые работают как единая система, которая может быть подключена локально или географически. в реальном времени
 Вы можете повысить производительность, развернув больше машин
 Это позволяет вам выбрать узел в качестве лидера для лучшей координации
 ZooKeeper работает быстрее с рабочими нагрузками, где чтение данных более распространено, чем запись
 Архитектура ZooKeeper: Как это устроено? 
 Вот краткое объяснение архитектуры Apache Zookeeper:
 Zookeeper следует архитектуре клиент-сервер
 Все системы хранят копию данных
 Лидеры выбираются при запуске
 Архитектура ZooKeeper  Сервер:  сервер отправляет подтверждение, когда любой клиент подключается.В случае отсутствия ответа от подключенного сервера клиент автоматически перенаправляет сообщение на другой сервер.
  Клиент : Клиент - это один из узлов в кластере распределенных приложений. Это помогает вам получать доступ к информации с сервера. Каждый клиент отправляет на сервер сообщение через равные промежутки времени, которое помогает серверу узнать, что клиент жив.
  Лидер:  Один из серверов назначен Лидером. Он предоставляет всю информацию клиентам, а также подтверждает, что сервер жив.Он выполнит автоматическое восстановление, если какой-либо из подключенных узлов вышел из строя.
  Последователь:  Узел сервера, который следует инструкции лидера, называется подчиненным.
 Клиентские запросы на чтение обрабатываются соответствующим подключенным сервером Zookeeper
 Клиентские запросы на запись обрабатываются лидером Zookeeper.
  Ансамбль / Кластер:  Группа серверов Zookeeper, которая называется ансамблем или Кластером. Вы можете использовать инфраструктуру ZooKeeper в кластерном режиме, чтобы оптимизировать систему при запуске Apache.
  ZooKeeper WebUI:  Если вы хотите работать с управлением ресурсами ZooKeeper, вам необходимо использовать WebUI. Это позволяет работать с ZooKeeper через веб-интерфейс пользователя вместо использования командной строки. Он предлагает быстрое и эффективное общение с приложением ZooKeeper.
 Модель данных Zookeeper (ZDM) 
 Теперь, в этом руководстве по ZooKeeper, давайте узнаем о модели данных Zookeeper. На приведенном ниже рисунке поясняется модель данных Apache Zookeeper:
 Модель данных zookeeper следует иерархическому пространству имен, где каждый узел называется ZNode.Узел - это система, в которой работает кластер.
 Каждый ZNode имеет данные. Он может иметь или не иметь дочерних узлов
 Пути ZNode: Канонические, разделенные косой чертой и абсолютные
 Не использовать никаких относительных ссылок
 Имена могут содержать символы Unicode
 ZNode поддерживает структуру статистики и номер версии для изменений данных.
 Типы узлов Zookeeper 
 Есть три типа Znodes:
  Постоянство  znode: Этот тип znode остается активным даже после того, как клиент, который создал этот конкретный znode, отключен.По умолчанию в zookeeper все узлы постоянны, если это не указано.
  Ephemeral  znode: этот тип zookeeper znode активен до тех пор, пока жив клиент. Следовательно, когда клиент отключается от zookeeper, он также будет удален. Более того, эфемерные узлы не имеют права иметь детей.
  Последовательный  znode: Последовательные znode могут быть временными или постоянными. Поэтому, когда новый znode создается как последовательный znode. Вы можете назначить путь к znode, добавив 10-значный порядковый номер к исходному имени.
 ZDM- Watches 
 Zookeeper, событие наблюдения - это одноразовый триггер, который отправляется клиенту, установившему наблюдение. Это произошло при изменении данных с этих часов. Часы ZDM позволяют клиентам получать уведомления при изменении znode. Операции чтения ZDM, такие как getData (), getChidleren (), существуют, имеют возможность установки часов.
 Часы заказаны, порядок событий часов соответствует порядку обновлений. Клиент сможет увидеть событие наблюдения для znode до того, как увидит новые данные, соответствующие этому znode.
 ZDM- Список контроля доступа 
 Zookeeper использует ACL для управления доступом к своим znodes. ACL состоит из пары (Схема: идентификатор, разрешение)
 Построить в схемах ACL:
 world: имеет один идентификатор, любой
 auth: Не использовать какой-либо идентификатор, он представляет любого аутентифицированного пользователя
 дайджест: использовать имя пользователя: пароль
 host: позволяет использовать имя хоста клиента в качестве идентификатора идентификатора ACL
 IP: использовать IP-адрес хоста клиента в качестве идентификатора идентификатора ACL
 Разрешения ACL:
 CREATE
 READ
 WRITE
 УДАЛИТЬ
 АДМИНИСТРАТОР
 E.Икс. (IP: 192.168.0.0/16, READ)
 ZKS - Состояния сеанса и время жизни 
 Перед выполнением любого запроса важно, чтобы клиент установил сеанс со службой
 Все операции, которые клиенты отправляют в службу, автоматически связывается с сеансом
 Клиент может подключаться к любому серверу в кластере. Но он будет подключаться только к одному серверу.
 Сеанс предоставляет «гарантии порядка». Запросы в сеансе выполняются в порядке FIFO
 Основными состояниями сеанса являются 1) Подключение, 2) Подключено 3) Закрыто 4) Не подключено.
 Как установить ZooKeeper 
  Шаг 1)  Перейдите по этой ссылке и нажмите «Продолжить подписку»  
  Шаг 2)  На следующей странице   Нажмите Принять условия
  Шаг 3)  Вы увидите следующее сообщение
  Шаг 4)  Обновите страницу через 5 минут и нажмите «Продолжить настройку»
  Шаг 5)  На следующем экране нажмите «Продолжить запуск»  
  Шаг 6 )  Готово!  
 Приложения Apache ZooKeeper 
 Apache Zookeeper, используемые для следующих целей:
 Управление конфигурацией
 Службы присвоения имен
 Выбор лидера
 Организация очереди сообщений
 Управление системой уведомлений
 Распределенная синхронизация
 Управление синхронизацией
 Компании, использующие Zookeeper 
 Yahoo
 Facebook
 eBay
 Twitter
 Netflix
 Zynga
 Nutanix
 Недостатки использования Zookeeper 
 При добавлении новых серверов Zookeeper
 может произойти потеря данных. Миграция не разрешена для пользователей
 Не поддерживает размещение в стойке и осведомленность
 Zookeeper не позволяет уменьшить количество модулей для предотвращения случайной потери данных
 Невозможно переключить службу на хост-сеть без полной повторной установки. я Установка при развертывании службы в виртуальной сети
 Служба не поддерживает изменение требований к объему, если начальное развертывание превышает
 Вовлечено большое количество узлов, поэтому может быть более одной точки отказа
 Сообщения могут быть потеряно в сети связи, для восстановления которой требуется специальное программное обеспечение
 Резюме 
 Распределенное приложение - это приложение, которое может работать в нескольких системах в сети
 Apache Zookeeper - это распределенная служба координации с открытым исходным кодом, которая помогает вам управлять большим набором хостов
 Обеспечивает взаимное исключение и взаимодействие между серверными процессами
 Сервер, клиент, лидер, ведомый, ансамбль / кластер, веб-интерфейс ZooKeeper являются важными компонентами zookeeper
 Три типа Znodes - постоянные, эфемерные и последовательные
 Часы ZDM - это одноразовый триггер, который отправляется на клиент, который установил часы.Это произошло, когда данные из этих часов меняются.
 Yahoo, Facebook, eBay, Twitter, Netflix - некоторые известные компании, использующие zookeeper
. Главный недостаток инструмента заключается в том, что при добавлении новых серверов Zookeeper
 могут возникнуть потери. Управление доступом к Apache ZooKeeper 
 . По соображениям безопасности вы можете ограничить доступ к узлам Apache ZooKeeper, которые являются частью
 из
 ваш кластер Amazon MSK.Для ограничения доступа к узлам можно назначить отдельную безопасность
 группа им. Затем вы можете решить, кто получит доступ к этой группе безопасности.
  Этот раздел содержит следующие разделы: 
 Для помещения узлов Apache ZooKeeper в отдельную группу безопасности 
 Получите строку подключения Apache ZooKeeper для вашего кластера.Чтобы узнать, как это сделать, см.
 Получение подключения к Apache ZooKeeper
 строка для кластера Amazon MSK. Строка подключения содержит
 DNS-имена ваших узлов Apache ZooKeeper.
 Используйте такой инструмент, как  host  или  ping , чтобы преобразовать DNS-имена.
 вы получили на предыдущем шаге IP-адреса.Сохраните эти IP-адреса, потому что
 они понадобятся вам позже в этой процедуре.
 Сохраните IP-адреса узлов Apache ZooKeeper, потому что они понадобятся вам позже.
 эта процедура.
 Войдите в Консоль управления AWS и откройте консоль Amazon EC2 по адресу
 https://console.aws.amazon.com/ec2/.
 На левой панели в разделе  СЕТЬ И БЕЗОПАСНОСТЬ  выберите  Сеть.
 Интерфейсы .
 В поле поиска над таблицей сетевых интерфейсов введите имя вашего
 кластер, затем введите return. Это ограничивает количество отображаемых сетевых интерфейсов.
 в таблице к тем интерфейсам, которые связаны с вашим кластером.
 Установите флажок в начале строки, соответствующей первому
 сетевой интерфейс в списке.
 На панели сведений внизу страницы найдите  Primary
 частный IPv4 IP .Если этот IP-адрес совпадает с одним из IP-адресов
 вы получили на первом этапе этой процедуры, это означает, что эта сеть
 интерфейс назначается узлу Apache ZooKeeper, который является частью вашего кластера.
 В противном случае снимите флажок рядом с этим сетевым интерфейсом и выберите
 следующий сетевой интерфейс в списке.Порядок, в котором вы выбираете сеть
 интерфейсы не имеет значения. На следующих этапах вы выполните те же операции.
 на всех сетевых интерфейсах, назначенных узлам Apache ZooKeeper, по очереди
 один.
 Когда вы выбираете сетевой интерфейс, соответствующий узлу Apache ZooKeeper,
 выберите меню  Действия  вверху страницы, затем выберите  Изменить группы безопасности .Назначьте новую группу безопасности этому
 сетевой интерфейс. Для получения информации о создании групп безопасности см. Создание группы безопасности в документации Amazon VPC.
 Повторите предыдущий шаг, чтобы назначить одну и ту же новую группу безопасности для всей сети.
 интерфейсы, связанные с узлами Apache ZooKeeper вашего
 кластер.
 Теперь вы можете выбрать, кто имеет доступ к этой новой группе безопасности. Для информации
 Сведения о настройке правил группы безопасности см. в разделе «Добавление, удаление и обновление правил» в документации Amazon VPC.
 Использование безопасности TLS с Apache ZooKeeper 
 Вы можете использовать безопасность TLS для шифрования при передаче между вашими клиентами и вашим
 Узлы Apache ZooKeeper.Чтобы реализовать безопасность TLS с вашими узлами Apache ZooKeeper,
 делать
 следующие:
 Кластеры должны использовать Apache Kafka версии 2.5.1 или новее для использования безопасности TLS с Apache
 Работник зоопарка.
 Включите безопасность TLS при создании или настройке кластера. Кластеры созданы с
 Apache
 Kafka версии 2.5.1 или более поздней с включенным TLS автоматически использует безопасность TLS.
 с конечными точками Apache ZooKeeper.Для получения информации о настройке безопасности TLS,
 см. Как мне начать работу с
 Шифрование ?.
 Получите конечные точки TLS Apache ZooKeeper с помощью операции DescribeCluster.
 Создайте файл конфигурации Apache ZooKeeper для использования со следующими командами интерфейса командной строки:
 Конфиг,
 ACL и ZooKeeper Shell.Вы используете файл конфигурации Apache Zookeeper с этими
 команды с помощью параметра  --zk-tls-config-file .
 В следующем примере показан типичный файл конфигурации Apache ZooKeeper:
  zookeeper.ssl.client.enable = true
zookeeper.clientCnxnSocket = org.apache.zookeeper.ClientCnxnSocketNetty
zookeeper.ssl.keystore.location = kafka.jks
zookeeper.ssl.keystore.password = test1234
zookeeper.ssl.truststore.location = truststore.jks
zookeeper.ssl.truststore.password = test1234  
 Для других команд (например,  kafka-themes ) необходимо использовать  KAFKA_OPTS  переменная среды для настройки Apache ZooKeeper
 параметры.В следующем примере показано, как настроить  KAFKA_OPTS  переменная среды для передачи Apache ZooKeeper
 параметры в другие команды:
  экспорт KAFKA_OPTS = "
-Dzookeeper.clientCnxnSocket = org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure = true
-Dzookeeper.ssl.trustStore.расположение = / домашний / ec2-пользователь / kafka.client.truststore.jks
-Dzookeeper.ssl.trustStore.password = changeit "
  
 После настройки переменной среды  KAFKA_OPTS  вы
 может нормально использовать команды CLI. В следующем примере создается Apache Kafka
 тема с использованием конфигурации Apache ZooKeeper из  KAFKA_OPTS  переменная окружения:
  bin / kafka-themes.sh --create --zookeeper  ZooKeeperTLSConnectString  - коэффициент репликации 3 --partitions 1 --topic AWSKafkaTutorialTopic  
 Имена параметров, которые вы используете в файле конфигурации Apache ZooKeeper и
 те вы
 использование в вашей  переменной среды KAFKA_OPTS  несовместимо.Платить
 внимание к тому, какие имена вы используете с какими параметрами в вашем файле конфигурации
 и  переменная среды KAFKA_OPTS .
 Для получения дополнительной информации о доступе к вашим узлам Apache ZooKeeper с помощью TLS см. KIP-515: Включение ZK-клиента для использования нового поддерживаемого TLS.
 аутентификация.
 .
Навигация по записям
Кт3157 параметры: Транзистор КТ3157 — DataSheet
Подключение сетевого инвертора: совместная работа инверторов Eltek Theia и МАП в солнечной электростанции
Похожие записи
 
 21.11.2024 0
 Особенности питания кормящей мамы: что можно и нельзя есть при грудном вскармливании
 
 19.11.2024 0
 Новорожденный какает слизью: причины появления слизи в кале грудничка
 
 19.11.2024 0
 Гемангиома у новорожденных: причины, виды, лечение и профилактика
Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий *
Имя * 
Email * 
Сайт 
  
Рубрики
 Карта сайта
 ©  M-Gen
  

  экспорт CLIENT_JVMFLAGS =" $ {CLIENT_JVMFLAGS} -Djava.security.auth.login.config = jaas.security.auth.login.config = jaas.conf "