網(wǎng)絡(luò)基礎(chǔ)知識

交換技術(shù)

廣播域

01 交換機在轉(zhuǎn)發(fā)數(shù)據(jù)時會先進行廣播，這個廣播可以發(fā)送的區(qū)域就是一個廣播域
02 交換機之間對廣播幀是透明的，所以交換機之間組成的網(wǎng)絡(luò)是一個廣播域
03 路由器的一個接口下的網(wǎng)絡(luò)是一個廣播域被去，所以路由器可以隔離廣播域

ARP（地址解析協(xié)議）

01 發(fā)送這個廣播幀是由ARP協(xié)議實現(xiàn)
02 ARP是通過IP地址獲取物理地址的一個TCP/IP協(xié)議

三層交換機

01 二層交換機只工作在數(shù)據(jù)鏈路層
02 路由器則工作在網(wǎng)絡(luò)層
03 三層交換機可同時工作在數(shù)據(jù)鏈路層和網(wǎng)絡(luò)層，并根據(jù) MAC地址或IP地址轉(zhuǎn)發(fā)數(shù)據(jù)包

VLAN（Virtual Local Area Network）：虛擬局域網(wǎng)

01 VLAN是一種將局域網(wǎng)設(shè)備從邏輯上劃分成一個個網(wǎng)段
02 一個VLAN就是一個廣播域暑诸，VLAN之間的通信是通過第3層的路由器來完成的
03 VLAN應(yīng)用非常廣泛，基本上大部分網(wǎng)絡(luò)項目都會劃分vlan

VLAN的主要好處

01 分割廣播域辟灰，減少廣播風(fēng)暴影響范圍个榕。
02 提高網(wǎng)絡(luò)安全性，根據(jù)不同的部門芥喇、用途西采、應(yīng)用劃分不同網(wǎng)段

路由技術(shù)

路由器主要分為兩個端口類型

路由器主要分為兩個端口類型：LAN口和WAN口
01 WAN口：配置公網(wǎng)IP，接入到互聯(lián)網(wǎng)继控，轉(zhuǎn)發(fā)來自LAN口的IP數(shù)據(jù)包械馆。
02 LAN口：配置內(nèi)網(wǎng)IP（網(wǎng)關(guān)），連接內(nèi)部交換機

功能

01 路由器是連接兩個或多個網(wǎng)絡(luò)的硬件設(shè)備
02 將從端口上接收的數(shù)據(jù)包武通，根據(jù)數(shù)據(jù)包的目的地址智能轉(zhuǎn)發(fā)出去

路由器的功能

? 路由
? 轉(zhuǎn)發(fā)
? 隔離子網(wǎng)
? 隔離廣播域

路由

01 靜態(tài)路由：指人工手動指定到目標(biāo)主機的地址然后記錄在路由表中霹崎，如果其中某個節(jié)點不可用則需要重新指定。
02 動態(tài)路由：則是路由器根據(jù)動態(tài)路由協(xié)議自動計算出路徑永久可用冶忱，能實時地適應(yīng)網(wǎng)絡(luò)結(jié)構(gòu)的變化尾菇。
03 常用的動態(tài)路由協(xié)議：
   ? RIP（ Routing Information Protocol ，路由信息協(xié)議）
   ? OSPF（Open Shortest Path First囚枪，開放式最短路徑優(yōu)先）
   ? BGP（Border Gateway Protocol派诬，邊界網(wǎng)關(guān)協(xié)議）

K8s網(wǎng)絡(luò)模型

回看Docker容器網(wǎng)絡(luò)模型

1641625262454.png

相關(guān)概念

01 Linux在網(wǎng)絡(luò)棧中引入網(wǎng)絡(luò)命名空間，將獨立的網(wǎng)絡(luò)協(xié)議棧隔離到不同的命令空間中链沼，彼此間無法通信默赂；
02 Docker利用這一特性，實現(xiàn)不同容器間的網(wǎng)絡(luò)隔離忆植。
? Veth設(shè)備對：Veth設(shè)備對的引入是為了實現(xiàn)在不同網(wǎng)絡(luò)命名空間的通信放可。
? Iptables/Netfilter：Docker使用Netfilter實現(xiàn)容器網(wǎng)絡(luò)轉(zhuǎn)發(fā)。
? 網(wǎng)橋（docker0）：網(wǎng)橋是一個二層網(wǎng)絡(luò)設(shè)備朝刊，通過網(wǎng)橋可以將Linux支持的不同的端口連接起來，并實現(xiàn)類似交換機那樣的多對多的通信蜈缤，在宿主機的網(wǎng)絡(luò)命名空間中
? 路由：Linux系統(tǒng)包含一個完整的路由功能拾氓，當(dāng)IP層在處理數(shù)據(jù)發(fā)送或轉(zhuǎn)發(fā)的時候，會使用路由表來決定發(fā)往哪里底哥。

容器之間通信

二層網(wǎng)絡(luò)之間的通信

容器訪問外網(wǎng)

通過docker0咙鞍，NAT轉(zhuǎn)發(fā)到外網(wǎng)
ip route

Pod網(wǎng)絡(luò)

1641627288967.png

infra container

Pod是K8s最小調(diào)度單元房官，一個Pod由一個容器或多個容器組成，當(dāng)多個容器時续滋，怎么都用這一個Pod IP翰守？

01 k8s會在每個Pod里先啟動一個infra container小容器，然后讓其他的容器連接進來這個網(wǎng)絡(luò)命名空間
02 其他容器看到的網(wǎng)絡(luò)就完全一樣了疲酌。即網(wǎng)絡(luò)設(shè)備蜡峰、IP地址、Mac地址等朗恳。
03 在Pod的IP地址就是infra container的IP地址

pod通信

在 Kubernetes 中湿颅，每一個 Pod 都有一個真實的 IP 地址，并且每一個 Pod 都可以使用此 IP 地址與 其他 Pod 通信粥诫。Pod之間通信會有兩種情況：
? 兩個Pod在同一個Node上
? 兩個Pod在不同Node上

兩個Pod在同一個Node上

1641627398255.png

01 對 Pod1 來說油航，eth0 通過虛擬以太網(wǎng)設(shè)備（veth0）連接到 root namespace；
02 網(wǎng)橋cbr0中為veth0配置了一個網(wǎng)段怀浆。一旦數(shù)據(jù)包到達(dá)網(wǎng)橋谊囚，網(wǎng)橋使用ARP協(xié)議解析出其正確的目標(biāo)網(wǎng)段veth1；
03 網(wǎng)橋 cbr0 將數(shù)據(jù)包發(fā)送到 veth1执赡；
04 數(shù)據(jù)包到達(dá) veth1 時镰踏，被直接轉(zhuǎn)發(fā)到Pod2的network namespace中的eth0 網(wǎng)絡(luò)設(shè)備。

兩個Pod在不同Node上

1641627451494.png

相比同節(jié)點Pod通信搀玖，這里源Pod發(fā)出的數(shù)據(jù)包需要傳遞到目標(biāo)節(jié)點余境，但是源Pod并不知道目標(biāo)Pod在哪個節(jié)點上？
因此灌诅，為了實現(xiàn)容器跨主機通信需求芳来，就需要部署網(wǎng)絡(luò)組件，這些網(wǎng)絡(luò)組件都必須滿足如下要求：
? 一個Pod一個IP
? 所有的 Pod 可以與任何其他 Pod 直接通信
? 所有節(jié)點可以與所有 Pod 直接通信
? Pod 內(nèi)部獲取到的 IP 地址與其他 Pod 或節(jié)點與其通信時的 IP 地址是同一個（pod綁定IP生命周期）

CNI（容器網(wǎng)絡(luò)接口）

CNI（Container Network Interface猜拾，容器網(wǎng)絡(luò)接口)：是一個容器網(wǎng)絡(luò)規(guī)范即舌，Kubernetes網(wǎng)絡(luò)采用的就是這個CNI規(guī)范，負(fù)責(zé)初始化infra容器的網(wǎng)絡(luò)設(shè)備挎袜。

CNI二進制程序默認(rèn)路徑：/opt/cni/bin/
項目地址：https://github.com/containernetworking/cni

