kubernetes快速入门13-网络

kubernetes快速入门13-网络

kubernetes快速入门13-网络

在kubernetes中容器有四种网络模型：

bridge，桥接式网络，自由式网络名称空间 joined，共享使用另外容器的网络空间 opened，容器直接共享宿主机的网络名称空间 Closed或None，不使用任何网络空间

docker网络存在的问题：跨越节点间容器访问时要经过各自宿主机的网络并做SNAT和DNATl转换，发起方容器访问目标容器是访问目标容器所在宿主机的网络，通过DNAT转换才能访问到目标容器，目标容器看不到发起方容器的IP地址，而发起方也看不到目标容器的IP地址。通过SNAT和DNAT转换进行通信效率低。

k8s的网络通信：

容器间通信： 同一个pod内的多个容器间的通信，直接使用lo回环地址 pod间通信：直接使用Pod的网络IP地址通信 Pod与Service通信： Pod的IP与ClusterIP进行通信 Service与集群外部的通信：外部的LB，ingress, NodePort

k8s自己不提供网络解决方案，它支持CNI(容器网络插件，这只是一种规范)网络插件方式引入网络解决方案，常见有flannel，calico，canal等，canal是flannel和calico的结合产物，在flannel的基础上增加的网络策略的实现。

flannel网络

flannel支持多种报文的承载方式：

VxLAN，使用隧道网络实现，开销较大，这是flannel的默认工作方式。 VxLAN也有两种工作方式： 1. 原生vxlan 2. directrouting, 直接路由，两个物理节点在同一个三层网络中则使用直接路由，如果物理节点之间有路由器进行隔离，那就降级为使用原生的vxlan的隧道叠加方式通信 host-gw: host gateway 主机网关，把宿主机的物理网卡虚拟出一个网卡作为pod的默认网关，通过路由表转发的方式实现跨物理节点的Pod间的访问，各个物理节点需要在同一个三层网络中 UDP，使用普通的UDP方式，效率很低，建议不要使用

flannel的配置参数

Network: flannel使用的CIDR格式的网络地址，用于为Pod配置网络功能 SubnetLen: 把Network切分子网供各节点使用时，使用多长的掩码进行切分，默认为24位 SubnetMin: 用于分配给节点子网的起始网络 SubnetMax: 用于分配给节点子网的最大网络 Backend: flannel的工作方式，vxlan, host-gw, udp

flannel工作原理探索

flannel插件被安装后默认以vxlan的方式工作，并以DaemonSet控制器管理flannel的Pod，即每个物理节点上运行一个此pod，该pod共享宿主机的网络名称空间。

在node02节点上查看当前的网络接口及路由信息

root@node02:~# ifconfig cni0: flags=4163 mtu 1450 inet 10.244.1.1 netmask 255.255.255.0 broadcast 10.244.1.255 ... docker0: flags=4099 mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ... ens33: flags=4163 mtu 1500 inet 192.168.101.41 netmask 255.255.255.0 broadcast 192.168.101.255 ... flannel.1: flags=4163 mtu 1450 inet 10.244.1.0 netmask 255.255.255.255 broadcast 0.0.0.0 ... ...

cni0和flannel.1两个接口是部署完flannel后自动生成的网络接口，cni0为一个网桥设备，负责该节点上容器间的通信，当该节点中的Pod需要访问该节点外的pod时数据报文就会通过flannel.1接口进行隧道报文封装。这两个接口的mtu值为1450，为隧道报的封装预留了一些空间。

再来看看该主机的路由信息

root@node02:~# ip route default via 192.168.101.1 dev ens33 proto static 10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 # 本机的pod就直接走cni0网络 10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink # 其他节点的pod网络需要走flannel.1接口进行隧道转发 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 192.168.101.0/24 dev ens33 proto kernel scope link src 192.168.101.41

从路由信息可知如果要访问其他节点的上Pod，那就需要把数据路由到flannel.1这个接口上进行隧道报文封装，毕竟使用了隧道技术，开销较大。

以一个Ping报文的事例来看看Pod间数据是怎么进行通信的

k8s@node01:~$ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES myapp-0 1/1 Running 1 20h 10.244.2.117 node03 myapp-1 1/1 Running 2 2d5h 10.244.1.88 node02 myapp-2 1/1 Running 2 2d5h 10.244.2.116 node03 # 在node03上运行的Pod中对node02上运行的Pod进行ping操作 k8s@node01:~$ kubectl exec -it myapp-0 -- /bin/sh / # ping 10.244.1.88 # 在node02上抓包看看 root@node02:~# tcpdump -i flannel.1 -nn icmp # flannel.1接口能看到icmp包的信息 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on flannel.1, link-type EN10MB (Ethernet), capture size 262144 bytes 15:03:27.659305 IP 10.244.2.117 > 10.244.1.88: ICMP echo request, id 5888, seq 69, length 64 15:03:27.659351 IP 10.244.1.88 > 10.244.2.117: ICMP echo reply, id 5888, seq 69, length 64 ... root@node02:~# tcpdump -i cni0 -nn icmp # cni0也能看到icmp包的信息 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on cni0, link-type EN10MB (Ethernet), capture size 262144 bytes 15:03:45.672189 IP 10.244.2.117 > 10.244.1.88: ICMP echo request, id 5888, seq 87, length 64 15:03:45.672244 IP 10.244.1.88 > 10.244.2.117: ICMP echo reply, id 5888, seq 87, length 64 ... # 物理接口ens33上没有icmp包的信息，这是因为从node03节点上的Ping包在进入到node02节点时就被flannel进行了隧道封装，使用了overlay网络叠加技术，所以直接抓icmp包是看不到的，但对数据包进行分析，可以看到被封装后的报文，如下 root@node02:~# tcpdump -i ens33 -nn ... 13:54:50.800954 IP 192.168.101.42.46347 > 192.168.101.41.8472: OTV, flags [I] (0x08), overlay 0, instance 1 IP 10.244.2.117 > 10.244.1.88: ICMP echo request, id 3328, seq 4, length 64 13:54:50.801064 IP 192.168.101.41.51235 > 192.168.101.42.8472: OTV, flags [I] (0x08), overlay 0, instance 1 IP 10.244.1.88 > 10.244.2.117: ICMP echo reply, id 3328, seq 4, length 64 ...

flannel网络优化

默认的vxlan工作方式在跨节点间的访问时进行隧道转发，效率不高，flannel还支持增加一个Directrouing参数，让其在跨节点间通信时直接使用路由技术，而不使用隧道转发，这样可以提高性能。

先下载在部署flannel网络插件时的yaml文件，并增加Directrouing参数

k8s@node01:~/install_k8s$ wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml # 编辑该文件，并在ConfigMap资源中的“net-conf.json”这个key的值中增加"Directrouing" k8s@node01:~/install_k8s$ vim kube-flannel.yml ... net-conf.json: | { "Network": "10.244.0.0/16", "Backend": { "Type": "vxlan", "Directrouting": true # 增加此key/value，注意上一行尾的逗号 } } ... # 先删除之前部署的flannel k8s@node01:~/install_k8s$ kubectl delete -f kube-flannel.yml # 再部署flannel k8s@node01:~/install_k8s$ kubectl apply -f kube-flannel.yml

再来看看node02节点上的路由信息

root@node02:~# ip route show default via 192.168.101.1 dev ens33 proto static 10.244.0.0/24 via 192.168.101.40 dev ens33 10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 10.244.2.0/24 via 192.168.101.42 dev ens33 # 到其他节点的Pod网络就直接走物理接口 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 192.168.101.0/24 dev ens33 proto kernel scope link src 192.168.101.41

现在到10.244.2.0/24时就不再走flannel.1接口，而是直接路由到物理接口ens33。而现在使用tcpdump命令在ens33接口上抓到相应Pod间的ICMP包。

host-gw的工作方式有点类似vxlan的directrouting，都是把宿主机的物理接口当作网关使用，只是在使用host-gw时要求集群内的所有节点都应该在同一个三层网络中。

注意： 生产环境中k8s集群已在跑业务时不能直接删除flannel后再增加参数后再应用，这样会导致集群中的Pod间通信中断。在刚部署好集群时就应该做flannel网络的优化。

基于Calico网络策略

更多关于calico的信息请参考：EE，OpenStack和裸机服务。

flannel解决了跨物理节点间pod网络的通信，但它缺少定义网络策略的功能，Calico同样能提供pod间的网络，也能提供网络策略，但Calico较flannel较为复杂，学习门槛较高，所以我们可以在使用flannel提供网络下再安装Calico，只使用它的网络策略功能。

flannel提供基础网络，而让Calico提供网络策略的安装请参考：server接口进行的。

# 下载其实就是 canal 这个网络插件，项目地址：https://github.com/projectcalico/canal，其文档文档也是跳转到calico的文档 k8s@node01:~/install_k8s$ wget https://docs.projectcalico.org/manifests/canal.yaml # 应用后会创建一大堆资源对象，大部分都是CRD(自定义资源定义) k8s@node01:~/install_k8s$ kubectl apply -f canal.yaml configmap/canal-config created customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created clusterrole.rbac.authorization.k8s.io/calico-node created clusterrole.rbac.authorization.k8s.io/flannel configured clusterrolebinding.rbac.authorization.k8s.io/canal-flannel created clusterrolebinding.rbac.authorization.k8s.io/canal-calico created daemonset.apps/canal created serviceaccount/canal created deployment.apps/calico-kube-controllers created serviceaccount/calico-kube-controllers created

Canal网络插件也是使用daemonset控制器管理，一个物理节点只运行一个pod，且共享物理节点的网络名称空间。相关资源都存放在kube-system名称空间。

k8s@node01:~/install_k8s$ kubectl get pods -n kube-system -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES calico-kube-controllers-578894d4cd-t66mz 1/1 Running 0 2m3s 10.244.2.126 node03 canal-fcpmq 2/2 Running 0 2m3s 192.168.101.41 node02 canal-jknl6 2/2 Running 0 2m3s 192.168.101.42 node03 canal-xsg99 2/2 Running 0 2m3s 192.168.101.40 node01 ...

安装完成后，k8s中会多出一个名叫networkpolicy的资源对象，可简写为netpol，同样可以使用kubectl explain networkpolicy查看资源的帮助信息

先创建两个名称空间便于做测试

k8s@node01:~/install_k8s$ kubectl create namespace dev k8s@node01:~/install_k8s$ kubectl create namespace prod

再在两个名称间中运行受Deployment控制器控制的pod

k8s@node01:~/networkpolicy$ cat deployment-pods.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy spec: replicas: 2 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp-pod image: ikubernetes/myapp:v1 k8s@node01:~/networkpolicy$ kubectl apply -f deployment-pods.yaml -n dev deployment.apps/myapp-deploy created k8s@node01:~/networkpolicy$ kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES myapp-deploy-6f96ddbbf9-x4jps 1/1 Running 0 96s 10.244.2.3 node03 myapp-deploy-6f96ddbbf9-xs227 1/1 Running 0 96s 10.244.1.3 node02 k8s@node01:~/networkpolicy$ kubectl get pods -n prod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES myapp-deploy-6f96ddbbf9-92s5g 1/1 Running 0 88s 10.244.1.4 node02 myapp-deploy-6f96ddbbf9-djwc6 1/1 Running 0 88s 10.244.2.4 node03

在没有网络策略前提下，这4个Pod间是可以互相通信的。现在利用networkpolicy制定网络策略

k8s@node01:~/networkpolicy$ cat netpol-test.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: netpo-test spec: podSelector: {} # 应用名称空间的所有pod policyTypes: - Ingress k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

此规则未定义ingress和egress，但策略类型指定为Ingress，表示在dev名称空间中的所有pod的入站请求使用默认的拒绝策略，在prod名称空间中的Pod中ping名称空间为dev中的pod，看是否能Ping通

k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- ping 10.244.2.3 PING 10.244.2.3 (10.244.2.3): 56 data bytes ^C k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- ping 10.244.1.3 PING 10.244.1.3 (10.244.1.3): 56 data bytes ^C # 都无法Ping通

再试一下dev名称空间中的Pod间是否能Ping能

k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-xs227 -n dev -- ping 10.244.2.3 PING 10.244.2.3 (10.244.2.3): 56 data bytes # 依然是不通的

这样的策略把pod的所有入站数据全部拒绝了。修改策略，开放dev名称空间中所有pod的入站点流量

k8s@node01:~/networkpolicy$ cat netpol-test.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: netpo-test spec: podSelector: {} # 应用名称空间的所有pod ingress: # 增加入站策略，但设置为空 - {} policyTypes: - Ingress k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

入站策略设置为空，而策略类型为Ingress，这表示入站变允许所有流量

# 在宿主机也可以直接访问dev空间中的两个Pod的ip地址，能正常访问其相当的服务 k8s@node01:~/networkpolicy$ curl 10.244.2.3 Hello MyApp | Version: v1 | Pod Name k8s@node01:~/networkpolicy$ curl 10.244.1.3 Hello MyApp | Version: v1 | Pod Name

修改策略，允许10.244.0.0/16网段访问dev名称空间中所有pod的所有端口，但除去prod名称空间中的pod地址为10.244.1.4/32的pod

k8s@node01:~/networkpolicy$ cat netpol-test.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: netpo-test spec: podSelector: {} # 应用名称空间的所有pod ingress: - from: - ipBlock: cidr: 10.244.0.0/16 except: - 10.244.1.4/32 policyTypes: - Ingress k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

分别在prod名称空间中的2个Pod中进行测试

# 地址为 10.244.1.4/32 的pod无法访问 k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- /usr/bin/wget -O - -q 10.244.2.3 ^C # 另一个Pod则可以正常访问 k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-djwc6 -n prod -- /usr/bin/wget -O - -q 10.244.2.3 Hello MyApp | Version: v1 | Pod Name

现在想实现在dev名称空间的pod可以相互访问，但是prod名称空间的Pod则无法访dev名称空间中的pod。这里就需要使用到标签选择器，先对dev名称空间里的Pod打标签

k8s@node01:~/networkpolicy$ kubectl get pods -n dev NAME READY STATUS RESTARTS AGE myapp-deploy-6f96ddbbf9-x4jps 1/1 Running 0 45m myapp-deploy-6f96ddbbf9-xs227 1/1 Running 0 45m k8s@node01:~/networkpolicy$ kubectl label pod myapp-deploy-6f96ddbbf9-x4jps ns=dev -n dev pod/myapp-deploy-6f96ddbbf9-x4jps labeled k8s@node01:~/networkpolicy$ kubectl label pod myapp-deploy-6f96ddbbf9-xs227 ns=dev -n dev pod/myapp-deploy-6f96ddbbf9-xs227 labeled k8s@node01:~/networkpolicy$ kubectl get pods -n dev --show-labels NAME READY STATUS RESTARTS AGE LABELS myapp-deploy-6f96ddbbf9-x4jps 1/1 Running 0 46m app=myapp,ns=dev,pod-template-hash=6f96ddbbf9 myapp-deploy-6f96ddbbf9-xs227 1/1 Running 0 46m app=myapp,ns=dev,pod-template-hash=6f96ddbbf9

给名称空间也打个标签

k8s@node01:~/networkpolicy$ kubectl label ns prod ns=prod namespace/prod labeled k8s@node01:~/networkpolicy$ kubectl label ns dev ns=dev namespace/dev labeled k8s@node01:~/networkpolicy$ kubectl get ns --show-labels NAME STATUS AGE LABELS default Active 10d dev Active 89m ns=dev ingress-nginx Active 5d2h app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx kube-node-lease Active 10d kube-public Active 10d kube-system Active 10d kubernetes-dashboard Active 31h prod Active 88m ns=prod

再来修改策略文件

k8s@node01:~/networkpolicy$ cat netpol-test.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: netpo-test spec: podSelector: matchLabels: ns: dev ingress: - from: - namespaceSelector: matchLabels: ns: dev policyTypes: - Ingress k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

现在的情况为prod名称空间里的两个pod都无法访问dev名称空间中pod，而dev名称空间中的pod可以相互访问

# 无法访问 k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-djwc6 -n prod -- /usr/bin/wget -O - -q 10.244.2.3 ^C k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- /usr/bin/wget -O - -q 10.244.2.3 ^C k8s@node01:~/networkpolicy$ kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES myapp-deploy-6f96ddbbf9-x4jps 1/1 Running 0 60m 10.244.2.3 node03 myapp-deploy-6f96ddbbf9-xs227 1/1 Running 0 60m 10.244.1.3 node02 # dev名称空间中的pod可以互相访问 k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-xs227 -n dev -- /usr/bin/wget -O - -q 10.244.2.3 Hello MyApp | Version: v1 | Pod Name

现在想开放80端口上的服务给prod中的pod访问，那修改策略文件如下

k8s@node01:~/networkpolicy$ cat netpol-test.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: netpo-test spec: podSelector: matchLabels: ns: dev ingress: - from: - namespaceSelector: matchLabels: ns: dev - from: # 增加一条开放给prod名称空间的权限 - namespaceSelector: matchLabels: ns: prod ports: - protocol: TCP port: 80 policyTypes: - Ingress k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

现在prod中的pod就可以访问dev名称空间中pod提供的kubectl exec myapp-deploy-6f96ddbbf9-djwc6 -n prod -- /usr/bin/wget -O - -q 10.244.2.3 Hello MyApp | Version: v1 | Pod Name k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- /usr/bin/wget -O - -q 10.244.2.3 Hello MyApp | Version: v1 | Pod Name # ping服务未开放，无法ping通 k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- ping 10.244.2.3 PING 10.244.2.3 (10.244.2.3): 56 data bytes ^C

networkpolicy的思想类似iptables，也是对出站与入站的流量进行过虑。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。