史上最全k8s必學必會知識梳理

正文

kube-apiserver

對外暴露了Kubernetes API。它是的 Kubernetes 核心控制層。它被設計爲水平擴展，即經過部署更多實例來橫向擴展。API Server 負責和 etcd 交互（其餘組件不會直接操做 etcd，只有 API Server 這麼作），是整個 kubernetes 集羣的數據中心，全部的交互都是以 API Server 爲核心的。API Server 提供瞭如下的功能：

• 整個集羣管理的 API 接口：全部對集羣進行的查詢和管理都要經過 API 來進行。
• 集羣內部各個模塊之間通訊的樞紐：全部模塊之間並不會互相調用，而是經過和 API Server 打交道來完成各自的工做。
• 集羣安全控制：API Server 提供的驗證和受權保證了整個集羣的安全。

kube-controller-manager和kube-scheduler的高可用選主機制

https://blog.csdn.net/weixin_...

在k8s的組件中，其中有kube-scheduler和kube-controller-manager兩個組件是有leader選舉的，這個選舉機制是k8s對於這兩個組件的高可用保障。須要--leader-elect=true啓動參數。即正常狀況下kube-scheduler或kube-manager-controller組件的多個副本只有一個是處於業務邏輯運行狀態，其它副本則不斷的嘗試去獲取鎖，去競爭leader，直到本身成爲leader。若是正在運行的leader因某種緣由致使當前進程退出，或者鎖丟失，則由其它副本去競爭新的leader，獲取leader繼而執行業務邏輯。

在K8s中， 經過建立資源對象（當前的實現中實現了 ConfigMap 和 Endpoint 兩種類型的資源）來維護鎖的狀態。這兩種資源對象存在etcd裏，也能夠說是用etcd來實現的。

分佈式鎖通常實現原理就是你們先去搶鎖，搶到的成爲 leader ，而後 leader 會按期更新鎖的狀態，聲明本身的活動狀態，不讓其餘人把鎖搶走。K8s 的資源鎖也相似，搶到鎖的節點會將本身的標記。設爲鎖的持有者，其餘人則須要經過對比鎖的更新時間和持有者來判斷本身是否能成爲新的 leader ，而 leader 則能夠經過更新RenewTime來確保持續保有該鎖。

主要調用client-go包中的：

k8s.io/client-go/tools/leaderelection

總共有7個leader選舉參數：

• lock-object-namespace和lock-object-name是鎖對象的命名空間和名稱。
• leader-elect表示該組件運行時是否須要leader選舉(若是集羣中運行多副本，須要設置該選項爲true，不然每一個副本都將參與實際工做)。
• leader-elect-lease-duration爲資源鎖租約觀察時間，若是其它競爭者在該時間間隔事後發現leader沒更新獲取鎖時間，則其它副本能夠認爲leader已經掛掉不參與工做了，將從新選舉leader。
• leader-elect-renew-deadline leader在該時間內沒有更新則失去leader身份。
• leader-elect-retry-period爲其它副本獲取鎖的時間間隔(競爭leader)和leader更新間隔。
• leader-elect-resource-lock是k8s分佈式資源鎖的資源對象，目前只支持endpoints和configmaps。

etcd

Etcd使用的是raft一致性算法來實現的，是一款分佈式的一致性KV存儲，主要用於共享配置和服務發現。用於 Kubernetes 的後端存儲。全部集羣數據都存儲在此處，ETCD在k8s技術棧的地位，就彷彿數據庫（Mysql、Postgresql或oracle等）在Web應用中的地位，它存儲了k8s集羣中全部的元數據（以key-value的方式）。整個kubernetes系統須要用到etcd用來協同和存儲配置的有：

• 網絡插件flannel、calico等網絡插件也須要用到etcd存儲網絡的配置信息
• kubernetes自己，包括各類對象的狀態和元信息配置

注意：flannel操做etcd使用的是v2的API，而kubernetes操做etcd使用的v3的API，因此在下面咱們執行etcdctl的時候須要設置ETCDCTL_API環境變量，該變量默認值爲2。

K8s中全部元數據的增刪改查都是由kube-apiserver來執行的。ETCD中key值經過觀察能夠簡單得出下面幾個規律：

k8s主要把本身的數據註冊在/registry/前綴下面（在ETCD-v3版本後沒有了目錄的概念，只能一切皆前綴了）。經過觀察k8s中deployment、namespace、pod等在ETCD中的表示，能夠知道這部分資源的key的格式爲/registry/{k8s對象}/{命名空間}/{具體實例名}。

kube-controller-manager

kube-controller-manager運行控制器，它們是處理集羣中常規任務的後臺線程。邏輯上，每一個控制器是一個單獨的協程。用於監視 apiserver 暴露的集羣狀態，而且不斷地嘗試把當前狀態向集羣的目標狀態遷移。爲了不頻繁查詢 apiserver，apiserver 提供了 watch 接口用於監視資源的增長刪除和更新，client-go 對此做了抽象，封裝一層 informer 來表示本地 apiserver 狀態的 cache 。

參考:

https://blog.csdn.net/huwh_/a...

這些控制器包括:

節點控制器（node-controller）: kubelet在啓動時會經過API Server註冊自身的節點信息，並定時向API Server彙報狀態信息，API Server接收到信息後將信息更新到etcd中。Node Controller經過API Server實時獲取Node的相關信息，實現管理和監控集羣中的各個Node節點的相關控制功能。

副本控制器（Replication Controller）: 負責維護系統中每一個副本控制器對象正確數量的 Pod。副本控制器的做用即保證集羣中一個RC所關聯的Pod副本數始終保持預設值。只有當Pod的重啓策略是Always的時候（RestartPolicy=Always），副本控制器纔會管理該Pod的操做（建立、銷燬、重啓等）。

服務賬戶和令牌控制器（ServiceAccount Controller ）: 爲新的命名空間建立默認賬戶和 API 訪問令牌。

資源配額管理控制器ResourceQuota Controller：資源配額管理確保指定的資源對象在任什麼時候候都不會超量佔用系統物理資源。支持三個層次的資源配置管理：

• 容器級別：對CPU和Memory進行限制;
• Pod級別：對一個Pod內全部容器的可用資源進行限制;
• Namespace級別：包括Pod數量、Replication Controller數量、Service數量、ResourceQuota數量、Secret數量、可持有的PV（Persistent Volume）數量

Namespace Controller：用戶經過API Server能夠建立新的Namespace並保存在etcd中，NamespaceController定時經過API Server讀取這些Namespace信息。若是Namespace被API標記爲優雅刪除（即設置刪除期限，DeletionTimestamp）,則將該Namespace狀態設置爲「Terminating」,並保存到etcd中。同時Namespace Controller刪除該Namespace下的ServiceAccount、RC、Pod等資源對象。

Service Controller：屬於kubernetes集羣與外部的雲平臺之間的一個接口控制器。Service Controller監聽Service變化，若是是一個LoadBalancer類型的Service，則確保外部的雲平臺上對該Service對應的LoadBalancer實例被相應地建立、刪除及更新路由轉發表。

deployment controller：用來替代之前的ReplicationController來方便的管理應用。只須要在 Deployment 中描述您想要的目標狀態是什麼，Deployment controller 就會幫您將 Pod 和ReplicaSet 的實際狀態改變到您的目標狀態。您能夠定義一個全新的 Deployment 來建立 ReplicaSet 或者刪除已有的 Deployment 並建立一個新的來替換。

• 定義Deployment來建立Pod和ReplicaSet
• 滾動升級和回滾應用
• 擴容和縮容
• 暫停和運行Deployment

statefulset controller：StatefulSet是爲了解決有狀態服務的問題（對應Deployments和ReplicaSets是爲無狀態服務而設計），其應用場景包括：

