k8s: include namespace in EndpointSliceName by EmilyShepherd · Pull Request #43999 · cilium/cilium

EmilyShepherd · 2026-01-25T15:56:23Z

We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes").

Including the namespace in EndpointSliceNames guarantees collisions cannot occur.

Warning: If this bugfix is to be merged into a branch that does not yet contain d003678, the old code that that commit cleaned up suffers from the same bug. Happy to provide a separate PR for that, if required, although it looks very out of date.

Please ensure your pull request adheres to the following guidelines:

For first time contributors, read Submitting a pull request
All code is covered by unit and/or runtime tests where feasible.
All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
All commits are signed off. See the section Developer’s Certificate of Origin
Provide a title or release-note blurb suitable for the release notes.
Are you a user of Cilium? Please add yourself to the Users doc
Thanks for contributing!

Fix a bug where removed addresses from EndpointSlices might be missed if multiple EndpointSlices share the same name

joamaki · 2026-01-26T11:00:35Z

Was there an actual issue caused by this? pkg/loadbalancer/reflectors/k8s.go collates endpoint slices by the namespaced service name so it shouldn't matter that the EndpointSliceName is not namespaced. At least I cannot find where we could mix them up.

What would be awesome would be if you'd be able to show with a test case in pkg/loadbalancer/tests/testdata that this indeed is a bug. clusterip.txtar might be a reasonable starting point. Just strip out all the stuff about BPF maps and just focus on inserting services and endpoints slices and seeing if this causes a collision.

Or is there a problematic use of EndpointSliceName outside of pkg/loadbalancer?

I wouldn't change this just for the sake of it if there are no issues due to this as this does increase the number of allocations we need to perform to process an endpoint slice change.

EmilyShepherd · 2026-01-26T11:19:03Z

Was there an actual issue caused by this? pkg/loadbalancer/reflectors/k8s.go collates endpoint slices by the namespaced service name so it shouldn't matter that the EndpointSliceName is not namespaced. At least I cannot find where we could mix them up.

Yes, apologies, I should have given more context:

processEndpointsEvent in pkg/loadbalancer/reflectors/k8s.go uses a map of all endpoints called currentEndpoints which it indexes using just the EndpointSliceName. This is used to detect orphan backend addresses (when they are removed from an endpoint slice) which should then be deleted from the BPF maps.

This bug caused real negative behaviour in our cluster, which does have EndpointSlices of the same name across namespaces, as each would clobber each other in the currentEndpoints map, resulting in cilium-agent successfully adding new backend addresses whenever they were added to EndpointSlices, but not always noticing and cleaning up when addresses were deleted.

What would be awesome would be if you'd be able to show with a test case in pkg/loadbalancer/tests/testdata that this indeed is a bug. clusterip.txtar might be a reasonable starting point. Just strip out all the stuff about BPF maps and just focus on inserting services and endpoints slices and seeing if this causes a collision.

This is reasonable - I will try to formulate a testcase to demonstrate this bug.

EmilyShepherd · 2026-01-26T12:36:52Z

@joamaki Thank you to the pointer to the testcases - I have added a testcase now demonstrating how this issue arises.

Without 4bd9521 this test always fails, with it the test always passes.

If you could point me in the right direction of the correct commit order etiquette for this test, that would be very helpful. Normally I'd add a fail-proving test before the commit that fixes it, but cilium's Contribution Guide mentions that every commit needs to be able to build so I wasn't clear if that means "every commit needs to compile + all tests pass" or just "every commit needs to compile; fail proving tests are acceptable". Happy to reorder commits as suggested.

(Also rebased to latest main)

EmilyShepherd · 2026-01-26T13:46:29Z

If we are concerned about memory usage, we could look at changing EndpointSliceName to be based on the EndpointSlice's uid instead of name (or name + namespace), which Kubernetes loosely guarantees will be a uuid

If we parse the uuid into a 128-bit value this will create a constant, and relatively short 16-byte binary string, or if we take the uid as-is a 36 byte string without any extra processing / allocations.

