目錄

一、pod的生命周期

二、創建 pod 的工作流程

三、ingres 有哪些組件并且描述出組件作用 ？

四、ingress 的工作原理

五、ingress 暴露服務的方式

六、pod 的組成

七、pod的本身性質（pod的種類與說明）

八、k8s命令

8.1在k8s中如何查看命名空間nanjing中的pod的IP

8.2k8s 中pod無法啟動怎么排查原因？

九、K8S 核心組件有哪些？功能是什么？

十、k8s 工作流程? （創建nginx 模版為例）

---

一、pod的生命周期

收到kubectl指令-->初始化容器（init container），生成文件(init可以有多個，但是不可以同時運行)-->創建容器成功-->start容器-->readnessProbe(就緒性探針：就緒檢測--> liveness Probe (存活性探針)：生存檢測-->stop容器?

① Pause 階段：當 Pod 中的容器被暫停時，Pod 會進入 Pause 階段。這通常發生在節點上發生調度變化時，為了確保容器狀態的一致性，Pod 會被暫停并且等待恢復。

② Init 階段：如果 Pod 中定義了 Init 容器，那么在主容器啟動之前，Init 容器會先啟動并執行其初始化任務。Pod 進入 Init 階段直到所有 Init 容器都成功完成。

③應用啟動階段：一旦所有的 Init 容器成功完成，主容器將會啟動并開始執行應用程序。

④ 存活階段：Pod 中的容器正在運行，并且沒有出現致命錯誤，此時 Pod 處于存活狀態。

⑤? 就緒階段：Pod 中的容器已經準備好接收流量。如果 Pod 中的所有容器都已經就緒，那么整個 Pod 就處于就緒狀態，可以開始接收請求。

二、創建 pod 的工作流程

kubectl ->auth -> apiserver?
apiserver -> etcd?
scheduler/controller manager watch apiserver （create pod 的事件）
shceduler 發送list 給apiserver -> etcd 獲取后端節點信息
以此來進行預選優選 -> 將結果返回給api-server?
controller 來一輪以上的
kubelet watch api-server 發現create Pod 創建事件，獲取創建pod所需資源與策略
kubelet 與cri 接口交互，調用docker 完成容器創建，并且調用控制器資源，完成Pod 創建?
kubelet 通過metrics 監控、采集本地節點的資源狀態信息 ——>周期性報告給api-server?
api-server 再將信息寫入etcd中

三、ingres 有哪些組件并且描述出組件作用 ？

Ingress 包含兩大組件：Ingress Controller 和 Ingress

• Ingress Controller 會根據定義的 Ingress 對象，提供對應的代理能力。業界常用的各種反向代理項目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已經為Kubernetes 專門維護了對應的 Ingress Controller
• ?Ingress 控制器不同于Deployment 控制器的是，Ingress控制器不直接運行為kube-controller-manager的一部分，它僅僅是Kubernetes集群的一個附件，類似于CoreDNS，需要在集群上單獨部署

四、ingress 的工作原理

• ingress-controller是接受用戶請求并且轉發，外界看ingress-controller是轉發給pod的，? ?其實并不是，而是轉發到service上面，他是通過讀取ingress-controller通過和 kubernetes APIServer 交互， ingress配置文件會保存在etcd當中并且ingress也配置定制了哪個域名發送到哪個service當中，
• 然后會生成一個nginx配置，并且他會寫入到運行的控制器的pod當中。在pod當中會實現nginx服務以及導入到nginx配置文件中nginx.conf
• ?然后reload加載，此時此刻控制器就知道了這個域名該轉發到哪個service---endpoints（里面是不是有很多端點），
• 然后再由我們的service請求轉到相應關聯操作的pod上面，所以說對外界來看是ingress來轉發的，實際上并不是，而是用戶把請求轉發給ingress-controller控制器， ?根據ingress的資源配置找到所對應的service? ，然后再由service轉發到pod

五、ingress 暴露服務的方式

• 方式一：Deployment+LoadBalancer 模式的 Service

如果要把ingress部署在公有云，那用這種方式比較合適。用Deployment部署ingress-controller，創建一個 type為 LoadBalancer 的 service 關聯這組 pod。大部分公有云，都會為 LoadBalancer 的 service 自動創建一個負載均衡器，通常還綁定了公網地址。 只要把域名解析指向該地址，就實現了集群服務的對外暴露

• 方式二：DaemonSet+HostNetwork+nodeSelector

用DaemonSet結合nodeselector來部署ingress-controller到特定的node上，然后使用HostNetwork直接把該pod與宿主機node的網絡打通，直接使用宿主機的80/433端口就能訪問服務。這時，ingress-controller所在的node機器就很類似傳統架構的邊緣節點，比如機房入口的nginx服務器。該方式整個請求鏈路最簡單，性能相對NodePort模式更好。缺點是由于直接利用宿主機節點的網絡和端口，一個node只能部署一個ingress-controller pod。 比較適合大并發的生產環境使用。

• 方式三：Deployment+NodePort模式的Service

同樣用deployment模式部署ingress-controller，并創建對應的service，但是type為NodePort。這樣，ingress就會暴露在集群節點ip的特定端口上。由于nodeport暴露的端口是隨機端口，一般會在前面再搭建一套負載均衡器來轉發請求。該方式一般用于宿主機是相對固定的環境ip地址不變的場景。
NodePort方式暴露ingress雖然簡單方便，但是NodePort多了一層NAT，在請求量級很大時可能對性能會有一定影響。

六、pod 的組成

① Pod 中有幾種容器
init 初始化 ，阻塞主容器運行，初始化后方可運行主容器
pause 基礎容器： 提供network 的 namespace 和 共享存儲
業務容器： 跑Pod 主應用?
（POD中跑什么：微服務、數據庫、監控、日志分析、mq、業務網關-類似Nginx的功能 SDK WSGI CGI等接口或協議的支持）

② Pod內網絡環境
共享形式，類似于docker-container 模式 ? 通過localhost 通訊

七、pod的本身性質（pod的種類與說明）

① 自主式pod:沒有自愈能力( Pod被刪除后不會重啟拉起新的pod）

② 控制器管理的pod:有自愈能力( Pod被刪除后會重啟拉起新的pod）

八、k8s命令

8.1在k8s中如何查看命名空間nanjing中的pod的IP

kubectl get pods -n nanjing -o wide

8.2k8s 中pod無法啟動怎么排查原因？

kubectl describe pod

kubectl logs

九、K8S 核心組件有哪些？功能是什么？

• api-server ：所有請求都經過該組件，負責整個K8S 集群的協調、交互
• scheduler ?：為集群資源提供指向調度能力，分為默認調度、節點標簽調度、親和反親和、污點容忍等調度方式
• etcd ?：記錄K8S集群中所有集群資源信息
• controller manager? ：負責控制器資源管理的組件
• kubelet? ：節點的核心代理?負責與api-server 交互（watch api-server的事件）具體執行于節點，并周期統計節點資源信息，返回給api-server?
• kube-proxy ：K8S 集群中L4負載均衡、反向代理的組件

十、k8s 工作流程? （創建nginx 模版為例）

• 首先要明確有kubernetes環境，然后啟動之后，master和node都會將自身的信息存儲到etcd數據庫中
• kubectl 首先創建命令 nginx服務 --> 他的安裝請求會到->auth（認證）-->?然后被發送到master節點的apiServer（資源操作的唯一入口）組件
• apiServer組件會調用scheduler組件(負責集群資源調度)來決定到底應該把這個服務安裝到哪個node節點上，在此時，它會從etcd中讀取各個node節點的信息，然后按照一定的算法進行選擇，并將結果告知apiServer
• apiServer調用controller-manager(負責維護集群的狀態)去調度Node節點安裝nginx服務
• kubelet(負責維護容器的生命周期)接收到指令后，會通知docker，然后由docker來啟動一個nginx的pod，pod是kubernetes的最小操作單元，容器必須跑在pod中至此，
• 一個nginx服務就運行了，如果需要訪問nginx，就需要通過kube-proxy(負責提供集群內部的服務發現和負載均衡)來對pod產生訪問的代理