kubelet 的工作核心，就是一個控制循環SyncLoop，驅動這個控制循環運行的事件，包括四種：

1.Pod?更新事件

2.Pod?生命周期變化

3.kubelet?本身設置的執行周期

4.定時的清理事件

kubelet 還負責維護著很多其他的子控制循環，比如 Volume Manager、Image Manager、Node Status Manager 等等，這些控制循環的責任，就是通過控制器模式，完成 kubelet 的某項具體職責。

例如：Node Status Manager，就負責響應 Node 的狀態變化，然后將 Node 的狀態收集起來，并通過 Heartbeat 的方式上報給 APIServer。CPU Manager，就負責維護該 Node 的 CPU 核的信息，以便在 Pod 通過 cpuset 的方式請求 CPU 核的時候，能夠正確地管理 CPU 核的使用量和可用量。

kubelet 通過 Watch 機制，監聽了與自己相關的 Pod 對象的變化：

這個 Watch 的過濾條件是該 Pod 的 nodeName 字段與自己相同，kubelet 會把這些 Pod 的信息緩存在自己的內存里。

當一個 Pod 完成調度、與一個 Node 綁定起來之后， 這個 Pod 的變化就會觸發 kubelet 在控制循環里注冊的 Handler，也就是上圖中的 HandlePods 部分。

通過檢查該 Pod 在 kubelet 內存里的狀態，kubelet 就能夠判斷出這是一個新調度過來的 Pod，從而觸發 Handler 里 ADD 事件對應的處理邏輯。（備注：在具體的處理過程當中，kubelet 會啟動一個名叫 Pod Update Worker 的、單獨的 Goroutine 來完成對 Pod 的處理工作。）

CRI是Container Runtime Interface（容器運行時接口）的簡寫，CRI解耦了kubelet與容器運行時，讓kubelet無需重新編譯就可以支持多種容器運行時，kubelet將通過CRI接口來跟第三方容器運行時進行通信，來操作容器與鏡像。實現了 CRI 接口的容器運行時通常稱為 CRI shim， 這是一個 gRPC Server，監聽在本地的 unix socket ?上；而 kubelet 作為 gRPC 的客戶端來調用 CRI 接口，來進行Pod ?和容器、鏡像的生命周期管理。另外，容器運行時需要自己負責管理容器的網絡，推薦使用 CNI。

CAdvisor

集成在 Kubelet 中的容器監控工具，用于收集本節點和容器的監控信息。

oomWatcher

kubelet的oomwatcher從cadvisor監聽事件，如果出現了system oom則記錄一個event事件。 對于容器的oom狀態，k8s使用docker的狀態State.OOMKilled判斷是否經歷oom事件。

GCManager

垃圾回收是 kubelet 的一個有用功能，它將清理未使用的鏡像和容器。 Kubelet 將每分鐘對容器執行一次垃圾回收，每五分鐘對鏡像執行一次垃圾回收。

不建議使用外部垃圾收集工具，因為這些工具可能會刪除原本期望存在的容器進而破壞 kubelet 的行為。

CPUManager

默認情況下，kubelet 使用CFS配額來執行 Pod 的 CPU 約束。 當節點上運行了很多 CPU 密集的 Pod 時，工作負載可能會遷移到不同的 CPU 核， 這取決于調度時 Pod 是否被扼制，以及哪些 CPU 核是可用的。 許多工作負載對這種遷移不敏感，因此無需任何干預即可正常工作。

ProberManager

ProberManager 實現對容器的健康檢查。目前有三種 probe 探針：

liveness: 讓Kubernetes知道你的應用程序是否健康，如果你的應用程序不健康，Kubernetes將刪除Pod并啟動一個新的替換它（與RestartPolicy有關）。Liveness 探測可以告訴 Kubernetes 什么時候通過重啟容器實現自愈。

readiness: readiness與liveness原理相同，不過Readiness探針是告訴 Kubernetes 什么時候可以將容器加入到 Service 負載均衡中，對外提供服務。

startupProbe：1.16開始支持的新特性,檢測慢啟動容器的狀態。

Kubelet 定期調用容器中的探針來診斷容器的健康狀況。 包含如下三種實現方式：

ExecAction：在容器內部執行一個命令，如果該命令的退出狀態碼為 0，則表明容器健康；

TCPSocketAction：通過容器的 IP 地址和端口號執行 TCP 檢查，如果端口能被訪問，則表明容器健康；

