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 时，定位和验证 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 ~
