《Kubernetes權威指南》——組件原理

1 API Server

1.1 提供集羣管理的API接口

• API Server在kubernetes中的進程名爲apiserver，運行在Master節點上
• apiserver開放兩個端口
  • 本地端口，默認8080
  • 安全端口，默認6443，接受Https，用於基於Token以及策略的受權
• Kubectl Proxy做爲API Server的反向代理，也能做爲普通客戶端訪問API Server
• 命令行工具kubectl用來將API Server的API包裝成建檔的命令集

1.2 成爲集羣內各個功能模塊之間數據交互和通訊的中心樞紐

• 集羣內的功能模塊經過API Server將信息存入etcd，其餘模塊經過API Server讀取這些信息，從而實現模塊之間的信息交互
• 爲了緩解各模塊對API Server的訪問壓力，各個功能模塊都採用緩存的機制來緩存數據，各模塊定時從API Server獲取指定資源對象信息(list及watch方式)，功能模塊不直接訪問API Server

1.3 擁有完備的集羣安全機制

後續安全章節

2 Controller Manager

其爲集羣內部的管理控制中心，負責集羣內的Node、Pod副本、服務端點(Endpoint)、命名空間(Namespace)、服務賬號(ServiceAccount)、資源定額(ResourceQuota)等的管理並執行自動化修復流程

2.1 Replication Controller

做用： 確保在任什麼時候候集羣中一個RC所關聯的Pod都保持必定數量的Pod副本處於正常運行狀態

• Pod對象被成功建立後不會消失，用戶或RC會銷燬Pod對象，惟一例外是當Pod處於succeeded或failed狀態時間過程時，該Pod將被系統自動回收
• 當Pod狀態編程failed或被刪除，且其RestartPolicy=Always時，管理該Pod的副本控制器將在其餘Node上從新建立運行該Pod
• Pod能夠經過修改Label來實現脫離RC的管控，該方法能夠用於將Pod從集羣中遷移、數據修復等調試
• 經過調整RC的spec.replicas的屬性來調整Pod的副本數量
• RC的使用模式：
  • 從新調度，保證Pod的副本數量
  • 彈性伸縮，手動或經過自動擴容代理修改RC的spce.replicas的值
    kubectl scale --replicas=3 replicationcontroller foo//設置foo的RC副本
  • 滾動更新，RC被設計成經過逐個替換Pod的方式來輔助服務的滾動更新

2.2 Node Controller

做用： 負責管理、發現和監控集羣中的各個Node節點

• Kubelet在啓動時經過API Server註冊節點信息，並定時向API Server發送節點信息，API Server將接受的信息存入etcd
• Node Controller經過API Server按期讀取信息，並作以下處理：
  1. Controller Manager在啓動時若是設置了--cluster-cdir參數，則每一個設置了spec.PodCIDR的Node生成一個CIDR地址
  2. 逐個讀取節點信息，將節點信息和Node Controller的nodeStatusMap中保存的節點信息作比較。
     • 沒收到節點信息、第一次收到節點信息、處理過程當中節點狀態變成非健康狀態、在指定時間內收到新節點信息且節點狀態發生變化，用Master節點的系統時間做爲探測時間和節點狀態變化時間
     • 在指定時間內收到新的節點信息，但節點狀態沒改變，用Master節點的系統時間做爲探測時間，用上次節點信息中的節點狀態狀態改變時間做爲該節點的狀態改變時間
  3. 若是某一段時間內沒有收到節點狀態信息，則置該節點狀態爲「未知」
  4. 若是節點狀態爲非就緒狀態，則將節點加入到待刪除隊列不然從該隊列中刪除。若是系統指定Cloud Provider則Node Controller調用Cloud Provider查看節點，發現節點故障則刪除etcd中節點信息，並刪除該節點相關的Pod等資源信息

2.3 ResourceQuota Controller

做用： 資源配置管理確保指定的對象在任什麼時候候都不會超量佔用系統資源

• 三個層次的資源配額管理：

  • 容器級別，對CPU與Memory進行限制
  • Pod級別，對一個Pod內全部容器的可用資源限制
  • Namespace級別，如今該Namespace下的Pod、Replication Controller、Service、ResourceQuota、Secret和可持有的PV(Persistent Volume)
