Repository navigation
[Feature]: Support tolerations in K8sGPT spec and operator deployment #767
Description
Activity
Valid feature request! Tolerations support is a standard Kubernetes pod placement feature that should be available alongside nodeSelector.
Supporting as a feature.
Implementation needed:
-
Operator Helm chart (
values.yaml):tolerations: [] # Allow users to specify tolerations for operator pods
-
K8sGPT CRD spec:
apiVersion: core.k8sgpt.ai/v1alpha1 kind: K8sGPT spec: tolerations: [] # Pass tolerations to k8sgpt analysis pods
-
Operator deployment template: Apply tolerations from values.yaml
-
K8sGPT controller: Pass tolerations from spec to k8sgpt pods
Use cases:
- Running on GPU-tainted nodes for AI workloads
- Dedicated analysis nodes with custom taints
- Mixed workload clusters with isolation requirements
This is a straightforward addition that improves flexibility without drawbacks. Should be relatively easy to implement by following the existing nodeSelector pattern.
-
Hi, I’m interested in the Kubernetes ecosystem. Is anyone working on this issue? If not, could I give it a try?
Checking whether toleration support is still needed for your operator deployment. If it is, a focused PR that threads
tolerationsthrough the chart values and rendered workload, with a Helm template test, would be a reviewable first step.Thanks for offering to help. This is still a useful, bounded contribution. Please take the focused path through chart values, the rendered operator workload, and the K8sGPT-managed workload, with a Helm template test proving a toleration survives each path.
Keep the field aligned with Kubernetes
[]corev1.Tolerationsemantics rather than inventing a chart-only shape, and link the PR here when ready.I'm interested in working on this issue. Could you please clarify if the tolerations field should be added to both the operator and the K8sGPT CRD? Looking at the values.yaml, there's already a nodeSelector under controllerManager. Should we follow the same pattern for tolerations? Also, should we add tolerations to the pod template as well? Any guidance on the expected structure would be helpful.
Sorry for the slow reply @CJstate, and thanks for offering. To answer your questions: yes to all three. Tolerations belong on the
K8sGPTCRD (copied into the managed K8sGPT Deployment's pod template) and on the operator chart ascontrollerManager.tolerations, following the existingnodeSelectorpattern, using the standard[]corev1.Tolerationshape.Heads-up though: @preko-p already opened #820 with exactly that shape (CRD
spec.tolerations, propagation inpkg/resources/k8sgpt.go, chart values and template, plus tests). It has fallen behindmainand now has conflicts. So rather than starting a second PR, the most useful thing would be to check with @preko-p on #820 whether they plan to rebase it, and to review or test it if you can. If they've moved on, a rebased version of that PR with credit is the quickest route.Thanks @AlexsJones — that mapped exactly onto what I found when I looked at #820.
I reviewed and rebuilt it:
go build ./...andgo vet ./...are clean, the newpkg/resourcesscheduling-constraints test passes, andhelm templateshows the toleration landing on the controller-manager pod whencontrollerManager.tolerationsis set (and notolerationskey at all when it is left at[]). The details are in my comment on #820.Rebasing onto
mainconflicts only inchart/operator/crds/k8sgpt-crd.yaml. I resolved it and regenerated both CRD copies with the pinnedcontroller-gen v0.21.0rather than re-inserting the block by hand, so the schema sits in generated (alphabetical) order and the chart copy is byte-identical to the generated file. I opened that as #855, with @preko-p credited as the commit author. Per what you suggested, I asked on #820 first and said I would close #855 immediately if they would rather finish it there — their branch has been stale since June and they have not been active on GitHub since 2026-06-09.Two notes: #855 will need an EasyCLA signature on my side (the bot will say so), and locally I cannot run the two envtest suites (
internal/controller/k8sgpt,internal/controller/mutation) because the kubebuilder assets are not installed here — they fail identically on unmodifiedmain, so CI is the real check for those.- added 2 commits that reference this issue
on Oct 3, 2026 Thanks @CJstate, carrying #820 forward with @preko-p credited and asking on their PR first is exactly the right way to do this.
I've reviewed #855 and left notes there. The only open question on our side is which of #820 and #855 lands, and since #820 has had no response since June, that's with the maintainers now. EasyCLA still needs your signature on #855 either way.
Checklist
Is this feature request related to a problem?
None
Problem Description
The operator helm chart and K8sGPT CRD currently supports
nodeSelectorfor pod placement but lackstolerationssupport. This prevents the operator and K8sGPT pods from being scheduled on tainted nodes.Solution Description
Add a
tolerationsfield to the operator chart and K8sGPT spec that accepts an array of toleration objects (following standard Kubernetes toleration structure), similar to how nodeSelector is currently implemented.Benefits
Enables both K8sGPT pods and operator deployment on tainted nodes (GPU nodes, dedicated workload nodes, etc.)
Potential Drawbacks
No response
Additional Information
No response