大纲
- 网络模型与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
转载：https://blog.csdn.net/fly910905/article/details/103794791