1.0 k8s 集群狀態檢查
# 查看集群信息
kubectl cluster-info
systemctl status kube-apiserver
systemctl status kubelet
systemctl status kube-proxy
systemctl status kube-scheduler
systemctl status kube-controller-manager
systemctl status docker
# 查看namespaces
kubectl get namespaces
# 為節點增加lable
kubectl label nodes 10.126.72.31 points=test
# 查看節點和lable
kubectl get nodes --show-labels
# 查看狀態
kubectl get componentstatuses
# Node的隔離與恢復 ## 隔離
kubectl cordon k8s-node1
## 恢復
kubectl uncordon k8s-node1
#查詢 # 查看nodes節點
kubectl get nodes
# 通過yaml文件查詢
kubectl get -f xxx-yaml/ # 查詢資源
kubectl get resourcequota
# endpoints端
kubectl get endpoints
# 查看pods
# 查看指定空間`kube-system`的pods
kubectl get po -n kube-system
# 查看所有空間的
kubectl get pods -o wide --all-namespaces
# 其他的寫法
kubectl get pod -o wide --namespace=kube-system
# 獲取svc
kubectl get svc --all-namespaces
# 其他寫法
kubectl get services --all-namespaces
# 通過lable查詢
kubectl get pods -l app=nginx -o yaml|grep podIP
# 當我們發現一個pod遲遲無法創建時，描述一個pods
kubectl describe pod xxx
刪除所有pod # 刪除所有pods
kubectl delete pods --all
# 刪除所有包含某個lable的pod和serivce
kubectl delete pods,services -l name=<lable-name> # 刪除ui server,然后重建
kubectl delete deployments kubernetes-dashboard --namespace=kube-system
kubectl delete services kubernetes-dashboard --namespace=kube-system
# 強制刪除部署
kubectl delete deployment kafka-1 # 刪除rc
kubectl delete rs --all && kubectl delete rc --all
## 強制刪除Terminating狀態的pod
kubectl delete deployment kafka-1 --grace-period=0 --force
滾動 # 升級
kubectl apply -f xxx.yaml --record
# 回滾
kubectl rollout undo deployment javademo
# 查看滾動升級記錄
kubectl rollout history deployment {名稱}
查看日志 # 查看指定鏡像的日志
kubectl logs -f kube-dns-699984412-vz1q6 -n kube-system
kubectl logs --tail=10 nginx
#指定其中一個查看日志
kubectl logs kube-dns-699984412-n5zkz -c kubedns --namespace=kube-system
kubectl logs kube-dns-699984412-vz1q6 -c dnsmasq --namespace=kube-system
kubectl logs kube-dns-699984412-mqb14 -c sidecar --namespace=kube-system
# 看日志
journalctl -f
擴展 # 擴展副本
kubectl scale rc xxxx --replicas=3
kubectl scale rc mysql --replicas=1
kubectl scale --replicas=3 -f foo.yaml
執行 # 啟動
nohup kubectl proxy --address='10.1.70.247' --port=8001 --accept-hosts='^*$' >/dev/null 2>&1 & # 進入鏡像
kubectl exec kube-dns-699984412-vz1q6 -n kube-system -c kubedns ifconfig
kubectl exec kube-dns-699984412-vz1q6 -n kube-system -c kubedns ifconfig /bin/bash
# 執行鏡像內命令
kubectl exec kube-dns-4140740281-pfjhr -c etcd --namespace=kube-system etcdctl get /skydns/local/cluster/default/redis-master
無限循環命令 while true; do sleep 1; done 資源管理 # 暫停資源更新（資源變更不會生效）
kubectl rollout pause deployment xxx
# 恢復資源更新
kubectl rollout resume deployment xxx
# 設置內存、cpu限制
kubectl set resources deployment xxx -c=xxx --limits=cpu=200m,memory=512Mi --requests=cpu=1m,memory=1Mi
# 設置storageclass為默認
kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' 其他 # 創建和刪除
kubectl create -f dashboard-controller.yaml
kubectl delete -f dashboard-dashboard.yaml
# 查看指定pods的環境變量
kubectl exec xxx env # 判斷dns是否通
kubectl exec busybox -- nslookup kube-dns.kube-system
# kube-proxy狀態
systemctl status kube-proxy -l
# 查看token
kubectl get serviceaccount/kube-dns --namespace=kube-system -o yaml|grep token
查看幫助：
[root@master1 ~]# kubectl --help
查看版本：（至今，yum安裝的版本竟然是1.5.2，，這兩天准備升級到1.8x）
[root@master1 ~]# kubectl --version
Kubernetes v1.5.2
get
get命令用於獲取集群的一個或一些resource信息。 使用–help查看詳細信息。
Ps：kubectl的幫助信息、示例相當詳細，而且簡單易懂。建議大家習慣使用幫助信息。kubectl可以列出集群所有resource的詳細。resource包括集群節點、運行的pod，ReplicationController，service等。
基礎查看命令
# kubectl get po //查看所有的pods
# kubectl get nodes //查看所有的nodes
# kubectl get pods -o wide //查看所有的pods更詳細些
# kubectl get nodes -o wide //查看所有的nodes更詳細些
# kubectl get po --all-namespaces //查看所有的namespace
3種方式查看一個pod的詳細信息和參數： # kubectl get po pod-redis -o yaml //以yaml文件形式顯示一個pod的詳細信息
kubectl get po <podname> -o json //以json文件形式顯示一個pod的詳細信息
2.0 常用命令詳解
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-3-l8v2r
create
不多講了，前面已經說了很多次了。 直接使用create則可以基於rc-nginx-3.yaml文件創建出ReplicationController（rc），rc會創建兩個副本：
# kubectl create -f rc-nginx.yaml
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
kubectl delete po rc-nginx-btv4j
kubectl delete po -lapp=nginx-2
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操作。
logs
logs命令用於顯示pod運行中，容器內程序輸出到標准輸出的內容。跟docker的logs命令類似。如果要獲得tail -f 的方式，也可以使用-f選項。
# kubectl get pods
# kubectl logs mysql-478535978-1dnm2
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
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上。
5）再查看nginx狀態，沒有任何變化，兩個副本仍運行在d-node1和k-node2上；
6）執行drain命令，將運行在d-node1上運行的pod平滑的趕到其他節點上；
7）再查看nginx的狀態發現，d-node1上的副本已經被遷移到k-node1上；這時候就可以對d-node1進行一些節點維護的操作，如升級內核，升級Docker等；
8）節點維護完后，使用uncordon命令解鎖d-node1，使其重新變得可調度；
9）檢查節點狀態，發現d-node1重新變回Ready狀態。
attach
類似於docker attach的功能，用於取得實時的類似於kubectl logs的信息
# kubectl get pods# kubectl attach sonarqube-3574384362-m7mdq
exec
exec命令同樣類似於docker的exec命令，為在一個已經運行的容器中執行一條shell命令，如果一個pod容器中，有多個容器，需要使用-c選項指定容器。
# kubectl get pods
# kubectl exec mysql-478535978-1dnm2 hostname //查看這個容器的hostname
port-forward
轉發一個本地端口到容器端口，博主一般都是使用yaml的方式編排容器，所以基本不使用此命令。
proxy
博主只嘗試過使用nginx作為kubernetes多master HA方式的代理，沒有使用過此命令為kubernetes api server運行過proxy
run
類似於docker的run命令，直接運行一個image。
label
為kubernetes集群的resource打標簽，如前面實例中提到的為rc打標簽對rc分組。還可以對nodes打標簽，這樣在編排容器時，可以為容器指定nodeSelector將容器調度到指定lable的機器上，如如果集群中有IO密集型，計算密集型的機器分組，可以將不同的機器打上不同標簽，然后將不同特征的容器調度到不同分組上。
在1.2之前的版本中，使用kubectl get nodes則可以列出所有節點的信息，包括節點標簽，1.2版本中不再列出節點的標簽信息，如果需要查看節點被打了哪些標簽，需要使用describe查看節點的信息。
cp
kubectl cp 用於pod和外部的文件交換。
在pod中創建一個文件message.log
# kubectl exec -it mysql-478535978-1dnm2 sh
#touch message.log
# kubectl cp message.log mysql-478535978-1dnm2:/tmp/message.log
kubectl cluster-info
使用cluster-info和cluster-info dump也能取出一些信息，尤其是你需要看整體的全部信息的時候一條命令一條命令的執行不如kubectl cluster-info dump來的快一些
# kubectl cluster-info
Kubernetes master is running at http://localhost:8080
3.0 常用命令實戰詳解
集群構成
一主三從的Kubernetes集群
[root@ku8-1 tmp]# kubectl get nodes
NAME STATUS AGE
192.168.32.132 Ready 12m
192.168.32.133 Ready 11m
192.168.32.134 Ready 11m
yaml文件：
[root@ku8-1 tmp]# cat nginx/nginx.yaml
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
name: nginx
spec:
replicas: 1
template:
metadata:
labels:
name: nginx
spec:
containers:
- name: nginx
image: 192.168.32.131:5000/nginx:1.12-alpine
ports:
- containerPort: 80
protocol: TCP
---
kind: Service
apiVersion: v1
metadata:
name: nginx
labels:
name: nginx
spec:
type: NodePort
ports:
- protocol: TCP
nodePort: 31001
targetPort: 80
port: 80
selector:
name: nginx
創建pod/deployment/service
[root@ku8-1 tmp]# kubectl create -f nginx/
deployment "nginx" created
service "nginx" created
確認 創建pod/deployment/service
[root@ku8-1 tmp]# kubectl get service
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 172.200.0.1 <none> 443/TCP 1d
nginx 172.200.229.212 <nodes> 80:31001/TCP 58s
[root@ku8-1 tmp]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-2476590065-1vtsp 1/1 Running 0 1m
[root@ku8-1 tmp]# kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 1m
kubectl edit
edit這條命令用於編輯 服務器 上的資源，具體是什么意思，可以通過如下使用方式來確認。
編輯對象確認
使用-o參數指定輸出格式為yaml的nginx的service的設定情況確認，取得現場情況，這也是我們不知道其yaml文件而只有環境時候能做的事情。
[root@ku8-1 tmp]# kubectl get service |grep nginx
nginx 172.200.229.212 <nodes> 80:31001/TCP 2m
[root@ku8-1 tmp]# kubectl get service nginx -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: 2017-06-30T04:50:44Z
labels:
name: nginx
name: nginx
namespace: default
resourceVersion: "77068"
selfLink: /api/v1/namespaces/default/services/nginx
uid: ad45612a-5d4f-11e7-91ef-000c2933b773
spec:
clusterIP: 172.200.229.212
ports:
- nodePort: 31001
port: 80
protocol: TCP
targetPort: 80
selector:
name: nginx
sessionAffinity: None
type: NodePort
status:
loadBalancer: {}
使用edit命令對nginx的service設定進行編輯，得到如下信息
可以看到當前端口為31001，在此編輯中，我們把它修改為31002
[root@ku8-1 tmp]# kubectl edit service nginx
service "nginx" edited
編輯之后確認結果發現，此服務端口已經改變
[root@ku8-1 tmp]# kubectl get service
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 172.200.0.1 <none> 443/TCP 1d
nginx 172.200.229.212 <nodes> 80:31002/TCP 8m
確認后發現能夠立連通
[root@ku8-1 tmp]# curl http://192.168.32.132:31002/
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
而之前的端口已經不通
[root@ku8-1 tmp]# curl http://192.168.32.132:31001/
curl: (7) Failed connect to 192.168.32.132:31001; Connection refused
kubectl replace
了解到edit用來做什么之后，我們會立即知道replace就是替換，我們使用上個例子中的service的port，重新把它改回31001
[root@ku8-1 tmp]# kubectl get service
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 172.200.0.1 <none> 443/TCP 1d
nginx 172.200.229.212 <nodes> 80:31002/TCP 17m
取得當前的nginx的service的設定文件，然后修改port信息
[root@ku8-1 tmp]# kubectl get service nginx -o yaml >nginx_forreplace.yaml
[root@ku8-1 tmp]# cp -p nginx_forreplace.yaml nginx_forreplace.yaml.org
[root@ku8-1 tmp]# vi nginx_forreplace.yaml
[root@ku8-1 tmp]# diff nginx_forreplace.yaml nginx_forreplace.yaml.org
15c15
< - nodePort: 31001
---
> - nodePort: 31002
執行replace命令
提示被替換了
[root@ku8-1 tmp]# kubectl replace -f nginx_forreplace.yaml
service "nginx" replaced
確認之后發現port確實重新變成了31001
[root@ku8-1 tmp]# kubectl get service
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 172.200.0.1 <none> 443/TCP 1d
nginx 172.200.229.212 <nodes> 80:31001/TCP 20m
kubectl patch
當部分修改一些設定的時候patch非常有用，尤其是在1.2之前的版本，port改來改去好無聊，這次換個image
當前port中使用的nginx是alpine的1.12版本
[root@ku8-1 tmp]# kubectl exec nginx-2476590065-1vtsp -it sh
/ # nginx -v
nginx version: nginx/1.12.0
執行patch進行替換
[root@ku8-1 tmp]# kubectl patch pod nginx-2476590065-1vtsp -p '{"spec":{"containers":[{"name":"nginx","image":"192.168.32.131:5000/nginx:1.13-alpine"}]}}'
"nginx-2476590065-1vtsp" patched
確認當前pod中的鏡像已經patch成了1.13
[root@ku8-1 tmp]# kubectl exec nginx-2476590065-1vtsp -it sh
/ # nginx -v
nginx version: nginx/1.13.1
kubectl scale scale命令用於橫向擴展，是kubernetes或者swarm這類容器編輯平台的重要功能之一，讓我們來看看是如何使用的
事前設定nginx的replica為一，而經過確認此pod在192.168.32.132上運行
[root@ku8-1 tmp]# kubectl delete -f nginx/
deployment "nginx" deleted
service "nginx" deleted
[root@ku8-1 tmp]# kubectl create -f nginx/
deployment "nginx" created
service "nginx" created
[root@ku8-1 tmp]#
[root@ku8-1 tmp]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-74tpk 1/1 Running 0 17s 172.200.26.2 192.168.32.132
[root@ku8-1 tmp]# kubectl get deployments -o wide
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 27s
執行scale命令 使用scale命令進行橫向擴展，將原本為1的副本，提高到3。
[root@ku8-1 tmp]# kubectl scale --current-replicas=1 --replicas=3 deployment/nginx
deployment "nginx" scaled
通過確認發現已經進行了橫向擴展，除了192.168.132.132，另外133和134兩台機器也各有一個pod運行了起來，這正是scale命令的結果。
[root@ku8-1 tmp]# kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 2m
[root@ku8-1 tmp]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-74tpk 1/1 Running 0 2m 172.200.26.2 192.168.32.132
nginx-2476590065-cm5d9 1/1 Running 0 16s 172.200.44.2 192.168.32.133
nginx-2476590065-hmn9j 1/1 Running 0 16s 172.200.59.2 192.168.32.134
kube autoscale ★★★★ autoscale命令用於自動擴展確認，跟scale不同的是前者還是需要手動執行，而autoscale則會根據負載進行調解。而這條命令則可以對Deployment/ReplicaSet/RC進行設定，通過最小值和最大值的指定進行設定，這里只是給出執行的結果，不再進行實際的驗證。
[root@ku8-1 tmp]# kubectl autoscale deployment nginx --min=2 --max=5
deployment "nginx" autoscaled
當然使用還會有一些限制，比如當前3個，設定最小值為2的話會出現什么樣的情況？
[root@ku8-1 tmp]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-74tpk 1/1 Running 0 5m 172.200.26.2 192.168.32.132
nginx-2476590065-cm5d9 1/1 Running 0 2m 172.200.44.2 192.168.32.133
nginx-2476590065-hmn9j 1/1 Running 0 2m 172.200.59.2 192.168.32.134
[root@ku8-1 tmp]# kubectl autoscale deployment nginx --min=2 --max=2
Error from server (AlreadyExists): horizontalpodautoscalers.autoscaling "nginx" already exists
kubectl cordon 與 uncordon ★★★ 在實際維護的時候會出現某個node壞掉，或者做一些處理，暫時不能讓生成的pod在此node上運行，需要通知kubernetes讓其不要創建過來，這條命令就是cordon，uncordon則是取消這個要求。例子如下：
創建了一個nginx的pod，跑在192.168.32.133上。
[root@ku8-1 tmp]# kubectl create -f nginx/
deployment "nginx" created
service "nginx" created
[root@ku8-1 tmp]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-dnsmw 1/1 Running 0 6s 172.200.44.2
192.168.32.133
執行scale命令 ★★★ 橫向擴展到3個副本，發現利用roundrobin策略每個node上運行起來了一個pod，134這台機器也有一個。
[root@ku8-1 tmp]# kubectl scale --replicas=3 deployment/nginx
deployment "nginx" scaled
[root@ku8-1 tmp]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-550sm 1/1 Running 0 5s 172.200.26.2 192.168.32.132
nginx-2476590065-bt3bc 1/1 Running 0 5s 172.200.59.2 192.168.32.134
nginx-2476590065-dnsmw 1/1 Running 0 17s 172.200.44.2 192.168.32.133
[root@ku8-1 tmp]# kubectl get pods -o wide |grep 192.168.32.134
nginx-2476590065-bt3bc 1/1 Running 0 12s 172.200.59.2 192.168.32.134
執行cordon命令 設定134，使得134不可使用，使用get node確認，其狀態顯示SchedulingDisabled。
[root@ku8-1 tmp]# kubectl cordon 192.168.32.134
node "192.168.32.134" cordoned
[root@ku8-1 tmp]# kubectl get nodes -o wide
NAME STATUS AGE EXTERNAL-IP
192.168.32.132 Ready 1d <none>
192.168.32.133 Ready 1d <none>
192.168.32.134 Ready,SchedulingDisabled 1d <none>
執行scale命令 再次執行橫向擴展命令，看是否會有pod漂到134這台機器上，結果發現只有之前的一個pod，再沒有新的pod漂過去。
[root@ku8-1 tmp]# kubectl scale --replicas=6 deployment/nginx
deployment "nginx" scaled
[root@ku8-1 tmp]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-550sm 1/1 Running 0 32s 172.200.26.2 192.168.32.132
nginx-2476590065-7vxvx 1/1 Running 0 3s 172.200.44.3 192.168.32.133
nginx-2476590065-bt3bc 1/1 Running 0 32s 172.200.59.2 192.168.32.134
nginx-2476590065-dnsmw 1/1 Running 0 44s 172.200.44.2 192.168.32.133
nginx-2476590065-fclhj 1/1 Running 0 3s 172.200.44.4 192.168.32.133
nginx-2476590065-fl9fn 1/1 Running 0 3s 172.200.26.3 192.168.32.132
[root@ku8-1 tmp]# kubectl get pods -o wide |grep 192.168.32.134
nginx-2476590065-bt3bc 1/1 Running 0 37s 172.200.59.2 192.168.32.134
執行uncordon命令 使用uncordon命令解除對134機器的限制，通過get node確認狀態也已經正常。
[root@ku8-1 tmp]# kubectl uncordon 192.168.32.134
node "192.168.32.134" uncordoned
[root@ku8-1 tmp]#
[root@ku8-1 tmp]# kubectl get nodes -o wide
NAME STATUS AGE EXTERNAL-IP
192.168.32.132 Ready 1d <none>
192.168.32.133 Ready 1d <none>
192.168.32.134 Ready 1d <none>
執行scale命令 再次執行scale命令，發現有新的pod可以創建到134node上了。
[root@ku8-1 tmp]# kubectl scale --replicas=10 deployment/nginx
deployment "nginx" scaled
[root@ku8-1 tmp]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-550sm 1/1 Running 0 1m 172.200.26.2 192.168.32.132
nginx-2476590065-7vn6z 1/1 Running 0 3s 172.200.44.4 192.168.32.133
nginx-2476590065-7vxvx 1/1 Running 0 35s 172.200.44.3 192.168.32.133
nginx-2476590065-bt3bc 1/1 Running 0 1m 172.200.59.2 192.168.32.134
nginx-2476590065-dnsmw 1/1 Running 0 1m 172.200.44.2 192.168.32.133
nginx-2476590065-fl9fn 1/1 Running 0 35s 172.200.26.3 192.168.32.132
nginx-2476590065-pdx91 1/1 Running 0 3s 172.200.59.3 192.168.32.134
nginx-2476590065-swvwf 1/1 Running 0 3s 172.200.26.5 192.168.32.132
nginx-2476590065-vdq2k 1/1 Running 0 3s 172.200.26.4 192.168.32.132
nginx-2476590065-wdv52 1/1 Running 0 3s 172.200.59.4 192.168.32.134
kubectl drain ★★★★★ drain命令用於對某個node進行設定，是為了設定此node為維護做准備。英文的drain有排干水的意思，下水道的水之后排干后才能進行維護。那我們來看一下kubectl”排水”的時候都作了什么
將nginx的副本設定為4，確認發現134上啟動了兩個pod。
[root@ku8-1 tmp]# kubectl create -f nginx/
deployment "nginx" created
service "nginx" created
[root@ku8-1 tmp]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-d6h8f 1/1 Running 0 8s 172.200.59.2 192.168.32.134
[root@ku8-1 tmp]#
[root@ku8-1 tmp]# kubectl get nodes -o wide
NAME STATUS AGE EXTERNAL-IP
192.168.32.132 Ready 1d <none>
192.168.32.133 Ready 1d <none>
192.168.32.134 Ready 1d <none>
[root@ku8-1 tmp]#
[root@ku8-1 tmp]# kubectl scale --replicas=4 deployment/nginx
deployment "nginx" scaled
[root@ku8-1 tmp]#
[root@ku8-1 tmp]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-9lfzh 1/1 Running 0 12s 172.200.59.3 192.168.32.134
nginx-2476590065-d6h8f 1/1 Running 0 1m 172.200.59.2 192.168.32.134
nginx-2476590065-v8xvf 1/1 Running 0 43s 172.200.26.2 192.168.32.132
nginx-2476590065-z94cq 1/1 Running 0 12s 172.200.44.2 192.168.32.133
執行drain命令
執行drain命令，發現這條命令做了兩件事情:
設定此node不可以使用（cordon)
evict了其上的兩個pod
[root@ku8-1 tmp]# kubectl drain 192.168.32.134
node "192.168.32.134" cordoned
pod "nginx-2476590065-d6h8f" evicted
pod "nginx-2476590065-9lfzh" evicted
node "192.168.32.134" drained
結果確認
evict的意思有驅逐和回收的意思，讓我們來看一下evcit這個動作的結果到底是什么。 結果是134上面已經不再有pod，而在132和133上新生成了兩個pod，用以替代在134上被退場的pod，而這個替代的動作應該是replicas的機制保證的。所以drain的結果就是退場pod和設定node不可用（排水），這樣的狀態則可以進行維護了，執行完后重新uncordon即可。
[root@ku8-1 tmp]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-2476590065-1ld9j 1/1 Running 0 13s 172.200.44.3 192.168.32.133
nginx-2476590065-ss48z 1/1 Running 0 13s 172.200.26.3 192.168.32.132
nginx-2476590065-v8xvf 1/1 Running 0 1m 172.200.26.2 192.168.32.132
nginx-2476590065-z94cq 1/1 Running 0 55s 172.200.44.2 192.168.32.133
[root@ku8-1 tmp]#
[root@ku8-1 tmp]# kubectl get nodes -o wide
NAME STATUS AGE EXTERNAL-IP
192.168.32.132 Ready 1d <none>
192.168.32.133 Ready 1d <none>
192.168.32.134 Ready,SchedulingDisabled 1d <none>
4.0 kubectl 深入解讀
kubectl cluster-info 查看集群信息
kubectl version 顯示命令行和kube服務端的版本
kubectl api-versions 顯示支持的api版本集合
kubectl config view 顯示當前kubectl的配置信息
kubectl logs 查看pod日志
kubectl exec -t [podname] /bin/bash 以交互模式進入容器執行命令
kubectl scale 實現水平或收縮
kubectl rollout status deploy [name]部署狀態變更狀態檢查
kubectl rollout history 部署歷史
kubectl rollout undo 回滾部署到最近或者某個版本
kubectl get nodes 查看集群中的節點
kubectl get [type] [name] 查看某種類型資源
kubectl describe [type] [name] 查看特定資源實例詳情
kubectl get ep 查看路由端點信息
kubectl set image deploy [deployment-name] [old-image-name]=[new-image-name] 為部署設置鏡像
kubectl cordon [nodeid] 標記節點不接受調度
kubectl uncordon [nodeid] 恢復節點可以接受調度
kubectl drain [nodeid] 驅趕該節點上運行的所有容器到其他可用節點
這里把Kubectl常用子命令大概分為以下幾類：
語法
$ kubectl [command] [TYPE] [NAME] [flags]
command：子命令
TYPE：資源類型
NAME：資源名稱
flags：命令參數
命令幫助
kubectl命令的幫助很詳細， kubectl -h 會列出所有的子命令，在任何子命令后跟 -h，都會輸出詳細的幫助以及用例，遇到問題可以隨時查看幫助。
資源對象
kubectl大部分子命令后都可以指定要操作的資源對象，可以用 kubectl api-resources 命令參考
全局參數
kubectl options 命令可以列出可以全局使用的命令參數，比較重要的有：
--cluster='': 指定命令操作對象的集群
--context='': 指定命令操作對象的上下文
-n, --namespace='': 指定命令操作對象的Namespace
資源字段
kubectl explain 命令可以輸出資源對應的屬性字段及定義,在定義資源配置文件時候非常有用。
# Usage:
kubectl explain RESOURCE [options]
# Examples:
$ kubectl explain deployment.spec.selector
KIND: Deployment
VERSION: extensions/v1beta1
RESOURCE: selector <Object>
DESCRIPTION:
Label selector for pods. Existing ReplicaSets whose pods are selected by
this will be the ones affected by this deployment.
A label selector is a label query over a set of resources. The result of
matchLabels and matchExpressions are ANDed. An empty label selector matches
all objects. A null label selector matches no objects.
FIELDS:
matchExpressions <[]Object>
matchExpressions is a list of label selector requirements. The requirements
are ANDed.
matchLabels <map[string]string>
matchLabels is a map of {key,value} pairs. A single {key,value} in the
matchLabels map is equivalent to an element of matchExpressions, whose key
field is "key", the operator is "In", and the values array contains only
"value". The requirements are ANDed.
聲明式資源對象管理
對集群資源的聲明式管理，是Kubernetes最主要的特性之一，而kubectl apply命令是最能體現這個特性的命令。apply命令最主要的參數有兩個:
# Usage:
kubectl apply (-f FILENAME | -k DIRECTORY) [options]
-f 參數后跟yaml或 json 格式的資源配置文件，-k 參數后跟kustomization.yaml配置文件的位置。
為什么說apply是聲明式管理呢，因為所有對集群的增改操作，都能用apply命令完成，一切取決於后面的配置文件：
如果配置文件中的資源找集群中不存在，則創建這個資源。
如果配置文件中的資源在集群中已存在，則根據配置對資源字段進行更新
舉個例子：
# 部署一個goweb應用，配置pod數為4個：
[root@master-1 ~]# grep replicas deployment-goweb.yaml
replicas: 4
# 使用 apply 創建資源
[root@master-1 ~]# kubectl apply -f deployment-goweb.yaml
deployment.apps/goweb created
[root@master-1 ~]# kubectl get po
NAME READY STATUS RESTARTS AGE
goweb-6b5d559869-4x5mb 1/1 Running 0 14s
goweb-6b5d559869-77lbz 1/1 Running 0 14s
goweb-6b5d559869-9ztkh 1/1 Running 0 14s
goweb-6b5d559869-ccjtp 1/1 Running 0 14s
# 修改pod數量為2個：
[root@master-1 ~]# sed -ri 's/4$/2/g' deployment-goweb.yaml
[root@master-1 ~]# grep replicas deployment-goweb.yaml
replicas: 2
# 使用apply更新資源
[root@master-1 ~]# kubectl apply -f deployment-goweb.yaml
deployment.apps/goweb configured
[root@master-1 ~]# kubectl get po
NAME READY STATUS RESTARTS AGE
goweb-6b5d559869-4x5mb 1/1 Running 0 8m21s
goweb-6b5d559869-77lbz 1/1 Running 0 8m21s
# pod數已更新為2個
可以看到，同一個 kubectl apply -f deployment-goweb.yaml 命令，可以用來創建資源也可以更新資源。
簡單來說，apply命令的作用就是一個：使集群的實際狀態朝用戶聲明的期望狀態變化，而用戶不用關心具體要進行怎樣的增刪改操作才能呢達到這個期望狀態，也即Kubernetes的聲明式資源管理。
命令式資源對象管理
命令式管理類就是直接通過命令執行增刪改的操作，除了刪除資源外，下面的命令能用apply代替，kubernetes也建議盡量使用apply命令。
創建資源
kubectl create deployment my-dep --image=busybox # 創建一個deplpyme
kubectl expose rc nginx --port=80 --target-port=8000 # 創建一個svc，暴露 nginx 這個rc
更新資源
kubectl scale --replicas=3 -f foo.yaml # 將foo.yaml中描述的對象擴展為3個
kubectl annotate pods foo description='my frontend' # 增加description='my frontend'備注,已有保留不覆蓋
kubectl label --overwrite pods foo status=unhealthy # 增加status=unhealthy 標簽，已有則覆蓋
刪除資源
kubectl delete -f xxx.yaml # 刪除一個配置文件對應的資源對象
kubectl delete pod,service baz foo # 刪除名字為baz或foo的pod和service
kubectl delete pods,services -l name=myLabel # -l 參數可以刪除包含指定label的資源對象
kubectl delete pod foo --grace-period=0 --force # 強制刪除一個pod，在各種原因pod一直terminate不掉的時候很有用
查看資源狀態
get
最常用的查看命令，顯示一個或多個資源的詳細信息
# Usage:
kubectl get
[(-o|--output=)](TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags]
[options]
# Examples:
kubectl get services # 列出當前NS中所有service資源
kubectl get pods --all-namespaces # 列出集群所有NS中所有的Pod
kubectl get pods -o wide # -o wide也比較常用，可以顯示更多資源信息，比如pod的IP等
kubectl get deployment my-dep # 可以直接指定資源名查看
kubectl get deployment my-dep --watch # --watch 參數可以監控資源的狀態，在狀態變換時輸出。在跟蹤服務部署情況時很有用
kubectl get pod my-pod -o yaml # 查看yaml格式的資源配置，這里包括資實際的status，可以用--export排除
kubectl get pod my-pod -l app=nginx # 查看所有帶有標簽app: nginx的pod
kubectl 可用JSONPATH來過濾字段，JSON Path的語法可參考 這里
kubectl get pods --selector=app=cassandra rc -o jsonpath='{.items[*].metadata.labels.version}' # 獲取所有具有 app=cassandra 的 pod 中的 version 標簽
describe
describe命令同樣用於查看資源信息，但相比與get只輸出資源本身的信息，describe聚合了相關資源的信息並輸出。比如，在describe node信息時，同時會輸出該node下的pod的資源利用情況。所以describe命令在排錯和調試時非常有用。
# Usage:
kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME) [options]
# Examples:
kubectl describe nodes my-node # 查看節點my-node的詳細信息
kubectl describe pods my-pod # 查看pod my-pod的詳細信息
容器管理 雖然邏輯上，Kubernetes的最小管理單位是Pod，但是實際上還是免不了與容器直接交互，特別是對於多容器的Pod，任意容器有問題，都會導致Pod不可用。
日志查看
# Usage:
kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER] [options]
# Examples:
kubectl logs my-pod
# 輸出一個單容器pod my-pod的日志到標准輸出
kubectl logs nginx-78f5d695bd-czm8z -c nginx
# 輸出多容器pod中的某個nginx容器的日志
kubectl logs -l app=nginx
# 輸出所有包含app-nginx標簽的pod日志
kubectl logs -f my-pod
# 加上-f參數跟蹤日志，類似tail -f
kubectl logs my-pod -p
# 輸出該pod的上一個退出的容器實例日志。在pod容器異常退出時很有用
kubectl logs my-pod --since-time=2018-11-01T15:00:00Z
# 指定時間戳輸出日志
kubectl logs my-pod --since=1h
# 指定時間段輸出日志，單位s/m/h
執行命令
命令作用和參數基本與docker exec一致
# Usage:
kubectl exec POD [-c CONTAINER] -- COMMAND [args...] [options]
# Examples:
kubectl exec my-pod ls # 對my-pod執行ls命令
kubectl exec -t -i nginx-78f5d695bd-czm8z bash # 進入pod的shell，並打開偽終端和標准輸入
文件傳輸
在排錯和測試服務的時候，時不時需要和容器互相交互文件，比如傳輸容器內存的dump到宿主機，或從宿主機臨時拷貝個新配置文件做調試，這時就可以用*kubectl cp命令。要注意的是，cp命令需要容器里已安裝有tar程序
# Usage:
kubectl cp <file-spec-src> <file-spec-dest> [options]
# Examples:
kubectl cp /tmp/foo_dir <some-pod>:/tmp/bar_dir # 拷貝宿主機本地文件夾到pod
kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar # 指定namespace的拷貝pod文件到宿主機本地目錄
kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container> # 對於多容器pod，用-c指定容器名
集群管理
除了和具體的資源打交道，在對集群進行維護時，也經常需要查看集群信息和對節點進行管理，集群管理有以下這些常用的命令：
集群信息查看
kubectl cluster-info # 查看master和集群服務的地址
kubectl cluster-info dump # 查看集群詳細日志
kubectl version # 查看Kubernetes集群和客戶端版本
節點管理
在集群節點出問題時，可能希望把一個節點不再被調度pod，或把節點目前的pod都驅逐出去
kubectl cordon my-node
# 標記 my-node 為 unschedulable,禁止pod被調度過來。注意這時現有的pod還會繼續運行，不會被驅逐。
kubectl uncordon my-node
# 與cordon相反，標記 my-node 為 允許調度。
kubectl drain my-node
# drain字面意思為排水，實際就是把my-node的pod平滑切換到其他node，同時標記pod為unschedulable，也就是包含了cordon命令。
# 但是直接使用命令一般不會成功，建議在要維護節點時，加上以下參數：
kubectl drain my-node --ignore-daemonsets --force --delete-local-data
# --ignore-daemonsets 忽略daemonset部署的pod
# --force 直接刪除不由workload對象（Deployment、Job等）管理的pod
# --delete-local-data 直接刪除掛載有本地目錄(empty-dir方式）的pod
