【从小白到专家】Istio技术实践专题（四）：应用接入Istio的正确姿式

上一篇文章中，咱们介绍了Istio针对单集群的三种主流部署安装方式：使用Istioctl安装、使用Helm自定义安装、独立Operator安装。本文将向你们介绍kubernetes中的应用接入Istio。主要包括kubernetes 中应用接入Istio使用实例、应用技巧、基本知识点总结和须要注意事项。

用什么姿式接入 istio？

虽然 istio 能解决那么多的问题，可是引入 istio 并非没有代价的。最大的问题是 istio 的复杂性，强大的功能也意味着 istio 的概念和组件很是多，要想理解和掌握 istio ，并成功在生产环境中部署须要很是详细的规划。通常状况下，集群管理团队须要对kubernetes很是熟悉，了解经常使用的使用模式，而后采用逐步演进的方式把 istio 的功能分批掌控下来。

咱们设定如下目标：

•istio部署

•dfb相关服务部署

•网关功能

•流量分配，按比例，header

•超时，重试

Istio的几个基本资源对象：

1. VirtualService配置影响流量路由的参数，VirtualService 定义了对特定目标服务的一组流量规则。如其名字所示， VirtualService在形式上表示一个虚拟服务，将知足条件的流量都转发到对应的服务后端，这个服务后端能够是一个服务，也能够是在Dest in at i onRu l e 中定义的服务的子集。
2. DestinationRule配置目标规则,DestinationRule定义了在路由发生后应用于服务流量的策略。这些规则指定负载平衡的配置，边车的链接池大小以及离群值检测设置，以从负载平衡池中检测和清除不正常的主机。
3. Gateway服务网关，入口.Gateway描述了一个负载均衡器，该负载均衡器在网格的边缘运行，以接收传入或传出的HTTP / TCP链接。
4. Service Entry外部服务配置,经过ServiceEntry，能够在Istio的内部服务注册表中添加其余条目，以便网格中自动发现的服务能够访问/路由到这些手动指定的服务。

网关功能：Gateway

Gateway 在网格边缘接收外部访问，并将流量转发到网格内的服务。Istio经过Gateway将网格内的服务发布成外部可访问的服务，还能够经过Gateway 配置外部访问的端口、协议及与内部服务的映射关系。

网关功能常见的应用：

1. 将网格内的HTTP 服务发布为HTTP 外部访问
2. 将网格内的HTTPS 服务发布为HTTPS 外部访问
3. 将网格内的HTTP 服务发布为HTTPS 外部访问
4. 将网格内的HTTP 服务发布为双向HTTPS 外部访问
5. 将网格内的HTTP 服务发布为HTTPS 外部访问和HTTPS 内部访问

在实践中。咱们更多须要的是1，3两个场景。

在dfb服务中，dfb-login 做为最外层的前端，是几个服务中惟一和外部用户产生交互的服务。所以咱们经过网关功能，将dfb-login 经过域名暴露给用户。

建立gateway 的yml文件：

建立virtualservice.yml：

咱们建立了两个资源对象，一个VirtualService 用来描述流量的路由关系。全部url 前缀为/ 的请求都route 到后端dfb-login.dfb-istio.svc.cluster.local 服务。

这个virtuaservice 经过gateways 字段和咱们申明的另外一个gateway 资源相互绑定。在Gateway 资源对象中。定义了入口的域名，协议，以及TLS 相关的配置。在istio 中。默认的ingressgateway 会监听gateway 资源对象的变动。多个ingressgateway 经过selector 进行选择.默认ingressgateway 是一个loadbalancer的service 。

咱们将这个ingressgateway 修改成宿主机网络，并固定到一个单独的节点。这样咱们就能够经过将域名解析到这个node节点的方式访问部署好的入口。

流量分配：按比例，根据请求内容

咱们设置了两个版本的login 服务。V1 版本用户登陆后显示的余额是从数据库取出来的。V2版本则是0。根据这两个版本的差别来判断流量的流向。

首先经过DestinationRule定义两个版本：

根据比例：

此时屡次刷新页面。能够看到用户的现金帐户余额在0 和真实额度之间变更。

根据请求内容决定路由：

修改上文yml 。经过postman请求dfb服务/home页面。默认状况下会路由指向V1版本的login服务。在请求头添加version=v2的header。则会转到v2的服务。

超时，重试功能

咱们首先在扩容dfb-api 这个服务为2个pod，在其中一个pod中拦截用户资产接口， 直接返回500 ，另外一个pod 正常返回。此时在dfb-login服务中请求。咱们能够发现，接口500 和200 状态码交替出现。

location =/user/account/list/338fbcd2-1be6-4dde-9918-84b7629b1ba5 {           
return500;       

}

此时应用下面的重试规则，再次调用接口。此时接口状态码一直返回200。

经过jaeger查看调用链，能够看到调用了两次dfb-api。虽然中间调用失败了，可是最终的状态码是200。