1. Switch between Minikue and Google Kubernetes Engine
Switch to Minikube
$minikube start
Starting local kubernetes cluster...
...
Setting up kubeconfig...
kubectl is now configured to use the cluster
After switching from Minikube to GKE, you can switch back by stopping Minikube and restarting. At this point kubectl will be reset again to apply to the Minikube cluster
Switch to GKE
$gcloud container clusters get-credentials my-gke-cluster
2. Use kubectl under multi-cluster or multi-namespace
If you need to switch between multiple kubernetes clusters, or want to work under a namespace outside of your namespace, but don't want to specify the --namespace option every time you run kubectl, you can do the following
1. Configure the path of the kubeconfig file
The configuration used by kubectl is usually stored in the ~/.kube/config file. If stored elsewhere, the environment variable KUBECONFIG needs to point to the location of the configuration file
You can let kubectl load all configurations at once by specifying multiple configuration files (separated by colons) in the KUBECONFIG environment variable
2. Understand the contents of the kubeconfig file
Example kubeconfig file
apiVersion:v1
clusters:
-cluster:
certificate-authority:/home/luksa/.minikube/ca.crt
server:https://192.168.99.100:8443
name: minikube
contexts:
-context:
cluster:minikube
user: minikube
namespace:default
name: minikube
current-context:minikube
kind:Config
preferences:{}
users:
name: minikube
user:
client-certificate:/home/luksa/.minikube/apiserver.crt
client-key:/home/luksa/.minikube/apiserver.key
The kubeconfig file consists of the following four parts:
- cluster list
- user list
- context list
- current context list
Each cluster, user and context has a name to distinguish it
cluster
The cluster entry represents the kuberrnetes cluster and contains the API server's URL, a certificate authority (CA) file, and possibly some other configuration options related to communicating through the API server. The CA certificate can be stored in a separate file and referenced in the kubeconfig file, or it can be included directly in the certificate-authority-data field.
users
Each user defines the credentials used when talking to the API server. This can be usernames and passwords, authentication tokens, and client keys and certificates. Certificates and keys can be included in the kubeconfig file (via the client-certificate-data and client-key-data properties), or stored in separate files and referenced in the configuration file.
context
A context associates the cluster, user, and default namespace that kubectl should use to execute commands. Multiple contexts can point to the same user or cluster.
current-context
Although multiple contexts can be defined in the kubeconfig file, only one of them is current at a time.
3. Query, add and modify kube configuration entries
This file can be manually edited to add, modify, and delete cluster, user, and context information, or via the kubectl config command.
Add or modify a cluster
The kubectl config set-cluster command adds a cluster
$kubectl config set-cluster my-other-cluster
return:
--server=http://k8s.example.com:6443
--certificate-authority=path/to/the/cafile
If the specified cluster name already exists, the set-cluster command will override the configuration options for the cluster with the same name
Add or modify user credentials
$kubectl config set-credentials foo --username=foo --password=pass
Use token-based authentication
$kubectl config set-credentials foo --tolen=mysecrettokenXFDJIQ1234
If you use the same credentials to authenticate against different clusters, you can customize a user and use it for both clusters
Link cluster and user credentials together
The context defines which user uses which cluster, and can also define the namespace that kubectl should use, so that there is no need to manually specify the namespace using the --namespace or -n options.
$kubectl config set-context some-context --cluster=my=other-cluster
return:
--user=foo --namespace=bar
This creates a context called some-context that uses the my-other=cluster cluster and the foo user credentials. The default namespace in the secondary context is set to bar
The same command can also be used to change the namespace of the current context.
$kubectl config current-context
Use the following command to modify the namespace
$kubectl config set-context minikube --namespace=another-namespace
4. Use kubectl in different clusters, users and contexts
When running kubectl commands, the cluster, user, and namespace defined in the current context of kubeconfig are used, but they can also be overridden with the following command options:
--user specifies a different user in a kubeconfig file
--username and --password specify different user names and passwords respectively (the user names and passwords do not need to be pre-defined in the configuration file), if you use other types of authentication, you can use --client-key, --client-certificate or- -token
--cluster specifies a different cluster (the cluster must be pre-defined in the configuration file)
--server specifies a different server url (one that does not exist in the configuration file)
--namespace specify a different namespace
5. Switch context
Additional contexts can be created using the set-context command and then switched between contexts
$kubectl config user-context my-other-context
This switches the current context to my-other-context
6. List contexts and clusters
$kubectl config get-contexts
7. Delete context and cluster
$kubectl config delete-config my-unused-context
and
$kubectl config delete-cluster my-old-cluster