Shulou(Shulou.com)05/31 Report--

This article mainly explains "what are the skills to improve kubectl productivity". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what are the skills to improve kubectl productivity.

What is kubectl?

Before you learn how to use kubectl more efficiently, you should have a basic understanding of what it is and how it works. From the user's point of view, kubectl is the "cockpit" from which you control Kubernetes. It allows you to perform all possible Kubernetes operations.

From a technical point of view, kubectl is the client of Kubernetes API. Kubernetes API is a HTTP REST API. This API is the real Kubernetes user interface. Kubernetes is fully controlled by this API, which means that each Kubernetes operation is exposed as an API endpoint and can be performed by an HTTP request to this endpoint. Therefore, the main job of kubectl is to execute the HTTP request to Kubernetes API:

Kubernetes is a completely resource-centric system. This means that Kubernetes maintains the internal state of resources and all Kubernetes operations are CRUD (add, read, update, delete) operations against those resources. You can control Kubernetes by manipulating these resources (Kubernetes will find a solution based on the current state of the resources). Therefore, Kubernetes API reference is primarily a list of resource types and their related operations.

Let's look at an example.

Suppose you want to create a ReplicaSet resource. To achieve this, you define ReplicaSet in a file called replicaset.yaml, and then run the following command:

Kubectl create-f replicaset.yaml

Obviously, your ReplicaSet has been created in Kubernetes. But what happens after that?

Kubernetes has an operation to create a ReplicaSet, and like all other Kubernetes operations, it is exposed as an API endpoint. For this operation, the specific API endpoint is as follows:

POST / apis/apps/v1/namespaces/ {namespace} / replicasets

You can find the API endpoints for all Kubernetes operations in API reference, including the above endpoints (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13). To make an actual request to an endpoint, you need to start by adding API server's URL to the endpoint path listed in API reference.

Therefore, when you execute the above command, kubectl will issue a HTTP POST request to the above API endpoint. The ReplicaSet definition (what you provided in the replicaset.yaml file) is passed in the body of the request.

This is how kubectl works for all commands that interact with the Kubernetes cluster. In these cases, kubectl only needs to issue a HTTP request to the appropriate Kubernetes API endpoint.

Note that by manually issuing a HTTP request to Kubernetes API, it is entirely possible to use a tool such as curl to control Kubernetes. Kubectl just makes it easier for you to use Kubernetes API.

This is a brief introduction to what kubectl is and how it works. However, every kubectl user should know more about Kubernetes API. To do this, let's first briefly introduce the internal structure of Kubernetes.

Kubernetes internal

The Kubernetes consists of a series of independent components that run as separate processes on the nodes of the cluster. Some components run on the master node, some components run on the worker node, and each component has its own specific function.

On the master node, there are the following important components:

Storage backend: storage resource definition (usually using etcd)

API Server: provide Kubernetes API and manage storage backend

Controller manager: ensure that the resource status matches the specification

Scheduler: schedule Pod to worker node

The most important components on the worker node are:

Kubelet: manages container execution on the worker node

To fully understand how these components work together, let's look at an example.

Suppose you just executed kubectl create-f replicaset.yaml, and after that, kubectl issued a HTTP POST request to _ create ReplicaSet API endpoint _ (passing your ReplicaSet resource definition). What factors cause this to happen in the cluster? As follows:

After executing kubectl create-f replicaset.yaml, API server will save your ReplicaSet resource definition on the back end of the storage.

This triggers the ReplicaSet controller in controller manager, which monitors the creation, update, and deletion of ReplicaSet resources.

ReplicaSet controller creates a Pod definition for each ReplicaSet copy (based on the Pod template in the ReplicaSet definition) and saves them to the storage backend.

This triggers the scheduler, which monitors the Pod that has not been assigned to the worker node.

Scheduler selects an appropriate worker node for each Pod and adds this information to the Pod definition in the storage backend.

Note that so far, there is no code running the workload anywhere in the cluster. All we've done so far is create and update resources in the storage backend on the master node.

This triggers the kubelet on the worker node to which Pod is dispatched, which monitors the pod dispatched to its worker node.

Kubelet reads the Pod definition from the storage backend and instructs the container runtime (for example, Docker) to run on the container on the worker node.

At this point, your ReplicaSet application is already running!

The role of Kubernetes API

As you can see from the above examples, Kubernetes components (except API server and storage backend) monitor and manipulate resource work by monitoring resource changes at the storage back end. However, these components do not have direct access to the storage backend and can only be accessed through Kubernetes API.

Look at the following example:

ReplicaSet controller uses the list ReplicaSets API endpoint _ API operation with the watch parameter _ to monitor changes to ReplicaSet resources.

ReplicaSet controller uses _ create Pod API endpoint _ to create Pod

Scheduler updates the Pod with _ patch Pod API endpoint _ and information about the selected worker node.

As you can see, this is the same as the API used by kubectl.

Kubernetes API's repetitive operation of internal components and external users is a basic design concept of Kubernetes. Now, let's summarize how Kubernetes works:

To store the state of (a resource, for example) Kubernetes at the back end.

API server provides an interface to the storage backend in the form of Kubernetes API

