服务网格

ServiceMesh介绍

• 本质：服务间通讯的抽象层，专门处理服务通讯的基础设施层，网络通信变为平台级行为
• 功能：请求分发，原生应用组成服务的复杂拓扑结构下进行可靠的请求传送
• 部署形式：它是一组和应用服务部署在一起的轻量级的SideCar网络代理，并且对应用服务透明。
• 特点：和应用透明，开发者不需要关注细节

边车模式sidecar

https://oneslide.blog.csdn.net/article/details/106828370

**边车模式sidecar是在不改变原有container功能的情况下，在同一个pod下增加其他container来增加对应的功能，**因为在同一个Pod下的容是共享一个namespace空间的，所以对应的网络、存储等资源也是同一个空间下的，这就可以很方便的进行两个containers之间交互。

服务网格细节剖析

宏观角度

• 在istio网格内，每个pod都会被注入一个envoy代理

• envoy充当nginx代理，作为proxy角色，负责接管pod的入口、出口流量

认识envoy

istio

什么是istio

为什么要用istio?

我们只要改变这里的weight就可以轻松按照百分比改变转发到pod的流量。除了上述金丝雀发布之外，我们要实现蓝绿部署、A/B测试、会话保持、流量镜像等功能都可以轻松实现，

流量管理

如果我们想让不同的客户端（Android、windows、firefox、chrome等）访问到不同的pod上，istio亦可以轻松实现。另外istio也提供了强大的可观测性，因为我们安装了kiali，也可以非常便捷的看到流量走向。

Istio可以轻松地创建一个具有负载均衡、服务到服务认证、监控等功能的部署服务网络，而只需对服务代码进行少量或不进行代码修改。您可以通过在整个环境中部署一个特殊的sidecar代理，将Istio支持添加到服务中，该代理可以拦截微服务之间的所有网络通信，然后使用其控制平面功能配置和管理Istio，其中包括：

• TTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。

• 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行精细控制。

• 可插拔的策略层和配置 API，支持访问控制、速率限制和配额。

• 集群内所有流量的自动度量、日志和跟踪，包括集群入口和出口。

• 在具有强大的基于身份认证和授权的集群中进行安全的服务对服务通信。

Istio的安装与部署

参考：https://github.com/AliyunContainerService/k8s-for-docker-desktop

curl -L https://istio.io/downloadIstio | sh -

配置环境变量

source .bash_profile

安装 Istio

yang@192 ~$ istioctl manifest apply --set profile=demo

This will install the Istio 1.13.2 demo profile with ["Istio core" "Istiod" "Ingress gateways" "Egress gateways"] components into the cluster. Proceed? (y/N) y
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Egress gateways installed
✔ Installation complete                                                                                                                                                               Making this installation the default for injection and validation.

Thank you for installing Istio 1.13.  Please take a few minutes to tell us about your install/upgrade experience!  https://forms.gle/pzWZpAvMVBecaQ9h9

安装完后会自动出现istio-system 的namespace

ayang@192: ~/code/istio_example/istio-1.13.2/bin $ k get ns                     [21:39:53]
NAME              STATUS   AGE
default           Active   6d6h
istio-system      Active   7m32s
kube-node-lease   Active   6d6h
kube-public       Active   6d6h
kube-system       Active   6d6h
myistio           Active   4h18m
test              Active   6d6h
yang@192: ~/code/istio_example/istio-1.13.2/bin $ kubectl get pods -n istio-system

NAME                                    READY   STATUS    RESTARTS   AGE
istio-egressgateway-66fdd867f4-fsrj7    1/1     Running   0          6m26s
istio-ingressgateway-77968dbd74-g4pll   1/1     Running   0          6m26s
istiod-699b647f8b-vzcx5                 1/1     Running   0          7m38s

yang@192: ~/code/istio_example/istio-1.13.2 $ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

service/details created
serviceaccount/bookinfo-details created
deployment.apps/details-v1 created
service/ratings created
serviceaccount/bookinfo-ratings created
deployment.apps/ratings-v1 created
service/reviews created
serviceaccount/bookinfo-reviews created
deployment.apps/reviews-v1 created
deployment.apps/reviews-v2 created
deployment.apps/reviews-v3 created
service/productpage created
serviceaccount/bookinfo-productpage created
deployment.apps/productpage-v1 created

yang@192: ~/code/istio_example/istio-1.13.2 $ kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml

gateway.networking.istio.io/bookinfo-gateway created
virtualservice.networking.istio.io/bookinfo created

确认示例应用在运行中

22:08:56 yang@192.168.1.7 ~ kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"
<title>Simple Bookstore App</title>

对外暴露应用
应用部署成功之后还无法从外部访问，需要创建Istio Ingress Gateway来对外暴露应用。Istio Ingress Gateway在网格边缘进行路径映射。

将应用与Istio gateway联合：

创建 Ingress Gateway

kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml

查看 Gateway 配置

22:09:54 yang@192.168.1.7 ~ kubectl get gateway

NAME               AGE
bookinfo-gateway   11m

可以通过浏览器访问 http://localhost/productpage

部署一个GRPC服务，用gateway方式访问

yang@192: ~/code/istio_example/istio-1.13.2 $ k get vs -n myistio                                          [22:20:00]
NAME     GATEWAYS           HOSTS   AGE
grpcvs   ["grpc-gateway"]   ["*"]   3m58s

istio服务网格方案

Istio 网关之南北、东西流量管理

南北流量（NORTH-SOURTH-TRAFFIC）：客户端到服务器之间通信的流量。

东西流量(EAST-WEST-TRAFFIC)：指的是服务器和服务器之间的流量

https://baijiahao.baidu.com/s?id=1667190925170521740&wfr=spider&for=pc

卸载ISTIO

istioctl manifest generate --set profile=demo | kubectl delete -f -

istio资源

destinationRule 和 VirtualService的联系和区别

两者之间的关系

在讲解virtualService中，路由目标对象destination中会包含Service子集的subset字段，这个服务子集就是通过DestinationRule定义的。

两者都是用于流量治理，那应用场景有什么区别？

虚拟服务(Virtual Service)

虚拟服务（Virtual Service）以及目标规则（Destination Rule）是 Istio 流量路由的两大基石。

虚拟服务可以将流量路由到 Istio 服务网格中的服务。每个虚拟服务由一组路由规则组成，这些路由规则按顺序进行评估。

如果没有 Istio virtual service，仅仅使用 k8s service 的话，那么只能实现最基本的流量负载均衡转发，但是就不能实现类似按百分比来分配流量等更加复杂、丰富、细粒度的流量控制了。

备注：虚拟服务相当于 K8s 服务的 sidecar，在原本 K8s 服务的功能之上，提供了更加丰富的路由控制。

目标规则（DestinationRule）

DestinationRule描述的是这个请求到达某个后端后怎么去处理，是方法内的处理逻辑。
所以负载均衡和熔断策略是定义在DestinationRule中的，还可以配置连接池大小、异常实例驱逐规则等功能。
Istio 资源共有两类，分别为虚拟服务（Virtual Service）和目的地规则（Destination Rule）。虚拟服务作用在 k8s 服务之上，并加强了原 k8s 服务的功能：

Kubernetes Service

配置一个常规的 Kubernetes Service

配置一个 Istio Gateway，关联ingressgateway的 80 端口：

配置一个 Istio VirtualService，将 Istio Gateway 与 Kubernetes service 关联，这次grpc服务端的svc使用的是clusterip类型,而不必一定是headless svc，是因为istio的xds是动态模型, 得到cluster后，根据cluster 实时地查询endpoint列表，然后再根据istio中配置的负载均衡配置(默认是roundbalance)直接路由到endpoint，而不需要经过kubernetes中的service(kube-proxy)机制

服务网格架构

istio目前的问题

软件架构没有银弹，往往是取舍。

在设计之初，Istio 考虑的是普适性和功能的完备性，支持流量管理、安全、可观测性等多个维度的功能设计，并且随着项目的发展，这个功能不断增强，其实带来的损害就是性能，以及海量实例场景下 CPU 与 内存的巨量消耗。

sidecar

sidecar的简单示例

从图中可以看出，Pod 内有两个容器：

• Main container：主容器内运行着一个http服务，它会读取磁盘上需要对外服务的内容。

• Sidecar container：sidecar容器内运行着一个git定时同步服务，它会定期从远端同步最新的服务内容到磁盘上。

这么做有两个好处：

• 职责划分清晰：负责主容器的团队，只需要考虑如何提供服务即可，不需要关心服务内容怎么进行同步。

• sidecar容器可复用：git同步容器只需要关系怎么将服务内容同步到磁盘上，不需要关心内容怎么对外提供。它做好后，可以共享给其他http服务进行复用，不需要重复造轮子。

sidecar的思想核心就是：不侵入主容器的前提下，可以进行服务功能扩展。一般都是一些共性的能力，比如说：

• 日志代理/转发，例如 fluentd；

• Service Mesh，比如 Istio，Linkerd；

• 代理，比如 Docker Ambassador；

• 探活：检查某些组件是不是正常工作；

• 其他辅助性的工作，比如拷贝文件，下载文件等；

sidecar的两种设计模式：

Adapter模式与Ambassador模式。

Adapter主内，管别人怎么访问自己。而Ambassador主外，管怎么访问别人。

在集群内可能存在使用不同语言实现的服务，如图中Pod A运行着Java实现的服务，Pod B运行着Python实现的服务。为了系统可用性考虑，来了个新需求，需要给服务增加监控。需要采集监控数据，并存入 Prometheus。现在考虑两个方案：

方案一，不同服务基于各自的语言实现监控数据采集与上报。

方案二，实现一个可复用的Adapter，适配不同语言服务，采集数据并上报。

一眼就可以看出，方案二更优。好处如下：

• 无须侵入。在不侵入主容器的情况下，不仅能够进行监控数据采集与上报，还具备一定的复用性。

• 统一标准。Prometheus对于监控数据上报服务有一定的规范要求，通过实现Adapter可以统一这个规范。

• 分工明确。团队分工上，负责各自服务的团队无需关心数据采集与上报如何实现，可以继续专注在自己的工作中。

通过示例，我们就更好理解。异构容器系统指的是容器内的服务架构不同，包括语言、框架、输入输出等。标准化是指通过Adapter容器去屏蔽异构系统中的差异性，对外提供统一标准的内容。

所以，Adapter模式主要是针对主容器对外提供的功能。通过适配的方式，标准化要提供的内容。

k8s Adapter模式

第一种模式是Adapter模式，该模式主要是为了解决异构容器系统下对外标准化的问题。

k8s Ambassador模式

与Adapter模式不同，Ambassador模式主要是针对主容器对外的访问需求。通过Ambassador容器可以屏蔽主容器对外访问的一些复杂性问题，给主容器带来更简单的访问方式。