王华伟

（1．北京全路通信信号研究设计院集团有限公司，北京 100070；2．北京市高速铁路运行控制系统工程技术研究中心，北京 100070）

1 概述

铁路信息系统是以运输组织、客货营销、经营管理为信息化建设重点，以实现调度指挥智能化、客货营销社会化、经营管理现代化为目标的人机系统。

随着市场经济的持续高速发展、国家产业的结构不断优化调整，铁路信息系统已开始为越来越多的领域提供服务，如何以最小成本、最快速度满足铁路及周边领域日益增长的业务需求，是业内人不断研究的技术方向之一。

在传统的铁路信息系统的建设模式下，为满足系统的运行性能及运行高可用，往往使完成某项特定任务的应用程序组独占两台高可用集群的服务器，使系统在日常运行中，大部分服务器负载很低，造成硬件资源的严重浪费；另一方面，每个系统在建设时，都需要进行设备集成、操作系统安装、软件平台实施、业务系统软件部署、功能测试等多个步骤，导致建设周期较长。

为解决上述问题，多个建设单位引入了虚拟机云平台，将业务部署在云平台上的虚拟机，以达到提高硬件资源利用率、业务系统快速发布的目的。但虚拟机云平台依然较重，且对比物理服务器，在运行速度上有所损耗，原因如下。

1）为能对资源统一管理，云平台依然需要在物理服务器上部署独立的专用操作系统。然后在其上发布虚拟机，为虚拟机安装操作系统。云平台本身会占用不少的硬件资源。

2）一般单独的一台虚拟机仍然需占用几GB至几十GB的空间，依然会有资源浪费在虚拟机的操作系统上。

3）云平台为虚拟机增加了一层虚拟硬件层，导致应用程序运行时性能有所损失。

容器技术的出现很好地解决了上述问题。容器相比虚拟机，守护进程可以直接与主操作系统进行通信，为各个容器分配本来属于主操作系统的资源，保证了性能；另外由于没有臃肿的从操作系统，容器可以节省大量的磁盘空间以及其他系统资源。

同时，容器几乎可以在任意平台上运行，包括虚拟机、物理机、公有云、私有云、个人电脑、服务器等，可移植性非常好。

由于容器的优异性，出现了很多致力于优化容器使用的技术，K8S就是其中最有代表性的技术。K8S是一个容器集群管理系统，主要职责是容器编排，包括启动容器、自动化部署、扩展和管理容器应用、回收容器等。

本文重点研究基于K8S平台实现铁路信息系统工程化的网络。

2 K8S网络模型分析

在K8S中，最小的管理单元是Pod，一个主机可以运行多个Pod，一个Pod里面可以运行多个容器。

每个pod都拥有一个独立的IP地址，而且所有pod都在一个可以直接连通的、扁平的网络空间中。所以不管这些pod是否运行在同一个主机中，都可以直接通过对方的IP进行访问。

在K8S的管理下，Pod故障后可以自动重启恢复，但重启的位置有可能不在原来的主机上，且IP会发生变化。因此，K8S中衍生出Service。Service管理了一系列的Pods，每个Service有一个虚拟的IP，要访问Service管理的Pod上的服务只需要访问这个虚拟IP即可，这个虚拟IP固定不变。

综上所述，对K8S网络模型的分析可以从以下4方面分析。

2.1 Pod中容器的通信

如图1所示，在Pod中，会自动生成一个Pause容器，它有独立的网络命名空间（Network NameSpace），每在Pod中创建一个容器，该容器就会加入到Pause拥有的网络命名空间中。

图1 Pod中容器通信Fig.1 Container communication in Pod

新创建的容器不会创建自己的网卡，而是和Pause容器共享IP、端口范围，同一个Pod中的容器由于共享网络命名空间，之间可以通过localhost+端口的方式来互相访问。

2.2 相同主机中Pod的通信

每个Pod都会有自己的独立IP，Pod之间的通信就可以像物理主机一样通过IP进行。

相同主机中的Pod通过主机系统中的虚拟网桥设备进行通信。虚拟网桥设备可以通过由两个虚拟接口组成的veth将不同的网络命名空间链接起来，就像二层交换机一样。

如图2所示，每个Pod中的eth虚拟网卡与主机的veth设备组成veth对，就像一根网线一样接入docker0虚拟网桥设备，同一主机上的Pod通过docker0进行通信。他们的IP由docker0来分配，属于同一网段，可以通过二层进行交互。

图2 相同主机Pod通信Fig.2 Pod communication in same host

2.3 不同主机中Pod的通信

在主机中，Pod与docker0网桥属于同一网段，而docker0网段与主机网卡是不同网段。不同主机之间的通信通过主机网卡进行，因此，K8S会将所有正在运行的Pod的IP分配信息等记录在etcd（K8S采用分布式kv存储系统）中，保证各节点主机可以对各个Pod进行寻址。但如何保证在不使用NAT的情况下，不同主机上的Pod能互相跨网段通信仍是需要解决的问题。

针对这个问题，K8S有多种不同的技术实现方案，但总体框架较为相似。

如图3所示，proxy是代理模块，在不同的网络实现方案中有不同的形式，有可能是TUN虚拟网络设备，也有可能是数据处理模块。

K8S网络插件会根据不同的网段生成对应的路由信息，在Pod1与Pod4通信时，数据包走到docker0后，会根据路由信息将包发送至proxy代理模块，proxy代理模块根据源地址、目的地址的关系对数据进行封装或修改，发送到主机网卡进入物理网络。在目的主机收到数据包后，也会优先将数据包发送至proxy代理模块进行数据拆包或解析，根据路由信息送至docker0网桥。

2.4 Pod与Service的通信

在K8S中，Pod的IP不是持久不变的，当集群中Pod故障或主机故障重启后，Pod会进行重启，IP可能会发生变化。K8S通过Service来解决这个问题，Service可以为其关联的Pod提供负载均衡服务，且IP不变。

当数据包到达Service的虚拟IP后，数据包会通过Service的负载均衡器路由到与其关联的Pod中的容器。

如图4所示，K8S根据Service的IP段在iptables上生成流量规则，在数据包从docker0发往eth0时，iptables会根据规则将目的IP由Service的IP地址随机换成其Service下关联的Pod的IP地址。

图4 Pod向Service发送数据Fig.4 Pod sending data to Service

在数据包到达目的主机Pod，目的Pod进行回包时，将源IP设为自己，目的IP设为Pod1的IP发送至源主机，源主机会进行一个反向操作。

如图5所示，数据包进入源主机后，流经iptables时，将数据包的源IP重写为Service的IP，因此，在Pod1收到数据包时，依然认为自己在和srv1进行通信。

图5 Service向Pod回包Fig.5 Service sending data back to Pod

3 K8S网络工程化设计

通过第二节分析，可以看到，K8S的网络模型融合了网络命名空间、虚拟网络设备、三层路由、NAT转换、覆盖网络、负载均衡等多种技术，在这些技术保证下，可以构建一个健壮、灵活的信息化工程网络。接下来以构建一个具备工程级应用的K8S网络为目的进行设计，该网络具有如下特点：

1）集群管理节点高可用；

2）业务服务可实现节点故障自动恢复；

3）实现服务发现；

4）能够实现业务服务对外部网络提供接口。

3.1 整体设计

如图6所示，为满足K8S平台的高可用，保证平台管理系统的持续运行，整体采用3+N的设计，即由3台主机做管理Master节点，其余主机做Node工作节点，管理Master节点上也可以运行容器服务。

图6 K8S网络工程化整体设计Fig.6 Overall design of K8S network engineering

3台管理节点采用Haproxy实现四层负载均衡，满足多节点访问需求，同时采用Keepalived实现服务的高可用，保证K8S平台的不间断运行。

网络方面，采用Flannel CNI网络插件实现K8S的网络模型。Flannel支持host-gw网关模式与VxLan隧道模式，也支持两者混合的模式，同时能够满足同网段主机的高效率传输和跨网段主机的数据交换。

在实现上，规划网络平面如下：

1）物理主机网络平面：192.168.0.0/24；

2）Service网络平面：172.16.0.0/16；

3）Pod网络平面：172.17.0.0/16。

利用K8S中Service资源对象实现业务服务之间的互相访问及负载均衡。

利用K8S中的CoreDns组件，实现业务之间的服务发现，增强灵活性。

3.2 管理节点的高可用

在K8S中，管理节点至关重要，是进行容器编排、业务扩容、服务HA、网络访问的核心，在工程化应用上，必须对其实现高可用。

K8S本身已具有了etcd、controller manager、scheduler等核心组件的高可用机制，只需要实现api server的高可用机制即可，保证各节点不间断的调用管理节点的api。

五是走进重点行业，到群众关注的热门领域宣传。践行以人民为中心的发展思想，以坚决有力的态度和措施，对群众反响强烈、深恶痛绝的黑恶势力掀起了凌厉攻势。组织旅发委、文化委、卫计委、建交委等9个重点行业，深入3A级旅游景区——鹅岭公园、解放碑得意世界广场、重庆中医骨科医院等场所向景区游客、群众宣传扫黑除恶，倡议大家共同创建平安和谐的社会环境。进一步营造行业系统“人人参与扫黑除恶，人人共建平安渝中”的浓厚氛围。

如图7所示，在三台管理节点上首先部署Haproxy实现三节点的负载均衡，以应对大规模集群。Haproxy可以实现四层及七层的负载均衡，非常适合用在这里。其次，部署Keepalived实现高可用，在无法侦测到监听端口时实现VIP的漂移，保证服务的可持续性。

图7 管理节点的高可用Fig.7 High availability of management nodes

3.3 业务服务Pod故障的自动恢复

Pod故障的自动恢复策略从两点进行考虑。

1）重启策略

Always：当容器终止退出后，总是重启容器，这是默认策略。

OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。

Never：当容器终止退出，从不重启容器。

可以根据不同的应用类型选择不同的重启策略，Always适合需要持续运行的应用，这也是信息系统中绝大部分应用需要的，OnFailure适合短周期运行的任务，如数据库备份等。

2）健康检查

选择好存储策略后，可以针对Pod中运行服务进行健康检查，让Pod根据服务的状态决定是否处于running状态。如果K8S检查到Pod的状态非running，会根据重启策略对Pod执行操作。

健康检查支持3种检查方法。

httpGet：发送HTTP请求，返回200～400范围以内的状态码，超过400就是错误状态码。

exec：执行shell命令来判断状态码是0位成功。

tcpSocket：判断TCP的端口状态。

无端口监听的应用可选择使用exec进行检查，有端口监听的应用可选择使用tcpSocket进行检查。

3.4 服务发现

容器在K8S中进行重启、迁移等操作时，IP地址可能发生变化，通过Service资源代理后端的Pod，可以将IP固定下来。但IP地址难以记忆，且在生产环境中，可能需要对Service的IP重新进行配置。为了不对正常运行的业务造成影响，就需要通过服务发现功能让应用之间能互相定位。

K8S推荐采用Coredns来实现服务发现功能。将Coredns采用Service方式部署在管理节点上，Pod副本数设置为2。

3.5 对外部网络提供接口

K8S中的Pod网络平面和Service网络平面对于外部网络来说是未知的，无法访问，外部网络只能访问到主机网络平面。K8S可以通过将Service端口映射的方法给外部网络访问。

本设计将主机专网中的两台主机配置成高可用负载均衡服务器为各接口Service提供代理，将接口Servcie暴露给外部网络，如图8所示。

图8 对外部网络提供接口Fig.8 Interfaces to external networks

重点如下：

1）两台主机采用Keepalived实现高可用，使外部系统访问的IP保持不变；

2）两台主机采用haproxy提供负载均衡服务代理，将访问内部接口服务的流量进行转发；

3）Service采用NodePort类型，使运行后端关联Pod的主机都打开对应的服务映射端口；

4）外部系统访问负载均衡服务器的VIP及相关服务的代理端口即可访问内网接口服务。

4 结束语

由于K8S的可移动、可扩展、自修复的诸多特点，在越来越多的领域得到广泛的应用。本文结合铁路信息系统的特点，对K8S在系统中具体应用的网络设计做出了研究及阐述，对高可用、自修复、服务发现、与外部系统接口等技术难点提出解决方案，对工程应用具有指导价值。