查看集群信息：

[[email protected] pods]# kubectl cluster-info
Kubernetes master is running at http://localhost:8080
KubeDNS is running at http://localhost:8080/api/v1/proxy/namespaces/kube-system/services/kube-dns

To further debug and diagnose cluster problems, use ‘kubectl cluster-info dump‘.

查看更詳細的可以用kubectl cluster-info dump

查看各組件狀態

[[email protected] pods]# kubectl -s http://localhost:8080 get componentstatuses
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}

GET信息：

查看節點

[[email protected] pods]# kubectl get nodes
NAME STATUS AGE
10.64.8.69 Ready 7d
10.64.8.70 Ready 7d
10.64.8.72 Ready 7d

查看rc和namespace

[[email protected] pods]# kubectl get rc,namespace
NAME STATUS AGE
default Active 7d
kube-system Active 7d

查看pod和svc(和service一樣)

[[email protected] pods]# kubectl get pods,svc

以jison格式輸出pod的詳細信息，內容太長就不貼了

[[email protected] pods]# kubectl get po mysql -o json

還可以輸出其它格式和方法(kubectl get -h查看幫助)：

[(-o|--output=)json|yaml|wide|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...]

查看指定pod跑在哪個node上

[[email protected] pods]# kubectl get po mysql -o wide

獲取指定json或ymal格式的KEY數據,custom-columns=XXXXX（自定義列名）:.status.hostIP（以“點開始”，然後寫路徑就可以）:

[[email protected] pods]# kubectl get po mysql -o custom-columns=HOST-IP:.status.hostIP,POD-IP:.status.podIP
HOST-IP POD-IP
10.64.8.69 172.17.62.2

describe方法

describe類似於get，同樣用於獲取resource的相關信息。不同的是，get獲得的是更詳細的resource個性的詳細信息，describe獲得的是resource集群相關的信息。describe命令同get類似，但是describe不支持-o選項，對於同一類型resource，describe輸出的信息格式，內容域相同。
註：如果發現是查詢某個resource的信息，使用get命令能夠獲取更加詳盡的信息。但是如果想要查詢某個resource的狀態，如某個pod並不是在running狀態，這時需要獲取更詳盡的狀態信息時，就應該使用describe命令。

[[email protected] pods]# kubectl describe po mysql

create創建

kubectl命令用於根據文件或輸入創建集群resource。如果已經定義了相應resource的yaml或son文件，直接kubectl create -f filename即可創建文件內定義的resource。

也可以直接只用子命令[namespace/secret/configmap/serviceaccount]等直接創建相應的resource。從追蹤和維護的角度出發，建議使用json或yaml的方式定義資源。

kubectl create -f 文件名

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

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"}}}‘

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

Delete

根據resource名或label刪除resource。

kubectl delete -f rc-nginx.yaml

apply

logs

logs命令用於顯示pod運行中，容器內程序輸出到標準輸出的內容。跟docker的logs命令類似。如果要獲得tail -f 的方式，也可以使用-f選項。

kubectl logs rc-nginx-2-kpiqt

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信息

scale

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

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

重新縮減副本數到2：

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

autoscale

scale雖然能夠很方便的對副本數進行擴展或縮小，但是仍然需要人工介入，不能實時自動的根據系統負載對副本數進行擴、縮。autoscale命令提供了自動根據pod負載對其副本進行擴縮的功能。
autoscale命令會給一個rc指定一個副本數的範圍，在實際運行中根據pod中運行的程序的負載自動在指定的範圍內對pod進行擴容或縮容。如前面創建的nginx，可以用如下命令指定副本範圍在1~4

kubectl autoscale rc rc-nginx-3 —min=1 —max=4

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

exec

exec命令同樣類似於docker的exec命令，為在一個已經運行的容器中執行一條shell命令，如果一個pod容器中，有多個容器，需要使用-c選項指定容器。

run

類似於docker的run命令，直接運行一個image。

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狀態

k8s常用命令