目录
一、 为什么你需要 Spring Cloud Kubernetes?
二、 Starter
三、 用于 Kubernetes 的 DiscoveryClient
四、Kubernetes 原生服务发现(service discovery)
五、Kubernetes PropertySource 的实现
1、使用 ConfigMap PropertySource
一、 为什么你需要 Spring Cloud Kubernetes?
Spring Cloud Kubernetes提供了众所周知的Spring Cloud接口的实现,允许开发者在Kubernetes上构建和运行Spring Cloud应用。虽然这个项目在构建云原生应用时可能对你有用,但它也不是在Kubernetes上部署Spring Boot应用的必要条件。如果你刚刚开始在Kubernetes上运行你的Spring Boot应用,你只需要一个基本的Spring Boot应用和Kubernetes本身就可以完成很多事情
二、 Starter
Starter 是方便的依赖描述,你可以在你的应用程序中包含它。导入一个Starter,以获得功能集的依赖和Spring Boot自动配置。以 spring-cloud-starter-kubernetes-fabric8 开头的Starter提供了使用 Fabric8 Kubernetes Java 客户端 的实现。以 spring-cloud-starter-kubernetes-client 开头的Starter提供了使用 Kubernetes Java 客户端 的实现。
Starter | Features |
Fabric8 依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-fabric8</artifactId> </dependency> Kubernetes Client 依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-client</artifactId> </dependency> | Discovery Client 实现,将服务名称(service name) 解析为Kubernetes服务。 |
Fabric8 依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-fabric8-config</artifactId> </dependency> Kubernetes Client 依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-client-config</artifactId> </dependency> | 从Kubernetes ConfigMap 和 Secret 加载应用 application properties。当 ConfigMap 或 Secret 发生变化时,重新加载 application properties。 |
Fabric8 依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-fabric8-all</artifactId> </dependency> Kubernetes Client 依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-client-all</artifactId> </dependency> | 所有 Spring Cloud Kubernetes 的特性。 |
三、 用于 Kubernetes 的 DiscoveryClient
该项目提供了 Kubernetes 的 Discovery Client 的实现。这个客户端(Client)可以让你按名称查询Kubernetes端点(见 services)。服务通常由Kubernetes API服务器公开,是代表 http 和 https 地址的端点的集合,客户端可以从作为pod运行的Spring Boot应用程序中访问这些端点。
这是你通过在你的项目中添加以下依赖而自动得到的东西。
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-discoveryclient</artifactId> </dependency>
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-fabric8</artifactId> </dependency>
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-client</artifactId> </dependency>
要启用 DiscoveryClient
的加载,请将 @EnableDiscoveryClient
添加到相应的配置或 application 类中,如下例所示。
@SpringBootApplication @EnableDiscoveryClient public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
然后,你可以通过自动注入将 client 注入你的代码中,如下例所示。
@Autowired private DiscoveryClient discoveryClient;
你可以通过在 application.properties
中设置以下属性来选择从所有命名空间启用 DiscoveryClient
。
spring.cloud.kubernetes.discovery.all-namespaces=true
要想只从指定的命名空间发现服务和端点,你应该将属性 all-namespaces
设置为 false
,并在 application.properties
中设置以下属性(在这个例子中命名空间是:ns1
和 ns2
)。
spring.cloud.kubernetes.discovery.namespaces[0]=ns1 spring.cloud.kubernetes.discovery.namespaces[1]=ns2
要发现未被 kubernetes api 服务器标记为 "ready" 的服务端点地址,可以在 application.properties
中设置以下属性(默认:false
):
spring.cloud.kubernetes.discovery.include-not-ready-addresses=true
如果你的服务暴露了多个端口,你将需要指定 DiscoveryClient
应该使用哪个端口。 DiscoveryClient
将使用以下逻辑来选择端口。
- 如果该服务有一个标签(label)
primary-port-name
,它将使用标签值中指定的名称的端口。 - 如果没有标签,那么将使用
spring.cloud.kubernetes.discovery.primary-port-name
中指定的端口名称。 - 如果以上两项都没有指定,它将使用名为
https
的端口。 - 如果上述条件都不满足,它将使用名为
http
的端口。 - 作为最后的手段,它将选择端口列表中的第一个端口。
默认情况下,所有的端口和它们的名字将被添加到 ServiceInstance
的元数据(metadata)中。
如果出于任何原因,你需要禁用 DiscoveryClient
,你可以在 application.properties
中设置以下属性:
spring.cloud.kubernetes.discovery.enabled=false
一些Spring Cloud组件使用 DiscoveryClient
,以获取本地服务实例的信息。要做到这一点,你需要将 Kubernetes 服务名称与 spring.application.name
属性对齐。
Spring Cloud Kubernetes还可以观察Kubernetes服务目录的变化,并相应地更新 DiscoveryClient
实现。我们所说的 "观察"(watch)是指每隔 spring.cloud.kubernetes.discovery.catalog-services-watch-delay
毫秒(默认为30000)发布一个心跳事件。该心跳事件将包含目标引用以及所有端点地址的命名空间(关于返回的确切细节,你可以看看 KubernetesCatalogWatch
内部)。这是一个实现细节,心跳事件的监听者不应该依赖这些细节。相反,他们应该通过 equals
方法查看两个后续心跳之间是否存在差异。我们会注意返回一个正确的实现,遵守 equals
契约。端点将以两种方式进行查询。
- 所有命名空间 (通过
spring.cloud.kubernetes.discovery.all-namespaces=true
启用) - 特定的命名空间 (通过
spring.cloud.kubernetes.discovery.namespaces
启用), 例如:
spring: cloud: kubernetes: discovery: namespaces: - namespace-a - namespace-b
- 如果不采取上述两种途径,我们将使用 命名空间解析(Namespace Resolution)。
为了启用这个功能,你需要在你的 application 中的配置(configuration)类上添加 @EnableScheduling。 默认情况下,我们使用 Endpoints(见 kubernetes.io/docs/concepts/services-networking/service/#endpoints ) API来查找服务的当前状态。但还有另一种方法,通过 EndpointSlices( kubernetes.io/docs/concepts/services-networking/endpoint-slices/ )。这种支持可以通过一个属性启用:spring.cloud.kubernetes.discovery.use-endpoint-slices=true(默认为 false)。当然,你的集群也必须支持它。事实上,如果你启用了这个属性,但你的集群不支持它,我们将无法启动应用程序。如果你决定启用这种支持,你还需要适当地设置 Role/ClusterRole。例如:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: namespace-reader rules: - apiGroups: ["discovery.k8s.io"] resources: ["endpointslices"] verbs: ["get", "list", "watch"]
四、Kubernetes 原生服务发现(service discovery)
Kubernetes 本身能够进行(服务端)服务发现(见: kubernetes.io/docs/concepts/services-networking/service/#discovering-services )。使用原生的kubernetes服务发现确保了与其他工具的兼容性,如Istio( istio.io ),这是一个能够进行负载均衡、断路器、故障转移等的 service mesh。
然后,调用者服务只需引用特定Kubernetes集群中可解析的名称。一个简单的实现可以使用一个指向完整域名(FQDN)的 spring RestTemplate,例如 {service-name}.{namespace}.svc.{cluster}.local:{service-port}。
此外,你还可以将 Hystrix 用于:
通过在 spring boot application 中注解 @EnableCircuitBreaker,在调用方实现断路器。
Fallback 功能,通过用 @HystrixCommand(fallbackMethod=…) 注解相应的方法。
五、Kubernetes PropertySource 的实现
配置Spring Boot应用程序的最常见方法是创建 application.properties 或 application.yaml 或 application-profile.properties 或 application-profile.yaml 文件,其中包含为你的应用程序或Spring Boot Starter 提供定制值的键值对。你可以通过指定系统属性(system properties)或环境变量来覆盖这些属性。
要启用这一功能,你需要在应用程序的配置属性中设置 spring.config.import=kubernetes:目前,你不能使用 spring.config.import 指定要加载的 ConfigMap 或 Secret,默认情况下,Spring Cloud Kubernetes 将根据 spring.application.name 属性加载 ConfigMap 和 / 或 Secret。如果没有设置 spring.application.name,它将加载一个带有 application 名称的 ConfigMap 和 / 或 Secret。
如果你想在启动阶段加载 Kubernetes PropertySource,就像3.0.x版本之前那样,你可以将 spring-cloud-starter-bootstrap 添加到你的应用程序的 classpath 中,或者将 spring.cloud.bootstrap.enabled=true 作为一个环境变量。
1、使用 ConfigMap PropertySource
Kubernetes提供了一种名为 ConfigMap 的资源,以键值对或嵌入式 application.properties 或 application.yaml 文件的形式将参数外部化,以传递给你的应用程序。Spring Cloud Kubernetes Config 项目使Kubernetes ConfigMap 实例在应用程序启动期间可用,并在观察到的 ConfigMap 实例上检测到变化时触发Bean或Spring上下文的热重载。
下面的一切解释主要是指使用 ConfigMap 的例子,但对 Secret 来说也是如此,即:两者都支持每一个功能。
默认行为是基于 Kubernetes ConfigMap 创建 Fabric8ConfigMapPropertySource(或 KubernetesClientConfigMapPropertySource),其 metadata.name 值为Spring应用程序的名称(由其 spring.application.name 属性定义)或在 application.properties 文件中定义的自定义名称,key如下:spring.cloud.kubernetes.config.name。
然而,更高级的配置是可能的,你可以使用多个 ConfigMap 实例。spring.cloud.kubernetes.config.sources 列表使这成为可能。例如,你可以定义以下 ConfigMap 实例:
spring: application: name: cloud-k8s-app cloud: kubernetes: config: name: default-name namespace: default-namespace sources: # Spring Cloud Kubernetes looks up a ConfigMap named c1 in namespace default-namespace - name: c1 # Spring Cloud Kubernetes looks up a ConfigMap named default-name in whatever namespace n2 - namespace: n2 # Spring Cloud Kubernetes looks up a ConfigMap named c3 in namespace n3 - namespace: n3 name: c3