以下是《kubernetes權威指南》的學習筆記，我對書中的內容做了總結和提煉。 如有謬誤之處， 還望各位指出。

Apiserver原理分析

概述

整個系統的數據匯流排。提供以下功能特性：

1. 集群管理的api入口

2. 資源配額控制的入口

3. 提供完善的集群安全機制

api 訪問

訪問api的三種方式：

1. 直接curl調用api

2. 啟動內部代理（kubectl proxy ），然後訪問內部代理進行調用，可以進行訪問控制，如限制要訪問的介面，增加允許訪問的client的白名單

3. 使用k8s提供的client lib ，通過編程的方式訪問，這種方式有兩種使用場景，一是pod需要發現同屬於一個service的其它pod副本的信息來組建集群（如elasticsearch集群）， 二是需要通過調用api來我開發基於k8s的管理平台

獨特的k8s proxy api：

這種api可以用來代理rest請求， 把收到的請求轉發到某一個node上的kubelet進程的埠上，由kubelet進行響應示例： curl 127.0.0.1:8080/api/v1/proxy/nodes/node-1/pods這裡返回的pods的信息是由node上的kubelet進程收集的， 而不是從etcd的資料庫獲取， 二者的信息可能在某個時間點會有偏差。這種特殊的api的應用場景是： 通過這類api來直接訪問pods上的應用， 可以用來逐一排查同一service的多個pod副本上的應用是否有異常。示例一： curl 127.0.0.1:8080/api/v1/proxy/namespaces/default/pods/xxxx-pod-1示例二： curl 127.0.0.1:8080/api／v1/proxy/namespaces/default/services/xxxx-svr-1

集群之間功能模塊的通信

kubelet --> apiserver (彙報自身狀態， 偵聽pod信息)controller-manager --> apiserver (實時監控node信息，並做處理)scheduler --> apiserver （偵聽新建pod的信息， 檢索符合要求的node列表，並進行調度邏輯的執行）

為緩解apiserver的壓力， 各個模塊會緩存從apiserver獲取的數據， 某些情況下會直接使用緩存的數據（什麼情況使用緩存， 如何保證數據的一致性？）

controller manager原理分析

集群內部的管理控制中心，是一個「修正系統」。負責以下對象的管理：

• node

• pod副本

• endpoint

• namespace

• service accout

• resource quota

包含了以下controller：

• replication controller

• node controller

• resourcequota controller

• namespace controller

• serviceaccount controller

• token controller

• service controller

• endpoint controller

replication controller

職責是： 保證pod副本數量始終保持預設值應用場景：

1. 確保pod數量， 以保證高可用要求

2. 系統擴容和縮容

3. 滾動更新

只有當pod的重啟策略是Always時（RestartPolicy=Always）時， replication controller 才會管理該pod的操作（例如創建， 銷毀， 重啟等）

pod通過修改標籤可以脫離replication controller的控制

node controller

通過apiserver獲取node的信息，實現管理和監控集群的各個node節點的相關控制功能。節點的健康狀態有三種： 就緒（true）， 未就緒（false）， 未知（unknown）master節點的系統時間作為探測時間， 狀態變化的時間可能是上一次保存的狀態時間，或者本次節點變化的時間。如果有段時間沒有收到節點信息，則狀態設置為unknown.當狀態為非就緒狀態時， 將節點加入待刪除隊列。

resourcequota controller

資源配額管理， 確保指定的資源對象在任何情況下都不會超量佔用系統資源，避免業務進程的設計和實現的缺陷導致整個系統的紊亂， 對整個集群的平穩運行起著重要作用。

k8s集群對資源配額的管理有三個維度： 容器級別， pod級別， namespace級別。容器級別： cpu & memorypod級別： 所有容器的可用資源namespace級別： pod數量， rc數量， svr數量， resourcequota數量， secret數量， pv數量

配額管理的控制：由apiserver中的admission control來控制， 實際上apiserver是配額控制的一個入口。兩種配額約束方式： limitranger（容器級別， pod級別）， resourcequota（namespace級別）

