.NET Core + Kubernetes:Service

通过 .NET Core + Kubernetes:Deployment 文章的介绍,我们可以通过 Deployment 控制器快速创建一组 Pod 来提供服务,每个 Pod 都会被分配一个集群内可见的虚拟 IP 地址,然后通过一个独立的 Endpoint(Pod IP + ContainerPort)进行访问。但在提供服务时,并不能依赖 Pod 的 Endpoint,首先 Pod IP 会随着 Pod 的重建而变化,另外同一组 Pod 更希望是以整体对外提供高可用服务,组内的 Pod 在进行动态伸缩、滚动更新等操作后并不能影响服务稳定性。

因此,Kubernetes 中的 Service 对象就是解决此问题的核心,Service 代理 Pod 集合对外表现是为一个访问入口,它提供了一个虚拟的 IP 地址(ClusterIP)和端口,来自 ClusterIP + 端口 的请求将被负载均衡器 (kube-proxy)转发到后端某个 Pod 中的容器。所以借助 Service 的能力,非常方便的实现了服务发现与负载均衡。

本文将主要介绍 Kubernetes 中各 Service 类型的使用,目前有以下四种类型:

  • ClusterIP:默认类型,自动分配一个仅集群内部可以访问的虚拟 IP,也可使用 ClusterIP 字段指定固定 IP,选择此类型意味着只想这个服务在集群内部才可以被访问

  • NodePort:在 ClusterIP 基础上,在集群的每一个节点绑定一个端口,这样就可以通过任意的

    :NodePort 来访问服务

  • LoadBalancer:在 NodePort 的基础上,通过创建一个外部的负载均衡器,将流量转发到每个节点

    :NodePort。因为如果外部所有客户端都访问一个 NodeIP,该节点的压力将会很大,LoadBalancer 则可解决此问题

  • ExternalName:把集群外部的服务引入到集群内部来,在集群内部直接使用。没有任何类型代理被创建,这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持

下面分别对这几种类型的使用方式进行介绍,在创建 Service 之前,还是先通过 Deployment 控制器创建一组 Pod,配置文件 k8sdemo-deployment.yaml 如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: k8sdemo-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      name: k8sdemo
  template:
    metadata:
      labels:
        name: k8sdemo
    spec:
      containers:
      - name: k8sdemo
        image: beckjin/k8sdemo:1.0.0
        ports:
        - containerPort: 80
        imagePullPolicy: IfNotPresent

ClusterIP 类型

创建 k8sdemo-service.yaml 文件,配置如下,主要是 portsselector 字段的设置,指定了 80 端口( port ) 映射到 Pod ContainerPort ( targetPort ) 端口,最终将通过 ClusterIP:80 访问服务。 selector 字段指定将 label 含 name:k8sdemo 的 Pod 作为这个 Service 指向的目标服务。

apiVersion: v1
kind: Service
metadata:
  name: k8sdemo-service
spec:
  ports:
  - port: 80                 # Service Port
    targetPort: 80           # Pod ContainerPort
  selector:
    name: k8sdemo
   # clusterIP: 10.1.19.92   # 取消注释指定IP

执行命令 kubectl apply -f k8sdemo-service.yaml 创建 Service,然后通过 kubectl get service 查看服务状态:

从上图可以看出 k8sdemo-service 被分配的 ClusterIP 是 10.1.19.96 ,所以可以在服务器上通过 curl http://10.1.19.96/WeatherForecast 来访问接口。

因为 ClusterIP 默认是自动分配的,所以每次重建会变化,如果需要固定,可通过 ClusterIP 字段设置。对于只需在集群内部提供的服务,ClusterIP 类型已足够。

NodePort 类型

基于 ClusterIP 类型中使用的配置文件 k8sdemo-service.yaml ,增加 type: NodePort 配置,重新创建 Service,如下:

apiVersion: v1
kind: Service
metadata:
  name: k8sdemo-service
spec:
  ports:
  - port: 80
    targetPort: 80
    # nodePort: 30080   # 取消注释指定端口
  selector:
    name: k8sdemo
  type: NodePort

从上图可以看出,除了类型变了, PORT(S)也变成了 80:30231/TCP ,即将 Service 的 80 端口与集群中各节点的 30231 端口进行映射,所以最终可以通过集群内任意的 NodeIP:30231 来访问,整个过程为: Client > NodeIP:NodePort > ClusterIP:ServicePort > PodIP:ContainerPort 。NodePort 默认分配的是 30000-32767 范围内随机选择的一个端口,实际使用时可以通过 nodePort 字段指定。请求结果如下:

注:192.168.124.10 是集群内某一台的 IP

LoadBalancer 类型

通过 NodePort 类型的使用介绍,已经了解可以通过 NodeIP:NodePort 方式来服务访问,而且 NodeIP 可以是集群内任意任何一台的 IP。而 LoadBalancer 则是在外层附加的负载均衡器,使请求能分摊到集群内各个节点上。

MetalLB 搭建

要使用 LoadBalancer 类型会稍微复杂一些,并不能只单纯的修改配置文件,因为一般自建的 Kubernetes 集群默认并不支持 LoadBalancer,所以它需要借助外部的负载均衡器来实现,这里将使用 MetalLB ( v0.9.3 ),安装请参考 Installation By Manifest ,步骤不复杂,但需要确保依赖镜像下载顺利,完成后查看 Pod 状态:

另外需要为 Metallb 设置地址池以及协议相关配置,Metallb 会监控服务对象的变化,当有新的 LoadBalancer 服务运行,但没有可申请的负载均衡器时,就会从配置的地址池中分配一个给该服务。这里以 Metallb Layer2 工作模式为例( Metallb 支持 Layer2/BGP 两种工作模式 ),创建一个资源类型为 ConfigMap 的配置文件 metallb-layer2-config.yaml ,内容如下:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.124.200-192.168.124.210  # IP 地址范围需与自己的集群环境对应

Layer2 工作模式原理图:

配置修改

有了以上的准备工作后,只需要在 Service 配置文件将 type 修改为 LoadBalancer ,然后重新创建 Service,如下:

apiVersion: v1
kind: Service
metadata:
  name: k8sdemo-service
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    name: k8sdemo
  type: LoadBalancer

从上图可以看出,TYPE 已是 LoadBalancer,另外 EXTERNAL-IP 被分配为地址池中的 192.168.124.200 ,接下来就可以通过这个 IP 进行访问了,结果如下:

ExternalName

ExternalName 类型比较特殊,它没有 selector,也没有定义任何的端口, 对于运行在集群外部的服务,它通过返回该外部服务的别名这种方式来提供服务,如下:

apiVersion: v1
kind: Service
metadata:
  name: k8sdemo-external-service
spec:
  type: ExternalName
  externalName: mingdao.com

当访问 k8sdemo-external-service.default.svc.cluster.local 时,集群的 DNS 服务将返回值为 mingdao.com 的 CNAME 记录,访问这种类型的服务与其它的唯一不同的是重定向发生在 DNS 层,而且不会进行代理或转发。

进入 Kubernetes 集群的任意一个 Pod 中(必须是集群内部才可访问),如: kubectl exec -it k8sdemo-deployment-68cb864ff6-fzzdq -- /bin/bash ,执行 curl -L http://k8sdemo-external-service.default.svc.cluster.local/ 即会重定向请求到 mingdao.com ,结果如下: