Pod屬性?nginx
- 在同一個Pod之下的容器使用IPC互相通訊
- 容器能夠經過localhost找到彼此
- 每一個容器繼承Pod的name
- 在同一個網絡共享平面中每一個Pod都有一個ip
- Volumes被Pod中的容器所共享
標籤(Label)ubuntu
- 標籤就是「鍵值」類型的數據,他們可於資源建立時直接指定,也可隨時按需添加於活動對象,然後便可由標籤選擇器進行匹配度檢查從而完成資源篩選
- 一個對象可擁有不止一個標籤,而同一個標籤也可被添加至多個資源之上
- 實踐中,能夠爲資源附件多個不一樣維度的標籤以實現靈活的資源分組管理功能,例如版本標籤、環境標籤、分層架構標籤等,用於交叉標識同一個資源所屬的不一樣版本、環境及架構層級等
- 標籤中的鍵名稱一般由鍵前綴和鍵名組成,其中前綴可選,其格式形如「KEY_PREFIX/KEY_NAME」
- 鍵名至多能使用63各字符,可以使用如數字、字母、鏈接號(-)、下劃線(_)、點號(.)等字符,且只能以字母或數字開頭
- 鍵前綴必須爲DNS子域名格式,且不能超過253個字符。省略鍵前綴時,鍵將被視爲用戶的私有數據,不過由Kunernetes系統組件或第三方組件自動爲用戶資源添加的鍵必須使用鍵前綴,而」Kubernetes.io/「前綴預留給kubernetes的核心組件使用
- 標籤中的鍵值必須不能多餘63個字符,它要麼爲空,要麼是以字母或者數字開頭及結尾,且中間僅使用了數字、字母、鏈接號(-)、下劃線(_)、點號(.)等字符的數據
標籤示例圖:c#
標籤選擇器(Label Selector)api
- 標籤選擇器用於表達標籤的查詢條件或者選擇標準,Kubernetes API目前支持兩個選擇器
- 給予等值關係(equality-based)
- 操做符有 = == 和 != 三種,其中前兩個意義相同,都表示「等值」關係,最後一個表示「不等」關係
- 基於集合關係(set-based)
- KEY in (VALUE1,VALUE12, ...)
- KEY not in (VALUE1,VALUE12, ...)
- KEY: 全部存在此鍵名標籤的資源
- KEY: 全部不存在此鍵名標籤的資源
- 使用標籤選擇器時還將遵循如下邏輯
- 同時指定多個選擇器之間的邏輯關係爲「與」操做
- 使用空值的標籤選擇器意味着每一個資源對象都將被選中
- 空的標籤選擇器將沒法選擇出任何資源
定義標籤選擇器的方式安全
- Kubernetes的諸多資源對象必須以標籤選擇器的方式關聯到Pod資源對象,例如Service、Deployment和ReplicaSet類型的資源等,他們在spec字段中嵌套使用嵌套的「selector"字段,經過「matchLabels」來指定標籤選擇器,有的甚至還支持使用「matchExpressions」構造複雜的標籤選擇機制。
- matchLabels:經過直接給定鍵值對指定標籤選擇器
- matchExpressions:基於表達式指定的標籤選擇器列表,每一個選擇器形如「{key: KEY_NAME,operator: OPERATOR,values:[VALUE1,VALUE2,...]}」,選擇器列表間爲邏輯「與」關係
- 使用In或NotIn操做符時,其values非必須爲非空的字符串列表,而使用Exists或DostDotExists時,其values必須爲空
添加標籤示例:網絡
yaml清單配置添加labels:
root@k8s-master:/home/ubuntu/manifests/basic# cat dev-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: dev-pod
namespace: develop
labels: # 這裏是新增標籤
app: ngx-demo rel: stable
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx-maple
hostNetwork: true
查詢結果:
命令行打標籤操做:
1. 增長tier標籤
2. overwrite app標籤
3. 刪除標籤,輸出標籤使用 鍵名-
資源註解(annotation)架構
- 註解也是「鍵值」類型的數據,不過它不能用於標籤及挑選kubernetes對象,僅用於爲資源提供「元數據」信息
- 註解中的元數據不受字符數量的限制,它可大可小,能夠爲結構化或非結構化形式,也支持使用在標籤中禁止使用的其餘字符
- 在kubernetes的新版本(Alpha或Beta階段)中爲某資源引入新字段時,常以註解方式提供以表面增刪等變更給用戶帶去困擾,一旦肯定支持使用它們,這心新增字段再引入到資源中並淘汰相關的註解
Pod生命週期app
容器探針:spa
- livenessProbe(存活):指示容器是否正在運行。若是存活探測失敗,則 kubelet 會殺死容器,而且容器將受到其重啓策略 的影響。若是容器不提供存活探針,則默認狀態爲 Success。
- readinessProbe(就緒):指示容器是否準備好服務請求。若是就緒探測失敗,端點控制器將從與 Pod 匹配的全部 Service 的端點中刪除該 Pod 的 IP 地址。初始延遲以前的就緒狀態默認爲 Failure。若是容器不提供就緒探針,則默認狀態爲 Success。
探針操做(由kubelet調用容器實現的Handler):命令行
- ExecAction:在容器內執行指定命令。若是命令退出時返回碼爲 0 則認爲診斷成功。
- TCPSocketAction:對指定端口上的容器的 IP 地址進行 TCP 檢查。若是端口打開,則診斷被認爲是成功的。
- HTTPGetAction:對指定的端口和路徑上的容器的 IP 地址執行 HTTP Get 請求。若是響應的狀態碼大於等於200 且小於 400,則診斷被認爲是成功的。
Pod對象的相位:
- 掛起(Pending):Pod 已被 Kubernetes 系統接受,但有一個或者多個容器鏡像還沒有建立。等待時間包括調度 Pod 的時間和經過網絡下載鏡像的時間,這可能須要花點時間。
- 運行中(Running):該 Pod 已經綁定到了一個節點上,Pod 中全部的容器都已被建立。至少有一個容器正在運行,或者正處於啓動或重啓狀態。
- 成功(Succeeded):Pod 中的全部容器都被成功終止,而且不會再重啓。
- 失敗(Failed):Pod 中的全部容器都已終止了,而且至少有一個容器是由於失敗終止。也就是說,容器以非0狀態退出或者被系統終止。
- 未知(Unknown):由於某些緣由沒法取得 Pod 的狀態,一般是由於與 Pod 所在主機通訊失敗。
Pod對象的建立過程:
容器的重啓策略:
Pod對象因容器程序崩潰或容器申請超出限制的資源等緣由均可能致使其被終止,此時是否應該重建取決於其重啓策略
- Always:但凡pod對象終止就將其重啓,此爲默認設定
- Onfailure: 僅在pod對象出現錯誤時纔將其重啓
- Never: 從不重啓
Pod對象的終止過程:
Pod安全上下文
- 節點運行權限設定,具體設定能夠參考securityContext
kubectl explain pod.spec.securityContext
- 同時還有容器的安全上下文設定securityContext
kubectl explain pod.spec.containers.securityContext
Pod優先級
資源緊缺時,須要用到優先級
kubectl explain pod.spec.priority
容器資源範圍
kubectl explain pod.spec.containers.resources.limits 上限
kubectl explain pod.spec.containers.resources.requests 下限
資源需求及資源限制
容器的計算資源配額
- CPU屬於可壓縮型資源,即資源額度可按需收縮,而內存則是不可壓縮型資源,對其執行收縮操做可能會致使某種程度的問題
- CPU資源的計量方式
- 一個核心至關於1000個微核心,及1=1000m,0.5=500m
- 內存資源的計量方式
- 默認單位爲字節,也可使用使用E、P、G、M和K後綴單位,或Ei、Pi、Gi、Mi和Ki後綴單位
Pod服務質量類別
根據Pod對象的requests和limits屬性,k8s把Pod對象歸類到BestEffort、Burstable和Guaranteed三個服務質量類別
- Guaranteed:每一個容器都爲CPU資源設置了具備相同值的requests和limits屬性,以及每一個容器都爲內存次元設置了具備相同值的requests和limits屬性的Pod資源會自動歸屬此列別,這類pod資源具備最高優先級
- Burstable:至少有一個容器設置了CPU或內存資源的requests屬性,但不知足Guaranteed類別要求的pod資源自動歸屬此類別,他們具備中等優先級
- BestEffort:未爲任何一個容器設置requests或limits屬性的pod資源自動歸屬此類別,他們的優先級爲最低級別