Basic Load Balancing Cookbook

介绍

本文档包含使用基本负载均衡服务的几个示例，适用于租户或“普通”云用户。

为了便于本指南的使用，我们假设 neutron 和 barbican 命令行界面，通过 OpenStack 客户端，将被用于配置 Octavia 的所有功能。为了使这些示例简短，我们还假设与部署负载均衡服务无关的任务已经完成。这可能包括部署和配置 Web 服务器、设置 Neutron 网络、从受信任的提供商处获取 TLS 证书等。每个示例下文都给出了起始条件的描述。

请注意，本指南假定您熟悉 Octavia 词汇表 中定义的特定负载均衡术语。有关负载均衡本身和 Octavia 项目的描述，请参阅：介绍 Octavia。

示例

部署基本的 HTTP 负载均衡器

虽然从技术上讲，这是可以部署的最简单的完整负载均衡解决方案，但我们建议使用健康监控部署 HTTP 负载均衡器，以确保后端成员的可用性。请参阅下面的 部署带有健康监控的 HTTP 负载均衡器。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了 HTTP 应用程序，TCP 端口为 80。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将 Web 请求分发到后端服务器。

解决方案:

  1. 在子网 public-subnet 上创建负载均衡器 lb1。

  2. 创建监听器 listener1。

  3. 将 pool1 创建为 listener1 的默认池。

  4. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1

部署带有健康监控的 HTTP 负载均衡器

这是 HTTP 应用程序最简单的推荐负载均衡解决方案。此解决方案适用于使用与 Neutron 浮动 IP 功能不兼容的提供商网络的运营商（例如 IPv6 网络）。但是，即使需要销毁或重新创建负载均衡器，如果您需要保留通过负载均衡器可访问的外部 IP 的控制权，则使用浮动 IP 部署基本负载均衡器可能更合适。请参阅下面的 使用浮动 IP 部署基本的 HTTP 负载均衡器。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了 HTTP 应用程序，TCP 端口为 80。

  • 这些后端服务器已配置为在 URL 路径“/healthcheck”处进行健康检查。请参阅下面的 HTTP 健康监控的配置参数。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将 Web 请求分发到后端服务器，并检查“/healthcheck”路径以确保后端成员的健康状况。

解决方案:

  1. 在子网 public-subnet 上创建负载均衡器 lb1。

  2. 创建监听器 listener1。

  3. 将 pool1 创建为 listener1 的默认池。

  4. 在 pool1 上创建一个健康监控器，测试“/healthcheck”路径。

  5. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path /healthcheck --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1

使用浮动 IP 部署基本的 HTTP 负载均衡器

在使用浮动 IP 设置负载均衡器的 VIP 时，这样做可能是有益的，以便确保您保留对分配为浮动 IP 的 IP 的控制权，以防需要销毁、移动或重新创建负载均衡器。

请注意，这不能用于 IPv6 负载均衡器，因为浮动 IP 不适用于 IPv6。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了 HTTP 应用程序，TCP 端口为 80。

  • 这些后端服务器已配置为在 URL 路径“/healthcheck”处进行健康检查。请参阅下面的 HTTP 健康监控的配置参数。

  • Neutron 网络 public 是云运营商创建的共享外部网络，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将 Web 请求分发到后端服务器，并检查“/healthcheck”路径以确保后端成员的健康状况。此外，我们希望使用浮动 IP 来实现这一点。

解决方案:

  1. 在子网 private-subnet 上创建负载均衡器 lb1。

  2. 创建监听器 listener1。

  3. 将 pool1 创建为 listener1 的默认池。

  4. 在 pool1 上创建一个健康监控器，测试“/healthcheck”路径。

  5. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

  6. 在 public-subnet 上创建一个浮动 IP 地址。

  7. 将此浮动 IP 与 lb1 的 VIP 端口关联。

CLI 命令:

openstack loadbalancer create --name lb1 --vip-subnet-id private-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path /healthcheck --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1
openstack floating ip create public
# The following IDs should be visible in the output of previous commands
openstack floating ip set --port <load_balancer_vip_port_id> <floating_ip_id>

部署带有会话持久性的 HTTP 负载均衡器

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了 HTTP 应用程序，TCP 端口为 80。

  • 应用程序编写方式如下：Web 客户端应始终在整个 Web 会话期间被定向到同一后端服务器，基于 Web 应用程序插入的名为“PHPSESSIONID”的应用程序 cookie。

  • 这些后端服务器已配置为在 URL 路径“/healthcheck”处进行健康检查。请参阅下面的 HTTP 健康监控的配置参数。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将 Web 请求分发到后端服务器，使用 PHPSESSIONID 作为密钥持久化会话，并检查“/healthcheck”路径以确保后端成员的健康状况。

解决方案:

  1. 在子网 public-subnet 上创建负载均衡器 lb1。

  2. 创建监听器 listener1。

  3. 将 pool1 创建为 listener1 的默认池，该池定义了在“PHPSESSIONID”cookie 上的会话持久性。

  4. 在 pool1 上创建一个健康监控器，测试“/healthcheck”路径。

  5. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --session-persistence type=APP_COOKIE,cookie_name=PHPSESSIONID --wait
openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path /healthcheck --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1

部署 TCP 负载均衡器

这通常适用于负载均衡非 HTTP 基于 TCP 的服务时。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了自定义应用程序，TCP 端口为 23456

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将请求分发到后端服务器。

  • 我们希望使用 TCP 健康检查来确保后端服务器可用。

解决方案:

  1. 在子网 public-subnet 上创建负载均衡器 lb1。

  2. 创建监听器 listener1。

  3. 将 pool1 创建为 listener1 的默认池。

  4. 在 pool1 上创建一个健康监控器，探测 pool1 成员的 TCP 服务端口。

  5. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol TCP --protocol-port 23456 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol TCP --wait
openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1

部署带有 QoS 规则的负载均衡器

此解决方案通过将 Neutron 质量服务 (QoS) 策略应用于 VIP 来限制通过负载均衡器的 VIP 的可用带宽，因此负载均衡器可以接受来自 Neutron 的 QoS 策略；然后限制负载均衡器传入或传出的流量。

注意

在使用此功能之前，请确保通过命令在正在运行的 OpenStack 环境中启用了 Neutron QoS 扩展 (qos)

openstack extension list

场景描述:

  • 由我们使用带宽限制规则从 Neutron 创建的 QoS 策略。

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了 HTTP 应用程序，TCP 端口为 80。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个基本负载均衡器，并在 Web 流量到达 vip 时限制流量带宽。

解决方案:

  1. 在 Neutron 中创建 QoS 策略 qos-policy-bandwidth，其中包含 bandwidth_limit。

  2. 在子网 public-subnet 上创建负载均衡器 lb1，其中包含 qos-policy-bandwidth 的 ID。

  3. 创建监听器 listener1。

  4. 将 pool1 创建为 listener1 的默认池。

  5. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openstack network qos policy create qos-policy-bandwidth
openstack network qos rule create --type bandwidth_limit --max-kbps 1024 --max-burst-kbits 1024 qos-policy-bandwidth
openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --vip-qos-policy-id qos-policy-bandwidth --wait
openstack loadbalancer listener create --name listener1 lb1 --protocol HTTP --protocol-port 80 --wait
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
openstack loadbalancer member create --subnet-id <private_subnet_id> --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id <private_subnet_id> --address 192.0.2.11 --protocol-port 80 --wait pool1

部署带有访问控制列表的负载均衡器

此解决方案将传入侦听器的流量限制为一组允许的源 IP 地址。任何其他传入流量将被拒绝。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了自定义应用程序，TCP 端口为 23456

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将请求分发到后端服务器。

  • TCP 端口 23456 上的应用程序可供有限的源 IP 地址（192.0.2.0/24 和 198.51.100/24）访问。

解决方案:

  1. 在子网 public-subnet 上创建负载均衡器 lb1。

  2. 创建带有允许 CIDR 的监听器 listener1。

  3. 将 pool1 创建为 listener1 的默认池。

  4. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol TCP --protocol-port 23456 --allowed-cidr 192.0.2.0/24 --allowed-cidr 198.51.100/24 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol TCP --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1

部署非终止的 HTTPS 负载均衡器

非终止的 HTTPS 负载均衡器实际上就像一个通用的 TCP 负载均衡器：负载均衡器将 Web 客户端的原始 TCP 流量转发到后端服务器，而不会对其进行解密。这意味着后端服务器本身必须配置为终止与 Web 客户端的 HTTPS 连接，并且负载均衡器无法将标头插入到 HTTP 会话中以指示客户端 IP 地址。（也就是说，对于后端服务器，所有 Web 请求都似乎来自负载均衡器。）此外，不能与非终止的 HTTPS 一起使用高级负载均衡器功能（例如第 7 层功能）。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了 TLS 加密的 Web 应用程序，TCP 端口为 443。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将请求分发到后端服务器。

  • 我们希望使用 TCP 健康检查来确保后端服务器可用。

解决方案:

  1. 在子网 public-subnet 上创建负载均衡器 lb1。

  2. 创建监听器 listener1。

  3. 将 pool1 创建为 listener1 的默认池。

  4. 在 pool1 上创建一个健康监控器，探测 pool1 成员的 TCP 服务端口。

  5. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol HTTPS --protocol-port 443 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTPS --wait
openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTPS --url-path /healthcheck --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 443 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 443 --wait pool1

部署 TLS 终止的 HTTPS 负载均衡器

使用 TLS 终止的 HTTPS 负载均衡器，Web 客户端通过 TLS 协议与负载均衡器通信。负载均衡器终止 TLS 会话并将解密后的请求转发到后端服务器。通过在负载均衡器上终止 TLS 会话，我们将 CPU 密集型加密工作卸载到负载均衡器，并能够使用高级负载均衡器功能，例如第 7 层功能和标头操作。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了常规 HTTP 应用程序，TCP 端口为 80。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 已从外部证书颁发机构获取 www.example.com 的 TLS 证书、密钥和中间证书链。现在这些文件位于当前目录中的 server.crt、server.key 和 ca-chain.crt 文件中。密钥和证书是 PEM 编码的，中间证书链是多个 PEM 编码的证书连接在一起。密钥未用密码加密。

  • 我们希望配置一个可从互联网访问的 TLS 终止 HTTPS 负载均衡器，使用上述密钥和证书，将请求分发到后端服务器，并通过非加密的 HTTP 协议进行分发。

  • Octavia 配置为使用 barbican 进行密钥管理。

解决方案:

  1. 将单个证书/密钥/中间体组合到一个 PKCS12 文件中。

  2. 创建 barbican secret 资源，用于 PKCS12 文件。我们将其命名为 tls_secret1。

  3. 在子网 public-subnet 上创建负载均衡器 lb1。

  4. 创建监听器 listener1 作为 TERMINATED_HTTPS 监听器，引用 tls_secret1 作为其默认 TLS 容器。

  5. 将 pool1 创建为 listener1 的默认池。

  6. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.crt -passout pass: -out server.p12
openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"
openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --protocol-port 443 --protocol TERMINATED_HTTPS --name listener1 --default-tls-container=$(openstack secret list | awk '/ tls_secret1 / {print $2}') --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1

注意

对于生产服务器，一个好的安全实践是启用 HTTP 严格传输安全 (HSTS)，可以使用 --hsts-max-age 选项以及可选的 --hsts-include-subdomains --hsts-prefetch 进行配置。

部署带有 SNI 的 TLS 终止 HTTPS 负载均衡器

此示例与 部署 TLS 终止 HTTPS 负载均衡器 相同，只是我们希望使用服务器名称指示 (SNI) 技术在同一个监听器上使用多个 TLS 证书。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了常规 HTTP 应用程序，TCP 端口为 80。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 已从外部证书颁发机构获取 www.example.com 和 www2.example.com 的 TLS 证书、密钥和中间证书链。现在这些文件位于当前目录中的 server.crt、server.key、ca-chain.crt、server2.crt、server2.key 和 ca-chain2.crt 文件中。密钥和证书是 PEM 编码的，中间证书链是多个证书 PEM 编码并连接在一起。任何密钥都没有用密码加密。

  • 我们希望配置一个可从互联网访问的 TLS 终止 HTTPS 负载均衡器，使用上述密钥和证书，将请求分发到后端服务器，并通过非加密的 HTTP 协议进行分发。

  • 如果 Web 客户端连接的客户端不具备 SNI 功能，我们希望负载均衡器响应 www.example.com 的证书。

解决方案:

  1. 将单个证书/密钥/中间体组合到单个 PKCS12 文件中。

  2. 创建 barbican secret 资源，用于 PKCS12 文件。我们将其命名为 tls_secret1 和 tls_secret2。

  3. 在子网 public-subnet 上创建负载均衡器 lb1。

  4. 创建监听器 listener1 作为 TERMINATED_HTTPS 监听器，引用 tls_secret1 作为其默认 TLS 容器，并使用 SNI 引用 tls_secret1 和 tls_secret2。

  5. 将 pool1 创建为 listener1 的默认池。

  6. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.crt -passout pass: -out server.p12
openssl pkcs12 -export -inkey server2.key -in server2.crt -certfile ca-chain2.crt -passout pass: -out server2.p12
openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"
openstack secret store --name='tls_secret2' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server2.p12)"
openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --protocol-port 443 --protocol TERMINATED_HTTPS --name listener1 --default-tls-container=$(openstack secret list | awk '/ tls_secret1 / {print $2}') --sni-container-refs $(openstack secret list | awk '/ tls_secret1 / {print $2}') $(openstack secret list | awk '/ tls_secret2 / {print $2}') --wait -- lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1

部署带有客户端身份验证的 TLS 终止 HTTPS 负载均衡器

使用 TLS 终止的 HTTPS 负载均衡器，Web 客户端通过 TLS 协议与负载均衡器通信。负载均衡器终止 TLS 会话并将解密后的请求转发到后端服务器。通过在负载均衡器上终止 TLS 会话，我们将 CPU 密集型加密工作卸载到负载均衡器，并能够使用高级负载均衡器功能，例如第 7 层功能和标头操作。添加客户端身份验证允许用户使用证书对 VIP 的连接进行身份验证。这也被称为双向 TLS 身份验证。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了常规 HTTP 应用程序，TCP 端口为 80。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 已从外部证书颁发机构获取 www.example.com 的 TLS 证书、密钥和中间证书链。现在这些文件位于当前目录中的 server.crt、server.key 和 ca-chain.crt 文件中。密钥和证书是 PEM 编码的，中间证书链是多个 PEM 编码的证书连接在一起。密钥未用密码加密。

  • 已从外部证书颁发机构获取证书颁发机构 (CA) 证书链和可选的证书吊销列表 (CRL)，以对客户端证书进行身份验证。

  • 我们希望配置一个可从互联网访问的 TLS 终止 HTTPS 负载均衡器，使用上述密钥和证书，将请求分发到后端服务器，并通过非加密的 HTTP 协议进行分发。

  • Octavia 配置为使用 barbican 进行密钥管理。

解决方案:

  1. 将单个证书/密钥/中间体组合到一个 PKCS12 文件中。

  2. 创建 barbican secret 资源，用于 PKCS12 文件。我们将其命名为 tls_secret1。

  3. 创建 barbican secret 资源，用于客户端 CA 证书。我们将其命名为 client_ca_cert。

  4. 可选地，创建一个 barbican secret，用于 CRL 文件。我们将其命名为 client_ca_crl。

  5. 在子网 public-subnet 上创建负载均衡器 lb1。

  6. 创建监听器 listener1，类型为 TERMINATED_HTTPS 监听器，引用 tls_secret1 作为默认 TLS 容器，启用客户端身份验证，client_ca_cert 作为客户端 CA tls 容器引用，client_ca_crl 作为客户端 CRL 容器引用。

  7. 将 pool1 创建为 listener1 的默认池。

  8. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.crt -passout pass: -out server.p12
openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"
openstack secret store --name='client_ca_cert' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < client_ca.pem)"
openstack secret store --name='client_ca_crl' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < client_ca.crl)"
openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --protocol-port 443 --protocol TERMINATED_HTTPS --name listener1 --default-tls-container=$(openstack secret list | awk '/ tls_secret1 / {print $2}') --client-authentication=MANDATORY --client-ca-tls-container-ref=$(openstack secret list | awk '/ client_ca_cert / {print $2}') --client-crl-container=$(openstack secret list | awk '/ client_ca_crl / {print $2}') --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1

部署具有 ALPN TLS 扩展的安全的 HTTP/2 负载均衡器

这个例子与 部署 TLS 终止的 HTTPS 负载均衡器 几乎相同，除了我们希望启用 HTTP/2 负载均衡。负载均衡器通过应用程序层协议协商 (ALPN) TLS 扩展在 TLS 握手中与客户端协商 HTTP/2。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了常规 HTTP 应用程序，TCP 端口为 80。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 已从外部证书颁发机构获取 www.example.com 的 TLS 证书、密钥和中间证书链。现在这些文件位于当前目录中的 server.crt、server.key 和 ca-chain.crt 文件中。密钥和证书是 PEM 编码的，中间证书链是多个 PEM 编码的证书连接在一起。密钥未用密码加密。

  • 我们希望配置一个 TLS 终止的 HTTP/2 负载均衡器，该负载均衡器可以使用上述密钥和证书从互联网访问，并将请求通过未加密的 HTTP 协议分发到后端服务器。

  • Octavia 配置为使用 barbican 进行密钥管理。

解决方案:

  1. 将单个证书/密钥/中间体组合到一个 PKCS12 文件中。

  2. 创建 barbican secret 资源，用于 PKCS12 文件。我们将其命名为 tls_secret1。

  3. 在子网 public-subnet 上创建负载均衡器 lb1。

  4. 创建监听器 listener1，类型为 TERMINATED_HTTPS 监听器，引用 tls_secret1 作为默认 TLS 容器，以及 h2 ALPN 协议 ID 和 http/1.1 作为备用协议，以防客户端不支持 HTTP/2。

  5. 将 pool1 创建为 listener1 的默认池。

  6. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.crt -passout pass: -out server.p12
openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"
openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --protocol-port 443 --protocol TERMINATED_HTTPS --alpn-protocol h2 --alpn-protocol http/1.1 --name listener1 --default-tls-container=$(openstack secret list | awk '/ tls_secret1 / {print $2}') --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1

在相同的 IP 地址和后端上部署 HTTP 和 TLS 终止的 HTTPS 负载均衡

这个例子与 部署 TLS 终止的 HTTPS 负载均衡器 几乎相同，除了我们希望同时拥有 HTTP 和 TERMINATED_HTTPS 监听器，它们使用相同的后端池（因此，无论 Web 客户端使用 HTTP 还是 HTTPS 协议连接，它们可能都会响应完全相同的内容）。

请注意，如果您希望所有 HTTP 请求都重定向到 HTTPS（以便仅通过 HTTPS 提供请求，并且尝试通过 HTTP 访问内容只是重定向到 HTTPS 监听器），请参阅 该示例 在 第 7 层 Cookbook 中。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上配置了常规 HTTP 应用程序，TCP 端口为 80。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 已从外部证书颁发机构获取 www.example.com 的 TLS 证书、密钥和中间证书链。现在这些文件位于当前目录中的 server.crt、server.key 和 ca-chain.crt 文件中。密钥和证书是 PEM 编码的，中间证书链是多个 PEM 编码的证书连接在一起。密钥未用密码加密。

  • 我们希望配置一个可从互联网访问的 TLS 终止 HTTPS 负载均衡器，使用上述密钥和证书，将请求分发到后端服务器，并通过非加密的 HTTP 协议进行分发。

  • 我们还希望配置一个与上述相同的 IP 地址上的 HTTP 负载均衡器，该负载均衡器提供完全相同的内容（即转发到相同的后端池），就像 TERMINATED_HTTPS 监听器一样。

解决方案:

  1. 将单个证书/密钥/中间体组合到一个 PKCS12 文件中。

  2. 创建 barbican secret 资源，用于 PKCS12 文件。我们将其命名为 tls_secret1。

  3. 在子网 public-subnet 上创建负载均衡器 lb1。

  4. 创建监听器 listener1 作为 TERMINATED_HTTPS 监听器，引用 tls_secret1 作为其默认 TLS 容器。

  5. 将 pool1 创建为 listener1 的默认池。

  6. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

  7. 创建监听器 listener2，类型为 HTTP 监听器，pool1 作为其默认池。

CLI 命令:

openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.crt -passout pass: -out server.p12
openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"
openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --protocol-port 443 --protocol TERMINATED_HTTPS --name listener1 --default-tls-container=$(openstack secret list | awk '/ tls_secret1 / {print $2}') --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 80 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 80 --wait pool1
openstack loadbalancer listener create --protocol-port 80 --protocol HTTP --name listener2 --default-pool pool1 --wait lb1

部署具有后端重新加密的负载均衡器

这个例子将演示如何启用从负载均衡器到后端成员服务器的 TLS 加密。通常，这与在监听器上启用 TLS 终止一起使用，但是，为了简化示例，我们将使用未加密的 HTTP 监听器。有关设置 TLS 终止监听器的信息，请参阅上面的部分 部署 TLS 终止的 HTTPS 负载均衡器。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上已配置为在 TCP 端口 443 上具有 HTTPS 应用程序。

  • 已从外部证书颁发机构获得证书颁发机构 (CA) 证书链和可选的证书吊销列表 (CRL)，以验证成员服务器证书。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将 Web 请求分发到后端服务器。

解决方案:

  1. 为成员 CA 证书创建一个 barbican secret 资源。我们将其命名为 member_ca_cert。

  2. 可选地，为 CRL 文件创建一个 barbican secret。我们将其命名为 member_ca_crl。

  3. 在子网 public-subnet 上创建负载均衡器 lb1。

  4. 创建监听器 listener1。

  5. 创建池 pool1 作为 listener1 的默认池，启用 TLS，具有用于验证成员服务器证书的证书颁发机构 (CA) 证书链 member_ca_cert，以及用于检查成员服务器证书的证书吊销列表 (CRL) member_ca_crl。

  6. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openstack secret store --name='member_ca_cert' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < member_ca.pem)"
openstack secret store --name='member_ca_crl' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < member_ca.crl)"
openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --enable-tls --ca-tls-container-ref $(openstack secret list | awk '/ member_ca_cert / {print $2}') --crl-container-ref $(openstack secret list | awk '/ member_ca_crl / {print $2}') --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 443 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 443 --wait pool1

部署具有后端重新加密和客户端身份验证的负载均衡器

这个例子将演示如何启用从负载均衡器到后端成员服务器的 TLS 加密，同时负载均衡器使用 TLS 客户端身份验证进行身份验证。通常，这与在监听器上启用 TLS 终止一起使用，但是，为了简化示例，我们将使用未加密的 HTTP 监听器。有关设置 TLS 终止监听器的信息，请参阅上面的部分 部署 TLS 终止的 HTTPS 负载均衡器。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上已配置为在 TCP 端口 443 上具有 HTTPS 应用程序。

  • 已从外部证书颁发机构获得证书颁发机构 (CA) 证书链和可选的证书吊销列表 (CRL)，以验证成员服务器证书。

  • 已从外部证书颁发机构 (CA) 获得 TLS 证书和密钥。现在它们存在于文件 member.crt 和 member.key 中。密钥和证书是 PEM 编码的，并且密钥未用密码短语加密（在本例中）。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将 Web 请求分发到后端服务器。

解决方案:

  1. 将成员客户端身份验证证书和密钥组合到一个 PKCS12 文件中。

  2. 为 PKCS12 文件创建一个 barbican secret 资源。我们将其命名为 member_secret1。

  3. 为成员 CA 证书创建一个 barbican secret 资源。我们将其命名为 member_ca_cert。

  4. 可选地，为 CRL 文件创建一个 barbican secret。我们将其命名为 member_ca_crl。

  5. 在子网 public-subnet 上创建负载均衡器 lb1。

  6. 创建监听器 listener1。

  7. 创建池 pool1 作为 listener1 的默认池，启用 TLS，具有用于成员客户端身份验证密钥和证书 pkcs12 的 TLS 容器引用，以及用于验证成员服务器证书的证书颁发机构 (CA) 证书链 member_ca_cert，以及用于检查成员服务器证书的证书吊销列表 (CRL) member_ca_crl。

  8. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openssl pkcs12 -export -inkey member.key -in member.crt -passout pass: -out member.p12
openstack secret store --name='member_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < member.p12)"
openstack secret store --name='member_ca_cert' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < member_ca.pem)"
openstack secret store --name='member_ca_crl' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < member_ca.crl)"
openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --enable-tls --ca-tls-container-ref $(openstack secret list | awk '/ member_ca_cert / {print $2}') --crl-container-ref $(openstack secret list | awk '/ member_ca_crl / {print $2}') --tls-container-ref $(openstack secret list | awk '/ member_secret1 / {print $2}') --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 443 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 443 --wait pool1

部署具有 ALPN TLS 扩展和后端重新加密的 HTTP/2 负载均衡器

这个例子将演示如何启用 HTTP/2 负载均衡。我们部署与我们在 部署具有 ALPN TLS 扩展的安全 HTTP/2 负载均衡器 中使用的相同的 h2 alpn 协议和 TLS 终止监听器，并且我们部署与我们在 部署具有后端重新加密的负载均衡器 中使用的相同的池和成员，具有后端重新加密和 h2 alpn 协议。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上已配置为在 TCP 端口 443 上具有 HTTPS 应用程序。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 已从外部证书颁发机构获取 www.example.com 的 TLS 证书、密钥和中间证书链。现在这些文件位于当前目录中的 server.crt、server.key 和 ca-chain.crt 文件中。密钥和证书是 PEM 编码的，中间证书链是多个 PEM 编码的证书连接在一起。密钥未用密码加密。

  • 我们希望配置一个 TLS 终止的 HTTP/2 负载均衡器，该负载均衡器可以使用上述密钥和证书从互联网访问，并将请求分发到后端服务器。

  • Octavia 配置为使用 barbican 进行密钥管理。

