Kyuubi项目Hive跨集群读写Kerberos认证问题解析
问题背景
在Kyuubi项目中,当用户尝试在两个启用了Kerberos认证的Hive集群之间进行跨集群读写操作时,遇到了认证失败的问题。具体表现为:在本地模式下运行Spark Shell时可以正常读写数据,但当提交到YARN集群运行时却出现AccessControlException异常,提示"Client cannot authenticate via:[TOKEN, KERBEROS]"。
问题现象
用户配置了两个Hive集群,并已建立Kerberos互信机制。在本地模式下使用如下配置启动Spark Shell时,可以成功查询数据:
spark-shell --master local[*] \
--conf "spark.sql.catalogImplementation=hive" \
--conf "spark.sql.catalog.reader_catalog=org.apache.kyuubi.spark.connector.hive.HiveTableCatalog" \
# 其他HDFS和Hive相关配置...
但当相同的代码提交到YARN集群运行时,却抛出认证异常,无法访问目标HDFS集群。
问题原因分析
这个问题主要源于YARN集群环境下Kerberos认证机制的差异:
-
本地模式与集群模式的区别:在本地模式下,Spark进程直接使用用户的Kerberos凭证进行认证;而在YARN集群模式下,任务会在不同的节点上执行,需要额外的配置来确保Kerberos凭证能够正确传播。
-
Hadoop安全机制:跨集群访问时,Spark需要明确知道需要访问哪些HDFS集群,以便获取相应的Kerberos票据。
-
认证方式限制:错误信息显示客户端无法通过TOKEN或KERBEROS方式认证,表明系统未能正确获取或使用Kerberos票据。
解决方案
针对这个问题,Kyuubi社区提供了两种解决方案:
-
配置spark.kerberos.access.hadoopFileSystems参数: 这个参数需要列出所有需要访问的HDFS集群地址,例如:
--conf "spark.kerberos.access.hadoopFileSystems=hdfs://cluster-a,hdfs://cluster-b"这样Spark就能知道需要为哪些HDFS集群获取Kerberos票据。
-
使用keytab方式提交Spark应用: 通过指定principal和keytab文件来提交作业,确保所有节点都能使用相同的凭证:
spark-shell --principal <principal> --keytab <keytab_path> ...
技术原理深入
Kerberos在分布式环境中的认证流程:
- 客户端首先向KDC获取TGT(Ticket Granting Ticket)
- 使用TGT获取服务票据(Service Ticket)
- 使用服务票据访问具体服务
在跨集群场景下,Spark需要:
- 为每个需要访问的HDFS集群获取独立的服务票据
- 确保这些票据能够在所有执行节点上可用
- 正确处理票据的更新和续期
最佳实践建议
- 对于生产环境,推荐使用keytab方式提交作业,更加稳定可靠
- 确保所有涉及的HDFS集群地址都正确配置在spark.kerberos.access.hadoopFileSystems中
- 定期更新keytab文件,避免票据过期导致作业失败
- 在YARN配置中设置适当的票据更新间隔
总结
Kyuubi项目在跨Kerberos认证的Hive集群间进行数据读写时,需要特别注意认证凭证的传播和配置。通过合理配置spark.kerberos.access.hadoopFileSystems参数或使用keytab提交方式,可以有效解决这类认证问题。这体现了在安全认证环境下进行跨集群数据访问时,凭证管理和传播机制的重要性。
Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型,它在 Kimi-K2-Base 的基础上,通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式,以及对话式与智能体范式无缝融合。Python00
GLM-4.7-FlashGLM-4.7-Flash 是一款 30B-A3B MoE 模型。作为 30B 级别中的佼佼者,GLM-4.7-Flash 为追求性能与效率平衡的轻量化部署提供了全新选择。Jinja00
VLOOKVLOOK™ 是优雅好用的 Typora/Markdown 主题包和增强插件。 VLOOK™ is an elegant and practical THEME PACKAGE × ENHANCEMENT PLUGIN for Typora/Markdown.Less00
PaddleOCR-VL-1.5PaddleOCR-VL-1.5 是 PaddleOCR-VL 的新一代进阶模型,在 OmniDocBench v1.5 上实现了 94.5% 的全新 state-of-the-art 准确率。 为了严格评估模型在真实物理畸变下的鲁棒性——包括扫描伪影、倾斜、扭曲、屏幕拍摄和光照变化——我们提出了 Real5-OmniDocBench 基准测试集。实验结果表明,该增强模型在新构建的基准测试集上达到了 SOTA 性能。此外,我们通过整合印章识别和文本检测识别(text spotting)任务扩展了模型的能力,同时保持 0.9B 的超紧凑 VLM 规模,具备高效率特性。Python00
KuiklyUI基于KMP技术的高性能、全平台开发框架,具备统一代码库、极致易用性和动态灵活性。 Provide a high-performance, full-platform development framework with unified codebase, ultimate ease of use, and dynamic flexibility. 注意:本仓库为Github仓库镜像,PR或Issue请移步至Github发起,感谢支持!Kotlin07
compass-metrics-modelMetrics model project for the OSS CompassPython00