I would be happy to do this if you think it would have value.

joamaki · 2026-01-26T13:49:19Z

@joamaki Thank you to the pointer to the testcases - I have added a testcase now demonstrating how this issue arises.

Without 4bd9521 this test always fails, with it the test always passes.

If you could point me in the right direction of the correct commit order etiquette for this test, that would be very helpful. Normally I'd add a fail-proving test before the commit that fixes it, but cilium's Contribution Guide mentions that every commit needs to be able to build so I wasn't clear if that means "every commit needs to compile + all tests pass" or just "every commit needs to compile; fail proving tests are acceptable". Happy to reorder commits as suggested.

(Also rebased to latest main)

Awesome thanks for the test case! I would add the failing test case first and then the fix. The CI only checks that every commit builds (e.g. go build ./...) not that every test passes on every commit.

I think the test case would be slightly easier to follow if it wouldn't look at the BPF maps and would just look at the tables. I'll see if I can come up with a minimal version of it.

joamaki · 2026-01-26T14:05:32Z

Here's a suggestion for how to write the test case:

#
# Regression test case for checking that the EndpointSlice names are allowed to overlap across
# namespaces. https://github.com/cilium/cilium/pull/43999.
#

# Start the test application
hive/start

# Make the test-b variants of the service and endpoint slice
cp service-a.yaml service-b.yaml
sed 'namespace: test-a' 'namespace: test-b' service-b.yaml
sed '10.96.50.104' '10.96.50.105' service-b.yaml
cp endpointslice-a.yaml endpointslice-b.yaml
sed 'namespace: test-a' 'namespace: test-b' endpointslice-b.yaml
sed '10.244.1.' '10.245.1.' endpointslice-b.yaml

# 1. Add the test-a Service and EndpointSlice.
k8s/add service-a.yaml endpointslice-a.yaml
db/cmp frontends frontends-1.table
db/cmp backends backends-1.table

# 2. Add the test-b Service and EndpointSlice. Both endpoint slices have
# the same name.
k8s/add service-b.yaml endpointslice-b.yaml
db/cmp frontends frontends-2.table
db/cmp backends backends-2.table

# 3. Update the first EndpointSlice - remove an address.
sed '.*- 10.244.1.2' '' endpointslice-a.yaml
k8s/update endpointslice-a.yaml
db/cmp frontends frontends-3.table
db/cmp backends backends-3.table

-- frontends-1.table --
Address               Type        ServiceName      PortName   Backends                             Status   Error
10.96.50.104:80/TCP   ClusterIP   test-a/service   http       10.244.1.1:80/TCP, 10.244.1.2:80/TCP Done

-- backends-1.table --
Address             Instances               Shadows   NodeName
10.244.1.1:80/TCP   test-a/service (http)             nodeport-worker
10.244.1.2:80/TCP   test-a/service (http)             nodeport-worker

-- frontends-2.table --
Address               Type        ServiceName      PortName   Backends                             Status   Error
10.96.50.104:80/TCP   ClusterIP   test-a/service   http       10.244.1.1:80/TCP, 10.244.1.2:80/TCP Done
10.96.50.105:80/TCP   ClusterIP   test-b/service   http       10.245.1.1:80/TCP, 10.245.1.2:80/TCP Done

-- backends-2.table --
Address             Instances               Shadows   NodeName
10.244.1.1:80/TCP   test-a/service (http)             nodeport-worker
10.244.1.2:80/TCP   test-a/service (http)             nodeport-worker
10.245.1.1:80/TCP   test-b/service (http)             nodeport-worker
10.245.1.2:80/TCP   test-b/service (http)             nodeport-worker

-- frontends-3.table --
Address               Type        ServiceName      PortName   Backends                             Status   Error
10.96.50.104:80/TCP   ClusterIP   test-a/service   http       10.244.1.1:80/TCP                    Done
10.96.50.105:80/TCP   ClusterIP   test-b/service   http       10.245.1.1:80/TCP, 10.245.1.2:80/TCP Done

-- backends-3.table --
Address             Instances               Shadows   NodeName
10.244.1.1:80/TCP   test-a/service (http)             nodeport-worker
10.245.1.1:80/TCP   test-b/service (http)             nodeport-worker
10.245.1.2:80/TCP   test-b/service (http)             nodeport-worker

-- service-a.yaml --
apiVersion: v1
kind: Service
metadata:
  name: service
  namespace: test-a
spec:
  clusterIP: 10.96.50.104
  clusterIPs:
  - 10.96.50.104
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  type: ClusterIP
  sessionAffinity: ClientIP

-- endpointslice-a.yaml --
# Initial EndpointSlice has two addresses
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  labels:
    kubernetes.io/service-name: service
  name: service
  namespace: test-a
addressType: IPv4
endpoints:
- addresses:
  - 10.244.1.1
  - 10.244.1.2
  conditions:
    ready: true
    serving: true
    terminating: false
  nodeName: nodeport-worker
ports:
- name: http
  port: 80
  protocol: TCP

EmilyShepherd · 2026-01-26T14:08:01Z

Here's a suggestion for how to write the test case:

#
# Regression test case for checking that the EndpointSlice names are allowed to overlap across
# namespaces. https://github.com/cilium/cilium/pull/43999.
#

# Start the test application
hive/start

# Make the test-b variants of the service and endpoint slice
cp service-a.yaml service-b.yaml
sed 'namespace: test-a' 'namespace: test-b' service-b.yaml
sed '10.96.50.104' '10.96.50.105' service-b.yaml
cp endpointslice-a.yaml endpointslice-b.yaml
sed 'namespace: test-a' 'namespace: test-b' endpointslice-b.yaml
sed '10.244.1.' '10.245.1.' endpointslice-b.yaml

# 1. Add the test-a Service and EndpointSlice.
k8s/add service-a.yaml endpointslice-a.yaml
db/cmp frontends frontends-1.table
db/cmp backends backends-1.table

# 2. Add the test-b Service and EndpointSlice. Both endpoint slices have
# the same name.
k8s/add service-b.yaml endpointslice-b.yaml
db/cmp frontends frontends-2.table
db/cmp backends backends-2.table

# 3. Update the first EndpointSlice - remove an address.
sed '.*- 10.244.1.2' '' endpointslice-a.yaml
k8s/update endpointslice-a.yaml
db/cmp frontends frontends-3.table
db/cmp backends backends-3.table

-- frontends-1.table --
Address               Type        ServiceName      PortName   Backends                             Status   Error
10.96.50.104:80/TCP   ClusterIP   test-a/service   http       10.244.1.1:80/TCP, 10.244.1.2:80/TCP Done

-- backends-1.table --
Address             Instances               Shadows   NodeName
10.244.1.1:80/TCP   test-a/service (http)             nodeport-worker
10.244.1.2:80/TCP   test-a/service (http)             nodeport-worker

-- frontends-2.table --
Address               Type        ServiceName      PortName   Backends                             Status   Error
10.96.50.104:80/TCP   ClusterIP   test-a/service   http       10.244.1.1:80/TCP, 10.244.1.2:80/TCP Done
10.96.50.105:80/TCP   ClusterIP   test-b/service   http       10.245.1.1:80/TCP, 10.245.1.2:80/TCP Done

-- backends-2.table --
Address             Instances               Shadows   NodeName
10.244.1.1:80/TCP   test-a/service (http)             nodeport-worker
10.244.1.2:80/TCP   test-a/service (http)             nodeport-worker
10.245.1.1:80/TCP   test-b/service (http)             nodeport-worker
10.245.1.2:80/TCP   test-b/service (http)             nodeport-worker

-- frontends-3.table --
Address               Type        ServiceName      PortName   Backends                             Status   Error
10.96.50.104:80/TCP   ClusterIP   test-a/service   http       10.244.1.1:80/TCP                    Done
10.96.50.105:80/TCP   ClusterIP   test-b/service   http       10.245.1.1:80/TCP, 10.245.1.2:80/TCP Done

-- backends-3.table --
Address             Instances               Shadows   NodeName
10.244.1.1:80/TCP   test-a/service (http)             nodeport-worker
10.245.1.1:80/TCP   test-b/service (http)             nodeport-worker
10.245.1.2:80/TCP   test-b/service (http)             nodeport-worker

-- service-a.yaml --
apiVersion: v1
kind: Service
metadata:
  name: service
  namespace: test-a
spec:
  clusterIP: 10.96.50.104
  clusterIPs:
  - 10.96.50.104
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  type: ClusterIP
  sessionAffinity: ClientIP

-- endpointslice-a.yaml --
# Initial EndpointSlice has two addresses
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  labels:
    kubernetes.io/service-name: service
  name: service
  namespace: test-a
addressType: IPv4
endpoints:
- addresses:
  - 10.244.1.1
  - 10.244.1.2
  conditions:
    ready: true
    serving: true
    terminating: false
  nodeName: nodeport-worker
ports:
- name: http
  port: 80
  protocol: TCP

Ta. Yes this is far more readable. I'll update.

joamaki · 2026-01-26T14:08:38Z

If we are concerned about memory usage, we could look at changing EndpointSliceName to be based on the EndpointSlice's uid instead of name (or name + namespace), which Kubernetes loosely guarantees will be a uuid

If we parse the uuid into a 128-bit value this will create a constant, and relatively short 16-byte binary string, or if we take the uid as-is a 36 byte string without any extra processing / allocations.

I would be happy to do this if you think it would have value.

I quickly checked with pkg/loadbalancer/benchmark and there wasn't a noticeable difference. I would just go with namespace + name.

joamaki · 2026-01-26T14:09:52Z

"fix endpointslices with the same name cause changes to be missed" as release note is a bit vague. Could you reword it a bit so it's clear what was fixed?

This commit adds a test that when we have two EndpointSlices in different namespaces with the same name, that these do not cause any collisions or problems. Specifically, we test the scenario where two EndpointSlices are setup, then one is modified by removing an address. This should be correctly picked up and the backend removed from the BPF maps. This test is a regression test for cilium#43999. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes"). Including the namespace in EndpointSliceNames guarantees collisions cannot occur. See cilium#43999 for further discussion of this bug. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

joamaki · 2026-01-26T14:36:53Z

/test

maintainer-s-little-helper · 2026-01-26T16:04:13Z

Commit 3954c69 does not match "(?m)^Signed-off-by:".

Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin

This commit adds a test that when we have two EndpointSlices in different namespaces with the same name, that these do not cause any collisions or problems. Specifically, we test the scenario where two EndpointSlices are setup, then one is modified by removing an address. This should be correctly picked up and the backend removed from the BPF maps. This test is a regression test for cilium#43999. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes"). Including the namespace in EndpointSliceNames guarantees collisions cannot occur. See cilium#43999 for further discussion of this bug. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

This commit adds a test that when we have two EndpointSlices in different namespaces with the same name, that these do not cause any collisions or problems. Specifically, we test the scenario where two EndpointSlices are setup, then one is modified by removing an address. This should be correctly picked up and the backend removed from the BPF maps. This test is a regression test for #43999. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

[ upstream commit e69da93 ] This commit adds a test that when we have two EndpointSlices in different namespaces with the same name, that these do not cause any collisions or problems. Specifically, we test the scenario where two EndpointSlices are setup, then one is modified by removing an address. This should be correctly picked up and the backend removed from the BPF maps. This test is a regression test for cilium#43999. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

[ upstream commit 3132f0c ] We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes"). Including the namespace in EndpointSliceNames guarantees collisions cannot occur. See cilium#43999 for further discussion of this bug. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

[ upstream commit 74c1bde ] This commit adds a test that when we have two EndpointSlices in different namespaces with the same name, that these do not cause any collisions or problems. Specifically, we test the scenario where two EndpointSlices are setup, then one is modified by removing an address. This should be correctly picked up and the backend removed from the BPF maps. This test is a regression test for cilium#43999. Signed-off-by: Emily Shepherd <emily@redcoat.dev> Signed-off-by: Joe Stringer <joe@cilium.io>

[ upstream commit 5c146c3 ] We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes"). Including the namespace in EndpointSliceNames guarantees collisions cannot occur. See cilium#43999 for further discussion of this bug. Signed-off-by: Emily Shepherd <emily@redcoat.dev> Signed-off-by: Joe Stringer <joe@cilium.io>

[ upstream commit 3132f0c ] We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes"). Including the namespace in EndpointSliceNames guarantees collisions cannot occur. See cilium#43999 for further discussion of this bug. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

[ upstream commit 74c1bde ] This commit adds a test that when we have two EndpointSlices in different namespaces with the same name, that these do not cause any collisions or problems. Specifically, we test the scenario where two EndpointSlices are setup, then one is modified by removing an address. This should be correctly picked up and the backend removed from the BPF maps. This test is a regression test for cilium#43999. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

[ upstream commit 5c146c3 ] We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes"). Including the namespace in EndpointSliceNames guarantees collisions cannot occur. See cilium#43999 for further discussion of this bug. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

[ upstream commit 74c1bde ] This commit adds a test that when we have two EndpointSlices in different namespaces with the same name, that these do not cause any collisions or problems. Specifically, we test the scenario where two EndpointSlices are setup, then one is modified by removing an address. This should be correctly picked up and the backend removed from the BPF maps. This test is a regression test for #43999. Signed-off-by: Emily Shepherd <emily@redcoat.dev> Signed-off-by: Joe Stringer <joe@cilium.io>

[ upstream commit 5c146c3 ] We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes"). Including the namespace in EndpointSliceNames guarantees collisions cannot occur. See #43999 for further discussion of this bug. Signed-off-by: Emily Shepherd <emily@redcoat.dev> Signed-off-by: Joe Stringer <joe@cilium.io>

[ upstream commit 74c1bde ] This commit adds a test that when we have two EndpointSlices in different namespaces with the same name, that these do not cause any collisions or problems. Specifically, we test the scenario where two EndpointSlices are setup, then one is modified by removing an address. This should be correctly picked up and the backend removed from the BPF maps. This test is a regression test for cilium#43999. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

[ upstream commit 5c146c3 ] We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes"). Including the namespace in EndpointSliceNames guarantees collisions cannot occur. See cilium#43999 for further discussion of this bug. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

[ upstream commit 74c1bde ] This commit adds a test that when we have two EndpointSlices in different namespaces with the same name, that these do not cause any collisions or problems. Specifically, we test the scenario where two EndpointSlices are setup, then one is modified by removing an address. This should be correctly picked up and the backend removed from the BPF maps. This test is a regression test for #43999. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

[ upstream commit 5c146c3 ] We previously did not include the Namespace in EndpointSliceNames, relying on the fact that EndpointSlices that use generateName- are unlikely to have name collisions, even across namespaces. While this is usually the case, there is no requirement for EndpointSlice managers to use generateName, and there are examples of controllers that do not (for example the master kubernetes service's EndpointSlice is always called "kubernetes"). Including the namespace in EndpointSliceNames guarantees collisions cannot occur. See #43999 for further discussion of this bug. Signed-off-by: Emily Shepherd <emily@redcoat.dev>

EmilyShepherd requested a review from a team as a code owner January 25, 2026 15:56

EmilyShepherd requested a review from joamaki January 25, 2026 15:56

maintainer-s-little-helper bot added the dont-merge/needs-release-note-label The author needs to describe the release impact of these changes. label Jan 25, 2026

github-actions bot added the kind/community-contribution This was a contribution made by a community member. label Jan 25, 2026

EmilyShepherd force-pushed the namespace-endpointslices branch from 2eb772a to 37721e8 Compare January 25, 2026 16:02

EmilyShepherd requested a review from a team as a code owner January 26, 2026 12:27

EmilyShepherd force-pushed the namespace-endpointslices branch 2 times, most recently from 382e990 to e5dc380 Compare January 26, 2026 12:33

joamaki added the release-note/bug This PR fixes an issue in a previous release of Cilium. label Jan 26, 2026

maintainer-s-little-helper bot removed the dont-merge/needs-release-note-label The author needs to describe the release impact of these changes. label Jan 26, 2026

joamaki added needs-backport/1.18 This PR / issue needs backporting to the v1.18 branch needs-backport/1.19 This PR / issue needs backporting to the v1.19 branch labels Jan 26, 2026

EmilyShepherd force-pushed the namespace-endpointslices branch from e5dc380 to f07f3d5 Compare January 26, 2026 14:19

joamaki approved these changes Jan 26, 2026

View reviewed changes

maintainer-s-little-helper bot added the dont-merge/needs-sign-off The author needs to add signoff to their commits before merge. label Jan 26, 2026

Merged via the queue into cilium:main with commit 5c146c3 Jan 26, 2026
76 checks passed

EmilyShepherd mentioned this pull request Jan 26, 2026

[v1.18] Backport: k8s: include namespace in EndpointSliceName #44021

Merged

joestringer mentioned this pull request Jan 27, 2026

Backport for v1.19 release blockers 2026-01-26 #44025

Merged

10 tasks

joestringer added backport-pending/1.19 The backport for Cilium 1.19.x for this PR is in progress. and removed needs-backport/1.19 This PR / issue needs backporting to the v1.19 branch labels Jan 27, 2026

github-actions bot added backport-done/1.19 The backport for Cilium 1.19.x for this PR is done. and removed backport-pending/1.19 The backport for Cilium 1.19.x for this PR is in progress. labels Jan 27, 2026

julianwiedmann added backport/author The backport will be carried out by the author of the PR. backport-pending/1.18 The backport for Cilium 1.18.x for this PR is in progress. and removed needs-backport/1.18 This PR / issue needs backporting to the v1.18 branch labels Jan 28, 2026

cilium-release-bot bot added this to cilium v1.19.0 Feb 3, 2026

cilium-release-bot bot moved this to Released in cilium v1.19.0 Feb 3, 2026

github-actions bot added backport-done/1.18 The backport for Cilium 1.18.x for this PR is done. and removed backport-pending/1.18 The backport for Cilium 1.18.x for this PR is in progress. labels Feb 25, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

k8s: include namespace in EndpointSliceName#43999

k8s: include namespace in EndpointSliceName#43999
borkmann merged 2 commits intocilium:mainfrom
EmilyShepherd:namespace-endpointslices

EmilyShepherd commented Jan 25, 2026 •

edited

Loading

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

EmilyShepherd commented Jan 26, 2026 •

edited

Loading

Uh oh!

EmilyShepherd commented Jan 26, 2026

Uh oh!

EmilyShepherd commented Jan 26, 2026

Uh oh!

joamaki commented Jan 26, 2026 •

edited

Loading

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

EmilyShepherd commented Jan 26, 2026

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

maintainer-s-little-helper bot commented Jan 26, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

EmilyShepherd commented Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

EmilyShepherd commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

EmilyShepherd commented Jan 26, 2026

Uh oh!

EmilyShepherd commented Jan 26, 2026

Uh oh!

joamaki commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

EmilyShepherd commented Jan 26, 2026

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

joamaki commented Jan 26, 2026

Uh oh!

maintainer-s-little-helper bot commented Jan 26, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

EmilyShepherd commented Jan 25, 2026 •

edited

Loading

EmilyShepherd commented Jan 26, 2026 •

edited

Loading

joamaki commented Jan 26, 2026 •

edited

Loading