Skip to content

Kubernetes Context

In Kubernetes, a Context is a client-side concept found within the kubeconfig file that functions as a convenient alias or shortcut for accessing specific cluster parameters^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]. It essentially groups a specific cluster, user identity, and namespace into a single, easily accessible reference point^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md].

When a specific context is active, all kubectl commands are executed against the cluster, namespace, and user defined within that context^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]. It is important to note that the kube-apiserver is unaware of the context itself; the translation of the context into specific request parameters occurs entirely on the client side before the request is sent to the server^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md].

Components of a Context

A context entry in the configuration file acts as a bridge between three other main configuration elements^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]:

  • Cluster: Defines the address of the Kubernetes API server (server URL) and the certificate authority data required to communicate securely with the cluster^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md].
  • User: Defines the authentication credentials used to identify the client, such as client certificates, bearer tokens, or an authenticating proxy configuration^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md].
  • Namespace: Specifies the default namespace for the kubectl request. If this is omitted, the default namespace is used^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md].

Use Cases

Contexts are primarily used to manage access across different environments, teams, or roles. By defining multiple contexts, a developer can easily switch between distinct configurations without manually editing connection parameters^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]. Common scenarios include:

  • Multi-environment access: Switching between production and development clusters^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md].
  • Team segregation: Ensuring a frontend developer operates only within the frontend namespace while a backend developer operates within the backend namespace^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md].

Management

The kubectl config command set is used to manage contexts.

Creating and Setting Contexts

To create or modify a context, use the set-context subcommand^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]:

[kubectl](<./kubectl.md>) config set-context <CONTEXT_NAME> \
  --namespace=<NAMESPACE_NAME> \
  --cluster=<CLUSTER_NAME> \
  --user=<USER_NAME>

Switching Contexts

To switch the active context used by kubectl^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]:

[kubectl](<./kubectl.md>) config use-context <CONTEXT_NAME>

To view the currently active context^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]:

[kubectl](<./kubectl.md>) config current-context

Viewing Configuration

To display the entire configuration file, including all defined contexts, clusters, and users^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]:

[kubectl](<./kubectl.md>) config view

To view only the configuration relevant to the current context^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]:

[kubectl](<./kubectl.md>) config view --minify
  • [[RBAC]]
  • [[Namespace]]
  • [[Service Account]]

Sources

^[400-devops-06-kubernetes-k8s-ithelp-day28-readme.md]