Kubectl

驗(yàn)證和生成器

• 具有 --restart-policy=Always 的資源被視為 Deployment；
• 具有 --restart-policy=OnFailure 的資源被視為 Job；
• 具有 --restart-policy=Never 的資源被視為 Pod。

API Group 和版本協(xié)商

客戶端驗(yàn)證

• 如果指定參數(shù) --kubeconfig，那么采用該值；
• 如果指定環(huán)境變量 $KUBECONFIG，那么采用該值；
• 否則查看默認(rèn)的目錄，如 ~/.kube，并使用找到的第一個(gè)文件。

• x509 證書使用 tls.TLSConfig 發(fā)送（包括 CA 證書）；
• bearer tokens 在 HTTP 請(qǐng)求頭 Authorization 中發(fā)送；
• 用戶名和密碼通過(guò) HTTP 基礎(chǔ)認(rèn)證發(fā)送；
• OpenID 認(rèn)證過(guò)程是由用戶事先手動(dòng)處理的，產(chǎn)生一個(gè)像 bearer token 一樣被發(fā)送的 token。

kube-apiserver

認(rèn)證

• 如果指定參數(shù) --client-ca-file，它會(huì)把 x509 authenticator 添加到列表中；
• 如果指定參數(shù) --token-auth-file，它會(huì)把 token authenticator 添加到列表中。

• x509 handler 會(huì)驗(yàn)證 HTTP 請(qǐng)求是否是通過(guò) CA 根證書簽名的 TLS 密鑰編碼的；
• bearer token handler 會(huì)驗(yàn)證 HTTP Authorization header 指定的 token 是否存在于 --token-auth-file 參數(shù)提供的 token 文件中；
• basicauth handler 會(huì)簡(jiǎn)單驗(yàn)證 HTTP 請(qǐng)求的基本身份憑據(jù)。

授權(quán)

• webhook：與集群外的 HTTP(S) 服務(wù)交互；
• ABAC：執(zhí)行靜態(tài)文件中定義的策略；
• RBAC：執(zhí)行由集群管理員添加為 K8s 資源的 RBAC 規(guī)則；
• Node：確保 Kubelet 只能訪問(wèn)自己節(jié)點(diǎn)上的資源。

Admission Controller

etcd

• 當(dāng)運(yùn)行 kube-apiserver 二進(jìn)制文件時(shí)，它會(huì)創(chuàng)建一個(gè)服務(wù)鏈，允許 apiserver 聚合。這是一種支持多 apiserver 的方式；
• 之后，它會(huì)創(chuàng)建一個(gè)用作默認(rèn)實(shí)現(xiàn)的 generic apiserver；
• 使用生成的 OpenAPI scheme 填充 apiserver 配置；
• 然后，kube-apiserver 遍歷 scheme 中指定的所有 API Group， 并為其構(gòu)造 storage provider。當(dāng)你訪問(wèn)或變更資源狀態(tài)時(shí)， kube-apiserver 就會(huì)調(diào)用這些 API Group；
• 對(duì)于每個(gè) API Group， 它還會(huì)迭代每個(gè)組版本，并為每個(gè) HTTP 路由安裝 REST 映射。這允許 kube-apiserver 映射請(qǐng)求，并且一旦找到匹配就能夠委托給正確的代碼邏輯；
• 對(duì)于本文的特定用例，將注冊(cè)一個(gè) POST handler，該處理程序?qū)⑽薪o create resource handler。

• 如果程序處理鏈可以將請(qǐng)求與注冊(cè)的路由匹配，它會(huì)將該請(qǐng)求交給注冊(cè)到該路由的 dedicated handler。否則它會(huì)回退到 path-based handler（這是調(diào)用 /apis 時(shí)會(huì)發(fā)生的情況）。如果沒(méi)有為該路由注冊(cè)處理程序，則會(huì)調(diào)用 not found handler，最終返回 404；
• 幸運(yùn)的是，我們有一個(gè)處理器名為 createHandler！它有什么作用？它將首先解碼 HTTP 請(qǐng)求并執(zhí)行基礎(chǔ)驗(yàn)證，例如確保請(qǐng)求提供的 JSON 與我們的版本化 API 資源匹配；
• 審計(jì)和準(zhǔn)入控制階段；
• 之后，資源會(huì)通過(guò) storage provider 存儲(chǔ)到 etcd 中。默認(rèn)情況下，保持到 etcd 的鍵的格式為 /，當(dāng)然，它也支持自定義；
• 資源創(chuàng)建過(guò)程中出現(xiàn)的任何錯(cuò)誤都會(huì)被捕獲，最后 storage provider 會(huì)執(zhí)行 get 調(diào)用來(lái)確認(rèn)該資源是否被成功創(chuàng)建。如果需要額外的清理工作（finalization），就會(huì)調(diào)用后期創(chuàng)建的處理器和裝飾器；
• 最后，構(gòu)造 HTTP 響應(yīng)并返回給客戶端。

控制循環(huán)

Deployment Controller

ReplicaSet Controller

• 父資源被刪除，但子資源沒(méi)有被刪除；
• 垃圾收集策略禁止刪除子資源。

Informers

Scheduler

• 當(dāng) Scheduler 啟動(dòng)時(shí)，會(huì)注冊(cè)一系列默認(rèn)的預(yù)選策略，這些預(yù)選策略會(huì)對(duì)候選節(jié)點(diǎn)進(jìn)行評(píng)估，判斷候選節(jié)點(diǎn)是否滿足候選 Pod 的需求。例如，如果 PodSpec 顯式地限制了 CPU 和內(nèi)存資源，并且節(jié)點(diǎn)的資源容量不滿足候選 Pod 的需求時(shí)，Pod 就不會(huì)被調(diào)度到該節(jié)點(diǎn)上（資源容量 = 節(jié)點(diǎn)資源總量 - 節(jié)點(diǎn)中已運(yùn)行的容器需求資源總和）；
• 一旦選擇了適當(dāng)?shù)墓?jié)點(diǎn)，就會(huì)對(duì)剩余的節(jié)點(diǎn)運(yùn)行一系列優(yōu)先級(jí)函數(shù)，以對(duì)候選節(jié)點(diǎn)進(jìn)行打分。例如，為了在整個(gè)系統(tǒng)中分散工作負(fù)載，它將偏好于資源請(qǐng)求較少的節(jié)點(diǎn)（因?yàn)檫@表明運(yùn)行的工作負(fù)載較少）。當(dāng)它運(yùn)行這些函數(shù)時(shí)，它為每個(gè)節(jié)點(diǎn)分配一個(gè)成績(jī)，然后選擇分?jǐn)?shù)最高的節(jié)點(diǎn)進(jìn)行調(diào)度。

• 將 NodeName 的值設(shè)置為 Binding 對(duì)象 ObjectReference 中的 NodeName；
• 添加相關(guān)的注釋（annotations）；
• 將 PodScheduled 的 status 設(shè)置為 True。

Kubelet

Pod Sync

• HTTP 請(qǐng)求通過(guò)了認(rèn)證、授權(quán)和準(zhǔn)入控制階段；
• 一個(gè) Deployment、ReplicaSet 和三個(gè) Pod 被持久化到 etcd；
• 最后每個(gè) Pod 都被調(diào)度到合適的節(jié)點(diǎn)。

• 如果 Pod 正在創(chuàng)建， Kubelet 就會(huì)暴露一些指標(biāo)，可以用于在 Prometheus 中追蹤 Pod 啟動(dòng)延時(shí)；
• 
  然后，生成一個(gè) PodStatus 對(duì)象，表示 Pod 當(dāng)前階段的狀態(tài)。Pod 的 Phase 狀態(tài)是 Pod 在其生命周期中的高度概括，包括 Pending、Running、Succeeded、Failed 和 Unkown 這幾個(gè)值。狀態(tài)的產(chǎn)生過(guò)程非常復(fù)雜，因此很有必要深入深挖一下：
  
  • 首先，串行執(zhí)行一系列 PodSyncHandlers，每個(gè)處理器檢查 Pod 是否應(yīng)該運(yùn)行在該節(jié)點(diǎn)上。當(dāng)其中之一的處理器認(rèn)為該 Pod 不應(yīng)該運(yùn)行在該節(jié)點(diǎn)上，則 Pod 的 Phase 值就會(huì)變成 PodFailed 并將從該節(jié)點(diǎn)被驅(qū)逐。例如，以 Job 為例，當(dāng)一個(gè) Pod 失敗重試的時(shí)間超過(guò)了 activeDeadlineSeconds 設(shè)置的值，就會(huì)將該 Pod 從該節(jié)點(diǎn)驅(qū)逐出去
  • 接下來(lái)，Pod 的 Phase 值由 init 容器和主容器狀態(tài)共同決定。由于主容器尚未啟動(dòng)，容器被視為處于等待階段，如果 Pod 中至少有一個(gè)容器處于等待階段，則其 Phase 值為 Pending
  • 最后，Pod 的 Condition 字段由 Pod 內(nèi)所有容器狀態(tài)決定?，F(xiàn)在我們的容器還沒(méi)有被容器運(yùn)行時(shí) (Container Runtime) 創(chuàng)建，所以，Kubelet 將 PodReady 的狀態(tài)設(shè)置為 False
• 
  生成 PodStatus 之后，Kubelet 就會(huì)將它發(fā)送到 Pod 的 status 管理器，該管理器的任務(wù)是通過(guò) apiserver 異步更新 etcd 中的記錄；
• 接下來(lái)運(yùn)行一系列 admit handlers 以確保該 Pod 具有正確的權(quán)限（包括強(qiáng)制執(zhí)行 AppArmor profiles 和 NO_NEW_PRIVS），在該階段被拒絕的 Pod 將永久處于 Pending 狀態(tài)；
• 如果 Kubelet 啟動(dòng)時(shí)指定了 cgroups-per-qos 參數(shù)，Kubelet 就會(huì)為該 Pod 創(chuàng)建 cgroup 并設(shè)置對(duì)應(yīng)的資源限制。這是為了更好的 Pod 服務(wù)質(zhì)量（QoS）；
• 
  為 Pod 創(chuàng)建相應(yīng)的數(shù)據(jù)目錄，包括：
  
  • Pod 目錄（通常是 /var/run/kubelet/pods/）
  • Pod 的掛載卷目錄（/volumes）
  • Pod 的插件目錄（/plugins）
• 
  卷管理器會(huì)掛載 Spec.Volumes 中定義的相關(guān)數(shù)據(jù)卷，然后等待掛載成功；
• 從 apiserver 中檢索 Spec.ImagePullSecrets，然后將對(duì)應(yīng)的 Secret 注入到容器中；
• 最后，通過(guò)容器運(yùn)行時(shí) （Container Runtime） 啟動(dòng)容器（下面會(huì)詳細(xì)描述）。

CRI 和 pause 容器

CNI 和 Pod 網(wǎng)絡(luò)

{
'cniVersion': '0.3.1',
'name': 'bridge',
'type': 'bridge',
'bridge': 'cnio0',
'isGateway': true,
'ipMasq': true,
'ipam': {
    'type': 'host-local',
    'ranges': [
      [{'subnet': '${POD_CIDR}'}]
    ],
    'routes': [{'dst': '0.0.0.0/0'}]
}
} 

• 該插件首先會(huì)在 Root Network Namespace（也就是宿主機(jī)的 Network Namespace） 中設(shè)置本地 Linux 網(wǎng)橋，以便為該主機(jī)上的所有容器提供網(wǎng)絡(luò)服務(wù)；
• 然后將一個(gè)網(wǎng)絡(luò)接口 （veth 設(shè)備對(duì)的一端）插入到 pause 容器的 Network Namespace 中，并將另一端連接到網(wǎng)橋上。你可以這樣來(lái)理解 veth 設(shè)備對(duì)：它就像一根很長(zhǎng)的管道，一端連接到容器，一端連接到 Root Network Namespace 中，允許數(shù)據(jù)包在中間傳輸；
• 
  之后，為 pause 容器的網(wǎng)絡(luò)接口分配一個(gè) IP 并設(shè)置相應(yīng)的路由，于是 Pod 就有了自己的 IP。IP 的分配是由 JSON 配置文件中指定的 IPAM Plugin 實(shí)現(xiàn)的；
  
  • IPAM Plugin 的工作方式和 CNI 插件類似：通過(guò)二進(jìn)制文件調(diào)用并具有標(biāo)準(zhǔn)化的接口，每一個(gè) IPAM Plugin 都必須要確定容器網(wǎng)絡(luò)接口的 IP、子網(wǎng)以及網(wǎng)關(guān)和路由，并將信息返回給 CNI 插件。最常見(jiàn)的 IPAM Plugin 稱為 host-local，它從預(yù)定義的一組地址池為容器分配 IP 地址。它將相關(guān)信息保存在主機(jī)的文件系統(tǒng)中，從而確保了單個(gè)主機(jī)上每個(gè)容器 IP 地址的唯一性。
• 
  對(duì)于 DNS， Kubelet 將為 CNI 插件指定 Kubernetes 集群內(nèi)部 DNS 服務(wù)器 IP 地址，確保正確設(shè)置容器的 resolv.conf 文件。

跨主機(jī)容器網(wǎng)絡(luò)

啟動(dòng)容器

• 拉取容器的鏡像。如果是私有倉(cāng)庫(kù)的鏡像，就會(huì)使用 PodSpec 中指定的 Secret 來(lái)拉取該鏡像；
• 通過(guò) CRI 創(chuàng)建容器。Kubelet 使用 PodSpec 中的信息填充了 ContainerConfig 數(shù)據(jù)結(jié)構(gòu)（在其中定義了 command、image、labels、mounts、devices、environment variables 等），然后通過(guò) protobufs 發(fā)送給 CRI。對(duì)于 Docker 來(lái)說(shuō)，它會(huì)將這些信息反序列化并填充到自己的配置信息中，然后再發(fā)送給 Dockerd 守護(hù)進(jìn)程。在這個(gè)過(guò)程中，它會(huì)將一些元數(shù)據(jù)（例如容器類型、日志路徑、sandbox ID 等）添加到容器中；
• 然后 Kubelet 將容器注冊(cè)到 CPU 管理器，它通過(guò)使用 * UpdateContainerResources CRI 方法給容器分配給本地節(jié)點(diǎn)上的 CPU 資源；
• 最后容器真正啟動(dòng)；
• 如果 Pod 中包含 Container Lifecycle Hooks，容器啟動(dòng)之后就會(huì)運(yùn)行這些 Hooks。Hook 的類型包括兩種：Exec（執(zhí)行一段命令） 和 HTTP（發(fā)送 HTTP 請(qǐng)求）。如果 PostStart Hook 啟動(dòng)的時(shí)間過(guò)長(zhǎng)、掛起或者失敗，容器將永遠(yuǎn)不會(huì)變成 Running 狀態(tài)。

Wrap-up