从本节开始,我们来学习 K8S 集群管理相关的知识。通过前面的学习,我们知道 K8S 遵循 C/S 架构,官方也提供了 CLI 工具 kubectl
用于完成大多数集群管理相关的功能。当然凡是你可以通过 kubectl
完成的与集群交互的功能,都可以直接通过 API 完成。
对于我们来说 kubectl
并不陌生,在第 3 章讲 K8S 整体架构时,我们首次提到了它。在第 4 章和第 5 章介绍了两种安装 kubectl
的方式故而本章不再赘述安装的部分。
首先我们在终端下执行下 kubectl
:
1 | ➜ ~ kubectl |
kubectl
已经将命令做了基本的归类,同时显示了其一般的用法 kubectl [flags] [options]
。
使用 kubectl options
可以看到所有全局可用的配置项。
在我们的用户家目录,可以看到一个名为 .kube/config
的配置文件,我们来看下其中的内容(此处以本地的 minikube 集群为例)。
1 | ➜ ~ ls $HOME/.kube/config |
$HOME/.kube/config
中主要包含着:
当然,我们在第 5 章时,也已经说过,也可以使用 --kubeconfig
或者环境变量 KUBECONFIG
来传递配置文件。
另外如果你并不想使用配置文件的话,你也可以通过使用直接传递相关参数来使用,例如:
1 | ➜ ~ kubectl --client-key='/home/tao/.minikube/client.key' --client-certificate='/home/tao/.minikube/client.crt' --server='https://192.168.99.101:8443' get nodes |
get
说起无论是第 4 章还是第 5 章,当我们创建集群后,我们都做了两个相同的事情,一个是执行 kubectl get nodes
另一个则是 kubectl cluster-info
,我们先从查看集群内 Node
开始。
这里我们使用了一个本地已创建好的 minikube
集群。
1 | ➜ ~ kubectl get nodes |
可以看到以上三种“名称”均可获取当前集群内 Node
信息。这是为了便于使用而增加的别名和缩写。
如果我们想要看到更详细的信息呢?可以通过传递 -o
参数以得到不同格式的输出。
1 | ➜ ~ kubectl get nodes -o wide |
当然也可以传递 -o yaml
或者 -o json
得到更加详尽的信息。
使用 -o json
将内容以 JSON 格式输出时,可以配合 jq
进行内容提取。例如:
1 | ➜ ~ kubectl get nodes -o json | jq ".items[] | {name: .metadata.name} + .status.nodeInfo" |
以此方法可得到 Node
的基础信息。
那么除了 Node
外我们还可以查看那些资源或别名呢?可以通过 kubectl api-resources
查看服务端支持的 API 资源及别名和描述等信息。
explain
当通过上面的命令拿到所有支持的 API 资源列表后,虽然后面基本都有一个简单的说明,是不是仍然感觉一头雾水?
别担心,在我们使用 Linux 的时候,我们有 man
,在使用 kubectl
的时候,我们除了 --help
外还有 explain
可帮我们进行说明。 例如:
1 | ➜ ~ kubectl explain node |
本节我们大致介绍了 kubectl
的基础使用,尤其是最常见的 get
命令。可通过传递不同参数获取不同格式的输出,配合 jq
工具可方便的进行内容提取。
以及关于 kubectl
的配置文件和无配置文件下通过传递参数直接使用等。
对应于我们前面提到的 K8S 架构,本节相当于 CURD
中的 R
即查询。查询对于我们来说,既是我们了解集群的第一步,同时也是后续验证操作结果或集群状态必不可少的技能。
当然,你在集群管理中可能会遇到各种各样的问题,单纯依靠 get
并不足以定位问题,我们在第 21 节中将介绍 Troubleshoot 的思路及方法。
下节我们来学习关于 C
的部分,即创建。