一篇带给你 Kubectl 高效使用技巧

让我们看一个简单的例子：

1. ➜  ~ kubectl get pods -o custom-columns='NAME:metadata.name' 
2. NAME 
3. nfs-client-provisioner-54f4485448-kwr45 
4. nginx-674ff86d-t6gbd 

在这里，输出包括显示所有 Pod 名称的一列，选择 Pod 名称的表达式是 meta.name，因为 Pod 的名称是在 Pod 资源的 metadata 属性下面的 name 字段中定义的(我们可以使用 kubectl explain pod.metadata.name 进行查找)。

现在，假设你想在输出中添加一个附加列，比如显示每个 Pod 在其上运行的节点，那么我们只需在自定义列选项中添加适当的列规范即可：

1. ➜  ~ kubectl get pods -o custom-columns='NAME:metadata.name,NODE:spec.nodeName' 
2. NAME                                      NODE 
3. nfs-client-provisioner-54f4485448-kwr45   172.27.0.2 
4. nginx-674ff86d-t6gbd                      172.27.0.2 

选择节点名称的表达式是 spec.nodeName，这是因为已将 Pod 调度的节点保存在 Pod 的 spec.nodeName 字段中了。不过需要请注意的是 Kubernetes 资源字段是区分大小写的。

我们可以通过这种方式将资源的任何字段设置为输出列，只需浏览资源规范并尝试使用任何你喜欢的字段即可。当然我们需要对字段选择的 JSONPath 表达式要有一定的了解。

JSONPath 表达式

用于选择资源字段的表达式基于 JSONPath 的。JSONPath 是一种用于从 JSON 文档提取数据的语言(类似于 XPath for XML)，选择单个字段只是 JSONPath 的最基本用法，它还有很多其他功能，例如 list selector、filter 等。

但是，kubectl explain 仅支持 JSONPath 功能的子集，下面我们通过一些示例用法来总结下这些使用规则：

选择一个列表的所有元素

1. # 获取Pod下面的所有容器镜像 
2. ➜  ~ kubectl get pods -o custom-columns='IMAGES:spec.containers[*].image' 
3. IMAGES 
4. cnych/nfs-subdir-external-provisioner:v4.0.2 
5. nginx:latest 

选择一个列表的指定元素

1. # 获取Pod下面第一个容器的镜像 
2. ➜  ~ kubectl get pods -o custom-columns='IMAGE:spec.containers[0].image' 
3. IMAGE 
4. cnych/nfs-subdir-external-provisioner:v4.0.2 
5. nginx:latest 

选择匹配过滤表达式的列表元素

1. ➜  ~ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx:latest")].image' 
2. DATA 
3. cnych/nfs-subdir-external-provisioner:v4.0.2 
4. <none> 

选择指定位置下的所有字段

1. ➜  ~ kubectl get pods -o custom-columns='DATA:metadata.*' 
2. DATA 
3. default,[map[apiVersion:apps/v1 blockOwnerDeletion:true controller:true kind:ReplicaSet name:nfs-client-provisioner-54f4485448 uid:39912344-d707-4029-8da8-5269cfcae9e9]],4926994155,map[app:nfs-client-provisioner pod-template-hash:54f4485448],2021-07-06T04:08:48Z,nfs-client-provisioner-54f4485448-,[map[apiVersion:v1 fieldsType:FieldsV1 fieldsV1:map[f:metadata:map[f:generateName:map[] f:labels:map[.:map[] f:app:map[] f:pod-template-hash:map[]] f:ownerReferences:map[.:map[] k:{"uid":"39912344-d707-4029-8da8-5269cfcae9e9"}:map[.:map[] f:apiVersion:map[] f:blockOwnerDeletion:map[] f:controller:map[] f:kind:map[] f:name:map[] f:uid:map[]]]] f:spec:map[f:containers:map[k:{"name":"nfs-client-provisioner"}:map[.:map[] f:env:map[.:map[] k:{"name":"NFS_PATH"}:map[.:map[] f:name:map[] f:value:map[]] k:{"name":"NFS_SERVER"}:map[.:map[] f:name:map[] f:value:map[]] k:{"name":"PROVISIONER_NAME"}:map[.:map[] f:name:map[] f:value:map[]]] f:image:map[] f:imagePullPolicy:map[] f:name:map[] f:resources:map[] f:terminationMessagePath:map[] f:terminationMessagePolicy:map[] f:volumeMounts:map[.:map[] k:{"mountPath":"/persistentvolumes"}:map[.:map[] f:mountPath:map[] f:name:map[]]]]] f:dnsPolicy:map[] f:enableServiceLinks:map[] f:restartPolicy:map[] f:schedulerName:map[] f:securityContext:map[] f:serviceAccount:map[] f:serviceAccountName:map[] f:terminationGracePeriodSeconds:map[] f:volumes:map[.:map[] k:{"name":"nfs-client-root"}:map[.:map[] f:name:map[] f:nfs:map[.:map[] f:path:map[] f:server:map[]]]]]] manager:kube-controller-manager operation:Update time:2021-07-06T04:08:48Z] map[apiVersion:v1 fieldsType:FieldsV1 fieldsV1:map[f:status:map[f:conditions:map[.:map[] k:{"type":"PodScheduled"}:map[.:map[] f:lastProbeTime:map[] f:lastTransitionTime:map[] f:message:map[] f:reason:map[] f:status:map[] f:type:map[]]]]] manager:kube-scheduler operation:Update time:2021-07-06T04:08:49Z] map[apiVersion:v1 fieldsType:FieldsV1 fieldsV1:map[f:metadata:map[f:annotations:map[.:map[] f:tke.cloud.tencent.com/networks-status:map[]]]] manager:multus operation:Update time:2021-07-06T04:09:24Z] map[apiVersion:v1 fieldsType:FieldsV1 fieldsV1:map[f:status:map[f:conditions:map[k:{"type":"ContainersReady"}:map[.:map[] f:lastProbeTime:map[] f:lastTransitionTime:map[] f:status:map[] f:type:map[]] k:{"type":"Initialized"}:map[.:map[] f:lastProbeTime:map[] f:lastTransitionTime:map[] f:status:map[] f:type:map[]] k:{"type":"Ready"}:map[.:map[] f:lastProbeTime:map[] f:lastTransitionTime:map[] f:status:map[] f:type:map[]]] f:containerStatuses:map[] f:hostIP:map[] f:phase:map[] f:podIP:map[] f:podIPs:map[.:map[] k:{"ip":"172.16.0.87"}:map[.:map[] f:ip:map[]]] f:startTime:map[]]] manager:kubelet operation:Update time:2021-08-02T23:00:33Z]],nfs-client-provisioner-54f4485448-kwr45,/api/v1/namespaces/default/pods/nfs-client-provisioner-54f4485448-kwr45,9c445349-42ce-4e38-b20a-41bb47587d7e,map[tke.cloud.tencent.com/networks-status:[{ 
4.     "name": "tke-bridge", 
5.     "ips": [ 
6.         "172.16.0.87" 
7.     ], 
8.     "default": true, 
9.     "dns": {} 
10. }]] 
11. ...... 

选择所有具有指定名称的字段，无论其位置如何

1. ➜  ~ kubectl get pods -o custom-columns='IMAGE:..image' 
2. IMAGE 
3. cnych/nfs-subdir-external-provisioner:v4.0.2,cnych/nfs-subdir-external-provisioner:v4.0.2 
4. nginx:latest,nginx:latest 

其中的 [ ] 运算符特别重要，Kubernetes 资源的许多字段都是列表，使用此运算符可以选择这些列表中的某一些元素，它通常与通配符一起使用 [*]，以选择列表中的所有项目。

示例应用程序

使用自定义列输出格式有无限可能，因为你可以在输出中显示资源的任何字段或字段组合。以下是一些示例应用程序，但你可以自己探索并找到对你有用的应用程序。

提示：如果你经常使用这些命令，则可以为其创建一个 shell 别名。

显示 Pod 的容器镜像

1. ➜  ~ kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image' 
2. NAME                                      IMAGES 
3. nfs-client-provisioner-54f4485448-kwr45   cnych/nfs-subdir-external-provisioner:v4.0.2 
4. nginx                                     nginx 
5. nginx-674ff86d-t6gbd                      nginx:latest 

此命令显示每个 Pod 的所有容器镜像的名称。因为一个 Pod 可能包含多个容器。在这种情况下，单个 Pod 的容器镜像在同一列中显示为由逗号分隔的列表。

显示节点的可用区

1. ➜  ~ kubectl get nodes \ 
2.   -o custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain\.beta\.kubernetes\.io/zone' 
3. NAME         ZONE 
4. 172.27.0.2   160001 

如果你的 Kubernetes 集群部署在公有云上，则此命令很有用，它显示每个节点所在的可用区。每个节点的可用区均通过特殊的 failure-domain.beta.kubernetes.io/zone 标签获得，如果集群在公有云基础架构上运行，则将自动创建此标签，并将其值设置为节点的可用性区域的名称。

标签不是 Kubernetes 资源规范的一部分，但是，如果将节点输出为 YAML 或 JSON，则可以看到它的相关信息：

1. kubectl get nodes -o yaml 
2. # or 
3. kubectl get nodes -o json 

多集群和命名空间切换

当 kubectl 向 Kubernetes API 发出请求时，它将读取 kubeconfig 文件，以获取它需要访问的所有连接参数并向 APIServer 发出请求。默认的 kubeconfig 文件是 ~/.kube/config，在使用多个集群时，在 kubeconfig 文件中配置了多个集群的连接参数，所以我们需要一种方法来告诉 kubectl 要将其连接到哪个集群中。在集群中，我们可以设置多个命名空间，Kubectl 还可确定 kubeconfig 文件中用于请求的命名空间，所以同样我们需要一种方法来告诉 kubectl 要使用哪个命名空间。

此外我们还可以通过在 KUBECONFIG 环境变量来设置它们，还可以为每个 kubectl 命令使用 --kubeconfig 选项覆盖默认的 kubeconfig 文件。

kubeconfig

kubeconfig 文件由一组上下文组成，上下文包含以下三个元素：

• Cluster：集群的 API server 地址
• User：集群中特定用户的身份验证凭据
• Namespace：连接到集群时要使用的命名空间

通常大部分用户在其 kubeconfig 文件中为每个集群使用单个上下文，但是，每个集群也可以有多个上下文，它们的用户或命名空间不同，但并不太常见，因此集群和上下文之间通常存在一对一的映射。

在任何指定时间，这些上下文其中之一都可以被设置为当前上下文：

当 kubectl 读取 kubeconfig 文件时，它总是使用当前上下文中的信息，所以在上面的示例中，kubectl 将连接到 Hare 集群。因此，要切换到另一个集群时，你只需在 kubeconfig 文件中更改当前上下文即可：

这样 kubectl 现在将连接到 Fox 集群，并切换到同一集群中的另一个命名空间，可以更改当前上下文的命名空间元素的值：

在上面的示例中，kubectl 现在将在 Fox 集群中使用 Prod 命名空间，而不是之前设置的 Test 命名空间了。理论上讲，我们可以通过手动编辑 kubeconfig 文件来进行这些更改，kubectl config 也命令提供了用于编辑 kubeconfig 文件的子命令：

• kubectl config get-contexts：列出所有上下文
• kubectl config current-context：获取当前上下文
• kubectl config use-context：更改当前上下文
• kubectl config set-context：更改上下文的元素

比如现在我有两个 kubeconfig 文件，分别连接两个集群，现在我们可以使用下面的命令来合并两个 kubeconfig 文件：

1. ➜  ~ cp $HOME/.kube/config $HOME/.kube/config.backup.$(date +%Y-%m-%d.%H:%M:%S) 
2. KUBECONFIG=$HOME/.kube/config:$HOME/.kube/ydzs-config kubectl config view --merge --flatten > $HOME/.kube/merged_kubeconfig && mv $HOME/.kube/merged_kubeconfig $HOME/.kube/config 
3. ➜  ~ kubectl config get-contexts 
4. CURRENT   NAME                           CLUSTER   AUTHINFO           NAMESPACE 
5.           cls-9kl736yn-context-default   tke       admin 
6. *         kubernetes-admin@kubernetes    local     kubernetes-admin   default 

通过上面的命令可以将两个 kubeconfig 合并到一起，我们可以看到现在有两个集群和两个上下文，在操作资源对象的时候可以通过使用参数 --context 来指定操作的集群：

1. ➜  ~ kubectl get pods --context=cls-9kl736yn-context-default 
2. NAME                                      READY   STATUS    RESTARTS   AGE 
3. nfs-client-provisioner-54f4485448-kwr45   1/1     Running   1          67d 
4. nginx-674ff86d-t6gbd                      1/1     Running   0          67d 
5. ➜  ~ kubectl get pods --context=kubernetes-admin@kubernetes 
6. NAME                                      READY   STATUS    RESTARTS   AGE 
7. nginx                                     1/1     Running   0          26d 

我们可以看到操作的时候是非常繁琐的，下面我们使用其他的工具来帮助我们自动进行这些更改。

Kubectx

Kubectx 可以有效帮助我们在集群和命名空间之间进行切换，该工具提供了 kubectx 和 kubens 命令，使我们可以分别更改当前上下文和命名空间。如果每个集群只有一个上下文，则更改当前上下文意味着更改集群。

如果我们已经安装过 kubectl 插件管理工具 Krew，则直接使用下面的命令来安装 Kubectx 插件即可：

1. kubectl krew install ctx 
2. kubectl krew install ns 

安装完成后，可以使用 kubectl ctx 和 kubectl ns 命令进行操作。但是需要注意这种方式不会安装 shell 自动补全脚本，如果需要，可以使用另外的方式进行安装，比如 macOS 下面使用 Homebrew 进行安装：

1. brew install kubectx 

此安装命令将自动设置 bash/zsh/fish 自动补全脚本，由于经常需要切换不同的集群，很可能会误操作集群，这个时候有个提示就很棒了，我们可以使用 kube-ps1 工具来修改 PS1。

不过由于我这里本地使用的是 oh-my-zsh，所以可以不用安装，直接在 ~/.zshrc 开启 plugin 加上 kube-ps1 就可以了，然后自定义一下，重新 source 下即可：

1. PROMPT='$(kube_ps1)'$PROMPT 
2. KUBE_PS1_PREFIX="" 
3. KUBE_PS1_SYMBOL_DEFAULT="" 
4. KUBE_PS1_DIVIDER="-" 
5. KUBE_PS1_SUFFIX=" " 

现在我们只需要输入 kubectx 命令就可以切换集群了：

由于我们配置了 kube-ps1，所以在操作的终端前面也直接显示了当前操作的集群，防止操作集群错误。

kubectx 的另一个十分有用的功能是交互模式，这需要与 fzf 工具一起工作(安装 fzf 会自动启用kubectx交互模式)。交互式模式允许你通过交互式模糊搜索界面选择目标上下文或命名空间。

kubectl 插件

从1.12版开始，kubectl 就提供了插件机制，可让你使用自定义命令扩展 kubectl，Kubectl 插件作为简单的可执行文件分发，名称形式为 kubectl-x，前缀 kubectl- 是必填项，其后是允许调用插件的新的 kubectl 子命令。

要安装插件，你只需要将 kubectl-x 文件复制到 PATH 中的任何目录并使其可执行，之后，你可以立即使用 kubectl x 调用插件。你可以使用以下命令列出系统上当前安装的所有插件：

1. kubectl plugin list 

Kubectl 插件可以像软件包一样共享和重用，但是在哪里可以找到其他人共享的插件?Krew 项目旨在为共享、查找、安装和管理 kubectl 插件提供统一的解决方案。Krew 根据 kubectl 插件进行索引，你可以从中选择和安装。当然 krew 本身就是一个 kubectl 插件，这意味着，安装 krew 本质上就像安装其他任何 kubectl 插件一样。你可以在GitHub页面上找到krew的详细安装说明：https://github.com/kubernetes-sigs/krew。

下面是一些重要的 krew 命令：

1. # Search the krew index (with an optional search query) 
2. kubectl krew search [<query>] 
3.  
4. # Display information about a plugin 
5. kubectl krew info <plugin> 
6.  
7. # Install a plugin 
8. kubectl krew install <plugin> 
9.  
10. # Upgrade all plugins to the newest versions 
11. kubectl krew upgrade 
12.  
13. # List all plugins that have been installed with krew 
14. kubectl krew list 
15.  
16. # Uninstall a plugin 
17. kubectl krew remove <plugin> 

需要注意 kubectl krew list 命令仅列出已与 krew 一起安装的插件，而 kubectl plugin list 命令列出了所有插件，即与 krew 一起安装的插件和以其他方式安装的插件。

创建插件

我们也可以很方便创建自己的 kubectl 插件，只需要创建一个执行所需操作的可执行文件，将其命名为 kubectl-x，然后按照如上所述的方式安装即可。可执行文件可以是任何类型，可以是 Bash 脚本、已编译的 Go 程序、Python 脚本，这些类型实际上并不重要。唯一的要求是它可以由操作系统直接执行。

让我们现在创建一个示例插件。前面我们使用 kubectl 命令列出每个 Pod 的容器镜像，我们可以轻松地将此命令转换为可以使用 kubectl img 调用的插件。只需创建一个名为 kubectl-img 的文件，其内容如下：

1. #!/bin/bash 
2. kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image' 

现在，使用 chmod + x kubectl-img 使该文件可执行，并将其移动到 PATH 中的任何目录，之后，你可以立即将插件与 kubectl img 一起使用了：

1. ➜  ~ kubectl img 
2. NAME                                      IMAGES 
3. nfs-client-provisioner-54f4485448-kwr45   cnych/nfs-subdir-external-provisioner:v4.0.2 
4. nginx-674ff86d-t6gbd                      nginx:latest 

kubectl 插件可以用任何编程或脚本语言编写，如果使用 Shell 脚本，则具有可以轻松从插件调用 kubectl 的优势。但是，你可以使用真实的编程语言编写更复杂的插件，例如使用 Kubernetes 客户端库，如果使用 Go，还可以使用 cli-runtime 库，该库专门用于编写 kubectl 插件。