预计完成时间:7 小时
可操作组件所有者:KUB/SERV/OBJ/FILE/PNET技能配置文件:部署工程师
本指南将创建一个根管理员集群,该集群将充当内部集群和组织基础架构集群的控制平面。
19.1. 设置路由配置
确认在 Bootstrapper 服务器安装期间已添加静态路由。 如果缺少静态路由,请向引导加载程序添加静态路由:
DATA_CIDR=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -o jsonpath={.spec.ipv4Spec.staticCidrBlocks[0]})
DATA_GATEWAY=$(kubectl get subnetclaims -n root control-plane-subnet -o jsonpath={.status.ipv4SubnetStatus.gateway})
ip route replace ${DATA_CIDR} via ${DATA_GATEWAY}
此路由可从引导加载程序的 Dataplane 接口访问根管理员集群的 API 服务器。如需详细了解 GDC 中的 API 服务器,请参阅全球级和可用区级 API 服务器。
19.2. 创建根管理员集群
以下命令会创建一个包含三个控制平面节点的根管理员集群。默认租户模式为多租户模式。
gdcloud system admin-cluster install -v=3 \
--tenant-mode=multi \
--root-admin-node-count=3 \
--generate-admin-yaml \
--addon-manager-manifests-set harbor.postgresqlHA.enabled=true \
--addon-manager-manifests-set harbor.productionEnvironment.enabled=true \
--addon-manager-manifests-set storage.mode=ontap \
--addon-manager-manifests-set gpuFeature.enabled=true \
--addon-manager-manifests-set rootAdmin.controller.adminLBPoolSize=23 \
--addon-manager-manifests-set rootAdmin.controller.systemLBPoolSize=60 \
--addon-manager-manifests-set network.noInternalSubnet=false \
--addon-manager-manifests-set minStage=FEATURE_THRESHOLD
创建根管理员集群需要集群 CR 的配置文件。默认情况下,系统会自动生成配置。您还可以通过将标志 --generate-admin-yaml 设置为 false 并指定 --admin-yaml-path 以指向目标配置路径,来自定义集群配置。
根管理员集群安装完成后,根管理员集群的 kubeconfig 会存储在 /root/release/root-admin/root-admin-kubeconfig 中。
集群安装完成后,系统会输出用户管理员用户界面 (UI) 的网址。请记住该值,以便在后续操作中使用。您还可以使用以下命令检索该值:
gdcloud system admin-cluster describe
19.3. 将组件部署到根管理员集群
以下命令会将可操作的组件生命周期模板部署到根管理员集群。
gdcloud system component deploy --kubeconfig KUBECONFIG --names=* --pivot-from=/root/.kube/config
19.4. 为根管理员配置功能门
如果您使用的功能阶段阈值不同于 production,则必须按照 OOPS-P0072 中的说明,相应地更新功能门,以与该阈值保持一致。
19.5. 在引导加载程序上配置桩解析器
使用以下命令在引导加载程序上设置 DNS 桩解析器。需要此桩解析器才能访问控制台。
gdcloud system dns install
此配置可确保所有组织的域名都可从引导加载程序解析,如下图所示:

