大纲

• 网络模型与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