前言

Kubernetes中的概念太多了, 什么Pod Service Deployment 等等等等, 給剛接觸的我都整蒙了. 通過幾天觀察下來, 說一下我對各個組件的理解.

此文章僅僅對這些概念做一個簡單的介紹, 不至于后面看其他文章的時候一頭霧水.

Node

Node很好理解. 就是服務實際運行的實例, 可以是一臺物理機, 也可以是一臺 VM 虛擬機

Pod

docker都用過了吧, 就是容器. 而Pod其實就類似于docker-composer, 多個的相關聯的容器組成了一個 Pod. 比如有一個nginx容器和一個php-fpm的容器, 他們兩個就可以組合為一個Pod`.

在同一個Pod中, 不同容器共享網絡棧與存儲卷. 也就是說, nginx訪問php-fpm可以直接使用localhost:9000即可, 也就是說, 一個Pod中啟動兩個容器, 都占用80端口, 是無法成功啟動的. 共享是通過Pause容器實現的, 這里只簡單介紹概念, 不展開了.

Pod 控制器

在Kubernetes中, Pod是資源的最小單位了. 而這一堆控制器, 就是用來對Pod進行自動管理的.當然, 如果不使用控制器而是手動管理也不是不行, 就是累唄. 比如:

• 管理Pod的數量
• 實現Pod的彈性伸縮
• 監控Pod的狀態
• 定時啟動并釋放Pod
• 等等

為了實現不同的需求, 出現了不同的Pod控制器. 以下控制器只是實現了不同的需求, 簡單過一下即可.

ReplicationController

對Pod數量進行管理. 確保Pod數量保持在用戶定義的數量. (若容器異常退出, 自動創建新的 Pod. 若數量多了, 也會自動回收. ) 不過現在建議使用 ReplicaSet替代了.

ReplicaSet

和ReplicationController的功能差不多, 額外增加了集合式selector的支持(標簽選擇器).

雖然ReplicaSet可以單獨使用, 但建議用Deployment進行管理.

Deployment

Deployment不會直接管理Pod, 而是通過管理ReplicaSet, 再經有ReplicaSet管理Pod.

Deployment處理了很多ReplicaSet不支持的額外操作. 如:

• rolling-update (滾動更新) 和回滾
• 自動伸縮(擴容和縮容)
• 暫停和繼續
• 等等

順帶說一下, Deployment的熱更新, 就是通過新建一個ReplicaSet, 逐漸減少原來ReplicaSet中Pod數量并增加新ReplicaSet中Pod數量來實現的. 回滾就是反過來嘛.

HorizontalPodAutoscaler

HPA也不會直接管理Pod, 而是管理Deployment或者ReplicaSet.

HPA可以檢測Pod資源使用率, 可以實現這樣的場景: 當Pod CPU 使用率大于80則自動新建, 否則自動釋放. 同時啟動的Pod數量最多30個, 最少5個. 既實現服務的水平擴展.

StatefulSet

StatefulSet是為了解決有狀態服務的. 上面的控制器都是無狀態的. StatefulSet可以實現如下功能:

• 穩定的持久化存儲. 當Pod動態調整后能夠訪問到相同的持久化數據. 基于PVC實現
• 穩定的網絡標識. Pod動態調整后 PodName HostName不變. 基于Headless Service實現.
• 有序部署. 既前一個Pod啟動成功, 才會創建下一個Pod. 解決服務依賴的問題. 基于init containers實現.
• 有序刪除. 有序部署的反向操作.

DeamonSet

可以確保所有(或指定的一部分)Node都運行一個Pod副本. 當新Node加入集群時自動新增對應的Pod, 當Node從集群移除時, 對應的Pod也會被回收.

這種運行在Node中的Pod有什么用呢? 比如資源監控, 再比如日志收集等等.

Job

批處理任務. kubernetes可以保證此任務的一個或多個Pod成功結束, 若任務失敗, kubernetes會自動重啟, 直到成功.

CronJob

Job的crontab版本. 基于時間管理的Job. 是通過在特定時間創建Job實現的. 可以在指定時間運行一次任務, 或者周期性的在指定時間運行.

服務發現及負載均衡

Service

Pod控制器只是對Pod的管理, 比如在一個Deployment中運行了5個Pod, 如果外部訪問Pod服務時寫的是每一個Pod的地址, 當Pod動態伸縮的時候, 維護這些地址就是一個讓人頭大的問題了.

而Service就是為了解決這個問題而出現的. 它為一組Pod提供了一個統一對外的接口, 外部訪問Service再經有Service將請求發給Pod, 而不需要關心Pod的數量、啟動、釋放等等。

同時Service還能夠對流量進行負載均衡

Ingress

因為Service是四層負載均衡, 也就是說只能代理到 IP 層, 無法實現像nginx一樣根據不同域名不同路徑進行負載均衡. 為了解決這個問題而提出了Ingress, Ingress是獨立與其他服務對請求進行轉發的. 可以將其理解為Service的Service.

一般來說, 通過Service對Pod進行內部代理, 然后通過Ingress將請求轉發給Service. Ingress也有不同的實現, 而其中比較常用的就是ingress-nginx了,其配置文件類似與nginx. 由官方維護的. 啟動命令為:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.0/deploy/static/provider/cloud/deploy.yaml

官方文檔: https://kubernetes.github.io/ingress-nginx/

存儲卷

這個需求就很普遍了, 用來對數據進行存儲及掛載服務. 在不同的容器、以及不同的pod中進行共享.

具體的使用方式可見: https://hujingnb.com/archives/709

ConfigMap

專門用于存儲配置文件, 同時還支持二進制內容. 將文件內容直接寫入到yaml配置中. 同時, ConfigMap是支持熱更新的.

Secret

存儲一些需要加密的信息, 比如密鑰、密碼等. 其基本上和ConfigMap差不多, 區別就是在ConfigMap的基礎上對內容做了一次加密. 不過不過, 現階段Secret的加密方式就是base64? 這也叫加密? 只能算作編碼吧.

可以通過命令: kubectl get secrets secret-name -o yaml查看內容.

不過, 社區后續應該會推出更安全的加密策略.

另外, 對于私有的鏡像倉庫, Secret可以添加拉取鏡像時的鑒權信息.

volume

在同一個pod下的多個容器之間共享存儲卷, 就跟磁盤的掛載差不多啦. volume沒有單獨的kind, 是直接進行定義的.

---

如上, 對Kubernetes中的各個名稱進行了簡單介紹, 再回去看其他文章, 是不是清楚多了. 全部都是對容器的各個方面各個層次的管理.

原文鏈接: https://hujingnb.com/archives/706

總結

以上是生活随笔為你收集整理的Kubernetes各个组件的概念的全部內容，希望文章能夠幫你解決所遇到的問題。

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