建站
咨詢
售后
建站咨詢
新聞中心
用插件擴(kuò)展 kubectl
本指南演示了如何為 ?kubectl ?安裝和編寫擴(kuò)展。 通過(guò)將核心 ?kubectl ?命令看作與 Kubernetes 集群交互的基本構(gòu)建塊， 集群管理員可以將插件視為一種利用這些構(gòu)建塊創(chuàng)建更復(fù)雜行為的方法。 插件用新的子命令擴(kuò)展了 ?kubectl?，允許新的和自定義的特性不包括在 ?kubectl ?的主要發(fā)行版中。
在開(kāi)始之前
你需要安裝一個(gè)可用的 ?kubectl ?可執(zhí)行文件。
安裝 kubectl 插件
插件是一個(gè)獨(dú)立的可執(zhí)行文件，名稱以 ?kubectl-? 開(kāi)頭。 要安裝插件，將其可執(zhí)行文件移動(dòng)到 ?PATH ?中的任何位置。
你也可以使用 Krew 來(lái)發(fā)現(xiàn)和安裝開(kāi)源的 kubectl 插件。 Krew 是一個(gè)由 Kubernetes SIG CLI 社區(qū)維護(hù)的插件管理器。
注意： Krew 插件索引 所維護(hù)的 kubectl 插件并未經(jīng)過(guò)安全性審查。 你要了解安裝和運(yùn)行第三方插件的安全風(fēng)險(xiǎn)，因?yàn)樗鼈儽举|(zhì)上時(shí)是一些在你的機(jī)器上 運(yùn)行的程序。
發(fā)現(xiàn)插件
?kubectl ?提供一個(gè)命令 ?kubectl plugin list?，用于搜索路徑查找有效的插件可執(zhí)行文件。 執(zhí)行此命令將遍歷路徑中的所有文件。任何以 ?kubectl-? 開(kāi)頭的可執(zhí)行文件都將在這個(gè)命令的輸出中以它們?cè)诼窂街谐霈F(xiàn)的順序顯示。 任何以 ?kubectl-? 開(kāi)頭的文件如果不可執(zhí)行，都將包含一個(gè)警告。 對(duì)于任何相同的有效插件文件，都將包含一個(gè)警告。
你可以使用 Krew 從社區(qū)策劃的插件索引 中發(fā)現(xiàn)和安裝 ?kubectl ?插件。
限制
目前無(wú)法創(chuàng)建覆蓋現(xiàn)有 ?kubectl ?命令的插件。 例如，創(chuàng)建一個(gè)插件 ?kubectl-version? 將導(dǎo)致該插件永遠(yuǎn)不會(huì)被執(zhí)行， 因?yàn)楝F(xiàn)有的 ?kubectl version? 命令總是優(yōu)先于它執(zhí)行。 由于這個(gè)限制，也不可能使用插件將新的子命令添加到現(xiàn)有的 ?kubectl ?命令中。 例如，通過(guò)將插件命名為 ?kubectl-create-foo? 來(lái)添加子命令 ?kubectl create foo? 將導(dǎo)致該插件被忽略。
對(duì)于任何試圖這樣做的有效插件 ?kubectl plugin list? 的輸出中將顯示警告。
編寫 kubectl 插件
你可以用任何編程語(yǔ)言或腳本編寫插件，允許你編寫命令行命令。
不需要安裝插件或預(yù)加載，插件可執(zhí)行程序從 ?kubectl ?二進(jìn)制文件接收繼承的環(huán)境， 插件根據(jù)其名稱確定它希望實(shí)現(xiàn)的命令路徑。 例如，名為 ?kubectl-foo? 的插件提供了命令 ?kubectl foo?。 必須將插件的可執(zhí)行文件安裝在 ?PATH ?中的某個(gè)位置。
示例插件
#!/bin/bash
# 可選的參數(shù)處理
if [[ "$1" == "version" ]]
then
echo "1.0.0"
exit 0
fi
# 可選的參數(shù)處理
if [[ "$1" == "config" ]]
then
echo $KUBECONFIG
exit 0
fi
echo "I am a plugin named kubectl-foo"使用插件
要使用某插件，先要使其可執(zhí)行：
sudo chmod +x ./kubectl-foo
并將它放在你的 PATH 中的任何地方：
sudo mv ./kubectl-foo /usr/local/bin
你現(xiàn)在可以調(diào)用你的插件作為 ?kubectl ?命令：
kubectl foo
I am a plugin named kubectl-foo
所有參數(shù)和標(biāo)記按原樣傳遞給可執(zhí)行文件：
kubectl foo version
1.0.0
所有環(huán)境變量也按原樣傳遞給可執(zhí)行文件：
export KUBECONFIG=~/.kube/config
kubectl foo config/home//.kube/config
KUBECONFIG=/etc/kube/config kubectl foo config
/etc/kube/config
此外，傳遞給插件的第一個(gè)參數(shù)總是調(diào)用它的位置的絕對(duì)路徑（在上面的例子中，?$0? 將等于 ?/usr/local/bin/kubectl-foo?）。
命名插件
如上面的例子所示，插件根據(jù)文件名確定要實(shí)現(xiàn)的命令路徑，插件所針對(duì)的命令路徑中的每個(gè)子命令都由破折號(hào)（?-?）分隔。 例如，當(dāng)用戶調(diào)用命令 ?kubectl foo bar baz? 時(shí)，希望調(diào)用該命令的插件的文件名為 ?kubectl-foo-bar-baz?。
參數(shù)和標(biāo)記處理
說(shuō)明：
插件機(jī)制不會(huì)為插件進(jìn)程創(chuàng)建任何定制的、特定于插件的值或環(huán)境變量。
較老的插件機(jī)制會(huì)提供環(huán)境變量（例如 ?
KUBECTL_PLUGINS_CURRENT_NAMESPACE?）；這種機(jī)制已被廢棄。
kubectl 插件必須解析并檢查傳遞給它們的所有參數(shù)。
這里是一些用戶調(diào)用你的插件的時(shí)候提供額外標(biāo)志和參數(shù)的場(chǎng)景。 這些場(chǎng)景時(shí)基于上述案例中的 ?kubectl-foo-bar-baz? 插件的。
如果你運(yùn)行 ?kubectl foo bar baz arg1 --flag=value arg2?，kubectl 的插件機(jī)制將首先嘗試找到 最長(zhǎng)可能名稱的插件，在本例中是 ?kubectl-foo-bar-baz-arg1?。 當(dāng)沒(méi)有找到這個(gè)插件時(shí)，kubectl 就會(huì)將最后一個(gè)以破折號(hào)分隔的值視為參數(shù)（在本例中為 ?arg1?）， 并嘗試找到下一個(gè)最長(zhǎng)的名稱 ?kubectl-foo-bar-baz?。 在找到具有此名稱的插件后，它將調(diào)用該插件，并在其名稱之后將所有參數(shù)和標(biāo)志傳遞給插件進(jìn)程。
示例：
# 創(chuàng)建一個(gè)插件
echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
sudo chmod +x ./kubectl-foo-bar-baz
# 將插件放到 PATH 下完成"安裝"
sudo mv ./kubectl-foo-bar-baz /usr/local/bin
# 確保 kubectl 能夠識(shí)別我們的插件
kubectl plugin listThe following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-foo-bar-baz# 測(cè)試通過(guò) "kubectl" 命令來(lái)調(diào)用我們的插件時(shí)可行的
# 即使我們給插件傳遞一些額外的參數(shù)或標(biāo)志
kubectl foo bar baz arg1 --meaningless-flag=trueMy first command-line argument was arg1
正如你所看到的，我們的插件是基于用戶指定的 ?kubectl ?命令找到的， 所有額外的參數(shù)和標(biāo)記都是按原樣傳遞給插件可執(zhí)行文件的。
帶有破折號(hào)和下劃線的名稱
雖然 ?kubectl ?插件機(jī)制在插件文件名中使用破折號(hào)（?-?）分隔插件處理的子命令序列， 但是仍然可以通過(guò)在文件名中使用下劃線（?_?）來(lái)創(chuàng)建命令行中包含破折號(hào)的插件命令。
例子：
# 創(chuàng)建文件名中包含下劃線的插件
echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
sudo chmod +x ./kubectl-foo_bar
# 將插件放到 PATH 下
sudo mv ./kubectl-foo_bar /usr/local/bin
# 現(xiàn)在可以通過(guò) kubectl 來(lái)調(diào)用插件
kubectl foo-barI am a plugin with a dash in my name
請(qǐng)注意，在插件文件名中引入下劃線并不會(huì)阻止我們使用 ?kubectl foo_bar? 之類的命令。 可以使用破折號(hào)（?-?）或下劃線（?_?）調(diào)用上面示例中的命令:
# 我們的插件也可以用破折號(hào)來(lái)調(diào)用
kubectl foo-barI am a plugin with a dash in my name
# 你也可以使用下劃線來(lái)調(diào)用我們的定制命令
kubectl foo_barI am a plugin with a dash in my name
命名沖突和弊端
可以在 ?PATH ?的不同位置提供多個(gè)文件名相同的插件， 例如，給定一個(gè) ?PATH ?為: ?PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins?， 在 ?/usr/local/bin/plugins? 和 ?/usr/local/bin/moreplugins? 中可以存在一個(gè)插件 ?kubectl-foo? 的副本，這樣 ?kubectl plugin list? 命令的輸出就是:
PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/plugins/kubectl-foo
/usr/local/bin/moreplugins/kubectl-foo
- warning: /usr/local/bin/moreplugins/kubectl-foo is overshadowed by a similarly named plugin: /usr/local/bin/plugins/kubectl-foo
error: one plugin warning was found在上面的場(chǎng)景中 ?/usr/local/bin/moreplugins/kubectl-foo? 下的警告告訴我們這個(gè)插件永遠(yuǎn)不會(huì)被執(zhí)行。 相反，首先出現(xiàn)在我們路徑中的可執(zhí)行文件 ?/usr/local/bin/plugins/kubectl-foo? 總是首先被 ?kubectl ?插件機(jī)制找到并執(zhí)行。
解決這個(gè)問(wèn)題的一種方法是你確保你希望與 ?kubectl ?一起使用的插件的位置總是在你的路徑中首先出現(xiàn)。 例如，如果我們總是想使用 ?/usr/local/bin/moreplugins/kubectl foo?， 那么在調(diào)用 ?kubectl ?命令 ?kubectl foo? 時(shí)，我們只需將路徑的值更改為 ?PATH=/usr/local/bin/moreplugins:/usr/local/bin/plugins?。
調(diào)用最長(zhǎng)的可執(zhí)行文件名
對(duì)于插件文件名而言還有另一種弊端，給定用戶路徑中的兩個(gè)插件 ?kubectl-foo-bar? 和 ?kubectl-foo-bar-baz? ?kubectl ?插件機(jī)制總是為給定的用戶命令選擇盡可能長(zhǎng)的插件名稱。下面的一些例子進(jìn)一步的說(shuō)明了這一點(diǎn)：
# 對(duì)于給定的 kubectl 命令，最長(zhǎng)可能文件名的插件是被優(yōu)先選擇的
kubectl foo bar bazPlugin kubectl-foo-bar-baz is executed
kubectl foo bar
Plugin kubectl-foo-bar is executed
kubectl foo bar baz buz
Plugin kubectl-foo-bar-baz is executed, with "buz" as its first argument
kubectl foo bar buz
Plugin kubectl-foo-bar is executed, with "buz" as its first argument
這種設(shè)計(jì)選擇確保插件子命令可以跨多個(gè)文件實(shí)現(xiàn)，如果需要，這些子命令可以嵌套在"父"插件命令下：
ls ./plugin_command_tree
kubectl-parent
kubectl-parent-subcommand
kubectl-parent-subcommand-subsubcommand檢查插件警告
你可以使用前面提到的 ?kubectl plugin list? 命令來(lái)確保你的插件可以被 ?kubectl ?看到， 并且驗(yàn)證沒(méi)有警告防止它被稱為 ?kubectl ?命令。
kubectl plugin list
The following kubectl-compatible plugins are available:
test/fixtures/pkg/kubectl/plugins/kubectl-foo
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo is overshadowed by a similarly named plugin: test/fixtures/pkg/kubectl/plugins/kubectl-foo
plugins/kubectl-invalid
- warning: plugins/kubectl-invalid identified as a kubectl plugin, but it is not executable
error: 2 plugin warnings were found使用命令行運(yùn)行時(shí)包
如果你在編寫 kubectl 插件，而且你選擇使用 Go 語(yǔ)言，你可以利用 cli-runtime 工具庫(kù)。
這些庫(kù)提供了一些輔助函數(shù)，用來(lái)解析和更新用戶的 ?kubeconfig ?文件，向 API 服務(wù)器發(fā)起 REST 風(fēng)格的請(qǐng)求，或者將參數(shù)綁定到某配置上， 抑或?qū)⑵浯蛴≥敵觥?/p>
關(guān)于 CLI Runtime 倉(cāng)庫(kù)所提供的工具的使用實(shí)例，可參考 CLI 插件示例 項(xiàng)目。
分發(fā) kubectl 插件
如果你開(kāi)發(fā)了一個(gè)插件給別人使用，你應(yīng)該考慮如何為其封裝打包、如何分發(fā)軟件 以及將來(lái)的更新到用戶。
Krew
Krew 提供了一種對(duì)插件進(jìn)行打包和分發(fā)的跨平臺(tái)方式。 基于這種方式，你會(huì)在所有的目標(biāo)平臺(tái)（Linux、Windows、macOS 等）使用同一 種打包形式，包括為用戶提供更新。 Krew 也維護(hù)一個(gè)插件索引（plugin index） 以便其他人能夠發(fā)現(xiàn)你的插件并安裝之。
原生的與特定平臺(tái)的包管理
另一種方式是，你可以使用傳統(tǒng)的包管理器（例如 Linux 上 的 ?apt ?或 ?yum?， Windows 上的 Chocolatey、macOs 上的 Homebrew）。 只要能夠?qū)⑿碌目蓤?zhí)行文件放到用戶的 ?PATH ?路徑上某處，這種包管理器就符合需要。 作為一個(gè)插件作者，如果你選擇這種方式來(lái)分發(fā)，你就需要自己來(lái)管理和更新 你的 kubectl 插件的分發(fā)包，包括所有平臺(tái)和所有發(fā)行版本。
源代碼
你也可以發(fā)布你的源代碼，例如，發(fā)布為某個(gè) Git 倉(cāng)庫(kù)。 如果你選擇這條路線，希望使用該插件的用戶必須取回代碼、配置一個(gè)構(gòu)造環(huán)境 （如果需要編譯的話）并部署該插件。 如果你也提供編譯后的軟件包，或者使用 Krew，那就會(huì)大大簡(jiǎn)化安裝過(guò)程了。
新聞標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes用插件擴(kuò)展kubectl
網(wǎng)頁(yè)路徑：http://www.dlmjj.cn/article/cdjghgj.html
