Kubernetes研究：网络原理及方案（网络原理基础经典版）

与用户空间代理一样，最终结果是绑定到服务的IP:端口的任何流量被代理到适当的后端，而客户端不知道关于Kubernetes或服务或Pod的任何信息。这应该比用户空间代理更快，更可靠。然而，与用户空间代理不同，如果最初选择的Pod不响应，则iptables代理不能自动重试另一个Pod，因此它取决于具有工作准备就绪探测。

6、Kube-dns介绍

Kube-dns用来为kubernetes service分配子域名，在集群中可以通过名称访问service;通常kube-dns会为service赋予一个名为“service名称.namespace.svc.cluster.local”的A记录，用来解析service的clusterip。

Kube-dns组件：

• 在Kubernetes v1.4版本之前由“Kube2sky、Etcd、Skydns、Exechealthz”四个组件组成。
• 在Kubernetes v1.4版本及之后由“Kubedns、dnsmasq、exechealthz”三个组件组成。 

Kubedns

• 接入SkyDNS，为dnsmasq提供查询服务。
• 替换etcd容器，使用树形结构在内存中保存DNS记录。
• 通过K8S API监视Service资源变化并更新DNS记录。
• 服务10053端口。

Dnsmasq

• Dnsmasq是一款小巧的DNS配置工具。
• 在kube-dns插件中的作用是：

1. 通过kubedns容器获取DNS规则，在集群中提供DNS查询服务
2. 提供DNS缓存，提高查询性能
3. 降低kubedns容器的压力、提高稳定性

• Dockerfile在GitHub上Kubernetes组织的contrib仓库中，位于dnsmasq目录下。
• 在kube-dns插件的编排文件中可以看到，dnsmasq通过参数–server=127.0.0.1:10053指定upstream为kubedns。

Exechealthz

• 在kube-dns插件中提供健康检查功能。
• 源码同样在contrib仓库中，位于exec-healthz目录下。
• 新版中会对两个容器都进行健康检查，更加完善。

四、Kubernetes网络开源组件

1、技术术语：

IPAM：IP地址管理;这个IP地址管理并不是容器所特有的，传统的网络比如说DHCP其实也是一种IPAM，到了容器时代我们谈IPAM，主流的两种方法： 基于CIDR的IP地址段分配地或者精确为每一个容器分配IP。但总之一旦形成一个容器主机集群之后，上面的容器都要给它分配一个全局唯一的IP地址，这就涉及到IPAM的话题。

Overlay：在现有二层或三层网络之上再构建起来一个独立的网络，这个网络通常会有自己独立的IP地址空间、交换或者路由的实现。

IPSesc：一个点对点的一个加密通信协议，一般会用到Overlay网络的数据通道里。

vxLAN：由VMware、Cisco、RedHat等联合提出的这么一个解决方案，这个解决方案最主要是解决VLAN支持虚拟网络数量(4096)过少的问题。因为在公有云上每一个租户都有不同的VPC，4096明显不够用。就有了vxLAN，它可以支持1600万个虚拟网络，基本上公有云是够用的。

网桥Bridge： 连接两个对等网络之间的网络设备，但在今天的语境里指的是Linux Bridge，就是大名鼎鼎的Docker0这个网桥。

BGP： 主干网自治网络的路由协议，今天有了互联网，互联网由很多小的自治网络构成的，自治网络之间的三层路由是由BGP实现的。

SDN、Openflow： 软件定义网络里面的一个术语，比如说我们经常听到的流表、控制平面，或者转发平面都是Openflow里的术语。

2、容器网络方案：

隧道方案( Overlay Networking )

隧道方案在IaaS层的网络中应用也比较多，大家共识是随着节点规模的增长复杂度会提升，而且出了网络问题跟踪起来比较麻烦，大规模集群情况下这是需要考虑的一个点。

• Weave：UDP广播，本机建立新的BR，通过PCAP互通
• Open vSwitch(OVS)：基于VxLan和GRE协议，但是性能方面损失比较严重
• Flannel：UDP广播，VxLan
• Racher：IPsec

路由方案

路由方案一般是从3层或者2层实现隔离和跨主机容器互通的，出了问题也很容易排查。

Calico：基于BGP协议的路由方案，支持很细致的ACL控制，对混合云亲和度比较高。

Macvlan：从逻辑和Kernel层来看隔离性和性能最优的方案，基于二层隔离，所以需要二层路由器支持，大多数云服务商不支持，所以混合云上比较难以实现。

3、CNM & CNI阵营：

容器网络发展到现在，形成了两大阵营，就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。首先明确一点，CNM和CNI并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用Flannel也好、用Calico也好，他们并不关心，CNM和CNI关心的是网络管理的问题。

CNM(Docker LibnetworkContainer Network Model):

Docker Libnetwork的优势就是原生，而且和Docker容器生命周期结合紧密;缺点也可以理解为是原生，被Docker“绑架”。

• Docker Swarm overlay
• Macvlan & IP networkdrivers
• Calico
• Contiv
• Weave

CNI(Container NetworkInterface)：

CNI的优势是兼容其他容器技术(e.g. rkt)及上层编排系统(Kubernetes & Mesos)，而且社区活跃势头迅猛，Kubernetes加上CoreOS主推;缺点是非Docker原生。

• Kubernetes
• Weave
• Macvlan
• Calico
• Flannel
• Contiv
• Mesos CNI

4、Flannel容器网络：

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

• 它给每个node上的docker容器分配相互不想冲突的IP地址;
• 它能给这些IP地址之间建立一个覆盖网络，同过覆盖网络，将数据包原封不动的传递到目标容器内。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!