06 Cluster Management Introduction with kubectl #
Starting from this section, we will learn about cluster management in K8S. As we know from previous sections, K8S follows a client-server architecture, and the official CLI tool kubectl is provided to perform most of the cluster management functions. Of course, any interaction with the cluster that can be done with kubectl can also be done directly through the API.
kubectl is not unfamiliar to us. We mentioned it for the first time in Chapter 3 when discussing the overall architecture of K8S. In Chapter 4 and Chapter 5, we introduced two ways to install kubectl, so we will not go into detail about the installation in this chapter.
Overview #
First, let’s execute kubectl in the terminal:
➜ ~ kubectl
kubectl controls the Kubernetes cluster manager.
...
Usage:
kubectl [flags] [options]
kubectl has categorized its commands and displayed its general usage as kubectl [flags] [options].
You can use kubectl options to see all globally available configuration options.
Basic Configuration #
In our user’s home directory, we can see a configuration file named .kube/config. Let’s take a look at its content (using the local minikube cluster as an example).
➜ ~ ls $HOME/.kube/config
/home/tao/.kube/config
➜ ~ cat $HOME/.kube/config
apiVersion: v1
clusters:
- cluster:
certificate-authority: /home/tao/.minikube/ca.crt
server: https://192.168.99.101:8443
name: minikube
contexts:
- context:
cluster: minikube
user: minikube
name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
user:
client-certificate: /home/tao/.minikube/client.crt
client-key: /home/tao/.minikube/client.key
The $HOME/.kube/config file mainly contains:
- The API address of the Kubernetes cluster
- Certificate addresses used for authentication
Of course, as we mentioned in Chapter 5, you can also pass the configuration file using --kubeconfig or the environment variable KUBECONFIG.
Additionally, if you don’t want to use a configuration file, you can also directly pass relevant parameters, for example:
➜ ~ kubectl --client-key='/home/tao/.minikube/client.key' --client-certificate='/home/tao/.minikube/client.crt' --server='https://192.168.99.101:8443' get nodes
NAME STATUS ROLES AGE VERSION
minikube Ready master 2d v1.11.3
Starting with get
#
Whether it’s Chapter 4 or Chapter 5, after we create a cluster, we do two things: executing kubectl get nodes and kubectl cluster-info. Let’s start by looking at the Node inside the cluster.
Here we are using a locally created minikube cluster.
➜ ~ kubectl get nodes
NAME STATUS ROLES AGE VERSION
minikube Ready master 2d v1.11.3
➜ ~ kubectl get node
NAME STATUS ROLES AGE VERSION
minikube Ready master 2d v1.11.3
➜ ~ kubectl get no
NAME STATUS ROLES AGE VERSION
minikube Ready master 2d v1.11.3
As you can see, all three “names” can retrieve information about the current Node in the cluster. These are aliases and abbreviations added for convenience.
If we want to see more detailed information, we can pass the -o parameter to get different output formats.
➜ ~ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
minikube Ready master 2d v1.11.3 10.0.2.15 <none> Buildroot 2018.05 4.15.0 docker://17.12.1-ce
Of course, you can also pass -o yaml or -o json to get more detailed information.
When using -o json to output the content in JSON format, you can use jq to extract content. For example:
➜ ~ kubectl get nodes -o json | jq ".items[] | {name: .metadata.name} + .status.nodeInfo"
{
"name": "minikube",
"architecture": "amd64",
"bootID": "d675d75b-e58e-40db-8910-6e5dda9e7cf9",
"containerRuntimeVersion": "docker://17.12.1-ce",
"kernelVersion": "4.15.0",
"kubeProxyVersion": "v1.11.3",
"kubeletVersion": "v1.11.3",
"machineID": "078e2d22629747178397e29cf1c96cc7",
"operatingSystem": "linux",
"osImage": "Buildroot 2018.05",
"systemUUID": "4073906D-69A1-46EE-A08C-0252D9F79893"
}
This method allows you to obtain the basic information of the Node.
Now, besides the Node, what other resources or aliases can we view? You can use kubectl api-resources to view the API resources supported by the server and their aliases, descriptions, and other information.
Frequently Asked Questions and Explanations explain
#
After obtaining the list of all supported API resources using the command above, do you still feel confused, even though there is a basic explanation for each resource?
Don’t worry, when we use Linux, we have man. When we use kubectl, in addition to --help, we also have explain to help us with explanations. For example:
➜ ~ kubectl explain node
KIND: Node
VERSION: v1
DESCRIPTION:
Node is a worker node in Kubernetes. Each node will have a unique
identifier in the cache (i.e. in etcd).
# ... Output omitted
Summary #
In this section, we have roughly introduced the basic usage of kubectl, especially the most common get command. By passing different parameters, you can obtain output in different formats, and you can conveniently extract content using the jq tool.
We have also discussed the configuration file of kubectl and how to use it directly without a configuration file by passing parameters.
As mentioned earlier in the Kubernetes architecture, this section corresponds to the “R” in CRUD, which is querying. Querying is not only the first step for us to understand the cluster, but also an essential skill for verifying operation results or cluster status in the future.
Of course, you may encounter various problems in cluster management, and relying solely on get may not be enough to locate the issues. In Section 21, we will introduce the troubleshooting mindset and methods.
In the next section, we will learn about the “C” part, which is creating.