Long execution time about kubectl-tree HOT 5 OPEN

thanks, no need to @ since it's my repo and I get notifications about everything

from kubectl-tree.

@ahmetb FYI

from kubectl-tree.

Found out the issue was the bug I introduced in the code. Still it takes time but significantly less:

I0106 15:02:16.109438   53594 query.go:45] all goroutines have returned in 19.125264491s
I0106 15:02:16.109445   53594 query.go:46] query result: error=<nil>, objects=8991

from kubectl-tree.

Increased the burst and qps to 2000 each and increased pagination value to 1000. Still no significant improvement. It went down to 17s.

What I can understand is that the large the cluster the more objects are listed. If I have 10k pods running then it will cause listing of all 10k pods which is definitely going to be slow.

The ideal way would require a change in design st. we start using labels of deployment and other objects to list down the children. Or maybe better if we could directly use field selector with ownerID (Not sure if there is a support for this in client-go).

func (od objectDirectory) ownedBy(id types.UID) []unstructured.Unstructured {
	var out sortedObjects
	for k := range od.ownership[id] { // instead of finding owner here make modification in snippet pasted below
		out = append(out, od.getObject(k))
	}
	sort.Sort(out)
	return out
}

Query api:

func queryAPI(client dynamic.Interface, api apiResource) ([]unstructured.Unstructured, error) {
	var out []unstructured.Unstructured

	var next string
	for {
		resp, err := client.Resource(api.GroupVersionResource()).List(metav1.ListOptions{
			Limit:    1000,
			Continue: next,
// The logic to filter should go here
		})

from kubectl-tree.

Sadly, server side filtering is not possible.

https://stackoverflow.com/questions/59442065/how-to-use-kubernetes-fieldselector-to-query-ownerreferences

The only improvement I can think of is to query resources only in specified namespace (Except nonnamespaced apis) and separately do a --all-namespaces flag for the current behavior.

I am not sure it’s worth fixing just yet. If it effects 1% users and takes only 20s waiting, I don’t want to fix it and change experience for everyone.

from kubectl-tree.