【云驻共创】华为云云原生之Istio控制面架构深度剖析

举报
愚公搬代码 发表于 2022/03/23 15:30:00 2022/03/23
【摘要】 本文主要介绍的内容有:Istio的基本概念、Istio整体架构及工作原理、lstio无侵入的Sidecar基本原理、Istio服务网格基本功能实现原理。

前言

本文主要介绍的内容有:

  • Istio的基本概念
  • Istio整体架构及工作原理
  • lstio无侵入的Sidecar基本原理
  • Istio服务网格基本功能实现原理

一、Istio的基本概念

1.Istio诞生背景

Istio是一个开源的服务网格平台,是由谷歌、IBM与Lyft共同开发,主要是为了统一微服务连接、安全保障、管理与监控方式。

Istio主要功能有:

  • 提供流量管理机制。
  • 为扩展需求安全性、监控、路由、连接管理与策略等其他功能,创造了基础。

Istio这款软件利用久经考验的Lyft Envoy代理进行构建,可在无需对应用程序代码作出任何发动的前提下实现可视性与控制能力。Istio项目是一款强大的工具,可以为企业管理者提供实施整体性安全、政策与合规性的要求。

2.Istio的定义

Istio提供一种简单的方式来建立已部署的服务的网络上实现限流,熔断,负载均衡,服务认证,链路监控等等功能。实现这些功能可以不需要改动任何服务代码。有了Istio,就相当于有了微服务开发框架,也不再需要自己手动实现各种复杂的服务治理功能。只要服务的客户端和服务端可以进行简单的直接网络访问,就可以通过将网络层委托Istio,从而获得一系列的完备功能。可以近似的理解为:Istio 包含了微服务框架的相关功能

3.Istio优势

Istio的优势 说明
系统的可视性 1.现实的问题:在运行系统的时候,我们比较关心的是集群运行状况,需要非常多的工具才能实时了解系统状态,成本非常高。2.Istio的优势:Istio项目就能够实现系统的实时监控与应用程序及网络活动相关的数据,利用Prometheus和Grafana对这这些活动数据加以渲染,而后将分析出来的指标和日志信息发送至相关系统中用来实现功能扩展。Istio项目亦利用Zipkin追踪分析性能热点并对分布式故障模式加以诊断。
运维的伸缩与效率 1.现实的问题:在开发微服务项目的时候,运维人员需要考虑系统的各个方面。比如利用断网重试、负载均衡、限流以及降级等方式解决由网络造成的各类常见故障情况。2.Istio的优势:Istio项目则提供一种统一方法以配置上述功能,使得运维人员能够更为轻松地运作高弹性水平服务网格。
系统的开发效率 1.现实的问题:要部署微服务项目开发人员需将分布式系统问题解决机制引入编写的代码当中,这样会照成运维上的困难,开发人员还得考虑各种分布式情况。2.Istio的优势:Istio项目能够确保开发人员专注于构建服务功能,从而极大提升其生产能力。另外,Istio项目则负责以统一化方式处理弹性与网络挑战。Istio项目还能够支持A/B测试、金丝雀部署以及故障注入等常用功能,旨在进一步提高生产效率。
系统的独立性 1.现实的问题:微服务项目运行其实是相互关联,互相调用服务的,会导致系统安全性、监控能力、扩展性与服务拓扑水平的不足。2.Istio的优势:Istio项目能够授权具有不同开发人员以实现独立运作。其将集群运营人员与功能开发人员进行周期性剥离,从而在无需更改代码的前提下弥补上述的不足。运维人员可以控制系统服务的匹配,从而匹配新的服务版本。另外,运维人员还能够在流量中注入故障或者提高延迟水平,用来测试服务的弹性,同时设置速率限制以防止服务过载。Istio项目还可用于强制执行合规性要求,例如在服务之间定义CL以确保仅具备授权的服务间可相互通信。
系统的安全性 1.现实的问题:在微服务系统中经常存在着大量网络安全问题。2.Istio的优势:Istio项目允许运维人员利用TLS连接来认证并保护各服务之间的所有通信,而不会给开发人员或者运营人员带来由证书管理造成的额外负担。其安全框架与新的SPIFFE规范保持一致,事实上谷歌公司一直在内部广泛使用类似的保障性系统。
系统的选择性 1.现实的问题:微服务系统一般都说互相调用,停止某些服务可能会造成其他服务问题。2.Istio的优势:在设计Istio项目时充分考虑到网络内所运行各服务的透明性,允许团队随着时间推移逐步采用Istio提供的各项功能。采用方可以先从启用集群范围内可视性起步,并在Istio在环境中的表现感到满意后根据实际需要启用其它功能。

