什么是 DaemonSet?
編寫 DaemonSet 規(guī)約
必需字段
Pod 模板
Pod Selector
僅在某些節(jié)點上運行 Pod
如何調(diào)度 Daemon Pod
與 Daemon Pod 通信
更新 DaemonSet
DaemonSet 的可替代選擇
init 腳本
裸 Pod
靜態(tài) Pod
Replication Controller
什么是 DaemonSet?
站在用戶的角度思考問題,與客戶深入溝通,找到南漳網(wǎng)站設(shè)計與南漳網(wǎng)站推廣的解決方案,憑借多年的經(jīng)驗,讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合,創(chuàng)造個性化、用戶體驗好的作品,建站類型包括:網(wǎng)站設(shè)計制作、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、主機域名、網(wǎng)頁空間、企業(yè)郵箱。業(yè)務(wù)覆蓋南漳地區(qū)。DaemonSet 確保全部(或者某些)節(jié)點上運行一個 Pod 的副本。當(dāng)有節(jié)點加入集群時,也會為他們新增一個 Pod 。 當(dāng)有節(jié)點從集群移除時,這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它創(chuàng)建的所有 Pod。
使用 DaemonSet 的一些典型用法:
運行集群存儲 daemon,例如在每個節(jié)點上運行 glusterd、ceph。
在每個節(jié)點上運行日志收集 daemon,例如fluentd、logstash。
在每個節(jié)點上運行監(jiān)控 daemon,例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理,或 Ganglia gmond。
一個簡單的用法是在所有的節(jié)點上都啟動一個 DaemonSet,將被作為每種類型的 daemon 使用。 一個稍微復(fù)雜的用法是單獨對每種 daemon 類型使用多個 DaemonSet,但具有不同的標(biāo)志,和/或?qū)Σ煌布愋途哂胁煌膬?nèi)存、CPU要求。
編寫 DaemonSet 規(guī)約
必需字段
和其它所有 Kubernetes 配置一樣,DaemonSet 需要 apiVersion、kind 和 metadata 字段。 有關(guān)配置文件的基本信息,詳見文檔 deploying applications、配置容器 和 資源管理 。
DaemonSet 也需要一個 .spec 配置段。
Pod 模板
.spec 唯一必需的字段是 .spec.template。
.spec.template 是一個 Pod 模板。 它與 Pod 具有相同的 schema,除了它是嵌套的,而且不具有 apiVersion 或 kind 字段。
除了 Pod 必需字段外,在 DaemonSet 中的 Pod 模板必須指定合理的標(biāo)簽(查看 Pod Selector)。
在 DaemonSet 中的 Pod 模板必須具有一個值為 Always 的 RestartPolicy,或者未指定它的值,默認是 Always。
Pod Selector
.spec.selector 字段表示 Pod Selector,它與 Job 或其它資源的 .spec.selector 的作用是相同的。
spec.selector 表示一個對象,它由如下兩個字段組成:
matchLabels - 與 ReplicationController 的 .spec.selector 的作用相同。
matchExpressions - 允許構(gòu)建更加復(fù)雜的 Selector,可以通過指定 key、value 列表,以及與 key 和 value 列表相關(guān)的操作符。
當(dāng)上述兩個字段都指定時,結(jié)果表示的是 AND 關(guān)系。
如果指定了 .spec.selector,必須與 .spec.template.metadata.labels 相匹配。如果沒有指定,它們默認是等價的。如果與它們配置的不匹配,則會被 API 拒絕。
如果 Pod 的 label 與 selector 匹配,或者直接基于其它的 DaemonSet、或者 Controller(例如 ReplicationController),也不可以創(chuàng)建任何 Pod。 否則 DaemonSet Controller 將認為那些 Pod 是它創(chuàng)建的。Kubernetes 不會阻止這樣做。一個場景是,可能希望在一個具有不同值的、用來測試用的節(jié)點上手動創(chuàng)建 Pod。
僅在某些節(jié)點上運行 Pod
如果指定了 .spec.template.spec.nodeSelector,DaemonSet Controller 將在能夠與 Node Selector 匹配的節(jié)點上創(chuàng)建 Pod。 類似這種情況,可以指定 .spec.template.spec.affinity,然后 DaemonSet Controller 將在能夠與 Node Affinity 匹配的節(jié)點上創(chuàng)建 Pod。 如果根本就沒有指定,則 DaemonSet Controller 將在所有節(jié)點上創(chuàng)建 Pod。
如何調(diào)度 Daemon Pod
正常情況下,Pod 運行在哪個機器上是由 Kubernetes 調(diào)度器來選擇的。然而,由 Daemon Controller 創(chuàng)建的 Pod 已經(jīng)確定了在哪個機器上(Pod 創(chuàng)建時指定了 .spec.nodeName),因此:
DaemonSet Controller 并不關(guān)心一個節(jié)點的 unschedulable 字段。
DaemonSet Controller 可以創(chuàng)建 Pod,即使調(diào)度器還沒有啟動,這對集群啟動是非常有幫助的。
Daemon Pod 關(guān)心 Taint 和 Toleration,它們會為沒有指定 tolerationSeconds 的 node.kubernetes.io/not-ready 和 node.alpha.kubernetes.io/unreachable 的 Taint,創(chuàng)建具有 NoExecute 的 Toleration。這確保了當(dāng) alpha 特性的 TaintBasedEvictions 被啟用時,發(fā)生節(jié)點故障,比如網(wǎng)絡(luò)分區(qū),這時它們將不會被清除掉(當(dāng) TaintBasedEvictions 特性沒有啟用,在這些場景下也不會被清除,但會因為 NodeController 的硬編碼行為而被清除,而不會因為 Toleration 導(dǎo)致被清除)。
與 Daemon Pod 通信
與 DaemonSet 中的 Pod 進行通信,幾種可能的模式如下:
Push:配置 DaemonSet 中的 Pod 向其它 Service 發(fā)送更新,例如統(tǒng)計數(shù)據(jù)庫。它們沒有客戶端。
NodeIP 和已知端口:DaemonSet 中的 Pod 可以使用 hostPort,從而可以通過節(jié)點 IP 訪問到 Pod。客戶端能通過某種方法知道節(jié)點 IP 列表,并且基于此也可以知道端口。
DNS:創(chuàng)建具有相同 Pod Selector 的 Headless Service,然后通過使用 endpoints 資源或從 DNS 檢索到多個 A 記錄來發(fā)現(xiàn) DaemonSet。
Service:創(chuàng)建具有相同 Pod Selector 的 Service,并使用該 Service 隨機訪問到某個節(jié)點上的 daemon(沒有辦法訪問到特定節(jié)點)。
更新 DaemonSet
如果修改了節(jié)點標(biāo)簽(Label),DaemonSet 將立刻向新匹配上的節(jié)點添加 Pod,同時刪除新近不能夠匹配的節(jié)點上的 Pod。
我們可以修改 DaemonSet 創(chuàng)建的 Pod。然而,不允許對 Pod 的所有字段進行更新。當(dāng)下次節(jié)點(即使具有相同的名稱)被創(chuàng)建時,DaemonSet Controller 還會使用最初的模板。
可以刪除一個 DaemonSet。如果使用 kubectl 并指定 --cascade=false 選項,則 Pod 將被保留在節(jié)點上。然后可以創(chuàng)建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 將能夠通過標(biāo)簽匹配并識別所有已經(jīng)存在的 Pod。它不會修改或刪除它們,即使是錯誤匹配了 Pod 模板。通過刪除 Pod 或者刪除節(jié)點,可以強制創(chuàng)建新的 Pod。
在 Kubernetes 1.6 或以后版本,可以在 DaemonSet 上 執(zhí)行滾動升級。
未來的 Kubernetes 版本將支持節(jié)點的可控更新。
DaemonSet 的可替代選擇
init 腳本
我們很可能希望直接在一個節(jié)點上啟動 daemon 進程(例如,使用 init、upstartd、或 systemd)。這非常好,但基于 DaemonSet 來運行這些進程有如下一些好處:
像對待應(yīng)用程序一樣,具備為 daemon 提供監(jiān)控和管理日志的能力。
為 daemon 和應(yīng)用程序使用相同的配置語言和工具(如 Pod 模板、kubectl)。
Kubernetes 未來版本可能會支持對 DaemonSet 創(chuàng)建 Pod 與節(jié)點升級工作流進行集成。
在資源受限的容器中運行 daemon,能夠增加 daemon 和應(yīng)用容器的隔離性。然而,這也實現(xiàn)了在容器中運行 daemon,但卻不能在 Pod 中運行(例如,直接基于 Docker 啟動)。
裸 Pod
可能要直接創(chuàng)建 Pod,同時指定其運行在特定的節(jié)點上。 然而,DaemonSet 替換了由于任何原因被刪除或終止的 Pod,例如節(jié)點失敗、例行節(jié)點維護、內(nèi)核升級。由于這個原因,我們應(yīng)該使用 DaemonSet 而不是單獨創(chuàng)建 Pod。
靜態(tài) Pod
可能需要通過在一個指定目錄下編寫文件來創(chuàng)建 Pod,該目錄受 Kubelet 所監(jiān)視。這些 Pod 被稱為 靜態(tài) Pod。 不像 DaemonSet,靜態(tài) Pod 不受 kubectl 和其它 Kubernetes API 客戶端管理。靜態(tài) Pod 不依賴于 apiserver,這使得它們在集群啟動的情況下非常有用。 而且,未來靜態(tài) Pod 可能會被廢棄掉。
Replication Controller
DaemonSet 與 Replication Controller 非常類似,它們都能創(chuàng)建 Pod,這些 Pod 對應(yīng)的進程都不希望被終止掉(例如,Web 服務(wù)器、存儲服務(wù)器)。 為無狀態(tài)的 Service 使用 Replication Controller,比如前端(Frontend)服務(wù),實現(xiàn)對副本的數(shù)量進行擴縮容、平滑升級,比之于精確控制 Pod 運行在某個主機上要重要得多。 需要 Pod 副本總是運行在全部或特定主機上,并需要先于其他 Pod 啟動,當(dāng)這被認為非常重要時,應(yīng)該使用 Daemon Controller
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場景需求。