美文网首页
k8s 网络选型探索(备战1)

k8s 网络选型探索(备战1)

作者: jaymz明 | 来源:发表于2020-05-14 17:16 被阅读0次

    提供底层的基础措施来部署一个集群

    可选方案

    1. minikube
    2. GCE、ACE(托管)
    3. ALK/ELK/GCP

    选择一个网络方案

    network_compare_mode.png

    Flannel

    Flannel是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
    在默认的Docker配置中,每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是,不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到,也就是相互ping通。
    Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则,从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址,并让属于不同节点上的容器能够直接通过内网IP通信。
    Flannel实质上是一种“覆盖网络(overlaynetwork)”,也就是将TCP数据包装在另一种网络包里面进行路由转发和通信,目前已经支持udp、vxlan、host-gw、aws-vpc、gce和alloc路由等数据转发方式,默认的节点间数据通信方式是UDP转发。

    特点

    1. 使集群中的不同Node主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
    2. 建立一个覆盖网络(overlay network),通过这个覆盖网络,将数据包原封不动的传递到目标容器。覆盖网络是建立在另一个网络之上并由其基础设施支持的虚拟网络。覆盖网络通过将一个分组封装在另一个分组内来将网络服务与底层基础设施分离。在将封装的数据包转发到端点后,将其解封装。
    3. 创建一个新的虚拟网卡flannel0接收docker网桥的数据,通过维护路由表,对接收到的数据进行封包和转发(vxlan)。
    4. etcd保证了所有node上flanned所看到的配置是一致的。同时每个node上的flanned监听etcd上的数据变化,实时感知集群中node的变化。

    解决办法:

    ​ Flannel在每个主机上都运行flanneld作为agent,会从所在主机里获取一个小的网段,然后容器从这个网段里分配。


    flannel-config.png

    flanneld将本主机获取的subnet以及用于主机间通信的Public IP通过etcd存储起来,需要时发送给相应模块。

    flannel利用各种后端组件,例如udp,vxlan等等,跨主机转发容器间的网络流量,完成容器间的跨主机通信。

    flannel-artitect.png

    Calico

    Calico 是一种容器之间互通的网络方案。在虚拟化平台中,比如 OpenStack、Docker 等都需要实现 workloads 之间互连,但同时也需要对容器做隔离控制,就像在 Internet 中的服务仅开放80端口、公有云的多租户一样,提供隔离和管控机制。而在多数的虚拟化平台实现中,通常都使用二层隔离技术来实现容器的网络,这些二层的技术有一些弊端,比如需要依赖 VLAN、bridge 和隧道等技术,其中 bridge 带来了复杂性,vlan 隔离和 tunnel 隧道则消耗更多的资源并对物理环境有要求,随着网络规模的增大,整体会变得越加复杂。我们尝试把 Host 当作 Internet 中的路由器,同样使用 BGP 同步路由,并使用 iptables 来做安全访问策略,最终设计出了 Calico 方案。

    适用场景:k8s环境中的pod之间需要隔离

    设计思想:Calico 不使用隧道或 NAT 来实现转发,而是巧妙的把所有二三层流量转换成三层流量,并通过 host 上路由配置完成跨 Host 转发。

    设计优势

    1.更优的资源利用

    二层网络通讯需要依赖广播消息机制,广播消息的开销与 host 的数量呈指数级增长,Calico 使用的三层路由方法,则完全抑制了二层广播,减少了资源开销。

    另外,二层网络使用 VLAN 隔离技术,天生有 4096 个规格限制,即便可以使用 vxlan 解决,但 vxlan 又带来了隧道开销的新问题。而 Calico 不使用 vlan 或 vxlan 技术,使资源利用率更高。

    2.可扩展性

    Calico 使用与 Internet 类似的方案,Internet 的网络比任何数据中心都大,Calico 同样天然具有可扩展性。

    3.简单而更容易 debug

    因为没有隧道,意味着 workloads 之间路径更短更简单,配置更少,在 host 上更容易进行 debug 调试。

    4.更少的依赖

    Calico 仅依赖三层路由可达。

    5.可适配性

    Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。

    calico-artitect.png

    Felix:运行在每一台 Host 的 agent 进程,主要负责网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报等。

    BGP Client(BIRD):Calico 为每一台 Host 部署一个 BGP Client,使用 BIRD 实现,BIRD 是一个单独的持续发展的项目,实现了众多动态路由协议比如 BGP、OSPF、RIP 等。在 Calico 的角色是监听 Host 上由 Felix 注入的路由信息,然后通过 BGP 协议广播告诉剩余 Host 节点,从而实现网络互通。

    BGP Route Reflector:在大型网络规模中,如果仅仅使用 BGP client 形成 mesh 全网互联的方案就会导致规模限制,因为所有节点之间俩俩互联,需要 N^2 个连接,为了解决这个规模问题,可以采用 BGP 的 Router Reflector 的方法,使所有 BGP Client 仅与特定 RR 节点互联并做路由同步,从而大大减少连接数。

    选择你的基础设施配置

    机器配置

    | 组件                   |机器配置                                    |  备注
    |   ETCD                |     建议4核CPU,  4G内存及以上配置,  3台       |        可以和k8s master组件共用机器混合部署,如果机器资源充足,建议分开部署          |
    |   K8S Master          |    建议4核CPU,  4G内存及以上配置, 3台         |       同上建议            |
    |   LoadBalance         |    建议4核CPU,  4G内存及以上配置, 2台         |                  主备, 注意这个不要和master,node组件混合部署, 影响稳定性和可用性 |
    |  Node         |     4核CPU,  4G内存, 1台以上         |       配置需求与运行的容器数量和应用类型相关            |
    

    相关文章

      网友评论

          本文标题:k8s 网络选型探索(备战1)

          本文链接:https://www.haomeiwen.com/subject/yrezghtx.html