大规模场景下对Istio的性能优化

这篇具有很好参考价值的文章主要介绍了大规模场景下对Istio的性能优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

简介

当前istio下发xDS使用的是全量下发策略,也就是网格里的所有sidecar(envoy),内存里都会有整个网格内所有的服务发现数据。这样的结果是,每个sidecar内存都会随着网格规模增长而增长。

Aeraki-mesh

aeraki-mesh项目下有一个子项目专门用来处理istio配置分发性能问题,我们找到该项目:
https://github.com/aeraki-mesh/lazyxds

从该项目的部署yaml中,我们知道它会在网格中增加两个组件:

  • egress:充当类似网格模型中默认网关角色

  • controller:用来分析并补全服务间的依赖关系

Egress

对应的配置文件为:lazyxds-egress.yaml
下面来一一查看该组件的组成部分

组件配置
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-egressgateway-lazyxds
  namespace: istio-system
  labels:
    app: istio-egressgateway-lazyxds
    istio: egressgateway
spec:
  replicas: 1
  selector:
    matchLabels:
      app: istio-egressgateway-lazyxds
      istio: egressgateway
  template:
    metadata:
      annotations:
        sidecar.istio.io/discoveryAddress: istiod.istio-system.svc:15012
        sidecar.istio.io/inject: "false"
      labels:
        app: istio-egressgateway-lazyxds
        istio: egressgateway
    spec:
      containers:
        - args:
            ......
          image: docker.io/istio/proxyv2:1.10.0
          imagePullPolicy: IfNotPresent
          name: istio-proxy
          ports:
            - containerPort: 8080
              protocol: TCP
            - containerPort: 15090
              name: http-envoy-prom
              protocol: TCP
          ......
          volumeMounts:
            - mountPath: /etc/istio/custom-bootstrap
              name: custom-bootstrap-volume
            ......
      volumes:
        - configMap:
            defaultMode: 420
            name: lazyxds-als-bootstrap
          name: custom-bootstrap-volume

由于配置太多,这里只挑选主要的部分,从上面可以看出,其实是启动一个istio proxy,该proxy的启动配置文件是使用的configmap挂载出来的。

启动配置
apiVersion: v1
kind: ConfigMap
metadata:
  name: lazyxds-als-bootstrap
  namespace: istio-system
data:
  custom_bootstrap.json: |
    {
      "static_resources": {
        "clusters": [{
          "name": "lazyxds-accesslog-service",
          "type": "STRICT_DNS",
          "connect_timeout": "1s",
          "http2_protocol_options": {},
          "dns_lookup_family": "V4_ONLY",
          "load_assignment": {
            "cluster_name": "lazyxds-accesslog-service",
            "endpoints": [{
              "lb_endpoints": [{
                "endpoint": {
                  "address": {
                    "socket_address": {
                      "address": "lazyxds.istio-system",
                      "port_value": 8080
                    }
                  }
                }
              }]
            }]
          },
          "respect_dns_ttl": true
        }]
      }
    }

从上面配置可以知道:

  • 定义了proxy组件代理的集群,该集群为"lazyxds-accesslog-service"

  • 该集群对应的后端服务地址为"lazyxds.istio-system",端口为8080
    这个后端就是lazyxds controller,后面细说

EnvoyFilter

从yaml文件我们看到,还定义了一个envoyfilter来修改proxy代理的流量配置

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: lazyxds-egress-als
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      app: istio-egressgateway-lazyxds
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        context: GATEWAY
        listener:
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
      patch:
        operation: MERGE
        value:
          typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
            access_log:
              ......
              - name: envoy.access_loggers.http_grpc
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.access_loggers.grpc.v3.HttpGrpcAccessLogConfig
                  common_config:
                    log_name: http_envoy_accesslog
                    transport_api_version: "V3"
                    grpc_service:
                      envoy_grpc:
                        cluster_name: lazyxds-accesslog-service

