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

4.3. 在带有 Kuryr 的 RHOSP 上安装 OpenShift Container Platform 的资源指南

当使用 Kuryr SDN 时，pod、服务、命名空间和网络策略会使用来自 RHOSP 配额的资源，这会增加最低要求。除了默认安装所需的之外，Kuryr 也有一些额外的要求。

使用以下配额来满足集群的默认最低要求：

表 4.1. 使用 Kuryr 的 RHOSP 上默认 OpenShift Container Platform 集群的建议资源
resourcevalue

浮动 IP 地址

3 - 加上预期的 LoadBalancer 类型服务数量

端口

1500 - 每个 Pod 需要 1 个

路由器

1

子网

250 - 每个命名空间/项目需要 1 个

网络

250 - 每个命名空间/项目需要 1 个

RAM

112 GB

VCPU

28

卷存储

275 GB

实例

7

安全组

250 - 每个服务和每个 NetworkPolicy 需要 1 个

安全组规则

1000

服务器组

2 - 每个机器池中每个额外可用区加 1

负载均衡器

100 - 每个服务需要 1 个

负载均衡器监听程序

500 - 每个服务公开端口需要 1 个

负载均衡器池

500 - 每个服务公开端口需要 1 个

集群或许能以少于推荐资源运行，但其性能无法保证。

重要

如果 RHOSP 对象存储(Swift)可用，并由具有 swiftoperator 角色的用户帐户执行，它将用作 OpenShift Container Platform 镜像 registry 的默认后端。在这种情况下，卷存储需要 175 GB。根据镜像 registry 的大小，Swift 空间要求会有所不同。

重要

如果您使用带有 Amphora 驱动程序的 Red Hat OpenStack Platform(RHOSP)版本 16，而不是 OVN Octavia 驱动程序，则安全组会与服务帐户而不是用户项目关联。

在设置资源时请考虑以下几点：

  • 需要的端口数量会大于 pod 的数量。Kuryr 使用端口池来预创建端口以供 pod 使用，并加快 pod 的启动时间。
  • 每个网络策略都映射到 RHOSP 安全组中，并根据 NetworkPolicy 规格将一个或多个规则添加到安全组中。

  • 每个服务都映射到一个 RHOSP 负载均衡器中。在估算配额所需的安全组数量时，请考虑此要求。

    如果您使用的是 RHOSP 版本 15 或更早版本，或者 ovn-octavia 驱动程序，则每个负载均衡器都有一个带有用户项目的安全组。

  • 配额不会考虑负载均衡器资源（如 VM 资源），但您必须在决定 RHOSP 部署的大小时考虑这些资源。默认安装将具有超过 50 个负载均衡器，集群必须能够容纳它们。

    如果您使用启用了 OVN Octavia 驱动程序的 RHOSP 版本 16，则只生成一个负载均衡器虚拟机；服务通过 OVN 流平衡负载。

OpenShift Container Platform 部署包含 control plane 机器、计算机器和 bootstrap 机器。

要启用 Kuryr SDN，您的环境必须满足以下要求：

  • 运行 RHOSP 13+。
  • 具有 Octavia 的 Overcloud。
  • 使用 Neutron Trunk 端口扩展。
  • 如果使用 ML2/OVS Neutron 驱动程序而不是 ovs-hybrid，则使用 openvswitch 防火墙驱动程序.

4.3.1. 增加配额

使用 Kuryr SDN 时，您必须提高配额以满足 pod、服务、命名空间和网络策略所使用的 Red Hat OpenStack Platform(RHOSP)资源要求。

流程

  • 运行以下命令为项目增加配额： 

    $ sudo openstack quota set --secgroups 250 --secgroup-rules 1000 --ports 1500 --subnets 250 --networks 250 <project>

4.3.2. 配置 Neutron

Kuryr CNI 利用 Neutron Trunks 扩展将容器插入 Red Hat OpenStack Platform(RHOSP)SDN，因此您必须使用 trunks 扩展才可以使 Kuryr 正常工作。

另外，如果您利用默认的 ML2/OVS Neutron 驱动程序，防火墙必须设置为 openvswitch 而不是 ovs_hybrid，以便在中继子端口上强制执行安全组，Kuryr 可以正确处理网络策略。

4.3.3. 配置 Octavia

Kuryr SDN 使用 Red Hat OpenStack Platform(RHOSP)的 Octavia LBaaS 来实现 OpenShift Container Platform 服务。因此，您必须在 RHOSP 中安装和配置 Octavia 组件以使用 Kuryr SDN。

