前言

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

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

Node

Node很好理解. 就是服務(wù)實際運(yùn)行的實例, 可以是一臺物理機(jī), 也可以是一臺 VM 虛擬機(jī)

Pod

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

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

Pod 控制器

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

• 管理Pod的數(shù)量
• 實現(xiàn)Pod的彈性伸縮
• 監(jiān)控Pod的狀態(tài)
• 定時啟動并釋放Pod
• 等等

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

ReplicationController

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

ReplicaSet

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

雖然ReplicaSet可以單獨使用, 但建議用Deployment進(jìn)行管理.

Deployment

Deployment不會直接管理Pod, 而是通過管理ReplicaSet, 再經(jīng)有ReplicaSet管理Pod.

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

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

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

HorizontalPodAutoscaler

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

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

StatefulSet

StatefulSet是為了解決有狀態(tài)服務(wù)的. 上面的控制器都是無狀態(tài)的. StatefulSet可以實現(xiàn)如下功能:

• 穩(wěn)定的持久化存儲. 當(dāng)Pod動態(tài)調(diào)整后能夠訪問到相同的持久化數(shù)據(jù). 基于PVC實現(xiàn)
• 穩(wěn)定的網(wǎng)絡(luò)標(biāo)識. Pod動態(tài)調(diào)整后 PodName HostName不變. 基于Headless Service實現(xiàn).
• 有序部署. 既前一個Pod啟動成功, 才會創(chuàng)建下一個Pod. 解決服務(wù)依賴的問題. 基于init containers實現(xiàn).
• 有序刪除. 有序部署的反向操作.

DeamonSet

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

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

Job

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

CronJob

Job的crontab版本. 基于時間管理的Job. 是通過在特定時間創(chuàng)建Job實現(xiàn)的. 可以在指定時間運(yùn)行一次任務(wù), 或者周期性的在指定時間運(yùn)行.

服務(wù)發(fā)現(xiàn)及負(fù)載均衡

Service

Pod控制器只是對Pod的管理, 比如在一個Deployment中運(yùn)行了5個Pod, 如果外部訪問Pod服務(wù)時寫的是每一個Pod的地址, 當(dāng)Pod動態(tài)伸縮的時候, 維護(hù)這些地址就是一個讓人頭大的問題了.

而Service就是為了解決這個問題而出現(xiàn)的. 它為一組Pod提供了一個統(tǒng)一對外的接口, 外部訪問Service再經(jīng)有Service將請求發(fā)給Pod, 而不需要關(guān)心Pod的數(shù)量、啟動、釋放等等。

同時Service還能夠?qū)α髁窟M(jìn)行負(fù)載均衡

Ingress

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

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

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/

存儲卷

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

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

ConfigMap

專門用于存儲配置文件, 同時還支持二進(jìn)制內(nèi)容. 將文件內(nèi)容直接寫入到y(tǒng)aml配置中. 同時, ConfigMap是支持熱更新的.

Secret

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

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

不過, 社區(qū)后續(xù)應(yīng)該會推出更安全的加密策略.

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

volume

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

---

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

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

總結(jié)

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

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