安装后配置

OpenShift Container Platform 4.5

OpenShift Container Platform 的第二天操作

Red Hat OpenShift Documentation Team

摘要

本文档提供有关 OpenShift Container Platform 安装后进行的操作说明。

第 1 章 安装后集群任务

安装 OpenShift Container Platform 后,您可以按照自己的要求进一步扩展和自定义集群。

1.1. 调整 worker 节点

如果您在部署过程中错误地定义了 worker 节点的大小,可以通过创建一个或多个新机器集来调整它们,先对它们进行扩展,并缩小原始的机器集,然后再删除它们。

1.1.1. 了解机器集和机器配置池之间的区别

MachineSet 对象描述了与云或机器供应商相关的 OpenShift Container Platform 节点。

MachineConfigPool 对象允许 MachineConfigController 组件在升级过程中定义并提供机器的状态。

MachineConfigPool 对象允许用户配置如何将升级应用到机器配置池中的 OpenShift Container Platform 节点。

NodeSelector 对象可以被一个到 MachineSet 对象的引用替换。

1.1.2. 手动扩展机器集

如果您必须在机器集中添加或移除机器实例,则可以手动扩展机器集。

这个指南与全自动的、安装程序置备的基础架构安装相关。自定义的、用户置备的基础架构安装没有机器集。

先决条件

  • 安装 OpenShift Container Platform 集群和 oc 命令行。
  • 以具有 cluster-admin 权限的用户身份登录 oc

流程

  1. 查看集群中的机器集:

    $ oc get machinesets -n openshift-machine-api

    机器集以 <clusterid>-worker-<aws-region-az> 的形式列出。

  2. 扩展机器集:

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

    或者:

    $ oc edit machineset <machineset> -n openshift-machine-api

    您可以扩展或缩减机器集。需要过几分钟以后新机器才可用。

1.1.3. 机器集删除策略

RandomNewestOldest 是三个支持的删除选项。默认值为 Random,表示在扩展机器时随机选择并删除机器。通过修改特定机器集,可以根据用例设置删除策略:

spec:
  deletePolicy: <delete_policy>
  replicas: <desired_replica_count>

无论删除策略是什么,都可通过在相关机器上添加 machine.openshift.io/cluster-api-delete-machine 注解来指定机器删除的优先级。

重要

默认情况下,OpenShift Container Platform 路由器 Pod 部署在 worker 上。由于路由器需要访问某些集群资源(包括 Web 控制台),除非先重新放置了路由器 Pod,否则请不要将 worker 机器集扩展为 0

注意

当用户需要特定的服务必须运行在特定节点,在 worker 机器集进行缩减时需要忽略这些服务时,可以使用自定义机器集。这可防止服务被中断。

1.2. 创建基础架构机器集

您可以创建一个 MachineSet 对象来仅托管基础架构组件。将特定的 Kubernetes 标签应用于这些机器,然后将基础架构组件更新为仅在那些机器上运行。这些基础架构节点不计入运行环境所需的订阅总数中。

1.2.1. OpenShift Container Platform 基础架构组件

以下基础架构工作负载不会导致 OpenShift Container Platform worker 订阅:

  • 在主控机上运行的 Kubernetes 和 OpenShift Container Platform control plane 服务
  • 默认路由器
  • 集成的容器镜像 registry
  • 集群指标集合或监控服务,包括监控用户定义的项目的组件
  • 集群聚合日志
  • 服务代理
  • Red Hat Quay
  • OpenShift Container Storage
  • Red Hat Advanced Cluster Manager

运行任何其他容器、Pod 或组件的所有节点都需要是您的订阅可涵盖的 worker 节点。

1.2.2. 创建默认的集群范围节点选择器

您可以组合使用 pod 上的默认集群范围节点选择器和节点上的标签,将集群中创建的所有 pod 限制到特定节点。

使用集群范围节点选择器时,如果您在集群中创建 pod,OpenShift Container Platform 会将默认节点选择器添加到 pod,并将该 pod 调度到具有匹配标签的节点。

您可以通过编辑调度程序 Operator 自定义资源(CR)来配置集群范围节点选择器。您可为节点、机器集或机器配置添加标签。将标签添加到机器集可确保节点或机器停机时,新节点具有标签。如果节点或机器停机,添加到节点或机器配置的标签不会保留。

注意

您可以向 pod 添加额外的键/值对。但是,您无法为一个默认的键添加不同的值。

流程

添加默认的集群范围节点选择器:

  1. 编辑调度程序 Operator CR 以添加默认的集群范围节点选择器:

    $ oc edit scheduler cluster

    使用节点选择器的调度程序 Operator CR 示例

    apiVersion: config.openshift.io/v1
    kind: Scheduler
    metadata:
      name: cluster
    ...
    
    spec:
      defaultNodeSelector: type=user-node,region=east 1
      mastersSchedulable: false
      policy:
        name: ""

    1
    使用适当的 <key>:<value> 对添加节点选择器。

    完成此更改后,请等待重新部署 openshift-kube-apiserver 项目中的 pod。这可能需要几分钟。只有重新部署 pod 后,默认的集群范围节点选择器才会生效。

  2. 通过使用机器集或直接编辑节点,为节点添加标签:

    • 在创建节点时,使用机器集向由机器集管理的节点添加标签:

      1. 运行以下命令,将标签添加到 MachineSet 对象中:

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api 1
        1
        为每个标识添加 <key>/<value> 对。

        例如:

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api
      2. 使用 oc edit 命令验证标签是否已添加到 MachineSet 对象中:

        例如:

        $ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        输出示例

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
        ...
        spec:
        ...
          template:
            metadata:
        ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node

      3. 通过缩减至 0 并扩展节点来重新部署与该机器集关联的节点:

        例如:

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
      4. 当节点就绪并可用时,使用 oc get 命令验证该标签是否已添加到节点:

        $ oc get nodes -l <key>=<value>

        例如:

        $ oc get nodes -l type=user-node

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.18.3+002a51f

    • 直接向节点添加标签:

      1. 为节点编辑 Node 对象:

        $ oc label nodes <name> <key>=<value>

        例如,若要为以下节点添加标签:

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east
      2. 使用 oc get 命令验证标签是否已添加到节点:

        $ oc get nodes -l <key>=<value>,<key>=<value>

        例如:

        $ oc get nodes -l type=user-node,region=east

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.18.3+002a51f

1.3. 将资源移到基础架构机器集

默认情况下,您的集群中已部署了某些基础架构资源。您可将它们移至您创建的基础架构机器集。

1.3.1. 移动路由器

您可以将路由器 pod 部署到不同的机器集中。默认情况下,pod 部署到 worker 节点。

先决条件

  • 在 OpenShift Container Platform 集群中配置额外的机器集。

流程

  1. 查看路由器 Operator 的 IngressController 自定义资源:

    $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

    命令输出类似于以下文本:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: 2019-04-18T12:35:39Z
      finalizers:
      - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
      generation: 1
      name: default
      namespace: openshift-ingress-operator
      resourceVersion: "11341"
      selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a
    spec: {}
    status:
      availableReplicas: 2
      conditions:
      - lastTransitionTime: 2019-04-18T12:36:15Z
        status: "True"
        type: Available
      domain: apps.<cluster>.example.com
      endpointPublishingStrategy:
        type: LoadBalancerService
      selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default
  2. 编辑 ingresscontroller 资源,并更改 nodeSelector 以使用infra 标签:

    $ oc edit ingresscontroller default -n openshift-ingress-operator

    spec 中添加使用 infra 标签的 nodeSelector 的部分,如下所示:

      spec:
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/infra: ""
  3. 确认路由器 Pod 在 infra 节点上运行。

    1. 查看路由器 Pod 列表,并记下正在运行的 Pod 的节点名称:

      $ oc get pod -n openshift-ingress -o wide

      输出示例

      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      在本例中,正在运行的 Pod 位于 ip-10-0-217-226.ec2.internal 节点上。

    2. 查看正在运行的 Pod 的节点状态:

      $ oc get node <node_name> 1
      1
      指定从 Pod 列表获得的 <node_name>

      输出示例

      NAME                          STATUS  ROLES         AGE   VERSION
      ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.18.3

      由于角色列表包含 infra,因此 Pod 在正确的节点上运行。

1.3.2. 移动默认 registry

您需要配置 registry Operator,以便将其 Pod 部署到其他节点。

先决条件

  • 在 OpenShift Container Platform 集群中配置额外的机器集。

流程

  1. 查看 config/instance 对象:

    $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

    输出示例

    apiVersion: imageregistry.operator.openshift.io/v1
    kind: Config
    metadata:
      creationTimestamp: 2019-02-05T13:52:05Z
      finalizers:
      - imageregistry.operator.openshift.io/finalizer
      generation: 1
      name: cluster
      resourceVersion: "56174"
      selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
      uid: 36fd3724-294d-11e9-a524-12ffeee2931b
    spec:
      httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
      logging: 2
      managementState: Managed
      proxy: {}
      replicas: 1
      requests:
        read: {}
        write: {}
      storage:
        s3:
          bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
          region: us-east-1
    status:
    ...

  2. 编辑 config/instance 对象:

    $ oc edit configs.imageregistry.operator.openshift.io/cluster
  3. 在对象的 spec 部分添加以下文本行:

      nodeSelector:
        node-role.kubernetes.io/infra: ""
  4. 验证 registry pod 已移至基础架构节点。

    1. 运行以下命令,以识别 registry pod 所在的节点:

      $ oc get pods -o wide -n openshift-image-registry
    2. 确认节点具有您指定的标签:

      $ oc describe node <node_name>

      查看命令输出,并确认 node-role.kubernetes.io/infra 列在 LABELS 列表中。

1.3.3. 为生产环境创建基础架构机器集

在生产环境部署中,至少部署三个机器集来容纳基础架构组件。日志记录聚合解决方案和服务网格都部署 Elasticsearch,而且 Elasticsearch 需要三个安装到不同节点上的实例。为获得高可用性,安装会将这些节点部署到不同的可用区。由于每个可用区需要不同的机器集,因此至少创建三台机器集。

1.3.3.1. 创建机器集

除了安装程序创建的机器集之外,还可创建自己的机器集来动态管理您选择的特定工作负载的机器计算资源。

先决条件

  • 部署一个 OpenShift Container Platform 集群。
  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 权限的用户身份登录 oc

流程

  1. 创建一个包含机器集自定义资源(CR)示例的新 YAML 文件,并将其命名为 <file_name>.yaml

    确保设置 <clusterID><role> 参数值。

    1. 如果不确定要为特定字段设置哪个值,您可以从集群中检查现有的机器集。

      $ oc get machinesets -n openshift-machine-api

      输出示例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
      agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1d   0         0                             55m
      agl030519-vplxk-worker-us-east-1e   0         0                             55m
      agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 检查特定机器集的值:

      $ oc get machineset <machineset_name> -n \
           openshift-machine-api -o yaml

      输出示例

      ...
      template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: agl030519-vplxk 1
              machine.openshift.io/cluster-api-machine-role: worker 2
              machine.openshift.io/cluster-api-machine-type: worker
              machine.openshift.io/cluster-api-machineset: agl030519-vplxk-worker-us-east-1a

      1
      集群 ID。
      2
      默认节点标签。
  2. 创建新的 MachineSet CR:

    $ oc create -f <file_name>.yaml
  3. 查看机器集列表:

    $ oc get machineset -n openshift-machine-api

    输出示例

    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
    agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
    agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1d   0         0                             55m
    agl030519-vplxk-worker-us-east-1e   0         0                             55m
    agl030519-vplxk-worker-us-east-1f   0         0                             55m

    当新机器集可用时,DESIREDCURRENT 的值会匹配。如果机器集不可用,请等待几分钟,然后再次运行命令。

  4. 新机器设置可用后,检查机器及其引用的节点的状态:

    $ oc describe machine <name> -n openshift-machine-api

    例如:

    $ oc describe machine agl030519-vplxk-infra-us-east-1a -n openshift-machine-api

    输出示例

    status:
      addresses:
      - address: 10.0.133.18
        type: InternalIP
      - address: ""
        type: ExternalDNS
      - address: ip-10-0-133-18.ec2.internal
        type: InternalDNS
      lastUpdated: "2019-05-03T10:38:17Z"
      nodeRef:
        kind: Node
        name: ip-10-0-133-18.ec2.internal
        uid: 71fb8d75-6d8f-11e9-9ff3-0e3f103c7cd8
      providerStatus:
        apiVersion: awsproviderconfig.openshift.io/v1beta1
        conditions:
        - lastProbeTime: "2019-05-03T10:34:31Z"
          lastTransitionTime: "2019-05-03T10:34:31Z"
          message: machine successfully created
          reason: MachineCreationSucceeded
          status: "True"
          type: MachineCreation
        instanceId: i-09ca0701454124294
        instanceState: running
        kind: AWSMachineProviderStatus

  5. 查看新节点,并确认新节点具有您指定的标签:

    $ oc get node <node_name> --show-labels

    查看命令输出,并确认 node-role.kubernetes.io/<your_label> 列在 LABELS 列表中。

注意

对机器集的任何更改都不会应用到机器集拥有的现有机器。例如,对现有机器集编辑或添加的标签不会传播到与该机器集关联的现有机器和节点。

1.3.4. 为不同云创建机器集

使用云的示例机器集。

1.3.4.1. AWS 上机器设置自定义资源的 YAML 示例

此 YAML 示例定义了一个在 us-east-1a Amazon Web Services (AWS) 区域中运行的机器集,并创建通过 node-role.kubernetes.io/<role>: "" 标记的节点。

在本例中,<infrastructureID> 是基础架构 ID 标签,该标签基于您在置备集群时设定的集群 ID,而 <role> 则是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructureID> 1
  name: <infrastructureID>-<role>-<zone> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructureID> 3
      machine.openshift.io/cluster-api-machineset: <infrastructureID>-<role>-<zone> 4
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructureID> 5
        machine.openshift.io/cluster-api-machine-role: <role> 6
        machine.openshift.io/cluster-api-machine-type: <role> 7
        machine.openshift.io/cluster-api-machineset: <infrastructureID>-<role>-<zone> 8
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: "" 9
      providerSpec:
        value:
          ami:
            id: ami-046fe691f52a953f9 10
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructureID>-worker-profile 11
          instanceType: m4.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: us-east-1a
            region: us-east-1
          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructureID>-worker-sg 12
          subnet:
            filters:
              - name: tag:Name
                values:
                  - <infrastructureID>-private-us-east-1a 13
          tags:
            - name: kubernetes.io/cluster/<infrastructureID> 14
              value: owned
          userDataSecret:
            name: worker-user-data
1 3 5 11 12 13 14
指定基于置备集群时所设置的集群 ID 的基础架构 ID。如果已安装 OpenShift CLI,您可以通过运行以下命令来获取基础架构 ID:
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 8
指定基础架构 ID、节点标签和区域。
6 7 9
指定要添加的节点标签。
10
为您的 OpenShift Container Platform 节点的 AWS 区域指定有效的 Red Hat Enterprise Linux CoreOS (RHCOS) AMI。

在 AWS 上运行的机器集支持非保证的 Spot 实例。与 AWS 上的 On-Demand 实例相比,您可以使用 Spot 实例以较低价格来节约成本。通过在机器集 YAML 文件中添加 spotMarketOptions配置 Spot 实例

1.3.4.2. Azure 上机器设置自定义资源的 YAML 示例

此 YAML 示例定义了一个在 centralus 地区(region)的 1 Microsoft Azure 区域(zone)中运行的机器集,并创建了通过 node-role.kubernetes.io/<role>: "" 标记的节点。

在本例中,<infrastructureID> 是基础架构 ID 标签,该标签基于您在置备集群时设定的集群 ID,而 <role> 则是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructureID> 1
    machine.openshift.io/cluster-api-machine-role: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructureID>-<role>-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructureID> 5
      machine.openshift.io/cluster-api-machineset: <infrastructureID>-<role>-<region> 6
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructureID> 7
        machine.openshift.io/cluster-api-machine-role: <role> 8
        machine.openshift.io/cluster-api-machine-type: <role> 9
        machine.openshift.io/cluster-api-machineset: <infrastructureID>-<role>-<region> 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/<role>: "" 11
      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructureID>-rg/providers/Microsoft.Compute/images/<infrastructureID>
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: centralus
          managedIdentity: <infrastructureID>-identity 12
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructureID>-rg 13
          sshPrivateKey: ""
          sshPublicKey: ""
          subnet: <infrastructureID>-<role>-subnet 14 15
          userDataSecret:
            name: <role>-user-data 16
          vmSize: Standard_D2s_v3
          vnet: <infrastructureID>-vnet 17
          zone: "1" 18
1 5 7 12 13 14 17
指定基于置备集群时所设置的集群 ID 的基础架构 ID。如果已安装 OpenShift CLI,您可以通过运行以下命令来获取基础架构 ID:
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 3 8 9 11 15 16
指定要添加的节点标签。
4 6 10
指定基础架构 ID、节点标签和地区。
18
指定您所在地区(region)内要放置 Machine 的区域 (zone)。确保您的地区支持您指定的区域。

1.3.4.3. GCP 上机器设置自定义资源的 YAML 示例

此 YAML 示例定义了一个在 Google Cloud Platform (GCP) 中运行的机器集,并创建通过 node-role.kubernetes.io/<role>: "" 标记的节点。

在本例中,<infrastructureID> 是基础架构 ID 标签,该标签基于您在置备集群时设定的集群 ID,而 <role> 则是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructureID> 1
  name: <infrastructureID>-w-a 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructureID> 3
      machine.openshift.io/cluster-api-machineset: <infrastructureID>-w-a 4
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructureID> 5
        machine.openshift.io/cluster-api-machine-role: <role> 6
        machine.openshift.io/cluster-api-machine-type: <role> 7
        machine.openshift.io/cluster-api-machineset: <infrastructureID>-w-a 8
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: "" 9
      providerSpec:
        value:
          apiVersion: gcpprovider.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <path_to_image> 10
            labels: null
            sizeGb: 128
            type: pd-ssd
          kind: GCPMachineProviderSpec
          machineType: n1-standard-4
          metadata:
            creationTimestamp: null
          networkInterfaces:
          - network: <infrastructureID>-network 11
            subnetwork: <infrastructureID>-<role>-subnet 12
          projectID: <project_name> 13
          region: us-central1
          serviceAccounts:
          - email: <infrastructureID>-w@<project_name>.iam.gserviceaccount.com 14 15
            scopes:
            - https://www.googleapis.com/auth/cloud-platform
          tags:
          - <infrastructureID>-<role> 16
          userDataSecret:
            name: worker-user-data
          zone: us-central1-a
1 2 3 4 5 8 11 14
指定基于置备集群时所设置的集群 ID 的基础架构 ID。如果已安装 OpenShift CLI,您可以通过运行以下命令来获取基础架构 ID:
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
12 16
指定基础架构 ID 和节点标签。
6 7 9
指定要添加的节点标签。
13 15
指定用于集群的 GCP 项目的名称。
10
指定当前机器集中使用的镜像的路径。如果已安装 OpenShift CLI,您可以通过运行以下命令来获取镜像的路径:
$ oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.disks[0].image}{"\n"}' \
    get machineset/<infrastructureID>-worker-a

1.3.4.4. vSphere 上机器设置自定义资源的 YAML 示例

此 YAML 示例定义了一个在 VMware vSphere 上运行的机器集,并创建标记为 node-role.kubernetes.io/<role>: "" 的节点。

在本例中,<infrastructure_id> 是基础架构 ID 标签,该标签基于您在置备集群时设定的集群 ID,而 <role> 则是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  creationTimestamp: null
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-<role> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 4
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
        machine.openshift.io/cluster-api-machine-role: <role> 6
        machine.openshift.io/cluster-api-machine-type: <role> 7
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 8
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/<role>: "" 9
      providerSpec:
        value:
          apiVersion: vsphereprovider.openshift.io/v1beta1
          credentialsSecret:
            name: vsphere-cloud-credentials
          diskGiB: 120
          kind: VSphereMachineProviderSpec
          memoryMiB: 8192
          metadata:
            creationTimestamp: null
          network:
            devices:
            - networkName: "<vm_network_name>" 10
          numCPUs: 4
          numCoresPerSocket: 1
          snapshot: ""
          template: <vm_template_name> 11
          userDataSecret:
            name: worker-user-data
          workspace:
            datacenter: <vcenter_datacenter_name> 12
            datastore: <vcenter_datastore_name> 13
            folder: <vcenter_vm_folder_path> 14
            resourcepool: <vsphere_resource_pool> 15
            server: <vcenter_server_ip> 16
1 3 5
指定基于置备集群时所设置的集群 ID 的基础架构 ID。如果已安装 OpenShift CLI(oc)软件包,您可以通过运行以下命令来获取基础架构 ID:
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 8
指定基础架构 ID 和节点标签。
6 7 9
指定要添加的节点标签。
10
指定要将机器集部署到的 vSphere VM 网络。
11
指定要使用的 vSphere 虚拟机模板,如 user-5ddjd-rhcos
12
指定要将机器集部署到的 vCenter Datacenter。
13
指定要部署机器集的 vCenter Datastore。
14
指定 vCenter 中 vSphere 虚拟机文件夹的路径,如 /dc1/vm/user-inst-5ddjd
15
指定虚拟机的 vSphere 资源池。
16
指定 vCenter 服务器 IP 或完全限定域名。

1.4. 创建基础架构节点

重要

请参阅为安装程序置备的基础架构环境创建基础架构机器集,或为其 master 节点由机器 API 管理的任何集群创建基础架构机器集。

集群的基础架构系统(也称为 infra 节点)的要求已被置备。安装程序只为 master 和 worker 节点提供置备。Worker 节点可以通过标记来指定为基础架构节点或应用程序(也称为 app )。

流程

  1. 向您要充当应用程序节点的 worker 节点添加标签:

    $ oc label node <node-name> node-role.kubernetes.io/app=""
  2. 向您要充当基础架构节点的 worker 节点添加标签:

    $ oc label node <node-name> node-role.kubernetes.io/infra=""
  3. 检查相关节点现在是否具有 infra 角色或 app 角色:

    $ oc get nodes
  4. 创建默认节点选择器,以便没有节点选择器的 pod 会被分配一个要部署到的节点子集中,例如,在 worker 节点上默认部署。例如,默认在 worker 节点上部署 pod 的默认 NodeSelector 应该类似于:

    defaultNodeSelector: node-role.kubernetes.io/app=
  5. 将基础架构资源移到新标记的 infra 节点中。

1.5. 创建基础架构机器

如果需要基础架构机器具有专用配置,则必须创建一个 infra 池。

流程

  1. 创建包含 worker 角色和自定义角色作为机器配置选择器的机器配置池:

    $ cat infra.mcp.yaml

    输出示例

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: infra
    spec:
      machineConfigSelector:
        matchExpressions:
          - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/infra: ""

  2. 具有 YAML 文件后,您可以创建机器配置池:

    $ oc create -f infra.mcp.yaml
  3. 检查机器配置,以确保基础架构配置成功:

    $ oc get machineconfig

    输出示例

    NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
    00-master                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
    00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
    01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
    01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
    01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
    01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
    99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
    99-master-ssh                                                                                          2.2.0             31d
    99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
    99-worker-ssh                                                                                          2.2.0             31d
    rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             23m
    rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
    rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   2.2.0             31d
    rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             17d
    rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             13d
    rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             7d3h
    rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
    rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
    rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
    rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             7d3h
    rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             17d
    rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   2.2.0             31d
    rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             13d

  4. 可选:要部署对自定义池的更改,请创建一个机器配置,该配置使用自定义池名称作为标签,如本例中的 infra:请注意,这不是必须的,在此包括仅用于指示目的。这样,您可以只应用特定于 infra 节点的任何自定义配置。

    $ cat infra.mc.yaml

    输出示例

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: infra
      name: 51-infra
    spec:
      config:
        ignition:
          version: 2.2.0
        storage:
          files:
          - contents:
              source: data:,infra
            filesystem: root
            mode: 0644
            path: /etc/infratest

  5. 应用机器配置,然后验证 infra-labeled 节点是否已使用配置文件更新:

    $ oc create -f infra.mc.yaml

1.6. 关于集群自动扩展

集群自动扩展会调整 OpenShift Container Platform 集群的大小,以满足其当前的部署需求。它使用 Kubernetes 样式的声明性参数来提供基础架构管理,而且这种管理不依赖于特定云提供商的对象。集群自动控制会在集群范围内有效,不与特定的命名空间相关联。

当由于资源不足而无法在任何当前节点上调度 Pod 时,或者在需要另一个节点来满足部署需求时,集群自动扩展会增加集群的大小。集群自动扩展不会将集群资源增加到超过您指定的限制。

重要

确保您所创建的 ClusterAutoscaler 资源定义中的 maxNodesTotal 值足够大,足以满足计算集群中可能的机器总数。此值必须包含 control plane 机器的数量以及可扩展至的机器数量。

如果相当长的一段时间内都不需要某些节点,例如集群资源使用率较低并且所有重要 Pod 都可以安置在其他节点上时,集群自动扩展会减小集群的大小。

如果节点上存在以下类型的 pod,集群自动扩展不会删除该节点:

  • 具有限制性 pod 中断预算(PDB)的 Pod。
  • 默认不在节点上运行的 Kube 系统 Pod。
  • 没有 PDB 或 PDB 限制性太强的 Kube 系统 pod。
  • 不受控制器对象支持的 Pod,如部署、副本集或有状态集。
  • 具有本地存储的 Pod。
  • 因为缺乏资源、节点选择器或关联性不兼容或有匹配的反关联性等原因而无法移至其他位置的 Pod。
  • 具有 "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" 注解的 Pod,除非同时也具有 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true” 注解。

如果配置集群自动扩展,则需要额外的使用限制:

  • 不要直接修改位于自动扩展节点组中的节点。同一节点组中的所有节点具有相同的容量和标签,并且运行相同的系统 Pod。
  • 指定适合您的 Pod 的请求。
  • 如果需要防止 Pod 被过快删除,请配置适当的 PDB。
  • 确认您的云提供商配额足够大,能够支持您配置的最大节点池。
  • 不要运行其他节点组自动扩展器,特别是云提供商提供的自动扩展器。

pod 横向自动扩展(HPA)和集群自动扩展以不同的方式修改集群资源。HPA 根据当前的 CPU 负载更改部署或副本集的副本数。如果负载增加,HPA 会创建新的副本,不论集群可用的资源量如何。如果没有足够的资源,集群自动扩展会添加资源,以便 HPA 创建的 pod 可以运行。如果负载减少,HPA 会停止一些副本。如果此操作导致某些节点利用率低下或完全为空,集群自动扩展会删除不必要的节点。

集群自动扩展会考虑 pod 优先级。如果集群没有足够的资源,则“Pod 优先级和抢占”功能可根据优先级调度 Pod,但集群自动扩展会确保集群具有运行所有 Pod 需要的资源。为满足这两个功能,集群自动扩展包含一个优先级截止函数。您可以使用此截止函数来调度“尽力而为”的 Pod,它们不会使集群自动扩展增加资源,而是仅在有可用备用资源时运行。

优先级低于截止值的 Pod 不会导致集群扩展或阻止集群缩减。系统不会添加新节点来运行 Pod,并且可能会删除运行这些 Pod 的节点来释放资源。

1.6.1. ClusterAutoscaler 资源定义

ClusterAutoscaler 资源定义显示了集群自动扩展的参数和示例值。

apiVersion: "autoscaling.openshift.io/v1"
kind: "ClusterAutoscaler"
metadata:
  name: "default"
spec:
  podPriorityThreshold: -10 1
  resourceLimits:
    maxNodesTotal: 24 2
    cores:
      min: 8 3
      max: 128 4
    memory:
      min: 4 5
      max: 256 6
    gpus:
      - type: nvidia.com/gpu 7
        min: 0 8
        max: 16 9
      - type: amd.com/gpu 10
        min: 0 11
        max: 4 12
  scaleDown: 13
    enabled: true 14
    delayAfterAdd: 10m 15
    delayAfterDelete: 5m 16
    delayAfterFailure: 30s 17
    unneededTime: 5m 18
1
指定 Pod 必须超过哪一优先级才能让机器自动扩展部署更多节点。输入一个 32 位整数值。podPriorityThreshold 值将与您分配给每个 Pod 的 PriorityClass 值进行比较。
2
指定要部署的最大节点数。这个值是集群中部署的机器总数,而不仅仅是自动扩展器控制的机器。确保这个值足够大,足以满足所有 control plane 和计算机器以及您在 MachineAutoscaler 资源中指定的副本总数。
3
指定要部署的最小内核数。
4
指定要部署的最大内核数。
5
指定集群中最小内存量(以 GiB 为单位)。
6
指定集群中的最大内存量(以 GiB 为单位)。
7 10
(可选)指定要部署的 GPU 节点的类型。只有 nvidia.com/gpuamd.com/gpu 是有效的类型。
8 11
指定要部署的最小 GPU 数。
9 12
指定要部署的最大 GPU 数。
13
在此部分中,您可以指定每个操作要等待的时长,可以使用任何有效的 ParseDuration 间隔,包括 nsusmssmh
14
指定集群自动扩展是否可以删除不必要的节点。
15
(可选)指定在最近添加节点之后要等待多久才能删除节点。如果不指定值,则使用默认值 10m
16
指定在最近删除节点之后要等待多久才能删除节点。如果不指定值,则使用默认值 10s
17
指定在发生缩减失败之后要等待多久才能删除节点。如果不指定值,则使用默认值 3m
18
指定要经过多长时间之后,不需要的节点才符合删除条件。如果不指定值,则使用默认值 10m
注意

执行扩展操作时,集群自动扩展会保持在 ClusterAutoscaler 资源定义中设置的范围,如要部署的最小和最大内核数,或集群中的内存量。但是,集群自动扩展无法将集群中的当前值修正为在这些范围内。

1.6.2. 部署集群自动扩展

要部署集群自动扩展,请创建一个 ClusterAutoscaler 资源实例。

流程

  1. ClusterAutoscaler 资源创建一个 YAML 文件,其中包含自定义的资源定义。
  2. 在集群中创建资源:

    $ oc create -f <filename>.yaml 1
    1
    <filename> 是您自定义的资源文件的名称。

1.7. 关于机器自动扩展

机器自动扩展会调整您在 OpenShift Container Platform 集群中部署的机器集中的 Machine 数量。您可以扩展默认 worker 机器集,以及您创建的其他机器集。当集群没有足够资源来支持更多部署时,机器自动扩展会增加 Machine。对 MachineAutoscaler 资源中的值(如最小或最大实例数量)的任何更改都会立即应用到目标机器设置中。

重要

您必须部署机器自动扩展才能使用集群自动扩展功能来扩展机器。集群自动扩展使用机器自动扩展集上的注解来确定可扩展的资源。如果您在没有定义机器自动扩展的情况下定义集群自动扩展,集群自动扩展永远不会扩展集群。

1.7.1. MachineAutoscaler 资源定义

MachineAutoscaler 资源定义显示了机器自动扩展器的参数和示例值。

apiVersion: "autoscaling.openshift.io/v1beta1"
kind: "MachineAutoscaler"
metadata:
  name: "worker-us-east-1a" 1
  namespace: "openshift-machine-api"
spec:
  minReplicas: 1 2
  maxReplicas: 12 3
  scaleTargetRef: 4
    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet 5
    name: worker-us-east-1a 6
1
指定机器自动扩展名称。为了更容易识别此机器自动扩展会扩展哪些机器集,请指定或注明要扩展的机器集的名称。机器集名称的格式如下: <clusterid>-<machineset>-<aws-region-az>
2
指定在机器自动扩展启动集群扩展后必须保留在指定区域中的指定类型的最小机器数量。如果在 AWS、GCP 或 Azure 中运行,则该值可设置为 0。对于其他供应商,请不要将此值设置为 0
3
指定集群自动扩展初始化集群扩展后可在指定 AWS 区域中部署的指定类型的最大机器数量。确保 ClusterAutoscaler 资源定义的 maxNodesTotal 值足够大,以便机器自动扩展器可以部署这个数量的机器。
4
在本小节中,提供用于描述要扩展的现有机器集的值。
5
kind 参数值始终为 MachineSet
6
name 值必须与现有机器集的名称匹配,如 metadata.name 参数值所示。

1.7.2. 部署机器自动扩展

要部署机器自动扩展,请创建一个 MachineAutoscaler 资源实例。

流程

  1. MachineAutoscaler 资源创建一个 YAML 文件,其中包含自定义的资源定义。
  2. 在集群中创建资源:

    $ oc create -f <filename>.yaml 1
    1
    <filename> 是您自定义的资源文件的名称。

1.8. 使用 FeatureGate 启用技术预览功能

