容器网络硬核技术内幕 (8) 五湖四海的友谊

上一期我们讲到，Kubernetes作为容器编排平台的事实标准，重新定义了容器网络的元素和接口标准，形成了以下共识：

1. Kubernetes的容器资源分配单位是pod，一个pod中可以有多个容器，但对pod之外呈现为一个整体(一个IP地址)；

2. Kubernetes的容器运行载体是node，一个node可以运行多个Pod。node有自己的操作系统(一般为Linux)。

我们用图来表示：

这个图似曾相识——

没错，是你是你就是你——

在《局域网SDN技术硬核内幕 5 虚拟化网络的实现》中，我们给出的这张经典组网图里，可以看出，在每台宿主机上运行了一个vSwitch (在KVM中默认是OVS，在vsphere中默认是VDS)，vSwitch连接了宿主机上所有的虚拟机。

我们可以类比虚拟化场景，将Node类比为宿主机，Pod类比为VM：

在Kubernetes中，还有另一个重要的概念——Service。

Service对外提供的是一个名称，通过这个名称，可以访问一组pod对内部或对外部提供的服务。

假设P站的某应用，通过容器化部署，那么其架构如下图：

图中，Pornhub-Web，Pornhub-APP和Pornhub-db是三个Service，只有Pornhub-web对外提供服务，另外两个service对内提供服务，类似于虚机实现的web-app-db三层架构。

当然，实际部署中，app很可能拆成多个微服务，这个问题我们后续再谈。

Service有三种类型：

Nodeport，Loadbalancer和Ingress。

其中，Nodeport访问非常麻烦，一般不使用，

LoadBalancer本质上是基于NAT的负载均衡，可以通过软件或硬件实现。

Ingress是基于HTTP反向代理的负载均衡，也可以通过软件或硬件实现。

但无论怎么样实现Service，都需要面临一个问题：同一组Pod之间如何跨宿主机互联互通呢？

我们联想到在《容器网络硬核技术内幕 (3) 批判的武器和武器的批判》中学习的，在docker中，不同宿主机上的容器可以通过VXLAN互通。

在K8S中可以吗？

让我们做个实验。

以下图为例：

两个node的IP分别为192.168.65.112和192.168.65.116,

分别运行命令：

# ovs-vsctl add-port br1 vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.65.116

# ovs-vsctl add-port br1 vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.65.112

就可以实现两个node通过VXLAN互通：

问题来了，对于100台主机构成的kubernetes集群，配置VXLAN互通的工作量将达到100*99=9900的天量！

如果考虑到VLAN划分，这个量级还要再乘以一个100-1000的数量。

当然，使用Ansible等自动化工具可以实现部分的自动化，但对于IT基础架构与运维人员而言，需要的一定是图形化，自动化的配置方式。

因此，Kubernetes提供了CNI(Container Network Interface)接口，来自五湖四海的开发者们，可以通过CNI接口实现自动化的网络编排，也就是CNI插件。五湖四海的爱好容器技术和世界和平的人们，也因此结成了深厚的友谊。

目前，主流的CNI插件有Flannel、Calico、Weave、H3C SNA、OpenShift SDN等。

在后面的专题中，我们也将分析各个插件的实现和利弊。

请看下期。