一直沒有寫過，通過自己學(xué)習(xí)的一些感悟，記錄下來，期望一起學(xué)習(xí)的小伙伴共同維護(hù)成長

目前創(chuàng)新互聯(lián)建站已為1000+的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)頁空間、網(wǎng)站托管、服務(wù)器租用、企業(yè)網(wǎng)站設(shè)計(jì)、綠春網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

直戳主題 

kubernetes   在網(wǎng)絡(luò)方面提出 service 概念 ，實(shí)現(xiàn)原理通過  node節(jié)點(diǎn)上的proxy  進(jìn)程調(diào)用 iptables進(jìn)行網(wǎng)絡(luò)均衡    簡單說 就是 每個(gè)node 上面都有同樣的iptables 規(guī)則 幫你輪轉(zhuǎn)  到后端的pod上   這點(diǎn) 有點(diǎn)像 lvs 的 nat模式 

再說 kubernetes   從pod 訪問 service   同樣的使用iptables  做了如上同樣規(guī)則 ，node訪問也一樣

重點(diǎn)， 從外部訪問     官方提供 2種辦法  

    a，使用  給本機(jī)通過iptalbes 映射一個(gè)端口 訪問到 service （每個(gè)機(jī)器都映射）nodeport 方式 

    b，通過 官方提供lb  但是 目前這種lb  只支持  google 的  與aws的 （普通用戶無法訪問）

那問題來了 

   我們?nèi)绾螐耐饷?訪問     到里面service 或者pod

方法 1，直接從etcd 里面調(diào)用后端pod地址實(shí)現(xiàn)       目前大部分同學(xué)都是這種辦法

方法2， 直接從外面訪問  service   （我這里做的是直連路由模式）

5  臺(tái)機(jī)器

   master  10.1.11.250 網(wǎng)關(guān)10.1.11.254

        添加2條路由   10.1.51.0/24   gw 10.1.11.1  (通過  ospf  軟件直接學(xué)習(xí)   quagga)

                               10.1.52.0/24  gw 10.1.11.2

   node1   10.1.11.1   網(wǎng)關(guān)10.1.11.254  docker 網(wǎng)絡(luò)  10.1.51.1   在額外起一片虛擬網(wǎng)卡 10.1.200.253

                                10.1.52.0/24  10.1.11.2 (quagga)

   node2   10.1.11.2     網(wǎng)關(guān)10.1.11.254  docker 網(wǎng)絡(luò) 10.1.52.1   在額外起一片虛擬網(wǎng)卡 10.1.200.253

                                 10.1.51.0/24  10.1.11.1 (quagga)

   網(wǎng)關(guān)路由器  10.1.11.254  外網(wǎng)10.1.10.1  （quagga）

                               10.1.51.0/24   gw 10.1.11.1  

                               10.1.52.0/24  gw 10.1.11.2

   客戶端地址   10.1.10.200

   加靜態(tài) route 10.1.200.0   gw 10.1.10.1

               route  10.1.11.0   gw  10.1.10.1

   kubernetes  虛擬網(wǎng)絡(luò)  10.1.200.0/24

通過上面的設(shè)置    路由器 上面  到達(dá)  10.1.200.0/24  nexttop  10.1.11.1

                                                                                   nexttop   10.1.12.1

通過session   cache 可以 完成簡單的輪訓(xùn)分發(fā) 并保證session一致性

這樣我用session  放出的服務(wù)  10.1.200.200  5000端口  當(dāng)路由轉(zhuǎn)到  10.1.11.1 或者 11.2  由于proxy 預(yù)先有5000端口的 dnat      那么訪問就直接被調(diào)度到后端 pod上面 （service  谷歌本身就做了 負(fù)載均衡 ）

通過上面放置路由器 實(shí)現(xiàn)等價(jià)路由  來訪問不同的 node1 實(shí)現(xiàn)負(fù)載。

文字功底不行，簡單說到這里 ，谷歌service  感覺其實(shí)現(xiàn)與  lvs  fullnat 差不多    顧采用 相同   直連路由方案。