基础架构节点是标记为运行 OpenShift Container Platform 环境组成部分的节点。目前，管理节点重新引导的最简单方法是确保至少有三个节点可用于运行基础架构。以下情景演示了一个常见的错误，只有两个节点可用时，它可能会导致 OpenShift Container Platform 上运行的应用程序发生服务中断。

使用三个基础架构节点的同一流程不会导致服务中断。但由于 pod 调度的原因，最后一个节点在撤离并返回到轮转后，会保留为运行零个 registry。其他两个节点将分别运行两个 registry 和一个 registry。最好的解决方法是借助 pod 反关联性。Kubernetes 中有一个 alpha 功能，现在可用于测试，但尚不支持用于生产环境工作负载。

Pod 反关联性 与 节点反关联性 稍有不同。如果没有其他适当的位置来部署 pod，则可以违反节点反关联性。Pod 反关联性可以设置为必要的或偏好的。

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity: 1
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 100 3
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: docker-registry 4
              operator: In 5
              values:
              - default
          topologyKey: kubernetes.io/hostname

本例假定容器镜像 registry pod 具有标签 docker-registry=default。Pod 反关联性可以使用任何 Kubernetes 匹配表达式。

最后一步是在 /etc/origin/master/scheduler.json 中启用 MatchInterPodAffinity 调度程序 predicate。进行了这样的设置后，如果只有两个基础架构节点可用，并且一个节点发生重新引导，容器镜像 registry pod 会被禁止在另一节点上运行。oc get pods 会报告 pod 未就绪，直到有合适的节点可用为止。一旦某个节点可用，并且所有 pod 恢复到就绪状态，下一个节点就可以重启。

在大多数情况下，运行 OpenShift Container Platform 路由器的 pod 将公开主机端口。PodFitsPorts 调度程序 predicate 确保没有使用相同端口的其他路由器 pod 在同一节点上运行，并且达成 pod 反关联性。如果路由器依赖于 IP 故障转移来实现高可用性，则不需要任何其他操作。如果路由器 pod 依赖 AWS Elastic Load Balancing 等外部服务来实现高可用性，则由该服务负责响应路由器 pod 重启。

在个别情况下，路由器 pod 可能没有配置主机端口。在这些情况下，务必要遵循推荐的基础架构节点的重启流程。

您可以通过在节点配置映射中添加 kubelet 参数来配置节点资源。

在 /etc/origin/node/node-config.yaml 文件中，一个参数控制可调度到节点的 pod 的最大数量： max-pods。当使用 max-pods 选项时，它会限制节点上的 pod 数量。超过这个值可能会导致：

max-pods 把节点可以运行的 pod 数量设置为一个固定值，而不需要考虑节点的属性。集群限制 记录 max-pods 的最大支持值。

kubeletArguments:
  max-pods:
    - "250"

使用上例，max-pods 的默认值为 250。

如果 etcd 主机已损坏，并且 /etc/etcd/etcd.conf 文件丢失，请按照以下步骤恢复该文件：

在本例中，备份文件存储在 /backup/etcd-config-<timestamp>/etcd/etcd.conf 路径中，其中可用作外部 NFS 共享、S3 存储桶或其他存储解决方案。

恢复 etcd 配置文件后，您必须重启静态 pod。这是在恢复 etcd 数据后完成的。

在静态 pod 中恢复 etcd 前：

在静态 pod 上恢复 etcd:

流程

如果您没有以静态 pod 用户身份在 master 节点上运行 etcd，您可能需要添加另一个 etcd 主机。

流程

修改当前的 etcd 集群

要创建 etcd 证书，请运行 openssl 命令，将值替换为您环境中的值。

修改新的 etcd 主机

修改每个 OpenShift Container Platform master

流程

下列步骤假定已创建新的 pvc。

流程

流程

如果您没有以静态 pod 用户身份在 master 节点上运行 etcd，您可能需要添加另一个 etcd 主机。

流程

修改当前的 etcd 集群

要创建 etcd 证书，请运行 openssl 命令，将值替换为您环境中的值。

修改新的 etcd 主机

修改每个 OpenShift Container Platform master

API 服务器根据由 master-config.yaml 文件的 projectRequestTemplate 参数标识的模板自动置备项目。如果没有定义该参数，API 服务器会创建一个默认模板，该模板将以请求的名称创建项目，并将请求用户分配至该项目的 admin 角色。

创建自己的自定义项目模板：

提交项目请求时，API 会替换模板中的以下参数：

API 访问权限授予具有 self-provisioner 角色和 self-provisioners 集群角色绑定的开发人员。默认情况下，所有通过身份验证的开发人员都可获得此角色。

您可以防止经过身份验证的用户组自助置备新项目。

作为集群管理员，您可以设置集群范围的默认节点选择器来限制 pod 放置到特定的节点。

编辑 /etc/origin/master/master-config.yaml 中的 master 配置文件，并为默认节点选择器添加一个值。这应用到没有指定 nodeSelector 值的所有项目中创建的 pod：

...
projectConfig:
  defaultNodeSelector: "type=user-node,region=east"
...

重启 OpenShift 服务以使更改生效：

# master-restart api
# master-restart controllers

要使用节点选择器创建单个项目，请在创建项目时使用 --node-selector 选项。例如，如果您有一个带有多个区域的 OpenShift Container Platform 拓扑，您可以使用节点选择器限制特定的 OpenShift Container Platform 项目，仅将 pod 部署到特定区域的节点。

以下命令创建一个名为 myproject 的新项目，它规定 pod 部署到标有 user-node 和 east 的节点上：

$ oc adm new-project myproject \
    --node-selector='type=user-node,region=east'

运行此命令后，这便成为指定项目中包含的所有容器集的管理员设置节点选择器。

使用 oc adm new-project 命令，为项目添加 注解 部分。您可以编辑项目，并更改 openshift.io/node-selector 值来覆盖默认值：

...
metadata:
  annotations:
    openshift.io/node-selector: type=user-node,region=east
...

您还可以使用以下命令覆盖现有项目命名空间的默认值：

# oc patch namespace myproject -p \
    '{"metadata":{"annotations":{"openshift.io/node-selector":"node-role.kubernetes.io/infra=true"}}}'

如果 openshift.io/node-selector 设置为空字符串(oc adm new-project --node-selector="")，则项目将无法具有管理员设置的节点选择器，即使已经设置了集群范围的默认值。这意味着，作为集群管理员，您可以设置默认值，将开发人员项目限制为节点的子集，并且仍然启用基础架构或其他项目来调度整个集群。

如果 OpenShift Container Platform 开发人员希望进一步限制节点，则可以在其 pod 配置上设置节点选择器。这将是项目节点选择器的补充，这意味着您仍然可以为具有节点选择器值的所有项目指定节点选择器值。

例如，如果使用上述注解创建了一个项目(openshift.io/node-selector: type=user-node,region=east)，并且开发人员在该项目中的 pod 上设置了另一个节点选择器（例如 disable=classified），pod 只会调度到具有所有三个标签（type=user-node、region=east 和 working=classified） 的节点上。如果容器集上设置了 region=west，则其容器集将要求具有标签 region=east 和 region=west 的节点，它们无法工作。pod 不会被调度，因为标签只能设置为一个值。

