$ openstack loadbalancer create --name API_OCP_CLUSTER --vip-subnet-id <id_of_worker_vms_subnet>
×
RHOSP 上的负载均衡
负载均衡器服务的限制
Red Hat OpenStack Platform (RHOSP) 上的 OpenShift Container Platform 集群使用 Octavia 处理负载均衡器服务。由于此选择，此类集群具有一些功能限制。
RHOSP Octavia 有两个受支持的提供程序：Amphora 和 OVN。这些提供程序在可用功能以及实现细节方面有所不同。这些区别会影响在集群上创建的负载均衡器服务。
本地外部流量策略
您可以设置负载均衡器服务的外部流量策略 (ETP) 参数 .spec.externalTrafficPolicy，以便在传入流量到达服务端点 Pod 时保留其源 IP 地址。但是，如果您的集群使用 Amphora Octavia 提供程序，则流量的源 IP 将被 Amphora VM 的 IP 地址替换。如果您的集群使用 OVN Octavia 提供程序，则不会发生此行为。
将ETP选项设置为Local需要为负载均衡器创建健康检查。如果没有健康检查，流量可能会路由到没有功能端点的节点，从而导致连接中断。要强制 Cloud Provider OpenStack 创建健康检查，必须将云提供商配置中的create-monitor选项的值设置为true。
在 RHOSP 16.2 中，OVN Octavia 提供程序不支持健康检查。因此，不支持将 ETP 设置为本地。
在 RHOSP 16.2 中，Amphora Octavia 提供程序不支持 UDP 池上的 HTTP 检查。因此，UDP 负载均衡器服务会改为创建UDP-CONNECT检查。由于实现细节，此配置仅与 OVN-Kubernetes CNI 插件配合才能正常工作。
使用 Octavia 扩展集群以处理应用程序流量
在 Red Hat OpenStack Platform (RHOSP) 上运行的 OpenShift Container Platform 集群可以使用 Octavia 负载均衡服务将流量分布到多个虚拟机 (VM) 或浮动 IP 地址。此功能可以缓解单台机器或地址造成的瓶颈。
您必须创建自己的 Octavia 负载均衡器才能将其用于应用程序网络扩展。
使用 Octavia 扩展集群
如果要使用多个 API 负载均衡器，请创建一个 Octavia 负载均衡器，然后将集群配置为使用它。
先决条件
-
Octavia 可在您的 Red Hat OpenStack Platform (RHOSP) 部署中使用。
步骤
-
从命令行创建使用 Amphora 驱动程序的 Octavia 负载均衡器
您可以使用您选择的名称代替
API_OCP_CLUSTER。 -
负载均衡器变为活动状态后，创建侦听器
$ openstack loadbalancer listener create --name API_OCP_CLUSTER_6443 --protocol HTTPS--protocol-port 6443 API_OCP_CLUSTER要查看负载均衡器的状态，请输入
openstack loadbalancer list。 -
创建一个使用轮询算法并启用会话持久性的池
$ openstack loadbalancer pool create --name API_OCP_CLUSTER_pool_6443 --lb-algorithm ROUND_ROBIN --session-persistence type=<source_IP_address> --listener API_OCP_CLUSTER_6443 --protocol HTTPS -
为确保控制平面机器可用，请创建健康检查。
$ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP API_OCP_CLUSTER_pool_6443 -
将控制平面机器作为负载均衡器池的成员添加
$ for SERVER in $(MASTER-0-IP MASTER-1-IP MASTER-2-IP) do openstack loadbalancer member create --address $SERVER --protocol-port 6443 API_OCP_CLUSTER_pool_6443 done -
可选：要重用集群 API 浮动 IP 地址，请将其取消设置
$ openstack floating ip unset $API_FIP -
将取消设置的
API_FIP或新地址添加到已创建的负载均衡器 VIP$ openstack floating ip set --port $(openstack loadbalancer show -c <vip_port_id> -f value API_OCP_CLUSTER) $API_FIP
您的集群现在使用 Octavia 进行负载均衡。
用户管理负载均衡器的服务
您可以将 Red Hat OpenStack Platform (RHOSP) 上的 OpenShift Container Platform 集群配置为使用用户管理的负载均衡器来代替默认负载均衡器。
|
配置用户管理的负载均衡器取决于您的供应商的负载均衡器。 本节中的信息和示例仅供指导。请咨询供应商文档以获取有关供应商负载均衡器的更具体信息。 |
Red Hat 支持以下用户管理负载均衡器的服务
-
入口控制器
-
OpenShift API
-
OpenShift MachineConfig API
您可以选择是否要为用户管理的负载均衡器配置一项或所有这些服务。仅配置入口控制器服务是一种常见的配置选项。为了更好地理解每项服务，请查看以下图表
图 1. 显示入口控制器在 OpenShift Container Platform 环境中运行的示例网络工作流程
图 2. 显示 OpenShift API 在 OpenShift Container Platform 环境中运行的示例网络工作流程
图 3. 显示 OpenShift MachineConfig API 在 OpenShift Container Platform 环境中运行的示例网络工作流程
以下配置选项受用户管理的负载均衡器支持
-
使用节点选择器将入口控制器映射到特定节点集。您必须为此集合中的每个节点分配静态 IP 地址，或配置每个节点从动态主机配置协议 (DHCP) 接收相同的 IP 地址。基础架构节点通常会收到这种类型的配置。
-
目标所有子网上的IP地址。此配置可以减少维护开销，因为您可以在这些网络中创建和销毁节点而无需重新配置负载均衡器目标。如果您使用较小网络（例如
/27或/28）上的机器集部署入口 Pod，则可以简化负载均衡器目标。您可以通过检查机器配置池的资源来列出网络中存在的所有IP地址。
在为OpenShift Container Platform集群配置用户管理的负载均衡器之前，请考虑以下信息
-
对于前端IP地址，您可以对前端IP地址、Ingress Controller的负载均衡器和API负载均衡器使用相同的IP地址。请检查供应商的文档以了解此功能。
-
对于后端IP地址，请确保OpenShift Container Platform控制平面节点的IP地址在用户管理的负载均衡器的生命周期内不会更改。您可以通过完成以下操作之一来实现此目的
-
为每个控制平面节点分配静态IP地址。
-
配置每个节点，使其每次请求DHCP租约时都从DHCP接收相同的IP地址。根据供应商的不同，DHCP租约可能是IP预留或静态DHCP分配的形式。
-
-
手动在用户管理的Ingress Controller后端服务的负载均衡器中定义运行Ingress Controller的每个节点。例如，如果Ingress Controller移动到未定义的节点，则可能会发生连接中断。
配置用户管理的负载均衡器
您可以将 Red Hat OpenStack Platform (RHOSP) 上的 OpenShift Container Platform 集群配置为使用用户管理的负载均衡器来代替默认负载均衡器。
|
在配置用户管理的负载均衡器之前，请确保您已阅读“用户管理的负载均衡器的服务”部分。 |
阅读以下适用于您要为用户管理的负载均衡器配置的服务的先决条件。
|
在集群上运行的MetalLB充当用户管理的负载均衡器。 |
OpenShift API先决条件
-
您已定义前端IP地址。
-
负载均衡器的前端IP地址上公开了TCP端口6443和22623。请检查以下项目
-
端口6443提供对OpenShift API服务的访问。
-
端口22623可以为节点提供启动配置。
-
-
所有位于OpenShift Container Platform集群外部位置的系统用户都可以访问前端IP地址和端口6443。
-
只有OpenShift Container Platform节点才能访问前端IP地址和端口22623。
-
负载均衡器后端可以通过端口6443和22623与OpenShift Container Platform控制平面节点通信。
Ingress Controller先决条件
-
您已定义前端IP地址。
-
负载均衡器的前端IP地址上公开了TCP端口443和80。
-
所有位于OpenShift Container Platform集群外部位置的系统用户都可以访问前端IP地址、端口80和端口443。
-
OpenShift Container Platform集群中运行的所有节点都可以访问前端IP地址、端口80和端口443。
-
负载均衡器后端可以通过端口80、443和1936与运行Ingress Controller的OpenShift Container Platform节点通信。
健康检查URL规范的先决条件
您可以通过设置健康检查URL来配置大多数负载均衡器，这些URL确定服务是否可用。OpenShift Container Platform为OpenShift API、机器配置API和Ingress Controller后端服务提供这些健康检查。
以下示例显示了前面列出的后端服务的健康检查规范
Kubernetes API健康检查规范示例
Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10机器配置API健康检查规范示例
Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10Ingress Controller健康检查规范示例
Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10步骤
-
配置HAProxy Ingress Controller，以便您可以通过负载均衡器上的端口6443、22623、443和80访问集群。根据您的需要，您可以在HAProxy配置中指定单个子网的IP地址或多个子网的IP地址。
列出了一个子网的HAProxy配置示例# ... listen my-cluster-api-6443 bind 192.168.1.100:6443 mode tcp balance roundrobin option httpchk http-check connect http-check send meth GET uri /readyz http-check expect status 200 server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2 server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2 server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2 listen my-cluster-machine-config-api-22623 bind 192.168.1.100:22623 mode tcp balance roundrobin option httpchk http-check connect http-check send meth GET uri /healthz http-check expect status 200 server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2 server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2 server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2 listen my-cluster-apps-443 bind 192.168.1.100:443 mode tcp balance roundrobin option httpchk http-check connect http-check send meth GET uri /healthz/ready http-check expect status 200 server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2 server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2 server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2 listen my-cluster-apps-80 bind 192.168.1.100:80 mode tcp balance roundrobin option httpchk http-check connect http-check send meth GET uri /healthz/ready http-check expect status 200 server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2 server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2 server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2 # ...列出了多个子网的HAProxy配置示例# ... listen api-server-6443 bind *:6443 mode tcp server master-00 192.168.83.89:6443 check inter 1s server master-01 192.168.84.90:6443 check inter 1s server master-02 192.168.85.99:6443 check inter 1s server bootstrap 192.168.80.89:6443 check inter 1s listen machine-config-server-22623 bind *:22623 mode tcp server master-00 192.168.83.89:22623 check inter 1s server master-01 192.168.84.90:22623 check inter 1s server master-02 192.168.85.99:22623 check inter 1s server bootstrap 192.168.80.89:22623 check inter 1s listen ingress-router-80 bind *:80 mode tcp balance source server worker-00 192.168.83.100:80 check inter 1s server worker-01 192.168.83.101:80 check inter 1s listen ingress-router-443 bind *:443 mode tcp balance source server worker-00 192.168.83.100:443 check inter 1s server worker-01 192.168.83.101:443 check inter 1s listen ironic-api-6385 bind *:6385 mode tcp balance source server master-00 192.168.83.89:6385 check inter 1s server master-01 192.168.84.90:6385 check inter 1s server master-02 192.168.85.99:6385 check inter 1s server bootstrap 192.168.80.89:6385 check inter 1s listen inspector-api-5050 bind *:5050 mode tcp balance source server master-00 192.168.83.89:5050 check inter 1s server master-01 192.168.84.90:5050 check inter 1s server master-02 192.168.85.99:5050 check inter 1s server bootstrap 192.168.80.89:5050 check inter 1s # ... -
使用
curlCLI命令验证用户管理的负载均衡器及其资源是否正常运行-
通过运行以下命令并观察响应，验证集群机器配置API是否可访问Kubernetes API服务器资源
$ curl https://<loadbalancer_ip_address>:6443/version --insecure如果配置正确，您将收到一个JSON对象作为响应
{ "major": "1", "minor": "11+", "gitVersion": "v1.11.0+ad103ed", "gitCommit": "ad103ed", "gitTreeState": "clean", "buildDate": "2019-01-09T06:44:10Z", "goVersion": "go1.10.3", "compiler": "gc", "platform": "linux/amd64" } -
通过运行以下命令并观察输出，验证集群机器配置API是否可访问机器配置服务器资源
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure如果配置正确，命令的输出将显示以下响应
HTTP/1.1 200 OK Content-Length: 0 -
通过运行以下命令并观察输出，验证控制器是否可以通过端口80访问Ingress Controller资源
$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>如果配置正确，命令的输出将显示以下响应
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache -
通过运行以下命令并观察输出，验证控制器是否可以通过端口443访问Ingress Controller资源
$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>如果配置正确，命令的输出将显示以下响应
HTTP/1.1 200 OK referrer-policy: strict-origin-when-cross-origin set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax x-content-type-options: nosniff x-dns-prefetch-control: off x-frame-options: DENY x-xss-protection: 1; mode=block date: Wed, 04 Oct 2023 16:29:38 GMT content-type: text/html; charset=utf-8 set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None cache-control: private
-
-
配置集群的DNS记录以指向用户管理的负载均衡器的前端IP地址。您必须更新集群API和负载均衡器上的应用程序的DNS服务器记录。
修改后的DNS记录示例<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End<load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End每个DNS记录的传播可能需要一些时间才能可用。请确保每个DNS记录都已传播后再进行验证。
-
为了使您的OpenShift Container Platform集群使用用户管理的负载均衡器，您必须在集群的
install-config.yaml文件中指定以下配置# ... platform: openstack: loadBalancer: type: UserManaged (1) apiVIPs: - <api_ip> (2) ingressVIPs: - <ingress_ip> (3) # ...1 为 type参数设置UserManaged，以指定集群的用户管理的负载均衡器。此参数默认为OpenShiftManagedDefault，表示默认的内部负载均衡器。对于在openshift-kni-infra命名空间中定义的服务，用户管理的负载均衡器可以将coredns服务部署到集群中的Pod，但会忽略keepalived和haproxy服务。2 指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共IP地址，以便Kubernetes API可以与用户管理的负载均衡器通信。 3 指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共IP地址，以便用户管理的负载均衡器可以管理集群的入口流量。
验证
-
使用
curlCLI命令验证用户管理的负载均衡器和DNS记录配置是否正常运行-
通过运行以下命令并观察输出，验证您是否可以访问集群API
$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure如果配置正确，您将收到一个JSON对象作为响应
{ "major": "1", "minor": "11+", "gitVersion": "v1.11.0+ad103ed", "gitCommit": "ad103ed", "gitTreeState": "clean", "buildDate": "2019-01-09T06:44:10Z", "goVersion": "go1.10.3", "compiler": "gc", "platform": "linux/amd64" } -
通过运行以下命令并观察输出，验证您是否可以访问集群机器配置
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure如果配置正确，命令的输出将显示以下响应
HTTP/1.1 200 OK Content-Length: 0 -
通过运行以下命令并观察输出，验证您是否可以访问端口上的每个集群应用程序
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure如果配置正确，命令的输出将显示以下响应
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.<cluster-name>.<base domain>/ cache-control: no-cacheHTTP/1.1 200 OK referrer-policy: strict-origin-when-cross-origin set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure x-content-type-options: nosniff x-dns-prefetch-control: off x-frame-options: DENY x-xss-protection: 1; mode=block date: Tue, 17 Nov 2020 08:42:10 GMT content-type: text/html; charset=utf-8 set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None cache-control: private -
通过运行以下命令并观察输出，验证您是否可以访问端口443上的每个集群应用程序
$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure如果配置正确，命令的输出将显示以下响应
HTTP/1.1 200 OK referrer-policy: strict-origin-when-cross-origin set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax x-content-type-options: nosniff x-dns-prefetch-control: off x-frame-options: DENY x-xss-protection: 1; mode=block date: Wed, 04 Oct 2023 16:29:38 GMT content-type: text/html; charset=utf-8 set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None cache-control: private
-