- Background
The above picture is a structure diagram of a service mesh data plane provided by Red Hat. The green part is the actual application, and the other part is the network agent, which is called Sidecar in the service mesh. Sidecar applications share the same lifecycle with other applications: they can be created and exited with other applications.
The development of cloud native technology enables the implementation of service grids by numerous organizations. Many of them have obtained the functions of load balancing, service discovery, certificate authority, tracking and monitoring, flow control, etc. Currently, they are merely implemented through service grids, but it is impossible to do multi-environment testing efficiently, hence, we designed and developed KubeOrbit to meet the needs of these scenarios.
KubeOrbit is a Kubernetes Operator that provides a solution for logical environment isolation, and at the same time utilizes ready-made traffic governance methods to help users solve the pain points of the test environment at a low cost.
- Technology Implementation
2.1 Basic Information about KubeOrbit
The main capability of KubeOrbit is to create a logically isolated environment, based on Kubernetes-customized resource objects, delivering them to the data plane of various service meshes, establishing tracing with labels to meet the requirements of the scalability and integration test environment. The core components are shown as follows:
2.2 Introduction of Orbit
An Orbit object represents a complete, single set of logically isolated environments, by describing providers to select (or deploy new) service meshes in a cluster. Taking the Istio implementation as an example, the configuration defined in the Spec will be converted into the corresponding Istio CRD, and the outbound filter will be generated to realize the identity transfer for the workload with the identity in the isolation environment.
2.3 What is ServiceRoute
The role of ServiceRoute is mainly to define the strategy for specific service routes to be forwarded, such as which replicas to forward to, the default forwarding strategy, and which traffic identifier to forward through. Taking Istio as an example, the routing strategy defined in Spec will be converted into Istio VirtualService and DestinationRule to support traffic forwarding between different replicas.
2.4 Traffic Route
After the creation of the CRD, the traffic can be routed to the workload carrying the traffic identifier in the environment according to rules. Taking the example of microservice gateway as the entrance, the east-west traffic scheduling is shown as follows:
2.5 Header Propagation
If the request is identified at the traffic source, the gateway will forward the request to the inbound services. Next, the requested traffic will invoke the next microservice from the inbound service, and a new request will be generated based on the business logic. So how do we add the traffic identifier to this new request so that it can be passed down the traces? Nowadays, microservices are invoked from local processes to remote processes. And remote services may also be deployed in the form of multi-copy containers, resulting in an unpredictable and uncertain node through which a request flows. This renders the transparent proxy Sidecar even more powerless.
The traffic identification in the current version of KubeOrbit can be transmitted all the time in trances. This requires the customized information function in the Trace solution. In the future, it will be connected to the common Skywalking, OpenTelemetry, Zipkin and other community solutions.
3 Future outlooks
In the near future, we will continue to iterate on core functions and expand the application scenarios, which mainly includes the following parts:
- Support the mainstream microservice registry
- Support most Layer-7 protocols
- CLI tools
Top comments (0)