Istio学习整理

最新推荐文章于 2024-09-16 12:43:04 发布

happy_king_zi

最新推荐文章于 2024-09-16 12:43:04 发布

阅读量993

点赞数 31

分类专栏：服务网格云原生 kubernetes 文章标签： istio 云原生 kubernetes

本文链接：https://blog.csdn.net/happy_king_zi/article/details/141184982

版权

kubernetes 同时被 3 个专栏收录

11 篇文章 0 订阅

订阅专栏

云原生

8 篇文章 0 订阅

订阅专栏

服务网格

1 篇文章 0 订阅

订阅专栏

一、Service Mesh

　　Service Mesh 的中文译为 “服务网格” ，是一个用于处理服务和服务之间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求，并为服务通信实现了微服务所需的基本组件功能，例如服务发现、负载均衡、监控、流量管理、访问控制等。在实践中，服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。

　　一）kubernetes功能

kubernetes提供平台基础设施层强大的容器编排与调度能力
- 服务部署与弹性伸缩：deployment
- 服务拆分与服务发现：service
kubernetes提供简单的负载均衡
- 负载均衡：基于IPVS或IPtables的简单均衡机制

　　二）Service Mesh

　　Service Mesh特点

治理能力独立（sidecar）
应用程序无感知
服务通信的基础设施层
解耦应用程序的重试、超时、监控、追踪和服务发现

　　绿色是服务，蓝色是sidecar

　　1、为什么要用Istio？

　　在从单体应用程序向分布式微服务架构的转型过程中，开发人员和运维人员面临诸多挑战，使用Istio可以解决这些问题。

　　术语服务网格（Service Mesh）通常用于描述构成这些应用程序的微服务网络以及它们之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。

　　它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等

　　Istio提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。

　　2、Istio+kubernetes

　　云原生应用治理+云原生应用设施

　　istio是kubernetes的非常好的补充，完美的结合

二、Istio概述

　　下载地址：Releases · istio/istio · GitHub

　　中文文档：概念 - 《Istio v1.11 官方文档中文版》 - 书栈网 · BookStack

　　一）Istio设计目标

　　1、最大化透明度

　　若想Istio被采纳，应该让运维和开发人员只需付出很少的代价就可以从中受益。为此，Istio将自身自动注入到服务间所有的网络路径中。

　　Istio使用sidecar代理来捕获流量，并且在尽可能的地方自动编程网络层，以路由流量通过这些代理，而无需对已部署的应用程序代码进行任何改动。

　　在Kubernetes中，代理被注入到pod中，通过编写iptable规则来捕获流量。一旦注入sidecar代理到pod中并且修改路由规则，Istio就能够调解所有流量。这个原则也适用于性能。当将Istio应用于部署时，运维人员可以发现，为提供这些功能而增加的资源开销是很小的。所有组件和API在设计时都必须考虑性能和规模。

　　2、增量

　　随着运维人员和开发人员越来越依赖Istio提供的功能，系统必然和他们的需求一起成长。虽然我们期望继续自己添加新功能，但是我们预计最大的需求是扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制，以便插入到其他服务中。此外，它允许扩展词汇表，以允许基于网格生成的信号来执行策略。

　　3、可移植性

　　使用Istio的生态系统将在很多维度上有差异。Istio必须能够以最少的代价运行在任何云或预设环境中。将基于Istio的服务移植到新环境应该是轻而易举的，而使用Istio将一个服务同时部署到多个环境中也是可行的。（例如：在多个云上进行冗余部署）。

　　4、策略一致性

　　在服务间的API调用中，策略的应用使得可以对网格间行为进行全面的控制，但对于无需在API级别表达的资源来说，对资源应用策略也同样重要。

　　例如：将配额应用到ML训练任务消耗的CPU数量上，将配额应用到启动这个工作的调用上更为有用。

　　因此，策略系统作为独特的服务来维护，具有自己的API，而不是将其放到代理sidecar中，这容许服务根据需要直接与其集成。

