估计群集大小 - Pod
节点、Pod 和服务需要 IP 地址。 但是，如何确定所需的 IP 地址数？ 如要确定地址的数量，必须了解应用程序的特征。 首先，确定所需的 Pod 数。 然后，可查看所需的节点大小以及需要运行的节点数。
需要多少个 Pod？
你的应用程序在 Pod 中运行。 简单的应用程序可能完全在单个 Pod 中运行。 在更复杂的应用程序中，例如由多个单独的服务构成的微服务体系结构应用程序，每个服务可能在自己的 Pod 中运行，Pod 分布在多个节点上。
你需要完全了解应用程序的体系结构。 由此，可以计算出应用程序需要的 Pod 数量。 然后，你可以查看要运行的每个 Pod 的副本数。 你可能知道你的应用程序具有很大程度上可预测的使用模式，并且通过测试，你确定它在固定数量的 Pod 情况下运行效果最佳。 或者，你的应用程序可能经历需求增加或降低的时期，需要更改 Pod 的数量来响应流量的波动。 即使在使用模式不可预测的情况下，你仍然应该对应用程序可纵向扩展到的最大 Pod 数设置限制。 此限制可确保应用程序不会耗尽群集中的所有资源。
最好设置负载测试环境来评估所需的资源。 可以使用负载测试程序来模拟典型需求场景或峰值需求场景。 来自负载测试的数据可帮助你了解应用程序在不同情况下的工作情况。 在确定确保应用程序在所有情况下保持响应所需的 Pod 数量时，此信息非常有用。
应运行多少个 Pod？
你知道你的公司想要部署一个新的联机 Web 商店，其中包含多项服务。 你联系负责新商店的开发人员，询问服务相关信息。 下表显示了每个服务需要多少个副本。
| 服务 | 副本数下限 | 副本数上限 |
|---|---|---|
| 网站前端 | 3 | 10 |
| 标识 API | 3 | 5 |
| 目录 API | 3 | 10 |
| 订单 API | 3 | 5 |
| 订单帮助程序 | 3 | 5 |
| 购物车 API | 3 | 10 |
| 市场营销 API | 3 | 10 |
| 位置 API | 3 | 5 |
| 所有服务的副本总数 | 24 | 60 |
你的团队同意你应该为每个服务至少部署 3 个副本。 此配置确保应用程序可提供基线级别的性能和可用性。 每个开发团队都提供了他们应对需求（包括任何季节性高峰）所需的最大副本数。
使用表中的数字，我们可以计算出群集应运行的 Pod 副本的最小和最大数量：
- Pod 的最小数量为 24（有 8 个服务，每个服务至少运行 3 个副本）。
- 副本的最大数量为 60。
有了 Pod 的计划后，需要考虑将托管这些 Pod 的 Azure VM。