目录
一、 为什么你需要 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
