feat: add tolerations support

[CJstate]

Summary

Adds scheduling tolerations at both levels asked for in #767:

• spec.tolerations ([]corev1.Toleration) on the K8sGPT CRD, copied into the managed K8sGPT Deployment pod template in GetDeployment.
• controllerManager.tolerations on the operator Helm chart, rendered into the controller-manager pod template, following the existing nodeSelector pattern.

Fixes #767.

This is @preko-p's change from #820, rebased onto main. @AlexsJones reviewed #820 and found the change complete ("the whole checklist"); the only blockers left there were the stale branch and EasyCLA. Rather than writing a second implementation I carried #820 forward:

• the conflict in chart/operator/crds/k8sgpt-crd.yaml is resolved,
• both CRD copies are regenerated with the pinned controller-gen v0.21.0 (make manifests) instead of hand-edited, so the tolerations schema matches the rest of the generated file and the chart copy is byte-identical to the generated one,
• zz_generated.deepcopy.go is unchanged on regeneration (make generate is a no-op on top of it),
• the trailing-whitespace noise feat: add tolerations support #820 had at the end of chart/operator/README.md is dropped.

@preko-p is credited as the commit author. I asked on #820 first whether they plan to rebase it (comment); given the branch has been stale since June and they have not been active on GitHub since 2026-06-09, I went ahead per @AlexsJones's suggestion in #767 — and I'll close this PR immediately if @preko-p would rather finish it on #820.

Because this branch also lands a commit under my name, the EasyCLA check will need a signature from me; I'll sort that out as soon as a maintainer wants to take this forward.

Tests

Unit test in pkg/resources:

$ go test ./pkg/resources/... -run Test_GetDeploymentWithSchedulingConstraints -v -count=1
=== RUN   Test_GetDeploymentWithSchedulingConstraints
--- PASS: Test_GetDeploymentWithSchedulingConstraints (0.00s)
PASS
ok  	github.com/k8sgpt-ai/k8sgpt-operator/pkg/resources	0.155s

Helm rendering — with controllerManager.tolerations set, the toleration reaches the controller-manager pod template:

$ helm template t chart/operator \
    --set controllerManager.tolerations[0].key=dedicated \
    --set controllerManager.tolerations[0].operator=Equal \
    --set controllerManager.tolerations[0].value=ai \
    --set controllerManager.tolerations[0].effect=NoSchedule
      tolerations:
        - effect: NoSchedule
          key: dedicated
          operator: Equal
          value: ai

With the default tolerations: [] the chart renders no tolerations key at all, the same {{- if }} guard behaviour as nodeSelector.

Build, vet and manifest generation:

$ go build ./...            # exit 0
$ go vet ./...              # exit 0
$ ./bin/controller-gen object:headerFile=hack/boilerplate.go.txt paths=./api/v1alpha1   # no diff
$ ./bin/controller-gen crd paths=./api/v1alpha1 output:crd:artifacts:config=config/crd/bases
# diff vs main: only the tolerations schema, in generated (alphabetical) order

go test ./... is green except for the two envtest suites, which cannot start a control plane in my sandbox because the kubebuilder assets are not installed (they fail the same way on unmodified main):

internal/controller/k8sgpt    ERROR controller-runtime.test-env  unable to start the controlplane
  {"tries": 0, "error": "exec: \"\\\\usr\\\\local\\\\kubebuilder\\\\bin\\\\etcd\": executable file not found in %PATH%"}
internal/controller/mutation  mutation_e2e_test.go:45: unable to start control plane itself: failed to start
  the controlplane. retried 5 times: exec: "\\usr\\local\\kubebuilder\\bin\\etcd": executable file not found in %PATH%

Note on process: the rebase, the CRD regeneration and the verification above were done with an AI coding assistant, which is why I am being explicit about who wrote what.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: CJstate / name: CJstate (bed96c1)

[AlexsJones]

Thanks @CJstate, this is a careful carry-forward of #820, and regenerating both CRD copies with the pinned controller-gen instead of hand-merging was the right move.

The change matches what was agreed on #767: spec.tolerations copied into the K8sGPT Deployment in GetDeployment, and controllerManager.tolerations in the chart behind the same if guard as nodeSelector, at pod-spec level. The test covers both fields. I approved the fork runs, and tests and the container build passed on this exact tree (your re-authored commit has the same tree as 2afaa4e).

Two things before it can land: EasyCLA still needs your signature, and which of #820 and #855 goes in is a maintainer call, so I've flagged that.

[CJstate]

Thanks for the review and the approval, @AlexsJones — CI is green on the current head (Run tests and Build container both pass).

The only red check left is the EasyCLA signature, and that one is on my side, so please hold off merging for a moment while I get it sorted. (The commit author is me for exactly that reason; @preko-p is credited as co-author in the commit message and in the description, and #820 stays open if they would rather pick it up there.)

[CJstate]

@AlexsJones EasyCLA is now signed and all checks are green. Thanks for flagging the maintainer call on #820 vs #855 — ready whenever the team decides how you'd like to proceed.

[CJstate]

Correction to my previous comment — nothing is pending on my side any more.

EasyCLA re-evaluated this PR and the check on the current head (bed96c10) is now green: "EasyCLA check passed. You are authorized to contribute." (2026-10-03T11:36Z). The combined status on that commit is success (DCO, License Compliance, EasyCLA) and all check runs on this exact tree are green or intentionally skipped, Test Helm Chart included.

So please disregard the "hold off for a moment" in my last comment: from my side the PR is ready whenever you decide between #820 and #855. #820 has not been touched, and @preko-p is credited in the commit message and in the description either way.

[AlexsJones]

Thanks for sorting the CLA so quickly @CJstate. Everything on this head is green now, so the only thing left is the #820 vs #855 call, and I've updated that with the maintainers to say nothing else is blocking.

[CJstate]

Thanks for the kind words and for pushing this forward, @AlexsJones. I'll defer to the maintainers on the #820 vs #855 decision—either way works for me, my goal was just to unblock this feature. Feel free to reach out if anything else is needed.