istio概述，与微服务、云原生、k8s的关系

喜欢ヅ旅行 2023-01-14 01:43 114阅读 0赞

1.1简单介绍istio  
与k8s紧密结合，适用于云原生场景，service mesh形态，服务治理的开放平台  
服务治理，包括：连接、安全、策略执行和可观察性。  
连接：通过配置的流量规则控制服务间的流量和调用，实现负载均衡，熔断，故障注入，重试，重定向等服务治理  
安全：提供认证机制、通道加密、服务访问授权等，增强服务访问的安全性  
策略执行：通过可动态插拔，可扩展的策略，实现访问控制，速率限制，配额管理，服务计费等能力  
可观察性:动态获取服务运行数据和输出，提供强大的调用链，监控，和调用日志收集与输出的能力。

1.2istio使用示例  
istio通过配置实现灰度发布的实例：  
apiVersion: networking.istio.io/vlalpha3  
kind: VirtualService  
metadata:   
 name: recommendation  
spec:  
 hosts:  
 - recommendation  
 http:  
 - match:  
  - headers:  
   cookie:  
    exact: "group=dev"  
  route:  
  - destination:  
   name: v2  
\- route:  
 - destination:  
    name: v1  
含义：  
group是dev的流量转发到recommendation服务的v2版本，其他用户访问v1版本，从而实现灰度。

1.3 istio与服务治理  
服务治理，比如一般经常提到的微服务治理，实际上只要有服务与访问就可以治理。

1.3.1 关于微服务  
为什么出现微服务：  
1）发布成本变高，如编译更多的代码，某一个小的点修改，要发布整个项目  
2）合作成本变高，如 代码冲突增加  
3）服务之间相互影响，如某个服务发生OOM，导致所有的服务不可用

微服务的本质：化繁为简 分而治之

微服务带来的好处：  
开发：服务内聚，微服务内易于设计和扩展，可以采用不同的语言和开发工具  
运维：每个服务可以自运维；迭代速度快，上线风险小  
组织管理：微服务角度切分小组，利于敏捷开发

引入的问题：  
服务注册、发现、调用、负载均衡，跨进程的分布式调用栈和链式追踪。

解决上面的问题就需要服务治理。

1.3.2 服务治理的形态演变  
第一种形态：在应用程序中包含治理逻辑，如rpc服务调用、重试机制等。  
特点：简单，但会有大量重复代码，业务代码和治理逻辑耦合，后期难以维护。

第二种形态：治理逻辑独立的代码  
sdk模式：即把治理的公共逻辑抽象成一个公共库，让所有的微服务使用这个公共库。典型的框架爱就是springCloud  
特点：代码上解耦了业务和治理的逻辑，但是两者还是在一个进程内，存在如下问题：  
1）业务代码必须和SDK是同一种语言  
2）因为多个服务分别引用治理的sdk，所以治理逻辑升级时需要整个服务一起升级  
3）sdk有一定的学习门槛

第三种形态：治理逻辑是独立的进程  
业务和治理代码彻底解耦。  
评价：对开发语言无限制，原服务也无需做任何修改，可以对老系统渐进式升级改造。

从三个形态整体来看：服务治理组件的位置在持续下沉，对应用的侵入主键减少

1.3.3 istio与微服务关系  
微服务是一种架构风格，是一种方法论。istio是一种服务治理的完整实践，但istio绝不是微服务方法论的落地。  
场景上，istio管理的大部分对象是微服务过的，但是也可以管理单体应用。特别适用于传统行业的用户业务需要在容器化后进行的服务治理。  
能力上，istio包含微服务情调的负载均衡、熔断、限流等治理能力，还包含可插拔的服务安全、控制策略、服务运行的可观察性等更广泛的能力。

谈论istio和微服务的关系，不如关注istio和k8s的关系。k8s和云原生实际上已经改变和重新定义了软件开发的很多方面。

1.4 istio与服务网格  
服务网格的特点  
基础设施：处理服务间通信的基础设施  
云原生：适用于云原生场景下的服务间的通信  
网络代理：轻量级的网络代理来执行治理逻辑  
对应用透明：应用程序网络代理部署在一起，但应用感知不到代理的存在

1.4.1 为什么会选择服务网格  
为什么服务网格这么火？  
1）进入了云原生时代，服务剧增，应用间的访问拓扑更加复杂，治理需求越来越多。与应用代码混合或进程混合的服务治理方式已经不再可以满足要求  
2）单个应用上，对应用完全无侵入，与开发语言无关  
3）全局来看，关注的是sideCar组成的网格，对网格间的服务访问进行管理，应用还是按照原本的方式进行互相访问。  
4）sidecar是网格动作的执行体，全局的管理规则和网格内的元数据通过一个统一的控制面实现，应用感知不到sideCar。

从forecast访问recommendation看sidecar导致的问题  
如图：

![20210419172711763.png][]  
需要先经过forecast服务的sidecar拦截outbound流量执行治理动作，再经过recommendation服务的sidecar拦截inbound流量执行治理工作。  
从上图可以看出，会引入如下问题：  
1）服务间访问增加了两跳，则增加了两处延迟和可能的故障点  解决：加大计算资源投入保证转发代理的轻量和高性能，降低延迟  
2) 多出来的两跳对整体可靠性和复杂度都带来了新的挑战。  解决：基础设施层面的可靠性、可维护性范畴，服务网格产品自身可以满足

1.4.2 为什么选择istio  
控制面上，基于xDs协议提供了一套标准的控制面规范，向数据面传递服务信息和治理规则。全新的设计，采用了gRPC协议，功能强大。  
数据面上，采用了envoy，采用c++语言实现的轻量高性能的代理；支持更多协议，有服务发现、健康检查、高级LB、前端代理等能力；架构上是一个可高度定制化的程序，提供了高度扩展性，支持热重启，模块化编码，已与测试。  
大厂支持上，istio由ibm和谷歌共同推出，定位上，将容器作为核心，k8s作为管理容器的编排系统，istio管理容器上服务之间的交互。

1.5 istio与k8s  
k8s：管理容器的平台

1.5.1 istio是k8s的好帮手  
k8s提供的功能：应用负载的部署、升级、扩容等运行管理能力  
k8s中的service机制可以实现服务注册、发现和负载均衡，并通过服务名访问服务实例  
k8s中的pod部署微服务也很合适，解决了微服务的互访互通的问题。

k8s的不足（为什么引入istio）：  
无法管理服务间的访问，如服务的熔断 限流 动态路由 调用链追踪等

istio实现的简单说明  
k8s的service基于节点的kube-proxy从kube-apiserver上获取service和endpoint信息，将对service的请求经过负载均衡后转发到对应的endpoint上。但无法基于应用层的信息进行负载均衡、无法进行流量管理、无法进行指标和调用链的跟踪。

istio复用了k8s service的定义，istio的服务发现就是中kube-apiserver中获取service和endpoint，然后将其转换成istio服务模型的service和serviceInstance，但是其数据面组件不再是kupe-proxy，而是每个pod里面部署的sidecar，可以看做是每个服务实例的proxy。所以proxy的粒度更细，通过拦截Pod的流量，并在sidecar上解析各种应用层协议，提供真正的应用层治理、监控和安全等能力。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70][]

1.5.2 k8s是istio的好基座  
1.数据面  
sidecar运行在k8s的pod中，应用完全无感知。  
2.统一服务发现  
istio的服务发现机制非常完美的基于k8s的域名访问机制构建而成。不需要新搭注册中心，且避免了服务发现中的数据不一致的问题  
3.易于k8s CRD描述规则  
istio的所有路由规则和控制策略都是通过k8s CRD实现的，因此各种规则策略对应的数据也被存储在kube-apiserver中

1.6 总结  
微服务化的服务与容器在轻量、敏捷、快速部署运维等特征上的匹配  
k8s在容器编排领域已经称为无可争辩的事实标准  
istio与k8s的天然融合且基于k8s构建，也补充了k8s的治理能力

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 2][]

云原生采用k8s的服务编排能力，采用istio的服务治理能力，将逐渐称为企业转型的标准配置。

[20210419172711763.png]: /images/20221022/310ab4610d964b04a84682f5f623ff2b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70]: /images/20221022/ccded8501bea4443a4300247d40ec62c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1]: /images/20221022/2935a37fd5014231b1867cdbc257d8a1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 2]: /images/20221022/351c41829ec84077980e79d20cb17263.png