19.6. 设置 iLo IP 地址
以下步骤将管理节点的 ILO IP 地址设置为 static。
ADMIN_NODE=NODE NAME
RACK=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.metadata.labels.system\.private\.gdc\.goog/rack-name}')
ILO_IP=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.ip}')
ILO_GATEWAY=$(kubectl --kubeconfig KUBECONFIG get subnetclaims -n root $RACK-mgmtsw01-server-bmc-subnet -o jsonpath='{.status.ipv4SubnetStatus.gateway}')
BMC_CREDS=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.credentialsRef.name}')
ILO_USER=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.username}' | base64 --decode)
ILO_PASS=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.password}' | base64 --decode)
echo Target Server: $ADMIN_NODE
echo ILO IP: $ILO_IP
echo ILO Gateway: $ILO_GATEWAY
echo ILO Username: $ILO_USER
echo ILO Password: $ILO_PASS
根据集群中的信息,验证上述信息是否正确。如果上述信息准确无误,请运行以下命令。
停用 DHCP。
curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"DHCPv4": {"DHCPEnabled": false}}' | jq '.'预期结果:
MessageId: iLO.2.15.ResetRequired配置 IP 地址和网关。
curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"IPv4Addresses":[{"Address":"'${ILO_IP}'","Gateway":"'${ILO_GATEWAY}'","SubnetMask":"255.255.255.0"}],"IPv4StaticAddresses": [{"Address": "'${ILO_IP}'", "Gateway": "'${ILO_GATEWAY}'", "SubnetMask": "255.255.255.0"}]}' | jq .预期结果:
MessageId: Base.1.4.Success重置 iLO 管理器。
curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq .预期结果:
MessageId: iLO.2.15.ResetInProgress验证以太网设置是否已应用。如果响应挂起,则表示重置尚未完成;请取消当前的 curl 命令,然后等待 20 秒后重试。
curl --insecure -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 -X GET | jq .
通过验证每个步骤的 HTTP 返回是否与其预期结果一致来确认成功。
针对集群中的所有根管理员节点重复上述步骤。
19.7. 建立 OI 网络和 Google Distributed Cloud (GDC) 经过网闸隔离的连接
本部分介绍了如何预配配置文件,以便 Operations Suite 基础架构 (OI) 和 Distributed Cloud 网络建立连接。
这些步骤需要访问一些 Distributed Cloud 文件,并且需要连接到 Distributed Cloud 实例的根管理员集群,才能检索运行时网络信息。
19.7.1. 准备工作
在部署流程的此阶段,必须满足以下所有条件:
两个 OIR 交换机均已连接线缆、开启电源、升级到相应版本,并已应用基本配置和 ACL 配置。
两个 OIF 防火墙均已连接线缆、开机、升级到相应版本、启用 FIPS-CC 模式,并已应用基本配置。
为了完成整个分布式云连接预配,分布式云实例必须完成网络引导,并从 kind 集群迁移到根管理员集群。
19.7.2. 准备环境
收集以下信息并设置环境变量,为后续步骤准备环境。
OI 可以通过两种方式连接:本地连接或远程连接。本地连接使用同一数据中心内机架之间的光纤连接,将 OI 直接连接到 Distributed Cloud。远程连接使用长距离传输连接到其他位置。此规范可在 interconnect.yaml 文件中提供,该文件是预配 Distributed Cloud 互连配置所必需的。
此文件包含配置 GDC 互连所需的所有信息。
19.7.2.1. 互连 YAML 规范
| 属性 |
说明 |
示例 |
|---|---|---|
zones[ ] 地图 |
有关 OI 部署需要连接到的 Distributed Cloud Cell 的信息。 如需连接到一系列分布式 Cloud 单元,请指定一个 列表,其中包含每个可用区中每个分布式 Cloud 单元的信息。 zones可用区选项 |
示例:zones: |
19.7.2.2. 可用区选项
用于在 interconnect.yaml 文件中携带有关分布式云单元的信息:
| 属性 |
说明 |
使用情况 |
|---|---|---|
zoneName字符串 |
OI 部署需要连接到的 Distributed Cloud Cell 缩写。 | zones: |
uplinkSpeeduint32 |
(可选)提供连接的上行速度:(10 或 100)。
|
值:10、100默认值: 10uplinkSpeed: 100 |
localInstanceint |
ocit.yaml 文件中 OI 部署网站的 InstanceID。本地连接使用同一数据中心内机架之间的光纤连接,将 Operations Suite 基础设施核心机架 (OIR) 站点直接连接到 Distributed Cloud。 |
zones: |
remoteInstance[ ] int |
InstanceID(s)(来自 ocit.yaml 文件)远程连接使用长途传输连接到其他位置。 可以提供 remoteInstance 值列表,以便生成所有 OIR 站点的配置来连接到给定的 Distributed Cloud 单元。
|
zones: zones: |
如果是本地连接,请按如下方式配置 interconnect.yaml 文件:
zones:
- zoneName: ah
uplinkSpeed: 100
localInstanceID: 1
cellCfg: /path/to/cellcfg
如果这是远程连接,请将 interconnect.yaml 文件配置为:
zones:
- zoneName: ah
uplinkSpeed: 100
remoteInstanceIDs:
- 2
cellCfg: /path/to/cellcfg
对于多站点 OI 部署,请将 interconnect.yaml 文件指定为:
zones:
- zoneName: ah
uplinkSpeed: 100
localInstanceID: 1
remoteInstanceIDs:
- 2
cellCfg: /path/to/cellcfg
19.7.3. 生成开关配置
这些步骤会生成补丁配置,以应用于网络设备,从而为 Distributed Cloud 配置连接。
occonfigtool generate cell config -c /path/to/interconnect.yaml -o path/to/ocit.yaml
这会为每个网站生成以下配置文件:
| 配置文件 | 设备 | 函数 |
|---|---|---|
| occoresw101.incremental | occoresw101 | 用于修补设备以连接到 Distributed Cloud 实例的配置 |
| occoresw101.acl | occoresw101 | 配置,用于修补 ACL 以通过分布式云网络强制执行流量。 |
| occoresw102.incremental | occoresw102 | 用于修补设备以连接到 Distributed Cloud 实例的配置 |
| occoresw102.acl | occoresw102 | 配置,用于修补 ACL 以通过分布式云网络强制执行流量。 |
| ocsw101.incremental | ocs1w01 | 用于修补设备以连接到 Distributed Cloud 实例的配置 |
| ocsw101.acl | ocsw101 | 配置,用于修补 ACL 以通过分布式云网络强制执行流量。 |
| ocsw102.incremental | ocsw102 | 用于修补设备以连接到 Distributed Cloud 实例的配置 |
| ocsw102.acl | ocsw102 | 配置,用于修补 ACL 以通过分布式云网络强制执行流量。 |
19.7.4. 生成防火墙政策
为了生成防火墙规则,occonfigtool 需要访问根管理员集群的 Kubernetes API。确保 KUBECONFIG 环境变量已设置为 root-admin-kubeconfig:
export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export OCIT_CONFIG_FILE=/path/to/ocit.yaml
运行以下命令以生成防火墙规则:
occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}
| 配置文件 | 设备 | 函数 |
|---|---|---|
| firewall-rules.base | occorefw01 | 用于修补设备以连接到 Distributed Cloud 实例的配置 |
19.7.5. 应用配置
使用输出文件,按照与上一步中交换机和防火墙相同的流程,将配置应用于相应的网络设备。
19.8. 更新分布式 Cloud RoutePolicy 资源
分布式云使用路由政策来强制执行哪些网络可以通告到路由表中。
将 OI 添加为外部网络时,我们需要更新 RoutePolicy CR 以预期新网络。
这需要使用 kubectl 访问 root-admin-cluster。确保已设置相应的 KUBECONFIG 变量:
export KUBECONFIG=/root/deploy/root-admin/root-admin-kubeconfig
如需确认,请执行以下操作:
kubectl get routepolicy -n gpc-system
您应该会看到以下输出(或类似输出):
NAME AGE
customerpeering-routepolicy 19d
datacenter-routepolicy 19d
mgmtnetworkoperationcenter-routepolicy 19d
networkoperationcenter-routepolicy 19d
在这些步骤中,我们将重点介绍 networkoperationcenter-routepolicy 和 mgmtnetworkoperationcenter-routepolicy。
19.8.1.1. 修补数据网络路由政策
从 ocinfo.opscenter.local.txt 中检索以下子网(包括网络和前缀长度)。
- OCCORE-SERVERS,在以下示例中用作
$OCCORE_SERVERS_NET - OC-WORKSTATIONS,在以下示例中用作
$OC_WORKSTATIONS_NET
使用以下值填充以下变量,以调整路由政策:
export OCCORE_SERVERS_NET=$OCCORE_SERVERS_NET
export OC_WORKSTATIONS_NET=$OC_WORKSTATIONS_NET
例如:
export OCCORE_SERVERS_NET=172.21.0.0/24
export OC_WORKSTATIONS_NET=172.21.32.0/24
设置环境变量后,运行以下 kubectl 命令:
kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OCCORE_SERVERS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OC_WORKSTATIONS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
输出示例:
routepolicy.system.private.gdc.goog/networkoperationcenter-routepolicy patched
19.8.1.2. 补丁管理网络路由政策
从 ocinfo.opscenter.local.txt 中检索以下子网(包括网络和前缀长度)。
- OCCORE-JUMPHOSTS,在以下示例中用作
$OCCORE_JUMPHOSTS_NET - OCCORE-ILOS,在以下示例中用作
$OCCORE_ILOS_NET
使用以下值填充以下变量,以调整路由政策:
export OCCORE_JUMPHOSTS_NET=$OCCORE_JUMPHOSTS_NET
export OCCORE_ILOS_NET=$OCCORE_ILOS_NET
例如:
export OCCORE_JUMPHOSTS_NET=172.21.2.0/27
export OCCORE_ILOS_NET=172.21.2.32/27
设置环境变量后,运行以下 kubectl 命令:
kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OCCORE_JUMPHOSTS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OCCORE_ILOS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
输出示例:
routepolicy.system.private.gdc.goog/mgmtnetworkoperationcenter-routepolicy patched
19.9. 验证 OI Distributed Cloud 网络连接
在部署的这一阶段,必须满足以下条件:
occoresw101和occoresw102均使用base、acl、incremental和incremental-acl配置文件进行配置。ocsw101和ocsw102均使用base、acl、incremental和incremental-acl配置文件进行配置。occorefw101和occoref102均使用base和firewall-rules.base配置文件进行配置。- 数据中心与运营中心之间的上行链路已连接并正常运行。
- 分布式云之间的物理上行链路已通过验证。
如果不满足上述任何条件,则以下输出可能会因当前状态而有很大差异,并且很可能无法在生产环境中产生预期行为。
19.9.1. 预期输出
以下代码段显示了以下命令在已知良好环境中的输出:
show ip bgp summary vrf allshow ip bgp vrf allshow ip route vrf allshow lldp neighbors
这些代码段可作为与生产环境进行比较的依据,使用相同的命令即可实现比较。
19.9.2. 密钥验证
以下是您需要在以下输出中重点关注的内容:
- 没有 BGP 会话处于
Idle、Active或Closing状态。 - 所有 BGP 会话都显示大于
0的State/PrxRcd值。 - 所有 BGP 会话都显示一个不断增加的
Up/Down计时器。 - 分布式云
externalCIDR前缀(可在 CIQ 中找到)存在于GDCH-DATA、GDCH-DATA-TRANSIT、OC-WORKSTATIONS和OCCORE-SERVERSVRF 的路由表和 BGP 表中。 - 分布式云
oobManagementCIDRs(位于 CIQ 中)存在于GDCH-MGMT、GDCH-MGMT-TRANSIT和HW-INFRAVRF 的路由表和 BGP 表中。
19.9.3. OCCORESW
下表显示了 Distributed Cloud 互联在每个 occore switch 上的预期输出。
您必须先完成所有网络验证,然后才能执行此步骤。
此处讨论的 BGP 邻居和路由应与前面提到的 BGP 邻居和路由一起存在。验证所有开关上的输出。
| VRF |
BGP 邻居 |
从 BGP 邻居 收到的预期路由 |
预期向 BGP 邻居 通告的路由 |
|---|---|---|---|
| GDCH-DATA-TRANSIT | AGGSW01 |
|
|
| GDCH-DATA-TRANSIT | AGGSW02 |
|
|
| GDCH-DATA-TRANSIT | 使用 OCCOREFW 到 OC-DATA VRF 的 HairPinned BGP 会话 |
|
|
| OC-DATA | OCSW01 BGP 会话 |
|
|
| OC-DATA | OCSW02 BGP 会话 |
|
|
| OC-DATA | OCCORESW BGP 会话 |
|
|
| GDCH-MGMT-TRANSIT | MGMTAGGSW01 |
|
|
| GDCH-MGMT-TRANSIT | MGMTAGGSW02 |
|
|
| GDCH-MGMT-TRANSIT | 使用 OCCOREFW 从 HW-INFRA VRF 到 HairPinned BGP 会话 |
|
19.9.4. OCSW
下表显示了执行分布式云互联程序后,每个 oc switch 上的预期输出。
您必须先完成所有网络验证,然后才能执行此步骤。
此处讨论的 BGP 邻居和路由应与前面提到的 BGP 邻居和路由一起存在。验证所有开关上的输出。
| VRF |
BGP 邻居 |
从 BGP 邻居 收到的预期路由 |
|---|---|---|
| OC-DATA | OCCORESW01 BGP 会话 |
|
| OC-DATA | OCCORESW02 BGP 会话 |
|
您可以在分布式云验证显示命令中找到输出命令代码段。
19.9.5. 多网站 OI 部署验证
以下部分详细介绍了如何验证具有多个互连的 Distributed Cloud Cell 的多站点部署。 在此阶段,包含两个站点的拓扑如下所示:

- 蓝色连接表示站点 1 连接到 Distributed Cloud Cell 01 和 Cell 02。
- 红色连接表示站点 2 连接到 Distributed Cloud Cell 01 和 Cell 02。
- 绿色连接表示网站 1 和网站 2 的互连。
对于所有交换机上的所有网站,您必须完成以下部分中列出的步骤
19.10. 执行 OI 网络最终步骤
在此阶段,所有配置都必须已生成并应用于所有设备。
网络访问控制列表现在处于允许特定预期流量的状态,但同时还具有允许所有流量的默认规则。
您现在必须将部署移交给运营团队。运营套件的功能、实现方式和提供的服务因客户而异。因此,它对流量的要求各不相同。
运营团队接受部署后,其任务是处理 ACL 并全面保护网络流量。
我们提供了操作手册来执行这些任务。
19.11. 升级对象存储
在对象存储启动期间,节点安装了 StorageGRID 的最新受支持次要版本。不过,目标版本可能需要更新到最新的紧急修复补丁版本。
使用以下命令从版本元数据中确定目标 StorageGRID 版本:
kubectl get releasemetadata -o jsonpath='{.items[0].spec.infraComponents.objectStorage.storageGridOSImageVersion}'
如果 StorageGRID 的当前版本不是目标版本,请使用目标版本执行对象存储升级。
19.12. 潜在问题
19.12.1. 存储虚拟机未协调
总结:在创建根管理员集群期间,存储虚拟机未就绪。
问题:创建根管理员集群后,存储虚拟机资源无法协调,并显示类似如下的警告事件:
StorageVirtualMachine Reconcile error, retrying: SVM status update failed,
error: failed to get network interface info: Get
"https://172.22.147.128/api/network/ip/interfaces?fields=%2A%2A&max_records=4096&svm.name=root-admin":
EOF
存储集群上出于安全原因而阻止 SSL 的配置错误可能会导致此问题。
解决方法:
使用 SSH 连接到序列或存储集群,然后运行以下命令:
security ssl modify -server-enabled true -client-enabled true -vserver
CELL_ID-stge-clus-01
连接后,存储虚拟机资源能够进行协调。
19.12.2. 在防火墙 TLS 服务器证书安装时,引导失败
在执行第 20 步中描述的根管理员控制平面引导任务时,您可能会遇到 TLSServerCertification 失败。
解决方法:
如需重新尝试安装防火墙服务器证书,请参阅 IO 服务手册 FW-R1008 中列出的说明。成功完成安装后,请将 gdcloud 命令与 --start-phase 命令搭配使用,以继续执行根管理员引导。