本系列教程适用于想要部署、运行和管理在 Google Kubernetes Engine (GKE) Enterprise 版本上运行的现代应用环境的 IT 管理员和运维人员。在学习本系列教程的过程中，您将学习如何使用 Cymbal Bank 示例微服务应用配置监控和提醒、扩缩工作负载以及模拟故障。
概览和目标
应用应该能够承受中断和故障。此功能使用户可以在出现问题时继续访问您的应用。Cymbal Bank 示例应用旨在处理故障并继续运行，您无需进行问题排查和修复。为了提供这种弹性，GKE 区域级集群会跨可用区分布计算节点，Kubernetes 控制器会自动响应集群内的服务问题。
在本教程中，您将学习如何模拟 Google Cloud 中的故障，并了解 Google Kubernetes Engine (GKE) 企业版集群中的应用 Service 如何响应。您将学习如何完成以下任务：
- 查看节点和 Service 的分布。
- 模拟节点或可用区故障。
- 验证 Service 是否继续在其余节点上运行。
费用
您将为本系列教程启用 GKE Enterprise 并部署 Cymbal Bank 示例应用，这意味着您需要按照我们价格页面中列出的价格，按集群为 GKE Enterprise on Google Cloud 付费，直到您停用 GKE Enterprise 或删除项目。
您还需要负责运行 Cymbal Bank 示例应用时产生的其他 Google Cloud 费用，例如 Compute Engine 虚拟机的费用。
准备工作
如需了解如何模拟故障，您必须完成第一个教程，创建一个使用 Autopilot 的 GKE 集群并部署基于微服务的 Cymbal Bank 示例应用。
我们建议您按顺序针对 Cymbal Bank 完成本系列教程。在完成本系列教程的过程中，您将学习新技能并使用其他 Google Cloud 产品和服务。
查看节点和服务的分布
在 Google Cloud 中，区域是指您可以在其中托管资源的特定地理位置。区域有三个或以上的可用区。例如，us-central1 区域表示美国中西部区域的一个具有多个可用区（例如us-central1-a、us-central1-b 和 us-central1-c）的区域。同一区域中的可用区之间具有高带宽、低延迟网络连接。
如需部署具有高可用性的容错应用，Google 建议您跨多个可用区和多个区域部署应用。此方法有助于防范意外的组件故障，或者更大范围的可用区或区域的意外故障。
在第 1 个教程中创建 GKE Enterprise 集群时，系统使用了一些默认配置值。默认情况下，使用 Autopilot 的 GKE Enterprise 集群会创建并运行跨越您指定的区域的各个可用区的节点。这种方法意味着已经跨多个可用区部署 Cymbal Bank 示例应用，这有助于防止意外故障。
检查 GKE Enterprise 集群中的节点分布：
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'结果类似于以下示例输出，显示节点分布在该区域中的所有三个可用区中：
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node2 us-central1-a 10.148.0.8 scalable-apps-pool-2-node1 us-central1-a 10.148.0.9 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4检查 Cymbal Bank 示例应用 Service 在 GKE Enterprise 集群节点上的分布情况：
kubectl get pods -o wide以下示例输出显示服务分布在集群中的各节点之间。在上一步中检查节点的分布方式，此输出显示 Service 在该区域内的各可用区中运行：
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 6m30s 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 6m30s 10.28.5.6 scalable-apps-pool-2-node1 contacts-7ddc76d94-qv4x5 1/1 Running 0 6m29s 10.28.4.6 scalable-apps-pool-2-node2 frontend-747b84bff4-xvjxq 1/1 Running 0 6m29s 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 6m29s 10.28.5.7 scalable-apps-pool-2-node1 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 6m29s 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 6m29s 10.28.4.7 scalable-apps-pool-2-node2 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 6m29s 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 6m28s 10.28.5.8 scalable-apps-pool-2-node1
模拟中断
Google 会设计可用区，以最大限度地降低因物理基础设施故障（如电源、制冷或网络）而导致的故障的风险。但是，可能会出现意外问题。如果某个节点或可用区不可用，则您希望 Service 继续在其他节点或同一区域内的可用区中运行。
Kubernetes 控制器会监控集群中节点、Service 和 Deployment 的状态。如果发生意外中断，控制器会重启受影响的资源，并且流量会路由到正常工作的节点。
为了模拟本教程中的中断情况，您需要封锁并排空其中一个可用区中的节点。此方法可模拟节点发生故障或整个可用区出现问题时会发生什么情况。Kubernetes 控制器应识别出某些 Service 不再可用，必须在其他可用区的节点上重启：
封锁并排空其中一个可用区中的节点。以下示例以
us-central1-a中的两个节点为目标：kubectl drain scalable-apps-pool-2-node1 \ --delete-emptydir-data --ignore-daemonsets kubectl drain scalable-apps-pool-2-node2 \ --delete-emptydir-data --ignore-daemonsets此命令将节点标记为无法安排，以使 Pod 无法再在这些节点上运行。Kubernetes 会将 Pod 重新调度到正常运行可用区中的其他节点。
检查模拟故障响应
在本系列的上一个教程中，您学习了如何为 GKE Enterprise 集群配置托管式 Prometheus 实例，以监控某些 Service 并生成提醒（如果出现问题）。如果 Pod 在模拟了服务中断的可用区中的节点上运行，您会从 Prometheus 生成的提醒中收到 Slack 通知消息。此行为展示了如何构建现代应用环境来监控 Deployment 的运行状况，在出现问题时收到提醒，并自动针对负载变化或故障进行调整。
您的 GKE Enterprise 集群会自动响应模拟的服务中断。受影响节点上的所有 Service 都会在其余节点上重启。
再次检查 GKE Enterprise 集群中的节点分布：
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'结果类似于以下示例输出，显示节点现在仅分布在该区域的两个可用区中：
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4Kubernetes 控制器识别出两个节点不再可用，并在可用节点之间重新分发 Service。所有 Service 都应继续运行。
检查 Cymbal Bank 示例应用 Service 在 GKE Enterprise 集群节点上的分布情况：
kubectl get pods -o wide以下示例输出显示 Service 分布在集群中的其余节点上。从上一步中检查节点的分布方式，此输出显示 Service 现在仅在该区域的两个可用区中运行：
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 28m 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 9m21s 10.28.5.6 scalable-apps-pool-2-node5 contacts-7ddc76d94-qv4x5 1/1 Running 0 9m20s 10.28.4.6 scalable-apps-pool-2-node4 frontend-747b84bff4-xvjxq 1/1 Running 0 28m 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 9m24s 10.28.5.7 scalable-apps-pool-2-node3 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 28m 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 9m21s 10.28.4.7 scalable-apps-pool-2-node5 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 28m 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 9m20s 10.28.5.8 scalable-apps-pool-2-node1查看 Service 的
AGE。在前面的示例输出中，Cymbal Bank 示例应用中某些 Service 的存在时间比其他 Service 短。这些较新的 Service 之前在模拟故障的其中一个节点上运行。Kubernetes 控制器在可用节点上重启了这些 Service。
在实际场景中，您可以排查问题，或者等待底层维护问题得到解决。如果您已将 Prometheus 配置为根据提醒发送 Slack 消息，则会看到这些通知。您还可以选择重复上一个教程扩缩资源中的步骤，查看在该区域中只有两个可用区可用时，GKE Enterprise 集群如何以增加的负载进行响应。集群应纵向扩容到两个剩余可用区。
清理
为避免因本教程中使用的资源导致您的 Google Cloud 账号产生费用，请删除您创建的项目。
- 在 Google Cloud 控制台中，进入管理资源页面。
- 在项目列表中，选择要删除的项目，然后点击删除。
- 在对话框中输入项目 ID，然后点击关闭以删除项目。
后续步骤
在开始创建自己的 GKE Enterprise 集群环境（类似于您在这组教程中了解的集群环境）之前，请查看一些生产注意事项。