.kube config: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(22 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]], [[#User|users]] and [[#Contexts|contexts]]. The content of the file can be displayed with:
<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 21: Line 22:
   name: docker-desktop
   name: docker-desktop
</syntaxhighlight>
</syntaxhighlight>
==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 32: Line 39:
     client-certificate-data: LS0tL...LS0K
     client-certificate-data: LS0tL...LS0K
     client-key-data: LS0tL...tLQo=
     client-key-data: LS0tL...tLQo=
- name: test-admin
  user:
    password: M1...0K
    username: admin
</syntaxhighlight>
</syntaxhighlight>
==User Operations==
===Adding a User===
Simply add the section to  $HOME/.kube/config. Also see: {{Internal|Kubernetes_User_Operations#Create_a_Normal_User|User Operations &#124; 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 47: 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 53: 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 62: Line 85:


  kubectl [[Kubectl_config#use-context|config use-context]] ''new-context-name''
  kubectl [[Kubectl_config#use-context|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===
<FONT COLOR=DARKGRAY>TODO</FONT>


=Creating a Client Configuration from Scratch=
=Creating a Client Configuration from Scratch=
Line 98: 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:

User Operations | Create a Normal User

Contexts

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. 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.