从 3.10.45 开始，您可以在 IBM POWER 服务器上安装 OpenShift Container Platform。

只在单一系统上安装 OpenShift Container Platform 只适用于开发环境。您不能在生产环境中使用这个 all-in-one 环境。

下表描述了单个 master（etcd 在同一个主机上安装）和两个节点的示例环境：

以下描述了一个示例环境，它有三个 master ，一个 HAProxy 负载均衡器和两个使用 原生 HA 的 节点。etcd 在 master 节点上作为静态 pod 运行：

以下是三个 master 的示例环境，一个 HAProxy 负载均衡器，三个外部集群的 etcd 主机，以及使用 原生 HA 方法的两个 节点:

您还可以安装 OpenShift Container Platform 作为一个独立的 registry，它使用 OpenShift Container Platform 集成的 registry。有关此场景的详情，请参阅安装独立 registry。

系统容器安装类型使用以下镜像：

默认情况下，所有上述镜像都是从 registry.redhat.io 的 Red Hat Registry 中拉取的。

如果需要在安装过程中使用私有 registry 来拉取镜像，可以提前指定 registry 信息。根据需要，在清单文件中设置以下 Ansible 变量：

oreg_url='<registry_hostname>/openshift3/ose-${component}:${version}'
openshift_docker_insecure_registries=<registry_hostname>
openshift_docker_blocked_registries=<registry_hostname>

默认组件从 oreg_url 值继承镜像前缀和版本。

额外的、不安全的以及受阻的容器 registry 的配置会在安装过程开始时生效，以确保在尝试拉取任何所需的镜像前应用这些设置。

安装过程会创建相关的 systemd 单元，以便可以使用一般的 systemctl 命令启动、停止和轮询服务。对于系统容器安装，这些单元名称与 RPM 安装的名称相匹配。

容器化安装的所有 OpenShift Container Platform 配置文件和基于 RPM 安装的配置文件位于同一个位置，并会在 os-tree 升级后保留下来。

但是，对于 Atomic Host 安装，默认镜像流和模板文件 安装在 /etc/origin/examples/ 中，而不是标准的 /usr/share/openshift/examples/ 中，因为在 RHEL Atomic Host 中这个目录是只读的。

RHEL Atomic Host 安装通常有一个非常小的 root 文件系统。但是，etcd、master 和节点容器会在 /var/lib/ 目录中保存数据。在安装 OpenShift Container Platform 前，请确保您在 root 文件系统中有足够的空间。详情请查看系统要求一节。

您的红帽帐户必须具有有效的 OpenShift Container Platform 订阅。如果没有，请与您的销售代表联系以了解更多信息。

系统要求因主机类型而异：

满足 RHEL Atomic Host 中 /var/ 文件系统大小的要求需要对默认配置进行修改。有关在安装过程中或安装后配置此功能的说明，请参阅使用 Docker 格式容器管理存储。

系统的临时目录根据 Python 标准库中 tempfile 模块中定义的规则确定。

您必须为每个运行容器守护进程的系统配置存储。对于容器化安装，您需要在 master 上存储。另外，在默认情况下，Web 控制台在 master 上的容器中运行，masters 需要存储来运行 Web 控制台。容器在节点上运行，因此节点始终需要存储。存储的大小取决于工作负载、容器数量、运行容器的大小以及容器的存储要求。您还必须配置存储以运行容器化 etcd。

强烈建议您使用带有可快速处理串口写入(fsync)的存储的 etcd，如 NVMe 或者 SSD。不建议使用 Ceph、NFS 和 spinning 磁盘。

满足最低要求的测试或示例环境功能。对于生产环境，建议使用以下设置：

更多详情，请参阅 OpenShift Container Platform master 主机的建议实践。

如需更多信息，请参阅 大小考虑 和 集群限制。

任何在聚合模式或独立模式集群中使用的节点都被视为存储节点。虽然单个节点不能在多个组中，但存储节点可以被分到不同的集群组。对于每个存储节点组：

监控堆栈需要额外的系统资源，它会被默认安装。请参阅 计算资源建议 和 集群监控文档。

在安装 OpenShift Container Platform 之前，必须在所有服务器上启用 Security-Enhanced Linux（SELinux），否则安装程序将失败。另外，在 /etc/selinux/config 文件中配置 SELINUX =enforcing 和 SELINUXTYPE=targeted:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

默认情况下，OpenShift Container Platform master 和节点使用它们运行的系统中的所有可用内核。您可以通过设置 GOMAXPROCS 环境变量来选择 OpenShift Container Platform 使用的内核数。如需更多信息，请参阅 Go Language 文档，包括 GOMAXPROCS 环境变量是如何工作的。

例如，在启动服务器前运行以下命令使 OpenShift Container Platform 只在一个核心上运行：

# export GOMAXPROCS=1

OverlayFS 是一个联合文件系统，允许用户在一个文件系统上使用另一个文件系统。

从 Red Hat Enterprise Linux 7.4 开始，您可以选择将 OpenShift Container Platform 环境配置为使用 OverlayFS。除了老的 overlay 驱动程序外，还完全支持 overlay2 图形驱动程序。但是，红帽建议使用 overlay2 而不是 overlay，因为其有速度和简单实施的优点。

比较 Overlay 和 Overlay2 Graph Drivers 提供了更多与 overlay 和 overlay2 驱动程序相关的信息。

有关如何为 Docker 服务启用 overlay2 图形驱动程序的说明，请参见 Atomic Host 文档中的 Overlay 图形驱动程序部分。

OpenShift Container Platform 在集群中的主机上运行容器，在一些情况下（如构建操作和 registry 服务），它使用特权容器进行操作。另外，这些容器会访问主机的 Docker 守护进程，并执行 docker build 和 docker push 操作。因此，集群管理员必须了解对镜像执行 docker run 操作相关的固有安全风险，因为它们实际具有根访问权限。这对 docker build 操作尤其重要。

可将有风险的容器分配给特定的节点，从而使可能的风险只限制在这些特定的节点中。更多信息，请参阅开发指南中的指定构建到特定节点 部分。对于集群管理员，请参阅 配置全局构建默认值和覆盖标题。

您还可以使用 安全上下文约束来控制 Pod 可以执行的操作，以及它有权访问的内容。有关如何在 Dockerfile 中使用 USER 来启用镜像运行的信息，请参阅管理安全性上下文约束 （需要具有 cluster-admin 特权的用户）。

如需了解更多相关信息，请参阅以下文章：

OpenShift Container Platform 需要环境中具有一个可以全面正常工作的 DNS 服务器。理想的情况是，在一个单独的主机上运行 DNS 软件，为平台上运行的主机和容器提供名称解析服务。

OpenShift Container Platform 的主要组件在容器内运行，并使用以下流程进行名称解析：

从 OpenShift Container Platform 3.2 开始，在所有 master 和节点上自动配置 dnsmasq。pod 使用节点作为其 DNS，节点会转发请求。默认情况下，dnsmasq 被配置为侦听节点上的端口 53，因此节点无法运行任何其他类型的 DNS 应用程序。

以下是 DNS 记录示例：

master1    A   10.64.33.100
master2    A   10.64.33.103
node1      A   10.64.33.101
node2      A   10.64.33.102

如果没有可以正常工作的 DNS 环境，则可能会遇到以下问题：

*.cloudapps.example.com. 300 IN  A 192.168.133.2

master 和节点主机之间必须存在一个共享网络。如果您计划使用标准集群安装过程 为高可用性配置多个 master，则必须在安装过程中选择将 IP 配置为您的 虚拟 IP (VIP)。您选择的 IP 必须在所有节点之间路由，如果使用 FQDN 进行配置，则必须在所有节点上解析。

[OSEv3:vars]
os_firewall_use_firewalld=True

Kubernetes 持久性卷 框架允许您使用环境中可用的联网存储来置备带有持久性存储的 OpenShift Container Platform 集群。这可在根据应用程序需要完成初始 OpenShift Container Platform 安装后完成，为用户提供在不了解底层基础架构的情况下请求这些资源的方法。

《配置集群指南》为集群管理员提供了使用 NFS、GlusterFS、Ceph RBD、OpenStack Cinder、AWS Elastic Block Store(EBS)、GCE Persistent Disks 和 iSCSI使用持久性存储置备 OpenShift Container Platform 集群的说明。

如果在云供应商环境上安装 OpenShift Container Platform 时，需要考虑某些方面。

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook  [-i /path/to/inventory] \
  playbooks/byo/openshift_facts.yml

OverlayFS 是一种联合文件系统。OverlayFS 允许您在另一个文件系统上覆盖一个文件系统。更改记录在上面的文件系统中，而较小的文件系统则未修改。

