19. 根管理员集群引导

预计完成时间: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

根据集群中的信息,验证上述信息是否正确。如果上述信息准确无误,请运行以下命令。

  1. 停用 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

  2. 配置 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

  3. 重置 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

  4. 验证以太网设置是否已应用。如果响应挂起,则表示重置尚未完成;请取消当前的 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. 准备工作

在部署流程的此阶段,必须满足以下所有条件:

  1. 两个 OIR 交换机均已连接线缆、开启电源、升级到相应版本,并已应用基本配置和 ACL 配置。

  2. 两个 OIF 防火墙均已连接线缆、开机、升级到相应版本、启用 FIPS-CC 模式,并已应用基本配置。

  3. 为了完成整个分布式云连接预配,分布式云实例必须完成网络引导,并从 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:
- zoneName: kb
- uplinkSpeed: 10
localInstanceIDs: 2

remoteInstanceIDs:
- 1
- cellCfg: path/to/cellcfg

- zoneName: ah
- uplinkSpeed: 100
localInstanceIDs: 3

- cellCfg: path/to/cellcfg

19.7.2.2. 可用区选项

用于在 interconnect.yaml 文件中携带有关分布式云单元的信息:

属性
说明
使用情况
zoneName
字符串
OI 部署需要连接到的 Distributed Cloud Cell 缩写。
zones:
- zoneName: kb
uplinkSpeed
uint32
(可选)提供连接的上行速度:(10100)。 值:10100
默认值:10

uplinkSpeed: 100
localInstance
int
ocit.yaml 文件中 OI 部署网站的 InstanceID
本地连接使用同一数据中心内机架之间的光纤连接,将 Operations Suite 基础设施核心机架 (OIR) 站点直接连接到 Distributed Cloud。
zones:
- zoneName: kb
localInstanceIDs: 1
remoteInstance
[ ] int
InstanceID(s)(来自 ocit.yaml 文件)
远程连接使用长途传输连接到其他位置。 可以提供 remoteInstance 值列表,以便生成所有 OIR 站点的配置来连接到给定的 Distributed Cloud 单元。
zones:
- zoneName: kb
remoteInstanceIDs:
- 1



zones:
- zoneName: kb
remoteInstanceIDs:
- 1

- 2

- 3



如果是本地连接,请按如下方式配置 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-routepolicymgmtnetworkoperationcenter-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 网络连接

在部署的这一阶段,必须满足以下条件:

  • occoresw101occoresw102 均使用 baseaclincrementalincremental-acl 配置文件进行配置。
  • ocsw101ocsw102 均使用 baseaclincrementalincremental-acl 配置文件进行配置。
  • occorefw101occoref102 均使用 basefirewall-rules.base 配置文件进行配置。
  • 数据中心与运营中心之间的上行链路已连接并正常运行。
  • 分布式云之间的物理上行链路已通过验证。

如果不满足上述任何条件,则以下输出可能会因当前状态而有很大差异,并且很可能无法在生产环境中产生预期行为。

19.9.1. 预期输出

以下代码段显示了以下命令在已知良好环境中的输出:

  • show ip bgp summary vrf all
  • show ip bgp vrf all
  • show ip route vrf all
  • show lldp neighbors

这些代码段可作为与生产环境进行比较的依据,使用相同的命令即可实现比较。

19.9.2. 密钥验证

以下是您需要在以下输出中重点关注的内容:

  • 没有 BGP 会话处于 IdleActiveClosing 状态。
  • 所有 BGP 会话都显示大于 0State/PrxRcd 值。
  • 所有 BGP 会话都显示一个不断增加的 Up/Down 计时器。
  • 分布式云 externalCIDR 前缀(可在 CIQ 中找到)存在于 GDCH-DATAGDCH-DATA-TRANSITOC-WORKSTATIONSOCCORE-SERVERS VRF 的路由表和 BGP 表中。
  • 分布式云 oobManagementCIDRs(位于 CIQ 中)存在于 GDCH-MGMTGDCH-MGMT-TRANSITHW-INFRA VRF 的路由表和 BGP 表中。

19.9.3. OCCORESW

下表显示了 Distributed Cloud 互联在每个 occore switch 上的预期输出。 您必须先完成所有网络验证,然后才能执行此步骤。 此处讨论的 BGP 邻居和路由应与前面提到的 BGP 邻居和路由一起存在。验证所有开关上的输出。

VRF
BGP 邻居
从 BGP 邻居
收到的预期路由
预期向 BGP 邻居
通告的路由
GDCH-DATA-TRANSIT AGGSW01
  • 为 Distributed Cloud Cell 添加了汇总摘要地址(子网为 /19)
  • OCCORE-SERVERS 前缀
  • OC-WORKSTATION 前缀
GDCH-DATA-TRANSIT AGGSW02
  • 为 Distributed Cloud Cell 添加了汇总摘要地址(子网为 /19)
  • OCCORE-SERVERS 前缀
  • OC-WORKSTATION 前缀
GDCH-DATA-TRANSIT 使用 OCCOREFW 到 OC-DATA VRF 的 HairPinned BGP 会话
  • 分布式云单元的汇总摘要地址(带有子网 /19)
OC-DATA OCSW01 BGP 会话
  • 分布式云单元的汇总摘要地址(带有子网 /19)
OC-DATA OCSW02 BGP 会话
  • 分布式云单元的汇总摘要地址(带有子网 /19)
OC-DATA OCCORESW BGP 会话
  • 分布式云单元的汇总摘要地址(带有子网 /19)
GDCH-MGMT-TRANSIT MGMTAGGSW01
  • 所有 GDCH OOB 管理网络的汇总摘要地址(子网为 /24)
  • OCCORE-JUMPHOSTS 前缀
  • OCCORE-ILOS 前缀
GDCH-MGMT-TRANSIT MGMTAGGSW02
  • 所有分布式云 OOB 管理网络的汇总摘要地址(子网为 /24)
  • OCCORE-JUMPHOSTS 前缀
  • OCCORE-ILOS 前缀
GDCH-MGMT-TRANSIT 使用 OCCOREFW 从 HW-INFRA VRF 到 HairPinned BGP 会话
  • 所有分布式云 OOB 管理网络的汇总摘要地址(子网为 /24)

19.9.4. OCSW

下表显示了执行分布式云互联程序后,每个 oc switch 上的预期输出。 您必须先完成所有网络验证,然后才能执行此步骤。 此处讨论的 BGP 邻居和路由应与前面提到的 BGP 邻居和路由一起存在。验证所有开关上的输出。

VRF
BGP 邻居
从 BGP 邻居
收到的预期路由
OC-DATA OCCORESW01 BGP 会话
  • GDCH 单元格的汇总摘要地址(带有子网 /19)
OC-DATA OCCORESW02 BGP 会话
  • GDCH 单元格的汇总摘要地址(带有子网 /19)

您可以在分布式云验证显示命令中找到输出命令代码段。

19.9.5. 多网站 OI 部署验证

以下部分详细介绍了如何验证具有多个互连的 Distributed Cloud Cell 的多站点部署。 在此阶段,包含两个站点的拓扑如下所示:

两个通过 2 个 GDCH 单元互连的 OC IT 站点

  • 蓝色连接表示站点 1 连接到 Distributed Cloud Cell 01 和 Cell 02。
  • 红色连接表示站点 2 连接到 Distributed Cloud Cell 01 和 Cell 02。
  • 绿色连接表示网站 1 和网站 2 的互连。

对于所有交换机上的所有网站,您必须完成以下部分中列出的步骤

  1. 网络验证
  2. 网络多站点验证
  3. 网络分布式云验证

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 命令搭配使用,以继续执行根管理员引导。