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地点之间成立一个包围收集，同过包围收集，将数据包原封不动的转达到方针容器内。

（编辑：湖南网）

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