search

kmesh-net / kmesh

High Performance ServiceMesh Data Plane Based on Programmable Kernel
https://kmesh.net
Apache License 2.0
405 stars 54 forks source link

Support label or annotate the pod to indicate that Kmesh is in charge of traffic management. #86

Open nlgwcy opened 8 months ago

nlgwcy commented 8 months ago

What would you like to be added: Support label or annotate the pod to indicate that Kmesh is in charge of traffic management.

Why is this needed: Kmesh supports collaborating with existing mesh data plane. Consider the following scenario: a namespace has already been injected with a sidecar, and then the Kmesh data plane is injected into this namespace.

According to the design, existing pods in the namespace will continue to have their traffic governed by the sidecar. However, the traffic of new pods created in the namespace will be taken over by Kmesh, although a new pod will still have a sidecar created, as shown in the diagram. image

In this situation, there needs to be a method to inform the operations team which pods' traffic is being managed by Kmesh; otherwise, confusion may arise.

hzxuzhonghu commented 8 months ago

@YaoZengzeng What's the behavior of ambient vs sidecar?

YaoZengzeng commented 8 months ago

Please ref: https://istio.io/latest/docs/ops/ambient/usage/ztunnel/

1704786580663

Of course it's not recommanded to have a ns or a pod both labeled with ambient and sidecar, but if it happend, always sidecar first, sidecar always should be in charge of traffic, according to reference above.

So it should be same for kmesh.

However, the traffic of new pods created in the namespace will be taken over by Kmesh, although a new pod will still have a sidecar created, as shown in the diagram.

So we should create sidecar and let sidecar manage the traffic in this situation @hzxuzhonghu @nlgwcy WDYT?.

hzxuzhonghu commented 8 months ago

Agree with that sidecar takes precedence.

nlgwcy commented 8 months ago
  1. sidecar takes precedence: For a namespace, if sidecar is already enabled, even if Kmesh is also enabled in that namespace, traffic will still be handled by the sidecar.
  2. Adding Kmesh label to Pod: After enabling Kmesh for a namespace, newly created Pod traffic will be taken over by Kmesh, while existing Pod traffic will not be taken over by Kmesh. For Pods taken over by Kmesh, they need to be labeled to explicitly indicate the state of traffic takeover, facilitating operations and maintenance. @bitcoffeeiux