Spring Cloud Kubernetes 移除 Eureka 中间件

Kubernetes 通过 Kube-proxy 组件、Service 对象实现了 Pod 的服务发现、负载均衡问题，在 Spring Cloud 体系中是通过 Eureka、Nacos 等中间件来实现的，既然我们的微服务是基于 Kubernetes 来部署的，那这部分功能就可以下沉到基础设施层，由 Kubernetes 来提供。

在 Spring-Cloud-Dependencies 中已经引入了 Kubernetes 客户端操作的相关包，来解决微服务在 K8s 体系中服务发现 Discovery（Service） 和配置中心 Config（ConfigMap） 的问题。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-kubernetes-dependencies</artifactId>
    <version>${spring-cloud-kubernetes.version}</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

下面还以 https://github.com/14032/cloud 这个 Demo 程序为例，来看下服务中如何使用 K8s 的服务发现功能来替代掉 Eureka。

在 Kubernetes 的实现版本中，首先去除掉 Eureka、Ribbon 客户端的依赖。

引入 Spring Cloud Kubernetes 相关依赖做适配，Spring Cloud Kubernetes 本身引入了 Fabbric8 的 Kubernetes Client 作为客户端来操作 Kubernetes API Server。

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-kubernetes</artifactId>
</dependency>
<!--<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-kubernetes-loadbalancer</artifactId>
</dependency>-->
<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-kubernetes-ribbon</artifactId>
</dependency>

上面提供了两种负载均衡实现，ribbon 和 loadbalancer 选择一个即可，再看下配置文件如下：

spring:
  cloud:
    kubernetes:
      discovery:
        service-name: ${spring.application.name}
        all-namespaces: true
      ribbon:
        enabled: true
        mode: service
        cluster-domain: cluster.local

spring.cloud.kubernetes.ribbon.mode 提供了两种模式：service 和 pod。

这两种模式，其实也就对应了 Kubernetes 的两个 API 接口：

• /api/v1/namespaces/cloud/endpoints
• /api/v1/namespaces/cloud/services

@Bean
@ConditionalOnMissingBean
public ServerList<?> ribbonServerList(KubernetesClient client, IClientConfig config,...) {
KubernetesServerList serverList;
  if (properties.getMode() == KubernetesRibbonMode.SERVICE) {
    serverList = new KubernetesServicesServerList(client, properties);
  }
  else {
    serverList = new KubernetesEndpointsServerList(client, properties);
  }
  return serverList;
}

如果选用 service 模式，Ribbon 的客户端负载均衡也就不在有效，而是使用 Kubernetes Service 本身具有的基于 DNS 的负载均衡功能。例如：auth-server.cloud.svc.cluster.local:9096，这种方式也不会再出现使用Eureka （服务端缓存、客户端心跳、客户端更新频率）时因服务更新而导致的服务间短暂调用失败问题。

因为只有处于就绪状态（readliness）的服务才会出现在 Service 的 Endpoints 站点列表中。pod 模式，就是去获取 Service 代理的 Endpoints 站点，由 Ribbon 来提供负载均衡功能。

下面再看下 Spring Cloud Kubernetes 是如何获取 K8s 集群服务列表的？答案就是：Fabbric8。

Fabbric8 通过默认的 Kubernetes API Server 的代理 Service 域名来访问 API Server。

从 Pod 中访问 API

当你从 Pod 中访问 API 时，定位和验证 apiserver 会有些许不同。
在 Pod 中定位 apiserver 的推荐方式是通过 kubernetes.default.svc 这个 DNS 名称，该名称将会解析为服务 IP，然后服务 IP 将会路由到 apiserver。
向 apiserver 进行身份验证的推荐方法是使用 服务帐户 凭据。 通过 kube-system，Pod 与服务帐户相关联，并且该服务帐户的凭证（token） 被放置在该 Pod 中每个容器的文件系统中，位于 /var/run/secrets/kubernetes.io/serviceaccount/token。

DEFAULT_MASTER_URL = "https://kubernetes.default.svc"

default 空间下，名称为 kubernetes 的 Service 的 Endpoints 即为 Master 节点上 6443 端口的服务，下图可以看到 6443 端口既是 kube-apiserver 组件。

经过上面的改造后，我们就可以重新构建镜像将微服务部署到 Kubernetes 集群中，当服务启动，相互访问的时候，会出现如下错误，Message: Forbidden!Configured service account doesn't have access Pod 内没有权限去访问 apiserver，如果你了解过 Kubernetes 基于角色的权限控制 （RBAC）的功能，你会立即想到要给 Pod 重新绑定一个 ServiceAccount 来授权操作 kube-apiserver 接口。

2021-07-25 17:42:21.000 ERROR 1 [   scheduling-1] [o.s.c.k.d.KubernetesCatalogWatch       ] - Error watching Kubernetes Services
io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: GET at: https://10.96.0.1/api/v1/endpoints. Message: Forbidden!Configured service account doesn't have access. Service account may have been revoked. endpoints is forbidden: User "system:serviceaccount:cloud:default" cannot list resource "endpoints" in API group "" at the cluster scope.
        at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestFailure(OperationSupport.java:589)
        at io.fabric8.kubernetes.client.dsl.base.OperationSupport.assertResponseCode(OperationSupport.java:526)
        at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:492)

参考文档：spring-cloud-kubernetes/docs/current/reference/html/#service-account

我这里直接给了 Kubernetes 默认的集群只读角色 view，更细粒度的可参看官方文档。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cloud-account
  namespace: cloud
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cloud-account
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - kind: ServiceAccount
    name: cloud-account
    namespace: cloud

然后再为微服务的每个 Pod 绑定此账号，这样容器里的应用就可以使用这个 ServiceAccount 来访问 API Server 了。

spec:  
  serviceAccountName: cloud-account

这样基于 kubernetes 平台部署的微服务，就不再需要引入 Eureka 中间件来解决服务发现/注册的功能，而是在基础设施层替代原有的应用层面的技术组件。

同样的，配置中心也可以下沉到基础设施层，由 kubernetes 中的 ConfigMap 对象来提供。

网关层，前面有介绍，Ingress 并不能胜任 API 网关的角色。

如果引入 Istio 服务网格，Istio 将会接管 Kube-proxy 的代理能力，以及 Kubernetes 中 Service 服务发现的能力。Istio 控制平面会和 Kubernetes 的 API 对接，将集群内部所有的服务、站点信息下发到每一个 Sidecar 代理中。

也即 Pod 中的所有请求被 Envoy 代理拦截后，直接根据本地的服务列表信息进行路由负载转发。

这时 Spring Cloud Feign、Discovery、Ribbon 等都可以移除，服务之间直接以服务名称（svc 域名）进行访问。

~ END ~