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 协议 协议 值 核心协议
core
AMQP
amqp
OpenWire
OpenWire
MQTT
mqtt
STOMP
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.com
Copy 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.com
Copy 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.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
编辑用于代理部署的
ActiveMQArtemis
CR。 指定在您要保护的每个接受者的
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-secret
secret 的 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.ks
Copy 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.pem
Copy 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.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以管理员身份登录 OpenShift Container Platform。例如:
oc login -u system:admin
$ oc login -u system:admin
Copy 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-secret
Copy 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.ks
Copy 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.pem
Copy 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.pem
Copy 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.ks
Copy 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.pem
Copy 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.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以管理员身份登录 OpenShift Container Platform。例如:
oc login -u system:admin
$ oc login -u system:admin
Copy 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-secret
Copy 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/balance
roundrobin 选项来启用负载均衡。 如果外部客户端使用 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 文档中的配置集群入口流量概述。