学习路线:可伸缩应用 - 模拟故障


本系列教程适用于想要部署、运行和管理在 Google Kubernetes Engine (GKE) Enterprise 版本上运行的现代应用环境的 IT 管理员和运维人员。在学习本系列教程的过程中,您将学习如何使用 Cymbal Bank 示例微服务应用配置监控和提醒、扩缩工作负载以及模拟故障。

  1. 创建集群并部署示例应用
  2. 使用 Google Cloud Managed Service for Prometheus 进行监控
  3. 扩缩工作负载
  4. 模拟故障(本教程)

概览和目标

应用应能够容忍服务中断和故障。借助此功能,即使出现问题,用户也能继续访问您的应用。Cymbal Bank 示例应用旨在处理故障并继续运行,而无需您进行问题排查和修复。为了提供这种弹性,GKE 区域级集群会跨可用区分布计算节点,Kubernetes 控制器会自动响应集群内的服务问题。

在本教程中,您将学习如何在 Google Cloud 中模拟故障,并了解 GKE 集群中的应用 Service 如何响应。您将学习如何完成以下任务:

  • 查看节点和 Service 的分布情况。
  • 模拟节点或可用区故障。
  • 验证 Service 是否继续在其余节点上运行。

费用

您将为本系列教程启用 GKE 并部署 Cymbal Bank 示例应用,这意味着您需要按照我们价格页面中列出的价格,按集群为 GKE on Google Cloud 付费,直到您停用 GKE 或删除项目。

您还需要负责运行 Cymbal Bank 示例应用时产生的其他 Google Cloud 费用,例如 Compute Engine 虚拟机的费用。

准备工作

如需了解如何模拟失败,您必须完成第一个教程,以创建使用 Autopilot 的 GKE 集群并部署基于微服务的示例应用 Cymbal Bank。

我们建议您按顺序对可伸缩应用完成本系列教程。在完成本系列教程的过程中,您将学习新技能并使用其他 Google Cloud 产品和服务。

查看节点和 Service 的分布

在 Google Cloud 中,区域是指您可以在其中托管资源的特定地理位置。区域有三个或以上的可用区。例如,us-central1 区域表示美国中西部区域的一个具有多个可用区(例如us-central1-aus-central1-bus-central1-c)的区域。同一区域中的可用区之间具有高带宽、低延迟网络连接。

Google 建议您跨多个可用区和多个区域部署应用,以便部署具有高可用性的容错应用。这种方法有助于防范意外的组件故障,乃至可用区或区域的意外故障。

在第一个教程中创建 GKE 集群时,系统使用了一些默认配置值。默认情况下,使用 Autopilot 的 GKE 集群会创建并运行跨您指定区域的多个可用区中的节点。这种方法意味着 Cymbal Bank 示例应用已部署到多个可用区,这有助于防范意外故障。

  1. 检查 GKE 集群中节点的分布情况:

    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
    
  2. 检查 Cymbal Bank 示例应用 Service 在 GKE 集群节点之间的分布:

    kubectl get pods -o wide
    

    以下示例输出显示 Service 分布在集群中的节点上。在上一步中,我们检查了节点的分布方式,此输出显示 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 集群配置托管式 Prometheus 实例,以监控某些 Service 并生成提醒(如果出现问题)。如果 Pod 在模拟了服务中断的可用区中的节点上运行,您会从 Prometheus 生成的提醒中收到 Slack 通知消息。此行为展示了如何构建现代应用环境,以监控 Deployment 的健康状况、在出现问题时提醒您,并可根据负载变化或故障自动调整。

您的 GKE 集群会自动响应模拟的服务中断。受影响节点上的所有 Service 都会在剩余节点上重启。

  1. 再次检查 GKE 集群中节点的分布情况:

    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.4
    
  2. Kubernetes 控制器会识别其中两个节点已不再可用,并将 Service 重新分配到可用节点。所有 Service 都应继续运行。

    检查 Cymbal Bank 示例应用 Service 在 GKE 集群节点之间的分布:

    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
    
  3. 查看 Service 的 AGE。在前面的示例输出中,Cymbal Bank 示例应用中某些 Service 的存在时间比其他 Service 短。这些较新的 Service 之前在您模拟故障的节点上运行。Kubernetes 控制器会在可用节点上重启这些服务。

在实际场景中,您需要排查问题,或者等待潜在的维护问题解决。如果您配置 Prometheus 以根据提醒发送 Slack 消息,则会看到这些通知。您还可以选择重复上一个教程扩缩资源中的步骤,查看在该区域中只有两个可用区可用时,GKE 集群如何以增加的负载进行响应。集群应使用剩余的两个可用区进行扩容。

清理

为避免系统因本教程中使用的资源而向您的 Google Cloud 账号收取费用,请删除您创建的项目。

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

后续步骤

在开始创建自己的 GKE 集群环境(与您在这组教程中学到的环境类似)之前,请查看一些生产环境注意事项