java ugi确认框_在对hadoop进行任何操作之前，我应该调用ugi.checkTGTAndReloginFrom

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来确定票证是否“接近”到期。在实践中，我从未亲自看到重新登录的延迟有问题。