大纲
- 网络模型与CNI
- Service
- Ingress
- DNS
- Network Policy
网络模型与CNI
一个Pod一个IP
- - 每个Pod独立IP, Pod内所有容器共享网络namespace(同一个IP)
- - 容器之间直接通信,不需要NAT
- - Node和容器直接通信,不需要NAT
- - 其他容器和容器自身看到的IP是一样的
集群内访问走Service,集群外访问走Ingress
CNI( container network interface)用于配置Pod网络 -不支持docker网络
Bridge网络
Overlay网络
CNI:Container Network Interface
容器网络的标准化
使用JSON来描述网络配置
两类接口:
- - 配置网络 -- 创建容器时调用
- AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)
- - 清理网络 -- 删除容器时调用
- DelNetwork(net NetworkConfig, rt RuntimeConf)
Service
Service类型
ClusterIP
- - 默认类型,自动分配集群内部可以访问的虚IP——Cluster IP。
NodePort
- - 为Service在Kubernetes集群的每个Node上分配一个端口,即NodePort, 集群内/外部可基于任何一个NodeIP:NodePort的形式来访问Service。
LoadBalancer
- - 需要跑在特定的cloud provider上
- - Service Controller自动创建一个外部LB并配置安全组
- - 对集群内访问, kube-proxy用iptables或ipvs实现了云服务提供商LB的部分功能: L4转发,安全组规则等
kubernetes服务发现
Service实现之iptables
Iptables是用户空间应用程序,通过配置Netfilter规则表( Xtables )来构建linux内核防火墙
DNAT 的全称为Destination Network Address Translation目的地址转换,常用于防火墙中。
iptables的规则表和链(忽略centos中的第5个表SECURITY,常用的只是filter, nat)
表(tables):提供特定的功能,iptables内置了4个表,即filter表、nat表、mangle表和raw表,分别用于实现包过滤,网络地址转换、包重构(修改)和数据跟踪处理。
链(chains):是数据包传播的路径,每一条链其实就是众多规则中的一个检查清单,每一条链中可以有一 条或数条规则。当一个数据包到达一个链时,iptables就会从链中第一条规则开始检查,看该数据包是否满足规则所定义的条件。如果满足,系统就会根据 该条规则所定义的方法处理该数据包;否则iptables将继续检查下一条规则,如果该数据包不符合链中任一条规则,iptables就会根据该链预先定义的默认策略来处理数据包。
规则链:
- 1)INPUT——进来的数据包应用此规则链中的策略
- 2)OUTPUT——外出的数据包应用此规则链中的策略
- 3)FORWARD——转发数据包时应用此规则链中的策略
- 4)PREROUTING——对数据包作路由选择前应用此链中的规则(记住!所有的数据包进来的时侯都先由这个链处理)
- 5)POSTROUTING——对数据包作路由选择后应用此链中的规则(所有的数据包出来的时侯都先由这个链处理)
链可以说是数据包流动的链条,只分两条路,转发出去和到本机的;链条里嵌着表,每个结点的表不一样,可以实现的规则功能和特定结点结合在一起;也可以从表考虑,nat表只影响PREROUTING,POSTROUTING,OUTPUT结点,在链条的前后;filter表只影响FORWARD,INPUT,OUTPUT结点,在链条的中间部分;
Service实现之ipvs
IPVS是LVS的负载均衡模块,亦基于netfilter,但比iptables性能更高。
ipvs长连接,默认时间15min,可以最大调整到31天
iptables和ipvs对比
如何从集群外访问kubernetes的service
使用NodePort类型的Service
- - 要求Node有对外可访问IP
使用LoadBalancer类型的Service
- - 要求在特定的云服务上跑K8S
Service只提供L4负载均衡功能,而没有L7功能
Ingress
Ingress是授权入站连接到达集群服务的规则集合
- - 支持通过URL方式将Service暴露到K8S集群外, Service之上的L7访问入口
- - 支持自定义Service的访问策略
- - 提供按域名访问的虚拟主机功能
- - 支持TLS
Ingress DIY
需要自己实现Ingress Controller
- - List/Watch K8S的Service, Endpoints, Ingress对象,刷新外部LB的规则和配置
- - 官方提供Nginx和GCE的Ingress Controller示例
想通过域名访问Ingress?
- - 需要自己配置域名和Ingress IP的映射: host文件,自己的DNS(不是Kube-dns)
DNS
kube-dns
- kubedns: List/Watch K8S Service和Endpoints变化。接入SkyDNS,在内存中维护DNS记录,是dnsmasq的上游。
- dnsmasq: DNS配置工具,监听53端口,为集群提供DNS查询服务。提供DNS缓存,降低kubedns压力。
- sidecar:健康检查,检查kube-dns和dnsmasq的健康
Network Policy
Network Policy是什么
基于源IP的访问控制列表
- - 限制Pod的进/出流量
- - 白名单
Pod网络隔离的一层抽象
- - label selector
- - namespace selector
- - port
- - CIDR
没有Network Policy意味着:“全网通”
网络插件实现Policy Controller
默认Network Policy
拒绝所有流量进入
限制部分流量进入
允许所有流量进入
限制流量从指定端口进入
支持Network Policy的网络插件
- Calico
- Cilium
- Weave Net
- Kube-router
- Romana
注意: flannel和kubenet不支持network policy