This is the 15th day of my participation in the August More Text Challenge

1. Kubeconfig file

Use kubeconFig files to organize information about clusters, users, namespaces, and authentication mechanisms. The Kubectl command line tool uses the Kubeconfig file to find the information needed to select the cluster and communicate with the cluster’s API server.

Note: The file used to configure cluster access is called the KubeconFig file. This is a common way to reference configuration files. This does not mean that there is a file called Kubeconfig

By default, kubectl looks for a file named config in the $HOME/. Kube directory. You can specify other KUBECONFIG files either by setting the KUBECONFIG environment variable or by setting the -- KUBECONFIG parameter. K8s cluster can distinguish different workgroups by setting namespace and context, so that they can share the same Kubernetes cluster services, but also can not interfere with each other.Copy the code

Supports multiple clusters, user authentication, and identity authentication

Suppose you have multiple clusters and your users and components are authenticated in a variety of ways. Such as:

  • Running Kubelet may be authenticated using certificates.
  • The user may be authenticated by a token.
  • An administrator may have multiple sets of certificates to provide to each user.

Using kubeconFig files, you can organize clusters, users, and namespaces. You can also define contexts for quick and easy switching between clusters and namespaces.

KUBECONFIG environment variable

The KUBECONFIG environment variable contains a list of KUBECONFIG files. For Linux and Mac, lists are separated by colons. For Windows, lists are separated by semicolons. KUBECONFIG environment variables are not required. If the KUBECONFIG environment variable is not present, kubectl uses the default KUBECONFIG file, $HOME/.kube/config.

Set temporary environment variables

export  KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
Copy the code

If the KUBECONFIG environment variable exists, Kubectl uses the valid configuration of the merged files listed in the KUBECONFIG environment variable.

2. Context

Using the context element in the KubeconFig file, group the access parameters with a handy name. Each context takes three parameters: cluster, namespace, and User. By default, the Kubectl command line tool communicates with the cluster using parameters in the current context.

The kubectl config command sets and uses the context

Select the current context

kubectl config use-context
Copy the code

Kubectl config –help View instructions for using the kubectl config command

The kubectl config command is used to set, use, and delete the context.

Namespace and Context examples:

Create two namespaces and context: Development and Production

2) Create a namespace


apiVersion: v1
kind: Namespace
 name: development
Copy the code


apiVersion: v1
kind: Namespace
 name: production
Copy the code

$ kubectl create -f namespace-development.yaml

$ kubectl create -f namespace-production.yaml

2) Create context

Create the ctx-dev context and specify its namespace as development

$ kubectl config set-context ctx-dev –namespace=development –cluster=kubernetes –user=kubernetes-admin

Create the CTX-prod context and specify its namespace as Production

$ kubectl config set-context ctx-prod –namespace=production –cluster=kubernetes –user=kubernetes-admin

–cluster=kubernetes –user=kubernetes-admin –user=kubernetes-admin –user=kubernetes-admin

$ kubectl config view

Check out kubeconFig content

From the information displayed, we can see that there are currently three contexts in the cluster, ctx-dev, CTx-prod, and kubernetes-admin@kubernetes(the default context for the K8S cluster).

In current-context, the current context is kubernetes-admin@kubernetes

3) Context switch

$ kubectl config use-context ctx-dev

Create an RC in the current context


    • apiVersion: v1
      kind: ReplicationController
       name: redis-slave
        name: redis-slave
       replicas: 2
        name: redis-slave
           name: redis-slave
         - name: slave
           image: kubeguide/guestbook-redis-slave
           - containerPort: 6379
      Copy the code

$ kubectl create -f redis-slave-controller.yaml

Create the RC in the current context

$ kubectl get rc

View the information about the RC resource

Switch to the CTX-PROd context

$ kubectl config use-context ctx-prod

View resource information for the current context

$ kubectl get rc

We find that there is no RC resource information in the CTX-PROD context, so resources are isolated from each other in different contexts.

4. Kubectl config common command

1. View the configuration

Kubectl config --kubeconfig=config-demo view kubectl config --kubeconfig=config-demo viewCopy the code

2. Create a cluster, user name, and context

Kubectl config --kubeconfig=config-demo set-cluster development --server= --certificate-authority=fake-ca-file kubectl config --kubeconfig=config-demo set-cluster scratch - server = - insecure - skip, TLS, and verifyCopy the code

3. Delete the user

kubectl --kubeconfig=config-demo config unset users.<name>
Copy the code

4. Delete the cluster

kubectl --kubeconfig=config-demo config unset clusters.<name>
Copy the code

5. Delete the context

kubectl --kubeconfig=config-demo config unset contexts.<name>
Copy the code

6. Add context details to the configuration file:

kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
Copy the code

7. Set the current context

kubectl config --kubeconfig=config-demo use-context dev-frontend
Copy the code

8. Switch context

kubectl config user-context ctx-dev
Copy the code