⑴ K8S安裝和創建集群終極教程（單master多worker）
本文會以 最簡單 、 最直接 、 最完整 的方式記錄kubernetes（下面統稱K8S）單master多工作節點（worker nodes）的集群步驟
首先要簡單了解一下本文的3個核心概念：
內存建議至少4G
問：如何查看主機名？
答：執行命令hostname
問：如何修改主機名？
答：永久生效的做法：執行命令vi /etc/hostname，把第一行去掉（不能注釋掉，要去掉），然後重新寫上自定義的主機名（注意命名規范），保存並重啟後生效；
臨時生效的做法：執行以下命令
問：如何查看MAC地址？
答：執行命令ip link，然後看你的第一網卡
問：如何查看proct_uuid？
答：執行命令sudo cat /sys/class/dmi/id/proct_uuid
注意：30000-32767這個埠范圍是我們創建服務的埠必須要設置的一個范圍（如果設置范圍以外的會有限制提示並創建失敗），這是K8S規定的。
另外，如果你要直接關閉防火牆可以執行
⑥必須禁用Swap
Swap total大於0，說明Swap分區是開啟的
問：如何關閉Swap？
答：編輯文件/etc/fstab，在swap行前面加上#號注釋， 保存並重啟伺服器
再次查看分區狀態，已生效
常見的容器引擎（Container runtime，簡稱runtime）：
本文使用的容器引擎是Docker
安裝完成後查看版本：
當出現可能跟Docker引擎相關的奇怪異常時可以嘗試把Docker卸載干凈並重新安裝，但一定要注意鏡像、容器、卷或配置文件這些是否需要備份。
下面記錄卸載Docker引擎的步驟：
①卸載 Docker Engine、CLI 和 Containerd 包：
②主機上的映像、容器、卷或自定義配置文件不會自動刪除。刪除所有鏡像、容器和卷：
③配置文件如果有不合法的字元時會導致啟動失敗，我們需要將其刪除然後重建
此時Docker引擎已卸載干凈
官網用的是谷歌的yum源，因為國內是連不上的，所以這里替換成阿里提供的yum源
①安裝
從安裝信息中可以看到版本號是1.22
Installing:
kubeadm x86_64 1.22.4-0 kubernetes 9.3 M
kubectl x86_64 1.22.4-0 kubernetes 9.7 M
kubelet x86_64 1.22.4-0 kubernetes 20 M
②啟動
這就是一個驅動程序，注意cgroup和cgroupfs不要混淆了
引用官方的一段話
「由於 kubeadm 把 kubelet 視為一個系統服務來管理，所以對基於 kubeadm 的安裝， 我們推薦使用 systemd 驅動，不推薦 cgroupfs 驅動。」
kubeadm默認是使用systemd 驅動，而我們的Docker默認驅動是cgroupfs（docker info可以查看），所以需要將Docker的驅動改成systemd
①編輯Docker配置文件
②重啟Docker服務
再次docker info查看驅動信息已變成了systemd
工作節點（worker nodes）的最小配置就到這里了
①鏡像源參數說明
默認情況下, kubeadm 會從 k8s.gcr.io 倉庫拉取鏡像，國內是拉不了的。官方文檔明確表示允許你使用其他的 imageRepository 來代替 k8s.gcr.io。
--image-repository 你的鏡像倉庫地址
接下來我找了一些國內的鏡像源，並簡單做了下分析
綜合上述統計，我選擇阿里雲的鏡像源
②ip地址范圍參數說明
--pod-network-cidr =192.168.0.0/16
注意:如果192.168.0.0/16已經在您的網路中使用，您必須選擇一個不同的pod網路CIDR，在上面的命令中替換192.168.0.0/16。
集群初始化命令：
因為我用的是演示機器，所以這里把完整的執行信息都貼出來方便查閱，平時工作中一定要注意保護好敏感的信息（我的ip地址范圍是自定義的便於下面的功能演示，另外初次init需要下載鏡像文件，一般需要等幾分鍾）
如上所示，集群初始化成功，此時一定要注意看上面執行結果最後的那部分操作提示，我已用標明了初始化成功後還需要執行的3個步驟
注意：如果init成功後發現參數需要調整，可以執行kubeadm reset，它的作用是盡最大努力恢復kubeadm init 或者 kubeadm join所做的更改。
To start using your cluster, you need to run the following as a regular user:
翻譯：開始使用集群前，如果你是普通用戶（非root），你需要執行以下的命令：
Alternatively, if you are the root user, you can run:
翻譯：或者，如果你使用的是root，你可以執行以下命令：
（注意：export只是臨時生效，意味著每次登錄你都需要執行一次）
網路配置配的就是Pod的網路，我的網路插件選用calico
cidr就是ip地址范圍，如果您使用 pod CIDR 192.168.0.0/16，請跳到下一步。
但本文中使用的pod CIDR是192.100.0.0/16，所以我需要取消對清單中的 CALICO_IPV4POOL_CIDR 變數的注釋，並將其設置為與我選擇的 pod CIDR 相同的值。（注意一定要注意好格式，注意對齊）
可根據需求自定義清單，一般不需要的就直接跳過這步
在所有的工作節點上執行join命令（復制之前初始化成功後返回的加入集群命令到所有的工作節點執行即可）
master上查看所有節點的狀態
到這里集群已經創建完成
最後我再安裝K8S的可視化界面kubernetes-dashboard，方便我們日常使用
①下載yaml文件
②修改yaml文件，新增type和nodePort，使服務能夠被外部訪問
③安裝並查看運行情況
④新建用戶
文件創建完成後保存並apply
⑤獲取Token，用於界面登錄
⑥登錄dashboard
192.168.189.128是我的master伺服器ip，另外要注意必須使用https，並且不能使用ie內核模式
復制⑤生成的token到輸入框，點擊登錄
dashboard安裝配置完成
問：如何在查看資源情況？
答：在master上執行以下命令可查看資源情況（-o wide是顯示更詳細的信息），
①查看所有節點
②查看所有命名空間
③查看命名空間下的pod
④查看所有命名空間的pod
⑤實時查看查看命名空間下的pod運行情況
問：kubeadm join 出現異常[ERROR Port-10250]: Port 10250 is in use，如何解決？
答：這是因為你之前join失敗過了，需要先執行kubeadm reset再重新join
問：虛擬機上測試時網卡突然消失如何解決（題外問題記錄）？
答：
①確認丟失的網卡信息，ens開頭（可選步驟）
ifconfig -a
②執行以下命令解決
問：如何查看K8S版本？
答：kubectl version
問：join命令忘記或者過期了怎麼辦？
答：
生成永不過期的
生成時效24小時的
問：Pod不斷重啟並且無其它報錯信息時怎麼辦？
答：這種情況通常是因為你的集群中只有master，沒有worker節點，master的創建默認是有污點的，即不允許調度新的Pod，如果你需要（當然這並不推薦），就需要刪除 master 上的污點。刪除污點可以執行以下命令，
它應該返回以下內容。
⑵ Descheler 實現 K8S Pod 二次調度
Kubernetes中的調度是將待處理的pod綁定到節點的過程，由Kubernetes的一個名為 kube-scheler 的組件執行。調度程序的決定，無論是否可以或不能調度容器，都由其可配置策略指導，該策略包括一組規則，稱為 謂詞 和 優先順序 。調度程序的決定受到其在第一次調度時出現新pod時的Kubernetes集群視圖的影響。由於Kubernetes集群非常動態且狀態隨時間而變化，因此可能需要將已經運行的pod重新調試到其它節點上，已達到節點使用資源平衡。
kube-scheler 是 Kubernetes 集群的默認調度器，並且是集群 控制面 的一部分。
對每一個新創建的 Pod 或者是未被調度的 Pod，kube-scheler 會選擇一個最優的 Node 去運行這個 Pod。然而，Pod 內的每一個容器對資源都有不同的需求，而且 Pod 本身也有不同的資源需求。因此，Pod 在被調度到 Node 上之前，根據這些特定的資源調度需求，需要對集群中的 Node 進行一次過濾。
在一個集群中，滿足一個 Pod 調度請求的所有 Node 稱之為 可調度節點 。如果沒有任何一個 Node 能滿足 Pod 的資源請求，那麼這個 Pod 將一直停留在未調度狀態直到調度器能夠找到合適的 Node。
調度器先在集群中找到一個 Pod 的所有可調度節點，然後根據一系列函數對這些可調度節點打分，然後選出其中得分最高的 Node 來運行 Pod。之後，調度器將這個調度決定通知給 kube-apiserver，這個過程叫做 綁定 。
在做調度決定時需要考慮的因素包括：單獨和整體的資源請求、硬體/軟體/策略限制、親和以及反親和要求、數據局域性、負載間的干擾等等。
kube-scheler 給一個 pod 做調度選擇包含兩個步驟：
因此，可能會在群集中不太理想的節點上安排多個pod。 Descheler 根據其政策，發現可以移動並移除它們的pod。請注意，在當前的實現中，Descheler 不會安排更換被驅逐的pod，而是依賴於默認的調度程序。
這就是本文想講的 Descheler 項目，根據該項目二次調度策略來解決上面所說的問題。具體策略說明如下：
該策略確保只有一個Pod與在同一節點上運行的副本集（RS），Replication Controller（RC），Deployment或Job相關聯。如果還有更多，則將這些重復的容器逐出，以更好地在群集中擴展容器。如果某些節點由於任何原因而崩潰，並且它們上的Pod移至其他節點，導致多個與RS或RC關聯的Pod（例如在同一節點上運行），則可能發生此問題。一旦出現故障的節點再次准備就緒，便可以啟用此策略以驅逐這些重復的Pod。當前，沒有與該策略關聯的參數。要禁用此策略，策略應如下所示：
該策略發現未充分利用的節點，並且如果可能的話，從其他節點驅逐pod，希望在這些未充分利用的節點上安排被驅逐的pod的重新創建。此策略的參數配置在 。
節點的利用率低是由可配置的閾值決定的 thresholds 。 thresholds 可以按百分比為cpu，內存和pod數量配置閾值 。如果節點的使用率低於所有（cpu，內存和pod數）的閾值，則該節點被視為未充分利用。目前，pods的請求資源需求被考慮用於計算節點資源利用率。
還有另一個可配置的閾值， targetThresholds 用於計算可以驅逐pod的潛在節點。任何節點，所述閾值之間， thresholds 並且 targetThresholds 被視為適當地利用，並且不考慮驅逐。閾值 targetThresholds 也可以按百分比配置為cpu，內存和pod數量。
這些閾值 thresholds 和 targetThresholds 可以根據您的集群要求進行調整。這是此策略的策略示例：
與該 LowNodeUtilization 策略相關的另一個參數稱為 numberOfNodes 。僅當未充分利用的節點數大於配置的值時，才可以配置此參數以激活策略。這在大型群集中很有用，其中一些節點可能會頻繁使用或短期使用不足。默認情況下， numberOfNodes 設置為0。
該策略可確保從節點中刪除違反Interpod反親和關系的pod。例如，如果某個節點上有 podA ，並且 podB 和 podC （在同一節點上運行）具有禁止它們在同一節點上運行的反親和規則，則 podA 將被從該節點逐出，以便 podB 和 podC 正常運行。當 podB 和 podC 已經運行在節點上後，反親和性規則被創建就會發送這樣的問題。目前，沒有與該策略關聯的參數。要禁用此策略，策略應如下所示：
此策略可確保從節點中刪除違反節點關聯的pod。例如，在nodeA上調度了podA，它在調度時滿足節點關聯性規則 ，但隨著時間的推移，nodeA不再滿足該規則，那麼如果另一個節點nodeB可用，它滿足節點關聯性規則，那麼podA將被逐出nodeA。策略文件如下所示：
該策略可以確保從節點中刪除違反 NoSchele 污點的 Pod 。例如，有一個名為 podA 的 Pod ，通過配置容忍 key=value:NoSchele 允許被調度到有該污點配置的節點上，如果節點的污點隨後被更新或者刪除了，則污點將不再被 Pod 的容忍滿足，然後將被驅逐，策略文件如下所示：
當 Descheler 程序決定從節點驅逐 Pod 時，它採用以下常規機制：
Descheler 可以在k8s集群中作為 Job 或 CronJob 運行。它的優點是可以多次運行而無需用戶干預。該調度程序容器在 kube-system 命名空間中作為關鍵容器運行，以避免被自身或kubelet逐出。
例如：
⑶ k8s 基本使用（上）
本文將介紹 k8s 中的一些最基本的命令，並輔以解釋一些基本概念來方便理解，也就是說，本文是一篇偏向實用性而非學術性的文章，如果你想提前了解一下 k8s 相關的知識的話，可以通過以下鏈接進行學習：
k8s 是經典的一對多模型，有一個主要的管理節點 master 和許多的工作節點 slaver 。當然，k8s 也可以配置多個管理節點，擁有兩個以上的管理節點被稱為 高可用 。k8s 包括了許多的組件，每個組件都是單運行在一個 docker 容器中，然後通過自己規劃的虛擬網路相互訪問。你可以通過 kubectl get pod -n kube-system 查看所有節點上的組件容器。
在管理節點中會比工作節點運行更多的 k8s 組件，我們就是靠著這些多出來的組件來對工作節點發號施令。他們都叫什麼這里就不詳細提了。反正對於」基本使用「來說，這些名字並不重要。
要想理解一個東西就要先明白它的內在理念。通俗點就是，k8s 做了什麼？為了提供更加可靠的服務，就要增加伺服器的數量，減少每個伺服器的體量來平攤負載，而越來越多的虛擬機就會帶來越來越高的運維成本。如何讓少量的運維人員就可以管理數量眾多的伺服器及其上的服務呢？這就是 k8s 做的工作。
k8s 把數量眾多的伺服器重新抽象為一個統一的資源池 ，對於運維人員來說，他們面前沒有伺服器1、伺服器2的概念，而是一個統一的資源池，增加新的伺服器對運維人員來說，只是增加自資源池的可用量。不僅如此，k8s 把所有能用的東西都抽象成了資源的概念，從而提供了一套更統一，更簡潔的管理方式。
接下來，我會把每個基本命令當做一節來進行介紹，並輔以介紹一些基本概念。本文介紹的命令涵蓋了增刪改查四方面，可參加下面表格，因為篇幅較長，我們將 create 及之後的不那麼常用的命令放在下一篇文章 k8s 基本使用（下） 里講：
接下來進入正題，首先來了解一下 k8s 中最最最常用的命令 kubectl get ，要記住，k8s 把所有的東西都抽象成了資源，而 kubectl get 就是用來查看這些資源的。最常見的資源就是 pod 。
不僅我們自己的服務是要包裝成 pod 的，就連 k8s 自己也是運行在一堆 pod 上。接下來就讓我們查看一下 k8s 的 pod ：
-n 參數指定了要查看哪個命名空間下的 pod 。 k8s 所有的 pod 都被放置在 kube-system 命名空間下。
執行了 kubectl get pod -n kube-system 命令後，你就可以看到如下內容：
其中每一行就是一個資源，這里我們看到的資源是 pod 。你看到的 pod 數量可能和我的不一致，因為這個列表裡包含了 k8s 在所有節點上運行的 pod ，你加入的節點越多，那麼顯示的 pod 也就越多。我們來一列一列的看：
kubectl get 可以列出 k8s 中所有資源
這里只介紹了如何用 kubectl 獲取 pod 的列表。但是不要把 get 和 pod 綁定在一起，pod 只是 k8s 中的一種服務，你不僅可以 get pod ，還可以 get svc ( 查看服務 )、 get rs ( 查看副本控制器 )、 get deploy ( 查看部署 )等等等等，雖然說 kubectl get pod 是最常用的一個，但是如果想查看某個資源而又不知道命令是什麼， kbuectl get <資源名> 就對了。
如果你想看更多的信息，就可以指定 -o wide 參數，如下：
加上這個參數之後就可以看到資源的所在 ip 和所在節點 node 了。
記得加上 -n
-n 可以說是 kubectl get 命令使用最頻繁的參數了，在正式使用中，我們永遠不會把資源發布在默認命名空間。所以，永遠不要忘記在 get 命令後面加上 -n 。
kubectl get 命令可以列出 k8s 中的資源，而 kubectl get pod 是非常常用的查看 pod 的命令。而 -n 參數則可以指定 pod 所在的命名空間。
kubectl describe 命令可以用來查看某一資源的具體信息，他同樣可以查看所有資源的詳情， 不過最常用的還是查看 pod 的詳情 。他也同樣可以使用 -n 參數指定資源所在的命名空間。
舉個例子，我們可以用下面命令來查看剛才 pod 列表中的某個 pod，注意不要忘記把 pod 名稱修改成自己的：
然後你就可以看到很多的信息，咱們分開說，首先是基本屬性，你可以在詳細信息的開頭找到它：
基本屬性
其中幾個比較常用的，例如 Node 、 labels 和 Controlled By 。通過 Node 你可以快速定位到 pod 所處的機器，從而檢查該機器是否出現問題或宕機等。通過 labels 你可以檢索到該 pod 的大致用途及定位。而通過 Controlled By ，你可以知道該 pod 是由那種 k8s 資源創建的，然後就可以使用 kubectl get <資源名> 來繼續查找問題。例如上文 DaemonSet/kube-flannel-ds-amd64 ，就可以通過 kubectl get DaemonSet -n kube-system 來獲取上一節資源的信息。
內部鏡像信息
在中間部分你可以找到像下面一樣的 Containers 段落。該段落詳細的描述了 pod 中每個 docker 容器的信息，常用的比如 Image 欄位，當 pod 出現 ImagePullBackOff 錯誤的時候就可以查看該欄位確認拉取的什麼鏡像。其他的欄位名都很通俗，直接翻譯即可。
事件
在 describe 查看詳情的時候，最常用的信息獲取處就是這個 Event 段落了，你可以在介紹內容的末尾找到它，如下：
是的，如果你看到上面這樣，沒有任何 Events 的話，就說明該 pod 一切正常。當 pod 的狀態不是 Running 時，這里一定會有或多或少的問題，長得像下面一樣，然後你就可以通過其中的信息分析 pod 出現問題的詳細原因了：
kubectl describe <資源名> <實例名> 可以查看一個資源的詳細信息，最常用的還是比如 kubectl describe pod <pod名> -n <命名空間> 來獲取一個 pod 的基本信息。如果出現問題的話，可以在獲取到的信息的末尾看到 Event 段落，其中記錄著導致 pod 故障的原因。
如果你想查看一個 pod 的具體日誌，就可以通過 kubectl logs <pod名> 來查看。注意，這個只能查看 pod 的日誌。通過添加 -f 參數可以持續查看日誌。例如，查看 kube-system 命名空間中某個 flannel pod 的日誌，注意修改 pod 名稱：
然後就可以看到如下輸出：
如果你發現某個 pod 的服務有問題，但是狀態還是顯示 Running ，就可以使用 kubectl logs 來查看其詳細日誌。
在本篇文章里，我們了解了 k8s 的宗旨和一些基本概念，並知道了最為常用的 get 、 descibe 及 logs 命令，知道了這三條命令之後就幾乎可以從 k8s 中獲取所有常用信息了。接下來的 k8s 基本使用（下） 里，我們會更深一步，來了解 k8s 中如何創建、修改及刪除資源。
⑷ K8S-[二]Deployment控制器
工作負載控制器（Workload Controllers）是K8s的一個抽象概念，用於更高級層次對象，部署和管理Pod。
常用工作負載控制器：
• Deployment ： 無狀態應用部署
• StatefulSet ： 有狀態應用部署
• DaemonSet ： 確保所有Node運行同一個Pod
• Job ： 一次性任務
• Cronjob ： 定時任務
控制器的作用：
• 管理Pod對象
• 使用標簽與Pod關聯
• 控制器實現了Pod的運維，例如滾動更新、伸縮、副本管理、維護Pod狀態等。
• 管理Pod和ReplicaSet（副本數量設定）
• 具有上線部署、副本設定、滾動升級、回滾等功能
• 提供聲明式更新，例如只更新一個新的Image
應用場景：網站、API、微服務
第一次寫deploy的yaml可以用命令導出的方式獲取模板，在進行刪減。
最終版deployment的yaml：
deploy就是管理Pod的，所以關於對Pod管理的配置都可以放在這個配置文件，如資源配額（resource），污點容忍（tolrations），健康檢查（linvenessProbe）等
部署：
查看：
暴露到外部訪問：
輸入 http://NodeIP:32149 訪問
應用的升級其實就是換個鏡像，更新鏡像的三種方式
• kubectl apply -f xxx.yaml
• kubectl set image deployment/web nginx=nginx:1.16 （這個好處是這樣回滾的時候可看到版本記錄）
• kubectl edit deployment/web
滾動升級：K8s對Pod升級的默認策略，通過使用新版本Pod逐步更新舊版本Pod，實現零停機發布，用戶無感知。
原理： 對Pod的升級，是先啟動一個新的pod ，並啟動。如果配了健康檢查會在健康檢查後完全沒問題，出現running狀態，才刪掉一個舊pod。在啟動一個新的，在刪掉一個舊的。反復下去，這一切也都是deployment控制的。滾動升級在k8s中，也是由1個deployment 和 2個 replicaset 實現的。2個replicaset分別控制 增加新啟動Pod副本數量；減少原pod的副本數量。 加一減一的原則。達到用戶無感知。
集群內部訪問一下service的集群IP，看下nginx此時版本是1.15
編輯delpoy.yaml，修改鏡像版本為1.18
圖中可看到，k8s先啟動了2個新pod， 在新pod成功運行後，再刪除一個舊的。直到最後成功更新2個Pod。
• maxSurge：滾動更新過程中最大Pod副本數，確保在更新時啟動的Pod數量比期望（replicas）Pod數量最大多出25%
• maxUnavailable：滾動更新過程中最大不可用Pod副本數，確保在更新時最大25% Pod數量不可用，即確保75% Pod數量是可用狀態。
deployment中replicas參數控制Pod副本數量
ReplicaSet控制器用途：
• Pod副本數量管理，不斷對比當前Pod數量與期望Pod數量，一直循環這個過程。
• Deployment每次發布都會創建一個RS作為記錄，用於實現回滾
所以剛才實現擴容都是ReplicaSet控制器做的。
可以查看ReplicaSet（RS）的信息
項目的下線很簡單。刪除對應的deploy控制器，svc 即可。
如果是用deploy創建的pod，那麼直接刪除Pod 是不起作用的，還會被拉起來，反復循環。這都是因為上面說的deployment控制器中的replicaset 一直在循環一個動作 ： 對比當前pod數量是否和期望的一樣，不一樣就拉起。所以不能直接刪除pod。
CronJob用於實現定時任務，像Linux的Crontab一樣。
• 定時任務
應用場景：通知，備份
cronjob.yaml
每過一分鍾會啟動這個pod，執行定義的命令
⑸ 關閉k8s集群正確順序
先增刪後改查。
關閉集群順序先打開增加的入口，再檢查入口進程，點擊關閉，最後退出控制節點。
k8s集群管理和控制節點，主要通過4個組件實現集群資源調度，負載均衡，資源增刪改查操作的唯一入口。
Server用來接收和處理其他組件發來的請求，是集群控制的入口進程。
k8s里所有資源的增刪改查，操作請求的唯一接收和處理。
⑹ K8s污點容忍度橫向主節點
污點是K8s高級調度的特性，用於限制哪些Pod可以被調度到某一個節點。在普通節點橫向時我們可以使用污點容忍度創建惡意pod來對主節點進行橫向控制。
kube-scheler 是 Kubernetes 集群的默認調度器，並且是集群控制面(master)的一部分。對每一個新創建的Pod或者是未被調度的Pod， kube-scheler 會選擇一個最優的Node去運行這個Pod。
然而， Pod 內的每一個容器對資源都有不同的需求，而且Pod本身也有不同的資源需求。因此，Pod在被調度到Node上之前，根據這些特定的資源調度需求，需要對集群中的Node進行一次過濾。
當創建pod時候，會首先把創建的命令請求提交給apiserver，通過一系列認證授權,apiserver把pod數據存儲到etcd,創建deployment資源並初始化。然後再是scheler通過進行list-watch機制進行監測，經過 調度演算法 把pod調度到某個node節點上，最後信息更新到etcd，再後面就是kubelet接受信息到創建容器。
當前調度器選擇適當的節點時，調度程序會檢查每個節點是否有足夠的資源滿足 Pod 調度，比如查看CPU和內存限制是否滿足：
通過資源限制調度程序可確保由於過多 Pod 競爭消耗節點所有可用資源，從而導致節點資源耗盡引起其他系統異常。
在創建pod的時候，節點選擇器可以約束pod在特定節點上運行。
nodeSelector 也是節點選擇約束的最簡單推薦形式， nodeSelector 欄位添加到 Pod 的規約中設置希望目標節點所具有的 節點標簽 。 K8s 只會將 Pod 調度到擁有你所指定的每個標簽的節點上。
例子， 比如多個節點需要調度時候，通過給1，2節點打上標簽，創建pod時候使用節點選擇器，那麼pod會被按照節點選擇器希望的目標在相應節點調度。
為節點打上標簽：
kubectl label node nodename env_role=env
查看節點的標簽：
kubectl get nodes nodename --show-labels
節點親和性概念上類似於 nodeSelector ， 它使可以根據節點上的標簽來約束 Pod 可以調度到哪些節點上，這種方法比上面的 nodeSelector 更加靈活，它可以進行一些簡單的邏輯組合了，不只是簡單的相等匹配。
節點親和性和節點選擇器相比功能更強大，比如還是剛才的圖，如果我使用節點選擇器 env_role:dev1 的話是找不到相應的節點的，就沒有辦法調度，會一直是一個等待的狀態：
但我如果使用節點親和性，就算當前沒有這個節點，我還是可以根據調度調度策略進行調度，不只是簡單的相等匹配。
調度可以分成軟策略( 軟親和性 )和硬策略( 硬親和性 )兩種方式：
如圖可以看到軟親和性和硬親和性的欄位其實差不多，軟親和性多了一個 weight 欄位，表權重：
如上親和性還有一個欄位是 operator 表匹配的邏輯操作符，可以使用 descirbe 命令查看具體的調度情況是否滿足我們的要求， K8s 提供的操作符有下面的幾種：
如果 nodeSelectorTerms 下面有多個選項的話，滿足任何一個條件就可以了；如果 matchExpressions 有多個選項的話，則必須同時滿足這些條件才能正常調度 POD。
容忍度（ Toleration ）是應用於 Pod 上的，允許（但並不要求）Pod 調度到帶有與之匹配的污點的節點上。污點說白了就是不做普通的調度。
對於節點親和性無論是軟親和性和硬親和性，都是調度 POD 到預期節點上，而污點( Taints )恰好與之相反，如果一個節點標記為 Taints ， 除非 POD 也被標識為可以容忍污點節點，否則該 Taints 節點不會被調度pod 。
查看污點情況：
kubectl describe node nodename | grep Taint
可以看到，默認污點也只有master有。
污點里的值有三種：
NoSchele 就是字面意思，不會被調度， PreferNoSchele 說白了是盡量不被調度， NoExecute 是不會調度並且還會驅逐 node 已有的 pod 。
創建一個pod：
如果不加污點，可以看到這個pod會隨機調度到節點1或者節點2：
這時候把pod刪除了，重新創建pod並且給node加上污點：
給節點打污點：
kubectl taint node nodename key=value:NoSchele
重新創建pod並且deployment多個：
可以發現全部被調度在節點2上，節點1的污點 NoSchele 起了作用。
刪除污點：
容忍度 tolerations 是定義在 Pod 對象上的鍵值型屬性數據，用於配置其可容忍的節點污點，而且調度器僅能將 Pod 對象調度至其能夠容忍該節點污點的節點之上。
污點定義在節點的 node Spec 中，而容忍度則定義在 Pod 的 podSpec 中，它們都是鍵值型數據。
在 Pod 對象上定義容忍度時，它支持兩種操作符：一種是等值比較 Equal ,表示容忍度與污點必須在 key 、 value 和 effect 三者之上完全匹配；另一種是存在性判斷 Exists ，表示二者的 key 和 effect 必須完全匹配，而容忍度中的 value 欄位要使用空值。
這里的key和value對應的值都是你自己設置的key和value：
說白了就是：
而污點容忍的作用舉個例子，如果像上面污點一樣設置了 NoSchele 污點的節點，那麼創建pod的時候是必不被調度到的，但是如果我使用污點容忍，那這個節點可以在設置 NoSchele 污點的情況下可能又被調度，類似於親和性那種作用。
污點和污點容忍度的作用也就是獲取 主節點的shell ，因為像常見或者節點shell的流程是創建pod--》分配到正常node---》通過常規掛載目錄拿到節點的shell，而默認主節點是不被調度的，所以只有使用污點容忍度，創建一個能夠被調度到master節點的pod，然後通過掛載之類的手法來拿到主節點的shell。
通過創建一個具有 node-role.kubernetes.io/master:NoSchele 的容忍度讓Pod被Kubernetes Master所調度。
如上的Pod中將宿主機的根目錄掛載到容器中（volumes與volumeMounts）即可逃逸至Kubernetes Master中接管集群。
查看節點，當前是在普通節點：
多次創建可以發現在master節點上了：
可以通過掛載操作master節點母機shell:
⑺ Kubectl 常用命令大全
create 命令 ：根據文件或者輸入來創建資源
delete 命令 ：刪除資源
get 命令 ：獲得資源信息
run 命令 ：在集群中創建並運行一個或多個容器鏡像。
更詳細用法參見 ： http://docs.kubernetes.org.cn/468.html
expose 命令 ：創建一個service服務，並且暴露埠讓外部可以訪問
更多expose詳細用法參見 ： http://docs.kubernetes.org.cn/475.html
set 命令 ：配置應用的一些特定資源，也可以修改應用已有的資源
set 命令詳情參見 ： http://docs.kubernetes.org.cn/669.html
這個命令用於設置資源的一些范圍限制。
資源對象中的 Pod 可以指定計算資源需求（CPU-單位m、內存-單位Mi），即使用的最小資源請求（Requests），限制（Limits）的最大資源需求，Pod將保證使用在設置的資源數量范圍。
對於每個Pod資源，如果指定了 Limits （限制）值，並省略了 Requests （請求），則 Requests 默認為 Limits 的值。
可用資源對象包括(支持大小寫) ： replicationcontroller 、 deployment 、 daemonset 、 job 、 replicaset 。
例如 ：
設置資源的 selector （選擇器）。如果在調用"set selector"命令之前已經存在選擇器，則新創建的選擇器將覆蓋原來的選擇器。
selector 必須以字母或數字開頭，最多包含63個字元，可使用：字母、數字、連字元" - " 、點"."和下劃線" _ "。如果指定了--resource-version，則更新將使用此資源版本，否則將使用現有的資源版本。
注意 ：目前 selector 命令只能用於 Service 對象。
用於更新現有資源的容器鏡像。
可用資源對象包括： pod (po) 、 replicationcontroller (rc) 、 deployment (deploy) 、 daemonset (ds) 、 job 、 replicaset (rs) 。
explain 命令 ：用於顯示資源文檔信息
edit 命令 : 用於編輯資源信息
label命令 : 用於更新（增加、修改或刪除）資源上的 label（標簽）
例 ：
annotate命令 ：更新一個或多個資源的Annotations信息。也就是註解信息，可以方便的查看做了哪些操作。
例子 ：
completion命令 ：用於設置 kubectl 命令自動補全
BASH
ZSH
rollout 命令 : 用於對資源進行管理
可用資源包括： deployments ， daemonsets 。
子命令 ：
rolling-update命令 : 執行指定ReplicationController的滾動更新。
該命令創建了一個新的 RC ， 然後一次更新一個 pod 方式逐步使用新的 PodTemplate ，最終實現 Pod 滾動更新， new-controller.json 需要與之前 RC 在相同的 namespace 下。
scale命令 ：擴容或縮容 Deployment 、 ReplicaSet 、 Replication Controller 或 Job 中 Pod 數量
scale 也可以指定多個前提條件，如：當前副本數量或 --resource-version ，進行伸縮比例設置前，系統會先驗證前提條件是否成立。這個就是彈性伸縮策略。
autoscale命令 ：這個比 scale 更加強大，也是彈性伸縮策略 ，它是根據流量的多少來自動進行擴展或者縮容。
指定 Deployment 、 ReplicaSet 或 ReplicationController ，並創建已經定義好資源的自動伸縮器。使用自動伸縮器可以根據需要自動增加或減少系統中部署的pod數量。
certificate命令 ：用於證書資源管理，授權等
cluster-info 命令 ：顯示集群信息
top 命令 ：用於查看資源的cpu，內存磁碟等資源的使用率
cordon命令 ：用於標記某個節點不可調度
uncordon命令 ：用於標簽節點可以調度
drain命令 ： 用於在維護期間排除節點。
taint命令 ：用於給某個 Node 節點設置污點
describe命令 ：顯示特定資源的詳細信息
logs命令 ：用於在一個pod中列印一個容器的日誌，如果pod中只有一個容器，可以省略容器名
參數選項 ：
exec命令 ：進入容器進行交互，在容器中執行命令
命令選項 ：
attach命令 ：連接到一個正在運行的容器。
參數選項 ：
cp命令 ：拷貝文件或者目錄到pod容器中
用於 pod 和外部的文件交換,類似於 docker 的 cp ，就是將容器中的內容和外部的內容進行交換。
api-servions命令 ：列印受支持的 api 版本信息
help命令 ：用於查看命令幫助
config 命令 : 用於修改 kubeconfig 配置文件（用於訪問api，例如配置認證信息）
設置 kubectl 與哪個 Kubernetes 集群進行通信並修改配置信息。查看 使用 kubeconfig 跨集群授權訪問 文檔獲取詳情配置文件信息。
version 命令 ：列印客戶端和服務端版本信息
plugin 命令 ：運行一個命令行插件
apply命令 ：通過文件名或者標准輸入對資源應用配置
通過文件名或控制台輸入，對資源進行配置。 如果資源不存在，將會新建一個。可以使用 JSON 或者 YAML 格式。
參數選項 ：
patch命令 ：使用補丁修改，更新資源的欄位，也就是修改資源的部分內容
replace命令 ： 通過文件或者標准輸入替換原有資源
convert命令 ：不同的版本之間轉換配置文件
要以特定格式將詳細信息輸出到終端窗口，可以將 -o 或 --output 參數添加到支持的 kubectl 命令。
Kubectl 日誌輸出詳細程度是通過 -v 或者 --v 來控制的，參數後跟了一個數字表示日誌的級別。 Kubernetes 通用的日誌習慣和相關的日誌級別在 這里 有相應的描述。
以上是 kubectl 一些基本命令操作，需要時方便查閱。