RM新时代网站-首页

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

深入研究Kubernetes調(diào)度

阿銘linux ? 來源:K8sMeetup社區(qū) ? 作者:Ron Sobol ? 2021-08-23 10:39 ? 次閱讀

“本文從 Pod 和節(jié)點(diǎn)的配置開始,介紹了 Kubernetes Scheduler 框架、擴(kuò)展點(diǎn)、API 以及可能發(fā)生的與資源相關(guān)的瓶頸,并展示了性能調(diào)整設(shè)置,涵蓋了 Kubernetes 中調(diào)度的大多方面。

Kubernetes Scheduler 是 Kubernetes 控制平面的核心組件之一。它在控制平面上運(yùn)行,將 Pod 分配給節(jié)點(diǎn),同時(shí)平衡節(jié)點(diǎn)之間的資源利用率。將 Pod 分配給新節(jié)點(diǎn)后,在該節(jié)點(diǎn)上運(yùn)行的 kubelet 會(huì)在 Kubernetes API 中檢索 Pod 定義,根據(jù)節(jié)點(diǎn)上的 Pod 規(guī)范創(chuàng)建資源和容器。換句話說,Scheduler 在控制平面內(nèi)運(yùn)行,并將工作負(fù)載分配給 Kubernetes 集群。

本文將對 Kubernetes Scheduler 進(jìn)行深入研究,首先概述一般的調(diào)度以及具有親和力(affinity)和 taint 的驅(qū)逐調(diào)度,然后討論調(diào)度程序的瓶頸以及生產(chǎn)中可能遇到的問題,最后研究如何微調(diào)調(diào)度程序的參數(shù)以適合集群。

調(diào)度簡介

Kubernetes 調(diào)度是將 Pod 分配給集群中匹配節(jié)點(diǎn)的過程。Scheduler 監(jiān)控新創(chuàng)建的 Pod,并為其分配最佳節(jié)點(diǎn)。它會(huì)根據(jù) Kubernetes 的調(diào)度原則和我們的配置選項(xiàng)選擇最佳節(jié)點(diǎn)。最簡單的配置選項(xiàng)是直接在 PodSpec 設(shè)置 nodeName:

apiVersion: v1

kind: Pod

metadata:

name: nginx

spec:

containers

- name: nginx

image: nginx

nodeName: node-01

上面的 nginx pod 默認(rèn)情況下將在 node-01 上運(yùn)行,但是 nodeName 有許多限制導(dǎo)致無法正常運(yùn)行 Pod,例如云中節(jié)點(diǎn)名稱未知、資源節(jié)點(diǎn)不足以及節(jié)點(diǎn)網(wǎng)絡(luò)間歇性問題等。因此,除了測試或開發(fā)期間,我們最好不使用 nodeName。

如果要在一組特定的節(jié)點(diǎn)上運(yùn)行 Pod,可以使用 nodeSelector。我們在 PodSpec 中將 nodeSelector 定義為一組鍵值對:

apiVersion: v1

kind: Pod

metadata:

name: nginx

spec:

containers:

- name: nginx

image: nginx

nodeSelector:

disktype: ssd

對于上面的 nginx pod,Kubernetes Scheduler 將找到一個(gè)磁盤類型為 ssd 的節(jié)點(diǎn)。當(dāng)然,該節(jié)點(diǎn)可以具有其他標(biāo)簽。我們可以在 Kubernetes 參考文檔中查看標(biāo)簽的完整列表。

地址:https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/

使用 nodeSelector 有約束 Pod 可以在有特定標(biāo)簽的節(jié)點(diǎn)上運(yùn)行。但它的使用僅受標(biāo)簽及其值限制。Kubernetes 中有兩個(gè)更全面的功能來表達(dá)更復(fù)雜的調(diào)度需求:節(jié)點(diǎn)親和力(node affinity),標(biāo)記容器以將其吸引到一組節(jié)點(diǎn)上;taint 和 toleration,標(biāo)記節(jié)點(diǎn)以排斥 Pod。這些功能將在下面討論。

節(jié)點(diǎn)親和力

