配置集群

OpenShift Container Platform 可以从源代码构建 容器镜像，部署并管理它们的生命周期。为此，OpenShift Container Platform 提供了一个内部集成的容器镜像 registry，可在 OpenShift Container Platform 环境中部署以在本地管理镜像。

在初始安装完整 OpenShift Container Platform 集群期间，可能会在安装过程中自动部署 registry。如果没有，或者您要进一步自定义 registry 的配置，请参阅在现有集群中部署 registry。

虽然它可以部署为作为完整 OpenShift Container Platform 集群集成的一部分运行，但 OpenShift Container Platform registry 可以作为独立容器镜像 registry 单独安装。

要安装独立 registry，请遵循安装独立 Registry。此安装路径部署运行 registry 和专用 Web 控制台的一体化集群。

如果集成的 registry 之前在 OpenShift Container Platform 集群的初始安装过程中没有被自动部署，或者如果不再成功运行，您需要在现有集群中重新部署它，请参阅以下部分来了解部署新 registry 的选项。

您可以为内部和外部引用配置 registry 的主机名和端口。通过这样做，镜像流将为镜像提供基于主机名的推送和拉取规格，允许使用镜像与对 registry 服务 IP 的更改进行隔离，并有可能允许镜像流及其引用在集群中可移植。

要设置从集群内部引用 registry 的主机名，请在 master 配置文件的 imagePolicyConfig 部分中设置 internalRegistryHostname。外部主机名通过在同一位置设置 externalRegistryHostname 值来控制。

imagePolicyConfig:
  internalRegistryHostname: docker-registry.default.svc.cluster.local:5000
  externalRegistryHostname: docker-registry.mycompany.com

registry 本身必须使用相同的内部主机名值进行配置。这可以通过在 registry 署配置中设置 REGISTRY_OPENSHIFT_SERVER_ADDR 环境变量或设置 registry 配置的 OpenShift 部分中的值来完成。

要部署集成的容器镜像 registry，请以具有集群管理员特权的用户身份使用 oc adm registry 命令。例如：

$ oc adm registry --config=/etc/origin/master/admin.kubeconfig \1
    --service-account=registry \2
    --images='registry.redhat.io/openshift3/ose-${component}:${version}' 3

这将创建服务和部署配置，两者均称为 docker-registry。部署成功后，会使用类似于 docker-registry-1-cpty9 的名称创建 pod。

查看创建 registry 时可以指定的完整选项列表：

$ oc adm registry --help

--fs-group 的值需要是 registry 使用的 SCC 所允许的（通常为有限制的 SCC）。

使用 oc adm registry 命令将 registry 部署为带有 --daemonset 选项的 DaemonSet。

DaemonSet 可确保在创建节点时，节点包含指定 pod 的副本。删除节点时，会收集 pod。

如需有关 DaemonSet 的更多信息，请参阅使用 Daemonsets。

默认情况下，创建 registry 时没有设置计算资源请求或限值。对于生产环境，强烈建议更新 registry 的部署配置，以便为 registry 容器集设置资源请求和限值。否则，registry pod 将被视为 BestEffort pod。

有关配置请求和限制的更多信息，请参阅计算资源。

registry 存储容器镜像和元数据。如果您只是使用 registry 来部署 pod，它会使用一个在 pod 退出时销毁的临时卷。任何用户已构建或推送到 registry 的镜像都会消失。

本节列出了支持的 registry 存储驱动程序。如需更多信息，请参阅容器镜像 registry 文档。

以下列表包括在 registry 配置文件中需要配置的存储驱动程序：

支持常规 registry 存储配置选项。如需更多信息，请参阅容器镜像 registry 文档。

以下存储选项需要通过文件系统驱动程序配置：

$ oc set volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \
     --claim-name=<pvc_name> --overwrite

storage:
  cache:
    layerinfo: inmemory
  delete:
    enabled: true
  s3:
    accesskey: awsaccesskey 1
    secretkey: awssecretkey 2
    region: us-west-1
    regionendpoint: http://myobjects.local
    bucket: bucketname
    encrypt: true
    keyid: mykeyid
    secure: true
    v4auth: false
    chunksize: 5242880
    rootdirectory: /s3/object/name/prefix

$ oc adm registry --service-account=registry \
    --config=/etc/origin/master/admin.kubeconfig \
    --images='registry.redhat.io/openshift3/ose-${component}:${version}' \ 1
    --mount-host=<path>

$ sudo chown 1001:root <path>

OpenShift Container Platform 为集成的 registry 提供了一个基于 Web 的界面。此 registry 控制台是浏览和管理镜像的可选组件。它部署为作为容器集运行的无状态服务。

$ oc set env dc registry-console G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper

要查看容器镜像 registry 的日志，请使用带有部署配置的 oc logs 命令：

$ oc logs dc/docker-registry
2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown"
2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler"
2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002

标签和镜像元数据存储在 OpenShift Container Platform 中，但 registry 将层和签名数据存储在挂载到位于 /registry 的 registry 容器中的卷中。因为 oc exec 不在特权容器上工作，若要查看 registry 的内容，您必须手动 SSH 到 registry pod 的容器所在的节点，然后在容器本身上运行 docker exec ：

对于高级用途，您可以直接访问 registry 来调用 docker 命令。这可让您直接使用 docker push 或 docker pull 等操作从集成的 registry 中推送镜像或从中提取镜像。为此，您必须使用 docker login 命令登录 registry。您可以执行的操作取决于您的用户权限，如以下各节所述。

OpenShift Container Registry 为 Prometheus metrics 提供了一个端点。Prometheus是一个独立的开源系统监视和警报工具包。

metrics 可以通过registry端点的/extensions/v2/metrics路径获得。但是，必须先启用此路由；请参阅 Extended Registry Configuration 了解说明。

以下是指标查询的简单示例：

$ curl -s -u <user>:<secret> \ 1
    http://172.30.30.30:5000/extensions/v2/metrics | grep openshift | head -n 10

# HELP openshift_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which OpenShift was built.
# TYPE openshift_build_info gauge
openshift_build_info{gitCommit="67275e1",gitVersion="v3.6.0-alpha.1+67275e1-803",major="3",minor="6+"} 1
# HELP openshift_registry_request_duration_seconds Request latency summary in microseconds for each operation
# TYPE openshift_registry_request_duration_seconds summary
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.5"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.9"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.99"} 0
openshift_registry_request_duration_seconds_sum{name="test/origin-pod",operation="blobstore.create"} 0
openshift_registry_request_duration_seconds_count{name="test/origin-pod",operation="blobstore.create"} 5

访问指标的另一种方法是使用集群角色。您仍然需要启用端点，但不需要指定 <secret>。配置文件中与指标数据相关的部分应如下所示：

openshift:
  version: 1.0
  metrics:
    enabled: true
...

如果您还没有角色来访问指标，则必须创建一个集群角色：

$ cat <<EOF |
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-scraper
rules:
- apiGroups:
  - image.openshift.io
  resources:
  - registry/metrics
  verbs:
  - get
EOF
oc create -f -

要将此角色添加到用户，请运行以下命令：

$ oc adm policy add-cluster-role-to-user prometheus-scraper <username>

有关更高级查询和推荐的可视化工具，请参阅 上游 Prometheus 文档。

默认情况下，OpenShift Container Platform registry 在集群安装过程中是安全的，以便通过 TLS 提供流量。默认情况下还会创建一个 passthrough 路由，以将服务公开到外部。

如果出于任何原因您的 registry 没有被保护或公开，请参阅以下部分来了解如何手动操作。

手动保护 registry 以通过 TLS 提供流量：

您可以通过首先保护 registry，然后使用路由公开它，而不是从 OpenShift Container Platform 集群内部登录到 OpenShift Container Platform registry。您可以使用路由地址从集群以外登陆到 registry，并使用路由主机进行镜像的 tag 和 push 操作。

对于非生产环境的 OpenShift Container Platform，可以公开一个非安全的 registry，而不必通过安全 registry 来公开 registry。这允许您使用一个外部路由到 registry，而无需使用 SSL 证书。

公开一个非安全的 registry：

登录到非安全且公开的 registry 时，请确保在 docker login 命令中指定 registry。例如：

# docker login -e user@company.com \
    -u f83j5h6 \
    -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \
    <host>

OpenShift Container Platform 使用其服务 IP 地址来引用集成的 registry，因此如果您决定删除并重新创建 docker-registry 服务，您可以通过安排在新服务中重复使用旧 IP 地址来确保完全透明转换。如果无法避免新的 IP 地址，您可以通过只重启 master 来最小化集群中断。

# master-restart api
# master-restart controllers

这样可确保从缓存中清除包括旧 IP 地址的旧 registry URL。

您可以使用 /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 搜索列表：

您可以为内部和外部引用配置 registry 的主机名和端口。通过这样做，镜像流将为镜像提供基于主机名的推送和拉取规格，允许使用镜像与对 registry 服务 IP 的更改进行隔离，并有可能允许镜像流及其引用在集群中可移植。

要设置从集群内部引用 registry 的主机名，请在 master 配置文件的 imagePolicyConfig 部分中设置 internalRegistryHostname。外部主机名通过在同一位置设置 externalRegistryHostname 值来控制。

imagePolicyConfig:
  internalRegistryHostname: docker-registry.default.svc.cluster.local:5000
  externalRegistryHostname: docker-registry.mycompany.com

registry 本身必须使用相同的内部主机名值进行配置。这可以通过在 registry 署配置中设置 REGISTRY_OPENSHIFT_SERVER_ADDR 环境变量或设置 registry 配置的 OpenShift 部分中的值来完成。

您可以使用自己的自定义配置覆盖集成 registry 的默认配置，默认覆盖正在运行的 registry 容器中的 /config.yml 中的默认配置。

要启用对 registry 配置文件的管理，并使用 ConfigMap 部署更新的配置：

这可以作为迭代过程执行，从而实现所需的配置。例如，在故障排除期间，可临时更新配置以将其置于 debug 模式。

更新现有配置：

上游 docker distribution 库中有许多配置选项。并非所有配置选项都受到支持或启用。覆盖 registry 配置时，请使用本节作为参考。

log:
  level: debug
  formatter: text
  fields:
    service: registry
    environment: staging

storage:
  delete:
    enabled: true 1
  redirect:
    disable: false
  cache:
    blobdescriptor: inmemory
  maintenance:
    uploadpurging:
      enabled: true
      age: 168h
      interval: 24h
      dryrun: false
    readonly:
      enabled: false

auth:
  openshift:
    realm: openshift

middleware:
  registry:
    - name: openshift 1
  repository:
    - name: openshift 2
      options:
        acceptschema2: true 3
        pullthrough: true 4
        mirrorpullthrough: true 5
        enforcequota: false 6
        projectcachettl: 1m 7
        blobrepositorycachettl: 10m 8
  storage:
    - name: openshift 9

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true
  s3:
    accesskey: BJKMSZBRESWJQXRWMAEQ
    secretkey: 5ah5I91SNXbeoUXXDasFtadRqOdy62JzlnOW1goS
    bucket: docker.myregistry.com
    region: eu-west-3
    regionendpoint: https://s3.eu-west-3.amazonaws.com
 auth:
  openshift:
    realm: openshift
middleware:
  registry:
    - name: openshift
  repository:
    - name: openshift
  storage:
    - name: openshift

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true
  s3: 1
    accesskey: BJKMSZBRESWJQXRWMAEQ
    secretkey: 5ah5I91SNXbeoUXXDasFtadRqOdy62JzlnOW1goS
    region: us-east-1
    bucket: docker.myregistry.com
auth:
  openshift:
    realm: openshift
middleware:
  registry:
    - name: openshift
  repository:
    - name: openshift
  storage:
    - name: cloudfront 2
      options:
        baseurl: https://jrpbyn0k5k88bi.cloudfront.net/ 3
        privatekey: /etc/docker/cloudfront-ABCEDFGHIJKLMNOPQRST.pem 4
        keypairid: ABCEDFGHIJKLMNOPQRST 5
    - name: openshift

middleware:
  repository:
    - name: openshift
      options:
        acceptschema2: true 1
        pullthrough: true 2
        mirrorpullthrough: true 3
        enforcequota: false 4
        projectcachettl: 1m 5
        blobrepositorycachettl: 10m 6

$ 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:
  version: 1.0 1
  server:
    addr: docker-registry.default.svc 2
  metrics:
    enabled: false 3
    secret: <secret> 4
  requests:
    read:
      maxrunning: 10 5
      maxinqueue: 10 6
      maxwaitinqueue 2m 7
    write:
      maxrunning: 10 8
      maxinqueue: 10 9
      maxwaitinqueue 2m 10

http:
  addr: :5000
  tls:
    certificate: /etc/secrets/registry.crt
    key: /etc/secrets/registry.key

notifications:
  endpoints:
    - name: registry
      disabled: false
      url: https://url:port/path
      headers:
        Accept:
          - text/plain
      timeout: 500
      threshold: 5
      backoff: 1000

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: "" 1
openshift:
  version: 1.0
  cache:
    disabled: true 2
    blobrepositoryttl: 10m

以下是部署或使用集成 registry 时已知的问题。

本地 docker-registry 部署会增加负载。默认情况下，它现在缓存 registry.redhat.io 的内容。来自为 STI 构建的 registry.redhat.io 的镜像现在存储在本地 registry 中。尝试拉取它们的结果从本地 docker-registry 中拉取。因此，在有些情况下，并发构建可能会造成拉取超时，构建可能会失败。要缓解此问题，请将 docker-registry 部署扩展到多个副本。检查构建器容器集日志中的超时。

当将扩展的 registry 与共享 NFS 卷搭配使用时，您可能会在推送镜像的过程中看到以下错误之一：

当 Docker 尝试推送镜像时，内部 registry 服务将返回这些错误。其原因源自于跨节点的文件属性同步。使用默认循环负载平衡配置推送镜像时可能会出现的错误，如 NFS 客户端缓存、网络延迟和层大小等因素。

您可以执行以下步骤来最大程度减少此类故障的可能性：

当拉取镜像推送到不同于从中拉取的镜像流时，会发生此错误。这是因为将构建的镜像重新标记到任意镜像流中：

$ oc tag srcimagestream:latest anyproject/pullimagestream:latest

internal.registry.url:5000/anyproject/pullimagestream:latest

在手动 Docker 拉取过程中，这会导致类似的错误：

Error: image anyproject/pullimagestream:latest not found

为防止这种情况，请完全避免标记内部管理的镜像，或者 手动 将构建的镜像重新推送到所需的命名空间。

当 registry 在 S3 存储后端上运行时，会报告问题。推送到容器镜像 registry 有时会失败，并显示以下错误：

Received unexpected HTTP status: 500 Internal Server Error

要进行调试，您需要 查看 registry 日志。在这里，查看推送失败时出现的类似的错误消息：

time="2016-03-30T15:01:21.22287816-04:00" level=error msg="unknown error completing upload: driver.Error{DriverName:\"s3\", Enclosed:(*url.Error)(0xc20901cea0)}" http.request.method=PUT
...
time="2016-03-30T15:01:21.493067808-04:00" level=error msg="response completed with error" err.code=UNKNOWN err.detail="s3: Put https://s3.amazonaws.com/oso-tsi-docker/registry/docker/registry/v2/blobs/sha256/ab/abe5af443833d60cf672e2ac57589410dddec060ed725d3e676f1865af63d2e2/data: EOF" err.message="unknown error" http.request.method=PUT
...
time="2016-04-02T07:01:46.056520049-04:00" level=error msg="error putting into main store: s3: The request signature we calculated does not match the signature you provided. Check your key and signing method." http.request.method=PUT
atest

如果您看到此类错误，请联系您的 Amazon S3 支持。您所在地区或您的特定存储桶可能有问题。

如果您在修剪镜像时遇到以下错误：

BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blob

您的 registry 日志 包含以下信息：

error deleting blob \"sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c\": operation unsupported

这意味着您的 自定义配置文件 缺少 storage 部分中的强制条目，即 storage:delete:enabled 设置为 true。添加它们，重新部署 registry，再重复您的镜像修剪操作。

可以通过多种方式使 流量进入集群。最常见的方法是使用 OpenShift Container Platform router 作为 OpenShift Container Platform 安装中 services 的外部流量入口点。

OpenShift Container Platform 提供和支持以下路由器插件：

在部署 OpenShift Container Platform 集群前，您必须有一个路由器的服务帐户，该帐户会在集群安装过程中自动创建。此服务帐户具有 安全性上下文约束 (SCC)的权限，允许它指定主机端口。

$ oc adm policy add-cluster-role-to-user \
    cluster-reader \
    system:serviceaccount:default:router

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 --dry-run --service-account=router 1

如果路由器不存在，请运行以下命令来创建路由器：

$ 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 adm router --dry-run --service-account=router

$ oc adm router --dry-run -o yaml --service-account=router

$ oc adm router --extended-logging=true

以下示例是使用 --extended-logging=true 的路由器的配置：

$ oc get pod router-1-xhdb9 -o yaml
apiVersion: v1
kind: Pod
spec:
  containers:
  - env:

    ....

    - name: ROUTER_SYSLOG_ADDRESS 1
      value: /var/lib/rsyslog/rsyslog.sock

    ....

 - command: 2
   - /sbin/rsyslogd
   - -n
   - -i
   - /tmp/rsyslog.pid
   - -f
   - /etc/rsyslog/rsyslog.conf
   image: registry.redhat.io/openshift3/ose-haproxy-router:v3.11.188
   imagePullPolicy: IfNotPresent
   name: syslog

使用以下命令查看 HAProxy 日志：

$ oc set env dc/test-router ROUTER_LOG_LEVEL=info 1
$ oc logs -f <pod-name> -c syslog 2

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

$ 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

在集群安装过程中，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 region-west -o yaml --images=myrepo/somerouter:mytag \
    --service-account=router

使用 ROUTE_LABELS 环境变量，您可以过滤路由，使其仅供特定路由器使用。

例如，如果您有多个路由器和 100 个路由，您可以将标签附加到路由，以便一部分标签由一个路由器处理，而其余则由另一个路由器处理。

创建路由器时，--max-connections= 选项会设置所需的限制：

$ oc adm router --max-connections=10000   ....

编辑路由器部署配置中的 ROUTER_MAX_CONNECTIONS 环境变量，以更改值。路由器容器集使用新值重启。如果 ROUTER_MAX_CONNECTIONS 不存在，则使用默认值 20000。

HAProxy strict-sni 可以通过路由器部署配置中的 ROUTER_STRICT_SNI 环境变量来控制。也可以使用 --strict-sni 命令行选项创建路由器时设置它。

$ oc adm router --strict-sni

在创建路由器时使用 --ciphers 选项设置路由器密码套件 ：

$ oc adm router --ciphers=modern   ....

值包括：modern, intermediate, 或 old，intermediate 为默认值。或者，可以提供一组":"分隔的密码。密码必须来自以下集合：

$ openssl ciphers

或者，将 ROUTER_CIPHERS 环境变量用于现有路由器。

可以使用 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   ....

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

--mutual-tls-auth-filter 值可用于根据证书主题进行精细的访问控制。该值是一个正则表达式，用于匹配证书的主题。

使用 --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  \
     ....

启用 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 格式的客户端证书。

您可以使用 IP 故障切换在 OpenShift Container Platform 集群中设置高可用性路由器。此设置在不同节点上有多个副本，因此如果当前副本失败，故障切换软件可以切换到另一个副本。

您可以通过设置环境变量 ROUTER_SERVICE_HTTP_PORT 和 ROUTER_SERVICE_HTTPS_PORT 来自定义模板路由器绑定的服务端口。这可以通过创建模板路由器，然后编辑其部署配置来完成。

以下示例创建带有 0 个副本的路由器部署，并自定义路由器服务 HTTP 和 HTTPS 端口，然后相应地将其扩展（到 1 个副本）。

$ oc adm router --replicas=0 --ports='10080:10080,10443:10443' 1
$ oc set env dc/router ROUTER_SERVICE_HTTP_PORT=10080  \
                   ROUTER_SERVICE_HTTPS_PORT=10443
$ oc scale dc/router --replicas=1

以下是使用 iptables 打开自定义路由器服务端口的示例：

$ iptables -A OS_FIREWALL_ALLOW -p tcp --dport 10080 -j ACCEPT
$ iptables -A OS_FIREWALL_ALLOW -p tcp --dport 10443 -j ACCEPT

管理员可以创建具有相同定义的多个路由器，为同一组路由提供服务。每个路由器将位于不同的节点，并且具有不同的 IP 地址。网络管理员需要获取到每个节点所需的流量。

可以分组多个路由器来在集群中分发路由负载，并将租户单独的租户分发到不同的路由器或 分片。组中的每个路由器或分片都根据路由器中的选择器接受路由。管理员可以使用 ROUTE_LABELS 在整个集群中创建分片。用户可以使用 NAMESPACE_LABELS 在命名空间（项目）上创建分片。

将特定路由器部署到特定的节点上需要两个步骤：

路由器分片使用 NAMESPACE_LABELS 和 ROUTE_LABELS 来过滤路由器命名空间和路由。这可让您通过多个路由器部署分发路由的子集。通过使用非覆盖的子集，您可以有效地对一组路由进行分区。或者，您可以定义由重叠的路由子集组成的分片。

默认情况下，路由器从所有项目（命名空间）中选择所有路由。分片涉及将标签添加到路由或命名空间，以及向路由器添加标签选择器。每个路由器分片都由一组特定标签选择器或属于由特定标签选择器选择的命名空间来选择的路由组成。

路由器划分和 DNS

由于需要外部 DNS 服务器将请求路由到所需的分片，因此管理员负责为项目中的每个路由器创建单独的 DNS 条目。路由器不会将未知路由转发到另一个路由器。

考虑以下示例：

单独的 DNS 条目必须将 *.foo.com 解析为托管 Router A 和 *.example.com 的节点：

路由器分片示例

本节论述了使用命名空间和路由标签进行路由器分片。

图 3.1. 路由器划分基于命名空间标签

添加此标签使路由在路由器中可用。

sla=high       geo=east     hw=modest     dept=finance
sla=medium     geo=west     hw=strong     dept=dev
sla=low                                   dept=ops

#!/bin/bash
# Usage: mkshard ID SELECTION-EXPRESSION
id=$1
sel="$2"
router=router-shard-$id           1
oc adm router $router --replicas=0  2
dc=dc/router-shard-$id            3
oc set env   $dc ROUTE_LABELS="$sel"  4
oc scale $dc --replicas=3         5

#!/bin/bash
# Usage: modshard ID SELECTION-EXPRESSION...
id=$1
shift
router=router-shard-$id       1
dc=dc/$router                 2
oc scale $dc --replicas=0     3
oc set env   $dc "$@"             4
oc scale $dc --replicas=3     5

$ modshard 3 ROUTE_LABELS='dept in (dev, ops)'

$ modshard 3 ROUTE_LABELS='dept != finance'

$ modshard 3 ROUTE_LABELS='hw=strong,type=dynamic,geo=west'

$ modshard 3 NAMESPACE_LABELS='frequency=weekly'

$ modshard 3 \
    NAMESPACE_LABELS='frequency=weekly' \
    ROUTE_LABELS='sla=low'

在公开服务时，用户可以使用来自外部用户用于访问应用的 DNS 名称相同的路由。外部网络的网络管理员必须确保主机名解析为已接受该路由的路由器的名称。用户可以使用指向此主机名的 CNAME 设置 DNS。但是，用户可能不知道路由器的主机名。当不知道时，集群管理员可以提供它。

在创建路由器时，集群管理员可以使用 --router-canonical-hostname 选项和路由器的规范主机名。例如：

# oc adm router myrouter --router-canonical-hostname="rtr.example.com"

这会在包含路由器主机名的路由器部署配置中创建 ROUTER_CANONICAL_HOSTNAME 环境变量。

对于已存在的路由器，集群管理员可以编辑路由器的部署配置，并添加 ROUTER_CANONICAL_HOSTNAME 环境变量：

spec:
  template:
    spec:
      containers:
        - env:
          - name: ROUTER_CANONICAL_HOSTNAME
            value: rtr.example.com

ROUTER_CANONICAL_HOSTNAME 值显示在接受该路由的所有路由器的路由状态中。每次重新载入路由器时，路由状态都会刷新。

当用户创建路由时，所有活跃的路由器都会评估路由，如果满足条件，则接受路由。当定义 ROUTER_CANONICAL_HOSTNAME 环境变量的路由器接受该路由时，路由器会将该值放在路由状态的 routerCanonicalHostname 字段中。用户可以检查路由状态，以确定路由器是否允许该路由，从列表中选择路由器，再查找要传给网络管理员的路由器的主机名。

status:
  ingress:
    conditions:
      lastTransitionTime: 2016-12-07T15:20:57Z
      status: "True"
      type: Admitted
      host: hello.in.mycloud.com
      routerCanonicalHostname: rtr.example.com
      routerName: myrouter
      wildcardPolicy: None

在可用时 oc describe 会包括主机名：

$ 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 的任何流量到达用户的应用。

您可以通过修改 master 配置文件（默认为 /etc/origin/master/master-config.yaml 文件）来自定义用作环境默认路由子域的后缀。没有指定主机名的路由会有一个使用该默认路由子域生成的路由。

以下示例演示了如何将配置的后缀设置为 v3.openshift.test ：

routingConfig:
  subdomain: v3.openshift.test

运行上述配置的 OpenShift Container Platform master 时，对于名为 no-route-hostname 的示例路由（没有主机名添加到命名空间 mynamespace）生成的主机名将是：

no-route-hostname-mynamespace.v3.openshift.test

如果管理员希望限制到特定路由子域的所有路由，他们可以将 --force-subdomain 选项传递给 oc adm router 命令。这会强制路由器覆盖路由中指定的任何主机名，并根据提供给 --force-subdomain 选项的模板生成一个主机名。

以下示例运行路由器，它使用自定义子域模板 ${name}-${namespace}.apps.example.com 来覆盖路由主机名。

$ oc adm router --force-subdomain='${name}-${namespace}.apps.example.com'

不包含证书的 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

路由器预期证书和密钥在单个文件中采用 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

手动重新部署路由器证书：

目前，不支持密码保护的密钥文件。启动后，HAProxy 会提示输入密码，且无法自动执行此过程。要从密钥文件中删除密码短语，您可以运行以下命令：

# openssl rsa -in <passwordProtectedKey.key> -out <new.key>

以下是如何在流量代理到目的地之前使用发生在路由器上发生 TLS 终止的安全边缘终止路由的示例：安全边缘终止路由指定 TLS 证书和密钥信息。TLS 证书由路由器前端提供。

首先，启动一个路由器实例：

