Istio 为什么要学习服务网格 Istio？

kubernetes面对的问题

---

第一种情况 

这是我的一套k8s环境，当将请求转发给svcx的时候，svcx会将请求转发给pod1和pod2的。客户端在去访问svcx的时候，它实现了对底端pod的负载均衡，它是通过kube-proxy的组件来对我们进行转发的，在转发的时候就涉及到了两种转发模式，一种是ipvs，一种是iptables。

那么现在相对流量做管控，比如往pod1走80%的流量，pod2走20%的流量。如果不考虑流量的话，只是单纯的svc往后端pod的时候，实际上做的是负载均衡，基本上往pod1转发了一些，往pod2转发了一些，比如各个50%。但是相对这些流量做一个明确的控制。

在将请求转发给svc之后，在往后端的pod1 pod2转发的时候是很难控制的。

第二种情况

有两套环境，如何实现往svc1走一定流量，往svc2走一定流量。如何往两个svc去转发呢？

如果要往两个svc去转发，那么要在两个svc之前，还应该有类似于负载均衡这样一个东西。这里就体现出来了k8s的一个弊端，对流量管理的不够细致。

 问题:

如果想往两个svc转发流量的时候，这两个svc前面还有类似于负载均衡的这样一个东西。我不访问svc而是直接访问loadbalance。

可以在testpod里面增加sidecar，这个sidecar可以使用haproxy来实现。那么可以设置两个后端服务为svc1和svc2，那么testpod不是直接访问svc1 svc2了而是直接访问sidecar了。

haproxy指定了后端的svc1和svc2，那么就就可以在haproxy里面指定svc1和svc2的负载比例，从而就实现了svc1往svc2的流量是可控的。

单独使用kubernetes进行流量控制

haproxy的设置  现在这里只是去访问一个服务。

如果是两个服务：

haproxy.cfg: |
  frontend  www-http
    bind: 80
    defalut_backend: www-http
  backend www-http
    server nginx-svc1 svc1:80 weight 1
    server nginx-svc2 svc1:80 weight 4

---------------------------------------------------------------------------------------------------------------------------------

Istio是运行在kubernetes之上的一种服务网格(Service Mesh，第三代微服务架构)，极大的扩展了kubernetes的功能，可以轻松实现比kubernetes更细颗粒度的流量管理。

当我们直接在kubernetes部署应用时，有时要实现一些特殊需求是比较困难的，比如金丝雀发布（也称为灰度发布）。

金丝雀发布是这样工作的，我们已经有了一个旧版本的应用这里称之为v1，然后要发布一个新版本的应用这里称之为v2。但是现在并不想让所有的客户端都访问v2，只是想在小范围内对部分客户端开放进行测试。

所以我们可以设置90%的流量转发到v1，10%的流量转发到v2。如果这10%的用户反馈v2还不错，那么我们我们可以扩大访问v2的流量，缩小访问v1的流量。

以此类推，直到把所有的流量逐步转移到v2上面。

如果没有istio的话实现的方式是这个样子的，创建两个deployment，一个是v1一个v2。他们创建的pod具备相同的标签供service关联。首先v1设置3个副本，v2设置一个副本，这样75%的流量都转发到v1上了，25%的流量转发到v2上。

然后我们可以缩小v1的副本数，增加v2的副本数来修改流量的走向，如下图。

但是这种流量的管控显得过于粗糙，且维护起来也过于麻烦。

但是我们在istio里是非常方便实现的。下面是取自一个VirtualService（简称为vs）里的部分代码，我们通过修改weight即可修改流量的走向。

    - destination:
        host: svc1
        subset: v1
      weight: 65
    - destination:
        host: svc1
        subset: v2
      weight: 35

这里指定往pod1的流量占65%，往pod2的流量占35%，然后通过下图看流量走向。

然后我们再次修改weight。

    - destination:
        host: svc1
        subset: v1
      weight: 35
    - destination:
        host: svc1
        subset: v2
      weight: 65

这里设置往pod1走35%的流量，往pod2走65%的流量，然后看下图。

我们只要改变这里的weight就可以轻松按照百分比改变转发到pod的流量。除了上述金丝雀发布之外，我们要实现蓝绿部署、A/B测试、会话保持、流量镜像等功能都可以轻松实现，所以istio的强大之处在于它的流量管理。

如果我们想让不同的客户端（Android、windows、firefox、chrome等）访问到不同的pod上，istio亦可以轻松实现。

另外istio也提供了强大的可观测性，上面因为我们安装了kiali，也可以非常便捷的看到流量走向。

istio也为我们提供了更强大的安全管理，包括通过AuthorizationPolicy做更细致的授权管理、pod之间的mTLS认证等，极大提高了pod的安全性。