对正常运行时间具有最高要求的组织必须能够承受更加严重的中断，例如整个可用性区域 (AZ) 的丢失。 虽然在托管云提供商中配置跨多个 AZ 的 Kubernetes 集群是一项简单的任务，但在 ArcGIS Enterprise on Kubernetes 软件的部署、配置和操作阶段，必须考虑其他管理要求。
以下部分描述了在配置组织之前必须考虑的事项和必须满足的要求、AZ 内功能丢失的预期影响，以及管理员如何在该 AZ 功能恢复后验证底层系统的运行状况。
部署应用程序的 Kubernetes 集群至少必须满足以下要求：
- 工作节点组至少跨三个 AZ。
- 充足的工作节点容量，可在中断期间将所有工作负载重新平衡到两个 AZ。
部署和配置
部署 ArcGIS Enterprise on Kubernetes 到多 AZ 集群时，有状态工作负载的存在意味着使用块存储设备时关联磁盘存在 AZ 依赖性。
为了确保每个有状态集的关联复本分布在相应拓扑中，将在部署属性文件中引入一个新属性 K8S_AVAILABILITY_TOPOLOGY_KEY，必须在运行部署脚本之前更新该属性。 将此属性更新为除了 kubernetes.io/hostname 之外的任何值都会向有状态集引入 topologySpreadConstraint 规范，由此确保在任何单个 AZ 中都不会出现不等的平衡或复本。 大多数云提供商中的 AZ 结点标注密钥是 topology.kubernetes.io/zone。
为了保证组织配置期间的最高可用性，请使用增强可用性架构配置文件配置组织。 在出现 AZ 故障时，这是确保充分覆盖所有有状态工作负载的唯一配置文件。
即使在使用增强可用性架构配置文件时，仍有许多部署保留在单个复本中，因为这些部署根据特定组织要求而存在很大差异。 请考虑以下部署来扩展到单个复本之上，进一步减少停机时间：
- arcgis-enterprise-apps
- arcgis-enterprise-manager
- arcgis-enterprise-portal
- arcgis-enterprise-web-style-app
- arcgis-help
- arcgis-javascript-api
- arcgis-service-api
- arcgis-service-lifecycle-manager
- arcgis-featureserver-webhook-processor
- arcgis-gpserver-webhook-processor
与关系数据存储故障转移过程相比，除了 arcgis-enterprise-web-style-app 之外，以上列出的每个部署在 AZ 丢失后重新启动所需的时间均更短。 扩展到所有已列出部署的附加复本将为总命名空间请求添加大约 1 个附加 CPU 和 0.5 GiB 附加 RAM，并为总命名空间限制添加 5 个附加 CPU 和 2.5 GiB 附加 RAM。
当发布服务时，应将所有专用服务设置为至少运行两个 Pod，确保重新调度期间不会发生中断。 出于相同目的，还应将共享实例部署扩展为至少两个复本。
AZ 丢失的影响
AZ 丢失的含义和影响取决于受影响的云服务。 特定服务（例如计算或存储）的丢失可能会对正在运行的工作负载产生重大影响，而其他基于网络的中断（例如 DNS 解析或延迟急剧增加）可能会影响微服务之间的通信方式。
在关系存储故障转移期间，某些功能（例如登录、托管要素服务编辑和托管图层加载）可能会在短时间内降级。 当完成将备用实例升级为主实例后，所有组织功能均应处于稳定状态。
组织运行状况验证
管理员可以使用集成的运行状况检查报告以评估其站点的运行状况。 管理员还可以检查命名空间的工作负载，以了解 Pod 启动中的问题以及可能出现的其他挑战。
可用性区域中断期间
如果在使用 PV 块存储时丢失 AZ，则由于卷关联性要求，无法将有状态集 Pod 重新调度到其他 AZ。
对于需要其的数据存储，将会维护仲裁，以便关联服务能够在降级状态下运行。 由于关系存储是其他几个服务所依赖的核心组件，因此可以通过管理 API 重置备用数据库。 这将删除有状态集和关联的 PVC 并创建一个新的有状态集。 允许备用实例在移入剩余可用区之一后与主实例同步。
可用性区域中断后
当发生中断的 AZ 中的服务恢复时，将重新启动处于待处理状态的关联工作负载，这可以通过 Kubernetes API 确认。
如果现有 AZ 无法恢复服务，请确保集群至少有 3 个剩余 AZ。 如果没有，请将集群扩展到其他 AZ。 完成后，请创建备份、取消部署并重新部署，然后根据备份执行恢复操作。