k8s网络配置管理

docker容器的四种网络类型1.桥接2.联盟3.主机4.无docker跨节点的容器通信必须通过NAT机制宿主机上的容器一般都是私网地址它可以通过宿主机的物理网卡把数据包发送到其它物理节点但是无法接收到其它节点的响应报文所以数据包经过宿主机网卡时候必须通过NAT做源地址转换请求报文在本物理机需要做源...

weixin_30896763

3100人浏览 · 2019-06-29 17:33:00

weixin_30896763 · 2019-06-29 17:33:00 发布

docker容器的四种网络类型

1.桥接
2.联盟
3.主机
4.无

docker跨节点的容器通信必须通过NAT机制宿主机上的容器一般都是私网地址它可以通过宿主机的物理网卡把数据包

发送到其它物理节点但是无法接收到其它节点的响应报文所以数据包经过宿主机网卡时候必须通过NAT做源地址转换

请求报文在本物理机需要做源地址转换(SNAT) 发送到目标物理机后需要做目标地址转换(DNAT) 必须经过两级NAT 性能比较差

其NAT规则由docker自动创建无需用户手动创建

网络虚拟化的常用方案

1.虚拟网桥用纯软件的方式实现一个虚拟网桥设备
必须依靠叠加网络来实现需要增加额外的网络开销
需要多封装IP首部或者MAC首部
1.vxlan
2.host-gw
路由表信息量比较大
所有的宿主机必须在同一个二层网络中
2.多路复用

MacVLAN
3.硬件交换

物理网卡直接支持虚拟出多个接口

k8s网络类型

1.容器间通信
同一个pod内的所有容器通过lo接口直接通信
2.Pod间通信
k8s要求pod间的通信必须通过podIP直接到达不能经过任何转发
3.Pod和Service通信
两者的IP不在同一个网段
依靠iptables或者ipvs规则来实现数据转发通信
ipvs只能用来实现负载均衡其它功能无法实现如NAT转发
4.Service和集群外部客户端通信
依靠ingress来实现

flannel配置

k8s中的所有Pod都是属于同一个网段中都可以直接通信 flannel无法实现网络策略控制某些pod不能相互通信

网络管理包含以下功能

1.接口创建
2.地址分配
3.网络创建
默认使用vxlan的方式 flannel.1的接口就是用来封装隧道报文的
每创建一个Pod 创建一对虚拟网络接口一个连接pod 一个连接到虚拟网桥虚拟网桥有一个接口连接到物理网卡

网络策略 NetWorkPolicy

控制pod和pod之间是否能够相互通信

flannel配置参数
Network: flannel使用的CIDR格式的网络地址为pod分配地址
10.244.0.0/16 一级网络
master: 10.244.1.0/24 一级网络中的子网
node1: 10.244.2.0/24
SubnetLen: 把Network切分子网供各节点使用时,使用多长的掩码进行切分
默认是24位
用于动态控制支持的节点数和节点上能够运行的Pod数
主机地址越长支持的节点数就越多
网络地址越长同一主机上支持的pod数就越多
Backend: vxlan host-gw udp

flannel网络测试 选择两个不同节点上的pod进行通信测试
[root@k8s-master ~]# kubectl get pods -o wide
NAME                            READY     STATUS    RESTARTS   AGE       IP             NODE
myapp-deploy-67f6f6b4dc-jnsbg   1/1       Running   0          18s       10.244.2.116   node3
myapp-deploy-67f6f6b4dc-pd8ss   1/1       Running   0          18s       10.244.1.4     node2
myapp-deploy-67f6f6b4dc-zdxht   1/1       Running   0          18s       10.244.2.115   node3
[root@k8s-master ~]# kubectl exec -it myapp-deploy-67f6f6b4dc-pd8ss -- /bin/sh
/ # ping 10.244.2.116
PING 10.244.2.116 (10.244.2.116): 56 data bytes
64 bytes from 10.244.2.116: seq=0 ttl=62 time=1.258 ms
64 bytes from 10.244.2.116: seq=1 ttl=62 time=5.573 ms
64 bytes from 10.244.2.116: seq=2 ttl=62 time=0.951 ms
64 bytes from 10.244.2.116: seq=3 ttl=62 time=0.764 ms

网络抓包 查看数据包的转发路径
说明flannel默认为数据从cni0接口进来 经过flannel.0接口
最后从从物理网卡发出去的是vxlan的叠加网络报文
[root@node2 ~]# tcpdump -i cni0 -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cni0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:51:20.765638 IP 10.244.1.4 > 10.244.2.116: ICMP echo request, id 2560, seq 178, length 64
21:51:20.766146 IP 10.244.2.116 > 10.244.1.4: ICMP echo reply, id 2560, seq 178, length 64
21:51:21.766591 IP 10.244.1.4 > 10.244.2.116: ICMP echo request, id 2560, seq 179, length 64
21:51:21.767360 IP 10.244.2.116 > 10.244.1.4: ICMP echo reply, id 2560, seq 179, length 64

#默认是通过flannel.1接口进行通信
[root@k8s-master ~]# ip route show
default via 192.168.11.2 dev ens33 proto dhcp metric 100 
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1 
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink 
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.11.0/24 dev ens33 proto kernel scope link src 192.168.11.141 metric 100 

[root@k8s-master ~]# kubectl delete -f kube-flannel.yml 
clusterrole.rbac.authorization.k8s.io "flannel" deleted
clusterrolebinding.rbac.authorization.k8s.io "flannel" deleted
serviceaccount "flannel" deleted

[root@k8s-master ~]# kubectl apply -f kube-flannel.yml 

#直接通过物理网卡ens33进行通信
[root@node2 ~]# ip route show
default via 10.200.106.1 dev ens34 proto dhcp metric 101 
default via 192.168.11.2 dev ens33 proto dhcp metric 102 
10.200.106.0/23 dev ens34 proto kernel scope link src 10.200.107.98 metric 101 
10.244.0.0/24 via 192.168.11.141 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.11.143 dev ens33 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.11.0/24 dev ens33 proto kernel scope link src 192.168.11.142 metric 102 

直接在物理网卡上进行抓包测试
[root@node2 ~]# tcpdump -i ens33 -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
22:12:24.054961 IP 10.244.1.5 > 10.244.2.117: ICMP echo request, id 2304, seq 0, length 64
22:12:25.055260 IP 10.244.1.5 > 10.244.2.117: ICMP echo request, id 2304, seq 1, length 64
22:12:26.056018 IP 10.244.1.5 > 10.244.2.117: ICMP echo request, id 2304, seq 2, length 64

flannel配置实例

calico配置和使用

网络策略 NetWorkPolicy

拒绝所有出站和入站规则

放行所有出站目标为本名称空间内的所有pod

 [root@k8s-master ~]# kubectl apply -f \
> https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/rbac.yaml
clusterrole.rbac.authorization.k8s.io/calico created
clusterrole.rbac.authorization.k8s.io/flannel configured
clusterrolebinding.rbac.authorization.k8s.io/canal-flannel created
clusterrolebinding.rbac.authorization.k8s.io/canal-calico created
[root@k8s-master ~]# kubectl apply -f \
> https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/canal.yaml
#创建了一些自定义的k8s资源
configmap/canal-config created
daemonset.extensions/canal created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created

#每个节点都需要运行一个canal pod 表示canal安装成功
[root@k8s-master ~]# kubectl get pods -n kube-system
NAME                                   READY     STATUS    RESTARTS   AGE
canal-9nt4d                            3/3       Running   0          3m
canal-fpxqt                            3/3       Running   0          3m
canal-jbpd7                            3/3       Running   0          3m

canal安装

apiVersion: networking.k8s.io/v1
kind:  NetworkPolicy
metadata:
  name:  deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress



apiVersion: networking.k8s.io/v1
kind:  NetworkPolicy
metadata:
  name:  deny-all-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

ingress-deny.yaml

apiVersion: networking.k8s.io/v1
kind:  NetworkPolicy
metadata:
  name:  allow-all-ingress
spec:
  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress


apiVersion: networking.k8s.io/v1
kind:  NetworkPolicy
metadata:
  name:  allow-egress
spec:
  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

View Code

apiVersion: networking.k8s.io/v1
kind:  NetworkPolicy
metadata:
  name:  allow-80-ingress
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - ipBlock:
        cidr: 10.244.0.0/16
        except:
        - 10.244.1.2/32
    ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

ingress-80.yaml

#同一网络规则在不同的配置清单中都定义过的话 
#后执行的清单设置会覆盖前面执行清单中的配置
[root@k8s-master networkpolicy]# kubectl apply -f ingress-allow.yaml -n dev
networkpolicy.networking.k8s.io/deny-all-ingress configured
[root@k8s-master networkpolicy]# curl 10.244.2.2
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@k8s-master networkpolicy]# curl 10.244.1.2
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@k8s-master networkpolicy]# kubectl apply -f ingress-def.yaml -n dev
networkpolicy.networking.k8s.io/deny-all-ingress configured
[root@k8s-master networkpolicy]# curl 10.244.2.2

[root@k8s-master networkpolicy]# kubectl get networkpolicy -n dev
NAME                POD-SELECTOR   AGE
allow-all-ingress   <none>         17s
deny-all-ingress    <none>         12m

[root@k8s-master networkpolicy]# kubectl label pods pod1 app=myapp -n dev
pod/pod1 labeled

[root@k8s-master networkpolicy]# curl 10.244.2.2:443
^C
[root@k8s-master networkpolicy]# curl 10.244.2.2:443
curl: (7) Failed connect to 10.244.2.2:443; Connection refused

View Code

转载于:https://www.cnblogs.com/yxh168/p/11106832.html

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub