Managing Cluster Access using kubeconfig files

Filed Under: Random
Managing Cluster Access Using Kubeconfig Files

Hello, readers. This article talks about Managing Cluster Access using kubeconfig files with examples.

So, let us begin!! 馃檪

Understanding the way to access a Kubernetes Cluster

When we spin up or provision a Kubernetes Cluster, we have two ways to access the same-

  1. First being the UI way of it. That is, we can access and view the resources within namespaces through the portal. For example, Google Kubernetes Engine Portal, Azure Kubernetes Service portal, Mirantis Kubernetes Engine Portal, minikube, etc.
  2. Accessing the cluster through the Command line way of it. That is, we can make use of kubectl command line tool to access the kubernetes resources from any CMD space.

This article focuses on the second way to access a cluster i.e. through the kubectl way. This command-line tool makes use of kubeconfig files to get access information about a cluster. This information contains the necessary access needed to communicate to the API server for information transfer on the CMD space.

Having understood this, let us now focus on the concept of Kubeconfig files in the upcoming section.

Exploring a Kubeconfig file for managing cluster access

Kubeconfig file is the one that contains the information that enables us to configure access to any cluster in the network.

As a default action, kubectl expects and looks for a config file that sits in the $HOME/.kube directory. This is the default way to configure access to any cluster. If we wish to have a customized config file, we can specify the same by setting the –kubeconfig flag or even by setting the KUBECONFIG environment variable.

The concept of kubeconfig files for access works well when we have multiple clusters provisioned within the same network.

Structure of a Kubeconfig file

  1. clusters: This section stores the information about the clusters we expect us to have an access to. It includes the cluster name as well as the CA certificate.
  2. users: This section contains a list of users who will be having access to the above mentioned clusters.
  3. contexts: This section includes the information that enables the kubectl command line tool to select one particular access mode for a specific user on a specific cluster i.e. setting the context out of all the clusters.

syntax — Demo Kubeconfig file

apiVersion: v1
kind: Config
preferences: {}

- cluster:
  name: development
- cluster:
  name: QA

- name: developer
- name: tester

- context:
  name: frontend
- context:
  name: QA-DB
- context:
  name: sandbox

Example — Kubeconfig file

apiVersion: v1
- cluster:
    certificate-authority: /home/ca-file
    server: https://demo/
  name: Sandbox
- context:
    cluster: QA
    user: developer
  name: QA-Database
current-context: QA-Database
kind: Config
preferences: {}
- name: developer
    client-certificate: /home/cert-file
    client-key: /home/key-file

In the above example, we have created a kubeconfig file that includes the access information about the Sandbox cluster. Further, it has set the QA-Database as the context for the user developer. To provide access, it also includes necessary certificates of the user ‘developer’.

To view the current configuration, we can make use of the below command-

kubectl config view

Moving ahead, when we have multiple contexts defined in the config file, the below command can help us switch to a particular context at a time-

kubectl config --kubeconfig=config-file-name use-context context-name


By this, we have reached the end of this topic. Feel free to comment below in the comment box, in case you come across any questions.

For more such posts related to Docker and Kubernetes, Stay tuned with us.

Till then, Happy Learning!! 馃檪

Generic selectors
Exact matches only
Search in title
Search in content