Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replacing ClusterIP service with NodePort service fails #24040

Closed
wombat opened this issue Apr 8, 2016 · 8 comments
Closed

Replacing ClusterIP service with NodePort service fails #24040

wombat opened this issue Apr 8, 2016 · 8 comments

Comments

@wombat
Copy link

wombat commented Apr 8, 2016

It had a service with type ClusterIP and wanted to switch it to type NodePortand it failed with the following message:
`The Service "xyz" is invalid.
spec.clusterIP: Invalid value: "": field is immutable``

I deleted the existing service and created the new one which worked fine.

@wombat wombat changed the title Replacing ClusterIP Service with NodePort service fails with Replacing ClusterIP Service with NodePort service fails Apr 8, 2016
@wombat wombat changed the title Replacing ClusterIP Service with NodePort service fails Replacing ClusterIP service with NodePort service fails Apr 8, 2016
@bprashanth
Copy link
Contributor

How did you change it? sounds like you tried to apply an update with clusterIP=="" whereas the Service in the apiserver already had a clusterIP.

Fyi the easiest way to update a Service is simply to run kubectl edit svcName, and change the one field (in this case Type from ClusterIP to NodePort).

@wombat
Copy link
Author

wombat commented Apr 8, 2016

I just did a kubectl replace .... Using ´kubectl edit` from a CI is not possible so I just wanted to replace the service completely.
At first it looked like this:

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  ports:
    - port: 80
      targetPort: 80
  selector:
    name: webapp

afterwards:

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
  selector:
    name: webapp

@bprashanth
Copy link
Contributor

A simple replace will try to update (get and re-put) which will try to preserve the clusterIP. A replace --force will delete and create. Does that work?

@wombat
Copy link
Author

wombat commented Apr 8, 2016

I can try later but I don´t understand why switching to NodePort leads to an error - I haven´t deleted the ip or similar.

@bprashanth
Copy link
Contributor

Without debugging too deep I believe it's because kubectl replace will do a GET followed by a PUT. The put therefore has the ClusterIP set to some non "" value (the same value it's currently set to in etcd). This causes an update violation.

You can confirm by running kubectl replace blah --v=7 and observing the REST calls.

One might argue that this behavior is unexpected, or that we should allow the same value to pass through etc, @kubernetes/kubectl

@sheerun
Copy link

sheerun commented Apr 11, 2016

Maybe you could implement "destroy-handlers" for some keys. e.g. handler that runs when ClusterIP is changed to some other property and sets clusterIP to default value.

@thockin
Copy link
Member

thockin commented Apr 16, 2016

replace is a full replacement, not a patch. It is invalid to change ClusterIP, and in this case you are changing it from a value to "". To replace a Service you really have to do an R-M-W cycle. Get it, apply mutations, then write it back.

@thockin thockin closed this as completed Apr 18, 2016
grebois added a commit to grebois/charts that referenced this issue Aug 29, 2018
…dBalancer

`Service is invalid: spec.clusterIP: Invalid value: "None": may not be set to 'None' for LoadBalancer services`

Relates to kubernetes/kubernetes#33766 kubernetes/kubernetes#24040 kubernetes/kubernetes#33036

Signed-off-by: grebois <grebois@gmail.com>
@tej1997
Copy link

tej1997 commented Feb 18, 2020

commenting out the "nodePort:" worked for me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants