Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

4.8. 为客户端连接配置基于 Operator 的代理部署

4.8.1. 配置接收器
复制链接

要在 OpenShift 部署中启用到代理 Pod 的客户端连接，为部署定义 acceptors。acceptors 定义代理 Pod 如何接受连接。您可以在用于代理部署的主自定义资源(CR)中定义接收器。当您创建接受器时，您可以指定要启用接收器的信息，以及用于这些协议的代理 Pod 上的端口。

以下流程演示了如何在 CR 中为代理部署定义新的接受者。

流程

  1. 在初始安装过程中下载并提取的 Operator 归档中的 deploy/crs 目录中，打开 broker_activemqartemis_cr.yaml 自定义资源(CR)文件。

  2. 在 acceptors 元素中，添加命名的 acceptor。添加 protocols 和 port 参数。设置值，以指定接受者使用的消息传递协议，以及每个代理 Pod 上的端口来公开这些协议。例如： 

    spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp
    port: 5672
...
    Copy to Clipboard Toggle word wrap

    配置的接受器将端口 5672 公开给 AMQP 客户端。您可以在表中显示您可以为 protocol 参数指定 的完整值。

    Expand
    协议值

    核心协议

    core

    AMQP

    amqp

    OpenWire

    OpenWire

    MQTT

    mqtt

    STOMP

    STOMP

    所有支持的协议

    all

    注意
    • 对于部署中的每个代理 Pod，Operator 还会创建一个使用端口 61616 的默认接受器。代理集群需要这个默认接受器，并启用了 Core Protocol。
    • 默认情况下，AMQ Broker 管理控制台使用代理 Pod 上的端口 8161。部署中的每个代理 Pod 都有一个专用的服务，它提供对控制台的访问。更多信息请参阅 第 5 章 连接到基于 Operator 的代理部署的 AMQ Management Console。

  3. 要在同一接收器中使用另一个协议，请修改 protocol 参数。指定以逗号分隔的协议列表。例如： 

    spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
...
    Copy to Clipboard Toggle word wrap

    配置的接收器现在将端口 5672 公开给 AMQP 和 OpenWire 客户端。

  4. 要指定接受器允许的并发客户端连接数量，请添加 connectionAllowed 参数并设置值。例如： 

    spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    connectionsAllowed: 5
...
    Copy to Clipboard Toggle word wrap

  5. 默认情况下，接受者仅公开给与代理部署相同的 OpenShift 集群中的客户端。要也会将接受者公开给 OpenShift 之外的客户端，请添加 expose 参数，并将值设为 true。 

    spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    connectionsAllowed: 5
    expose: true
    ...
...
    Copy to Clipboard Toggle word wrap

    当您向 OpenShift 外部的客户端公开接收器时，Operator 会自动为部署中的每个代理 Pod 创建一个专用的服务和路由。

  6. 要启用与 OpenShift 外部客户端的接受器的安全连接，请添加 sslEnabled 参数，并将值设为 true。 

    spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    connectionsAllowed: 5
    expose: true
    sslEnabled: true
    ...
...
    Copy to Clipboard Toggle word wrap

    当您启用 SSL（即，安全套接字层）安全性在接收器（或连接器）安全性时，您可以添加相关的配置，例如：

    • 用于在 OpenShift 集群中存储身份验证凭据的机密名称。当您在 acceptor 上启用 SSL 时，需要一个 secret。有关生成此 secret 的更多信息，请参阅 第 4.8.2 节 “保护 broker-client 连接”。
    • 用于安全网络通信的传输层安全(TLS)协议。TLS 是一个更新的、更加安全的 SSL 版本。您在 enabledProtocols 参数中指定 TLS 协议。
    • 接收器是否在代理和客户端之间使用双向 TLS（也称为 mutual 身份验证 ）。您可以通过将 needClientAuth 参数的值设置为 true 来指定。

其他资源

4.8.2. 保护 broker-client 连接
复制链接

如果您在接受者或连接器上启用了安全性（即，将 sslEnabled 设为 true），您必须配置传输层安全(TLS)以允许代理和客户端之间的基于证书的身份验证。TLS 是一个更新的、更加安全的 SSL 版本。有两个主要 TLS 配置：

