Kubernetes基礎學習

Kubernetes核心組件

Kubernetes核心組件如下：

Kubernetes Master部分：

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

Kubernetes Node部分：

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

Pod

概念

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

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

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

Pod的聯(lián)網(wǎng)

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

Pod的生命周期

Pod有以下階段：

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

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

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

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

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

Init容器

Init 容器是一種特殊容器，在 Pod 內(nèi)的應用容器啟動之前運行。每個 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容器運行完成，才能被創(chuàng)建并運行。

官方示例中演示了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"]

容器探針

三種探測狀態(tài)

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

三種探針

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

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

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

kubernetes提供了三種類型的處理程序，處理程序用于探測容器是否正?；顒?#xff1a;

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。