一、istio原理

      Istio的原理是拦截 Kubernetes 中创建 Pod 的事件，然后向 Pod 中注入一个包含 Envoy 的容器，进出 Pod 的流量会被 “劫持” 到 Envoy 进行处理。由于流量被 “劫持” 了，所以 Istio 可以对流量进行分析例如收集请求信息，以及一系列的流量管理操作，也可以验证授权信息。当 Envoy 拦截流量并执行一系列操作之后，如果请求没问题，就会转发流量到业务应用的 Pod 中。所以，总结一下，istio劫持了pod的流量，根据istio相关CRD配置后完成了相关治理，再转发给目的pod，大致的关系如下，后文会详细介绍。

二、istio架构

     istio的架构分为 控制平面 、 数据平面 、出入口网关。

• 控制平面：控制平面为istiod，默认部署在istio-system命名空间。进入istiod容器可以看到主进程的名字为pilot。所以我们可以得知控制平面的主体是pilot，其他组件如citadel Galley，是被pilot管理启动的。pilot作为istio控制面的核心，主要有两个职责：1）监听k8s平台获取 svc , endpoint , virtualservice , gateway , destinationrule 等资源信息，这些信息是做流量转发必须依赖的；2）把获取到的信息抽象聚合，生成为envoy能识别的配置结构，最终通过xds协议下发配置到数据平面envoy。envoy 创建了一套 envoy动态下发配置并热生效的协议，被统称为xds。 pilot内实现了xds服务器，把已聚合转换的配置信息下发给数据面的envoy，实现流量策略的热生效。
• 数据平面：安装完istio之后，需要进行如下操作才会自动注入数据平面。

#对整个namespace自动注入:
kubectl label namespace default istio-injection=enabled
#对单个工作负载自动注入:
添加annotation  sidecar.istio.io/inject=true

        开启自动注入后，istio会向pod中注入sidecar容器，一个是修改pod内iptables的initcontainer，另一个即是istio数据平面istio-proxy。进入到istio-proxy中可以看到，主进程的名字为pilot-agent。envoy以子进程的形式被pilot-agent启动管理。pilot-agent有两个职责：1）pilot-agent 会与 pilot交互， pilot下发的xds请求正是由pilot-agent接收；2）启动管理envoy进程，并根据接收到的配置对envoy进行热更新。

• 出入口网关：istio-ingressgateway 和网格内的sidecar一样，核心处理组件也是一个envoy，它作为网格的入口允许从服务从网格外部访问服务网格内部的服务，起到了类似 nginx-ingress的作用。

        istio-ingressgateway 的主要包括以下作用：1）接收集群外部的流量，并根据 Istio 的配置将请求路由到适当的内部服务（起到网关的作用）；2）负载均衡和流量控制功能，包括请求路由、重试、超时、熔断等（流量治理）；3）支持 TLS 配置，以便在流量进入服务网格之前进行加密（给域名配置证书）；4）支持双向 TLS 身份验证，以提高服务网格的安全性（服务间通讯）；5）提供 Metrics、Tracing 和 Logging 收集，以便更好地观察和监控流量（需要自己安装对应的组件）

三、istio常用CRD资源

3.1 gateway

       在istio中，定义“监听信息与入口网关“绑定关系的资源叫 Gateway

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-gateway
  namespace: istio-test
spec:
  selector:    
    istio: ingressgateway  # 根据标签选择生效的入口网关
  servers:
    - port:                # 监听的端口
        number: 8080
        name: http
        protocol: HTTP     # 接收请求的协议
      hosts:
        - "*"              # 接收请求的域名

3.2  virtualService

         主要提供：1）路由功能：声明一个后端服务，及这个后端服务的路由信息；2）流量管控：镜像流量、故障注入、跨域配置等；3）绑定网关：通过spec.gateways字段绑定网关，在网关上生效路由规则和流量管控规则；4）绑定后端：spec.http.route.destination字段，声明了每种路由的转发地址。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-virtualservice
  namespace: istio-test
spec:
  hosts:
  - "*"
  gateways:
  - my-gateway                              ## virtualservice关联gateway
  http:
  - name: "nginx-v1-routes"
    match:                                  ## 路由规则，根据uri匹配
    - uri:
        prefix: "/aaa"          
    - uri:
        prefix: "/"
    route:
    - destination:                                  ## virtualservice关联destinationrule
        host: nginx.istio-test.svc.cluster.local    
        subset: v1                                  ## 关联destinationRule的subset.name

     注意事项：

