华为云云原生钻石集训营 第十四课：Istio流量治理与监控管理深度剖析

前言：

前面王者课程，大家已经对lstio流量治理和监控管理有一定的了解

本节课程将为大家带来深度的lstio流量治理和监控管理原理剖析

课程目标：

学完本课程后，您将能够:

1.深入理解流量治理API

2.深入理解流量监控

3.深入理解Envoy在流量治理中的职责

目录：

1. lstio流量治理基本介绍

2. lstio流量治理深度剖析

3. lstio监控深度剖析

流量治理演进

上一代微服务框架，大部分流量治理方案是:

-将流量治理策略放在SDK中

- Java系微服务框架比较流行

-异构开发语言很不友好

-缺少灵活性，流量治理策略一般是静态配置，少数支持动态配置

lstio流量治理方案是:

-流量治理策略完全由Sidecar实现

应用完全无感知

-语言无关

-灵活，支持动态配置

lstio流量治理基本介绍

简化服务治理配置:

-熔断，降级

-超时

-重试

- A/B测试，金丝雀发布

-基于权重的流量切分

-故障检测与恢复

lstio流量治理深度解析

-VirtualServiceVirtualService:最重要的路由API

允许您配置如何将请求路由到Istio服务网格中的服务，构建在Istio和您的平台提供的基本连接和发现之上。

Without VS，请求将按照基本的负载均衡策略分发到所有的服务实例

With vS，可以将请求按照百分比(Weight)分发到一组或者多组后端实例，或者根据请求属性(Match)，将请求路由到不同的服务实例组。

典型的使用场景是灰度发布

lstio流量治理深度解析-VirtualService

. hosts:选择目标服务,VS应用到目标服务上

. match:匹配HTTP属性Header，Authority，URI，Method，QueryParam

. Destination.Host:目的服务

. Destination.Subset:通过DestinationRule定义的服务实例集合

. Route.Weight:流量权重分配

lstio流量治理深度解析-DestinationRule

DestinationRule:

·常常与VS配合使用，VS定义一些策略将流量路由到某些目标服务，而DestinationRule允许用户针对目标服务配置一些负载均衡，异常检测，连接池以及证书

·特别是利用DR Subset定义特定服务的实例分组，结合VirtualService可以实现完整的蓝绿部署，金丝雀发布等功能。

K8S API Server

提供Pilot相关的CRD Resource的增、删、改、查。和Pilot相关的CRD有以下几种:

Virtualservice：用于定义路由规则，如根据来源或 Header 制定规则，或在不同服务版本之间分拆流量。

DestinationRule：定义目的服务的配置策略以及可路由子集。策略包括断路器、负载均衡以及 TLS 等。

ServiceEntry：可以使用ServiceEntry向Istio中加入附加的服务条目，以使网格内可以向istio 服务网格之外的服务发出请求。

Gateway：为网格配置网关，以允许一个服务可以被网格外部访问。

EnvoyFilter：可以为Envoy配置过滤器。由于Envoy已经支持Lua过滤器，因此可以通过EnvoyFilter启用Lua过滤器，动态改变Envoy的过滤链行为。我之前一直在考虑如何才能动态扩展Envoy的能力，EnvoyFilter提供了很灵活的扩展性。

Sidecar：缺省情况下，Pilot将会把和Envoy Sidecar所在namespace的所有services的相关配置，包括inbound和outbound listenter, cluster, route等，都下发给Enovy。使用Sidecar可以对Pilot向Envoy Sidcar下发的配置进行更细粒度的调整，例如只向其下发该Sidecar 所在服务需要访问的那些外部服务的相关outbound配置。

lstio流量治理深度解析-Gateway

类似Ingress，K8s Gateway API

应用于网格边缘独立运行的Envoy代理

配置L4-L6的负载均衡，比如端口，证书

L7层的路由能力需要与VirtualService绑定

lstio流量治理深度解析-ServiceEntry

·类似K8s Service

·将外部服务注册到K8s注册中心

·将虚拟机服务注册到K8s注册中心

·配合VirtualService与DestinationRule可应用部分治理能力:重试，超时，故障注入，熔断，异常检测

lstio流量治理深度解析-Sidecar

. lstio中，默认所有的工作负载可访问所有的服务

·利用Sidecar可以:

·限制负载可访问的服务

·精确控制部分端口可被访问

. Sidecar可作用在具体的工作负载or Namespaces内

·大规模场景下，降低控制面和数据面开销(内存，CPU，带宽)

lstio Observability

lstio提供以下可观测性能力(非侵入)∶

Metrics，应用流量粒度的监控统计

Distributed Traces:调用链上报

Access Logs:访问日志

服务网格监控-Metrics

指标监控依靠Istio扩展的Filter:

istio.alpn过滤器，重写ALPN

istio.metadata_exchange，交换双方的Metadata

istio.stats,记录metrics

服务网格监控-Trace

并非完全零侵入，应用必须进行调用链埋点，即从接收的请求中采集以下信息，并且发送给下一个服务

·x-request-id

x-b3-traceid

x-b3-spanid

x-b3-parentspanid

x-b3-sampledo

x-b3-flags

x-ot-span-context ( Lightstep )

Envoy send Tracing到Trace后端:Zipkin Lightstep Datadog Stackdriver   Opencensus Skywalking

Istio Trace支持

envoy支持trace

envoy原生就支持分布式追踪系统的接入，如支持jaeger和zipkin，如envoy的Tracing官方文档中表明envoy支持如下trace特性：

生成Request Id，填充HTTP的header字段x-request-id

外部跟踪服务集成，如支持LightStep, Zipkin或任何Zipkin兼容后端(如Jaeger)

添加Client trace ID

Istio的envoy代理拦截流量后会主动上报trace系统，通过proxy的参数zipkinAddress指定了trace系统的地址，这样就不会再经过mixer了，直接envoy和trace系统交互，大体流程：

如果incoming的请求没有trace相关的headers，则会再流量进入pods之前创建一个root span

如果incoming的请求包含有trace相关的headers，Sidecar的proxy将会extract这些span的上下文信息，然后再在流量进入pods之前创建一个继承上一个span的新的span

Tracing 简介

为什么需要tracing？

在微服务架构中，当多个服务相互调用时，故障排查变得不再容易。故障的根因是什么，为什么请求的性能不佳，哪个服务是调用堆栈中的瓶颈，请求之间的网络延迟是多少？

有了分布式跟踪，就可以可视化完整的调用堆栈，查看哪个服务调用了哪个服务，每个调用花费了多长时间以及它们之间的网络等待时间是多少。可以知道请求失败的位置或哪个服务花费太多时间来响应。

服务网格监控-AccessLog

支持的AccessLog Sink:

File，异步写

gRPC

stdout

stderr

总结：

本课程讲解重点1: Istio流量治理API及实现。

本课程讲解重点2: Istio的监控和调用链埋点

参考链接：

流量治理: https://support.huaweicloud.com/usermanual-istio/istio_01_0011.html

流量监控: https://support.huaweicloud.com/usermanual-istio/istio_ 01_0012.html

lstio官方网站: https://istio.io/

ASM应用服务网格官方首页: https://support.huaweicloud.com/istio/

Istio Kubernetes 云原生

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。