HTTPGetAction：通過容器的 IP 地址和端口號及路徑調用 HTTP GET 方法，如果響應的狀態碼大于等于 200 且小于 400，則認為容器狀態健康。

StatusManager

StatusManager 的主要功能是將 pod 狀態信息同步到 apiserver，statusManage 并不會主動監控 pod 的狀態，而是提供接口供其他 manager 進行調用。比如 probeManager。probeManager 會定時去監控 pod 中容器的健康狀況，一旦發現狀態發生變化，就調用 statusManager 提供的方法更新 pod 的狀態。

EvictionManager

EvictionManager 會監控資源的使用情況，并使用驅逐機制防止計算和存儲資源耗盡。

VolumeManager

volumeManager通過actualStateOfWorld和desiredStateOfWorld來表明當前的volume掛載狀態和期望的volume掛載狀態。然后由desiredStateOfWorldPopulator維護desireedStateOfWorld和podManager的一致性；由reconcile維護actualStateOfWorld和desiredStateOfWorld的一致性及磁盤volume掛載和actualStateOfWorld的一致性。通過這些機制，volumeManager完成了volume掛載生命周期的管理。

PluginManager

PluginManager 可以用將系統硬件資源發布到kubelet。

podworker，其功能就是處理當前節點被調度pod的聲明周期的，也就是說你建了一個pod，然后調度器將這個pod調度到某個節點上面了，那么kubelet就需要去工作了，它的工作就是啟動這個pod，用容器運行時去啟動，也就是將進程拉起來，放到某個namespace下面去，通過cgroup對資源做限制，通過網絡插件將網絡配置好。

kubectl

常用命令格式

創建：kubectl run <name> --image=<image> 或者 kubectl create -f manifest.yaml

查詢：kubectl get <resource>

更新 kubectl set 或者 kubectl patch

刪除：kubectl delete <resource> <name> 或者 kubectl delete -f manifest.yaml

查詢 Pod IP：kubectl get pod <pod-name> -o jsonpath='{.status.podIP}'

容器內執行命令：kubectl exec -ti <pod-name> sh

容器日志：kubectl logs [-f] <pod-name>

導出服務：kubectl expose deploy <name> --port=80

自定義輸出列

比如，查詢所有 Pod 的資源請求和限制：

Kubectl?get pods --all-namespaces -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,"CPU(requests)":.spec.containers[*].resources.requests.cpu,"CPU(limits)":.spec.containers[*].resources.limits.cpu,"MEMORY(requests)":.spec.containers[*].resources.requests.memory,"MEMORY(limits)":.spec.containers[*].resources.limits.memory

日志查看

# Return snapshot logs from pod nginx with only one container

kubectl logs nginx

# Return snapshot of previous terminated ruby container logs from pod web-1

kubectl logs -p -c ruby web-1

# Begin streaming the logs of the ruby container in pod web-1

kubectl logs -f -c ruby web-1

連接到一個正在運行的容器

kubectl attach 123456-7890 -c ruby-container -i -t

在容器內部執行命令

# Get output from running 'date' from pod 123456-7890, using the first container by default

??kubectl exec 123456-7890 date

??# Get output from running 'date' in ruby-container from pod 123456-7890

??kubectl exec 123456-7890 -c ruby-container date

??# Switch to raw terminal mode, sends stdin to 'bash' in ruby-container from pod 123456-7890

??# and sends stdout/stderr from 'bash' back to the client

??kubectl exec 123456-7890 -c ruby-container -i -t -- bash -il

Options:

??-c, --container='': Container name. If omitted, the first container in the pod will be chosen

??-p, --pod='': Pod name

??-i, --stdin=false: Pass stdin to the container

??-t, --tty=false: Stdin is a TT

端口轉發

kubectl patch

kubectl get?pv,pvc -o wide

kubectl get pod,svc,ingress

Kubernetes Service ?定義了這樣一種抽象：一個 ?Pod ?的邏輯分組，一種可以訪問它們的策略 —— 通常稱為微服務。 這一組 ?Pod ?能夠被 ?Service ?訪問到，通常是通過 ?Label Selector

Service 在 K8s 中有以下四種類型

1.ClusterIp：默認類型，自動分配一個僅 Cluster 內部可以訪問的虛擬 IP

2.NodePort：在 ClusterIP 基礎上為 Service 在每臺機器上綁定一個端口，這樣就可以通過 : NodePort 來訪問該服務

3.LoadBalancer：在 NodePort 的基礎上，借助 cloud provider 創建一個外部負載均衡器，并將請求轉發到: NodePort

4.ExternalName：把集群外部的服務引入到集群內部來，在集群內部直接使用。沒有任何類型代理被創建，這只有 kubernetes 1.7 或更高版本的 kube-dns 才支持

apiVersion: v1

kind: Service

metadata:

??name: my-service

spec:

??selector:

????app: MyApp

??ports:

????- protocol: TCP

??????port: 80

??????targetPort: 9376

上述配置創建一個名稱為 “my-service” 的?Service?對象，它會將請求代理到使用 TCP 端口 9376，并且具有標簽?"app=MyApp"?的?Pod?上。 Kubernetes 為該服務分配一個 IP 地址（有時稱為 “集群IP” ），該 IP 地址由服務代理使用。

endpoint

Endpoint是kubernetes中的一個資源對象，存儲在etcd中，用來記錄一個service對應的所有pod的訪問地址，它是根據service配置文件中selector描述產生的。

????一個service由一組pod組成，這些pod通過Endpoint暴露出來，Endpoints是實現實際服務的端點集合。換句話說，service和pod之間的聯系是通過endpoints實現的。

kube-proxy 目前支持三種工作模式：userspace、iptables、ipvs

userspace模式下，kube-proxy會為每一個Service創建一個監聽端口，發向Cluster IP的請求被Iptables規則重定向到kube-proxy監聽的端口上，kube-proxy根據LB算法選擇一個提供服務的pod并和其建立鏈接，以將請求轉發到Pod上。

該模式下，kube-proxy充當了一個四層負責均衡器的角色，由于kube-proxy運行在userspace中，在進行轉發處理時會增加內核和用戶空間之間的數據拷貝，雖然比較穩定，但是效率比較低。

iptables模式下，kube-proxy為service后端的每個Pod創建對應的iptables規則，直接將發向Cluster IP的請求重定向到一個Pod IP。

?該模式下，kube-proxy不承擔四層負責均衡器的角色，只負責創建iptables規則。該模式的優點是較userspace模式效率更高，但不能提供靈活的LB策略，當后端Pod不可用時也無法進行重試。

pvs模式和iptables模式類似，kube-proxy監控Pod的變化并創建相應的ipvs規則，ipvs相對iptables轉發效率更高。除此之外，ipvs支持更多的LB算法。

Kubernetes Controller內擁有許多的控制器類型，用來控制pod的狀態、行為、副本數量等等，控制器通過Pod的標簽來控制Pod ，從而實現對應用的運維，如伸縮、升級等。

常用的控制器類型如下：

ReplicationController 、ReplicaSet、Deployment：無狀態服務，保證在任意時間運行Pod指定的副本數量，能夠保證Pod總是可用的，支持滾動更新、回滾。典型用法：web服務。

DaemonSet：確保集群內全部（或部分）node節點上都分配一個pod，如果新加node節點，也會自動再分配對應的pod。典型用法：filebeat日志收集、prometheus資源監控。

StatefulSet：有狀態服務，如各種數據存儲系統。StatefullSet內的服務有著穩定的持久化存儲和網絡標識，有序部署，有序伸縮。

Job：只運行一次的作業。

CronJob：周期性運行的作業。典型用法：數據庫定時備份。

Horizontal Pod Autoscaling（HPA）：按照期望的pod的cpu或內存來自動伸縮pod數量。

Pod是通過Controller實現應用的運維，比如彈性伸縮，滾動升級等

Pod 和 Controller之間是通過label標簽來建立關系，同時Controller又被稱為控制器工作負載

Scheduler是 Kubernetes 的調度器，屬于核心組件，主要的任務是把定義的 Pod 分配到集群的節點上，聽起來非常簡單，但是有很多要考慮的問題：

公平：如果保證每個節點都能被分配資源

資源高效利用： 集群所有資源最大化被使用

效率：調度的性能更好，能夠盡快地對大批量的 Pod 完成調度工作

靈活：允許用戶根據自己的需求控制調度的邏輯

Scheduler 提供的調度流程分為預選 (Predicates) 和優選 (Priorities) 兩個步驟：

預選，K8S會遍歷當前集群中的所有?Node，篩選出其中符合要求的 Node 作為候選

優選，K8S將對候選的 Node 進行打分

第一階段：預選

預選的作用，是找到滿足條件的節點，如具有SSD硬盤，系統內存大于某個值，去掉不滿足條件的節點。以下是幾個比較重要的策略：

防止過度提交

反親和

親和

污染和容忍

第二階段：優選

預選可能找到多個滿足條件的node, 優選階段將按照一些規則對其進行打分并匯總，打分高者最后會被選中。以下是幾個優選的策略：

節點漫延

反親和

親和

打分后線性相加，得到最后的總分，分高的node將會被選中。

現在再來看 Kubernetes 從一開始就提供的東西：描述各種資源需求的標準 API。例如，

描述 pod、container 等計算需求?的 API；

描述 service、ingress 等虛擬網絡功能?的 API；

描述 volumes 之類的持久存儲?的 API；

甚至還包括 service account 之類的服務身份?的 API 等等。

用戶創建一個資源分兩個步驟：

第一步是將對應請求發送給apiserver，通過apiserver把對應資源定義的信息存放在etcd中；第二個步驟是對應資源類型的控制器通過apiserver從etcd中讀取對應資源的定義，將其創建出來

k8s上，資源的類型有很多，比如pod，service，PersistentVolume，PersistentVolumeClaim等等，這些都是一些基礎的資源類型

k8s上擴展資源類型的方式有三種

第一種是crd，crd是k8s內建的資源類型，該類型資源主要用來創建用戶自定義資源類型的資源；即通過crd資源，可以將用戶自定義資源類型轉換為k8s上資源類型；

第二種是自定義apiserver；這種方式要比第一種方式要復雜一點，需要用戶手動開發程序實現對應功能的apiserver，讓其用戶創建自定義類型資源能夠通過自定義apiserver實現；

第三種方式就是修改現有k8sapiserver，讓其支持對應用戶自定義資源類型

自定義控制器

　　自定義資源類型我們可以使用crd資源實現，也可以使用自定義apiserver或修改原有apiserver代碼實現

自定義控制器也是同樣的邏輯，使用自定義控制器的目的也是讓對應自定義類型資源能夠被自定義控制器監聽，一旦對應資源發生變動，它能夠將其在k8s上創建出來，并一直保持和用戶期望的狀態吻合；自定義控制器和自定義資源類型可以分開實現，也可以合并在一起實現，即自定義控制器程序能夠自動創建crd資源，讓其對應自定義類型資源能夠被k8s識別并將其創建出來；具體是分開實現還是合并在一起實現，取決開發自定義控制器程序員

crd資源是k8s上的標準資源之一，它的定義主要有apiVersion，kind，metadata，spec和status；其中kind類型為CustomResourceDefinition，apiVersion是apiextensions.k8s.io/v1；這兩個是固定格式；spec字段是用來定義對應指定資源類型資源的相關屬性

CRD：用來聲明用戶的自定義資源，例如它是 namespace-scope 還是 cluster-scope 的資源、有哪些字段等等，K8s 會自動根據這個定義生成相應的 API；

CRD 是資源類型定義，具體的資源叫 CR。

Operator 框架：“operator” 在這里的字面意思是“承擔運維任務的程序”， 它們的基本邏輯都是一樣的：時刻盯著資源狀態，一有變化馬上作出反應（也就是 reconcile 邏輯）。

控制器的目的是讓 CRD 定義的資源達到我們預期的一個狀態，要達到我們定義的狀態，我們需要監聽觸發事件。觸發事件的概念是從硬件信號產生?中斷?的機制衍生過來的，

其產生一個電平信號時，有水平觸發（包括高電平、低電平），也有邊緣觸發（包括上升沿、下降沿觸發等）。

水平觸發 : 系統僅依賴于當前狀態。即使系統錯過了某個事件（可能因為故障掛掉了），當它恢復時，依然可以通過查看信號的當前狀態來做出正確的響應。

邊緣觸發 : 系統不僅依賴于當前狀態，還依賴于過去的狀態。如果系統錯過了某個事件（“邊緣”），則必須重新查看該事件才能恢復系統。

Kubernetes 的 API 和控制器都是基于水平觸發的，可以促進系統的自我修復和周期調協。

其 API 實現方式（也是我們常說的聲明式 API）是：控制器監視資源對象的實際狀態，并與對象期望的狀態進行對比，然后調整實際狀態，使之與期望狀態相匹配。

總結

以上是生活随笔為你收集整理的kubernetes基础组件原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。