搜索

安装后配置

download PDF
OpenShift Container Platform 4.15

OpenShift Container Platform 的第二天操作

Red Hat OpenShift Documentation Team

摘要

本文档提供有关 OpenShift Container Platform 安装后进行的操作说明。

第 1 章 安装后配置概述

安装 OpenShift Container Platform 后,集群管理员可以配置和自定义以下组件:

  • 机器
  • 裸机
  • 集群
  • 节点
  • Network
  • 存储
  • 用户
  • 警报和通知

1.1. 安装后配置任务

您可以执行安装后配置任务来配置环境,以满足您的需要。

以下列表详细介绍了这些配置:

  • 配置操作系统功能 :Machine Config Operator(MCO) 管理 MachineConfig 对象。通过使用 MCO,您可以配置节点和自定义资源。
  • 配置裸机节点 :您可以使用 Bare Metal Operator (BMO) 来管理裸机主机。BMO 可以完成以下操作:

    • 检查主机的硬件详情,并将其报告到裸机主机。
    • 检查固件并配置 BIOS 设置。
    • 使用所需镜像调配主机。
    • 在置备主机之前或之后清理主机的磁盘内容。
  • 配置集群功能。您可以修改 OpenShift Container Platform 集群的以下功能:

    • 镜像 registry
    • 网络配置
    • 镜像构建行为
    • 用户身份提供程序
    • etcd 配置
    • 用于处理工作负载的机器集
    • 云供应商凭证管理
  • 配置私有集群:默认情况下,安装程序使用公开的 DNS 和端点置备 OpenShift Container Platform。要使集群只能从内部网络进行访问,请配置以下组件使其私有:

    • DNS
    • Ingress Controller
    • API Server
  • 执行节点操作 :默认情况下,OpenShift Container Platform 使用 Red Hat Enterprise Linux CoreOS(RHCOS)计算机器。您可以执行以下操作:

    • 添加和删除计算机器。
    • 添加和删除污点和容限。
    • 配置每个节点的最大 pod 数量。
    • 启用设备管理器。
  • 配置网络:安装 OpenShift Container Platform 后,您可以配置以下组件:

    • 入口集群流量
    • 节点端口服务范围
    • 网络策略
    • 启用集群范围代理
  • 配置存储 :默认情况下,容器使用临时存储或临时存储进行操作。临时存储具有生命周期限制。要长期存储数据,您必须配置持久性存储。您可以使用以下方法之一配置存储:

    • 动态置备 :您可以通过定义并创建控制不同级别的存储类(包括存储访问)来按需动态置备存储。
    • 静态置备 :您可以使用 Kubernetes 持久性卷使现有存储可供集群使用。静态置备支持各种设备配置和挂载选项。
  • 配置用户 :OAuth 访问令牌允许用户自行验证 API。您可以配置 OAuth 以执行以下任务:
  • 指定身份提供程序
  • 使用基于角色的访问控制为用户定义和授予权限
  • 从 OperatorHub 安装 Operator
  • 配置警报通知 :默认情况下,触发的警报显示在 web 控制台的 Alerting UI 中。您还可以配置 OpenShift Container Platform,将警报通知发送到外部系统。

第 2 章 配置私有集群

安装 OpenShift Container Platform 版本 4.15 集群后,您可以将其某些核心组件设置为私有。

2.1. 关于私有集群

默认情况下,OpenShift Container Platform 被置备为使用可公开访问的 DNS 和端点。在部署私有集群后,您可以将 DNS、Ingress Controller 和 API 服务器设置为私有。

重要

如果集群有任何公共子网,管理员创建的负载均衡器服务可能会公开访问。为确保集群安全性,请验证这些服务是否已明确标注为私有。

DNS

如果在安装程序置备的基础架构上安装 OpenShift Container Platform,安装程序会在预先存在的公共区中创建记录,并在可能的情况下为集群自己的 DNS 解析创建一个私有区。在公共区和私有区中,安装程序或集群为 *.appsIngress 对象创建 DNS 条目,并为 API 服务器创建 api

公共和私有区中的 *.apps 记录是相同的,因此当您删除公有区时,私有区为集群无缝地提供所有 DNS 解析。

Ingress Controller

由于默认 Ingress 对象是作为公共对象创建的,所以负载均衡器是面向互联网的,因此在公共子网中。

Ingress Operator 为 Ingress Controller 生成默认证书,以充当占位符,直到您配置了自定义默认证书为止。不要在生产环境集群中使用 Operator 生成的默认证书。Ingress Operator 不轮转其自身的签名证书或它生成的默认证书。Operator 生成的默认证书的目的是作为您配置的自定义默认证书的占位者。

API Server

默认情况下,安装程序为 API 服务器创建适当的网络负载均衡器,供内部和外部流量使用。

在 Amazon Web Services(AWS)上,会分别创建独立的公共和私有负载均衡器。负载均衡器是基本相同的,唯一不同是带有一个额外的、用于在集群内部使用的端口。虽然安装程序根据 API 服务器要求自动创建或销毁负载均衡器,但集群并不管理或维护它们。只要保留集群对 API 服务器的访问,您可以手动修改或移动负载均衡器。对于公共负载均衡器,需要打开端口 6443,并根据 /readyz 路径配置 HTTPS 用于健康检查。

在 Google Cloud Platform 上,会创建一个负载均衡器来管理内部和外部 API 流量,因此您无需修改负载均衡器。

在 Microsoft Azure 上,会创建公共和私有负载均衡器。但是,由于当前实施的限制,您刚刚在私有集群中保留两个负载均衡器。

2.2. 将 DNS 设置为私有

部署集群后,您可以修改其 DNS 使其只使用私有区。

流程

  1. 查看集群的 DNS 自定义资源:

    $ oc get dnses.config.openshift.io/cluster -o yaml

    输出示例

    apiVersion: config.openshift.io/v1
    kind: DNS
    metadata:
      creationTimestamp: "2019-10-25T18:27:09Z"
      generation: 2
      name: cluster
      resourceVersion: "37966"
      selfLink: /apis/config.openshift.io/v1/dnses/cluster
      uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
    spec:
      baseDomain: <base_domain>
      privateZone:
        tags:
          Name: <infrastructure_id>-int
          kubernetes.io/cluster/<infrastructure_id>: owned
      publicZone:
        id: Z2XXXXXXXXXXA4
    status: {}

    请注意,spec 部分包含一个私有区和一个公共区。

  2. 修补 DNS 自定义资源以删除公共区:

    $ oc patch dnses.config.openshift.io/cluster --type=merge --patch='{"spec": {"publicZone": null}}'
    dns.config.openshift.io/cluster patched

    因为 Ingress Controller 在创建 Ingress 对象时会参考 DNS 定义,因此当您创建或修改 Ingress 对象时,只会创建私有记录。

    重要

    在删除公共区时,现有 Ingress 对象的 DNS 记录不会修改。

  3. 可选:查看集群的 DNS 自定义资源,并确认已删除公共区:

    $ oc get dnses.config.openshift.io/cluster -o yaml

    输出示例

    apiVersion: config.openshift.io/v1
    kind: DNS
    metadata:
      creationTimestamp: "2019-10-25T18:27:09Z"
      generation: 2
      name: cluster
      resourceVersion: "37966"
      selfLink: /apis/config.openshift.io/v1/dnses/cluster
      uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
    spec:
      baseDomain: <base_domain>
      privateZone:
        tags:
          Name: <infrastructure_id>-int
          kubernetes.io/cluster/<infrastructure_id>-wfpg4: owned
    status: {}

2.3. 将 Ingress Controller 设置为私有

部署集群后,您可以修改其 Ingress Controller 使其只使用私有区。

流程

  1. 修改默认 Ingress Controller,使其仅使用内部端点:

    $ oc replace --force --wait --filename - <<EOF
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: default
    spec:
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal
    EOF

    输出示例

    ingresscontroller.operator.openshift.io "default" deleted
    ingresscontroller.operator.openshift.io/default replaced

    删除公共 DNS 条目,并更新私有区条目。

2.4. 将 API 服务器限制为私有

将集群部署到 Amazon Web Services(AWS)或 Microsoft Azure 后,可以重新配置 API 服务器,使其只使用私有区。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 使用具有 admin 权限的用户登陆到 web 控制台。

流程

  1. 在云供应商的 web 门户或控制台中,执行以下操作:

    1. 找到并删除相关的负载均衡器组件:

      • 对于 AWS,删除外部负载均衡器。私有区的 API DNS 条目已指向内部负载均衡器,它使用相同的配置,因此您无需修改内部负载均衡器。
      • 对于 Azure,删除公共负载均衡器的 api-internal-v4 规则。
    2. 对于 Azure,将 Ingress Controller 端点发布范围配置为 Internal。如需更多信息,请参阅"将 Ingress Controller 端点发布范围配置为 Internal"。
    3. 对于 Azure 公共负载均衡器,如果您将 Ingress Controller 端点发布范围配置为 Internal,且公共负载均衡器中没有现有的入站规则,则必须明确创建一个出站规则来为后端地址池提供出站流量。如需更多信息,请参阅 Microsoft Azure 文档中有关添加出站规则的内容。
    4. 删除 public 区域中的 api.$clustername.$yourdomainapi.$clustername DNS 条目。
  2. AWS 集群:删除外部负载均衡器:

    重要

    您只能对安装程序置备的基础架构 (IPI) 集群执行以下步骤。对于用户置备的基础架构 (UPI) 集群,您必须手动删除或禁用外部负载均衡器。

    • 如果您的集群使用 control plane 机器集,删除配置公共或外部负载均衡器的 control plane 机器集自定义资源中的行:

      # ...
      providerSpec:
        value:
      # ...
          loadBalancers:
          - name: lk4pj-ext 1
            type: network 2
          - name: lk4pj-int
            type: network
      # ...
      1
      删除外部负载均衡器的 name 值,它以 -ext 结尾。
      2
      删除外部负载均衡器的 type 值。
    • 如果您的集群没有使用 control plane 机器集,您必须从每个 control plane 机器中删除外部负载均衡器。

      1. 在终端中,运行以下命令来列出集群机器:

        $ oc get machine -n openshift-machine-api

        输出示例

        NAME                            STATE     TYPE        REGION      ZONE         AGE
        lk4pj-master-0                  running   m4.xlarge   us-east-1   us-east-1a   17m
        lk4pj-master-1                  running   m4.xlarge   us-east-1   us-east-1b   17m
        lk4pj-master-2                  running   m4.xlarge   us-east-1   us-east-1a   17m
        lk4pj-worker-us-east-1a-5fzfj   running   m4.xlarge   us-east-1   us-east-1a   15m
        lk4pj-worker-us-east-1a-vbghs   running   m4.xlarge   us-east-1   us-east-1a   15m
        lk4pj-worker-us-east-1b-zgpzg   running   m4.xlarge   us-east-1   us-east-1b   15m

        control plane 机器在名称中包含 master

      2. 从每个 control plane 机器中删除外部负载均衡器:

        1. 运行以下命令,将 control plane 机器对象编辑为:

          $ oc edit machines -n openshift-machine-api <control_plane_name> 1
          1
          指定要修改的 control plane 机器对象名称。
        2. 删除描述外部负载均衡器的行,它们在以下示例中被标记:

          # ...
          providerSpec:
            value:
          # ...
              loadBalancers:
              - name: lk4pj-ext 1
                type: network 2
              - name: lk4pj-int
                type: network
          # ...
          1
          删除外部负载均衡器的 name 值,它以 -ext 结尾。
          2
          删除外部负载均衡器的 type 值。
        3. 保存更改并退出对象规格。
        4. 为每个 control plane 机器重复此步骤。

2.4.1. 将 Ingress Controller 端点发布范围配置为 Internal

当集群管理员在没有指定集群为私有的情况下安装新集群时,将默认 Ingress Controller 创建,并将 scope 设置为 External。集群管理员可以将 External 范围的 Ingress Controller 更改为 Internal

先决条件

  • 已安装 oc CLI。

流程

  • 要将 External 范围的 Ingress Controller 更改为 Internal,请输入以下命令:

    $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'
  • 要检查 Ingress Controller 的状态,请输入以下命令:

    $ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
    • Progressing 状态条件指示您必须执行进一步的操作。例如,状态条件可以通过输入以下命令来指示需要删除该服务:

      $ oc -n openshift-ingress delete services/router-default

      如果删除了该服务,Ingress Operator 会重新创建为 Internal

2.5. 在 Azure 上配置私有存储端点

您可以使用 Image Registry Operator 在 Azure 上使用私有端点,它会在 OpenShift Container Platform 部署到私有 Azure 集群上时启用私有存储帐户的无缝配置。这可让您在不公开面向公共的存储端点的情况下部署镜像 registry。

您可以通过两种方式之一将 Image Registry Operator 配置为使用 Azure 上的私有存储端点:

  • 通过配置 Image Registry Operator 来发现 VNet 和子网名称
  • 使用用户提供的 Azure Virtual Network (VNet) 和子网名称

2.5.1. 在 Azure 上配置私有存储端点的限制

在 Azure 上配置私有存储端点时有以下限制:

  • 在将 Image Registry Operator 配置为使用私有存储端点时,禁用对存储帐户的公共网络访问。因此,在 registry Operator 配置中设置 disableRedirect: true 才能从 OpenShift Container Platform 之外拉取镜像。启用重定向后,registry 会重定向客户端直接从存储帐户拉取镜像,这不再会因为公共网络访问被禁用而工作。如需更多信息,请参阅"在 Azure 上使用私有存储端点时禁用重定向"。
  • Image Registry Operator 无法撤销此操作。

2.5.2. 通过启用 Image Registry Operator 发现 VNet 和子网名称,在 Azure 上配置私有存储端点

以下流程演示了如何通过配置 Image Registry Operator 来发现 VNet 和子网名称在 Azure 上设置私有存储端点。

先决条件

  • 您已将镜像 registry 配置为在 Azure 上运行。
  • 使用 Installer Provisioned Infrastructure 安装方法设置了您的网络。

    对于具有自定义网络设置的用户,请参阅"使用用户提供的 VNet 和子网名称在 Azure 上配置私有存储端点"。

流程

  1. 编辑 Image Registry Operator config 对象,并将 networkAccess.type 设置为 Internal

    $ oc edit configs.imageregistry/cluster
    # ...
    spec:
      # ...
       storage:
          azure:
            # ...
            networkAccess:
              type: Internal
    # ...
  2. 可选:输入以下命令确认 Operator 已完成置备。这可能需要几分钟时间。

    $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w
  3. 可选:如果 registry 由路由公开,并且要将存储帐户配置为私有,则必须禁用重定向(如果集群外部拉取到集群),则必须禁用重定向才能继续工作。输入以下命令禁用 Image Operator 配置中的重定向:

    $ oc patch configs.imageregistry cluster --type=merge -p '{"spec":{"disableRedirect": true}}'
    注意

    启用重定向后,从集群外部拉取镜像将无法正常工作。

验证

  1. 运行以下命令来获取 registry 服务名称:

    $ oc registry info --internal=true

    输出示例

    image-registry.openshift-image-registry.svc:5000

  2. 运行以下命令来进入 debug 模式:

    $ oc debug node/<node_name>
  3. 运行推荐的 chroot 命令。例如:

    $ chroot /host
  4. 输入以下命令登录到容器 registry:

    $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

    输出示例

    Login Succeeded!

  5. 输入以下命令验证您可以从 registry 中拉取镜像:

    $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools

    输出示例

    Trying to pull image-registry.openshift-image-registry.svc:5000/openshift/tools/openshift/tools...
    Getting image source signatures
    Copying blob 6b245f040973 done
    Copying config 22667f5368 done
    Writing manifest to image destination
    Storing signatures
    22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

2.5.3. 使用用户提供的 VNet 和子网名称在 Azure 上配置私有存储端点

使用以下步骤配置禁用公共网络访问权限的存储帐户,并在 Azure 上的私有存储端点后公开。

先决条件

  • 您已将镜像 registry 配置为在 Azure 上运行。
  • 您必须知道用于 Azure 环境的 VNet 和子网名称。
  • 如果您的网络是在 Azure 中的单独资源组中配置的,还必须知道其名称。

流程

  1. 编辑 Image Registry Operator config 对象并使用 VNet 和子网名称配置私有端点:

    $ oc edit configs.imageregistry/cluster
    # ...
    spec:
      # ...
       storage:
          azure:
            # ...
            networkAccess:
              type: Internal
              internal:
                subnetName: <subnet_name>
                vnetName: <vnet_name>
                networkResourceGroupName: <network_resource_group_name>
    # ...
  2. 可选:输入以下命令确认 Operator 已完成置备。这可能需要几分钟时间。

    $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w
    注意

    启用重定向后,从集群外部拉取镜像将无法正常工作。

验证

  1. 运行以下命令来获取 registry 服务名称:

    $ oc registry info --internal=true

    输出示例

    image-registry.openshift-image-registry.svc:5000

  2. 运行以下命令来进入 debug 模式:

    $ oc debug node/<node_name>
  3. 运行推荐的 chroot 命令。例如:

    $ chroot /host
  4. 输入以下命令登录到容器 registry:

    $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

    输出示例

    Login Succeeded!

  5. 输入以下命令验证您可以从 registry 中拉取镜像:

    $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools

    输出示例

    Trying to pull image-registry.openshift-image-registry.svc:5000/openshift/tools/openshift/tools...
    Getting image source signatures
    Copying blob 6b245f040973 done
    Copying config 22667f5368 done
    Writing manifest to image destination
    Storing signatures
    22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

2.5.4. 可选:在 Azure 上使用私有存储端点时禁用重定向

默认情况下,在使用镜像 registry 时会启用重定向。重定向允许将 registry pod 的流量卸载到对象存储中,从而加快拉取速度。当启用重定向且存储帐户为私有时,来自集群外部的用户无法从 registry 中拉取镜像。

在某些情况下,用户可能希望禁用重定向,以便集群外部的用户可以从 registry 中拉取镜像。

使用以下步骤禁用重定向。

先决条件

  • 您已将镜像 registry 配置为在 Azure 上运行。
  • 您已配置了路由。

流程

  • 输入以下命令禁用镜像 registry 配置中的重定向:

    $ oc patch configs.imageregistry cluster --type=merge -p '{"spec":{"disableRedirect": true}}'

验证

  1. 运行以下命令来获取 registry 服务名称:

    $ oc registry info

    输出示例

    default-route-openshift-image-registry.<cluster_dns>

  2. 输入以下命令登录到容器 registry:

    $ podman login --tls-verify=false -u unused -p $(oc whoami -t) default-route-openshift-image-registry.<cluster_dns>

    输出示例

    Login Succeeded!

  3. 输入以下命令验证您可以从 registry 中拉取镜像:

    $ podman pull --tls-verify=false default-route-openshift-image-registry.<cluster_dns>
    /openshift/tools

    输出示例

    Trying to pull default-route-openshift-image-registry.<cluster_dns>/openshift/tools...
    Getting image source signatures
    Copying blob 6b245f040973 done
    Copying config 22667f5368 done
    Writing manifest to image destination
    Storing signatures
    22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

第 3 章 裸机配置

在裸机主机上部署 OpenShift Container Platform 时,在置备前或置备后,有时您需要对主机进行更改。这包括检查主机的硬件、固件和固件详情。它还可以包含格式化磁盘或更改可修改的固件设置。

3.1. 关于 Bare Metal Operator

使用 Bare Metal Operator (BMO) 来置备、管理和检查集群中的裸机主机。

BMO 使用三个资源来完成这些任务:

  • BareMetalHost
  • HostFirmwareSettings
  • FirmwareSchema

BMO 通过将每个裸机主机映射到 BareMetalHost 自定义资源定义的实例来维护集群中的物理主机清单。每个 BareMetalHost 资源都有硬件、软件和固件详情。BMO 持续检查集群中的裸机主机,以确保每个 BareMetalHost 资源准确详细说明相应主机的组件。

BMO 还使用 HostFirmwareSettings 资源和 FirmwareSchema 资源来详细说明裸机主机的固件规格。

使用 Ironic API 服务在集群中的裸机主机的 BMO 接口。Ironic 服务使用主机上的 Baseboard Management Controller (BMC) 来与机器进行接口。

使用 BMO 可以完成的一些常见任务包括:

  • 使用特定镜像置备裸机主机到集群
  • 在置备前或取消置备后格式化主机的磁盘内容
  • 打开或关闭主机
  • 更改固件设置
  • 查看主机的硬件详情

3.1.1. 裸机 Operator 架构

Bare Metal Operator (BMO) 使用三个资源来置备、管理和检查集群中的裸机主机。下图演示了这些资源的架构:

BMO 架构概述

BareMetalHost

BareMetalHost 资源定义物理主机及其属性。将裸机主机置备到集群时,您必须为该主机定义 BareMetalHost 资源。对于主机的持续管理,您可以检查 BareMetalHost 中的信息或更新此信息。

BareMetalHost 资源具有置备信息,如下所示:

  • 部署规格,如操作系统引导镜像或自定义 RAM 磁盘
  • 置备状态
  • 基板管理控制器 (BMC) 地址
  • 所需的电源状态

BareMetalHost 资源具有硬件信息,如下所示:

  • CPU 数量
  • NIC 的 MAC 地址
  • 主机的存储设备的大小
  • 当前电源状态

HostFirmwareSettings

您可以使用 HostFirmwareSettings 资源来检索和管理主机的固件设置。当主机进入 Available 状态时,Ironic 服务读取主机的固件设置并创建 HostFirmwareSettings 资源。BareMetalHost 资源和 HostFirmwareSettings 资源之间存在一对一映射。

您可以使用 HostFirmwareSettings 资源来检查主机的固件规格,或更新主机的固件规格。

注意

在编辑 HostFirmwareSettings 资源的 spec 字段时,您必须遵循特定于供应商固件的 schema。这个模式在只读 FirmwareSchema 资源中定义。

FirmwareSchema

固件设置因硬件供应商和主机模型而异。FirmwareSchema 资源是一个只读资源,其中包含每个主机模型中每个固件设置的类型和限制。数据通过使用 Ironic 服务直接从 BMC 传递。FirmwareSchema 资源允许您识别 HostFirmwareSettings 资源的 spec 字段中可以指定的有效值。

如果 schema 相同,则 FirmwareSchema 资源可应用到许多 BareMetalHost 资源。

3.2. 关于 BareMetalHost 资源

裸机3 引入了 BareMetalHost 资源的概念,它定义了物理主机及其属性。BareMetalHost 资源包含两个部分:

  1. BareMetalHost 规格
  2. BareMetalHost 状态

3.2.1. BareMetalHost 规格

BareMetalHost 资源的 spec 部分定义了主机所需状态。

表 3.1. BareMetalHost spec
参数描述

automatedCleaningMode

在置备和取消置备过程中启用或禁用自动清理的接口。当设置为 disabled 时,它将跳过自动清理。当设置为 metadata 时,会自动清理会被启用。默认设置为 metadata

bmc:
  address:
  credentialsName:
  disableCertificateVerification:

bmc 配置设置包含主机上基板管理控制器(BMC)的连接信息。这些字段包括:

  • address :与主机的 BMC 控制器通信的 URL。
  • credentialsName :引用包含 BMC 的用户名和密码的 secret。
  • disableCertificateVerification :当设置为 true 时跳过证书验证的布尔值。

bootMACAddress

用于置备主机的 NIC 的 MAC 地址。

bootMode

主机的引导模式。它默认为 UEFI,但也可以设置为 legacy 用于 BIOS 引导,或 UEFISecureBoot

consumerRef

对使用主机的另一个资源的引用。如果另一个资源目前没有使用主机,则它可能为空。例如,当 machine-api 使用主机时,Machine 资源可能会使用主机。

description

提供的字符串,用于帮助识别主机。

externallyProvisioned

指明主机置备和取消置备是在外部管理的布尔值。当设置时:

  • 仍可使用在线字段管理电源状态。
  • 将监控硬件清单,但不会在主机上执行置备或取消置备操作。

firmware

包含有关裸机主机的 BIOS 配置的信息。目前,只有 iRMC、S iDRAC、i iLO4 和 iLO5 BMC 支持 firmware。子字段有:

  • simultaneousMultithreadingEnabled:允许单个物理处理器内核显示为多个逻辑处理器。有效设置为 truefalse
  • sriovEnabled: SR-IOV 支持可让虚拟机监控程序创建 PCI-express 设备的虚拟实例,这可能会提高性能。有效设置为 truefalse
  • virtualizationEnabled:支持平台硬件的虚拟化。有效设置为 truefalse
image:
  url:
  checksum:
  checksumType:
  format:

image 配置设置包含要部署到主机上的镜像的详细信息。Ironic 需要镜像字段。但是,当 externallyProvisioned 配置设置被设置为 true,且外部管理不需要电源控制时,字段可以为空。这些字段包括:

  • url:部署到主机的镜像的 URL。
  • checksum :位于 image.url 的镜像的实际校验和值,或包括镜像的校验和的文件 URL。
  • checksumType :指定 checksum 算法。目前,Image.checksumType 只支持 md5sha256sha512。默认 checksum 类型为 md5
  • format :镜像的磁盘格式。它可以是 raw, qcow2, vdi, vmdk, live-iso 或不设置。把它设置为 raw 可为该镜像在 Ironic 代理中进行原始镜像流处理。将它设置为 live-iso 会启用 iso 镜像在没有部署到磁盘的情况下进行实时引导,它会忽略 checksum 字段。

networkData

对包含网络配置数据及其命名空间的 secret 的引用,以便在主机引导以设置网络前将其附加到主机。

online

指示主机是否应开启的布尔值,true 代表开启,false 代表关闭。更改此值将触发对物理主机的电源状态变化。

raid:
  hardwareRAIDVolumes:
  softwareRAIDVolumes:

(可选)包含有关裸机主机的 RAID 配置的信息。如果没有指定,它会保留当前的配置。

注意

OpenShift Container Platform 4.15 支持 BMC 的硬件 RAID,包括:

  • Fujitsu iRMC 支持 RAID 0、1、5、6 和 10
  • Dell iDRAC 使用带有固件版本 6.10.30.20 或更高版本和 RAID 级别 0、1 和 5 的 Redfish API

OpenShift Container Platform 4.15 不支持软件 RAID。

请参见以下配置设置:

  • hardwareRAIDVolumes :包含硬件 RAID 的逻辑驱动器列表,并在硬件 RAID 中定义所需的卷配置。如果您没有指定 rootDeviceHints,则第一个卷是 root 卷。子字段是:

    • level :逻辑驱动器的 RAID 级别。支持以下级别:0,1,2,5,6,1+0,5+0,6+0.
    • name :卷名称(字符串)。它在服务器中应该是唯一的。如果未指定,则自动生成卷名称。
    • numberOfPhysicalDisks :物理驱动器的数量,作为用于逻辑 drove 的整数。默认为特定 RAID 级别所需的最小磁盘驱动器数。
    • physicalDisks :物理磁盘驱动器的名称列表作为字符串。这是可选字段。如果指定,还必须指定 controller 字段。
    • controller :(可选)RAID 控制器的名称作为要在硬件 RAID 卷中使用的字符串。
    • rotational :如果设为 true,则它只会选择轮转磁盘驱动器。如果设置为 false,它将只选择固态和 NVMe 驱动器。如果没有设置,则会选择任何驱动器类型,这是默认行为。
    • sizeGibibytes :逻辑驱动器的大小作为在 GiB 中创建的整数。如果未指定或设置为 0,它将为逻辑驱动器使用物理驱动器的最大容量。
  • softwareRAIDVolumes: OpenShift Container Platform 4.15 不支持软件 RAID。以下信息仅供参考。这个配置包含软件 RAID 的逻辑磁盘列表。如果您没有指定 rootDeviceHints,则第一个卷是 root 卷。如果您设置了 HardwareRAIDVolumes,则此项将无效。软件 RAID 总是被删除。创建的软件 RAID 设备的数量必须是 12。如果只有一个软件 RAID 设备,它必须是 RAID-1。如果有两个 RAID 设备,则第一个设备必须是 RAID-1,而第二个设备的 RAID 级别可以为 0, 1, 或 1+0。第一个 RAID 设备将是部署设备。因此,当设备出现故障时,强制 RAID-1 降低了非引导节点的风险。softwareRAIDVolume 字段定义软件 RAID 中卷所需的配置。子字段是:

    • level :逻辑驱动器的 RAID 级别。支持以下级别:0,1,1+0
    • physicalDisks :设备提示列表.项目数量应大于或等于 2
    • sizeGibibytes :逻辑磁盘驱动器的大小作为整数,以 GiB 为单位创建。如果未指定或设置为 0,它将为逻辑驱动器使用物理驱动器的最大容量。

您可以将 hardwareRAIDVolume 设置为空片段,以清除硬件 RAID 配置。例如:

spec:
   raid:
     hardwareRAIDVolume: []

如果您收到出错信息表示驱动程序不支持 RAID,则将 raid, hardwareRAIDVolumessoftwareRAIDVolumes 设置为 nil。您可能需要确保主机具有 RAID 控制器。

rootDeviceHints:
  deviceName:
  hctl:
  model:
  vendor:
  serialNumber:
  minSizeGigabytes:
  wwn:
  wwnWithExtension:
  wwnVendorExtension:
  rotational:

rootDeviceHints 参数启用将 RHCOS 镜像置备到特定设备。它会按照发现设备的顺序检查设备,并将发现的值与 hint 值进行比较。它使用第一个与 hint 值匹配的发现设备。该配置可组合多个 hints,但设备必须与所有提示都匹配才能被选择。这些字段包括:

  • deviceName:包含类似 /dev/vda 的 Linux 设备名称的字符串。hint 必须与实际值完全匹配。
  • hctl :包含类似 0:0:0:0 的 SCSI 总线地址的字符串。hint 必须与实际值完全匹配。
  • model :包含特定厂商的设备标识符的字符串。hint 可以是实际值的子字符串。
  • vendor :包含该设备厂商或制造商名称的字符串。hint 可以是实际值的子字符串。
  • serialNumber :包含设备序列号的字符串。hint 必须与实际值完全匹配。
  • minSizeGigabytes :一个整数,代表设备的最小大小(以 GB 为单位)。
  • wwn :包含唯一存储标识符的字符串。hint 必须与实际值完全匹配。
  • wwnWithExtension :包含附加厂商扩展的唯一存储标识符的字符串。hint 必须与实际值完全匹配。
  • wwnVendorExtension :包含唯一厂商存储标识符的字符串。hint 必须与实际值完全匹配。
  • rotational :指示该设备应该是旋转磁盘(true)还是非旋转磁盘(false)的布尔值。

3.2.2. BareMetalHost 状态

BareMetalHost 状态代表主机的当前状态,包括经过测试的凭证、当前的硬件详情和其他信息。

表 3.2. BareMetalHost 状态
参数描述

goodCredentials

对 secret 及其命名空间的引用,其中包含最近一组基板管理控制器(BMC)凭证,以便系统能够验证。

errorMessage

置备后端的最后一个错误的详情(若有)。

errorType

表示导致主机进入错误状态的问题类别。错误类型包括:

  • provisioned registration error:当控制器无法重新注册已置备的主机时发生。
  • registration error :当控制器无法连接到主机的基板管理控制器时,请注意。
  • inspection error :尝试从主机获取硬件详细信息时发生错误。
  • preparation error :在清理失败时生成。
  • provisioning error :当控制器无法置备或取消置备主机时会发生。
  • power management error :当控制器无法修改主机的电源状态时会发生。
  • detach error: 当控制器无法从置备程序卸载主机时会发生。
hardware:
  cpu
    arch:
    model:
    clockMegahertz:
    flags:
    count:

系统中的 CPU 的 hardware.cpu 字段详情。这些字段包括:

  • arch :CPU 的架构。
  • model: CPU 系列(字符串)
  • clockMegahertz :CPU 的速度(MHz)。
  • flags: CPU 标记列表。例如,'mmx','sse','sse2','vmx' 等。
  • count: 系统中可用的 CPU 数量。
hardware:
  firmware:

包含 BIOS 固件信息。例如,硬件供应商和版本。

hardware:
  nics:
  - ip:
    name:
    mac:
    speedGbps:
    vlans:
    vlanId:
    pxe:

hardware.nics 字段包含主机的网络接口列表。这些字段包括:

  • ip:NIC 的 IP 地址,如果在发现代理运行时是否被分配。
  • name: 标识网络设备的字符串。例如,nic-1
  • mac: NIC 的 MAC 地址。
  • speedGbps: 设备的速度(Gbps)。
  • vlans: 保存此 NIC 可用的所有 VLAN 的列表。
  • vlanId :未标记的 VLAN ID。
  • pxe: NIC 是否能够使用 PXE 引导。
hardware:
  ramMebibytes:

主机的内存量(兆字节(MiB))。

hardware:
  storage:
  - name:
    rotational:
    sizeBytes:
    serialNumber:

hardware.storage 字段包含可用于主机的存储设备列表。这些字段包括:

  • name: 标识存储设备的字符串。例如,disk 1 (boot).
  • rotational :指示磁盘是否为轮转的,返回 truefalse
  • sizeBytes :存储设备的大小。
  • serialNumber :设备的序列号。
hardware:
  systemVendor:
    manufacturer:
    productName:
    serialNumber:

包含主机的 manufacturer, productName, 和 serialNumber 的信息。

lastUpdated

主机状态最后一次更新的时间戳。

operationalStatus

服务器的状态。状态为以下之一:

  • OK :指示主机的所有详细信息均为已知、正确配置、正常工作和可以管理。
  • discovered: 指定某些主机的详细信息无法正常工作或缺失。例如,BMC 地址已知,但登录凭证未知。
  • error: 指示系统发现某种不可恢复的错误。如需更多详细信息,请参阅 status 部分中的 errorMessage 字段。
  • delayed:指示置备延迟来限制同时置备多个主机。
  • detached: 指示主机被标记为 unmanaged

poweredOn

指明主机是否开机的布尔值。

provisioning:
  state:
  id:
  image:
  raid:
  firmware:
  rootDeviceHints:

provisioning 字段包含与主机部署镜像相关的值。子字段包括:

  • state: 任何持续置备操作的当前状态。状态包括:

    • <empty string>: 目前没有进行置备。
    • unmanaged: 没有足够的信息来注册主机。
    • registering: 用来检查主机的 BMC 详情的代理
    • match profile :代理将主机上发现的硬件详情与已知的配置集进行比较。
    • available: 主机可用于置备。这个状态之前被称为 ready
    • preparing :现有配置将被删除,新的配置将在主机上设置。
    • provisioning :置备程序正在将镜像写入主机的存储。
    • provisioned: 置备程序已将镜像写入主机的存储。
    • externally provisioned: Metal3 不管理主机上的镜像。
    • deprovisioning: 置备程序正在从主机的存储中清除镜像。
    • inspecting: 代理正在收集主机的硬件详情。
    • deleting: 代理正在从集群中删除。
  • id: 底层调配工具中服务的唯一标识符。
  • Image :最近部署到主机的镜像。
  • raid: 最近设定的硬件或软件 RAID 卷列表。
  • firmware: 裸机服务器的 BIOS 配置。
  • rootDeviceHints :用于最新置备操作的根设备选择说明。

triedCredentials

对 secret 及其命名空间的引用,其中包含发送到置备后端的最后一个 BMC 凭证集合。

3.3. 获取 BareMetalHost 资源

BareMetalHost 资源包含物理主机的属性。您必须获取物理主机的 BareMetalHost 资源才能查看其属性。

流程

  1. 获取 BareMetalHost 资源列表:

    $ oc get bmh -n openshift-machine-api -o yaml
    注意

    您可以使用 baremetalhost 作为 oc get 命令的 bmh 长形式。

  2. 获取主机列表:

    $ oc get bmh -n openshift-machine-api
  3. 获取特定主机的 BareMetalHost 资源:

    $ oc get bmh <host_name> -n openshift-machine-api -o yaml

    其中 <host_name> 是主机的名称。

    输出示例

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      creationTimestamp: "2022-06-16T10:48:33Z"
      finalizers:
      - baremetalhost.metal3.io
      generation: 2
      name: openshift-worker-0
      namespace: openshift-machine-api
      resourceVersion: "30099"
      uid: 1513ae9b-e092-409d-be1b-ad08edeb1271
    spec:
      automatedCleaningMode: metadata
      bmc:
        address: redfish://10.46.61.19:443/redfish/v1/Systems/1
        credentialsName: openshift-worker-0-bmc-secret
        disableCertificateVerification: true
      bootMACAddress: 48:df:37:c7:f7:b0
      bootMode: UEFI
      consumerRef:
        apiVersion: machine.openshift.io/v1beta1
        kind: Machine
        name: ocp-edge-958fk-worker-0-nrfcg
        namespace: openshift-machine-api
      customDeploy:
        method: install_coreos
      online: true
      rootDeviceHints:
        deviceName: /dev/disk/by-id/scsi-<serial_number>
      userData:
        name: worker-user-data-managed
        namespace: openshift-machine-api
    status:
      errorCount: 0
      errorMessage: ""
      goodCredentials:
        credentials:
          name: openshift-worker-0-bmc-secret
          namespace: openshift-machine-api
        credentialsVersion: "16120"
      hardware:
        cpu:
          arch: x86_64
          clockMegahertz: 2300
          count: 64
          flags:
          - 3dnowprefetch
          - abm
          - acpi
          - adx
          - aes
          model: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
        firmware:
          bios:
            date: 10/26/2020
            vendor: HPE
            version: U30
        hostname: openshift-worker-0
        nics:
        - mac: 48:df:37:c7:f7:b3
          model: 0x8086 0x1572
          name: ens1f3
        ramMebibytes: 262144
        storage:
        - hctl: "0:0:0:0"
          model: VK000960GWTTB
          name: /dev/disk/by-id/scsi-<serial_number>
          sizeBytes: 960197124096
          type: SSD
          vendor: ATA
        systemVendor:
          manufacturer: HPE
          productName: ProLiant DL380 Gen10 (868703-B21)
          serialNumber: CZ200606M3
      lastUpdated: "2022-06-16T11:41:42Z"
      operationalStatus: OK
      poweredOn: true
      provisioning:
        ID: 217baa14-cfcf-4196-b764-744e184a3413
        bootMode: UEFI
        customDeploy:
          method: install_coreos
        image:
          url: ""
        raid:
          hardwareRAIDVolumes: null
          softwareRAIDVolumes: []
        rootDeviceHints:
          deviceName: /dev/disk/by-id/scsi-<serial_number>
        state: provisioned
      triedCredentials:
        credentials:
          name: openshift-worker-0-bmc-secret
          namespace: openshift-machine-api
        credentialsVersion: "16120"

3.4. 关于 HostFirmwareSettings 资源

您可以使用 HostFirmwareSettings 资源来检索和管理主机的 BIOS 设置。当主机进入 Available 状态时,Ironic 会读取主机的 BIOS 设置并创建 HostFirmwareSettings 资源。资源包含从基板管理控制器(BMC)返回的完整 BIOS 配置。BareMetalHost 资源中的 firmware 字段会返回三个供应商独立的字段,HostFirmwareSettings 资源通常包含每个主机中特定供应商的字段的许多 BIOS 设置。

HostFirmwareSettings 资源包含两个部分:

  1. HostFirmwareSettings spec。
  2. HostFirmwareSettings 状态。

3.4.1. HostFirmwareSettings spec

HostFirmwareSettings 资源的 spec 部分定义了主机的 BIOS 所需的状态,默认为空。Ironic 使用 spec.settings 部分中的设置,在主机处于 Preparing 状态时更新基板管理控制器(BMC)。使用 FirmwareSchema 资源,确保不向主机发送无效的名称/值对。如需了解更多详细信息,请参阅 "About the FirmwareSchema resource"。

Example

spec:
  settings:
    ProcTurboMode: Disabled1

1
在foregoing示例中,spec.settings 部分包含一个 name/value 对,它将把 ProcTurboMode BIOS 设置为 Disabled
注意

status 部分中列出的整数参数显示为字符串。例如,"1"。当在 spec.settings 部分中设置整数时,这些值应设置为不带引号的整数。例如,1.

3.4.2. HostFirmwareSettings 状态

status 代表主机的 BIOS 的当前状态。

表 3.3. HostFirmwareSettings
参数描述
status:
  conditions:
  - lastTransitionTime:
    message:
    observedGeneration:
    reason:
    status:
    type:

conditions 字段包含状态更改列表。子字段包括:

  • lastTransitionTime :状态更改最后一次的时间。
  • message: 状态更改的描述。
  • observedGeneration :当前 status 的世代。如果 metadata.generation 和此字段不同,则 status.conditions 可能已过时。
  • reason: 状态更改的原因。
  • status: 状态更改的状态。状态可以是 True, FalseUnknown
  • type: 状态更改的类型。类型为 ValidChangeDetected
status:
  schema:
    name:
    namespace:
    lastUpdated:

固件设置的 FirmwareSchema。这些字段包括:

  • name: 引用该模式的名称或唯一标识符。
  • namespace :存储 schema 的命名空间。
  • lastUpdated: 资源最后一次更新的时间。
status:
  settings:

settings 字段包含主机当前 BIOS 设置的名称/值对列表。

3.5. 获取 HostFirmwareSettings 资源

HostFirmwareSettings 资源包含物理主机的特定于供应商的 BIOS 属性。您必须获取物理主机的 HostFirmwareSettings 资源才能查看其 BIOS 属性。

流程

  1. 获取 HostFirmwareSettings 资源的详细列表:

    $ oc get hfs -n openshift-machine-api -o yaml
    注意

    您可以使用 hostfirmwaresettings 作为 oc get 命令的 hfs 长形式。

  2. 获取 HostFirmwareSettings 资源列表:

    $ oc get hfs -n openshift-machine-api
  3. 获取特定主机的 HostFirmwareSettings 资源

    $ oc get hfs <host_name> -n openshift-machine-api -o yaml

    其中 <host_name> 是主机的名称。

3.6. 编辑 HostFirmwareSettings 资源

您可以编辑已置备的主机的 HostFirmwareSettings

重要

您只能在主机处于 provisioned 状态时编辑主机,不包括只读值。您不能编辑状态为 externally provisioned 的主机。

流程

  1. 获取 HostFirmwareSettings 资源列表:

    $ oc get hfs -n openshift-machine-api
  2. 编辑主机的 HostFirmwareSettings 资源:

    $ oc edit hfs <host_name> -n openshift-machine-api

    其中 <host_name> 是置备的主机的名称。HostFirmwareSettings 资源将在终端的默认编辑器中打开。

  3. 将 name/value 对添加到 spec.settings 部分:

    Example

    spec:
      settings:
        name: value 1

    1
    使用 FirmwareSchema 资源来识别主机的可用设置。您不能设置只读值。
  4. 保存更改并退出编辑器。
  5. 获取主机的机器名称:

     $ oc get bmh <host_name> -n openshift-machine name

    其中 <host_name> 是主机的名称。机器名称会出现在 CONSUMER 字段下。

  6. 注解机器将其从 machineset 中删除:

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api

    其中 <machine_name> 是要删除的机器的名称。

  7. 获取节点列表并计算 worker 节点数量:

    $ oc get nodes
  8. 获取 machineset:

    $ oc get machinesets -n openshift-machine-api
  9. 缩放 machineset:

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>

    其中 <machineset_name> 是 machineset 的名称,<n-1> 是 worker 节点数量的减少。

  10. 当主机进入 Available 状态时,扩展 machineset,使 HostFirmwareSettings 资源更改生效:

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>

    其中 <machineset_name> 是 machineset 的名称,<n> 是 worker 节点的数量。

3.7. 验证 HostFirmware Settings 资源是否有效

当用户编辑 spec.settings 部分以更改为 HostFirmwareSetting(HFS)资源时,BMO 会针对 FimwareSchema 资源验证更改,这是只读资源。如果设置无效,BMO 会将 status.ConditionType 值设置为 False,并生成事件并将其存储在 HFS 资源中。使用以下步骤验证资源是否有效。

流程

  1. 获取 HostFirmwareSetting 资源列表:

    $ oc get hfs -n openshift-machine-api
  2. 验证特定主机的 HostFirmwareSettings 资源是否有效:

    $ oc describe hfs <host_name> -n openshift-machine-api

    其中 <host_name> 是主机的名称。

    输出示例

    Events:
      Type    Reason            Age    From                                    Message
      ----    ------            ----   ----                                    -------
      Normal  ValidationFailed  2m49s  metal3-hostfirmwaresettings-controller  Invalid BIOS setting: Setting ProcTurboMode is invalid, unknown enumeration value - Foo

    重要

    如果响应返回 ValidationFailed,资源配置中会出现一个错误,您必须更新这些值以符合 FirmwareSchema 资源。

3.8. 关于 FirmwareSchema 资源

BIOS 设置因硬件供应商和主机模型而异。FirmwareSchema 资源是一个只读资源,其中包含每个主机模型中的每个 BIOS 设置的类型和限值。数据直接通过 Ironic 来自 BMC。FirmwareSchema 允许您识别 HostFirmwareSettings 资源的 spec 字段中可以指定的有效值。FirmwareSchema 资源具有从其设置和限值派生的唯一标识符。相同的主机模型使用相同的 FirmwareSchema 标识符。HostFirmwareSettings 的多个实例可能使用相同的 FirmwareSchema

表 3.4. FirmwareSchema 规格
参数描述
<BIOS_setting_name>
  attribute_type:
  allowable_values:
  lower_bound:
  upper_bound:
  min_length:
  max_length:
  read_only:
  unique:

spec 是由 BIOS 设置名称和设置的限制组成的简单映射。这些字段包括:

  • attribute_type :设置类型。支持的类型有:

    • Enumeration
    • 整数
    • 字符串
    • 布尔值
  • allowable_values :当 attribute_typeEnumeration 时,允许值的列表。
  • lower_boundattribute_typeInteger 时允许的最小值。
  • upper_boundattribute_typeInteger 时允许的最大值。
  • min_length :当 attribute_typeString 时,值的字符串最短长度。
  • max_length :当 attribute_typeString 时,值第字符串最长长度。
  • read_only : 设置为只读,不可修改。
  • unique :该设置特定于此主机。

3.9. 获取 FirmwareSchema 资源

每个供应商的每个主机模型都有不同的 BIOS 设置。在编辑 HostFirmwareSettings 资源的 spec 部分时,您设置的名称/值对必须符合该主机的固件模式。要确保设置有效的名称/值对,请获取主机的 FirmwareSchema 并查看它。

流程

  1. 要获得 FirmwareSchema 资源实例列表,请执行以下操作:

    $ oc get firmwareschema -n openshift-machine-api
  2. 要获得特定 FirmwareSchema 实例,请执行:

    $ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml

    其中 <instance_name>HostFirmwareSettings 资源中所述的 schema 实例的名称(请参阅表 3)。

第 4 章 在 OpenShift 集群中配置多架构计算机器

4.1. 关于带有多架构计算机器的集群

带有多架构计算机器的 OpenShift Container Platform 集群是一个支持具有不同架构的计算机器的集群。具有多架构计算机器的集群仅在带有 64 位 x86 control plane 机器的 Amazon Web Services (AWS) 或 Microsoft Azure 安装程序置备的基础架构和裸机、IBM Power 和 IBM Z 用户置备的基础架构上可用。

注意

当集群中有多个架构的节点时,镜像的构架必须与节点的构架一致。您需要确保将 pod 分配给具有适当架构的节点,并将它与镜像架构匹配。如需有关将 pod 分配给节点的更多信息,请参阅将 pod 分配给节点

重要

具有多架构计算机器的集群中不支持 Cluster Samples Operator。集群可以在没有此功能的情况下创建。如需更多信息,请参阅启用集群功能

有关将单架构集群迁移到支持多架构计算机器的集群的详情,请参考 迁移到带有多架构计算机器的集群

4.1.1. 使用多架构计算机器配置集群

要使用不同安装选项和平台的多架构计算机器创建集群,您可以使用下表中的文档:

表 4.1. 带有多架构计算机器安装选项的集群
文档部分平台用户置备的安装安装程序置备的安装Control PlaneCompute 节点

在 Azure 上使用多架构计算机器创建集群

Microsoft Azure

 

x86_64

aarch64

在 AWS 上使用多架构计算机器创建集群

Amazon Web Services (AWS)

 

x86_64

aarch64

在 GCP 上使用多架构计算机器创建集群

Google Cloud Platform (GCP)

 

x86_64

aarch64

在裸机、IBM Power 或 IBM Z 上使用多架构计算机器创建集群

裸机

 

x86_64

aarch64

IBM Power

 

x86_64ppc64le

x86_64,ppc64le

IBM Z

 

x86_64s390x

x86_64,s390x

在 IBM Z 和使用 z/VM 的 IBM® LinuxONE 上使用多架构计算机器创建集群

IBM Z® 和 IBM® LinuxONE

 

x86_64

x86_64,s390x

在带有 RHEL KVM 的 IBM Z 和 IBM® LinuxONE 上使用多架构计算机器创建集群

IBM Z® 和 IBM® LinuxONE

 

x86_64

x86_64,s390x

在 IBM Power® 上使用多架构计算机器创建集群

IBM Power®

 

x86_64

x86_64,ppc64le

重要

Google Cloud Platform (GCP) 目前不支持从零自动扩展。

4.2. 在 Azure 上使用多架构计算机器创建集群

要使用多架构计算机器部署 Azure 集群,您必须首先创建一个使用多架构安装程序二进制文件的单架构 Azure 安装程序置备集群。如需有关 Azure 安装的更多信息,请参阅使用自定义在 Azure 上安装集群。然后,您可以在集群中添加 ARM64 计算机器集,以使用多架构计算机器创建集群。

以下流程描述了如何生成 ARM64 引导镜像并创建使用 ARM64 引导镜像的 Azure 计算机器集。这会在集群中添加 ARM64 计算节点,并部署您需要的 ARM64 虚拟机 (VM) 的数量。

4.2.1. 验证集群兼容性

在开始在集群中添加不同架构的计算节点前,您必须验证集群是否兼容多架构。

先决条件

  • 已安装 OpenShift CLI (oc)

流程

  • 您可以运行以下命令来检查集群是否使用构架有效负载:

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"

验证

  1. 如果您看到以下输出,集群将使用多架构有效负载:

    {
     "release.openshift.io/architecture": "multi",
     "url": "https://access.redhat.com/errata/<errata_version>"
    }

    然后,您可以开始在集群中添加多架构计算节点。

  2. 如果您看到以下输出,集群不使用多架构有效负载:

    {
     "url": "https://access.redhat.com/errata/<errata_version>"
    }
    重要

    要迁移集群以便集群支持多架构计算机器,请按照 Migrating to a cluster with multi-architecture compute machines 的步骤进行操作。

4.2.2. 使用 Azure 镜像 gallery 创建 ARM64 引导镜像

以下流程描述了如何手动生成 ARM64 引导镜像。

先决条件

  • 已安装 Azure CLI (az)。
  • 已使用多架构安装程序二进制文件创建了单架构 Azure 安装程序置备集群。

流程

  1. 登录到您的 Azure 帐户:

    $ az login
  2. 创建存储帐户并将 arm64 虚拟硬盘 (VHD) 上传到您的存储帐户。OpenShift Container Platform 安装程序会创建一个资源组,但引导镜像也可以上传到名为资源组的自定义中:

    $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS 1
    1
    westus 对象是一个示例区域。
  3. 使用您生成的存储帐户创建存储容器:

    $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}
  4. 您必须使用 OpenShift Container Platform 安装程序 JSON 文件提取 URL 和 aarch64 VHD 名称:

    1. 运行以下命令,提取 URL 字段并将其设置为 RHCOS_VHD_ORIGIN_URL

      $ RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.aarch64."rhel-coreos-extensions"."azure-disk".url')
    2. 运行以下命令,提取 aarch64 VHD 名称并将其设置为 BLOB_NAME 作为文件名:

      $ BLOB_NAME=rhcos-$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.aarch64."rhel-coreos-extensions"."azure-disk".release')-azure.aarch64.vhd
  5. 生成共享访问令牌 (SAS) 令牌。通过以下命令,使用此令牌将 RHCOS VHD 上传到存储容器:

    $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`
    $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`
  6. 将 RHCOS VHD 复制到存储容器中:

    $ az storage blob copy start --account-name ${STORAGE_ACCOUNT_NAME} --sas-token "$sas" \
     --source-uri "${RHCOS_VHD_ORIGIN_URL}" \
     --destination-blob "${BLOB_NAME}" --destination-container ${CONTAINER_NAME}

    您可以使用以下命令检查复制过程的状态:

    $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy

    输出示例

    {
     "completionTime": null,
     "destinationSnapshot": null,
     "id": "1fd97630-03ca-489a-8c4e-cfe839c9627d",
     "incrementalCopy": null,
     "progress": "17179869696/17179869696",
     "source": "https://rhcos.blob.core.windows.net/imagebucket/rhcos-411.86.202207130959-0-azure.aarch64.vhd",
     "status": "success", 1
     "statusDescription": null
    }

    1
    如果 status 参数显示 success 对象,则复制过程已完成。
  7. 使用以下命令创建镜像 gallery:

    $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}

    使用镜像 gallery 创建镜像定义。在以下示例中,rhcos-arm64 是镜像定义的名称。

    $ az sig image-definition create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --publisher RedHat --offer arm --sku arm64 --os-type linux --architecture Arm64 --hyper-v-generation V2
  8. 要获取 VHD 的 URL,并将其设置为 RHCOS_VHD_URL 作为文件名称,请运行以下命令:

    $ RHCOS_VHD_URL=$(az storage blob url --account-name ${STORAGE_ACCOUNT_NAME} -c ${CONTAINER_NAME} -n "${BLOB_NAME}" -o tsv)
  9. 使用 RHCOS_VHD_URL 文件、您的存储帐户、资源组和镜像 gallery 创建镜像版本。在以下示例中,1.0.0 是镜像版本。

    $ az sig image-version create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --gallery-image-version 1.0.0 --os-vhd-storage-account ${STORAGE_ACCOUNT_NAME} --os-vhd-uri ${RHCOS_VHD_URL}
  10. 现在生成您的 arm64 引导镜像。您可以使用以下命令访问镜像的 ID:

    $ az sig image-version show -r $GALLERY_NAME -g $RESOURCE_GROUP -i rhcos-arm64 -e 1.0.0

    以下示例镜像 ID 在计算机器设置的 recourseID 参数中使用:

    resourceID 示例

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0

4.2.3. 在集群中添加多架构计算机器集

要在集群中添加 ARM64 计算节点,您必须创建一个使用 ARM64 引导镜像的 Azure 计算机器集。要在 Azure 上创建自己的自定义计算机器集,请参阅"创建 Azure 上的计算机器集"。

先决条件

  • 已安装 OpenShift CLI(oc)。

流程

  • 使用以下命令,创建计算机器集并修改 resourceIDvmSize 参数。此计算机器集将控制集群中的 arm64 worker 节点:

    $ oc create -f arm64-machine-set-0.yaml

    使用 arm64 引导镜像的 YAML 计算机器集示例

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
      name: <infrastructure_id>-arm64-machine-set-0
      namespace: openshift-machine-api
    spec:
      replicas: 2
      selector:
        matchLabels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id>
          machine.openshift.io/cluster-api-machineset: <infrastructure_id>-arm64-machine-set-0
      template:
        metadata:
          labels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machine-role: worker
            machine.openshift.io/cluster-api-machine-type: worker
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-arm64-machine-set-0
        spec:
          lifecycleHooks: {}
          metadata: {}
          providerSpec:
            value:
              acceleratedNetworking: true
              apiVersion: machine.openshift.io/v1beta1
              credentialsSecret:
                name: azure-cloud-credentials
                namespace: openshift-machine-api
              image:
                offer: ""
                publisher: ""
                resourceID: /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0 1
                sku: ""
                version: ""
              kind: AzureMachineProviderSpec
              location: <region>
              managedIdentity: <infrastructure_id>-identity
              networkResourceGroup: <infrastructure_id>-rg
              osDisk:
                diskSettings: {}
                diskSizeGB: 128
                managedDisk:
                  storageAccountType: Premium_LRS
                osType: Linux
              publicIP: false
              publicLoadBalancer: <infrastructure_id>
              resourceGroup: <infrastructure_id>-rg
              subnet: <infrastructure_id>-worker-subnet
              userDataSecret:
                name: worker-user-data
              vmSize: Standard_D4ps_v5 2
              vnet: <infrastructure_id>-vnet
              zone: "<zone>"

    1
    resourceID 参数设置为 arm64 引导镜像。
    2
    vmSize 参数设置为安装中使用的实例类型。一些实例类型是 Standard_D4ps_v5D8ps

验证

  1. 输入以下命令验证新的 ARM64 机器是否正在运行:

    $ oc get machineset -n openshift-machine-api

    输出示例

    NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
    <infrastructure_id>-arm64-machine-set-0                   2        2      2          2  10m

  2. 您可以使用以下命令检查节点是否就绪并可访问:

    $ oc get nodes

4.3. 在 AWS 上使用多架构计算机器创建集群

要使用多架构计算机器创建 AWS 集群,您必须首先使用多架构安装程序二进制文件创建一个单架构 AWS 安装程序置备集群。如需有关 AWS 安装的更多信息,请参阅使用自定义在 AWS 上安装集群。然后,您可以在 AWS 集群中添加 ARM64 计算机器集。

4.3.1. 验证集群兼容性

在开始在集群中添加不同架构的计算节点前,您必须验证集群是否兼容多架构。

先决条件

  • 已安装 OpenShift CLI (oc)

流程

  • 您可以运行以下命令来检查集群是否使用构架有效负载:

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"

验证

  1. 如果您看到以下输出,集群将使用多架构有效负载:

    {
     "release.openshift.io/architecture": "multi",
     "url": "https://access.redhat.com/errata/<errata_version>"
    }

    然后,您可以开始在集群中添加多架构计算节点。

  2. 如果您看到以下输出,集群不使用多架构有效负载:

    {
     "url": "https://access.redhat.com/errata/<errata_version>"
    }
    重要

    要迁移集群以便集群支持多架构计算机器,请按照 Migrating to a cluster with multi-architecture compute machines 的步骤进行操作。

4.3.2. 在集群中添加 ARM64 计算机器集

要使用多架构计算机器配置集群,您必须创建一个 AWS ARM64 计算机器集。这会在集群中添加 ARM64 计算节点,以便集群有多架构计算机器。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您可以使用安装程序创建带有多架构安装程序二进制文件的 AMD64 单架构 AWS 集群。

流程

  • 创建和修改计算机器集,这将控制集群中的 ARM64 计算节点。

    $ oc create -f aws-arm64-machine-set-0.yaml

    部署 ARM64 计算节点的 YAML 计算机器集示例

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
      name: <infrastructure_id>-aws-arm64-machine-set-0 2
      namespace: openshift-machine-api
    spec:
      replicas: 1
      selector:
        matchLabels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
          machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 4
      template:
        metadata:
          labels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machine-role: <role> 5
            machine.openshift.io/cluster-api-machine-type: <role> 6
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 7
        spec:
          metadata:
            labels:
              node-role.kubernetes.io/<role>: ""
          providerSpec:
            value:
              ami:
                id: ami-02a574449d4f4d280 8
              apiVersion: awsproviderconfig.openshift.io/v1beta1
              blockDevices:
                - ebs:
                    iops: 0
                    volumeSize: 120
                    volumeType: gp2
              credentialsSecret:
                name: aws-cloud-credentials
              deviceIndex: 0
              iamInstanceProfile:
                id: <infrastructure_id>-worker-profile 9
              instanceType: m6g.xlarge 10
              kind: AWSMachineProviderConfig
              placement:
                availabilityZone: us-east-1a 11
                region: <region> 12
              securityGroups:
                - filters:
                    - name: tag:Name
                      values:
                        - <infrastructure_id>-worker-sg 13
              subnet:
                filters:
                  - name: tag:Name
                    values:
                      - <infrastructure_id>-private-<zone>
              tags:
                - name: kubernetes.io/cluster/<infrastructure_id> 14
                  value: owned
                - name: <custom_tag_name>
                  value: <custom_tag_value>
              userDataSecret:
                name: worker-user-data

    1 2 3 9 13 14
    指定基于置备集群时所设置的集群 ID 的基础架构 ID。如果已安装 OpenShift CLI,您可以通过运行以下命令来获取基础架构 ID:
    $ oc get -o jsonpath=‘{.status.infrastructureName}{“\n”}’ infrastructure cluster
    4 7
    指定基础架构 ID、角色节点标签和区域。
    5 6
    指定要添加的角色节点标签。
    8
    为 OpenShift Container Platform 节点的 AWS 区域指定支持 Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) 的 ARM64。
    $ oc get configmap/coreos-bootimages \
    	  -n openshift-machine-config-operator \
    	  -o jsonpath='{.data.stream}' | jq \
    	  -r '.architectures.<arch>.images.aws.regions."<region>".image'
    10
    指定支持 ARM64 的机器类型。如需更多信息,请参阅"为 AWS 64 位 ARM 测试实例类型"
    11
    指定区域,如 us-east-1a。确保您选择的区域提供 64 位 ARM 机器。
    12
    指定区域,如 us-east-1。确保您选择的区域提供 64 位 ARM 机器。

验证

  1. 输入以下命令来查看计算机器集列表:

    $ oc get machineset -n openshift-machine-api

    然后,您可以看到创建的 ARM64 机器集。

    输出示例

    NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
    <infrastructure_id>-aws-arm64-machine-set-0                   2        2      2          2  10m

  2. 您可以使用以下命令检查节点是否就绪并可访问:

    $ oc get nodes

4.4. 在 GCP 上使用多架构计算机器创建集群

要使用多架构计算机器创建 Google Cloud Platform (GCP)集群,您必须首先使用多架构安装程序二进制文件创建一个单架构 GCP 安装程序置备集群。如需有关 AWS 安装的更多信息,请参阅使用自定义在 GCP 上安装集群。然后,您可以在 GCP 集群中添加 ARM64 计算机器集。

注意

GCP 的 ARM64 机器目前不支持安全引导

4.4.1. 验证集群兼容性

在开始在集群中添加不同架构的计算节点前,您必须验证集群是否兼容多架构。

先决条件

  • 已安装 OpenShift CLI (oc)

流程

  • 您可以运行以下命令来检查集群是否使用构架有效负载:

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"

验证

  1. 如果您看到以下输出,集群将使用多架构有效负载:

    {
     "release.openshift.io/architecture": "multi",
     "url": "https://access.redhat.com/errata/<errata_version>"
    }

    然后,您可以开始在集群中添加多架构计算节点。

  2. 如果您看到以下输出,集群不使用多架构有效负载:

    {
     "url": "https://access.redhat.com/errata/<errata_version>"
    }
    重要

    要迁移集群以便集群支持多架构计算机器,请按照 Migrating to a cluster with multi-architecture compute machines 的步骤进行操作。

4.4.2. 在 GCP 集群中添加 ARM64 计算机器集

要使用多架构计算机器配置集群,您必须创建一个 GCP ARM64 计算机器集。这会在集群中添加 ARM64 计算节点。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您可以使用安装程序创建带有多架构安装程序二进制文件的 AMD64 单架构 AWS 集群。

流程

  • 创建和修改计算机器集,这会控制集群中的 ARM64 计算节点:

    $ oc create -f gcp-arm64-machine-set-0.yaml

    部署 ARM64 计算节点的 GCP YAML 计算机器集示例

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
      name: <infrastructure_id>-w-a
      namespace: openshift-machine-api
    spec:
      replicas: 1
      selector:
        matchLabels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id>
          machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
      template:
        metadata:
          creationTimestamp: null
          labels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machine-role: <role> 2
            machine.openshift.io/cluster-api-machine-type: <role>
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
        spec:
          metadata:
            labels:
              node-role.kubernetes.io/<role>: ""
          providerSpec:
            value:
              apiVersion: gcpprovider.openshift.io/v1beta1
              canIPForward: false
              credentialsSecret:
                name: gcp-cloud-credentials
              deletionProtection: false
              disks:
              - autoDelete: true
                boot: true
                image: <path_to_image> 3
                labels: null
                sizeGb: 128
                type: pd-ssd
              gcpMetadata: 4
              - key: <custom_metadata_key>
                value: <custom_metadata_value>
              kind: GCPMachineProviderSpec
              machineType: n1-standard-4 5
              metadata:
                creationTimestamp: null
              networkInterfaces:
              - network: <infrastructure_id>-network
                subnetwork: <infrastructure_id>-worker-subnet
              projectID: <project_name> 6
              region: us-central1 7
              serviceAccounts:
              - email: <infrastructure_id>-w@<project_name>.iam.gserviceaccount.com
                scopes:
                - https://www.googleapis.com/auth/cloud-platform
              tags:
                - <infrastructure_id>-worker
              userDataSecret:
                name: worker-user-data
              zone: us-central1-a

    1
    指定基于置备集群时所设置的集群 ID 的基础架构 ID。您可以运行以下命令来获取基础架构 ID:
    $ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
    2
    指定要添加的角色节点标签。
    3
    指定当前计算机器集中使用的镜像的路径。您需要到镜像的路径的项目和镜像名称。

    要访问项目和镜像名称,请运行以下命令:

    $ oc get configmap/coreos-bootimages \
      -n openshift-machine-config-operator \
      -o jsonpath='{.data.stream}' | jq \
      -r '.architectures.aarch64.images.gcp'

    输出示例

      "gcp": {
        "release": "415.92.202309142014-0",
        "project": "rhcos-cloud",
        "name": "rhcos-415-92-202309142014-0-gcp-aarch64"
      }

    使用输出中的 projectname 参数,在机器集中创建 image 字段的路径。镜像的路径应该采用以下格式:

    $ projects/<project>/global/images/<image_name>
    4
    可选:以 key:value 对的形式指定自定义元数据。有关用例,请参阅 GCP 文档,以查看设置自定义元数据
    5
    指定支持 ARM64 的机器类型。如需更多信息,请参阅"添加资源"的 64 位 ARM 基础架构上为 GCP 测试的实例类型
    6
    指定用于集群的 GCP 项目的名称。
    7
    指定区域,如 us-central1。确保您选择的区域提供 64 位 ARM 机器。

验证

  1. 输入以下命令来查看计算机器集列表:

    $ oc get machineset -n openshift-machine-api

    然后,您可以看到创建的 ARM64 机器集。

    输出示例

    NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
    <infrastructure_id>-gcp-arm64-machine-set-0                   2        2      2          2  10m

  2. 您可以使用以下命令检查节点是否就绪并可访问:

    $ oc get nodes

4.5. 在裸机、IBM Power 或 IBM Z 上使用多架构计算机器创建集群

要在裸机 (x86_64)、IBM Power® (ppc64le) 或 IBM Z® (s390x) 上使用多架构计算机器创建集群,您必须在其中一个平台上有一个现有的单架构集群。按照您的平台安装过程操作:

在为集群添加额外的计算节点前,您必须将集群升级到使用多架构有效负载的节点。有关迁移到多架构有效负载的更多信息,请参阅 迁移到带有多架构计算机器的集群

以下流程解释了如何使用 ISO 镜像或网络 PXE 引导创建 RHCOS 计算机器。这将允许您向集群添加额外的节点,并使用多架构计算机器部署集群。

4.5.1. 验证集群兼容性

在开始在集群中添加不同架构的计算节点前,您必须验证集群是否兼容多架构。

先决条件

  • 已安装 OpenShift CLI (oc)

流程

  • 您可以运行以下命令来检查集群是否使用构架有效负载:

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"

验证

  1. 如果您看到以下输出,集群将使用多架构有效负载:

    {
     "release.openshift.io/architecture": "multi",
     "url": "https://access.redhat.com/errata/<errata_version>"
    }

    然后,您可以开始在集群中添加多架构计算节点。

  2. 如果您看到以下输出,集群不使用多架构有效负载:

    {
     "url": "https://access.redhat.com/errata/<errata_version>"
    }
    重要

    要迁移集群以便集群支持多架构计算机器,请按照 Migrating to a cluster with multi-architecture compute machines 的步骤进行操作。

