Одна изначально неочевидная вещь в Kubernetes заключается в том, что изменение ConfigMap (набора значений конфигурации) не определяется как изменение в Deployments (как Pod или набор Pod должны быть развернуты в кластере) или Pod. что ссылка на эту конфигурацию. Это ожидание может привести к непреднамеренному сохранению устаревшей конфигурации до изменения спецификации Pod. Это может включать в себя только что созданные модули из-за события автоматического масштабирования или даже перезапускается после сбоя, что приводит к неправильной конфигурации и непредвиденному поведению в кластере.
Примечание. Это не влияет на ConfigMaps, смонтированные как тома,которые периодически синхронизируются запущенным на каждом узле kubelet.
Для обновления configmap выполните:
$ kubectl replace -f file.yaml
Прежде чем использовать его, необходимо создать ConfigMap. Поэтому я рекомендую сначала изменить configMap, а затем заново развернуть модуль.
Обратите внимание, что контейнер, использующий ConfigMap в качестве монтируемого тома subPath , не будет получать обновления ConfigMap.
Ресурс configMap предоставляет способ внедрения конфигурацииданные в стручки. На данные, хранящиеся в объекте ConfigMap, можно ссылаться в томе типа configMap, а затем использовать в контейнерах приложений, работающих в модуле.
При ссылке на объект configMap вы можете просто указать его имя в томе для ссылкиЭто. Вы также можете настроить путь, который будет использоваться для конкретной записи в ConfigMap.
Когда обновляется ConfigMap, уже используемый в томе, спроецированные ключи в конечном итоге также обновляются. Kubelet проверяет, является ли установленный ConfigMap свежим при каждой периодической синхронизации. Тем не менее, он использует свой локальный кэш на основе ttl для получения текущего значения ConfigMap. В результате общая задержка с момента обновления ConfigMap до момента, когда новые ключи проецируются на модуль, может составлять столько же, сколько период синхронизации kubelet (1 минута по умолчанию) + ttl кэша ConfigMaps (1 минута по умолчанию)) в kubelet.
Но я настоятельно рекомендую вам использовать Kubernetes Operator для Spark . Он поддерживает монтирование томов и ConfigMaps в модулях Spark для их настройки. Эта функция недоступна в Apache Spark начиная с версии 2.4.
SparkApplication может указывать Kubernetes ConfigMap, хранящий файлы конфигурации Spark, такие как spark-env. sh или spark-defaults.conf с использованием необязательного поля .spec.sparkConfigMap, значением которого является имя ConfigMap. Предполагается, что ConfigMap находится в том же пространстве имен, что и SparkApplication. Spark на K8S предоставляет параметры конфигурации, которые позволяют монтировать определенные типы томов в модули драйвера и исполнителя. Объемы «доставляются» со стороны Kubernetes, но они могут быть доставлены из локального хранилища в Spark. Если в качестве локального хранилища не задан том, Spark использует временное пространство для хранения данных, чтобы пролить данные на диск во время перемешивания и других операций. При использовании Kubernetes в качестве менеджера ресурсов модули будут создаваться с томом emptyDir, смонтированным для каждого каталога, указанного в spark.local.dir, или переменной среды SPARK_LOCAL_DIRS. Если никакие каталоги не указаны явно, тогда каталог по умолчанию создается и настраивается соответствующим образом.
Полезный блог: spark-kubernetes-operator .