Skip to content

K8SPG-866 use discovery.k8s.io/v1 EndpointSlice - #1307

Closed
gkech wants to merge 14 commits into
mainfrom
K8SPG-866
Closed

K8SPG-866 use discovery.k8s.io/v1 EndpointSlice#1307
gkech wants to merge 14 commits into
mainfrom
K8SPG-866

Conversation

@gkech

@gkech gkech commented Oct 2, 2025

Copy link
Copy Markdown
Contributor

K8SPG-866 Powered by Pull Request Badge

DESCRIPTION

Problem:
v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointSlice

Solution:
Before this PR, the operator created only the -primary Endpoints resource. All other Endpoints resources are created by patroni. Patroni currently does not support creating EndpointSlices in place of the deprecated Endpoints.

This PR adds a feature gate EndpointSlices which replaces the -primary Endpoints resource with an EndpointSlice once version 2.9.0 is reached. As part of the migration, the deprecated Endpoints resource and the mirrored EndpointSlice created by endpointslicemirroring-controller.k8s.io from the deprecated Endpoints resource are deleted.

This PR also addresses the fact that EndpointSlices are not supported on GKE out of the box. The default DNS provider on GKE is kube-dns, which does not support EndpointSlices. To use EndpointSlices, users must manually deploy CoreDNS or use Cloud DNS. To fix tests, every test deploys CoreDNS in the kube-system namespace if it is not already present.

Please note that Endpoints resources are mirrored to EndpointSlices by endpointslicemirroring-controller.k8s.io, which is why the upgrade-consistency test includes assertions for EndpointSlices.

CHECKLIST

Jira

  • Is the Jira ticket created and referenced properly?
  • Does the Jira ticket have the proper statuses for documentation (Needs Doc) and QA (Needs QA)?
  • Does the Jira ticket link to the proper milestone (Fix Version field)?

Tests

  • Is an E2E test/test case added for the new feature/change?
  • Are unit tests added where appropriate?

Config/Logging/Testability

  • Are all needed new/changed options added to default YAML files?
  • Are all needed new/changed options added to the Helm Chart?
  • Did we add proper logging messages for operator actions?
  • Did we ensure compatibility with the previous version or cluster upgrade process?
  • Does the change support oldest and newest supported PG version?
  • Does the change support oldest and newest supported Kubernetes version?

@egegunes egegunes left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR also addresses the fact that EndpointSlices are not supported on GKE out of the box. The default DNS provider on GKE is kube-dns, which does not support EndpointSlices. To use EndpointSlices, users must manually deploy CoreDNS or use Cloud DNS. To fix tests, every test deploys CoreDNS in the kube-system namespace if it is not already present.

this worries me. this means we are breaking GKE installations out of the box. and we don't know when will Endpoints support be dropped. maybe we need make using EndpointSlices optional for now by introducing a cr field. wdyt @hors ?

@mayankshah1607

mayankshah1607 commented Jan 20, 2026

Copy link
Copy Markdown
Member

maybe we need make using EndpointSlices optional for now by introducing a cr field

It looks more like a system-wide preference. Do we imagine a use-case where some clusters use Endpoints and some use EndpointSlices? Maybe it should be a CLI / feature flag?

@egegunes

Copy link
Copy Markdown
Contributor

maybe we need make using EndpointSlices optional for now by introducing a cr field

It looks more like a system-wide preference. Do we imagine a use-case where some clusters use Endpoints and some use EndpointSlices? Maybe it should be a CLI / feature flag?

yes, you have a point. maybe we need a feature flag

@hors

hors commented Jan 22, 2026

Copy link
Copy Markdown
Collaborator

maybe we need make using EndpointSlices optional for now by introducing a cr field

It looks more like a system-wide preference. Do we imagine a use-case where some clusters use Endpoints and some use EndpointSlices? Maybe it should be a CLI / feature flag?

yes, you have a point. maybe we need a feature flag

Let's use a feature flag and disable it by default.

@JNKPercona

Copy link
Copy Markdown
Collaborator
Test Name Result Time
backup-enable-disable passed 00:09:36
builtin-extensions passed 00:05:50
cert-manager-tls passed 00:05:33
custom-envs passed 00:19:15
custom-extensions passed 00:15:41
custom-tls passed 00:05:53
database-init-sql passed 00:02:20
demand-backup passed 00:33:33
demand-backup-offline-snapshot failure 00:31:08
dynamic-configuration passed 00:03:30
finalizers passed 00:03:59
init-deploy passed 00:02:54
huge-pages passed 00:03:18
ldap passed 00:07:16
ldap-tls passed 00:06:33
monitoring passed 00:08:17
monitoring-pmm3 passed 00:10:48
one-pod passed 00:06:24
operator-self-healing failure 01:30:22
pg-tde passed 00:10:32
pitr passed 00:13:00
scaling passed 00:06:52
scheduled-backup passed 00:29:58
self-healing passed 00:08:57
sidecars passed 00:02:46
standby-pgbackrest passed 00:13:35
standby-streaming passed 00:09:42
start-from-backup passed 00:16:29
tablespaces passed 00:08:06
telemetry-transfer passed 00:04:01
upgrade-consistency passed 00:05:15
upgrade-minor passed 00:05:51
users passed 00:04:50
Summary Value
Tests Run 33/33
Job Duration 02:54:18
Total Test Time 06:52:18

commit: bd37c95
image: perconalab/percona-postgresql-operator:PR-1307-bd37c959e

@gkech

gkech commented May 12, 2026

Copy link
Copy Markdown
Contributor Author

going to close this pr for now and we can reopen if needed

@gkech gkech closed this May 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants