You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's necessarily true that each invocation of our tool only needs one of the clusters/contexts/users in the kubeconfig. If we constructed a tempfile containing only the information we actually need we could eliminate the sharing of this dependency between invocations (which is aesthetically nice--we don't mutate it of course!), guarantee we could only be using the right context, and reduce the size of the file kubectl repeatedly loads (see below).
For performance?
tl;dr Unlikely to help Shopify, unsure if it would help others
Last year, I did a bit of performance work on this gem using a watch command I didn't end up merging. One thing I found out was that kubectl get itself was a major contributor to sync cycle slowness at the time. I also discovered that kubectl versions < 1.14 have a bug where the kubeconfig is loaded repeatedly, which reported has severe performance implications if the file is large and/or the cluster has large numbers of resources. The maintainers refused to backport the fix. The number of times it is reloaded apparently scales up with the number of resources being retrieved, which we can't do much about. However, reducing the file size also helps, according the the bug report, and we do have control over that.
I believe I confirmed that we were affected at the time, but it was a long time ago and fell off my mental radar until recently. Today, on a Shipit instance (because a comment on the bug report suggests it may only affect linux), I did a get pods targeting one of our most populated clusters, and it only loaded the kubeconfig 4 times. So no quick win for us after all. It might still help others though.
The text was updated successfully, but these errors were encountered:
Idea
It's necessarily true that each invocation of our tool only needs one of the clusters/contexts/users in the kubeconfig. If we constructed a tempfile containing only the information we actually need we could eliminate the sharing of this dependency between invocations (which is aesthetically nice--we don't mutate it of course!), guarantee we could only be using the right context, and reduce the size of the file kubectl repeatedly loads (see below).
For performance?
tl;dr Unlikely to help Shopify, unsure if it would help others
Last year, I did a bit of performance work on this gem using a
watch
command I didn't end up merging. One thing I found out was thatkubectl get
itself was a major contributor to sync cycle slowness at the time. I also discovered that kubectl versions < 1.14 have a bug where the kubeconfig is loaded repeatedly, which reported has severe performance implications if the file is large and/or the cluster has large numbers of resources. The maintainers refused to backport the fix. The number of times it is reloaded apparently scales up with the number of resources being retrieved, which we can't do much about. However, reducing the file size also helps, according the the bug report, and we do have control over that.I believe I confirmed that we were affected at the time, but it was a long time ago and fell off my mental radar until recently. Today, on a Shipit instance (because a comment on the bug report suggests it may only affect linux), I did a
get pods
targeting one of our most populated clusters, and it only loaded the kubeconfig 4 times. So no quick win for us after all. It might still help others though.The text was updated successfully, but these errors were encountered: