本系列教程适用于想要部署、运行和管理在 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 产品和服务。
查看节点和 Service 的分布
在 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 控制器会在可用节点上重启这些服务。
在实际场景中，您可以排查问题，或者等待底层维护问题得到解决。如果您已将 Prometheus 配置为根据提醒发送 Slack 消息，则会看到这些通知。您还可以选择重复上一个教程扩缩资源中的步骤，查看在该区域中只有两个可用区可用时，GKE Enterprise 集群如何以增加的负载进行响应。集群应纵向扩容到两个剩余可用区。
清理
本系列针对 Cymbal Bank 的教程设计为逐一完成。在完成本系列教程的过程中，您将学习新技能并使用其他 Google Cloud 产品和服务。
如果您想在继续学习下一个教程之前休息一下，并避免系统因本教程中使用的资源向您的 Google Cloud 账号收取费用，请删除您创建的项目。
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
后续步骤
请在下一个教程中了解如何使用 Config Sync 集中进行变更管理。