插件配置应包含运行后 pod 的默认活跃截止时间。此截止时间在全局范围内执行，但可以根据每个项目替代。

admissionConfig:
  pluginConfig:
    RunOnceDuration:
      configuration:
        apiVersion: v1
        kind: RunOnceDurationConfig
        activeDeadlineSecondsOverride: 3600 1
....

除了为运行一次 pod 指定全局最长持续时间外，管理员还可以向特定项目添加注解(openshift.io/active-deadline-seconds-override)，以覆盖全局默认值。

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  containers:
  - name: egress-router
    image: openshift3/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 1
      value: 192.168.12.99
    - name: EGRESS_GATEWAY 2
      value: 192.168.12.1
    - name: EGRESS_DESTINATION 3
      value: 203.0.113.25
  nodeSelector:
    site: springfield-1 4

apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: http
    port: 80
  - name: https
    port: 443
  type: ClusterIP
  selector:
    name: egress-1

作为 OpenShift Container Platform 集群管理员，您可以使用出口策略限制集群中有些或所有 pod 可以访问的外部地址，以便：

例如，您可以使用不同的出口策略配置项目，允许 <project A> 访问指定的 IP 范围，但拒绝对 <project B> 相同的访问。

项目管理员既不能创建 EgressNetworkPolicy 对象，也不能编辑您在项目中创建的对象。另外还有一些其他限制可以创建 EgressNetworkPolicy ：

违反这些限制将导致项目的出口策略中断，并可能导致所有外部网络流量被丢弃。

将项目加入现有项目网络：

$ oc adm pod-network join-projects --to=<project1> <project2> <project3>

在上例中，<project2> 和 <project3&gt 中的所有 pod 和服务现在可以访问 <project1> 中的任何 pod 和服务，反之亦然。服务可以通过 IP 或完全限定 DNS 名称(<service>.<pod_namespace>.svc.cluster.local)访问。例如，若要访问 myproject 项目中名为 db 的服务，可使用 db.myproject.svc.cluster.local。

另外，您也可以使用 --selector=<project_selector> 选项，而不指定具体的项目名称。

验证您接合的网络：

$ oc get netnamespaces

然后查看 NETID 列。同一 pod-network 中的项目将具有相同的 NetID。

允许项目访问集群中的所有 pod 和服务，反之亦然：

$ oc adm pod-network make-projects-global <project1> <project2>

在上例中，<project1> 和 <project2> 中的所有 pod 和服务现在可以访问集群中的任何 pod 和服务，反之亦然。

另外，您也可以使用 --selector=<project_selector> 选项，而不指定具体的项目名称。

OpenShift Container Platform 出口路由器使用一个私有源 IP 地址运行一项服务，该服务将流量重定向到指定的远程服务器。服务允许容器集与设置为仅允许从白名单 IP 地址访问的服务器进行通信。

部署注意事项

Egress 路由器向节点的主网络接口添加第二个 IP 地址和 MAC 地址。如果您没有在裸机上运行 OpenShift Container Platform，您可能需要配置虚拟机监控程序或云供应商来允许额外的地址。

具体来说，请确保启用了以下功能：

出口路由器模式

出口路由器可以三种不同的模式运行： 重定向模式、HTTP 代理模式和 DNS 代理模式。重定向模式可用于除 HTTP 和 HTTPS 以外的所有服务。对于 HTTP 和 HTTPS 服务，请使用 HTTP 代理模式。对于使用 IP 地址或域名的基于 TCP 的服务，请使用 DNS 代理模式。

apiVersion: v1
kind: Pod
metadata:
  name: egress-multi
  labels:
    name: egress-multi
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift3/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 1
      value: 192.168.12.99/24
    - name: EGRESS_GATEWAY
      value: 192.168.12.1
    - name: EGRESS_DESTINATION 2
      value: |
        80   tcp 203.0.113.25
        8080 tcp 203.0.113.26 80
        8443 tcp 203.0.113.26 443
        203.0.113.27
    - name: EGRESS_ROUTER_MODE
      value: init
  containers:
  - name: egress-router-wait
    image: registry.redhat.io/openshift3/ose-pod

有些集群管理员可能希望对传出流量执行操作，这些流量不适合 EgressNetworkPolicy 或出口路由器的模型。在某些情况下，这可以通过直接创建 iptables 规则来完成。

例如，您可以创建记录到特定目的地的流量的规则，或者防止每秒超过特定数量的传出连接。

OpenShift Container Platform 不提供自动添加自定义 iptables 规则的方法，但它提供了一个可供管理员手动添加此类规则的位置。在启动时，每个节点都会在 过滤器 表中创建一个名为 OPENSHIFT-ADMIN-OUTPUT-RULES 的空链（假设链尚不存在）。管理员添加至该链的任何规则都将应用到从 pod 到集群外目的地的所有流量（而不是任何其他流量）。

使用此功能时需要注意以下几点：

NetworkPolicy 对象允许您在命名空间中通过标签来相互隔离不同的 pod。

将 NetworkPolicy 对象应用到单一命名空间中的大量 pod 时，效率较低。pod 标签不存在于 IP 级别上，因此 NetworkPolicy 对象会为使用 pod Selector 选择的每个 pod 之间生成单独的 OVS 流规则。

例如，在一个 NetworkPolicy 对象中如果 spec podSelector 和 ingress podSelector 每个都匹配 200 个 pod，则会产生 40,000 (200*200) 个 OVS 流规则。这可能会减慢机器的速度。

若要减少 OVS 流规则的数量，可使用命名空间来包含需要隔离的 pod 组。

使用 namespaceSelectors 或空 podSelectors 选择整个命名空间的 NetworkPolicy 对象只会生成与命名空间的 VXLAN VNID 匹配的 OVS 流规则。

保留不需要在原始命名空间中隔离的 pod，并将需要隔离的 pod 移到一个或多个不同的命名空间中。

创建额外的目标跨命名空间策略，以允许来自隔离 pod 的特定流量。

使用 ovs-multitenant 插件时，所有命名空间中会自动允许来自路由器的流量。这是因为路由器通常位于 default 命名空间中，所有命名空间都允许来自该命名空间中的 pod 的连接。使用 ovs-networkpolicy 插件时，这不会自动发生。因此，如果您有一个默认隔离命名空间的策略，则需要执行额外的步骤来允许路由器访问命名空间。

一种选择是为每个服务创建一个策略，允许从所有来源访问。例如：

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-to-database-service
spec:
  podSelector:
    matchLabels:
      role: database
  ingress:
  - ports:
    - protocol: TCP
      port: 5432

这允许路由器访问该服务，但也允许其他用户命名空间中的容器集访问该服务。这不应造成任何问题，因为这些容器集通常可以使用公共路由器访问服务。

另外，您可以创建一个允许从默认命名空间中完全访问的策略，如 ovs-multitenant 插件中所示：

集群管理员可修改默认项目模板，以便在创建新项目时自动创建默认 NetworkPolicy 对象 （一个或多个）。要做到这一点：

查看集群角色及其关联的规则集：

