萬字硬核乾貨！6大kubectl技巧，極速提高生產力！

明晚8:30， k3s實戰課程開啓！將由Rancher研發總監帶你暢遊k3s與邊緣AI的奇妙世界。課程內容徹底由實際使用場景中總結而來，別錯過啦~！訪問如下連接便可傳送到課程現場：

http://z-mz.cn/PmxF

若是你正在使用Kubernetes，那麼kubectl必定是你最常使用的工具。不管你須要學習任何工具，都應該先提早了解kubectl並有效地使用它。本文包含了一系列技巧，可讓你更高效並且有效地使用kubectl。同時，能夠加深你對Kubernetes各個方面工做方式的理解。

本文的目標不只是使你使用Kubernetes的平常工做更高效，並且更愉快！

目  錄

• 什麼是kubectl？
• 使用命令補全功能保存輸入
• 迅速查找資源規範
• 使用自定義列輸出格式
• 輕鬆在集羣和命名空間之間切換
• 使用自動生成別名（Aliases）保存輸入
• 使用插件擴展kubectl

什麼是kubectl

在學習如何更高效地使用kubectl以前，你應該對它是什麼以及如何工做有個基本的瞭解。從用戶的角度來講，kubectl是你控制Kubernetes的「駕駛艙」。它可讓你執行全部可能的Kubernetes操做。

從技術角度上看，kubectl是Kubernetes API的客戶端。Kubernetes API是一個 HTTP REST API。這個API是真正的Kubernetes用戶界面。Kubernetes徹底受這個API控制，這意味着每一個Kubernetes操做都做爲API端點公開，而且能夠由對此端點的HTTP請求執行。所以，kubectl的主要工做是執行對Kubernetes API的HTTP請求：

Kubernetes是一個徹底以資源爲中心的系統。這意味着，Kubernetes維護資源的內部狀態而且全部的Kubernetes操做都是針對這些資源的CRUD（增長、讀取、更新、刪除）操做。你徹底能夠經過操控這些資源（Kubernetes會根據資源的當前狀態找出解決方案）來控制Kubernetes。所以，Kubernetes API reference主要是資源類型及其相關操做的列表。

來，咱們來看一個例子。

假設你想要建立一個ReplicaSet資源。爲了達成此目標，你在一個名爲replicaset.yaml的文件中定義ReplicaSet，而後運行如下命令：

kubectl create -f replicaset.yaml

顯然，在Kubernetes已經建立了你的ReplicaSet。但以後會發生什麼呢？

Kubernetes有一個建立ReplicaSet的操做，而且它和其餘全部Kubernetes操做同樣，都會做爲API端點暴露。對於這個操做而言，該特定API端點以下：

POST /apis/apps/v1/namespaces/{namespace}/replicasets

你能夠在API reference中找到全部Kubernetes操做對應的API端點，包括以上端點（https://kubernetes.io/docs/re... ）。要向端點發出實際請求，你須要一開始就在API reference中列出的端點路徑中添加API server的URL。

所以，當你執行上述命令時，kubectl將向上述API端點發出HTTP POST請求。ReplicaSet定義（你在replicaset.yaml文件中所提供的）在請求的正文中傳遞。

這就是kubectl對於與Kubernetes集羣交互的全部命令的工做方式。在這些狀況下，kubectl只需向適當的Kubernetes API端點發出HTTP請求便可。

請注意，經過手動向Kubernetes API發出HTTP請求，徹底有可能使用curl之類的工具來控制Kubernetes。Kubectl只是讓你更輕鬆地使用Kubernetes API。

以上就是什麼是kubectl及其工做原理的簡單介紹。可是，每一個kubectl用戶都應該瞭解更多有關Kubernetes API的信息。爲此，咱們先簡要地介紹一下Kubernetes的內部結構。

Kubernetes 內部

Kubernetes由一系列獨立組件構成，這些組件會在集羣的節點上做爲單獨的進程運行。一些組件運行在master節點，一些組件運行在worker節點，每一個組件都有其特定功能。

在master節點上，有如下重要組件：

• 存儲後端：存儲資源定義（一般使用etcd）
• API Server：提供Kubernetes API並管理存儲後端
• Controller manager：確保資源狀態與規範相匹配
• Scheduler：將Pod調度到worker節點

在worker節點上最重要的組件爲：

• Kubelet：在worker節點上管理容器的執行

爲了充分了解這些組件是如何一塊兒工做的，讓咱們來看一個例子。

假設你剛剛執行了kubectl create -f replicaset.yaml，此後，kubectl向_create ReplicaSet  API端點_發出了HTTP POST請求（傳遞你的ReplicaSet資源定義）。哪些因素會致使集羣中出現這種狀況？以下：

執行kubectl create -f replicaset.yaml以後，API server將會在存儲後端保存你的ReplicaSet資源定義。

這將觸發controller manager中的ReplicaSet controller，後者監視ReplicaSet資源的建立，更新和刪除。

ReplicaSet controller爲每一個ReplicaSet副本建立了一個Pod定義（根據在ReplicaSet定義中的Pod模板建立）並將它們保存到存儲後端。

這觸發了scheduler，它監視還沒有被分配給worker節點的Pod。

Scheduler爲每一個Pod選擇一個合適的worker節點，並在存儲後端中添加該信息到Pod定義中。

請注意，到目前爲止，集羣中任何地方都沒有運行工做負載的代碼。至今，咱們所完成的事就是在master節點上的存儲後端中建立和更新資源。

這觸發了在Pod所調度到的worker節點上的kubelet，它監視調度到其worker節點上的pod。

Kubelet從存儲後端讀取Pod定義並指示容器運行時（好比，Docker）來運行在worker節點上的容器。

此時，你的ReplicaSet應用程序已經在運行啦！

Kubernetes API的角色

從上述例子可知，Kubernetes組件（除了API server和存儲後端）經過在存儲後端監視資源更改和操控資源工做。然而，這些組件沒法直接訪問存儲後端，僅能經過Kubernetes API進行訪問。

看一下如下示例：

• ReplicaSet controller使用帶有watch參數_的list ReplicaSets API 端點_API操做來監視ReplicaSet資源的更改。
• ReplicaSet controller使用_create Pod API 端點_來建立Pod
• Scheduler使用_patch Pod API端點_以及有關選定的worker節點信息來更新Pod。

正如你所見，這與kubectl所使用的API相同。

Kubernetes API對於內部組件和外部用戶的重複操做是Kubernetes的基本設計概念。如今，咱們來總結一下Kubernetes如何工做的：

1. 存儲後端存儲（如，資源）Kubernetes的狀態
2. API server以Kubernetes API的形式提供到存儲後端的接口
3. 全部其餘Kubernetes的組件和用戶經過Kubernetes API讀取、監視以及操控Kubernetes的狀態（如資源）。

熟悉這些概念將在很大程度上幫助你更好地理解kubectl並利用它。

接下來，咱們來看一下具體的技巧，來幫助你提高kubectl的生產力。

一、 使用命令補全功能保存輸入

命令補全是提升kubectl生產率的最有用但常常被忽略的技巧之一。

命令補全功能使你可使用Tab鍵自動完成kubectl命令的各個部分。這適用於子命令、選項和參數，包括諸如資源名稱之類難以鍵入的內容。

在這裏，你能夠看到kubectl命令的完成狀況：

命令補全可用於Bash和Zsh Shell。

官方文檔中包含有關設置命令完成的詳細說明（https://kubernetes.io/docs/ta...），可是如下部分會簡要向您介紹如何設置。

命令補全功能工做方式

整體而言，命令補全是經過補全腳本而起做用的Shell功能。補全腳本是一個shell腳本，它爲特定命令定義了補全行爲。經過輸入補全腳本能夠補全相應的命令。Kubectl可使用如下命令爲Bash和Zsh自動生成並print out補全腳本：

kubectl completion bash
# or
kubectl completion zsh

理論上，在合適的shell（Bash或Zsh）中提供此命令的輸出將會啓用kubectl的命令補全功能。然而，實際上，在Bash和Zsh之間存在一些細微的差異（包括在Linux和macOS之間也存在差異）。如下部分將對此進行詳細解釋。

Bash on Linux

Bash的補全腳本主要依賴bash-completion項目（https://github.com/scop/bash-...），因此你須要先安裝它。

你可使用不一樣的軟件包管理器安裝bash-completion。如：

sudo apt-get install bash-completion
# or
yum install bash-completion

你可使用如下命令測試bash-completion是否正確安裝：

type \_init\_completion

若是輸出的是shell功能的代碼，那麼bash-completion就已經正確安裝了。若是命令輸出的是not found錯誤，你必須添加如下命令行到你的~/.bashrc文件：

source /usr/share/bash-completion/bash_completion

你是否須要添加這一行到你的~/.bashrc文件中，取決於你用於安裝bash-completion的軟件包管理器。對於APT來講，這是必要的，對於yum則不是。

bash-completion安裝完成以後，你須要進行一些設置，以便在全部的shell會話中得到kubectl補全腳本。一種方法是將如下命令行添加到~/.bashrc文件中：

source  <(kubectl completion bash)

另外一種可能性是將kubectl補充腳本添加到/etc/bash_completion.d目錄中（若是不存在，則須要先建立它）：

kubectl completion bash  >/etc/bash_completion.d/kubectl

/etc/bash_completion.d目錄中的全部補全腳本均由bash-completion自動提供。

以上兩種方法都是同樣的效果。從新加載shell後，kubectl命令補全就能正常工做啦！

Bash on macOS

使用macOS時，會有些複雜。緣由是截至成文時macOS上Bash的默認版本是3.2，這已通過時了。不幸的是，kubectl補全腳本至少須要Bash 4.1，所以不適用於Bash 3.2。

蘋果依舊在macOS上默認使用過期的Bash版本是由於更新版本的Bash使用的是GPLv3 license，而蘋果不支持這一license。

這意味着，要在macOS上使用kubectl命令補全功能，你必須安裝較新版本的Bash。你甚至能夠將其設置爲新的默認shell，這將在未來爲你省去不少此類麻煩。這實際上並不難，你能夠在我以前寫的文章中找到說明：

https://itnext.io/upgrading-b...

在繼續剩下的步驟以前，確保你如今已經在使用Bash 4.1或更高的版本（使用bash --version查看版本）。

同上一部分同樣，Bash的補全腳本主要依賴bash-completion項目（https://github.com/scop/bash-... ），因此你須要先安裝它。

你可使用Homebrew安裝bash-completion：

brew install bash-completion@2

@2表明bash-completion v2。Kubectl補全腳本要求bash-completion v2，而bash-completion v2要求至少是Bash 4.1。這就是你不能在低於4.1的Bash版本上使用kubectl補全腳本的緣由。

brew intall命令的輸出包括一個「Caveats」部分，其中的說明將如下行添加~/.bash_profile文件：

export BASH\_COMPLETION\_COMPAT_DIR=/usr/local/etc/bash_completion.d 
[[ -r "/usr/local/etc/profile.d/bash_completion.sh"  ]]  &&  .  "/usr/local/etc/profile.d/bash_completion.sh"

你必須執行此操做才能完成bash-completion的安裝。可是，我建議將這些行添加到~/.bashrc而不是~/.bash_profile文件中。這能夠確保bash-completion在子shell中也可用。

從新加載shell以後，你可使用如下命令測試bash-completion是否正確安裝：

type \_init\_completion

若是輸出爲shell功能的代碼，意味着一切都設置完成。如今，你須要進行一些設置，以便在全部的shell會話中得到kubectl補全腳本。一種方法是將如下命令行添加到~/.bashrc文件中：

source  <(kubectl completion bash)

另外一種方法是將kubectl補全腳本添加到/usr/local/etc/bash_completion.d目錄中：

kubectl completion bash  >/usr/local/etc/bash_completion.d/kubectl

僅當你使用Homebrew安裝了bash-completion時，此方法纔有效。在這種狀況下，bash-completion會在此目錄中提供全部補全腳本。

若是你還用Homebrew安裝了kubectl，則甚至沒必要執行上述步驟，由於補全腳本應該已經由kubectl Homebrew公式放置在/usr/local/etc/bash_completion.d目錄中。在這種狀況下，kubectl補全應該在安裝bash-completion後自動開始工做。全部方法都是效果都是一致的。

從新加載shell後，kubectl完成就能正常工做！

Zsh

Zsh的補全腳本沒有任何依賴項。因此，你所須要作的是去進行一些設置，以便它能在全部的shell會話中被獲取到。

你能夠經過添加如下命令行到你的~/.zshrc文件中來實現這一效果：

source  <(kubectl completion zsh)

若是在從新加載你的shell以後，你得到了command not found: compdef錯誤，你須要啓動內置的compdef，你能夠在將如下行添加到開始的~/.zshrc文件中：

autoload -Uz compinit 
compinit

二、迅速查看資源規範

當你建立YAML資源定義時，你須要知道字段以及這些資源的意義。API reference中提供了一個查找此類信息的位置，其中包含全部資源的完整規範：

https://kubernetes.io/docs/re...

然而，每次你須要查找某些內容時都要切換到Web瀏覽器，這十分繁瑣。所以，kubectl提供了kubectl explain命令，它能在你的terminal中正確地輸入全部資源規範。

kubectl explain的用法以下：

kubectl explain resource\[.field\]...

該命令輸出所請求資源或字段的規範。kubectl explain所顯示的信息與API reference中的信息相同。默認狀況下，kubectl explain僅顯示單個級別的字段。你可使用--recursive標誌來顯示全部級別的字段：

kubectl explain deployment.spec --recursive

若是你不肯定哪一個資源名稱能夠用於kubectl explain，你可使用如下命令查看：

kubectl api-resources

該命令以複數形式顯示資源名稱（如deployments）。它同時顯示資源名稱的縮寫（如deploy）。無需擔憂這些差異，全部名稱變體對於kubectl都是等效的。也就是說，你可使用它們中的任何一個。

例如，如下命令效果都是同樣的：

kubectl explain deployments.spec
# or
kubectl explain deployment.spec
# or
kubectl explain deploy.spec

三、 使用自定義列輸出格式

kubectl get命令默認的輸出方式以下（該命令用於讀取資源）：

kubectl get pods
NAME                      READY   STATUS    RESTARTS   AGE
engine-544b6b6467-22qr6   1/1     Running   0          78d
engine-544b6b6467-lw5t8   1/1     Running   0          78d
engine-544b6b6467-tvgmg   1/1     Running   0          78d
web-ui-6db964458-8pdw4    1/1     Running   0          78d

這是一種很好的可讀格式，可是它僅包含有限的信息量。如你所見，每一個資源僅顯示了一些字段，而不是完整的資源定義。此時，自定義列輸出格式應運而生，它使你能夠自由定義列和想在其中顯示的數據。你能夠選擇資源的任何字段，使其在輸出中顯示爲單獨的列。

自定義列輸出選項的用法以下：

-o custom-columns=<header>:<jsonpath>\[,<header>:<jsonpath>\]...

你必須將每一個輸出列定義爲<header>：<jsonpath>對：

• <header>是列的名稱，你能夠選擇任何所需的內容。
• <jsonpath>是一個選擇資源字段的表達式（下面將詳細說明）。

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

kubectl get pods -o custom-columns='NAME:metadata.name'
NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

在這裏，輸出包括顯示全部Pod名稱的一列。

選擇Pod名稱的表達式是meta.name。緣由是Pod的名稱是在Pod資源的元數據字段的name字段中定義的（你能夠在API reference中或使用kubectl explain pod.metadata.name進行查找）。

如今，假設你想在輸出中添加一個附加列，例如，顯示每一個Pod在其上運行的節點。爲此，你只需在自定義列選項中添加適當的列規範便可：

kubectl get pods \
  -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'
NAME                      NODE
engine-544b6b6467-22qr6   ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8   ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg   ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4    ip-10-0-118-34.ec2.internal

選擇節點名稱的表達式是spec.nodeName。這是由於已將Pod調度的節點保存在Pod的spec.nodeName字段中（請參閱kubectl explain pod.spec.nodeName）。

請注意，Kubernetes資源字段區分大小寫。

你能夠經過這種方式將資源的任何字段設置爲輸出列。只需瀏覽資源規範並嘗試使用任何你喜歡的字段便可！

可是首先，讓咱們仔細看看這些字段選擇表達式。

JSONPath 表達式

用於選擇資源字段的表達式基於JSONPath：

https://goessner.net/articles...

JSONPath是一種用於從JSON文檔提取數據的語言（相似於XPath for XML）。選擇單個字段只是JSONPath的最基本用法。它具備不少功能，例如list selector、filter等。

可是，kubectl explain，僅支持JSONPath功能的子集。如下經過示例用法總結了這些獲得支持的功能：

# Select all elements of a list
kubectl get pods -o custom-columns='DATA:spec.containers[*].image'

# Select a specific element of a list
kubectl get pods -o custom-columns='DATA:spec.containers[0].image'

# Select those elements of a list that match a filter expression
kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'

# Select all fields under a specific location, regardless of their name
kubectl get pods -o custom-columns='DATA:metadata.*'

# Select all fields with a specific name, regardless of their location
kubectl get pods -o custom-columns='DATA:..image'

特別重要的是[ ]運算符。Kubernetes資源的許多字段都是列表，使用此運算符能夠選擇這些列表中的項目。它一般與通配符一塊兒用做[*]，以選擇列表中的全部項目。

在下面，你將找到一些使用此符號的示例。

示例應用程序

使用自定義列輸出格式有無限可能，由於你能夠在輸出中顯示資源的任何字段或字段組合。如下是一些示例應用程序，但你能夠本身探索並找到對你有用的應用程序。

Tip：若是你常用這些命令，則能夠爲其建立一個shell別名。

顯示Pod的容器鏡像

kubectl get pods \
  -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'
NAME                       IMAGES
engine-544b6b6467-22qr6    rabbitmq:3.7.8-management,nginx
engine-544b6b6467-lw5t8    rabbitmq:3.7.8-management,nginx
engine-544b6b6467-tvgmg    rabbitmq:3.7.8-management,nginx
web-ui-6db964458-8pdw4     wordpress

此命令顯示每一個Pod的全部容器鏡像的名稱。

請記住，一個Pod可能包含多個容器。在這種狀況下，單個Pod的容器鏡像在同一列中顯示爲由逗號分隔的列表。

顯示節點的可用區

kubectl get nodes \
  -o custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain\.beta\.kubernetes\.io/zone'
NAME                          ZONE
ip-10-0-118-34.ec2.internal   us-east-1b
ip-10-0-36-80.ec2.internal    us-east-1a
ip-10-0-80-67.ec2.internal    us-east-1b

若是您的Kubernetes集羣部署在公有云基礎架構（例如AWS，Azure或GCP）上，則此命令頗有用。它顯示每一個節點所在的可用區。

可用區是一個公有云的概念，表示一個地理區域內的複製點。

每一個節點的可用區均經過特殊的failure-domain.beta.kubernetes.io/zone 標籤得到。若是集羣在公有云基礎架構上運行，則將自動建立此標籤，並將其值設置爲節點的可用性區域的名稱。

標籤不是Kubernetes資源規範的一部分，所以您沒法在API reference中找到以上標籤。可是，若是將節點輸出爲YAML或JSON，則能夠看到它（以及全部其餘標籤）：

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

除了探索資源規範外，這一般是發現更多有關資源的信息的好方法。

四、輕鬆在集羣和命名空間之間切換

當kubectl必須向Kubernetes API發出請求時，它將讀取系統上的所謂kubeconfig文件，以獲取它須要訪問的全部鏈接參數並向API服務器發出請求。

默認的kubeconfig文件是〜/ .kube / config。該文件一般是經過某些命令自動建立或更新的（例如，若是使用託管的Kubernetes服務，則爲aws eks update-kubeconfig或gcloud container clusters get-credentials）。

使用多個集羣時，在kubeconfig文件中配置了多個集羣的鏈接參數。這意味着，你須要一種方法來告訴kubectl要將其鏈接到哪些集羣中。

在集羣中，您能夠設置多個命名空間（命名空間是物理集羣中的一種「虛擬」集羣）。Kubectl還可肯定kubeconfig文件中用於請求的命名空間。所以，你須要一種方法來告訴kubectl你要使用哪一個命名空間。

請注意，您還能夠經過在KUBECONFIG環境變量中列出它們，以擁有多個kubeconfig文件。在這種狀況下，全部這些文件將在執行時合併爲一個有效的配置。你還能夠爲每一個kubectl命令使用--kubeconfig選項覆蓋默認的kubeconfig文件。具體請參閱官方文檔：

https://kubernetes.io/docs/co...

Kubeconfig文件

讓咱們看看kubeconfig文件實際包含什麼：

如你所見，kubeconfig文件由一組上下文組成。上下文包含如下三個元素：

• 集羣：集羣的API server的URL
• 用戶：集羣中特定用戶的身份驗證憑據
• 命名空間：鏈接到集羣時要使用的命名空間

實際上，人們一般在其kubeconfig文件中爲每一個集羣使用單個上下文。可是，每一個集羣也能夠有多個上下文，它們的用戶或命名空間不一樣。但這彷佛不太常見，所以集羣和上下文之間一般存在一對一的映射。

在任何給定時間中，這些上下文其中之一均可以被設置爲當前上下文（經過kubeconfig文件中的專用字段）：

當kubectl讀取kubeconfig文件時，它老是使用當前上下文中的信息。所以，在上面的示例中，kubectl將鏈接到Hare集羣。

所以，要切換到另外一個集羣時，你只需在kubeconfig文件中更改當前上下文便可：

在上面的示例中，kubectl如今將鏈接到Fox集羣。

並切換到同一集羣中的另外一個命名空間，能夠更改當前上下文的命名空間元素的值：

在上面的示例中，kubectl如今將在Fox集羣中使用Prod命名空間（而不是以前設置的Test命名空間）。

請注意，kubectl還提供了—cluster、-user、-namespace和--context選項，不管kubeconfig文件中設置了什麼，它們均可以覆蓋單個元素和當前上下文自己。請參閱kubectl options

從理論上講，你能夠經過手動編輯kubeconfig文件來進行這些更改。可是，這十分繁瑣。如下各節介紹了各類工具，可以讓你自動進行這些更改。

Kubectx

Kubectx能夠有效幫助集羣和命名空間之間進行切換。該工具提供了kubectx和kubens命令，使你能夠分別更改當前上下文和命名空間。

如前所述，若是每一個集羣只有一個上下文，則更改當前上下文意味着更改集羣。

在這裏，你能夠看到這兩個命令的做用：

如上一節所述，這些命令僅需在後臺編輯kubeconfig文件便可。

要安裝kubectx，只需按照GitHub頁面上的說明進行操做便可：

https://github.com/ahmetb/kub...

kubectx和kubens都經過補全腳本提供命令補全功能。這使你能夠自動完成上下文名稱和命名空間的輸入。你也能夠在GitHub頁面上找到設置完成的說明：

https://github.com/ahmetb/kub...

kubectx的另外一個十分有用的功能是交互模式。這與fzf工具（它必須單獨安裝）一塊兒工做（實際上，安裝fzf會自動啓用kubectx交互模式）。交互式模式容許你經過交互式模糊搜索界面（由fzf提供）選擇目標上下文或命名空間。

fzf Github主頁：https://github.com/junegunn/fzf

使用shell別名

實際上，你並不須要單獨的工具來更改當前上下文和命名空間，由於kubectl也提供了執行此操做的命令。特別是，kubectl config命令提供了用於編輯kubeconfig文件的子命令。這裏是其中的一些：

• kubectl config get-contexts：列出全部上下文
• kubectl config current-context：獲取當前上下文
• kubectl config use-context：更改當前上下文
• kubectl config set-context：更改上下文的元素

可是，直接使用這些命令不是很方便，由於它們的鍵入時間很長。可是你能夠作的是將它們包裝到能夠更容易執行的shell別名中。

我根據這些命令建立了一組別名，這些別名提供了與kubectx相似的功能。在這裏，你能夠看到它們的做用：

請注意，別名使用fzf提供的交互式模糊搜索界面（例如kubectx的交互式模式）。這意味着，你須要安裝fzf才能使用這些別名。

如下是別名的定義：

# Get current context  
alias krc='kubectl config current-context'  
# List all contexts  
alias klc='kubectl config get-contexts -o name | sed "s/^/ /;\\|^ $(krc)$|s/ /*/"'  
# Change current context  
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'  
# Get current namespace  
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print \$5}" | sed "s/^$/default/"'  
# List all namespaces  
alias kln='kubectl get -o name ns | sed "s|^.*/| |;\\|^ $(krn)$|s/ /*/"'  
# Change current namespace  
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

要安裝這些別名，只需將以上定義添加到〜/ .bashrc或〜/ .zshrc文件中，而後從新加載你的shell。

使用插件

Kubectl容許安裝能夠像原生命令同樣調用的插件。例如，你能夠安裝名爲kubectl-foo的插件，而後將其做爲kubectl foo調用。kubectl插件將在本文後面的部分中詳細介紹。

可以像這樣更改當前上下文和命名空間不是很好嗎？例如，運行kubectl ctx更改上下文，運行kubectl ns更改命名空間？

我建立了兩個能夠實現這一功能的插件：

• kubectl-ctx：

  https://github.com/weibeld/ku...

• kubectl-ns：

  https://github.com/weibeld/ku...

在內部，插件創建在上一部分的別名基礎上。

在這裏，你能夠看到正在使用的插件：

請注意，插件使用fzf提供的交互式模糊搜索界面。這意味着，您須要安裝fzf才能使用這些插件。

要安裝插件，只需將名爲kubectl-ctx和kubectl-ns的shell腳本下載到PATH中的任何目錄，並使它們可執行（例如，使用chmod + x）。以後，你應該當即可使用kubectl ctx和kubectl ns。

五、 使用自動生成的別名保存輸入

Shell別名一般是保存輸入內容的好方法。kubectl-aliases項目則是這一想法的具體體現，併爲常見的kubectl命令提供了約800個別名：

https://github.com/ahmetb/kub...

你可能想知道如何記住800個別名？實際上，你不須要記住它們，由於它們都是根據簡單的方案生成的，以下所示：

如你所見，別名由組件組成，每一個組件表明kubectl命令的特定元素。每一個別名能夠具備一個用於基本命令、操做和資源的組件，以及一個用於選項的多個組件，你只需按照上述方案從左到右「填充」這些組件便可。

請注意，當前詳細的方案位於GitHub頁面上：

https://github.com/ahmetb/kub...

在這裏您還能夠找到別名的完整列表：

https://github.com/ahmetb/kub...

例如，別名kgpooyamlall表明命令kubectl get pods -o yaml --all-namespaces：

• k→ kubectl
• g→ get
• po→ pods
• oyaml→ -o yaml
• all→ --all-namespaces

請注意，大多數選項組件的相對順序可有可無。所以，kgpooyamlall等同於kgpoalloyaml。

你不須要使用全部組件做爲別名。例如，k、kg、klo、ksys或kgpo也是有效的別名。此外，你能夠在命令行上將別名與其餘單詞組合在一塊兒。

例如，你可使用k proxy來運行kubectl proxy。或使用kg roles來運行kubectl get roles（當前不存在Roles資源的別名組件）。要得到特定的Pod，你可使用kgpo my-pod來運行kubectl get pod my-pod。

請注意，某些別名甚至須要在命令行上進一步輸入參數。例如，kgpol別名表明kubectl get pods -l。-l選項須要一個參數（標籤規範）。所以，你必須使用此別名，例如：

所以，你只能在別名末尾使用a，f和l組件。

總而言之，一旦掌握了該方案，就能夠從要執行的命令中直觀地推斷出別名，並節省大量輸入！

安裝

要安裝kubectl-aliases，只需從GitHub下載.kubectl-aliases文件，而後將其從〜/ .bashrc或〜/ .zshrc文件中獲取便可：

source ~/.kubectl_aliases

從新加載shell後，你應該可使用全部800個kubectl別名！

補全功能

如你所見，你常常在命令行上將其餘單詞附加到別名上。例如：

kgpooyaml test-pod-d4b77b989

若是使用kubectl命令補全功能，則可能習慣於自動完成資源名稱之類的事情。可是當你使用別名時仍然能夠這樣作嗎？

這是一個重要的問題，由於若是補全功能沒法正常工做，這些別名的某些好處將會被削弱。

那麼，這一問題的答案取決於你所使用的shell。

對於Zsh，補全能夠當即和別名一塊兒使用。

對於Bash，默認狀況下補全功能將不會正常工做。可是它能夠經過一些額外的步驟來使其正常運行。

在Bash中同時啓用別名和補全功能

Bash的問題在於，它會在別名名稱上（而不是在別名命令上）嘗試補全（不管什麼時候按Tab鍵）。因爲你沒有全部800個別名的補全腳本，所以沒法使用。

complete-alias項目提供瞭解決此問題的通用方法（https://github.com/cykerway/c... ）。它利用別名的補全機制，在內部將別名擴展爲別名命令，並返回擴展命令的補全建議。這意味着，別名的補全行爲與別名命令的行爲徹底相同。

在下面的內容中，我將首先說明如何安裝complete-alias，而後如何配置它以啓用全部kubectl別名的補全。

安裝complete-alias

首先，complete-alias依賴於bash-completion。所以，在安裝complete-alias以前，你須要確保已安裝bash-completion。前面已經針對Linux和macOS給出了相關說明。

對於macOS用戶的重要說明：與kubectl補全腳本同樣，complete-alias不適用於Bash 3.2，後者是macOS上Bash的默認版本。特別是，complete-alias依賴於bash-completion v2（brew install bash-completion@2），至少須要Bash 4.1。這意味着，要在macOS上使用complete-alias，您須要安裝較新版本的Bash。

要安裝complete-alias，你只須要從GitHub存儲庫（https://github.com/cykerway/c... ）下載bash_completion.sh腳本，並將其source到你的〜/ .bashrc文件中：

source ~/bash_completion.sh

從新加載你的shell以後，complete-alias將完成安裝。

爲kubectl別名啓用補全功能

從技術上講，complete-alias提供了_complete_alias shell函數。此函數檢查別名，並返回別名命令的補全建議。

要將其與特定別名聯繫起來，你必須使用完整的Bash內置函數將_complete_alias設置爲別名的補全功能。

例如，讓咱們使用k別名表明kubectl命令。要將_complete_alias設置爲該別名的補全功能，你必須執行如下命令：

complete -F _complete_alias k

