service和Pods
service通过使用labels指向pods,而不是指向deployments或者replicasets。这种设计的灵活性极高，因为创建pods的方式有很多，而Service不需要关心pods通过那种方式创建
不使用service（首先看不使用service的情况）
如下图，有两个node和一个pod,两个node分别使用外部IP地址（10.10.10.1）和（10.10.10.2)以及内部IP地址（1.1.1.1和1.1.1.2）,而名为pod-mysql的pod只有一个内部IP地址
如下图，现在我们添加第二名为pod-nginx的pod,它被调度到了node1上。虽然两个pod在不同的node上，但这不影响它们互相访问。在kubernetes集群中，所有的pod都可以通过内部IP地址访问其他的pod,不管它们运行在那个node上。这就意味着pod-nginx能通过内部IP地址1.1.1.3ping或者连接pod-mysql
如上图，现在我们考虑将pod-mysql杀死并重建一个新pod.操作完成之后，pod-nginx就无法继续访问IP地址1.1.1.3，这样系统就中断崩溃了。为了避免这种问题，我们来创建第一类service！
Cluster IP类型
与上述场景一样，但这次我们配置一个Cluster IP类型service。service不像pod会调度到特定的node上，在本文中你可以假定service仅在整个集群的内存中生效
现在，pod-nginx总是能够安全地连接IP地址1.1.10.1或者域名service-mysql，然后重定向到一个活跃地mysql pod上。
NodePort类型
现在我们想让Cluster IP类型的service在集群外部也能够使用，所有将其转换成NodePort类型的service。
如下图所示，现在我们集群内部service-mysql也能通过所有node的内部以及外部IP地址和端口30080访问
如下图所示，集群内部的pod也能访问node的内部IP地址和端口30080
LoadBalancer类型
当我们想通过一个IP地址将请求分发到所有node节点的外部IP地址时，可以使用LoadBalancer类型的service。因此，它是构建于NodePort类型的service之上，如下图所示
ExternalName类型
ExternalName类型的service，它可以被认为是有点分开的，和之前介绍的3种不在一个技术栈。简而言之，它创建了一个内部服务，端点指向一个DNS域名
现在假设pod-nginx以及迁移到新的kubernetes集群，但mysql服务还在外部
如下图所示，pod-nginx可以直接连接http://remote.server.url.com，这样是没有问题的。但不久之后，我们想将mysql服务也迁移到新的集群中，到时就会出问题了，因此我们可以创建一个ExternalName类型的service
现在，pod-nginx可以简单地与http://service-mysql:80建立连接，就像使用Cluster IP类型地service一样。当最终我们绝对将mysql服务迁移到新的Kubernetes集群中时，我们只需要将service的类型改成Cluster IP并使用对应的labels配置即可
使用ExternalName类型service的最大好处在于，你可以先建设好kubernetes集群基础设施，并且基于service和IP地址设定好规则和限制，尽管有些服务依然存在于集群外部。