|
|
51CTO旗下网站
|
|
移步端
创造专栏

付出条件下的 Kubernetes 容器网络演进的路

采用 Docker+Kubernetes 来简化开发人员的上班流,使应用更加便捷地迭代,缩短发布周期,在许多研发团队中已经是周边的作法。

笔者:马蜂窝技术| 2019-12-20 10:45

采用 Docker+Kubernetes 来简化开发人员的上班流,使应用更加便捷地迭代,缩短发布周期,在许多研发团队中已经是周边的作法。

如果说 Docker 提供的是运用级的主机抽象,这就是说 Kubernetes 的企图就是运用级的集群抽象,提供容器集群运行所需的基础设施,意志解决容器化应用的风源配置、布局运行、劳务意识、扩容缩容等问题。

一直以来,容器网络设计都把认为是异样关键,但相对复杂的一部分。 本文要介绍的 Kubernetes 网络,脚下第一为马蜂窝旅游网大多数 Java 工作提供开发条件的底色基础设施。随着团队的调节及工作需求升级,任何系统对网络架构的要求也越来越严峻。基于这样的全景,Kubernetes 网络过去一年多经历了两次比较重要的改造,以期不断下滑运维调试成本,增长研发效率。

借由本文分享我们的实行经验,与当今共勉。

Part.1.K8S 网络原理及挑战

1. Kubernetes Pod 计划

Pod 是 Kubernetes 的中心调度单元,咱们可以将 Pod 认为是容器的一种延伸扩展,一度 Pod 也是一番隔离体,而 Pod 其间又包含一组共享的容器。

每个 Pod 中的容器由一度奇异的 Pause 容器,及一个或多个致密相关的工作容器组成。Pause 容器是 Pod 的脚容器,对应的镜像属于 Kubernetes 平台的组成部分,以他的状态代表全部容器组的状态。同一个 Pod 阴之容器之间仅需通过 localhost 就能互相通信。

每个 Pod 会把 Kubernetes 网络组件分配一个唯一的(在集群内的 IP 地点,称为 Pod IP,这样就同意不同 Pod 中的服务可以运用同一端口(同一个 Pod 官方端口只能被一个劳动占用),避免了发生端口冲突的题材。

2. 迎战

Pod 的 IP 是在 Kubernetes 集群内的,是虚拟且局域的。这就带来一个问题,Pod IP 在集群内部访问没有问题,但在现实项目支出中,难免会有真正网络环境下的使用需要访问 Kubernetes 集群里之容器,这就要求我们做一些额外的上班。

本文将结合我们开发条件下基于 K8S 容器网络演进的经过,介绍在 Pod IP 为虚拟或真实 IP 情况下的几种直接访问 Pod IP 的解决方案。

Part.2.基于K8S的容器网络演进

着重阶段:K8S + Flannel

最早,咱们的网络设计方案只服务于大交通工作。最初大交通的 Java 使用是安排在物理机上的,团组织内部容器相关的底色基础设施几乎为 0。为了更加稳定地贯彻容器化的出生,中间我们没有直接把劳动全部迁移到 K8S 官方扮,而是经历了一段混跑。

其一过程中必然会有物理机上的 Java 使用访问 K8S 阴 Java 容器的状况(一度注册中心)。那时我们选用的网络架构是 Flannel VXLAN + Kube-proxy,重点是考虑到 Flannel 的简短性。

Flannel 是为 K8S 计划的一个奇异简洁之多节点三层网络方案,重点用于解决容器的跨主机通信问题,是一番比较大一统的提案。他的计划目的是为集群中的所有节点重新规划 IP 地点的采取规则,故而有效不同节点上的容器能够获得「同属一个内网」且「不重复的」IP地点,并让属于不同节点上的容器能够直接穿过内网IP打电话。

Flannel 的规律是为每个 host 分配一个 subnet,容器从此 subnet 官方分配 IP,该署 IP 可以在 host 间路由,容器间无需 NAT 和 port mapping 就足以跨主机通信。每个 subnet 都是副一个更大的 IP 池中划分的,Flannel 会在每个 host 地方运行一个守护进程 flanneld,他任务就是从大池子中分配 subnet,为了各个主机间共享信息。Flannel 用 ETCD 存放网络配置、已分配的 subnet、host 的 IP 等信息。

Flannel 的兴奋点间有三种通信方式:

  • VXLAN:默认配置,采取内核级别的 VXLAN 来封装 host 之间传送的包
  • Host-gw:二层网络配置,不支持云环境,穿过在 host 的路由表中直接创建到其它主机 subnet 的路由条目
  • UDP:普通用于 debug
  • 咱们在一切的工作物理机上都部署了 Flannel,并且启动 Flanneld 劳务,使之加入 K8S 编造网络,这样物理机上的劳务与 K8S 阴之容器服务在互相调用时,就足以通过 Flannel+Kube-proxy 的虚拟网络。完全结构图如下:

  • 年产量 1 是安排在物理机和 K8S 容器里之使用注册服务的轨道
  • 年产量 2 是两个物理机节点互相调用时的轨道
  • 年产量 3 是大体机节点调用 K8S 容器应用时的轨道,反之 app3 租用 app1 时就会直接访问 app1 八方的物理机 IP
  • 其次阶段:K8S + Flannel+ VPN-server

    为了加快大交通工作微服务和容器化的出生,咱们在集体内部形成了开发条件容器化的改造,并将全部流量全部迁移到 K8S 编辑系统上。

    大交通整体的微服务改造基于 Dubbo。刺探的爱人都晓得,Dubbo 劳务中 Consumer 和 Provider 的报道很常见,对应到我们的面貌就有了当地 Dubbo 劳务 (Consumer) 消费支出条件微服务 (Provider) ,以及地方远程 debug 付出条件的状况。但是 Dubbo consumer 副注册中心拿到的都是容器的虚拟网络 IP,在集群外的真正网络环境里第一访问不通。

    为了消灭这个题目,增长开发与联调效率,咱们开始了举足轻重次 K8S 容器网络方案之改造。

    咱们设想,既然一个商店的职工可以通过拨通 VPN,副公网进入到合作社的内网,那如果在 K8S 集群内部署一个 OpenVPN 的 Server,只是也得以下集群外进入到集群的内网之中?贯彻思路如下图所示:

  • 咱们在集群的 middleware 蓝天下以 nodeport 的措施部署了 VPN Server,并送客户端分配了 10.140 的网段
  • 顶客户端通过 172.18.12.21:30030 拨通 VPN时,客户端与 VPN Server 间的网络被打通
  • 因为 VPN Server 自己处于集群虚拟网络环境中,故此其他容器的 IP 对于 vpn server 是可见的,故此拨通 VPN 此后,VPN 客户端就足以直接对集群内的 Pod 拓展走访
  • 改建后开发条件与机房 K8S 集群之间的网络架构图如下所示:

    穿过在 K8S 集群里架设 OpenVPN,咱们暂时解决了办公室区对机房 K8S 集群的 RPC 报道问题。该方案之得失如下:

    优点:

  • 很快实现
  • 配图量小
  • 网络隔离,证明验证更安全
  • 不足:

  • 借鉴略繁琐,如使用时要求申请证书,安装客户端软件;每次使用前需要先打开 OpenVPN
  • 是一种中间方案,没有下本质上解决问题
  • 先后三阶段:基于 MAC-VLAN 的 K8S CNI

    为了更好地支持 Java 工作的微服务改造,避免重蹈覆辙造轮子,咱们构建了联合的 Java 基础平台,先前的网络方案也面向更多的单位提供服务。

    随着服务的工作和人口越来越多,由人工操作带来的窘迫和题材越来越显著,咱们决定对 K8S 网络进行再一次改造。副先前的阅历中我们深感,如果 K8S 的虚拟网络不去除,容器服务的 IP 是不可能直接由集群外的真正网络到达之。

    为了迅速满足不同业务场景下对于 K8S 网络功能的急需,咱们开始深入研究 CNI。

    关于 CNI

    CNI (Conteinre Network Interface) 意志为容器平台提供统一的网络标准,由 Google 和 CoreOS 基本制定。他自己并不是一番完整的解决方案或者程序代码,而是综合考虑了灵活性、扩展性、IP 分配、多网卡等因素后,在 RKT 的基础上发展起来的一种容器网络接口协议。

    CNI 的网络分类和主流的贯彻工具主要包括:

    着重类:与宿主机平行网络(2 层网络或 3 层网络),网络软件主要包括 Bridge、MAC-VLAN 、IP-VLAN、Calico BGP、Flannel host-GW 等

    其次类:采取SDN 艺术之虚拟网络,网络软件主要有:Flannel vxlan、Calico ipip、Weave 等

    MAC-VLAN 及其带来的题材

    穿过对比测试,考虑到当下需求,咱们最终决定基于网络改造、运维成本和复杂度都较低的 MAC-VLAN 提案:

    MAC-VLAN 具有 Linux Kernal 的性状,用于给一个物理网络接口(parent)安排虚拟化接口。虚拟化接口与 parent 网络接口拥有不同之 mac 地点,但 parent 接口上接受发给他对应的虚拟化接口的 mac 包时,会分发给对应的虚拟化接口,有点像将虚拟化接口和 parent 接口进行了「桥接」,使虚拟化网络接口在安排了 IP 和路由后就能互相访问。

    在 MAC-VLAN 气象下,K8S 容器访问可能会遇到一些问题,比如配置 MAC-VLAN 此后,容器不能访问 parent 接口的 IP。

    穿过调研,意识有以下两种解决方案:

    1. 编造网卡:开拓网卡混杂模式,穿过在宿主机上虚拟出一番虚拟网卡,名将虚拟网卡与宿主机真实网卡聚合绑定

    2. PTP 提案:类似 Bridge 的法制化版,但是网络配置更复杂,并且有部分配置在自测过程中发现并没有太大用处。与 Bridge 重点的不同是 PTP 不采取网桥,而是直接行使 vethpair+路由配置。

    穿过对比两种方案之可实施性,末了我们挑选了举足轻重种方案,但是第一种方案在虚拟机环境中经过补考发现偶尔会有宿主机与本机容器不通的场面,提议使用第一种方案之同窗尽量不要运用虚拟机环境(怀疑还是网卡混杂设置的题材)。

    「分区而治」的网络改造

    K8S 的骨干组件 KubeDNS 在起步时默认会访问 ClusterIP 段的程序一个 IP;如果继续采用原有的 Nginx-ingress,这就是说 Nginx-ingress 的容器在起步时也是采取 ClusterIP 扮演连接 KubeDNS 。而采取 MAC-VLAN 送 KubeDNS 和 Nginx-ingress 分配的都是实际网络 IP,她们是心有余而力不足联通 ClusterIP 的,故此 KubeDNS 和 Nginx-ingress 容器又未能采取 MAC-VLAN 提案,否则容器服务的书名访问能力将丧失。

    概括考虑之下,末了我们采用了「分区而治」的主意,名将不同类别的容器调度到不同之海域,采用不同之网络方案,大致的图解如下:

    利用 MAC-VLAN 提案时容器 IP 的分配方案有两种:DHCP 和 host-local。考虑到公司目前没有统一的 DHCP 和 IPAM 传感器为容器分配 IP,付出条件的机械数量不多,咱们就利用了人工参与每个节点的网络 IP 段分配。

    综上,本次改造后的网络架构图大致如下:

    功能

    可以看出与主要次网络改造的架构图对比:

  • 宿主机 1 和宿主机 2 上已经抛弃了 Kube-proxy 和 Flannel 该署虚拟网络的组件
  • 宿主机 1 和宿主机 2 该署业务容器节点直接行使了商家公共 DNS 装备
  • 办公室区本地 consumer 劳务在注册中心拿到 provider 的 IP 此后,可以直接连接消费,反之亦可
  • K8S 集群分为了虚拟网络区 (运作 K8S 集群管理组件) 和实际网络区 (运作业务容器)
  • 本次改造的劣势和不足总结为:

    优点:

  • 远程 debug
  • 办公室网与集群内服务间的 RPC,TCP 报道在二层网络中发掘
  • 网络延迟大大降低
  • 支持多机房容灾部署
  • 症结:

  • 配图量大
  • 要求耗费大量真实 IP 地点
  • 集群规模很大时,生活 ARP 广播风暴和交换机 MAC 表面超限风险
  • Part.3.不久前优化方向

    每一次挑战都是发展的内核。K8S 网络系统自上点以来,极大增强了 Java 工作容器化的运维效率,降低了运维成本,同时提供了更灵活、更安宁的劳务运行环境。

    在采取和改建 K8S 网络的经过中, 咱们也碰到了众多问题,比如服务的优雅上下线、容器 HPA 的设定规则、容器模版的异化支持等等,不久前我们将着重针对以下几地方近一地优化和改善:

    1. 生产条件逐步进行网络改造,并落实集群多机房部署,增长相灾能力

    2. 对第二次网络改造中的虚拟网络区中的 Nginx-ingress 二次开发,使他支持使用公司公共 DNS,并且废弃 SVC,彻底抛弃虚拟网络的采取

    【本文是51CTO专栏作者马蜂窝技术之原创文章,笔者微信公众号马蜂窝技术(ID:mfwtech)】

    戳这里,瞧该作者更多好文

    【编纂推荐】

    1. 瞧美国国防部如何增强网络空间安全
    2. 网络攻击成本仅一顿饭钱
    3. 为什么网络风险是高管必需关心的题材
    4. 网络安全市场急缺的六种非技术专业人才
    5. 剖析Docker容器安全管控方法
    【义务编辑: 武晓燕 TEL:(010)68476606】

    点赞 0
  • Kubernetes  容器  网络
  • 分享:
    大家都在看
    猜你喜欢
    1. <xmp id="7d5fd5a1">



        <form id="29c66510"></form>