安装

OpenShift Container Platform 4.3

安装并配置 OpenShift Container Platform 集群

Red Hat OpenShift Documentation Team

摘要

本文档提供有关安装和配置 OpenShift Container Platform 的信息。

第 1 章 收集安装日志

为帮助排查 OpenShift Container Platform 安装失败的问题,您可以从 bootstrap 和 control plane 或 master 机器中收集日志。

先决条件

  • 已尝试安装 OpenShift Container Platform 集群,但安装失败。
  • 您为安装程序提供了 SSH 密钥,且该密钥已加入到正在运行的 ss-agent 进程中。

1.1. 从失败安装中收集日志

如果为安装程序提供了 SSH 密钥,则可以收集与失败安装相关的数据。

注意

用于收集失败安装日志的命令与从正在运行的集群收集日志时所用的命令不同。如果需要从正在运行的集群收集日志,请使用 oc adm must-gather 命令。

先决条件

  • OpenShift Container Platform 安装在 bootstrap 过程完成前失败。bootstrap 节点必须正在运行,并可通过 SSH 访问。
  • ssh-agent 进程在您的计算机上处于活跃状态,并且为 ssh-agent 进程和安装程序提供了相同的 SSH 密钥。
  • 如果尝试在您置备的基础架构中安装集群,则一定需要有 control plane 或 master 机器的完全限定域名。

流程

  1. 生成从 bootstrap 和 control plane 机器获取安装日志的命令:

    • 如果使用了安装程序置备的基础架构,请运行以下命令:

      $ ./openshift-install gather bootstrap --dir=<directory> 1
      1
      installation_directory 是安装程序所创建的用来保存 OpenShift Container Platform 定义文件的目录。

      对于安装程序置备的基础架构,安装程序会保存有关集群的信息,因此您不用指定主机名或 IP 地址。

    • 如果使用了您置备的基础架构,请运行以下命令:

      $ ./openshift-install gather bootstrap --dir=<directory> \ 1
          --bootstrap <bootstrap_address> \ 2
          --master <master_1_address> \ 3
          --master <master_2_address> \ 4
          --master <master_3_address>" 5
      1
      installation_directory 是安装程序所创建的用来保存 OpenShift Container Platform 定义文件的目录。
      2
      <bootstrap_address> 是集群 bootstrap 机器的完全限定域名或 IP 地址。
      3 4 5
      <master_address> 是集群中 control plane 或 master 机器的完全限定域名或 IP 地址。
      注意

      默认集群包含三个 control plane 机器。如所示,列出所有 control plane 机器,无论集群使用了多少个。

    命令输出类似以下示例:

    INFO Pulling debug logs from the bootstrap machine
    INFO Bootstrap gather logs captured here "<directory>/log-bundle-<timestamp>.tar.gz"

    如果需要创建关安装失败的红帽支持问题单,请在问题单中附上压缩日志。

1.2. 通过到主机的 SSH 连接手动收集日志

must-gather 或自动收集方法无法正常工作的情况下手动收集日志。

先决条件

  • 必须有到主机的 SSH 访问权限。

流程

  1. 运行以下命令,使用 journalctl 命令从 bootstrap 主机收集 bootkube.service 服务日志:

    $ journalctl -b -f -u bootkube.service
  2. 使用 Podman 的 logs 命令收集 bootstrap 主机的容器日志。以下命令从主机获取所有容器的日志:

    $ for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done
  3. 或者,通过运行以下命令来使用 tail 命令收集主机的容器日志:

    # tail -f /var/lib/containers/storage/overlay-containers/*/userdata/ctr.log
  4. 运行 journalctl 命令从 master 和 worker 主机收集 kubelet.servicecrio.service 服务日志:

    $ journalctl -b -f -u kubelet.service -u crio.service
  5. 使用 tail 命令收集 master 和 worker 主机容器日志:

    $ sudo tail -f /var/log/containers/*

1.3. 在不使用 SSH 连接到主机的情况下手动收集日志

must-gather 或自动收集方法无法正常工作的情况下手动收集日志。

如果您无法对节点进行 SSH 访问,则可以通过访问系统日志来调查主机上发生的情况。

先决条件

  • OpenShift Container Platform 安装已完成。
  • API 服务仍然可以正常工作。
  • 有系统管理员特权。

流程

  1. 通过运行以下命令访问 /var/log 中的 journald 单元日志:

    $ oc adm node-logs --role=master -u kubelet
  2. 通过运行以下命令访问 /var/log 中的主机文件路径:

    $ oc adm node-logs --role=master --path=openshift-apiserver

第 2 章 支持 FIPS 加密

从版本 4.3 开始,您可以安装一个使用经 FIPS 验证的/IUT (Implementation Under Test) 加密库的 OpenShift Container Platform 集群。

对于集群中的 Red Hat Enterprise Linux CoreOS (RHCOS) 机器,当机器根据 install-config.yaml 文件中的选项的状态进行部署时,会应用这个更改,该文件管理用户可在集群部署过程中更改的集群选项。在 Red Hat Enterprise Linux 机器中,您必须在计划用作 worker 的机器上安装操作系统时,启用 FIPS 模式。这些配置方法可确保集群满足 FIPS 合规审核的要求:在初始系统引导前,只启用经 FIPS 验证的/IUT (Implementation Under Test) 加密软件包。

因为 FIPS 必须在集群首次引导操作系统之前启用,所以您不能在部署集群后启用 FIPS。

2.1. OpenShift Container Platform 中的 FIPS 验证

OpenShift Container Platform 在 Red Hat Enterprise Linux (RHEL) 和 Red Hat CoreOS (RHCOS) 中使用特定的 FIPS 验证的/IUT (Implementation Under Test) 模块用于使用它们的操作系统组件。请参阅 RHEL7 core crypto components 中的内容。例如,当用户 SSH 到 OpenShift Container Platform 集群和容器时,这些连接会被正确加密。

OpenShift Container Platform 组件以 Go 编写,并使用红帽的 golang 编译器构建。当您为集群启用 FIPS 模式时,红帽的 golang 编译器会为所有需要加密签名的 OpenShift Container Platform 组件调用 RHEL 和 RHCOS 加密程序库。在 OpenShift Container Platform 版本 4.3 的初始发行版本中,只有 ose-sdn 软件包会使用原生 golang 加密法,它不是经过 FIPS 验证的/IUT (Implementation Under Test) 。红帽会验证所有其它软件包是否使用经 FIPS 验证的/IUT (Implementation Under Test) OpenSSL 模块。

表 2.1. OpenShift Container Platform 4.3 中的 FIPS 模式属性和限制

属性限制:

RHEL 7 操作系统支持 FIPS 。

FIPS 实现还没有提供一个单一的计算哈希函数和验证基于该哈希的键的函数。在以后的 OpenShift Container Platform 版本中,将继续评估并改进这个限制。

CRI-O 运行时支持 FIPS。

OpenShift Container Platform 服务支持 FIPS。

从 RHEL 7 和 RHCOS 二进制文件和镜像中获得的 FIPS 验证的/IUT (Implementation Under Test) 加密模块和算法。

 

使用 FIPS 兼容 golang 编译器。

对 TLS FIPS 的支持当前还不完整,但计划在将来的 OpenShift Container Platform 版本中被完全支持。

2.2. 集群使用的组件支持 FIPS

尽管 OpenShift Container Platform 集群本身使用 FIPS 验证的/IUT(Implementation Under Test)模块,但请确保支持 OpenShift Container Platform 集群的系统也使用 FIPS 验证的/IUT(Implementation Under Test)模块进行加密。

2.2.1. etcd

要确保存储在 etcd 中的 secret 使用 FIPS 验证的/IUT(Implementation Under Test)加密,使用 FIPS 批准的加密算法加密 etcd 数据存储。安装集群后,可以使用 aes cbc 算法加密 etcd 数据

2.2.2. 存储

对于本地存储,使用 RHEL 提供的磁盘加密或者使用 RHEL 提供的磁盘加密的容器原生存储。通过将所有数据存储到使用 RHEL 提供的磁盘加密的卷中,并为您的集群启用 FIPS 模式,静态数据和正在启动的数据或网络数据都受到 FIPS 验证的/IUT(Implementation Under Test)加密的保护。您可以将集群配置为加密每个节点的根文件系统,如自定义节点 中所述。

2.2.3. 运行时

要确保容器知道它们在使用 FIPS 验证的/IUT(Implementation Under Test)加密模块的主机上运行,请使用 CRI-O 管理您的运行时。CRI-O 支持 FIPS-Mode,它将容器配置为知道它们是在 FIPS 模式下运行的。

2.3. 在 FIPS 模式下安装集群

要使用 FIPS 模式安装集群,请按照在相应的基础架构中安装自定义集群的步骤进行。在部署集群前,请确定在 install-config.yaml 文件中设置了 fips: true

要将 AES CBC 加密应用到 etcd 数据存储中,请在安装集群后执行加密 etcd 数据操作。

如果您在集群中添加 RHEL 节点,请确定在机器初始引导前启用 FIPS 模式。请参阅 RHEL 7 文档中的 Adding RHEL compute machines to a OpenShift Container Platform clusterEnabling FIPS Mode 部分。

第 3 章 安装配置

3.1. 不同平台的安装方法

您可以在不同的平台上执行不同类型的安装。

注意

不是所有安装选项都可用于所有平台,如下表所示。

表 3.1. 安装程序置备的基础架构选项

 AWSAzureGCPOpenStack裸机vSphereIBM Z

Default

X

X

X

    

Custom

X

X

X

X

   

Cluster Network Operator

X

X

X

    

私有集群

X

X

X

    

现有的虚拟私有网络

X

X

X

    

表 3.2. 用户置备的基础架构

 AWSAzureGCPOpenStack裸机vSphereIBM Z

Custom

X

X

X

 

X

X

 

Cluster Network Operator

    

X

X

 

Restricted network

X

 

X

 

X

X

 

3.2. 自定义节点

虽然不鼓励直接更改 OpenShift Container Platform 节点,但有时在实现低级别安全、网络或性能功能时需要这样做。通过以下方法可以对 OpenShift Container Platform 节点直接进行更改:

  • 创建包含在清单文件中的 MachineConfig,以便在 openshift-install 期间启动集群。
  • 创建通过 Machine Config Operator 传递至运行的 OpenShift Container Platform 节点的 MachineConfig。

以下小节描述了您可能需要以这种方式在节点中配置的功能。

3.2.1. 添加 day-1 内核参数

虽然修改内核参数通常应做为第 2 天的任务,但您可能希望在初始集群安装过程中将内核参数添加到所有 master 节点或 worker 节点中。下面是一些您可能需要在集群安装过程中添加内核参数以在系统第一次引导前生效的原因:

  • 禁用某个功能(比如 SELinux),以使这个功能不会对系统产生任何影响。
  • 您需要在系统启动前进行一些低级网络配置。

要向 master 节点或 worker 节点添加内核参数,您可以创建一个 MachineConfig 对象,并将该对象注入 Ignition 在集群设置过程中使用的清单文件集合中。

如需列出引导时可以传递给 RHEL 8 内核的参数,请参阅 Kernel.org 内核参数。如果需要这些参数来完成初始的 OpenShift Container Platform 安装,最好使用这个流程添加内核参数。

流程

  1. 为集群生成 Kubernetes 清单:

    $ ./openshift-install create manifests --dir=<installation_directory>
  2. 决定您要向 worker 节点或 master 节点添加的内核参数。
  3. openshift 目录中,创建一个文件(例如: 99_openshift-machineconfig_master-kargs.yaml)来定义 MachineConfig 对象以添加内核设置。这个示例为 master 节点添加了一个 loglevel=7 的内核参数:

    $ cat << EOF > 99_openshift-machineconfig_master-kargs.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 99_openshift-machineconfig_master-kargs
    spec:
      kernelArguments:
        - 'loglevel=7'
    EOF

    您可以将 master 改为 worker ,以将内核参数添加到 worker 节点。创建一个单独的 YAML 文件,以添加到 master 节点和 worker 节点中。

现在您可以继续创建集群。

3.2.2. 在节点中添加内核模块

对于大多数常用硬件,在计算机启动时,Linux 内核会包括使用这些硬件所需的设备驱动程序模块。但是对于一些硬件来说,在 Linux 中不提供它们的模块。因此,您必须找到一种方法来为每个主机计算机提供这些模块。此流程介绍了如何为 OpenShift Container Platform 集群中的节点进行此操作。

当首先按照这些说明部署了一个内核模块后,这个模块就可用于当前内核。如果安装了新内核,kmods-via-containers 软件将被重建并部署该模块,以便使新内核可使用该模块的兼容版本。

使这个功能可以在每个节点中保持模块最新状态的方法是:

  • 在引导时启动的每个节点中添加 systemd 服务,以检测是否安装了新内核。
  • 如果检测到一个新的内核,该服务会重建该模块并将其安装到内核中

有关此过程所需软件的详情,请查看 kmods-via-containers github 站点。

需要记住的几个重要问题:

  • 这个过程是技术预览。
  • 软件工具和示例还没有官方的 RPM,现只能从非官方的 github.com 站点获得。
  • 红帽不支持您通过这些步骤添加的第三方内核模块。
  • 在本流程中,构建您的内核模块所需的软件部署在 RHEL 8 容器中。请记住,当节点有新内核时,每个节点上会自动重新构建模块。因此,每个节点都需要访问一个 yum 存储库,该程序存储库包含重建该模块所需的内核和相关软件包。该内容最好由一个有效的 RHEL 订阅提供。

3.2.2.1. 构建并测试内核模块容器

在将内核模块部署到 OpenShift Container Platform 集群之前,您可以在单独的 RHEL 系统中测试此过程。收集内核模块的源代码、KVC 框架和 kmod-via-containers 软件。然后构建并测试模块。要在 RHEL 8 系统中做到这一点,请执行以下操作:

流程

  1. 获取 RHEL 8 系统,然后注册并订阅它:

    # subscription-manager register
    Username: yourname
    Password: ***************
    # subscription-manager attach --auto
  2. 安装构建软件和容器所需的软件:

    # yum install podman make git -y
  3. 克隆 kmod-via-containers 存储库:

    $ mkdir kmods; cd kmods
    $ git clone https://github.com/kmods-via-containers/kmods-via-containers
  4. 在 RHEL 8 构建主机上安装 KVC 框架实例来测试模块。这会添加 kmods-via-container systemd 服务并加载它:

    $ cd kmods-via-containers/
    $ sudo make install
    $ sudo systemctl daemon-reload
  5. 获取内核模块源代码。通过源代码,可以构建一个您无法控制但由其他人提供的第三方模块。您需要类似 kvc -simple-kmod 示例中显示的内容 ,使用以下步骤将这些内容克隆到您的系统中:

    $ cd ..
    $ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
  6. 编辑示例中的配置文件 simple-kmod.conf,将 Dockerfile 的名称改为 Dockerfile.rhel ,该文件如下所示:

    $ cd kvc-simple-kmod
    $ cat simple-kmod.conf
    
    KMOD_CONTAINER_BUILD_CONTEXT="https://github.com/kmods-via-containers/kvc-simple-kmod.git"
    KMOD_CONTAINER_BUILD_FILE=Dockerfile.rhel
    KMOD_SOFTWARE_VERSION=dd1a7d4
    KMOD_NAMES="simple-kmod simple-procfs-kmod"
  7. 为您的内核模块创建一个 kmods-via-containers@.service 实例(在这个示例中是 simple-kmod )并启用它:

    $ sudo make install
    $ sudo kmods-via-containers build simple-kmod $(uname -r)
  8. 启用并启动 systemd 服务,然后检查状态:

    $ sudo systemctl enable kmods-via-containers@simple-kmod.service
    $ sudo systemctl start kmods-via-containers@simple-kmod.service
    $ sudo systemctl status kmods-via-containers@simple-kmod.service
    ● kmods-via-containers@simple-kmod.service - Kmods Via Containers - simple-kmod
       Loaded: loaded (/etc/systemd/system/kmods-via-containers@.service;
              enabled; vendor preset: disabled)
       Active: active (exited) since Sun 2020-01-12 23:49:49 EST; 5s ago...
  9. 要确认载入了内核模块,请使用 lsmod 命令列出模块:

    $ lsmod | grep simple_
    simple_procfs_kmod     16384  0
    simple_kmod            16384  0
  10. simple-kmod 示例还有几个其它方法来测试它是否可以正常工作。使用 dmesg 在内核环缓冲中查找 "Hello world" 信息:

    $ dmesg | grep 'Hello world'
    [ 6420.761332] Hello world from simple_kmod.

    /proc 中检查 simple-procfs-kmod 的值:

    $ sudo cat /proc/simple-procfs-kmod
    simple-procfs-kmod number = 0

    运行 spkut 命令从模块中获取更多信息:

    $ sudo spkut 44
    KVC: wrapper simple-kmod for 4.18.0-147.3.1.el8_1.x86_64
    Running userspace wrapper using the kernel module container...
    + podman run -i --rm --privileged
       simple-kmod-dd1a7d4:4.18.0-147.3.1.el8_1.x86_64 spkut 44
    simple-procfs-kmod number = 0
    simple-procfs-kmod number = 44

下一步,当系统引导这个服务时,会检查新内核是否在运行。如果有一个新内核,该服务会构建内核模块的新版本,然后载入它。如果已经构建了该模块,它将只载入该模块。

3.2.2.2. 为 OpenShift Container Platform 置备内核模块

根据 OpenShift Container Platform 集群首次引导时是否必须存在内核模块,您可以通过以下两种方式之一设置内核模块部署:

  • 在集群安装时(day-1)置备内核模块:您可以通过一个 MachineConfig 创建内容,并通过包括一组清单文件来将其提供给 openshift-install
  • 通过 Machine Config Operator 置备内核模块(day-2):如果可以等到集群启动并运行后再添加内核模块,则可以通过 Machine Config Operator (MCO) 部署内核模块软件。

在这两种情况下,每个节点都需要在检测到新内核时可以获得内核软件包及相关软件包。您可以通过以下几种方法设置每个节点来获取该内容。

  • 为每个节点提供 RHEL 权利。
  • 从现有的 RHEL 主机获取 RHEL 权利。把 /etc/pki/entitlement 目录中的 RHEL 授权复制到与您在构建 Ignition 配置时提供的其他文件相同的位置。
  • 在 Dockerfile 中,添加包括了内核和其他软件包的 yum 存储库。这必须包括新内核软件包,因为它们需要与新安装的内核相匹配。
3.2.2.2.1. 通过 MachineConfig 置备内核模块

通过将内核模块软件与 MachineConfig 一起打包,您可以在安装时或通过 Machine Config Operator 向 worker 或 master 节点发送该软件。

首先创建您要使用的基本 Ignition 配置。在安装时,Ignition 配置需要包含添加到集群中的 core 用户的 authorized_keys 文件中的 ssh 公钥 。如果在以后通过 MCO 添加 MachineConfig,则不需要 ssh 公钥。对于这两种方式,simple-kmod 服务示例都会创建一个 systemd 单元文件,它需要一个 kmods-via-containers@simple-kmod.service

注意

systemd 单元是 上游程序错误的一个临时解决方案。确保 kmods-via-containers@simple-kmod.service 在引导时启动:

  1. 获取 RHEL 8 系统,然后注册并订阅它:

    # subscription-manager register
    Username: yourname
    Password: ***************
    # subscription-manager attach --auto
  2. 安装构建软件所需的软件:

    # yum install podman make git -y
  3. 创建 Ignition 配置文件以创建 systemd 单元文件:

    $ mkdir kmods; cd kmods
    $ cat <<EOF > ./baseconfig.ign
    {
      "ignition": { "version": "2.2.0" },
      "passwd": {
        "users": [
          {
            "name": "core",
            "groups": ["sudo"],
            "sshAuthorizedKeys": [
              "ssh-rsa AAAA"
            ]
          }
        ]
      },
      "systemd": {
        "units": [{
          "name": "require-kvc-simple-kmod.service",
          "enabled": true,
          "contents": "[Unit]\nRequires=kmods-via-containers@simple-kmod.service\n[Service]\nType=oneshot\nExecStart=/usr/bin/true\n\n[Install]\nWantedBy=multi-user.target"
        }]
      }
    }
    EOF
    注意

    您必须将公共 SSH 密钥添加到 baseconfig.ign 文件中 ,以便 openshift-install 使用该文件。如果通过 MCO 创建 MachineConfig,则不需要使用公共 SSH 密钥。

  4. 创建如下所示的基础 MCO YAML 片断:
$ cat <<EOF > mc-base.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 10-kvc-simple-kmod
spec:
  config:
EOF

+

注意

Mc-base.yaml 设置为在 worker 节点上部署内核模块 。要部署到 master 节点上,请将角色从 worker 更改为 master。要进行这两个操作,您可以通过为不同类型的部署使用不同的文件名来重复整个过程。

  1. 获得 kmods-via-containers 软件:

    $ git clone https://github.com/kmods-via-containers/kmods-via-containers
    $ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
  2. 获取您的模块软件。在这个示例中使用 kvc-simple-kmod
  3. 使用之前克隆的存储库,创建一个 fakeroot 目录,并将您要通过 Ignition 传递的文件放置到这个目录:

    $ FAKEROOT=$(mktemp -d)
    $ cd kmods-via-containers
    $ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
    $ cd ../kvc-simple-kmod
    $ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
  4. 获取名为 filetranspiler 的工具程序及相关的依赖软件:

    $ cd ..
    $ sudo yum install -y python3
    git clone https://github.com/ashcrow/filetranspiler.git
  5. 生成最终的 MachineConfig YAML(mc.yaml),它包含基础 Ignition 配置、基础 MachineConfig,以及包括您要提供的文件的 fakeroot 目录:

    $ ./filetranspiler/filetranspile -i ./baseconfig.ign \
         -f ${FAKEROOT} --format=yaml --dereference-symlinks \
         | sed 's/^/     /' | (cat mc-base.yaml -) > 99_simple-kmod.yaml
  6. 如果集群还没有启用,生成清单文件并将该文件添加到 openshift 目录中。如果集群已在运行,按照以下方法应用该文件:

    $ oc create -f 99_simple-kmod.yaml

    您的节点将启动 kmods-via-containers@simple-kmod.service 服务,并将载入内核模块。

  7. 为了确认内核模块已加载,您可以登录到节点(使用 oc debug node/<openshift-node>,然后运行 chroot /host)。要列出模块,请使用 lsmod 命令:

    $ lsmod | grep simple_
    simple_procfs_kmod     16384  0
    simple_kmod            16384  0

3.2.3. 在安装过程中加密磁盘

在 OpenShift Container Platform 安装过程中,您可以在所有 master 和 worker 节点上启用磁盘加密。这个功能:

  • 可用于安装程序置备的基础架构和用户置备的基础架构部署
  • 只在 Red Hat Enterprise Linux CoreOS (RHCOS) 系统上被支持
  • 在清单安装阶段设置磁盘加密,以便加密所有写入磁盘的数据(从第一次引导开始)
  • 只加密 root 文件系统中的数据(/dev/mapper/coreos-luks-root on /
  • 不需要用户干预就可以提供密码短语
  • 使用 AES-256-CBC 加密
  • 应该为集群启用来支持 FIPS。

支持的加密模式有两种:

  • TPM v2:这是首选模式。TPM v2 在安全加密处理器中存储密码短语。要实现 TPM v2 磁盘加密,请创建 Ignition 配置文件,如下所述。
  • Tang:要使用 Tang 来加密集群,您需要使用一个 Tang 服务器。Clevis 在客户端实现解密。只有在裸机上的安装支持 Tang 加密模式。

按照以下两个流程之一为集群中的节点启用磁盘加密。

3.2.3.1. 启用 TPM v2 磁盘加密

使用这个流程在 OpenShift Container Platform 部署过程中启用 TPM v2 模式磁盘加密。

流程

  1. 检查每个节点的 BIOS 是否需要启用 TPM v2 加密。这在大多数 Dell 系统中是必需的。请参阅您的计算机的相关手册。
  2. 为集群生成 Kubernetes 清单:

    $ ./openshift-install create manifests --dir=<installation_directory>
  3. openshift 目录中,创建一个 master 和/或 worker 文件来为这些节点加密磁盘。以下是这两个文件的例子:

    $ cat << EOF > ./99_openshift-worker-tpmv2-encryption.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: worker-tpm
      labels:
        machineconfiguration.openshift.io/role: worker
    spec:
      config:
        ignition:
          version: 2.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;base64,e30K
            filesystem: root
            mode: 420
            path: /etc/clevis.json
    EOF
    $ cat << EOF > ./99_openshift-master-tpmv2-encryption.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: master-tpm
      labels:
        machineconfiguration.openshift.io/role: master
    spec:
      config:
        ignition:
          version: 2.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;base64,e30K
            filesystem: root
            mode: 420
            path: /etc/clevis.json
    EOF
  4. 生成 YAML 文件的备份副本。在创建集群时会删除该文件,所以您应该进行备份。
  5. 继续进行 OpenShift Container Platform 部署的剩余部分。

3.2.3.2. 启用 Tang 磁盘加密

使用这个流程在 OpenShift Container Platform 部署过程中启用 Tang 模式磁盘加密。

流程

  1. 使用一个 Red Hat Enterprise Linux 服务器配置加密设置,并运行 openshift-install 来安装一个集群及 oc
  2. 设置或访问现有的 Tang 服务器。具体步骤请查看网络绑定磁盘加密 。另请参阅 Securing Automated Decryption New Cryptography and Techni
  3. 在为集群安装 RHCOS 时,添加用于配置网络的参数。如果错过了这一步,第二个引导将失败。例如:在向内核命令行中添加参数时,如果要配置 DHCP 网络,指定 ip=dhcp, 或者设置静态网络。
  4. 生成 thumbprint。安装 clevis 软件包(如果还没有安装),并从 Tang 服务器生成一个 thumbprint。使用 Tang 服务器 URL 替换 url 的值:

    $ sudo yum install clevis -y
    $ echo nifty random wordwords \
         | clevis-encrypt-tang \
           '{"url":"https://tang.example.org"}'
    
    The advertisement contains the following signing keys:
    
    PLjNyRdGw03zlRoGjQYMahSZGu9
    
    Do you wish to trust these keys? [ynYN] y
    eyJhbmc3SlRyMXpPenc3ajhEQ01tZVJiTi1oM...
  5. 创建 Base64 编码文件,使用新生成的 Tang server 替换 url,thumbprint 替换thp

    $ (cat <<EOM
    {
     "url": "https://tang.example.com",
     "thp": "PLjNyRdGw03zlRoGjQYMahSZGu9"
    }
    EOM
    ) | base64 -w0
    
    ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K
  6. 将 TPM2 示例中的 “source” 替换为 worker 和/或 master 节点的其中一个或两个示例的 Base64 编码文件:

    $ cat << EOF > ./99_openshift-worker-tang-encryption.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: worker-tang
      labels:
        machineconfiguration.openshift.io/role: worker
    spec:
      config:
        ignition:
          version: 2.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;base64,e30K
              source: data:text/plain;base64,ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K
            filesystem: root
            mode: 420
            path: /etc/clevis.json
    EOF
    $ cat << EOF > ./99_openshift-master-encryption.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: master-tang
      labels:
        machineconfiguration.openshift.io/role: master
    spec:
      config:
        ignition:
          version: 2.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;base64,e30K
              source: data:text/plain;base64,ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K
            filesystem: root
            mode: 420
            path: /etc/clevis.json
    EOF
  7. 继续进行 OpenShift Container Platform 部署的剩余部分。

3.2.4. 配置 chrony 时间服务

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

流程

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

    $ cat << EOF | base64
        server clock.redhat.com iburst
        driftfile /var/lib/chrony/drift
        makestep 1.0 3
        rtcsync
        logdir /var/log/chrony
        EOF
    
    ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGli
    L2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAv
    dmFyL2xvZy9jaHJvbnkK
  2. 创建 MachineConfig 文件,将 base64 字符串替换为您刚刚创建的字符串。本例将文件添加到 master 节点。您可以将其更改为 worker ,或为 worker 角色创建额外的 MachineConfig:

    $ cat << EOF > ./99_masters-chrony-configuration.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: masters-chrony-configuration
    spec:
      config:
        ignition:
          config: {}
          security:
            tls: {}
          timeouts: {}
          version: 2.2.0
        networkd: {}
        passwd: {}
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,c2VydmVyIGNsb2NrLnJlZGhhdC5jb20gaWJ1cnN0CmRyaWZ0ZmlsZSAvdmFyL2xpYi9jaHJvbnkvZHJpZnQKbWFrZXN0ZXAgMS4wIDMKcnRjc3luYwpsb2dkaXIgL3Zhci9sb2cvY2hyb255Cg==
              verification: {}
            filesystem: root
            mode: 420
            path: /etc/chrony.conf
      osImageURL: ""
    EOF
  3. 对配置文件做一个副本备份。
  4. 如果集群还没有启动,生成清单文件,将此文件添加到 openshift 目录中,然后继续创建集群。
  5. 如果集群已在运行,按照以下方法应用该文件:

     $ oc apply -f ./masters-chrony-configuration.yaml

3.2.5. 其他资源

如需更多与 FIPS 相关的信息,请参阅 Support for FIPS cryptography

3.3. 创建用于在受限网络中安装的镜像 registry

在受限网络中置备的基础架构上安装集群前,您必须创建镜像 registry。在受限网络中安装仅支持您置备的基础架构,不支持安装程序置备的基础架构。

重要

您必须有权访问互联网,才能获取填充镜像存储库的数据。在这一流程中,您要将镜像 registry 放在可访问您的网络以及互联网的堡垒(bastion)主机上。如果您没有堡垒主机的访问权限,请使用最适合您的限制条件的方法将镜像 registry 的内容提取到受限网络中。

3.3.1. 关于镜像 registry

您可以镜像 OpenShift Container Platform registry 的内容,也可以镜像生成安装程序所需的镜像。

镜像 registry 是一个关键组件,有了它才能在受限网络中完成安装。您可以在堡垒主机上创建此镜像,该主机可同时访问互联网和您的封闭网络,也可以使用满足您的限制条件的其他方法。

由于 OpenShift Container Platform 验证发行版本有效负载完整性的方式,您的本地 registry 中的镜像引用与红帽在 Quay.io 上托管的镜像相同。在安装的 bootstrap 过程中,不论镜像是从哪个存储库提取的,镜像都必须有相同的摘要。要确保发行版有效负载一致,请将镜像镜像到您的本地存储库。

3.3.2. 准备堡垒主机

在创建镜像 registry 前,您必须准备堡垒主机。

3.3.2.1. 通过下载二进制文件安装 CLI

为了可以使用命令行界面与 OpenShift Container Platform 进行交互,您需要安装 CLI。

重要

如果安装了旧版本的 oc,则无法使用 OpenShift Container Platform 4.3 中的所有命令。下载并安装新版本的 oc

流程

  1. 在 Red Hat OpenShift Cluster Manager 站点的 Infrastructure Provider 页面中导航至您的安装类型页面,并点击 Download Command-line Tools
  2. 点您的操作系统和系统架构的文件夹,然后点压缩文件。

    注意

    您可在 Linux 、Windows 或 macOS 上安装 oc

  3. 将文件保存到文件系统。
  4. 展开压缩文件。
  5. 把它放到 PATH 中的一个目录下。

安装 CLI 后,就可以使用oc命令:

$ oc <command>

3.3.3. 创建镜像 registry

创建 registry 来托管安装 OpenShift Container Platform 所需的镜像内容。要在受限网络中安装,您必须将镜像放在您的堡垒主机上。

注意

以下流程创建一个简单的 registry,它可在 /opt/registry 文件夹中保存数据并在 podman 容器中运行。您可以使用不同的 registry 解决方案,例如 Red Hat Quay。检查以下流程以确保 registry 可以正常工作。

先决条件

  • 网络上有一个 Red Hat Enterprise Linux (RHEL) 服务器充当 registry 主机。
  • registry 主机可以访问互联网。

流程

在堡垒主机上,执行以下操作:

  1. 安装所需的软件包:

    # yum -y install podman httpd-tools

    podman 软件包提供容器软件包,用于运行 registry。httpd-tools 软件包提供 htpasswd 实用程序,用于创建用户。

  2. 为 registry 创建文件夹:

    # mkdir -p /opt/registry/{auth,certs,data}

    这些文件夹挂载到 registry 容器中。

  3. 为 registry 提供证书。如果您没有现有的可信证书颁发机构,您可以生成自签名证书:

    $ cd /opt/registry/certs
    # openssl req -newkey rsa:4096 -nodes -sha256 -keyout domain.key -x509 -days 365 -out domain.crt

    在提示符处,为证书提供所需的值:

    国家/地区名称(双字母代码)

    指定您所在位置的双字母 ISO 国家/地区代码。请参见 ISO 3166 国家/地区代码标准。

    州或省名称(完整名称)

    输入您的州或省的完整名称。

    本地名称(例如,城市)

    输入您的城市名称。

    机构名称(例如,公司)

    输入公司的名称。

    组织单元名称(例如,部门)

    输入您的部门名称。

    通用名称(例如,您的名字或服务器主机名)

    输入 registry 主机的主机名。确保您的主机名在 DNS 中,并且解析为预期的 IP 地址。

    电子邮件地址

    输入您的电子邮件地址。如需了解更多信息,请参阅 OpenSSL 文档中的 req 说明。

  4. 为 registry 生成使用 bcrpt 格式的用户名和密码:

    # htpasswd -bBc /opt/registry/auth/htpasswd <user_name> <password> 1
    1
    <user_name><password> 替换为用户名和密码。
  5. 创建 mirror-registry 容器以托管 registry:

    # podman run --name mirror-registry -p <local_registry_host_port>:5000 \ 1
         -v /opt/registry/data:/var/lib/registry:z \
         -v /opt/registry/auth:/auth:z \
         -e "REGISTRY_AUTH=htpasswd" \
         -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
         -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
         -v /opt/registry/certs:/certs:z \
         -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
         -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
         -e REGISTRY_COMPATIBILITY_SCHEMA1_ENABLED=true \
         -d docker.io/library/registry:2
    1
    对于 <local_registry_host_port>,请指定您的镜像 registry 用于提供内容的端口。
  6. 为 registry 打开所需的端口:

    # firewall-cmd --add-port=<local_registry_host_port>/tcp --zone=internal --permanent 1
    # firewall-cmd --add-port=<local_registry_host_port>/tcp --zone=public   --permanent 2
    # firewall-cmd --reload
    1 2
    对于 <local_registry_host_port>,请指定您的镜像 registry 用于提供内容的端口。
  7. 将自签名证书添加到您的可信证书列表中:

    # cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
    # update-ca-trust

    您必须信任您的证书,才能在镜像过程中登录到 registry。

  8. 确认 registry 可用:

    $ curl -u <user_name>:<password> -k https://<local_registry_host_name>:<local_registry_host_port>/v2/_catalog 1
    
    {"repositories":[]}
    1
    对于 <user_name><password>,指定 registry 的用户名和密码。对于 <local_registry_host_name>,请指定在您的证书中指定的 registry 域名,如 registry.example.com。对于 <local_registry_host_port>,请指定您的镜像 registry 用于提供内容的端口。

    如果命令输出显示一个空存储库,则您的 registry 已经可用。

3.3.4. 在 pull secret 中添加 registry

在受限网络中安装 OpenShift Container Platform 集群前,需要为 OpenShift Container Platform 集群修改 pull secret 来使用本地 registry。

先决条件

  • 配置了一个镜像(mirror) registry 在受限网络中使用。

流程

在堡垒主机上完成以下步骤:

  1. 从 Red Hat OpenShift Cluster Manager 站点的 Pull Secret 页面下载 registry.redhat.io 的 pull secret。
  2. 为您的镜像 registry 生成 base64 编码的用户名和密码或令牌:

    $ echo -n '<user_name>:<password>' | base64 -w0 1
    
    BGVtbYk3ZHAtqXs=
    1
    通过 <user_name><password> 指定 registry 的用户名和密码。
  3. 以 JSON 格式创建您的 pull secret 副本:

    $ cat ./pull-secret.text | jq .  > <path>/<pull-secret-file>1
    1
    指定到存储 pull secret 的文件夹的路径,以及您创建的 JSON 文件的名称。

    该文件类似于以下示例:

    {
      "auths": {
        "cloud.openshift.com": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "quay.io": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "registry.connect.redhat.com": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        },
        "registry.redhat.io": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        }
      }
    }
  4. 编辑新文件并添加描述 registry 的部分:

      "auths": {
    ...
        "<local_registry_host_name>:<local_registry_host_port>": { 1
          "auth": "<credentials>", 2
          "email": "you@example.com"
      },
    ...
    1
    使用 <local_registry_host_name> 指定您证书中指定的 registry 域名,使用 <local_registry_host_port> 指定镜像 registry 用来提供内容的端口。
    2
    使用 <credentials> 为您生成的镜像 registry 指定 base64 编码的用户名和密码。

    该文件类似于以下示例:

    {
      "auths": {
        "cloud.openshift.com": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "quay.io": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "registry.connect.redhat.com": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        },
        "<local_registry_host_name>:<local_registry_host_port>": {
          "auth": "<credentials>",
          "email": "you@example.com"
        },
        "registry.redhat.io": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        }
      }
    }

3.3.5. 镜像 OpenShift Container Platform 镜像存储库

镜像要在集群安装或升级过程中使用的 OpenShift Container Platform 镜像存储库。

先决条件

  • 您已将镜像 registry 配置为在受限网络中使用,并可访问您配置的证书和凭证。
  • 您已从 Red Hat OpenShift Cluster Manager 站点的 Pull Secret页面下载了 pull secret,并已修改为包含镜像存储库身份验证信息。

流程

在堡垒主机上完成以下步骤:

  1. 查看 OpenShift Container Platform 下载页面,以确定您要安装的 OpenShift Container Platform 版本,并决定 Repository Tags 页中的相应标签(tag)。
  2. 设置所需的环境变量:

    $ export OCP_RELEASE=<release_version> 1
    $ export LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>' 2
    $ export LOCAL_REPOSITORY='<repository_name>' 3
    $ export PRODUCT_REPO='openshift-release-dev' 4
    $ export LOCAL_SECRET_JSON='<path_to_pull_secret>' 5
    $ export RELEASE_NAME="ocp-release" 6
    1
    对于 <release_version>,请指定与 OpenShift Container Platform 版本对应的标签,用于您的架构,如 4.3.0-x86_64
    2
    对于 <local_registry_host_name>,请指定镜像存储库的 registry 域名;对于 <local_registry_host_port>,请指定用于提供内容的端口。
    3
    对于 <repository_name>,请指定要在 registry 中创建的存储库名称,如 ocp4/openshift4
    4
    要镜像的存储库。对于生产环境版本,必须指定 openshift-release-dev
    5
    对于 <path_to_pull_secret>,请指定您创建的镜像 registry 的 pull secret 的绝对路径和文件名。
    6
    发行版本镜像。对于生产环境版本,您必须指定 ocp-release
  3. 镜像存储库:

    $ oc adm -a ${LOCAL_SECRET_JSON} release mirror \
         --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
         --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
         --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}

    该命令将发行信息提取为摘要,其输出包括安装集群时所需的 imageContentSources 数据。

  4. 记录上一命令输出中的 imageContentSources 部分。您的镜像信息与您的镜像存储库相对应,您必须在安装过程中将 imageContentSources 部分添加到 install-config.yaml 文件中。
  5. 要创建基于您镜像内容的安装程序,请提取内容并将其固定到发行版中:

    $ oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"
    重要

    要确保将正确的镜像用于您选择的 OpenShift Container Platform 版本,您必须从镜像内容中提取安装程序。

    您必须在有活跃互联网连接的机器上执行这个步骤。

3.3.6. 使用带有备用或经过镜像的 registry 的 Samples Operator 镜像流

OpenShift 命名空间中大多数由 Samples Operator 管理的镜像流指向位于 registry.redhat.io 上红帽 registry 中的镜像。镜像功能不适用于这些镜像流。

重要

jenkinsjenkins-agent-mavenjenkins-agent-nodejs 镜像流的确来自安装有效负载,并由 Samples Operator 管理,因此这些镜像流不需要进一步的镜像操作。

将 Sample Operator 配置文件中的 samplesRegistry 字段设置为 registry.redhat.io 有很多冗余,因为它已经定向到 registry.redhat.io,只用于 Jenkins 镜像和镜像流。它还会破坏 Jenkins 镜像流的安装有效负载。

Samples Operator 禁止将以下 registry 用于 Jenkins 镜像流:

注意

cliinstallermust-gathertest 镜像流虽然属于安装有效负载的一部分,但不由 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
  2. registry.redhat.io 中与您在受限网络环境中需要的任何镜像流关联的镜像,镜像 (mirror) 成一个定义的镜像 (mirror):

    $ oc image mirror registry.redhat.io/rhscl/ruby-25-rhel7:latest ${MIRROR_ADDR}/rhscl/ruby-25-rhel7:latest
  3. 在集群的镜像配置对象中,为镜像添加所需的可信 CA:

    $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config
    $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge
  4. 更新 Samples Operator 配置对象中的 samplesRegistry 字段,使其包含镜像配置中定义的镜像位置的 hostname 部分:

    $ oc get configs.samples.operator.openshift.io -n openshift-cluster-samples-operator
    注意

    这是必要的,因为镜像流导入过程在此刻不使用镜像(mirro)或搜索机制。

  5. 将所有未镜像的镜像流添加到 Samples Operator 配置对象的 skippedImagestreams 字段。或者,如果您不想支持任何示例镜像流,请在 Samples Operator 配置对象中将 Samples Operator 设置为 Removed

    注意

    镜像流导入失败两小时后,任何没有跳过的未镜像的镜像流,或者如果 Samples Operator 没有更改为 Removed,都会导致 Samples Operator 报告Degraded 状态。

    OpenShift 命名空间中的多个模板都引用镜像流。因此,使用 Removed 清除镜像流和模板,将避免在因为缺少镜像流而导致镜像流和模板无法正常工作时使用它们。

后续步骤

3.4. 可用的集群自定义

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

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

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

3.4.1. 集群配置资源

所有集群配置资源都作用于全局范围(而非命名空间),且命名为 cluster

资源名称描述

apiserver.config.openshift.io

提供 api-server 配置,如证书和证书颁发机构

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

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

3.4.2. Operator 配置资源

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

资源名称描述

console.operator.openshift.io

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

config.imageregistry.operator.openshift.io

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

config.samples.operator.openshift.io

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

3.4.3. 其他配置资源

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

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

alertmanager.monitoring.coreos.com

main

openshift-monitoring

控制 alertmanager 部署参数。

ingresscontroller.operator.openshift.io

default

openshift-ingress-operator

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

3.4.4. 信息资源

可以使用这些资源检索集群信息。请不要直接编辑这些资源。

资源名称实例名称描述

clusterversion.config.openshift.io

version

在 OpenShift Container Platform 4.3 中,不得自定义生产集群的 ClusterVersion 资源,而应遵循相关流程来更新集群

dns.config.openshift.io

cluster

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

infrastructure.config.openshift.io

cluster

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

network.config.openshift.io

cluster

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

3.5. 配置防火墙

如果使用防火墙,您必须进行配置,以便 OpenShift Container Platform 能访问正常运作所需要的网站。您必须始终授予一些站点的访问权限,如果使用 Red Hat Insights、Telemetry 服务、托管集群的云以及某些构建策略,则还要授予更多站点的访问权限。

3.5.1. 为 OpenShift Container Platform 配置防火墙

在安装 OpenShift Container Platform 之前,您必须配置防火墙,以授予 OpenShift Container Platform 所需站点的访问权限。

流程

  1. 将以下 registry URL 列入白名单:

    URL功能

    registry.redhat.io

    提供核心容器镜像

    *.quay.io

    提供核心容器镜像

    sso.redhat.com

    https://cloud.redhat.com/openshift 站点使用 sso.redhat.com 提供的身份验证

  2. 将提供构建所需语言或框架的资源的任何站点列入白名单。
  3. 如果不禁用 Telemetry,您必须授予对以下 URL 的访问权限,以便能访问 Red Hat Insights:

    URL功能

    cert-api.access.redhat.com

    Telemetry 所需

    api.access.redhat.com

    Telemetry 所需

    infogw.api.openshift.com

    Telemetry 所需

    https://cloud.redhat.com/api/ingress

    Telemetry 和 insights-operator 需要

  4. 如果使用 Amazon Web Services (AWS)、Microsoft Azure 或 Google Cloud Platform (GCP) 来托管您的集群,您必须授予对提供该云的云供应商 API 和 DNS 的 URL 的访问权限:

    URL功能

    AWS

    *.amazonaws.com

    需要此项以访问 AWS 服务和资源。请参阅 AWS 文档中 AWS Service Endpoints,以确定您使用的区域所允许的具体端点。

    GCP

    *.googleapis.com

    需要此项以访问 GCP 服务和资源。请参阅 GCP 文档中的 Cloud Endpoints,以确定您的 API 所允许的端点。

    accounts.google.com

    需要此项以访问您的 GCP 帐户。

    Azure

    management.azure.com

    需要此项以访问 Azure 服务和资源。请参阅 Azure 文档中的Azure REST API 参考,以确定您的 API 所允许的端点。

  5. 将以下 URL 列入白名单:

    URL功能

    mirror.openshift.com

    需要此项以访问镜像安装内容和镜像

    *.apps.<cluster_name>.<base_domain>

    需要此项以访问默认的集群路由,除非您在安装过程中设置了入口通配符

    quay-registry.s3.amazonaws.com

    需要此项以访问 AWS 中的 Quay 镜像内容

    api.openshift.com

    需要此项以检查集群是否有可用的更新

    art-rhcos-ci.s3.amazonaws.com

    需要此项以下载 Red Hat Enterprise Linux CoreOS (RHCOS) 镜像

    api.openshift.com

    集群令牌所需

    cloud.redhat.com/openshift

    集群令牌所需

法律通告

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

为了尽快向用户提供最新的信息,本文档可能会包括由机器自动从英文原文翻译的内容。如需更多信息,请参阅此说明。