　　二）架构

　　1、总体架构

　　　　1）1.5版本之前

　　　　2）1.5版本之后

　　2、istio架构与组件组成

　　　　1）数据平面

　　由一组proxy组成，这些Proxy负责所有微服务网络通信，实现高效转发和策略。

　　使用envoy实现，envoy是一个基于C++实现的L4/L7 Proxy转发器，是Istio在数据平面唯一的组件。

　　　　2）控制平面

　　1.5版本之后弃用了mixer，将原有多个组件整合为 istiod

　　使用全新的部署模式：istiod，这个组件负责处理Sidecar注入、证书分发、配置管理等功能，替代原有组件，降低复杂度，提高易用性。

　　• Pilot：策略配置组件，为Proxy提供服务发现、智能路由、错误处理等。

　　• Citadel：安全组件，提供证书生成下发、加密通信、访问控制。

　　• Galley：配置管理、验证、分发

　　　　Pilot

　　Pilot 是 Istio 的主要控制组件，下发指令控制客户端。在整个系统中，Pilot 完成以下任务：
　　• 从 Kubernetes 或者其他平台的注册中心获取服务信息，完成服务发现过程。
　　• 读取 Istio 的各项控制配置，在进行转换之后，将其发给数据面进行实施。

　　　　Citadel

　　Citadel是 Istio的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。Citadel一直监听 Kube- apiserver，以 Secret的形式为每个服务都生成证书密钥，并在Pod创建时挂载到Pod上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向TLS认证、通道加密、访问授权等安全功能。如图所示，frontend 服务对 forecast 服务的访问用到了HTTP方式，通过配置即可对服务增加认证功能，双方的Envoy会建立双向认证的TLS通道，从而在服务间启用双向认证的HTTPS。

　　三）Istio与kubernetes：架构结合

　　四）版本变化：istio中的mixer架构进化

　　自 Istio 1.5 起，Istio 弃用了mixer，标准指标由 Envoy 代理直接导出。在先前的 Istio 版本中，Mixer 生成了这些指标。

　　Mixer 提供三个核心功能：

前提条件检查。允许服务在响应来自服务消费者的传入请求之前验证一些前提条件。前提条件包括认证，黑白名单，ACL检查等等。
配额管理。使服务能够在多个维度上分配和释放配额。典型例子如限速。
遥测报告。使服务能够上报日志和监控。

　　在Istio内，由于Envoy只是个干活的小兵，因此它也重度依赖Mixer

　　1、Istio遥测指标

　　　　1）代理级别

　　代理级指标是Envoy代理本身提供的有关所有直通流量的标准指标，以及有关代理管理功能的详细统计信息，包括配置和运行信息。

　　Envoy生成的度量标准存在于Envoy资源（例如侦听器和集群）的粒度级别上。

　　　　2）服务级别

　　除了代理级别的度量标准之外，Istio还提供了一组面向服务的度量标准，用于监控服务通信。这些指标涵盖了四个基本的服务监视需求：延迟，流量，错误和饱和。

　　Istio附带了一组默认的仪表板，用于根据这些指标监视服务行为。

　　2、Istio telemetry 进化

　　　　1）Istio telemetry with Mixer（1.5之前）

　　现有的 Istio 提供了名为 Mixer 插件模型用于扩展 Envoy 数据面功能，具体来说，在 Envoy 内部，Istio 开发了一个原生 C++ 插件用于收集和获取运行时请求信息并通过 gRPC 将信息上报给 Mixer，外部 Mixer 则调用各个 Mixer Adapter 用于监控、授权控制、限流等等操作，相关处理结果如有必要再返回给 Envoy 中 C++ 插件用于做相关控制。