从这个配置文件,可以看出在启动envoy时,会向其注入一个accesslog service,也就是envoy的日志收集器,而这个service就是lazyxds-accesslog-service

Controller

具体的lazy xds实现就是通过这个controller实现的

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: lazyxds
  name: lazyxds
  namespace: istio-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: lazyxds
  template:
    metadata:
      labels:
        app: lazyxds
    spec:
      serviceAccountName: lazyxds
      containers:
        - image: aeraki/lazyxds:latest
          imagePullPolicy: Always
          name: app
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: lazyxds
  name: lazyxds
  namespace: istio-system
spec:
  ports:
    - name: grpc-als
      port: 8080
      protocol: TCP
  selector:
    app: lazyxds
  type: ClusterIP

从配置可以看到,在egress环节我们知道了proxy的代理的后端地址为lazyxds.istio-system,刚好对应这里的controller。

并且我们还知道,envoy的访问日志最终会发送给这个controller来处理,而这就是实现增量下发envoy配置的关键之处,也就是解决istio性能的解决之法。

增量下发

Accesslog接口

要接受envoy的访问日志,必须实现envoy定义的接口:

type AccessLogServiceServer interface {
   // Envoy will connect and send StreamAccessLogsMessage messages forever. It does not expect any
   // response to be sent as nothing would be done in the case of failure. The server should
   // disconnect if it expects Envoy to reconnect. In the future we may decide to add a different
   // API for "critical" access logs in which Envoy will buffer access logs for some period of time
   // until it gets an ACK so it could then retry. This API is designed for high throughput with the
   // expectation that it might be lossy.
   StreamAccessLogs(AccessLogService_StreamAccessLogsServer) error
}

日志解析

lazyxds实现如下:

func (server *Server) StreamAccessLogs(logStream als.AccessLogService_StreamAccessLogsServer) error {
   for {
      data, err := logStream.Recv()
      if err != nil {
         return err
      }

      httpLog := data.GetHttpLogs()
      if httpLog != nil {
         for _, entry := range httpLog.LogEntry {
            server.log.V(4).Info("http log entry", "entry", entry)
            fromIP := getDownstreamIP(entry)
            if fromIP == "" {
               continue
            }

            upstreamCluster := entry.CommonProperties.UpstreamCluster
            svcID := utils.UpstreamCluster2ServiceID(upstreamCluster)

            toIP := getUpstreamIP(entry)

            if err := server.handler.HandleAccess(fromIP, svcID, toIP); err != nil {
               server.log.Error(err, "handle access error")
            }
         }
      }
   }
}

上面主要的逻辑就是解析envoy的访问日志,然后进行处理:

  • lazy xds Controller 会对接收到的日志进行访问关系分析,然后把新的依赖关系表达到 sidecar CRD 中。

  • 同时 Controller 还会更新 Egress 的规则:删除、更新或创建。

Slime

网易Slime方案与腾讯云Aeraki方案的思路一致
文档:https://cloudnative.to/blog/netease-slime/
github:https://github.com/slime-io/slime/tree/master/staging/src/slime.io/slime/modules/lazyload

https://cloud.tencent.com/developer/article/1922778

https://www.zhaohuabing.com/post/2018-09-25-istio-traffic-management-impl-intro/文章来源地址https://www.toymoban.com/news/detail-688016.html

到了这里,关于大规模场景下对Istio的性能优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • FLINK 在蚂蚁大规模金融场景的平台建设

    摘要:本文整理自蚂蚁集团高级技术专家、蚂蚁集团流计算平台负责人李志刚,在 Flink Forward Asia 2022 平台建设专场的分享。本篇内容主要分为四个部分: 主要挑战 架构方案 核心技术介绍 未来规划 点击查看直播回放和演讲 PPT 1.1 金融场景业务特点介绍 第一部分是时效性。金

    2023年04月21日
    浏览(40)
  • 大规模数据量下ES如何实现高性能检索?

    ElasticSearch,是基于Lucene库的搜索引擎。它提供了一个分布式、多租户的全文搜索引擎,具有HTTP web接口和无模式JSON文档。根据DB引擎排名,Elasticsearch是最受欢迎的企业搜索引擎。ES的特点是分布式、高扩展以及近实时。那么,大规模数据量下ES是如何实现高性能检索的呢? 说

    2024年02月16日
    浏览(105)
  • 客户案例:高性能、大规模、高可靠的AIGC承载网络

    客户是一家AIGC领域的公司,他们通过构建一套完整的内容生产系统,革新内容创作过程,让用户以更低成本完成内容创作。 RoCE的计算网络 RoCE存储网络 1.不少于600端口200G以太网接入端口,未来可扩容至至少1280端口 1.不少于100端口200G以太网接入端口,未来可扩容至至少240端

    2024年02月11日
    浏览(58)
  • Redis 分区:构建高性能、高可用的大规模数据存储解决方案

    在 Redis 中,分区是一种将数据分布在多个实例上的技术,用于处理大规模数据和提高系统性能。通过分区,可以将数据均匀地分布在多个节点上,从而减轻单个节点的负载压力,并实现水平扩展。 Redis 分区应用场景 1. 大规模数据存储 在 Redis 中,单个实例的内存有限,无法

    2024年04月14日
    浏览(49)
  • 如何通过美国多IP服务器优化大规模在线媒体传输?

    在数字化时代,随着视频内容消费的持续增长,如何有效地传输大规模在线媒体成为了许多企业面临的挑战。美国多IP服务器的配置提供了一种有效的解决方案,不仅可以提高传输效率,还能优化用户体验。通过合理配置和管理美国多IP服务器,可以确保视频内容的高效分发和

    2024年04月27日
    浏览(50)
  • 【AI大数据】大规模数据集处理必备:Apache Mahout介绍、应用及优化

    作者:禅与计算机程序设计

    2024年02月16日
    浏览(55)
  • 开源代码分享(8)—大规模电动汽车时空耦合双层优化调度(附matlab代码)

    参考文献: [1]He L , Yang J , Yan J , et al. A bi-layer optimization based temporal and spatial scheduling for large-scale electric vehicles[J]. Applied Energy, 2016, 168(apr.15):179-192. DOI:10.1016/j.apenergy.2016.01.089         电动汽车(EV)是一种有前景的环保技术,因其减少使用化石燃料的潜力而备受关注。大规

    2024年02月16日
    浏览(36)
  • 大规模参数服务器上的神经网络训练优化——Facebook 研究团队进展报告

    作者:禅与计算机程序设计艺术 随着深度学习在图像、自然语言处理等领域的广泛应用,其模型的规模也越来越大,训练所需要的时间也越来越长。为了加快训练速度,参数服务器(Parameter Server)模式被提出,将神经网络训练过程中的参数分配到多个计算机上,并通过统一

    2024年02月06日
    浏览(44)
  • 华为云云耀云服务器L实例评测|基于华为云云耀云服务器L实例搭建EMQX大规模分布式 MQTT 消息服务器场景体验

    EMQX 是一款国内开发的大规模分布式MQTT消息服务器,它旨在为物联网应用提供高效可靠的连接,实时处理和分发消息以及事件流数据。作为一个关键的物联网基础设施组件,EMQX为企业和开发者提供了一个强大的工具,用于构建各种规模和复杂度的物联网与云应用。 EMQX的主要

    2024年02月08日
    浏览(58)
  • 大规模语言模型--LLaMA 家族

    LLaMA 模型集合由 Meta AI 于 2023 年 2 月推出, 包括四种尺寸(7B 、13B 、30B 和 65B)。由于 LLaMA 的 开放性和有效性, 自从 LLaMA 一经发布, 就受到了研究界和工业界的广泛关注。LLaMA 模型在开放基准的各 种方面都取得了非常出色的表现, 已成为迄今为止最流行的开放语言模型。大

    2024年04月25日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包