Kubernetes基礎學習

Kubernetes核心組件

Kubernetes核心組件如下：

Kubernetes Master部分：

• etcd保存了整個集群的狀態；
• apiserver提供了資源操作的唯一入口，并提供認證、授權、訪問控制、API注冊和發現等機制；
• controller manager負責維護集群的狀態，比如故障檢測、自動擴展、滾動更新等；
• scheduler負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；

Kubernetes Node部分：

• kubelet負責維護容器的生命周期，同時也負責Volume（CVI）和網絡（CNI）的管理；
• Container runtime負責鏡像管理以及Pod和容器的真正運行（CRI）；
• kube-proxy負責為Service提供cluster內部的服務發現和負載均衡；

Pod

概念

Pod 是可以在 Kubernetes 中創建和管理的、最小的可部署的計算單元。

Pod 的共享上下文包括一組 Linux 名字空間、控制組（cgroup）和可能一些其他的隔離 方面，即用來隔離 Docker 容器的技術。 在 Pod 的上下文中，每個獨立的應用可能會進一步實施隔離。

就 Docker 概念的術語而言，Pod 類似于共享名字空間和文件系統卷的一組 Docker 容器。

Pod的聯網

每個 Pod 都在每個地址族中獲得一個唯一的 IP 地址。 Pod 中的每個容器共享網絡名字空間，包括 IP 地址和網絡端口。 Pod 內 的容器可以使用 localhost 互相通信。 當 Pod 中的容器與 Pod 之外 的實體通信時，它們必須協調如何使用共享的網絡資源 （例如端口）。

Pod的生命周期

Pod有以下階段：

• Pending：Pod 已被 Kubernetes 系統接受，但有一個或者多個容器尚未創建亦未運行。此階段包括等待 Pod 被調度的時間和通過網絡下載鏡像的時間。
• Running：Pod 已經綁定到了某個節點，Pod 中所有的容器都已被創建。至少有一個容器仍在運行，或者正處于啟動或重啟狀態。
• Succeeded：Pod 中的所有容器都已成功終止，并且不會再重啟。
• Failed：Pod 中的所有容器都已終止，并且至少有一個容器是因為失敗終止。也就是說，容器以非 0 狀態退出或者被系統終止。
• Unknown：因為某些原因無法取得 Pod 的狀態。這種情況通常是因為與 Pod 所在主機通信失敗。

Pod 遵循一個預定義的生命周期，起始于 Pending 階段，如果至少其中有一個主要容器正常啟動，則進入 Running，之后取決于 Pod 中是否有容器以 失敗狀態結束而進入 Succeeded 或者 Failed 階段。

注意：Running不代表Pod可以提供服務了，只代表了至少其中有一個主要容器正常啟動

和一個個獨立的應用容器一樣，Pod 也被認為是相對臨時性（而不是長期存在）的實體。 Pod 會被創建、賦予一個唯一的 ID（UID）， 并被調度到節點，并在終止（根據重啟策略）或刪除之前一直運行在該節點。

Pod 自身不具有自愈能力。如果 Pod 被調度到某節點 而該節點之后失效，或者調度操作本身失效，Pod 會被刪除；與此類似，Pod 無法在節點資源 耗盡或者節點維護期間繼續存活。Kubernetes 使用一種高級抽象，稱作 控制器，來管理這些相對而言 可隨時丟棄的 Pod 實例。

Init容器

Init 容器是一種特殊容器，在 Pod 內的應用容器啟動之前運行。每個 Pod 中可以包含多個容器， 應用運行在這些容器里面，同時 Pod 也可以有一個或多個先于應用容器啟動的 Init 容器。

Init 容器與普通的容器非常像，除了如下兩點：

• 它們總是運行到完成。
• 每個都必須在下一個啟動之前成功完成。

如果 Pod 的 Init 容器失敗，kubelet 會不斷地重啟該 Init 容器直到該容器成功為止。 然而，如果 Pod 對應的 restartPolicy 值為 “Never”，Kubernetes 不會重新啟動 Pod。

官方示例：

在下面的官方示例中，定義了一個叫myapp-pod的Pod，并且定義了兩個Init容器 init-myservice 和 init-mydb ，這兩個Init容器分別等待myservice和mydb服務的啟動，myapp-pod中的應用容器myapp-container必須等待兩個Init容器運行完成，才能被創建并運行。

官方示例中演示了Init容器比較常用的場景。

apiVersion: v1 kind: Pod metadata:name: myapp-podlabels:app: myapp spec:containers:- name: myapp-containerimage: busybox:1.28command: ['sh', '-c', 'echo The app is running! && sleep 3600']initContainers:- name: init-myserviceimage: busybox:1.28command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]- name: init-mydbimage: busybox:1.28command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

容器探針

三種探測狀態

• Success（成功）：容器通過了診斷。
• Failure（失敗）：容器未通過診斷。
• Unknown（未知）：診斷失敗，因此不會采取任何行動。

三種探針

對應Pod內部的容器是否正常運行，kubernetes提供了三種類型的探針，三種類型的探針擁有不同的探測時機以及如何針對探測結果作出反應：

• livenessProbe：指示容器是否正在運行。如果存活態探測失敗，則 kubelet 會殺死容器， 并且容器將根據其重啟策略決定未來。如果容器不提供存活探針， 則默認狀態為 Success。
• readinessProbe：指示容器是否準備好為請求提供服務。如果就緒態探測失敗， 端點控制器將從與 Pod 匹配的所有服務的端點列表中刪除該 Pod 的 IP 地址。 初始延遲之前的就緒態的狀態值默認為 Failure。 如果容器不提供就緒態探針，則默認狀態為 Success。
• startupProbe: 指示容器中的應用是否已經啟動。如果提供了啟動探針，則所有其他探針都會被 禁用，直到此探針成功為止。如果啟動探測失敗，kubelet 將殺死容器，而容器依其 重啟策略進行重啟。 如果容器沒有提供啟動探測，則默認狀態為 Success。

三種處理程序（探測方式）

kubernetes提供了三種類型的處理程序，處理程序用于探測容器是否正常活動：

• ExecAction： 在容器內執行指定命令。如果命令退出時返回碼為 0 則認為診斷成功。
• TCPSocketAction： 對容器的 IP 地址上的指定端口執行 TCP 檢查。如果端口打開，則診斷被認為是成功的。
• HTTPGetAction： 對容器的 IP 地址上指定端口和路徑執行 HTTP Get 請求。如果響應的狀態碼大于等于 200 且小于 400，則診斷被認為是成功的。

總結

以上是生活随笔為你收集整理的Kubernetes基础学习（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

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