您可以通过编辑 openshift-config 项目中的 FeatureGate 自定义资源(名为 cluster),为集群中的所有节点开启和关闭技术预览功能。

FeatureGate 可以启用以下技术预览功能:

  • RotateKubeletServerCertificate
  • SupportPodPidsLimit
重要

使用 FeatureGate 自定义资源开启技术预览功能后无法撤消并会阻止升级。

流程

为整个集群开启技术预览功能:

  1. 创建 FeatureGate 实例:

    1. 切换到 AdministrationCustom Resource Definitions 页面。
    2. Custom Resource Definitions 页面中,点击 FeatureGate
    3. Custom Resource Definitions 页面中,点击 Actions Menu 并选择 View Instances
    4. Feature Gates 页面中,点击 Create Feature Gates
    5. 用以下示例替换代码:

      apiVersion: config.openshift.io/v1
      kind: FeatureGate
      metadata:
        name: cluster
      spec: {}
    6. 点击 Create
  2. 要打开技术预览功能,请将 spec 参数更改为:

    apiVersion: config.openshift.io/v1
    kind: FeatureGate
    metadata:
      name: cluster
    spec:
      featureSet: TechPreviewNoUpgrade 1
    1
    添加 featureSet: TechPreviewNoUpgrade,以启用受 FeatureGate 影响的技术预览功能。

1.9. etcd 任务

备份 etcd、启用或禁用 etcd 加密或清除 etcd 数据。

1.9.1. 关于 etcd 加密

默认情况下,OpenShift Container Platform 不加密 etcd 数据。在集群中启用对 etcd 进行加密的功能可为数据的安全性提供额外的保护层。例如,如果 etcd 备份暴露给不应该获得这个数据的人员,它会帮助保护敏感数据。

启用 etcd 加密时,以下 OpenShift API 服务器和 Kubernetes API 服务器资源将被加密:

  • Secrets
  • 配置映射
  • Routes
  • OAuth 访问令牌
  • OAuth 授权令牌

当您启用 etcd 加密时,会创建加密密钥。这些密钥会每周进行轮转。您必须有这些密钥才能从 etcd 备份中恢复数据。

1.9.2. 启用 etcd 加密

您可以启用 etcd 加密来加密集群中的敏感资源。

警告

不建议在初始加密过程完成前备份 etcd。如果加密过程还没有完成,则备份可能只被部分加密。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 修改 APIServer 对象:

    $ oc edit apiserver
  2. encryption 项类型设置为 aescbc

    spec:
      encryption:
        type: aescbc 1
    1
    aescbc 类型表示 AES-CBC 使用 PKCS#7 padding 和 32 字节密钥来执行加密。
  3. 保存文件以使改变生效。

    加密过程开始。根据集群的大小,这个过程可能需要 20 分钟或更长的时间才能完成。

  4. 验证 etcd 加密是否成功。

    1. 查看 OpenShift API 服务器的 Encrypted 状态条件,以验证其资源是否已成功加密:

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功加密后输出显示 EncryptionCompleted

      EncryptionCompleted
      All resources encrypted: routes.route.openshift.io, oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io

      如果输出显示 EncryptionInProgress,这意味着加密仍在进行中。等待几分钟后重试。

    2. 查看 Kubernetes API 服务器的 Encrypted 状态条件,以验证其资源是否已成功加密:

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功加密后输出显示 EncryptionCompleted

      EncryptionCompleted
      All resources encrypted: secrets, configmaps

      如果输出显示 EncryptionInProgress,这意味着加密仍在进行中。等待几分钟后重试。

1.9.3. 禁用 etcd 加密

您可以在集群中禁用 etcd 数据的加密。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 修改 APIServer 对象:

    $ oc edit apiserver
  2. encryption 字段类型设置为 identity

    spec:
      encryption:
        type: identity 1
    1
    identity 类型是默认值,意味着没有执行任何加密。
  3. 保存文件以使改变生效。

    解密过程开始。根据集群的大小,这个过程可能需要 20 分钟或更长的时间才能完成。

  4. 验证 etcd 解密是否成功。

    1. 查看 OpenShift API 服务器的 Encrypted 状态条件,以验证其资源是否已成功解密:

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功解密后输出显示 DecryptionCompleted

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      如果输出显示 DecryptionInProgress,这意味着解密仍在进行中。等待几分钟后重试。

    2. 查看 Kubernetes API 服务器的 Encrypted 状态条件,以验证其资源是否已成功解密:

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功解密后输出显示 DecryptionCompleted

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      如果输出显示 DecryptionInProgress,这意味着解密仍在进行中。等待几分钟后重试。

1.9.4. 备份 etcd 数据

按照以下步骤,通过创建 etcd 快照并备份静态 pod 的资源来备份 etcd 数据。这个备份可以被保存,并在以后需要时使用它来恢复 etcd 数据。

重要

只保存单一 master 主机的备份。您不需要对集群中的每个 master 主机都进行备份。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您已检查是否启用了集群范围代理。

    提示

    您可以通过查看 oc get proxy cluster -o yaml 的输出来检查代理是否已启用。如果 httpProxyhttpsProxynoProxy 字段设置了值,则会启用代理。

流程

  1. 为 master 节点启动一个 debug 会话:

    $ oc debug node/<node_name>
  2. 将您的根目录改为主机:

    sh-4.2# chroot /host
  3. 如果启用了集群范围的代理,请确定已导出了 NO_PROXYHTTP_PROXYHTTPS_PROXY 环境变量。
  4. 运行 cluster-backup.sh 脚本,输入保存备份的位置。

    sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

    脚本输出示例

    1bf371f1b5a483927cd01bb593b0e12cff406eb8d7d0acf4ab079c36a0abd3f7
    etcdctl version: 3.3.18
    API version: 3.3
    found latest kube-apiserver-pod: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-7
    found latest kube-controller-manager-pod: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-8
    found latest kube-scheduler-pod: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
    found latest etcd-pod: /etc/kubernetes/static-pod-resources/etcd-pod-2
    Snapshot saved at /home/core/assets/backup/snapshot_2020-03-18_220218.db
    snapshot db and kube resources are successfully saved to /home/core/assets/backup

    在这个示例中,在 master 主机上的 /home/core/assets/backup/ 目录中创建了两个文件:

    • snapshot_<datetimestamp>.db:这个文件是 etcd 快照。
    • static_kuberesources_<datetimestamp>.tar.gz:此文件包含静态 pod 的资源。如果启用了 etcd 加密,它也包含 etcd 快照的加密密钥。

      注意

      如果启用了 etcd 加密,建议出于安全考虑,将第二个文件与 etcd 快照分开保存。但是,需要这个文件才能从 etcd 快照中进行恢复。

      请记住,etcd 仅对值进行加密,而不对键进行加密。这意味着资源类型、命名空间和对象名称是不加密的。

1.9.5. 分离 etcd 数据

在 etcd 历史记录压缩和其他事件后,必须定期执行手动清除碎片以便重新声明磁盘空间。

历史压缩将自动每五分钟执行一次,并在后端数据库中造成混乱。此碎片空间可供 etcd 使用,但主机文件系统不可用。您必须对碎片 etcd 进行碎片清除,才能使这个空间可供主机文件系统使用。

因为 etcd 将数据写入磁盘,所以其性能主要取决于磁盘性能。根据您的集群的具体情况,考虑每个月清理一次 etcd 碎片,或每个月清理两次。您还可以监控 etcd_db_total_size_in_bytes 指标,以确定是否需要进行碎片操作。

警告

分离 etcd 是一个阻止性操作。在进行碎片处理完成前,etcd 成员不会响应。因此,在每个下一个 pod 要进行碎片清理前,至少等待一分钟,以便集群可以恢复正常工作。

