K8S污點容忍度橫向主節點
污點 節點親和性 容忍度
污點是K8s高級調度的特性，用于限制哪些Pod可以被調度到某一個節點。在普通節點橫向時我們可以使用污點容忍度創建惡意pod來對主節點進行橫向控制。
kube-scheduler調度
kube-scheduler是Kubernetes集群的默認調度器，并且是集群控制面(master)的一部分。對每一個新創建的Pod或者是未被調度的Pod，kube-scheduler會選擇一個最優的Node去運行這個Pod。
然而，Pod內的每一個容器對資源都有不同的需求，而且Pod本身也有不同的資源需求。因此，Pod在被調度到Node上之前，根據這些特定的資源調度需求，需要對集群中的Node進行一次過濾。
如下為在創建pod的流程中，調度器的作用
當創建pod時候，會首先把創建的命令請求提交給apiserver，通過一系列認證授權,apiserver把pod數據存儲到etcd,創建deployment資源并初始化。
然后再是scheduler通過進行list-watch機制進行監測，經過調度算法把pod調度到某個node節點上，最后信息更新到etcd，再后面就是kubelet接受信息到創建容器。
哪些因素影響調度
1.pod資源限制
當前調度器選擇適當的節點時，調度程序會檢查每個節點是否有足夠的資源滿足 Pod 調度，比如查看CPU和內存限制是否滿足：
通過資源限制調度程序可確保由于過多 Pod 競爭消耗節點所有可用資源，從而導致節點資源耗盡引起其他系統異常。
2.節點選擇器nodeSelector
在創建pod的時候，節點選擇器可以約束pod在特定節點上運行。
nodeSelector也是節點選擇約束的最簡單推薦形式，nodeSelector字段添加到 Pod 的規約中設置希望目標節點所具有的節點標簽。K8s 只會將 Pod 調度到擁有你所指定的每個標簽的節點上。
例子， 比如多個節點需要調度時候，通過給1，2節點打上標簽，創建pod時候使用節點選擇器，那么pod會被按照節點選擇器希望的目標在相應節點調度。
為節點打上標簽：
kubectl label node nodename env_role=env
查看節點的標簽：
kubectl get nodes nodename --show-labels
3.節點親和性nodeAffinity
節點親和性概念上類似于nodeSelector， 它可以根據節點上的標簽來約束 Pod 可以調度到哪些節點上，這種方法比上面的nodeSelector更加靈活，它可以進行一些簡單的邏輯組合了，不只是簡單的相等匹配。
節點親和性和節點選擇器相比功能更強大，比如還是剛才的圖，如果我使用節點選擇器env_role:dev1的話是找不到相應的節點的，就沒有辦法調度，會一直是一個等待的狀態：
但我如果使用節點親和性，就算當前沒有這個節點，我還是可以根據調度調度策略進行調度，不只是簡單的相等匹配。
調度策略
調度可以分成軟策略(軟親和性)和硬策略(硬親和性)兩種方式：
- 軟親和性(preferredDuringSchedulingIgnoredDuringExecution)就是如果你沒有滿足調度要求的節點的話，POD 就會忽略這條規則，繼續完成調度過程，說白了就是滿足條件最好了，沒有的話也無所謂了的策略；
- 硬親和性(requiredDuringSchedulingIgnoredDuringExecution)表示當前的條件必須滿足，如果沒有滿足條件的節點的話，就不斷重試直到滿足條件為止，簡單說就是你必須滿足我的要求，不然我就不干的策略。
如圖可以看到軟親和性和硬親和性的字段其實差不多，軟親和性多了一個weight字段，表權重：
親和性操作符
如上親和性還有一個字段是operator表匹配的邏輯操作符，可以使用descirbe命令查看具體的調度情況是否滿足我們的要求，K8s提供的操作符有下面的幾種：
- In：label 的值在某個列表中
- NotIn：label 的值不在某個列表中
- Gt：label 的值大于某個值
- Lt：label 的值小于某個值
- Exists：某個 label 存在
- DoesNotExist：某個 label 不存在
如果nodeSelectorTerms下面有多個選項的話，滿足任何一個條件就可以了；如果matchExpressions有多個選項的話，則必須同時滿足這些條件才能正常調度 POD。
污點（Taints）與容忍（tolerations）
容忍度（Toleration）是應用于 Pod 上的，允許（但并不要求）Pod 調度到帶有與之匹配的污點的節點上。污點說白了就是不做普通的調度。
對于節點親和性無論是軟親和性和硬親和性，都是調度 POD 到預期節點上，而污點(Taints)恰好與之相反，如果一個節點標記為 Taints，除非 POD 也被標識為可以容忍污點節點，否則該 Taints 節點不會被調度pod。
污點（Taints）
查看污點情況：
kubectl describe node nodename | grep Taint
可以看到，默認污點也只有master有。
污點里的值有三種：
- NoSchedule：POD 不會被調度到標記為 taints 節點。
- PreferNoSchedule：NoSchedule 的軟策略版本。
- NoExecute：該選項意味著一旦 Taint 生效，如該節點內正在運行的 POD 沒有對應 Tolerate 設置，會直接被逐出。
NoSchedule就是字面意思，不會被調度，PreferNoSchedule說白了是盡量不被調度，NoExecute是不會調度并且還會驅逐node已有的pod。
創建一個pod：
如果不加污點，可以看到這個pod會隨機調度到節點1或者節點2：
這時候把pod刪除了，重新創建pod并且給node加上污點：
給節點打污點：
kubectl taint node nodename key=value:NoSchedule
重新創建pod并且deployment多個：
可以發現全部被調度在節點2上，節點1的污點NoSchedule起了作用。
刪除污點：
污點容忍度（tolerations）
容忍度tolerations是定義在Pod對象上的鍵值型屬性數據，用于配置其可容忍的節點污點，而且調度器僅能將Pod對象調度至其能夠容忍該節點污點的節點之上。
污點定義在節點的node Spec中，而容忍度則定義在Pod的podSpec中，它們都是鍵值型數據。
在Pod對象上定義容忍度時，它支持兩種操作符：一種是等值比較Equal,表示容忍度與污點必須在key、value和effect三者之上完全匹配；另一種是存在性判斷Exists，表示二者的key和effect必須完全匹配，而容忍度中的value字段要使用空值。
這里的key和value對應的值都是你自己設置的key和value：
說白了就是：
- 如果operator是Exists（此時容忍度不能指定 value）
- 如果operator是Equal，則它們的value應該相等
而污點容忍的作用舉個例子，如果像上面污點一樣設置了NoSchedule污點的節點，那么創建pod的時候是必不被調度到的，但是如果我使用污點容忍，那這個節點可以在設置NoSchedule污點的情況下可能又被調度，類似于親和性那種作用。
污點橫向滲透
污點和污點容忍度的作用也就是獲取主節點的shell，因為像常見或者節點shell的流程是創建pod--》分配到正常node---》通過常規掛載目錄拿到節點的shell，而默認主節點是不被調度的，所以只有使用污點容忍度，創建一個能夠被調度到master節點的pod，然后通過掛載之類的手法來拿到主節點的shell。
通過創建一個具有node-role.kubernetes.io/master:NoSchedule的容忍度讓Pod被Kubernetes Master所調度。
apiVersion: v1kind: Podmetadata: name: nginx labels: env: testspec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent tolerations: - key: "node-role.kubernetes.io/master" operator: "Exists" effect: "NoSchedule"
如上的Pod中將宿主機的根目錄掛載到容器中（volumes與volumeMounts）即可逃逸至Kubernetes Master中接管集群。
查看節點，當前是在普通節點：
多次創建可以發現在master節點上了：
可以通過掛載操作master節點母機shell:
