Ingress-nginx: kubectl ingress-nginx plugin improvements

[ElvinEfendi]

In 0.23.0 we have introduced a new kubectl plugin for ingress-nginx thanks to @alexkursell. It's bare minimum and we can now add more commands, and refine it. Please comment what you would want to see in that plugin to support then I'll include it in the following list.

• [x] kubectl ingress-nginx exec command to execute a command on an ingress-nginx pod
• [x] kubectl ingress-nginx logs command that's just like kubectl logs but does not require to provide pod name
• [ ] tbd

[aledbf]

• [x] kubectl ingress-nginx ingresses should have another column with the number of endpoints of the service

[alexkursell]

• [x] kubectl ingress-nginx ssh might also be a good idea. Essentially just running kubectl exec -it -n <NAMESPACE> <POD> -- /bin/bash.

[Evesy]

Being able to specify the Nginx service/pod names would be useful, since we run more than one controller in a namespace the service/pod names don't match the defaults set here: https://github.com/kubernetes/ingress-nginx/blob/2fcbcbcb8bf8423e0364ef9c92bf949d8abb3d8c/cmd/plugin/request/request.go#L33-L36

Being able to store these in a config file would be useful too

[aledbf]

It could be interesting if we can provide a command to check if some change is required to an ingress before the update to the new version (like the rewrite-target change) to avoid the report of issues after an update. Also, check for invalid/deprecated annotations.

[alexkursell]

Just for reference, the following of the above features have been implemented:

• [x] kubectl ingress-nginx exec
• [x] kubectl ingress-nginx logs
• [x] kubectl ingress-nginx ssh
• [x] --deployment and --service flags
• [x] ENDPOINTS column for kubectl ingress-nginx ingresses

@aledbf Regarding the idea of checking if changes are required to update, here's an idea as to how this could be done:

• Add a new command with a name like validate, lint, or check that contains a bunch of lints checking for one specific thing. Examples being deprecated annotation/configmap values, deprecated/removed config flags, checks for things like if an ingress with rewrite-target contains a path without a capture group, etc.
• Every release, add the new changes/deprecations as new lints to the subcommand. That way people can just run krew update, run the validate command pointed at their clusters, and get a list of every place they might have to update.

[aledbf]

validate, lint, or check

Maybe something more specific to the check for update process? (naming is hard :smile:)

[alexkursell]

(naming is hard 😄)

Yup :-). I'll just pick something long and we can bikeshed in the actual PR.

[aledbf]

Using this script https://github.com/kubernetes/ingress-nginx/issues/3457#issuecomment-455593401 from a job can help to troubleshoot the ingress controller pods

Edit: like this approach https://github.com/iovisor/kubectl-trace/blob/master/pkg/tracejob/job.go

[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.

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

[tallaxes]

Support DaemonSet-based deployment (currently appears to look specifically for Deployment)