6.2. 将 RHCOS 计算机器添加到 OpenShift Container Platform 集群

您可以在裸机上的 OpenShift Container Platform 集群中添加更多 Red Hat Enterprise Linux CoreOS（RHCOS）计算机器。

在将更多计算机器添加到在裸机基础架构上安装的集群之前，必须先创建 RHCOS 机器供其使用。您可以使用 ISO 镜像或网络 PXE 引导来创建机器。

6.2.1. 先决条件

您在裸机上安装了集群。
您有用来创建集群的安装介质和 Red Hat Enterprise Linux CoreOS（RHCOS）镜像。如果您没有这些文件，需要按照安装过程的说明获得这些文件。

6.2.2. 使用 ISO 镜像创建更多 RHCOS 机器

您可以使用 ISO 镜像为裸机集群创建更多 Red Hat Enterprise Linux CoreOS（RHCOS）计算机器，以创建机器。

先决条件

获取集群计算机器的 Ignition 配置文件的 URL。在安装过程中将该文件上传到 HTTP 服务器。

流程

使用 ISO 文件在更多计算机器上安装 RHCOS。在安装集群前，使用创建机器时使用的相同方法：
- 将 ISO 镜像刻录到磁盘并直接启动。
- 在 LOM 接口中使用 ISO 重定向。
在不指定任何选项或中断实时引导序列的情况下引导 RHCOS ISO 镜像。等待安装程序在 RHCOS live 环境中引导进入 shell 提示符。
注意
您可以中断 RHCOS 安装引导过程来添加内核参数。但是，在这个 ISO 过程中，您应该使用以下步骤中所述的 coreos-installer 命令，而不是添加内核参数。
运行 coreos-installer 命令并指定满足您的安装要求的选项。您至少必须指定指向节点类型的 Ignition 配置文件的 URL，以及您要安装到的设备：
```
$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12
```
1
您必须使用 sudo 运行 coreos-installer 命令，因为 core 用户没有执行安装所需的 root 权限。
2
当 Ignition 配置文件通过 HTTP URL 获取时，需要 --ignition-hash 选项来验证集群节点上 Ignition 配置文件的真实性。<digest> 是上一步中获取的 Ignition 配置文件 SHA512 摘要。
注意
如果要通过使用 TLS 的 HTTPS 服务器提供 Ignition 配置文件，您可以在运行 coreos-installer 前将内部证书颁发机构(CA)添加到系统信任存储中。
以下示例将引导节点安装初始化到 /dev/sda 设备。bootstrap 节点的 Ignition 配置文件从 IP 地址 192.168.1.2 的 HTTP Web 服务器获取：
```
$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
```
在机器的控制台上监控 RHCOS 安装的进度。
重要
在开始安装 OpenShift Container Platform 之前，确保每个节点中安装成功。观察安装过程可以帮助确定可能会出现 RHCOS 安装问题的原因。
继续为集群创建更多计算机器。

6.2.3. 通过 PXE 或 iPXE 启动来创建更多 RHCOS 机器

您可以使用 PXE 或 iPXE 引导为裸机集群创建更多 Red Hat Enterprise Linux CoreOS（RHCOS）计算机器。

先决条件

获取集群计算机器的 Ignition 配置文件的 URL。在安装过程中将该文件上传到 HTTP 服务器。
获取您在集群安装过程中上传到 HTTP 服务器的 RHCOS ISO 镜像、压缩的裸机 BIOS、kernel 和 initramfs 文件的 URL。
您可以访问在安装过程中为 OpenShift Container Platform 集群创建机器时使用的 PXE 引导基础架构。机器必须在安装 RHCOS 后从本地磁盘启动。
如果使用 UEFI，您可以访问在 OpenShift Container Platform 安装过程中修改的 grub.conf 文件。

流程

确认 RHCOS 镜像的 PXE 或 iPXE 安装正确。
- 对于 PXE：
```
DEFAULT pxeboot
TIMEOUT 20
PROMPT 0
LABEL pxeboot
    KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
    APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2
```
  1
  指定上传到 HTTP 服务器的 live kernel 文件位置。
  2
  指定上传到 HTTP 服务器的 RHCOS 文件的位置。initrd 参数值是 live initramfs 文件的位置，coreos.inst.ignition_url 参数值是 worker Ignition 配置文件的位置，coreos.live.rootfs_url 参数值是 live rootfs 文件的位置。coreos.inst.ignition_url 和 coreos.live.rootfs_url 参数仅支持 HTTP 和 HTTPS。

此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台，请在 APPEND 行中添加一个或多个 console= 参数。例如，添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台，并将图形控制台设置为二级控制台。如需更多信息，请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台？

对于 iPXE：
```
kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 1
initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 2
```
1
指定上传到 HTTP 服务器的 RHCOS 文件的位置。kernel 参数值是 kernel 文件的位置，在 UEFI 系统中引导时需要 initrd=main 参数。 coreos.inst.ignition_url 参数值是 worker Ignition 配置文件的位置，coreos.live.rootfs_url 参数值则是 live rootfs 文件的位置。coreos.inst.ignition_url 和 coreos.live.rootfs_url 参数仅支持 HTTP 和 HTTPS。
2
指定上传到 HTTP 服务器的 initramfs 文件的位置。

此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台，请在 内核参数 中添加一个或多个 console= 参数。例如，添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台，并将图形控制台设置为二级控制台。如需更多信息，请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和（或）控制台？

使用 PXE 或 iPXE 基础架构为集群创建所需的计算机器。

6.2.4. 批准机器的证书签名请求

当您将机器添加到集群时，会为您添加的每台机器生成两个待处理证书签名请求(CSR)。您必须确认这些 CSR 已获得批准，或根据需要自行批准。必须首先批准客户端请求，然后批准服务器请求。

先决条件

您已将机器添加到集群中。

流程

确认集群可以识别这些机器：
```
$ oc get nodes
```
输出示例
```
NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.23.0
master-1  Ready     master  63m  v1.23.0
master-2  Ready     master  64m  v1.23.0
```
输出中列出了您创建的所有机器。
注意
在有些 CSR 被批准前，前面的输出可能不包括计算节点（也称为 worker 节点）。

检查待处理的 CSR，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端请求：

$ oc get csr

输出示例

NAME        AGE     REQUESTOR                                                                   CONDITION
csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...

在本例中，两台机器加入集群。您可能会在列表中看到更多已批准的 CSR。

如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：
注意
由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后，Kubelet 为服务证书创建一个二级 CSR，这需要手动批准。然后，如果 Kubelet 请求具有相同参数的新证书，则后续提供证书续订请求由 machine-approver 自动批准。
注意
对于在未启用机器 API 的平台上运行的集群，如裸机和其他用户置备的基础架构，您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。
- 要单独批准，请对每个有效的 CSR 运行以下命令：
```
$ oc adm certificate approve <csr_name> 1
```
  1
  <csr_name> 是当前 CSR 列表中 CSR 的名称。
- 要批准所有待处理的 CSR，请运行以下命令：
```
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
```
  注意
  在有些 CSR 被批准前，一些 Operator 可能无法使用。

现在，您的客户端请求已被批准，您必须查看添加到集群中的每台机器的服务器请求：

$ oc get csr

输出示例

NAME        AGE     REQUESTOR                                                                   CONDITION
csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
...

如果剩余的 CSR 没有被批准，且处于 Pending 状态，请批准集群机器的 CSR：
- 要单独批准，请对每个有效的 CSR 运行以下命令：
```
$ oc adm certificate approve <csr_name> 1
```
  1
  <csr_name> 是当前 CSR 列表中 CSR 的名称。
- 要批准所有待处理的 CSR，请运行以下命令：
```
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
```

批准所有客户端和服务器 CSR 后，机器将 处于 Ready 状态。运行以下命令验证：

$ oc get nodes

输出示例

NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.23.0
master-1  Ready     master  73m  v1.23.0
master-2  Ready     master  74m  v1.23.0
worker-0  Ready     worker  11m  v1.23.0
worker-1  Ready     worker  11m  v1.23.0

注意

批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态。

其他信息

如需有关 CSR 的更多信息，请参阅证书签名请求。

6.2.5. 在 AWS 中使用自定义 `/var` 分区添加新的 RHCOS worker 节点

OpenShift Container Platform 使用 bootstrap 过程中完成的机器配置支持在安装过程中分区设备。但是，如果您使用 /var 分区，该设备名称必须在安装时确定，且不可更改。如果节点具有不同的设备命名模式，则无法将不同的实例类型添加为节点。例如，如果您将 /var 分区配置为 m4.large 实例的默认 AWS 设备名称，dev/xvdb，则无法直接添加 AWS m5.large 实例，因为 m5.large 实例默认使用 /dev/nvme1n1 设备。由于不同的命名模式，设备可能无法分区。

本节中的步骤演示了如何使用与安装时配置的不同设备名称的实例添加新的 Red Hat Enterprise Linux CoreOS(RHCOS)计算节点。您可以创建自定义用户数据 secret 并配置新机器集。这些步骤特定于 AWS 集群。其原则也适用于其他云部署。但是，针对其他部署的设备命名模式会有所不同，应该根据具体情况进行决定。

流程

在命令行中更改为 openshift-machine-api 命名空间：
```
$ oc project openshift-machine-api
```

从 worker-user-data secret 创建新 secret：

将 secret 的 userData 部分导出到文本文件：

$ oc get secret worker-user-data --template='{{index .data.userData | base64decode}}' | jq > userData.txt

编辑文本文件，为要用于新节点的分区添加 storage, filesystems, 和 systemd 小节。您可以根据需要指定任何 Ignition 配置参数。

注意

不要更改 ignition 小节中的值。

{
  "ignition": {
    "config": {
      "merge": [
        {
          "source": "https:...."
        }
      ]
    },
    "security": {
      "tls": {
        "certificateAuthorities": [
          {
            "source": "data:text/plain;charset=utf-8;base64,.....=="
          }
        ]
      }
    },
    "version": "3.2.0"
  },
  "storage": {
    "disks": [
      {
        "device": "/dev/nvme1n1", 1
        "partitions": [
          {
            "label": "var",
            "sizeMiB": 50000, 2
            "startMiB": 0 3
          }
        ]
      }
    ],
    "filesystems": [
      {
        "device": "/dev/disk/by-partlabel/var", 4
        "format": "xfs", 5
        "path": "/var" 6
      }
    ]
  },
  "systemd": {
    "units": [ 7
      {
        "contents": "[Unit]\nBefore=local-fs.target\n[Mount]\nWhere=/var\nWhat=/dev/disk/by-partlabel/var\nOptions=defaults,pquota\n[Install]\nWantedBy=local-fs.target\n",
        "enabled": true,
        "name": "var.mount"
      }
    ]
  }
}

1: 指定 AWS 块设备的绝对路径。
2: 指定以兆字节为单位的数据分区大小。
3: 指定以兆字节为单位的分区的开头。当在引导磁盘中添加数据分区时，推荐最少使用 25000 MB(Mebibytes)。root 文件系统会自动调整大小以填充所有可用空间（最多到指定的偏移值）。如果没有指定值，或者指定的值小于推荐的最小值，则生成的 root 文件系统会太小，而在以后进行的 RHCOS 重新安装可能会覆盖数据分区的开始部分。
4: 指定到 /var 分区的绝对路径。
5: 指定文件系统格式。
6: 指定文件系统的挂载点，而 Ignition 运行时相对于根文件系统挂载的位置。这不一定与应在真实 root 中挂载的位置相同，但鼓励使其相同的位置。
7: 定义将 /dev/disk/by-partlabel/var 设备挂载到 /var 分区的 systemd 挂载单元。

将 disableTemplating 部分从 work-user-data secret 提取到文本文件：

$ oc get secret worker-user-data --template='{{index .data.disableTemplating | base64decode}}' | jq > disableTemplating.txt

从两个文本文件创建新用户数据机密文件。此用户数据 secret 将 userData.txt 文件中的额外节点分区信息传递给新创建的节点。
```
$ oc create secret generic worker-user-data-x5 --from-file=userData=userData.txt --from-file=disableTemplating=disableTemplating.txt
```

为新节点创建新机器集：

创建新的机器集 YAML 文件，类似于为 AWS 配置的文件。添加所需分区和新创建的用户数据 secret：

提示

使用现有机器集作为模板，并根据需要更改新节点的参数。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: auto-52-92tf4
  name: worker-us-east-2-nvme1n1 1
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: auto-52-92tf4
      machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: auto-52-92tf4
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
    spec:
      metadata: {}
      providerSpec:
        value:
          ami:
            id: ami-0c2dbd95931a
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
          - DeviceName: /dev/nvme1n1 2
            ebs:
              encrypted: true
              iops: 0
              volumeSize: 120
              volumeType: gp2
          - DeviceName: /dev/nvme1n2 3
            ebs:
              encrypted: true
              iops: 0
              volumeSize: 50
              volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: auto-52-92tf4-worker-profile
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          metadata:
            creationTimestamp: null
          placement:
            availabilityZone: us-east-2b
            region: us-east-2
          securityGroups:
          - filters:
            - name: tag:Name
              values:
              - auto-52-92tf4-worker-sg
          subnet:
            id: subnet-07a90e5db1
          tags:
          - name: kubernetes.io/cluster/auto-52-92tf4
            value: owned
          userDataSecret:
            name: worker-user-data-x5 4

1: 为新节点指定名称。
2: 指定到 AWS 块设备的绝对路径，这里是一个加密的 EBS 卷。
3: 可选的。指定附加 EBS 卷。
4: 指定用户数据 secret 文件。

创建机器集：
```
$ oc create -f <file-name>.yaml
```
机器可能需要一些时间才可用。

验证新分区和节点是否已创建：

验证是否已创建机器集：

$ oc get machineset

输出示例

NAME                                               DESIRED   CURRENT   READY   AVAILABLE   AGE
ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1a        1         1         1       1           124m
ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1b        2         2         2       2           124m
worker-us-east-2-nvme1n1                           1         1         1       1           2m35s 1

1: 这是新机器集。

验证新节点是否已创建：

$ oc get nodes

输出示例

NAME                           STATUS   ROLES    AGE     VERSION
ip-10-0-128-78.ec2.internal    Ready    worker   117m    v1.23.0+60f5a1c
ip-10-0-146-113.ec2.internal   Ready    master   127m    v1.23.0+60f5a1c
ip-10-0-153-35.ec2.internal    Ready    worker   118m    v1.23.0+60f5a1c
ip-10-0-176-58.ec2.internal    Ready    master   126m    v1.23.0+60f5a1c
ip-10-0-217-135.ec2.internal   Ready    worker   2m57s   v1.23.0+60f5a1c 1
ip-10-0-225-248.ec2.internal   Ready    master   127m    v1.23.0+60f5a1c
ip-10-0-245-59.ec2.internal    Ready    worker   116m    v1.23.0+60f5a1c

1: 这是新节点。

验证新节点上是否创建了自定义 /var 分区：

$ oc debug node/<node-name> -- chroot /host lsblk

例如：

$ oc debug node/ip-10-0-217-135.ec2.internal -- chroot /host lsblk

输出示例

NAME        MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT
nvme0n1     202:0    0   120G  0 disk
|-nvme0n1p1 202:1    0     1M  0 part
|-nvme0n1p2 202:2    0   127M  0 part
|-nvme0n1p3 202:3    0   384M  0 part /boot
`-nvme0n1p4 202:4    0 119.5G  0 part /sysroot
nvme1n1     202:16   0    50G  0 disk
`-nvme1n1p1 202:17   0  48.8G  0 part /var 1

1: nvme1n1 设备被挂载到 /var 分区。

其他资源

如需有关 OpenShift Container Platform 如何使用磁盘分区的更多信息，请参阅磁盘分区。

6.2. 将 RHCOS 计算机器添加到 OpenShift Container Platform 集群

6.2.1. 先决条件

6.2.2. 使用 ISO 镜像创建更多 RHCOS 机器

6.2.3. 通过 PXE 或 iPXE 启动来创建更多 RHCOS 机器

6.2.4. 批准机器的证书签名请求

6.2.5. 在 AWS 中使用自定义 `/var` 分区添加新的 RHCOS worker 节点

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links

6.2. 将 RHCOS 计算机器添加到 OpenShift Container Platform 集群

6.2.1. 先决条件

6.2.2. 使用 ISO 镜像创建更多 RHCOS 机器

6.2.3. 通过 PXE 或 iPXE 启动来创建更多 RHCOS 机器

6.2.4. 批准机器的证书签名请求

6.2.5. 在 AWS 中使用自定义 /var 分区添加新的 RHCOS worker 节点

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links

6.2.5. 在 AWS 中使用自定义 `/var` 分区添加新的 RHCOS worker 节点