文章目錄
- 一、存儲(Storage)
- 1.1、Volume
- 1.2、PersistentVolume (PV)
- 1.3、PersistentVolumeClaim (PVC)
- 1.4、StorageClass
- 1.5、PVC 和 PV 的綁定過程?
- 二、配置管理(Configuration)
- 2.1、ConfigMap
- 2.2、Secret
- 2.3、存活、就緒和啟動探針
- 三、安全(Security)
- 四、策略與最佳實踐
- 五、總結
這一章節主要涉及如何持久化應用數據、管理配置、保護敏感信息以及定義安全和訪問控制策略。以下是干貨總結:
一、存儲(Storage)
1.1、Volume
-
Pod 內部的臨時存儲,生命周期與 Pod 綁定。
-
為集群中的 Pods 提供長期和臨時存儲的方法。
Container(容器)中的磁盤文件是短暫的,當容器崩潰時,kubelet會重新啟動容器,但最初的文件將丟失,Container會以最干凈的狀態啟動。另外,當一個Pod運行多個Container時,各個容器可能需要共享一些文件。Kubernetes Volume可以解決這兩個問題。
一些需要持久化數據的程序才會用到Volumes,或者一些需要共享數據的容器需要volumes。
- 常見類型:emptyDir、hostPath、configMap、secret、persistentVolumeClaim。
1.2、PersistentVolume (PV)
由集群管理員提供的持久化存儲資源(如 NFS、Ceph、云盤)。
1.3、PersistentVolumeClaim (PVC)
用戶申請存儲的請求(聲明自己需要多大的存儲)。
Pod 通過 PVC 來掛載 PV,實現數據持久化。
1.4、StorageClass
定義存儲類型(SSD、HDD、云存儲等),支持動態創建 PV。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: low-latencyannotations:storageclass.kubernetes.io/is-default-class: "false"
provisioner: csi-driver.example-vendor.example
reclaimPolicy: Retain # 默認值是 Delete
allowVolumeExpansion: true
mountOptions:- discard # 這可能會在塊存儲層啟用 UNMAP/TRIM
volumeBindingMode: WaitForFirstConsumer
parameters:guaranteedReadWriteLatency: "true" # 這是服務提供商特定的
1.5、PVC 和 PV 的綁定過程?
用戶創建 PVC → 調度器尋找匹配的 PV → 綁定成功 → Pod 使用 PVC 掛載。
二、配置管理(Configuration)
2.1、ConfigMap
存放非敏感配置信息(環境變量、配置文件);可以掛載為文件或注入環境變量。
一般用ConfigMap去管理一些配置文件、或者一些大量的環境變量信息。
ConfigMap將配置和Pod分開,有一個nginx,nginx.conf -> configmap,nginx
更易于配置文件的更改和管理。
這是一個 ConfigMap 的示例,它的一些鍵只有一個值,其他鍵的值看起來像是 配置的片段格式。
apiVersion: v1
kind: ConfigMap
metadata:name: game-demo
data:# 類屬性鍵;每一個鍵都映射到一個簡單的值player_initial_lives: "3"ui_properties_file_name: "user-interface.properties"# 類文件鍵game.properties: |enemy.types=aliens,monstersplayer.maximum-lives=5 user-interface.properties: |color.good=purplecolor.bad=yellowallow.textmode=true
2.2、Secret
存放敏感信息(密碼、證書、密鑰)。
Secret 是一種包含少量敏感信息例如密碼、令牌或密鑰的對象。 這樣的信息可能會被放在 Pod 規約中或者鏡像中。 使用 Secret 意味著你不需要在應用程序代碼中包含機密數據。
由于創建 Secret 可以獨立于使用它們的 Pod, 因此在創建、查看和編輯 Pod 的工作流程中暴露 Secret(及其數據)的風險較小。 Kubernetes 和在集群中運行的應用程序也可以對 Secret 采取額外的預防措施, 例如避免將敏感數據寫入非易失性存儲。
Secret 類似于 ConfigMap 但專門用于保存機密數據。
Base64 編碼存儲,建議結合 KMS 或外部密鑰管理服務。Secret更傾向于存儲和共享敏感、加密的配置信息。
使用方式
-
掛載到 Pod 中(文件/環境變量)。
-
動態更新:Pod 內應用可監聽掛載的配置變化。
2.3、存活、就緒和啟動探針
Kubernetes 提供了多種探針:
- 存活探針
- 就緒探針
- 啟動探針
- 存活探針
存活探針決定何時重啟容器。 例如,當應用在運行但無法取得進展時,存活探針可以捕獲這類死鎖。
如果一個容器的存活探針失敗多次,kubelet 將重啟該容器。
存活探針不會等待就緒探針成功。 如果你想在執行存活探針前等待,你可以定義 initialDelaySeconds,或者使用啟動探針。
- 就緒探針
就緒探針決定容器何時準備好接受流量。 這種探針在等待應用執行耗時的初始任務時非常有用; 例如:建立網絡連接、加載文件和預熱緩存。在容器的生命周期后期, 就緒探針也很有用,例如,從臨時故障或過載中恢復時。
如果就緒探針返回的狀態為失敗,Kubernetes 會將該 Pod 從所有對應服務的端點中移除。
就緒探針在容器的整個生命期內持續運行。
- 啟動探針
啟動探針檢查容器內的應用是否已啟動。 啟動探針可以用于對慢啟動容器進行存活性檢測,避免它們在啟動運行之前就被 kubelet 殺掉。
如果配置了這類探針,它會禁用存活檢測和就緒檢測,直到啟動探針成功為止。
這類探針僅在啟動時執行,不像存活探針和就緒探針那樣周期性地運行。
三、安全(Security)
-
ServiceAccount
-
Pod 與 API Server 交互的身份。
-
每個 Pod 默認分配一個 ServiceAccount。
-
-
RBAC (Role-Based Access Control)
-
Role:命名空間級別的權限。
-
ClusterRole:跨命名空間的全局權限。
-
RoleBinding/ClusterRoleBinding:將用戶/組綁定到角色。
-
-
Pod Security Context
- 定義運行時安全策略(UID/GID、只讀文件系統、是否允許特權模式)。
-
NetworkPolicy
-
控制 Pod 之間、Pod 與外部的網絡訪問。
-
類似“防火墻規則”。
-
四、策略與最佳實踐
-
資源限制(ResourceQuota & LimitRange)
-
為 Pod/命名空間設置 CPU、內存上限。
-
避免“資源被少數應用吃光”。
-
-
PodDisruptionBudget (PDB)
- 控制在節點維護或升級時,至少有多少 Pod 副本存活。
-
安全加固
-
使用 Pod Security Admission(PSA) 替代 PodSecurityPolicy。
-
常見模式:privileged、baseline、restricted。
-
五、總結
-
存儲:PV 提供,PVC 申請,SC 動態化。
-
配置:ConfigMap 普通配置,Secret 存密碼。
-
安全:ServiceAccount 身份,RBAC 控權限,NetworkPolicy 限流量。
-
策略:資源配額防濫用,PDB 保障高可用。
“人的一生會經歷很多痛苦,但回頭想想,都是傳奇”。