以Flannel網(wǎng)絡(luò)組件為例顽聂，當(dāng)部署Flanneld后，會在每臺宿主機上生成它對應(yīng)的CNI配置文件（它其實是一個
ConfigMap）盯仪，從而告訴Kubernetes要使用 Flannel 作為容器網(wǎng)絡(luò)方案紊搪。

CNI配置文件默認(rèn)路徑：/etc/cni/net.d
當(dāng) kubelet 組件需要創(chuàng)建 Pod 的時候，先調(diào)用dockershim它先創(chuàng)建一個 Infra 容器全景。然后調(diào)用 CNI 插件為 Infra 容器配置網(wǎng)絡(luò)

這兩個路徑可在kubelet啟動參數(shù)中定義：
--network-plugin=cni
--cni-conf-dir=/etc/cni/net.d
--cni-bin-dir=/opt/cni/bin

K8s網(wǎng)絡(luò)組件之Calico

概述

01 Calico是一個純?nèi)龑拥臄?shù)據(jù)中心網(wǎng)絡(luò)方案耀石，Calico支持廣泛的平臺，包括Kubernetes爸黄、OpenStack等滞伟。

02 Calico 在每一個計算節(jié)點利用 Linux Kernel 實現(xiàn)了一個高效的虛擬路由器（ vRouter） 來負(fù)責(zé)數(shù)據(jù)轉(zhuǎn)發(fā)揭鳞，而每個 vRouter 通過 BGP 協(xié)議負(fù)責(zé)把自己上運行的 workload 的路由信息向整個 Calico 網(wǎng)絡(luò)內(nèi)傳播。

03 Calico 項目還實現(xiàn)了 Kubernetes 網(wǎng)絡(luò)策略梆奈，提供ACL功能野崇。

04 實際上，Calico項目提供的網(wǎng)絡(luò)解決方案亩钟，與Flannel的host-gw模式幾乎一樣乓梨。也就是說，Calico也是基于
路由表實現(xiàn)容器數(shù)據(jù)包轉(zhuǎn)發(fā)

05 但不同于Flannel使用flanneld進程來維護路由信息的做法径荔，而Calico項目使用BGP協(xié)議來自動維護整個集群的路由信息

06 BGP英文全稱是Border Gateway Protocol督禽，即邊界網(wǎng)關(guān)協(xié)議，它是一種自治系統(tǒng)間的動態(tài)路由發(fā)現(xiàn)協(xié)議总处，
與其他 BGP 系統(tǒng)交換網(wǎng)絡(luò)可達(dá)信息

BGP介紹

1641679622038.png

01 在這個圖中狈惫，有兩個自治系統(tǒng)（autonomous system，簡稱為AS）：AS 1 和 AS 2鹦马。

02 在互聯(lián)網(wǎng)中胧谈，一個自治系統(tǒng)(AS)是一個有權(quán)自主地決定在本系統(tǒng)中應(yīng)采用何種路由協(xié)議的小型單位。

03 這個網(wǎng)絡(luò)單位可以是一個簡單的網(wǎng)絡(luò)也可以是一個由一個或多個普通的網(wǎng)絡(luò)管理員來控制的網(wǎng)絡(luò)群體荸频，它是一個單獨的可管理的網(wǎng)絡(luò)單元（例如一所大學(xué)菱肖，一個企業(yè)或者一個公司個體）。

04 一個自治系統(tǒng)有時也被稱為是一個路由選擇域（routing domain）旭从。一個自治系統(tǒng)將會分配一個全局的唯一的16位號碼稳强，有時我們把這個號碼叫做自治系統(tǒng)號（ASN）。

05 在正常情況下和悦，自治系統(tǒng)之間不會有任何來往退疫。如果兩個自治系統(tǒng)里的主機，要通過 IP 地址直接進行通信鸽素，我們就必須使用路由器把這兩個自治系統(tǒng)連接起來褒繁。BGP協(xié)議就是讓他們互聯(lián)的一種方式

1641680464507.png

在了解了 BGP 之后，Calico 項目的架構(gòu)就非常容易理解了馍忽，
Calico主要由三個部分組成：
01 Felix：以DaemonSet方式部署棒坏，運行在每一個Node節(jié)點上，主要負(fù)責(zé)維護宿主機上路由規(guī)則以及ACL規(guī)則
02 BGP Client（BIRD）：主要負(fù)責(zé)把 Felix 寫入 Kernel 的路由信息分發(fā)到集群 Calico 網(wǎng)絡(luò)
03 Etcd：分布式鍵值存儲遭笋，保存Calico的策略和網(wǎng)絡(luò)配置狀態(tài)坝冕。
04 calicoctl：命令行管理Calico。

部署

Calico存儲有兩種方式：
? 數(shù)據(jù)存儲在etcd
https://docs.projectcalico.org/v3.9/manifests/calico-etcd.yaml
? 數(shù)據(jù)存儲在Kubernetes API Datastore服務(wù)中
https://docs.projectcalico.org/manifests/calico.yaml

---------------------------------------------------------------------------------------
數(shù)據(jù)存儲在etcd中還需要修改yaml：
? 配置連接etcd地址瓦呼，如果使用https徽诲，還需要配置證書。（ConfigMap和Secret位置）

---------------------------------------------------------------------------------------

根據(jù)實際網(wǎng)絡(luò)規(guī)劃修改Pod CIDR（CALICOIPV4POOLCIDR）

cat /opt/kubernetes/cfg/kube-controller-manager.conf
--cluster-cidr=10.244.0.0/16 

cat calico.yaml
- name: CALICO_IPV4POOL_CIDR
  value: "10.244.0.0/16"
                          
--------------------------------------------------------------------------------------- 
部署：
# kubectl apply -f calico.yaml
# kubectl get pods -n kube-system

管理工具calicoctl

概述

calicoctl 在使用過程中吵血，需要從配置文件中讀取 Calico 對象存儲地址等信息谎替。
默認(rèn)配置文件路徑 /etc/calico/calicoctl.cfg

[root@k8s-m1 calico]# chmod +x calicoctl 
[root@k8s-m1 calico]# cp calicoctl /usr/bin/

etcd方式

vi /etc/calico/calicoctl.cfg

apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
  datastoreType: "etcdv3"
  etcdEndpoints: "https://192.168.31.61:2379,https://192.168.31.62:2379"
  etcdKeyFile: "/opt/etcd/ssl/server-key.pem"
  etcdCertFile: "/opt/etcd/ssl/server.pem"
  etcdCACertFile: "/opt/etcd/ssl/ca.pem"

api方式-kubeadmin

vi /etc/calico/calicoctl.cfg

apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
  datastoreType: "kubernetes"
  kubeconfig: "/root/.kube/config"

api方式-二進制

vi /etc/calico/calicoctl.cfg

apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
  datastoreType: "kubernetes"
  kubeconfig: "/root/calico/config"

查看Calico狀態(tài)

[root@k8s-m1 ~]# calicoctl node status
Calico process is running.

IPv4 BGP status
+----------------+-------------------+-------+----------+-------------+
|  PEER ADDRESS  |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+----------------+-------------------+-------+----------+-------------+
| 192.168.153.27 | node-to-node mesh | up    | 22:20:26 | Established |
| 192.168.153.28 | node-to-node mesh | up    | 22:21:00 | Established |
+----------------+-------------------+-------+----------+-------------+



[root@k8s-m1 ~]# calicoctl get nodes
NAME        
k8s-m1      
k8s-node1   
k8s-node2   

[root@k8s-m1 ~]# calicoctl get ippool -o wide
NAME                  CIDR            NAT    IPIPMODE   VXLANMODE   DISABLED   SELECTOR   
default-ipv4-ippool   10.244.0.0/16   true   Always     Never       false      all()  

工作模式

Calico工作模式：
? IPIP：Overlay Network方案，源數(shù)據(jù)包封裝在宿主機網(wǎng)絡(luò)包里進行轉(zhuǎn)發(fā)和通信蹋辅。（默認(rèn)）
? BGP：基于路由轉(zhuǎn)發(fā)钱贯，每個節(jié)點通過BGP協(xié)議同步路由表，寫到宿主機侦另。 （值設(shè)置Never）
? CrossSubnet：同時支持BGP和IPIP秩命，即根據(jù)子網(wǎng)選擇轉(zhuǎn)發(fā)方式。

