kubectl create ingress #94327

rikatz · 2020-08-29T01:47:58Z

What type of PR is this?
/kind feature

What this PR does / why we need it: Add kubectl create ingress

Which issue(s) this PR fixes:
Fixes #93267

Special notes for your reviewer:

Discussion: https://groups.google.com/g/kubernetes-sig-network/c/QZYWzBFcU-s
Unit tests are pending, asking for the review of the code logic right now and if this is compliant with sig/cli guidelines
Because of the "complexity" of rules, there are some "strings split" in the code and also a Regex used for the rule validation. If sig-cli is ok with that maybe using named groups from the regex would be better than using that bunch of strings.split in the code.

Does this PR introduce a user-facing change?:

kubectl create now supports creating ingress objects.

TODO:

Unit tests
Write the necessary validations in Validate() method, like if the referenced secret or service exists (otherwise decide if issue a Warning or an Error)
Adjust the ingressExample (as this has been copied and adapted from create_deployment)
Add support for DefaultBackend
Add support for TLS flags
add support for TLS secret without host definition

/sig cli
/sig network

rikatz · 2020-09-09T23:42:53Z

Contextualization for a future me:
Ingress have a specific way of declaring multiple rules. One suggestion would be
to use kubectl create ingress --rule=host=lala.com,path=/,pathtype=prefix,svc-name=bla etc

This is really ugly. So Tim suggested some sort of 'positional' creation, with a 'loop' of

host - Can not be empty, if you want this empty use "_"
pathtype - Can only be one of the valid values below
path - The path you want to declare
service-name - The name of the backend service going to be used
TODO: This can also support a TypedLocalObjReference, but for the first pass, will leave
with only service support.
svc-port OR svc-port-name - The name or the int of the port of the backend

It's much like the suggested in #93267 (comment):

kubectl create ingress myingress \
    --host=myhost.com --pathtype=prefix --path=/foo
--service-name=foo-svc --service-port=80 \
    --host=yourhost.com --pathtype=prefix --path=/bar
--service-name=bar-svc --service-port-name=http

So some problems starts to appear:

One can have the same host with multiple path/backends. The solution here is to repeat
the same host again and again and again for each path. This needs to turn into something like
a map, with the key being all the hosts and the values being an array of the Paths/services/etc
How to assure that the positional order of each combination is the same of the array?
Like, I have a path[0] containing "/foo", and a path[1] containing "/bar", but
service-port[0] will be 80 and service-port-name[0] will be "http" so there's no
consistency. Maybe having only --service-port and checking if this is a int or a string, and
if it's a int32, convert it to int32 and insert in the correct struct of the rule spec
How 'ugly' is this?
How to assure each host gots its own pathtype, path, service-name and service-port?
This one seems to be easy, the len of each array should be equal
So I've found a major problem here: what if a user puts something like:

--host=myhost.com --pathtype=prefix --path=/foo \
    --service-port=80 \
--service-name=bar-svc --service-name=foo-svc --service-port-name=http \
    --host=yourhost.com --pathtype=prefix --path=/bar

So the thing here is that keeping the strict order is pretty hard.

I"m moving to the next suggestion, of having a SliceVar that splits every "," character (which should not be used in host, servicename, port, etc) and consider the ordering of that, as the following

                #  host[0]   host[1]
 --host=myhost.com,yourhost.com \
                     # pt[0]  pt[1]
    --pathtype=prefix,prefix --path=/foo,/bar \
    --service-name=foo-svc,bar-sve --service-port=80,80

rikatz · 2020-09-10T01:58:02Z

So there's a new version:

kubectl create ingress ingress-demo --ingress-class=xpto --host=\*.foo.com,bar.com,bar.com --path=/,/locationx,/locationy --pathtype=Prefix,Exact,ImplementationSpecific --service-name=svc1,svc2,svc2 --service-port=8080,9999,redis```

This is going to create an Ingress

With IngressClass = xpto
2 Rules
- *.foo.com with a location "/" pointing to svc1:8080 and PathType=Prefix
- bar.com with a location "/locationx" pointing to svc2:9999 and PathType=Exact, and other location "/locationy" pointing to svc2:redis (named port for ingress controllers that support this), and PathType=ImplementationSpecific

Still need to create the default-backend and the tls flag, but this seems to cover a lot of cases.

rikatz · 2020-09-10T02:02:59Z

/priority backlog

rikatz · 2020-09-28T00:21:21Z

/auto-cc

rikatz · 2020-10-07T22:15:23Z

/hold cancel

rikatz · 2020-10-09T17:14:58Z

@soltysh thanks!

Removed some leading empty lines, tried to make the regex as much descriptive as possible, and corrected the error.

jayunit100 · 2020-10-11T15:09:24Z

just tested this locally, seems to work reasonably well for me. I've added a PR to validate the "basic" scenario (single endpoint with a secret) as the first help option, and also to instantly reject the kubectl create ingress x command (since otherwise you get a more cryptic backend validation error that isn't capable of being option-aware)
seems to work nicely for me with contour ! thanks @rikatz !

jayunit100 · 2020-10-11T15:10:09Z

staging/src/k8s.io/kubectl/pkg/cmd/create/create_ingress.go

+
+	ingressExample = templates.Examples(i18n.T(`
+		# Create a catch all ingress pointing to service svc:port and Ingress Class as "otheringress"
+		kubectl create ingress catch-all --class=otheringress --rule="_/=svc:port"


maybe an even simpler first example, mad. a PR for this to your fork . that _ is confusing and, its nice to see quickly that you can add secrets as well since that's usually the thing people need to do (a single service w/ a pls)

minor so feel free to ignore me on this one :)

Is the _ really needed? host.com/foo and /foo are not ambiguous...

The idea of _ was exactly to remove the ambiguity before I started using the regex. But yes, this might be an improvement. Putting in my TODO for tomorrow, to check the impact on simply using "/foo" directly and verifying in the code if the len of the hostpath array is bigger than 1 then consider the first field as host and the second as path, otherwise just path :)

