younsl opened a new pull request, #441: URL: https://github.com/apache/superset-kubernetes-operator/pull/441
## Summary The controller registered Owns on corev1 Pod, but the operator never creates Pods itself. Component pods are owned by ReplicaSets and lifecycle task pods by Jobs, so this watch never queued a reconcile. It still started a Pod informer that cached every Pod the operator could see, which in a cluster scoped install means every Pod in the cluster, inside a manager with a 128 MiB memory limit by default. This PR removes the unused Pod watch and limits the Pod informer to pods that carry the superset.apache.org/parent label, so operator memory no longer grows with unrelated workloads. ## Details - The Pod watch is removed from SetupWithManager. It never fired because no Pod is controller owned by a Superset. - The manager cache now uses a ByObject label selector for Pods: superset.apache.org/parent must exist. Other kinds are unchanged. - All three Pod reads already select on labels that only operator managed pods carry: drain (parent label), maintenance page readiness (parent label), and task pod startup errors (instance label, and task pods also carry the parent label). They see the same pods as before. - The parent label has been on every component, maintenance page and task pod since the first commit, so pods created by older operator versions stay visible after an upgrade. - No RBAC, CRD, chart or docs change. The operator still needs list and watch on pods. - New unit test in cmd checks the selector keeps component and task pods and drops unrelated ones. One thing to keep in mind for future code: a Pod list that does not select on the parent label would now silently return nothing from the cache. The cacheOptions doc comment calls this out. <details> <summary>Memory measurement on Kind</summary> GRAPH_PLACEHOLDER Setup: Kind v1.37.0 node image, operator installed from the chart (cluster scoped, 128 MiB limit), images built from main and from this branch. Noise: a Deployment with 2,000 replicas in an unrelated namespace, pinned to a missing node label so the pods stay Pending, each with a 3 KB annotation. Each image was restarted and left for 90 seconds before sampling. RSS comes from /proc on the node and is the median of 6 samples taken 10 seconds apart. Peak is cgroup memory.peak. | Image | Unrelated pods | RSS (MiB) | cgroup peak (MiB) | |---|---|---|---| | main | 0 | 18.2 | 64.9 | | this PR | 0 | 19.5 | 65.5 | | main | 2,000 | 51.4, 43.0 | 86.6, 93.9 | | this PR | 2,000 | 18.6, 15.3 | 68.5, 65.6 | With main, steady RSS grows by about 15 KiB per unrelated pod in this setup. Real pods are usually larger (status, managedFields), so the growth on a busy cluster is likely higher. With this PR, RSS stays at the no noise baseline. </details> <details> <summary>Functional check on Kind</summary> Ran with this branch's image and a Development mode Superset with webServer, celeryWorker and celeryBeat, backed by the dev dependencies sample. - Initial install: lifecycle Complete, 3/3 components ready. - Changed spec.image.tag to trigger an upgrade. Phases went Draining, Migrating, Initializing, Restoring, Complete. Draining took about 45 seconds while the operator waited for the old component pods to terminate, which shows the drain pod count still sees component pods through the scoped cache. - The first upgrade attempt pointed at a tag the node could not pull. The operator surfaced the migrate pod's ImagePullBackOff in status.lifecycle.migrate.message, which shows the task pod lookup still works. After the image was made available, the upgrade finished and the Superset returned to Available. - make test-unit and make lint-go pass. </details> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
