CodeVault文档站
  • 中间件
  • Istio
Yyzop
2022-01-27
目录

Istio概述

# Service Mesh

# 概念篇

  • Service Mesh产生的原因
  • Service Mesh的演讲过程
  • Service Mesh的核心功能

# Service Mesh的起源

# 为什么会出现Service Mesh技术？

因为现有的微服务存在着一些问题，具体有哪些问题，期中有两个特性非常重要：

微服务架构的特性

  • 特点1： 围绕业务构建团队
  • 特点2： 去中心化的数据管理

微服务架构的优势

  • 团队层面： 内聚，独立开发业务，没有依赖
  • 产品层面： 服务批次独立，独立部署，没有依赖

# 为什么网络通信是微服务架构痛点？

分布式计算的8个谬论（Fallacies of Distributed Computing Explained）

  • 网络是可靠的 网络延迟是0
  • 宽带是无限的 网络是安全的
  • 网络拓扑从不改变 只有一个管理员
  • 传输成本是0 网络是同构的

# 如何管理和控制服务间通信？

  • 服务注册/发现
  • 路由,流量转移
  • 弹性能力（熔断，超时，重试）
  • 安全
  • 可观察性

以上的功能所有组在一起，就是我们所说的service mesh

# Service Mesh的发展

第一阶段：控制逻辑和业务逻辑耦合

第二阶段：公共库

第三阶段：代理

第四阶段：边车模式（Sidecar）

第五阶段: Service Mesh的出现

Service Mesh演进总结：

逻辑耦合 > 公共库 > 代理 > Sidecar > Service Mesh > Service MeshV2

# 什么是Service Mesh？

一言以蔽之：Service Mesh 是微服务时代的 TCP/IP 协议。

  • 微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序 (opens new window)，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。
  • 目前业界跟微服务相关的开发平台和框架更是不胜枚举：Spring Cloud， Service Fabric，Linkerd，Envoy，Istio ...

# Service Mesh的主要功能

# 1.流量控制🚀

  • 路由，流量转移
  • 超时重试，熔断
  • 故障注入，流量镜像

# 2.策略🚀

  • 流量限制
  • 黑白名单

# 3.网络安全🚀

  • 授权以及身份认证

# 4.可观察性🚀

  • 指标收集和展示
  • 日志收集
  • 分布式追踪

# 与Kubernetes的关系

Kubernetes🌊

  • 解决容器编排与调度的问题
  • 本质上是管理应用生命周期（调度器）
  • 给予Service Mesh 支持和帮助

Service Mesh🌊

  • 解决服务间网络通信问题
  • 本质上是管理服务通信（代理）
  • 是对Kubernetes网络功能方面的扩展和延伸。

# 与API网关的异同点

API网关

  • 负载均衡
  • 服务发现
  • 流量控制

功能有重叠，但角色不同。

Service Mesh在应用内部，而API网关在应用之上（边界）

# 有哪些主流的Service Mesh产品？

时间 相关的Service Mesh的产品
2016 Linkerd、Envoy
2017 Linkerd1.0、Envoy、Istio0.1发布、Conduit发布 Linkerd1.0、Envoy加入CNCF
2018 Istio1.0发布、Envoy稳定发布、Conduit并入Linkerd2.0 Conduit是国内大厂研发
2019 Istio1.1发布、AWS APP Mesh GA、Google Traffic Director beta发布、Kong发布Kuma、Mosn、
2020 Isitio1.5发布 3月份一直到后面在迭代更新

# 什么是Istio？

# 前言

现在最火的后端架构无疑是**微服务了，微服务将之前的单体应用拆分成了许多独立的服务，好处自然很多，但是随着应用的越来越大，微服务暴露出来的问题也就随之而来了，微服务越来越多，管理越来越麻烦，特别是要你部署一套新环境的时候，你就能体会到这种痛苦了，随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等等**问题。如果从头到尾完成过一套微服务框架的话，你就会知道这里面涉及到的东西真的非常多。对于 Java 领域来说还有 Spring Cloud 这种完整的微服务框架，但是也仅仅局限于 Java 语言。当然随着微服务的不断发展，微服务的生态也不断完善，最近就发现新一代的微服务开发就悄然兴起了，那就是 Service Mesh（服务网格）。

# Istio的介绍

官方定义： 它是一个完全开源的服务网格，作为透明的一层接入到现有的分布式应用中，它也是一个平台，可以与任何日志、遥测和策略系统进行集成。Istio多样化的特性让你能够成功而且高效地运行微服务框架，并提供保护，连接和监控微服务的统一方法。

优势：

  • 轻松构建服务网格
  • 应用代码无需更改
  • 功能功强大

Istio核心功能：

  • 流量控制： 路由、流量转移、弹性、测试、
  • 安全： 认证、授权
  • 可观察性： 指标、日志、追踪
  • 策略： 限流、黑白名单

# Istio的使命

Istio的意义

  • 实际上是让你重新定义了微服务的开发方式，让你可以轻松的在你的微服务架构中植入Service Mesh技术。
  • 大幅度降低微服务的应用的开发门槛，让你只关注业务的本身，不用去考虑如何添加很多网络控制相关的功能，或者是类库。
  • 它使用了统一的运维和开发方式，来简化微服务的开发流程。

