1、內(nèi)容概要容器網(wǎng)絡(luò)容器存儲服務(wù)治理Docker提供的網(wǎng)絡(luò)模式網(wǎng)橋模式默認(rèn)模式建立虛擬網(wǎng)卡Docker0增加路由規(guī)則配置iptables在宿主機上有何容器的端口映射也叫做NAT模式，使用最多Docker提供的網(wǎng)絡(luò)模式None模式容器啟動時不創(chuàng)建任何網(wǎng)絡(luò)，即此時在容器內(nèi)部沒有配置任何地址此模式可以在容器啟動后再配置容器網(wǎng)絡(luò)nova-docker使用此種方式網(wǎng)絡(luò)創(chuàng)建的責(zé)任完全交給用戶Docker提供的網(wǎng)絡(luò)模式Host模式容器啟動時和宿主機共用網(wǎng)絡(luò)配置使用宿主機的地址作為容器地址端口也為宿主機端口，但不能使用低配置端口，需要管理好端口分配網(wǎng)絡(luò)沒有進行隔離，存在安全隱患Docker提供的網(wǎng)絡(luò)模式容器模式容

2、器啟動時和另外一個容器共用網(wǎng)絡(luò)配置使用另外一個容器的地址作為容器地址端口也為另外一個容器端口，需要管理好端口分配網(wǎng)絡(luò)和另外一個容器沒有進行隔離網(wǎng)絡(luò)存在問題在同一臺宿主機器內(nèi)，容器間可以相互訪問，跨主機訪問成為問題雖然使用網(wǎng)橋模式可以跨主機，但性能較差使用Host模式也可以實現(xiàn)跨主機，但存在安全問題為解決這個問題，先后出現(xiàn)了多種方案：Docker 1.9 新的網(wǎng)絡(luò)模式WeaveFlannelPipworkCalico二層VLAN或者Overlay上面提到的網(wǎng)絡(luò)項目在實現(xiàn)細節(jié)上存在很多差異，但其思路無非分為兩種：二層VLAN網(wǎng)絡(luò)和Overlay網(wǎng)絡(luò)二層VLAN網(wǎng)絡(luò)的解決跨主機通信的思路是把原先的網(wǎng)

3、絡(luò)架構(gòu)改造為互通的大二層網(wǎng)絡(luò)，通過特定網(wǎng)絡(luò)設(shè)備直接路由，實現(xiàn)容器點到點的之間通信。特點是傳輸效率高，但需要二層網(wǎng)絡(luò)設(shè)備支持，通用性和靈活性不如，可能帶來廣播泛濫Overlay網(wǎng)絡(luò)是指在不改變現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)設(shè)施的前提下，通過某種約定通信協(xié)議，把二層報文封裝在IP報文之上的新的數(shù)據(jù)格式， Overlay網(wǎng)絡(luò)實際上是目前最主流的容器跨節(jié)點數(shù)據(jù)傳輸和路由方案Docker 1.9 跨主機網(wǎng)絡(luò)Sandbox：對應(yīng)一個容器中的網(wǎng)絡(luò)環(huán)境，包括相應(yīng)的網(wǎng)卡配置、路由表、DNS配置Endpoint：實際上就是一個容器中的虛擬網(wǎng)卡，在容器中會顯示為eth0、eth1依次類推Network：指的是一個能夠相互通信的容器網(wǎng)

4、絡(luò)，加入了同一個網(wǎng)絡(luò)的容器直接可以直接通過對方的名字相互連接需要SwarmWeavepcap overlayfast datapath來提供高性能FlannelUDP vxlanetcd存儲配置數(shù)據(jù)和子網(wǎng)分配Calico純?nèi)龑拥?SDN 實現(xiàn)，它基于 BPG 協(xié)議和 Linux 自己的路由轉(zhuǎn)發(fā)機制，不依賴特殊硬件，沒有使用 NAT 或 Tunnel 等技性能接近于物理機問題容器網(wǎng)絡(luò)一般采用哪兩種方式實現(xiàn)？內(nèi)容概要容器網(wǎng)絡(luò)容器存儲服務(wù)治理存儲問題容器的兩個事實：1. 容器內(nèi)數(shù)據(jù)隨容器銷毀而銷毀2. 容器集群后會進行漂移帶來的問題：日志如何收集和查看？文件存儲在哪里？容器漂移后，狀態(tài)數(shù)據(jù)如何處理？

5、Docker 存儲掛載不同存儲需求的進行不同處理：日志掛載宿主本地文件系統(tǒng)數(shù)據(jù)庫掛載SSD磁盤普通文件掛載SAS持久的用分布式存儲容器漂移FlockerDocker的plugin機制可以隨容器的遷移而遷移支持多種存儲后端問題Docker是否支持以插件模式管理存儲？內(nèi)容概要容器網(wǎng)絡(luò)容器存儲服務(wù)治理容器化后服務(wù)使用問題容器啟動前地址一般不是事先確定的，這就造成基于地址的服務(wù)發(fā)現(xiàn)和使用成為問題兩種思路：一種是將服務(wù)的地址在服務(wù)使用方容器啟動時以環(huán)境變量注入進去一種是通過DNS域名解析方式使用服務(wù)Kubernetes服務(wù)支持兩種方式 變量注入（自動） DNSConsul分布式服務(wù)注冊和發(fā)現(xiàn)Consul 的優(yōu)勢使用 Raft 算法來保證一致性, 比復(fù)雜的 Paxos 算法更直接. 相比較而言, zookeeper 采用的是 Paxos, 而 etcd 使用的則是 Raft.支持多數(shù)據(jù)中心，內(nèi)外網(wǎng)的服務(wù)采用不同的端口進行監(jiān)聽。 多數(shù)據(jù)中心集群可以避免單數(shù)據(jù)中心的單點故障,而其部署則需要考慮網(wǎng)絡(luò)延遲, 分片等情況等. zookeeper 和 etcd 均不提供多數(shù)據(jù)中心功能的支持.支持健康檢查. etcd 不提供此功能.支持 http 和 dns 協(xié)議