這樣的效果是，每當你對k別名自動補全時，就會調用_complete_alias函數，該函數將檢查別名並返回kubectl命令的補全建議。

再舉一個例子，讓咱們使用表明kubectl get的kg別名：

complete -F _complete_alias kg

一樣，這樣作的效果是，當你對kg自動補全時，你將得到與kubectl get相同的補全建議。

請注意，能夠經過這種方式對系統上的任何別名使用complete-alias。

所以，要爲全部kubectl別名啓用補全功能，只需爲每一個別名運行以上命令。以下所示（假設你將kubectl-aliases安裝到〜/ .kubectl-aliases）：

for _a in  $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases);  do complete -F _complete_alias "$_a"  
done

只需將此片斷添加到你的〜/ .bashrc文件中，從新加載你的shell，如今你就能夠對800個kubectl別名使用補全功能了！

六、使用插件擴展kubectl

從1.12版開始，kubectl包含插件機制，可以讓你使用自定義命令擴展kubectl。

這是一個能夠做爲kubectl hello調用的kubectl插件的示例：

若是你對此十分熟悉，其實kubectl插件機制與Git插件機制的設計十分相近。

本節將向您展現如何安裝插件，你能夠在其中找到現有插件以及如何建立本身的插件。

安裝插件

Kubectl插件做爲簡單的可執行文件分發，名稱形式爲kubectl-x。前綴kubectl-是必填項，其後是容許調用插件的新的kubectl子命令。

例如，上面顯示的hello插件將做爲名爲kubectl-hello的文件分發。

要安裝插件，你只須要將kubectl-x文件複製到PATH中的任何目錄並使其可執行（例如，使用chmod + x）。以後，你能夠當即使用kubectl x調用插件。

你可使用如下命令列出系統上當前安裝的全部插件：

kubectl plugin list

若是你有多個具備相同名稱的插件，或者存在沒法執行的插件文件，此命令還會顯示警告。

使用krew查找和安裝插件

Kubectl插件使本身像軟件包同樣能夠共享和重用。可是在哪裏能夠找到其餘人共享的插件？

krew項目旨在爲共享、查找、安裝和管理kubectl插件提供統一的解決方案（https://github.com/GoogleCont... ）。該項目將本身稱爲「 kubectl插件的軟件包管理器」（krew與brew十分類似）。

Krew根據kubectl插件進行索引，你能夠從中選擇和安裝。在這裏，你能夠看到實際操做：

如你所見，krew自己就是一個kubectl插件。這意味着，安裝krew本質上就像安裝其餘任何kubectl插件同樣。你能夠在GitHub頁面上找到krew的詳細安裝說明：

https://github.com/GoogleCont...

最重要的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>

請注意，使用krew安裝插件不會阻止你繼續使用傳統方式安裝插件。即便你使用krew，你仍然能夠經過其餘方式安裝在其餘地方找到的插件（或建立本身的插件）。

此外，kubectl krew list命令僅列出已與krew一塊兒安裝的插件，而kubectl plugin list命令列出了全部插件，即，與krew一塊兒安裝的插件和以其餘方式安裝的插件。

在其餘地方尋找插件

Krew仍然是一個年輕的項目，目前krew索引中只有大約30個插件。若是找不到所需的內容，則能夠在其餘地方（例如，在GitHub上）查找插件。

我建議你查看kubectl-plugins GitHub主題。你會在這裏找到幾十個可用的插件：

https://github.com/topics/kub...

建立本身的插件

固然，你也能夠建立本身的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插件能夠用任何編程或腳本語言編寫。若是使用Shell腳本，則具備能夠輕鬆從插件調用kubectl的優點。可是，你可使用真實的編程語言編寫更復雜的插件，例如，使用Kubernetes客戶端庫。若是使用Go，還可使用cli-runtime庫，該庫專門用於編寫kubectl插件。

共享你的插件

若是你認爲其中一個插件可能對其餘人有用，歡迎在GitHub上共享。只需將其添加到kubectl-plugins主題，其餘人就能夠方便地找到它。

你還能夠將插件添加到krew索引。你能夠在krew GitHub存儲庫中找到有關如何執行此操做的說明。

命令補全功能

遺憾的是，目前插件機制尚不支持命令補全。這意味着你須要完整鍵入插件名稱以及插件的全部參數。可是，kubectl GitHub存儲庫中對此有一個開放功能請求。所以，未來有可能實現此功能。

做者丨Daniel Weibel

原文連接：
https://learnk8s.io/blog/kube...