二、Istio整体架构及工作原理

1.Istio整体架构

Istio架构分层来看主要分为

  • 控制面Istiod(Pilot、Citadel、Galley、Sidecar-lnjector)

    控制平面管理并配置代理来进行流量路由。此外,控制平面配置 Mixer 来执行策略和收集遥测数据。

  • 数据面(Envoy、Pilot-Agent)

    数据平面由一组智能代理(Envoy)组成,被部署为 sidecar。这些代理通过一个通用的策略和遥测中心(Mixer)传递和控制微服务之间的所有网络通信。

1.1 控制面Istiod

控制面主要分为以下4部分:

  • Pilot:xDS服务器,为数据面代理提供各种配置
  • Citadel:为数据面签发证书
  • Galley:Admission Webhook,校验Istio API配置
  • Sidecar-lnjector:自动注入Sidecar

在这里插入图片描述

1.1.1 Pilot

Pilot基本架构:

  • 原生支持Kubernetes,List-Watch Service,Endpoint,Pod,Node,etc
  • 扩展支持其他注册中心,以MCP协议的方式
  • xDS服务器向下对所有的数据面Sidecar提供xDS配置
  • 中间内核层负责生成xDS配置,每一种xDS对应有一种生成器,xDS Generator深入理解Istio API与Envoy API之间的转换

在这里插入图片描述
服务列表中的istio-pilot是istio的控制中枢Pilot服务。如果把数据面的envoy也看作一种agent,则Pilot类似传统C/S架构中的服务端Master,下发指令控制客户端完成业务功能。和传统的微服务架构对比,Pilot至少涵盖服务注册中心和Config Server等管理组件的功能。pilot可以直接从kubernetes,consul提取数据并将其构造和转换成istio的服务发现模型,因此pilot只有服务发现功能,无须进行服务注册。这种抽象模型解耦Pilot和底层平台的不同实现,可支持kubernetes,consul等平台
在这里插入图片描述

1.1.2 Citadel

Citadel基本架构:

  • Citadel是服务网格的安全组件与NodeAgent一起为工作复杂提供证书的签发、轮换。
  • Citadel对下处理来自NodeAgent的CSR请求
  • Citadel内部签发证书主要有两种形式:
    • 本身作为CA自己签发
    • 作为RA代理CSR请求

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

1.1.3 Galley

Galley负责配置管理相关的工作。
Galley基本架构:

  • Admission Webhook提供配置校验
  • MCP Sink提供配置的摄取

在这里插入图片描述

1.1.4 Sidecar-lnjector

sidecar-injector是负责动态注入的组件,只要开启了自动注入,在Pod创建时就会自动调用sidecar-injector向Pod中注入Sidecar容器。在Kubernetes环境下,根据自动注入配置,Kube-apiserver在拦截到Pod创建的请求时,会调用自动注入服务sidecar-injector生成Sidecar容器的描述并将其插入原Pod的定义中。这样,在创建的Pod内除了包括业务容器,还包括Sidecar容器。这个注入过程对用户透明,用户使用原方式创建工作负载。

1.2 数据面

1.2.1 Envoy

istio的sidecar(istio-proxy)是开源项目envoy的扩展版,Envoy是用C++开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面,是istio架构中唯一的数据面组件,Envoy提供了动态服务发现、负载均衡、TLS,HTTP/2及gRPC代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能。在istio-proxy容器中除了有Envoy,还有一个pilot-agent的守护进程。
在这里插入图片描述

