建站
咨詢
售后
建站咨詢
新聞中心
作者?| 曾凡松（逐靈）?阿里云容器平臺高級技術(shù)專家
本文整理自《CNCF x Alibaba 云原生技術(shù)公開課》第 16 講。
導(dǎo)讀：etcd?是用于共享配置和服務(wù)發(fā)現(xiàn)的分布式、一致性的 KV 存儲系統(tǒng)。本文從 etcd 項目發(fā)展所經(jīng)歷的幾個重要時刻開始，為大家介紹了 etcd 的總體架構(gòu)及其設(shè)計中的基本原理。希望能夠幫助大家更好的理解和使用 etcd。
一、etcd 項目的發(fā)展歷程
etcd 誕生于 CoreOS 公司，它最初是用于解決集群管理系統(tǒng)中 OS 升級的分布式并發(fā)控制以及配置文件的存儲與分發(fā)等問題?；诖?，etcd 被設(shè)計為提供高可用、強(qiáng)一致的小型 keyvalue 數(shù)據(jù)存儲服務(wù)。
項目當(dāng)前隸屬于 CNCF 基金會，被 AWS、Google、Microsoft、Alibaba 等大型互聯(lián)網(wǎng)公司廣泛使用。
最初，在 2013 年 6 月份由 CoreOS 公司向 GitHub 中提交了第一個版本的初始代碼。
到了 2014 年的 6 月，社區(qū)發(fā)生了一件事情，Kubernetes v0.4 版本發(fā)布。這里有必要介紹一下 Kubernetes 項目，它首先是一個容器管理平臺，由谷歌開發(fā)并貢獻(xiàn)給社區(qū)，因為它集齊了谷歌在容器調(diào)度以及集群管理等領(lǐng)域的多年經(jīng)驗，從誕生之初就備受矚目。在 Kubernetes v0.4 版本中，它使用了 etcd 0.2 版本作為實(shí)驗核心元數(shù)據(jù)的存儲服務(wù)，自此 etcd 社區(qū)得到了飛速的發(fā)展。
很快，在 2015 年 2 月份，etcd 發(fā)布了第一個正式的穩(wěn)定版本 2.0。在 2.0 版本中，etcd 重新設(shè)計了 Raft 一致性算法，并為用戶提供了一個簡單的樹形數(shù)據(jù)視圖，在 2.0 版本中 etcd 支持每秒超過 1000 次的寫入性能，滿足了當(dāng)時絕大多數(shù)的應(yīng)用場景需求。2.0 版本發(fā)布之后，經(jīng)過不斷的迭代與改進(jìn)，其原有的數(shù)據(jù)存儲方案逐漸成為了新時期的性能瓶頸，之后 etcd 啟動了 v3 版本的方案設(shè)計。
2017 年 1 月份的時候，etcd 發(fā)布了 3.1 版本，v3 版本方案基本上標(biāo)志著 etcd 技術(shù)上全面成熟。在 v3 版本中 etcd 提供了一套全新的 API，重新實(shí)現(xiàn)了更高效的一致性讀取方法，并且提供了一個 gRPC 的 proxy 用于擴(kuò)展 etcd 的讀取性能。同時，在 v3 版本的方案中包含了大量的 GC 優(yōu)化，在性能優(yōu)化方面取得了長足的進(jìn)步，在該版本中 etcd 可以支持每秒超過 10000 次的寫入。
2018 年，CNCF 基金會下的眾多項目都使用了 etcd 作為其核心的數(shù)據(jù)存儲。據(jù)不完全統(tǒng)計，使用 etcd 的項目超過了 30 個，在同年 11 月份，etcd 項目自身也成為了 CNCF 旗下的孵化項目。進(jìn)入 CNCF 基金會后，etcd 擁有了超過 400 個貢獻(xiàn)組，其中包含了來自 AWS、Google、Alibaba 等 8 個公司的 9 個項目維護(hù)者。
2019 年，etcd 即將發(fā)布全新的 3.4 版本，該版本由 Google、Alibaba 等公司聯(lián)合打造，將進(jìn)一步改進(jìn) etcd 的性能及穩(wěn)定性，以滿足在超大型公司使用中苛刻的場景要求。
二、架構(gòu)及內(nèi)部機(jī)制解析
總體架構(gòu)
etcd 是一個分布式的、可靠的 key-value 存儲系統(tǒng)，它用于存儲分布式系統(tǒng)中的關(guān)鍵數(shù)據(jù)，這個定義非常重要。
一個 etcd 集群，通常會由 3 個或者 5 個節(jié)點(diǎn)組成，多個節(jié)點(diǎn)之間通過 Raft 一致性算法的完成分布式一致性協(xié)同，算法會選舉出一個主節(jié)點(diǎn)作為 leader，由 leader 負(fù)責(zé)數(shù)據(jù)的同步與數(shù)據(jù)的分發(fā)。當(dāng) leader 出現(xiàn)故障后系統(tǒng)會自動地選取另一個節(jié)點(diǎn)成為 leader，并重新完成數(shù)據(jù)的同步?？蛻舳嗽诙鄠€節(jié)點(diǎn)中，僅需要選擇其中的任意一個就可以完成數(shù)據(jù)的讀寫，內(nèi)部的狀態(tài)及數(shù)據(jù)協(xié)同由 etcd 自身完成。
在 etcd 整個架構(gòu)中，有一個非常關(guān)鍵的概念叫做 quorum，quorum 的定義是 （n+1）/2，也就是說超過集群中半數(shù)節(jié)點(diǎn)組成的一個團(tuán)體，在 3 個節(jié)點(diǎn)的集群中，etcd 可以容許 1 個節(jié)點(diǎn)故障，也就是只要有任何 2 個節(jié)點(diǎn)可用，etcd 就可以繼續(xù)提供服務(wù)。同理，在 5 個節(jié)點(diǎn)的集群中，只要有任何 3 個節(jié)點(diǎn)可用，etcd 就可以繼續(xù)提供服務(wù)，這也是 etcd 集群高可用的關(guān)鍵。
在允許部分節(jié)點(diǎn)故障之后繼續(xù)提供服務(wù)，就需要解決一個非常復(fù)雜的問題：分布式一致性。在 etcd 中，該分布式一致性算法由 Raft 一致性算法完成，這個算法本身是比較復(fù)雜的有機(jī)會再詳細(xì)展開，這里僅做一個簡單的介紹以方便大家對其有一個基本的認(rèn)知。Raft 一致性算法能夠工作的一個關(guān)鍵點(diǎn)是：任意兩個 quorum 的成員之間一定會有一個交集（公共成員），也就是說只要有任意一個 quorum 存活，其中一定存在某一個節(jié)點(diǎn)（公共成員），它包含著集群中所有的被確認(rèn)提交的數(shù)據(jù)。正是基于這一原理，Raft 一致性算法設(shè)計了一套數(shù)據(jù)同步機(jī)制，在 Leader 任期切換后能夠重新同步上一個 quorum 被提交的所有數(shù)據(jù)，從而保證整個集群狀態(tài)向前推進(jìn)的過程中保持?jǐn)?shù)據(jù)的一致。
etcd 內(nèi)部的機(jī)制比較復(fù)雜，但 etcd 給客戶提供的接口是簡單直接的。如上圖所示，我們可以通過 etcd 提供的客戶端去訪問集群的數(shù)據(jù)，也可以直接通過 http 的方式（類似 curl 命令）直接訪問 etcd。在 etcd 內(nèi)部，其數(shù)據(jù)表示也是比較簡單的，我們可以直接把 etcd 的數(shù)據(jù)存儲理解為一個有序的 map，它存儲著 key-value 數(shù)據(jù)。同時 etcd 為了方便客戶端去訂閱數(shù)據(jù)的變更，也支持了一個 watch 機(jī)制，通過 watch 實(shí)時地拿到 etcd 中數(shù)據(jù)的增量更新，從而實(shí)現(xiàn)與 etcd 中的數(shù)據(jù)同步等業(yè)務(wù)邏輯。
API 介紹
接下來我們看一下 etcd 提供的接口，這里將 etcd 的接口分為了 5 組：
- 第一組是 Put 與 Delete。上圖可以看到 put 與 delete 的操作都非常簡單，只需要提供一個 key 和一個 value，就可以向集群中寫入數(shù)據(jù)了，刪除數(shù)據(jù)的時候只需要指定 key 即可；
- 第二組是查詢操作。etcd 支持兩種類型的查詢：第一種是指定單個 key 的查詢，第二種是指定的一個 key 的范圍；
- 第三組是數(shù)據(jù)訂閱。etcd 提供了 Watch 機(jī)制，我們可以利用 watch 實(shí)時訂閱到 etcd 中增量的數(shù)據(jù)更新，watch 支持指定單個 key，也可以指定一個 key 的前綴，在實(shí)際應(yīng)用場景中的通常會采用第二種形勢；
- 第四組事務(wù)操作。etcd 提供了一個簡單的事務(wù)支持，用戶可以通過指定一組條件滿足時執(zhí)行某些動作，當(dāng)條件不成立的時候執(zhí)行另一組操作，類似于代碼中的 if else 語句，etcd 確保整個操作的原子性；
- 第五組是 Leases 接口。Leases 接口是分布式系統(tǒng)中常用的一種設(shè)計模式，其用法后面會具體展開。
數(shù)據(jù)版本機(jī)制
要正確使用 etcd 的 API，必須要知道內(nèi)部對應(yīng)數(shù)據(jù)版本號的基本原理。
首先 etcd 中有個 term 的概念，代表的是整個集群 Leader 的任期。當(dāng)集群發(fā)生 Leader 切換，term 的值就會 +1。在節(jié)點(diǎn)故障，或者 Leader 節(jié)點(diǎn)網(wǎng)絡(luò)出現(xiàn)問題，再或者是將整個集群停止后再次拉起，都會發(fā)生 Leader 的切換。
第二個版本號叫做 revision，revision 代表的是全局?jǐn)?shù)據(jù)的版本。當(dāng)數(shù)據(jù)發(fā)生變更，包括創(chuàng)建、修改、刪除，其 revision 對應(yīng)的都會 +1。特別的，在集群中跨 Leader 任期之間，revision 都會保持全局單調(diào)遞增。正是 revision 的這一特性，使得集群中任意一次的修改都對應(yīng)著一個唯一的 revision，因此我們可以通過 revision 來支持?jǐn)?shù)據(jù)的 MVCC，也可以支持?jǐn)?shù)據(jù)的 Watch。
對于每一個 KeyValue 數(shù)據(jù)節(jié)點(diǎn)，etcd 中都記錄了三個版本：
- 第一個版本叫做 create_revision，是 KeyValue 在創(chuàng)建時對應(yīng)的 revision；
- 第二個叫做 mod_revision，是其數(shù)據(jù)被操作的時候?qū)?yīng)的 revision；
- 第三個 version 就是一個計數(shù)器，代表了 KeyValue 被修改了多少次。
這里可以用圖的方式給大家展示一下：
在同一個 Leader 任期之內(nèi)，我們發(fā)現(xiàn)所有的修改操作，其對應(yīng)的 term 值始終都等于 2，而 revision 則保持單調(diào)遞增。當(dāng)重啟集群之后，我們會發(fā)現(xiàn)所有的修改操作對應(yīng)的 term 值都變成了 3。在新的 Leader 任期內(nèi)，所有的 term 值都等于3，且不會發(fā)生變化，而對應(yīng)的 revision 值同樣保持單調(diào)遞增。從一個更大的維度去看，可以發(fā)現(xiàn)在 term=2 和 term=3 的兩個 Leader 任期之間，數(shù)據(jù)對應(yīng)的 revision 值依舊保持了全局單調(diào)遞增。
mvcc & streaming watch
了解 etcd 的版本號控制后，接下來如何使用 etcd 多版本號來實(shí)現(xiàn)并發(fā)控制以及數(shù)據(jù)訂閱（Watch）。
在 etcd 中支持對同一個 Key 發(fā)起多次數(shù)據(jù)修改，每次數(shù)據(jù)修改都對應(yīng)一個版本號。etcd 在實(shí)現(xiàn)上記錄了每一次修改對應(yīng)的數(shù)據(jù)，也就就意味著一個 key 在 etcd 中存在多個歷史版本。在查詢數(shù)據(jù)的時候如果不指定版本號，etcd 會返回 Key 對應(yīng)的最新版本，當(dāng)然 etcd 也支持指定一個版本號來查詢歷史數(shù)據(jù)。
因為 etcd 將每一次修改都記錄了下來，使用 watch 訂閱數(shù)據(jù)時，可以支持從任意歷史時刻（指定 revision）開始創(chuàng)建一個 watcher，在客戶端與 etcd 之間建立一個數(shù)據(jù)管道，etcd 會推送從指定 revision 開始的所有數(shù)據(jù)變更。etcd 提供的 watch 機(jī)制保證，該 Key 的數(shù)據(jù)后續(xù)的被修改之后，通過這個數(shù)據(jù)管道即時的推送給客戶端。
如下圖所示，etcd 中所有的數(shù)據(jù)都存儲在一個 b+tree 中（灰色），該 b+tree 保存在磁盤中，并通過?mmap 的方式映射到內(nèi)存用來支持快速的訪問?；疑?b+tree 中維護(hù)著 revision 到 value 的映射關(guān)系，支持通過 revision 查詢對應(yīng)的數(shù)據(jù)。因為 revision 是單調(diào)遞增的，當(dāng)我們通過 watch 來訂閱指定 revision 之后的數(shù)據(jù)時，僅需要訂閱該 b+ tree 的數(shù)據(jù)變化即可。
在 etcd 內(nèi)部還維護(hù)著另外一個 btree（藍(lán)色），它管理著 key 到 revision 的映射關(guān)系。當(dāng)客戶端使用 key 查詢數(shù)據(jù)時，首先需要經(jīng)過藍(lán)色的 btree 將 key 轉(zhuǎn)化為對應(yīng)的 revision，再通過灰色的 btree 查詢到對應(yīng)的數(shù)據(jù)。
細(xì)心的讀者會發(fā)現(xiàn)，etcd 將每一次修改都記錄下來會導(dǎo)致數(shù)據(jù)持續(xù)增長，這會帶來內(nèi)存及磁盤的空間消耗，同時也會影響 b+tree 的查詢效率。為了解決這一問題，在 etcd 中會運(yùn)行一個周期性的 Compaction 的機(jī)制來清理歷史數(shù)據(jù)，將一段時間之前的同一個 Key 的多個歷史版本數(shù)據(jù)清理掉。最終的結(jié)果是灰色的 b+tree 依舊保持單調(diào)遞增，但可能會出現(xiàn)一些空洞。
mini-transactions
在理解了 mvcc 機(jī)制及 watch 機(jī)制之后，繼續(xù)看 etcd 提供的 mini-transactions 機(jī)制。etcd 的 transaction 機(jī)制比較簡單，基本可以理解為一段 if-else 程序，在 if 中可以提供多個操作，如下圖所示：
If 里面寫了兩個條件，當(dāng) Value(key1) 大于 "bar" 并且 Version(key1) 的版本等于 2 的時候，執(zhí)行 Then 里面指定的操作：修改 Key2 的數(shù)據(jù)為 valueX，同時刪除 Key3 的數(shù)據(jù)。如果不滿足條件，則執(zhí)行另外一個操作：Key2 修改為 valueY。
在 etcd 內(nèi)部會保證整個事務(wù)操作的原子性。也就是說 If 操作所有的比較條件，其看到的視圖一定是一致的。同時它能夠確保多個操作的原子性不會出現(xiàn) Then 中的操作僅執(zhí)行了一半的情況。
通過 etcd 提供的事務(wù)操作，我們可以在多個競爭中去保證數(shù)據(jù)讀寫的一致性，比如說前面已經(jīng)提到過的 Kubernetes 項目，它正是利用了 etcd 的事務(wù)機(jī)制，來實(shí)現(xiàn)多個 KubernetesAPI server 對同樣一個數(shù)據(jù)修改的一致性。
lease 的概念及用法
lease 是分布式系統(tǒng)中一個常見的概念，用于代表一個分布式租約。典型情況下，在分布式系統(tǒng)中需要去檢測一個節(jié)點(diǎn)是否存活的時，就需要租約機(jī)制。
上圖示例中的代碼示例首先創(chuàng)建了一個 10s 的租約，如果創(chuàng)建租約后不做任何的操作，那么 10s 之后，這個租約就會自動過期。接著將 key1 和 key2 兩個 key value 綁定到這個租約之上，這樣當(dāng)租約過期時 etcd 就會自動清理掉 key1 和 key2，使得節(jié)點(diǎn) key1 和 key2 具備了超時自動刪除的能力。
如果希望這個租約永不過期，需要周期性的調(diào)用 KeeyAlive 方法刷新租約。比如說需要檢測分布式系統(tǒng)中一個進(jìn)程是否存活，可以在進(jìn)程中去創(chuàng)建一個租約，并在該進(jìn)程中周期性的調(diào)用 KeepAlive 的方法。如果一切正常，該節(jié)點(diǎn)的租約會一致保持，如果這個進(jìn)程掛掉了，最終這個租約就會自動過期。
在 etcd 中，允許將多個 key 關(guān)聯(lián)在同一個 lease 之上，這個設(shè)計是非常巧妙的，可以大幅減少 lease 對象刷新帶來的開銷。試想一下，如果有大量的 key 都需要支持類似的租約機(jī)制，每一個 key 都需要獨(dú)立的去刷新租約，這會給? etcd 帶來非常大的壓力。通過多個 key 綁定在同一個 lease 的模式，我們可以將超時間相似的 key 聚合在一起，從而大幅減小租約刷新的開銷，在不失靈活性同時能夠大幅提高 etcd 支持的使用規(guī)模。
三、典型的使用場景介紹
元數(shù)據(jù)存儲
Kubernetes 將自身所用的狀態(tài)存儲在 etcd 中，其狀態(tài)數(shù)據(jù)的高可用交給 etcd 來解決，Kubernetes 系統(tǒng)自身不需要再應(yīng)對復(fù)雜的分布式系統(tǒng)狀態(tài)處理，自身的系統(tǒng)架構(gòu)得到了大幅的簡化。
Server Discovery （Naming Service）
第二個場景是 Service Discovery，也叫做名字服務(wù)。在分布式系統(tǒng)中，通常會出現(xiàn)的一個模式就是需要多個后端（可能是成百上千個進(jìn)程）來提供一組對等的服務(wù)，比如說檢索服務(wù)、推薦服務(wù)。
對于這樣一種后端服務(wù)，通常情況下為了簡化后端服務(wù)的運(yùn)維成本（節(jié)點(diǎn)故障時隨時被替換），后端的這一進(jìn)程會被類似 Kubernetes 這樣的集群管理系統(tǒng)所調(diào)度，這樣當(dāng)用戶（或上游服務(wù)）調(diào)用過來時，我們就需要一個服務(wù)發(fā)現(xiàn)機(jī)制來解決服務(wù)路由問題。這一服務(wù)發(fā)現(xiàn)問題可以利用 etcd 來高效解決，方式如下：
- 在進(jìn)程內(nèi)部啟動之后，可以將自身所在的地址注冊到 etcd；
- API 網(wǎng)關(guān)夠通過 etcd 及時感知到后端進(jìn)程的地址，當(dāng)后端進(jìn)程發(fā)生故障遷移時會重新注冊到 etcd 中，API 網(wǎng)關(guān)也能夠及時地感知到新的地址；
- 利用 etcd 提供的?Lease 機(jī)制，如果提供服務(wù)的進(jìn)程運(yùn)行過程中出現(xiàn)了異常（crash），API 網(wǎng)關(guān)也可以摘除其流量避免調(diào)用超時。
在這一架構(gòu)中，服務(wù)狀態(tài)數(shù)據(jù)被 etcd 接管，API 網(wǎng)關(guān)本身也是無狀態(tài)的，可以水平地擴(kuò)展來服務(wù)更多的客戶。同時得益于 etcd 的良好性能，可以支持上萬個后端進(jìn)程的節(jié)點(diǎn)，使得這一架構(gòu)可以服務(wù)于大型的企業(yè)。
Distributed Coordination: leader election
在分布式系統(tǒng)中，有一種典型的設(shè)計模式就是 Master+Slave。通常情況下，Slave 提供了 CPU、內(nèi)存、磁盤以及網(wǎng)絡(luò)等各種資源 ，而 Master 用來調(diào)和這些節(jié)點(diǎn)以使其對外提供一個服務(wù)（比如分布式存儲，分布式計算）。典型的分布式存儲服務(wù)（HDFS）以及分布式計算服務(wù)（Hadoop）它們都是采用了類似這樣的設(shè)計模式。這樣的設(shè)計模式會有一個典型的問題：Master 節(jié)點(diǎn)的可用性。當(dāng) Master 故障以后，整個集群的服務(wù)就掛掉了，沒有辦法再服務(wù)用戶的請求。
為了解決這個問題，典型的做法就是啟動多個 Master 節(jié)點(diǎn)。因為 Master 節(jié)點(diǎn)內(nèi)會包含控制邏輯，多個節(jié)點(diǎn)之間的狀態(tài)同步是非常復(fù)雜的，這里最典型的做法就是通過選主的方式，選出其中一個節(jié)點(diǎn)作為主節(jié)點(diǎn)來提供服務(wù)，另一個節(jié)點(diǎn)處于等待狀態(tài)。
通過 etcd 提供的機(jī)制可以很容易的實(shí)現(xiàn)分布式進(jìn)程的選主功能，比如可以通過對同一個 key 的事務(wù)寫來實(shí)現(xiàn)搶主的邏輯。一般而言，被選主的 Leader 會將自己的 IP 注冊到 etcd 中，使得 Slave 節(jié)點(diǎn)能夠及時獲取到當(dāng)前的 Leader 地址，從而使得系統(tǒng)按照之前單個 Master 節(jié)點(diǎn)的方式繼續(xù)工作。當(dāng) Leader 節(jié)點(diǎn)發(fā)生異常之后，通過 etcd 能夠選取出一個新的節(jié)點(diǎn)成為主節(jié)點(diǎn)，并且注冊新的 IP 之后，Slave 又能夠拉取新的主節(jié)點(diǎn)的 IP，繼續(xù)恢復(fù)服務(wù)。
Distributed Coordination 分布式系統(tǒng)并發(fā)控制
在分布式系統(tǒng)中，當(dāng)我們?nèi)?zhí)行一些任務(wù)，比如說去升級 OS、或者說升級 OS 上的軟件的時候、又或者去執(zhí)行一些計算任務(wù)的時候，出于對后端服務(wù)的瓶頸或者是業(yè)務(wù)穩(wěn)定性的考慮，通常情況下需要控制任務(wù)的并發(fā)度。如果該任務(wù)缺少一個調(diào)和的 Master 節(jié)點(diǎn)，可以通過 etcd 來完成這樣的分布式系統(tǒng)工作。
在這個模式中通過 etcd 去實(shí)現(xiàn)一個分布式的信號量，并且可以利用 etcd leases 機(jī)制來實(shí)現(xiàn)自動地剔除掉故障節(jié)點(diǎn)。在進(jìn)程執(zhí)行過程中，如果進(jìn)程的運(yùn)行周期比較長，我們可以將進(jìn)程運(yùn)行過程中的一些狀態(tài)數(shù)據(jù)存儲到 etcd，從而使得當(dāng)進(jìn)程故障之后且需要恢復(fù)到其他地方時，能夠從 etcd 中去恢復(fù)一些執(zhí)行狀態(tài)，而不需要重新去完成整個的計算邏輯，以此來加速整個任務(wù)的執(zhí)行效率。
本文總結(jié)
本文分享的主要內(nèi)容就到此為止了，這里為大家簡單總結(jié)一下：
- 第一部分，為大家介紹了 etcd 項目是如何誕生的，以及在 etcd 發(fā)展過程中經(jīng)歷的幾個重要時刻；
- 第二部分，為大家介紹了 etcd 的架構(gòu)以及其內(nèi)部的基本操作接口，在理解 etcd 是如何實(shí)現(xiàn)高可用的基礎(chǔ)之上，展示了 etcd 數(shù)據(jù)的一些基本操作以及其內(nèi)部的實(shí)現(xiàn)原理；
- 第三部分，介紹了三種典型的 etcd 使用場景，以及在對應(yīng)的場景下，分布式系統(tǒng)的設(shè)計思路。
“ 阿里巴巴云原生微信公眾號（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)公眾號?！?/p>
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
本文題目：從零開始入門K8s|手把手帶你理解etcd-創(chuàng)新互聯(lián)
路徑分享：http://www.dlmjj.cn/article/djdjcd.html
