从第三节:的示例中,已经运行起来了一个 Nginx 的 Pod,处于好奇,当运行起来之后及时看到状态是 Runing 的,也会想尝试用浏览器访问试试看是否真的运行了。但是,事情就是这么尴尬,刚打开浏览器,然后就发现不知道该访问什么地址,第三篇文章里面也没说啊,假设我告诉你查询 Pod 可以加一个参数,可以看到 IP:

  1. [root@liqiang.io]# kubectl get pods first-pod -o wide
  2. NAME READY STATUS RESTARTS AGE IP NODE
  3. first-pod 1/1 Running 0 14h 172.17.0.2 host-79

这里有一个 IP: 172.17.0.2,然而,当你尝试访问的时候,一般情况下是访问不通的(当然,不排除你网络设置等原因可以访问通),这就很尴尬了啊,我运行的应用不就是想被访问的吗,现在访问不了是几个意思?

这个时候就要聊聊 K8S 对于 Pod 的设计理念了,Pod 是最小的单元,往往当我们运行一个应用的时候,对 Pod 有一些额外的要求,例如高可用或者多实例,这就意味着如果你只记住一个 Pod 的 IP,那么很多时候都是会有问题的,例如高可用,可能会因为 Pod 的重建而改变,这样你记住的那个 IP 就失效了。一个很自然的想法就是,能不能把这个 IP 固定住,这是个好的想法,但是实现的时候有一些可以扩展的地方,例如,高可用类型的 Pod 可以固定 IP,那么我多个实例的 IP 做负载均衡要不要固定 IP 呢?于是乎,就到了这篇文章要介绍的新的资源:Service。

为什么要存在 Service

从前面的描述中,我们已经知道了 Service 存在的意义,总结起来一下亮点:

所以可以用这个图来展示一下 Pod 和 Service 的关系:

Service 操作

按照惯例,要开始介绍一些例子了,承接前面将 Pod 的描述,在 K8S 中,资源通用的字段 Service 都会有,下面就给出一个示例:

  1. [root@liqiang.io]# cat /home/liqiang.io/blog/kubernetes/guide/chap04/00-simple-service.yaml
  2. ---
  3. apiVersion: v1
  4. kind: Service
  5. metadata:
  6. name: first-svc
  7. spec:
  8. type: NodePort
  9. selector:
  10. app: nginx
  11. ports:
  12. - protocol: TCP
  13. port: 5580
  14. targetPort: 80
  15. nodePort: 32280
  16. [root@liqiang.io]# kubectl apply -f 00-simple-service.yaml
  17. service "first-svc" created
  18. [root@liqiang.io]# kubectl get svc first-svc
  19. NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
  20. first-svc 10.110.87.116 <nodes> 5580:32280/TCP 3m

这里有几个地方需要说明一下:

可能你会认为这个时候打开浏览器就可以通过 10.110.87.116 这个 IP 访问到这个 Service 了,但是事实上,一般情况下也是不行的。这个 IP 是集群内部使用的,集群外部也是访问不了的,那么如果你想测试验证一下该怎么办?你需要访问的是 K8S 在的集群的 IP,以及上面这里指定的 32280 端口,也就是说:

  1. [root@liqiang.io]# curl -I 192.168.62.255:32280
  2. HTTP/1.1 200 OK
  3. Server: nginx/1.17.0
  4. Date: Sun, 30 Jun 2019 05:53:09 GMT
  5. Content-Type: text/html
  6. Content-Length: 612
  7. Last-Modified: Tue, 21 May 2019 14:23:57 GMT
  8. Connection: keep-alive
  9. ETag: "5ce409fd-264"
  10. Accept-Ranges: bytes

这样就访问通了这个 Pod,这个 IP 可以是集群中任意一个节点的 IP,都没有关系。

外部访问 Service 的几种方式

这里之所以我们在集群外部能访问到 Service,是因为我指定了 Service 的 Type 是 NodePort,在 K8S 中,如果不指定这个 Type 的话,Service 是只能在内部访问的,集群外部是访问不了的。要想在集群外部访问,就需要特别的设置,这里有几种可以设置的方式:

NodePort 的使用就如示例中介绍的那样就可以访问了。LoadBalancer 一般也不在私有云中使用,所以比较难以尝试,就不介绍了。最后一种就是 Ingress,在一般的尝试中,我们都是通过 Nginx-Ingress 的方式进行介绍,这里因为入门的缘故,也就不介绍得那么深了,可以理解成我们将以前写 Nginx 的配置的方式转化成写 K8S 资源配置的形式来处理就可以了。

内部访问 Service

那么在我们集群内部又要如何访问 Service 呢?例如我设置了一个名字叫做 MySQL 的 Service,在我的一个应用 service-blog 中要怎么访问 MySQL?是指定 Service 的 IP 的形式吗?但是在开发的时候我都不知道部署在哪个集群,这个集群里面 MySQL 的 service ip 是什么,这就没法写了。

K8S 的设计肯定是考虑到了这种情况,对于 Service 的访问,内部都是通过 DNS 来进行的,也就是说,当你定义了一个 Service 之后,K8S 就响应得生成了一个 DNS 记录,这个 Service 对应的内部域名就是: <cluster-name>.<namespace>.svc.cluster.local,在没有特别指定 Service 类型的时候,访问这个 A 记录,它返回的是 Service 的 ClusterIP;如果你设置了 Service 的 ClusterIP 为 None,那么返回的就是所有被代理的 Pod 的 IP 地址的集合。

小结

在这篇文章中,我介绍了什么是一个 Service 以及 Service 存在的意义,还有 Service 是怎么和 Pod 联系起来并且对外提供服务的。但是,还有一些内容没有提及,这个都不能简单的属于入门内容,后面有入门之后的进阶系列,你可以多关注了解一下。