红帽全球峰会配置集群
OpenShift Container Platform 3.11 安装和配置
摘要
第 1 章 概述
本指南涵盖了安装后 OpenShift Container Platform 集群的更多配置选项。
第 2 章 设置 Registry
2.1. 内部 Registry 概述
2.1.1. 关于 Registry
OpenShift Container Platform 可以从源代码构建 容器镜像，部署并管理它们的生命周期。为此，OpenShift Container Platform 提供了一个内部集成的容器镜像 registry，可在 OpenShift Container Platform 环境中部署以在本地管理镜像。
2.1.2. 集成的或独立 registry
在初始安装完整 OpenShift Container Platform 集群期间，可能会在安装过程中自动部署 registry。如果没有，或者您要进一步自定义 registry 的配置，请参阅在现有集群中部署 registry。
虽然它可以部署为作为完整 OpenShift Container Platform 集群集成的一部分运行，但 OpenShift Container Platform registry 可以作为独立容器镜像 registry 单独安装。
要安装独立 registry，请遵循安装独立 Registry。此安装路径部署运行 registry 和专用 Web 控制台的一体化集群。
2.2. 在现有集群中部署 registry
2.2.1. 概述
如果集成的 registry 之前在 OpenShift Container Platform 集群的初始安装过程中没有被自动部署，或者如果不再成功运行，您需要在现有集群中重新部署它，请参阅以下部分来了解部署新 registry 的选项。
如果您安装了 独立 registry，则不需要这个主题。
2.2.2. 设置 Registry 主机名
您可以为内部和外部引用配置 registry 的主机名和端口。通过这样做，镜像流将为镜像提供基于主机名的推送和拉取规格，允许使用镜像与对 registry 服务 IP 的更改进行隔离，并有可能允许镜像流及其引用在集群中可移植。
要设置从集群内部引用 registry 的主机名，请在 master 配置文件的 imagePolicyConfig 部分中设置 internalRegistryHostname。外部主机名通过在同一位置设置 externalRegistryHostname 值来控制。
镜像策略配置
imagePolicyConfig: internalRegistryHostname: docker-registry.default.svc.cluster.local:5000 externalRegistryHostname: docker-registry.mycompany.com
imagePolicyConfig:
internalRegistryHostname: docker-registry.default.svc.cluster.local:5000
externalRegistryHostname: docker-registry.mycompany.com
registry 本身必须使用相同的内部主机名值进行配置。这可以通过在 registry 署配置中设置 REGISTRY_OPENSHIFT_SERVER_ADDR 环境变量或设置 registry 配置的 OpenShift 部分中的值来完成。
如果您已经为 registry 启用了 TLS，服务器证书必须包含您希望引用 registry 的主机名。有关添加主机名到服务器证书的说明，请参阅保护registry。
2.2.3. 部署 Registry
要部署集成的容器镜像 registry，请以具有集群管理员特权的用户身份使用 oc adm registry 命令。例如：
oc adm registry --config=/etc/origin/master/admin.kubeconfig \
--service-account=registry \
--images='registry.redhat.io/openshift3/ose-${component}:${version}'
$ oc adm registry --config=/etc/origin/master/admin.kubeconfig \
--service-account=registry \
--images='registry.redhat.io/openshift3/ose-${component}:${version}' 这将创建服务和部署配置，两者均称为 docker-registry。部署成功后，会使用类似于 docker-registry-1-cpty9 的名称创建 pod。
查看创建 registry 时可以指定的完整选项列表：
oc adm registry --help
$ oc adm registry --help
--fs-group 的值需要是 registry 使用的 SCC 所允许的（通常为有限制的 SCC）。
2.2.4. 将 Registry 部署为 DaemonSet
使用 oc adm registry 命令将 registry 部署为带有 --daemonset 选项的 DaemonSet。
DaemonSet 可确保在创建节点时，节点包含指定 pod 的副本。删除节点时，会收集 pod。
如需有关 DaemonSet 的更多信息，请参阅使用 Daemonsets。
2.2.5. registry 计算资源
默认情况下，创建 registry 时没有设置计算资源请求或限值。对于生产环境，强烈建议更新 registry 的部署配置，以便为 registry 容器集设置资源请求和限值。否则，registry pod 将被视为 BestEffort pod。
有关配置请求和限制的更多信息，请参阅计算资源。
2.2.6. Registry 的存储
registry 存储容器镜像和元数据。如果您只是使用 registry 来部署 pod，它会使用一个在 pod 退出时销毁的临时卷。任何用户已构建或推送到 registry 的镜像都会消失。
本节列出了支持的 registry 存储驱动程序。如需更多信息，请参阅容器镜像 registry 文档。
以下列表包括在 registry 配置文件中需要配置的存储驱动程序：
- 文件系统。文件系统是默认设置，不需要进行配置。
- S3.如需更多信息，请参阅 CloudFront 配置 文档。
- OpenStack Swift
- Google Cloud Storage(GCS)
- Microsoft Azure
- Aliyun OSS
支持常规 registry 存储配置选项。如需更多信息，请参阅容器镜像 registry 文档。
以下存储选项需要通过文件系统驱动程序配置：
2.2.6.1. 产品使用
对于生产环境，请附加一个远程卷，或者 定义和使用您选择的持久性存储方法。
例如，使用现有持久性卷声明：
oc set volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \
--claim-name=<pvc_name> --overwrite
$ oc set volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \
--claim-name=<pvc_name> --overwrite测试显示，使用 RHEL NFS 服务器作为容器镜像 registry 的存储后端会出现问题。这包括 OpenShift Container Registry 和 Quay。因此，不建议使用 RHEL NFS 服务器来备份核心服务使用的 PV。
市场上的其他 NFS 实现可能没有这些问题。如需了解更多与此问题相关的信息，请联络相关的 NFS 厂商。
2.2.6.1.1. 使用 Amazon S3 作为存储后端
还有一个选项，可以将 Amazon Simple Storage Service 存储与内部容器镜像 registry 搭配使用。它是一种安全云存储，可通过 AWS 管理控制台进行管理。要使用它，必须手动编辑注册表的配置文件并将其挂载到 registry Pod。但是，在开始配置之前，请查看上游的建议步骤。
采用 默认 YAML 配置文件作为基础，并将 storage 部分中的 filesystem 条目替换为 s3 条目，如下方所示：生成的存储部分可能类似如下：
所有 s3 配置选项都记录在上游 驱动程序参考文档中。
覆盖 registry 配置将引导您完成将配置文件挂载到 pod 的其他步骤。
当 registry 在 S3 存储后端上运行时，会报告问题。
如果要使用您正在使用的集成 registry 不支持的 S3 区域，请参阅 S3 驱动程序配置。
2.2.6.2. 非生产环境中的使用
对于非生产环境，您可以使用 --mount-host=<path> 选项为 registry 指定用于持久性存储的目录。然后，registry 卷在指定的 <path> 上创建为 host-mount。
mount-host 选项可从 registry 容器所在的节点上挂载目录。如果扩展 docker-registry 部署配置，您的 registry Pod 和容器可能会在不同节点上运行，这可能会导致两个或多个 registry 容器，每个容器都有自己的本地存储。这会导致无法预测的行为，因为后续的拉取同一镜像的请求可能并不总是成功，具体取决于请求最终所针对的容器。
--mount-host 选项要求 registry 容器以特权模式运行。这在指定 --mount-host 时自动启用。但是，并非所有 pod 都默认允许运行特权容器。如果您仍然希望使用这个选项，请创建 registry 并指定它使用在安装过程中创建的 registry 服务帐户：
oc adm registry --service-account=registry \
--config=/etc/origin/master/admin.kubeconfig \
--images='registry.redhat.io/openshift3/ose-${component}:${version}' \
--mount-host=<path>
$ oc adm registry --service-account=registry \
--config=/etc/origin/master/admin.kubeconfig \
--images='registry.redhat.io/openshift3/ose-${component}:${version}' \
--mount-host=<path>- 1
- 为 OpenShift Container Platform 拉取正确的镜像是必需的。
${component}和${version}在安装过程中会被动态替换。
容器镜像 registry 容器集以用户 1001 身份运行。此用户必须能够写入主机目录。使用以下命令，您可能需要将目录所有权改为用户 ID 1001 ：
sudo chown 1001:root <path>
$ sudo chown 1001:root <path>2.2.7. 启用 Registry 控制台
OpenShift Container Platform 为集成的 registry 提供了一个基于 Web 的界面。此 registry 控制台是浏览和管理镜像的可选组件。它部署为作为容器集运行的无状态服务。
如果将 OpenShift Container Platform 作为独立 registry 安装，则 registry 控制台在安装过程中会自动部署和保护。
如果 Cockpit 已在运行，您需要先将其关闭，然后才能继续，以避免与 registry 控制台造成端口冲突（默认为 9090）。
2.2.7.1. 部署 Registry 控制台
您必须首先 公开 registry。
在 default 项目中创建一个 passthrough 路由。下一步中创建 registry 控制台应用时，您将需要此设置。
oc create route passthrough --service registry-console \ --port registry-console \ -n default$ oc create route passthrough --service registry-console \ --port registry-console \ -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 部署 registry 控制台应用。将
<openshift_oauth_url>替换为 OpenShift Container Platform OAuth 供应商的 URL，通常是 master。oc new-app -n default --template=registry-console \ -p OPENSHIFT_OAUTH_PROVIDER_URL="https://<openshift_oauth_url>:8443" \ -p REGISTRY_HOST=$(oc get route docker-registry -n default --template='{{ .spec.host }}') \ -p COCKPIT_KUBE_URL=$(oc get route registry-console -n default --template='https://{{ .spec.host }}')$ oc new-app -n default --template=registry-console \ -p OPENSHIFT_OAUTH_PROVIDER_URL="https://<openshift_oauth_url>:8443" \ -p REGISTRY_HOST=$(oc get route docker-registry -n default --template='{{ .spec.host }}') \ -p COCKPIT_KUBE_URL=$(oc get route registry-console -n default --template='https://{{ .spec.host }}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果您试图登录到 registry 控制台时重定向 URL 错误，请使用
oc get oauthclients检查 OAuth 客户端。- 最后，使用 Web 浏览器使用路由 URI 查看控制台。
2.2.7.2. 保护 Registry 控制台
默认情况下，如果按照部署 registry 控制台中的步骤手动部署，registry 控制台会生成自签名 TLS 证书 。如需更多信息，请参阅 对 Registry 控制台进行故障排除。
使用以下步骤将组织的签名证书添加为 secret 卷。假设您的证书在 oc 客户端主机上可用。
创建一个包含证书和密钥的 .cert 文件。使用以下内容格式化文件：
- 服务器证书和中间证书颁发机构的一个或多个 BEGIN CERTIFICATE 块
包含该密钥的 BEGIN PRIVATE KEY 或类似密钥的块。密钥不能加密
例如：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 安全 registry 应包含以下主题备用名称(SAN)列表：
两个服务主机名：
例如：
docker-registry.default.svc.cluster.local docker-registry.default.svc
docker-registry.default.svc.cluster.local docker-registry.default.svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 服务 IP 地址.
例如：
172.30.124.220
172.30.124.220Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令获取容器镜像 registry 服务 IP 地址：
oc get service docker-registry --template='{{.spec.clusterIP}}'oc get service docker-registry --template='{{.spec.clusterIP}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 公共主机名.
例如：
docker-registry-default.apps.example.com
docker-registry-default.apps.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令获取容器镜像 registry 公共主机名：
oc get route docker-registry --template '{{.spec.host}}'oc get route docker-registry --template '{{.spec.host}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，服务器证书应包含类似如下的 SAN 详情：
X509v3 Subject Alternative Name: DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98X509v3 Subject Alternative Name: DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98Copy to Clipboard Copied! Toggle word wrap Toggle overflow registry 控制台从 /etc/cockpit/ws-certs.d 目录中加载证书。它使用最后一个带有 .cert 扩展名的文件（按字母顺序排列）。因此，.cert 文件应至少包含以 OpenSSL 样式格式化的至少两个 PEM 块。
如果没有找到证书，将使用
openssl命令创建自签名证书，并存储在 0-self-signed.cert 文件中。
创建 secret：
oc create secret generic console-secret \ --from-file=/path/to/console.cert$ oc create secret generic console-secret \ --from-file=/path/to/console.certCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 secret 添加到 registry-console 部署配置中：
oc set volume dc/registry-console --add --type=secret \ --secret-name=console-secret -m /etc/cockpit/ws-certs.d$ oc set volume dc/registry-console --add --type=secret \ --secret-name=console-secret -m /etc/cockpit/ws-certs.dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这会触发 registry 控制台的新部署，使其包含您的签名证书。
2.2.7.3. 对 Registry 控制台进行故障排除
2.2.7.3.1. 调试模式
使用环境变量启用 registry 控制台调试模式。以下命令以 debug 模式重新部署 registry 控制台：
oc set env dc registry-console G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper
$ oc set env dc registry-console G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper启用调试模式允许在 registry 控制台的 pod 日志中显示更详细的日志。
2.2.7.3.2. 显示 SSL 证书路径
要检查 registry 控制台正在使用的证书，可以从控制台容器集内运行命令。
列出 default 项目中的 pod，并找到 registry 控制台的 pod 名称：
oc get pods -n default
$ oc get pods -n default NAME READY STATUS RESTARTS AGE registry-console-1-rssrw 1/1 Running 0 1dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用上一命令中的容器集名称，获取 cockpit-ws 进程使用的证书路径。本例演示了使用自动生成的证书的控制台：
oc exec registry-console-1-rssrw remotectl certificate
$ oc exec registry-console-1-rssrw remotectl certificate certificate: /etc/cockpit/ws-certs.d/0-self-signed.certCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. 访问 Registry
2.3.1. 查看日志
要查看容器镜像 registry 的日志，请使用带有部署配置的 oc logs 命令：
2.3.2. 文件存储
标签和镜像元数据存储在 OpenShift Container Platform 中，但 registry 将层和签名数据存储在挂载到位于 /registry 的 registry 容器中的卷中。因为 oc exec 不在特权容器上工作，若要查看 registry 的内容，您必须手动 SSH 到 registry pod 的容器所在的节点，然后在容器本身上运行 docker exec ：
列出当前的 pod 以查找容器镜像 registry 的 pod 名称：
oc get pods
# oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 然后，使用
oc describe来查找运行容器的节点的主机名：oc describe pod <pod_name>
# oc describe pod <pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 登录到所需的节点：
ssh node.example.com
# ssh node.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从节点主机上的默认项目中列出正在运行的容器，并确定容器镜像 registry 的容器 ID：
docker ps --filter=name=registry_docker-registry.*_default_
# docker ps --filter=name=registry_docker-registry.*_default_Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc rsh命令列出 registry 内容：
2.3.3. 直接访问 Registry
对于高级用途，您可以直接访问 registry 来调用 docker 命令。这可让您直接使用 docker push 或 docker pull 等操作从集成的 registry 中推送镜像或从中提取镜像。为此，您必须使用 docker login 命令登录 registry。您可以执行的操作取决于您的用户权限，如以下各节所述。
2.3.3.1. 用户必备条件
要直接访问 registry，您使用的用户必须满足以下条件，具体取决于您的预期用途：
对于任何直接访问，您必须有首选身份提供程序的常规用户。普通用户可以生成登录到 registry 所需的访问令牌。系统用户（如 system:admin ）无法获取访问令牌，因此无法直接访问 registry。
例如，如果您使用
HTPASSWD身份验证，您可以使用以下命令创建一个：htpasswd /etc/origin/master/htpasswd <user_name>
# htpasswd /etc/origin/master/htpasswd <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 若要调取镜像，例如使用
docker pull命令，用户必须具有 registry-viewer 角色。添加此角色：oc policy add-role-to-user registry-viewer <user_name>
$ oc policy add-role-to-user registry-viewer <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为了编写或推送镜像，例如使用
docker push命令，用户必须具有 registry-editor 角色。添加此角色：oc policy add-role-to-user registry-editor <user_name>
$ oc policy add-role-to-user registry-editor <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
如需有关用户权限的更多信息，请参阅管理角色绑定。
2.3.3.2. 登录到 Registry
确保您的用户满足直接访问 registry 的先决条件。
直接登录到 registry：
确保您以 普通用户身份 登录到 OpenShift Container Platform：
oc login
$ oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用您的访问令牌登录到容器镜像registry：
docker login -u openshift -p $(oc whoami -t) <registry_ip>:<port>
docker login -u openshift -p $(oc whoami -t) <registry_ip>:<port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
您可以为用户名传递任何值，令牌包含所有必要的信息。传递包含冒号的用户名将导致登录失败。
2.3.3.3. 推送和拉取镜像
登录 registry 后，您可以对 registry 执行 docker pull 和 docker push 操作。
您可以抓取任意镜像，但是如果已添加了system:registry角色，则只能将镜像推送到您自己的registry中。
在以下示例中，我们使用：
| 组件 | 值 |
| <registry_ip> |
|
| <port> |
|
| <project> |
|
| <image> |
|
| <tag> |
忽略 (默认为 |
抓取任意镜像：
docker pull docker.io/busybox
$ docker pull docker.io/busyboxCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
<registry_ip>:<port>/<project>/<image>格式标记（tag）新镜像。项目名称必须出现在这个 pull 规范中，以供OpenShift Container Platform 把这个镜像正确放置在 registry 中，并在以后正确访问 registry 中的这个镜像：docker tag docker.io/busybox 172.30.124.220:5000/openshift/busybox
$ docker tag docker.io/busybox 172.30.124.220:5000/openshift/busyboxCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您的常规用户必须具有指定项目的 system:image-builder 角色，该角色允许用户写入或推送镜像。否则，下一步中的
docker push将失败。若要进行测试，您可以创建一个新项目来推送 busybox 镜像。将新标记的镜像推送到registry：
docker push 172.30.124.220:5000/openshift/busybox
$ docker push 172.30.124.220:5000/openshift/busybox ... cf2616975b4a: Image successfully pushed Digest: sha256:3662dd821983bc4326bee12caec61367e7fb6f6a3ee547cbaff98f77403cab55Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.4. 访问 Registry 指标
OpenShift Container Registry 为 Prometheus metrics 提供了一个端点。Prometheus是一个独立的开源系统监视和警报工具包。
metrics 可以通过registry端点的/extensions/v2/metrics路径获得。但是，必须先启用此路由；请参阅 Extended Registry Configuration 了解说明。
以下是指标查询的简单示例：
访问指标的另一种方法是使用集群角色。您仍然需要启用端点，但不需要指定 <secret>。配置文件中与指标数据相关的部分应如下所示：
openshift:
version: 1.0
metrics:
enabled: true
...
openshift:
version: 1.0
metrics:
enabled: true
...如果您还没有角色来访问指标，则必须创建一个集群角色：
要将此角色添加到用户，请运行以下命令：
oc adm policy add-cluster-role-to-user prometheus-scraper <username>
$ oc adm policy add-cluster-role-to-user prometheus-scraper <username>有关更高级查询和推荐的可视化工具，请参阅 上游 Prometheus 文档。
2.4. 保护并公开 Registry
2.4.1. 概述
默认情况下，OpenShift Container Platform registry 在集群安装过程中是安全的，以便通过 TLS 提供流量。默认情况下还会创建一个 passthrough 路由，以将服务公开到外部。
如果出于任何原因您的 registry 没有被保护或公开，请参阅以下部分来了解如何手动操作。
2.4.2. 手动保护 Registry
手动保护 registry 以通过 TLS 提供流量：
- 部署 registry。
获取 registry 的服务 IP 和端口：
oc get svc/docker-registry
$ oc get svc/docker-registry NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE docker-registry ClusterIP 172.30.82.152 <none> 5000/TCP 1dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以使用现有服务器证书，或者创建对指定 CA 签名的指定 IP 和主机名有效的密钥和服务器证书。要为 registry 服务 IP 和 docker-registry.default.svc.cluster.local 主机名创建服务器证书，请在 Ansible 主机清单文件中列出的第一个 master 中运行以下命令，默认为 /etc/ansible/hosts ：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果路由器将在 外部公开，请在
--hostnames标志中添加公共路由主机名：--hostnames='mydocker-registry.example.com,docker-registry.default.svc.cluster.local,172.30.124.220 \
--hostnames='mydocker-registry.example.com,docker-registry.default.svc.cluster.local,172.30.124.220 \Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如需有关更新默认证书的更多详细信息，请参阅重新部署 Registry 和路由器 证书，以便可从外部访问该路由。
注意oc adm ca create-server-cert命令会生成一个有效期为两年的证书。这可以通过--expire-days选项进行修改，但出于安全原因，建议不要超过这个值。为 registry 证书创建 secret：
oc create secret generic registry-certificates \ --from-file=/etc/secrets/registry.crt \ --from-file=/etc/secrets/registry.key$ oc create secret generic registry-certificates \ --from-file=/etc/secrets/registry.crt \ --from-file=/etc/secrets/registry.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将该机密添加到 registry 容器集的服务帐户（包括 默认 服务帐户）：
oc secrets link registry registry-certificates oc secrets link default registry-certificates
$ oc secrets link registry registry-certificates $ oc secrets link default registry-certificatesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意默认情况下，“将 secret 仅限于引用它们的服务帐户”的功能被禁用。这意味着，如果在主配置文件中将
serviceAccountConfig.limitSecretReferences设置为false（默认设置），则不需要将 secret 连接到一个特定的服务。暂停
docker-registry服务：oc rollout pause dc/docker-registry
$ oc rollout pause dc/docker-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 secret 卷添加到 registry 部署配置中：
oc set volume dc/docker-registry --add --type=secret \ --secret-name=registry-certificates -m /etc/secrets$ oc set volume dc/docker-registry --add --type=secret \ --secret-name=registry-certificates -m /etc/secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过在 registry 部署配置中添加以下环境变量来启用 TLS：
oc set env dc/docker-registry \ REGISTRY_HTTP_TLS_CERTIFICATE=/etc/secrets/registry.crt \ REGISTRY_HTTP_TLS_KEY=/etc/secrets/registry.key$ oc set env dc/docker-registry \ REGISTRY_HTTP_TLS_CERTIFICATE=/etc/secrets/registry.crt \ REGISTRY_HTTP_TLS_KEY=/etc/secrets/registry.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如需更多信息，请参阅 Docker 文档中的配置 registry 部分。
将 registry 的存活度探测使用从 HTTP 更新到 HTTPS:
oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{$ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{ "name":"registry", "livenessProbe": {"httpGet": {"scheme":"HTTPS"}} }]}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您的 registry 最初部署在 OpenShift Container Platform 3.2 或更高版本上，请将用于 registry 的就绪度探测从 HTTP 更新到 HTTPS:
oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{$ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{ "name":"registry", "readinessProbe": {"httpGet": {"scheme":"HTTPS"}} }]}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 恢复
docker-registry服务：oc rollout resume dc/docker-registry
$ oc rollout resume dc/docker-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证 registry 是否以 TLS 模式运行。等待最新的 docker-registry 部署完成，再验证 registry 容器的 Docker 日志。您应该找到
listening on :5000, tls的条目。oc logs dc/docker-registry | grep tls
$ oc logs dc/docker-registry | grep tls time="2015-05-27T05:05:53Z" level=info msg="listening on :5000, tls" instance.id=deeba528-c478-41f5-b751-dc48e4935fc2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 CA 证书复制到 Docker 证书目录。这必须在集群的所有节点上完成：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ca.crt 文件是 master 上的 /etc/origin/master/ca.crt 的副本。
在使用身份验证时，一些
docker版本还需要将集群配置为信任操作系统级别的证书。复制证书：
cp /etc/origin/master/ca.crt /etc/pki/ca-trust/source/anchors/myregistrydomain.com.crt
$ cp /etc/origin/master/ca.crt /etc/pki/ca-trust/source/anchors/myregistrydomain.com.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行：
update-ca-trust enable
$ update-ca-trust enableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
只删除 /etc/sysconfig/docker 文件中的这个特定 registry 的
--insecure-registry选项。然后，重新载入守护进程并重启 docker 服务来反映这个配置更改：sudo systemctl daemon-reload sudo systemctl restart docker
$ sudo systemctl daemon-reload $ sudo systemctl restart dockerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证
docker客户端连接。运行docker push到 registry 或 registry 中的docker pull应该会成功。确保您已登录到 registry。docker tag|push <registry/image> <internal_registry/project/image>
$ docker tag|push <registry/image> <internal_registry/project/image>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.3. 手动公开安全 Registry
您可以通过首先保护 registry，然后使用路由公开它，而不是从 OpenShift Container Platform 集群内部登录到 OpenShift Container Platform registry。您可以使用路由地址从集群以外登陆到 registry，并使用路由主机进行镜像的 tag 和 push 操作。
以下每个先决条件步骤都会在典型的集群安装过程中默认执行。如果没有，请手动执行它们：
在初始集群安装过程中，默认为 registry 创建 passthrough 路由：
验证路由是否存在：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意也支持重新加密路由来公开安全 registry。
如果不存在，则通过
oc create route passthrough命令创建路由，将 registry 指定为路由的服务。默认情况下，创建的路由的名称与服务名称相同：获取 docker-registry 服务详情：
oc get svc
$ oc get svc NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE docker-registry 172.30.69.167 <none> 5000/TCP docker-registry=default 4h kubernetes 172.30.0.1 <none> 443/TCP,53/UDP,53/TCP <none> 4h router 172.30.172.132 <none> 80/TCP router=router 4hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建路由：
oc create route passthrough \ --service=docker-registry \ --hostname=<host>$ oc create route passthrough \ --service=docker-registry \1 --hostname=<host> route "docker-registry" created2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
接下来，您必须信任主机系统上用于 registry 的证书，以允许主机推送和拉取镜像。引用的证书是在保护 registry 时创建的。
sudo mkdir -p /etc/docker/certs.d/<host> sudo cp <ca_certificate_file> /etc/docker/certs.d/<host> sudo systemctl restart docker
$ sudo mkdir -p /etc/docker/certs.d/<host> $ sudo cp <ca_certificate_file> /etc/docker/certs.d/<host> $ sudo systemctl restart dockerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用保护 registry 的信息，登录到 registry。但是，这一次指向路由中使用的主机名，而不是您的服务 IP。登录到安全且公开的 registry 时，请确保在
docker login命令中指定 registry：docker login -e user@company.com \ -u f83j5h6 \ -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \ <host># docker login -e user@company.com \ -u f83j5h6 \ -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \ <host>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 现在，您可以使用路由主机标记和推送镜像。例如，要在名为
test的项目中标记和推送busybox镜像：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您的镜像流将具有 registry 服务的 IP 地址和端口，而不是路由名称和端口。详情请参阅
oc get imagestreams。
2.4.4. 手动公开 Non-Secure Registry
对于非生产环境的 OpenShift Container Platform，可以公开一个非安全的 registry，而不必通过安全 registry 来公开 registry。这允许您使用一个外部路由到 registry，而无需使用 SSL 证书。
为外部访问非安全的 registry 只适用于非生产环境。
公开一个非安全的 registry：
公开 registry：
oc expose service docker-registry --hostname=<hostname> -n default
# oc expose service docker-registry --hostname=<hostname> -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这会创建以下 JSON 文件：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 验证路由是否已创建成功：
oc get route
# oc get route NAME HOST/PORT PATH SERVICE LABELS INSECURE POLICY TLS TERMINATION docker-registry registry.example.com docker-registry docker-registry=defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查 registry 的健康状况：
curl -v http://registry.example.com/healthz
$ curl -v http://registry.example.com/healthzCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期为 HTTP 200/OK 消息。
公开 registry 后，通过将端口号添加到
OPTIONS条目来更新您的 /etc/sysconfig/docker 文件。例如：OPTIONS='--selinux-enabled --insecure-registry=172.30.0.0/16 --insecure-registry registry.example.com:80'
OPTIONS='--selinux-enabled --insecure-registry=172.30.0.0/16 --insecure-registry registry.example.com:80'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要上面的选项应该添加到您要从其登录的客户端上。
此外，确保 Docker 在客户端上运行。
登录到非安全且公开的 registry 时，请确保在 docker login 命令中指定 registry。例如：
docker login -e user@company.com \
-u f83j5h6 \
-p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \
<host>
# docker login -e user@company.com \
-u f83j5h6 \
-p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \
<host>2.5. 扩展 Registry 配置
2.5.1. 维护 Registry IP 地址
OpenShift Container Platform 使用其服务 IP 地址来引用集成的 registry，因此如果您决定删除并重新创建 docker-registry 服务，您可以通过安排在新服务中重复使用旧 IP 地址来确保完全透明转换。如果无法避免新的 IP 地址，您可以通过只重启 master 来最小化集群中断。
- 重新使用地址
- 要重新使用 IP 地址，您必须在删除旧 docker-registry 服务前保存其 IP 地址，并安排将新分配的 IP 地址替换为新 docker-registry 服务中保存的 IP 地址。
记录该服务的
clusterIP:oc get svc/docker-registry -o yaml | grep clusterIP:
$ oc get svc/docker-registry -o yaml | grep clusterIP:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除服务：
oc delete svc/docker-registry dc/docker-registry
$ oc delete svc/docker-registry dc/docker-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 registry.yaml 中创建 registry 定义，将
<options>替换为非生产环境使用部分中说明的第 3 步中使用的 ：oc adm registry <options> -o yaml > registry.yaml
$ oc adm registry <options> -o yaml > registry.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
编辑 registry.yaml，找到
Service，并将其clusterIP更改为第 1 步中记录的地址。 使用修改后的 registry.yaml 创建 registry：
oc create -f registry.yaml
$ oc create -f registry.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- 重启 Master
- 如果您无法重新使用 IP 地址，则任何使用包含旧 IP 地址的 pull specification 的操作都将失败。要最小化集群中断，您必须重启 master:
master-restart api master-restart controllers
# master-restart api
# master-restart controllers这样可确保从缓存中清除包括旧 IP 地址的旧 registry URL。
我们建议不要重启整个集群，因为这会对 pod 造成不必要的停机时间，实际上不会清除缓存。
2.5.2. 配置外部 registry 搜索列表
您可以使用 /etc/containers/registries.conf 文件创建 Docker Registry 列表来搜索容器镜像。
/etc/containers/registries.conf 文件是 OpenShift Container Platform 在用户使用镜像简短名称（如 myimage:latest ）提取镜像时应对其搜索的 registry 服务器列表。您可以自定义搜索顺序，指定安全且不安全的 registry，并定义一个被阻断的 registry 列表。OpenShift Container Platform 不允许搜索或允许从被阻塞列表中的 registry 中拉取(pull)。
例如，如果用户想要拉取 myimage:latest 镜像，OpenShift Container Platform 会按照它们出现在列表中的顺序搜索 registry，直到找到 myimage:latest 镜像。
registry 搜索列表允许您策展一组可供 OpenShift Container Platform 用户下载的镜像和模板。您可以将这些镜像放在一个或多个 Docker registry 中，将 registry 添加到列表中，并将这些镜像拉取到集群中。
使用 registry 搜索列表时，OpenShift Container Platform 不会从不在搜索列表中的 registry 中拉取镜像。
配置 registry 搜索列表：
2.5.3. 设置 Registry 主机名
您可以为内部和外部引用配置 registry 的主机名和端口。通过这样做，镜像流将为镜像提供基于主机名的推送和拉取规格，允许使用镜像与对 registry 服务 IP 的更改进行隔离，并有可能允许镜像流及其引用在集群中可移植。
要设置从集群内部引用 registry 的主机名，请在 master 配置文件的 imagePolicyConfig 部分中设置 internalRegistryHostname。外部主机名通过在同一位置设置 externalRegistryHostname 值来控制。
镜像策略配置
imagePolicyConfig: internalRegistryHostname: docker-registry.default.svc.cluster.local:5000 externalRegistryHostname: docker-registry.mycompany.com
imagePolicyConfig:
internalRegistryHostname: docker-registry.default.svc.cluster.local:5000
externalRegistryHostname: docker-registry.mycompany.com
registry 本身必须使用相同的内部主机名值进行配置。这可以通过在 registry 署配置中设置 REGISTRY_OPENSHIFT_SERVER_ADDR 环境变量或设置 registry 配置的 OpenShift 部分中的值来完成。
如果您已经为 registry 启用了 TLS，服务器证书必须包含您希望引用 registry 的主机名。有关添加主机名到服务器证书的说明，请参阅保护registry。
2.5.4. 覆盖 Registry 配置
您可以使用自己的自定义配置覆盖集成 registry 的默认配置，默认覆盖正在运行的 registry 容器中的 /config.yml 中的默认配置。
此文件中的上游配置选项也可使用环境变量覆盖。middleware 部分是一个例外，因为只有几个选项可以使用环境变量覆盖。了解如何覆盖特定的配置选项。
要启用对 registry 配置文件的管理，并使用 ConfigMap 部署更新的配置：
- 部署 registry。
根据需要在本地编辑 registry 配置文件。registry 中部署的初始 YAML 文件如下所示：查看支持的选项。
registry 配置文件
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个
ConfigMap，包含此目录中每个文件的内容：oc create configmap registry-config \ --from-file=</path/to/custom/registry/config.yml>/$ oc create configmap registry-config \ --from-file=</path/to/custom/registry/config.yml>/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 registry-config ConfigMap 作为卷添加到 registry 的部署配置中，以在 /etc/docker/registry/ 中挂载自定义配置文件：
oc set volume dc/docker-registry --add --type=configmap \ --configmap-name=registry-config -m /etc/docker/registry/$ oc set volume dc/docker-registry --add --type=configmap \ --configmap-name=registry-config -m /etc/docker/registry/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过在 registry 的部署配置中添加以下环境变量来更新 registry，以引用上一步中的配置路径：
oc set env dc/docker-registry \ REGISTRY_CONFIGURATION_PATH=/etc/docker/registry/config.yml$ oc set env dc/docker-registry \ REGISTRY_CONFIGURATION_PATH=/etc/docker/registry/config.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
这可以作为迭代过程执行，从而实现所需的配置。例如，在故障排除期间，可临时更新配置以将其置于 debug 模式。
更新现有配置：
此流程将覆盖当前部署的 registry 配置。
- 编辑本地 registry 配置文件 config.yml。
删除 registry-config configmap：
oc delete configmap registry-config
$ oc delete configmap registry-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重新创建 configmap 以引用更新的配置文件：
oc create configmap registry-config\ --from-file=</path/to/custom/registry/config.yml>/$ oc create configmap registry-config\ --from-file=</path/to/custom/registry/config.yml>/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重新部署 registry 以读取更新的配置：
oc rollout latest docker-registry
$ oc rollout latest docker-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow
在源代码控制存储库中维护配置文件。
2.5.5. registry 配置参考
上游 docker distribution 库中有许多配置选项。并非所有配置选项都受到支持或启用。覆盖 registry 配置时，请使用本节作为参考。
此文件中的上游配置选项也可使用环境变量覆盖。但是，middleware 部分可能无法使用环境变量覆盖。了解如何覆盖特定的配置选项。
2.5.5.1. Log
例如：
2.5.5.2. Hook
不支持邮件 hook。
2.5.5.3. 存储
本节列出了支持的 registry 存储驱动程序。如需更多信息，请参阅容器镜像 registry 文档。
以下列表包括在 registry 配置文件中需要配置的存储驱动程序：
- 文件系统。文件系统是默认设置，不需要进行配置。
- S3.如需更多信息，请参阅 CloudFront 配置 文档。
- OpenStack Swift
- Google Cloud Storage(GCS)
- Microsoft Azure
- Aliyun OSS
支持常规 registry 存储配置选项。如需更多信息，请参阅容器镜像 registry 文档。
以下存储选项需要通过文件系统驱动程序配置：
常规存储配置选项
- 1
- 此条目对于镜像修剪正常工作是必需的。
2.5.5.4. Auth
不应更改 Auth 选项。openshift 扩展是唯一支持的选项。
auth:
openshift:
realm: openshift
auth:
openshift:
realm: openshift2.5.5.5. Middleware
存储库 中间件扩展允许配置负责与 OpenShift Container Platform 和镜像代理交互的 OpenShift Container Platform 中间件。
- 1 2 9
- 这些条目是必需的。其存在可确保加载所需的组件。这些值不应更改。
- 3
- 4
- 允许 registry 充当远程 Blob 的代理。详情请查看 下方。
- 5
- 允许从远程 registry 提供 registry 缓存 Blob，以便稍后进行快速访问。镜像在第一次访问 Blob 时开始。如果禁用了 pullthrough，则选项无效。
- 6
- 防止 Blob 上传超过目标项目中定义的大小限制。
- 7
- 在 registry 中缓存的限制的过期超时。值越低，限制更改传播到 registry 所需的时间就会越短。但是，registry 会更频繁地从服务器查询限制，因此推送速度会较慢。
- 8
- blob 和 repository 之间记住关联的过期超时。值越大，快速查找的几率更高，registry 操作效率越高。另一方面，内存使用会增加为用户提供服务的风险，因为用户不再获得访问该层的权限。
2.5.5.5.1. S3 驱动程序配置
如果要使用您正在使用的集成 registry 不支持的 S3 区域，您可以指定一个 regionendpoint 以避免 区域 验证错误。
有关使用 Amazon Simple Storage Service 存储的更多信息，请参阅 Amazon S3 作为存储后端。
例如：
验证 region 和 regionendpoint 字段本身是否一致。否则，集成的 registry 将启动，但它无法读取或写入 S3 存储。
如果您使用与 Amazon S3 不同的 S3 存储，则 regionendpoint 也很有用。
2.5.5.5.2. CloudFront 中间件
可以添加 CloudFront 中间件扩展 以支持 AWS CloudFront CDN 存储供应商。CloudFront 中间件加快了镜像内容在国际间分发。Blob 分布到世界各地的几个边缘位置。客户端始终定向到延迟最低的边缘。
CloudFront 中间件扩展 只能用于 S3 存储。它仅在 Blob 服务期间使用。因此，只有 Blob 下载可以加快，不能上传。
以下是带有 CloudFront 中间件的 S3 存储驱动程序的最小配置示例：
2.5.5.5.3. 覆盖中间件配置选项
middleware 部分无法使用环境变量覆盖。但也有一些例外：例如：
- 1
- 此配置选项可以被布尔值环境变量
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ACCEPTSCHEMA2覆盖，允许在清单放置请求时接受清单架构 v2。可识别的值为true和false（适用于以下所有其他布尔值变量）。 - 2
- 此配置选项可以被布尔值环境变量
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_PULLTHROUGH覆盖，启用远程存储库的代理模式。 - 3
- 此配置选项可以被布尔值环境变量
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_MIRRORPULLTHROUGH覆盖，它指示 registry 在提供远程 Blob 时在本地镜像 Blob。 - 4
- 此配置选项可以被布尔值环境变量
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA覆盖，允许开启或关闭配额执行。默认情况下，配额强制是禁用的。 - 5
- 可被环境变量
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_PROJECTCACHETTL覆盖的配置选项，为项目配额对象指定驱除超时。它需要一个有效的持续时间字符串（如2m）。如果为空，则获得默认超时。如果零(0m)，则禁用缓存。 - 6
- 可被环境变量
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_BLOBREPOSITORYCACHETTL覆盖的配置选项，为 blob 和包含存储库之间的关联指定驱除超时。值的格式与projectcachettl示例中的格式相同。
2.5.5.5.4. 镜像 Pullthrough
如果启用，registry 将尝试从远程 registry 获取请求的 blob，除非 blob 在本地存在。远程候选从存储在 镜像流 状态的 DockerImage 条目（客户端从中拉取）计算。此类条目中的所有唯一远程 registry 引用将依次尝试，直到找到 Blob。
只有存在拉取镜像的镜像流标签时才会进行 pullthrough。例如，如果拉取的镜像为 docker-registry.default.svc:5000/yourproject/yourimage:prod，则 registry 将在项目 yourproject 中查找名为 yourimage:prod 的镜像流标签。如果找到镜像，它将尝试使用该镜像流标签关联的 dockerImageReference 来拉取镜像。
在执行 pullthrough 时，registry 将使用与所引用镜像流标签关联的项目中找到的拉取凭据。此功能还允许您拉取驻留在 registry 上的镜像，它们没有凭证可以访问，只要您有权访问引用该镜像的镜像流标签。
您必须确保 registry 具有适当的证书来信任您针对的任何外部 registry。证书需要放置在 pod 上的 /etc/pki/tls/certs 目录中。您可以使用 配置映射 或 secret 挂载证书。请注意，必须替换整个 /etc/pki/tls/certs 目录。您必须包含新证书，并在您挂载的 secret 或配置映射中替换系统证书。
请注意，默认情况下，镜像流标签使用引用策略类型 Source，这意味着镜像流引用被解析为镜像拉取规格时，使用的规格将指向镜像的来源。对于托管在外部 registry 上的镜像，这将是外部 registry，因此该资源将引用外部 registry 并拉取镜像。例如，registry.redhat.io/openshift3/jenkins-2-rhel7 和 pullthrough 将不适用。为确保引用镜像流的资源使用指向内部 Registry 的拉取规格，镜像流标签应使用引用策略类型 Local。有关参考政策的更多信息，
这个功能默认是开启的。不过，它可以通过配置选项来禁用。
默认情况下，除非禁用 mirrorpullthrough，否则通过这种方式提供的所有远程 Blob 都存储在本地以进行后续的快速访问。此镜像功能的缺点是增加存储的使用。
当客户端尝试至少获取一个 blob 字节时，镜像开始。要在实际需要前将特定镜像预先放入集成的 registry 中，您可以运行以下命令：
oc get imagestreamtag/${IS}:${TAG} -o jsonpath='{ .image.dockerImageLayers[*].name }' | \
xargs -n1 -I {} curl -H "Range: bytes=0-1" -u user:${TOKEN} \
http://${REGISTRY_IP}:${PORT}/v2/default/mysql/blobs/{}
$ oc get imagestreamtag/${IS}:${TAG} -o jsonpath='{ .image.dockerImageLayers[*].name }' | \
xargs -n1 -I {} curl -H "Range: bytes=0-1" -u user:${TOKEN} \
http://${REGISTRY_IP}:${PORT}/v2/default/mysql/blobs/{}此 OpenShift Container Platform 镜像功能不应与上游 registry 通过缓存功能拉取(pull) 混淆，后者是类似但不同的功能。
2.5.5.5.5. 清单架构 v2 支持
每一镜像具有一个清单，用于描述其 Blob、运行它的说明以及其他元数据。清单是经过版本控制的，每个版本具有不同的结构和字段，随着时间推移而发展。同一镜像可由多个清单版本表示。每个版本都有不同的摘要。
registry 目前支持 清单 v2 模式 1 (schema1)和 清单 v2 模式 2 （架构2）。前者已被淘汰，但将会延长支持时间。
默认配置是存储 schema2。
您应注意与各种 Docker 客户端的兼容性问题：
- 1.9 或更早版本的 Docker 客户端仅支持 schema1。此客户端拉取或推送的任何清单都将是这种传统架构。
- 版本 1.10 的 Docker 客户端支持 schema1 和 schema2。默认情况下，如果支持较新的架构，它会将后者推送到 registry。
存储具有 schema1 的镜像的 registry 将始终不动地将其返回到客户端。Schema2 将仅原封不动传输到较新的 Docker 客户端。对于较旧版本，它将自行转换为 schema1。
这具有显著的后果。例如，通过较新的 Docker 客户端推送到 registry 的镜像无法被旧 Docker 通过其摘要拉取。这是因为存储的镜像的清单是 schema2，其摘要只能用于拉取此版本的清单。
旦您确信所有 registry 客户端都支持 schema2，就可以在 registry 中启用其支持。有关特定选项，请参见上述中间件配置参考。
2.5.5.6. OpenShift
本节回顾针对特定于 OpenShift Container Platform 的功能的全局设置配置。在以后的发行版本中，Middleware 部分中与 openshift相关的设置将被弃用。
目前，本节允许您配置 registry 指标集合：
- 1
- 指定本节配置版本的必填条目。唯一支持的值是
1.0。 - 2
- registry 的主机名。应设置为 master 上配置的相同值。它可以被环境变量
REGISTRY_OPENSHIFT_SERVER_ADDR覆盖。 - 3
- 可以设置为
true来启用指标集合。它可以被布尔值环境变量REGISTRY_OPENSHIFT_METRICS_ENABLED覆盖。 - 4
- 用于授权客户端请求的机密。指标客户端必须在
Authorization标头中将它用作 bearer 令牌。它可以被环境变量REGISTRY_OPENSHIFT_METRICS_SECRET覆盖。 - 5
- 同时拉取请求的最大数量。它可以被环境变量
REGISTRY_OPENSHIFT_REQUESTS_READ_MAXRUNNING覆盖。零表示无限制。 - 6
- 已排队拉取请求的最大数量。它可以被环境变量
REGISTRY_OPENSHIFT_REQUESTS_READ_MAXINQUEUE覆盖。零表示无限制。 - 7
- 拉取请求在被拒绝前可在队列中等待的最长时间。它可以被环境变量
REGISTRY_OPENSHIFT_REQUESTS_READ_MAXWAITINQUEUE覆盖。零表示无限制。 - 8
- 同时推送请求的最大数量。它可以被环境变量
REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXRUNNING覆盖。零表示无限制。 - 9
- 最多排队的推送请求数.它可以被环境变量
REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXINQUEUE覆盖。零表示无限制。 - 10
- 推送请求在被拒绝前可在队列中等待的最长时间。它可以被环境变量
REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXWAITINQUEUE覆盖。零表示无限制。
有关使用信息，请参阅访问 Registry Metrics。
2.5.5.7. 报告
报告不受支持。
2.5.5.8. HTTP
支持上游选项。了解如何通过环境变量更改这些设置。应当仅更改 tls 部分。例如：
http:
addr: :5000
tls:
certificate: /etc/secrets/registry.crt
key: /etc/secrets/registry.key
http:
addr: :5000
tls:
certificate: /etc/secrets/registry.crt
key: /etc/secrets/registry.key2.5.5.9. 通知
支持上游选项。REST API 参考 提供了更加全面的集成选项。
例如：
2.5.5.10. Redis
不支持 Redis。
2.5.5.11. Health
支持上游选项。registry 部署配置在 /healthz 上提供了一个集成健康检查。
2.5.5.12. Proxy
不应启用代理配置。此功能由 OpenShift Container Platform 存储库中间件扩展 pullthrough: true 提供。
2.5.5.13. Cache
集成 registry 会主动缓存数据，以减少对减慢外部资源的调用数量。有两个缓存：
- 用于缓存 Blob 元数据的存储缓存。此缓存没有过期时间，数据会一直存在，直到显式删除为止。
- 应用缓存包含 blob 和存储库之间的关联。此缓存中的数据具有过期时间。
要完全关闭缓存，您需要更改配置：
2.6. 已知问题
2.6.1. 概述
以下是部署或使用集成 registry 时已知的问题。
2.6.2. 使用 Registry Pull-through 的并发构建
本地 docker-registry 部署会增加负载。默认情况下，它现在缓存 registry.redhat.io 的内容。来自为 STI 构建的 registry.redhat.io 的镜像现在存储在本地 registry 中。尝试拉取它们的结果从本地 docker-registry 中拉取。因此，在有些情况下，并发构建可能会造成拉取超时，构建可能会失败。要缓解此问题，请将 docker-registry 部署扩展到多个副本。检查构建器容器集日志中的超时。
2.6.3. 使用共享 NFS 卷扩展 registry 的镜像推送错误
当将扩展的 registry 与共享 NFS 卷搭配使用时，您可能会在推送镜像的过程中看到以下错误之一：
-
digest invalid: provided digest did not match uploaded content -
blob upload unknown -
blob upload invalid
当 Docker 尝试推送镜像时，内部 registry 服务将返回这些错误。其原因源自于跨节点的文件属性同步。使用默认循环负载平衡配置推送镜像时可能会出现的错误，如 NFS 客户端缓存、网络延迟和层大小等因素。
您可以执行以下步骤来最大程度减少此类故障的可能性：
确保 docker-registry 服务的
sessionAffinity设置为ClientIP:oc get svc/docker-registry --template='{{.spec.sessionAffinity}}'$ oc get svc/docker-registry --template='{{.spec.sessionAffinity}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这应该会返回
ClientIP，这是 OpenShift Container Platform 近期版本中的默认设置。如果没有，请修改它：oc patch svc/docker-registry -p '{"spec":{"sessionAffinity": "ClientIP"}}'$ oc patch svc/docker-registry -p '{"spec":{"sessionAffinity": "ClientIP"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
确保 NFS 服务器上的 registry 卷的 NFS 导出行列出
no_wdelay选项。no_wdelay选项可防止服务器延迟写入，这极大提高了读写一致性，这是 Registry 的一项要求。
测试显示，使用 RHEL NFS 服务器作为容器镜像 registry 的存储后端会出现问题。这包括 OpenShift Container Registry 和 Quay。因此，不建议使用 RHEL NFS 服务器来备份核心服务使用的 PV。
市场上的其他 NFS 实现可能没有这些问题。如需了解更多与此问题相关的信息，请联络相关的 NFS 厂商。
2.6.4. 使用 "not found" 错误来拉取内部管理的镜像故障
当拉取镜像推送到不同于从中拉取的镜像流时，会发生此错误。这是因为将构建的镜像重新标记到任意镜像流中：
oc tag srcimagestream:latest anyproject/pullimagestream:latest
$ oc tag srcimagestream:latest anyproject/pullimagestream:latest然后，使用如下镜像引用从中提取：
internal.registry.url:5000/anyproject/pullimagestream:latest
internal.registry.url:5000/anyproject/pullimagestream:latest在手动 Docker 拉取过程中，这会导致类似的错误：
Error: image anyproject/pullimagestream:latest not found
Error: image anyproject/pullimagestream:latest not found为防止这种情况，请完全避免标记内部管理的镜像，或者 手动 将构建的镜像重新推送到所需的命名空间。
当 registry 在 S3 存储后端上运行时，会报告问题。推送到容器镜像 registry 有时会失败，并显示以下错误：
Received unexpected HTTP status: 500 Internal Server Error
Received unexpected HTTP status: 500 Internal Server Error要进行调试，您需要 查看 registry 日志。在这里，查看推送失败时出现的类似的错误消息：
如果您看到此类错误，请联系您的 Amazon S3 支持。您所在地区或您的特定存储桶可能有问题。
2.6.6. 镜像修剪失败
如果您在修剪镜像时遇到以下错误：
BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blob
BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blob您的 registry 日志 包含以下信息：
error deleting blob \"sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c\": operation unsupported
error deleting blob \"sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c\": operation unsupported
这意味着您的 自定义配置文件 缺少 storage 部分中的强制条目，即 storage:delete:enabled 设置为 true。添加它们，重新部署 registry，再重复您的镜像修剪操作。
第 3 章 设置路由器
3.1. 路由器概述
3.1.1. 关于路由器
可以通过多种方式使 流量进入集群。最常见的方法是使用 OpenShift Container Platform router 作为 OpenShift Container Platform 安装中 services 的外部流量入口点。
OpenShift Container Platform 提供和支持以下路由器插件：
- HAProxy 模板路由器是默认的插件。它使用 openshift3/ose-haproxy-router 镜像和 OpenShift Container Platform 上的容器内的模板路由器插件运行 HAProxy 实例。它目前支持通过 SNI 的 HTTP(S)流量和启用 TLS 的流量。路由器的容器侦听主机网络接口，这与大多数仅侦听私有 IP 的容器不同。路由器将路由名称的外部请求代理到与路由关联的服务标识的实际 pod 的 IP。
- F5 路由器 可与您环境中的现有 F5 BIG-IP® 系统集成，以同步路由。需要 F5 BIG-IP® 版本 11.4 或更高版本才能使用 F5 iControl REST API。
- 部署默认 HAProxy 路由器
- 部署自定义 HAProxy 路由器
- 将 HAProxy 路由器配置为使用 PROXY 协议
- 配置路由超时
3.1.2. 路由器服务帐户
在部署 OpenShift Container Platform 集群前，您必须有一个路由器的服务帐户，该帐户会在集群安装过程中自动创建。此服务帐户具有 安全性上下文约束 (SCC)的权限，允许它指定主机端口。
3.1.2.1. 访问标签的权限
使用 命名空间标签 时，例如在创建 路由器分片 时，路由器的服务帐户必须具有 cluster-reader 权限。
oc adm policy add-cluster-role-to-user \
cluster-reader \
system:serviceaccount:default:router
$ oc adm policy add-cluster-role-to-user \
cluster-reader \
system:serviceaccount:default:router服务帐户就位后，您可以继续安装默认的 HAProxy 路由器或自定义 HAProxy 路由器
3.2. 使用默认 HAProxy 路由器
3.2.1. 概述
oc adm router 命令随管理员 CLI 一同提供，以简化在新安装中设置路由器的任务。oc adm router 命令创建服务和部署配置对象。使用 --service-account 选项指定路由器用于联系主控机的服务帐户。
路由器服务帐户 可以提前创建，或者通过 oc adm router --service-account 命令创建。
OpenShift Container Platform 组件之间的每种通信都受到 TLS 的保护，并使用各种证书和身份验证方法。可以提供 --default-certificate .pem 格式文件，或者由 oc adm router 命令创建文件。创建路由时，用户可以提供路由器在处理路由时使用的路由证书。
删除路由器时，请确保也删除了部署配置、服务和机密。
路由器部署到特定的节点上。这使得集群管理员和外部网络管理器能够更轻松地协调哪个 IP 地址将运行路由器以及路由器将处理的流量。路由器通过使用 节点选择器 部署到特定的节点上。
使用 oc adm router 创建的路由器 pod 具有默认的资源请求，节点必须满足这些请求才能部署路由器 pod。为提高基础架构组件的可靠性，默认资源请求用于在不使用资源请求的情况下增加 pod 以上的路由器容器集的 QoS 层。默认值表示部署基本路由器所需的已观察到最少资源，可以在路由器部署配置中编辑，并且您可能希望根据路由器负载来增加这些资源。
3.2.2. 创建路由器
如果路由器不存在，请运行以下命令来创建路由器：
oc adm router <router_name> --replicas=<number> --service-account=router --extended-logging=true
$ oc adm router <router_name> --replicas=<number> --service-account=router --extended-logging=true
除非创建 高可用性 配置，否则 --replicas 通常为 1。
--extended-logging=true 配置路由器，将 HAProxy 生成的日志转发到 syslog 容器。
查找路由器的主机 IP 地址：
oc get po <router-pod> --template={{.status.hostIP}}
$ oc get po <router-pod> --template={{.status.hostIP}}您还可以使用路由器分片来确保路由器被过滤到特定的命名空间或路由，或者在路由器创建后设置任何环境变量。本例中为每个分片创建一个路由器。
3.2.3. 其他基本路由器命令
- 检查默认路由器
- 名为 router 的默认路由器服务帐户会在集群安装过程中自动创建。验证此帐户是否已存在：
oc adm router --dry-run --service-account=router
$ oc adm router --dry-run --service-account=router- 查看默认路由器
- 查看创建的默认路由器会是什么样子：
oc adm router --dry-run -o yaml --service-account=router
$ oc adm router --dry-run -o yaml --service-account=router- 将路由器配置为转发 HAProxy 日志
-
您可以将路由器配置为将 HAProxy 生成的日志转发到 rsyslog sidecar 容器。
--extended-logging=true参数附加 syslog 容器将 HAProxy 日志转发到标准输出。
oc adm router --extended-logging=true
$ oc adm router --extended-logging=true
以下示例是使用 --extended-logging=true 的路由器的配置：
使用以下命令查看 HAProxy 日志：
oc set env dc/test-router ROUTER_LOG_LEVEL=info oc logs -f <pod-name> -c syslog
$ oc set env dc/test-router ROUTER_LOG_LEVEL=info
$ oc logs -f <pod-name> -c syslog HAProxy 日志的格式如下：
2020-04-14T03:05:36.629527+00:00 test-311-node-1 haproxy[43]: 10.0.151.166:59594 [14/Apr/2020:03:05:36.627] fe_no_sni~ be_secure:openshift-console:console/pod:console-b475748cb-t6qkq:console:10.128.0.5:8443 0/0/1/1/2 200 393 - - --NI 2/1/0/1/0 0/0 "HEAD / HTTP/1.1" 2020-04-14T03:05:36.633024+00:00 test-311-node-1 haproxy[43]: 10.0.151.166:59594 [14/Apr/2020:03:05:36.528] public_ssl be_no_sni/fe_no_sni 95/1/104 2793 -- 1/1/0/0/0 0/0
2020-04-14T03:05:36.629527+00:00 test-311-node-1 haproxy[43]: 10.0.151.166:59594 [14/Apr/2020:03:05:36.627] fe_no_sni~ be_secure:openshift-console:console/pod:console-b475748cb-t6qkq:console:10.128.0.5:8443 0/0/1/1/2 200 393 - - --NI 2/1/0/1/0 0/0 "HEAD / HTTP/1.1"
2020-04-14T03:05:36.633024+00:00 test-311-node-1 haproxy[43]: 10.0.151.166:59594 [14/Apr/2020:03:05:36.528] public_ssl be_no_sni/fe_no_sni 95/1/104 2793 -- 1/1/0/0/0 0/0- 将路由器部署到标记的节点
- 将路由器部署到与指定 节点标签 匹配的任何节点上：
oc adm router <router_name> --replicas=<number> --selector=<label> \
--service-account=router
$ oc adm router <router_name> --replicas=<number> --selector=<label> \
--service-account=router
例如，如果要创建一个名为 router 的路由器，并将其放置到带有 node-role.kubernetes.io/infra=true 标签的节点上：
oc adm router router --replicas=1 --selector='node-role.kubernetes.io/infra=true' \ --service-account=router
$ oc adm router router --replicas=1 --selector='node-role.kubernetes.io/infra=true' \
--service-account=router
在集群安装过程中，openshift_router_selector 和 openshift_registry_selector Ansible 设置默认设置为 node-role.kubernetes.io/infra=true。只有在存在与 node-role.kubernetes.io/infra=true 标签匹配的节点时，才会自动部署默认路由器和 registry。
有关更新标签的详情，请参阅更新节点上的标签。
根据调度程序策略，在不同的主机上创建多个实例。
- 使用不同的路由器镜像
- 使用其他路由器镜像并查看要使用的路由器配置：
oc adm router <router_name> -o <format> --images=<image> \
--service-account=router
$ oc adm router <router_name> -o <format> --images=<image> \
--service-account=router例如：
oc adm router region-west -o yaml --images=myrepo/somerouter:mytag \
--service-account=router
$ oc adm router region-west -o yaml --images=myrepo/somerouter:mytag \
--service-account=router3.2.4. 过滤到特定路由器的路由
使用 ROUTE_LABELS 环境变量，您可以过滤路由，使其仅供特定路由器使用。
例如，如果您有多个路由器和 100 个路由，您可以将标签附加到路由，以便一部分标签由一个路由器处理，而其余则由另一个路由器处理。
创建路由器 后，使用
ROUTE_LABELS环境变量标记路由器：oc set env dc/<router=name> ROUTE_LABELS="key=value"
$ oc set env dc/<router=name> ROUTE_LABELS="key=value"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将标签添加到所需路由中：
oc label route <route=name> key=value
oc label route <route=name> key=valueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证标签是否已附加到路由，请检查路由配置：
oc describe route/<route_name>
$ oc describe route/<route_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 设置最大并发连接数
-
默认情况下，路由器可以处理最多 20000 连接。您可以根据需要更改该限制。由于连接太少，健康检查无法正常工作，从而导致不必要的重启。您需要配置系统，以支持最大连接数。
'sysctl fs.nr_open'和'sysctl fs.file-max'中显示的限值必须足够大。否则，HAproxy 将不会启动。
创建路由器时，--max-connections= 选项会设置所需的限制：
oc adm router --max-connections=10000 ....
$ oc adm router --max-connections=10000 ....
编辑路由器部署配置中的 ROUTER_MAX_CONNECTIONS 环境变量，以更改值。路由器容器集使用新值重启。如果 ROUTER_MAX_CONNECTIONS 不存在，则使用默认值 20000。
连接包括 frontend 和 internal 后端。这表示两个连接。务必将 ROUTER_MAX_CONNECTIONS 设置为两倍，超过您要创建的连接数。
3.2.5. HAProxy Strict SNI
HAProxy strict-sni 可以通过路由器部署配置中的 ROUTER_STRICT_SNI 环境变量来控制。也可以使用 --strict-sni 命令行选项创建路由器时设置它。
oc adm router --strict-sni
$ oc adm router --strict-sni3.2.6. TLS 密码套件
在创建路由器时使用 --ciphers 选项设置路由器密码套件 ：
oc adm router --ciphers=modern ....
$ oc adm router --ciphers=modern ....
值包括：modern, intermediate, 或 old，intermediate 为默认值。或者，可以提供一组":"分隔的密码。密码必须来自以下集合：
openssl ciphers
$ openssl ciphers
或者，将 ROUTER_CIPHERS 环境变量用于现有路由器。
3.2.7. 双向 TLS 身份验证
可以使用 mutual TLS 身份验证限制对路由器和后端服务的客户端访问。路由器将拒绝来自不在 通过身份验证 的集合中的客户端的请求。双向 TLS 身份验证是在客户端证书上实施的，可以根据签发证书的证书颁发机构(CA)控制，证书撤销列表和/或任何证书主题过滤器。在创建路由器时，使用 mutual tls 配置选项 --mutual-tls-auth, --mutual-tls-auth-ca, --mutual-tls-auth-crl 和 --mutual-tls-auth-filter：
oc adm router --mutual-tls-auth=required \
--mutual-tls-auth-ca=/local/path/to/cacerts.pem ....
$ oc adm router --mutual-tls-auth=required \
--mutual-tls-auth-ca=/local/path/to/cacerts.pem ....
--mutual-tls-auth 的值是 required, optional, 或 none，none 是默认值。--mutual-tls-auth-ca 值指定包含一个或多个 CA 证书的文件。路由器使用这些 CA 证书来验证客户端的证书。
可以使用 --mutual-tls-auth-crl 指定证书撤销列表，以处理证书（由有效认证机构签发）被撤销的情况。
oc adm router --mutual-tls-auth=required \
--mutual-tls-auth-ca=/local/path/to/cacerts.pem \
--mutual-tls-auth-filter='^/CN=my.org/ST=CA/C=US/O=Security/OU=OSE$' \
....
$ oc adm router --mutual-tls-auth=required \
--mutual-tls-auth-ca=/local/path/to/cacerts.pem \
--mutual-tls-auth-filter='^/CN=my.org/ST=CA/C=US/O=Security/OU=OSE$' \
....
--mutual-tls-auth-filter 值可用于根据证书主题进行精细的访问控制。该值是一个正则表达式，用于匹配证书的主题。
上面的 mutual TLS 身份验证过滤器显示了一个限制性正则表达式(regex)，包括在 ^ 和 $ 之间，这会完全准确匹配证书的主题。如果您决定使用限制较小的正则表达式，请注意这可能与您认为有效的任何 CA 颁发的证书匹配。建议您使用 --mutual-tls-auth-ca 选项，以便您更精细地控制发布的证书。
使用 --mutual-tls-auth=required 可确保您只允许经过身份验证的客户端访问后端资源。这意味着始终 需要 客户端来提供身份验证信息（提供一个客户端证书）。要使 mutual TLS 身份验证可选，请使用 --mutual-tls-auth=optional （或使用 none 禁用它，这是默认设置）。请注意，optional 意味着您 不需要 客户端提供任何身份验证信息，如果客户端提供任何身份验证信息，这会在 X-SSL* HTTP 标头中传递给后端。
oc adm router --mutual-tls-auth=optional \
--mutual-tls-auth-ca=/local/path/to/cacerts.pem \
....
$ oc adm router --mutual-tls-auth=optional \
--mutual-tls-auth-ca=/local/path/to/cacerts.pem \
....
启用 mutual TLS 身份验证支持时（使用 --mutual-tls-auth 标志的 required 值或 optional 值），客户端身份验证信息将以 X-SSL* HTTP 标头的形式传递给后端。
X-SSL* HTTP 标头 X-SSL-Client-DN 示例：证书主题的完整可分辨名称(DN)。X-SSL-Client-NotBefore ：客户端证书启动日期为 YYMMDDhhmmss[Z] 格式。X-SSL-Client-NotAfter ：客户端证书结束日期，采用 YYMMDDhhmmss[Z] 格式。X-SSL-Client-SHA1 ：客户端证书的 SHA-1 指纹。X-SSL-Client-DER ：提供客户端证书的完整访问权限。包含以 base-64 格式编码的 DER 格式的客户端证书。
3.2.8. 高可用路由器
您可以使用 IP 故障切换在 OpenShift Container Platform 集群中设置高可用性路由器。此设置在不同节点上有多个副本，因此如果当前副本失败，故障切换软件可以切换到另一个副本。
3.2.9. 自定义路由器服务端口
您可以通过设置环境变量 ROUTER_SERVICE_HTTP_PORT 和 ROUTER_SERVICE_HTTPS_PORT 来自定义模板路由器绑定的服务端口。这可以通过创建模板路由器，然后编辑其部署配置来完成。
以下示例创建带有 0 个副本的路由器部署，并自定义路由器服务 HTTP 和 HTTPS 端口，然后相应地将其扩展（到 1 个副本）。
oc adm router --replicas=0 --ports='10080:10080,10443:10443'
oc set env dc/router ROUTER_SERVICE_HTTP_PORT=10080 \
ROUTER_SERVICE_HTTPS_PORT=10443
oc scale dc/router --replicas=1
$ oc adm router --replicas=0 --ports='10080:10080,10443:10443'
$ oc set env dc/router ROUTER_SERVICE_HTTP_PORT=10080 \
ROUTER_SERVICE_HTTPS_PORT=10443
$ oc scale dc/router --replicas=1- 1
- 确保为使用容器网络模式
--host-network=false的路由器正确设置公开端口。
如果您确实自定义模板路由器服务端口，您还需要确保运行路由器 Pod 的节点在防火墙中打开这些自定义端口（通过 Ansible 或 iptables，或通过 firewall-cmd使用的任何其他自定义方式）。
以下是使用 iptables 打开自定义路由器服务端口的示例：
iptables -A OS_FIREWALL_ALLOW -p tcp --dport 10080 -j ACCEPT iptables -A OS_FIREWALL_ALLOW -p tcp --dport 10443 -j ACCEPT
$ iptables -A OS_FIREWALL_ALLOW -p tcp --dport 10080 -j ACCEPT
$ iptables -A OS_FIREWALL_ALLOW -p tcp --dport 10443 -j ACCEPT3.2.10. 使用多个路由器
管理员可以创建具有相同定义的多个路由器，为同一组路由提供服务。每个路由器将位于不同的节点，并且具有不同的 IP 地址。网络管理员需要获取到每个节点所需的流量。
可以分组多个路由器来在集群中分发路由负载，并将租户单独的租户分发到不同的路由器或 分片。组中的每个路由器或分片都根据路由器中的选择器接受路由。管理员可以使用 ROUTE_LABELS 在整个集群中创建分片。用户可以使用 NAMESPACE_LABELS 在命名空间（项目）上创建分片。
3.2.11. 在部署配置中添加 Node Selector
将特定路由器部署到特定的节点上需要两个步骤：
为所需节点添加 标签 ：
oc label node 10.254.254.28 "router=first"
$ oc label node 10.254.254.28 "router=first"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将节点选择器添加到路由器部署配置中：
oc edit dc <deploymentConfigName>
$ oc edit dc <deploymentConfigName>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用与标签对应的键和值添加
template.spec.nodeSelector字段：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 键和值分别是
router和first，对应于router=first标签。
3.2.12. 使用路由器共享
路由器分片使用 NAMESPACE_LABELS 和 ROUTE_LABELS 来过滤路由器命名空间和路由。这可让您通过多个路由器部署分发路由的子集。通过使用非覆盖的子集，您可以有效地对一组路由进行分区。或者，您可以定义由重叠的路由子集组成的分片。
默认情况下，路由器从所有项目（命名空间）中选择所有路由。分片涉及将标签添加到路由或命名空间，以及向路由器添加标签选择器。每个路由器分片都由一组特定标签选择器或属于由特定标签选择器选择的命名空间来选择的路由组成。
路由器服务帐户必须设置 [集群读取器] 权限，以允许访问其他命名空间中的标签。
路由器划分和 DNS
由于需要外部 DNS 服务器将请求路由到所需的分片，因此管理员负责为项目中的每个路由器创建单独的 DNS 条目。路由器不会将未知路由转发到另一个路由器。
考虑以下示例：
-
路由器 A 驻留在主机 192.168.0.5 上，并且具有
*.foo.com的路由。 -
路由器 B 驻留在主机 192.168.1.9 上，并且具有
*.example.com的路由。
单独的 DNS 条目必须将 *.foo.com 解析为托管 Router A 和 *.example.com 的节点：
-
*.foo.com A IN 192.168.0.5 -
*.example.com A IN 192.168.1.9
路由器分片示例
本节论述了使用命名空间和路由标签进行路由器分片。
图 3.1. 路由器划分基于命名空间标签
使用命名空间标签选择器配置路由器：
oc set env dc/router NAMESPACE_LABELS="router=r1"
$ oc set env dc/router NAMESPACE_LABELS="router=r1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 由于该路由器在命名空间上有一个选择器，因此路由器将仅处理匹配的命名空间的路由。要使此选择器与命名空间匹配，请相应地标记命名空间：
oc label namespace default "router=r1"
$ oc label namespace default "router=r1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 现在，如果您在 default 命名空间中创建路由，该路由位于默认路由器中：
oc create -f route1.yaml
$ oc create -f route1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建新项目（命名空间）并创建路由
route2：oc new-project p1 oc create -f route2.yaml
$ oc new-project p1 $ oc create -f route2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意路由在路由器中不可用。
标签命名空间
p1带有router=r1oc label namespace p1 "router=r1"
$ oc label namespace p1 "router=r1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
添加此标签使路由在路由器中可用。
- 示例
一个路由器部署
finops-router使用标签选择器NAMESPACE_LABELS="name in (finance, ops)"配置，一个路由器部署dev-router使用标签选择器NAMESPACE_LABELS="name=dev"配置。如果所有路由都位于标有
name=finance、name=ops和name=dev 的命名空间中，则此配置会在两个路由器部署之间有效分发您的路由。在上面的场景中，分片成为分区的一种特殊情况，没有重叠的子集。路由在路由器分片之间划分。
路由选择标准适用于路由的分布方式。有可能在路由器部署之间具有重叠的路由子集。
- 示例
除了上例中的
finops-router和dev-router外，您还有devops-router，它使用标签选择器NAMESPACE_LABELS="name in (dev, ops)"配置。标签为
name=dev或name=ops的命名空间中的路由现在由两个不同的路由器部署服务。在这种情况下，您定义了重叠的路由子集，如 基于命名空间标签的路由器交换过程中所示。另外，这可让您创建更复杂的路由规则，允许将优先级更高的流量转移到专用的
finops-router，同时将较低优先级的流量发送到devops-router。
基于路由标签的路由器划分
NAMESPACE_LABELS 允许过滤项目来服务并从这些项目中选择所有路由，但您可能希望根据与路由本身相关的其他标准对路由进行分区。ROUTE_LABELS 选择器允许您对路由本身进行分片。
- 示例
使用标签选择器
ROUTE_LABELS="mydeployment=prod"配置路由器部署prod-router，路由器部署devtest-router则配置了标签选择器ROUTE_LABELS="mydeployment in(dev, test)"。此配置根据路由的标签（无论命名空间如何）在两个路由器部署之间路由。
这个示例假设您有要服务的所有路由，并带有标签
"mydeployment=<tag>"。
3.2.12.1. 创建路由器分片
本节描述了路由器分片的高级示例。假设有 26 个路由，名为 a 到 z，且具有不同的标签：
路由上可能的标签
sla=high geo=east hw=modest dept=finance sla=medium geo=west hw=strong dept=dev sla=low dept=ops
sla=high geo=east hw=modest dept=finance
sla=medium geo=west hw=strong dept=dev
sla=low dept=ops这些标签表达了包括服务级别协议、地理位置、硬件要求和部门在内的概念。路由最多可在每列中有一个标签。有些路由可能具有其他标签，或者根本没有标签。
| 名称 | SLA | 地域 | HW | 部门 | 其他标签 |
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
以下是一个便捷脚本 mkshard，它演示了如何一起使用 oc adm router、oc set env 和 oc scale 来创建路由器分片。
运行 mkshard 几次创建多个路由器：
| 路由器 | 选择表达式 | Routes |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
3.2.12.2. 修改路由器分片
由于路由器分片是基于标签的结构，因此您可以修改标签（通过 oc label）或选择表达式（通过 oc set env）。
本节扩展了创建路由器分片一节中启动的示例，演示了如何更改选择表达式。
以下是可修改现有路由器以使用新选择表达式的便捷脚本 modshard ：
在 modshard 中，如果 router-shard-<id>部署策略 是 Rolling，则不需要 oc scale 命令。
例如，将 router-shard-3 的部门扩展到包含 ops 和 dev ：
modshard 3 ROUTE_LABELS='dept in (dev, ops)'
$ modshard 3 ROUTE_LABELS='dept in (dev, ops)'
结果是，router-shard-3 现在选择路由 g — s (g — k 和 l — s 的组合)。
本例考虑了本例中只有三个部门，并指定了一个部门离开分片，从而得到与上例相同的结果：
modshard 3 ROUTE_LABELS='dept != finance'
$ modshard 3 ROUTE_LABELS='dept != finance'
这个示例指定了三个用逗号分开的功能，并只选择路由 b ：
modshard 3 ROUTE_LABELS='hw=strong,type=dynamic,geo=west'
$ modshard 3 ROUTE_LABELS='hw=strong,type=dynamic,geo=west'
与涉及路由标签的 ROUTE_LABELS 类似，您可以使用 NAMESPACE_LABELS 环境变量根据路由命名空间的标签选择路由。本例修改 router-shard-3 以提供命名空间具有标签 frequency=weekly 的路由：
modshard 3 NAMESPACE_LABELS='frequency=weekly'
$ modshard 3 NAMESPACE_LABELS='frequency=weekly'
最后一个示例组合了 ROUTE_LABELS 和 NAMESPACE_LABELS，以选择带有标签 sla=low 的路由，其命名空间具有标签 frequency=weekly ：
modshard 3 \
NAMESPACE_LABELS='frequency=weekly' \
ROUTE_LABELS='sla=low'
$ modshard 3 \
NAMESPACE_LABELS='frequency=weekly' \
ROUTE_LABELS='sla=low'3.2.13. 查找路由器的主机名
在公开服务时，用户可以使用来自外部用户用于访问应用的 DNS 名称相同的路由。外部网络的网络管理员必须确保主机名解析为已接受该路由的路由器的名称。用户可以使用指向此主机名的 CNAME 设置 DNS。但是，用户可能不知道路由器的主机名。当不知道时，集群管理员可以提供它。
在创建路由器时，集群管理员可以使用 --router-canonical-hostname 选项和路由器的规范主机名。例如：
oc adm router myrouter --router-canonical-hostname="rtr.example.com"
# oc adm router myrouter --router-canonical-hostname="rtr.example.com"
这会在包含路由器主机名的路由器部署配置中创建 ROUTER_CANONICAL_HOSTNAME 环境变量。
对于已存在的路由器，集群管理员可以编辑路由器的部署配置，并添加 ROUTER_CANONICAL_HOSTNAME 环境变量：
ROUTER_CANONICAL_HOSTNAME 值显示在接受该路由的所有路由器的路由状态中。每次重新载入路由器时，路由状态都会刷新。
当用户创建路由时，所有活跃的路由器都会评估路由，如果满足条件，则接受路由。当定义 ROUTER_CANONICAL_HOSTNAME 环境变量的路由器接受该路由时，路由器会将该值放在路由状态的 routerCanonicalHostname 字段中。用户可以检查路由状态，以确定路由器是否允许该路由，从列表中选择路由器，再查找要传给网络管理员的路由器的主机名。
在可用时 oc describe 会包括主机名：
oc describe route/hello-route3
$ oc describe route/hello-route3
...
Requested Host: hello.in.mycloud.com exposed on router myroute (host rtr.example.com) 12 minutes ago
利用上述信息，用户可以要求 DNS 管理员将路由的主机 hello.in.mycloud.com 中的 CNAME 设置为路由器的规范主机名 rtr.example.com。这将导致指向 hello.in.mycloud.com 的任何流量到达用户的应用。
3.2.14. 自定义默认路由子域
您可以通过修改 master 配置文件（默认为 /etc/origin/master/master-config.yaml 文件）来自定义用作环境默认路由子域的后缀。没有指定主机名的路由会有一个使用该默认路由子域生成的路由。
以下示例演示了如何将配置的后缀设置为 v3.openshift.test ：
routingConfig: subdomain: v3.openshift.test
routingConfig:
subdomain: v3.openshift.test如果 master 正在运行，这个更改需要重启。
运行上述配置的 OpenShift Container Platform master 时，对于名为 no-route-hostname 的示例路由（没有主机名添加到命名空间 mynamespace）生成的主机名将是：
no-route-hostname-mynamespace.v3.openshift.test
no-route-hostname-mynamespace.v3.openshift.test3.2.15. 将路由主机名强制到自定义路由子域
如果管理员希望限制到特定路由子域的所有路由，他们可以将 --force-subdomain 选项传递给 oc adm router 命令。这会强制路由器覆盖路由中指定的任何主机名，并根据提供给 --force-subdomain 选项的模板生成一个主机名。
以下示例运行路由器，它使用自定义子域模板 ${name}-${namespace}.apps.example.com 来覆盖路由主机名。
oc adm router --force-subdomain='${name}-${namespace}.apps.example.com'
$ oc adm router --force-subdomain='${name}-${namespace}.apps.example.com'3.2.16. 使用通配符证书
不包含证书的 TLS 路由改为使用路由器的默认证书。在大多数情况下，此证书应由可信证书颁发机构提供，但为了方便起见，您可以使用 OpenShift Container Platform CA 创建证书。例如：
CA=/etc/origin/master
oc adm ca create-server-cert --signer-cert=$CA/ca.crt \
--signer-key=$CA/ca.key --signer-serial=$CA/ca.serial.txt \
--hostnames='*.cloudapps.example.com' \
--cert=cloudapps.crt --key=cloudapps.key
$ CA=/etc/origin/master
$ oc adm ca create-server-cert --signer-cert=$CA/ca.crt \
--signer-key=$CA/ca.key --signer-serial=$CA/ca.serial.txt \
--hostnames='*.cloudapps.example.com' \
--cert=cloudapps.crt --key=cloudapps.key
oc adm ca create-server-cert 命令会生成一个有效期为两年的证书。这可以通过 --expire-days 选项进行修改，但出于安全原因，建议不要超过这个值。
仅从 Ansible 主机清单文件中列出的第一个 master 运行 oc adm 命令，默认为 /etc/ansible/hosts。
路由器预期证书和密钥在单个文件中采用 PEM 格式：
cat cloudapps.crt cloudapps.key $CA/ca.crt > cloudapps.router.pem
$ cat cloudapps.crt cloudapps.key $CA/ca.crt > cloudapps.router.pem
在这里您可以使用 --default-cert 标志：
oc adm router --default-cert=cloudapps.router.pem --service-account=router
$ oc adm router --default-cert=cloudapps.router.pem --service-account=router浏览器只考虑一个级别深度的子域有效通配符。因此在此示例中，证书对 a.cloudapps.example.com 有效，但不适用于 a.b.cloudapps.example.com。
3.2.17. 手动重新部署证书
手动重新部署路由器证书：
检查包含默认路由器证书的 secret 是否已添加到路由器中：
oc set volume dc/router
$ oc set volume dc/router deploymentconfigs/router secret/router-certs as server-certificate mounted at /etc/pki/tls/privateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果添加了证书，请跳过以下步骤并覆盖 secret。
确保为以下变量
DEFAULT_CERTIFICATE_DIR设置了一个默认证书目录：oc set env dc/router --list
$ oc set env dc/router --list DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/privateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果没有，请使用以下命令创建该目录：
oc set env dc/router DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private
$ oc set env dc/router DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/privateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将证书导出到 PEM 格式：
cat custom-router.key custom-router.crt custom-ca.crt > custom-router.crt
$ cat custom-router.key custom-router.crt custom-ca.crt > custom-router.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 覆盖或创建路由器证书 secret：
如果证书 secret 添加到路由器，请覆盖该 secret。如果没有，请创建一个新 secret。
要覆盖 secret，请运行以下命令：
oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls -o json --dry-run | oc replace -f -
$ oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls -o json --dry-run | oc replace -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要创建新 secret，请运行以下命令：
oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls oc set volume dc/router --add --mount-path=/etc/pki/tls/private --secret-name='router-certs' --name router-certs
$ oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls $ oc set volume dc/router --add --mount-path=/etc/pki/tls/private --secret-name='router-certs' --name router-certsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 部署路由器。
oc rollout latest dc/router
$ oc rollout latest dc/routerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2.18. 使用安全路由
目前，不支持密码保护的密钥文件。启动后，HAProxy 会提示输入密码，且无法自动执行此过程。要从密钥文件中删除密码短语，您可以运行以下命令：
openssl rsa -in <passwordProtectedKey.key> -out <new.key>
# openssl rsa -in <passwordProtectedKey.key> -out <new.key>以下是如何在流量代理到目的地之前使用发生在路由器上发生 TLS 终止的安全边缘终止路由的示例：安全边缘终止路由指定 TLS 证书和密钥信息。TLS 证书由路由器前端提供。
首先，启动一个路由器实例：
oc adm router --replicas=1 --service-account=router
# oc adm router --replicas=1 --service-account=router
接下来，为我们边缘安全路由创建私钥、csr 和证书。有关如何执行此操作的说明将特定于您的证书颁发机构和提供商。有关名为 www.example.test 的域的简单自签名证书，请参考以下示例：
使用上述证书和密钥生成路由。
oc create route edge --service=my-service \
--hostname=www.example.test \
--key=example-test.key --cert=example-test.crt
$ oc create route edge --service=my-service \
--hostname=www.example.test \
--key=example-test.key --cert=example-test.crt
route "my-service" created看一下其定义。
确保 www.example.test 的 DNS 条目指向您的路由器实例，并且到您的域的路由应可用。以下示例使用 curl 和本地解析器模拟 DNS 查找：
routerip="4.1.1.1" # replace with IP address of one of your router instances. curl -k --resolve www.example.test:443:$routerip https://www.example.test/
# routerip="4.1.1.1" # replace with IP address of one of your router instances.
# curl -k --resolve www.example.test:443:$routerip https://www.example.test/3.2.19. 使用通配符路由（用于子域）
HAProxy 路由器支持通配符路由，这通过将 ROUTER_ALLOW_WILDCARD_ROUTES 环境变量设置为 true 来启用。具有 Subdomain 通配符策略且通过路由器准入检查的任何路由都将由 HAProxy 路由器提供服务。然后，HAProxy 路由器根据路由的通配符策略公开相关的服务（用于路由）。
要更改路由的通配符策略，您必须删除路由并使用更新的通配符策略重新创建路由。仅编辑路由的 .yaml 文件中的路由通配符策略无法正常工作。
oc adm router --replicas=0 ... oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true oc scale dc/router --replicas=1
$ oc adm router --replicas=0 ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true
$ oc scale dc/router --replicas=1使用安全通配符边缘终止路由
这个示例反映了在流量代理到目的地之前在路由器上发生的 TLS 终止。发送到子域 example.org( )中的任何主机的流量将代理到公开的服务。
*.example.org
安全边缘终止路由指定 TLS 证书和密钥信息。TLS 证书由与子域(*.example.org)匹配的所有主机的路由器前端提供。
启动路由器实例：
oc adm router --replicas=0 --service-account=router oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true oc scale dc/router --replicas=1
$ oc adm router --replicas=0 --service-account=router $ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true $ oc scale dc/router --replicas=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为边缘安全路由创建私钥、证书签名请求(CSR)和证书。
有关如何执行此操作的说明特定于您的证书颁发机构和供应商。有关名为
*.example.test的域的简单自签名证书，请查看以下示例：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用上述证书和密钥生成通配符路由：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确保
*.example.test的 DNS 条目指向您的路由器实例，并且到域的路由可用。这个示例使用带有本地解析器的
curl来模拟 DNS 查找：routerip="4.1.1.1" # replace with IP address of one of your router instances. curl -k --resolve www.example.test:443:$routerip https://www.example.test/ curl -k --resolve abc.example.test:443:$routerip https://abc.example.test/ curl -k --resolve anyname.example.test:443:$routerip https://anyname.example.test/
# routerip="4.1.1.1" # replace with IP address of one of your router instances. # curl -k --resolve www.example.test:443:$routerip https://www.example.test/ # curl -k --resolve abc.example.test:443:$routerip https://abc.example.test/ # curl -k --resolve anyname.example.test:443:$routerip https://anyname.example.test/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
对于允许通配符路由的路由器（ROUTER_ALLOW_WILDCARD_ROUTES 设置为 true），存在一些注意事项，即与通配符路由关联的子域的所有权。
在通配符路由之前，所有权基于针对任何其他声明赢得路由最旧的命名空间的主机名提出的声明。例如，如果路由 r1 比路由 r2 老，对于 主机名 one.example.test，命名空间 ns1 中的路由 r1（有一个 one.example.test 的声明）会优于命令空间 ns2 中具有相同声明的路由 r2。
另外，其他命名空间中的路由也被允许声明非覆盖的主机名。例如，命名空间 ns1 中的路由 rone 可以声明 www.example.test，命名空间 d2 中的另一个路由 rtwo 可以声明 c3po.example.test。
如果没有任何通配符路由声明同一子域（上例中的example.test ），则仍会出现这种情况。
但是，通配符路由需要声明子域中的所有主机名（以 \*.example.test格式的主机名）。通配符路由的声明会根据该子域的最旧路由(example.test)是否与通配符路由在同一命名空间中被允许或拒绝。最旧的路由可以是常规路由，也可以是通配符路由。
例如，如果已有一个路由 eldest 存在于 s1 命名空间中，声明一个名为 owner.example.test 的主机，如果稍后某个时间点上添加了一个新的通配符用来通配子域 (example.test) 中的路由，则通配路由的声明仅在与拥有的路由处于相同命名空间 (ns1)时才被允许。
以下示例演示了通配符路由的声明将成功或失败的各种情景。
在以下示例中，只要通配符路由未声明子域，允许通配符路由的路由器将允许对子域 example.test 中的主机进行非覆盖声明。
在以下示例中，允许通配符路由的路由器不允许 owner.example.test 或 aname.example.test 的声明成功，因为拥有的命名空间是 ns1。
在以下示例中，允许通配符路由的路由器将允许 '\*.example.test 声明成功，因为拥有的命名空间是 ns1，通配符路由属于同一命名空间。
在以下示例中，允许通配符路由的路由器不允许 '\*.example.test 声明成功，因为拥有的命名空间是 ns1，并且通配符路由属于另一个命名空间 cyclone。
同样，当具有通配符路由的命名空间声明子域后，只有该命名空间中的路由才能声明同一子域中的任何主机。
在以下示例中，当命名空间 ns1 中带有通配符路由声明子域 example.test 的路由之后，只有命名空间 ns1 中的路由可以声明同一子域中的任何主机。
在以下示例中，显示了不同的场景，其中删除所有者路由并在命名空间内和跨命名空间传递所有权。虽然命名空间 ns1 中存在声明主机 eldest.example.test 的路由，但该命名空间中的通配符路由可以声明子域 example.test。当删除主机 eldest.example.test 的路由时，下一个最旧的路由 senior.example.test 将成为最旧的路由，不会影响任何其他路由。删除主机 senior.example.test 的路由后，下一个最旧的路由 junior.example.test 将成为最旧路由并阻止通配符路由。
3.2.20. 使用 Container Network Stack
OpenShift Container Platform 路由器在容器内运行，默认的行为是使用主机的网络堆栈（即，路由器容器运行的节点）。这个默认行为有利于性能，因为来自远程客户端的网络流量不需要通过用户空间获取多个跃点来访问目标服务和容器。
另外，这个默认行为可让路由器获取远程连接的实际源 IP 地址，而不是获取节点的 IP 地址。这可用于定义基于原始 IP、支持粘性会话和监控流量以及其他用途的入口规则。
此主机网络行为由 --host-network 路由器命令行选项控制，默认行为等同于使用 --host-network=true。如果要使用容器网络堆栈运行路由器，请在创建路由器时使用 --host-network=false 选项。例如：
oc adm router --service-account=router --host-network=false
$ oc adm router --service-account=router --host-network=false在内部，这意味着路由器容器必须发布 80 和 443 端口，以便外部网络与路由器通信。
使用容器网络堆栈运行意味着路由器将连接的源 IP 地址视为节点的 NATed IP 地址，而不是实际的远程 IP 地址。
在使用多租户网络隔离的 OpenShift Container Platform 集群中，带有 --host-network=false 选项的非默认命名空间中的路由器将加载集群中的所有路由，但命名空间之间的路由会因为网络隔离而无法访问。使用 --host-network=true 选项时，路由会绕过容器网络，并且可以访问集群中的任何 pod。在这种情况下，如果需要隔离，则不要在命名空间间添加路由。
3.2.21. 使用动态配置管理器
您可以配置 HAProxy 路由器来支持动态配置管理器。
动态配置管理器带来某些类型的在线路由，无需 HAProxy 重新加载停机时间。它处理任何路由和端点生命周期事件，如路由和端点附加 |deletion|update。
通过将 ROUTER_HAPROXY_CONFIG_MANAGER 环境变量设置为 true 来启用动态配置管理器：
oc set env dc/<router_name> ROUTER_HAPROXY_CONFIG_MANAGER='true'
$ oc set env dc/<router_name> ROUTER_HAPROXY_CONFIG_MANAGER='true'如果动态配置管理器无法动态配置 HAProxy，它会重写配置并重新加载 HAProxy 进程。例如，如果新路由包含自定义注解，如自定义超时，或者路由需要自定义 TLS 配置。
动态配置内部使用 HAProxy 套接字和配置 API，以及预分配的路由和后端服务器池。预分配的路由池使用路由蓝图创建。默认蓝图集支持不安全的路由、边缘安全路由，无需任何自定义 TLS 配置和直通路由。
重新加密 路由需要自定义 TLS 配置信息，因此需要额外的配置才能将其用于动态配置管理器。
通过设置 ROUTER_BLUEPRINT_ROUTE_NAMESPACE 以及可选的 ROUTER_BLUEPRINT_ROUTE_LABELS 环境变量来扩展动态配置管理器可以使用的蓝图。
蓝图路由命名空间中的所有路由或路由标签的路由作为与默认蓝图集类似的自定义蓝图处理。这包括使用自定义注解或路由的重新加密路由或自定义 TLS 配置的路由。
以下流程假定您已创建了三个路由对象：reencrypt-blueprint, annotated-edge-blueprint, 和 annotated-unsecured-blueprint。如需不同路由类型对象的示例，请参阅 Route Types。
流程
创建一个新项目
oc new-project namespace_name
$ oc new-project namespace_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建新路由。此方法公开现有的服务：
oc create route edge edge_route_name --key=/path/to/key.pem \ --cert=/path/to/cert.pem --service=<service> --port=8443$ oc create route edge edge_route_name --key=/path/to/key.pem \ --cert=/path/to/cert.pem --service=<service> --port=8443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 标记路由：
oc label route edge_route_name type=route_label_1
$ oc label route edge_route_name type=route_label_1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建与路由对象定义不同的路由 ：所有都具有标签
type=route_label_1:oc create -f reencrypt-blueprint.yaml oc create -f annotated-edge-blueprint.yaml oc create -f annotated-unsecured-blueprint.json
$ oc create -f reencrypt-blueprint.yaml $ oc create -f annotated-edge-blueprint.yaml $ oc create -f annotated-unsecured-blueprint.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您还可以从路由中删除标签，这会阻止它用作蓝图路由。例如，防止
annotated-unsecured-blueprint用作蓝图路由：oc label route annotated-unsecured-blueprint type-
$ oc label route annotated-unsecured-blueprint type-Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建用于蓝图池的新路由器：
oc adm router
$ oc adm routerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为新路由器设置环境变量：
oc set env dc/router ROUTER_HAPROXY_CONFIG_MANAGER=true \ ROUTER_BLUEPRINT_ROUTE_NAMESPACE=namespace_name \ ROUTER_BLUEPRINT_ROUTE_LABELS="type=route_label_1"$ oc set env dc/router ROUTER_HAPROXY_CONFIG_MANAGER=true \ ROUTER_BLUEPRINT_ROUTE_NAMESPACE=namespace_name \ ROUTER_BLUEPRINT_ROUTE_LABELS="type=route_label_1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 处理命名空间或带有
type=route_label_1标签的项目namespace_name中的所有路由，并用作自定义蓝图。请注意，您还可以通过管理该命名空间
namespace_name中的路由来添加、更新或删除蓝图。动态配置管理器会监视命名空间namespace_name中路由的更改，类似于路由器监视路由和服务的方式。预分配的路由和后端服务器的池大小可以通过
ROUTER_BLUEPRINT_ROUTE_POOL_SIZE控制，默认为10， 而ROUTER_MAX_DYNAMIC_SERVERS默认为5环境变量。您还可以控制动态配置管理器所做的更改的频率，即当重新编写 HAProxy 配置并重新加载 HAProxy 进程时。默认值为 1 小时或 3600 秒，或者当动态配置管理器用尽池空间时。COMMIT_INTERVAL环境变量控制此设置：oc set env dc/router -c router ROUTER_BLUEPRINT_ROUTE_POOL_SIZE=20 \ ROUTER_MAX_DYNAMIC_SERVERS=3 COMMIT_INTERVAL=6h$ oc set env dc/router -c router ROUTER_BLUEPRINT_ROUTE_POOL_SIZE=20 \ ROUTER_MAX_DYNAMIC_SERVERS=3 COMMIT_INTERVAL=6hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这个示例将每个蓝图路由的池大小增加到
20，将动态服务器的数量减少到3，并将提交间隔增加到6小时。
3.2.22. 公开路由器指标
HAProxy 路由器指标 默认以 Prometheus 格式 公开或发布，供外部指标收集和聚合系统（如 Prometheus、statsd）使用。指标数据也可直接从 HAProxy 路由器 以自己的 HTML 格式获取，以便在浏览器或 CSV 下载中查看。这些指标包括 HAProxy 原生指标和一些控制器指标。
当您使用以下命令创建路由器时，OpenShift Container Platform 以 Prometheus 格式在 stats 端口（默认为 1936）上提供指标数据。
oc adm router --service-account=router
$ oc adm router --service-account=router要提取 Prometheus 格式的原始统计信息，请运行以下命令：
curl <user>:<password>@<router_IP>:<STATS_PORT>
curl <user>:<password>@<router_IP>:<STATS_PORT>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
curl admin:sLzdR6SgDJ@10.254.254.35:1936/metrics
$ curl admin:sLzdR6SgDJ@10.254.254.35:1936/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以获取访问路由器服务注解中的指标所需的信息：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow prometheus.io/port是 stats 端口，默认为 1936。您可能需要配置防火墙以允许访问。使用前面的用户名和密码来访问指标。路径是 /metrics。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在浏览器中获取指标：
从路由器部署配置文件中删除以下 环境变量 ：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 对路由器就绪度探测进行补丁，以使用与存活度探测相同的路径，它现在由 haproxy 路由器提供：
oc patch dc router -p '"spec": {"template": {"spec": {"containers": [{"name": "router","readinessProbe": {"httpGet": {"path": "/healthz"}}}]}}}'$ oc patch dc router -p '"spec": {"template": {"spec": {"containers": [{"name": "router","readinessProbe": {"httpGet": {"path": "/healthz"}}}]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在浏览器中使用以下 URL 启动 stats 窗口，其中
STATS_PORT值默认为1936:http://admin:<Password>@<router_IP>:<STATS_PORT>
http://admin:<Password>@<router_IP>:<STATS_PORT>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以通过在 URL 中添加
;csv来获得 CSV 格式的统计信息：例如：
http://admin:<Password>@<router_IP>:1936;csv
http://admin:<Password>@<router_IP>:1936;csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 获取路由器 IP、管理员名称和密码：
oc describe pod <router_pod>
oc describe pod <router_pod>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
禁止指标收集：
oc adm router --service-account=router --stats-port=0
$ oc adm router --service-account=router --stats-port=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2.23. 大型集群的 ARP 缓存调优
在具有大量路由的 OpenShift Container Platform 集群中（超过 net.ipv4.neigh.default.gc_thresh3 的值 65536），您必须增加运行路由器 pod 的集群中每个节点上的 sysctl 变量默认值，以允许 ARP 缓存中更多条目。
当出现问题时，内核信息类似如下：
[ 1738.811139] net_ratelimit: 1045 callbacks suppressed [ 1743.823136] net_ratelimit: 293 callbacks suppressed
[ 1738.811139] net_ratelimit: 1045 callbacks suppressed
[ 1743.823136] net_ratelimit: 293 callbacks suppressed
当出现这个问题时，oc 命令可能会因为以下错误开始失败：
Unable to connect to the server: dial tcp: lookup <hostname> on <ip>:<port>: write udp <ip>:<port>-><ip>:<port>: write: invalid argument
Unable to connect to the server: dial tcp: lookup <hostname> on <ip>:<port>: write udp <ip>:<port>-><ip>:<port>: write: invalid argument要验证 IPv4 的 ARP 条目的实际数量，请运行以下内容：
ip -4 neigh show nud all | wc -l
# ip -4 neigh show nud all | wc -l
如果数字开始接近 net.ipv4.neigh.default.gc_thresh3 阈值，则增加值。运行以下命令来获取当前值：
以下 sysctl 将变量设置为 OpenShift Container Platform 当前默认值。
sysctl net.ipv4.neigh.default.gc_thresh1=8192 sysctl net.ipv4.neigh.default.gc_thresh2=32768 sysctl net.ipv4.neigh.default.gc_thresh3=65536
# sysctl net.ipv4.neigh.default.gc_thresh1=8192
# sysctl net.ipv4.neigh.default.gc_thresh2=32768
# sysctl net.ipv4.neigh.default.gc_thresh3=65536要使这些设置永久生效，请查看本文档。
3.2.24. 保护 DDoS Attacks
向默认 HAProxy 路由器镜像添加 超时 http-request，以防止部署遭受分布式拒绝服务（例如，slowloris）攻击：
- 1
- 超时 http-request 设置为 5 秒。HAProxy 为客户端 5 秒提供 * 以发送其整个 HTTP 请求。否则，HAProxy 会关闭连接并显示 *an 错误。
另外，当设置环境变量 ROUTER_SLOWLORIS_TIMEOUT 时，它会限制客户端发送整个 HTTP 请求所需的时间。否则，HAProxy 将关闭连接。
通过设置 环境变量，可以将信息捕获为路由器部署配置的一部分，不需要手动修改模板，而手动添加 HAProxy 设置要求您重新构建路由器 Pod 和维护路由器模板文件。
使用注解在 HAProxy 模板路由器中实施基本的 DDoS 保护，包括限制以下功能：
- 并发 TCP 连接数
- 客户端可以请求 TCP 连接的速率
- 可以发出 HTTP 请求的速率
这些是在每个路由上启用的，因为应用可能有完全不同的流量模式。
| 设置 | 描述 |
|---|---|
|
| 启用设置（例如，设置为 true ）。 |
|
| 此路由上相同 IP 地址可执行的并发 TCP 连接数。 |
|
| 客户端 IP 可以打开的 TCP 连接数。 |
|
| 客户端 IP 在 3 秒期间内可以进行的 HTTP 请求数。 |
3.2.25. 启用 HAProxy 线程
使用 --threads 标志启用线程处理。此标志指定 HAProxy 路由器将使用的线程数量。
3.3. 部署自定义 HAProxy 路由器
3.3.1. 概述
默认 HAProxy 路由器旨在满足大多数用户的需求。但是，它不会公开 HAProxy 的所有功能。因此，用户可能需要根据自己的需求修改路由器。
您可能需要在应用后端内实施新功能，或修改当前的操作。router 插件提供了进行此自定义所需的所有功能。
路由器容器集使用模板文件来创建所需的 HAProxy 配置文件。模板文件是 golang 模板。在处理模板时，路由器可以访问 OpenShift Container Platform 信息，包括路由器的部署配置、接受路由集和一些帮助程序功能。
当路由器 pod 启动时，并且每次重新加载时，它会创建一个 HAProxy 配置文件，然后启动 HAProxy。HAProxy 配置手册 描述了 HAProxy 的所有功能以及如何构建有效的配置文件。
configMap 可用于添加新模板到路由器 pod。通过这种方法，修改路由器部署配置，将 configMap 挂载为路由器 Pod 中的卷。TEMPLATE_FILE 环境变量设置为路由器 Pod 中模板文件的完整路径名称。
无法保证在升级 OpenShift Container Platform 后路由器模板自定义仍然可以正常工作。
此外，路由器模板自定义必须应用到运行的路由器的模板版本。
或者，您也可以构建自定义路由器镜像，并在部署部分或所有路由器时使用它。不需要所有路由器来运行同一镜像。为此，请修改 haproxy-template.config 文件，再重新构建 路由器 镜像。新镜像推送到集群的 Docker 存储库，路由器的部署配置 image: 字段则使用新名称更新。更新集群时，需要重新构建并推送镜像。
在这两种情况下，路由器容器集都以模板文件开头。
3.3.2. 获取路由器配置模板
HAProxy 模板文件非常大且复杂。对于某些更改，修改现有模板可能比编写完整的替换版本更简单。您可以通过在 master 上运行并引用路由器 pod，从正在运行的路由器获取 haproxy-config.template 文件：
oc get po oc exec router-2-40fc3 cat haproxy-config.template > haproxy-config.template oc exec router-2-40fc3 cat haproxy.config > haproxy.config
# oc get po
NAME READY STATUS RESTARTS AGE
router-2-40fc3 1/1 Running 0 11d
# oc exec router-2-40fc3 cat haproxy-config.template > haproxy-config.template
# oc exec router-2-40fc3 cat haproxy.config > haproxy.config另外，您可以登录到运行路由器的节点：
docker run --rm --interactive=true --tty --entrypoint=cat \
registry.redhat.io/openshift3/ose-haproxy-router:v{product-version} haproxy-config.template
registry.redhat.io/openshift3/ose-haproxy-router:v{product-version} haproxy-config.template
# docker run --rm --interactive=true --tty --entrypoint=cat \
registry.redhat.io/openshift3/ose-haproxy-router:v{product-version} haproxy-config.template镜像名称来自容器镜像。
将此内容保存到文件中，以用作自定义模板的基础。保存的 haproxy.config 显示实际运行的内容。
3.3.3. 修改路由器配置模板
3.3.3.1. 背景信息
模板基于 golang 模板。它可以引用路由器部署配置中的任何环境变量、下面描述的任何配置信息，以及路由器提供的帮助程序功能。
模板文件的结构镜像生成的 HAProxy 配置文件。在处理模板时，所有未被 {{" something "}} 包括的内容会直接复制到配置文件。被 {{" something "}} 包括的内容会被评估。生成的文本（如果有）复制到配置文件。
3.3.3.2. Go 模板操作
define 操作命名将包含已处理模板的文件。
{{define "/var/lib/haproxy/conf/haproxy.config"}}pipeline{{end}}
{{define "/var/lib/haproxy/conf/haproxy.config"}}pipeline{{end}}| 功能 | 含义 |
|---|---|
|
| 返回有效端点列表。当操作为"shuffle"时，端点的顺序是随机的。 |
|
| 尝试从容器集获取 named 环境变量。如果未定义或为空，它将返回可选的第二个参数。否则，它将返回空字符串。 |
|
| 第一个参数是包含正则表达式的字符串，第二个参数是要测试的变量。返回一个布尔值，指示作为第一个参数提供的正则表达式是否与作为第二个参数提供的字符串匹配。 |
|
| 确定给定变量是否为整数。 |
|
| 将给定字符串与允许字符串的列表进行比较。通过列表向右返回第一个匹配扫描. |
|
| 将给定字符串与允许字符串的列表进行比较。如果字符串为允许的值，则返回 "true"，否则返回 false。 |
|
| 生成与路由主机（和路径）匹配的正则表达式。第一个参数是主机名，第二个参数是路径，第三个参数是通配符布尔值。 |
|
| 生成用于服务/匹配证书的主机名。第一个参数是主机名，第二个参数是通配符布尔值。 |
|
| 确定给定变量是否包含"true"。 |
这些功能由 HAProxy 模板路由器插件提供。
3.3.3.3. 路由器提供的信息
本节回顾路由器在模板中提供的 OpenShift Container Platform 信息。路由器配置参数是 HAProxy 路由器插件提供的一组数据。这些字段可由 (dot).Fieldname 访问。
路由器配置参数下方的表格根据各种字段的定义展开。特别是 .State 拥有一组可接受的路由。
| 字段 | 类型 | 描述 |
|---|---|---|
|
| 字符串 | 文件要写入的目录，默认为 /var/lib/containers/router |
|
|
| 路由。 |
|
|
| 服务查找。 |
|
| 字符串 | 以 pem 格式到默认证书的完整路径名称。 |
|
|
| 对等。 |
|
| 字符串 | 公开统计数据的用户名（如果模板支持）。 |
|
| 字符串 | 公开统计数据的密码（如果模板支持）。 |
|
| int | 公开统计信息的端口（如果模板支持）。 |
|
| bool | 路由器是否应绑定默认端口。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
| 字符串 | 路由特定于用户的名称。 |
|
| 字符串 | 路由的命名空间。 |
|
| 字符串 |
主机名。例如： |
|
| 字符串 |
可选路径。例如： |
|
|
| 此后端的终止策略；驱动映射文件和路由器配置。 |
|
|
| 用于保护此后端的证书。按证书 ID 的键。 |
|
|
| 指明需要永久保留的配置状态。 |
|
| 字符串 | 指明用户要公开的端口。如果为空，将为服务选择一个端口。 |
|
|
|
指明到边缘终端路由的不安全连接所需的行为： |
|
| 字符串 | 用于模糊 cookie ID 的路由 + 命名空间名称的哈希值。 |
|
| bool | 表示此服务单元需要通配符支持。 |
|
|
| 附加到此路由的注解。 |
|
|
| 支持此路由的服务集合，按服务名称键，并根据映射中其他条目的权重加上相应的权重。 |
|
| int |
权重为非零的 |
ServiceAliasConfig 是服务的路由。由主机 + 路径唯一标识指定。默认模板使用 {{range $cfgIdx、$cfg := .State }} 迭代路由。在这样的 {{range}} 块中，模板可以使用 $cfg.Field 引用当前 ServiceAliasConfig 的任何字段。
| 字段 | 类型 | 描述 |
|---|---|---|
|
| 字符串 |
对应于服务名称 + namespace 的名称。由 |
|
|
| 支持该服务的端点。这转换为路由器的最终后端实施。 |
ServiceUnit 是一种服务封装、支持该服务的端点，以及指向服务的路由。这是驱动创建路由器配置文件的数据
| 字段 | 类型 |
|---|---|
|
| 字符串 |
|
| 字符串 |
|
| 字符串 |
|
| 字符串 |
|
| 字符串 |
|
| 字符串 |
|
| bool |
Endpoint 是 Kubernetes 端点的内部表示。
| 字段 | 类型 | 描述 |
|---|---|---|
|
| 字符串 |
代表一个公钥/私钥对。它通过 ID 来标识，该 ID 将成为文件名。CA 证书将不会设置 |
|
| 字符串 | 表示此配置所需的文件已持久保存到磁盘。有效值："saved", ""。 |
| 字段 | 类型 | 描述 |
|---|---|---|
| ID | 字符串 | |
| 内容 | 字符串 | 证书。 |
| PrivateKey | 字符串 | 私钥。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
| 字符串 | 指定安全通信将停止的位置。 |
|
| 字符串 | 表示路由不安全连接所需的行为。虽然每个路由器可能会对要公开的端口做出自己的决定，但通常这是端口 80。 |
TLSTerminationType 和 InsecureEdgeTerminationPolicyType 指定安全通信将停止的位置。
| 常数 | 值 | 含义 |
|---|---|---|
|
|
| 终止边缘路由器上的加密。 |
|
|
| 目的地终止加密，目的地负责解密流量。 |
|
|
| 在边缘路由器中终止加密，并使用目的地提供的新证书重新加密。 |
| 类型 | 含义 |
|---|---|
|
| 流量发送到不安全端口（默认）上的服务器。 |
|
| 不安全的端口不允许流量。 |
|
| 客户端重定向到安全端口。 |
None ("") 与 Disable 相同。
3.3.3.4. 注解
每个路由都可以附加注解。每个注释仅是一个名称和一个值。
名称可以是与现有 Annotations 没有冲突的任何内容。值是任意字符串。字符串可以具有多个令牌，用空格分开。例如，aa bb cc.该模板使用 {{index}} 来提取注释的值。例如：
{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}
{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}这是如何将其用于相互客户端授权的示例。
然后，您可以使用此命令处理列入白名单的 CN。
oc annotate route <route-name> --overwrite whiteListCertCommonName="CN1 CN2 CN3"
$ oc annotate route <route-name> --overwrite whiteListCertCommonName="CN1 CN2 CN3"如需更多信息，请参阅特定于路由的注解。
3.3.3.5. 环境变量
该模板可以使用路由器 pod 中存在的任何环境变量。环境变量可以在部署配置中设置。可以添加新的环境变量。
它们由 env 函数引用：
{{env "ROUTER_MAX_CONNECTIONS" "20000"}}
{{env "ROUTER_MAX_CONNECTIONS" "20000"}}
第一个字符串是 变量，第二个字符串是变量缺失或 nil 时的默认值。当 ROUTER_MAX_CONNECTIONS 未设置或为 nil 时，则使用 20000。环境变量是一个映射，其中键是环境变量名称，内容是 变量的值。
如需更多信息，请参阅特定于路由的环境变量。
3.3.3.6. 用法示例
以下是基于 HAProxy 模板文件的简单模板：
从注释开始：
{{/*
Here is a small example of how to work with templates
taken from the HAProxy template file.
*/}}
{{/*
Here is a small example of how to work with templates
taken from the HAProxy template file.
*/}}模板可以创建任意数量的输出文件。使用定义结构来创建输出文件。文件名指定为要定义的参数，定义块内直到匹配端的所有内容都会被写入为该文件的内容。
{{ define "/var/lib/haproxy/conf/haproxy.config" }}
global
{{ end }}
{{ define "/var/lib/haproxy/conf/haproxy.config" }}
global
{{ end }}
上方会将 global 复制到 /var/lib/haproxy/conf/haproxy.config 文件，然后关闭该文件。
根据环境变量设置日志记录。
{{ with (env "ROUTER_SYSLOG_ADDRESS" "") }}
log {{.}} {{env "ROUTER_LOG_FACILITY" "local1"}} {{env "ROUTER_LOG_LEVEL" "warning"}}
{{ end }}
{{ with (env "ROUTER_SYSLOG_ADDRESS" "") }}
log {{.}} {{env "ROUTER_LOG_FACILITY" "local1"}} {{env "ROUTER_LOG_LEVEL" "warning"}}
{{ end }}
env 函数提取环境变量的值。如果未定义环境变量或 nil，则返回第二个参数。
通过，使用 将 块中的 "."(dot)值设置为作为使用 的参数提供的任何值。with 操作测试点为 nil。如果没有 nil，则会处理到最后。在上面，假设 ROUTER_SYSLOG_ADDRESS 包含 /var/log/msg、ROUTER_LOG_FACILITY 未定义，并且 ROUTER_LOG_LEVEL 包含 info。以下命令将复制到输出文件中：
log /var/log/msg local1 info
log /var/log/msg local1 info
每个接受的路由最终都会在配置文件中生成行。使用 范围 来进入接受的路由：
{{ range $cfgIdx, $cfg := .State }}
backend be_http_{{$cfgIdx}}
{{end}}
{{ range $cfgIdx, $cfg := .State }}
backend be_http_{{$cfgIdx}}
{{end}}
.State 是 ServiceAliasConfig 的映射，其中键是路由名称. 范围 步骤通过映射，每个传递都使用 键 设置 $cfgIdx，并将 $cfg 设置为指向描述路由的 ServiceAliasConfig。如果有两个路由名为 myroute 和 heroute，则上述命令会将以下内容复制到输出文件中：
backend be_http_myroute backend be_http_hisroute
backend be_http_myroute
backend be_http_hisroute
Route Annotations、$cfg.Annotations 也是注解名称作为键的映射，内容字符串作为值。路由可以根据需要拥有更多注解，其使用由模板作者定义。用户将注解代码到路由中，模板作者则自定义 HAProxy 模板来处理注解。
常见用法是索引注解以获取值。
{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}
{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}
索引提取给定注解的值（若有）。因此，$balanceAlgo 将包含与注解或 nil 关联的字符串。如上所示，您可以测试非空字符串，并使用 with 结构对其执行操作。
{{ with $balanceAlgo }}
balance $balanceAlgo
{{ end }}
{{ with $balanceAlgo }}
balance $balanceAlgo
{{ end }}
此处，如果 $balanceAlgo 不是 nil，平衡 $balanceAlgo 将复制到输出文件中。
在第二个示例中，您想要根据注释中设置的超时值设置服务器超时。
$value := index $cfg.Annotations "haproxy.router.openshift.io/timeout"
$value := index $cfg.Annotations "haproxy.router.openshift.io/timeout"
现在 $value 会被评估，以确保它包含正确构建的字符串。matchPattern 函数接受正则表达式，如果参数满足表达式要求，则返回 true。
matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value
matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value
这会接受 5000ms，但不接受 7y。结果可用于测试。
{{if (matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value) }}
timeout server {{$value}}
{{ end }}
{{if (matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value) }}
timeout server {{$value}}
{{ end }}它还可用于匹配令牌：
matchPattern "roundrobin|leastconn|source" $balanceAlgo
matchPattern "roundrobin|leastconn|source" $balanceAlgo
另外，也可以使用 matchValues 来匹配令牌：
matchValues $balanceAlgo "roundrobin" "leastconn" "source"
matchValues $balanceAlgo "roundrobin" "leastconn" "source"3.3.4. 使用 ConfigMap 替换路由器配置模板
您可以使用 ConfigMap 来自定义路由器实例，而无需重新构建路由器镜像。可以修改 haproxy-config.template、reload-haproxy 和其他脚本，以及创建和修改路由器环境变量。
- 复制您要修改的 haproxy-config.template，如上所述根据需要进行修改。
创建 ConfigMap：
oc create configmap customrouter --from-file=haproxy-config.template
$ oc create configmap customrouter --from-file=haproxy-config.templateCopy to Clipboard Copied! Toggle word wrap Toggle overflow customrouterConfigMap 现在包含修改后的 haproxy-config.template 文件的副本。修改路由器部署配置，将 ConfigMap 挂载为文件，并将
TEMPLATE_FILE环境变量指向该文件。这可以通过oc set env和oc set volume命令完成，或者通过编辑路由器部署配置来完成。- 使用
oc命令 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 编辑路由器部署配置
使用
oc edit dc router，使用文本编辑器编辑路由器部署配置。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 保存更改并退出编辑器。这将重新启动路由器。
- 使用
3.3.5. 使用粘滞表
以下示例自定义可在高可用性路由设置中使用，以使用在对等点间同步的粘滞表。
添加 Peer 部分
要在对等点间同步粘滞位，您必须在 HAProxy 配置中定义对等部分。本节决定了 HAProxy 如何识别并连接到同级服务器。插件在 .PeerEndpoints 变量下向模板提供数据，以便您可以轻松地识别路由器服务的成员。您可以通过添加以下内容，将 peer 部分添加到路由器镜像中的 haproxy-config.template 文件中：
更改重新加载脚本
使用粘滞位时，您可以选择告知 HAProxy 在 peer 部分中应考虑本地主机的名称。在创建端点时，插件会尝试将 TargetName 设置为端点的 TargetRef.Name 的值。如果没有设置 TargetRef，它会将 TargetName 设置为 IP 地址。TargetRef.Name 与 Kubernetes 主机名对应，因此您可以将 -L 选项添加到 reload-haproxy 脚本中，以标识 peer 部分中的本地主机。
- 1
- 必须与 peer 部分中使用的端点目标名称匹配。
修改后端
最后，若要在后端使用 stick-tables，您可以修改 HAProxy 配置以使用 stick-tables 和 peer 设置。以下是将 TCP 连接的现有后端更改为使用 stick-table 的示例：
在修改后，您可以重建路由器。
3.3.6. 重建路由器
若要重建路由器，您需要复制正在运行的路由器上存在的多个文件。创建一个工作目录并从路由器复制文件：
您可以编辑或替换其中任何一个文件。但是，conf/haproxy-config.template 和 reload-haproxy 最有可能被修改。
更新文件后：
docker build -t openshift/origin-haproxy-router-myversion . docker tag openshift/origin-haproxy-router-myversion 172.30.243.98:5000/openshift/haproxy-router-myversion docker push 172.30.243.98:5000/openshift/origin-haproxy-router-pc:latest
# docker build -t openshift/origin-haproxy-router-myversion .
# docker tag openshift/origin-haproxy-router-myversion 172.30.243.98:5000/openshift/haproxy-router-myversion
# docker push 172.30.243.98:5000/openshift/origin-haproxy-router-pc:latest
要使用新路由器，请通过更改 image: 字符串或将 --images=<repo>/<image>:<tag> 标志添加到 oc adm router 命令来编辑路由器部署配置。
调试更改时，设置 imagePullPolicy:Always 在部署配置中，强制在每次 pod 创建时拉取镜像。调试完成后，您可以将其改回到 imagePullPolicy:IfNotPresent 以避免每次 pod 启动时都拉取。
3.4. 将 HAProxy 路由器配置为使用 PROXY 协议
3.4.1. 概述
默认情况下，HAProxy 路由器要求进入到不安全、边缘和重新加密路由的连接才能使用 HTTP。但是，您可以使用 PROXY 协议 将路由器配置为预期传入请求。本节论述了如何将 HAProxy 路由器和外部负载均衡器配置为使用 PROXY 协议。
3.4.2. 为什么使用 PROXY 协议？
当代理服务器或负载平衡器等中间服务转发 HTTP 请求时，它会将连接的源地址附加到请求的"Forwarded"标头，从而将此信息提供给后续请求，以及最终将请求转发到的后端服务。但是，如果连接被加密，则无法修改"Forwarded"标头。在这种情况下，HTTP 标头无法在转发请求时准确传达原始源地址。
为了解决这个问题，一些负载均衡器使用 PROXY 协议封装 HTTP 请求，作为只转发 HTTP 的替代选择。封装使负载平衡器能够在不修改转发请求本身的情况下向请求添加信息。特别是，这意味着负载均衡器即使在转发加密的连接时也能通信源地址。
HAProxy 路由器可以配置为接受 PROXY 协议并解封 HTTP 请求。由于路由器终止对边缘和再加密路由的加密，因此路由器随后可以更新请求中的 "Forwarded" HTTP 标头（及相关的 HTTP 标头），附加使用 PROXY 协议通信的任何源地址。
PROXY 协议和 HTTP 不兼容，不可混合。如果您在路由器前面使用负载均衡器，则必须使用 PROXY 协议或 HTTP。将一个协议配置为使用一个协议，另一个协议使用其他协议会导致路由失败。
3.4.3. 使用 PROXY 协议
默认情况下，HAProxy 路由器不使用 PROXY 协议。可以使用 ROUTER_USE_PROXY_PROTOCOL 环境变量配置路由器，以预期传入连接的 PROXY 协议：
启用 PROXY 协议
oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=true
$ oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=true
将变量设置为 true 或 TRUE 以外的任何值，以禁用 PROXY 协议：
禁用 PROXY 协议
oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=false
$ oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=false如果您在路由器中启用 PROXY 协议，则必须将路由器前面的负载均衡器配置为使用 PROXY 协议。以下是配置 Amazon Elastic Load Balancer(ELB)服务以使用 PROXY 协议的示例。本例假定 ELB 将端口 80(HTTP)、443(HTTPS)和 5000（镜像注册表）转发到一个或多个 EC2 实例上运行的路由器。
将 Amazon ELB 配置为使用 PROXY 协议
要简化后续步骤，首先设置一些 shell 变量：
lb='infra-lb' instances=( 'i-079b4096c654f563c' ) secgroups=( 'sg-e1760186' ) subnets=( 'subnet-cf57c596' )
$ lb='infra-lb'1 $ instances=( 'i-079b4096c654f563c' )2 $ secgroups=( 'sg-e1760186' )3 $ subnets=( 'subnet-cf57c596' )4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接下来，使用适当的监听程序、安全组和子网创建 ELB。
注意您必须将所有监听程序配置为使用 TCP 协议，而不是 HTTP 协议。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用 ELB 注册路由器实例或实例：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置 ELB 的健康检查：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最后，创建一个启用了
ProxyProtocol属性的负载均衡器策略，并在 ELB 的 TCP 端口 80 和 443 中配置它：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证配置
您可以按如下所示检查负载均衡器以验证配置是否正确：
或者，如果您已经配置了 ELB，但没有配置为使用 PROXY 协议，则需要更改 TCP 端口 80 的现有监听程序以使用 TCP 协议而不是 HTTP（TCP 端口 443 应已使用 TCP 协议）：
aws elb delete-load-balancer-listeners --load-balancer-name "$lb" \ --load-balancer-ports 80 aws elb create-load-balancer-listeners --load-balancer-name "$lb" \ --listeners 'Protocol=TCP,LoadBalancerPort=80,InstanceProtocol=TCP,InstancePort=80'
$ aws elb delete-load-balancer-listeners --load-balancer-name "$lb" \
--load-balancer-ports 80
$ aws elb create-load-balancer-listeners --load-balancer-name "$lb" \
--listeners 'Protocol=TCP,LoadBalancerPort=80,InstanceProtocol=TCP,InstancePort=80'验证协议更新
验证协议是否已更新，如下所示：
- 1
- 所有监听器（包括 TCP 端口 80 的监听器）都应使用 TCP 协议。
然后，创建一个负载均衡器策略，并将其添加到 ELB 中，如上一步第 5 步所述。
第 4 章 部署 Red Hat CloudForms
4.1.1. 简介
OpenShift Container Platform 安装程序包括 Ansible 角色 openshift-management， 以及用于在 OpenShift Container Platform 上部署 Red Hat CloudForms 4.6（CloudForms Management Engine 5.9 或 CFME）的 playbook。
当前实施与 Red Hat CloudForms 4.5 的技术预览部署过程不兼容，如 OpenShift Container Platform 3.6 文档 中所述。
在 OpenShift Container Platform 上部署 Red Hat CloudForms 时，需要做出两个主要决策：
- 您是否想要外部或容器化（也称为 podified）PostgreSQL 数据库？
- 哪个存储类将支持您的持久性卷(PV)？
对于第一个决定，您可以使用两种方式之一部署 Red Hat CloudForms，具体取决于 Red Hat CloudForms 使用的 PostgreSQL 数据库的位置：
| Deployment Variant | 描述 |
|---|---|
| 完全容器化 | 所有应用程序服务和 PostgreSQL 数据库都作为 pod 在 OpenShift Container Platform 上运行。 |
| 外部数据库 | 应用程序使用外部托管的 PostgreSQL 数据库服务器，所有其他服务则作为 pod 在 OpenShift Container Platform 上运行。 |
对于第二个决定，openshift-management 角色提供了覆盖许多默认部署参数的自定义选项。这包括以下存储类选项来支持 PV：
| Storage class | 描述 |
|---|---|
| NFS（默认） | 本地，在集群上 |
| NFS 外部 | NFS（如存储设备） |
| 云供应商 | 使用云供应商（Google Cloud Engine、Amazon Web Services 或 Microsoft Azure）的自动存储置备。 |
| 预配置（高级） | 假设您提前创建了所有内容 |
本指南的主题包括：在 OpenShift Container Platform 上运行 Red Hat CloudForms 的要求、可用配置变量的说明，以及在初始 OpenShift Container Platform 安装期间或置备集群之后运行安装程序的说明。
下表中列出了默认要求。可以通过 自定义模板参数 来覆盖它们。
如果无法满足这些要求，应用性能将会受到影响，甚至可能无法部署。
| 项 | 要求 | 描述 | 自定义参数 |
|---|---|---|---|
| 应用程序内存 | ≥ 4.0 Gi | 应用程序所需的最小内存 |
|
| 应用程序存储 | ≥ 5.0 Gi | 应用程序所需的最小 PV 大小 |
|
| PostgreSQL 内存 | ≥ 6.0 Gi | 数据库所需的最小内存 |
|
| PostgreSQL 存储 | ≥ 15.0 Gi | 数据库所需的最小 PV 大小 |
|
| 集群主机 | ≥ 3 | 集群中的主机数量 | N/A |
满足这些要求：
- 您必须具有几个集群节点。
- 您的集群节点必须具有大量可用内存。
- 您必须有多个 GiB 的可用存储，无论是本地还是云供应商。
- 可以通过为模板参数提供覆盖值来更改 PV 大小。
4.3. 配置角色变量
4.3.1. 概述
以下小节描述了 Ansible 清单文件中可能使用的角色变量，用于控制 运行安装程序 时红帽 CloudForms 安装的行为。
4.3.2. 常规变量
| 变量 | 必填 | 默认 | 描述 |
|---|---|---|---|
|
| 否 |
|
布尔值，设置为 |
|
| 是 |
|
要安装的红帽 CloudForms 的部署变体。为容器化数据库设置 |
|
| 否 |
| 红帽 CloudForms 安装的命名空间（项目） |
|
| 否 |
| 命名空间（项目）描述。 |
|
| 否 |
| 默认管理用户名。更改此值不会更改用户名；只有在您更改了名称并运行集成脚本（如 添加容器提供程序的脚本）时，才会更改此值。 |
|
| 否 |
| 默认管理密码。更改此值不会更改密码；只有在您更改了密码并且正在运行集成脚本（如用于 添加容器提供程序的脚本）时，才会更改此值。 |
4.3.3. 自定义模板参数
您可以使用 openshift_management_template_parameters Ansible 角色变量来指定要在应用程序或 PV 模板中覆盖的任何模板参数。
例如，如果要降低 PostgreSQL pod 的内存要求，您可以设置以下内容：
openshift_management_template_parameters={'POSTGRESQL_MEM_REQ': '1Gi'}
openshift_management_template_parameters={'POSTGRESQL_MEM_REQ': '1Gi'}
处理红帽 CloudForms 模板后，1Gi 将用于 POSTGRESQL_MEM_REQ 模板参数的值。
并非所有模板参数都存在于 两种 模板变体中（容器化或外部数据库）。例如，虽然 podified 数据库模板具有 POSTGRESQL_MEM_REQ 参数，但外部 db 模板中没有这样的参数，因为不需要此信息，因为没有要求 pod 的数据库。
因此，如果您要覆盖模板参数，请非常小心。包含模板中未定义的参数将导致错误。如果在 Ensure the Management App is created 任务期间收到错误，请在再次运行安装程序前先运行 卸载脚本。
4.3.4. 数据库变量
4.3.4.1. 容器化（pod）数据库
cfme-template.yaml 文件中任何 POSTGRES 模板参数都可以通过清单文件中的 _* 或DATABASE_*openshift_management_template_parameters 哈希进行自定义。
4.3.4.2. 外部数据库
cfme-template-ext-db.yaml 文件中的任何 POSTGRES _* 或 DATABASE_* 模板参数都可以通过清单文件中的 openshift_management_template_parameters 哈希进行自定义。
外部 PostgreSQL 数据库要求您提供数据库连接参数。您必须在清单中的 openshift_management_template_parameters 参数中设置所需的连接密钥。以下键是必需的：
-
DATABASE_USER -
DATABASE_PASSWORD -
DATABASE_IP -
DATABASE_PORT（大多数 PostgreSQL 服务器在端口5432上运行） -
DATABASE_NAME
确保您的外部数据库正在运行 PostgreSQL 9.5，或者您可能无法成功部署 CloudForms 应用。
您的清单将包含类似如下的行：
[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}
[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}- 1
- 将
openshift_management_app_template参数设置为cfme-template-ext-db。
4.3.5. 存储类变量
| 变量 | 必填 | 默认 | 描述 |
|---|---|---|---|
|
| 否 |
|
要使用的存储类型。选项包括 |
|
| 否 |
|
如果您使用的是外部 NFS 服务器，如 NetApp 设备，则必须在此处设置主机名。如果没有使用外部 NFS，则该值保留为 |
|
| 否 |
| 如果您使用外部 NFS，则可以在此处将基本路径设置为导出位置。对于本地 NFS，如果您要更改用于本地 NFS 导出的默认路径，您还可以更改此值。 |
|
| 否 |
|
如果您的清单中没有 |
4.3.5.1. NFS（默认）
NFS 存储类最适合概念验证和测试部署。它也是部署的默认存储类。选择时不需要额外的配置。
此存储类将集群主机上的 NFS（默认为清单文件中的第一个 master）配置为支持所需的 PV。应用需要一个 PV，而数据库（可能外部托管）可能需要一秒钟。Red Hat CloudForms 应用所需的最小 PV 大小为 5GiB，PostgreSQL 数据库为 15GiB（如果专用于 NFS，则为卷或分区上的最小可用空间为 20GiB）。
自定义通过以下角色变量提供：
-
openshift_management_storage_nfs_base_dir -
openshift_management_storage_nfs_local_hostname
4.3.5.2. NFS 外部
外部 NFS 依靠预先配置的 NFS 服务器为所需的 PV 提供导出。对于外部 NFS，您必须有一个 cfme-app 和可选的一个 cfme-db （容器化数据库）导出。
配置通过以下角色变量提供：
-
openshift_management_storage_nfs_external_hostname -
openshift_management_storage_nfs_base_dir
openshift_management_storage_nfs_external_hostname 参数必须设置为外部 NFS 服务器的主机名或 IP。
如果 /exports 不是您的导出的父目录，则必须通过 openshift_management_storage_nfs_base_dir 参数设置基础目录。
例如，如果您的服务器导出为 /exports/hosted/prod/cfme-app，则必须设置 openshift_management_storage_nfs_base_dir=/exports/hosted/prod。
4.3.5.3. 云供应商
如果您要将 OpenShift Container Platform 云供应商集成用于存储类，Red Hat CloudForms 也可以使用云供应商存储来支持其所需的 PV。要使此功能正常工作，您必须已配置了 openshift_cloudprovider_kind 变量（用于 AWS 或 GCE），以及特定于您所选云供应商的所有关联参数。
当使用此存储类创建应用程序时，需要使用配置的云供应商存储集成自动置备所需的 PV。
没有额外的变量可用于配置此存储类的行为。
4.3.5.4. 预配置（高级）
预配置 存储类意味着您准确知道您的操作，并且所有存储要求都已提前处理。通常，这意味着您已创建了正确大小的 PV。安装程序不会进行任何操作来修改任何存储设置。
没有额外的变量可用于配置此存储类的行为。
4.4. 运行安装程序
您可以选择在初始 OpenShift Container Platform 安装过程中或置备集群后部署 Red Hat CloudForms：
确定在清单文件
[OSEv3:vars]部分下的清单文件中将openshift_management_install_management设置为true：[OSEv3:vars] openshift_management_install_management=true
[OSEv3:vars] openshift_management_install_management=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 在清单文件中设置任何其他红帽 CloudForms 角色变量，如 配置角色变量 中所述。清单文件示例中提供了有助于执行此操作 的资源。
根据是否已置备 OpenShift Container Platform，选择要运行的 playbook:
- 如果要在安装 OpenShift Container Platform 集群的同时安装 Red Hat CloudForms，请调用标准 config.yml playbook，如 运行安装 Playbook 所述以开始 OpenShift Container Platform 集群和 Red Hat CloudForms 安装。
如果要在已置备的 OpenShift Container Platform 集群上安装 Red Hat CloudForms，请切换到 playbook 目录，并直接调用 Red Hat CloudForms playbook 开始安装：
cd /usr/share/ansible/openshift-ansible ansible-playbook -v [-i /path/to/inventory] \ playbooks/openshift-management/config.yml$ cd /usr/share/ansible/openshift-ansible $ ansible-playbook -v [-i /path/to/inventory] \ playbooks/openshift-management/config.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.2. 清单文件示例
以下小节演示了在 OpenShift Container Platform 中显示 Red Hat CloudForms 的各种配置的清单文件示例片段，可帮助您开始。
如需完整的变量描述，请参阅配置角色变量。
4.4.2.1. 所有默认值
本例最简单的方法是使用所有默认值和选项。这将实现完全容器化（指定）红帽 CloudForms 安装。所有应用程序组件以及 PostgreSQL 数据库都是在 OpenShift Container Platform 中创建的：
[OSEv3:vars] openshift_management_app_template=cfme-template
[OSEv3:vars]
openshift_management_app_template=cfme-template4.4.2.2. 外部 NFS 存储
如前例所示，除了在集群中使用本地 NFS 服务外，它使用的是现有的外部 NFS 服务器（如存储设备）。请注意两个新参数：
[OSEv3:vars] openshift_management_app_template=cfme-template openshift_management_storage_class=nfs_external openshift_management_storage_nfs_external_hostname=nfs.example.com
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_storage_class=nfs_external
openshift_management_storage_nfs_external_hostname=nfs.example.com 如果外部 NFS 主机在不同的父目录下导出目录，如 /exports/hosted/prod，请添加以下额外变量：
openshift_management_storage_nfs_base_dir=/exports/hosted/prod
openshift_management_storage_nfs_base_dir=/exports/hosted/prod4.4.2.3. 覆盖 PV 大小
这个示例覆盖持久性卷(PV)大小。PV 大小必须通过 openshift_management_template_parameters 设置，这样可确保应用程序和数据库能够在创建的 PV 上发出声明，而无需相互干扰：
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_VOLUME_CAPACITY': '10Gi', 'DATABASE_VOLUME_CAPACITY': '25Gi'}
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_VOLUME_CAPACITY': '10Gi', 'DATABASE_VOLUME_CAPACITY': '25Gi'}4.4.2.4. 覆盖内存要求
在测试或概念验证安装中，您可能需要降低应用程序和数据库内存要求，以符合您的容量。请注意，减少内存限值可能会导致性能降低或完全失败来初始化应用程序：
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_MEM_REQ': '3000Mi', 'POSTGRESQL_MEM_REQ': '1Gi', 'ANSIBLE_MEM_REQ': '512Mi'}
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_MEM_REQ': '3000Mi', 'POSTGRESQL_MEM_REQ': '1Gi', 'ANSIBLE_MEM_REQ': '512Mi'}
本例指示安装程序处理应用程序模板，参数 APPLICATION_MEM_REQ 设置为 3000Mi，POSTGRESQL_MEM_REQ 设置为 1Gi，ANSIBLE_MEM_REQ 设置为 512Mi。
这些参数可以和上一示例 覆盖 PV Sizes 中显示的参数结合使用。
4.4.2.5. 外部 PostgreSQL 数据库
要使用外部数据库，您必须将 openshift_management_app_template 参数值改为 cfme-template-ext-db。
此外，必须使用 openshift_management_template_parameters 变量提供数据库连接信息。如需了解更多详细信息，请参阅配置角色变量。
[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}
[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}确保您正在运行 PostgreSQL 9.5，或者您可能无法成功部署应用。
4.5. 启用容器提供程序集成
4.5.1. 添加单一容器提供程序
在 OpenShift Container Platform 上部署 Red Hat CloudForms 后，如 运行安装程序 所述，有两种方法可用于启用容器供应商集成。您可以将 OpenShift Container Platform 手动添加为容器供应商，也可以尝试使用此角色中包含的 playbook。
4.5.1.1. 手动添加
有关将 OpenShift Container Platform 集群手动添加为容器供应商的步骤，请参阅以下 Red Hat CloudForms 文档：
4.5.1.2. 自动添加
可以使用此角色中包含的 playbook 来完成自动化容器提供程序集成。
此 playbook：
- 收集所需的身份验证 secret。
- 查找指向红帽 CloudForms 应用程序和集群 API 的公共路由。
- 发出 REST 调用，以将 OpenShift Container Platform 集群添加为容器供应商。
进入 playbook 目录并运行容器供应商 playbook：
cd /usr/share/ansible/openshift-ansible
ansible-playbook -v [-i /path/to/inventory] \
openshift-management/add_container_provider.yml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
openshift-management/add_container_provider.yml4.5.2. 多个容器供应商
除了提供 playbook 以将当前 OpenShift Container Platform 集群集成到 Red Hat CloudForms 部署中，此角色包含一个脚本，允许您在任何任意红帽 CloudForms 服务器中添加多个容器平台作为容器供应商。容器平台可以是 OpenShift Container Platform 或 OpenShift Origin。
在运行 playbook 时，使用多个提供程序脚本需要在 CLI 上手动配置和设置 EXTRA_VARS 参数。
4.5.2.1. 准备脚本
要准备多个供应商脚本，请完成以下手动配置：
- 复制 /usr/share/ansible/openshift-ansible/roles/openshift_management/files/examples/container_providers.yml 示例，如 /tmp/cp.yml。您将修改此文件。
-
如果您更改了红帽 CloudForms 名称或密码，请更新您复制的 container_providers.yml 文件中的
management_server键中的hostname、user和password参数。 填写您要添加为容器供应商的每个容器平台集群的
container_providers键下的条目。必须配置以下参数：
-
auth_key- 这是具有cluster-admin权限的服务帐户的令牌。 -
hostname- 这是指向集群 API 的主机名。每个容器提供程序必须具有唯一的主机名。 -
name -这是要在红帽 CloudForms 服务器容器提供程序概览页面中显示的集群名称。这必须是唯一的。
提示从集群中获取
auth_keybearer 令牌：oc serviceaccounts get-token -n management-infra management-admin
$ oc serviceaccounts get-token -n management-infra management-adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
可选择性地配置以下参数：
-
port- 如果您的容器平台集群在8443之外的端口上运行 API，则更新此密钥。 -
endpoint- 您可以启用 SSL验证(verify_ssl)，或将验证设置更改为ssl-with-validation。目前不支持自定义可信 CA 证书。
-
4.5.2.1.1. 示例
例如，请考虑以下情况：
- 您可以将 container_providers.yml 文件复制到 /tmp/cp.yml。
- 您需要添加两个 OpenShift Container Platform 集群。
-
您的红帽 CloudForms 服务器在
mgmt.example.com上运行
在这种情况下，您将自定义 /tmp/cp.yml，如下所示：
4.5.2.2. 运行 Playbook
要运行 multi-providers 集成脚本，您必须提供容器提供程序配置文件的路径，作为 ansible-playbook 命令的 EXTRA_VARS 参数。使用 -e （或 --extra-vars）参数将 container_providers_config 设置为配置文件路径。进入 playbook 目录并运行 playbook:
cd /usr/share/ansible/openshift-ansible
ansible-playbook -v [-i /path/to/inventory] \
-e container_providers_config=/tmp/cp.yml \
playbooks/openshift-management/add_many_container_providers.yml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
-e container_providers_config=/tmp/cp.yml \
playbooks/openshift-management/add_many_container_providers.yml
playbook 完成后，您应在红帽 CloudForms 服务中找到两个新的容器提供程序。导航到 Compute → Containers → Providers 页面，查看概述。
4.5.3. 刷新供应商
添加单个或多个容器提供程序后，必须在红帽 CloudForms 中刷新新的提供程序，以获取关于容器提供程序和所管理容器的所有最新数据。这涉及导航到红帽 CloudForms Web 控制台中的各个提供程序，然后单击每个控制台的刷新按钮。
有关步骤，请参阅以下 Red Hat CloudForms 文档：
4.6. 卸载 Red Hat CloudForms
4.6.1. 运行卸载 Playbook
要从 OpenShift Container Platform 卸载并删除部署的 Red Hat CloudForms 安装，请切换到 playbook 目录并运行 uninstall.yml playbook:
cd /usr/share/ansible/openshift-ansible
ansible-playbook -v [-i /path/to/inventory] \
playbooks/openshift-management/uninstall.yml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
playbooks/openshift-management/uninstall.ymlNFS 导出定义和数据不会自动删除。在尝试初始化新部署之前，您必须手动从旧应用或数据库部署中清除任何数据。
4.6.2. 故障排除
无法擦除旧的 PostgreSQL 数据可能会导致级联错误，从而导致 postgresql pod 进入 crashloopbackoff 状态。这会阻止 cfme pod 启动。crashloopbackoff 的原因是，之前部署期间创建的数据库 NFS 导出的文件权限不正确。
要继续，请从 PostgreSQL 导出中删除所有数据，并删除 pod（而不是部署器 Pod）。例如，如果您有以下 pod：
然后，您将：
- 从数据库 NFS 导出中删除数据。
运行：
oc delete postgresql-1-6w2t4
$ oc delete postgresql-1-6w2t4Copy to Clipboard Copied! Toggle word wrap Toggle overflow
PostgreSQL 部署器容器集将尝试扩展新的 postgresql 容器集，以取代您删除的容器集。在 postgresql 容器集运行后，cfme 容器集将停止阻止并开始应用初始化。
第 5 章 Prometheus Cluster Monitoring
5.1. 概述
OpenShift Container Platform 附带一个预先配置和自我更新的监控堆栈，它基于 Prometheus 开源项目及其更广泛的生态系统。它提供对集群组件的监控，并附带一组警报，以便立即通知集群管理员任何出现的问题，以及一组 Grafana 仪表板。
上图中突出显示，监控堆栈的核心是 OpenShift Container Platform Cluster Monitoring Operator(CMO)，它监视部署的监控组件和资源，并确保它们始终保持最新状态。
Prometheus Operator (PO) 可以创建、配置和管理 Prometheus 和 Alertmanager 实例。还能根据熟悉的 Kubernetes 标签查询来自动生成监控目标配置。
除了 Prometheus 和 Alertmanager 外，OpenShift Container Platform 监控还包括 node-exporter 和 kube-state-metrics。node-exporter 是部署在每个节点上的代理，用于收集有关它的指标。kube-state-metrics 导出器代理将 Kubernetes 对象转换为 Prometheus 可使用的指标。
作为集群监控的一部分监控的目标有：
- Prometheus 本身
- Prometheus-Operator
- cluster-monitoring-operator
- Alertmanager 集群实例
- Kubernetes apiserver
- kubelet（kubelet 为每个容器指标嵌入 cAdvisor）
- kube-controllers
- kube-state-metrics
- node-exporter
- etcd（如果启用了 etcd 监控）
所有这些组件都会自动更新。
如需有关 OpenShift Container Platform Cluster Monitoring Operator 的更多信息，请参阅 Cluster Monitoring Operator GitHub 项目。
为了能够提供具有保证兼容性的更新，OpenShift Container Platform 监控堆栈的可配置性仅限于明确可用的选项。
5.2. 配置 OpenShift Container Platform 集群监控
OpenShift Container Platform Ansible openshift_cluster_monitoring_operator 角色使用清单文件中的变量配置和部署 Cluster Monitoring Operator。
| 变量 | 描述 |
|---|---|
|
|
如果为 |
|
|
每个 Prometheus 实例的持久性卷声明大小。只有在 |
|
|
每个 Alertmanager 实例的持久性卷声明大小。只有在 |
|
|
设置为所需的现有 节点选择器，以确保 pod 放置到具有特定标签的节点上。默认为 |
|
| 配置 Alertmanager。 |
|
|
启用 Prometheus 时间序列数据的持久性存储。默认将此变量设置为 |
|
|
启用 Alertmanager 通知和静默的持久性存储。默认将此变量设置为 |
|
|
如果启用了 |
|
|
如果启用了 |
5.2.1. 监控先决条件
监控堆栈会带来额外的资源需求。详情请查看计算资源建议。
5.2.2. 安装监控堆栈
监控堆栈默认安装有 OpenShift Container Platform。您可以防止安装它。为此，请在 Ansible 清单文件中将此变量设置为 false ：
openshift_cluster_monitoring_operator_install
您可以通过运行以下命令完成：
ansible-playbook [-i </path/to/inventory>] <OPENSHIFT_ANSIBLE_DIR>/playbooks/openshift-monitoring/config.yml \ -e openshift_cluster_monitoring_operator_install=False
$ ansible-playbook [-i </path/to/inventory>] <OPENSHIFT_ANSIBLE_DIR>/playbooks/openshift-monitoring/config.yml \
-e openshift_cluster_monitoring_operator_install=False
Ansible 目录的常用路径是 /usr/share/ansible/openshift-ansible/。在本例中，配置文件的路径为 /usr/share/ansible/openshift-ansible/playbooks/openshift-monitoring/config.yml。
5.2.3. 持久性存储
使用持久性存储运行集群监控意味着您的指标存储在 持久性卷中，并可在 Pod 重新启动或重新创建后保留。如果您需要预防指标或警报数据丢失，这是理想方案。在生产环境中，强烈建议您使用块存储技术配置永久存储。
5.2.3.1. 启用持久性存储
默认情况下，对于 Prometheus 时间序列数据和 Alertmanager 通知和静默禁用持久性存储。您可以将集群配置为永久存储其中任何一个或两者。
要启用 Prometheus 时间序列数据的持久性存储，请在 Ansible 清单文件中将此变量设置为
true：openshift_cluster_monitoring_operator_prometheus_storage_enabled要启用 Alertmanager 通知和静默的持久性存储，请在 Ansible 清单文件中将此变量设置为
true：openshift_cluster_monitoring_operator_alertmanager_storage_enabled
5.2.3.2. 确定需要多少存储
您需要的存储量取决于 Pod 的数目。管理员负责投入足够的存储来确保磁盘未满。如需有关持久性存储的系统要求的信息，请参阅 Cluster Monitoring Operator 的容量规划。
5.2.3.3. 设置持久性存储大小
要为 Prometheus 和 Alertmanager 指定持久性卷声明的大小，请更改这些 Ansible 变量：
-
openshift_cluster_monitoring_operator_prometheus_storage_capacity(default:50Gi) -
openshift_cluster_monitoring_operator_alertmanager_storage_capacity(default:2Gi)
只有将其对应的 storage_enabled 变量设置为 true 时，每个变量才会生效。
5.2.3.4. 分配充足的持久性卷
除非使用动态置备的存储，否则您需要确保 PVC 准备好声明持久性卷(PV)，每个副本一个 PV。Prometheus 有两个副本，Alertmanager 有三个副本，它们相当于五个 PV。
5.2.3.5. 启用动态置备的存储
您可以使用动态置备的存储，而不是静态置备的存储。详情请参阅动态卷置备。
要为 Prometheus 和 Alertmanager 启用动态存储，请在 Ansible 清单文件中将以下参数设置为 true ：
-
openshift_cluster_monitoring_operator_prometheus_storage_enabled(Default: false) -
openshift_cluster_monitoring_operator_alertmanager_storage_enabled(Default: false)
启用动态存储后，您还可以在 Ansible 清单文件中为每个组件设置存储类 ：
-
openshift_cluster_monitoring_operator_prometheus_storage_class_name(default: "") -
openshift_cluster_monitoring_operator_alertmanager_storage_class_name(default: "")
只有将其对应的 storage_enabled 变量设置为 true 时，每个变量才会生效。
5.2.4. 支持的配置
配置 OpenShift Container Platform Monitoring 的支持方法是使用本指南中介绍的选项进行配置。除了这些明确的配置选项外，还可以将其他配置注入到堆栈中。但不受支持，因为配置范例可能会在 Prometheus 发行版本间有所变化，只有在控制了所有可能的配置时，才能安全地应对这样的情况。
明确不支持的情形包括：
-
在
openshift-monitoring命名空间中创建额外的ServiceMonitor对象，从而扩展集群监控 Prometheus 实例提取的目标。这可能导致无法考量的冲突和负载差异，因此 Prometheus 设置可能会不稳定。 -
创建额外的
ConfigMap对象，导致集群监控 Prometheus 实例包含额外的警报和记录规则。请注意，如果应用此行为，这个行为会导致行为中断，因为 Prometheus 2.0 将附带新的规则文件语法。
5.3. 配置 Alertmanager
Alertmanager 管理传入的警报；这包括银级、禁止、聚合和通过电子邮件、PagerDuty 和 HipChat 等方法发送通知。
OpenShift Container Platform Monitoring Alertmanager 集群的默认配置是：
可以使用 openshift_cluster_monitoring_operator 角色中的 Ansible 变量 openshift_cluster_monitoring_operator_alertmanager_config 覆盖此配置。
以下示例将 PagerDuty 配置为通知。如需了解如何检索 service_key，请参阅 Alertmanager 的 PagerDuty 文档。
子路由仅匹配严重性为 critical 的警报，并使用名为 team-frontend-page 的接收器发送它们。如名称所示，对于关键警报，应传出某人。参阅 Alertmanager 配置来配置通过不同警报接收器发送警报。
5.3.1. 死人开关
OpenShift Container Platform Monitoring 附带了一个 死人开关，用于确保监控基础架构的可用性。
死人开关是始终触发的简单 Prometheus 警报规则。Alertmanager 持续向支持此功能的通知提供程序发送死人交换机的通知。这也可确保 Alertmanager 和通知提供程序之间的通信正常工作。
PagerDuty 支持这种机制，以在监控系统本身停机时发出警报。如需更多信息，请参阅下面的死人开关 PagerDuty。
5.3.2. 分组警报
在警报针对 Alertmanager 触发后，必须将其配置为了解如何在逻辑上分组它们。
在本例中，添加了一个新的路由来反映 frontend 团队的警报路由。
流程
添加新路由。可以在原始路由下添加多个路由，通常用于定义通知的接收方。以下示例使用匹配器来确保只使用来自服务
example-app的警报：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 子路由仅匹配严重性为
critical的警报，并使用名为team-frontend-page的接收器发送它们。如名称所示，对于关键警报，应传出某人。
5.3.3. 死人开关 PagerDuty
PagerDuty 通过名为 死人开关 的集成来支持此机制。只需将 PagerDuty 配置添加到默认的 deadmanswitch 接收器。使用上述流程添加此配置。
如果死人开关警报静默 15 分钟，将死人开关配置为页面运算符。使用默认的 Alertmanager 配置时，死人开关警报每五分钟重复一次。如果死人开关在 15 分钟后触发，这表明通知失败至少两次。
了解如何 为 PagerDuty 配置死人开关。
5.3.4. 警报规则
OpenShift Container Platform Cluster Monitoring 附带了以下默认配置的警报规则。目前无法添加自定义警报规则。
有些警报规则的名称相同。这是有意设计的。它们会警告同一事件，它们具有不同的阈值，或严重性不同。在禁止规则中，触发较高的严重性时会禁止较低严重性。
有关警报规则的详情，请查看配置文件。
| 警报 | 重要性 | 描述 |
|---|---|---|
|
|
| Cluster Monitoring Operator 会出现 X% 错误。 |
|
|
| Alertmanager 已从 Prometheus 目标发现中消失。 |
|
|
| ClusterMonitoringOperator 已从 Prometheus 目标发现中消失。 |
|
|
| KubeAPI 已从 Prometheus 目标发现中消失。 |
|
|
| kubecontrollermanager 已从 Prometheus 目标发现中消失。 |
|
|
| kubescheduler 已从 Prometheus 目标发现中消失。 |
|
|
| kubeStateMetrics 已从 Prometheus 目标发现中消失。 |
|
|
| kubelet 已从 Prometheus 目标发现中消失。 |
|
|
| NodeExporter 已从 Prometheus 目标发现中消失。 |
|
|
| Prometheus 已从 Prometheus 目标发现中消失。 |
|
|
| PrometheusOperator 已从 Prometheus 目标发现中消失。 |
|
|
| Namespace/Pod (Container) 重启 times / second |
|
|
| Namespace/Pod 未就绪。 |
|
|
| 部署 Namespace/Deployment 生成不匹配 |
|
|
| 部署 Namespace/Deployment 副本不匹配 |
|
|
| StatefulSet Namespace/StatefulSet 副本不匹配 |
|
|
| StatefulSet Namespace/StatefulSet 生成不匹配 |
|
|
| 只有调度并准备好用于守护进程设置 Namespace/DaemonSet 的所需 pod 的 X% |
|
|
| 没有调度 daemonset Namespace/DaemonSet 的 pod。 |
|
|
| 许多 daemonset Namespace/DaemonSet 的 pod 在不应该运行的位置运行。 |
|
|
| CronJob Namespace/CronJob 需要 1h 以上才能完成。 |
|
|
| Job Namespaces/Job 需要超过 1h 的时间才能完成。 |
|
|
| Job Namespaces/Job 无法完成。 |
|
|
| Pod 上过量使用的 CPU 资源请求无法容忍节点失败。 |
|
|
| Pod 上过量使用的内存资源请求，无法容忍节点失败。 |
|
|
| 命名空间上过量使用的 CPU 资源请求配额。 |
|
|
| 命名空间上过量使用的内存资源请求配额。 |
|
|
| 命名空间 Namespace 中的 X% 的资源已使用。 |
|
|
| 命名空间 Namespace 中的 PersistentVolumeClaim 声明的持久性卷有 X% free。 |
|
|
| 根据最近的抽样，命名空间 Namespace 中的 PersistentVolumeClaim 声明的持久性卷应该在四天内填满。X 字节当前可用。 |
|
|
| 节点 已就绪一小时以上 |
|
|
| 运行 X 种不同版本的 Kubernetes 组件。 |
|
|
| Kubernetes API 服务器客户端的 'Job/Instance' 正在遇到 X% 错误。 |
|
|
| Kubernetes API 服务器客户端的 'Job/Instance' 正在遇到 X 错误/ sec'。 |
|
|
| kubelet 实例正在运行 X pod，接近 110。 |
|
|
| API 服务器具有 99% 的 Verb 资源 延迟 X 秒。 |
|
|
| API 服务器具有 99% 的 Verb 资源 延迟 X 秒。 |
|
|
| API 服务器针对 X% 的请求出错。 |
|
|
| API 服务器针对 X% 的请求出错。 |
|
|
| Kubernetes API 证书将在不到 7 天后过期。 |
|
|
| Kubernetes API 证书将在不到 1 天后过期。 |
|
|
|
Summary：配置不同步.描述：Alertmanager 集群 |
|
|
| Summary：Alertmanager 的配置重新加载失败。描述：重新加载 Alertmanager 的配置对于 Namespace/Pod 失败。 |
|
|
| Summary：目标已停机。描述：X% 的作业 目标为 down。 |
|
|
| Summary：通知 DeadMansSwitch.描述：这是一个 DeadMansSwitch，可确保整个 Alerting 管道正常工作。 |
|
|
| node-exporter Namespace/Pod 的设备设备在接下来 24 小时内完全运行。 |
|
|
| node-exporter Namespace/Pod 的设备设备在接下来 2 小时内完全运行。 |
|
|
| Summary：重新载入 Prometheus 配置失败。描述：为 Namespace/Pod 重新载入 Prometheus 配置失败 |
|
|
| Summary：Prometheus 的警报通知队列已满运行。描述：Prometheus 的警报通知队列已完全针对 Namespace/Pod 运行 |
|
|
| Summary：从 Prometheus 发送警报时出错。描述：将警报从 Prometheus Namespace/Pod 发送到 Alertmanager 时出错 |
|
|
| Summary：从 Prometheus 发送警报时出错。描述：将警报从 Prometheus Namespace/Pod 发送到 Alertmanager 时出错 |
|
|
| Summary：Prometheus 没有连接到任何 Alertmanager。描述：Prometheus Namespace/Pod 没有连接到任何 Alertmanager |
|
|
| Summary：Prometheus 在从磁盘重新载入数据块时遇到问题。描述：在过去四个小时内，实例中的作业有 X 重新加载失败。 |
|
|
| Summary：Prometheus 在压缩示例块时遇到问题。描述：实例的作业过去四小时内出现 X 紧凑故障。 |
|
|
| Summary：Prometheus write-ahead 日志已被损坏。描述：Instance 中的 作业 具有损坏的 write-ahead 日志(WAL)。 |
|
|
| Summary：Prometheus 不捕获示例。描述：Prometheus Namespace/Pod 不嵌套示例。 |
|
|
| Summary：Prometheus 有许多示例被拒绝。描述：Namespace/Pod 因为时间戳重复但不同的值而拒绝多个示例 |
|
|
| Etcd 集群 "Job": insufficient members (X). |
|
|
| Etcd 集群 "Job": member Instance 没有 leader。 |
|
|
| Etcd 集群 "Job": 实例 Instance 在过去一小时内看到 X leader 改变。 |
|
|
| Etcd 集群 "Job":X% 的 GRPC_Method 请求在 etcd 实例 Instance 上失败。 |
|
|
| Etcd 集群 "Job":X% 的 GRPC_Method 请求在 etcd 实例 Instance 上失败。 |
|
|
| Etcd 集群 "Job": 到 GRPC_Method 的 gRPC 请求在 X_s on etcd instance _Instance。 |
|
|
| Etcd 集群 "Job": 成员与 To 通信正在 X_s on etcd instance _Instance。 |
|
|
| Etcd 集群 "Job":X 提议在 etcd 实例 Instance 的最后一小时内失败。 |
|
|
| Etcd 集群 "Job":99th percentile fync durations 是 X_s on etcd instance _Instance。 |
|
|
| Etcd 集群 "Job":99 percentile 的提交持续时间为 X_s on etcd instance _Instance。 |
|
|
| Job instance Instance 很快会耗尽其文件描述符 |
|
|
| Job instance Instance 很快会耗尽其文件描述符 |
5.4. 配置 etcd 监控
如果 etcd 服务没有正确运行，则整个 OpenShift Container Platform 集群的成功操作将处于危险之中。因此，最好为 etcd 配置监控。
按照以下步骤配置 etcd 监控 ：
流程
验证监控堆栈是否正在运行：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 打开集群监控堆栈的配置文件：
oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
config.yaml: |+下，添加etcd部分。如果在 master 节点上运行静态 pod 的
etcd，您可以使用选择器指定etcd节点：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果在单独的主机上运行
etcd，则需要使用 IP 地址指定节点：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果
etcd节点的 IP 地址有变化，您必须更新此列表。
验证
etcd服务监控器现在是否正在运行：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
etcd服务监控器。
etcd服务监控器最多可能需要一分钟才能启动。现在，您可以进入 Web 界面来查看有关
etcd监控状态的更多信息。要获取 URL，请运行：
oc -n openshift-monitoring get routes
$ oc -n openshift-monitoring get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD ... prometheus-k8s prometheus-k8s-openshift-monitoring.apps.msvistun.origin-gce.dev.openshift.com prometheus-k8s web reencrypt NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
使用
https，导航到为prometheus-k8s列出的 URL。登录。
确保该用户属于
cluster-monitoring-view角色。此角色提供查看集群监控 UI 的访问权限。例如，要将用户
developer添加到cluster-monitoring-view角色中，请运行：oc adm policy add-cluster-role-to-user cluster-monitoring-view developer
$ oc adm policy add-cluster-role-to-user cluster-monitoring-view developerCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
在 Web 界面中，以属于
cluster-monitoring-view角色的用户身份登录。 单击 Status，然后单击 Targets。如果您看到
etcd条目，则会监控etcd。虽然
etcd被监控，但 Prometheus 还无法通过etcd进行身份验证，因此无法收集指标数据。针对
etcd配置 Prometheus 身份验证：将
/etc/etcd/ca/ca.crt和/etc/etcd/ca/ca.key凭证文件从 master 节点复制到本地机器：ssh -i gcp-dev/ssh-privatekey cloud-user@35.237.54.213
$ ssh -i gcp-dev/ssh-privatekey cloud-user@35.237.54.213Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建包含以下内容的
openssl.cnf文件：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 生成
etcd.key私钥文件：openssl genrsa -out etcd.key 2048
$ openssl genrsa -out etcd.key 2048Copy to Clipboard Copied! Toggle word wrap Toggle overflow 生成
etcd.csr证书签名请求文件：openssl req -new -key etcd.key -out etcd.csr -subj "/CN=etcd" -config openssl.cnf
$ openssl req -new -key etcd.key -out etcd.csr -subj "/CN=etcd" -config openssl.cnfCopy to Clipboard Copied! Toggle word wrap Toggle overflow 生成
etcd.crt证书文件：openssl x509 -req -in etcd.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out etcd.crt -days 365 -extensions v3_req -extfile openssl.cnf
$ openssl x509 -req -in etcd.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out etcd.crt -days 365 -extensions v3_req -extfile openssl.cnfCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将凭证置于 OpenShift Container Platform 使用的格式：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这会创建 etcd-cert-secret.yaml 文件
将凭证文件应用到集群：
oc apply -f etcd-cert-secret.yaml
$ oc apply -f etcd-cert-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
现在您已配置了身份验证，请再次访问 Web 界面的 Targets 页面。验证
etcd现在是否正确监控。可能需要几分钟后更改才会生效。如果您希望在更新 OpenShift Container Platform 时自动更新
etcd监控，请将 Ansible 清单文件中的这个变量设置为true：openshift_cluster_monitoring_operator_etcd_enabled=true
openshift_cluster_monitoring_operator_etcd_enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您在单独的主机上运行
etcd，请按照 IP 地址使用此 Ansible 变量指定节点：openshift_cluster_monitoring_operator_etcd_hosts=[<address1>, <address2>, ...]
openshift_cluster_monitoring_operator_etcd_hosts=[<address1>, <address2>, ...]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果
etcd节点的 IP 地址改变，您必须更新此列表。
5.5. 访问 Prometheus、Alertmanager 和 Grafana。
OpenShift Container Platform Monitoring 附带了一个用于集群监控的 Prometheus 实例和一个中央 Alertmanager 集群。除了 Prometheus 和 Alertmanager 外，OpenShift Container Platform Monitoring 还包含一个 Grafana 实例，以及用于集群监控故障排除的预构建仪表板。由监控堆栈提供的 Grafana 实例及其仪表板是只读的。
获取用于访问 Prometheus、Alertmanager 和 Grafana Web UI 的地址：
流程
运行以下命令：
oc -n openshift-monitoring get routes
$ oc -n openshift-monitoring get routes NAME HOST/PORT alertmanager-main alertmanager-main-openshift-monitoring.apps._url_.openshift.com grafana grafana-openshift-monitoring.apps._url_.openshift.com prometheus-k8s prometheus-k8s-openshift-monitoring.apps._url_.openshift.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确保将
https://添加到这些地址。您无法使用未加密的连接访问 Web UI。-
根据 OpenShift Container Platform 身份进行身份验证，并使用与 OpenShift Container Platform 其他位置相同的凭证或验证方式。您必须使用具有所有命名空间的读取访问权限的角色，如
cluster-monitoring-view集群角色。
第 6 章 访问并配置 Red Hat Registry
6.1. 启用身份验证的 Red Hat Registry
Red Hat Container Catalog （registry.access.redhat.com)是一个托管的镜像 registry，通过它可以获得所需的容器镜像。OpenShift Container Platform 3.11 Red Hat Container Catalog 从 registry.access.redhat.com 移到 registry.redhat.io。
新的 registry（Registry.redhat.io）需要进行身份验证才能访问OpenShift Container Platform上的镜像及内容。当迁移到新registry后，现有的registry仍将在一段时间内可用。
OpenShift Container Platform从Registry.redhat.io中提取（pull）镜像，因此需要配置集群以使用它。
新registry使用标准的OAuth机制进行身份验证：
- 身份验证令牌。令牌（token）是服务帐户，由管理员生成。系统可以使用它们与容器镜像registry进行身份验证。服务帐户不受用户帐户更改的影响，因此使用令牌进行身份验证是一个可靠且具有弹性的方法。这是生产环境集群中唯一受支持的身份验证选项。
-
Web用户名和密码。这是用于登录到诸如
access.redhat.com之类的资源的标准凭据集。虽然可以在OpenShift Container Platform上使用此身份验证方法，但在生产环境部署中不支持此方法。此身份验证方法应该只限于在OpenShift Container Platform之外的独立项目中使用。
您可以在 docker login 中使用您的凭证（用户名和密码，或身份验证令牌）来访问新 registry 中的内容。
所有镜像流均指向新的registry。由于新 registry 需要进行身份验证才能访问，因此 OpenShift 命名空间中有一个名为 imagestreamsecret 的新机密。
您需要将凭据放在两个位置：
- OpenShift 命名空间 。您的凭据必须存在于 OpenShift 命名空间中，以便 OpenShift 命名空间中的镜像流可以导入。
- 您的主机。您的凭据必须存在于主机上，因为在抓取（pull）镜像时，Kubernetes会使用主机中的凭据。
访问新 registry:
-
验证镜像导入 secret(
imagestreamsecret)是否位于 OpenShift 命名空间中。该 secret 具有允许您访问新 registry 的凭证。 -
验证所有集群节点都有一个
/var/lib/origin/.docker/config.json，可以从 master 中复制，供您访问红帽 registry。
6.1.1. 创建用户帐户
如果您是有权使用红帽产品的红帽客户，则拥有具有适用用户凭证的帐户。这些是您用于登录到红帽客户门户的用户名和密码。
如果您没有帐户，可以通过注册以下选项之一获取免费帐户：
6.1.2. 为 Red Hat Registry 创建服务帐户和身份验证令牌
如果您的组织管理共享帐户，则必须创建令牌。管理员可以创建、查看和删除与组织关联的所有令牌。
先决条件
- 用户凭证
流程
要创建令牌以完成 docker login，请执行以下操作 ：
-
导航到
registry.redhat.io。 - 使用您的红帽网络(RHN)用户名和密码登录。
出现提示时接受条款.
- 如果未立即提示您接受条款，则在继续以下步骤时会提示您。
在 Registry Service Accounts 页面中点 Create Service Account
- 为服务帐户提供名称。它将带有一个随机字符串。
- 输入描述。
- 单击 create。
- 切回到您的服务帐户。
- 点您创建的服务帐户。
- 复制用户名，包括前缀字符串。
- 复制令牌。
6.1.3. 管理用于安装和升级的 registry 凭证
您还可以在安装过程中使用 Ansible 安装程序管理 registry 凭据。
这将设置以下内容：
-
OpenShift 命名空间中的
imagestreamsecret。 - 所有节点上的凭据。
当您将 registry.redhat.io 的默认值用于 openshift_examples_registryurl 或 oreg_url 时，Ansible 安装程序将需要凭证。
先决条件
- 用户凭证
- 服务帐户
- 服务帐户令牌
流程
要在安装过程中使用 Ansible 安装程序管理 registry 凭证：
-
在安装或升级过程中，指定安装程序清单中的
oreg_auth_user和oreg_auth_password变量。
如果您已创建了令牌，请将 oreg_auth_password 设置为令牌的值。
需要访问其他经过身份验证的 registry 的集群可以通过设置 openshift_additional_registry_credentials 来配置 registry 列表。每个 registry 都需要主机和密码值，您可以通过设置用户来指定用户名。默认情况下，通过尝试检查指定 registry 上的镜像 openshift3/ose-pod 来验证指定的凭证。
要指定备用镜像，请执行以下操作：
-
设置
test_image。 -
通过将
test_login设置为 False 来禁用凭据验证。
如果 registry 不安全，则将 tls_verify 设置为 False。
此列表中的所有凭据都将在 OpenShift 命名空间中创建 imagestreamsecret，并部署到所有节点的凭据。
例如：
openshift_additional_registry_credentials=[{'host':'registry.example.com','user':'name','password':'pass1','test_login':'False'},{'host':'registry2.example.com','password':'token12345','tls_verify':'False','test_image':'mongodb/mongodb'}]
openshift_additional_registry_credentials=[{'host':'registry.example.com','user':'name','password':'pass1','test_login':'False'},{'host':'registry2.example.com','password':'token12345','tls_verify':'False','test_image':'mongodb/mongodb'}]6.1.4. 在 Red Hat Registry 中使用服务帐户
在为 Red Hat Registry 创建服务帐户和生成的令牌后，您可以执行其他任务。
本节提供了手动步骤，可以通过提供 管理 registry Credentials for Installation 和 Upgrade 部分中概述的清单变量来自动执行这些步骤。
先决条件
- 用户凭证
- 服务帐户
- 服务帐户令牌
流程
在 Registry Service Accounts 页面中点击您的帐户名称。在这里，您可以执行以下任务：
- 在 Token Information 选项卡中，您可以查看您的用户名（您提供的带有随机字符串的名称）和密码（令牌）。在此选项卡中，您可以重新生成令牌。
在 OpenShift Secret 选项卡中，您可以：
- 单击选项卡中的链接，以下载该机密。
将 secret 提交到集群：
oc create -f <account-name>-secret.yml --namespace=openshift
# oc create -f <account-name>-secret.yml --namespace=openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
imagePullSecrets字段在 Kubernetes pod 配置中添加对 secret 的引用来更新 Kubernetes 配置，例如：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在 Docker Login 选项卡中，您可以运行
docker login。例如：docker login -u='<numerical-string|account-name>'
# docker login -u='<numerical-string|account-name>' -p=<token>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 成功登录后，将
~/.docker/config.json复制到/var/lib/origin/.docker/config.json，然后重新启动节点。cp -r ~/.docker /var/lib/origin/
# cp -r ~/.docker /var/lib/origin/ systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 Docker Configuration 选项卡中，您可以：
- 单击选项卡中的链接，下载凭据配置。
通过将文件放入 Docker 配置目录中，将配置写入到磁盘。这将覆盖现有的凭据。例如：
mv <account-name>-auth.json ~/.docker/config.json
# mv <account-name>-auth.json ~/.docker/config.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 7 章 Master 和节点配置
7.1. 安装后自定义 master 和节点配置
openshift start 命令（用于 master 服务器）和 Hyperkube 命令（用于节点服务器）采用一组有限的参数，足以在开发或实验环境中启动服务器。但是，这些参数不足以描述和控制生产环境中所需的整套配置和安全选项。
您必须在 master 配置文件(/etc/origin/master/master-config.yaml) 和 节点配置映射中提供这些选项。这些文件定义了选项，包括覆盖默认插件、连接到 etcd、自动创建服务帐户、构建镜像名称、自定义项目请求、配置卷插件等。
本节介绍了自定义 OpenShift Container Platform master 和节点主机的可用选项，并演示了如何在安装后更改配置。
在不使用默认值的情况下，将完全指定这些文件。因此，一个空值表示您要使用该参数的空值启动。这样可以轻松地说明您配置的确切原因，但也难以记住要指定的所有选项。为此，可以使用 --write-config 选项创建配置文件，然后与 --config 选项一起使用。
7.2. 安装依赖项
生产环境应该使用标准 集群安装 过程进行安装。在生产环境中，最好将 多个 master 用于 高可用性 (HA)。建议使用三个 master 的集群架构，并且推荐使用 HAproxy。
如果在 master 主机上 安装 etcd，则必须将集群配置为使用至少三个 master，因为 etcd 无法决定哪个是权威的。成功运行两个 master 的唯一方法是在 master 以外的主机上安装 etcd。
7.3. 配置主控机和节点
配置 master 和节点配置文件的方法必须与用于安装 OpenShift Container Platform 集群的方法匹配。如果您遵循标准 集群安装 过程，请在 Ansible 清单文件中进行配置更改。
7.4. 使用 Ansible 进行配置更改
对于本节，假设您熟悉 Ansible。
只有一部分可用的主机配置选项会 公开给 Ansible。安装 OpenShift Container Platform 后，Ansible 会使用一些替换的值创建一个清单文件。修改此清单文件并重新运行 Ansible 安装程序 playbook 是为了自定义 OpenShift Container Platform 集群。
虽然 OpenShift Container Platform 支持使用 Ansible playbook 和清单文件进行集群安装，但您也可以使用其他管理工具，如 Puppet、Chef 或 Salt。
使用案例：将集群配置为使用 HTPasswd 身份验证
- 此用例假定您已为 playbook 中引用的所有节点设置了 SSH 密钥。
htpasswd工具程序位于httpd-tools软件包中：yum install httpd-tools
# yum install httpd-toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
修改 Ansible 清单并进行配置更改：
- 打开 ./hosts 清单文件。
在文件的
[OSEv3:vars]部分添加以下新变量：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 对于 HTPasswd 身份验证，
openshift_master_identity_providers变量启用身份验证类型。您可以使用 HTPasswd 配置三个不同的身份验证选项：-
如果主机上已配置了
/etc/origin/master/htpasswd，则仅指定。openshift_master_identity_providers -
指定
openshift_master_identity_providers和openshift_master_htpasswd_file将本地 htpasswd 文件复制到主机。 -
指定
openshift_master_identity_providers和openshift_master_htpasswd_users，以在主机上生成新的 htpasswd 文件。
由于 OpenShift Container Platform 需要哈希密码来配置 HTPasswd 身份验证，因此您可以使用
htpasswd命令(如以下小结所述)为用户生成哈希密码，或使用用户和相关哈希密码创建平面文件。以下示例将身份验证方法从默认
拒绝所有设置到htpasswd，并使用指定的文件为jsmith和blob 用户可以生成用户 ID 和密码。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
如果主机上已配置了
重新运行 ansible playbook 以使这些修改生效：
ansible-playbook -b -i ./hosts ~/src/openshift-ansible/playbooks/deploy_cluster.yml
$ ansible-playbook -b -i ./hosts ~/src/openshift-ansible/playbooks/deploy_cluster.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow playbook 更新配置，并重启 OpenShift Container Platform master 服务以应用更改。
您现在已使用 Ansible 修改了 master 和节点配置文件，但这只是一个简单的用例。从此处您可以看到哪些 master 和 节点配置选项 公开给 Ansible，并自定义您自己的 Ansible 清单。
7.4.1. 使用 htpasswd 命令
要将 OpenShift Container Platform 集群配置为使用 HTPasswd 身份验证，您至少需要一个带有哈希密码的用户才能包含在 清单文件中。
您可以：
创建用户和散列密码：
运行以下命令来添加指定用户：
htpasswd -n <user_name>
$ htpasswd -n <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您可以包含
-b选项，用于在命令行中提供密码：htpasswd -nb <user_name> <password>
$ htpasswd -nb <user_name> <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入并确认用户的明文密码。
例如：
htpasswd -n myuser
$ htpasswd -n myuser New password: Re-type new password: myuser:$apr1$vdW.cI3j$WSKIOzUPs6QCopy to Clipboard Copied! Toggle word wrap Toggle overflow 该命令将生成散列版本的密码。
然后您可以在配置 HTPasswd 身份验证时使用哈希密码。hashed 密码是字符串，位于 : 后面。在上例中，请输入：
openshift_master_htpasswd_users={'myuser': '$apr1$wIwXkFLI$bAygtISk2eKGmqaJftB'}
openshift_master_htpasswd_users={'myuser': '$apr1$wIwXkFLI$bAygtISk2eKGmqaJftB'}创建带有用户名和散列密码的平面文件：
执行以下命令：
htpasswd -c /etc/origin/master/htpasswd <user_name>
$ htpasswd -c /etc/origin/master/htpasswd <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您可以包含
-b选项，用于在命令行中提供密码：htpasswd -c -b <user_name> <password>
$ htpasswd -c -b <user_name> <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入并确认用户的明文密码。
例如：
htpasswd -c /etc/origin/master/htpasswd user1 New password: Re-type new password: Adding password for user user1
htpasswd -c /etc/origin/master/htpasswd user1 New password: Re-type new password: Adding password for user user1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 命令会生成一个文件，其中包含用户名以及用户密码的散列版本。
然后，您可以在配置 HTPasswd 身份验证时使用密码文件。
如需有关 htpasswd 命令的更多信息，请参阅 HTPasswd 身份提供程序。
7.5. 进行手动配置更改
使用案例：配置集群以使用 HTPasswd 身份验证
手动修改配置文件：
- 打开您要修改的配置文件，本例中为 /etc/origin/master/master-config.yaml 文件：
将以下新变量添加到文件的
identityProviders小节中：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存您的更改并关闭该文件。
重启 master 以使更改生效：
master-restart api master-restart controllers
# master-restart api # master-restart controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
您现在已手动修改 master 和节点配置文件，但这只是一个简单的用例。在这里，您可以通过进行进一步的修改来查看所有 master 和节点配置选项，并进一步自定义自己的集群。
要修改集群中的节点，请根据需要更新节点配置映射。不要手动编辑 node-config.yaml 文件。
7.6. 主配置文件
本节介绍了 master-config.yaml 文件中提到的参数。
您可以 创建新的 master 配置文件 来查看已安装 OpenShift Container Platform 版本的有效选项。
每当修改 master-config.yaml 文件时，您必须重启 master 才能使更改生效。请参阅重启 OpenShift Container Platform 服务。
7.6.1. 准入控制配置
| 参数名称 | 描述 |
|---|---|
|
| 包含 准入插件 配置。OpenShift Container Platform 具有可在创建或修改 API 对象时触发的准入控制器插件的可配置列表。此选项允许您覆盖默认插件列表；例如，禁用一些插件、添加其他插件、更改顺序以及指定配置。插件及其配置列表都可从 Ansible 控制。 |
|
|
键值对将直接传递给与 API 服务器的命令行参数匹配的 Kube API 服务器。它们不会被迁移，但如果您引用了不存在服务器的值，则不会启动。这些值可能会覆盖 apiServerArguments: event-ttl: - "15m" |
|
|
键值对将直接传递给与控制器管理器的命令行参数匹配的 Kube 控制器管理器。它们不会被迁移，但如果您引用了不存在服务器的值，则不会启动。这些值可能会覆盖 |
|
|
用于启用或禁用各种准入插件。当此类型作为 |
|
| 允许为每个准入插件指定配置文件。 |
|
| master 上将安装的准入插件名称列表。订购非常显著。如果为空，则使用默认插件列表。 |
|
|
键值对将直接传递给与调度程序的命令行参数匹配的 Kube 调度程序。它们不会被迁移，但如果您引用了不存在服务器的值，则不会启动。这些值可能会覆盖 |
7.6.2. 资产配置
| 参数名称 | 描述 |
|---|---|
|
| 如果存在，则资产服务器会根据定义的参数启动。例如： |
|
|
要使用其他主机名从 web 应用访问 API 服务器，您必须通过将配置字段中的 corsAllowedOrigins 指定 |
|
| 不应启动的功能列表。您可能想将其设置为 null。不太可能每个人都希望手动禁用功能，不建议这样做。 |
|
| 从子上下文下资产服务器文件系统提供服务的文件。 |
|
| 当设置为 true 时，告诉资产服务器为每个请求重新载入扩展脚本和样式表，而不是只在启动时使用。它使您可以开发扩展，无需每次更改重启服务器。 |
|
|
key-(string)和 value-（字符串）对，这些对将注入到全局变量 |
|
| Web 控制台加载时，资产服务器文件中的文件路径作为脚本加载。 |
|
| Web 控制台加载时，资产服务器上的文件路径以作为风格的表加载。 |
|
| 用于日志记录的公共端点（可选）。 |
|
| 在登出 Web 控制台后将 Web 浏览器重定向到的一个可选的绝对 URL。如果未指定，则会显示内置注销页面。 |
|
| Web 控制台如何访问 OpenShift Container Platform 服务器。 |
|
| 指标的公共端点（可选）。 |
|
| 资产服务器的 URL。 |
7.6.3. 认证和授权配置
| 参数名称 | 描述 |
|---|---|
|
| 包含身份验证和授权配置选项。 |
|
| 指明应缓存多少个验证结果。如果为 0，则使用默认的缓存大小。 |
|
| 表示应缓存授权结果的时长。它接受有效的持续时间字符串（例如："5m").如果为空，则获得默认超时。如果为 0 (例如"0m"), 禁用缓存。 |
7.6.4. Controller 配置
| 参数名称 | 描述 |
|---|---|
|
|
应该启动的控制器列表。如果设置为 none，则不会自动启动任何控制器。默认值为 *，它将启动所有控制器。当使用 * 时，您可以通过在其名称前加上 |
|
|
启用控制器选择，指示 master 在控制器启动并在该值定义的秒数内尝试获取租期。将此值设置为非负值会强制 |
|
| 指示 master 不会自动启动控制器，而是等待接收通知到服务器，然后再启动它们。 |
7.6.5. etcd 配置
| 参数名称 | 描述 |
|---|---|
|
| advertised host:port 用于客户端连接到 etcd。 |
|
| 包含有关如何连接到 etcd 的信息。指定 etcd 是否作为嵌入式或非嵌入运行，以及主机。其余的配置由 Ansible 清单处理。例如： |
|
| 如果存在，etcd 会根据定义的参数启动。例如： |
|
| 包含 API 资源如何在 etcd 中存储的信息。这些值只有在 etcd 是集群的后备存储时才相关。 |
|
| etcd 中的路径，Kubernetes 资源将在其下作为根（root） 。如果更改，这个值将意味着 etcd 中的现有对象将不再存在。默认值为 kubernetes.io。 |
|
| etcd 中的 Kubernetes 资源应该被序列化为的 API 版本。当从 etcd 读取的集群的所有客户端都有相应的代码才能读取新版本时，这个值不应该为高级。 |
|
| OpenShift Container Platform 资源根到的 etcd 中的路径。如果更改，这个值将意味着 etcd 中的现有对象将不再存在。默认值为 openshift.io。 |
|
| etcd 中 OS 资源的 API 版本应序列化为。当从 etcd 读取的集群的所有客户端都有相应的代码才能读取新版本时，这个值不应该为高级。 |
|
| 到 etcd 的对等点连接的广告 host:port。 |
|
| 描述如何开始为 etcd peer 提供服务。 |
|
| 描述如何开始服务。例如： |
|
| etcd 存储目录的路径。 |
7.6.6. 授权配置
| 参数名称 | 描述 |
|---|---|
|
| 描述如何处理补贴。 |
|
| 自动批准客户端授权请求。 |
|
| 自动拒绝客户端授权请求。 |
|
| 提示用户批准新的客户端授权请求。 |
|
| 决定在 OAuth 客户端请求授权时使用的默认策略。只有特定的 OAuth 客户端不提供自己策略，则使用这种方法。有效的授权处理方法有：
|
7.6.7. 镜像配置
| 参数名称 | 描述 |
|---|---|
|
| 为系统组件构建的名称格式。 |
|
| 决定是否将从 registry 中拉取 latest 标签。 |
7.6.8. 镜像策略配置
| 参数名称 | 描述 |
|---|---|
|
| 允许禁用镜像的调度后台导入。 |
|
| 控制用户执行 Docker 存储库批量导入时导入的镜像数量。此数字默认为 5，以防止用户意外导入大量镜像。设置 -1 代表没有限制。 |
|
| 每分钟将在后台导入的最大调度镜像流数。默认值为 60。 |
|
| 针对上游存储库检查调度后台导入的镜像流时可达最少的秒数。默认值为 15 分钟。 |
|
| 限制普通用户可从中导入镜像的 Docker docker。将此列表设置为您信任包含有效 Docker 镜像且希望应用程序能够从中导入的 registry。有权通过 API 创建镜像或 ImageStreamMappings 的用户不受此策略的影响 - 通常只有管理员或系统集成将具有这些权限。 |
|
| 指定到 PEM 编码文件的文件路径，它列出了在镜像流导入期间应被信任的额外证书颁发机构。此文件需要可以被 API 服务器进程访问。根据集群安装的方式，这可能需要将文件挂载到 API 服务器 pod 中。 |
|
|
设置默认内部镜像 registry 的主机名。该值必须采用 |
|
|
ExternalRegistryHostname 设置默认外部镜像 registry 的主机名。只有在镜像 registry 对外公开时才应设置外部主机名。该值用于 ImageStreams 中的 |
7.6.9. Kubernetes 的主配置
| 参数名称 | 描述 |
|---|---|
|
| 应该在启动时启用的 API 级别的列表 v1 作为示例。 |
|
|
组映射到应禁用的版本（或 |
|
| 包含有关如何连接到 kubelet 的信息。 |
|
| 包含如何连接到 kubelet 的 KubernetesMasterConfig 的信息。如果存在，则使用此流程启动 kubernetes master。 |
|
| 应正在运行的预期 master 数量。这个值默认为 1，可以被设置为正整数，或者设置为 -1，这表示这是集群的一部分。 |
|
|
Kubernetes 资源的公共 IP 地址。如果为空，来自 |
|
| 描述如何将此节点连接到 master 的 .kubeconfig 文件的文件名。 |
|
|
控制删除失败节点上的 pod 的宽限期。它需要有效的持续时间字符串。如果为空，您会收到默认的 pod 驱除超时。默认值为 |
|
| 指定代理到 pod 时使用的客户端证书/密钥。例如： proxyClientInfo:
certFile: master.proxy-client.crt
keyFile: master.proxy-client.key
|
|
| 用于分配主机上服务公共端口的范围。默认 30000-32767。 |
|
| 用于分配服务 IP 的子网。 |
|
| 静态已知的节点列表。 |
7.6.10. 网络配置
仔细选择以下参数中的 CIDR，因为 IPv4 地址空间由节点的所有用户共享。OpenShift Container Platform 为自己的使用保留 IPv4 地址空间中的 CIDR，并为外部用户和集群间共享的地址保留来自 IPv4 地址空间的 CIDR。
| 参数名称 | 描述 |
|---|---|
|
| 指定全局覆盖网络的 L3 空间的 CIDR 字符串。这为集群网络的内部使用保留。 |
|
|
控制服务外部 IP 字段可接受哪些值。如果为空，则不能设置 |
|
| 分配给每一主机子网的位数。例如，8 表示主机上的 /24 网络。 |
|
|
控制为裸机上的类型为 LoadBalancer 的服务分配入口 IP 的范围。它可以包含从其中分配的一个 CIDR。默认情况下，配置了 |
|
| 分配给每一主机子网的位数。例如，8 表示主机上的 /24 网络。 |
|
| 传递给 compiled-in-network 的插件。此处的许多选项可以在 Ansible 清单中控制。
例如： |
|
| 要使用的网络插件的名称。 |
|
| 用于指定服务网络的 CIDR 字符串。 |
7.6.11. OAuth 身份验证配置
| 参数名称 | 描述 |
|---|---|
|
| 强制供应商选择页面，即使只有一个提供程序，也要呈现。 |
|
| 用于构建有效客户端重定向 URL 用于外部访问。 |
|
| 一个包含 go 模板的文件路径，用于在身份验证期间呈现错误页面，或授权流（如果没有指定），则会使用默认错误页面。 |
|
| 订购用户以识别自身的方式列表。 |
|
| 包含用来呈现登录页面的 go 模板的文件路径。如果未指定，则使用默认登录页面。 |
|
|
用于验证到 |
|
| 用于构建有效客户端重定向 URL 用于外部访问。 |
|
| 用于让服务器对服务器调用来交换访问令牌的授权代码。 |
|
| 如果存在，/oauth 端点会根据定义的参数启动。例如： |
|
| 允许自定义登录页面等页面。 |
|
| 包含用来呈现提供程序选择页面的 go 模板的文件路径。如果未指定，则使用默认供应商选择页面。 |
|
| 包含有关配置会话的信息。 |
|
| 允许您自定义登录页面等页面。 |
|
| 包含授权和访问令牌的选项。 |
7.6.12. 项目配置
| 参数名称 | 描述 |
|---|---|
|
| 包含默认项目节点选择器。 |
|
| 包含有关项目创建和默认值的信息：
|
|
| 当用户无法通过项目请求 API 端点来请求项目时向用户显示的字符串。 |
|
| 响应 projectrequest 以创建项目时使用的模板。它采用 namespace/template 格式，它是可选的。如果没有指定，则使用默认模板。 |
7.6.13. 调度程序配置
| 参数名称 | 描述 |
|---|---|
|
| 指向描述如何设置调度程序的文件。如果为空，您可以获得默认的调度规则 |
7.6.14. 安全分配器配置
| 参数名称 | 描述 |
|---|---|
|
|
定义将分配给命名空间的 MCS 类别范围。格式为 |
|
| 控制为项目自动分配 UID 和 MCS 标签。如果为 nil，则禁用分配。 |
|
| 定义会自动分配给项目的 Unix 用户 ID(UID)，以及每个命名空间获取的块的大小。例如，1000-1999/10 将根据每个命名空间分配十个 UID，并在用尽空间前分配最多 100 个块。默认值为在 10k 块中分配 10 亿到 20 亿的块（这是在用户命名空间启动后使用范围容器镜像的预期大小）。 |
7.6.15. 服务帐户配置
| 参数名称 | 描述 |
|---|---|
|
| 控制是否允许服务帐户在没有显式引用命名空间中引用任何 secret。 |
|
|
在每个命名空间中创建的服务帐户名称列表。如果没有指定名称，则不会启动 |
|
| 用于验证 TLS 连接到主主机的 CA。服务帐户控制器会自动将此文件的内容注入到 pod 中，以便它们能够验证与主控机的连接。 |
|
|
包含 PEM 编码私有 RSA 密钥的文件，用于签署服务帐户令牌。如果没有指定私钥，则不会启动服务帐户 |
|
| 文件列表，各自包含 PEM 编码的公共 RSA 密钥。如果有任何文件包含私钥，则使用密钥的公钥部分。公钥列表用于验证所提供的服务帐户令牌。每个密钥按顺序尝试，直到列表耗尽或验证成功为止。如果没有指定密钥，则不会使用服务帐户身份验证。 |
|
| 包含与服务帐户相关的选项：
|
7.6.16. 服务信息配置
| 参数名称 | 描述 |
|---|---|
|
| 允许主服务器上的 DNS 服务器以递归方式应答查询。请注意，打开解析器可用于 DNS 模糊攻击，并且主 DNS 不应该被公共网络访问。 |
|
| 要服务的 ip:port。 |
|
| 控制导入镜像的限值和行为。 |
|
| 包含 PEM 编码证书的文件。 |
|
| 用于提供安全流量的 TLS 证书信息。 |
|
| 您识别传入客户端证书的所有签名人的证书捆绑包。 |
|
| 如果存在，则根据定义的参数启动 DNS 服务器。例如： dnsConfig: bindAddress: 0.0.0.0:8053 bindNetwork: tcp4 |
|
| 包含域后缀。 |
|
| 包含 IP。 |
|
|
包含由 |
|
| 为用于连接 master 的客户端连接提供覆盖。这个参数不被支持。要设置 QPS 和 burst 值，请参阅设置节点 QPS 和 Burst 值。 |
|
| 允许到服务器的并发请求数。如果零，则不限制。 |
|
| 用于保护到特定主机名请求的证书列表。 |
|
| 请求超时前的秒数。默认值为 60 分钟。如果 -1，请求没有限制。 |
|
| 资产的 HTTP 服务信息。 |
7.6.17. 卷配置
| 参数名称 | 描述 |
|---|---|
|
| 启用或禁用动态置备的布尔值。默认为 true。 |
| FSGroup |
为每个 FSGroup 在每个节点上启用 本地存储配额。目前，这仅适用于 emptyDir 卷，如果底层 |
|
| 包含用于在 master 节点上配置卷插件的选项。 |
|
| 包含用于在节点上配置卷的选项。 |
|
| 包含用于在节点中配置卷插件的选项：
|
|
|
卷所在的目录。使用 |
7.6.18. 基本审计
审计提供一组安全相关的按时间排序的记录，记录各个用户、管理员或其他系统组件影响系统的一系列活动。
审计在 API 服务器级别运作，记录所有传入到服务器的请求。每个审计日志包含两个条目：
请求行中包含：
- 用于匹配响应行的唯一 ID（参见 #2）
- 请求的源 IP
- 被调用的 HTTP 方法
- 调用该操作的原始用户
-
操作的模拟用户（
self表示自己） -
操作的模拟组（
lookup表示用户的组） - 请求的命名空间或 <none>
- 请求的 URI
响应行中包括：
- #1 中的唯一 ID
- 响应代码
用户 admin 询问 pod 列表的输出示例：
AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" ip="127.0.0.1" method="GET" user="admin" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods" AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" response="200"
AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" ip="127.0.0.1" method="GET" user="admin" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods"
AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" response="200"7.6.18.1. 启用基本审计
以下流程在安装后启用基本审计。
高级审计必须在安装过程中启用。
编辑所有 master 节点上的 /etc/origin/master/master-config.yaml 文件，如下例所示：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重启集群中的 API pod。
/usr/local/bin/master-restart api
# /usr/local/bin/master-restart apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow
要在安装过程中启用基本审计，请在清单文件中添加以下变量声明。根据情况调整值。
openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/lib/origin/openpaas-oscp-audit.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5}
openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/lib/origin/openpaas-oscp-audit.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5}审计配置采用以下参数：
| 参数名称 | 描述 |
|---|---|
|
|
启用或禁用审计日志的布尔值。默认为 |
|
| 请求应记录到的文件路径。如果没有设置，日志会被输出到 master 日志中。 |
|
| 根据文件名中编码的时间戳，指定用于保留旧审计日志文件的最大天数。 |
|
| 指定要保留的旧审计日志文件的最大数量。 |
|
| 在轮转日志文件前，指定日志文件的最大大小（以 MB 为单位）。默认值为 100MB。 |
Audit 配置示例
当您定义 auditFilePath 参数时，如果该目录不存在，则会创建该目录。
7.6.19. 高级审计
高级审计功能对 基本审计功能 进行了一些改进，包括精细的事件过滤和多个输出后端。
要启用高级审计功能，您可以创建一个审计策略文件，并在 openshift_master_audit_config 和 openshift_master_audit_policyfile 参数中指定以下值：
openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/log/origin/audit-ocp.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5, "policyFile": "/etc/origin/master/adv-audit.yaml", "logFormat":"json"}
openshift_master_audit_policyfile="/<path>/adv-audit.yaml"
openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/log/origin/audit-ocp.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5, "policyFile": "/etc/origin/master/adv-audit.yaml", "logFormat":"json"}
openshift_master_audit_policyfile="/<path>/adv-audit.yaml"您必须在安装集群前创建 adv-audit.yaml 文件，并指定其在集群清单文件中的位置。
下表包含您可以使用的附加选项。
| 参数名称 | 描述 |
|---|---|
|
| 定义审计策略配置的文件的路径。 |
|
| 嵌入式审计策略配置。 |
|
|
指定保存的审计日志的格式。允许的值是 |
|
|
定义审计 Webhook 配置的 |
|
|
指定发送审计事件的策略。允许的值是 |
要启用高级审计功能，您必须提供 policyFile 或 policyConfiguration 描述审计规则：
Audit 策略配置示例
- 1 8
- 每个事件都可以记录四个可能级别：
-
None- 不记录与此规则匹配的日志事件。 -
Metadata- 日志请求元数据（请求用户、时间戳、资源、操作等），但不请求或响应正文。这与基本审计中使用的级别相同。 -
Request- 日志记录事件元数据和请求正文，但不包括响应的正文。 -
RequestResponse- 日志记录事件元数据、请求和响应正文。
-
- 2
- 适用于规则的用户列表。一个空列表表示每个用户。
- 3
- 此规则应用到的操作动词列表。一个空列表表示每个动词。这是与 API 请求关联的 Kubernetes 动词（包括
get,list,watch,create,update,patch,delete,deletecollection, 和proxy）。 - 4
- 适用于该规则的资源列表。一个空列表表示每个资源。每个资源都被指定为分配给的组（例如，Kubernetes 核心 API、批处理、build.openshift.io 等）的空项，以及该组中的资源列表。
- 5
- 适用于该规则的组列表。一个空列表表示每个组。
- 6
- 规则应用到的非资源 URL 列表。
- 7
- 适用于规则的命名空间列表。一个空列表表示每个命名空间。
- 9
- Web 控制台使用的端点。
- 10
- CLI 使用的端点。
如需有关高级审计的更多信息，请参阅 Kubernetes 文档
7.6.20. 为 etcd 指定 TLS 密码
您可以指定在 master 和 etcd 服务器之间的通信时使用的 支持的 TLS 密码。
在每个 etcd 节点上，升级 etcd：
yum update etcd iptables-services
# yum update etcd iptables-servicesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确认 etcd 版本为 3.2.22 或更高版本：
etcd --version
# etcd --version etcd Version: 3.2.22Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在每个 master 主机上，指定在
/etc/origin/master/master-config.yaml文件中启用的密码：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在每个 master 主机上，重启 master 服务：
master-restart api master-restart controllers
# master-restart api # master-restart controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确认应用了密码。例如，对于 TLSv1.2 密码
ECDHE-RSA-AES128-GCM-SHA256，请运行以下命令：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
etcd1.example.com是 etcd 主机的名称。
7.7. 节点配置文件
在安装过程中，OpenShift Container Platform 为每类节点组在 openshift-node 项目中创建一个 configmap：
- node-config-master
- node-config-infra
- node-config-compute
- node-config-all-in-one
- node-config-master-infra
若要对现有节点进行配置更改，请编辑相应的配置映射。各个节点上的 同步 pod 监视配置映射的变化。在安装过程中，使用 sync Daemonsets 和一个 /etc/origin/node/node-config.yaml 文件（节点的配置参数所在的文件）创建的同步 pod 被添加到每个节点。当同步 pod 检测到配置映射更改时，它会在该节点组的所有节点上更新 node-config.yaml，并在适当的节点上重启 atomic-openshift-node.service。
oc get cm -n openshift-node
$ oc get cm -n openshift-node输出示例
node-config-compute 组的配置映射示例
- 1
- 身份验证和授权配置选项.
- 2
- 附加到 pod 的 /etc/resolv.conf 的 IP 地址。
- 3
- 直接传递给与 Kubelet 命令行参数匹配的 Kubelet 的键值对。
- 4
- pod 清单文件或目录的路径。目录必须包含一个或多个清单文件。OpenShift 容器平台使用清单文件在节点上创建 pod。
- 5
- 节点上的 pod 网络设置。
- 6
- 软件定义型网络(SDN)插件.为 ovs-subnet 插件设置为
redhat/openshift-ovs-subnet，为 ovs-multitenant 插件设置为redhat/openshift-ovs-multitenant，为 ovs-networkpolicy 插件设置为redhat/openshift-ovs-networkpolicy。 - 7
- 节点的证书信息。
- 8
- 可选：PEM 编码的证书捆绑包。如果设置，则必须根据指定文件中的证书颁发机构显示并验证有效的客户端证书，然后才能检查请求标头中的用户名。
不要手动修改 /etc/origin/node/node-config.yaml 文件。
节点配置文件决定了节点的资源。如需更多信息，请参阅 Cluster Administrator 指南中的 Allocating node resources 部分。
7.7.1. Pod 和节点配置
| 参数名称 | 描述 |
|---|---|
|
| 完全指定的配置启动 OpenShift Container Platform 节点。 |
|
| 用于标识集群中的这个特定节点的值。如果可能，则这应该是您的完全限定主机名。如果您要描述一组静态节点到 master 节点，则这个值必须与列表中的其中一个值匹配。 |
7.7.2. Docker 配置
| 参数名称 | 描述 |
|---|---|
|
| 如果为 true，kubelet 将忽略 Docker 的错误。这意味着，节点可以在没有启动 docker 的机器上启动。 |
|
| 保留 Docker 相关配置选项 |
|
| 在容器中执行命令的处理程序。 |
7.7.3. 本地存储配置
您可以使用 XFS quota 子系统 基于 emptyDir 卷（如 secret 和配置映射）限制 emptyDir 卷和卷的大小。
要限制 XFS 文件系统中的 emptyDir 卷大小，使用 openshift-node 项目中的 node-config-compute 配置映射为每个唯一 FSGroup 配置本地卷配额。
apiVersion: kubelet.config.openshift.io/v1
kind: VolumeConfig
localQuota:
perFSGroup: 1Gi
apiVersion: kubelet.config.openshift.io/v1
kind: VolumeConfig
localQuota:
perFSGroup: 1Gi - 1
- 包含控制节点上本地卷配额的选项。
- 2
- 将此值设置为代表每个 [FSGroup] 的资源数量，每个节点（如
1Gi、512Mi等）。要求 volumeDirectory 位于通过grpquota选项挂载的 XFS 文件系统上。匹配的安全性上下文约束 fsGroup 类型 必须设为MustRunAs。
如果没有指定 FSGroup，这表示请求与 RunAsAny 的 SCC 匹配，则会跳过配额应用程序。
不要直接编辑 /etc/origin/node/volume-config.yaml 文件。该文件从 node-config-compute 配置映射创建。使用 node-config-compute 配置映射在 volume-config.yaml 文件中创建或编辑 paramaters。
7.7.4. 设置节点 Queries per Second (QPS) Limits 和 Burst 值
kubelet 与 API 服务器进行交互的频率取决于 qps 和 burst 值。如果每个节点上运行的 pod 有限，默认值就足够了。如果节点上有足够 CPU 和内存资源，可以在 /etc/origin/node/node-config.yaml 文件中调整 qps 和 burst 值：
kubeletArguments: kube-api-qps: - "20" kube-api-burst: - "40"
kubeletArguments:
kube-api-qps:
- "20"
kube-api-burst:
- "40"以上 qps 和 burst 值是 OpenShift Container Platform 的默认值。
| 参数名称 | 描述 |
|---|---|
|
|
Kubelet 与 APIServer 通信的 QPS 速率。默认值为 |
|
|
Kubelet 与 APIServer 通信的突发率。默认值为 |
|
| 在容器中执行命令的处理程序。 |
7.7.5. 使用 Docker 1.9+ 并行镜像拉取(pull)
如果使用 Docker 1.9+，您可能需要考虑启用并行镜像拉取，因为默认值是一次拉取镜像。
Docker 1.9 之前的数据损坏潜在的问题。但是，从 1.9 开始，崩溃问题已解决，它可以安全地切换到并行拉取。
kubeletArguments: serialize-image-pulls: - "false"
kubeletArguments:
serialize-image-pulls:
- "false" - 1
- 更改为
true以禁用并行拉取。这是默认配置。
7.8. 密码和其他敏感数据
对于一些身份验证配置，需要一个 LDAP bindPassword 或 OAuth clientSecret 值。这些值不是直接在主配置文件中指定，而是以环境变量、外部文件或加密文件形式提供。
环境变量示例
bindPassword:
env: BIND_PASSWORD_ENV_VAR_NAME
bindPassword:
env: BIND_PASSWORD_ENV_VAR_NAME外部文件示例
bindPassword:
file: bindPassword.txt
bindPassword:
file: bindPassword.txt加密的外部文件示例
bindPassword:
file: bindPassword.encrypted
keyFile: bindPassword.key
bindPassword:
file: bindPassword.encrypted
keyFile: bindPassword.key为以上示例创建加密的文件和密钥文件：
oc adm ca encrypt --genkey=bindPassword.key --out=bindPassword.encrypted Data to encrypt: B1ndPass0rd!
$ oc adm ca encrypt --genkey=bindPassword.key --out=bindPassword.encrypted
> Data to encrypt: B1ndPass0rd!
仅从 Ansible 主机清单文件中列出的第一个 master 运行 oc adm 命令，默认为 /etc/ansible/hosts。
加密的数据仅像解密密钥一样安全。请小心谨慎，以限制文件系统权限和对密钥文件的访问。
7.9. 创建新配置文件
从头开始定义 OpenShift Container Platform 配置时，请先创建新的配置文件。
对于 master 主机配置文件，使用 openshift start 命令和 --write-config 选项来写入配置文件。对于节点主机，使用 oc adm create-node-config 命令写入配置文件。
以下命令将相关的启动配置文件、证书文件和任何其他必要的文件写入指定的 --write-config 或 --node-dir 目录。
生成的证书文件在两年内有效，而证书颁发机构(CA)证书在五年内有效。这可以通过 --expire-days 和 --signer-expire-days 选项进行修改，但为了安全起见，建议您不要使其大于这些值。
在指定目录中为一体化服务器（master 和一个节点）创建配置文件：
openshift start --write-config=/openshift.local.config
$ openshift start --write-config=/openshift.local.config要在指定目录中创建 master 配置文件和其他所需的文件：
openshift start master --write-config=/openshift.local.config/master
$ openshift start master --write-config=/openshift.local.config/master在指定目录中创建节点配置文件和其他相关文件：
在创建节点配置文件时，--hostnames 选项接受以逗号分隔的每个主机名或 IP 地址列表，用于有效服务器证书。
7.10. 使用配置文件启动服务器
将主控机和节点配置文件修改为您的规格后，您可以在启动服务器时将它们指定为参数来使用。如果您指定配置文件，则您传递的其他命令行选项都不会被遵守。
要修改集群中的节点，请根据需要更新节点配置映射。不要手动编辑 node-config.yaml 文件。
使用 master 配置文件启动 master 服务器：
openshift start master \ --config=/openshift.local.config/master/master-config.yaml$ openshift start master \ --config=/openshift.local.config/master/master-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用节点配置文件和 node.kubeconfig 文件启动网络代理和 SDN 插件：
openshift start network \ --config=/openshift.local.config/node-<node_hostname>/node-config.yaml \ --kubeconfig=/openshift.local.config/node-<node_hostname>/node.kubeconfig$ openshift start network \ --config=/openshift.local.config/node-<node_hostname>/node-config.yaml \ --kubeconfig=/openshift.local.config/node-<node_hostname>/node.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用节点配置文件启动节点服务器：
hyperkube kubelet \ $(/usr/bin/openshift-node-config \ --config=/openshift.local.config/node-<node_hostname>/node-config.yaml)$ hyperkube kubelet \ $(/usr/bin/openshift-node-config \ --config=/openshift.local.config/node-<node_hostname>/node-config.yaml)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.11. 查看 Master 和节点日志
OpenShift Container Platform 使用 systemd-journald.service 作为节点和名为 master-logs 的脚本，为 master 收集调试的日志消息。
web 控制台中显示的行的数量在 5000 中被硬编码，且无法更改。要查看整个日志，可使用 CLI。
日志记录根据 Kubernetes 日志记录惯例使用五个日志消息，如下所示：
| 选项 | 描述 |
|---|---|
| 0 | 仅限错误和警告 |
| 2 | 普通信息 |
| 4 | 调试级别信息 |
| 6 | API 级调试信息（请求/响应） |
| 8 | 正文级别 API 调试信息 |
您可以根据需要 更改独立于 master 或节点的日志级别。
查看节点日志
要查看节点系统的日志，请运行以下命令：
journalctl -r -u <journal_name>
# journalctl -r -u <journal_name>
使用 -r 选项显示最新的条目。
查看 master 日志
要查看 master 组件的日志，请运行以下命令：
/usr/local/bin/master-logs <component> <container>
# /usr/local/bin/master-logs <component> <container>例如：
/usr/local/bin/master-logs controllers controllers /usr/local/bin/master-logs api api /usr/local/bin/master-logs etcd etcd
# /usr/local/bin/master-logs controllers controllers
# /usr/local/bin/master-logs api api
# /usr/local/bin/master-logs etcd etcd将 master 日志重定向到文件
要将 master 日志的输出重定向到文件，请运行以下命令：
master-logs api api 2> file
master-logs api api 2> file7.11.1. 配置日志记录级别
您可以通过在 master 或 /etc/sysconfig/atomic-openshift-node 文件中的 /etc/origin/master/master.env 文件中设置 DEBUG_LOGLEVEL 选项来控制哪些 INFO 信息。将日志配置为收集所有信息可能会导致大型日志被解释，并可能会占用过量空间。仅在需要调试集群时收集所有消息。
不论日志配置是什么，日志中会出现带有 FATAL、ERROR、WARNING 和一些 INFO 严重性的消息。
更改日志记录级别：
- 编辑 master 或 /etc/sysconfig/atomic-openshift-node 文件的 /etc/origin/master/master.env 文件。
在
DEBUG_LOGLEVEL字段中，输入 Log Level Options 表中的值。例如：
DEBUG_LOGLEVEL=4
DEBUG_LOGLEVEL=4Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 根据需要重启 master 或节点主机。请参阅重启 OpenShift Container Platform 服务。
重启后，所有新日志消息均符合新设置。旧的消息不会更改。
可以使用标准集群安装过程来设置默认日志级别。如需更多信息，请参阅 集群变量。
以下示例是不同日志级别重定向的主日志文件的摘录。已从这些示例中删除系统信息。
loglevel=2 的 master-logs api api 2> 文件 输出摘录
loglevel=4 的 master-logs api api 2> 文件 输出摘录
loglevel=8 中的 master-logs api api 2> 文件 输出摘录
7.12. 重启 master 和节点服务
要应用 master 或节点配置更改，您必须重启相应的服务。
要重新载入 master 配置更改，请使用 master-restart 命令重启在 control plane 静态 pod 中运行的主服务：
master-restart api master-restart controllers
# master-restart api
# master-restart controllers要重新载入节点配置更改，重启节点主机上的节点服务：
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-node第 8 章 OpenShift Ansible Broker 配置
8.1. 概述
当在集群中部署 OpenShift Ansible 代理 (OAB)时，其行为主要由代理在启动时加载的配置文件决定。代理的配置作为 ConfigMap 对象存储在代理的命名空间中（默认为openshift-ansible-service-broker ）。
OpenShift Ansible Broker 配置文件示例
8.2. 在 Red Hat Partner Connect Registry 进行身份验证
在配置 Automation Broker 前，您必须在 OpenShift Container Platform 集群的所有节点上运行以下命令，才能使用 Red Hat Partner Connect：
docker --config=/var/lib/origin/.docker login -u <registry-user> -p <registry-password> registry.connect.redhat.com
$ docker --config=/var/lib/origin/.docker login -u <registry-user> -p <registry-password> registry.connect.redhat.com8.3. 修改 OpenShift Ansible Broker 配置
在部署后修改 OAB 的默认代理配置：
以具有 cluster-admin 权限的用户身份编辑 OAB 命名空间中的 broker-config ConfigMap 对象：
oc edit configmap broker-config -n openshift-ansible-service-broker
$ oc edit configmap broker-config -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 保存任何更新后，请重新部署 OAB 的部署配置以使更改生效：
oc rollout latest dc/asb -n openshift-ansible-service-broker
$ oc rollout latest dc/asb -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. Registry 配置
registry 部分允许您定义代理应该用于 APB 的 registry。
| 字段 | 描述 | 必填 |
|---|---|---|
|
| registry 的名称。代理用来识别来自此 registry 的 APB。 | Y |
|
|
用于向 registry 进行身份验证的用户名。当 | N |
|
|
用于向 registry 进行身份验证的密码。当 | N |
|
|
如果没有通过 | N |
|
|
存储应读取的 registry 凭证的机密或文件的名称。将 |
N，仅当 |
|
| 镜像中包含的命名空间或机构。 | N |
|
|
registry 的类型。可用的适配器有 | Y |
|
|
用于配置 | N |
|
|
用于检索镜像信息的 URL。适用于 RHCC 的广泛使用，而 | N |
|
| 此 registry 失败，如果失败 bootstrap 请求。将停止执行其他 registry 加载。 | N |
|
|
用于定义应允许哪些镜像名称的正则表达式列表。必须有一个白名单，才能将 APB 添加到目录中。如果要检索 registry 中的所有 APB，您可以使用的最宽松的正则表达式为 | N |
|
| 用于定义应不允许哪些镜像名称的正则表达式列表。如需了解更多详细信息，请参阅 APB 过滤。 | N |
|
| 要与 OpenShift Container Registry 搭配使用的镜像列表。 | N |
8.4.1. 生产或开发
一个生产环境代理配置设计为指向可信容器分发 registry，如 Red Hat Container Catalog(RHCC)：
但是，开发 代理配置主要供使用代理的开发人员使用。要启用开发人员设置，将 registry 名称设置为 dev，并将 broker 部分中的 dev_broker 字段设置为 true ：
registry: name: dev
registry:
name: devbroker: dev_broker: true
broker:
dev_broker: true8.4.2. 存储 registry 凭证
代理配置决定了代理应该如何读取任何 registry 凭证。它们可以从 registry 中的 user 和 pass 值读取，例如：
如果要确保这些凭据不可公开访问，registry 部分中的 auth_type 字段可以设置为 secret 或 file 类型。secret 类型将 registry 配置为使用代理命名空间中的 secret，而 file 类型将 registry 配置为使用已挂载为卷的 secret。
使用 secret 或 file 类型 ：
关联的机密应定义值
用户名和密码。在使用 secret 时，您必须确保openshift-ansible-service-broker命名空间存在，因为这是从中读取 secret 的位置。例如，创建一个 reg-creds.yaml 文件：
cat reg-creds.yaml --- username: <user_name> password: <password>
$ cat reg-creds.yaml --- username: <user_name> password: <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 从
openshift-ansible-service-broker命名空间中的此文件创建 secret：oc create secret generic \ registry-credentials-secret \ --from-file reg-creds.yaml \ -n openshift-ansible-service-broker$ oc create secret generic \ registry-credentials-secret \ --from-file reg-creds.yaml \ -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 选择是否要使用
secret或file类型 ：使用
secret类型：在代理配置中，将
auth_type设置为secret，auth_name设置为 secret 的名称：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 设置 secret 所在的命名空间：
openshift: namespace: openshift-ansible-service-broker
openshift: namespace: openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
使用
file类型：编辑
asb部署配置，将文件挂载到 /tmp/registry-credentials/reg-creds.yaml 中：oc edit dc/asb -n openshift-ansible-service-broker
$ oc edit dc/asb -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
containers.volumeMounts部分添加：volumeMounts: - mountPath: /tmp/registry-credentials name: reg-authvolumeMounts: - mountPath: /tmp/registry-credentials name: reg-authCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
volumes部分，添加：volumes: - name: reg-auth secret: defaultMode: 420 secretName: registry-credentials-secretvolumes: - name: reg-auth secret: defaultMode: 420 secretName: registry-credentials-secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在代理配置中，将
auth_type设置为file，并将auth_type设置为文件的位置：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.3. APB 过滤
APB 可使用 white_list 或 black_list 参数的组合（根据代理配置中的 registry）组合来筛选其镜像名称。
这两者都是可选的正则表达式列表，这些表达式将在给定 registry 的总发现的 APB 中运行，以确定匹配项。
| 存在 | 允许 | 阻塞 |
|---|---|---|
| 只有白名单 | 匹配列表中的正则表达式。 | 任何不匹配的 APB。 |
| 只有黑名单 | 所有不匹配的 APB。 | 与列表中正则表达式匹配的 APB。 |
| 两者都存在 | 匹配白名单中的正则表达式，当不在黑名单中。 | 与黑名单中的正则表达式匹配的 APB。 |
| 无 | 没有来自 registry 的 APB。 | 来自该 registry 的所有 APB。 |
例如：
仅有白名单
white_list: - "foo.*-apb$" - "^my-apb$"
white_list:
- "foo.*-apb$"
- "^my-apb$"
对于 foo.*-apb$ 的任何匹配，在这种情况下，仅允许使用 my-apb。所有其他 APB 都会被拒绝。
仅有黑名单
black_list: - "bar.*-apb$" - "^foobar-apb$"
black_list:
- "bar.*-apb$"
- "^foobar-apb$"
任何与 bar.*-apb$ 以及本例中只有 foobar-apb 的匹配都会被阻断。所有其他 APB 都将被允许。
白名单和黑名单
white_list: - "foo.*-apb$" - "^my-apb$" black_list: - "^foo-rootkit-apb$"
white_list:
- "foo.*-apb$"
- "^my-apb$"
black_list:
- "^foo-rootkit-apb$"
此处，foo-rootkit-apb 由黑名单明确阻止，尽管白名单匹配会被覆盖。
否则，只允许与 foo.*-apb$ 和 my-apb 匹配的通过。
代理配置 registry 示例部分：
8.4.4. 模拟 Registry
模拟 registry 有助于读取本地 APB 规格。这使用的是本地 spec 列表，而不是通过 registry 搜索镜像规格。将 registry 的名称设置为 mock 以使用模拟 registry。
registry:
- name: mock
type: mock
registry:
- name: mock
type: mock8.4.5. Dockerhub Registry
dockerhub 类型允许您从 DockerHub 中的特定机构加载 APB。例如，ansibleplaybookbundle 组织。
8.4.6. Ansible Galaxy Registry
galaxy 类型允许您使用 Ansible Galaxy 的 APB 角色。您还可以选择指定机构。
8.4.7. 本地 OpenShift Container Registry
通过使用 local_openshift 类型，您可以从 OpenShift Container Platform 集群内部的 OpenShift Container Registry 加载 APB。您可以配置您要在其中查找公布的 APB 的命名空间。
8.4.8. Red Hat Container Catalog Registry
使用 rhcc 类型将允许您加载发布到 Red Hat Container Catalog (RHCC)registry 中的 APB。
8.4.9. Red Hat Partner Connect Registry
Red Hat Container Catalog 中的第三方镜像是从 Red Hat 合作伙伴 Connect Registry 提供的，地址为 https://registry.connect.redhat.com。partner_rhcc 类型允许代理从合作伙伴注册表引导，以检索 APB 列表并加载其 spec。合作伙伴 Registry 需要身份验证才能使用有效的红帽客户门户网站用户名和密码拉取镜像。
由于合作伙伴 registry 需要身份验证，因此还需要以下手动步骤来配置代理以使用合作伙伴 Registry URL：
在 OpenShift Container Platform 集群的所有节点上运行以下命令：
docker --config=/var/lib/origin/.docker \ login -u <registry_user> -p <registry_password> \ registry.connect.redhat.com# docker --config=/var/lib/origin/.docker \ login -u <registry_user> -p <registry_password> \ registry.connect.redhat.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.10. Helm Chart Registry
使用 helm 类型时，您可以使用 Helm Chart 仓库中的 Helm Chart。
stable 存储库中的许多 Helm chart 不适用于 OpenShift Container Platform，如果使用它们，则会失败。
8.4.11. API V2 Docker Registry
通过使用 apiv2 类型，您可以使用 Docker Registry HTTP API V2 协议的 docker registry 中的镜像。
如果 registry 需要身份验证来拉取镜像，这可以通过在现有集群的每个节点中运行以下命令来实现：
docker --config=/var/lib/origin/.docker login -u <registry-user> -p <registry-password> <registry_url>
$ docker --config=/var/lib/origin/.docker login -u <registry-user> -p <registry-password> <registry_url>8.4.12. Quay Docker Registry
使用 quay 类型可以加载发布到 CoreOS Quay Registry 的 APB。如果提供了身份验证令牌，则将加载令牌配置为访问的专用存储库。指定机构中的公共存储库不需要令牌来加载。
如果 Quay registry 需要身份验证来拉取镜像，这可通过在现有集群的每个节点中运行以下命令来实现：
docker --config=/var/lib/origin/.docker login -u <registry-user> -p <registry-password> quay.io
$ docker --config=/var/lib/origin/.docker login -u <registry-user> -p <registry-password> quay.io8.4.13. 多个 registry
您可以使用多个 registry 将 APB 分开到逻辑机构中，并从同一代理管理它们。registry 必须具有唯一的非空名称。如果没有唯一名称，则服务代理将失败，并显示出错信息警报。
8.5. 代理身份验证
代理支持身份验证，这意味着连接到代理时，调用者必须提供每个请求的 Basic Auth 或 Bearer Auth 凭证。使用 curl，它像提供一样简单：
-u <user_name>:<password>
-u <user_name>:<password>或者
-h "Authorization: bearer <token>
-h "Authorization: bearer <token>至命令。服务目录必须配置有包含用户名和密码组合的 secret 或 bearer 令牌的 secret。
8.5.1. 基本验证
要启用 Basic Auth 使用，在代理配置中设置以下内容：
broker:
...
auth:
- type: basic
enabled: true
broker:
...
auth:
- type: basic
enabled: true 8.5.1.1. 部署模板和 Secret
通常，代理是使用部署模板中的 ConfigMap 进行配置。您提供身份验证配置的方式与文件配置文件中相同。
以下是部署模板的示例：
auth:
- type: basic
enabled: ${ENABLE_BASIC_AUTH}
auth:
- type: basic
enabled: ${ENABLE_BASIC_AUTH}Basic Auth 的另一个部分是用于向代理进行身份验证的用户名和密码。虽然基本 Auth 实施可以由不同的后端服务提供支持，但当前支持的一个 secret 由 secret 提供支持。secret 必须通过卷挂载（在 /var/run/asb_auth 位置）注入 pod。这是代理读取用户名和密码的位置。
在 部署模板 中，必须指定 secret。例如：
secret 必须包含用户名和密码。值必须采用 base64 编码。为这些条目生成值的最简单方法是使用 echo 和 base64 命令：
echo -n admin | base64
$ echo -n admin | base64
YWRtaW4=- 1
n选项非常重要。
此 secret 现在必须通过卷挂载传递给 pod。这在部署模板中也配置：
然后，在 volumes 部分挂载 secret:
volumes:
...
- name: asb-auth-volume
secret:
secretName: asb-auth-secret
volumes:
...
- name: asb-auth-volume
secret:
secretName: asb-auth-secret上述命令将创建一个位于 /var/run/asb-auth 的卷挂载。此卷将有两个文件：由 asb-auth-secret 机密写入的用户名和密码。
8.5.1.2. 配置服务目录和代理通信
现在，代理配置为使用 Basic Auth，您必须告诉服务目录如何与代理通信。这通过代理资源的 authInfo 部分来完成。
以下是在服务目录中 创建代理 资源的示例。spec 告知服务目录代理正在侦听的 URL。authInfo 告诉它读取哪个 secret 获取身份验证信息。
从服务目录的 v0.0.17 开始，代理资源配置更改：
8.5.2. Bearer Auth
默认情况下，如果没有指定身份验证，代理将使用 bearer 令牌身份验证(Bearer Auth)。Bearer Auth 使用 Kubernetes apiserver 库的委托身份验证。
配置通过 Kubernetes RBAC 角色和角色绑定授予对 URL 前缀的访问权限。代理添加了配置选项 cluster_url 以指定 url_prefix。这个值默认为 openshift-ansible-service-broker。
集群角色示例
8.5.2.1. 部署模板和 Secret
以下是创建服务目录可以使用的 secret 的示例。本例假定角色 access-asb-role 已创建。来自部署模板：
上例中会创建一个服务帐户，授予 access-asb-role 的访问权限，并为该服务帐户令牌创建 secret。
8.5.2.2. 配置服务目录和代理通信
现在，代理配置为使用 Bearer Auth 令牌，您必须告知服务目录如何与代理通信。这通过 代理 资源的 authInfo 部分来完成。
以下是在服务目录中 创建代理 资源的示例。spec 告知服务目录代理正在侦听的 URL。authInfo 告诉它读取哪个 secret 获取身份验证信息。
8.6. DAO 配置
| 字段 | 描述 | 必填 |
|---|---|---|
|
| etcd 主机的 URL。 | Y |
|
|
与 | Y |
8.7. 日志配置
| 字段 | 描述 | 必填 |
|---|---|---|
|
| 写入代理日志的位置。 | Y |
|
| 将日志写入 stdout。 | Y |
|
| 日志输出的级别。 | Y |
|
| 颜色日志。 | Y |
8.8. OpenShift 配置
| 字段 | 描述 | 必填 |
|---|---|---|
|
| OpenShift Container Platform 主机。 | N |
|
| 证书颁发机构文件的位置。 | N |
|
| 要使用的 bearer 令牌的位置。 | N |
|
| 拉取镜像的时间。 | Y |
|
| 代理部署到的命名空间。诸如通过 secret 传递参数值等事项非常重要。 | Y |
|
| 为 APB 沙盒环境提供的角色。 | Y |
|
| 始终在执行 APB 后保留命名空间。 | N |
|
| 在 APB 执行出错后保留命名空间。 | N |
8.9. 代理配置
broker 部分告诉代理应该启用和禁用功能。它还将告知代理在磁盘上查找要启用完整功能的文件。
| 字段 | 描述 | 默认值 | 必填 |
|---|---|---|---|
|
| 允许访问开发路由。 |
| N |
|
| 允许绑定为 no-op。 |
| N |
|
| 允许代理在启动时尝试 bootstrap 本身。将从配置的 registry 中检索 APB。 |
| N |
|
| 允许代理通过处理 etcd 中记录的待处理作业来尝试恢复其自身。 |
| N |
|
| 允许代理输出对日志文件的请求，以便更轻松地调试。 |
| N |
|
| 告知代理在哪里查找 TLS 密钥文件。如果没有设置，API 服务器将尝试创建一个。 |
| N |
|
| 告知代理在哪里查找 TLS .crt 文件。如果没有设置，API 服务器将尝试创建一个。 |
| N |
|
| 查询新镜像规格的 registry 的时间间隔。 |
| N |
|
| 允许代理在运行 APB 时升级用户的权限。 |
| N |
|
| 为代理预期的 URL 设置前缀。 |
| N |
async bind 和 unbind 是一个实验性功能，不受支持或默认启用。如果没有 async 绑定，将 launch_apb_on_bind 设置为 true 可能会导致 bind 操作超时，并会重试。代理会使用 "409 Conflicts" 处理这个问题，因为它使用不同的参数使用相同的绑定请求。
8.10. secret 配置
secrets 部分会在代理的命名空间和代理运行的 APB 中创建 secret 间的关联。代理使用这些规则将 secret 挂载到运行的 APB 中，允许用户使用 secret 传递参数，而无需将它们公开给目录或用户。
部分是每个条目具有以下结构的列表：
| 字段 | 描述 | 必填 |
|---|---|---|
|
| 规则的标题。这仅用于显示和输出目的。 | Y |
|
|
与指定 secret 关联的 APB 名称。这是完全限定名称( < | Y |
|
| 要从中拉取参数的 secret 名称。 | Y |
您可以下载并使用 create_broker_secret.py 文件来创建和格式化这个配置部分。
secrets: - title: Database credentials secret: db_creds apb_name: dh-rhscl-postgresql-apb
secrets:
- title: Database credentials
secret: db_creds
apb_name: dh-rhscl-postgresql-apb8.11. 在代理后面运行
在代理 OpenShift Container Platform 集群内运行 OAB 时，务必要了解其核心概念，并在用于外部网络访问的代理上下文中考虑它们。
作为概述，代理本身作为集群中的 pod 运行。它具有外部网络访问权限的要求，具体取决于其 registry 的配置方式。
8.11.1. registry Adapter Whitelists
代理配置的 registry 适配器必须能够与外部 registry 通信，才能成功引导并加载远程 APB 清单。这些请求可以通过代理进行，但代理必须确保可以访问所需的远程主机。
需要白名单的主机示例：
| registry Adapter Type | 将主机列入白名单 |
|---|---|
|
|
|
|
|
|
8.11.2. 使用 Ansible 配置代理成为代理
如果在初始安装过程中，您可以将 OpenShift Container Platform 集群配置为在代理后运行（请参阅" 配置全局代理选项"），当部署 OAB 时：
- 自动继承这些集群范围的代理设置，
-
生成所需的
NO_PROXY列表，包括cidr字段和serviceNetworkCIDR,
不需要进一步配置。
8.11.3. 手动配置代理成为代理
如果在初始安装过程中或部署代理前没有配置集群的全局代理选项，或者修改了全局代理设置，则必须手动配置代理以便通过代理进行外部访问：
在尝试在代理后面运行 OAB 之前，请参阅使用 HTTP Proxies 工作，并确保集群进行相应配置，以便在代理后面运行。
特别是，集群必须配置为 不 代理内部集群请求。这通常配置有
NO_PROXY设置：.cluster.local,.svc,<serviceNetworkCIDR_value>,<master_IP>,<master_domain>,.default
.cluster.local,.svc,<serviceNetworkCIDR_value>,<master_IP>,<master_domain>,.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 除了任何其他所需的
NO_PROXY设置之外。如需了解更多详细信息，请参阅配置 NO_PROXY。注意部署未指定版本的 或 v1 APBs 还必须将
172.30.0.1添加到其NO_PROXY列表中。v2 之前的 APB 通过execHTTP 请求从运行 APB pod 中提取凭证，而不是通过 secret 交换。除非在 OpenShift Container Platform 3.9 之前运行带有实验代理支持的代理，否则您可能不必担心。以具有 cluster-admin 权限的用户身份登录代理的
DeploymentConfig：oc edit dc/asb -n openshift-ansible-service-broker
$ oc edit dc/asb -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 设置以下环境变量：
-
HTTP_PROXY -
HTTPS_PROXY -
NO_PROXY
注意如需更多信息，请参阅在 Pod 中设置代理环境变量。
-
保存任何更新后，请重新部署 OAB 的部署配置以使更改生效：
oc rollout latest dc/asb -n openshift-ansible-service-broker
$ oc rollout latest dc/asb -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.11.4. 在 Pod 中设置代理环境变量
APB pod 本身还需要通过代理进行外部访问。如果代理识别具有代理配置，它会将这些环境变量透明地应用到它生成的 APB pod。只要 APB 中使用的模块通过环境变量处理代理配置，APB 也将使用这些设置来执行其工作。
最后，APB 生成的服务可能还需要通过代理访问外部网络。如果在其自己的执行环境中识别这些环境变量，则必须明确编写 APB 来设置这些环境变量，或者集群操作员必须手动修改所需的服务才能将其注入其环境中。
第 9 章 将主机添加到现有集群
9.1. 添加主机
您可以通过运行 scaleup.yml playbook 添加新主机到集群。此 playbook 查询 master，为新主机生成和发布新证书，然后仅在新主机上运行配置 playbook。在运行 scaleup.yml playbook 之前，请完成所有必备的主机准备步骤。
scaleup.yml playbook 仅配置新主机。它不会更新 master 服务的 NO_PROXY，也不会重启 master 服务。
您必须有一个现有的清单文件，如 /etc/ansible/hosts，它代表当前集群配置，才能运行 scaleup.yml playbook。如果您之前使用 atomic-openshift-installer 命令来运行安装，您可以检查 ~/.config/openshift/hosts 查找安装程序生成的最后一个清单文件，并将该文件用作清单文件。您可以根据需要修改此文件。然后，在运行 ansible-playbook 时，您必须使用 -i 指定文件位置。
有关推荐的最大节点数，请参阅集群最大值部分。
流程
通过更新 openshift-ansible 软件包来确保您有最新的 playbook：
yum update openshift-ansible
# yum update openshift-ansibleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑 /etc/ansible/hosts 文件，并将 new_<host_type> 添加到 [OSEv3:children] 部分。例如，要添加新节点主机，请添加 new_nodes ：
[OSEv3:children] masters nodes new_nodes
[OSEv3:children] masters nodes new_nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 若要添加新的 master 主机，可添加 new_masters。
创建一个 [new_<host_type>] 部分来为新主机指定主机信息。将此部分格式化为现有部分，如下例所示：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如需了解更多选项，请参阅配置主机变量。
在添加新 master 时，将主机添加到 [new_masters] 部分和 [new_nodes] 部分，以确保新 master 主机是 OpenShift SDN 的一部分：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要如果您使用
node-role.kubernetes.io/infra=true标签标记 master 主机，且没有其他专用基础架构节点，还必须通过向条目中添加openshift_schedulable=true明确将该主机标记为可以调度。否则，registry 和路由器 Pod 将无法放置到任何节点。更改到 playbook 目录，再运行 openshift_node_group.yml playbook。如果您的清单文件位于 /etc/ansible/hosts 默认以外的位置，请使用
-i选项指定位置：cd /usr/share/ansible/openshift-ansible ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/openshift_node_group.yml
$ cd /usr/share/ansible/openshift-ansible $ ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/openshift_node_group.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这会为新节点组创建 ConfigMap，并最终为主机上的节点配置文件。
注意运行 openshift_node_group.yaml playbook 只会更新新节点。无法运行它来更新集群中的现有节点。
运行 scaleup.yml playbook。如果您的清单文件位于默认 /etc/ansible/hosts 以外的位置，请使用
-i选项指定位置。对于额外的节点：
ansible-playbook [-i /path/to/file] \ playbooks/openshift-node/scaleup.yml$ ansible-playbook [-i /path/to/file] \ playbooks/openshift-node/scaleup.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 对于额外的 master：
ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/scaleup.yml$ ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/scaleup.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
如果您在集群中部署了 EFK 堆栈，请将节点标签设置为
logging-infra-fluentd=true：oc label node/new-node.example.com logging-infra-fluentd=true
# oc label node/new-node.example.com logging-infra-fluentd=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 在 playbook 运行后，验证安装。
将您在 [new_<host_type>] 部分定义的任何主机移动到它们的相应部分。通过移动这些主机，后续的 playbook 运行使用此清单文件正确处理节点。您可以保留空 [new_<host_type>] 部分。例如，添加新节点时：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2. 在现有集群中添加 etcd 主机
您可以通过运行 etcd 扩展 playbook 来在集群中添加新的 etcd 主机。此 playbook 查询 master，为新主机生成并分发新证书，然后仅在新主机上运行配置 playbook。在运行 etcd scaleup.yml playbook 前，请完成所有预备 主机准备步骤。
这些步骤会将 Ansible 清单中的设置与集群同步。确保 Ansible 清单中显示了任何本地更改。
将 etcd 主机添加到现有集群中：
通过更新 openshift-ansible 软件包来确保您有最新的 playbook：
yum update openshift-ansible
# yum update openshift-ansibleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑 /etc/ansible/hosts 文件，将 new_<host_type> 添加到 [OSEv3: Child] 组，并在 new_<host_type> 组下添加主机。例如，要添加新的 etcd，请添加 new_etcd：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更改到 playbook 目录，再运行 openshift_node_group.yml playbook。如果您的清单文件位于 /etc/ansible/hosts 默认以外的位置，请使用
-i选项指定位置：cd /usr/share/ansible/openshift-ansible ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/openshift_node_group.yml
$ cd /usr/share/ansible/openshift-ansible $ ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/openshift_node_group.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这会为新节点组创建 ConfigMap，并最终为主机上的节点配置文件。
注意运行 openshift_node_group.yaml playbook 只会更新新节点。无法运行它来更新集群中的现有节点。
运行 etcd scaleup.yml playbook。如果您的清单文件位于 /etc/ansible/hosts 默认以外的位置，请使用
-i选项指定位置：ansible-playbook [-i /path/to/file] \ playbooks/openshift-etcd/scaleup.yml
$ ansible-playbook [-i /path/to/file] \ playbooks/openshift-etcd/scaleup.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - playbook 成功完成后，验证安装。
9.3. 将现有的 master 替换为 etcd colocated
在将机器迁移到不同的数据中心以及分配给它的网络和 IP 将改变时，请按照以下步骤操作。
在 OpenShift Container Platform 版本 3.11 的初始发行版本中，scaleup.yml playbook 不会扩展 etcd。这个问题已在 OpenShift Container Platform 3.11.59 及更高版本中解决。
-
添加 master。在这一流程的第 3 步，在
[new_masters]和[new_nodes]中添加新数据中心的主机，运行 openshift_node_group.yml playbook，并运行 master scaleup.yml playbook。 - 将相同的主机放在 etcd 部分中，运行 openshift_node_group.yml playbook，并运行 etcd scaleup.yml playbook。
验证主机是否已添加：
oc get nodes
# oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证 master 主机 IP 是否已添加：
oc get ep kubernetes
# oc get ep kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证已添加了 etcd。
ETCDCTL_API的值取决于所使用的版本：source /etc/etcd/etcd.conf ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
# source /etc/etcd/etcd.conf # ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 /etc/origin/master/ca.serial.txt 从 /etc/origin/master 目录复制到清单文件中最先列出的新 master 主机。默认情况下，这是 /etc/ansible/hosts。
- 删除 etcd 主机。
- 将 /etc/etcd/ca 目录复制到清单文件中第一个列出的新 etcd 主机中。默认情况下，这是 /etc/ansible/hosts。
从 master-config.yaml 文件中删除旧的 etcd 客户端：
grep etcdClientInfo -A 11 /etc/origin/master/master-config.yaml
# grep etcdClientInfo -A 11 /etc/origin/master/master-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重启 master：
master-restart api master-restart controllers
# master-restart api # master-restart controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从集群中删除旧的 etcd 成员。
ETCDCTL_API的值取决于所使用的版本：source /etc/etcd/etcd.conf ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
# source /etc/etcd/etcd.conf # ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 获取以上命令的输出中的 ID，并使用 ID 删除旧的成员：
etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URL member remove 1609b5a3a078c227
# etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URL member remove 1609b5a3a078c227Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过删除 etcd pod 定义来停止旧 etcd 主机上的 etcd 服务：
mkdir -p /etc/origin/node/pods-stopped mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
# mkdir -p /etc/origin/node/pods-stopped # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过将定义文件从静态 pod dir /etc/origin/node/pods 中移出，关闭旧的 master API 和控制器服务：
mkdir -p /etc/origin/node/pods/disabled mv /etc/origin/node/pods/controller.yaml /etc/origin/node/pods/disabled/:
# mkdir -p /etc/origin/node/pods/disabled # mv /etc/origin/node/pods/controller.yaml /etc/origin/node/pods/disabled/:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 从 HA 代理配置中删除 master 节点，该配置在原生安装过程中默认作为负载均衡器安装。
- 弃用机器。
通过删除 pod 定义并重启主机来停止 master 上的节点服务：
mkdir -p /etc/origin/node/pods-stopped mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/ reboot
# mkdir -p /etc/origin/node/pods-stopped # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/ # rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除节点资源：
oc delete node
# oc delete nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.4. 迁移节点
您可以单独对节点进行迁移，或以组的形式迁移节点（例如 2 个、5 个 10 个为一组等），具体取决于您对节点的服务运行和扩展的方式。
第 10 章 添加默认镜像流和模板
10.1. 概述
如果您在有 x86_64 架构的服务器上安装了 OpenShift Container Platform，您的集群包含了红帽提供的 镜像流和模板 组，以便开发人员轻松创建新应用程序。默认情况下，集群安装过程会在 openshift 项目中创建这些集合，它是所有用户具有查看访问权限的默认全局项目。
如果您在使用 IBM POWER 架构的服务器上安装 OpenShift Container Platform，您可以 在集群中添加 镜像流和模板。
10.2. 按订阅类型提供
根据您的红帽帐户上的活跃订阅，红帽提供了以下镜像流和模板集并被红帽支持。请联系红帽销售代表了解更多详情。
10.2.1. OpenShift Container Platform 订阅
带有一个活跃的 OpenShift Container Platform 订阅，并提供支持了镜像流和模板的核心集合。这包括以下技术：
| 类型 | 技术 |
|---|---|
| 语言和框架 | |
| 数据库 | |
| 中间件服务 | |
| 其他服务 |
10.2.2. xPaaS 中间件附加订阅
xPaaS 中间件镜像支持由 xPaaS 中间件附加组件订阅提供，它是每个 xPaaS 产品的独立订阅。如果您的帐户上已有相关的订阅，则会为以下技术提供镜像流和模板支持：
10.3. 开始前
在考虑执行本主题中的任务前，请通过执行以下操作之一确认这些镜像流和模板已在 OpenShift Container Platform 集群中注册：
- 登录 Web 控制台，再点 Add to Project。
使用 CLI 列出 openshift 项目：
oc get is -n openshift oc get templates -n openshift
$ oc get is -n openshift $ oc get templates -n openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
如果删除或更改了默认镜像流和模板，可以根据这里的内容自行创建默认对象。否则，不需要以下说明。
10.4. 先决条件
在创建默认镜像流和模板之前：
- 必须在 OpenShift Container Platform 安装中部署集成的容器镜像 registry 服务。
-
您必须使用 cluster-admin 特权运行
oc create命令，因为它们在默认的 openshift 项目 上运行。 - 您必须已安装了 openshift-ansible RPM 软件包。具体步骤请参阅 软件先决条件。
-
对于 IBM POWER8 或 IBM POWER9 服务器中的内部安装，在
openshift命名空间中为registry.redhat.io创建 secret。 为包含镜像流和模板的目录定义 shell 变量。这可显著缩短以下部分中的命令。要做到这一点：
- 对于 x86_64 服务器中的云安装和内部安装：
IMAGESTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/image-streams"; \
XPAASSTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/xpaas-streams"; \
XPAASTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/xpaas-templates"; \
DBTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/db-templates"; \
QSTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/quickstart-templates"
$ IMAGESTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/image-streams"; \
XPAASSTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/xpaas-streams"; \
XPAASTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/xpaas-templates"; \
DBTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/db-templates"; \
QSTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/x86_64/quickstart-templates"- 对于 IBM POWER8 或 IBM POWER9 服务器中的内部安装：
IMAGESTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/ppc64le/image-streams"; \
DBTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/ppc64le/db-templates"; \
QSTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/ppc64le/quickstart-templates"
IMAGESTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/ppc64le/image-streams"; \
DBTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/ppc64le/db-templates"; \
QSTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/ppc64le/quickstart-templates"10.5. 为 OpenShift Container Platform 镜像创建镜像流
如果您的节点主机使用 Red Hat Subscription Manager 订阅，且您想要使用使用 Red Hat Enterprise Linux(RHEL)7 的镜像的核心镜像流集合：
oc create -f $IMAGESTREAMDIR/image-streams-rhel7.json -n openshift
$ oc create -f $IMAGESTREAMDIR/image-streams-rhel7.json -n openshift另外，要创建使用基于 CentOS 7 的镜像的核心镜像流集合：
oc create -f $IMAGESTREAMDIR/image-streams-centos7.json -n openshift
$ oc create -f $IMAGESTREAMDIR/image-streams-centos7.json -n openshift无法同时创建 CentOS 和 RHEL 镜像流集，因为它们使用相同的名称。要将镜像流集可供用户使用，可在另一项目中创建一个集合，或者编辑其中一个文件，并修改镜像流名称以使其唯一。
10.6. 为 xPaaS 中间件镜像创建镜像流
xPaaS 中间件镜像流为 JBoss EAP、JBoss JWS、JBoss A-MQ、红帽 Fuse on OpenShift、Decision Server、JBoss Data Virtualization 和 JBoss Data Grid 提供图像。它们可用于使用提供的模板为这些平台构建应用程序。
创建 xPaaS 中间件镜像流集：
oc create -f $XPAASSTREAMDIR/jboss-image-streams.json -n openshift
$ oc create -f $XPAASSTREAMDIR/jboss-image-streams.json -n openshift访问这些镜像流引用的镜像需要相关的 xPaaS 中间件订阅。
10.7. 创建数据库服务模板
借助数据库服务模板，可以更轻松地运行可供其他组件使用的数据库镜像。对于每个数据库（MongoDB、MySQL 和 PostgreSQL）,定义了两个模板。
一个模板使用容器中的临时存储，这意味着如果容器重启，存储的数据将会丢失，例如，如果 pod 移动。此模板仅用于演示目的。
其他模板定义了用于存储的持久性卷，但 OpenShift Container Platform 安装需要配置 持久性卷。
创建数据库模板的核心集合：
oc create -f $DBTEMPLATES -n openshift
$ oc create -f $DBTEMPLATES -n openshift创建模板后，用户可以轻松地实例化各种模板，使它们快速访问数据库部署。
10.8. 创建 Instant App 和 Quickstart 模板
Instant App 和 Quickstart 模板为正在运行的应用程序定义一组完整的对象。它们是：
有些模板也定义了数据库部署和服务，以便应用程序能够执行数据库操作。
定义数据库的模板将临时存储用于数据库内容。这些模板仅限于演示目的，因为如果数据库 pod 因任何原因重启，所有数据库数据都将丢失。
通过使用这些模板，用户可以使用 OpenShift Container Platform 提供的各种语言镜像轻松实例化完整的应用程序。它们也可以在实例化过程中自定义模板参数，以便从其自己的存储库构建源，而非示例存储库，从而为构建新应用提供了简单起点。
创建核心 Instant App 和 Quickstart 模板：
oc create -f $QSTEMPLATES -n openshift
$ oc create -f $QSTEMPLATES -n openshift还有一组模板，可使用各种 xPaaS 中间件产品（JBoss EAP, JBoss JWS, JBoss A-MQ, Red Hat Fuse on OpenShift, Decision Server, 和 JBoss Data Grid）创建应用程序，通过运行以下命令：
oc create -f $XPAASTEMPLATES -n openshift
$ oc create -f $XPAASTEMPLATES -n openshiftxPaaS 中间件模板需要 xPaaS 中间件镜像流，后者需要相关的 xPaaS 中间件订阅。
定义数据库的模板将临时存储用于数据库内容。这些模板仅限于演示目的，因为如果数据库 pod 因任何原因重启，所有数据库数据都将丢失。
10.9. 下一步是什么？
创建这些工件后，开发人员 现在可以登录到 web 控制台，并根据 模板创建过程 进行操作。可以选择任何数据库或应用程序模板，在当前项目中创建正在运行的数据库服务或应用程序。请注意，一些应用程序模板也定义了自己的数据库服务。
示例应用都构建了默认在模板中引用的 GitHub 存储库，如 SOURCE_REPOSITORY_URL 参数值中所示。这些存储库可以进行分叉，并且分叉可以在从模板创建时作为 SOURCE_REPOSITORY_URL 参数值提供。这使得开发人员能够尝试创建自己的应用程序。
您可以将开发人员定向到开发者指南中的使用 Instant App 和 Quickstart Templates 部分。
第 11 章 配置自定义证书
11.1. 概述
管理员可以为 OpenShift Container Platform API 和 Web 控制台的 公共主机名配置自定义服务证书。这可在集群安装过程中完成，也可以在安装后配置。
11.2. 配置证书链
如果使用证书链，则必须手动将所有证书链接到一个命名的证书文件中。这些证书必须按以下顺序放置：
- OpenShift Container Platform master 主机证书
- 中间 CA 证书
- Root CA 证书
- 第三方证书
要创建此证书链，请将证书串联为通用文件。您必须为每个证书运行这个命令，并确保它们按之前定义的顺序运行。
cat <certificate>.pem >> ca-chain.cert.pem
$ cat <certificate>.pem >> ca-chain.cert.pem11.3. 在安装过程中配置自定义证书
在集群安装过程中，可以使用 openshift_master_named_certificates 和 openshift_master_overwrite_named_certificates 参数来配置自定义证书，它们可在清单文件中配置。有关使用 Ansible 配置自定义证书 的更多详细信息。
自定义证书配置参数
openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}]
openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"}
openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}]
openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"} master API 证书的参数示例：
openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"names": ["master.148.251.233.173.nip.io"], "certfile": "/home/cloud-user/master.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/master.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/master-bundle.cert.pem"}]
openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"names": ["master.148.251.233.173.nip.io"], "certfile": "/home/cloud-user/master.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/master.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/master-bundle.cert.pem"}]路由器通配符证书的参数示例：
openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}
openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}11.4. 为 Web 控制台或 CLI 配置自定义证书
您可以通过主配置文件 的 serviceInfo 部分为 web 控制台和 CLI 指定自定义证书：
-
serviceInfo.namedCertificates部分为 web 控制台提供自定义证书。 -
serviceInfo部分提供 CLI 和其它 API 调用的自定义证书。
您可以以这种方式配置多个证书，每个证书都可与多个主机名、多个路由器或 OpenShift Container Platform 镜像 registry 关联。
除了 namedCertificates 外，还必须在 serviceInfo.certFile 和 serviceInfo.keyFile 配置部分中配置默认证书。
namedCertificates 部分应仅为与 /etc/origin/master/master-config.yaml 文件中的 masterPublicURL 和 oauthConfig.assetPublicURL 设置关联的主机名配置。将自定义服务证书用于与 关联的主机名将导致 TLS 错误，因为基础架构组件将尝试使用内部 masterURL 主机联系 master API。
masterURL
自定义证书配置
Ansible 清单文件（默认为 /etc/ansible/hosts）中的 openshift_master_cluster_public_hostname 和 openshift_master_cluster_hostname 参数必须是不同的。如果它们相同，命名的证书将失败，您需要重新安装它们。
Native HA with External LB VIPs
# Native HA with External LB VIPs
openshift_master_cluster_hostname=internal.paas.example.com
openshift_master_cluster_public_hostname=external.paas.example.com有关在 OpenShift Container Platform 中使用 DNS 的更多信息，请参阅 DNS 安装先决条件。
这种方法允许您利用 OpenShift Container Platform 生成的自签名证书，并根据需要将自定义可信证书添加到各个组件中。
请注意，内部基础架构证书仍是自签名的，这可能被某些安全或 PKI 团队视为不当做法。但是，这里的风险最小，因为信任这些证书的唯一客户端是集群中的其他组件。所有外部用户和系统都使用自定义可信证书。
相对路径基于主配置文件的位置解析。重启服务器以获取配置更改。
11.5. 配置自定义 master 主机证书
为了促进与 OpenShift Container Platform 的外部用户的可信连接，您可以置备一个与 Ansible 清单文件（默认为 /etc/ansible/hosts）中的 openshift_master_cluster_public_hostname 参数提供的域名匹配的命名证书。
您必须将此证书放在 Ansible 可访问的目录中，并在 Ansible 清单文件中添加路径，如下所示：
openshift_master_named_certificates=[{"certfile": "/path/to/console.ocp-c1.myorg.com.crt", "keyfile": "/path/to/console.ocp-c1.myorg.com.key", "names": ["console.ocp-c1.myorg.com"]}]
openshift_master_named_certificates=[{"certfile": "/path/to/console.ocp-c1.myorg.com.crt", "keyfile": "/path/to/console.ocp-c1.myorg.com.key", "names": ["console.ocp-c1.myorg.com"]}]如果参数值是：
- cert File 是包含 OpenShift Container Platform 自定义主 API 证书的文件的路径。
- keyfile 是包含 OpenShift Container Platform 自定义主 API 证书密钥的文件的路径。
- name 是集群的公共主机名。
对于 Ansible 允许，文件路径需要是系统的本地路径。证书被复制到 master 主机，并部署到 /etc/origin/master 目录中。
在保护 registry 时，将服务主机名和 IP 地址添加到 registry 的服务器证书中。主题备用名称(SAN)必须包含以下内容：
两个服务主机名：
docker-registry.default.svc.cluster.local docker-registry.default.svc
docker-registry.default.svc.cluster.local docker-registry.default.svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 服务 IP 地址.
例如：
172.30.252.46
172.30.252.46Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令获取容器镜像 registry 服务 IP 地址：
oc get service docker-registry --template='{{.spec.clusterIP}}'oc get service docker-registry --template='{{.spec.clusterIP}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 公共主机名.
docker-registry-default.apps.example.com
docker-registry-default.apps.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令获取容器镜像 registry 公共主机名：
oc get route docker-registry --template '{{.spec.host}}'oc get route docker-registry --template '{{.spec.host}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例如，服务器证书应包含类似如下的 SAN 详情：
X509v3 Subject Alternative Name:
DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98
X509v3 Subject Alternative Name:
DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.9811.6. 为默认路由器配置自定义通配符证书
您可以使用默认通配符证书配置 OpenShift Container Platform 默认路由器。默认通配符证书为在 OpenShift Container Platform 中部署的应用程序提供了一种便捷方式，而无需自定义证书，即可使用默认加密。
不建议在非生产环境中使用默认通配符证书。
要配置默认通配符证书，置备一个对 *.<app_domain> 有效的证书，其中 <app_domain> 是 Ansible 清单文件 中的 openshift_master_default_subdomain 的值，默认为 /etc/ansible/hosts。置备后，将证书、密钥和 ca 证书文件放在 Ansible 主机上，并将下面这一行添加到您的 Ansible 清单文件。
openshift_hosted_router_certificate={"certfile": "/path/to/apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/apps.c1-ocp.myorg.com.key", "cafile": "/path/to/apps.c1-ocp.myorg.com.ca.crt"}
openshift_hosted_router_certificate={"certfile": "/path/to/apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/apps.c1-ocp.myorg.com.key", "cafile": "/path/to/apps.c1-ocp.myorg.com.ca.crt"}例如：
openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}
openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}参数值是：
- cert File 是包含 OpenShift Container Platform 路由器通配符证书的文件的路径。
- keyfile 是包含 OpenShift Container Platform 路由器通配符证书密钥的文件的路径。
- CAfile 是包含此密钥和证书 root CA 的文件的路径。如果使用了中间 CA，则该文件应包含中间和 root CA。
如果这些证书文件是 OpenShift Container Platform 集群的新文件，请切换到 playbook 目录，并运行 Ansible deploy_router.yml playbook，将这些文件添加到 OpenShift Container Platform 配置文件中。playbook 将证书文件添加到 /etc/origin/master/ 目录中。
ansible-playbook [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/deploy_router.yml
# ansible-playbook [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/deploy_router.yml如果 证书不是新的，例如，要更改现有证书或替换过期的证书，请切换到 playbook 目录并运行以下 playbook：
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml要使此 playbook 运行，证书名称不得更改。如果证书名称改变，请重新运行 Ansible deploy_cluster.yml playbook，就像证书是新证书一样。
11.7. 为 Image Registry 配置自定义证书
OpenShift Container Platform 镜像 registry 是一个可促进构建和部署的内部服务。大多数与 registry 的通信都由 OpenShift Container Platform 中的内部组件处理。因此，您不应该需要替换 registry 服务本身使用的证书。
但是，默认情况下，registry 使用路由来允许外部系统和用户拉取和推送镜像。您可以使用带有提供给外部用户的自定义证书的重新加密路由，而不使用内部自签名证书。
要配置此功能，请将以下行添加到 Ansible 清单文件的 [OSEv3:vars] 部分，默认为 /etc/ansible/hosts 文件。指定要与 registry 路由一起使用的证书。
openshift_hosted_registry_routehost=registry.apps.c1-ocp.myorg.com
openshift_hosted_registry_routecertificates={"certfile": "/path/to/registry.apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/registry.apps.c1-ocp.myorg.com.key", "cafile": "/path/to/registry.apps.c1-ocp.myorg.com-ca.crt"}
openshift_hosted_registry_routetermination=reencrypt
openshift_hosted_registry_routehost=registry.apps.c1-ocp.myorg.com
openshift_hosted_registry_routecertificates={"certfile": "/path/to/registry.apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/registry.apps.c1-ocp.myorg.com.key", "cafile": "/path/to/registry.apps.c1-ocp.myorg.com-ca.crt"}
openshift_hosted_registry_routetermination=reencrypt - 1
- registry 的主机名。
- 2
- cacert, cert, 和 key 文件的位置。
- cert File 是包含 OpenShift Container Platform registry 证书的文件的路径。
- keyfile 是包含 OpenShift Container Platform registry 证书密钥的文件的路径。
- CAfile 是包含此密钥和证书 root CA 的文件的路径。如果使用了中间 CA，则该文件应包含中间和 root CA。
- 3
- 指定执行加密的位置：
-
设置为
reencrypt，使用重新加密路由在边缘路由器中终止加密，并使用目的地提供的新证书重新加密。 -
设置为
passthrough会在目的地终止加密。目的地负责对数据进行解密。
-
设置为
11.8. 为负载均衡器配置自定义证书
如果您的 OpenShift Container Platform 集群使用默认的负载均衡器或企业级负载均衡器，您可以使用自定义证书使 Web 控制台和 API 使用公开签名的自定义证书。保留内部端点的现有内部证书。
以这种方式将 OpenShift Container Platform 配置为使用自定义证书：
编辑 master 配置文件的
servingInfo部分：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意仅为与
masterPublicURL和oauthConfig.assetPublicURL设置关联的主机名配置namedCertificates部分。将自定义服务证书用于与masterURL关联的主机名会导致 TLS 错误，因为基础架构组件尝试使用内部 masterURL 主机联系主 API。在 Ansible 清单文件中指定
openshift_master_cluster_public_hostname和openshift_master_cluster_hostname参数，默认为 /etc/ansible/hosts。这些值必须不同。如果它们相同，则命名证书将失败。Native HA with External LB VIPs
# Native HA with External LB VIPs openshift_master_cluster_hostname=paas.example.com1 openshift_master_cluster_public_hostname=public.paas.example.com2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
有关负载均衡器环境的信息，请参阅 供应商和自定义证书 SSL 终止（产品） 的 OpenShift Container Platform 参考架构。
11.9. 将自定义证书重新引入到集群中
您可以将自定义 master 和自定义路由器证书重新创建到现有的 OpenShift Container Platform 集群中。
11.9.1. 将自定义 Master 证书重新引入到集群中
重新引进自定义证书 ：
-
编辑 Ansible 清单文件，以设置
openshift_master_overwrite_named_certificates=true。 使用
openshift_master_named_certificates参数指定证书的路径。openshift_master_overwrite_named_certificates=true openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}]openshift_master_overwrite_named_certificates=true openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 进入 playbook 目录并运行以下 playbook：
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您使用命名的证书：
- 更新每个 master 节点上的 master-config.yaml 文件中的证书参数。
重启 OpenShift Container Platform master 服务以应用更改。
master-restart api master-restart controllers
# master-restart api # master-restart controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.9.2. 将自定义路由器证书重新引入到集群中
重新引进自定义路由器证书：
-
编辑 Ansible 清单文件，以设置
openshift_master_overwrite_named_certificates=true。 使用
openshift_hosted_router_certificate参数指定证书的路径。openshift_master_overwrite_named_certificates=true openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"}openshift_master_overwrite_named_certificates=true openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"}1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 进入 playbook 目录并运行以下 playbook：
cd /usr/share/ansible/openshift-ansible ansible-playbook playbooks/openshift-hosted/redeploy-router-certificates.yml
$ cd /usr/share/ansible/openshift-ansible $ ansible-playbook playbooks/openshift-hosted/redeploy-router-certificates.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.10. 将自定义证书与其他组件一起使用
如需有关其他组件（如日志记录和指标等）如何使用自定义证书，请参阅证书管理。
第 12 章 重新部署证书
12.1. 概述
OpenShift Container Platform 使用证书为以下组件提供安全连接：
- master（API 服务器和控制器）
- etcd
- 节点
- registry
- 路由器
您可以使用由安装程序提供的 Ansible playbook 来自动检查集群证书的过期日期。此外，还提供了 playbook 来自动备份和恢复这些证书，从而可以修复常见的证书错误。
重新部署证书的可能用例包括：
- 安装程序检测到错误的主机名，发现问题的时间太晚。
- 证书已过期，您需要更新它们。
- 您有新的 CA 并想要改用证书。
12.2. 检查证书过期
您可以使用安装程序在可配置的窗口内过期任何证书，并通知您了解已经过期的任何证书。证书到期 playbook 使用 Ansible 角色 openshift_certificate_expiry。
角色检查的证书包括：
- Master 和节点服务证书
- 来自 etcd secret 的路由器和 registry 服务证书
- cluster-admin 用户的 master、node、router、registry 和 kubeconfig 文件
- etcd 证书（包括嵌入式）
了解如何列出所有 OpenShift TLS 证书到期日期。
12.2.1. 角色变量
openshift_certificate_expiry 角色使用以下变量：
| 变量名称 | 默认值 | 描述 |
|---|---|---|
|
|
| OpenShift Container Platform 基础配置目录。 |
|
|
| 标记将在从现在开始的这个天数后过期的证书。 |
|
|
| 在结果中包含健康状态（非过期和非警告）的证书。 |
| 变量名称 | 默认值 | 描述 |
|---|---|---|
|
|
| 生成到期检查结果的 HTML 报告。 |
|
|
| 保存 HTML 报告的完整路径。默认为由报告文件的主目录和时间戳后缀组成。 |
|
|
| 将到期检查结果保存为 JSON 文件。 |
|
|
| 保存 JSON 报告的完整路径。默认为由报告文件的主目录和时间戳后缀组成。 |
12.2.2. 运行证书过期 Playbook
OpenShift Container Platform 安装程序提供一组示例证书过期 playbook，它使用了 openshift_certificate_expiry 角色的不同配置集合。
这些 playbook 必须与代表集群 的清单文件 一起使用。要获得最佳结果，请使用 -v 选项运行 ansible-playbook。
使用 easy-mode.yaml 示例 playbook，您可以根据需要尝试角色在对规格进行调整。此 playbook：
- 在 $HOME 目录中生成 JSON 和 stylized HTML 报告。
- 将警告窗口设置得非常大，以保证您将总能得到结果。
- 在结果中包含所有证书（健康或非 ）。
进入 playbook 目录并运行 easy-mode.yaml playbook：
cd /usr/share/ansible/openshift-ansible
ansible-playbook -v -i <inventory_file> \
playbooks/openshift-checks/certificate_expiry/easy-mode.yaml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v -i <inventory_file> \
playbooks/openshift-checks/certificate_expiry/easy-mode.yaml其他 Playbook 示例
其它示例 playbook 还可用于直接从 /usr/share/ansible/openshift-ansible/playbooks/certificate_expiry/ 目录运行。
| 文件名 | 使用方法 |
|---|---|
| default.yaml |
生成 |
| html_and_json_default_paths.yaml | 在默认路径中生成 HTML 和 JSON 工件。 |
| longer_warning_period.yaml | 将到期警告窗口更改为 1500 天。 |
| longer-warning-period-json-results.yaml | 将过期警告窗口更改为 1500 天，并将结果保存为 JSON 文件。 |
运行其中任何示例 playbook：
cd /usr/share/ansible/openshift-ansible
ansible-playbook -v -i <inventory_file> \
playbooks/openshift-checks/certificate_expiry/<playbook>
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v -i <inventory_file> \
playbooks/openshift-checks/certificate_expiry/<playbook>12.2.3. 输出格式
如上方所述，可以通过两种方式格式化检查报告。在用于机器解析的 JSON 格式，或作为风格的 HTML 页面，用于简单skimming。
HTML 报告
安装程序提供了 HTML 报告示例。您可以在浏览器中打开以下文件以查看它：
/usr/share/ansible/openshift-ansible/roles/openshift_certificate_expiry/examples/cert-expiry-report.html
JSON 报告
保存的 JSON 结果中有两个顶层键： 数据和 摘要。
data 键是一个哈希值，其中键是检查每个主机的名称，值是每个对应主机上标识的证书的检查结果。
summary 键是一个哈希，用于总结证书的总数：
- 在整个集群中检查
- 这是正确的
- 在配置的警告窗口中过期
- 已过期
有关完整 JSON 报告示例，请参阅 /usr/share/ansible/openshift-ansible/roles/openshift_certificate_expiry/examples/cert-expiry-report.json。
可以使用各种命令行工具，轻松检查 JSON 数据的摘要，是否有警告或过期时间。例如，使用 grep 查找单词 summary，并在匹配项后打印出两行 (-A2)：
grep -A2 summary $HOME/cert-expiry-report.yyyymmddTHHMMSS.json
$ grep -A2 summary $HOME/cert-expiry-report.yyyymmddTHHMMSS.json
"summary": {
"warning": 16,
"expired": 0
如果可用，也可以使用 jq 工具查找特定值。下面的前两个示例显示了如何仅选择一个值，可以是 warning 或 已过期。第三个示例演示了如何同时选择这两个值：
12.3. 重新部署证书
重新部署 playbook 重启 control plane 服务，并可能导致集群停机。一个服务中的错误可能会导致 playbook 失败并影响集群健康状况。如果 playbook 失败，您可能需要手动解决问题并重新启动 playbook。playbook 必须按顺序完成所有任务才能成功。
使用以下 playbook 在所有相关主机上重新部署 master、etcd、node、registry 和路由器证书。您可以一次使用当前的 CA 重新部署所有这些证书，只为特定组件重新部署证书，或者自行重新部署新生成的或自定义 CA。
与证书到期 playbook 一样，这些 playbook 必须使用代表集群 的清单文件 运行。
特别是，清单必须通过以下变量指定或覆盖所有主机名和 IP 地址，以便它们与当前的集群配置匹配：
-
openshift_public_hostname -
openshift_public_ip -
openshift_master_cluster_hostname -
openshift_master_cluster_public_hostname
您需要的 playbook 通过以下方式提供：
yum install openshift-ansible
# yum install openshift-ansible任何证书在重新部署时自动生成的任何证书的有效性（以天为单位），也可以通过 Ansible 配置。请参阅 配置证书有效期。
OpenShift Container Platform CA 和 etcd 证书在 5 年后过期。签名的 OpenShift Container Platform 证书在两年后过期。
redeploy-certificates.yml playbook 不会 重新生成 OpenShift Container Platform CA 证书。使用当前 CA 证书创建新 master、etcd、node、registry 和路由器证书，为新证书签名。
这还包括以下串行重启：
- etcd
- 主服务
- 节点服务
要使用当前的 OpenShift Container Platform CA 重新部署 master、etcd 和节点证书，请切换到 playbook 目录并运行此 playbook，指定您的清单文件：
cd /usr/share/ansible/openshift-ansible
ansible-playbook -i <inventory_file> \
playbooks/redeploy-certificates.yml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -i <inventory_file> \
playbooks/redeploy-certificates.yml
如果 OpenShift Container Platform CA 被重新部署为 openshift-master/redeploy-openshift-ca.yml playbook，则必须将 -e openshift_redeploy_openshift_ca=true 添加到这个命令。
12.3.2. 重新部署新的或自定义 OpenShift Container Platform CA
openshift-master/redeploy-openshift-ca.yml playbook 通过生成新的 CA 证书并将更新的捆绑包分发到所有组件，包括客户端 kubeconfig 文件和可信 CA( CA-trust) 的节点数据库 (CA-trust)。
这还包括以下串行重启：
- 主服务
- 节点服务
- docker
另外，您可以在重新部署证书时 指定自定义 CA 证书，而不依赖于 OpenShift Container Platform 生成的 CA。
当主服务重启时，registry 和路由器可以继续与 master 通信，而没有重新部署，因为主设备的 serving 证书相同，并且注册表和路由器仍然有效。
要重新部署新生成的或自定义 CA：
如果要使用自定义 CA，请在清单文件中设置以下变量。要使用当前的 CA，请跳过这一步。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果 CA 证书由中间 CA 发布，则捆绑的证书必须包含 CA 的完整链（中间和 root 证书）来验证子证书。
例如：
cat intermediate/certs/intermediate.cert.pem \ certs/ca.cert.pem >> intermediate/certs/ca-chain.cert.pem certs/ca.cert.pem >> intermediate/certs/ca-chain.cert.pem$ cat intermediate/certs/intermediate.cert.pem \ certs/ca.cert.pem >> intermediate/certs/ca-chain.cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 进入 playbook 目录并运行 openshift-master/redeploy-openshift-ca.yml playbook，指定您的清单文件：
cd /usr/share/ansible/openshift-ansible ansible-playbook -i <inventory_file> \ playbooks/openshift-master/redeploy-openshift-ca.yml$ cd /usr/share/ansible/openshift-ansible $ ansible-playbook -i <inventory_file> \ playbooks/openshift-master/redeploy-openshift-ca.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新的 OpenShift Container Platform CA 已就位，每当您想要在所有组件上重新部署由新 CA 签名的证书时，请使用 redeploy-certificates.yml playbook。
重要在新的 OpenShift Container Platform CA 之后使用 redeploy-certificates.yml playbook 时，您必须在 playbook 命令中添加
-e openshift_redeploy_openshift_ca=true。
12.3.3. 重新部署新的 etcd CA
openshift-etcd/redeploy-ca.yml playbook 通过生成新的 CA 证书来重新部署 etcd CA 证书，并将更新的捆绑包分发到所有 etcd peers 和 master 客户端。
这还包括以下串行重启：
- etcd
- 主服务
重新部署新生成的 etcd CA：
运行 openshift-etcd/redeploy-ca.yml playbook，指定您的清单文件：
cd /usr/share/ansible/openshift-ansible ansible-playbook -i <inventory_file> \ playbooks/openshift-etcd/redeploy-ca.yml$ cd /usr/share/ansible/openshift-ansible $ ansible-playbook -i <inventory_file> \ playbooks/openshift-etcd/redeploy-ca.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
首次运行 playbook/openshift-etcd/redeploy-ca.yml playbook 后，包含 CA 符号器的压缩捆绑包将保留到 /etc/etcd/etcd_ca.tgz 中。因为生成新 etcd 证书需要 CA 签名者，所以备份它们非常重要。
如果 playbook 再次运行，因为预注意它不会在磁盘上覆盖这个捆绑包。要再次运行 playbook，请备份并移动该路径中的捆绑包，然后运行 playbook。
当新的 etcd CA 已就绪后，每当您希望使用由 etcd 对等和 master 客户端上的新的 etcd CA 签发的证书进行重新部署时，您可以自行决定使用 openshift-etcd/redeploy-certificates.yml playbook。另外，除了 etcd peers 和 master 客户端外，您还可以使用 redeploy-certificates.yml playbook 为 OpenShift Container Platform 组件重新部署证书。
etcd 证书重新部署可能会导致将 串行 复制到所有 master 主机上。
12.3.4. 重新部署 Master 和 Web 控制台证书
openshift-master/redeploy-certificates.yml playbook 会重新部署 master 证书和密钥。这包括 master 服务的串行重启。
要重新部署 master 证书和密钥，请切换到 playbook 目录并运行此 playbook，指定您的清单文件：
cd /usr/share/ansible/openshift-ansible
ansible-playbook -i <inventory_file> \
playbooks/openshift-master/redeploy-certificates.yml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -i <inventory_file> \
playbooks/openshift-master/redeploy-certificates.yml运行此 playbook 后，您必须通过删除包含服务证书的现有 secret 或密钥对 来重新生成任何服务签名证书或密钥对，或删除并重新添加注解到适当的服务。
如果需要，您可以在清单文件中设置 openshift_redeploy_service_signer=false 参数，以跳过对服务签名证书的重新部署。如果在清单文件中设置了 openshift_redeploy_openshift_ca=true 和 openshift_redeploy_service_signer=true，则服务签名证书会在重新部署 master 证书时重新部署。如果设置了 openshift_redeploy_openshift_ca=false 或省略了参数，则服务 signer 证书永远不会重新部署。
12.3.5. 仅重新部署指定证书
openshift-master/redeploy-named-certificates.yml playbook 只重新部署命名的证书。运行此 playbook 也会完成 master 服务的串行重启。
要仅重新部署指定证书，请更改到包含 playbook 的目录，并运行此 playbook。
cd /usr/share/ansible/openshift-ansible
ansible-playbook -i <inventory_file> \
playbooks/openshift-master/redeploy-named-certificates.yml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -i <inventory_file> \
playbooks/openshift-master/redeploy-named-certificates.yml
ansible 清单文件中的 _ openshift_master_named_certificates_ 参数必须包含与 master-config.yaml 文件中同名的证书。如果更改了 certfile 和 keyfile 的名称，您必须更新每个 master-config.yaml 文件中的命名证书参数，然后重新启动 api 和 controllers 服务。带有完整 ca 链的 cafile 已添加到 /etc/origin/master/ca-bundle.crt 中。
12.3.6. 只重新部署 etcd 证书
openshift-etcd/redeploy-certificates.yml playbook 只重新部署包含 master 客户端证书的 etcd 证书。
这还包括以下串行重启：
- etcd
- 主服务。
要重新部署 etcd 证书，请切换到 playbook 目录并运行此 playbook，指定您的清单文件：
cd /usr/share/ansible/openshift-ansible
ansible-playbook -i <inventory_file> \
playbooks/openshift-etcd/redeploy-certificates.yml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -i <inventory_file> \
playbooks/openshift-etcd/redeploy-certificates.yml12.3.7. 重新部署节点证书
默认情况下，节点证书有效期为一年。OpenShift Container Platform 会在节点接近到期时自动轮转节点证书。如果没有配置自动批准，您必须手动批准证书签名请求(CSR)。
如果您需要重新部署证书，因为 CA 证书已被更改，您可以使用 -e openshift_redeploy_openshift_ca=true 标记的 playbooks/redeploy-certificates.yml playbook。详情请参阅 使用当前 OpenShift Container Platform 和 etcd CA 重新部署所有证书。在运行此 playbook 时，CSR 会被自动批准。
12.3.8. 只重新部署 Registry 或路由器证书
openshift-hosted/redeploy-registry-certificates.yml 和 openshift-hosted/redeploy-router-certificates.yml playbook 替换 registry 和路由器的安装程序创建的证书。如果自定义证书用于这些组件，请参阅 重新部署自定义 registry 或路由器证书 来手动替换它们。
12.3.8.1. 只重新部署 registry 证书
要重新部署 registry 证书，请切换到 playbook 目录并运行以下 playbook，指定您的清单文件：
cd /usr/share/ansible/openshift-ansible
ansible-playbook -i <inventory_file> \
playbooks/openshift-hosted/redeploy-registry-certificates.yml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -i <inventory_file> \
playbooks/openshift-hosted/redeploy-registry-certificates.yml12.3.8.2. 只重新部署路由器证书
要重新部署路由器证书，请切换到 playbook 目录并运行以下 playbook，指定您的清单文件：
cd /usr/share/ansible/openshift-ansible
ansible-playbook -i <inventory_file> \
playbooks/openshift-hosted/redeploy-router-certificates.yml
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -i <inventory_file> \
playbooks/openshift-hosted/redeploy-router-certificates.yml12.3.9. 重新部署自定义 registry 或路由器证书
当因为重新部署了 CA 节点被撤离时，registry 和路由器 pod 会重启。如果 registry 和路由器证书也未被新的 CA 重新部署，这可能会导致中断，因为它们无法使用其旧证书访问 master。
12.3.9.1. 手动重新部署 registry 证书
要手动重新部署 registry 证书，您必须将新的 registry 证书添加到名为 registry-certificates 的 secret 中，然后重新部署 registry：
使用以下步骤的其余部分切换到
default项目：oc project default
$ oc project defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您的 registry 最初是在 OpenShift Container Platform 3.1 或更早版本上创建，它可能仍在使用环境变量来存储证书（这已被淘汰使用 secret）。
运行以下命令，并查找
OPENSHIFT_CA_DATA、OPENSHIFT_CERT_DATA、OPENSHIFT_KEY_DATA环境变量：oc set env dc/docker-registry --list
$ oc set env dc/docker-registry --listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果不存在，请跳过这一步。如果这样做，请创建以下
ClusterRoleBinding：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 然后，运行以下命令来删除环境变量：
oc set env dc/docker-registry OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-
$ oc set env dc/docker-registry OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
本地设置以下环境变量使其更复杂：
REGISTRY_IP=`oc get service docker-registry -o jsonpath='{.spec.clusterIP}'` REGISTRY_HOSTNAME=`oc get route/docker-registry -o jsonpath='{.spec.host}'`$ REGISTRY_IP=`oc get service docker-registry -o jsonpath='{.spec.clusterIP}'` $ REGISTRY_HOSTNAME=`oc get route/docker-registry -o jsonpath='{.spec.host}'`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建新 registry 证书：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仅从 Ansible 主机清单文件中列出的第一个 master 运行
oc adm命令，默认为 /etc/ansible/hosts。使用新的 registry 证书更新
registry-certificatessecret：oc create secret generic registry-certificates \ --from-file=/etc/origin/master/registry.crt,/etc/origin/master/registry.key \ -o json --dry-run | oc replace -f -$ oc create secret generic registry-certificates \ --from-file=/etc/origin/master/registry.crt,/etc/origin/master/registry.key \ -o json --dry-run | oc replace -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重新部署 registry：
oc rollout latest dc/docker-registry
$ oc rollout latest dc/docker-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.3.9.2. 手动重新部署路由器证书
要手动重新部署路由器证书，您必须将新的路由器证书添加到名为 router-certs 的 secret 中，然后重新部署路由器：
使用以下步骤的其余部分切换到
default项目：oc project default
$ oc project defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您的路由器最初是在 OpenShift Container Platform 3.1 或更早版本创建的，它可能仍然使用环境变量来存储证书，这已被使用 service serving 证书 secret。
运行以下命令并查找
OPENSHIFT_CA_DATA、OPENSHIFT_CERT_DATA、OPENSHIFT_KEY_DATA环境变量：oc set env dc/router --list
$ oc set env dc/router --listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果这些变量存在，请创建以下
ClusterRoleBinding：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果存在这些变量，请运行以下命令删除它们：
oc set env dc/router OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-
$ oc set env dc/router OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
获取证书。
- 如果您使用外部证书颁发机构(CA)为证书进行签名，请创建新的证书并根据内部流程将其提供给 OpenShift Container Platform。
如果使用内部 OpenShift Container Platform CA 签署证书，请运行以下命令：
重要以下命令生成内部签名的证书。它仅被信任 OpenShift Container Platform CA 的客户端信任。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这些命令生成以下文件：
- 名为 router.crt 的新证书。
- 签名 CA 证书链 /etc/origin/master/ca.crt 的副本。如果您使用中间 CA，则此链可以包含多个证书。
- 对应的名为 router.key 的私钥。
创建新文件以串联生成的证书：
cat router.crt /etc/origin/master/ca.crt router.key > router.pem
$ cat router.crt /etc/origin/master/ca.crt router.key > router.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意只有在使用由 OpenShift CA 签名的证书时，此步骤才有效。如果使用自定义证书，则应该使用正确的 CA 链的文件而不是
/etc/origin/master/ca.crt。在生成新的 secret 前，备份当前 secret：
oc get -o yaml --export secret router-certs > ~/old-router-certs-secret.yaml
$ oc get -o yaml --export secret router-certs > ~/old-router-certs-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建新 secret 以容纳新证书和密钥，并替换现有 secret 的内容：
oc create secret tls router-certs --cert=router.pem \ --key=router.key -o json --dry-run | \ oc replace -f -$ oc create secret tls router-certs --cert=router.pem \1 --key=router.key -o json --dry-run | \ oc replace -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- router.pem 是包含您生成的证书的串联的文件。
重新部署路由器：
oc rollout latest dc/router
$ oc rollout latest dc/routerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 最初部署路由器时，会将注解添加到路由器的服务，该服务自动创建一个名为
router-metrics-tls的 服务证书 secret。要手动重新部署
router-metrics-tls证书，可通过删除 secret、删除并重新添加注解到路由器服务来重新创建服务证书，然后重新部署router-metrics-tlssecret：从
router服务中删除以下注解：oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name- \ service.alpha.openshift.io/serving-cert-signed-by-$ oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name- \ service.alpha.openshift.io/serving-cert-signed-by-Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除现有的
router-metrics-tlssecret。oc delete secret router-metrics-tls
$ oc delete secret router-metrics-tlsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重新添加注解：
oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name=router-metrics-tls$ oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name=router-metrics-tlsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.4. 管理证书签名请求
集群管理员可以查看证书签名请求(CSR)并批准或拒绝它们。
12.4.1. 查看证书签名请求
您可以查看证书签名请求(CSR)的列表。
获取当前 CSR 列表。
oc get csr
$ oc get csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看 CSR 的详细信息以验证其是否有效：
oc describe csr <csr_name>
$ oc describe csr <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>是当前 CSR 列表中 CSR 的名称。
12.4.2. 批准证书签名请求
您可以使用 oc certificate approve 命令手动批准证书签名请求(CSR)。
批准 CSR：
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approveCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.4.3. 拒绝证书签名请求
您可以使用 oc certificate deny 命令手动拒绝证书签名请求(CSR)。
拒绝 CSR：
oc adm certificate deny <csr_name>
$ oc adm certificate deny <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>是当前 CSR 列表中 CSR 的名称。
12.4.4. 配置证书签名请求的自动批准
您可以在安装集群时将以下参数添加到 Ansible 清单文件，来配置节点证书签名请求(CSR)：
openshift_master_bootstrap_auto_approve=true
openshift_master_bootstrap_auto_approve=true添加此参数可让使用 bootstrap 凭证生成的所有 CSR，或者从之前验证的节点中批准，而无需管理员干预。
如需更多信息，请参阅配置集群变量。
第 13 章 配置身份验证和用户代理
13.1. 概述
OpenShift Container Platform master 包含内置的 OAuth 服务器。开发人员和管理员获取 OAuth 访问令牌，以完成自身的 API 身份验证。
作为管理员，您可以使用 master 配置文件 配置 OAuth，以指定身份提供程序。最好 在集群安装过程中 配置身份提供程序，但您可以在安装后配置它。
OpenShift Container Platform 用户名不能包括 /、: 和 %。
Deny All identity provider 被默认使用，它拒绝对所有用户名和密码的访问。要允许访问，您必须选择不同的身份提供程序并配置 master 配置文件（默认为 /etc/origin/master/master-config.yaml ）。
当您运行没有配置文件的 master 时，Allow All identity provider 会被默认使用，它允许任何非空用户名和密码登录。这可用于测试目的。要使用其他身份提供程序，或者修改任何 token, grant, 或 session options，您必须从配置文件运行 master。
需要分配的角色以通过外部用户管理设置。
在修改了身份提供程序后，您必须重启 master 服务才能使更改生效：
master-restart api master-restart controllers
# master-restart api
# master-restart controllers13.2. 身份提供程序参数
所有身份提供程序都有四个参数：
| 参数 | 描述 |
|---|---|
|
| 此提供程序名称作为前缀放在提供程序用户名前，以此组成身份名称。 |
|
|
为
要防止跨站点请求伪造 (CSRF) 攻击，只有在请求上存在 |
|
|
为
如果您希望在重定向到身份提供程序登录前将用户发送到品牌页面，然后在 master 配置文件中设置 |
|
| 定义在用户登录时如何将新身份映射到用户。输入以下值之一：
|
在添加或更改身份提供程序时，您可以通过把 mappingMethod 参数设置为 add，将新提供程序中的身份映射到现有的用户。
13.3. 配置身份提供程序
OpenShift Container Platform 不支持为同一身份提供程序配置多个 LDAP 服务器。但是，您可以为更复杂的配置（如 LDAP 故障转移 ）扩展基本身份验证。
您可以使用这些参数在安装过程中或安装后定义身份提供程序。
13.3.1. 使用 Ansible 配置身份提供程序
对于初始集群安装，但 Deny All identity provider 被默认配置，但可在安装过程中配置 openshift_master_identity_providers 参数。OAuth 配置中的会话选项也可在清单文件中配置。
使用 Ansible 的用户身份供应商配置示例
- 1
- 如果您只为 LDAP 身份提供程序在
openshift_master_identity_providers参数中指定了'insecure': 'true'，您可以省略 CA 证书。 - 2 3 4
- 如果您在运行 playbook 的主机上指定一个文件，则其内容将复制到 /etc/origin/master/<identity_provider_name>_<identity_provider_type>_ca.crt 文件中。身份供应商的名称是
openshift_master_identity_providers参数的值，ldap,openid, 或request_header。如果您没有指定 CA 文本或本地 CA 文件的路径，您必须将 CA 证书放在该位置。如果指定多个身份提供程序，则必须手动放置每个供应商的 CA 证书。您无法更改此位置。
您可以指定多个身份提供程序。如果这样做，您必须将每个身份提供程序的 CA 证书放在 /etc/origin/master/ 目录中。例如，您可以在 openshift_master_identity_providers 值中包含以下供应商：
您必须将这些身份提供程序的 CA 证书放在以下文件中：
- /etc/origin/master/foo_openid_ca.crt
- /etc/origin/master/bar_openid_ca.crt
- /etc/origin/master/baz_requestheader_ca.crt
13.3.2. 在 master 配置文件中配置身份提供程序
您可以通过修改 master 主配置文件，配置 master 主机以使用所需的身份提供程序进行身份验证。
例 13.1. master 配置文件中的身份提供程序配置示例
当设置为默认的 声明 值时，如果身份映射到之前存在的用户名，OAuth 将失败。
13.3.2.1. 使用 lookup 映射方法时手动置备用户
使用 lookup 映射方法时，用户置备由外部系统通过 API 进行。通常，身份在登录时自动映射到用户。'lookup' 映射方法自动禁用这个自动映射，这需要您手动置备用户。
如需有关身份对象的更多信息，请参阅 Identity user API obejct。
如果使用 lookup 映射方法，请在配置身份提供程序后为每个用户执行以下步骤：
如果还没有创建，创建一个 OpenShift Container Platform 用户：
oc create user <username>
$ oc create user <username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，以下命令会创建一个 OpenShift Container Platform 用户
bob：oc create user bob
$ oc create user bobCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果尚未创建，请创建一个 OpenShift Container Platform 身份。使用身份提供程序的名称，并在身份提供程序范围内唯一代表此身份的名称：
oc create identity <identity-provider>:<user-id-from-identity-provider>
$ oc create identity <identity-provider>:<user-id-from-identity-provider>Copy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;identity-provider> 是 master 配置中身份提供程序的名称，如下面的相应身份提供程序部分所示。例如，以下命令会创建一个身份提供程序
ldap_provider和身份提供程序用户名bob_s的身份。oc create identity ldap_provider:bob_s
$ oc create identity ldap_provider:bob_sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为创建用户和身份创建 user/identity 映射：
oc create useridentitymapping <identity-provider>:<user-id-from-identity-provider> <username>
$ oc create useridentitymapping <identity-provider>:<user-id-from-identity-provider> <username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，以下命令将身份映射到用户：
oc create useridentitymapping ldap_provider:bob_s bob
$ oc create useridentitymapping ldap_provider:bob_s bobCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.3.3. 允许所有
在 identityProviders 小节中设置 AllowAllPasswordIdentityProvider，以允许任何非空用户名和密码登录。
例 13.2. 使用 AllowAllPasswordIdentityProvider 的 master 配置
13.3.4. 拒绝所有
在 identityProviders 小节中设置 DenyAllPasswordIdentityProvider，以拒绝对所有用户名和密码的访问。
例 13.3. 使用 DenyAllPasswordIdentityProvider 的 master 配置
13.3.5. HTPasswd
在 identityProviders 小节中设置 HTPasswdPasswordIdentityProvider，针对使用 htpasswd 生成的文件验证用户名和密码。
htpasswd 工具程序位于 httpd-tools 软件包中：
yum install httpd-tools
# yum install httpd-tools
OpenShift Container Platform 支持 Bcrypt、SHA-1 和 MD5 加密哈希功能，而 MD5 是 htpasswd 的默认值。目前不支持明文、加密文本和其他散列功能。
如果修改时间更改，则无格式文件重新读取，无需重新启动服务器。
由于 OpenShift Container Platform master API 现在作为静态 pod 运行，因此您必须在 /etc/origin/master/ 中创建 HTPasswdPasswordIdentityProvider htpasswd 文件，使其可以被容器读取。
使用 htpasswd 命令：
要创建带有用户名和散列密码的平面文件，请运行：
htpasswd -c /etc/origin/master/htpasswd <user_name>
$ htpasswd -c /etc/origin/master/htpasswd <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 然后，输入 并确认该用户的明文密码。该命令将生成散列版本的密码。
例如：
htpasswd -c /etc/origin/master/htpasswd user1 New password: Re-type new password: Adding password for user user1
htpasswd -c /etc/origin/master/htpasswd user1 New password: Re-type new password: Adding password for user user1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您可以包含
-b选项，用于在命令行中提供密码：htpasswd -c -b <user_name> <password>
$ htpasswd -c -b <user_name> <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
htpasswd -c -b file user1 MyPassword!
$ htpasswd -c -b file user1 MyPassword! Adding password for user user1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
要在文件中添加或更新登录，请运行：
htpasswd /etc/origin/master/htpasswd <user_name>
$ htpasswd /etc/origin/master/htpasswd <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要从文件中删除登录，请运行：
htpasswd -D /etc/origin/master/htpasswd <user_name>
$ htpasswd -D /etc/origin/master/htpasswd <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例 13.4. 使用 HTPasswdPasswordIdentityProvider 的 master 配置
13.3.6. Keystone
Keystone 是一个提供身份、令牌、目录和策略服务的 OpenStack 项目。您可以将 OpenShift Container Platform 集群与 Keystone 集成，以便通过配置为将用户存储在内部数据库中的 OpenStack Keystone v3 服务器启用共享身份验证。此配置允许用户使用其 Keystone 凭证登录 OpenShift Container Platform。
您可以配置与 Keystone 的集成，以便 OpenShift Container Platform 的新用户基于 Keystone 用户名或者唯一 Keystone ID。使用这两种方法时，用户可以输入其 Keystone 用户名和密码进行登录。使 OpenShift Container Platform 用户基于 Keystone ID 更为安全。如果删除了某一 Keystone 用户并使用其用户名创建了新的 Keystone 用户，新用户或许能够访问旧用户的资源。
13.3.6.1. 在 master 上配置身份验证
如果您有：
已完成 Openshift 的安装，然后将 /etc/origin/master/master-config.yaml 文件复制到新目录中，例如：
cd /etc/origin/master mkdir keystoneconfig; cp master-config.yaml keystoneconfig
$ cd /etc/origin/master $ mkdir keystoneconfig; cp master-config.yaml keystoneconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 尚未安装 OpenShift Container Platform，然后启动 OpenShift Container Platform API 服务器，指定(future)OpenShift Container Platform master 的主机名，以及一个用于存储由 start 命令创建的配置文件的目录：
openshift start master --public-master=<apiserver> --write-config=<directory>
$ openshift start master --public-master=<apiserver> --write-config=<directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
openshift start master --public-master=https://myapiserver.com:8443 --write-config=keystoneconfig
$ openshift start master --public-master=https://myapiserver.com:8443 --write-config=keystoneconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果要使用 Ansible 安装，您必须将
identityProvider配置添加到 Ansible playbook 中。如果在使用 Ansible 安装后使用以下步骤手动修改配置，那么每当您重新运行安装工具或升级时，您都会丢失任何修改。
编辑新的 keystoneconfig/master-config.yaml 文件的
identityProviders小节，并复制示例KeystonePasswordIdentityProvider配置并粘贴它来替换现有的小节：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 此提供程序名称作为前缀放在提供程序用户名前，以此组成身份名称。
- 2
- 为
true时，来自非 Web 客户端（如 CLI）的未经身份验证的令牌请求会为此提供程序发送WWW-Authenticate质询标头。 - 3
- 为
true时，来自 Web 客户端（如 Web 控制台）的未经身份验证的令牌请求会重定向到由该供应商支持的登录页面。 - 4
- 控制如何在此提供程序的身份和用户对象之间建立映射，如上 所述。
- 5
- Keystone 域名。在 Keystone 中，用户名是特定于域的。只支持一个域。
- 6
- 用于连接到 Keystone 服务器的 URL（必需）。
- 7
- 可选：用于验证所配置 URL 的服务器证书的证书捆绑包。
- 8
- 可选：向配置的 URL 发出请求时要出现的客户端证书。
- 9
- 客户端证书的密钥。如果指定了
certFile，则需要此项。 - 10
- 为
true时，表示用户通过 Keystone ID 进行身份验证，而不是由 Keystone 用户名进行身份验证。设置为false以根据用户名进行身份验证。
对
identityProviders小节进行以下修改：-
更改提供程序
名称("my_keystone_provider")以匹配您的 Keystone 服务器。此名称作为前缀放在提供程序用户名前，以此组成身份名称。 -
如果需要，更改
mappingMethod来控制如何在提供程序的身份和用户对象之间建立映射。 -
将
domainName更改为 OpenStack Keystone 服务器的域名。在 Keystone 中，用户名是特定于域的。只支持一个域。 -
指定用于连接 OpenStack Keystone 服务器的
url。 -
另外，要根据 Keystone ID（而非 Keystone 用户名）验证用户身份，
可将KeystoneIdentity设置为true。 -
（可选）将
ca更改为证书捆绑包，以用于验证所配置 URL 的服务器证书。 -
（可选）将
certFile更改为客户端证书，使其在向配置的 URL 发出请求时显示。 -
如果指定了
certFile，您必须将keyFile更改为客户端证书的密钥。
-
更改提供程序
- 保存您的更改并关闭该文件。
启动 OpenShift Container Platform API 服务器，指定您刚才修改的配置文件：
openshift start master --config=<path/to/modified/config>/master-config.yaml
$ openshift start master --config=<path/to/modified/config>/master-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
配置之后，系统会提示您使用其 Keystone 凭据登录 OpenShift Container Platform Web 控制台。
13.3.6.2. 使用 Keystone 身份验证创建用户
在 OpenShift Container Platform 中与外部身份验证供应商（如本例中为 Keystone）集成时，您不会在 OpenShift Container Platform 中创建用户。Keystone 是记录系统，表示用户在 Keystone 数据库中定义用户，并且配置的身份验证服务器的有效 Keystone 用户名的任何用户都可以登录。
要为 OpenShift Container Platform 添加用户，用户必须存在于 Keystone 数据库中，如果需要，必须为该用户创建新的 Keystone 帐户。
13.3.6.3. 验证用户
登录一个或多个用户后，您可以运行 oc get users 来查看用户列表并验证用户是否已成功创建：
例 13.5. oc get users 命令的输出
oc get users
$ oc get users
NAME UID FULL NAME IDENTITIES
bobsmith a0c1d95c-1cb5-11e6-a04a-002186a28631 Bob Smith keystone:bobsmith - 1
- OpenShift Container Platform 中的身份由作为 Keystone 用户名前缀的身份提供商名称组成。
在这里，您可能需要 了解如何管理用户角色。
13.3.7. LDAP 身份验证
在 identityProviders 小节中设置 LDAPPasswordIdentityProvider，以使用简单的绑定身份验证根据 LDAPv3 服务器验证用户名和密码。
如果您需要 LDAP 服务器故障转移，而不是按照以下步骤，通过 为 LDAP 故障转移配置 SSSD 来扩展基本验证方法。
在身份验证过程中，搜索 LDAP 目录中与提供的用户名匹配的条目。如果找到一个唯一匹配项，则尝试使用该条目的可分辨名称 (DN) 以及提供的密码进行简单绑定。
执行下面这些步骤：
-
通过将配置的
url中的属性和过滤器与用户提供的用户名组合来生成搜索过滤器。 - 使用生成的过滤器搜索目录。如果搜索返回的不是一个条目，则拒绝访问。
- 尝试使用搜索所获条目的 DN 和用户提供的密码绑定到 LDAP 服务器。
- 如果绑定失败，则拒绝访问。
- 如果绑定成功，则将配置的属性用作身份、电子邮件地址、显示名称和首选用户名来构建一个身份。
配置的 url 是 RFC 2255 URL，指定要使用的 LDAP 主机和搜索参数。URL 的语法是：
ldap://host:port/basedn?attribute?scope?filter
ldap://host:port/basedn?attribute?scope?filter对于以上示例：
| URL 组件 | 描述 |
|---|---|
|
|
对于常规 LDAP，使用 |
|
|
LDAP 服务器的名称和端口。LDAP 默认为 |
|
| 所有搜索都应从中开始的目录分支的 DN。至少，这必须是目录树的顶端，但也可指定目录中的子树。 |
|
|
要搜索的属性。虽然 RFC 2255 允许使用逗号分隔属性列表，但无论提供多少个属性，都仅使用第一个属性。如果没有提供任何属性，则默认使用 |
|
|
搜索的范围。可以是 |
|
|
有效的 LDAP 搜索过滤器。如果未提供，则默认为 |
在进行搜索时，属性、过滤器和提供的用户名会组合在一起，创建类似如下的搜索过滤器：
(&(<filter>)(<attribute>=<username>))
(&(<filter>)(<attribute>=<username>))例如，可考虑如下 URL：
ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)
ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)
当客户端尝试使用用户名 bob 连接时，生成的搜索过滤器将为 (&(enabled=true)(cn=bob))。
如果 LDAP 目录需要身份验证才能搜索，请指定用于执行条目搜索的 bindDN 和 bindPassword。
使用 LDAPPasswordIdentityProvider 的 master 配置
- 1
- 此提供程序名称作为前缀放在返回的用户 ID 前，以此组成身份名称。
- 2
- 为
true时，来自非 Web 客户端（如 CLI）的未经身份验证的令牌请求会为此提供程序发送WWW-Authenticate质询标头。 - 3
- 为
true时，来自 Web 客户端（如 Web 控制台）的未经身份验证的令牌请求会重定向到由该供应商支持的登录页面。 - 4
- 控制如何在此提供程序的身份和用户对象之间建立映射，如上 所述。
- 5
- 用作身份的属性列表。使用第一个非空属性。至少需要一个属性。如果列出的属性都没有值，身份验证会失败。
- 6
- 用作电子邮件地址的属的列表。使用第一个非空属性。
- 7
- 用作显示名称的属性列表。使用第一个非空属性。
- 8
- 为此身份置备用户时用作首选用户名的属性列表。使用第一个非空属性。
- 9
- 在搜索阶段用来绑定的可选 DN。
- 10
- 在搜索阶段用来绑定的可选密码。此值也可在 环境变量、外部文件或加密文件 中提供。
- 11
- 用于验证所配置 URL 的服务器证书的证书捆绑包。此文件的内容复制到 /etc/origin/master/<identity_provider_name>_ldap_ca.crt 文件中。身份提供程序名称是
openshift_master_identity_providers参数的值。如果您没有指定 CA 文本或本地 CA 文件的路径，您必须将 CA 证书放在/etc/origin/master/目录中。如果指定多个身份提供程序，您必须手动将每个供应商的 CA 证书放在/etc/origin/master/目录中。您无法更改此位置。只有在清单文件中设置了insecure: false时，才会定义证书捆绑包。 - 12
- 为
true时，不会对服务器进行 TLS 连接。为false时，ldaps://URL 使用 TLS 进行连接，并且ldap://URL 升级到 TLS。 - 13
- RFC 2255 URL，指定要使用的 LDAP 主机和搜索参数，如上所述。
要将用户列在 LDAP 集成的白名单中，请使用 lookup 映射方法。在允许从 LDAP 登录前，集群管理员必须为每个 LDAP 用户创建身份和用户对象。
13.3.8. 基本身份验证（远程）
基本身份验证是一种通用后端集成机制，用户可以使用针对远程身份提供程序验证的凭证来登录 OpenShift Container Platform。
由于基本身份验证是通用的，因此您可以在高级身份验证配置中使用此身份提供程序。您可以配置 LDAP 故障转移，或使用 容器化基本身份验证 存储库作为另一个高级远程基本身份验证配置的起点。
基本身份验证必须使用 HTTPS 连接到远程服务器，以防止遭受用户 ID 和密码嗅探以及中间人攻击。
配置了 BasicAuthPasswordIdentityProvider 后，用户将其用户名和密码发送到 OpenShift Container Platform，然后通过发出服务器对服务器请求来传递凭证作为 Basic Auth 标头来针对远程服务器验证这些凭证。这要求用户在登录期间向 OpenShift Container Platform 发送凭证。
这只适用于用户名/密码登录机制，并且 OpenShift Container Platform 必须能够向远程身份验证服务器发出网络请求。
在 identityProviders 小节中设置 BasicAuthPasswordIdentityProvider，以使用 server-to-server 基本身份验证请求对远程服务器验证用户名和密码。针对受基本身份验证保护并返回 JSON 的远程 URL 验证用户名和密码。
401 响应表示身份验证失败。
非 200 状态或出现非空“error”键表示出现错误：
{"error":"Error message"}
{"error":"Error message"}
200 状态并带有 sub（subject）键则表示成功：
{"sub":"userid"}
{"sub":"userid"} - 1
- 主体必须是经过身份验证的用户所特有的，而且必须不可修改。
成功响应可能会（可选）提供额外的数据，例如：
使用
name键的显示名称。例如：{"sub":"userid", "name": "User Name", ...}{"sub":"userid", "name": "User Name", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
email键的电子邮件地址。例如：{"sub":"userid", "email":"user@example.com", ...}{"sub":"userid", "email":"user@example.com", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
preferred_username键的首选用户名。这可用在唯一不可改主体是数据库密钥或 UID 且存在更易读名称的情形中。为经过身份验证的身份置备 OpenShift Container Platform 用户时，这可用作提示。例如：{"sub":"014fbff9a07c", "preferred_username":"bob", ...}{"sub":"014fbff9a07c", "preferred_username":"bob", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.3.8.1. 在 master 上配置身份验证
如果您有：
已完成 Openshift 的安装，然后将 /etc/origin/master/master-config.yaml 文件复制到新目录中，例如：
mkdir basicauthconfig; cp master-config.yaml basicauthconfig
$ mkdir basicauthconfig; cp master-config.yaml basicauthconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 尚未安装 OpenShift Container Platform，然后启动 OpenShift Container Platform API 服务器，指定(future)OpenShift Container Platform master 的主机名，以及一个用于存储由 start 命令创建的配置文件的目录：
openshift start master --public-master=<apiserver> --write-config=<directory>
$ openshift start master --public-master=<apiserver> --write-config=<directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
openshift start master --public-master=https://myapiserver.com:8443 --write-config=basicauthconfig
$ openshift start master --public-master=https://myapiserver.com:8443 --write-config=basicauthconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果要使用 Ansible 安装，您必须将
identityProvider配置添加到 Ansible playbook 中。如果在使用 Ansible 安装后使用以下步骤手动修改配置，那么每当您重新运行安装工具或升级时，您都会丢失任何修改。
编辑新的 master-config.yaml 文件的
identityProviders小节，并复制 示例BasicAuthPasswordIdentityProvider配置 并粘贴它来替换现有的小节：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 此提供程序名称作为前缀放在返回的用户 ID 前，以此组成身份名称。
- 2
- 为
true时，来自非 Web 客户端（如 CLI）的未经身份验证的令牌请求会为此提供程序发送WWW-Authenticate质询标头。 - 3
- 为
true时，来自 Web 客户端（如 Web 控制台）的未经身份验证的令牌请求会重定向到由该供应商支持的登录页面。 - 4
- 控制如何在此提供程序的身份和用户对象之间建立映射，如上 所述。
- 5
- 接受基本身份验证标头中凭证的 URL。
- 6
- 可选：用于验证所配置 URL 的服务器证书的证书捆绑包。
- 7
- 可选：向配置的 URL 发出请求时要出现的客户端证书。
- 8
- 客户端证书的密钥。如果指定了
certFile，则需要此项。
对
identityProviders小节进行以下修改：-
将供应商
名称设置为与您的部署的唯一且相关内容。此名称作为前缀放在返回的用户 ID 前，以此组成身份名称。 -
如果需要，设置
mappingMethod来控制如何在提供程序的身份和用户对象之间建立映射。 -
指定
HTTPSURL 用于连接到接受基本身份验证标头中凭证的服务器。 -
（可选）将
ca设置为证书捆绑包，以使用 以验证所配置 URL 的服务器证书，或将其留空，以使用系统信任的根证书。 -
（可选）删除或将
certFile设置为客户端证书，以便在向配置的 URL 发出请求时显示。 -
如果指定了
certFile，您必须将keyFile设置为客户端证书的密钥。
- 保存您的更改并关闭该文件。
启动 OpenShift Container Platform API 服务器，指定您刚才修改的配置文件：
openshift start master --config=<path/to/modified/config>/master-config.yaml
$ openshift start master --config=<path/to/modified/config>/master-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
配置后，系统会提示您使用其基本身份验证凭证登录 OpenShift Container Platform Web 控制台。
13.3.8.2. 故障排除
最常见的问题与后端服务器网络连接相关。要进行简单调试，请在 master 上运行 curl 命令。要测试成功的登录，请将以下示例命令中的 <user> 和 <password> 替换为有效的凭证。要测试无效的登录，请将它们替换为错误的凭证。
curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp
curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp成功响应
200 状态并带有 sub（subject）键则表示成功：
{"sub":"userid"}
{"sub":"userid"}subject 必须是经过身份验证的用户所特有的，而且必须不可修改。
成功响应可能会（可选）提供额外的数据，例如：
使用
name键的显示名称：{"sub":"userid", "name": "User Name", ...}{"sub":"userid", "name": "User Name", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
email键的电子邮件地址：{"sub":"userid", "email":"user@example.com", ...}{"sub":"userid", "email":"user@example.com", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
preferred_username键的首选用户名：{"sub":"014fbff9a07c", "preferred_username":"bob", ...}{"sub":"014fbff9a07c", "preferred_username":"bob", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow preferred_username键可用在唯一不可改主体是数据库密钥或 UID 且存在更易读名称的情形中。为经过身份验证的身份置备 OpenShift Container Platform 用户时，这可用作提示。
失败的响应
-
401响应表示身份验证失败。 -
非
200状态或带有非空“error”键表示错误：{"error":"Error message"}
13.3.9. 请求标头（Request header）
在 identityProviders 小节中设置 RequestHeaderIdentityProvider，以标识请求标头值中的用户，如 X-Remote-User。它通常与设定请求标头值的身份验证代理一起使用。这与 OpenShift Enterprise 2 中的远程用户插件 是，管理员可以提供 Kerberos、LDAP 和许多其他形式的企业身份验证。
您还可以将请求标头身份提供程序用于高级配置，如由社区支持的 SAML 身份验证。请注意，红帽不支持 SAML 验证。
要使用户使用这个身份提供程序进行身份验证，必须通过身份验证代理访问 https://<master>/oauth/authorize （及子路径）。要达到此目的，请将 OAuth 服务器配置为将 OAuth 令牌的未经身份验证的请求重定向到代理到 https://<master>/oauth/authorize 的代理端点。
重定向来自希望基于浏览器型登录流的客户端的未经身份验证请求：
-
将
login参数设置为true。 -
将
provider.loginURL参数设置为身份验证代理 URL，该代理将验证交互式客户端并将其请求代理到https://<master>/oauth/authorize。
重定向来自希望 WWW-Authenticate 质询的客户端的未经身份验证请求：
-
将
challenge参数设置为true。 -
将
provider.challengeURL参数设置为身份验证代理 URL，该代理将验证希望WWW-Authenticate质询的客户端，然后将请求代理到https://<master>/oauth/authorize。
provider.challengeURL 和 provider.loginURL 参数可以在 URL 的查询部分中包含以下令牌：
${url}替换为当前的 URL，进行转义以在查询参数中安全使用。例如：
https://www.example.com/sso-login?then=${url}${query}替换为当前的查询字符串，不进行转义。例如：
https://www.example.com/auth-proxy/oauth/authorize?${query}
如果您期望未经身份验证的请求可以访问 OAuth 服务器，则需要为此此身份提供程序设置 clientCA 参数，以便在检查请求标头检查用户名的标头前检查传入的请求。否则，任何向 OAuth 服务器直接请求都可通过设置请求标头来模拟该提供程序的任何身份。
使用 RequestHeaderIdentityProvider 的 master 配置
- 1
- 此提供程序名称作为前缀放在请求标头中的用户名前，以此组成身份名称。
- 2
RequestHeaderIdentityProvider只能通过重定向到配置的challengeURL来响应请求WWW-Authenticate质询的客户端。配置的 URL 应以WWW-Authenticate质询进行响应。- 3
RequestHeaderIdentityProvider只能通过重定向到配置的loginURL来响应请求登录流的客户端。配置的 URL 应通过登录流做出响应。- 4
- 控制如何在此提供程序的身份和用户对象之间建立映射，如上 所述。
- 5
- 可选：将未经身份验证的
/oauth/authorize请求重定向到的 URL，该请求将验证希望WWW-Authenticate质询的客户端，然后将它们代理到https://<master>/oauth/authorize.${url}替换为当前的 URL，进行转义以在查询参数中安全使用。${query}替换为当前的查询字符串。 - 6
- 可选：将未经身份验证的
/oauth/authorize请求重定向到的 URL，它将验证基于浏览器的客户端，然后将请求代理到https://<master>/oauth/authorize。代理到https://<master>/oauth的 URL 必须以 /authorize 结尾（不含尾部斜杠），并代理子路径，以便 OAuth 批准流正常工作。/authorize${url}替换为当前的 URL，进行转义以在查询参数中安全使用。${query}替换为当前的查询字符串。 - 7
- 可选：PEM 编码的证书捆绑包。如果设置，则必须根据指定文件中的证书颁发机构显示并验证有效的客户端证书，然后才能检查请求标头中的用户名。
- 8
- 可选：通用名称 (
cn) 的列表。如果设定，则必须出示带有指定列表中通用名称 (cn) 的有效客户端证书，然后才能检查请求标头中的用户名。如果为空，则允许任何通用名称。只能与clientCA结合使用。 - 9
- 按顺序查找用户身份的标头名称。第一个包含值的标头被用作身份。必需，不区分大小写。
- 10
- 按顺序查找电子邮件地址的标头名称。第一个包含值的标头被用作电子邮件地址。可选，不区分大小写。
- 11
- 按顺序查找显示名称的标头名称。第一个包含值的标头被用作显示名称。可选，不区分大小写。
- 12
- 按顺序查找首选用户名的标头名称（如果与通过
headers中指定的标头确定的不可变身份不同）。在置备时，第一个包含值的标头用作首选用户名。可选，不区分大小写。
Microsoft Windows 上的 SSPI 连接支持
使用 Microsoft Windows 上的 SSPI 连接支持是技术预览功能。技术预览功能不包括在红帽生产服务级别协议（SLA）中，且其功能可能并不完善。因此，红帽不建议在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
如需红帽技术预览功能支持范围的更多信息，请参阅 https://access.redhat.com/support/offerings/techpreview/。
从版本 3.11 开始，
oc 支持安全支持提供程序接口 (SSPI)，以允许 Microsft Windows 上的 SSO 流。如果您使用请求标头身份提供程序与支持 GSSAPI 的代理将 Active Directory 服务器连接到 OpenShift Container Platform，用户可以通过加入了域的 Microsoft Windows 计算机使用 oc 命令行界面来自动进行 OpenShift Container Platform 身份验证。
使用 Request 标头的 Apache 身份验证
本例在与 master 位于同一主机上配置身份验证代理。在同一主机上让代理和 master 提供方便方便的，可能不适用于您的环境。例如，如果您已在 master 上运行 路由器，端口 443 不可用。
另请务必注意，尽管此参考配置使用 Apache 的 mod_auth_gssapi，但这种引用配置并不是必需的，且如果满足以下要求，您可以轻松地使用其他代理：
-
阻断来自客户端请求的
X-Remote-User标头以防止欺骗。 -
在
RequestHeaderIdentityProvider配置中强制进行客户端证书验证 。 -
使用质询流为所有身份验证请求设置
X-Csrf-Token标头。 -
只有
/oauth/authorize端点及其子路径应代理，并且不应重写重定向，从而使后端服务器可以将客户端发送到正确的位置。 代理到
https://<master>/oauth/authorize的 URL 必须以/authorize结尾（不含尾部斜杠）。例如：-
https://proxy.example.com/login-proxy/authorize?…→https://<master>/oauth/authorize?…
-
代理到
https://<master>/oauth/authorize的 URL 的子路径必须代理到https://<master>/oauth/authorize 的子路径。例如：-
https://proxy.example.com/login-proxy/authorize/approve?…→https://<master>/oauth/authorize/approve?…
-
安装先决条件
通过 Optional channel 获得 mod_auth_gssapi 模块。安装以下软件包：
yum install -y httpd mod_ssl mod_session apr-util-openssl mod_auth_gssapi
# yum install -y httpd mod_ssl mod_session apr-util-openssl mod_auth_gssapiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 生成用于验证提交可信标头的请求的 CA。此 CA 应在 master 身份提供程序配置中用作
clientCA的文件名。oc adm ca create-signer-cert \ --cert='/etc/origin/master/proxyca.crt' \ --key='/etc/origin/master/proxyca.key' \ --name='openshift-proxy-signer@1432232228' \ --serial='/etc/origin/master/proxyca.serial.txt'
# oc adm ca create-signer-cert \ --cert='/etc/origin/master/proxyca.crt' \ --key='/etc/origin/master/proxyca.key' \ --name='openshift-proxy-signer@1432232228' \ --serial='/etc/origin/master/proxyca.serial.txt'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意oc adm ca create-signer-cert命令生成有效 5 年的证书。这可以通过--expire-days选项进行修改，但出于安全原因，建议不要超过这个值。仅从 Ansible 主机清单文件中列出的第一个 master 运行
oc adm命令，默认为 /etc/ansible/hosts。示例：为代理生成客户端证书这可以通过任何 x509 证书工具完成。为方便起见，可以使用
oc admCLI：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意oc adm create-api-client-config命令生成有效期为两年的证书。这可以通过--expire-days选项进行修改，但出于安全原因，建议不要超过这个值。仅从 Ansible 主机清单文件中列出的第一个 master 运行oc adm命令，默认为 /etc/ansible/hosts。
配置 Apache
此代理不需要驻留在与 master 相同的主机上。它使用客户端证书连接到 master，该 master 配置为信任 X-Remote-User 标头。
-
为 Apache 配置创建证书。您通过
SSLProxyMachineCertificateFile参数值指定的证书是用于向服务器验证代理的代理的客户端证书。它必须使用TLS Web 客户端身份验证作为扩展密钥类型。 创建 Apache 配置文件。使用以下模板来提供所需设置和值：
重要仔细检查模板的内容，并根据您的环境自定义其相应的内容。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
配置 master
/etc/origin/master/master-config.yaml 文件中的 identityProviders 小节必须更新：
重启服务
最后，重启以下服务：
systemctl restart httpd master-restart api master-restart controllers
# systemctl restart httpd
# master-restart api
# master-restart controllers验证配置
通过绕过代理来测试。如果您提供正确的客户端证书和标头，则可以请求令牌：
curl -L -k -H "X-Remote-User: joe" \ --cert /etc/pki/tls/certs/authproxy.pem \ https://[MASTER]:8443/oauth/token/request
# curl -L -k -H "X-Remote-User: joe" \ --cert /etc/pki/tls/certs/authproxy.pem \ https://[MASTER]:8443/oauth/token/requestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果没有提供客户端证书，请求应该被拒绝：
curl -L -k -H "X-Remote-User: joe" \ https://[MASTER]:8443/oauth/token/request
# curl -L -k -H "X-Remote-User: joe" \ https://[MASTER]:8443/oauth/token/requestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这应该会显示指向配置的
challengeURL（带有额外查询参数）的重定向：curl -k -v -H 'X-Csrf-Token: 1' \ '<masterPublicURL>/oauth/authorize?client_id=openshift-challenging-client&response_type=token'
# curl -k -v -H 'X-Csrf-Token: 1' \ '<masterPublicURL>/oauth/authorize?client_id=openshift-challenging-client&response_type=token'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这会显示带有
WWW-Authenticate基本质询、协商质询或两个质询都有的 401 响应：curl -k -v -H 'X-Csrf-Token: 1' \ '<redirected challengeURL from step 3 +query>'# curl -k -v -H 'X-Csrf-Token: 1' \ '<redirected challengeURL from step 3 +query>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 测试在使用 Kerberos ticket 并不使用 Kerberos ticket 的情况下登录到
oc命令行：如果您使用
kinit生成了 Kerberos ticket，请将其销毁：kdestroy -c cache_name
# kdestroy -c cache_name1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 提供 Kerberos 缓存的名称。
使用您的 Kerberos 凭证登录到
oc：oc login
# oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在提示符后输入您的 Kerberos 用户名和密码。
从
oc命令行注销：oc logout
# oc logoutCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用您的 Kerberos 凭证获得一个 ticket：
kinit
# kinitCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在提示符后输入您的 Kerberos 用户名和密码。
确认您可以登录到
oc命令行：oc login
# oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果配置正确，您会在不需要单独输入凭证的情况下成功登录。
13.3.10. GitHub 和 GitHub Enterprise
GitHub 使用 OAuth，您可以集成 OpenShift Container Platform 集群以使用该 OAuth 身份验证。OAuth 可以协助 OpenShift Container Platform 和 GitHub 或 GitHub Enterprise 之间的令牌交换流。
您可以使用 GitHub 集成来连接 GitHub 或 GitHub Enterprise。对于 GitHub Enterprise 集成，您必须提供实例的 hostname，并可选择提供要在服务器请求中使用的 ca 证书捆绑包。
除非有所注明，否则以下步骤同时适用于 GitHub 和 GitHub Enterprise。
配置 GitHub 身份验证后，用户可使用 GitHub 凭证登录 OpenShift Container Platform。为防止具有任何 GitHub 用户 ID 的任何人登录 OpenShift Container Platform 集群，您可以将访问权利限制给仅属于特定 GitHub 组织的用户。
13.3.10.1. 在 GitHub 上注册应用程序
注册应用程序：
- 对于 GitHub，点击 Settings → Developer settings → Register a new OAuth application。
- 对于 GitHub Enterprise，前往 GitHub Enterprise 主页，然后点击 Settings → Developer settings → Register a new application。
-
输入应用程序名称，如
My OpenShift Install。 -
输入主页 URL，如
https://myapiserver.com:8443。 - （可选）输入应用程序描述。
输入授权回调 URL，其中 URL 的末尾包含身份提供程序 名称，该名称在 master 配置文件（该配置文件在下一节中配置）的
identityProviders小节中定义：<apiserver>/oauth2callback/<identityProviderName>
<apiserver>/oauth2callback/<identityProviderName>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
https://myapiserver.com:8443/oauth2callback/github/
https://myapiserver.com:8443/oauth2callback/github/Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 点击 Register application。Github 会提供客户端 ID 和客户端 Secret。保持此窗口打开，以便您可以复制这些值并将其粘贴到主配置文件中。
13.3.10.2. 在 master 上配置身份验证
如果您有：
已安装 OpenShift Container Platform，然后将 /etc/origin/master/master-config.yaml 文件复制到新目录中，例如：
cd /etc/origin/master mkdir githubconfig; cp master-config.yaml githubconfig
$ cd /etc/origin/master $ mkdir githubconfig; cp master-config.yaml githubconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 尚未安装 OpenShift Container Platform，然后启动 OpenShift Container Platform API 服务器，指定(future)OpenShift Container Platform master 的主机名，以及一个用于存储由 start 命令创建的配置文件的目录：
openshift start master --public-master=<apiserver> --write-config=<directory>
$ openshift start master --public-master=<apiserver> --write-config=<directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
openshift start master --public-master=https://myapiserver.com:8443 --write-config=githubconfig
$ openshift start master --public-master=https://myapiserver.com:8443 --write-config=githubconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果要使用 Ansible 安装，您必须将
identityProvider配置添加到 Ansible playbook 中。如果在使用 Ansible 安装后使用以下步骤手动修改配置，那么每当您重新运行安装工具或升级时，您都会丢失任何修改。注意使用
openshift 自行启动 master将自动检测主机名，但 GitHub 必须能够重定向到您在注册应用程序时指定的准确主机名。因此，您无法自动检测 ID，因为它可能会重定向到错误的地址。反之，您必须指定 Web 浏览器用来与 OpenShift Container Platform 集群交互的主机名。
编辑新的 master-config.yaml 文件的
identityProviders小节，并复制示例GitHubIdentityProvider配置并粘贴它来替换现有的小节：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 此提供程序名称作为前缀放在 GitHub 数字用户 ID 前，以此组成身份名称。它还可用来构建回调 URL。
- 2
GitHubIdentityProvider无法用于发送WWW-Authenticate质询。- 3
- 为
true时，来自 Web 客户端（如 Web 控制台）的未经身份验证的令牌请求将重定向到 GitHub 以进行登录。 - 4
- 控制如何在此提供程序的身份和用户对象之间建立映射，如上 所述。
- 5
- 对于 GitHub Enterprise，CA 是向服务器发出请求时使用的可选的可信证书颁发机构捆绑包。省略此参数以使用默认系统 root 证书。对于 GitHub，请省略此参数。
- 6
- 注册的 GitHub OAuth 应用程序的客户端 ID。应用程序必须配置有 <
master>/oauth2callback/<identityProviderName> 的回调 URL。 - 7
- GitHub 发布的客户端 secret。此值也可在 环境变量、外部文件或加密文件 中提供。
- 8
- 对于 GitHub Enterprise，您必须提供实例的主机名，如
example.com。这个值必须与 /setup/settings 文件中的 GitHub Enterprisehostname值匹配，且不可包括端口号。对于 GitHub，请省略此参数。 - 9
- 可选的组织列表。如果指定，只有至少是一个所列组织成员的 GitHub 用户才能登录。如果在
clientID中配置的 GitHub OAuth 应用程序不归该组织所有，则组织所有者必须授予第三方访问权限才能使用此选项。这可以在组织管理员第一次登录 GitHub 时完成，也可以在 GitHub 组织设置中完成。不可与teams字段结合使用。 - 10
- 可选的团队列表。如果指定，只有是至少一个列出团队的成员的 GitHub 用户才能登录。如果在
clientID中配置的 GitHub OAuth 应用程序不归该团队的组织所有，则组织所有者必须授予第三方访问权限才能使用此选项。这可以在组织管理员第一次登录 GitHub 时完成，也可以在 GitHub 组织设置中完成。不可与organizations字段结合使用。
对
identityProviders小节进行以下修改：更改供应商
名称，以匹配您在 GitHub 上配置回调 URL。例如，如果您将回调 URL 定义为
https://myapiserver.com:8443/oauth2callback/github/，则name必须是github。-
将
clientID更改为您之前注册的 GitHub 中的客户端 ID。 -
将
clientSecret改为 之前注册的 GitHub 中的 Client Secret。 -
更改
organizations或teams，使其包含一个或多个 GitHub 机构或团队的列表，用户必须具有成员资格才能进行身份验证。如果指定，只有至少是一个列出的机构或团队的成员的 GitHub 用户才能登录。如果未指定，则具有有效 GitHub 帐户的任何人都可以登录。
- 保存您的更改并关闭该文件。
启动 OpenShift Container Platform API 服务器，指定您刚才修改的配置文件：
openshift start master --config=<path/to/modified/config>/master-config.yaml
$ openshift start master --config=<path/to/modified/config>/master-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
配置后，任何登录 OpenShift Container Platform Web 控制台的用户都将提示使用其 GitHub 凭证登录。首次登录时，用户必须点击 授权应用程序 来允许 GitHub 使用其用户名、密码和机构成员资格。然后，用户会被重新重定向到 Web 控制台。
13.3.10.3. 使用 GitHub 身份验证创建用户
当与外部身份验证供应商（如 GitHub）集成时，不会在 OpenShift Container Platform 中创建用户。GitHub 或 GitHub Enterprise 是记录系统，即用户由 GitHub 定义，以及属于指定机构的任何用户可以登录。
要将用户添加到 OpenShift Container Platform，您必须将该用户添加到 GitHub 或 GitHub Enterprise 上的批准机构中，如果需要为用户创建新的 GitHub 帐户。
13.3.10.4. 验证用户
登录一个或多个用户后，您可以运行 oc get users 来查看用户列表并验证用户是否已成功创建：
例 13.6. oc get users 命令的输出
oc get users
$ oc get users
NAME UID FULL NAME IDENTITIES
bobsmith 433b5641-066f-11e6-a6d8-acfc32c1ca87 Bob Smith github:873654 - 1
- OpenShift Container Platform 中的身份由身份提供程序名称和 GitHub 的内部数字用户 ID 组成。这样，如果用户更改 GitHub 用户名或电子邮件，他们仍然可以登录到 OpenShift Container Platform，而不依赖于附加到 GitHub 帐户的凭证。这会创建一个稳定的登录。
在这里，您可能需要了解如何 控制用户角色。
13.3.11. GitLab
在 identityProviders 小节中设置 GitLabIdentityProvider，以使用 GitLab.com 或任何其他 GitLab 实例作为身份提供程序。如果使用 GitLab 版本 7.7.0 到 11.0，您可以使用 OAuth 集成进行连接。如果使用 GitLab 版本 11.1 或更高版本，您可以使用 OpenID Connect (OIDC) 进行连接，而不使用 OAuth。
例 13.7. 使用 GitLabIdentityProvider的 master 配置
- 1
- 此提供程序名称作为前缀放在 GitLab 数字用户 ID 前，以此组成身份名称。它还可用来构建回调 URL。
- 2
- 为
true时，来自非 Web 客户端（如 CLI）的未经身份验证的令牌请求会为此提供程序发送WWW-Authenticate质询标头。这将使用 Resource Owner Password Credentials 授权流从 GitLab 获取访问令牌。 - 3
- 为
true时，来自 Web 客户端（如 Web 控制台）的未经身份验证的令牌请求将重定向到 GitLab 以进行登录。 - 4
- 控制如何在此提供程序的身份和用户对象之间建立映射，如上 所述。
- 5
- 决定是否使用 OAuth 或 OIDC 作为身份验证供应商。设置为
true，以使用 OAuth 和false来使用 OIDC。您必须使用 GitLab.com 或 GitLab 版本 11.1 或更高版本使用 OIDC。如果没有提供值，OAuth 用于连接 GitLab 实例，并使用 OIDC 连接到 GitLab.com。 - 6
- GitLab 提供程序的主机 URL。这可以是
https://gitlab.com/或其他自托管 GitLab 实例。 - 7
- 注册的 GitLab OAuth 应用程序的客户端 ID 。应用程序必须配置有 <
master>/oauth2callback/<identityProviderName> 的回调 URL。 - 8
- GitLab 发布的客户端 secret。此值也可在 环境变量、外部文件或加密文件 中提供。
- 9
- CA 是一个可选的可信证书颁发机构捆绑包，用于在向 GitLab 实例发出请求时使用。若为空，则使用默认的系统根证书。
13.3.12. Google
在 identityProviders 小节中将 GoogleIdentityProvider 设置为将 Google 用作身份提供程序，使用 Google 的 OpenID Connect 集成。
使用 Google 作为身份提供程序要求用户使用 <master>/oauth/token/request 来获取令牌，以便用于命令行工具。
使用 Google 作为身份提供程序时，任何 Google 用户都能与您的服务器进行身份验证。您可以使用 hostedDomain 配置属性将身份验证限制到特定托管域的成员，如下所示。
例 13.8. 使用 GoogleIdentityProvider进行 master 配置
- 1
- 此提供程序名称作为前缀放在 Google 数字用户 ID 前，以此组成身份名称。它还可用来构建的重定向 URL。
- 2
GoogleIdentityProvider无法用于发送WWW-Authenticate质询。- 3
- 当为
true时，来自 web 客户端（如 Web 控制台）的未经身份验证的令牌请求会被重定向到 Google 进行登录。 - 4
- 控制如何在此提供程序的身份和用户对象之间建立映射，如上 所述。
- 5
- 注册的 Google 项目的客户端 ID 。项目必须配置有重定向 URI <
master>/oauth2callback/<identityProviderName>。 - 6
- Google 发布的客户端 secret。此值也可在 环境变量、外部文件或加密文件 中提供。
- 7
- 可选的 hosted domain 以限制登录帐户。如果为空，任何 Google 帐户都可进行身份验证。
13.3.13. OpenID 连接
在 identityProviders 小节中设置 OpenIDIdentityProvider，以使用授权代码流与 OpenID Connect 身份提供程序 集成。
您可以将 Red Hat Single Sign-On 配置为 OpenShift Container Platform 的 OpenID Connect 身份提供程序。
不支持 ID Token 和 UserInfo 解密。
默认情况下，需要 openid 范围。如果必要，可在 extraScopes 字段中指定额外的范围。
声明可读取自从 OpenID 身份提供程序返回的 JWT id_token；若有指定，也可读取自从 UserInfo URL 返回的 JSON。
必须至少配置一个声明，以用作用户的身份。标准的身份声明是 sub。
您还可以指定将哪些声明用作用户的首选用户名、显示名称和电子邮件地址。如果指定了多个声明，则使用第一个带有非空值的声明。标准的声明是：
|
| “subject identifier”的缩写。 用户在签发者处的远程身份。 |
|
|
置备用户时的首选用户名。用户希望使用的简写名称，如 |
|
| 电子邮件地址。 |
|
| 显示名称。 |
如需更多信息，请参阅 OpenID 声明文档。
使用 OpenID Connect 身份提供程序要求用户使用 <master>/oauth/token/request 来获取令牌，以便用于命令行工具。
使用 OpenIDIdentityProvider的标准 master 配置
- 1
- 此提供程序名称作为前缀放在身份声明值前，以此组成身份名称。它还可用来构建的重定向 URL。
- 2
- 为
true时，来自非 Web 客户端（如 CLI）的未经身份验证的令牌请求会为此提供程序发送WWW-Authenticate质询标头。这要求 OpenID 供应商支持 Resource Owner Password Credentials 授权流。 - 3
- 当为
true时，来自 Web 客户端（如 Web 控制台）的未经身份验证的令牌请求会重定向到要登录的授权 URL。 - 4
- 控制如何在此提供程序的身份和用户对象之间建立映射，如上 所述。
- 5
- 在 OpenID 提供程序中注册的客户端的客户端 ID。该客户端必须能够重定向到
<master>/oauth2callback/<identityProviderName>。 - 6
- 客户端机密。此值也可在 环境变量、外部文件或加密文件 中提供。
- 7
- 用作身份的声明的列表。使用第一个非空声明。至少需要一个声明。如果列出的声明都没有值，身份验证会失败。例如，这使用返回的
id_token中的sub声明的值作为用户的身份。 - 8
- OpenID spec 中描述的 授权端点。必须使用
https。 - 9
- OpenID spec 中描述的令牌端点。必须使用
https。
也可以指定自定义证书捆绑包、额外范围、额外授权请求参数和 userInfo URL：
例 13.9. 使用 OpenIDIdentityProvider的完整 Master 配置
13.4. 令牌选项
OAuth 服务器生成两种令牌：
| 访问令牌 | 存在时间较长的令牌，用于授权对 API 的访问。 |
| 授权代码 | 存在时间较短的令牌，仅用于交换访问令牌。 |
使用 tokenConfig 小节来设置令牌选项：
例 13.10. 主配置选项
oauthConfig:
...
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
oauthConfig:
...
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
您可以通过 OAuthClient 对象定义 覆盖 accessTokenMaxAgeSeconds 值。
13.5. 授权选项
当 OAuth 服务器收到用户之前没有授予权限的客户端的令牌请求时，OAuth 服务器采取的操作取决于 OAuth 客户端的授权策略。
当请求令牌的 OAuth 客户端不提供自己的授权策略时，会使用服务器端的默认策略。要配置默认策略，请在 grantConfig 部分中设置 method 值。方法 的有效值有：
|
| 自动批准授权并重试请求。 |
|
| 提示用户批准或拒绝授权。 |
|
| 自动拒绝授权并给客户端返回失败错误。 |
例 13.11. 主配置选项
oauthConfig:
...
grantConfig:
method: auto
oauthConfig:
...
grantConfig:
method: auto13.6. 会话选项
OAuth 服务器在登录和重定向流程期间使用签名和加密的 cookie 会话。
使用 sessionConfig 小节来设置会话选项：
例 13.12. Master 配置会话选项
- 1
- 控制会话的最长期限；会话会在令牌请求完成后自动过期。如果没有启用 auto-grant，只要用户希望批准或拒绝客户端授权请求，就需要会话有效。
- 2
- 用于存储会话的 Cookie 名称。
- 3
- 包含序列化
SessionSecrets对象的文件名。如果为空，则在每次服务器启动时都会生成随机签名和加密 secret。
如果没有指定 sessionSecretsFile，则会在每次主服务器启动时生成一个随机签名和加密 secret。这意味着，如果重启 master，任何正在进行中的登录都将在 master 重新启动时其会话无效。这也意味着它们将无法解码由其他其中一个 master 生成的会话。
要指定要使用的签名和加密 secret，请指定 sessionSecretsFile。这可让您将 secret 值与配置文件分开，并保留可分发的配置文件，例如用于调试目的。
可以在 sessionSecretsFile 中指定多个 secret 来启用轮转。使用列表中第一个 secret，对新会话进行签名和加密。现有会话由每个 secret 进行解密和验证，直到成功为止。
13.7. 防止 CLI 版本与用户代理不匹配
OpenShift Container Platform 实施了一个用户代理，可用于防止应用程序开发人员的 CLI 访问 OpenShift Container Platform API。
OpenShift Container Platform CLI 的用户代理由 OpenShift Container Platform 中的一组值组成：
<command>/<version>+<git_commit> (<platform>/<architecture>) <client>/<git_commit>
<command>/<version>+<git_commit> (<platform>/<architecture>) <client>/<git_commit>例如，在以下情况下：
-
<command> =
oc -
<version> = 客户端版本。例如：
v3.3.0。对位于/api的 Kubernetes API 发出的请求会接收 Kubernetes 版本，对位于/oapi的 OpenShift Container Platform API 发出的请求则会接收 OpenShift Container Platform 版本（如oc version所指定） -
<platform> =
linux -
<architecture> =
amd64 -
<client> =
openshift或kubernetes，具体取决于请求的目标是位于/api的 Kubernetes API 还是位于/oapi的 OpenShift Container Platform API -
<git_commit> = 客户端版本的 Git 提交（例如
f034127）
用户代理将是：
oc/v3.3.0+f034127 (linux/amd64) openshift/f034127
oc/v3.3.0+f034127 (linux/amd64) openshift/f034127您必须在 master 配置文件 /etc/origin/master/master-config.yaml 中配置用户代理。要应用配置，重启 API 服务器：
/usr/local/bin/master-restart api
$ /usr/local/bin/master-restart api
作为 OpenShift Container Platform 管理员，您可以使用 master 配置中的 userAgentMatching 配置设置来防止客户端访问 API。因此，如果客户端使用特定的库或二进制代码，则阻止它们访问 API。
以下用户代理示例拒绝 Kubernetes 1.2 客户端二进制文件、OpenShift Origin 1.1.3 二进制文件，以及 POST 和 PUT httpVerbs ：
管理员也可以拒绝与预期客户端不完全匹配的客户端：
要拒绝将原本包含在一组允许的客户端中的客户端，请结合使用 deniedClients 和 requiredClients 值。以下示例允许除 1.13 之外的所有 1.X 客户端二进制文件：
当客户端的用户代理与配置不匹配时，会出现错误。要确保变异请求匹配，强制白名单。规则映射到特定的操作动词，因此您可以在允许非处理请求时对请求进行攻击。
第 14 章 使用 LDAP 同步组
14.1. 概述
作为 OpenShift Container Platform 管理员，您可以使用组来管理用户、更改其权限，并加强协作。您的组织可能已创建了用户组，并将其存储在 LDAP 服务器中。OpenShift Container Platform 可以将这些 LDAP 记录与 OpenShift Container Platform 内部记录同步，让您能够集中在一个位置管理您的组。OpenShift Container Platform 目前支持与使用以下三种通用模式定义组成员资格的 LDAP 服务器进行组同步：RFC 2307、Active Directory 和增强 Active Directory。
您必须具有 cluster-admin 特权才能 同步组。
14.2. 配置 LDAP 同步
在运行 LDAP 同步 之前，您需要有一个同步配置文件。此文件包含 LDAP 客户端配置详情：
- 用于连接 LDAP 服务器的配置。
- 依赖于您的 LDAP 服务器中所用模式的同步配置选项。
同步配置文件也可以包含管理员定义的名称映射列表，用于将 OpenShift Container Platform 组名称映射到 LDAP 服务器中的组。
14.2.1. LDAP 客户端配置
LDAP 客户端配置
url: ldap://10.0.0.0:389 bindDN: cn=admin,dc=example,dc=com bindPassword: password insecure: false ca: my-ldap-ca-bundle.crt
url: ldap://10.0.0.0:389
bindDN: cn=admin,dc=example,dc=com
bindPassword: password
insecure: false
ca: my-ldap-ca-bundle.crt - 1
- 连接协议、托管数据库的 LDAP 服务器的 IP 地址以及要连接的端口，格式为
scheme://host:port。 - 2
- 可选的可分辨名称 (DN)，用作绑定 DN。如果需要升级特权才能检索同步操作的条目，OpenShift Container Platform 会使用此项。
- 3
- 用于绑定的可选密码。如果需要升级特权才能检索同步操作的条目，OpenShift Container Platform 会使用此项。此值也可在 环境变量、外部文件或加密文件 中提供。
- 4
- 为
false时，安全 LDAPldaps://URL 使用 TLS 进行连接，并且不安全 LDAPldap://URL 会被升级到 TLS。为true时，不会对服务器进行 TLS 连接，除非您指定了ldaps://URL，这时 URL 仍然尝试使用 TLS 进行连接。 - 5
- 用于验证所配置 URL 的服务器证书的证书捆绑包。如果为空，OpenShift Container Platform 将使用系统信任的根证书。只有
insecure设为false时才会应用此项。
14.2.2. LDAP 查询定义
同步配置由用于同步所需条目的 LDAP 查询定义组成。LDAP 查询的具体定义取决于用来在 LDAP 服务器中存储成员资格信息的模式。
LDAP 查询定义
| LDAP 搜索范围 | 描述 |
|---|---|
|
| 仅考虑通过为查询给定的基本 DN 指定的对象。 |
|
| 考虑作为查询的基本 DN 的树中同一级上的所有对象。 |
|
| 考虑根部是为查询给定的基本 DN 的整个子树。 |
| dereferencing Behavior | 描述 |
|---|---|
|
| 从不解引用 LDAP 树中找到的任何别名。 |
|
| 仅解引用搜索时找到的别名。 |
|
| 仅在查找基本对象时解引用别名。 |
|
| 始终解引用 LDAP 树中找到的所有别名。 |
14.2.3. 用户定义的名称映射
用户定义的名称映射明确将 OpenShift Container Platform 组的名称映射到可在 LDAP 服务器上找到组的唯一标识符。映射使用普通 YAML 语法。用户定义的映射可为 LDAP 服务器中每个组包含一个条目，或者仅包含这些组的一个子集。如果 LDAP 服务器上的组没有用户定义的名称映射，同步过程中的默认行为是使用指定为 OpenShift Container Platform 组名称的属性。
用户定义的名称映射
groupUIDNameMapping: "cn=group1,ou=groups,dc=example,dc=com": firstgroup "cn=group2,ou=groups,dc=example,dc=com": secondgroup "cn=group3,ou=groups,dc=example,dc=com": thirdgroup
groupUIDNameMapping:
"cn=group1,ou=groups,dc=example,dc=com": firstgroup
"cn=group2,ou=groups,dc=example,dc=com": secondgroup
"cn=group3,ou=groups,dc=example,dc=com": thirdgroup14.3. 运行 LDAP 同步
创建 同步配置文件 后，同步可以开始。OpenShift Container Platform 允许管理员与同一服务器进行多种不同类型的同步。
默认情况下，所有组同步或修剪操作都是空运行，因此您必须在 sync-groups 命令上设置 --confirm 标志，以便更改 OpenShift Container Platform 组记录。
将 LDAP 服务器上的所有组与 OpenShift Container Platform 同步：
oc adm groups sync --sync-config=config.yaml --confirm
$ oc adm groups sync --sync-config=config.yaml --confirm同步所有已在 OpenShift Container Platform 中并与配置文件中指定的 LDAP 服务器中的组对应的组：
oc adm groups sync --type=openshift --sync-config=config.yaml --confirm
$ oc adm groups sync --type=openshift --sync-config=config.yaml --confirm要将 LDAP 组的子集与 OpenShift Container Platform 同步，您可以使用白名单文件、黑名单文件或两者：
您可以使用黑名单文件、白名单文件或白名单字面量的任意组合。白名单和黑名单文件必须每行包含一个唯一组标识符，您可以在该命令本身中直接包含白名单字面量。这些准则适用于在 LDAP 服务器上找到的组，以及 OpenShift Container Platform 中已存在的组。
14.4. 运行组修剪任务
如果创建组的 LDAP 服务器上的记录已不存在，管理员也可以选择从 OpenShift Container Platform 记录中移除这些组。修剪任务将接受与用于同步任务相同的同步配置文件和白名单。Pruning groups 部分提供了更多信息。
14.5. 同步示例
本节包含 RFC 2307、Active Directory 和增强 Active Directory 模式的示例。以下示例中两个成员同步了名为 admins 的组：Jane 和 Jim.每个示例都解释了：
- 如何将组和用户添加到 LDAP 服务器中。
- LDAP 同步配置文件的概貌。
- 同步之后 OpenShift Container Platform 中会生成什么组记录。
这些示例假定所有用户都是其各自组的直接成员。具体而言，没有任何组的成员是其他组。如需有关如何 同步嵌套组 的信息，请参阅嵌套成员资格同步示例。
14.5.1. 使用 RFC 2307 模式同步组
在 RFC 2307 模式中，用户（Jane 和 Jim）和组都作为第一类条目存在于 LDAP 服务器上，组成员资格则存储在组的属性中。以下 ldif 片段定义了这个模式的用户和组：
使用 RFC 2307 模式的 LDAP 条目：rfc2307.ldif
要同步此组，您必须首先创建配置文件。RFC 2307 模式要求您提供用户和组条目的 LDAP 查询定义，以及在 OpenShift Container Platform 内部记录中代表它们的属性。
为明确起见，您在 OpenShift Container Platform 中创建的组应尽可能将可分辨名称以外的属性用于面向用户或管理员的字段。例如，通过电子邮件标识 OpenShift Container Platform 组的用户，并将该组的名称用作通用名称。以下配置文件创建了这些关系：
如果使用用户定义的名称映射，您的配置文件 会有所不同。
使用 RFC 2307 模式的 LDAP 同步配置：rfc2307_config.yaml
- 1
- 存储该组记录的 LDAP 服务器的 IP 地址和主机。
- 2
- 为
false时，安全 LDAPldaps://URL 使用 TLS 进行连接，并且不安全 LDAPldap://URL 会被升级到 TLS。为true时，不会对服务器进行 TLS 连接，除非您指定了ldaps://URL，这时 URL 仍然尝试使用 TLS 进行连接。 - 3
- 唯一标识 LDAP 服务器上组的属性。将 DN 用于 groupUIDAttribute 时，您无法指定
groupsQuery过滤器。要进行精细过滤，请使用 白名单/黑名单方法。 - 4
- 要用作组名称的属性。
- 5
- 存储成员资格信息的组属性。
- 6
- 唯一标识 LDAP 服务器上用户的属性。将 DN 用于 userUIDAttribute 时，您无法指定
usersQuery过滤器。要进行精细过滤，请使用 白名单/黑名单方法。 - 7
- OpenShift Container Platform 组记录中用作用户名称的属性。
使用 rfc2307_config.yaml 文件运行同步：
oc adm groups sync --sync-config=rfc2307_config.yaml --confirm
$ oc adm groups sync --sync-config=rfc2307_config.yaml --confirmOpenShift Container Platform 创建以下组记录作为上述同步操作的结果：
使用 rfc2307_config.yaml 文件创建的 OpenShift Container Platform 组
14.5.1.1. RFC2307，带有用户定义的名称映射
使用用户定义的名称映射同步组时，配置文件会更改为包含这些映射，如下所示。
使用 RFC 2307 模式及用户定义的名称映射的 LDAP 同步配置： rfc2307_config_user_defined.yaml
使用 rfc2307_config_user_defined.yaml 文件运行同步：
oc adm groups sync --sync-config=rfc2307_config_user_defined.yaml --confirm
$ oc adm groups sync --sync-config=rfc2307_config_user_defined.yaml --confirmOpenShift Container Platform 创建以下组记录作为上述同步操作的结果：
使用 rfc2307_config_user_defined.yaml 文件创建的 OpenShift Container Platform 组
- 1
- 由用户定义的名称映射指定的组名称。
14.5.2. 使用 RFC 2307 及用户定义的容错来同步组
默认情况下，如果要同步的组包含其条目在成员查询中定义范围之外的成员，组同步会失败并显示以下错误：
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with dn="<user-dn>" would search outside of the base dn specified (dn="<base-dn>")".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with dn="<user-dn>" would search outside of the base dn specified (dn="<base-dn>")".
这通常表示 usersQuery 字段中配置了 baseDN。不过，如果 baseDN 有意不含有组中的部分成员，那么设置 tolerateMemberOutOfScopeErrors: true 可以让组同步继续进行。范围之外的成员将被忽略。
同样，当组同步过程未能找到某个组的某一成员时，它会彻底失败并显示错误：
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" refers to a non-existent entry". Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" and filter "<filter>" did not return any results".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" refers to a non-existent entry".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" and filter "<filter>" did not return any results".
这通常表示错误配置的 usersQuery 字段。不过，如果组中包含已知缺失的成员条目，那么设置 tolerateMemberNotFoundErrors: true 可以让组同步继续进行。有问题的成员将被忽略。
为 LDAP 组同步启用容错会导致同步过程忽略有问题的成员条目。如果 LDAP 组同步配置不正确，这可能会导致同步的 OpenShift Container Platform 组中缺少成员。
使用 RFC 2307 模式并且组成员资格有问题的 LDAP 条目：rfc2307_problematic_users.ldif
要容许以上示例中的错误，您必须在同步配置文件中添加以下内容：
使用 RFC 2307 模式且容许错误的 LDAP 同步配置：rfc2307_config_tolerating.yaml
使用 rfc2307_config_tolerating.yaml 文件运行同步：
oc adm groups sync --sync-config=rfc2307_config_tolerating.yaml --confirm
$ oc adm groups sync --sync-config=rfc2307_config_tolerating.yaml --confirmOpenShift Container Platform 创建以下组记录作为上述同步操作的结果：
使用 rfc2307_config.yaml 文件创建的 OpenShift Container Platform 组
- 1
- 属于组的成员的用户，根据同步文件指定。缺少查询遇到容许错误的成员。
14.5.3. 使用 Active Directory 同步组
在 Active Directory 模式中，两个用户（Jane 和 Jim）都作为第一类条目存在于 LDAP 服务器中，组成员资格则存储在用户的属性中。以下 ldif 片段定义了这个模式的用户和组：
使用 Active Directory 模式的 LDAP 条目：active_directory.ldif
- 1
- 用户的组成员资格列为用户的属性，组没有作为条目存在于服务器中。
memberOf属性不一定是用户的字面量属性；在一些 LDAP 服务器中，它在搜索过程中创建并返回给客户端，但不提交给数据库。
要同步此组，您必须首先创建配置文件。Active Directory 模式要求您提供用户条目的 LDAP 查询定义，以及在内部 OpenShift Container Platform 组记录中代表它们的属性。
为明确起见，您在 OpenShift Container Platform 中创建的组应尽可能将可分辨名称以外的属性用于面向用户或管理员的字段。例如，通过电子邮件标识 OpenShift Container Platform 组的用户，但通过 LDAP 服务器上的组名称来定义组名称。以下配置文件创建了这些关系：
使用 Active Directory 模式的 LDAP 同步配置：active_directory_config.yaml
使用 active_directory_config.yaml 文件运行同步：
oc adm groups sync --sync-config=active_directory_config.yaml --confirm
$ oc adm groups sync --sync-config=active_directory_config.yaml --confirmOpenShift Container Platform 创建以下组记录作为上述同步操作的结果：
使用 active_directory_config.yaml 文件创建的 OpenShift Container Platform 组
14.5.4. 使用增强 Active Directory 同步组
在增强 Active Directory 模式中，用户（Jane 和 Jim）和组都作为第一类条目存在于 LDAP 服务器中，组成员资格则存储在用户的属性中。以下 ldif 片段定义了这个模式的用户和组：
使用增强 Active Directory 模式的 LDAP 条目：increaseded_active_directory.ldif
要同步此组，您必须首先创建配置文件。增强 Active Directory（augmented Active Directory） 模式要求您提供用户条目和组条目的 LDAP 查询定义，以及在内部 OpenShift Container Platform 组记录中代表它们的属性。
为明确起见，您在 OpenShift Container Platform 中创建的组应尽可能将可分辨名称以外的属性用于面向用户或管理员的字段。例如，通过电子邮件标识 OpenShift Container Platform 组的用户，并将该组的名称用作通用名称。以下配置文件创建了这些关系。
使用增强 Active Directory 模式的 LDAP 同步配置：increaseded_active_directory_config.yaml
使用 augmented_active_directory_config.yaml 文件运行同步：
oc adm groups sync --sync-config=augmented_active_directory_config.yaml --confirm
$ oc adm groups sync --sync-config=augmented_active_directory_config.yaml --confirmOpenShift Container Platform 创建以下组记录作为上述同步操作的结果：
使用 augmented_active_directory_config.yaml 文件创建的 OpenShift 组
14.6. 嵌套成员资格同步示例
OpenShift Container Platform 中的组不嵌套。在消耗数据之前，LDAP 服务器必须平展组成员资格。Microsoft 的 Active Directory Server 通过 LDAP_MATCHING_RULE_IN_CHAIN 规则支持这一功能，其 OID 为 1.2.840.113556.1.4.1941。另外，使用此匹配规则时只能同步明确列在白名单中 的组。
本节中的示例使用了增强 Active Directory 模式，它将同步一个名为 admins 的组，该组有一个用户 Jane 和一个组 otheradmins。otheradmins 组具有一个用户成员：Jim.这个示例阐述了：
- 如何将组和用户添加到 LDAP 服务器中。
- LDAP 同步配置文件的概貌。
- 同步之后 OpenShift Container Platform 中会生成什么组记录。
在增强 Active Directory 模式中，用户（Jane 和 Jim）和组都作为第一类条目存在于 LDAP 服务器中，组成员资格则存储在用户或组的属性中。以下 ldif 片段定义了这个模式的用户和组：
使用增强 Active Directory 模式和嵌套成员的 LDAP 条目：augmented_active_directory_nested.ldif
要将嵌套的组与 Active Directory 同步，您必须提供用户条目和组条目的 LDAP 查询定义，以及在内部 OpenShift Container Platform 组记录中代表它们的属性。另外，此配置也需要进行某些修改：
-
oc adm groups sync命令必须明确将组 列在白名单中。 -
用户的
groupMembershipAttributes必须包含"memberOf:1.2.840.113556.1.4.1941:"，以遵守LDAP_MATCHING_RULE_IN_CHAIN规则。 -
groupUIDAttribute必须设为dn。 groupsQuery：-
不得设置
filter。 -
必须设置有效的
derefAliases。 -
不应设置
basedn，因为此值将被忽略。 -
不应设置
scope，因为此值将被忽略。
-
不得设置
为明确起见，您在 OpenShift Container Platform 中创建的组应尽可能将可分辨名称以外的属性用于面向用户或管理员的字段。例如，通过电子邮件标识 OpenShift Container Platform 组的用户，并将该组的名称用作通用名称。以下配置文件创建了这些关系：
使用增强 Active Directory 模式和嵌套成员的 LDAP 同步配置：increaseded_active_directory_config_nested.yaml
使用 augmented_active_directory_config_nested.yaml 文件运行同步：
oc adm groups sync \
'cn=admins,ou=groups,dc=example,dc=com' \
--sync-config=augmented_active_directory_config_nested.yaml \
--confirm
$ oc adm groups sync \
'cn=admins,ou=groups,dc=example,dc=com' \
--sync-config=augmented_active_directory_config_nested.yaml \
--confirm
您必须明确将 cn=admins,ou=groups,dc=example,dc=com 组 列在白名单中。
OpenShift Container Platform 创建以下组记录作为上述同步操作的结果：
使用 augmented_active_directory_config_nested.yaml 文件创建的 OpenShift 组
14.7. LDAP 同步配置规格
配置文件的对象规格如下。请注意，不同的模式对象有不同的字段。例如，v1.ActiveDirectoryConfig 没有 groupsQuery 字段，而 v1.RFC2307Config 和 v1.AugmentedActiveDirectoryConfig 都有这个字段。
不支持二进制属性。所有来自 LDAP 服务器的属性数据都必须采用 UTF-8 编码字符串的格式。例如，切勿将 objectGUID 等二进制属性用作 ID 属性。您必须改为使用字符串属性，如 sAMAccountName 或 userPrincipalName。
14.7.1. v1.LDAPSyncConfig
LDAPSyncConfig 包含定义 LDAP 组同步所需的配置选项。
| 名称 | 描述 | 模式 |
|---|---|---|
|
| 代表此对象所代表的 REST 资源的字符串值。服务器可以从客户端向其提交请求的端点推断。无法更新。采用驼峰拼写法 (CamelCase)。更多信息：https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#types-kinds | 字符串 |
|
| 定义对象的此表示法的版本控制模式。服务器应该将识别的模式转换为最新的内部值，并可拒绝未识别的值。更多信息：https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#resources | 字符串 |
|
|
主机是要连接到的 LDAP 服务器的方案、主机和端口： | 字符串 |
|
| 要绑定到 LDAP 服务器的可选 DN。 | 字符串 |
|
| 在搜索阶段要绑定的可选密码。 | |
|
|
若为 | 布尔值 |
|
| 在向服务器发出请求时使用的可选的可信证书颁发机构捆绑包。若为空，则使用默认的系统根证书。 | 字符串 |
|
| LDAP 组 UID 与 OpenShift Container Platform 组名称的可选直接映射。 | 对象 |
|
| 包含用于从设置的 LDAP 服务器提取数据的配置，其格式类似于 RFC2307：第一类组和用户条目，以及由列出其成员的组条目的多值属性决定的组成员资格。 | |
|
| 包含用于从设置的 LDAP 服务器提取数据的配置，其格式与 Active Directory 中使用的类似：第一类用户条目，以及由列出所在组的成员的多值属性决定的组成员资格。 | |
|
| 包含用于从设置的 LDAP 服务器提取数据的配置，其格式与上面描述的 Active Directory 中使用的类似，再另加一项：有第一类组条目，它们用来保存元数据而非组成员资格。 |
14.7.2. v1.StringSource
StringSource 允许指定内联字符串，或通过环境变量或文件从外部指定。当它只包含一个字符串值时，它会编列为一个简单 JSON 字符串。
| 名称 | 描述 | 模式 |
|---|---|---|
|
|
指定明文值，或指定加密值（如果指定了 | 字符串 |
|
|
指定包含明文值或加密值（如果指定了 | 字符串 |
|
|
引用含有明文值或加密值（如果指定了 | 字符串 |
|
| 引用包含用于解密值的密钥的文件。 | 字符串 |
14.7.3. v1.LDAPQuery
LDAPQuery 包含构建 LDAP 查询时所需的选项。
| 名称 | 描述 | 模式 |
|---|---|---|
|
| 所有搜索都应从中开始的目录分支的 DN。 | 字符串 |
|
|
（可选）搜索的范围。可以是 | 字符串 |
|
|
（可选）搜索的行为与别名相关。可以是 | 字符串 |
|
|
包含所有对服务器的请求在放弃等待响应前应保持待定的时间限制，以秒为单位。如果是 | 整数 |
|
| 使用基本 DN 从 LDAP 服务器检索所有相关条目的有效 LDAP 搜索过滤器。 | 字符串 |
|
|
最大首选页面大小，以 LDAP 条目数衡量。页面大小为 | 整数 |
14.7.4. v1.RFC2307Config
RFC2307Config 包含必要的配置选项，用于定义 LDAP 组同步如何使用 RFC2307 模式与 LDAP 服务器交互。
| 名称 | 描述 | 模式 |
|---|---|---|
|
| 包含用于返回组条目的 LDAP 查询模板。 | |
|
|
定义 LDAP 组条目上的哪个属性将解释为其唯一标识符。( | 字符串 |
|
| 定义 LDAP 组条目上的哪些属性将解释为用于 OpenShift Container Platform 组的名称。 | 字符串数组 |
|
|
定义 LDAP 组条目上哪些属性将解释为其成员。这些属性中包含的值必须可由 | 字符串数组 |
|
| 包含用于返回用户条目的 LDAP 查询模板。 | |
|
|
定义 LDAP 用户条目上的哪个属性将解释为其唯一标识符。它必须与 | 字符串 |
|
|
定义要使用 LDAP 用户条目上的哪些属性，以用作其 OpenShift Container Platform 用户名。使用第一个带有非空值的属性。这应该与您的 | 字符串数组 |
|
|
决定在遇到缺失的用户条目时 LDAP 同步任务的行为。若为 | 布尔值 |
|
|
决定在遇到超出范围的用户条目时 LDAP 同步任务的行为。如果为 | 布尔值 |
14.7.5. v1.ActiveDirectoryConfig
ActiveDirectoryConfig 包含必要的配置选项，用于定义 LDAP 组同步如何使用 Active Directory 模式与 LDAP 服务器交互。
| 名称 | 描述 | 模式 |
|---|---|---|
|
| 包含用于返回用户条目的 LDAP 查询模板。 | |
|
|
定义 LDAP 用户条目上的哪些属性将解释为其 OpenShift Container Platform 用户名。用作 OpenShift Container Platform 组记录中用户名称的属性。大多数安装中首选 | 字符串数组 |
|
| 定义 LDAP 用户条目上的哪些属性将解释为它所属的组。 | 字符串数组 |
14.7.6. v1.AugmentedActiveDirectoryConfig
AugmentedActiveDirectoryConfig 包含必要的配置选项，用于定义 LDAP 组同步如何使用增强 Active Directory 模式与 LDAP 服务器交互。
| 名称 | 描述 | 模式 |
|---|---|---|
|
| 包含用于返回用户条目的 LDAP 查询模板。 | |
|
|
定义 LDAP 用户条目上的哪些属性将解释为其 OpenShift Container Platform 用户名。用作 OpenShift Container Platform 组记录中用户名称的属性。大多数安装中首选 | 字符串数组 |
|
| 定义 LDAP 用户条目上的哪些属性将解释为它所属的组。 | 字符串数组 |
|
| 包含用于返回组条目的 LDAP 查询模板。 | |
|
|
定义 LDAP 组条目上的哪个属性将解释为其唯一标识符。( | 字符串 |
|
| 定义 LDAP 组条目上的哪些属性将解释为用于 OpenShift Container Platform 组的名称。 | 字符串数组 |
第 15 章 配置 LDAP 故障切换
OpenShift Container Platform 提供了一个 身份验证供应商，用于轻量级目录访问协议(LDAP)设置，但它只能连接到单个 LDAP 服务器。在 OpenShift Container Platform 安装过程中，您可以为 LDAP 故障切换配置系统安全服务守护进程(SSSD)，以确保在一个 LDAP 服务器失败时访问集群。
此配置的设置是高级的，需要单独的身份验证服务器（也称为 远程基本身份验证服务器 ）用于 OpenShift Container Platform 进行通信。您可以将这个服务器配置为将额外属性（如电子邮件地址）传递给 OpenShift Container Platform，以便它可以在 web 控制台中显示它们。
本小节论述了如何在专用物理或虚拟机(VM)上完成此设置，但您也可以在容器中配置 SSSD。
您必须完成本主题的所有部分。
15.1. 配置基本身份验证的先决条件
在开始设置前，您需要了解以下有关 LDAP 服务器的以下信息：
- 目录服务器是否由 FreeIPA、Active Directory 或其他 LDAP 解决方案提供驱动。
- LDAP 服务器的统一资源标识符 (URI)，如 ldap.example.com。
- LDAP 服务器的 CA 证书的位置。
- LDAP 服务器是否为 RFC 2307 还是 RFC2307bis 供用户组使用。
准备服务器：
remote-basic.example.com ：用作远程基本身份验证服务器的虚拟机。
- 选择包括此服务器的 SSSD 版本 1.12.0 的操作系统，如 Red Hat Enterprise Linux 7.0 或更高版本。
openshift.example.com ：OpenShift Container Platform 的新安装。
- 没有为这个集群配置验证方法。
- 不要在这个集群上启动 OpenShift Container Platform。
15.2. 使用远程基本身份验证服务器生成和共享证书
在 Ansible 主机清单文件（默认为 /etc/ansible/hosts）中列出的第一个 master 主机上完成以下步骤。
为确保远程基本身份验证服务器和 OpenShift Container Platform 间的通信需要信任，在这组其他阶段创建一组传输层安全(TLS)证书。运行以下命令：
openshift start \ --public-master=https://openshift.example.com:8443 \ --write-config=/etc/origin/# openshift start \ --public-master=https://openshift.example.com:8443 \ --write-config=/etc/origin/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出中包含 /etc/origin/master/ca.crt 和 /etc/origin/master/ca.key 签名证书。
使用签名证书生成要在远程基本身份验证服务器中使用的密钥：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 以逗号分隔的所有主机名和接口 IP 地址列表，它们需要访问远程基本身份验证服务器。
注意您生成的证书文件有效期为两年。您可以通过更改
--expire-days和--signer-expiredays值来更改这个周期，但出于安全原因，不要使它们大于 730。重要如果您没有列出需要访问远程基本身份验证服务器的所有主机名和接口 IP 地址，HTTPS 连接将失败。
将必要的证书和密钥复制到远程基本身份验证服务器：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3. 为 LDAP 故障切换配置 SSSD
在远程基本身份验证服务器上完成这些步骤。
您可以将 SSSD 配置为检索属性，如电子邮件地址和显示名称，并将它们传递给 OpenShift Container Platform 以便在 web 界面中显示。在以下步骤中，您要将 SSSD 配置为向 OpenShift Container Platform 提供电子邮件地址：
安装所需的 SSSD 和 Web 服务器组件：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 设置 SSSD 以针对 LDAP 服务器验证此虚拟机。如果 LDAP 服务器是 FreeIPA 或 Active Directory 环境，则使用 realmd 将这个计算机加入到域中。
realm join ldap.example.com
# realm join ldap.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 有关更高级的情况，请参阅 系统级验证指南
- 要使用 SSSD 管理 LDAP 的故障切换情况，请在 ldap_uri 行上的 /etc/sssd/sssd.conf 文件中添加更多条目。使用 FreeIPA 注册的系统可以使用 DNS SRV 记录自动处理故障转移。
修改 /etc/sssd/sssd.conf 文件的 [domain/DOMAINNAME] 部分并添加此属性：
[domain/example.com] ... ldap_user_extra_attrs = mail
[domain/example.com] ... ldap_user_extra_attrs = mail1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定检索 LDAP 解决方案的电子邮件地址的正确属性。对于 IPA，请指定
邮件。其他 LDAP 解决方案可能使用其他属性，如电子邮件。
确认 /etc/sssd/sssd.conf 文件中的 domain 参数仅包含 [domain/DOMAINNAME] 部分中列出的域名。
domains = example.com
domains = example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 授予 Apache 权限以检索电子邮件属性。将以下行添加到 /etc/sssd/sssd.conf 文件的 [ifp] 部分：
[ifp] user_attributes = +mail allowed_uids = apache, root
[ifp] user_attributes = +mail allowed_uids = apache, rootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要确定正确应用所有更改，请重启 SSSD：
systemctl restart sssd.service
$ systemctl restart sssd.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 测试用户信息是否可以正确检索：
getent passwd <username>
$ getent passwd <username> username:*:12345:12345:Example User:/home/username:/usr/bin/bashCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确认您指定的 mail 属性返回您的域的电子邮件地址：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 尝试以 LDAP 用户身份登录虚拟机，并确认您可以使用 LDAP 凭证登录。您可以使用本地控制台或 SSH 等远程服务登录。
默认情况下，所有用户都可以使用其 LDAP 凭据登录远程基本身份验证服务器。您可以更改此行为：
- 如果您使用 IPA 加入的系统，请配置基于主机的访问控制。
- 如果您使用 Active Directory 加入系统，请使用组策略对象。
- 有关其他情况，请参阅 SSSD 配置文档。
15.4. 配置 Apache 使用 SSSD
创建一个包含以下内容的 /etc/pam.d/openshift 文件：
auth required pam_sss.so account required pam_sss.so
auth required pam_sss.so account required pam_sss.soCopy to Clipboard Copied! Toggle word wrap Toggle overflow 此配置可让 PAM（可插拔验证模块）使用 pam_ss.so 确定为 openshift 堆栈发出身份验证请求的身份验证和访问控制。
编辑 /etc/httpd/conf.modules.d/55-authnz_pam.conf 文件并取消注释以下行：
LoadModule authnz_pam_module modules/mod_authnz_pam.so
LoadModule authnz_pam_module modules/mod_authnz_pam.soCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要为远程基本身份验证配置 Apache httpd.conf 文件，请在 /etc/httpd/conf.d 目录中创建 openshift-remote-basic-auth.conf 文件。使用以下模板来提供所需设置和值：
重要仔细检查模板的内容，并根据您的环境自定义其相应的内容。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 /var/www/html 目录中创建 check_user.php 脚本。包含以下代码：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 启用 Apache 加载模块。修改 /etc/httpd/conf.modules.d/55-lookup_identity.conf 文件并取消注释以下行：
LoadModule lookup_identity_module modules/mod_lookup_identity.so
LoadModule lookup_identity_module modules/mod_lookup_identity.soCopy to Clipboard Copied! Toggle word wrap Toggle overflow 设置 SELinux 布尔值，以便 SElinux 允许 Apache 通过 D-BUS 连接到 SSSD：
setsebool -P httpd_dbus_sssd on
# setsebool -P httpd_dbus_sssd onCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将布尔值设置为 告知 SELinux 可以接受 Apache 联络 PAM 子系统：
setsebool -P allow_httpd_mod_auth_pam on
# setsebool -P allow_httpd_mod_auth_pam onCopy to Clipboard Copied! Toggle word wrap Toggle overflow 启动 Apache：
systemctl start httpd.service
# systemctl start httpd.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
修改集群的默认配置，以使用您创建的新身份提供程序。在 Ansible 主机清单文件中列出的第一个 master 主机上完成以下步骤。
- 打开 /etc/origin/master/master-config.yaml 文件。
找到 identityProviders 部分，并将其替换为以下代码：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用更新的配置重启 OpenShift Container Platform：
/usr/local/bin/master-restart api api /usr/local/bin/master-restart controllers controllers
# /usr/local/bin/master-restart api api # /usr/local/bin/master-restart controllers controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
ocCLI 测试登录：oc login https://openshift.example.com:8443
$ oc login https://openshift.example.com:8443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您只能使用有效的 LDAP 凭证登录。
列出身份，并确认为每个用户名显示一个电子邮件地址。运行以下命令：
oc get identity -o yaml
$ oc get identity -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 16 章 配置 SDN
16.1. 概述
OpenShift SDN 启用 OpenShift Container Platform 集群内 pod 之间的通信，并建立 pod 网络。目前提供了三个 SDN 插件 （ovs-subnet、ovs-multitenant 和 ovs-networkpolicy），提供不同的方法来配置 pod 网络。
16.2. 可用的 SDN 供应商
上游 Kubernetes 项目不附带默认的网络解决方案。相反，Kubernetes 已开发了一个 Container Network Interface(CNI)，以便网络供应商与自己的 SDN 解决方案集成。
有几个 OpenShift SDN 插件可用于红帽及第三方插件。
红帽已与多个 SDN 供应商合作，通过 Kubernetes CNI 接口在 OpenShift Container Platform 上认证其 SDN 网络解决方案，其中包括通过其产品授权流程对 SDN 插件的支持流程。如果您通过 OpenShift 创建支持问题单，红帽可促进交易流程，以便这两个公司都参与满足您的需求。
以下 SDN 解决方案由第三方供应商直接在 OpenShift Container Platform 上验证和支持：
- Cisco ACI (™)
- Juniper Contrail(™)
- Nokia Nuage(™)
- Tigera Calico(™)
- VMware NSX-T (™)
在 OpenShift Container Platform 上安装 VMware NSX-T(™)
VMware NSX-T(™)提供了一个 SDN 和安全基础架构来构建云原生应用程序环境。除了 vSphere 管理程序(ESX)外，这些环境还包括 KVM 和原生公共云。
当前集成需要同时具有 NSX-T 和 OpenShift Container Platform 的新安装。目前，支持 NSX-T 版本 2.4，当前只支持使用 ESXi 和 KVM 虚拟机监控程序。
如需更多信息，请参阅 OpenShift 的 NSX-T Container Plug-in。
16.3. 使用 Ansible 配置 Pod 网络
对于初始集群安装，则默认安装和配置 ovs-subnet 插件，尽管可以在安装期间使用 os_sdn_network_plugin_name 参数覆盖，可在 Ansible 清单文件中配置。
例如，要覆盖标准 ovs-subnet 插件，并使用 ovs-multitenant 插件：
Configure the multi-tenant SDN plugin (default is 'redhat/openshift-ovs-subnet')
# Configure the multi-tenant SDN plugin (default is 'redhat/openshift-ovs-subnet')
os_sdn_network_plugin_name='redhat/openshift-ovs-multitenant'如需了解可在清单文件中设置的与网络相关的 Ansible 变量的描述，请参阅配置集群变量。
16.4. 在 Master 中配置 Pod 网络
集群管理员可以通过修改 master 配置文件的 networkConfig 部分中的参数（默认位于 /etc/origin/ master /master-config.yaml ）来控制 master 主机上的 pod 网络设置：
为单个 CIDR 配置 pod 网络
另外，您可以通过将单独的范围添加到带有范围和 hostSubnetLength 的 clusterNetworks 字段中，创建具有多个 CIDR 范围的 pod 网络。
可将多个范围用于一次，而且该范围可以被扩展或合同。通过撤离节点，可以把节点从一个范围移到另一个范围，然后删除并重新创建节点。如需更多信息，请参阅 管理节点 部分。列出顺序出现节点分配，然后在范围已满后移至列表上的下一个操作。
为多个 CIDR 配置 pod 网络
您可以将元素添加到 clusterNetworks 值，如果没有节点正在使用这个 CIDR 范围，则删除它们。
在集群首次创建后无法更改 hostSubnetLength 值，cidr 项只能更改为一个更大的网络，它需要仍然包含原始网络（如果节点在它的范围内分配），且只能扩展 serviceNetworkCIDR。例如，对于 10.128.0.0/14 的典型值，您可以将 cidr 改为 10.128.0.0/9 （例如，net 10 的整个上半个）而不是 10.64.0.0/16，因为这不会重叠原始值。
您可以将 serviceNetworkCIDR 从 172.30.0.0/16 改为 172.30.0.0/15，但不改为 172.28.0.0/14，因为原始范围完全位于 CIDR 的开头。如需更多信息，请参阅扩展服务网络。
确保重启 API 和 master 服务以使任何更改生效：
master-restart api master-restart controllers
$ master-restart api
$ master-restart controllers
节点上的 pod 网络设置必须与 master 上的 networkConfig.clusterNetworks 参数配置的 pod 网络设置匹配。这可以通过修改相应节点 配置映射的 networkConfig 部分中的参数来实现 ：
proxyArguments: cluster-cidr: - 10.128.0.0/12
proxyArguments:
cluster-cidr:
- 10.128.0.0/12 - 1
- CIDR 值必须包含在 master 级别上定义的所有集群网络 CIDR 范围，但不与其他 IP 范围冲突，如用于节点和服务。
在重启 master 服务后，必须将配置传播到节点。在每个节点上，必须重启 atomic-openshift-node 服务和 ovs pod。为了避免停机遵循 管理节点 中定义的步骤，并一次为每个节点或一组节点执行以下步骤：
将节点标记为不可调度。
oc adm manage-node <node1> <node2> --schedulable=false
# oc adm manage-node <node1> <node2> --schedulable=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 排空节点：
oc adm drain <node1> <node2>
# oc adm drain <node1> <node2>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重启节点：
reboot
# rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将节点重新标记为可调度：
oc adm manage-node <node1> <node2> --schedulable
# oc adm manage-node <node1> <node2> --schedulableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.5. 更改集群网络的 VXLAN PORT
作为集群管理员，您可以更改系统使用的 VXLAN 端口。
由于您无法更改正在运行的 clusternetwork 对象的 VXLAN 端口，所以您必须通过编辑 master 配置文件中的 vxlanPort 变量来删除任何现有的网络配置。
删除现有的
clusternetwork：oc delete clusternetwork default
# oc delete clusternetwork defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑 master 配置文件（默认位于 /etc/origin/master/master-config.yaml）来创建新的
clusternetwork：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 设置为节点用于 VXLAN 端口的值。它可以是 1-65535 之间的一个整数。默认值为
4789。
在每个集群节点上的 iptables 规则添加新端口：
iptables -A OS_FIREWALL_ALLOW -p udp -m state --state NEW -m udp --dport 4889 -j ACCEPT
# iptables -A OS_FIREWALL_ALLOW -p udp -m state --state NEW -m udp --dport 4889 -j ACCEPT1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
4889是您在主配置文件中设置的vxlanPort值。
重启 master 服务：
master-restart api master-restart controllers
# master-restart api # master-restart controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除所有旧的 SDN pod，以使用新更改传播新 pod：
oc delete pod -l app=sdn -n openshift-sdn
# oc delete pod -l app=sdn -n openshift-sdnCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.6. 在节点上配置 Pod 网络
集群管理员可以通过修改相应节点配置映射的 networkConfig 部分中的参数来控制 节点上的 pod 网络设置 ：
networkConfig: mtu: 1450 networkPluginName: "redhat/openshift-ovs-subnet"
networkConfig:
mtu: 1450
networkPluginName: "redhat/openshift-ovs-subnet" 您必须在所有 master 和作为 OpenShift Container Platform SDN 一部分的节点上更改 MTU 大小。另外，tun0 接口的 MTU 大小必须在属于集群的所有节点中相同。
16.7. 扩展服务网络
如果您在服务网络中的有效地址的数量较少，只要您确定当前范围位于新范围的开头，就可以扩展该范围。
服务网络只能扩展，无法更改或合同。
-
对所有的 master，修改配置文件中的
serviceNetworkCIDR和servicesSubnet参数（默认为 /etc/origin/master/master-config.yaml）。仅将/后面的数字更改为较小的数字。 删除
clusterNetwork 默认对象：oc delete clusternetwork default
$ oc delete clusternetwork defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在所有 master 上重启控制器组件：
master-restart controllers
# master-restart controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 Ansible 清单文件中的
openshift_portal_net变量的值更新为新的 CIDR：Configure SDN cluster network and kubernetes service CIDR blocks. These network blocks should be private and should not conflict with network blocks in your infrastructure that pods may require access to. Can not be changed after deployment.
# Configure SDN cluster network and kubernetes service CIDR blocks. These # network blocks should be private and should not conflict with network blocks # in your infrastructure that pods may require access to. Can not be changed # after deployment. openshift_portal_net=172.30.0.0/<new_CIDR_range>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
对于集群中的每个节点，请完成以下步骤：
- 将节点标记为不可调度。
- 撤离节点 中的 pod。
- 重新引导节点。
- 节点再次可用后，将节点标记为可调度。
16.8. 在 SDN 插件之间迁移
如果您已经使用一个 SDN 插件，并希望切换到另外一个 SDN 插件：
-
在所有 master 和 节点上 更改
networkPluginName参数。 在所有 master 上重启 API 和 master 服务：
master-restart api master-restart controllers
# master-restart api # master-restart controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 停止所有 master 和节点上的节点服务：
systemctl stop atomic-openshift-node.service
# systemctl stop atomic-openshift-node.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您要在 OpenShift SDN 插件间进行切换，请在所有 master 和节点上重启 OpenShift SDN。
oc delete pod --all -n openshift-sdn
oc delete pod --all -n openshift-sdnCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在所有 master 和节点上重启节点服务：
systemctl restart atomic-openshift-node.service
# systemctl restart atomic-openshift-node.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您要从 OpenShift SDN 插件切换到第三方插件，请清理特定于 OpenShift SDN 的工件：
oc delete clusternetwork --all oc delete hostsubnets --all oc delete netnamespaces --all
$ oc delete clusternetwork --all $ oc delete hostsubnets --all $ oc delete netnamespaces --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow
另外，在切换到 ovs-multitenant 后，用户无法使用服务目录置备服务。对 openshift-monitoring 也是如此。要更正此问题，使这些项目成为全局项目：
oc adm pod-network make-projects-global kube-service-catalog $ oc adm pod-network make-projects-global openshift-monitoring
$ oc adm pod-network make-projects-global kube-service-catalog
$ oc adm pod-network make-projects-global openshift-monitoring如果集群最初使用 ovs-multitenant 安装，则不会出现此问题，因为这些命令是作为 Ansible playbook 的一部分执行的。
从 ovs-subnet 切换到 ovs-multitenant OpenShift SDN 插件时，集群中的所有现有项目都将被完全隔离（作为唯一的 VNID）。集群管理员可以选择使用管理员 CLI 修改项目网络。
运行以下命令来检查 VNIDs：
oc get netnamespace
$ oc get netnamespace16.8.1. 从 ovs-multitenant 迁移到 ovs-networkpolicy
v1 NetworkPolicy 功能仅适用于 OpenShift Container Platform。这意味着 OpenShift Container Platform 不提供出口策略类型、IPBlock 和组合 podSelector 和 namespaceSelector。
不要在默认的 OpenShift Container Platform 项目中应用 NetworkPolicy 功能，因为它们可能会破坏与集群的通信。
除了在 SDN 插件间迁移以上通用的插件迁移步骤外，从 ovs-multitenant 插件迁移到 ovs-networkpolicy 插件时，会有一个额外的步骤。您需要确定每个命名空间有一个唯一的 NetID这意味着，如果您之前已将项目接合在一起或将项目设置为全局项目，则需要在切换到 ovs-networkpolicy 插件前撤销该项目，否则 NetworkPolicy 对象无法正常工作。
提供了一个帮助脚本，可修复 NetID 的，创建 NetworkPolicy 对象来隔离之前隔离命名空间，并启用之前加入的命名空间之间的连接。
使用以下步骤将这个帮助程序脚本迁移到 ovs-networkpolicy 插件，同时仍然运行 ovs-multitenant 插件：
下载脚本并添加执行文件权限：
curl -O https://raw.githubusercontent.com/openshift/origin/release-3.11/contrib/migration/migrate-network-policy.sh chmod a+x migrate-network-policy.sh
$ curl -O https://raw.githubusercontent.com/openshift/origin/release-3.11/contrib/migration/migrate-network-policy.sh $ chmod a+x migrate-network-policy.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行脚本（需要集群管理员角色）。
./migrate-network-policy.sh
$ ./migrate-network-policy.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow
运行此脚本后，每个命名空间都完全与其它命名空间隔离，因此不同命名空间中的 pod 间的连接尝试会失败，直到完成到 ovs-networkpolicy 插件为止。
如果您希望新创建的命名空间同时具有相同的策略，您可以将默认 NetworkPolicy 对象设置为与 default-deny 匹配，以及由迁移脚本创建的 allow-from-global-namespaces 策略。
如果脚本失败或其他错误，或者稍后决定恢复到 ovs-multitenant 插件，您可以使用 un-migration 脚本。此脚本会撤消迁移脚本所做的更改，并重新加入之前加入的命名空间。
16.9. 外部访问集群网络
如果一个 OpenShift Container Platform 以外的主机需要访问集群网络，则有两个选项：
- 将主机配置为 OpenShift Container Platform 节点，但将其 不可调度，以便 master 不会在其上调度容器。
- 在主机和位于集群网络上的主机间创建一个隧道。
这两个选项都作为实际用例的一部分阐述，在文档中用于配置 从边缘负载均衡器到 OpenShift SDN 中的容器的路由。
16.10. 使用 Flannel
作为默认 SDN 的替代方案，OpenShift Container Platform 还提供用于安装基于 flannel的网络的 Ansible playbook。这在两个平台中也依赖于 SDN 的云供应商平台（如 Red Hat OpenStack Platform）中运行 OpenShift Container Platform 非常有用。
Flannel 使用单个 IP 网络命名空间用于向每个实例分配连续空间子集。因此，容器无法尝试联系同一网络空间中的任何 IP 地址。这种障碍的多租户是多租户，因为网络无法用于将一个应用中的容器与另一个应用隔离。
根据您首选的租户隔离还是性能，您应该在决定 OpenShift SDN（多租户）和用于内部网络的 flannel（多租户）之间决定适当的选择。
Flannel 仅支持 Red Hat OpenStack Platform 上的 OpenShift Container Platform。
当前版本的 Neutron 默认在端口上强制实施端口安全性。这可防止端口发送或接收使用与端口本身不同的 MAC 地址的数据包。Flannel 创建虚拟 MAC 和 IP 地址，且必须在端口上发送和接收数据包，因此在执行 flannel 流量的端口上必须禁用端口安全性。
在 OpenShift Container Platform 集群中启用 flannel：
Neutron 端口安全控制必须配置为与 Flannel 兼容。Red Hat OpenStack Platform 的默认配置会禁用用户对
port_security的控制。配置 Neutron，以允许用户控制各个端口上的port_security设置。在 Neutron 服务器上，将以下内容添加到 /etc/neutron/plugins/ml2/ml2_conf.ini 文件：
[ml2] ... extension_drivers = port_security
[ml2] ... extension_drivers = port_securityCopy to Clipboard Copied! Toggle word wrap Toggle overflow 然后重启 Neutron 服务：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在 Red Hat OpenStack Platform 上创建 OpenShift Container Platform 实例时，在容器网络 flannel 接口的端口中禁用端口安全性和安全组：
neutron port-update $port --no-security-groups --port-security-enabled=False
neutron port-update $port --no-security-groups --port-security-enabled=FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意Flannel 从 etcd 收集信息来配置和分配节点的子网。因此，附加到 etcd 主机的安全组应该允许从节点访问端口 2379/tcp，节点安全组应允许到 etcd 主机上该端口的出口通信。
在运行安装前，在 Ansible 清单文件中设置以下变量：
openshift_use_openshift_sdn=false openshift_use_flannel=true flannel_interface=eth0
openshift_use_openshift_sdn=false1 openshift_use_flannel=true2 flannel_interface=eth0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 另外，您还可以使用
flannel_interface变量来指定要用于主机间通信的接口。如果没有此变量，OpenShift Container Platform 安装将使用默认接口。注意以后的发行版本中将支持使用 flannel 的 pod 和服务的自定义网络 CIDR。BZ#1473858
在 OpenShift Container Platform 安装后，在每个 OpenShift Container Platform 节点上添加一组 iptables 规则：
iptables -A DOCKER -p all -j ACCEPT iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A DOCKER -p all -j ACCEPT iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADECopy to Clipboard Copied! Toggle word wrap Toggle overflow 要在 /etc/sysconfig/iptables 中保留这些更改，在每个节点上使用以下命令：
cp /etc/sysconfig/iptables{,.orig} sh -c "tac /etc/sysconfig/iptables.orig | sed -e '0,/:DOCKER -/ s/:DOCKER -/:DOCKER ACCEPT/' | awk '"\!"p && /POSTROUTING/{print \"-A POSTROUTING -o eth1 -j MASQUERADE\"; p=1} 1' | tac > /etc/sysconfig/iptables"cp /etc/sysconfig/iptables{,.orig} sh -c "tac /etc/sysconfig/iptables.orig | sed -e '0,/:DOCKER -/ s/:DOCKER -/:DOCKER ACCEPT/' | awk '"\!"p && /POSTROUTING/{print \"-A POSTROUTING -o eth1 -j MASQUERADE\"; p=1} 1' | tac > /etc/sysconfig/iptables"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意iptables-save命令保存在 内存 iptables 规则中的所有 当前。但是，由于 Docker，Kubernetes 和 OpenShift Container Platform 会创建大量 iptables 规则（服务等），因此无法保留这些规则，保存这些规则可能会变得存在问题。
要从 OpenShift Container Platform 流量隔离容器流量，红帽建议创建隔离的租户网络并将所有节点附加到其中。如果您使用不同的网络接口(eth1)，请记得通过 /etc/sysconfig/network-scripts/ifcfg-eth1 文件将接口配置为在引导时启动：
第 17 章 配置 Nuage SDN
17.1. Nuage SDN 和 OpenShift Container Platform
Nuage Networks Virtualized Services Platform (VSP) 为容器环境提供虚拟网络和软件定义网络 (SDN) 基础架构，从而简化 IT 操作并扩展 OpenShift Container Platform 的原生网络功能。
Nuage Networks VSP 支持在 OpenShift Container Platform 上运行的基于 Docker 的应用程序，以加快 pod 和传统工作负载之间的虚拟网络配置，并跨整个云基础架构启用安全策略。VSP 允许自动化安全设备，为容器应用包含精细安全性和微分段策略。
将 VSP 与 OpenShift Container Platform 应用程序工作流集成，可通过删除 DevOps 团队所面临的网络布局快速打开和更新应用程序。VSP 通过 OpenShift Container Platform 支持不同的工作流，以适应用户在使用基于策略的自动化时或完全控制的场景。
如需有关 VSP 与 OpenShift Container Platform 集成的更多信息，请参阅 网络。
17.2. 开发人员工作流
此工作流用于开发环境，需要开发人员进行很少的输入来设置网络。在此工作流中，nuage-openshift-monitor 负责创建为 OpenShift Container Platform 项目中创建的 pod 提供适当策略和网络所需的 VSP 结构（Zone、子网等）。创建项目时，由 nuage-openshift-monitor 创建该项目的默认区域和默认子网。当为给定项目创建的默认子网被省略时，nu age-openshift-monitor 会动态创建额外的子网。
为每个 OpenShift Container Platform 项目创建一个单独的 VSP Zone，可确保在项目之间隔离。
17.3. 操作工作流
运维团队会使用此工作流来推出应用程序。在此工作流中，首先在 VSD 上配置网络和安全策略，以根据组织设置的规则来部署应用。管理用户可能会创建多个区域和子网，并使用标签将它们映射到同一项目。在启动 pod 时，用户可以使用 Nuage Labels 指定 pod 需要附加到的网络，以及需要将其应用哪些网络策略。这允许以精细的方式控制项目内和内部流量的部署。例如，项目基础上启用了项目间的通信。这可用于将项目连接到部署在共享项目中的常用服务。
17.4. 安装
VSP 与 OpenShift Container Platform 集成可用于虚拟机(VM)和裸机 OpenShift Container Platform 安装。
具有高可用性(HA)的环境可以配置多个 master 和多个节点。
在多 master 模式中的 Nuage VSP 集成只支持本节中介绍的原生 HA 配置方法。这可以和任何负载平衡解决方案结合使用，这是 HAProxy 的默认设置。清单文件包含三个 master 主机、节点、etcd 服务器和一个 HAProxy，以在所有 master 主机上平衡主 API。HAProxy 主机在清单文件的 [lb] 部分中定义，使 Ansible 能够自动安装和配置 HAProxy 作为负载平衡解决方案。
在 Ansible 节点文件中，需要指定以下参数，才能将 Nuage VSP 设置为网络插件：
第 18 章 配置 NSX-T SDN
18.1. NSX-T SDN 和 OpenShift Container Platform
VMware NSX-T Data Center ™ 为简化 IT 操作并扩展了原生 OpenShift Container Platform 网络功能提供高级软件定义网络(SDN)、安全性和可见性。
NSX-T Data Center 支持跨多个集群的虚拟机、裸机和容器工作负载。这使得组织可以在整个环境中使用单个 SDN 来完成可见性。
有关如何与 OpenShift Container Platform 集成 NSX-T 的更多信息，请参阅 Available SDN 插件中的 NSX-T SDN。
18.2. Topology 示例
一个典型的用例是有一个 Tier-0 (T0) 路由器将物理系统与虚拟环境连接，以及一个 Tier-1 (T1) 路由器充当 OpenShift Container Platform 虚拟机的默认网关。
每个虚拟机有两个 vNIC：一个 vNIC 连接至管理逻辑交换机，以访问虚拟机。其他 vNIC 连接到 Dump Logical Switch，并由 nsx-node-agent 用来连接 Pod 网络。详情请参阅 OpenShift 的 NSX Container Plug-in。
用于在 OpenShift Container Platform 安装过程中自动创建用于配置 OpenShift Container Platform 路由和所有项目 T1 路由器和逻辑交换机的 LoadBalancer。
在此拓扑中，默认的 OpenShift Container Platform HAProxy 路由器用于所有基础架构组件，如 Grafana、Prometheus、控制台、服务目录等。确保基础架构组件的 DNS 记录指向基础架构节点 IP 地址，因为 HAProxy 使用主机网络命名空间。这适用于基础架构路由，但为了避免将基础架构节点管理 IP 公开给外部世界，请将特定于应用程序的路由部署到 NSX-T LoadBalancer 中。
此示例拓扑假设您使用三个 OpenShift Container Platform master 虚拟机，以及四个 OpenShift Container Platform worker 虚拟机（用于基础架构，两个用于 compute）。
18.3. 安装 VMware NSX-T
先决条件
ESXi 主机要求：
托管 OpenShift Container Platform 节点虚拟机的 ESXi 服务器必须是 NSX-T 传输节点。
图 18.1. NSX UI 为典型的高可用性环境分离传输节点：
DNS 要求：
-
您必须在 DNS 服务器中向基础架构节点使用通配符添加新条目。这允许 NSX-T 或其他第三方 LoadBalancer 进行负载均衡。在下面的
hosts文件中，条目由openshift_master_default_subdomain变量定义。 -
您必须使用
openshift_master_cluster_hostname和openshift_master_cluster_public_hostname变量更新您的 DNS 服务器。
-
您必须在 DNS 服务器中向基础架构节点使用通配符添加新条目。这允许 NSX-T 或其他第三方 LoadBalancer 进行负载均衡。在下面的
虚拟机要求：
- OpenShift Container Platform 节点虚拟机必须有两个 vNIC：
- 管理 vNIC 必须连接到连接到管理 T1 路由器的逻辑交换机。
所有虚拟机上的第二个 vNIC 必须标记 NSX-T，以便 NSX Container Plug-in(NCP)知道哪个端口需要用作特定 OpenShift Container Platform 节点上运行的所有 Pod 的父 VIF。标签必须如下：
{'ncp/node_name': 'node_name'} {'ncp/cluster': 'cluster_name'}{'ncp/node_name': 'node_name'} {'ncp/cluster': 'cluster_name'}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 下图显示了所有节点的 NSX UI 中的标签。对于大规模集群，您可以使用 API 调用或使用 Ansible 自动标记。
图 18.2. NSX UI 显示节点标签
NSX UI 中的标签顺序与 API 相反。节点名称必须与 kubelet 预期相同，集群名称必须与 Ansible 主机文件中的
nsx_openshift_cluster_name相同，如下所示。确保每个节点上的第二个 vNIC 中应用正确的标签。
NSX-T 要求：
在 NSX 中需要满足以下先决条件：
- Tier-0 路由器.
- Overlay Transport Zone.
- POD 网络的 IP 块。
- （可选）用于路由(NoNAT) POD 网络的 IP 块。
- SNAT 的 IP 池。默认情况下，每个项目从 Pod 网络 IP Block 指定的子网只能在 NSX-T 中路由。NCP 使用这个 IP 池提供与外部的连接。
- （可选）dFW（分发防火墙）中的 top 和 Bottom 防火墙部分。NCP 在这两个部分之间放置 Kubernetes 网络策略规则。
-
Open vSwitch 和 CNI 插件 RPM 需要托管在 HTTP 服务器中，可从 OpenShift Container Platform 节点虚拟机访问（在这个示例中为
http://websrv.example.com）。这些文件包含在 NCP Tar 文件中，您可以在 Download NSX Container Plug-in 2.4.0 从 VMware 下载。
OpenShift Container Platform 要求：
运行以下命令，为 OpenShift Container Platform 安装所需的软件包（若有）：
ansible-playbook -i hosts openshift-ansible/playbooks/prerequisites.yml
$ ansible-playbook -i hosts openshift-ansible/playbooks/prerequisites.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 确保所有节点上本地下载 NCP 容器镜像
在
prerequisites.ymlplaybook 成功执行后，在所有节点上运行以下命令，将xxx替换为 NCP 构建版本：docker load -i nsx-ncp-rhel-xxx.tar
$ docker load -i nsx-ncp-rhel-xxx.tarCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
docker load -i nsx-ncp-rhel-2.4.0.12511604.tar
$ docker load -i nsx-ncp-rhel-2.4.0.12511604.tarCopy to Clipboard Copied! Toggle word wrap Toggle overflow 获取镜像名称并重新标记它：
docker images docker image tag registry.local/xxxxx/nsx-ncp-rhel nsx-ncp
$ docker images $ docker image tag registry.local/xxxxx/nsx-ncp-rhel nsx-ncp1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
xxx替换为 NCP 构建版本。例如：
docker image tag registry.local/2.4.0.12511604/nsx-ncp-rhel nsx-ncp
docker image tag registry.local/2.4.0.12511604/nsx-ncp-rhel nsx-ncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 OpenShift Container Platform Ansible 主机文件中，指定以下参数，将 NSX-T 设置为网络插件：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如需有关 OpenShift Container Platform 安装参数的信息，请参阅 配置清单文件。
流程
满足所有先决条件后，您可以部署 NSX Data Center 和 OpenShift Container Platform。
部署 OpenShift Container Platform 集群：
ansible-playbook -i hosts openshift-ansible/playbooks/deploy_cluster.yml
$ ansible-playbook -i hosts openshift-ansible/playbooks/deploy_cluster.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如需有关 OpenShift Container Platform 安装的更多信息，请参阅安装 OpenShift Container Platform。
安装完成后，验证 NCP 和 nsx-node-agent Pod 是否正在运行：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.4. 在 OpenShift Container Platform 部署后检查 NSX-T
安装 OpenShift Container Platform 并验证 NCP 和 nsx-node-agent-* Pod:
检查路由。确保安装期间创建了 Tier-1 路由器，并链接到 Tier-0 路由器：
图 18.3. NSX UI dislaying 显示 T1 路由器
观察网络 traceflow 和 visibility。例如，检查 'console' 和 'grafana' 之间的连接。
如需有关保护 Pod、项目、虚拟机和外部服务间的通信的更多信息，请参见以下示例：
图 18.4. NSX UI dislaying 显示网络 traceflow
检查负载平衡。NSX-T 数据中心提供 Load Balancer 和 Ingress Controller 功能，如下例所示：
图 18.5. NSX UI 显示展示负载均衡器
有关其他配置和选项，请参阅 VMware NSX-T v2.4 OpenShift Plug-In 文档。
第 19 章 配置 Kuryr SDN
19.1. Kuryr SDN 和 OpenShift Container Platform
Kuryr （或更具体为 Kuryr-Kubernetes）是一个使用 CNI 和 OpenStack Neutron 构建的 SDN 解决方案。其优点包括能够使用广泛的 Neutron SDN 后端，并在 Kubernetes pod 和 OpenStack 虚拟机(VM)之间提供连接。
Kuryr-Kubernetes 和 OpenShift Container Platform 集成主要针对在 OpenStack 虚拟机上运行的 OpenShift Container Platform 集群设计。Kuryr-Kubernetes 组件作为 pod 在 kuryr 命名空间中的 OpenShift Container Platform 上安装：
-
kuryr-controller - 在一个
infra节点上安装的单个服务实例。在 OpenShift Container Platform 中建模为一个部署。 -
kuryr-cni - 在每个 OpenShift Container Platform 节点上安装和配置 Kuryr 作为 CNI 驱动程序。在 OpenShift Container Platform 中建模为一个
DaemonSet。
Kuryr 控制器监控 OpenShift API 服务器中的 pod、服务和命名空间创建、更新和删除事件。它将 OpenShift Container Platform API 调用映射到 Neutron 和 Octavia 中的对应对象。这意味着，实现了 Neutron 中继端口功能的每个网络解决方案都可以通过 Kuryr 支持 OpenShift Container Platform。这包括开源解决方案，如 OVS 和 OVN，以及 Neutron 兼容的商业 SDN。
19.2. 安装 Kuryr SDN
对于 OpenStack 云上的 Kuryr SDN 安装，您必须遵循 OpenStack 配置文档 中所述的步骤。
19.3. 验证
安装 OpenShift Container Platform 后，您可以检查 Kuryr pod 是否已成功部署：
Kuryr-cni pod 在每个 OpenShift Container Platform 节点上运行。单一 kuryr-controller 实例可以在任何 infra 节点上运行。
启用 Kuryr SDN 时不支持网络策略和节点端口服务。
第 20 章 为 Amazon Web Services(AWS)配置
20.1. 概述
OpenShift Container Platform 可以配置为访问 AWS EC2 基础架构，包括使用 AWS 卷作为应用程序数据的持久性存储。配置 AWS 后，必须在 OpenShift Container Platform 主机上完成一些额外的配置。
20.1.1. 为 Amazon Web Services(AWS)配置授权
权限 AWS 实例需要使用在创建时分配给实例的 access 和 secret 密钥或 IAM 角色来请求和管理 OpenShift Container Platform 中的负载均衡器和存储的 IAM 角色。
IAM 帐户或 IAM 角色必须具有以下策略权限才能拥有完整的云供应商功能。
aws iam put-role-policy \ --role-name openshift-role \ --policy-name openshift-admin \ --policy-document file: //openshift_iam_policy
aws iam put-role-policy \
--role-name openshift-role \
--policy-name openshift-admin \
--policy-document file: //openshift_iam_policyaws iam put-user-policy \ --user-name openshift-admin \ --policy-name openshift-admin \ --policy-document file: //openshift_iam_policy
aws iam put-user-policy \
--user-name openshift-admin \
--policy-name openshift-admin \
--policy-document file: //openshift_iam_policy
OpenShift 节点实例只需要 ec2:DescribeInstance 权限，但安装程序仅允许定义单个 AWS 访问密钥和 secret。这可绕过使用 IAM 角色，并将上面的权限分配给 master 实例，并将 ec2:DescribeInstance 分配给节点。
20.1.1.1. 在安装时配置 OpenShift Container Platform 云供应商
流程
要使用具有 access 和 secret 键的 IAM 帐户配置 Amazon Web Services 云供应商，请将以下值添加到清单中：
[OSEv3:vars] openshift_cloudprovider_kind=aws openshift_clusterid=openshift openshift_cloudprovider_aws_access_key=AKIAJ6VLBLISADPBUA openshift_cloudprovider_aws_secret_key=g/8PmDNYHVSQn0BQE+xtsHzbaZaGYjGNzhbdgwjH
[OSEv3:vars]
openshift_cloudprovider_kind=aws
openshift_clusterid=openshift
openshift_cloudprovider_aws_access_key=AKIAJ6VLBLISADPBUA
openshift_cloudprovider_aws_secret_key=g/8PmDNYHVSQn0BQE+xtsHzbaZaGYjGNzhbdgwjH 要使用 IAM 角色配置 Amazon Web Services 云供应商，请在清单中添加以下值：
NOTE: The IAM role takes the place of needing an access and secret key.
NOTE: The IAM role takes the place of needing an access and secret key.20.1.1.2. 安装后配置 OpenShift Container Platform 云供应商
如果安装时没有提供 Amazon Web Services 云供应商值，则可以在安装后定义和创建配置。按照以下步骤配置配置文件，并为 AWS 手动配置 master 和节点。
-
每个 master 主机、节点主机和子网必须具有
kubernetes.io/cluster/<clusterid>,Value=(owned|shared)标签。 一个安全组（最好链接到节点）必须具有
kubernetes.io/cluster/<clusterid>,Value=(owned|shared)标签。-
不要使用
kubernetes.io/cluster/<clusterid>,Value=(owned|shared)标签标记所有安全组，否则 Elastic Load Balancing(ELB)将无法创建负载均衡器。
-
不要使用
20.2. 配置安全组
在 AWS 上安装 OpenShift Container Platform 时，请确保设置适当的安全组。
这些是在安全组中必须具有的一些端口，而安装会失败。根据您要安装的集群配置，您可能需要更多。如需更多信息，并相应地调整您的安全组，请参阅所需端口以了解更多信息。
| 所有 OpenShift Container Platform 主机 |
|
| etcd 安全组 |
|
| Master 安全组 |
|
| 节点安全组 |
|
| 基础架构节点（一个可以托管 OpenShift Container Platform 路由器） |
|
| CRI-O |
如果使用 CRIO，则必须打开 tcp/10010 以允许 |
如果为 master 和/或路由器配置外部负载均衡器(ELB)，您还需要为 ELB 相应地配置入口和 Egress 安全组。
20.2.1. 覆盖检测到的 IP 地址和主机名
在 AWS 中，需要覆盖变量的情况包括：
| 变量 | 使用方法 |
|---|---|
|
|
用户安装在 VPC 中，它没有为 |
|
| 您已经配置了多个网络接口，并希望使用除默认接口以外的其他网络接口。 |
|
|
|
|
|
|
对于 EC2 主机，必须部署到启用了 DNS 主机名和 解析的 VPC 中。
DNS
Amazon Web Services (AWS) 提供对象存储，OpenShift Container Platform 可以使用它们使用 OpenShift Container Platform 容器 registry 存储容器镜像。
如需更多信息，请参阅 Amazon S3。
先决条件
OpenShift Container Platform 使用 S3 作为镜像存储。应创建 S3 存储桶、IAM 策略和带有 Programmatic Access 的 IAM 用户，以允许安装程序配置 registry。
以下示例使用 awscli 在 us-east-1 区域中创建一个名为 openshift-registry-storage 的存储桶。
# aws s3api create-bucket \
--bucket openshift-registry-storage \
--region us-east-1
# aws s3api create-bucket \
--bucket openshift-registry-storage \
--region us-east-1默认策略
20.2.1.1.1. 将 OpenShift Container Platform 清单配置为使用 S3
流程
将 registry 的 Ansible 清单配置为使用 S3 存储桶和 IAM 用户：
要使用 Amazon Web Services(AWS)S3 对象存储，请编辑 registry 的配置文件并挂载到 registry pod。
流程
导出当前的 config.yml ：
oc get secret registry-config \ -o jsonpath='{.data.config\.yml}' -n default | base64 -d \ >> config.yml.old$ oc get secret registry-config \ -o jsonpath='{.data.config\.yml}' -n default | base64 -d \ >> config.yml.oldCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从旧 config.yml 创建新配置文件：
cp config.yml.old config.yml
$ cp config.yml.old config.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑该文件，使其包含 S3 参数。在 registry 配置文件的
storage部分指定 accountname、accountkey、container 和 realm。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除
registry-configsecret：oc delete secret registry-config -n default
$ oc delete secret registry-config -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重新创建 secret 来引用更新的配置文件：
oc create secret generic registry-config \ --from-file=config.yml -n default$ oc create secret generic registry-config \ --from-file=config.yml -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重新部署 registry 以读取更新的配置：
oc rollout latest docker-registry -n default
$ oc rollout latest docker-registry -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow
20.2.1.1.3. 验证 registry 是否使用 S3 存储
验证 registry 是否使用 Amazon S3 存储：
流程
在成功部署 registry 后，registry
deploymentconfig会将 registry-storage 描述为emptydir而不是 AWS S3，但 AWS S3 存储桶的配置位于 secretdocker-config中。docker-config机密挂载到REGISTRY_CONFIGURATION_PATH，后者在将 AWS S3 用于注册表对象存储时提供所有 paramaters。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 共享 pod 生命周期的临时目录。
确定 /registry 挂载点为空：
oc exec \ $(oc get pod -l deploymentconfig=docker-registry \ -o=jsonpath='{.items[0].metadata.name}') -i -t -- ls -l /registry$ oc exec \ $(oc get pod -l deploymentconfig=docker-registry \ -o=jsonpath='{.items[0].metadata.name}') -i -t -- ls -l /registry total 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果为空，则代表 S3 配置在
registry-configsecret 中定义：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 安装程序会使用扩展的 registry 功能创建带有所需配置的 config.yml 文件，如安装文档所述。要查看配置文件，包括存储存储桶配置的
storage部分：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 另外，您可以查看 secret：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
如果使用 emptyDir 卷，/registry 挂载点类似如下：
20.3. 配置 AWS 变量
要设置所需的 AWS 变量，请在所有 OpenShift Container Platform 主机上（master 和 节点）创建一个 /etc/origin/cloudprovider/aws.conf 文件：
[Global] Zone = us-east-1c
[Global]
Zone = us-east-1c - 1
- 这是 AWS 实例的 Availability Zone，且您的 EBS 卷所在的位置 ; 这些信息可从 AWS 管理控制台获取。
20.4. 为 AWS 配置 OpenShift Container Platform
您可以通过两种方式在 OpenShift Container Platform 上设置 AWS 配置：
- 使用 Ansible 或
- 手动。
20.4.1. 使用 Ansible 为 AWS 配置 OpenShift Container Platform
在集群安装过程中，可以使用 openshift_cloudprovider_aws_access_key, openshift_cloudprovider_aws_secret_key, openshift_cloudprovider_kind, openshift_clusterid 参数配置 AWS，这些参数可以在 inventory 文件 中进行配置。
使用 Ansible 的 AWS 配置示例
当 Ansible 配置 AWS 时，它会自动对以下文件进行必要的更改：
- /etc/origin/cloudprovider/aws.conf
- /etc/origin/master/master-config.yaml
- /etc/origin/node/node-config.yaml
20.4.2. 为 AWS 手动配置 OpenShift Container Platform Master
在所有 master 上编辑 或创建 master 配置文件（默认为/etc/origin/master/master-config.yaml ）并更新 apiServerArguments 和 controllerArguments 部分的内容：
目前，nodeName 必须与 AWS 中的实例名称匹配，以便云供应商集成正常工作。名称也必须与 RFC1123 兼容。
在触发容器化安装时，只有 /etc/origin 和 /var/lib/origin 的目录被挂载到 master 和节点容器。因此，aws.conf 应该位于 /etc/origin/ 而不是 /etc/ 中。
20.4.3. 为 AWS 手动配置 OpenShift Container Platform 节点
编辑 适当的节点配置映射 并更新 kubeletArguments 部分的内容：
kubeletArguments:
cloud-provider:
- "aws"
cloud-config:
- "/etc/origin/cloudprovider/aws.conf"
kubeletArguments:
cloud-provider:
- "aws"
cloud-config:
- "/etc/origin/cloudprovider/aws.conf"在触发容器化安装时，只有 /etc/origin 和 /var/lib/origin 的目录被挂载到 master 和节点容器。因此，aws.conf 应该位于 /etc/origin/ 而不是 /etc/ 中。
20.4.4. 手动设置键-值访问对
确保在 master 上的 /etc/origin/master/master.env 文件中设置以下环境变量，以及节点上的 /etc/sysconfig/atomic-openshift-node 文件中：
AWS_ACCESS_KEY_ID=<key_ID> AWS_SECRET_ACCESS_KEY=<secret_key>
AWS_ACCESS_KEY_ID=<key_ID>
AWS_SECRET_ACCESS_KEY=<secret_key>在设置 AWS IAM 用户时获取访问密钥。
20.5. 应用配置更改
在所有 master 和节点主机上启动或重启 OpenShift Container Platform 服务以应用您的配置更改，请参阅重启 OpenShift Container Platform 服务 ：
master-restart api master-restart controllers systemctl restart atomic-openshift-node
# master-restart api
# master-restart controllers
# systemctl restart atomic-openshift-nodeKubernetes 架构需要来自云提供商的可靠端点。当云提供商停机时，kubelet 会防止 OpenShift Container Platform 重启。如果底层云供应商端点不可靠，请不要安装使用云供应商集成的集群。如在裸机环境中一样安装集群。不建议在已安装的集群中打开或关闭云提供商集成。但是，如果该情境不可避免，请完成以下过程。
从不使用云供应商切换到使用云提供商会产生错误消息。添加云供应商会尝试删除节点，因为从其切换的节点使用 hostname 作为 externalID （当没有云供应商使用时）使用云供应商的 instance-id （由云提供商指定）。要解决这个问题：
- 以集群管理员身份登录到 CLI。
检查和备份现有节点标签：
oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除节点：
oc delete node <node_name>
$ oc delete node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在每个节点主机上，重启 OpenShift Container Platform 服务。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 在每个主机上重新添加回您以前具有的标记。
20.6. 为 AWS 标记集群
如果配置 AWS 供应商凭证，还必须确保所有主机都被标记为。
要正确识别与集群关联的资源，请使用键 kubernetes.io/cluster/<clusterid> 标签资源，其中：
-
<clusterid> 是集群的唯一名称。
如果节点专门用于集群，将相关值设为 owned；如果资源与其他系统共享，将相关值设置为 shared。
使用 kubernetes.io/cluster/<clusterid>,Value=(owned|shared) 标签标记所有资源，可以避免多个区或多个集群中的潜在问题。
请参阅 Pod 和服务，了解更多有关在 OpenShift Container Platform 中标记和标记的信息。
20.6.1. 需要标签的资源
需要标记四种资源：
- 实例
- 安全组
- Load Balancers
- EBS 卷
20.6.2. 标记现有集群
集群使用 kubernetes.io/cluster/<clusterid>,Value=(owned|shared) 标签的值来决定 AWS 集群的资源。这意味着所有相关资源必须使用与键相同的值的 kubernetes.io/cluster/<clusterid>,Value=(owned|shared) 标签进行标记。这些资源包括：
- 所有主机。
- 要在 AWS 实例中使用的所有相关负载均衡器。
所有 EBS 卷。需要标记的 EBS 卷可使用以下地址找到：
oc get pv -o json|jq '.items[].spec.awsElasticBlockStore.volumeID'
$ oc get pv -o json|jq '.items[].spec.awsElasticBlockStore.volumeID'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 与 AWS 实例一起使用的所有相关安全组。
注意不要使用
kubernetes.io/cluster/<name>,Value=<clusterid>标签标记所有现有的安全组，否则 Elastic Load Balancing（ELB）将无法创建负载均衡器。
在标记任何资源后，重启 master 上的 master 服务，并在所有节点上重启节点服务。请参阅 应用配置部分。
20.6.3. 关于 Red Hat OpenShift Container Storage
Red Hat OpenShift Container Storage(RHOCS)是 OpenShift Container Platform 内部或混合云中与无关的持久性存储供应商。作为红帽存储解决方案，RHOCS 与 OpenShift Container Platform 完全集成，用于部署、管理和监控，无论它是否安装在 OpenShift Container Platform（融合）或与 OpenShift Container Platform（独立）。OpenShift Container Storage 不仅限于单个可用区或节点，这使得它可能会停机。您可以在 RHOCS 3.11 部署指南中找到使用 RHOCS 的完整说明。
第 21 章 为 Red Hat Virtualization 配置
您可以通过创建一个堡垒虚拟机并使用它来安装 OpenShift Container Platform，为 Red Hat Virtualization 配置 OpenShift Container Platform。
21.1. 创建堡垒（bastion）虚拟机
在 Red Hat Virtualization 中创建堡垒主机来安装 OpenShift Container Platform。
流程
- 使用 SSH 登录到 Manager 机器。
- 为安装文件创建一个临时 bastion 安装目录，如 /bastion_installation。
使用
ansible-vault创建加密的 /bastion_installation/secure_vars.yaml 文件并记录密码：ansible-vault create secure_vars.yaml
# ansible-vault create secure_vars.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 secure_vars.yaml 文件中添加以下参数值：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 登录管理门户的密码。
- 2
- 堡垒虚拟机的 root 密码。
- 3
- Red Hat Subscription Manager 凭证。
- 4
- Red Hat Virtualization Manager 订阅池的池 ID。
- 5
- OpenShift Container Platform root 密码。
- 6
- Red Hat Virtualization Manager CA 证书。如果您不从 Manager 机器运行 playbook，则需要
engine_cafile值。Manager CA 证书的默认位置为 /etc/pki/ovirt-engine/ca.pem。 - 7
- 如果您使用需要身份验证的镜像 registry，请添加凭证。
- 保存该文件。
获取 Red Hat Enterprise Linux KVM 客户机镜像 下载链接：
- 访问 Red Hat Customer Portal:下载 Red Hat Enterprise Linux。
- 在产品软件 选项卡中，找到 Red Hat Enterprise Linux KVM 客户机镜像。
右键单击 Download Now，复制 链接并保存。
该链接对时间敏感，且必须先复制，然后才能创建 bastion 虚拟机。
使用以下内容创建 /bastion_installation/create-bastion-machine-playbook.yaml 文件并更新其参数值：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Manager 机器的 FQDN。
- 2
<qcow_url>是 Red Hat Enterprise Linux KVM 客户机镜像的下载链接。Red Hat Enterprise Linux KVM 客户机镜像 包含cloud-init软件包，此 playbook 需要该软件包。如果没有使用 Red Hat Enterprise Linux，请下载cloud-init软件包，并在运行此 playbook 前手动安装它。
创建堡垒虚拟机：
ansible-playbook -i localhost create-bastion-machine-playbook.yaml -e @secure_vars.yaml --ask-vault-pass
# ansible-playbook -i localhost create-bastion-machine-playbook.yaml -e @secure_vars.yaml --ask-vault-passCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 登录管理门户。
- 点击 → 来验证 rhel-bastion 虚拟机是否已成功创建。
21.2. 使用堡垒虚拟机安装 OpenShift Container Platform
使用 Red Hat Virtualization 中的 bastion 虚拟机安装 OpenShift Container Platform。
流程
- 登录 rhel-bastion。
创建一个包含以下内容的 install_ocp.yaml 文件：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个包含以下内容的 setup_dns.yaml 文件：
- hosts: masters strategy: free tasks: - shell: "echo {{ ansible_default_ipv4.address }} {{ inventory_hostname }} etcd.{{ inventory_hostname.split('.', 1)[1] }} openshift-master.{{ inventory_hostname.split('.', 1)[1] }} openshift-public-master.{{ inventory_hostname.split('.', 1)[1] }} docker-registry-default.apps.{{ inventory_hostname.split('.', 1)[1] }} webconsole.openshift-web-console.svc registry-console-default.apps.{{ inventory_hostname.split('.', 1)[1] }} >> /etc/hosts" when: openshift_ovirt_all_in_one is defined | ternary((openshift_ovirt_all_in_one | bool), false)- hosts: masters strategy: free tasks: - shell: "echo {{ ansible_default_ipv4.address }} {{ inventory_hostname }} etcd.{{ inventory_hostname.split('.', 1)[1] }} openshift-master.{{ inventory_hostname.split('.', 1)[1] }} openshift-public-master.{{ inventory_hostname.split('.', 1)[1] }} docker-registry-default.apps.{{ inventory_hostname.split('.', 1)[1] }} webconsole.openshift-web-console.svc registry-console-default.apps.{{ inventory_hostname.split('.', 1)[1] }} >> /etc/hosts" when: openshift_ovirt_all_in_one is defined | ternary((openshift_ovirt_all_in_one | bool), false)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个包含以下内容的 /etc/ansible/openshift_3_11.hosts Ansible 清单文件：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 获取 Red Hat Enterprise Linux KVM 客户机镜像 下载链接：
- 访问 Red Hat Customer Portal:下载 Red Hat Enterprise Linux。
- 在产品软件 选项卡中，找到 Red Hat Enterprise Linux KVM 客户机镜像。
右键单击 Download Now，复制 链接并保存。
不要使用您在创建堡垒虚拟机时复制的链接。下载链接区分大小写，且必须先复制后才能运行安装 playbook。
使用以下内容创建 vars.yaml 文件并更新其参数值：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Manager 机器的 FQDN。
- 2
<qcow_url>是 Red Hat Enterprise Linux KVM 客户机镜像的下载链接。Red Hat Enterprise Linux KVM 客户机镜像 包含cloud-init软件包，此 playbook 需要该软件包。如果没有使用 Red Hat Enterprise Linux，请下载cloud-init软件包，并在运行此 playbook 前手动安装它。
安装 OpenShift Container Platform：
export ANSIBLE_ROLES_PATH="/usr/share/ansible/roles/:/usr/share/ansible/openshift-ansible/roles" export ANSIBLE_JINJA2_EXTENSIONS="jinja2.ext.do" ansible-playbook -i /etc/ansible/openshift_3_11.hosts install_ocp.yaml -e @vars.yaml -e @secure_vars.yaml --ask-vault-pass
# export ANSIBLE_ROLES_PATH="/usr/share/ansible/roles/:/usr/share/ansible/openshift-ansible/roles" # export ANSIBLE_JINJA2_EXTENSIONS="jinja2.ext.do" # ansible-playbook -i /etc/ansible/openshift_3_11.hosts install_ocp.yaml -e @vars.yaml -e @secure_vars.yaml --ask-vault-passCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 为每个基础架构实例创建路由器的 DNS 条目。
- 配置循环路由，以便路由器可以将流量传递到应用。
- 为 OpenShift Container Platform Web 控制台创建 DNS 条目。
- 指定负载均衡器节点的 IP 地址。
第 22 章 为 OpenStack 配置
22.1. 概述
在 OpenStack 上部署时，OpenShift Container Platform 可以配置为访问 OpenStack 基础架构，包括使用 OpenStack Cinder 卷作为应用程序数据的持久性存储。
OpenShift Container Platform 3.11 支持与 Red Hat OpenStack Platform 13 搭配使用。
最新的 OpenShift Container Platform 版本支持最新的 Red Hat OpenStack Platform 长生命版本和中间版本。OpenShift Container Platform 和 Red Hat OpenStack Platform 的发行周期不同，今后测试的版本会根据两个产品的发行日期的不同而有所不同。
22.2. 开始前
22.2.1. OpenShift Container Platform SDN
默认的 OpenShift Container Platform SDN 是 OpenShiftSDN。还有另一个选项： 使用 Kuryr SDN。
22.2.2. Kuryr SDN
Kuryr 是一个 CNI 插件，它使用 Neutron 和 Octavia 为 pod 和服务提供网络。它主要针对在 OpenStack 虚拟机上运行的 OpenShift Container Platform 集群设计。Kuryr 通过将 OpenShift Container Platform pod 插入 OpenStack SDN 来提高网络性能。另外，它还提供 OpenShift Container Platform pod 和 OpenStack 虚拟实例间的互联性。
建议在封装的 OpenStack 租户网络上部署 OpenShift Container Platform 时使用 Kuryr，以避免出现重复封装，例如通过 OpenStack 网络运行封装的 OpenShift SDN。每当需要 VXLAN、GRE 或 GENEVE 时，都建议使用 Kuryr。
因此，在以下情况下使用 Kuryr 并不有意义：
- 您可以使用提供商网络、租户 VLAN 或第三方商业 SDN，如 Cisco ACI 或 Juniper Contrail。
- 部署将在几个虚拟机监控程序或 OpenShift Container Platform 虚拟机节点上使用多个服务。每个 OpenShift Container Platform 服务会在 OpenStack 中创建一个 Octavia Amphora 虚拟机，它托管所需的负载均衡器。
要启用 Kuryr SDN，您的环境必须满足以下要求：
- 运行 OpenStack 13 或更高版本
- overcloud 带有 Octavia
- 启用 Neutron Trunk 端口扩展
- 如果使用 ML2/OVS Neutron 驱动程序，则必须使用 OpenvSwitch 防火墙驱动程序，而不是 ovs-hybrid。
要将 Kuryr 与 OpenStack 13.0.13 搭配使用，Kuryr 容器镜像必须是版本 3.11.306 或更高版本。
22.2.3. OpenShift Container Platform 先决条件
成功部署 OpenShift Container Platform 需要满足很多前提条件。其中包括一组基础架构和主机配置步骤，然后再使用 Ansible 进行 OpenShift Container Platform 的实际安装。在后续小节中，详细介绍了 OpenStack 环境中 OpenShift Container Platform 所需的前提条件和配置更改。
本参考环境中的所有 OpenStack CLI 命令都使用 CLI openstack 命令从 director 节点的不同节点执行。在另一节点中执行命令，以避免与 Ansible 版本 2.6 及更高版本产生软件包冲突。务必在指定的软件仓库中安装以下软件包。
例如：
从 Set Up Repositories 启用 rhel-7-server-openstack-13-tools-rpms 和所需的 OpenShift Container Platform 存储库。
sudo subscription-manager repos \
--enable rhel-7-server-openstack-{rhosp_version}-tools-rpms \
--enable rhel-7-server-openstack-14-tools-rpms
sudo subscription-manager repo-override --repo=rhel-7-server-openstack-14-tools-rpms --add=includepkgs:"python2-openstacksdk.* python2-keystoneauth1.* python2-os-service-types.*"
sudo yum install -y python2-openstackclient python2-heatclient python2-octaviaclient ansible
$ sudo subscription-manager repos \
--enable rhel-7-server-openstack-{rhosp_version}-tools-rpms \
--enable rhel-7-server-openstack-14-tools-rpms
$ sudo subscription-manager repo-override --repo=rhel-7-server-openstack-14-tools-rpms --add=includepkgs:"python2-openstacksdk.* python2-keystoneauth1.* python2-os-service-types.*"
$ sudo yum install -y python2-openstackclient python2-heatclient python2-octaviaclient ansible
验证软件包是否至少包含以下版本（使用 rpm -q <package_name>）:
-
python2-openstackclient-3.14.1.-1 -
python2-heatclient1.14.0-1 -
python2-octaviaclient1.4.0-1 -
python2-openstacksdk0.17.2
22.2.3.1. 启用 Octavia：OpenStack 负载平衡即服务(LBaaS)
Octavia 是一个支持的负载均衡器解决方案，建议与 OpenShift Container Platform 一起使用，以便对外部传入的流量进行负载平衡，并为应用程序提供 OpenShift Container Platform master 服务的单一视图。
要启用 Octavia，必须包含在安装 OpenStack overcloud 的过程中，如果 overcloud 已存在则需要升级 Octavia 服务。以下步骤提供启用 Octavia 的基本非自定义步骤，并适用于 overcloud 的干净安装或 overcloud 更新。
以下步骤只包括在部署 OpenStack 时需要处理 Octavia 部分的信息。有关更多信息，请参阅安装 OpenStack 文档。请注意对于节点 registry 方法会有所不同。有关更多信息，请参阅 Registry 方法 文档。这个示例使用了本地 registry 方法。
如果使用本地 registry，请创建一个模板来将镜像上传到 registry。如下例所示。
验证创建的 local_registry_images.yaml 是否包含 Octavia 镜像。
本地 registry 文件中的 Octavia 镜像
Octavia 容器的版本会根据安装的特定 Red Hat OpenStack Platform 版本而有所不同。
以下步骤从 registry.redhat.io 拉取容器镜像到 undercloud 节点。这个过程可能需要一些时间，具体要看网络和 undercloud 磁盘的速度。
(undercloud) $ sudo openstack overcloud container image upload \ --config-file /home/stack/local_registry_images.yaml \ --verbose
(undercloud) $ sudo openstack overcloud container image upload \
--config-file /home/stack/local_registry_images.yaml \
--verbose当 Octavia Load Balancer 用于访问 OpenShift API 时，需要增加它们的监听程序默认超时时间。默认超时为 50 秒。通过将以下文件传递给 overcloud deploy 命令，将超时时间增加到 20 分钟：
(undercloud) $ cat octavia_timeouts.yaml parameter_defaults: OctaviaTimeoutClientData: 1200000 OctaviaTimeoutMemberData: 1200000
(undercloud) $ cat octavia_timeouts.yaml
parameter_defaults:
OctaviaTimeoutClientData: 1200000
OctaviaTimeoutMemberData: 1200000在 Red Hat OpenStack Platform 14 起，不需要这样做。
使用 Octavia 安装或更新 overcloud 环境：
以上命令只包含与 Octavia 相关的文件。此命令将根据您具体的 OpenStack 安装而有所不同。如需更多信息，请参阅官方 OpenStack 文档 。有关自定义 Octavia 安装的详情请参考 使用 Director 安装 Octavia。
如果使用 Kuryr SDN，overcloud 安装需要在 Neutron 中启用"中继"扩展。这在 Director 部署中默认启用。当 Neutron 后端是 ML2/OVS 时，使用 openvswitch 防火墙而不是默认的 ovs-hybrid。如果后端为 ML2/OVN，则不需要修改。
22.2.3.2. 创建 OpenStack 用户帐户、项目和角色
在安装 OpenShift Container Platform 之前，Red Hat OpenStack Platform (RHOSP) 环境需要一个项目（通常称为 租户 ），后者存储了要安装的 OpenShift Container Platform 的 OpenStack 实例。此项目要求用户的所有权，并且该用户的角色设置为 _member_。
以下步骤演示了如何完成上述操作。
作为 OpenStack overcloud 管理员，
创建一个项目（租户），用于存储 RHOSP 实例
openstack project create <project>
$ openstack project create <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建拥有之前创建的项目的 RHOSP 用户：
openstack user create --password <password> <username>
$ openstack user create --password <password> <username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 设置用户的角色：
openstack role add --user <username> --project <project> _member_
$ openstack role add --user <username> --project <project> _member_Copy to Clipboard Copied! Toggle word wrap Toggle overflow
分配给新的 RH OSP 项目的默认配额不足以用于 OpenShift Container Platform 安装。将配额增加到至少 30 个安全组、200 个安全组规则和 200 端口。
openstack quota set --secgroups 30 --secgroup-rules 200 --ports 200 <project>
$ openstack quota set --secgroups 30 --secgroup-rules 200 --ports 200 <project>
- 1
- 对于
<project>，请指定要修改的项目名称
22.2.3.3. Kuryr SDN 的额外步骤
如果启用了 Kuryr SDN，特别是在使用命名空间隔离时，增加项目的配额以满足这些最低要求：
- 300 个安全组 - 每个命名空间对应一个命名空间，每个负载均衡器都对应一个
- 150 网络 - 每个命名空间有一个
- 150 个子网 - 每个命名空间都有一个
- 500 个安全组规则
- 500 端口 - 每个 Pod 一个端口，以及池的额外端口用于加快 Pod 创建
这不是全球推荐。调整您的配额以满足您的要求。
如果使用命名空间隔离，则每个命名空间都会获得一个新的网络和子网。另外，还会创建一个安全组来启用命名空间中的 Pod 间的流量。
openstack quota set --networks 150 --subnets 150 --secgroups 300 --secgroup-rules 500 --ports 500 <project>
$ openstack quota set --networks 150 --subnets 150 --secgroups 300 --secgroup-rules 500 --ports 500 <project>
- 1
- 对于
<project>，请指定要修改的项目名称
如果启用了命名空间隔离，您必须在创建项目后将项目 ID 添加到 octavia.conf 配置文件中。此步骤可确保所需的 LoadBalancer 安全组属于该项目，并可将其更新为在命名空间间强制实施服务隔离。
获取项目 ID
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将项目 ID 添加到控制器上的 [filename]octavia.conf 中，然后重新启动 octavia worker。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.2.3.4. 配置 RC 文件
配置完项目后，OpenStack 管理员可以创建对实施 OpenShift Container Platform 环境的用户所需的信息的 RC 文件。
一个 RC 文件示例：
只要引用同一域，就支持从默认值更改 _OS_PROJECT_DOMAIN_NAME 和 _OS_USER_DOMAIN_NAME。
作为在 OpenStack director 节点或工作站中实施 OpenShift Container Platform 环境的用户，请确保如下所示 source 凭证：
source path/to/examplerc
$ source path/to/examplerc22.2.3.5. 创建 OpenStack 类别
在 OpenStack 中，类别通过定义 nova 计算实例的计算、内存和存储容量来定义虚拟服务器的大小。由于此参考架构中的基础镜像是 Red Hat Enterprise Linux 7.5，因此使用以下规格创建 m1.node 和 m1.master 大小，如 表 22.1 “OpenShift 的最低系统要求” 所示。
虽然最小系统要求足以运行集群，以提高性能，但建议在 master 节点上增加 vCPU。另外，如果 etcd 位于 master 节点上，则建议更多内存。
| 节点类型 | CPU | RAM | 根磁盘 | Flavor |
|---|---|---|---|---|
| Master | 4 | 16 GB | 45 GB |
|
| 节点 | 1 | 8 GB | 20 GB |
|
作为 OpenStack 管理员，
openstack flavor create <flavor_name> \
--id auto \
--ram <ram_in_MB> \
--disk <disk_in_GB> \
--vcpus <num_vcpus>
$ openstack flavor create <flavor_name> \
--id auto \
--ram <ram_in_MB> \
--disk <disk_in_GB> \
--vcpus <num_vcpus>以下示例演示了在本参考环境中创建类别。
如果访问 OpenStack 管理员权限来创建新类别不可用，请在 OpenStack 环境中使用现有类别来满足 表 22.1 “OpenShift 的最低系统要求” 中的要求。
通过以下方法验证 OpenStack 类别：
openstack flavor list
$ openstack flavor list22.2.3.6. 创建 OpenStack 密钥对
Red Hat OpenStack Platform 使用 cloud-init 将 ssh 公钥放在每个实例上，允许 ssh 访问该实例。Red Hat OpenStack Platform 期望用户存放私钥。
丢失私钥将导致无法访问实例。
要生成密钥对，请使用以下命令：
openstack keypair create <keypair-name> > /path/to/<keypair-name>.pem
$ openstack keypair create <keypair-name> > /path/to/<keypair-name>.pem对密钥对创建进行验证可通过以下方法完成：
openstack keypair list
$ openstack keypair list
创建了密钥对后，将权限设置为 600，从而仅允许文件所有者来读取和写入该文件。
chmod 600 /path/to/<keypair-name>.pem
$ chmod 600 /path/to/<keypair-name>.pem22.2.3.7. 为 OpenShift Container Platform 设置 DNS
DNS 服务是 OpenShift Container Platform 环境中的一个重要组件。无论 DNS 的供应商如何，机构都需要有特定记录才能为各种 OpenShift Container Platform 组件提供服务。
使用 /etc/hosts 无效，必须存在正确的 DNS 服务。
通过使用 DNS 的关键 secret，您可以为 OpenShift Ansible 安装程序提供信息，它将自动为目标实例和各种 OpenShift Container Platform 组件添加记录。稍后将在配置 OpenShift Ansible 安装程序时描述此过程设置。
预期可以访问 DNS 服务器。您可以使用 Red Hat Labs DNS 帮助程序 获得访问权限的帮助。
应用程序 DNS
OpenShift 提供的应用可通过端口 80/TCP 和 443/TCP 上的路由器访问。路由器使用通配符记录将特定子域下的所有主机名映射到同一 IP 地址，而无需为每个名称单独记录。
这允许 OpenShift Container Platform 添加带有任意名称的应用程序，只要它们位于那个子域下。
例如，*. apps.example.com 的通配符记录会导致 DNS 名称查找 tax.apps.example.com 和 home-goods.apps.example.com，两者返回相同的 IP 地址：10.19.x.y.所有流量都转发到 OpenShift 路由器。路由器检查查询的 HTTP 标头并将其转发到正确的目的地。
使用负载均衡器（如 Octavia、主机地址 10.19.x.y）时，可以添加通配符 DNS 记录，如下所示：
| IP 地址 | Hostname | 用途 |
|---|---|---|
| 10.19.x.y |
| 对应用程序 Web 服务的用户访问 |
在 Red Hat OpenStack Platform 上部署 OpenShift Container Platform 时，该片段中描述的要求有两个网络是 public -public 和 内部网络。
公共网络
公共网络 是包含外部访问的网络，可以被外部世界访问。公共网络创建只能由 OpenStack 管理员执行。
以下命令提供了为 公共网络 访问创建 OpenStack 提供商网络的示例。
作为 OpenStack 管理员（overcloudrc 访问），
创建网络和子网后，通过以下方法验证：
openstack network list openstack subnet list
$ openstack network list
$ openstack subnet list
<float_start_ip & gt; 和 <float_end_ip > 是提供给标记为 公共网络 的浮动 IP 池。无类别域间路由(CIDR)采用 <ip>/<routing_prefix> 格式，如 10.0.0.1/24。
内部网络
在网络设置过程中，内部网络通过路由器连接到公共网络。这样，每个附加到内部网络的 Red Hat OpenStack Platform 实例都可以从公共网络请求浮动 IP 进行公共访问。通过设置 openshift_openstack_private_network_name 来自动由 OpenShift Ansible 安装程序自动创建 内部网络。稍后介绍了有关 OpenShift Ansible 安装程序所需更改的更多信息。
22.2.3.9. 创建 OpenStack 部署主机安全组
OpenStack 网络允许用户定义入站和出站流量过滤器，可以应用到网络上的每个实例。这允许用户根据实例服务的功能限制每个实例的网络流量，而不依赖于基于主机的过滤。OpenShift Ansible 安装程序处理除部署主机外，为 OpenShift Container Platform 集群一部分的每种主机需要的所有端口和服务正确创建。
以下命令创建一个空安全组，没有为部署主机设置规则。
source path/to/examplerc openstack security group create <deployment-sg-name>
$ source path/to/examplerc
$ openstack security group create <deployment-sg-name>验证安全组的创建：
openstack security group list
$ openstack security group list部署主机安全组
部署实例只需要允许入站 ssh。此实例存在，供操作员提供一个稳定的基础，以部署、监控和管理 OpenShift Container Platform 环境。
| 端口/协议 | 服务 | 远程源 | 用途 |
|---|---|---|---|
| ICMP | ICMP | 任意 | 允许 ping、traceroute 等。 |
| 22/TCP | SSH | 任意 | 安全 shell 登录 |
创建上述安全组规则如下：
安全组规则验证如下：
22.2.3.10. OpenStack Cinder 卷
OpenStack Block Storage 通过 cinder 服务提供持久的块存储管理。块存储使得 OpenStack 用户能够创建可以连接到不同 OpenStack 实例的卷。
22.2.3.10.1. Docker 卷
master 和节点实例包含用于存储 docker 镜像的卷。卷的目的是确保大型镜像或容器不破坏现有节点的节点性能或能力。
运行容器至少需要 15GB 的 docker 卷。这可能需要根据每个节点运行的大小和容器数量进行调整。
docker 卷由 OpenShift Ansible 安装程序通过变量 openshift_openstack_docker_volume_size 创建。稍后介绍了有关 OpenShift Ansible 安装程序所需更改的更多信息。
22.2.3.10.2. registry 卷
OpenShift 镜像注册表需要一个 cinder 卷，以确保在 registry 需要迁移到另一个节点时保存镜像。以下步骤演示了如何通过 OpenStack 创建镜像 registry。创建卷后，卷 ID 将包含在 OpenShift Installer OSEv3.yml 文件中，该文件通过参数 openshift_hosted_registry_storage_openstack_volumeID 如下所述。
source /path/to/examplerc openstack volume create --size <volume-size-in-GB> <registry-name>
$ source /path/to/examplerc
$ openstack volume create --size <volume-size-in-GB> <registry-name>registry 卷大小应该至少有 30GB。
验证卷的创建。
22.2.3.11. 创建并配置部署实例
部署实例的角色是充当 OpenShift Container Platform 部署和管理的 utility 主机。
创建部署主机网络和路由器
在创建实例之前，必须创建一个内部网络和路由器来与部署主机通信。以下命令创建了该网络和路由器。
部署部署实例
创建网络和安全组时，部署该实例。
默认情况下，如果 m1.small 类别不存在，则使用满足 1 vCPU 和 2GB RAM 要求的现有类别。
创建并将浮动 IP 添加到部署实例
创建部署实例后，必须创建一个浮动 IP，然后分配给实例。以下示例显示了示例。
在上面的输出中，floating_ip_address 字段显示创建了浮动 IP 10.20.120.150。要将这个 IP 分配给部署实例，请运行以下命令：
source /path/to/examplerc openstack server add floating ip <deployment-instance-name> <ip>
$ source /path/to/examplerc
$ openstack server add floating ip <deployment-instance-name> <ip>
例如，如果实例 deployment.example.com 被分配 IP 10.20.120.150，则命令将为：
source /path/to/examplerc openstack server add floating ip deployment.example.com 10.20.120.150
$ source /path/to/examplerc
$ openstack server add floating ip deployment.example.com 10.20.120.150在部署主机中添加 RC 文件
部署主机存在后，通过 scp 将之前创建的 RC 文件复制到部署主机上，如下所示
scp <rc-file-deployment-host> cloud-user@<ip>:/home/cloud-user/
scp <rc-file-deployment-host> cloud-user@<ip>:/home/cloud-user/22.2.3.12. OpenShift Container Platform 的部署配置
以下小节描述了正确配置部署实例所需的所有步骤。
配置 ~/.ssh/config 以使用 Deployment Host 作为 Jumphost
要轻松连接到 OpenShift Container Platform 环境，请按照以下步骤操作。
在 OpenStack director 节点上，或使用私钥 <keypair-name>.pem 的本地工作站：
exec ssh-agent bash ssh-add /path/to/<keypair-name>.pem
$ exec ssh-agent bash
$ ssh-add /path/to/<keypair-name>.pem
Identity added: /path/to/<keypair-name>.pem (/path/to/<keypair-name>.pem)
添加到 ~/.ssh/config 文件中：
Host deployment
HostName <deployment_fqdn_hostname OR IP address>
User cloud-user
IdentityFile /path/to/<keypair-name>.pem
ForwardAgent yes
Host deployment
HostName <deployment_fqdn_hostname OR IP address>
User cloud-user
IdentityFile /path/to/<keypair-name>.pem
ForwardAgent yes
使用带有 -A 选项的 ssh 连接到部署主机，这可以启用转发身份验证代理连接。
确保只针对 ~/.ssh/config 文件所有者的读取写入权限：
chmod 600 ~/.ssh/config
$ chmod 600 ~/.ssh/configssh -A cloud-user@deployment
$ ssh -A cloud-user@deployment
登录部署主机后，请通过检查 SSH_AUTH_SOCK 来验证 ssh 代理转发是否正常工作
echo "$SSH_AUTH_SOCK"
$ echo "$SSH_AUTH_SOCK"
/tmp/ssh-NDFDQD02qB/agent.1387订阅管理器并启用 OpenShift Container Platform 软件仓库
在部署实例中，在 Red Hat Subscription Manager 中注册。这可以通过使用凭证来实现：
sudo subscription-manager register --username <user> --password '<password>'
$ sudo subscription-manager register --username <user> --password '<password>'另外，您可以使用激活码：
sudo subscription-manager register --org="<org_id>" --activationkey=<keyname>
$ sudo subscription-manager register --org="<org_id>" --activationkey=<keyname>注册后，启用以下软件仓库，如下所示：
请参阅设置存储库，以确认要启用的 OpenShift Container Platform 存储库和 Ansible 版本。以上文件只是一个示例。
部署主机上所需的软件包
部署主机上需要安装以下软件包。
安装以下软件包：
-
openshift-ansible -
python-openstackclient -
python2-heatclient -
python2-octaviaclient -
python2-shade -
python-dns -
git -
ansible
sudo yum -y install openshift-ansible python-openstackclient python2-heatclient python2-octaviaclient python2-shade python-dns git ansible
$ sudo yum -y install openshift-ansible python-openstackclient python2-heatclient python2-octaviaclient python2-shade python-dns git ansible配置 Ansible
ansible 安装在部署实例上，以执行注册、安装软件包，并在 master 和节点实例上部署 OpenShift Container Platform 环境。
在运行 playbook 前，务必要创建一个 ansible.cfg 文件来反映您要部署的环境：
以下参数值对于 ansible.cfg 文件很重要。
-
remote_user必须保留为用户 openshift。 - inventory 参数确保两个清单之间没有空格。
示例： inventory = path/to/inventory1,path/to/inventory2
以上代码块可覆盖文件中的默认值。确保使用复制到部署实例的密钥对填充 <keypair-name>。
inventory 目录在 第 22.3.1 节 “为置备准备清单” 中创建。
OpenShift Authentication
OpenShift Container Platform 提供了使用许多不同的身份验证平台。如需身份验证选项列表，请参阅 配置身份验证和用户代理。
配置默认身份提供程序非常重要，因为默认配置是 Deny All。
完成部署配置部署主机后，我们将使用 Ansible 为部署 OpenShift Container Platform 准备环境。在以下小节中，配置了 Ansible，并修改某些 YAML 文件，以实现 OpenStack 部署成功的 OpenShift Container Platform。
22.3.1. 为置备准备清单
通过前面的步骤安装 openshift-ansible 软件包后，有一个 sample-inventory 目录，我们将复制到部署主机的 cloud-user 主目录。
在部署主机上，
cp -r /usr/share/ansible/openshift-ansible/playbooks/openstack/sample-inventory/ ~/inventory
$ cp -r /usr/share/ansible/openshift-ansible/playbooks/openstack/sample-inventory/ ~/inventory在这个清单目录中，all.yml 文件包含所有必须设置的不同参数，才能成功置备 RHOCP 实例。OSEv3.yml 文件包含 all.yml 文件和可自定义的所有可用 OpenShift Container Platform 集群参数的一些引用。
22.3.1.1. OpenShiftSDN 所有 YAML 文件
all.yml 文件有许多选项，可以修改以符合您的特定需求。此文件中收集的信息适用于成功部署 OpenShift Container Platform 所需的实例的调配部分。务必要仔细审阅。本文档将提供所有 YAML 文件的精简版本，并专注于为成功部署而需要设置的最关键参数。
由于使用外部 DNS 服务器，私有和公共部分使用 DNS 服务器的公共 IP 地址，因为 DNS 服务器不驻留在 OpenStack 环境中。
以上以星号(*)括起的值需要根据您的 OpenStack 环境和 DNS 服务器进行修改。
要正确修改 All YAML 文件的 DNS 部分，登录到 DNS 服务器并执行以下命令捕获密钥名称、密钥算法和密钥 secret：
密钥名称可能有所不同，上面的只是一个示例。
22.3.1.2. KuryrSDN 所有 YAML 文件
以下 all.yml 文件启用 Kuryr SDN 而不是默认的 OpenShiftSDN。请注意，以下示例是密度的版本，务必要仔细检查默认模板。
如果使用命名空间隔离，Kuryr-controller 会为每个命名空间创建一个新的 Neutron 网络和子网。
启用 Kuryr SDN 时不支持网络策略和节点端口服务。
如果启用了 Kuryr，OpenShift Container Platform 服务会通过 OpenStack Octavia Amphora 虚拟机实现。
Octavia 不支持 UDP 负载均衡。不支持公开 UDP 端口的服务。
22.3.1.2.1. 配置全局命名空间访问权限
kuryr_openstack_global_namespace 参数包含定义全局命名空间的列表。默认情况下，只有 默认 和 openshift-monitoring 命名空间包含在此列表中。
如果您要从 OpenShift Container Platform 3.11 的以前的 z-release 升级，请注意，从全局命名空间中对其他命名空间的访问由安全组 *-allow_from_default 控制。
虽然 remote_group_id 规则 可以从全局命名空间中控制对其他命名空间的访问，但使用该脚本可能会导致缩放和连接问题。要避免这些问题，请从在 *_allow_from_default 到 remote_ip_prefix 处使用 remote_group_id:
在命令行中检索您的网络
subnetCIDR值：oc get kuryrnets ns-default -o yaml | grep subnetCIDR
$ oc get kuryrnets ns-default -o yaml | grep subnetCIDR subnetCIDR: 10.11.13.0/24Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为这个范围创建 TCP 和 UDP 规则：
openstack security group rule create --remote-ip 10.11.13.0/24 --protocol tcp openshift-ansible-openshift.example.com-allow_from_default openstack security group rule create --remote-ip 10.11.13.0/24 --protocol udp openshift-ansible-openshift.example.com-allow_from_default
$ openstack security group rule create --remote-ip 10.11.13.0/24 --protocol tcp openshift-ansible-openshift.example.com-allow_from_default $ openstack security group rule create --remote-ip 10.11.13.0/24 --protocol udp openshift-ansible-openshift.example.com-allow_from_defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除使用
remote_group_id的安全组规则：openstack security group show *-allow_from_default | grep remote_group_id openstack security group rule delete REMOTE_GROUP_ID
$ openstack security group show *-allow_from_default | grep remote_group_id $ openstack security group rule delete REMOTE_GROUP_IDCopy to Clipboard Copied! Toggle word wrap Toggle overflow
| 变量 | 描述 |
|---|---|
| openshift_openstack_clusterid | 集群识别名称 |
| openshift_openstack_public_dns_domain | 公共 DNS 域名 |
| openshift_openstack_dns_nameservers | DNS 名称服务器的 IP |
| openshift_openstack_public_hostname_suffix | 在公共和私有的 DNS 记录中的节点主机名中添加后缀 |
| openshift_openstack_nsupdate_zone | 要使用 OCP 实例 IP 更新的区域 |
| openshift_openstack_keypair_name | 用于登录 OCP 实例的密钥对名称 |
| openshift_openstack_external_network_name | OpenStack 公共网络名称 |
| openshift_openstack_default_image_name | 用于 OCP 实例的 OpenStack 镜像 |
| openshift_openstack_num_masters | 要部署的 master 节点数量 |
| openshift_openstack_num_infra | 要部署的基础架构节点数量 |
| openshift_openstack_num_cns | 要部署的容器原生存储节点数量 |
| openshift_openstack_num_nodes | 要部署的应用程序节点数量 |
| openshift_openstack_master_flavor | 用于 master 实例的 OpenStack 类别的名称 |
| openshift_openstack_default_flavor | 如果未指定的具体类别，则 Openstack 类别的名称用于所有实例。 |
| openshift_openstack_use_lbaas_load_balancer | 启用 Octavia 负载均衡器的布尔值（必须安装Octavia） |
| openshift_openstack_docker_volume_size | Docker 卷的最小大小（必需变量） |
| openshift_openstack_external_nsupdate_keys | 使用实例 IP 地址更新 DNS |
| ansible_user | 用于部署 OpenShift Container Platform 的 Ansible 用户。"openshift"是需要的名称，且不得更改。 |
| openshift_openstack_disable_root | 禁用 root 访问权限的布尔值 |
| openshift_openstack_user | 使用此用户创建的 OCP 实例 |
| openshift_openstack_node_subnet_name | 用于部署的现有 OpenShift 子网的名称。这应该与用于您的部署主机的子网名称相同。 |
| openshift_openstack_router_name | 用于部署的现有 OpenShift 路由器的名称。这应该与用于部署主机的路由器名称相同。 |
| openshift_openstack_master_floating_ip |
默认为 |
| openshift_openstack_infra_floating_ip |
默认为 |
| openshift_openstack_compute_floating_ip |
默认为 |
| openshift_use_openshift_sdn |
如果要禁用 openshift-sdn，则必须设置为 |
| openshift_use_kuryr |
如果要启用 kuryr sdn，则必须设置为 |
| use_trunk_ports |
必须设置为 |
| os_sdn_network_plugin_name |
选择 SDN 行为。为 kuryr 设置为 |
| openshift_node_proxy_mode |
必须将 Kuryr 设置为 |
| openshift_master_open_ports | 使用 Kuryr 时会在虚拟机上打开的端口 |
| kuryr_openstack_public_net_id | 由 Kuryr 的需求。从中获取 FIP 的公共 OpenStack 网络的 ID |
| openshift_kuryr_subnet_driver |
Kuryr Subnet 驱动程序。必须是 |
| openshift_kuryr_sg_driver |
Kuryr 安全组驱动程序。必须是 |
| kuryr_openstack_global_namespaces |
用于命名空间隔离的全局命名空间。默认值为 |
| kuryr_openstack_ca | 到云的 CA 证书的路径。如果 OpenStack 云端点可以通过 HTTPS 访问，则需要此项。 |
22.3.1.3. OSEv3 YAML 文件
OSEv3 YAML 文件指定与 OpenShift 安装相关的所有不同参数和自定义。
以下是文件的一个精简版本，其中包含成功部署所需的所有变量。根据特定 OpenShift Container Platform 部署所需的自定义，可能需要额外的变量。
有关列出的任何变量的更多详情，请参阅 OpenShift-Ansible 主机清单示例。
22.3.2. OpenStack 先决条件 Playbook
OpenShift Container Platform Ansible 安装程序提供了一个 playbook，以确保满足 OpenStack 实例的所有置备步骤。
在运行 playbook 之前，请确保 source RC 文件
source path/to/examplerc
$ source path/to/examplerc
通过部署主机上的 ansible-playbook 命令，使用 prerequisites.yml playbook 确保满足所有先决条件：
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openstack/openshift-cluster/prerequisites.yml
$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openstack/openshift-cluster/prerequisites.yml当先决条件 playbook 成功完成后，运行置备 playbook，如下所示：
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openstack/openshift-cluster/provision.yml
$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openstack/openshift-cluster/provision.yml如果 provision.yml prematurely 错误，请检查 OpenStack 堆栈的状态并等待它完成
如果堆栈显示 CREATE_IN_PROGRESS，请等待堆栈以最终结果（如 CREATE_COMPLETE ）完成。如果堆栈成功完成，请重新运行 provision.yml playbook，以完成所有其他必要的步骤。
如果堆栈显示 CREATE_FAILED，请确保运行以下命令来查看导致错误的原因：
openstack stack failures list openshift-cluster
$ openstack stack failures list openshift-cluster22.3.3. 堆栈名称配置
默认情况下，OpenStack 为 OpenShift Container Platform 集群创建的 Heat 堆栈名为 openshift-cluster。如果要使用其他名称，必须在运行 playbook 前设置 OPENSHIFT_CLUSTER 环境变量：
export OPENSHIFT_CLUSTER=openshift.example.com
$ export OPENSHIFT_CLUSTER=openshift.example.com
如果使用非默认堆栈名称并运行 openshift-ansible playbook 来更新部署，您必须将 OPENSHIFT_CLUSTER 设置为您的堆栈名称以避免错误。
成功置备节点后，下一步是确保通过 subscription-manager 成功注册所有节点，以安装成功 OpenShift Container Platform 安装的所有必要软件包。为简单起见，已创建了一个并提供了 repos.yml 文件。
请参阅 Set Up Repositories 来确认要启用的软件仓库和版本。以上文件只是一个示例。
使用 repos.yml，运行 ansible-playbook 命令：
ansible-playbook repos.yml
$ ansible-playbook repos.yml
上例使用 Ansible 的 redhat_subscription 和 rhsm_repository 模块来进行所有注册，禁用和启用存储库。本特定示例使用了使用红帽激活码。如果您没有激活码，请确保访问 Ansible redhat_subscription 模块以使用用户名和密码进行修改，如下例所示： https://docs.ansible.com/ansible/2.6/modules/redhat_subscription_module.html
有时候，redhat_subscription 模块可能会在某些节点上失败。如果出现这个问题，请使用 subscription-manager 手动注册 OpenShift Container Platform 实例。
在调配的 OpenStack 实例后，将重点转移到安装 OpenShift Container Platform。安装和配置通过 OpenShift RPM 软件包提供的一系列 Ansible playbook 和角色来进行。查看之前配置好的 OSEv3.yml 文件，以确保所有选项都已正确设置。
在运行安装程序 playbook 之前，请确保通过以下方法满足所有 {rhocp} 先决条件：
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml
$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml运行安装程序 playbook 以安装 Red Hat OpenShift Container Platform：
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openstack/openshift-cluster/install.yml
$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openstack/openshift-cluster/install.ymlOpenShift Container Platform 版本 3.11 支持 RH OSP 14 和 RH OSP 13。OpenShift Container Platform 版本 3.10 需要运行在 RH OSP 13 上。
22.6. 将配置更改应用到现有 OpenShift Container Platform 环境
在所有 master 和节点主机上启动或重启 OpenShift Container Platform 服务以应用您的配置更改，请参阅重启 OpenShift Container Platform 服务 ：
master-restart api master-restart controllers systemctl restart atomic-openshift-node
# master-restart api
# master-restart controllers
# systemctl restart atomic-openshift-nodeKubernetes 架构需要来自云提供商的可靠端点。当云提供商停机时，kubelet 会防止 OpenShift Container Platform 重启。如果底层云供应商端点不可靠，请不要安装使用云供应商集成的集群。如在裸机环境中一样安装集群。不建议在已安装的集群中打开或关闭云提供商集成。但是，如果该情境不可避免，请完成以下过程。
从不使用云供应商切换到使用云提供商会产生错误消息。添加云供应商会尝试删除节点，因为从其切换的节点使用 hostname 作为 externalID （当没有云供应商使用时）使用云供应商的 instance-id （由云提供商指定）。要解决这个问题：
- 以集群管理员身份登录到 CLI。
检查和备份现有节点标签：
oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除节点：
oc delete node <node_name>
$ oc delete node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在每个节点主机上，重启 OpenShift Container Platform 服务。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 在每个主机上重新添加回您以前具有的标记。
22.6.1. 在现有 OpenShift 环境中配置 OpenStack 变量
要设置所需的 OpenStack 变量，请修改所有 OpenShift Container Platform 主机上以下内容的 /etc/origin/cloudprovider/openstack.conf 文件，包括 master 和节点：
请参考您的 OpenStack 管理员获取 OS_ 变量的值，它们通常用于 OpenStack 配置。
22.6.2. 为动态创建的 OpenStack PV 配置区域标签
管理员可以为动态创建的 OpenStack PV 配置区域标签。如果 OpenStack Cinder 区域名称与计算区域名称不匹配，则此选项很有用，例如，如果只有一个 Cinder 区域，并且有多个计算区域。管理员可以动态创建 Cinder 卷，然后检查标签。
查看 PV 的区标签：
oc get pv --show-labels
# oc get pv --show-labels
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS
pvc-1faa6f93-64ac-11e8-930c-fa163e3c373c 1Gi RWO Delete Bound openshift-node/pvc1 standard 12s failure-domain.beta.kubernetes.io/zone=nova
默认设置是 enabled。使用 oc get pv --show-labels 命令返回 failure-domain.beta.kubernetes.io/zone=nova 标签。
要禁用区标签，请通过添加以下内容更新 openstack.conf 文件：
[BlockStorage] ignore-volume-az = yes
[BlockStorage]
ignore-volume-az = yes重启 master 服务后创建的 PV 将不会具有 zone 标签。
第 23 章 为 Google Compute Engine 配置
您可以配置 OpenShift Container Platform 以访问现有的 Google Compute Engine(GCE)基础架构，包括使用 GCE 卷作为应用程序数据的持久性存储。
23.1. 开始前
23.1.1. 为 Google Cloud Platform 配置授权
角色
为 OpenShift Container Platform 配置 GCP 需要以下 GCP 角色：
|
| 创建服务帐户、云存储、实例、镜像、模板、云 DNS 条目以及部署负载均衡器和健康检查所需要的。 |
如果用户应在测试阶段重新部署环境，则需要删除权限。
您还可以创建服务帐户以避免在部署 GCP 对象时使用个人用户。
如需更多信息，请参阅 GCP 文档中的了解角色部分，包括如何配置角色的步骤。
范围和服务帐户
GCP 使用范围来确定经过身份验证的身份是否有权在资源内执行操作。例如，如果具有只读范围访问令牌的应用程序 A 只能读取，而具有读写范围访问令牌的应用程序 B 可能会读取和修改数据。
范围在 GCP API 级别中定义为 https://www.googleapis.com/auth/compute.readonly。
您可以使用 --scopes=[SCOPE,… 指定范围。] 选项在创建实例时，或者您可以使用 --no-scopes 选项来创建实例，如果没有考虑实例访问 GCP API，则可以使用 --no-scopes 选项来创建实例。
如需更多信息，请参阅 GCP 文档中的 Scopes 部分。
所有 GCP 项目都包括一个默认的 [PROJECT_NUMBER]-compute@developer.gserviceaccount.com 服务帐户，具有项目编辑器权限。
默认情况下，新创建的实例会自动启用为具有以下访问范围的默认服务帐户运行：
- https://www.googleapis.com/auth/devstorage.read_only
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/pubsub
- https://www.googleapis.com/auth/service.management.readonly
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/trace.append
- https://www.googleapis.com/auth/bigquery
- https://www.googleapis.com/auth/cloud-platform
- https://www.googleapis.com/auth/compute.readonly
- https://www.googleapis.com/auth/compute
- https://www.googleapis.com/auth/datastore
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/service.management.readonly
- https://www.googleapis.com/auth/sqlservice.admin
- https://www.googleapis.com/auth/devstorage.full_control
- https://www.googleapis.com/auth/devstorage.read_only
- https://www.googleapis.com/auth/devstorage.read_write
- https://www.googleapis.com/auth/taskqueue
- https://www.googleapis.com/auth/userinfo.email
在创建实例时，您可以使用 --service-account=SERVICE_ACCOUNT 选项指定另一个服务帐户，或使用 gcloud CLI 明确禁用实例的 服务帐户。
23.1.2. Google Compute Engine 对象
将 OpenShift Container Platform 与 Google Compute Engine(GCE)集成需要以下组件或服务。
- GCP 项目
- GCP 项目是组织基本级别的实体，它组成了创建、启用和使用所有 GCP 服务的基础。这包括管理 API、启用账单、添加和删除协作器以及管理权限。
如需更多信息，请参阅 GCP 文档中的项目资源部分。
项目 ID 是唯一标识符，项目 ID 必须在所有 Google Cloud Engine 之间唯一。这意味着，如果其他人使用该 ID 创建了一个项目 ID，则您无法使用 myproject 作为项目 ID。
- 账单
- 除非将账单附加到帐户，否则您无法创建新的资源。新项目可以链接到现有项目，也可以输入新的信息。
如需更多信息，请参阅 GCP 文档中的创建、修改或关闭您的账单帐户。
- 云身份和访问管理
- 部署 OpenShift Container Platform 需要正确权限。用户必须能够创建服务帐户、云存储、实例、镜像、模板、云 DNS 条目，以及部署负载均衡器和健康检查。删除权限也会有帮助，以便在测试过程中重新部署环境。
您可以使用特定权限创建服务帐户，然后使用它们部署基础架构组件，而不是常规用户。您还可以创建角色来限制对不同用户或服务帐户的访问。
GCP 实例使用服务帐户来允许应用程序调用 GCP API。例如，OpenShift Container Platform 节点主机可以调用 GCP 磁盘 API，为应用程序提供持久性卷。
IAM 服务可使用对各种基础架构、服务资源和细粒度角色的访问控制。如需更多信息，请参阅 GCP 文档中的访问云概述 部分。
- SSH 密钥
- GCP 将 SSH 公钥作为授权密钥注入，以便您可以在创建的实例中使用 SSH 登录。您可以为每个实例或每个项目配置 SSH 密钥。
您可以使用现有的 SSH 密钥。GCP 元数据可帮助存储实例中引导时注入的 SSH 密钥，以允许 SSH 访问。
如需更多信息，请参阅 GCP 文档中的 Metadata 部分。
- GCP 区域和区
- GCP 有一个覆盖区域和可用区的全局基础架构。在不同区的 GCP 中部署 OpenShift Container Platform 有助于避免出现单点故障，但存储有一些注意事项。
GCP 磁盘在区内创建。因此，如果 OpenShift Container Platform 节点主机在区域 "A" 中停机，并且 pod 移到 zone "B"，则持久性存储无法附加到这些 pod，因为磁盘位于不同的区。
在安装 OpenShift Container Platform 前，部署多区 OpenShift Container Platform 环境是一个重要决定。如果部署多区环境，建议的设置是在单一区域中使用三个不同的区。
如需更多信息 ，请参阅 GCP 文档中有关 区域和 区的 Kubernetes 文档。
- 外部 IP 地址
- 因此，GCP 实例可以与互联网通信，您必须将外部 IP 地址附加到实例。另外，还需要外部 IP 地址与从 Virtual Private Cloud(VPC)网络外部署的实例进行通信。
需要外部 IP 地址 进行互联网访问 是该提供程序的限制。如果需要，您可以将防火墙规则配置为阻止实例中进入的外部流量。
如需更多信息，请参阅外部 IP 地址上的 GCP 文档。
- Cloud DNS
- GCP Cloud DNS 是一个 DNS 服务，用于使用 GCP DNS 服务器将域名发布到全局 DNS。
公共云 DNS 区域需要一个通过 Google 的"Domains"服务或第三方供应商购买的域名。在创建区时，必须将 Google 提供的名称服务器添加到注册商中。
如需更多信息，请参阅 Cloud DNS 的 GCP 文档。
GCP VPC 网络有一个内部 DNS 服务，可自动解析内部主机名。
实例的内部完全限定域名(FQDN)遵循 [HOST_NAME].c.[PROJECT_ID].internal 格式。
如需更多信息，请参阅内部 DNS 上的 GCP 文档。
- 负载平衡
- GCP 负载均衡服务启用在 GCP 云中的多个实例间流量分布。
负载均衡有三种：
HTTPS 和 TCP 代理负载平衡是 master 节点使用 HTTPS 健康检查的唯一选项，用于检查 /healthz 的状态。
由于 HTTPS 负载均衡需要自定义证书，这种实现使用 TCP 代理负载平衡来简化过程。
如需更多信息，请参阅 GCP 文档。
- 实例大小
- 成功的 OpenShift Container Platform 环境需要一些最低硬件要求：
| 角色 | 大小 |
|---|---|
| Master |
|
| 节点 |
|
GCP 允许您创建自定义实例大小来满足不同的要求。如需更多信息，请参阅使用自定义 Machine Type 创建实例，或参阅 Machine type 和 OpenShift Container Platform Minimum 硬件要求来获得有关实例大小的更多信息。
- 存储选项
默认情况下，每个 GCP 实例都有一个包含操作系统的小根磁盘。当实例中运行的应用程序需要更多存储空间时，您可以为实例添加额外的存储选项：
- 标准持久性磁盘
- SSD 持久性磁盘
- 本地 SSD
- 云存储存储桶
如需更多信息，请参阅有关存储选项的 GCP 文档。
23.2. 为 GCE 配置 OpenShift Container Platform
您可以通过两种方式为 GCE 配置 OpenShift Container Platform：
您可以在安装时或安装后修改 Ansible 清单文件，为 Google Compute Platform(GCP)配置 OpenShift Container Platform。
流程
您至少必须定义
openshift_cloudprovider_kind、openshift_gcp_project和openshift_gcp_prefix参数，以及对于 multizone 部署的可选openshift_gcp_multizone，则为openshift_gcp_network_name定义。在安装时将以下部分添加到 Ansible 清单文件中，以便为 GCP 配置 OpenShift Container Platform 环境：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用 Ansible 安装也会创建并配置以下文件以适合您的 GCP 环境：
- /etc/origin/cloudprovider/gce.conf
- /etc/origin/master/master-config.yaml
- /etc/origin/node/node-config.yaml
-
如果您使用 GCP 运行负载均衡器服务，Compute Engine 虚拟机实例需要
ocp后缀。例如，如果openshift_gcp_prefix参数的值设置为mycluster，则必须标记带有myclusterocp的节点。有关如何在 Compute Engine 虚拟机实例中添加网络标签的更多信息，请参阅添加和删除网络标签。 另外，您可以配置多区支持。
集群安装过程默认配置单区支持，但您可以配置多个区以避免出现单一故障点。
因为 GCP 磁盘是在区中创建的，在不同的区上的 GCP 中部署 OpenShift Container Platform 可能会导致存储出现问题。如果 OpenShift Container Platform 节点主机在区域 "A" 中停机，并且 pod 移到 zone "B"，则持久性存储无法附加到这些 pod，因为磁盘现在位于不同的区。如需更多信息，请参阅 Kubernetes 文档中的多个区限制。
要使用 Ansible 清单文件启用多区支持，请添加以下参数：
[OSEv3:vars] openshift_gcp_multizone=true
[OSEv3:vars] openshift_gcp_multizone=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要返回单区支持，将
openshift_gcp_multizone值设置为false，然后重新运行 Ansible 清单文件。
23.2.2. 选项 2：为 GCE 手动配置 OpenShift Container Platform
23.2.2.1. 为 GCE 手动配置 master 主机
在所有 master 主机上执行以下步骤。
流程
默认情况下，将 GCE 参数添加到
/etc/origin/master/master-config.yaml中的 master 配置文件的apiServerArguments和controllerArguments部分：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用 Ansible 为 GCP 配置 OpenShift Container Platform 时，会自动创建 /etc/origin/cloudprovider/gce.conf 文件。由于您要手动为 GCP 配置 OpenShift Container Platform，所以您必须创建该文件并输入以下命令：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 集群安装过程默认配置单区支持。
在不同区的 GCP 中部署 OpenShift Container Platform 有助于避免出现单一故障点，但可能会导致存储出现问题。这是因为 GCP 磁盘是在区中创建。如果 OpenShift Container Platform 节点主机在区域 "A" 中停机，并且 pod 应该移到 zone "B" 中，则持久性存储无法附加到这些 pod，因为磁盘现在位于不同的区中。如需更多信息，请参阅 Kubernetes 文档中的多个区限制。
重要要使用 GCP 运行负载均衡器服务，Compute Engine 虚拟机节点实例需要
ocp后缀： <openshift_gcp_prefix>ocp。例如，如果openshift_gcp_prefix参数的值设置为mycluster，则必须标记带有myclusterocp的节点。有关如何在 Compute Engine 虚拟机实例中添加网络标签的更多信息，请参阅添加和删除网络标签。重启 OpenShift Container Platform 主机服务：
master-restart api master-restart controllers systemctl restart atomic-openshift-node
# master-restart api # master-restart controllers # systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
要返回单区支持，将 multizone 值设置为 false，然后重新启动 master 和节点主机服务。
23.2.2.2. 为 GCE 手动配置节点主机
在所有节点主机上执行以下内容。
流程
编辑 适当的节点配置映射 并更新
kubeletArguments部分的内容：kubeletArguments: cloud-provider: - "gce" cloud-config: - "/etc/origin/cloudprovider/gce.conf"kubeletArguments: cloud-provider: - "gce" cloud-config: - "/etc/origin/cloudprovider/gce.conf"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要nodeName必须与 GCP 中的实例名称匹配，才能使云供应商集成正常工作。名称也必须与 RFC1123 兼容。重启所有节点上的 OpenShift Container Platform 服务。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
23.2.3. 为 GCP 配置 OpenShift Container Platform registry
Google Cloud Platform(GCP)提供对象存储，OpenShift Container Platform 可以使用 OpenShift Container Platform 使用 OpenShift Container Platform 容器镜像 registry 存储容器镜像。
如需更多信息，请参阅 GCP 文档中的 Cloud Storage。
先决条件
您必须在安装前创建存储桶来托管 registry 镜像。以下命令使用配置的服务帐户创建区域存储桶：
默认情况下，存储桶的数据会使用 Google 管理的密钥自动加密。要指定不同的密钥来加密数据，请参阅 GCP 中的数据加密选项。
如需更多信息，请参阅创建存储存储桶文档。
流程
配置 registry 的 Ansible 清单文件 以使用 Google Cloud Storage (GCS) 存储桶：
如需更多信息，请参阅 GCP 文档中的 Cloud Storage。
要使用 GCP 对象存储，请编辑 registry 的配置文件并挂载到 registry pod。
有关存储驱动程序配置文件的更多信息，请参阅 Google Cloud Storage Driver 文档。
流程
导出当前的 /etc/registry/config.yml 文件：
oc get secret registry-config \ -o jsonpath='{.data.config\.yml}' -n default | base64 -d \ >> config.yml.old$ oc get secret registry-config \ -o jsonpath='{.data.config\.yml}' -n default | base64 -d \ >> config.yml.oldCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从旧的 /etc/registry/config.yml 文件创建新配置文件：
cp config.yml.old config.yml
$ cp config.yml.old config.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑该文件以包含 GCP 参数。在 registry 配置文件的
storage部分指定存储桶和密钥文件：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除
registry-configsecret：oc delete secret registry-config -n default
$ oc delete secret registry-config -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重新创建 secret 来引用更新的配置文件：
oc create secret generic registry-config \ --from-file=config.yml -n default$ oc create secret generic registry-config \ --from-file=config.yml -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重新部署 registry 以读取更新的配置：
oc rollout latest docker-registry -n default
$ oc rollout latest docker-registry -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow
23.2.3.1.1. 验证 registry 是否使用 GCP 对象存储
验证 registry 是否使用 GCP 存储桶存储：
流程
使用 GCP 存储成功部署 registry 后，如果 registry 部署使用
emptydir而不是 GCP 存储桶存储，registrydeploymentconfig不会显示任何信息：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 共享 pod 生命周期的临时目录。
检查 /registry 挂载点是否为空。这是将使用卷 GCP 存储：
oc exec \ $(oc get pod -l deploymentconfig=docker-registry \ -o=jsonpath='{.items[0].metadata.name}') -i -t -- ls -l /registry$ oc exec \ $(oc get pod -l deploymentconfig=docker-registry \ -o=jsonpath='{.items[0].metadata.name}') -i -t -- ls -l /registry total 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow