kumahq / kuma

🐻 The multi-zone service mesh for containers, Kubernetes and VMs. Built with Envoy. CNCF Sandbox Project.
https://kuma.io/install
Apache License 2.0
3.55k stars 326 forks source link

In Global Control Plane, the AdvertisedAddress and the AdvertisedPort is wiped off when Workload is created in corresponding Zone #10738

Open manju-rn opened 6 days ago

manju-rn commented 6 days ago

What happened?

Setup:

  1. Cluster with Zone Control plane, Gateway and a HttpRoute resource
  2. Cluster with Global Control Plane to which Zone is connected. The ZoneIngress in the GUI is visible and AdvertisedAddress & AdvertisedPort of the zone cluster is manually updated
  3. If in the cluster of the zone control, if I delete Workload and corresponding HttpRoute and recreate it, the AdvertisedAddress & AdvertisedPort in Global Control plane vanishes!

Step 1: Workload and HttpRoute is available in the zone control plane and the AdvertisedAddress & AdvertisedPort is available image Step 2: Remove the workload recreate the workload in the zone control plane,

manju@k1:~/adminer$ ls
adminer_all.yaml  adminer_http_route.yaml
manju@k1:~/adminer$ k apply -f adminer_all.yaml
service/adminer-svc created
deployment.apps/adminer-app created

Step 3: Check the GUI in the Global Control plane, the AdvertisedAddress & AdvertisedPort is missing in the ZoneIngress image

michaelbeaumont commented 6 days ago

Hi, can you post the resources you applied? Can you also check the control plane logs for any errors or warnings?

manju-rn commented 5 days ago

Okay i found the solution. I think we need to update the docs based on this. Legend:

Interestingly, if I change the advertisedAddress and advertisedPort of ZoneIngress via gk, and if in k1 / k2, the workloads are refreshed / workloads added /deleted, then the advertisedAddress and advertisedPort vanish (as my original post).

However, if I update the advertisedAddress and advertisedPort of ZoneIngress in the respective cluster (k1 / k2), than these values stay put regardless of any workloads change.

I think it might have to do how Global Control Plane sync the zone ingress instances from Zone Control Plane. like: in gk, the ZoneIngress are like below

manju@gk:~$ k -n kuma-system get zoneingress
NAME                                             ZONE
kuma-ingress-564c8f5954-4n22c-z859dvcx86v9zxcc   k1

in k1, the ZoneIngress is like:

manju@k1:~$ k -n kuma-system get zoneingress
NAME                                             ZONE
kuma-ingress-564c8f5954-4n22c

So when editing the ZoneIngress in gk (for advertisedAddress and advertisedPort ), I was probably changing only the instance value kuma-ingress-564c8f5954-4n22c-z859dvcx86v9zxcc and not actual resource itself which is in k1 kuma-ingress-564c8f5954-4n22c. Hence the ZoneIngress values must not be changed via gk (Global CP), but directly on k1 /k2 (Zone CP) Am i correct in my analysis?