<p>In the world of kubectl and kubernetes config, what's the difference between context and a cluster? For example I see these commands:</p>

<pre><code>Available Commands:
  current-context Displays the current-context
  delete-cluster  Delete the specified cluster from the kubeconfig
  delete-context  Delete the specified context from the kubeconfig
  get-clusters    Display clusters defined in the kubeconfig
  get-contexts    Describe one or many contexts
  rename-context  Renames a context from the kubeconfig file.
  set             Sets an individual value in a kubeconfig file
  set-cluster     Sets a cluster entry in kubeconfig
  set-context     Sets a context entry in kubeconfig
</code></pre>

<p>and in .kube/config I see:</p>

<pre><code>- context:
    cluster: arn:aws:eks:us-west-2:91XXXXXXX71:cluster/ignitecluster
    namespace: ignite
    user: arn:aws:eks:us-west-2:91XXXXXXX71:cluster/ignitecluster
  name: arn:aws:eks:us-west-2: 91XXXXXXX71:cluster/ignitecluster
</code></pre>

<h3>Clusters</h3>

<p>Cluster is a place where all Kubernetes components, capabilities, and workloads are configured.</p>

<p>Clusters in Kubernetes are identified by their respective Certificate Authority (CA) certificates. For ex, let's say you have three clusters.</p>

<p><a href="https://i.stack.imgur.com/lSDDL.png" rel="noreferrer"><img src="https://i.stack.imgur.com/lSDDL.png" alt="Clusters data table"></a></p>

<pre><code>rewanth@ubuntu:~$ cat ~/.kube/config
...
clusters:
- cluster:
    certificate-authority: /home/rewanth/.minikube/development-ca.crt
    server: https://192.168.177.136:8443
  name: development
...
</code></pre>

<h3>Users</h3>

<p>Users in Kubernetes are identified by their respective client/user certificates. For ex, let's assume you have three users.</p>

<p><a href="https://i.stack.imgur.com/taClS.png" rel="noreferrer"><img src="https://i.stack.imgur.com/taClS.png" alt="Users data table"></a></p>

<pre><code>rewanth@ubuntu:~$ cat ~/.kube/config
...
users:
- name: admin
  user:
    client-certificate: /home/rewanth/.minikube/admin.crt
    client-key: /home/rewanth/.minikube/admin.key
...
</code></pre>

<h3>Contexts</h3>

<p>So, a user has to provide both the <code>cluster</code> certificates and <code>user</code> certificates to validate and run workloads on the targeted resource.</p>

<p>We need to provide three certificates to run workloads on any cluster.</p>

<ul>
<li>One CA certificate for cluster</li>
<li>Two certificates for user: A private key and public key</li>
</ul>

<p><strong>Context</strong> makes this work easier by combining <strong>User</strong> and <strong>Cluster</strong> configurations/certificates.</p>

<p><a href="https://i.stack.imgur.com/gxXcs.png" rel="noreferrer"><img src="https://i.stack.imgur.com/gxXcs.png" alt="Context data table"></a></p>

<pre><code>rewanth@ubuntu:~$ cat ~/.kube/config
...
contexts:
- context:
    cluster: staging
    user: user1
  name: Context1
- context:
    cluster: development
    user: admin
  name: Context2
- context:
    cluster: development
    namespace: private
    user: user1
  name: Context4
...
</code></pre>

<p>So, simply referring to <code>Context2</code> means we want to log in to <code>Development</code> cluster as <code>admin</code> user.</p>

<p><code>Context4</code> means we want to log in to <code>private</code> namespace in <code>development</code> cluster as <code>user1</code> user.</p>

<p><code>Context1</code> means we want to log in to <code>staging</code> cluster as <code>user1</code> user.</p>

<h3>IMPORTANT NOTE</h3>

<p><strong>Context</strong> doesn't create new users/clusters. A context simply sets a new mapping that makes switching easier between multiple clusters.</p>