IPIP工作模式

概述

IPIP模式：采用Linux IPIP隧道技術(shù)實現(xiàn)的數(shù)據(jù)包封裝與轉(zhuǎn)發(fā)褒傅。
IP 隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文的技術(shù)弃锐，Linux系統(tǒng)內(nèi)核實現(xiàn)的
IP隧道技術(shù)主要有三種：IPIP、GRE殿托、SIT
默認(rèn)使用IPIP模式

- name: CALICO_IPV4POOL_IPIP
  value: "Always"
  
7: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 10.244.42.128/32 brd 10.244.42.128 scope global tunl0
       valid_lft forever preferred_lft forever  

工作流程

1641694824473.png

Pod 1 訪問 Pod 2 大致流程如下：
01 數(shù)據(jù)包（原始數(shù)據(jù)包）從容器出去到達(dá)宿主機霹菊，宿主機根據(jù)路由表發(fā)送到tunl0設(shè)備（IP隧道設(shè)備）
02 Linux內(nèi)核IPIP驅(qū)動將原始數(shù)據(jù)包封裝在宿主機網(wǎng)絡(luò)的IP包中（新的IP包目的地之是原IP包的下一跳地
址，即192.168.31.63）支竹。
03 數(shù)據(jù)包根據(jù)宿主機網(wǎng)絡(luò)到達(dá)Node2旋廷；
04 Node2收到數(shù)據(jù)包后，使用IPIP驅(qū)動進行解包礼搁，從中拿到原始數(shù)據(jù)包饶碘；
05 然后根據(jù)路由規(guī)則，根據(jù)路由規(guī)則將數(shù)據(jù)包轉(zhuǎn)發(fā)給cali設(shè)備馒吴，從而到達(dá)容器2

BGP工作模式

概述

01 基于路由轉(zhuǎn)發(fā)扎运，每個節(jié)點通過BGP協(xié)議同步路由表
02 將每個宿主機當(dāng)做路由器，實現(xiàn)數(shù)據(jù)包轉(zhuǎn)發(fā)

calicoctl工具修改為BGP模式

# calicoctl get ipPool -o yaml > ippool.yaml

# vi ippool.yaml
  ipipMode: Never

# calicoctl apply -f ippool.yaml
# calicoctl get ippool -o wide

tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0


[root@k8s-m1 ~]# ss -antp|grep ESTAB|grep 179
ESTAB      0      0      192.168.153.25:179                192.168.153.28:42181               users:(("bird",pid=4430,fd=8))
ESTAB      0      0      192.168.153.25:179                192.168.153.27:46032               users:(("bird",pid=4430,fd=9))s

工作流程

1641711189304.png

Pod 1 訪問 Pod 2 大致流程如下：
01 數(shù)據(jù)包從容器出去到達(dá)宿主機饮戳；
02 宿主機根據(jù)路由規(guī)則豪治，將數(shù)據(jù)包轉(zhuǎn)發(fā)給下一跳（網(wǎng)關(guān)）；
03 到達(dá)Node2莹捡，根據(jù)路由規(guī)則將數(shù)據(jù)包轉(zhuǎn)發(fā)給cali設(shè)備鬼吵，從而到達(dá)容器2。

Route Reflector 模式（RR）

背景

1641711433877.png

01 Calico 維護的網(wǎng)絡(luò)在默認(rèn)是（Node-to-Node Mesh）全互聯(lián)模式
02 Calico集群中的節(jié)點之間都會相互建立連接篮赢，用于路由交換
03 但是隨著集群規(guī)模的擴大齿椅，mesh模式將形成一個巨大服務(wù)網(wǎng)格，連接數(shù)成倍增加启泣，就會產(chǎn)生性能問題
04 這時就需要使用 Route Reflector（路由器反射）模式解決這個問題

解決

1641712150416.png

