1. Истекший ticket или неправильный ticket cache

Классический сценарий: пользователь запускает spark-submit, приложение стартует, но executors или long-running job начинают падать позже. В логах появляются GSSException, Client not found in Kerberos database, Failed to find any Kerberos tgt или ошибки доступа к HDFS/Hive. Проверять нужно не только klist на gateway, но и то, как ticket передается в YARN application, какой cache видит процесс и не истекает ли TGT раньше окончания расчета.

2. Keytab есть, но principal не совпадает с реальностью

Для сервисных запусков проблема часто не в отсутствии keytab, а в несовпадении principal, realm, hostname, прав на файл или параметров spark.yarn.principal и spark.yarn.keytab. Отдельно стоит проверять, не подменяется ли конфигурация через wrapper-скрипты, Airflow, Livy или CI/CD. На больших платформах такие ошибки выглядят как случайные падения, потому что разные entrypoint используют разные конфиги.

3. Delegation tokens не покрывают все сервисы

Spark может успешно получить HDFS token, но упасть при обращении к Hive Metastore, HBase, Kafka или другому защищенному сервису. Тогда Kerberos формально включен правильно, но конкретный путь данных не авторизован или не получил нужный token. Диагностика должна идти по фактическому data path: какие сервисы открывает driver, какие открывают executors, где именно появляется AccessControlException или SASL/GSSAPI ошибка.

4. Classpath и разные версии библиотек Hadoop/Spark/Hive

В несколько версий Spark среде похожие симптомы дает конфликт hadoop-auth, hive-exec, curator, jersey, protobuf или клиентских jar. Ошибка может маскироваться под Kerberos, хотя на самом деле executor загружает не ту библиотеку или берет конфиг не из того каталога. Поэтому рядом с security-проверками нужно смотреть effective classpath, spark-submit параметры, shuffle service, HADOOP_CONF_DIR и зависимости, которые приезжают вместе с приложением.

5. Ranger и политики доступа путают с Kerberos

Kerberos отвечает на вопрос кто ты, а Ranger - что тебе разрешено. Если аутентификация прошла, но Ranger policy не дает доступ к базе, таблице, HDFS path или Kafka topic, job падает уже на уровне авторизации. Хороший признак - в логах виден корректный authenticated user, но дальше идет Access denied. В этом случае лечить keytab бессмысленно: нужна проверка политик, групп, синхронизации пользователей и audit-событий Ranger.

Практический порядок диагностики

Начинайте с простого: klist, срок TGT, principal, keytab, HADOOP_CONF_DIR и effective spark-submit. Затем отделите driver от executor: где именно падает обращение к защищенному сервису. После этого проверьте delegation tokens, classpath, Ranger audit и сетевую доступность KDC/NameNode/Hive Metastore/Kafka. Такой порядок экономит часы, потому что команда перестает спорить «это Kerberos или Spark» и начинает проверять конкретную цепочку выполнения.

Что обычно быстрее приводит к исправлению

Падение Spark-джобы в Kerberos-среде редко лечится одной универсальной настройкой. Нужен короткий чек-лист, доступ к логам driver/executor, понимание data path и аккуратное разделение AuthN, AuthZ, classpath и YARN diagnostics. Такой разбор быстрее приводит к исправлению, чем перебор параметров вслепую.