　　Mixer 模型虽然提高了极高的灵活性，且对 Envoy 侵入性极低，但是引入了大量的额外的外部调用和数据交互，带来了巨大的性能开销（相关的测试结果很多，按照 istio 社区的数据：移除 Mixer 可以使整体 CPU 消耗减少 50%）。而且 Istio 插件扩展模型和 Envoy 插件模型整体是割裂的，Istio 插件在 out-of-process 中执行，通过 gRPC 进行插件与 Envoy 主体的数据交互，而 Envoy 原生插件则是 in-proxy 模式，在同一个进程中通过虚函数接口进行调用和执行。

　　　　2）Mixerless的实现—Istio Telemetry V2（1.5之后）

　　在 Istio 1.5 中，Istio 提供了全新的插件扩展模型：WASM in proxy。使用 Envoy 支持的WASM机制来扩展插件：兼顾性能、多语言支持、动态下发动态载入、以及安全性。唯一的缺点就是现有的支持还不够完善。

　　为了提升性能，Istio 社区在 1.5 发布中，已经将几个扩展使用 in-proxy 模型（基于 WASM API 而非原生 Envoy C++ HTTP 插件 API）进行实现。但是目前考虑到 WASM 还不够稳定，所以相关扩展默认不会执行在 WSAM 沙箱之中（在所谓 NullVM 中执行）。虽然 istio 也支持将相关扩展编译为 WASM 模块，并在沙箱中执行，但是不是默认选项。

　　所谓 Mixer V2 其最终目标就是将现有的 out-of-process 的插件模型最终用基于 WASM 的 in-proxy 扩展模型来替代。但是目前举例目标仍旧有较长一段路要走，毕竟即使 Istio 社区本身的插件，也未能完全在 WASM 沙箱中落地。但从 Istio 1.5 开始，Istio 社区应该会快速推动 WASM 的发展。

　　定制Metrics

　　大致分两步：

第一步，配置EnvoyFilter。
第二步，在pod中添加annotations。不难理解，由于遥测下沉到Envoy了，因此每一个pod都需要将想要让Prometheus监控的指标声明出来

　　五）核心资源

　　1、VirtualService（虚拟服务）

　　实现服务请求路由规则的功能。

　　虚拟服务来定义路由规则和描述满足条件的请求去哪里，而目标规则则是定义子集和策略，描述到达目标的请求该怎么处理，以图为例

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v3

　　2、DestinationRule（目标规则）

　　实现目标服务的负载均衡、服务发现、故障处理和故障注入的功能。

　　在虚拟服务中使用Hosts配置默认绑定的路由地址，用http.route字段，设置http进入的路由地址，可以看到，他导入到了目标规则为reviews的v3子集

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

　　3、Gateway（网关）

　　让服务网格内的服务，可以被全世界看到。

　　一个运行在网格边缘的负载均衡器，主要工作是接受外部请求，转发到内部的服务，还可以配置对外的端口、协议与内部服务的映射关系。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-gateway
spec:
  selector:
    app: my-gateway-controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

　　一个监听80端口的入口网关，它会将80端口的http流量导入到集群内

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  gateway: 
  - my-gateway
  http:
  - route:
    - destination:
        host: reviews
        subset: v3

　　4、ServiceEntry（服务入口）

　　允许管理网格外的服务的流量

　　在生产环境中会控制内部服务对外界的访问，ServiceEntry就是用来做这个的，我们可以先把内部服务对外部的访问给干掉

kubectl get configmap istio -n istio-system -o yaml | sed 's/mode: ALLOW_ANY/mode: REGISTRY_ONLY/g' | kubectl replace -n istio-system -f -

　　再exec到pod中会发现无法curl www.baidu.com了
　　现在配置一下对应的ServiceEntry

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metabase: 
    name: http-baidu
spec: 
    hosts: 
    - www.baidu.com
    ports:
    - number:80
      name: http
      protocol: HTTP
    resolution: DNS
    location: MESH_EXTERNAL

　　再去curl www.baidu.com会发现可以访问到，这是因为我们已经通过ServiceEntry来注册了 www.baidu.com 在我们的服务中了