All other Kubernetes components and users read, monitor, and manipulate the status of Kubernetes (such as resources) through Kubernetes API.

Familiarity with these concepts will greatly help you better understand kubectl and take advantage of it.

Next, let's take a look at specific techniques to help you increase the productivity of kubectl.

1. Use the command completion function to save input

Command completion is one of the most useful but often overlooked techniques for improving kubectl productivity.

The command completion feature allows you to use the Tab key to automate all parts of the kubectl command. This applies to subcommands, options, and parameters, including things that are difficult to type, such as resource names.

Here, you can see the completion of the kubectl command:

Command completion is available for Bash and Zsh Shell.

The official documentation contains a detailed description of the completion of the setup command (https://kubernetes.io/docs/tasks/tools/install-kubectl/#enabling-shell-autocompletion), but the following sections briefly show you how to set it.

Working mode of command completion function

Overall, command completion is a Shell function that works by completing scripts. A completion script is an shell script that defines completion behavior for specific commands. You can complete the corresponding commands by entering a completion script. Kubectl can automatically generate and print out completion scripts for Bash and Zsh using the following command:

Kubectl completion bash# orkubectl completion zsh

In theory, providing the output of this command in the appropriate shell (Bash or Zsh) will enable the command completion of kubectl. In practice, however, there are some subtle differences between Bash and Zsh (including differences between Linux and macOS). This will be explained in detail in the following sections.

Bash on Linux

Bash's completion script mainly depends on the bash-completion project (https://github.com/scop/bash-completion), so you need to install it first.

You can install bash-completion using different package managers. Such as:

Sudo apt-get install bash-completion# oryum install bash-completion

You can use the following command to test that bash-completion is installed correctly:

Type\ _ init\ _ completion

If you output the code for the shell function, then bash-completion is installed correctly. If the command output is a not found error, you must add the following command line to your ~ / .bashrc file:

Source / usr/share/bash-completion/bash_completion

Whether you need to add this line to your ~ / .bashrc file depends on the package manager you use to install bash-completion. This is necessary for APT, but not for yum.

After the bash-completion installation is complete, you need to make some settings to get the kubectl completion script in all shell sessions. One way is to add the following command line to the ~ / .bashrc file:

Source / etc/bash_completion.d/kubectl

All completion scripts in the / etc/bash_completion.d directory are provided automatically by bash-completion.

The above two methods have the same effect. After reloading shell, the kubectl command completion will work properly!

Bash on macOS

When using macOS, it can be a little complicated. The reason is that as of writing, the default version of Bash on macOS is 3.2, which is out of date. Unfortunately, the kubectl completion script requires at least Bash 4.1, so it does not apply to Bash 3.2.

Apple still uses the outdated version of Bash on macOS by default because the newer version of Bash uses GPLv3 license, which Apple does not support.

This means that to use kubectl command completion on macOS, you must install a newer version of Bash. You can even set it as the new default shell, which will save you a lot of such trouble in the future. This is actually not difficult, and you can find instructions in my previous article:

Https://itnext.io/upgrading-bash-on-macos-7138bd1066ba

Before continuing with the remaining steps, make sure you are already using Bash version 4.1 or later (use bash-- version to see the version).

As in the previous section, Bash's completion script mainly relies on the bash-completion project (https://github.com/scop/bash-completion), so you need to install it first.

You can install bash-completion using Homebrew:

Brew install bash-completion@2

@ 2 represents bash-completion v2. The Kubectl completion script requires bash-completion v2, while bash-completion v2 requires at least Bash 4.1. This is why you cannot use kubectl completion scripts on Bash versions earlier than 4.1.

The output of the brew intall command includes a "Caveats" section in which the description will add the ~ / .bash_profile file with the following line:

Export BASH\ _ COMPLETION\ _ COMPAT_DIR=/usr/local/etc/bash_completion.d [[- r "/ usr/local/etc/profile.d/bash_completion.sh"]] &. "/ usr/local/etc/profile.d/bash_completion.sh"

You must do this to complete the installation of bash-completion. However, I recommend that you add these lines to ~ / .bashrc instead of ~ / .bash_profile file. This ensures that bash-completion is also available in the child shell.

After reloading shell, you can test that bash-completion is installed correctly using the following command:

Type\ _ init\ _ completion

If you output the code for the shell function, it means that everything is set up. Now, you need to make some settings to get the kubectl completion script in all shell sessions. One way is to add the following command line to the ~ / .bashrc file:

Source / usr/local/etc/bash_completion.d/kubectl

This method works only if you have installed bash-completion using Homebrew. In this case, bash-completion provides all completion scripts in this directory.

If you also installed kubectl with Homebrew, you don't even have to perform the above steps, because the completion script should have been placed in the / usr/local/etc/bash_completion.d directory by the kubectl Homebrew formula. In this case, kubectl completion should start working automatically after bash-completion is installed. All methods have the same effect.

After reloading the shell, the kubectl will work properly when it is complete!

Zsh

Zsh's completion script does not have any dependencies. So, all you need to do is make some settings so that it can be obtained in all shell sessions.

You can do this by adding the following command line to your ~ / .zshrc file:

Source

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.