讓我們看一個(gè)簡(jiǎn)單的例子：

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

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

現(xiàn)在，假設(shè)你想在輸出中添加一個(gè)附加列，比如顯示每個(gè) Pod 在其上運(yùn)行的節(jié)點(diǎn)，那么我們只需在自定義列選項(xiàng)中添加適當(dāng)?shù)牧幸?guī)范即可：

➜  ~ 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 

選擇節(jié)點(diǎn)名稱的表達(dá)式是 spec.nodeName，這是因?yàn)橐褜?Pod 調(diào)度的節(jié)點(diǎn)保存在 Pod 的 spec.nodeName 字段中了。不過需要請(qǐng)注意的是 Kubernetes 資源字段是區(qū)分大小寫的。

我們可以通過這種方式將資源的任何字段設(shè)置為輸出列，只需瀏覽資源規(guī)范并嘗試使用任何你喜歡的字段即可。當(dāng)然我們需要對(duì)字段選擇的 JSONPath 表達(dá)式要有一定的了解。

JSONPath 表達(dá)式

用于選擇資源字段的表達(dá)式基于 JSONPath 的。JSONPath 是一種用于從 JSON 文檔提取數(shù)據(jù)的語(yǔ)言(類似于 XPath for XML)，選擇單個(gè)字段只是 JSONPath 的最基本用法，它還有很多其他功能，例如 list selector、filter 等。

但是，kubectl explain 僅支持 JSONPath 功能的子集，下面我們通過一些示例用法來總結(jié)下這些使用規(guī)則：

選擇一個(gè)列表的所有元素

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

選擇一個(gè)列表的指定元素

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

選擇匹配過濾表達(dá)式的列表元素

➜  ~ 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": {} 
}]] 
...... 

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

➜  ~ 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 

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

示例應(yīng)用程序

使用自定義列輸出格式有無(wú)限可能，因?yàn)槟憧梢栽谳敵鲋酗@示資源的任何字段或字段組合。以下是一些示例應(yīng)用程序，但你可以自己探索并找到對(duì)你有用的應(yīng)用程序。

提示：如果你經(jīng)常使用這些命令，則可以為其創(chuàng)建一個(gè) 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 

此命令顯示每個(gè) Pod 的所有容器鏡像的名稱。因?yàn)橐粋€(gè) Pod 可能包含多個(gè)容器。在這種情況下，單個(gè) Pod 的容器鏡像在同一列中顯示為由逗號(hào)分隔的列表。

顯示節(jié)點(diǎn)的可用區(qū)

➜  ~ 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 集群部署在公有云上，則此命令很有用，它顯示每個(gè)節(jié)點(diǎn)所在的可用區(qū)。每個(gè)節(jié)點(diǎn)的可用區(qū)均通過特殊的 failure-domain.beta.kubernetes.io/zone 標(biāo)簽獲得，如果集群在公有云基礎(chǔ)架構(gòu)上運(yùn)行，則將自動(dòng)創(chuàng)建此標(biāo)簽，并將其值設(shè)置為節(jié)點(diǎn)的可用性區(qū)域的名稱。

標(biāo)簽不是 Kubernetes 資源規(guī)范的一部分，但是，如果將節(jié)點(diǎn)輸出為 YAML 或 JSON，則可以看到它的相關(guān)信息：

kubectl get nodes -o yaml 
# or 
kubectl get nodes -o json 

多集群和命名空間切換

當(dāng) kubectl 向 Kubernetes API 發(fā)出請(qǐng)求時(shí)，它將讀取 kubeconfig 文件，以獲取它需要訪問的所有連接參數(shù)并向 APIServer 發(fā)出請(qǐng)求。默認(rèn)的 kubeconfig 文件是 ~/.kube/config，在使用多個(gè)集群時(shí)，在 kubeconfig 文件中配置了多個(gè)集群的連接參數(shù)，所以我們需要一種方法來告訴 kubectl 要將其連接到哪個(gè)集群中。在集群中，我們可以設(shè)置多個(gè)命名空間，Kubectl 還可確定 kubeconfig 文件中用于請(qǐng)求的命名空間，所以同樣我們需要一種方法來告訴 kubectl 要使用哪個(gè)命名空間。

此外我們還可以通過在 KUBECONFIG 環(huán)境變量來設(shè)置它們，還可以為每個(gè) kubectl 命令使用 --kubeconfig 選項(xiàng)覆蓋默認(rèn)的 kubeconfig 文件。

kubeconfig

kubeconfig 文件由一組上下文組成，上下文包含以下三個(gè)元素：

• Cluster：集群的 API server 地址
• User：集群中特定用戶的身份驗(yàn)證憑據(jù)
• Namespace：連接到集群時(shí)要使用的命名空間

通常大部分用戶在其 kubeconfig 文件中為每個(gè)集群使用單個(gè)上下文，但是，每個(gè)集群也可以有多個(gè)上下文，它們的用戶或命名空間不同，但并不太常見，因此集群和上下文之間通常存在一對(duì)一的映射。

在任何指定時(shí)間，這些上下文其中之一都可以被設(shè)置為當(dāng)前上下文：

當(dāng) kubectl 讀取 kubeconfig 文件時(shí)，它總是使用當(dāng)前上下文中的信息，所以在上面的示例中，kubectl 將連接到 Hare 集群。因此，要切換到另一個(gè)集群時(shí)，你只需在 kubeconfig 文件中更改當(dāng)前上下文即可：

這樣 kubectl 現(xiàn)在將連接到 Fox 集群，并切換到同一集群中的另一個(gè)命名空間，可以更改當(dāng)前上下文的命名空間元素的值：

在上面的示例中，kubectl 現(xiàn)在將在 Fox 集群中使用 Prod 命名空間，而不是之前設(shè)置的 Test 命名空間了。理論上講，我們可以通過手動(dòng)編輯 kubeconfig 文件來進(jìn)行這些更改，kubectl config 也命令提供了用于編輯 kubeconfig 文件的子命令：

• kubectl config get-contexts：列出所有上下文
• kubectl config current-context：獲取當(dāng)前上下文
• kubectl config use-context：更改當(dāng)前上下文
• kubectl config set-context：更改上下文的元素

比如現(xiàn)在我有兩個(gè) kubeconfig 文件，分別連接兩個(gè)集群，現(xiàn)在我們可以使用下面的命令來合并兩個(gè) 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 

通過上面的命令可以將兩個(gè) kubeconfig 合并到一起，我們可以看到現(xiàn)在有兩個(gè)集群和兩個(gè)上下文，在操作資源對(duì)象的時(shí)候可以通過使用參數(shù) --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 

我們可以看到操作的時(shí)候是非常繁瑣的，下面我們使用其他的工具來幫助我們自動(dòng)進(jìn)行這些更改。

Kubectx

Kubectx 可以有效幫助我們?cè)诩汉兔臻g之間進(jìn)行切換，該工具提供了 kubectx 和 kubens 命令，使我們可以分別更改當(dāng)前上下文和命名空間。如果每個(gè)集群只有一個(gè)上下文，則更改當(dāng)前上下文意味著更改集群。

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

kubectl krew install ctx 
kubectl krew install ns 

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

brew install kubectx 

此安裝命令將自動(dòng)設(shè)置 bash/zsh/fish 自動(dòng)補(bǔ)全腳本，由于經(jīng)常需要切換不同的集群，很可能會(huì)誤操作集群，這個(gè)時(shí)候有個(gè)提示就很棒了，我們可以使用 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=" " 

現(xiàn)在我們只需要輸入 kubectx 命令就可以切換集群了：

由于我們配置了 kube-ps1，所以在操作的終端前面也直接顯示了當(dāng)前操作的集群，防止操作集群錯(cuò)誤。

kubectx 的另一個(gè)十分有用的功能是交互模式，這需要與 fzf 工具一起工作(安裝 fzf 會(huì)自動(dòng)啟用kubectx交互模式)。交互式模式允許你通過交互式模糊搜索界面選擇目標(biāo)上下文或命名空間。

kubectl 插件

從1.12版開始，kubectl 就提供了插件機(jī)制，可讓你使用自定義命令擴(kuò)展 kubectl，Kubectl 插件作為簡(jiǎn)單的可執(zhí)行文件分發(fā)，名稱形式為 kubectl-x，前綴 kubectl- 是必填項(xiàng)，其后是允許調(diào)用插件的新的 kubectl 子命令。

要安裝插件，你只需要將 kubectl-x 文件復(fù)制到 PATH 中的任何目錄并使其可執(zhí)行，之后，你可以立即使用 kubectl x 調(diào)用插件。你可以使用以下命令列出系統(tǒng)上當(dāng)前安裝的所有插件：

kubectl plugin list 

Kubectl 插件可以像軟件包一樣共享和重用，但是在哪里可以找到其他人共享的插件?Krew 項(xiàng)目旨在為共享、查找、安裝和管理 kubectl 插件提供統(tǒng)一的解決方案。Krew 根據(jù) kubectl 插件進(jìn)行索引，你可以從中選擇和安裝。當(dāng)然 krew 本身就是一個(gè) kubectl 插件，這意味著，安裝 krew 本質(zhì)上就像安裝其他任何 kubectl 插件一樣。你可以在GitHub頁(yè)面上找到krew的詳細(xì)安裝說明：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 一起安裝的插件和以其他方式安裝的插件。

創(chuàng)建插件

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

讓我們現(xiàn)在創(chuàng)建一個(gè)示例插件。前面我們使用 kubectl 命令列出每個(gè) Pod 的容器鏡像，我們可以輕松地將此命令轉(zhuǎn)換為可以使用 kubectl img 調(diào)用的插件。只需創(chuàng)建一個(gè)名為 kubectl-img 的文件，其內(nèi)容如下：

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

現(xiàn)在，使用 chmod + x kubectl-img 使該文件可執(zhí)行，并將其移動(dòng)到 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 插件可以用任何編程或腳本語(yǔ)言編寫，如果使用 Shell 腳本，則具有可以輕松從插件調(diào)用 kubectl 的優(yōu)勢(shì)。但是，你可以使用真實(shí)的編程語(yǔ)言編寫更復(fù)雜的插件，例如使用 Kubernetes 客戶端庫(kù)，如果使用 Go，還可以使用 cli-runtime 庫(kù)，該庫(kù)專門用于編寫 kubectl 插件。