Spring Cloud Kubernetes详解

目录

一、 为什么你需要 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 将使用以下逻辑来选择端口。

1. 如果该服务有一个标签（label） primary-port-name，它将使用标签值中指定的名称的端口。
2. 如果没有标签，那么将使用 spring.cloud.kubernetes.discovery.primary-port-name 中指定的端口名称。
3. 如果以上两项都没有指定，它将使用名为 https 的端口。
4. 如果上述条件都不满足，它将使用名为 http 的端口。
5. 作为最后的手段，它将选择端口列表中的第一个端口。

默认情况下，所有的端口和它们的名字将被添加到 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