云计算网络技术内幕 (23) 向云原生进军 (上)

在前几期，我们从容器基本原理讲到了容器网络的开源社区实现、容器网络的大型公有云实现以及私有化容器平台实现。实际上，与大型公有云同构的私有化容器平台，如腾讯TCS等，被赋予了一个更重要的使命——企业云原生平台。

所谓的云原生指的是，应用从设计之初就考虑到在云上开发、部署、运行和迭代。云原生平台为企业提供的就是这样一个将应用开发、部署、运行和迭代的全生命周期搬到云上的平台，西方产品的代表为GAE(Google Application Engine)，红帽OpenShift，而国内产品的代表就是Tencent TCS。

云原生应用最基本的特征是：

1. 微服务化，将单体应用的各个模块解耦并拆解为微服务；
2. 容器化，将微服务运行在容器中，利用容器的弹性伸缩和快速迭代能力提升运维效率；
3. DevOps，开发运维一体化，提升开发人员迭代应用的效率；

显然，应用云原生化的一个重要特征就是，应用由多个组件分布式处理。

在分布式系统中，一个非常重要的要素就是负载均衡。我们知道，在传统基于虚拟化的网络中，负载均衡后端的RS (Real Server)是虚拟机或裸金属服务器(Bare Metal)。

如图，来自外网的请求由外网负载均衡(LB WAN)分发给各个VM，而云内也有内网负载均衡(LB LAN)负责内部请求的分发。我们如果把这个图中的VM换成容器，就是下图：

看起来是不是很简单？

但是，这个模型是错误的。

我们知道，由于Kubernetes网络是完全虚拟化出来的一个网络，且涉及到大量分布式的调用，因此，Pod服务的暴露需要遵守以下几条铁律：

1. 容器集群内部和外部的IP地址不可以直接路由，必须经过转换；
2. 不同业务的Pod和Pod之间访问不可以直接访问，必须通过地址转换机制；
3. 容器内部的Pod访问容器外部的IP地址也不可以直接访问，必须通过转换；
4. 即使是对容器集群内部发布的VIP，也不可以直接使用，需要通过一个类似域名解析(Service Name)的方式实现。

因此，Kubernetes实际上是建立了一个如上图所示的网络模型。

来自外部的访问目标是一个域名，这个域名通过Ingress抽象出来，代表Kubernetes集群对外暴露的一个应用。

Ingress后面有可能有一个或多个Service。Service是K8S对一组具有相同label的Pod构成的内部服务的抽象，也可以理解为所谓的“微服务”。每个Service最终将请求分发到Pod上。

在Kubernetes内部，将Kubernetes集群外部的服务也视为一种特殊的service，称为externalname，将外部的中间件、数据库等服务抽象为一个服务名称，对Kubernetes内部提供。

我们发现，在Kubernetes内部，其实需要两种不同的负载均衡器：

1. Service，将Service名称解析为IP地址，并且转发到具体的Pod上；

2. Ingress，将外部域名解析为VIP；

Service需要通过分布式的方式来实现，这是因为，Kubernetes内部有大量的Service，如果通过集中式的节点来实现则无法避免出现瓶颈；

而Ingress则需要通过(相对)集中式的方式来实现，这是因为，Ingress是一个七层负载均衡，如果完全分布式处理，无法保证用户http会话的同步；

因此，Kubernetes的开发者们针对二者也给出了不同的版本答案。

备注：本文封面是参照《小美人鱼》的审美观挑选的。