-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Add kubectl plugin #3779
Add kubectl plugin #3779
Conversation
@alexkursell thank you for working on this! |
cmd/plugin/request/request.go
Outdated
|
||
const ( | ||
ingressPodName = "nginx-ingress-controller" | ||
ingressServiceName = "nginxcontrib-ingress" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ingressServiceName = ingress-nginx
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, true. I was testing on a cluster that changed the name of the service. I wonder if there is a way to "detect" an ingress-nginx deployment or service regardless of the name? Or maybe just adding a config flag would be better. Probably just adding a flag considering multiple ingress-nginx deployments or services can exist at a time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assume the default ingress-nginx/use the labels https://github.com/kubernetes/ingress-nginx/blob/master/deploy/provider/cloud-generic.yaml#L13
Those labels could be used to find the service/s and pod/s
@alexkursell can we dump the lua tables? (sticky session state for instance) |
That is on my list, along with dynamic cert info. I just have to add endpoints and a |
return nil | ||
}, | ||
} | ||
backendsCmd.Flags().String("pod", "", "Query a particular ingress-nginx pod") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens when we don't specify this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So regarding dumping lua tables, the only ones that are shared between all workers are the |
@ElvinEfendi any idea how can we dump this? (this could help with some of the issues with affinity) |
@alexkursell @ElvinEfendi can we think of adding redis to store some of the states as an option? (like the affinity). Also the rate limiting could benefit from this to have a global state and not per ingress controller pod |
6a3df5d
to
5f8a239
Compare
@aledbf I suggest we stick to existing minimal debugging features provided by dbg executable and ship the plugin first. We can then iterate and add more commands.
Please no redis :) It's a great advantage of ingress-nginx to not rely on any other storage component. What kind of states are you looking to get i.e in the case of session affinity debugging? |
how's this different that |
@alexkursell can we ship the first version without any of the TODOs you mentioned?
So if I pull your branch and build and install the plugin as you documented it won't work? What's the actual issue, maybe @aledbf can help with? |
|
kubectl ingress-nginx ingresses --all-namespaces
We get more information:
|
This is not related to debugging itself but an additional (optional) feature. Right now when we use rate limits or session affinity that only applies per pod, not to all the replicas in the deployment |
I see, it's a bit offtopic for this PR, but session affinity does not care about state because it's implemented using consistent hashing. So every Nginx replicas will behave the same. As to rate limit, yeah that's per replica/pod. I feel like this would be a great fit to be implemented as a plugin. |
@aledbf Right now, the plugin fails to authenticate on gcp clusters with the error
@ElvinEfendi I'd like to resolve the above issue, as right now the plugin is totally useless to anyone who uses gcp. As for e2e-tests and documentation, I suppose it's up to you and @aledbf how complete we want to be in this regard before merging. But in terms of the extra features listed there, we can definitely leave them to another PR. |
Please check https://github.com/kubernetes/client-go/tree/master/examples#auth-plugins |
@alexkursell @ElvinEfendi I am fine with the state of this PR as the first version. |
Sounds like a plan! That'll give us a chance to polish the plugin and make it more useful for large audience. |
663da49
to
ad3c9bb
Compare
38e2196
to
864a85e
Compare
I think that this is ready for merge unless @ElvinEfendi or @aledbf think there is something else that needs to be done. |
build/build-plugin.sh
Outdated
|
||
|
||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you delete these redundant lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed. I should probably look into some linting tool that detects trailing newlines in text files.
cmd/plugin/ingress-nginx.yaml.tmpl
Outdated
os: windows | ||
arch: amd64 | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
@alexkursell can you also add minimal documentation on how to install and use this? Then squash the commits and we should be good to merge. |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
I don't think it does - @aledbf is this safe to ignore? |
ce772ab
to
9e424a4
Compare
Yes (at least for now) |
In that case I guess we're good to merge! |
/approved I'll let @aledbf to |
/approve |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aledbf, alexkursell, ElvinEfendi 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:
Approvers can indicate their approval by writing |
Nice work with this. I just wanted to put a comment here regarding the |
Apologies for this but this is on purpose. Starting in 0.24 dynamic certificates will be the default, and the static mode is going to be removed in 0.25. |
What this PR does / why we need it: This PR adds a kubectl plugin,
kubectl ingress-nginx
, that makes it easier to debug ingress-nginx. In the future, this plugin should also get the ability to add/remove/configure ingress-nginx deployments in a cluster (see https://gist.github.com/aledbf/db25dbc723fc7d71345a9657abfd766d). Right now, it just includes debugging functionality.Which issue this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close that issue when PR gets merged): fixes #3755Current features
kubectl ingress-nginx backends
, which basically can query the output of/dbg backends
inside ingress-nginx podskubectl ingress-nginx general
,kubectl ingress-nginx conf
, which do the same but for/dbg general
and/dbg conf
kubectl ingress-nginx ingress
which tries to output a table similar tokubectl get ingress
, but with richer information including hostnames, paths, whether or not a rule is protected by TLS, and backend name.kubectl ingress-nginx info
Pretty sparse right now, just prints the internal and external addresses of the ingress-nginx deployment.Packaging
The plugin binaries + krew manifest can be built using
make build-plugin
. Right now it builds for Linux, MacOS, and Windows, although I've only tested it on MacOS. Distributing the plugin would look something like this:ingress-nginx
release, runmake build-plugin
and commit the generatedcmd/plugin/release
directory.ingress-nginx.yaml
manifestTo-do
1.13.3
versions we have vendored now. I'm still trying to fix this. (edit: fixed by Update mergo dependency #3793)ingress-nginx
deployments as in https://gist.github.com/aledbf/db25dbc723fc7d71345a9657abfd766d. Although this may not be necessary for an MVP (edit: punting to a future PR)ingress-nginx
deployments that have names other thaningress-nginx
(edit: punting to a future PR)cc: @ElvinEfendi @aledbf