4.5.2. 使用 ISO 镜像创建 RHCOS 机器

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

先决条件

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

流程

  1. 运行以下命令,从集群中删除 Ignition 配置文件:

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
  2. 将您从集群导出的 worker.ign Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。
  3. 您可以验证 ignition 文件是否在 URL 上可用。以下示例获取计算节点的 Ignition 配置文件:

    $ curl -k http://<HTTP_server>/worker.ign
  4. 您可以运行以下命令来访问 ISO 镜像以引导新机器:

    RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.<architecture>.artifacts.metal.formats.iso.disk.location')
  5. 使用 ISO 文件在更多计算机器上安装 RHCOS。在安装集群前,使用创建机器时使用的相同方法:

    • 将 ISO 镜像刻录到磁盘并直接启动。
    • 在 LOM 接口中使用 ISO 重定向。
  6. 在不指定任何选项或中断实时引导序列的情况下引导 RHCOS ISO 镜像。等待安装程序在 RHCOS live 环境中引导进入 shell 提示符。

    注意

    您可以中断 RHCOS 安装引导过程来添加内核参数。但是,在这个 ISO 过程中,您应该使用以下步骤中所述的 coreos-installer 命令,而不是添加内核参数。

  7. 运行 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
  8. 在机器的控制台上监控 RHCOS 安装的进度。

    重要

    在开始安装 OpenShift Container Platform 之前,确保每个节点中安装成功。观察安装过程可以帮助确定可能会出现 RHCOS 安装问题的原因。

  9. 继续为集群创建更多计算机器。

4.5.3. 通过 PXE 或 iPXE 启动来创建 RHCOS 机器

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

先决条件

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

流程

  1. 确认 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_urlcoreos.live.rootfs_url 参数仅支持 HTTP 和 HTTPS。
      注意

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

    • 对于 iPXE (x86_64 + aarch64):

      kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
      initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3
      boot
      1
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。kernel 参数值是 kernel 文件的位置,在 UEFI 系统中引导时需要 initrd=main 参数,coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 worker Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 initramfs 文件的位置。
      注意

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

      注意

      要在 aarch64 架构中网络引导 CoreOS 内核,您需要使用启用了 IMAGE_GZIP 选项的 iPXE 构建版本。请参阅 iPXE 中的IMAGE_GZIP 选项

    • 对于 aarch64 中的 PXE(使用 UEFI 和 GRUB 作为第二阶段):

      menuentry 'Install CoreOS' {
          linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
          initrd rhcos-<version>-live-initramfs.<architecture>.img 3
      }
      1
      指定上传到 HTTP/TFTP 服务器的 RHCOS 文件的位置。kernel 参数值是 TFTP 服务器中的 kernel 文件的位置。coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 HTTP 服务器上的 worker Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 TFTP 服务器的 initramfs 文件的位置。
  2. 使用 PXE 或 iPXE 基础架构为集群创建所需的计算机器。

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

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

先决条件

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

流程

  1. 确认集群可以识别这些机器:

    $ oc get nodes

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.28.5
    master-1  Ready     master  63m  v1.28.5
    master-2  Ready     master  64m  v1.28.5

    输出中列出了您创建的所有机器。

    注意

    在有些 CSR 被批准前,前面的输出可能不包括计算节点(也称为 worker 节点)。

  2. 检查待处理的 CSR,并确保添加到集群中的每台机器都有 PendingApproved 状态的客户端请求:

    $ 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。

  3. 如果 CSR 没有获得批准,在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后,请批准集群机器的 CSR:

    注意

    由于 CSR 会自动轮转,因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们,证书将会轮转,每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后,Kubelet 为服务证书创建一个二级 CSR,这需要手动批准。然后,如果 Kubelet 请求具有相同参数的新证书,则后续提供证书续订请求由 machine-approver 自动批准。

    注意

    对于在未启用机器 API 的平台上运行的集群,如裸机和其他用户置备的基础架构,您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求,则 oc exec、ocrshoc logs 命令将无法成功,因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR,确认 CSR 由 system: nodesystem: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 可能无法使用。

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

    $ 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
    ...

  5. 如果剩余的 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
  6. 批准所有客户端和服务器 CSR 后,机器将 处于 Ready 状态。运行以下命令验证:

    $ oc get nodes

    输出示例

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

    注意

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

其他信息

4.6. 在带有 z/VM 的 IBM Z 和 IBM LinuxONE 上使用多架构计算机器创建集群

要使用 IBM® Z 和 IBM® LinuxONE (s390x)上的多架构计算机器创建集群,您必须使用现有的单架构 x86_64 集群。然后,您可以在 OpenShift Container Platform 集群中添加 s390x 计算机器。

在为集群添加 s390x 节点前,您必须将集群升级到使用多架构有效负载的节点。有关迁移到多架构有效负载的更多信息,请参阅 迁移到带有多架构计算机器的集群

以下流程描述了如何使用 z/VM 实例创建 RHCOS 计算机器。这将允许您在集群中添加 s390x 节点,并使用多架构计算机器部署集群。

注意

要使用 x86_64 上的多架构计算机器创建 IBM Z® 或 IBM® LinuxONE (s390x) 集群,请按照在 IBM Z® 和 IBM® LinuxONE 上安装集群 的说明操作。然后,您可以添加 x86_64 计算机器 ,如在裸机、IBM Power 或 IBM Z 上创建带有多架构计算机器的集群中所述。

4.6.1. 验证集群兼容性

在开始在集群中添加不同架构的计算节点前,您必须验证集群是否兼容多架构。

先决条件

  • 已安装 OpenShift CLI (oc)

流程

  • 您可以运行以下命令来检查集群是否使用构架有效负载:

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"

验证

  1. 如果您看到以下输出,集群将使用多架构有效负载:

    {
     "release.openshift.io/architecture": "multi",
     "url": "https://access.redhat.com/errata/<errata_version>"
    }

    然后,您可以开始在集群中添加多架构计算节点。

  2. 如果您看到以下输出,集群不使用多架构有效负载:

    {
     "url": "https://access.redhat.com/errata/<errata_version>"
    }
    重要

    要迁移集群以便集群支持多架构计算机器,请按照 Migrating to a cluster with multi-architecture compute machines 的步骤进行操作。

4.6.2. 使用 z/VM 在 IBM Z 上创建 RHCOS 机器

您可以使用 z/VM 创建在 IBM Z® 上运行的更多 Red Hat Enterprise Linux CoreOS (RHCOS)计算机器,并将它们附加到现有集群。

先决条件

  • 您有一个域名服务器(DNS),它可以对节点执行主机名和反向查找。
  • 您有在置备机器上运行的 HTTP 或 HTTPS 服务器,可供您创建的机器访问。

流程

  1. 禁用 UDP 聚合。

    目前,IBM Z® 不支持 UDP 聚合,且不会在带有 x86_64 control plane 和其他 s390x 计算机器的多架构计算机器上自动取消激活 UDP 聚合。为确保正确在集群中添加额外的计算节点,您必须手动禁用 UDP 聚合。

    1. 使用以下内容创建 YAML 文件 udp-aggregation-config.yaml

      apiVersion: v1
      kind: ConfigMap
      data:
        disable-udp-aggregation: "true"
      metadata:
        name: udp-aggregation-config
        namespace: openshift-network-operator
    2. 运行以下命令来创建 ConfigMap 资源:

      $ oc create -f udp-aggregation-config.yaml
  2. 运行以下命令,从集群中删除 Ignition 配置文件:

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
  3. 将您从集群导出的 worker.ign Ignition 配置文件上传到 HTTP 服务器。注意此文件的 URL。
  4. 您可以验证 Ignition 文件是否在 URL 上可用。以下示例获取计算节点的 Ignition 配置文件:

    $ curl -k http://<HTTP_server>/worker.ign
  5. 运行以下命令下载 RHEL live kernelinitramfsrootfs 文件:

    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
    | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
    | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
    | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')
  6. 将下载的 RHEL live kernelinitramfsrootfs 文件移到可从您要添加的 z/VM 客户机访问的 HTTP 或 HTTPS 服务器中。
  7. 为 z/VM 客户机创建一个参数文件。以下参数特定于虚拟机:

    • 可选: 要指定一个静态 IP 地址,请添加带有以下条目的 ip= 参数,每个条目用冒号隔开:

      1. 计算机的 IP 地址。
      2. 个空字符串。
      3. 网关
      4. 子网掩码.
      5. hostname.domainname 格式的机器主机和域名。省略这个值可让 RHCOS 决定。
      6. 网络接口名称。省略这个值可让 RHCOS 决定。
      7. none
    • 对于 coreos.inst.ignition_url=,请指定 worker.ign 文件的 URL。仅支持 HTTP 和 HTTPS 协议。
    • 对于 coreos.live.rootfs_url=,请为您引导的 kernelinitramfs 指定匹配的 rootfs 构件。仅支持 HTTP 和 HTTPS 协议。
    • 对于在 DASD 类型磁盘中安装,请完成以下任务:

      1. 对于 coreos.inst.install_dev=,请指定 /dev/dasda
      2. Userd .dasd= 指定安装 RHCOS 的 DASD。
      3. 所有其他参数保持不变。

        以下是一个示例参数文件 additional-worker-dasd.parm

        rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/dasda \
        coreos.live.rootfs_url=http://cl1.provide.example.com:8080/assets/rhcos-live-rootfs.s390x.img \
        coreos.inst.ignition_url=http://cl1.provide.example.com:8080/ignition/worker.ign \
        ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.dasd=0.0.3490

        将参数文件中的所有选项写为一行,并确保您没有换行字符。

    • 对于在 FCP 类型磁盘中安装,请完成以下任务:

      1. User d.zfcp=<adapter>,<wwpn>,<lun> 以指定要安装 RHCOS 的 FCP 磁盘。对于多路径,为每个额外路径重复此步骤。

        注意

        当使用多个路径安装时,您必须在安装后直接启用多路径,而不是在以后启用多路径,因为这可能导致问题。

      2. 将安装设备设置为:coreos.inst.install_dev=/dev/sda

        注意

        如果使用 NPIV 配置额外的 LUN,FCP 需要 zfcp.allow_lun_scan=0。如果必须启用 zfcp.allow_lun_scan=1,因为您使用 CSI 驱动程序,则必须配置 NPIV,以便每个节点无法访问另一个节点的引导分区。

      3. 所有其他参数保持不变。

        重要

        需要额外的安装后步骤才能完全启用多路径。如需更多信息,请参阅 安装后机器配置任务 中的"使用 RHCOS 上内核参数启用多路径"。

        以下是使用多路径的 worker 节点的 additional-worker-fcp.parm 示例参数文件:

        rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/sda \
        coreos.live.rootfs_url=http://cl1.provide.example.com:8080/assets/rhcos-live-rootfs.s390x.img \
        coreos.inst.ignition_url=http://cl1.provide.example.com:8080/ignition/worker.ign \
        ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000

        将参数文件中的所有选项写为一行,并确保您没有换行字符。

  8. 使用 FTP 将 initramfskernel、参数文件和 RHCOS 镜像传送到 z/VM 中。有关如何使用 FTP 传输文件并从虚拟读取器引导的详情,请参阅 在 Z/VM 中安装
  9. 将文件 punch 到 z/VM 虚拟机的虚拟读取器。

    请参阅 IBM® 文档中的 PUNCH

    提示

    您可以使用 CP PUNCH 命令,或者,如果使用 Linux,则使用 vmur 命令在两个 z/VM 虚拟机之间传输文件。

  10. 在 bootstrap 机器上登录到 CMS。
  11. 运行以下命令,从 reader IPL bootstrap 机器:

    $ ipl c

    请参阅 IBM® 文档中的 IPL

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

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

先决条件

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

流程

  1. 确认集群可以识别这些机器:

    $ oc get nodes

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.28.5
    master-1  Ready     master  63m  v1.28.5
    master-2  Ready     master  64m  v1.28.5

    输出中列出了您创建的所有机器。

    注意

    在有些 CSR 被批准前,前面的输出可能不包括计算节点(也称为 worker 节点)。

  2. 检查待处理的 CSR,并确保添加到集群中的每台机器都有 PendingApproved 状态的客户端请求:

    $ 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。

  3. 如果 CSR 没有获得批准,在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后,请批准集群机器的 CSR:

    注意

    由于 CSR 会自动轮转,因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们,证书将会轮转,每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后,Kubelet 为服务证书创建一个二级 CSR,这需要手动批准。然后,如果 Kubelet 请求具有相同参数的新证书,则后续提供证书续订请求由 machine-approver 自动批准。

    注意

    对于在未启用机器 API 的平台上运行的集群,如裸机和其他用户置备的基础架构,您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求,则 oc exec、ocrshoc logs 命令将无法成功,因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR,确认 CSR 由 system: nodesystem: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 可能无法使用。

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

    $ 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
    ...

  5. 如果剩余的 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
  6. 批准所有客户端和服务器 CSR 后,机器将 处于 Ready 状态。运行以下命令验证:

    $ oc get nodes

    输出示例

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

    注意

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

其他信息

4.7. 使用 RHEL KVM 在 IBM Z 和 IBM LinuxONE 上使用多架构计算机器创建集群

要使用 RHEL KVM 在 IBM Z® 和 IBM® LinuxONE (s390x) 上使用多架构计算机器创建集群,您必须有一个现有的单架构 x86_64 集群。然后,您可以在 OpenShift Container Platform 集群中添加 s390x 计算机器。

在为集群添加 s390x 节点前,您必须将集群升级到使用多架构有效负载的节点。有关迁移到多架构有效负载的更多信息,请参阅 迁移到带有多架构计算机器的集群

以下流程描述了如何使用 RHEL KVM 实例创建 RHCOS 计算机器。这将允许您在集群中添加 s390x 节点,并使用多架构计算机器部署集群。

注意

要使用 x86_64 上的多架构计算机器创建 IBM Z® 或 IBM® LinuxONE (s390x) 集群,请按照在 IBM Z® 和 IBM® LinuxONE 上安装集群 的说明操作。然后,您可以添加 x86_64 计算机器 ,如在裸机、IBM Power 或 IBM Z 上创建带有多架构计算机器的集群中所述。

4.7.1. 验证集群兼容性

在开始在集群中添加不同架构的计算节点前,您必须验证集群是否兼容多架构。

先决条件

  • 已安装 OpenShift CLI (oc)

流程

  • 您可以运行以下命令来检查集群是否使用构架有效负载:

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"

验证

  1. 如果您看到以下输出,集群将使用多架构有效负载:

    {
     "release.openshift.io/architecture": "multi",
     "url": "https://access.redhat.com/errata/<errata_version>"
    }

    然后,您可以开始在集群中添加多架构计算节点。

  2. 如果您看到以下输出,集群不使用多架构有效负载:

    {
     "url": "https://access.redhat.com/errata/<errata_version>"
    }
    重要

    要迁移集群以便集群支持多架构计算机器,请按照 Migrating to a cluster with multi-architecture compute machines 的步骤进行操作。

4.7.2. 使用 virt-install 创建 RHCOS 机器

您可以使用 virt-install 为集群创建更多 Red Hat Enterprise Linux CoreOS (RHCOS)计算机器。

先决条件

  • 您至少有一个 LPAR 在 KVM 的 RHEL 8.7 或更高版本中运行,在此过程中称为 RHEL KVM 主机。
  • KVM/QEMU 管理程序安装在 RHEL KVM 主机上。
  • 您有一个域名服务器(DNS),它可以对节点执行主机名和反向查找。
  • 设置了 HTTP 或 HTTPS 服务器。

流程

  1. 禁用 UDP 聚合。

    目前,IBM Z® 不支持 UDP 聚合,且不会在带有 x86_64 control plane 和其他 s390x 计算机器的多架构计算机器上自动取消激活 UDP 聚合。为确保正确在集群中添加额外的计算节点,您必须手动禁用 UDP 聚合。

    1. 使用以下内容创建 YAML 文件 udp-aggregation-config.yaml

      apiVersion: v1
      kind: ConfigMap
      data:
        disable-udp-aggregation: "true"
      metadata:
        name: udp-aggregation-config
        namespace: openshift-network-operator
    2. 运行以下命令来创建 ConfigMap 资源:

      $ oc create -f udp-aggregation-config.yaml
  2. 运行以下命令,从集群中删除 Ignition 配置文件:

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
  3. 将您从集群导出的 worker.ign Ignition 配置文件上传到 HTTP 服务器。注意此文件的 URL。
  4. 您可以验证 Ignition 文件是否在 URL 上可用。以下示例获取计算节点的 Ignition 配置文件:

    $ curl -k http://<HTTP_server>/worker.ign
  5. 运行以下命令下载 RHEL live kernelinitramfsrootfs 文件:

     $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
    | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
    | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
    | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')
  6. 在启动 virt-install 前,将下载的 RHEL live kernelinitramfsrootfs 文件移到 HTTP 或 HTTPS 服务器中。
  7. 使用 RHEL kernelinitramfs 和 Ignition 文件创建新的 KVM 客户机节点;新磁盘镜像,并调整了 parm 行参数。

    $ virt-install \
       --connect qemu:///system \
       --name <vm_name> \
       --autostart \
       --os-variant rhel9.2 \ 1
       --cpu host \
       --vcpus <vcpus> \
       --memory <memory_mb> \
       --disk <vm_name>.qcow2,size=<image_size> \
       --network network=<virt_network_parm> \
       --location <media_location>,kernel=<rhcos_kernel>,initrd=<rhcos_initrd> \ 2
       --extra-args "rd.neednet=1" \
       --extra-args "coreos.inst.install_dev=/dev/vda" \
       --extra-args "coreos.inst.ignition_url=<worker_ign>" \ 3
       --extra-args "coreos.live.rootfs_url=<rhcos_rootfs>" \ 4
       --extra-args "ip=<ip>::<default_gateway>:<subnet_mask_length>:<hostname>::none:<MTU>" \ 5
       --extra-args "nameserver=<dns>" \
       --extra-args "console=ttysclp0" \
       --noautoconsole \
       --wait
    1
    对于 os-variant,为 RHCOS 计算机器指定 RHEL 版本。rhel9.2 是推荐的版本。要查询支持的操作系统的 RHEL 版本,请运行以下命令:
    $ osinfo-query os -f short-id
    注意

    os-variant 是区分大小写的。

    2
    对于 --location,指定 kernel/initrd 在 HTTP 或 HTTPS 服务器上的位置。
    3
    对于 coreos.inst.ignition_url=,为机器角色指定 worker.ign Ignition 文件。仅支持 HTTP 和 HTTPS 协议。
    4
    对于 coreos.live.rootfs_url=,请为您引导的 kernelinitramfs 指定匹配的 rootfs 构件。仅支持 HTTP 和 HTTPS 协议。
    5
    可选: 对于 hostname,指定客户端机器的完全限定主机名。
    注意

    如果您使用 HAProxy 作为负载均衡器,在 /etc/haproxy/haproxy.cfg 配置文件中为 ingress-router-443ingress-router-80 更新 HAProxy 规则。

  8. 继续为集群创建更多计算机器。

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

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

先决条件

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

流程

  1. 确认集群可以识别这些机器:

    $ oc get nodes

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.28.5
    master-1  Ready     master  63m  v1.28.5
    master-2  Ready     master  64m  v1.28.5

    输出中列出了您创建的所有机器。

    注意

    在有些 CSR 被批准前,前面的输出可能不包括计算节点(也称为 worker 节点)。

  2. 检查待处理的 CSR,并确保添加到集群中的每台机器都有 PendingApproved 状态的客户端请求:

    $ 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。

  3. 如果 CSR 没有获得批准,在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后,请批准集群机器的 CSR:

    注意

    由于 CSR 会自动轮转,因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们,证书将会轮转,每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后,Kubelet 为服务证书创建一个二级 CSR,这需要手动批准。然后,如果 Kubelet 请求具有相同参数的新证书,则后续提供证书续订请求由 machine-approver 自动批准。

    注意

    对于在未启用机器 API 的平台上运行的集群,如裸机和其他用户置备的基础架构,您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求,则 oc exec、ocrshoc logs 命令将无法成功,因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR,确认 CSR 由 system: nodesystem: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 可能无法使用。

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

    $ 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
    ...

  5. 如果剩余的 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
  6. 批准所有客户端和服务器 CSR 后,机器将 处于 Ready 状态。运行以下命令验证:

    $ oc get nodes

    输出示例

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

    注意

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

其他信息

4.8. 在 IBM Power 上使用多架构计算机器创建集群

要在 IBM Power® (ppc64le) 上使用多架构计算机器创建集群,您必须有一个现有的单架构 (x86_64) 集群。然后,您可以将 ppc64le 计算机器添加到 OpenShift Container Platform 集群中。

重要

在为集群添加 ppc64le 节点前,您必须将集群升级到使用多架构有效负载的节点。有关迁移到多架构有效负载的更多信息,请参阅 迁移到带有多架构计算机器的集群

以下流程解释了如何使用 ISO 镜像或网络 PXE 引导创建 RHCOS 计算机器。这将允许您在集群中添加 ppc64le 节点,并使用多架构计算机器部署集群。

注意

要在 x86_64 上使用多架构计算机器创建 IBM Power®(ppc64le) 集群,请按照在 IBM Power® 上安装集群 的说明进行操作。然后,您可以添加 x86_64 计算机器 ,如在裸机、IBM Power 或 IBM Z 上创建带有多架构计算机器的集群中所述。

4.8.1. 验证集群兼容性

在开始在集群中添加不同架构的计算节点前,您必须验证集群是否兼容多架构。

先决条件

  • 已安装 OpenShift CLI (oc)
注意

在使用多个架构时,OpenShift Container Platform 节点的主机必须共享相同的存储层。如果它们没有相同的存储层,请使用 nfs-provisioner 等存储提供程序。

注意

您应该尽可能限制 compute 和 control plane 之间的网络跃点数量。

流程

  • 您可以运行以下命令来检查集群是否使用构架有效负载:

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"

验证

  1. 如果您看到以下输出,集群将使用多架构有效负载:

    {
     "release.openshift.io/architecture": "multi",
     "url": "https://access.redhat.com/errata/<errata_version>"
    }

    然后,您可以开始在集群中添加多架构计算节点。

  2. 如果您看到以下输出,集群不使用多架构有效负载:

    {
     "url": "https://access.redhat.com/errata/<errata_version>"
    }
    重要

    要迁移集群以便集群支持多架构计算机器,请按照 Migrating to a cluster with multi-architecture compute machines 的步骤进行操作。

4.8.2. 使用 ISO 镜像创建 RHCOS 机器

您可以使用 ISO 镜像为集群创建更多 Red Hat Enterprise Linux CoreOS (RHCOS) 计算机器,以创建机器。

先决条件

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

流程

  1. 运行以下命令,从集群中删除 Ignition 配置文件:

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
  2. 将您从集群导出的 worker.ign Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。
  3. 您可以验证 ignition 文件是否在 URL 上可用。以下示例获取计算节点的 Ignition 配置文件:

    $ curl -k http://<HTTP_server>/worker.ign
  4. 您可以运行以下命令来访问 ISO 镜像以引导新机器:

    RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.<architecture>.artifacts.metal.formats.iso.disk.location')
  5. 使用 ISO 文件在更多计算机器上安装 RHCOS。在安装集群前,使用创建机器时使用的相同方法:

    • 将 ISO 镜像刻录到磁盘并直接启动。
    • 在 LOM 接口中使用 ISO 重定向。
  6. 在不指定任何选项或中断实时引导序列的情况下引导 RHCOS ISO 镜像。等待安装程序在 RHCOS live 环境中引导进入 shell 提示符。

    注意

    您可以中断 RHCOS 安装引导过程来添加内核参数。但是,在这个 ISO 过程中,您应该使用以下步骤中所述的 coreos-installer 命令,而不是添加内核参数。

  7. 运行 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
  8. 在机器的控制台上监控 RHCOS 安装的进度。

    重要

    在开始安装 OpenShift Container Platform 之前,确保每个节点中安装成功。观察安装过程可以帮助确定可能会出现 RHCOS 安装问题的原因。

  9. 继续为集群创建更多计算机器。

4.8.3. 通过 PXE 或 iPXE 启动来创建 RHCOS 机器

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

先决条件

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

流程

  1. 确认 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_urlcoreos.live.rootfs_url 参数仅支持 HTTP 和 HTTPS。
      注意

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

    • 对于 iPXE (x86_64 + ppc64le):

      kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
      initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3
      boot
      1
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。kernel 参数值是 kernel 文件的位置,在 UEFI 系统中引导时需要 initrd=main 参数,coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 worker Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 initramfs 文件的位置。
      注意

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

      注意

      要在 ppc64le 架构中网络引导 CoreOS kernel,您需要使用启用了 IMAGE_GZIP 选项的 iPXE 构建版本。请参阅 iPXE 中的IMAGE_GZIP 选项

    • 对于 ppc64le 上的 PXE (使用 UEFI 和 GRUB 作为第二阶段):

      menuentry 'Install CoreOS' {
          linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
          initrd rhcos-<version>-live-initramfs.<architecture>.img 3
      }
      1
      指定上传到 HTTP/TFTP 服务器的 RHCOS 文件的位置。kernel 参数值是 TFTP 服务器中的 kernel 文件的位置。coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 HTTP 服务器上的 worker Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 TFTP 服务器的 initramfs 文件的位置。
  2. 使用 PXE 或 iPXE 基础架构为集群创建所需的计算机器。

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

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

先决条件

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

流程

  1. 确认集群可以识别这些机器:

    $ oc get nodes

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.28.5
    master-1  Ready     master  63m  v1.28.5
    master-2  Ready     master  64m  v1.28.5

    输出中列出了您创建的所有机器。

    注意

    在有些 CSR 被批准前,前面的输出可能不包括计算节点(也称为 worker 节点)。

  2. 检查待处理的 CSR,并确保添加到集群中的每台机器都有 PendingApproved 状态的客户端请求:

    $ 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。

  3. 如果 CSR 没有获得批准,在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后,请批准集群机器的 CSR:

    注意

    由于 CSR 会自动轮转,因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们,证书将会轮转,每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后,Kubelet 为服务证书创建一个二级 CSR,这需要手动批准。然后,如果 Kubelet 请求具有相同参数的新证书,则后续提供证书续订请求由 machine-approver 自动批准。

    注意

    对于在未启用机器 API 的平台上运行的集群,如裸机和其他用户置备的基础架构,您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求,则 oc exec、ocrshoc logs 命令将无法成功,因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR,确认 CSR 由 system: nodesystem: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 可能无法使用。

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

    $ 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
    ...

  5. 如果剩余的 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
  6. 批准所有客户端和服务器 CSR 后,机器将 处于 Ready 状态。运行以下命令验证:

    $ oc get nodes -o wide

    输出示例

    NAME               STATUS   ROLES                  AGE   VERSION           INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                                                       KERNEL-VERSION                  CONTAINER-RUNTIME
    worker-0-ppc64le   Ready    worker                 42d   v1.28.2+e3ba6d9   192.168.200.21   <none>        Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.ppc64le   cri-o://1.28.1-3.rhaos4.15.gitb36169e.el9
    worker-1-ppc64le   Ready    worker                 42d   v1.28.2+e3ba6d9   192.168.200.20   <none>        Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.ppc64le   cri-o://1.28.1-3.rhaos4.15.gitb36169e.el9
    master-0-x86       Ready    control-plane,master   75d   v1.28.2+e3ba6d9   10.248.0.38      10.248.0.38   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.28.1-3.rhaos4.15.gitb36169e.el9
    master-1-x86       Ready    control-plane,master   75d   v1.28.2+e3ba6d9   10.248.0.39      10.248.0.39   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.28.1-3.rhaos4.15.gitb36169e.el9
    master-2-x86       Ready    control-plane,master   75d   v1.28.2+e3ba6d9   10.248.0.40      10.248.0.40   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.28.1-3.rhaos4.15.gitb36169e.el9
    worker-0-x86       Ready    worker                 75d   v1.28.2+e3ba6d9   10.248.0.43      10.248.0.43   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.28.1-3.rhaos4.15.gitb36169e.el9
    worker-1-x86       Ready    worker                 75d   v1.28.2+e3ba6d9   10.248.0.44      10.248.0.44   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.28.1-3.rhaos4.15.gitb36169e.el9

    注意

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

其他信息

4.9. 使用多架构计算机器管理集群

4.9.1. 使用多架构计算机器在集群中调度工作负载

使用不同架构的计算节点在集群中部署工作负载需要注意和监控集群。您可能需要进行进一步的操作,才能成功将 pod 放置到集群的节点中。

如需有关节点关联性、调度、污点和容限和容忍的更多信息,请参阅以下文档:

4.9.1.1. 多架构节点工作负载部署示例

在使用不同架构的计算节点将工作负载调度到具有不同架构的计算节点上之前,请考虑以下用例:

使用节点关联性在节点上调度工作负载

您可以只允许将工作负载调度到其镜像支持的一组节点上,您可以在 pod 模板规格中设置 spec.affinity.nodeAffinity 字段。

nodeAffinity 设置为特定架构的部署示例

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
   # ...
  template:
     # ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values: 1
                - amd64
                - arm64

1
指定支持的构架。有效值包括 amd64,arm64, 或这两个值。
为特定架构污点每个节点

您可以污点节点,以避免与其架构不兼容的工作负载调度到该节点上。如果集群正在使用 MachineSet 对象,您可以在 .spec.template.spec.taints 字段中添加参数,以避免在带有不支持的架构的节点上调度工作负载。

  • 在污点节点前,您必须缩减 MachineSet 对象或删除可用的机器。您可以使用以下命令之一缩减机器集:

    $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api

    或者:

    $ oc edit machineset <machineset> -n openshift-machine-api

    有关扩展机器集的更多信息,请参阅"修改计算机器集"。

带有污点集的 MachineSet 示例

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      # ...
      taints:
      - effect: NoSchedule
        key: multi-arch.openshift.io/arch
        value: arm64

您还可以运行以下命令来在特定节点上设置污点:

$ oc adm taint nodes <node-name> multi-arch.openshift.io/arch=arm64:NoSchedule
创建默认容限

您可以运行以下命令来注解命名空间,以便所有工作负载都获得相同的默认容限:

$ oc annotate namespace my-namespace \
  'scheduler.alpha.kubernetes.io/defaultTolerations'='[{"operator": "Exists", "effect": "NoSchedule", "key": "multi-arch.openshift.io/arch"}]'
在工作负载中容忍架构污点

在具有定义污点的节点上,工作负载不会调度到该节点上。但是,您可以通过在 pod 的规格中设置容限来允许调度它们。

具有容限的部署示例

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      tolerations:
      - key: "multi-arch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"

本例部署也可以在指定了 multi-arch.openshift.io/arch=arm64 污点的节点上允许。

使用带有污点和容限的节点关联性

当调度程序计算一组要调度 pod 的节点时,容限可能会扩大集合,而节点关联性会限制集合。如果将污点设置为特定架构的节点,则需要以下示例容限才能调度 pod。

使用节点关联性和容限集的部署示例。

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - amd64
                - arm64
      tolerations:
      - key: "multi-arch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"

其他资源

4.9.2. 在 Red Hat Enterprise Linux CoreOS (RHCOS) 内核中启用 64k 页

您可以在集群中的 64 位 ARM 计算机器上启用 Red Hat Enterprise Linux CoreOS (RHCOS) 内核中的 64k 内存页。64k 页大小内核规格可用于大型 GPU 或高内存工作负载。这使用 Machine Config Operator (MCO) 完成,它使用机器配置池来更新内核。要启用 64k 页面大小,您必须为 ARM64 指定一个机器配置池,以便在内核中启用。

重要

使用 64k 页专用于 64 位 ARM 架构计算节点或在 64 位 ARM 机器上安装的集群。如果您使用 64 位 x86 机器在机器配置池中配置 64k 页内核,机器配置池和 MCO 将降级。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您在其中一个支持的平台中使用不同架构的计算节点创建集群。

流程

  1. 标记您要运行 64k 页大小内核的节点:

    $ oc label node <node_name> <label>

    示例命令

    $ oc label node worker-arm64-01 node-role.kubernetes.io/worker-64k-pages=

  2. 创建包含使用 ARM64 架构和 worker-64k-pages 角色的 worker 角色的机器配置池:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: worker-64k-pages
    spec:
      machineConfigSelector:
        matchExpressions:
          - key: machineconfiguration.openshift.io/role
            operator: In
            values:
            - worker
            - worker-64k-pages
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker-64k-pages: ""
          kubernetes.io/arch: arm64
  3. 在计算节点上创建机器配置,以使用 64k-pages 参数启用 64k-pages

    $ oc create -f <filename>.yaml

    MachineConfig 示例

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: "worker-64k-pages" 1
      name: 99-worker-64kpages
    spec:
      kernelType: 64k-pages 2

    1
    在自定义机器配置池中指定 machineconfiguration.openshift.io/role 标签的值。MachineConfig 示例使用 worker-64k-pages 标签在 worker-64k-pages 池中启用 64k 页面。
    2
    指定所需的内核类型。有效值为 64k-pagesdefault
    注意

    64k-pages 类型仅支持基于 64 位 ARM 架构。realtime 类型仅支持基于 64 位 x86 架构。

验证

  • 要查看您的新 worker-64k-pages 机器配置池,请运行以下命令:

    $ oc get mcp

    输出示例

    NAME     CONFIG                                                                UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master   rendered-master-9d55ac9a91127c36314e1efe7d77fbf8                      True      False      False      3              3                   3                     0                      361d
    worker   rendered-worker-e7b61751c4a5b7ff995d64b967c421ff                      True      False      False      7              7                   7                     0                      361d
    worker-64k-pages  rendered-worker-64k-pages-e7b61751c4a5b7ff995d64b967c421ff   True      False      False      2              2                   2                     0                      35m

4.9.3. 在多架构计算机器上的镜像流中导入清单列表

在带有多架构计算机器的 OpenShift Container Platform 4.15 集群中,集群中的镜像流不会自动导入清单列表。您必须手动将默认的 importMode 选项改为 PreserveOriginal 选项,才能导入清单列表。

先决条件

  • 已安装 OpenShift Container Platform CLI (oc)。

流程

  • 以下示例命令演示了如何对 ImageStream cli-artifacts 进行补丁,以便 cli-artifacts:latest 镜像流标签作为清单列表导入。

    $ oc patch is/cli-artifacts -n openshift -p '{"spec":{"tags":[{"name":"latest","importPolicy":{"importMode":"PreserveOriginal"}}]}}'

验证

  • 您可以通过检查镜像流标签来检查是否正确导入的清单列表。以下命令将列出特定标签的各个架构清单。

    $ oc get istag cli-artifacts:latest -n openshift -oyaml

    如果存在 dockerImageManifests 对象,则清单列表导入成功。

    dockerImageManifests 对象的输出示例

    dockerImageManifests:
      - architecture: amd64
        digest: sha256:16d4c96c52923a9968fbfa69425ec703aff711f1db822e4e9788bf5d2bee5d77
        manifestSize: 1252
        mediaType: application/vnd.docker.distribution.manifest.v2+json
        os: linux
      - architecture: arm64
        digest: sha256:6ec8ad0d897bcdf727531f7d0b716931728999492709d19d8b09f0d90d57f626
        manifestSize: 1252
        mediaType: application/vnd.docker.distribution.manifest.v2+json
        os: linux
      - architecture: ppc64le
        digest: sha256:65949e3a80349cdc42acd8c5b34cde6ebc3241eae8daaeea458498fedb359a6a
        manifestSize: 1252
        mediaType: application/vnd.docker.distribution.manifest.v2+json
        os: linux
      - architecture: s390x
        digest: sha256:75f4fa21224b5d5d511bea8f92dfa8e1c00231e5c81ab95e83c3013d245d1719
        manifestSize: 1252
        mediaType: application/vnd.docker.distribution.manifest.v2+json
        os: linux

第 5 章 在 vSphere 集群上启用加密

您可以通过一次排空和关闭节点,在 vSphere 上安装 OpenShift Container Platform 4.15 后对虚拟机进行加密。在每个虚拟机关闭时,您可以在 vCenter web 界面中启用加密。

5.1. 加密虚拟机

您可以使用以下过程对虚拟机进行加密。您可以排空虚拟机,关闭并使用 vCenter 接口加密它们。最后,您可以创建一个存储类以使用加密存储。

先决条件

流程

  1. 排空和封锁其中一个节点。有关节点管理的详细信息,请参阅"使用节点"。
  2. 在 vCenter 界面中关闭与该节点关联的虚拟机。
  3. 在 vCenter 界面中右键单击虚拟机,然后选择 VM PoliciesEdit VM Storage Policies
  4. 选择加密的存储策略并选择 OK
  5. 在 vCenter 界面中启动加密的虚拟机。
  6. 对您要加密的所有节点重复步骤 1-5。
  7. 配置使用加密存储策略的存储类。有关配置加密存储类的更多信息,请参阅"VMware vSphere CSI Driver Operator"。

5.2. 其他资源

第 6 章 安装后配置 vSphere 连接设置

在启用了平台集成功能的 vSphere 上安装 OpenShift Container Platform 集群后,您可能需要根据安装方法手动更新 vSphere 连接设置。

对于使用 Assisted Installer 的安装,您必须更新连接设置。这是因为 Assisted Installer 在安装过程中将默认连接设置作为占位符添加到 vSphere 连接配置向导中。

对于安装程序置备的基础架构安装,您应该在安装过程中输入有效的连接设置。您可以随时使用 vSphere 连接配置向导来验证或修改连接设置,但这不是完成安装的强制设置。

6.1. 配置 vSphere 连接设置

根据需要修改以下 vSphere 配置设置:

  • vCenter 地址
  • vCenter 集群
  • vCenter 用户名
  • vCenter 密码
  • vCenter 地址
  • vSphere 数据中心
  • vSphere 数据存储
  • 虚拟机文件夹

先决条件

流程

  1. 在 Administrator 视角中,进入到 Home → Overview
  2. Status 下,点 vSphere connection 打开 vSphere 连接配置向导。
  3. vCenter 字段中,输入 vSphere vCenter 服务器的网络地址。这可以是域名,也可以是 IP 地址。它会出现在 vSphere Web 客户端 URL 中,例如 https://[your_vCenter_address]/ui
  4. vCenter cluster 字段中,输入安装 OpenShift Container Platform 的 vSphere vCenter 集群名称。

    重要

    如果安装了 OpenShift Container Platform 4.13 或更高版本,则此步骤是必需的。

  5. Username 字段中,输入 vSphere vCenter 用户名。
  6. Password 字段中输入您的 vSphere vCenter 密码。

    警告

    系统将用户名和密码存储在集群的 kube-system 命名空间中的 vsphere-creds secret 中。不正确的 vCenter 用户名或密码使集群节点不可调度。

  7. Datacenter 字段中,输入 vSphere 数据中心的名称,其中包含用于托管集群的虚拟机;例如,SDDC-Datacenter
  8. Default data store 字段中,输入存储持久数据卷的 vSphere 数据存储的路径和名称;例如:/SDDC-Datacenter/datastore/datastorename

    警告

    在保存配置后,更新 vSphere 数据中心或默认数据存储会分离任何活跃的 vSphere PersistentVolume

  9. Virtual Machine Folder 字段中,输入包含集群虚拟机的数据中心文件夹;例如,/SDDC-Datacenter/vm/ci-ln-hjg4vg2-c61657-t2gzr。要使 OpenShift Container Platform 安装成功,组成集群的所有虚拟机都必须位于单个数据中心文件夹中。
  10. Save Configuration。这会更新 openshift-config 命名空间中的 cloud-provider-config ConfigMap 资源,并启动配置过程。
  11. 重新打开 vSphere 连接配置向导,再展开 Monitored operators 面板。检查 Operator 的状态是否为 ProgressingHealthy

6.2. 验证配置

连接配置过程更新 Operator 状态和 control plane 节点。完成大约需要一小时才能完成。在配置过程中,节点将重新引导。以前绑定的 PersistentVolumeClaims 对象可能会断开连接。

先决条件

  • 您已在 vSphere 连接配置向导中保存了配置设置。

流程

  1. 检查配置过程是否已成功完成:

    1. 在 OpenShift Container Platform Administrator 视角中,进入到 Home → Overview
    2. Status 下点 Operators。等待所有操作器状态从 Progressing 变为 All succeededFailed 状态表示配置失败。
    3. Status 下,点 Control Plane。等待所有 Control Pane 组件的响应率返回到 100%。失败的 control plane 组件表示配置失败。

    失败表示至少一个连接设置不正确。更改 vSphere 连接配置向导中的设置,然后再次保存配置。

  2. 通过执行以下步骤来检查您是否可以绑定 PersistentVolumeClaims 对象:

    1. 使用以下 YAML 创建 StorageClass 对象:

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
       name: vsphere-sc
      provisioner: kubernetes.io/vsphere-volume
      parameters:
       datastore: YOURVCENTERDATASTORE
       diskformat: thin
      reclaimPolicy: Delete
      volumeBindingMode: Immediate
    2. 使用以下 YAML 创建 PersistentVolumeClaims 对象:

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
       name: test-pvc
       namespace: openshift-config
       annotations:
         volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume
       finalizers:
         - kubernetes.io/pvc-protection
      spec:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
          storage: 10Gi
       storageClassName: vsphere-sc
       volumeMode: Filesystem

      如果您无法创建 PersistentVolumeClaims 对象,您可以在 OpenShift Container Platform Web 控制台的 Administrator 视角中进入 StoragePersistentVolumeClaims 来进行故障排除。

有关创建存储对象的说明,请参阅动态置备

第 7 章 安装后机器配置任务

有时您需要更改 OpenShift Container Platform 节点上运行的操作系统。这包括更改网络时间服务的设置、添加内核参数或者以特定的方式配置日志。

除了一些特殊功能外,通过创建称为 Machine Config Operator 管理的 MachineConfig 对象,可以对 OpenShift Container Platform 节点上的操作系统进行大多数更改。

本节中的任务介绍了如何使用 Machine Config Operator 的功能在 OpenShift Container Platform 节点上配置操作系统功能。

重要

NetworkManager 以 key file 的格式将新网络配置保存到 /etc/NetworkManager/system-connections/

在以前的版本中,NetworkManager 将新的网络配置以 ifcfg 格式保存到 /etc/sysconfig/network-scripts/。从 RHEL 9.0 开始,RHEL 将新网络配置存储在 /etc/NetworkManager/system-connections/ 中,采用 key 文件格式。以旧格式存储在 /etc/sysconfig/network-scripts/ 中的连接配置仍可以正常工作。对现有配置集的修改会继续更新旧的文件。

7.1. 了解 Machine Config Operator

7.1.1. Machine Config Operator

用途

Machine Congig Operator 管理并应用基本操作系统和容器运行时的配置和更新,包括内核和 kubelet 之间的所有配置和更新。

有四个组件:

  • machine-config-server:为加入集群的新机器提供 Ignition 配置。
  • machine-config-controller:协调机器升级到 MachineConfig 对象定义的配置。提供用来控制单独一组机器升级的选项。
  • machine-config-daemon:在更新过程中应用新机器配置。验证并验证机器的状态到请求的机器配置。
  • machine-config:提供安装、首次启动和更新一个机器的完整机器配置源。
重要

目前,不支持阻止或限制机器配置服务器端点。机器配置服务器必须公开给网络,以便新置备的机器没有现有配置或状态,才能获取其配置。在这个模型中,信任的根是证书签名请求 (CSR) 端点,即 kubelet 发送其证书签名请求以批准加入集群。因此,机器配置不应用于分发敏感信息,如 secret 和证书。

为确保机器配置服务器端点,端口 22623 和 22624 在裸机场景中是安全的,客户必须配置正确的网络策略。

项目

openshift-machine-config-operator

7.1.2. 机器配置概述

Machine Config Operator(MCO)管理对 systemd、CRI-O 和 Kubelet、内核、Network Manager 和其他系统功能的更新。它还提供了一个 MachineConfig CRD,它可以在主机上写入配置文件(请参阅 machine-config-operator)。了解 MCO 的作用以及如何与其他组件交互对于对 OpenShift Container Platform 集群进行高级系统级更改至关重要。以下是您应该了解的 MCO、机器配置以及它们的使用方式:

  • 机器配置按字母顺序处理,按字母顺序增加名称。呈现控制器使用列表中的第一个机器配置作为基础,并将剩余的附加到基本机器配置中。
  • 机器配置可以对每个系统的操作系统上的文件或服务进行特定的更改,代表一个 OpenShift Container Platform 节点池。
  • MCO 应用对机器池中的操作系统的更改。所有 OpenShift Container Platform 集群都以 worker 和 control plane 节点池开头。通过添加更多角色标签,您可以配置自定义节点池。例如,您可以设置一个自定义的 worker 节点池,其中包含应用程序所需的特定硬件功能。但是,本节中的示例着重介绍了对默认池类型的更改。

    重要

    一个节点可以应用多个标签来指示其类型,如 masterworker,但只能是一个单一机器配置池的成员。

  • 机器配置更改后,MCO 根据 topology.kubernetes.io/zone 标签,按区字母更新受影响的节点。如果一个区域有多个节点,则首先更新最旧的节点。对于不使用区的节点,如裸机部署中的节点,节点会按使用的时间升级,首先更新最旧的节点。MCO 一次更新机器配置池中由 maxUnavailable 字段指定的节点数量。
  • 在将 OpenShift Container Platform 安装到磁盘前,必须先进行一些机器配置。在大多数情况下,这可以通过创建直接注入 OpenShift Container Platform 安装程序进程中的机器配置来实现,而不必作为安装后机器配置运行。在其他情况下,您可能需要在 OpenShift Container Platform 安装程序启动时传递内核参数时进行裸机安装,以完成诸如设置每个节点的 IP 地址或高级磁盘分区等操作。
  • MCO 管理机器配置中设置的项目。MCO 不会覆盖您对系统进行的手动更改,除非明确告知 MCO 管理冲突文件。换句话说,MCO 只提供您请求的特定更新,它不会声明对整个节点的控制。
  • 强烈建议手动更改节点。如果您需要退出某个节点并启动一个新节点,则那些直接更改将会丢失。
  • MCO 只支持写入 /etc/var 目录里的文件,虽然有些目录的符号链接可以通过符号链接到那些区域之一来写入。例如 /opt/usr/local 目录。
  • Ignition 是 MachineConfig 中使用的配置格式。详情请参阅 Ignition 配置规格 v3.2.0
  • 虽然 Ignition 配置设置可以在 OpenShift Container Platform 安装时直接交付,且以 MCO 提供 Ignition 配置的方式格式化,但 MCO 无法查看这些原始 Ignition 配置是什么。因此,您应该在部署 Ignition 配置前将 Ignition 配置设置嵌套到机器配置中。
  • 当由 MCO 管理的文件在 MCO 之外更改时,Machine Config Daemon(MCD)会将该节点设置为 degraded。然而,它不会覆盖这个错误的文件,它应该继续处于 degraded(降级)状态。
  • 使用机器配置的一个关键原因是,当您为 OpenShift Container Platform 集群中的池添加新节点时,会应用它。machine-api-operator 置备一个新机器, MCO 配置它。

MCO 使用 Ignition 作为配置格式。OpenShift Container Platform 4.6 从 Ignition 配置规格版本 2 移到版本 3。

7.1.2.1. 机器配置可以更改什么?

MCO 可更改的组件类型包括:

  • config:创建 Ignition 配置对象(请参阅 Ignition 配置规格),以完成修改 OpenShift Container Platform 机器上的文件、systemd 服务和其他功能,包括:

    • Configuration files:创建或覆盖 /var/etc 目录中的文件。
    • systemd units:在附加设置中丢弃并设置 systemd 服务的状态,或者添加到现有 systemd 服务中。
    • 用户和组:在安装后更改 passwd 部分中的 SSH 密钥。

      重要
      • 只有 core 用户才支持使用机器配置更改 SSH 密钥。
      • 不支持使用机器配置添加新用户。
  • kernelArguments:在 OpenShift Container Platform 节点引导时在内核命令行中添加参数。
  • kernelType:(可选)使用非标准内核而不是标准内核。使用 realtime 来使用 RT 内核(用于 RAN)。这只在选择的平台上被支持。使用 64k-pages 参数启用 64k 页大小内核。此设置专用于具有 64 位 ARM 架构的机器。
  • fips:启用 FIPS 模式。不应在安装时设置 FIPS,而不是安装后的步骤。
重要

要为集群启用 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。

  • extensions:通过添加所选预打包软件来扩展 RHCOS 功能。对于这个功能,可用的扩展程序包括 usbguard 和内核模块。
  • Custom resources(用于 ContainerRuntimeKubelet:在机器配置外,MCO 管理两个特殊自定义资源,用于修改 CRI-O 容器运行时设置(ContainerRuntime CR)和 Kubelet 服务(Kubelet CR)。

MCO 不是更改 OpenShift Container Platform 节点上的操作系统组件的唯一 Operator。其他 Operator 也可以修改操作系统级别的功能。一个例子是 Node Tuning Operator,它允许您通过 Tuned 守护进程配置集进行节点级别的性能优化。

安装后可以进行的 MCO 配置任务包括在以下步骤中。如需在 OpenShift Container Platform 安装过程中或之前完成的系统配置任务,请参阅 RHCOS 裸机安装的描述。

在某些情况下,节点上的配置与当前应用的机器配置指定不完全匹配。这个状态被称为 配置偏移。Machine Config Daemon(MCD)定期检查节点是否有配置偏移。如果 MCD 检测到配置偏移,MCO 会将节点标记为 降级(degraded),直到管理员更正节点配置。降级的节点在线且可操作,但无法更新。有关配置偏移的更多信息,请参阅了解配置偏移检测

7.1.2.2. 项目

详情请参阅 openshift-machine-config-operator GitHub 站点。

7.1.3. 了解 Machine Config Operator 节点排空行为

当您使用机器配置更改系统功能时(如添加新配置文件、修改 systemd 单元或内核参数或更新 SSH 密钥),Machine Config Operator (MCO) 会应用这些更改,并确保每个节点处于所需的配置状态。

在进行更改后,MCO 会确保生成新的机器配置。在大多数情况下,当应用新的机器配置时,Operator 会在每个受影响的节点上执行以下步骤,直到所有受影响的节点都有更新的配置:

  1. Cordon.对于额外的工作负载,MCO 会将节点标记为不可调度。
  2. Drain.MCO 终止节点上运行的所有工作负载,导致工作负载重新调度到其他节点上。
  3. Apply.MCO 根据需要将新配置写入节点。
  4. 重新启动.MCO 重启节点。
  5. Uncordon.对于工作负载,MCO 将节点标记为可调度。

在此过程中,MCO 根据机器配置池中设置的 MaxUnavailable 值维护所需的 pod 数量。

如果 MCO 在 master 节点上排空 pod,请注意以下条件:

  • 在单节点 OpenShift 集群中,MCO 会跳过排空操作。
  • MCO 不会排空静态 pod,以防止干扰服务(如 etcd)。
注意

在某些情况下,节点不会被排空。如需更多信息,请参阅 "About the Machine Config Operator"。

您可以通过禁用 control plane 重启来缓解排空和重启周期造成的中断。如需更多信息,请参阅"禁用 Machine Config Operator 自动重新引导"。

7.1.4. 了解配置偏移检测

当节点的磁盘上状态与机器配置中配置的内容不同时,可能会出现情况。这称为 配置偏移(drift)。例如,集群管理员可能会手动修改一个文件、systemd 单元文件,或者通过机器配置配置的文件权限。这会导致配置偏移。配置偏移可能会导致 Machine Config Pool 中的节点或机器配置更新时出现问题。

Machine Config Operator(MCO)使用 Machine Config Daemon(MCD)定期检查节点是否有配置偏移。如果检测到,MCO 会将节点和机器配置池(MCP)设置为 Degraded,并报告错误。降级的节点在线且可操作,但无法更新。

MCD 在出现任何以下条件时执行配置偏移检测:

  • 当节点引导时。
  • 在机器配置中指定的任何文件(Ignition 文件和 systemd 置入单元)后,会在机器配置外修改。
  • 应用新机器配置前。

    注意

    如果您将新机器配置应用到节点,MCD 会临时关闭配置偏移检测。这个关闭是必需的,因为新机器配置必须与节点上的机器配置不同。应用新机器配置后,MCD 将使用新机器配置重启检测配置偏移。

在执行配置偏移检测时,MCD 会验证文件内容和权限是否与当前应用的机器配置指定完全匹配。通常,MCD 在触发检测后检测到小于第二个配置偏移。

如果 MCD 检测到配置偏移,MCD 执行以下任务:

  • 向控制台日志发送错误
  • 发送 Kubernetes 事件
  • 在节点上停止进一步检测
  • 将节点和 MCP 设置为 degraded

您可以通过列出 MCP 检查是否有降级的节点:

$ oc get mcp worker

如果您有一个降级的 MCP,DEGRADEDMACHINECOUNT 字段将不为零,类似于以下输出:

输出示例

NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-404caf3180818d8ac1f50c32f14b57c3   False     True       True       2              1                   1                     1                      5h51m

您可以通过检查机器配置池来确定问题是否由配置偏移导致:

$ oc describe mcp worker

输出示例

 ...
    Last Transition Time:  2021-12-20T18:54:00Z
    Message:               Node ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4 is reporting: "content mismatch for file \"/etc/mco-test-file\"" 1
    Reason:                1 nodes are reporting degraded status on sync
    Status:                True
    Type:                  NodeDegraded 2
 ...

1
此消息显示节点的 /etc/mco-test-file 文件(由机器配置添加)已在机器配置外有所变化。
2
节点的状态为 NodeDegraded

或者,如果您知道哪个节点已降级,请检查该节点:

$ oc describe node/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4

输出示例

 ...

Annotations:        cloud.network.openshift.io/egress-ipconfig: [{"interface":"nic0","ifaddr":{"ipv4":"10.0.128.0/17"},"capacity":{"ip":10}}]
                    csi.volume.kubernetes.io/nodeid:
                      {"pd.csi.storage.gke.io":"projects/openshift-gce-devel-ci/zones/us-central1-a/instances/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4"}
                    machine.openshift.io/machine: openshift-machine-api/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4
                    machineconfiguration.openshift.io/controlPlaneTopology: HighlyAvailable
                    machineconfiguration.openshift.io/currentConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
                    machineconfiguration.openshift.io/desiredConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
                    machineconfiguration.openshift.io/reason: content mismatch for file "/etc/mco-test-file" 1
                    machineconfiguration.openshift.io/state: Degraded 2
 ...

1
错误消息表示在节点和列出的机器配置间检测到配置偏移。此处的错误消息表示 /etc/mco-test-file 的内容由机器配置添加,在机器配置外有所变化。
2
节点的状态为 Degraded

您可以通过执行以下补救之一来更正配置偏移并将节点返回到 Ready 状态:

  • 确保节点上文件的内容和文件权限与机器配置中配置的内容匹配。您可以手动重写文件内容或更改文件权限。
  • 在降级节点上生成一个强制文件。强制文件使 MCD 绕过常见的配置偏移检测并消除了当前的机器配置。

    注意

    在节点上生成强制文件会导致该节点重新引导。

7.1.5. 检查机器配置池状态

要查看 Machine Config Operator(MCO)、其子组件及其管理的资源的状态,请使用以下 oc 命令:

流程

  1. 要查看集群中为每个机器配置池 (MCP) 中可用 MCO 管理的节点数量,请运行以下命令:

    $ oc get machineconfigpool

    输出示例

    NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
    master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
    worker    rendered-worker-f4b64…    False    True       False     3             2                  2                   0                     4h42m

    其中:

    UPDATED
    True 状态表示 MCO 已将当前机器配置应用到该 MCP 中的节点。当前机器配置在 oc get mcp 输出中的 STATUS 字段中指定。False 状态表示 MCP 中的节点正在更新。
    UPDATING
    True 状态表示 MCO 正在按照 MachineConfigPool 自定义资源中的规定应用到该 MCP 中的至少一个节点。所需的机器配置是新编辑的机器配置。要进行更新的节点可能不适用于调度。False 状态表示 MCP 中的所有节点都已更新。
    DEGRADED
    True 状态表示 MCO 被禁止将当前或所需的机器配置应用到该 MCP 中的至少一个节点,或者配置失败。降级的节点可能不适用于调度。False 状态表示 MCP 中的所有节点都就绪。
    MACHINECOUNT
    表示该 MCP 中的机器总数。
    READYMACHINECOUNT
    指明 MCP 中准备进行调度的机器总数。
    UPDATEDMACHINECOUNT
    指明 MCP 中有当前机器配置的机器总数。
    DEGRADEDMACHINECOUNT
    指明 MCP 中标记为 degraded 或 unreconcilable 的机器总数。

    在前面的输出中,有三个 control plane (master) 节点和三个 worker 节点。control plane MCP 和关联的节点更新至当前机器配置。worker MCP 中的节点会更新为所需的机器配置。worker MCP 中的两个节点被更新,一个仍在更新,如 UPDATEDMACHINECOUNT2。没有问题,如 DEGRADEDMACHINECOUNT0DEGRADEDFalse

    虽然 MCP 中的节点正在更新,但 CONFIG 下列出的机器配置是当前的机器配置,该配置会从这个配置进行更新。更新完成后,列出的机器配置是所需的机器配置,它被更新为 MCP。

    注意

    如果节点被封锁,则该节点不包含在 READYMACHINECOUNT 中,但包含在 MACHINECOUNT 中。另外,MCP 状态被设置为 UPDATING。因为节点具有当前的机器配置,所以它被计算在 UPDATEDMACHINECOUNT 总计:

    输出示例

    NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
    master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
    worker    rendered-worker-c1b41a…   False    True       False     3             2                  3                   0                     4h42m

  2. 要通过检查 MachineConfigPool 自定义资源来检查 MCP 中的节点状态,请运行以下命令:

    $ oc describe mcp worker

    输出示例

    ...
      Degraded Machine Count:     0
      Machine Count:              3
      Observed Generation:        2
      Ready Machine Count:        3
      Unavailable Machine Count:  0
      Updated Machine Count:      3
    Events:                       <none>

    注意

    如果节点被封锁,则节点不包含在 Ready Machine Count 中。它包含在 Unavailable Machine Count 中:

    输出示例

    ...
      Degraded Machine Count:     0
      Machine Count:              3
      Observed Generation:        2
      Ready Machine Count:        2
      Unavailable Machine Count:  1
      Updated Machine Count:      3

  3. 要查看每个现有的 MachineConfig 对象,请运行以下命令:

    $ oc get machineconfigs

    输出示例

    NAME                             GENERATEDBYCONTROLLER          IGNITIONVERSION  AGE
    00-master                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
    00-worker                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
    01-master-container-runtime      2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
    01-master-kubelet                2c9371fbb673b97a6fe8b1c52…     3.2.0            5h18m
    ...
    rendered-master-dde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
    rendered-worker-fde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m

    请注意,列为 renderedMachineConfig 对象并不意味着要更改或删除。

  4. 要查看特定机器配置的内容(本例中为 01-master-kubelet),请运行以下命令:

    $ oc describe machineconfigs 01-master-kubelet

    命令的输出显示此 MachineConfig 对象同时包含配置文件(cloud.confkubelet.conf) 和 systemd 服务(Kubernetes Kubelet):

    输出示例

    Name:         01-master-kubelet
    ...
    Spec:
      Config:
        Ignition:
          Version:  3.2.0
        Storage:
          Files:
            Contents:
              Source:   data:,
            Mode:       420
            Overwrite:  true
            Path:       /etc/kubernetes/cloud.conf
            Contents:
              Source:   data:,kind%3A%20KubeletConfiguration%0AapiVersion%3A%20kubelet.config.k8s.io%2Fv1beta1%0Aauthentication%3A%0A%20%20x509%3A%0A%20%20%20%20clientCAFile%3A%20%2Fetc%2Fkubernetes%2Fkubelet-ca.crt%0A%20%20anonymous...
            Mode:       420
            Overwrite:  true
            Path:       /etc/kubernetes/kubelet.conf
        Systemd:
          Units:
            Contents:  [Unit]
    Description=Kubernetes Kubelet
    Wants=rpc-statd.service network-online.target crio.service
    After=network-online.target crio.service
    
    ExecStart=/usr/bin/hyperkube \
        kubelet \
          --config=/etc/kubernetes/kubelet.conf \ ...

如果应用的机器配置出现问题,您可以随时退出这一更改。例如,如果您运行 oc create -f ./myconfig.yaml 以应用机器配置,您可以运行以下命令来删除该机器配置:

$ oc delete -f ./myconfig.yaml

如果这是唯一的问题,则受影响池中的节点应返回非降级状态。这会导致呈现的配置回滚到其之前更改的状态。

如果在集群中添加自己的机器配置,您可以使用上例中显示的命令检查其状态以及应用到它们的池的相关状态。

7.1.6. 检查机器配置节点状态

在更新过程中,您可能希望监控单个节点的进度,以防出现问题,您需要对节点进行故障排除。

要查看集群的 Machine Config Operator (MCO) 更新的状态,请使用以下 oc 命令:

重要

改进了 MCO 状态报告只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

流程

  1. 运行以下命令,获取所有机器配置池中所有节点的更新状态概述:

    $ oc get machineconfignodes

    输出示例

    NAME                          UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETED   UPDATECOMPLETED   RESUMED
    ip-10-0-12-194.ec2.internal   True      False             False              False                    False              False
    ip-10-0-17-102.ec2.internal   False     True              False              False                    False              False
    ip-10-0-2-232.ec2.internal    False     False             True               False                    False              False
    ip-10-0-59-251.ec2.internal   False     False             False              True                     False              False
    ip-10-0-59-56.ec2.internal    False     False             False              False                    True               True
    ip-10-0-6-214.ec2.internal    False     False             Unknown            False                    False              False

    其中:

    UPDATED
    True 状态表示 MCO 已将当前机器配置应用到该特定节点。False 状态表示节点当前正在更新。Unknown 状态表示操作正在处理。
    UPDATEPREPARED
    False 状态表示 MCO 尚未开始协调要分发的新机器配置。True 状态表示 MCO 已完成更新这个阶段。Unknown 状态表示操作正在处理。
    UPDATEEXECUTED
    False 状态表示 MCO 尚未启动封锁和排空节点。它还表示磁盘状态和操作系统尚未启动更新。True 状态表示 MCO 已完成更新这个阶段。Unknown 状态表示操作正在处理。
    UPDATEPOSTACTIONCOMPLETED
    False 状态表示 MCO 尚未启动重新引导节点或关闭守护进程。True 状态表示 MCO 已完成重新引导并更新节点状态。Unknown 状态表示在这个阶段更新过程中发生了错误,或者 MCO 当前正在应用更新。
    UPDATECOMPLETED
    False 状态表示 MCO 尚未启动节点并更新节点状态和指标。True 状态表示 MCO 完成更新节点状态和可用指标。
    RESUMED

    False 状态表示 MCO 尚未启动配置偏移监控器。True 状态表示节点有恢复的操作。Unknown 状态表示操作正在处理。

    注意

    在前面描述的主要阶段中,您可以有二级阶段,可用于查看更新进度。您可以使用上一命令的 -o wide 选项获取包含更新的辅助阶段的更多信息。这提供了额外的 UPDATECOMPATIBLE,UPDATEFILESANDOS,DRAINEDNODE,CORDONEDNODE,REBOOTNODE,RELOADEDCRIOUNCORDONED 列。这些辅助阶段并不总是发生,并依赖于您要应用的更新类型。

  2. 运行以下命令,检查特定机器配置池中节点的更新状态:

    $ oc get machineconfignodes $(oc get machineconfignodes -o json | jq -r '.items[]|select(.spec.pool.name=="<pool_name>")|.metadata.name') 1
    1
    池的名称是 MachineConfigPool 对象名称。

    输出示例

    NAME                          UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETE   UPDATECOMPLETE   RESUMED
    ip-10-0-48-226.ec2.internal   True      False            False            False                      False            False
    ip-10-0-5-241.ec2.internal    True      False            False            False                      False            False
    ip-10-0-74-108.ec2.internal   True      False            False            False                      False            False

  3. 运行以下命令,检查单个节点的更新状态:

    $ oc describe machineconfignode/<node_name> 1
    1
    节点的名称是 MachineConfigNode 对象名称。

    输出示例

    Name:         <node_name>
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  machineconfiguration.openshift.io/v1alpha1
    Kind:         MachineConfigNode
    Metadata:
      Creation Timestamp:  2023-10-17T13:08:58Z
      Generation:          1
      Resource Version:    49443
      UID:                 4bd758ab-2187-413c-ac42-882e61761b1d
    Spec:
      Node Ref:
        Name:         <node_name>
      Pool:
        Name:         master
      ConfigVersion:
        Desired: rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b 1
    Status:
      Conditions:
        Last Transition Time:  2023-10-17T13:09:02Z
        Message:               Node has completed update to config rendered-master-cf99e619747ab19165f11e3546c71f1e
        Reason:                NodeUpgradeComplete
        Status:                True
        Type:                  Updated
        Last Transition Time:  2023-10-17T13:09:02Z
        Message:               This node has not yet entered the UpdatePreparing phase
        Reason:                NotYetOccured
        Status:                False
      Config Version:
        Current:            rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b
        Desired:            rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b 2
      Health:               Healthy
      Most Recent Error:
      Observed Generation:  3

    1
    在节点上检测到新配置时,spec.configversion.desired 字段指定所需的配置会立即更新。
    2
    只有在 Machine Config Daemon (MCD)验证新配置时,status.configversion.desired 字段中指定的配置才会更新。MCD 通过检查更新的当前阶段来执行验证。如果更新成功通过 UPDATEPREPARED 阶段,则状态会添加新配置。

7.1.7. 查看证书并与其交互

以下证书由 Machine Config Controller (MCC) 在集群中处理,并可在 ControllerConfig 资源中找到:

  • /etc/kubernetes/kubelet-ca.crt
  • /etc/kubernetes/static-pod-resources/configmaps/cloud-config/ca-bundle.pem
  • /etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt

MCC 还处理镜像 registry 证书及其关联的用户捆绑包证书。

您可以获取有关列出的证书的信息,包括减少证书的捆绑包,以及签名和主题数据。

流程

  • 运行以下命令来获取详细的证书信息:

    $ oc get controllerconfig/machine-config-controller -o yaml | yq -y '.status.controllerCertificates'

    输出示例

    "controllerCertificates": [
                       {
                           "bundleFile": "KubeAPIServerServingCAData",
                           "signer": "<signer_data1>",
                           "subject": "CN=openshift-kube-apiserver-operator_node-system-admin-signer@168909215"
                       },
                       {
                           "bundleFile": "RootCAData",
                           "signer": "<signer_data2>",
                           "subject": "CN=root-ca,OU=openshift"
                       }
                    ]

  • 使用以下命令检查机器配置池状态,获取 ControllerConfig 中找到信息的更简单版本:

    $ oc get mcp master -o yaml | yq -y '.status.certExpirys'

    输出示例

    status:
      certExpirys:
      - bundle: KubeAPIServerServingCAData
        subject: CN=admin-kubeconfig-signer,OU=openshift
      - bundle: KubeAPIServerServingCAData
        subject: CN=kube-csr-signer_@1689585558
      - bundle: KubeAPIServerServingCAData
        subject: CN=kubelet-signer,OU=openshift
      - bundle: KubeAPIServerServingCAData
        subject: CN=kube-apiserver-to-kubelet-signer,OU=openshift
      - bundle: KubeAPIServerServingCAData
        subject: CN=kube-control-plane-signer,OU=openshift

    此方法适用于已经消耗机器配置池信息的 OpenShift Container Platform 应用程序。

  • 通过查看 /etc/docker/cert.d 目录的内容来检查节点上哪些镜像 registry 证书:

    # ls /etc/docker/certs.d

    输出示例

    image-registry.openshift-image-registry.svc.cluster.local:5000 image-registry.openshift-image-registry.svc:5000

7.2. 使用 MachineConfig 对象配置节点

您可以使用本节中的任务创建 MachineConfig 对象,修改 OpenShift Container Platform 节点上运行的文件、systemd 单元文件和其他操作系统功能。有关使用机器配置的更多信息,请参阅有关 更新 SSH 授权密钥、验证镜像签名启用 SCTP 的内容,并为 OpenShift Container Platform 配置 iSCSI initiatorname

OpenShift Container Platform 支持 Ignition 规格版本 3.2。您创建的所有新机器配置都应该基于 Ignition 规格版本 3.2。如果要升级 OpenShift Container Platform 集群,任何现有的 Ignition 规格版本 2.x 机器配置将自动转换为规格版本 3.2。

在某些情况下,节点上的配置与当前应用的机器配置指定不完全匹配。这个状态被称为 配置偏移。Machine Config Daemon(MCD)定期检查节点是否有配置偏移。如果 MCD 检测到配置偏移,MCO 会将节点标记为 降级(degraded),直到管理员更正节点配置。降级的节点在线且可操作,但无法更新。有关配置偏移的更多信息,请参阅了解配置偏移检测

提示

使用 "Configuring chrony time service" 部分作为如何将其他配置文件添加到 OpenShift Container Platform 节点的模型。

7.2.1. 配置 chrony 时间服务

您可以通过修改 chrony .conf 文件的内容,并将这些内容作为机器配置传递给节点,从而设置 chrony 时间服务(chronyd)使用的时间服务器和相关设置。

流程

  1. 创建一个 Butane 配置,包括 chrony.conf 文件的内容。例如,要在 worker 节点上配置 chrony,请创建一个 99-worker-chrony.bu 文件。

    注意

    如需有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    variant: openshift
    version: 4.15.0
    metadata:
      name: 99-worker-chrony 1
      labels:
        machineconfiguration.openshift.io/role: worker 2
    storage:
      files:
      - path: /etc/chrony.conf
        mode: 0644 3
        overwrite: true
        contents:
          inline: |
            pool 0.rhel.pool.ntp.org iburst 4
            driftfile /var/lib/chrony/drift
            makestep 1.0 3
            rtcsync
            logdir /var/log/chrony
    1 2
    在 control plane 节点上,在这两个位置中将 master 替换为 worker
    3
    为机器配置文件的 mode 字段指定数值模式。在创建文件并应用更改后,模式 将转换为十进制值。您可以使用 oc get mc <mc-name> -o yaml 命令来检查 YAML 文件。
    4
    指定任何有效的、可访问的时间源,如 DHCP 服务器提供的源。或者,您可以指定以下 NTP 服务器:1.rhel.pool.ntp.org, 2.rhel.pool.ntp.org, 或 3.rhel.pool.ntp.org
  2. 使用 Butane 生成 MachineConfig 对象文件 99-worker-chrony.yaml,其中包含要交付至节点的配置:

    $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
  3. 使用以下两种方式之一应用配置:

    • 如果集群还没有运行,在生成清单文件后,将 MachineConfig 对象文件添加到 <installation_directory>/openshift 目录中,然后继续创建集群。
    • 如果集群已在运行,请应用该文件:

      $ oc apply -f ./99-worker-chrony.yaml

7.2.2. 禁用 chrony 时间服务

您可以使用 MachineConfig 自定义资源 (CR) 为具有特定角色的节点禁用 chrony 时间服务 (chronyd)。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 创建 MachineConfig CR,为指定节点角色禁用 chronyd

    1. disable-chronyd.yaml 文件中保存以下 YAML:

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: <node_role> 1
        name: disable-chronyd
      spec:
        config:
          ignition:
            version: 3.2.0
          systemd:
            units:
              - contents: |
                  [Unit]
                  Description=NTP client/server
                  Documentation=man:chronyd(8) man:chrony.conf(5)
                  After=ntpdate.service sntp.service ntpd.service
                  Conflicts=ntpd.service systemd-timesyncd.service
                  ConditionCapability=CAP_SYS_TIME
                  [Service]
                  Type=forking
                  PIDFile=/run/chrony/chronyd.pid
                  EnvironmentFile=-/etc/sysconfig/chronyd
                  ExecStart=/usr/sbin/chronyd $OPTIONS
                  ExecStartPost=/usr/libexec/chrony-helper update-daemon
                  PrivateTmp=yes
                  ProtectHome=yes
                  ProtectSystem=full
                  [Install]
                  WantedBy=multi-user.target
                enabled: false
                name: "chronyd.service"
      1
      要禁用 chronyd 的节点角色,如 master
    2. 运行以下命令来创建 MachineConfig CR:

      $ oc create -f disable-chronyd.yaml

7.2.3. 为节点添加内核参数

在一些特殊情况下,您可能需要为集群中的一组节点添加内核参数。进行此操作时应小心谨慎,而且您必须先清楚了解所设参数的影响。

警告

不当使用内核参数会导致系统变得无法引导。

您可以设置的内核参数示例包括:

  • nosmt:在内核中禁用对称多线程 (SMT)。多线程允许每个 CPU 有多个逻辑线程。您可以在多租户环境中考虑使用 nosmt,以减少潜在的跨线程攻击风险。禁用 SMT 在本质上相当于选择安全性而非性能。
  • systemd.unified_cgroup_hierarchy:启用 Linux 控制组版本 2 (cgroup v2)。cgroup v2 是内核控制组的下一个版本,它包括了多个改进。
  • Enforcing=0:将 Security Enhanced Linux(SELinux)配置为以 permissive 模式运行。在 permissive 模式中,系统会象 enforcing 模式一样加载安全策略,包括标记对象并在日志中记录访问拒绝条目,但它并不会拒绝任何操作。虽然不建议在生产环境系统中使用 permissive 模式,但 permissive 模式会有助于调试。

    警告

    不支持在生产环境中禁用 RHCOS 上的 SELinux。在节点上禁用 SELinux 后,必须在生产集群中重新设置前重新置备它。

如需内核参数的列表和描述,请参阅 Kernel.org 内核参数

在以下流程中,您要创建一个用于标识以下内容的 MachineConfig 对象:

  • 您要添加内核参数的一组机器。本例中为具有 worker 角色的机器。
  • 附加到现有内核参数末尾的内核参数。
  • 指示机器配置列表中应用更改的位置的标签。

先决条件

  • 具有正常运行的 OpenShift Container Platform 集群的管理特权。

流程

  1. 列出 OpenShift Container Platform 集群的现有 MachineConfig 对象,以确定如何标记您的机器配置:

    $ oc get MachineConfig

    输出示例

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-ssh                                                                                 3.2.0             40m
    99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-worker-ssh                                                                                 3.2.0             40m
    rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

  2. 创建一个用于标识内核参数的 MachineConfig 对象文件(例如 05-worker-kernelarg-selinuxpermissive.yaml

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker1
      name: 05-worker-kernelarg-selinuxpermissive2
    spec:
      kernelArguments:
        - enforcing=03
    1
    仅将新内核参数应用到 worker 节点。
    2
    用于标识它插入到机器配置中的什么位置(05)以及发挥什么作用(添加一个内核参数来配置 SELinux permissive 模式)。
    3
    将确切的内核参数标识为 enforcing=0
  3. 创建新机器配置:

    $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml
  4. 检查机器配置以查看是否添加了新配置:

    $ oc get MachineConfig

    输出示例

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
    99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-ssh                                                                                 3.2.0             40m
    99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-worker-ssh                                                                                 3.2.0             40m
    rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

  5. 检查节点:

    $ oc get nodes

    输出示例

    NAME                           STATUS                     ROLES    AGE   VERSION
    ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.28.5
    ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.28.5
    ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.28.5
    ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.28.5
    ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.28.5
    ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.28.5

    您可以发现,在应用更改时每个 worker 节点上的调度都会被禁用。

  6. 前往其中一个 worker 节点并列出内核命令行参数(主机上的 /proc/cmdline 中),以检查内核参数确实已发挥作用:

    $ oc debug node/ip-10-0-141-105.ec2.internal

    输出示例

    Starting pod/ip-10-0-141-105ec2internal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.2# cat /host/proc/cmdline
    BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
    rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
    coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0
    
    sh-4.2# exit

    您应看到 enforcing=0 参数已添加至其他内核参数。

7.2.4. 在 RHCOS 上启用带有内核参数的多路径

Red Hat Enterprise Linux CoreOS (RHCOS) 支持主磁盘上的多路径,允许对硬件故障进行更强大的弹性,以实现更高的主机可用性。通过机器配置激活多路径,提供安装后支持。

重要

对于在 OpenShift Container Platform 4.8 或更高版本中置备的节点,推荐在安装过程中启用多路径。在任何 I/O 到未优化路径会导致 I/O 系统错误的设置中,您必须在安装时启用多路径。有关在安装过程中启用多路径的更多信息,请参阅在裸机上安装中的 "使用 RHCOS 上内核参数启用多路径"。

重要

在 IBM Z® 和 IBM® LinuxONE 中,您只能在在安装过程中为它配置集群时启用多路径。如需更多信息,请参阅在 IBM Z® 和 IBM® LinuxONE 上安装使用 z/VM 的集群"安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程"。

重要

当在配置了多路径的 IBM Power® 上带有 "vSCSI" 存储的单个 VIOS 主机中安装或配置为安装后活动时,启用了多路径的 CoreOS 节点无法引导。此行为是正常的,因为只有一个路径可用于节点。

先决条件

  • 您有一个正在运行的 OpenShift Container Platform 集群,它使用版本 4.7 或更高版本。
  • 以具有管理特权的用户身份登录集群。
  • 您已确认为多路径启用了磁盘。只有通过 HBA 适配器连接到 SAN 的主机上才支持多路径。

流程

  1. 要在 control plane 节点上启用多路径安装后:

    • 创建机器配置文件,如 99-master-kargs-mpath.yaml,该文件指示集群添加 master 标签并标识多路径内核参数,例如:

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: "master"
        name: 99-master-kargs-mpath
      spec:
        kernelArguments:
          - 'rd.multipath=default'
          - 'root=/dev/disk/by-label/dm-mpath-root'
  2. 在 worker 节点上启用多路径安装后:

    • 创建机器配置文件,如 99-worker-kargs-mpath.yaml,该文件指示集群添加 worker 标签并标识多路径内核参数,例如:

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: "worker"
        name: 99-worker-kargs-mpath
      spec:
        kernelArguments:
          - 'rd.multipath=default'
          - 'root=/dev/disk/by-label/dm-mpath-root'
  3. 使用之前创建的 master 或 worker YAML 文件创建新机器配置:

    $ oc create -f ./99-worker-kargs-mpath.yaml
  4. 检查机器配置以查看是否添加了新配置:

    $ oc get MachineConfig

    输出示例

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-ssh                                                                                 3.2.0             40m
    99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-worker-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             105s
    99-worker-ssh                                                                                 3.2.0             40m
    rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

  5. 检查节点:

    $ oc get nodes

    输出示例

    NAME                           STATUS                     ROLES    AGE   VERSION
    ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.28.5
    ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.28.5
    ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.28.5
    ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.28.5
    ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.28.5
    ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.28.5

    您可以发现,在应用更改时每个 worker 节点上的调度都会被禁用。

  6. 前往其中一个 worker 节点并列出内核命令行参数(主机上的 /proc/cmdline 中),以检查内核参数确实已发挥作用:

    $ oc debug node/ip-10-0-141-105.ec2.internal

    输出示例

    Starting pod/ip-10-0-141-105ec2internal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.2# cat /host/proc/cmdline
    ...
    rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
    ...
    
    sh-4.2# exit

    您应看到添加的内核参数。

7.2.5. 在节点中添加实时内核

一些 OpenShift Container Platform 工作负载需要高度确定性。虽然 Linux 不是实时操作系统,但 Linux 实时内核包含一个抢占调度程序,它为操作系统提供实时特征。

如果您的 OpenShift Container Platform 工作负载需要这些实时特征,您可以将机器切换到 Linux 实时内核。对于 OpenShift Container Platform,4.15 您可以使用 MachineConfig 对象进行这个切换。虽然进行这个切换非常简单(只需要把机器配置的 kernelType 设置为 realtime),但进行更改前需要注意:

  • 目前,实时内核只支持在 worker 节点上运行,且只支持无线电访问网络(RAN)使用。
  • 使用为 Red Hat Enterprise Linux for Real Time 8 认证系统的裸机安装完全支持以下步骤。
  • OpenShift Container Platform 中的实时支持仅限于特定的订阅。
  • 以下流程也支持与 Google Cloud Platform 搭配使用。

先决条件

  • 有一个正在运行的 OpenShift Container Platform 集群(版本 4.4 或更高版本)。
  • 以具有管理特权的用户身份登录集群。

流程

  1. 为实时内核创建一个机器配置:创建一个 YAML 文件(例如,99-worker-realtime.yaml),其中包含一个 realtime 内核类型的 MachineConfig 对象。本例告诉集群在所有 worker 节点中使用实时内核:

    $ cat << EOF > 99-worker-realtime.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: "worker"
      name: 99-worker-realtime
    spec:
      kernelType: realtime
    EOF
  2. 将机器配置添加到集群。键入以下内容将机器配置添加到集群中:

    $ oc create -f 99-worker-realtime.yaml
  3. 检查实时内核: 每当受影响节点重新引导后,登录到集群,并运行以下命令来确保您配置的节点组中使用实时内核替换了常规内核:

    $ oc get nodes

    输出示例

    NAME                                        STATUS  ROLES    AGE   VERSION
    ip-10-0-143-147.us-east-2.compute.internal  Ready   worker   103m  v1.28.5
    ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.28.5
    ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.28.5

    $ oc debug node/ip-10-0-143-147.us-east-2.compute.internal

    输出示例

    Starting pod/ip-10-0-143-147us-east-2computeinternal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.4# uname -a
    Linux <worker_node> 4.18.0-147.3.1.rt24.96.el8_1.x86_64 #1 SMP PREEMPT RT
            Wed Nov 27 18:29:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

    内核名称包含 rt 和 "PREMPT RT" 来表示这是一个实时内核。

  4. 要返回常规内核,请删除 MachineConfig 对象:

    $ oc delete -f 99-worker-realtime.yaml

7.2.6. 配置 journald 设置

如果您需要在 OpenShift Container Platform 节点上配置 journald 服务设置,您可以修改适当的配置文件并将该文件作为机器配置传递给适当的节点池。

此流程描述了如何修改 /etc/systemd/journald.conf 文件中的 journald 限制设置并将其应用到 worker 节点。有关如何使用该文件的详情,请查看 journald.conf 手册页。

先决条件

  • 有一个正在运行的 OpenShift Container Platform 集群。
  • 以具有管理特权的用户身份登录集群。

流程

  1. 创建一个 Butane 配置文件 40-worker-custom-journald.bu,其中包含带有所需设置的 /etc/systemd/journald.conf 文件。

    注意

    有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    variant: openshift
    version: 4.15.0
    metadata:
      name: 40-worker-custom-journald
      labels:
        machineconfiguration.openshift.io/role: worker
    storage:
      files:
      - path: /etc/systemd/journald.conf
        mode: 0644
        overwrite: true
        contents:
          inline: |
            # Disable rate limiting
            RateLimitInterval=1s
            RateLimitBurst=10000
            Storage=volatile
            Compress=no
            MaxRetentionSec=30s
  2. 使用 Butane 生成 MachineConfig 对象文件 40-worker-custom-journald.yaml,包含要发送到 worker 节点的配置:

    $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
  3. 将机器配置应用到池:

    $ oc apply -f 40-worker-custom-journald.yaml
  4. 检查是否应用新机器配置,并且节点是否处于降级状态。它可能需要几分钟时间。worker 池将显示更新进行中,每个节点都成功应用了新的机器配置:

    $ oc get machineconfigpool
    NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
    master rendered-master-35 True    False    False    3            3                 3                   0                    34m
    worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m
  5. 要检查是否应用了更改,您可以登录到 worker 节点:

    $ oc get node | grep worker
    ip-10-0-0-1.us-east-2.compute.internal   Ready    worker   39m   v0.0.0-master+$Format:%h$
    $ oc debug node/ip-10-0-0-1.us-east-2.compute.internal
    Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ...
    ...
    sh-4.2# chroot /host
    sh-4.4# cat /etc/systemd/journald.conf
    # Disable rate limiting
    RateLimitInterval=1s
    RateLimitBurst=10000
    Storage=volatile
    Compress=no
    MaxRetentionSec=30s
    sh-4.4# exit

7.2.7. 为 RHCOS 添加扩展

RHCOS 是基于容器的最小 RHEL 操作系统,旨在为所有平台的 OpenShift Container Platform 集群提供一组通用的功能。通常不建议在 RHCOS 系统中添加软件软件包,但 MCO 提供了一个 extensions(扩展) 功能,您可以使用 MCO 为 RHCOS 节点添加一组最小的功能。

目前,有以下扩展可用:

  • usbguard:添加 usbguard 扩展可保护 RHCOS 系统不受入侵 USB 设备的攻击。详情请查看 USBGuard
  • Kerberos:添加 kerberos 扩展提供了一种机制,允许用户和机器标识自身对网络进行定义的定义、限制对管理员配置的区域和服务的访问权限。请参阅使用 Kerberos 的详情,包括如何设置 Kerberos 客户端并挂载 Kerberized NFS 共享。

以下流程描述了如何使用机器配置为 RHCOS 节点添加一个或多个扩展。

先决条件

  • 有一个正在运行的 OpenShift Container Platform 集群(版本 4.6 或更高版本)。
  • 以具有管理特权的用户身份登录集群。

流程

  1. 为扩展创建机器配置:创建一个 YAML 文件(如 80-extensions.yaml),其中包含 MachineConfig extensions 对象。本例告诉集群添加 usbguard 扩展。

    $ cat << EOF > 80-extensions.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 80-worker-extensions
    spec:
      config:
        ignition:
          version: 3.2.0
      extensions:
        - usbguard
    EOF
  2. 将机器配置添加到集群。键入以下内容将机器配置添加到集群中:

    $ oc create -f 80-extensions.yaml

    这会将所有 worker 节点设置为安装 usbguard 的 rpm 软件包。

  3. 检查是否应用了扩展:

    $ oc get machineconfig 80-worker-extensions

    输出示例

    NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
    80-worker-extensions                       3.2.0           57s

  4. 检查是否应用新机器配置,并且节点是否处于降级状态。它可能需要几分钟时间。worker 池将显示更新进行中,每台机器都成功应用了新机器配置:

    $ oc get machineconfigpool

    输出示例

    NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
    master rendered-master-35 True    False    False    3            3                 3                   0                    34m
    worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

  5. 检查扩展。要检查是否应用了扩展,请运行:

    $ oc get node | grep worker

    输出示例

    NAME                                        STATUS  ROLES    AGE   VERSION
    ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.28.5

    $ oc debug node/ip-10-0-169-2.us-east-2.compute.internal

    输出示例

    ...
    To use host binaries, run `chroot /host`
    sh-4.4# chroot /host
    sh-4.4# rpm -q usbguard
    usbguard-0.7.4-4.el8.x86_64.rpm

7.2.8. 在机器配置清单中载入自定义固件 Blob

因为 /usr/lib 中固件 Blob 的默认位置是只读的,所以您可以通过更新搜索路径来查找自定义固件 Blob。这可让您在 RHCOS 不管理 blob 时载入机器配置清单中的本地固件 Blob。

流程

  1. 创建 Butane 配置文件 98-worker-firmware-blob.bu,它会更新搜索路径,以便其为 root 所有且对本地存储可写。以下示例将本地工作站的自定义 blob 文件放在 /var/lib/firmware 下的节点上。

    注意

    有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    自定义固件 blob 的 Butane 配置文件

    variant: openshift
    version: 4.15.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-worker-firmware-blob
    storage:
      files:
      - path: /var/lib/firmware/<package_name> 1
        contents:
          local: <package_name> 2
        mode: 0644 3
    openshift:
      kernel_arguments:
        - 'firmware_class.path=/var/lib/firmware' 4

    1
    设置将固件软件包复制到的节点上的路径。
    2
    指定包含从运行 Butane 的系统上本地文件目录中读取的内容的文件。本地文件的路径相对于 files-dir 目录,必须在下一步中使用 --files-dir 选项指定它。
    3
    为 RHCOS 节点上的文件设置权限。建议把选项设置为 0644
    4
    firmware_class.path 参数自定义内核搜索路径,在其中查找从本地工作站复制到节点的根文件系统的自定义固件 Blob。这个示例使用 /var/lib/firmware 作为自定义路径。
  2. 运行 Butane 生成 MachineConfig 对象文件,该文件使用名为 98-worker-firmware-blob.yaml 的本地工作站中的固件 blob 副本。固件 blob 包含要传送到节点的配置。以下示例使用 --files-dir 选项指定工作站上本地文件或目录所在的目录:

    $ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir <directory_including_package_name>
  3. 通过两种方式之一将配置应用到节点:

    • 如果集群还没有运行,在生成清单文件后,将 MachineConfig 对象文件添加到 <installation_directory>/openshift 目录中,然后继续创建集群。
    • 如果集群已在运行,请应用该文件:

      $ oc apply -f 98-worker-firmware-blob.yaml

      已为您创建一个 MachineConfig 对象 YAML 文件,以完成机器的配置。

  4. 如果将来需要更新 MachineConfig 对象,请保存 Butane 配置。

7.2.9. 更改节点访问的核心用户密码

默认情况下,Red Hat Enterprise Linux CoreOS (RHCOS) 在集群的节点上创建一个名为 core 的用户。您可以使用 core 用户通过云供应商串口控制台或裸机基板管理控制器管理器 (BMC) 访问节点。例如,如果节点停机且您无法使用 SSH 或 oc debug node 命令访问该节点,这非常有用。但是,默认情况下,此用户没有密码,因此您无法在不创建密码的情况下登录。

您可以使用机器配置为 core 用户创建密码。Machine Config Operator (MCO) 分配密码并将密码注入 /etc/shadow 文件中,允许您使用 core 用户登录。MCO 不会检查密码哈希。因此,如果密码出现问题,MCO 无法报告。

注意
  • 密码只能通过云供应商串口控制台或 BMC 正常工作。它不适用于 SSH。
  • 如果您有包含 /etc/shadow 文件或 systemd 单元的机器配置,则优先于密码哈希。

您可以通过编辑用于创建密码的机器配置来更改密码。另外,您可以通过删除机器配置来删除密码。删除机器配置不会删除用户帐户。

流程

  1. 使用您的操作系统支持的工具,创建一个哈希密码。例如,通过运行以下命令,使用 mkpasswd 创建哈希密码:

    $ mkpasswd -m SHA-512 testpass

    输出示例

    $ $6$CBZwA6s6AVFOtiZe$aUKDWpthhJEyR3nnhM02NM1sKCpHn9XN.NPrJNQ3HYewioaorpwL3mKGLxvW0AOb4pJxqoqP4nFX77y0p00.8.

  2. 创建包含 core 用户名和散列密码的机器配置文件:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: set-core-user-password
    spec:
      config:
        ignition:
          version: 3.2.0
        passwd:
          users:
          - name: core 1
            passwordHash: <password> 2
    1
    这必须是 core
    2
    core 帐户一起使用的散列密码。
  3. 运行以下命令来创建机器配置:

    $ oc create -f <file-name>.yaml

    节点不会重启,并在几分钟内可用。您可以使用 oc get mcp 来监控要更新的机器配置池,如下例所示:

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master   rendered-master-d686a3ffc8fdec47280afec446fce8dd   True      False      False      3              3                   3                     0                      64m
    worker   rendered-worker-4605605a5b1f9de1d061e9d350f251e5   False     True       False      3              0                   0                     0                      64m

验证

  1. 节点返回 UPDATED=True 状态后,运行以下命令为节点启动 debug 会话:

    $ oc debug node/<node_name>
  2. 运行以下命令,将 /host 设置为 debug shell 中的根目录:

    sh-4.4# chroot /host
  3. 检查 /etc/shadow 文件的内容:

    输出示例

    ...
    core:$6$2sE/010goDuRSxxv$o18K52wor.wIwZp:19418:0:99999:7:::
    ...

    哈希密码分配给 core 用户。

7.3. 配置 MCO 相关的自定义资源

除了管理 MachineConfig 对象外,MCO 管理两个自定义资源(CR):KubeletConfigContainerRuntimeConfig。这些 CR 可让您更改节点级别的设置,这会影响到 Kubelet 和 CRI-O 容器运行时服务的行为。

7.3.1. 创建 KubeletConfig CRD 来编辑 kubelet 参数

kubelet 配置目前被序列化为 Ignition 配置,因此可以直接编辑。但是,在 Machine Config Controller (MCC) 中同时添加了新的 kubelet-config-controller 。这可让您使用 KubeletConfig 自定义资源 (CR) 来编辑 kubelet 参数。

注意

因为 kubeletConfig 对象中的字段直接从上游 Kubernetes 传递给 kubelet,kubelet 会直接验证这些值。kubeletConfig 对象中的无效值可能会导致集群节点不可用。有关有效值,请参阅 Kubernetes 文档

请考虑以下指导:

  • 编辑现有的 KubeletConfig CR 以修改现有设置或添加新设置,而不是为每个更改创建一个 CR。建议您仅创建一个 CR 来修改不同的机器配置池,或用于临时更改,以便您可以恢复更改。
  • 为每个机器配置池创建一个 KubeletConfig CR,带有该池需要更改的所有配置。
  • 根据需要,创建多个 KubeletConfig CR,每个集群限制为 10。对于第一个 KubeletConfig CR,Machine Config Operator (MCO) 会创建一个机器配置,并附带 kubelet。对于每个后续 CR,控制器会创建另一个带有数字后缀的 kubelet 机器配置。例如,如果您有一个带有 -2 后缀的 kubelet 机器配置,则下一个 kubelet 机器配置会附加 -3
注意

如果要将 kubelet 或容器运行时配置应用到自定义机器配置池,则 machineConfigSelector 中的自定义角色必须与自定义机器配置池的名称匹配。

例如,由于以下自定义机器配置池名为 infra,因此自定义角色也必须是 infra

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
# ...

如果要删除机器配置,以相反的顺序删除它们,以避免超过限制。例如,在删除 kubelet-2 机器配置前删除 kubelet-3 机器配置。

注意

如果您有一个带有 kubelet-9 后缀的机器配置,并且创建了另一个 KubeletConfig CR,则不会创建新的机器配置,即使少于 10 个 kubelet 机器配置。

KubeletConfig CR 示例

$ oc get kubeletconfig

NAME                AGE
set-max-pods        15m

显示 KubeletConfig 机器配置示例

$ oc get mc | grep kubelet

...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
...

以下流程演示了如何配置 worker 节点上的每个节点的最大 pod 数量。

先决条件

  1. 为您要配置的节点类型获取与静态 MachineConfigPool CR 关联的标签。执行以下步骤之一:

    1. 查看机器配置池:

      $ oc describe machineconfigpool <name>

      例如:

      $ oc describe machineconfigpool worker

      输出示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        creationTimestamp: 2019-02-08T14:52:39Z
        generation: 1
        labels:
          custom-kubelet: set-max-pods 1

      1
      如果添加了标签,它会出现在 labels 下。
    2. 如果标签不存在,则添加一个键/值对:

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

流程

  1. 查看您可以选择的可用机器配置对象:

    $ oc get machineconfig

    默认情况下,与 kubelet 相关的配置为 01-master-kubelet01-worker-kubelet

  2. 检查每个节点的最大 pod 的当前值:

    $ oc describe node <node_name>

    例如:

    $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

    Allocatable 小节中找到 value: pods: <value>

    输出示例

    Allocatable:
     attachable-volumes-aws-ebs:  25
     cpu:                         3500m
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      15341844Ki
     pods:                        250

  3. 通过创建一个包含 kubelet 配置的自定义资源文件,设置 worker 节点上的每个节点的最大 pod:

    重要

    以特定机器配置池为目标的 kubelet 配置也会影响任何依赖的池。例如,为包含 worker 节点的池创建 kubelet 配置也适用于任何子集池,包括包含基础架构节点的池。要避免这种情况,您必须使用仅包含 worker 节点的选择表达式创建新的机器配置池,并让 kubelet 配置以这个新池为目标。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: set-max-pods
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: set-max-pods 1
      kubeletConfig:
        maxPods: 500 2
    1
    输入机器配置池中的标签。
    2
    添加 kubelet 配置。在本例中,使用 maxPods 设置每个节点的最大 pod。
    注意

    kubelet 与 API 服务器进行交互的频率取决于每秒的查询数量 (QPS) 和 burst 值。如果每个节点上运行的 pod 数量有限,使用默认值(kubeAPIQPS50kubeAPIBurst100)就可以。如果节点上有足够 CPU 和内存资源,则建议更新 kubelet QPS 和 burst 速率。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: set-max-pods
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: set-max-pods
      kubeletConfig:
        maxPods: <pod_count>
        kubeAPIBurst: <burst_rate>
        kubeAPIQPS: <QPS>
    1. 为带有标签的 worker 更新机器配置池:

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods
    2. 创建 KubeletConfig 对象:

      $ oc create -f change-maxPods-cr.yaml
    3. 验证 KubeletConfig 对象是否已创建:

      $ oc get kubeletconfig

      输出示例

      NAME                AGE
      set-max-pods        15m

      根据集群中的 worker 节点数量,等待每个 worker 节点被逐个重启。对于有 3 个 worker 节点的集群,这个过程可能需要大约 10 到 15 分钟。

  4. 验证更改是否已应用到节点:

    1. 在 worker 节点上检查 maxPods 值已更改:

      $ oc describe node <node_name>
    2. 找到 Allocatable 小节:

       ...
      Allocatable:
        attachable-volumes-gce-pd:  127
        cpu:                        3500m
        ephemeral-storage:          123201474766
        hugepages-1Gi:              0
        hugepages-2Mi:              0
        memory:                     14225400Ki
        pods:                       500 1
       ...
      1
      在本例中,pods 参数应报告您在 KubeletConfig 对象中设置的值。
  5. 验证 KubeletConfig 对象中的更改:

    $ oc get kubeletconfigs set-max-pods -o yaml

    这应该显示 True 状态和 type:Success,如下例所示:

    spec:
      kubeletConfig:
        maxPods: 500
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: set-max-pods
    status:
      conditions:
      - lastTransitionTime: "2021-06-30T17:04:07Z"
        message: Success
        status: "True"
        type: Success

7.3.2. 创建 ContainerRuntimeConfig CR 以编辑 CRI-O 参数

您可以为与特定机器配置池(MCP)关联的节点更改与 OpenShift Container Platform CRI-O 运行时关联的一些设置。通过使用 ContainerRuntimeConfig 自定义资源(CR),您可以设置配置值并添加一个标签以匹配 MCP。然后,MCO 会使用更新的值重建关联节点上的 crio.confstorage.conf 配置文件。

注意

要使用 ContainerRuntimeConfig CR 恢复实现的更改,您必须删除 CR。从机器配置池中删除标签不会恢复更改。

您可以使用 ContainerRuntimeConfig CR 修改以下设置:

  • PIDs limit :在 ContainerRuntimeConfig 中设置 PID 限值将被弃用。如果需要 PIDs 限制,建议在 KubeletConfig CR 中使用 podPidsLimit 字段。podPidsLimit 字段的默认值为 4096

    注意

    CRI-O 标志应用到容器的 cgroup 上,而 Kubelet 标志则在 pod 的 cgroup 中设置。请相应地调整 PID 限值。

  • 日志级别: logLevel 参数设置 CRI-O log_level 参数,即日志消息的详细程度。默认为 info (log_level = info)。其他选项包括 fatalpanicerrorwarndebugtrace
  • Overlay 大小overlaySize 参数设置 CRI-O Overlay 存储驱动程序 size 参数,这是容器镜像的最大大小。
  • 最大日志大小 :在 ContainerRuntimeConfig 中设置最大日志大小被弃用。如果需要最大日志大小,建议在 KubeletConfig CR 中使用 containerLogMaxSize 字段。
  • 容器运行时defaultRuntime 参数将容器运行时设置为 runccrun。默认为 runc

您应该为每个机器配置池有一个ContainerRuntimeConfig CR,并为该池分配所有配置更改。如果要将相同的内容应用到所有池,则所有池只需要 oneContainerRuntimeConfig CR。

您应该编辑现有的 ContainerRuntimeConfig CR,以修改现有设置或添加新设置,而不是为每个更改创建新 CR。建议您只创建一个新的 ContainerRuntimeConfig CR 来修改不同的机器配置池,或者用于临时的更改,以便您可以恢复更改。

您可以根据需要创建多个 ContainerRuntimeConfig CR,每个集群的限制为 10。对于第一个 ContainerRuntimeConfig CR,MCO 会创建一个机器配置并附加 containerruntime。对于每个后续 CR,控制器会创建一个带有数字后缀的新 containerruntime 机器配置。例如,如果您有一个带有 -2 后缀的 containerruntime 机器配置,则下一个 containerruntime 机器配置会附加 -3

如果要删除机器配置,应该以相反的顺序删除它们,以避免超过限制。例如,您应该在删除 containerruntime-2 机器配置前删除 containerruntime-3 机器配置。

注意

如果您的机器配置带有 containerruntime-9 后缀,并且创建了 anotherContainerRuntimeConfig CR,则不会创建新的机器配置,即使少于 10 个 containerruntime 机器配置。

显示多个 ContainerRuntimeConfig CR 示例

$ oc get ctrcfg

输出示例

NAME         AGE
ctr-overlay  15m
ctr-level    5m45s

显示多个 containerruntime 机器配置示例

$ oc get mc | grep container

输出示例

...
01-master-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
01-worker-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
99-worker-generated-containerruntime               b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
99-worker-generated-containerruntime-1             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             17m
99-worker-generated-containerruntime-2             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             7m26s
...

以下示例将 log_level 字段设置为 debug,并将覆盖大小设置为 8 GB:

ContainerRuntimeConfig CR 示例

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: '' 1
 containerRuntimeConfig:
   logLevel: debug 2
   overlaySize: 8G 3
   defaultRuntime: "crun" 4

1
指定机器配置池标签。对于容器运行时配置,角色必须与关联的机器配置池的名称匹配。
2
可选:指定日志消息的详细程度。
3
可选:指定容器镜像的最大大小。
4
可选:指定部署到新容器的容器运行时。默认值为 runc

流程

使用 ContainerRuntimeConfig CR 更改 CRI-O 设置:

  1. ContainerRuntimeConfig CR 创建 YAML 文件:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: ContainerRuntimeConfig
    metadata:
     name: overlay-size
    spec:
     machineConfigPoolSelector:
       matchLabels:
         pools.operator.machineconfiguration.openshift.io/worker: '' 1
     containerRuntimeConfig: 2
       logLevel: debug
       overlaySize: 8G
    1
    为您要修改的机器配置池指定一个标签。
    2
    根据需要设置参数。
  2. 创建 ContainerRuntimeConfig CR:

    $ oc create -f <file_name>.yaml
  3. 验证是否已创建 CR:

    $ oc get ContainerRuntimeConfig

    输出示例

    NAME           AGE
    overlay-size   3m19s

  4. 检查是否创建了新的 containerruntime 机器配置:

    $ oc get machineconfigs | grep containerrun

    输出示例

    99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s

  5. 监控机器配置池,直到所有系统都显示为 ready 状态:

    $ oc get mcp worker

    输出示例

    NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
    worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h

  6. 验证设置是否在 CRI-O 中应用:

    1. 打开到机器配置池中节点的 oc debug 会话,并运行 chroot /host

      $ oc debug node/<node_name>
      sh-4.4# chroot /host
    2. 验证 crio.conf 文件中的更改:

      sh-4.4# crio config | grep 'log_level'

      输出示例

      log_level = "debug"

    3. 验证 'storage.conf' 文件中的更改:

      sh-4.4# head -n 7 /etc/containers/storage.conf

      输出示例

      [storage]
        driver = "overlay"
        runroot = "/var/run/containers/storage"
        graphroot = "/var/lib/containers/storage"
        [storage.options]
          additionalimagestores = []
          size = "8G"

7.3.3. 使用 CRI-O 为 Overlay 设置默认的最大容器根分区大小

每个容器的根分区显示底层主机的所有可用磁盘空间。按照以下说明,为所有容器的 root 磁盘设置最大分区大小。

要配置最大 Overlay 大小以及其他 CRI-O 选项,您可以创建以下 ContainerRuntimeConfig 自定义资源定义 (CRD):

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     custom-crio: overlay-size
 containerRuntimeConfig:
   logLevel: debug
   overlaySize: 8G

流程

  1. 创建配置对象:

    $ oc apply -f overlaysize.yml
  2. 要将新的 CRI-O 配置应用到 worker 节点,请编辑 worker 机器配置池:

    $ oc edit machineconfigpool worker
  3. 根据在 ContainerRuntimeConfig CRD 中设置的 matchLabels 名称添加 custom-crio 标签:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      creationTimestamp: "2020-07-09T15:46:34Z"
      generation: 3
      labels:
        custom-crio: overlay-size
        machineconfiguration.openshift.io/mco-built-in: ""
  4. 保存更改,然后查看机器配置:

    $ oc get machineconfigs

    新的 99-worker-generated-containerruntimerendered-worker-xyz 对象被创建:

    输出示例

    99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
    rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s

  5. 创建这些对象后,监控机器配置池以了解要应用的更改:

    $ oc get mcp worker

    worker 节点将 UPDATING 显示为 True,以及机器数量、更新的数字和其他详情:

    输出示例

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    worker rendered-worker-xyz False True False     3             2                   2                    0                      20h

    完成后,worker 节点会从 UPDATING 转换回 FalseUPDATEDMACHINECOUNT 数与 MACHINECOUNT 数匹配:

    输出示例

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    worker   rendered-worker-xyz   True      False      False      3         3            3             0           20h

    查看 worker 机器,您会看到新的 8 GB 最大大小配置适用于所有 worker:

    输出示例

    head -n 7 /etc/containers/storage.conf
    [storage]
      driver = "overlay"
      runroot = "/var/run/containers/storage"
      graphroot = "/var/lib/containers/storage"
      [storage.options]
        additionalimagestores = []
        size = "8G"

    在容器内,您会看到 root 分区现在为 8 GB:

    输出示例

    ~ $ df -h
    Filesystem                Size      Used Available Use% Mounted on
    overlay                   8.0G      8.0K      8.0G   0% /

第 8 章 安装后集群任务

安装 OpenShift Container Platform 后,您可以按照自己的要求进一步扩展和自定义集群。

8.1. 可用的集群自定义

大多数集群配置和自定义在 OpenShift Container Platform 集群部署后完成。有若干配置资源可用。

注意

如果在 IBM Z® 上安装集群,则不是所有功能都可用。

您可以修改配置资源来配置集群的主要功能,如镜像 registry、网络配置、镜像构建操作以及用户身份供应商。

如需设置这些资源的当前信息,请使用 oc explain 命令,如 oc explain builds --api-version=config.openshift.io/v1

8.1.1. 集群配置资源

所有集群配置资源都作用于全局范围(而非命名空间),且命名为 cluster

资源名称描述

apiserver.config.openshift.io

提供 API 服务器配置,如 证书和证书颁发机构

authentication.config.openshift.io

控制集群的 身份提供程序 和身份验证配置。

build.config.openshift.io

控制集群中所有构建的默认和强制 配置

console.config.openshift.io

配置 Web 控制台界面的行为,包括 注销行为

featuregate.config.openshift.io

启用 FeatureGates,以便可以使用技术预览功能。

image.config.openshift.io

配置应如何对待 特定的镜像 registry (允许、禁止、不安全、CA 详情)。

ingress.config.openshift.io

路由相关的 配置详情,如路由的默认域。

oauth.config.openshift.io

配置身份提供程序以及与 内部 OAuth 服务器 流相关的其他行为。

project.config.openshift.io

配置项目(包括 项目模板)的方式

proxy.config.openshift.io

定义需要外部网络访问的组件要使用的代理。注意:目前不是所有组件都会消耗这个值。

scheduler.config.openshift.io

配置 调度程序行为,如配置集和默认节点选择器。

8.1.2. Operator 配置资源

这些配置资源是集群范围的实例,即 cluster,控制归特定 Operator 所有的特定组件的行为。

资源名称描述

consoles.operator.openshift.io

控制控制台外观,如品牌定制

config.imageregistry.operator.openshift.io

配置 OpenShift 镜像 registry 设置,如公共路由、日志级别、代理设置、资源约束、副本数和存储类型。

config.samples.operator.openshift.io

配置 Samples Operator,以控制在集群上安装哪些镜像流和模板示例。

8.1.3. 其他配置资源

这些配置资源代表一个特定组件的单一实例。在有些情况下,您可以通过创建多个资源实例来请求多个实例。在其他情况下,Operator 只消耗指定命名空间中的特定资源实例名称。如需有关如何和何时创建其他资源实例的详情,请参考具体组件的文档。

资源名称实例名称命名空间描述

alertmanager.monitoring.coreos.com

main

openshift-monitoring

控制 Alertmanager 部署参数。

ingresscontroller.operator.openshift.io

default

openshift-ingress-operator

配置 Ingress Operator 行为,如域、副本数、证书和控制器放置。

8.1.4. 信息资源

可以使用这些资源检索集群信息。有些配置可能需要您直接编辑这些资源。

资源名称实例名称描述

clusterversion.config.openshift.io

version

在 OpenShift Container Platform 4.15 中,不得自定义生产集群的 ClusterVersion 资源。相反,请按照流程 更新集群

dns.config.openshift.io

cluster

无法修改集群的 DNS 设置。您可以查看 DNS Operator 状态

infrastructure.config.openshift.io

cluster

允许集群与其云供应商交互的配置详情。

network.config.openshift.io

cluster

无法在安装后修改集群网络。要自定义您的网络,请按照流程 在安装过程中自定义网络

8.2. 更新全局集群 pull secret

您可以通过替换当前的 pull secret 或附加新的 pull secret 来更新集群的全局 pull secret。

当用户使用单独的 registry 存储镜像而不使用安装过程中的 registry时,需要这个过程。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 可选: 要将新的 pull secret 附加到现有 pull secret 中,请完成以下步骤:

    1. 输入以下命令下载 pull secret:

      $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1
      1
      提供 pull secret 文件的路径。
    2. 输入以下命令来添加新 pull secret:

      $ oc registry login --registry="<registry>" \ 1
      --auth-basic="<username>:<password>" \ 2
      --to=<pull_secret_location> 3
      1
      提供新的 registry。您可以在同一个 registry 中包含多个软件仓库,例如:--registry="<registry/my-namespace/my-repository>"
      2
      提供新 registry 的凭据。
      3
      提供 pull secret 文件的路径。

      另外,您可以对 pull secret 文件执行手动更新。

  2. 输入以下命令为您的集群更新全局 pull secret:

    $ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1
    1
    提供新 pull secret 文件的路径。

    该更新将推广至所有节点,可能需要一些时间,具体取决于集群大小。

    注意

    从 OpenShift Container Platform 4.7.4 开始,对全局 pull secret 的更改不再触发节点排空或重启。

8.3. 添加 worker 节点

部署 OpenShift Container Platform 集群后,您可以添加 worker 节点来扩展集群资源。您可以根据安装方法和集群的环境,添加 worker 节点的不同方法。

8.3.1. 在安装程序置备的基础架构集群中添加 worker 节点

对于安装程序置备的基础架构集群,您可以手动或自动扩展 MachineSet 对象以匹配可用的裸机主机数量。

要添加裸机主机,您必须配置所有网络先决条件,配置关联的 baremetalhost 对象,然后为集群置备 worker 节点。您可以手动添加裸机主机,或使用 Web 控制台。

8.3.2. 在用户置备的基础架构集群中添加 worker 节点

对于用户置备的基础架构集群,您可以使用 RHEL 或 RHCOS ISO 镜像添加 worker 节点,并使用集群 Ignition 配置文件将其连接到集群。对于 RHEL worker 节点,以下示例使用 Ansible playbook 在集群中添加 worker 节点。对于 RHCOS worker 节点,以下示例使用 ISO 镜像和网络引导来在集群中添加 worker 节点。

8.3.3. 将 worker 节点添加到由 Assisted Installer 管理的集群

对于由 Assisted Installer 管理的集群,您可以使用 Red Hat OpenShift Cluster Manager 控制台(辅助安装程序 REST API)添加 worker 节点,也可以使用 ISO 镜像和集群 Ignition 配置文件手动添加 worker 节点。

8.3.4. 将 worker 节点添加到由 Kubernetes 的多集群引擎管理的集群

对于由 Kubernetes 多集群引擎管理的集群,您可以使用专用多集群引擎控制台添加 worker 节点。

8.4. 调整 worker 节点

如果您在部署过程中错误地定义了 worker 节点的大小,请通过创建一个或多个新计算机器集来调整它们,扩展它们,然后扩展原始的计算机器集,然后再删除它们。

8.4.1. 了解计算机器集和机器配置池之间的区别

MachineSet 对象描述了与云或机器供应商相关的 OpenShift Container Platform 节点。

MachineConfigPool 对象允许 MachineConfigController 组件在升级过程中定义并提供机器的状态。

MachineConfigPool 对象允许用户配置如何将升级应用到机器配置池中的 OpenShift Container Platform 节点。

NodeSelector 对象可以被一个到 MachineSet 对象的引用替换。

8.4.2. 手动扩展计算机器集

要在计算机器集中添加或删除机器实例,您可以手动扩展计算机器集。

这个指南与全自动的、安装程序置备的基础架构安装相关。自定义的、用户置备的基础架构安装没有计算机器集。

先决条件

  • 安装 OpenShift Container Platform 集群和 oc 命令行。
  • 以具有 cluster-admin 权限的用户身份登录 oc

流程

  1. 运行以下命令,查看集群中的计算机器:

    $ oc get machinesets -n openshift-machine-api

    计算机器集以 <clusterid>-worker-<aws-region-az> 的形式列出。

  2. 运行以下命令,查看集群中的计算机器:

    $ oc get machine -n openshift-machine-api
  3. 运行以下命令,在要删除的计算机器上设置注解:

    $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"
  4. 运行以下命令来扩展计算机器集:

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

    或者:

    $ oc edit machineset <machineset> -n openshift-machine-api
    提示

    您还可以应用以下 YAML 来扩展计算机器集:

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    metadata:
      name: <machineset>
      namespace: openshift-machine-api
    spec:
      replicas: 2

    您可以扩展或缩减计算机器。需要过几分钟以后新机器才可用。

    重要

    默认情况下,机器控制器会尝试排空在机器上运行的节点,直到成功为止。在某些情况下,如错误配置了 pod 中断预算,排空操作可能无法成功。如果排空操作失败,机器控制器无法继续删除机器。

    您可以通过在特定机器上注解 machine.openshift.io/exclude-node-draining 来跳过排空节点。

验证

  • 运行以下命令,验证删除所需的机器:

    $ oc get machines

8.4.3. 计算机器集删除策略

RandomNewestOldest 是三个支持的删除选项。默认值为 Random,表示在扩展计算机器时随机选择并删除机器。通过修改特定的计算机器集,可以根据用例设置删除策略:

spec:
  deletePolicy: <delete_policy>
  replicas: <desired_replica_count>

无论删除策略是什么,都可通过在相关机器上添加 machine.openshift.io/delete-machine=true 注解来指定机器删除的优先级。

重要

默认情况下,OpenShift Container Platform 路由器 Pod 部署在 worker 上。由于路由器需要访问某些集群资源(包括 Web 控制台),除非先重新放置了路由器 Pod,否则请不要将 worker 计算机器集扩展为 0

注意

对于需要特定节点运行的用例,可以使用自定义计算机器集,在 worker 计算机器集缩减时,控制器会忽略这些服务。这可防止服务被中断。

8.4.4. 创建默认的集群范围节点选择器

您可以组合使用 pod 上的默认集群范围节点选择器和节点上的标签,将集群中创建的所有 pod 限制到特定节点。

使用集群范围节点选择器时,如果您在集群中创建 pod,OpenShift Container Platform 会将默认节点选择器添加到 pod,并将该 pod 调度到具有匹配标签的节点。

您可以通过编辑调度程序 Operator 自定义资源(CR)来配置集群范围节点选择器。您可向节点、计算机器集或机器配置添加标签。将标签添加到计算机器集可确保节点或机器停机时,新节点具有该标签。如果节点或机器停机,添加到节点或机器配置的标签不会保留。

注意

您可以向 pod 添加额外的键/值对。但是,您无法为一个默认的键添加不同的值。

流程

添加默认的集群范围节点选择器:

  1. 编辑调度程序 Operator CR 以添加默认的集群范围节点选择器:

    $ oc edit scheduler cluster

    使用节点选择器的调度程序 Operator CR 示例

    apiVersion: config.openshift.io/v1
    kind: Scheduler
    metadata:
      name: cluster
    ...
    spec:
      defaultNodeSelector: type=user-node,region=east 1
      mastersSchedulable: false

    1
    使用适当的 <key>:<value> 对添加节点选择器。

    完成此更改后,请等待重新部署 openshift-kube-apiserver 项目中的 pod。这可能需要几分钟。只有重新部署 pod 后,默认的集群范围节点选择器才会生效。

  2. 使用计算机器集或直接编辑节点,为节点添加标签:

    • 在创建节点时,使用计算机器集向由计算机器设置管理的节点添加标签:

      1. 运行以下命令,将标签添加到 MachineSet 对象中:

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api 1
        1
        为每个标识添加 <key>/<value> 对。

        例如:

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api
        提示

        您还可以应用以下 YAML 来向计算机器集中添加标签:

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"
      2. 使用 oc edit 命令验证标签是否已添加到 MachineSet 对象中:

        例如:

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        MachineSet 对象示例

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
          ...
        spec:
          ...
          template:
            metadata:
          ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node
          ...

      3. 通过缩减至 0 并扩展节点来重新部署与该计算机器集关联的节点:

        例如:

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
      4. 当节点就绪并可用时,使用 oc get 命令验证该标签是否已添加到节点:

        $ oc get nodes -l <key>=<value>

        例如:

        $ oc get nodes -l type=user-node

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.28.5

    • 直接向节点添加标签:

      1. 为节点编辑 Node 对象:

        $ oc label nodes <name> <key>=<value>

        例如,若要为以下节点添加标签:

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east
        提示

        您还可以应用以下 YAML 来向节点添加标签:

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            type: "user-node"
            region: "east"
      2. 使用 oc get 命令验证标签是否已添加到节点:

        $ oc get nodes -l <key>=<value>,<key>=<value>

        例如:

        $ oc get nodes -l type=user-node,region=east

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.28.5

8.5. 使用 worker 延迟配置集提高高延迟环境中的集群稳定性

如果集群管理员为平台验证执行了延迟测试,他们可以发现需要调整集群的操作,以确保高延迟的情况的稳定性。集群管理员只需要更改一个参数,该参数记录在一个文件中,它控制了 Supervisory 进程读取状态并解释集群的运行状况的四个参数。仅更改一个参数可以以方便、可支持的方式提供集群调整。

Kubelet 进程提供监控集群运行状况的起点。Kubelet 为 OpenShift Container Platform 集群中的所有节点设置状态值。Kubernetes Controller Manager (kube controller) 默认每 10 秒读取状态值。如果 kube 控制器无法读取节点状态值,它会在配置的时间后丢失与该节点联系。默认行为是:

  1. control plane 上的节点控制器将节点健康状况更新为 Unhealthy,并奖节点 Ready 的条件标记为 'Unknown'。
  2. 因此,调度程序会停止将 pod 调度到该节点。
  3. Node Lifecycle Controller 添加了一个 node.kubernetes.io/unreachable 污点,对节点具有 NoExecute 效果,默认在五分钟后调度节点上的任何 pod 进行驱除。

如果您的网络容易出现延迟问题,尤其是在网络边缘中有节点时,此行为可能会造成问题。在某些情况下,Kubernetes Controller Manager 可能会因为网络延迟而从健康的节点接收更新。Kubelet 会从节点中驱除 pod,即使节点处于健康状态。

要避免这个问题,您可以使用 worker 延迟配置集调整 kubelet 和 Kubernetes Controller Manager 在执行操作前等待状态更新的频率。如果在控制平面和 worker 节点间存在网络延迟,worker 节点没有处于最近状态,这个调整有助于集群可以正常工作。

这些 worker 延迟配置集包含预定义的三组参数,它们带有经过仔细调优的值,以控制集群对增加的延迟进行适当地响应。用户不需要手动进行实验以查找最佳值。

您可在安装集群时配置 worker 延迟配置集,或当您发现集群网络中的延迟增加时。

8.5.1. 了解 worker 延迟配置集

worker 延迟配置集带有四个不同的、包括经过仔细调优的参数的类别。实现这些值的四个参数是 node-status-update-frequencynode-monitor-grace-perioddefault-not-ready-toleration-secondsdefault-unreachable-toleration-seconds。这些参数可让您使用这些值来控制集群对延迟问题的响应,而无需手动确定最佳值。

重要

不支持手动设置这些参数。参数设置不正确会影响集群的稳定性。

所有 worker 延迟配置集配置以下参数:

node-status-update-frequency
指定 kubelet 将节点状态发布到 API 服务器的频率。
node-monitor-grace-period
指定 Kubernetes Controller Manager 在节点不健康前等待更新的时间(以秒为单位),并将 node.kubernetes.io/not-readynode.kubernetes.io/unreachable 污点添加到节点。
default-not-ready-toleration-seconds
指定在标记节点不健康后,Kube API Server Operator 在从该节点驱除 pod 前等待的时间(以秒为单位)。
default-unreachable-toleration-seconds
指定在节点无法访问后,Kube API Server Operator 在从该节点驱除 pod 前等待的时间(以秒为单位)。

以下 Operator 监控 worker 延迟配置集的更改并相应地响应:

  • Machine Config Operator (MCO) 更新 worker 节点上的 node-status-update-frequency 参数。
  • Kubernetes Controller Manager 更新 control plane 节点上的 node-monitor-grace-period 参数。
  • Kubernetes API Server Operator 更新 control plane 节点上的 default-not-ready-toleration-secondsdefault-unreachable-toleration-seconds 参数。

虽然默认配置在大多数情况下可以正常工作,但 OpenShift Container Platform 会为网络遇到比通常更高的延迟的情况提供两个其他 worker 延迟配置集。以下部分描述了三个 worker 延迟配置集:

默认 worker 延迟配置集

使用 Default 配置集时,每个 Kubelet 每 10 秒更新其状态(node-status-update-frequency)。Kube Controller Manager 每 5 秒检查 Kubelet 的状态(node-monitor-grace-period)。

在认为 Kubelet 不健康前,Kubernetes Controller Manager 会等待 40 秒以获取来自 Kubelet 的状态更新。如果没有可用于 Kubernetes Controller Manager 的使用状态,它会使用 node.kubernetes.io/not-readynode.kubernetes.io/unreachable 污点标记节点,并驱除该节点上的 pod。

如果该节点上的 pod 具有 NoExecute 污点,则 pod 会根据 tolerationSeconds 运行。如果 pod 没有污点,它将在 300 秒内被驱除(default-not-ready-toleration-secondsKube API Serverdefault-unreachable-toleration-seconds 设置)。

profile组件参数

Default(默认)

kubelet

node-status-update-frequency

10s

kubelet Controller Manager

node-monitor-grace-period

40s

Kubernetes API Server Operator

default-not-ready-toleration-seconds

300s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

300s

中型 worker 延迟配置集

如果网络延迟比通常稍高,则使用 MediumUpdateAverageReaction 配置集。

MediumUpdateAverageReaction 配置集减少了 kubelet 更新频率为 20 秒,并将 Kubernetes Controller Manager 等待这些更新的时间更改为 2 分钟。该节点上的 pod 驱除周期会减少到 60 秒。如果 pod 具有 tolerationSeconds 参数,则驱除会等待该参数指定的周期。

Kubernetes Controller Manager 会先等待 2 分钟时间,才会认为节点不健康。另一分钟后,驱除过程会启动。

profile组件参数

MediumUpdateAverageReaction

kubelet

node-status-update-frequency

20s

kubelet Controller Manager

node-monitor-grace-period

2m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

低 worker 延迟配置集

如果网络延迟非常高,请使用 LowUpdateSlowReaction 配置集。

LowUpdateSlowReaction 配置集将 kubelet 更新频率减少为 1 分钟,并将 Kubernetes Controller Manager 等待这些更新的时间更改为 5 分钟。该节点上的 pod 驱除周期会减少到 60 秒。如果 pod 具有 tolerationSeconds 参数,则驱除会等待该参数指定的周期。

Kubernetes Controller Manager 在认为节点不健康前会等待 5 分钟。另一分钟后,驱除过程会启动。

profile组件参数

LowUpdateSlowReaction

kubelet

node-status-update-frequency

1m

kubelet Controller Manager

node-monitor-grace-period

5m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

8.5.2. 使用和更改 worker 延迟配置集

要更改 worker 延迟配置集以处理网络延迟,请编辑 node.config 对象以添加配置集的名称。当延迟增加或减少时,您可以随时更改配置集。

您必须一次移动一个 worker 延迟配置集。例如,您无法直接从 Default 配置集移到 LowUpdateSlowReaction worker 延迟配置集。您必须首先从 Default worker 延迟配置集移到 MediumUpdateAverageReaction 配置集,然后再移到 LowUpdateSlowReaction。同样,当返回到 Default 配置集时,您必须首先从低配置集移到中配置集,然后移到 Default

注意

您还可以在安装 OpenShift Container Platform 集群时配置 worker 延迟配置集。

流程

将默认的 worker 延迟配置集改为:

  1. 中 worke worker 延迟配置集:

    1. 编辑 node.config 对象:

      $ oc edit nodes.config/cluster
    2. 添加 spec.workerLatencyProfile: MediumUpdateAverageReaction

      node.config 对象示例

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: MediumUpdateAverageReaction 1
      
      # ...

      1
      指定中 worker 延迟策略。

      随着更改被应用,每个 worker 节点上的调度都会被禁用。

  2. 可选:改为低 worker 延迟配置集:

    1. 编辑 node.config 对象:

      $ oc edit nodes.config/cluster
    2. spec.workerLatencyProfile 值更改为 LowUpdateSlowReaction

      node.config 对象示例

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: LowUpdateSlowReaction 1
      
      # ...

      1
      指定使用低 worker 延迟策略。

随着更改被应用,每个 worker 节点上的调度都会被禁用。

验证

  • 当所有节点都返回到 Ready 条件时,您可以使用以下命令查看 Kubernetes Controller Manager 以确保应用它:

    $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

    输出示例

    # ...
        - lastTransitionTime: "2022-07-11T19:47:10Z"
          reason: ProfileUpdated
          status: "False"
          type: WorkerLatencyProfileProgressing
        - lastTransitionTime: "2022-07-11T19:47:10Z" 1
          message: all static pod revision(s) have updated latency profile
          reason: ProfileUpdated
          status: "True"
          type: WorkerLatencyProfileComplete
        - lastTransitionTime: "2022-07-11T19:20:11Z"
          reason: AsExpected
          status: "False"
          type: WorkerLatencyProfileDegraded
        - lastTransitionTime: "2022-07-11T19:20:36Z"
          status: "False"
    # ...

    1
    指定配置集被应用并激活。

要将中配置集改为默认,或将默认改为中,编辑 node.config 对象,并将 spec.workerLatencyProfile 参数设置为适当的值。

8.6. 管理 control plane 机器

control plane 机器集 为 control plane 机器提供管理功能,与为计算机器提供的计算机器集类似。集群上的 control plane 机器集的可用性和初始状态取决于您的云供应商和您安装的 OpenShift Container Platform 版本。如需更多信息,请参阅开始使用 control plane 机器集

8.7. 为生产环境创建基础架构机器集

您可以创建一个计算机器集来创建仅托管基础架构组件的机器,如默认路由器、集成的容器镜像 registry 和组件用于集群指标和监控。这些基础架构机器不会被计算为运行环境所需的订阅总数。

在生产部署中,建议您部署至少三个计算机器集来容纳基础架构组件。OpenShift Logging 和 Red Hat OpenShift Service Mesh 部署 Elasticsearch,这需要三个实例安装到不同的节点上。这些节点都可以部署到不同的可用区以实现高可用性。类似的配置需要三个不同的计算机器集,每个可用区都有一个。在没有多个可用区的全局 Azure 区域,您可以使用可用性集来确保高可用性。

有关基础架构节点以及可在基础架构节点上运行的组件的详情,请参考 创建基础架构机器集

要创建基础架构节点,您可以使用机器集为节点分配标签,或使用机器配置池

有关可用于这些步骤的机器集示例,请参阅为不同的云创建机器集

将特定节点选择器应用到所有基础架构组件会导致 OpenShift Container Platform 使用 该标签将这些工作负载调度到具有该标签的节点

8.7.1. 创建计算机器集

除了安装程序创建的计算机器集外,您还可以创建自己的来动态管理您选择的特定工作负载的机器计算资源。

先决条件

  • 部署一个 OpenShift Container Platform 集群。
  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 权限的用户身份登录 oc

流程

  1. 创建一个包含计算机器集自定义资源(CR)示例的新 YAML 文件,并将其命名为 <file_name>.yaml

    确保设置 <clusterID><role> 参数值。

  2. 可选:如果您不确定要为特定字段设置哪个值,您可以从集群中检查现有计算机器集:

    1. 要列出集群中的计算机器集,请运行以下命令:

      $ oc get machinesets -n openshift-machine-api

      输出示例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
      agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1d   0         0                             55m
      agl030519-vplxk-worker-us-east-1e   0         0                             55m
      agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 要查看特定计算机器集自定义资源 (CR) 的值,请运行以下命令:

      $ oc get machineset <machineset_name> \
        -n openshift-machine-api -o yaml

      输出示例

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        labels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
        name: <infrastructure_id>-<role> 2
        namespace: openshift-machine-api
      spec:
        replicas: 1
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
        template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: <infrastructure_id>
              machine.openshift.io/cluster-api-machine-role: <role>
              machine.openshift.io/cluster-api-machine-type: <role>
              machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
          spec:
            providerSpec: 3
              ...

      1
      集群基础架构 ID。
      2
      默认节点标签。
      注意

      对于具有用户置备的基础架构的集群,计算机器集只能创建 workerinfra 类型机器。

      3
      计算机器设置 CR 的 <providerSpec> 部分中的值是特定于平台的。有关 CR 中的 <providerSpec> 参数的更多信息,请参阅您的供应商计算机器设置 CR 配置示例。
  3. 运行以下命令来创建 MachineSet CR:

    $ oc create -f <file_name>.yaml

验证

  • 运行以下命令,查看计算机器集列表:

    $ oc get machineset -n openshift-machine-api

    输出示例

    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
    agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
    agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1d   0         0                             55m
    agl030519-vplxk-worker-us-east-1e   0         0                             55m
    agl030519-vplxk-worker-us-east-1f   0         0                             55m

    当新的计算机器集可用时,DESIREDCURRENT 的值会匹配。如果 compute 机器集不可用,请等待几分钟,然后再次运行命令。

8.7.2. 创建基础架构节点

重要

请参阅为安装程序置备的基础架构环境创建基础架构机器集,或为其 control plane 节点由机器 API 管理的任何集群创建基础架构机器集。

集群的基础架构系统(也称为 infra 节点)的要求已被置备。安装程序只为 control plane 和 worker 节点提供置备。Worker 节点可以通过标记来指定为基础架构节点或应用程序(也称为 app )。

流程

  1. 向您要充当应用程序节点的 worker 节点添加标签:

    $ oc label node <node-name> node-role.kubernetes.io/app=""
  2. 向您要充当基础架构节点的 worker 节点添加标签:

    $ oc label node <node-name> node-role.kubernetes.io/infra=""
  3. 检查相关节点现在是否具有 infra 角色或 app 角色:

    $ oc get nodes
  4. 创建默认的集群范围节点选择器。默认节点选择器应用到在所有命名空间中创建的 pod。这会创建一个与 pod 上任何现有节点选择器交集的交集,这会额外限制 pod 的选择器。

    重要

    如果默认节点选择器键与 pod 标签的键冲突,则不会应用默认节点选择器。

    但是,不要设置可能会导致 pod 变得不可调度的默认节点选择器。例如,当 pod 的标签被设置为不同的节点角色(如 node-role.kubernetes.io/infra="")时,将默认节点选择器设置为特定的节点角色(如 node-role.kubernetes.io/master="")可能会导致 pod 无法调度。因此,将默认节点选择器设置为特定节点角色时要小心。

    您还可以使用项目节点选择器来避免集群范围节点选择器键冲突。

    1. 编辑 Scheduler 对象:

      $ oc edit scheduler cluster
    2. 使用适当的节点选择器添加 defaultNodeSelector 字段:

      apiVersion: config.openshift.io/v1
      kind: Scheduler
      metadata:
        name: cluster
      spec:
        defaultNodeSelector: node-role.kubernetes.io/infra="" 1
      # ...
      1
      这个示例节点选择器默认在基础架构节点上部署 pod。
    3. 保存文件以使改变生效。

现在,您可以将基础架构资源移到新标记的 infra 节点。

其他资源

  • 有关如何配置项目节点选择器以避免集群范围节点选择器冲突的详情,请参考 项目节点选择器

8.7.3. 为基础架构机器创建机器配置池

如果需要基础架构机器具有专用配置,则必须创建一个 infra 池。

重要

在创建一个默认自定义集群配置池时,如果它们引用同一文件或单元,则创建的自定义机器配置池会覆盖默认的 worker 池配置。

流程

  1. 向您要分配为带有特定标签的 infra 节点的节点添加标签:

    $ oc label node <node_name> <label>
    $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=
  2. 创建包含 worker 角色和自定义角色作为机器配置选择器的机器配置池:

    $ cat infra.mcp.yaml

    输出示例

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: infra
    spec:
      machineConfigSelector:
        matchExpressions:
          - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]} 1
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/infra: "" 2

    1
    添加 worker 角色和自定义角色。
    2
    将您添加的标签作为 nodeSelector 添加到节点。
    注意

    自定义机器配置池从 worker 池中继承机器配置。自定义池使用任何针对 worker 池的机器配置,但增加了部署仅针对自定义池的更改的功能。由于自定义池从 worker 池中继承资源,对 worker 池的任何更改也会影响自定义池。

  3. 具有 YAML 文件后,您可以创建机器配置池:

    $ oc create -f infra.mcp.yaml
  4. 检查机器配置,以确保基础架构配置成功:

    $ oc get machineconfig

    输出示例

    NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
    00-master                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
    00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
    01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
    01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
    01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
    01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
    99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
    99-master-ssh                                                                                          3.2.0             31d
    99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
    99-worker-ssh                                                                                          3.2.0             31d
    rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             23m
    rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
    rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
    rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
    rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d
    rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
    rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
    rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
    rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
    rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
    rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
    rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
    rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d

    您应该会看到一个新的机器配置,带有 rendered-infra-* 前缀。

  5. 可选:要部署对自定义池的更改,请创建一个机器配置,该配置使用自定义池名称作为标签,如本例中的 infra。请注意,这不是必须的,在此包括仅用于指示目的。这样,您可以只应用特定于 infra 节点的任何自定义配置。

    注意

    创建新机器配置池后,MCO 会为该池生成一个新的呈现配置,以及该池重启的关联节点以应用新配置。

    1. 创建机器配置:

      $ cat infra.mc.yaml

      输出示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        name: 51-infra
        labels:
          machineconfiguration.openshift.io/role: infra 1
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            files:
            - path: /etc/infratest
              mode: 0644
              contents:
                source: data:,infra

      1
      将您添加的标签作为 nodeSelector 添加到节点。
    2. 将机器配置应用到 infra-labeled 节点:

      $ oc create -f infra.mc.yaml
  6. 确认您的新机器配置池可用:

    $ oc get mcp

    输出示例

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    infra    rendered-infra-60e35c2e99f42d976e084fa94da4d0fc    True      False      False      1              1                   1                     0                      4m20s
    master   rendered-master-9360fdb895d4c131c7c4bebbae099c90   True      False      False      3              3                   3                     0                      91m
    worker   rendered-worker-60e35c2e99f42d976e084fa94da4d0fc   True      False      False      2              2                   2                     0                      91m

    在本例中,worker 节点被改为一个 infra 节点。

其他资源

8.8. 为基础架构节点分配机器设置资源

在创建了基础架构机器集后,workerinfra 角色将应用到新的 infra 节点。具有 infra 角色的节点不会计入运行环境所需的订阅总数中,即使也应用了 worker 角色。

但是,当为 infra 节点分配 worker 角色时,用户工作负载可能会意外地分配给 infra 节点。要避免这种情况,您可以将污点应用到 infra 节点,并为您要控制的 pod 应用容限。

8.8.1. 使用污点和容限绑定基础架构节点工作负载

如果您有一个分配了 infraworker 角色的 infra 节点,您必须配置该节点,以便不为其分配用户工作负载。

重要

建议您保留为 infra 节点创建的双 infra,worker 标签,并使用污点和容限来管理用户工作负载调度到的节点。如果从节点中删除 worker 标签,您必须创建一个自定义池来管理它。没有自定义池的 MCO 不能识别具有 masterworker 以外的标签的节点。如果不存在选择自定义标签的自定义池,维护 worker 标签可允许默认 worker 机器配置池管理节点。infra 标签与集群通信,它不计算订阅总数。

先决条件

  • 在 OpenShift Container Platform 集群中配置额外的 MachineSet 对象。

流程

  1. 向 infra 节点添加污点以防止在其上调度用户工作负载:

    1. 确定节点是否具有污点:

      $ oc describe nodes <node_name>

      输出示例

      oc describe node ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Name:               ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Roles:              worker
       ...
      Taints:             node-role.kubernetes.io/infra:NoSchedule
       ...

      本例显示节点具有污点。您可以在下一步中继续向 pod 添加容限。

    2. 如果您还没有配置污点以防止在其上调度用户工作负载:

      $ oc adm taint nodes <node_name> <key>=<value>:<effect>

      例如:

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoSchedule
      提示

      您还可以应用以下 YAML 来添加污点:

      kind: Node
      apiVersion: v1
      metadata:
        name: <node_name>
        labels:
          ...
      spec:
        taints:
          - key: node-role.kubernetes.io/infra
            effect: NoSchedule
            value: reserved
        ...

      本例在 node1 上放置一个键为 node-role.kubernetes.io/infra 的污点,污点是 NoSchedule。具有 NoSchedule effect 的节点仅调度容许该污点的 pod,但允许现有 pod 继续调度到该节点上。

      注意

      如果使用 descheduler,则违反了节点污点的 pod 可能会从集群驱除。

    3. 添加带有 NoExecute Effect 的污点,以及上述带有 NoSchedule Effect 的污点:

      $ oc adm taint nodes <node_name> <key>=<value>:<effect>

      例如:

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoExecute
      提示

      您还可以应用以下 YAML 来添加污点:

      kind: Node
      apiVersion: v1
      metadata:
        name: <node_name>
        labels:
          ...
      spec:
        taints:
          - key: node-role.kubernetes.io/infra
            effect: NoExecute
            value: reserved
        ...

      本例在 node1 上放置一个键为 node-role.kubernetes.io/infra 的污点,污点是 NoExecute。带有 NoExecute 效果的节点仅调度容许该污点的 pod。该效果将从没有匹配容限的节点中删除任何现有 pod。

  2. 为要在 infra 节点上调度的 pod 配置添加容限,如路由器、registry 和监控工作负载。在 Pod 对象规格中添加以下代码:

    tolerations:
      - effect: NoSchedule 1
        key: node-role.kubernetes.io/infra 2
        value: reserved 3
      - effect: NoExecute 4
        key: node-role.kubernetes.io/infra 5
        operator: Exists 6
        value: reserved 7
    1
    指定添加到节点的效果。
    2
    指定添加到节点的键。
    3
    指定添加到节点的键值对污点的值。
    4
    指定添加到节点的效果。
    5
    指定添加到节点的键。
    6
    指定 Exists Operator,以要求节点上存在一个带有键为 node-role.kubernetes.io/infra 的污点。
    7
    指定添加到节点的键值对污点的值。

    此容忍度与 oc adm taint 命令创建的污点匹配。具有此容忍度的 pod 可以调度到 infra 节点上。

    注意

    并不总是能够将通过 OLM 安装的 Operator 的 Pod 移到 infra 节点。移动 Operator Pod 的能力取决于每个 Operator 的配置。

  3. 使用调度程序将 pod 调度到 infra 节点。详情请参阅控制节点上的 pod 放置的文档。

8.9. 将资源移到基础架构机器集

默认情况下,您的集群中已部署了某些基础架构资源。您可将它们移至您创建的基础架构机器集。

8.9.1. 移动路由器

您可以将路由器 Pod 部署到不同的计算机器集中。默认情况下,pod 部署到 worker 节点。

先决条件

  • 在 OpenShift Container Platform 集群中配置额外的计算机器集。

流程

  1. 查看路由器 Operator 的 IngressController 自定义资源:

    $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

    命令输出类似于以下文本:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: 2019-04-18T12:35:39Z
      finalizers:
      - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
      generation: 1
      name: default
      namespace: openshift-ingress-operator
      resourceVersion: "11341"
      selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a
    spec: {}
    status:
      availableReplicas: 2
      conditions:
      - lastTransitionTime: 2019-04-18T12:36:15Z
        status: "True"
        type: Available
      domain: apps.<cluster>.example.com
      endpointPublishingStrategy:
        type: LoadBalancerService
      selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default
  2. 编辑 ingresscontroller 资源,并更改 nodeSelector 以使用infra 标签:

    $ oc edit ingresscontroller default -n openshift-ingress-operator
      spec:
        nodePlacement:
          nodeSelector: 1
            matchLabels:
              node-role.kubernetes.io/infra: ""
          tolerations:
          - effect: NoSchedule
            key: node-role.kubernetes.io/infra
            value: reserved
          - effect: NoExecute
            key: node-role.kubernetes.io/infra
            value: reserved
    1
    添加 nodeSelector 参数,并设为适用于您想要移动的组件的值。您可以根据为节点指定的值,按所示格式使用 nodeSelector 或使用 <key>: <value> 对。如果您在 infrasructure 节点中添加了污点,还要添加匹配的容限。
  3. 确认路由器 Pod 在 infra 节点上运行。

    1. 查看路由器 Pod 列表,并记下正在运行的 Pod 的节点名称:

      $ oc get pod -n openshift-ingress -o wide

      输出示例

      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      在本例中,正在运行的 Pod 位于 ip-10-0-217-226.ec2.internal 节点上。

    2. 查看正在运行的 Pod 的节点状态:

      $ oc get node <node_name> 1
      1
      指定从 Pod 列表获得的 <node_name>

      输出示例

      NAME                          STATUS  ROLES         AGE   VERSION
      ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.28.5

      由于角色列表包含 infra,因此 Pod 在正确的节点上运行。

8.9.2. 移动默认 registry

您需要配置 registry Operator,以便将其 Pod 部署到其他节点。

先决条件

  • 在 OpenShift Container Platform 集群中配置额外的计算机器集。

流程

  1. 查看 config/instance 对象:

    $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

    输出示例

    apiVersion: imageregistry.operator.openshift.io/v1
    kind: Config
    metadata:
      creationTimestamp: 2019-02-05T13:52:05Z
      finalizers:
      - imageregistry.operator.openshift.io/finalizer
      generation: 1
      name: cluster
      resourceVersion: "56174"
      selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
      uid: 36fd3724-294d-11e9-a524-12ffeee2931b
    spec:
      httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
      logging: 2
      managementState: Managed
      proxy: {}
      replicas: 1
      requests:
        read: {}
        write: {}
      storage:
        s3:
          bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
          region: us-east-1
    status:
    ...

  2. 编辑 config/instance 对象:

    $ oc edit configs.imageregistry.operator.openshift.io/cluster
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              namespaces:
              - openshift-image-registry
              topologyKey: kubernetes.io/hostname
            weight: 100
      logLevel: Normal
      managementState: Managed
      nodeSelector: 1
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    1
    添加 nodeSelector 参数,并设为适用于您想要移动的组件的值。您可以根据为节点指定的值,按所示格式使用 nodeSelector 或使用 <key>: <value> 对。如果您在 infrasructure 节点中添加了污点,还要添加匹配的容限。
  3. 验证 registry pod 已移至基础架构节点。

    1. 运行以下命令,以识别 registry pod 所在的节点:

      $ oc get pods -o wide -n openshift-image-registry
    2. 确认节点具有您指定的标签:

      $ oc describe node <node_name>

      查看命令输出,并确认 node-role.kubernetes.io/infra 列在 LABELS 列表中。

8.9.3. 移动监控解决方案

监控堆栈包含多个组件,包括 Prometheus、Thanos Querier 和 Alertmanager。Cluster Monitoring Operator 管理此堆栈。要将监控堆栈重新部署到基础架构节点,您可以创建并应用自定义配置映射。

流程

  1. 编辑 cluster-monitoring-config 配置映射,并更改 nodeSelector 以使用 infra 标签:

    $ oc edit configmap cluster-monitoring-config -n openshift-monitoring
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |+
        alertmanagerMain:
          nodeSelector: 1
            node-role.kubernetes.io/infra: ""
          tolerations:
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoSchedule
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoExecute
        prometheusK8s:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          tolerations:
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoSchedule
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoExecute
        prometheusOperator:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          tolerations:
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoSchedule
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoExecute
        k8sPrometheusAdapter:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          tolerations:
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoSchedule
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoExecute
        kubeStateMetrics:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          tolerations:
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoSchedule
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoExecute
        telemeterClient:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          tolerations:
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoSchedule
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoExecute
        openshiftStateMetrics:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          tolerations:
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoSchedule
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoExecute
        thanosQuerier:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          tolerations:
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoSchedule
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoExecute
        monitoringPlugin:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          tolerations:
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoSchedule
          - key: node-role.kubernetes.io/infra
            value: reserved
            effect: NoExecute
    1
    添加 nodeSelector 参数,并设为适用于您想要移动的组件的值。您可以根据为节点指定的值,按所示格式使用 nodeSelector 或使用 <key>: <value> 对。如果您在 infrasructure 节点中添加了污点,还要添加匹配的容限。
  2. 观察监控 pod 移至新机器:

    $ watch 'oc get pod -n openshift-monitoring -o wide'
  3. 如果组件没有移到 infra 节点,请删除带有这个组件的 pod:

    $ oc delete pod -n openshift-monitoring <pod>

    已删除 pod 的组件在 infra 节点上重新创建。

8.9.4. 移动日志记录资源

有关移动日志记录资源的详情,请参考:

8.10. 关于集群自动扩展

集群自动扩展会调整 OpenShift Container Platform 集群的大小,以满足其当前的部署需求。它使用 Kubernetes 样式的声明性参数来提供基础架构管理,而且这种管理不依赖于特定云提供商的对象。集群自动控制会在集群范围内有效,不与特定的命名空间相关联。

当由于资源不足而无法在任何当前 worker 节点上调度 pod 时,或者在需要另一个节点来满足部署需求时,集群自动扩展会增加集群的大小。集群自动扩展不会将集群资源增加到超过您指定的限制。

集群自动扩展会计算集群中所有节点上的内存、CPU 和 GPU,即使它不管理 control plane 节点。这些值不是单计算机导向型。它们是整个集群中所有资源的聚合。例如,如果您设置最大内存资源限制,集群自动扩展在计算当前内存用量时包括集群中的所有节点。然后,该计算用于确定集群自动扩展是否具有添加更多 worker 资源的容量。

重要

确保您所创建的 ClusterAutoscaler 资源定义中的 maxNodesTotal 值足够大,足以满足计算集群中可能的机器总数。此值必须包含 control plane 机器的数量以及可扩展至的机器数量。

每隔 10 秒,集群自动扩展会检查集群中不需要哪些节点,并移除它们。如果满足以下条件,集群自动扩展会考虑要删除的节点:

  • 节点使用率低于集群的节点 利用率级别 阈值。节点使用率级别是请求的资源的总和,由分配给节点的资源划分。如果您没有在 ClusterAutoscaler 自定义资源中指定值,集群自动扩展会使用默认值 0.5,它对应于 50% 的利用率。
  • 集群自动扩展可以将节点上运行的所有 pod 移到其他节点。Kubernetes 调度程序负责在节点上调度 pod。
  • 集群自动扩展没有缩减禁用注解。

如果节点上存在以下类型的 pod,集群自动扩展不会删除该节点:

  • 具有限制性 pod 中断预算(PDB)的 Pod。
  • 默认不在节点上运行的 Kube 系统 Pod。
  • 没有 PDB 或 PDB 限制性太强的 Kube 系统 pod。
  • 不受控制器对象支持的 Pod,如部署、副本集或有状态集。
  • 具有本地存储的 Pod。
  • 因为缺乏资源、节点选择器或关联性不兼容或有匹配的反关联性等原因而无法移至其他位置的 Pod。
  • 具有 "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" 注解的 Pod,除非同时也具有 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true” 注解。

例如,您可以将最大 CPU 限值设置为 64 个内核,并将集群自动扩展配置为每个创建具有 8 个内核的机器。如果您的集群从 30 个内核开始,集群自动扩展可最多添加具有 32 个内核的 4 个节点,共 62 个。

如果配置集群自动扩展,则需要额外的使用限制:

  • 不要直接修改位于自动扩展节点组中的节点。同一节点组中的所有节点具有相同的容量和标签,并且运行相同的系统 Pod。
  • 指定适合您的 Pod 的请求。
  • 如果需要防止 Pod 被过快删除,请配置适当的 PDB。
  • 确认您的云提供商配额足够大,能够支持您配置的最大节点池。
  • 不要运行其他节点组自动扩展器,特别是云提供商提供的自动扩展器。

pod 横向自动扩展(HPA)和集群自动扩展以不同的方式修改集群资源。HPA 根据当前的 CPU 负载更改部署或副本集的副本数。如果负载增加,HPA 会创建新的副本,不论集群可用的资源量如何。如果没有足够的资源,集群自动扩展会添加资源,以便 HPA 创建的 pod 可以运行。如果负载减少,HPA 会停止一些副本。如果此操作导致某些节点利用率低下或完全为空,集群自动扩展会删除不必要的节点。

集群自动扩展会考虑 pod 优先级。如果集群没有足够的资源,则“Pod 优先级和抢占”功能可根据优先级调度 Pod,但集群自动扩展会确保集群具有运行所有 Pod 需要的资源。为满足这两个功能,集群自动扩展包含一个优先级截止函数。您可以使用此截止函数来调度“尽力而为”的 Pod,它们不会使集群自动扩展增加资源,而是仅在有可用备用资源时运行。

优先级低于截止值的 Pod 不会导致集群扩展或阻止集群缩减。系统不会添加新节点来运行 Pod,并且可能会删除运行这些 Pod 的节点来释放资源。

集群自动扩展支持在其上有机器 API 的平台。

8.10.1. 集群自动扩展资源定义

ClusterAutoscaler 资源定义显示了集群自动扩展的参数和示例值。

apiVersion: "autoscaling.openshift.io/v1"
kind: "ClusterAutoscaler"
metadata:
  name: "default"
spec:
  podPriorityThreshold: -10 1
  resourceLimits:
    maxNodesTotal: 24 2
    cores:
      min: 8 3
      max: 128 4
    memory:
      min: 4 5
      max: 256 6
    gpus:
      - type: nvidia.com/gpu 7
        min: 0 8
        max: 16 9
      - type: amd.com/gpu
        min: 0
        max: 4
  logVerbosity: 4 10
  scaleDown: 11
    enabled: true 12
    delayAfterAdd: 10m 13
    delayAfterDelete: 5m 14
    delayAfterFailure: 30s 15
    unneededTime: 5m 16
    utilizationThreshold: "0.4" 17
1
指定 Pod 必须超过哪一优先级才能让机器自动扩展部署更多节点。输入一个 32 位整数值。podPriorityThreshold 值将与您分配给每个 Pod 的 PriorityClass 值进行比较。
2
指定要部署的最大节点数。这个值是集群中部署的机器总数,而不仅仅是自动扩展器控制的机器。确保这个值足够大,足以满足所有 control plane 和计算机器以及您在 MachineAutoscaler 资源中指定的副本总数。
3
指定在集群中部署的最小内核数。
4
指定集群中要部署的最大内核数。
5
指定集群中最小内存量(以 GiB 为单位)。
6
指定集群中的最大内存量(以 GiB 为单位)。
7
可选:指定要部署的 GPU 节点的类型。只有 nvidia.com/gpuamd.com/gpu 是有效的类型。
8
指定在集群中部署的最小 GPU 数。
9
指定集群中要部署的最大 GPU 数量。
10
指定 010 之间的日志记录详细程度。为指导提供了以下日志级别阈值:
  • 1:(默认)有关更改的基本信息。
  • 4 :用于对典型问题进行故障排除的详细程度。
  • 9 :广泛的、协议级的故障排除信息。

如果没有指定值,则使用默认值 1

11
在此部分中,您可以指定每个操作要等待的时长,可以使用任何有效的 ParseDuration 间隔,包括 nsusmssmh
12
指定集群自动扩展是否可以删除不必要的节点。
13
可选:指定在最近添加节点之后要等待多久才能删除节点。如果不指定值,则使用默认值 10m
14
可选:指定在最近删除节点之后要等待多久才能删除节点。如果没有指定值,则使用默认值 0s
15
可选:指定在发生缩减失败之后要等待多久才能删除节点。如果不指定值,则使用默认值 3m
16
可选:指定不必要的节点有资格删除前的时间。如果不指定值,则使用默认值 10m
17
可选:指定 节点使用率级别。此使用率级别下的节点可以被删除。

节点使用率是请求的资源的总和(由节点分配的资源划分),且值必须大于 "0",但小于 "1"。如果没有指定值,集群自动扩展会使用默认值 "0.5",它对应于 50% 的使用率。您必须以字符串形式表示这个值。

注意

执行扩展操作时,集群自动扩展会保持在 ClusterAutoscaler 资源定义中设置的范围,如要部署的最小和最大内核数,或集群中的内存量。但是,集群自动扩展无法将集群中的当前值修正为在这些范围内。

最小和最大 CPU、内存和 GPU 值是通过计算集群中所有节点上的这些资源来确定,即使集群自动扩展无法管理该节点。例如,control plane 节点在集群的总内存中考虑,即使集群自动扩展不管理 control plane 节点。

8.10.2. 部署集群自动扩展

要部署集群自动扩展,请创建一个 ClusterAutoscaler 资源实例。

流程

  1. 为包含自定义资源定义的 ClusterAutoscaler 资源创建一个 YAML 文件。
  2. 运行以下命令在集群中创建自定义资源:

    $ oc create -f <filename>.yaml 1
    1
    <filename> 是自定义资源文件的名称。

8.11. 关于机器自动扩展

机器自动扩展会调整您在 OpenShift Container Platform 集群中部署的计算机器集中的机器数量。您可以扩展默认 worker 计算机器集,以及您创建的任何其他计算机器集。当集群没有足够资源来支持更多部署时,机器自动扩展会增加 Machine。对 MachineAutoscaler 资源中的值(如最小或最大实例数量)的任何更改都会立即应用到目标计算机器设置。

重要

您必须部署机器自动扩展才能使用集群自动扩展功能来扩展机器。集群自动扩展使用机器自动扩展集上的注解来确定可扩展的资源。如果您在没有定义机器自动扩展的情况下定义集群自动扩展,集群自动扩展永远不会扩展集群。

8.11.1. 机器自动扩展资源定义

MachineAutoscaler 资源定义显示了机器自动扩展器的参数和示例值。

apiVersion: "autoscaling.openshift.io/v1beta1"
kind: "MachineAutoscaler"
metadata:
  name: "worker-us-east-1a" 1
  namespace: "openshift-machine-api"
spec:
  minReplicas: 1 2
  maxReplicas: 12 3
  scaleTargetRef: 4
    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet 5
    name: worker-us-east-1a 6
1
指定机器自动扩展名称。为了更容易识别此机器自动扩展会扩展哪些计算机器,请指定或包含要扩展的计算机器设置的名称。计算机器集名称采用以下形式: <clusterid>-<machineset>-<region>
2
指定在机器自动扩展启动集群扩展后必须保留在指定区域中的指定类型的最小机器数量。如果在 AWS、GCP、Azure、RHOSP 或 vSphere 中运行,则此值可设为 0。对于其他供应商,请不要将此值设置为 0

对于用于特殊工作负载的高价或有限使用硬件,或者扩展具有额外大型机器的计算机器集,您可以将此值设置为 0 来节约成本。如果机器没有使用,集群自动扩展会将计算机器设置缩减为零。

重要

对于安装程序置备的基础架构,请不要将 OpenShift Container Platform 安装过程中创建的三台计算机器集的 spec.minReplicas 值设置为 0

3
指定集群自动扩展初始化集群扩展后可在指定类型区域中部署的指定类型的最大机器数量。确保 ClusterAutoscaler 资源定义的 maxNodesTotal 值足够大,以便机器自动扩展器可以部署这个数量的机器。
4
在本小节中,提供描述要扩展的现有计算机器设置的值。
5
kind 参数值始终为 MachineSet
6
name 值必须与现有计算机器集的名称匹配,如 metadata.name 参数值中所示。

8.11.2. 部署机器自动扩展

要部署机器自动扩展,请创建一个 MachineAutoscaler 资源实例。

流程

  1. MachineAutoscaler 资源创建一个 YAML 文件,其中包含自定义资源定义。
  2. 运行以下命令在集群中创建自定义资源:

    $ oc create -f <filename>.yaml 1
    1
    <filename> 是自定义资源文件的名称。

8.12. 配置 Linux cgroup

自 OpenShift Container Platform 4.14 起,OpenShift Container Platform 在集群中使用 Linux 控制组版本 2 (cgroup v2)。如果您在 OpenShift Container Platform 4.13 或更早版本中使用 cgroup v1,迁移到 OpenShift Container Platform 4.14 或更高版本不会自动将 cgroup 配置更新至版本 2。全新安装 OpenShift Container Platform 4.14 或更高版本默认使用 cgroup v2。但是,您可以在安装时启用 Linux 控制组群版本 1 (cgroup v1)。

cgroup v2 是 Linux cgroup API 的当前版本。cgroup v2 比 cgroup v1 提供多种改进,包括统一层次结构、更安全的子树委派、新功能,如 Pressure Stall Information,以及增强的资源管理和隔离。但是,cgroup v2 与 cgroup v1 具有不同的 CPU、内存和 I/O 管理特征。因此,在运行 cgroup v2 的集群上,一些工作负载可能会遇到内存或 CPU 用量差异。

您可以根据需要在 cgroup v1 和 cgroup v2 之间更改。在 OpenShift Container Platform 中启用 cgroup v1 禁用集群中的所有 cgroup v2 控制器和层次结构。

注意

目前,cgroup v2 不支持禁用 CPU 负载均衡。因此,如果您启用了 cgroup v2,则可能无法从性能配置集中获取所需的行为。如果您使用 executeace 配置集,则不建议启用 cgroup v2。

先决条件

  • 您有一个正在运行的 OpenShift Container Platform 集群,它使用版本 4.12 或更高版本。
  • 以具有管理特权的用户身份登录集群。

流程

  1. 在节点上启用 cgroup v1:

    1. 编辑 node.config 对象:

      $ oc edit nodes.config/cluster
    2. 添加 spec.cgroupMode: "v1":

      node.config 对象示例

      apiVersion: config.openshift.io/v2
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v2
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        cgroupMode: "v1" 1
      ...

      1
      启用 cgroup v1。

验证

  1. 检查机器配置以查看是否添加了新的机器配置:

    $ oc get mc

    输出示例

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    97-master-generated-kubelet                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-worker-generated-kubelet                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-ssh                                                                                 3.2.0             40m
    99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-worker-ssh                                                                                 3.2.0             40m
    rendered-master-23d4317815a5f854bd3553d689cfe2e9   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             10s 1
    rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    rendered-worker-dcc7f1b92892d34db74d6832bcc9ccd4   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             10s

    1
    创建新机器配置,如预期一样。
  2. 检查新的 kernelArguments 是否已添加到新机器配置中:

    $ oc describe mc <name>

    cgroup v1 的输出示例

    apiVersion: machineconfiguration.openshift.io/v2
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 05-worker-kernelarg-selinuxpermissive
    spec:
      kernelArguments:
        systemd.unified_cgroup_hierarchy=0 1
        systemd.legacy_systemd_cgroup_controller=1 2

    1
    禁用 cgroup v2。
    2
    在 systemd 中启用 cgroup v1。
  3. 检查节点以查看是否禁用了在节点上调度。这表示要应用更改:

    $ oc get nodes

    输出示例

    NAME                                       STATUS                     ROLES    AGE   VERSION
    ci-ln-fm1qnwt-72292-99kt6-master-0         Ready,SchedulingDisabled   master   58m   v1.28.5
    ci-ln-fm1qnwt-72292-99kt6-master-1         Ready                      master   58m   v1.28.5
    ci-ln-fm1qnwt-72292-99kt6-master-2         Ready                      master   58m   v1.28.5
    ci-ln-fm1qnwt-72292-99kt6-worker-a-h5gt4   Ready,SchedulingDisabled   worker   48m   v1.28.5
    ci-ln-fm1qnwt-72292-99kt6-worker-b-7vtmd   Ready                      worker   48m   v1.28.5
    ci-ln-fm1qnwt-72292-99kt6-worker-c-rhzkv   Ready                      worker   48m   v1.28.5

  4. 节点返回 Ready 状态后,为该节点启动 debug 会话:

    $ oc debug node/<node_name>
  5. /host 设置为 debug shell 中的根目录:

    sh-4.4# chroot /host
  6. 检查您的节点上是否存在 sys/fs/cgroup/cgroup2fs 文件。此文件由 cgroup v1 创建:

    $ stat -c %T -f /sys/fs/cgroup

    输出示例

    cgroup2fs

8.13. 使用 FeatureGate 启用技术预览功能

您可以通过编辑 FeatureGate 自定义资源(CR)为集群中的所有节点开启当前技术预览功能的子集。

8.13.1. 了解功能门

您可以使用 FeatureGate 自定义资源(CR)在集群中启用特定的功能集。功能集是 OpenShift Container Platform 功能的集合,默认情况下不启用。

您可以使用 FeatureGate CR 激活以下功能集:

  • TechPreviewNoUpgrade.这个功能集是当前技术预览功能的子集。此功能集允许您在测试集群中启用这些技术预览功能,您可以在测试集群中完全测试它们,同时保留生产集群中禁用的功能。

    警告

    在集群中启用 TechPreviewNoUpgrade 功能集无法撤消,并会阻止次版本更新。您不应该在生产环境集群中启用此功能。

    此功能集启用了以下技术预览功能:

    • 外部云供应商。为 vSphere、AWS、Azure 和 GCP 上的集群启用外部云供应商的支持。对 OpenStack 的支持是 GA。这是一个内部功能,大多数用户不需要与之交互。(ExternalCloudProvider)
    • OpenShift 构建中的共享资源 CSI 驱动程序。启用 Container Storage Interface (CSI)。(CSIDriverSharedResource)
    • 节点上的交换内存。根据每个节点为 OpenShift Container Platform 工作负载启用交换内存使用。(NodeSwap)
    • OpenStack Machine API 提供程序。此最低要求无效,计划在以后的发行版本中从此功能集中删除。(MachineAPIProviderOpenStack)
    • Insights Operator。启用 InsightsDataGather CRD,允许用户配置一些 Insights 数据收集选项。功能集还启用了 DataGather CRD,允许用户按需运行 Insights 数据收集。(InsightsConfigAPI)
    • 递归默认存储类.如果 PVC 创建时没有默认存储类(RetroactiveDefaultStorageClass) 启用 OpenShift Container Platform 会主动地将默认存储类分配给 PVC。
    • 动态资源分配 API。启用一个新的 API 在 pod 和容器间请求和共享资源。这是一个内部功能,大多数用户不需要与之交互。(DynamicResourceAllocation)
    • Pod 安全准入强制。为 pod 安全准入启用受限强制模式。如果 pod 违反了 pod 安全标准,它们会被拒绝,而不是仅记录警告信息。(OpenShiftPodSecurityAdmission)
    • StatefulSet pod 可用性升级限制。允许用户定义在更新过程中不可用的 statefulset pod 的最大数量,这可以减少应用程序停机时间。(MaxUnavailableStatefulSet)
    • Admin Network 策略和 Baseline Admin Network 策略。在运行 OVN-Kubernetes CNI 插件的集群中,启用 AdminNetworkPolicyBaselineAdminNetworkPolicy 资源,它们是 Network Policy V2 API 的一部分。集群管理员可以在创建命名空间前为整个集群应用集群范围的策略和保护。网络管理员可以通过强制无法覆盖的网络流量控制来保护集群。如果需要,网络管理员可以实施可选的基准网络流量控制,这些流量可以被集群中的用户覆盖。目前,这些 API 仅支持集群内流量的策略。(AdminNetworkPolicy)
    • MatchConditions 是一个必须满足的条件列表,只要在满足这些条件时才向此 webhook 发送请求。匹配条件过滤请求,它们已与 rules、namespaceSelector 和 objectSelector 匹配。一个空的 matchConditions 列表,匹配所有请求。(admissionWebhookMatchConditions)
    • 网关 API.要启用 OpenShift Container Platform Gateway API,在 ServiceMeshControlPlane 资源的 techPreview.gatewayAPI 规格中将 enabled 字段的值设置为 true。(gateGatewayAPI)
    • gcpLabelsTags
    • vSphereStaticIPs
    • routeExternalCertificate
    • automatedEtcdBackup
    • gcpClusterHostedDNS
    • vSphereControlPlaneMachineset
    • dnsNameResolver
    • machineConfigNodes
    • metricsServer
    • installAlternateInfrastructureAWS
    • sdnLiveMigration
    • mixedCPUsAllocation
    • managedBootImages
    • onClusterBuild
    • signatureStores

8.13.2. 使用 Web 控制台启用功能集

您可以通过编辑 FeatureGate 自定义资源(CR)来使用 OpenShift Container Platform Web 控制台为集群中的所有节点启用功能集。

流程

启用功能集:

  1. 在 OpenShift Container Platform web 控制台中,切换到 AdministrationCustom Resource Definitions 页面。
  2. Custom Resource Definitions 页面中,点击 FeatureGate
  3. Custom Resource Definition Details 页面中,点 Instances 选项卡。
  4. 集群 功能门,然后点 YAML 选项卡。
  5. 编辑集群实例以添加特定的功能集:

    警告

    在集群中启用 TechPreviewNoUpgrade 功能集无法撤消,并会阻止次版本更新。您不应该在生产环境集群中启用此功能。

    功能门自定义资源示例

    apiVersion: config.openshift.io/v1
    kind: FeatureGate
    metadata:
      name: cluster 1
    # ...
    spec:
      featureSet: TechPreviewNoUpgrade 2

    1
    FeatureGate CR 的名称必须是 cluster
    2
    添加要启用的功能集:
    • TechPreviewNoUpgrade 启用了特定的技术预览功能。

    保存更改后,会创建新的机器配置,然后更新机器配置池,并在应用更改时在每个节点上调度。

验证

您可以在节点返回就绪状态后查看节点上的 kubelet.conf 文件来验证是否启用了功能门。

  1. 从 Web 控制台中的 Administrator 视角,进入到 ComputeNodes
  2. 选择一个节点。
  3. Node 详情页面中,点 Terminal
  4. 在终端窗口中,将根目录改为 /host

    sh-4.2# chroot /host
  5. 查看 kubelet.conf 文件:

    sh-4.2# cat /etc/kubernetes/kubelet.conf

    输出示例

    # ...
    featureGates:
      InsightsOperatorPullingSCA: true,
      LegacyNodeRoleBehavior: false
    # ...

    在集群中启用列为 true 的功能。

    注意

    列出的功能因 OpenShift Container Platform 版本的不同而有所不同。

8.13.3. 使用 CLI 启用功能集

您可以通过编辑 FeatureGate 自定义资源(CR)来使用 OpenShift CLI(oc)为集群中的所有节点启用功能集。

先决条件

  • 已安装 OpenShift CLI(oc)。

流程

启用功能集:

  1. 编辑名为 clusterFeatureGate CR:

    $ oc edit featuregate cluster
    警告

    在集群中启用 TechPreviewNoUpgrade 功能集无法撤消,并会阻止次版本更新。您不应该在生产环境集群中启用此功能。

    FeatureGate 自定义资源示例

    apiVersion: config.openshift.io/v1
    kind: FeatureGate
    metadata:
      name: cluster 1
    # ...
    spec:
      featureSet: TechPreviewNoUpgrade 2

    1
    FeatureGate CR 的名称必须是 cluster
    2
    添加要启用的功能集:
    • TechPreviewNoUpgrade 启用了特定的技术预览功能。

    保存更改后,会创建新的机器配置,然后更新机器配置池,并在应用更改时在每个节点上调度。

验证

您可以在节点返回就绪状态后查看节点上的 kubelet.conf 文件来验证是否启用了功能门。

  1. 从 Web 控制台中的 Administrator 视角,进入到 ComputeNodes
  2. 选择一个节点。
  3. Node 详情页面中,点 Terminal
  4. 在终端窗口中,将根目录改为 /host

    sh-4.2# chroot /host
  5. 查看 kubelet.conf 文件:

    sh-4.2# cat /etc/kubernetes/kubelet.conf

    输出示例

    # ...
    featureGates:
      InsightsOperatorPullingSCA: true,
      LegacyNodeRoleBehavior: false
    # ...

    在集群中启用列为 true 的功能。

    注意

    列出的功能因 OpenShift Container Platform 版本的不同而有所不同。

8.14. etcd 任务

备份 etcd、启用或禁用 etcd 加密或清除 etcd 数据。

8.14.1. 关于 etcd 加密

默认情况下,OpenShift Container Platform 不加密 etcd 数据。在集群中启用对 etcd 进行加密的功能可为数据的安全性提供额外的保护层。例如,如果 etcd 备份暴露给不应该获得这个数据的人员,它会帮助保护敏感数据。

启用 etcd 加密时,以下 OpenShift API 服务器和 Kubernetes API 服务器资源将被加密:

  • Secrets
  • 配置映射
  • Routes
  • OAuth 访问令牌
  • OAuth 授权令牌

当您启用 etcd 加密时,会创建加密密钥。您必须具有这些密钥才能从 etcd 备份中恢复。

注意

etcd 加密只加密值,而不加密键。资源类型、命名空间和对象名称是未加密的。

如果在备份过程中启用了 etcd 加密,static_kuberesources_<datetimestamp>.tar.gz 文件包含 etcd 快照的加密密钥。为安全起见,请将此文件与 etcd 快照分开存储。但是,需要这个文件才能从相应的 etcd 快照恢复以前的 etcd 状态。

8.14.2. 支持的加密类型

在 OpenShift Container Platform 中,支持以下加密类型来加密 etcd 数据:

AES-CBC
使用带有 PKCS#7 padding 和 32 字节密钥的 AES-CBC 来执行加密。加密密钥每周轮转。
AES-GCM
使用带有随机 nonce 和 32 字节密钥的 AES-GCM 来执行加密。加密密钥每周轮转。

8.14.3. 启用 etcd 加密

您可以启用 etcd 加密来加密集群中的敏感资源。

警告

在初始加密过程完成前,不要备份 etcd 资源。如果加密过程还没有完成,则备份可能只被部分加密。

启用 etcd 加密后,可能会出现一些更改:

  • etcd 加密可能会影响几个资源的内存消耗。
  • 您可能会注意到对备份性能具有临时影响,因为领导必须提供备份服务。
  • 磁盘 I/O 可能会影响接收备份状态的节点。

您可以在 AES-GCM 或 AES-CBC 加密中加密 etcd 数据库。

注意

要将 etcd 数据库从一个加密类型迁移到另一个加密类型,您可以修改 API 服务器的 spec.encryption.type 字段。将 etcd 数据迁移到新的加密类型会自动进行。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 修改 APIServer 对象:

    $ oc edit apiserver
  2. spec.encryption.type 字段设置为 aesgcmaescbc

    spec:
      encryption:
        type: aesgcm 1
    1
    设置为 aesgcm 用于 AES-GCM 加密,或设置为 aescbc 用于 AES-CBC 加密。
  3. 保存文件以使改变生效。

    加密过程开始。根据 etcd 数据库的大小,这个过程可能需要 20 分钟或更长时间才能完成。

  4. 验证 etcd 加密是否成功。

    1. 查看 OpenShift API 服务器的 Encrypted 状态条件,以验证其资源是否已成功加密:

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功加密后输出显示 EncryptionCompleted

      EncryptionCompleted
      All resources encrypted: routes.route.openshift.io

      如果输出显示 EncryptionInProgress,加密仍在进行中。等待几分钟后重试。

    2. 查看 Kubernetes API 服务器的 Encrypted 状态条件,以验证其资源是否已成功加密:

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功加密后输出显示 EncryptionCompleted

      EncryptionCompleted
      All resources encrypted: secrets, configmaps

      如果输出显示 EncryptionInProgress,加密仍在进行中。等待几分钟后重试。

    3. 查看 OpenShift OAuth API 服务器的 Encrypted 状态条件,以验证其资源是否已成功加密:

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功加密后输出显示 EncryptionCompleted

      EncryptionCompleted
      All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io

      如果输出显示 EncryptionInProgress,加密仍在进行中。等待几分钟后重试。

8.14.4. 禁用 etcd 加密

您可以在集群中禁用 etcd 数据的加密。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 修改 APIServer 对象:

    $ oc edit apiserver
  2. encryption 字段类型设置为 identity

    spec:
      encryption:
        type: identity 1
    1
    identity 类型是默认值,意味着没有执行任何加密。
  3. 保存文件以使改变生效。

    解密过程开始。根据集群的大小,这个过程可能需要 20 分钟或更长的时间才能完成。

  4. 验证 etcd 解密是否成功。

    1. 查看 OpenShift API 服务器的 Encrypted 状态条件,以验证其资源是否已成功解密:

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功解密后输出显示 DecryptionCompleted

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      如果输出显示 DecryptionInProgress,解密仍在进行中。等待几分钟后重试。

    2. 查看 Kubernetes API 服务器的 Encrypted 状态条件,以验证其资源是否已成功解密:

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功解密后输出显示 DecryptionCompleted

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      如果输出显示 DecryptionInProgress,解密仍在进行中。等待几分钟后重试。

    3. 查看 OpenShift OAuth API 服务器的 Encrypted 状态条件,以验证其资源是否已成功解密:

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功解密后输出显示 DecryptionCompleted

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      如果输出显示 DecryptionInProgress,解密仍在进行中。等待几分钟后重试。

8.14.5. 备份 etcd 数据

按照以下步骤,通过创建 etcd 快照并备份静态 pod 的资源来备份 etcd 数据。这个备份可以被保存,并在以后需要时使用它来恢复 etcd 数据。

重要

只保存单一 control plane 主机的备份。不要从集群中的每个 control plane 主机进行备份。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您已检查是否启用了集群范围代理。

    提示

    您可以通过查看 oc get proxy cluster -o yaml 的输出来检查代理是否已启用。如果 httpProxyhttpsProxynoProxy 字段设置了值,则会启用代理。

流程

  1. 以 root 用户身份为 control plane 节点启动一个 debug 会话:

    $ oc debug --as-root node/<node_name>
  2. 在 debug shell 中将根目录改为 /host

    sh-4.4# chroot /host
  3. 如果启用了集群范围的代理,请确定已导出了 NO_PROXYHTTP_PROXYHTTPS_PROXY 环境变量。
  4. 在 debug shell 中运行 cluster-backup.sh 脚本,并传递保存备份的位置。

    提示

    cluster-backup.sh 脚本作为 etcd Cluster Operator 的一个组件被维护,它是 etcdctl snapshot save 命令的包装程序(wrapper)。

    sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

    脚本输出示例

    found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
    found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
    found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
    found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
    ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
    etcdctl version: 3.4.14
    API version: 3.4
    {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
    {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
    {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
    {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
    {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
    {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
    Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
    {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
    snapshot db and kube resources are successfully saved to /home/core/assets/backup

    在这个示例中,在 control plane 主机上的 /home/core/assets/backup/ 目录中创建了两个文件:

    • snapshot_<datetimestamp>.db:这个文件是 etcd 快照。cluster-backup.sh 脚本确认其有效。
    • static_kuberesources_<datetimestamp>.tar.gz:此文件包含静态 pod 的资源。如果启用了 etcd 加密,它也包含 etcd 快照的加密密钥。

      注意

      如果启用了 etcd 加密,建议出于安全考虑,将第二个文件与 etcd 快照分开保存。但是,需要这个文件才能从 etcd 快照中进行恢复。

      请记住,etcd 仅对值进行加密,而不对键进行加密。这意味着资源类型、命名空间和对象名称是不加密的。

8.14.6. 分离 etcd 数据

对于大型、高密度的集群,如果键空间增长过大并超过空间配额,etcd 的性能将会受到影响。定期维护并处理碎片化的 etcd,以释放数据存储中的空间。监控 Prometheus 以了解 etcd 指标数据,并在需要时对其进行碎片处理;否则,etcd 可能会引发一个集群范围的警报,使集群进入维护模式,仅能接受对键的读和删除操作。

监控这些关键指标:

  • etcd_server_quota_backend_bytes,这是当前配额限制
  • etcd_mvcc_db_total_size_in_use_in_bytes,表示历史压缩后实际数据库使用量
  • etcd_mvcc_db_total_size_in_bytes 显示数据库大小,包括等待碎片整理的可用空间

在导致磁盘碎片的事件后(如 etcd 历史记录紧凑)对 etcd 数据进行清理以回收磁盘空间。

历史压缩将自动每五分钟执行一次,并在后端数据库中造成混乱。此碎片空间可供 etcd 使用,但主机文件系统不可用。您必须对碎片 etcd 进行碎片清除,才能使这个空间可供主机文件系统使用。

碎片清理会自动发生,但您也可以手动触发它。

注意

自动清理碎片非常适合大多数情况,因为 etcd operator 使用集群信息来确定用户最有效的操作。

8.14.6.1. 自动清理

etcd Operator 自动清理碎片磁盘。不需要人工干预。

查看以下日志之一来验证碎片整理过程是否成功:

  • etcd 日志
  • cluster-etcd-operator pod
  • Operator 状态错误日志
警告

自动清除可能会导致各种 OpenShift 核心组件中的领导选举失败,如 Kubernetes 控制器管理器,这会触发重启失败的组件。重启会有危害,并会触发对下一个正在运行的实例的故障切换,或者组件在重启后再次恢复工作。

成功进行碎片处理的日志输出示例

etcd member has been defragmented: <member_name>, memberID: <member_id>

进行碎片处理失败的日志输出示例

failed defrag on member: <member_name>, memberID: <member_id>: <error_message>

8.14.6.2. 手动清理

Prometheus 警报指示您需要手动进行碎片处理。该警报在两个情况下显示:

  • 当 etcd 使用超过 50% 的可用空间超过了 10 分钟
  • 当 etcd 活跃使用小于其数据库总大小的 50% 超过了 10 分钟

您还可以通过检查 etcd 数据库大小(MB)来决定是否需要进行碎片整理。通过 PromQL 表达 (etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_use_in_bytes)/1024/1024 来释放空间。

警告

分离 etcd 是一个阻止性操作。在进行碎片处理完成前,etcd 成员将没有响应。因此,在每个下一个 pod 要进行碎片清理前,至少等待一分钟,以便集群可以恢复正常工作。

按照以下步骤对每个 etcd 成员上的 etcd 数据进行碎片处理。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 确定哪个 etcd 成员是领导成员,因为领导会进行最后的碎片处理。

    1. 获取 etcd pod 列表:

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

      输出示例

      etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
      etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
      etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

    2. 选择 pod 并运行以下命令来确定哪个 etcd 成员是领导:

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

      输出示例

      Defaulting container name to etcdctl.
      Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      基于此输出的 IS LEADER 列,https://10.0.199.170:2379 端点是领导。与上一步输出匹配此端点,领导的 pod 名称为 etcd-ip-10-0-199-170.example.redhat.com

  2. 清理 etcd 成员。

    1. 连接到正在运行的 etcd 容器,传递 不是 领导的 pod 的名称:

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
    2. 取消设置 ETCDCTL_ENDPOINTS 环境变量:

      sh-4.4# unset ETCDCTL_ENDPOINTS
    3. 清理 etcd 成员:

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag

      输出示例

      Finished defragmenting etcd member[https://localhost:2379]

      如果发生超时错误,增加 --command-timeout 的值,直到命令成功为止。

    4. 验证数据库大小是否已缩小:

      sh-4.4# etcdctl endpoint status -w table --cluster

      输出示例

      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 1
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      本例显示这个 etcd 成员的数据库大小现在为 41 MB,而起始大小为 104 MB。

    5. 重复这些步骤以连接到其他 etcd 成员并进行碎片处理。最后才对领导进行碎片清除。

      至少要在碎片处理操作之间等待一分钟,以便 etcd pod 可以恢复。在 etcd pod 恢复前,etcd 成员不会响应。

  3. 如果因为超过空间配额而触发任何 NOSPACE 警告,请清除它们。

    1. 检查是否有 NOSPACE 警告:

      sh-4.4# etcdctl alarm list

      输出示例

      memberID:12345678912345678912 alarm:NOSPACE

    2. 清除警告:

      sh-4.4# etcdctl alarm disarm

8.14.7. 恢复到一个以前的集群状态

您可以使用保存的 etcd 备份来恢复以前的集群状态,或恢复丢失了大多数 control plane 主机的集群。

注意

如果您的集群使用 control plane 机器集,请参阅 "Troubleshooting control plane 机器集"来了解有关 etcd 恢复的过程。

重要

恢复集群时,必须使用同一 z-stream 发行版本中获取的 etcd 备份。例如,OpenShift Container Platform 4.7.2 集群必须使用从 4.7.2 开始的 etcd 备份。

先决条件

  • 通过一个基于证书的 kubeconfig 使用具有 cluster-admin 角色的用户访问集群,如安装期间的情况。
  • 用作恢复主机的健康 control plane 主机。
  • SSH 对 control plane 主机的访问。
  • 包含从同一备份中获取的 etcd 快照和静态 pod 资源的备份目录。该目录中的文件名必须采用以下格式: snapshot_<datetimestamp>.dbstatic_kuberesources_<datetimestamp>.tar.gz
重要

对于非恢复 control plane 节点,不需要建立 SSH 连接或停止静态 pod。您可以逐个删除并重新创建其他非恢复 control plane 机器。

流程

  1. 选择一个要用作恢复主机的 control plane 主机。这是您要在其中运行恢复操作的主机。
  2. 建立到每个 control plane 节点(包括恢复主机)的 SSH 连接。

    恢复过程启动后,kube-apiserver 将无法访问,因此您无法访问 control plane 节点。因此,建议在一个单独的终端中建立到每个control plane 主机的 SSH 连接。

    重要

    如果没有完成这个步骤,将无法访问 control plane 主机来完成恢复过程,您将无法从这个状态恢复集群。

  3. etcd 备份目录复制到恢复 control plane 主机上。

    此流程假设您将 backup 目录(其中包含 etcd 快照和静态 pod 资源)复制到恢复 control plane 主机的 /home/core/ 目录中。

  4. 在任何其他 control plane 节点上停止静态 pod。

    注意

    您不需要停止恢复主机上的静态 pod。

    1. 访问不是恢复主机的 control plane 主机。
    2. 运行以下命令,将现有 etcd pod 文件从 kubelet 清单目录中移出:

      $ sudo mv -v /etc/kubernetes/manifests/etcd-pod.yaml /tmp
    3. 使用以下命令验证 etcd pod 是否已停止:

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

      如果这个命令的输出不为空,请等待几分钟,然后再次检查。

    4. 运行以下命令,将现有 kube-apiserver 文件从 kubelet 清单目录中移出:

      $ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
    5. 运行以下命令验证 kube-apiserver 容器是否已停止:

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"

      如果这个命令的输出不为空,请等待几分钟,然后再次检查。

    6. 使用以下方法将现有 kube-controller-manager 文件从 kubelet 清单目录中移出:

      $ sudo mv -v /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp
    7. 运行以下命令验证 kube-controller-manager 容器是否已停止:

      $ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"

      如果这个命令的输出不为空,请等待几分钟,然后再次检查。

    8. 使用以下方法将现有 kube-scheduler 文件从 kubelet 清单目录中移出:

      $ sudo mv -v /etc/kubernetes/manifests/kube-scheduler-pod.yaml /tmp
    9. 使用以下命令验证 kube-scheduler 容器是否已停止:

      $ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"

      如果这个命令的输出不为空,请等待几分钟,然后再次检查。

    10. 使用以下示例将 etcd 数据目录移到不同的位置:

      $ sudo mv -v /var/lib/etcd/ /tmp
    11. 如果 /etc/kubernetes/manifests/keepalived.yaml 文件存在,且节点被删除,请按照以下步骤执行:

      1. /etc/kubernetes/manifests/keepalived.yaml 文件从 kubelet 清单目录中移出:

        $ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp
      2. 容器验证由 keepalived 守护进程管理的任何容器是否已停止:

        $ sudo crictl ps --name keepalived

        命令输出应该为空。如果它不是空的,请等待几分钟后再重新检查。

      3. 检查 control plane 是否已分配任何 Virtual IP (VIP):

        $ ip -o address | egrep '<api_vip>|<ingress_vip>'
      4. 对于每个报告的 VIP,运行以下命令将其删除:

        $ sudo ip address del <reported_vip> dev <reported_vip_device>
    12. 在其他不是恢复主机的 control plane 主机上重复此步骤。
  5. 访问恢复 control plane 主机。
  6. 如果使用 keepalived 守护进程,请验证恢复 control plane 节点是否拥有 VIP:

    $ ip -o address | grep <api_vip>

    如果存在 VIP 的地址(如果存在)。如果 VIP 没有设置或配置不正确,这个命令会返回一个空字符串。

  7. 如果启用了集群范围的代理,请确定已导出了 NO_PROXYHTTP_PROXYHTTPS_PROXY 环境变量。

    提示

    您可以通过查看 oc get proxy cluster -o yaml 的输出来检查代理是否已启用。如果 httpProxyhttpsProxynoProxy 字段设置了值,则会启用代理。

  8. 在恢复 control plane 主机上运行恢复脚本,并传递到 etcd 备份目录的路径:

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/backup

    脚本输出示例

    ...stopping kube-scheduler-pod.yaml
    ...stopping kube-controller-manager-pod.yaml
    ...stopping etcd-pod.yaml
    ...stopping kube-apiserver-pod.yaml
    Waiting for container etcd to stop
    .complete
    Waiting for container etcdctl to stop
    .............................complete
    Waiting for container etcd-metrics to stop
    complete
    Waiting for container kube-controller-manager to stop
    complete
    Waiting for container kube-apiserver to stop
    ..........................................................................................complete
    Waiting for container kube-scheduler to stop
    complete
    Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
    starting restore-etcd static pod
    starting kube-apiserver-pod.yaml
    static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
    starting kube-controller-manager-pod.yaml
    static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
    starting kube-scheduler-pod.yaml
    static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

    cluster-restore.sh 脚本必须显示 etcdkube-apiserverkube-controller-managerkube-scheduler pod 已停止,然后在恢复过程结束时启动。

    注意

    如果在上次 etcd 备份后更新了节点,则恢复过程可能会导致节点进入 NotReady 状态。

  9. 检查节点以确保它们处于 Ready 状态。

    1. 运行以下命令:

      $ oc get nodes -w

      输出示例

      NAME                STATUS  ROLES          AGE     VERSION
      host-172-25-75-28   Ready   master         3d20h   v1.28.5
      host-172-25-75-38   Ready   infra,worker   3d20h   v1.28.5
      host-172-25-75-40   Ready   master         3d20h   v1.28.5
      host-172-25-75-65   Ready   master         3d20h   v1.28.5
      host-172-25-75-74   Ready   infra,worker   3d20h   v1.28.5
      host-172-25-75-79   Ready   worker         3d20h   v1.28.5
      host-172-25-75-86   Ready   worker         3d20h   v1.28.5
      host-172-25-75-98   Ready   infra,worker   3d20h   v1.28.5

      所有节点都可能需要几分钟时间报告其状态。

    2. 如果有任何节点处于 NotReady 状态,登录到节点,并从每个节点上的 /var/lib/kubelet/pki 目录中删除所有 PEM 文件。您可以 SSH 到节点,或使用 web 控制台中的终端窗口。

      $  ssh -i <ssh-key-path> core@<master-hostname>

      pki 目录示例

      sh-4.4# pwd
      /var/lib/kubelet/pki
      sh-4.4# ls
      kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
      kubelet-client-current.pem              kubelet-server-current.pem

  10. 在所有 control plane 主机上重启 kubelet 服务。

    1. 在恢复主机中运行:

      $ sudo systemctl restart kubelet.service
    2. 在所有其他 control plane 主机上重复此步骤。
  11. 批准待处理的证书签名请求 (CSR):

    注意

    没有 worker 节点的集群(如单节点集群或由三个可调度的 control plane 节点组成的集群)不会批准任何待处理的 CSR。您可以跳过此步骤中列出的所有命令。

    1. 运行以下命令获取当前 CSR 列表:

      $ oc get csr

      输出示例

      NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
      csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
      csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
      csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
      csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
      ...

      1 1 2
      一个待处理的 kubelet 服务 CSR,由 kubelet 服务端点请求。
      3 4
      一个待处理的 kubelet 客户端 CSR,使用 node-bootstrapper 节点 bootstrap 凭证请求。
    2. 运行以下命令,查看 CSR 的详情以验证其是否有效:

      $ oc describe csr <csr_name> 1
      1
      <csr_name> 是当前 CSR 列表中 CSR 的名称。
    3. 运行以下命令来批准每个有效的 node-bootstrapper CSR:

      $ oc adm certificate approve <csr_name>
    4. 对于用户置备的安装,运行以下命令批准每个有效的 kubelet 服务 CSR:

      $ oc adm certificate approve <csr_name>
  12. 确认单个成员 control plane 已被成功启动。

    1. 在恢复主机上,使用以下命令验证 etcd 容器是否正在运行:

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

      输出示例

      3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

    2. 在恢复主机上,使用以下命令验证 etcd pod 是否正在运行:

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      输出示例

      NAME                                             READY   STATUS      RESTARTS   AGE
      etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

      如果状态是 Pending,或者输出中列出了多个正在运行的 etcd pod,请等待几分钟,然后再次检查。

  13. 如果使用 OVNKubernetes 网络插件,您必须重启 ovnkube-controlplane pod。

    1. 运行以下命令删除所有 ovnkube-controlplane pod:

      $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-control-plane
    2. 使用以下命令验证所有 ovnkube-controlplane pod 是否已重新部署:

      $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-control-plane
  14. 如果使用 OVN-Kubernetes 网络插件,请逐个重启所有节点上的 Open Virtual Network (OVN) Kubernetes pod。使用以下步骤重启每个节点上的 OVN-Kubernetes pod:

    重要

    按照以下顺序重启 OVN-Kubernetes pod:

    1. 恢复控制平面主机
    2. 其他控制平面主机(如果可用)
    3. 其他节点
    注意

    验证和变异准入 Webhook 可能会拒绝 pod。如果您添加了额外的 Webhook,其 failurePolicy 被设置为 Fail 的,则它们可能会拒绝 pod,恢复过程可能会失败。您可以通过在恢复集群状态时保存和删除 Webhook 来避免这种情况。成功恢复集群状态后,您可以再次启用 Webhook。

    另外,您可以在恢复集群状态时临时将 failurePolicy 设置为 Ignore。成功恢复集群状态后,您可以将 failurePolicy 设置为 Fail

    1. 删除北向数据库 (nbdb) 和南向数据库 (sbdb)。使用 Secure Shell (SSH) 访问恢复主机和剩余的 control plane 节点,并运行:

      $ sudo rm -f /var/lib/ovn-ic/etc/*.db
    2. 重新启动 OpenVSwitch 服务。使用 Secure Shell (SSH) 访问节点,并运行以下命令:

      $ sudo systemctl restart ovs-vswitchd ovsdb-server
    3. 运行以下命令删除节点上的 ovnkube-node pod,将 <node> 替换为您要重启的节点的名称:

      $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
    4. 使用以下命令验证 ovnkube-node pod 已再次运行:

      $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
      注意

      pod 可能需要几分钟时间来重启。

  15. 逐个删除并重新创建其他非恢复 control plane 机器。重新创建机器后,会强制一个新修订版本,etcd 会自动扩展。

    • 如果使用用户置备的裸机安装,您可以使用最初创建它时使用的相同方法重新创建 control plane 机器。如需更多信息,请参阅"在裸机上安装用户置备的集群"。

      警告

      不要为恢复主机删除并重新创建机器。

    • 如果您正在运行安装程序置备的基础架构,或者您使用 Machine API 创建机器,请按照以下步骤执行:

      警告

      不要为恢复主机删除并重新创建机器。

      对于安装程序置备的基础架构上的裸机安装,不会重新创建 control plane 机器。如需更多信息,请参阅"替换裸机控制平面节点"。

      1. 为丢失的 control plane 主机之一获取机器。

        在一个终端中使用 cluster-admin 用户连接到集群,运行以下命令:

        $ oc get machines -n openshift-machine-api -o wide

        输出示例:

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
        clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        1
        这是用于丢失的 control plane 主机 ip-10-0-131-183.ec2.internal 的 control plane 机器。
      2. 运行以下命令,将机器配置保存到文件系统中的一个文件中:

        $ oc get machine clustername-8qw5l-master-0 \ 1
            -n openshift-machine-api \
            -o yaml \
            > new-master-machine.yaml
        1
        为丢失的 control plane 主机指定 control plane 机器的名称。
      3. 编辑上一步中创建的 new-master-machine.yaml 文件,以分配新名称并删除不必要的字段。

        1. 运行以下命令删除整个 status 部分:

          status:
            addresses:
            - address: 10.0.131.183
              type: InternalIP
            - address: ip-10-0-131-183.ec2.internal
              type: InternalDNS
            - address: ip-10-0-131-183.ec2.internal
              type: Hostname
            lastUpdated: "2020-04-20T17:44:29Z"
            nodeRef:
              kind: Node
              name: ip-10-0-131-183.ec2.internal
              uid: acca4411-af0d-4387-b73e-52b2484295ad
            phase: Running
            providerStatus:
              apiVersion: awsproviderconfig.openshift.io/v1beta1
              conditions:
              - lastProbeTime: "2020-04-20T16:53:50Z"
                lastTransitionTime: "2020-04-20T16:53:50Z"
                message: machine successfully created
                reason: MachineCreationSucceeded
                status: "True"
                type: MachineCreation
              instanceId: i-0fdb85790d76d0c3f
              instanceState: stopped
              kind: AWSMachineProviderStatus
        2. 运行以下命令,将 metadata.name 字段改为新名称:

          建议您保留与旧机器相同的基础名称,并将结束号码改为下一个可用数字。在本例中,clustername-8qw5l-master-0 被改为 clustername-8qw5l-master-3

          apiVersion: machine.openshift.io/v1beta1
          kind: Machine
          metadata:
            ...
            name: clustername-8qw5l-master-3
            ...
        3. 运行以下命令来删除 spec.providerID 字段:

          providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
        4. 运行以下命令,删除 metadata.annotationsmetadata.generation 字段:

          annotations:
            machine.openshift.io/instance-state: running
          ...
          generation: 2
        5. 运行以下命令,删除 metadata.resourceVersionmetadata.uid 字段:

          resourceVersion: "13291"
          uid: a282eb70-40a2-4e89-8009-d05dd420d31a
      4. 运行以下命令,删除丢失的 control plane 主机的机器:

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
        1
        为丢失的 control plane 主机指定 control plane 机器的名称。
      5. 运行以下命令验证机器是否已删除:

        $ oc get machines -n openshift-machine-api -o wide

        输出示例:

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal   aws:///us-east-1c/i-02626f1dba9ed5bba  running
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
      6. 运行以下命令,使用 new-master-machine.yaml 文件创建机器:

        $ oc apply -f new-master-machine.yaml
      7. 运行以下命令验证新机器是否已创建:

        $ oc get machines -n openshift-machine-api -o wide

        输出示例:

        NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
        clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 1
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        1
        新机器 clustername-8qw5l-master-3 会被创建,并在阶段从 Provisioning 变为 Running 后就绪。

        创建新机器可能需要几分钟时间。当机器或节点返回到健康状态时,etcd 集群 Operator 将自动同步。

      8. 对不是恢复主机的每个已丢失的 control plane 主机重复此步骤。
  16. 输入以下内容关闭仲裁保护:

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    此命令可确保您可以成功重新创建机密并推出静态 pod。

  17. 在恢复主机中的一个单独的终端窗口中,运行以下命令导出恢复 kubeconfig 文件:

    $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
  18. 强制 etcd 重新部署。

    在导出恢复 kubeconfig 文件的同一终端窗口中,运行:

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
    1
    forceRedeploymentReason 值必须是唯一的,这就是为什么附加时间戳的原因。

    etcd 集群 Operator 执行重新部署时,现有节点开始使用与初始 bootstrap 扩展类似的新 pod。

  19. 输入以下内容重新打开仲裁保护:

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  20. 您可以运行以下命令来验证 unsupportedConfigOverrides 部分是否已从对象中删除:

    $ oc get etcd/cluster -oyaml
  21. 验证所有节点是否已更新至最新的修订版本。

    在一个终端中使用 cluster-admin 用户连接到集群,请运行:

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    查看 etcdNodeInstallerProgressing 状态条件,以验证所有节点是否处于最新的修订版本。在更新成功后,输出会显示 AllNodesAtLatestRevision

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1
    1
    在本例中,最新的修订版本号是 7

    如果输出包含多个修订号,如 2 个节点为修订版本 6;1 个节点为修订版本 7,这意味着更新仍在进行中。等待几分钟后重试。

  22. 重新部署 etcd 后,为 control plane 强制进行新的推出部署。kube-apiserver 将在其他节点上重新安装自己,因为 kubelet 使用内部负载均衡器连接到 API 服务器。

    在一个终端中使用 cluster-admin 用户连接到集群,请运行:

    1. kube-apiserver 强制进行新的推出部署:

      $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

      验证所有节点是否已更新至最新的修订版本。

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      查看 NodeInstallerProgressing 状态条件,以验证所有节点是否处于最新版本。在更新成功后,输出会显示 AllNodesAtLatestRevision

      AllNodesAtLatestRevision
      3 nodes are at revision 7 1
      1
      在本例中,最新的修订版本号是 7

      如果输出包含多个修订号,如 2 个节点为修订版本 6;1 个节点为修订版本 7,这意味着更新仍在进行中。等待几分钟后重试。

    2. 运行以下命令,为 Kubernetes 控制器管理器强制进行新的推出部署:

      $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

      运行以下命令,验证所有节点是否已更新至最新的修订版本:

      $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      查看 NodeInstallerProgressing 状态条件,以验证所有节点是否处于最新版本。在更新成功后,输出会显示 AllNodesAtLatestRevision

      AllNodesAtLatestRevision
      3 nodes are at revision 7 1
      1
      在本例中,最新的修订版本号是 7

      如果输出包含多个修订号,如 2 个节点为修订版本 6;1 个节点为修订版本 7,这意味着更新仍在进行中。等待几分钟后重试。

    3. 运行以下命令,为 kube-scheduler 强制进行新的推出部署:

      $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

      使用以下命令验证所有节点是否已更新至最新的修订版本:

      $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      查看 NodeInstallerProgressing 状态条件,以验证所有节点是否处于最新版本。在更新成功后,输出会显示 AllNodesAtLatestRevision

      AllNodesAtLatestRevision
      3 nodes are at revision 7 1
      1
      在本例中,最新的修订版本号是 7

      如果输出包含多个修订号,如 2 个节点为修订版本 6;1 个节点为修订版本 7,这意味着更新仍在进行中。等待几分钟后重试。

  23. 验证所有 control plane 主机是否已启动并加入集群。

    在一个终端中使用 cluster-admin 用户连接到集群,运行以下命令:

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    输出示例

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

为确保所有工作负载在恢复过程后返回到正常操作,请重启存储 kube-apiserver 信息的每个 pod。这包括 OpenShift Container Platform 组件,如路由器、Operator 和第三方组件。

注意

完成前面的流程步骤后,您可能需要等待几分钟,让所有服务返回到恢复的状态。例如,在重启 OAuth 服务器 pod 前,使用 oc login 进行身份验证可能无法立即正常工作。

考虑使用 system:admin kubeconfig 文件立即进行身份验证。这个方法基于 SSL/TLS 客户端证书作为 OAuth 令牌的身份验证。您可以发出以下命令来使用此文件进行身份验证:

$ export KUBECONFIG=<installation_directory>/auth/kubeconfig

发出以下命令以显示您的验证的用户名:

$ oc whoami

8.14.8. 恢复持久性存储状态的问题和解决方法

如果您的 OpenShift Container Platform 集群使用任何形式的持久性存储,集群的状态通常存储在 etcd 外部。它可能是在 pod 中运行的 Elasticsearch 集群,或者在 StatefulSet 对象中运行的数据库。从 etcd 备份中恢复时,还会恢复 OpenShift Container Platform 中工作负载的状态。但是,如果 etcd 快照是旧的,其状态可能无效或过期。

重要

持久性卷(PV)的内容绝不会属于 etcd 快照的一部分。从 etcd 快照恢复 OpenShift Container Platform 集群时,非关键工作负载可能会访问关键数据,反之亦然。

以下是生成过时状态的一些示例情况:

  • MySQL 数据库在由 PV 对象支持的 pod 中运行。从 etcd 快照恢复 OpenShift Container Platform 不会使卷恢复到存储供应商上,且不会生成正在运行的 MySQL pod,尽管 pod 会重复尝试启动。您必须通过在存储供应商中恢复卷,然后编辑 PV 以指向新卷来手动恢复这个 pod。
  • Pod P1 使用卷 A,它附加到节点 X。如果另一个 pod 在节点 Y 上使用相同的卷,则执行 etcd 恢复时,pod P1 可能无法正确启动,因为卷仍然被附加到节点 Y。OpenShift Container Platform 并不知道附加,且不会自动分离它。发生这种情况时,卷必须从节点 Y 手动分离,以便卷可以在节点 X 上附加,然后 pod P1 才可以启动。
  • 在执行 etcd 快照后,云供应商或存储供应商凭证会被更新。这会导致任何依赖于这些凭证的 CSI 驱动程序或 Operator 无法正常工作。您可能需要手动更新这些驱动程序或 Operator 所需的凭证。
  • 在生成 etcd 快照后,会从 OpenShift Container Platform 节点中删除或重命名设备。Local Storage Operator 会为从 /dev/disk/by-id/dev 目录中管理的每个 PV 创建符号链接。这种情况可能会导致本地 PV 引用不再存在的设备。

    要解决这个问题,管理员必须:

    1. 手动删除带有无效设备的 PV。
    2. 从对应节点中删除符号链接。
    3. 删除 LocalVolumeLocalVolumeSet 对象(请参阅 StorageConfiguring persistent storagePersistent storage → Persistent storageDeleting the Local Storage Operator Resources)。

8.15. Pod 中断预算

了解并配置 pod 中断预算。

8.15.1. 了解如何使用 pod 中断预算来指定必须在线的 pod 数量

pod 中断预算允许在操作过程中指定 pod 的安全限制,如排空节点以进行维护。

PodDisruptionBudget 是一个 API 对象,用于指定在某一时间必须保持在线的副本的最小数量或百分比。在项目中进行这些设置对节点维护(比如缩减集群或升级集群)有益,而且仅在自愿驱除(而非节点失败)时遵从这些设置。

PodDisruptionBudget 对象的配置由以下关键部分组成:

  • 标签选择器,即一组 pod 的标签查询。
  • 可用性级别,用来指定必须同时可用的最少 pod 的数量:

    • minAvailable 是必须始终可用的 pod 的数量,即使在中断期间也是如此。
    • maxUnavailable 是中断期间可以