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
namespace-development.yaml
apiVersion: v1
kind: Namespace
metadata:
name: development
Copy the code
namespace-production.yaml
apiVersion: v1
kind: Namespace
metadata:
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
redis-slave-controller.yaml
-
-
apiVersion: v1 kind: ReplicationController metadata: name: redis-slave labels: name: redis-slave spec: replicas: 2 selector: name: redis-slave template: metadata: labels: name: redis-slave spec: containers: - name: slave image: kubeguide/guestbook-redis-slave ports: - 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=https://1.2.3.4 --certificate-authority=fake-ca-file kubectl config --kubeconfig=config-demo set-cluster scratch - server = https://5.6.7.8 - 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