參考老師的文檔寫的學習筆記：專題三-Kubernetes_學習文檔-N.docx

3.2.3.1 搭建K8S高可用集羣及K8S網絡方案詳解

1、docker網絡的4種模式

主機(host)：與宿主機共享網絡(與宿主機ip地址一樣)
   橋接(bridge)：與宿主機是一臺機器
   空(none)：有網卡，但沒連網(eg：有線網卡沒插網線、無線網卡沒連WIFI)，只能ping自己(localhost、127.0.0.1)
   容器(container)：與其他容器共享命名空間(namespace)，共享網絡【根容器會創建一個網絡，其他容器就共享這一個網絡】

2、docker的網絡基礎

2.1、linux網絡名詞解釋

1、Network Namespace
           不同的網絡命名空間中，協議棧是獨立的，完全隔離，彼此之間無法通信。
           同一個網絡命名空間有獨立的路由表、獨立的Iptables/Netfilter，
                   來提供包的轉發、NAT、IP包過濾等功能。
       2、網絡命名空間的實現
           將與網絡協議棧相關的全局變量變成一個Net Namespace變量的成員，然後在調用協議棧函數，加入一個Namespace參數。
       3、常用用的操作
           1、創建網絡命名空間：ip netns add
           2、在命名空間內執行命令：ip netns exec
           3、進入命名空間：ip netns exec bash
       4、veth設備對
           是爲了實現在不同網絡命名空間的通信
       5、Iptable/Netfilter
           Netfilter：負責在內核中執行各種掛接的規則(過濾、修改、丟棄)，運行在內核模式中
           Iptables：負責協助維護內核中Netfilter的各種規則表，是在用戶模式下運行的進程
           通過二者的配合來實現整個linux網絡協議棧中靈活的數據包處理機制
       6、網橋
           是一個二層網絡設備，通過網橋可以將linux支持的不同端口連接起來，並實現類似交換機那樣的多對的的通信。
       7、路由
           linux系統包含一個完整的路由功能，當IP層在處理數據發送或轉發的時候，會使用路由表來決定發往哪裏。

2.2、Docker網絡在整個Docker生態技術棧中的位置

3、docker的網絡實現

3.1、單機網絡模式

birdge、host、container、none

3.2、多機網絡模式

1、docker在1.9版本中引入libnetwork項目，對跨節點網絡的原生支持
2、通過插件plugin方式引入的第三方實現方案，eg：flannel、calico

容器網絡

3.3、4種網絡模式

Docker網絡模式	配置	說明
host模式	–net=host	容器和宿主機共享Network namespace。
container模式	–net=container: NAME_or_ID	容器和另外一個容器共享Network namespace。 kubernetes中的pod就是多個容器共享一個Network namespace。
none模式	–net=none	容器有獨立的Network namespace，但並沒有對其進行任何網絡設置，如分配veth pair 和網橋連接，配置IP等。
bridge模式	–net=bridge （默認）

4、k8s網絡要解決的問題

1、保證每個Pod擁有一個集羣內唯一的IP地址
   2、保證不同節點的IP地址劃分不會重複
   3、保證跨節點的Pod可以互相通信
   4、保證不同節點的Pod可以與跨節點的主機互相通信
   爲解決這些問題，出現的網絡插件有：flannel、calico、contiv、weave net、cilium、canal

4.1、網絡架構圖

圖中的flannel的作用：保證當前節點所有容器的IP地址唯一，與其他節點的IP地址不會出現重複
node之間的Pod通信時，工作流程：pod的eth0找docker0，docker0找flannel，flannel向api server發請求，api server從etcd中查找目標pod的IP地址、及pod所在的node的物理地址；找到後，flannel將信息給當前node1的物理網卡eth0，node1的物理網卡eth0根據信息向目標網卡(node2的eth0)發請求：在它上面對應的pod地址

3.2.3.2 內置的負載均衡機制及自定義拓展

1、Flannel容器網絡

2、k8s的4種負載均衡機制

2.1、service

直接用service提供cluster內部的負載均衡，並藉助cloud provider提供的LB，來提供外部訪問。
           Service是對一組提供相同功能的Pods的抽象，併爲它們提供一個統一的入口。藉助Service，應用可以方便的實現服務發現與負載均衡，並實現應用的零宕機升級。Service通過標籤來選取服務後端，一般配合Replication Controller或者Deployment來保證後端容器的正常運行
       1、Service目前有三種類型：
           ClusterIP：默認類型，自動分配一個僅cluster內部可以訪問的虛擬IP
           NodePort：在ClusterIP基礎上爲Service在每臺機器上綁定一個端口，這樣就可以通過<NodeIP>:NodePort來訪問該服務
           LoadBalancer：在NodePort的基礎上，藉助cloud provider創建一個外部的負載均衡器，並將請求轉發到<NodeIP>:NodePort

        2、Service中常見的三種端口的含義：
           port：Service暴露在Cluster IP上的端口，也就是虛擬IP要綁定的端口。port是提供給集羣內部客戶訪問Service的入口。
           nodePort：是Kubernetes提供給集羣外部客戶訪問Service的入口。
           targetPort：是Pod裏容器的端口，從port和nodePort上進入的數據最終會經過Kube-Proxy流入到後端Pod裏容器的端口。如果targetPort沒有被顯式聲明，那麼會默認轉發到Service接受請求的端口（和port端口的值一樣）。
總的來說，port和nodePort都是Service的端口，前者暴露給集羣內客戶訪問服務，後者暴露給集羣外客戶訪問服務。從這兩個端口到來的數據都需要經過反向代理Kube-Proxy流入後端Pod裏容器的端口，從而到達Pod上的容器內。
另外，也可以將已有的服務以Service的形式加入到Kubernetes集羣中來，只需要在創建Service的時候不指定Label selector，而是在Service創建好後手動爲其添加endpoint。
service的限制：對外訪問的時候，NodePort類型需要在外部搭建額外的負載均衡，而LoadBalancer要求kubernetes必須跑在支持的cloud provider上面。

2.2、service load balancer

把load balancer直接跑在容器中，實現bare metal的service load balancer。
Service Load Balancer是解決Service侷限性的方式。Service Load Balancer將haproxy跑在容器中，並監控service和endpoint的變化，通過容器IP對外提供4層和7層負載均衡服務。
社區提供的Service Load Balancer支持四種負載均衡協議：TCP、HTTP、HTTPS、SSL TERMINATION，並支持ACL訪問控制。
像阿里雲、aws、azure、openstack、gce都提供了loadbalance服務。

2.3、custom load balancer

自定義負載均衡，並替代kube-proxy,一般在物理部署k8s時使用，方便接入公司已有的外部服務。
雖然Kubernetes提供了豐富的負載均衡機制，但在實際使用的時候，還是會碰到一些複雜的場景是它不能支持的，eg：
1、接入已有的負載均衡設備
2、多租戶網絡情況下，容器網絡和主機網絡是隔離的，這樣kube-proxy就不能正常工作
這個時候就可以自定義組件，並代替kube-proxy來做負載均衡。基本的思路是監控kubernetes中service和endpoints的變化，並根據這些變化來配置負載均衡器。eg：weave flux、nginx plus、kube2haproxy等

2.4、ingress

用service提供cluster內部的負載均衡，通過自定義的LB，來提供外部訪問。
ingress是一套接口，nginx是ingress的一種實現。
官方文檔：https://kubernetes.github.io/ingress-nginx/
ingress解決了service的限制，用來將服務暴露到cluster外面，可以自定義服務的訪問策略。
ingress規則是很靈活的，可以根據不同域名、不同path轉發請求到不同的service，並且支持https/http。

1、Ingress組成
   1、將nginx的配置抽象成一個ingress對象，沒添加一個服務只需寫一個新的ingress的yaml文件即可
   2、將新加入的ingress轉換成nginx的配置文件並使之生效
   3、ingress controller
   4、ingress服務
2、Ingress工作原理
   1、ingress controller通過與kubernetes api交互，動態的去感知集羣中ingress規則變化
   2、然後讀取它，按照自定義的規則，規則就是寫明哪個域名對應哪個service,生成一段nginx配置
   3、再寫到nginx-ingress-controller的pod裏，這個ingress controller的pod裏運行着一個nginx服務，控制器會把生成的nginx配置寫入/etc/nginx.conf文件中
   4、然後reload一下，使配置生效。以此達到域名分配置和動態更新的問題
3、ingress可以解決的2個問題
   1、動態配置服務
   2、減少不必要的端口暴露
4、區分ingress與ingress-controller
   1、ingress
       ingress對象：指的是k8s中的一個api對象，一般用yaml配置。作用是定義請求如何轉發到service的規則，可以理解爲配置模板。
       eg：nginx-ingress就是動態生成nginx配置，動態更新upstream
   2、ingress-controller
       具體實現反向代理及負載均衡的程序，對ingress定義的規則進行解析，根據配置的規則來實現請求轉發。
   ingress-controller是負責具體轉發的組件，ingress是用來告訴ingress-controller該如何轉發請求

3.2.3 K8S進階