容器化上云之容器网络分析

首先分析网络网络的连通性问题。

容器集群共享一个网络平面，根据组网方式的不同，容器网络与底层IaaS网络间的关系包括：

l   Overlay：容器网络是基于底层IaaS网络之上的虚拟网络，私有云默认采用这种模式；

l   Underlay：容器网络与底层IaaS网络打通，容器可以获得底层网络的IP地址。

从单个容器的角度看，容器集群内外主要包括如下几类地址：

l   容器IP：容器内网卡的IP，在Pod内由Pause容器提供，多个业务容器共享；

l   Service的IP，即ClusterIP：一个VIP（虚拟IP），只在kube-proxy的转发规则中存在；

l   节点IP：容器集群节点上的网卡IP，通常为VPC网络的地址；

l   外部IP：外部网络的IP，例如公网IP。

从容器内和节点访问这几类地址的连通性关系如下：

表1-1  

接下来分析容器间相互访问的问题。

由于容器的动态性，不能采用直连容器实例IP的方式访问，应该采用Kubernetes的Service对象，将动态的容器实例进行抽象，形成一个稳定的访问入口。通过Service进行访问时，Kubernetes自动提供基于随机策略的四层负载均衡能力。Service可以通过ClusterI和域名方式访问。

最后分析从集群外部访问容器的问题。

默认情况下，外部网络与容器网络不互通，同时外部网络与集群节点所在的VPC网络也不互通。当节点挂载了EIP之后，可以获得外部网络可访问的弹性IP地址。

将容器开放给外部客户端访问主要有两种方式：

l   NodePort：将容器端口映射到集群内所有节点的端口上，此时绑定了EIP的节点可以被外部客户端访问。

l   LoadBalancer：通过对接具有弹性IP的负载均衡服务对外暴露容器的访问入口。

其中NodePort方式有比较大的局限，建议只在非正式环境中使用，主要的限制包括：

l   端口范围：外部访问端口必须在30000-32767之前，且整个集群内不允许冲突。

l   单点故障：虽然NodePort在集群内所有节点都可访问，但当外部客户端只依赖单个EIP时，仍然存在单点故障，若绑定该EIP的节点宕机，则服务无法访问。