1. spec.http.route.destination.host尽量使用FQDN（全限定域名）
2. uri匹配时，大小写敏感
3. istio的vs的url匹配顺序是从上向下，而不是最长匹配。在生产环境中建议使用一个无条件的规则作为最后规则，确保流量始终会匹配到最少一条规则，防止意外情况的方式
4. 当为已存在的host创建第二个及更多的 VirtualService时，istio 会将额外的路由规则合并到host现有配置中，这种合并不保证匹配顺序性，可能会造成与预期匹配效果不一致。所以建议一个host的路由配置写在一个virtualService.yaml文件中

3.3 destinationRule

    通过VistualService的 spec.http.route.destination字段，VistualService 与 DestinationRule 形成了绑定关系。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination
  namespace: istio-test
spec:
  host: mynginx.istio-test.svc.cluster.local   ## kuberntes内部FQDN域名，关联一个kubernetes service
  subsets:
  - name: v1
    labels:                                  ##根据标签给pod分类，常用在灰度发布场景
      version: v1    
  - name: v2
    labels:
      version: v2

     DestinationRule主要功能：

• 负载功能：从host字段的service endpoint列表中 选择一个，成为处理本次请求的真正后端。有轮询、一致性哈希、最少连接数、位置负载均衡等方式。
• 连接池：对后端服务的连接数等进行限制。
• 异常点检测：对后端服务进行健康探测，将异常后端点踢出负载。
• 定义子集版本：通过label把endpoint分类。

四、istio资源和kubernetes资源的关系

     istio服务网格，他的主要管理对象当然是服务，即kubernetes中的service。istio控制面pilot中包含informer用来获取kubernetes集群中的service、endpoint、pod资源信息，并将其转化为envoy的cluster、endpoint配置下发给数据面。大多数情况下我们可以把envoy cluster理解为 K8s 集群中的一个service，一个service 通常对应着一组pod，envoy中的cluster同样是一种相同后端的集合。

4.1 istio CRD资源和kubernetes资源扭转关系图

      istio的destinationRule定义一组负载均衡后端服务地址，通过spec.host字段关联kubernetes集群中的service，来获取kubernetes中的后端地址列表endpoint。istio的destinationRule还可以通过关联pod-label从service中筛选特定pod，常用于灰度发布。istio-ingressgateway的本质是一个部署在istio-system命名空间的deployment，运行着envoy进程容器。我们一般需要手动创建LoadBalacne类型的kubernetes-service，使其获得对外的ip。

4.2  istio需要通过kubernetes service port 信息获取服务协议

      istio 需要知道服务提供什么七层协议，从而来为其配置相应协议的 filter chain，官方建议显式声明协议。如果没有声明，istio 会自动探测，但这个探测能力比较有限（仅能探测识别http https http2协议），可能导致无法正常工作。

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 8080
    name: rpc
    appProtocol: grpc       # 第一种：指定该端口提供grpc协议的服务
  - number: 80    
    name: http-web          # 第二种：以协议名为前缀命名端口，声明80端口提供http协议服务

五、istio常用资源操作和关联关系展示

5.1 创建deployment、service资源

kind: Deployment
apiVersion: apps/v1
metadata:
  name: mynginx
  namespace: istio-test
  labels:
    appgroup: ''
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mynginx
      version: v1
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: mynginx
        version: v1
    spec:
      containers:
        - name: container-1
          image: nginx:1.17.4
          resources:
            limits:
              cpu: 250m
              memory: 512Mi
            requests:
              cpu: 250m
              memory: 512Mi
          imagePullPolicy: IfNotPresent
      restartPolicy: Always
      dnsPolicy: ClusterFirst
      imagePullSecrets:
        - name: default-secret
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: istio-test
  labels:
    app: mynginx
    version: v1
spec:
  ports:
    - name: http-nginx
      port: 80
      targetPort: 80
  selector:
    app: mynginx
    version: v1
  type: ClusterIP

5.2 创建对应istio资源

       按照3.1  3.2  3.3 章节 yaml创建相关istio资源

5.3 查看相关资源关联关系

• 创建gateway资源后

• 创建virtualservice资源后

• 创建destinationrule资源后  

订阅本文作者或关注容器魔方

获取更多云原生技术资讯

本文评论区回复“云原生”，即可添加小助手微信k8s2222

领取应季云原生资料一份