一篇文章为你图解Kubernetes收集通讯道理

通过查察路由表，也能窥见一二：

root@node-1:/opt/bin# route -n 
Kernel IP routing table 
Destination Gateway Genmask Flags Metric Ref Use Iface 
0.0.0.0 172.23.100.1 0.0.0.0 UG 0 0 0 eth0 
10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel.1 #flannel 收集内跨节点的通讯会交给 flannel.1 处理赏罚 
10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0 #flannel 收集内节点内的通讯会走 docker0 

1 Pod内通讯

如下图所示：

这种环境下，统一个pod内共享收集定名空间，容器之间通过会见127.0.0.1:(端口)即可。图中的veth*即指veth对的一端(另一端未标注，但现实上是成对呈现)，该veth对是由Docker Daemon挂载在docker0网桥上，另一端添加到容器所属的收集定名空间，图上表现是容器中的eth0。

图中演示了bridge模式下的容器间通讯。docker1向docker2发送哀求，docker1，docker2均与docker0成立了veth对举办通信。

当哀求颠末docker0时，因为容器和docker0同属于一个子网，因此哀求颠末docker2与docker0的veth*对，转发到docker2，该进程并未跨节点，因此不颠末eth0。

2 Pod间通讯

同节点pod间通讯

因为Pod内共享收集定名空间(由pause容器建设)，以是本质上也是同节点容器间的通讯。同时，统一Node中Pod的默认路由都是docker0的地点，因为它们关联在统一个docker0网桥上，地点网段沟通，全部它们之间该当是能直接通讯的。来看看现实上这一进程怎样实现。如上图，Pod1中容器1和容器2共享收集定名空间，因此对pod外的哀求通过pod1和Docker0网桥的veth对(图中挂在eth0和ethx上)实现。

会见另一个pod内的容器，其哀求的地点是PodIP而非容器的ip，现实上也是统一个子网间通讯，直接颠末veth对转发即可。

跨节点通讯

CNI：容器收集接口

CNI 是一种尺度，它旨在为容器平台提供收集的尺度化。差异的容器平台(好比今朝的 kubernetes、mesos 和 rkt)可以或许通过沟通的接口挪用差异的收集组件。

今朝kubernetes支持的CNI组件种类许多，譬喻：bridge calico calico-ipam dhcp flannel host-local ipvlan loopback macvlan portmap ptp sample tuning vlan。在docker中，主流的跨主机通讯方案首要有一下几种：

1)基于地道的overlay收集：按地道范例来说，差异的公司可能组织有差异的实现方案。docker原生的overlay收集就是基于vxlan地道实现的。ovn则必要通过geneve可能stt地道来实现的。flannel最新版本也开始默认基于vxlan实现overlay收集。

2)基于包封装的overlay收集：基于UDP封装等数据包包装方法，在docker集群上实现跨主机收集。典范实现方案有weave、flannel的早期版本。

3)基于三层实现SDN收集：基于三层协媾和路由，直接在三层上实现跨主机收集，而且通过iptables实现收集的安详断绝。典范的方案为Project Calico。同时对不支持三层路由的情形，Project Calico还提供了基于IPIP封装的跨主机收集实现

通讯方法

集群内跨节点通讯涉及到差异的子网间通讯，仅靠docker0无法实现，这里必要借助CNI收集插件来实现。图中展示了行使flannel实现跨节点通讯的方法。

简朴说来，flannel的用户态历程flanneld会为每个node节点建设一个flannel.1的网桥，按照etcd或apiserver的全局同一的集群信息为每个node分派全局独一的网段，停止地点斗嘴。同时会为docker0和flannel.1建设veth对，docker0将报文丢给flannel.1,。

Flanneld维护了一份全局node的收集表，通过flannel.1吸取到哀求后，按照node表，将哀求二次封装为UDP包，扔给eth0，由eth0出口进入物理网路发送给目标node。

在另一端以相反的流程。Flanneld解包并发往docker0，进而发往目标Pod中的容器。

外部会见集群

从集群外会见集群有多种方法，好比loadbalancer，Ingress，nodeport，nodeport和loadbalancer是service的两个根基范例，是将service直接对外袒露的方法，ingress则是提供了七层负载平衡，其根基道理将外部流量转发到内部的service，再转发到后端endpoints，在平常的行使中，我们可以依据详细的营业需求选用差异的方法。这里首要先容nodeport和ingress方法。

Nodeport

通过将Service的范例配置为NodePort，就可以在Cluster中的主机上通过一个指定端口袒露处事。留意通过Cluster中每台主机上的该指定端口都可以会见到该处事，发送到该主机端口的哀求会被kubernetes路由到提供处事的Pod上。回收这种处事范例，可以在kubernetes cluster收集外通过主机IP：端口的方法会见随处事。

这里给出一个influxdb的例子，我们也可以针对这个模板去修改成其他的范例：

kind: Service 
apiVersion: v1 
metadata: 
 name: influxdb 
spec: 
 type: NodePort 
 ports: 
 - port: 8086 
 nodePort: 31112 
 selector: 
 name: influxdb 

Ingress

（编辑：湖南网）

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