@thockin created a new PR to solve this (#95660) and also another...well... bug because in the final past I've removed the generators flag but forgot to add the dryrun flag and now the command simply panics

jayunit100 · 2020-10-11T15:12:03Z

staging/src/k8s.io/kubectl/pkg/cmd/create/create_ingress.go

+	cmdutil.AddValidateFlags(cmd)
+	cmdutil.AddGeneratorFlags(cmd, "")
+	cmd.Flags().StringVar(&o.IngressClass, "class", o.IngressClass, "Ingress Class to be used")
+	cmd.Flags().StringArrayVar(&o.Rules, "rule", o.Rules, "Rule in format host/path=service:port[,tls=secretname]. Paths containing the leading character '*' are considered pathType=Prefix. tls argument is optional.")


just a quick thought, is it common to look the TLS up or would it be helpful to provide feedback "this secret doesn't exist" yet if its not in the namespace? no strong opinion but if that's valuable I might be able to PR against it. its always a mistake I make, misnaming the secret.

I think it's 'hard' because when the secret doesn't exists Ingress Controllers (don't know if all of them) fallback into the default secret.

Also this would be useless when using dry-run, so IMO create should try to create the object and rely on the apiserver validation. If the api-server does not return an error/warning when you create an YAML with a non-existing secret, it should not return an error/warning when you use kubectl create command either :)

Also this was my first thought also, like 'should we validate the existence of a secret' but then I realized that for me, it doesn't make sense

rikatz · 2020-10-13T19:58:53Z

/hold cancel

soltysh

A couple of empty line nits, and generator flags for removal and you're good.
/approve

soltysh · 2020-10-15T11:28:07Z

staging/src/k8s.io/kubectl/pkg/cmd/create/create_ingress.go

soltysh · 2020-10-15T11:30:09Z

staging/src/k8s.io/kubectl/pkg/cmd/create/create_ingress.go

You don't need it

soltysh · 2020-10-15T11:30:25Z

staging/src/k8s.io/kubectl/pkg/cmd/create/create_ingress.go

Unnecessary empty line

soltysh · 2020-10-15T11:31:32Z

staging/src/k8s.io/kubectl/pkg/cmd/create/create_ingress.go

You do like having empty lines at the begining of functions 😉

k8s-ci-robot · 2020-10-15T11:32:56Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rikatz, soltysh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~staging/src/k8s.io/kubectl/OWNERS~~ [soltysh]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Signed-off-by: Ricardo Pchevuzinske Katz <[email protected]>

rikatz · 2020-10-15T12:18:38Z

/test pull-kubernetes-node-e2e

rikatz · 2020-10-15T13:01:55Z

/test pull-kubernetes-node-e2e

soltysh

/lgtm

k8s-ci-robot · 2020-10-15T14:44:32Z

@rikatz: The following test failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
pull-kubernetes-integration	`73aa0a9`	link	`/test pull-kubernetes-integration`

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

rikatz · 2020-10-15T14:50:48Z

/test pull-kubernetes-integration

k8s-ci-robot requested review from derekwaynecarr and zhouya0 August 29, 2020 01:48

k8s-ci-robot added the area/kubectl label Aug 29, 2020

k8s-ci-robot removed request for derekwaynecarr and zhouya0 August 29, 2020 01:50

rikatz marked this pull request as draft August 29, 2020 02:36

rikatz marked this pull request as ready for review September 10, 2020 02:00

k8s-ci-robot added priority/backlog Higher priority than priority/awaiting-more-evidence. and removed needs-priority Indicates a PR lacks a `priority/foo` label and requires one. labels Sep 10, 2020

rikatz changed the title ~~WIP: kubectl create ingress~~ kubectl create ingress Sep 28, 2020

k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 28, 2020

k8s-ci-robot requested review from mengqiy and shiywang September 28, 2020 00:21

k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Oct 6, 2020

rikatz mentioned this pull request Oct 7, 2020

Feature: kubectl create ingress #78153

Merged

rikatz force-pushed the create-ingress branch from 8c356ac to 61f77ac Compare October 9, 2020 17:13

jayunit100 suggested changes Oct 12, 2020

View reviewed changes

k8s-ci-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. do-not-merge/contains-merge-commits Indicates a PR which contains merge commits. labels Oct 13, 2020

rikatz force-pushed the create-ingress branch from dd2b1b2 to 806c827 Compare October 13, 2020 16:56

k8s-ci-robot removed the do-not-merge/contains-merge-commits Indicates a PR which contains merge commits. label Oct 13, 2020

rikatz force-pushed the create-ingress branch from 806c827 to 7d929e6 Compare October 13, 2020 17:10

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 13, 2020

rikatz force-pushed the create-ingress branch 2 times, most recently from e1a0704 to c7fda59 Compare October 13, 2020 18:42

k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 13, 2020

soltysh approved these changes Oct 15, 2020

View reviewed changes

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 15, 2020

rikatz force-pushed the create-ingress branch from c7fda59 to c6f298c Compare October 15, 2020 12:05

Add support for create ingress in kubectl

73aa0a9

Signed-off-by: Ricardo Pchevuzinske Katz <[email protected]>

rikatz force-pushed the create-ingress branch from c6f298c to 73aa0a9 Compare October 15, 2020 12:07

soltysh approved these changes Oct 15, 2020

View reviewed changes

k8s-ci-robot assigned soltysh Oct 15, 2020

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 15, 2020

k8s-ci-robot merged commit 35e20f1 into kubernetes:master Oct 15, 2020

k8s-ci-robot added this to the v1.20 milestone Oct 15, 2020

rikatz mentioned this pull request Apr 22, 2021

Fix validation in kubectl create ingress #101377

Merged

kubectl create ingress #94327

kubectl create ingress #94327

Uh oh!

Conversation

rikatz commented Aug 29, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rikatz commented Sep 9, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rikatz commented Sep 10, 2020

Uh oh!

rikatz commented Sep 10, 2020

Uh oh!

rikatz commented Sep 28, 2020

Uh oh!

rikatz commented Oct 7, 2020

Uh oh!

rikatz commented Oct 9, 2020

Uh oh!

jayunit100 commented Oct 11, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jayunit100 Oct 11, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rikatz commented Oct 13, 2020

Uh oh!

soltysh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

k8s-ci-robot commented Oct 15, 2020

Uh oh!

rikatz commented Oct 15, 2020

Uh oh!

rikatz commented Oct 15, 2020

Uh oh!

soltysh left a comment

Choose a reason for hiding this comment

Uh oh!

k8s-ci-robot commented Oct 15, 2020

Uh oh!

rikatz commented Oct 15, 2020

Uh oh!

Uh oh!

rikatz commented Aug 29, 2020 •

edited

Loading

rikatz commented Sep 9, 2020 •

edited

Loading

jayunit100 commented Oct 11, 2020 •

edited

Loading

jayunit100 Oct 11, 2020 •

edited

Loading