Specify NodePort in "kubectl expose" command

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.

@bgrant0607

@bgrant0607 wdyt?

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

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)

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

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

/sig cli

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

@hvalls

@hvalls hi, how did you solve this problem?

@charpty

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

@hvalls

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

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.

Here's how I managed to do it:

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

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?

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.

@mmumshad

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

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

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

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

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.

Navigation Menu

Repository navigation

Specify NodePort in "kubectl expose" command #25478

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Specify NodePort in "kubectl expose" command #25478

Description

Activity

adohe-zz commented on May 12, 2016

smarterclayton commented on May 12, 2016

thockin commented on May 12, 2016

hvalls commented on May 12, 2016

bgrant0607 commented on May 12, 2016

0xmichalis commented on Jun 20, 2017

fejta-bot commented on Dec 29, 2017

2 remaining items

charpty commented on Apr 20, 2018

hvalls commented on Apr 20, 2018

mkasep commented on Jul 20, 2018

odedpriva commented on Sep 4, 2018

Sher-Chowdhury commented on May 30, 2019

cawoodm commented on Feb 11, 2022

cawoodm commented on Feb 11, 2022

ultraasi-atanas commented on Feb 22, 2022

alkdese commented on Apr 7, 2022

carlosjmarin commented on Oct 4, 2023

esgn commented on Oct 10, 2023

thockin commented on Oct 10, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions