4.12. 为客户端连接配置基于 Operator 的代理部署
4.12.1. 配置接收器 复制链接链接已复制到粘贴板!
要在 OpenShift 部署中启用到代理 pod 的客户端连接,您可以为部署定义 acceptors。acceptors 定义代理 pod 如何接受连接。您可以在用于代理部署的主自定义资源(CR)中定义 acceptors。当您创建 acceptor 时,您可以指定要在接收器上启用的消息传递协议等信息,以及代理 pod 上用于这些协议的端口。
流程
-
编辑代理部署的
ActiveMQArtemis自定义资源(CR)。 在
acceptors属性中,添加 named acceptor。添加protocols和port属性。设置值,以指定接受者和每个代理 pod 上的端口用于这些协议的消息传递协议。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置的接收器将端口 5672 公开给 AMQP 客户端。下表中显示了您可以为 protocol 属性指定的完整值集。
Expand 表 4.4. acceptor 协议 协议 值 核心协议
coreAMQP
amqpOpenWire
OpenWireMQTT
mqttSTOMP
stomp所有支持的协议
all注意- 对于部署中的每个代理 pod,Operator 还会创建一个使用端口 61616 的默认接收器。代理集群需要这个默认接受器,并启用了核心协议。
- 默认情况下,AMQ Broker 管理控制台使用代理 pod 上的端口 8161。部署中的每个代理 pod 都有一个专用的服务,它提供对控制台的访问。如需更多信息,请参阅 第 5 章 连接到基于 Operator 的代理部署的 AMQ 管理控制台。
要在同一个接收器中使用另一个协议,请修改 protocol 属性。
指定以逗号分隔的协议列表。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置的接收器现在向 AMQP 和 OpenWire 客户端公开端口 5672。
要指定接受者允许的并发客户端连接数量,请添加
connectionsAllowed属性并设置值。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 默认情况下,acceptor 仅公开给与代理部署相同的 OpenShift 集群中的客户端。要同时将 acceptor 公开给 OpenShift 之外的客户端,请将
expose属性和sslEnabled属性设置为true。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当您在接受器(或连接器)上启用 SSL (安全套接字层)安全性时,您可以添加相关的配置,例如:
- 用于在 OpenShift 集群中存储身份验证凭据的机密名称。当您在 acceptor 上启用 SSL 时,需要一个 secret。
-
用于保护网络通信的传输层安全性(TLS)协议。TLS 是一个更新的、更加安全的 SSL 版本。您可以在
enabledProtocols属性中指定 TLS 协议。 -
acceptor 是否在代理和客户端之间使用 mTLS (也称为 mutual 身份验证)。您可以通过将
needClientAuth属性的值设置为true来指定此值。
有关这些任务的详情,请参考 第 4.12.2 节 “保护 broker-client 连接”。
当您向 OpenShift 外部的客户端公开接受者时,Operator 会自动为部署中的每个代理 pod 上的接受器创建一个专用服务和 Openshift 路由。
如果要自定义每个 pod 上为接收器公开的路由的主机名,以匹配 Openshift 集群中的内部路由配置,您可以执行以下操作之一或两者:
-
使用
ingressHost属性将默认主机名替换为特定接收器的自定义主机名。 使用
ingressDomain属性将自定义域附加到主机名中。自定义域也应用于由 CR 配置公开的所有其他路由,如其他接受器和控制台的路由。要为 acceptor 路由设置自定义主机名,请添加
ingressHost属性并指定主机字符串。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意ingressHost值在 Openshift 集群中必须是唯一的。如果您的代理集群有多个代理 pod,您可以通过在值中包含 $(BROKER_ORDINAL)变量来使ingressHost值是唯一的。Operator 将每个代理 pod 上的此变量替换为分配给 pod 的 StatefulSet 编号。例如,在第一个 pod上,my-acceptor-$(BROKER_ORDINAL)-production.my-subdomain.com的ingressHost值将路由的主机名设置为。my-acceptor-0-production.my-subdomain您可以在自定义主机名字符串中为 acceptor 路由包含以下变量:
Expand 表 4.5. 自定义主机名字符串中的变量用于 acceptor 路由 Name 描述 $(CR_NAME)
CR 中的
metadata.name属性的值。$(CR_NAMESPACE)
自定义资源的命名空间。
$(BROKER_ORDINAL)
StatefulSet 分配给代理 pod 的普通数量。
$(ITEM_NAME)
接受者的名称。
$(RES_TYPE)
资源类型。路由具有
rte资源类型。入口的资源类型为ing。$(INGRESS_DOMAIN)
如果在 CR 中配置,
spec.ingressDomain属性的值。要将自定义域附加到路由中的主机名中,请添加
spec.ingressDomain属性并指定自定义字符串。例如:spec: ... ingressDomain: my.domain.com
spec: ... ingressDomain: my.domain.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
使用
如果机构的网络策略要求您使用 ingress 而不是路由公开接收器,请完成以下步骤:
添加
exposeMode属性,并将值设为ingress。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果要自定义为接受者公开的入口主机名,以匹配 Openshift 集群中的内部路由配置,您可以执行以下操作之一或两者:
-
使用
ingressHost属性将默认主机名替换为自定义主机名。 使用
ingressDomain属性将自定义域附加到主机名中。自定义域也应用于 CR 配置公开的所有其他入口(如其他接收器和控制台的 ingress)。要为 acceptor 的 ingresses 设置自定义主机名,请添加
ingressHost属性并指定主机字符串。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以包括相同的变量来自定义入口主机作为路由主机,如此流程前面所述。
要将自定义域附加到 ingresses 中的主机名,请添加
spec.ingressDomain属性并指定自定义字符串。例如:spec: ... ingressDomain: my-subdomain.domain.com
spec: ... ingressDomain: my-subdomain.domain.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 对于 acceptors,ingress 的默认主机名采用 <
cr-name>-<acceptor name>-<ordinal>-svc-ing-<namespace> 的格式。例如,如果您在amqbroker命名空间中有一个名为production的 CR,则ingressDomain值mydomain.com会为 Pod 0 上创建的 ingress 提供主机值production-wconsj-0-svc-ing-mynamespace.amqbroker.com。
-
使用
其他资源
- 要了解如何配置 TLS 来保护 broker-client 连接,包括生成用于存储身份验证凭证的 secret,请参阅 第 4.12.2 节 “保护 broker-client 连接”。
- 有关完整的自定义资源配置参考,包括接收器和连接器的配置,请参阅 第 8.1 节 “自定义资源配置参考”。
4.12.2. 保护 broker-client 连接 复制链接链接已复制到粘贴板!
如果您在接收器或连接器上启用了安全性(即,将 sslEnabled 设置为 true),您必须配置传输层安全(TLS)以允许代理和客户端之间的基于证书的身份验证。TLS 是一个更新的、更加安全的 SSL 版本。主要 TLS 配置有两个:
- TLS
- 只有代理会显示证书。客户端使用证书来验证代理。这是最常见的配置。
- mTLS
- 代理和客户端都提供证书。这有时被称为 mutual 身份验证。
您可以使用各种方法生成 TLS 证书。
如果代理和客户端在同一 Openshift 集群上运行,您可以使用 Openshift 为代理生成服务证书。
如果代理和客户端没有在同一 Openshift 集群上运行,则必须使用允许您自定义证书的方法生成证书。本节论述了可以用来生成自定义证书的两种方法:
- 用于 Openshift 的 cert-manager Operator
- Java Keytool 工具.
4.12.2.1. 使用 Openshift 服务服务证书 复制链接链接已复制到粘贴板!
如果要保护同一 Openshift 集群中的代理和客户端之间的内部连接,您可以在 acceptor 服务中添加注解来请求 Openshift 生成服务证书。生成的证书和密钥采用 PEM 格式,分别存储在所创建 secret 的 tls.crt 和 tls.key 中。
用于发布服务证书的服务 CA 证书在 26 个月内有效,并在有效期少于 13 个月时进行自动轮转。轮转后,以前的服务 CA 配置仍会被信任直到其过期为止。这将为所有受影响的服务建立一个宽限期,以在过期前刷新其密钥内容。如果没有在这个宽限期内对集群进行升级(升级会重启服务并刷新其密钥),您可能需要手动重启服务以避免在上一个服务 CA 过期后出现故障。
流程
-
编辑用于代理部署的
ActiveMQArtemis自定义资源(CR)。 使用
resourceTemplates属性来注解为接收器创建的服务。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - resourceTemplates.selector.kind
-
指定自定义应用到的资源类型是
Service。 - resourceTemplates.selector.name
指定要应用注解的服务名称。acceptor 服务的名称格式为: <
CR name><acceptor name><ordinal>-svc,其中:-
<CR name> name 是 CR 中的
metadata.name属性的值。 -
<acceptor name> 是接受者的名称。示例假定接受者的名称为
myacceptor。 - <ordinal> 是 StatefulSet 分配给代理 pod 的普通号。
-
<CR name> name 是 CR 中的
- resourceTemplates.annotations
指定
service.beta.openshift.io/serving-cert-secret-name: <secret> 的注解,其中< secret > 是 Openshift 为服务创建的 secret 的名称。注意secret 名称必须与 acceptor 名称匹配,并且具有
-ptls后缀。需要特定的后缀,以允许 Operator 在创建 secret 前部署 CR。
在 CR 中的 sslSecret' 属性中,指定包含代理证书的 secret。例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
brokerProperties属性中,将代理配置为在每次在 Openshift 中续订证书时自动加载新证书。例如:spec: ... brokerProperties - "acceptorConfigurations.myacceptor.params.sslAutoReload=true" ...
spec: ... brokerProperties - "acceptorConfigurations.myacceptor.params.sslAutoReload=true" ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 将服务用证书的公钥添加到每个客户端的信任存储中。
如果要在代理和客户端之间配置 mTLS 身份验证,请完成以下步骤。
-
创建一个信任捆绑包,其中包含您希望代理信任的每个客户端证书,并将信任捆绑包添加到 secret 中,例如
trusted-clients-bundle。 在代理 CR 中配置的 acceptors 中,添加
needClientAuth属性,并设置为true以要求客户端身份验证。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在每个 acceptor 的
trustSecret属性中,指定包含客户端证书信任捆绑包的 secret。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
创建一个信任捆绑包,其中包含您希望代理信任的每个客户端证书,并将信任捆绑包添加到 secret 中,例如
- 保存 CR。
其他资源
4.12.2.2. 为 Openshift 使用 cert-manager Operator 复制链接链接已复制到粘贴板!
OpenShift 的 cert-manager Operator 是一个集群范围的服务,提供应用程序证书生命周期管理。cert-manager 会自动管理,并从各种证书颁发机构隔离 TLS 证书。
以下示例演示了如何使用自签名证书配置传输层安全(TLS)。如果您的策略需要由可识别的证书管理器签名的证书,您可以使用 OpenShift 的 cert-manager Operator 请求证书。
先决条件
已安装 cert-manager Operator for Red Hat OpenShift。
如需更多信息,请参阅 OpenShift Container Platform 文档中的 为 Red Hat OpenShift 安装 cert-manager Operator。
如果要在代理和客户端之间配置 mTLS,则安装 Kubernetes 的信任管理器。
如需更多信息,请参阅安装 trust-manager。
流程
创建一个 YAML 文件,如
self-signed-issuer.yaml,该文件定义 root 自签名签发者。签发者( issuer)是一个 Openshift 资源,它代表证书颁发机构(CA),它可以通过遵循证书签名请求来生成签名证书。以下示例 yaml 创建一个自签名签发者,然后使用该签发者创建证书颁发机构(CA)证书。您的 CA 证书可由 cert-manager Operator 管理。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个 YAML 文件,如
root-ca.yaml,用于定义 root CA 证书。在
issuerRef.name字段中,指定您创建的自签名签发者(root-issuer)的名称。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 证书以 Privacy Enhanced Mail (PEM)格式创建,格式为
root-ca-secret。创建一个 YAML 文件,如
root-ca-issuer.yaml,该文件定义了发布由 root CA 签名的证书的 CA 签发者。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建定义代理证书的 YAML 文件,如
broker-cert.yaml。在
issuerRef.Name字段中,指定您创建用来发布由 root CA 签名的证书的签发者名称root-ca-issuer。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 部署您在 YAML 文件中为签发者和证书定义的自定义资源,以创建对应的 OpenShift 对象。例如:
oc create -f self-signed-issuer.yaml oc create -f root-ca.yaml oc create -f root-ca-issuer.yaml oc create -f broker-cert.yaml
$ oc create -f self-signed-issuer.yaml $ oc create -f root-ca.yaml $ oc create -f root-ca-issuer.yaml $ oc create -f broker-cert.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
编辑用于代理部署的
ActiveMQArtemisCR。 指定在您要保护的每个接受者的
sslSecret属性中包含代理证书的 secret。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
brokerProperties属性中,将代理配置为在每次为 Openshift 的 cert-manager Operator 更新证书时自动加载接受者的新代理证书。例如:spec: ... brokerProperties - "acceptorConfigurations.new-acceptor.params.sslAutoReload=true" ...
spec: ... brokerProperties - "acceptorConfigurations.new-acceptor.params.sslAutoReload=true" ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
向每个客户端的信任存储中添加签名代理证书的 root CA 证书,该证书在本示例过程中创建一个名为
root-ca-secretsecret 的 secret 中,以便客户端可以信任代理。 如果要在代理和客户端之间配置 mTLS 身份验证,请完成以下步骤。
-
使用 Trust Manager for Kubernetes 创建一个信任捆绑包,其中包含您希望代理信任的每个客户端证书,并将信任捆绑包添加到 secret 中,如
trusted-clients-bundle。有关如何创建信任捆绑包的详情,请参考 trust-manager 文档。 在代理 CR 中配置的 acceptors 中,添加
needClientAuth属性,并设置为true以要求客户端身份验证。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在每个 acceptor 的
trustSecret属性中,指定包含客户端证书信任捆绑包的 secret。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
使用 Trust Manager for Kubernetes 创建一个信任捆绑包,其中包含您希望代理信任的每个客户端证书,并将信任捆绑包添加到 secret 中,如
- 保存 CR。
4.12.2.3. 使用 Java keytool 工具 复制链接链接已复制到粘贴板!
keytool 是 Java 中包含的证书管理实用程序。
4.12.2.3.1. 配置单向 TLS 复制链接链接已复制到粘贴板!
本节中的步骤演示了如何配置单向传输层安全(TLS)来保护 broker-client 连接。
在单向 TLS 中,只有代理会显示证书。此证书供客户端用来验证代理。
先决条件
- 当客户端使用主机名验证时,您应该了解代理证书生成的要求。更多信息请参阅 第 4.12.2.4 节 “为主机名验证配置代理证书”。
流程
为代理密钥存储生成自签名证书。
keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ksCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从代理密钥存储导出证书,以便它可以与客户端共享。以 Base64 编码的
.pem格式导出证书。例如:keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在客户端上,创建导入代理证书的客户端信任存储。
keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以管理员身份登录 OpenShift Container Platform。例如:
oc login -u system:admin
$ oc login -u system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow 切换到包含代理部署的项目。例如:
oc project <my_openshift_project>
$ oc project <my_openshift_project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建用于存储 TLS 凭据的机密。例如:
oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/client.ks \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
$ oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/client.ks \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意在生成 secret 时,OpenShift 需要同时指定密钥存储和信任存储。信任存储密钥通常被命名为
client.ts。对于代理和客户端之间的单向 TLS,实际上不需要信任存储。但是,若要成功生成 secret,您需要将 一些 有效的存储文件指定为client.ts的值。上一步为client.ts提供"dummy"值,方法是重新使用之前生成的代理密钥存储文件。这足以生成一个 secret,其中包含单向 TLS 所需的所有凭证。将 secret 链接到安装 Operator 时创建的服务帐户。例如:
oc secrets link sa/amq-broker-operator secret/my-tls-secret
$ oc secrets link sa/amq-broker-operator secret/my-tls-secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在安全接收器或连接器的
sslSecret参数中指定 secret 名称。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.12.2.3.2. 配置双向 TLS 复制链接链接已复制到粘贴板!
本节中的步骤演示了如何配置双向传输层安全(TLS)来保护 broker-client 连接。
在双向 TLS 中,代理和客户端都提供证书。代理和客户端使用这些证书在进程中相互验证,有时被称为 mutual 身份验证。
先决条件
- 当客户端使用主机名验证时,您应该了解代理证书生成的要求。更多信息请参阅 第 4.12.2.4 节 “为主机名验证配置代理证书”。
流程
为代理密钥存储生成自签名证书。
keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ksCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从代理密钥存储导出证书,以便它可以与客户端共享。以 Base64 编码的
.pem格式导出证书。例如:keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在客户端上,创建导入代理证书的客户端信任存储。
keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在客户端上,为客户端密钥存储生成自签名证书。
keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ksCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在客户端上,从客户端密钥存储导出证书,以便它可以与代理共享。以 Base64 编码的
.pem格式导出证书。例如:keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
$ keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建导入客户端证书的代理信任存储。
keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
$ keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以管理员身份登录 OpenShift Container Platform。例如:
oc login -u system:admin
$ oc login -u system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow 切换到包含代理部署的项目。例如:
oc project <my_openshift_project>
$ oc project <my_openshift_project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建用于存储 TLS 凭据的机密。例如:
oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/broker.ts \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
$ oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/broker.ts \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意在生成 secret 时,OpenShift 需要同时指定密钥存储和信任存储。信任存储密钥通常被命名为
client.ts。对于代理和客户端之间的双向 TLS,您必须生成一个包含代理信任存储的 secret,因为这会包含客户端证书。因此,在前面的步骤中,您为client.ts键指定的值实际上是 代理 信任存储文件。将 secret 链接到安装 Operator 时创建的服务帐户。例如:
oc secrets link sa/amq-broker-operator secret/my-tls-secret
$ oc secrets link sa/amq-broker-operator secret/my-tls-secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在安全接收器或连接器的
sslSecret参数中指定 secret 名称。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.12.2.4. 为主机名验证配置代理证书 复制链接链接已复制到粘贴板!
本节论述了在配置单向或双向 TLS 时必须生成的代理证书的一些要求。
当客户端尝试连接到部署中的代理 Pod 时,客户端连接 URL 中的 verifyHost 选项决定客户端是否将代理证书的通用名称(CN)与主机名进行比较,以验证它们是否匹配。如果您指定了 verifyHost=true,或者在客户端连接 URL 中类似,客户端会执行此验证。
在罕见的情况下,您可能会省略这个验证,当您对连接的安全性无关,例如,如果在隔离的网络中的 OpenShift 集群上部署代理时,可能会省略这个验证。否则,对于安全连接,建议客户端执行此验证。在这种情况下,正确配置代理密钥存储证书是确保成功客户端连接所必需的。
通常,当客户端使用主机验证时,您在生成代理证书时指定的 CN 必须与客户端连接到的代理 Pod 上 Route 的完整主机名匹配。例如,如果您使用单个代理 Pod 部署,则 CN 可能类似如下:
CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
为确保 CN 可以解析带有多个代理的的代理 Pod 中的任何代理,您可以指定一个星号(*)通配符字符来代替普通的代理 Pod。例如:
CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
上例中显示的 CN 可以成功解析为 my-broker-deployment 部署中的任何代理 Pod。
另外,您在生成代理证书时指定的 Subject Alternative Name (SAN) 必须单独列出 部署中的所有代理 Pod,作为逗号分隔的列表。例如:
"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."
"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."
4.12.3. 代理部署中的网络服务 复制链接链接已复制到粘贴板!
在代理部署的 OpenShift Container Platform Web 控制台的 Networking 窗格中,有两个运行的服务: 无头服务 和 ping 服务。无头服务的默认名称使用 < custom_resource_name> -hdls-svc 的格式,如 my-broker-deployment-hdls-svc。ping 服务的默认名称使用 < custom_resource_name> -ping-svc 的格式,例如 'my-broker-deployment-ping-svc。
无头服务提供对端口 61616 的访问,用于内部代理集群。
ping 服务供代理用于发现,并允许代理在 OpenShift 环境中组成集群。在内部,该服务会公开端口 8888。
4.12.4. 从内部和外部客户端连接到代理 复制链接链接已复制到粘贴板!
本节中的示例演示了如何从内部客户端(即,与代理部署相同的 OpenShift 集群中的客户端)和外部客户端(即 OpenShift 集群以外的客户端)连接到代理。
4.12.4.1. 从内部客户端连接到代理 复制链接链接已复制到粘贴板!
要将内部客户端连接到代理,请在客户端连接详情中指定代理 pod 的 DNS 可解析名称。例如:
tcp://ex–aao-ss-0:<port>
$ tcp://ex–aao-ss-0:<port>
如果内部客户端使用 Core 协议,且连接 URL 中没有设置 useTopologyForLoadBalancing=false 键,在客户端第一次连接到代理后,代理可以告知客户端集群中的所有代理的地址。然后,客户端可以在所有代理间负载均衡连接。
如果您的代理具有持久订阅队列或请求/回复队列,请注意在客户端连接负载均衡时使用这些队列的相关注意事项。更多信息请参阅 第 4.12.4.4 节 “具有持久订阅队列或回复/请求队列时负载平衡客户端连接的注意事项”。
4.12.4.2. 从外部客户端连接到代理 复制链接链接已复制到粘贴板!
当您向外部客户端公开接受者(即,通过将 expose 参数的值设置为 true时),Operator 会自动为部署中的每个代理 pod 创建一个专用服务和路由。
外部客户端可以通过指定为代理 pod 创建的路由的完整主机名来连接到代理。您可以使用基本的 curl 命令测试对这个完整主机名的外部访问。例如:
curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
$ curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
代理 pod 路由的完整主机名必须解析为托管 OpenShift 路由器的节点。OpenShift 路由器使用主机名来确定在 OpenShift 内部网络内发送流量的位置。默认情况下,OpenShift 路由器侦听非安全(即非 SSL)流量和端口 443 的端口 80,用于安全(即 SSL 加密)流量。对于 HTTP 连接,如果指定了安全连接 URL (即 https),路由器会自动将流量定向到端口 443 (即 http)。
如果您希望外部客户端在集群中的代理间负载均衡连接:
-
通过在每个代理 pod 的 OpenShift 路由上配置
haproxy.router.openshift.io/balanceroundrobin 选项来启用负载均衡。 如果外部客户端使用 Core 协议,请在客户端连接 URL 中设置
useTopologyForLoadBalancing=false键。设置
useTopologyForLoadBalancing=false键可防止客户端使用代理提供的集群拓扑信息中的 AMQ Broker Pod DNS 名称。Pod DNS 名称解析为内部 IP 地址,外部客户端无法访问。
如果您的代理具有持久订阅队列或请求/回复队列,请注意在负载平衡客户端连接时使用这些队列的相关注意事项。更多信息请参阅 第 4.12.4.4 节 “具有持久订阅队列或回复/请求队列时负载平衡客户端连接的注意事项”。
如果您不希望外部客户端在集群中的不同代理间进行负载均衡连接:
- 在每个客户端的连接 URL 中,为每个代理 pod 指定路由的完整主机名。客户端尝试在连接 URL 中连接到第一个主机名。但是,如果第一个主机名不可用,客户端会在连接 URL 中自动连接到下一个主机名,以此类推。
-
如果外部客户端使用 Core 协议,在客户端的连接 URL 中设置
useTopologyForLoadBalancing=false键,以防止客户端使用代理提供的集群拓扑信息。
对于非 HTTP 连接:
- 客户端必须明确指定端口号(例如,端口 443),作为连接 URL 的一部分。
- 对于单向 TLS,客户端必须指定其信任存储的路径和对应的密码,作为连接 URL 的一部分。
- 对于双向 TLS,客户端还必须指定其密钥存储的路径和对应的密码,作为连接 URL 的一部分。
以下是一些用于支持的消息传递协议的客户端连接 URL 示例。
外部核心客户端,使用单向 TLS
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \ &trustStorePath=~/client.ts&trustStorePassword=<password>
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&trustStorePath=~/client.ts&trustStorePassword=<password>
在连接 URL 中,useTopologyForLoadBalancing 键明确设置为 false,因为外部核心客户端无法使用代理返回的拓扑信息。如果此键设为 true,或者您没有指定值,它会生成 DEBUG 日志消息。
外部核心客户端,使用双向 TLS
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \ &keyStorePath=~/client.ks&keyStorePassword=<password> \ &trustStorePath=~/client.ts&trustStorePassword=<password>
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&keyStorePath=~/client.ks&keyStorePassword=<password> \
&trustStorePath=~/client.ts&trustStorePassword=<password>
外部 OpenWire 客户端,使用单向 TLS
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443" # Also, specify the following JVM flags -Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"
# Also, specify the following JVM flags
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
外部 OpenWire 客户端,使用双向 TLS
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443" # Also, specify the following JVM flags -Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \ -Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"
# Also, specify the following JVM flags
-Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
使用单向 TLS 的外部 AMQP 客户端
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \ &transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
外部 AMQP 客户端,使用双向 TLS
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \ &transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \ &transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
4.12.4.3. 使用 NodePort 连接到 Broker 复制链接链接已复制到粘贴板!
作为使用路由的替代选择,OpenShift 管理员可以配置 NodePort,以从 OpenShift 外部的客户端连接到代理 pod。NodePort 应该映射到为代理配置的接收器指定的特定协议端口之一。
默认情况下,NodePort 在 30000 到 32767 范围内,这意味着 NodePort 通常与代理 Pod 上预期的端口不匹配。
要通过 NodePort 从 OpenShift 外部客户端连接到代理,您需要以 <protocol>://<ocp_node_ip>:<node_port_number> 格式指定一个 URL。
4.12.4.4. 具有持久订阅队列或回复/请求队列时负载平衡客户端连接的注意事项 复制链接链接已复制到粘贴板!
持久化订阅
持久订阅表示为代理上的队列,在持久订阅者首次连接到代理时创建。此队列存在并接收信息,直到客户端取消订阅为止。如果客户端重新连接到不同的代理,则在那个代理上创建另一个持久订阅队列。这可能导致以下问题。
| 问题 |
| 缓解方案 |
| 消息可以在原始订阅队列中进行控制。 |
|
通过为地址或一组地址设置
在这个示例中,代理会在队列的最终消费者关闭后等待 5000 毫秒,然后再将消息重新分发到其他代理。 有关消息重新发布的更多信息,请参阅启用消息重新发布。 |
| 在仍路由其他消息时,可能会以错误的顺序接收消息,因为消息重新发布期间有一个窗口。 |
| 无。 |
| 当客户端取消订阅时,它只会删除它最后一次连接的代理上的队列。这意味着其他队列仍然可以存在并接收消息。 |
|
要删除其他可能为未订阅的客户端存在的空队列,请为地址或一组地址配置以下两个属性:您可以在
将 如需更多信息,请参阅配置自动创建和删除地址和队列。 |
请求/重新队列
当 JMS Producer 创建临时回复队列时,会在代理上创建队列。如果客户端从工作队列使用并回复临时队列连接到不同的代理,则可能会出现以下问题。
| 问题 | 缓解方案 |
|---|---|
| 由于客户端连接到的代理上不存在回复队列,因此客户端可能会生成错误。 |
将代理配置为在客户端请求连接到不存在的队列时自动创建队列。若要配置自动队列创建,请在
|
| 发送到工作队列的消息可能无法分发。 |
通过在
另外,通过为地址或一组地址设置
如需更多信息,请参阅启用消息重新发布。 |
其他资源
有关使用 Routes 和 NodePort 等方法与集群中运行的服务从 OpenShift 集群外部进行通信的更多信息,请参阅:
- OpenShift Container Platform 文档中的配置集群入口流量概述。