envoy: server-side apply, skip unchanged applies, and ConfigMap checksum for pod rollouts

[HarshithaMS005]

What type of PR is this?
/kind feature

**What this PR does **:
The Envoy ResourceManager used to only create the proxy ServiceAccount, ConfigMap, Deployment, and Service when they were missing. This PR reconciles those objects on every sync so changes (Envoy image, bootstrap/SDS content, manual edits) converge without deleting the Gateway.
Infra updates use server-side apply (docs) with a single field manager and Force, instead of field-by-field comparison in reconcile.go. reconcile.go now only holds configMapDataChecksum for the pod-template annotation. Because updating a mounted ConfigMap alone does not restart pods, the Deployment pod template keeps a checksum annotation derived from rendered ConfigMap data so bootstrap/SDS changes still trigger a rollout. The controller does not wait for the Envoy Deployment Available condition, so it does not block reconciliation of other Gateways (#198).
Proxy resources use the standard Gateway label gateway.networking.k8s.io/gateway-name (GEP-1762).

Which issue(s) this PR fixes:
Fixes #238

Does this PR introduce a user-facing change?:

NONE

[netlify]

✅ Deploy Preview for kube-agentic-networking ready!

Name	Link
🔨 Latest commit	2847436
🔍 Latest deploy log	https://app.netlify.com/projects/kube-agentic-networking/deploys/6a0ef60d06fb0e0008568641
😎 Deploy Preview	https://deploy-preview-246--kube-agentic-networking.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[HarshithaMS005]

/test pull-kube-agentic-networking-verify

[bowei]

I think since we are adding this new server-side apply logic, it would be good to send a PR for one resource for review to avoid having a quite large review. Once that review is done, we can have a follow up for the rest of the resources as they will be boilerplate in a single follow-up PR.

In addition, it would be good to discuss explicitly which fields you chose to be managed vs unmanaged. There are quite a lot of choices here and it's not clear that the choices are obvious?

Finally, the checksum on the ConfigMap. I would like this separate out into its own PR.

[HarshithaMS005]

@bowei , Thanks for the review — agree on all three points.

• In this branch i ended up with stacked commits (ServiceAccount skip first, then ConfigMap / Deployment / Service skip) rather than separate GitHub PRs; happy to mirror that in the PR description or split into follow-up PRs if you’d rather merge SA-only first.
• Managed vs unmanaged: Documented in serviceAccountDesiredMatchesExisting and in proxy_desired_match.go for ConfigMap, Deployment, and Service (configMapDesiredMatchesExisting, deploymentDesiredMatchesExisting, serviceDesiredMatchesExisting), aligned with what each serviceAccountApply/configMapApply/deploymentApply/
  serviceApply sends on SSA.
• Checksum/rollout: Understood on isolating that story. Today it ships with the SSA infra work on this branch; we can either call that out explicitly in the description/release notes, or I can follow up with a small PR that only moves/splits checksum-related files/commits if you want a distinct review for “hash ConfigMap data → pod rollout.” Say what you prefer.

[haiyanmeng]

/lgtm

/hold for @LiorLieberman to approve

[bowei]

There are some resources we should just consider "owned completely" by the controller. In these cases, it's not out of the question to do the simple thing and overwrite all fields. Is Service Account one of these cases?

I'm trying to think through which controllers/users will "collaborate" on the definition of the service account.

[HarshithaMS005]

Yes — the Envoy proxy ServiceAccount is fully owned by this controller. It has a deterministic hashed name, a Gateway ownerReference, is only referenced by the proxy Deployment, and is deleted with the Gateway. We don’t expect users or other controllers to co-manage this object directly; the only supported customization path is Gateway.spec.infrastructure labels/annotations propagated to proxy infra.
We still shouldn’t do a full-object replace that clears .secrets (populated by the token controllers). SSA via serviceAccountApply only sets labels, annotations, and ownerReferences with our field manager + Force, which is the simple “overwrite what we own” model without touching apiserver-owned fields.

I removed the GET/compare skip-apply logic for the ServiceAccount — that optimization made sense for shared/complex resources but was unnecessary here. ensureSA now always Applies. ConfigMap/Deployment/Service still use skip-apply where the field surface is larger.

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: HarshithaMS005
Once this PR has been reviewed and has the lgtm label, please ask for approval from haiyanmeng. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• pkg/OWNERS

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