kubectl context vs cluster

Question

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

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

and in .kube/config I see:

- 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

Answer 1

Cluster defines connection endpoint for Kubernetes API of a cluster.

User defines credentials for connecting to cluster.

Context defines both cluster and user.

Answer 2

Clusters

Cluster is a place where all Kubernetes components, capabilities, and workloads are configured.

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

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

Users

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

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

Contexts

So, a user has to provide both the cluster certificates and user certificates to validate and run workloads on the targeted resource.

We need to provide three certificates to run workloads on any cluster.

• One CA certificate for cluster
• Two certificates for user: A private key and public key

Context makes this work easier by combining User and Cluster configurations/certificates.

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

So, simply referring to Context2 means we want to log in to Development cluster as admin user.

Context4 means we want to log in to private namespace in development cluster as user1 user.

Context1 means we want to log in to staging cluster as user1 user.

IMPORTANT NOTE

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

Answer 3

Cluster : Kubernetes brings together individual physical or virtual machines into a cluster using a shared network to communicate between each server. This cluster is the physical platform where all Kubernetes components, capabilities, and workloads are configured.

Context : A context is just a set of access parameters that contains a Kubernetes cluster, a user, and a namespace.

The current context is the cluster that is currently the default for kubectl and all kubectl commands run against that cluster.

Answer 4

From https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#kubeconfig :

A context is a group of access parameters.
Each context contains a Kubernetes cluster, a user, and a namespace.
The current context is the cluster that is currently the default for kubectl:
all kubectl commands run against that cluster

So, contextX = {clusterX, userX, namespaceX}