01 確定一個或多個Calico節(jié)點充當(dāng)路由反射器涣脚，集中分發(fā)路由
02 讓其他節(jié)點從這個RR節(jié)點獲取路由信息

具體步驟：

01 關(guān)閉 node-to-node模式

添加 default BGP配置，調(diào)整 nodeToNodeMeshEnabled和asNumber：
vi bgpconfig.yaml

apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: default
spec:
  logSeverityScreen: Info
  nodeToNodeMeshEnabled: false
  asNumber: 64512


ASN號可以通過獲取 # calicoctl get nodes --output=wide

[root@k8s-m1 ~]# calicoctl apply -f bgpconfig.yaml 
Successfully applied 1 'BGPConfiguration' resource(s)

[root@k8s-m1 ~]# calicoctl get bgpconfig
NAME      LOGSEVERITY   MESHENABLED   ASNUMBER   
default   Info          false         64512 

02 配置指定節(jié)點充當(dāng)路由反射器

為方便讓BGPPeer輕松選擇節(jié)點寥茫，通過標(biāo)簽選擇器匹配

001 給路由器反射器節(jié)點打標(biāo)簽：
kubectl label node k8s-m1 route-reflector=true  

002 配置路由器反射器節(jié)點routeReflectorClusterID：
# calicoctl get node k8s-m1 -o yaml > rr-node2.yaml
# vi rr-node2.yaml
...
spec:
  bgp:
    ipv4Address: 192.168.153.25/24
    routeReflectorClusterID: 244.0.0.1 # 添加集群ID
...

[root@k8s-m1 ~]# calicoctl apply -f rr-node2.yaml
Successfully applied 1 'Node' resource(s)

3遣蚀、使用標(biāo)簽選擇器將路由反射器節(jié)點與其他非路由反射器節(jié)點配置為對等

# vi bgppeer.yaml
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: peer-with-route-reflectors
spec:
  nodeSelector: all()
  peerSelector: route-reflector == 'true'
  
[root@k8s-m1 ~]# calicoctl apply -f bgppeer.yaml
Successfully applied 1 'BGPPeer' resource(s)

4、查看節(jié)點的BGP連接狀態(tài)

[root@k8s-m1 ~]# calicoctl node status
Calico process is running.

IPv4 BGP status
+----------------+---------------+-------+----------+-------------+
|  PEER ADDRESS  |   PEER TYPE   | STATE |  SINCE   |    INFO     |
+----------------+---------------+-------+----------+-------------+
| 192.168.153.27 | node specific | up    | 07:51:58 | Established |
| 192.168.153.28 | node specific | up    | 07:51:58 | Established |
+----------------+---------------+-------+----------+-------------+

[root@k8s-node1 ~]# calicoctl node status
Calico process is running.

IPv4 BGP status
+----------------+---------------+-------+----------+-------------+
|  PEER ADDRESS  |   PEER TYPE   | STATE |  SINCE   |    INFO     |
+----------------+---------------+-------+----------+-------------+
| 192.168.153.25 | node specific | up    | 07:51:57 | Established |
+----------------+---------------+-------+----------+-------------+

[root@k8s-node2 ~]# calicoctl node status       
Calico process is running.

IPv4 BGP status
+----------------+---------------+-------+----------+-------------+
|  PEER ADDRESS  |   PEER TYPE   | STATE |  SINCE   |    INFO     |
+----------------+---------------+-------+----------+-------------+
| 192.168.153.25 | node specific | up    | 07:51:57 | Established |
+----------------+---------------+-------+----------+-------------+

選擇方案

01 網(wǎng)絡(luò)性能：首選路由方案，hostgw和BGP
02 集群規(guī)模：100+建議用calico
03 網(wǎng)絡(luò)限制：不能在宿主機刷路由表芭梯，不能跑BGP
04 是否需要網(wǎng)絡(luò)策略

辦公網(wǎng)絡(luò)與K8s網(wǎng)絡(luò)互通方案

網(wǎng)絡(luò)需求

