You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During minikube start, minikube populates the host ~/.kube/config file with the data needed for kubectl and other Kubernetes clients to connect to the Kubernetes instance running in the minikube VM.
There are three specific members of this file which are populated with absolute paths to other required files:
clusters.cluster.certificate-authority
users.user.client-certificate
users.user.client-key
Typically the values of these three members are ca.crt, client.crt, and client.key respectively in the host's ~/.minikube/ directory.
However, the official format of the .kube/config file allows these three members to be specified with a -data suffix instead and the value being a base-64 encoding of the certificate/key data instead of a file reference.
The benefit of embedding the certificates and keys directly into .kube/config means that users of Minikube on Windows can then copy (or symlink) their C:\Users\someone\.kube\config file directly to ~/.kube/config inside their Windows Subsystem for Linux (WSL) environment and use Linux builds of kubectl and other Kubernetes clients inside the WSL environment immediately.
With the current non-embedded implementation, WSL users must rewrite the absolute paths inside .kube/config from Windows paths to WSL-suitable paths and repeat this each time the config file changes (e.g. minikube VM IP changes, additional minikube profiles).
While this is an arguably niche use case, the use of certificates embedded in .kube/config is standard Kubernetes and should continue to work on all platforms with no impact to those not using WSL.
The text was updated successfully, but these errors were encountered:
FEATURE REQUEST
During
minikube start
, minikube populates the host~/.kube/config
file with the data needed forkubectl
and other Kubernetes clients to connect to the Kubernetes instance running in the minikube VM.There are three specific members of this file which are populated with absolute paths to other required files:
clusters.cluster.certificate-authority
users.user.client-certificate
users.user.client-key
Typically the values of these three members are
ca.crt
,client.crt
, andclient.key
respectively in the host's~/.minikube/
directory.However, the official format of the
.kube/config
file allows these three members to be specified with a-data
suffix instead and the value being a base-64 encoding of the certificate/key data instead of a file reference.This embedding approach is used by
kubectl config set-credentials --embed-certs
and also by the Kubernetes deployment included with Docker for Windows 18.02 CE Edge.The benefit of embedding the certificates and keys directly into
.kube/config
means that users of Minikube on Windows can then copy (or symlink) theirC:\Users\someone\.kube\config
file directly to~/.kube/config
inside their Windows Subsystem for Linux (WSL) environment and use Linux builds ofkubectl
and other Kubernetes clients inside the WSL environment immediately.With the current non-embedded implementation, WSL users must rewrite the absolute paths inside
.kube/config
from Windows paths to WSL-suitable paths and repeat this each time the config file changes (e.g. minikube VM IP changes, additional minikube profiles).While this is an arguably niche use case, the use of certificates embedded in
.kube/config
is standard Kubernetes and should continue to work on all platforms with no impact to those not using WSL.The text was updated successfully, but these errors were encountered: