记一次HDFS Delegation Token失效问题(续)

在上篇讲到了,HDFS Delegation Token 问题的解决方法是 Spark-Submit 方式可以进行解决,经过了一段时间的反思和查看 Livy 和 Spark-Submit 两者日志之后,有了一点新发现,并且测试认证了,该方式是可行的,那么是怎么实现的呢?

上篇传输门:地址

上文我有提到 livy spengo 是通过代理的方式实现 Kerberos 的认证的,当使用类似于 Spark-Submit 方式 添加对应的 spark.yarn.keytabspark.yarn.principal Livy 日志中会存在 --proxy-user or --principal 的错误信息,在比对了两种方式的认证日志,发现 Livy 代理方式在 realUser 是 Livy,而 Spark-Submit 方式则为空。

因而联想到了,可能 Livy 代理模式导致这两种结果的不同。在查看 Livy 配置资料之后, livy.impersonation.enabled 配置有关,尝试将该配置项设为 false 。在通过上篇中的测试方法,将 dfs.namenode.delegation.key.update-interval,dfs.namenode.delegation.token.max-lifetime,dfs.namenode.delegation.token.renew-interval 进行相应的调小,帮助快速论证结果。需要注意的一点,在测试过程中,Spark 应用是需要发消息,也就是数据,不能仅仅是运行,因为如果不发消息,其实应用是没有在正常运行的,也就不会出现过期的问题了。

实验的结果是该种方式 Livy 是可以解决 HDFS Delegation Token 失效问题的。如果只是使用 Livy 方式提交,上篇中的 HDFS 的配置 hadoop.proxyuser.yarn.hosts=* 是不需要进行相应的修改的,在 HDP 环境中该配置是一个具体的 host 地址。

以上

图片描述

你可能感兴趣的:(kerberos)