.kube config: Difference between revisions
(18 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
* [[Kubernetes Configuration#Subjects|Kubernetes Configuration]] | * [[Kubernetes Configuration#Subjects|Kubernetes Configuration]] | ||
* [[Kubectl#Configuration|kubectl]] | * [[Kubectl#Configuration|kubectl]] | ||
* [[Amazon_EKS_Concepts#.kube.2Fconfig_Configuration|EKS .kube/config]] | |||
=Overview= | =Overview= | ||
<tt>$HOME/.kube/config</tt> is <tt>[[Kubectl#Configuration|kubectl]]</tt> configuration file. It contains definitions for [[#Cluster|clusters]], [[# | <tt>$HOME/.kube/config</tt> is <tt>[[Kubectl#Configuration|kubectl]]</tt> configuration file. It contains definitions for [[#Cluster|clusters]], [[#Users|users]] and [[#Contexts|contexts]]. The content of the file can be displayed with: | ||
kubectl [[Kubectl_config#view|config view]] | kubectl [[Kubectl_config#view|config view]] | ||
Line 23: | Line 24: | ||
==Cluster Operations== | ==Cluster Operations== | ||
===List all Clusters=== | |||
kubectl config get-clusters | |||
=Users= | =Users= | ||
The "users" section of $HOME/.kube/config contains definitions of users that might have different levels of permissions for each cluster. Each user definition has a friendly name, a username and a set of credentials. | The "users" section of $HOME/.kube/config contains definitions of users that might have different levels of permissions for each cluster. Each user definition has a friendly name, a username and a set of credentials. The credentials are the certificate the user needs to connect to the API server. In OpenShift's case, the original content of ~/.kube/config for the Unix root account of the master server is created by copying it from /etc/openshift/master/admin.kubeconfig. | ||
<syntaxhighlight lang='yaml'> | <syntaxhighlight lang='yaml'> | ||
Line 43: | Line 48: | ||
===Adding a User=== | ===Adding a User=== | ||
Simply add the section to $HOME/.kube/config. | Simply add the section to $HOME/.kube/config. Also see: {{Internal|Kubernetes_User_Operations#Create_a_Normal_User|User Operations | Create a Normal User}} | ||
=Contexts= | =Contexts= | ||
{{External|https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/#context}} | |||
Contexts bring together clusters and users under a friendly name. The contexts are declared in the "contexts" section of $HOME/.kube/config. | Contexts bring together clusters and users under a friendly name. The contexts are declared in the "contexts" section of $HOME/.kube/config. They are represented by a formal syntax element ("context"), which has three parameters: cluster, namespace and user. | ||
<syntaxhighlight lang='yaml'> | <syntaxhighlight lang='yaml'> | ||
Line 58: | Line 64: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
==All Contexts== | ==Current Context== | ||
At any moment, there's a context that is "current" - meaning that all [[kubectl]] invocations are directed to the cluster designated by the current context, with the identity set as part of the current context. | |||
==Context Operations== | |||
===List All Contexts=== | |||
All contexts can be obtained with: | All contexts can be obtained with: | ||
Line 64: | Line 76: | ||
kubectl config get-contexts | kubectl config get-contexts | ||
==Current Context== | ===Show Current Context=== | ||
The current context can be viewed with: | The current context can be viewed with: | ||
Line 74: | Line 86: | ||
kubectl [[Kubectl_config#use-context|config use-context]] ''new-context-name'' | kubectl [[Kubectl_config#use-context|config use-context]] ''new-context-name'' | ||
==Delete a Context== | ===Set a Current Context=== | ||
kubectl config use-context <''context-name''> | |||
===Delete a Context=== | |||
kubectl config delete-context <''context-name''> | kubectl config delete-context <''context-name''> | ||
===Rename a Context=== | |||
<FONT COLOR=DARKGRAY>TODO</FONT> | |||
=Creating a Client Configuration from Scratch= | =Creating a Client Configuration from Scratch= | ||
Line 113: | Line 133: | ||
The user client-key-data is obtained <font color=darkgray>as follows.</font> | The user client-key-data is obtained <font color=darkgray>as follows.</font> | ||
=<span id='Multiple_Configuration_Files'></span>KUBECONFIG and Multiple Configuration Files= | |||
kubectl first look at the the <code>KUBECONFIG</code> environment variable to determine where its configuration is. As such, different terminals (environments) can set the value of the environment variable differently and access different '''sets''' of Kubernetes contexts: | |||
<syntaxhighlight lang='bash'> | |||
export KUBECONFIG=~/some-kubeconfig | |||
</syntaxhighlight> | |||
This way you can set up different terminals "dedicated" to different clusters. | |||
=.kube/config and OpenShift= | |||
OpenShift [[oc]] updates .kube/config during the [[oc login]] operation. |
Latest revision as of 02:08, 5 March 2021
Internal
Overview
$HOME/.kube/config is kubectl configuration file. It contains definitions for clusters, users and contexts. The content of the file can be displayed with:
kubectl config view
Clusters
The "clusters" section of $HOME/.kube/config contains the definition of one or more clusters. Each cluster definition has a name, certificate info and the API server's endpoint.
clusters:
- cluster:
certificate-authority-data: LS0tLS1...tLQo=
server: https://kubernetes.docker.internal:6443
name: docker-desktop
Cluster Operations
List all Clusters
kubectl config get-clusters
Users
The "users" section of $HOME/.kube/config contains definitions of users that might have different levels of permissions for each cluster. Each user definition has a friendly name, a username and a set of credentials. The credentials are the certificate the user needs to connect to the API server. In OpenShift's case, the original content of ~/.kube/config for the Unix root account of the master server is created by copying it from /etc/openshift/master/admin.kubeconfig.
users:
- name: docker-desktop
user:
client-certificate-data: LS0tL...LS0K
client-key-data: LS0tL...tLQo=
- name: test-admin
user:
password: M1...0K
username: admin
User Operations
Adding a User
Simply add the section to $HOME/.kube/config. Also see:
Contexts
Contexts bring together clusters and users under a friendly name. The contexts are declared in the "contexts" section of $HOME/.kube/config. They are represented by a formal syntax element ("context"), which has three parameters: cluster, namespace and user.
current-context: docker-desktop
contexts:
- context:
cluster: docker-desktop
user: docker-desktop
name: docker-desktop
Current Context
At any moment, there's a context that is "current" - meaning that all kubectl invocations are directed to the cluster designated by the current context, with the identity set as part of the current context.
Context Operations
List All Contexts
All contexts can be obtained with:
kubectl config get-contexts
Show Current Context
The current context can be viewed with:
kubectl config current-context
and can be changed with:
kubectl config use-context new-context-name
Set a Current Context
kubectl config use-context <context-name>
Delete a Context
kubectl config delete-context <context-name>
Rename a Context
TODO
Creating a Client Configuration from Scratch
This procedure is useful if we install kubectl only on a remote client machine and we need it to configure it to connect to a Kubernetes cluster.
- Download kubectl and install it as described here: kubectl Installation.
- Create a ~/.kube directory.
- Create a ~/.kube/config file with the following content:
apiVersion: v1
kind: Config
clusters:
- name: kubernetes-kubespray
cluster:
certificate-authority-data: LS0tL...LQo=
server: https://10.10.2.146:6443
users:
- name: kubernetes-kubespray-admin
user:
client-certificate-data: LS0t...tLQo=
client-key-data: LS0tLS...S0tLQo=
contexts:
- name: kubernetes-kubespray
context:
cluster: kubernetes-kubespray
user: kubernetes-kubespray-admin
current-context: kubernetes-kubespray
preferences: {}
The cluster certificate-authority-data is obtained as follows.
The user client-certificate-data is obtained as follows.
The user client-key-data is obtained as follows.
KUBECONFIG and Multiple Configuration Files
kubectl first look at the the KUBECONFIG
environment variable to determine where its configuration is. As such, different terminals (environments) can set the value of the environment variable differently and access different sets of Kubernetes contexts:
export KUBECONFIG=~/some-kubeconfig
This way you can set up different terminals "dedicated" to different clusters.
.kube/config and OpenShift
OpenShift oc updates .kube/config during the oc login operation.