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地址设定好规则和限制,尽管有些服务依然存在于集群外部。