使用K8s遇难题？Istio来帮您！

若是你正在使用容器，特别是Kubernetes，那么你应该也据说过Istio。对于初学者来讲，Istio是Kubernetes的服务网格（service mesh）。所谓服务网格，它是一个网络层，而且能够动态管理服务流量，而后以安全的方式进行管理。

如何充分使用Istio，这不是一篇博客文章能阐述清楚的。所以，在本文中我将介绍一些它的特性，更重要的是，你能够经过这篇文章，了解到一些方法来自动化解决某些实际问题。

Istio可让你使用一组自定义Kubernetes资源来管理网络流量，而且能够帮助你保护和加密服务之间以及集群内外的网络流量。它全面集成了Kubernetes API，这意味着可使用与其余Kubernetes配置彻底相同的方式来定义和管理Istio设置。

权衡利弊,再作选择

若是要开始使用Istio，首先应该问本身为何。Istio提供了一些很是有价值的功能，如金丝雀发布等，可是若是不增长一些复杂性，就没法使用它们。你还须要投入必定的时间来学习它。也就是说，若是你的状况合适使用它，你能够（而且应该）在本身的集群中谨慎且逐步地采用Istio的功能。

若是你要从头开始构建新环境，而且通过利弊权衡决定继续使用Istio，那么必定要从一开始就使用严格的相互TLS对其进行设置，并积极使用其强大的功能。具体操做请参考：

https://istio.io/docs/setup/i...

为了使一切都有价值而且具备必定的性价比，咱们须要在实际应用程序的上下文中考虑Istio，可是若是没有快速免责声明的话，最好不要这样作。若是你只须要管理少许服务（且位于单个集群内），那么引入Istio的性价比相对而言没有那么高。

本文中的代码示例不必定可以彻底帮助你解决你的问题，可是若是你须要全部的代码以及如何使用它的详细说明均可以在GitLab上找到：

https://gitlab.com/ContainerS...

接下来是你在Cloud Native旅程中可能遇到的两个常见问题，以及如何使用Istio来解决这些问题。

问题1：我不相信个人测试

若是测试范围并无彻底涵盖你所更改的应用程序，那么你可能会很快采起行动进行新一轮测试，但也有可能应用程序没法正常运行了。

在理想情况下，咱们都想要确保每一个代码通过全面的测试，不然就不会将功能添加到应用程序中。可是现实总归是骨感的，咱们经常被ddl追赶，可能还未编写或者更新测试，功能就得上传到项目中了。

解决方案：放慢速度

那么，如何确保我绝大多数用户不受代码中潜伏的任何错误的影响，又如何进行更改和部署新功能呢？答案是经过先将新版本部署到最少数量的用户来最大程度地减小这些小问题的辐射范围。

若是更改可以按照预期工做的话，你能够缓慢增长使用新版本的用户百分比。若是各项指标出现问题，你能够轻松回滚你的更改，而后重试。

在没有Istio的状况下能够在Kubernetes上运行金丝雀部署吗？固然没问题，可是若是要自动化这一过程，你须要彻底将本身的精力放在web服务器代码和自定义自动化脚本方面。这样的操做方式性价比并不高。

Istio有一些十分优雅的流量分配解决方案，咱们可使用它们在恰当的时间为合适的版本提供适当的客户端服务，而且咱们只需调整其中的1个或2个参数。

为了实现这一点，你须要设置一个网关入口（Ingress gateway）、一个虚拟服务（virtual service）和一个destination rule。这将位于通常的部署和服务之上，并为你分配流量。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hos
ts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - "*"
  gateways:
    - http-gateway
  http:
  - match:
    - uri:
        prefix: "/my-app"
    rewrite:
      uri: "/"
    route:
      - destination:
          host: my-app
          subset: v1
          port:
            number: 80
        weight: 90
      - destination:
          host: my-app
          subset: v2
          port:
            number: 80
        weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-app
spec:
  host: my-app
  subsets:
  - name: v1
    labels:
      version: v1.0.0
  - name: v2
    labels:
      version: v2.0.0

