kubernetes基础实践之网络

2019-10-07  本文已影响0人  jerry的技术与思维

前面的文章讲到k8s基本概念中的网络和存储部分是比较难的,今天我们来啃下网络这个硬骨头。

Kubernetes(k8s)是用来搭建服务集群的,而k8s只是搭建在有限的物理机或者虚拟机上面,服务器提供的IP是有限的,而k8s集群支持分布式服务、支持服务的弹性伸缩,这一切都利用了容器化技术,从以主机为中心的基础架构转移到以容器为中心的基础架构。

我们已经知道Pod 是 Kubernetes 的基本构建块,它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元,而pod是有生命周期的,它们可以被创建,也可以被销毁,然而一旦被销毁生命就永远结束。每个pod被创建的时候都有ip,但是这些ip是不稳定的,因为pod被销毁的时候ip就被释放了,就算是重建该pod,pod的ip也会发生改变。

正是k8s这样的特性,这里带来了两个问题:

  1. 如何管理IP,宿主node节点的ip是有限的,如何保证分配给pod的ip是唯一的并且和宿主node的ip不冲突?

  2. 如果一组 Pod(称为 backend)为其它 Pod (称为 frontend)提供服务,那么那些 frontend 该如何发现,并连接到这组 Pod 中的哪些 backend 呢?

kubernetes网络模型

在Kubernetes网络中存在两种IP(Pod IP和Service Cluster IP),Pod IP 地址是实际存在于某个网卡(可以是虚拟设备)上的,Service Cluster IP它是一个虚拟IP,是由kube-proxy使用Iptables规则重新定向到其本地端口,再均衡到后端Pod的。

  1. 网络基本原则

    每个Pod都拥有一个独立的IP地址(IP Per Pod),而且假定所有的pod都在一个可以直接连通的、扁平的网络空间中,即pod之间的ip可以直接相互通信,就好比在一个局域网中。

  2. 网络要求

所有的容器都可以在不用NAT的方式下同别的容器通讯;所有节点都可在不用NAT的方式下同所有容器通讯;容器的地址和别人看到的地址是同一个地址。

网络发展现状

容器网络发展到现在,形成了两大阵营,就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。需要注意的是,CNM和CNI并不是网络实现,他们是网络规范和网络体系,类似jdbc规范,j2ee规范其实就是一堆接口,你底层是用Flannel也好、用Calico也好都是可以的,CNM和CNI关心的是网络管理的问题,即能满足网络模型即可。

CNM(Docker LibnetworkContainer Network Model)我们这里就不介绍了,因为在很长的时间内docker就没有好好的规划网络这块,导致大规模使用docker提供服务编排存在很多难点,这也是k8s流行起来的原因。

CNI(Container NetworkInterface):CNI是兼容容器技术及上层编排系统,特别在k8s中发展势头迅猛,在k8s中以网络插件的方式存在,有很多非常好的实现。下面这些都是CNI的实现。

这些实现中Flannel和Calico是两个比较典型且优秀的。

Flannel容器网络

Flannel之所以可以搭建kubernets依赖的底层网络,是因为它可以实现以下两点:

  1. 它给每个node上的docker容器分配相互不想冲突的IP地址;

  2. 它能给这些IP地址之间建立一个覆盖网络,同过覆盖网络,将数据包原封不动的传递到目标容器内。

Flannel介绍

Flannel.jpeg

Calico容器网络:

Calico架构图

Calico.jpeg
上一篇 下一篇

猜你喜欢

热点阅读