Open christiancadieux opened 2 weeks ago
seeing field is immutable
in the logs, so this is same as https://github.com/envoyproxy/gateway/issues/1818
I don't think it's the same but it's related. for example with Services, it's important to update the labels of the service and not delete/re-create the service since re-creating would assign a new external-IP to the service, which is not good. Also, when labels come from the Gateway infrastructure, they could be important labels related to the ownership (tenant) of the Gateway for example, and it's important that the envoy-proxy pod and the service be updated.
i'll bring this up in the community meeting tomorrow, the issue is the same - should Envoy Gateway recreate resources when it hits this specific error field is immutable
by default , or should it be based on an opt in flag
no need to re-create resources to update labels. It is possible to update labels with PATCH:
$ kubectl label service/envoy-tenant1-ns1-envoy-gateway-d016235c infra1-label=infra1-test123 --overwrite -v6
I0624 15:46:02.121803 1444301 loader.go:395] Config loaded from file: /home/ccadie883/.kube/config
I0624 15:46:02.504242 1444301 round_trippers.go:553] GET https://10.112.182.142:6443/api/v1/namespaces/tenant1-eg/services/envoy-tenant1-ns1-envoy-gateway-d016235c 200 OK in 376 milliseconds
I0624 15:46:02.630137 1444301 round_trippers.go:553] PATCH https://10.112.182.142:6443/api/v1/namespaces/tenant1-eg/services/envoy-tenant1-ns1-envoy-gateway-d016235c?fieldManager=kubectl-label 200 OK in 124 milliseconds
service/envoy-tenant1-ns1-envoy-gateway-d016235c labeled
$ kubectl get service --show-labels
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE LABELS
envoy-gateway ClusterIP 192.168.235.139 <none> 18000/TCP,18001/TCP,19001/TCP 4h18m app.kubernetes.io/instance=eg-tenant1,app.kubernetes.io/managed-by=Helm,app.kubernetes.io/name=gateway-helm,app.kubernetes.io/version=v1.0.1,control-plane=envoy-gateway,helm.sh/chart=gateway-helm-v1.0.1
envoy-tenant1-ns1-envoy-gateway-d016235c LoadBalancer 192.168.254.13 10.112.182.62 8080:9153/TCP 4h10m app.kubernetes.io/component=proxy,app.kubernetes.io/managed-by=envoy-gateway,app.kubernetes.io/name=envoy,gateway.envoyproxy.io/owning-gateway-name=envoy-gateway,gateway.envoyproxy.io/owning-gateway-namespace=tenant1-ns1,infra1-label=infra1-test123
or pod:
$kubectl label pod/envoy-tenant1-ns1-envoy-gateway-d016235c-6979c4cbf5-grrgl infra1-label=infra1-test123 --overwrite -v6
I0624 15:47:13.898528 1444420 loader.go:395] Config loaded from file: /home/ccadie883/.kube/config
I0624 15:47:14.284137 1444420 round_trippers.go:553] GET https://10.112.182.142:6443/api/v1/namespaces/tenant1-eg/pods/envoy-tenant1-ns1-envoy-gateway-d016235c-6979c4cbf5-grrgl 200 OK in 380 milliseconds
I0624 15:47:14.547887 1444420 round_trippers.go:553] PATCH https://10.112.182.142:6443/api/v1/namespaces/tenant1-eg/pods/envoy-tenant1-ns1-envoy-gateway-d016235c-6979c4cbf5-grrgl?fieldManager=kubectl-label 200 OK in 138 milliseconds
pod/envoy-tenant1-ns1-envoy-gateway-d016235c-6979c4cbf5-grrgl labeled
$kubectl get pod envoy-tenant1-ns1-envoy-gateway-d016235c-6979c4cbf5-grrgl --show-labels
NAME READY STATUS RESTARTS AGE LABELS
envoy-tenant1-ns1-envoy-gateway-d016235c-6979c4cbf5-grrgl 2/2 Running 0 4h11m app.kubernetes.io/component=proxy,app.kubernetes.io/managed-by=envoy-gateway,app.kubernetes.io/name=envoy,gateway.envoyproxy.io/owning-gateway-name=envoy-gateway,gateway.envoyproxy.io/owning-gateway-namespace=tenant1-ns1,infra1-label=infra1-test123,pod-template-hash=6979c4cbf5
-1 to recreation. As stated, there are many possible side effects, including IP change, disruption to traffic, etc. If possible to solve this with a different strategy (e.g. patch), that should be fine.
hey @sanposhiho can you help with this one if you have a cycle ?
can we make the Patch API https://github.com/envoyproxy/gateway/blob/9a2a7f607e1db52d7aa22daa4c22749cadbf3a91/internal/infrastructure/kubernetes/infra_client.go#L29C24-L29C66 behave like kubectl --overwrite
so it doesnt throw an error of field is immutable
when updating labels, and also does this w/o recreating the pod or service
/assign
I'll take a look.
Had a bit of time checking this issue.
According to the provided logs, looks like it doesn't get a conflict at labels, but get conflicted at deployment's selector. If we fail at updating deployment here, we don't update other following resources, which is why your service isn't updated. https://github.com/envoyproxy/gateway/blob/main/internal/infrastructure/kubernetes/infra.go#L72-L87
So, I believe this issue is the same as https://github.com/envoyproxy/gateway/issues/1818, as @arkodg mentioned first.
Description: Changes to Gateway infrastructure labels do not propagate to the service and pods
Repro steps:
Note: maybe related to other 'immutable' bugs like https://github.com/envoyproxy/gateway/issues/1818 Deleting the Gateway does delete the envoy-proxy deployment
Environment:
Gateway
PODS
Logs: the logs when the gateway labels are updated: