深入理解K8S网络原理上

675 阅读6分钟

K8s四层网络

抽象成四层网络

Node节点网络

底层基础设施支持节点主机之间网络的互通

Pod网络

能够相互做IP寻址、相互通讯

同一节点上的Pod网络

大多数场景下一个pod下面有1个容器 也有一些场景下一个pod下有多个容器
这些容器共享pod中的网络栈
  • eth0
是主机上的网卡 也是流量出入的设备 也支持k8s集群节点之间做网络寻址和互通的设备
  • docker0
是一个虚拟网桥 简单理解为是一个虚拟交换机
支持节点上面或节点之间进行IP寻址和互通的设备
  • veth0
是pod1上的虚拟网卡 支持pod内容器互通的设备
内部的容器可以通过localhost相互访问
  • pause
pause是一个特殊的容器 为pod建立veth0网络共享的接口
通过docker ps就可以看到这个容器
  • pod
pod的ip是docker0网桥分配的

不同节点上的Pod网络

pod1和pod2在同一个网桥dokcer0里 所以可以互联互通
节点内的pod网络在172.17.0.0/24这个地址空间内的
节点主机网络在10.100.0.0/24这个地址空间内的
也就是说 pod网络和节点网络不在同一个网络空间内

不同节点上的pod之间如何互通?

路由方案

对于目标段172.17.1.0/24这个网段的pod转发到10.100.0.3这个主机
对于目标段172.17.0.0/24这个网段的pod转发到10.100.0.2这个主机
当主机eth0接受到pod网络的包就会向内部的pod网桥转发
这样不同节点的pod网络就可以IP寻址和通讯
这种方案引入了底层的网络设备 但是额外的网络开销比较少
覆盖网络方案(Overlay)
如果是公有云网络 就不支持路由方案
所以就可以用覆盖网络方案
所谓的覆盖网络方案就是在现有的网络基础上建立一个虚拟网络
所支持的技术很多 比如Flannel/Weavenet
大多采用隧道封包的技术

pod网络的数据包在出节点之前先被封装成节点网络的数据包
经过底层网络到达目标节点
就会被解封出来再转发给内部的pod网络
这种方案对底层网络没有太多依赖
但封包解包对性能有影响

考虑到pod网络实现技术众多
k8s为了简化集成
引入了CNI技术

CNI是一个Pod网络集成标准 简化K8s和不同Pod网络实现技术的集成
kubelet通过CNI插件去操作pod网络 而不需要关注底层的具体实现

Service

一个service背后往往是由多个pod组成的集群
由此引入了服务发现以及负载均衡等问题

服务发现与负载均衡

如何发现并且定位pod ip?

account-app pod集合中pod ip可能会变化 重新发布或自己挂了 k8s重新调度部署 也会变化

要解决服务发现问题 需要了解下技术演进的过程

DNS

最早是通过DNS来解决这个问题
K8s也支持DNS组件
运行的时候 K8s会把Pod集群中的Pod信息(ip和端口)注册到DNS上去
client应用通过查询DNS就可以发现目标Pod 就可以发起调用
对client无侵入

劣势:
1、有些客户端每次都会查询DNS服务 造成不必要的开销
2、有些客户端会缓存DNS信息 默认超时时间比较长 当目标Pod ip发生了变化
就会存在缓存刷新不及时问题 就会导致访问pod失效
3、大多数负载均衡策略比较简单 有些还不支持负载均衡

所以K8s并没有采用这种方式做服务发现 但实际上K8s还是引入了DNS组件来实现通过域名访问服务的

Service Registry+Client方案

这种方案典型的代表: Eureka+Ribbon/Consul/Nacos
K8s 自带的分布式存储etcd 就可以用来实现Service Registry

1、k8s将pod集群中的pod信息自动注册到service registry
2、client应用可以通过servcie registry查询发现目标pod 然后可以发起调用

这种方案实现不复杂 client也可以实现灵活的负载均衡策略

但是对客户端应用有侵入性 所以k8s也没有直接采用这种方案

k8s service网络具体实现原理

Kube-ProxyKubelet、K8s Master 是K8s实现服务发现与注册到关键

"服务注册阶段"

1、服务Pod实例发布的时候 Kubelet会负责启动这些Pod实例
2、启动完之后 会把Pod实例列表注册到K8s Master上面去
3、在Servcie发布的时候 K8s会为Service分配ClusterIP 
相关信息也会记录在Master节点上面
并且ClusterIPPodIP有映射关系

"服务发现阶段"

Kube-Proxy会监听Master并且发现ServiceClusterIpPod实例列表
并且修改本地的Linux Iptables转发机制
在接受到目标IP为某个ClusterIp的时候进行负载均衡并且转发到对应Pod上面去

"服务实际调用阶段"

当有消费者Pod需要访问某个服务的时候 先调用dns获取服务名 就通过clusterip发起调用
会被本地的iptables机制所截获
然后通过负载均衡转发到pod实例上面

dns组建也监听master节点并发现服务名称与clusterip之间的映射关系

k8s服务发现与eureka+ribbon方案对比

都是客户端代理的机制
负载均衡都是在客户端实现的

ribbon是以libary库的形式嵌入在客户端应用中的 对客户端应用是有侵入性的
而k8s的kube-proxy是独立的组件
每个docker节点上都有一个kube-proxy 对客户应用是无侵入的
该做法类似于ServiceMesh中的SideCar

Ribbon转发是穿透的
K8s中的转发是通过iptables转发
kube-proxy只负责服务发现 修改iptables规则 请求是不穿透kube-proxy的
早期的k8s是穿kube-proxy的 考虑单点问题和性能损耗 新的版本不穿kube-proxy了


ribbon实现服务名到服务实例ip地址的映射 它只有一层映射
在k8s中是有两层映射的 
kube-proxy是clusterip到podip的映射
kube-dns实现服务名到clusterip的映射

通过clusterip统一屏蔽服务发现和负载均衡问题