-
Notifications
You must be signed in to change notification settings - Fork 2k
Description
Version
edge
What Kubernetes platforms are you running on?
Other
Steps to reproduce
Consider the following deployment that uses Virtualserver
and a service without selectors:
apiVersion: v1
kind: Service
metadata:
name: coffee-svc
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
name: http
---
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
addressType: IPv4
ports:
- name: http
port: 8080
protocol: TCP
endpoints:
- addresses:
- 1.2.3.4
conditions:
ready: true
metadata:
name: coffee-1
labels:
kubernetes.io/service-name: coffee-svc
---
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
upstreams:
- name: coffee
port: 80
service: coffee-svc
routes:
- path: /coffee
action:
pass: coffee
The generated config for the deployment above will contain an upstream block similar to
upstream vs_default_cafe_coffee {
zone vs_default_cafe_coffee 512k;
random two least_conn;
server 1.2.3.4:8080 max_fails=1 fail_timeout=10s max_conns=0;
}
Now, if the endpointslice coffee-1
is changed, the upstream server block will change and reflect the new addresses. Also, if a new endpointslice pointing to the right service via the label kubernetes.io/service-name: coffee-svc
is created, the upstream block will include those new addresses. That works well.
However, deleting an existing endpointslice does not remove its addresses from the upstream block. This is because in syncEndpointSlices
we do an early return if the change is a deletion. This is not correct, since the endpointslice could be associated to an existing service and therefore a config change would need to be done in the corresponding upstream block.
Current workarounds are:
- Deleting and re-adding the VirtualServer.
- Pointing the VirtualServer at a nonexistent service, then pointing it back to the correct service again.
- Unlink the endpoints then delete the endpointSlice.