-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
k8s ingress & gateway api: fix unintentional deletion of shared envoy cluster resource #28896
k8s ingress & gateway api: fix unintentional deletion of shared envoy cluster resource #28896
Conversation
/test |
ce19e9a
to
eaab947
Compare
/ci-gateway-api |
Currently, the Clusters resources in the CiliumEnvoyConfig aren't qualified with the namespace and name of the CEC itself. This leads to issues when updating the CiliumEnvoyConfigs due to changes in the K8s Ingress & Gateway API resources. If multiple resources are referencing the same K8s Service, the Cluster resource gets deleted if one of these K8s Ingress or Gateway resources gets deleted - and therefore breaks the other resources. With this commit, the name of the Cluster resource and their references gets qualified like the rest of the resources. For the EDS lookup of the endpoint addresses, the field `service_name` of the Cluster is used. Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com>
eaab947
to
d51730c
Compare
/test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change on ciliumenvoyconfig.go
is great, I had similar support for TcpProxy cluster name qualification also in my development branch.
Correct me if I'm wrong, but the EDSClusterConfig.ServiceName
allows clusters with different names to be associated with endpoints/backends that have a ClusterName
field matching the ServiceName
, and that's why there is no change in the way the service backends are synced to Envoy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have similar question like above.
The changes look good in general.
Exactly. Until now we had a 1:1 relationship between Envoy Clusters and the Endpoints. The default Endpoint lookup happens with the name of the cluster itself. By using the This way garbage collection is way easier - without the need to count references. |
This also didn't apply cleanly on v1.14, marking "backport/author" |
Currently, the Envoy
Cluster
resources in theCiliumEnvoyConfig
aren't qualified with the namespace and name of theCiliumEnvoyConfig
itself.This leads to issues when updating a
CiliumEnvoyConfig
due to changes in the K8s Ingress & Gateway API resources. If multiple resources are referencing the same K8s Service, the Cluster resource gets deleted if one of these K8s Ingress or Gateway resources gets deleted - and therefore breaks the other resources.With this PR, the name of the Cluster resource and their references gets qualified like the rest of the resources. For the EDS lookup of the endpoint addresses, the field
service_name
of the Cluster is used. (Currently an implicit 1:1 mapping of the names -> clusters name is used for the lookup)See Envoy Docs for further information about the property
service_name
: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/cluster/v3/cluster.proto#config-cluster-v3-cluster-edsclusterconfig