taint

1. kubectl taint nodes node1 foo=bar:NoSchedule -- 某個節點被加上了一個 Taint，即被“打上了汙點”，那麼所有 Pod 就都不能在這個節點上執行，除非，有個別的 Pod 宣告自己能“容忍”這個“汙點”，即宣告瞭 Toleration，它才可以在這個節點上執行。該 node1 節點上就會增加一個鍵值對格式的 Taint，即：foo=bar:NoSchedule。其中值裡面的 NoSchedule，意味著這個 Taint 只會在排程新 Pod 時產生作用，而不會影響已經在 node1 上執行的 Pod，哪怕它們沒有 Toleration。
2. kubectl taint nodes --all node-role.kubernetes.io/master- -- 刪除這個 Taint,在“node-role.kubernetes.io/master”這個鍵後面加上了一個短橫線“-”，這個格式就意味著移除所有以“node-role.kubernetes.io/master”為鍵的 Taint

apiVersion: v1
kind: Pod
...
spec:
  tolerations:
  - key: "foo"
    operator: "Exists"
    effect: "NoSchedule"
複製程式碼

exec

1. kubectl exec -it test-projected-volume -- /bin/sh -- 進入容器

node

1. kubectl get nodes -- 檢視節點狀態
2. kubectl describe node master -- 檢視這個節點（Node）物件的詳細資訊、狀態和事件（Event）

pod

1. kubectl create -f xxx.yaml -- 建立pod
2. kubectl replace -f xxx.yaml -- 修改pod
3. kubectl apply -f xxx.yaml -- 應用修改或建立
4. kubectl get pods -l app=nginx
   -- 加上了一個 -l 引數，即獲取所有匹配 app: nginx 標籤的 Pod
5. kubectl exec -it nginx-deployment-5c678cfb6d-lg9lw -- /bin/bash -- 進入pod
6. kubectl delete -f nginx-deployment.yaml --刪除
7. kubectl attach -it nginx -c shell -- 連線進容器
8. kubectl get pod testpodname -o yaml -- 這樣的引數，會將指定的 Pod API 物件以 YAML 的方式展示出來。
9. kubectl get pods -w -l app=nginx-- -w 引數，即：Watch 功能，實時檢視建立例項的過程

• 生命週期
  1. Pending。這個狀態意味著，Pod 的 YAML 檔案已經提交給了 Kubernetes，API 物件已經被建立並儲存在 Etcd 當中。但是，這個 Pod 裡有些容器因為某種原因而不能被順利建立。比如，排程不成功。
  2. Running。這個狀態下，Pod 已經排程成功，跟一個具體的節點繫結。它包含的容器都已經建立成功，並且至少有一個正在執行中。
  3. Succeeded。這個狀態意味著，Pod 裡的所有容器都正常執行完畢，並且已經退出了。這種情況在執行一次性任務時最為常見。
  4. Failed。這個狀態下，Pod 裡至少有一個容器以不正常的狀態（非 0 的返回碼）退出。這個狀態的出現，意味著你得想辦法 Debug 這個容器的應用，比如檢視 Pod 的 Events 和日誌。
  5. Unknown。這是一個異常狀態，意味著 Pod 的狀態不能持續地被 kubelet 彙報給 kube-apiserver，這很有可能是主從節點（Master 和 Kubelet）間的通訊出現了問題。

secrets

1. kubectl get secrets -- 獲取到secrets

scale -- 水平擴充套件與收縮

1. kubectl scale deployment nginx-deployment --replicas=4 -- 將nginx-deployment的 ReplicaSet 的個數改為4
2. kubectl rollout status deployment/nginx-deployment -- 實時檢視 Deployment 物件的狀態變化

edit -- 滾動更新

1. kubectl edit deployment/nginx-deployment -- kubectl edit 指令，會幫你直接開啟 nginx-deployment 的 API 物件。然後，你就可以修改這裡的 Pod 模板
2. 修改了 Deployment 裡的 Pod 定義之後，Deployment Controller 會使用這個修改後的 Pod 模板，建立一個新的 ReplicaSet，這個新的 ReplicSet 的初始 Pod 副本數是：0。
3. kubectl set image deployment/nginx-deployment nginx=nginx:1.91 -- 滾動升級映象
4. kubectl rollout undo deployment/nginx-deployment -- 因為映象不存在等原因，“滾動更新”被觸發後，會立刻報錯並停止。這時候使用 roollout undo及能把整個 Deployment 回滾到上一個版本
5. kubectl rollout history deployment/nginx-deployment 檢視每次 Deployment 變更對應的版本
6. kubectl rollout undo deployment/nginx-deployment --to-revision=2 在 kubectl rollout undo 命令列最後，加上要回滾到的指定版本的版本號,回滾到指定版本。
7. kubectl rollout pause deployment/nginx-deployment -- 讓這個 Deployment 進入了一個“暫停”狀態,接下來，你就可以隨意使用 kubectl edit 或者 kubectl set image 指令，修改這個 Deployment 的內容,我們對 Deployment 的所有修改，都不會觸發新的“滾動更新”，也不會建立新的 ReplicaSet。
8. kubectl rollout resume deploy/nginx-deployment -- 對 Deployment 修改操作都完成之後，只需要再執行一條 kubectl rollout resume 指令，就可以把這個 Deployment“恢復”回來，在 kubectl rollout pause 指令之後的這段時間裡，我們對 Deployment 進行的所有修改，最後只會觸發一次“滾動更新”。

• 每執行一次擴充套件升級操作都會產生一個RS，即使我們用pause和resume控制了 ReplicaSet 的生成數量，隨著應用版本的不斷增加，Kubernetes 中還是會為同一個 Deployment 儲存很多不同的 ReplicaSet。那麼，我們又該如何控制這些“歷史”ReplicaSet 的數量呢？很簡單，Deployment 物件有一個欄位，叫作 spec.revisionHistoryLimit，就是 Kubernetes 為 Deployment 保留的“歷史版本”個數。所以，如果把它設定為 0，你就再也不能做回滾操作了。