【Kubernetes系列】第9篇 网络原理解析(上篇)

  • 时间:
  • 浏览:0

他们都 把Pod端的网络接口叫 eth0,原本 Pod就不时需知道底层主机,它认为它拥有此人 的根网络设备。另一端命名成比如 vethxxx。让他用 ifconfig 可能 ip a 命令列出你的节点上的所有有有哪些接口。

Kubernetes Node(linux network bridge)

Kubernetes Node(root network namespace)

Kubernetes网络有另一一两个重要的基本设计原则:

假设另一一两个数据包要从pod1到达pod4(在不同的节点上)

每个Pod拥有唯一的IP

节点上的所有Pod都会完成你你這個 过程。有有哪些Pod要相互通信,就要用到linux的以太网桥 cbr0 了。Docker使用了类似的网桥,称为docker0。让他用 brctl show 命令列出所有网桥。

假设另一一两个网络数据包要由pod1到pod2

第一步是确保同一节点上的Pod时需相互通信,好多好多 时需扩展到跨节点通信、internet上的通信,等等。

类似的,每个Pod都会其自身的netns(network namespace),通过另一一两个虚拟的以太网对连接到root netns。这基本上好多好多 另一一两个管道对,一端在root netns内,另一端在Pod的netns内。

这好多好多 同一节点内容器间通信的流程。当然也时需用其它法子,好多好多 无疑这是最简单的法子,一齐也是Docker采用的法子。

正如我前面提到,Pod也时需跨节点可达。Kubernetes不关心怎样才能实现。他们都 时需使用L2(ARP跨节点),L3(IP路由跨节点,就像云提供商的路由表),Overlay网络,可能甚至信鸽。无所谓,但是我流量能到达原本 节点的期望Pod就好。每个节点都为Pod IPs分配了唯一的CIDR块(一段IP地址范围),好多好多 每个Pod都拥有唯一的IP,无需和其它节点上的Pod冲突。



Kubernetes Node(pod network namespace)



在每个Kubernetes节点(本场景指的是Linux机器)上,都会另一一两个根(root)命名空间(root是作为基准,而都会超级用户)-- root netns(root network namespace)。

Kubernetes Nodes with route table(cross node pod-to-pod communication)

这里他们都 有另一一两个节点,与但是看了的类似。每个节点有不同的网络命名空间、网络接口以及网桥。

Kubernetes Node(same node pod-to-pod communication)

这点满足后,Kubernetes唯一的要求是,有有哪些Pod IP可被其它所有Pod访问,不管有有哪些Pod在哪个节点。

主要的网络接口 eth0 好多好多 在你你這個 root netns下。

你你這個 Pod IP被该Pod内的所有容器共享,好多好多 其它所有Pod时需路由到该Pod。你可曾注意到,你的Kubernetes节点上运行着好多好多 "pause"容器?它们被称作“沙盒容器(sandbox containers)",其唯一任务是保留并持有另一一两个网络命名空间(netns),该命名空间被Pod内所有容器共享。通过你你這個 法子,即使另一一两个容器死掉,新的容器创建出来代替你你這個 容器,Pod IP好多好多 会改变。你你這個 IP-per-pod模型的巨大优势是,Pod和底层主机无需有IP可能端口冲突。他们都 无需担心应用使用了有哪些端口。

这好多好多 Kubernetes网络的基础。下次你碰到间题,务必先检查有有哪些网桥、iptables规则表和路由表。

大多数状况下,不怎样才能是在云环境上,云提供商的路由表就能确保数据包到达正确的目的地。他们都 在每个节点上建立正确的路由能够达到同样的目的。好多好多 其它的网络插件通过此人 的法子达到你你這個 目的。