節(jié)點(diǎn)親和力(Node Affinity)是在 Pod 上定義的一組約束,用于確定哪些節(jié)點(diǎn)適合進(jìn)行調(diào)度,即使用親和性規(guī)則為 Pod 的節(jié)點(diǎn)分配定義硬性要求和軟性要求。例如可以將 Pod 配置為僅運(yùn)行帶有 GPU 的節(jié)點(diǎn),并且最好使用 NVIDIA_TESLA_V100 運(yùn)行深度學(xué)習(xí)工作負(fù)載。Scheduler 會(huì)評估規(guī)則,并在定義的約束內(nèi)找到合適的節(jié)點(diǎn)。與 nodeSelectors 相似,節(jié)點(diǎn)親和性規(guī)則可與節(jié)點(diǎn)標(biāo)簽一起使用,但它比 nodeSelectors 更強(qiáng)大。

我們可以為 podspec 添加四個(gè)相似性規(guī)則:

requiredDuringSchedulingIgnoredDuringExecution

requiredDuringSchedulingRequiredDuringExecution

preferredDuringSchedulingIgnoredDuringExecution

preferredDuringSchedulingRequiredDuringExecution

這四個(gè)規(guī)則由兩個(gè)條件組成:必需或首選條件,以及兩個(gè)階段:計(jì)劃和執(zhí)行。以 required 開頭的規(guī)則描述了必須滿足的嚴(yán)格要求。以 preferred 開頭的規(guī)則是軟性要求,將強(qiáng)制執(zhí)行但不能保證。調(diào)度階段是指將 Pod 首次分配給節(jié)點(diǎn)。執(zhí)行階段適用于在調(diào)度分配后節(jié)點(diǎn)標(biāo)簽發(fā)生更改的情況。

如果規(guī)則聲明為 IgnoredDuringExecution,Scheduler 在第一次分配后不會(huì)檢查其有效性。但如果使用 RequiredDuringExecution 指定了規(guī)則,Scheduler 會(huì)通過將容器移至合適的節(jié)點(diǎn)來確保規(guī)則的有效性。

以下是示例:

apiVersion: v1kind: Pod

metadata:

name: nginx

spec:

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms

- matchExpressions:

- key: topology.kubernetes.io/region

operator: In

values:

- us-east

preferredDuringSchedulingIgnoredDuringExecution:

- weight: 1

preference:

matchExpressions:

- key: topology.kubernetes.io/zone

operator: In

values:

- us-east-1

- us-east-2

containers:

- name: nginx

image: nginx

上面的 Nginx Pod 具有節(jié)點(diǎn)親和性規(guī)則,該規(guī)則讓 Kubernetes Scheduler 將 Pod 放置在 us-east 的節(jié)點(diǎn)上。第二條規(guī)則指示優(yōu)先使用 us-east-1 或 us-east-2。

使用親和性規(guī)則,我們可以讓 Kubernetes 調(diào)度決策適用于自定義需求。

Taint 與 Toleration

集群中并非所有 Kubernetes 節(jié)點(diǎn)都相同。某些節(jié)點(diǎn)可能具有特殊的硬件,例如 GPU、磁盤或網(wǎng)絡(luò)功能。同樣,我們可能需要將一些節(jié)點(diǎn)專用于測試、數(shù)據(jù)保護(hù)或用戶組。我們可以將 Taint 添加到節(jié)點(diǎn)以排斥 Pod,如以下示例所示:

kubectl taint nodes node1 test-environment=true:NoSchedule

使用 test-environment=true:NoScheduletaint 時(shí),除非在 podspec 具有匹配的 toleration,否則 Kubernetes Scheduler 將不會(huì)分配任何 pod:

apiVersion: v1kind: Pod

metadata:

name: nginx

spec:

containers:

- name: nginx

image: nginx

tolerations:

- key: “test-environment”

operator: “Exists”

effect: “NoSchedule”

taint 和 tolerations 共同發(fā)揮作用,讓 Kubernetes Scheduler 專用于某些節(jié)點(diǎn)并分配特定 Pod。

調(diào)度瓶頸

盡管 Kubernetes Scheduler 能選擇最佳節(jié)點(diǎn),但是在 Pod 開始運(yùn)行之后,“最佳節(jié)點(diǎn)”可能會(huì)改變。所以從長遠(yuǎn)來看,Pod 的資源使用及其節(jié)點(diǎn)分配可能存在問題。

資源請求(Request)和限制(Limit):“Noisy Neighbor”

“Noisy Neighbor”并不特定于 Kubernetes。任何多租戶系統(tǒng)都是它們的潛在地。假設(shè)有兩個(gè)容器 A 和 B,它們在同一節(jié)點(diǎn)上運(yùn)行。如果 Pod B 試圖通過消耗所有 CPU 或內(nèi)存來創(chuàng)造 noise,Pod A 將出現(xiàn)問題。如果我們?yōu)槿萜髟O(shè)置了資源請求和限制就能控制住 neighbor。Kubernetes 將確保為容器安排其請求的資源,并且不會(huì)消耗超出其資源限制的資源。如果在生產(chǎn)中運(yùn)行 Kubernetes,最好設(shè)置資源請求和限制以確保系統(tǒng)可靠。

系統(tǒng)進(jìn)程資源不足

Kubernetes 節(jié)點(diǎn)主要是連接到 Kubernetes 控制平面的虛擬機(jī)。因此,節(jié)點(diǎn)上也有自己的操作系統(tǒng)和相關(guān)進(jìn)程。如果 Kubernetes 工作負(fù)載消耗了所有資源,則這些節(jié)點(diǎn)將無法運(yùn)行,并會(huì)發(fā)生各種問題問題。我們需要在 kubelet 中使用 –system -reserved 設(shè)置保留資源,以防止發(fā)生這種情況。

搶占或調(diào)度 Pod

如果 Kubernetes Scheduler 無法將 Pod 調(diào)度到可用節(jié)點(diǎn),則可以從節(jié)點(diǎn)搶占(preempt)或驅(qū)逐(evict)一些 Pod 以分配資源。如果看到 Pod 在集群中移動(dòng)而沒有發(fā)現(xiàn)特定原因,可以使用優(yōu)先級類對其進(jìn)行定義。同樣,如果沒有調(diào)度好 Pod,并且正在等待其他 Pod,也需要檢查其優(yōu)先級。

以下是示例:

apiVersion: scheduling.k8s.io/v1kind: PriorityClass

metadata:

name: high-priority-nonpreempting

value: 100000preemptionPolicy: NeverglobalDefault: false

description: “This priority class will not preempt other pods.”

可以通過以下方式在 podspec 中為分配優(yōu)先級:

apiVersion: v1kind: Pod

metadata:

name: nginx

spec:

containers:

- name: nginx

image: nginx

priorityClassName: high-priority-nonpreempting

調(diào)度框架

Kubernetes Scheduler 具有可插拔的調(diào)度框架架構(gòu),可向框架添加一組新的插件。插件實(shí)現(xiàn) Plugin API,并被編譯到調(diào)度程序中。下面我們將討論調(diào)度框架的工作流、擴(kuò)展點(diǎn)和 Plugin API。

工作流和擴(kuò)展點(diǎn)

調(diào)度 Pod 包括兩個(gè)階段:調(diào)度周期(scheduling cycle)和綁定周期(binding cycle)。在調(diào)度周期中,Scheduler 會(huì)找到一個(gè)可用節(jié)點(diǎn),然后在綁定過程中,將決策應(yīng)用于集群。

工作流中的以下幾點(diǎn)對插件擴(kuò)展開放:

QueueSort:對隊(duì)列中的 Pod 進(jìn)行排序

PreFilter:檢查預(yù)處理 Pod 的相關(guān)信息以安排調(diào)度周期

Filter:過濾不適合該 Pod 的節(jié)點(diǎn)

PostFilter:如果找不到可用于 Pod 的可行節(jié)點(diǎn),調(diào)用該插件

PreScore:運(yùn)行 PreScore 任務(wù)以生成一個(gè)可共享狀態(tài)供 Score 插件使用

Score:通過調(diào)用每個(gè) Score 插件對過濾的節(jié)點(diǎn)進(jìn)行排名

NormalizeScore:合并分?jǐn)?shù)并計(jì)算節(jié)點(diǎn)的最終排名

Reserve:在綁定周期之前選擇保留的節(jié)點(diǎn)

Permit:批準(zhǔn)或拒絕調(diào)度周期結(jié)果

PreBind:執(zhí)行任何先決條件工作,例如配置網(wǎng)絡(luò)卷

Bind:將 Pod 分配給 Kubernetes API 中的節(jié)點(diǎn)

PostBind:通知綁定周期的結(jié)果

插件擴(kuò)展實(shí)現(xiàn)了 Plugin API,是 Kubernetes Scheduler 的一部分。我們可以在 Kubernetes 存儲(chǔ)庫中檢查。插件應(yīng)使用以下名稱進(jìn)行注冊:

// Plugin is the parent type for all the scheduling framework plugins.

type Plugin interface {

Name() string

}

插件還實(shí)現(xiàn)了相關(guān)的擴(kuò)展點(diǎn),如下所示:

// QueueSortPlugin is an interface that must be implemented by “QueueSort” plugins.

// These plugins are used to sort pods in the scheduling queue. Only one queue sort plugin may be enabled at a time.

type QueueSortPlugin interface {

Plugin

// Less are used to sort pods in the scheduling queue.

Less(*QueuedPodInfo, *QueuedPodInfo) bool

}

Scheduler 性能調(diào)整

Kubernetes Scheduler 有一個(gè)工作流來查找和綁定 Pod 的可行節(jié)點(diǎn)。當(dāng)集群中的節(jié)點(diǎn)數(shù)量非常多時(shí),Scheduler 的工作量將成倍增加。在大型集群中,可能需要很長時(shí)間才能找到最佳節(jié)點(diǎn),因此要微調(diào)調(diào)度程序的性能,以在延遲和準(zhǔn)確性之間找到折中方案。

percentageOfNodesToScore 將限制節(jié)點(diǎn)的數(shù)量來計(jì)算自己的分?jǐn)?shù)。默認(rèn)情況下,Kubernetes 在 100 節(jié)點(diǎn)集群的 50% 和 5000 節(jié)點(diǎn)集群的 10% 之間設(shè)置線性閾值。默認(rèn)最小值為 5%,它要確保至少考慮集群中 5% 節(jié)點(diǎn)的調(diào)度。

下面的示例展示了如何通過性能調(diào)整 kube-scheduler 來手動(dòng)設(shè)置閾值:

apiVersion: kubescheduler.config.k8s.io/v1alpha1

kind: KubeSchedulerConfiguration

algorithmSource:

provider: DefaultProvider

percentageOfNodesToScore: 50

如果有一個(gè)龐大的集群并且 Kubernetes 工作負(fù)載不能承受 Kubernetes Scheduler 引起的延遲,那么更改百分比是個(gè)好主意。

總結(jié)

本文涵蓋了 Kubernetes 調(diào)度的大多方面,從 Pod 和節(jié)點(diǎn)的配置開始,包括 nodeSelector、親和性規(guī)則、taint 和 toleration,然后介紹了 Kubernetes Scheduler 框架、擴(kuò)展點(diǎn)、API 以及可能發(fā)生的與資源相關(guān)的瓶頸,最后展示了性能調(diào)整設(shè)置。盡管 Kubernetes Scheduler 能簡單地將 Pod 分配給節(jié)點(diǎn),但是了解其動(dòng)態(tài)性并對其進(jìn)行配置以實(shí)現(xiàn)可靠的生產(chǎn)級 Kubernetes 設(shè)置至關(guān)重要。

原文鏈接:https://thenewstack.io/a-deep-dive-into-kubernetes-scheduling/

作者:Ron Sobol. 翻譯:Bach(才云)

校對:星空下的文仔(才云)、bot(才云)

責(zé)任編輯:haq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • kubernetes
    +關(guān)注

    關(guān)注

    0

    文章

    224

    瀏覽量

    8712

原文標(biāo)題:Kubernetes 調(diào)度詳解

文章出處:【微信號:aming_linux,微信公眾號:阿銘linux】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    電力系統(tǒng)中電動(dòng)車充電樁布局與調(diào)度的優(yōu)化策略探究

    15821697760 摘要:本文深入鉆研電動(dòng)車充電樁于電力系統(tǒng)布局及調(diào)度的問題,融合地理信息系統(tǒng)與電網(wǎng)模型,綜合考慮電力供應(yīng)能力、民眾電動(dòng)車出行需求以及充電設(shè)備安全等要素,構(gòu)建多因多目標(biāo)優(yōu)化模型
    的頭像 發(fā)表于 12-13 16:39 ?207次閱讀
    電力系統(tǒng)中電動(dòng)車充電樁布局與<b class='flag-5'>調(diào)度</b>的優(yōu)化策略探究

    對于電力系統(tǒng)中新能源電動(dòng)車充電樁布局與調(diào)度優(yōu)化方法的研究

    本文針對電動(dòng)車充電樁在電力系統(tǒng)布局及調(diào)度方面進(jìn)行深入研究,借鑒地理信息系統(tǒng)與電網(wǎng)模型,綜合考量電力供應(yīng)的能力,大眾對電動(dòng)車出行需求,以及充電設(shè)備的安全,多因多目標(biāo)優(yōu)化模型誕生。有效地確定充電樁的*優(yōu)布局方案。
    的頭像 發(fā)表于 12-12 08:39 ?163次閱讀
    對于電力系統(tǒng)中新能源電動(dòng)車充電樁布局與<b class='flag-5'>調(diào)度</b>優(yōu)化方法的<b class='flag-5'>研究</b>

    電動(dòng)汽車有序充放電分群調(diào)度:原理、策略與平臺(tái)應(yīng)用的深度剖析與展望

    分群調(diào)度策略實(shí)施步驟、挑戰(zhàn)及效果評估體系。結(jié)論顯示該策略在提升電網(wǎng)效率與用戶滿意度方面成果顯著,未來仍需在技術(shù)創(chuàng)新、用戶行為探究及政策協(xié)同等方面深入挖掘。 關(guān)鍵詞:電動(dòng)汽車;有序充放電;分群調(diào)度;智能優(yōu)化算法 1.
    的頭像 發(fā)表于 12-04 16:36 ?364次閱讀
    電動(dòng)汽車有序充放電分群<b class='flag-5'>調(diào)度</b>:原理、策略與平臺(tái)應(yīng)用的深度剖析與展望

    基于量子計(jì)算技術(shù)的AGV調(diào)度問題研究

    由于自動(dòng)化和智能化的普及,AGV(自動(dòng)導(dǎo)引車)調(diào)度問題在物流、運(yùn)輸和生產(chǎn)領(lǐng)域有著廣泛的應(yīng)用。 隨著AGV數(shù)量的增加,經(jīng)典計(jì)算方法難以滿足大規(guī)模調(diào)度的需求,而玻色量子自研的相干光量子計(jì)算技術(shù)具有強(qiáng)大
    的頭像 發(fā)表于 11-11 09:36 ?240次閱讀
    基于量子計(jì)算技術(shù)的AGV<b class='flag-5'>調(diào)度</b>問題<b class='flag-5'>研究</b>

    構(gòu)建語音控制機(jī)器人 - 深入研究電路

    2024-07-29 |Annabel Ng S1XT33N項(xiàng)目 正如[之前的博客文章]中提到的,加州大學(xué)伯克利分校的 EECS 16B 課程重點(diǎn)關(guān)注構(gòu)建名為 S1XT33N 的語音控制機(jī)器人的為期一個(gè)學(xué)期的項(xiàng)目。然而,這個(gè)機(jī)器人并不是你在初中或高中時(shí)建造的標(biāo)準(zhǔn)機(jī)器人汽車。我和我的實(shí)驗(yàn)室伙伴只獲得了基本的兩輪機(jī)器人組件,包括輪子、電機(jī)、底盤、Arduino Leonardo、電池和面包板,我們必須自己構(gòu)建和連接其他所有組件。如果您有興趣了解有關(guān)該課程的更多信息,請?jiān)L問課程網(wǎng)站[https://www.eec
    的頭像 發(fā)表于 10-02 16:40 ?234次閱讀
    構(gòu)建語音控制機(jī)器人 - <b class='flag-5'>深入研究</b>電路

    深入探討Linux的進(jìn)程調(diào)度

    Linux操作系統(tǒng)作為一個(gè)開源且廣泛應(yīng)用的操作系統(tǒng),其內(nèi)核設(shè)計(jì)包含了許多核心功能,而進(jìn)程調(diào)度器(Scheduler)就是其中一個(gè)至關(guān)重要的模塊。進(jìn)程調(diào)度器負(fù)責(zé)決定在任何給定的時(shí)刻哪個(gè)進(jìn)程可以運(yùn)行
    的頭像 發(fā)表于 08-13 13:36 ?939次閱讀
    <b class='flag-5'>深入</b>探討Linux的進(jìn)程<b class='flag-5'>調(diào)度</b>器

    使用Velero備份Kubernetes集群

    Velero 是 heptio 團(tuán)隊(duì)(被 VMWare 收購)開源的 Kubernetes 集群備份、遷移工具。
    的頭像 發(fā)表于 08-05 15:43 ?348次閱讀
    使用Velero備份<b class='flag-5'>Kubernetes</b>集群

    如何使用Kubeadm命令在PetaExpress Ubuntu系統(tǒng)上安裝Kubernetes集群

    Kubernetes,通??s寫為K8s,是一個(gè)開源的容器編排平臺(tái),旨在自動(dòng)化容器化應(yīng)用的部署、擴(kuò)展和管理。有了Kubernetes,您可以輕松地部署、更新和擴(kuò)展應(yīng)用,而無需擔(dān)心底層基礎(chǔ)設(shè)施。
    的頭像 發(fā)表于 07-15 13:31 ?857次閱讀
    如何使用Kubeadm命令在PetaExpress Ubuntu系統(tǒng)上安裝<b class='flag-5'>Kubernetes</b>集群

    倫敦商學(xué)院深入研究中國神州數(shù)碼戰(zhàn)略轉(zhuǎn)型

    China)數(shù)字化轉(zhuǎn)型歷程的深入研究為基礎(chǔ),共同撰寫了案例研究「神州數(shù)碼的轉(zhuǎn)型:駕馭數(shù)據(jù)、云和人工智能的潛力(The Transformation of Digital China
    的頭像 發(fā)表于 07-02 11:25 ?501次閱讀
    倫敦商學(xué)院<b class='flag-5'>深入研究</b>中國神州數(shù)碼戰(zhàn)略轉(zhuǎn)型

    AQY212S光耦合器:特性和應(yīng)用揭秘

    讓我們深入研究AQY212S的功能和應(yīng)用,揭開這款令人印象深刻的器件的神秘面紗。
    的頭像 發(fā)表于 01-19 16:01 ?1175次閱讀
    AQY212S光耦合器:特性和應(yīng)用揭秘

    Kubernetes Gateway API攻略教程

    Kubernetes Gateway API 剛剛 GA,旨在改進(jìn)將集群服務(wù)暴露給外部的過程。這其中包括一套更標(biāo)準(zhǔn)、更強(qiáng)大的 API資源,用于管理已暴露的服務(wù)。在這篇文章中,我將介紹 Gateway
    的頭像 發(fā)表于 01-12 11:32 ?882次閱讀
    <b class='flag-5'>Kubernetes</b> Gateway API攻略教程

    深入研究電路設(shè)計(jì)中的“地”之謎:詳解分類與作用應(yīng)用

    在電路設(shè)計(jì)中,地(Ground)是一個(gè)至關(guān)重要的概念,它承擔(dān)著電路中引導(dǎo)電流、穩(wěn)定電壓、保護(hù)設(shè)備等多重職責(zé)。
    的頭像 發(fā)表于 01-10 15:52 ?2425次閱讀
    <b class='flag-5'>深入研究</b>電路設(shè)計(jì)中的“地”之謎:詳解分類與作用應(yīng)用

    深入理解FFmpeg閱讀體驗(yàn)》+ 書收到了,嶄新的開篇

    今天收到了《深入理解FFmpeg》 嶄新的書,一個(gè)在2022年較近距離接觸過卻尚未深入研究的領(lǐng)域圖像處理。最近剛好在作這方面的研究,希望自己可以把握這次機(jī)會(huì),好好學(xué)習(xí)下 FFMpeg,相信可以讓自己
    發(fā)表于 01-07 18:57

    使用Jenkins和單個(gè)模板部署多個(gè)Kubernetes組件

    在持續(xù)集成和部署中,我們通常需要部署多個(gè)實(shí)例或組件到Kubernetes集群中。通過Jenkins的管道腳本,我們可以自動(dòng)化這個(gè)過程。在本文中,我將演示如何使用Jenkins Pipeline及單個(gè)
    的頭像 發(fā)表于 01-02 11:40 ?759次閱讀
    使用Jenkins和單個(gè)模板部署多個(gè)<b class='flag-5'>Kubernetes</b>組件

    Kubernetes RBAC:掌握權(quán)限管理的精髓

    Kubernetes RBAC(Role-Based Access Control)是 Kubernetes 中一項(xiàng)關(guān)鍵的安全功能,它通過細(xì)粒度的權(quán)限控制機(jī)制,確保集群資源僅被授權(quán)的用戶或服務(wù)賬號訪問。
    的頭像 發(fā)表于 12-25 09:43 ?471次閱讀
    RM新时代网站-首页