Нужна стратегия сохранения лидеров разделов при качающемся рестарте Кафки

Question

У меня есть кластер kafka с брокерами, распределенными в качестве контейнеров на узлы данных оркестром кочевников.

Всякий раз, когда я пытаюсь запустить контейнер или выполнить exec в контейнере, я получаю ошибку, подобную следующей:

root@ip-172-25-1-58:~# docker exec -it 4188ccb7f4a5 bash
rpc error: code = 5 desc = open /var/run/docker/libcontainerd/containerd/4188ccb7f4a5b45eec4d3254ad31db5308ad016982d8595acfe2d1b92f017f2f/0dab278911acc60fb7af41b6e0d8377194785b2853b3ca6da7a2bcf030110522/shim-log.json: no such file or directory

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

Однако я обеспокоен тем, что это делается на каждом из моих узлов данных - по одномуза один раз - это приведет к тому, что руководители разделов Кафки будут облажаны.

Буду очень признателен за идеи, которых можно избежать, исправить или смягчить.В идеале я хотел бы сохранить кластер Kafka вверх, но был бы заинтересован в решениях, которые также не удовлетворяли этому требованию.

Также очень интересно, есть ли способ заставить docker исправить себя без перезапуска containerd.

Контейнер Kafka основан на confluentinc / cp-kafka: 4.1.1

root@ip-172-25-1-58:~# docker version
Client:
 Version:           18.06.1-ce
 API version:       1.27 (downgraded from 1.38)
 Go version:        go1.10.4
 Git commit:        e68fc7a
 Built:             Fri Jan 25 14:33:54 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          17.03.2-ce
  API version:      1.27 (minimum version 1.12)
  Go version:       go1.6.2
  Git commit:       f5ec1e2
  Built:            Thu Jul  5 23:07:48 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Answer 1

Кафка отлично справляется с циклическим перезапуском.

При создании Кафка также постарается распределить как можно больше лидеров по кластеру, чтобы обеспечить «баланс лидеров».Также брокер, который является первоначальным лидером, становится предпочтительным лидером.

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

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