第 11 章 使用基于代理的安装程序安装内部集群
11.1. 准备使用基于代理的安装程序安装
11.1.1. 关于基于代理的安装程序
基于代理的安装方法提供了以任何方式引导内部服务器的灵活性。它将辅助安装服务的使用与离线运行的功能相结合,包括在 air-gapped 环境中。基于代理的安装是 OpenShift Container Platform 安装程序的子命令。它生成一个可引导的 ISO 镜像,其中包含使用可用发行镜像部署 OpenShift Container Platform 集群所需的所有信息。
配置的格式与安装程序置备的基础架构和用户置备的基础架构安装方法相同。基于代理的安装程序也可以选择生成或接受 Zero Touch Provisioning (ZTP) 自定义资源。ZTP 允许您使用裸机设备声明配置来置备新的边缘站点。
CPU 架构 | 连接安装 | 断开连接的安装 |
---|---|---|
| ✓ | ✓ |
| ✓ | ✓ |
| ✓ | ✓ |
| ✓ | ✓ |
11.1.2. 了解基于代理的安装程序
作为 OpenShift Container Platform 用户,您可以在断开连接的环境中利用 Assisted Installer 托管服务的优势。
基于代理的安装包含一个可引导 ISO,其中包含辅助发现代理和辅助服务。两者都需要执行集群安装,但后者仅在其中一个主机上运行。
目前,IBM Z®(s390x'
)上的 ISO 引导支持仅适用于 Red Hat Enterprise Linux (RHEL) KVM,这为选择 PXE 或基于 ISO 的安装提供了灵活性。对于使用 z/VM 和逻辑分区(LPAR)的安装,只支持 PXE 引导。
openshift-install agent create image
子命令会根据您提供的输入生成一个临时 ISO。您可以选择通过以下清单提供输入:
Preferred:
-
install-config.yaml
-
agent-config.yaml
可选:ZTP 清单
-
cluster-manifests/cluster-deployment.yaml
-
cluster-manifests/agent-cluster-install.yaml
-
cluster-manifests/pull-secret.yaml
-
cluster-manifests/infraenv.yaml
-
cluster-manifests/cluster-image-set.yaml
-
cluster-manifests/nmstateconfig.yaml
-
mirror/registries.conf
-
mirror/ca-bundle.crt
11.1.2.1. 基于代理的安装程序工作流
其中一个 control plane 主机在引导过程中运行 Assisted Service,最终成为 bootstrap 主机。此节点称为 rendezvous 主机 (node 0)。Assisted Service 确保所有主机都满足要求,并触发 OpenShift Container Platform 集群部署。所有节点都将 Red Hat Enterprise Linux CoreOS (RHCOS) 镜像写入磁盘。非引导节点重新引导并启动集群部署。节点重启后,rendezvous 主机会重启并加入集群。bootstrap 已完成,并部署了集群。
图 11.1. 节点安装工作流
您可以通过 openshift-install agent create image
子命令为以下拓扑安装断开连接的 OpenShift Container Platform 集群:
- 单节点 OpenShift Container Platform 集群 (SNO) :一个 master 和 worker 的节点。
- 三节点 OpenShift Container Platform 集群 :一个紧凑集群,它有三个 master 节点,也是 worker 节点。
- 高可用性 OpenShift Container Platform 集群 (HA) :具有任意数量的 worker 节点的 master 节点。
11.1.2.2. 拓扑的建议资源
为以下拓扑推荐的集群资源:
Topology | control plane 节点数量 | 计算节点数量 | vCPU | memory | 存储 |
---|---|---|---|---|---|
单节点集群 | 1 | 0 | 8 个 vCPU 内核 | 16 GB RAM | 120 GB |
紧凑集群 | 3 | 0 或 1 | 8 个 vCPU 内核 | 16 GB RAM | 120 GB |
HA 集群 | 3 | 2 及更高版本 | 8 个 vCPU 内核 | 16 GB RAM | 120 GB |
在 install-config.yaml
中,指定在其上执行安装的平台。支持以下平台:
-
baremetal
-
vsphere
none
重要对于平台,
none
:-
none
选项需要在集群中置备 DNS 名称解析和负载平衡基础架构。如需更多信息,请参阅"Additional resources"部分中的使用平台"none"选项集群的要求。 - 在尝试在虚拟化或云环境中安装 OpenShift Container Platform 集群前,请参阅有关在未经测试的平台上部署 OpenShift Container Platform 的指南 中的信息。
-
11.1.3. 关于 FIPS 合规性
对于许多 OpenShift Container Platform 客户,在将任何系统投入生产前需要达到一定级别的法规就绪状态或合规性。这种法规就绪状态可通过国家标准、行业标准或机构的企业监管框架来施加。FIPS(Federal Information Processing Standards)合规性是高安全性环境中所需的最重要的组件之一,可确保节点上只允许使用支持的加密技术。
要为集群启用 FIPS 模式,您必须从配置为以 FIPS 模式操作的 Red Hat Enterprise Linux (RHEL) 计算机运行安装程序。有关在 RHEL 中配置 FIPS 模式的更多信息,请参阅在 FIPS 模式中安装该系统。
当以 FIPS 模式运行 Red Hat Enterprise Linux (RHEL) 或 Red Hat Enterprise Linux CoreOS (RHCOS)时,OpenShift Container Platform 核心组件使用 RHEL 加密库,在 x86_64、ppc64le 和 s390x 架构上提交到 NIST FIPS 140-2/140-3 Validation。
11.1.4. 通过基于代理的安装程序配置 FIPS
在集群部署期间,当在集群中部署 Red Hat Enterprise Linux CoreOS (RHCOS) 机器时,会应用联邦信息处理标准 (FIPS) 更改。在 Red Hat Enterprise Linux(RHEL) 机器中,您必须在计划用作 worker 机器的机器上安装操作系统时启用 FIPS 模式。
您可以通过首选使用 install-config.yaml
和 agent-config.yaml
来启用 FIPS 模式:
您必须在
install-config.yaml
文件中将fips
字段的值设置为True
:install-config.yaml.file 示例
apiVersion: v1 baseDomain: test.example.com metadata: name: sno-cluster fips: True
可选:如果使用 GitOps ZTP 清单,您必须在
agent-cluster-install.yaml
文件的Agent-install.openshift.io/install-config-overrides
字段中将fips
的值设置为True
:agent-cluster-install.yaml 文件示例
apiVersion: extensions.hive.openshift.io/v1beta1 kind: AgentClusterInstall metadata: annotations: agent-install.openshift.io/install-config-overrides: '{"fips": True}' name: sno-cluster namespace: sno-cluster-test
11.1.5. 主机配置
您可以在 agent-config.yaml
文件中为集群中的每个主机创建额外的配置,如网络配置和 root 设备提示。
对于您配置的每个主机,您必须提供主机上接口的 MAC 地址,以指定您要配置的主机。
11.1.5.1. 主机角色
集群中的每个主机都被分配了 master
或 worker
的角色。您可以使用 role
参数为 agent-config.yaml
文件中的每个主机定义角色。如果您没有为主机分配角色,则会在安装过程中随机分配角色。
建议为您的主机显式定义角色。
rendezvousIP
必须分配给具有 master
角色的主机。这可以手动完成,或者通过允许基于代理的安装程序分配角色。
您不需要为 rendezvous 主机显式定义 master
角色,但您无法创建与这个分配冲突的配置。
例如,如果您有 4 个主机明确定义为具有 master
角色,则在安装过程中自动分配 worker
角色的最后一个主机无法配置为 rendezvous 主机。
agent-config.yaml 文件示例
apiVersion: v1beta1 kind: AgentConfig metadata: name: example-cluster rendezvousIP: 192.168.111.80 hosts: - hostname: master-1 role: master interfaces: - name: eno1 macAddress: 00:ef:44:21:e6:a5 - hostname: master-2 role: master interfaces: - name: eno1 macAddress: 00:ef:44:21:e6:a6 - hostname: master-3 role: master interfaces: - name: eno1 macAddress: 00:ef:44:21:e6:a7 - hostname: worker-1 role: worker interfaces: - name: eno1 macAddress: 00:ef:44:21:e6:a8
11.1.5.2. 关于 root 设备提示
rootDeviceHints
参数可让安装程序将 Red Hat Enterprise Linux CoreOS(RHCOS)镜像置备到特定的设备。安装程序会按照发现设备的顺序检查设备,并将发现的值与 hint 值进行比较。安装程序使用第一个与 hint 值匹配的发现设备。配置可以组合多个 hint,但设备必须与所有提示匹配,以便安装程序进行选择。
子字段 | 描述 |
---|---|
|
包含 Linux 设备名称的字符串(如 |
|
包含类似 |
| 包含特定厂商的设备标识符的字符串。hint 可以是实际值的子字符串。 |
| 包含该设备厂商或制造商名称的字符串。hint 可以是实际值的子字符串。 |
| 包含设备序列号的字符串。hint 必须与实际值完全匹配。 |
| 以 GB 为单位代表设备的最小大小的整数。 |
| 包含唯一存储标识符的字符串。hint 必须与实际值完全匹配。 |
| 指明该设备为旋转磁盘(true)还是非旋转磁盘(false)的布尔值。 |
用法示例
- name: master-0 role: master rootDeviceHints: deviceName: "/dev/sda"
11.1.6. 关于网络
在生成代理 ISO 时,必须知道 rendezvous IP,以便在初始引导过程中,所有主机都可以检查辅助服务。如果使用动态主机配置协议 (DHCP) 服务器分配 IP 地址,则必须将 rendezvousIP
字段设置为将成为部署 control plane 一部分的主机的 IP 地址。在没有 DHCP 服务器的环境中,您可以静态定义 IP 地址。
除了静态 IP 地址外,您还可以应用任何采用 NMState 格式的网络配置。这包括 VLAN 和 NIC 绑定。
11.1.6.1. DHCP
首选方法:install-config.yaml
和 agent-config.yaml
您必须为 rendezvousIP
字段指定值。networkConfig
字段可以留空:
agent-config.yaml.file 示例
apiVersion: v1alpha1
kind: AgentConfig
metadata:
name: sno-cluster
rendezvousIP: 192.168.111.80 1
- 1
- rendezvous 主机的 IP 地址。
11.1.6.2. 静态网络
首选方法:
install-config.yaml
和agent-config.yaml
agent-config.yaml.file 示例
cat > agent-config.yaml << EOF apiVersion: v1alpha1 kind: AgentConfig metadata: name: sno-cluster rendezvousIP: 192.168.111.80 1 hosts: - hostname: master-0 interfaces: - name: eno1 macAddress: 00:ef:44:21:e6:a5 2 networkConfig: interfaces: - name: eno1 type: ethernet state: up mac-address: 00:ef:44:21:e6:a5 ipv4: enabled: true address: - ip: 192.168.111.80 3 prefix-length: 23 4 dhcp: false dns-resolver: config: server: - 192.168.111.1 5 routes: config: - destination: 0.0.0.0/0 next-hop-address: 192.168.111.1 6 next-hop-interface: eno1 table-id: 254 EOF
可选方法:GitOps ZTP 清单
GitOps ZTP 自定义资源的可选方法包含 6 个自定义资源 ; 您可以在
nmstateconfig.yaml
文件中配置静态 IP。apiVersion: agent-install.openshift.io/v1beta1 kind: NMStateConfig metadata: name: master-0 namespace: openshift-machine-api labels: cluster0-nmstate-label-name: cluster0-nmstate-label-value spec: config: interfaces: - name: eth0 type: ethernet state: up mac-address: 52:54:01:aa:aa:a1 ipv4: enabled: true address: - ip: 192.168.122.2 1 prefix-length: 23 2 dhcp: false dns-resolver: config: server: - 192.168.122.1 3 routes: config: - destination: 0.0.0.0/0 next-hop-address: 192.168.122.1 4 next-hop-interface: eth0 table-id: 254 interfaces: - name: eth0 macAddress: 52:54:01:aa:aa:a1 5
rendezvous IP 从 config
字段中指定的静态 IP 地址中选择。
11.1.7. 使用平台"none"选项对集群的要求
本节介绍了配置为使用平台 none
选项的基于 Agent 的 OpenShift Container Platform 安装的要求。
在尝试在虚拟化或云环境中安装 OpenShift Container Platform 集群前,请参阅有关在未经测试的平台上部署 OpenShift Container Platform 的指南 中的信息。
11.1.7.1. 平台"none" DNS 要求
在 OpenShift Container Platform 部署中,以下组件需要 DNS 名称解析:
- The Kubernetes API
- OpenShift Container Platform 应用程序通配符
- control plane 和计算机器
Kubernetes API、control plane 机器和计算机器还需要反向 DNS 解析。
DNS A/AAAA 或 CNAME 记录用于名称解析,PTR 记录用于反向名称解析。反向记录很重要,因为 Red Hat Enterprise Linux CoreOS(RHCOS)使用反向记录为所有节点设置主机名,除非 DHCP 提供主机名。另外,反向记录用于生成 OpenShift Container Platform 需要操作的证书签名请求(CSR)。
建议使用 DHCP 服务器为每个群集节点提供主机名。
使用 platform none
选项的 OpenShift Container Platform 集群需要以下 DNS 记录,且必须在安装前就位它们。在每个记录中,<cluster_name>
是集群名称,<base_domain>
是您在 install-config.yaml
文件中指定的基域。完整的 DNS 记录采用以下形式: <component>.<cluster_name>.<base_domain>.
。
组件 | 记录 | 描述 |
---|---|---|
Kubernetes API |
| DNS A/AAAA 或 CNAME 记录,以及用于标识 API 负载均衡器的 DNS PTR 记录。这些记录必须由集群外的客户端和集群中的所有节点解析。 |
| DNS A/AAAA 或 CNAME 记录,以及用于内部标识 API 负载均衡器的 DNS PTR 记录。这些记录必须可以从集群中的所有节点解析。 重要 API 服务器必须能够根据 Kubernetes 中记录的主机名解析 worker 节点。如果 API 服务器无法解析节点名称,则代理的 API 调用会失败,且您无法从 pod 检索日志。 | |
Routes |
| 通配符 DNS A/AAAA 或 CNAME 记录,指向应用程序入口负载均衡器。应用程序入口负载均衡器以运行 Ingress Controller Pod 的机器为目标。默认情况下,Ingress Controller Pod 在计算机器上运行。这些记录必须由集群外的客户端和集群中的所有节点解析。
例如,console |
control plane 机器 |
| DNS A/AAAA 或 CNAME 记录,以识别 control plane 节点的每台机器。这些记录必须由集群中的节点解析。 |
计算机器 |
| DNS A/AAAA 或 CNAME 记录,用于识别 worker 节点的每台机器。这些记录必须由集群中的节点解析。 |
在 OpenShift Container Platform 4.4 及更新的版本中,您不需要在 DNS 配置中指定 etcd 主机和 SRV 记录。
您可以使用 dig
命令验证名称和反向名称解析。
11.1.7.1.1. 平台 "none" 集群的 DNS 配置示例
本节提供了 A 和 PTR 记录配置示例,它满足使用平台 none
选项部署 OpenShift Container Platform 的 DNS 要求。样本不是为选择一个 DNS 解决方案提供建议。
在这个示例中,集群名称为 ocp4
,基域是 example.com
。
平台 "none" 集群的 DNS A 记录配置示例
以下示例是 BIND 区域文件,它显示了使用 platform none
选项在集群中名称解析的 A 记录示例。
例 11.1. DNS 区数据库示例
$TTL 1W @ IN SOA ns1.example.com. root ( 2019070700 ; serial 3H ; refresh (3 hours) 30M ; retry (30 minutes) 2W ; expiry (2 weeks) 1W ) ; minimum (1 week) IN NS ns1.example.com. IN MX 10 smtp.example.com. ; ; ns1.example.com. IN A 192.168.1.5 smtp.example.com. IN A 192.168.1.5 ; helper.example.com. IN A 192.168.1.5 helper.ocp4.example.com. IN A 192.168.1.5 ; api.ocp4.example.com. IN A 192.168.1.5 1 api-int.ocp4.example.com. IN A 192.168.1.5 2 ; *.apps.ocp4.example.com. IN A 192.168.1.5 3 ; master0.ocp4.example.com. IN A 192.168.1.97 4 master1.ocp4.example.com. IN A 192.168.1.98 5 master2.ocp4.example.com. IN A 192.168.1.99 6 ; worker0.ocp4.example.com. IN A 192.168.1.11 7 worker1.ocp4.example.com. IN A 192.168.1.7 8 ; ;EOF
- 1
- 为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址。
- 2
- 为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址,用于内部集群通信。
- 3
- 为通配符路由提供名称解析。记录引用应用程序入口负载均衡器的 IP 地址。应用程序入口负载均衡器以运行 Ingress Controller Pod 的机器为目标。默认情况下,Ingress Controller Pod 在计算机器上运行。注意
在这个示例中,将相同的负载均衡器用于 Kubernetes API 和应用入口流量。在生产环境中,您可以单独部署 API 和应用程序入口负载均衡器,以便可以隔离扩展每个负载均衡器基础架构。
- 4 5 6
- 为 control plane 机器提供名称解析。
- 7 8
- 为计算机器提供名称解析。
平台 "none" 集群的 DNS PTR 记录配置示例
下面的 BIND 区文件示例显示集群中使用 platform none
选项反向名称解析的 PTR 记录示例。
例 11.2. 反向记录的 DNS 区数据库示例
$TTL 1W @ IN SOA ns1.example.com. root ( 2019070700 ; serial 3H ; refresh (3 hours) 30M ; retry (30 minutes) 2W ; expiry (2 weeks) 1W ) ; minimum (1 week) IN NS ns1.example.com. ; 5.1.168.192.in-addr.arpa. IN PTR api.ocp4.example.com. 1 5.1.168.192.in-addr.arpa. IN PTR api-int.ocp4.example.com. 2 ; 97.1.168.192.in-addr.arpa. IN PTR master0.ocp4.example.com. 3 98.1.168.192.in-addr.arpa. IN PTR master1.ocp4.example.com. 4 99.1.168.192.in-addr.arpa. IN PTR master2.ocp4.example.com. 5 ; 11.1.168.192.in-addr.arpa. IN PTR worker0.ocp4.example.com. 6 7.1.168.192.in-addr.arpa. IN PTR worker1.ocp4.example.com. 7 ; ;EOF
OpenShift Container Platform 应用程序通配符不需要 PTR 记录。
11.1.7.2. 平台"none"负载均衡要求
在安装 OpenShift Container Platform 前,您必须置备 API 和应用程序入口负载均衡基础架构。在生产环境中,您可以单独部署 API 和应用程序入口负载均衡器,以便可以隔离扩展每个负载均衡器基础架构。
这些要求不适用于使用 platform none
选项的单节点 OpenShift 集群。
如果要使用 Red Hat Enterprise Linux (RHEL) 实例部署 API 和应用程序入口负载均衡器,您必须单独购买 RHEL 订阅。
负载平衡基础架构必须满足以下要求:
API 负载均衡器 :提供一个通用端点,供用户(包括人工和机器)与平台交互和配置。配置以下条件:
- 仅第 4 层负载均衡.这可称为 Raw TCP、SSL Passthrough 或 SSL 网桥模式。如果使用 SSL Bridge 模式,必须为 API 路由启用 Server Name Indication(SNI)。
- 无状态负载平衡算法。这些选项根据负载均衡器的实施而有所不同。
重要不要为 API 负载均衡器配置会话持久性。
在负载均衡器的前端和后端配置以下端口:
表 11.5. API 负载均衡器 port 后端机器(池成员) internal 外部 描述 6443
控制平面。您必须为 API 服务器健康检查探测配置
/readyz
端点。X
X
Kubernetes API 服务器
22623
控制平面。
X
机器配置服务器
注意负载均衡器必须配置为,从 API 服务器关闭
/readyz
端点到从池中移除 API 服务器实例时最多需要 30 秒。在/readyz
返回错误或健康后的时间范围内,端点必须被删除或添加。每 5 秒或 10 秒探测一次,有两个成功请求处于健康状态,三个成为不健康的请求是经过良好测试的值。应用程序入口负载均衡器 :为应用程序流量从集群外部流提供入口点。OpenShift Container Platform 集群需要正确配置入口路由器。
配置以下条件:
- 仅第 4 层负载均衡.这可称为 Raw TCP、SSL Passthrough 或 SSL 网桥模式。如果使用 SSL Bridge 模式,您必须为入口路由启用 Server Name Indication(SNI)。
- 建议根据可用选项以及平台上托管的应用程序类型,使用基于连接的或基于会话的持久性。
提示如果应用程序入口负载均衡器可以看到客户端的真实 IP 地址,启用基于 IP 的会话持久性可以提高使用端到端 TLS 加密的应用程序的性能。
在负载均衡器的前端和后端配置以下端口:
表 11.6. 应用程序入口负载均衡器 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 节点。
11.1.7.2.1. 平台 "none" 集群的负载均衡器配置示例
本节提供了一个满足平台 none
选项的集群的负载均衡要求的 API 和应用程序 Ingress 负载均衡器配置示例。示例是 HAProxy 负载均衡器的 /etc/haproxy/haproxy.cfg
配置。这个示例不是为选择一个负载平衡解决方案提供建议。
在这个示例中,将相同的负载均衡器用于 Kubernetes API 和应用入口流量。在生产环境中,您可以单独部署 API 和应用程序入口负载均衡器,以便可以隔离扩展每个负载均衡器基础架构。
如果您使用 HAProxy 作为负载均衡器,并且 SELinux 设置为 enforcing
,您必须通过运行 setsebool -P haproxy_connect_any=1
来确保 HAProxy 服务可以绑定到配置的 TCP 端口。
例 11.3. 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 server master0 master0.ocp4.example.com:6443 check inter 1s server master1 master1.ocp4.example.com:6443 check inter 1s server master2 master2.ocp4.example.com:6443 check inter 1s listen machine-config-server-22623 2 bind *:22623 mode tcp 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 3 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 4 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
- 端口
22623
处理机器配置服务器流量并指向 control plane 机器。 - 3
- 端口
443
处理 HTTPS 流量,并指向运行 Ingress Controller pod 的机器。默认情况下,Ingress Controller Pod 在计算机器上运行。 - 4
- 端口
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
。
11.1.8. 示例:绑定和 VLAN 接口节点网络配置
以下 agent-config.yaml
文件是绑定和 VLAN 接口的清单示例。
apiVersion: v1alpha1 kind: AgentConfig rendezvousIP: 10.10.10.14 hosts: - hostname: master0 role: master interfaces: - name: enp0s4 macAddress: 00:21:50:90:c0:10 - name: enp0s5 macAddress: 00:21:50:90:c0:20 networkConfig: interfaces: - name: bond0.300 1 type: vlan 2 state: up vlan: base-iface: bond0 id: 300 ipv4: enabled: true address: - ip: 10.10.10.14 prefix-length: 24 dhcp: false - name: bond0 3 type: bond 4 state: up mac-address: 00:21:50:90:c0:10 5 ipv4: enabled: false ipv6: enabled: false link-aggregation: mode: active-backup 6 options: miimon: "150" 7 port: - enp0s4 - enp0s5 dns-resolver: 8 config: server: - 10.10.10.11 - 10.10.10.12 routes: config: - destination: 0.0.0.0/0 next-hop-address: 10.10.10.10 9 next-hop-interface: bond0.300 10 table-id: 254
11.1.9. 示例:绑定和 SR-IOV 双节点网络配置
以下 agent-config.yaml
文件是带有绑定和 SR-IOV 接口的双端口 NIC 的清单示例:
apiVersion: v1alpha1 kind: AgentConfig rendezvousIP: 10.10.10.14 hosts: - hostname: worker-1 interfaces: - name: eno1 macAddress: 0c:42:a1:55:f3:06 - name: eno2 macAddress: 0c:42:a1:55:f3:07 networkConfig: 1 interfaces: 2 - name: eno1 3 type: ethernet 4 state: up mac-address: 0c:42:a1:55:f3:06 ipv4: enabled: true dhcp: false 5 ethernet: sr-iov: total-vfs: 2 6 ipv6: enabled: false - name: sriov:eno1:0 type: ethernet state: up 7 ipv4: enabled: false 8 ipv6: enabled: false dhcp: false - name: sriov:eno1:1 type: ethernet state: down - name: eno2 type: ethernet state: up mac-address: 0c:42:a1:55:f3:07 ipv4: enabled: true ethernet: sr-iov: total-vfs: 2 ipv6: enabled: false - name: sriov:eno2:0 type: ethernet state: up ipv4: enabled: false ipv6: enabled: false - name: sriov:eno2:1 type: ethernet state: down - name: bond0 type: bond state: up min-tx-rate: 100 9 max-tx-rate: 200 10 link-aggregation: mode: active-backup 11 options: primary: sriov:eno1:0 12 port: - sriov:eno1:0 - sriov:eno2:0 ipv4: address: - ip: 10.19.16.57 13 prefix-length: 23 dhcp: false enabled: true ipv6: enabled: false dns-resolver: config: server: - 10.11.5.160 - 10.2.70.215 routes: config: - destination: 0.0.0.0/0 next-hop-address: 10.19.17.254 next-hop-interface: bond0 14 table-id: 254
- 1
networkConfig
字段包含有关主机的网络配置的信息,子字段包括接口
、dns-resolver
和routes
。- 2
interfaces
字段是为主机定义的网络接口数组。- 3
- 接口的名称。
- 4
- 接口的类型。这个示例创建了一个以太网接口。
- 5
- 如果物理功能 (PF) 没有严格要求,则将其设置为
false
以禁用 DHCP。 - 6
- 把它设置为要实例化的 SR-IOV 虚拟功能 (VF) 的数量。
- 7
- 把它设置为
up
。 - 8
- 把它设置为
false
,以禁用附加到绑定的 VF 的 IPv4 寻址。 - 9
- 为 VF 设置最小传输率(以 Mbps 为单位)。这个示例值设置 100 Mbps 的速度。
- 这个值必须小于或等于最大传输率。
-
Intel NIC 不支持
min-tx-rate
参数。如需更多信息,请参阅 BZ#1772847。
- 10
- 为 VF 设置最大传输率(以 Mbps 为单位)。此示例值设置 200 Mbps 的速度。
- 11
- 设置所需的绑定模式。
- 12
- 设置绑定接口的首选端口。主设备是要使用的绑定接口的第一个,除非失败,否则不会被取消。当绑定接口中的一个 NIC 速度更快时,此设置特别有用,因此可以处理较大的负载。只有在绑定接口处于
active-backup
模式(模式 1)和balance-tlb
(模式 5)时,此设置才有效。 - 13
- 为绑定接口设置静态 IP 地址。这是节点 IP 地址。
- 14
- 将
bond0
设置为默认路由的网关。
其他资源
11.1.10. 裸机 install-config.yaml 文件示例
您可以自定义 install-config.yaml
文件,以指定有关 OpenShift Container Platform 集群平台的更多详情,或修改所需参数的值。
apiVersion: v1 baseDomain: example.com 1 compute: 2 - name: worker replicas: 0 3 controlPlane: 4 name: master replicas: 1 5 metadata: name: sno-cluster 6 networking: clusterNetwork: - cidr: 10.128.0.0/14 7 hostPrefix: 23 8 networkType: OVNKubernetes 9 serviceNetwork: 10 - 172.30.0.0/16 platform: none: {} 11 fips: false 12 pullSecret: '{"auths": ...}' 13 sshKey: 'ssh-ed25519 AAAA...' 14
- 1
- 集群的基域。所有 DNS 记录都必须是这个基域的子域,并包含集群名称。
- 2 4
controlPlane
部分是一个单个映射,但compute
部分是一系列映射。为满足不同数据结构的要求,compute
部分的第一行必须以连字符-
开头,controlPlane部分
的第一行则不以连字符开头。仅使用一个 control plane 池。- 3
- 此参数控制基于代理的安装在触发安装过程前等待发现的计算机器数量。它是必须使用生成的 ISO 引导的计算机器数量。注意
如果要安装一个三节点集群,在安装 Red Hat Enterprise Linux CoreOS(RHCOS)机器时不要部署任何计算机器。
- 5
- 您添加到集群的 control plane 机器数量。由于集群使用这些值作为集群中的 etcd 端点数量,所以该值必须与您部署的 control plane 机器数量匹配。
- 6
- 您在 DNS 记录中指定的集群名称。
- 7
- 从中分配 Pod IP 地址的 IP 地址块。此块不得与现有物理网络重叠。这些 IP 地址用于 pod 网络。如果需要从外部网络访问 pod,您必须配置负载均衡器和路由器来管理流量。注意
类 E CIDR 范围被保留以供以后使用。要使用 Class E CIDR 范围,您必须确保您的网络环境接受 Class E CIDR 范围内的 IP 地址。
- 8
- 分配给每个节点的子网前缀长度。例如,如果
hostPrefix 设为
23
,则每个节点从 givencidr
中分配 a/23
子网,这样就能有 510(2^(32 - 23)- 2)个 pod IP 地址。如果需要从外部网络访问节点,请配置负载均衡器和路由器来管理流量。 - 9
- 要安装的集群网络插件。默认值
OVNKubernetes
是唯一支持的值。 - 10
- 用于服务 IP 地址的 IP 地址池。您只能输入一个 IP 地址池。此块不得与现有物理网络重叠。如果您需要从外部网络访问服务,请配置负载均衡器和路由器来管理流量。
- 11
- 对于单节点集群,您必须将平台设置为
none
。对于多节点集群,您可以将平台设置为vsphere
、baremetal
或none
。注意如果将平台设置为
vsphere
或baremetal
,您可以以三种方式为集群节点配置 IP 地址端点:- IPv4
- IPv6
- IPv4 和 IPv6 并行 (dual-stack)
双栈网络示例
networking: clusterNetwork: - cidr: 172.21.0.0/16 hostPrefix: 23 - cidr: fd02::/48 hostPrefix: 64 machineNetwork: - cidr: 192.168.11.0/16 - cidr: 2001:DB8::/32 serviceNetwork: - 172.22.0.0/16 - fd03::/112 networkType: OVNKubernetes platform: baremetal: apiVIPs: - 192.168.11.3 - 2001:DB8::4 ingressVIPs: - 192.168.11.4 - 2001:DB8::5
- 12
- 是否启用或禁用 FIPS 模式。默认情况下不启用 FIPS 模式。如果启用了 FIPS 模式,运行 OpenShift Container Platform 的 Red Hat Enterprise Linux CoreOS(RHCOS)机器会绕过默认的 Kubernetes 加密套件,并使用由 RHCOS 提供的加密模块。重要
当以 FIPS 模式运行 Red Hat Enterprise Linux (RHEL) 或 Red Hat Enterprise Linux CoreOS (RHCOS)时,OpenShift Container Platform 核心组件使用 RHEL 加密库,在 x86_64、ppc64le 和 s390x 架构上提交到 NIST FIPS 140-2/140-3 Validation。
- 13
- 此 pull secret 允许您与所含授权机构提供的服务进行身份验证,这些服务包括为 OpenShift Container Platform 组件提供容器镜像的 Quay.io。
- 14
- Red Hat Enterprise Linux CoreOS(RHCOS)中
core
用户的 SSH 公钥。注意对于您要在其上执行安装调试或灾难恢复的生产环境 OpenShift Container Platform 集群,请指定
ssh-agent
进程使用的 SSH 密钥。
11.1.11. 在代理 ISO 创建前验证检查
基于代理的安装程序在创建 ISO 之前对用户定义的 YAML 文件执行验证检查。验证成功后,会创建代理 ISO。
install-config.yaml
-
支持
裸机
,vsphere
和none
平台。 -
如果平台为
none
,则networkType
参数需要为OVNKubernetes
。 -
如果是裸机和 vSphere 平台,则需要设置
apiVIPs
和ingressVIPs
参数。 -
在
agent-config.yaml
文件中,裸机平台配置中有一些特定于主机的字段将被忽略。如果设置了这些字段,则会记录警告消息。
agent-config.yaml
- 每个接口都必须有一个定义的 MAC 地址。另外,所有接口都必须具有不同的 MAC 地址。
- 每个主机必须至少定义一个接口。
- root 设备提示不支持全局名称 (WWN) 供应商扩展。
-
host
对象中的role
参数的值必须是master
或worker
。
11.1.11.1. ZTP 清单
agent-cluster-install.yaml
-
对于 IPv6,
networkType
参数唯一支持的值是OVNKubernetes
。OpenshiftSDN
值只能用于 IPv4。
cluster-image-set.yaml
-
ReleaseImage
参数必须与安装程序中定义的发行版本匹配。