1.2.2 Pilot-Agent

Pilot-Agent基本架构:

  • 渲染Envoy的启动模板,生成Bootstrap配置文件,最后启动Envoy进程
  • Envoy的守护功能
  • 代理应用健康检查
  • NodeAgent SDS服务器,与Citadel协作
  • xDS代理
  • Local DNS服务

在这里插入图片描述

三、lstio无侵入的Sidecar基本原理

1.Sidecar基本介绍

将属于应用程序的功能拆分成单独的进程,这个进程可以被理解为Sidecar。在微服务体系内,将集成在应用内的微服务功能剥离到了sidecar内,sidecar提供了微服务发现、注册,服务调用,应用认证,限速等功能。

  • Sidecar自动注入,由Sidecar lnjector负责,支持按照Namespace以及按照应用注入
  • 业务代码不感知Sidecar的存在
  • Sidecar负责拦截应用的流量,并且提供流量治理、安全、监控三大功能

在这里插入图片描述
sidecar容器内部运行着pilot-agent与envoy

  • Pilot-agent:基于kubernetes API资源对象为envoy初始化可用的bootstrap配置进行启动,在运行后管理envoy运行状态,如配置变更,出错重启等。
  • envoy:数据平面的执行层,由pilot-agent所启动的,从xDS API动态获取配置信息。Envoy并通过流量拦截机制处理入栈及出栈的流量。

2.Sidecar流量拦截

  • InitContainer或lstio-CNI设置iptables规则
  • 流量拦截的流程

在这里插入图片描述

2.1 Sidecar流量拦截完整流程

sidecar通过注入到Pod中的init,执行在pod命名空间中设置iptable规则来完成流量捕获并管理。通过查看nsenter命令可以查看对应实现的内容。

iptables中的4条主要链如下:ISTIO_INBOUND、ISTIO_IN_REDIRECT、ISTIO_OUTPUT、ISTIO_REDIRECT

完整流程参考下面代码:

# nsenter -t `ps -ef|grep details|grep envoy|awk '{print $2}'` -n iptables -t nat -S 
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N ISTIO_INBOUND
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp -m tcp --dport 15008 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 22 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT 

-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006

-A ISTIO_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN

-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT

-A ISTIO_OUTPUT -o lo -m owner ! --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN

-A ISTIO_OUTPUT -j ISTIO_REDIRECT

-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001

3.Envoy基本介绍

  1. envoy是作为微服务服务架构中以独立进程方式实现高级网络功能的,轻量级的7层服务代理程序,通常以sidecar的方式运行在应用程序的周边,也可以作为网络的边缘代理来运行
  2. envoy的特性是进程外体系结构,L3/L4过滤器体系结构,HTTP L7过滤器体系结构,一流的HTTP/2支持,HTTP/3支持(目前为alpha),HTTP L7路由,gRPC支持,服务发现和动态配置,健康检查,高级负载平衡,前端/边缘代理支持,一流的可观察性

3.1 Envoy相关组件

在这里插入图片描述

  • Downstream:主要是指连接到Envoy的主机,这些主机用来发送请求并接受响应。
  • Upstream:主要是指接收来自Envoy连接和请求的主机,并返回响应。
  • Listener:主要是服务或程序的监听器,Envoy暴露一个或多个监听器监听下游主机的请求,当监听到请求时,通过Filter Chain把对请求的处理全部抽象为Filter,例如ReadFilter、WriteFilter、HttpFilter等。
  • Cluster:主要是服务提供集群,指Envoy连接的一组逻辑相同的上游主机。Envoy通过服务发现功能来发现集群内的成员,通过负载均衡功能将流量路由到集群的各个成员。

4.Envoy流量代理流程

在这里插入图片描述

  • LDS:istioctl pc listener{podname}
  • RDS:istioctl pc route{podname}
  • CDS:istioctl pc cluster{podname}
  • EDS:istioctl pc endpoint{podname}

