Using Bridge to K8s to debug minikube on VMWare

[SillyCode]

Hi all,

I have a Win10 host system on which I'm running a VMware Workstation Debian VM.
This VM has Docker and Minikube (started with driver=none) running and all works quite well.

My question is. Is it possible to debug an application running on the Minikube cluster (on the VM)
from the Visual Studio on win10 using the "Bridge to Kubernetes"?

Thank you

[afbjorklund]

I think the none driver still binds to all interfaces, rather than localhost, so you can (ab)use that...
Instead of the regular 127.0.0.1, you use the VM IP. Eventually that bug will be fixed though: #4313

https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/

Otherwise when accessing a kubernetes cluster on a remote host, one normally uses SSH tunnels.
So you tunnel to the machine using minikube, either forwarding the 8443 port or use kubectl proxy

https://kubernetes.io/docs/tasks/extend-kubernetes/http-proxy-access-api/

---

In the future, using the ssh drivers will make it easier to use remote clusters such as this one.

Since it will set up your local kubernetes config, instead of doing it on the control plane.

See #4733 (comment) for the reasoning behind the new driver, and how it completes "none".

The obvious alternative would otherwise be to run your IDE on the Debian VM with minikube.

[SillyCode]

As far as I understand VS unable to access the VM even if I copy the K8S config file over the host.
And using the VM IP address, still does not seem to get me to where I want to be. See image below:

Also, not sure how do I make use of kubectl proxy for my benefit.

Resorted to using the VS Code IDE with Bridge to Kubernetes and remote debugging for now with .Net.
Not the greatest solution but at least it works

[afbjorklund]

I think this could be a good topic for a tutorial, how to connect to a remote computer running minikube...

Like how to do it properly, without opening up unnecessary things on the machine for remote access.

The plan was to forward the port over the ssh connection, and then start kubectl proxy on the VM.

ssh -L 8001:127.0.0.1:8001 ...

                         _             _            
            _         _ ( )           ( )           
  ___ ___  (_)  ___  (_)| |/')  _   _ | |_      __  
/' _ ` _ `\| |/' _ `\| || , <  ( ) ( )| '_`\  /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )(  ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)

$ sudo KUBECONFIG=/etc/kubernetes/admin.conf /var/lib/minikube/binaries/v1.20.2/kubectl proxy
Starting to serve on 127.0.0.1:8001

in another terminal, on the host:

$ curl http://localhost:8001/api/
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.99.253:8443"
    }
  ]
$ minikube ip
192.168.99.253

Of course, if anyone has access to localhost that means the whole cluster is compromised as well.

[SillyCode]

Actually, connecting to the VM is not a problem. It has NAT and bridged net cards defined.
So we do have explicit and direct access to it over SSH and over port 80/443.
So you are able to access K8S services on your web browser without any tunneling.
But having the VS IDE connecting to the VM cluster is a different issue.

[afbjorklund]

minikube is only supposed to be available to the local learning environment, i.e. localhost

https://kubernetes.io/docs/setup/learning-environment/

Having it accessible for remote access makes it more like a regular production environment

https://kubernetes.io/docs/setup/production-environment/

[awhileback]

The whole point is to simulate an environment, which cannot be done if it refuses to talk to a network outside of the host it's running on.