Kubernetes之kubectl常用命令

好久沒寫部落格了，前段時間公司搞997太凶殘。997結束也快1個禮拜了，終於緩過來一點了，先來兩篇輕鬆點文章，然後再來點幹活，寫一個kubernetes的系列。這篇主要介紹一下kubernetes相關的命令，供初接觸kubernetes的參考。

kubernetes通過kube-apiserver作為整個叢集管理的入口。Apiserver是整個叢集的主管理節點，使用者通過Apiserver配置和組織叢集，同時叢集中各個節點同etcd儲存的互動也是通過Apiserver進行互動。Apiserver實現了一套RESTful的介面，使用者可以直接使用API同Apiserver互動。另外官方還提供了一個客戶端kubectl隨工具集打包，用於可直接通過kubectl以命令列的方式同叢集互動。

由於博主水平有限，本文主要介紹一些博主在日常中經常使用到的命令，另外最近正式release的kubernetes 1.2中新加入的的一些feature，由於博主也還沒有深入研究，所以不會太多涉及。

1. Help

類似於所有的命令列工具工具，kubectl也可以直接執行<kubectl>或<kubectl help> | <kubectl --help>可獲得命令的幫助資訊。如下圖所示，kubectl使用方式為：

Usage：
    kubectl [flags]
    kubectl [commond]

另外所有的命令選項都可以通過執行--help獲得特定命令的幫助資訊。

2. get

get命令用於獲取叢集的一個或一些resource資訊。使用--help檢視詳細資訊。kubectl的幫助資訊、示例相當詳細，而且簡單易懂。建議大家習慣使用幫助資訊。kubectl可以列出叢集所有resource的詳細。resource包括叢集節點、執行的pod，ReplicationController，service等。

Usage:
  kubectl get [(-o|--output=)json|yaml|wide|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...] (TYPE [NAME | -l label] | TYPE/NAME ...) [flags] [flags]

1）例如獲取pod資訊，可以直接使用"kubectl get po“獲取當前執行的所有pods的資訊，或使用”kubectl get po -o wide“獲取pod執行在哪個節點上的資訊。注:叢集中可以建立多個namespace，未顯示的指定namespace的情況下，所有操作都是針對default namespace。如下圖所示列出了default 和kube-system的pods：

2）獲取namespace資訊

# kubectl get namespace

3）類似可以使用"kubectl get rc”, “kubectl get svc”, “kubectl get nodes”等獲取其他resource資訊。
4）獲取一些更具體的資訊，可以通過使用選項“-o”。如：
（1）kubectl get po <podname> -o yaml 以yawl格式輸出pod的詳細資訊。

（2）kubectl get po <podname> -o json 以jison格式輸出pod的詳細資訊。

（3）另外還可以使用”-o=custom-columns=“定義直接獲取指定內容的值。如前面使用json和ymal格式的輸出中，metadata.labels.app的值可以使用如下命令獲取。

kubectl get po rc-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命令。

kubectl describe po rc-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

apiVersion: v1
kind: ReplicationController
metadata:
  name: rc-nginx-2
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx-2
    spec:
      containers:
      - name: nginx-2
        image: xingwangc.docker.rg/nginx
        ports:
        - containerPort: 80

直接使用create則可以基於rc-nginx.yaml檔案建立出ReplicationController（rc），rc會建立兩個副本：

kubectl create -f rc-nginx.yaml

建立後，使用“kubectl get rc”可以看到一個名為rc-nginx-2的ReplicationController將被建立，同時“kubectl get po”的結果中會多出兩個字首為“rc-nginx-2-”的pod。關於kubernetes叢集中resource，pod， ReplicationController…等後續會新開博文詳細介紹。

5. replace

replace命令用於對已有資源進行更新、替換。如前面create中建立的nginx，當我們需要更新resource的一些屬性的時候，如果修改副本數量，增加、修改label，更改image版本，修改埠等。都可以直接修改原yaml檔案，然後執行replace命令。

注：名字不能被更更新。另外，如果是更新label，原有標籤的pod將會與更新label後的rc斷開聯絡，有新label的rc將會建立指定副本數的新的pod，但是預設並不會刪除原來的pod。所以此時如果使用get po將會發現pod數翻倍，進一步check會發現原來的pod已經不會被新rc控制，此處只介紹命令不詳談此問題，好奇者可自行實驗。

kubectl replace -f rc-nginx.yaml 

6. patch

如果一個容器已經在執行，這時需要對一些容器屬性進行修改，又不想刪除容器，或不方便通過replace的方式進行更新。kubernetes還提供了一種在容器執行時，直接對容器進行修改的方式，就是patch命令。
如前面建立pod的label是app=nginx-2，如果在執行過程中，需要把其label改為app=nginx-3，這patch命令如下：

kubectl patch pod rc-nginx-2-kpiqt -p '{"metadata":{"labels":{"app":"nginx-3"}}}' 

7. edit

edit提供了另一種更新resource源的操作，通過edit能夠靈活的在一個common的resource基礎上，發展出更過的significant resource。例如，使用edit直接更新前面建立的pod的命令為：

kubectl edit po rc-nginx-btv4j 

上面命令的效果等效於：

kubectl get po rc-nginx-btv4j -o yaml >> /tmp/nginx-tmp.yaml 
vim /tmp/nginx-tmp.yaml 
/*do some changes here */ 
kubectl replace -f /tmp/nginx-tmp.yaml 

8. Delete

根據resource名或label刪除resource。

kubectl delete -f rc-nginx.yaml 
kubectl delete po rc-nginx-btv4j 
kubectl delete po -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選項。

kubectl logs rc-nginx-2-kpiqt 

11. rolling-update

rolling-update是一個非常重要的命令，對於已經部署並且正在執行的業務，rolling-update提供了不中斷業務的更新方式。rolling-update每次起一個新的pod，等新pod完全起來後刪除一箇舊的pod，然後再起一個新的pod替換舊的pod，直到替換掉所有的pod。

rolling-update需要確保新的版本有不同的name，Version和label，否則會報錯 。

kubectl rolling-update rc-nginx-2 -f rc-nginx.yaml 

如果在升級過程中，發現有問題還可以中途停止update，並回滾到前面版本

kubectl rolling-update rc-nginx-2 —rollback 

rolling-update還有很多其他選項提供豐富的功能，如—update-period指定間隔週期，使用時可以使用-h檢視help資訊

12. scale

scale用於程式在負載加重或縮小時副本進行擴容或縮小，如前面建立的nginx有兩個副本，可以輕鬆的使用scale命令對副本數進行擴充套件或縮小。
擴充套件副本數到4：

kubectl scale rc rc-nginx-3 —replicas=4 

重新縮減副本數到2：

kubectl scale rc rc-nginx-3 —replicas=2 

13. autoscale

scale雖然能夠很方便的對副本數進行擴充套件或縮小，但是仍然需要人工介入，不能實時自動的根據系統負載對副本數進行擴、縮。autoscale命令提供了自動根據pod負載對其副本進行擴縮的功能。

autoscale命令會給一個rc指定一個副本數的範圍，在實際執行中根據pod中執行的程式的負載自動在指定的範圍內對pod進行擴容或縮容。如前面建立的nginx，可以用如下命令指定副本範圍在1~4

kubectl autoscale rc rc-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容器的輸出。

 kubectl attach kube-dns-v9-rcfuk -c skydns —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檢視節點的資訊。

21. 其他

其他還有如cluster-info資訊可以檢視當前叢集的一些資訊，Version檢視叢集版本資訊等，還有一些叢集配置相關的命令等。