本参考指南介绍了如何使用Spring Cloud Kubernetes。
1.为什么需要Spring Cloud Kubernetes?
Spring Cloud Kubernetes提供了使用Kubernetes本机服务的Spring Cloud通用接口实现。该存储库中提供的项目的主要目的是促进Kubernetes中运行的Spring Cloud和Spring Boot应用程序的集成。
2.首发
入门程序是方便的依赖项描述符,您可以在应用程序中包含它们。包括一个启动器以获取功能集的依赖关系和Spring Boot自动配置。
起动机 特征
org.springframework.cloud
spring-cloud-starter-kubernetes
将服务名称解析为Kubernetes Services的Discovery Client实现。
- Kubernetes的DiscoveryClient
该项目提供了Kubernetes的Discovery Client 的实现。通过此客户端,您可以按名称查询Kubernetes端点(请参阅服务)。Kubernetes API服务器通常将服务公开为代表http和https寻址的端点的集合,并且客户端可以从作为Pod运行的Spring Boot应用程序访问该服务。Spring Cloud Kubernetes Ribbon项目还使用此发现功能来获取为要进行负载平衡的应用程序定义的端点列表。
您可以通过在项目内部添加以下依赖项来免费获得这些东西:
org.springframework.cloud spring-cloud-starter-kubernetes 要启用的加载DiscoveryClient,请添加@EnableDiscoveryClient到相应的配置或应用程序类中,如以下示例所示:@SpringBootApplication
@EnableDiscoveryClient
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
然后,您可以简单地通过自动装配将客户端注入代码中,如以下示例所示:
@Autowired
private DiscoveryClient discoveryClient;
您可以DiscoveryClient通过在中设置以下属性来选择从所有名称空间启用application.properties:
spring.cloud.kubernetes.discovery.all-namespaces=true
如果出于任何原因需要禁用DiscoveryClient,则可以在中设置以下属性application.properties:
spring.cloud.kubernetes.discovery.enabled=false
某些Spring Cloud组件使用DiscoveryClient来获取有关本地服务实例的信息。为此,您需要将Kubernetes服务名称与该spring.application.name属性对齐。
spring.application.name 对于在Kubernetes中为该应用程序注册的名称无效
Spring Cloud Kubernetes还可以监视Kubernetes服务目录中的更改并相应地更新 DiscoveryClient实现。为了启用此功能,您需要@EnableScheduling在应用程序中添加 配置类。
- Kubernetes本机服务发现
Kubernetes本身具有(服务器端)服务发现的能力(请参阅:kubernetes.io/docs/concepts/services-networking/service/#discovering-services)。使用本机kubernetes服务发现可确保与其他工具的兼容性,例如Istio(istio.io),该服务网具有负载平衡,功能区,断路器,故障转移等功能。
然后,调用者服务仅需要引用特定Kubernetes群集中可解析的名称。一个简单的实现可以使用一个弹簧RestTemplate来引用一个完全限定域名(FQDN),例如{service-name}.{namespace}.svc.{cluster}.local:{service-port}。
此外,您可以将Hystrix用于:
调用方的断路器实现,方法是在Spring Boot应用程序类中添加注释 @EnableCircuitBreaker
后备功能,通过使用注释相应的方法 @HystrixCommand(fallbackMethod=
- Kubernetes PropertySource实现
配置Spring Boot应用程序的最常见方法是创建一个application.propertiesor或application.yamlor application-profile.properties或application-profile.yaml文件,其中包含为应用程序或Spring Boot启动器提供自定义值的键值对。您可以通过指定系统属性或环境变量来覆盖这些属性。
5.1。用一个ConfigMap PropertySource
Kubernetes提供了一个资源ConfigMap,用于以键值对或嵌入式application.properties或application.yaml文件的形式将参数外部化以传递给您的应用程序。在春季云Kubernetes配置项目,使Kubernetes ConfigMap在应用程序引导可用实例和触发器时观察到的检测到更改热重装豆类或Spring上下文的ConfigMap实例。
默认行为是创建一个ConfigMapPropertySource基于一个Kubernetes ConfigMap具有metadata.nameSpring应用程序的任何名称的值(由它的定义spring.application.name属性)或中定义的自定义名称 bootstrap.properties下面的项下的文件: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
在前面的示例中,如果spring.cloud.kubernetes.config.namespace尚未设置,则将在应用程序运行的名称空间中查找ConfigMapnamed c1。
ConfigMap找到的所有匹配项均按以下方式处理:
应用单个配置属性。
应用yaml任何名为的属性的内容application.yaml。
将名为的任何属性的内容用作属性文件application.properties。
前述流程的唯一例外是当ConfigMap包含单个表示该文件是YAML或属性文件的键时。在那种情况下,键的名称不必是application.yaml或 application.properties(可以是任何东西),并且属性的值被正确对待。此功能有助于ConfigMap通过以下方式创建的用例:
kubectl create configmap game-config --from-file=/path/to/app-config.yaml
假设我们有一个名为Spring Boot的应用程序demo,它使用以下属性来读取其线程池配置。
pool.size.core
pool.size.maximum
可以将其外部yaml化为配置映射,格式如下:
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
pool.size.core: 1
pool.size.max: 16
在大多数情况下,单个属性都可以正常工作。但是,有时嵌入式yaml更方便。在这种情况下,我们使用一个名为的属性application.yaml来嵌入yaml,如下所示:
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
application.yaml: |-
pool:
size:
core: 1
max:16
以下示例也适用:
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
custom-name.yaml: |-
pool:
size:
core: 1
max:16
您还可以根据ConfigMap读取时合并在一起的活动配置文件来不同地配置Spring Boot应用程序。您可以通过使用application.properties或application.yaml属性,为特定配置文件提供不同的属性值 ,并在各自的文档中指定特定于配置文件的值(由—顺序指示),如下所示:
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
application.yml: |-
greeting:
message: Say Hello to the World
farewell:
message: Say Goodbye
—
spring:
profiles: development
greeting:
message: Say Hello to the Developers
farewell:
message: Say Goodbye to the Developers
—
spring:
profiles: production
greeting:
message: Say Hello to the Ops
在上述情况下,使用development概要文件加载到您的Spring Application中的配置如下:
greeting:
message: Say Hello to the Developers
farewell:
message: Say Goodbye to the Developers
但是,如果production概要文件处于活动状态,则配置将变为:
greeting:
message: Say Hello to the Ops
farewell:
message: Say Goodbye
如果两个配置文件均处于活动状态,则最后出现在该属性中的属性将ConfigMap覆盖所有先前的值。
另一个选择是为每个配置文件创建一个不同的配置映射,Spring Boot会根据活动的配置文件自动获取它
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
application.yml: |-
greeting:
message: Say Hello to the World
farewell:
message: Say Goodbye
kind: ConfigMap
apiVersion: v1
metadata:
name: demo-development
data:
application.yml: |-
spring:
profiles: development
greeting:
message: Say Hello to the Developers
farewell:
message: Say Goodbye to the Developers
kind: ConfigMap
apiVersion: v1
metadata:
name: demo-production
data:
application.yml: |-
spring:
profiles: production
greeting:
message: Say Hello to the Ops
farewell:
message: Say Goodbye
要告诉Spring Boot profile应该在引导程序中启用它,可以传递SPRING_PROFILES_ACTIVE环境变量。为此,您可以使用环境变量启动您的Spring Boot应用程序,您可以在容器规范的PodSpec中定义它。部署资源文件,如下:
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-name
labels:
app: deployment-name
spec:
replicas: 1
selector:
matchLabels:
app: deployment-name
template:
metadata:
labels:
app: deployment-name
spec:
containers:
- name: container-name
image: your-image
env:
- name: SPRING_PROFILES_ACTIVE
value: “development”
您应该检查安全性配置部分。要从Pod内部访问配置映射,您需要具有正确的Kubernetes服务帐户,角色和角色绑定。
使用ConfigMap实例的另一种选择是通过运行Spring Cloud Kubernetes应用程序并使Spring Cloud Kubernetes从文件系统读取它们,将它们安装到Pod中。此行为由spring.cloud.kubernetes.config.paths属性控制。您可以使用它作为上述机制的补充或替代。您可以spring.cloud.kubernetes.config.paths使用,定界符在其中指定多个(精确)文件路径。
您必须提供每个属性文件的完整确切路径,因为不会递归解析目录。
表1.属性:
名称 类型 默认 描述
spring.cloud.kubernetes.config.enabled
Boolean
true
启用ConfigMap PropertySource
spring.cloud.kubernetes.config.name
String
${spring.application.name}
设置ConfigMap要查找的名称
spring.cloud.kubernetes.config.namespace
String
客户端名称空间
设置Kubernetes命名空间在哪里查找
spring.cloud.kubernetes.config.paths
List
null
设置ConfigMap实例安装的路径
spring.cloud.kubernetes.config.enableApi
Boolean
true
ConfigMap通过API 启用或禁用使用实例
5.2。秘密PropertySource
Kubernetes具有用于存储敏感数据(例如密码,OAuth令牌等)的秘密的概念。该项目提供了与的集成,Secrets以使Spring Boot应用程序可以访问秘密。您可以通过设置spring.cloud.kubernetes.secrets.enabled属性来显式启用或禁用此功能。
启用后,将从以下来源SecretsPropertySource查找Kubernetes Secrets:
从秘密坐骑递归读取
以应用程序命名(由定义spring.application.name)
匹配一些标签
注意:
默认情况下,出于安全原因,未启用通过API消费机密(以上第2点和第3点)。机密上的权限“列表”允许客户端检查指定名称空间中的机密值。此外,我们建议容器通过安装的卷共享机密。
如果您通过API启用使用机密,我们建议您使用授权策略(例如RBAC)限制对机密的访问。有关通过API使用“机密”时的风险和最佳做法的更多信息,请参阅此文档。
如果找到了机密,则其数据可供应用程序使用。
假设我们有一个名为Spring Boot的应用程序demo,它使用属性读取其数据库配置。我们可以使用以下命令创建Kubernetes机密:
oc create secret generic db-secret --from-literal=username=user --from-literal=password=p455w0rd
前面的命令将创建以下秘密(您可以使用来查看oc get secrets db-secret -o yaml):
apiVersion: v1
data:
password: cDQ1NXcwcmQ=
username: dXNlcg==
kind: Secret
metadata:
creationTimestamp: 2017-07-04T09:15:57Z
name: db-secret
namespace: default
resourceVersion: “357496”
selfLink: /api/v1/namespaces/default/secrets/db-secret
uid: 63c89263-6099-11e7-b3da-76d6186905a8
type: Opaque
请注意,数据包含该create命令提供的文字的Base64编码版本。
然后,您的应用程序可以使用此秘密-例如,通过将秘密的值导出为环境变量:
apiVersion: v1
kind: Deployment
metadata:
name: ${project.artifactId}
spec:
template:
spec:
containers:
- env:
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: db-secret
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: password
您可以通过多种方式选择要使用的秘密:
通过列出映射机密的目录:
-Dspring.cloud.kubernetes.secrets.paths=/etc/secrets/db-secret,etc/secrets/postgresql
如果您已将所有机密映射到公共根,则可以将它们设置为:
-Dspring.cloud.kubernetes.secrets.paths=/etc/secrets
通过设置命名机密:
-Dspring.cloud.kubernetes.secrets.name=db-secret
通过定义标签列表:
-Dspring.cloud.kubernetes.secrets.labels.broker=activemq
-Dspring.cloud.kubernetes.secrets.labels.db=postgresql
与一样ConfigMap,在可以使用多个Secret 实例的情况下,也可以进行更高级的配置。该spring.cloud.kubernetes.secrets.sources列表使这成为可能。例如,您可以定义以下Secret实例:
spring:
application:
name: cloud-k8s-app
cloud:
kubernetes:
secrets:
name: default-name
namespace: default-namespace
sources:
# Spring Cloud Kubernetes looks up a Secret named s1 in namespace default-namespace
- name: s1
# Spring Cloud Kubernetes looks up a Secret named default-name in whatever namespace n2
- namespace: n2
# Spring Cloud Kubernetes looks up a Secret named s3 in namespace n3
- namespace: n3
name: s3
在前面的示例中,如果spring.cloud.kubernetes.secrets.namespace尚未设置,则将在应用程序运行的名称空间中查找Secretnamed s1。
表2.属性:
名称 类型 默认 描述
spring.cloud.kubernetes.secrets.enabled
Boolean
true
启用秘密 PropertySource
spring.cloud.kubernetes.secrets.name
String
${spring.application.name}
设置要查找的机密名称
spring.cloud.kubernetes.secrets.namespace
String
客户端名称空间
设置Kubernetes命名空间的查找位置
spring.cloud.kubernetes.secrets.labels
Map
null
设置用于查找机密的标签
spring.cloud.kubernetes.secrets.paths
List
null
设置安装机密的路径(示例1)
spring.cloud.kubernetes.secrets.enableApi
Boolean
false
通过API启用或禁用使用机密(示例2和3)
笔记:
该spring.cloud.kubernetes.secrets.labels属性的行为如基于Map的binding所定义 。
该spring.cloud.kubernetes.secrets.paths属性的行为与基于Collection的binding定义的行为相同 。
出于安全原因,可能会限制通过API访问机密。首选方法是将机密安装到Pod。
您可以spring-cloud-kubernetes在spring-boot-camel-config上找到使用机密(尽管尚未更新以使用新项目) 的应用程序示例。
5.3。PropertySource重装
某些应用程序可能需要检测外部属性源上的更改并更新其内部状态以反映新配置。当相关ConfigMap或 Secret更改时,Spring Cloud Kubernetes的重新加载功能能够触发应用程序重新加载。
默认情况下,此功能处于禁用状态。您可以使用spring.cloud.kubernetes.reload.enabled=true配置属性(例如,在application.properties文件中)启用它。
支持以下级别的重载(通过设置spring.cloud.kubernetes.reload.strategy属性):* refresh(默认值):仅重载带有@ConfigurationProperties或注释的配置bean @RefreshScope。此重载级别利用了Spring Cloud Context的刷新功能。* restart_context:整个Spring ApplicationContext正常重启。使用新配置重新创建Bean。* shutdown:ApplicationContext关闭Spring 以激活容器的重新启动。使用此级别时,请确保所有非守护程序线程的生命周期都已绑定到,ApplicationContext 并且已将复制控制器或副本集配置为重新启动Pod。
假设使用默认设置(refresh模式)启用了重载功能,那么当配置映射更改时,以下bean会刷新:
@组态
@ConfigurationProperties(前缀=“ bean”)
公共类MyConfig {
private String message =“可以实时更改的消息”;
// getter和setter
}
要查看更改是否有效发生,可以创建另一个bean,该bean定期打印消息,如下所示
@Component
public class MyBean {
@Autowired
private MyConfig config;
@Scheduled(fixedDelay = 5000)
public void hello() {
System.out.println("The message is: " + config.getMessage());
}
}
您可以使用来更改应用程序打印的消息ConfigMap,如下所示:
apiVersion: v1
kind: ConfigMap
metadata:
name: reload-example
data:
application.properties: |-
bean.message=Hello World!
到命名属性的任何变化bean.message在ConfigMap与吊舱相关联的被反映在输出中。更一般地说,与属性相关联的更改将以注释prefix 字段定义的值为前缀@ConfigurationProperties被检测到并反映在应用程序中。 本章前面已说明了将a ConfigMap与pod 关联。
完整的示例可在中找到spring-cloud-kubernetes-reload-example。
重新加载功能支持两种操作模式:*事件(默认):使用Kubernetes API(Web套接字)监视配置映射或机密的更改。任何事件都会对配置进行重新检查,并在发生更改的情况下重新加载。该view服务帐户的角色需要,以监听配置图的变化。edit机密需要更高级别的角色(例如)(默认情况下,机密不会受到监视)。*轮询:根据配置映射和机密信息定期重新创建配置,以查看配置是否已更改。您可以使用该spring.cloud.kubernetes.reload.period属性配置轮询时间,默认为15秒。它需要与受监视属性源相同的角色。例如,这意味着对文件挂载的秘密源使用轮询不需要特定的特权。
表3.属性:
名称 类型 默认 描述
spring.cloud.kubernetes.reload.enabled
Boolean
false
启用监视属性源和配置重载
spring.cloud.kubernetes.reload.monitoring-config-maps
Boolean
true
允许监视配置映射中的更改
spring.cloud.kubernetes.reload.monitoring-secrets
Boolean
false
允许监视机密更改
spring.cloud.kubernetes.reload.strategy
Enum
refresh
该战略烧成重载时使用(refresh,restart_context,或shutdown)
spring.cloud.kubernetes.reload.mode
Enum
event
指定如何侦听属性源(event或polling)中的更改
spring.cloud.kubernetes.reload.period
Duration
15s
使用polling策略时验证变更的期限
注意:*请勿spring.cloud.kubernetes.reload在配置映射或机密中使用属性。在运行时更改此类属性可能会导致意外结果。*使用refresh关卡时,删除属性或整个配置图不会恢复Bean的原始状态。
- Kubernetes中的功能区发现
调用微服务的Spring Cloud客户端应用程序应该对依靠客户端负载平衡功能感兴趣,以便自动发现它可以在哪个端点到达给定服务。该机制已在spring-cloud-kubernetes-ribbon项目中实现,其中Kubernetes客户端填充了一个Ribbon ServerList,其中包含有关此类端点的信息。
该实现是以下启动器的一部分,可以通过将其依赖项添加到pom文件中来使用该实现:
org.springframework.cloud spring-cloud-starter-kubernetes-ribbon ${latest.version} 填充端点列表后,Kubernetes客户端通过匹配功能区客户端注释中定义的服务名称来搜索当前名称空间或项目中存在的注册端点,如下所示:@RibbonClient(name = “name-service”)
您可以使用以下格式application.properties通过(通过应用程序专用的ConfigMap)在您的属性中提供属性来配置Ribbon的行为.ribbon.:
对应于您通过功能区访问的服务名称,该名称是使用@RibbonClient注释配置的 (例如,name-service在前面的示例中)。
是Ribbon的CommonClientConfigKeyclass定义的Ribbon配置键之一 。
此外,该spring-cloud-kubernetes-ribbon项目定义了两个附加的配置键,以进一步控制Ribbon与Kubernetes的交互方式。特别是,如果端点定义了多个端口,则默认行为是使用找到的第一个端口。要更具体地选择在多端口服务中使用哪个端口,可以使用PortName键。如果您想指定应在哪个Kubernetes命名空间中查找目标服务,则可以使用该KubernetesNamespace密钥,在这两个实例中都记住要为这些密钥加上您的服务名称和 ribbon前缀(如前所述)。
表4. Spring Cloud Kubernetes功能区配置
属性键 类型 默认值
spring.cloud.kubernetes.ribbon.enabled
布尔值
真正
spring.cloud.kubernetes.ribbon.mode
KubernetesRibbonMode
荚
spring.cloud.kubernetes.ribbon.cluster-domain
串
cluster.local
spring.cloud.kubernetes.ribbon.mode支持POD和SERVICE模式。
POD模式是通过获取Kubernetes的Pod IP地址并使用功能区来实现负载平衡的。POD模式使用功能区的负载平衡不支持Kubernetes负载平衡,不支持的流量策略Istio。
该SERVICE模式直接基于service name功能区的。获取Kubernetes服务分为以下几种service-name.{namespace}.svc.{cluster.domain}:{port}:demo1.default.svc.cluster.local:8080。该SERVICE模式使用Kubernetes服务的负载平衡来支持Istio的流量策略。
spring.cloud.kubernetes.ribbon.cluster-domain设置自定义Kubernetes集群域后缀。默认值为:“ cluster.local”
以下示例使用此模块进行功能区发现:
弹簧云断路器和功能区
fabric8-quickstarts-弹簧靴-功能区
Kubeflix-贷款经纪人-银行
您可以通过spring.cloud.kubernetes.ribbon.enabled=false在应用程序属性文件中设置密钥来禁用功能区发现客户端。
7. Kubernetes生态系统意识
无论您的应用程序是否在Kubernetes中运行,本指南前面介绍的所有功能都可以很好地工作。这对于开发和故障排除确实很有帮助。从开发角度来看,这使您可以启动Spring Boot应用程序并调试属于该项目的模块之一。您无需将其部署在Kubernetes中,因为该项目的代码依赖于 Fabric8 Kubernetes Java客户端,它是一种流利的DSL,可以通过使用http协议与Kubernetes Server的REST API进行通信。
要禁用与Kubernetes的集成,可以设置spring.cloud.kubernetes.enabled为false。请注意,当spring-cloud-kubernetes-config在classpath上时, spring.cloud.kubernetes.enabled应在bootstrap.{properties|yml}(或配置文件专用的)中设置,否则应在application.{properties|yml}(或配置文件专用的)中设置。还要注意的是,这些特性:spring.cloud.kubernetes.config.enabled和spring.cloud.kubernetes.secrets.enabled才生效时集bootstrap.{properties|yml}
7.1。Kubernetes配置文件自动配置
当应用程序在Kubernetes中作为pod运行时,名为的Spring配置文件会kubernetes自动激活。这使您可以自定义配置,以定义在Kubernetes平台中部署Spring Boot应用程序时要应用的bean(例如,不同的开发和生产配置)。
7.2。Istio意识
当包括spring-cloud-kubernetes-istio在应用程序的类路径模块,新的配置文件添加到应用程序,提供的应用运行在Kubernetes集群里面Istio安装。然后,您可以@Profile(“istio”)在Bean和@Configuration类中使用spring 注释。
Istio感知模块用于me.snowdrop:istio-client与Istio API进行交互,使我们能够发现流量规则,断路器等,从而使我们的Spring Boot应用程序可以轻松使用此数据,以根据环境动态配置自身。
8.豆荚健康指标
Spring Boot用于HealthIndicator公开有关应用程序运行状况的信息。这对于将与健康相关的信息提供给用户非常有用,并且非常适合用作就绪探针。
Kubernetes运行状况指示器(是核心模块的一部分)公开以下信息:
窗格名称,IP地址,名称空间,服务帐户,节点名称及其IP地址
一个标志,指示Spring Boot应用程序在Kubernetes内部还是外部
9.领导人选举
<待定>
-
Kubernetes内部的安全配置
10.1。命名空间
该项目中提供的大多数组件都需要知道名称空间。对于Kubernetes(1.3+),名称空间作为服务帐户密码的一部分可供Pod使用,并由客户端自动检测到。对于早期版本,需要将其指定为Pod的环境变量。一种快速的方法如下:env:
- name: “KUBERNETES_NAMESPACE”
valueFrom:
fieldRef:
fieldPath: “metadata.namespace”
10.2。服务帐号
对于支持集群内基于角色的更细粒度访问的Kubernetes发行版,您需要确保与之一起运行的Pod spring-cloud-kubernetes有权访问Kubernetes API。对于您分配给部署或Pod的任何服务帐户,您需要确保它们具有正确的角色。
- name: “KUBERNETES_NAMESPACE”
根据要求,你需要get,list并watch在以下资源权限:
表5. Kubernetes资源权限
相依性 资源资源
spring-cloud-starter-kubernetes
吊舱,服务,端点
spring-cloud-starter-kubernetes-config
configmaps,秘密
Spring-Cloud-Starter-Kubernetes-功能区
吊舱,服务,端点
出于开发目的,您可以cluster-reader向default服务帐户添加权限。在生产系统上,您可能需要提供更精细的权限。
以下Role和RoleBinding是该default帐户的命名空间权限的示例:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: YOUR-NAME-SPACE
name: namespace-reader
rules:
- apiGroups: ["", “extensions”, “apps”]
resources: [“configmaps”, “pods”, “services”, “endpoints”, “secrets”]
verbs: [“get”, “list”, “watch”]
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: namespace-reader-binding
namespace: YOUR-NAME-SPACE
subjects:
- kind: ServiceAccount
name: default
apiGroup: “”
roleRef:
kind: Role
name: namespace-reader
apiGroup: “”
11.服务注册中心的实施
在Kubernetes服务注册由平台控制的情况下,应用程序本身不像其他平台那样控制注册。因此,使用spring.cloud.service-registry.auto-registration.enabled 或设置@EnableDiscoveryClient(autoRegister=false)在Spring Cloud Kubernetes中无效。
12.例子
Spring Cloud Kubernetes尝试通过遵循Spring Cloud接口使应用程序使用Kubernetes Native Services透明化。
在您的应用程序中,您需要将spring-cloud-kubernetes-discovery依赖项添加到类路径中,并删除任何其他包含DiscoveryClient实现的依赖项(即Eureka发现客户端)。这同样适用于PropertySourceLocator,您需要在的类路径中添加spring-cloud-kubernetes-config并删除包含PropertySourceLocator实现(即配置服务器客户端)的任何其他依赖项。
以下项目重点介绍了这些依赖项的用法,并演示了如何从任何Spring Boot应用程序中使用这些库:
Spring Cloud Kubernetes示例:位于此存储库中的示例。
Spring Cloud Kubernetes完整示例:奴才和上司
奴才
老板
Spring Cloud Kubernetes完整示例:SpringOne Platform Tickets Service
具有Spring Cloud Kubernetes发现和配置的Spring Cloud Gateway
使用Spring Cloud Kubernetes发现和配置进行Spring Boot Admin
13.其他资源
本节列出了其他资源,例如有关Spring Cloud Kubernetes的演示(幻灯片)和视频。
PKS上的S1P Spring Cloud
Spring Cloud,Docker,Kubernetes→伦敦Java社区2018年7月
请随时通过拉取请求向此存储库提交其他资源。
14.配置属性
要查看所有与Sleuth相关的配置属性的列表,请检查附录页面。
15.建筑
15.1。基本编译和测试
要构建源代码,您将需要安装JDK 1.7。
Spring Cloud使用Maven进行大多数与构建相关的活动,并且您应该能够通过克隆您感兴趣的项目并键入来快速启动
$ ./mvnw安装
您还可以自己安装Maven(> = 3.3.3)并在以下示例mvn中代替./mvnw该位置运行命令。如果这样做,-P spring则如果本地Maven设置不包含Spring预发行项目的存储库声明,则可能还需要添加。
请注意,通过将MAVEN_OPTS环境变量设置为,可能需要增加Maven可用的内存量-Xmx512m -XX:MaxPermSize=128m。我们尝试在.mvn配置中进行介绍,因此,如果您发现必须进行此操作才能使构建成功,请提出票证以将设置添加到源代码管理中。
有关如何构建项目的提示,请查看.travis.yml是否存在。应该有一个“脚本”,也许还有“安装”命令。另外,请查看“服务”部分,以查看是否需要在本地运行任何服务(例如mongo或Rabbit)。忽略您可能在“ before_install”中找到的与git相关的位,因为它们与设置git凭据有关,并且您已经拥有了这些凭据。
需要中间件的项目通常包括 docker-compose.yml,因此请考虑使用 Docker Compose在Docker容器中运行中间件服务器。有关mongo,rabbit和redis常见情况的特定说明,请参见脚本演示存储库中的README 。
如果其他所有方法均失败,则使用.travis.yml(通常为 ./mvnw install)命令进行构建。
15.2。文献资料
spring-cloud-build模块有一个“ docs”配置文件,如果您打开它,将尝试从中构建asciidoc源 src/main/asciidoc。作为该过程的一部分,它将查找 README.adoc并通过加载所有包含项来对其进行处理,但不对其进行解析或渲染,只需将其复制到
m
a
i
n
.
b
a
s
e
d
i
r
(
默
认
为
{main.basedir} (默认为
main.basedir(默认为{basedir},即项目的根目录)即可。如果自述文件有任何更改,它将在Maven构建后显示为正确位置的已修改文件。只需提交并推动更改即可。
15.3。使用代码
如果您没有IDE偏好设置,我们建议您在使用代码时使用 Spring Tools Suite或 Eclipse。我们使用 m2eclipse eclipse插件来获得maven支持。只要其他IDE和工具使用Maven 3.3.3或更高版本,它们也应该可以正常工作。
15.3.1。使用m2eclipse导入eclipse
当使用eclipse时,我们建议使用m2eclipse eclipse插件。如果尚未安装m2eclipse,则可以从“ eclipse市场”中获得。
较旧的m2e版本不支持Maven 3.3,因此,一旦将项目导入Eclipse,您还需要告诉m2eclipse为项目使用正确的配置文件。如果您在项目中看到许多与POM相关的错误,请检查您是否具有最新的安装。如果您无法升级m2e,请在您的中添加“ spring”配置文件settings.xml。或者,您可以将存储库设置从父pom的“ spring”配置文件复制到settings.xml。
15.3.2。不使用m2eclipse导入eclipse
如果您不想使用m2eclipse,则可以使用以下命令生成eclipse项目元数据:
$ ./mvnw eclipse:eclipse
可以通过import existing projects 从file菜单中选择导入生成的Eclipse项目。
16.贡献
Spring Cloud是在非限制性Apache 2.0许可下发布的,并遵循非常标准的Github开发流程,使用Github跟踪程序解决问题并将合并请求合并到master中。如果您想贡献些微不足道的东西,请不要犹豫,但请遵循以下准则。
16.1。签署贡献者许可协议
在我们接受不重要的补丁或请求请求之前,我们将需要您签署“ 贡献者许可协议”。签署贡献者协议并不会授予任何人对主存储库的提交权,但这确实意味着我们可以接受您的贡献,如果这样做,您将获得作者的荣誉。可能会要求活跃的贡献者加入核心团队,并具有合并合并请求的能力。
16.2。行为守则
该项目遵守《贡献者公约》行为守则。通过参与,您将遵守此代码。请向spring-code-of-conduct@pivotal.io报告不可接受的行为。
16.3。规范和内务守则
对于拉取请求,这些都不是必不可少的,但它们都会有所帮助。也可以在原始请求请求之后但在合并之前添加它们。
使用Spring Framework代码格式约定。如果您使用Eclipse,则可以使用Spring Cloud Build项目中的eclipse-code-formatter.xml文件 导入格式化程序设置 。如果使用IntelliJ,则可以使用 Eclipse Code Formatter插件来导入相同的文件。
确保所有新.java文件都具有简单的Javadoc类注释,其中至少包含一个@author用于标识您的 标签,并且最好至少包含有关该类用途的段落。
将ASF许可证标头注释添加到所有新.java文件(从项目中的现有文件复制)
将您自己添加为@author您进行了实质性修改(不只是外观更改)的.java文件。
添加一些Javadocs,如果更改名称空间,则添加一些XSD doc元素。
进行一些单元测试也有很大帮助-有人必须这样做。
如果没有其他人在使用您的分支,请根据当前的主节点(或主项目中的其他目标分支)对其进行重新设置。
编写提交消息时,请遵循以下约定,如果要解决现有问题,请Fixes gh-XXXX在提交消息的末尾添加(其中XXXX是问题编号)。
16.4。Checkstyle
Spring Cloud Build带有一组checkstyle规则。您可以在spring-cloud-build-tools模块中找到它们。该模块下最值得注意的文件是:
spring-cloud-build-tools /
└──src
├──格纹
│└──checkstyle-suppressions.xml
└──主要
└──资源
├──checkstyle-header.txt
└──checkstyle.xml
默认Checkstyle规则
文件头设置
默认抑制规则
16.4.1。Checkstyle配置
Checkstyle规则默认为禁用。要将checkstyle添加到项目中,只需定义以下属性和插件。
pom.xml
<属性>
<maven-checkstyle-plugin.failsOnError> true </maven-checkstyle-plugin.failsOnError>
<maven-checkstyle-plugin.failsOnViolation>是
</maven-checkstyle-plugin.failsOnViolation>
<maven-checkstyle-plugin.includeTestSourceDirectory> true
</maven-checkstyle-plugin.includeTestSourceDirectory>
</ properties>
<内部版本>
<插件>
<插件>
io.spring.javaformat </ groupId>
spring-javaformat-maven-plugin </ artifactId>
</ plugin>
<插件>
org.apache.maven.plugins </ groupId>
maven-checkstyle-plugin </ artifactId>
</ plugin>
</ plugins>
<报告>
<插件>
<插件>
<groupId> org.apache.maven.plugins </ groupId>
<artifactId> maven-checkstyle-plugin </ artifactId>
</ plugin>
</ plugins>
</ reporting>
</ build>
因Checkstyle错误而无法构建
因Checkstyle违规而无法构建
Checkstyle还分析测试源
添加Spring Java Format插件,该插件将重新格式化您的代码以通过大多数Checkstyle格式化规则
将Checkstyle插件添加到您的构建和报告阶段
如果您需要取消某些规则(例如,行长需要更长),那么您就可以通过${project.root}/src/checkstyle/checkstyle-suppressions.xml取消操作来定义一个文件。例:
projectRoot / src / checkstyle / checkstyle-suppresions.xml
<?xml version =“ 1.0”?>
<!DOCTYPE禁止发布
“-//小狗爬网// DTD抑制1.1 // EN”
“ https://www.puppycrawl.com/dtds/suppressions_1_1.dtd“>
<抑制>
<suppress files =“。* ConfigServerApplication \ .java” checks =“ HideUtilityClassConstructor” />
<suppress files =“。* ConfigClientWatch \ .java” checks =“ LineLengthCheck” />
</ suppressions>
建议将
s
p
r
i
n
g
−
c
l
o
u
d
−
b
u
i
l
d
.
r
o
o
t
F
o
l
d
e
r
/
.
e
d
i
t
o
r
c
o
n
f
i
g
和
复
制
{spring-cloud-build.rootFolder}/.editorconfig和复制
spring−cloud−build.rootFolder/.editorconfig和复制{spring-cloud-build.rootFolder}/.springformat到您的项目中。这样,将应用一些默认格式设置规则。您可以通过运行以下脚本来这样做:
$ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/.editorconfig -o .editorconfig
$ touch .springformat
16.5。IDE设置
16.5.1。Intellij IDEA
为了设置Intellij,您应该导入我们的编码约定,检查配置文件并设置checkstyle插件。在Spring Cloud Build项目中可以找到以下文件。
spring-cloud-build-tools /
└──src
├──格纹
│└──checkstyle-suppressions.xml
└──主要
└──资源
├──checkstyle-header.txt
├──checkstyle.xml
└──intellij
├──Intellij_Project_Defaults.xml
└──Intellij_Spring_Boot_Java_Conventions.xml
默认Checkstyle规则
文件头设置
默认抑制规则
适用于大多数Checkstyle规则的Intellij项目默认值
适用于大多数Checkstyle规则的Intellij的项目样式约定
代码风格
图1.代码样式
进入File→交通Settings→交通Editor→交通Code style。单击该Scheme部分旁边的图标。在那里,单击Import Scheme值并选择Intellij IDEA code style XML选项。导入spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml文件。
代码风格
图2.检查配置文件
进入File→交通Settings→交通Editor→交通Inspections。单击该Profile部分旁边的图标。在那里,单击Import Profile并导入spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml文件。
Checkstyle
要使Intellij与Checkstyle一起使用,您必须安装Checkstyle插件。建议还安装Assertions2Assertj来自动转换JUnit断言
Checkstyle
进入File→交通Settings→交通Other settings→交通Checkstyle。单击+该Configuration file部分中的图标。在这里,您必须定义应从何处选择checkstyle规则。在上图中,我们从克隆的Spring Cloud Build存储库中选择了规则。但是,您可以指向春云构建计划的GitHub的库(例如用于checkstyle.xml:raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-build-tools/src/main/resources/checkstyle.xml)。我们需要提供以下变量:
checkstyle.header.file-请指向spring-cloud-build-tools/src/main/resources/checkstyle-header.txt克隆存储库中或通过raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-build-tools/src/main/resources/checkstyle-header.txtURL 的Spring Cloud Build 文件。
checkstyle.suppressions.file-默认抑制。请将其指向spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml您的克隆存储库中或通过raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xmlURL 的Spring Cloud Build的文件。
checkstyle.additional.suppressions.file-此变量对应于本地项目中的抑制。例如,您正在努力spring-cloud-contract。然后指向该project-root/src/checkstyle/checkstyle-suppressions.xml文件夹。的示例为spring-cloud-contract:/home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml。