emissary
emissary copied to clipboard
emissary-ingress
Ambassador needs to ignore no-op "changes" to Kubernetes resources
A user recently ran into a situation where his Kubernetes Ingress resources were changing every few seconds, triggering an Ambassador reconfiguration even though the Ambassador installation wasn't using Ingress resources for its configuration, and even though (as I understand it) the changes to the resources weren't anything that Ambassador should've needed to care about even if Ambassador were supposed to be paying attention to Ingress resources.
Ambassador should filter out immaterial changes in watt, so that the more expensive reconfiguration doesn't need to happen at all.
Hullo, just wanted to :+1: this issue - we find that when performing a deployment in kubernetes the number of resource changes seems to occasionally trigger our ambassador deployments to significantly increase their CPU utilisation.
This is particularly bad for internal clusters where your CI pipeline may be running in the same cluster as your ambassador deployments: the CPU utilisation of ambassador can degrade the speed of your pipeline, causing it to take longer to update kubernetes resources, causing ambassador to be confused & high-CPU for longer, causing the pipeline to take longer, etc.
Do you have a sense of the time scales for this issue, and, is there anything I could do to assist? Might be able to provide information, or be able to spend time investigating the issue to create a PR (though I've never worked on this code base, so mileage may vary :smile:)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
not sure if the ~recent fast reconfig support takes care of this/makes this a non-issue.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This still happens on legacy mode, which we are currently stuck on due to issues with Consul 1.10.
