Kubernetes集群内外的网络连通性

Kubernetes集群中包含多种对象，如Node, Container, Pod, Service等，这里主要总结Kubernetes集群中的各种对象的网络连通性。大致可以分为Kubernetes集群内部的各对象之间的网络连通性，以及Kubernetes集群内部的对象对集群外部的网络可见性。

对于前者，又可以细分为Pod内部的多个容器实例之间的网络连通性、不同Pods之间的网络连通性、Pod与Service之间的网络连通性，以及Service与Service之间的连通性，我们将在本文中详细论述。

对于后者，只有Kubernetes集群中的Services对集群外部是可见的。具体地说，Kubernetes集群中，只有NodePort类型的服务和LoadBalancer类型的服务，是可以从集群外部进行访问的。我们在后续涉及NodePort服务和LoadBalancer服务的部分，也会详细介绍。

1. 容器实例之间的连通性

通常，一个Pod内部的容器实例只有一个，不存在容器实例之间的通信问题。这里的容器实例之间的连通性，主要是指一个Pod内有多个容器实例的情况。

根据Kubernetes集群的网络模型，一个Pod内部的多个容器实例之间，永远是连通的。可以将Pod视为Docker host，在同一Pod内的各个容器实例，其实是位于同一个网桥的私有子网内，因此各个容器实例之间彼此是网络连通的。所有容器实例共用Pod的IP及hostname，因而通过<pod_IP>:<container_port>或localhost:<container_port>即可互相访问。可以看到，在一个Pod内部的多个容器实例应该使用不同的端口，这在后续为Pod创建服务的时候也是必须的。

如果将Pod视为一台物理机器，一个容器实例就是Pod的一个进程，因此容器实例之间还可以直接通过进程内通信（如SystemV信令, POSIX共享内存等）。

2. Pods之间的连通性

Pod是其内部容器实例的宿主机，一个Pod能够与其内部任何容器实例互相通信。那么不同Pods之间的网络连通性如何呢？

一个Pod可以视为一个逻辑主机，是Kubernetes分配IP的最小粒度，即“IP-per-Pod”模型。因而，一个Pod拥有集群内部唯一的IP。

根据Kubernetes集群的网络模型，一个集群内的任意Pods之间，永远是连通的，而无论Pods实际位于哪个Node上。Pods之间通过Pod的IP即可互相访问。

一个Pod内的容器实例要访问另一个Pod内的容器实例，只需要访问目标Pod的<IP>:<Port>即可。注意，Pod的<Port>，默认与Pod内部的容器实例的<container_port>相同。

如果目标Pod内有多个容器实例，则需要将这些容器实例暴露到Pod的不同端口，需要将某个容器实例的端口映射到Pod的不同端口。一个Pod内的容器实例通过Pod的一个端口暴露，而Pod的端口port往往与容器实例的端口targetPort相同，所以一个Pod内的不同容器实例其内部端口应该与其他容器实例的内部端口不同。

3. Service与Pod之间的连通性

既然集群内的Pods之间已经连通了，为啥还需要集群内的Services呢？这是因为Pods是短暂已逝的，动态产生和消亡的，一个新创建的Pod拥有不同的IP。因而，在Kubernetes集群中，任何时候，都不建议直接以<pod_IP>:<pod_Port>的形式访问Pod。另外，Pods对Kubernetes集群外部是不可见的。

相对于Pods来说，Services是持久的。一个Service拥有一个在其生命周期内确定不变的虚拟IP（virtualIP, VIP）。VIP就是Service的CLUSTER-IP，也被称为internalIP。因而，在Kubernetes集群内部，通过<CLUSTER-IP>:<PORT>就可以访问一个服务。

1) Service到Pods的连通性

定义一个Service时，在YAML文件中配置Service的Label，拥有相同Label的一组Pods都被包含到这个Service。Service可以嵌套定义。

加入到Service中的每个Pod，都以<pod_IP>:<pod_Port>的形式组成Service的Endpoint的一部分。对一个Service的请求，会根据一定的规则从Service的Endpoint中选择一个<pod_IP>:<pod_Port>，最终将请求转发到对应的Pod进行处理。所以说，一个Service与其包含的Pods之间，永远是连通的。

如果一个Pod内包含多个容器实例，则加入到Service时，Service会为Pod内的每个容器实例暴露一个服务端口，以port-1, port-2形式给出。如果是NodePort类型的Service，还会为每个服务端口关联一个物理的NodePort端口。

一个Service与其他Pods之间的连通性，可以归结为Services之间的连通性，我们将在后文介绍。

2) Pod到Services的连通性

一个Pod（其实是Pod内的容器实例）要访问一个Service，首先要知道这个Service的存在。Pod发现Services有两种方式，通过环境变量或者通过DNS服务器。

Kubernetes集群默认以环境变量的方式发现Services。但是有个限制条件，就是只能发现Pod创建之前已存在的Services。这很容易理解，只有在Pod创建之前就已经存在的Services，其IP和Port才有可能被加入到Pod的环境变量。

要通过DNS服务器发现Services，首先需要为Kubernetes集群另外安装CoreDNS插件，这将启动一个kube-dns服务。该服务维护了一个服务名称与服务IP的映射表，并能够实时监控Kubernetes集群中的服务变化。通过DNS服务器可以发现任何Services。对于ExternalName类型的服务，只能通过DNS服务器发现。

在Kubernetes集群中，能够被发现的Services，对于一个Pod来说都是连通的。

4. Services之间的连通性

与Pod到Services的连通性相似，Services之间的连通性实质上也是服务发现的问题。在Kubernetes集群中，能够被发现的Services，对于一个Service来说都是连通的。只需要通过<CLUSTER-IP>:<PORT>的方式就可以访问服务。

5. Services对Kubernetes集群外部的连通性

在Kubernetes集群外部，唯一可见的就是Services。从Kubernetes集群外部，只能访问集群内部的某些类型的Services（NodePort类型和LoadBalancer类型）。

Services的CLUSTER_IP对集群外部是不可见的。为了能够从集群外部访问一个Service，还需要为Service配置一个EXTERNAL-IP。在Kubernetes集群外部，通过Service的EXTERNAL-IP访问服务时，根据Services的类型不同，访问方式如下：

对于NodePort类型的服务，访问http://<EXTERNAL-IP>:<NodePort> -k
对于LoadBalancer类型的服务，访问curl http://<EXTERNAL-IP> -k
注意，Services的EXTERNAL-IP不在集群的管理范围内。

 

参考链接：https://kubernetes.io/docs/concepts/architecture/master-node-communication/
https://kubernetes.io/docs/concepts/cluster-administration/networking/