Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

安装后配置

OpenShift Container Platform 4.7

OpenShift Container Platform 的第二天操作

摘要

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

第 1 章 安装后配置概述
复制链接

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

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

1.1. 执行安装后配置任务
复制链接

集群管理员可执行以下安装后配置任务：

  • 配置操作系统功能 ： Machine Config Operator(MCO)管理 MachineConfig 对象。通过使用 MCO，您可以在 OpenShift Container Platform 集群中执行以下操作：

    • 使用 MachineConfig 对象配置节点
    • 配置 MCO 相关的自定义资源

  • 配置集群功能 ： 作为集群管理员，您可以修改 OpenShift Container Platform 集群主要功能的配置资源。这些特性包括：

    • 镜像 registry
    • 网络配置
    • 镜像构建行为
    • 用户身份提供程序
    • etcd 配置
    • 创建机器集以处理工作负载
    • 云供应商凭证管理

  • 将集群组件配置为私有 ： 默认情况下，安装程序使用公开的 DNS 和端点置备 OpenShift Container Platform。如果您希望集群只能从内部网络访问，请将以下组件配置为私有：

    • DNS
    • Ingress Controller
    • API Server

  • 执行节点操作 ：默认情况下，OpenShift Container Platform 使用 Red Hat Enterprise Linux CoreOS(RHCOS)计算机器。作为集群管理员，您可以使用 OpenShift Container Platform 集群中的机器执行以下操作：

    • 添加和删除计算机器
    • 为节点添加和删除污点和容限
    • 配置每个节点的最大 pod 数量
    • 启用设备管理器

  • 配置网络 ：安装 OpenShift Container Platform 后，作为集群管理员，您可以配置以下内容：

    • 集群入口流量
    • 节点端口服务范围
    • 网络策略
    • 启用集群范围代理

  • 配置存储 ：默认情况下，容器使用临时存储或临时本地存储来运行。临时存储有一个生命周期限制，因此您必须配置持久性存储来长期存储数据。您可以使用以下方法之一配置存储：

    • 动态置备 ：您可以通过定义和创建控制不同级别的存储（包括存储访问）的存储类来动态按需置备存储。
    • 静态调配 ：集群管理员可以使用 Kubernetes 持久卷通过支持各种设备配置和挂载选项，将现有存储提供给集群。
  • 配置用户 ：OAuth 访问令牌允许用户对自身进行 API 身份验证。作为集群管理员，您可以配置 OAuth 以指定身份提供程序，使用基于角色的访问控制来定义并应用到用户，并从 OperatorHub 安装 Operator。
  • 管理警报和通知 ：作为集群管理员，您可以从 Web 控制台的 Alerting UI 中默认查看触发警报。您还可以将 OpenShift Container Platform 配置为向外部系统发送警报通知，以便了解集群存在的重要问题。

第 2 章 配置私有集群
复制链接

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

2.1. 关于私有集群
复制链接

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

DNS

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

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

Ingress Controller

由于默认 Ingress 对象是作为公共对象创建的，所以负载均衡器是面向互联网的，因此在公共子网中。您可以将默认 Ingress Controller 替换为内部控制器。

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
    Copy to Clipboard Toggle word wrap

    输出示例

    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: {}
    Copy to Clipboard Toggle word wrap

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

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

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

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

    重要

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

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

    $ oc get dnses.config.openshift.io/cluster -o yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    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: {}
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

    输出示例

    ingresscontroller.operator.openshift.io "default" deleted
ingresscontroller.operator.openshift.io/default replaced
    Copy to Clipboard Toggle word wrap

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

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

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

先决条件

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

流程

  1. 在 AWS 或 Azure 的 web 门户或控制台中，执行以下操作：

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

      • 对于 AWS，删除外部负载均衡器。私有区的 API DNS 条目已指向内部负载均衡器，它使用相同的配置，因此您无需修改内部负载均衡器。
      • 对于 Azure，删除负载均衡器的 api-internal 规则。
    2. 在公共区中删除 api.$clustername.$yourdomain DNS 条目。

  2. 删除外部负载均衡器：

    重要

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

    1. 在终端中列出集群机器： 

      $ oc get machine -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      Copy to Clipboard Toggle word wrap

      在以下步骤中，修改 control plane 机器（名称中包含 master 的机器）。

    2. 从每台 control plane 机器移除外部负载均衡器。

      1. 编辑 control plane Machine 对象以移除对外部负载均衡器的引用： 

        $ oc edit machines -n openshift-machine-api <master_name>
        1
        Copy to Clipboard Toggle word wrap
        1
        指定要修改的 control plane 或 master Machine 对象的名称。

      2. 删除描述外部负载均衡器的行（在以下示例中已被标记），保存并退出对象规格： 

        ...
spec:
  providerSpec:
    value:
    ...
      loadBalancers:
      - name: lk4pj-ext
        1 
        
        type: network
        2 
        
      - name: lk4pj-int
        type: network
        Copy to Clipboard Toggle word wrap
        1 2
        删除这一行。
      3. 对名称中包含 master 的每个机器重复这个过程。

第 3 章 安装后机器配置任务
复制链接

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

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

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

3.1. 了解 Machine Config Operator
复制链接

3.1.1. Machine Config Operator
复制链接

用途

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

有四个组件：

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

openshift-machine-config-operator

3.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 节点（也称为 master 节点）池开头。通过添加更多角色标签，您可以配置自定义节点池。例如，您可以设置一个自定义的 worker 节点池，其中包含应用程序所需的特定硬件功能。但是，本节中的示例着重介绍了对默认池类型的更改。

    重要

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

  • 在将 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。

3.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）。这只在选择的平台上被支持。
  • fips：启用 FIPS 模式。不应在安装时设置 FIPS，而不是安装后的步骤。
重要

只有在 x86_64 架构中的 OpenShift Container Platform 部署支持 FIPS 验证的/Modules in Process 加密库。

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

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

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

3.1.2.2. project
复制链接

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

3.1.3. 检查机器配置池状态
复制链接

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

流程

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

    $ oc get machineconfigpool
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

    其中：

    已更新
    True 状态表示 MCO 已将当前机器配置应用到该 MCP 中的节点。当前机器配置在 oc get mcp 输出中的 STATUS 字段中指定。False 状态表示 MCP 中的节点正在更新。
    更新
    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 中的两个节点被更新，一个仍在更新，如 UPDATEDMACHINECOUNT 为 2。没有问题，如 DEGRADED MACHINECOUNT 为 0， DEGRADED 为 False。

    虽然 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
    Copy to Clipboard Toggle word wrap

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

    $ oc describe mcp worker
    Copy to Clipboard Toggle word wrap

    输出示例

    ...
  Degraded Machine Count:     0
  Machine Count:              3
  Observed Generation:        2
  Ready Machine Count:        3
  Unavailable Machine Count:  0
  Updated Machine Count:      3
Events:                       <none>
    Copy to Clipboard Toggle word wrap

    注意

    如果节点被封锁，则节点不包含在 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
    Copy to Clipboard Toggle word wrap

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

    $ oc get machineconfigs
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

    请注意，列为 rendered 的 MachineConfig 对象并不意味着要更改或删除。

  4. 要查看特定机器配置的内容（本例中为 01-master-kubelet），请运行以下命令： 

    $ oc describe machineconfigs 01-master-kubelet
    Copy to Clipboard Toggle word wrap

    命令的输出显示此 MachineConfig 对象同时包含配置文件(cloud.conf 和 kubelet.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 \ ...
    Copy to Clipboard Toggle word wrap

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

$ oc delete -f ./myconfig.yaml
Copy to Clipboard Toggle word wrap

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

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

3.2. 使用 MachineConfig 对象配置节点
复制链接

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

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

提示

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

3.2.1. 配置 chrony 时间服务
复制链接

您可以通过修改 chrony.conf 文件的内容来设置 chrony 时间服务（chronyd）使用的时间服务器和相关设置，并通过一个机器配置将这些内容传递给节点。

流程

  1. 创建 chrony.conf 文件的内容并对其进行 base64 编码。例如： 

    $ cat << EOF | base64
    pool 0.rhel.pool.ntp.org iburst
    1 
    
    driftfile /var/lib/chrony/drift
    makestep 1.0 3
    rtcsync
    logdir /var/log/chrony
EOF
    Copy to Clipboard Toggle word wrap
    1
    指定任何有效的、可访问的时间源，如 DHCP 服务器提供的时间源。另外，您可以指定以下 NTP 服务器： 1.rhel.pool.ntp.org、2.rhel.pool.ntp.org 或 3.rhel.pool.ntp.org。

    输出示例

    ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGli
L2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAv
dmFyL2xvZy9jaHJvbnkK
    Copy to Clipboard Toggle word wrap

  2. 创建 MachineConfig 对象文件，将 base64 字符串替换为您刚刚创建的字符串。本例将文件添加到 master 节点。您可以将其更改为 worker，或为 worker 角色创建额外的 MachineConfig。为集群使用的每种机器创建 MachineConfig 文件： 

    $ cat << EOF > ./99-masters-chrony-configuration.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-masters-chrony-configuration
spec:
  config:
    ignition:
      config: {}
      security:
        tls: {}
      timeouts: {}
      version: 3.2.0
    networkd: {}
    passwd: {}
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGliL2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAvdmFyL2xvZy9jaHJvbnkK
        mode: 420
    1 
    
        overwrite: true
        path: /etc/chrony.conf
  osImageURL: ""
EOF
    Copy to Clipboard Toggle word wrap
    1
    为机器配置文件的 mode 字段指定数值模式。在创建文件并应用更改后，模式 将转换为十进制值。您可以使用 oc get mc <mc-name> -o yaml 命令来检查 YAML 文件。
  3. 对配置文件做一个备份副本。

  4. 使用两种方式之一应用配置：

    • 如果集群还没有启动，在生成清单文件后，将此文件添加到 <installation_directory>/openshift 目录中，然后继续创建集群。

    • 如果集群已在运行，请应用该文件： 

       $ oc apply -f ./99-masters-chrony-configuration.yaml
      Copy to Clipboard Toggle word wrap

3.2.2. 为节点添加内核参数
复制链接

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

警告

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

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

  • Enforcing=0：将 Security Enhanced Linux（SELinux）配置为以 permissive 模式运行。在 permissive 模式中，系统会象 SELinux 一样加载安全策略，包括标记对象并在日志中记录访问拒绝条目，但它并不会拒绝任何操作。虽然不支持生产系统，permissive 模式对调试非常有用。
  • nosmt：在内核中禁用对称多线程 (SMT)。多线程允许每个 CPU 有多个逻辑线程。您可以在多租户环境中考虑使用 nosmt，以减少潜在的跨线程攻击风险。禁用 SMT 在本质上相当于选择安全性而非性能。

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

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

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

先决条件

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

流程

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

    $ oc get MachineConfig
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

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

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    1 
    
  name: 05-worker-kernelarg-selinuxpermissive
    2 
    
spec:
  config:
    ignition:
      version: 3.2.0
  kernelArguments:
    - enforcing=0
    3
    Copy to Clipboard Toggle word wrap
    1
    仅将新内核参数应用到 worker 节点。
    2
    用于标识它插入到机器配置中的什么位置（05）以及发挥什么作用（添加一个内核参数来配置 SELinux permissive 模式）。
    3
    将确切的内核参数标识为 enforcing=0。

  3. 创建新机器配置： 

    $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml
    Copy to Clipboard Toggle word wrap

  4. 检查机器配置以查看是否添加了新配置： 

    $ oc get MachineConfig
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

  5. 检查节点： 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                           STATUS                     ROLES    AGE   VERSION
ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.20.0
ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.20.0
ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.20.0
ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.20.0
ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.20.0
ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.20.0
    Copy to Clipboard Toggle word wrap

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

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

    $ oc debug node/ip-10-0-141-105.ec2.internal
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

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

3.2.3. 在 RHCOS 上启用内核参数的多路径
复制链接

RHCOS 支持主磁盘上的多路径，对硬件故障有更强的恢复能力，从而实现更高的主机可用性。

重要

只有在使用机器配置激活多路径时才支持，如下流程所述。它必须在 RHCOS 安装后启用。

重要

在 IBM Z 和 LinuxONE 上，只有在在安装过程中为其配置了集群时，才能启用多路径。如需更多信息，请参阅 Installing a cluster with z/VM on IBM Z and LinuxONE 中的 "Creating Red Hat Enterprise Linux CoreOS (RHCOS) machines" 部分。

先决条件

  • 您有一个正在运行的 OpenShift Container Platform 集群，它使用版本 4.7 或更高版本。
  • 您以具有管理特权的用户身份登录集群。

流程

  1. 要在 control plane 节点上启用多路径（也称为 master 节点）：

    • 创建机器配置文件，如 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
    Copy to Clipboard Toggle word wrap

  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
      Copy to Clipboard Toggle word wrap

  3. 使用之前创建的 master 或 worker YAML 文件创建新机器配置： 

    $ oc create -f ./99-master-kargs-mpath.yaml
    Copy to Clipboard Toggle word wrap

  4. 检查机器配置以查看是否添加了新配置： 

    $ oc get MachineConfig
    Copy to Clipboard Toggle word wrap

    输出示例

    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-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   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
    Copy to Clipboard Toggle word wrap

  5. 检查节点： 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                           STATUS                     ROLES    AGE   VERSION
ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.20.0
ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.20.0
ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.20.0
ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.20.0
ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.20.0
ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.20.0
    Copy to Clipboard Toggle word wrap

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

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

    $ oc debug node/ip-10-0-141-105.ec2.internal
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

    您应该看到添加的内核参数。

3.2.4. 在节点中添加实时内核
复制链接

一些 OpenShift Container Platform 工作负载需要高度确定性。虽然 Linux 不是实时操作系统，但 Linux 实时内核包含一个抢占调度程序，它为操作系统提供实时特征。

如果您的 OpenShift Container Platform 工作负载需要这些实时特征，您可以将机器切换到 Linux 实时内核。对于 OpenShift Container Platform 4.7，您可以使用 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
    Copy to Clipboard Toggle word wrap

  2. 将机器配置添加到集群。键入以下内容将机器配置添加到集群中： 

    $ oc create -f 99-worker-realtime.yaml
    Copy to Clipboard Toggle word wrap

  3. 检查实时内核： 每当受影响节点重新引导后，登录到集群，并运行以下命令来确保您配置的节点组中使用实时内核替换了常规内核： 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                        STATUS  ROLES    AGE   VERSION
ip-10-0-143-147.us-east-2.compute.internal  Ready   worker   103m  v1.20.0
ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.20.0
ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.20.0
    Copy to Clipboard Toggle word wrap 

    $ oc debug node/ip-10-0-143-147.us-east-2.compute.internal
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

    内核名称包含 rt 和 "PREMPT RT" 来表示这是一个实时内核。

  4. 要返回常规内核，请删除 MachineConfig 对象： 

    $ oc delete -f 99-worker-realtime.yaml
    Copy to Clipboard Toggle word wrap

3.2.5. 配置 journald 设置
复制链接

如果您需要在 OpenShift Container Platform 节点上配置 journald 服务设置，您可以修改适当的配置文件并将该文件作为机器配置传递给适当的节点池。

此流程描述了如何修改 /etc/systemd/journald.conf 文件中的 journald 限制设置并将其应用到 worker 节点。有关如何使用该文件的详情，请查看 journald.conf 手册页。

先决条件

  • 有一个正在运行的 OpenShift Container Platform 集群（版本 4.4 或更高版本）。
  • 以具有管理特权的用户身份登录集群。

流程

  1. 创建 /etc/systemd/journald.conf 文件的内容并将其编码为 base64。例如： 

    $ cat > /tmp/jrnl.conf <<EOF
# Disable rate limiting
RateLimitInterval=1s
RateLimitBurst=10000
Storage=volatile
Compress=no
MaxRetentionSec=30s
EOF
    Copy to Clipboard Toggle word wrap

  2. 将临时 journal.conf 文件转换为 base64 并将其保存到变量(jrnl_cnf): 

    $ export jrnl_cnf=$( cat /tmp/jrnl.conf | base64 -w0 )
$ echo $jrnl_cnf
IyBEaXNhYmxlIHJhdGUgbGltaXRpbmcKUmF0ZUxpbWl0SW50ZXJ2YWw9MXMKUmF0ZUxpbWl0QnVyc3Q9MTAwMDAKU3RvcmFnZT12b2xhdGlsZQpDb21wcmVzcz1ubwpNYXhSZXRlbnRpb25TZWM9MzBzCg==
    Copy to Clipboard Toggle word wrap

  3. 创建机器配置，包括经过编码的 journald.conf 内容（jrnl_cnf 变量）： 

    $ cat > /tmp/40-worker-custom-journald.yaml <<EOF
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 40-worker-custom-journald
spec:
  config:
    ignition:
      config: {}
      security:
        tls: {}
      timeouts: {}
      version: 3.1.0
    networkd: {}
    passwd: {}
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,${jrnl_cnf}
          verification: {}
        filesystem: root
        mode: 420
        path: /etc/systemd/journald.conf
    systemd: {}
  osImageURL: ""
EOF
    Copy to Clipboard Toggle word wrap

  4. 将机器配置应用到池： 

    $ oc apply -f /tmp/40-worker-custom-journald.yaml
    Copy to Clipboard Toggle word wrap

  5. 检查是否应用新机器配置，并且节点是否处于降级状态。它可能需要几分钟时间。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
    Copy to Clipboard Toggle word wrap

  6. 要检查是否应用了更改，您可以登录到 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
    Copy to Clipboard Toggle word wrap

3.2.6. 为 RHCOS 添加扩展
复制链接

RHCOS 是基于容器的最小 RHEL 操作系统,旨在为所有平台的 OpenShift Container Platform 集群提供一组通用的功能。通常不建议在 RHCOS 系统中添加软件软件包，但 MCO 提供了一个 extensions（扩展） 功能，您可以使用 MCO 为 RHCOS 节点添加一组最小的功能。

目前，提供了以下扩展程序：

  • usbguard：添加 usbguard 扩展可保护 RHCOS 系统不受入侵 USB 设备的攻击。详情请查看 USBGuard。

以下流程描述了如何使用机器配置为 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
    Copy to Clipboard Toggle word wrap

  2. 将机器配置添加到集群。键入以下内容将机器配置添加到集群中： 

    $ oc create -f 80-extensions.yaml
    Copy to Clipboard Toggle word wrap

    这会将所有 worker 节点设置为安装 usbguard 的 rpm 软件包。

  3. 检查是否应用了扩展： 

    $ oc get machineconfig 80-worker-extensions
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
80-worker-extensions                       3.2.0           57s
    Copy to Clipboard Toggle word wrap

  4. 检查是否应用新机器配置，并且节点是否处于降级状态。它可能需要几分钟时间。worker 池将显示更新进行中，每台机器都成功应用了新机器配置： 

    $ oc get machineconfigpool
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

  5. 检查扩展。要检查是否应用了扩展，请运行： 

    $ oc get node | grep worker
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                        STATUS  ROLES    AGE   VERSION
ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.18.3
    Copy to Clipboard Toggle word wrap 

    $ oc debug node/ip-10-0-169-2.us-east-2.compute.internal
    Copy to Clipboard Toggle word wrap

    输出示例

    ...
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
    Copy to Clipboard Toggle word wrap

3.2.7. 在机器配置清单中载入自定义固件 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.9.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
    Copy to Clipboard Toggle word wrap

    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>
    Copy to Clipboard Toggle word wrap

  3. 通过两种方式之一将配置应用到节点：

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

    • 如果集群已在运行，请应用该文件： 

      $ oc apply -f 98-worker-firmware-blob.yaml
      Copy to Clipboard Toggle word wrap

      已创建一个 MachineConfig 对象 YAML 文件，供您完成机器配置。

  4. 保存 Butane 的配置，以便以后可能需要更新 MachineConfig 对象。

3.3. 配置 MCO 相关的自定义资源
复制链接

除了管理 MachineConfig 对象外，MCO 管理两个自定义资源（CR）：KubeletConfig 和 ContainerRuntimeConfig。这些 CR 可让您更改节点级别的设置，这会影响到 Kubelet 和 CRI-O 容器运行时服务的行为。

3.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，带有该池需要更改的所有配置。如果要将相同的内容应用到所有池，则所有池仅需要一个 KubeletConfig CR。
  • 编辑现有的 KubeletConfig CR 以修改现有设置或添加新设置，而不是为每个更改创建一个 CR。建议您仅创建一个 CR 来修改不同的机器配置池，或用于临时更改，以便您可以恢复更改。
  • 根据需要，创建多个 KubeletConfig CR，每个集群限制为 10。对于第一个 KubeletConfig CR，Machine Config Operator (MCO) 会创建一个机器配置，并附带 kubelet。对于每个后续 CR，控制器会创建另一个带有数字后缀的 kubelet 机器配置。例如，如果您有一个带有 -2 后缀的 kubelet 机器配置，则下一个 kubelet 机器配置会附加 -3。

如果要删除机器配置，以相反的顺序删除它们，以避免超过限制。例如，在删除 kubelet-2 机器配置前删除 kubelet-3 机器配置。

注意

如果您有一个带有 kubelet-9 后缀的机器配置，并且创建了另一个 KubeletConfig CR，则不会创建新的机器配置，即使少于 10 个 kubelet 机器配置。

KubeletConfig CR 示例

$ oc get kubeletconfig
Copy to Clipboard Toggle word wrap 

NAME                AGE
set-max-pods        15m
Copy to Clipboard Toggle word wrap

显示 KubeletConfig 机器配置示例

$ oc get mc | grep kubelet
Copy to Clipboard Toggle word wrap 

...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
...
Copy to Clipboard Toggle word wrap

以下流程演示了如何配置 worker 节点上的每个节点的最大 pod 数量。

先决条件

  1. 为您要配置的节点类型获取与静态 MachineConfigPool CR 关联的标签。执行以下步骤之一：

    1. 查看机器配置池： 

      $ oc describe machineconfigpool <name>
      Copy to Clipboard Toggle word wrap

      例如： 

      $ oc describe machineconfigpool worker
      Copy to Clipboard Toggle word wrap

      输出示例

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: 2019-02-08T14:52:39Z
  generation: 1
  labels:
    custom-kubelet: set-max-pods
      1
      Copy to Clipboard Toggle word wrap

      1
      如果添加了标签，它会出现在 labels 下。

    2. 如果标签不存在，则添加一个键/值对： 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods
      Copy to Clipboard Toggle word wrap

流程

  1. 查看您可以选择的可用机器配置对象： 

    $ oc get machineconfig
    Copy to Clipboard Toggle word wrap

    默认情况下，与 kubelet 相关的配置为 01-master-kubelet 和 01-worker-kubelet。

  2. 检查每个节点的最大 pod 的当前值： 

    $ oc describe node <node_name>
    Copy to Clipboard Toggle word wrap

    例如： 

    $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94
    Copy to Clipboard Toggle word wrap

    在 Allocatable 小节中找到 value: pods: <value>：

    输出示例

    Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         3500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      15341844Ki
 pods:                        250
    Copy to Clipboard Toggle word wrap

  3. 通过创建一个包含 kubelet 配置的自定义资源文件，设置 worker 节点上的每个节点的最大 pod： 

    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
    Copy to Clipboard Toggle word wrap
    1
    输入机器配置池中的标签。
    2
    添加 kubelet 配置。在本例中，使用 maxPods 设置每个节点的最大 pod。
    注意

    kubelet 与 API 服务器进行交互的频率取决于每秒的查询数量 (QPS) 和 burst 值。如果每个节点上运行的 pod 数量有限，使用默认值（kubeAPIQPS 为 50，kubeAPIBurst 为 100）就可以。如果节点上有足够 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>
    Copy to Clipboard Toggle word wrap

    1. 为带有标签的 worker 更新机器配置池： 

      $ oc label machineconfigpool worker custom-kubelet=large-pods
      Copy to Clipboard Toggle word wrap

    2. 创建 KubeletConfig 对象： 

      $ oc create -f change-maxPods-cr.yaml
      Copy to Clipboard Toggle word wrap

    3. 验证 KubeletConfig 对象是否已创建： 

      $ oc get kubeletconfig
      Copy to Clipboard Toggle word wrap

      输出示例

      NAME                AGE
set-max-pods        15m
      Copy to Clipboard Toggle word wrap

      根据集群中的 worker 节点数量，等待每个 worker 节点被逐个重启。对于有 3 个 worker 节点的集群，这个过程可能需要大约 10 到 15 分钟。

  4. 验证更改是否已应用到节点：

    1. 在 worker 节点上检查 maxPods 值已更改： 

      $ oc describe node <node_name>
      Copy to Clipboard Toggle word wrap

    2. 找到 Allocatable 小节： 

       ...
Allocatable:
  attachable-volumes-gce-pd:  127
  cpu:                        3500m
  ephemeral-storage:          123201474766
  hugepages-1Gi:              0
  hugepages-2Mi:              0
  memory:                     14225400Ki
  pods:                       500
      1 
      
 ...
      Copy to Clipboard Toggle word wrap
      1
      在本例中，pods 参数应报告您在 KubeletConfig 对象中设置的值。

  5. 验证 KubeletConfig 对象中的更改： 

    $ oc get kubeletconfigs set-max-pods -o yaml
    Copy to Clipboard Toggle word wrap

    这应该会显示 status: "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
    Copy to Clipboard Toggle word wrap

您可以为与特定机器配置池（MCP）关联的节点更改与 OpenShift Container Platform CRI-O 运行时关联的一些设置。通过使用 ContainerRuntimeConfig 自定义资源（CR），您可以设置配置值并添加一个标签以匹配 MCP。然后，MCO 会使用更新的值重建关联节点上的 crio.conf 和 storage.conf 配置文件。

注意

要使用 ContainerRuntimeConfig CR 恢复实现的更改，您必须删除 CR。从机器配置池中删除标签不会恢复更改。

您可以使用 ContainerRuntimeConfig CR 修改以下设置：

  • PIDs limit：pidsLimit 参数设置 CRI-O pids_limit 参数，这是容器中允许的最大进程数。默认为 1024（pids_limit = 1024）。
  • 日志级别: logLevel 参数设置 CRI-O log_level 参数，即日志消息的详细程度。默认为 info (log_level = info)。其他选项包括 fatal、panic、error、warn、debug 和 trace。
  • Overlay 大小：overlaySize 参数设置 CRI-O Overlay 存储驱动程序 size 参数，这是容器镜像的最大大小。
  • 最大日志大小：logSizeMax 参数设置 CRI-O log_size_max 参数，这是容器日志文件允许的最大值。默认为没有限制（log_size_max = -1）。如果设置为正数，则必须至少小于 ConMon 读取缓冲的 8192。conMon 是一个监控单个容器管理器（如 Podman 或 CRI-O）与 OCI 运行时（如 runc 或 crun）之间的通信的程序。

您应该为每个机器配置池有一个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
Copy to Clipboard Toggle word wrap

输出示例

NAME         AGE
ctr-pid      24m
ctr-overlay  15m
ctr-level    5m45s
Copy to Clipboard Toggle word wrap

显示多个 containerruntime 机器配置示例

$ oc get mc | grep container
Copy to Clipboard Toggle word wrap

输出示例

...
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
...
Copy to Clipboard Toggle word wrap

以下示例将 pids_limit 增加到 2048，将 log_level 设置为 debug，将覆盖大小设置为 8 GB，并将 log_size_max 设置为无限：

ContainerRuntimeConfig CR 示例

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: ''
1 

 containerRuntimeConfig:
   pidsLimit: 2048
2 

   logLevel: debug
3 

   overlaySize: 8G
4 

   logSizeMax: "-1"
5
Copy to Clipboard Toggle word wrap

1
指定机器配置池标签。
2
可选：指定容器中允许的最大进程数。
3
可选：指定日志消息的详细程度。
4
可选：指定容器镜像的最大大小。
5
可选：指定容器日志文件允许的最大大小。如果设置为正数，则必须至少为 8192。

流程

使用 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 
    
   pidsLimit: 2048
   logLevel: debug
   overlaySize: 8G
   logSizeMax: "-1"
    Copy to Clipboard Toggle word wrap
    1
    为您要修改的机器配置池指定一个标签。
    2
    根据需要设置参数。

  2. 创建 ContainerRuntimeConfig CR： 

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap

  3. 验证是否已创建 CR： 

    $ oc get ContainerRuntimeConfig
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME           AGE
overlay-size   3m19s
    Copy to Clipboard Toggle word wrap

  4. 检查是否创建了新的 containerruntime 机器配置： 

    $ oc get machineconfigs | grep containerrun
    Copy to Clipboard Toggle word wrap

    输出示例

    99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s
    Copy to Clipboard Toggle word wrap

  5. 监控机器配置池，直到所有系统都显示为 ready 状态： 

    $ oc get mcp worker
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h
    Copy to Clipboard Toggle word wrap

  6. 验证设置是否在 CRI-O 中应用：

    1. 打开到机器配置池中节点的 oc debug 会话，并运行 chroot /host。 

      $ oc debug node/<node_name>
      Copy to Clipboard Toggle word wrap 
      sh-4.4# chroot /host
      Copy to Clipboard Toggle word wrap

    2. 验证 crio.conf 文件中的更改： 

      sh-4.4# crio config | egrep 'log_level|pids_limit|log_size_max'
      Copy to Clipboard Toggle word wrap

      输出示例

      pids_limit = 2048
log_size_max = -1
log_level = "debug"
      Copy to Clipboard Toggle word wrap

    3. 验证 'storage.conf' 文件中的更改： 

      sh-4.4# head -n 7 /etc/containers/storage.conf
      Copy to Clipboard Toggle word wrap

      输出示例

      [storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"
      Copy to Clipboard Toggle word wrap

每个容器的根分区显示底层主机的所有可用磁盘空间。按照以下说明，为所有容器的 root 磁盘设置最大分区大小。

要配置最大 Overlay 大小，以及其他 CRI-O 选项，如日志级别和 PID 限制，您可以创建以下 ContainerRuntimeConfig 自定义资源定义（CRD）： 

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     custom-crio: overlay-size
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug
   overlaySize: 8G
Copy to Clipboard Toggle word wrap

流程

  1. 创建配置对象： 

    $ oc apply -f overlaysize.yml
    Copy to Clipboard Toggle word wrap

  2. 要将新的 CRI-O 配置应用到 worker 节点，请编辑 worker 机器配置池： 

    $ oc edit machineconfigpool worker
    Copy to Clipboard Toggle word wrap

  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: ""
    Copy to Clipboard Toggle word wrap

  4. 保存更改，然后查看机器配置： 

    $ oc get machineconfigs
    Copy to Clipboard Toggle word wrap

    新的 99-worker-generated-containerruntime 和 rendered-worker-xyz 对象被创建：

    输出示例

    99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s
    Copy to Clipboard Toggle word wrap

  5. 创建这些对象后，监控机器配置池以了解要应用的更改： 

    $ oc get mcp worker
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    完成后，worker 节点会从 UPDATING 转换回 False，UPDATEDMACHINECOUNT 数与 MACHINECOUNT 数匹配：

    输出示例

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-xyz   True      False      False      3         3            3             0           20h
    Copy to Clipboard Toggle word wrap

    查看 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"
    Copy to Clipboard Toggle word wrap

    在容器内，您会看到 root 分区现在为 8 GB：

    输出示例

    ~ $ df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                   8.0G      8.0K      8.0G   0% /
    Copy to Clipboard Toggle word wrap

第 4 章 安装后集群任务
复制链接

安装 OpenShift Container Platform 后，您可以按照自己的要求进一步扩展和自定义集群。

4.1. 可用的集群自定义
复制链接

大多数集群配置和自定义在 OpenShift Container Platform 集群部署后完成。有若干配置资源可用。

注意

如果在 IBM Z 上安装集群，则不是所有功能都可用。

您可以修改配置资源来配置集群的主要功能，如镜像 registry、网络配置、镜像构建操作以及用户身份供应商。

如需设置这些资源的当前信息，请使用 oc explain 命令，如 oc explain builds --api-version=config.openshift.io/v1

4.1.1. 集群配置资源
复制链接

所有集群配置资源都作用于全局范围（而非命名空间），且命名为 cluster。

Expand
资源名称描述

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

配置调度程序行为，如策略和默认节点选择器。

4.1.2. Operator 配置资源
复制链接

这些配置资源是集群范围的实例，即 cluster，控制归特定 Operator 所有的特定组件的行为。

Expand
资源名称描述

consoles.operator.openshift.io

控制控制台外观，如品牌定制

config.imageregistry.operator.openshift.io

配置内部镜像 registry 设置，如公共路由、日志级别、代理设置、资源约束、副本数和存储类型。

config.samples.operator.openshift.io

配置 Samples Operator，以控制在集群上安装哪些镜像流和模板示例。

4.1.3. 其他配置资源
复制链接

这些配置资源代表一个特定组件的单一实例。在有些情况下，您可以通过创建多个资源实例来请求多个实例。在其他情况下，Operator 只消耗指定命名空间中的特定资源实例名称。如需有关如何和何时创建其他资源实例的详情，请参考具体组件的文档。

Expand
资源名称实例名称命名空间描述

alertmanager.monitoring.coreos.com

main

openshift-monitoring

控制 Alertmanager 部署参数。

ingresscontroller.operator.openshift.io

default

openshift-ingress-operator

配置 Ingress Operator 行为，如域、副本数、证书和控制器放置。

4.1.4. 信息资源
复制链接

可以使用这些资源检索集群信息。有些配置可能需要您直接编辑这些资源。

Expand
资源名称实例名称描述

clusterversion.config.openshift.io

version

在 OpenShift Container Platform 4.7 中，不得自定义生产集群的 ClusterVersion 资源。相反，请按照 更新集群的流程 进行操作。

dns.config.openshift.io

cluster

无法修改集群的 DNS 设置。您可以查看 DNS Operator 状态。

infrastructure.config.openshift.io

cluster

允许集群与其云供应商交互的配置详情。

network.config.openshift.io

cluster

无法在安装后修改集群网络。要自定义您的网络，请遵循相关的流程在安装过程中自定义联网。

4.2. 更新全局集群 pull secret
复制链接

您可以通过替换当前的 pull secret 或附加新的 pull secret 来更新集群的全局 pull secret。

当用户使用单独的 registry 存储镜像时，需要这个过程，而不是在安装过程中使用的 registry。

警告

集群资源必须调整为新的 pull secret，这样可暂时限制集群的可用性。

先决条件

  • 您可以使用具有 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
      Copy to Clipboard Toggle word wrap
      1
      提供 pull secret 文件的路径。

    2. 输入以下命令来添加新 pull secret： 

      $ oc registry login --registry="<registry>" \
      1 
      
--auth-basic="<username>:<password>" \
      2 
      
--to=<pull_secret_location>
      3
      Copy to Clipboard Toggle word wrap
      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
    Copy to Clipboard Toggle word wrap
    1
    提供新 pull secret 文件的路径。

    该更新将推广至所有节点，可能需要一些时间，具体取决于集群大小。

    注意

    从 OpenShift Container Platform 4.7.4 开始，对全局 pull secret 的更改不再触发节点排空或重启。

4.3. 调整 worker 节点
复制链接

如果您在部署过程中错误地定义了 worker 节点的大小，可以通过创建一个或多个新机器集来调整它们，先对它们进行扩展，并缩小原始的机器集，然后再删除它们。

4.3.1. 了解机器集和机器配置池之间的区别
复制链接

MachineSet 对象描述了与云或机器供应商相关的 OpenShift Container Platform 节点。

MachineConfigPool 对象允许 MachineConfigController 组件在升级过程中定义并提供机器的状态。

MachineConfigPool 对象允许用户配置如何将升级应用到机器配置池中的 OpenShift Container Platform 节点。

NodeSelector 对象可以被一个到 MachineSet 对象的引用替换。

4.3.2. 手动扩展机器集
复制链接

要在机器集中添加或删除机器实例，您可以手动扩展机器集。

这个指南与全自动的、安装程序置备的基础架构安装相关。自定义的、用户置备的基础架构安装没有机器集。

先决条件

  • 安装 OpenShift Container Platform 集群和 oc 命令行。
  • 以具有 cluster-admin 权限的用户身份登录 oc。

流程

  1. 查看集群中的机器集： 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    机器集以 <clusterid>-worker-<aws-region-az> 的形式列出。

  2. 查看集群中的机器： 

    $ oc get machine -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 在您要删除的机器上设置注解： 

    $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/cluster-api-delete-machine="true"
    Copy to Clipboard Toggle word wrap

  4. cordon 并排空您要删除的节点： 

    $ oc adm cordon <node_name>
$ oc adm drain <node_name>
    Copy to Clipboard Toggle word wrap

  5. 扩展机器集： 

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    或者： 

    $ oc edit machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    您可以扩展或缩减机器集。需要过几分钟以后新机器才可用。

验证

  • 验证删除预期的机器： 

    $ oc get machines
    Copy to Clipboard Toggle word wrap

4.3.3. 机器集删除策略
复制链接

Random、Newest 和 Oldest 是三个支持的删除选项。默认值为 Random，表示在扩展机器时随机选择并删除机器。通过修改特定机器集，可以根据用例设置删除策略： 

spec:
  deletePolicy: <delete_policy>
  replicas: <desired_replica_count>
Copy to Clipboard Toggle word wrap

无论删除策略是什么，都可通过在相关机器上添加 machine.openshift.io/cluster-api-delete-machine=true 注解来指定机器删除的优先级。

重要

默认情况下，OpenShift Container Platform 路由器 Pod 部署在 worker 上。由于路由器需要访问某些集群资源（包括 Web 控制台），除非先重新放置了路由器 Pod，否则请不要将 worker 机器集扩展为 0。

注意

当用户需要特定的服务必须运行在特定节点，在 worker 机器集进行缩减时需要忽略这些服务时，可以使用自定义机器集。这可防止服务被中断。

4.3.4. 创建默认的集群范围节点选择器
复制链接

您可以组合使用 pod 上的默认集群范围节点选择器和节点上的标签，将集群中创建的所有 pod 限制到特定节点。

使用集群范围节点选择器时，如果您在集群中创建 pod,OpenShift Container Platform 会将默认节点选择器添加到 pod，并将该 pod 调度到具有匹配标签的节点。

您可以通过编辑调度程序 Operator 自定义资源（CR）来配置集群范围节点选择器。您可为节点、机器集或机器配置添加标签。将标签添加到机器集可确保节点或机器停机时，新节点具有标签。如果节点或机器停机，添加到节点或机器配置的标签不会保留。

注意

您可以向 pod 添加额外的键/值对。但是，您无法为一个默认的键添加不同的值。

流程

添加默认的集群范围节点选择器：

  1. 编辑调度程序 Operator CR 以添加默认的集群范围节点选择器： 

    $ oc edit scheduler cluster
    Copy to Clipboard Toggle word wrap

    使用节点选择器的调度程序 Operator CR 示例

    apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
...

spec:
  defaultNodeSelector: type=user-node,region=east
    1 
    
  mastersSchedulable: false
  policy:
    name: ""
    Copy to Clipboard Toggle word wrap

    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
        Copy to Clipboard Toggle word wrap
        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
        Copy to Clipboard Toggle word wrap

      2. 使用 oc edit 命令验证标签是否已添加到 MachineSet 对象中：

        例如： 

        $ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

        输出示例

        apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
...
spec:
...
  template:
    metadata:
...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
        Copy to Clipboard Toggle word wrap

      3. 通过缩减至 0 并扩展节点来重新部署与该机器集关联的节点：

        例如： 

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap 
        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

      4. 当节点就绪并可用时，使用 oc get 命令验证该标签是否已添加到节点： 

        $ oc get nodes -l <key>=<value>
        Copy to Clipboard Toggle word wrap

        例如： 

        $ oc get nodes -l type=user-node
        Copy to Clipboard Toggle word wrap

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.18.3+002a51f
        Copy to Clipboard Toggle word wrap

    • 直接向节点添加标签：

      1. 为节点编辑 Node 对象： 

        $ oc label nodes <name> <key>=<value>
        Copy to Clipboard Toggle word wrap

        例如，若要为以下节点添加标签： 

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east
        Copy to Clipboard Toggle word wrap

      2. 使用 oc get 命令验证标签是否已添加到节点： 

        $ oc get nodes -l <key>=<value>,<key>=<value>
        Copy to Clipboard Toggle word wrap

        例如： 

        $ oc get nodes -l type=user-node,region=east
        Copy to Clipboard Toggle word wrap

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.18.3+002a51f
        Copy to Clipboard Toggle word wrap

4.4. 为生产环境创建基础架构机器集
复制链接

您可以创建一个机器集来创建仅托管基础架构组件的机器，如默认路由器、集成容器镜像 registry 和用于集群指标和监控的组件。这些基础架构机器不计入运行环境所需的订阅总数中。

在生产部署中，建议您至少部署三个机器集来容纳基础架构组件。OpenShift Logging 和 Red Hat OpenShift Service Mesh 部署 Elasticsearch，这需要三个实例安装到不同的节点上。这些节点可以部署到不同的可用区，以实现高可用性。这样的配置需要三个不同的计算机集，每个可用区对应一个。在没有多个可用区的全局 Azure 区域，您可以使用可用性集来确保高可用性。

有关基础架构节点以及可以在基础架构节点上运行的组件的信息，请参阅 创建基础架构机器集。

有关可用于这些步骤的机器集示例，请参阅 为不同的云创建机器集。

4.4.1. 创建机器集
复制链接

除了安装程序创建的机器集之外，还可创建自己的机器集来动态管理您选择的特定工作负载的机器计算资源。

先决条件

  • 部署一个 OpenShift Container Platform 集群。
  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 权限的用户身份登录 oc。

流程

  1. 创建一个包含机器集自定义资源（CR）示例的新 YAML 文件，并将其命名为 <file_name>.yaml。

    确保设置 <clusterID> 和 <role> 参数值。

    1. 如果您不确定要为特定字段设置哪个值，您可以从集群中检查现有机器集： 

      $ oc get machinesets -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      Copy to Clipboard Toggle word wrap

    2. 检查特定机器集的值： 

      $ oc get machineset <machineset_name> -n \
     openshift-machine-api -o yaml
      Copy to Clipboard Toggle word wrap

      输出示例

      ...
template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: agl030519-vplxk
      1 
      
        machine.openshift.io/cluster-api-machine-role: worker
      2 
      
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: agl030519-vplxk-worker-us-east-1a
      Copy to Clipboard Toggle word wrap

      1
      集群 ID。
      2
      默认节点标签。

  2. 创建新的 MachineSet CR: 

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap

  3. 查看机器集列表： 

    $ oc get machineset -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

    当新机器集可用时，DESIRED 和 CURRENT 的值会匹配。如果机器集不可用，请等待几分钟，然后再次运行命令。

4.4.2. 创建基础架构节点
复制链接

重要

请参阅为安装程序置备的基础架构环境创建基础架构机器集，或为 control plane 节点（也称为 master 节点）由机器 API 管理的任何集群创建基础架构机器集。

集群的基础架构系统（也称为 infra 节点）的要求已被置备。安装程序只为 control plane 和 worker 节点提供置备。Worker 节点可以通过标记来指定为基础架构节点或应用程序（也称为 app ）。

流程

  1. 向您要充当应用程序节点的 worker 节点添加标签： 

    $ oc label node <node-name> node-role.kubernetes.io/app=""
    Copy to Clipboard Toggle word wrap

  2. 向您要充当基础架构节点的 worker 节点添加标签： 

    $ oc label node <node-name> node-role.kubernetes.io/infra=""
    Copy to Clipboard Toggle word wrap

  3. 检查相关节点现在是否具有 infra 角色或 app 角色： 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  4. 创建默认的集群范围节点选择器。默认节点选择器应用到在所有命名空间中创建的 pod。这会创建一个与 pod 上任何现有节点选择器交集的交集，这会额外限制 pod 的选择器。

    重要

    如果默认节点选择器键与 pod 标签的键冲突，则不会应用默认节点选择器。

    但是，不要设置可能会导致 pod 变得不可调度的默认节点选择器。例如，当 pod 的标签被设置为不同的节点角色（如 node-role.kubernetes.io/infra=""）时，将默认节点选择器设置为特定的节点角色（如 node-role.kubernetes.io/master=""）可能会导致 pod 无法调度。因此，将默认节点选择器设置为特定节点角色时要小心。

    您还可以使用项目节点选择器来避免集群范围节点选择器键冲突。

    1. 编辑 Scheduler 对象： 

      $ oc edit scheduler cluster
      Copy to Clipboard Toggle word wrap

    2. 使用适当的节点选择器添加 defaultNodeSelector 字段： 

      apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
...
spec:
  defaultNodeSelector: topology.kubernetes.io/region=us-east-1
      1 
      
...
      Copy to Clipboard Toggle word wrap
      1
      默认情况下，此节点选择器示例将容器集部署到 us-east-1 区域的节点。
    3. 保存文件以使改变生效。

现在，您可以将基础架构资源移到新标记的 infra 节点。

4.4.3. 为基础架构机器创建机器配置池
复制链接

如果需要基础架构机器具有专用配置，则必须创建一个 infra 池。

流程

  1. 向您要分配为带有特定标签的 infra 节点的节点添加标签： 

    $ oc label node <node_name> <label>
    Copy to Clipboard Toggle word wrap 
    $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=
    Copy to Clipboard Toggle word wrap

  2. 创建包含 worker 角色和自定义角色作为机器配置选择器的机器配置池： 

    $ cat infra.mcp.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

    1
    添加 worker 角色和自定义角色。
    2
    将您添加的标签作为 nodeSelector 添加到节点。
    注意

    自定义机器配置池从 worker 池中继承机器配置。自定义池使用任何针对 worker 池的机器配置，但增加了部署仅针对自定义池的更改的功能。由于自定义池从 worker 池中继承资源，对 worker 池的任何更改也会影响自定义池。

  3. 具有 YAML 文件后，您可以创建机器配置池： 

    $ oc create -f infra.mcp.yaml
    Copy to Clipboard Toggle word wrap

  4. 检查机器配置，以确保基础架构配置成功： 

    $ oc get machineconfig
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

    您应该会看到一个新的机器配置，带有 rendered-infra-* 前缀。

  5. 可选：要部署对自定义池的更改，请创建一个机器配置，该配置使用自定义池名称作为标签，如本例中的 infra：请注意，这不是必须的，在此包括仅用于指示目的。这样，您可以只应用特定于 infra 节点的任何自定义配置。

    注意

    创建新机器配置池后，MCO 会为该池生成一个新的呈现配置，以及该池重启的关联节点以应用新配置。

    1. 创建机器配置： 

      $ cat infra.mc.yaml
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      Copy to Clipboard Toggle word wrap

      1
      将您添加的标签作为 nodeSelector 添加到节点。

    2. 将机器配置应用到 infra-labeled 节点： 

      $ oc create -f infra.mc.yaml
      Copy to Clipboard Toggle word wrap

  6. 确认您的新机器配置池可用： 

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

    在本例中，worker 节点被改为一个 infra 节点。

4.5. 为基础架构节点分配机器设置资源
复制链接

在创建了基础架构机器集后，worker 和 infra 角色将应用到新的 infra 节点。具有 infra 角色的节点不会计入运行环境所需的订阅总数中，即使也应用了 worker 角色。

但是，当为 infra 节点分配 worker 角色时，用户工作负载可能会意外地分配给 infra 节点。要避免这种情况，您可以将污点应用到 infra 节点，并为您要控制的 pod 应用容限。

如果您有一个分配了 infra 和 worker 角色的 infra 节点，您必须配置该节点，以便不为其分配用户工作负载。

重要

建议您保留为 infra 节点创建的双 infra,worker 标签，并使用污点和容限来管理用户工作负载调度到的节点。如果从节点中删除 worker 标签，您必须创建一个自定义池来管理它。没有自定义池的 MCO 不能识别具有 master 或 worker 以外的标签的节点。如果不存在选择自定义标签的自定义池，维护 worker 标签可允许默认 worker 机器配置池管理节点。infra 标签与集群通信，它不计算订阅总数。

先决条件

  • 在 OpenShift Container Platform 集群中配置额外的 MachineSet 对象。

流程

  1. 向 infra 节点添加污点以防止在其上调度用户工作负载：

    1. 确定节点是否具有污点： 

      $ oc describe nodes <node_name>
      Copy to Clipboard Toggle word wrap

      输出示例

      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
 ...
      Copy to Clipboard Toggle word wrap

      本例显示节点具有污点。您可以在下一步中继续向 pod 添加容限。

    2. 如果您还没有配置污点以防止在其上调度用户工作负载： 

      $ oc adm taint nodes <node_name> <key>:<effect>
      Copy to Clipboard Toggle word wrap

      例如： 

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra:NoSchedule
      Copy to Clipboard Toggle word wrap

      本例在 node1 上放置一个键为 node-role.kubernetes.io/infra 的污点，污点是 NoSchedule。具有 NoSchedule effect 的节点仅调度容许该污点的 pod，但允许现有 pod 继续调度到该节点上。

      注意

      如果使用 descheduler，则违反了节点污点的 pod 可能会从集群驱除。

  2. 为要在 infra 节点上调度的 pod 配置添加容限，如路由器、registry 和监控工作负载。在 Pod 对象规格中添加以下代码： 

    tolerations:
  - effect: NoSchedule
    1 
    
    key: node-role.kubernetes.io/infra
    2 
    
    operator: Exists
    3
    Copy to Clipboard Toggle word wrap
    1
    指定添加到节点的效果。
    2
    指定添加到节点的键。
    3
    指定 Exists Operator，以要求节点上存在一个带有键为 node-role.kubernetes.io/infra 的污点。

    此容忍度与 oc adm taint 命令创建的污点匹配。具有此容忍度的 pod 可以调度到 infra 节点上。

    注意

    并不总是能够将通过 OLM 安装的 Operator 的 Pod 移到 infra 节点。移动 Operator Pod 的能力取决于每个 Operator 的配置。

  3. 使用调度程序将 pod 调度到 infra 节点。详情请参阅控制节点上的 pod 放置的文档。

4.6. 将资源移到基础架构机器集
复制链接

默认情况下，您的集群中已部署了某些基础架构资源。您可将它们移至您创建的基础架构机器集。

4.6.1. 移动路由器
复制链接

您可以将路由器 pod 部署到不同的机器集中。默认情况下，pod 部署到 worker 节点。

先决条件

  • 在 OpenShift Container Platform 集群中配置额外的机器集。

流程

  1. 查看路由器 Operator 的 IngressController 自定义资源： 

    $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml
    Copy to Clipboard Toggle word wrap

    命令输出类似于以下文本： 

    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
    Copy to Clipboard Toggle word wrap

  2. 编辑 ingresscontroller 资源，并更改 nodeSelector 以使用infra 标签： 

    $ oc edit ingresscontroller default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap

    在 spec 中添加使用 infra 标签的 nodeSelector 的部分，如下所示： 

      spec:
    nodePlacement:
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/infra: ""
    Copy to Clipboard Toggle word wrap

  3. 确认路由器 Pod 在 infra 节点上运行。

    1. 查看路由器 Pod 列表，并记下正在运行的 Pod 的节点名称： 

      $ oc get pod -n openshift-ingress -o wide
      Copy to Clipboard Toggle word wrap

      输出示例

      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>
      Copy to Clipboard Toggle word wrap

      在本例中，正在运行的 Pod 位于 ip-10-0-217-226.ec2.internal 节点上。

    2. 查看正在运行的 Pod 的节点状态： 

      $ oc get node <node_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      指定从 Pod 列表获得的 <node_name>。

      输出示例

      NAME                          STATUS  ROLES         AGE   VERSION
ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.20.0
      Copy to Clipboard Toggle word wrap

      由于角色列表包含 infra，因此 Pod 在正确的节点上运行。

4.6.2. 移动默认 registry
复制链接

您需要配置 registry Operator，以便将其 Pod 部署到其他节点。

先决条件

  • 在 OpenShift Container Platform 集群中配置额外的机器集。

流程

  1. 查看 config/instance 对象： 

    $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    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:
...
    Copy to Clipboard Toggle word wrap

  2. 编辑 config/instance 对象： 

    $ oc edit configs.imageregistry.operator.openshift.io/cluster
    Copy to Clipboard Toggle word wrap

  3. 修改对象的 spec 部分，使其类似以下 YAML： 

    spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          namespaces:
          - openshift-image-registry
          topologyKey: kubernetes.io/hostname
        weight: 100
  logLevel: Normal
  managementState: Managed
  nodeSelector:
    node-role.kubernetes.io/infra: ""
    Copy to Clipboard Toggle word wrap

  4. 验证 registry pod 已移至基础架构节点。

    1. 运行以下命令，以识别 registry pod 所在的节点： 

      $ oc get pods -o wide -n openshift-image-registry
      Copy to Clipboard Toggle word wrap

    2. 确认节点具有您指定的标签： 

      $ oc describe node <node_name>
      Copy to Clipboard Toggle word wrap

      查看命令输出，并确认 node-role.kubernetes.io/infra 列在 LABELS 列表中。

4.6.3. 移动监控解决方案
复制链接

默认情况下，部署包含 Prometheus、Grafana 和 AlertManager 的 Prometheus Cluster Monitoring 堆栈来提供集群监控功能。它由 Cluster Monitoring Operator 进行管理。若要将其组件移到其他机器上，需要创建并应用自定义配置映射。

流程

  1. 将以下 ConfigMap 定义保存为 cluster-monitoring-configmap.yaml 文件： 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |+
    alertmanagerMain:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    prometheusK8s:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    prometheusOperator:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    grafana:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    k8sPrometheusAdapter:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    kubeStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    telemeterClient:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    openshiftStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    thanosQuerier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    Copy to Clipboard Toggle word wrap

    运行此配置映射会强制将监控堆栈的组件重新部署到基础架构节点。

  2. 应用新的配置映射： 

    $ oc create -f cluster-monitoring-configmap.yaml
    Copy to Clipboard Toggle word wrap

  3. 观察监控 pod 移至新机器： 

    $ watch 'oc get pod -n openshift-monitoring -o wide'
    Copy to Clipboard Toggle word wrap

  4. 如果组件没有移到 infra 节点，请删除带有这个组件的 pod: 

    $ oc delete pod -n openshift-monitoring <pod>
    Copy to Clipboard Toggle word wrap

    已删除 pod 的组件在 infra 节点上重新创建。

4.6.4. 移动 OpenShift Logging 资源
复制链接

您可以配置 Cluster Logging Operator，将 OpenShift Logging 组件（如 Elasticsearch 和 Kibana）的 pod 部署到不同的节点上。您无法将 Cluster Logging Operator Pod 从其安装位置移走。

例如，您可以因为 CPU、内存和磁盘要求较高而将 Elasticsearch Pod 移到一个单独的节点上。

先决条件

  • 必须安装 OpenShift Logging 和 Elasticsearch。默认情况下没有安装这些功能。

流程

  1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）： 

    $ oc edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap 
    apiVersion: logging.openshift.io/v1
kind: ClusterLogging

...

spec:
  collection:
    logs:
      fluentd:
        resources: null
      type: fluentd
  logStore:
    elasticsearch:
      nodeCount: 3
      nodeSelector:
    1 
    
        node-role.kubernetes.io/infra: ''
      redundancyPolicy: SingleRedundancy
      resources:
        limits:
          cpu: 500m
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      storage: {}
    type: elasticsearch
  managementState: Managed
  visualization:
    kibana:
      nodeSelector:
    2 
    
        node-role.kubernetes.io/infra: ''
      proxy:
        resources: null
      replicas: 1
      resources: null
    type: kibana

...
    Copy to Clipboard Toggle word wrap
1 2
添加 nodeSelector 参数，并设为适用于您想要移动的组件的值。您可以根据为节点指定的值，按所示格式使用 nodeSelector 或使用 <key>: <value> 对。

验证

要验证组件是否已移动，您可以使用 oc get pod -o wide 命令。

例如：

  • 您需要移动来自 ip-10-0-147-79.us-east-2.compute.internal 节点上的 Kibana pod： 

    $ oc get pod kibana-5b8bdf44f9-ccpq9 -o wide
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
kibana-5b8bdf44f9-ccpq9   2/2     Running   0          27s   10.129.2.18   ip-10-0-147-79.us-east-2.compute.internal   <none>           <none>
    Copy to Clipboard Toggle word wrap

  • 您需要将 Kibana Pod 移到 ip-10-0-139-48.us-east-2.compute.internal 节点，该节点是一个专用的基础架构节点： 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                         STATUS   ROLES          AGE   VERSION
ip-10-0-133-216.us-east-2.compute.internal   Ready    master         60m   v1.20.0
ip-10-0-139-146.us-east-2.compute.internal   Ready    master         60m   v1.20.0
ip-10-0-139-192.us-east-2.compute.internal   Ready    worker         51m   v1.20.0
ip-10-0-139-241.us-east-2.compute.internal   Ready    worker         51m   v1.20.0
ip-10-0-147-79.us-east-2.compute.internal    Ready    worker         51m   v1.20.0
ip-10-0-152-241.us-east-2.compute.internal   Ready    master         60m   v1.20.0
ip-10-0-139-48.us-east-2.compute.internal    Ready    infra          51m   v1.20.0
    Copy to Clipboard Toggle word wrap

    请注意，该节点具有 node-role.kubernetes.io/infra: " label: 

    $ oc get node ip-10-0-139-48.us-east-2.compute.internal -o yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    kind: Node
apiVersion: v1
metadata:
  name: ip-10-0-139-48.us-east-2.compute.internal
  selfLink: /api/v1/nodes/ip-10-0-139-48.us-east-2.compute.internal
  uid: 62038aa9-661f-41d7-ba93-b5f1b6ef8751
  resourceVersion: '39083'
  creationTimestamp: '2020-04-13T19:07:55Z'
  labels:
    node-role.kubernetes.io/infra: ''
...
    Copy to Clipboard Toggle word wrap

  • 要移动 Kibana pod，编辑 ClusterLogging CR 以添加节点选择器： 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging

...

spec:

...

  visualization:
    kibana:
      nodeSelector:
    1 
    
        node-role.kubernetes.io/infra: ''
      proxy:
        resources: null
      replicas: 1
      resources: null
    type: kibana
    Copy to Clipboard Toggle word wrap
    1
    添加节点选择器以匹配节点规格中的 label。

  • 保存 CR 后，当前 Kibana Pod 将被终止，新的 Pod 会被部署： 

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                            READY   STATUS        RESTARTS   AGE
cluster-logging-operator-84d98649c4-zb9g7       1/1     Running       0          29m
elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg   2/2     Running       0          28m
elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj   2/2     Running       0          28m
elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78    2/2     Running       0          28m
fluentd-42dzz                                   1/1     Running       0          28m
fluentd-d74rq                                   1/1     Running       0          28m
fluentd-m5vr9                                   1/1     Running       0          28m
fluentd-nkxl7                                   1/1     Running       0          28m
fluentd-pdvqb                                   1/1     Running       0          28m
fluentd-tflh6                                   1/1     Running       0          28m
kibana-5b8bdf44f9-ccpq9                         2/2     Terminating   0          4m11s
kibana-7d85dcffc8-bfpfp                         2/2     Running       0          33s
    Copy to Clipboard Toggle word wrap

  • 新 pod 位于 ip-10-0-139-48.us-east-2.compute.internal 节点上 : 

    $ oc get pod kibana-7d85dcffc8-bfpfp -o wide
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                      READY   STATUS        RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
kibana-7d85dcffc8-bfpfp   2/2     Running       0          43s   10.131.0.22   ip-10-0-139-48.us-east-2.compute.internal   <none>           <none>
    Copy to Clipboard Toggle word wrap

  • 片刻后，原始 Kibana Pod 将被删除。 

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                            READY   STATUS    RESTARTS   AGE
cluster-logging-operator-84d98649c4-zb9g7       1/1     Running   0          30m
elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg   2/2     Running   0          29m
elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj   2/2     Running   0          29m
elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78    2/2     Running   0          29m
fluentd-42dzz                                   1/1     Running   0          29m
fluentd-d74rq                                   1/1     Running   0          29m
fluentd-m5vr9                                   1/1     Running   0          29m
fluentd-nkxl7                                   1/1     Running   0          29m
fluentd-pdvqb                                   1/1     Running   0          29m
fluentd-tflh6                                   1/1     Running   0          29m
kibana-7d85dcffc8-bfpfp                         2/2     Running   0          62s
    Copy to Clipboard Toggle word wrap

4.7. 关于集群自动扩展
复制链接

集群自动扩展会调整 OpenShift Container Platform 集群的大小，以满足其当前的部署需求。它使用 Kubernetes 样式的声明性参数来提供基础架构管理，而且这种管理不依赖于特定云提供商的对象。集群自动控制会在集群范围内有效，不与特定的命名空间相关联。

当因为资源不足而无法在任何当前 worker 节点上调度 pod 时，或者在需要另一个节点来满足部署需求时，集群自动扩展会增加集群的大小。集群自动扩展不会将集群资源增加到超过您指定的限制。

集群自动扩展计算集群所有节点上的内存、CPU 和 GPU 总量，即使它不管理 control plane 节点。这些值不是单机导向型。它们是整个集群中所有资源的聚合。例如，如果您设置了最大内存资源限值，集群自动扩展会在计算当前内存用量时包括集群中的所有节点。然后，使用该计算来确定集群自动扩展是否具有添加更多工作程序资源的能力。

重要

确保您所创建的 ClusterAutoscaler 资源定义中的 maxNodesTotal 值足够大，足以满足计算集群中可能的机器总数。此值必须包含 control plane 机器的数量以及可扩展至的机器数量。

每隔 10 秒，集群自动扩展会检查集群中不需要哪些节点，并删除它们。如果满足以下条件，集群自动扩展会考虑删除节点：

  • 该节点上运行的所有容器集的 CPU 和内存请求总和低于节点上分配的资源的 50%。
  • 集群自动扩展可以将节点上运行的所有 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 个内核开头，集群自动扩展最多可添加 4 个带有 32 个内核的节点，总节点数量为 82。

如果配置集群自动扩展，则需要额外的使用限制：

  • 不要直接修改位于自动扩展节点组中的节点。同一节点组中的所有节点具有相同的容量和标签，并且运行相同的系统 Pod。
  • 指定适合您的 Pod 的请求。
  • 如果需要防止 Pod 被过快删除，请配置适当的 PDB。
  • 确认您的云提供商配额足够大，能够支持您配置的最大节点池。
  • 不要运行其他节点组自动扩展器，特别是云提供商提供的自动扩展器。

pod 横向自动扩展（HPA）和集群自动扩展以不同的方式修改集群资源。HPA 根据当前的 CPU 负载更改部署或副本集的副本数。如果负载增加，HPA 会创建新的副本，不论集群可用的资源量如何。如果没有足够的资源，集群自动扩展会添加资源，以便 HPA 创建的 pod 可以运行。如果负载减少，HPA 会停止一些副本。如果此操作导致某些节点利用率低下或完全为空，集群自动扩展会删除不必要的节点。

集群自动扩展会考虑 pod 优先级。如果集群没有足够的资源，则“Pod 优先级和抢占”功能可根据优先级调度 Pod，但集群自动扩展会确保集群具有运行所有 Pod 需要的资源。为满足这两个功能，集群自动扩展包含一个优先级截止函数。您可以使用此截止函数来调度“尽力而为”的 Pod，它们不会使集群自动扩展增加资源，而是仅在有可用备用资源时运行。

优先级低于截止值的 Pod 不会导致集群扩展或阻止集群缩减。系统不会添加新节点来运行 Pod，并且可能会删除运行这些 Pod 的节点来释放资源。

4.7.1. ClusterAutoscaler 资源定义
复制链接

此 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
  scaleDown:
10 

    enabled: true
11 

    delayAfterAdd: 10m
12 

    delayAfterDelete: 5m
13 

    delayAfterFailure: 30s
14 

    unneededTime: 5m
15
Copy to Clipboard Toggle word wrap
1
指定 Pod 必须超过哪一优先级才能让机器自动扩展部署更多节点。输入一个 32 位整数值。podPriorityThreshold 值将与您分配给每个 Pod 的 PriorityClass 值进行比较。
2
指定要部署的最大节点数。这个值是集群中部署的机器总数，而不仅仅是自动扩展器控制的机器。确保这个值足够大，足以满足所有 control plane 和计算机器以及您在 MachineAutoscaler 资源中指定的副本总数。
3
指定在集群中部署的最小内核数。
4
指定集群中要部署的最大内核数。
5
指定集群中最小内存量（以 GiB 为单位）。
6
指定集群中的最大内存量（以 GiB 为单位）。
7
（可选）指定要部署的 GPU 节点的类型。只有 nvidia.com/gpu 和 amd.com/gpu 是有效的类型。
8
指定在集群中部署的最小 GPU 数。
9
指定集群中要部署的最大 GPU 数量。
10
在此部分中，您可以指定每个操作要等待的时长，可以使用任何有效的 ParseDuration 间隔，包括 ns、us、ms、s、m 和 h。
11
指定集群自动扩展是否可以删除不必要的节点。
12
（可选）指定在最近添加节点之后要等待多久才能删除节点。如果不指定值，则使用默认值 10m。
13
指定在最近删除节点之后要等待多久才能删除节点。如果不指定值，则使用默认值 10s。
14
指定在发生缩减失败之后要等待多久才能删除节点。如果不指定值，则使用默认值 3m。
15
指定要经过多长时间之后，不需要的节点才符合删除条件。如果不指定值，则使用默认值 10m。
注意

执行扩展操作时，集群自动扩展会保持在 ClusterAutoscaler 资源定义中设置的范围，如要部署的最小和最大内核数，或集群中的内存量。但是，集群自动扩展无法将集群中的当前值修正为在这些范围内。

最小和最大 CPU、内存和 GPU 值可通过计算集群中的所有节点上的资源来确定，即使集群自动扩展不管理节点。例如，control plane 节点会在集群中的总内存中被考虑，即使集群自动扩展不管理 control plane 节点。

4.7.2. 部署集群自动扩展
复制链接

要部署集群自动扩展，请创建一个 ClusterAutoscaler 资源实例。

流程

  1. 为 ClusterAutoscaler 资源创建一个 YAML 文件，其中包含自定义的资源定义。

  2. 在集群中创建资源： 

    $ oc create -f <filename>.yaml
    1
    Copy to Clipboard Toggle word wrap
    1
    <filename> 是您自定义的资源文件的名称。

4.8. 关于机器自动扩展
复制链接

机器自动扩展会调整您在 OpenShift Container Platform 集群中部署的机器集中的 Machine 数量。您可以扩展默认 worker 机器集，以及您创建的其他机器集。当集群没有足够资源来支持更多部署时，机器自动扩展会增加 Machine。对 MachineAutoscaler 资源中的值（如最小或最大实例数量）的任何更改都会立即应用到目标机器设置中。

重要

您必须部署机器自动扩展才能使用集群自动扩展功能来扩展机器。集群自动扩展使用机器自动扩展集上的注解来确定可扩展的资源。如果您在没有定义机器自动扩展的情况下定义集群自动扩展，集群自动扩展永远不会扩展集群。

4.8.1. MachineAutoscaler 资源定义
复制链接

此 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
Copy to Clipboard Toggle word wrap
1
指定机器自动扩展名称。为了更容易识别此机器自动扩展会扩展哪些机器集，请指定或注明要扩展的机器集的名称。机器集名称的格式如下： < clusterid>-<machineset>-<region&gt;。
2
指定在机器自动扩展启动集群扩展后必须保留在指定区域中的指定类型的最小机器数量。如果在 AWS、GCP、Azure 或 RHOSP 中运行，则该值可设置为 0。对于其他供应商，请不要将此值设置为 0。

对于用于特殊工作负载的高价或有限使用硬件，或者扩展具有额外大型机器的机器集，您可以将此值设置为 0 来节约成本。如果机器没有使用，集群自动扩展会将机器集缩减为零。

重要

对于安装程序置备的基础架构，请不要将 OpenShift Container Platform 安装过程中创建的三台计算机器集的 spec.minReplicas 值设置为 0。

3
指定集群自动扩展启动集群扩展后可在指定区域中部署的指定类型的最大机器数量。确保 ClusterAutoscaler 资源定义的 maxNodesTotal 值足够大，以便机器自动扩展器可以部署这个数量的机器。
4
在本小节中，提供用于描述要扩展的现有机器集的值。
5
kind 参数值始终为 MachineSet。
6
name 值必须与现有机器集的名称匹配，如 metadata.name 参数值所示。

4.8.2. 部署机器自动扩展
复制链接

要部署机器自动扩展，请创建一个 MachineAutoscaler 资源实例。

流程

  1. 为 MachineAutoscaler 资源创建一个 YAML 文件，其中包含自定义的资源定义。

  2. 在集群中创建资源： 

    $ oc create -f <filename>.yaml
    1
    Copy to Clipboard Toggle word wrap
    1
    <filename> 是您自定义的资源文件的名称。

4.9. 使用 FeatureGate 启用技术预览功能
复制链接

您可以通过编辑 FeatureGate 自定义资源（CR）为集群中的所有节点开启当前技术预览功能的子集。

4.9.1. 了解功能门
复制链接

您可以使用 FeatureGate 自定义资源（CR）在集群中启用特定的功能集。功能集是 OpenShift Container Platform 功能的集合，默认情况下不启用。

您可以使用 FeatureGate CR 激活以下功能集：

  • IPv6DualStackNoUpgrade.此功能门在集群中启用双栈网络模式。双堆栈网络支持同时使用 IPv4 和 IPv6。启用此功能集 不被支持，无法撤消，并会阻止更新。不建议在生产环境集群中使用此功能集。

4.9.2. 使用 CLI 启用功能集
复制链接

您可以通过编辑 FeatureGate 自定义资源（CR）来使用 OpenShift CLI（oc）为集群中的所有节点启用功能集。

先决条件

  • 已安装 OpenShift CLI（oc）。

流程

启用功能集：

  1. 编辑名为 cluster 的 FeatureGate CR： 

    $ oc edit featuregate cluster
    Copy to Clipboard Toggle word wrap

    FeatureGate 自定义资源示例

    apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
    1 
    
spec:
  featureSet: IPv6DualStackNoUpgrade
    2
    Copy to Clipboard Toggle word wrap

    1
    FeatureGate CR 的名称必须是 cluster。
    2
    添加 IPv6DualStackNoUpgrade 功能集，以启用双栈网络模式。

    保存更改后，创建新的机器配置，机器配置池会更新，并在应用更改时在每个节点上调度。

    注意

    启用 IPv6DualStackNoUpgrade 功能集无法撤消，并防止更新。不建议在生产环境集群中使用此功能集。

验证

在节点返回就绪状态后，您可以通过查看节点上的 kubelet.conf 文件来验证是否启用了功能门。

  1. 为节点启动 debug 会话： 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap

  2. 将您的根目录改为主机： 

    sh-4.2# chroot /host
    Copy to Clipboard Toggle word wrap

  3. 查看 kubelet.conf 文件： 

    sh-4.2# cat /etc/kubernetes/kubelet.conf
    Copy to Clipboard Toggle word wrap

    输出示例

     ...
featureGates:
  InsightsOperatorPullingSCA: true,
  LegacyNodeRoleBehavior: false
 ...
    Copy to Clipboard Toggle word wrap

    集群中启用了列为 true 的功能。

    注意

    列出的功能因 OpenShift Container Platform 版本而异。

4.10. etcd 任务
复制链接

备份 etcd、启用或禁用 etcd 加密或清除 etcd 数据。

4.10.1. 关于 etcd 加密
复制链接

默认情况下，OpenShift Container Platform 不加密 etcd 数据。在集群中启用对 etcd 进行加密的功能可为数据的安全性提供额外的保护层。例如，如果 etcd 备份暴露给不应该获得这个数据的人员，它会帮助保护敏感数据。

启用 etcd 加密时，以下 OpenShift API 服务器和 Kubernetes API 服务器资源将被加密：

  • Secrets
  • 配置映射
  • Routes
  • OAuth 访问令牌
  • OAuth 授权令牌

当您启用 etcd 加密时，会创建加密密钥。这些密钥会每周进行轮转。您必须具有这些密钥才能从 etcd 备份中恢复。

注意

请记住，etcd 仅对值进行加密，而不对键进行加密。这意味着资源类型、命名空间和对象名称是不加密的。

4.10.2. 启用 etcd 加密
复制链接

您可以启用 etcd 加密来加密集群中的敏感资源。

警告

不建议在初始加密过程完成前备份 etcd。如果加密过程还没有完成，则备份可能只被部分加密。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 修改 APIServer 对象： 

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

  2. 把 encryption 项类型设置为 aescbc： 

    spec:
  encryption:
    type: aescbc
    1
    Copy to Clipboard Toggle word wrap
    1
    aescbc 类型表示 AES-CBC 使用 PKCS#7 padding 和 32 字节密钥来执行加密。

  3. 保存文件以使改变生效。

    加密过程开始。根据集群的大小，这个过程可能需要 20 分钟或更长的时间才能完成。

  4. 验证 etcd 加密是否成功。

    1. 查看 OpenShift API 服务器的 Encrypted 状态条件，以验证其资源是否已成功加密： 

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      在成功加密后输出显示 EncryptionCompleted： 

      EncryptionCompleted
All resources encrypted: routes.route.openshift.io
      Copy to Clipboard Toggle word wrap

      如果输出显示 EncryptionInProgress，加密仍在进行中。等待几分钟后重试。

    2. 查看 Kubernetes API 服务器的 Encrypted 状态条件，以验证其资源是否已成功加密： 

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      在成功加密后输出显示 EncryptionCompleted： 

      EncryptionCompleted
All resources encrypted: secrets, configmaps
      Copy to Clipboard Toggle word wrap

      如果输出显示 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"}'
      Copy to Clipboard Toggle word wrap

      在成功加密后输出显示 EncryptionCompleted： 

      EncryptionCompleted
All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
      Copy to Clipboard Toggle word wrap

      如果输出显示 EncryptionInProgress，加密仍在进行中。等待几分钟后重试。

4.10.3. 禁用 etcd 加密
复制链接

您可以在集群中禁用 etcd 数据的加密。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 修改 APIServer 对象： 

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

  2. 将 encryption 字段类型设置为 identity： 

    spec:
  encryption:
    type: identity
    1
    Copy to Clipboard Toggle word wrap
    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"}'
      Copy to Clipboard Toggle word wrap

      在成功解密后输出显示 DecryptionCompleted： 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      如果输出显示 DecryptionInProgress，解密仍在进行中。等待几分钟后重试。

    2. 查看 Kubernetes API 服务器的 Encrypted 状态条件，以验证其资源是否已成功解密： 

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      在成功解密后输出显示 DecryptionCompleted： 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      如果输出显示 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"}'
      Copy to Clipboard Toggle word wrap

      在成功解密后输出显示 DecryptionCompleted： 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      如果输出显示 DecryptionInProgress，解密仍在进行中。等待几分钟后重试。

4.10.4. 备份 etcd 数据
复制链接

按照以下步骤，通过创建 etcd 快照并备份静态 pod 的资源来备份 etcd 数据。这个备份可以被保存，并在以后需要时使用它来恢复 etcd 数据。

重要

仅保存单一 control plane 主机（也称为 master 主机）的备份。不要从集群中的每个 control plane 主机进行备份。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

  • 您已检查是否启用了集群范围代理。

    提示

    您可以通过查看 oc get proxy cluster -o yaml 的输出来检查代理是否已启用。如果 httpProxy、httpsProxy和 noProxy 字段设置了值，则会启用代理。

流程

  1. 为 control plane 节点启动一个 debug 会话： 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap

  2. 将您的根目录改为主机： 

    sh-4.2# chroot /host
    Copy to Clipboard Toggle word wrap
  3. 如果启用了集群范围的代理，请确定已导出了 NO_PROXY、HTTP_PROXY和 HTTPS_PROXY 环境变量。

  4. 运行 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
    Copy to Clipboard Toggle word wrap

    脚本输出示例

    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
    Copy to Clipboard Toggle word wrap

    在这个示例中，在 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 仅对值进行加密，而不对键进行加密。这意味着资源类型、命名空间和对象名称是不加密的。

4.10.5. 分离 etcd 数据
复制链接

在 etcd 历史记录压缩和其他事件后，必须定期执行手动清除碎片以便重新声明磁盘空间。

历史压缩将自动每五分钟执行一次，并在后端数据库中造成混乱。此碎片空间可供 etcd 使用，但主机文件系统不可用。您必须对碎片 etcd 进行碎片清除，才能使这个空间可供主机文件系统使用。

因为 etcd 将数据写入磁盘，所以其性能主要取决于磁盘性能。根据您的集群的具体情况，考虑每个月清理一次 etcd 碎片，或每个月清理两次。您还可以监控 etcd_db_total_size_in_bytes 指标，以确定是否需要进行碎片操作。

警告

分离 etcd 是一个阻止性操作。在进行碎片处理完成前，etcd 成员不会响应。因此，在每个下一个 pod 要进行碎片清理前，至少等待一分钟，以便集群可以恢复正常工作。

按照以下步骤对每个 etcd 成员上的 etcd 数据进行碎片处理。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 确定哪个 etcd 成员是领导成员，因为领导会进行最后的碎片处理。

    1. 获取 etcd pod 列表： 

      $ oc get pods -n openshift-etcd -o wide | grep -v quorum-guard | grep etcd
      Copy to Clipboard Toggle word wrap

      输出示例

      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>
      Copy to Clipboard Toggle word wrap

    2. 选择 pod 并运行以下命令来确定哪个 etcd 成员是领导： 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table
      Copy to Clipboard Toggle word wrap

      输出示例

      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.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      基于此输出的 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
      Copy to Clipboard Toggle word wrap

    2. 取消设置 ETCDCTL_ENDPOINTS 环境变量： 

      sh-4.4# unset ETCDCTL_ENDPOINTS
      Copy to Clipboard Toggle word wrap

    3. 清理 etcd 成员： 

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
      Copy to Clipboard Toggle word wrap

      输出示例

      Finished defragmenting etcd member[https://localhost:2379]
      Copy to Clipboard Toggle word wrap

      如果发生超时错误，增加 --command-timeout 的值，直到命令成功为止。

    4. 验证数据库大小是否已缩小： 

      sh-4.4# etcdctl endpoint status -w table --cluster
      Copy to Clipboard Toggle word wrap

      输出示例

      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         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.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        |
      1 
      
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      本例显示这个 etcd 成员的数据库大小现在为 41 MB，而起始大小为 104 MB。

    5. 重复这些步骤以连接到其他 etcd 成员并进行碎片处理。最后才对领导进行碎片清除。

      至少要在碎片处理操作之间等待一分钟，以便 etcd pod 可以恢复。在 etcd pod 恢复前，etcd 成员不会响应。

  3. 如果因为超过空间配额而触发任何 NOSPACE 警告，请清除它们。

    1. 检查是否有 NOSPACE 警告： 

      sh-4.4# etcdctl alarm list
      Copy to Clipboard Toggle word wrap

      输出示例

      memberID:12345678912345678912 alarm:NOSPACE
      Copy to Clipboard Toggle word wrap

    2. 清除警告： 

      sh-4.4# etcdctl alarm disarm
      Copy to Clipboard Toggle word wrap

4.10.6. 恢复到一个以前的集群状态
复制链接

您可以使用保存的 etcd 备份来恢复以前的集群状态，或者恢复丢失了大多数 control plane 主机（也称为 master 主机）的集群。

重要

恢复集群时，必须使用同一 z-stream 发行版本中获取的 etcd 备份。例如，OpenShift Container Platform 4.7.2 集群必须使用从 4.7.2 开始的 etcd 备份。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 用作恢复主机的健康 control plane 主机。
  • SSH 对 control plane 主机的访问。
  • 包含从同一备份中获取的 etcd 快照和静态 pod 资源的备份目录。该目录中的文件名必须采用以下格式: snapshot_<datetimestamp>.db 和 static_kuberesources_<datetimestamp>.tar.gz 。
重要

对于非恢复 control plane 节点，不需要建立 SSH 连接或停止静态 pod。您可以逐个删除并重新创建其他非恢复 control plane 机器。

流程

  1. 选择一个要用作恢复主机的 control plane 主机。这是您要在其中运行恢复操作的主机。

  2. 建立到每个 control plane 节点（包括恢复主机）的 SSH 连接。

    恢复过程启动后，Kubernetes API 服务器将无法访问，因此您无法访问 control plane 节点。因此，建议在一个单独的终端中建立到每个control plane 主机的 SSH 连接。

    重要

    如果没有完成这个步骤，将无法访问 control plane 主机来完成恢复过程，您将无法从这个状态恢复集群。

  3. 将 etcd 备份目录复制复制到恢复 control plane 主机上。

    此流程假设您将 backup 目录（其中包含 etcd 快照和静态 pod 资源）复制到恢复 control plane 主机的 /home/core/ 目录中。

  4. 在任何其他 control plane 节点上停止静态 pod。

    注意

    不需要手动停止恢复主机上的 pod。恢复脚本将停止恢复主机上的 pod。

    1. 访问不是恢复主机的 control plane 主机。

    2. 将现有 etcd pod 文件从 Kubelet 清单目录中移出： 

      $ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

    3. 验证 etcd pod 是否已停止。 

      $ sudo crictl ps | grep etcd | grep -v operator
      Copy to Clipboard Toggle word wrap

      命令输出应该为空。如果它不是空的，请等待几分钟后再重新检查。

    4. 将现有 Kubernetes API 服务器 pod 文件移出 kubelet 清单目录中： 

      $ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

    5. 验证 Kubernetes API 服务器 pod 是否已停止。 

      $ sudo crictl ps | grep kube-apiserver | grep -v operator
      Copy to Clipboard Toggle word wrap

      命令输出应该为空。如果它不是空的，请等待几分钟后再重新检查。

    6. 将 etcd 数据目录移到不同的位置： 

      $ sudo mv /var/lib/etcd/ /tmp
      Copy to Clipboard Toggle word wrap
    7. 在其他不是恢复主机的 control plane 主机上重复此步骤。
  5. 访问恢复 control plane 主机。

  6. 如果启用了集群范围的代理，请确定已导出了 NO_PROXY、HTTP_PROXY和 HTTPS_PROXY 环境变量。

    提示

    您可以通过查看 oc get proxy cluster -o yaml 的输出来检查代理是否已启用。如果 httpProxy、httpsProxy和 noProxy 字段设置了值，则会启用代理。

  7. 在恢复 control plane 主机上运行恢复脚本，提供到 etcd 备份目录的路径： 

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup
    Copy to Clipboard Toggle word wrap

    脚本输出示例

    ...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
    Copy to Clipboard Toggle word wrap

    注意

    如果在最后的 etcd 备份后更新节点，恢复过程可能会导致节点进入 NotReady 状态。

  8. 检查节点以确保它们处于 Ready 状态。

    1. 运行以下命令： 

      $ oc get nodes -w
      Copy to Clipboard Toggle word wrap

      输出示例

      NAME                STATUS  ROLES          AGE     VERSION
host-172-25-75-28   Ready   master         3d20h   v1.23.3+e419edf
host-172-25-75-38   Ready   infra,worker   3d20h   v1.23.3+e419edf
host-172-25-75-40   Ready   master         3d20h   v1.23.3+e419edf
host-172-25-75-65   Ready   master         3d20h   v1.23.3+e419edf
host-172-25-75-74   Ready   infra,worker   3d20h   v1.23.3+e419edf
host-172-25-75-79   Ready   worker         3d20h   v1.23.3+e419edf
host-172-25-75-86   Ready   worker         3d20h   v1.23.3+e419edf
host-172-25-75-98   Ready   infra,worker   3d20h   v1.23.3+e419edf
      Copy to Clipboard Toggle word wrap

      所有节点都可能需要过几分钟时间才能报告其状态。

    2. 如果有任何节点处于 NotReady 状态，请登录节点，并从每个节点上的 /var/lib/kubelet/pki 目录中删除所有 PEM 文件。您可以 SSH 到节点，或使用 web 控制台中的终端窗口。 

      $  ssh -i <ssh-key-path> core@<master-hostname>
      Copy to Clipboard Toggle word wrap

      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
      Copy to Clipboard Toggle word wrap

  9. 在所有 control plane 主机上重启 kubelet 服务。

    1. 在恢复主机中运行以下命令： 

      $ sudo systemctl restart kubelet.service
      Copy to Clipboard Toggle word wrap
    2. 在所有其他 control plane 主机上重复此步骤。

  10. 批准待处理的 CSR：

    1. 获取当前 CSR 列表。 

      $ oc get csr
      Copy to Clipboard Toggle word wrap

      输出示例

      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 
      
...
      Copy to Clipboard Toggle word wrap

      1 1 2
      一个待处理的 kubelet 服务 CSR（用于用户置备的安装）。
      3 4
      一个待处理的 node-bootstrapper CSR。

    2. 查看一个 CSR 的详细信息以验证其是否有效： 

      $ oc describe csr <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <csr_name> 是当前 CSR 列表中 CSR 的名称。

    3. 批准每个有效的 node-bootstrapper CSR： 

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

    4. 对于用户置备的安装，请批准每个有效的 kubelet 服务 CSR： 

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

  11. 确认单个成员 control plane 已被成功启动。

    1. 从恢复主机上，验证 etcd 容器是否正在运行。 

      $ sudo crictl ps | grep etcd | grep -v operator
      Copy to Clipboard Toggle word wrap

      输出示例

      3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0
      Copy to Clipboard Toggle word wrap

    2. 从恢复主机上，验证 etcd pod 是否正在运行。 

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
      Copy to Clipboard Toggle word wrap
      注意

      如果您试图在运行这个命令前运行 oc login 并接收以下错误，请等待一些时间以便身份验证控制器启动并再次尝试。 

      Unable to connect to the server: EOF
      Copy to Clipboard Toggle word wrap

      输出示例

      NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s
      Copy to Clipboard Toggle word wrap

      如果状态是 Pending，或者输出中列出了多个正在运行的 etcd pod，请等待几分钟，然后再次检查。

    3. 对不是恢复主机的 control plane 主机重复此步骤。

  12. 删除并重新创建其他非恢复(control plane)机器，逐个删除和重新创建。重新创建这些机器后，会强制一个新的修订版本，etcd 会自动扩展。

    如果您正在运行安装程序置备的基础架构，或者您使用 Machine API 创建机器，请按照以下步骤执行。否则，您必须使用最初创建它时使用的相同方法创建新的 control plane 节点。

    警告

    不要为恢复主机删除和重新创建计算机。

    1. 为丢失的 control plane 主机之一获取机器。

      在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令： 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      输出示例： 

      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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      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
        Copy to Clipboard Toggle word wrap

      2. 将 metadata.name 字段更改为新名称。

        建议您保留与旧机器相同的基础名称，并将结束号码改为下一个可用数字。在本例中，cluster name-8qw5l-master-0 被改为 clustername-8qw5l-master-3 ： 

        apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
        Copy to Clipboard Toggle word wrap

      3. 删除 spec.providerID 字段： 

        providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
        Copy to Clipboard Toggle word wrap

      4. 删除 metadata.annotations 和 metadata.generation 字段： 

        annotations:
  machine.openshift.io/instance-state: running
...
generation: 2
        Copy to Clipboard Toggle word wrap

      5. 删除 metadata.resourceVersion 和 metadata.uid 字段： 

        resourceVersion: "13291"
uid: a282eb70-40a2-4e89-8009-d05dd420d31a
        Copy to Clipboard Toggle word wrap

    4. 删除丢失的 control plane 主机的机器： 

      $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
      1
      Copy to Clipboard Toggle word wrap
      1
      为丢失的 control plane 主机指定 control plane 机器的名称。

    5. 验证机器是否已删除： 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      输出示例： 

      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
      Copy to Clipboard Toggle word wrap

    6. 使用 new-master-machine.yaml 文件创建新机器： 

      $ oc apply -f new-master-machine.yaml
      Copy to Clipboard Toggle word wrap

    7. 验证新机器是否已创建： 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      输出示例： 

      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
      Copy to Clipboard Toggle word wrap
      1
      新机器 clustername-8qw5l-master-3 会被创建，并在阶段从 Provisioning 变为 Running 后就绪。

      创建新机器可能需要几分钟时间。当机器或节点返回一个健康状态时，etcd cluster Operator 将自动同步。

    8. 对不是恢复主机的 control plane 主机重复这些步骤。

  13. 在一个单独的终端窗口中，使用以下命令以具有 cluster-admin 角色的用户身份登录到集群： 

    $ oc login -u <cluster_admin>
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <cluster_admin>，使用 cluster-admin 角色指定一个用户名。

  14. 强制 etcd 重新部署。

    在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令： 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 值必须是唯一的，这就是为什么附加时间戳的原因。

    当 etcd cluster Operator 执行重新部署时，现有节点开始使用与初始 bootstrap 扩展类似的新 pod。

  15. 验证所有节点是否已更新至最新的修订版本。

    在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令： 

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    Copy to Clipboard Toggle word wrap

    查看 etcd 的NodeInstallerProgressing 状态条件，以验证所有节点是否处于最新的修订。在更新成功后，输出会显示 AllNodesAtLatestRevision： 

    AllNodesAtLatestRevision
3 nodes are at revision 7
    1
    Copy to Clipboard Toggle word wrap
    1
    在本例中，最新的修订版本号是 7。

    如果输出包含多个修订号，如 2 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。

  16. 在重新部署 etcd 后，为 control plane 强制进行新的 rollout。由于 kubelet 使用内部负载平衡器连接到 API 服务器，因此 Kubernetes API 将在其他节点上重新安装自己。

    在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令。

    1. 为 Kubernetes API 服务器强制进行新的推出部署： 

      $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
      Copy to Clipboard Toggle word wrap

      验证所有节点是否已更新至最新的修订版本。 

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      查看 NodeInstallerProgressing 状态条件，以验证所有节点是否处于最新版本。在更新成功后，输出会显示 AllNodesAtLatestRevision： 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      在本例中，最新的修订版本号是 7。

      如果输出包含多个修订号，如 2 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。

    2. 为 Kubernetes 控制器管理器强制进行新的推出部署： 

      $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
      Copy to Clipboard Toggle word wrap

      验证所有节点是否已更新至最新的修订版本。 

      $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      查看 NodeInstallerProgressing 状态条件，以验证所有节点是否处于最新版本。在更新成功后，输出会显示 AllNodesAtLatestRevision： 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      在本例中，最新的修订版本号是 7。

      如果输出包含多个修订号，如 2 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。

    3. 为 Kubernetes 调度程序强制进行新的推出部署： 

      $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
      Copy to Clipboard Toggle word wrap

      验证所有节点是否已更新至最新的修订版本。 

      $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      查看 NodeInstallerProgressing 状态条件，以验证所有节点是否处于最新版本。在更新成功后，输出会显示 AllNodesAtLatestRevision： 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      在本例中，最新的修订版本号是 7。

      如果输出包含多个修订号，如 2 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。

  17. 验证所有 control plane 主机是否已启动并加入集群。

    在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令： 

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    Copy to Clipboard Toggle word wrap

为确保所有工作负载在恢复过程后返回到正常操作，请重启存储 Kubernetes API 信息的每个 pod。这包括 OpenShift Container Platform 组件，如路由器、Operator 和第三方组件。

请注意，在完成这个过程后，可能需要几分钟才能恢复所有服务。例如，在重启 OAuth 服务器 pod 前，使用 oc login 进行身份验证可能无法立即正常工作。

4.10.7. 恢复持久性存储状态的问题和解决方法
复制链接

如果您的 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. 删除 LocalVolume 或 LocalVolumeSet 对象（请参阅 Storage → Configuring persistent storage → Persistent storage → Persistent storage → Deleting the Local Storage Operator Resources）。

4.11. Pod 中断预算
复制链接

了解并配置 pod 中断预算。

pod 中断预算是 Kubernetes API 的一部分，可以像其他对象类型一样通过 oc 命令进行管理。它们允许在操作过程中指定 pod 的安全约束，比如为维护而清空节点。

PodDisruptionBudget 是一个 API 对象，用于指定在某一时间必须保持在线的副本的最小数量或百分比。在项目中进行这些设置对节点维护（比如缩减集群或升级集群）有益，而且仅在自愿驱除（而非节点失败）时遵从这些设置。

PodDisruptionBudget 对象的配置由以下关键部分组成：

  • 标签选择器，即一组 pod 的标签查询。

  • 可用性级别，用来指定必须同时可用的最少 pod 的数量。

    • minAvailable 是必须始终可用的 pod 的数量，即使在中断期间也是如此。
    • maxUnavailable 是中断期间可以无法使用的 pod 的数量。
注意

允许 maxUnavailable 为 0% 或 0，minAvailable 为 100％ 或等于副本数，但这样设置可能会阻止节点排空操作。

您可以使用以下命令来检查所有项目的 pod 中断预算： 

$ oc get poddisruptionbudget --all-namespaces
Copy to Clipboard Toggle word wrap

输出示例

NAMESPACE         NAME          MIN-AVAILABLE   SELECTOR
another-project   another-pdb   4               bar=foo
test-project      my-pdb        2               foo=bar
Copy to Clipboard Toggle word wrap

如果系统中至少有 minAvailable 个 pod 正在运行，则 PodDisruptionBudget 被视为是健康的。超过这一限制的每个 pod 都可被驱除。

注意

根据您的 pod 优先级与抢占设置，可能会无视 pod 中断预算要求而移除较低优先级 pod。

您可以使用 PodDisruptionBudget 对象来指定某一时间必须保持在线的副本的最小数量或百分比。

流程

配置 pod 中断预算：

  1. 使用类似以下示例的对象定义来创建 YAML 文件： 

    apiVersion: policy/v1beta1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2
    2 
    
  selector:
    3 
    
    matchLabels:
      foo: bar
    Copy to Clipboard Toggle word wrap
    1
    PodDisruptionBudget 是 policy/v1beta1 API 组的一部分。
    2
    必须同时可用的最小 pod 数量。这可以是整数，也可以是指定百分比的字符串（如 20％）。
    3
    对一组资源进行的标签查询。matchLabels 和 matchExpressions 的结果在逻辑上是联合的。

    或者： 

    apiVersion: policy/v1beta1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  maxUnavailable: 25%
    2 
    
  selector:
    3 
    
    matchLabels:
      foo: bar
    Copy to Clipboard Toggle word wrap
    1
    PodDisruptionBudget 是 policy/v1beta1 API 组的一部分。
    2
    同时不能使用的最多的 pod 数量。这可以是整数，也可以是指定百分比的字符串（如 20％）。
    3
    对一组资源进行的标签查询。matchLabels 和 matchExpressions 的结果在逻辑上是联合的。

  2. 运行以下命令，将对象添加到项目中： 

    $ oc create -f </path/to/file> -n <project_name>
    Copy to Clipboard Toggle word wrap

4.12. 轮转或删除云供应商凭证
复制链接

安装 OpenShift Container Platform 后，一些机构需要轮转或删除初始安装过程中使用的云供应商凭证。

要允许集群使用新凭证，您必须更新 Cloud Credential Operator(CCO)用来 管理云供应商凭证的 secret。

4.12.1. 手动轮转云供应商凭证
复制链接

如果因为某种原因更改了云供应商凭证，您必须手动更新 Cloud Credential Operator（CCO）用来管理云供应商凭证的 secret。

轮转云凭证的过程取决于 CCO 配置使用的模式。在为使用 mint 模式的集群轮转凭证后，您必须手动删除由删除凭证创建的组件凭证。

先决条件

  • 您的集群会在支持使用您要使用的 CCO 模式手动轮转云凭证的平台上安装：

    • 对于 mint 模式，支持 Amazon Web Services(AWS)和 Google Cloud Platform(GCP)。
    • 对于 passthrough 模式，支持 Amazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform(GCP)、Red Hat OpenStack Platform(RHOSP)、Red Hat Virtualization(RHV)和 VMware vSphere。
  • 您已更改了用于与云供应商接口的凭证。
  • 新凭证有足够的权限来在集群中使用 CCO 模式。
注意

当轮转使用 mint 模式的 Azure 集群的凭证时，请不要删除或替换在安装过程中使用的服务主体。反之，生成新的 Azure 服务主体客户端 secret，并相应地更新 OpenShift Container Platform secret。

流程

  1. 在 web 控制台的 Administrator 视角中，导航到 Workloads → Secrets。

  2. 在 Secrets 页面的表中，找到您的云供应商的 root secret。

    Expand
    平台Secret 名称

    AWS

    aws-creds

    Azure

    azure-credentials

    GCP

    gcp-credentials

    RHOSP

    openstack-credentials

    RHV

    ovirt-credentials

    vSphere

    vsphere-creds

  3. 点与 secret 相同的行 kebab 中的 Options 菜单，然后选择 Edit Secret。
  4. 记录 Value 字段的内容。您可以使用这些信息验证在更新凭证后该值是否不同。
  5. 使用云供应商的新身份验证信息更新 Value 字段的文本，然后点 Save。

  6. 如果集群的 CCO 配置为使用 mint 模式，请删除各个 CredentialsRequest 对象引用的每个组件 secret。

    1. 以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform CLI。

    2. 获取所有引用的组件 secret 的名称和命名空间： 

      $ oc -n openshift-cloud-credential-operator get CredentialsRequest \
  -o json | jq -r '.items[] | select (.spec.providerSpec.kind=="<provider_spec>") | .spec.secretRef'
      Copy to Clipboard Toggle word wrap

      其中 <provider_spec > 是您的云供应商的对应值：

      • AWS: AWSProviderSpec
      • Azure: AzureProviderSpec
      • GCP: GCPProviderSpec
      • RHOSP: OpenStackProviderSpec
      • RHV: OvirtProviderSpec
      • vSphere: VSphereProviderSpec

      AWS 输出的部分示例

      {
  "name": "ebs-cloud-credentials",
  "namespace": "openshift-cluster-csi-drivers"
}
{
  "name": "cloud-credential-operator-iam-ro-creds",
  "namespace": "openshift-cloud-credential-operator"
}
...
      Copy to Clipboard Toggle word wrap

    3. 删除每个引用的组件 secret： 

      $ oc delete secret <secret_name> \
      1 
      
  -n <secret_namespace>
      2
      Copy to Clipboard Toggle word wrap
      1
      指定 secret 的名称。
      2
      指定包含 secret 的命名空间。

      删除 AWS secret 示例

      $ oc delete secret ebs-cloud-credentials -n openshift-cluster-csi-drivers
      Copy to Clipboard Toggle word wrap

      您不需要从供应商控制台手动删除凭证。删除引用的组件 secret 将导致 CCO 从平台中删除现有凭证并创建新凭证。

  7. 验证凭证是否已更改：

    1. 在 web 控制台的 Administrator 视角中，导航到 Workloads → Secrets。
    2. 验证 Value 字段的内容与之前记录的信息不同。

4.12.2. 删除云供应商凭证
复制链接

在以 mint 模式使用 Cloud Credential Operator（CCO）安装 OpenShift Container Platform 集群后，您可以从集群中的 kube-system 命名空间中删除管理员级别的凭证 secret。只有在进行更改时（需要提高的权限，如升级），才需要管理员级别的凭证。

注意

在非 z-stream 升级前，您必须使用管理员级别的凭证重新恢复凭证 secret。如果没有凭证，则可能无法进行升级。

先决条件

  • 集群安装在支持从 CCO 中删除云凭证的平台上。支持的平台是 AWS 和 GCP。

流程

  1. 在 web 控制台的 Administrator 视角中，导航到 Workloads → Secrets。

  2. 在 Secrets 页面的表中，找到您的云供应商的 root secret。

    Expand
    平台Secret 名称

    AWS

    aws-creds

    GCP

    gcp-credentials

  3. 点击与 secret 相同的行 kebab 中的 Options 菜单，然后选择 Delete Secret。

4.13. 为断开连接的集群配置镜像流
复制链接

在断开连接的环境中安装 OpenShift Container Platform 后，为 Cluster Samples Operator 和 must-gather 镜像流配置镜像流。

4.13.1. 协助镜像的 Cluster Samples Operator
复制链接

在安装过程中，OpenShift Container Platform 在 openshift-cluster-samples-operator 命名空间中创建一个名为 imagestreamtag-to-image 的配置映射。imagestreamtag-to-image 配置映射包含每个镜像流标签的条目（填充镜像）。

配置映射中 data 字段中每个条目的键格式为 <image_stream_name>_<image_stream_tag_name>。

在断开连接的 OpenShift Container Platform 安装过程中，Cluster Samples Operator 的状态被设置为 Removed。如果您将其改为 Managed，它会安装示例。

注意

在网络受限或停用环境中使用示例可能需要访问您网络外部的服务。例如，Github、Maven Central、npm、RubyGems、PyPi 以及其他服务。可能需要执行其他步骤，以便集群样本操作器的对象访问所需的服务。

您可以使用此配置映射作为导入镜像流所需的镜像的引用。

  • 在 Cluster Samples Operator 被设置为 Removed 时，您可以创建镜像的 registry，或决定您要使用哪些现有镜像 registry。
  • 使用新的配置映射作为指南来镜像您要镜像的 registry 的示例。
  • 将没有镜像的任何镜像流添加到 Cluster Samples Operator 配置对象的 skippedImagestreams 列表中。
  • 将 Cluster Samples Operator 配置对象的 samplesRegistry 设置为已镜像的 registry。
  • 然后，将 Cluster Samples Operator 设置为 Managed 来安装您已镜像的镜像流。

openshift 命名空间中大多数由 Cluster Samples Operator 管理的镜像流指向位于 registry.redhat.io 上红帽容器镜像仓库中的镜像。镜像功能不适用于这些镜像流。

重要

jenkins、jenkins-agent-maven 和 jenkins-agent-nodejs 镜像流的确来自安装有效负载，并由 Samples Operator 管理，因此这些镜像流不需要进一步的镜像操作。

将 Sample Operator 配置文件中的 samplesRegistry 字段设置为 registry.redhat.io 有很多冗余，因为它已经定向到 registry.redhat.io，只用于 Jenkins 镜像和镜像流。

注意

cli、installer、must-gather 和 test 镜像流虽然属于安装有效负载的一部分，但不由 Cluster Samples Operator 管理。此流程中不涉及这些镜像流。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 为您的镜像 registry 创建 pull secret。

流程

  1. 访问被镜像（mirror）的特定镜像流的镜像，例如： 

    $ oc get is <imagestream> -n openshift -o json | jq .spec.tags[].from.name | grep registry.redhat.io
    Copy to Clipboard Toggle word wrap

  2. 将 registry.redhat.io 中与您在受限网络环境中需要的任何镜像流关联的镜像，镜像 (mirror) 成一个定义的镜像 (mirror)： 

    $ oc image mirror registry.redhat.io/rhscl/ruby-25-rhel7:latest ${MIRROR_ADDR}/rhscl/ruby-25-rhel7:latest
    Copy to Clipboard Toggle word wrap

  3. 创建集群的镜像配置对象： 

    $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config
    Copy to Clipboard Toggle word wrap

  4. 在集群的镜像配置对象中，为镜像添加所需的可信 CA： 

    $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

  5. 更新 Cluster Samples Operator 配置对象中的 samplesRegistry 字段，使其包含镜像配置中定义的镜像位置的 hostname 部分： 

    $ oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator
    Copy to Clipboard Toggle word wrap
    注意

    这是必要的，因为镜像流导入过程在此刻不使用镜像（mirro）或搜索机制。

  6. 将所有未镜像的镜像流添加到 Cluster Samples Operator 配置对象的 skippedImagestreams 字段。或者，如果您不想支持任何示例镜像流，在 Cluster Samples Operator 配置对象中将 Cluster Samples Operator 设置为 Removed。

    注意

    如果镜像流导入失败，Cluster Samples Operator 会发出警告，但 Cluster Samples Operator 会定期重试，或看起来并没有重试它们。

    openshift 命名空间中的许多模板都引用镜像流。因此，使用 Removed 清除镜像流和模板，将避免在因为缺少镜像流而导致镜像流和模板无法正常工作时使用它们。

4.13.3. 准备集群以收集支持数据
复制链接

使用受限网络的集群必须导入默认的 must-gather 镜像，以便为红帽支持收集调试数据。在默认情况下，must-gather 镜像不会被导入，受限网络中的集群无法访问互联网来从远程存储库拉取最新的镜像。

流程

  1. 如果您还没有将镜像 registry 的可信 CA 添加到集群的镜像配置对象中，作为 Cluster Samples Operator 配置的一部分，请执行以下步骤：

    1. 创建集群的镜像配置对象： 

      $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config
      Copy to Clipboard Toggle word wrap

    2. 在集群的镜像配置对象中，为镜像添加所需的可信 CA： 

      $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge
      Copy to Clipboard Toggle word wrap

  2. 从您的安装有效负载中导入默认 must-gather 镜像： 

    $ oc import-image is/must-gather -n openshift
    Copy to Clipboard Toggle word wrap

在运行 oc adm must-gather 命令时，请使用 --image 标志并指向有效负载镜像，如下例所示： 

$ oc adm must-gather --image=$(oc adm release info --image-for must-gather)
Copy to Clipboard Toggle word wrap

第 5 章 安装后的节点任务
复制链接

安装 OpenShift Container Platform 后，您可以通过某些节点任务进一步根据要求扩展和自定义集群。

理解并使用 RHEL 计算节点。

5.1.1. 关于在集群中添加 RHEL 计算节点
复制链接

在 OpenShift Container Platform 4.7 中，如果使用用户置备的基础架构安装，您可以选择将 Red Hat Enterprise Linux (RHEL) 机器用作集群中的计算机器（也称为 worker）。集群中的 control plane 或主控机器（master）必须使用 Red Hat Enterprise Linux CoreOS (RHCOS)。

与所有使用用户置备的基础架构的安装一样，如果选择在集群中使用 RHEL 计算机器，您将需要负责所有操作系统生命周期的管理和维护任务，包括执行系统更新、应用补丁以及完成所有其他必要的任务。

重要

由于从集群中的机器上删除 OpenShift Container Platform 需要破坏操作系统，因此您必须对添加到集群中的所有 RHEL 机器使用专用的硬件。

重要

添加到 OpenShift Container Platform 集群的所有 RHEL 机器上都禁用内存交换功能。您无法在这些机器上启用交换内存。

您必须在初始化 control plane 之后将所有 RHEL 计算机器添加到集群。

5.1.2. RHEL 计算节点的系统要求
复制链接

OpenShift Container Platform 环境中的 Red Hat Enterprise Linux (RHEL) 计算或 worker 机器主机必须满足以下最低硬件规格和系统级别要求：

  • 您的红帽帐户必须具有有效的 OpenShift Container Platform 订阅。如果没有，请与您的销售代表联系以了解更多信息。
  • 生产环境必须提供能支持您的预期工作负载的计算机器。作为集群管理员，您必须计算预期的工作负载，再加上大约 10％ 的开销。对于生产环境，请分配足够的资源，以防止节点主机故障影响您的最大容量。

  • 所有系统都必须满足以下硬件要求：

    • 物理或虚拟系统，或在公有或私有 IaaS 上运行的实例。

    • 基础操作系统：使用 "Minimal" 安装选项的 RHEL 7.9。

      重要

      在 OpenShift Container Platform 集群中添加 RHEL 7 计算机器已被弃用。弃用的功能仍然包含在 OpenShift Container Platform 中，并将继续被支持。但是，这个功能会在以后的发行版本中被删除，且不建议在新的部署中使用。

      另外，您不能将计算机器升级到 RHEL 8，因为本发行版本中没有相关支持。

      有关 OpenShift Container Platform 中已弃用或删除的主要功能的最新列表，请参阅 OpenShift Container Platform 发行注记中已弃用和删除的功能部分。

    • 如果以 FIPS 模式部署 OpenShift Container Platform，则需要在 RHEL 机器上启用 FIPS，然后才能引导它。请参阅 RHEL 7 文档中的启用 FIPS 模式 。
重要

只有在 x86_64 架构中的 OpenShift Container Platform 部署支持 FIPS 验证的/Modules in Process 加密库。

  • NetworkManager 1.0 或更高版本。
  • 1 个 vCPU。
  • 最小 8 GB RAM。
  • 最小15 GB 硬盘空间，用于包含 /var/ 的文件系统。
  • 最小1 GB 硬盘空间，用于包含 /usr/local/bin/ 的文件系统。

  • 最小1 GB 硬盘空间，用于包含系统临时目录的文件系统。系统的临时目录根据 Python 标准库中 tempfile 模块中定义的规则确定。

    • 每个系统都必须满足您的系统提供商的任何其他要求。例如，如果在 VMware vSphere 上安装了集群，必须根据其存储准则配置磁盘，而且必须设置 disk.enableUUID=true 属性。
    • 每个系统都必须能够使用 DNS 可解析的主机名访问集群的 API 端点。任何现有的网络安全访问控制都必须允许系统访问集群的 API 服务端点。
5.1.2.1. 证书签名请求管理
复制链接

在使用您置备的基础架构时，集群只能有限地访问自动机器管理，因此您必须提供一种在安装后批准集群证书签名请求 (CSR) 的机制。kube-controller-manager 只能批准 kubelet 客户端 CSR。machine-approver 无法保证使用 kubelet 凭证请求的提供证书的有效性，因为它不能确认是正确的机器发出了该请求。您必须决定并实施一种方法，以验证 kubelet 提供证书请求的有效性并进行批准。

5.1.3. 准备机器以运行 Playbook
复制链接

在将使用 Red Hat Enterprise Linux(RHEL)作为操作系统的计算机器添加到 OpenShift Container Platform 4.7 集群之前，您必须准备 RHEL 7 机器来运行将新节点添加到集群中的 Ansible playbook。这台机器不是集群的一部分，但必须能够访问集群。

先决条件

  • 在运行 playbook 的机器上安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 权限的用户身份登录。

流程

  1. 确保机器上具有集群的 kubeconfig 文件，以及用于安装集群的安装程序。若要实现这一目标，一种方法是使用安装集群时所用的同一台机器。
  2. 配置机器，以访问您计划用作计算机器的所有 RHEL 主机。您可以使用公司允许的任何方法，包括使用 SSH 代理或 VPN 的堡垒主机。

  3. 在运行 playbook 的机器上配置一个用户，该用户对所有 RHEL 主机具有 SSH 访问权限。

    重要

    如果使用基于 SSH 密钥的身份验证，您必须使用 SSH 代理来管理密钥。

  4. 如果还没有这样做，请使用 RHSM 注册机器，并为它附加一个带有 OpenShift 订阅的池：

    1. 使用 RHSM 注册机器： 

      # subscription-manager register --username=<user_name> --password=<password>
      Copy to Clipboard Toggle word wrap

    2. 从 RHSM 获取最新的订阅数据： 

      # subscription-manager refresh
      Copy to Clipboard Toggle word wrap

    3. 列出可用的订阅： 

      # subscription-manager list --available --matches '*OpenShift*'
      Copy to Clipboard Toggle word wrap

    4. 在上一命令的输出中，找到 OpenShift Container Platform 订阅的池 ID 并附加该池： 

      # subscription-manager attach --pool=<pool_id>
      Copy to Clipboard Toggle word wrap

  5. 启用 OpenShift Container Platform 4.7 所需的仓库： 

    # subscription-manager repos \
    --enable="rhel-7-server-rpms" \
    --enable="rhel-7-server-extras-rpms" \
    --enable="rhel-7-server-ansible-2.9-rpms" \
    --enable="rhel-7-server-ose-4.7-rpms"
    Copy to Clipboard Toggle word wrap

  6. 安装所需的软件包，包括 openshift-ansible: 

    # yum install openshift-ansible openshift-clients jq
    Copy to Clipboard Toggle word wrap

    openshift-ansible 软件包提供了安装实用程序，并且会拉取将 RHEL 计算节点添加到集群所需要的其他软件包，如 Ansible、playbook 和相关的配置文件。openshift-clients 提供 oc CLI，jq 软件包则可改善命令行中 JSON 输出的显示。

5.1.4. 准备 RHEL 计算节点
复制链接

在将 Red Hat Enterprise Linux (RHEL) 机器添加到 OpenShift Container Platform 集群之前，您必须将每台主机注册到 Red Hat Subscription Manager (RHSM)，为其附加有效的 OpenShift Container Platform 订阅，并且启用所需的存储库。

  1. 在每一主机上进行 RHSM 注册： 

    # subscription-manager register --username=<user_name> --password=<password>
    Copy to Clipboard Toggle word wrap

  2. 从 RHSM 获取最新的订阅数据： 

    # subscription-manager refresh
    Copy to Clipboard Toggle word wrap

  3. 列出可用的订阅： 

    # subscription-manager list --available --matches '*OpenShift*'
    Copy to Clipboard Toggle word wrap

  4. 在上一命令的输出中，找到 OpenShift Container Platform 订阅的池 ID 并附加该池： 

    # subscription-manager attach --pool=<pool_id>
    Copy to Clipboard Toggle word wrap

  5. 禁用所有 yum 存储库：

    1. 禁用所有已启用的 RHSM 存储库： 

      # subscription-manager repos --disable="*"
      Copy to Clipboard Toggle word wrap

    2. 列出剩余的 yum 存储库，并记录它们在 repo id 下的名称（若有）： 

      # yum repolist
      Copy to Clipboard Toggle word wrap

    3. 使用 yum-config-manager 禁用剩余的 yum 存储库： 

      # yum-config-manager --disable <repo_id>
      Copy to Clipboard Toggle word wrap

      或者，禁用所有存储库： 

      # yum-config-manager --disable \*
      Copy to Clipboard Toggle word wrap

      请注意，有大量可用存储库时可能需要花费几分钟

  6. 仅启用 OpenShift Container Platform 4.7 需要的仓库： 

    # subscription-manager repos \
    --enable="rhel-7-server-rpms" \
    --enable="rhel-7-fast-datapath-rpms" \
    --enable="rhel-7-server-extras-rpms" \
    --enable="rhel-7-server-optional-rpms" \
    --enable="rhel-7-server-ose-4.7-rpms"
    Copy to Clipboard Toggle word wrap

  7. 停止并禁用主机上的防火墙： 

    # systemctl disable --now firewalld.service
    Copy to Clipboard Toggle word wrap
    注意

    请不要在以后启用防火墙。如果这样做，则无法访问 worker 上的 OpenShift Container Platform 日志。

5.1.5. 在集群中添加 RHEL 计算机器
复制链接

您可以将使用 Red Hat Enterprise Linux 作为操作系统的计算机器添加到 OpenShift Container Platform 4.7 集群中。

先决条件

  • 运行 playbook 的机器上已安装必需的软件包并且执行了必要的配置。
  • RHEL 主机已做好安装准备。

流程

在为运行 playbook 而准备的机器上执行以下步骤：

  1. 创建一个名为 /<path>/inventory/hosts 的 Ansible 清单文件，以定义您的计算机器主机和必要的变量： 

    [all:vars]
ansible_user=root
    1 
    
#ansible_become=True
    2 
    

openshift_kubeconfig_path="~/.kube/config"
    3 
    

[new_workers]
    4 
    
mycluster-rhel7-0.example.com
mycluster-rhel7-1.example.com
    Copy to Clipboard Toggle word wrap
    1
    指定要在远程计算机器上运行 Ansible 任务的用户名。
    2
    如果不将 root 指定为 ansible_user，您必须将 ansible_become 设置为 True，并为该用户分配 sudo 权限。
    3
    指定集群的 kubeconfig 文件的路径和文件名。
    4
    列出要添加到集群中的每台 RHEL 机器。必须为每个主机提供完全限定域名。此名称是集群用来访问机器的主机名，因此请设置用于访问机器的正确公共或私有名称。

  2. 进入到 Ansible playbook 目录： 

    $ cd /usr/share/ansible/openshift-ansible
    Copy to Clipboard Toggle word wrap

  3. 运行 playbook： 

    $ ansible-playbook -i /<path>/inventory/hosts playbooks/scaleup.yml
    1
    Copy to Clipboard Toggle word wrap
    1
    对于<path> ，指定您创建的Ansible库存文件的路径。

5.1.6. Ansible hosts 文件的必要参数
复制链接

在将 Red Hat Enterprise Linux (RHEL) 计算机器添加到集群之前，必须在 Ansible hosts 文件中定义以下参数。

Expand
参数描述值

ansible_user

能够以免密码方式进行 SSH 身份验证的 SSH 用户。如果使用基于 SSH 密钥的身份验证，则必须使用 SSH 代理来管理密钥。

系统上的用户名。默认值为 root。

ansible_become

如果 ansible_user 的值不是 root，您必须将 ansible_become 设置为 True，并且您指定为 ansible_user 的用户必须配置有免密码 sudo 访问权限。

True。如果值不是 True，请不要指定和定义此参数。

openshift_kubeconfig_path

指定包含集群的 kubeconfig 文件的本地目录的路径和文件名。

配置文件的路径和名称。

5.1.7. 可选：从集群中删除 RHCOS 计算机器
复制链接

将 Red Hat Enterprise Linux（RHEL）计算机器添加到集群后，您可以选择性地删除 Red Hat Enterprise Linux CoreOS（RHCOS）计算机器来释放资源。

先决条件

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

流程

  1. 查看机器列表并记录 RHCOS 计算机器的节点名称： 

    $ oc get nodes -o wide
    Copy to Clipboard Toggle word wrap

  2. 对于每一台 RHCOS 计算机器，删除其节点：

    1. 通过运行 oc adm cordon 命令，将节点标记为不可调度： 

      $ oc adm cordon <node_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      指定其中一台 RHCOS 计算机器的节点名称。

    2. 清空节点中的所有 Pod： 

      $ oc adm drain <node_name> --force --delete-emptydir-data --ignore-daemonsets
      1
      Copy to Clipboard Toggle word wrap
      1
      指定您隔离的 RHCOS 计算机器的节点名称。

    3. 删除节点： 

      $ oc delete nodes <node_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      指定您清空的 RHCOS 计算机器的节点名称。

  3. 查看计算机器的列表，以确保仅保留 RHEL 节点： 

    $ oc get nodes -o wide
    Copy to Clipboard Toggle word wrap
  4. 从集群的计算机器的负载均衡器中删除 RHCOS 机器。您可以删除虚拟机或重新制作 RHCOS 计算机器物理硬件的镜像。

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

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

5.2.1. 先决条件
复制链接

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

5.2.2. 使用 ISO 镜像创建更多 RHCOS 机器
复制链接

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

先决条件

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

流程

  1. 使用 ISO 文件在更多计算机器上安装 RHCOS。在安装集群前，使用创建机器时使用的相同方法：

    • 将 ISO 镜像刻录到磁盘并直接启动。
    • 在 LOM 接口中使用 ISO 重定向。
  2. 实例启动后，按 TAB 或 E 键编辑内核命令行。

  3. 将参数添加到内核命令行： 

    coreos.inst.install_dev=sda
    1 
    
coreos.inst.ignition_url=http://example.com/worker.ign
    2
    Copy to Clipboard Toggle word wrap
    1
    指定要安装到的系统块设备。
    2
    指定计算 Ignition 配置文件的 URL。只支持 HTTP 和 HTTPS 协议。
  4. 按 Enter 键完成安装。安装 RHCOS 后，系统会重启。系统重启后，它会应用您指定的 Ignition 配置文件。
  5. 继续为集群创建更多计算机器。

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

先决条件

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

流程

  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
      Copy to Clipboard Toggle word wrap
      1
      指定上传到 HTTP 服务器的 live kernel 文件位置。
      2
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。initrd 参数值是 live initramfs 文件的位置，coreos.inst.ignition_url 参数值是 worker Ignition 配置文件的位置，coreos.live.rootfs_url 参数值是 live rootfs 文件的位置。coreos.inst.ignition_url 和 coreos.live.rootfs_url 参数仅支持 HTTP 和 HTTPS。

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

  • 对于 iPXE： 

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

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

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

5.2.4. 批准机器的证书签名请求
复制链接

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

先决条件

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

流程

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.20.0
master-1  Ready     master  63m  v1.20.0
master-2  Ready     master  64m  v1.20.0
    Copy to Clipboard Toggle word wrap

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

    注意

    在一些 CSR 被批准前，以上输出可能不包括计算节点（也称为 worker 节点）。

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    输出示例

    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
...
    Copy to Clipboard Toggle word wrap

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

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

    注意

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

    注意

    对于在未启用机器 API 的平台中运行的集群，如裸机和其他用户置备的基础架构，必须采用一种方法自动批准 kubelet 提供证书请求（CSR）。如果没有批准请求，则 oc exec、oc rsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。这个方法必须监视新的 CSR，确认 CSR 由 system:node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。

    • 若要单独批准，请对每个有效的 CSR 运行以下命令： 

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      注意

      在有些 CSR 被批准前，一些 Operator 可能无法使用。

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    输出示例

    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
...
    Copy to Clipboard Toggle word wrap

  5. 如果剩余的 CSR 没有被批准，且处于 Pending 状态，请批准集群机器的 CSR：

    • 若要单独批准，请对每个有效的 CSR 运行以下命令： 

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.20.0
master-1  Ready     master  73m  v1.20.0
master-2  Ready     master  74m  v1.20.0
worker-0  Ready     worker  11m  v1.20.0
worker-1  Ready     worker  11m  v1.20.0
    Copy to Clipboard Toggle word wrap

    注意

    批准服务器 CSR 后可能需要几分钟时间让机器转换为 Ready 状态。

其他信息

5.3. 部署机器健康检查
复制链接

理解并部署机器健康检查。

重要

此过程不适用于使用手动置备的机器的集群。您只能在 Machine API 操作的集群中使用高级机器管理和扩展功能。

5.3.1. 关于机器健康检查
复制链接

机器健康检查自动修复特定机器池中不健康的机器。

要监控机器的健康状况，创建资源来定义控制器的配置。设置要检查的条件（例如，处于 NotReady 状态达到 5 分钟或 node-problem-detector 中显示了持久性状况），以及用于要监控的机器集合的标签。

注意

您不能对具有 master 角色的机器进行机器健康检查。

监控 MachineHealthCheck 资源的控制器会检查定义的条件。如果机器无法进行健康检查，则会自动删除机器并创建一个机器来代替它。删除机器之后，您会看到机器被删除事件。

为限制删除机器造成的破坏性影响，控制器一次仅清空并删除一个节点。如果目标机器池中不健康的机器池中不健康的机器数量大于 maxUnhealthy 的值，则补救会停止，需要启用手动干预。

注意

请根据工作负载和要求仔细考虑超时。

  • 超时时间较长可能会导致不健康的机器上的工作负载长时间停机。
  • 超时时间太短可能会导致补救循环。例如，检查 NotReady 状态的超时时间必须足够长，以便机器能够完成启动过程。

要停止检查，请删除资源。

5.3.1.1. 部署机器健康检查时的限制
复制链接

部署机器健康检查前需要考虑以下限制：

  • 只有机器集拥有的机器才可以由机器健康检查修复。
  • 目前不支持 control plane 机器，如果不健康，则不会被修复。
  • 如果机器的节点从集群中移除，机器健康检查会认为机器不健康，并立即修复机器。
  • 如果机器对应的节点在 nodeStartupTimeout 之后没有加入集群，则会修复机器。
  • 如果 Machine 资源阶段为 Failed，则会立即修复机器。

5.3.2. MachineHealthCheck 资源示例
复制链接

所有基于云的安装类型的 MachineHealthCheck 资源，以及裸机以外的资源，类似以下 YAML 文件： 

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
1 

  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role>
2 

      machine.openshift.io/cluster-api-machine-type: <role>
3 

      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone>
4 

  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"
5 

    status: "False"
  - type:    "Ready"
    timeout: "300s"
6 

    status: "Unknown"
  maxUnhealthy: "40%"
7 

  nodeStartupTimeout: "10m"
8
Copy to Clipboard Toggle word wrap
1
指定要部署的机器健康检查的名称。
2 3
为要检查的机器池指定一个标签。
4
以 <cluster_name>-<label>-<zone> 格式 指定要跟踪的机器集。例如，prod-node-us-east-1a。
5 6
指定节点条件的超时持续时间。如果在超时时间内满足了条件，则会修复机器。超时时间较长可能会导致不健康的机器上的工作负载长时间停机。
7
指定目标池中允许同时修复的机器数量。这可设为一个百分比或一个整数。如果不健康的机器数量超过 maxUnhealthy 设定的限制，则不会执行补救。
8
指定机器健康检查在决定机器不健康前必须等待节点加入集群的超时持续时间。
注意

matchLabels 只是示例; 您必须根据具体需要映射您的机器组。

5.3.2.1. 短路机器健康检查补救
复制链接

短路可确保仅在集群健康时机器健康检查修复机器。通过 MachineHealthCheck 资源中的 maxUnhealthy 字段配置短路。

如果用户在修复任何机器前为 maxUnhealthy 字段定义了一个值，MachineHealthCheck 会将 maxUnhealthy 的值与它决定不健康的目标池中的机器数量进行比较。如果不健康的机器数量超过 maxUnhealthy 限制，则不会执行补救。

重要

如果没有设置 maxUnhealthy，则默认值为 100%，无论集群状态如何，机器都会被修复。

适当的 maxUnhealthy 值取决于您部署的集群规模以及 MachineHealthCheck 覆盖的机器数量。例如，您可以使用 maxUnhealthy 值覆盖多个可用区间的多个机器集，以便在丢失整个区时，maxUnhealthy 设置可以在集群中阻止进一步补救。

maxUnhealthy 字段可以设置为整数或百分比。根据 maxUnhealthy 值，有不同的补救实现。

5.3.2.1.1. 使用绝对值设置 maxUnhealthy
复制链接

如果将 maxUnhealthy 设为 2:

  • 如果 2 个或更少节点不健康，则可执行补救
  • 如果 3 个或更多节点不健康，则不会执行补救

这些值与机器健康检查要检查的机器数量无关。

5.3.2.1.2. 使用百分比设置 maxUnhealthy
复制链接

如果 maxUnhealthy 被设置为 40%，有 25 个机器被检查：

  • 如果有 10 个或更少节点处于不健康状态，则可执行补救
  • 如果 11 个或多个节点不健康，则不会执行补救

如果 maxUnhealthy 被设置为 40%，有 6 个机器被检查：

  • 如果 2 个或更少节点不健康，则可执行补救
  • 如果 3 个或更多节点不健康，则不会执行补救
注意

当被检查的 maxUnhealthy 机器的百分比不是一个整数时，允许的机器数量会被舍入到一个小的整数。

5.3.3. 创建 MachineHealthCheck 资源
复制链接

您可以为集群中的所有 MachineSet 创建 MachineHealthCheck 资源。您不应该创建针对 control plane 机器的 MachineHealthCheck 资源。

先决条件

  • 安装 oc 命令行界面。

流程

  1. 创建一个 healthcheck.yml 文件，其中包含您的机器健康检查的定义。

  2. 将 healthcheck.yml 文件应用到您的集群： 

    $ oc apply -f healthcheck.yml
    Copy to Clipboard Toggle word wrap

5.3.4. 手动扩展机器集
复制链接

要在机器集中添加或删除机器实例，您可以手动扩展机器集。

这个指南与全自动的、安装程序置备的基础架构安装相关。自定义的、用户置备的基础架构安装没有机器集。

先决条件

  • 安装 OpenShift Container Platform 集群和 oc 命令行。
  • 以具有 cluster-admin 权限的用户身份登录 oc。

流程

  1. 查看集群中的机器集： 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    机器集以 <clusterid>-worker-<aws-region-az> 的形式列出。

  2. 查看集群中的机器： 

    $ oc get machine -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 在您要删除的机器上设置注解： 

    $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/cluster-api-delete-machine="true"
    Copy to Clipboard Toggle word wrap

  4. cordon 并排空您要删除的节点： 

    $ oc adm cordon <node_name>
$ oc adm drain <node_name>
    Copy to Clipboard Toggle word wrap

  5. 扩展机器集： 

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    或者： 

    $ oc edit machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    您可以扩展或缩减机器集。需要过几分钟以后新机器才可用。

验证

  • 验证删除预期的机器： 

    $ oc get machines
    Copy to Clipboard Toggle word wrap

5.3.5. 了解机器集和机器配置池之间的区别
复制链接

MachineSet 对象描述了与云或机器供应商相关的 OpenShift Container Platform 节点。

MachineConfigPool 对象允许 MachineConfigController 组件在升级过程中定义并提供机器的状态。

MachineConfigPool 对象允许用户配置如何将升级应用到机器配置池中的 OpenShift Container Platform 节点。

NodeSelector 对象可以被一个到 MachineSet 对象的引用替换。

5.4. 推荐的节点主机实践
复制链接

OpenShift Container Platform 节点配置文件包含重要的选项。例如，控制可以为节点调度的最大 pod 数量的两个参数: podsPerCore 和 maxPods。

当两个参数都被设置时，其中较小的值限制了节点上的 pod 数量。超过这些值可导致：

  • CPU 使用率增加。
  • 减慢 pod 调度的速度。
  • 根据节点中的内存数量，可能出现内存耗尽的问题。
  • 耗尽 IP 地址池。
  • 资源过量使用，导致用户应用程序性能变差。
重要

在 Kubernetes 中，包含单个容器的 pod 实际使用两个容器。第二个容器用来在实际容器启动前设置联网。因此，运行 10 个 pod 的系统实际上会运行 20 个容器。

注意

云供应商的磁盘 IOPS 节流可能会对 CRI-O 和 kubelet 产生影响。当节点上运行大量 I/O 高负载的 pod 时，可能会出现超载的问题。建议您监控节点上的磁盘 I/O，并使用有足够吞吐量的卷。

podsPerCore 根据节点中的处理器内核数来设置节点可运行的 pod 数量。例如：在一个有 4 个处理器内核的节点上将 podsPerCore 设为 10 ，则该节点上允许的最大 pod 数量为 40。 

kubeletConfig:
  podsPerCore: 10
Copy to Clipboard Toggle word wrap

将 podsPerCore 设置为 0 可禁用这个限制。默认为 0。podsPerCore 不能超过 maxPods。

maxPods 把节点可以运行的 pod 数量设置为一个固定值，而不需要考虑节点的属性。 

 kubeletConfig:
    maxPods: 250
Copy to Clipboard Toggle word wrap

5.4.1. 创建 KubeletConfig CRD 来编辑 kubelet 参数
复制链接

kubelet 配置目前被序列化为 Ignition 配置，因此可以直接编辑。但是，在 Machine Config Controller (MCC) 中同时添加了新的 kubelet-config-controller 。这可让您使用 KubeletConfig 自定义资源 (CR) 来编辑 kubelet 参数。

注意

因为 kubeletConfig 对象中的字段直接从上游 Kubernetes 传递给 kubelet，kubelet 会直接验证这些值。kubeletConfig 对象中的无效值可能会导致集群节点不可用。有关有效值，请参阅 Kubernetes 文档。

请考虑以下指导：

  • 为每个机器配置池创建一个 KubeletConfig CR，带有该池需要更改的所有配置。如果要将相同的内容应用到所有池，则所有池仅需要一个 KubeletConfig CR。
  • 编辑现有的 KubeletConfig CR 以修改现有设置或添加新设置，而不是为每个更改创建一个 CR。建议您仅创建一个 CR 来修改不同的机器配置池，或用于临时更改，以便您可以恢复更改。
  • 根据需要，创建多个 KubeletConfig CR，每个集群限制为 10。对于第一个 KubeletConfig CR，Machine Config Operator (MCO) 会创建一个机器配置，并附带 kubelet。对于每个后续 CR，控制器会创建另一个带有数字后缀的 kubelet 机器配置。例如，如果您有一个带有 -2 后缀的 kubelet 机器配置，则下一个 kubelet 机器配置会附加 -3。

如果要删除机器配置，以相反的顺序删除它们，以避免超过限制。例如，在删除 kubelet-2 机器配置前删除 kubelet-3 机器配置。

注意

如果您有一个带有 kubelet-9 后缀的机器配置，并且创建了另一个 KubeletConfig CR，则不会创建新的机器配置，即使少于 10 个 kubelet 机器配置。

KubeletConfig CR 示例

$ oc get kubeletconfig
Copy to Clipboard Toggle word wrap 

NAME                AGE
set-max-pods        15m
Copy to Clipboard Toggle word wrap

显示 KubeletConfig 机器配置示例

$ oc get mc | grep kubelet
Copy to Clipboard Toggle word wrap 

...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
...
Copy to Clipboard Toggle word wrap

以下流程演示了如何配置 worker 节点上的每个节点的最大 pod 数量。

先决条件

  1. 为您要配置的节点类型获取与静态 MachineConfigPool CR 关联的标签。执行以下步骤之一：

    1. 查看机器配置池： 

      $ oc describe machineconfigpool <name>
      Copy to Clipboard Toggle word wrap

      例如： 

      $ oc describe machineconfigpool worker
      Copy to Clipboard Toggle word wrap

      输出示例

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: 2019-02-08T14:52:39Z
  generation: 1
  labels:
    custom-kubelet: set-max-pods
      1
      Copy to Clipboard Toggle word wrap

      1
      如果添加了标签，它会出现在 labels 下。

    2. 如果标签不存在，则添加一个键/值对： 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods
      Copy to Clipboard Toggle word wrap

流程

  1. 查看您可以选择的可用机器配置对象： 

    $ oc get machineconfig
    Copy to Clipboard Toggle word wrap

    默认情况下，与 kubelet 相关的配置为 01-master-kubelet 和 01-worker-kubelet。

  2. 检查每个节点的最大 pod 的当前值： 

    $ oc describe node <node_name>
    Copy to Clipboard Toggle word wrap

    例如： 

    $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94
    Copy to Clipboard Toggle word wrap

    在 Allocatable 小节中找到 value: pods: <value>：

    输出示例

    Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         3500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      15341844Ki
 pods:                        250
    Copy to Clipboard Toggle word wrap

  3. 通过创建一个包含 kubelet 配置的自定义资源文件，设置 worker 节点上的每个节点的最大 pod： 

    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
    Copy to Clipboard Toggle word wrap
    1
    输入机器配置池中的标签。
    2
    添加 kubelet 配置。在本例中，使用 maxPods 设置每个节点的最大 pod。
    注意

    kubelet 与 API 服务器进行交互的频率取决于每秒的查询数量 (QPS) 和 burst 值。如果每个节点上运行的 pod 数量有限，使用默认值（kubeAPIQPS 为 50，kubeAPIBurst 为 100）就可以。如果节点上有足够 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>
    Copy to Clipboard Toggle word wrap

    1. 为带有标签的 worker 更新机器配置池： 

      $ oc label machineconfigpool worker custom-kubelet=large-pods
      Copy to Clipboard Toggle word wrap

    2. 创建 KubeletConfig 对象： 

      $ oc create -f change-maxPods-cr.yaml
      Copy to Clipboard Toggle word wrap

    3. 验证 KubeletConfig 对象是否已创建： 

      $ oc get kubeletconfig
      Copy to Clipboard Toggle word wrap

      输出示例

      NAME                AGE
set-max-pods        15m
      Copy to Clipboard Toggle word wrap

      根据集群中的 worker 节点数量，等待每个 worker 节点被逐个重启。对于有 3 个 worker 节点的集群，这个过程可能需要大约 10 到 15 分钟。

  4. 验证更改是否已应用到节点：

    1. 在 worker 节点上检查 maxPods 值已更改： 

      $ oc describe node <node_name>
      Copy to Clipboard Toggle word wrap

    2. 找到 Allocatable 小节： 

       ...
Allocatable:
  attachable-volumes-gce-pd:  127
  cpu:                        3500m
  ephemeral-storage:          123201474766
  hugepages-1Gi:              0
  hugepages-2Mi:              0
  memory:                     14225400Ki
  pods:                       500
      1 
      
 ...
      Copy to Clipboard Toggle word wrap
      1
      在本例中，pods 参数应报告您在 KubeletConfig 对象中设置的值。

  5. 验证 KubeletConfig 对象中的更改： 

    $ oc get kubeletconfigs set-max-pods -o yaml
    Copy to Clipboard Toggle word wrap

    这应该会显示 status: "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
    Copy to Clipboard Toggle word wrap

5.4.2. 修改不可用 worker 节点的数量
复制链接

默认情况下，在对可用的 worker 节点应用 kubelet 相关的配置时，只允许一台机器不可用。对于大型集群来说，它可能需要很长时间才可以反映出配置的更改。在任何时候，您可以调整更新的机器数量来加快进程速度。

流程

  1. 编辑 worker 机器配置池： 

    $ oc edit machineconfigpool worker
    Copy to Clipboard Toggle word wrap

  2. 将 maxUnavailable 设置为您需要的值： 

    spec:
  maxUnavailable: <node_count>
    Copy to Clipboard Toggle word wrap
    重要

    当设置该值时，请考虑无法使用的 worker 节点数量，而不影响在集群中运行的应用程序。

5.4.3. Control plane 节点大小
复制链接

control plane 节点对资源的要求取决于集群中的节点数量。以下推荐的 control plane 节点大小是基于 control plane 密度测试的结果。control plane 测试会根据节点数在每个命名空间中在集群中创建以下对象：

  • 12 个镜像流
  • 3 个构建配置
  • 6 个构建
  • 1 个部署，带有 2 个 pod 副本，每个都挂载两个 secret
  • 2 个部署，带有 1 个 pod 副本，挂载了两个 secret
  • 3 个指向以前部署的服务
  • 3 个指向之前部署的路由
  • 10 个 secret，其中 2 个由以前的部署挂载
  • 10 个配置映射，其中 2 个由以前的部署挂载
Expand
worker 节点数量集群负载（命名空间）CPU 内核内存 (GB)

25

500

4

16

100

1000

8

32

250

4000

16

96

在具有三个 master 或 control plane 节点的大型高密度集群中，当其中一个节点停止、重启或失败时，CPU 和内存用量将会激增。故障可能是因为电源、网络或底层基础架构出现意外问题，除了在关闭集群后重启集群以节约成本的情况下。其余两个 control plane 节点必须处理负载才能高度可用，从而增加资源使用量。另外，在升级过程中还会有这个预期，因为 master 被封锁、排空并按顺序重新引导，以应用操作系统更新以及 control plane Operator 更新。为了避免级联失败，请将 control plane 节点上的总 CPU 和内存资源使用量至最多 60% 的所有可用容量，以处理资源用量增加。相应地增加 control plane 节点上的 CPU 和内存，以避免因为缺少资源而造成潜在的停机。

重要

节点大小取决于集群中的节点和对象数量。它还取决于集群上是否正在主动创建这些对象。在创建对象时，control plane 在资源使用量方面与对象处于运行（running）阶段的时间相比更活跃。

重要

如果使用安装程序置备的基础架构安装方法，则无法修改正在运行的 OpenShift Container Platform 4.7 集群中的 control plane 节点大小。反之，您必须估计节点总数并在安装过程中使用推荐的 control plane 节点大小。

重要

建议基于在带有 OpenShiftSDN 作为网络插件的 OpenShift Container Platform 集群上捕获的数据点。

注意

在 OpenShift Container Platform 4.7 中，与 OpenShift Container Platform 3.11 及之前的版本相比，系统现在默认保留半个 CPU 内核（500 millicore）。确定大小时应该考虑这一点。

5.4.4. 设置 CPU Manager
复制链接

流程

  1. 可选：标记节点： 

    # oc label node perf-node.example.com cpumanager=true
    Copy to Clipboard Toggle word wrap

  2. 编辑启用 CPU Manager 的节点的 MachineConfigPool 。在这个示例中，所有 worker 都启用了 CPU Manager： 

    # oc edit machineconfigpool worker
    Copy to Clipboard Toggle word wrap

  3. 为 worker 机器配置池添加标签： 

    metadata:
  creationTimestamp: 2020-xx-xxx
  generation: 3
  labels:
    custom-kubelet: cpumanager-enabled
    Copy to Clipboard Toggle word wrap

  4. 创建 KubeletConfig，cpumanager-kubeletconfig.yaml，自定义资源 (CR) 。请参阅上一步中创建的标签，以便使用新的 kubelet 配置更新正确的节点。请参见 MachineConfigPoolSelector 部分： 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cpumanager-enabled
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: cpumanager-enabled
  kubeletConfig:
     cpuManagerPolicy: static
    1 
    
     cpuManagerReconcilePeriod: 5s
    2
    Copy to Clipboard Toggle word wrap
    1
    指定一个策略：
    • none.这个策略明确启用了现有的默认 CPU 关联性方案，从而不会出现超越调度程序自动进行的关联性。
    • static。此策略允许具有某些资源特征的 pod 获得提高 CPU 关联性和节点上专用的 pod。
    2
    可选。指定 CPU Manager 协调频率。默认值为 5s。

  5. 创建动态 kubelet 配置： 

    # oc create -f cpumanager-kubeletconfig.yaml
    Copy to Clipboard Toggle word wrap

    这会在 kubelet 配置中添加 CPU Manager 功能，如果需要，Machine Config Operator（MCO）将重启节点。要启用 CPU Manager，则不需要重启。

  6. 检查合并的 kubelet 配置： 

    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7
    Copy to Clipboard Toggle word wrap

    输出示例

           "ownerReferences": [
            {
                "apiVersion": "machineconfiguration.openshift.io/v1",
                "kind": "KubeletConfig",
                "name": "cpumanager-enabled",
                "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
            }
        ]
    Copy to Clipboard Toggle word wrap

  7. 检查 worker 是否有更新的 kubelet.conf： 

    # oc debug node/perf-node.example.com
sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager
    Copy to Clipboard Toggle word wrap

    输出示例

    cpuManagerPolicy: static
    1 
    
cpuManagerReconcilePeriod: 5s
    2
    Copy to Clipboard Toggle word wrap

    1 2
    当创建 KubeletConfig CR 时会定义这些设置。

  8. 创建请求一个或多个内核的 pod。限制和请求都必须将其 CPU 值设置为一个整数。这是专用于此 pod 的内核数： 

    # cat cpumanager-pod.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    apiVersion: v1
kind: Pod
metadata:
  generateName: cpumanager-
spec:
  containers:
  - name: cpumanager
    image: gcr.io/google_containers/pause-amd64:3.0
    resources:
      requests:
        cpu: 1
        memory: "1G"
      limits:
        cpu: 1
        memory: "1G"
  nodeSelector:
    cpumanager: "true"
    Copy to Clipboard Toggle word wrap

  9. 创建 pod： 

    # oc create -f cpumanager-pod.yaml
    Copy to Clipboard Toggle word wrap

  10. 确定为您标记的节点调度了 pod： 

    # oc describe pod cpumanager
    Copy to Clipboard Toggle word wrap

    输出示例

    Name:               cpumanager-6cqz7
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:  perf-node.example.com/xxx.xx.xx.xxx
...
 Limits:
      cpu:     1
      memory:  1G
    Requests:
      cpu:        1
      memory:     1G
...
QoS Class:       Guaranteed
Node-Selectors:  cpumanager=true
    Copy to Clipboard Toggle word wrap

  11. 确认正确配置了 cgroups。获取 pause 进程的进程 ID（PID）： 

    # ├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
└─kubepods.slice
  ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
  │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
  │ └─32706 /pause
    Copy to Clipboard Toggle word wrap

    服务质量（QoS）等级为 Guaranteed 的 pod 被放置到 kubepods.slice 中。其它 QoS 等级的 pod 会位于 kubepods 的子 cgroups 中： 

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
# for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done
    Copy to Clipboard Toggle word wrap

    输出示例

    cpuset.cpus 1
tasks 32706
    Copy to Clipboard Toggle word wrap

  12. 检查任务允许的 CPU 列表： 

    # grep ^Cpus_allowed_list /proc/32706/status
    Copy to Clipboard Toggle word wrap

    输出示例

     Cpus_allowed_list:    1
    Copy to Clipboard Toggle word wrap

  13. 确认系统中的另一个 pod（在这个示例中，QoS 等级为 burstable 的 pod）不能在为等级为Guaranteed 的 pod 分配的内核中运行： 

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
0
# oc describe node perf-node.example.com
    Copy to Clipboard Toggle word wrap

    输出示例

    ...
Capacity:
 attachable-volumes-aws-ebs:  39
 cpu:                         2
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      8162900Ki
 pods:                        250
Allocatable:
 attachable-volumes-aws-ebs:  39
 cpu:                         1500m
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      7548500Ki
 pods:                        250
-------                               ----                           ------------  ----------  ---------------  -------------  ---
  default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests          Limits
  --------                    --------          ------
  cpu                         1440m (96%)       1 (66%)
    Copy to Clipboard Toggle word wrap

    这个 VM 有两个 CPU 内核。system-reserved 设置保留 500 millicores，这代表一个内核中的一半被从节点的总容量中减小，以达到 Node Allocatable 的数量。您可以看到 Allocatable CPU 是 1500 毫秒。这意味着您可以运行一个 CPU Manager pod，因为每个 pod 需要一个完整的内核。一个完整的内核等于 1000 毫秒。如果您尝试调度第二个 pod，系统将接受该 pod，但不会调度它： 

    NAME                    READY   STATUS    RESTARTS   AGE
cpumanager-6cqz7        1/1     Running   0          33m
cpumanager-7qc2t        0/1     Pending   0          11s
    Copy to Clipboard Toggle word wrap

5.5. 巨页
复制链接

了解并配置巨页。

5.5.1. 巨页的作用
复制链接

内存在块（称为页）中进行管理。在大多数系统中，页的大小为 4Ki。1Mi 内存相当于 256 个页，1Gi 内存相当于 256,000 个页。CPU 有内置的内存管理单元，可在硬件中管理这些页的列表。Translation Lookaside Buffer (TLB) 是虚拟页到物理页映射的小型硬件缓存。如果在硬件指令中包括的虚拟地址可以在 TLB 中找到，则其映射信息可以被快速获得。如果没有包括在 TLN 中，则称为 TLB miss。系统将会使用基于软件的，速度较慢的地址转换机制，从而出现性能降低的问题。因为 TLB 的大小是固定的，因此降低 TLB miss 的唯一方法是增加页的大小。

巨页指一个大于 4Ki 的内存页。在 x86_64 构架中，有两个常见的巨页大小: 2Mi 和 1Gi。在其它构架上的大小会有所不同。要使用巨页，必须写相应的代码以便应用程序了解它们。Transparent Huge Pages（THP）试图在应用程序不需要了解的情况下自动管理巨页，但这个技术有一定的限制。特别是，它的页大小会被限为 2Mi。当有较高的内存使用率时，THP 可能会导致节点性能下降，或出现大量内存碎片（因为 THP 的碎片处理）导致内存页被锁定。因此，有些应用程序可能更适用于（或推荐）使用预先分配的巨页，而不是 THP。

5.5.2. 应用程序如何使用巨页
复制链接

节点必须预先分配巨页以便节点报告其巨页容量。一个节点只能预先分配一个固定大小的巨页。

巨页可以使用名为 hugepages-<size> 的容器一级的资源需求被消耗。其中 size 是特定节点上支持的整数值的最精简的二进制标记。例如：如果某个节点支持 2048KiB 页大小，它将会有一个可调度的资源 hugepages-2Mi。与 CPU 或者内存不同，巨页不支持过量分配。 

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi
1 

        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard Toggle word wrap
1
为巨页指定要分配的准确内存数量。不要将这个值指定为巨页内存大小乘以页的大小。例如，巨页的大小为 2MB，如果应用程序需要使用由巨页组成的 100MB 的内存，则需要分配 50 个巨页。OpenShift Container Platform 会进行相应的计算。如上例所示，您可以直接指定 100MB 。

分配特定大小的巨页

有些平台支持多个巨页大小。要分配指定大小的巨页，在巨页引导命令参数前使用巨页大小选择参数hugepagesz=<size>。<size> 的值必须以字节为单位，并可以使用一个可选的后缀 [kKmMgG]。默认的巨页大小可使用 default_hugepagesz=<size> 引导参数定义。

巨页要求

  • 巨页面请求必须等于限制。如果指定了限制，则它是默认的，但请求不是。
  • 巨页在 pod 范围内被隔离。容器隔离功能计划在以后的版本中推出。
  • 后端为巨页的 EmptyDir 卷不能消耗大于 pod 请求的巨页内存。
  • 通过带有 SHM_HUGETLB 的 shmget() 来使用巨页的应用程序，需要运行一个匹配 proc/sys/vm/hugetlb_shm_group 的 supplemental 组。

5.5.3. 配置巨页
复制链接

节点必须预先分配在 OpenShift Container Platform 集群中使用的巨页。保留巨页的方法有两种： 在引导时和在运行时。在引导时进行保留会增加成功的可能性，因为内存还没有很大的碎片。Node Tuning Operator 目前支持在特定节点上分配巨页。

5.5.3.1. 在引导时
复制链接

流程

要减少节点重启的情况，请按照以下步骤顺序进行操作：

  1. 通过标签标记所有需要相同巨页设置的节点。 

    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=
    Copy to Clipboard Toggle word wrap

  2. 创建一个包含以下内容的文件，并把它命名为 hugepages_tuning.yaml： 

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: hugepages
    1 
    
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
    2 
    
  - data: |
      [main]
      summary=Boot time configuration for hugepages
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50
    3 
    
    name: openshift-node-hugepages

  recommend:
  - machineConfigLabels:
    4 
    
      machineconfiguration.openshift.io/role: "worker-hp"
    priority: 30
    profile: openshift-node-hugepages
    Copy to Clipboard Toggle word wrap
    1
    将 Tuned 资源的 name 设置为 hugepages。
    2
    将 profile 部分设置为分配巨页。
    3
    请注意，参数顺序是非常重要的，因为有些平台支持各种大小的巨页。
    4
    启用基于机器配置池的匹配。

  3. 创建 Tuned hugepages 配置集 

    $ oc create -f hugepages-tuned-boottime.yaml
    Copy to Clipboard Toggle word wrap

  4. 创建一个带有以下内容的文件，并把它命名为 hugepages-mcp.yaml： 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-hp
  labels:
    worker-hp: ""
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-hp: ""
    Copy to Clipboard Toggle word wrap

  5. 创建机器配置池： 

    $ oc create -f hugepages-mcp.yaml
    Copy to Clipboard Toggle word wrap

因为有足够的非碎片内存，worker-hp 机器配置池中的所有节点现在都应分配 50 个 2Mi 巨页。 

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
Copy to Clipboard Toggle word wrap
警告

目前，这个功能只在 Red Hat Enterprise Linux CoreOS（RHCOS）8.x worker 节点上被支持。在 Red Hat Enterprise Linux（RHEL）7.x worker 节点上，目前不支持 Tuned [bootloader] 插件。

5.6. 了解设备插件
复制链接

设备插件提供一致并可移植的解决方案，以便跨集群消耗硬件设备。设备插件通过一种扩展机制提供对这些设备的支持，从而将设备提供给容器，提供设备健康检查，并且安全地共享设备。

重要

OpenShift Container Platform 支持设备插件 API，但设备插件容器则由各家供应商提供支持。

设备插件是在节点（kubelet 的外部）上运行的 gRPC 服务，负责管理特定的硬件资源。任何设备插件都必须支持以下远程过程调用 (RPC)： 

service DevicePlugin {
      // GetDevicePluginOptions returns options to be communicated with Device
      // Manager
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plug-in can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // PreStartcontainer is called, if indicated by Device Plug-in during
      // registration phase, before each container start. Device plug-in
      // can run device specific operations such as reseting the device
      // before making devices available to the container
      rpc PreStartcontainer(PreStartcontainerRequest) returns (PreStartcontainerResponse) {}
}
Copy to Clipboard Toggle word wrap
设备插件示例
注意

对于简单设备插件参考实现，设备管理器代码中提供了一个存根设备插件：vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go。

5.6.1. 设备插件部署方法
复制链接

  • 守护进程集是设备插件部署的推荐方法。
  • 在启动时，设备插件会尝试在节点上的 /var/lib/kubelet/device-plugin/ 创建一个 UNIX 域套接字，以服务来自于设备管理器的 RPC。
  • 由于设备插件必须管理硬件资源、主机文件系统的访问权以及套接字创建，它们必须在一个特权安全上下文中运行。
  • 各种设备插件实现中提供了有关部署步骤的更多细节。

5.6.2. 了解设备管理器
复制链接

设备管理器提供了一种机制，可借助称为“设备插件”的插件公告专用节点硬件资源。

您可以公告专用的硬件，而不必修改任何上游代码。

重要

OpenShift Container Platform 支持设备插件 API，但设备插件容器则由各家供应商提供支持。

设备管理器将设备公告为外部资源。用户 pod 可以利用相同的限制/请求机制来使用设备管理器公告的设备，这一机制也用于请求任何其他扩展资源。

在启动时，设备插件通过在 /var/lib/kubelet/device-plugins/kubelet.sock 上调用 Register 将自身注册到设备管理器，再启动位于 /var/lib/kubelet/device-plugins/<plugin>.sock 的 gRPC 服务来服务设备管理器请求。

在处理新的注册请求时，设备管理器会在设备插件服务中调用 ListAndWatch 远程过程调用 (RPC)。作为响应，设备管理器通过 gRPC 流从插件中获取设备对象的列表。设备管理器对流进行持续监控，以确认插件有没有新的更新。在插件一端，插件也会使流保持开放；只要任何设备的状态有所改变，就会通过相同的流传输连接将新设备列表发送到设备管理器。

在处理新的 pod 准入请求时，Kubelet 将请求的扩展资源传递给设备管理器以进行设备分配。设备管理器在其数据库中检查，以验证是否存在对应的插件。如果插件存在并且有可分配的设备及本地缓存，则在该特定设备插件上调用 Allocate RPC。

此外，设备插件也可以执行其他几个特定于设备的操作，如驱动程序安装、设备初始化和设备重置。这些功能视具体实现而异。

5.6.3. 启用设备管理器
复制链接

启用设备管理器来实现设备插件，在不更改上游代码的前提下公告专用硬件。

设备管理器提供了一种机制，可借助称为“设备插件”的插件公告专用节点硬件资源。

  1. 为您要配置的节点类型获取与静态 MachineConfigPool CRD 关联的标签。执行以下步骤之一：

    1. 查看机器配置： 

      # oc describe machineconfig <name>
      Copy to Clipboard Toggle word wrap

      例如： 

      # oc describe machineconfig 00-worker
      Copy to Clipboard Toggle word wrap

      输出示例

      Name:         00-worker
Namespace:
Labels:       machineconfiguration.openshift.io/role=worker
      1
      Copy to Clipboard Toggle word wrap

      1
      设备管理器所需标签。

流程

  1. 为配置更改创建自定义资源 (CR)。

    设备管理器 CR 配置示例

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: devicemgr
    1 
    
spec:
  machineConfigPoolSelector:
    matchLabels:
       machineconfiguration.openshift.io: devicemgr
    2 
    
  kubeletConfig:
    feature-gates:
      - DevicePlugins=true
    3
    Copy to Clipboard Toggle word wrap

    1
    为 CR 分配一个名称。
    2
    输入来自机器配置池的标签。
    3
    将 DevicePlugins 设为“true”。

  2. 创建设备管理器： 

    $ oc create -f devicemgr.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    kubeletconfig.machineconfiguration.openshift.io/devicemgr created
    Copy to Clipboard Toggle word wrap

  3. 通过确认节点上已创建了 /var/lib/kubelet/device-plugins/kubelet.sock，确保已启用了设备管理器。这是设备管理器 gRPC 服务器在其上侦听新插件注册的 UNIX 域套接字。只有启用了设备管理器，才会在 Kubelet 启动时创建此 sock 文件。

5.7. 污点和容限
复制链接

理解并使用污点和容限。

5.7.1. 了解污点和容限
复制链接

通过使用污点（taint），节点可以拒绝调度 pod，除非 pod 具有匹配的容限（toleration）。

您可以通过节点规格（NodeSpec）将污点应用到节点，并通过 Pod 规格（PodSpec）将容限应用到 pod。当您应用污点时，调度程序无法将 pod 放置到该节点上，除非 pod 可以容限该污点。

节点规格中的污点示例

spec:
....
  template:
....
    spec:
      taints:
      - effect: NoExecute
        key: key1
        value: value1
....
Copy to Clipboard Toggle word wrap

Pod 规格中的容限示例

spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoExecute"
        tolerationSeconds: 3600
....
Copy to Clipboard Toggle word wrap

污点与容限由 key、value 和 effect 组成。

Expand
表 5.1. 污点和容限组件
参数描述

key

key 是任意字符串，最多 253 个字符。key 必须以字母或数字开头，可以包含字母、数字、连字符、句点和下划线。

value

value 是任意字符串，最多 63 个字符。value 必须以字母或数字开头，可以包含字母、数字、连字符、句点和下划线。

effect

effect 的值包括：

Expand

NoSchedule [1]

  • 与污点不匹配的新 pod 不会调度到该节点上。
  • 该节点上现有的 pod 会保留。

PreferNoSchedule

  • 与污点不匹配的新 pod 可以调度到该节点上，但调度程序会尽量不这样调度。
  • 该节点上现有的 pod 会保留。

NoExecute

  • 与污点不匹配的新 pod 无法调度到该节点上。
  • 节点上没有匹配容限的现有 pod 将被移除。

operator

Expand

Equal

key/value/effect 参数必须匹配。这是默认值。

Exists

key/effect 参数必须匹配。您必须保留一个空的 value 参数，这将匹配任何值。

  1. 如果为 control plane 节点（也称为 master 节点）添加了一个 NoSchedule 污点，则节点必须具有 node-role.kubernetes.io/master=:NoSchedule 污点，该污点会被默认添加。

    例如： 

    apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
...
    Copy to Clipboard Toggle word wrap

容限与污点匹配：

  • 如果 operator 参数设为 Equal：

    • key 参数相同；
    • value 参数相同；
    • effect 参数相同。

  • 如果 operator 参数设为 Exists：

    • key 参数相同；
    • effect 参数相同。

OpenShift Container Platform 中内置了以下污点：

  • node.kubernetes.io/not-ready：节点未就绪。这与节点状况 Ready=False 对应。
  • node.kubernetes.io/unreachable：节点无法从节点控制器访问。这与节点状况 Ready=Unknown 对应。
  • node.kubernetes.io/memory-pressure：节点存在内存压力问题。这与节点状况 MemoryPressure=True 对应。
  • node.kubernetes.io/disk-pressure：节点存在磁盘压力问题。这与节点状况 DiskPressure=True 对应。
  • node.kubernetes.io/network-unavailable：节点网络不可用。
  • node.kubernetes.io/unschedulable：节点不可调度。
  • node.cloudprovider.kubernetes.io/uninitialized：当节点控制器通过外部云提供商启动时，在节点上设置这个污点来将其标记为不可用。在云控制器管理器中的某个控制器初始化这个节点后，kubelet 会移除此污点。

  • node.kubernetes.io/pid-pressure ：节点具有 pid 压力。这与节点状况 PIDPressure=True 对应。

    重要

    OpenShift Container Platform 不设置默认的 pid.available evictionHard。

5.7.1.1. 了解如何使用容限秒数来延迟 pod 驱除
复制链接

您可以通过在 Pod 规格或 MachineSet 对象中指定 tolerationSeconds 参数，指定 pod 在被驱除前可以保持与节点绑定的时长。如果将具有 NoExecute effect 的污点添加到节点，则容限污点（包含 tolerationSeconds 参数）的 pod，在此期限内 pod 不会被驱除。

输出示例

spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoExecute"
        tolerationSeconds: 3600
Copy to Clipboard Toggle word wrap

在这里，如果此 pod 正在运行但没有匹配的容限，pod 保持与节点绑定 3600 秒，然后被驱除。如果污点在这个时间之前移除，pod 就不会被驱除。

5.7.1.2. 了解如何使用多个污点
复制链接

您可以在同一个节点中放入多个污点，并在同一 pod 中放入多个容限。OpenShift Container Platform 按照如下所述处理多个污点和容限：

  1. 处理 pod 具有匹配容限的污点。

  2. 其余的不匹配污点在 pod 上有指示的 effect：

    • 如果至少有一个不匹配污点具有 NoSchedule effect，则 OpenShift Container Platform 无法将 pod 调度到该节点上。
    • 如果没有不匹配污点具有 NoSchedule effect，但至少有一个不匹配污点具有 PreferNoSchedule effect，则 OpenShift Container Platform 尝试不将 pod 调度到该节点上。

    • 如果至少有一个未匹配污点具有 NoExecute effect，OpenShift Container Platform 会将 pod 从该节点驱除（如果它已在该节点上运行），或者不将 pod 调度到该节点上（如果还没有在该节点上运行）。

      • 不容许污点的 Pod 会立即被驱除。
      • 如果 Pod 容许污点而没有在 Pod 规格中指定 tolerationSeconds，则会永久保持绑定。
      • 如果 Pod 容许污点，且指定了 tolerationSeconds，则会在指定的时间里保持绑定。

例如：

  • 向节点添加以下污点： 

    $ oc adm taint nodes node1 key1=value1:NoSchedule
    Copy to Clipboard Toggle word wrap 
    $ oc adm taint nodes node1 key1=value1:NoExecute
    Copy to Clipboard Toggle word wrap 
    $ oc adm taint nodes node1 key2=value2:NoSchedule
    Copy to Clipboard Toggle word wrap

  • pod 具有以下容限： 

    spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoExecute"
    Copy to Clipboard Toggle word wrap

在本例中，pod 无法调度到节点上，因为没有与第三个污点匹配的容限。如果在添加污点时 pod 已在节点上运行，pod 会继续运行，因为第三个污点是三个污点中 pod 唯一不容许的污点。

Taint Nodes By Condition （默认启用）可自动污点报告状况的节点，如内存压力和磁盘压力。如果某个节点报告一个状况，则添加一个污点，直到状况被清除为止。这些污点具有 NoSchedule effect；即，pod 无法调度到该节点上，除非 pod 有匹配的容限。

在调度 pod 前，调度程序会检查节点上是否有这些污点。如果污点存在，则将 pod 调度到另一个节点。由于调度程序检查的是污点而非实际的节点状况，因此您可以通过添加适当的 pod 容限，将调度程序配置为忽略其中一些节点状况。

为确保向后兼容，守护进程会自动将下列容限添加到所有守护进程中：

  • node.kubernetes.io/memory-pressure
  • node.kubernetes.io/disk-pressure
  • node.kubernetes.io/unschedulable（1.10 或更高版本）
  • node.kubernetes.io/network-unavailable（仅限主机网络）

您还可以在守护进程集中添加任意容限。

注意

control plane 还会在具有 QoS 类的 pod 中添加 node.kubernetes.io/memory-pressure 容限。这是因为 Kubernetes 在 Guaranteed 或 Burstable QoS 类中管理 pod。新的 BestEffort pod 不会调度到受影响的节点上。

Taint-Based Evictions 功能默认是启用的，可以从遇到特定状况（如 not-ready 和 unreachable）的节点驱除 pod。当节点遇到其中一个状况时，OpenShift Container Platform 会自动给节点添加污点，并开始驱除 pod 以及将 pod 重新调度到其他节点。

Taint Based Evictions 具有 NoExecute 效果，不容许污点的 pod 都被立即驱除，容许污点的 pod 不会被驱除，除非 pod 使用 tolerationSeconds 参数。

tolerationSeconds 参数允许您指定 pod 保持与具有节点状况的节点绑定的时长。如果在 tolerationSections 到期后状况仍然存在，则污点会保持在节点上，并且具有匹配容限的 pod 将被驱除。如果状况在 tolerationSeconds 到期前清除，则不会删除具有匹配容限的 pod。

如果使用没有值的 tolerationSeconds 参数，则 pod 不会因为未就绪和不可访问的节点状况而被驱除。

注意

OpenShift Container Platform 会以限速方式驱除 pod，从而防止在主控机从节点分离等情形中发生大量 pod 驱除。

默认情况下，如果给定区中超过 55% 的节点不健康，节点生命周期控制器会将该区的状态更改为 PartialDisruption，并降低 pod 驱除率。对于此状态下的小型集群（默认为 50 个节点或更小），此区中的节点不会污点，驱除也会停止。

如需更多信息，请参阅 Kubernetes 文档中的降低驱除限制。

OpenShift Container Platform 会自动为 node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable 添加容限并设置 tolerationSeconds=300，除非 Pod 配置中指定了其中任一种容限。 

spec:
....
  template:
....
    spec:
      tolerations:
      - key: node.kubernetes.io/not-ready
        operator: Exists
        effect: NoExecute
        tolerationSeconds: 300
1 

      - key: node.kubernetes.io/unreachable
        operator: Exists
        effect: NoExecute
        tolerationSeconds: 300
Copy to Clipboard Toggle word wrap
1
这些容限确保了在默认情况下，pod 在检测到这些节点条件问题中的任何一个时，会保持绑定 5 分钟。

您可以根据需要配置这些容限。例如，如果您有一个具有许多本地状态的应用程序，您可能希望在发生网络分区时让 pod 与节点保持绑定更久一些，以等待分区恢复并避免 pod 驱除行为的发生。

由守护进程集生成的 pod 在创建时会带有以下污点的 NoExecute 容限，且没有 tolerationSeconds:

  • node.kubernetes.io/unreachable
  • node.kubernetes.io/not-ready

因此，守护进程集 pod 不会被驱除。

5.7.1.5. 容限所有污点
复制链接

您可以通过添加 operator: "Exists" 容限而无需 key 和 value 参数，将节点配置为容许所有污点。具有此容限的 Pod 不会从具有污点的节点中删除。

用于容忍所有污点的Pod 规格

spec:
....
  template:
....
    spec:
      tolerations:
      - operator: "Exists"
Copy to Clipboard Toggle word wrap

5.7.2. 添加污点和容限
复制链接

您可以为 pod 和污点添加容限，以便节点能够控制哪些 pod 应该或不应该调度到节点上。对于现有的 pod 和节点，您应首先将容限添加到 pod，然后将污点添加到节点，以避免在添加容限前从节点上移除 pod。

流程

  1. 通过编辑 Pod spec 使其包含 tolerations 小节来向 pod 添加容限：

    使用 Equal 运算符的 pod 配置文件示例

    spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
    1 
    
        value: "value1"
        operator: "Equal"
        effect: "NoExecute"
        tolerationSeconds: 3600
    2
    Copy to Clipboard Toggle word wrap

    1
    容限参数，如 Taint 和 toleration 组件表中所述。
    2
    tolerationSeconds 参数指定 pod 在被驱除前可以保持与节点绑定的时长。

    例如：

    使用 Exists 运算符的 pod 配置文件示例

    spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
        operator: "Exists"
    1 
    
        effect: "NoExecute"
        tolerationSeconds: 3600
    Copy to Clipboard Toggle word wrap

    1
    Exists 运算符不会接受一个 value。

    本例在 node1 上放置一个键为 key1 且值为 value1 的污点，污点效果是 NoExecute。

  2. 通过以下命令，使用 Taint 和 toleration 组件表中描述的参数为节点添加污点： 

    $ oc adm taint nodes <node_name> <key>=<value>:<effect>
    Copy to Clipboard Toggle word wrap

    例如： 

    $ oc adm taint nodes node1 key1=value1:NoExecute
    Copy to Clipboard Toggle word wrap

    此命令在 node1 上放置一个键为 key1，值为 value1 的污点，其效果是 NoExecute。

    注意

    如果为 control plane 节点（也称为 master 节点）添加了一个 NoSchedule 污点，则节点必须具有 node-role.kubernetes.io/master=:NoSchedule 污点，该污点会被默认添加。

    例如： 

    apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
...
    Copy to Clipboard Toggle word wrap

    pod 上的容限与节点上的污点匹配。具有任一容限的 pod 可以调度到 node1 上。

5.7.3. 使用机器集添加污点和容限
复制链接

您可以使用机器集为节点添加污点。与 MachineSet 对象关联的所有节点都会使用污点更新。容限对由机器集添加的污点的处理方式与直接添加到节点的污点的处理方式相同。

流程

  1. 通过编辑 Pod spec 使其包含 tolerations 小节来向 pod 添加容限：

    使用 Equal 运算符的 pod 配置文件示例

    spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
    1 
    
        value: "value1"
        operator: "Equal"
        effect: "NoExecute"
        tolerationSeconds: 3600
    2
    Copy to Clipboard Toggle word wrap

    1
    容限参数，如 Taint 和 toleration 组件表中所述。
    2
    tolerationSeconds 参数指定 pod 在被驱除前与节点绑定的时长。

    例如：

    使用 Exists 运算符的 pod 配置文件示例

    spec:
  tolerations:
  - key: "key1"
    operator: "Exists"
    effect: "NoExecute"
    tolerationSeconds: 3600
    Copy to Clipboard Toggle word wrap

  2. 将污点添加到 MachineSet 对象：

    1. 为您想要污点的节点编辑 MachineSet YAML，也可以创建新 MachineSet 对象： 

      $ oc edit machineset <machineset>
      Copy to Clipboard Toggle word wrap

    2. 将污点添加到 spec.template.spec 部分：

      机器集规格中的污点示例

      spec:
....
  template:
....
    spec:
      taints:
      - effect: NoExecute
        key: key1
        value: value1
....
      Copy to Clipboard Toggle word wrap

      本例在节点上放置一个键为 key1，值为 value1 的污点，污点效果是 NoExecute。

    3. 将机器缩减为 0: 

      $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      等待机器被删除。

    4. 根据需要扩展机器设置： 

      $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      等待机器启动。污点添加到与 MachineSet 对象关联的节点上。

5.7.4. 使用污点和容限将用户绑定到节点
复制链接

如果要指定一组节点供特定用户独占使用，为 pod 添加容限。然后，在这些节点中添加对应的污点。具有容限的 pod 被允许使用污点节点，或集群中的任何其他节点。

如果您希望确保 pod 只调度到那些污点节点，还要将标签添加到同一组节点，并为 pod 添加节点关联性，以便 pod 只能调度到具有该标签的节点。

流程

配置节点以使用户只能使用该节点：

  1. 为这些节点添加对应的污点：

    例如： 

    $ oc adm taint nodes node1 dedicated=groupName:NoSchedule
    Copy to Clipboard Toggle word wrap
  2. 通过编写自定义准入控制器，为 pod 添加容限。

如果集群中有少量节点具有特殊的硬件，您可以使用污点和容限让不需要特殊硬件的 pod 与这些节点保持距离，从而将这些节点保留给那些确实需要特殊硬件的 pod。您还可以要求需要特殊硬件的 pod 使用特定的节点。

您可以将容限添加到需要特殊硬件并污点具有特殊硬件的节点的 pod 中。

流程

确保为特定 pod 保留具有特殊硬件的节点：

  1. 为需要特殊硬件的 pod 添加容限。

    例如： 

    spec:
  tolerations:
    - key: "disktype"
      value: "ssd"
      operator: "Equal"
      effect: "NoSchedule"
      tolerationSeconds: 3600
    Copy to Clipboard Toggle word wrap

  2. 使用以下命令之一，给拥有特殊硬件的节点添加污点： 

    $ oc adm taint nodes <node-name> disktype=ssd:NoSchedule
    Copy to Clipboard Toggle word wrap

    或者： 

    $ oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule
    Copy to Clipboard Toggle word wrap

5.7.6. 删除污点和容限
复制链接

您可以根据需要，从节点移除污点并从 pod 移除容限。您应首先将容限添加到 pod，然后将污点添加到节点，以避免在添加容限前从节点上移除 pod。

流程

移除污点和容限：

  1. 从节点移除污点： 

    $ oc adm taint nodes <node-name> <key>-
    Copy to Clipboard Toggle word wrap

    例如： 

    $ oc adm taint nodes ip-10-0-132-248.ec2.internal key1-
    Copy to Clipboard Toggle word wrap

    输出示例

    node/ip-10-0-132-248.ec2.internal untainted
    Copy to Clipboard Toggle word wrap

  2. 要从 pod 移除某一容限，请编辑 Pod 规格来移除该容限： 

    spec:
  tolerations:
  - key: "key2"
    operator: "Exists"
    effect: "NoExecute"
    tolerationSeconds: 3600
    Copy to Clipboard Toggle word wrap

5.8. 拓扑管理器
复制链接

理解并使用拓扑管理器。

5.8.1. 拓扑管理器策略
复制链接

拓扑管理器通过从 Hint 提供者（如 CPU Manager 和设备管理器）收集拓扑提示来调整所有级别服务质量（QoS）的 Pod 资源，并使用收集的提示来匹配 Pod 资源。

注意

要将 CPU 资源与 Pod 规格中的其他请求资源匹配，必须使用 static CPU Manager 策略启用 CPU Manager。

拓扑管理器支持四个分配策略，这些策略在 cpumanager-enabled 自定义资源（CR）中定义：

none 策略
这是默认策略，不执行任何拓扑对齐调整。
best-effort 策略
对于带有 best-effort 拓扑管理策略的 pod 中的每个容器，kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这些信息，拓扑管理器会保存那个容器的首选 NUMA 节点关联性设置。如果关联性没有被首选设置，则拓扑管理器会保存这个设置，并把 pod 分配给节点。
restricted 策略
对于带有 restricted 拓扑管理策略的 pod 中的每个容器，kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这些信息，拓扑管理器会保存那个容器的首选 NUMA 节点关联性设置。如果关联性没有被首选，则拓扑管理器会从节点拒绝这个 pod，从而导致 pod 处于 Terminated 状态，且 pod 准入失败。
single-numa-node 策略
对于带有 single-numa-node 拓扑管理策略的 pod 中的每个容器，kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这个信息，拓扑管理器会决定单个 NUMA 节点关联性是否可能。如果是，pod 将会分配给该节点。如果无法使用单一 NUMA 节点关联性，则拓扑管理器会拒绝来自节点的 pod。这会导致 pod 处于 Terminated 状态，且 pod 准入失败。

5.8.2. 设置拓扑管理器
复制链接

要使用拓扑管理器，您必须在 cpumanager-enabled 自定义资源（CR）中配置分配策略。如果您设置了 CPU Manager，则该文件可能会存在。如果这个文件不存在，您可以创建该文件。

先决条件

  • 将 CPU Manager 策略配置为 static。请参考扩展和性能文档中的使用 CPU Manager 部分 。

流程

激活 Topolgy Manager:

  1. 在 cpumanager-enabled 自定义资源（CR）中配置拓扑管理器分配策略。 

    $ oc edit KubeletConfig cpumanager-enabled
    Copy to Clipboard Toggle word wrap