发布 GIS 服务后，最佳做法是对其进行监控，例如通过查看服务使用情况统计数据，从而了解使用模式以及如何根据您观察到的流量相应地调整资源。 随着流量模式和用户对服务的需求出现变化，您可以通过多种方式做出相应的响应。 为了满足需求和性能预期，请考虑以下方法来优化服务资源：
- 调整服务模式，最大限度地利用服务专用资源。
- 通过指定要为服务分配的 Pod 数量来手动扩缩服务。
- 通过指定将自动为服务分配的 Pod 阈值来启用自动扩缩。
在确定要选择的选项时，请考虑以下情况。
扩缩类型
您可以手动扩缩服务，也可以使用自动扩缩功能自动扩缩服务。 在这两种情况下，扩缩服务的方法的特点是水平（向内或向外）扩缩或垂直（向上和向下）扩缩。 无论服务的配置模式是共享模式还是专用模式，都可对其进行扩缩。
- 水平扩缩 - 向服务部署添加更多 Pod。 例如，从一个 Pod 扩展到多个 Pod。 支持手动和自动扩缩。
- 垂直扩缩 - 将 CPU 或内存添加到部署中的当前 Pod 集。 支持手动扩缩。
当您增加可用于服务的 Pod 数量时，Kubernetes 集群将生成服务部署的现有 Pod 的其他复本，包括其服务配置和 Pod 内的服务实例。
扩缩还会增加服务的内存和 CPU 消耗，以及服务实例的可用性和总吞吐量。 因为您正在扩缩 Kubernetes 基础架构，所以该选项具有容错性；发生故障的 Pod 将自动恢复，而不会影响其他 Pod。 它还允许独立和隔离扩缩，而不会影响系统内的其他服务或其他组件。
注：
部署组织的 Kubernetes 集群具有有限数量的计算机节点。 通过手动或自动扩缩许多 GIS 服务，组织可能会达到分配给 ArcGIS Enterprise on Kubernetes 的计算机资源的限制。 如果发生这种情况，请与您的 IT 管理员一起将更多节点添加到 Kubernetes 集群中。 请考虑在您的环境中使用 Cluster Autoscaler 作为解决方案。
水平扩缩
水平扩缩将向服务部署添加更多 Pod。 例如，从一个 Pod 扩展到多个 Pod。 它同时支持手动和自动扩缩。
以上示例说明了在专用模式下运行的地理处理服务的水平扩缩。 当需要附加 Pod 时，将相应地手动或自动调整服务部署。 在本示例中，会将一个附加 Pod 复本添加到服务部署。
在以下示例中，通过将 Pod 复本添加到部署来水平扩展共享要素服务部署。 在初始共享资源集中，3 个要素服务由 4 个 Pod 提供支持。 随着稳定需求的增加，服务部署中的 Pod 已增加到 8 个。
垂直扩缩
垂直扩缩可将 CPU 或内存添加到部署的当前 Pod 集中，并支持手动扩缩。
以上示例说明了在专用模式下运行的影像服务的垂直扩缩。 当需要附加容量时，可以相应地手动或自动调整一个或多个专用 Pod。 在这种情况下，会将增加的资源（CPU、内存或两者）分配给 Pod。
在另一个示例中，当专用模式下的地图服务不再需要附加资源时，会对其资源进行垂直缩减。
在以下示例中，垂直扩缩用于共享地图服务部署。 当需要 CPU 或内存时，可以相应地调整专用 Pod。 在这种情况下，会将增加的 CPU 或内存资源分配给 3 个参与的 Pod。
场景
为了满足性能需求，并同时节约组织对资源的使用，了解何时以及如何扩缩可用于服务的资源非常重要。 以下示例是组织管理员在扩缩其资源时需要考虑的假设情景：
- 公共组织中的 Web 地图突然收到高流量，并且用户遇到性能延迟。 组织管理员查看系统日志并确定 Web 地图使用的地图服务负担过重。 首先，他们将服务模式从使用共享资源更改为使用专用资源。 接下来，可为服务部署增加 Pod 复本。 通过为地图服务提供专用资源，管理员可以确保处理服务的高流量而不会出现性能问题。
- 一家测量公司已在其组织中积累了数百项要素服务。 它们全部设置为共享模式，因此会有一种服务部署支持它们。 所有服务的流量都不会很高，但是组织 GIS 内容的整体使用给服务部署带来了负担。 组织管理员选择通过增加服务部署中的 Pod 复本数量来手动扩展服务。 通过运行更多共享实例，可以充分处理组织的许多要素服务的流量。
- 在内容迁移工程期间，市政府的 GIS 组织会将许多 Web 地图和 Web 图层重新发布到组织。 由于时间限制，他们希望尽快完成。 由于发布 Web 地图和 Web 图层的底层服务是由 PublishingTools 实用程序服务执行的，因此可用于该实用程序服务的计算机资源决定了发布的速度。 组织管理员会临时增加 PublishingTools 服务部署中的 Pod 复本，以提高工程期间的发布效率。 工程完成后，他们会减少服务部署中的 Pod 复本以节省计算机资源。
回顾以上前两个情景，如果地图服务负担过重或者同时使用大量要素服务导致系统负担过重，则手动扩缩专用地图服务或者共享要素服务部署可能不是最可行的方法。 手动扩缩需要持续监控负载并了解负载模式以确定要扩缩到的 Pod 数量。 如果负载呈间歇性且不可预测，则在系统负载不大的情况下，手动添加大量 Pod 会导致资源浪费。 相反，您希望系统能够向外扩展，因为需要更多的 Pod 来处理更重的负载。
这可能是管理员利用自动扩缩的最佳案例。 自动扩缩允许您保持最小数量的 Pod，并根据已设置的 CPU 阈值来设置系统可向外扩缩到的最大 Pod 数量。 此方法可自动检测何时增加或减少 Pod 以响应负载变化。 无需持续监控系统，并节省系统资源。
调整服务模式
如果使用共享资源的地图或要素服务所接收的流量恒定，则可以调整服务模式以使用专用资源。 随即打开一个专用于该服务的新服务资源池。
手动扩缩
当服务需求可预测或者稳定时，可以通过指定分配给服务的 Pod 数量或者增加服务可用的资源（CPU/内存）来手动扩展服务部署。 当面向服务的专用资源数量不足且用户出现了性能延迟时，可使用此选项。
如果在监控服务后发现需求有所增加，或者如果报告了服务的性能问题，则可以根据需要增加 Pod 的数量。 如果需求开始下降，则可以减少 Pod 的数量。
自动扩缩
如果服务需求不可预测或呈间歇性，则可以启用自动扩缩以最大限度地提高跨系统资源的效率。
如果在服务上启用自动扩缩，则服务部署中的 Pod 复本将自动增加或减少以满足需求。 服务部署将使用预定义的条件（例如 CPU 或内存）来计算对更多或更少 Pod 的需求，并相应地进行调整。
注：
要在 ArcGIS Enterprise on Kubernetes 中应用水平 Pod 自动扩缩，需要使用指标服务器从每个运行节点上的 kubelet 收集 Pod 资源消耗指标。 有关详细信息，请参阅 Kubernetes Metrics Server。
服务实例的角色
未托管的服务部署（如地图、图像、地理处理或地理编码）包含在服务部署的每个 Pod 中运行的服务实例。 这些代表每个 Pod 的容量，并且是用于处理对任何这些服务的请求的底层进程。 支持调整和扩缩这些过程；但是，建议您改为在 Pod 级别进行调整和扩缩，以利用 Kubernetes 的优势（容错、隔离、弹性、自动扩缩等）。