Kubernetes之kubectl常用命令
1. Help
類似於所有的命令列工具工具,kubectl也可以直接執行或 | 可獲得命令的幫助資訊。如下圖所示,kubectl使用方式為:123 | Usage:kubectl[flags]kubectl[commond] |
另外所有的命令選項都可以通過執行 --help獲得特定命令的幫助資訊。
2. get
get命令用於獲取叢集的一個或一些resource資訊。使用--help檢視詳細資訊。kubectl的幫助資訊、示例相當詳細,而且簡單易懂。建議大家習慣使用幫助資訊。kubectl可以列出叢集所有resource的詳細。resource包括叢集節點、執行的pod,ReplicationController,service等。12 | Usage:kubectlget[(-o|--output=)json|yaml|wide|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...](TYPE[NAME|-llabel]|TYPE/NAME...)[flags][flags] |
1例如獲取pod資訊,可以直接使用"kubectl get po“獲取當前執行的所有pods的資訊,或使用”kubectl get po -o wide“獲取pod執行在哪個節點上的資訊。注:叢集中可以建立多個namespace,未顯示的指定namespace的情況下,所有操作都是針對default namespace。如下圖所示列出了default 和kube-system的pods:
1 | kubectlgetnamespace |
1 | kubectlgetporc-nginx-2-btv4j-o=custom-columns=LABELS:.metadata.labels.app |
其中LABELS為顯示的列標題,”.metadata.labels.app”為查詢的域名
(4)其他資源也可以使用類似的方式。3. describe
describe類似於get,同樣用於獲取resource的相關資訊。不同的是,get獲得的是更詳細的resource個性的詳細資訊,describe獲得的是resource叢集相關的資訊。describe命令同get類似,但是describe不支援-o選項,對於同一型別resource,describe輸出的資訊格式,內容域相同。注:如果發現是查詢某個resource的資訊,使用get命令能夠獲取更加詳盡的資訊。但是如果想要查詢某個resource的狀態,如某個pod並不是在running狀態,這時需要獲取更詳盡的狀態資訊時,就應該使用describe命令。
1 | kubectldescribeporc-nginx-2-btv4j |
4. create
kubectl命令用於根據檔案或輸入建立叢集resource。如果已經定義了相應resource的yaml或son檔案,直接kubectl create -f filename即可建立檔案內定義的resource。也可以直接只用子命令[namespace/secret/configmap/serviceaccount]等直接建立相應的resource。從追蹤和維護的角度出發,建議使用json或yaml的方式定義資源。如,前面get中獲取的兩個nginx pod的replication controller檔案內容如下。檔名為:rc-nginx.yaml
1234567891011121314151617 | apiVersion: v1kind: ReplicationControllermetadata:name: rc-nginx-2spec:replicas: 2template:metadata:labels:app: nginx-2spec:containers:- name: nginx-2image: xingwangc.docker.rg/nginxports:- containerPort: 80 |
1 | kubectlcreate-frc-nginx.yaml |
5. replace
replace命令用於對已有資源進行更新、替換。如前面create中建立的nginx,當我們需要更新resource的一些屬性的時候,如果修改副本數量,增加、修改label,更改image版本,修改埠等。都可以直接修改原yaml檔案,然後執行replace命令。注:名字不能被更更新。另外,如果是更新label,原有標籤的pod將會與更新label後的rc斷開聯絡,有新label的rc將會建立指定副本數的新的pod,但是預設並不會刪除原來的pod。所以此時如果使用get po將會發現pod數翻倍,進一步check會發現原來的pod已經不會被新rc控制,此處只介紹命令不詳談此問題,好奇者可自行實驗。
1 | kubectlreplace-frc-nginx.yaml |
6. patch
如果一個容器已經在執行,這時需要對一些容器屬性進行修改,又不想刪除容器,或不方便通過replace的方式進行更新。kubernetes還提供了一種在容器執行時,直接對容器進行修改的方式,就是patch命令。
如前面建立pod的label是app=nginx-2,如果在執行過程中,需要把其label改為app=nginx-3,這patch命令如下:
1 | kubectlpatchpodrc-nginx-2-kpiqt-p'{"metadata":{"labels":{"app":"nginx-3"}}}' |
此外,patch命令還可以用於對deployment進行平滑重啟,比如通過patch修改deployment中一些無關緊要的屬性,那麼deployment對應的pods會執行平滑重啟:
1 | kubectlpatchdeploymentyour-deployment-p"{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"$(date +%s)\"}}}}}" |
7. edit
edit提供了另一種更新resource源的操作,通過edit能夠靈活的在一個common的resource基礎上,發展出更過的significant resource。例如,使用edit直接更新前面建立的pod的命令為:
1 | kubectleditporc-nginx-btv4j |
1234 | kubectlgetporc-nginx-btv4j-oyaml >>/tmp/nginx-tmp.yamlvim/tmp/nginx-tmp.yaml/*dosomechangeshere*/kubectlreplace-f/tmp/nginx-tmp.yaml |
8. Delete
根據resource名或label刪除resource。
123 | kubectldelete-frc-nginx.yamlkubectldeleteporc-nginx-btv4jkubectldeletepo-lapp=nginx-2 |
9. apply
apply命令提供了比patch,edit等更嚴格的更新resource的方式。通過apply,使用者可以將resource的configuration使用source control的方式維護在版本庫中。每次有更新時,將配置檔案push到server,然後使用kubectl apply將更新應用到resource。kubernetes會在引用更新前將當前配置檔案中的配置同已經應用的配置做比較,並只更新更改的部分,而不會主動更改任何使用者未指定的部分。
apply命令的使用方式同replace相同,不同的是,apply不會刪除原有resource,然後建立新的。apply直接在原有resource的基礎上進行更新。同時kubectl apply還會resource中新增一條註釋,標記當前的apply。類似於git操作。
10. logs
logs命令用於顯示pod執行中,容器內程式輸出到標準輸出的內容。跟docker的logs命令類似。如果要獲得tail -f 的方式,也可以使用 -f 選項。
1 | kubectllogsrc-nginx-2-kpiqt |
11. rolling-update
rolling-update是一個非常重要的命令,對於已經部署並且正在執行的業務,rolling-update提供了不中斷業務的更新方式。rolling-update每次起一個新的pod,等新pod完全起來後刪除一箇舊的pod,然後再起一個新的pod替換舊的pod,直到替換掉所有的pod。
rolling-update需要確保新的版本有不同的name,Version和label,否則會報錯 。
1 | kubectlrolling-updaterc-nginx-2-frc-nginx.yaml |
1 | kubectlrolling-updaterc-nginx-2--rollback |
12. scale
scale用於程式在負載加重或縮小時副本進行擴容或縮小,如前面建立的nginx有兩個副本,可以輕鬆的使用scale命令對副本數進行擴充套件或縮小。
擴充套件副本數到4:
1 | kubectlscalercrc-nginx-3--replicas=4 |
1 | kubectlscalercrc-nginx-3--replicas=2 |
13. autoscale
scale雖然能夠很方便的對副本數進行擴充套件或縮小,但是仍然需要人工介入,不能實時自動的根據系統負載對副本數進行擴、縮。autoscale命令提供了自動根據pod負載對其副本進行擴縮的功能。
autoscale命令會給一個rc指定一個副本數的範圍,在實際執行中根據pod中執行的程式的負載自動在指定的範圍內對pod進行擴容或縮容。如前面建立的nginx,可以用如下命令指定副本範圍在1~4
1 | kubectlautoscalercrc-nginx-3--min=1--max=4 |
14. cordon, drain, uncordon
這三個命令是正式release的1.2新加入的命令,三個命令一起介紹,是因為三個命令配合使用可以實現節點的維護。在1.2之前,因為沒有相應的命令支援,如果要維護一個節點,只能stop該節點上的kubelet將該節點退出叢集,是叢集不在將新的pod排程到該節點上。如果該節點上本生就沒有pod在執行,則不會對業務有任何影響。如果該節點上有pod正在執行,kubelet停止後,master會發現該節點不可達,而將該節點標記為notReady狀態,不會將新的節點排程到該節點上。同時,會在其他節點上建立新的pod替換該節點上的pod。這種方式雖然能夠保證叢集的健壯性,但是任然有些暴力,如果業務只有一個副本,而且該副本正好執行在被維護節點上的話,可能仍然會造成業務的短暫中斷。
1.2中新加入的這3個命令可以保證維護節點時,平滑的將被維護節點上的業務遷移到其他節點上,保證業務不受影響。如下圖所示是一個整個的節點維護的流程(為了方便demo增加了一些檢視節點資訊的操作):1)首先檢視當前叢集所有節點狀態,可以看到共四個節點都處於ready狀態;2)檢視當前nginx兩個副本分別執行在d-node1和k-node2兩個節點上;3)使用cordon命令將d-node1標記為不可排程;4)再使用kubectl get nodes檢視節點狀態,發現d-node1雖然還處於Ready狀態,但是同時還被禁能了排程,這意味著新的pod將不會被排程到d-node1上。4)再檢視nginx狀態,沒有任何變化,兩個副本仍執行在d-node1和k-node2上;5)執行drain命令,將執行在d-node1上執行的pod平滑的趕到其他節點上;6)再檢視nginx的狀態發現,d-node1上的副本已經被遷移到k-node1上;這時候就可以對d-node1進行一些節點維護的操作,如升級核心,升級Docker等;7)節點維護完後,使用uncordon命令解鎖d-node1,使其重新變得可排程;8)檢查節點狀態,發現d-node1重新變回Ready狀態。
15. attach
attach命令類似於docker的attach命令,可以直接檢視容器中以daemon形式執行的程序的輸出,效果類似於logs -f,退出檢視使用ctrl-c。如果一個pod中有多個容器,要檢視具體的某個容器的的輸出,需要在pod名後使用-c containers name指定執行的容器。如下示例的命令為檢視kube-system namespace中的kube-dns-v9-rcfuk pod中的skydns容器的輸出。
1 | kubectlattachkube-dns-v9-rcfuk-cskydns—namespace=kube-system |
16. exec
exec命令同樣類似於docker的exec命令,為在一個已經執行的容器中執行一條shell命令,如果一個pod容器中,有多個容器,需要使用-c選項指定容器。
17. port-forward
轉發一個本地埠到容器埠,博主一般都是使用yaml的方式編排容器,所以基本不使用此命令。
18. proxy
博主只嘗試過使用nginx作為kubernetes多master HA方式的代理,沒有使用過此命令為kubernetes api server執行過proxy
19. run
類似於docker的run命令,直接執行一個image。
20. label
為kubernetes叢集的resource打標籤,如前面例項中提到的為rc打標籤對rc分組。還可以對nodes打標籤,這樣在編排容器時,可以為容器指定nodeSelector將容器排程到指定lable的機器上,如如果叢集中有IO密集型,計算密集型的機器分組,可以將不同的機器打上不同標籤,然後將不同特徵的容器排程到不同分組上。
在1.2之前的版本中,使用kubectl get nodes則可以列出所有節點的資訊,包括節點標籤,1.2版本中不再列出節點的標籤資訊,如果需要檢視節點被打了哪些標籤,需要使用describe檢視節點的資訊。