Service's information about Endpoints doesn't update after creating EndpointSlice object

[IvanOtkidach]

What happened?

Hello everyone! Trying to follow the documentation page https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/ I made a Service (with no selectors) and a EndpointSlice based on documentation. Unfortunately, command "kubectl describe svc" indicates that EndpointSlice didn't map to a Service (Endpoints: ), but it actually did.

What did you expect to happen?

"kubectl describe svc" shows "Endpoints: "Ip from endpointslice object""

How can we reproduce it (as minimally and precisely as possible)?

1. Create objects (Service and EndpointSlice)
2. kubectl describe svc external

Service:

apiVersion: v1 kind: Service metadata: name: external namespace: default spec: ipFamilies:

• IPv4 ports:
• port: 80 protocol: TCP targetPort: 80 type: ClusterIP

apiVersion: discovery.k8s.io/v1 kind: EndpointSlice metadata: name: external labels: kubernetes.io/managed-by: manual kubernetes.io/service-name: external addressType: IPv4 ports:

• port: 80 endpoints:
• addresses:
  • "my ip" conditions: ready: true

Anything else we need to know?

No response

Kubernetes version

$ kubectl version
# paste output here
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.4", GitCommit:"fa3d7990104d7c1f16943a67f11b154b71f6a132", GitTreeState:"clean", BuildDate:"2023-07-19T12:20:54Z", GoVersion:"go1.20.6", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.4", GitCommit:"fa3d7990104d7c1f16943a67f11b154b71f6a132", GitTreeState:"clean", BuildDate:"2023-07-19T12:14:49Z", GoVersion:"go1.20.6", Compiler:"gc", Platform:"linux/amd64"}

Cloud provider

no

OS version

# On Linux:
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
# paste output here
$ uname -a
Linux Master-node-1 5.15.0-78-generic kubernetes/kubernetes#85-Ubuntu SMP Fri Jul 7 15:25:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

kubeadm version: &version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.4", GitCommit:"fa3d7990104d7c1f16943a67f11b154b71f6a132", GitTreeState:"clean", BuildDate:"2023-07-19T12:19:40Z", GoVersion:"go1.20.6", Compiler:"gc", Platform:"linux/amd64"}

Container runtime (CRI) and version (if applicable)

containerd containerd.io 1.6.21 3dce8eb055cbb6872793272b4f20ed16117344f8

Related plugins (CNI, CSI, ...) and versions (if applicable)

docker.io/weaveworks/weave-kube@sha256:35827a9c549c095f0e9d1cf8b35d8f27ae2c76e31bc6f7f3c0bc95911d5accea

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[aojea]

kubectl describe does not use EndpointSlices to map the information, it uses the Endpoints

https://github.com/kubernetes/kubernetes/blob/2c6c4566eff972d6c1320b5f8ad795f88c822d09/staging/src/k8s.io/kubectl/pkg/describe/describe.go#L2955-L2959

/sig cli

take into account that kubectl describe is just informational

[Ithrael]

I think the issue lies in the fact that "kubectl describeService" command retrieves endpoints instead of endpointSlice. And the endpoints do not have the address from the endpointSlice. When creating an endpointSlice and the label matches the service's "kubernetes.io/service-name: external", the address of the endpointSlice should be added to the subsets of the endpoints with the same name. /assign

[aojea]

the address of the endpointSlice should be added to the subsets of the endpoints with the same name.

@Ithrael before moving forward, what solution are you suggesting?

The best solution is for the kubectl library to use EndpointSlices instead of Endpoints because there is an EndpointSliceMirroring controller that will mirror the custom Endpoints, that is the opposite situation we have here, since we never implemented a controller that mirror custom Endpointslices to Endpoints, since the evolution is only one way, from Endpoint to Endpointslices

[sftim]

The best solution is for the kubectl library to use EndpointSlices instead of Endpoints

:+1: This also scales better: kubectl describe service … will give incomplete information for a Service with many endpoints

(we should think about how to handle that - if there are more than say 60 - or some other number, say 300 - endpoints, we might want to provide a summary even for kubectl describe)

[sftim]

I recommend this Prow command, but will let someone else run it: /transfer kubectl

[sftim]

We might also want to update the documentation to clarify why kubectl describe doesn't show that detail.

@IvanOtkidach are you willing to file that as a separate issue?

[sftim]

:thought_balloon: what should kubectl describe service do - if anything - when the Endpoints and EndpointSlices are not in sync?

[aojea]

💭 what should kubectl describe service do - if anything - when the Endpoints and EndpointSlices are not in sync?

This should happen only with custom created objects, IIRC he mirroring controller must take over and create the corresponding EndpointSlices ...

[sftim]

Mmm, I was thinking of the custom object creation case. But there is also the too-many-backends case.

[sftim]

Should we transfer this to the kubectl issue tracker?

[mpuckett159]

Should we transfer this to the kubectl issue tracker?

I agree we should transfer to the kubectl issue tracker and figure out how to handle the open issues of how to display the information in different scenarios. Will go ahead and do that. /transfer kubectl

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[aroradaman]

@mpuckett159 I have a PR with the fix. https://github.com/kubernetes/kubernetes/pull/124598