fix: proxy-webhook selector matches operator pods

[bowling233]

Changes

Fixes #3227

Both the tekton-operator and tekton-operator-proxy-webhook Deployments
label their Pods with name: tekton-operator. The
tekton-operator-proxy-webhook Service uses this same label as its only
selector, so it inadvertently load-balances traffic across both Deployments.
Because tekton-operator pods do not serve on port 8443, ~50% of admission
webhook requests fail with connection refused. Since the
MutatingWebhookConfiguration has failurePolicy: Fail, each failure
immediately rejects TaskRun Pod creation.

Changes:

• cmd/kubernetes/operator/kodata/webhook/webhook.yaml: rename the
  proxy-webhook Deployment's matchLabels selector and pod template label
  from name: tekton-operator to name: tekton-operator-proxy-webhook;
  update the Service selector to match.
• cmd/openshift/operator/kodata/webhook/webhook.yaml: same change for the
  OpenShift manifest.

The existing app: tekton-operator label is preserved on both Deployments.
No other resources are affected.

Alternative considered: adding a set-based (NotIn) expression to the
Service selector to exclude tekton-operator pods. This was not viable
because Kubernetes Services only support equality-based (matchLabels)
selectors.

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Run make test lint before submitting a PR
• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide for more details.

Note on tests: This bug only manifests at the Service routing layer
(i.e., ~50% of requests land on a pod with no server). There is no
in-tree unit or integration test that exercises which pods a Service
selects. A targeted e2e test verifying that the proxy-webhook Service
endpoints do not include tekton-operator pods would be a good addition,
but is left for a follow-up.

Release Notes

Fix: the tekton-operator-proxy-webhook Service selector incorrectly matched
tekton-operator pods in addition to proxy-webhook pods, causing ~50% of
admission webhook requests to fail with "connection refused" and TaskRun Pod
creation to be rejected. Users on v0.78.1 can work around this until upgrading
by adding `pod-template-hash: <webhook-pod-hash>` to the Service selector.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: bowling233 / name: Baolin Zhu (49cacf1)

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign anithapriyanatarajan after the PR has been reviewed.
You can assign the PR to them by writing /assign @anithapriyanatarajan in a comment when ready.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Copilot]

Pull request overview

Fixes a production routing bug where the tekton-operator-proxy-webhook Service selector unintentionally matched both proxy-webhook and main operator pods, causing intermittent admission webhook failures and rejected TaskRun Pod creation.

Changes:

• Update the proxy-webhook Deployment selector + pod template label to use name: tekton-operator-proxy-webhook.
• Update the proxy-webhook Service selector to match the new pod label (Kubernetes + OpenShift manifests).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
cmd/kubernetes/operator/kodata/webhook/webhook.yaml	Aligns proxy-webhook Deployment/Service selectors to target only proxy-webhook pods on Kubernetes.
cmd/openshift/operator/kodata/webhook/webhook.yaml	Same selector/label fix for the OpenShift manifest.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jkhelil]

@bowling233 , thank for your PR.

• can you check what happens to existing clusters during upgrade? ( Install 0.78.1 and then apply your change)
  Please describe and post a proof that upgrade is working and not broken

[anithapriyanatarajan]

@bowling233 - Request you to address the review comment, if you are still pursuing this PR. Thank you. 🙇‍♀️

[bowling233]

Hi @anithapriyanatarajan,

So sorry for the late response! I won't have the bandwidth to properly validate these changes until next month.

I can confirm this approach has side effects—specifically, the HorizontalPodAutoscaler is hitting FailedGetResourceMetric errors because it's incorrectly picking up the main operator pods, which lack the expected CPU requests in the tekton-operator-lifecycle container.

This PR definitely needs more refinement to handle the selector immutability and the HPA configuration. Should I move this to a Draft for now, or would you prefer I close this and resubmit once I've validated a full fix?