feat(zrpc): migrate kube resolver from Endpoints to EndpointSlice API

[soasurs]

Motivation

Kubernetes is gradually deprecating the legacy core/v1 Endpoints API in favor of the newer discovery/v1 EndpointSlice API.
Compared with Endpoints, EndpointSlice objects:

• Scale horizontally—each slice covers a subset of endpoints, avoiding the single-object size limit.
• Reduce API-server churn—only slices that change are updated.
• Provide topology and readiness metadata that can be leveraged for smarter routing.

To keep go-zero up-to-date with upstream best practices and to prevent future breakage as clusters disable the old API, we need to adopt EndpointSlice.

---

What this PR does

1. Event Path Migration

   • Replaces all core/v1 Endpoints types with discovery/v1 EndpointSlice in the kube resolver.
   • Adjusts event-handler logic to iterate over EndpointSlice.Endpoints[].Addresses[].

2. Informer Updates

   • Swaps the informer factory from Core().V1().Endpoints() to Discovery().V1().EndpointSlices().
   • Uses the recommended label selector kubernetes.io/service-name=<svc>.

3. Initial Sync & Port Resolution

   • Lists existing EndpointSlice objects for the target service at startup.
   • Resolves svc.Port from the first available slice port when the user omits it.

4. Constants & Clean-ups

   • Renames nameSelector → serviceSelector for clarity.
   • Adds explicit error reporting when no matching slices are found.

---

Impact

• Transparent to callers – existing zrpc resolver API remains unchanged.
• Better scalability & performance – large services no longer hit the 1000-endpoint hard limit.
• Future-proof – compatible with clusters that have disabled the legacy Endpoints API.
• RBAC change required – controllers using this resolver must be granted get, list, watch on EndpointSlices (discovery.k8s.io group).

No other functional regressions are expected. All unit tests pass against Kubernetes ≥1.21 (the minimum version that GA-supports EndpointSlice).

[codecov]

Codecov Report

Attention: Patch coverage is 57.89474% with 16 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
zrpc/resolver/internal/kubebuilder.go	0.00%	16 Missing ⚠️

📢 Thoughts on this report? Let us know!

[kevwan]

Thanks for your contribution!

This PR will be merged in v1.9.0

[Copilot]

Pull Request Overview

This PR migrates the zrpc Kubernetes resolver from using the legacy core/v1 Endpoints API to the newer discovery/v1 EndpointSlice API, updating event handling, informer setup, initial synchronization, and port resolution.

• Swap informer and event-handler logic to work with EndpointSlice and its Endpoints[].Addresses[].
• Implement initial listing of EndpointSlice objects and derive service port from the first available slice.
• Rename selector constant and add explicit error when no slices are found.

Reviewed Changes

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

File	Description
zrpc/resolver/internal/kubebuilder.go	Replace Endpoints informer with EndpointSlices, update port resolution and initial sync
zrpc/resolver/internal/kube/eventhandler.go	Update event handler and update logic to handle discovery/v1.EndpointSlice
zrpc/resolver/internal/kube/eventhandler_test.go	Update tests to use EndpointSlice types and verify address-change handling

Comments suppressed due to low confidence (1)

zrpc/resolver/internal/kubebuilder.go:62

• The logic that lists EndpointSlices and assigns svc.Port from the first slice isn't covered by existing tests. Consider adding unit tests for port resolution and the error path when no slices or ports are available.

	if svc.Port == 0 {

When there’s a pod change, the EndpointSlice returned isn’t the full set, but only the changed slice, right? We need to carefully analyze the notification mechanism. For example, if it’s split into 10 slices and a new pod is added, only one slice is returned — then traffic might become skewed toward that part.