比较 Overlay 和 Overlay2 Graph Drivers 提供了更多与 overlay 和 overlay2 驱动程序相关的信息。

要使用 overlay2 驱动程序，下层必须使用 XFS 文件系统。较低层文件系统是保持未修改的文件系统。

有关为 Docker 服务启用 OverlayFS 存储驱动程序的详情，请查看 Red Hat Enterprise Linux Atomic Host 文档。

您可以使用 Docker 中包含的 docker-storage-setup 脚本来创建精简池设备并配置 Docker 的存储驱动程序。安装 Docker 后，可以进行此操作，且必须在创建镜像或容器前进行此操作。该脚本从 /etc/sysconfig/docker-storage-setup 文件中读取配置选项，并支持 3 个创建逻辑卷的选项：

使用附加块设备是最可靠的选项，但需要在配置 Docker 存储前向您的主机添加另一个块设备。其他选项都需要在置备主机时保留可用空间。使用 root 文件系统卷组中剩余的可用空间会导致一些应用程序出现问题，例如 Red Hat Mobile Application Platform（RHMAP）。

如果您需要在创建 docker-pool 后重新配置 Docker 存储：

有关 LVM 管理的详情，请查看逻辑卷管理器管理。

OpenShift Container Platform 能够检查镜像是否来自可信源。容器安全指南介绍了相关内容。

您可以使用 atomic 命令行界面（CLI）版本 1.12.5 或更高版本来配置镜像签名验证。在 RHEL Atomic Host 系统中预先安装 atomic CLI。

以下文件和目录组成主机的信任配置：

您可以直接管理每个节点上的信任配置，或者管理独立主机上的文件，或使用 Ansible 将这些文件分发到适当的节点。有关使用 Ansible 自动分发文件的实例，请参阅容器镜像签名集成指南。

为防止容器的日志文件（容器运行在的节点上的 /var/lib/docker/containers/<hash> /<hash>-json.log 文件）的大小增长到会出问题的大小，您可以配置 Docker 的 json-file 日志记录驱动程序来限制日志文件的大小和数量。

您可以在容器运行的节点上的 /var/lib/docker/containers/<hash> / 目录中查看容器日志。例如：

# ls -lh /var/lib/docker/containers/f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8/
total 2.6M
-rw-r--r--. 1 root root 5.6K Nov 24 00:12 config.json
-rw-r--r--. 1 root root 649K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.1
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.2
-rw-r--r--. 1 root root 1.3K Nov 24 00:12 hostconfig.json
drwx------. 2 root root    6 Nov 24 00:12 secrets

当使用 Dockerfile 中的 VOLUME 指令置备卷或使用 docker run -v <volumename> 命令时，会使用主机的存储空间。使用这个存储会导致意外地出现存储空间的问题，并可能导致主机关闭。

在 OpenShift Container Platform 中，试图运行自己的镜像可能会导致占用完节点主机上的所有存储空间。解决这个问题的一种方法是防止用户使用卷运行镜像。这样，用户唯一可以访问的存储会被限制，集群管理员可以分配存储配额。

使用 docker-novolume-plugin 可通过禁止使用定义的本地卷启动容器来解决这个问题。特别是，插件块 docker run 命令包含以下内容：

该插件不会阻止对绑定挂载的引用。

要启用 docker-novolume-plugin，在每个节点主机上执行以下步骤：

启用此插件后，定义了本地卷的容器无法启动并显示以下错误消息：

runContainer: API error (500): authorization denied by plugin
docker-novolume-plugin: volumes are not allowed

用于定义节点配置的 Configmap 必须在 openshift-node 项目中可用。现在，ConfigMap 也是节点标签的权威定义，旧的 openshift_node_labels 值会被实际忽略。

默认情况下，安装程序会在集群安装过程中创建以下默认 ConfigMap:

另外还会创建以下 ConfigMap，将节点标记为多个角色：

以下 ConfigMap 是每个现有默认节点组的 CRI-O 变体：

安装最新的 openshift-ansible 软件包后，您可以在 /usr/share/ansible/openshift-ansible/roles/openshift_facts/defaults/main.yml 文件中以 YAML 格式查看默认节点组定义集：

