如果您使用 Kubernetes，那麼 kubectl 可能是您最常使用的實用程式之一。 每當您花費大量時間使用某個特定工具時，好好研究它並學習如何有效地使用它是值得的。
團隊 翻譯了 Daniel Weibel 撰寫的一篇文章，您將在其中找到有效使用 kubectl 的提示和技巧。 它還將幫助您更深入地了解 Kubernetes。
作者表示，本文的目標是讓您使用 Kubernetes 的日常工作不僅更有效率，更愉快！
簡介：什麼是 kubectl
在學習更有效地使用 kubectl 之前，您需要對它是什麼以及它如何運作有基本的了解。
從使用者的角度來看，kubectl 是一個控制面板，可讓您執行 Kubernetes 操作。
從技術上講，kubectl 是一個 Kubernetes API 客戶端。
Kubernetes API 是一個 HTTP REST API。 這個API是真正的Kubernetes使用者介面，透過它可以完全控制。 這意味著每個 Kubernetes 操作都以 API 端點公開，並且可以透過對該端點的 HTTP 請求來進行。
因此，kubectl的主要工作是向Kubernetes API發出HTTP請求：
Kubernetes 是一個完全以資源為導向的系統。 這意味著它維護資源的內部狀態，並且所有 Kubernetes 操作都是 CRUD 操作。
透過管理這些資源，您可以完全控制 Kubernetes，並且 Kubernetes 根據資源的當前狀態決定要做什麼。 因此，Kubernetes API 參考被組織為資源類型及其關聯操作的清單。
讓我們來看一個例子.
假設您要建立一個 ReplicaSet 資源。 為此，您可以按名稱在文件中描述 ReplicaSet replicaset.yaml，然後運行命令：
$ kubectl create -f replicaset.yaml這將會建立一個 ReplicaSet 資源。 但幕後發生了什麼事？
Kubernetes 有一個 ReplicaSet 建立操作。 與任何其他操作一樣，它會作為 API 端點公開。 此操作的具體 API 端點如下所示：
POST /apis/apps/v1/namespaces/{namespace}/replicasets所有 Kubernetes 操作的 API 端點可以在以下位置找到： （包括 ）。 若要向端點發出實際請求，您必須先將 API 伺服器 URL 新增至 API 參考中所列的端點路徑。
因此，當您執行上述命令時，kubectl 會向上述 API 端點傳送 HTTP POST 請求。 您在文件中提供的 ReplicaSet 定義 replicaset.yaml，在請求正文中發送。
這就是 kubectl 適用於與 Kubernetes 叢集互動的所有命令的方式。 在所有這些情況下，kubectl 只是向適當的 Kubernetes API 端點發出 HTTP 請求。
請注意，您可以使用實用程式來完全管理 Kubernetes，例如 curl透過手動向 Kubernetes API 發送 HTTP 請求。 Kubectl 只是讓 Kubernetes API 的使用變得更容易。
這是 kubectl 是什麼及其工作原理的基礎知識。 但每個 kubectl 使用者都應該了解有關 Kubernetes API 的其他內容。 讓我們快速了解 Kubernetes 的內在世界。
Kubernetes的內部世界
Kubernetes 由一組獨立的元件組成，這些元件作為單獨的進程在叢集節點上運行。 有些元件在主節點上運行，其他元件在工作節點上運行，每個元件執行自己的特定任務。
以下是主節點上最重要的元件：
- 金庫 - 儲存資源定義（).
- API伺服器 — 提供 API 並管理儲存。
- 控制器經理 — 確保資源狀態符合規範。
- 調度器 — 在工作節點上調度 pod。
這是工作節點上最重要的元件之一：
- 庫貝萊特 — 管理工作節點上容器的啟動。
要了解這些元件如何協同工作，讓我們來看一個範例。
假設您剛剛完成 kubectl create -f replicaset.yaml，之後 kubectl 向 （傳遞ReplicaSet資源定義）。
集群中發生了什麼事？
- 做完之後
kubectl create -f replicaset.yamlAPI 伺服器將您的 ReplicaSet 資源定義儲存在儲存中： - 接下來，在控制器管理員中啟動ReplicaSet控制器，該控制器處理ReplicaSet資源的建立、修改和刪除：
- ReplicaSet控制器為每個ReplicaSet副本建立一個Pod定義（根據ReplicaSet定義中的Pod模板）並將它們儲存在儲存中：
- 調度程序啟動，追蹤尚未分配給任何工作節點的 Pod：
- 調度程序為每個 pod 選擇適當的工作節點，並將此資訊新增至儲存中的 pod 定義：
- 在分配 pod 的工作節點上，啟動 Kubelet，它追蹤分配給該節點的 pod：
- Kubelet 從儲存中讀取 pod 定義，並指示容器執行時間（例如 Docker）在節點上啟動容器：
以下是此描述的文字版本。
對 ReplicaSet 建立端點的 API 請求由 API 伺服器處理。 API 伺服器對請求進行身份驗證並將 ReplicaSet 資源定義儲存在儲存中。
此事件啟動 ReplicaSet 控制器，它是控制器管理器的子程序。 ReplicaSet 控制器監控儲存中 ReplicaSet 資源的建立、更新和刪除，並在發生這種情況時接收事件通知。
ReplicaSet 控制器的工作是確保存在所需數量的 ReplicaSet pod。 在我們的範例中，尚不存在 pod，因此 ReplicaSet 控制器會建立這些 pod 定義（根據 ReplicaSet 定義中的 pod 範本）並將它們儲存在儲存中。
新 Pod 的創建由調度程序觸發，該調度程序追蹤尚未為工作節點調度的 Pod 定義。 調度程式為每個 Pod 選擇合適的工作節點並更新儲存庫中的 Pod 定義。
請注意，到目前為止，叢集中的任何位置都沒有運行工作負載程式碼。 到目前為止所做的一切 - 這是主節點上儲存庫中資源的建立和更新。
最後一個事件會觸發 Kubelet，它會監視為其工作節點調度的 Pod。 安裝 ReplicaSet Pod 的工作節點的 Kubelet 必須指示容器執行時間（例如 Docker）下載所需的容器映像並執行它們。
至此，您的 ReplicaSet 應用程式終於運作起來了！
Kubernetes API 的作用
如您在前面的範例中所看到的，Kubernetes 元件（API 伺服器和儲存除外）會監視儲存中資源的變更並變更有關儲存中資源的資訊。
當然，這些元件並非直接與儲存交互，而是僅透過 Kubernetes API 進行交互。
考慮以下範例:
- ReplicaSet控制器使用API端點 帶參數
watch監控ReplicaSet資源的變化。 - ReplicaSet控制器使用API端點 (create pod) 建立 pod。
- 調度程序使用API端點 （編輯 pod）以使用有關所選工作節點的資訊更新 pod。
如您所見，這與 kubectl 存取的 API 相同。 對內部元件和外部使用者使用相同的 API 是 Kubernetes 設計中的一個基本概念。
現在我們可以總結一下 Kubernetes 的工作原理：
- 儲存儲存狀態，即 Kubernetes 資源。
- API伺服器以Kubernetes API的形式提供儲存介面。
- 所有其他 Kubernetes 元件和使用者都透過 API 讀取、觀察和操作 Kubernetes 狀態（資源）。
了解這些概念將幫助您更好地理解 kubectl 並充分利用它。
現在讓我們來看看一些具體的提示和技巧，它們將有助於提高您使用 kubectl 的工作效率。
1.使用指令補全加速輸入
用於提高 kubectl 性能的最有用但經常被忽視的技術之一是命令完成。
指令補全可讓您使用 Tab 鍵自動補全 kubectl 指令的部分內容。 這適用於子命令、選項和參數，包括像資源名稱這樣複雜的東西。
查看 kubectl 指令補全的工作原理：
指令完成適用於 Bash 和 Zsh shell。
包含設定自動完成的詳細說明，但下面我們將提供簡短的摘錄。
命令完成的工作原理
命令完成是一項使用完成腳本工作的 shell 功能。 擴充腳本是一個 shell 腳本，它定義特定指令的擴充行為。
Kubectl 使用以下命令自動產生並輸出 Bash 和 Zsh 的擴充腳本：
$ kubectl completion bashИли：
$ kubectl completion zsh理論上，將這些命令的輸出連接到適當的命令 shell 就足夠了，以便 kubectl 可以補充這些命令。
實際上，Bash（包括Linux和MacOS之間的差異）和Zsh的連接方法是不同的。 下面我們將看看所有這些選項。
Linux 上的 Bash
Bash 補全腳本依賴 bash-completion 套件，因此需要先安裝它：
$ sudo apt-get install bash-completionИли：
$ yum install 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 指令完成將會運作。
MacOS 上的 Bash
在 MacOS 上，設定稍微複雜一些。 事實是，預設情況下，MacOS 使用 Bash 3.2 版本，而 kubectl 自動完成腳本需要至少 4.1 的 Bash 版本，並且在 Bash 3.2 中不起作用。
在 MacOS 上使用過時版本的 Bash 有相關的授權問題。 Bash 版本 4 根據 GPLv3 授權，Apple 不支援。
要在 MacOS 上設定 kubectl 自動完成功能，您需要安裝更新版本的 Bash。 您還可以將更新的 Bash 設定為您的預設 shell，這將為您在將來節省很多問題。 並不難，文章中有詳細介紹““。
在繼續之前，請確保您使用的是最新版本的 Bash（檢查輸出 bash --version).
Bash 完成腳本因專案而異 ，所以你需要先安裝它。
您可以使用安裝 bash-completion :
$ brew install bash-completion@2
這裡 @2 代表 bash-completion version 2.kubectl 自動完成需要 bash-completion v2，而 bash-completion v2 至少需要 Bash 版本 4.1。
命令輸出 brew-install 包含一個警告部分，它指定需要添加到文件中的內容 ~/.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_profile，並在 ~/.bashrc。 在這種情況下，自動完成功能不僅在主命令 shell 中可用，而且在子命令 shell 中也可用。
重新啟動命令 shell 後，您可以使用以下命令驗證安裝是否正確：
$ type _init_completion如果您在輸出中看到 shell 函數，則表示一切配置正確。
現在我們需要確保在所有會話中啟用 kubectl 自動完成功能。
一種方法是將以下行添加到您的 ~/.bashrc:
source <(kubectl completion bash)
第二種方法是將自動完成腳本新增到資料夾中 /usr/local/etc/bash_completion.d:
$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl只有當您使用 Homebrew 安裝了 bash-completion 時，此方法才有效。 在這種情況下，bash-completion 會載入此目錄中的所有腳本。
如果你安裝了 ，那麼就不需要執行上一步了，因為自動補全腳本會自動放到該資料夾中 /usr/local/etc/bash_completion.d 在安裝過程中。 在這種情況下，一旦您安裝了 bash-completion，kubectl 自動完成功能就會開始運作。
因此，所有這些選項都是等效的。
岩組
Zsh 的自動完成腳本不需要任何相依性。 您所需要做的就是在載入命令 shell 時啟用它們。
您可以透過在您的 ~/.zshrc 文件：
source <(kubectl completion zsh)
如果您收到錯誤 not found: compdef 重新啟動 shell 後，您需要啟用內建功能 compdef。 您可以透過將其新增至文件的開頭來啟用它 ~/.zshrc 以下內容：
autoload -Uz compinit
compinit2.快速查看資源規格
在建立 YAML 資源定義時，您需要了解這些資源的欄位及其意義。 可以在 API 參考中找到此信息，其中包含所有資源的完整規格。
然而，每次需要搜尋某些內容時都切換到網頁瀏覽器很不方便。 因此 kubectl 提供了指令 kubectl explain，它顯示終端中所有資源的規格。
命令格式如下：
$ kubectl explain resource[.field]...此命令將輸出所請求的資源或欄位的規格。 顯示的資訊與 API 手冊中包含的資訊相同。
默認情況下， kubectl explain 僅顯示欄位的第一層嵌套。
看看它是什麼樣子 .
如果新增選項，則可以顯示整個樹 --recursive:
$ kubectl explain deployment.spec --recursive如果您不確切知道需要哪些資源，可以使用以下命令顯示所有資源：
$ kubectl api-resources
此指令以複數形式顯示資源名稱，例如 deployments 而不是 deployment。 它還顯示短名稱，例如 deploy，對於那些擁有它的資源。 不用擔心這些差異。 所有這些命名選項對於 kubectl 都是等效的。 也就是說，您可以將它們中的任何一個用於 kubectl explain.
以下所有指令都是等效的：
$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или
$ kubectl explain deploy.spec3.使用自訂列輸出格式
預設命令輸出格式 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 名稱 metadata.name。 這是因為 pod 的名稱是在 child name 欄位中定義的 metadata 在 pod 的資源描述中。 更多詳細資訊可以參見 或輸入命令 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 被指派給一個節點時，它的名字被寫在欄位中 spec.nodeName Pod 資源規範。 更詳細的資訊可以在輸出中找到 kubectl explain pod.spec.nodeName.
請注意，Kubernetes 資源欄位區分大小寫。
您可以將任何資源欄位視為列。 只需查看資源規格並嘗試使用您喜歡的任何欄位即可。
但首先，讓我們仔細看看字段選擇表達式。
JSONPath 表達式
選擇資源欄位的表達式基於 .
JSONPath 是一種用於從 JSON 文件檢索資料的語言。 選擇單一欄位是 JSONPath 最簡單的用例。 他有很多 ，包括選擇器、過濾器等。
Kubectl解釋支援有限數量的JSONPath功能。 下面描述了它們的可能性和使用範例：
# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'[] 運算子尤其重要。 許多 Kubernetes 資源欄位都是列表，此運算子可讓您選擇這些列表的成員。 它通常與 [*] 等通配符一起使用來選擇清單中的所有元素。
應用實例
使用自訂列輸出格式的可能性是無限的，因為您可以在輸出中顯示任何欄位或資源欄位的組合。 以下是一些範例應用程序，但您可以隨意自行探索並找到適合您的應用程式。
- 顯示 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 可以包含多個容器，那麼鏡像名稱將顯示在一行上，並以逗號分隔。
- 顯示節點可用區：
$ 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 資源規範的一部分，因此您在以下位置找不到有關它們的信息 。 但是，如果您以 YAML 或 JSON 格式請求有關節點的信息，則可以看到它們（與任何其他標籤一樣）：
$ kubectl get nodes -o yaml # или $ kubectl get nodes -o json除了學習資源規範之外，這是了解更多資源的好方法。
4.在集群和命名空間之間輕鬆切換
當 kubectl 向 Kubernetes API 發出請求時，它會先讀取 kubeconfig 檔案以取得連線所需的所有參數。
預設情況下，kubeconfig 檔案是 ~/.kube/config。 通常，該文件是由特殊命令創建或更新的。
當您使用多個叢集時，您的 kubeconfig 檔案包含用於連接到所有這些叢集的設定。 您需要一種方法來告訴 kubectl 命令您正在使用哪個叢集。
在一個叢集中，您可以建立多個命名空間—實體叢集中的一種虛擬叢集。 Kubectl 也根據 kubeconfig 檔案決定要使用哪個命名空間。 這意味著您還需要一種方法來告訴 kubectl 命令要使用哪個命名空間。
在本章中，我們將解釋它是如何運作的以及如何使其有效地運作。
請注意，KUBECONFIG 環境變數中可能列出了多個 kubeconfig 檔案。 在這種情況下，所有這些檔案將在運行時組合成一個通用配置。 您也可以透過使用參數來執行 kubectl 來更改預設的 kubeconfig 文件 --kubeconfig。 看 .
kubeconfig 檔案
讓我們看看 kubeconfig 檔案到底包含什麼：
如您所見，kubeconfig 檔案包含一組上下文。 上下文由三個元素組成：
- 叢集 — 叢集伺服器的 API URL。
- 使用者 - 叢集中的使用者身份驗證憑證。
- 命名空間 - 加入叢集時使用的命名空間。
在實踐中，他們經常在 kubeconfig 中為每個集群使用一個上下文。 但是，每個群集可以有多個上下文，按使用者或命名空間進行區分。 然而，這種多上下文配置並不常見，因此集群和上下文之間通常存在一對一的映射。
在任何給定時間，其中一個上下文都是當前的：
當 kubectl 讀取設定檔時，它總是從當前上下文中獲取資訊。 在上面的範例中，kubectl 將連接到 Hare 叢集。
因此，要切換到另一個集群，您需要更改 kubeconfig 檔案中的當前上下文：
現在 kubectl 將連接到 Fox 叢集。
要切換到同一叢集中的不同命名空間，您需要變更目前上下文的命名空間元素的值：
在上面的範例中，kubectl 將使用 Fox 叢集的 Prod 命名空間（先前設定了 Test 命名空間）。
請注意，kubectl 還提供了選項 --cluster, --user, --namespace и --context，它允許您覆寫單一元素和當前上下文本身，無論在 kubeconfig 中設定了什麼。 看 kubectl options.
理論上，您可以手動更改 kubeconfig 中的設定。 但很不方便。 為了簡化這些操作，有多種實用程式可讓您自動變更參數。
使用kubectx
一個非常流行的實用程序，用於在叢集和命名空間之間切換。
該實用程式提供命令 kubectx и kubens 分別更改目前上下文和命名空間。
如前所述，如果每個集群只有一個上下文，則更改當前上下文意味著更改集群。
以下是執行這些命令的範例：
本質上，這些命令只是如上所述編輯 kubeconfig 檔案。
安裝 kubectx，請按照說明進行操作
這兩個命令都支援上下文和命名空間名稱的自動完成，這樣就無需完整鍵入它們。 設定自動完成的說明 .
另一個有用的功能 kubectx 是 。 它與實用程式結合使用 ，必須單獨安裝。 自動安裝 fzf 使互動模式可用 kubectx。 互動式地，您可以透過 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 的互動模式）。 這意味著你需要 使用這些別名。
以下是別名本身的定義：
# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/ /;|^ $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'
# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/| |;|^ $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'
要設定這些別名，您需要將上述定義新增到您的檔案中 ~/.bashrc 或 ~/.zshrc 並重新啟動你的外殼。
使用插件
Kubectl 允許您載入以與基本命令相同的方式執行的插件。 例如，您可以安裝 kubectl-foo 插件並透過執行命令來運行它 kubectl foo.
以這種方式更改上下文和命名空間會很方便，例如透過運行 kubectl ctx 改變上下文和 kubectl ns 更改命名空間。
我寫了兩個插件來做到這一點：
插件的工作是基於上一節中的別名。
它們的工作原理如下：
請注意，插件使用 fzf 提供互動式免費搜尋介面（如 kubectx 的互動模式）。 這意味著你需要使用這些別名。
要安裝插件，您需要下載名為 и 到 PATH 變數中的任何目錄並使它們可執行，例如 chmod +x。 在此之後您將能夠立即使用 kubectl ctx и kubectl ns.
5. 使用自動別名減少輸入
Shell 別名是加快輸入速度的好方法。 專案 包含大約 800 個基本 kubectl 指令的捷徑。
您可能想知道 - 如何記住 800 個別名？ 但您不需要全部記住它們，因為它們是根據一個簡單的方案構建的，如下所示：
例如：
- kgpooyaml - kubectl 取得 pods oyaml
- ksysgsvcw — kubectl -n kube-system 取得 svc w
- ksysrmcm -kubectl -n kube-system rm cm
- kgdepallsl - kubectl 取得部署所有 sl
如您所見，別名由元件組成，每個元件代表 kubectl 指令的特定元素。 每個別名可以有一個用於基本命令、操作和資源的元件，以及多個用於參數的元件。 您只需根據上圖從左到右「填充」這些組件即可。
目前的詳細圖位於 。 在那裡你還可以找到.
例如，別名 kgpooyamlall 相當於指令 kubectl get pods -o yaml --all-namespaces.
選項的相對順序並不重要：命令 kgpooyamlall 相當於命令 kgpoalloyaml.
您不必使用所有元件作為別名。 例如 k, kg, klo, ksys, kgpo 也可以使用。 此外，您可以在命令列上組合別名和常規命令或選項：
例如：
- 而不是
kubectl proxy你可以寫k proxy. - 而不是
kubectl get roles你可以寫kg roles（角色資源目前沒有別名）。 - 要取得特定 pod 的數據，可以使用以下命令
kgpo my-pod — kubectl get pod my-pod.
請注意，某些別名需要命令列參數。 例如，別名 kgpol 手段 kubectl get pods -l。 選項 -l 需要一個參數 - 標籤規格。 如果您使用別名，它將看起來像 kgpol app=ui.
由於某些別名需要參數，因此必須最後使用別名 a、f 和 l。
一般來說，一旦掌握了這個方案，您就可以直觀地從要執行的命令中派生別名，並節省大量的打字時間。
安裝
要安裝kubectl-aliases，需要下載文件 來自 GitHub 並將其包含在文件中 ~/.bashrc 或 ~/.zshrc:
source ~/.kubectl_aliases自動完成
正如我們之前所說，您經常在命令列上向別名添加其他單字。 例如：
$ kgpooyaml test-pod-d4b77b989如果您使用 kubectl 命令完成，您可能已經對資源名稱等內容使用了自動完成功能。 但是使用別名時可以做到這一點嗎？
這是一個非常重要的問題，因為如果自動完成不起作用，您將失去別名的一些好處。
答案取決於您使用的 shell：
- 對於 Zsh，別名補全是開箱即用的。
- 不幸的是，對於 Bash 來說，需要做一些工作才能讓自動完成功能發揮作用。
在 Bash 中啟用別名自動補全
Bash 的問題在於它嘗試完成（每次按 Tab 時）別名，而不是別名引用的命令（例如 Zsh 所做的）。 由於您沒有所有 800 個別名的完成腳本，因此自動完成功能不起作用。
項目 為這個問題提供了一個通用的解決方案。 它連接到別名的完成機制，在內部將別名擴展為命令，並傳回已完成命令的完成選項。 這意味著別名的填充行為與完整命令的填充行為完全相同。
下面，我將首先解釋如何安裝complete-alias，然後如何設定它以啟用所有 kubectl 別名的補全。
安裝完整別名
首先，完整別名取決於 。 因此，在安裝complete-alias之前，需要確保已安裝bash-completion。 之前已提供 Linux 和 MacOS 的安裝說明。
MacOS 用戶的重要注意事項：與 kubectl 自動完成腳本一樣，complete-alias 不適用於 Bash 3.2，這是 MacOS 上的預設設定。 特別是，complete-alias 依賴 bash-completion v2 (brew install bash-completion@2），至少需要 Bash 4.1。 這意味著要在 MacOS 上使用完整別名，您需要安裝較新版本的 Bash。
您需要下載腳本 的 並將其包含在您的文件中 ~/.bashrc:
source ~/bash_completion.sh重新啟動 shell 後，complete-alias 將會完全安裝。
為 kubectl 別名啟用自動補全
從技術上來說，complete-alias 提供了一個包裝函數 _complete_alias。 此函數檢查別名並傳回別名命令的完成提示。
要將函數與特定別名關聯起來，需要使用內建的 Bash 機制 ， 安裝 _complete_alias 作為別名完成函數。
作為範例，我們以別名 k 為例，它代表 kubectl 指令。 安裝 _complete_alias 作為此別名的補充函數，您應該執行以下命令：
$ complete -F _complete_alias k
這樣做的結果是，每當您自動完成別名 k 時，都會呼叫該函數 _complete_alias，它檢查別名並返回命令的完成提示 kubectl.
作為第二個例子，我們使用別名 kg，這表示 kubectl get:
$ 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 別名。
6. 使用外掛擴充 kubectl
從。開始 , kubectl 支持 ，它允許您使用附加命令擴展其功能。
如果你熟悉 ，那麼 kubectl 外掛也是基於相同的原理建構的。
在本章中，我們將介紹如何安裝插件、在哪裡找到它們以及如何建立自己的插件。
安裝插件
Kubectl 外掛程式以簡單的可執行檔分發，其名稱如下 kubectl-x。 字首 kubectl- 是必需的，後面跟著一個新的 kubectl 子命令，允許您呼叫該插件。
例如，hello 外掛程式將作為一個名為的檔案分發 kubectl-hello.
要安裝插件，需要複製文件 kubectl-x 到 PATH 中的任何目錄並使其可執行，例如 chmod +x。 在此之後您可以立即調用該插件 kubectl x.
您可以使用以下命令列出系統上目前安裝的所有插件：
$ kubectl plugin list如果您有多個同名插件，或者存在不可執行的插件文件，此命令也會顯示警告。
使用 Krew 尋找並安裝插件
Kubectl 外掛程式可以像軟體包一樣共享或重複使用。 但是在哪裡可以找到其他人共享的插件呢？
旨在為共享、搜尋、安裝和管理 kubectl 插件提供統一的解決方案。 該專案稱自己為「kubectl 插件的套件管理器」（Krew 類似於 ).
Krew 是您可以選擇並安裝的 kubectl 外掛程式清單。 同時Krew也是kubectl的插件。
這意味著安裝 Krew 的工作原理本質上就像安裝任何其他 kubectl 插件一樣。 您可以在以下位置找到詳細說明： .
最重要的克魯命令是：
# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>請注意，使用 Krew 安裝插件不會幹擾使用上述標準方法安裝插件。
請注意該命令 kubectl krew list 僅顯示使用 Krew 安裝的插件，而指令 kubectl plugin list 列出所有插件，即使用 Krew 安裝的插件和透過其他方法安裝的插件。
在其他地方尋找插件
Krew 是一個年輕的項目，目前正處於 只有大約 30 個插件。 如果找不到所需的插件，可以在其他地方找到插件，例如 GitHub。
我建議查看 GitHub 部分 。 在那裡你會發現數十個值得一試的可用插件。
編寫自己的插件
你可以自己 - 這並不難。 您需要建立一個執行您需要的可執行文件，將其命名為 kubectl-x 並依照上述方法安裝。
該檔案可以是 bash 腳本、Python 腳本或已編譯的 GO 應用程式 - 這並不重要。 唯一的條件是可以在作業系統中直接執行。
現在讓我們建立一個範例插件。 在上一節中，您使用 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 的優點。 但是，您可以使用真實的程式語言編寫更複雜的插件 。 如果您使用 Go，您也可以使用 ，它專門用於編寫 kubectl 插件。
如何分享您的插件
如果您認為您的外掛程式對其他人有用，請隨時在 GitHub 上分享。 請務必將它們添加到主題中 .
您也可以請求將您的插件新增到 。 有關如何執行此操作的說明位於 .
命令完成
插件目前不支援自動完成。 也就是說，您必須輸入插件的全名和參數的全名。
該函數的 GitHub kubectl 儲存庫有 。 所以這個功能有可能在未來的某個時候實現。
祝你好運！！！
關於該主題還可以閱讀什麼:
- .
- .
- .
來源： www.habr.com