《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，從備選節點列表中選出各項資源使用率最均衡的節點