解决方案:

  1. 将单个证书/密钥/中间体组合到一个 PKCS12 文件中。

  2. 创建 barbican secret 资源，用于 PKCS12 文件。我们将其命名为 tls_secret1。

  3. 在子网 public-subnet 上创建负载均衡器 lb1。

  4. 创建监听器 listener1，类型为 TERMINATED_HTTPS 监听器，引用 tls_secret1 作为默认 TLS 容器，以及 h2 ALPN 协议 ID 和 http/1.1 作为备用协议，以防客户端不支持 HTTP/2。

  5. 创建池 pool1 作为 listener1 的默认池，启用 TLS，以及 h2 ALPN 协议 ID 和 http/1.1 作为备用协议，以防客户端不支持 HTTP/2。

  6. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.crt -passout pass: -out server.p12
openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"
openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --protocol-port 443 --protocol TERMINATED_HTTPS --alpn-protocol h2 --alpn-protocol http/1.1 --name listener1 --default-tls-container=$(openstack secret list | awk '/ tls_secret1 / {print $2}') --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --enable-tls --alpn-protocol h2 --alpn-protocol http/1.1 --wait
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 443 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 443 --wait pool1

部署具有健康监视器的 UDP 负载均衡器

这是一个适用于基于 UDP 的服务的负载均衡器解决方案。

场景描述:

  • 后端服务器 192.0.2.10 和 192.0.2.11 在子网 private-subnet 上已配置为在 UDP 端口 1234 上具有应用程序。

  • 子网 public-subnet 是云运营商创建的共享外部子网，可以从互联网访问。

  • 我们希望配置一个可从互联网访问的基本负载均衡器，将请求分发到后端服务器。

  • 我们希望使用 UDP 健康检查来确保后端服务器可用。如果安全规则阻止了 ICMP 目标不可达 (ICMP 类型 3) 消息，UDP 健康检查可能无法正常工作（请参阅 其他健康监视器）。

解决方案:

  1. 在子网 private-subnet 上创建负载均衡器 lb1。

  2. 创建监听器 listener1。

  3. 将 pool1 创建为 listener1 的默认池。

  4. 在 pool1 上创建一个健康监视器，该监视器连接到后端服务器。

  5. 将成员 192.0.2.10 和 192.0.2.11 添加到 private-subnet 上的 pool1。

CLI 命令:

openstack loadbalancer create --name lb1 --vip-subnet-id public-subnet --wait
openstack loadbalancer listener create --name listener1 --protocol UDP --protocol-port 1234 --wait lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol UDP --wait
openstack loadbalancer healthmonitor create --delay 3 --max-retries 2 --timeout 2 --type UDP-CONNECT --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.10 --protocol-port 1234 --wait pool1
openstack loadbalancer member create --subnet-id private-subnet --address 192.0.2.11 --protocol-port 1234 --wait pool1

健康监视器最佳实践

Octavia 健康监视器是一个定期对每个后端成员进行健康检查的过程，以主动检测失败的成员并暂时将其从池中移除。

如果健康监视器检测到失败的成员，它会将其从池中删除，并将成员标记为 ERROR。在您修复成员并使其再次正常运行后，健康监视器会自动将成员的状态从 ERROR 更改为 ONLINE，并恢复向其传递流量。

始终在生产负载均衡器中使用健康监视器。如果您没有健康监视器，则失败的成员不会从池中删除。这可能导致 Web 客户端的服务中断。

请参阅命令 loadbalancer healthmonitor create。

所有健康监视器的配置参数

Octavia 的所有健康监视器类型都需要以下可配置参数

  • delay：健康检查之间的秒数。

  • timeout：等待任何给定健康检查完成的秒数。timeout 应该始终小于 delay。

  • max-retries：给定后端服务器必须失败的连续健康检查次数，然后才认为它宕机，或者失败的后端服务器必须通过多少次才能被认为恢复在线。

HTTP 健康监视器的配置参数

除了之前在 所有健康监视器的配置参数 中列出的参数之外，HTTP 健康监视器类型还需要以下参数，这些参数默认设置

  • url-path：应从后端服务器检索的 URL 的路径部分。默认情况下，此值为“/”。

  • http-method：用于检索 url-path 的 HTTP 方法。默认情况下，此值为“GET”。

  • expected-codes：指示 OK 健康检查的 HTTP 状态代码列表。默认情况下，此值为“200”。

有关 Octavia 健康监视器的所有配置参数的完整列表，请参阅命令 loadbalancer healthmonitor create。

在编写生成 Web 应用程序中健康检查的代码时，请务必记住以下最佳实践

  • 健康监视器 url-path 不需要身份验证才能加载。

  • 默认情况下，健康监视器 url-path 应该返回 HTTP 200 OK 状态代码以指示健康的服务器，除非您指定其他 expected-codes。

  • 健康检查应该执行足够的内部检查以确保应用程序正常，并且不要多余。这可能意味着确保数据库或其他外部存储连接已启动并正在运行，服务器负载可接受，站点未处于维护模式，以及特定于您的应用程序的其他测试。

  • 由健康检查生成的页面应该非常轻量级

    • 它应该在不到一秒的时间内返回。

    • 它不应给应用程序服务器带来显著的负载。

  • 由健康检查生成的页面绝不应被缓存，尽管运行健康检查的代码可以引用缓存的数据。例如，您可能会发现通过 cron 运行更全面的健康检查并将结果存储到磁盘上很有用。生成健康监视器 url-path 处的页面的代码将合并此 cron 作业的结果到它执行的测试中。

  • 由于 Octavia 只关心返回的 HTTP 状态代码，并且由于健康检查运行得非常频繁，因此使用“HEAD”或“OPTIONS”HTTP 方法来减少不必要的页面处理可能是有意义的。

其他健康监视器

其他健康监视器类型包括 PING、TCP、HTTPS、SCTP、TLS-HELLO 和 UDP-CONNECT。

PING 健康监视器会定期发送 ICMP PING 请求到后端服务器。显然，您的后端服务器必须配置为允许 PING 才能通过这些健康检查。

警告

PING 健康监视器仅检查成员是否可访问并响应 ICMP 回显请求。它不会检测您的应用程序是否在实例上正常运行。大多数池应该使用其他健康监视器选项。PING 应该仅在 ICMP 回显请求是有效健康检查的特定情况下使用。

TCP 健康监视器会在后端服务器的协议端口上打开 TCP 连接。您的自定义 TCP 应用程序应该编写为响应负载均衡器连接、打开 TCP 连接并在 TCP 握手后关闭它而无需发送任何数据，以表示 OK。

HTTPS 健康监视器的工作方式与 HTTP 健康监视器完全相同，但针对 ssl 后端服务器。不幸的是，如果服务器正在执行客户端证书验证，这会导致问题，因为 HAProxy 没有有效的证书。在这种情况下，使用 TLS-HELLO 类型监控是一种替代方案。

SCTP 健康监视器向后端服务器的端口发送 INIT 数据包。如果应用程序正在侦听此端口，则操作系统应回复 INIT ACK 数据包，但如果端口已关闭，则回复 ABORT 数据包。如果健康监视器收到 INIT ACK 数据包，它会立即使用 ABORT 数据包关闭连接，并认为服务器处于 ONLINE 状态。

TLS-HELLO 健康监视器只是确保后端服务器响应 SSLv3 客户端 hello 消息。它不会检查任何其他健康指标，例如状态代码或正文内容。

UDP-CONNECT 健康监视器执行基本的 UDP 端口连接。如果成员服务器上未启用目标不可达 (ICMP 类型 3)，或者被安全规则阻止，则此类型的健康监视器可能无法正常工作。成员服务器可能会被标记为运行状态 ONLINE，而实际上它已宕机。

中间证书链

某些 TLS 证书要求您安装中间证书链，以便 Web 客户端浏览器信任该证书。此链可以采用多种形式，并且是您从获得 TLS 证书的组织提供的文件。

PEM 编码链

中间链的最简单形式是 PEM 编码的文本文件，其中包含一系列单独编码的 PEM 证书，或者 PEM 编码的 PKCS7 块。如果这是您收到的中间链的类型，则该文件将包含 -----BEGIN PKCS7----- 或 -----BEGIN CERTIFICATE----- 在文件的顶部附近，以及 64 个字符 ASCII 文本行的一个或多个块（对于人类来说看起来像一堆乱码）。这些文件通常也以 .crt 或 .pem 扩展名命名。

DER 编码链

如果提供给您的中间链是包含看似随机二进制数据的的文件，则它可能是 DER 格式的 PKCS7 链。这些文件也可能以 .p7b 扩展名命名。

您可以使用二进制 DER 文件原样构建您的 PKCS12 包

openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.p7b -passout pass: -out server.p12

… 或者您可以将其转换为一系列 PEM 编码的证书

openssl pkcs7 -in intermediates-chain.p7b -inform DER -print_certs -out intermediates-chain.crt

… 或者您可以将其转换为 PEM 编码的 PKCS7 包

openssl pkcs7 -in intermediates-chain.p7b -inform DER -outform PEM -out intermediates-chain.crt

如果文件不是 PKCS7 DER 包，则以下两个 openssl pkcs7 命令将会失败。

更多阅读

有关使用第 7 层功能进行更高级负载均衡的示例，请参阅： 第 7 层 Cookbook