要启用 Octavia，您必须在安装 RHOSP Overcloud 的过程中包括 Octavia 服务，或者如果 Overcloud 已存在则需要升级 Octavia 服务。以下启用 Octavia 的步骤适用于全新的 Overcloud 安装或 Overcloud 更新。

注意

以下步骤只包括在部署 RHOSP 时需要处理 Octavia 的关键部分。还要注意 registry 方法 会有所不同。

本例使用本地 registry 方法。

流程

  1. 如果您使用本地 registry，请创建一个模板来将镜像上传到 registry。例如： 

    (undercloud) $ openstack overcloud container image prepare \
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \
--namespace=registry.access.redhat.com/rhosp13 \
--push-destination=<local-ip-from-undercloud.conf>:8787 \
--prefix=openstack- \
--tag-from-label {version}-{product-version} \
--output-env-file=/home/stack/templates/overcloud_images.yaml \
--output-images-file /home/stack/local_registry_images.yaml

  2. 验证 local_registry_images.yaml 文件是否包含 Octavia 镜像。例如： 

    ...
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-api:13.0-43
  push_destination: <local-ip-from-undercloud.conf>:8787
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-health-manager:13.0-45
  push_destination: <local-ip-from-undercloud.conf>:8787
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-housekeeping:13.0-45
  push_destination: <local-ip-from-undercloud.conf>:8787
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-worker:13.0-44
  push_destination: <local-ip-from-undercloud.conf>:8787
    注意

    Octavia 容器版本根据安装的特定 RHOSP 版本的不同而有所不同。

  3. 将 registry.redhat.io 中的容器镜像拉取到 Undercloud 节点： 

    (undercloud) $ sudo openstack overcloud container image upload \
  --config-file  /home/stack/local_registry_images.yaml \
  --verbose

    这可能需要一些时间，具体取决于您的网络速度和 Undercloud 磁盘的速度。

  4. 使用 Octavia 安装或更新 Overcloud 环境： 

    $ openstack overcloud deploy --templates \
  -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \
  -e octavia_timeouts.yaml
    注意

    这个命令只包含与 Octavia 相关的文件，它根据您具体的 RHOSP 安装而有所不同。如需更多信息，请参阅 RHOSP 文档。有关自定义 Octavia 安装的详情，请参考 使用 Director 安装 Octavia。

    注意

    在利用 Kuryr SDN 时，Overcloud 安装需要 Neutron 中继 扩展。这在 director 部署中默认可用。当 Neutron 后端为 ML2/OVS 时，请使用 openvswitch 防火墙而不是默认的 ovs-hybrid。如果后端为 ML2/OVN，则不需要修改。

4.3.3.1. Octavia OVN 驱动程序

Octavia 通过 Octavia API 支持多个供应商驱动程序。

要查看所有可用的 Octavia 供应商驱动程序，请在命令行中输入： 

$ openstack loadbalancer provider list

输出示例

+---------+-------------------------------------------------+
| name    | description                                     |
+---------+-------------------------------------------------+
| amphora | The Octavia Amphora driver.                     |
| octavia | Deprecated alias of the Octavia Amphora driver. |
| ovn     | Octavia OVN driver.                             |
+---------+-------------------------------------------------+

从 RHOSP 版本 16 开始，Octavia OVN 供应商驱动程序(ovn)在 RHOSP 部署的 OpenShift Container Platform 上被支持。

OVN 是 Octavia 和 OVN 提供的负载平衡的集成驱动程序。它支持基本的负载平衡功能，并且基于 OpenFlow 规则。Director 在使用 OVN Neutron ML2 的部署中自动启用该驱动程序。

Amphora 供应商驱动程序是默认驱动程序。If ovn 被启用，Kuryr 使用它。

如果 Kuryr 使用 ovn 而不是 Amphora，它会提供以下优点：

  • 资源要求降低.Kuryr 不需要为每个服务都提供一个负载均衡器虚拟机。
  • 网络延迟降低.
  • 通过对每个服务使用 OpenFlow 规则而不是 VM 来提高服务创建速度。
  • 跨所有节点的分布式负载平衡操作，而不是集中到 Amphora 虚拟机中。

您可以在 RHOSP 云从版本 13 升级到版本 16 后将 集群配置为使用 Octavia OVN 驱动程序。

4.3.4. 已知的使用 Kuryr 安装的限制

将 OpenShift Container Platform 与 Kuryr SDN 搭配使用有一些已知的限制。

RHOSP 常规限制

