Provide easy debug network access to services #1863
Labels
area/api
Indicates an issue on api area.
area/usability
priority/awaiting-more-evidence
Lowest priority. Possibly useful, but not yet enough support to actually get it done.
sig/api-machinery
Categorizes an issue or PR as relevant to SIG API Machinery.
Comments
|
I think the main issue with the master proxy is that it requires auth. Basically we need some standard gateway providing utilities. |
|
Bastions are also touched upon in #1513 (ssh), at least for individual pods (as opposed to services). |
|
It would be nice to be able to combine external ips, a bastion (for some sort of auth), and a service for "just-in-time external port exposure". Or alternatively, be able to start an ssh proxy pod that can forward port traffic on demand inside a namespace, add an external ip/port for it, and generate a one time key for the user with that pod. Seems like for debugging you want a secure external port, not just the gateway. |
bgrant0607
added
the
sig/network
goltermann
added
the
priority/backlog
This was referenced Jan 31, 2015
bgrant0607
added
area/api
|
#5763 is setting the stage for making this easily secured via the bastion. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now when you start a service it is available on the service IP port from within the kubernetes cluster. But hitting that service from the outside is really hard.
@lavalamp introduced an HTTP proxy through the master (
api/v1beta1/proxy/services/servicename) but there will be times when a more direct access pattern is needed.One solution is to claim a host port and look up what minion a pod landed on. That won't be stable if the minion gets rescheduled.
Another idea is to introduce an idea of a 'cluster debug port' and run a TCP proxy on perhaps the master that'll do TCP (and UDP?) forwarding to the service for that port.
The text was updated successfully, but these errors were encountered: