[翻译] 一个kubernetes网络简明教程[Part 1]

一个kubernetes网络简明教程[Part 1]

翻译: icebug

全部我学到的关于kubernetes网络的事情

你可能已经在kubernetes集群当中跑了一堆服务而且正在享受其带来的好处. 或者至少, 你已经计划这么干了. 虽然已经有一大堆工具能够用来安装或者管理集群, 你任然想知道这一切究竟是怎么回事. 另外, 当出现故障时到哪里去寻找解决方案? 我知道, 由于我遇到过.

固然, Kubernetes刚开始使用时很是简单. 但仍是让我直面它吧--它就是一只引擎盖下面的怪兽. 这里有不少可剥离的组件, 若是你想在失败面前处乱不惊, 知道如何将它们完美地组在一块儿工做则是一项必备技能. 其中最复杂, 也是最有挑战的一部分就是网络了.

因此我开始着手去理解网络在kubernetes当中到底是如何工做的. 我读文档, 看演讲, 甚至翻阅了源代码, 以下是个人一些发现.

Kubernetes网络模型

在kubernetes的核心当中, Kubernetes网络有一个重要的基础设计哲学.

每个Pod都有一个独一无二的IP.

这个Pod IP被这个Pod当中的全部容器所共享, 而且它能够从其余全部的Pod当中路由过来. 你注意到了一些“pause”字样的容器运行在你的Kubernetes节点当中吗? 它们被称为“沙盒容器”, 它们的惟一做用就是保留和占据一个被Pod当中全部容器所共享的网络命名空间(netns). 就这样, 一个Pod IP并不会随着Pod当中的一个容器的起停而改变. 这种一个Pod一个IP的模型的一个巨大的好处就是跟宿主机永远也不会有IP或者端口冲突, 咱们甚至都不用管应用用的是什么端口.

有了上面的基础, Kubernetes目前惟一的需求就是这些Pod IP是可路由或者说能够被全部其余Pod访问的, 无论这些Pod运行在什么节点上.

节点内网络通讯

第一步先要确保同一个节点上的Pod能够相互通讯, 而后再把这个想法扩展到跨节点通讯以及互联网通讯等.

在每个Kubernetes节点上, 在这里假设是一台Linux机器, 会有一个root网络命名空间(root表示基命名空间, 区别于系统当中的超级用户root) -- root netns.

主要的网络接口eth0在root netns当中.

一样的, 每个Pod也都有它本身的netns, 有一个虚拟的以太网络接口对链接到root netns当中. 这只是一个基础的管道对, 一端链接到root netns当中, 另外一端链接到Pod netns当中.

Kubernetes节点 (root命名空间)

咱们把Pod这端的接口命名为eth0, 因此Pod并不知道底下的宿主机并认为本身已经设置了root netns, 另外一端链接root netns的接口的命名为vnetxxx的样式.

Kubernetes节点 (Pod网络命名空间)

你能够经过ifconfig命令或者ip a命令在你的节点上看到全部的接口.

这一切对于节点上的全部Pod都同样. 对于想要想要互相通讯Pod, 还须要用到Linux以太网网桥cbr0, Docker用了一个类似的网桥命名为docker0. 你能够经过brctl show看到全部的网桥.

Kubernetes Node (Linux network bridge)

假设一个网络包要从Pod 1到Pod 2.

1. 网络包从eth0离开Pod 1的netns并经过vnetxxx进入到root netns.
2. 网络包被传到网桥cbr0, 网桥经过发送“who has this IP?”的ARP请求来发现网络包须要转发到的目的地.
3. vethyyy回答到它有这个IP, 因此网桥知道应该把网络包转发到哪里.
4. 网络包到达vethyyy接口, 并经过管道对进入到Pod 2的netns.

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

以上就是一个节点当中的容器是如何进行网络通讯的内容. 很显然, 还有别的方式, 但这多是最简单的方式, 而且Docker也是采用的这种方式.

节点间的网络通讯

正如我前面提到的, Pod也须要在各个节点之间可以相互访问. Kubernetes并无论它是如何实现的. 咱们能用L2(跨节点ARP), L3(跨节点进行IP路由 -- 像云服务提供商的路由表), overlay 网络, 甚至用信鸽. 只要能网络流量能到达另外一个节点上指定的Pod, 这一切都没有关系. 每个节点都会被分配一个独一无二的CIDR块(一个IP地址范围)用于Pod IP, 因此每个Pod都有一个独一无二的不会和别的节点上的Pod相冲突的IP.

在大多数的状况下, 尤为是在云环境当中, 云计算提供厂商的路由表保证了网络包抵达正确的目的地. 一样的事情也可以经过在每一个节点上设置正确的路由来完成. 这里还有一堆其余的网络插件用于完成这件事情.

下面咱们有两个节点, 跟咱们前面看到的同样, 每个节点都含有不一样的网络命名空间, 网络接口和一个网桥.

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

假设一个网络包从pod1到pod4(在一个不一样的节点上)

1. 网络包从eth0离开Pod 1的netns, 并从vethxxx进入root netns.
2. 网络包被传到cbr0网桥, 经过ARP请求来寻找网络包目的地.
3. 网络包从cbr0传到主网络接口eth0, 由于在这个节点上没有人有Pod 4的IP地址.
4. 网络包开始离开node 1, 走上了一条出发端是Pod 1, 目的端是Pod 4的线上.
5. 路由表上已经设置好了各个节点上CIDR的路由, 而且将网络包路由到CIDR块含有Pod 4 IP的节点.

6. 因此网络包到达了node 2的主网络接口eth0, 虽然Pod 4不是eth0的IP, 网络包仍然被转发到cbr0, 由于节点被配置为能够进行IP转发, 节点的路由表会寻找任何匹配Pod 4 IP的路由. 而后找到cbr0做为这个节点CIDR块的目的地. 你能够经过route -n命令查看节点的路由表, 而后会发现一条关于cbr0的路由以下:

7. cbr0网桥获取到网络包, 发出一个ARP请求, 而后发现IP属于vethyyy.

8. 网络包经过管道对抵达Pod4.

这是一篇关于Kubernetes网络基础的文章, 因此假以下次Kubernetes网络出现问题了, 别忘了检查那些网桥和路由表. 😉

这就是这篇文章的所有了, 在下一篇文章, 咱们来看看“overlay网络是如何工做的[Part 2]”, 当pod不断地建立和删除时网络发生了什么变化, 以及流入和流出的网络流量是如何流动的.

Reference

原文: https://medium.com/@ApsOps/an-illustrated-guide-to-kubernetes-networking-part-1-d1ede3322727

译者感悟

一直想翻译一些好的英文文档和文章, 奈何惰性太强, 一直仍是停留在想法阶段. 下午好友问我要不要加入Kubernetes翻译组, 这不就是本身一直想作的事情嘛, 说干就干, 而后才知道报名筛选规则至少要提交一篇本身翻译过的文章, 而后下班后找来一篇以前学习Kubernetes网络时看过的一篇文章, 零零散散花了差很少三个小时翻译了这篇文章. 第一次翻译, 可能有翻译的不太准确或者恰当的地方, 欢迎拍砖指正. 且无论能不能加入到Kubernetes翻译组, 今天算是开了个好头了.