将 OpenShift Container Platform 与 Kuryr SDN 搭配使用有一些限制，适用于所有版本和环境：

  • 不支持具有 NodePort 类型的 Service 对象。
  • 如果 Endpoints 对象的 .subsets.addresses 属性包含节点或 pod 的子网时，使用 OVN Octavia 供应商驱动程序的集群才支持未指定 .spec.selector 属性的 Service 对象。
  • 如果创建机器的子网没有连接到路由器，或者子网已连接但路由器没有设置外部网关，Kuryr 无法为类型为 LoadBalancer 的 Service 对象创建浮动 IP。
  • 在 Service 对象上配置 sessionAffinity=ClientIP 属性无效。Kuryr 不支持此设置。
RHOSP 版本限制

将 OpenShift Container Platform 与 Kuryr SDN 搭配使用有一些限制，具体取决于 RHOSP 版本。

  • RHOSP 16 前的版本使用默认 Octavia 负载均衡器驱动程序(Amphora)。此驱动要求在每个 OpenShift Container Platform 服务中部署一个 Amphora 负载均衡器虚拟机。创建太多的服务会导致您耗尽资源。

    如果以后版本的 RHOSP 部署禁用了 OVN Octavia 驱动程序，则也使用 Amphora 驱动程序。它们受到与早期版本的 RHOSP 相同的资源问题。

  • Kuryr SDN 不支持由服务自动取消闲置。
RHOSP 升级限制

由于 RHOSP 升级过程，可能会更改 Octavia API，可能需要升级到用于负载均衡器的 Amphora 镜像。

您可以单独处理 API 更改。

如果升级了 Amphora 镜像，RHOSP operator 可以通过两种方式处理现有的负载均衡器虚拟机：

如果运算符使用第一个选项，在故障切换过程中可能会有短暂的停机时间。

如果 Operator 采用第二个选项，现有的负载均衡器将不支持升级的 Octavia API 功能，如 UDP 侦听程序。在这种情况下，用户必须重新创建其服务以使用这些功能。

4.3.5. control plane 机器

默认情况下，OpenShift Container Platform 安装过程会创建三台 control plane 机器。

每台机器都需要：

  • 来自 RHOSP 配额的实例
  • 来自 RHOSP 配额的端口
  • 至少有 16 GB 内存和 4 个 vCPU 的类别
  • RHOSP 配额中至少有 100 GB 存储空间

4.3.6. 计算机器

默认情况下，OpenShift Container Platform 安装过程会创建三台计算机器。

每台机器都需要：

  • 来自 RHOSP 配额的实例
  • 来自 RHOSP 配额的端口
  • 至少有 8 GB 内存和 2 个 vCPU 的类别
  • RHOSP 配额中至少有 100 GB 存储空间
提示

计算机器托管您在 OpenShift Container Platform 上运行的应用程序；运行数量应尽可能多。

4.3.7. bootstrap 机器

在安装过程中，会临时置备 bootstrap 机器来支持 control plane。生产 control plane 就绪后，bootstrap 机器会被取消置备。

bootstrap 机器需要：

  • 来自 RHOSP 配额的实例
  • 来自 RHOSP 配额的端口
  • 至少有 16 GB 内存和 4 个 vCPU 的类别
  • RHOSP 配额中至少有 100 GB 存储空间

4.3.8. 用户置备的基础架构的负载均衡要求

重要

使用用户管理的负载平衡器进行部署只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

在安装 OpenShift Container Platform 前，您可以置备自己的 API 和应用程序入口负载平衡基础架构，以代替默认的内部负载平衡解决方案。在生产环境中，您可以单独部署 API 和应用程序入口负载均衡器，以便可以隔离扩展每个负载均衡器基础架构。

注意

如果要使用 Red Hat Enterprise Linux (RHEL) 实例部署 API 和应用程序入口负载均衡器，您必须单独购买 RHEL 订阅。

负载平衡基础架构必须满足以下要求：

  1. API 负载均衡器 ：提供一个通用端点，供用户（包括人工和机器）与平台交互和配置。配置以下条件：

    • 仅第 4 层负载均衡.这可被称为 Raw TCP 或 SSL Passthrough 模式。
    • 无状态负载平衡算法。这些选项根据负载均衡器的实施而有所不同。
    重要

    不要为 API 负载均衡器配置会话持久性。为 Kubernetes API 服务器配置会话持久性可能会导致出现过量 OpenShift Container Platform 集群应用程序流量，以及过量的在集群中运行的 Kubernetes API。

    在负载均衡器的前端和后端配置以下端口：

    表 4.2. API 负载均衡器
    port后端机器（池成员）internal外部描述

    6443

    Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后，您要从负载均衡器中删除 bootstrap 机器。您必须为 API 服务器健康检查探测配置 /readyz 端点。

    X

    X

    Kubernetes API 服务器

    22623

    Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后，您要从负载均衡器中删除 bootstrap 机器。

    X

    		 

    机器配置服务器

    注意

    负载均衡器必须配置为，从 API 服务器关闭 /readyz 端点到从池中移除 API 服务器实例时最多需要 30 秒。在 /readyz 返回错误或健康后的时间范围内，端点必须被删除或添加。每 5 秒或 10 秒探测一次，有两个成功请求处于健康状态，三个成为不健康的请求是经过良好测试的值。

  2. 应用程序入口负载均衡器 ：为应用程序流量从集群外部流提供入口点。OpenShift Container Platform 集群需要正确配置入口路由器。

    配置以下条件：

    • 仅第 4 层负载均衡.这可被称为 Raw TCP 或 SSL Passthrough 模式。
    • 建议根据可用选项以及平台上托管的应用程序类型，使用基于连接的或基于会话的持久性。
    提示

    如果应用程序入口负载均衡器可以看到客户端的真实 IP 地址，启用基于 IP 的会话持久性可以提高使用端到端 TLS 加密的应用程序的性能。

    在负载均衡器的前端和后端配置以下端口：

    表 4.3. 应用程序入口负载均衡器
    port后端机器（池成员）internal外部描述

    443

    默认情况下，运行 Ingress Controller Pod、计算或 worker 的机器。

    X

    X

    HTTPS 流量

    80

    默认情况下，运行 Ingress Controller Pod、计算或 worker 的机器。

    X

    X

    HTTP 流量

    注意

    如果要部署一个带有零计算节点的三节点集群，Ingress Controller Pod 在 control plane 节点上运行。在三节点集群部署中，您必须配置应用程序入口负载均衡器，将 HTTP 和 HTTPS 流量路由到 control plane 节点。

4.3.8.1. 使用用户管理的负载均衡器部署的集群的负载均衡器配置示例

本节提供了一个满足用户管理的负载均衡器部署的集群的负载均衡要求的 API 和应用程序入口负载均衡器配置示例。示例是 HAProxy 负载均衡器的 /etc/haproxy/haproxy.cfg 配置。这个示例不是为选择一个负载平衡解决方案提供建议。

在这个示例中，将相同的负载均衡器用于 Kubernetes API 和应用入口流量。在生产环境中，您可以单独部署 API 和应用程序入口负载均衡器，以便可以隔离扩展每个负载均衡器基础架构。

注意

如果您使用 HAProxy 作为负载均衡器，并且 SELinux 设置为 enforcing，您必须通过运行 setsebool -P haproxy_connect_any=1 来确保 HAProxy 服务可以绑定到配置的 TCP 端口。

例 4.1. API 和应用程序入口负载均衡器配置示例

global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443 1
  bind *:6443
  mode tcp
  option  httpchk GET /readyz HTTP/1.0
  option  log-health-checks
  balance roundrobin
  server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup 2
  server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
listen machine-config-server-22623 3
  bind *:22623
  mode tcp
  server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup 4
  server master0 master0.ocp4.example.com:22623 check inter 1s
  server master1 master1.ocp4.example.com:22623 check inter 1s
  server master2 master2.ocp4.example.com:22623 check inter 1s
listen ingress-router-443 5
  bind *:443
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:443 check inter 1s
  server worker1 worker1.ocp4.example.com:443 check inter 1s
listen ingress-router-80 6
  bind *:80
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:80 check inter 1s
  server worker1 worker1.ocp4.example.com:80 check inter 1s
1
端口 6443 处理 Kubernetes API 流量并指向 control plane 机器。
2 4
bootstrap 条目必须在 OpenShift Container Platform 集群安装前就位，且必须在 bootstrap 过程完成后删除它们。
3
端口 22623 处理机器配置服务器流量并指向 control plane 机器。
5
端口 443 处理 HTTPS 流量，并指向运行 Ingress Controller pod 的机器。默认情况下，Ingress Controller Pod 在计算机器上运行。
6
端口 80 处理 HTTP 流量，并指向运行 Ingress Controller pod 的机器。默认情况下，Ingress Controller Pod 在计算机器上运行。
注意

如果要部署一个带有零计算节点的三节点集群，Ingress Controller Pod 在 control plane 节点上运行。在三节点集群部署中，您必须配置应用程序入口负载均衡器，将 HTTP 和 HTTPS 流量路由到 control plane 节点。

提示

如果您使用 HAProxy 作为负载均衡器，您可以通过在 HAProxy 节点上运行 netstat -nltupe 来检查 haproxy 进程是否在侦听端口 6443、22623、443 和 80。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.