• 穩定的持久化存儲，即Pod從新調度後仍是能訪問到相同的持久化數據，基於PVC來實現;
• 穩定的網絡標誌，即Pod從新調度後其PodName和HostName不變，基於Headless Service（即沒有Cluster IP的Service）來實現。StatefulSet中每一個Pod的DNS格式爲：

statefulSetPodName-{0..N-1}.serviceName.namespace.svc.cluster.local

• 有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次依次進行（即從0到N-1，在下一個Pod運行以前全部以前的Pod必須都是Running和Ready狀態），基於init containers來實現；
• 有序收縮，有序刪除（即從N-1到0）

daemonset controller：DaemonSet確保所有（或者一些）Node 上運行一個 Pod 的副本。當有 Node 加入集羣時，也會爲他們新增一個 Pod 。當有 Node 從集羣移除時，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它建立的全部 Pod。

Horizontal Pod Autoscaling：僅適用於Deployment和ReplicaSet，在V1版本中僅支持根據Pod的CPU利用率擴所容，在v1alpha版本中，支持根據內存和用戶自定義的metric擴縮容。

persistentvolume-binder：按期同步磁盤卷掛載信息，負責pv和pvc的綁定。

Endpoints controller：表示了一個Service對應的全部Pod副本的訪問地址，而EndpointsController負責生成和維護全部Endpoints對象的控制器。它負責監聽Service和對應的Pod副本的變化。

• 若是監測到Service被刪除，則刪除和該Service同名的Endpoints對象；
• 若是監測到新的Service被建立或修改，則根據該Service信息得到相關的Pod列表，而後建立或更新Service對應的Endpoints對象;
• 若是監測到Pod的事件，則更新它對應的Service的Endpoints對象。

kube-proxy進程獲取每一個Service的Endpoints，實現Service的負載均衡功能。

以上只是部分控制器，都是一個獨立的協程，被controller-manager這個進程所管理。

Statefulset和Deployment的區別

Deployment用於部署無狀態服務，StatefulSet用來部署有狀態服務。

若是部署的應用知足如下一個或多個部署需求，則建議使用StatefulSet。

• 穩定的、惟一的網絡標識;
• 穩定的、持久的存儲;
• 有序的、優雅的部署和伸縮;
• 有序的、優雅的刪除和中止;
• 有序的、自動的滾動更新;
• 實現固定的Pod IP方案, 能夠優先考慮基於StatefulSet

穩定的：主要是針對Pod發生re-schedule後仍然要保持以前的網絡標識和持久化存儲。這裏所說的網絡標識包括hostname、集羣內DNS中該Pod對應的A Record，並不能保證Pod re-schedule以後IP不變。要想保持Pod IP不變，咱們能夠藉助穩定的Pod hostname定製IPAM獲取固定的Pod IP。藉助StatefulSet的穩定的惟一的網絡標識特性，咱們能比較輕鬆的實現Pod的固定IP需求，而後若是使用Deployment，那麼將會複雜的多，你須要考慮滾動更新的過程當中的參數控制(maxSurge、maxUnavailable)、每一個應用的IP池預留形成的IP浪費等等問題。

存儲：StatefulSet對應Pod的存儲最好經過StorageClass來動態建立：每一個Pod都會根據StatefulSet中定義的VolumeClaimTemplate來建立一個對應的PVC，而後PVS經過StorageClass自動建立對應的PV，並掛載給Pod。因此這種方式，須要事先建立好對應的StorageClass。固然，你也能夠經過預先由管理員手動建立好對應的PV，只要能保證自動建立的PVC能和這些PV匹配上。

爲了數據安全，當刪除StatefulSet中Pods或者對StatefulSet進行縮容時，Kubernetes並不會自動刪除StatefulSet對應的PV，並且這些PV默認也不能被其餘PVC Bound。當你確認數據無用以後再手動去刪除PV的時候，數據是否刪除取決於PV的ReclaimPolicy配置。Reclaim Policy支持如下三種：

• Retain，意味着須要你手動清理；
• Recycle，等同於rm -rf /thevolume/*
• Delete，默認值，依賴於後端的存儲系統本身實現。

部署和伸縮時與Deployment的區別

• 當部署有N個副本的StatefulSet應用時，嚴格按照index從0到N-1的遞增順序建立，下一個Pod建立必須是前一個Pod Ready爲前提。
• 當刪除有N個副本的StatefulSet應用時，嚴格按照index從N-1到0的遞減順序刪除，下一個Pod刪除必須是前一個Pod shutdown並徹底刪除爲前提。
• 當擴容StatefulSet應用時，每新增一個Pod必須是前一個Pod Ready爲前提。
• 當縮容StatefulSet應用時，沒刪除一個Pod必須是前一個Pod shutdown併成功刪除爲前提。

kube-scheduler

kube-scheduler監視沒有分配節點的新建立的 Pod，選擇一個節點供他們運行。調度節點分配主要能夠分爲預選（Predicates）與優選（Priorities）兩個環節：

預選

根據配置的PredicatesPolicies（默認爲DefaultProvider中定義的default predicates policies集合）過濾掉那些不知足這些Policies 的 Node，預選的輸出做爲優選的輸入；

優選

根據配置的PrioritiesPolicies（默認爲DefaultProvider中定義的default priorities policies集合）給預選後的 Node 進行打分排名，得分最高的 Node 即做爲最適合的 Node ，該 Pod 就綁定（Bind）到這個 Node 。

注：若是通過優選將 Node 打分排名後，有多個 Node 並列得分最高，那麼kube-scheduler將隨機從中選擇一個 Node 做爲目標 Node 。

預選階段算法

NoDiskConflict：評估是否存在volume衝突。若是該 volume 已經 mount 過了，k8s可能會不容許重複mount(取決於volume類型)；

NoVolumeZoneConflict：評估該節點上是否存在 Pod 請求的 volume；

PodFitsResources：檢查節點剩餘資源(CPU、內存)是否能知足 Pod 的需求。剩餘資源=總容量-全部 Pod 請求的資源；

MatchNodeSelector：判斷是否知足 Pod 設置的 NodeSelector；

CheckNodeMemoryPressure：檢查 Pod 是否能夠調度到存在內存壓力的節點；

CheckNodeDiskPressure：檢查 Pod 是否能夠調度到存在硬盤壓力的節點；

優選階段算法

依次計算該 Pod 運行在每個 Node 上的得分。主要算法有：

LeastRequestedPriority：最低請求優先級，即 Node 使用率越低，得分越高；

BalancedResourceAllocation：資源平衡分配，即CPU/內存配比合適的 Node 得分更高；

SelectorSpreadPriority：儘可能將同一 RC/Replica 的多個 Pod 分配到不一樣的 Node 上；

CalculateAntiAffinityPriority：儘可能將同一 Service 下的多個相同 Label 的 Pod 分配到不一樣的 Node；

ImageLocalityPriority：Image本地優先，Node 上若是已經存在 Pod 須要的鏡像，而且鏡像越大，得分越高，從而減小 Pod 拉取鏡像的開銷(時間)；

NodeAffinityPriority：根據親和性標籤進行選擇；

默認的預選、優選調度算法遠不止以上這些。能夠經過kube-scheduler的啓動參數中加policy-config-file文件、configmaps（過期）、或者--config指定調度器用哪些預選、優選算法。

調度算法的擴展

若是kube-scheduler提供的調度算法不知足調度要求，也能夠本身開發擴展調度器，在kube-scheduler啓動參數的policy-config中指定擴展調度器的地址，包括（預選接口、優選接口、優先級搶佔，pod和node綁定的Bind接口）。

擴展調度器示例代碼：

https://github.com/liabio/k8s...

因爲默認調度器kube-scheduler須要調用擴展調度程序kube-scheduler-extender，故須要在kube-scheduler的啓動參數裏配置擴展調度器的地址。須要在master節點主機的/etc/kubernetes目錄下的scheduler.yaml中配置以下內容：（static pod方式部署的kube-scheduler不能用configmaps的方式掛載配置文件）

apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
algorithmSource:
  policy:
    file:
      path: /etc/kubernetes/scheduler-policy.json
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf
leaderElection:
  leaderElect: true

主要配置是否啓用選舉機制，以及與API Server交互時認證用的scheduler.conf文件地址，調度策略選擇用的scheduler-policy.json：

{
  "kind": "Policy",
  "apiVersion": "v1",
  "predicates": [
    {
      "name": "NoVolumeZoneConflict"
    },
    {
      "name": "MatchInterPodAffinity"
    },
    {
      "name": "NoDiskConflict"
    },
    {
      "name": "GeneralPredicates"
    },
    {
      "name": "PodToleratesNodeTaints"
    },
    {
      "name": "CheckVolumeBinding"
    }
  ],
  "priorities": [
    {
      "name": "SelectorSpreadPriority",
      "weight": 1
    },
    {
      "name": "InterPodAffinityPriority",
      "weight": 1
    },
    {
      "name": "LeastRequestedPriority",
      "weight": 1
    },
    {
      "name": "NodeAffinityPriority",
      "weight": 1
    },
    {
      "name": "BalancedResourceAllocation",
      "weight": 1
    },
    {
      "name": "NodePreferAvoidPodsPriority",
      "weight": 10000
    },
    {
      "name": "TaintTolerationPriority",
      "weight": 1
    }
  ],
  "extenders": [
    {
      "urlPrefix": "http://kube-scheduler-extender:80/scheduler",
      "filterVerb": "predicates/middleware_predicate",
      "prioritizeVerb": "",
      "preemptVerb": "",
      "bindVerb": "bind",
      "weight": 1,
      "enableHttps": false,
      "nodeCacheCapable": false
    }
  ],
  "hardPodAffinitySymmetricWeight": 10,
  "alwaysCheckAllPredicates": false
}

裏面指定了默認調度器用到的預選、優選算法，以及調用擴展調度器的service地址，預選和Bind接口URI。

在/etc/kubernetes/manifests目錄下的kube-scheduler.yaml中啓動參數中加--config=/etc/kubernetes/scheduler.yaml，該文件經過hostPath的方式掛載到容器內。

DNS

kube-dns這個插件是官方推薦安裝的。經過將 Service 註冊到 DNS 中，k8s 能夠爲咱們提供一種簡單的服務註冊發現與負載均衡方式。

kube-dns內部經過監聽services和endpoints的變動事件將域名和IP對應信息同步到本地緩存。好比服務 a 訪問服務 b，dns解析依賴a容器內 /etc/resolv.conf 文件的配置

cat/etc/resolv.conf

nameserver 10.233.0.3
search default.svc.cluster.local svc.cluster.localcluster.local

這個文件中，配置的 DNS Server，通常就是 K8S 中，kubedns 的 Service 的 ClusterIP，這個IP是虛擬IP，沒法ping。

[root@node4 user1]#kubectl get svc -n kube-system
NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
kube-dns              ClusterIP   10.233.0.3             53/UDP,53/TCP   270d
kubernetes-dashboard  ClusterIP   10.233.22.223          443/TCP         124d

全部域名的解析，其實都要通過 kubedns 的虛擬IP 10.233.0.3 ，負載到某一個kube-dns pod上去解析。若是不能解析，則會去kube-dns pod所在的主機上的dns服務（/etc/resolv.conf）作解析。Kubernetes 啓動的容器自動將 DNS 服務器包含在容器內的/etc/resolv.conf 中。

域名格式以下：

statefulset通常使用Headless Service，如statefulset名爲test，建立2個pod，則域名爲test-0.test.kube-system.svc.cluster.local和test-1.test.kube-system.svc.cluster.local

節點組件

節點組件在每一個節點上運行，維護運行的 Pod 並提供Kubernetes 運行時環境。kubelet通常做爲二進制運行到每一個k8s節點；kube-proxy做爲daemonset pod運行到每一個k8s節點。

kubelet

在kubernetes集羣中，每一個Node節點都會啓動kubelet進程，用來處理Master節點下發到本節點的任務，管理Pod和其中的容器。kubelet會在API Server上註冊節點信息，按期向Master彙報節點資源使用狀況，並經過cAdvisor監控容器和節點資源。

• pod被調度到kubelet所在節點時，調用CNI（Docker 運行或經過 rkt)運行 Pod 的容器;
• 週期性的對容器生命週期進行探測。（健康檢查readness-隔離、liveness-重啓）;
• 檢查節點狀態，將節點的狀態報告給kube-apiserver;
• 容器監控所在節點的資源使用狀況，並定時向 kube-apiserver報告。知道整個集羣全部節點的資源狀況，對於 pod 的調度和正常運行相當重要。kubelet 使用cAdvisor進行資源使用率的監控。

kube-proxy

https://blog.csdn.net/qq_2181...

service是一組pod的服務抽象，至關於一組pod的負載均衡器，負責將請求分發給對應的pod。service會提供一個clusterIP。kube-proxy的做用主要是負責service的實現，具體來講，就是實現了內部請求到service和外部的從node port向service的訪問，轉發到後端某個pod。

舉個例子，如今有podA，podB，podC和serviceAB。serviceAB是podA，podB的服務抽象(service)。那麼kube-proxy的做用就是能夠將某一個發往（如podC發起的請求）向serviceAB的請求，進行轉發到service所表明的一個具體pod(podA或者podB)上。請求的分配方法通常分配是採用輪詢方法進行分配。

kube-proxy提供了三種負載均衡器（LB）模式: 一種是基於用戶態的模式userspace, 一種是iptables模式，一種是ipvs模式。

• userspace：是以socket的方式實現代理的，userspace這種模式最大的問題是，service的請求會先從用戶空間進入內核iptables，而後再回到用戶空間，由kube-proxy完成後端Endpoints的選擇和代理工做，這樣流量從用戶空間進出內核帶來的性能損耗是不可接受的；
• iptables mode：由於使用iptable NAT來完成轉發，也存在不可忽視的性能損耗。另外，若是集羣中存在上萬的Service/Endpoint，那麼Node上的iptables rules將會很是龐大，性能還會再打折扣；
• IPVS 模式：工做原理其實跟 iptables 模式相似，當咱們建立了前面的Service 以後，kube-proxy首先會在宿主機上建立一個虛擬網卡（kube-ipvs0）併爲他分配service VIP做爲IP地址，kube-proxy會經過linux的IPVS模塊爲這個IP設置三個虛擬主機（後端的三個POD IP），使用輪詢做爲LB策略（ipvsadm命令查看），IPVS模塊會負責請求的轉發。

  如下截圖來自於極客時間張磊的課程描述：

  iptables模式和ipvs模式的對比

服務暴露方式

http://dockone.io/article/4884

NodePort

NodePort服務是引導外部流量到你的服務的最原始方式。能夠經過訪問集羣內的每一個NodeIP:NodePort的方式，訪問到對應Service後端的Endpoint。在全部節點（虛擬機）上開放一個特定端口，任何發送到該端口的流量都被轉發到對應服務。

NodePort 服務的 YAML 文件相似以下：

apiVersion: v1
kind: Service
metadata:  
  name: my-nodeport-service
selector:    
  app: my-app
spec:
  type: NodePort
  ports:  
  - name: http
    port: 80
    targetPort: 80
    nodePort: 30036
    protocol: TCP

NodePort 服務主要有兩點區別於普通的「ClusterIP」服務。第一，它的類型是「NodePort」。有一個額外的端口，稱爲 nodePort，它指定節點上開放的端口值。若是你不指定這個端口，系統將選擇一個隨機端口。

什麼時候使用這種方式？

這種方法有許多缺點：

• 每一個端口只能是一種服務
• 端口範圍只能是 30000-32767
• 若是節點/VM 的 IP 地址發生變化，你須要能處理這種狀況。

基於以上緣由，我不建議在生產環境上用這種方式暴露服務。若是你運行的服務不要求一直可用，或者對成本比較敏感，你可使用這種方法。這樣的應用的最佳例子是 demo 應用，或者某些臨時應用。

hostNetwork

這種方式在建立pod時的yaml中spec.hostNetwork: true指定走主機網絡，這種方式pod使用的端口必須是宿主機上沒有被佔用的端口。外部能夠直接經過pod所在宿主機IP:Pod端口訪問。

LoadBalancer

這也是用來對集羣外暴露服務的，不一樣的是這須要雲服務商的支持，好比亞馬遜等。這個方式的最大缺點是每個用 LoadBalancer 暴露的服務都會有它本身的 IP 地址，每一個用到的 LoadBalancer 都須要付費，這是很是昂貴的。

Ingress

ingress配置一種路由轉發規則，ingress controller會根據ingress中的規則，生成路由轉發配置。如nginx-ingress-controller，控制循環會檢測ingress對象的添加，經過其規則和service、pod信息生成nginx的配置，經過nginx實現對外服務和負載均衡。

pod建立流程

一、客戶端提交建立請求，經過API Server的Restful API，或者用kubectl命令行工具。支持的數據類型包括JSON和YAML。

二、API Server處理用戶請求，存儲Pod數據到etcd。

三、kube-scheduler經過API Server查看未綁定的Pod。嘗試爲Pod分配主機。

四、kube-scheduler經過預選算法過濾掉不符合要求的主機。好比Pod指定了所須要的資源量，那麼可用資源比Pod須要的資源量少的主機會被過濾掉，端口被佔用的也被過濾掉；

五、kube-scheduler經過優選算法給主機打分，對預選篩選出的符合要求的主機進行打分，在主機打分階段，調度器會考慮一些總體優化策略，好比把一個deployment類型的pod分佈到不一樣的主機上，使得資源均衡；或者將兩個親和的服務分配到同一個主機上。

六、選擇主機：選擇打分最高的主機，進行binding（調用apiserver將pod和node綁定）操做，結果存儲到etcd中。

七、kubelet監聽Api Server，根據調度結果執行Pod建立操做：綁定成功後，scheduler會調用API Server的API在etcd中建立一個bound pod對象，描述在一個工做節點上綁定運行的全部pod信息。運行在每一個工做節點上的kubelet也會按期與etcd同步bound pod信息，一旦發現應該在該工做節點上運行的bound pod對象沒有更新，則調用Docker API建立並啓動pod內的容器。

八、kubelet調用CNI（Docker 運行或經過 rkt)運行 Pod 的容器。並週期性的對容器生命週期進行探測。（健康檢查readness-隔離、liveness-重啓）

---

各組件基本都是經過API Server提供的list-watch API進行監聽資源對象變化，進行本身的控制循環，這些核心功能都被封裝到了client-go包中。咱們能夠根據本身的需求，經過CRD編寫controller、operator進行本身的控制循環邏輯、運維自動化部署，很輕鬆的擴展k8s能力。

---

---

---

本公衆號免費提供csdn下載服務，海量IT學習資源，若是你準備入IT坑，勵志成爲優秀的程序猿，那麼這些資源很適合你，包括但不限於java、go、python、springcloud、elk、嵌入式 、大數據、面試資料、前端 等資源。同時咱們組建了一個技術交流羣，裏面有不少大佬，會不定時分享技術文章，若是你想來一塊兒學習提升，能夠公衆號後臺回覆【2】，免費邀請加技術交流羣互相學習提升，會不按期分享編程IT相關資源。

---

掃碼關注，精彩內容第一時間推給你