This is great to see. It makes a lot of sense to not build a separate
service mesh but instead be a replacement to Envoy in Istio.
I think this will make Istio much more extensible and will provide a lot
of value to the user if we could build and use custom APISIX Plugins in
the data plane.
Is this the repo for the project: github.com/api7/apisix-mesh-agent
<https://github.com/api7/apisix-mesh-agent> ?
Looking forward to see this in action.
- Navendu
On 11/03/22 5:47 pm, Jintao Zhang wrote:
Background introduction
Service mesh is currently the most popular architectural pattern.
Especially for the microservice architecture, it is very effective. It can
be used to manage east-west traffic, improve security, etc.
Apache APISIX is a cloud-native high-performance API Gateway that can also
be used to manage north-south and east-west traffic.
However, if the deployment scenario is limited to the Kubernetes cluster,
we will find that the service mesh solution is more natural and flexible.
So I want to *bring Apache APISIX to the service mesh world*.
There are already multiple solutions for service meshes, and there is not
much value in implementing a completely new solution.
I would like to choose Istio[1], the most popular service mesh solution, as
the control plane.
Uses Apache APISIX as its data plane[2].
*Value*
This will generate a lot of value.
For APISIX *Community*
Introducing Apache APISIX to the service mesh world allows it to have more
use cases, especially in east-west traffic management, security, and
observability.
Integrating with Istio is also easier to adopt.
For Istio *Community*
It can enrich the ecology of Istio. Currently, the default data plane of
Istio is Envoy[3], but the learning cost of Envoy is high, and it is more
complicated to expand and maintain it.
In addition, we have done a comparison, APISIX's performance is better than
Envoy.
APISIX and Istio integration, allowing users to have more choices.
For end-user
We choose Istio as the control plane and only replace the data plane, so it
is insensitive to user migration. Of course, we will also conduct
compatibility testing to make this process more secure and reliable.
Architecture design
```
|Control-plane--------------------+
| |
| |
| Istio |
| |
+----------------+----------------+
|
|
+-------------------------+-----------------------+
| Discovery |
| Configuration |
| Certificates |
| |
| |
+-------------v------------------+
+------------------v-------------+
| | |
|
| +----------------------------+ | |
+----------------------------+ |
| | | | | |
| |
| | +--------------+---------+ | | | |
+--------------+---------+ | |
Ingress | | | | | | | | | |
| | | | Egress
--------------+-> | | Amesh | +-+-----------+-> |
| Amesh | +-+-------------->
Traffic | | | +---------+ | | | | |
+---------+ | | Traffic
| | |APISIX | | | | | |APISIX
| | |
| | +------------------------+ | | | |
+------------------------+ | |
| | | | | |
| |
| +-----+--------------^-------+ | |
+-----+---------------^------+ |
| | | | | |
| |
| +-----v--------------+-------+ | |
+-----v---------------+------+ |
| | Service A | | | |
Service B | |
| | | | | |
| |
| +----------------------------+ | |
+----------------------------+ |
| | |
|
+--------------------------------+
+--------------------------------+
```
concept:
- Amesh： It is a Go program that interacts with Istio for the xDS
protocol. Will be compiled into a .so file and embedded in APISIX. And the
configuration will be written directly to the shdict of APISIX.
- APISIX: It will read configuration from shdict and no longer need to
rely on storage like etcd.
*Deliverables*
When this goal is achieved, we can deliver the following two parts
Amesh
As mentioned above, this is a Go program that will do the mapping of Istio
functionality and APISIX configuration
APISIX
APISIX will modify how the configuration is read. Allows getting
configuration information from shdict.
*Development Roadmap*
TBD