• 配額管理經過准入機制(Admission Control)實現，與配額相關的兩種准入控制器是LimitRanger與ResourceQuota，前者做用與Pod和Container後者做用於Namespace
• 全部Pod、Service、RC、Secret和Persistent Volume資源對象的實時狀態經過API Server保存到etcd，ResourceQuota Controller在計算資源使用總量時會用到這些信息

• 用戶經過API Server請求建立或修改資源時，API Server會調用Admission Controller的ResourceQuota插件，其將讀取etcd中的統計結果，若是某項資源超出配額，則將拒絕執行

2.4 Namespace Controller

• 經過API Server建立Namespace並保存到etcd，Namespace Controller定時讀取Namespace信息
• 當Namespace被標識爲優雅刪除(設置刪除期限，DeletionTimestamp屬性被設置)，則將其狀態設置爲Terminating，同時刪除其下的全部對象
• 當狀態爲Terminating時由Adminssion Controller的NamespaceLifecycle插件阻止爲該Namespace建立新資源
• Namespace Controller爲其刪除完全部資源對象後，將對其執行finalize操做，刪除Namespace的spec.finalizers域中的信息

2.5 ServiceAccount Controller與Token Controller

ServiceAccount Controller 在Controller Manager啓動時被建立，其監聽Service Account的刪除事件和Namespace的建立、修改事件

Token Controller 監聽Service Account和Secret的建立、修改和刪除事件，並根據事件的不一樣作不一樣處理

2.6 Service Controller與Endpoint Controller

Service 定義Pod集合的抽象，或者被訪問者看做一個訪問策略，也可稱爲微服務

Service Controller 監控Service的變化，若是是LoadBalancer類型則需確保外部LoadBalancer被相應建立與刪除

Endpoint Controller 經過Store來緩存Service和Pod信息，監控Service和Pod的變化

• Kubernetes中Service是一種資源對象經過標籤選擇器選擇Pod
• 若是Service指定了標籤選擇器，系統將自動建立一個和該Service同名的Endpoint資源對象，其包含一個地址和端口集合，地址與端口即被選擇的Pod的
• 經過虛擬IP訪問後端Pod
  • kube-proxy進程會觀察Master上添加和刪除Service和Endpoint的行爲
  • kube-proxy爲每一個Service在本地主機開一個端口，任何訪問該端口的鏈接都被代理到相應的Pod(選擇Pod依據Round Robin算法及Service的Session粘連決定)
  • kube-proxy在本機Iptables安裝相應規則，將捕獲的流量重定向到上一步中的隨機端口
• Kubernetes會爲Service制定一個集羣Ip
• Kubernetes支持容器的Service環境變量和DNS兩種形式來查找Service的集羣IP
• Service暴露外網ip能夠經過NodePort和LoadBalancer兩種模式

3 Scheduler

做用： 在於將待調度的Pod經過一些複雜的調度流程綁定到某個合適的Node上，並寫入etcd

• 主要涉及待調度Pod列表、可用Node列表和調度算法和策略
• Kubernetes提供的默認調度流程：
  1. 預選調度過程，遍歷全部目標Node，篩選出符合要求的候選節點
  2. 肯定最優勢，基於候選節點，採用優選策略計算出每一個候選節點的積分，積分最高者獲勝
• 預選策略
  • NoDiskConflict，判斷備選Pod的GCEPersistentDisk或AWSElasticBloackStore和備選的節點中已存的Pod是否存在衝突
  • PodFitsResources，判斷節點的資源是否知足Pod的需求
  • PodSelectorMatches，節點是否包含備選pod的標籤選擇器指定的標籤
  • PodFitsHost，判斷備選Pod的spec.nodeName所指定的節點名稱和備選節點名稱是否一致
  • CheckNodeLabelPresence，判斷策略列出的標籤在備選節點中存在時，是否選擇該備選節點
  • CheckServiceAffinity，判備選節點是否包含策略指定的標籤或包含和備選Pod在相同Service和Namespace下的Pod所在節點的標籤列表
  • PodFitsPorts，判斷備選Pod所用端口列表中的端口是否在備選節點中已被佔用
• 優選策略，每一個節點經過優選策略都會算出一個得分，計算各項總分，分值最大的最優
  • LeastRequestedPriority，從備選節點列表中選出資源消耗最小的節點
  • CalculateNodeLabelPriority，判斷策略列出的標籤在備選節點中存在時，是否選擇該備選節點
  • BalancedResourceAllocation，從備選節點列表中選出各項資源使用率最均衡的節點