共计 1617 个字符，预计需要花费 5 分钟才能阅读完成。
摘要
KubeOrbit 是一款云原生利用的微服务集成测试工具。本篇文章将从其技术实现的角度，为大家介绍波及到的技术及设计逻辑，帮忙大家了解这个开源产品，也期待将来有更多开发力量的退出。
1 背景介绍
上图是 Red Hat 提供的一张服务网格数据立体的构图，绿色局部是理论的应用程序，蓝色局部便是网络代理，这在服务网格中被称为 Sidecar，Sidecar 利用与应用程序共享雷同的生命周期，与应用程序一起创立和退出。
云原生技术倒退至今，服务网格曾经被大量企业施行落地，通过接管分布式服务的通信层流量，胜利让许多企业团队开箱即可取得负载平衡、服务发现、认证受权、监控追踪、流量管制等分布式系统所须要的性能。然而目前仅通过服务网格无奈实现高效的微服务多环境测试，KubeOrbit 即是解决这类场景设计出的。
KubeOrbit 是一个 Kubernetes Operator，提供逻辑环境隔离的计划，同时借助现成的流量治理基础设施层以低成本的形式帮忙用户解决测试环境治理的痛点。
2 技术实现
2.1 KubeOrbit 概念介绍
KubeOrbit 次要的能力是通过创立逻辑隔离环境的形式，基于 Kubernetes 定制的资源对象，将其下发至各种服务网格的数据立体，建设起带标识的调用链路，达到按需增量扩大测试和联调环境的需要，外围组件展现如下：
2.2 Orbit
Orbit 对象代表一个残缺的，独自的一套逻辑隔离环境，通过形容 provider 抉择集群中的（或者部署新的）服务网格。以 Istio 实现为例，Spec 中定义的配置会转化成相应的 Istio CRD，通过生成 Outbound Filter 为隔离环境中带标识的工作负载实现标识传递。
2.3 ServiceRoute
ServiceRoute 的作用次要是：定义具体的服务路由被转发的策略，如转发到哪些正本，默认的转发策略，以及通过何种流量标识转发。这里还是以 Istio 实现举例，Spec 中定义的路由策略会转化成 Istio VirtualService 和 DestinationRule，来反对不同正本的流量转发。
2.4 流量门路
实现 CRD 的创立后，流量即可按规定路由至环境中携带流量标识的工作负载，以入口为微服务网关为例，东西向的流量调度示意如下：
2.5 染色透传
如果在流量源头将申请染色，那么申请通过网关时，网关作为代理会将申请一成不变的转发给入口服务。紧接着，申请流量会从入口服务开始调用下一个微服务，会依据业务逻辑造成新的调用申请。那么咱们如何将流量标识增加到这个新的调用申请，从而能够在链路中传递上来呢？现在的微服务之间调用是从本地过程的服务调用远端过程中的服务，并且远端服务可能以多正本容器模式部署，以至于一条申请流经的节点是不可预知的、不确定的，这对于通明代理 Sidecar 来说想通过不侵入的形式接管更是无能为力，KubeOrbit 以后版本中的流量标识可能在链路中始终传递上来，须要依赖 Trace 计划中的自定义信息性能，将来会对接常见的 Skywalking、OpenTelemetry、Zipkin 等社区计划。
3 瞻望
下一步 KubeOrbit 将持续迭代外围性能，扩大利用场景，次要会有以下几个局部：
- 支流微服务注册核心反对
- 常见 Layer-7 协定反对
- CLI 工具
目前，KubeOrbit 已凋谢全副代码，欢送各位开发者敌人退出，一起探讨。
GitHub 地址：https://github.com/teamcode-inc/kubeorbit
同时，任何疑难或想法，也欢送通过 Discord 频道及时与咱们反馈和交换。
Discord 频道: https://discord.gg/5XaTS9VArf
关注咱们
公众号|知乎：TeamCode
微博：TeamCode 官博
理解更多
KubeOrbit 官网：http://www.kubeorbit.io
TeamCode 官网：http://www.teamcode.com
简历投递：hr@teamcode.com