$ oc describe clusterrole.rbac
Name:		admin
Labels:		<none>
Annotations:	openshift.io/description=A user that has edit rights within the project and can change the project's membership.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources							Non-Resource URLs	Resource Names	Verbs
  ---------							-----------------	--------------	-----
  appliedclusterresourcequotas					[]			[]		[get list watch]
  appliedclusterresourcequotas.quota.openshift.io		[]			[]		[get list watch]
  bindings							[]			[]		[get list watch]
  buildconfigs							[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs/instantiate					[]			[]		[create]
  buildconfigs.build.openshift.io/instantiate			[]			[]		[create]
  buildconfigs/instantiatebinary				[]			[]		[create]
  buildconfigs.build.openshift.io/instantiatebinary		[]			[]		[create]
  buildconfigs/webhooks						[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io/webhooks			[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs							[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds							[]			[]		[create delete deletecollection get list patch update watch]
  builds.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds/clone							[]			[]		[create]
  builds.build.openshift.io/clone				[]			[]		[create]
  builds/details						[]			[]		[update]
  builds.build.openshift.io/details				[]			[]		[update]
  builds/log							[]			[]		[get list watch]
  builds.build.openshift.io/log					[]			[]		[get list watch]
  configmaps							[]			[]		[create delete deletecollection get list patch update watch]
  cronjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  daemonsets.extensions						[]			[]		[get list watch]
  deploymentconfigrollbacks					[]			[]		[create]
  deploymentconfigrollbacks.apps.openshift.io			[]			[]		[create]
  deploymentconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/instantiate					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/instantiate		[]			[]		[create]
  deploymentconfigs/log						[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/log			[]			[]		[get list watch]
  deploymentconfigs/rollback					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/rollback			[]			[]		[create]
  deploymentconfigs/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io/scale			[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/status					[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/status			[]			[]		[get list watch]
  deployments.apps						[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/rollback				[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/status					[]			[]		[create delete deletecollection get list patch update watch]
  endpoints							[]			[]		[create delete deletecollection get list patch update watch]
  events							[]			[]		[get list watch]
  horizontalpodautoscalers.autoscaling				[]			[]		[create delete deletecollection get list patch update watch]
  horizontalpodautoscalers.extensions				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimports						[]			[]		[create]
  imagestreamimports.image.openshift.io				[]			[]		[create]
  imagestreammappings						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreammappings.image.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams							[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/layers						[]			[]		[get update]
  imagestreams.image.openshift.io/layers			[]			[]		[get update]
  imagestreams/secrets						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io/secrets			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/status						[]			[]		[get list watch]
  imagestreams.image.openshift.io/status			[]			[]		[get list watch]
  imagestreamtags						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamtags.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  jenkins.build.openshift.io					[]			[]		[admin edit view]
  jobs.batch							[]			[]		[create delete deletecollection get list patch update watch]
  limitranges							[]			[]		[get list watch]
  localresourceaccessreviews					[]			[]		[create]
  localresourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  localsubjectaccessreviews					[]			[]		[create]
  localsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  localsubjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  namespaces							[]			[]		[get list watch]
  namespaces/status						[]			[]		[get list watch]
  networkpolicies.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  persistentvolumeclaims					[]			[]		[create delete deletecollection get list patch update watch]
  pods								[]			[]		[create delete deletecollection get list patch update watch]
  pods/attach							[]			[]		[create delete deletecollection get list patch update watch]
  pods/exec							[]			[]		[create delete deletecollection get list patch update watch]
  pods/log							[]			[]		[get list watch]
  pods/portforward						[]			[]		[create delete deletecollection get list patch update watch]
  pods/proxy							[]			[]		[create delete deletecollection get list patch update watch]
  pods/status							[]			[]		[get list watch]
  podsecuritypolicyreviews					[]			[]		[create]
  podsecuritypolicyreviews.security.openshift.io		[]			[]		[create]
  podsecuritypolicyselfsubjectreviews				[]			[]		[create]
  podsecuritypolicyselfsubjectreviews.security.openshift.io	[]			[]		[create]
  podsecuritypolicysubjectreviews				[]			[]		[create]
  podsecuritypolicysubjectreviews.security.openshift.io		[]			[]		[create]
  processedtemplates						[]			[]		[create delete deletecollection get list patch update watch]
  processedtemplates.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  projects							[]			[]		[delete get patch update]
  projects.project.openshift.io					[]			[]		[delete get patch update]
  replicasets.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  replicasets.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers.extensions/scale			[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/status					[]			[]		[get list watch]
  resourceaccessreviews						[]			[]		[create]
  resourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  resourcequotas						[]			[]		[get list watch]
  resourcequotas/status						[]			[]		[get list watch]
  resourcequotausages						[]			[]		[get list watch]
  rolebindingrestrictions					[]			[]		[get list watch]
  rolebindingrestrictions.authorization.openshift.io		[]			[]		[get list watch]
  rolebindings							[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.authorization.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.rbac.authorization.k8s.io			[]			[]		[create delete deletecollection get list patch update watch]
  roles								[]			[]		[create delete deletecollection get list patch update watch]
  roles.authorization.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  roles.rbac.authorization.k8s.io				[]			[]		[create delete deletecollection get list patch update watch]
  routes							[]			[]		[create delete deletecollection get list patch update watch]
  routes.route.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  routes/custom-host						[]			[]		[create]
  routes.route.openshift.io/custom-host				[]			[]		[create]
  routes/status							[]			[]		[get list watch update]
  routes.route.openshift.io/status				[]			[]		[get list watch update]
  scheduledjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  secrets							[]			[]		[create delete deletecollection get list patch update watch]
  serviceaccounts						[]			[]		[create delete deletecollection get list patch update watch impersonate]
  services							[]			[]		[create delete deletecollection get list patch update watch]
  services/proxy						[]			[]		[create delete deletecollection get list patch update watch]
  statefulsets.apps						[]			[]		[create delete deletecollection get list patch update watch]
  subjectaccessreviews						[]			[]		[create]
  subjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  subjectrulesreviews						[]			[]		[create]
  subjectrulesreviews.authorization.openshift.io		[]			[]		[create]
  templateconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  templateconfigs.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances						[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  templates							[]			[]		[create delete deletecollection get list patch update watch]
  templates.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]


Name:		basic-user
Labels:		<none>
Annotations:	openshift.io/description=A user that can get basic information about projects.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources						Non-Resource URLs	Resource Names	Verbs
  ---------						-----------------	--------------	-----
  clusterroles						[]			[]		[get list]
  clusterroles.authorization.openshift.io		[]			[]		[get list]
  clusterroles.rbac.authorization.k8s.io		[]			[]		[get list watch]
  projectrequests					[]			[]		[list]
  projectrequests.project.openshift.io			[]			[]		[list]
  projects						[]			[]		[list watch]
  projects.project.openshift.io				[]			[]		[list watch]
  selfsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  selfsubjectrulesreviews				[]			[]		[create]
  selfsubjectrulesreviews.authorization.openshift.io	[]			[]		[create]
  storageclasses.storage.k8s.io				[]			[]		[get list]
  users							[]			[~]		[get]
  users.user.openshift.io				[]			[~]		[get]


Name:		cluster-admin
Labels:		<none>
Annotations:	authorization.openshift.io/system-only=true
		openshift.io/description=A super-user that can perform any action in the cluster. When granted to a user within a project, they have full control over quota and membership and can perform every action...
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources	Non-Resource URLs	Resource Names	Verbs
  ---------	-----------------	--------------	-----
  		[*]			[]		[*]
  *.*		[]			[]		[*]


Name:		cluster-debugger
Labels:		<none>
Annotations:	authorization.openshift.io/system-only=true
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources	Non-Resource URLs	Resource Names	Verbs
  ---------	-----------------	--------------	-----
  		[/debug/pprof]		[]		[get]
  		[/debug/pprof/*]	[]		[get]
  		[/metrics]		[]		[get]


Name:		cluster-reader
Labels:		<none>
Annotations:	authorization.openshift.io/system-only=true
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources							Non-Resource URLs	Resource Names	Verbs
  ---------							-----------------	--------------	-----
  								[*]			[]		[get]
  apiservices.apiregistration.k8s.io				[]			[]		[get list watch]
  apiservices.apiregistration.k8s.io/status			[]			[]		[get list watch]
  appliedclusterresourcequotas					[]			[]		[get list watch]

...

查看当前的集群角色绑定集合，这显示绑定到各种角色的用户和组：

$ oc describe clusterrolebinding.rbac
Name:		admin
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind			Name				Namespace
  ----			----				---------
  ServiceAccount	template-instance-controller	openshift-infra


Name:		basic-users
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	basic-user
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		cluster-admin
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-admin
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	pvinstaller	default
  Group			system:masters


Name:		cluster-admins
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-admin
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:cluster-admins
  User	system:admin


Name:		cluster-readers
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-reader
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:cluster-readers


Name:		cluster-status-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-status
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated
  Group	system:unauthenticated


Name:		registry-registry-role
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:registry
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	registry	default


Name:		router-router-role
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:router
Subjects:
  Kind			Name	Namespace
  ----			----	---------
  ServiceAccount	router	default


Name:		self-access-reviewers
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	self-access-reviewer
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated
  Group	system:unauthenticated


Name:		self-provisioners
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	self-provisioner
Subjects:
  Kind	Name				Namespace
  ----	----				---------
  Group	system:authenticated:oauth


Name:		system:basic-user
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:basic-user
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated
  Group	system:unauthenticated


Name:		system:build-strategy-docker-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:build-strategy-docker
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		system:build-strategy-jenkinspipeline-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:build-strategy-jenkinspipeline
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		system:build-strategy-source-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:build-strategy-source
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		system:controller:attachdetach-controller
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:controller:attachdetach-controller
Subjects:
  Kind			Name			Namespace
  ----			----			---------
  ServiceAccount	attachdetach-controller	kube-system


Name:		system:controller:certificate-controller
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:controller:certificate-controller
Subjects:
  Kind			Name			Namespace
  ----			----			---------
  ServiceAccount	certificate-controller	kube-system


Name:		system:controller:cronjob-controller
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true

...

所有默认集群角色都可以在本地绑定到用户或组。

可以创建自定义本地角色。

本地角色绑定也可以查看。

查看当前的本地角色绑定集合，这显示绑定到各种角色的用户和组：

$ oc describe rolebinding.rbac

默认情况下，在查看本地角色绑定时使用当前项目。此外，也可通过 -n 标志指定项目。如果用户已经拥有 admin 默认集群角色，这可用于查看另一个项目的本地角色绑定。

$ oc describe rolebinding.rbac -n joe-project
Name:		admin
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind	Name	Namespace
  ----	----	---------
  User	joe


Name:		system:deployers
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:deployer
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	deployer	joe-project


Name:		system:image-builders
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:image-builder
Subjects:
  Kind			Name	Namespace
  ----			----	---------
  ServiceAccount	builder	joe-project


Name:		system:image-pullers
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:image-puller
Subjects:
  Kind	Name					Namespace
  ----	----					---------
  Group	system:serviceaccounts:joe-project

要向镜像添加新签名，您可以使用 HTTP PUT 方法将 JSON 有效负载发送到 extensions 端点：

PUT /extensions/v2/<namespace>/<name>/signatures/<digest>

$ curl -X PUT --data @signature.json http://<user>:<token>@<registry_endpoint>:5000/extensions/v2/<namespace>/<name>/signatures/sha256:<digest>

带有签名内容的 JSON 有效负载应具有以下结构：

{
  "version": 2,
  "type":    "atomic",
  "name":    "sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23",
  "content": "<cryptographic_signature>"
}

name 字段包含镜像签名的名称，该名称必须是唯一的，格式为 <digest>@<name>。<digest> 代表镜像名称，<name> 是签名的名称。签名名称长度必须为 32 个字符。<cryptgraph_signature> 必须遵循 容器/镜像库 中记录的规格。

假设已签名的镜像已被推送到 OpenShift Container Registry 中，您可以使用以下命令读取签名：

GET /extensions/v2/<namespace>/<name>/signatures/<digest>

$ curl http://<user>:<token>@<registry_endpoint>:5000/extensions/v2/<namespace>/<name>/signatures/sha256:<digest>

<namespace> 代表 OpenShift Container Platform 项目名称或 registry 存储库名称，<name> 代表镜像存储库的名称。摘要（digest）代表镜像的 SHA-256 校验和。

如果给定镜像包含签名数据，则上述命令的输出应生成以下 JSON 响应：

{
  "signatures": [
  {
    "version": 2,
    "type":    "atomic",
    "name":    "sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23",
    "content": "<cryptographic_signature>"
  }
  ]
}

name 字段包含镜像签名的名称，该名称必须是唯一的，格式为 <digest>@<name>。<digest> 代表镜像名称，<name> 是签名的名称。签名名称长度必须为 32 个字符。<cryptgraph_signature> 必须遵循 容器/镜像库 中记录的规格。

如果在所有 OpenShift Container Platform master 节点上通过 registry 配置目录配置了签名存储，OpenShift Container Platform 可以自动导入镜像签名。

registry 配置目录包含各种 registry（存储远程容器镜像）和其中存储的内容的配置。单个目录确保不必在每一个命令的命令行选项中提供配置，以便容器/镜像的所有用户可以共享该配置。

默认 registry 配置目录位于 /etc/containers/registries.d/default.yaml 文件中。

导致所有红帽镜像自动导入镜像签名的示例配置示例：

docker:
  registry.redhat.io:
    sigstore: https://registry.redhat.io/containers/sigstore 1

有关 registry 配置目录的详情，请参阅 registry 配置目录。

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext: 1
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000 1
  containers:
    - name: sec-ctx-demo
      image: gcr.io/google-samples/node-hello:1.0

这可与 SELinux、fsGroup 和补充组配合使用。如需更多信息，请参阅卷安全性。

在某些情况下，管理员可能希望允许管理员组以外的用户或组创建更多 特权 pod。为此，您可以：

首先，创建一个 服务帐户。例如，要在 myproject 项目中创建服务帐户 mysvcacct ：

$ oc create serviceaccount mysvcacct -n myproject

然后，将服务帐户添加到 特权 SCC。

$ oc adm policy add-scc-to-user privileged system:serviceaccount:myproject:mysvcacct

然后，确保为服务帐户创建资源。为此，请将 spec.serviceAccountName 字段设置为服务帐户名称。将服务帐户名称留空将导致使用 default 服务帐户。

然后，确保至少有一个 pod 的容器在安全上下文中请求特权模式。

放松集群中的安全性，以便镜像不会强制以预分配的 UID 运行，而不授予每个人都对 特权 SCC 的访问权限：

某些容器镜像（示例： postgres 和 redis）需要 root 访问权限，并且对卷的拥有方式有一定期望。对于这些镜像，将服务帐户添加到 anyuid SCC。

$ oc adm policy add-scc-to-user anyuid system:serviceaccount:myproject:mysvcacct

推荐持久性存储使用PersistentVolume，PersistentVolumeClaim对象可用于 registry 部署。如果您要测试并且希望将 oc adm registry 命令与 --mount-host 选项搭配使用，您必须首先为 Registry 创建一个新 服务帐户，并将它添加到 特权 SCC。有关完整说明，请参阅 管理员指南 。

在某些情况下，镜像可能会需要一些功能，它们没有包括在开箱即用的 Docker 中。您可以在 Pod 规格中请求其他功能，这些功能将针对 SCC 进行验证。

与非 root 用户结合使用时，还必须确保使用 setcap 命令赋予需要额外权限的文件。例如，在镜像的 Dockerfile 中：

setcap cap_net_raw,cap_net_admin+p /usr/bin/ping

此外，如果 Docker 中默认提供了一项功能，则您无需修改 pod 规格即可请求该功能。例如，默认情况下会提供 NET_RAW，并且应该已在 ping 上设置功能，因此无需执行特殊步骤来运行 ping。

提供额外的功能：

当您为每个人授予对 anyuid SCC 的访问权限时，您的集群：

 $ oc adm policy add-scc-to-group anyuid system:authenticated

要修改集群，使其不预先分配 UID，且不允许容器以 root 用户身份运行，请为每个人授予 nonroot SCC 的访问权限：

 $ oc adm policy add-scc-to-group nonroot system:authenticated

要缓解集群中的安全性，以便允许 pod 使用 hostPath 卷插件，而不授予每个人都对更多特权 SCC（如 特权、hostaccess 或 hostmount-anyuid ）的访问权限，请执行以下操作：

现在，hostPath 卷的所有 pod 都被 hostpath SCC 接受。

您可以通过设置 SCC 的 Priority 字段来控制准入中的 SCC 排序。有关排序的更多信息，请参阅 SCC 优先级部分。

在添加 SCC 到用户或组之前，您可以先使用 scc-review 选项来检查用户或组是否可以创建容器集。如需更多信息，请参阅 授权 主题。

SCC 不直接授予项目。相反，您要将服务帐户添加到 SCC 中，并指定 Pod 上的服务帐户名称，或者在未指定的情况下作为 default 服务帐户运行。

将 SCC 添加到用户：

$ oc adm policy add-scc-to-user <scc_name> <user_name>

将 SCC 添加到服务帐户：

$ oc adm policy add-scc-to-user <scc_name> \
    system:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>

如果您当前处于服务帐户所属的项目中，您可以使用 -z 标志，只需指定 <serviceaccount_name>。

$ oc adm policy add-scc-to-user <scc_name> -z <serviceaccount_name>

将 SCC 添加到组中：

$ oc adm policy add-scc-to-group <scc_name> <group_name>

将 SCC 添加到命名空间中的所有服务帐户：

$ oc adm policy add-scc-to-group <scc_name> \
    system:serviceaccounts:<serviceaccount_namespace>

Pod 调度是一个内部过程，决定新 pod 如何放置到集群内的节点上。

调度程度代码具有明确隔离，会监测创建的新 pod 并确定最适合托管它们的节点。然后，它会利用主 API 为 pod 创建 pod 至节点的绑定。

OpenShift Container Platform 附带一个满足大多数用户需求的默认调度程序。默认调度程序同时使用内置和可自定义的工具来确定最适合 pod 的工具。

有关默认调度程序如何决定 pod 放置和可用可自定义参数的详情，请参考 默认调度。

如果您想要更多地控制新 pod 的放置位置，可以利用 OpenShift Container Platform 高级调度功能来配置 pod，从而使 pod 能够根据要求或偏好在特定的节点上运行，或者与特定的 pod 一起运行。通过高级调度，您还可以防止 pod 放置到某个节点上或放置到另一个 pod 中。

有关高级调度的详情，请查看 高级调度。

OpenShift Container Platform 还允许您通过编辑 pod 规格来使用自己的或第三方调度程序。

如需更多信息，请参阅 自定义调度程序。

OpenShift Container Platform 的默认 pod 调度程序负责确定在集群的节点中放置新的 pod。它从 pod 读取数据，并尝试根据配置的策略寻找最适合的节点。它完全独立存在，作为单机或可插拔的解决方案。它不会修改 pod，只是为 pod 创建将 pod 与特定节点衔接起来的绑定。

现有的通用调度程序是平台默认提供的调度程序引擎，它可通过三步操作来选择托管 pod 的节点：

根据指定的约束或要求过滤可用的节点。这可以通过称为 predicates 的过滤器函数列表运行每个节点。

选择 predicate 和 priorities 定义调度程序的策略。

调度程序配置文件是一个 JSON 文件，指定调度程序将考虑的 predicates 和 priorities。

如果没有调度程序策略文件，则会应用默认配置文件 /etc/origin/master/scheduler.json。

{
    "apiVersion": "v1",
    "kind": "Policy",
    "predicates": [
        {
            "name": "NoVolumeZoneConflict"
        },
        {
            "name": "MaxEBSVolumeCount"
        },
        {
            "name": "MaxGCEPDVolumeCount"
        },
        {
            "name": "MaxAzureDiskVolumeCount"
        },
        {
            "name": "MatchInterPodAffinity"
        },
        {
            "name": "NoDiskConflict"
        },
        {
            "name": "GeneralPredicates"
        },
        {
            "name": "PodToleratesNodeTaints"
        },
        {
            "argument": {
                "serviceAffinity": {
                    "labels": [
                        "region"
                    ]
                }
            },
            "name": "Region"

         }
    ],
    "priorities": [
        {
            "name": "SelectorSpreadPriority",
            "weight": 1
        },
        {
            "name": "InterPodAffinityPriority",
            "weight": 1
        },
        {
            "name": "LeastRequestedPriority",
            "weight": 1
        },
        {
            "name": "BalancedResourceAllocation",
            "weight": 1
        },
        {
            "name": "NodePreferAvoidPodsPriority",
            "weight": 10000
        },
        {
            "name": "NodeAffinityPriority",
            "weight": 1
        },
        {
            "name": "TaintTolerationPriority",
            "weight": 1
        },
        {
            "argument": {
                "serviceAntiAffinity": {
                    "label": "zone"
                }
            },
            "name": "Zone",
            "weight": 2
        }
    ]
}

kind: "Policy"
version: "v1"
"predicates": [
        {
            "name": "PodFitsResources"
        },
        {
            "name": "NoDiskConflict"
        },
        {
            "name": "MatchNodeSelector"
        },
        {
            "name": "HostName"
        },
        {
            "argument": {
                "serviceAffinity": {
                    "labels": [
                        "region"
                    ]
                }
            },
            "name": "Region"
        }
    ],
    "priorities": [
        {
            "name": "LeastRequestedPriority",
            "weight": 1
        },
        {
            "name": "BalancedResourceAllocation",
            "weight": 1
        },
        {
            "name": "ServiceSpreadingPriority",
            "weight": 1
        },
        {
            "argument": {
                "serviceAntiAffinity": {
                    "label": "zone"
                }
            },
            "name": "Zone",
            "weight": 2
        }
    ]

predicates 是用于过滤掉不合格节点的规则。

OpenShift Container Platform 中默认提供一些 predicates。其中的一些 predicates 可以通过提供特定参数来自定义。可以组合多个 predicates 来提供更多节点过滤。

{"name" : "NoVolumeZoneConflict"}

{"name" : "MaxEBSVolumeCount"}

{"name" : "MaxGCEPDVolumeCount"}

{"name" : "MatchInterPodAffinity"}

{"name" : "NoDiskConflict"}

{"name" : "PodToleratesNodeTaints"}

{"name" : "CheckVolumeBinding"}

{"name" : "CheckNodeCondition"}

{"name" : "PodToleratesNodeNoExecuteTaints"}

{"name" : "CheckNodeLabelPresence"}

{"name" : "checkServiceAffinity"}

{"name" : "MaxAzureDiskVolumeCount"}

{"name" : "PodFitsResources"}

{"name" : "PodFitsHostPorts"}

{"name" : "HostName"}

{"name" : "MatchNodeSelector"}

"predicates":[
      {
         "name":"<name>", 1
         "argument":{
            "serviceAffinity":{
               "labels":[
                  "<label>" 2
               ]
            }
         }
      }
   ],

        "name":"ZoneAffinity",
        "argument":{
            "serviceAffinity":{
                "labels":[
                    "rack"
                ]
            }
        }

"predicates":[
      {
         "name":"<name>", 1
         "argument":{
            "labelsPresence":{
               "labels":[
                  "<label>" 2
                ],
                "presence": true 3
            }
         }
      }
   ],

        "name":"RackPreferred",
        "argument":{
            "labelsPresence":{
                "labels":[
                    "rack",
                    "region"
                ],
                "presence": true
            }
        }

优先级是根据偏好排列剩余节点等级的规则。

可以指定一组自定义优先级来配置调度程序。OpenShift Container Platform 中默认提供一些优先级。也可通过提供某些参数来自定义其他优先级。可将多个优先级合并，并为每个优先级赋予不同的权重来影响优先顺序。

{"name" : "SelectorSpreadPriority", "weight" : 1}

{"name" : "InterPodAffinityPriority", "weight" : 1}

{"name" : "LeastRequestedPriority", "weight" : 1}

{"name" : "BalancedResourceAllocation", "weight" : 1}

{"name" : "NodePreferAvoidPodsPriority", "weight" : 10000}

{"name" : "NodeAffinityPriority", "weight" : 1}

{"name" : "TaintTolerationPriority", "weight" : 1}

{"name" : "EqualPriority", "weight" : 1}

{"name" : "MostRequestedPriority", "weight" : 1}

{"name" : "ImageLocalityPriority", "weight" : 1}

{"name" : "ServiceSpreadingPriority", "weight" : 1}

"priorities":[
    {
        "name":"<name>", 1
        "weight" : 1 2
        "argument":{
            "serviceAntiAffinity":{
                "label":[
                    "<label>" 3
                ]
            }
        }
    }
]

        "name":"RackSpread", 1
        "weight" : 1 2
        "argument":{
            "serviceAntiAffinity":{
                "label": "rack" 3
            }
        }

"priorities":[
    {
        "name":"<name>", 1
        "weight" : 1, 2
        "argument":{
            "labelPreference":{
                "label": "<label>", 3
                "presence": true 4
            }
        }
    }
]

在 OpenShift Container Platform 中调度的一个重要用例是支持灵活的关联性和反关联性策略。

以下配置如果通过调度程序策略文件指定，则指定默认的调度程序配置。

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RegionZoneAffinity" 1
    argument:
      serviceAffinity: 2
        labels: 3
          - "region"
          - "zone"
priorities:
...
  - name: "RackSpread" 4
    weight: 1
    argument:
      serviceAntiAffinity: 5
        label: "rack" 6

在下方的所有示例配置中，predicates 和 priorities 函数的列表都已截断，仅包含与指定用例相关的内容。在实践中，完整/有意义的调度程序策略应当包含前文所述的大部分（若非全部）默认 predicates 和 priorities。

以下示例定义了三个拓扑级别，即 region（关联性）-> zone（关联性）-> rack（反关联性）：

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RegionZoneAffinity"
    argument:
      serviceAffinity:
        labels:
          - "region"
          - "zone"
priorities:
...
  - name: "RackSpread"
    weight: 1
    argument:
      serviceAntiAffinity:
        label: "rack"

以下示例定义了三个拓扑级别，即 city（关联性）-> building（反关联性）-> room（反关联性）：

kind: "Policy"
version: "v1"
predicates:
...
  - name: "CityAffinity"
    argument:
      serviceAffinity:
        labels:
          - "city"
priorities:
...
  - name: "BuildingSpread"
    weight: 1
    argument:
      serviceAntiAffinity:
        label: "building"
  - name: "RoomSpread"
    weight: 1
    argument:
      serviceAntiAffinity:
        label: "room"

以下示例定义了一个策略，以仅使用定义了“region”标签的节点，并且优先选择定义有“zone”标签的节点：

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RequireRegion"
    argument:
      labelsPresence:
        labels:
          - "region"
        presence: true
priorities:
...
  - name: "ZonePreferred"
    weight: 1
    argument:
      labelPreference:
        label: "zone"
        presence: true

以下示例组合使用静态和可配置的 predicates 和 priorities：

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RegionAffinity"
    argument:
      serviceAffinity:
        labels:
          - "region"
  - name: "RequireRegion"
    argument:
      labelsPresence:
        labels:
          - "region"
        presence: true
  - name: "BuildingNodesAvoid"
    argument:
      labelsPresence:
        labels:
          - "building"
        presence: false
  - name: "PodFitsPorts"
  - name: "MatchNodeSelector"
priorities:
...
  - name: "ZoneSpread"
    weight: 2
    argument:
      serviceAntiAffinity:
        label: "zone"
  - name: "ZonePreferred"
    weight: 1
    argument:
      labelPreference:
        label: "zone"
        presence: true
  - name: "ServiceSpreadingPriority"
    weight: 1

分离涉及根据 特定的策略 驱除 pod，以便可将 pod 重新调度到更合适的节点上。

集群可以从取消调度和重新调度已在运行的 pod 中受益，原因如下：

descheduler 不调度被驱除的 pod。调度程序 自动为被驱除的 pod 执行此任务。

务必要注意，有许多核心组件（如 DNS）对于集群全面运行至关重要，但在常规集群节点而非 master 上运行。如果组件被驱除，集群可能会停止正常工作。要防止 descheduler 删除这些 pod，请将 pod 配置为 关键 pod，方法是将 scheduler.alpha.kubernetes.io/critical-pod 注解添加到 pod 规格中。

descheduler 作业和 descheduler pod 在 kube-system 项目中创建，默认创建。

descheduler 不会驱除以下类型的 pod：

以下小节描述了配置和运行 descheduler 的流程：

配置 descheduler 在 pod 中正常工作所需的权限：

您可以将 descheduler 配置为从违反了 YAML 策略文件中 策略 定义的规则的节点中删除 pod。然后，您可以创建一个 包含策略文件路径的配置映射 以及使用该配置映射应用特定取消调度策略的作业规格。

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "RemoveDuplicates":
     enabled: false
  "LowNodeUtilization":
     enabled: true
     params:
       nodeResourceUtilizationThresholds:
         thresholds:
           "cpu" : 20
           "memory": 20
           "pods": 20
         targetThresholds:
           "cpu" : 50
           "memory": 50
           "pods": 50
         numberOfNodes: 3
  "RemovePodsViolatingInterPodAntiAffinity":
     enabled: true
  "RemovePodsViolatingNodeAffinity":
    enabled: true
    params:
      nodeAffinityType:
      - "requiredDuringSchedulingIgnoredDuringExecution"

有三个可与 descheduler 一起使用的默认策略：

您可以根据需要配置和禁用与策略关联的参数。

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "RemoveDuplicates":
     enabled: false 1

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "LowNodeUtilization":
     enabled: true
     params:
       nodeResourceUtilizationThresholds:
         thresholds: 1
           "cpu" : 20
           "memory": 20
           "pods": 20
         targetThresholds: 2
           "cpu" : 50
           "memory": 50
           "pods": 50
         numberOfNodes: 3 3

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "RemovePodsViolatingInterPodAntiAffinity": 1
     enabled: true

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "RemovePodsViolatingNodeAffinity": 1
    enabled: true
    params:
      nodeAffinityType:
      - "requiredDuringSchedulingIgnoredDuringExecution" 2

为 kube-system 项目中 descheduler 策略文件创建 配置映射，以便 descheduler 作业可以引用它。

# oc create configmap descheduler-policy-configmap \
     -n kube-system --from-file=<path-to-policy-dir/policy.yaml> 1

为 descheduler 创建 作业配置。

apiVersion: batch/v1
kind: Job
metadata:
  name: descheduler-job
  namespace: kube-system
spec:
  parallelism: 1
  completions: 1
  template:
    metadata:
      name: descheduler-pod 1
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: "true" 2
    spec:
        containers:
        - name: descheduler
          image: registry.access.redhat.com/openshift3/ose-descheduler
          volumeMounts: 3
          - mountPath: /policy-dir
            name: policy-volume
          command:
          - "/bin/sh"
          - "-ec"
          - |
            /bin/descheduler --policy-config-file /policy-dir/policy.yaml 4
        restartPolicy: "Never"
        serviceAccountName: descheduler-sa 5
        volumes:
        - name: policy-volume
          configMap:
            name: descheduler-policy-configmap

策略文件作为卷从配置映射中挂载。

以 pod 中作业的形式运行 descheduler：

# oc create -f <file-name>.yaml

例如：

# oc create -f descheduler-job.yaml

您可以运行多个自定义调度程序以及默认调度程序，并配置要用于各个 pod 的调度程序。

要使用特定的调度程序调度给定 pod，在 Pod 的规格中指定调度程序的名称。

在集群中包含自定义调度程序的常规流程涉及创建镜像，并将该镜像包含在部署中。

在集群中部署自定义调度程序后，您可以将 pod 配置为使用该调度程序，而不是默认调度程序。

作为集群管理员，您可以设置策略，以防止具有特定角色的应用开发人员在调度 pod 时定位特定的节点。

Pod 节点 Constraints 准入控制器确保 pod 只使用标签部署到指定的节点主机上，并防止没有特定角色的用户使用 nodeSelector 字段来调度 pod。

使用 Pod 节点 Constraints 准入控制器，通过为其分配标签并在 pod 配置中的 nodeName 设置中指定 pod，以确保 pod 只部署到指定节点主机上。

使用 节点选择器，您可以确保 pod 只放置到具有特定标签的节点上。作为集群管理员，您可以使用 Pod 节点约束准入控制器来设置一个策略，防止没有 pod/绑定 权限的用户使用节点选择器来调度 pod。

master 配置文件的 nodeSelectorLabelBlacklist 字段可让您控制 pod 配置的 nodeSelector 字段中特定角色可以指定的标签。具有 pod/binding 权限 角色 的用户、服务帐户和组可以指定任何节点选择器。没有 pods/binding 权限的组群会被禁止为 nodeSelectorLabelBlacklist 中出现的任何标签设置 nodeSelector。

例如，OpenShift Container Platform 集群可能包含五个数据中心，分布在两个区域。U.S.：us-east, us-central, 和 us-west; Asia-Pacific region (APAC), apac-east 和 apac-west。每个地理区域中的每个节点都会进行相应的标记。例如 region: us-east。

作为集群管理员，您可以创建一个基础架构，应用程序开发人员应在最接近其地理位置的节点上部署 pod。您可以创建节点选择器，将美国数据中心分组到 superregion: us，APAC 数据中心到 superregion: apac。

要维护每个数据中心的资源甚至加载，您可以将所需的 区域 添加到 master 配置的 nodeSelectorLabelBlacklist 部分。然后，每当位于美国的开发人员创建 pod 时，它将部署到具有 superregion: us 标签的其中一个区域的节点。如果开发人员尝试将其容器集的特定区域作为目标（如 region: us-east），则他们会收到错误。如果他们再次尝试，其 pod 上没有节点选择器，它仍然可以部署到他们尝试的目标区域，因为 superregion: us 被设置为项目级别节点选择器，节点被标记为 region: us-east 的节点也被标记为 superregion: us。

Pod Node Selector 准入控制器允许您将 pod 强制到与特定项目关联的节点上，并防止 pod 调度到这些节点上。

Pod Node Selector 准入控制器使用项目中的标签和在 pod 中指定的节点选择器决定 pod 放置的位置。只有 pod 中的节点选择器与项目中的标签匹配时，才会将新 pod 放置到与项目关联的节点上。

在 pod 创建后，节点选择器合并到 pod 中，以便 pod 规格包括最初包含在规格中的标签以及节点选择器中的任何新标签。以下示例说明了合并效果。

Pod Node Selector 准入控制器还允许您创建在特定项目中允许的标签列表。此列表充当 白名单，使开发人员能够知道可在项目中使用哪些标签，并让管理员更好地控制集群中的标签。

激活 Pod Node Selector 准入控制器：

如果您创建了一个没有在项目规格中指定的标签的 pod，则 pod 不会被调度到该节点上。

例如，这里的标签 env: production 不在任何项目规格中：

nodeSelector:
 "env: production"
 "infra": "fedora",
 "os": "fedora"

如果有一个没有节点选择器注解的节点，则 pod 会在该处调度。

您可以在集群中启用 pod 优先级与抢占功能。Pod 优先级指明 pod 相对于其他 pod 的重要程度，并根据这个优先级对 pod 进行排队。Pod 抢占则允许集群驱除低优先级 pod 或与之争抢，从而在合适的节点上没有可用空间时能够调度优先级较高的 pod。pod 优先级也会影响 pod 的调度顺序以及节点上资源不足驱除顺序。

要使用优先级和抢占功能，您需要创建优先级类来定义 pod 的相对权重。然后，在 pod 规格中引用优先级类，以应用这个权重来进行调度。

抢占通过调度程序配置文件中的 disablePreemption 参数来进行控制，该参数默认设置为 false。

当启用 Pod 优先级和抢占功能时，调度程序会按照优先级调度待处理 pod，并将待处理 pod 放在调度队列中优先级较低的其他待处理 pod 的前面。因此，如果达到调度要求，较高优先级的 pod 可能比低优先级的 pod 更早调度。如果 pod 无法调度，调度程序会继续调度其他较低优先级 pod。

当开发人员创建 pod 时，pod 会排入某一队列。当启用 Pod 优先级和抢占功能时，调度程序会从队列中选择一个 pod，并尝试将 pod 调度到节点上。如果调度程序无法在满足 pod 的所有指定要求的适当节点上找到空间，则会为待处理 pod 触发抢占逻辑。

当调度程序在节点上抢占一个或多个节点时，较高优先级 pod 规格的 nominatedNodeName 字段将设为该节点的名称，nodename 字段同样如此。调度程序使用 nominatedNodeName 字段来跟踪为 pod 保留的资源，同时也向用户提供与集群中抢占相关的信息。

在调度程序抢占了某一较低优先级 pod 后，调度程序会尊重该 pod 的安全终止期限。如果在调度程序等待较低优先级 pod 终止过程中另一节点变为可用，调度程序会将较高优先级 pod 调度到该节点上。因此，pod 规格的 nominatedNodeName 字段和 nodeName 字段可能会不同。

另外，如果调度程序在某一节点上抢占 pod 并正在等待终止，这时又有优先级比待处理 pod 高的 pod 需要调度，那么调度程序可以改为调度这个优先级更高的 pod。在这种情况下，调度程序会清除待处理 pod 的 nominatedNodeName，使该 pod 有资格调度到其他节点上。

抢占不一定从节点中移除所有较低优先级 pod。调度程序可以通过移除一部分较低优先级 pod 调度待处理 pod。

只有待处理 pod 能够调度到节点时，调度程序才会对这个节点考虑 pod 抢占。

Pod 优先级和抢占为 pod 分配优先级，以进行调度。调度程序将抢占（驱除）较低优先级 pod，从而调度优先级较高的 pod。

通过创建优先级类对象并使用 pod 规格中的 priorityClassName 将 pod 与优先级关联，可以应用 pod 优先级与抢占。

apiVersion: scheduling.k8s.io/v1beta1
kind: PriorityClass
metadata:
  name: high-priority 1
value: 1000000 2
globalDefault: false 3
description: "This priority class should be used for XYZ service pods only." 4

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority 1

配置集群以使用优先级与抢占功能：

您可以禁用 pod 优先级与抢占功能。

禁用该功能后，现有 pod 会保留其优先级字段，但会禁用抢占功能，而且也会忽略优先级字段。如果禁用该功能，您便无法在新 pod 中设置优先级类名称。

为集群禁用抢占：

高级调度涉及配置 pod，以便 pod 需要在特定节点上运行，或者优先在特定节点上运行。

通常，不需要高级调度，因为 OpenShift Container Platform 会自动以合理的方式放置 pod。例如，默认调度程序会尝试在节点间平均分配 pod，并考虑节点中的可用资源。但是，您可能需要更多地控制 pod 的放置位置。

如果 pod 需要位于具有更快磁盘速度（或阻止放置于该计算机上）或来自两个不同服务的 pod 以便它们进行通信的机器上，您可以使用高级调度来实现这一点。

为确保将适当的新 pod 调度到专用的一组节点上，并防止将其他新 pod 调度到这些节点上，您可以根据需要组合这些方法。

在集群中调用高级调度的方法有几种：

节点关联性 是由调度程序用来确定 pod 的可放置位置的一组规则。规则使用 节点上的自定义标签和 pod 中指定的选择器来定义。节点关联性允许 pod 为其可放置的一组 节点 指定关联性（或反关联性）。节点对放置没有控制权。

例如，您可以将 pod 配置为仅在具有特定 CPU 或位于特定可用区的节点上运行。

节点关联性规则有两种，即必要规则和偏好规则。

必须满足必要规则，pod 才能调度到节点上。偏好规则指定在满足规则时调度程序会尝试强制执行规则，但不保证一定能强制执行成功。

您可以通过 pod 规格文件配置节点关联性。您可以指定 必要规则（required rule）或 偏好规则（preferred rule） ，或同时指定两者。如果您同时指定，节点必须首先满足必要规则，然后尝试满足偏好规则。

下例中的 pod 规格包含一条规则，要求 pod 放置到具有某一标签（键为 e2e-az-NorthSouth 且值为 e2e-az-North 或 e2e-az-South）的节点上：

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity: 1
      requiredDuringSchedulingIgnoredDuringExecution: 2
        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-NorthSouth 3
            operator: In 4
            values:
            - e2e-az-North 5
            - e2e-az-South 6
  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

下例中的节点规格包含一条偏好规则，其规定优先为 pod 选择具有键为 e2e-az-EastWest 且值为 e2e-az-East 或 e2e-az-West 的节点：

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity: 1
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 1 3
        preference:
          matchExpressions:
          - key: e2e-az-EastWest 4
            operator: In 5
            values:
            - e2e-az-East 6
            - e2e-az-West 7
  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

没有明确的节点反关联性概念，但使用 NotIn 或 DoesNotExist 运算符就能实现这种行为。

以下示例演示了节点关联性。

通过 pod 关联性和 pod 反关联性，您可以指定有关如何将 pod 放置到其他 pod 的规则。规则使用 节点上的自定义标签和 pod 中指定的选择器来定义。pod 关联性/反关联性允许 pod 为其可以放置的一组 pod 指定关联性（或反关联性）。节点对放置没有控制权。

例如，您可以使用关联性规则，在服务内或相对于其他服务中的 pod 来分散或聚拢 pod。如果特定服务的 pod 的性能已知会受到另一服务的 pod 影响，那么您可以利用反关联性规则，防止前一服务的 pod 调度到与后一服务的 pod 相同的节点上。或者，您可以将服务的 pod 分散到不同的节点或可用区间，以减少关联的故障。

pod 关联性/反关联性允许您根据其他 pod 上的标签限制 pod 有资格调度到哪些节点。标签 是一个键/值对。

pod 关联性规则有两种，即必要规则和偏好规则。

必须满足必要规则，pod 才能调度到节点上。偏好规则指定在满足规则时调度程序会尝试强制执行规则，但不保证一定能强制执行成功。

您可以通过 pod 规格文件来配置 pod 的关联性/反关联性。您可以指定 必要规则（required rule）或 偏好规则（preferred rule） ，或同时指定两者。如果您同时指定，节点必须首先满足必要规则，然后尝试满足偏好规则。

以下示例显示配置了 pod 关联性和反关联性的 pod 规格。

在本例中，pod 关联性规则指明，只有当节点至少有一个已在运行且具有键 security 和值 S1 的标签的 pod 时，pod 才可以调度到这个节点上。pod 反关联性则表示，如果节点已在运行带有键 security 和值 S2.的标签的 pod，则 pod 将偏向于不调度到该节点上。

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity: 1
      requiredDuringSchedulingIgnoredDuringExecution: 2
      - labelSelector:
          matchExpressions:
          - key: security 3
            operator: In 4
            values:
            - S1 5
        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity: 1
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 100  3
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security 4
              operator: In 5
              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod