etcd

etcd是Coreos团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值(（key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd是go语言编写的

etcd作为服务发现系统,有以下的特点:

简单:安装配置简单，而且提供了HTTP API进行交互，使用也很简单
安全:支持ssL证书验证
快速:单实例支持每秒2k+读操作
可靠:采用raft算法，实现分布式系统数据的可用性和一致性

etcd目前默认使用2379端口提供HTTP API服务，2380端口和peer通信(这两个端口已经被IANA(互联网数字分配机构)官方预留给etcd) 即etcd默认使用2379端口对外为客户端提供通讯，使用端口2380来进行服务器间内部通讯。 etcd在生产环境中一般推荐集群方式部署。由于etcd的leader选举机制，要求至少为3台或以上的奇数台.

准备签发证书环境

CFSSL 是CloudFlare 公司开源的一款、PKI/TLS 工具。CFSSL包含一个命令行工具和一个用于签名、验证和捆绑TLs 证书的 HTTP API服务。使用GO语言编写。

CFSSL使用配置文件生成证书，因此自签之前，需要生成它识别的 json 格式的配置文件，CFSSL提供了方便的命令行生成配置文件。

CFSSL用来为etcd提供TLS 证书，它支持签三种类型的证书:

client 证书，服务端连接客户端时携带的证书，用于客户端验证服务端身份，如 kube-apiserver访问 etcd;
server证书，客户端连接服务端时携带的证书，用于服务端验证客户端身份，如 etcd对外提供服务;
peer 证书，相互之间连接时使用的证书，如etcd节点之间进行验证和通信。

CNI网络组件

k8s中 pod网络通讯

Pod内容器与容器之间的通信

在同一个Pod 内的容器

(Pod 内的容器是不会跨宿主机的）共享同一个网络命名空间，相当于它们在同一台机器上一样，可以用localhost地址访问彼此的端口。

同一个Node内Pod 之间的通信

每个Pod都有一个真实的全局IP地址，同一个 Node 内的不同Pod 之间可以直接采用对方pod 的 IP地址进行通信，Podl与 pod2 都是通过 Veth 连接到同一个docker0/cni0 网桥，网段相同，所以他们之间可以直接通讯

同Node 上 Pod之间的通信

Pod 地址与 docker0在同一网段，docker0网段与宿主机网卡是两个不同的网段，且不同Node之间的通信只能通过宿主机的物理网卡进行。要想实现不同 node 上 pod 之间的通信，就必须想办法通过主机的物理网卡IP地址进行寻址和通信。因比要满足两个条什: pod 的 IP 不能冲突:将 pod 的 IP 所在的 Node 的 IP 关联起来，通过这个关联让不同 node 上 pod 之间直接通过内网 IP 地址通讯

overlay Network:

叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链路隧道连接起来。通过Overlay技术(可以理解成隧道技术)，在原始报文外再包一层四层协议（UDP协议），通过主机网络进行路由转发。这种方式性能有一定损耗，主要体现在对原始报文的修及。目前Overlay主要采用VHLAN。

VHLAN

将源数据包封装到UDP中，并使用基础网络的IP/MAC作为外层报文头进行封装，然后在以网络上传输，到达目的地后由隧道端点解封装并将数据发送到目标地址。

Flannel

Flannel 的功能是让集群中的不同节点主机创建的 Docker容器都具有全集群唯一的虚拟IP地址。 Flannel是 Overlay 网络的一种，也是将TCP源数据包封装在另一种网络包里面进行路由转发和通信，目前支持 UDP、VLAN、Host-gw 3种数据传输方式。

Flannel UDP 模式的工作原理:

数据从主机A上 Pod 的源容器中发出后，经由所在主机的 docker0/cni0 网络接口转发到flannel0接口，flanmeld 服务监听在flannne10虚拟网卡的另外一端。 flannel 通过 ETCD 服务维护了一张节点间的路由表。源主机A的flameld服务将原本的数拱内容封装到UDP报文中，根器自己的路由表通过物理网卡投递给目的节点主机B的flameld服务，数据到达以后被解包，然后直接进入目的节点的 flannel0接口，之后被转发到目的主机的 doctero/cni0网桥，最后就像本机容器道信一样由 docker0/cni0 转发到目标容器。

ETCD 之Flannel提供说明:

存储管理Flannel可分配的IP地址段资源
监控ETCD中每个Pod 的实际地址，并在内存中建立维护Pod节点路由表

由于 UDP 模式是在用户态做转发，会多一次报文隧道封装，因此性能上会比内核态做转发的VXLAN模式差

VXLAN模式

VXLAN模式使用比较简单，flannel 会在各节点生成一个flannel.1的 VXLAM网卡（VTEP设备，负责VXLAN封装和解封装）

VXLAN模式下封包与解包的工作是由内核进行的。flannel不转发数据，仅动态设置ARP表和 MAC表项。

UDP模式的 flanne10网卡是三层转发，使用 flannel0 时在物理网络之上构建三层网络，属于 ip in upd : VXLAN模式是二层实现，overlay 是数据帧，属于 mac in udp。

Flannel VXLAN模式跨主机的工作原理:

数据帧从主机 A 上 Pod 的源容器中发出后，经由所在主机的 docker0/cni0网络接口转发到 flanne1.1 接口
flannel.l收到数据帧后添加VXLAN 头部，封装在 UDP报文中
主机A通过物理网卡发送封包到主机B的物理网卡中
主机B的物理网卡再通过 VXLAN默认端口4789转发到flannel.1接口进行解封装
解封装以后，内核将数据帧发送到 cni0，最后由 cni0 发送到桥接到此接口的容器B中。

Calico

k8s组网方案对比

flannel方案

需要在每个节点上把发向容器的数据包进行封装后，再用隧道将封装后的数据包发送到运行着日标pod的node节点上。目标node节点再负责去掉封装，将去除封装的数据包发送到目标Pod 上。数据通信性能则大受影响。

calico方案

Calico不使用隧道或NAT来实现转发，而是把Host当作nternet中的路由器，使用bgp同步路由，并使用iptables来做安全访问策略，完成跨Host转发。采用直接路由的方式，这种方式性能损耗最低，不需要修改报文数据，但是如果网络比较复杂场景下，路由表会很复杂，对运维同事提出了较高的要求。

calico 的模式:

IPIP模式:在原有IP 报文中封装一个新的 IP 报文，新的 IP 报文中将源地址IP和目的地址IP都修改为对端宿主机 ip。calico 默认使用IPIP的模式,
BGP模式:将节点做为虚拟路由器通过 BGP 路由协议来实现集群内容器之间的网络访问。
cross-subnet (ipip-bgp混合模式):IPIP模式和 BGP模式都有对应的局限性，对于一些主机跨子网而又无法使网络设备使用BGP的场景可以使用cross-subnet模式，实现同子网机器使用BGP模式，跨子网机器使用IPIP模式。

calico 主哥由以下几个部分组成:

Calico CNL插件:主要负责与kubernetes对接，供kubelet调用使用。
Felix:负责维护宿主机上的路由规则、FIB转发信息库等。
BIRD:负责分发路由规则，类似路由器。
Confd:配置管理组件。

calico 工作原理:

IPIP 模式:

Calico 会将容器的IP 包通过内核的TPIP 驱动直接在封装宿主机网络的IP 包中，并根据路由通过tunlO 网卡发送给其他节点，这样到达目标节点以后再通过 IPIP 驱动解包得到原始容器IP包，然后通过路由规则发送给veth pair设备到达日标容器。

BGP模式:

calico是通过路由表来维护每个pod 的通信。calico 的 CNI 插件会为每个容器设置一个veth pair 设备,然后把另一端接入到宿主机网络空间，由于没有网桥，CNI插件还需要在宿主机上为每个容器的veth pair 设备配置一条路由规则，用于接收传入的IP包。有了这样的 veth pair 设备以后，容器发出的IP 包就会通过veth pair 设备到达宿主机，然后宿主机根据路由规则的下一跳地址，发送给正确的网关，然后到达目标宿主机，再到达目标容器。这些路由规则都是 Felix 维护配置的，而路由信息则是calico BIRD组件基于 BGP 分发而来。caivo实际上是将集群里所有的节点都当做边界路由器来处理，他们一起组成了一个全互联的网络。彼此之间通过BGP交换路由，这些节点我们叫做BGP Peer 。

相比IPIP模式，BGP模式下不需要tunl0设备参与报文传输，报文直接通过物理网卡（比如ens33）转发到目标主机上，不会进行二次IP报文的封装，因此从性能上来看，BGP是占优势的，但是由于没有二次封装，BGP模式只能在同一个子网内使用，无法跨网段使用

目前比较常用的CNL网络组件是flannel和calico，flannel的功能比较简单，但不具备复杂的网络策略配置能力但calico以其性能、灵活性而闻名。calico的功能更为全面，不仅提供主机和pod之间的网络连接，还涉及网络安全和管理，但具备复杂网络配置能力的同时，往往意味着本身的配置比较复杂，所以相对而言，比较小而简单集群使用flannel，考虑到日后扩容，未来网络可能需要加入更多设备，配置更多网络策略，则使用calico更好。

总结

k8s的三种网络
节点网络  节点物理网卡IP 


flannel  是k8s的pod能够实现跨节点通讯的cni网络插件

flannel模式： UPD（默认模式）  VXLAN（推荐，性能比UPD更好）  host-gw（性能最好，但配置繁琐）
由于 UPD模式是在用户态做转发，会多一次报文隧道封装，因此性能上会比内核态做转发的 VXLAN 模式差

flannel的UPD模式工作原理

1、应用数据从源主机的pod发出到cni0网桥接口，再由cni0网桥接口转发到flannel0虚拟网卡接口
2、flanneld服务会监听flannel0接口的数据，flanneld服务会将内部数据包封装到UDP报文里
3、根据flannel在etcd维护的路由表通过物理网卡转发到目标主机（通过flannel在etcd维护的路由表查到目标pod所在的节点ip，在UDP报文外在封装节点ip报文，MAC报文后发送到目标节点）
4、通过8285号端口，UDP报文送达到目标主机的flanneld服务后会被解封装，然后会通过目标主机的flannel0接口转发到目标主机的cni0网桥，最后在被cni0转发到目标pod


flannel和 calico区别？
flannel：udp  vxlan host-gw， 
              通常使用vxlan模式，采用的是叠加网络，IP隧道方式传输数据，，可以实现跨子网传输，但传输过程中需要封包和解包的过程，对性能有一定的影响，
              同时也具有一些优点，功能简单，配置方便，利于管理，但不具备复杂的网络策略规则配置能力

calico: ipip bgp 混合
使用ipip模式可以实现夸子网传输，但传输过程中需要封包和解包，对性能有一点的影响
使用bgp模式可以直接根据bgp路由规则转发，且传输过程中不需要封包和解包因此性能较好，但只能在同一个子网内使用，无法跨网络使用
          具有更丰富的网络安全策略和配置管理能力，但是维护起来较为复杂

所以对于较小规模且网络要求简单的k8s集群，可以采用flannel；
对于集群规模较大且要求更多的网络策略配置时，可以采用功能更为全面地calico




coreDNS 是kubernetes 的默认 DNS 实现

根据 service 资源名称  解析出 cluster IP
根据 pod 资源名称 解析出 pod IP

云原生kubernetes---基础知识（2）