kubectl context vs cluster
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 kubeconfigand 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/igniteclusterSimilar Questions
4 Answers
Cluster defines connection endpoint for Kubernetes API of a cluster.
User defines credentials for connecting to cluster.
Context defines both cluster and user.
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.
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.
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 clusterSo, contextX = {clusterX, userX, namespaceX}