Support running in an in-cluster self-hosted worker without separately setting context

Using a solution like summerwind/actions-runner-controller, it is possible to run a self-hosted worker in a Kubernetes cluster. This self-hosted worker can then use the Kubernetes service account the worker is running under to authenticate to the K8s API to eg. do deployment.

Azure/k8s-deploy instead insists on a “context” set by Azure/k8s-set-context. It cannot use or refuses to use the Kubernetes native service account authentication (ie. token and connection info mounted at /var/run/secrets/kubernetes.io/serviceaccount).

As a rule of thumb, I think if kubectl is able to run, Azure/k8s-deploy should be able to run. If you feel this is out of scope for k8s-deploy, alternatively k8s-set-context should be augmented to support the native way.

[japsu]

@koushdey My actions runner is running in a pod in a Kubernetes cluster. That pod is running on a service account that has the required access. If I were to run kubectl commands in that pod, they would use the Kubernetes credentials supplied to the pod by Kubernetes and succeed. k8s-set-context with the service account method asks for information that is not relevant or which I do not have in this use case.

[thesattiraju]

@koushdey inorder to support this, perhaps we could change the logic of throwing the error into a warning instead.

https://github.com/Azure/k8s-deploy/blob/acd12a47055b679be711e4937c41f1755316cfae/src/run.ts#L43-L47