Istio和Kubernetes：通过混沌工程降低风险

「【只做懂你de云原生干货知识共享】」

Istio 和 Kubernetes：通过混沌工程降低风险

在 Cloud Native 系统中设计微服务架构时，在Kubernetes 集群上设置Istio服务网格可以让您更好地控制和观察网络流量。但是，它也可以帮助您解决问题，这将是本博文的重点。

混沌工程是 Netflix 创造的一个术语，它可以归结为在生产中破坏您的系统，并在事情有机会意外中断之前设计解决方案来补救副作用。

「https://www.oreilly.com/library/view/chaos-engineering/9781491988459/」

您知道如果后端基础设施的一半无法访问会发生什么吗？如果您的前端 Web 服务器之一出现故障怎么办？如果流量需要额外的几秒钟才能到达后端的关键组件怎么办？如果你不能自信地回答这类问题，你就需要开始混沌工程。

混沌工程实验是我们容器解决方案工程师和我们的客户测试我们共同构建的云原生系统的一部分。此类弹性测试是我们四步云原生转型流程（思考、设计、构建、运行）的一部分，它们可帮助我们的客户在浪费时间、金钱和人力资源之前，尽早找出哪些有效，哪些无效。

既然您知道为什么应该接受这种心态，那么让我们来谈谈将想法付诸行动的一些方法。此外，打破东西可以很有趣！

模拟服务中断

让我们首先模拟您的一个 Web 服务的部分中断。这是用于高可用前端服务的典型 Istio 虚拟服务。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: frontend
spec:
  hosts:
  - frontend
  http:
  - route:
    - destination:
        host: frontend
        subset: v1



如您所见，我们将传入流量发送到任意数量的带有“前端”标签的服务。您可以开始杀死 pod 以查看会发生什么（您应该这样做）。但是我们将专注于您可以使用 Istio 做什么来模拟您的一些请求被错误配置或无法访问的微服务处理。

这是相同的 yaml，加上一个“错误”部分，我们将使用它来导致我们的一半请求以 503 个内部服务器错误进行响应。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: frontend
spec:
  hosts:
  - frontend
  http:
  - route:
    - destination:
        host: frontend
        subset: v1
  - fault:
       abort:
        httpStatus: 503
        percent: 50


这是另一个示例，但不是故障，而是设置超时，以便在返回 504 Gateway Timeout 错误之前为我们的服务提供有限的响应时间。这应该针对您的一些后端 REST API 进行测试，以查看依赖于它们的服务如何处理它。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: frontend
spec:
  hosts:
  - frontend
  http:
  - route:
    - destination:
        host: frontend
        subset: v1
    timeout: 1s


最后，我们将尝试通过延迟故障注入在我们的网络中引入一些延迟。通过这个，我们可以了解我们的前端应用程序如何处理预期响应中的延迟。希望它只是在几秒钟后返回您期望的内容，但最好现在找出答案，然后在周六凌晨 4 点被传呼。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: frontend
spec:
  hosts:
  - frontend
  http:
  - route:
    - destination:
        host: frontend
        subset: v1
  - fault:
      delay:
        fixedDelay: 5s
        percent: 100



让 Istio 重试失败的请求

因此，既然您已经测试了一些常见的故障模式，现在是进行补救的时候了。在大多数情况下，您需要更新应用程序代码以优雅地处理故障，但 Istio 有一个内置的重试选项，可以为您争取一些时间来解决问题。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: frontend
spec:
  hosts:
  - frontend
  http:
  - route:
    - destination:
        host: frontend
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s


HTTP 重试完全符合您的预期。如果请求失败，无论出于何种原因，Istio 都会通过重试您指定的次数来处理它。如果某些服务仍然可用，根据您的配置方式，您的请求最终将由健康的 pod 提供。假设您的基础设施本身是高度可用的（想想多区域/多集群），那么性能下降应该很少（如果有的话）。

知道如果出现问题会发生什么感觉不是很好吗？我知道通过混沌工程的知识，我晚上睡得更轻松。可能会导致生产系统中断似乎很可怕，但即使是最好的灾难恢复计划在经过测试之前也是不完整的。要么你测试它们，要么它们测试你——如果你读了这么多，那么你已经知道哪个更可取了。

参考：

https://blog.container-solutions.com/istio-and-kubernetes-reducing-risk-through-chaos-engineering

       Kubernetes 模式：InitContainers模式

          Kubernetes 日志监控工具

          kubernetes是如何工作的

      用于蓝/绿部署策略的 Kubectl 插件

         Kubernetes 监控：Kubeview

         kubernetes二次开发实战(阶段二）

                                                                                                                    嘿，你在看吗？