Open Aonodensetsu opened 5 months ago
I am actually planning on switching docker over to using the socket instead as its API is more "robust" and easier to handle interfacing with docker.
That said, I don't hate this idea. Would you be open to providing some guidance with it? I have effectively 0 experience with kubernetes.
As an aside I am unsure if this would be a core provider or a 3rd party one (IE part of netman.nvim or a standalone extension that is dependent on netman.nvim). I think the answer to that would be "how painful is this to setup and will it require external dependencies (aside from netman)?"
sorry lol
kubectl get pods -o yaml(/json)
gets all the pod info in yaml/json, pods have docker containers in them
kubectl exec --stdin --tty POD_NAME -- /bin/bash
gets you an interactive shell, as you might imagine the last argument is a command to run inside the container
the containers usually don't have much in them, as is the case with docker, so the commands are limited, but the standard ones should be there, most of the time
if someone's working with kubernetes, they will have kubectl installed it also has an api but auth shit's not worth dealing with
That all makes sense. Consider this something that will eventually get addressed. Creating a new provider is a ton of work, and it will be more so for me as I don't have a ton of experience with kubernetes lol. I do think there is value in this though so it will get done eventually. No idea by who or when though.
Similarly to the Docker provider, allow exploring Kubernetes resources. I assume the docker provider uses exec, so
kubectl exec
is a similar interface for kubernetes - at least for the pods.