单向 TLS
只有代理会显示一个证书。客户端使用该证书来验证代理。这是最常见的配置。
双向 TLS
代理和客户端都提供证书。这有时被称为 mutual 身份验证。

以下描述了以下部分：

对于单向和双向 TLS，您可以生成一个 secret，在代理和客户端之间存储成功 TLS 握手所需的凭证来完成配置。这是您必须在安全接收器或连接器的 sslSecret 参数中指定的 secret 名称。secret 必须包含 Base64 编码的代理密钥存储（单向和双向 TLS）、Base64 编码的代理信任存储（仅双向 TLS）以及这些文件的对应密码，以及 Base64 编码的。单向和双向 TLS 配置流程演示了如何生成此 secret。

注意

如果您没有在受保护接收器或连接器的 sslSecret 参数中明确指定 secret 名称，接受者或连接器会假定默认 secret 名称。默认 secret 名称使用 < custom_resource_name> - <acceptor_name> -secret 或 < custom_resource_name> - &lt;connector_name>-secret 的格式。例如，my-broker-deployment-my-acceptor-secret。

即使接受者或连接器假设默认 secrete 名称，您仍需要自己生成此 secret。它不会被自动创建。

4.8.2.1. 为主机名验证配置代理证书
复制链接

注意

本节介绍了在配置单向或双向 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
Copy to Clipboard Toggle word wrap

为确保 CN 可以解析带有多个代理的的代理 Pod 中的任何代理，您可以指定一个星号(*)通配符字符来代替普通的代理 Pod。例如： 

CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
Copy to Clipboard Toggle word wrap

上例中显示的 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,..."
Copy to Clipboard Toggle word wrap

4.8.2.2. 配置单向 TLS
复制链接

本节中的步骤演示了如何配置单向传输层安全(TLS)来保护 broker-client 连接。

在单向 TLS 中，只有代理会显示证书。客户端使用此证书验证代理。

先决条件

流程

  1. 为代理密钥存储生成自签名证书。 

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
    Copy to Clipboard Toggle word wrap

  2. 从代理密钥存储导出证书，以便它与客户端共享。以 Base64 编码的 .pem 格式导出证书。例如： 

    $ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
    Copy to Clipboard Toggle word wrap

  3. 在客户端上，创建一个导入代理证书的客户端信任存储。 

    $ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
    Copy to Clipboard Toggle word wrap

  4. 以管理员身份登录 OpenShift Container Platform。例如： 

    $ oc login -u system:admin
    Copy to Clipboard Toggle word wrap

  5. 切换到包含代理部署的项目。例如： 

    $ oc project <my_openshift_project>
    Copy to Clipboard Toggle word wrap

  6. 创建用于存储 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>
    Copy to Clipboard Toggle word wrap
    注意

    在生成 secret 时，OpenShift 要求您同时指定密钥存储和信任存储。信任存储密钥通常被命名为 client.ts。对于代理和客户端之间的单向 TLS，实际上并不需要信任存储。但是，若要成功生成 secret，您需要将 一些 有效的存储文件指定为 client.ts 的值。上一步通过重复使用之前生成的代理密钥存储文件为 client.ts 提供"dummy"值。这足以生成一个带有单向 TLS 所需的所有凭证的 secret。

  7. 将 secret 链接到您在安装 Operator 时创建的服务帐户。例如： 

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
    Copy to Clipboard Toggle word wrap

  8. 在安全接受器或连接器的 sslSecret 参数中指定 secret 名称。例如： 

    spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    sslEnabled: true
    sslSecret: my-tls-secret
    expose: true
    connectionsAllowed: 5
...
    Copy to Clipboard Toggle word wrap

4.8.2.3. 配置双向 TLS
复制链接

本节中的步骤演示了如何配置双向传输层安全(TLS)来保护 broker-client 连接。

在双向 TLS 中，代理和客户端都提供证书。代理和客户端使用这些证书在进程中相互验证，有时被称为 mutual身份验证。

先决条件

