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

 

点击上方“马蜂窝技术”，关注订阅更多优质内容

使用 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