4.1 XDS具体概念

XDS相关概念:XDS是一组基于不同数据源的服务发现协议的总称,包括CDS、LDS、EDS、RDS等。在Istio架构中,基于xDS协议提供了标准的控制面规范,并以此向数据面传递服务信息和治理规则。在Envoy中,xDS被称为数据平面API,并且担任控制平面Pilot和数据平面Envoy的通信协议。

4.2 CDS具体概念

CDS相关概念:Envoy使用它在进行路由的时候发现上游Cluster。Envoy通常会优雅地添加、更新和删除Cluster。有了CDS协议,Envoy在初次启动的时候不一定要感知拓扑里所有的上游Cluster。在做路由HTTP请求的时候通过在HTTP请求头里添加Cluster信息实现请求转发。

4.3 EDS具体概念

EDS相关概念:在Envoy术语中,Endpoint即Cluster的成员。Envoy通过EDS API可以更加智能地动态获取上游Endpoint。

4.4 LDS具体概念

LDS相关概念:基于此,Envoy可以在运行时发现所有的Listener,包括L3和L4 filter等所有的filter栈,并由此执行各种代理工作,如认证、TCP代理和HTTP代理等。添加LDS使得Envoy的任何配置都可以动态执行。

4.5 RDS具体概念

RDS相关概念:用于Envoy在运行时为HTTP连接管理filter获取完整的路由配置,比如HTTP头部修改等。并且路由配置会被优雅地写入而无需影响已有的请求。当RDS和EDS、CDS共同使用时,可以帮助构建一个复杂的路由拓扑蓝绿发布等。

4.6 小结

ADS、EDS、CDS等每个独立的服务都对应了不同的gRPC服务名称。对于需要控制不同类型资源抵达Envoy顺序的需求,可以使用聚合发现服务,即Aggregated xDS,它可以通过单一的gRPC服务流支持所有的资源类型,借助于有序的配置分发,从而解决资源更新顺序的问题。

5.Envoy流量匹配与转发

在这里插入图片描述

5.1 Envoy流量匹配与转发完整流程

在这里插入图片描述
概念:

LDS(Listener Discovery Service):监听发现服务

RDS(Route Discovery Service):路由发现服务

CDS(Cluster Discovery Service):集群发现服务

EDS(Endpoint Discovery Service):集群成员发现服务

四、Istio服务网格基本功能实现原理

1.流量治理基本API

API 意义
ServiceEntry 定义Kubernetes集群外部服务,提供非K8s服务发现或者跨集群的服务发现
VirtualService 定义一些路由匹配、灰度、故障注入等功能
DestinationRule 提供目标服务的负载均衡策略以及连接管理,熔断等策略
Gateway 为服务网格边缘提供基本的流量转发策略

2.流量治理基本原理

在这里插入图片描述

2.1 Istio流量治理的基本流程

在控制面会经过如下流程:
(1)管理员通过命令行或者API创建流量规则;
(2)Pilot将流量规则转换为Envoy的标准格式;
(3)Pilot将规则下发给Envoy。

在数据面会经过如下流程:
(1)Envoy拦截Pod上本地容器的Inbound流量和Outbound流量;
(2)在流量经过Envoy时执行对应的流量规则,对流量进行治理。

3.服务发现

在这里插入图片描述

3.1 Istio服务发现的基本流程

在这里插入图片描述
服务发现与负载均衡,只是一个种策略实施的特例:

(1)提供服务的SvcB新增一个Pod(标号1);

(2)在Pilot后台修改SvcB的集群配置(标号2);

(3)Pilot将SvcB的最新信息同步给该配置的订阅方(标号3),即SvcB的调用方SvcA对应的Proxy;

(4)SvcA对应的Proxy增加到SvcB的链接(标号4),并实施负载均衡;

4.路由匹配

在这里插入图片描述

5.灰度发布

在这里插入图片描述