Istio的战略使命

  • istio 是由Google、IBM、Lyft等共同开源的 Service Mesh（服务网格）框架，于2017年初开始进入大众视野。所以它有这三家公司支撑着。

# Istio的架构

Istio1.0的架构

Istio1.1架构

Istio的架构之伤

复杂是万恶之源，学会停止焦虑，爱上单体————Istio团队

原有的架构复杂性：

  • 维护性
  • 多组件分离的必要性
  • 伸缩性
  • 安全性

架构1.5版本

  • 重建控制平面
  • 整合istod
  • 废弃Mixer
  • 添加新特性
  • 性能提升
  • Bug修复

# Istio核心功能流量控制

Istio流量控制能力

主要功能：

  • 路由、流量转移
  • 流量进出
  • 网络弹性能力
  • 测试相关

核心资源：

  • 虚拟服务（Virtual Service）
  • 目标规则（Destination Rule）
  • 网关（Gateway）
  • 服务入口（Service Entry）
  • Sidecar

  1. # 虚拟服务（Virtual Service）

  • 将流量路由到给定的目标地址
  • 请求地址与真实的工作负载解耦
  • 包含一组路由规则
  • 通常和目标规则（Destination Rule）成对出现
  • 丰富的路由匹配规则

  1. # 目标规则（Destination Rule）

定义虚拟服务路由目标地址的真实地址，即子集（subnet）

设置负载均衡的方式

  • 随机
  • 权重
  • 最少请求数

  1. # 网关（Gateway）

管理进出的网格流量

处在网格的边界

  1. # Sidecar

调整Envoy代理接管的端口和协议

限制Envoy代理可访问的服务

  1. # 网络弹性和测试

弹性能力： 超时 重试 熔断

测试能力： 故障注入 流量镜像

# Istio服务的可观察性

什么是可观察性？

  • 可观察性!=监控
  • 从开发者的角度探究系统的状态
  • 组成： 指标、日志、追踪

  1. # 指标（Metrics）

以聚合的方式监控和理解系统行为

Istio中的指标分类：

  • 代理级别的指标（Proxy-level）
  • 服务级别的指标（Service-level）
  • 控制平面指标（Control plane）

  1. # 代理级别的指标

  • 收集目标： sidecar代理
  • 资源粒度上的网格监控
  • 容许指定收集的代理（针对性的调试）

  1. # 服务级别的指标

  • 用于监控服务的通信
  • 四个基本服务监控的需求： 延迟、流量、错误、饱和
  • 默认指标导出到Prometheus（可自定义和更改）
  • 可根据需求开启和关闭

  1. # 访问日志（Access logs）

  • 通过应用产生的事件来了解系统
  • 包括了完整的元数据信息（目标、源）
  • 生成位置可选（本地、远端、如filebeat）
  • 日志内容：
    • 应用日志
    • Envoy日志 kubectl logs -l app=demo -c istio-proxy

# Istio的安全架构

# 认证

  • 认证方式
  • 策略存储
  • 支持兼容模式

# 认证方式

对等认证（Peer authentication）

  • 用于服务间身份认证
  • Mutual TLS（mTLS）

请求认证（Request authentication）

  • 用于终端用户身份认真
  • JSON Web Token（JWT）

# 认证策略

  • 配置方式
  • 配置生效范围： [网格、命名空间、工作负载（服务）]
  • 策略的更新
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: example-peer-only
  namespace: foo
spec:
  selector:
    matchLabels:
      app: reviews
  mtls:
    mode: STRICT

# 授权

  • 授权级别
  • 策略分发
  • 授权引擎
  • 无需显式启用

# 授权策略

通过创建AuthorizationPolicy实现

组成部分

  • 选择器（Selector）
  • 行为（Action）
  • 规则列表（Rules）
    • 来源（from）
    • 操作（to）
    • 匹配条件（when）
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin-policy
 namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/sleep"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/info*"]
    when:
    - key: request.auth.claims[iss]
      values: ["https://foo.com"]

# 授权策略的设置

范围（目标）设置：metadata/namespace/selector

匹配值： 精确、模糊、前缀、后缀

全部容许和拒绝

自定义条件

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: tester
 namespace: default     #这里是匹配范围
spec:
  selector:
    matchLabels:
      app: products     #包括使用selector选择范围
  action: ALLOW
  rules:
  - to:
    - operation: 
        paths: ["/test/*","*/info"]

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: allow-all
 namespace: default     #这里是匹配范围
spec:
  rules: 
  - {}     #这里表示全部

when:
- key: request.headers[version]
  values: ["v1","v2"]
上次更新: 2023/11/28, 22:03:59
SpringBoot整合ES
Istio安装

← Istio安装→

最近更新
01
学习文档
11-28
02
如何成为FISCO社区的MVP 总结篇
11-28
03
一文搞懂Truffle测试
11-28
更多文章>
Theme by Vdoing | Copyright © 2023-2023 YYzop & Hior | MIT License