建站
咨詢
售后
建站咨詢
新聞中心
本篇文章給大家分享的是有關(guān)Kubernetes中的Pod怎么用，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
10年積累的成都網(wǎng)站建設(shè)、成都做網(wǎng)站經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有六合免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
Pod是Kubernetes系統(tǒng)的基礎(chǔ)單元，是資源對象模型中可由用戶創(chuàng)建或部署的最小組件，也是在Kubernetes系統(tǒng)上運行容器化應(yīng)用的資源對象。
容器與Pod的關(guān)系
Docker推薦采用單容器單進程的方式運行，但由于容器間的隔離機制，各容器進程間又無法實現(xiàn)IPC（Inter-Process Communication）通信。這就導(dǎo)致功能相關(guān)的容器之間通信困難，比如主容器與負責日志收集的容器之間的通信。而Pod資源抽象正是用來解決此類問題的組件，Pod對象是一組容器的集合，這些容器共享Network、UTS（UNIX Time-sharing System）及IPC名稱空間，因此具有相同的域名、主機名和網(wǎng)絡(luò)接口，并可通過IPC直接通信。 為一個Pod對象中的各容器提供網(wǎng)絡(luò)名稱空間等共享機制的是底層基礎(chǔ)容器pause。 盡管Pod支持運行多個容器，但作為最佳實踐，除非多個進程之間具有密切的關(guān)系，否則都應(yīng)該將其構(gòu)建到多個Pod中，這樣多個Pod可被調(diào)度至多個不同的主機運行，提高了資源利用率，也便于規(guī)模的伸縮。
Sidecar pattern（邊車模式）
多個進程之間具有密切的關(guān)系時，一般按照邊車模型來組織多個容器，邊車即為Pod的主應(yīng)用容器提供協(xié)同的輔助應(yīng)用容器，典型的應(yīng)用場景是將主應(yīng)用容器中的日志使用agent收集至日志服務(wù)器中時，可以將agent運行為輔助應(yīng)用容器。
管理Pod對象的容器
Pod的配置清單舉例：
apiVersion: v1 kind: Pod metadata: name: pod-example spec: containers: - name: myapp image: ikubernetes/myapp:v2
其中spec字段下，containers為及其子字段name為必選項，image在手動場景Pod時必選，在但在被高級別管理資源如Deployment控制時可選，因為這個字段可能會被覆蓋。
定義鏡像的獲取策略
Pod的核心功能是運行容器，而 通過image.imagePullPolicy可以自定義鏡像的獲取策略。
Always：鏡像標簽為“l(fā)atest”或鏡像不存在時總是從指定的倉庫中獲取鏡像
IfNotPresent：僅當本地鏡像缺失時才從目標倉庫下載鏡像
Never：禁止從倉庫下載鏡像，即僅使用本地鏡像
spec: containers: - name: myapp image: ikubernetes/myapp:v2 imagePullPolicy: Always
對于標簽為“l(fā)atest”的鏡像文件，其默認的鏡像獲取策略即為“Always”，而對于其他標簽的鏡像，其默認策略則為“IfNotPresent”。
暴露端口
在Pod中暴露端口與為Docker容器暴露端口的意義不一樣： 在Docker的網(wǎng)絡(luò)模型中，使用默認網(wǎng)絡(luò)的容器化應(yīng)用需通過NAT機制將其“暴露”（expose）到外部網(wǎng)絡(luò)中才能被其他節(jié)點之上的容器客戶端所訪問； 而在K8S中，各Pod的IP地址已經(jīng)處于同一網(wǎng)絡(luò)平面，無論是否為容器暴露端口，都不會影響集群中其他節(jié)點之上的Pod客戶端對其進行訪問，所以暴露的端口只是信息性數(shù)據(jù)，而且顯式指定容器端口也方便調(diào)用。
spec: containers: - name: myapp image: ikubernetes/myapp:v2 ports: - name: http containerPort: 80 protocol: TCP
這里的配置指定暴露容器上的TCP端口80，并將其命名為http。 Pod對象的IP地址僅在當前集群內(nèi)可達，它們無法直接接收來自集群外部客戶端的請求流量，盡管它們的服務(wù)可達性不受工作節(jié)點邊界的約束，但依然受制于集群邊界。如何讓集群外部訪問到Pod對象，將在后面學習。
自定義運行的容器化應(yīng)用
command字段能夠指定不同于鏡像默認運行的應(yīng)用程序，并且可以同時使用args字段進行參數(shù)傳遞，它們將覆蓋鏡像中的默認定義。不過，如果僅為容器定義了args字段，那么它將作為參數(shù)傳遞給鏡像中默認指定運行的應(yīng)用程序；如果僅為容器定義了command字段，那么它將覆蓋鏡像中定義的程序及參數(shù)，并以無參數(shù)方式運行應(yīng)用程序。
spec: containers: - name: myapp image: ikubernetes/myapp:v2 imagePullPolicy: Never command: ["/bin/sh"] args: ["-c", "while true; do sleep 30; done"]
環(huán)境變量
環(huán)境變量也是向容器化應(yīng)用傳遞配置的一種方式，向Pod對象中的容器環(huán)境變量傳遞數(shù)據(jù)的方法有兩種：env和envFrom，這里只介紹第一種方式，第二種方式將在介紹ConfigMap和Secret資源時進行說明。環(huán)境變量通常由name和value字段構(gòu)成。
spec: containers: - name: myapp image: ikubernetes/myapp:v2 env: - name: redis_HOST value: do.macOS - name: LOG_LEVEL value: info
標簽與標簽選擇器
標簽的管理
標簽選擇器可以對附帶標簽的資源對象進行挑選，并進行所需要的操作。一個對象可擁有不止一個標簽，而同一個標簽也可被添加至多個資源之上。 可以為資源附加多個不同緯度的標簽以實現(xiàn)靈活的資源分組管理功能，例如，版本標簽、環(huán)境標簽、分層架構(gòu)標簽等，用于交叉標識同一個資源所屬的不同版本、環(huán)境及架構(gòu)層級等。 定義標簽示例：
apiVersion: v1 kind: Pod metadata: name: pod-example labels: env: qa tier: frontend
資源創(chuàng)建后，在kubectl get pods命令中添加--show-labels選項就可顯示lables信息。 -L 選項可增加對應(yīng)的列信息。 直接管理活動對象的標簽:
kubectl label pods/pod-example release=beta
為pod-example添加了release=beta，如果要修改已經(jīng)存在的減值對，需要添加--overwrite選項。
標簽選擇器
標簽選擇器用于表達標簽的查詢條件或選擇標準，Kubernetes API目前支持兩個選擇器：基于
equality-based，可用操作符有“=”“==”和“! =”三種，前兩種等價
set-based，支持in、notin和exists三種操作符，此外還有可以只指定KEY來篩選所有存在此鍵名標簽的資源，!KEY則篩選所有不存在此鍵名標簽的資源 使用標簽選擇器時遵循以下邏輯:
同時指定的多個選擇器之間的邏輯關(guān)系為“與”操作
使用空值的標簽選擇器意味著每個資源對象都將被選中
空的標簽選擇器將無法選出任何資源。
Kubernetes的諸多資源對象必須以標簽選擇器的方式關(guān)聯(lián)到Pod資源對象，例如Service、Deployment和ReplicaSet類型的資源等，可以在spec字段通過嵌套的“selector”字段來指定選擇器，有兩種方式：
matchLabels：通過直接給定鍵值對來指定標簽選擇器
matchExpressions：基于表達式指定的標簽選擇器列表，每個選擇器都形如“{key:KEY_NAME, operator: OPERATOR,values: [VALUE1, VALUE2, …]}”，選擇器列表間為“邏輯與”關(guān)系；使用In或NotIn操作符時，其values不強制要求為非空的字符串列表，而使用Exists或DostNotExist時，其values必須為空。 格式舉例：
selector:
matchLabels:
component: redis
matchExpressions:
- {key: tier, operator: In, values: [cache]}
- {key: environment, operator: Exists, values:}資源注解
標簽之外，Pod與其他各種資源還能使用資源注解（annotation），也是鍵值類型的數(shù)據(jù)，不過它不能用于標簽及挑選Kubernetes對象，僅可用于為資源提供“元數(shù)據(jù)”信息。另外，注解中的元數(shù)據(jù)不受字符數(shù)量的限制，可以為結(jié)構(gòu)化或非結(jié)構(gòu)化形式，而且對字符類型也沒有限制。 Annotation中放置構(gòu)建、發(fā)行或鏡像相關(guān)的信息，指向日志、監(jiān)控、分析或?qū)徲媯}庫的地址，或者由客戶端庫或工具程序生成的用于調(diào)試目的的信息：如名稱、版本、構(gòu)建信息等信息。
查看資源注解使用kubectl get -o yaml和kubectl describe命令均能顯示資源的注解信息。
kubectl describe pods pod-example | grep "Annotations"
管理資源注解在配置清單中定義annotations：
apiVersion: v1 kind: Pod metadata: name: pod-example annotations: created-by: "cluster admin"
追加annotations：
kubectl annotate pods pod-example created-by2="admin"
Pod對象的生命周期
Pod的生命周期如圖： 
Phase
Pod對象總是應(yīng)該處于其生命進程中以下幾個Phase（階段）之一：
Pending:API Server創(chuàng)建了Pod資源對象并已存入etcd中，但它尚未被調(diào)度完成，或者仍處于從倉庫下載鏡像的過程中。?
Running:Pod已經(jīng)被調(diào)度至某節(jié)點，并且所有容器都已經(jīng)被kubelet創(chuàng)建完成。?
Succeeded:Pod中的所有容器都已經(jīng)成功終止并且不會被重啟。?
Failed：所有容器都已經(jīng)終止，但至少有一個容器終止失敗，即容器返回了非0值的退出狀態(tài)或已經(jīng)被系統(tǒng)終止。?
Unknown:API Server無法正常獲取到Pod對象的狀態(tài)信息，通常是由于其無法與所在工作節(jié)點的kubelet通信所致。
Pod的創(chuàng)建過程
Pod的創(chuàng)建過程是指Pod自身及其主容器及其輔助容器創(chuàng)建的過程。 
用戶通過kubectl或其他API客戶端提交PodSpec給API Server。
API Server嘗試著將Pod對象的相關(guān)信息存入etcd中，待寫入操作執(zhí)行完成，API Server即會返回確認信息至客戶端。
API Server開始反映etcd中的狀態(tài)變化。
所有的Kubernetes組件均使用“watch”機制來跟蹤檢查API Server上的相關(guān)的變動。
kube-scheduler（調(diào)度器）通過其“watcher”覺察到API Server創(chuàng)建了新的Pod對象但尚未綁定至任何工作節(jié)點。
kube-scheduler為Pod對象挑選一個工作節(jié)點并將結(jié)果信息更新至API Server。
調(diào)度結(jié)果信息由API Server更新至etcd存儲系統(tǒng)，而且API Server也開始反映此Pod對象的調(diào)度結(jié)果。
Pod被調(diào)度到的目標工作節(jié)點上的kubelet嘗試在當前節(jié)點上調(diào)用Docker啟動容器，并將容器的結(jié)果狀態(tài)回送至API Server。
API Server將Pod狀態(tài)信息存入etcd系統(tǒng)中。
在etcd確認寫入操作成功完成后，API Server將確認信息發(fā)送至相關(guān)的kubelet，事件將通過它被接受。
Pod生命周期中的重要行為
除了創(chuàng)建應(yīng)用容器（主容器及其輔助容器）之外，用戶還可以為Pod對象定義其生命周期中的多種行為，如用于初始化的容器、存活性探測及就緒性探測等
用于初始化的容器
用于初始化的容器(init container)是應(yīng)用程序的主容器啟動之前要運行的容器，常用于為主容器執(zhí)行一些預(yù)置操作，典型的應(yīng)用如：
用于運行特定的工具程序，出于安全等方面的原因，這些程序不適于包含在主容器鏡像中。
提供主容器鏡像中不具備的工具程序或自定義代碼。
為容器鏡像的構(gòu)建和部署人員提供了分離、獨立工作的途徑，使得他們不必協(xié)同起來制作單個鏡像文件。
初始化容器和主容器處于不同的文件系統(tǒng)視圖中，因此可以分別安全地使用敏感數(shù)據(jù)，例如Secrets資源。
初始化容器要先于應(yīng)用容器串行啟動并運行完成，因此可用于延后應(yīng)用容器的啟動直至其依賴的條件得到滿足。
在資源清單中通過initContainers字段定義：
spec: containers: - name: myapp image: ikubernetes/myapp:v2 initContainers: - name: init-something image: busybox command: ['sh', '-c', 'sleep 10']
生命周期鉤子函數(shù)
Kubernetes為容器提供了兩種生命周期鉤子：
postStart：在容器創(chuàng)建完成之后立即運行，但是Kubernetes無法確保它一定會在容器中的ENTRYPOINT之前運行。
preStop：在容器終止操作之前立即運行，它以同步的方式調(diào)用，因此在其完成之前會阻塞刪除容器的操作。
鉤子函數(shù)的實現(xiàn)方式有“Exec”和“HTTP”兩種，前一種在鉤子事件觸發(fā)時直接在當前容器中運行由用戶定義的命令，后一種則是在當前容器中向某URL發(fā)起HTTP請求。鉤子函數(shù)定義在容器的spec.lifecycle字段。
容器的重啟策略
容器程序發(fā)生崩潰或容器申請超出限制的資源等原因都可能會導(dǎo)致Pod對象的終止，此時是否應(yīng)該重建該Pod對象則取決于其重啟策略（restartPolicy）屬性的定義。
Always：只要Pod對象終止就將其重啟，此為默認設(shè)定。
OnFailure：僅在Pod對象出現(xiàn)錯誤時方才將其重啟。
Never：從不重啟。
容器在重啟失敗后，之后的重啟將有一段時間的延遲，且延遲時間越來越長，依次為10秒、20秒、40秒、80秒、160秒、300秒。
Pod的終止過程
用戶發(fā)送刪除Pod對象的命令。
API服務(wù)器中的Pod對象會隨著時間的推移而更新，在寬限期內(nèi)（默認為30秒），Pod被視為“dead”。
將Pod標記為“Terminating”狀態(tài)。
（與第3步同時運行）kubelet在監(jiān)控到Pod對象轉(zhuǎn)為“Terminating”狀態(tài)的同時啟動Pod關(guān)閉過程。
（與第3步同時運行）端點控制器監(jiān)控到Pod對象的關(guān)閉行為時將其從所有匹配到此端點的Service資源的端點列表中移除。
如果當前Pod對象定義了preStop鉤子處理器，則在其標記為“terminating”后即會以同步的方式啟動執(zhí)行；如若寬限期結(jié)束后，preStop仍未執(zhí)行結(jié)束，則第2步會被重新執(zhí)行并額外獲取一個時長為2秒的小寬限期。
Pod對象中的容器進程收到TERM信號。
寬限期結(jié)束后，若存在任何一個仍在運行的進程，那么Pod對象即會收到SIGKILL信號。
Kubelet請求API Server將此Pod資源的寬限期設(shè)置為0從而完成刪除操作，它變得對用戶不再可見。
如果在等待進程終止的過程中，kubelet或容器管理器發(fā)生了重啟，那么終止操作會重新獲得一個滿額的刪除寬限期并重新執(zhí)行刪除操作。
Pod存活性探測
kubelet可基于存活性探測判定何時需要重啟一個容器。可通過spec.containers.livenessProbe定義，支持三種探測方法：
exec
httpGet
tcpSocket
exec
exec類型的探針通過在目標容器中執(zhí)行由用戶自定義的命令來判定容器的健康狀態(tài)，若命令狀態(tài)返回值為0則表示“成功”通過檢測，其它值均為“失敗”狀態(tài)。它只有一個可用屬性“command”，用于指定要執(zhí)行的命令，示例：
apiVersion: v1 kind: Pod metadata: name: liveness-exec-demo labels: test: liveness-exec-demo spec: containers: - name: liveness-exec-demo image: busybox args: ["/bin/sh", "-c", " touch /tmp/healthy;sleep 60; rm -rf /tmp/healthy;sleep 600"] livenessProbe: exec: command: ["test", "-e", "/tmp/healthy"]
這段配置清單基于busybox鏡像啟動一個容器，并執(zhí)行args定義的命令，此命令在容器啟動時創(chuàng)建/tmp/healthy文件，并于60秒之后將其刪除。存活性探針運行“test -e/tmp/healthy”命令檢查/tmp/healthy文件的存在性，若文件存在則返回狀態(tài)碼0，表示成功通過測試。 所以60秒后使用describe命令可以看到容器被重啟的event。
httpGet
httpGet方式是向目標容器發(fā)起一個HTTP GET請求，根據(jù)其響應(yīng)碼進行結(jié)果判定，2xx或3xx時表示檢測通過。 可配置字段有：
host，請求的主機地址，默認為Pod IP，也可以在httpHeaders中使用“Host:”來定義。
port，請求的端口，必選字段。
httpHeaders，自定義的請求報文頭。
path，請求的HTTP資源路徑。
scheme：建立連接使用的協(xié)議，僅可為HTTP或HTTPS，默認為HTTP。
示例
apiVersion: v1 kind: Pod metadata: name: liveness-http-demo labels: test: liveness-http-demo spec: containers: - name: liveness-http-demo image: nginx:1.12-alpine ports: - name: http containerPort: 80 lifecycle: postStart: exec: command: ["/bin/sh", "-c", " echo Healthy > /usr/share/nginx/html/healthz"] livenessProbe: httpGet: path: /healthz port: http scheme: HTTP
這個配置清單通過postStart hook創(chuàng)建了一個專用于httpGet測試的頁面文件healthz。而為httpGet探測指定的路徑為“/healthz”，地址默認為Pod IP，端口使用了容器中定義的端口名稱http。 啟動容器后健康檢查是正常的，但執(zhí)行如下命令刪除healthz頁面后，可在event中看到Container liveness-http-demo failed liveness probe, will be restarted。
kubectl exec liveness-http-demo rm /usr/share/nginx/html/healthz
一般應(yīng)為HTTP探測操作定義專用的URL路徑，此URL路徑對應(yīng)的Web資源應(yīng)該以輕量化的方式在內(nèi)部對應(yīng)用程序的各關(guān)鍵組件進行全面檢測以確保它們可正常向客戶端提供完整的服務(wù)。
tcpSocket
基于TCP的存活性探測用于向容器的特定端口發(fā)起TCP請求并嘗試建立連接，連接建立成功即為通過檢測。相比較來說，它比基于HTTP的探測要更高效、更節(jié)約資源，但精準度較低。 可配置字段有：
host，請求連接的目標IP地址，默認為Pod IP。
port，請求連接的目標端口，必選字段。
舉例：
spec: containers: - name: liveness-tcp-demo image: nginx:1.12-alpine livenessProbe: tcpSocket: port: 80
存活性探測行為屬性
對于配置了liveness的pod，通過describe命令可以看到類似這樣的信息，有delay、timeout等配置，由于之前沒有指定所以都為默認值：
Liveness: tcp-socket :80 delay=0s timeout=1s period=10s #success=1 #failure=3
initialDelaySeconds，存活性探測延遲時長，即容器啟動多久之后再開始第一次探測操作，顯示為delay屬性，默認為0秒，整型
timeoutSeconds，存活性探測的超時時長，顯示為timeout屬性，默認為1s，整型，最小1s
periodSeconds，存活性探測的頻度，顯示為period屬性，整型，默認為10s，最小值為1s；過高的頻率會對Pod對象帶來較大的額外開銷，而過低的頻率又會使得對錯誤的反應(yīng)不及時
successThreshold，處于失敗狀態(tài)時，探測操作至少連續(xù)多少次的成功才被認為是通過檢測，顯示為#success屬性，默認值為1，最小值也為1，整型
failureThreshold：處于成功狀態(tài)時，探測操作至少連續(xù)多少次的失敗才被視為是檢測不通過，顯示為#failure屬性，默認值為3，最小值為1，整型。
另外，liveness檢測僅對當前服務(wù)有效，比如但后端服務(wù)（如數(shù)據(jù)庫或緩存服務(wù)）導(dǎo)致故障時，重啟當前服務(wù)并不能解決問題，但它卻會被一次次重啟，直到后端服務(wù)恢復(fù)正常為止。
Pod就緒性探測
Pod對象啟動后，容器應(yīng)用通常需要一段時間才能完成其初始化過程，例如加載配置或數(shù)據(jù)，甚至有些程序還需要預(yù)熱的過程。因此應(yīng)該避免在Pod對象啟動后立即讓其處理客戶端請求，而是等待容器初始化工作執(zhí)行完成并轉(zhuǎn)為Ready狀態(tài)，尤其是存在其他提供相同服務(wù)的Pod對象的場景更是如此。 就緒性探測是用來判斷容器就緒與否的周期性操作，探測操作返回“success”狀態(tài)時，就認為容器已經(jīng)就緒。 與liveness探測類似，它也支持三種方式，但定義時使用的屬性名為readinessProbe。 舉例：
apiVersion: v1 kind: Pod metadata: name: readiness-tcp-demo labels: test: readiness-tcp-demo spec: containers: - name: readiness-tcp-demo image: nginx:1.12-alpine readinessProbe: tcpSocket: port: 80
未定義就緒性探測的Pod對象在Pod進入“Running”狀態(tài)后將立即就緒。生產(chǎn)實踐中，必須為需要時間進行初始化容器以及關(guān)鍵性Pod資源中的容器定義就緒性探測。
資源需求及資源限制
K8S中可由容器或Pod請求或消費的“計算資源”是指CPU和內(nèi)存，其中CPU屬于可壓縮（compressible）型資源，可按需收縮，而內(nèi)存則是不可壓縮型資源，對其執(zhí)行收縮操作可能會導(dǎo)致無法預(yù)知的問題。 目前資源隔離屬于容器級別，所以CPU和內(nèi)存資源的配置需要在Pod中的容器上進行，支持兩種屬性：
requests，定義了其請求的確保可用值，即容器運行可能用不到這些額度的資源，但用到時必須要確保有如此多的資源可用；
limits，限制資源可用的最大值
在K8S中，1個單位的CPU相當于虛擬機上的1顆虛擬CPU（vCPU）或物理機上的一個超線程（Hyperthread，或稱為一個邏輯CPU），它支持分數(shù)計量方式，一個核心（1 core）相當于1000個微核心（millicores），因此500m相當于是0.5個核心。內(nèi)存的計量方式與日常使用方式相同，默認單位是字節(jié)，也可以使用E(Ei)、P(Pi)、T(Ti)、G(Gi)、M(Mi)和K(Ki)作為單位后綴。
資源需求
apiVersion: v1 kind: Pod metadata: name: stress-demo spec: containers: - name: stress-demo image: ikubernetes/stress-ng command: ["/usr/bin/stress-ng", "-m 1", "-c 1", "--metrics-brief"] resources: requests: memory: "128Mi" cpu: "200m"
以上的配置清單定義了容器的資源需求為128M內(nèi)存、200m(0.2)個CPU核心。它運行stress-ng(一個多功能系統(tǒng)壓力測工具)鏡像啟動一個進程（-m 1）進行內(nèi)存性能壓力測試，再啟動一個專用的CPU壓力測試進程（-c 1）。 然后使用kubectl exec stress-demo -- top命令來查看資源的使用情況，在我的電腦（6核，內(nèi)存16G）上顯示的內(nèi)存占用為262m，CPU占用2*17%（約等于2/6，因為兩個測試線程分布于兩個CPU核心以滿載的方式運行），都遠高于requests中定義的值，這是因為當前資源充裕，一旦 資源緊張時，節(jié)點僅保證容器有五分之一個CPU核心可用，對于有著6個核心的節(jié)點來說，它的占用率約為3.33%，多占用的資源會被壓縮。內(nèi)存為非可壓縮型資源，所以此Pod在內(nèi)存資源緊張時可能會因OOM被殺死（killed）。 如果沒有定義requests，那么在CPU資源緊張時，可能會被其它Pod壓縮至極低的水平，甚至會達到Pod不能夠被調(diào)度運行的境地，而不可壓縮型的內(nèi)存資源，則可能因OOM導(dǎo)致進程被殺死。因此在Kubernetes系統(tǒng)上運行關(guān)鍵型業(yè)務(wù)相關(guān)的Pod時必須使用requests屬性為容器定義資源的確保可用量。
集群中的每個節(jié)點擁有的CPU和內(nèi)存資源是固定的，Kubernetes的調(diào)度器在調(diào)度Pod時，會根據(jù)容器的requests屬性來判定哪些節(jié)點可接收運行當前的Pod資源，而對于一個節(jié)點的資源來說，每運行一個Pod對象，其requests中定義的請求量都要被預(yù)留，直到給所有Pod對象分配完為止。
資源限制
通過定義資源需求可以保證容器的最少資源量，如果要限制容器使用資源的上限，則需要定義資源限制。 如果定義了資源限制，則容器進程無法獲得超出其CPU配額的可用時間，而進程申請分配超出其limits定義的內(nèi)存資源時，它將被OOM killer殺死。
Pod的服務(wù)質(zhì)量類別
Kubernetes允許節(jié)點資源對limits的過載使用，這意味著節(jié)點無法同時滿足其上的所有Pod對象以資源滿載的方式運行。于是就需要確定Pod對象的優(yōu)先級，在內(nèi)存資源緊缺時，先終止低優(yōu)先級的Pod對象。 Pod對象的優(yōu)先級是根據(jù)requests和limits屬性確定的，分為三個級別或QoS(Quality of Service）:
Guaranteed，Pod中所有容器對所有資源類型都定義了Limits和Requests，而且Limits值等于Requests值且不為0，Requests值未定義時默認等于Limits，優(yōu)先級最高。
BestEffort，沒有為任何一個容器設(shè)置requests或limits屬性的Pod資源屬于這一類，優(yōu)先級最低。
Burstable，不為Guaranteed和BestEffort時，優(yōu)先級中等。
只適用于內(nèi)存資源緊缺時，CPU資源無法得到滿足時，Pod僅僅是暫時獲取不到相應(yīng)的資源而已。
以上就是Kubernetes中的Pod怎么用，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
當前文章：Kubernetes中的Pod怎么用
本文網(wǎng)址：http://www.ef60e0e.cn/article/gsscgo.html