# oc adm router --replicas=1 --service-account=router

接下来，为我们边缘安全路由创建私钥、csr 和证书。有关如何执行此操作的说明将特定于您的证书颁发机构和提供商。有关名为 www.example.test 的域的简单自签名证书，请参考以下示例：

# sudo openssl genrsa -out example-test.key 2048
#
# sudo openssl req -new -key example-test.key -out example-test.csr  \
  -subj "/C=US/ST=CA/L=Mountain View/O=OS3/OU=Eng/CN=www.example.test"
#
# sudo openssl x509 -req -days 366 -in example-test.csr  \
      -signkey example-test.key -out 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

看一下其定义。

$ oc get route/my-service -o yaml
apiVersion: v1
kind: Route
metadata:
  name:  my-service
spec:
  host: www.example.test
  to:
    kind: Service
    name: my-service
  tls:
    termination: edge
    key: |
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

确保 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/

HAProxy 路由器支持通配符路由，这通过将 ROUTER_ALLOW_WILDCARD_ROUTES 环境变量设置为 true 来启用。具有 Subdomain 通配符策略且通过路由器准入检查的任何路由都将由 HAProxy 路由器提供服务。然后，HAProxy 路由器根据路由的通配符策略公开相关的服务（用于路由）。

$ oc adm router --replicas=0 ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true
$ oc scale dc/router --replicas=1

了解如何为通配符路由配置 Web 控制台。

安全边缘终止路由指定 TLS 证书和密钥信息。TLS 证书由与子域(*.example.org)匹配的所有主机的路由器前端提供。

对于允许通配符路由的路由器（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 中的主机进行非覆盖声明。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test
$ oc expose service myservice --hostname=bname.example.test

$ oc project ns2
$ oc expose service anotherservice --hostname=second.example.test
$ oc expose service anotherservice --hostname=cname.example.test

$ oc project otherns
$ oc expose service thirdservice --hostname=emmy.example.test
$ oc expose service thirdservice --hostname=webby.example.test

在以下示例中，允许通配符路由的路由器不允许 owner.example.test 或 aname.example.test 的声明成功，因为拥有的命名空间是 ns1。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test

$ oc project ns2
$ oc expose service secondservice --hostname=bname.example.test
$ oc expose service secondservice --hostname=cname.example.test

$ # Router will not allow this claim with a different path name `/p1` as
$ # namespace `ns1` has an older route claiming host `aname.example.test`.
$ oc expose service secondservice --hostname=aname.example.test --path="/p1"

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `owner.example.test`.
$ oc expose service secondservice --hostname=owner.example.test

$ oc project otherns

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `aname.example.test`.
$ oc expose service thirdservice --hostname=aname.example.test

在以下示例中，允许通配符路由的路由器将允许 '\*.example.test 声明成功，因为拥有的命名空间是 ns1，通配符路由属于同一命名空间。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will allow this claim.

在以下示例中，允许通配符路由的路由器不允许 '\*.example.test 声明成功，因为拥有的命名空间是 ns1，并且通配符路由属于另一个命名空间 cyclone。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Switch to a different namespace/project.
$ oc project cyclone

$ # Reusing the route.yaml from a prior example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will deny (_NOT_ allow) this claim.

同样，当具有通配符路由的命名空间声明子域后，只有该命名空间中的路由才能声明同一子域中的任何主机。

在以下示例中，当命名空间 ns1 中带有通配符路由声明子域 example.test 的路由之后，只有命名空间 ns1 中的路由可以声明同一子域中的任何主机。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service otherservice --hostname=other.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `other.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for deux.example.test
$ oc expose service mysecondservice --hostname=deux.example.test

$ # namespace `ns1` is allowed to claim for deux.example.test with path /p1
$ oc expose service mythirdservice --hostname=deux.example.test --path="/p1"

$ oc project otherns

$ # namespace `otherns` is not allowed to claim for deux.example.test
$ # with a different path '/otherpath'
$ oc expose service otherservice --hostname=deux.example.test --path="/otherpath"

$ # namespace `otherns` is not allowed to claim for owner.example.test
$ oc expose service yetanotherservice --hostname=owner.example.test

$ # namespace `otherns` is not allowed to claim for unclaimed.example.test
$ oc expose service yetanotherservice --hostname=unclaimed.example.test

在以下示例中，显示了不同的场景，其中删除所有者路由并在命名空间内和跨命名空间传递所有权。虽然命名空间 ns1 中存在声明主机 eldest.example.test 的路由，但该命名空间中的通配符路由可以声明子域 example.test。当删除主机 eldest.example.test 的路由时，下一个最旧的路由 senior.example.test 将成为最旧的路由，不会影响任何其他路由。删除主机 senior.example.test 的路由后，下一个最旧的路由 junior.example.test 将成为最旧路由并阻止通配符路由。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=eldest.example.test
$ oc expose service seniorservice --hostname=senior.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service juniorservice --hostname=junior.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `junior.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for dos.example.test
$ oc expose service mysecondservice --hostname=dos.example.test

$ # Delete route for host `eldest.example.test`, the next oldest route is
$ # the one claiming `senior.example.test`, so route claims are unaffacted.
$ oc delete route myservice

$ # Delete route for host `senior.example.test`, the next oldest route is
$ # the one claiming `junior.example.test` in another namespace, so claims
$ # for a wildcard route would be affected. The route for the host
$ # `dos.example.test` would be unaffected as there are no other wildcard
$ # claimants blocking it.
$ oc delete route seniorservice

OpenShift Container Platform 路由器在容器内运行，默认的行为是使用主机的网络堆栈（即，路由器容器运行的节点）。这个默认行为有利于性能，因为来自远程客户端的网络流量不需要通过用户空间获取多个跃点来访问目标服务和容器。

另外，这个默认行为可让路由器获取远程连接的实际源 IP 地址，而不是获取节点的 IP 地址。这可用于定义基于原始 IP、支持粘性会话和监控流量以及其他用途的入口规则。

此主机网络行为由 --host-network 路由器命令行选项控制，默认行为等同于使用 --host-network=true。如果要使用容器网络堆栈运行路由器，请在创建路由器时使用 --host-network=false 选项。例如：

$ oc adm router --service-account=router --host-network=false

在内部，这意味着路由器容器必须发布 80 和 443 端口，以便外部网络与路由器通信。

您可以配置 HAProxy 路由器来支持动态配置管理器。

动态配置管理器带来某些类型的在线路由，无需 HAProxy 重新加载停机时间。它处理任何路由和端点生命周期事件，如路由和端点附加 |deletion|update。

通过将 ROUTER_HAPROXY_CONFIG_MANAGER 环境变量设置为 true 来启用动态配置管理器：

$ oc set env dc/<router_name> ROUTER_HAPROXY_CONFIG_MANAGER='true'

