Specify NodePort in "kubectl expose" command

[hvalls]

If Service type is NodePort, it would be desirable to specify the nodePort in command kubectl expose.

Example:
kubectl expose rc example-rc --type=NodePort --port=9000 --target-port=8080 --node-port=32001

If you define a Service declaratively, in a yaml file, you use the field spec.ports[*].nodePort to achieve it. But, if it is not possible to create a declarative Service, there is not a way to specify the nodePort.

[adohe-zz]

@bgrant0607 wdyt?

[smarterclayton]

We've been discussing recently that expose has too many options. If we have create service, do we need this in expose?

[thockin]

I'd much prefer that create service be the place where we accumulate
flag-per-field sorts of things. Expose is supposed to be simple. That
said, this flag is not egregious to me, since there's ample precedent

On Wed, May 11, 2016 at 7:17 PM, Clayton Coleman notifications@github.com
wrote:

We've been discussing recently that expose has too many options. If we
have create service, do we need this in expose?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#25478 (comment)

[hvalls]

I didn't know of the existence of the feature create service. So I'm agree with place it in kubectl create service.

I'd much prefer that create service be the place where we accumulate
flag-per-field sorts of things. Expose is supposed to be simple. That
said, this flag is not egregious to me, since there's ample precedent

[bgrant0607]

I'd also like to add --edit to expose (and to run, create), which would allow someone to add arbitrary fields that didn't have flags. #18064

[0xmichalis]

/sig cli

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[charpty]

@hvalls hi, how did you solve this problem?

[hvalls]

@charpty Actually, I didn't. I just used the declarative way, automating yml generation.

[mkasep]

@hvalls So besides te declarative way, there is no other way to describe a nodeport on a single command?

[odedpriva]

you can do something like that

kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort  --overrides '{ "apiVersion": "v1","spec":{"ports":[{"port":80,"protocol":"TCP","targetPort":8080,"nodePort":30031}]}}'

you can also add --dry-run -o yaml to check validate the service object that will be created.

[Sher-Chowdhury]

Here's how I managed to do it:

kubectl create service nodeport myservice --node-port=31000 --tcp=3050:80

[cawoodm]

kubectl create service nodeport myservice --node-port=31000 --tcp=3050:80

This doesn't seem to be well documented. How do you specify which pods you are selecting?

[cawoodm]

Expose is supposed to be simple.

Expose already offers 2 ports, one of which (port) is superfluous for nodeports since we only care about the nodePort and the targetPort. Adding one more port would really help everyone confronted with the thousands of tutorials using kubectl expose which don't mention that you can't specify a nodeport.

[ultraasi-atanas]

kubectl create service nodeport myservice --node-port=31000 --tcp=3050:80

This doesn't seem to be well documented. How do you specify which pods you are selecting?

I don't think you do - that's another issue that's documented - #46191, as @mmumshad pointed out, this will not use the pods labels as selectors, instead it will assume selectors as app=myservice so generate the file and modify the selectors before creating the service

[alkdese]

I'd much prefer that create service be the place where we accumulate flag-per-field sorts of things. Expose is supposed to be simple. That said, this flag is not egregious to me, since there's ample precedent

On Wed, May 11, 2016 at 7:17 PM, Clayton Coleman notifications@github.com wrote:

We've been discussing recently that expose has too many options. If we
have create service, do we need this in expose?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#25478 (comment)

expose already simple and very nice coz I do not need specify selectors it does that for me. But what I do not like is that coz I can't specify nodeport I need to do more jumps review labels and add selector. I wish --node-port was there. Do not use if you don't need it

[carlosjmarin]

Seems cumbersome to have to create a service for this imparatively, has there been a plan to add nodeport as an option to expose?

[esgn]

Would be helpful to have such and option directly in expose or k create service

[thockin]

kubectl create service has weird semantics. As far as I can tell it doesn't even take a selector, which makes it awkward to use.

kubectl expose has weird semantics, too (only one port flag) but is closer.

Choosing a specific nodeport is very uncommon, so there's not much demand for it.

All of these CLI modes are sort of "toys". Good for kicking the tires but probably not what you want in prod. kubectl {apply | create | replace} support everything.

That said, I would not object to adding this to expose (with the current weird semantics), or to fixing expose to be less weird, or to fixing create service to take a selector.

KEPs welcome.