随着Kubernetes王者时代的到来,计算、网络、存储、安全是Kubernetes绕不开的话题,本次主要分享Kubernetes网络原理及方案。
在kubernetes中存在着两种IP,分别是podIP和service Cluster IP.podIP是指某个网卡或者虚拟设备上的,是真实存在的。service Cluster IP是一个虚拟IP,是由kube-proxy使用iptables规则重定向到本地的端口,再有负载均衡器分发到pod上的。
网络的命名空间:Linux在网络栈中引入网络命名空间,将独立的网络协议栈隔离到不同的命令空间中,彼此间无法通信;docker利用这一特性,实现不容器间的网络隔离。
Veth设备对:Veth设备对的引入是为了实现在不同网络命名空间的通信。
Iptables/Netfilter:Netfilter负责在内核中执行各种挂接的规则(过滤、修改、丢弃等),运行在内核 模式中;Iptables模式是在用户模式下运行的进程,负责协助维护内核中Netfilter的各种规则表;通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制。
网桥:网桥是一个二层网络设备,通过网桥可以将linux支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。
路由:Linux系统包含一个完整的路由功能,当IP层在处理数据发送或转发的时候,会使用路由表来决定发往哪里。
单机网络模式:分为四种网络模式:host,none,container,bridge,详细信息请看:docker网络模式
多机网络模式:Docker在1.9版本以后引入了Libnetwork项目,支持docker原生的跨节点网络通信。还可以使用插件引入第三方的解决方案,如:flannel,calico等。
同一个Pod的容器共享同一个网络命名空间,它们之间的访问可以用localhost地址 + 容器端口就可以访问。
同一Node中Pod的默认路由都是docker0的地址,由于它们关联在同一个docker0网桥上,地址网段相同,所有它们之间应当是能直接通信的。
不同Node中Pod间通信要满足2个条件: Pod的IP不能冲突; 将Pod的IP和所在的Node的IP关联起来,通过这个关联让Pod可以互相访问。
service是kubernetes的核心概念,是一组pod的集合,可以将pod对外提供一个统一的入口地址,访问该地址和端口就可以将请求分发到后端的容器。其实就相当于pod的负载均衡器。
通过配置yaml配置文件可以指定这个LB的ip类型,分配策略。yaml格式如下
可以通过spec.type来指定service的类型,一共有三种:clusterIP,nodePort,LoadBablance。
clusterIP:默认的类型,虚拟的service ip,可用于集群内部的pod之间的访问,当然需要建立网络策略(这个以后再讨论)。node上kube-proxy通过iptables规则进行转发。也就是说这个虚拟的IP地址是不能通过node直接进行访问,需要经过kube-proxy根据规则进行转发才能够访问到pod。而pod之间访问时可以利用这个虚拟ip的。
nodePort:指定node节点上的端口与pod进行映射。直接访问nodeip:nodeport就可以访问到pod提供的服务。
loadbalance:指定外部负载均衡器的地址,需要同时配置nodePort和clusterIP。
IPAM:IP地址管理;这个IP地址管理并不是容器所特有的,传统的网络比如说DHCP其实也是一种IPAM,到了容器时代我们谈IPAM,主流的两种方法: 基于CIDR的IP地址段分配地或者精确为每一个容器分配IP。但总之一旦形成一个容器主机集群之后,上面的容器都要给它分配一个全局唯一的IP地址,这就涉及到IPAM的话题。
Overlay:在现有二层或三层网络之上再构建起来一个独立的网络,这个网络通常会有自己独立的IP地址空间、交换或者路由的实现。
IPSesc:一个点对点的一个加密通信协议,一般会用到Overlay网络的数据通道里。
vxLAN:由VMware、Cisco、RedHat等联合提出的这么一个解决方案,这个解决方案最主要是解决VLAN支持虚拟网络数量(4096)过少的问题。因为在公有云上每一个租户都有不同的VPC,4096明显不够用。就有了vxLAN,它可以支持1600万个虚拟网络,基本上公有云是够用的。
网桥Bridge: 连接两个对等网络之间的网络设备,但在今天的语境里指的是Linux Bridge,就是大名鼎鼎的Docker0这个网桥。
BGP: 主干网自治网络的路由协议,今天有了互联网,互联网由很多小的自治网络构成的,自治网络之间的三层路由是由BGP实现的。
SDN、Openflow: 软件定义网络里面的一个术语,比如说我们经常听到的流表、控制平面,或者转发平面都是Openflow里的术语。
隧道方案:在IAAS层网络中应用较多,但是不适合大规模集群,因为随着节点的增多,复杂度会增加,出现网络问题不易排查。代表有flannel。
路由方案:从2层或者3层实现容器隔离和跨主机通信的,代表有calico。
calico和flannel后续会在研究,请持续关注。