一 Controller Manager原理 1.1 Controller Manager概述 一般來說，智能系統和自動系統通常會通過一個“控制系統”來不斷修正系統的工作狀態。在Kubernetes集群中，每個Controller都是這樣的一個“控制系統”，它們通過API Server提供的（Lis ...
一 Controller Manager原理
1.1 Controller Manager概述
一般來說，智能系統和自動系統通常會通過一個“控制系統”來不斷修正系統的工作狀態。在Kubernetes集群中，每個Controller都是這樣的一個“控制系統”，它們通過API Server提供的（List-Watch）介面實時監控集群中特定資源的狀態變化，當發生各種故障導致某資源對象的狀態發生變化時，Controller會嘗試將其狀態調整為期望的狀態。 比如當某個Node意外宕機時，Node Controller會及時發現此故障並執行自動化修複流程，確保集群始終處於預期的工作狀態。Controller Manager是Kubernetes中各種Controller的管理者，是集群內部的管理控制中心，也是Kubernetes自動化功能的核心。 Controller Manager內部包含Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、ServiceAccount Controller、Token Controller、Service Controller及Endpoint Controller這8種Controller，每種Controller都負責一種特定資源的控制流程，而Controller Manager正是這些Controller的核心管理者。 提示：ServiceAccount Controller與Token Controller是與安全相關的兩個控制器，並且與ServiceAccount、Token密切相關。
提示：在Kubernetes集群中與Controller Manager協調的另一個組件是Kubernetes Scheduler，它的作用是將待調度的Pod（包括通過API Server新創建的Pod及RC為補足副本而創建的Pod等）通過一些複雜的調度流程計算出最佳目標節點，然後綁定到該節點上。
二 Replication Controller
2.1 Replication Controller（副本控制器）作用
Replication Controller的核心作用是確保在任何時候集群中某個RC關聯的Pod副本數量都保持預設值。如果發現Pod的副本數量超過預期值，則Replication Controller會銷毀一些Pod副本；反之，Replication Controller會自動創建新的Pod副本，直到符合條件的Pod副本數量達到預設值。 註意：只有當Pod的重啟策略是Always時（RestartPolicy=Always），Replication Controller才會管理該Pod的操作（例如創建、銷毀、重啟等）。 在通常情況下，Pod對象被成功創建後不會消失，唯一的例外是當Pod處於succeeded或failed狀態的時間過長（超時參數由系統設定）時，該Pod會被系統自動回收，管理該Pod的副本控制器將在其他工作節點上重新創建、運行該Pod副本。 RC中的Pod模板就像一個模具，模具製作出來的東西一旦離開模具，它們之間就再也沒關係了。同樣，一旦Pod被創建完畢，無論模板如何變化，甚至換成一個新的模板，也不會影響到已經創建的Pod了。 此外，Pod可以通過修改它的標簽來脫離RC的管控。該方法可以用於將Pod從集群中遷移、數據修複等調試。 對於被遷移走的Pod，RC會自動創建一個新的副本替換被遷移的副本。 註意：刪除一個RC不會影響它所創建的Pod。 如果想刪除一個被RC所控制的Pod，則需要將該RC的副本數（Replicas）屬性設置為0，這樣所有的Pod副本就都會被自動刪除。 提示：建議不要越過RC直接創建Pod，因為Replication Controller會通過RC管理Pod副本，實現自動創建、補足、替換、刪除Pod副本，這樣能提高系統的容災能力，減少由於節點崩潰等意外狀況造成的損失。即使應用程式只用到一個Pod副本，也強烈建議使用RC來定義Pod。 Replication Controller的作用總結如下：- 確保在當前集群中有且僅有N個Pod實例，N是在RC中定義的Pod副本數量。
- 通過調整RC的spec.replicas屬性值來實現系統擴容或者縮容。
- 通過改變RC中的Pod模板（主要是鏡像版本）來實現系統的滾動升級。
2.2 Replication Controller（副本控制器）場景
Replication Controller的典型使用場景通常有如下幾種：- 重新調度（Rescheduling）：不管想運行1個副本還是1000個副本，副本控制器都能確保指定數量的副本存在於集群中，即使發生節點故障或Pod副本被終止運行等意外狀況。
- 彈性伸縮（Scaling）：手動或者通過自動擴容代理修改副本控制器的spec.replicas屬性值，非常容易實現增加或減少副本的數量。
- 滾動更新（RollingUpdates）：副本控制器被設計成通過逐個替換Pod的方式來輔助服務的滾動更新。推薦的方式是創建一個只有一個副本的新RC，若新RC副本數量加1，則舊RC的副本數量減1，直到這個舊RC的副本數量為0，然後刪除該舊RC。通過上述模式，即使在滾動更新的過程中發生了不可預料的錯誤，Pod集合的更新也都在可控範圍內。在理想情況下，滾動更新控制器需要將準備就緒的應用考慮在內，並保證在集群中任何時刻都有足夠數量的可用Pod。
三 Node Controller
3.1 Node Controller作用
kubelet進程在啟動時通過API Server註冊自身的節點信息，並定時向API Server彙報狀態信息，API Server在接收到這些信息後，會將這些信息更新到etcd中。在etcd中存儲的節點信息包括節點健康狀況、節點資源、節點名稱、節點地址信息、操作系統版本、Docker版本、kubelet版本等。 節點健康狀況包含“就緒”（True）“未就緒”（False）和“未知”（Unknown）三種。3.2 Node Controller工作流程
Node Controller通過API Server實時獲取Node的相關信息，實現管理和監控集群中的各個Node的相關控制功能。
Node Controller的核心工作流程：
- ControllerM anager在啟動時如果設置了--cluster-cidr參數，那麼為每個沒有設置Spec.PodCIDR的Node都生成一個CIDR地址，並用該CIDR地址設置節點的Spec.PodCIDR屬性，這樣做的目的是防止不同節點的CIDR地址發生衝突。
- 逐個讀取Node信息，多次嘗試修改nodeStatusMap中的節點狀態信息，將該節點信息和Node Controller的nodeStatusMap中保存的節點信息做比較。如果判斷出沒有收到kubelet發送的節點信息、第1次收到節點kubelet發送的節點信息，或在該處理過程中節點狀態變成非“健康”狀態，則在nodeStatusMap中保存該節點的狀態信息，並用Node Controller所在節點的系統時間作為探測時間和節點狀態變化時間。如果判斷出在指定時間內收到新的節點信息，且節點狀態發生變化，則在nodeStatusMap中保存該節點的狀態信息，並用Node Controller所在節點的系統時間作為探測時間和節點狀態變化時間。如果判斷出在指定時間內收到新的節點信息，但節點狀態沒發生變化，則在nodeStatusMap中保存該節點的狀態信息，並用Node Controller所在節點的系統時間作為探測時間，將上次節點信息中的節點狀態變化時間作為該節點的狀態變化時間。如果判斷出在某段時間（gracePeriod）內沒有收到節點狀態信息，則設置節點狀態為“未知”，並且通過API Server保存節點狀態。
- 逐個讀取節點信息，如果節點狀態變為非“就緒”狀態，則將節點加入待刪除隊列，否則將節點從該隊列中刪除。如果節點狀態為非“就緒”狀態，且系統指定了CloudProvider，則Node Controller調用CloudProvider查看節點，若發現節點故障，則刪除etcd中的節點信息，並刪除和該節點相關的Pod等資源的信息。
四 ResourceQuota Controller
4.1 ResourceQuota Controller作用
ResourceQuota Controller，即資源配額管理，資源配額管理確保了指定的資源對象在任何時候都不會超量占用系統物理資源，避免了由於某些業務進程的設計或實現的缺陷導致整個系統運行紊亂甚至意外宕機，對整個集群的平穩運行和穩定性有非常重要的作用。 目前Kubernetes支持如下三個層次的資源配額管理。- 容器級別，可以對CPU和Memory進行限制。
- Pod級別，可以對一個Pod內所有容器的可用資源進行限制。
- Namespace級別，為Namespace（多租戶）級別的資源限制，包括：
- Pod數量；
- Replication Controller數量；
- Service數量；
- ResourceQuota數量；
- Secret數量；
- 可持有的PV數量。
4.2 ResourceQuota Controller工作流程
如圖所示，如果在Pod定義中同時聲明瞭LimitRanger，則用戶通過API Server請求創建或修改資源時，Admission Control會計算當前配額的使用情況，如果不符合配額約束，則創建對象失敗。
對於定義了ResourceQuota的Namespace，ResourceQuota Controller組件則負責定期統計和生成該Namespace下的各類對象的資源使用總量，統計結果包括Pod、Service、RC、Secret和PersistentVolume等對象實例個數，以及該Namespace下所有Container實例所使用的資源量（目前包括CPU和記憶體），然後將這些統計結果寫入etcd的resourceQuotaStatusStorage目錄（resourceQuotas/status）下。寫入resourceQuotaStatusStorage的內容包含Resource名稱、配額值（ResourceQuota對象中spec.hard域下包含的資源的值）、當前使用值（ResourceQuota Controller統計出來的值）。隨後這些統計信息被Admission Control使用，以確保相關Namespace下的資源配額總量不會超過ResourceQuota中的限定值。
五 Namespace Controller
5.1 Namespace Controller作用
用戶通過API Server可以創建新的Namespace並將其保存在etcd中，Namespace Controller定時通過API Server讀取這些Namespace的信息。如果Namespace被API標識為優雅刪除（通過設置刪除期限實現，即設置DeletionTimestamp屬性），則將該NameSpace的狀態設置成Terminating並保存到etcd中。同時Namespace Controller刪除該Namespace下的ServiceAccount、RC、Pod、Secret、PersistentVolume、ListRange、ResourceQuota和Event等資源對象。 在Namespace的狀態被設置成Terminating後，由Admission Controller的NamespaceLifecycle插件來阻止為該Namespace創建新的資源。同時，在Namespace Controller刪除該Namespace中的所有資源對象後，Namespace Controller對該Namespace執行finalize操作，刪除Namespace的spec.finalizers域中的信息。如果Namespace Controller觀察到Namespace設置了刪除期限，同時Namespace的spec.finalizers域值是空的，那麼Namespace Controller將通過API Server刪除該Namespace資源。六 Service Controller與Endpoints Controller
6.1 Service Controller與Endpoints Controller作用
如下所示為Service、Endpoints與Pod的關係。
Endpoints表示一個Service對應的所有Pod副本的訪問地址，Endpoints Controller就是負責生成和維護所有Endpoints對象的控制器。
Endpoints Controller負責監聽Service和對應的Pod副本的變化，如果監測到Service被刪除，則刪除和該Service同名的Endpoints對象。如果監測到新的Service被創建或者修改，則根據該Service信息獲得相關的Pod列表，然後創建或者更新Service對應的Endpoints對象。如果監測到Pod的事件，則更新它所對應的Service的Endpoints對象（增加、刪除或者修改對應的Endpoint條目）。
每個Node的kube-proxy進程會使用Endpoints對象，kube-proxy進程獲取每個Service的Endpoints，實現了Service的負載均衡功能。
因此Service Controller的作用，它其實是屬於Kubernetes集群與外部的雲平臺之間的一個介面控制器。Service Controller監聽Service的變化，如果該Service是一個LoadBalancer類型的Service（externalLoadBalancers=true），則Service Controller確保在外部的雲平臺上該Service對應的LoadBalancer實例被相應地創建、刪除及更新路由轉發表（根據Endpoints的條目）。
七 Admission Control
7.1 Admission Control概述
Admission Control配備了一個準入控制器的插件列表，發送給API Server的任何請求都需要通過列表中每個準入控制器的檢查，檢查不通過，則API Server拒絕此調用請求。此外，準入控制器插件能夠修改請求參數以完成一些自動化任務，比如ServiceAccount這個控制器插件。7.2 可配置創建列表
當前可配置的準入控制器插件如下。- AlwaysAdmit：已棄用，允許所有請求。
- AlwaysPullImages：在啟動容器之前總是嘗試重新下載鏡像。這對於多租戶共用一個集群的場景非常有用，系統在啟動容器之前可以保證總是使用租戶的密鑰去下載鏡像。如果不設置這個控制器，則在Node上下載的鏡像的安全性將被削弱，只要知道該鏡像的名稱，任何人便都可以使用它們了。
- AlwaysDeny：已棄用，禁止所有請求，用於測試。
- DefaultStorageClass：會關註PersistentVolumeClaim資源對象的創建，如果其中沒有包含任何針對特定Storage class的請求，則為其指派指定的Storage class。在這種情況下，用戶無須在PVC中設置任何特定的Storage class就能完成PVC的創建了。如果沒有設置預設的Storage class，該控制器就不會進行任何操作；如果設置了超過一個的預設Storage class，該控制器就會拒絕所有PVC對象的創建申請，並返回錯誤信息。因此需要確保Storage class對象的配置只有一個預設值。
- DefaultTolerationSeconds：針對沒有設置容忍node.kubernetes.io/not-ready:NoExecute或者node.alpha.kubernetes.io/unreachable:NoExecute的Pod，設置5min的預設容忍時間。
- DenyExecOnPrivileged：已棄用，攔截所有想在Privileged Container上執行命令的請求。如果你的集群支持Privileged Container，又希望限制用戶在這些Privileged Container上執行命令，那麼強烈推薦使用它。其功能已被合併到DenyEscalatingExec中。
- DenyEscalatingExec：攔截所有exec和attach到具有特權的Pod上的請求。如果你的集群支持運行有escalated privilege許可權的容器，又希望限制用戶在這些容器內執行命令，那麼強烈推薦使用它。
- EventReateLimit：Alpha版本，用於應對事件密集情況下對API Server造成的洪水攻擊。
- ExtendedResourceToleration：如果需要創建帶有特定資源（例如GPU、FPGA等）的獨立節點，則可能會對節點進行Taint處理來進行特別配置。該控制器能夠自動為申請這些特別資源的Pod加入Toleration定義，無須人工干預。
- ImagePolicyWebhook：這個插件將允許後端的一個Webhook程式來完成Admission Controller的功能。ImagePolicyWebhook需要使用一個配置文件（通過kube-API Server的啟動參數--admission-control-config-file設置）定義後端Webhook的參數。目前是Alpha版本的功能。
- Initializers：Alpha。用於為動態準入控制提供支持，通過修改待創建資源的元數據來完成對該資源的修改。LimitPodHardAntiAffinityTopology：該插件啟用了Pod的反親和性調度策略設置，在設置親和性策略參數requiredDuringSchedulingRequiredDuringExecution時要求將topologyKey的值設置為“kubernetes.io/hostname”，否則Pod會被拒絕創建。
- LimitRanger：這個插件會監控進入的請求，確保請求的內容符合在Namespace中定義的LimitRange對象里的資源限制。如果要在Kubernetes集群中使用LimitRange對象，則必須啟用該插件才能實施這一限制。LimitRanger還能用於為沒有設置資源請求的Pod自動設置預設的資源請求，該插件會為default命名空間中的所有Pod設置0.1CPU的資源請求。
- MutatingAdmissionWebhook：Beta。這一插件會變更符合要求的請求的內容，Webhook以串列的方式順序執行。
- NamespaceAutoProvision：這一插件會檢測所有進入的具備命名空間的資源請求，如果其中引用的命名空間不存在，就會自動創建命名空間。
- NamespaceExists：這一插件會檢測所有進入的具備命名空間的資源請求，如果其中引用的命名空間不存在，就會拒絕這一創建過程。
- NamespaceLifecycle：如果嘗試在一個不存在的Namespace中創建資源對象，則該創建請求將被拒絕。當刪除一個Namespace時，系統將會刪除該Namespace中的所有對象，包括Pod、Service等，並阻止刪除default、kube-system和kube-public這三個命名空間。
- NodeRestriction：該插件會限制kubelet對Node和Pod的修改行為。為了實現這一限制，kubelet必須使用system:nodes組中用戶名為system:node:<nodeName>的Token來運行。符合條件的kubelet只能修改自己的Node對象，也只能修改分配到各自Node上的Pod對象。在Kubernetes1.11以後的版本中，kubelet無法修改或者更新自身Node的taint屬性。在Kubernetes1.13以後，這一插件還會阻止kubelet刪除自己的Node資源，並限制對有kubernetes.io/或k8s.io/首碼的標簽的修改。
- OnwerReferencesPermissionEnforcement：在該插件啟用後，一個用戶要想修改對象的metadata.ownerReferences，就必須具備delete許可權。該插件還會保護對象的metadata.ownerReferences[x].blockOwnerDeletion欄位，用戶只有在對finalizers子資源擁有update許可權的時候才能進行修改。
- PersistentVolumeLabel：棄用。這一插件自動根據云供應商（例如GCE或AWS）的定義，為PersistentVolume對象加入region或zone標簽，以此來保障PersistentVolume和Pod同處一區。如果插件不為PV自動設置標簽，則需要用戶手動保證Pod和其載入捲的相對位置。該插件正在被Cloudcontrollermanager替換，從Kubernetes1.11版本開始預設被禁止。
- PodNodeSelector：該插件會讀取命名空間的annotation欄位及全局配置，來對一個命名空間中對象的節點選擇器設置預設值或限制其取值。
- PersistentVolumeClaimResize：該插件實現了對PersistentVolumeClaim發起的resize請求的額外校驗。
- PodPreset：該插件會使用PodSelector選擇Pod，為符合條件的Pod進行註入。
- PodSecurityPolicy：在創建或修改Pod時決定是否根據Pod的securitycontext和可用的PodSecurityPolicy對Pod的安全策略進行控制。
- PodTolerationRestriction：該插件首先會在Pod和其命名空間的Toleration中進行衝突檢測，如果其中存在衝突，則拒絕該Pod的創建。它會把命名空間和Pod的Toleration進行合併，然後將合併的結果與命名空間中的白名單進行比較，如果合併的結果不在白名單內，則拒絕創建。如果不存在命名空間級的預設Toleration和白名單，則會採用集群級別的預設Toleration和白名單。
- Priority：這一插件使用priorityClassName欄位來確定優先順序，如果沒有找到對應的PriorityClass，該Pod就會被拒絕。
- ResourceQuota：用於資源配額管理目的，作用於Namespace。該插件攔截所有請求，以確保在Namespace上的資源配額使用不會超標。推薦在Admission Control參數列表中將這個插件排最後一個，以免可能被其他插件拒絕的Pod被過早分配資源。
- SecurityContextDeny：這個插件將在Pod中定義的SecurityContext選項全部失效。SecurityContext在Container中定義了操作系統級別的安全設定（uid、gid、capabilities、SELinux等）。在未設置PodSecurityPolicy的集群中建議啟用該插件，以禁用容器設置的非安全訪問許可權。
- ServiceAccount：這個插件將ServiceAccount實現了自動化，如果想使用ServiceAccount對象，那麼強烈推薦使用它。
- StorageObjectInUseProtection：這一插件會在新創建的PVC或PV中加入kubernetes.io/pvc-protection或kubernetes.io/pv-protection的finalizer。如果想要刪除PVC或者PV，則直到所有finalizer的工作都完成，刪除動作才會執行。
- ValidatingAdmissionWebhook：在Kubernetes1.8中為Alpha版本，在Kubernetes1.9中為Beta版本。該插件會針對符合其選擇要求的請求調用校驗Webhook。目標Webhook會以並行方式運行；如果其中任何一個Webhook拒絕了該請求，該請求就會失敗。
1 --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultsStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota對Kubernetes 1.9及以下版本設置如下：
1 --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,CalidatingAdmissionWebhook,ResourceQuota