按照以下步骤对每个 etcd 成员上的 etcd 数据进行碎片处理。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 确定哪个 etcd 成员是领导成员,因为领导会进行最后的碎片处理。

    1. 获取 etcd pod 列表:

      $ oc get pods -n openshift-etcd -o wide | grep etcd

      输出示例

      etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
      etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
      etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

    2. 选择 pod 并运行以下命令来确定哪个 etcd 成员是领导:

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.us-west-1.compute.internal etcdctl endpoint status --cluster -w table

      输出示例

      Defaulting container name to etcdctl.
      Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      基于此输出的 IS LEADER 列,https://10.0.199.170:2379 端点是领导。与上一步输出匹配此端点,领导的 pod 名称为 etcd-ip-10-0-199-170.example.redhat.com

  2. 清理 etcd 成员。

    1. 连接到正在运行的 etcd 容器,传递 不是 领导的 pod 的名称:

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
    2. 取消设置 ETCDCTL_ENDPOINTS 环境变量:

      sh-4.4# unset ETCDCTL_ENDPOINTS
    3. 清理 etcd 成员:

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag

      输出示例

      Finished defragmenting etcd member[https://localhost:2379]

      如果发生超时错误,增加 --command-timeout 的值,直到命令成功为止。

    4. 验证数据库大小是否已缩小:

      sh-4.4# etcdctl endpoint status -w table --cluster

      输出示例

      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 1
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      本例显示这个 etcd 成员的数据库大小现在为 41 MB,而起始大小为 104 MB。

    5. 重复这些步骤以连接到其他 etcd 成员并进行碎片处理。最后才对领导进行碎片清除。

      至少要在碎片处理操作之间等待一分钟,以便 etcd pod 可以恢复。在 etcd pod 恢复前,etcd 成员不会响应。

  3. 如果因为超过空间配额而触发任何 NOSPACE 警告,请清除它们。

    1. 检查是否有 NOSPACE 警告:

      sh-4.4# etcdctl alarm list

      输出示例

      memberID:12345678912345678912 alarm:NOSPACE

    2. 清除警告:

      sh-4.4# etcdctl alarm disarm

1.9.6. 恢复到一个以前的集群状态

您可以使用已保存的 etcd 备份恢复到先前的集群状态。您可以使用 etcd 备份来恢复单个 control plane 主机。然后,etcd cluster Operator 会处理剩余的 master 主机的扩展。

重要

恢复集群时,必须使用同一 z-stream 发行版本中获取的 etcd 备份。例如,OpenShift Container Platform 4.5.2 集群必须使用从 4.5.2 中获得的 etcd 备份。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 具有对 master 主机的 SSH 访问权限。
  • 包含从同一备份中获取的 etcd 快照和静态 pod 资源的备份目录。该目录中的文件名必须采用以下格式: snapshot_<datetimestamp>.db 和 static_kuberesources_<datetimestamp>.tar.gz

流程

  1. 选择一个要用作恢复主机的 control plane 主机。这是您要在其中运行恢复操作的主机。
  2. 建立到每个 control plane 节点(包括恢复主机)的 SSH 连接。

    恢复过程启动后,Kubernetes API 服务器将无法访问,因此您无法访问 control plane 节点。因此,建议在一个单独的终端中建立到每个control plane 主机的 SSH 连接。

    重要

    如果没有完成这个步骤,将无法访问 master 主机来完成恢复过程,您将无法从这个状态恢复集群。

  3. 将 etcd 备份目录复制复制到恢复 control plane 主机上。

    此流程假设您将 backup 目录(其中包含 etcd 快照和静态 pod 资源)复制到恢复 control plane 主机的 /home/core/ 目录中。

  4. 在所有其他 control plane 节点上停止静态 pod。

    注意

    不需要手动停止恢复主机上的 pod。恢复脚本将停止恢复主机上的 pod。

    1. 访问不是恢复主机的 control plane 主机。
    2. 将现有 etcd pod 文件从 Kubelet 清单目录中移出:

      [core@ip-10-0-154-194 ~]$ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
    3. 验证 etcd pod 是否已停止。

      [core@ip-10-0-154-194 ~]$ sudo crictl ps | grep etcd | grep -v operator

      命令输出应该为空。如果它不是空的,请等待几分钟后再重新检查。

    4. 将现有 Kubernetes API 服务器 pod 文件移出 kubelet 清单目录中:

      [core@ip-10-0-154-194 ~]$ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
    5. 验证 Kubernetes API 服务器 pod 是否已停止。

      [core@ip-10-0-154-194 ~]$ sudo crictl ps | grep kube-apiserver | grep -v operator

      命令输出应该为空。如果它不是空的,请等待几分钟后再重新检查。

    6. 将 etcd 数据目录移到不同的位置:

      [core@ip-10-0-154-194 ~]$ sudo mv /var/lib/etcd/ /tmp
    7. 在其他不是恢复主机的 master 主机上重复这个步骤。
  5. 访问恢复 control plane 主机。
  6. 如果启用了集群范围的代理,请确定已导出了 NO_PROXYHTTP_PROXYHTTPS_PROXY 环境变量。

    提示

    您可以通过查看 oc get proxy cluster -o yaml 的输出来检查代理是否已启用。如果 httpProxyhttpsProxynoProxy 字段设置了值,则会启用代理。

  7. 在恢复 control plane 主机上运行恢复脚本,提供到 etcd 备份目录的路径:

    [core@ip-10-0-143-125 ~]$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup

    脚本输出示例

    ...stopping kube-scheduler-pod.yaml
    ...stopping kube-controller-manager-pod.yaml
    ...stopping etcd-pod.yaml
    ...stopping kube-apiserver-pod.yaml
    Waiting for container etcd to stop
    .complete
    Waiting for container etcdctl to stop
    .............................complete
    Waiting for container etcd-metrics to stop
    complete
    Waiting for container kube-controller-manager to stop
    complete
    Waiting for container kube-apiserver to stop
    ..........................................................................................complete
    Waiting for container kube-scheduler to stop
    complete
    Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
    starting restore-etcd static pod
    starting kube-apiserver-pod.yaml
    static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
    starting kube-controller-manager-pod.yaml
    static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
    starting kube-scheduler-pod.yaml
    static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

  8. 在所有 master 主机上重启 kubelet 服务。

    1. 在恢复主机中运行以下命令:

      [core@ip-10-0-143-125 ~]$ sudo systemctl restart kubelet.service
    2. 在所有其他 master 主机上重复此步骤。
  9. 确认单个成员 control plane 已被成功启动。

    1. 从恢复主机上,验证 etcd 容器是否正在运行。

      [core@ip-10-0-143-125 ~]$ sudo crictl ps | grep etcd | grep -v operator

      输出示例

      3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

    2. 从恢复主机上,验证 etcd pod 是否正在运行。

      [core@ip-10-0-143-125 ~]$ oc get pods -n openshift-etcd | grep etcd
      注意

      如果您试图在运行这个命令前运行 oc login 并接收以下错误,请等待一些时间以便身份验证控制器启动并再次尝试。

      Unable to connect to the server: EOF

      输出示例

      NAME                                             READY   STATUS      RESTARTS   AGE
      etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

      如果状态是 Pending,或者输出中列出了多个正在运行的 etcd pod,请等待几分钟,然后再次检查。

  10. 强制 etcd 重新部署。

    在一个终端中使用 cluster-admin 用户连接到集群,运行以下命令:

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
    1 1
    forceRedeploymentReason 值必须是唯一的,这就是为什么附加时间戳的原因。

    当 etcd cluster Operator 执行重新部署时,现有节点开始使用与初始 bootstrap 扩展类似的新 pod。

  11. 验证所有节点是否已更新至最新的修订版本。

    在一个终端中使用 cluster-admin 用户连接到集群,运行以下命令:

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    查看 etcd 的NodeInstallerProgressing 状态条件,以验证所有节点是否处于最新的修订。在更新成功后,输出会显示 AllNodesAtLatestRevision

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1
    1
    在本例中,最新的修订版本号是 7

    如果输出包含多个修订号,如 2 个节点为修订版本 6;1 个节点为修订版本 7,这意味着更新仍在进行中。等待几分钟后重试。

  12. 在重新部署 etcd 后,为 control plane 强制进行新的 rollout。由于 kubelet 使用内部负载平衡器连接到 API 服务器,因此 Kubernetes API 将在其他节点上重新安装自己。

    在一个终端中使用 cluster-admin 用户连接到集群,运行以下命令。

    1. 更新 kubeapiserver:

      $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

      验证所有节点是否已更新至最新的修订版本。

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      查看 NodeInstallerProgressing 状态条件,以验证所有节点是否处于最新版本。在更新成功后,输出会显示 AllNodesAtLatestRevision

      AllNodesAtLatestRevision
      3 nodes are at revision 7 1
      1
      在本例中,最新的修订版本号是 7

      如果输出包含多个修订号,如 2 个节点为修订版本 6;1 个节点为修订版本 7,这意味着更新仍在进行中。等待几分钟后重试。

    2. 更新 kubecontrollermanager:

      $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

      验证所有节点是否已更新至最新的修订版本。

      $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      查看 NodeInstallerProgressing 状态条件,以验证所有节点是否处于最新版本。在更新成功后,输出会显示 AllNodesAtLatestRevision

      AllNodesAtLatestRevision
      3 nodes are at revision 7 1
      1
      在本例中,最新的修订版本号是 7

      如果输出包含多个修订号,如 2 个节点为修订版本 6;1 个节点为修订版本 7,这意味着更新仍在进行中。等待几分钟后重试。

    3. 更新 kubescheduler

      $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

      验证所有节点是否已更新至最新的修订版本。

      $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      查看 NodeInstallerProgressing 状态条件,以验证所有节点是否处于最新版本。在更新成功后,输出会显示 AllNodesAtLatestRevision

      AllNodesAtLatestRevision
      3 nodes are at revision 7 1
      1
      在本例中,最新的修订版本号是 7

      如果输出包含多个修订号,如 2 个节点为修订版本 6;1 个节点为修订版本 7,这意味着更新仍在进行中。等待几分钟后重试。

  13. 验证所有 master 主机已启动并加入集群。

    在一个终端中使用 cluster-admin 用户连接到集群,运行以下命令:

    $ oc get pods -n openshift-etcd | grep etcd

    输出示例

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

请注意,在完成这个过程后,可能需要几分钟才能恢复所有服务。例如,在重启 OAuth 服务器 pod 前,使用 oc login 进行身份验证可能无法立即正常工作。

1.10. Pod 中断预算

了解并配置 pod 中断预算。

1.10.1. 了解如何使用 pod 中断预算来指定必须在线的 pod 数量

pod 中断预算Kubernetes API 的一部分,可以像其他对象类型一样通过 oc 命令进行管理。它们允许在操作过程中指定 pod 的安全约束,比如为维护而清空节点。

PodDisruptionBudget 是一个 API 对象,用于指定在某一时间必须保持在线的副本的最小数量或百分比。在项目中进行这些设置对节点维护(比如缩减集群或升级集群)有益,而且仅在自愿驱除(而非节点失败)时遵从这些设置。

PodDisruptionBudget 对象的配置由以下关键部分组成:

  • 标签选择器,即一组 pod 的标签查询。
  • 可用性级别,用来指定必须同时可用的最少 pod 的数量。

    • minAvailable 是必须始终可用的 pod 的数量,即使在中断期间也是如此。
    • maxUnavailable 是中断期间可以无法使用的 pod 的数量。
注意

允许 maxUnavailable0%0minAvailable100% 或等于副本数,但这样设置可能会阻止节点排空操作。

您可以使用以下命令来检查所有项目的 pod 中断预算:

$ oc get poddisruptionbudget --all-namespaces

输出示例

NAMESPACE         NAME          MIN-AVAILABLE   SELECTOR
another-project   another-pdb   4               bar=foo
test-project      my-pdb        2               foo=bar

如果系统中至少有 minAvailable 个 pod 正在运行,则 PodDisruptionBudget 被视为是健康的。超过这一限制的每个 pod 都可被驱除。

注意

根据您的 pod 优先级与抢占设置,可能会无视 pod 中断预算要求而移除较低优先级 pod。

1.10.2. 使用 pod 中断预算指定必须在线的 pod 数量

您可以使用 PodDisruptionBudget 对象来指定某一时间必须保持在线的副本的最小数量或百分比。

流程

配置 pod 中断预算:

  1. 使用类似以下示例的对象定义来创建 YAML 文件:

    apiVersion: policy/v1beta1 1
    kind: PodDisruptionBudget
    metadata:
      name: my-pdb
    spec:
      minAvailable: 2  2
      selector:  3
        matchLabels:
          foo: bar
    1
    PodDisruptionBudgetpolicy/v1beta1 API 组的一部分。
    2
    必须同时可用的最小 pod 数量。这可以是整数,也可以是指定百分比的字符串(如 20%)。
    3
    对一组资源进行的标签查询。matchLabelsmatchExpressions 的结果在逻辑上是联合的。

    或者:

    apiVersion: policy/v1beta1 1
    kind: PodDisruptionBudget
    metadata:
      name: my-pdb
    spec:
      maxUnavailable: 25% 2
      selector: 3
        matchLabels:
          foo: bar
    1
    PodDisruptionBudgetpolicy/v1beta1 API 组的一部分。
    2
    同时不能使用的最多的 pod 数量。这可以是整数,也可以是指定百分比的字符串(如 20%)。
    3
    对一组资源进行的标签查询。matchLabelsmatchExpressions 的结果在逻辑上是联合的。
  2. 运行以下命令,将对象添加到项目中:

    $ oc create -f </path/to/file> -n <project_name>

1.11. 删除云供应商凭证

在 Amazon Web Services(AWS)上安装了 OpenShift Container Platform 集群后,您可以从集群中的 kube-system 命名空间中删除管理员级别的凭证 secret。只有在进行更改时(需要提高的权限,如升级),才需要管理员级别的凭证。

注意

在非 z-stream 升级前,您必须使用管理员级别的凭证重新恢复凭证 secret。如果没有凭证,则可能无法进行升级。

先决条件

  • 集群安装在支持从 CCO 中删除云凭证的平台上。

流程

  1. 在 web 控制台的 Administrator 视角中,导航到 WorkloadsSecrets
  2. Secrets 页面的表中,找到 AWS 的 aws-creds root secret。

    平台Secret 名

    AWS

    aws-creds

  3. 点击与 secret 相同的行 kebab 中的 Options 菜单,然后选择 Delete Secret

第 2 章 安装后的节点任务

安装 OpenShift Container Platform 后,您可以通过某些节点任务进一步根据要求扩展和自定义集群。

2.1. 在 OpenShift Container Platform 集群中添加 RHEL 计算机器

理解并使用 RHEL 计算节点。

2.1.1. 关于在集群中添加 RHEL 计算节点

在 OpenShift Container Platform 4.5 中,如果使用用户置备的基础架构安装,您可以选择将 Red Hat Enterprise Linux (RHEL) 机器用作集群中的计算机器(也称为 worker)。集群中的 control plane 或主控机器(master)必须使用 Red Hat Enterprise Linux CoreOS (RHCOS)。

与所有使用用户置备的基础架构的安装一样,如果选择在集群中使用 RHEL 计算机器,您将需要负责所有操作系统生命周期的管理和维护任务,包括执行系统更新、应用补丁以及完成所有其他必要的任务。

重要

由于从集群中的机器上删除 OpenShift Container Platform 需要破坏操作系统,因此您必须对添加到集群中的所有 RHEL 机器使用专用的硬件。

重要

添加到 OpenShift Container Platform 集群的所有 RHEL 机器上都禁用内存交换功能。您无法在这些机器上启用交换内存。

您必须在初始化 control plane 之后将所有 RHEL 计算机器添加到集群。

2.1.2. RHEL 计算节点的系统要求

OpenShift Container Platform 环境中的 Red Hat Enterprise Linux (RHEL) 计算机器(也称为 worker)主机必须满足以下最低硬件规格和系统级别要求。

  • 您的红帽帐户必须具有有效的 OpenShift Container Platform 订阅。如果没有,请与您的销售代表联系以了解更多信息。
  • 生产环境必须提供能支持您的预期工作负载的计算机器。作为集群管理员,您必须计算预期的工作负载,再加上大约 10% 的开销。对于生产环境,请分配足够的资源,以防止节点主机故障影响您的最大容量。
  • 所有系统都必须满足以下硬件要求:

    • 物理或虚拟系统,或在公有或私有 IaaS 上运行的实例。
    • 基础操作系统:使用 "Minimal" 安装选项的 RHEL 7.7-7.8

      重要

      OpenShift Container Platform 4.5 仅支持 RHEL 7.7-7.8。您不能将计算机器升级到 RHEL 8。

    • 如果以 FIPS 模式部署 OpenShift Container Platform,则需要在 RHEL 机器上启用 FIPS,然后才能引导它。请参阅 RHEL 7 文档中的启用 FIPS 模式
    • NetworkManager 1.0 或更高版本。
    • 1 个 vCPU。
    • 最小 8 GB RAM。
    • 最小15 GB 硬盘空间,用于包含 /var/ 的文件系统。
    • 最小1 GB 硬盘空间,用于包含 /usr/local/bin/ 的文件系统。
    • 最小1 GB 硬盘空间,用于包含系统临时目录的文件系统。系统的临时目录根据 Python 标准库中 tempfile 模块中定义的规则确定。
  • 每个系统都必须满足您的系统提供商的任何其他要求。例如,如果在 VMware vSphere 上安装了集群,必须根据其存储准则配置磁盘,而且必须设置 disk.enableUUID=true 属性。
  • 每个系统都必须能够使用可解析的主机名访问集群的 API 端点。任何现有的网络安全访问控制都必须允许系统访问集群的 API 服务端点。

2.1.2.1. 证书签名请求管理

在使用您置备的基础架构时,集群只能有限地访问自动机器管理,因此您必须提供一种在安装后批准集群证书签名请求 (CSR) 的机制。kube-controller-manager 只能批准 kubelet 客户端 CSR。machine-approver 无法保证使用 kubelet 凭证请求的提供证书的有效性,因为它不能确认是正确的机器发出了该请求。您必须决定并实施一种方法,以验证 kubelet 提供证书请求的有效性并进行批准。

2.1.3. 准备机器以运行 Playbook

在将使用 Red Hat Enterprise Linux 作为操作系统的计算机器添加到 OpenShift Container Platform 4.5 集群之前,必须准备一台机器来运行 playbook。这台机器不是集群的一部分,但必须能够访问集群。

先决条件

  • 在运行 playbook 的机器上安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 权限的用户身份登录。

流程

  1. 确保机器上具有集群的 kubeconfig 文件,以及用于安装集群的安装程序。若要实现这一目标,一种方法是使用安装集群时所用的同一台机器。
  2. 配置机器,以访问您计划用作计算机器的所有 RHEL 主机。您可以使用公司允许的任何方法,包括使用 SSH 代理或 VPN 的堡垒主机。
  3. 在运行 playbook 的机器上配置一个用户,该用户对所有 RHEL 主机具有 SSH 访问权限。

    重要

    如果使用基于 SSH 密钥的身份验证,您必须使用 SSH 代理来管理密钥。

  4. 如果还没有这样做,请使用 RHSM 注册机器,并为它附加一个带有 OpenShift 订阅的池:

    1. 使用 RHSM 注册机器:

      # subscription-manager register --username=<user_name> --password=<password>
    2. 从 RHSM 获取最新的订阅数据:

      # subscription-manager refresh
    3. 列出可用的订阅:

      # subscription-manager list --available --matches '*OpenShift*'
    4. 在上一命令的输出中,找到 OpenShift Container Platform 订阅的池 ID 并附加该池:

      # subscription-manager attach --pool=<pool_id>
  5. 启用 OpenShift Container Platform 4.5 所需的存储库:

    # subscription-manager repos \
        --enable="rhel-7-server-rpms" \
        --enable="rhel-7-server-extras-rpms" \
        --enable="rhel-7-server-ansible-2.9-rpms" \
        --enable="rhel-7-server-ose-4.5-rpms"
  6. 安装所需的软件包,包括 openshift-ansible:

    # yum install openshift-ansible openshift-clients jq

    openshift-ansible 软件包提供了安装实用程序,并且会拉取将 RHEL 计算节点添加到集群所需要的其他软件包,如 Ansible、playbook 和相关的配置文件。openshift-clients 提供 oc CLI,jq 软件包则可改善命令行中 JSON 输出的显示。

2.1.4. 准备 RHEL 计算节点

在将 Red Hat Enterprise Linux (RHEL) 机器添加到 OpenShift Container Platform 集群之前,您必须将每台主机注册到 Red Hat Subscription Manager (RHSM),为其附加有效的 OpenShift Container Platform 订阅,并且启用所需的存储库。

  1. 在每一主机上进行 RHSM 注册:

    # subscription-manager register --username=<user_name> --password=<password>
  2. 从 RHSM 获取最新的订阅数据:

    # subscription-manager refresh
  3. 列出可用的订阅:

    # subscription-manager list --available --matches '*OpenShift*'
  4. 在上一命令的输出中,找到 OpenShift Container Platform 订阅的池 ID 并附加该池:

    # subscription-manager attach --pool=<pool_id>
  5. 禁用所有 yum 存储库:

    1. 禁用所有已启用的 RHSM 存储库:

      # subscription-manager repos --disable="*"
    2. 列出剩余的 yum 存储库,并记录它们在 repo id 下的名称(若有):

      # yum repolist
    3. 使用 yum-config-manager 禁用剩余的 yum 存储库:

      # yum-config-manager --disable <repo_id>

      或者,禁用所有存储库:

      # yum-config-manager --disable \*

      请注意,有大量可用存储库时可能需要花费几分钟

  6. 仅启用 OpenShift Container Platform 4.5 需要的存储库:

    # subscription-manager repos \
        --enable="rhel-7-server-rpms" \
        --enable="rhel-7-server-extras-rpms" \
        --enable="rhel-7-server-ose-4.5-rpms"
  7. 停止并禁用主机上的防火墙:

    # systemctl disable --now firewalld.service
    注意

    请不要在以后启用防火墙。如果这样做,则无法访问 worker 上的 OpenShift Container Platform 日志。

2.1.5. 在集群中添加 RHEL 计算机器

您可以将使用 Red Hat Enterprise Linux 作为操作系统的计算机器添加到 OpenShift Container Platform 4.5 集群中。

先决条件

  • 运行 playbook 的机器上已安装必需的软件包并且执行了必要的配置。
  • RHEL 主机已做好安装准备。

流程

在为运行 playbook 而准备的机器上执行以下步骤:

  1. 创建一个名为 /<path>/inventory/hosts 的 Ansible 清单文件,以定义您的计算机器主机和必要的变量:

    [all:vars]
    ansible_user=root 1
    #ansible_become=True 2
    
    openshift_kubeconfig_path="~/.kube/config" 3
    
    [new_workers] 4
    mycluster-rhel7-0.example.com
    mycluster-rhel7-1.example.com
    1
    指定要在远程计算机器上运行 Ansible 任务的用户名。
    2
    如果不将 root 指定为 ansible_user,您必须将 ansible_become 设置为 True,并为该用户分配 sudo 权限。
    3
    指定集群的 kubeconfig 文件的路径和文件名。
    4
    列出要添加到集群中的每台 RHEL 机器。必须为每个主机提供完全限定域名。此名称是集群用来访问机器的主机名,因此请设置用于访问该机器的正确公用或私有名称。
  2. 进入到 Ansible playbook 目录:

    $ cd /usr/share/ansible/openshift-ansible
  3. 运行 playbook:

    $ ansible-playbook -i /<path>/inventory/hosts playbooks/scaleup.yml 1
    1
    对于<path> ,指定您创建的Ansible库存文件的路径。

2.1.6. Ansible hosts 文件的必要参数

在将 Red Hat Enterprise Linux (RHEL) 计算机器添加到集群之前,必须在 Ansible hosts 文件中定义以下参数。

参数描述

ansible_user

能够以免密码方式进行 SSH 身份验证的 SSH 用户。如果使用基于 SSH 密钥的身份验证,则必须使用 SSH 代理来管理密钥。

系统上的用户名。默认值为 root

ansible_become

如果 ansible_user 的值不是 root,您必须将 ansible_become 设置为 True,并且您指定为 ansible_user 的用户必须配置有免密码 sudo 访问权限。

True。如果值不是 True,请不要指定和定义此参数。

openshift_kubeconfig_path

指定包含集群的 kubeconfig 文件的本地目录的路径和文件名。

配置文件的路径和名称。

2.1.7. 可选:从集群中删除 RHCOS 计算机器

将 Red Hat Enterprise Linux(RHEL)计算机器添加到集群后,您可以选择性地删除 Red Hat Enterprise Linux CoreOS(RHCOS)计算机器来释放资源。

先决条件

  • 您已将 RHEL 计算机器添加到集群中。

流程

  1. 查看机器列表并记录 RHCOS 计算机器的节点名称:

    $ oc get nodes -o wide
  2. 对于每一台 RHCOS 计算机器,删除其节点:

    1. 通过运行 oc adm cordon 命令,将节点标记为不可调度:

      $ oc adm cordon <node_name> 1
      1
      指定其中一台 RHCOS 计算机器的节点名称。
    2. 清空节点中的所有 Pod:

      $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets 1
      1
      指定您隔离的 RHCOS 计算机器的节点名称。
    3. 删除节点:

      $ oc delete nodes <node_name> 1
      1
      指定您清空的 RHCOS 计算机器的节点名称。
  3. 查看计算机器的列表,以确保仅保留 RHEL 节点:

    $ oc get nodes -o wide
  4. 从集群的计算机器的负载均衡器中删除 RHCOS 机器。您可以删除虚拟机或重新制作 RHCOS 计算机器物理硬件的镜像。

2.2. 将 RHCOS 计算机器添加到 OpenShift Container Platform 集群

您可以在裸机上的 OpenShift Container Platform 集群中添加更多 Red Hat Enterprise Linux CoreOS(RHCOS)计算机器。

在将更多计算机器添加到在裸机基础架构上安装的集群之前,必须先创建 RHCOS 机器供其使用。您可以使用 ISO 镜像或网络 PXE 引导来创建机器。

2.2.1. 先决条件

  • 您在裸机上安装了集群。
  • 您有用来创建集群的安装介质和 Red Hat Enterprise Linux CoreOS(RHCOS)镜像。如果您没有这些文件,您必须按照 安装过程的说明获得这些文件。

2.2.2. 使用 ISO 镜像创建更多 RHCOS 机器

您可以使用 ISO 镜像为裸机集群创建更多 Red Hat Enterprise Linux CoreOS(RHCOS)计算机器,以创建机器。

先决条件

  • 获取集群计算机器的 Ignition 配置文件的 URL。在安装过程中将该文件上传到 HTTP 服务器。
  • 获取您在集群安装过程中上传到 HTTP 服务器的 BIOS 或 UEFI RHCOS 镜像文件的 URL。

流程

  1. 使用 ISO 文件在更多计算机器上安装 RHCOS。在安装集群前,使用创建机器时使用的相同方法:

    • 将 ISO 镜像刻录到磁盘并直接启动。
    • 在 LOM 接口中使用 ISO 重定向。
  2. 实例启动后,按 TABE 键编辑内核命令行。
  3. 将参数添加到内核命令行:

    coreos.inst=yes
    coreos.inst.install_dev=sda 1
    coreos.inst.image_url=<bare_metal_image_URL> 2
    coreos.inst.ignition_url=http://example.com/worker.ign 3
    1
    指定要安装到的系统块设备。
    2
    指定您上传到服务器的 UEFI 或 BIOS 镜像的 URL。
    3
    指定计算 Ignition 配置文件的 URL。
  4. Enter 键完成安装。安装 RHCOS 后,系统会重启。系统重启后,它会应用您指定的 Ignition 配置文件。
  5. 继续为集群创建更多计算机器。

2.2.3. 通过 PXE 或 iPXE 启动来创建更多 RHCOS 机器

您可以使用 PXE 或 iPXE 引导为裸机集群创建更多 Red Hat Enterprise Linux CoreOS(RHCOS)计算机器。

先决条件

  • 获取集群计算机器的 Ignition 配置文件的 URL。在安装过程中将该文件上传到 HTTP 服务器。
  • 获取您在集群安装过程中上传到 HTTP 服务器的 RHCOS ISO 镜像、压缩的裸机 BIOS、kernelinitramfs 文件的 URL。
  • 您可以访问在安装过程中为 OpenShift Container Platform 集群创建机器时使用的 PXE 引导基础架构。机器必须在安装 RHCOS 后从本地磁盘启动。
  • 如果使用 UEFI,您可以访问在 OpenShift Container Platform 安装过程中修改的 grub.conf 文件。

流程

  1. 确认 RHCOS 镜像的 PXE 或 iPXE 安装正确。

    • 对于 PXE:

      DEFAULT pxeboot
      TIMEOUT 20
      PROMPT 0
      LABEL pxeboot
          KERNEL http://<HTTP_server>/rhcos-<version>-installer-kernel-<architecture> 1
          APPEND ip=dhcp rd.neednet=1 initrd=http://<HTTP_server>/rhcos-<version>-installer-initramfs.<architecture>.img coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.image_url=http://<HTTP_server>/rhcos-<version>-metal.<architecture>.raw.gz coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 2 3
      1
      指定上传到 HTTP 服务器的 kernel 文件位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。initrd 参数值是 initramfs 文件的位置,coreos.inst.image_url 参数值是压缩的裸机 RAW 镜像的位置,coreos.inst.ignition_url 参数值则是 worker Ignition 配置文件的位置。
      注意

      这个配置不会在使用图形控制台的机器上启用串口控制台访问。要配置不同的控制台,请在 APPEND 行中添加一个或多个 console= 参数。例如,添加 console=tty0 console=ttyS0 将第一个 PC 串口设置为主控制台,图形控制台作为二级控制台。如需更多信息,请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和(或)控制台?

    • 对于 iPXE:

      kernel http://<HTTP_server>/rhcos-<version>-installer-kernel-<architecture> ip=dhcp rd.neednet=1 initrd=http://<HTTP_server>/rhcos-<version>-installer-initramfs.<architecture>.img coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.image_url=http://<HTTP_server>/rhcos-<version>-metal.<arhcitectutre>.raw.gz coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
      initrd http://<HTTP_server>/rhcos-<version>-installer-initramfs.<architecture>.img 3
      boot
      1
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。kernel 参数值是 kernel 文件的位置,initrd 参数值是 initramfs 文件的位置,coreos.inst.image_url 参数值是压缩的裸机 RAW 镜像的位置,coreos.inst.ignition_url 参数值则是 worker Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 initramfs 文件的位置。
      注意

      这个配置不会在使用图形控制台的机器上启用串口控制台访问。要配置不同的控制台,请在 kerne 行中添加一个或多个 console= 参数。例如,添加 console=tty0 console=ttyS0 将第一个 PC 串口设置为主控制台,图形控制台作为二级控制台。如需更多信息,请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和(或)控制台?

  2. 使用 PXE 或 iPXE 基础架构为集群创建所需的计算机器。

2.2.4. 批准机器的证书签名请求

将机器添加到集群时,会为您添加的每台机器生成两个待处理证书签名请求(CSR)。您必须确认这些 CSR 已获得批准,或根据需要自行批准。客户端请求必须首先被批准,然后是服务器请求。

先决条件

  • 您已将机器添加到集群中。

流程

  1. 确认集群可以识别这些机器:

    $ oc get nodes

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.18.3
    master-1  Ready     master  63m  v1.18.3
    master-2  Ready     master  64m  v1.18.3
    worker-0  NotReady  worker  76s  v1.18.3
    worker-1  NotReady  worker  70s  v1.18.3

    输出将列出您创建的所有机器。

  2. 检查待处理的 CSR,并确保可以看到添加到集群中的每台机器都有 PendingApproved 状态的客户端请求:

    $ oc get csr

    输出示例

    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    ...

    在本例中,两台机器加入了集群。您可能会在列表中看到更多已批准的 CSR。

  3. 如果 CSR 没有获得批准,请在所添加机器的所有待处理 CSR 都处于 Pending 状态后,为您的集群机器批准这些 CSR:

    注意

    由于 CSR 会自动轮转,因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准,证书将会轮转,每个节点将会存在多个证书。您必须批准所有这些证书。批准初始 CSR 后,集群的 kube-controller-manager 会自动批准后续的节点客户端 CSR。您必须实施一个方法来自动批准 kubelet 提供的证书请求。

    • 若要单独批准,请对每个有效的 CSR 运行以下命令:

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> 是当前 CSR 列表中 CSR 的名称。
    • 要批准所有待处理的 CSR,请运行以下命令:

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
  4. 现在,您的客户端请求已被批准,您必须查看添加到集群中的每台机器的服务器请求:

    $ oc get csr

    输出示例

    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...

  5. 如果剩余的 CSR 没有被批准,且处于 Pending 状态,请批准集群机器的 CSR:

    • 若要单独批准,请对每个有效的 CSR 运行以下命令:

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> 是当前 CSR 列表中 CSR 的名称。
    • 要批准所有待处理的 CSR,请运行以下命令:

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
  6. 批准所有客户端和服务器 CSR 后,器将处于 Ready 状态。运行以下命令验证:

    $ oc get nodes

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.20.0
    master-1  Ready     master  73m  v1.20.0
    master-2  Ready     master  74m  v1.20.0
    worker-0  Ready     worker  11m  v1.20.0
    worker-1  Ready     worker  11m  v1.20.0

    注意

    批准服务器 CSR 后可能需要几分钟时间让机器转换为 Ready 状态。

其他信息

2.3. 部署机器健康检查

理解并部署机器健康检查。

重要

此过程不适用于自己手动置备机器的集群。您只能在使用机器 API 的集群中使用高级机器管理和扩展功能。

2.3.1. 关于机器健康检查

您可以使用 MachineHealthCheck 资源定义集群中的机器被视为不健康的条件。会自动修复满足条件的机器。

要监控机器健康状况,创建一个 MachineHealthCheck 自定义资源(CR),其中包含要监控的机器集合的标签以及要检查的条件,如维持 NotReady 状态 15 分钟,或在 node-problem-detector 中显示持久性状况。

监控 MachineHealthCheck CR 的控制器会检查您定义的条件。如果机器无法进行健康检查,则会自动删除机器并创建新的机器来代替它。删除机器之后,您会看到机器被删除事件。

注意

对于具有 master 角色的机器,机器健康检查会报告不健康的节点数量,但不会删除机器。例如:

输出示例

$ oc get machinehealthcheck example -n openshift-machine-api

NAME      MAXUNHEALTHY   EXPECTEDMACHINES   CURRENTHEALTHY
example   40%            3                  1

为限制删除机器造成的破坏性影响,控制器一次仅排空并删除一个节点。如果目标机器池中不健康的机器池中不健康的机器数量大于 maxUnhealthy 的值,则控制器会停止删除机器,您必须手动进行处理。

要停止检查,请删除自定义资源。

2.3.1.1. Bare Metal 上的 MachineHealthCheck

在裸机集群上删除机器会触发重新置备裸机主机。通常,裸机重新置备是一个需要较长时间的过程,在这个过程中,集群缺少计算资源,应用程序可能会中断。要将默认补救过程从机器删除到主机的节能周期,请使用 machine.openshift.io/remediation-strategy: external-baremetal 注解来注解 MachineHealthCheck 资源。

设置注解后,不健康的机器会使用 BMC 凭证进行节能。

2.3.1.2. 部署机器健康检查时的限制

部署机器健康检查前需要考虑以下限制:

  • 只有机器集拥有的机器才可以由机器健康检查修复。
  • 目前不支持 control plane 机器,如果不健康,则不会被修复。
  • 如果机器的节点从集群中移除,机器健康检查会认为机器不健康,并立即修复机器。
  • 如果机器对应的节点在 nodeStartupTimeout 之后没有加入集群,则会修复机器。
  • 如果 Machine 资源阶段为 Failed,则会立即修复机器。

2.3.2. MachineHealthCheck 资源示例

MachineHealthCheck 资源类似以下 YAML 文件之一:

裸机的MachineHealthCheck

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example 1
  namespace: openshift-machine-api
  annotations:
    machine.openshift.io/remediation-strategy: external-baremetal 2
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role> 3
      machine.openshift.io/cluster-api-machine-type: <role> 4
      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> 5
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s" 6
    status: "False"
  - type:    "Ready"
    timeout: "300s" 7
    status: "Unknown"
  maxUnhealthy: "40%" 8
  nodeStartupTimeout: "10m" 9

1
指定要部署的机器健康检查的名称。
2
对于裸机集群,您必须在 annotations 部分中包含 machine.openshift.io/remediation-strategy: external-baremetal 注解来启用电源周期补救。采用这种补救策略时,不健康的主机会被重启,而不是从集群中删除。
3 4
为要检查的机器池指定一个标签。
5
<cluster_name>-<label>-<zone> 格式 指定要跟踪的机器集。例如,prod-node-us-east-1a
6 7
指定节点条件的超时持续时间。如果在超时时间内满足了条件,则会修复机器。超时时间较长可能会导致不健康的机器上的工作负载长时间停机。
8
指定目标池中允许的不健康机器的数量。这可设为一个百分比或一个整数。
9
指定机器健康检查在决定机器不健康前必须等待节点加入集群的超时持续时间。
注意

matchLabels 只是示例; 您必须根据具体需要映射您的机器组。

所有其他安装类型的MachineHealthCheck

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example 1
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role> 2
      machine.openshift.io/cluster-api-machine-type: <role> 3
      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> 4
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s" 5
    status: "False"
  - type:    "Ready"
    timeout: "300s" 6
    status: "Unknown"
  maxUnhealthy: "40%" 7
  nodeStartupTimeout: "10m" 8

1
指定要部署的机器健康检查的名称。
2 3
为要检查的机器池指定一个标签。
4
<cluster_name>-<label>-<zone> 格式 指定要跟踪的机器集。例如,prod-node-us-east-1a
5 6
指定节点条件的超时持续时间。如果在超时时间内满足了条件,则会修复机器。超时时间较长可能会导致不健康的机器上的工作负载长时间停机。
7
指定目标池中允许的不健康机器的数量。这可设为一个百分比或一个整数。
8
指定机器健康检查在决定机器不健康前必须等待节点加入集群的超时持续时间。
注意

matchLabels 只是示例; 您必须根据具体需要映射您的机器组。

2.3.2.1. 短路机器健康检查补救

短路可确保仅在集群健康时机器健康检查修复机器。通过 MachineHealthCheck 资源中的 maxUnhealthy 字段配置短路。

如果用户在修复任何机器前为 maxUnhealthy 字段定义了一个值,MachineHealthCheck 会将 maxUnhealthy 的值与它决定不健康的目标池中的机器数量进行比较。如果不健康的机器数量超过 maxUnhealthy 限制,则不会执行补救。

重要

如果没有设置 maxUnhealthy,则默认值为 100%,无论集群状态如何,机器都会被修复。

maxUnhealthy 字段可以设置为整数或百分比。根据 maxUnhealthy 值,有不同的补救实现。

2.3.2.1.1. 使用绝对值设置 maxUnhealthy

如果将 maxUnhealthy 设为 2:

  • 如果 2 个或更少节点不健康,则可执行补救
  • 如果 3 个或更多节点不健康,则不会执行补救

这些值与机器健康检查要检查的机器数量无关。

2.3.2.1.2. 使用百分比设置 maxUnhealthy

如果 maxUnhealthy 被设置为 40%,有 25 个机器被检查:

  • 如果有 10 个或更少节点处于不健康状态,则可执行补救
  • 如果 11 个或多个节点不健康,则不会执行补救

如果 maxUnhealthy 被设置为 40%,有 6 个机器被检查:

  • 如果 2 个或更少节点不健康,则可执行补救
  • 如果 3 个或更多节点不健康,则不会执行补救
注意

当被检查的 maxUnhealthy 机器的百分比不是一个整数时,允许的机器数量会被舍入到一个小的整数。

2.3.3. 创建 MachineHealthCheck 资源

您可以为集群中的所有 MachineSet 创建 MachineHealthCheck 资源。您不应该创建针对 control plane 机器的 MachineHealthCheck 资源。

先决条件

  • 安装 oc 命令行界面。

流程

  1. 创建一个 healthcheck.yml 文件,其中包含您的机器健康检查的定义。
  2. healthcheck.yml 文件应用到您的集群:

    $ oc apply -f healthcheck.yml

2.3.4. 手动扩展机器集

如果您必须在机器集中添加或移除机器实例,则可以手动扩展机器集。

这个指南与全自动的、安装程序置备的基础架构安装相关。自定义的、用户置备的基础架构安装没有机器集。

先决条件

  • 安装 OpenShift Container Platform 集群和 oc 命令行。
  • 以具有 cluster-admin 权限的用户身份登录 oc

流程

  1. 查看集群中的机器集:

    $ oc get machinesets -n openshift-machine-api

    机器集以 <clusterid>-worker-<aws-region-az> 的形式列出。

  2. 扩展机器集:

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

    或者:

    $ oc edit machineset <machineset> -n openshift-machine-api

    您可以扩展或缩减机器集。需要过几分钟以后新机器才可用。

2.3.5. 了解机器集和机器配置池之间的区别

MachineSet 对象描述了与云或机器供应商相关的 OpenShift Container Platform 节点。

MachineConfigPool 对象允许 MachineConfigController 组件在升级过程中定义并提供机器的状态。

MachineConfigPool 对象允许用户配置如何将升级应用到机器配置池中的 OpenShift Container Platform 节点。

NodeSelector 对象可以被一个到 MachineSet 对象的引用替换。

2.4. 推荐的节点主机实践

OpenShift Container Platform 节点配置文件包含重要的选项。例如,控制可以为节点调度的最大 pod 数量的两个参数: podsPerCoremaxPods

当两个参数都被设置时,其中较小的值限制了节点上的 pod 数量。超过这些值可导致:

  • CPU 使用率增加。
  • 减慢 pod 调度的速度。
  • 根据节点中的内存数量,可能出现内存耗尽的问题。
  • 耗尽 IP 地址池。
  • 资源过量使用,导致用户应用程序性能变差。
重要

在 Kubernetes 中,包含单个容器的 pod 实际使用两个容器。第二个容器用来在实际容器启动前设置联网。因此,运行 10 个 pod 的系统实际上会运行 20 个容器。

podsPerCore 根据节点中的处理器内核数来设置节点可运行的 pod 数量。例如:在一个有 4 个处理器内核的节点上将 podsPerCore 设为 10 ,则该节点上允许的最大 pod 数量为 40

kubeletConfig:
  podsPerCore: 10

podsPerCore 设置为 0 可禁用这个限制。默认为 0podsPerCore 不能超过 maxPods

maxPods 把节点可以运行的 pod 数量设置为一个固定值,而不需要考虑节点的属性。

 kubeletConfig:
    maxPods: 250

2.4.1. 创建 KubeletConfig CRD 来编辑 kubelet 参数

kubelet 配置目前被序列化为 Ignition 配置,因此可以直接编辑。但是,在 Machine Config Controller (MCC) 中同时添加了新的 kubelet-config-controller 。这可让您创建 KubeletConfig 自定义资源 (CR) 来编辑 kubelet 参数。

流程

  1. 运行:

    $ oc get machineconfig

    这个命令显示了可选择的可用机器配置对象列表。默认情况下,与 kubelet 相关的配置为 01-master-kubelet01-worker-kubelet

  2. 要检查每个节点中最大 pod 数量的当前设置,请运行:

    # oc describe node <node-ip> | grep Allocatable -A6

    找到 value: pods: <value>.

    例如:

    # oc describe node ip-172-31-128-158.us-east-2.compute.internal | grep Allocatable -A6

    输出示例

    Allocatable:
     attachable-volumes-aws-ebs:  25
     cpu:                         3500m
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      15341844Ki
     pods:                        250

  3. 要设置 worker 节点上的每个节点的最大 pod,请创建一个包含 kubelet 配置的自定义资源文件。例如: change-maxPods-cr.yaml

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: set-max-pods
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: large-pods
      kubeletConfig:
        maxPods: 500

    kubelet 与 API 服务器进行交互的频率取决于每秒的查询数量 (QPS) 和 burst 值。如果每个节点上运行的 pod 数量有限,使用默认值(kubeAPIQPS50kubeAPIBurst100)就可以。如果节点上有足够 CPU 和内存资源,则建议更新 kubelet QPS 和 burst 率:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: set-max-pods
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: large-pods
      kubeletConfig:
        maxPods: <pod_count>
        kubeAPIBurst: <burst_rate>
        kubeAPIQPS: <QPS>
    1. 运行:

      $ oc label machineconfigpool worker custom-kubelet=large-pods
    2. 运行:

      $ oc create -f change-maxPods-cr.yaml
    3. 运行:

      $ oc get kubeletconfig

      这个命令会返回 set-max-pods

      根据集群中的 worker 节点数量,等待每个 worker 节点被逐个重启。对于有 3 个 worker 节点的集群,这个过程可能需要大约 10 到 15 分钟。

  4. 查看 worker 节点的 maxPods 的变化 :

    $ oc describe node
    1. 运行以下命令验证更改:

      $ oc get kubeletconfigs set-max-pods -o yaml

      这个命令会显示 True 状态和 type:Success

流程

默认情况下,在对可用的 worker 节点应用 kubelet 相关的配置时,只允许一台机器不可用。对于大型集群来说,它可能需要很长时间才可以反映出配置的更改。在任何时候,您可以调整更新的机器数量来加快进程速度。

  1. 运行:

    $ oc edit machineconfigpool worker
  2. maxUnavailable 设为所需值。

    spec:
      maxUnavailable: <node_count>
    重要

    当设置该值时,请考虑无法使用的 worker 节点数量,而不影响在集群中运行的应用程序。

2.4.2. Control plane 节点大小

control plane 节点对资源的要求取决于集群中的节点数量。以下推荐的 control plane 节点大小是基于 control plane 密度测试的结果。control plane 测试会根据节点数在每个命名空间中在集群中创建以下对象:

  • 12 个镜像流
  • 3 个构建配置
  • 6 个构建
  • 1 个部署,每个 pod 副本挂载两个 secret
  • 2 个部署,1 个 pod 副本挂载两个 secret
  • 3 个服务指向以前的部署
  • 3 个指向之前部署的路由
  • 10 个 secret,其中 2 个由以前的部署挂载
  • 10 个配置映射,其中 2 个由以前的部署挂载
worker 节点数量集群负载(命名空间)CPU 内核内存 (GB)

25

500

4

16

100

1000

8

32

250

4000

16

96

在具有三个 master 或 control plane 节点的集群中,当一个节点停止、重新引导或失败时,CPU 和内存用量会增加,因为剩余的两个节点必须处理负载才能具有高可用性。另外,在升级过程中还会有这个预期,因为 master 被封锁、排空并按顺序重新引导,以应用操作系统更新以及 control plane Operator 更新。为了避免大型和高密度的集群出现级联失败,请将 master 节点上的总资源使用量至少保留到所有可用容量的一半,以处理资源用量增加。相应地增加 master 节点上的 CPU 和内存。

重要

节点大小取决于集群中的节点和对象数量。它还取决于集群上是否正在主动创建这些对象。在创建对象时,control plane 在资源使用量方面与对象处于运行(running)阶段的时间相比更活跃。

重要

因为无法修改正在运行的 OpenShift Container Platform 4.5 集群中的 control plane 节点大小,所以您必须估计节点总数并在安装过程中使用推荐的 control plane 节点大小。

重要

建议基于在带有 OpenShiftSDN 作为网络插件的 OpenShift Container Platform 集群上捕获的数据点。

注意

在 OpenShift Container Platform 4.5 中,与 OpenShift Container Platform 3.11 及之前的版本相比,系统现在默认保留半个 CPU 内核(500 millicore)。确定大小时应该考虑这一点。

2.4.3. 设置 CPU Manager

流程

  1. 可选:标记节点:

    # oc label node perf-node.example.com cpumanager=true
  2. 编辑启用 CPU Manager 的节点的 MachineConfigPool 。在这个示例中,所有 worker 都启用了 CPU Manager:

    # oc edit machineconfigpool worker
  3. 为 worker 机器配置池添加标签:

    metadata:
      creationTimestamp: 2020-xx-xxx
      generation: 3
      labels:
        custom-kubelet: cpumanager-enabled
  4. 创建 KubeletConfigcpumanager-kubeletconfig.yaml,自定义资源 (CR) 。请参阅上一步中创建的标签,以便使用新的 kubelet 配置更新正确的节点。请参见 MachineConfigPoolSelector 部分:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: cpumanager-enabled
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: cpumanager-enabled
      kubeletConfig:
         cpuManagerPolicy: static 1
         cpuManagerReconcilePeriod: 5s 2
    1
    指定一个策略:
    • none.这个策略明确启用了现有的默认 CPU 关联性方案,从而不会出现超越调度程序自动进行的关联性。
    • static。此策略允许具有某些资源特征的 pod 获得提高 CPU 关联性和节点上专用的 pod。
    2
    可选。指定 CPU Manager 协调频率。默认值为 5s
  5. 创建动态 kubelet 配置:

    # oc create -f cpumanager-kubeletconfig.yaml

    这会在 kubelet 配置中添加 CPU Manager 功能,如果需要,Machine Config Operator(MCO)将重启节点。要启用 CPU Manager,则不需要重启。

  6. 检查合并的 kubelet 配置:

    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

    输出示例

           "ownerReferences": [
                {
                    "apiVersion": "machineconfiguration.openshift.io/v1",
                    "kind": "KubeletConfig",
                    "name": "cpumanager-enabled",
                    "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
                }
            ]

  7. 检查 worker 是否有更新的 kubelet.conf

    # oc debug node/perf-node.example.com
    sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

    输出示例

    cpuManagerPolicy: static        1
    cpuManagerReconcilePeriod: 5s   2

    1 2
    当创建 KubeletConfig CR 时会定义这些设置。
  8. 创建请求一个或多个内核的 pod。限制和请求都必须将其 CPU 值设置为一个整数。这是专用于此 pod 的内核数:

    # cat cpumanager-pod.yaml

    输出示例

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: cpumanager-
    spec:
      containers:
      - name: cpumanager
        image: gcr.io/google_containers/pause-amd64:3.0
        resources:
          requests:
            cpu: 1
            memory: "1G"
          limits:
            cpu: 1
            memory: "1G"
      nodeSelector:
        cpumanager: "true"

  9. 创建 pod:

    # oc create -f cpumanager-pod.yaml
  10. 确定为您标记的节点调度了 pod:

    # oc describe pod cpumanager

    输出示例

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

  11. 确认正确配置了 cgroups。获取 pause 进程的进程 ID(PID):

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    服务质量(QoS)等级为 Guaranteed 的 pod 被放置到 kubepods.slice 中。其它 QoS 等级的 pod 会位于 kubepods 的子 cgroups 中:

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done

    输出示例

    cpuset.cpus 1
    tasks 32706

  12. 检查任务允许的 CPU 列表:

    # grep ^Cpus_allowed_list /proc/32706/status

    输出示例

     Cpus_allowed_list:    1

  13. 确认系统中的另一个 pod(在这个示例中,QoS 等级为 burstable 的 pod)不能在为等级为Guaranteed 的 pod 分配的内核中运行:

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    0
    # oc describe node perf-node.example.com

    输出示例

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    这个 VM 有两个 CPU 内核。system-reserved 设置保留 500 millicores,这代表一个内核中的一半被从节点的总容量中减小,以达到 Node Allocatable 的数量。您可以看到 Allocatable CPU 是 1500 毫秒。这意味着您可以运行一个 CPU Manager pod,因为每个 pod 需要一个完整的内核。一个完整的内核等于 1000 毫秒。如果您尝试调度第二个 pod,系统将接受该 pod,但不会调度它:

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s

2.5. 巨页

了解并配置巨页。

2.5.1. 巨页的作用

内存在块(称为页)中进行管理。在大多数系统中,页的大小为 4Ki。1Mi 内存相当于 256 个页,1Gi 内存相当于 256,000 个页。CPU 有内置的内存管理单元,可在硬件中管理这些页的列表。Translation Lookaside Buffer (TLB) 是虚拟页到物理页映射的小型硬件缓存。如果在硬件指令中包括的虚拟地址可以在 TLB 中找到,则其映射信息可以被快速获得。如果没有包括在 TLN 中,则称为 TLB miss。系统将会使用基于软件的,速度较慢的地址转换机制,从而出现性能降低的问题。因为 TLB 的大小是固定的,因此降低 TLB miss 的唯一方法是增加页的大小。

巨页指一个大于 4Ki 的内存页。在 x86_64 构架中,有两个常见的巨页大小: 2Mi 和 1Gi。在其它构架上的大小会有所不同。要使用巨页,必须写相应的代码以便应用程序了解它们。Transparent Huge Pages(THP)试图在应用程序不需要了解的情况下自动管理巨页,但这个技术有一定的限制。特别是,它的页大小会被限为 2Mi。当有较高的内存使用率时,THP 可能会导致节点性能下降,或出现大量内存碎片(因为 THP 的碎片处理)导致内存页被锁定。因此,有些应用程序可能更适用于(或推荐)使用预先分配的巨页,而不是 THP。

2.5.2. 应用程序如何使用巨页

节点必须预先分配巨页以便节点报告其巨页容量。一个节点只能预先分配一个固定大小的巨页。

巨页可以使用名为 hugepages-<size> 的容器一级的资源需求被消耗。其中 size 是特定节点上支持的整数值的最精简的二进制标记。例如:如果某个节点支持 2048KiB 页大小,它将会有一个可调度的资源 hugepages-2Mi。与 CPU 或者内存不同,巨页不支持过量分配。

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
1
巨页指定要分配的准确内存数量。不要将这个值指定为巨页内存大小乘以页的大小。例如,巨页的大小为 2MB,如果应用程序需要使用由巨页组成的 100MB 的内存,则需要分配 50 个巨页。OpenShift Container Platform 会进行相应的计算。如上例所示,您可以直接指定 100MB

分配特定大小的巨页

有些平台支持多个巨页大小。要分配指定大小的巨页,在巨页引导命令参数前使用巨页大小选择参数hugepagesz=<size><size> 的值必须以字节为单位,并可以使用一个可选的后缀 [kKmMgG]。默认的巨页大小可使用 default_hugepagesz=<size> 引导参数定义。

巨页要求

  • 巨页面请求必须等于限制。如果指定了限制,则它是默认的,但请求不是。
  • 巨页在 pod 范围内被隔离。容器隔离功能计划在以后的版本中推出。
  • 后端为巨页的 EmptyDir 卷不能消耗大于 pod 请求的巨页内存。
  • 通过带有 SHM_HUGETLBshmget() 来使用巨页的应用程序,需要运行一个匹配 proc/sys/vm/hugetlb_shm_group 的 supplemental 组。

其他资源

2.5.3. 配置巨页

节点必须预先分配在 OpenShift Container Platform 集群中使用的巨页。保留巨页的方法有两种: 在引导时和在运行时。在引导时进行保留会增加成功的可能性,因为内存还没有很大的碎片。Node Tuning Operator 目前支持在特定节点上分配巨页。

2.5.3.1. 在引导时

流程

要减少节点重启的情况,请按照以下步骤顺序进行操作:

  1. 通过标签标记所有需要相同巨页设置的节点。

    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=
  2. 创建一个包含以下内容的文件,并把它命名为 hugepages_tuning.yaml

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      name: hugepages 1
      namespace: openshift-cluster-node-tuning-operator
    spec:
      profile: 2
      - data: |
          [main]
          summary=Boot time configuration for hugepages
          include=openshift-node
          [bootloader]
          cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50 3
        name: openshift-node-hugepages
    
      recommend:
      - machineConfigLabels: 4
          machineconfiguration.openshift.io/role: "worker-hp"
        priority: 30
        profile: openshift-node-hugepages
    1
    将 Tuned 资源的 name 设置为 hugepages
    2
    profile 部分设置为分配巨页。
    3
    请注意,参数顺序是非常重要的,因为有些平台支持各种大小的巨页。
    4
    启用基于机器配置池的匹配。
  3. 创建 Tuned hugepages 配置集

    $ oc create -f hugepages-tuned-boottime.yaml
  4. 创建一个带有以下内容的文件,并把它命名为 hugepages-mcp.yaml

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: worker-hp
      labels:
        worker-hp: ""
    spec:
      machineConfigSelector:
        matchExpressions:
          - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker-hp: ""
  5. 创建机器配置池:

    $ oc create -f hugepages-mcp.yaml

因为有足够的非碎片内存,worker-hp 机器配置池中的所有节点现在都应分配 50 个 2Mi 巨页。

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
警告

目前,这个功能只在 Red Hat Enterprise Linux CoreOS(RHCOS)8.x worker 节点上被支持。在 Red Hat Enterprise Linux(RHEL)7.x worker 节点上,目前不支持 Tuned [bootloader] 插件。

2.6. 了解设备插件

设备插件提供一致并可移植的解决方案,以便跨集群消耗硬件设备。设备插件通过一种扩展机制提供对这些设备的支持,从而将设备提供给容器,提供设备健康检查,并且安全地共享设备。

重要

OpenShift Container Platform 支持设备插件 API,但设备插件容器则由各家供应商提供支持。

设备插件是在节点(kubelet 的外部)上运行的 gRPC 服务,负责管理特定的硬件资源。任何设备插件都必须支持以下远程过程调用 (RPC):

service DevicePlugin {
      // GetDevicePluginOptions returns options to be communicated with Device
      // Manager
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plug-in can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // PreStartcontainer is called, if indicated by Device Plug-in during
      // registration phase, before each container start. Device plug-in
      // can run device specific operations such as reseting the device
      // before making devices available to the container
      rpc PreStartcontainer(PreStartcontainerRequest) returns (PreStartcontainerResponse) {}
}
设备插件示例
注意

对于简单设备插件参考实现,设备管理器代码中提供了一个存根设备插件:vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go

2.6.1. 设备插件部署方法

  • 守护进程集是设备插件部署的推荐方法。
  • 在启动时,设备插件会尝试在节点上的 /var/lib/kubelet/device-plugin/ 创建一个 UNIX 域套接字,以服务来自于设备管理器的 RPC。
  • 由于设备插件必须管理硬件资源、主机文件系统的访问权以及套接字创建,它们必须在一个特权安全上下文中运行。
  • 各种设备插件实现中提供了有关部署步骤的更多细节。

2.6.2. 了解设备管理器

设备管理器提供了一种机制,可借助称为“设备插件”的插件公告专用节点硬件资源。

您可以公告专用的硬件,而不必修改任何上游代码。

重要

OpenShift Container Platform 支持设备插件 API,但设备插件容器则由各家供应商提供支持。

设备管理器将设备公告为外部资源。用户 pod 可以利用相同的限制/请求机制来使用设备管理器公告的设备,这一机制也用于请求任何其他扩展资源

在启动时,设备插件通过在 /var/lib/kubelet/device-plugins/kubelet.sock 上调用 Register 将自身注册到设备管理器,再启动位于 /var/lib/kubelet/device-plugins/<plugin>.sock 的 gRPC 服务来服务设备管理器请求。

在处理新的注册请求时,设备管理器会在设备插件服务中调用 ListAndWatch 远程过程调用 (RPC)。作为响应,设备管理器通过 gRPC 流从插件中获取设备对象的列表。设备管理器对流进行持续监控,以确认插件有没有新的更新。在插件一端,插件也会使流保持开放;只要任何设备的状态有所改变,就会通过相同的流传输连接将新设备列表发送到设备管理器。

在处理新的 pod 准入请求时,Kubelet 将请求的扩展资源传递给设备管理器以进行设备分配。设备管理器在其数据库中检查,以验证是否存在对应的插件。如果插件存在并且有可分配的设备及本地缓存,则在该特定设备插件上调用 Allocate RPC。

此外,设备插件也可以执行其他几个特定于设备的操作,如驱动程序安装、设备初始化和设备重置。这些功能视具体实现而异。

2.6.3. 启用设备管理器

启用设备管理器来实现设备插件,在不更改上游代码的前提下公告专用硬件。

设备管理器提供了一种机制,可借助称为“设备插件”的插件公告专用节点硬件资源。

  1. 为您要配置的节点类型获取与静态 MachineConfigPool CRD 关联的标签。执行以下步骤之一:

    1. 查看机器配置:

      # oc describe machineconfig <name>

      例如:

      # oc describe machineconfig 00-worker

      输出示例

      Name:         00-worker
      Namespace:
      Labels:       machineconfiguration.openshift.io/role=worker 1

      1
      设备管理器所需标签。

流程

  1. 为配置更改创建自定义资源 (CR)。

    设备管理器 CR 配置示例

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: devicemgr 1
    spec:
      machineConfigPoolSelector:
        matchLabels:
           machineconfiguration.openshift.io: devicemgr 2
      kubeletConfig:
        feature-gates:
          - DevicePlugins=true 3

    1
    为 CR 分配一个名称。
    2
    输入来自机器配置池的标签。
    3
    DevicePlugins 设为“true”。
  2. 创建设备管理器:

    $ oc create -f devicemgr.yaml

    输出示例

    kubeletconfig.machineconfiguration.openshift.io/devicemgr created

  3. 通过确认节点上已创建了 /var/lib/kubelet/device-plugins/kubelet.sock,确保已启用了设备管理器。这是设备管理器 gRPC 服务器在其上侦听新插件注册的 UNIX 域套接字。只有启用了设备管理器,才会在 Kubelet 启动时创建此 sock 文件。

2.7. 污点和容限

理解并使用污点和容限。

2.7.1. 了解污点和容限

通过使用污点(taint),节点可以拒绝调度 pod,除非 pod 具有匹配的容限(toleration)

您可以通过节点规格(NodeSpec)将污点应用到节点,并通过 Pod 规格(PodSpec)将容限应用到 pod。当您应用污点时,调度程序无法将 pod 放置到该节点上,除非 pod 可以容限该污点。

节点规格中的污点示例

spec:
....
  template:
....
    spec:
      taints:
      - effect: NoExecute
        key: key1
        value: value1
....

Pod 规格中的容限示例

spec:
....
  template:
....
    spec
      tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoExecute"
        tolerationSeconds: 3600
....

污点与容限由 key、value 和 effect 组成。

表 2.1. 污点和容限组件

参数描述

key

key 是任意字符串,最多 253 个字符。key 必须以字母或数字开头,可以包含字母、数字、连字符、句点和下划线。

value

value 是任意字符串,最多 63 个字符。value 必须以字母或数字开头,可以包含字母、数字、连字符、句点和下划线。

effect

effect 的值包括:

NoSchedule[1]

  • 与污点不匹配的新 pod 不会调度到该节点上。
  • 该节点上现有的 pod 会保留。

PreferNoSchedule

  • 与污点不匹配的新 pod 可以调度到该节点上,但调度程序会尽量不这样调度。
  • 该节点上现有的 pod 会保留。

NoExecute

  • 与污点不匹配的新 pod 无法调度到该节点上。
  • 节点上没有匹配容限的现有 pod 将被移除。

operator

Equal

key/value/effect 参数必须匹配。这是默认值。

Exists

key/effect 参数必须匹配。您必须保留一个空的 value 参数,这将匹配任何值。

  1. 如果向 master 节点添加 NoSchedule 污点,节点必须具有 node-role.kubernetes.io/master=:NoSchedule 污点,默认添加该污点。

    例如:

    apiVersion: v1
    kind: Node
    metadata:
      annotations:
        machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
        machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
    ...
    spec:
      taints:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
    ...

容限与污点匹配:

  • 如果 operator 参数设为 Equal

    • key 参数相同;
    • value 参数相同;
    • effect 参数相同。
  • 如果 operator 参数设为 Exists

    • key 参数相同;
    • effect 参数相同。

OpenShift Container Platform 中内置了以下污点:

  • node.kubernetes.io/not-ready:节点未就绪。这与节点状况 Ready=False 对应。
  • node.kubernetes.io/unreachable:节点无法从节点控制器访问。这与节点状况 Ready=Unknown 对应。
  • node.kubernetes.io/out-of-disk:节点上的可用空间不足,无法添加新 pod。这与节点状况 OutOfDisk=True 对应。
  • node.kubernetes.io/memory-pressure:节点存在内存压力问题。这与节点状况 MemoryPressure=True 对应。
  • node.kubernetes.io/disk-pressure:节点存在磁盘压力问题。这与节点状况 DiskPressure=True 对应。
  • node.kubernetes.io/network-unavailable:节点网络不可用。
  • node.kubernetes.io/unschedulable:节点不可调度。
  • node.cloudprovider.kubernetes.io/uninitialized:当节点控制器通过外部云提供商启动时,在节点上设置这个污点来将其标记为不可用。在云控制器管理器中的某个控制器初始化这个节点后,kubelet 会移除此污点。

2.7.1.1. 了解如何使用容限秒数来延迟 pod 驱除

您可以通过在 Pod 规格或 MachineSet 对象中指定 tolerationSeconds 参数,指定 pod 在被驱除前可以保持与节点绑定的时长。如果将具有 NoExecute effect 的污点添加到节点,则容限污点(包含 tolerationSeconds 参数)的 pod,在此期限内 pod 不会被驱除。

输出示例

spec:
....
  template:
....
    spec
      tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoExecute"
        tolerationSeconds: 3600

在这里,如果此 pod 正在运行但没有匹配的容限,pod 保持与节点绑定 3600 秒,然后被驱除。如果污点在这个时间之前移除,pod 就不会被驱除。

2.7.1.2. 了解如何使用多个污点

您可以在同一个节点中放入多个污点,并在同一 pod 中放入多个容限。OpenShift Container Platform 按照如下所述处理多个污点和容限:

  1. 处理 pod 具有匹配容限的污点。
  2. 其余的不匹配污点在 pod 上有指示的 effect:

    • 如果至少有一个不匹配污点具有 NoSchedule effect,则 OpenShift Container Platform 无法将 pod 调度到该节点上。
    • 如果没有不匹配污点具有 NoSchedule effect,但至少有一个不匹配污点具有 PreferNoSchedule effect,则 OpenShift Container Platform 尝试不将 pod 调度到该节点上。
    • 如果至少有一个未匹配污点具有 NoExecute effect,OpenShift Container Platform 会将 pod 从该节点驱除(如果它已在该节点上运行),或者不将 pod 调度到该节点上(如果还没有在该节点上运行)。

      • 不容许污点的 Pod 会立即被驱除。
      • 如果 Pod 容许污点而没有在 Pod 规格中指定 tolerationSeconds,则会永久保持绑定。
      • 如果 Pod 容许污点,且指定了 tolerationSeconds,则会在指定的时间里保持绑定。

例如:

  • 向节点添加以下污点:

    $ oc adm taint nodes node1 key1=value1:NoSchedule
    $ oc adm taint nodes node1 key1=value1:NoExecute
    $ oc adm taint nodes node1 key2=value2:NoSchedule
  • pod 具有以下容限:

    spec:
    ....
      template:
    ....
        spec
          tolerations:
          - key: "key1"
            operator: "Equal"
            value: "value1"
            effect: "NoSchedule"
          - key: "key1"
            operator: "Equal"
            value: "value1"
            effect: "NoExecute"

在本例中,pod 无法调度到节点上,因为没有与第三个污点匹配的容限。如果在添加污点时 pod 已在节点上运行,pod 会继续运行,因为第三个污点是三个污点中 pod 唯一不容许的污点。

2.7.1.3. 了解 pod 调度和节点状况(根据状况保留节点)

Taint Nodes By Condition (默认启用)可自动污点报告状况的节点,如内存压力和磁盘压力。如果某个节点报告一个状况,则添加一个污点,直到状况被清除为止。这些污点具有 NoSchedule effect;即,pod 无法调度到该节点上,除非 pod 有匹配的容限。

在调度 pod 前,调度程序会检查节点上是否有这些污点。如果污点存在,则将 pod 调度到另一个节点。由于调度程序检查的是污点而非实际的节点状况,因此您可以通过添加适当的 pod 容限,将调度程序配置为忽略其中一些节点状况。

为确保向后兼容,守护进程会自动将下列容限添加到所有守护进程中:

  • node.kubernetes.io/memory-pressure
  • node.kubernetes.io/disk-pressure
  • node.kubernetes.io/out-of-disk(仅限关键 pod)
  • node.kubernetes.io/unschedulable(1.10 或更高版本)
  • node.kubernetes.io/network-unavailable(仅限主机网络)

您还可以在守护进程集中添加任意容限。

2.7.1.4. 了解根据状况驱除 pod(基于垃圾的驱除)

Taint-Based Evictions 功能默认是启用的,可以从遇到特定状况(如 not-readyunreachable)的节点驱除 pod。当节点遇到其中一个状况时,OpenShift Container Platform 会自动给节点添加污点,并开始驱除 pod 以及将 pod 重新调度到其他节点。

Taint Based Evictions 具有 NoExecute 效果,不容许污点的 pod 都被立即驱除,容许污点的 pod 不会被驱除,除非 pod 使用 tolerationSeconds 参数。

tolerationSeconds 参数允许您指定 pod 保持与具有节点状况的节点绑定的时长。如果在 tolerationSections 到期后状况仍然存在,则污点会保持在节点上,并且具有匹配容限的 pod 将被驱除。如果状况在 tolerationSeconds 到期前清除,则不会删除具有匹配容限的 pod。

如果使用没有值的 tolerationSeconds 参数,则 pod 不会因为未就绪和不可访问的节点状况而被驱除。

注意

OpenShift Container Platform 会以限速方式驱除 pod,从而防止在主控机从节点分离等情形中发生大量 pod 驱除。

OpenShift Container Platform 会自动为 node.kubernetes.io/not-readynode.kubernetes.io/unreachable 添加容限并设置 tolerationSeconds=300,除非 Pod 配置中指定了其中任一种容限。

spec:
....
  template:
....
    spec
      tolerations:
      - key: node.kubernetes.io/not-ready
        operator: Exists
        effect: NoExecute
        tolerationSeconds: 300 1
      - key: node.kubernetes.io/unreachable
        operator: Exists
        effect: NoExecute
        tolerationSeconds: 300
1
这些容限确保了在默认情况下,pod 在检测到这些节点条件问题中的任何一个时,会保持绑定 5 分钟。

您可以根据需要配置这些容限。例如,如果您有一个具有许多本地状态的应用程序,您可能希望在发生网络分区时让 pod 与节点保持绑定更久一些,以等待分区恢复并避免 pod 驱除行为的发生。

由守护进程集生成的 pod 在创建时会带有以下污点的 NoExecute 容限,且没有 tolerationSeconds:

  • node.kubernetes.io/unreachable
  • node.kubernetes.io/not-ready

因此,守护进程集 pod 不会被驱除。

2.7.1.5. 容限所有污点

您可以通过添加 operator: "Exists" 容限而无需 keyvalue 参数,将节点配置为容许所有污点。具有此容限的 Pod 不会从具有污点的节点中删除。

用于容忍所有污点的Pod 规格

spec:
....
  template:
....
    spec
      tolerations:
      - operator: "Exists"

2.7.2. 添加污点和容限

您可以为 pod 和污点添加容限,以便节点能够控制哪些 pod 应该或不应该调度到节点上。对于现有的 pod 和节点,您应首先将容限添加到 pod,然后将污点添加到节点,以避免在添加容限前从节点上移除 pod。

流程

  1. 通过编辑 Pod spec 使其包含 tolerations 小节来向 pod 添加容限:

    使用 Equal 运算符的 pod 配置文件示例

    spec:
    ....
      template:
    ....
        spec:
          tolerations:
          - key: "key1" 1
            value: "value1"
            operator: "Equal"
            effect: "NoExecute"
            tolerationSeconds: 3600 2

    1
    容限参数,如 Taint 和 toleration 组件表中所述。
    2
    tolerationSeconds 参数指定 pod 在被驱除前可以保持与节点绑定的时长。

    例如:

    使用 Exists 运算符的 pod 配置文件示例

    spec:
    ....
      template:
    ....
        spec:
          tolerations:
          - key: "key1"
            operator: "Exists" 1
            effect: "NoExecute"
            tolerationSeconds: 3600

    1
    Exists 运算符不会接受一个 value

    本例在 node1 上放置一个键为 key1 且值为 value1 的污点,污点效果是 NoExecute

  2. 通过以下命令,使用 Taint 和 toleration 组件表中描述的参数为节点添加污点:

    $ oc adm taint nodes <node_name> <key>=<value>:<effect>

    例如:

    $ oc adm taint nodes node1 key1=value1:NoExecute

    此命令在 node1 上放置一个键为 key1,值为 value1 的污点,其效果是 NoExecute

    注意

    如果向 master 节点添加 NoSchedule 污点,节点必须具有 node-role.kubernetes.io/master=:NoSchedule 污点,默认添加该污点。

    例如:

    apiVersion: v1
    kind: Node
    metadata:
      annotations:
        machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
        machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
    ...
    spec:
      taints:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
    ...

    Pod 上的容限与节点上的污点匹配。具有任一容限的 pod 可以调度到 node1 上。

2.7.3. 使用机器集添加污点和容限

您可以使用机器集为节点添加污点。与 MachineSet 对象关联的所有节点都会使用污点更新。容限对由机器集添加的污点的处理方式与直接添加到节点的污点的处理方式相同。

流程

  1. 通过编辑 Pod spec 使其包含 tolerations 小节来向 pod 添加容限:

    使用 Equal 运算符的 pod 配置文件示例

    spec:
    ....
      template:
    ....
        spec:
          tolerations:
          - key: "key1" 1
            value: "value1"
            operator: "Equal"
            effect: "NoExecute"
            tolerationSeconds: 3600 2

    1
    容限参数,如 Taint 和 toleration 组件表中所述。
    2
    tolerationSeconds 参数指定 pod 在被驱除前与节点绑定的时长。

    例如:

    使用 Exists 运算符的 pod 配置文件示例

    spec:
    ....
      template:
    ....
        spec:
          tolerations:
          - key: "key1"
            operator: "Exists"
            effect: "NoExecute"
            tolerationSeconds: 3600

  2. 将污点添加到 MachineSet 对象:

    1. 为您想要污点的节点编辑 MachineSet YAML,也可以创建新 MachineSet 对象:

      $ oc edit machineset <machineset>
    2. 将污点添加到 spec.template.spec 部分:

      节点规格中的污点示例

      spec:
      ....
        template:
      ....
          spec:
            taints:
            - effect: NoExecute
              key: key1
              value: value1
      ....

      本例在节点上放置一个键为 key1,值为 value1 的污点,污点效果是 NoExecute

    3. 将机器缩减为 0:

      $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api

      等待机器被删除。

    4. 根据需要扩展机器设置:

      $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

      等待机器启动。污点添加到与 MachineSet 对象关联的节点上。

2.7.4. 使用污点和容限将用户绑定到节点

如果要指定一组节点供特定用户独占使用,为 pod 添加容限。然后,在这些节点中添加对应的污点。具有容限的 pod 被允许使用污点节点,或集群中的任何其他节点。

如果您希望确保 pod 只调度到那些污点节点,还要将标签添加到同一组节点,并为 pod 添加节点关联性,以便 pod 只能调度到具有该标签的节点。

流程

配置节点以使用户只能使用该节点:

  1. 为这些节点添加对应的污点:

    例如:

    $ oc adm taint nodes node1 dedicated=groupName:NoSchedule
  2. 通过编写自定义准入控制器,为 pod 添加容限。

2.7.5. 使用污点和容限控制具有特殊硬件的节点

如果集群中有少量节点具有特殊的硬件,您可以使用污点和容限让不需要特殊硬件的 pod 与这些节点保持距离,从而将这些节点保留给那些确实需要特殊硬件的 pod。您还可以要求需要特殊硬件的 pod 使用特定的节点。

您可以将容限添加到需要特殊硬件并污点具有特殊硬件的节点的 pod 中。

流程

确保为特定 pod 保留具有特殊硬件的节点:

  1. 为需要特殊硬件的 pod 添加容限。

    例如:

    spec:
    ....
      template:
    ....
        spec:
          tolerations:
          - key: "disktype"
            value: "ssd"
            operator: "Equal"
            effect: "NoSchedule"
            tolerationSeconds: 3600
  2. 使用以下命令之一,给拥有特殊硬件的节点添加污点:

    $ oc adm taint nodes <node-name> disktype=ssd:NoSchedule

    或者:

    $ oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule

2.7.6. 删除污点和容限

您可以根据需要,从节点移除污点并从 pod 移除容限。您应首先将容限添加到 pod,然后将污点添加到节点,以避免在添加容限前从节点上移除 pod。

流程

移除污点和容限:

  1. 从节点移除污点:

    $ oc adm taint nodes <node-name> <key>-

    例如:

    $ oc adm taint nodes ip-10-0-132-248.ec2.internal key1-

    输出示例

    node/ip-10-0-132-248.ec2.internal untainted

  2. 要从 pod 移除某一容限,请编辑 Pod 规格来移除该容限:

    spec:
    ....
      template:
    ....
        spec:
          tolerations:
          - key: "key2"
            operator: "Exists"
            effect: "NoExecute"
            tolerationSeconds: 3600

2.8. 拓扑管理器

理解并使用拓扑管理器。

2.8.1. 拓扑管理器策略

拓扑管理器通过从 Hint 提供者(如 CPU Manager 和设备管理器)收集拓扑提示来调整所有级别服务质量(QoS)的 Pod 资源,并使用收集的提示来匹配 Pod 资源。

注意

要将 CPU 资源与 Pod 规格中的其他请求资源匹配,必须使用 static CPU Manager 策略启用 CPU Manager。

拓扑管理器支持四个分配策略,这些策略在 cpumanager-enabled 自定义资源(CR)中定义:

none 策略
这是默认策略,不执行任何拓扑对齐调整。
best-effort 策略
对于带有 best-effort 拓扑管理策略的 pod 中的每个容器,kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这些信息,拓扑管理器会保存那个容器的首选 NUMA 节点关联性设置。如果关联性没有被首选设置,则拓扑管理器会保存这个设置,并把 pod 分配给节点。
restricted 策略
对于带有 restricted 拓扑管理策略的 pod 中的每个容器,kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这些信息,拓扑管理器会保存那个容器的首选 NUMA 节点关联性设置。如果关联性没有被首选,则拓扑管理器会从节点拒绝这个 pod,从而导致 pod 处于 Terminated 状态,且 pod 准入失败。
single-numa-node 策略
对于带有 single-numa-node 拓扑管理策略的 pod 中的每个容器,kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这个信息,拓扑管理器会决定单个 NUMA 节点关联性是否可能。如果是,pod 将会分配给该节点。如果无法使用单一 NUMA 节点关联性,则拓扑管理器会拒绝来自节点的 pod。这会导致 pod 处于 Terminated 状态,且 pod 准入失败。

2.8.2. 设置拓扑管理器

要使用拓扑管理器,您必须启用 LatencySensitive Feature Gate,并在cpumanager-enabled 子定义资源(CR)中配置拓扑管理器策略。如果您设置了 CPU Manager,则该文件可能会存在。如果这个文件不存在,您可以创建该文件。

先决条件

  • 将 CPU Manager 策略配置为 static。请参考扩展和性能文档中的使用 CPU Manager 部分 。

流程

激活 Topolgy Manager:

  1. 编辑 FeatureGate 对象以添加 LatencySensitive 功能集:

    $ oc edit featuregate/cluster
    apiVersion: config.openshift.io/v1
    kind: FeatureGate
    metadata:
      annotations:
        release.openshift.io/create-only: "true"
      creationTimestamp: 2020-06-05T14:41:09Z
      generation: 2
      managedFields:
      - apiVersion: config.openshift.io/v1
        fieldsType: FieldsV1
        fieldsV1:
          f:metadata:
            f:annotations:
              .: {}
              f:release.openshift.io/create-only: {}
          f:spec: {}
        manager: cluster-version-operator
        operation: Update
        time: 2020-06-05T14:41:09Z
      - apiVersion: config.openshift.io/v1
        fieldsType: FieldsV1
        fieldsV1:
          f:spec:
            f:featureSet: {}
        manager: oc
        operation: Update
        time: 2020-06-05T15:21:44Z
      name: cluster
      resourceVersion: "28457"
      selfLink: /apis/config.openshift.io/v1/featuregates/cluster
      uid: e802e840-89ee-4137-a7e5-ca15fd2806f8
    spec:
      featureSet: LatencySensitive 1
    ...
    1
    添加以逗号分隔的列表中设定的 LatencySensitive 功能。
  2. cpumanager-enabled 自定义资源(CR)中配置的拓扑管理器。

    $ oc edit KubeletConfig cpumanager-enabled
    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: cpumanager-enabled
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: cpumanager-enabled
      kubeletConfig:
         cpuManagerPolicy: static 1
         cpuManagerReconcilePeriod: 5s
         topologyManagerPolicy: single-numa-node 2
    1
    此参数必须是 static
    2
    指定所选的拓扑管理器策略。在这里,策略是 single-numa-node。有效值为:defaultbest-effortrestrictedsingle-numa-node

2.8.3. Pod 与拓扑管理器策略的交互

以下的 Pod specs 示例演示了 Pod 与 Topology Manager 的交互。

因为没有指定资源请求或限制,以下 pod 以 BestEffort QoS 类运行。

spec:
  containers:
  - name: nginx
    image: nginx

因为请求小于限制,下一个 pod 以 Burstable QoS 类运行。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

如果所选策略不是 none,则拓扑管理器将不考虑其中任何一个 Pod 规格。

因为请求等于限制,最后一个 pod 以 Guaranteed QoS 类运行。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

拓扑管理器将考虑这个 pod。拓扑管理器会参考 CPU Manager 的静态策略,该策略可返回可用 CPU 的拓扑结构。拓扑管理器还参考设备管理器来发现可用设备的拓扑结构,如 example.com/device。

拓扑管理器将使用此信息存储该容器的最佳拓扑。在本 pod 中,CPU Manager 和设备管理器将在资源分配阶段使用此存储的信息。

2.9. 资源请求和过量使用

对于每个计算资源,容器可以指定一个资源请求和限制。根据确保节点有足够可用容量以满足请求值的请求来做出调度决策。如果容器指定了限制,但忽略了请求,则请求会默认采用这些限制。容器无法超过节点上指定的限制。

限制的强制实施取决于计算资源类型。如果容器没有请求或限制,容器会调度到没有资源保障的节点。在实践中,容器可以在最低本地优先级适用的范围内消耗指定的资源。在资源较少的情况下,不指定资源请求的容器将获得最低的服务质量。

调度基于请求的资源,而配额和硬限制指的是资源限制,它们可以设置为高于请求的资源。请求和限制的差值决定了过量使用程度;例如,如果为容器赋予 1Gi 内存请求和 2Gi 内存限制,则根据 1Gi 请求将容器调度到节点上,但最多可使用 2Gi;因此过量使用为 200%。

2.10. 使用 Cluster Resource Override Operator 的集群级别的过量使用

Cluster Resource Override Operator 是一个准入 Webhook,可让您控制过量使用的程度,并在集群中的所有节点上管理容器密度。Operator 控制特定项目中节点可以如何超过定义的内存和 CPU 限值。

您必须使用 OpenShift Container Platform 控制台或 CLI 安装 Cluster Resource override Operator,如下所示。在安装过程中,您会创建一个 ClusterResourceOverride 自定义资源 (CR),其中设置过量使用级别,如下例所示:

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
-   name: cluster 1
spec:
   memoryRequestToLimitPercent: 50 2
   cpuRequestToLimitPercent: 25 3
   limitCPUToMemoryPercent: 200 4
1
名称必须是 cluster
2
可选。如果指定或默认指定了容器内存限值,则该内存请求会覆盖到限值的这个百分比,从 1 到 100 之间。默认值为 50.
3
可选。如果指定或默认指定了容器 CPU 限值,则将 CPU 请求覆盖到限值的这个百分比,从 1 到 100 之间。默认值为 25。
4
可选。如果指定或默认指定了容器内存限值,则 CPU 限值将覆盖的内存限值的百分比(如果指定)。以 100% 扩展 1Gi RAM, 等于 1 个 CPU 内核。这会在覆盖 CPU 请求前进行(如果配置了)。默认值为 200。
注意

如果容器上没有设置限值,则 Cluster Resourceoverride Operator 覆盖无效。创建一个针对单独项目的带有默认限制的 LimitRange 对象,或在 Pod specs 中配置要应用的覆盖的限制。

配置后,可通过将以下标签应用到每个项目的命名空间对象来启用每个项目的覆盖:

apiVersion: v1
kind: Namespace
metadata:

....

  labels:
    clusterresourceoverrides.admission.autoscaling.openshift.io/enabled: "true"

....

Operator 监视 ClusterResourceOverride CR, 并确保 ClusterResourceOverride 准入 Webhook 被安装到与 Operator 相同的命名空间。

2.10.1. 使用 Web 控制台安装 Cluster Resource Override Operator

您可以使用 OpenShift Container Platform Web 控制台来安装 Cluster Resource Override Operator,以帮助控制集群中的过量使用。

先决条件

  • 如果容器上未设置限值,Cluster Resourceoverride Operator 将没有作用。您必须使用一个 LimitRange 对象为项目指定默认限值,或在 Pod spec 中配置要应用的覆盖的限制。

流程

使用 OpenShift Container Platform web 控制台安装 Cluster Resource Override Operator:

  1. 在 OpenShift Container Platform web 控制台中进入 HomeProjects

    1. 点击 Create Project
    2. 指定 clusterresourceoverride-operator 作为项目的名称。
    3. 点击 Create
  2. 进入 OperatorsOperatorHub

    1. 从可用 Operator 列表中选择 ClusterResourceOverride Operator,再点击 Install
    2. Install Operator 页面中,确保为 Installation Mode 选择了 A specific Namespace on the cluster
    3. 确保为 Installed Namespace 选择了 clusterresourceoverride-operator
    4. 指定更新频道批准策略
    5. 点击 Install
  3. Installed Operators 页面中,点 ClusterResourceOverride

    1. ClusterResourceOverride Operator 详情页面中,点 Create Instance
    2. Create ClusterResourceOverride 页面 中,编辑 YAML 模板以根据需要设置过量使用值:

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
        name: cluster 1
      spec:
        podResourceOverride:
          spec:
            memoryRequestToLimitPercent: 50 2
            cpuRequestToLimitPercent: 25 3
            limitCPUToMemoryPercent: 200 4
      1
      名称必须是 cluster
      2
      可选。指定在 1-100 之间覆盖容器内存限值的百分比(如果使用的话)。默认值为 50.
      3
      可选。指定在 1-100 之间覆盖容器 CPU 限值的百分比(如果使用的话)。默认值为 25。
      4
      可选。如果使用,请指定覆盖容器内存限值的百分比。以 100% 扩展 1Gi RAM, 等于 1 个 CPU 内核。这会在覆盖 CPU 请求前进行处理(如果已配置)。默认值为 200。
    3. 点击 Create
  4. 通过检查集群自定义资源的状态来检查准入 Webhook 的当前状态:

    1. ClusterResourceOverride Operator 页面中,点击 cluster
    2. ClusterResourceOverride Details 页中,点 YAML。当 webhook 被调用时,mutatingWebhookConfigurationRef 项会出现。

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
        annotations:
          kubectl.kubernetes.io/last-applied-configuration: |
            {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
        creationTimestamp: "2019-12-18T22:35:02Z"
        generation: 1
        name: cluster
        resourceVersion: "127622"
        selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
        uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
      spec:
        podResourceOverride:
          spec:
            cpuRequestToLimitPercent: 25
            limitCPUToMemoryPercent: 200
            memoryRequestToLimitPercent: 50
      status:
      
      ....
      
          mutatingWebhookConfigurationRef: 1
            apiVersion: admissionregistration.k8s.io/v1beta1
            kind: MutatingWebhookConfiguration
            name: clusterresourceoverrides.admission.autoscaling.openshift.io
            resourceVersion: "127621"
            uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3
      
      ....
      1
      引用 ClusterResourceOverride 准入Webhook。

2.10.2. 使用 CLI 安装 Cluster Resource Override Operator

您可以使用 OpenShift Container Platform CLI 来安装 Cluster Resource Override Operator,以帮助控制集群中的过量使用。

先决条件

  • 如果容器上未设置限值,Cluster Resourceoverride Operator 将没有作用。您必须使用一个 LimitRange 对象为项目指定默认限值,或在 Pod spec 中配置要应用的覆盖的限制。

流程

使用 CLI 安装 Cluster Resource Override Operator:

  1. 为 Cluster Resource Override Operator 创建命名空间:

    1. 为 Cluster Resource Override Operator 创建一个 Namespace 空间对象 YAML 文件(如 cro-namespace.yaml):

      apiVersion: v1
      kind: Namespace
      metadata:
        name: clusterresourceoverride-operator
    2. 创建命名空间:

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

      例如:

      $ oc create -f cro-namespace.yaml
  2. 创建一个 Operator 组:

    1. 为 Cluster Resource Override Operator 创建一个 OperatorGroup 对象 YAML 文件(如 cro-og.yaml):

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: clusterresourceoverride-operator
        namespace: clusterresourceoverride-operator
      spec:
        targetNamespaces:
          - clusterresourceoverride-operator
    2. 创建 Operator 组:

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

      例如:

      $ oc create -f cro-og.yaml
  3. 创建一个订阅:

    1. 为 Cluster Resourceoverride Operator 创建一个 Subscription 对象 YAML 文件(如 cro-sub.yaml):

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: clusterresourceoverride
        namespace: clusterresourceoverride-operator
      spec:
        channel: "4.5"
        name: clusterresourceoverride
        source: redhat-operators
        sourceNamespace: openshift-marketplace
    2. 创建订阅:

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

      例如:

      $ oc create -f cro-sub.yaml
  4. clusterresourceoverride-operator 命名空间中创建 ClusterResourceOverride 自定义资源(CR)对象:

    1. 进入 clusterresourceoverride-operator 命名空间。

      $ oc project clusterresourceoverride-operator
    2. 为 Cluster Resourceoverride Operator 创建 ClusterResourceOverride 对象 YAML 文件(如 cro-cr.yaml):

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
          name: cluster 1
      spec:
        podResourceOverride:
          spec:
            memoryRequestToLimitPercent: 50 2
            cpuRequestToLimitPercent: 25 3
            limitCPUToMemoryPercent: 200 4
      1
      名称必须是 cluster
      2
      可选。指定在 1-100 之间覆盖容器内存限值的百分比(如果使用的话)。默认值为 50.
      3
      可选。指定在 1-100 之间覆盖容器 CPU 限值的百分比(如果使用的话)。默认值为 25。
      4
      可选。如果使用,请指定覆盖容器内存限值的百分比。以 100% 扩展 1Gi RAM, 等于 1 个 CPU 内核。这会在覆盖 CPU 请求前进行处理(如果已配置)。默认值为 200。
    3. 创建 ClusterResourceOverride 对象:

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

      例如:

      $ oc create -f cro-cr.yaml
  5. 通过检查集群自定义资源的状态来验证准入 Webhook 的当前状态。

    $ oc get clusterresourceoverride cluster -n clusterresourceoverride-operator -o yaml

    当 webhook 被调用时,mutatingWebhookConfigurationRef 项会出现。

    输出示例

    apiVersion: operator.autoscaling.openshift.io/v1
    kind: ClusterResourceOverride
    metadata:
      annotations:
        kubectl.kubernetes.io/last-applied-configuration: |
          {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
      creationTimestamp: "2019-12-18T22:35:02Z"
      generation: 1
      name: cluster
      resourceVersion: "127622"
      selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
      uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
    spec:
      podResourceOverride:
        spec:
          cpuRequestToLimitPercent: 25
          limitCPUToMemoryPercent: 200
          memoryRequestToLimitPercent: 50
    status:
    
    ....
    
        mutatingWebhookConfigurationRef: 1
          apiVersion: admissionregistration.k8s.io/v1beta1
          kind: MutatingWebhookConfiguration
          name: clusterresourceoverrides.admission.autoscaling.openshift.io
          resourceVersion: "127621"
          uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3
    
    ....

    1
    引用 ClusterResourceOverride 准入Webhook。

2.10.3. 配置集群级别的过量使用

Cluster Resource Override Operator 需要一个 ClusterResourceOverride 自定义资源 (CR),以及您希望 Operator 来控制过量使用的每个项目的标识。

先决条件

  • 如果容器上未设置限值,Cluster Resourceoverride Operator 将没有作用。您必须使用一个 LimitRange 对象为项目指定默认限值,或在 Pod spec 中配置要应用的覆盖的限制。

流程

修改集群级别的过量使用:

  1. 编辑 ClusterResourceOverride CR:

    apiVersion: operator.autoscaling.openshift.io/v1
    kind: ClusterResourceOverride
    metadata:
    -   name: cluster
    spec:
       memoryRequestToLimitPercent: 50 1
       cpuRequestToLimitPercent: 25 2
       limitCPUToMemoryPercent: 200 3
    1
    可选。指定在 1-100 之间覆盖容器内存限值的百分比(如果使用的话)。默认值为 50.
    2
    可选。指定在 1-100 之间覆盖容器 CPU 限值的百分比(如果使用的话)。默认值为 25。
    3
    可选。如果使用,请指定覆盖容器内存限值的百分比。以 100% 扩展 1Gi RAM, 等于 1 个 CPU 内核。这会在覆盖 CPU 请求前进行处理(如果已配置)。默认值为 200。
  2. 确保在每个您希望 Cluster Resourceoverride Operator 来控制过量使用的项目中都添加了以下标识:

    apiVersion: v1
    kind: Namespace
    metadata:
    
    ....
    
      labels:
        clusterresourceoverrides.admission.autoscaling.openshift.io/enabled: "true" 1
    
    ....
    1
    把这个标识添加到每个项目。

2.11. 节点级别的过量使用

您可以使用各种方法来控制特定节点上的过量使用,如服务质量 (QOS) 保障、CPU 限值或保留资源。您还可以为特定节点和特定项目禁用过量使用功能。

2.11.1. 了解计算资源和容器

计算资源的节点强制行为特定于资源类型。

2.11.1.1. 了解容器 CPU 请求

容器可以保证获得其请求的 CPU 量,还可额外消耗节点上提供的超额 CPU,但不会超过容器指定的限制。如果多个容器试图使用超额 CPU,则会根据每个容器请求的 CPU 数量来分配 CPU 时间。

例如,如果一个容器请求了 500m CPU 时间,另一个容器请求了 250m CPU 时间,那么该节点上提供的额外 CPU 时间以 2:1 比例在这两个容器之间分配。如果容器指定了一个限制,它将被限速,无法使用超过指定限制的 CPU。使用 Linux 内核中的 CFS 共享支持强制实施 CPU 请求。默认情况下,使用 Linux 内核中的 CFS 配额支持以 100ms 测量间隔强制实施 CPU 限制,但这可以禁用。

2.11.1.2. 了解容器内存请求

容器可以保证获得其请求的内存量。容器可以使用高于请求量的内存,但一旦超过请求量,就有可能在节点上遇到内存不足情形时被终止。如果容器使用的内存少于请求量,它不会被终止,除非系统任务或守护进程需要的内存量超过了节点资源保留考虑在内的内存量。如果容器指定了内存限制,则超过限制数量时会立即被终止。

2.11.2. 了解过量使用和服务质量类

当节点上调度了没有发出请求的 pod,或者节点上所有 pod 的限制总和超过了机器可用容量时,该节点处于过量使用状态。

在过量使用环境中,节点上的 pod 可能会在任意给定时间点尝试使用超过可用量的计算资源。发生这种情况时,节点必须为 pod 赋予不同的优先级。有助于做出此决策的工具称为服务质量 (QoS) 类。

对于每个计算资源,容器划分到三个 QoS 类中的一个,它们按照优先级降序排列:

表 2.2. 服务质量类

优先级类名称描述

1(最高)

Guaranteed

如果为所有资源设置了限制和可选请求(不等于 0)并且它们相等,则容器被归类为 Guaranteed

2

Burstable

如果为所有资源设置了请求和可选限制(不等于 0)并且它们不相等,则容器被归类为 Burstable

3(最低)

BestEffort

如果没有为任何资源设置请求和限制,则容器被归类为 BestEffort

内存是一种不可压缩的资源,因此在内存量较低的情况下,优先级最低的容器首先被终止:

  • Guaranteed 容器优先级最高,并且保证只有在它们超过限制或者系统遇到内存压力且没有优先级更低的容器可被驱除时,才会被终止。
  • 在遇到系统内存压力时,Burstable 容器如果超过其请求量并且不存在其他 BestEffort 容器,则有较大的可能会被终止。
  • BestEffort 容器被视为优先级最低。系统内存不足时,这些容器中的进程最先被终止。

2.11.2.1. 了解如何为不同的服务质量层级保留内存

您可以使用 qos-reserved 参数指定在特定 QoS 级别上 pod 要保留的内存百分比。此功能尝试保留请求的资源,阻止较低 QoS 类中的 pod 使用较高 QoS 类中 pod 所请求的资源。

OpenShift Container Platform 按照如下所示使用 qos-reserved 参数:

  • 值为 qos-reserved=memory=100% 时,阻止 BurstableBestEffort QoS 类消耗较高 QoS 类所请求的内存。这会增加 BestEffortBurstable 工作负载上为了提高 GuaranteedBurstable 工作负载的内存资源保障而遭遇 OOM 的风险。
  • 值为 qos-reserved=memory=50% 时,允许 BurstableBestEffort QoS 类消耗较高 QoS 类所请求的内存的一半。
  • 值为 qos-reserved=memory=0% 时,允许 BurstableBestEffort QoS 类最多消耗节点的所有可分配数量(若可用),但会增加 Guaranteed 工作负载不能访问所请求内存的风险。此条件等同于禁用这项功能。

2.11.3. 了解交换内存和 QoS

您可以在节点上默认禁用交换,以便保持服务质量 (QoS) 保障。否则,节点上的物理资源会超额订阅,从而影响 Kubernetes 调度程序在 pod 放置过程中所做的资源保障。

例如,如果两个有保障 pod 达到其内存限制,各个容器可以开始使用交换内存。最终,如果没有足够的交换空间,pod 中的进程可能会因为系统被超额订阅而被终止。

如果不禁用交换,会导致节点无法意识到它们正在经历 MemoryPressure,从而造成 pod 无法获得它们在调度请求中索取的内存。这样节点上就会放置更多 pod,进一步增大内存压力,最终增加遭遇系统内存不足 (OOM) 事件的风险。

重要

如果启用了交换,则对于可用内存的资源不足处理驱除阈值将无法正常发挥作用。利用资源不足处理,允许在遇到内存压力时从节点中驱除 pod,并且重新调度到没有此类压力的备选节点上。

2.11.4. 了解节点过量使用

在过量使用的环境中,务必要正确配置节点,以提供最佳的系统行为。

当节点启动时,它会确保为内存管理正确设置内核可微调标识。除非物理内存不足,否则内核应该永不会在内存分配时失败。

为确保这一行为,OpenShift Container Platform 通过将 vm.overcommit_memory 参数设置为 1 来覆盖默认操作系统设置,从而将内核配置为始终过量使用内存。

OpenShift Container Platform 还通过将 vm.panic_on_oom 参数设置为 0,将内核配置为不会在内存不足时崩溃。设置为 0 可告知内核在内存不足 (OOM) 情况下调用 oom_killer,以根据优先级终止进程

您可以通过对节点运行以下命令来查看当前的设置:

$ sysctl -a |grep commit

输出示例

vm.overcommit_memory = 1

$ sysctl -a |grep panic

输出示例

vm.panic_on_oom = 0

注意

节点上应该已设置了上述标记,不需要进一步操作。

您还可以为每个节点执行以下配置:

  • 使用 CPU CFS 配额禁用或强制实施 CPU 限制
  • 为系统进程保留资源
  • 为不同的服务质量等级保留内存

2.11.5. 使用 CPU CFS 配额禁用或强制实施 CPU 限制

默认情况下,节点使用 Linux 内核中的完全公平调度程序 (CFS) 配额支持来强制实施指定的 CPU 限制。

如果禁用了 CPU 限制强制实施,了解其对节点的影响非常重要:

  • 如果容器有 CPU 请求,则请求仍由 Linux 内核中的 CFS 共享来实施。
  • 如果容器没有 CPU 请求,但没有 CPU 限制,则 CPU 请求默认为指定的 CPU 限值,并由 Linux 内核中的 CFS 共享强制。
  • 如果容器同时具有 CPU 请求和限制,则 CPU 请求由 Linux 内核中的 CFS 共享强制实施,且 CPU 限制不会对节点产生影响。

先决条件

  1. 为您要配置的节点类型获取与静态 MachineConfigPool CRD 关联的标签。执行以下步骤之一:

    1. 查看机器配置池:

      $ oc describe machineconfigpool <name>

      例如:

      $ oc describe machineconfigpool worker

      输出示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        creationTimestamp: 2019-02-08T14:52:39Z
        generation: 1
        labels:
          custom-kubelet: small-pods 1

      1
      如果添加了标签,它会出现在 labels 下。
    2. 如果标签不存在,则添加一个键/值对:

      $ oc label machineconfigpool worker custom-kubelet=small-pods

流程

  1. 为配置更改创建自定义资源 (CR)。

    禁用 CPU 限制的示例配置

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: disable-cpu-units 1
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: small-pods 2
      kubeletConfig:
        cpuCfsQuota: 3
          - "false"

    1
    为 CR 分配一个名称。
    2
    指定要应用配置更改的标签。
    3
    cpuCfsQuota 参数设置为 false

2.11.6. 为系统进程保留资源

为提供更可靠的调度并且最大程度减少节点资源过量使用,每个节点都可以保留一部分资源供系统守护进程使用(节点上必须运行这些守护进程才能使集群正常工作)。特别是,建议您为内存等不可压缩的资源保留资源。

流程

要明确为非 pod 进程保留资源,请通过指定可用于调度的资源来分配节点资源。如需了解更多详细信息,请参阅“为节点分配资源”。

2.11.7. 禁用节点过量使用

启用之后,可以在每个节点上禁用过量使用。

流程

要在节点中禁用过量使用,请在该节点上运行以下命令:

$ sysctl -w vm.overcommit_memory=0

2.12. 项目级别限值

为帮助控制过量使用,您可以设置每个项目的资源限值范围,为过量使用无法超过的项目指定内存和 CPU 限值,以及默认值。

如需有关项目级别资源限值的信息,请参阅附加资源。

另外,您可以为特定项目禁用过量使用。

2.12.1. 禁用项目过量使用

启用之后,可以按项目禁用过量使用。例如,您可以允许独立于过量使用配置基础架构组件。

流程

在某个项目中禁用过量使用:

  1. 编辑项目对象文件
  2. 添加以下注解:

    quota.openshift.io/cluster-resource-override-enabled: "false"
  3. 创建项目对象:

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

2.13. 使用垃圾回收释放节点资源

理解并使用垃圾回收。

2.13.1. 了解如何通过垃圾回收移除已终止的容器

可使用驱除阈值来执行容器垃圾回收。

为垃圾回收设定了驱除阈值时,节点会尝试为任何可从 API 访问的 pod 保留容器。如果 pod 已被删除,则容器也会被删除。只要 pod 没有被删除且没有达到驱除阈值,容器就会保留。如果节点遭遇磁盘压力,它会移除容器,并且无法再通过 oc logs 访问其日志。

  • eviction-soft - 软驱除阈值将驱除阈值与一个由管理员指定的必要宽限期配对。
  • removal-hard - 硬驱除阈值没有宽限期,如果观察到,OpenShift Container Platform 就会立即采取行动。

如果节点在软驱除阈值上下浮动,但没有超过其关联的宽限期,则对应的节点将持续在 truefalse 之间振荡。因此,调度程序可能会做出不当的调度决策。

要防止这种情况的出现,请使用 remove-pressure-transition-period 标记来控制 OpenShift Container Platform 在摆脱压力状况前必须等待的时间。OpenShift Container Platform 不会设置在状况切换回 false 前,在指定期限内针对指定压力状况满足的驱除阈值。

2.13.2. 了解如何通过垃圾回收移除镜像

镜像垃圾回收依靠节点上 cAdvisor 报告的磁盘用量来决定从节点中移除哪些镜像。

镜像垃圾收集策略基于两个条件:

  • 触发镜像垃圾回收的磁盘用量百分比(以整数表示)。默认值为 85
  • 镜像垃圾回收试尝试释放的磁盘用量百分比(以整数表示)。默认值为 80

对于镜像垃圾回收,您可以使用自定义资源修改以下任意变量。

表 2.3. 用于配置镜像垃圾回收的变量

设置描述

imageMinimumGCAge

在通过垃圾收集移除镜像前,未用镜像的最小年龄。默认值为 2m

imageGCHighThresholdPercent

触发镜像垃圾回收的磁盘用量百分比,以整数表示。默认值为 85

imageGCLowThresholdPercent

镜像垃圾回收试尝试释放的磁盘用量百分比,以整数表示。默认值为 80

每次运行垃圾收集器都会检索两个镜像列表:

  1. 目前在至少一个 pod 中运行的镜像的列表。
  2. 主机上可用镜像的列表。

随着新容器运行,新镜像即会出现。所有镜像都标有时间戳。如果镜像正在运行(上方第一个列表)或者刚被检测到(上方第二个列表),它将标上当前的时间。其余镜像的标记来自于以前的运行。然后,所有镜像都根据时间戳进行排序。

一旦开始回收,首先删除最旧的镜像,直到满足停止条件。

2.13.3. 为容器和镜像配置垃圾回收

作为管理员,您可以通过为各个机器配置池创建 kubeletConfig 对象来配置 OpenShift Container Platform 执行垃圾回收的方式。

注意

OpenShift Container Platform 只支持每个机器配置池的一个 kubeletConfig 对象。

您可以配置以下几项的任意组合:

  • 容器软驱除
  • 容器硬驱除
  • 镜像驱除

对于容器软驱除,您还可以配置驱除前宽限期。

先决条件

  1. 为您要配置的节点类型获取与静态 MachineConfigPool CRD 关联的标签。执行以下步骤之一:

    1. 查看机器配置池:

      $ oc describe machineconfigpool <name>

      例如:

      $ oc describe machineconfigpool worker

      输出示例

      Name:         worker
      Namespace:
      Labels:       custom-kubelet=small-pods 1

      1
      如果添加了标签,它会出现在 Labels 下。
    2. 如果标签不存在,则添加一个键/值对:

      $ oc label machineconfigpool worker custom-kubelet=small-pods

流程

  1. 为配置更改创建自定义资源 (CR)。

    容器垃圾回收 CR 的配置示例:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: worker-kubeconfig 1
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: small-pods 2
      kubeletConfig:
        evictionSoft: 3
          memory.available: "500Mi" 4
          nodefs.available: "10%"
          nodefs.inodesFree: "5%"
          imagefs.available: "15%"
          imagefs.inodesFree: "10%"
        evictionSoftGracePeriod:  5
          memory.available: "1m30s"
          nodefs.available: "1m30s"
          nodefs.inodesFree: "1m30s"
          imagefs.available: "1m30s"
          imagefs.inodesFree: "1m30s"
        evictionHard:
          memory.available: "200Mi"
          nodefs.available: "5%"
          nodefs.inodesFree: "4%"
          imagefs.available: "10%"
          imagefs.inodesFree: "5%"
        evictionPressureTransitionPeriod: 0s 6
        imageMinimumGCAge: 5m 7
        imageGCHighThresholdPercent: 80 8
        imageGCLowThresholdPercent: 75 9

    1
    对象的名称。
    2
    选择器标签。
    3
    驱除类型:EvictionSoftEvictionHard
    4
    基于特定驱除触发信号的驱除阈值。
    5
    软驱除宽限期。此参数不适用于 eviction-hard
    6
    摆脱驱除压力状况前的等待时间
    7
    在通过垃圾收集移除镜像前,未用镜像的最小年龄。
    8
    触发镜像垃圾回收的磁盘用量百分比(以整数表示)。
    9
    镜像垃圾回收试尝试释放的磁盘用量百分比(以整数表示)。
  2. 创建对象:

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

    例如:

    $ oc create -f gc-container.yaml

    输出示例

    kubeletconfig.machineconfiguration.openshift.io/gc-container created

  3. 验证垃圾回收是否活跃。您在自定义资源中指定的 Machine Config Pool 会将 UPDATING 显示为“true”,直到更改完全实施为止:

    $ oc get machineconfigpool

    输出示例

    NAME     CONFIG                                   UPDATED   UPDATING
    master   rendered-master-546383f80705bd5aeaba93   True      False
    worker   rendered-worker-b4c51bb33ccaae6fc4a6a5   False     True

2.14. 使用 Node Tuning Operator

理解并使用 Node Tuning Operator。

Node Tuning Operator 可以帮助您通过编排 Tuned 守护进程来管理节点级别的性能优化。大多数高性能应用程序都需要一定程度的内核级性能优化。Node Tuning Operator 为用户提供了一个统一的、节点一级的 sysctl 管理接口,并可以根据具体用户的需要灵活地添加自定义性能优化设置。

Operator 将为 OpenShift Container Platform 容器化 Tuned 守护进程作为一个 Kubernetes 守护进程集进行管理。它保证了自定义性能优化设置以可被守护进程支持的格式传递到在集群中运行的所有容器化的 Tuned 守护进程中。相应的守护进程会在集群的所有节点上运行,每个节点上运行一个。

在发生触发配置集更改的事件时,或通过接收和处理终止信号安全终止容器化 Tuned 守护进程时,容器化 Tuned 守护进程所应用的节点级设置将被回滚。

在版本 4.1 及更高版本中,OpenShift Container Platform 标准安装中包含了 Node Tuning Operator。

2.14.1. 访问 Node Tuning Operator 示例规格

使用此流程来访问 Node Tuning Operator 的示例规格。

流程

  1. 运行:

    $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

默认 CR 旨在为 OpenShift Container Platform 平台提供标准的节点级性能优化,它只能被修改来设置 Operator Management 状态。Operator 将覆盖对默认 CR 的任何其他自定义更改。若进行自定义性能优化,请创建自己的 Tuned CR。新创建的 CR 将与默认的 CR 合并,并基于节点或 pod 标识和配置文件优先级对节点应用自定义调整。

警告

虽然在某些情况下,对 pod 标识的支持可以作为自动交付所需调整的一个便捷方式,但我们不鼓励使用这种方法,特别是在大型集群中。默认 Tuned CR 并不带有 pod 标识匹配。如果创建了带有 pod 标识匹配的自定义配置集,则该功能将在此时启用。在以后的 Node Tuning Operator 版本中可能会弃用 pod 标识功能。

2.14.2. 自定义调整规格

Operator 的自定义资源 (CR) 包含两个主要部分。第一部分是 profile:,这是 tuned 配置集及其名称的列表。第二部分是 recommend:,用来定义配置集选择逻辑。

多个自定义调优规格可以共存,作为 Operator 命名空间中的多个 CR。Operator 会检测到是否存在新 CR 或删除了旧 CR。所有现有的自定义性能优化设置都会合并,同时更新容器化 Tuned 守护进程的适当对象。

配置集数据

profile: 部分列出了 Tuned 配置集及其名称。

profile:
- name: tuned_profile_1
  data: |
    # Tuned profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other Tuned daemon plug-ins supported by the containerized Tuned

# ...

- name: tuned_profile_n
  data: |
    # Tuned profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

建议的配置集

profile: 选择逻辑通过 CR 的 recommend: 部分来定义。recommend: 部分是根据选择标准推荐配置集的项目列表。

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

列表中的独立项:

- machineConfigLabels: 1
    <mcLabels> 2
  match: 3
  <match> 4
  priority: <priority> 5
  profile: <tuned_profile_name> 6
1
可选。
2
MachineConfig 标签的键/值字典。键必须是唯一的。
3
如果省略,则会假设配置集匹配,除非设置了优先级更高的配置集,或设置了 machineConfigLabels
4
可选列表。
5
配置集排序优先级。较低数字表示优先级更高(0 是最高优先级)。
6
在匹配项中应用的 Tuned 配置集。例如 tuned_profile_1

<match> 是一个递归定义的可选数组,如下所示:

- label: <label_name> 1
  value: <label_value> 2
  type: <label_type> 3
  <match> 4
1
节点或 pod 标签名称。
2
可选的节点或 pod 标签值。如果省略,<label_name> 足以匹配。
3
可选的对象类型(nodepod)。如果省略,会使用 node
4
可选的 <match> 列表。

如果不省略 <match>,则所有嵌套的 <match> 部分也必须评估为 true。否则会假定 false,并且不会应用或建议具有对应 <match> 部分的配置集。因此,嵌套(子级 <match> 部分)会以逻辑 AND 运算来运作。反之,如果匹配 <match> 列表中任何一项,整个 <match> 列表评估为 true。因此,该列表以逻辑 OR 运算来运作。

如果定义 了 machineConfigLabels,基于机器配置池的匹配会对给定的 recommend: 列表项打开。<mcLabels> 指定机器配置标签。机器配置会自动创建,以在配置集 <tuned_profile_name> 中应用主机设置,如内核引导参数。这包括使用与 <mcLabels> 匹配的机器配置选择器查找所有机器配置池,并在与机器配置池的节点选择器匹配的所有节点上设置配置集 <tuned_profile_name>

列表项 matchmachineConfigLabels 由逻辑 OR 操作符连接。match 项首先以短电路方式评估。因此,如果它被评估为 true,则不考虑 MachineConfigLabels 项。

重要

当使用基于机器配置池的匹配时,建议将具有相同硬件配置的节点分组到同一机器配置池中。不遵循这个原则可能会导致在共享同一机器配置池的两个或者多个节点中 Tuned 操作对象导致内核参数冲突。

示例:基于节点或 pod 标签的匹配

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

根据配置集优先级,以上 CR 针对容器化 Tuned 守护进程转换为 recommend.conf 文件。优先级最高 (10) 的配置集是 openshift-control-plane-es,因此会首先考虑它。在给定节点上运行的容器化 Tuned 守护进程会查看同一节点上是否在运行设有 tuned.openshift.io/elasticsearch 标签的 pod。如果没有,则整个 <match> 部分评估为 false。如果存在具有该标签的 pod,为了让 <match> 部分评估为 true,节点标签也需要是 node-role.kubernetes.io/masternode-role.kubernetes.io/infra

如果这些标签对优先级为 10 的配置集而言匹配,则应用 openshift-control-plane-es 配置集,并且不考虑其他配置集。如果节点/pod 标签组合不匹配,则考虑优先级第二高的配置集 (openshift-control-plane)。如果容器化 Tuned Pod 在具有标签 node-role.kubernetes.io/masternode-role.kubernetes.io/infra 的节点上运行,则应用此配置集。

最后,配置集 openshift-node 的优先级最低 (30)。它没有 <match> 部分,因此始终匹配。如果给定节点上不匹配任何优先级更高的配置集,它会作为一个适用于所有节点的配置集来设置 openshift-node 配置集。

决定工作流

示例:基于机器配置池的匹配

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

为尽量减少节点的重新引导情况,为目标节点添加机器配置池将匹配的节点选择器标签,然后创建上述 Tuned CR,最后创建自定义机器配置池。

2.14.3. 在集群中设置默认配置集

以下是在集群中设置的默认配置集。

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - name: "openshift"
    data: |
      [main]
      summary=Optimize systems running OpenShift (parent profile)
      include=${f:virt_check:virtual-guest:throughput-performance}

      [selinux]
      avc_cache_threshold=8192

      [net]
      nf_conntrack_hashsize=131072

      [sysctl]
      net.ipv4.ip_forward=1
      kernel.pid_max=>4194304
      net.netfilter.nf_conntrack_max=1048576
      net.ipv4.conf.all.arp_announce=2
      net.ipv4.neigh.default.gc_thresh1=8192
      net.ipv4.neigh.default.gc_thresh2=32768
      net.ipv4.neigh.default.gc_thresh3=65536
      net.ipv6.neigh.default.gc_thresh1=8192
      net.ipv6.neigh.default.gc_thresh2=32768
      net.ipv6.neigh.default.gc_thresh3=65536
      vm.max_map_count=262144

      [sysfs]
      /sys/module/nvme_core/parameters/io_timeout=4294967295
      /sys/module/nvme_core/parameters/max_retries=10

  - name: "openshift-control-plane"
    data: |
      [main]
      summary=Optimize systems running OpenShift control plane
      include=openshift

      [sysctl]
      # ktune sysctl settings, maximizing i/o throughput
      #
      # Minimal preemption granularity for CPU-bound tasks:
      # (default: 1 msec#  (1 + ilog(ncpus)), units: nanoseconds)
      kernel.sched_min_granularity_ns=10000000
      # The total time the scheduler will consider a migrated process
      # "cache hot" and thus less likely to be re-migrated
      # (system default is 500000, i.e. 0.5 ms)
      kernel.sched_migration_cost_ns=5000000
      # SCHED_OTHER wake-up granularity.
      #
      # Preemption granularity when tasks wake up.  Lower the value to
      # improve wake-up latency and throughput for latency critical tasks.
      kernel.sched_wakeup_granularity_ns=4000000

  - name: "openshift-node"
    data: |
      [main]
      summary=Optimize systems running OpenShift nodes
      include=openshift

      [sysctl]
      net.ipv4.tcp_fastopen=3
      fs.inotify.max_user_watches=65536
      fs.inotify.max_user_instances=8192

  recommend:
  - profile: "openshift-control-plane"
    priority: 30
    match:
    - label: "node-role.kubernetes.io/master"
    - label: "node-role.kubernetes.io/infra"

  - profile: "openshift-node"
    priority: 40

2.14.4. 支持的 Tuned 守护进程插件

在使用 Tuned CR 的 profile: 部分中定义的自定义配置集时,以下 Tuned 插件都受到支持,但 [main] 部分除外:

  • audio
  • cpu
  • disk
  • eeepc_she
  • modules
  • mounts
  • net
  • scheduler
  • scsi_host
  • selinux
  • sysctl
  • sysfs
  • usb
  • video
  • vm

其中一些插件提供了不受支持的动态性能优化功能。以下 Tuned 插件目前还不支持:

  • bootloader
  • script
  • systemd

如需更多信息,请参阅 Available Tuned Plug-insGetting Started with Tuned

2.15. 配置每个节点的最大 pod 数量

有两个参数控制可调度到节点的 pod 数量上限,分别为 podsPerCoremaxPods。如果您同时使用这两个选项,则取两者中较小的限制来限制节点上的 pod 数。

例如,如果将一个有 4 个处理器内核的节点上的 podsPerCore 设置为 10,则该节点上允许的 pod 数量上限为 40。

先决条件

  1. 为您要配置的节点类型获取与静态 MachineConfigPool CRD 关联的标签。执行以下步骤之一:

    1. 查看机器配置池:

      $ oc describe machineconfigpool <name>

      例如:

      $ oc describe machineconfigpool worker

      输出示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        creationTimestamp: 2019-02-08T14:52:39Z
        generation: 1
        labels:
          custom-kubelet: small-pods 1

      1
      如果添加了标签,它会出现在 labels 下。
    2. 如果标签不存在,则添加一个键/值对:

      $ oc label machineconfigpool worker custom-kubelet=small-pods

流程

  1. 为配置更改创建自定义资源 (CR)。

    max-pods CR 配置示例

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: set-max-pods 1
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: small-pods 2
      kubeletConfig:
        podsPerCore: 10 3
        maxPods: 250 4

    1
    为 CR 分配一个名称。
    2
    指定要应用配置更改的标签。
    3
    根据节点的处理器内核数限制节点上可运行的 pod 数量。
    4
    将节点上可运行的 pod 数量指定为一个固定值,而不考虑节点的属性。
    注意

    podsPerCore 设置为 0 可禁用这个限制。

    在上例中,podsPerCore 的默认值为 10maxPods 的默认值则为 250。这意味着,除非节点有 25 个以上的内核,否则 podsPerCore 就是默认的限制因素。

  2. 列出 MachineConfigPool CRD 以查看是否应用了更改。如果 Machine Config Controller 抓取到更改,则 UPDATING 列会报告 True

    $ oc get machineconfigpools

    输出示例

    NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
    master   master-9cc2c72f205e103bb534   False     False      False
    worker   worker-8cecd1236b33ee3f8a5e   False     True       False

    更改完成后,UPDATED 列会报告 True

    $ oc get machineconfigpools

    输出示例

    NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
    master   master-9cc2c72f205e103bb534   False     True       False
    worker   worker-8cecd1236b33ee3f8a5e   True      False      False

第 3 章 安装后的网络配置

安装 OpenShift Container Platform 后,您可以按照您的要求进一步扩展和自定义网络。

3.1. 使用 OpenShift SDN 配置网络策略

理解并使用网络策略。

3.1.1. 关于网络策略

在使用支持 Kubernetes 网络策略的 Kubernetes Container Network Interface(CNI)插件的集群中,网络隔离完全由 NetworkPolicy 对象控制。在 OpenShift Container Platform 4.5 中,OpenShift SDN 支持在默认的网络隔离模式中使用网络策略。

注意

在使用 OpenShift SDN 集群网络供应商时,网络策略会有以下限制:

  • 不支持由 egress 字段指定的出口网络策略。
  • 网络策略支持 IPBlock,但不支持 except。如果创建的策略带有一个有 except 的 IPBlock 项,SDN pod 的日志中会出现警告,策略中的整个 IPBlock 项都会被忽略。
警告

网络策略不适用于主机网络命名空间。启用主机网络的 Pod 不受网络策略规则的影响。

默认情况下,项目中的所有 pod 都可被其他 pod 和网络端点访问。要在一个项目中隔离一个或多个 Pod,您可以在该项目中创建 NetworkPolicy 对象来指示允许的入站连接。项目管理员可以在自己的项目中创建和删除 NetworkPolicy 对象。

如果一个 pod 由一个或多个 NetworkPolicy 对象中的选择器匹配,那么该 pod 将只接受至少被其中一个 NetworkPolicy 对象所允许的连接。未被任何 NetworkPolicy 对象选择的 pod 可以完全访问。

以下示例 NetworkPolicy 对象演示了支持不同的情景:

  • 拒绝所有流量:

    要使项目默认为拒绝流量,请添加一个匹配所有 pod 但不接受任何流量的 NetworkPolicy 对象:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
    spec:
      podSelector:
      ingress: []
  • 只允许 OpenShift Container Platform Ingress Controller 的连接:

    要使项目只允许 OpenShift Container Platform Ingress Controller 的连接,请添加以下 NetworkPolicy 对象。

    重要

    对于 OVN-Kubernetes 网络供应商插件,当 Ingress Controller 配置为使用 HostNetwork 端点发布策略时,不支持应用网络策略,以便允许入口流量,所有其他流量都会被拒绝。

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-ingress
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: ingress
      podSelector: {}
      policyTypes:
      - Ingress

    如果 Ingress Controller 配置了endpointPublishingStrategy: HostNetwork,则 Ingress Controller pod 在主机网络中运行。在主机网络中运行时,来自 Ingress Controller 的网络流量会被分配 netid:0 Virtual Network ID (VNID) 。与 Ingress Operator 关联的命名空间的 netid 不同,因此 allow-from-openshift-ingress 中的 matchLabel 网络策略与 default Ingress Controller 的流量不匹配。使用 OpenShift SDN 时,default 命名空间分配 netid:0 VNID,您可以把 default 命名空间标记(label)为 network.openshift.io/policy-group: ingress 来允许来自于 default Ingress Controller 的网络流量。

  • 只接受项目中 pod 的连接:

    要使 pod 接受同一项目中其他 pod 的连接,但拒绝其他项目中所有 pod 的连接,请添加以下 NetworkPolicy 对象:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-same-namespace
    spec:
      podSelector:
      ingress:
      - from:
        - podSelector: {}
  • 仅允许基于 pod 标签的 HTTP 和 HTTPS 流量:

    要对带有特定标签(以下示例中的 role=frontend)的 pod 仅启用 HTTP 和 HTTPS 访问,请添加类似如下的 NetworkPolicy 对象:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-http-and-https
    spec:
      podSelector:
        matchLabels:
          role: frontend
      ingress:
      - ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 443
  • 使用命名空间和 pod 选择器接受连接:

    要通过组合使用命名空间和 pod 选择器来匹配网络流量,您可以使用类似如下的 NetworkPolicy 对象:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-pod-and-namespace-both
    spec:
      podSelector:
        matchLabels:
          name: test-pods
      ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                project: project_name
            podSelector:
              matchLabels:
                name: test-pods

NetworkPolicy 对象是可添加的;也就是说,您可以组合多个 NetworkPolicy 对象来满足复杂的网络要求。

例如,对于以上示例中定义的 NetworkPolicy 对象,您可以在同一个项目中定义 allow-same-namespaceallow-http-and-https 策略。因此,允许带有标签 role=frontend 的 pod 接受每一策略所允许的任何连接。即,任何端口上来自同一命名空间中的 pod 的连接,以及端口 80443 上的来自任意命名空间中 pod 的连接。

3.1.2. 示例 NetworkPolicy 对象

下文解释了示例 NetworkPolicy 对象:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017
1
NetworkPolicy 对象的名称
2
一个选择器(selector)用于描述策略应用到的 pod。策略对象只能选择定义了 NetworkPolicy 对象的项目中的 pod。
3
与策略对象允许从中入口流量的 pod 匹配的选择器。选择器将匹配任何项目中的 pod。
4
接受流量的一个或多个目标端口的列表。

3.1.3. 创建网络策略

要定义细致的规则描述集群中项目允许的 ingress 网络流量,您可以创建一个网络策略。

先决条件

  • 集群使用支持 NetworkPolicy 对象的默认 CNI 网络供应商,如设置了 mode: NetworkPolicy 的 OpenShift SDN 网络供应商。此模式是 OpenShift SDN 的默认模式。
  • 已安装 OpenShift CLI(oc)。
  • 使用具有 cluster-admin 权限的用户登陆到集群。

流程

  1. 创建策略规则:

    1. 创建一个 <policy-name>.yaml 文件,其中 <policy-name> 描述策略规则。
    2. 在刚才创建的文件中,定义一个策略对象,如下例所示:

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: <policy-name> 1
      spec:
        podSelector:
        ingress: []
      1
      为策略对象指定一个名称。
  2. 运行以下命令来创建策略对象:

    $ oc create -f <policy-name>.yaml -n <project>

    在以下示例中,在名为 project1 的项目中创建一个新的 NetworkPolicy 对象:

    $ oc create -f default-deny.yaml -n project1

    输出示例

    networkpolicy "default-deny" created

3.1.4. 删除网络策略

您可以删除网络策略。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 使用具有 cluster-admin 权限的用户登陆到集群。

流程

  • 要删除 NetworkPolicy 对象,请输入以下命令。将 <policy-name> 替换为项目名称。

    $ oc delete networkpolicy <policy-name>

3.1.5. 查看网络策略

您可以列出集群中的网络策略。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 使用具有 cluster-admin 权限的用户登陆到集群。

流程

  • 要查看集群中定义的 NetworkPolicy 对象,请运行以下命令:

    $ oc get networkpolicy

3.1.6. 使用网络策略配置多租户隔离

您可以配置项目,使其与其他项目命名空间中的 pod 和服务分离。

先决条件

  • 集群使用支持 NetworkPolicy 对象的集群网络供应商,如设置了 mode: NetworkPolicy 的 OpenShift SDN 网络供应商。此模式是 OpenShift SDN 的默认模式。
  • 已安装 OpenShift CLI(oc)。
  • 使用具有 cluster-admin 权限的用户登陆到集群。

流程

  1. 创建以下 NetworkPolicy 对象:

    1. 名为 allow-from-openshift-ingress 的策略。

      重要

      对于 OVN-Kubernetes 网络供应商插件,当 Ingress Controller 配置为使用 HostNetwork 端点发布策略时,不支持应用网络策略,以便允许入口流量,所有其他流量都会被拒绝。

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
      EOF
    2. 名为 allow-from-openshift-monitoring 的策略:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
      EOF
    3. 名为 allow-same-namespace 的策略:

      $ cat << EOF| oc create -f -
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      EOF
  2. 如果 default Ingress Controller 配置设置了 spec.endpointPublishingStrategy: HostNetwork 值,您需要为 default OpenShift Container Platform 命名空间添加一个标记来允许 Ingress Controller 和项目间的网络流量:

    1. 确定您的 default Ingress Controller 是否使用了 HostNetwork 端点发布策略:

      $ oc get --namespace openshift-ingress-operator ingresscontrollers/default \
        --output jsonpath='{.status.endpointPublishingStrategy.type}'
    2. 如果上个命令报告了端点发布策略为 HostNetwork,在 default 命名空间中设置一个标记:

      $ oc label namespace default 'network.openshift.io/policy-group=ingress'
  3. 运行以下命令确认当前项目中存在 NetworkPolicy 对象:

    $ oc get networkpolicy <policy-name> -o yaml

    在以下示例中会显示 allow-from-openshift-ingress NetworkPolicy 对象:

    $ oc get -n project1 networkpolicy allow-from-openshift-ingress -o yaml

    输出示例

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-ingress
      namespace: project1
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: ingress
      podSelector: {}
      policyTypes:
      - Ingress

3.1.7. 为新项目创建默认网络策略

作为集群管理员,您可以在创建新项目时修改新项目模板,使其自动包含 NetworkPolicy 对象。

3.1.8. 为新项目修改模板

作为集群管理员,您可以修改默认项目模板,以便使用自定义要求创建新项目。

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

流程

  1. 以具有 cluster-admin 特权的用户身份登录。
  2. 生成默认项目模板:

    $ oc adm create-bootstrap-project-template -o yaml > template.yaml
  3. 使用文本编辑器,通过添加对象或修改现有对象来修改生成的 template.yaml 文件。
  4. 项目模板必须创建在 openshift-config 命名空间中。加载修改后的模板:

    $ oc create -f template.yaml -n openshift-config
  5. 使用 Web 控制台或 CLI 编辑项目配置资源。

    • 使用 Web 控制台:

      1. 导航至 AdministrationCluster Settings 页面。
      2. 点击 Global Configuration,查看所有配置资源。
      3. 找到 Project 的条目,并点击 Edit YAML
    • 使用 CLI:

      1. 编辑 project.config.openshift.io/cluster 资源:

        $ oc edit project.config.openshift.io/cluster
  6. 更新 spec 部分,使其包含 projectRequestTemplatename 参数,再设置您上传的项目模板的名称。默认名称为 project-request

    带有自定义项目模板的项目配置资源

    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
      ...
    spec:
      projectRequestTemplate:
        name: <template_name>

  7. 保存更改后,创建一个新项目来验证是否成功应用了您的更改。

3.1.8.1. 在新项目模板中添加网络策略

作为集群管理员,您可以在新项目的默认模板中添加网络策略。OpenShift Container Platform 将自动创建项目中模板中指定的所有 NetworkPolicy 对象。

先决条件

  • 集群使用支持 NetworkPolicy 对象的默认 CNI 网络供应商,如设置了 mode: NetworkPolicy 的 OpenShift SDN 网络供应商。此模式是 OpenShift SDN 的默认模式。
  • 已安装 OpenShift CLI(oc)。
  • 您需要使用具有 cluster-admin 权限的用户登陆到集群。
  • 您必须已为新项目创建了自定义的默认项目模板。

流程

  1. 运行以下命令来编辑新项目的默认模板:

    $ oc edit template <project_template> -n openshift-config

    <project_template> 替换为您为集群配置的缺省模板的名称。默认模板名称为 project-request

  2. 在模板中,将每个 NetworkPolicy 对象作为一个元素添加到 objects 参数中。objects 参数可以是一个或多个对象的集合。

    在以下示例中,objects 参数集合包括几个 NetworkPolicy 对象:

    objects:
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
    ...
  3. 可选:通过运行以下命令创建一个新项目,来确认您的网络策略对象已被成功创建:

    1. 创建一个新项目

      $ oc new-project <project> 1
      1
      <project> 替换为您要创建的项目的名称。
    2. 确认新项目模板中的网络策略对象存在于新项目中:

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s

3.2. 将 DNS 设置为私有

部署集群后,您可以修改其 DNS 使其只使用私有区。

流程

  1. 查看集群的 DNS 自定义资源:

    $ oc get dnses.config.openshift.io/cluster -o yaml

    输出示例

    apiVersion: config.openshift.io/v1
    kind: DNS
    metadata:
      creationTimestamp: "2019-10-25T18:27:09Z"
      generation: 2
      name: cluster
      resourceVersion: "37966"
      selfLink: /apis/config.openshift.io/v1/dnses/cluster
      uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
    spec:
      baseDomain: <base_domain>
      privateZone:
        tags:
          Name: <infrastructureID>-int
          kubernetes.io/cluster/<infrastructureID>: owned
      publicZone:
        id: Z2XXXXXXXXXXA4
    status: {}

    请注意,spec 部分包含一个私有区和一个公共区。

  2. 修补 DNS 自定义资源以删除公共区:

    $ oc patch dnses.config.openshift.io/cluster --type=merge --patch='{"spec": {"publicZone": null}}'
    dns.config.openshift.io/cluster patched

    因为 Ingress Controller 在创建 Ingress 对象时会参考 DNS 定义,因此当您创建或修改 Ingress 对象时,只会创建私有记录。

    重要

    在删除公共区时,现有 Ingress 对象的 DNS 记录不会修改。

  3. 可选:查看集群的 DNS 自定义资源,并确认已删除公共区:

    $ oc get dnses.config.openshift.io/cluster -o yaml

    输出示例

    apiVersion: config.openshift.io/v1
    kind: DNS
    metadata:
      creationTimestamp: "2019-10-25T18:27:09Z"
      generation: 2
      name: cluster
      resourceVersion: "37966"
      selfLink: /apis/config.openshift.io/v1/dnses/cluster
      uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
    spec:
      baseDomain: <base_domain>
      privateZone:
        tags:
          Name: <infrastructureID>-int
          kubernetes.io/cluster/<infrastructureID>-wfpg4: owned
    status: {}

3.3. 启用集群范围代理

Proxy 对象用于管理集群范围出口代理。如果在安装或升级集群时没有配置代理,则 Proxy 对象仍会生成,但它会有一个空的 spec。例如:

apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
  name: cluster
spec:
  trustedCA:
    name: ""
status:

集群管理员可以通过修改这个 cluster Proxy 对象来配置 OpenShift Container Platform 的代理。

注意

只支持名为 cluster 的 Proxy 对象,且无法创建额外的代理。

先决条件

  • 集群管理员权限
  • 已安装 OpenShift Container Platform oc CLI 工具

流程

  1. 创建包含代理 HTTPS 连接所需的额外 CA 证书的 ConfigMap。

    注意

    如果代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名,您可以跳过这一步。

    1. 利用以下内容,创建一个名为 user-ca-bundle.yaml 的文件,并提供 PEM 编码证书的值:

      apiVersion: v1
      data:
        ca-bundle.crt: | 1
          <MY_PEM_ENCODED_CERTS> 2
      kind: ConfigMap
      metadata:
        name: user-ca-bundle 3
        namespace: openshift-config 4
      1
      这个数据键必须命名为 ca-bundle.crt
      2
      一个或多个 PEM 编码的 X.509 证书,用来为代理的身份证书签名。
      3
      要从 Proxy 对象引用的 ConfigMap 名称。
      4
      ConfigMap 必须在 openshift-config 命名空间中。
    2. 从此文件创建 ConfigMap:

      $ oc create -f user-ca-bundle.yaml
  2. 使用 oc edit 命令修改 Proxy 对象:

    $ oc edit proxy/cluster
  3. 为代理配置所需的字段:

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      name: cluster
    spec:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: http://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
      readinessEndpoints:
      - http://www.google.com 4
      - https://www.google.com
      trustedCA:
        name: user-ca-bundle 5
    1
    用于创建集群外 HTTP 连接的代理 URL。URL 必须是 http
    2
    用于创建集群外 HTTPS 连接的代理 URL。如果没有指定,则 httpProxy 会同时用于 HTTP 和 HTTPS 连接。
    3
    要排除代理的目标域名、域、IP 地址或其他网络 CIDR 的逗号分隔列表。

    在域前面加 . 来仅匹配子域。例如: .y.com 匹配 x.y.com,但不匹配 y.com。使用 * 可对所有目的地绕过所有代理。如果您扩展了未包含在安装配置中 networking.machineNetwork[].cidr 字段定义的 worker,您必须将它们添加到此列表中,以防止连接问题。

    如果未设置 httpProxyhttpsProxy 字段,则此字段将被忽略。

    4
    httpProxyhttpsProxy 值写进状态之前,执行就绪度检查时要使用的一个或多个集群外部 URL。
    5
    引用 openshift-config 命名空间中的 ConfigMap,其包含代理 HTTPS 连接所需的额外 CA 证书。注意 ConfigMap 必须已经存在,然后才能在这里引用它。此字段是必需的,除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。
  4. 保存文件以使改变生效。
注意

URL 必须是 http。目前不支持 https

3.4. Cluster Network Operator 配置

集群网络的配置作为 Cluster Network Operator (CNO) 配置的一部分被指定,并存储在名为 cluster的 CR 对象中。CR 指定 operator.openshift.io API 组中的 Network API 的参数。

注意

在集群安装后,您无法修改集群网络供应商的配置。

3.5. 配置集群入口流量

OpenShift Container Platform 提供了以下从集群外部与集群中运行的服务进行通信的方法:

  • 如果您有 HTTP/HTTPS,请使用 Ingress Controller。
  • 如果您有 HTTPS 之外的 TLS 加密协议,如使用 SNI 标头的 TLS,请使用 Ingress Controller。
  • 否则,请使用负载均衡器、外部 IP 或节点端口。
方法用途

使用 Ingress Controller

允许访问 HTTP/HTTPS 流量和 HTTPS 以外的 TLS 加密协议(例如,使用 SNI 标头的 TLS)。

使用负载均衡器服务自动分配外部 IP

允许流量通过从池分配的 IP 地址传到非标准端口。

手动将外部 IP 分配给服务

允许流量通过特定的 IP 地址传到非标准端口。

配置 NodePort

在集群中的所有节点上公开某一服务。

3.6. Red Hat OpenShift Service Mesh 支持的配置

以下是 Red Hat OpenShift Service Mesh 唯一支持的配置:

  • Red Hat OpenShift Container Platform 版本 4.x。
注意

OpenShift Online 和 OpenShift Dedicated 不支持 Red Hat OpenShift Service Mesh。

  • 部署必须包含在一个独立的 OpenShift Container Platform 集群中。
  • 此版本的 Red Hat OpenShift Service Mesh 仅适用于 OpenShift Container Platform x86_64。
  • 此发行版本只支持在 OpenShift 集群中包含所有 Service Mesh 组件的配置。它不支持在集群之外或在多集群场景中管理微服务。
  • 这个版本只支持没有集成外部服务的配置,比如虚拟机。

3.6.1. Red Hat OpenShift Service Mesh 支持的 Kiali 配置

  • Kiali 观察控制台只支持 Chrome 、Edge 、Firefox 或 SDomain 浏览器的最新的两个版本。

3.6.2. 支持的 Mixer 适配器

  • 此发行版本只支持以下 Mixer 适配器:

    • 3scale Istio Adapter

3.6.3. Red Hat OpenShift Service Mesh 安装操作

要安装 Red Hat OpenShift Service Mesh Operator,需首先安装以下 Operator:

  • Elasticsearch - 基于开源的 Elasticsearch 项目,您可以配置和管理 Elasticsearch 集群来使用 Jaeger 进行追踪和日志。
  • Jaeger - 基于开源 Jaeger 项目,可让您执行追踪来监控复杂分布式系统中的事务并进行故障排除。
  • Kiali - 基于开源的 Kiali 项目,提供了对服务网格进行观察的功能。通过使用 Kiali,您可以查看配置、监控流量,并在单一控制台中查看和分析 trace。

安装 Elasticsearch 、Jaeger 和 Kiali Operator 后,请安装 Red Hat OpenShift Service Mesh Operator。Service Mesh Operator 定义并监控管理 ServiceMeshControlPlane 资源,这个资源用来管理 Service Mesh 组件的部署、更新和删除操作。

  • Red Hat OpenShift Service Mesh - 基于开源 Istio 项目,可让您连接、控制并观察组成应用程序的微服务。

后续步骤

3.7. 优化路由

OpenShift Container Platform HAProxy 路由器扩展以优化性能。

3.7.1. Ingress Controller(router)性能的基线

OpenShift Container Platform Ingress Controller,或称为路由器,是所有用于 OpenShift Container Platform 服务的外部流量的入站点。

当根据每秒处理的 HTTP 请求来评估单个 HAProxy 路由器性能时,其性能取决于多个因素。特别是:

  • HTTP keep-alive/close 模式
  • 路由类型
  • 对 TLS 会话恢复客户端的支持
  • 每个目标路由的并行连接数
  • 目标路由数
  • 后端服务器页面大小
  • 底层基础结构(网络/SDN 解决方案、CPU 等)

具体环境中的性能会有所不同,红帽实验室在一个有 4 个 vCPU/16GB RAM 的公共云实例中进行测试。一个 HAProxy 路由器处理由后端终止的 100 个路由服务提供 1kB 静态页面,每秒处理以下传输数。

在 HTTP 的 keep-alive 模式下:

EncryptionLoadBalancerServiceHostNetwork

none

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

在 HTTP 关闭(无 keep-alive)情境中:

EncryptionLoadBalancerServiceHostNetwork

none

5719

8273

edge

2729

4069

passthrough

4121

5344

re-encrypt

2320

2941

默认 Ingress Controller 配置使用 ROUTER_THREADS=4,并测试了两个不同的端点发布策略 (LoadBalancerService/hostnetwork) 。TLS 会话恢复用于加密路由。使用 HTTP keep-alive 设置,单个 HAProxy 路由器可在页面大小小到 8 kB 时充满 1 Gbit NIC。

当在使用现代处理器的裸机中运行时,性能可以期望达到以上公共云实例测试性能的大约两倍。这个开销是由公有云的虚拟化层造成的,基于私有云虚拟化的环境也会有类似的开销。下表是有关在路由器后面的应用程序数量的指导信息:

应用程序数量应用程序类型

5-10

静态文件/web 服务器或者缓存代理

100-1000

生成动态内容的应用程序

取决于所使用的技术,HAProxy 通常可支持 5 到 1000 个程序的路由。Ingress Controller 性能可能会受其后面的应用程序的能力和性能的限制,如使用的语言,静态内容或动态内容。

如果有多个服务于应用程序的 Ingress 或路由器,则应该使用路由器分片(router sharding)以帮助横向扩展路由层。

3.7.2. Ingress Controller(路由器)性能优化

OpenShift Container Platform 不再支持通过设置以下环境变量来修改 Ingress Controller 的部署: ROUTER_THREADSROUTER_DEFAULT_TUNNEL_TIMEOUTROUTER_DEFAULT_CLIENT_TIMEOUTROUTER_DEFAULT_SERVER_TIMEOUTRELOAD_INTERVAL

您可以修改 Ingress Controller 的部署,但当 Ingress Operator 被启用时,其配置会被覆盖。

第 4 章 安装后存储配置

安装 OpenShift Container Platform 后,您可以按照自己的要求进一步扩展和自定义集群,包括存储配置。

4.1. 动态置备

4.1.1. 关于动态置备

StorageClass 资源对象描述并分类了可请求的存储,并提供了根据需要为动态置备存储传递参数的方法。StorageClass 也可以作为控制不同级别的存储和访问存储的管理机制。集群管理员(cluster-admin)或存储管理员(storage-admin)可以在无需了解底层存储卷资源的情况下,定义并创建用户可以请求的 StorageClass 对象。

OpenShift Container Platform 的持久性卷框架启用了这个功能,并允许管理员为集群提供持久性存储。该框架还可让用户在不了解底层存储架构的情况下请求这些资源。

很多存储类型都可用于 OpenShift Container Platform 中的持久性卷。虽然它们都可以由管理员静态置备,但有些类型的存储是使用内置供应商和插件 API 动态创建的。

4.1.2. 可用的动态部署插件

OpenShift Container Platform 提供了以下置备程序插件,用于使用集群配置的供应商 API 创建新存储资源的动态部署:

存储类型provisioner 插件名称备注

Red Hat OpenStack Platform(RHOSP)Cinder

kubernetes.io/cinder

 

RHOSP Manila Container Storage Interface(CSI)

manila.csi.openstack.org

安装后, OpenStack Manila CSI Driver Operator 和 ManilaDriver 会自动为所有可用 Manila 共享类型创建动态置备所需的存储类。

AWS Elastic Block Store (EBS)

kubernetes.io/aws-ebs

当在不同的区中使用多个集群进行动态置备时,使用 Key=kubernetes.io/cluster/<cluster_name>,Value=<cluster_id> (每个集群的<cluster_name><cluster_id> 是唯一的)来标记(tag)每个节点。

Azure Disk

kubernetes.io/azure-disk

 

Azure File

kubernetes.io/azure-file

persistent-volume-binder 服务帐户需要相应的权限,以创建并获取 Secret 来存储 Azure 存储帐户和密钥。

GCE 持久性磁盘 (gcePD)

kubernetes.io/gce-pd

在多区(multi-zone)配置中,建议在每个 GCE 项目中运行一个 OpenShift Container Platform 集群,以避免在当前集群没有节点的区域中创建 PV。

VMware vSphere

kubernetes.io/vsphere-volume

 
重要

任何选择的置备程序插件还需要根据相关文档为相关的云、主机或者第三方供应商配置。

4.2. 定义存储类

StorageClass 对象目前是一个全局范围的对象,必须由 cluster-adminstorage-admin 用户创建。

重要

根据使用的平台,Cluster Storage Operator 可能会安装一个默认的存储类。这个存储类由 Operator 拥有和控制。不能在定义注解和标签之外将其删除或修改。如果需要实现不同的行为,则必须定义自定义存储类。

以下小节描述了 StorageClass 对象的基本定义,以及每个支持的插件类型的具体示例。

4.2.1. 基本 StorageClass 对象定义

以下资源显示了用来配置存储类的参数和默认值。这个示例使用 AWS ElasticBlockStore (EBS) 对象定义。

StorageClass 定义示例

kind: StorageClass 1
apiVersion: storage.k8s.io/v1 2
metadata:
  name: gp2 3
  annotations: 4
    storageclass.kubernetes.io/is-default-class: 'true'
    ...
provisioner: kubernetes.io/aws-ebs 5
parameters: 6
  type: gp2
...

1
(必需)API 对象类型。
2
(必需)当前的 apiVersion。
3
(必需)存储类的名称。
4
(可选)存储类的注解。
5
(必需)与这个存储类关联的置备程序类型。
6
(可选)特定置备程序所需的参数,这将根据插件的不同而有所不同。

4.2.2. 存储类注解

要将存储类设置为集群范围的默认值,请在存储类元数据中添加以下注解:

storageclass.kubernetes.io/is-default-class: "true"

例如:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
...

这允许任何没有指定特定存储类的持久性卷声明(PVC)通过默认存储类自动置备。

注意

beta 注解 storageclass.beta.kubernetes.io/is-default-class 当前仍然可用,但将在以后的版本中被删除。

要设置存储类描述,请在存储类元数据中添加以下注解:

kubernetes.io/description: My Storage Class Description

例如:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubernetes.io/description: My Storage Class Description
...

4.2.3. RHOSP Cinder 对象定义

cinder-storageclass.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gold
provisioner: kubernetes.io/cinder
parameters:
  type: fast  1
  availability: nova 2
  fsType: ext4 3

1
在 Cinder 中创建的卷类型。默认为空。
2
可用区如果没有指定可用区,则通常会在所有 OpenShift Container Platform 集群有节点的所有活跃区域间轮换选择。
3
在动态部署卷中创建的文件系统。这个值被复制到动态配置的持久性卷的 fstype 字段中,并在第一个挂载卷时创建文件系统。默认值为 ext4

4.2.4. AWS Elastic Block Store (EBS) 对象定义

aws-ebs-storageclass.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1 1
  iopsPerGB: "10" 2
  encrypted: "true" 3
  kmsKeyId: keyvalue 4
  fsType: ext4 5

1
(必需)选择 io1gp2sc1st1。默认为 gp2。可用的 Amazon 资源名 (ARN) 值请查看 AWS 文档
2
(可选)只适用于 io1 卷。每个 GiB 每秒一次 I/O 操作。AWS 卷插件乘以这个值,再乘以请求卷的大小以计算卷的 IOPS。数值上限为 20,000 IOPS,这是 AWS 支持的最大值。详情请查看 AWS 文档
3
(可选)是否加密 EBS 卷。有效值为 true 或者 false
4
(可选)加密卷时使用的密钥的完整 ARN。如果没有提供任何信息,但 encypted 被设置为 true,则 AWS 会生成一个密钥。有效 ARN 值请查看 AWS 文档
5
(可选)在动态部署卷中创建的文件系统。这个值被复制到动态配置的持久性卷的 fstype 字段中,并在第一个挂载卷时创建文件系统。默认值为 ext4

4.2.5. Azure Disk 对象定义

azure-advanced-disk-storageclass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/azure-disk
volumeBindingMode: WaitForFirstConsumer 1
allowVolumeExpansion: true
parameters:
  kind: Managed 2
  storageaccounttype: Premium_LRS 3
reclaimPolicy: Delete

1
强烈建议使用 WaitForFirstConsumer。这会置备卷,同时允许有足够的存储空间从可用区将 pod 调度到空闲 worker 节点上。
2
可能的值有 Shared (默认)、ManagedDedicated
重要

红帽仅在存储类中支持使用 kind: Managed

使用 SharedDedicated 时,Azure 会创建非受管磁盘,而 OpenShift Container Platform 为机器 OS(root)磁盘创建一个受管磁盘。但是,因为 Azure Disk 不允许在节点上同时使用受管和非受管磁盘,所以使用 SharedDedicated 创建的非受管磁盘无法附加到 OpenShift Container Platform 节点。

3
Azure 存储帐户 SKU 层。默认为空。请注意,高级虚拟机可以同时附加 Standard_LRSPremium_LRS 磁盘,标准虚拟机只能附加 Standard_LRS 磁盘,受管虚拟机只能附加受管磁盘,非受管虚拟机则只能附加非受管磁盘。
  1. 如果 kind 设为 Shared,Azure 会在与集群相同的资源组中的几个共享存储帐户下创建所有未受管磁盘。
  2. 如果 kind 设为 Managed,Azure 会创建新的受管磁盘。
  3. 如果 kind 设为 Dedicated,并且指定了 StorageAccount,Azure 会将指定的存储帐户用于与集群相同的资源组中新的非受管磁盘。为此,请确保:

    • 指定的存储帐户必须位于同一区域。
    • Azure Cloud Provider 必须具有存储帐户的写入权限。
  4. 如果 kind 设为 Dedicated,并且未指定 StorageAccount,Azure 会在与集群相同的资源组中为新的非受管磁盘创建一个新的专用存储帐户。

4.2.6. Azure File 对象定义

Azure File 存储类使用 secret 来存储创建 Azure File 共享所需的 Azure 存储帐户名称和存储帐户密钥。这些权限是在以下流程中创建的。

流程

  1. 定义允许创建和查看 secret 的 ClusterRole 对象:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
    #  name: system:azure-cloud-provider
      name: <persistent-volume-binder-role> 1
    rules:
    - apiGroups: ['']
      resources: ['secrets']
      verbs:     ['get','create']
    1
    要查看并创建 secret 的集群角色名称。
  2. 将集群角色添加到服务帐户:

    $ oc adm policy add-cluster-role-to-user <persistent-volume-binder-role>

    输出示例

     system:serviceaccount:kube-system:persistent-volume-binder

  3. 创建 Azure File StorageClass 对象:

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: <azure-file> 1
    provisioner: kubernetes.io/azure-file
    parameters:
      location: eastus 2
      skuName: Standard_LRS 3
      storageAccount: <storage-account> 4
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    1
    存储类的名称。持久性卷声明使用此存储类来置备关联的持久性卷。
    2
    Azure 存储帐户的位置,如 eastus。默认为空,表示将在 OpenShift Container Platform 集群的位置创建新的 Azure 存储帐户。
    3
    Azure 存储帐户的 SKU 层,如 Standard_LRS。默认为空,表示将使用 Standard_LRS SKU 创建新的 Azure 存储帐户。
    4
    Azure 存储帐户的名称。如果提供了存储帐户,则忽略 skuNamelocation。如果没有提供存储帐户,则存储类会为任何与定义的 skuNamelocation 匹配的帐户搜索与资源组关联的存储帐户。

4.2.6.1. 使用 Azure File 时的注意事项

默认 Azure File 存储类不支持以下文件系统功能:

  • 符号链接
  • 硬链接
  • 扩展属性
  • 稀疏文件
  • 命名管道

另外,Azure File 挂载目录的所有者用户标识符 (UID) 与容器的进程 UID 不同。可在 StorageClass 对象中指定 uid 挂载选项来定义用于挂载的目录的特定用户标识符。

以下 StorageClass 对象演示了修改用户和组标识符,以及为挂载的目录启用符号链接。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azure-file
mountOptions:
  - uid=1500 1
  - gid=1500 2
  - mfsymlinks 3
provisioner: kubernetes.io/azure-file
parameters:
  location: eastus
  skuName: Standard_LRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
1
指定用于挂载的目录的用户标识符。
2
指定用于挂载的目录的组标识符。
3
启用符号链接。

4.2.7. GCE PersistentDisk (gcePD) 对象定义

gce-pd-storageclass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard 1
  replication-type: none
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Delete

1
选择 pd-standardpd-ssd。默认为 pd-standard

4.2.8. VMware vSphere 对象定义

vsphere-storageclass.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/vsphere-volume 1
parameters:
  diskformat: thin 2

1
有关在 OpenShift Container Platform 中使用 VMware vSphere 的详情,请参阅 VMware vSphere 文档
2
diskformatthinzeroedthickeagerzeroedthick 都是有效的磁盘格式。如需有关磁盘格式类型的更多详情,请参阅 vSphere 文档。默认值为 thin

4.3. 更改默认存储类

如果使用 AWS,请使用以下流程更改默认存储类。这个过程假设您定义了两个存储类,gp2standard,您想要将默认存储类从 gp2 改为 standard

  1. 列出存储类:

    $ oc get storageclass

    输出示例

    NAME                 TYPE
    gp2 (default)        kubernetes.io/aws-ebs 1
    standard             kubernetes.io/aws-ebs

    1
    (默认) 表示默认存储类。
  2. 将默认存储类的 storageclass.kubernetes.io/is-default-class 注解的值更改为 false:

    $ oc patch storageclass gp2 -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
  3. 通过添加或修改注解 storageclass.kubernetes.io/is-default-class=true 来使另一个存储类作为默认设置

    $ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
  4. 确认更改:

    $ oc get storageclass

    输出示例

    NAME                 TYPE
    gp2                  kubernetes.io/aws-ebs
    standard (default)   kubernetes.io/aws-ebs

4.4. 优化存储

优化存储有助于最小化所有资源中的存储使用。通过优化存储,管理员可帮助确保现有存储资源以高效的方式工作。

4.5. 可用的持久性存储选项

了解持久性存储选项,以便可以优化 OpenShift Container Platform 环境。

表 4.1. 可用存储选项

存储类型描述例子

Block

  • 在操作系统 (OS) 中作为块设备
  • 适用于需要完全控制存储,并绕过文件系统在低层直接操作文件的应用程序
  • 也称为存储区域网络 (SAN)
  • 不可共享,这意味着,每次只有一个客户端可以挂载这种类型的端点

AWS EBS 和 VMware vSphere 支持在 OpenShift Container Platform 中的原生动态持久性卷 (PV)置备 。

File

  • 在 OS 中作为要挂载的文件系统导出
  • 也称为网络附加存储(Network Attached Storage,NAS)
  • 取决于不同的协议、实现、厂商及范围,其并行性、延迟、文件锁定机制和其它功能可能会有很大不同。

RHEL NFS, NetApp NFS [1],和厂商 NFS

对象

  • 通过 REST API 端点访问
  • 可配置用于 OpenShift Container Platform Registry
  • 应用程序必须在应用程序和(/或)容器中构建其驱动程序。

AWS S3

  1. NetApp NFS 在使用 Trident 插件时支持动态 PV 置备。
重要

目前,OpenShift Container Platform 4.5 不支持 CNS。

4.6. 推荐的可配置存储技术

下表总结了为给定的 OpenShift Container Platform 集群应用程序推荐的可配置存储技术。

表 4.2. 推荐的、可配置的存储技术

存储类型ROX1RWX2Registry扩展的 registry指标3日志记录Apps

1 ReadOnlyMany

2 ReadWriteMany

3 Prometheus 是用于指标数据的底层技术。

4 这不适用于物理磁盘、虚拟机物理磁盘、VMDK 、NFS 回送、AWS EBS 和 Azure 磁盘。

5 对于指标数据,使用 ReadWriteMany (RWX) 访问模式的文件存储是不可靠的。如果使用文件存储,请不要在配置用于指标数据的持久性卷声明(PVC)上配置 RWX 访问模式。

6 要进行日志记录,使用任何共享存储都会是一个反 pattern。每个 elasticsearch 都需要一个卷。

7 对象存储不会通过 OpenShift Container Platform 的 PV 或 PVC 使用。应用程序必须与对象存储 REST API 集成。

Block

4

可配置

无法配置

推荐的

推荐的

推荐的

File

4

可配置

可配置

可配置5

可配置6

推荐的

对象

推荐的

推荐的

无法配置

无法配置

无法配置7

注意

扩展的容器镜像仓库(registry)是一个 OpenShift Container Platform 容器镜像仓库,它有两个或更多个 pod 运行副本。

4.6.1. 特定应用程序存储建议

重要

测试显示在 Red Hat Enterprise Linux(RHEL)中使用 NFS 服务器作为核心服务的存储后端的问题。这包括 OpenShift Container Registry 和 Quay,Prometheus 用于监控存储,以及 Elasticsearch 用于日志存储。因此,不推荐使用 RHEL NFS 作为 PV 后端用于核心服务。

市场上的其他 NFS 实现可能没有这些问题。如需了解更多与此问题相关的信息,请联络相关的 NFS 厂商。

4.6.1.1. Registry

在一个非扩展的/高可用性 (HA) OpenShift Container Platform registry 集群部署中:

  • 存储技术不需要支持 RWX 访问模式。
  • 存储技术必须保证读写一致性。
  • 首选存储技术是对象存储,然后是块存储。
  • 对于应用于生产环境工作负载的 OpenShift Container Platform Registry 集群部署,我们不推荐使用文件存储。

4.6.1.2. 扩展的 registry

在扩展的/HA OpenShift Container Platform registry 集群部署中:

  • 存储技术必须支持 RWX 访问模式,且必须保证读写一致性。
  • 首选存储技术是对象存储。
  • 支持 Amazon Simple Storage Service(Amazon S3)、Google Cloud Storage(GCS)、Microsoft Azure Blob Storage 和 OpenStack Swift。
  • 对象存储应该兼容 S3 或 Swift。
  • 对于应用于生产环境负载的扩展的/HA OpenShift Container Platform registry 集群部署,不建议使用文件存储。
  • 对于非云平台,如 vSphere 和裸机安装,唯一可配置的技术是文件存储。
  • 块存储是不可配置的。

4.6.1.3. 指标

在 OpenShift Container Platform 托管的 metrics 集群部署中:

  • 首选存储技术是块存储。
  • 对象存储是不可配置的。
重要

在带有生产环境负载的托管 metrics 集群部署中不推荐使用文件存储。

4.6.1.4. 日志记录

在 OpenShift Container Platform 托管的日志集群部署中:

  • 首选存储技术是块存储。
  • 对于应用于生产环境负载的扩展的/HA OpenShift Container Platform registry 集群部署,不建议使用文件存储。
  • 对象存储是不可配置的。
重要

测试显示,在 RHEL 中使用 NFS 服务器作为核心服务的存储后端可能会出现问题。这包括用于日志存储的 Elasticsearch。因此,不推荐使用 RHEL NFS 作为 PV 后端用于核心服务。

市场上的其他 NFS 实现可能没有这些问题。如需了解更多与此问题相关的信息,请联络相关的 NFS 厂商。

4.6.1.5. 应用程序

应用程序的用例会根据不同应用程序而不同,如下例所示:

  • 支持动态 PV 部署的存储技术的挂载时间延迟较低,且不与节点绑定来支持一个健康的集群。
  • 应用程序开发人员需要了解应用程序对存储的要求,以及如何与所需的存储一起工作以确保应用程序扩展或者与存储层交互时不会出现问题。

4.6.2. 其他特定的应用程序存储建议

  • OpenShift Container Platform 内部 etcd:为了获得最好的 etcd 可靠性,首选使用具有最低一致性延迟的存储技术。
  • 强烈建议您使用带有可快速处理串口写入(fsync)的存储的 etcd,比如 NVMe 或者 SSD。不建议使用 Ceph、NFS 和 spinning 磁盘。
  • Red Hat OpenStack Platform(RHOSP)Cinder: RHOSP Cinder 倾向于在 ROX 访问模式用例中使用。
  • 数据库:数据库(RDBMS 、nosql DBs 等等)倾向于使用专用块存储来获得最好的性能。

4.7. 部署 OpenShift Container Storage

Red Hat OpenShift Container Storage 是 OpenShift Container Platform 支持的文件、块和对象存储的持久性存储供应商,可以在内部或混合云环境中使用。作为红帽存储解决方案,Red Hat OpenShift Container Storage 与 OpenShift Container Platform 完全集成,用于部署、管理和监控。

如果您要寻找 Red Hat OpenShift Container Storage 的相关信息请参阅以下 Red Hat OpenShift Container Storage 文档:

新的、已知的问题、显著的程序错误修复以及技术预览

OpenShift Container Storage 4.5 发行注记

支持的工作负载、布局、硬件和软件要求、调整和扩展建议

规划 OpenShift Container Storage 4.5 部署

有关在您的环境没有直接连接到互联网时准备部署的说明

准备在断开连接的环境中部署 OpenShift Container Storage 4.5

部署 OpenShift Container Storage 以使用外部 Red Hat Ceph Storage 集群的说明

以外部模式部署 OpenShift Container Storage 4.5

有关将 OpenShift Container Storage 部署到裸机基础架构上的本地存储的说明

使用裸机基础架构部署 OpenShift Container Storage 4.5

在 Red Hat OpenShift Container Platform VMWare vSphere 集群上部署 OpenShift Container Storage 的说明

在 VMWare vSphere 上部署 OpenShift Container Storage 4.5

有关使用 Amazon Web Services 进行本地或云存储的部署 OpenShift Container Storage 的说明

使用 Amazon Web Services 部署 OpenShift Container Storage 4.5

在现有 Red Hat OpenShift Container Platform Google Cloud 集群上部署和管理 OpenShift Container Storage 的说明

使用 Google Cloud 部署和管理 OpenShift Container Storage 4.5

在现有 Red Hat OpenShift Container Platform Azure 集群上部署和管理 OpenShift Container Storage 的说明

使用 Microsoft Azure 部署和管理 OpenShift Container Storage 4.5

管理 Red Hat OpenShift Container Storage 4.5 集群

管理 OpenShift Container Storage 4.5

监控 Red Hat OpenShift Container Storage 4.5 集群

监控 Red Hat OpenShift Container Storage 4.5

解决操作过程中遇到的问题

OpenShift Container Storage 4.5 故障排除

将 OpenShift Container Platform 集群从版本 3 迁移到版本 4

迁移

第 5 章 准备供用户使用

安装 OpenShift Container Platform 后,您可以按照您的要求进一步扩展和自定义集群,包括为用户准备步骤。

5.1. 了解身份提供程序配置

OpenShift Container Platform control plane 包含内置的 OAuth 服务器。开发人员和管理员获取 OAuth 访问令牌,以完成自身的 API 身份验证。

作为管理员,您可以在安装集群后通过配置 OAuth 来指定身份提供程序。

5.1.1. 关于 OpenShift Container Platform 中的身份提供程序

默认情况下,集群中只有 kubeadmin 用户。要指定身份提供程序,您必须创建一个自定义资源(CR) 来描述该身份提供程序并把它添加到集群中。

注意

OpenShift Container Platform 用户名不能包括 /:%

5.1.2. 支持的身份提供程序

您可以配置以下类型的身份提供程序:

用户身份提供程序描述

HTPasswd

配置 htpasswd 身份提供程序,针对使用 htpasswd 生成的文件验证用户名和密码。

Keystone

配置 keystone 身份提供程序,将 OpenShift Container Platform 集群与 Keystone 集成以启用共享身份验证,用配置的 OpenStack Keystone v3 服务器将用户存储到内部数据库中。

LDAP

配置 ldap 身份提供程序,使用简单绑定身份验证来针对 LDAPv3 服务器验证用户名和密码。

基本身份验证(Basic authentication)

配置 basic-authentication 身份提供程序,以便用户使用针对远程身份提供程序验证的凭证来登录 OpenShift Container Platform。基本身份验证是一种通用后端集成机制。

请求标头(Request header)

配置 request-header 身份提供程序,标识请求标头值中的用户,例如 X-Remote-User。它通常与设定请求标头值的身份验证代理一起使用。

Github 或 GitHub Enterprise

配置 github 身份提供程序,针对 GitHub 或 GitHub Enterprise 的 OAuth 身份验证服务器验证用户名和密码。

GitLab

配置 gitlab 身份提供程序,使用 GitLab.com 或任何其他 GitLab 实例作为身份提供程序。

Google

配置 google 身份提供程序,使用 Google 的 OpenID Connect 集成

OpenID Connect

配置 oidc 身份提供程序,使用授权代码流与 OpenID Connect 身份提供程序集成。

定义了身份提供程序后,可以使用 RBAC 来定义并应用权限

5.1.3. 身份提供程序参数

以下是所有身份提供程序通用的参数:

参数描述

name

此提供程序名称作为前缀放在提供程序用户名前,以此组成身份名称。

mappingMethod

定义在用户登录时如何将新身份映射到用户。输入以下值之一:

claim
默认值。使用身份的首选用户名置备用户。如果具有该用户名的用户已映射到另一身份,则失败。
lookup
查找现有的身份、用户身份映射和用户,但不自动置备用户或身份。这允许集群管理员手动或使用外部流程设置身份和用户。使用此方法需要手动置备用户。
generate
使用身份的首选用户名置备用户。如果拥有首选用户名的用户已映射到现有的身份,则生成一个唯一用户名。例如:myuser2。此方法不应与需要在 OpenShift Container Platform 用户名和身份提供程序用户名(如 LDAP 组同步)之间完全匹配的外部流程一同使用。
add
使用身份的首选用户名置备用户。如果已存在具有该用户名的用户,此身份将映射到现有用户,添加到该用户的现有身份映射中。如果配置了多个身份提供程序并且它们标识同一组用户并映射到相同的用户名,则需要进行此操作。
注意

在添加或更改身份提供程序时,您可以通过把 mappingMethod 参数设置为 add,将新提供程序中的身份映射到现有的用户。

5.1.4. 身份提供程序 CR 示例

以下自定义资源 (CR) 显示用来配置身份提供程序的参数和默认值。示例中使用了 HTPasswd 身份提供程序。

身份提供程序 CR 示例

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: my_identity_provider 1
    mappingMethod: claim 2
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpass-secret 3

1
此提供程序名称作为前缀放在提供程序用户名前,以此组成身份名称。
2
控制如何在此提供程序的身份和 User 对象之间建立映射。
3
包含使用 htpasswd 生成的文件的现有 secret。

5.2. 使用 RBAC 定义和应用权限

理解并应用基于角色的访问控制。

5.2.1. RBAC 概述

基于角色的访问控制 (RBAC) 对象决定是否允许用户在项目内执行给定的操作。

集群管理员可以使用集群角色和绑定来控制谁对 OpenShift Container Platform 平台本身和所有项目具有各种访问权限等级。

开发人员可以使用本地角色和绑定来控制谁有权访问他们的项目。请注意,授权是与身份验证分开的一个步骤,身份验证更在于确定执行操作的人的身份。

授权通过使用以下几项来管理:

授权对象描述

规则

一组对象上允许的操作集合。例如,用户或服务帐户能否创建(create) Pod。

角色

规则的集合。可以将用户和组关联或绑定到多个角色。

绑定

用户和/组与角色之间的关联。

控制授权的 RBAC 角色和绑定有两个级别:

RBAC 级别描述

集群 RBAC

对所有项目均适用的角色和绑定。集群角色存在于集群范围,集群角色绑定只能引用集群角色。

本地 RBAC

作用于特定项目的角色和绑定。虽然本地角色只存在于单个项目中,但本地角色绑定可以同时引用集群和本地角色。

集群角色绑定是存在于集群级别的绑定。角色绑定存在于项目级别。集群角色 view 必须使用本地角色绑定来绑定到用户,以便该用户能够查看项目。只有集群角色不提供特定情形所需的权限集合时才应创建本地角色。

这种双级分级结构允许通过集群角色在多个项目间重复使用,同时允许通过本地角色在个别项目中自定义。

在评估过程中,同时使用集群角色绑定和本地角色绑定。例如:

  1. 选中集群范围的“allow”规则。
  2. 选中本地绑定的“allow”规则。
  3. 默认为拒绝。

5.2.1.1. 默认集群角色

OpenShift Container Platform 包括了一组默认的集群角色,您可以在集群范围或本地将它们绑定到用户和组。如果需要,可以手动修改默认集群角色。

默认集群角色描述

admin

项目管理者。如果在本地绑定中使用,则 admin 有权查看项目中的任何资源,并且修改项目中除配额外的任何资源。

basic-user

此用户可以获取有关项目和用户的基本信息。

cluster-admin

此超级用户可以在任意项目中执行任何操作。当使用本地绑定来绑定一个用户时,这些用户可以完全控制项目中每一资源的配额和所有操作。

cluster-status

此用户可以获取基本的集群状态信息。

edit

此用户可以修改项目中大多数对象,但无权查看或修改角色或绑定。

self-provisioner

此用户可以创建自己的项目。

view

此用户无法进行任何修改,但可以查看项目中的大多数对象。不能查看或修改角色或绑定。

请注意本地和集群绑定之间的区别。例如,如果使用本地角色绑定将 cluster-admin 角色绑定到一个用户,这可能看似该用户具有了集群管理员的特权。事实并非如此。将 cluster-admin 绑定到项目里的某一用户,仅会将该项目的超级管理员特权授予这一用户。该用户具有集群角色 admin 的权限,以及该项目的一些额外权限,例如能够编辑项目的速率限制。通过 web 控制台 UI 操作时此绑定可能会令人混淆,因为它不会列出绑定到真正集群管理员的集群角色绑定。然而,它会列出可用来本地绑定 cluster-admin 的本地角色绑定。

下方展示了集群角色、本地角色、集群角色绑定、本地角色绑定、用户、组和服务帐户之间的关系。

OpenShift Container Platform RBAC

5.2.1.2. 评估授权

OpenShift Container Platform 使用以下几项来评估授权:

身份
用户名以及用户所属组的列表。
操作

您执行的操作。在大多数情况下,这由以下几项组成:

  • 项目:您访问的项目。项目是一种附带额外注解的 Kubernetes 命名空间,使一个社区的用户可以在与其他社区隔离的前提下组织和管理其内容。
  • 操作动词:操作本身:getlistcreateupdatedeletedeletecollectionwatch
  • 资源名称:您访问的 API 端点。
绑定
绑定的完整列表,用户或组与角色之间的关联。

OpenShift Container Platform 通过以下几个步骤评估授权:

  1. 使用身份和项目范围操作来查找应用到用户或所属组的所有绑定。
  2. 使用绑定来查找应用的所有角色。
  3. 使用角色来查找应用的所有规则。
  4. 针对每一规则检查操作,以查找匹配项。
  5. 如果未找到匹配的规则,则默认拒绝该操作。
提示

请记住,用户和组可以同时关联或绑定到多个角色。

项目管理员可以使用 CLI 查看本地角色和绑定信息,包括与每个角色关联的操作动词和资源的一览表。

重要

通过本地绑定来绑定到项目管理员的集群角色会限制在一个项目内。不会像授权给 cluster-adminsystem:admin 的集群角色那样在集群范围绑定。

集群角色是在集群级别定义的角色,但可在集群级别或项目级别进行绑定。

5.2.1.2.1. 集群角色聚合

默认的 admin、edit、view 和 cluster-reader 集群角色支持集群角色聚合,其中每个角色的集群规则可在创建了新规则时动态更新。只有通过创建自定义资源扩展 Kubernetes API 时,此功能才有意义。

5.2.2. 项目和命名空间

Kubernetes 命名空间提供设定集群中资源范围的机制。Kubernetes 文档中提供有关命名空间的更多信息。

命名空间为以下对象提供唯一范围:

  • 指定名称的资源,以避免基本命名冲突。
  • 委派给可信用户的管理授权。
  • 限制社区资源消耗的能力。

系统中的大多数对象都通过命名空间来设定范围,但一些对象不在此列且没有命名空间,如节点和用户。

项目是附带额外注解的 Kubernetes 命名空间,是管理常规用户资源访问权限的集中载体。通过项目,一个社区的用户可以在与其他社区隔离的前提下组织和管理其内容。用户必须由管理员授予对项目的访问权限;或者,如果用户有权创建项目,则自动具有自己创建项目的访问权限。

项目可以有单独的 namedisplayNamedescription

  • 其中必备的 name 是项目的唯一标识符,在使用 CLI 工具或 API 时最常见。名称长度最多为 63 个字符。
  • 可选的 displayName 是项目在 web 控制台中的显示形式(默认为 name)。
  • 可选的 description 可以为项目提供更加详细的描述,也可显示在 web 控制台中。

每个项目限制了自己的一组:

对象描述

对象(object)

Pod、服务和复制控制器等。

策略(policy)

用户能否对对象执行操作的规则。

约束(constraint)

对各种对象进行限制的配额。

服务帐户

服务帐户自动使用项目中对象的指定访问权限进行操作。

集群管理员可以创建项目,并可将项目的管理权限委派给用户社区的任何成员。集群管理员也可以允许开发人员创建自己的项目。

开发人员和管理员可以使用 CLI 或 Web 控制台与项目交互。

5.2.3. 默认项目

OpenShift Container Platform 附带若干默认项目,名称以 openshift-- 开头的项目对用户而言最为重要。这些项目托管作为 Pod 运行的主要组件和其他基础架构组件。在这些命名空间中创建的带有关键 (critical) Pod 注解的 Pod 是很重要的,它们可以保证被 kubelet 准入。在这些命名空间中为主要组件创建的 Pod 已标记为“critical”。

注意

您无法将 SCC 分配给在以下某一默认命名空间中创建的 Pod: defaultkube-systemkube-publicopenshift-nodeopenshift-infraopenshift。您不能使用这些命名空间用来运行 pod 或服务。

5.2.4. 查看集群角色和绑定

通过 oc describe 命令,可以使用 oc CLI 来查看集群角色和绑定。

先决条件

  • 安装 oc CLI。
  • 获取查看集群角色和绑定的权限。

在集群范围内绑定了 cluster-admin 默认集群角色的用户可以对任何资源执行任何操作,包括查看集群角色和绑定。

流程

  1. 查看集群角色及其关联的规则集:

    $ oc describe clusterrole.rbac

    输出示例

    Name:         admin
    Labels:       kubernetes.io/bootstrapping=rbac-defaults
    Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
    PolicyRule:
      Resources                                                  Non-Resource URLs  Resource Names  Verbs
      ---------                                                  -----------------  --------------  -----
      .packages.apps.redhat.com                                  []                 []              [* create update patch delete get list watch]
      imagestreams                                               []                 []              [create delete deletecollection get list patch update watch create get list watch]
      imagestreams.image.openshift.io                            []                 []              [create delete deletecollection get list patch update watch create get list watch]
      secrets                                                    []                 []              [create delete deletecollection get list patch update watch get list watch create delete deletecollection patch update]
      buildconfigs/webhooks                                      []                 []              [create delete deletecollection get list patch update watch get list watch]
      buildconfigs                                               []                 []              [create delete deletecollection get list patch update watch get list watch]
      buildlogs                                                  []                 []              [create delete deletecollection get list patch update watch get list watch]
      deploymentconfigs/scale                                    []                 []              [create delete deletecollection get list patch update watch get list watch]
      deploymentconfigs                                          []                 []              [create delete deletecollection get list patch update watch get list watch]
      imagestreamimages                                          []                 []              [create delete deletecollection get list patch update watch get list watch]
      imagestreammappings                                        []                 []              [create delete deletecollection get list patch update watch get list watch]
      imagestreamtags                                            []                 []              [create delete deletecollection get list patch update watch get list watch]
      processedtemplates                                         []                 []              [create delete deletecollection get list patch update watch get list watch]
      routes                                                     []                 []              [create delete deletecollection get list patch update watch get list watch]
      templateconfigs                                            []                 []              [create delete deletecollection get list patch update watch get list watch]
      templateinstances                                          []                 []              [create delete deletecollection get list patch update watch get list watch]
      templates                                                  []                 []              [create delete deletecollection get list patch update watch get list watch]
      deploymentconfigs.apps.openshift.io/scale                  []                 []              [create delete deletecollection get list patch update watch get list watch]
      deploymentconfigs.apps.openshift.io                        []                 []              [create delete deletecollection get list patch update watch get list watch]
      buildconfigs.build.openshift.io/webhooks                   []                 []              [create delete deletecollection get list patch update watch get list watch]
      buildconfigs.build.openshift.io                            []                 []              [create delete deletecollection get list patch update watch get list watch]
      buildlogs.build.openshift.io                               []                 []              [create delete deletecollection get list patch update watch get list watch]
      imagestreamimages.image.openshift.io                       []                 []              [create delete deletecollection get list patch update watch get list watch]
      imagestreammappings.image.openshift.io                     []                 []              [create delete deletecollection get list patch update watch get list watch]
      imagestreamtags.image.openshift.io                         []                 []              [create delete deletecollection get list patch update watch get list watch]
      routes.route.openshift.io                                  []                 []              [create delete deletecollection get list patch update watch get list watch]
      processedtemplates.template.openshift.io                   []                 []              [create delete deletecollection get list patch update watch get list watch]
      templateconfigs.template.openshift.io                      []                 []              [create delete deletecollection get list patch update watch get list watch]
      templateinstances.template.openshift.io                    []                 []              [create delete deletecollection get list patch update watch get list watch]
      templates.template.openshift.io                            []                 []              [create delete deletecollection get list patch update watch get list watch]
      serviceaccounts                                            []                 []              [create delete deletecollection get list patch update watch impersonate create delete deletecollection patch update get list watch]
      imagestreams/secrets                                       []                 []              [create delete deletecollection get list patch update watch]
      rolebindings                                               []                 []              [create delete deletecollection get list patch update watch]
      roles                                                      []                 []              [create delete deletecollection get list patch update watch]
      rolebindings.authorization.openshift.io                    []                 []              [create delete deletecollection get list patch update watch]
      roles.authorization.openshift.io                           []                 []              [create delete deletecollection get list patch update watch]
      imagestreams.image.openshift.io/secrets                    []                 []              [create delete deletecollection get list patch update watch]
      rolebindings.rbac.authorization.k8s.io                     []                 []              [create delete deletecollection get list patch update watch]
      roles.rbac.authorization.k8s.io                            []                 []              [create delete deletecollection get list patch update watch]
      networkpolicies.extensions                                 []                 []              [create delete deletecollection patch update create delete deletecollection get list patch update watch get list watch]
      networkpolicies.networking.k8s.io                          []                 []              [create delete deletecollection patch update create delete deletecollection get list patch update watch get list watch]
      configmaps                                                 []                 []              [create delete deletecollection patch update get list watch]
      endpoints                                                  []                 []              [create delete deletecollection patch update get list watch]
      persistentvolumeclaims                                     []                 []              [create delete deletecollection patch update get list watch]
      pods                                                       []                 []              [create delete deletecollection patch update get list watch]
      replicationcontrollers/scale                               []                 []              [create delete deletecollection patch update get list watch]
      replicationcontrollers                                     []                 []              [create delete deletecollection patch update get list watch]
      services                                                   []                 []              [create delete deletecollection patch update get list watch]
      daemonsets.apps                                            []                 []              [create delete deletecollection patch update get list watch]
      deployments.apps/scale                                     []                 []              [create delete deletecollection patch update get list watch]
      deployments.apps                                           []                 []              [create delete deletecollection patch update get list watch]
      replicasets.apps/scale                                     []                 []              [create delete deletecollection patch update get list watch]
      replicasets.apps                                           []                 []              [create delete deletecollection patch update get list watch]
      statefulsets.apps/scale                                    []                 []              [create delete deletecollection patch update get list watch]
      statefulsets.apps                                          []                 []              [create delete deletecollection patch update get list watch]
      horizontalpodautoscalers.autoscaling                       []                 []              [create delete deletecollection patch update get list watch]
      cronjobs.batch                                             []                 []              [create delete deletecollection patch update get list watch]
      jobs.batch                                                 []                 []              [create delete deletecollection patch update get list watch]
      daemonsets.extensions                                      []                 []              [create delete deletecollection patch update get list watch]
      deployments.extensions/scale                               []                 []              [create delete deletecollection patch update get list watch]
      deployments.extensions                                     []                 []              [create delete deletecollection patch update get list watch]
      ingresses.extensions                                       []                 []              [create delete deletecollection patch update get list watch]
      replicasets.extensions/scale                               []                 []              [create delete deletecollection patch update get list watch]
      replicasets.extensions                                     []                 []              [create delete deletecollection patch update get list watch]
      replicationcontrollers.extensions/scale                    []                 []              [create delete deletecollection patch update get list watch]
      poddisruptionbudgets.policy                                []                 []              [create delete deletecollection patch update get list watch]
      deployments.apps/rollback                                  []                 []              [create delete deletecollection patch update]
      deployments.extensions/rollback                            []                 []              [create delete deletecollection patch update]
      catalogsources.operators.coreos.com                        []                 []              [create update patch delete get list watch]
      clusterserviceversions.operators.coreos.com                []                 []              [create update patch delete get list watch]
      installplans.operators.coreos.com                          []                 []              [create update patch delete get list watch]
      packagemanifests.operators.coreos.com                      []                 []              [create update patch delete get list watch]
      subscriptions.operators.coreos.com                         []                 []              [create update patch delete get list watch]
      buildconfigs/instantiate                                   []                 []              [create]
      buildconfigs/instantiatebinary                             []                 []              [create]
      builds/clone                                               []                 []              [create]
      deploymentconfigrollbacks                                  []                 []              [create]
      deploymentconfigs/instantiate                              []                 []              [create]
      deploymentconfigs/rollback                                 []                 []              [create]
      imagestreamimports                                         []                 []              [create]
      localresourceaccessreviews                                 []                 []              [create]
      localsubjectaccessreviews                                  []                 []              [create]
      podsecuritypolicyreviews                                   []                 []              [create]
      podsecuritypolicyselfsubjectreviews                        []                 []              [create]
      podsecuritypolicysubjectreviews                            []                 []              [create]
      resourceaccessreviews                                      []                 []              [create]
      routes/custom-host                                         []                 []              [create]
      subjectaccessreviews                                       []                 []              [create]
      subjectrulesreviews                                        []                 []              [create]
      deploymentconfigrollbacks.apps.openshift.io                []                 []              [create]
      deploymentconfigs.apps.openshift.io/instantiate            []                 []              [create]
      deploymentconfigs.apps.openshift.io/rollback               []                 []              [create]
      localsubjectaccessreviews.authorization.k8s.io             []                 []              [create]
      localresourceaccessreviews.authorization.openshift.io      []                 []              [create]
      localsubjectaccessreviews.authorization.openshift.io       []                 []              [create]
      resourceaccessreviews.authorization.openshift.io           []                 []              [create]
      subjectaccessreviews.authorization.openshift.io            []                 []              [create]
      subjectrulesreviews.authorization.openshift.io             []                 []              [create]
      buildconfigs.build.openshift.io/instantiate                []                 []              [create]
      buildconfigs.build.openshift.io/instantiatebinary          []                 []              [create]
      builds.build.openshift.io/clone                            []                 []              [create]
      imagestreamimports.image.openshift.io                      []                 []              [create]
      routes.route.openshift.io/custom-host                      []                 []              [create]
      podsecuritypolicyreviews.security.openshift.io             []                 []              [create]
      podsecuritypolicyselfsubjectreviews.security.openshift.io  []                 []              [create]
      podsecuritypolicysubjectreviews.security.openshift.io      []                 []              [create]
      jenkins.build.openshift.io                                 []                 []              [edit view view admin edit view]
      builds                                                     []                 []              [get create delete deletecollection get list patch update watch get list watch]
      builds.build.openshift.io                                  []                 []              [get create delete deletecollection get list patch update watch get list watch]
      projects                                                   []                 []              [get delete get delete get patch update]
      projects.project.openshift.io                              []                 []              [get delete get delete get patch update]
      namespaces                                                 []                 []              [get get list watch]
      pods/attach                                                []                 []              [get list watch create delete deletecollection patch update]
      pods/exec                                                  []                 []              [get list watch create delete deletecollection patch update]
      pods/portforward                                           []                 []              [get list watch create delete deletecollection patch update]
      pods/proxy                                                 []                 []              [get list watch create delete deletecollection patch update]
      services/proxy                                             []                 []              [get list watch create delete deletecollection patch update]
      routes/status                                              []                 []              [get list watch update]
      routes.route.openshift.io/status                           []                 []              [get list watch update]
      appliedclusterresourcequotas                               []                 []              [get list watch]
      bindings                                                   []                 []              [get list watch]
      builds/log                                                 []                 []              [get list watch]
      deploymentconfigs/log                                      []                 []              [get list watch]
      deploymentconfigs/status                                   []                 []              [get list watch]
      events                                                     []                 []              [get list watch]
      imagestreams/status                                        []                 []              [get list watch]
      limitranges                                                []                 []              [get list watch]
      namespaces/status                                          []                 []              [get list watch]
      pods/log                                                   []                 []              [get list watch]
      pods/status                                                []                 []              [get list watch]
      replicationcontrollers/status                              []                 []              [get list watch]
      resourcequotas/status                                      []                 []              [get list watch]
      resourcequotas                                             []                 []              [get list watch]
      resourcequotausages                                        []                 []              [get list watch]
      rolebindingrestrictions                                    []                 []              [get list watch]
      deploymentconfigs.apps.openshift.io/log                    []                 []              [get list watch]
      deploymentconfigs.apps.openshift.io/status                 []                 []              [get list watch]
      controllerrevisions.apps                                   []                 []              [get list watch]
      rolebindingrestrictions.authorization.openshift.io         []                 []              [get list watch]
      builds.build.openshift.io/log                              []                 []              [get list watch]
      imagestreams.image.openshift.io/status                     []                 []              [get list watch]
      appliedclusterresourcequotas.quota.openshift.io            []                 []              [get list watch]
      imagestreams/layers                                        []                 []              [get update get]
      imagestreams.image.openshift.io/layers                     []                 []              [get update get]
      builds/details                                             []                 []              [update]
      builds.build.openshift.io/details                          []                 []              [update]
    
    
    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
    	  ---------                                           -----------------  --------------  -----
    	  selfsubjectrulesreviews                             []                 []              [create]
    	  selfsubjectaccessreviews.authorization.k8s.io       []                 []              [create]
    	  selfsubjectrulesreviews.authorization.openshift.io  []                 []              [create]
    	  clusterroles.rbac.authorization.k8s.io              []                 []              [get list watch]
    	  clusterroles                                        []                 []              [get list]
    	  clusterroles.authorization.openshift.io             []                 []              [get list]
    	  storageclasses.storage.k8s.io                       []                 []              [get list]
    	  users                                               []                 [~]             [get]
    	  users.user.openshift.io                             []                 [~]             [get]
    	  projects                                            []                 []              [list watch]
    	  projects.project.openshift.io                       []                 []              [list watch]
    	  projectrequests                                     []                 []              [list]
    	  projectrequests.project.openshift.io                []                 []              [list]
    
    Name:         cluster-admin
    Labels:       kubernetes.io/bootstrapping=rbac-defaults
    Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
    PolicyRule:
    Resources  Non-Resource URLs  Resource Names  Verbs
    ---------  -----------------  --------------  -----
    *.*        []                 []              [*]
               [*]                []              [*]
    
    ...

  2. 查看当前的集群角色绑定集合,这显示绑定到不同角色的用户和组:

    $ oc describe clusterrolebinding.rbac

    输出示例

    Name:         alertmanager-main
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  ClusterRole
      Name:  alertmanager-main
    Subjects:
      Kind            Name               Namespace
      ----            ----               ---------
      ServiceAccount  alertmanager-main  openshift-monitoring
    
    
    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:         cloud-credential-operator-rolebinding
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  ClusterRole
      Name:  cloud-credential-operator-role
    Subjects:
      Kind            Name     Namespace
      ----            ----     ---------
      ServiceAccount  default  openshift-cloud-credential-operator
    
    
    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
      ----   ----            ---------
      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-api-manager-rolebinding
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  ClusterRole
      Name:  cluster-api-manager-role
    Subjects:
      Kind            Name     Namespace
      ----            ----     ---------
      ServiceAccount  default  openshift-machine-api
    
    ...

5.2.5. 查看本地角色和绑定

使用 oc describe 命令通过 oc CLI 来查看本地角色和绑定。

先决条件

  • 安装 oc CLI。
  • 获取查看本地角色和绑定的权限:

    • 在集群范围内绑定了 cluster-admin 默认集群角色的用户可以对任何资源执行任何操作,包括查看本地角色和绑定。
    • 本地绑定了 admin 默认集群角色的用户可以查看并管理项目中的角色和绑定。

流程

  1. 查看当前本地角色绑定集合,这显示绑定到当前项目的不同角色的用户和组:

    $ oc describe rolebinding.rbac
  2. 要查其他项目的本地角色绑定,请向命令中添加 -n 标志:

    $ oc describe rolebinding.rbac -n joe-project

    输出示例

    Name:         admin
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  ClusterRole
      Name:  admin
    Subjects:
      Kind  Name        Namespace
      ----  ----        ---------
      User  kube:admin
    
    
    Name:         system:deployers
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows deploymentconfigs in this namespace to rollout pods in
                    this namespace.  It is auto-managed by a controller; remove
                    subjects to disa...
    Role:
      Kind:  ClusterRole
      Name:  system:deployer
    Subjects:
      Kind            Name      Namespace
      ----            ----      ---------
      ServiceAccount  deployer  joe-project
    
    
    Name:         system:image-builders
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows builds in this namespace to push images to this
                    namespace.  It is auto-managed by a controller; remove subjects
                    to disable.
    Role:
      Kind:  ClusterRole
      Name:  system:image-builder
    Subjects:
      Kind            Name     Namespace
      ----            ----     ---------
      ServiceAccount  builder  joe-project
    
    
    Name:         system:image-pullers
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows all pods in this namespace to pull images from this
                    namespace.  It is auto-managed by a controller; remove subjects
                    to disable.
    Role:
      Kind:  ClusterRole
      Name:  system:image-puller
    Subjects:
      Kind   Name                                Namespace
      ----   ----                                ---------
      Group  system:serviceaccounts:joe-project

5.2.6. 向用户添加角色

可以使用 oc adm 管理员 CLI 管理角色和绑定。

将角色绑定或添加到用户或组可让用户或组具有该角色授予的访问权限。您可以使用 oc adm policy 命令向用户和组添加和移除角色。

您可以将任何默认集群角色绑定到项目中的本地用户或组。

流程

  1. 向指定项目中的用户添加角色:

    $ oc adm policy add-role-to-user <role> <user> -n <project>

    例如,您可以运行以下命令,将 admin 角色添加到 joe 项目中的 alice 用户:

    $ oc adm policy add-role-to-user admin alice -n joe
  2. 查看本地角色绑定,并在输出中验证添加情况:

    $ oc describe rolebinding.rbac -n <project>

    例如,查看 joe 项目的本地角色绑定:

    $ oc describe rolebinding.rbac -n joe

    输出示例

    Name:         admin
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  ClusterRole
      Name:  admin
    Subjects:
      Kind  Name        Namespace
      ----  ----        ---------
      User  kube:admin
    
    
    Name:         admin-0
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  ClusterRole
      Name:  admin
    Subjects:
      Kind  Name   Namespace
      ----  ----   ---------
      User  alice 1
    
    
    Name:         system:deployers
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows deploymentconfigs in this namespace to rollout pods in
                    this namespace.  It is auto-managed by a controller; remove
                    subjects to disa...
    Role:
      Kind:  ClusterRole
      Name:  system:deployer
    Subjects:
      Kind            Name      Namespace
      ----            ----      ---------
      ServiceAccount  deployer  joe
    
    
    Name:         system:image-builders
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows builds in this namespace to push images to this
                    namespace.  It is auto-managed by a controller; remove subjects
                    to disable.
    Role:
      Kind:  ClusterRole
      Name:  system:image-builder
    Subjects:
      Kind            Name     Namespace
      ----            ----     ---------
      ServiceAccount  builder  joe
    
    
    Name:         system:image-pullers
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows all pods in this namespace to pull images from this
                    namespace.  It is auto-managed by a controller; remove subjects
                    to disable.
    Role:
      Kind:  ClusterRole
      Name:  system:image-puller
    Subjects:
      Kind   Name                                Namespace
      ----   ----                                ---------
      Group  system:serviceaccounts:joe

    1
    alice 用户已添加到 admins RoleBinding

5.2.7. 创建本地角色

您可以为项目创建本地角色,然后将其绑定到用户。

流程

  1. 要为项目创建本地角色,请运行以下命令:

    $ oc create role <name> --verb=<verb> --resource=<resource> -n <project>

    在此命令中,指定:

    • <name>,本地角色的名称
    • <verb>,以逗号分隔的、应用到角色的操作动词列表
    • <resource>,角色应用到的资源
    • <project>,项目名称

    例如,要创建一个本地角色来允许用户查看 blue 项目中的 Pod,请运行以下命令:

    $ oc create role podview --verb=get --resource=pod -n blue
  2. 要将新角色绑定到用户,运行以下命令:

    $ oc adm policy add-role-to-user podview user2 --role-namespace=blue -n blue

5.2.8. 创建集群角色

您可以创建集群角色。

流程

  1. 要创建集群角色,请运行以下命令:

    $ oc create clusterrole <name> --verb=<verb> --resource=<resource>

    在此命令中,指定:

    • <name>,本地角色的名称
    • <verb>,以逗号分隔的、应用到角色的操作动词列表
    • <resource>,角色应用到的资源

    例如,要创建一个集群角色来允许用户查看 Pod,请运行以下命令:

    $ oc create clusterrole podviewonly --verb=get --resource=pod

5.2.9. 本地角色绑定命令

在使用以下操作为本地角色绑定管理用户或组的关联角色时,可以使用 -n 标志来指定项目。如果未指定,则使用当前项目。

您可以使用以下命令进行本地 RBAC 管理。

表 5.1. 本地角色绑定操作

命令描述

$ oc adm policy who-can <verb> <resource>

指出哪些用户可以对某一资源执行某种操作。

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

将指定角色绑定到当前项目中的指定用户。

$ oc adm policy remove-role-from-user <role> <username>

从当前项目中的指定用户移除指定角色。

$ oc adm policy remove-user <username>

移除当前项目中的指定用户及其所有角色。

$ oc adm policy add-role-to-group <role> <groupname>

将给定角色绑定到当前项目中的指定组。

$ oc adm policy remove-role-from-group <role> <groupname>

从当前项目中的指定组移除给定角色。

$ oc adm policy remove-group <groupname>

移除当前项目中的指定组及其所有角色。

5.2.10. 集群角色绑定命令

您也可以使用以下操作管理集群角色绑定。因为集群角色绑定使用没有命名空间的资源,所以这些操作不使用 -n 标志。

表 5.2. 集群角色绑定操作

命令描述

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

将给定角色绑定到集群中所有项目的指定用户。

$ oc adm policy remove-cluster-role-from-user <role> <username>

从集群中所有项目的指定用户移除给定角色。

$ oc adm policy add-cluster-role-to-group <role> <groupname>

将给定角色绑定到集群中所有项目的指定组。

$ oc adm policy remove-cluster-role-from-group <role> <groupname>

从集群中所有项目的指定组移除给定角色。

5.2.11. 创建集群管理员

需要具备 cluster-admin 角色才能在 OpenShift Container Platform 集群上执行管理员级别的任务,例如修改集群资源。

先决条件

  • 您必须已创建了要定义为集群管理员的用户。

流程

  • 将用户定义为集群管理员:

    $ oc adm policy add-cluster-role-to-user cluster-admin <user>

5.3. kubeadmin 用户

OpenShift Container Platform 在安装过程完成后会创建一个集群管理员 kubeadmin

此用户自动具有 cluster-admin 角色,并视为集群的 root 用户。其密码是动态生成的,对 OpenShift Container Platform 环境中是唯一的。安装完成后,安装程序的输出中会包括这个密码。例如:

INFO Install complete!
INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI.
INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes).
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com
INFO Login to the console with user: kubeadmin, password: <provided>

5.3.1. 移除 kubeadmin 用户

在定义了身份提供程序并创建新的 cluster-admin 用户后,您可以移除 kubeadmin 来提高集群安全性。

警告

如果在另一用户成为 cluster-admin 前按照这个步骤操作,则必须重新安装 OpenShift Container Platform。此命令无法撤销。

先决条件

  • 必须至少配置了一个身份提供程序。
  • 必须向用户添加了 cluster-admin 角色。
  • 必须已经以管理员身份登录。

流程

  • 移除 kubeadmin Secret:

    $ oc delete secrets kubeadmin -n kube-system

5.4. 镜像配置资源

了解并配置镜像 registry 设置。

5.4.1. 镜像控制器配置参数

Image.config.openshift.io/cluster 资源包含有关如何处理镜像的集群范围信息。规范且唯一有效的名称是 cluster。它的 spec 提供以下配置参数。

参数描述

allowedRegistriesForImport

限制普通用户可从中导入镜像的容器镜像 registry。将此列表设置为您信任包含有效镜像且希望应用程序能够从中导入的 registry。有权从 API 创建镜像或 ImageStreamMappings 的用户不受此策略的影响。通常只有集群管理员具有适当权限。

这个列表中的每个项包含由 registry 域名指定的 registry 的位置。

domainname:指定 registry 的域名。如果 registry 使用非标准的 80443 端口,则端口还需要包含在域名中。

insecure:不安全指示 registry 是否安全。默认情况下,如果未另行指定,registry 假定为安全。

additionalTrustedCA

对包含 image stream importpod image pullopenshift-image-registry pullthrough 和构建期间应受信任的额外 CA 的配置映射的引用。

此配置映射的命名空间为 openshift-config。ConfigMap 的格式是使用 registry 主机名作为键,使用 PEM 编码证书作为值,用于每个要信任的额外 registry CA。

externalRegistryHostnames

提供默认外部镜像 registry 的主机名。只有在镜像 registry 对外公开时才应设置外部主机名。第一个值用于镜像流中的 publicDockerImageRepository 字段。该值必须采用 hostname[:port] 格式。

registrySources

包含用于决定容器运行时在访问构建和 pod 的镜像时应如何处理个别 registry 的配置。例如,是否允许不安全的访问。它不包含内部集群 registry 的配置。

insecureRegistries:无有效 TLS 证书或仅支持 HTTP 连接的 registry。

blockedRegistries:列入镜像拉取(pull)和推送(push)操作的拒绝名单。允许所有其他 registry。

allowedRegistries:列入镜像拉取(pull)和推送(push)操作的允许名单。阻止所有其他 registry。

可以设置 blockedRegistriesallowedRegistries ,但不能同时都被设置。

警告

当定义 allowedRegistries 参数时,除非明确列出,否则所有 registry(包括 registry.redhat.ioquay.io registry)都会被阻断,。在使用该参数时,为了避免 pod 失败,您必须将 registry.redhat.ioquay.io 添加到 allowedRegistries 列表中, 因为环境中有效负载镜像需要它们。不要将 registry.redhat.ioquay.io registry 添加到 blockedRegistries 列表中。对于断开连接的集群,还必须添加镜像的 registry。

image.config.openshift.io/cluster 资源的 status 项包括了从集群观察到的值。

参数描述

internalRegistryHostname

由控制 internalRegistryHostname 的 Image Registry Operator 设置。它为默认内部镜像 registry 设置主机名。该值必须采用 hostname[:port] 格式。为实现向后兼容,您仍可使用 OPENSHIFT_DEFAULT_REGISTRY 环境变量,但该设置会覆盖环境变量。

externalRegistryHostnames

由 Image Registry Operator 设置,在镜像 registry 通过外部公开时为它提供外部主机名。第一个值用于镜像流中的 publicDockerImageRepository 字段。该值必须采用 hostname[:port] 格式。

5.4.2. 配置镜像设置

您可以通过编辑 image.config.openshift.io/cluster 自定义资源(CR)来配置镜像 registry 设置。Machine Config Operator(MCO)会监控 image.config.openshift.io/cluster CR 是否有对 registry 的更改,并在检测到更改时重启节点。

流程

  1. 编辑 image.config.openshift.io/cluster 自定义资源:

    $ oc edit image.config.openshift.io/cluster

    以下是 image.config.openshift.io/cluster CR 示例:

    apiVersion: config.openshift.io/v1
    kind: Image 1
    metadata:
      annotations:
        release.openshift.io/create-only: "true"
      creationTimestamp: "2019-05-17T13:44:26Z"
      generation: 1
      name: cluster
      resourceVersion: "8302"
      selfLink: /apis/config.openshift.io/v1/images/cluster
      uid: e34555da-78a9-11e9-b92b-06d6c7da38dc
    spec:
      allowedRegistriesForImport: 2
        - domainName: quay.io
          insecure: false
      additionalTrustedCA: 3
        name: myconfigmap
      registrySources:4
        allowedRegistries:
        - example.com
        - quay.io
        - registry.redhat.io
        insecureRegistries:
        - insecure.com
    status:
      internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1
    Image:包含有关如何处理镜像的集群范围信息。规范且唯一有效的名称是 cluster
    2
    allowedRegistriesForImport:限制普通用户可从中导入镜像的容器镜像 registry。将此列表设置为您信任包含有效镜像且希望应用程序能够从中导入的 registry。有权从 API 创建镜像或 ImageStreamMappings 的用户不受此策略的影响。通常只有集群管理员具有适当权限。
    3
    additionalTrustedCA:引用包含镜像流导入、Pod 镜像拉取、openshift-image-registry pullthrough 和构建期间受信任的额外证书颁发机构(CA)的配置映射。此配置映射的命名空间为 openshift-config。ConfigMap 的格式是使用 registry 主机名作为键,使用 PEM 证书作为值,用于每个要信任的额外 registry CA。
    4
    registrySources:包含用于决定容器运行时在访问构建和 pod 的镜像时应如何处理个别 registry 的配置。例如,是否允许不安全的访问。它不包含内部集群 registry 的配置。本例列出了 allowedRegistries,用于定义允许使用的 registry。列出的 registry 中的一个是不安全的。
  2. 要检查是否应用了更改,请列出您的节点:

    $ oc get nodes

    输出示例

    NAME                                       STATUS                     ROLES    AGE   VERSION
    ci-ln-j5cd0qt-f76d1-vfj5x-master-0         Ready                         master   98m   v1.19.0+7070803
    ci-ln-j5cd0qt-f76d1-vfj5x-master-1         Ready,SchedulingDisabled      master   99m   v1.19.0+7070803
    ci-ln-j5cd0qt-f76d1-vfj5x-master-2         Ready                         master   98m   v1.19.0+7070803
    ci-ln-j5cd0qt-f76d1-vfj5x-worker-b-nsnd4   Ready                         worker   90m   v1.19.0+7070803
    ci-ln-j5cd0qt-f76d1-vfj5x-worker-c-5z2gz   NotReady,SchedulingDisabled   worker   90m   v1.19.0+7070803
    ci-ln-j5cd0qt-f76d1-vfj5x-worker-d-stsjv   Ready                         worker   90m   v1.19.0+7070803

5.4.2.1. 为镜像 registry 访问配置额外的信任存储

Image.config.openshift.io/cluster 自定资源可包含对配置映射的引用,该配置映射包含要在镜像 registry 访问期间被信任的额外证书颁发机构。

先决条件

  • 证书颁发机构(CA)必须经过 PEM 编码。

流程

您可以在openshift-config命名空间中创建配置映射,并在 image.config.openshift.io 子定义资源中的 AdditionalTrustedCA 中使用其名称,以提供与外部 registry 联系时可以被信任的额外CA。

对于每个要信任的额外 registry CA,ConfigMap 键是带有要信任此 CA 的端口的 registry 主机的名称,值是经 base64 编码的证书。

镜像 registry CA 配置映射示例

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  registry.example.com: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: | 1
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

1
如果 registry 带有端口,如 registry-with-port.example.com:5000: 需要被 .. 替换。

您可以按照以下过程配置其他CA。

  1. 配置其他CA:

    $ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
    $ oc edit image.config.openshift.io cluster
    spec:
      additionalTrustedCA:
        name: registry-config

5.4.2.2. 允许不安全的 registry

您可以通过编辑 image.config.openshift.io/cluster 自定义资源(CR)来添加不安全的 registry。OpenShift Container Platform 会将对此 CR 的更改应用到集群中的所有节点。

没有使用有效 SSL 证书或不需要 HTTPS 连接的 registry 被视为是不安全的 registry。

警告

应避免使用不安全的外部 registry,以减少可能的安全性风险。

流程

  1. 编辑 image.config.openshift.io/cluster CR:

    $ oc edit image.config.openshift.io/cluster

    以下是一个带有不安全 registry 列表的 image.config.openshift.io/cluster CR 示例:

    apiVersion: config.openshift.io/v1
    kind: Image
    metadata:
      annotations:
        release.openshift.io/create-only: "true"
      creationTimestamp: "2019-05-17T13:44:26Z"
      generation: 1
      name: cluster
      resourceVersion: "8302"
      selfLink: /apis/config.openshift.io/v1/images/cluster
      uid: e34555da-78a9-11e9-b92b-06d6c7da38dc
    spec:
      registrySources: 1
        insecureRegistries: 2
        - insecure.com
        allowedRegistries:
        - example.com
        - quay.io
        - registry.redhat.io
        - insecure.com 3
    status:
      internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1
    registrySources:包含用于决定容器运行时在访问构建和 pod 的镜像时应如何处理个别 registry 的配置。它不包含内部集群 registry 的配置。
    2
    指定不安全的 registry。
    3
    确保将任何不安全的 registry 包含在 allowedRegistries 列表中。
    注意

    当定义 allowedRegistries 参数时,除非明确列出,否则所有 registry(包括 registry.redhat.io 和 quay.io registry)都会被阻断,。如果使用该参数,为了避免 pod 失败,您必须将 registry.redhat.ioquay.io 添加到 allowedRegistries 列表中, 因为环境中有效负载镜像需要它们。不要将 registry.redhat.ioquay.io registry 添加到 blockedRegistries 列表中。

    Machine Config Operator (MCO) 会监控 image.config.openshift.io/cluster CR 以了解对 registry 的任何更改,并在检测到更改时重启节点。对不安全和受阻 registry 的更改都出现在每个节点的 /etc/containers/registries.conf 文件中。

  2. 要检查 registry 是否已添加到策略文件中,请在节点上使用以下命令:

    $ cat /host/etc/containers/registries.conf

    以下示例表示来自 insecure.com registry 的镜像是不安全的,并允许进行镜像拉取和推送。

    输出示例

    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    
    [[registry]]
      prefix = ""
      location = "insecure.com"
      insecure = true

5.4.2.3. 配置镜像 registry 存储库镜像

通过设置容器 registry 存储库镜像,您可以进行以下操作:

  • 配置 OpenShift Container Platform 集群,以便重定向从源镜像 registry 上的存储库拉取(pull)镜像的请求,并通过已镜像 (mirror) 的镜像 registry 上的存储库来解决该请求。
  • 为每个目标存储库识别多个已镜像 (mirror)的存储库,以确保如果一个镜像停止运作,仍可使用其他镜像。

OpenShift Container Platform 中存储库镜像的属性包括:

  • 镜像拉取(pull)可应对 registry 停机的问题
  • 受限网络中的集群可以从关键位置(如 quay.io)拉取镜像,并让位于公司防火墙后的 registry 提供请求的镜像。
  • 发出镜像拉取(pull)请求时尝试特定 registry 顺序,通常最后才会尝试持久性 registry。
  • 您所输入的镜像信息会添加到 OpenShift Container Platform 集群中每个节点上的 /etc/containers/registries.conf 文件中。
  • 当节点从源存储库中请求镜像时,它会依次尝试每个已镜像的存储库,直到找到所请求的内容。如果所有镜像均失败,集群则会尝试源存储库。如果成功,则镜像拉取至节点中。

可通过以下方式设置存储库镜像:

  • 在 OpenShift Container Platform 安装中:

    通过拉取(pull) OpenShift Container Platform 所需的容器镜像,然后将这些镜像放至公司防火墙后,即可将 OpenShift Container Platform 安装到受限网络中的数据中心。

  • 安装 OpenShift Container Platform 后:

    即使没有在 OpenShift Container Platform 安装期间配置镜像 (mirror),之后您仍可使用 ImageContentSourcePolicy 对象进行配置。

以下流程提供安装后镜像配置,您可在此处创建 ImageContentSourcePolicy 对象来识别:

  • 您希望镜像 (mirror) 的容器镜像存储库的源
  • 您希望为其提供从源存储库请求的内容的每个镜像存储库的单独条目。
注意

您只能为具有 ImageContentSourcePolicy 对象的集群配置全局 pull secret。您不能在项目中添加 pull secret。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 通过以下方法配置已镜像的存储库:

    • 按照 Red Hat Quay 存储库镜像中所述,使用 Red Hat Quay 来设置已镜像的存储库。使用 Red Hat Quay 有助于您将镜像从一个存储库复制到另一存储库,并可随着时间的推移重复自动同步这些存储库。
    • 使用 skopeo 等工具手动将镜像从源目录复制到已镜像的存储库。

      例如:在 Red Hat Enterprise Linux(RHEL 7 或 RHEL 8)系统上安装 skopeo RPM 软件包后,使用 skopeo 命令,如下例所示:

      $ skopeo copy \
      docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
      docker://example.io/example/ubi-minimal

      在本例中,您有一个名为 example.io 的容器镜像 registry,其中包含一个名为 example 的镜像存储库,您希望将 ubi8/ubi-minimal 镜像从 registry.access.redhat.com 复制到此镜像存储库。创建该 registry 后,您可将 OpenShift Container Platform 集群配置为将源存储库的请求重定向到已镜像的存储库。

  2. 登录您的 OpenShift Container Platform 集群。
  3. 创建 ImageContentSourcePolicy 文件(如:registryrepomirror.yaml),将源和镜像 (mirror) 替换为您自己的 registry、存储库对和镜像中的源和镜像:

    apiVersion: operator.openshift.io/v1alpha1
    kind: ImageContentSourcePolicy
    metadata:
      name: ubi8repo
    spec:
      repositoryDigestMirrors:
      - mirrors:
        - example.io/example/ubi-minimal 1
        source: registry.access.redhat.com/ubi8/ubi-minimal 2
      - mirrors:
        - example.com/example/ubi-minimal
        source: registry.access.redhat.com/ubi8/ubi-minimal
    1
    指明镜像 registry 和存储库的名称。
    2
    指明包含所镜像内容的 registry 和存储库。
  4. 创建新的 ImageContentSourcePolicy 对象:

    $ oc create -f registryrepomirror.yaml

    创建 ImageContentSourcePolicy 对象后,新的设置将部署到每个节点,集群开始使用已镜像的存储库来响应源存储库请求。

  5. 要检查是否应用了已镜像的配置设置,在其中一个节点上执行以下内容。

    1. 列出您的节点:

      $ oc get node

      输出示例

      NAME                           STATUS                     ROLES    AGE  VERSION
      ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.18.3
      ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.18.3
      ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.18.3
      ip-10-0-147-35.ec2.internal    Ready,SchedulingDisabled   worker   7m   v1.18.3
      ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.18.3
      ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.18.3

      您可以发现,在应用更改时每个 worker 节点上的调度都会被禁用。

    2. 启动调试过程以访问节点:

      $ oc debug node/ip-10-0-147-35.ec2.internal

      输出示例

      Starting pod/ip-10-0-147-35ec2internal-debug ...
      To use host binaries, run `chroot /host`

    3. 访问节点的文件:

      sh-4.2# chroot /host
    4. 检查 /etc/containers/registries.conf 文件,确保已完成更改:

      sh-4.2# cat /etc/containers/registries.conf

      输出示例

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
      [[registry]]
        location = "registry.access.redhat.com/ubi8/"
        insecure = false
        blocked = false
        mirror-by-digest-only = true
        prefix = ""
      
        [[registry.mirror]]
          location = "example.io/example/ubi8-minimal"
          insecure = false
      
        [[registry.mirror]]
          location = "example.com/example/ubi8-minimal"
          insecure = false

    5. 将镜像摘要从源拉取到节点,并检查是否通过镜像解析。ImageContentSourcePolicy 对象仅支持镜像摘要,不支持镜像标签。

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

存储库镜像故障排除

如果存储库镜像流程未按规定工作,请使用以下有关存储库镜像如何工作的信息协助排查问题。

  • 首个工作镜像用于提供拉取(pull)的镜像。
  • 只有在无其他镜像工作时,才会使用主 registry。
  • 从系统上下文,Insecure 标志用作回退。
  • 最近更改了 /etc/containers/registries.conf 文件的格式。现在它是第 2 版,采用 TOML 格式。

5.5. 使用 OperatorHub 安装 operator

OperatorHub 是一个发现 Operator 的用户界面,它与 Operator Lifecycle Manager(OLM)一起工作,后者在集群中安装和管理 Operator。

作为集群管理员,您可以使用 OpenShift Container Platform Web 控制台或 CLI 安装来自 OperatorHub 的 Operator。将 Operator 订阅到一个或多个命名空间,供集群上的开发人员使用。

安装过程中,您必须为 Operator 确定以下初始设置:

安装模式
选择 All namespaces on the cluster (default) 将 Operator 安装至所有命名空间;或选择单个命名空间(如果可用),仅在选定命名空间中安装 Operator。本例选择 All namespaces…​ 使 Operator 可供所有用户和项目使用。
更新频道
如果某个 Operator 可通过多个频道获得,则可任选您想要订阅的频道。例如,要通过 stable 频道部署(如果可用),则从列表中选择这个选项。
批准策略

您可以选择自动或者手动更新。

如果选择自动更新某个已安装的 Operator,则当所选频道中有该 Operator 的新版本时,Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例,而无需人为干预。

如果选择手动更新,则当有新版 Operator 可用时,OLM 会创建更新请求。作为集群管理员,您必须手动批准该更新请求,才可将 Operator 更新至新版本。

5.5.1. 使用 Web 控制台从 OperatorHub 安装

您可以使用 OpenShift Container Platform Web 控制台从 OperatorHub 安装并订阅 Operator。

先决条件

  • 使用具有 cluster-admin 权限的账户访问 OpenShift Container Platform 集群。

流程

  1. 在 Web 控制台中导航至 Operators → OperatorHub 页面。
  2. 找到您需要的 Operator(滚动页面会在 Filter by keyword 框中输入查找关键字)。例如,键入 jaeger 来查找 Jaeger Operator。

    您还可以根据基础架构功能过滤选项。例如,如果您希望 Operator 在断开连接的环境中工作,请选择 Disconnected

  3. 选择要显示更多信息的 Operator。

    注意

    选择 Community Operator 会警告红帽没有认证社区 Operator ; 您必须确认该警告方可继续。

  4. 阅读 Operator 信息并单击 Install
  5. Install Operator 页面中:

    1. 任选以下一项:

      • All namespaces on the cluster (default),选择该项会将 Operator 安装至默认 openshift-operators 命名空间,以便供集群中的所有命名空间监视和使用。该选项并非始终可用。
      • A specific namespace on the cluster,该项支持您选择单一特定命名空间来安装 Operator。该 Operator 仅限在该单一命名空间中监视和使用。
    2. 选择一个更新频道(如有多个可用)。
    3. 如前面所述,选择自动手动批准策略。
  6. 点击 Install 使 Operator 可供 OpenShift Container Platform 集群上的所选命名空间使用。

    1. 如果选择了手动批准策略,订阅的升级状态将保持在 Upgrading 状态,直至您审核并批准安装计划。

      Install Plan 页面批准后,订阅的升级状态将变为 Up to date

    2. 如果选择了 Automatic 批准策略,升级状态会在不用人工参与的情况下变为 Up to date
  7. 在订阅的升级状态成为 Up to date 后,选择 Operators → Installed Operators 来验证已安装 Operator 的 ClusterServiceVersion(CSV)是否最终出现了。状态最终会在相关命名空间中变为 InstallSucceeded

    注意

    对于 All namespaces…​ 安装模式,状态在 openshift-operators 命名空间中解析为 InstallSucceeded,但如果检查其他命名空间,则状态为 Copied

    如果没有:

    1. 检查 openshift-operators 项目(如果选择了 A specific namespace…​ 安装模式)中的 openshift-operators 项目中的 pod 的日志,这会在 Workloads → Pods 页面中报告问题以便进一步排除故障。

5.5.2. 使用 CLI 从 OperatorHub 安装

您可以使用 CLI 从 OperatorHub 安装 Operator,而不必使用 OpenShift Container Platform Web 控制台。使用 oc 命令来创建或更新一个订阅对象。

先决条件

  • 使用具有 cluster-admin 权限的账户访问 OpenShift Container Platform 集群。
  • 在您的本地系统安装 oc 命令。

流程

  1. 查看 OperatorHub 中集群可用的 Operator 列表:

    $ oc get packagemanifests -n openshift-marketplace

    输出示例

    NAME                               CATALOG               AGE
    3scale-operator                    Red Hat Operators     91m
    advanced-cluster-management        Red Hat Operators     91m
    amq7-cert-manager                  Red Hat Operators     91m
    ...
    couchbase-enterprise-certified     Certified Operators   91m
    crunchy-postgres-operator          Certified Operators   91m
    mongodb-enterprise                 Certified Operators   91m
    ...
    etcd                               Community Operators   91m
    jaeger                             Community Operators   91m
    kubefed                            Community Operators   91m
    ...

    记录下所需 Operator 的目录。

  2. 检查所需 Operator,以验证其支持的安装模式和可用频道:

    $ oc describe packagemanifests <operator_name> -n openshift-marketplace
  3. 一个 Operator 组(由 OperatorGroup 对象定义),在其中选择目标命名空间,在其中为与 Operator 组相同的命名空间中的所有 Operator 生成所需的 RBAC 访问权限。

    订阅 Operator 的命名空间必须具有与 Operator 的安装模式相匹配的 Operator 组,可采用 AllNamespaces 模式,也可采用 SingleNamespace 模式。如果您要使用 AllNamespaces 安装 Operator,则 openshift-operators 命名空间已有适当的 Operator 组。

    如果要安装的 Operator 采用 SingleNamespace 模式,而您没有适当的 Operator 组,则必须创建一个。

    注意

    在选择 SingleNamespace 模式时,该流程的 Web 控制台版本会在后台自动为您处理 OperatorGroupSubscription 对象的创建。

    1. 创建 OperatorGroup 对象 YAML 文件,如 operatorgroup.yaml

      OperatorGroup 对象示例

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

    2. 创建 OperatorGroup 对象:

      $ oc apply -f operatorgroup.yaml
  4. 创建一个 Subscription 对象 YAML 文件,以便为 Operator 订阅一个命名空间,如 sub.yaml

    Subscription 对象示例

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: <subscription_name>
      namespace: openshift-operators 1
    spec:
      channel: <channel_name> 2
      name: <operator_name> 3
      source: redhat-operators 4
      sourceNamespace: openshift-marketplace 5

    1
    对于 AllNamespaces 安装模式的使用,指定 openshift-operators 命名空间。否则,为 SingleNamespace 安装模式使用指定相关单一命名空间。
    2
    要订阅的频道的名称。
    3
    要订阅的 Operator 的名称。
    4
    提供 Operator 的目录源的名称。
    5
    目录源的命名空间。将 openshift-marketplace 用于默认的 OperatorHub 目录源。
  5. 创建 Subscription 对象:

    $ oc apply -f sub.yaml

    此时,OLM 已了解所选的 Operator。Operator 的集群服务版本(CSV)应出现在目标命名空间中,由 Operator 提供的 API 应可用于创建。

其他资源

法律通告

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