Service Mesh
- Service Mesh 的中文译为 “服务网格” ，是一个用于处理服务和服务之间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求，并为服务通信实现了微服务所需的基本组件功能。
- 例如服务发现、负载均衡、监控、流量管理、访问控制等。
- 在实践中，服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。
1 | 1. 基于通信 |
1 | # 图中: |
1 | # 传统的网络代理 |
1 | 1. 治理能力独立（Sidecar） |
1 | # Sidecar 就是一个网络代理,如果ServiceA 要访问 ServiceB ，都需要经过 SidecarA -> SidecarB -> ServiceB |
Istio 概述
- Isito是Service Mesh的产品化落地，是目前最受欢迎的服务网格，功能丰富、成熟度高。
- Linkerd是世界上第一个服务网格类的产品。
1 | 官网: |
1 | 1. 连接（Connect） |
Istio 与 K8S
1 | # 微服务链路监控系统 Pinpoint 可以拿到微服务产生的一些流量数据，但是比较有限 |
Isito 架构与组件
数据平面：
- 由一组代理组成，这些代理微服务所有网络通信，并接收和实施来自Mixer的策略。
- Proxy：负责高效转发与策略实现。实现:Envoy(与nginx类似)
控制平面：
- 管理和配置代理来路由流量。此外，通过mixer实施策略与收集来自边车代理的数据。
- Mixer：适配组件，数据平面与控制平面通过它交互，为Proxy提供策略和数据上报。
- Pilot：策略配置组件，为Proxy提供服务发现、智能路由、错误处理等。
- Citadel：安全组件，提供证书生成下发、加密通信、访问控制。
- Galley：配置管理、验证、分发。
Istio 基本概念
- Istio 有 4 个配置资源，落地所有流量管理需求(实现上面Istio的功能)：
1 | 1. VirtualService： 实现服务请求路由规则的功能。 转发规则 |
在 Kubernetes 部署 Istio
1 | # istioctl 暂时不支持 helm v3的部署 |
1 | # 在k8s里面查看 , 如果网络不好的话 就需要自己下载好镜像,在各个节点上提前准备好 |
Sidercar 注入
1 | # 查看实例 |
部署 httpbin Web示例
1 | [root@k8s-master1 httpbin]# vim httpbin-nodeport.yaml |
手动注入 Sidercar
1 | # Sidercar 就是 istio 的 proxy |
1 | # istio 自身的管控进出流量 |
1 | [root@k8s-master1 httpbin]# kubectl apply -f httpbin-gateway.yaml |
服务网关 Gateway
- Gateway为网格内服务提供负载均衡器，提供以下功能： Envoy
- L4-L7的负载均衡
- 对外的mTLS
- Gateway根据流入流出方向分为：
- IngressGateway：接收外部访问，并将流量转发到网格内的服务。
- EgressGateway：网格内服务访问外部应用。
部署 bookinfo 微服务示例
Bookinfo 应用分为四个单独的微服务
- productpage ：productpage 微服务会调用 details 和reviews 两个微服务，用来生成页面。
- details ：这个微服务包含了书籍的信息。
- reviews ：这个微服务包含了书籍相关的评论。它还会调用ratings 微服务。
- ratings ：ratings 微服务中包含了由书籍评价组成的评级信息。
reviews 微服务有 3 个版本
- v1 版本不会调用 ratings 服务。
- v2 版本会调用 ratings 服务，并使用 5个黑色五角星 来显示评分信息。
- v3 版本会调用 ratings 服务，并使用 5个红色五角星 来显示评分信息。
部署 bookinfo
1 | # 创建命名空间 |
通过域名分流
1 | 配置hosts |
1 | # 增加LB nginx 作为流量的统一入口 -> ingressgateway |
1 | # 修改 ingressgateway的 host |
1 | # 修改 bookinfo |
Istio 实现灰度发布
1. 主流发布方案：
1 | 1. 蓝绿发布 |
1 | 1. 都是为新旧业务切换,保证平滑切换 |
蓝绿发布
蓝绿发布
- 项目逻辑上分为AB组，在项目升级时，首先把A组从负
- 载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。
- A组升级完成上线，B组从负载均衡中摘除。
- 特点：
- 策略简单
- 升级/回滚速度快
- 用户无感知，平滑过渡
- 缺点：
- 需要两倍以上服务器资源
- 短时间内浪费一定资源成本
滚动发布
滚动发布
- 每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版升级新版本。
- Kubernetes的默认发布策略。
- 特点：
- 用户无感知，平滑过渡
- 缺点：
- 部署周期长
- 发布策略较复杂
- 不易回滚
- 有问题影响范围大
灰度发布（金丝雀发布）
灰度发布（金丝雀发布）
- 只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没有什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。
- 特点：
- 保证整体系统稳定性
- 用户无感知，平滑过渡
- 缺点：
- 自动化要求高
灰度发布 A/B Test
A/B Test
- 灰度发布的一种方式，主要对特定用户采样后，对收集到的反馈数据做相关对比，然后根据比对结果作出决策。
- 用来测试应用功能表现的方法，侧重应用的可用性，受欢迎程度等，最后决定是否升级。
基于权重的路由（金丝雀发布）
任务
- 流量全部发送到reviews v1版本（不带五角星）
- 将90%的流量发送到reviews v1版本，另外10%的流量发送到reviews v2版本（5个黑色五角星），最后完全切换到v2版本
- 将50%的流量发送到v2版本，另外50%的流量发送到v3版本（5个红色五角星）
1 | kubectl apply -f networking/virtual-service-all-v1.yaml -n bookinfo |
基于请求内容的路由（A/B Test）
任务：
- 将特定用户的请求发送到reviews v2版本（5个黑色五角星），其他用户则不受影响（v3）
- 这个实例是根据请求的用户做区分
- jason登录的 都是v2版本
1 | kubectl apply -f networking/virtual-service-reviews-jason-v2-v3.yaml -n bookinfo |
Istio 实现灰度发布流程
可视化监控
- 监控指标（Grafana）
- 网格可视化（Kiali）
- 调用链跟踪（Jaeger）
1 | # 通过 istio-ingressgateway 暴露应用 |
1 | grafana |
小总结
1 | 用户 -> LB搭理多套ingress -> ingress -> pod |