最近，我们在对几个学员进行sapdatahub环境培训时遇到了一些问题，该环境运行在部署在Azure上的Kubernetes集群上。如果使用高级网络默认部署Kubernetes，则每个节点的pod限制为30个pod。这是您在安装之前需要考虑的问题，因为它只能在集群的初始部署期间设置，并且之后不能更改（请参阅本文）。

我们在Azure上的kubernetes集群上部署了SAP Datahub，该集群当前运行3个节点（8个VCPU，32 GB内存）。对于我们看到的那些小练习来说，这本应该足够了，但我们还是遇到了问题。将资源扩展到8个节点暂时解决了这个问题，但很快我们又遇到了问题。以下是原因解释：

集群中的每个节点限制为30个pod。在启动kubernetes集群时，kubernetes本身已经在每个节点上启动了多个pod，为将部署到集群上的应用程序提供多个服务：

网络服务dns服务代理服务kubernets仪表板监控服务…

如果你看看我们的3节点部署，已经有25个pod被kuberenetes自己占用了：

此外，datahub安装需要相当数量的pod来运行，以提供运行环境所需的所有核心服务。如果我看一下kubernetes"SAPDATAHUB"（我们在kuberenetes中部署datahub的名称空间）中的pod，我们有51个pod为核心系统运行。实际上是49个，啥叫人工智能，因为在使用了sapdatahub启动板和系统管理之后有2个pod，我将在后面解释。

kuberenetes使用的25个pod和means使用的49个pod在我们的3节点部署上可用的90个pod中有76个已经使用，我甚至还没有开始使用该应用程序。因为，当您启动Datahub启动板时，集群上会启动一个pod。一旦您通过单击其中一个互动程序启动datahub应用程序，电梯物联网，集群上至少会启动一个其他pod。

如果我开始使用连接管理、元数据资源管理器、建模器、Vora工具和系统管理，您可以在Kuberenets仪表板中检索这些pod。使用launchpad并启动应用程序启动专用于用户的pod。这意味着另一个用户将启动另一组专用于其用户的pod。首次以新用户身份使用启动板和应用程序时遇到的初始延迟是由群集上所需的pod的启动引起的。

请注意，即使您注销datahub，淘客联盟，启动板和应用程序pod在群集上仍保持活动状态。以前已经登录的用户将重用已经启动的pod。但是，您会注意到您不再具有初始启动延迟。

如果您开始通过"元资源管理器"进行数据分析，或开始执行您在"建模器"中创建的图形，则所需的进程将通过向集群提交pod来执行其执行任务。下一个屏幕截图显示了通过在数据集上启动分析作业启动的附加pod。

在分析的情况下，启动一个协调器pod，该协调器pod将保持活动状态并专用于用户，其他pod将结束并释放它们运行的kubernetes节点上的pod分配。

一旦运行到pod限制，pods将不再启动并开始等待pod插槽被完成的pods释放，或者通过添加新节点来扩展kubernetes集群而变得可用的pod插槽。释放一些pod的另一种方法是删除一些用户的应用程序实例，这些用户使用通过Launchpad提供的系统管理应用程序。删除用户实例也会删除相关的pod.

为了解决我们在培训过程中遇到的问题，自助建站源码，我们增加了一些节点，但是由于pod的限制，两个培训用户会完全分配一个8vcpu、32gb的VM，使可用资源得不到充分利用。当查看cpu和内存请求时，相关节点仅分配了cpu和内存的1/3。如果你用一个更强大的vm来启动kubernetes集群，资源损失会更大。

所以在部署kubernetes集群时，你应该考虑一个高于30的pod限制。Azure允许最大pod限制为250，而kubernetes不建议超过100。

请随时发表评论或反馈。

，采购返利