docker swarm服務發現和負載均衡原理
docker使用的是linux核心iptables和ipvs的功能來實現服務發現和負載均衡。iptables是linux核心中可用的包過濾技術，可根據資料報的內容進行分類、修改和**決策。ipvs是linux核心中可用的傳輸級負載均衡。
本地建立乙個集群環境，我本地有三節點集群環境：
客戶端映象：registry.cn-hangzhou.aliyuncs.com/anoy/ubuntu
服務端映象：registry.cn-hangzhou.aliyuncs.com/anoy/vote
基於dns的負載均衡：
dns server內嵌於docker引擎。在建立集群的時候可以直接指定
--endpoint-mode dnsrr 來指明，這個服務裡面的task或者是所有啟動的容器訪問都通過dns的方式來進行負載均衡，這個是啥意思。操作下就清楚了：
建立乙個網路
docker network create --driver overlay overlay1
建立client節點（啟動乙個），和vote節點（啟動多個），實現client節點訪問vote的時候，是給均衡到不同的vote上了。
然後進行如下操作
docker service ls 檢視服務
docker service ps ***xclient的id 檢視client的資訊，找到他在哪個節點上，然後登陸到那個節點節點的機器上
docker ps 檢視容器，找到client對應的容器
docker exec -it ***xclientid bash 登陸到這個容器
上面操作如下圖
此時在client容器上，可以直接dig vote 看下對vote的dns解析
如上，有兩條。可以測試下是不是會被隨機解析到上面，這裡用ping
是可以看到均衡效果的，這個就是基本的dns解析來實現負載均衡。但是這樣會產生問題，某些應用程式將dns主機名快取到ip位址對映，這回導致應用程式在訪問更改時超時，具有非零dns ttl 值會導致dns條目反應最新的詳細資訊時發生延遲。
基於vip的負載均衡。
基於vip的負載均衡可以解決1中dns總是隨便挑給客戶端帶來的不方便的影響。每個服務都有乙個ip位址，並且該ip位址對映到與該服務關聯的多個容器的ip位址。在這種情況下，與服務關聯的服務ip不會改變，即使與該服務關聯的容器死亡並重新啟動。
執行過程中，dns service會將服務名」vote」解析到vip，使用iptables和ipvs,vip實現2個服務端」vote」容器的負載均衡。
把上面建立的兩個服務刪除，然後重新部署。
並沒有指定--endpoint-mode，也就是說docker swarm預設就是用的vip
檢視這兩個服務的vip
然後跟上面姿勢一樣，找下client在哪個節點上，登上去，看下他是怎麼dns vote的。
這次dns就只有乙個解析了，解析到的位址是vote服務的vip，ping的話也不會存在跳轉別的ip的情況。
現在別動，繼續在client裡面執行
curl vote | grep -i "container id"
通過返回來的容器id來區分到底是誰在為我們幹活
路由網格（routing mesh）
使用路由網格，服務暴露的埠會暴露在swarm集群中的所有工作節點。docker是通過建立 ingress overlay網路來實現這一點的。所有節點預設使用內在的sandbox網路命名空間成為ingress overlay網路的一部分：
直接在上面的實操例子上更新乙個埠對映
sandbox和vote容器是ingress網路的一部分，它有助於路由網格。client容器和vote容器是overlay1網路的一部分，有助於內部負載均衡。所有容器都是預設docker_gwbridge網路的一部分。遵循iptables中的nat規則顯示，埠80上的主機流量傳送到node1裡的sandbox.
這樣，然後瀏覽器訪問（不同重新整理）：
跟預期的一樣，每個節點上不停的重新整理都會看到下面的容器id會交替變化，說明負載均衡是好使的。
docker swarm 管理服務
docker swarm中服務的概念是 乙個服務包含swarm集群中多個節點，每個節點都可以部署服務，每個服務也包含多個相關的容器。docker service help commands create create a new service inspect display detailed in...
Docker Swarm （服務構建，水平擴充套件）
使用服務仍能夠配置大多數熟悉的容器屬性，比如容器名 埠對映 接入網路和映象。此外還增加了額外的特性，比如可以宣告應用服務的期望狀態，將其告知 docker 後，docker 會負責進行服務的部署和管理。舉例說明，假如某應用有乙個 web 前端服務，該服務有相應的映象。測試表明對於正常的流量來說 5 ...
用Docker Swarm實現容器服務高可用
如何用容器快速部署這三個應用？如何提高效能？如何保障後端可用性？在我以往的實踐中，容器的編排使用了docker compose實現，問題一就已經解決。但docker compose也只是用於編排，可以各啟動三個服務的乙個容器，效能與高可用性就可能不能滿足要求。對於效能與高可用，如果是大型專案，目前不...