.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 基础上，在集群的每一个节点绑定一个端口，这样就可以通过任意的 <NodeIP>:NodePort 来访问服务
LoadBalancer：在 NodePort 的基础上，通过创建一个外部的负载均衡器，将流量转发到每个节点 <NodeIP>: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 文件，配置如下，主要是 ports 和 selector 字段的设置，指定了 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，结果如下：