Shulou(Shulou.com)06/02 Report--

For many IT people, the mechanism for daily interaction with Kubernetes is generally through kubectl--, a command-line tool. Kubectl is primarily used to communicate with Kubernetes API servers to create, update, and delete workloads in Kubernetes. The purpose of this tutorial is to provide an overview of some common commands you can use and to provide a good starting point for managing Kubernetes.

We'll show you how to install kubectl on your computer, communicate with your Kubernetes environment, and perform some common actions. Most common kubectl commands provide a specific operation, such as create, delete, and so on. This approach usually requires interpreting files (YAML or JSON) that describe objects in Kubernetes, such as POD, services, resources, and so on. These files are often used as templates and ongoing documentation for the environment, and help preserve Kubernetes's focus on declarative configuration. The actions given on the command line are passed to the API server and then communicate with the back-end services in Kubernetes as needed.

Cdn.xitu.io/2019/7/12/16be3eb27ecc3d7d?w=568&h=370&f=jpeg&s=28534 ">

We will introduce some of the most common kubectl commands and provide some examples. For more details on each command, including all supported flags and subcommands, check the kubectl reference documentation:

Https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands .

Install kubectl

Kubectl is a stand-alone program, so there is no need for a complex installation process. It is a single file that needs to be located in the operating system PATH. There are many ways to get kubectl binaries, such as through the operating system's native package manager or through curl. Some of the examples in the following table are how to install kubectl for various operating systems:

Be careful

As the new version is released, the best version of kubectl for Windows will change over time. To find the current best binaries, click this link to find the latest stable version and adjust the above URL: https://storage.googleapis.com/kubernetes-release/release/stable.txt as needed

The version of kubectl used in the environment needs to be consistent with the version of the Kubernetes server. You can view the version of the kubectl client you are using by typing:

Kubectl maintains compatibility with one version in all respects. The client version is one step ahead of the server version. This supports the features and commands provided in the server version: v1.13.4. If the client version is not one of the versions after the server version, you may encounter errors or incompatibilities when trying to access the features available in the corresponding server version.

Kubectl syntax

The syntax for kubectl is as follows:

Command (command): refers to the actions you want to perform (create, delete, etc.)

Type (category): refers to the type of resource you are executing the command (Pod, Service, etc.)

Name (name): the name of the object (case sensitive). If you do not specify a name, you can get information about all resources that the command matches (for example, Pod)

Flags (flag): this can be selected on demand (optional), but it is very useful when looking for specific resources. For example,-- namespacespace allows you to specify which specific namespace to perform the operation in.

Kubeconfig

Kubectl uses configuration files to access the Kubernetes cluster. The default kubectl configuration file is located in ~ / .kube / config, called the kubeconfig file.

The kubeconfig file organizes information about clusters, users, namespaces, and authentication mechanisms. The kubectl command uses these files to find the information it needs when selecting and communicating with a cluster.

The load order follows the following rules:

If the-- kubeconfig flag is set, only the given file is loaded. This flag can only be set once and no merge will occur.

If the $KUBECONFIG environment variable is set, it is resolved to a list of file system paths according to the system's normal path separation rules.

Otherwise, if neither of the above is set, the ${HOME} / .kube/config file is used without any merging.

If you see a message similar to the following, it means that kubectl is not configured correctly or cannot connect to the Kubernetes cluster.

The connection to the server was refused-did you specify the right host or port?

You can create configuration files in a variety of ways, depending on which Kubernetes distribution you use. The different K8S distributions and their locations are listed below:

RKE

When you create a Kubernetes cluster using RKE, RKE creates a kube_config_rancher-cluster.yml file in the local directory that contains the credentials needed to connect to the new cluster using tools such as kubectl.

You can copy this file to $HOME / .kube / config, or, if you are using multiple Kubernetes clusters, set the KUBECONFIG environment variable to the path of kube_config_rancher-cluster.yml, as follows:

Kubernetes Cluster managed by Rancher

In Rancher, you can download the kubeconfig file through Web UI and use it to connect to the Kubernetes environment through kubectl.

In Rancher UI, click the cluster to which you want to connect through kubectl. In the upper right corner of the page, click the Kubeconfig File button:

Click the button to view the configuration file in detail and the orientation placed in ~ / .kube / config.

After copying the configuration to ~ / .kube / config, you can run the kubectl command without specifying the location of the-- kube-config file:

Some examples of basic commands

Below I will focus on many of the commands that would be used in a typical environment. We will start with an overview of the cluster, all the way through to exploring the various scenarios of what is currently running in the Kubernetes environment.

I'm sure the following will help you familiarize yourself with kubectl and typical output commands.

Manage kubectl configuration

The kubectl command contains different commands that can be used to help view and manage your own configuration. These can be useful during initial setup, or when the cluster set you need to deal with changes.

To view the current configuration, type:

ApiVersion: v1 clusters:-cluster: certificate-authority-data: DATA+OMITTED server: https://www..com/k8s/clusters/ name: gcpcluster- cluster: certificate-authority-data: DATA+OMITTED server: https://10.240.0.41:6443 name: gcpcluster-k8s-1-cluster: certificate-authority-data: DATA+OMITTED server: https://10.240.0.42:6443 name: gcpcluster-k8s-2-cluster: certificate- Authority-data: DATA+OMITTED server: https://10.240.0.43:6443 name: gcpcluster-k8s-3 contexts:-context: cluster: gcpcluster namespace: rancher user: user-qkvpz name: gcpcluster

The output you can see summarizes the clusters and contexts you have configured. The cluster key contains a list of each available cluster, as well as relevant connection and verification details. The contexts key combines users, clusters, and optional namespaces to form a unique identification and usage context for interacting with the set.

To get a more concise summary of each available context, you can type:

The output shows the details of each defined context and the currently selected context, represented by an asterisk (*).

To quickly check the context currently in use, type:

Although we won't cover it in this summary, you can also use kubectl set-cluster, kubectl set-credentials, and kubectl set-context, as well as various flags, to define clusters and contexts, but we won't dwell on them in this article.

To change the context to connect, use the use-context command:

Check the status of cluster components

After selecting the appropriate context for the cluster, you can use the get componentstatuses (abbreviated to get cs) command to check the status of the core master component:

The output shows the status of the scheduler, controller manager, and etcd node, as well as the latest messages and errors collected from each service. If your cluster is not working properly, this is a good opportunity to have your first diagnostic check.

You can use the cluster-info command to collect additional connection and service information:

Kubernetes master is running at https://www..com/k8s/clusters/ KubeDNS is running at https://www..com/k8s/clusters//api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Here, the output shows the endpoint of our Kubernetes master and the endpoint of the KubeDNS service endpoint.

To view information about each individual node that is a member of the cluster, use the get nodes command:

NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k8s-1 Ready controlplane,etcd,worker 34d v1.13.5 Ubuntu 18.10 4.18.0-1011-gcp docker://18.9.5 k8s-2 Ready controlplane,etcd Worker 34d v1.13.5 Ubuntu 18.104.18.0-1011-gcp docker://18.9.5 k8s-3 Ready controlplane,etcd,worker 34d v1.13.5 Ubuntu 18.104.18.0-1011-gcp docker://18.9.5

This lists the status, role, connection information, and version number of the core software running on each node. If you need to perform maintenance or log in on the cluster node to debug the problem, this command can help you provide the information you need.

View resource and event information

To outline the namespaces available in the cluster, use the get namespaces command:

This shows the namespace partitions defined in the current cluster.

To summarize all resources running on the cluster across all namespaces, use the following command:

The output shows the namespace information for each resource deployed, as well as the resource name prefixed with the resource type (such as pod in the example shown above). After that, information about the ready and running status of each resource will help determine whether the process is running properly.

To view the events associated with the resource, use the get events command:

NAMESPACE LAST SEEN TYPE REASON KIND MESSAGE cattle-system 9m31s Normal BackOff Pod Back-off pulling image "miguelgt/k8s-demo:v2" cattle-system 24m Warning Failed Pod Error: ImagePullBackOff cattle-system 14m Normal BackOff Pod Back-off pulling image "miguelgt/k8s-demo:v2" cattle-system 9m30s Warning Failed Pod Error: ImagePullBackOff

The output lists the latest events recorded by the resource, including the event message and why it was triggered.

Exampl

To demonstrate more specifically the workflows that you might participate in when using kubectl, we will introduce a quick scenario for deploying containers to a cluster and deploy them to a non-default namespace.

By default, if you deploy a cluster without a namespace specified, kubectl places resources in a namespace named default. If you are deploying to another namespace, you need to specify the desired alternatives.

Although we can provide namespaces for creating commands, it is easier to change the context if we want to use namespaces to handle multiple commands. Changing the namespace associated with the context automatically applies the namespace specification to any other command until the context is changed.

To change the namespace of the current context, use the set-context command with the-- currentand-- namespace flag:

This changes the current context to automatically apply future operations to the rancher namespace.

Next, we can create a deployment called nginx, which runs the container based on the default nginx container image. Because we changed our context, it runs in the rancher namespace:

You can check whether the deployment is successful by listing the currently deployed pod:

Here, we can see that the Nginx deployment is working properly. The READY column shows that the container is ready, the status is running, and there is no failure.

Although we have verified that pod is running, we have no information about which namespace it is deployed to. However, we can change the output slightly by adding the-- all-namespaces flag:

This displays the pod running in each namespace and adds a separate NAMESPACE column listing the namespace to which each resource is deployed. Here, we see that Nginx pod has been correctly deployed to our rancher namespace instead of the usual default namespace.

This shows that our context operation and our deployment are working as expected.

You can also clean up deployed resources by typing:

Other reference information

Although an in-depth discussion of this chapter may be beyond the scope of this article, we have listed some very useful commands for you.

Pod

Resource deletion

Service

Event & indicator

Namespace & Security

Intermediate command

Other resources

Official overview of kubectl: https://kubernetes.io/docs/reference/kubectl/overview/

Official command document for kubectl: https://kubernetes.io/docs/reference/kubectl/kubectl/

Kubectl's official cheat sheet: https://kubernetes.io/docs/reference/kubectl/cheatsheet/

Rancher kubeconfig documents: https://rancher.com/docs/rancher/v2.x/en/cluster-admin/kubeconfig/

Rancher document on using kubectl to access clusters: https://rancher.com/docs/rancher/v2.x/en/cluster-admin/kubectl/

Kubectl configuration command: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#config

Organize a cluster using kubeconfig files: https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.