Skip to content

Specify NodePort in "kubectl expose" command #25478

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

Closed
hvalls opened this issue May 11, 2016 · 20 comments
Closed

Specify NodePort in "kubectl expose" command #25478

hvalls opened this issue May 11, 2016 · 20 comments
Labels
area/kubectl lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/backlog Higher priority than priority/awaiting-more-evidence. sig/cli Categorizes an issue or PR as relevant to SIG CLI.

Comments

@hvalls
Copy link

hvalls commented May 11, 2016

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
Copy link

@bgrant0607 wdyt?

@smarterclayton
Copy link
Contributor

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

@thockin
Copy link
Member

thockin commented May 12, 2016

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
Copy link
Author

hvalls commented May 12, 2016

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
Copy link
Member

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

@bgrant0607 bgrant0607 added help-wanted priority/backlog Higher priority than priority/awaiting-more-evidence. area/kubectl labels May 12, 2016
@k8s-github-robot k8s-github-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label May 31, 2017
@0xmichalis
Copy link
Contributor

/sig cli

@k8s-ci-robot k8s-ci-robot added the sig/cli Categorizes an issue or PR as relevant to SIG CLI. label Jun 20, 2017
@k8s-github-robot k8s-github-robot removed the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Jun 20, 2017
@fejta-bot
Copy link

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

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 29, 2017
@fejta-bot
Copy link

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

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jan 28, 2018
@thockin thockin closed this as completed Feb 1, 2018
@charpty
Copy link

charpty commented Apr 20, 2018

@hvalls hi, how did you solve this problem?

@hvalls
Copy link
Author

hvalls commented Apr 20, 2018

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

@mkasep
Copy link

mkasep commented Jul 20, 2018

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

@odedpriva
Copy link

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
Copy link

Here's how I managed to do it:

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

@cawoodm
Copy link

cawoodm commented Feb 11, 2022

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
Copy link

cawoodm commented Feb 11, 2022

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
Copy link

ultraasi-atanas commented Feb 22, 2022

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
image

@alkdese
Copy link

alkdese commented Apr 7, 2022

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
Copy link

carlosjmarin commented Oct 4, 2023

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
Copy link

esgn commented Oct 10, 2023

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

@thockin
Copy link
Member

thockin commented Oct 10, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kubectl lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/backlog Higher priority than priority/awaiting-more-evidence. sig/cli Categorizes an issue or PR as relevant to SIG CLI.
Projects
None yet
Development

No branches or pull requests