溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
如果你正在使用Kubernetes，那么kubectl一定是你最常使用的工具。無論你需要學習任何工具，都應該先提前了解kubectl并有效地使用它。本文包含了一系列技巧，可以讓你更高效而且有效地使用kubectl。同時，可以加深你對Kubernetes各個方面工作方式的理解。
本文的目標不僅是使你使用Kubernetes的日常工作更高效，而且更愉快！
在學習如何更高效地使用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/reference/generated/kubernetes-api/v1.13 ）。要向端點發出實際請求，你需要一開始就在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由一系列獨立組件構成，這些組件會在集群的節點上作為單獨的進程運行。一些組件運行在master節點，一些組件運行在worker節點，每個組件都有其特定功能。
在master節點上，有以下重要組件：
存儲后端：存儲資源定義（通常使用etcd）
API Server：提供Kubernetes API并管理存儲后端
Controller manager：確保資源狀態與規范相匹配
Scheduler：將Pod調度到worker節點
在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 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如何工作的：
存儲后端存儲（如，資源）Kubernetes的狀態
API server以Kubernetes API的形式提供到存儲后端的接口
熟悉這些概念將在很大程度上幫助你更好地理解kubectl并利用它。
接下來，我們來看一下具體的技巧，來幫助你提升kubectl的生產力。
命令補全是提高kubectl生產率的最有用但經常被忽略的技巧之一。
命令補全功能使你可以使用Tab鍵自動完成kubectl命令的各個部分。這適用于子命令、選項和參數，包括諸如資源名稱之類難以鍵入的內容。
在這里，你可以看到kubectl命令的完成情況：
命令補全可用于Bash和Zsh Shell。
官方文檔中包含有關設置命令完成的詳細說明（https://kubernetes.io/docs/tasks/tools/install-kubectl/#enabling-shell-autocompletion），但是以下部分會簡要向您介紹如何設置。
總體而言，命令補全是通過補全腳本而起作用的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-completion ），所以你需要先安裝它。
你可以使用不同的軟件包管理器安裝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-bash-on-macos-7138bd1066ba
在繼續剩下的步驟之前，確保你現在已經在使用Bash 4.1或更高的版本（使用bash --version查看版本）。
同上一部分一樣，Bash的補全腳本主要依賴bash-completion項目（https://github.com/scop/bash-completion ），所以你需要先安裝它。
你可以使用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/reference/generated/kubernetes-api/v1.13/
然而，每次你需要查找某些內容時都要切換到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：
https://goessner.net/articles/JsonPath/index.html
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/concepts/configuration/organize-cluster-access-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和kubens命令，使你可以分別更改當前上下文和命名空間。
如前所述，如果每個集群只有一個上下文，則更改當前上下文意味著更改集群。
在這里，你可以看到這兩個命令的作用：
如上一節所述，這些命令僅需在后臺編輯kubeconfig文件即可。
要安裝kubectx，只需按照GitHub頁面上的說明進行操作即可：
https://github.com/ahmetb/kubectx/#installation
kubectx和kubens都通過補全腳本提供命令補全功能。這使你可以自動完成上下文名稱和命名空間的輸入。你也可以在GitHub頁面上找到設置完成的說明：
https://github.com/ahmetb/kubectx/#installation
kubectx的另一個十分有用的功能是交互模式。這與fzf工具（它必須單獨安裝）一起工作（實際上，安裝fzf會自動啟用kubectx交互模式）。交互式模式允許你通過交互式模糊搜索界面（由fzf提供）選擇目標上下文或命名空間。
fzf Github主頁：https://github.com/junegunn/fzf
實際上，你并不需要單獨的工具來更改當前上下文和命名空間，因為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/kubectl-ctx
kubectl-ns：
https://github.com/weibeld/kubectl-ns
在內部，插件建立在上一部分的別名基礎上。
在這里，你可以看到正在使用的插件：
請注意，插件使用fzf提供的交互式模糊搜索界面。這意味著，您需要安裝fzf才能使用這些插件。
要安裝插件，只需將名為kubectl-ctx和kubectl-ns的shell腳本下載到PATH中的任何目錄，并使它們可執行（例如，使用chmod + x）。之后，你應該立即可以使用kubectl ctx和kubectl ns。
Shell別名通常是保存輸入內容的好方法。kubectl-aliases項目則是這一想法的具體體現，并為常見的kubectl命令提供了約800個別名：
https://github.com/ahmetb/kubectl-aliases
你可能想知道如何記住800個別名？實際上，你不需要記住它們，因為它們都是根據簡單的方案生成的，如下所示：
如你所見，別名由組件組成，每個組件代表kubectl命令的特定元素。每個別名可以具有一個用于基本命令、操作和資源的組件，以及一個用于選項的多個組件，你只需按照上述方案從左到右“填充”這些組件即可。
請注意，當前詳細的方案位于GitHub頁面上：
https://github.com/ahmetb/kubectl-aliases/blob/master/.kubectl_aliases
在這里您還可以找到別名的完整列表：
https://github.com/ahmetb/kubectl-aliases#syntax-explanation
例如，別名kgpooyamlall代表命令kubectl get pods -o yaml --all-namespaces：
k→ kubectl
g→ get
po→ pods
oyaml→ -o yaml
請注意，大多數選項組件的相對順序無關緊要。因此，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/complete-alias ）。它利用別名的補全機制，在內部將別名擴展為別名命令，并返回擴展命令的補全建議。這意味著，別名的補全行為與別名命令的行為完全相同。
在下面的內容中，我將首先說明如何安裝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/complete-alias ）下載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別名使用補全功能了！
從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
如果你有多個具有相同名稱的插件，或者存在無法執行的插件文件，此命令還會顯示警告。
Kubectl插件使自己像軟件包一樣可以共享和重用。但是在哪里可以找到其他人共享的插件？
krew項目旨在為共享、查找、安裝和管理kubectl插件提供統一的解決方案（https://github.com/GoogleContainerTools/krew ）。該項目將自己稱為“ kubectl插件的軟件包管理器”（krew與brew十分相似）。
Krew根據kubectl插件進行索引，你可以從中選擇和安裝。在這里，你可以看到實際操作：
如你所見，krew本身就是一個kubectl插件。這意味著，安裝krew本質上就像安裝其他任何kubectl插件一樣。你可以在GitHub頁面上找到krew的詳細安裝說明：
https://github.com/GoogleContainerTools/krew/#installation
最重要的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/kubectl-plugins
當然，你也可以創建自己的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存儲庫中對此有一個開放功能請求。因此，將來有可能實現此功能。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
