EEPW论坛

在介绍Service这个api资源对象时，我们已经汇总过Service的几种类型：ClusterIP、NodePort、LoadeBalancer，其实除了这三个外还有其它的类型，在本章节我们暂且不去讨论。

这三种类型的Service，LoadBalancer依赖NodePort，而NodePort通常要和ClusterIP一起使用，如果在Service的yaml文件里定义type为LoadBalancer，则它会自动创建NodePort，而NodePort也会自动创建ClusterIP。

下面，再来演绎一下从Pod到Service的网络变化情况：

1）单个Pod之间通信

单个Pod和Pod之间通信只能通过Pod的IP和Port来通信，如下图

没有多余的描述，只要知道对方Pod的IP以及服务的端口，直接去访问就行了，简单粗暴！

2）Pod有多个

当引入Deployment，并为Pod设置多个副本时，那么提供某一个服务（如Nginx服务）的Pod就不止一个了，此时即使知道了这些Pod的IP，那访问起来也并不方便。所以，这里需要有一个统一入口，其它Pod通过这个统一入口去请求该服务（Nginx）对应的所有Pod。这时就有了Service这个资源对象，它主要作用就是用来提供统一入口，也就是说只需要一个IP就能访问所有的Pod，而这个入口IP就是ClusterIP，也就是Service的IP。

3）外部资源访问内部Pod

有了Service，的确可以很方便为内部的Pod提供入口，但是在集群外面访问这个内部的资源就没办法了。于是，就有了这个NodePort，使用Service的NodePort类型，可以将Service的ClusterIP对应的Port映射到每一个Node的IP上，映射出去的Port范围为30000~32767

4）借助公有云的负载均衡器

使用这个NodePort并不方便，毕竟它带着一个长长的端口号，而且还有一个非常尴尬的问题，就是访问时还得带着Node的IP，如果这个Node挂掉，那么就无法访问此资源，虽然可以通过另外一个Node去访问，但这样太麻烦在！所以，此时的解决方案是：借助三方的负载均衡器，将请求分发到所有的Node上，其底层还是NodePort。

总结：Service为内部Pod的统一入口，内部资源之间可以通过最简单的ClusterIP进行通信，而外部资源访问需要借助NodePort的形式，但是带着长长端口不方便，于是又衍生了LoadBalancer的形式，这种形式需要借助三方的负载均衡器，将请求分发到每一个NodePort上。