Hadoop提交者在这里!这是一个很好的问题。
不幸的是,如果不深入研究应用程序的特定使用模式,很难给出明确的答案。相反,我可以提供一般准则,并描述Hadoop何时为您自动处理票证更新或从keytab重新登录,以及何时不这样做。
Hadoop生态系统中Kerberos身份验证的主要用例是Hadoop的RPC框架,该框架使用SASL进行身份验证。Hadoop生态系统中的大多数守护进程都通过UserGroupInformation#loginUserFromKeytab在进程启动时进行一次一次性调用来处理此问题。这样的示例包括HDFS DataNode和YARN NodeManager,该HDFS DataNode必须对其对NameNode的RPC调用进行身份验证,而YARN NodeManager必须对对ResourceManager的调用进行身份验证。像DataNode这样的守护程序如何在进程启动时进行一次登录,然后继续运行数月,这比典型的票证到期时间还长呢?
由于这是一个常见用例,因此Hadoop直接在RPC客户端层内部实现自动重新登录机制。此代码在RPC Client#handleSaslConnectionFailure方法中可见:
// try re-login
if (UserGroupInformation.isLoginKeytabBased()) {
UserGroupInformation.getLoginUser().reloginFromKeytab();
} else if (UserGroupInformation.isLoginTicketBased()) {
UserGroupInformation.getLoginUser().reloginFromTicketCache();
}
您可以将其视为重新登录的“惰性评估”。它仅在尝试进行RPC连接时由于身份验证失败而重新执行登录。
知道这一点,我们可以给出部分答案。如果您的应用程序的使用模式是从密钥表登录,然后执行典型的Hadoop RPC调用,那么您可能不需要滚动自己的重新登录代码。RPC客户端层将为您完成此任务。“典型的Hadoop RPC”表示用于与Hadoop交互的绝大多数Java API,包括HDFS FileSystemAPI,YarnClient和MapReduce Job提交。
但是,某些应用程序使用模式根本不涉及Hadoop RPC。这样的一个示例是仅与Hadoop的REST API(例如WebHDFS或YARN REST API)交互的应用程序。在这种情况下,身份验证模型会通过Hadoop HTTP身份验证文档中所述通过SPNEGO使用Kerberos 。
知道这一点,我们可以在答案中添加更多内容。如果您的应用程序的使用模式根本不使用Hadoop RPC,而是仅使用REST API,那么您必须滚动自己的重新登录逻辑。正如您所注意到的,这就是为什么WebHdfsFileSystem打电话的UserGroupInformation#checkTGTAndReloginFromkeytab原因。 WebHdfsFileSystem选择在每次操作前立即拨打电话。这是一个不错的策略,因为UserGroupInformation#checkTGTAndReloginFromkeytab仅在“接近”到期时更新票证。 否则,该呼叫为无人操作。
作为最终用例,让我们考虑一个交互式过程,而不是从keytab登录,而是要求用户kinit在启动应用程序之前在外部运行。在大多数情况下,它们将是短期运行的应用程序,例如Hadoop CLI命令。但是,在某些情况下,这些过程可能是运行时间更长的过程。为了支持运行时间更长的流程,Hadoop启动了一个后台线程来将Kerberos票证“关闭”更新为到期。该逻辑在UserGroupInformation#spawnAutoRenewalThreadForUserCreds。与RPC层中提供的自动重新登录逻辑相比,这里有一个重要的区别。在这种情况下,Hadoop仅具有续签和延长其寿命的功能。根据Kerberos基础结构的规定,票证具有最大的可再生寿命。之后,该票将不再可用。在这种情况下,重新登录实际上是不可能的,因为这将暗示重新提示用户输入密码,并且他们很可能已离开终端。这意味着,如果该进程持续运行到票证到期之后,它将无法再进行身份验证。
同样,我们可以使用此信息来告知我们的总体答案。如果您kinit在启动应用程序之前依靠用户以交互方式登录,并且您确信该应用程序的运行时间不会超过Kerberos票证的最大可再生寿命,那么您可以依靠Hadoop内部构件来为您进行定期更新。
如果您使用的是基于keytab的登录,并且只是不确定应用程序的使用模式是否可以依赖Hadoop RPC层的自动重新登录,那么保守的方法是自行滚动。@SamsonScharfrichter在这里给自己一个很好的答案。
HBase Kerberos连接更新策略
最后,我应该添加有关API稳定性的注释。该Apache Hadoop Compatibility指南详细讨论了Hadoop开发社区对向后兼容的承诺。的接口UserGroupInformation带有LimitedPrivate和Evolving。从技术上讲,这意味着的API UserGroupInformation不被认为是公共的,并且可能以向后不兼容的方式发展。实际上,已经有很多代码取决于的接口UserGroupInformation,因此对我们来说,做出重大更改根本不可行。当然,在当前的2.x发行版中,我不会担心方法签名会从您的下方更改并破坏您的代码。
现在,我们已经掌握了所有这些背景信息,让我们重新讨论您的具体问题。
是否可以在需要时依赖它们调用checkTGTAndReloginFromKeytab的各种Hadoop客户端?
如果您的应用程序的使用模式是调用Hadoop客户端,那么您可以依靠它,而Hadoop客户端又利用Hadoop的RPC框架。如果您的应用程序的使用模式仅调用Hadoop REST API,则您不能依靠它。
我应该在自己的代码中自称checkTGTAndReloginFromKeytab吗?
如果您的应用程序的使用模式仅是调用Hadoop REST API而不是Hadoop RPC调用,则可能需要执行此操作。您将无法从Hadoop的RPC客户端内部实现的自动重新登录中受益。
如果是这样,我应该在每次调用ugi.doAs(...)之前执行此操作,还是设置一个计时器并定期(多长时间一次)调用一次?
可以UserGroupInformation#checkTGTAndReloginFromKeytab在需要验证的每个操作之前立即进行调用。如果票证即将到期,则该方法将为无操作。如果您怀疑Kerberos基础结构缓慢,并且您不希望客户端操作支付重新登录的延迟成本,那么这就是在单独的后台线程中进行此操作的原因。只要确保在机票的实际到期时间之前提前一点时间即可。您可以借用内部逻辑UserGroupInformation来确定票证是否“接近”到期。在实践中,我从未亲自看到重新登录的延迟有问题。
如果觉得《java ugi确认框_在对hadoop进行任何操作之前 我应该调用ugi.checkTGTAndReloginFrom》对你有帮助,请点赞、收藏,并留下你的观点哦!