流程

  1. 为代理密钥存储生成自签名证书。 

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
    Copy to Clipboard Toggle word wrap

  2. 从代理密钥存储导出证书，以便它与客户端共享。以 Base64 编码的 .pem 格式导出证书。例如： 

    $ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
    Copy to Clipboard Toggle word wrap

  3. 在客户端上，创建一个导入代理证书的客户端信任存储。 

    $ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
    Copy to Clipboard Toggle word wrap

  4. 在客户端上，为客户端密钥存储生成自签名证书。 

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
    Copy to Clipboard Toggle word wrap

  5. 在客户端上，从客户端密钥存储导出证书，以便它与代理共享。以 Base64 编码的 .pem 格式导出证书。例如： 

    $ keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
    Copy to Clipboard Toggle word wrap

  6. 创建导入客户端证书的代理信任存储。 

    $ keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
    Copy to Clipboard Toggle word wrap

  7. 以管理员身份登录 OpenShift Container Platform。例如： 

    $ oc login -u system:admin
    Copy to Clipboard Toggle word wrap

  8. 切换到包含代理部署的项目。例如： 

    $ oc project <my_openshift_project>
    Copy to Clipboard Toggle word wrap

  9. 创建用于存储 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>
    Copy to Clipboard Toggle word wrap
    注意

    在生成 secret 时，OpenShift 要求您同时指定密钥存储和信任存储。信任存储密钥通常被命名为 client.ts。对于代理和客户端之间的双向 TLS，您必须生成一个包括代理信任存储的 secret，因为这包含客户端证书。因此，在前面的步骤中，您为 client.ts 键指定的值实际上是 代理 信任存储文件。

  10. 将 secret 链接到您在安装 Operator 时创建的服务帐户。例如： 

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
    Copy to Clipboard Toggle word wrap

  11. 在安全接受器或连接器的 sslSecret 参数中指定 secret 名称。例如： 

    spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    sslEnabled: true
    sslSecret: my-tls-secret
    expose: true
    connectionsAllowed: 5
...
    Copy to Clipboard Toggle word wrap

4.8.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.8.4. 从内部和外部客户端连接到代理
复制链接

本节中的示例演示了如何从内部客户端（即代理部署相同的 OpenShift 集群中的客户端）和外部客户端（即 OpenShift 集群外的客户端）连接到代理。

4.8.4.1. 从内部客户端连接到代理
复制链接

要将内部客户端连接到代理（客户端连接详情中），请指定代理 Pod 的 DNS 可解析名称。例如： 

$ tcp://ex–aao-ss-0:<port>
Copy to Clipboard Toggle word wrap

如果内部客户端使用 Core 协议，且连接 URL 中未设置 useTopologyForLoadBalancing=false 密钥，在客户端第一次连接到代理后，代理可以告知集群中所有代理的地址的客户端。然后，客户端可以在所有代理之间对连接进行负载平衡。

如果您的代理有持久的订阅队列或请求/回复队列，请注意在客户端连接负载平衡时使用这些队列的相关注意事项。更多信息请参阅 第 4.8.4.4 节 “如果您有持久性订阅队列或回复/请求队列时，需要负载平衡客户端连接的问题”。

4.8.4.2. 从外部客户端连接到代理
复制链接

当您向外部客户端公开一个接受者（即，通过将 expose 参数的值设置为 true时），Operator 会自动为部署中的每个代理 Pod 创建一个专用的服务和路由。

外部客户端可以通过指定为代理 pod 创建的路由的完整主机名连接到代理。您可以使用基本的 curl 命令测试对此完整主机名的外部访问。例如： 

$ curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
Copy to Clipboard Toggle word wrap

代理 Pod 的路由的完整主机名必须解析到托管 OpenShift 路由器的节点。OpenShift 路由器使用主机名来决定在 OpenShift 内部发送流量的位置。默认情况下，OpenShift 路由器通过监听端口 80 进行不安全保护（即非 SSL）流量和端口 443（即 SSL 加密）流量。对于 HTTP 连接，如果您指定了安全连接 URL（即 https），或者端口 80 直接将流量定向到端口 443（即 https），如果您指定了非安全连接 URL（即 http）。

如果您希望外部客户端在集群中的代理间负载均衡连接：

  • 通过在每个代理 Pod 的 OpenShift 路由中配置 haproxy.router.openshift.io/balance roundrobin 选项来启用负载均衡。
  • 如果外部客户端默认使用 Core 协议，则 useTopologyForLoadBalancing 配置选项将设为 true。确保该值没有在连接 URL 中设置为 false。

如果您的代理有持久的订阅队列或请求/回复队列，请注意在负载平衡客户端连接时使用这些队列的相关注意事项。更多信息请参阅 第 4.8.4.4 节 “如果您有持久性订阅队列或回复/请求队列时，需要负载平衡客户端连接的问题”。

如果您不希望外部客户端在集群中的不同代理间进行负载均衡连接：

  • 在每个客户端使用的连接 URL 中设置 useTopologyForLoadBalancing=false 键。
  • 在每个客户端的连接 URL 中，指定每个代理 pod 的路由的完整主机名。客户端尝试在连接 URL 中连接到第一个主机名。但是，如果第一个主机名不可用，客户端会自动连接到连接 URL 中的下一个主机名，以此类推。

对于非 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>
Copy to Clipboard Toggle word wrap

注意

在连接 URL 中明确将 useTopologyForLoadBalancing 键明确设置为 false，因为外部 Core 客户端无法使用代理返回的拓扑信息。如果此键被设置为 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>
Copy to Clipboard Toggle word wrap

外部 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>
Copy to Clipboard Toggle word wrap

外部 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>
Copy to Clipboard Toggle word wrap

外部 AMQP 客户端，使用单向 TLS

amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
Copy to Clipboard Toggle word wrap

外部 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>
Copy to Clipboard Toggle word wrap

4.8.4.3. 使用 NodePort 连接到代理
复制链接

作为使用路由的替代选择，OpenShift 管理员可以将 NodePort 配置为从 OpenShift 外部的客户端连接到代理 Pod。NodePort 应映射到由为代理配置的接受器指定的一个协议特定端口之一。

默认情况下，NodePort 在 30000 到 32767 范围中，这意味着 NodePort 通常与代理 Pod 上的预期端口不匹配。

要通过 NodePort 从 OpenShift 外部客户端连接到代理，您需要以 <protocol>://<ocp_node_ip>:<node_port_number> 格式指定一个 URL。

持久化订阅

持久化订阅以代理上的队列形式表示，并在意外的订阅者第一次连接到代理时创建。这个队列存在并接收消息，直到客户端退订。如果客户端重新连接了不同的代理，则在该代理上创建另一个持久的订阅队列。这可能导致以下问题。

Expand
问题缓解方案

消息可能会发生在原始订阅队列中。

确保启用了消息 redistribution。如需更多信息，请参阅启用消息重新分发。

信息可能会以错误的顺序接收，因为当其他消息仍被路由时，消息会在消息重新分发时有一个窗口。

无。

当客户端取消订阅时，它会只删除它最近连接的代理上的队列。这意味着其他队列仍然可以存在并接收消息。

要删除其他可以被取消订阅的客户端的空队列，请配置以下这两个属性：

将 auto-delete-queues-message-count 属性设置为 0， 以便只能在队列中没有消息时删除队列。设置 auto-delete-queues-delay 属性，以在没有消息后删除没有消息的队列，以毫秒为单位。

如需更多信息，请参阅配置自动创建和删除地址和队列。

Request/Reply 队列

当 JMS Producer 创建临时的回复队列时，队列会在代理上创建。如果从工作队列使用的客户端并回复临时队列连接到不同的代理，则可能会出现以下问题。

Expand
问题缓解方案

由于客户端连接的代理中不存在答复队列，客户端可能会生成错误。

确保 auto-create-queues 属性设为 true。如需更多信息，请参阅配置自动创建和删除地址和队列。

发送到工作队列的消息可能无法分发。

通过将 message-load-balancing 属性设置为 ON-DEMAND，确保消息按需负载平衡。另外，请确保启用了消息 redistribution。如需更多信息，请参阅启用消息重新分发。

其他资源

  • 有关使用方法（如 Routes 和 NodePort）从 OpenShift 集群外部与集群中运行的服务进行通信的更多信息，请参阅：

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat