在前面文章 (spring-cloud-k8s 跨 NS 的坑 中,讲述了 spring-cloud-k8s
中,如何利用 k8s 基于 Ribbon 等负载均衡利器来实现 LB,但存在跨命名空间
的问题。
今天主要分享的是,基于 K8s 本身的 LB 利器,如何实现跨命名空间的应用服务互相访问,而且不是通过 K8s 原生的负载均衡 url 方式。还是基于 ServiceName。
直击源码
首先,我们新建一个服务提供者:diff-ns-service
,该服务提供了一个接口:
/**
* 返回远程调用的结果
* @return
*/
@RequestMapping("/getservicedetail")
public String getservicedetail(
@RequestParam(value = "servicename", defaultValue = "") String servicename) {
return JSON.toJSONString(discoveryClient.getInstances(servicename));
}
该接口的功能是返回指定 service 的相关信息。比如:这个 Service 对应的有几个 pod,每个 pod 的节点信息,host 等。
![edf6eb797278940ac2019918b5259d95.png](https://i-blog.csdnimg.cn/blog_migrate/bf093a17ff9ce8ed8ea4dfd3d4c19f6e.png)
如果想结合 K8s 来实现这个服务的发现,可以基于这个配置:
management:
endpoint:
restart:
enabled: true
health:
enabled: true
info:
enabled: true
spring:
application:
name: diff-ns-service
cloud:
loadbalancer:
ribbon:
enabled: false
kubernetes:
ribbon:
mode: SERVICE
discovery:
all-namespaces: true
另外,如果想利用 k8s configMap 的配置来实现动态刷新应用服务的环境配置,可以这样配置:
spring:
application:
name: diff-ns-service
cloud:
kubernetes:
reload:
enabled: true
strategy: refresh
mode: event
config:
name: ${spring.application.name}
namespace: default
sources:
- name: ${spring.application.name}
namespace: ns-app
这里的动态刷新的模式有两个:[polling
、event
。一个是主动拉取,一个是当 configmap 发生改变时,这种事件会被监听到,会主动刷新。
另外,这个刷新的策略也有几种:
refresh,直接刷新
restart_context,整个 Spring Context 会优雅重启,里面的所有配置都会重新加载
shutdown,重启容器
这样,我们再来配置一下 Service:
apiVersion: v1
kind: Service
metadata:
name: diff-ns-service-service
namespace: ns-app
spec:
type: NodePort
ports:
- name: diff-ns-svc
port: 2008
targetPort: 2001
selector:
app: diff-ns-service
这里我们设置了 Service 的 port,并且这个 Service 以 NodePort
类型创建。在(spring-cloud-k8s 跨 NS 的坑)一文中,我们使用的是默认的类型:ClusterIp。
这样,一个简单的服务提供者就创建成功了。接下来,我们看看服务消费者。
同样,我们先来创建一个服务 rest-service
,创建接口:
@GetMapping("/get