作者:justmine
头条号:大数据与云原生
微信公众号:大数据与云原生
创作不易,在满足创作共用版权协议的基础上可以转载,但请以超链接形式注明出处。
为了方便阅读,微信公众号已按分类排版,后续的文章将在移动端首发,想学习云原生相关知识,请关注我。
云原生 - 体验Istio的完美入门之旅(一)
云原生 - Why is istio(二)
[请持续关注...]
如前所述,业务微服务化后,每个单独的微服务可能会有很多副本,多个版本,这么多微服务之间的相互调用、管理和治理非常复杂,Istio统一封装了这块内容在代理层,最终形成一个分布式的微服务代理集群(服务网格)。管理员通过统一的控制平面来配置整个集群的应用流量、安全规则等,代理会自动从控制中心获取动态配置,根据用户的期望来改变行为。
话外音:借着微服务和容器化的东风,传统的代理摇身一变,成了如今炙手可热的服务网格。
Istio就是上面service mesh架构的一种实现,通过代理(默认是envoy)全面接管服务间通信,完全支持主流的通信协议HTTP/1.1,HTTP/2,gRPC ,TCP等;同时进一步细分控制中心,包括Pilot、Mixer、Citadel等。
话外音:后面系列会详细介绍控制中心的各个组件,请持续关注。
整体功能描述如下:
连接(Connect)
控制中心从集群中获取所有微服务的信息,并分发给代理,这样代理就能根据用户的期望来完成服务之间的通信(自动地服务发现、负载均衡、流量控制等)。
保护(Secure)
所有的流量都是通过代理,当代理接收到未加密流量时,可以自动做一次封装,把它升级成安全的加密流量。
控制(Control)
用户可以配置各种规则(比如 RBAC 授权、白名单、rate limit 、quota等),当代理发现服务之间的访问不符合这些规则,就直接拒绝掉。
观察(Observe)
所有的流量都经过代理,因此代理对整个集群的访问情况知道得一清二楚,它把这些数据上报到控制中心,那么管理员就能观察到整个集群的流量情况。
作为服务网格的一个完整解决方案,为了追求完美,Istio高度抽象并设计了一个优雅的架构,涉及到众多的组件,它们分工协作,共同组成了完整的控制平面。为了更好地学习如何运用Istio的连接、安全、控制、可观察性全面地治理分布式微服务应用,先从战略上鸟瞰Istio,进一步从战术上学习Istio将更加容易,故作者决定从可观察性开始Istio的布道,先体验,再实践,最后落地,一步步爱上Istio,爱上云原生,充分利用云资源的优势,解放应用开发工程师的双手,使他们仅仅关注业务实现,让专业的人做专业的事,为企业创造更大的价值。
当业务微服务化后,一次业务请求,可能会涉及到多个微服务,分布式跟踪可以对跨多个分布式服务网格的1个请求进行追踪分析,并通过可视化的方式深入地了解请求的延迟,序列化和并发,充分地了解服务流量实况,从而快速地排查和定位问题。
Istio利用Envoy 的分布式追踪功能提供了开箱即用的追踪集成。确切地说,Istio 提供了安装各种各种追踪后端服务的选项,并且通过配置代理来自动发送追踪span到追踪后端服务。
话外音:Istio目前支持的追踪后端服务包括Zipkin、Jaeger、LightStep。
话外音:Istio分布式追踪的整体功能,请参考文末链接。
默认情况下,使用demo配置文件安装时,Istio会捕获所有请求的追踪信息,即每次访问 /productpage
接口时,都可以在dashboard中看到一条相应的追踪信息。此采样频率适用于测试或低流量网格。对于高流量网格(如:生产环境),请通过下面的两种方法之一来降低追踪采样频率:
在安装时,使用可选项 values.pilot.traceSampling
来设置采样百分比。
在运行时,通过编辑 istio-pilot
deployment并通过以下步骤来改变环境变量:
root@just:~# kubectl -n istio-system get deploy istio-pilot -o yaml
apiVersion: extensions/v1beta1
kind: Deployment
[...]
name: istio-pilot
namespace: istio-system
[...]
env:
- name: PILOT_TRACE_SAMPLING
value: "1"
[...]
Istio默认的追踪采样率为1%,即100个请求生成一次追踪报告,有效值的范围从 0.0 到100.0,精度为 0.01。
本篇以zipkin为例,体验Istio的分布式追踪功能。
请先部署Istio系统和在线书店例子,详情请参考:云原生 - 体验Istio的完美入门之旅(一)。
istioctl manifest apply --set values.tracing.enabled=true \
--set values.tracing.provider=zipkin
要查看追踪数据,必须向服务发送请求。请求的数量取决于Istio的追踪采样率,默认为1%,即在第一个追踪报告可见之前,需要发送至少100个请求。
使用如下命令向productpage
服务发送200个请求:
for i in `seq 1 200`; do curl -s -o /dev/null http://$GATEWAY_URL/productpage; done
从上可以看出,产生了两份追踪报告,完全符合追踪采集率。
关于追踪报告的分析,这里就不赘述了。
本篇先回顾了微服务架构的痛点,以及服务网格的本质,然后大致概述了Istio的整体功能,最后从why、what、how的角度体验了Istio的可观察性特性。除了分布式跟踪,Istio的可观察性还包括:日志、监控,敬请期待,未完待续。
如果有什么疑问和见解,欢迎评论区交流。
如果觉得本篇有帮助的话,欢迎推荐和转发。
如果觉得本篇非常不错的话,可以请作者吃个鸡腿,创作的源泉将如滔滔江水连绵不断,嘿嘿。
https://istio.io/docs/tasks/observability/distributed-tracing/overview
https://istio.io/docs/tasks/observability/distributed-tracing/zipkin
https://www.envoyproxy.io/docs/envoy/v1.12.0/intro/arch_overview/observability/tracing