k8s微服务isito相关知识和例子

最新推荐文章于 2024-09-25 14:10:10 发布

iwtbs_kevin

最新推荐文章于 2024-09-25 14:10:10 发布

阅读量4.9k

点赞数

分类专栏： AIops 文章标签： k8s 容器虚拟化故障注入 istio

本文链接：https://blog.csdn.net/qq_34219959/article/details/100303632

版权

AIops 专栏收录该内容

16 篇文章 13 订阅

订阅专栏

文章目录

istio是什么
流量管理
Bookinfo应用部署

istio是什么

服务网格

服务网格（Service Mesh）这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。

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

istio

Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，只需要对服务的代码进行一点或不需要做任何改动。想要让服务支持 Istio，只需要在您的环境中部署一个特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，拦截微服务之间的所有网络通信：

HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制。
可插入的策略层和配置 API，支持访问控制、速率限制和配额。
对出入集群入口和出口中所有流量的自动度量指标、日志记录和追踪。
通过强大的基于身份的验证和授权，在集群中实现安全的服务间通信。
Istio 旨在实现可扩展性，满足各种部署需求

架构

Istio 服务网格逻辑上分为数据平面和控制平面。

数据平面由一组以 sidecar 方式部署的智能代理（Envoy）组成。这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。
控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。
下图显示了构成每个面板的不同组件：

在这里插入图片描述

流量管理

Pilot 和 Envoy

Pilot 负责管理通过 Istio 服务网格发布的 Envoy 实例的生命周期。
在这里插入图片描述

服务之间的通讯

在这里插入图片描述

服务发现与负载均衡

在这里插入图片描述

Bookinfo应用部署

项目介绍

部署一个样例应用，它由四个单独的微服务构成，用来演示多种 Istio 特性。这个应用模仿在线书店的一个分类，显示一本书的信息。页面上会显示一本书的描述，书籍的细节（ISBN、页数等），以及关于这本书的一些评论。

Bookinfo 应用分为四个单独的微服务：

productpage ：productpage 微服务会调用 details 和 reviews 两个微服务，用来生成页面。
details ：这个微服务包含了书籍的信息。
reviews ：这个微服务包含了书籍相关的评论。它还会调用 ratings 微服务。
ratings ：ratings 微服务中包含了由书籍评价组成的评级信息。

reviews 微服务有 3 个版本：

v1 版本不会调用 ratings 服务。
v2 版本会调用 ratings 服务，并使用 1 到 5 个黑色星形图标来显示评分信息。
v3 版本会调用 ratings 服务，并使用 1 到 5 个红色星形图标来显示评分信息。

Bookinfo 是一个异构应用，几个微服务是由不同的语言编写的。这些服务对 Istio 并无依赖，但是构成了一个有代表性的服务网格的例子：它由多个服务、多个语言构成，并且 reviews 服务具有多个版本

部署应用

把 Envoy sidecar 注入到每个服务之中。部署结果如下图所示：
在这里插入图片描述

智能路由

请求路由，首先会把 Bookinfo 应用的进入流量导向 reviews 服务的 v1 版本。接下来会把特定用户的请求发送给 v2 版本，其他用户则不受影响。
故障注入，会使用 Istio 测试 Bookinfo 应用的弹性，具体方式就是在 reviews:v2 和 ratings 之间进行延迟注入。接下来以测试用户的角度观察后续行为，我们会注意到 reviews 服务的 v2 版本有一个 Bug。注意所有其他用户都不会感知到正在进行的测试过程。
流量迁移，最后，会使用 Istio 将所有用户的流量从 reviews 的 v2 版本转移到 v3 版本之中，以此来规避 v2 版本中 Bug 造成的影响。

首先将所有流量导入v1版本的reviews

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

让普通用户全部访问 v1 版，而特殊用户（jason）访问 v2 版。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

故障注入

abort故障注入

我们可以看到对于版本v1的路由规则里多了一条fault对象。这个fault对象中，则包含了设定的故障属性。可以解读为，v1版本添加abort故障并且设定返回的http状态码为501，percent设定为100这意味着所有访问v1的请求都会收到501的http响应，显而易见如果这里设成50则只有一半的请求会收到501响应，另一半则会收到正常的响应
延时故障注入
我们已经给v1版本注入了中断故障，现在我们给v4版本注入延时故障，设定时间延迟为2秒，并且所有访问v4的请求都会有2秒的延迟
其他例子1

在这个例子中，当cookie满足user=vip时会触发延时故障，2秒延时后访问v4版本，当user=svip的时候则会触发中断故障，当cookie不满足以上两个条件时，则可以正常访问v1版本
其他例子2

在这个例子中不论cookie符合vip还是svip，亦或是都不符合两个条件，都可以正常的访问到v1版本。这是由于route对象放在了第一个，没有任何匹配条件，不管cookie值是什么都“满足条件”，所以所有的流量不加任何处理直接会流向版本v1，这里要特殊提醒下，如若自己手动添加故障注入一定要注意相对顺序，否则可能不会出现你想设定的结果
其他例子3

这个virtual service中我们对同一个版本注入了两个不同的故障，满足任何一个条件都可以触发相应的故障，如果所有条件都不满足则会默认的正常访问v1版本。那么问题来了，如果我没有配置最后一条route，出现了一条既不符合中断故障匹配条件，也不符合延时故障匹配条件，请求会走向哪里呢？对于这种yaml设置，结果异常的简单直白，如果请求不符合任何条件，则会直接获得404的响应，不会自动流入任何其他的版本

深入遥测

如何使用 Istio Mixer 和 Istio sidecar 获取指标和日志，并在不同的服务间进行追踪

收集指标：配置 Mixer，收集 Bookinfo 应用中所有服务的系列指标。
查询指标：安装 Prometheus 插件，用来收集指标，并在 Prometheus 服务中查询 Istio 指标。
分布式追踪：这个任务会使用 Istio 来对应用中请求的流动路径进行追踪。最终用户所体验的总体延迟在服务之间是如何分布的？分布式追踪能够解决这一疑问，从而帮助开发人员更快的解决问题，这也是对分布式应用进行分析和排错的有力工具。
使用 Istio Dashboard：安装 Grafana 插件，这一插件中带有一个预配置 Dashboard，可以用来对服务网格中的流量进行监控。