使用Kubernetes和Docker進行簡單的leader選舉
來自： http://dockone.io/article/968
【編者的話】Kubernetes簡化了運行在集群中的服務部署和運維管理，然而，它也簡化了這些管理工作的部署。本篇文章將會展示如何在分布式應用系統中使用Kubernetes來簡單地運行leader選舉。
概述
為了可靠性和伸縮性，分布式系統通常會復制多個服務任務，但往往有必要指定一個副本作為leader負責協調所有的副本。通常在leader選舉中，一組有機會成為leader的候選者都是可以確認的。這些候選者都競相宣布自己是leader，其中會有一個候選者脫穎而出成為leader。一旦贏了選舉之后，leader將會繼續以leader身份發送“心跳”來更新他們的位置。而其它的候選者將會周期性地作出嘗試來成為leader，這套機制確保了如果當前的leader由于某些原因失效了，可以快速指定新的leader。
leader選舉的實現通常需要任一一套分布式協調系統比如ZooKeeper、etcd或者Consul，使用它們來取得共識，或者交替實現自己的共識算法。接下來我們將會看到Kubernetes如何使得在應用中進行leader選舉明顯更容易。
Kubernetes中leader選舉的實現
leader選舉的第一個要求是對于有意成為leader的一組候選者的規范，Kubernetes已經使用了Endpoints來表示一組包含服務的Pods副本，所以我們將重用這個相同的對象（旁白：你可能會認為我們將使用ReplicationControllers，但它們被綁定到一個特定的二進制軟件包，即使在執行滾動更新的過程中也通常需要一個leader）。執行leader選舉將使用Kubernetes API中的兩個屬性：
- ResourceVersions——每個API都有一個唯一的ResourceVersions，用戶可以使用這些版本在Kubernetes對象上執行Compare-and-Swap操作。
- Annotations——每個API都可以被用于客戶端的任意鍵/值對注解。
鑒于這些原語，使用選主的代碼相對簡單，可以在這兒找到相關代碼，運行如下：
$ kubectl run leader-elector --image=gcr.io/google_containers/leader-elector:0.4 --replicas=3 -- --election=example
這將會創建一個有三個副本的leader選舉組：
$ kubectl get pods NAME READY STATUS RESTARTS AGE leader-elector-inmr1 1/1 Running 0 13s leader-elector-qkq00 1/1 Running 0 13s leader-elector-sgwcq 1/1 Running 0 13s
為了查看哪一個Pod被選為了leader，用戶可以訪問Pods的日志，在下面的位置替換為你自己的Pod的名字：
${pod_name}, (e.g. leader-elector-inmr1 from the above)
$ kubectl logs -f ${name}
leader is (leader-pod-name)</pre>
或者，用戶可以直接檢查Endpoints對象：
# ‘example’ is the name of the candidate set from the above kubectl run … command
$ kubectl get endpoints example -o yams
現在需要驗證leader選舉是否生效，在另外一個終端中執行：
$ kubectl delete pods (leader-pod-name)
這個命令將會刪除已有的leader，因為Replication Controller管理Pods組，一個新的Pod將會替換掉已經刪除的，從而確保副本數目仍然為3。通過leader選舉，這三個Pod中將會有一個被選為leader，并且leader角色還會失效轉移到不同的Pod上。因為Kubernetes框架中Pod在終止前會有一個寬限期，通常是持續30~40秒。
leader選舉容器提供了一個簡單的Web服務器，可以運行在任何地址上（比如http://localhost:4040），我們可以通過刪除一個已有的leader選舉組并創建一個新的來測試這個容器，此處可以另外傳入一個形如-http=(host):(port) 規格的配置到鏡像中，這樣就會導致每一個組成員通過Webhook來獲得有關leader的服務信息。
# delete the old leader elector group
$ kubectl delete rc leader-elector
create the new group, note the --http=localhost:4040 flag
$ kubectl run leader-elector --image=gcr.io/google_containers/leader-elector:0.4 --replicas=3 -- --election=example --http=0.0.0.0:4040
create a proxy to your Kubernetes api server
$ kubectl proxy</pre>
接著可以訪問：
http://localhost:8001/api/v1/proxy/namespaces/default/pods/(leader-pod-name):4040/
然后就會看到：
{"name":"(name-of-leader-here)"}
leader選舉與sidecars
太好了，現在可以通過HTTP來進行leader選舉和找出leader，但怎么能在您自己的應用程序中使用它們呢？這就需要引入Sidecars的概念。在Kubernetes中，Pods由一個或者多個容器組成，通常，這意味著添加sidecars容器到主應用程序中組成一個Pod（對于這個主題的更詳細的處理，請看我以前的博客文章）。
leader選舉容器可以作為一個Sidecars來從自己的應用中使用，Pod中的任何容器對誰是當前的選主感興趣的都可以簡單地通過http://localhost:4040 來訪問，然后返回一個簡單的JSON對象，其中包含了當前選主的名字。既然Pod中的所有容器共享了相同的網絡命名空間，就不再需要服務發現了！
舉個例子，有一個簡單的Node.js應用程序連接到leader選舉Sidecar，然后打印出這個是否是當前的選主，領導人選舉Sidecar將其標識符設置為默認的主機名。
var http = require('http');
// This will hold info about the current master
var master = {};
// The web handler for our nodejs application
var handleRequest = function(request, response) {
response.writeHead(200);
response.end("Master is " + master.name);
};
// A callback that is used for our outgoing client requests to the sidecar
var cb = function(response) {
var data = '';
response.on('data', function(piece) { data = data + piece; });
response.on('end', function() { master = JSON.parse(data); });
};
// Make an async request to the sidecar at http://localhost:4040
var updateMaster = function() {
var req = http.get({host: 'localhost', path: '/', port: 4040}, cb);
req.on('error', function(e) { console.log('problem with request: ' + e.message); });
req.end();
};
// Set up regular updates
updateMaster();
setInterval(updateMaster, 5000);
// set up the web server
var www = http.createServer(handleRequest);
www.listen(8080); </pre>
當然，可以使用任何語言，選擇支持HTTP和JSON來使用這個Sidecar。
總結
希望我已經向你展示了是多么容易為分布式應用程序使用Kubernetes來構建leader選舉。在以后的部分我們將向您展示Kubernetes是如何使得構建分布式系統更容易。與此同時，還前往Google容器引擎或kubernetes.io來開始使用Kubernetes。
原文鏈接：Simple leader election with Kubernetes and Docker（翻譯：胡震）