4

I keep getting the below error inconsistently on one of my services' endpoint object. : "Failed to update endpoint default/myservice: Operation cannot be fulfilled on endpoints "myservice": the object has been modified; please apply your changes to the latest version and try again". I am sure I am not editing the endpoint object manually because all my Kubernetes objects are deployed through helm3 charts. But it keeps giving the same error. It goes away if I delete and recreate the service. Please help/give any leads as to what could be the issue. Below is my service.yml object from the cluster:

kind: Service
apiVersion: v1
metadata:
name: myservice
namespace: default
selfLink: /api/v1/namespaces/default/services/myservice
uid: 4af68af5-4082-4ffb-b11b-641d16b28f31
resourceVersion: '1315842'
creationTimestamp: '2020-08-13T11:00:53Z'
labels:
app: myservice
app.kubernetes.io/managed-by: Helm
chart: myservice-1.0.0
heritage: Helm
release: vanilla
annotations:
meta.helm.sh/release-name: vanilla
meta.helm.sh/release-namespace: default
spec:
ports:
- name: http
protocol: TCP
port: 5000
targetPort: 5000
selector:
app: myservice
clusterIP: 10.0.225.85
type: ClusterIP
sessionAffinity: None
status:
loadBalancer: {}
bamishr
  • 410
  • 1
  • 6
  • 23

2 Answers2

2

Inside the Kubernetes system is a control loop which evaluates the selector of every Service and saves the results into a corresponding Endpoints object. So a good place to debug if your service side is fine is to look at the Pods being selected by the Service. Selector labels should be the labels defined on pods.

kubectl get pods -l app=myservice

If you get results, look at the RESTARTS column if pods are restarting, if pods are restarting there could be intermittent connectivity issues.

If you are not getting results it could be due to wrong selector labels. Verify labels on pods by running the command

kubectl get pods -A --show-labels

A good point of reference is https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/

slashpai
  • 1,141
  • 7
  • 12
2

It's common behavior and might happen when you try to deploy resources by copy-pasting manifests including metadata fields like creationTimeStamp, resourceVersion, selfLink etc.

Those fields are generated before the object is persisted. It appears when you attempt to update the resource that has been already updated and the version has changed so it refuses to update it. The solution is to check your yamls and apply must-have objects without specifying fields populated by the system.

kool
  • 3,214
  • 1
  • 10
  • 26