从虚拟服务的权重字段中能够看到，Istio将根据指定的值在应用程序的两个版本之间分配流量。这些值的总和必须为100％，不然，API将拒绝应用该定义。

而后，你（或者理想状况下，在“持续集成/连续交付”流水线中手动执行一个或多个步骤）将调整权重，以将新版本推广给更多用户，直到全部请求由新版本知足为止，而且之前的版本能够中止维护。

经过使用Istio的故障注入功能来模拟网络中断和实际流量性能降低，还能够将Istio集成到您的集成测试策略中。

若是在生产中进行测试的想法给你留下了心理阴影，那必定是你的作法有所欠缺。例如，尝试在你的虚拟服务规范中添加如下代码片断以添加一些混乱，而后再找一篇文章来看看怎么用Istio解决这样的混乱。

spec:
  hosts:
  - my-app
  http:
  - fault:
      delay:
        fixedDelay: 7s
        percent: 100
   route:
    - destination:
        host: ratings
        subset: v2

问题2：市场策略没法肯定发布版本

一般，业务须要针对实际用户测试应用程序的多个版本。可是有时实在没法搞清楚是哪一种营销策略能够带来最佳转化率，或者哪一种设计选择能够带来最佳的客户留存率。

使用Kubernetes，你能够将流量分为两个版本，可是要想从练习中得到任何有价值的看法，则再次须要一大堆自定义代码来获取相关信息，并以非技术同事能够理解的方式对其进行处理。

解决方案：使用Istio进行A/B测试

Istio的流量分配规则能够再次解决这一问题，它与Prometheus和Grafana的紧密集成能够帮助你获取直观的A/B测试的结果。通常而言，根据传入数据包内容的某些部分，几乎有无数种方法来决定哪些用户能够获取你的应用程序的版本。

在这一示例中，咱们将使用User-Agent字段为不一样的浏览器提供不一样的版本。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - "*"
  gateways:
    - http-gateway
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Chrome.*"
      uri:
        prefix: "/my-app"
    rewrite:
      uri: "/"
    route:
      - destination:
          host: my-app
          subset: v1
          port:
            number: 80
  - match:
    - headers:
        user-agent:
          regex: ".*Mozilla.*"
      uri:
        prefix: "/my-app"
    rewrite:
      uri: "/"
    route:
      - destination:
          host: my-app
          subset: v2
          port:
            number: 80

从上面的代码中能够看到，使用Firefox的用户将得到应用程序的版本1，而Chrome用户将得到版本2。若是浏览器的“User-Agent”字段不包含“mozilla”或“chrome”，则他们都将不会得到任一版本。

要为其余客户提供服务，您须要添加一条默认路由，我将做为练习留给你。（嘿嘿）

若是你不想安装其余浏览器，只是想尝试一下，则可使用带有头部标志的curl假装成所需的任何浏览器，例如：

curl /my-app -H "User-Agent: Chrome"

经过更改user-agent的值，你能够从命令行测试全部不一样的路由。

总 结

以上两种状况大概能让你体验到Istio强大功能的冰山一角。正如上文所说，若是没有Istio，你依然能够进行金丝雀部署和A/B测试，只是你必须本身实现流量分配。但这大大增长了开发部署的复杂性，实属性价比低之选。

我但愿这篇文章可让你对Istio的实际应用有很好的理解，而且十分期待你本身尝试一下。若是你想了解更多关于Istio的信息，能够访问它们的官网，上面有许多有用的资料：https://istio.io/

值得一提的是，Rancher 2.3 Preview2版本上开始支持Istio，用户能够直接在UI界面中启动Istio而且能够为每一个命名空间注入自动sidecar。此外，Rancher简化Istio的安装和配置，内置了一个支持Kiali的仪表盘，用于流量和遥测的可视化，而后用Jaeger进行追踪，甚至还有本身的Prometheus和Grafana（与用于高级监控的实例不一样）。这一切让部署和管理Istio变得简单而快速。

有关发行说明和安装步骤，请访问GitHub：

https://github.com/rancher/ra...