讓我們看一個簡單的例子：

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

在這里，輸出包括顯示所有 Pod 名稱的一列，選擇 Pod 名稱的表達式是 meta.name，因為 Pod 的名稱是在 Pod 資源的 metadata 屬性下面的 name 字段中定義的(我們可以使用 kubectl explain pod.metadata.name 進行查找)。

現在，假設你想在輸出中添加一個附加列，比如顯示每個 Pod 在其上運行的節點，那么我們只需在自定義列選項中添加適當的列規范即可：

➜  ~ kubectl get pods -o custom-columns='NAME:metadata.name,NODE:spec.nodeName' 
NAME                                      NODE 
nfs-client-provisioner-54f4485448-kwr45   172.27.0.2 
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 功能的子集，下面我們通過一些示例用法來總結下這些使用規則：

選擇一個列表的所有元素

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

選擇一個列表的指定元素

# 獲取Pod下面第一個容器的鏡像 
➜  ~ kubectl get pods -o custom-columns='IMAGE:spec.containers[0].image' 
IMAGE 
cnych/nfs-subdir-external-provisioner:v4.0.2 
nginx:latest 

選擇匹配過濾表達式的列表元素

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

選擇指定位置下的所有字段

➜  ~ kubectl get pods -o custom-columns='DATA:metadata.*' 
DATA 
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:[{ 
    "name": "tke-bridge", 
    "ips": [ 
        "172.16.0.87" 
    ], 
    "default": true, 
    "dns": {} 
}]] 
...... 

選擇所有具有指定名稱的字段，無論其位置如何

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

其中的 [ ] 運算符特別重要，Kubernetes 資源的許多字段都是列表，使用此運算符可以選擇這些列表中的某一些元素，它通常與通配符一起使用 [*]，以選擇列表中的所有項目。

示例應用程序

使用自定義列輸出格式有無限可能，因為你可以在輸出中顯示資源的任何字段或字段組合。以下是一些示例應用程序，但你可以自己探索并找到對你有用的應用程序。

提示：如果你經常使用這些命令，則可以為其創建一個 shell 別名。

顯示 Pod 的容器鏡像

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

此命令顯示每個 Pod 的所有容器鏡像的名稱。因為一個 Pod 可能包含多個容器。在這種情況下，單個 Pod 的容器鏡像在同一列中顯示為由逗號分隔的列表。

顯示節點的可用區

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

如果你的 Kubernetes 集群部署在公有云上，則此命令很有用，它顯示每個節點所在的可用區。每個節點的可用區均通過特殊的 failure-domain.beta.kubernetes.io/zone 標簽獲得，如果集群在公有云基礎架構上運行，則將自動創建此標簽，并將其值設置為節點的可用性區域的名稱。

標簽不是 Kubernetes 資源規范的一部分，但是，如果將節點輸出為 YAML 或 JSON，則可以看到它的相關信息：

kubectl get nodes -o yaml 
# or 
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 文件：

➜  ~ cp $HOME/.kube/config $HOME/.kube/config.backup.$(date +%Y-%m-%d.%H:%M:%S) 
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 
➜  ~ kubectl config get-contexts 
CURRENT   NAME                           CLUSTER   AUTHINFO           NAMESPACE 
          cls-9kl736yn-context-default   tke       admin 
*         kubernetes-admin@kubernetes    local     kubernetes-admin   default 

通過上面的命令可以將兩個 kubeconfig 合并到一起，我們可以看到現在有兩個集群和兩個上下文，在操作資源對象的時候可以通過使用參數 --context 來指定操作的集群：

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

我們可以看到操作的時候是非常繁瑣的，下面我們使用其他的工具來幫助我們自動進行這些更改。

Kubectx

Kubectx 可以有效幫助我們在集群和命名空間之間進行切換，該工具提供了 kubectx 和 kubens 命令，使我們可以分別更改當前上下文和命名空間。如果每個集群只有一個上下文，則更改當前上下文意味著更改集群。

如果我們已經安裝過 kubectl 插件管理工具 Krew，則直接使用下面的命令來安裝 Kubectx 插件即可：

kubectl krew install ctx 
kubectl krew install ns 

安裝完成后，可以使用 kubectl ctx 和 kubectl ns 命令進行操作。但是需要注意這種方式不會安裝 shell 自動補全腳本，如果需要，可以使用另外的方式進行安裝，比如 macOS 下面使用 Homebrew 進行安裝：

brew install kubectx 

此安裝命令將自動設置 bash/zsh/fish 自動補全腳本，由于經常需要切換不同的集群，很可能會誤操作集群，這個時候有個提示就很棒了，我們可以使用 kube-ps1 工具來修改 PS1。

不過由于我這里本地使用的是 oh-my-zsh，所以可以不用安裝，直接在 ~/.zshrc 開啟 plugin 加上 kube-ps1 就可以了，然后自定義一下，重新 source 下即可：

PROMPT='$(kube_ps1)'$PROMPT 
KUBE_PS1_PREFIX="" 
KUBE_PS1_SYMBOL_DEFAULT="" 
KUBE_PS1_DIVIDER="-" 
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 調用插件。你可以使用以下命令列出系統上當前安裝的所有插件：

kubectl plugin list 

Kubectl 插件可以像軟件包一樣共享和重用，但是在哪里可以找到其他人共享的插件?Krew 項目旨在為共享、查找、安裝和管理 kubectl 插件提供統一的解決方案。Krew 根據 kubectl 插件進行索引，你可以從中選擇和安裝。當然 krew 本身就是一個 kubectl 插件，這意味著，安裝 krew 本質上就像安裝其他任何 kubectl 插件一樣。你可以在GitHub頁面上找到krew的詳細安裝說明：https://github.com/kubernetes-sigs/krew。

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

# Search the krew index (with an optional search query) 
kubectl krew search [<query>] 
 
# Display information about a plugin 
kubectl krew info <plugin> 
 
# Install a plugin 
kubectl krew install <plugin> 
 
# Upgrade all plugins to the newest versions 
kubectl krew upgrade 
 
# List all plugins that have been installed with krew 
kubectl krew list 
 
# Uninstall a plugin 
kubectl krew remove <plugin> 

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

創建插件

我們也可以很方便創建自己的 kubectl 插件，只需要創建一個執行所需操作的可執行文件，將其命名為 kubectl-x，然后按照如上所述的方式安裝即可。可執行文件可以是任何類型，可以是 Bash 腳本、已編譯的 Go 程序、Python 腳本，這些類型實際上并不重要。唯一的要求是它可以由操作系統直接執行。

讓我們現在創建一個示例插件。前面我們使用 kubectl 命令列出每個 Pod 的容器鏡像，我們可以輕松地將此命令轉換為可以使用 kubectl img 調用的插件。只需創建一個名為 kubectl-img 的文件，其內容如下：

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

現在，使用 chmod + x kubectl-img 使該文件可執行，并將其移動到 PATH 中的任何目錄，之后，你可以立即將插件與 kubectl img 一起使用了：

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

kubectl 插件可以用任何編程或腳本語言編寫，如果使用 Shell 腳本，則具有可以輕松從插件調用 kubectl 的優勢。但是，你可以使用真實的編程語言編寫更復雜的插件，例如使用 Kubernetes 客戶端庫，如果使用 Go，還可以使用 cli-runtime 庫，該庫專門用于編寫 kubectl 插件。