5.1 灰度发布的基本流程

按比例灰度发布
在这里插入图片描述
如上图所示,服务A调用服务B,服务B要发布一个灰度版本,需要5%的流量打到服务B的新版本,只需要:

(1)部署服务B的新版本;

(2)控制平面Pilot上进行策略配置,策略同步到Envoy;

(3)数据平面Envoy接收到策略配置,实时分流策略;

按流程灰度发布
在这里插入图片描述
如上图所示,服务B要发布一个灰度版本,需要把iPhone的流量打到B的新版本,操作流程完全一样(部署服务,Pilot控制,Envoy实施),非常方便。

如果Envoy原来只支持按照流量比例分流,不支持基于应用层协议分流,此时只需要:

(1)升级Envoy的分流策略,以及策略控制端Pilot;

(2)调用方服务A不需要升级;

(3)服务方服务B也不需要升级;

6.服务网格监控-Observability

Istio以非侵入的方式提供了以下遥测类型:

  • Metrics
  • Distributed Traces
  • Access Logs

6.1 服务网格监控-Metrics

在这里插入图片描述

6.2 服务网格监控-Trace

应用必须要从接收的请求中采集以下信息,并且发送给下一跳,这一点也证明服务网格并非完全零侵入

  • x-request-id
  • x-b3-traceid
  • x-b3-spanid
  • x-b3-parentspanid
  • x-b3-sampled
  • x-b3-flags
  • x-ot-span-context

依赖Envoy Tracer支持多种Trace后端:Zipkin Lightstep Datadog Stackdriver Opencensus Skywalking

在这里插入图片描述
Trace包含一个或者多个Span,Span表示一个逻辑单元,拥有起止时间并且包
含Metadata,每个Span又包含:

  • Originating service cluster setvia --service-cluster
  • Start time and duration of the request
  • Originating host set via–service-node
  • Downstream cluster set via the x-envoy-downstream-service-clusterheader.
  • HTTP request URL, method, protocoland user-agent.
  • Additional custom tags set via custom_tags.
  • Upstream cluster name, observability name, and address.
  • HTTP response status code.
  • GRPC response status and message (if available).
  • An error tag when HTTP status is 5xx or GRPC status is not’OK’

6.3 服务网格监控-AccessLog

在这里插入图片描述

在这里插入图片描述

总结

本文主要介绍的内容有:Istio的基本概念、Istio整体架构及工作原理、lstio无侵入的Sidecar基本原理、Istio服务网格基本功能实现原理。Istio是一个服务治理平台,治理的是服务间的访问,只要有访问就可以治理,不在乎这个服务是不是所谓的微服务,也不要求跑在其上的代码是否是微服务化的。

Istio在服务网络中统一提供的关键功能如下:

  • 流量控制:控制服务之间的流量和API调用的流向,使得调用更可靠,并使网络在恶劣情况下更加健壮。
  • 可观察性:了解服务之间的依赖关系,以及它们之间流量的本质和流向,从而提供快速识别问题的能力。
  • 策略执行:将组织策略应用于服务之间的互动,确保访问策略得以执行,资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
  • 服务身份和安全:为网格中的服务提供可验证身份,并提供保护服务流量的能力,使其可以在不同可信度的网络上流转。

除此之外,Istio针对可扩展性进行了设计,以满足不同的部署需要:

  • 平台支持:Istio旨在在各种环境中运行,包括跨云,预置,Kubernetes,Mesos等。最初专注于Kubernetes,但很快将支持其他环境。
  • 集成和定制:策略执行组件可以扩展和定制,以便与现有的ACL,日志,监控,配额,审核等解决方案集成。

这些功能极大地减少了应用程序代码,底层平台和策略之间的耦合,使微服务更容易实现。

参考链接


本文整理自华为云社区【内容共创】活动第14期。

查看活动详情:https://bbs.huaweicloud.com/blogs/336904

相关任务详情:任务22.华为云云原生钻石课程12:Istio控制面架构深度剖析

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。