openshift_node_groups:
  - name: node-config-master 1
    labels:
      - 'node-role.kubernetes.io/master=true' 2
    edits: [] 3
  - name: node-config-infra
    labels:
      - 'node-role.kubernetes.io/infra=true'
    edits: []
  - name: node-config-compute
    labels:
      - 'node-role.kubernetes.io/compute=true'
    edits: []
  - name: node-config-master-infra
    labels:
      - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true'
    edits: []
  - name: node-config-all-in-one
    labels:
      - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true,node-role.kubernetes.io/compute=true'
    edits: []

如果您没有在清单文件中的 [OSEv3:vars] 组中设置 openshift_node_groups 变量，则会使用这些默认值。但是，如果要设置自定义节点组，则必须在清单文件中定义整个 openshift_node_groups 结构，包括所有计划的节点组。

openshift_node_groups 值没有与默认值合并，您必须将 YAML 定义转换为 Python 字典。然后，您可以使用 edits 字段指定键值对来修改任何节点配置变量。

例如，以下清单文件中的条目定义了名为 node-config-master、node-config-infra 和 node-config-compute 的组。

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true']}]

您还可以使用其他标签定义新节点组名称，清单文件中的以下条目定义了名为 node-config-master、node- config-infra、node- config-compute 和 node-config-compute-storage 的组。

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true']}, {'name': 'node-config-compute-storage', 'labels': ['node-role.kubernetes.io/compute-storage=true']}]

当在清单文件中设置条目时，您还可编辑节点组的 ConfigMap:

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.pods-per-core','value': ['20']}]}]

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.experimental-allocatable-ignore-eviction','value': ['true']}, {'key': 'kubeletArguments.eviction-hard', 'value': ['memory.available<1Ki']}]}]

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'volumeConfig.localQuota','value': {'perFSGroup':'512Mi'}}]}]

每当运行 openshift_node_group.yml playbook 时，在 edits 字段中定义的更改会更新相关的 ConfigMap（本例中的node-config-compute ），这最终将影响主机上的节点配置文件。

要把 ConfigMap 映射到节点，在清单的 [nodes] 组中定义的所有主机都需要使用 openshift_node_group_name 变量分配到一个节点组。

openshift_node_group_name 的值用于选择配置每个节点的 ConfigMap。例如：

[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'

如果在 openshift_node_groups 中定义了其他自定义 ConfigMap，它们也可以被使用。例如：

[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
gluster[1:6].example.com openshift_node_group_name='node-config-compute-storage'

您可以在集群安装过程中为节点主机分配 标签（Label）。通过标签，调度程序（scheduler）可以决定 pod 放置的节点位置。

如果要修改分配给节点主机的默认标签，必须创建自己的自定义节点组。您无法再设置 openshift_node_labels 变量来更改标签。请参阅 节点组定义来修改默认节点组。

除 node-role.kubernetes.io/infra=true （使用此组的主机也称为 专用基础架构节点，在 配置 Dedicated Infrastructure 节点一节中会进一步讨论） 外，其他实际标签名称和值都是任意的并可随意分配，但最好根据集群的要求进行分配。

[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'

# default selectors for router and registry services
# openshift_router_selector='node-role.kubernetes.io/infra=true'
# openshift_registry_selector='node-role.kubernetes.io/infra=true'

[nodes]
infra-node1.example.com openshift_node_group_name='node-config-infra'

openshift_hosted_manage_registry=false
openshift_hosted_manage_router=false

[nodes]
master.example.com openshift_node_group_name='node-config-master-infra'

为了使部署成功，需要有效的镜像标签。将 <tag> 替换为与 OpenShift Container Platform 3.11 兼容的 Red Hat Gluster Storage 版本，如清单文件中以下变量互操作性表格 中所述：

如果没有使用 registry 存储选项，默认的 OpenShift Container Registry 为临时存储。当 pod 不再存在时会丢失所有数据。

在使用高级安装程序时启用 registry 存储有几个选项：

选项 A：NFS 主机组

当设置以下变量时，会在集群安装过程中在 [nfs]主机组中的主机上创建一个 NFS 卷（路径为 <nfs_directory>/<volume_name>）例如，使用这些选项的卷路径是 /exports/registry:

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_hosted_registry_storage_kind=nfs
openshift_hosted_registry_storage_access_modes=['ReadWriteMany']
openshift_hosted_registry_storage_nfs_directory=/exports
openshift_hosted_registry_storage_nfs_options='*(rw,root_squash)'
openshift_hosted_registry_storage_volume_name=registry
openshift_hosted_registry_storage_volume_size=10Gi

选项 B：外部 NFS 主机

要使用外部 NFS 卷，必须在存储主机上有 <nfs_directory>/<volume_name> 路径。使用以下选项的远程卷路径为 nfs.example.com:/exports/registry。

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_hosted_registry_storage_kind=nfs
openshift_hosted_registry_storage_access_modes=['ReadWriteMany']
openshift_hosted_registry_storage_host=nfs.example.com
openshift_hosted_registry_storage_nfs_directory=/exports
openshift_hosted_registry_storage_volume_name=registry
openshift_hosted_registry_storage_volume_size=10Gi

升级或安装带有 NFS 的 OpenShift Container Platform

选项 C：OpenStack Platform

OpenStack 存储配置必须已经存在。

[OSEv3:vars]

openshift_hosted_registry_storage_kind=openstack
openshift_hosted_registry_storage_access_modes=['ReadWriteOnce']
openshift_hosted_registry_storage_openstack_filesystem=ext4
openshift_hosted_registry_storage_openstack_volumeID=3a650b4f-c8c5-4e0a-8ca5-eaee11f16c57
openshift_hosted_registry_storage_volume_size=10Gi

选项 D:：WS 或者其它 S3 存储解决方案

简单的存储解决方案（S3）存储桶必须已经存在。

[OSEv3:vars]

#openshift_hosted_registry_storage_kind=object
#openshift_hosted_registry_storage_provider=s3
#openshift_hosted_registry_storage_s3_accesskey=access_key_id
#openshift_hosted_registry_storage_s3_secretkey=secret_access_key
#openshift_hosted_registry_storage_s3_bucket=bucket_name
#openshift_hosted_registry_storage_s3_region=bucket_region
#openshift_hosted_registry_storage_s3_chunksize=26214400
#openshift_hosted_registry_storage_s3_rootdirectory=/registry
#openshift_hosted_registry_pullthrough=true
#openshift_hosted_registry_acceptschema2=true
#openshift_hosted_registry_enforcequota=true

如果您使用不同的 S3 服务，如 Minio 或 ExoScale，还要添加 region 端点参数：

openshift_hosted_registry_storage_s3_regionendpoint=https://myendpoint.example.com/

选项 E：聚合模式

与 配置聚合模式 类似，可将 Red Hat Gluster Storage 配置为在初始安装集群期间为 OpenShift Container Registry 提供存储，以便为 registry 提供冗余可靠的存储。

选项 F： Google Compute Engine（GCE）上的 Google Cloud Storage（GCS）存储桶

GCS 存储桶必须已经存在。

[OSEv3:vars]

openshift_hosted_registry_storage_provider=gcs
openshift_hosted_registry_storage_gcs_bucket=bucket01
openshift_hosted_registry_storage_gcs_keyfile=test.key
openshift_hosted_registry_storage_gcs_rootdirectory=/registry

选项 G：使用 vSphere Cloud Provider（VCP）的 vSphere 卷

vSphere Cloud Provider 必须通过 OpenShift Container Platform 节点访问的数据存储进行配置。

在为 registry 使用 vSphere 卷时，您必须将存储访问模式设置为 ReadWriteOnce，并将副本数设置为 1:

[OSEv3:vars]

openshift_hosted_registry_storage_kind=vsphere
openshift_hosted_registry_storage_access_modes=['ReadWriteOnce']
openshift_hosted_registry_storage_annotations=['volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume']
openshift_hosted_registry_replicas=1

必须设置 openshift_metrics_cassandra_storage_type 变量才能将持久性存储用于指标数据。如果没有设置 openshift_metrics_cassandra_storage_type，则集群指标数据将存储在 emptyDir 卷中，该卷将在 Cassandra pod 终止时被删除。

在集群安装过程中启用集群指标存储有三个选项：

选项 A：动态

如果您的 OpenShift Container Platform 环境支持为云供应商进行 动态卷置备，请使用以下变量：

[OSEv3:vars]

openshift_metrics_cassandra_storage_type=dynamic

如果有多个默认动态置备的卷类型，如 gluster-storage 和 glusterfs-storage-block，您可以根据变量指定置备的卷类型。使用以下变量：

[OSEv3:vars]

openshift_metrics_cassandra_storage_type=pv
openshift_metrics_cassandra_pvc_storage_class_name=glusterfs-storage-block

有关使用 DynamicProvisioningEnabled 来启用或禁用动态置备的详情，请查看 卷配置。

选项 B：NFS 主机组

当设置以下变量时，会在集群安装过程中在 [nfs]主机组中的主机上创建一个 NFS 卷（路径为 <nfs_directory>/<volume_name>）例如，使用这些选项的卷路径是 /exports/metrics:

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_metrics_storage_kind=nfs
openshift_metrics_storage_access_modes=['ReadWriteOnce']
openshift_metrics_storage_nfs_directory=/exports
openshift_metrics_storage_nfs_options='*(rw,root_squash)'
openshift_metrics_storage_volume_name=metrics
openshift_metrics_storage_volume_size=10Gi

选项 C：外部 NFS 主机

要使用外部 NFS 卷，必须在存储主机上有 <nfs_directory>/<volume_name> 路径。

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_metrics_storage_kind=nfs
openshift_metrics_storage_access_modes=['ReadWriteOnce']
openshift_metrics_storage_host=nfs.example.com
openshift_metrics_storage_nfs_directory=/exports
openshift_metrics_storage_volume_name=metrics
openshift_metrics_storage_volume_size=10Gi

使用以下选项的远程卷路径是 nfs.example.com:/exports/metrics。

升级或安装带有 NFS 的 OpenShift Container Platform

不建议将 NFS 用于 OpenShift Container Platform 核心组件，因为 NFS（和 NFS 协议）没有提供组成 OpenShift Container Platform 基础架构的应用程序所需的一致性。

因此，安装程序和更新 playbook 需要一个选项来启用使用带核心基础架构组件的 NFS。

# Enable unsupported configurations, things that will yield a partially
# functioning cluster but would not be supported for production use
#openshift_enable_unsupported_configurations=false

如果您在升级或安装集群时看到以下信息，则需要额外的步骤。

TASK [Run variable sanity checks] **********************************************
fatal: [host.example.com]: FAILED! => {"failed": true, "msg": "last_checked_host: host.example.com, last_checked_var: openshift_hosted_registry_storage_kind;nfs is an unsupported type for openshift_hosted_registry_storage_kind. openshift_enable_unsupported_configurations=True mustbe specified to continue with this configuration."}

在 Ansible 清单文件中指定以下参数：

[OSEv3:vars]
openshift_enable_unsupported_configurations=True

必须设置 openshift_logging_es_pvc_dynamic 变量，以便使用持久性存储进行日志记录。如果没有设置 openshift_logging_es_pvc_dynamic，则集群日志记录数据存储在 emptyDir 卷中，当 Elasticsearch Pod 终止时会删除它。

在集群安装过程中启用集群日志记录存储有三个选项：

选项 A：动态

如果您的 OpenShift Container Platform 环境有动态卷置备，它可以通过云供应商或一个独立的存储供应商进行配置。例如，云供应商可以在 GCE 上带有 provisioner kubernetes.io/gce-pd 的 StorageClass，而一个独立的存储供应商（如 GlusterFS）则可能具有带有 provisioner kubernetes.io/glusterfs 的 StorageClass。在这两种情况下，请使用以下变量：

[OSEv3:vars]

openshift_logging_es_pvc_dynamic=true

有关动态置备的额外信息，请参阅 动态置备和创建存储类。

如果有多个默认动态置备的卷类型，如 gluster-storage 和 glusterfs-storage-block，您可以根据变量指定置备的卷类型。使用以下变量：

[OSEv3:vars]

openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_storage_class_name=glusterfs-storage-block

有关使用 DynamicProvisioningEnabled 来启用或禁用动态置备的详情，请查看 卷配置。

选项 B：NFS 主机组

当设置以下变量时，会在集群安装过程中在 [nfs]主机组中的主机上创建一个 NFS 卷（路径为 <nfs_directory>/<volume_name>）例如，使用这些选项的卷路径是 /exports/logging:

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_nfs_directory=/exports 1
openshift_logging_storage_nfs_options='*(rw,root_squash)' 2
openshift_logging_storage_volume_name=logging 3
openshift_logging_storage_volume_size=10Gi
openshift_enable_unsupported_configurations=true
openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_size=10Gi
openshift_logging_es_pvc_storage_class_name=''
openshift_logging_es_pvc_dynamic=true
openshift_logging_es_pvc_prefix=logging

选项 C：外部 NFS 主机

要使用外部 NFS 卷，必须在存储主机上有 <nfs_directory>/<volume_name> 路径。

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_host=nfs.example.com 1
openshift_logging_storage_nfs_directory=/exports 2
openshift_logging_storage_volume_name=logging 3
openshift_logging_storage_volume_size=10Gi
openshift_enable_unsupported_configurations=true
openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_size=10Gi
openshift_logging_es_pvc_storage_class_name=''
openshift_logging_es_pvc_dynamic=true
openshift_logging_es_pvc_prefix=logging

使用以下选项的远程卷路径为 nfs.example.com:/exports/logging。

升级或安装带有 NFS 的 OpenShift Container Platform

不建议将 NFS 用于 OpenShift Container Platform 核心组件，因为 NFS（和 NFS 协议）没有提供组成 OpenShift Container Platform 基础架构的应用程序所需的一致性。

因此，安装程序和更新 playbook 需要一个选项来启用使用带核心基础架构组件的 NFS。

# Enable unsupported configurations, things that will yield a partially
# functioning cluster but would not be supported for production use
#openshift_enable_unsupported_configurations=false

如果您在升级或安装集群时看到以下信息，则需要额外的步骤。

TASK [Run variable sanity checks] **********************************************
fatal: [host.example.com]: FAILED! => {"failed": true, "msg": "last_checked_host: host.example.com, last_checked_var: openshift_hosted_registry_storage_kind;nfs is an unsupported type for openshift_hosted_registry_storage_kind. openshift_enable_unsupported_configurations=True mustbe specified to continue with this configuration."}

在 Ansible 清单文件中指定以下参数：

[OSEv3:vars]
openshift_enable_unsupported_configurations=True

OpenShift Ansible 代理（OAB）在安装过程中默认启用。

如果您不想安装 OAB，请在清单文件中将 ansible_service_broker_install 参数值设置为 false:

ansible_service_broker_install=false

模板服务代理（TSB）在安装过程中默认启用。

如果不想安装 TSB，将 template_service_broker_install 参数值设置为 false:

template_service_broker_install=false

要配置 TSB，则必须将一个或多个项目定义为代理的源命名空间，用于将模板和镜像流加载到服务目录中。通过修改清单文件中的 [OSEv3:vars] 部分中的以下内容来设置源项目：

openshift_template_service_broker_namespaces=['openshift','myproject']

下表描述了单个 master （单一 etcd 实例在同一主机上运行的静态 pod）、两个托管用户应用程序的 节点 以及两个具有 node-role.kubernetes.io/infra=true 标签的节点，用于托管专用基础架构的示例环境：

您可以看到以下清单文件的 [masters]、[etcd] 和 [nodes] 部分中出现的这些示例主机：

# Create an OSEv3 group that contains the masters, nodes, and etcd groups
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
# SSH user, this user should allow ssh based auth without requiring a password
ansible_ssh_user=root

# If ansible_ssh_user is not root, ansible_become must be set to true
#ansible_become=true

openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# host group for masters
[masters]
master.example.com

# host group for etcd
[etcd]
master.example.com

# host group for nodes, includes region info
[nodes]
master.example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

要使用本例，修改该文件以符合您的环境和规格，并将它保存为 /etc/ansible/hosts。

下表描述了单个 master、三个 etcd 主机、两个用于托管用户应用程序的节点，以及两个具有 node-role.kubernetes.io/infra=true 标签的节点:

您可以看到以下清单文件的 [masters]、[nodes] 和 [etcd] 部分中出现的这些示例主机：

# Create an OSEv3 group that contains the masters, nodes, and etcd groups
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# host group for masters
[masters]
master.example.com

# host group for etcd
[etcd]
etcd1.example.com
etcd2.example.com
etcd3.example.com

# host group for nodes, includes region info
[nodes]
master.example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

要使用本例，修改该文件以符合您的环境和规格，并将它保存为 /etc/ansible/hosts。

下面描述了使用 原生 HA 方法的三个 master 的示例环境：一个 HAProxy 负载均衡器，三个 etcd 主机，两个用于托管用户应用程序的节点，具有 用于托管专用基础架构 的 node-role.kubernetes.io/infra=true 标签的两个节点：

您可以看到以下清单文件的 [masters]、[etcd]、[lb] 和 [nodes] 部分中出现的这些示例主机：

# Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
# The lb group lets Ansible configure HAProxy as the load balancing solution.
# Comment lb out if your load balancer is pre-configured.
[OSEv3:children]
masters
nodes
etcd
lb

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# Native high availbility cluster method with optional load balancer.
# If no lb group is defined installer assumes that a load balancer has
# been preconfigured. For installation the value of
# openshift_master_cluster_hostname must resolve to the load balancer
# or to one or all of the masters defined in the inventory if no load
# balancer is present.
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-internal.example.com
openshift_master_cluster_public_hostname=openshift-cluster.example.com

# apply updated node defaults
openshift_node_groups=[{'name': 'node-config-all-in-one', 'labels': ['node-role.kubernetes.io/master=true', 'node-role.kubernetes.io/infra=true', 'node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.pods-per-core','value': ['20']}]}]

# host group for masters
[masters]
master1.example.com
master2.example.com
master3.example.com

# host group for etcd
[etcd]
etcd1.example.com
etcd2.example.com
etcd3.example.com

# Specify load balancer host
[lb]
lb.example.com

# host group for nodes, includes region info
[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

要使用本例，修改该文件以符合您的环境和规格，并将它保存为 /etc/ansible/hosts。

下面描述了使用 原生 HA 方法的三个 master 的示例环境（每个主机上的 etcd 作为静态 pod 运行）,一个 HAProxy 负载均衡器，两个用于托管用户应用程序的 节点，具有 用于托管专用基础架构 的 node-role.kubernetes.io/infra=true 标签的两个节点：

您可以看到以下清单文件的 [masters]、[etcd]、[lb] 和 [nodes] 部分中出现的这些示例主机：

# Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
# The lb group lets Ansible configure HAProxy as the load balancing solution.
# Comment lb out if your load balancer is pre-configured.
[OSEv3:children]
masters
nodes
etcd
lb

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# Native high availability cluster method with optional load balancer.
# If no lb group is defined installer assumes that a load balancer has
# been preconfigured. For installation the value of
# openshift_master_cluster_hostname must resolve to the load balancer
# or to one or all of the masters defined in the inventory if no load
# balancer is present.
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-internal.example.com
openshift_master_cluster_public_hostname=openshift-cluster.example.com

# host group for masters
[masters]
master1.example.com
master2.example.com
master3.example.com

# host group for etcd
[etcd]
master1.example.com
master2.example.com
master3.example.com

# Specify load balancer host
[lb]
lb.example.com

# host group for nodes, includes region info
[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

要使用本例，修改该文件以符合您的环境和规格，并将它保存为 /etc/ansible/hosts。

基于 RPM 的安装程序使用 RPM 软件包安装的 Ansible 运行本地主机上可用的 playbook 和配置文件。

要运行基于 RPM 的安装程序：

. 如果安装成功，验证安装。 如果安装失败，重试安装。

openshift3/ose-ansible 镜像是 OpenShift Container Platform 安装程序的容器化版本。这个安装程序镜像提供和基于 RPM 的安装程序相同的功能，但它可在容器化环境中运行，该环境中提供所有依赖项，而不是直接安装到主机上。使用它的唯一要求是能够运行容器。

# atomic install --system \
    --storage=ostree \
    --set INVENTORY_FILE=/path/to/inventory \
    --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/pre-install.yml \ 1
    --set OPTS="-v" \ 2
    registry.redhat.io/openshift3/ose-ansible:v3.11

$ ansible-playbook --user openshift \
  -i openshift-ansible/playbooks/openstack/inventory.py \
  -i inventory \
  openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml

安装程序使用模块化 playbook，以便管理员可以根据需要安装特定的组件。通过分隔角色和 playbook 可以更好地将临时管理任务作为目标。这会增加安装过程中的控件并节省时间。

主要的安装 playbook /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml 以特定顺序运行一组独立组件 playbook，安装程序会回到已完成阶段的最后进行报告。如果安装失败，会收到哪个阶段失败的信息以及 Ansible 运行中的错误信息。

在有互联网连接的 RHEL 7 服务器中，同步软件仓库：

拉取所需的容器镜像：

如果您的环境无法访问您的内部网络，并需要使用物理介质来传输内容，请导出镜像到压缩文件。如果您的主机同时连接到互联网和您的内部网络，可以跳过以下步骤，然后继续准备并填充存储库服务器。