开发环境下的 Kubernetes 容器网络演进之路

2019-12-23 628

马蜂窝技术原创文章，更多干货请搜索公众号：mfwtech

使用 Docker+Kubernetes 来简化开发人员的工作流，使应用更加快速地迭代，缩短发布周期，在很多研发团队中已经是常见的做法。

如果说 Docker 提供的是应用级的主机抽象，那么 Kubernetes 的作用就是应用级的集群抽象，提供容器集群运行所需的基础设施，旨在解决容器化应用的资源调度、部署运行、服务发现、扩容缩容等问题。

一直以来，容器网络设计都被认为是非常重要，但相对复杂的部分。本文要介绍的 Kubernetes 网络，目前主要为马蜂窝旅游网大多数 Java 业务提供开发环境的底层基础设施。随着团队的调整及业务需求升级，整个系统对网络架构的要求也越来越严苛。基于这样的背景，Kubernetes 网络过去一年多经历了两次比较重要的改造，以期不断降低运维调试成本，提高研发效率。

借由本文分享我们的实践经验，与君共勉。

Part.1 Kubernetes 网络原理及挑战

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 基于 Kubernetes 的容器网络演进

第一阶段：Kubernetes + 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

第二阶段：Kubernetes + 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 的 Kubernetes 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，彻底抛弃虚拟网络的使用

本文作者：张小伍，马蜂窝旅游网交酒平台研发工程师。

微信关注我们

原文链接：https://my.oschina.net/u/4084220/blog/3146103

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

你不知道Lambda的秘密和陷阱

二探lambda表达式一探Lambda：https://my.oschina.net/lt0314/blog/3144851 从例子二探lambda 传递Runnable创建Thread java8之前 package com.baigt.learn.nolambda; public class NoLambdaWithSecond { public static void main(String[] args) { new Thread(new Runnable() { @Override public void run() { // do some thing } }); } } 查看编译情况文件情况 D:\IdeaProjects\course\out\production\classes\com\baigt\learn\nolambda>ls NoLambdaWithSecond$1.class NoLambdaWithSecond.class java8 package com.baigt.learn; public class LambdaWithSecond {...

2019-12-22

538

MyExcel，是一个集导入、导出、加密Excel等多项功能的Java工具包。 MyExcel采用声明式语法来构建、读取Excel，屏蔽POI的具体操作细节（对POI无感知），以开发常用的技术替代，使得构建（从简单到高度复杂Excel）以及读取Excel变得极为便利。如导入： List<ArtCrowd> result = SaxExcelReader.of(ArtCrowd.class) .sheet(0) // 0代表第一个，如果为0，可省略该操作，也可sheet("名称")读取 .rowFilter(row -> row.getRowNum() > 0) // 如无需过滤，可省略该操作，0代表第一行 .beanFilter(ArtCrowd::isDance) // bean过滤 .read(path.toFile());// 另外，MyExcel一直在实际生产环境中使用，每天导出、读取Excel接近上亿数据，内存占用、抖动极低，足够应对绝大部分应用场景。导入：提供简便的API，读取Excel内容，并转化为List< Bean >...

2019-12-23

662

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。