Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now
Uncategorised

What is kubectl and How to configure it for accessing kubernetes?

March 26, 2021 comments off

Use of kubeconfig file

In order for kubectl to find and access a Kubernetes cluster, it needs a kubeconfig file, which is created automatically

  • When you create a cluster using kube-up.sh or
  • Successfully deploy a Minikube cluster.

By default, kubectl configuration is located at ~/.kube/config

kubeconfig file Loading order

kubectl configuration loading order follows these rules:

  1. If the –kubeconfig flag is set, then only that file is loaded. The flag may only be set once and no merging takes place.
  2. If $KUBECONFIG environment variable is set, then it is used a list of paths (normal path delimitting rules for your system). These paths are merged. When a value is modified, it is modified in the file that defines the stanza. When a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the last file in the list.
  3. Otherwise, ${HOME}/.kube/config is used and no merging takes place.

Terminology in kubeconfig file

There are following terminology used in kubectl configuration file.

clusters
A cluster contains endpoint data for a kubernetes cluster. This includes the fully qualified url for the kubernetes apiserver, as well as the cluster’s certificate authority or insecure-skip-tls-verify: true, if the cluster’s serving certificate is not signed by a system trusted certificate authority. A cluster has a name (nickname) which acts as a dictionary key for the cluster within this kubeconfig file. You can add or modify cluster entries using “kubectl config set-cluster”.

clusters -> cluster -> certificate-authority
clusters -> cluster -> server
clusters -> cluster -> name

contexts
A context element in a kubeconfig file is used to group access parameters under a convenient name. A context defines a named cluster,user,namespace tuple which is used to send requests to the specified cluster using the provided authentication info and namespace. Each of the three is optional; it is valid to specify a context with only one of cluster, user,namespace, or to specify none. Unspecified values, or named values that don’t have corresponding entries in the loaded kubeconfig (e.g. if the context specified a pink-user for the above kubeconfig file) will be replaced with the default. See Loading and merging rules below for override/merge behavior. You can add or modify context entries with kubectl config set-context. By default, the kubectl command-line tool uses parameters from the current context to communicate with the cluster.

contexts -> context -> cluster
contexts -> context -> user
contexts -> context -> name

users
A user defines client credentials for authenticating to a kubernetes cluster. A user has a name (nickname) which acts as its key within the list of user entries after kubeconfig is loaded/merged. Available credentials are client-certificate, client-key, token, and username/password. username/password and token are mutually exclusive, but client certs and keys can be combined with them.
users -> name
users -> user -> client-certificate # Path to a client certificate file for TLS
users -> user -> client-key # Path to a client key file for TLS

Example of kubectl configuration file

apiVersion: v1
clusters:
- cluster:
    certificate-authority: C:\Users\Rajesh\.minikube\ca.crt
    server: https://192.168.99.100:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: C:\Users\Rajesh\.minikube\client.crt
    client-key: C:\Users\Rajesh\.minikube\client.key

kubeconfig for multiple clusters & users

Suppose you have several clusters, and your users and components authenticate in a variety of ways. For example:

  1. A running kubelet might authenticate using certificates.
  2. A user might authenticate using tokens.
  3. Administrators might have sets of certificates that they provide to individual users.

With kubeconfig files, you can organize your clusters, users, and namespaces. You can also define contexts to quickly and easily switch between clusters and namespaces.

Most frequently used kubectl commands

# Check that kubectl is properly configured by getting the cluster state:
$ kubectl cluster-info

# If kubectl cluster-info returns the url response but you can’t access your cluster, to check whether it is configured properly, use:
$ kubectl cluster-info dump

#Display the current-context
$ kubectl config current-context

# Delete the minikube cluster
$ kubectl config delete-cluster minikube

# Delete the context for the minikube cluster
$ kubectl config delete-context minikube

# List the clusters kubectl knows about
$ kubectl config get-clusters

# List all the contexts in your kubeconfig file
$ kubectl config get-contexts

# Describe one context in your kubeconfig file.
$ kubectl config get-contexts my-context

# Rename the context 'old-name' to 'new-name' in your kubeconfig file
$ kubectl config rename-context old-name new-name

# Set only the server field on the e2e cluster entry without touching other values.
$ kubectl config set-cluster e2e --server=https://1.2.3.4

# Embed certificate authority data for the e2e cluster entry
$ kubectl config set-cluster e2e --certificate-authority=~/.kube/e2e/kubernetes.ca.crt

# Disable cert checking for the dev cluster entry
$ kubectl config set-cluster e2e --insecure-skip-tls-verify=true

# Set the user field on the gce context entry without touching other values
$ kubectl config set-context gce --user=cluster-admin

# Set only the "client-key" field on the "cluster-admin" # entry, without touching other values:
$ kubectl config set-credentials cluster-admin --client-key=~/.kube/admin.key

# Set basic auth for the "cluster-admin" entry
$ kubectl config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif

# Embed client certificate data in the "cluster-admin" entry
$ kubectl config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true

# Enable the Google Compute Platform auth provider for the "cluster-admin" entry
$ kubectl config set-credentials cluster-admin --auth-provider=gcp

# Enable the OpenID Connect auth provider for the "cluster-admin" entry with additional args
$ kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar

# Remove the "client-secret" config value for the OpenID Connect auth provider for the "cluster-admin" entry
$ kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-

# Unset the current-context.
$ kubectl config unset current-context

# Unset namespace in foo context.
$ kubectl config unset contexts.foo.namespace

# Use the context for the minikube cluster
$ kubectl config use-context minikube

# Show Merged kubeconfig settings.
$ kubectl config view

# Get the password for the e2e user
$ kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
Rajesh Kumar
Follow me
Latest posts by Rajesh Kumar (see all)