意外又看到不少正在學 Kubernetes 新手。想想本人寫過各種自己懂或不懂、信或不信的原理、機制、方法和工具等等各種東西，唯獨沒寫過 kubectl，其實這東西也是值得一寫的——比如說去年我才從一線同學的操作裡學會用 -A 代替 --all-namespaces。理順 kubectl 的用法，也會對 Kubernetes 的知識體系以及運維工作有很大的幫助。
對 Kubernetes 稍有了解的讀者應該都知道聲明式 API 的說法，kubectl 就是一個這種 API 的客戶端，所以 kubectl 的主要功能就是用來操作對象的。
開局兩張圖下圖是個常見的使用方式：
其實本來想寫主謂賓定狀補的，後來想想還得複習一下，算了算了。
一般的 kubectl 使用都是這麼個順序，參數是可以調整位置的，暫且如此就可以了。
用一個思維導圖來歸納一下：
動作在 kubectl 中被稱為 command 也就是命令。使用 kubectl --help 能看到可用的命令列表：
$ kubectl --help
kubectl controls the Kubernetes cluster manager.
Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/
Basic Commands (Beginner):
create Create a resource from a file or from stdin.
...
run 在集群中運行一個指定的鏡像
...
Basic Commands (Intermediate):
explain 查看資源的文檔
get 顯示一個或更多 resources
...
Deploy Commands:
rollout Manage the rollout of a resource
...
可以看到 kubectl 的命令行幫助非常不錯，不僅有功能說明、分類，還有難度標識，甚至有部分的中文說明，kubectl 的每個命令都可以用 --help 查看進一步的幫助說明。
這裡列出了很多可用的命令，按照操作能力，主流命令基本可以分為增刪改查（CRUD）四種。
C新建命令用於在集群中創建對象，最常用的新建命令應該是 create、run 了，create 能夠創建多種對象，而 run 則主要用來創建 Pod。這兩個命令都需要在命令行中使用參數的方式來表達待創建的對象的欄位內容，其表達力非常粗糙和有限，並且帶有明顯的命令式 API 風味，在我的日常工作中已經很少用到這樣的命令了。
但是這種命令往往有個妙用，--dry-run=client（舊版本中是 --dry-run），可以在不產生實際操作的情況下，測試命令的輸出，加上 -o yaml，可以幫助輸出 YAML 文檔。
Rget 是最常用的查詢指令，用於獲取對象列表和基本信息，而 describe 則用於獲取一個對象的詳細信息。另外一個常用的讀取指令就是 Debug 常用的日誌查看指令：kubectl logs。
U最重要的更新命令可以說是 apply，edit 了，patch、label、annotation、scale 等命令也算常用。
apply 是把 yaml 提交給 Kubernetes 集群的最常用方式，而 edit patch 都是用於修改線上負載的常用手段。label 和 annotation 命令則是用於修改對象元數據的，例如標籤和註解。
D這個沒什麼好說——delete
獲取幫助kubectl 的所有命令、子命令都支持 --help 參數，可以用這種方式獲取幫助。
kubectl options 命令能夠獲取 kubectl 的所有全局參數。
常用參數-f：很多指令（不只是 apply 和 create）都可以用 -f <文件名> 的方式進行輸入，如果使用管道操作，則可以用參數 -f - 接收 STDIN 的輸入。
-l：可以使用各種對象上的標籤對操作範圍進行過濾，例如 -l app=hello
-o：指定輸出格式，這個參數相對複雜，最常用的是 yaml 或者 json 用於輸出機器報文，還可以用 JSON Path 或者 Go Template 對結果進行處理。
對象對象通常是類型+名稱的一個組合，可以用 kubectl 獲得當前集群支持的對象類型：
如上圖，輸出內容包含幾個列：名稱、簡稱、API 群組、是否歸屬命名空間以及對象的 Kind 屬性。例如常用的 Deployment：
名稱：
Deployment
簡稱：
Deploy
API 群組：
apps
歸屬命名空間：
是
Kind：
Deployment
使用命令 kubectl get deploy，就能獲得當前命名空間中的 Deployment 對象列表，如果在尾巴上加入 Deployment 的名稱，就能得到符合名稱要求的 Deployment 對象，
Schema前面提到的 -f 參數，或者是 get -o yaml，都要用到具體的對象數據結構，這個結構到底是哪裡規定的呢？基本結構可以分為三個部分，以一個 Namespace 為例：
apiVersion: v1
kind: Namespace
metadata:
name: default
spec:
finalizers:
- kubernetes
一般會分為四個基礎欄位：apiVersion、kind、metadata、status 以及 spec。
apiVersion：
格式為 <apiGroup>/<apiVersion>，一個對象的 API Group，可以用前文提到的 api-resources 命令查到，而版本則可以通過 kubectl api-versions 查詢得到。
kind：
對應 api-resources 命令輸出的欄位。
metadata：
元數據，其中包括標籤、註解、名稱等欄位，如果對象是屬於命名空間的，也會把命名空間寫在這裡。
status：
這個欄位的內容通常是由 Kubenretes 自動填寫的。
經常會被省略掉。
spec：
具體的對象內容，可以由幾個途徑獲取其定義結構
部分資源可以使用 kubectl explain <對象類別> 獲得解釋
如果該資源在集群中有對象存在，可以使用 kubectl get <對象類別> <對象名稱> -o yaml 的方式獲得原文，向其致敬。
如果前兩種方法都沒有，就需要去查看 Kubernetes 或者第三方的 API Reference 了。
最後看了上面的解釋，是不是對 Kubernetes 的控制臺操作有點底了？