Kubernetes 服务选择(selector)

K8S中的Service是一个抽象概念,它定义了一个服务的多个pod逻辑合集和访问pod的策略,一般把service称为微服务

举个例子:一个a服务运行3个pod,b服务怎么访问a服务的pod,pod的ip都不是持久化的重启之后就会有变化。 这时候b服务可以访问跟a服务绑定的service,service信息是固定的提前告诉b就行了,service通过Label Selector跟a服务的pod绑定,无论a的pod如何变化对b来说都是透明的。

创建服务对应的后端

先创建一个可以充当 backend pods 的 deployment

文件名:service-deployment-hello.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  replicas: 5
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: nginx
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 80

这个普通的 Deployment。唯一需要注意的是 ports 信息,它显示了这个 Pod 暴露了哪些端口,类似于 docker 中 expose 的意义。但是一般来讲,这个信息是没必要的。因为 Pod 具有唯一的集群内可访问的 ip, 不会跟其他 Pod 产生冲突,任何监听了 0.0.0.0 这样地址的服务都可以通过 :的方式访问。这里写上的作用主要是提供一些更明确的信息,也方便一些工具比如 kubectl 的使用而已。

在终端执行如下命令创建 deployment:

ctr -n k8s.io i import /share/images/nginx.tar
kubectl create -f /share/lesson/kubernetes/service-deployment-hello.yaml

看下最终我们创建出来的 pods 结果

kubectl get po

然后我们来创建对应的 Service

文件名:service-svc-hello.yaml

apiVersion: v1
kind: Service
metadata:
  name: hello
  labels:
    app: hello
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: hello

Service 的 spec 部分就是它的主要信息,主要包含以下内容:

  • ports: 是一个端口信息列表,也就是说一个 Service 可以管理多个端口的访问。本身 Pod 可以对外暴露多个端口
  • port: service 绑定的端口,也就是这个 Service 所对应的 ip 监听的端口
  • targetPort: backend 的端口,也就是 Pod 所暴露的端口
  • selector: 标签选择,符合这个标签的 Pod 会作为这个 Service 的 backend。

在终端执行如下命令创建并查看:

kubectl create -f /share/lesson/kubernetes/service-svc-hello.yaml
kubectl get svc 

这条命令用来查看 default namespace 下的 Service 信息列表。因为 default namespace 是默认值,可不写。 -o wide 会增加一些额外的信息展示,看下结果:

除了 yaml 中我们填写的信息之外,kubernetes 帮我们补充了其他的默认信息:

  • Type: 类型,决定着 Service 如何对外提供服务。因为我们在 yaml 里未设置,所以这里用的默认值: ClusterIP, 具体有哪些可选的会在下面讲解。
  • Cluster IP: 系统帮我们自动生成的 ip 地址。这个 ip 地址的范围是可配置的,并且只能在集群内部访问。

看下完整的 yaml:

kubectl get svc hello -o yaml

这里又比刚才的列表页显示了更多的信息,需要注意的如下:

  • sessionAffinity: 这是负载均衡里面比较常见的一个概念,就是让来自于同一个 client 的请求落到同一个 backend 上。默认为 None。
  • ports[0].protocol: 端口协议,默认为 TCP ,目前只支持 TCP/UDP。

容器的轻量级特性,让作为 backend 的 Pod 可以比传统方式更加随意地起停。Service 只记录了 labelSelector,但具体的映射关系仍然需要有个地方记录下来。当然这个工作是由 kubernetes 来完成,而不是用户。记录这个映射关系的资源就是 Endpoints,同一个 namespace 下与 Service 同名的 Endpoints Resource 即是这个映射关系的管理者。刚才我们创建好了 Service 之后,Kubernetes 已经帮我们创建好了相应的 Endpoints 资源:

kubectl get ep hello -o yaml

注:ep 是 endpoints 的简称。

主要信息在 subsets 里面,addresses 列表记录了每个 backend 的信息,这里面的两个 Pod 信息就是我们刚才创建的两个 Pod 。addresses 里面记录了 Pod 的 ip、所在的主机名称、以及具体的 Resource Object 的引用。

下面我们可以通过访问这个 service 的 ip(即CLUSTERIP) 来访问这个服务了。

helloclusterip=$(kubectl get svc hello -o go-template --template='{{.spec.clusterIP}}')
echo $helloclusterip
curl $helloclusterip

其中$helloclusterip即上面的 service 生成之后所分配的 ip ,每次创建的 ip 都是不一样的。

注意:

  • 我们的hello程序运行了一个页面,其中显示了运行其的 host 的 hostname, 在这个场景中就是 pod 的 hostname, 而 pod 的 hostname 一般就是其名字。
  • 这里我们可以观察出来, Service 做了负载均衡,将流量转发到了不同的pod实例上。

DNS

上面的使用 ip 的使用有一个很致命的问题,就是它不好记,而且不方便使用。如果你让系统自动分配,那很难知道生成的结果是什么,无法提前配置。如果是自己选好固定的 ip ,服务多了又不好管理。而服务发现就解决了这个问题。我们仍然拿刚才的实验继续验证下。

首先要注意的是,service 的 ip 是可以在 kubernetes 的 node 上和 pod 里面直接访问的。但 dns 只能在 pod 里面访问,因为它需要配置 kubernetes 的 dns 服务为解析服务器,而且还要配置其他参数。 kubernetes 在启动每个 pod 时都会将这些配置好。

准备busybox pod

ctr -n k8s.io i import /share/images/busybox.latest.tar
kubectl create -f /share/lesson/kubernetes/busybox.yaml

进入busybox pod

kubectl exec -it busybox sh

使用域名访问服务,而不是IP

wget -O- hello

可以看到,运行结果与上面通过 curl 是一样的。那么它是怎么实现的呢?

我们用 nslookup 命令来探究下:

nslookup hello

nslookup 命令用于解析某一个域名,会得到如下类似的结果

Server:         10.96.0.10
Address:        10.96.0.10:53

Name:   hello.default.svc.cluster.local
Address: 10.96.177.43

这里我们需要注意的是:

(1)server 的地址,这里显示的 server 就是 dns server, 它就是 kubernetes 中 dns 服务的地址。

kubectl get svc -n kube-system

在部署完集群后,这个 svc 就自动创建了。

(2)解析到的名字

dns server 帮我们解析到了正确的 ip ,但是后面显示的域名比较长。这里涉及到了一个 dns search-path 的概念。我们看下 dns resolve 的配置文件。

cat /etc/resolv.conf

简单来讲,当我们查询 hello 这个域名时,dns server 会帮我们查询下面的几个名字:

  • hello
  • hello.default.svc.cluster.local
  • hello.svc.cluster.local
  • hello.cluster.local

其中 hello.default.svc.cluster.local 是正确的域名,它的格式为..svc.。其中 suffix 是集群配置,而 namespace 则视具体的情况而定。有了 search path, kubernetes 的服务不仅实现了通过域名访问,而且实现了最简单的仅通过名字即可访问的模式。在实际的业务场景中,这是非常便利的一个条件。想象一个常见的场景, 有一个 namespace 叫 http,里面有服务 a 、 b, 有一个 namespace 叫 storage, 里面有 redis、db 两个服务,那么 a、b 之间的互相访问只需要知道对方的名字即可,不需要知道它们所处的 namespace(可以方便地一起迁移)。而 a b 想要访问 redis 或者 db, 那么也仅仅需要用 redis.storage 或者 db.storage 这两个名字即可。

移动端设备除iPad Pro外,其它移动设备仅能阅读基础的文本文字。
建议使用PC或笔记本电脑,浏览器使用Chrome或FireFox进行浏览,以开启左侧互动实验区来提升学习效率,推荐使用的分辨率为1920x1080或更高。
我们坚信最好的学习是参与其中这一理念,并致力成为中文互联网上体验更好的学练一体的IT技术学习交流平台。
您可加QQ群:575806994,一起学习交流技术,反馈网站使用中遇到问题。
内容、课程、广告等相关合作请扫描右侧二维码添加好友。

狐狸教程 Copyright 2021

进入全屏