resourcequota controller組件負責定期統計namespace下pod， rc， svr， resourcequota， secret， pv等資源對象的數量， 還有container實例使用的資源，將統計結果寫入etcd。這些信息會被admission controller使用， 如果不符合配額約束， 則創建對象失敗。如果既在namespace上命名了resourcequota約束， 又在pod級別聲明了limitranger，admission control 會同時計算二者的情況， 需要同時滿足才會創建對象。

namespace controller

用戶通過api server創建新的namespace， 並保存在etcd中。 而這個controller可以通過api server讀取namespace的相關信息。當namespace的狀態被設置為terminating時， 這個controller會刪除改namespace下的所有對象資源。admission controller會通過namespacelifecycle插件來阻止為該namespace創建新的資源。

serviceaccount controller

token controller

service controller

k8s集群和外部雲平台的一個介面控制器，負責偵聽service的變化。如果service的type是loadbalancer， 那麼service controller就會負責動態更新創建對於的loadbalancer實例， 和路由轉發表等

endpoint controller

負責偵聽service和相應的pod副本的變化，以及生成和維護所有endpoints對象。 當service被刪除時，該controller會負責刪除該service同名的endpoints對象。 當新的service被創建或修改， pod產生相關事件時， 該controller就會更新對應service的endpoints對象（更改對應的endpoint條目）。

註： endpoints對象維護一個service對應的所有pod副本的訪問地址。

scheduler 原理分析

scheduler是負責pod調度的重要組件。起著承上啟下的作用， 從上游接收controller manager 創建的pod， 為起安排node落腳， 然後交給目標node上的kubelet進程， 由其負責pod的「下半生」的生命周期管理。

默認調度流程分兩步：

1. 預選（predicates）： 遍歷所有node， 先根據預選策略初步篩選出符合條件的node

2. 優選（priority）： 從預選的node中挑出最優的選擇

調度流程是通過插件的方式載入調度演算法提供者。 每個algorithmprovider都要提供3個參數， 演算法名稱name， 預選策略集合predicatekeys， 優選策略集合prioritykeys

7個可用的預選策略：

• NoDiskConflict

• PodFirstResources

• PodSelectorMatches

• PodFitsHost

• CheckNodeLablePresence

• CheckServiceAffinity

• PodFitsPorts

默認的algorithmprovider載入的預選策略：

• NoDiskConflict

• PodFirstResources

• PodSelectorMatches

• PodFitsHost

• PodFitsPorts

所有預選策略的說明

• NoDiskConflict

判斷備選pod的gcepersistentdisk或者awselasticblockstore和備選的節點已存在的pod是否存在衝突

• PodFirstResources

node的資源是否滿足備選pod的需求。需要對備選pod和node上已有pod的資源進行求和，看是否超過node所能提供的資源

• PodSelectorMatches

node是否有pod的標籤選擇器所指定的標籤， 即nodeselector所指定的標籤

• PodFitsHost

node的名稱是否和pod所指定的node名稱一致， 即nodename所指定的名稱

• CheckNodeLablePresence

用於判斷當策略列出的標籤在備選節點存在是， 是否選擇該備選節點

• CheckServiceAffinity

用於判斷備選節點是否包含策略指定的標籤

• PodFitsPorts

判斷備選pod所用的埠是否在備選的node中被佔用

3個優選策略：

• LeastRequestedPriority

• CalculateNodeLabelPriority

• BalancedResourceAllocation

註：每個節點通過優選策略會算出一個得分， 得分最大的節點作為最終的優選結果。

問題： 所有的優選策略都要計算一遍么？還是只是挑選其中的一個？如果挑選其中一個，又是如何挑選？

所有優選策略的說明：

• LeastRequestedPriority

選出資源消耗最少的節點， 即資源最充足的節點（cpu， mem兩個維度）， 有對應的計算公式

• CalculateNodeLabelPriority

  
  

  判斷策略列出的標籤在備選節點出現時，是否選擇該備選節點

• BalancedResourceAllocation

從備選節點中選出各項資源使用率最均衡的方法， 與1類似，但是計算公式又不同

歡迎關注微信公眾號"雲時代的運維開發"