【云原生|技术基石】4:速通云原生基石-Istio服务网格

举报
bdi洲 发表于 2022/06/14 23:43:38 2022/06/14
【摘要】 本期文章是介绍云原生技术的基石:Istio服务网格,上次的文章中我们已经学习过了Pod的详细介绍,感兴趣的同学可以去看一下,任意门:【云原生|实战研发】2:Pod的深入实践与理解 云原生Istio...

本期文章是介绍云原生技术的基石:Istio服务网格,上次的文章中我们已经学习过了Pod的详细介绍,感兴趣的同学可以去看一下,任意门:【云原生|实战研发】2:Pod的深入实践与理解

前言:先来聊聊服务网格Service Mesh

提到微服务的时候,我们经常提到服务之间的各类服务网络是如何进行互相调用、互相配置、互相传递请求的。这些都必不可少的不能不提及服务网络。

引用谷歌上面的解释:Service Mesh是微服务时代的 TCP/IP 协议。那么其作用就很好理解了,就是给服务之间提供稳定安全、快速可靠的通讯。一言以盖之,服务网络就是各个服务之间的TCP/IP协议簇,负责我们所熟悉的网络调用、限流、熔断监控等等各种功能。

与实际应用部署一起,并且能对应用透明。下图就是服务网格中常使用的典型的Sidecar边车方式:

也就是说,图中的应用作为服务发起方,需要用最简单的方式将请求发送给本地的服务网格代理,然后代理会进行后续的操作,即服务发现、负载均衡等,然后将请求发送给目标服务即可。

在这里插入图片描述

在项目中,服务肯定是互相调用的并且有很多服务互相调用,那么就是真正意义上的“服务网格”。大致的效果图如下图所示了:这样就是网格的真正含义,看起来形成了一个一个网状格子,每个格子之间互相调用。也就是每个服务之间相互调用。而下面要讲的Istio就是这样一种可以被看做是服务网格的东西。

服务网格旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格,而是一个“代理”的网格,服务可以插入这个代理,从而使网络抽象化。在典型的服务网格中,这些代理作为一个 sidecar(边车)被注入到每个服务部署中。服务不直接通过网络调用服务,而是调用它们本地的 sidecar 代理,而 sidecar 代理又代表服务管理请求,从而封装了服务间通信的复杂性。
在这里插入图片描述

正文:云原生 Istio服务网格

1、Istio的产生背景

先来了解一下Istio的产生背景,才能更方便我们知道Istio是什么。

基于k8s的背景下,k8s作为容器编排工具,其作用就是进行容器编排、解决分布式系统的部署、规划、运维等问题,使得运维可以使用一台机器而得到使用多台机器的效果。

现在的云厂商强调的都是资源弹性,一台机器的资源是有限的,而又不能一下子开很多台服务器的资源,由于网络上的用户流量都是实时变化的,存在流量峰值等情况,所以为了使得减少成本等各种原因,需要机器的弹性资源供应。

那么,简而言之,微服务是解决服务治理的技术。而Kubernetes 和 Istio 的诞生又是为了解决微服务迁移过程中遇到的问题。

Istio就是一种以简单的方式来建立已部署服务的网络,有调用链追踪、动态路由、熔断限流等许多功能,用来配合k8s的服务,并且不需要改动任何服务代码。

2、为什么需要Istio服务网格?

上述背景之下产生的问题:微服务对项目功能进行了细化与简化,将复杂的项目功能划分成许多个微服务来分解和降低项目整体的复杂度,使得这些微服务容易维护。

但其实复杂度并没有就说消失了。微服务拆分之后,单个微服务的复杂度确实是大幅降低了,但由于系统从一个单体划分为许多的一小块微服务, 那么这么多微服务之间也会存在许多问题:每个微服务之间的连接、管理和监控。

如果对这么多的微服务进行部署、版本控制、故障转移、遥测和监控等肯定是十分困难的。并且像限流、访问控制等各类运维需求做起来肯定十分困难。所以,文章最开始介绍的服务网格就诞生了。

3、Istio的功能

  • HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。可以使调用服务时更加可靠,服务更加健壮。
  • 通过丰富的路由规则、重试、故障转移和故障注入,可以对流量行为进行细粒度控制。了解服务之间的依赖关系,以及服务之间流量的本质和流向,从而提供快速识别流量问题的能力。
  • 可插入的策略层和配置 API,支持访问控制、速率限制和配额。
  • 对出入集群入口和出口中所有流量的自动度量指标、日志记录和追踪。
  • 通过强大的基于身份的验证和授权,在集群中实现安全的服务间通信。
  • 支持多平台,可以在许多环境中运行Istio,如k8s、跨云上等。

上述的这些功能极大的减少了应用程序代码,以及底层平台和策略的耦合度。

4、Istio的架构

Istio服务网格的架构分为 数据面板控制面板

  • 数据面板:是由一组智能代理(Envoy)组成,其代理部署模式为边车模式,可以调解和控制服务之间的所有网络通信。
  • 控制面板:负责在运行时执行策略,管理和配置代理进行路由流量。

如下图所示,为Istio的架构图。

在这里插入图片描述

Envoy

在这里插入图片描述

Envoy属于数据面板,官方文档介绍Envoy的功能:

  • Istio 使用Envoy代理的扩展版本,Envoy是以C++开发的高性能代理,用于调解服务网格中所有服务的所有入站和出站流量。
  • Istio利用了Envoy的许多内置功能,例如动态服务发现,负载均衡,TLS termination,HTTP/2&gRPC代理,熔断器,健康检查,基于百分比流量拆分的分段推出,故障注入和丰富的metrics。
  • Envoy实现了过滤和路由、服务发现、健康检查,提供了具有弹性的负载均衡。它在安全上支持TLS,在通信方面支持gRPC。

大致的来说,其功能是:提供服务间的网络通讯能力(如Http、GRPC、TCP),及与网络通信直接相关的服务(如负载均衡、健康检查、执行路由规则等。)

Envoy在Istio中是负责基础底层工作的模块部分,也就是说,Envoy是真正进行操作的,需要将其他部分的决策、控制等进行运行配置。

Pilot

Pilot属于控制面板,可以对Envoy进行控制指挥。官方文档介绍其功能:

  • Pilot负责收集和验证配置并将其传播到各种Istio组件。它从Mixer和Envoy中抽取环境特定的实现细节,为他们提供独立于底层平台的用户服务的抽象表示。此外,流量管理规则(即通用4层规则和7层HTTP/gRPC路由规则)可以在运行时通过Pilot进行编程。

  • 每个Envoy实例根据其从Pilot获得的信息以及其负载均衡池中的其他实例的定期健康检查来维护 负载均衡信息,从而允许其在目标实例之间智能分配流量,同时遵循其指定的路由规则。

  • Pilot负责在Istio服务网格中部署的Envoy实例的生命周期。
    在这里插入图片描述

Mixer

Mixer的作用:在服务网格上执行使用策略与访问控制,收集Envoy代理和其他服务的遥测数据。

Mixer是为了降低应用程序的微服务与基础设施的后端服务之间的耦合而创造的。即Mixer为前面两者的中介。

在这里插入图片描述

Istio使用属性来控制服务网格中运行服务时的行为。在请求处理时,属性由Envoy收集后发送给Mixer,Mixer中根据运维人员设置的配置来处理属性。基于这些属性,Mixer会产生对各种基础设施后端的调用。
在这里插入图片描述

Istio-Auth

简单来说,其作用就是鉴权。提供服务到服务的认证、终端用户的认证。也可以通过增加细粒度的访问控制与审计,以使用各种访问控制机制来监控服务等。

下图中展示的鉴权过程中,三个重要的模块分别是:身份信息、秘钥管理、通信安全加密。

服务A以foo账户运行,服务B则是bar运行,A与B之间的通讯原本是没有加密的。但是Istio在不修改代码的情况下,通过Envoy的服务网格,直接可以在客户端的服务网格Envoy与服务器端的服务网格Envoy进行加密通讯。
在这里插入图片描述

后文:总结Istio

现在通过上文的学习已经学习到,Istio的基本原理、架构以及组成部件的作用。

Istio的功能:
1、流量管理:通过配置进行服务间的流量限制、流量管理,设置超时、重试等简单配置。
2、可观测性:通过跟踪、监控、记录让我们更好的了解到正在运行的服务。
3、高安全性:通过代理层进行管理认证、加密授权、通信等,可以可靠安全的进行服务执行。
在这里插入图片描述

文章来源: blog.csdn.net,作者:洲的学习笔记,版权归原作者所有,如需转载,请联系作者。

原文链接:blog.csdn.net/weixin_51484460/article/details/125174653

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

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

全部回复

上滑加载中

设置昵称

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

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

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