网络基础知识
交换技术
广播域
01 交换机在转发数据时会先进行广播，这个广播可以发送的区域就是一个广播域
02 交换机之间对广播帧是透明的，所以交换机之间组成的网络是一个广播域
03 路由器的一个接口下的网络是一个广播域，所以路由器可以隔离广播域
ARP（地址解析协议）
01 发送这个广播帧是由ARP协议实现
02 ARP是通过IP地址获取物理地址的一个TCP/IP协议
三层交换机
01 二层交换机只工作在数据链路层
02 路由器则工作在网络层
03 三层交换机可同时工作在数据链路层和网络层，并根据 MAC地址或IP地址转发数据包
VLAN（Virtual Local Area Network）：虚拟局域网
01 VLAN是一种将局域网设备从逻辑上划分成一个个网段
02 一个VLAN就是一个广播域，VLAN之间的通信是通过第3层的路由器来完成的
03 VLAN应用非常广泛，基本上大部分网络项目都会划分vlan
VLAN的主要好处
01 分割广播域，减少广播风暴影响范围。
02 提高网络安全性，根据不同的部门、用途、应用划分不同网段
路由技术
路由器主要分为两个端口类型
路由器主要分为两个端口类型：LAN口和WAN口
01 WAN口：配置公网IP，接入到互联网，转发来自LAN口的IP数据包。
02 LAN口：配置内网IP（网关），连接内部交换机
功能
01 路由器是连接两个或多个网络的硬件设备
02 将从端口上接收的数据包，根据数据包的目的地址智能转发出去
路由器的功能
• 路由
• 转发
• 隔离子网
• 隔离广播域
路由
01 静态路由：指人工手动指定到目标主机的地址然后记录在路由表中，如果其中某个节点不可用则需要重新指定。
02 动态路由：则是路由器根据动态路由协议自动计算出路径永久可用，能实时地适应网络结构的变化。
03 常用的动态路由协议：
• RIP（ Routing Information Protocol ，路由信息协议）
• OSPF（Open Shortest Path First，开放式最短路径优先）
• BGP（Border Gateway Protocol，边界网关协议）
K8s网络模型
回看Docker容器网络模型
1641625262454.png
相关概念
01 Linux在网络栈中引入网络命名空间，将独立的网络协议栈隔离到不同的命令空间中，彼此间无法通信；
02 Docker利用这一特性，实现不同容器间的网络隔离。
• Veth设备对：Veth设备对的引入是为了实现在不同网络命名空间的通信。
• Iptables/Netfilter：Docker使用Netfilter实现容器网络转发。
• 网桥（docker0）：网桥是一个二层网络设备，通过网桥可以将Linux支持的不同的端口连接起来，并实现类似交换机那样的多对多的通信，在宿主机的网络命名空间中
• 路由：Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里。
容器之间通信
二层网络之间的通信
容器访问外网
通过docker0，NAT转发到外网
ip route
Pod网络
1641627288967.png
infra container
Pod是K8s最小调度单元，一个Pod由一个容器或多个容器组成，当多个容器时，怎么都用这一个Pod IP？
01 k8s会在每个Pod里先启动一个infra container小容器，然后让其他的容器连接进来这个网络命名空间
02 其他容器看到的网络就完全一样了。即网络设备、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 通过虚拟以太网设备（veth0）连接到 root namespace；
02 网桥cbr0中为veth0配置了一个网段。一旦数据包到达网桥，网桥使用ARP协议解析出其正确的目标网段veth1；
03 网桥 cbr0 将数据包发送到 veth1；
04 数据包到达 veth1 时，被直接转发到Pod2的network namespace中的eth0 网络设备。
两个Pod在不同Node上
1641627451494.png
相比同节点Pod通信，这里源Pod发出的数据包需要传递到目标节点，但是源Pod并不知道目标Pod在哪个节点上？
因此，为了实现容器跨主机通信需求，就需要部署网络组件，这些网络组件都必须满足如下要求：
• 一个Pod一个IP
• 所有的 Pod 可以与任何其他 Pod 直接通信
• 所有节点可以与所有 Pod 直接通信
• Pod 内部获取到的 IP 地址与其他 Pod 或节点与其通信时的 IP 地址是同一个（pod绑定IP生命周期）
CNI（容器网络接口）
CNI（Container Network Interface，容器网络接口)：是一个容器网络规范，Kubernetes网络采用的就是这个CNI规范，负责初始化infra容器的网络设备。
CNI二进制程序默认路径：/opt/cni/bin/
项目地址：https://github.com/containernetworking/cni
以Flannel网络组件为例，当部署Flanneld后，会在每台宿主机上生成它对应的CNI配置文件（它其实是一个
ConfigMap），从而告诉Kubernetes要使用 Flannel 作为容器网络方案。
CNI配置文件默认路径：/etc/cni/net.d
当 kubelet 组件需要创建 Pod 的时候，先调用dockershim它先创建一个 Infra 容器。然后调用 CNI 插件为 Infra 容器配置网络
这两个路径可在kubelet启动参数中定义：
--network-plugin=cni
--cni-conf-dir=/etc/cni/net.d
--cni-bin-dir=/opt/cni/bin
K8s网络组件之Calico
概述
01 Calico是一个纯三层的数据中心网络方案，Calico支持广泛的平台，包括Kubernetes、OpenStack等。
02 Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的虚拟路由器（ vRouter） 来负责数据转发，而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息向整个 Calico 网络内传播。
03 Calico 项目还实现了 Kubernetes 网络策略，提供ACL功能。
04 实际上，Calico项目提供的网络解决方案，与Flannel的host-gw模式几乎一样。也就是说，Calico也是基于
路由表实现容器数据包转发
05 但不同于Flannel使用flanneld进程来维护路由信息的做法，而Calico项目使用BGP协议来自动维护整个集群的路由信息
06 BGP英文全称是Border Gateway Protocol，即边界网关协议，它是一种自治系统间的动态路由发现协议，
与其他 BGP 系统交换网络可达信息
BGP介绍
1641679622038.png
01 在这个图中，有两个自治系统（autonomous system，简称为AS）：AS 1 和 AS 2。
02 在互联网中，一个自治系统(AS)是一个有权自主地决定在本系统中应采用何种路由协议的小型单位。
03 这个网络单位可以是一个简单的网络也可以是一个由一个或多个普通的网络管理员来控制的网络群体，它是一个单独的可管理的网络单元（例如一所大学，一个企业或者一个公司个体）。
04 一个自治系统有时也被称为是一个路由选择域（routing domain）。一个自治系统将会分配一个全局的唯一的16位号码，有时我们把这个号码叫做自治系统号（ASN）。
05 在正常情况下，自治系统之间不会有任何来往。如果两个自治系统里的主机，要通过 IP 地址直接进行通信，我们就必须使用路由器把这两个自治系统连接起来。BGP协议就是让他们互联的一种方式
1641680464507.png
在了解了 BGP 之后，Calico 项目的架构就非常容易理解了，
Calico主要由三个部分组成：
01 Felix：以DaemonSet方式部署，运行在每一个Node节点上，主要负责维护宿主机上路由规则以及ACL规则
02 BGP Client（BIRD）：主要负责把 Felix 写入 Kernel 的路由信息分发到集群 Calico 网络
03 Etcd：分布式键值存储，保存Calico的策略和网络配置状态。
04 calicoctl：命令行管理Calico。
部署
Calico存储有两种方式：
• 数据存储在etcd
https://docs.projectcalico.org/v3.9/manifests/calico-etcd.yaml
• 数据存储在Kubernetes API Datastore服务中
https://docs.projectcalico.org/manifests/calico.yaml
---------------------------------------------------------------------------------------
数据存储在etcd中还需要修改yaml：
• 配置连接etcd地址，如果使用https，还需要配置证书。（ConfigMap和Secret位置）
---------------------------------------------------------------------------------------
根据实际网络规划修改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 对象存储地址等信息。
默认配置文件路径 /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状态
[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方案，源数据包封装在宿主机网络包里进行转发和通信。（默认）
• BGP：基于路由转发，每个节点通过BGP协议同步路由表，写到宿主机。 （值设置Never）
• CrossSubnet：同时支持BGP和IPIP，即根据子网选择转发方式。
IPIP工作模式
概述
IPIP模式：采用Linux IPIP隧道技术实现的数据包封装与转发。
IP 隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，Linux系统内核实现的
IP隧道技术主要有三种：IPIP、GRE、SIT
默认使用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 数据包（原始数据包）从容器出去到达宿主机，宿主机根据路由表发送到tunl0设备（IP隧道设备）
02 Linux内核IPIP驱动将原始数据包封装在宿主机网络的IP包中（新的IP包目的地之是原IP包的下一跳地
址，即192.168.31.63）。
03 数据包根据宿主机网络到达Node2；
04 Node2收到数据包后，使用IPIP驱动进行解包，从中拿到原始数据包；
05 然后根据路由规则，根据路由规则将数据包转发给cali设备，从而到达容器2
BGP工作模式
概述
01 基于路由转发，每个节点通过BGP协议同步路由表
02 将每个宿主机当做路由器，实现数据包转发
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 数据包从容器出去到达宿主机；
02 宿主机根据路由规则，将数据包转发给下一跳（网关）；
03 到达Node2，根据路由规则将数据包转发给cali设备，从而到达容器2。
Route Reflector 模式（RR）
背景
1641711433877.png
01 Calico 维护的网络在默认是（Node-to-Node Mesh）全互联模式
02 Calico集群中的节点之间都会相互建立连接，用于路由交换
03 但是随着集群规模的扩大，mesh模式将形成一个巨大服务网格，连接数成倍增加，就会产生性能问题
04 这时就需要使用 Route Reflector（路由器反射）模式解决这个问题
解决
1641712150416.png
01 确定一个或多个Calico节点充当路由反射器，集中分发路由
02 让其他节点从这个RR节点获取路由信息
具体步骤：
01 关闭 node-to-node模式
添加 default BGP配置，调整 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 配置指定节点充当路由反射器
为方便让BGPPeer轻松选择节点，通过标签选择器匹配
001 给路由器反射器节点打标签：
kubectl label node k8s-m1 route-reflector=true
002 配置路由器反射器节点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、使用标签选择器将路由反射器节点与其他非路由反射器节点配置为对等
# 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、查看节点的BGP连接状态
[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 网络性能：首选路由方案，hostgw和BGP
02 集群规模：100+建议用calico
03 网络限制：不能在宿主机刷路由表，不能跑BGP
04 是否需要网络策略
办公网络与K8s网络互通方案
网络需求
01 办公网络与Pod网络不通。在微服务架构下，开发人员希望在办公电脑能直接连接K8s中注册中心调试；
02 办公网络与Service网络不通。在测试环境运行的mysql、redis等需要通过nodeport暴露，维护成本大；
03 现有虚拟机业务访问K8s上的业务。
解决方案：打通办公网络与K8s网络
方案一：专门准备一台Node负责转发来自办公网络
1641715407863.png
01 k8s目标网络 10.244.0.0/16(pod),10.0.0.0/16(service)
02 Node1是k8s的Node节点(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增加路由，源数据包（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路由反射器客户端
网络策略
概述
网络策略（Network Policy）
01 用于限制Pod出入流量
02 提供Pod级别和Namespace级别网络访问控制
应用场景
01 应用程序间的访问控制。例如微服务A允许访问微服务B，微服务C不能访问微服务A
02 开发环境命名空间不能访问测试环境命名空间Pod
03 当Pod暴露到外部时，需要做Pod白名单
04 多租户网络环境隔离
Pod网络入口方向隔离
01 基于Pod级网络隔离：只允许特定对象访问Pod（使用标签定义），允许白名单上的IP地址或者IP段访问Pod
02 基于Namespace级网络隔离：多个命名空间，A和B命名空间Pod完全隔离。
Pod网络出口方向隔离
01 拒绝某个Namespace上所有Pod访问外部
02 基于目的IP的网络隔离：只允许Pod访问白名单上的IP地址或者IP段
03 基于目标端口的网络隔离：只允许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：目标Pod，根据标签选择
policyTypes：策略类型，指定策略用于入站、出站流量。
Ingress：from是可以访问的白名单，可以来自于IP段、命名空间、Pod标签等，ports是可以访问的端口。
Egress：这个Pod组可以访问外部的IP段和端口。
需求1：将default命名空间携带app=web标签的Pod隔离，只允许携带run=client1标签的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
---------------------------------------------------------------------------------
准备测试环境：
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,执行策略后，只有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: {}：如果未配置，默认所有Pod
from.podSelector: {} : 如果未配置，默认不允许
准备测试环境：
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%
执行策略后，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
网友评论