Как справиться с постоянной / зависимой от состояния неудачей запуска модуля в Kubernetes?

Question

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

[2019-05-25 09:11:33,980] ERROR [KafkaServer id=0] Fatal error during KafkaServer startup. Prepare to shutdown (kafka.server.KafkaServer)
org.apache.kafka.common.KafkaException: Failed to acquire lock on file .lock in /opt/kafka/data/logs. A Kafka instance in another process or thread is using this directory.
    at kafka.log.LogManager$$anonfun$lockLogDirs$1.apply(LogManager.scala:240)
    at kafka.log.LogManager$$anonfun$lockLogDirs$1.apply(LogManager.scala:236)
    at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:241)
    at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:241)
    at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
    at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
    at scala.collection.TraversableLike$class.flatMap(TraversableLike.scala:241)
    at scala.collection.AbstractTraversable.flatMap(Traversable.scala:104)
    at kafka.log.LogManager.lockLogDirs(LogManager.scala:236)
    at kafka.log.LogManager.<init>(LogManager.scala:97)
    at kafka.log.LogManager$.apply(LogManager.scala:953)
    at kafka.server.KafkaServer.startup(KafkaServer.scala:237)
    at io.confluent.support.metrics.SupportedServerStartable.startup(SupportedServerStartable.java:114)
    at io.confluent.support.metrics.SupportedKafka.main(SupportedKafka.java:66)

Я установил Kafka с помощью официального шлемапоэтому я предполагаю, что настройка модулей Kafka и zookeeper, а также присвоение постоянным томам и утверждениям подходит для Kubernetes.

Прежде всего: это хорошая идея для сохранения рабочего состояния напостоянный объем?Поскольку предполагается, что стручки ненадежны и в любой момент могут потерпеть крах или быть выселены, этот метод очень подвержен ошибкам.Должен ли я считать это ошибкой или недостатком, о котором стоит сообщить авторам рулевой диаграммы?

Так как ошибки существуют, и другое программное обеспечение может сохраняться, это работает на постоянном томе, я заинтересован в общем подходе передовой практикикак перевести постоянный том в состояние, когда модуль, использующий его, может начать снова (в этом случае это может быть удаление файла блокировки из /opt/kafka/data/logs afaik).

До сих пор я пытался запустить консоль вОболочка контейнера и попробуйте выполнить команду, чтобы удалить файл до сбоя модуля.Это требует некоторых попыток и очень раздражает.

Я испытываю это с microk8s 1.14.2 (608) в Ubuntu 19.10, но я думаю, что это может произойти в любой реализации Kubernetes.

Answer 1

Чтобы решить эту ошибку, я думаю, нам просто нужны спецификации PreStart и PreStop Hook in Kafka pod, как и другие официальные схемы руля.

containers:
  - name: kafka-broker
    ...
    lifecycle:
      preStart:
        exec:
          command:
            - "/bin/sh"
            - "-ec"
            - |
              rm -rf ${KAFKA_LOG_DIRS}/.lock
      preStop:
        exec:
          command:
          - "/bin/sh"
          - "-ec"
          - "/usr/bin/kafka-server-stop"