chore(K8s): migrate from CoreV1 Endpoints to DiscoveryV1 EndpointSlice

[programmer04]

What this PR does / why we need it:

EndpointSlice API is available as V1 since K8s 1.21. KIC 2.9's minimum supported K8s version is 1.22.

Which issue this PR fixes:

#3916

Leftovers to address separately

• KIC docs - Update FAQ about endpoints for KIC 2.10 docs.konghq.com#5578
• KIC linter config - chore(ci): unify import aliases and introduce forbidigo #4016
• Helm Chart - Adjust RBAC permissions for KIC for Endpoints and secrets/status charts#795

Special notes for your reviewer:

1. K8s permissions - get rid of Endpoints, EndpointSlices are already allowed - get (from annotation), watch, list. Subresource status is redundant for both Endpoints or EndpointSlices because they don't implement it. Affected files

   • config/rbac/role.yaml
   • deploy/single/*.yaml

   I've spotted secrets/status too, it seems redundant (it's addressed separately in chore(rbac): get rid of rbac permissions for secrets/status #4017).

2. One K8s Service can have multiple EndpointSlices thus now we have to work with a slice instead of a single resource.

3. In terms of readiness for an endpoint the way that ensures the same semantic as in CoreV1 is used.

4. EndpointSlice by default handles 100 endpoints, Service can have multiple EndpointSlices. In integration/e2e tests having a Service that has more than one EndpointSlice is rather not sensible. But in controller manager with --max-endpoints-per-slice flag number of allowed endpoints per EndpointSlice can be adjusted. Maybe it's worth to add a test case that would use a cluster that will have configured --max-endpoints-per-slice 1 so multiple EndpointSlices per Service will be easily achievable.

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

[codecov]

Codecov Report

Patch coverage: 88.6% and project coverage change: -0.1 ⚠️

Comparison is base (4fa7cf0) 59.7% compared to head (0a2fec4) 59.6%.

❗ Current head 0a2fec4 differs from pull request most recent head 2829cbf. Consider uploading reports for the commit 2829cbf to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3997     +/-   ##
=======================================
- Coverage   59.7%   59.6%   -0.1%     
=======================================
  Files        149     149             
  Lines      16399   16406      +7     
=======================================
- Hits        9793    9782     -11     
- Misses      5970    5987     +17     
- Partials     636     637      +1     

Impacted Files	Coverage Δ
internal/store/store.go	56.6% <73.0%> (+0.2%)	⬆️
...trollers/configuration/zz_generated_controllers.go	27.3% <85.7%> (ø)
internal/dataplane/parser/parser.go	74.3% <97.5%> (-1.2%)	⬇️
internal/manager/controllerdef.go	98.8% <100.0%> (ø)
internal/store/fake_store.go	58.7% <100.0%> (ø)

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[pmalek]

2 things that I'd like to raise:

• the left over issues that you mention: ideally we'd have issues for those so that we don't loose track of those
• I believe we should add a changelog entry for this because
  • we'll have a trace in history (apart from git log) stating where we've changed from one to another
  • some users might be genuinely interested in this change, so let's now hide it from them

[pmalek]

When you're ready with this you might want to add ci/run-e2e label to your PR to trigger e2e tests to verify everything is as it should be.

[randmonkey]

Generally LGTM, only some minor points remaining. Also, Since the user-facing manifests are changed, I think this needs an update on CHANGELOG.

[pmalek]

@programmer04 There seem to be some failures in GKE e2e tests 🤔
https://github.com/Kong/kubernetes-ingress-controller/actions/runs/4991359055/jobs/8937809045#step:5:129

I'll be happy to help you out in debugging them.

[programmer04]

GKE e2e tests failed, because we don't have mechanism of building&loading images from PR to GKE clusters, there is issue KTF #587 to implement this. Curently it uses an image from nightlies that does not include changes from this PR

[pmalek]

GKE e2e tests failed, because we don't have mechanism of building&loading images from PR to GKE clusters, there is issue KTF #587 to implement this. Curently it uses an image from nightlies that does not include changes from this PR

As discussed on zoom: I'm OK merging this and seeing the results of tests the next day but I'd suggest we invest in the GKE image loading so that we don't need to do this in the future.

The fact that this works on kind and all integration tests given a certain level of confidence that this will work on GKE as well.