01 辦公網(wǎng)絡(luò)與Pod網(wǎng)絡(luò)不通险耀。在微服務(wù)架構(gòu)下，開發(fā)人員希望在辦公電腦能直接連接K8s中注冊中心調(diào)試玖喘；
02 辦公網(wǎng)絡(luò)與Service網(wǎng)絡(luò)不通甩牺。在測試環(huán)境運行的mysql、redis等需要通過nodeport暴露累奈，維護成本大贬派；
03 現(xiàn)有虛擬機業(yè)務(wù)訪問K8s上的業(yè)務(wù)。

解決方案：打通辦公網(wǎng)絡(luò)與K8s網(wǎng)絡(luò)

方案一：專門準(zhǔn)備一臺Node負(fù)責(zé)轉(zhuǎn)發(fā)來自辦公網(wǎng)絡(luò)

1641715407863.png

01 k8s目標(biāo)網(wǎng)絡(luò) 10.244.0.0/16(pod),10.0.0.0/16(service)
02 Node1是k8s的Node節(jié)點(192.168.31.62)
03 路由器配置
--10.244.0.0/16 192.168.31.62 
--10.0.0.0/16   192.168.31.62 
04 Node1增加路由澎媒，源數(shù)據(jù)包（192.168.1.0） 
--192.168.1.0/24   10.244.0.0/16
--192.168.1.0/24   10.0.0.0/16


ip route add 10.244.0.0/16 via 192.168.153.25 dev ens32
ip route add 192.168.153.0/24 via 10.244.0.0/16 dev ens32

方案二：兩方上層路由器使用BGP做路由交換

1641715418549.png

01 核心交換機Calico路由反射器客戶端

網(wǎng)絡(luò)策略

概述

網(wǎng)絡(luò)策略（Network Policy）
01 用于限制Pod出入流量
02 提供Pod級別和Namespace級別網(wǎng)絡(luò)訪問控制

應(yīng)用場景

01 應(yīng)用程序間的訪問控制搞乏。例如微服務(wù)A允許訪問微服務(wù)B，微服務(wù)C不能訪問微服務(wù)A
02 開發(fā)環(huán)境命名空間不能訪問測試環(huán)境命名空間Pod
03 當(dāng)Pod暴露到外部時戒努，需要做Pod白名單
04 多租戶網(wǎng)絡(luò)環(huán)境隔離

Pod網(wǎng)絡(luò)入口方向隔離

01 基于Pod級網(wǎng)絡(luò)隔離：只允許特定對象訪問Pod（使用標(biāo)簽定義）请敦，允許白名單上的IP地址或者IP段訪問Pod
02 基于Namespace級網(wǎng)絡(luò)隔離：多個命名空間，A和B命名空間Pod完全隔離柏卤。

Pod網(wǎng)絡(luò)出口方向隔離

01 拒絕某個Namespace上所有Pod訪問外部
02 基于目的IP的網(wǎng)絡(luò)隔離：只允許Pod訪問白名單上的IP地址或者IP段
03 基于目標(biāo)端口的網(wǎng)絡(luò)隔離：只允許Pod訪問白名單上的端口

Demo

apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata:
  name: test-network-policy 
  namespace: default 
spec :
  podSelector:
    matchLabels:
      role: db 
  policyTypes:
  - Ingress 
  - Egress 
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        -172.17.1.0/24 
    - namespaceSelector:
        matchLabels:
          project: myproject 
    - podSelector:
        matchLabels:
          role: frontend 
    ports:
    - protocol: TCP 
      port: 6379
  egress:
  - to： 
    - ipBlock:
        cidr: 10.0.0.0/24 
    ports:
    - protocol: ТСР 
      port :5978
      
------------------------------------------------------------------------------
podSelector：目標(biāo)Pod冬三，根據(jù)標(biāo)簽選擇
policyTypes：策略類型，指定策略用于入站缘缚、出站流量勾笆。
Ingress：from是可以訪問的白名單，可以來自于IP段桥滨、命名空間窝爪、Pod標(biāo)簽等，ports是可以訪問的端口齐媒。
Egress：這個Pod組可以訪問外部的IP段和端口蒲每。

需求1：將default命名空間攜帶app=web標(biāo)簽的Pod隔離，只允許攜帶run=client1標(biāo)簽的Pod訪問80端口

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          run: client1
    ports:
    - protocol: TCP
      port: 80
---------------------------------------------------------------------------------
準(zhǔn)備測試環(huán)境：
kubectl create deployment web --image=nginx
kubectl run client1 --image=busybox -- sleep 36000
kubectl run client2 --image=busybox -- sleep 36000

[root@k8s-m1 ~]# kubectl get pod -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP               NODE        
client1               1/1     Running   0          61s   10.244.169.190   k8s-node2   
client2               1/1     Running   0          55s   10.244.169.130   k8s-node2   
web-96d5df5c8-7sjfg   1/1     Running   0          60s   10.244.169.191   k8s-node2   
web-96d5df5c8-c5bm2   1/1     Running   0          69s   10.244.169.189   k8s-node2   

[root@k8s-m1 ~]# kubectl get pod --show-labels 
NAME                  READY   STATUS    RESTARTS   AGE     LABELS
client1               1/1     Running   0          4m56s   run=client1
client2               1/1     Running   0          4m50s   run=client2
web-96d5df5c8-7sjfg   1/1     Running   0          4m55s   app=web,pod-template-hash=96d5df5c8
web-96d5df5c8-c5bm2   1/1     Running   0          5m4s    app=web,pod-template-hash=96d5df5c8

[root@k8s-m1 ~]# kubectl exec -it client1 -- sh
/ # wget 10.244.169.191
Connecting to 10.244.169.191 (10.244.169.191:80)
index.html           100% 


[root@k8s-m1 ~]# kubectl exec -it client2 -- sh 
/ # wget 10.244.169.191
Connecting to 10.244.169.191 (10.244.169.191:80)
index.html           100% 

#此時喻括，client1和client2都可以訪問default下邀杏，app=web的pod,執(zhí)行策略后，只有run=client1才能訪問app=web的pod,并且只是80端口

[root@k8s-m1 calico]# kubectl apply -f np1.yaml 

[root@k8s-m1 ~]# kubectl exec -it client1 -- sh
/ # wget 10.244.169.191
Connecting to 10.244.169.191 (10.244.169.191:80)
index.html           100% 
#但此時無法ping通唬血，因為只允許80端口

[root@k8s-m1 calico]# kubectl exec -it client2 -- sh 
/ # wget 10.244.169.191
Connecting to 10.244.169.191 (10.244.169.191:80)
......
#此時無法連接pod

[root@k8s-m1 calico]# kubectl delete -f np1.yaml 
networkpolicy.networking.k8s.io "test-network-policy" deleted

需求2：default命名空間下所有pod可以互相訪問望蜡，也可以訪問其他命名空間Pod，但其他命名空間不能訪問default命名空間Pod

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-from-other-namespaces
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}
    
 --------------------------------------------------------------------------------
 podSelector: {}：如果未配置拷恨，默認(rèn)所有Pod
 from.podSelector: {} : 如果未配置脖律，默認(rèn)不允許
 
 準(zhǔn)備測試環(huán)境：
 
kubectl run client3 --image=busybox  -n kube-system -- sleep 36000 

#此時，client1腕侄、client2小泉、client3均可以訪問default下的pod

[root@k8s-m1 calico]#  kubectl exec -it client3 -n kube-system -- sh 
/ # wget 10.244.169.191
Connecting to 10.244.169.191 (10.244.169.191:80)
index.html           100% 

執(zhí)行策略后芦疏，client2可以正常訪問，client1微姊、client2可以正常訪問酸茴，client3不能訪問
[root@k8s-m1 calico]# kubectl apply -f np2.yaml 
networkpolicy.networking.k8s.io/deny-from-other-namespaces created

[root@k8s-m1 calico]#  kubectl exec -it client3 -n kube-system -- sh 
/ # wget 10.244.169.191
Connecting to 10.244.169.191 (10.244.169.191:80)
......
#此時無法連接pod

[root@k8s-m1 calico]# kubectl delete -f np2.yaml 
networkpolicy.networking.k8s.io "deny-from-other-namespaces" deleted