如果动态配置管理器无法动态配置 HAProxy，它会重写配置并重新加载 HAProxy 进程。例如，如果新路由包含自定义注解，如自定义超时，或者路由需要自定义 TLS 配置。

动态配置内部使用 HAProxy 套接字和配置 API，以及预分配的路由和后端服务器池。预分配的路由池使用路由蓝图创建。默认蓝图集支持不安全的路由、边缘安全路由，无需任何自定义 TLS 配置和直通路由。

以下流程假定您已创建了三个路由对象：reencrypt-blueprint, annotated-edge-blueprint, 和 annotated-unsecured-blueprint。如需不同路由类型对象的示例，请参阅 Route Types。

HAProxy 路由器指标 默认以 Prometheus 格式 公开或发布，供外部指标收集和聚合系统（如 Prometheus、statsd）使用。指标数据也可直接从 HAProxy 路由器 以自己的 HTML 格式获取，以便在浏览器或 CSV 下载中查看。这些指标包括 HAProxy 原生指标和一些控制器指标。

当您使用以下命令创建路由器时，OpenShift Container Platform 以 Prometheus 格式在 stats 端口（默认为 1936）上提供指标数据。

$ oc adm router --service-account=router

在具有大量路由的 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

当出现这个问题时，oc 命令可能会因为以下错误开始失败：

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

如果数字开始接近 net.ipv4.neigh.default.gc_thresh3 阈值，则增加值。运行以下命令来获取当前值：

# sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 128
# sysctl net.ipv4.neigh.default.gc_thresh2
net.ipv4.neigh.default.gc_thresh2 = 512
# sysctl net.ipv4.neigh.default.gc_thresh3
net.ipv4.neigh.default.gc_thresh3 = 1024

以下 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

要使这些设置永久生效，请查看本文档。

向默认 HAProxy 路由器镜像添加 超时 http-request，以防止部署遭受分布式拒绝服务（例如，slowloris）攻击：

# and the haproxy stats socket is available at /var/run/haproxy.stats
global
  stats socket ./haproxy.stats level admin

defaults
  option http-server-close
  mode http
  timeout http-request 5s
  timeout connect 5s 1
  timeout server 10s
  timeout client 30s

另外，当设置环境变量 ROUTER_SLOWLORIS_TIMEOUT 时，它会限制客户端发送整个 HTTP 请求所需的时间。否则，HAProxy 将关闭连接。

通过设置 环境变量，可以将信息捕获为路由器部署配置的一部分，不需要手动修改模板，而手动添加 HAProxy 设置要求您重新构建路由器 Pod 和维护路由器模板文件。

使用注解在 HAProxy 模板路由器中实施基本的 DDoS 保护，包括限制以下功能：

这些是在每个路由上启用的，因为应用可能有完全不同的流量模式。

使用 --threads 标志启用线程处理。此标志指定 HAProxy 路由器将使用的线程数量。

默认 HAProxy 路由器旨在满足大多数用户的需求。但是，它不会公开 HAProxy 的所有功能。因此，用户可能需要根据自己的需求修改路由器。

您可能需要在应用后端内实施新功能，或修改当前的操作。router 插件提供了进行此自定义所需的所有功能。

路由器容器集使用模板文件来创建所需的 HAProxy 配置文件。模板文件是 golang 模板。在处理模板时，路由器可以访问 OpenShift Container Platform 信息，包括路由器的部署配置、接受路由集和一些帮助程序功能。

当路由器 pod 启动时，并且每次重新加载时，它会创建一个 HAProxy 配置文件，然后启动 HAProxy。HAProxy 配置手册 描述了 HAProxy 的所有功能以及如何构建有效的配置文件。

configMap 可用于添加新模板到路由器 pod。通过这种方法，修改路由器部署配置，将 configMap 挂载为路由器 Pod 中的卷。TEMPLATE_FILE 环境变量设置为路由器 Pod 中模板文件的完整路径名称。

或者，您也可以构建自定义路由器镜像，并在部署部分或所有路由器时使用它。不需要所有路由器来运行同一镜像。为此，请修改 haproxy-template.config 文件，再重新构建 路由器 镜像。新镜像推送到集群的 Docker 存储库，路由器的部署配置 image: 字段则使用新名称更新。更新集群时，需要重新构建并推送镜像。

在这两种情况下，路由器容器集都以模板文件开头。

HAProxy 模板文件非常大且复杂。对于某些更改，修改现有模板可能比编写完整的替换版本更简单。您可以通过在 master 上运行并引用路由器 pod，从正在运行的路由器获取 haproxy-config.template 文件：

# 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

镜像名称来自容器镜像。

将此内容保存到文件中，以用作自定义模板的基础。保存的 haproxy.config 显示实际运行的内容。

您可以使用 ConfigMap 来自定义路由器实例，而无需重新构建路由器镜像。可以修改 haproxy-config.template、reload-haproxy 和其他脚本，以及创建和修改路由器环境变量。

以下示例自定义可在高可用性路由设置中使用，以使用在对等点间同步的粘滞表。

添加 Peer 部分

要在对等点间同步粘滞位，您必须在 HAProxy 配置中定义对等部分。本节决定了 HAProxy 如何识别并连接到同级服务器。插件在 .PeerEndpoints 变量下向模板提供数据，以便您可以轻松地识别路由器服务的成员。您可以通过添加以下内容，将 peer 部分添加到路由器镜像中的 haproxy-config.template 文件中：

{{ if (len .PeerEndpoints) gt 0 }}
peers openshift_peers
  {{ range $endpointID, $endpoint := .PeerEndpoints }}
    peer {{$endpoint.TargetName}} {{$endpoint.IP}}:1937
  {{ end }}
{{ end }}

更改重新加载脚本

使用粘滞位时，您可以选择告知 HAProxy 在 peer 部分中应考虑本地主机的名称。在创建端点时，插件会尝试将 TargetName 设置为端点的 TargetRef.Name 的值。如果没有设置 TargetRef，它会将 TargetName 设置为 IP 地址。TargetRef.Name 与 Kubernetes 主机名对应，因此您可以将 -L 选项添加到 reload-haproxy 脚本中，以标识 peer 部分中的本地主机。

peer_name=$HOSTNAME 1

if [ -n "$old_pid" ]; then
  /usr/sbin/haproxy -f $config_file -p $pid_file -L $peer_name -sf $old_pid
else
  /usr/sbin/haproxy -f $config_file -p $pid_file -L $peer_name
fi

修改后端

最后，若要在后端使用 stick-tables，您可以修改 HAProxy 配置以使用 stick-tables 和 peer 设置。以下是将 TCP 连接的现有后端更改为使用 stick-table 的示例：

            {{ if eq $cfg.TLSTermination "passthrough" }}
backend be_tcp_{{$cfgIdx}}
  balance leastconn
  timeout check 5000ms
  stick-table type ip size 1m expire 5m{{ if (len $.PeerEndpoints) gt 0 }} peers openshift_peers {{ end }}
  stick on src
                {{ range $endpointID, $endpoint := $serviceUnit.EndpointTable }}
  server {{$endpointID}} {{$endpoint.IP}}:{{$endpoint.Port}} check inter 5000ms
                {{ end }}
            {{ end }}

在修改后，您可以重建路由器。

若要重建路由器，您需要复制正在运行的路由器上存在的多个文件。创建一个工作目录并从路由器复制文件：

# mkdir - myrouter/conf
# cd myrouter
# 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 > conf/haproxy-config.template
# oc exec router-2-40fc3 cat error-page-503.http > conf/error-page-503.http
# oc exec router-2-40fc3 cat default_pub_keys.pem > conf/default_pub_keys.pem
# oc exec router-2-40fc3 cat ../Dockerfile > Dockerfile
# oc exec router-2-40fc3 cat ../reload-haproxy > reload-haproxy

您可以编辑或替换其中任何一个文件。但是，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 1
# docker push 172.30.243.98:5000/openshift/origin-haproxy-router-pc:latest 2

要使用新路由器，请通过更改 image: 字符串或将 --images=<repo>/<image>:<tag> 标志添加到 oc adm router 命令来编辑路由器部署配置。

调试更改时，设置 imagePullPolicy:Always 在部署配置中，强制在每次 pod 创建时拉取镜像。调试完成后，您可以将其改回到 imagePullPolicy:IfNotPresent 以避免每次 pod 启动时都拉取。

默认情况下，HAProxy 路由器要求进入到不安全、边缘和重新加密路由的连接才能使用 HTTP。但是，您可以使用 PROXY 协议 将路由器配置为预期传入请求。本节论述了如何将 HAProxy 路由器和外部负载均衡器配置为使用 PROXY 协议。

当代理服务器或负载平衡器等中间服务转发 HTTP 请求时，它会将连接的源地址附加到请求的"Forwarded"标头，从而将此信息提供给后续请求，以及最终将请求转发到的后端服务。但是，如果连接被加密，则无法修改"Forwarded"标头。在这种情况下，HTTP 标头无法在转发请求时准确传达原始源地址。

为了解决这个问题，一些负载均衡器使用 PROXY 协议封装 HTTP 请求，作为只转发 HTTP 的替代选择。封装使负载平衡器能够在不修改转发请求本身的情况下向请求添加信息。特别是，这意味着负载均衡器即使在转发加密的连接时也能通信源地址。

HAProxy 路由器可以配置为接受 PROXY 协议并解封 HTTP 请求。由于路由器终止对边缘和再加密路由的加密，因此路由器随后可以更新请求中的 "Forwarded" HTTP 标头（及相关的 HTTP 标头），附加使用 PROXY 协议通信的任何源地址。

默认情况下，HAProxy 路由器不使用 PROXY 协议。可以使用 ROUTER_USE_PROXY_PROTOCOL 环境变量配置路由器，以预期传入连接的 PROXY 协议：

$ oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=true

将变量设置为 true 或 TRUE 以外的任何值，以禁用 PROXY 协议：

$ 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 实例上运行的路由器。

$ aws elb describe-load-balancers --load-balancer-name "$lb" |
    jq '.LoadBalancerDescriptions| [.[]|.ListenerDescriptions]'
[
  [
    {
      "Listener": {
        "InstancePort": 80,
        "LoadBalancerPort": 80,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": ["infra-lb-ProxyProtocol-policy"] 1
    },
    {
      "Listener": {
        "InstancePort": 443,
        "LoadBalancerPort": 443,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": ["infra-lb-ProxyProtocol-policy"] 2
    },
    {
      "Listener": {
        "InstancePort": 5000,
        "LoadBalancerPort": 5000,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": [] 3
    }
  ]
]

或者，如果您已经配置了 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 describe-load-balancers --load-balancer-name "$lb" |
   jq '[.LoadBalancerDescriptions[]|.ListenerDescriptions]'
[
  [
    {
      "Listener": {
        "InstancePort": 443,
        "LoadBalancerPort": 443,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    },
    {
      "Listener": {
        "InstancePort": 5000,
        "LoadBalancerPort": 5000,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    },
    {
      "Listener": {
        "InstancePort": 80,
        "LoadBalancerPort": 80,
        "Protocol": "TCP", 1
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    }
  ]
]

然后，创建一个负载均衡器策略，并将其添加到 ELB 中，如上一步第 5 步所述。

OpenShift Container Platform 安装程序包括 Ansible 角色 openshift-management， 以及用于在 OpenShift Container Platform 上部署 Red Hat CloudForms 4.6（CloudForms Management Engine 5.9 或 CFME）的 playbook。

在 OpenShift Container Platform 上部署 Red Hat CloudForms 时，需要做出两个主要决策：

对于第一个决定，您可以使用两种方式之一部署 Red Hat CloudForms，具体取决于 Red Hat CloudForms 使用的 PostgreSQL 数据库的位置：

对于第二个决定，openshift-management 角色提供了覆盖许多默认部署参数的自定义选项。这包括以下存储类选项来支持 PV：

本指南的主题包括：在 OpenShift Container Platform 上运行 Red Hat CloudForms 的要求、可用配置变量的说明，以及在初始 OpenShift Container Platform 安装期间或置备集群之后运行安装程序的说明。

以下小节描述了 Ansible 清单文件中可能使用的角色变量，用于控制 运行安装程序 时红帽 CloudForms 安装的行为。

您可以使用 openshift_management_template_parameters Ansible 角色变量来指定要在应用程序或 PV 模板中覆盖的任何模板参数。

例如，如果要降低 PostgreSQL pod 的内存要求，您可以设置以下内容：

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 任务期间收到错误，请在再次运行安装程序前先运行 卸载脚本。

您可以选择在初始 OpenShift Container Platform 安装过程中或置备集群后部署 Red Hat CloudForms：

以下小节演示了在 OpenShift Container Platform 中显示 Red Hat CloudForms 的各种配置的清单文件示例片段，可帮助您开始。

[OSEv3:vars]
openshift_management_app_template=cfme-template

[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_storage_class=nfs_external 1
openshift_management_storage_nfs_external_hostname=nfs.example.com 2

openshift_management_storage_nfs_base_dir=/exports/hosted/prod

[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_MEM_REQ': '3000Mi', 'POSTGRESQL_MEM_REQ': '1Gi', 'ANSIBLE_MEM_REQ': '512Mi'}

[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'}

在 OpenShift Container Platform 上部署 Red Hat CloudForms 后，如 运行安装程序 所述，有两种方法可用于启用容器供应商集成。您可以将 OpenShift Container Platform 手动添加为容器供应商，也可以尝试使用此角色中包含的 playbook。

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
    openshift-management/add_container_provider.yml

除了提供 playbook 以将当前 OpenShift Container Platform 集群集成到 Red Hat CloudForms 部署中，此角色包含一个脚本，允许您在任何任意红帽 CloudForms 服务器中添加多个容器平台作为容器供应商。容器平台可以是 OpenShift Container Platform 或 OpenShift Origin。

在运行 playbook 时，使用多个提供程序脚本需要在 CLI 上手动配置和设置 EXTRA_VARS 参数。

container_providers:
  - connection_configurations:
      - authentication: {auth_key: "<token>", authtype: bearer, type: AuthToken} 1
        endpoint: {role: default, security_protocol: ssl-without-validation, verify_ssl: 0}
    hostname: "<provider_hostname1>"
    name: <display_name1>
    port: 8443
    type: "ManageIQ::Providers::Openshift::ContainerManager"
  - connection_configurations:
      - authentication: {auth_key: "<token>", authtype: bearer, type: AuthToken} 2
        endpoint: {role: default, security_protocol: ssl-without-validation, verify_ssl: 0}
    hostname: "<provider_hostname2>"
    name: <display_name2>
    port: 8443
    type: "ManageIQ::Providers::Openshift::ContainerManager"
management_server:
  hostname: "<hostname>"
  user: <user_name>
  password: <password>

$ 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

添加单个或多个容器提供程序后，必须在红帽 CloudForms 中刷新新的提供程序，以获取关于容器提供程序和所管理容器的所有最新数据。这涉及导航到红帽 CloudForms Web 控制台中的各个提供程序，然后单击每个控制台的刷新按钮。

有关步骤，请参阅以下 Red Hat CloudForms 文档：

要从 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

无法擦除旧的 PostgreSQL 数据可能会导致级联错误，从而导致 postgresql pod 进入 crashloopbackoff 状态。这会阻止 cfme pod 启动。crashloopbackoff 的原因是，之前部署期间创建的数据库 NFS 导出的文件权限不正确。

要继续，请从 PostgreSQL 导出中删除所有数据，并删除 pod（而不是部署器 Pod）。例如，如果您有以下 pod：

$ oc get pods
NAME                 READY     STATUS             RESTARTS   AGE
httpd-1-cx7fk        1/1       Running            1          21h
cfme-0               0/1       Running            1          21h
memcached-1-vkc7p    1/1       Running            1          21h
postgresql-1-deploy  1/1       Running            1          21h
postgresql-1-6w2t4   0/1       CrashLoopBackOff   1          21h

然后，您将：

PostgreSQL 部署器容器集将尝试扩展新的 postgresql 容器集，以取代您删除的容器集。在 postgresql 容器集运行后，cfme 容器集将停止阻止并开始应用初始化。

监控堆栈会带来额外的资源需求。详情请查看计算资源建议。

监控堆栈默认安装有 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 目录的常用路径是 /usr/share/ansible/openshift-ansible/。在本例中，配置文件的路径为 /usr/share/ansible/openshift-ansible/playbooks/openshift-monitoring/config.yml。

使用持久性存储运行集群监控意味着您的指标存储在 持久性卷中，并可在 Pod 重新启动或重新创建后保留。如果您需要预防指标或警报数据丢失，这是理想方案。在生产环境中，强烈建议您使用块存储技术配置永久存储。

配置 OpenShift Container Platform Monitoring 的支持方法是使用本指南中介绍的选项进行配置。除了这些明确的配置选项外，还可以将其他配置注入到堆栈中。但不受支持，因为配置范例可能会在 Prometheus 发行版本间有所变化，只有在控制了所有可能的配置时，才能安全地应对这样的情况。

明确不支持的情形包括：

OpenShift Container Platform Monitoring 附带了一个 死人开关，用于确保监控基础架构的可用性。

死人开关是始终触发的简单 Prometheus 警报规则。Alertmanager 持续向支持此功能的通知提供程序发送死人交换机的通知。这也可确保 Alertmanager 和通知提供程序之间的通信正常工作。

PagerDuty 支持这种机制，以在监控系统本身停机时发出警报。如需更多信息，请参阅下面的死人开关 PagerDuty。

在警报针对 Alertmanager 触发后，必须将其配置为了解如何在逻辑上分组它们。

在本例中，添加了一个新的路由来反映 frontend 团队的警报路由。

PagerDuty 通过名为 死人开关 的集成来支持此机制。只需将 PagerDuty 配置添加到默认的 deadmanswitch 接收器。使用上述流程添加此配置。

如果死人开关警报静默 15 分钟，将死人开关配置为页面运算符。使用默认的 Alertmanager 配置时，死人开关警报每五分钟重复一次。如果死人开关在 15 分钟后触发，这表明通知失败至少两次。

了解如何 为 PagerDuty 配置死人开关。

OpenShift Container Platform Cluster Monitoring 附带了以下默认配置的警报规则。目前无法添加自定义警报规则。

有些警报规则的名称相同。这是有意设计的。它们会警告同一事件，它们具有不同的阈值，或严重性不同。在禁止规则中，触发较高的严重性时会禁止较低严重性。

有关警报规则的详情，请查看配置文件。

如果您是有权使用红帽产品的红帽客户，则拥有具有适用用户凭证的帐户。这些是您用于登录到红帽客户门户的用户名和密码。

如果您没有帐户，可以通过注册以下选项之一获取免费帐户：

如果您的组织管理共享帐户，则必须创建令牌。管理员可以创建、查看和删除与组织关联的所有令牌。

您还可以在安装过程中使用 Ansible 安装程序管理 registry 凭据。

这将设置以下内容：

当您将 registry.redhat.io 的默认值用于 openshift_examples_registryurl 或 oreg_url 时，Ansible 安装程序将需要凭证。

需要访问其他经过身份验证的 registry 的集群可以通过设置 openshift_additional_registry_credentials 来配置 registry 列表。每个 registry 都需要主机和密码值，您可以通过设置用户来指定用户名。默认情况下，通过尝试检查指定 registry 上的镜像 openshift3/ose-pod 来验证指定的凭证。

要指定备用镜像，请执行以下操作：

如果 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'}]

在为 Red Hat Registry 创建服务帐户和生成的令牌后，您可以执行其他任务。

要将 OpenShift Container Platform 集群配置为使用 HTPasswd 身份验证，您至少需要一个带有哈希密码的用户才能包含在 清单文件中。

您可以：

创建用户和散列密码：

然后您可以在配置 HTPasswd 身份验证时使用哈希密码。hashed 密码是字符串，位于 : 后面。在上例中，请输入：

openshift_master_htpasswd_users={'myuser': '$apr1$wIwXkFLI$bAygtISk2eKGmqaJftB'}

创建带有用户名和散列密码的平面文件：

然后，您可以在配置 HTPasswd 身份验证时使用密码文件。