⑴ etcd簡要使用
etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines.
從定義可以看到，etcd是一個key-value型存儲，具有強一致性
etcd的客戶端有etcdctl、etcd-go、etcd-java，其中etcdctl是etcd自帶的命令行工具，其主要命令有
etcd的數據是按照B+樹的方式組織，並按照MVCC的思想存儲數據，也就是數據按照多個版本存儲，每個版本都有一個版本號，當數據更新時，並非更新原有數據，而是再存儲一條新版本號數據。
在內存中，實際上有兩個B+樹，一個存儲key到revison的映射，一個存儲revison和value的映射。當進行get的時候，先到key-revison映射中查找revison，如果未制定版本號，就取最新的revison，然後用revison到revison-value的B+樹查找value。
為什麼要用B+樹，因為要支持范圍查找。
本文總結etcd的簡要使用，下篇再對底層原理進行解析。
⑵ RPC 框架使用 Etcd 作為注冊中心
對 etcd 來說,鍵值對( key-value pair )是最小可操作單元，每個鍵值對都有許多欄位,以 protobuf 格式定義。
除了鍵和值之外， etcd 還將附加的修訂元數據作為鍵消息的一部分 。該修訂信息按創建和修改的時間對鍵進行排序，這對於管理分布式同步的並發性非常有用。etcd客戶端的分布式共享鎖使用創建修改來等待鎖定所有權。類似地，修改修訂用於檢測軟體事務內存讀集沖突並等待領導人選舉更新。
申請租約
授權租約
撤銷
租約續約
⑶ go-micro的etcd服務注冊管理界面使用方法
我們在使用consul時，consul提供了管理界面，可很直觀的看到我們注冊到consul的服務及健康狀況。
etcd並未提供此功能，但是我們可以使用go-micro提供的一個簡易界面查看我們注冊到etcd中的服務
本文是基於【docker+etcd+go-micro api網關的搭建及使用】： https://www.jianshu.com/p/13d1df6e6731 ，這篇文章的環境基礎來實現的，沒有搭建docker+etcd+go-micro api網關的，可以按照上面的鏈接搭建一遍。
啟動這個管理界面也是使用go-micor的鏡像來操作，只是指令上有些變化，在啟動api網關時，我們使用的是api指令，如下：
docker run -d -p 8080:8080 --name=micro_api_gw ba526346c047 --registry=etcd --registry_address=192.168.109.131:12379 --api_namespace=api.tutor.com --api_handler=http api
這里我們使用web指令,如下：
docker run -d -p 8082:8082 --name=micro_etcd_monitor ba526346c047 --registry=etcd --registry_address=192.168.109.131:12379 --api_namespace=api.tutor.com web
啟動完成後，在瀏覽器輸入 http://192.168.109.131:8082/registry ，就可以看到如下界面（192.168.109.131是我的虛擬機ip，可以根據自己的機器調整）：
今天就介紹到這里
⑷ ETCD中K8S的元數據
假設你已經通過kubeadm 安裝好了K8S 和對應的etcd集群
Kubenretes1.6中使用etcd V3版本的API，使用etcdctl直接ls的話只能看到/kube-centos一個路徑。需要在命令前加上ETCDCTL_API=3這個環境變數才能看到kuberentes在etcd中保存的數據。
如果是使用 kubeadm 創建的集群，在 Kubenretes 1.11 中，etcd 默認使用 tls ，這時你可以在 master 節點上使用以下命令來訪問 etcd ：
-w指定輸出格式
將得到這樣的json的結果：
使用--prefix可以看到所有的子目錄，如查看集群中的namespace：
輸出結果中可以看到所有的namespace。
key的值是經過base64編碼，需要解碼後才能看到實際值，如：
etcd中kubernetes的元數據
我們使用kubectl命令獲取的kubernetes的對象狀態實際上是保存在etcd中的，使用下面的腳本可以獲取etcd中的所有kubernetes對象的key：
注意，我們使用了ETCD v3版本的客戶端命令來訪問etcd。
通過輸出的結果我們可以看到kubernetes的原數據是按何種結構包括在kuberentes中的，輸出結果如下所示：
我們可以看到所有的Kuberentes的所有元數據都保存在/registry目錄下，下一層就是API對象類型（復數形式），再下一層是namespace，最後一層是對象的名字。
以下是etcd中存儲的kubernetes所有的元數據類型：
轉自
⑸ kong網關怎麼獲取etcd埠
etcd簡介與應用場景 etcd 是一個分布式一致性k-v存儲系統,可用於服務注冊發現與...
2.
單機模式運行 默認在centos7的yum源里已集成了etcd包,可以通過yum進行安裝...
3.
集群模式說明 這里的集群模式是指完全集群模式,當然也可以在單機上通過不同的埠,部署偽...
4.
靜態模式 如果只是測試,這里建議使用二進制包進行測試。因為源碼包編譯的,使用etcd命令...
5.
動態配置 靜態配置前提是在搭建集群之前已經提前知道各節點的信息,而實際應用中可能
⑹ kubernetes控制平面組件：etcd
--listen-peer-urls
--listen-client-urls
--initial-advertise-peer-urls
--initial-cluster
--initial-cluster-state
--advertise-client-urls
1.code
headless svc, 像DNS RR ClusterIP:None
kubectl -n stg1 get endpoints
client 怎麼訪問：
2.配置文件
3.apply
官方的code有兩個問題
本地訪問
擴容
利用反親和性 分布etcd pod到不同節點
~ ❯❯❯ etcdctl get / --prefix
從 etcd 的架構圖中我們可以看到，etcd 主要分為四個部分。
etcd 目前支持 V2 和 V3 兩個大版本，這兩個版本在實現上有比較大的不同，一方面是對外提供介面的方式，另一方面就是底層的存儲引擎，V2 版本的實例是一個純內存的實現，所有的數據都沒有存儲在磁碟上，而 V3 版本的實例就支持了數據的持久化。
v3默認boltdb
consortium etcd2+mysql
數據默認會存放在 /var/lib/etcd/default/ 目錄。我們會發現數據所在的目錄，會被分為兩個文件夾中，分別是 snap 和 wal目錄。
解決三個問題：節點選舉、日誌復制以及安全性 。
每一個 Raft 集群中都包含多個伺服器，在任意時刻，每一台伺服器只可能處於 Leader 、 Follower 以及 Candidate 三種狀態；在處於正常的狀態時，集群中只會存在一個 Leader 狀態，其餘的伺服器都是 Follower 狀態。
所有的 Follower 節點都是被動的，它們不會主動發出任何的請求 ，只會響應 Leader 和 Candidate 發出的請求。對於每一個用戶的可變操作，都會被路由給 Leader 節點進行處理，除了 Leader 和 Follower 節點之外，Candidate 節點其實只是集群運行過程中的一個臨時狀態。
每一個伺服器都會存儲當前集群的最新任期，它就像是一個單調遞增的邏輯時鍾，能夠同步各個節點之間的狀態，當前節點持有的任期會隨著每一個請求被傳遞到其他的節點上。Raft 協議在每一個任期的開始時都會從一個集群中選出一個節點作為集群的 Leader 節點，這個節點會負責集群中的日誌的復制以及管理工作。
客戶端通過 監聽指定的key可以迅速感知key的變化並作出相應處理 ，watch機制的實現依賴於 資源版本號revision的設計 ，每一次key的更新都會使得revision原子遞增，因此根據不同的版本號revision的對比就可以感知新事件的發生。etcd watch機制有著廣泛的應用，比如利用etcd實現分布式鎖； k8s中監聽各種資源的變化 ，從而實現各種controller邏輯等。
watch機制的實現主要可分為三個部分
client使用 watchClient 的watch介面發起watch請求，與server端建立一個 gRPCStream 連接。
server端會為每個client生成唯一一個watch id，並記錄每個client也就是watcher監聽的key或者key range，通過recvLoop接收client請求，通過sendLoop發送請求，server端只負責收發請求和響應。
主要的實現都放在了watchalbStore層，watchalbStore會監聽key的變化，然後通過syncWatchersLoop和syncVictimsLoop兩個處理流程將key的更新變化包裝成event，通過channel發送給gRPC server。
MVCC（Multiversion Concurrency Control）多版本並發控制機制
場景1:
這就是悲觀鎖
悲觀鎖：悲觀得認為並發事務會沖突，所以要先拿鎖，拿到鎖的作修改操作
場景2
資料庫：寫回磁碟，A寫好了。哎，B和C都是version 13，我咋寫？算了，報錯吧。。
就是樂觀鎖，默認不加鎖，你盡管寫，沖突我認慫！樂觀鎖其實不是鎖，只是相對悲觀鎖來定義，適合讀多寫少。
樂觀鎖：樂觀得認為數據不會沖突，但發生沖突時要能檢測到。
場景3
這就是MVCC，在 MVCC 資料庫中，你更新一個 key-value 數據的時候，它並不會直接覆蓋原數據，而是 新增一個版本來存儲新的數據，每個數據都有一個版本號 ，版本號是一個邏輯時鍾，不會因為伺服器時間的差異而受影響。
MVCC不等於樂觀鎖！
--rev 查的是main
在底層boltdb里，實際分布是這樣的：
底層的key是revision，/奧特曼是用戶key，「他很帥」就是用戶value
刪除
之前有delete動作，但是依然有版本記錄。為什麼？
刪除這個動作，其實etcd是在blotdb里寫了一條，「刪除用戶/奧特曼」
此時有個問題：用戶說我的確刪除了啊，真的不要了！請把空間還給我啊！
回收 compact（壓縮）
etcdctl compact {version}
compact 需要一個版本號。這個版本號就是寫事務遞增的那個版本號，compact 12345，就是說把版本12345以前的 標記刪除了的數據 釋放掉，用戶沒刪除的數據肯定不能回收。
如何壓縮：
注意修改go.mod
Watch
服務發現要解決的也是分布式系統中最常見的問題之一，即在同一個分布式集群中的進程或服務，要如何才能找到對方並建立連接。本質上來說，服務發現就是想要了解集群中是否有進程在監聽 udp 或 tcp 埠，並且通過名字就可以查找和連接。
需要實現的功能；
discover.go
eBay payment
ebay kubernetes 控制面架構
問題
⑺ 使用etcd分布式鎖做主備切換
利用etcd事務機制可以實現分布式鎖，利用分布式鎖可以做主備切換功能。
Etcd分布式鎖實現方式如下：利用etcd事務機制向etcd創建key，若key不存在則創建key，獲取鎖成功，若key存在則獲取鎖失敗.
主備切換功能實現思路如下：各程序向etcd搶鎖，搶到鎖即為主，沒搶到為從，從程序會監視鎖是否釋放，若鎖釋放重新搶鎖。考慮到在網路不穩定的情況下，可能出現已經成為主的程序失去了鎖的擁有，某一個從程序搶到了鎖，但是已經成為主的程序並不知道自己失去了鎖，因此成為主的程序需要搶到鎖後不斷查詢目前鎖是否為自己擁有，若已經失去則標記自己為從並且重新搶鎖。
具體實現如下：
參考
https://studygolang.com/articles/16307?fr=sidebar
https://www.jianshu.com/p/d3068d0ac7c1
https://yq.aliyun.com/articles/70546
"go.etcd.io/etcd/clientv3/concurrency"包的example_mutex_test.go/session.go/mutex.go/key.go