Networking Operators


OpenShift Container Platform 4.17

在 OpenShift Container Platform 中管理网络特定的 Operator

Red Hat OpenShift Documentation Team

摘要

本文档涵盖了 OpenShift Container Platform 中各种与网络相关的 Operator 的安装、配置和管理。

第 1 章 Kubernetes NMState Operator

Kubernetes NMState Operator 提供了一个 Kubernetes API,用于使用 NMState 在 OpenShift Container Platform 集群的节点上执行状态驱动的网络配置。Kubernetes NMState Operator 为用户提供了在集群节点上配置各种网络接口类型、DNS 和路由的功能。另外,集群节点中的守护进程会定期向 API 服务器报告每个节点的网络接口状态。

重要

红帽在裸机、IBM Power®、IBM Z®、IBM® LinuxONE、VMware vSphere 和 Red Hat OpenStack Platform (RHOSP) 安装上的生产环境中支持 Kubernetes NMState Operator。

红帽支持在 Microsoft Azure 上使用 Kubernetes NMState Operator,但有使用限制。支持仅限于将系统中的 DNS 服务器配置为安装后任务。

在 OpenShift Container Platform 中使用 NMState 之前,必须安装 Kubernetes NMState Operator。安装 Kubernetes NMState Operator 后,您可以完成以下任务:

  • 观察和更新节点网络状态和配置
  • 有关创建包含自定义 br-ex 网桥的清单对象,以了解有关这些任务的更多信息,请参阅附加资源部分

在 OpenShift Container Platform 中使用 NMState 之前,必须安装 Kubernetes NMState Operator。

注意

Kubernetes NMState Operator 更新二级 NIC 的网络配置。Operator 无法更新主 NIC 的网络配置,或更新大多数内部网络中的 br-ex 网桥。

在裸机平台上,只有在将 br-ex 网桥设置为机器配置时,才支持使用 Kubernetes NMState Operator 更新 br-ex 网桥网络配置。要将 br-ex 网桥更新为安装后任务,您必须将 br-ex 网桥设置为集群的 NodeNetworkConfigurationPolicy 自定义资源 (CR) 的 NMState 配置中的接口。如需更多信息,请参阅安装后配置中的创建包含自定义 br-ex 网桥的清单对象

OpenShift Container Platform 使用 nmstate 来报告并配置节点网络的状态。这样便可通过将单个配置清单应用到集群来修改网络策略配置,例如在所有节点上创建 Linux 网桥。

节点网络由以下对象监控和更新:

NodeNetworkState
报告该节点上的网络状态。
NodeNetworkConfigurationPolicy
描述节点上请求的网络配置。您可以通过将 NodeNetworkConfigurationPolicy CR 应用到集群来更新节点网络配置,包括添加和删除网络接口 。
NodeNetworkConfigurationEnactment
报告每个节点上采用的网络策略。

1.1. 安装 Kubernetes NMState Operator

您可以使用 web 控制台或 CLI 安装 Kubernetes NMState Operator。

您可以使用 web 控制台安装 Kubernetes NMState Operator。安装 Kubernetes NMState Operator 后,Operator 将 NMState State Controller 部署为在所有集群节点中的守护进程集。

先决条件

  • 您以具有 cluster-admin 权限的用户身份登录。

流程

  1. 选择 OperatorsOperatorHub
  2. All Items 下面的搜索字段中, 输入 nmstate 并点 Enter 来搜索 Kubernetes NMState Operator。
  3. 点 Kubernetes NMState Operator 搜索结果。
  4. Install 打开 Install Operator 窗口。
  5. Install 安装 Operator。
  6. Operator 安装完成后,点 View Operator
  7. Provided APIs 下,点 Create Instance 打开对话框以创建 kubernetes-nmstate 实例。
  8. 在对话框的 Name 字段中,确保实例的名称是 nmstate.

    注意

    名称限制是一个已知问题。该实例是整个集群的单个实例。

  9. 接受默认设置并点 Create 创建实例。

1.1.2. 使用 CLI 安装 Kubernetes NMState Operator

您可以使用 OpenShift CLI(oc) 安装 Kubernetes NMState Operator。安装后,Operator 可将 NMState State Controller 部署为在所有集群节点中的守护进程集。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您以具有 cluster-admin 权限的用户身份登录。

流程

  1. 创建 nmstate Operator 命名空间:

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-nmstate
    spec:
      finalizers:
      - kubernetes
    EOF
    Copy to Clipboard Toggle word wrap
  2. 创建 OperatorGroup

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-nmstate
      namespace: openshift-nmstate
    spec:
      targetNamespaces:
      - openshift-nmstate
    EOF
    Copy to Clipboard Toggle word wrap
  3. 订阅 nmstate Operator:

    $ cat << EOF| oc apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: kubernetes-nmstate-operator
      namespace: openshift-nmstate
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: kubernetes-nmstate-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    EOF
    Copy to Clipboard Toggle word wrap
  4. 确认 nmstate Operator 部署的 ClusterServiceVersion (CSV) 状态等于 Succeeded

    $ oc get clusterserviceversion -n openshift-nmstate \
     -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap
  5. 创建 nmstate Operator 实例:

    $ cat << EOF | oc apply -f -
    apiVersion: nmstate.io/v1
    kind: NMState
    metadata:
      name: nmstate
    EOF
    Copy to Clipboard Toggle word wrap
  6. 如果您的集群因为 DNS 连接问题导致 DNS 健康检查探测出现问题,您可以在 NMState CRD 中添加以下 DNS 主机名配置,以便在可以解决这些问题的健康检查中构建:

    apiVersion: nmstate.io/v1
    kind: NMState
    metadata:
      name: nmstate
    spec:
      probeConfiguration:
        dns:
          host: redhat.com
    # ...
    Copy to Clipboard Toggle word wrap
    1. 运行以下命令,将 DNS 主机名配置应用到集群网络。确保将 <filename> 替换为 CRD 文件的名称。

      $ oc apply -f <filename>.yaml
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令,监控 nmstate CRD,直到资源达到 Available 条件。确保为 the- timeout 选项设置了一个值,以便在此设置的最大等待时间中没有满足 Available 条件时,命令会超时并生成错误消息。

      $ oc wait --for=condition=Available nmstate/nmstate --timeout=600s
      Copy to Clipboard Toggle word wrap

验证

  1. 输入以下命令验证 NMState Operator 的所有 pod 是否具有 Running 状态:

    $ oc get pod -n openshift-nmstate
    Copy to Clipboard Toggle word wrap

1.1.3. 查看 Kubernetes NMState Operator 收集的指标

Kubernetes NMState Operator kubernetes-nmstate-operator 可以从 kubernetes_nmstate_features_applied 组件收集指标,并将其公开为可随时使用的指标。作为查看指标的用例,请考虑创建 NodeNetworkConfigurationPolicy 自定义资源且您要确认策略处于活跃状态的情况。

注意

kubernetes_nmstate_features_applied 指标不是一个 API,可能会在 OpenShift Container Platform 版本之间有所变化。

DeveloperAdministrator 视角中, Metrics UI 包括所选项目的一些预定义 CPU、内存、带宽和网络数据包查询。您可以对项目的 CPU、内存、带宽、网络数据包和应用程序指标运行自定义 Prometheus Query Language (PromQL) 查询。

以下示例演示了一个 NodeNetworkConfigurationPolicy 清单示例,它应用到 OpenShift Container Platform 集群:

# ...
interfaces:
  - name: br1
    type: linux-bridge
    state: up
    ipv4:
      enabled: true
      dhcp: true
      dhcp-custom-hostname: foo
    bridge:
      options:
        stp:
          enabled: false
      port: []
# ...
Copy to Clipboard Toggle word wrap

NodeNetworkConfigurationPolicy 清单会公开指标,并使其可用于 Cluster Monitoring Operator (CMO)。以下示例显示了一些公开的指标:

controller_runtime_reconcile_time_seconds_bucket{controller="nodenetworkconfigurationenactment",le="0.005"} 16
controller_runtime_reconcile_time_seconds_bucket{controller="nodenetworkconfigurationenactment",le="0.01"} 16
controller_runtime_reconcile_time_seconds_bucket{controller="nodenetworkconfigurationenactment",le="0.025"} 16
...
# HELP kubernetes_nmstate_features_applied Number of nmstate features applied labeled by its name
# TYPE kubernetes_nmstate_features_applied gauge
kubernetes_nmstate_features_applied{name="dhcpv4-custom-hostname"} 1
Copy to Clipboard Toggle word wrap

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以管理员身份登录到 web 控制台并安装 Kubernetes NMState Operator。
  • 对于您要查看指标的项目,您可以作为开发者或具有查看权限的用户访问集群。
  • 您已为用户定义的项目启用了监控。
  • 您已在用户定义的项目中部署了服务。
  • 您已创建了 NodeNetworkConfigurationPolicy 清单,并将其应用到集群。

流程

  1. 如果要从 OpenShift Container Platform Web 控制台中的 Developer 视角查看指标,请完成以下任务:

    1. Observe
    2. 要查看特定项目的指标,请在 Project: 列表中选择该项目。例如,openshift-nmstate
    3. Metrics 选项卡。
    4. 要在图表中视觉化指标,请从 Select query 列表中选择查询,或者通过选择 Show PromQL 根据所选查询创建自定义 PromQL 查询。

      注意

      Developer 视角中,您一次只能运行一个查询。

  2. 如果要从 OpenShift Container Platform Web 控制台中的 Administrator 视角查看指标,请完成以下任务:

    1. ObserveMetrics
    2. Expression 字段中输入 kubernetes_nmstate_features_applied
    3. Add query,然后点 Run query
  3. 要探索视觉化的指标,请执行以下操作之一:

    1. 要放大图表并更改时间范围,请执行以下任何任务:

      • 要可视化选择时间范围,请单击并拖动图表。
      • 要选择时间范围,请使用控制台左上角的菜单。
    2. 要重置时间范围,请选择 Reset Zoom
    3. 要显示所有查询在特定时间点的输出,请将鼠标光标停留在图表中的对应点上。查询输出显示在弹出窗口中。

1.2. 卸载 Kubernetes NMState Operator

您可以使用 Operator Lifecycle Manager (OLM)卸载 Kubernetes NMState Operator,但设计 OLM 不会删除任何关联的自定义资源定义(CRD)、自定义资源(CR)或 API Services。

在从 OLM 使用的 Subcription 资源卸载 Kubernetes NMState Operator 前,请确定要删除的 Kubernetes NMState Operator 资源。此标识可确保您可以在不影响正在运行的集群的情况下删除资源。

如果您需要重新安装 Kubernetes NMState Operator,请参阅"使用 CLI 安装 Kubernetes NMState Operator"或"使用 web 控制台安装 Kubernetes NMState Operator"。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已安装 jq CLI 工具。
  • 您以具有 cluster-admin 权限的用户身份登录。

流程

  1. 运行以下命令,从 Subcription 资源取消订阅 Kubernetes NMState Operator:

    $ oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operator
    Copy to Clipboard Toggle word wrap
  2. 查找与 Kubernetes NMState Operator 关联的 ClusterServiceVersion (CSV) 资源:

    $ oc get --namespace openshift-nmstate clusterserviceversion
    Copy to Clipboard Toggle word wrap

    列出 CSV 资源的输出示例

    NAME                              	  DISPLAY                   	VERSION   REPLACES     PHASE
    kubernetes-nmstate-operator.v4.18.0   Kubernetes NMState Operator   4.18.0           	   Succeeded
    Copy to Clipboard Toggle word wrap

  3. 删除 CSV 资源。删除文件后,OLM 会删除其为 Operator 创建的某些资源,如 RBAC

    $ oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.18.0
    Copy to Clipboard Toggle word wrap
  4. 运行以下命令来删除 nmstate CR 和任何关联的 Deployment 资源:

    $ oc -n openshift-nmstate delete nmstate nmstate
    Copy to Clipboard Toggle word wrap
    $ oc delete --all deployments --namespace=openshift-nmstate
    Copy to Clipboard Toggle word wrap
  5. 删除 nmstate CR 后,从 console.operator.openshift.io/cluster CR 中删除 nmstate-console-plugin 控制台插件名称。

    1. 运行以下命令,存储在启用插件列表中存在 nmstate-console-plugin 条目的位置。以下命令使用 jq CLI 工具将条目的索引存储在名为 INDEX 的环境变量中:

      INDEX=$(oc get console.operator.openshift.io cluster -o json | jq -r '.spec.plugins | to_entries[] | select(.value == "nmstate-console-plugin") | .key')
      Copy to Clipboard Toggle word wrap
    2. 运行以下 patch 命令,从 console.operator.openshift.io/cluster CR 中删除 nmstate-console-plugin 条目:

      $ oc patch console.operator.openshift.io cluster --type=json -p "[{\"op\": \"remove\", \"path\": \"/spec/plugins/$INDEX\"}]" 
      1
      Copy to Clipboard Toggle word wrap
      1
      INDEX 是辅助变量。您可以为此变量指定不同的名称。
  6. 运行以下命令删除所有自定义资源定义 (CRD),如 nmstates.nmstate.io

    $ oc delete crd nmstates.nmstate.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd nodenetworkconfigurationenactments.nmstate.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd nodenetworkstates.nmstate.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd nodenetworkconfigurationpolicies.nmstate.io
    Copy to Clipboard Toggle word wrap
  7. 删除命名空间:

    $ oc delete namespace kubernetes-nmstate
    Copy to Clipboard Toggle word wrap

1.4. 后续步骤

第 2 章 AWS Load Balancer Operator

2.1. AWS Load Balancer Operator 发行注记

AWS Load Balancer (ALB) Operator 部署和管理 AWSLoadBalancerController 资源的实例。

重要

AWS Load Balancer (ALB) Operator 仅在 x86_64 构架中被支持。

本发行注记介绍了 OpenShift Container Platform 中的 AWS Load Balancer Operator 的开发。

如需 AWS Load Balancer Operator 的概述,请参阅 OpenShift Container Platform 中的 AWS Load Balancer Operator

注意

AWS Load Balancer Operator 目前不支持 AWS GovCloud。

2.1.1. AWS Load Balancer Operator 1.2.0

以下公告可用于 AWS Load Balancer Operator 版本 1.2.0 :

2.1.1.1. 主要变化
  • 此发行版本支持 AWS Load Balancer Controller 版本 2.8.2。
  • 在这个版本中,Infrastructure 资源中定义的平台标签将添加到控制器创建的所有 AWS 对象中。

2.1.2. AWS Load Balancer Operator 1.1.1

以下公告可用于 AWS Load Balancer Operator 版本 1.1.1:

2.1.3. AWS Load Balancer Operator 1.1.0

AWS Load Balancer Operator 版本 1.1.0 支持 AWS Load Balancer Controller 版本 2.4.4。

以下公告可用于 AWS Load Balancer Operator 版本 1.1.0:

2.1.3.1. 主要变化
  • 此发行版本使用 Kubernetes API 版本 0.27.2。
2.1.3.2. 新功能
  • AWS Load Balancer Operator 现在支持使用 Cloud Credential Operator 的标准化安全令牌服务 (STS) 流。
2.1.3.3. 程序错误修复
  • FIPS 兼容集群必须使用 TLS 版本 1.2。在以前的版本中,AWS Load Balancer Controller 的 Webhook 只接受 TLS 1.3 作为最小版本,从而导致在与 FIPS 兼容的集群中出现以下错误:

    remote error: tls: protocol version not supported
    Copy to Clipboard Toggle word wrap

    现在,AWS Load Balancer Controller 接受 TLS 1.2 作为最小 TLS 版本,从而解决了这个问题。(OCPBUGS-14846)

2.1.4. AWS Load Balancer Operator 1.0.1

以下公告可用于 AWS Load Balancer Operator 版本 1.0.1:

2.1.5. AWS Load Balancer Operator 1.0.0

现在,AWS Load Balancer Operator 已正式发布。AWS Load Balancer Operator 版本 1.0.0 支持 AWS Load Balancer Controller 版本 2.4.4。

以下公告可用于 AWS Load Balancer Operator 版本 1.0.0:

重要

AWS Load Balancer (ALB) Operator 版本 1.x.x 无法从技术预览版本 0.x.x 自动升级。要从早期版本升级,您必须卸载 ALB 操作对象并删除 aws-load-balancer-operator 命名空间。

2.1.5.1. 主要变化
  • 此发行版本使用新的 v1 API 版本。
2.1.5.2. 程序错误修复
  • 在以前的版本中,AWS Load Balancer Operator 置备的控制器无法正确将配置用于集群范围代理。这些设置现在对控制器正确应用。(OCPBUGS-4052, OCPBUGS-5295)

2.1.6. 早期版本

AWS Load Balancer Operator 的两个最早版本作为技术预览提供。这些版本不应在生产环境中使用。有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

以下公告可用于 AWS Load Balancer Operator 版本 0.2.0 :

以下公告可用于 AWS Load Balancer Operator 版本 0.0.1:

AWS Load Balancer Operator 部署和管理 AWS Load Balancer Controller。您可以使用 OpenShift Container Platform Web 控制台或 CLI 安装来自 OperatorHub 的 AWS Load Balancer Operator。

2.2.1. AWS Load Balancer Operator 的注意事项

在安装和使用 AWS Load Balancer Operator 前查看以下限制:

  • IP 流量模式仅适用于 AWS Elastic Kubernetes Service (EKS)。AWS Load Balancer Operator 禁用 AWS Load Balancer Controller 的 IP 流量模式。禁用 IP 流量模式后,AWS Load Balancer Controller 无法使用 pod 就绪度。
  • AWS Load Balancer Operator 将命令行标记(如 --disable-ingress-class-annotation--disable-ingress-group-name-annotation )添加到 AWS Load Balancer Controller。因此,AWS Load Balancer Operator 不允许在 Ingress 资源中使用 kubernetes.io/ingress.classalb.ingress.kubernetes.io/group.name 注解。
  • 您已配置了 AWS Load Balancer Operator,使 SVC 类型是 NodePort (而不是 LoadBalancerClusterIP)。

2.2.2. AWS Load Balancer Operator

如果缺少 kubernetes.io/role/elb 标签,AWS Load Balancer Operator 可以标记公共子网。另外,AWS Load Balancer Operator 从底层 AWS 云检测到以下信息:

  • 托管 Operator 的集群的虚拟私有云 (VPC) 的 ID。
  • 发现 VPC 的公共和私有子网。

AWS Load Balancer Operator 支持类型为 LoadBalancer 的 Kubernetes 服务资源,使用只有 instance 目标类型的 Network Load Balancer (NLB)。

流程

  1. 要从 OperatorHub 部署 AWS Load Balancer Operator on-demand,请运行以下命令创建一个 Subscription 对象:

    $ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令,检查安装计划的状态是否为 Complete

    $ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令,查看 aws-load-balancer-operator-controller-manager 部署的状态:

    $ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
    aws-load-balancer-operator-controller-manager  1/1       1            1           23h
    Copy to Clipboard Toggle word wrap

您可以配置 AWS Load Balancer Operator,以便在 AWS VPC 集群中置备 AWS Application Load Balancer。AWS Outposts 不支持 AWS Network Load Balancers。因此,AWS Load Balancer Operator 无法在 Outpost 中置备 Network Load Balancers。

您可以在云子网或 Outpost 子网中创建 AWS Application Load Balancer。云中的 Application Load Balancer 可以附加到基于云的计算节点,而 Outpost 中的 Application Load Balancer 可以附加到边缘计算节点。您必须使用 Outpost 子网或 VPC 子网来注解 Ingress 资源,但不能同时注解两者。

先决条件

  • 您已将 AWS VPC 集群扩展到 Outpost。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 AWS Load Balancer Operator 并创建了 AWS Load Balancer Controller。

流程

  • Ingress 资源配置为使用指定的子网:

    Ingress 资源配置示例

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: <application_name>
      annotations:
        alb.ingress.kubernetes.io/subnets: <subnet_id> 
    1
    
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: <application_name>
                    port:
                      number: 80
    Copy to Clipboard Toggle word wrap

    1
    指定要使用的子网。
    • 要在 Outpost 中使用 Application Load Balancer,请指定 Outpost 子网 ID。
    • 要在云中使用 Application Load Balancer,您必须在不同的可用区中指定至少两个子网。

2.3. 为 AWS Load Balancer Operator 准备 AWS STS 集群

您可以在使用安全令牌服务 (STS) 的集群中安装 Amazon Web Services (AWS) Load Balancer Operator。在安装 Operator 前,按照以下步骤准备集群。

AWS Load Balancer Operator 依赖于 CredentialsRequest 对象来引导 Operator 和 AWS Load Balancer Controller。AWS Load Balancer Operator 等待所需的 secret 创建并可用。

2.3.1. 先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您知道集群的基础架构 ID。要显示此 ID,请在 CLI 中运行以下命令:

    $ oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"
    Copy to Clipboard Toggle word wrap
  • 您知道集群的 OpenID Connect (OIDC) DNS 信息。要显示此信息,请在 CLI 中输入以下命令:

    $ oc get authentication.config cluster -o=jsonpath="{.spec.serviceAccountIssuer}" 
    1
    Copy to Clipboard Toggle word wrap
    1
    https://rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f 是 OIDC DNS 的一个示例。
  • 已登陆到 AWS Web 控制台,进入到 IAMAccess managementIdentity provider,以及 OIDC Amazon Resource Name (ARN) 信息。一个 OIDC ARN 示例为 arn:aws:iam::777777777777:oidc-provider/<oidc_dns_url>

2.3.2. 为 AWS Load Balancer Operator 创建 IAM 角色

需要额外的 Amazon Web Services (AWS) Identity 和 Access Management (IAM) 角色,才能在使用 STS 的集群中安装 AWS Load Balancer Operator。需要 IAM 角色与子网和虚拟私有云(VPC)交互。AWS Load Balancer Operator 使用 IAM 角色生成 CredentialsRequest 对象来引导其自身。

您可以使用以下选项创建 IAM 角色:

如果您的环境不支持 ccoctl 命令,请使用 AWS CLI。

您可以使用 Cloud Credential Operator 实用程序(ccoctl) 为 AWS Load Balancer Operator 创建 AWS IAM 角色。AWS IAM 角色与子网和虚拟私有云 (VPC) 交互。

先决条件

  • 您必须提取并准备 ccoctl 二进制文件。

流程

  1. 运行以下命令,下载 CredentialsRequest 自定义资源 (CR) 并将其存储在目录中:

    $ curl --create-dirs -o <credentials_requests_dir>/operator.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yaml
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令,使用 ccoctl 实用程序创建 AWS IAM 角色:

    $ ccoctl aws create-iam-roles \
        --name <name> \
        --region=<aws_region> \
        --credentials-requests-dir=<credentials_requests_dir> \
        --identity-provider-arn <oidc_arn>
    Copy to Clipboard Toggle word wrap

    输出示例

    2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-operator created 
    1
    
    2023/09/12 11:38:57 Saved credentials configuration to: /home/user/<credentials_requests_dir>/manifests/aws-load-balancer-operator-aws-load-balancer-operator-credentials.yaml
    2023/09/12 11:38:58 Updated Role policy for Role <name>-aws-load-balancer-operator-aws-load-balancer-operator created
    Copy to Clipboard Toggle word wrap

    1
    请注意为 AWS Load Balancer Operator 创建的 AWS IAM 角色的 Amazon Resource Name (ARN),如 arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-operator
    注意

    AWS IAM 角色名称的长度必须小于或等于 12 个字符。

2.3.2.2. 使用 AWS CLI 创建 AWS IAM 角色

您可以使用 AWS 命令行界面为 AWS Load Balancer Operator 创建 IAM 角色。IAM 角色用于与子网和虚拟私有云 (VPC) 交互。

先决条件

  • 您必须有权访问 AWS 命令行界面 (aws)。

流程

  1. 运行以下命令,使用身份提供程序生成信任策略文件:

    $ cat <<EOF > albo-operator-trust-policy.json
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Federated": "<oidc_arn>" 
    1
    
                },
                "Action": "sts:AssumeRoleWithWebIdentity",
                "Condition": {
                    "StringEquals": {
                        "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" 
    2
    
                    }
                }
            }
        ]
    }
    EOF
    Copy to Clipboard Toggle word wrap
    1
    指定 OIDC 身份提供程序的 Amazon 资源名称(ARN),如 arn:aws:iam::777777777777:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f
    2
    指定 AWS Load Balancer Controller 的服务帐户。一个 <cluster_oidc_endpoint> 示例是 rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f
  2. 运行以下命令,使用生成的信任策略创建 IAM 角色:

    $ aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.json
    Copy to Clipboard Toggle word wrap

    输出示例

    ROLE	arn:aws:iam::<aws_account_number>:role/albo-operator	2023-08-02T12:13:22Z 
    1
    
    ASSUMEROLEPOLICYDOCUMENT	2012-10-17
    STATEMENT	sts:AssumeRoleWithWebIdentity	Allow
    STRINGEQUALS	system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-manager
    PRINCIPAL	arn:aws:iam:<aws_account_number>:oidc-provider/<cluster_oidc_endpoint>
    Copy to Clipboard Toggle word wrap

    1
    为 AWS Load Balancer Operator 创建的 AWS IAM 角色的 ARN,如 arn:aws:iam::777777777777:role/albo-operator
  3. 运行以下命令,下载 AWS Load Balancer Operator 的权限策略:

    $ curl -o albo-operator-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-permission-policy.json
    Copy to Clipboard Toggle word wrap
  4. 运行以下命令,将 AWS Load Balancer Controller 的权限策略附加到 IAM 角色:

    $ aws iam put-role-policy --role-name albo-operator --policy-name perms-policy-albo-operator --policy-document file://albo-operator-permission-policy.json
    Copy to Clipboard Toggle word wrap

2.3.3. 为 AWS Load Balancer Operator 配置 ARN 角色

您可以将 AWS Load Balancer Operator 的 Amazon 资源名称 (ARN) 角色配置为环境变量。您可以使用 CLI 配置 ARN 角色。

先决条件

  • 已安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令来创建 aws-load-balancer-operator 项目:

    $ oc new-project aws-load-balancer-operator
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令来创建 OperatorGroup 对象:

    $ cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: aws-load-balancer-operator
      namespace: aws-load-balancer-operator
    spec:
      targetNamespaces: []
    EOF
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令来创建 Subscription 对象:

    $ cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: aws-load-balancer-operator
      namespace: aws-load-balancer-operator
    spec:
      channel: stable-v1
      name: aws-load-balancer-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      config:
        env:
        - name: ROLEARN
          value: "<albo_role_arn>" 
    1
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    指定 CredentialsRequest 中使用的 ARN 角色,以便为 AWS Load Balancer Operator 置备 AWS 凭证。一个 <albo_role_arn> 示例是 arn:aws:iam::<aws_account_number>:role/albo-operator
    注意

    AWS Load Balancer Operator 会在进入 Available 状态前等待创建 secret。

2.3.4. 为 AWS Load Balancer Controller 创建 IAM 角色

AWS Load Balancer Controller 的 CredentialsRequest 对象必须使用手动置备的 IAM 角色设置。

您可以使用以下选项创建 IAM 角色:

如果您的环境不支持 ccoctl 命令,请使用 AWS CLI。

您可以使用 Cloud Credential Operator 实用程序(ccoctl) 为 AWS Load Balancer Controller 创建 AWS IAM 角色。AWS IAM 角色用于与子网和虚拟私有云 (VPC) 交互。

先决条件

  • 您必须提取并准备 ccoctl 二进制文件。

流程

  1. 运行以下命令,下载 CredentialsRequest 自定义资源 (CR) 并将其存储在目录中:

    $ curl --create-dirs -o <credentials_requests_dir>/controller.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yaml
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令,使用 ccoctl 实用程序创建 AWS IAM 角色:

    $ ccoctl aws create-iam-roles \
        --name <name> \
        --region=<aws_region> \
        --credentials-requests-dir=<credentials_requests_dir> \
        --identity-provider-arn <oidc_arn>
    Copy to Clipboard Toggle word wrap

    输出示例

    2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-controller created 
    1
    
    2023/09/12 11:38:57 Saved credentials configuration to: /home/user/<credentials_requests_dir>/manifests/aws-load-balancer-operator-aws-load-balancer-controller-credentials.yaml
    2023/09/12 11:38:58 Updated Role policy for Role <name>-aws-load-balancer-operator-aws-load-balancer-controller created
    Copy to Clipboard Toggle word wrap

    1
    请注意为 AWS Load Balancer Controller 创建的 AWS IAM 角色的 Amazon Resource Name (ARN),如 arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-controller
    注意

    AWS IAM 角色名称的长度必须小于或等于 12 个字符。

2.3.4.2. 使用 AWS CLI 为控制器创建 AWS IAM 角色

您可以使用 AWS 命令行界面为 AWS Load Balancer Controller 创建 AWS IAM 角色。AWS IAM 角色用于与子网和虚拟私有云 (VPC) 交互。

先决条件

  • 您必须有权访问 AWS 命令行界面 (aws)。

流程

  1. 运行以下命令,使用身份提供程序生成信任策略文件:

    $ cat <<EOF > albo-controller-trust-policy.json
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Federated": "<oidc_arn>" 
    1
    
                },
                "Action": "sts:AssumeRoleWithWebIdentity",
                "Condition": {
                    "StringEquals": {
                        "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" 
    2
    
                    }
                }
            }
        ]
    }
    EOF
    Copy to Clipboard Toggle word wrap
    1
    指定 OIDC 身份提供程序的 Amazon 资源名称(ARN),如 arn:aws:iam::777777777777:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f
    2
    指定 AWS Load Balancer Controller 的服务帐户。一个 <cluster_oidc_endpoint> 示例是 rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f
  2. 运行以下命令,使用生成的信任策略创建 AWS IAM 角色:

    $ aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.json
    Copy to Clipboard Toggle word wrap

    输出示例

    ROLE	arn:aws:iam::<aws_account_number>:role/albo-controller	2023-08-02T12:13:22Z 
    1
    
    ASSUMEROLEPOLICYDOCUMENT	2012-10-17
    STATEMENT	sts:AssumeRoleWithWebIdentity	Allow
    STRINGEQUALS	system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager
    PRINCIPAL	arn:aws:iam:<aws_account_number>:oidc-provider/<cluster_oidc_endpoint>
    Copy to Clipboard Toggle word wrap

    1
    AWS Load Balancer Controller 的 AWS IAM 角色的 ARN,如 arn:aws:iam::777777777777:role/albo-controller
  3. 运行以下命令,下载 AWS Load Balancer Controller 的权限策略:

    $ curl -o albo-controller-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/assets/iam-policy.json
    Copy to Clipboard Toggle word wrap
  4. 运行以下命令,将 AWS Load Balancer Controller 的权限策略附加到 AWS IAM 角色:

    $ aws iam put-role-policy --role-name albo-controller --policy-name perms-policy-albo-controller --policy-document file://albo-controller-permission-policy.json
    Copy to Clipboard Toggle word wrap
  5. 创建定义 AWSLoadBalancerController 对象的 YAML 文件:

    sample-aws-lb-manual-creds.yaml 文件示例

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController 
    1
    
    metadata:
      name: cluster 
    2
    
    spec:
      credentialsRequestConfig:
        stsIAMRoleARN: <albc_role_arn> 
    3
    Copy to Clipboard Toggle word wrap

    1
    定义 AWSLoadBalancerController 对象。
    2
    定义 AWS Load Balancer Controller 名称。所有相关资源都使用此实例名称作为后缀。
    3
    指定 AWS Load Balancer Controller 的 ARN 角色。CredentialsRequest 对象使用此 ARN 角色来置备 AWS 凭证。一个 <albc_role_arn> 示例是 arn:aws:iam::777777777777:role/albo-controller

2.4. 安装 AWS Load Balancer Operator

AWS Load Balancer Operator 部署和管理 AWS Load Balancer Controller。您可以使用 OpenShift Container Platform Web 控制台或 CLI 安装来自 OperatorHub 的 AWS Load Balancer Operator。

您可以使用 Web 控制台安装 AWS Load Balancer Operator。

先决条件

  • 已作为具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform Web 控制台。
  • 集群被配置为使用 AWS 作为平台类型和云供应商。
  • 如果您使用安全令牌服务(STS)或用户置备的基础架构,请按照相关的准备步骤操作。例如,如果您使用 AWS 安全令牌服务,请参阅使用 AWS 安全令牌服务(STS) "在集群中准备 AWS Load Balancer Operator"。

流程

  1. 在 OpenShift Container Platform Web 控制台中进入 OperatorsOperatorHub
  2. 选择 AWS Load Balancer Operator。您可以使用 Filter by keyword 文本框,或者使用过滤器列表从 Operator 列表搜索 AWS Load Balancer Operator。
  3. 选择 aws-load-balancer-operator 命名空间。
  4. Install Operator 页面中,选择以下选项:

    1. 更新频道stable-v1
    2. 安装模式All namespaces on the cluster (default)
    3. Installed Namespaceaws-load-balancer-operator。如果 aws-load-balancer-operator 命名空间不存在,它会在 Operator 安装过程中创建。
    4. 选择 Update approvalAutomaticManual。默认情况下,Update approval 设置为 Automatic。如果选择自动更新,Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例,而无需任何干预。如果选择手动更新,OLM 将创建一个更新请求。作为集群管理员,您必须手动批准该更新请求,以便将 Operator 更新至新版本。
  5. Install

验证

  • 在 Installed Operators 仪表板中验证 AWS Load Balancer Operator 的 Status 显示为 Succeeded

2.4.2. 使用 CLI 安装 AWS Load Balancer Operator

您可以使用 CLI 安装 AWS Load Balancer Operator。

先决条件

  • 以具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform Web 控制台。
  • 集群被配置为使用 AWS 作为平台类型和云供应商。
  • 已登陆到 OpenShift CLI (oc)。

流程

  1. 创建一个 Namespace 对象:

    1. 创建定义 Namespace 对象的 YAML 文件:

      namespace.yaml 文件示例

      apiVersion: v1
      kind: Namespace
      metadata:
        name: aws-load-balancer-operator
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来创建 Namespace 对象:

      $ oc apply -f namespace.yaml
      Copy to Clipboard Toggle word wrap
  2. 创建一个 OperatorGroup 对象:

    1. 创建定义 OperatorGroup 对象的 YAML 文件:

      operatorgroup.yaml 文件示例

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: aws-lb-operatorgroup
        namespace: aws-load-balancer-operator
      spec:
        upgradeStrategy: Default
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来创建 OperatorGroup 对象:

      $ oc apply -f operatorgroup.yaml
      Copy to Clipboard Toggle word wrap
  3. 创建 Subscription 对象:

    1. 创建定义 Subscription 对象的 YAML 文件:

      subscription.yaml 文件示例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: aws-load-balancer-operator
        namespace: aws-load-balancer-operator
      spec:
        channel: stable-v1
        installPlanApproval: Automatic
        name: aws-load-balancer-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来创建 Subscription 对象:

      $ oc apply -f subscription.yaml
      Copy to Clipboard Toggle word wrap

验证

  1. 从订阅中获取安装计划的名称:

    $ oc -n aws-load-balancer-operator \
      get subscription aws-load-balancer-operator \
      --template='{{.status.installplan.name}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  2. 检查安装计划的状态:

    $ oc -n aws-load-balancer-operator \
      get ip <install_plan_name> \
      --template='{{.status.phase}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap

    输出必须是 Complete

2.4.3. 创建 AWS Load Balancer Controller

您只能在集群中安装 AWSLoadBalancerController 对象的单个实例。您可以使用 CLI 创建 AWS Load Balancer Controller。AWS Load Balancer Operator 只协调名为 resource 的集群

先决条件

  • 您已创建了 echoserver 命名空间。
  • 您可以访问 OpenShift CLI(oc)。

流程

  1. 创建定义 AWSLoadBalancerController 对象的 YAML 文件:

    sample-aws-lb.yaml 文件示例

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController 
    1
    
    metadata:
      name: cluster 
    2
    
    spec:
      subnetTagging: Auto 
    3
    
      additionalResourceTags: 
    4
    
      - key: example.org/security-scope
        value: staging
      ingressClass: alb 
    5
    
      config:
        replicas: 2 
    6
    
      enabledAddons: 
    7
    
        - AWSWAFv2 
    8
    Copy to Clipboard Toggle word wrap

    1
    定义 AWSLoadBalancerController 对象。
    2
    定义 AWS Load Balancer Controller 名称。此实例名称作为后缀添加到所有相关资源。
    3
    配置 AWS Load Balancer Controller 的子网标记方法。以下值有效:
    • Auto :AWS Load Balancer Operator 决定属于集群的子网,并相应地标记它们。如果内部子网上不存在内部子网标签,Operator 无法正确确定角色。
    • Manual :您可以使用适当的角色标签手动标记属于集群的子网。如果在用户提供的基础架构上安装集群,则使用这个选项。
    4
    定义在置备 AWS 资源时 AWS Load Balancer Controller 使用的标签。
    5
    定义入口类名称。默认值为 alb
    6
    指定 AWS Load Balancer Controller 的副本数。
    7
    将注解指定为 AWS Load Balancer Controller 的附加组件。
    8
    启用 alb.ingress.kubernetes.io/wafv2-acl-arn 注解。
  2. 运行以下命令来创建 AWSLoadBalancerController 对象:

    $ oc create -f sample-aws-lb.yaml
    Copy to Clipboard Toggle word wrap
  3. 创建定义 Deployment 资源的 YAML 文件:

    sample-aws-lb.yaml 文件示例

    apiVersion: apps/v1
    kind: Deployment 
    1
    
    metadata:
      name: <echoserver> 
    2
    
      namespace: echoserver
    spec:
      selector:
        matchLabels:
          app: echoserver
      replicas: 3 
    3
    
      template:
        metadata:
          labels:
            app: echoserver
        spec:
          containers:
            - image: openshift/origin-node
              command:
               - "/bin/socat"
              args:
                - TCP4-LISTEN:8080,reuseaddr,fork
                - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
              imagePullPolicy: Always
              name: echoserver
              ports:
                - containerPort: 8080
    Copy to Clipboard Toggle word wrap

    1
    定义部署资源。
    2
    指定部署名称。
    3
    指定部署的副本数量。
  4. 创建定义 Service 资源的 YAML 文件:

    service-albo.yaml 文件示例

    apiVersion: v1
    kind: Service 
    1
    
    metadata:
      name: <echoserver> 
    2
    
      namespace: echoserver
    spec:
      ports:
        - port: 80
          targetPort: 8080
          protocol: TCP
      type: NodePort
      selector:
        app: echoserver
    Copy to Clipboard Toggle word wrap

    1
    定义服务资源。
    2
    指定服务名称。
  5. 创建定义 Ingress 资源的 YAML 文件:

    ingress-albo.yaml 文件示例

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: <name> 
    1
    
      namespace: echoserver
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/target-type: instance
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: <echoserver> 
    2
    
                    port:
                      number: 80
    Copy to Clipboard Toggle word wrap

    1
    Ingress 资源指定一个名称。
    2
    指定服务名称。

验证

  • 运行以下命令,将 Ingress 资源的状态保存到 HOST 变量中:

    $ HOST=$(oc get ingress -n echoserver echoserver --template='{{(index .status.loadBalancer.ingress 0).hostname}}')
    Copy to Clipboard Toggle word wrap
  • 运行以下命令,验证 Ingress 资源的状态:

    $ curl $HOST
    Copy to Clipboard Toggle word wrap

2.5. 配置 AWS Load Balancer Operator

2.5.1. 信任集群范围代理的证书颁发机构

您可以在 AWS Load Balancer Operator 中配置集群范围代理。配置集群范围代理后,Operator Lifecycle Manager (OLM) 会使用 HTTP_PROXYHTTPS_PROXYNO_PROXY 等环境变量自动更新 Operator 的所有部署。这些变量由 AWS Load Balancer Operator 填充给受管控制器。

  1. 运行以下命令,创建配置映射以在 aws-load-balancer-operator 命名空间中包含证书颁发机构 (CA) 捆绑包:

    $ oc -n aws-load-balancer-operator create configmap trusted-ca
    Copy to Clipboard Toggle word wrap
  2. 要将可信 CA 捆绑包注入配置映射中,请运行以下命令将 config.openshift.io/inject-trusted-cabundle=true 标签添加到配置映射中:

    $ oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令,更新 AWS Load Balancer Operator 订阅以访问 AWS Load Balancer Operator 部署中的配置映射:

    $ oc -n aws-load-balancer-operator patch subscription aws-load-balancer-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}],"volumes":[{"name":"trusted-ca","configMap":{"name":"trusted-ca"}}],"volumeMounts":[{"name":"trusted-ca","mountPath":"/etc/pki/tls/certs/albo-tls-ca-bundle.crt","subPath":"ca-bundle.crt"}]}}}'
    Copy to Clipboard Toggle word wrap
  4. 部署 AWS Load Balancer Operator 后,运行以下命令来验证 CA 捆绑包是否已添加到 aws-load-balancer-operator-controller-manager 部署中:

    $ oc -n aws-load-balancer-operator exec deploy/aws-load-balancer-operator-controller-manager -c manager -- bash -c "ls -l /etc/pki/tls/certs/albo-tls-ca-bundle.crt; printenv TRUSTED_CA_CONFIGMAP_NAME"
    Copy to Clipboard Toggle word wrap

    输出示例

    -rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt
    trusted-ca
    Copy to Clipboard Toggle word wrap

  5. 可选:通过运行以下命令,每次 configmap 发生变化时重启 AWS Load Balancer Operator 的部署:

    $ oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
    Copy to Clipboard Toggle word wrap

2.5.2. 在 AWS Load Balancer 中添加 TLS 终止

您可以将域的流量路由到服务的 pod,并在 AWS 负载均衡器中添加 TLS 终止。

先决条件

  • 您可以访问 OpenShift CLI(oc)。

流程

  1. 创建定义 AWSLoadBalancerController 资源的 YAML 文件:

    add-tls-termination-albc.yaml 文件示例

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController
    metadata:
      name: cluster
    spec:
      subnetTagging: Auto
      ingressClass: tls-termination 
    1
    Copy to Clipboard Toggle word wrap

    1
    定义入口类名称。如果集群中没有 ingress 类,AWS Load Balancer Controller 会创建一个。如果 spec.controller 设置为 ingress.k8s.aws/alb,AWS Load Balancer Controller 会协调额外的入口类值。
  2. 创建定义 Ingress 资源的 YAML 文件:

    add-tls-termination-ingress.yaml 文件示例

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: <example> 
    1
    
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing 
    2
    
        alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx 
    3
    
    spec:
      ingressClassName: tls-termination 
    4
    
      rules:
      - host: example.com 
    5
    
        http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: <example_service> 
    6
    
                    port:
                      number: 80
    Copy to Clipboard Toggle word wrap

    1
    指定入口名称。
    2
    控制器在公共子网中为入口置备负载均衡器,以便通过互联网访问负载均衡器。
    3
    附加到负载均衡器的证书的 Amazon 资源名称(ARN)。
    4
    定义入口类名称。
    5
    定义流量路由的域。
    6
    定义流量路由的服务。

您可以通过单个 AWS Load Balancer 将流量路由到属于单个域一部分的、带有多个 ingress 资源的不同服务。每个 ingress 资源提供了域的不同端点。

先决条件

  • 您可以访问 OpenShift CLI(oc)。

流程

  1. 创建一个 IngressClassParams 资源 YAML 文件,如 sample-single-lb-params.yaml,如下所示:

    apiVersion: elbv2.k8s.aws/v1beta1 
    1
    
    kind: IngressClassParams
    metadata:
      name: single-lb-params 
    2
    
    spec:
      group:
        name: single-lb 
    3
    Copy to Clipboard Toggle word wrap
    1
    定义 IngressClassParams 资源的 API 组和版本。
    2
    指定 IngressClassParams 资源名称。
    3
    指定 IngressGroup 资源名称。此类的所有 Ingress 资源都属于此 IngressGroup
  2. 运行以下命令来创建 IngressClassParams 资源:

    $ oc create -f sample-single-lb-params.yaml
    Copy to Clipboard Toggle word wrap
  3. 创建 IngressClass 资源 YAML 文件,如 sample-single-lb-class.yaml,如下所示:

    apiVersion: networking.k8s.io/v1 
    1
    
    kind: IngressClass
    metadata:
      name: single-lb 
    2
    
    spec:
      controller: ingress.k8s.aws/alb 
    3
    
      parameters:
        apiGroup: elbv2.k8s.aws 
    4
    
        kind: IngressClassParams 
    5
    
        name: single-lb-params 
    6
    Copy to Clipboard Toggle word wrap
    1
    定义 IngressClass 资源的 API 组和版本。
    2
    指定入口类名称。
    3
    定义控制器名称。ingress.k8s.aws/alb 值表示此类的所有入口资源都应由 AWS Load Balancer Controller 管理。
    4
    定义 IngressClassParams 资源的 API 组。
    5
    定义 IngressClassParams 资源的资源类型。
    6
    定义 IngressClassParams 资源名称。
  4. 运行以下命令来创建 IngressClass 资源:

    $ oc create -f sample-single-lb-class.yaml
    Copy to Clipboard Toggle word wrap
  5. 创建 AWSLoadBalancerController 资源 YAML 文件,如 sample-single-lb.yaml,如下所示:

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController
    metadata:
      name: cluster
    spec:
      subnetTagging: Auto
      ingressClass: single-lb 
    1
    Copy to Clipboard Toggle word wrap
    1
    定义 IngressClass 资源的名称。
  6. 运行以下命令来创建 AWSLoadBalancerController 资源:

    $ oc create -f sample-single-lb.yaml
    Copy to Clipboard Toggle word wrap
  7. 创建 Ingress 资源 YAML 文件,如 sample-multiple-ingress.yaml,如下所示:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-1 
    1
    
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing 
    2
    
        alb.ingress.kubernetes.io/group.order: "1" 
    3
    
        alb.ingress.kubernetes.io/target-type: instance 
    4
    
    spec:
      ingressClassName: single-lb 
    5
    
      rules:
      - host: example.com 
    6
    
        http:
            paths:
            - path: /blog 
    7
    
              pathType: Prefix
              backend:
                service:
                  name: example-1 
    8
    
                  port:
                    number: 80 
    9
    
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-2
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/group.order: "2"
        alb.ingress.kubernetes.io/target-type: instance
    spec:
      ingressClassName: single-lb
      rules:
      - host: example.com
        http:
            paths:
            - path: /store
              pathType: Prefix
              backend:
                service:
                  name: example-2
                  port:
                    number: 80
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-3
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/group.order: "3"
        alb.ingress.kubernetes.io/target-type: instance
    spec:
      ingressClassName: single-lb
      rules:
      - host: example.com
        http:
            paths:
            - path: /
              pathType: Prefix
              backend:
                service:
                  name: example-3
                  port:
                    number: 80
    Copy to Clipboard Toggle word wrap
    1
    指定入口名称。
    2
    指明在公共子网中置备的负载均衡器,以访问互联网。
    3
    指定在负载均衡器收到请求时,来自多个入口资源的规则的顺序匹配。
    4
    表示负载均衡器将针对 OpenShift Container Platform 节点为目标,以访问该服务。
    5
    指定属于此入口的入口类。
    6
    定义用于请求路由的域名。
    7
    定义必须路由到服务的路径。
    8
    定义提供 Ingress 资源中配置的端点的服务名称。
    9
    定义服务上提供端点的端口。
  8. 运行以下命令来创建 Ingress 资源:

    $ oc create -f sample-multiple-ingress.yaml
    Copy to Clipboard Toggle word wrap

2.5.4. AWS Load Balancer Operator 日志

您可以使用 oc logs 命令查看 AWS Load Balancer Operator 日志。

流程

  • 运行以下命令,查看 AWS Load Balancer Operator 的日志:

    $ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager
    Copy to Clipboard Toggle word wrap

第 3 章 eBPF manager Operator

3.1. 关于 eBPF Manager Operator

重要

eBPF Manager Operator 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

3.1.1. 关于扩展 Berkeley Packet Filter (eBPF)

eBPF 扩展原始 Berkeley Packet 过滤器,用于高级网络流量过滤。它充当 Linux 内核中的虚拟机,允许您运行沙盒程序来响应网络数据包、系统调用或内核功能等事件。

3.1.2. 关于 eBPF Manager Operator

eBPF Manager 简化了 Kubernetes 中的 eBPF 程序的管理和部署,以及增强使用 eBPF 程序的安全性。它利用 Kubernetes 自定义资源定义 (CRD) 来管理打包为 OCI 容器镜像的 eBPF 程序。这种方法有助于通过限制特定用户可部署的程序类型来划分部署权限并增强安全性。

eBPF Manager 是一个软件堆栈,用于在 Kubernetes 中管理 eBPF 程序。它有助于在 Kubernetes 集群中对 eBPF 程序进行加载、卸载、修改和监控。它包括守护进程、CRD、代理和 Operator:

bpfman
通过 gRPC API 管理 eBPF 程序的系统守护进程。
eBPF CRD
一组 CRD,如 XdpProgram 和 TcProgram 用于加载 eBPF 程序,以及一个代表载入程序状态的由 bpfman 生成的 CRD (BpfProgram)。
bpfman-agent
在 daemonset 容器中运行,确保每个节点上的 eBPF 程序处于所需的状态。
bpfman-operator
使用 Operator SDK 管理集群中的 bpfman-agent 和 CRD 的生命周期。

eBPF Manager Operator 提供以下功能:

  • 通过一个控制的守护进程来集中 eBPF 程序加载功能以增强安全性。eBPF Manager 具有升级的特权,因此应用程序不需要这些权限。 eBPF 程序控制遵循标准的 Kubernetes 基于角色的访问控制 (RBAC)机制,它可以允许或拒绝应用程序对用于管理 eBPF 程序加载和卸载的不同 eBPF Manager CRD 的访问。
  • 提供对活跃 eBPF 程序的详细可见性,提高了您在系统中调试问题的能力。
  • 可以使来自不同源的多个 eBPF 程序共存,使用 libxdp 等协议用于 XDP 和 TC 程序,从而增强了互操作性。
  • 简化 Kubernetes 中 eBPF 程序的部署和生命周期管理。开发人员可以专注于程序交互,而不是生命周期管理,支持现有 eBPF 库,如 Cilium、libbpf 和 Aya。

3.1.4. 后续步骤

3.2. 安装 eBPF Manager Operator

作为集群管理员,您可以使用 OpenShift Container Platform CLI 或 Web 控制台安装 eBPF Manager Operator。

重要

eBPF Manager Operator 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

3.2.1. 使用 CLI 安装 eBPF Manager Operator

作为集群管理员,您可以使用 CLI 安装 Operator。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 有管理员特权的帐户。

流程

  1. 运行以下命令来创建 bpfman 命名空间:

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/enforce-version: v1.24
      name: bpfman
    EOF
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令来创建 OperatorGroup CR:

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: bpfman-operators
      namespace: bpfman
    EOF
    Copy to Clipboard Toggle word wrap
  3. 订阅 eBPF Manager Operator。

    1. 要为 eBPF Manager Operator 创建 Subscription CR,请输入以下命令:

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bpfman-operator
        namespace: bpfman
      spec:
        name: bpfman-operator
        channel: alpha
        source: community-operators
        sourceNamespace: openshift-marketplace
      EOF
      Copy to Clipboard Toggle word wrap
  4. 要验证是否已安装 Operator,请输入以下命令:

    $ oc get ip -n bpfman
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME            CSV                                 APPROVAL    APPROVED
    install-ppjxl   security-profiles-operator.v0.8.5   Automatic   true
    Copy to Clipboard Toggle word wrap

  5. 要验证 Operator 的版本,请输入以下命令:

    $ oc get csv -n bpfman
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
    bpfman-operator.v0.5.0              eBPF Manager Operator              0.5.0     bpfman-operator.v0.4.2              Succeeded
    Copy to Clipboard Toggle word wrap

3.2.2. 使用 Web 控制台安装 eBPF Manager Operator

作为集群管理员,您可以使用 Web 控制台安装 eBPF Manager Operator。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 有管理员特权的帐户。

流程

  1. 安装 eBPF Manager Operator:

    1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
    2. 从可用的 Operator 列表中选择 eBPF Manager Operator,如果提示输入 Show community Operator,请点 Continue
    3. Install
    4. Install Operator 页面中,在 Installed Namespace 下选择 Operator recommended Namespace
    5. Install
  2. 验证 eBPF Manager Operator 是否已成功安装:

    1. 导航到 OperatorsInstalled Operators 页面。
    2. 确保 openshift-ingress-node-firewall 项目中列出的 eBPF Manager OperatorStatusInstallSucceeded

      注意

      在安装过程中,Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息,您可以忽略这个 Failed 信息。

      如果 Operator 没有 InstallSucceeded 状态,请按照以下步骤进行故障排除:

      • 检查 Operator SubscriptionsInstall Plans 选项卡中的 Status 项中是否有任何错误。
      • 进入到 WorkloadsPods 页面,在 bpfman 项目中检查 pod 的日志。

3.2.3. 后续步骤

3.3. 部署 eBPF 程序

作为集群管理员,您可以使用 eBPF Manager Operator 部署容器化 eBPF 应用程序。

对于此流程中部署的 eBPF 程序示例,示例清单执行以下操作:

首先,它创建基本的 Kubernetes 对象,如 NamespaceServiceAccountClusterRoleBinding。它还创建一个 XdpProgram 对象,它是 eBPF Manager 提供的自定义资源定义(CRD) 来加载 eBPF XDP 程序。每种程序类型都有自己的 CRD,但它们的作用类似。如需更多信息,请参阅在 Kubernetes 上加载 eBPF 程序

其次,它会创建一个守护进程集,运行一个用户空间程序,该程序读取 eBPF 程序生成的 eBPF 映射信息。此 eBPF 映射是使用 Container Storage Interface (CSI) 驱动程序挂载的卷。通过在容器中挂载 eBPF 映射来实现在主机上访问它的效果,应用程序 pod 可以在没有特权的情况下访问 eBPF 映射。有关如何配置 CSI 的更多信息,请参阅在 Kubernetes 上部署 eBPF 的应用程序

重要

eBPF Manager Operator 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

3.3.1. 部署容器化的 eBPF 程序

作为集群管理员,您可以将 eBPF 程序部署到集群中的节点。在此过程中,在 go-xdp-counter 命名空间中安装了一个容器化的 eBPF 程序示例。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 有管理员特权的帐户。
  • 已安装 eBPF Manager Operator。

流程

  1. 要下载清单,请输入以下命令:

    $ curl -L https://github.com/bpfman/bpfman/releases/download/v0.5.1/go-xdp-counter-install-selinux.yaml -o go-xdp-counter-install-selinux.yaml
    Copy to Clipboard Toggle word wrap
  2. 要部署示例 eBPF 应用程序,请输入以下命令:

    $ oc create -f go-xdp-counter-install-selinux.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    namespace/go-xdp-counter created
    serviceaccount/bpfman-app-go-xdp-counter created
    clusterrolebinding.rbac.authorization.k8s.io/xdp-binding created
    daemonset.apps/go-xdp-counter-ds created
    xdpprogram.bpfman.io/go-xdp-counter-example created
    selinuxprofile.security-profiles-operator.x-k8s.io/bpfman-secure created
    Copy to Clipboard Toggle word wrap

  3. 要确认 eBPF 示例应用程序已被成功部署,请输入以下命令:

    $ oc get all -o wide -n go-xdp-counter
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                          READY   STATUS    RESTARTS   AGE   IP             NODE                                 NOMINATED NODE   READINESS GATES
    pod/go-xdp-counter-ds-4m9cw   1/1     Running   0          44s   10.129.0.92    ci-ln-dcbq7d2-72292-ztrkp-master-1   <none>           <none>
    pod/go-xdp-counter-ds-7hzww   1/1     Running   0          44s   10.130.0.86    ci-ln-dcbq7d2-72292-ztrkp-master-2   <none>           <none>
    pod/go-xdp-counter-ds-qm9zx   1/1     Running   0          44s   10.128.0.101   ci-ln-dcbq7d2-72292-ztrkp-master-0   <none>           <none>
    
    NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS       IMAGES                                           SELECTOR
    daemonset.apps/go-xdp-counter-ds   3         3         3       3            3           <none>          44s   go-xdp-counter   quay.io/bpfman-userspace/go-xdp-counter:v0.5.0   name=go-xdp-counter
    Copy to Clipboard Toggle word wrap

  4. 要确认示例 XDP 程序正在运行,请输入以下命令:

    $ oc get xdpprogram go-xdp-counter-example
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                     BPFFUNCTIONNAME   NODESELECTOR   STATUS
    go-xdp-counter-example   xdp_stats         {}             ReconcileSuccess
    Copy to Clipboard Toggle word wrap

  5. 要确认 XDP 程序正在收集数据,请输入以下命令:

    $ oc logs <pod_name> -n go-xdp-counter
    Copy to Clipboard Toggle word wrap

    <pod_name> 替换为 XDP 程序 pod 的名称,如 go-xdp-counter-ds-4m9cw

    输出示例

    2024/08/13 15:20:06 15016 packets received
    2024/08/13 15:20:06 93581579 bytes received
    ...
    Copy to Clipboard Toggle word wrap

第 4 章 外部 DNS Operator

4.1. 外部 DNS Operator 发行注记

External DNS Operator 部署并管理 ExternalDNS,以便为从外部 DNS 供应商到 OpenShift Container Platform 的服务和路由提供名称解析。

重要

External DNS Operator 仅在 x86_64 架构上被支持。

本发行注记介绍了 OpenShift Container Platform 中外部 DNS Operator 的开发。

4.1.1. 外部 DNS Operator 1.3.0

以下公告可用于外部 DNS Operator 版本 1.3.0 :

此更新包括更新到上游项目的 0.14.2 版本。

4.1.1.1. 程序错误修复

在以前的版本中,ExternalDNS Operator 无法在 HCP 集群中部署操作对象。在这个版本中,Operator 以 running 和 ready 状态部署操作对象。(OCPBUGS-37059)

在以前的版本中,ExternalDNS Operator 没有使用 RHEL 9 作为其构建或基础镜像。在这个版本中,RHEL9 是基础。(OCPBUGS-41683)

在以前的版本中,godoc 为 Infoblox 供应商有一个有问题的链接。在这个版本中,godoc 被修改为准确性。有些链接在其它链接被 GitHub permalinks 替换时会被删除。(OCPBUGS-36797)

4.1.2. 外部 DNS Operator 1.2.0

以下公告可用于外部 DNS Operator 版本 1.2.0 :

4.1.2.1. 新功能
4.1.2.2. 程序错误修复
  • 操作对象的更新策略从 Rolling 改为 Recreate。(OCPBUGS-3630)

4.1.3. 外部 DNS Operator 1.1.1

以下公告可用于外部 DNS Operator 版本 1.1.1:

4.1.4. 外部 DNS Operator 1.1.0

此发行版本包含来自上游项目 0.13.1 版本的操作对象的变基。以下公告可用于外部 DNS Operator 版本 1.1.0:

4.1.4.1. 程序错误修复
  • 在以前的版本中,ExternalDNS Operator 为卷强制有一个空的 defaultMode 值,这会导致因为与 OpenShift API 冲突而造成恒定的更新。现在,defaultMode 值不会被强制,操作对象部署不会持续更新。(OCPBUGS-2793)

4.1.5. 外部 DNS Operator 1.0.1

以下公告可用于外部 DNS Operator 版本 1.0.1:

4.1.6. 外部 DNS Operator 1.0.0

以下公告可用于 External DNS Operator 版本 1.0.0:

4.1.6.1. 程序错误修复
  • 在以前的版本中,External DNS Operator 在 ExternalDNS 操作对象 pod 部署中发出有关违反 restricted SCC 策略的警告。这个问题已解决。(BZ#2086408)

4.2. 了解外部 DNS Operator

External DNS Operator 部署并管理 ExternalDNS,以便为从外部 DNS 供应商到 OpenShift Container Platform 的服务和路由提供名称解析。

4.2.1. 外部 DNS Operator

External DNS Operator 从 olm.openshift.io API 组实现外部 DNS API。External DNS Operator 更新服务、路由和外部 DNS 供应商。

先决条件

  • 已安装 yq CLI 工具。

流程

您可以根据 OperatorHub 的要求部署外部 DNS Operator。部署外部 DNS Operator 会创建一个 Subscription 对象。

  1. 运行以下命令,检查安装计划的名称,如 install-zcvlr

    $ oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令,检查安装计划的状态是否为 Complete

    $ oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令,查看 external-dns-operator 部署的状态:

    $ oc get -n external-dns-operator deployment/external-dns-operator
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                    READY     UP-TO-DATE   AVAILABLE   AGE
    external-dns-operator   1/1       1            1           23h
    Copy to Clipboard Toggle word wrap

4.2.2. 查看外部 DNS Operator 日志

您可以使用 oc logs 命令查看外部 DNS Operator 日志。

流程

  1. 运行以下命令,查看外部 DNS Operator 的日志:

    $ oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator
    Copy to Clipboard Toggle word wrap
4.2.2.1. 外部 DNS Operator 域名限制

External DNS Operator 使用 TXT registry,它为 TXT 记录添加前缀。这可减少 TXT 记录的域名的最大长度。没有对应的 TXT 记录时无法出现 DNS 记录,因此 DNS 记录的域名必须遵循与 TXT 记录相同的限制。例如,一个 <domain_name_from_source> DNS 记录会导致一个 external-dns-<record_type>-<domain_name_from_source> TXT 记录。

外部 DNS Operator 生成的 DNS 记录的域名有以下限制:

Expand
记录类型字符数

CNAME

44

AzureDNS 上的通配符 CNAME 记录

42

A

48

AzureDNS 上的通配符 A 记录

46

如果生成的域名超过任何域名限制,则外部 DNS Operator 日志中会出现以下错误:

time="2022-09-02T08:53:57Z" level=error msg="Failure in zone test.example.io. [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="InvalidChangeBatch: [FATAL problem: DomainLabelTooLong (Domain label is too long) encountered with 'external-dns-a-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc']\n\tstatus code: 400, request id: e54dfd5a-06c6-47b0-bcb9-a4f7c3a4e0c6"
Copy to Clipboard Toggle word wrap

4.3. 安装 External DNS Operator

您可以在云供应商环境中安装外部 DNS Operator,如 AWS、Azure 和 GCP。

4.3.1. 使用 OperatorHub 安装 External DNS Operator

您可以使用 OpenShift Container Platform OperatorHub 安装外部 DNS Operator。

流程

  1. 在 OpenShift Container Platform Web 控制台中点 OperatorsOperatorHub
  2. External DNS Operator。您可以使用 Filter by keyword 文本框或过滤器列表从 Operator 列表中搜索 External DNS Operator。
  3. 选择 external-dns-operator 命名空间。
  4. External DNS Operator 页面中,点 Install
  5. Install Operator 页面中,确保选择了以下选项:

    1. 将频道更新为 stable-v1
    2. 安装模式为 A specific name on the cluster
    3. 安装的命名空间为 external-dns-operator。如果命名空间 external-dns-operator 不存在,它会在 Operator 安装过程中创建。
    4. Approval Strategy 选为 AutomaticManual。默认情况下,批准策略设置为 Automatic
    5. Install

如果选择了 Automatic 更新,Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例,而无需任何干预。

如果选择 手动 更新,则 OLM 会创建一个更新请求。作为集群管理员,您必须手动批准该更新请求,才可将 Operator 更新至新版本。

验证

验证 External DNS Operator 是否在 Installed Operators 仪表板上显示 StatusSucceeded

4.3.2. 使用 CLI 安装 External DNS Operator

您可以使用 CLI 安装 External DNS Operator

先决条件

  • 以具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform Web 控制台。
  • 已登陆到 OpenShift CLI (oc)。

流程

  1. 创建一个 Namespace 对象:

    1. 创建定义 Namespace 对象的 YAML 文件:

      namespace.yaml 文件示例

      apiVersion: v1
      kind: Namespace
      metadata:
        name: external-dns-operator
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来创建 Namespace 对象:

      $ oc apply -f namespace.yaml
      Copy to Clipboard Toggle word wrap
  2. 创建一个 OperatorGroup 对象:

    1. 创建定义 OperatorGroup 对象的 YAML 文件:

      operatorgroup.yaml 文件示例

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: external-dns-operator
        namespace: external-dns-operator
      spec:
        upgradeStrategy: Default
        targetNamespaces:
        - external-dns-operator
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来创建 OperatorGroup 对象:

      $ oc apply -f operatorgroup.yaml
      Copy to Clipboard Toggle word wrap
  3. 创建 Subscription 对象:

    1. 创建定义 Subscription 对象的 YAML 文件:

      subscription.yaml 文件示例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: external-dns-operator
        namespace: external-dns-operator
      spec:
        channel: stable-v1
        installPlanApproval: Automatic
        name: external-dns-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来创建 Subscription 对象:

      $ oc apply -f subscription.yaml
      Copy to Clipboard Toggle word wrap

验证

  1. 运行以下命令,从订阅获取安装计划的名称:

    $ oc -n external-dns-operator \
      get subscription external-dns-operator \
      --template='{{.status.installplan.name}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令,验证安装计划的状态是否为 Complete

    $ oc -n external-dns-operator \
      get ip <install_plan_name> \
      --template='{{.status.phase}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令,验证 external-dns-operator pod 的状态是否为 Running

    $ oc -n external-dns-operator get pod
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                     READY   STATUS    RESTARTS   AGE
    external-dns-operator-5584585fd7-5lwqm   2/2     Running   0          11m
    Copy to Clipboard Toggle word wrap

  4. 运行以下命令,验证订阅的目录源是否为 redhat-operators

    $ oc -n external-dns-operator get subscription
    Copy to Clipboard Toggle word wrap
  5. 运行以下命令检查 external-dns-operator 版本:

    $ oc -n external-dns-operator get csv
    Copy to Clipboard Toggle word wrap

4.4. 外部 DNS Operator 配置参数

External DNS Operator 包括以下配置参数。

4.4.1. 外部 DNS Operator 配置参数

External DNS Operator 包括以下配置参数:

Expand
参数描述

spec

启用云供应商的类型。

spec:
  provider:
    type: AWS 
1

    aws:
      credentials:
        name: aws-access-key 
2
Copy to Clipboard Toggle word wrap
1
定义可用选项,如 AWS、GCP、Azure 和 Infoblox。
2
为云供应商定义 secret 名称。

zones

允许您根据域指定 DNS 区域。如果没有指定区,External DNS 资源会发现云供应商帐户中存在的所有区域。

zones:
- "myzoneid" 
1
Copy to Clipboard Toggle word wrap
1
指定 DNS 区域的名称。

domains

允许您根据域指定 AWS 区域。如果没有指定域,External DNS 资源会发现云供应商帐户中存在的所有区域。

domains:
- filterType: Include 
1

  matchType: Exact 
2

  name: "myzonedomain1.com" 
3

- filterType: Include
  matchType: Pattern 
4

  pattern: ".*\\.otherzonedomain\\.com" 
5
Copy to Clipboard Toggle word wrap
1
确保 ExternalDNS 资源包含域名。
2
指示 ExternalDNS 指示域匹配必须完全匹配,而不是正则表达式匹配。
3
定义域的名称。
4
ExternalDNS 资源中设置 regex-domain-filter 标志。您可以使用 Regex 过滤器来限制可能的域。
5
定义 ExternalDNS 资源用来过滤目标区的域的 regex 模式。

source

允许您指定 DNS 记录、ServiceRoute 的源。

source: 
1

  type: Service 
2

  service:
    serviceType:
3

      - LoadBalancer
      - ClusterIP
  labelFilter: 
4

    matchLabels:
      external-dns.mydomain.org/publish: "yes"
  hostnameAnnotation: "Allow" 
5

  fqdnTemplate:
  - "{{.Name}}.myzonedomain.com" 
6
Copy to Clipboard Toggle word wrap
1
定义 DNS 记录源的设置。
2
ExternalDNS 资源使用 Service 类型作为创建 DNS 记录的源。
3
ExternalDNS 资源中设置 service-type-filter 标志。serviceType 包含以下字段:
  • 默认:LoadBalancer
  • 预期:ClusterIP
  • NodePort
  • LoadBalancer
  • ExternalName
4
确保控制器只考虑与标签过滤器匹配的资源。
5
hostnameAnnotation 的默认值为 Ignore,它指示 ExternalDNS 使用字段 fqdnTemplates 中指定的模板生成 DNS 记录。当值是 Allow,DNS 记录根据 external-dns.alpha.kubernetes.io/hostname 注解中指定的值生成。
6
外部 DNS Operator 使用一个字符串从没有定义主机名的源生成 DNS 名称,或者与 fake 源配对时添加主机名后缀。
source:
  type: OpenShiftRoute 
1

  openshiftRouteOptions:
    routerName: default 
2

    labelFilter:
      matchLabels:
        external-dns.mydomain.org/publish: "yes"
Copy to Clipboard Toggle word wrap
1
创建 DNS 记录。
2
如果源类型是 OpenShiftRoute,您可以传递 Ingress Controller 名称。ExternalDNS 资源使用 Ingress Controller 的规范名称作为 CNAME 记录的目标。

4.5. 在 AWS 上创建 DNS 记录

您可以使用 External DNS Operator 在 AWS 和 AWS GovCloud 上创建 DNS 记录。

您可以使用 Red Hat External DNS Operator 在 AWS 公共托管区上创建 DNS 记录。您可以使用相同的说明在 AWS GovCloud 的托管区上创建 DNS 记录。

流程

  1. 运行以下命令,检查用户配置文件,如 system:admin。用户配置集必须有权访问 kube-system 命名空间。如果没有凭证,您可以从 kube-system 命名空间中获取凭证,运行以下命令来使用云供应商客户端:

    $ oc whoami
    Copy to Clipboard Toggle word wrap
  2. kube-system 命名空间中存在的 aws-creds secret 中获取值。

    $ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)
    Copy to Clipboard Toggle word wrap
    $ export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)
    Copy to Clipboard Toggle word wrap
  3. 获取路由来检查域:

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    输出示例

    openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  4. 获取 DNS 区域列表,并找到与您之前查询的路由域对应的 DNS 区域:

    $ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
    Copy to Clipboard Toggle word wrap

    输出示例

    HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5
    Copy to Clipboard Toggle word wrap

  5. 路由源创建 ExternalDNS 资源:

    $ cat <<EOF | oc create -f -
    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-aws 
    1
    
    spec:
      domains:
      - filterType: Include   
    2
    
        matchType: Exact   
    3
    
        name: testextdnsoperator.apacshift.support 
    4
    
      provider:
        type: AWS 
    5
    
      source:  
    6
    
        type: OpenShiftRoute 
    7
    
        openshiftRouteOptions:
          routerName: default 
    8
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    定义外部 DNS 资源的名称。
    2
    默认情况下,所有托管区都被选为潜在的目标。您可以包括需要的托管区。
    3
    目标区的域匹配必须是完全准确的(与正则表达式匹配不同)。
    4
    指定您要更新的区域的确切域。路由的主机名必须是指定域的子域。
    5
    定义 AWS Route53 DNS 供应商。
    6
    定义 DNS 记录源的选项。
    7
    定义 OpenShift 路由资源,作为在之前指定的 DNS 供应商中创建的 DNS 记录来源。
    8
    如果源是 OpenShiftRoute,您可以传递 OpenShift Ingress Controller 名称。外部 DNS Operator 在创建 CNAME 记录时,选择该路由器的规范主机名作为目标。
  6. 使用以下命令,检查为 OCP 路由创建的记录:

    $ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console
    Copy to Clipboard Toggle word wrap

您可以使用 ExternalDNS Operator 使用共享 Virtual Private Cloud (VPC)在不同的 AWS 帐户中创建 DNS 记录。通过使用共享 VPC,组织可将资源从多个项目连接到通用 VPC 网络。然后,机构可以使用 VPC 共享在多个 AWS 帐户间使用单个 Route 53 实例。

先决条件

  • 您已创建了两个 Amazon AWS 帐户:一个 VPC 和配置了 Route 53 私有托管区(帐户 A),另一个用于安装集群(帐户 B)。
  • 您已创建了具有帐户 B 的相应权限的 IAM 策略和 IAM 角色,以便在帐户 A 的 Route 53 托管区中创建 DNS 记录。
  • 您已在帐户 B 上安装了帐户 A 的集群。
  • 您已在帐户 B 的集群中安装了 ExternalDNS Operator。

流程

  1. 运行以下命令,获取您创建的 IAM 角色的 Role ARN,以允许帐户 B 访问帐户 A 的 Route 53 托管区:

    $ aws --profile account-a iam get-role --role-name user-rol1 | head -1
    Copy to Clipboard Toggle word wrap

    输出示例

    ROLE	arn:aws:iam::1234567890123:role/user-rol1	2023-09-14T17:21:54+00:00	3600	/	AROA3SGB2ZRKRT5NISNJN	user-rol1
    Copy to Clipboard Toggle word wrap

  2. 运行以下命令,找到用于帐户 A 凭证的私有托管区:

    $ aws --profile account-a route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
    Copy to Clipboard Toggle word wrap

    输出示例

    HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support. 5
    Copy to Clipboard Toggle word wrap

  3. 运行以下命令来创建 ExternalDNS 对象:

    $ cat <<EOF | oc create -f -
    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-aws
    spec:
      domains:
      - filterType: Include
        matchType: Exact
        name: testextdnsoperator.apacshift.support
      provider:
        type: AWS
        aws:
          assumeRole:
            arn: arn:aws:iam::12345678901234:role/user-rol1 
    1
    
      source:
        type: OpenShiftRoute
        openshiftRouteOptions:
          routerName: default
    EOF
    Copy to Clipboard Toggle word wrap
    1
    指定 Role ARN,以便在帐户 A 中创建 DNS 记录。
  4. 使用以下命令,检查为 OpenShift Container Platform (OCP) 路由创建的记录:

    $ aws --profile account-a route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console-openshift-console
    Copy to Clipboard Toggle word wrap

4.6. 在 Azure 上创建 DNS 记录

您可以使用外部 DNS Operator 在 Azure 上创建 DNS 记录。

重要

不支持在支持 Microsoft Entra Workload ID 的集群或在 Microsoft Azure Government (MAG) 区域中运行的集群中使用 External DNS Operator。

4.6.1. 在 Azure DNS 区域中创建 DNS 记录

您可以使用 External DNS Operator 在 Azure 的公共或私有 DNS 区域上创建域名服务器(DNS)记录。

先决条件

  • 您必须具有管理员特权。
  • admin 用户必须有权访问 kube-system 命名空间。

流程

  1. 运行以下命令,从 kube-system 命名空间中获取凭证以使用云供应商客户端:

    $ CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)
    $ CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)
    $ RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)
    $ SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)
    $ TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令来登录到 Azure:

    $ az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令来获取路由列表:

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    输出示例

    openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  4. 获取 DNS 区域列表。

    1. 对于公共 DNS 区域,请运行以下命令:

      $ az network dns zone list --resource-group "${RESOURCE_GROUP}"
      Copy to Clipboard Toggle word wrap
    2. 对于私有 DNS 区域,请运行以下命令:

      $ az network private-dns zone list -g "${RESOURCE_GROUP}"
      Copy to Clipboard Toggle word wrap
  5. 创建一个 YAML 文件,如 external-dns-sample-azure.yaml,该文件定义 ExternalDNS 对象:

    external-dns-sample-azure.yaml 文件示例

    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-azure 
    1
    
    spec:
      zones:
      - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com" 
    2
    
      provider:
        type: Azure 
    3
    
      source:
        openshiftRouteOptions: 
    4
    
          routerName: default 
    5
    
        type: OpenShiftRoute 
    6
    Copy to Clipboard Toggle word wrap

    1
    指定外部 DNS 名称。
    2
    定义区域 ID。对于私有 DNS 区域,将 dnszones 更改为 privateDnsZones
    3
    定义提供程序类型。
    4
    您可以定义 DNS 记录源的选项。
    5
    如果源类型是 OpenShiftRoute,您可以传递 OpenShift Ingress Controller 名称。外部 DNS 在创建 CNAME 记录时,选择该路由器的规范主机名作为目标。
    6
    route 资源定义为 Azure DNS 记录的来源。

故障排除

  1. 检查为路由创建的记录。

    1. 对于公共 DNS 区域,请运行以下命令:

      $ az network dns record-set list -g "${RESOURCE_GROUP}" -z "${ZONE_NAME}" | grep console
      Copy to Clipboard Toggle word wrap
    2. 对于私有 DNS 区域,请运行以下命令:

      $ az network private-dns record-set list -g "${RESOURCE_GROUP}" -z "${ZONE_NAME}" | grep console
      Copy to Clipboard Toggle word wrap

4.7. 在 GCP 上创建 DNS 记录

您可以使用 External DNS Operator 在 Google Cloud Platform (GCP) 上创建 DNS 记录。

重要

不支持在启用了 GCP Workload Identity 的集群上使用 External DNS Operator。有关 GCP Workload Identity 的更多信息,请参阅 GCP Workload Identity

4.7.1. 在 GCP 公共管理区上创建 DNS 记录

您可以使用 External DNS Operator 在 GCP 公共受管区上创建 DNS 记录。

先决条件

  • 您必须具有管理员特权。

流程

  1. 运行以下命令,将 gcp-credentials secret 复制到 encoded-gcloud.json 文件中:

    $ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令导出 Google 凭证:

    $ export GOOGLE_CREDENTIALS=decoded-gcloud.json
    Copy to Clipboard Toggle word wrap
  3. 使用以下命令激活您的帐户:

    $ gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json
    Copy to Clipboard Toggle word wrap
  4. 运行以下命令来设置项目:

    $ gcloud config set project <project_id as per decoded-gcloud.json>
    Copy to Clipboard Toggle word wrap
  5. 运行以下命令来获取路由列表:

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    输出示例

    openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  6. 运行以下命令,获取受管区域的列表,如 qe-cvs4g-private-zone test.gcp.example.com

    $ gcloud dns managed-zones list | grep test.gcp.example.com
    Copy to Clipboard Toggle word wrap
  7. 创建一个 YAML 文件,如 external-dns-sample-gcp.yaml,该文件定义 ExternalDNS 对象:

    external-dns-sample-gcp.yaml 文件示例

    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-gcp 
    1
    
    spec:
      domains:
        - filterType: Include 
    2
    
          matchType: Exact 
    3
    
          name: test.gcp.example.com 
    4
    
      provider:
        type: GCP 
    5
    
      source:
        openshiftRouteOptions: 
    6
    
          routerName: default 
    7
    
        type: OpenShiftRoute 
    8
    Copy to Clipboard Toggle word wrap

    1
    指定外部 DNS 名称。
    2
    默认情况下,所有托管区都被选为潜在的目标。您可以包含托管区。
    3
    目标的域必须与 name 键定义的字符串匹配。
    4
    指定您要更新的区域的确切域。路由的主机名必须是指定域的子域。
    5
    定义提供程序类型。
    6
    您可以定义 DNS 记录源的选项。
    7
    如果源类型是 OpenShiftRoute,您可以传递 OpenShift Ingress Controller 名称。外部 DNS 在创建 CNAME 记录时,选择该路由器的规范主机名作为目标。
    8
    route 资源定义为 GCP DNS 记录的源。
  8. 运行以下命令,检查为 OpenShift Container Platform 路由创建的 DNS 记录:

    $ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
    Copy to Clipboard Toggle word wrap

4.8. 在 Infoblox 上创建 DNS 记录

您可以使用 External DNS Operator 在 Infoblox 上创建 DNS 记录。

您可以使用 External DNS Operator 在 Infoblox 上的公共 DNS 区域上创建 DNS 记录。

先决条件

  • 您可以访问 OpenShift CLI(oc)。
  • 您可以访问 Infoblox UI。

流程

  1. 运行以下命令,使用 Infoblox 凭证创建 secret 对象:

    $ oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令来获取路由列表:

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    输出示例

    openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  3. 创建一个 YAML 文件,如 external-dns-sample-infoblox.yaml,该文件定义 ExternalDNS 对象:

    external-dns-sample-infoblox.yaml 文件示例

    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-infoblox 
    1
    
    spec:
      provider:
        type: Infoblox 
    2
    
        infoblox:
          credentials:
            name: infoblox-credentials
          gridHost: ${INFOBLOX_GRID_PUBLIC_IP}
          wapiPort: 443
          wapiVersion: "2.3.1"
      domains:
      - filterType: Include
        matchType: Exact
        name: test.example.com
      source:
        type: OpenShiftRoute 
    3
    
        openshiftRouteOptions:
          routerName: default 
    4
    Copy to Clipboard Toggle word wrap

    1
    指定外部 DNS 名称。
    2
    定义提供程序类型。
    3
    您可以定义 DNS 记录源的选项。
    4
    如果源类型是 OpenShiftRoute,您可以传递 OpenShift Ingress Controller 名称。外部 DNS 在创建 CNAME 记录时,选择该路由器的规范主机名作为目标。
  4. 运行以下命令,在 Infoblox 上创建 ExternalDNS 资源:

    $ oc create -f external-dns-sample-infoblox.yaml
    Copy to Clipboard Toggle word wrap
  5. 通过 Infoblox UI,检查为 console 路由创建的 DNS 记录:

    1. Data ManagementDNSZones
    2. 选择区域名称。

4.9. 在外部 DNS Operator 上配置集群范围代理

配置集群范围代理后,Operator Lifecycle Manager (OLM) 会触发对使用 HTTP_PROXYHTTPS_PROXYNO_PROXY 环境变量的新内容的所有部署的 Operator 的自动更新。

4.9.1. 信任集群范围代理的证书颁发机构

您可以将外部 DNS Operator 配置为信任集群范围代理的证书颁发机构。

流程

  1. 运行以下命令,创建配置映射以在 external-dns-operator 命名空间中包含 CA 捆绑包:

    $ oc -n external-dns-operator create configmap trusted-ca
    Copy to Clipboard Toggle word wrap
  2. 要将可信 CA 捆绑包注入配置映射中,请运行以下命令将 config.openshift.io/inject-trusted-cabundle=true 标签添加到配置映射中:

    $ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令更新外部 DNS Operator 的订阅:

    $ oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'
    Copy to Clipboard Toggle word wrap

验证

  • 部署外部 DNS Operator 后,通过运行以下命令验证是否将可信 CA 环境变量作为 trusted-ca 添加至 external-dns-operator 部署中:

    $ oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
    Copy to Clipboard Toggle word wrap

第 5 章 MetalLB Operator

5.1. 关于 MetalLB 和 MetalLB Operator

作为集群管理员,您可以将 MetalLB Operator 添加到集群中,以便在将 LoadBalancer 类型服务添加到集群中时,MetalLB 可为该服务添加外部 IP 地址。外部 IP 地址添加到集群的主机网络中。

5.1.1. 何时使用 MetalLB

当您有裸机集群或类似裸机的基础架构时,使用 MetalLB 有价值,并且您希望通过外部 IP 地址对应用程序进行容错访问。

您必须配置网络基础架构,以确保外部 IP 地址的网络流量从客户端路由到集群的主机网络。

使用 MetalLB Operator 部署 MetalLB 后,当添加类型为 LoadBalancer 的服务时,MetalLB 提供了一个平台原生负载均衡器。

当外部流量通过 MetalLB LoadBalancer 服务进入 OpenShift Container Platform 集群时,返回到客户端的流量具有负载均衡器的外部 IP 地址作为源 IP。

在 layer2 模式中的 MetalLB 操作通过使用与 IP 故障转移类似的机制提供对故障切换的支持。但是,MetalLB 利用基于 gosip 的协议来识别节点故障实例,而不依赖于虚拟路由器冗余协议 (VRRP) 和 keepalived。当检测到故障转移时,另一个节点会假定领导节点的角色,并且分配了一个 gratuitous ARP 消息来广播此更改。

MetalLB 在 layer3 或边框网关协议 (BGP) 模式下操作,将故障检测委派给网络。OpenShift Container Platform 节点建立连接的 BGP 路由器或路由器将识别任何节点故障并终止到该节点的路由。

最好使用 MetalLB 而不是 IP 故障转移来确保 pod 和服务的高可用性。

5.1.2. MetalLB Operator 自定义资源

MetalLB Operator 为以下自定义资源监控自己的命名空间:

MetalLB
当您在集群中添加 MetalLB 自定义资源时,MetalLB Operator 会在集群中部署 MetalLB。Operator 只支持单个自定义资源实例。如果删除了实例,Operator 会从集群中删除 MetalLB。
IPAddressPool

MetalLB 需要一个或多个 IP 地址池,您可以在添加类型为 LoadBalancer 的服务时分配给服务。一个 IPAddressPool,包含 IP 地址列表。列表可以是使用范围设置的单个 IP 地址,如 1.1.1.1-1.1.1.1、以 CIDR 表示法指定的范围、指定为起始和结束地址的范围,或者以连字符分隔的、两者的组合。IPAddressPool 需要一个名称。文档使用 doc-exampledoc-example-reserveddoc-example-ipv6 等名称。MetalLB 控制器IPAddressPool 中的地址池中分配 IP 地址。L2AdvertisementBGPAdvertisement 自定义资源启用从一个指定池中广告一个给定 IP。您可以使用 IPAddressPool 自定义资源中的 spec.serviceAllocation 规格将 IP 地址从 IPAddressPool 分配给服务和命名空间。

注意

单个 IPAddressPool 可以被 L2 公告和 BGP 公告来引用。

BGPPeer
BGP peer 自定义资源标识 MetalLB 进行通信的 BGP 路由器、路由器的 AS 数量、MetalLB 的 AS 编号,以及路由公告的自定义。MetalLB 将服务负载平衡器 IP 地址的路由公告给一个或多个 BGP 对等点。
BFDProfile
BFD 配置集自定义资源可为 BGP peer 配置双向转发检测(BFD)。BFD 提供比 BGP 单独提供的路径故障检测速度。
L2Advertisement
L2Advertisement 自定义资源使用 L2 协议广告一个来自 IPAddressPool 的 IP。
BGPAdvertisement
BGPAdvertisement 自定义资源使用 BGP 协议广告一个来自 IPAddressPool 的 IP。

在将 MetalLB 自定义资源添加到集群,且 Operator 部署了 MetalLB 后,controllerspeaker MetalLB 软件组件将开始运行。

MetalLB 验证所有相关自定义资源。

5.1.3. MetalLB 软件组件

安装 MetalLB Operator 时,metallb-operator-controller-manager 部署会启动一个 pod。pod 是 Operator 的实施。pod 监控所有相关资源的更改。

当 Operator 启动 MetalLB 实例时,它会启动一个 controller 部署和一个 speaker 守护进程集。

注意

您可以在 MetalLB 自定义资源中配置部署规格,以管理 controllerspeaker pod 如何在集群中部署和运行。有关这些部署规格的更多信息,请参阅附加资源部分

controller

Operator 会启动部署和单个 pod。当您添加类型为 LoadBalancer 的服务时,Kubernetes 使用 controller 从地址池中分配 IP 地址。如果服务失败,请验证 controller pod 日志中有以下条目:

输出示例

"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller
Copy to Clipboard Toggle word wrap

speaker

Operator 为 speaker pod 启动守护进程集。默认情况下,在集群的每个节点上启动 pod。您可以在启动 MetalLB 时在 MetalLB 自定义资源中指定节点选择器,将 pod 限制到特定的节点。如果 controller 为服务分配了 IP 地址,并且服务仍不可用,请阅读 speaker pod 日志。如果 speaker pod 不可用,请运行 oc describe pod -n 命令。

对于第 2 层模式,控制器 为服务分配 IP 地址后,speaker pod 使用一种算法来确定哪些 speaker pod 将宣布负载均衡器 IP 地址。该算法涉及对节点名称和负载均衡器 IP 地址进行哈希处理。如需更多信息,请参阅"MetalLB 和外部流量策略"。speaker 使用地址解析协议 (ARP) 来宣布 IPv4 地址和邻居发现协议 (NDP) 来宣布 IPv6 地址。

对于 Border Gateway Protocol (BGP) 模式,controller 为服务分配 IP 地址后,每个 speaker pod 为其 BGP 对等点公告负载均衡器 IP 地址。您可以配置节点在 BGP 对等点上启动 BGP 会话。

对负载均衡器 IP 地址的请求会路由到具有声明 IP 地址的 speaker 的节点。节点接收数据包后,服务代理会将数据包路由到该服务的端点。在最佳情况下,端点可以位于同一节点上,也可以位于另一节点上。每次建立连接时,服务代理都会选择一个端点。

5.1.4. MetalLB 和外部流量策略

使用第 2 层模式时,集群中的一个节点会接收服务 IP 地址的所有流量。使用 BGP 模式时,主机网络上的路由器会打开与集群中其中一个节点的连接,用于新客户端连接。集群在进入节点后如何处理流量受外部流量策略的影响。

cluster

这是 spec.externalTrafficPolicy 的默认值。

使用 cluster 流量策略时,节点接收流量后,服务代理会将流量分发到服务中的所有容器集。此策略在 pod 之间提供统一流量分布,但它会模糊客户端 IP 地址,并可能会在 pod 中显示流量源自节点而不是客户端的应用。

local

采用 local 流量策略时,节点接收流量后,服务代理仅将流量发送到同一节点上的 pod。例如,如果节点上的 speaker pod 宣布外部服务 IP,则所有流量都发送到节点 A。流量进入节点 A 后,服务代理仅将流量发送到节点 A 上的服务的 pod。位于其他节点上的服务的 Pod 不会从节点 A 接收任何流量。在需要故障转移时,其他节点上的服务的 Pod 充当副本。

此策略不会影响客户端 IP 地址。应用容器集可以确定来自传入连接的客户端 IP 地址。

注意

在 BGP 模式中配置外部流量策略时,以下信息非常重要。

虽然 MetalLB 公告来自所有有资格的节点的负载均衡器 IP 地址,但可能会限制在路由器的容量下,以建立同等成本多路径(ECMP)路由。如果广告 IP 的节点数量大于路由器的 ECMP 组的限制,路由器将使用比广告 IP 的节点数量少的节点。

例如,如果外部流量策略设置为 local,且路由器将 ECMP 组限制设置为 16,实施 LoadBalancer 服务的 pod 部署在 30 个节点上,这会导致在 14 个节点上部署的 pod 不接收任何流量。在这种情况下,最好将该服务的外部流量策略设置为 cluster

5.1.5. 第 2 层模式的 MetalLB 概念

在第 2 层模式中,一个节点上的 speaker pod 向主机网络宣布服务的外部 IP 地址。从网络的角度来看,节点似乎有多个 IP 地址分配给网络接口。

注意

在第 2 层模式中,MetalLB 依赖于 ARP 和 NDP。这些协议在特定子网中实施本地地址解析。在这种情况下,客户端必须能够访问由 MetalLB 分配的 VIP,它与节点位于同一个子网中,以便 MetalLB 正常工作。

speaker pod 响应 IPv4 服务和 IPv6 的 NDP 请求。

在第 2 层模式中,服务 IP 地址的所有流量都通过一个节点进行路由。在流量进入节点后,CNI 网络供应商的服务代理会将流量分发到该服务的所有 pod。

由于服务的所有流量都通过第 2 层模式中的单一节点进入,所以严格意义上,MetalLB 不会为第 2 层实施负载平衡器。相反,MetalLB 为第 2 层实施故障转移机制,以便在 speaker pod 不可用时,不同节点上的 speaker pod 可以宣布服务 IP 地址。

当节点不可用时,自动故障转移。其他节点上的 speaker pod 检测到节点不可用,新的 speaker pod 和节点从故障节点上拥有服务 IP 地址的所有权。

上图显示了与 MetalLB 相关的以下概念:

  • 应用程序可以通过在 172.130.0.0/16 子网上具有集群 IP 的服务获取。该 IP 地址可以从集群内部访问。服务也有一个外部 IP 地址,用于分配给服务的 MetalLB,即 192.168.100.200
  • 节点 1 和 3 具有应用程序的 pod。
  • speaker 守护进程集在每个节点上运行一个 pod。MetalLB Operator 启动这些 pod。
  • 每个 speaker pod 都是主机网络的 pod。容器集的 IP 地址与主机网络上节点的 IP 地址相同。
  • 节点 1 上的 speaker pod 使用 ARP 声明服务的外部 IP 地址 192.168.100.200。声明外部 IP 地址的 speaker pod 必须与服务的端点位于同一个节点上,端点必须为 Ready 条件。
  • 客户端流量路由到主机网络,并连接到 192.168.100.200 IP 地址。在流量进入节点后,服务代理会根据您为服务设置的外部流量策略,将流量发送到同一节点上的应用 pod 或其他节点。

    • 如果服务的外部流量策略设置为 cluster,则会从运行 speaker pod 的节点选择广告 192.168.100.200 负载均衡器 IP 地址的节点。只有该节点才能接收该服务的流量。
    • 如果服务的外部流量策略设置为 local,则会从运行 speaker pod 的节点以及至少一个服务的端点选择广告 192.168.100.200 负载均衡器 IP 地址的节点。只有该节点才能接收该服务的流量。在上图中,节点 1 或 3 将广告 192.168.100.200
  • 如果节点 1 不可用,则外部 IP 地址将故障转移到另一节点。在具有应用 pod 和服务端点实例的另一个节点上,speaker Pod 开始宣布外部 IP 地址 192.168.100.200,新节点接收客户端流量。在图中,唯一的候选项是节点 3。

5.1.6. BGP 模式的 MetalLB 概念

在 BGP 模式中,默认情况下每个 speaker pod 都会向每个 BGP 对等广告一个服务的负载均衡器 IP 地址。也可以通过添加可选 BGP 对等列表来广告来自给定池的 IP 地址到特定的对等池。BGP 对等点是配置为使用 BGP 协议的网络路由器。当路由器收到负载均衡器 IP 地址的流量时,路由器会选择一个带有公告 IP 地址的 speaker pod 的节点。路由器将流量发送到该节点。在流量进入节点后,CNI 网络插件的服务代理会将流量分发到该服务的所有 pod。

与集群节点相同的第 2 层网络段中直接连接的路由器可以配置为 BGP 对等点。如果直接连接的路由器没有配置为 BGP peer,您需要配置网络,以便负载均衡器 IP 地址的数据包在 BGP 对等机和运行 speaker Pod 的集群节点之间路由。

每次路由器接收负载均衡器 IP 地址的新流量时,它会创建一个新的与节点的连接。每个路由器制造商都有一个特定于实施的算法,用于选择要启动连接的节点。但是,算法通常设计为在可用节点之间分发流量,以平衡网络负载。

如果节点不可用,路由器会与具有 speaker pod 的另一个节点发起一个新的连接,以公告负载均衡器 IP 地址。

图 5.1. BGP 模式的 MetalLB 拓扑图

上图显示了与 MetalLB 相关的以下概念:

  • 应用通过 172.130.0.0/16 子网上具有 IPv4 集群 IP 的服务进行访问。该 IP 地址可以从集群内部访问。该服务也有一个外部 IP 地址,MetalLB 分配到该服务 203.0.113.200
  • 节点 2 和 3 具有该应用的 pod。
  • speaker 守护进程集在每个节点上运行一个 pod。MetalLB Operator 启动这些 pod。您可以配置 MetalLB 来指定运行 speaker pod 的节点。
  • 每个 speaker pod 都是主机网络的 pod。容器集的 IP 地址与主机网络上节点的 IP 地址相同。
  • 每个 speaker pod 启动一个 BGP 会话,其中包含所有 BGP 对等点,并将负载均衡器 IP 地址或聚合路由公告给 BGP 对等点。speaker pod 公告它们是 Autonomous System 65010 的一部分。图显示路由器 R1 作为同一自主系统内的 BGP peer。但是,您可以将 MetalLB 配置为与属于其他自主系统的同行启动 BGP 会话。
  • 具有 speaker pod 的所有节点(公告负载均衡器 IP 地址)都可以接收该服务的流量。

    • 如果服务的外部流量策略设置为 cluster,则运行 speaker pod 的所有节点都会广告 203.0.113.200 负载平衡器 IP 地址,具有 speaker pod 的所有节点都可以接收该服务的流量。只有外部流量策略设为 cluster 时,主机前缀才会广告给路由器对等点。
    • 如果服务的外部流量策略设置为 local,则运行 speaker Pod 的所有节点都会运行,并且至少有一个运行的服务端点可能会广告 203.0.113.200 负载均衡器 IP 地址。只有这些节点才能接收该服务的流量。在上图中,节点 2 和 3 将公告 203.0.113.200
  • 您可以在添加 BGP peer 自定义资源时指定节点选择器,将 MetalLB 配置为通过指定带有特定 BGP peer 的节点选择器来控制哪些 speaker pod 启动 BGP 对等点。
  • 任何配置为使用 BGP 的路由器(如 R1)都可以设置为 BGP 同级服务器。
  • 客户端流量路由到主机网络上的其中一个节点。在流量进入节点后,服务代理会根据您为服务设置的外部流量策略,将流量发送到同一节点上的应用 pod 或其他节点。
  • 如果节点不可用,路由器检测到失败,并启动与另一节点的新连接。您可以将 MetalLB 配置为将双向转发检测(BFD)配置集用于 BGP 对等点。BFD 提供更快的链路失败检测,以便路由器可以比没有 BFD 的情况下启动新连接。

5.1.7. 限制和限制

5.1.7.1. MetalLB 的基础架构注意事项

MetalLB 主要用于内部的裸机安装,因为这些安装不包含原生负载平衡器功能。除了裸机安装外,在有些基础架构上安装 OpenShift Container Platform 可能不包括原生负载均衡器功能。例如,以下基础架构可从添加 MetalLB Operator 中受益:

  • 裸机
  • VMware vSphere
  • IBM Z® 和 IBM® LinuxONE
  • IBM Z® and IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
  • IBM Power®
5.1.7.2. 第 2 层模式的限制
5.1.7.2.1. 单节点瓶颈

MetalLB 通过单一节点路由服务的所有流量,该节点可能会成为瓶颈并限制性能。

第 2 层模式将服务的入口带宽限制为单个节点的带宽。这是使用 ARP 和 NDP 定向流量的一个根本限制。

5.1.7.2.2. 延迟故障转移性能

节点之间的故障转移取决于客户端的合作。发生故障转移时,MetalLB 发送粒度 ARP 数据包来通知客户端与服务 IP 关联的 MAC 地址已更改。

大多数客户端操作系统正确处理细粒度 ARP 数据包,并及时更新其邻居缓存。当客户端快速更新其缓存时,故障转移将在几秒钟内完成。客户端通常在 10 秒内故障转移到新节点。但是,一些客户端操作系统或者根本不处理饱和的 ARP 数据包,或者存在延迟缓存更新的过时实施。

Windows、macOS 和 Linux 等常见操作系统的最新版本正确实现了第 2 层故障转移。除了较旧和不太常见的客户端操作系统外,预计不会出现故障转移较慢的问题。

为最大程度减轻计划内故障转移对过时客户端的影响,在颠倒领导地位后让旧节点保持运行几分钟。旧节点可以继续转发过期客户端的流量,直到其缓存刷新。

在计划外故障转移期间,服务 IP 无法访问,直到过期的客户端刷新其缓存条目为止。

将相同的 VLAN 用于 MetalLB 和源 pod 上设置的额外网络接口可能会导致连接失败。当 MetalLB IP 和源 pod 驻留在同一节点上时,会出现这种情况。

为了避免连接失败,请将 MetalLB IP 放在源 pod 所在的不同子网中。此配置可确保来自源 pod 的流量将采用默认网关。因此,流量可以使用 OVN 覆盖网络有效地到达其目的地,确保连接功能如预期一样。

5.1.7.3. BGP 模式限制
5.1.7.3.1. 节点故障可能会破坏所有活跃的连接

MetalLB 共享一个限制,这是基于 BGP 的负载平衡。当 BGP 会话终止时,如节点失败或者 speaker pod 重启时,会话终止可能会导致重置所有活跃的连接。最终用户可以 通过 peer 消息完成连接重置

所终止的 BGP 会话的结果是特定于路由器制造商的实现。但是,您可以预测 speaker pod 数量的变化会影响 BGP 会话的数量,并且与 BGP 对等点的活动连接将中断。

为了避免或降低服务中断的可能性,您可以在添加 BGP 对等点时指定节点选择器。通过限制启动 BGP 会话的节点数量,没有 BGP 会话的节点出现错误不会影响到该服务的连接。

5.1.7.3.2. 只支持单个 ASN 和单个路由器 ID

当您添加 BGP peer 自定义资源时,您可以指定 spec.myASN 字段来识别 MetalLB 所属的 Autonomous System Number(ASN)。OpenShift Container Platform 使用带有 MetalLB 的 BGP 实施,它要求 MetalLB 属于单个 ASN。如果您试图添加 BGP peer 并为 spec.myASN 指定与现有的 BGP peer 自定义资源不同的值,您会收到一个错误。

同样,当您添加 BGP peer 自定义资源时,spec.routerID 字段是可选的。如果为此字段指定一个值,您必须为要添加的所有其他 BGP peer 自定义资源指定相同的值。

支持单个 ASN 和单个路由器 ID 的限制与支持的 MetalLB 实施不同。

5.2. 安装 MetalLB Operator

作为集群管理员,您可以添加 MetalLB Operator,以便 Operator 可以管理集群中的 MetalLB 实例的生命周期。

MetalLB 和 IP 故障转移不兼容。如果您为集群配置了 IP 故障转移,请在安装 Operator 前执行删除 IP 故障切换 的步骤。

作为集群管理员,您可以使用 OpenShift Container Platform Web 控制台安装 MetalLB Operator。

先决条件

  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在 OpenShift Container Platform Web 控制台中导航至 OperatorsOperatorHub
  2. Filter by keyword 框中输入关键字,或滚动以查找您想要的 Operator。例如,键入 metallb 来查找 MetalLB Operator。

    您还可以根据基础架构功能过滤选项。例如,如果您希望 Operator 在断开连接的环境中工作,请选择 Disconnected

  3. Install Operator 页面中,接受默认值并点 Install

验证

  1. 确认安装成功:

    1. 导航到 OperatorsInstalled Operators 页面。
    2. 检查 Operator 是否安装在 openshift-operators 命名空间中,其状态是否为 Succeeded
  2. 如果 Operator 没有成功安装,请检查 Operator 的状态并查看日志:

    1. 导航到 OperatorsInstalled Operators 页面,并检查 Status 列中是否有任何错误或故障。
    2. 导航到 WorkloadsPods 页面,并检查 openshift-operators 项目中报告问题的 pod 的日志。

5.2.2. 使用 CLI 从 OperatorHub 安装

您可以使用 CLI 从 OperatorHub 安装 Operator,而不必使用 OpenShift Container Platform Web 控制台。您可以使用 OpenShift CLI(oc)安装 MetalLB Operator。

建议您在使用 metallb-system 命名空间中安装 Operator 的 CLI 时使用。

先决条件

  • 在裸机硬件上安装的集群。
  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 输入以下命令为 MetalLB Operator 创建命名空间:

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: metallb-system
    EOF
    Copy to Clipboard Toggle word wrap
  2. 在命名空间中创建 Operator 组自定义资源(CR):

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: metallb-operator
      namespace: metallb-system
    EOF
    Copy to Clipboard Toggle word wrap
  3. 确认 Operator 组已安装在命名空间中:

    $ oc get operatorgroup -n metallb-system
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME               AGE
    metallb-operator   14m
    Copy to Clipboard Toggle word wrap

  4. 创建一个 Subscription CR:

    1. 定义 Subscription CR 并保存 YAML 文件,如 metallb-sub.yaml

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator-sub
        namespace: metallb-system
      spec:
        channel: stable
        name: metallb-operator
        source: redhat-operators 
      1
      
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap
      1
      您必须指定 redhat-operators 值。
    2. 要创建 Subscription CR,请运行以下命令:

      $ oc create -f metallb-sub.yaml
      Copy to Clipboard Toggle word wrap
  5. 可选: 要确保 BGP 和 BFD 指标出现在 Prometheus 中,您可以使用以下命令标记命名空间:

    $ oc label ns metallb-system "openshift.io/cluster-monitoring=true"
    Copy to Clipboard Toggle word wrap

验证

验证步骤假定 metallb-system 命名空间中安装了 MetalLB Operator。

  1. 确认安装计划位于命名空间中:

    $ oc get installplan -n metallb-system
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME            CSV                                   APPROVAL    APPROVED
    install-wzg94   metallb-operator.4.17.0-nnnnnnnnnnnn   Automatic   true
    Copy to Clipboard Toggle word wrap

    注意

    安装 Operator 可能需要几秒钟。

  2. 要验证是否已安装 Operator,请输入以下命令,然后检查 Operator 的输出显示 Succeeded

    $ oc get clusterserviceversion -n metallb-system \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap

5.2.3. 在集群中启动 MetalLB

安装 Operator 后,您需要配置 MetalLB 自定义资源的单一实例。配置自定义资源后,Operator 会在集群中启动 MetalLB。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 安装 MetalLB Operator。

流程

此流程假设 MetalLB Operator 已安装在 metallb-system 命名空间中。如果使用 Web 控制台安装,请替换命名空间的 openshift-operators

  1. 创建 MetalLB 自定义资源的单一实例:

    $ cat << EOF | oc apply -f -
    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    EOF
    Copy to Clipboard Toggle word wrap

验证

确认 MetalLB 控制器的部署和 MetalLB speaker 的守护进程集正在运行。

  1. 验证控制器的部署是否正在运行:

    $ oc get deployment -n metallb-system controller
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
    controller   1/1     1            1           11m
    Copy to Clipboard Toggle word wrap

  2. 验证发言人的守护进程集是否正在运行:

    $ oc get daemonset -n metallb-system speaker
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
    speaker   6         6         6       6            6           kubernetes.io/os=linux   18m
    Copy to Clipboard Toggle word wrap

    示例输出显示 6 个 speaker Pod。集群中的 speaker pod 数量可能与示例输出不同。确保输出指示集群中每个节点有一个容器集。

5.2.4. MetalLB 的部署规格

当使用 MetalLB 自定义资源启动 MetalLB 实例时,您可以在 MetalLB 自定义资源中配置部署规格,以管理 controllerspeaker pod 如何在集群中部署并运行。使用这些部署规格来管理以下任务:

  • 为 MetalLB pod 部署选择节点。
  • 使用 pod 优先级和 pod 关联性来管理调度。
  • 为 MetalLB pod 分配 CPU 限值。
  • 为 MetalLB pod 分配容器 RuntimeClass。
  • 为 MetalLB pod 分配元数据。
5.2.4.1. 将 speaker pod 限制到特定的节点

默认情况下,当使用 MetalLB Operator 启动 MetalLB 时,Operator 会在集群中的每个节点上启动 speaker pod 的实例。只有具有 speaker pod 的节点可以公告负载均衡器 IP 地址。您可以使用节点选择器配置 MetalLB 自定义资源,以指定运行 speaker pod 的节点。

speaker Pod 限制到特定的节点的最常见原因是,确保只有具有特定网络上网络接口的节点公告负载均衡器 IP 地址。只有具有正在运行的 speaker pod 的节点才会公告为负载均衡器 IP 地址的目的地。

如果将 speaker 的 pod 限制到特定的节点,并为服务的外部流量策略指定 local,则必须确保该服务的应用程序 pod 部署到同一节点上。

将 speaker pod 限制为 worker 节点的配置示例

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:  
1

    node-role.kubernetes.io/worker: ""
  speakerTolerations:   
2

  - key: "Example"
    operator: "Exists"
    effect: "NoExecute"
Copy to Clipboard Toggle word wrap

1
示例配置指定将 speaker pod 分配给 worker 节点,但您可以指定分配给节点或任何有效的节点选择器的标签。
2
在本示例配置中,附加此容限的 pod 可以容忍与 key 值和 effect 值匹配的任何污点,并使用 operator 容许值。

使用 spec.nodeSelector 字段应用清单后,您可以检查 Operator 使用 oc get daemonset -n metallb-system speaker 命令部署的 pod 数量。同样,您可以使用 oc get nodes -l node-role.kubernetes.io/worker= 等命令显示与标签匹配的节点。

您可以选择允许节点使用关联性规则控制哪些 speaker pod 应该或不应该调度到节点上。您还可以通过应用容限列表来限制这些 pod。如需有关关联性规则、污点和容限的更多信息,请参阅其他资源。

您可以通过配置 MetalLB 自定义资源,选择将 pod 优先级和 pod 关联性规则分配给 controllerspeaker pod。pod 优先级指示节点上 pod 的相对重要性,并根据这个优先级调度 pod。在 controllerspeaker pod 上设置高优先级,以确保在节点上的其他 pod 上调度优先级。

Pod 关联性管理 pod 间的关系。将 pod 关联性分配给 controllerspeaker pod,以控制调度程序将 pod 放置到 pod 关系的节点上。例如,您可以使用 pod 关联性规则来确保某些 pod 位于同一节点或节点上,这有助于提高网络通信并减少这些组件之间的延迟。

先决条件

  • 您以具有 cluster-admin 权限的用户身份登录。
  • 已安装 MetalLB Operator。
  • 已在集群中启动 MetalLB Operator。

流程

  1. 创建 PriorityClass 自定义资源,如 myPriorityClass.yaml,以配置优先级级别。这个示例定义了名为 high-priorityPriorityClass,值设为 1000000。与具有较低优先级类的 pod 相比,在调度过程中分配此优先级类的 Pod 被视为优先级更高:

    apiVersion: scheduling.k8s.io/v1
    kind: PriorityClass
    metadata:
      name: high-priority
    value: 1000000
    Copy to Clipboard Toggle word wrap
  2. 应用 PriorityClass 自定义资源配置:

    $ oc apply -f myPriorityClass.yaml
    Copy to Clipboard Toggle word wrap
  3. 创建 MetalLB 自定义资源,如 MetalLBPodConfig.yaml,以指定 priorityClassNamepodAffinity 值:

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      controllerConfig:
        priorityClassName: high-priority 
    1
    
        affinity:
          podAffinity: 
    2
    
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                 app: metallb
              topologyKey: kubernetes.io/hostname
      speakerConfig:
        priorityClassName: high-priority
        affinity:
          podAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                 app: metallb
              topologyKey: kubernetes.io/hostname
    Copy to Clipboard Toggle word wrap
    1
    指定 MetalLB 控制器 pod 的优先级类。在这种情况下,它被设置为 high-priority
    2
    指定您要配置 pod 关联性规则。这些规则指定如何调度 pod 与其他 pod 或节点。此配置指示调度程序将具有标签 app: metallb 的 pod 调度到共享同一主机名的节点。这有助于在同一节点上并置与 MetalLB 相关的 pod,可能会优化这些 pod 之间的网络通信、延迟和资源使用情况。
  4. 应用 MetalLB 自定义资源配置:

    $ oc apply -f MetalLBPodConfig.yaml
    Copy to Clipboard Toggle word wrap

验证

  • 要在 metallb-system 命名空间中查看分配给 pod 的优先级类,请运行以下命令:

    $ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                                 PRIORITY
    controller-584f5c8cd8-5zbvg                          high-priority
    metallb-operator-controller-manager-9c8d9985-szkqg   <none>
    metallb-operator-webhook-server-c895594d4-shjgx      <none>
    speaker-dddf7                                        high-priority
    Copy to Clipboard Toggle word wrap

  • 要验证调度程序是否根据 pod 关联性规则放置 pod,请运行以下命令来查看 pod 的节点或节点的元数据:

    $ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
    Copy to Clipboard Toggle word wrap
5.2.4.3. 在 MetalLB 部署中配置 pod CPU 限制

您可以通过配置 MetalLB 自定义资源(可选)将 pod CPU 限值分配给 controllerspeaker pod。为 controllerspeaker pod 定义 CPU 限制可帮助您管理节点上的计算资源。这样可确保节点上的所有 pod 具有必要的计算资源来管理工作负载和集群内务。

先决条件

  • 您以具有 cluster-admin 权限的用户身份登录。
  • 已安装 MetalLB Operator。

流程

  1. 创建 MetalLB 自定义资源文件,如 CPULimits.yaml,以指定 controllerspeaker pod 的 cpu 值:

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      controllerConfig:
        resources:
          limits:
            cpu: "200m"
      speakerConfig:
        resources:
          limits:
            cpu: "300m"
    Copy to Clipboard Toggle word wrap
  2. 应用 MetalLB 自定义资源配置:

    $ oc apply -f CPULimits.yaml
    Copy to Clipboard Toggle word wrap

验证

  • 要查看 pod 的计算资源,请运行以下命令,将 <pod_name> 替换为您的目标 pod:

    $ oc describe pod <pod_name>
    Copy to Clipboard Toggle word wrap

5.2.6. 后续步骤

5.3. 升级 MetalLB Operator

默认情况下,将命名空间订阅到 metallb-systemSubscription 自定义资源 (CR) 会自动将 installPlanApproval 参数设置为 Automatic。这意味着,当红帽提供的 Operator 目录包含 MetalLB Operator 的较新版本时,MetalLB Operator 会自动升级。

如果需要手动控制 MetalLB Operator 升级,请将 installPlanApproval 参数设置为 Manual

5.3.1. 手动升级 MetalLB Operator

要手动控制升级 MetalLB Operator,您必须编辑将命名空间订阅到 metallb-systemSubscription 自定义资源(CR)。Subscription CR 作为 Operator 安装的一部分创建,且 CR 默认将 installPlanApproval 参数设置为 Automatic

先决条件

  • 将集群更新至最新的 z-stream 版本。
  • 使用 OperatorHub 安装 MetalLB Operator。
  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 输入以下命令在 metallb-system 命名空间中获取 metallb-operator 订阅的 YAML 定义:

    $ oc -n metallb-system get subscription metallb-operator -o yaml
    Copy to Clipboard Toggle word wrap
  2. 通过将 installPlanApproval 参数设置为 Manual 来编辑 Subscription CR:

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: metallb-operator
      namespace: metallb-system
    # ...
    spec:
       channel: stable
       installPlanApproval: Manual
       name: metallb-operator
       source: redhat-operators
       sourceNamespace: openshift-marketplace
    # ...
    Copy to Clipboard Toggle word wrap
  3. 输入以下命令查找 MetalLB Operator 的最新 OpenShift Container Platform 4.17 版本:

    $ oc -n metallb-system get csv
    Copy to Clipboard Toggle word wrap
  4. 输入以下命令检查命名空间中存在的安装计划。

    $ oc -n metallb-system get installplan
    Copy to Clipboard Toggle word wrap

    将 install-tsz2g 显示为手动安装计划的输出示例

    NAME            CSV                                     APPROVAL    APPROVED
    install-shpmd   metallb-operator.v4.17.0-202502261233   Automatic   true
    install-tsz2g   metallb-operator.v4.17.0-202503102139   Manual      false
    Copy to Clipboard Toggle word wrap

  5. 输入以下命令来编辑命名空间中存在的安装计划。确保将 <name_of_installplan> 替换为安装计划的名称,如 install-tsz2g

    $ oc edit installplan <name_of_installplan> -n metallb-system
    Copy to Clipboard Toggle word wrap
    1. 在编辑器中打开安装计划后,将 spec.approval 参数设置为 Manual,并将 spec.approved 参数设置为 true

      注意

      编辑安装计划后,升级操作会启动。如果在升级操作过程中输入 oc -n metallb-system get csv 命令,则输出可能会显示 ReplacingPending 状态。

验证

  • 要验证 Operator 是否已升级,请输入以下命令,然后检查 Operator 的输出显示 Succeeded

    $ oc -n metallb-system get csv
    Copy to Clipboard Toggle word wrap

5.3.2. 其他资源

Cluster Network Operator (CNO)在 OpenShift Container Platform 集群上部署和管理集群网络组件,包括在安装过程中为集群选择的 Container Network Interface (CNI) 网络插件。

6.1. Cluster Network Operator

Cluster Network Operator 从 operator.openshift.io API 组实现 network API。Operator 通过使用守护进程集部署 OVN-Kubernetes 网络插件,或部署您在集群安装过程中选择的网络供应商插件。

流程

Cluster Network Operator 在安装过程中被部署为一个 Kubernetes 部署

  1. 运行以下命令,以查看部署状态:

    $ oc get -n openshift-network-operator deployment/network-operator
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    network-operator   1/1     1            1           56m
    Copy to Clipboard Toggle word wrap

  2. 运行以下命令,以查看 Cluster Network Operator 的状态:

    $ oc get clusteroperator/network
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.16.1     True        False         False      50m
    Copy to Clipboard Toggle word wrap

    以下字段提供有关 Operator 状态的信息:AVAILABLEProgressingDEGRADED。当 Cluster Network Operator 报告可用状态条件时,AVAILABLE 字段为 True

6.2. 查看集群网络配置

每个 OpenShift Container Platform 新安装都有一个名为 clusternetwork.config 对象。

流程

  • 使用 oc describe 命令查看集群网络配置:

    $ oc describe network.config/cluster
    Copy to Clipboard Toggle word wrap

    输出示例

    Name:         cluster
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  config.openshift.io/v1
    Kind:         Network
    Metadata:
      Creation Timestamp:  2024-08-08T11:25:56Z
      Generation:          3
      Resource Version:    29821
      UID:                 808dd2be-5077-4ff7-b6bb-21b7110126c7
    Spec: 
    1
    
      Cluster Network:
        Cidr:         10.128.0.0/14
        Host Prefix:  23
      External IP:
        Policy:
      Network Diagnostics:
        Mode:
        Source Placement:
        Target Placement:
      Network Type:  OVNKubernetes
      Service Network:
        172.30.0.0/16
    Status: 
    2
    
      Cluster Network:
        Cidr:               10.128.0.0/14
        Host Prefix:        23
      Cluster Network MTU:  1360
      Conditions:
        Last Transition Time:  2024-08-08T11:51:50Z
        Message:
        Observed Generation:   0
        Reason:                AsExpected
        Status:                True
        Type:                  NetworkDiagnosticsAvailable
      Network Type:            OVNKubernetes
      Service Network:
        172.30.0.0/16
    Events:  <none>
    Copy to Clipboard Toggle word wrap

    1
    Spec 字段显示集群网络的已配置状态。
    2
    Status 字段显示集群网络配置的当前状态。

6.3. 查看 Cluster Network Operator 状态

您可以使用 oc describe 命令来检查状态并查看 Cluster Network Operator 的详情。

流程

  • 运行以下命令,以查看 Cluster Network Operator 的状态:

    $ oc describe clusteroperators/network
    Copy to Clipboard Toggle word wrap

6.4. 全局启用 IP 转发

从 OpenShift Container Platform 4.14 开始,基于 OVN-Kubernetes 的集群部署禁用了全局 IP 地址转发,以防止集群管理员对作为路由器的节点造成不必要的影响。但是,在某些情况下,管理员希望转发一个新的配置参数 ipForwarding 来允许转发所有 IP 流量。

要为 OVN-Kubernetes 受管接口上的所有流量重新启用 IP 转发,请按照以下流程将 Cluster Network Operator 中的 gatewayConfig.ipForwarding 规格设置为 Global

流程

  1. 运行以下命令备份现有网络配置:

    $ oc get network.operator cluster -o yaml > network-config-backup.yaml
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令修改现有的网络配置:

    $ oc edit network.operator cluster
    Copy to Clipboard Toggle word wrap
    1. spec 中添加或更新以下块,如下例所示:

      spec:
        clusterNetwork:
        - cidr: 10.128.0.0/14
          hostPrefix: 23
        serviceNetwork:
        - 172.30.0.0/16
        networkType: OVNKubernetes
        clusterNetworkMTU: 8900
        defaultNetwork:
          ovnKubernetesConfig:
            gatewayConfig:
              ipForwarding: Global
      Copy to Clipboard Toggle word wrap
    2. 保存并关闭该文件。
  3. 应用更改后,OpenShift Cluster Network Operator (CNO) 在集群中应用更新。您可以使用以下命令监控进度:

    $ oc get clusteroperators network
    Copy to Clipboard Toggle word wrap

    状态最终应报告为 Available,Progressing=False, 和 Degraded=False

  4. 另外,您可以运行以下命令来全局启用 IP 转发:

    $ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge
    Copy to Clipboard Toggle word wrap
    注意

    当您要恢复此更改时,此参数的其他有效选项为 Restrictedrestricted 是默认设置,并且禁用设置全局 IP 地址转发。

6.5. 查看 Cluster Network Operator 日志

您可以使用 oc logs 命令来查看 Cluster Network Operator 日志。

流程

  • 运行以下命令,以查看 Cluster Network Operator 的日志:

    $ oc logs --namespace=openshift-network-operator deployment/network-operator
    Copy to Clipboard Toggle word wrap

6.6. Cluster Network Operator 配置

集群网络的配置作为 Cluster Network Operator(CNO)配置的一部分指定,并存储在名为 cluster 的自定义资源(CR)对象中。CR 指定 operator.openshift.io API 组中的 Network API 的字段。

CNO 配置在集群安装过程中从 Network.config.openshift.io API 组中的 Network API 继承以下字段:

clusterNetwork
从中分配 Pod IP 地址的 IP 地址池。
serviceNetwork
服务的 IP 地址池.
defaultNetwork.type
集群网络插件。OVNKubernetes 是安装期间唯一支持的插件。
注意

在集群安装后,您只能修改 clusterNetwork IP 地址范围。

您可以通过在名为 cluster 的 CNO 对象中设置 defaultNetwork 对象的字段来为集群指定集群网络插件配置。

6.6.1. Cluster Network Operator 配置对象

下表中描述了 Cluster Network Operator(CNO)的字段:

Expand
表 6.1. Cluster Network Operator 配置对象
字段类型描述

metadata.name

字符串

CNO 对象的名称。这个名称始终是 集群

spec.clusterNetwork

array

用于指定从哪些 IP 地址块分配 Pod IP 地址以及集群中每个节点的子网前缀长度的列表。例如:

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23
Copy to Clipboard Toggle word wrap

spec.serviceNetwork

array

服务的 IP 地址块。OVN-Kubernetes 网络插件只支持服务网络的一个 IP 地址块。例如:

spec:
  serviceNetwork:
  - 172.30.0.0/14
Copy to Clipboard Toggle word wrap

此值是只读的,在集群安装过程中从名为 clusterNetwork.config.openshift.io 对象继承。

spec.defaultNetwork

object

为集群网络配置网络插件。

spec.kubeProxyConfig

object

此对象的字段指定 kube-proxy 配置。如果使用 OVN-Kubernetes 集群网络供应商,则 kube-proxy 配置不会起作用。

重要

对于需要在多个网络间部署对象的集群,请确保为 install-config.yaml 文件中定义的每种网络类型指定与 clusterNetwork.hostPrefix 参数相同的值。为每个 clusterNetwork.hostPrefix 参数设置不同的值可能会影响 OVN-Kubernetes 网络插件,其中插件无法有效地在不同节点间路由对象流量。

6.6.1.1. defaultNetwork 对象配置

下表列出了 defaultNetwork 对象的值:

Expand
表 6.2. defaultNetwork 对象
字段类型描述

type

字符串

OVNKubernetes。Red Hat OpenShift Networking 网络插件在安装过程中被选择。此值在集群安装后无法更改。

注意

OpenShift Container Platform 默认使用 OVN-Kubernetes 网络插件。OpenShift SDN 不再作为新集群的安装选择提供。

ovnKubernetesConfig

object

此对象仅对 OVN-Kubernetes 网络插件有效。

6.6.1.1.1. 配置 OVN-Kubernetes 网络插件

下表描述了 OVN-Kubernetes 网络插件的配置字段:

Expand
表 6.3. ovnKubernetesConfig object
字段类型描述

mtu

integer

Geneve(通用网络虚拟化封装)覆盖网络的最大传输单元(MTU)。这个值通常是自动配置的。

genevePort

integer

Geneve 覆盖网络的 UDP 端口。

ipsecConfig

object

用于描述集群的 IPsec 模式的对象。

ipv4

object

为 IPv4 设置指定配置对象。

ipv6

object

为 IPv6 设置指定配置对象。

policyAuditConfig

object

指定用于自定义网络策略审计日志的配置对象。如果未设置,则使用默认的审计日志设置。

gatewayConfig

object

可选:指定一个配置对象来自定义如何将出口流量发送到节点网关。有效值为 SharedLocal。默认值为 Shared。在默认设置中,Open vSwitch (OVS) 将流量直接输出到节点 IP 接口。在 Local 设置中,它会遍历主机网络;因此,它会应用到主机的路由表。

注意

在迁移出口流量时,工作负载和服务流量会受到一定影响,直到 Cluster Network Operator (CNO) 成功推出更改。

Expand
表 6.4. ovnKubernetesConfig.ipv4 object
字段类型描述

internalTransitSwitchSubnet

字符串

如果您的现有网络基础架构与 100.88.0.0/16 IPv4 子网重叠,您可以指定不同的 IP 地址范围供 OVN-Kubernetes 使用。启用东西流量的分布式传输交换机的子网。此子网不能与 OVN-Kubernetes 或主机本身使用的任何其他子网重叠。必须足够大,以适应集群中的每个节点一个 IP 地址。

默认值为 100.88.0.0/16

internalJoinSubnet

字符串

如果您的现有网络基础架构与 100.64.0.0/16 IPv4 子网重叠,您可以指定不同的 IP 地址范围供 OVN-Kubernetes 使用。您必须确保 IP 地址范围没有与 OpenShift Container Platform 安装使用的任何其他子网重叠。IP 地址范围必须大于可添加到集群的最大节点数。例如,如果 clusterNetwork.cidr 值为 10.128.0.0/14,并且 clusterNetwork.hostPrefix 值为 /23,则最大节点数量为 2^(23-14)=512

默认值为 100.64.0.0/16

Expand
表 6.5. ovnKubernetesConfig.ipv6 object
字段类型描述

internalTransitSwitchSubnet

字符串

如果您的现有网络基础架构与 fd97::/64 IPv6 子网重叠,您可以指定不同的 IP 地址范围供 OVN-Kubernetes 使用。启用东西流量的分布式传输交换机的子网。此子网不能与 OVN-Kubernetes 或主机本身使用的任何其他子网重叠。必须足够大,以适应集群中的每个节点一个 IP 地址。

默认值为 fd97::/64

internalJoinSubnet

字符串

如果您的现有网络基础架构与 fd98::/64 IPv6 子网重叠,您可以指定不同的 IP 地址范围供 OVN-Kubernetes 使用。您必须确保 IP 地址范围没有与 OpenShift Container Platform 安装使用的任何其他子网重叠。IP 地址范围必须大于可添加到集群的最大节点数。

默认值为 fd98::/64

Expand
表 6.6. policyAuditConfig object
字段类型描述

rateLimit

整数

每个节点每秒生成一次的消息数量上限。默认值为每秒 20 条消息。

maxFileSize

整数

审计日志的最大大小,以字节为单位。默认值为 50000000 或 50 MB。

maxLogFiles

整数

保留的日志文件的最大数量。

目的地

字符串

以下附加审计日志目标之一:

libc
主机上的 journald 进程的 libc syslog() 函数。
UDP:<host>:<port>
一个 syslog 服务器。将 <host>:<port> 替换为 syslog 服务器的主机 和端口。
Unix:<file>
<file> 指定的 Unix 域套接字文件。
null
不要将审计日志发送到任何其他目标。

syslogFacility

字符串

syslog 工具,如 as kern,如 RFC5424 定义。默认值为 local0。

Expand
表 6.7. gatewayConfig object
字段类型描述

routingViaHost

布尔值

将此字段设置为 true,将来自 pod 的出口流量发送到主机网络堆栈。对于依赖于在内核路由表中手动配置路由的高级别安装和应用程序,您可能需要将出口流量路由到主机网络堆栈。默认情况下,出口流量在 OVN 中进行处理以退出集群,不受内核路由表中的特殊路由的影响。默认值为 false

此字段与 Open vSwitch 硬件卸载功能有交互。如果将此字段设置为 true,则不会获得卸载的性能优势,因为主机网络堆栈会处理出口流量。

ipForwarding

object

您可以使用 Network 资源中的 ipForwarding 规格来控制 OVN-Kubernetes 管理接口上所有流量的 IP 转发。指定 Restricted 只允许 Kubernetes 相关流量的 IP 转发。指定 Global 以允许转发所有 IP 流量。对于新安装,默认值为 Restricted。对于到 OpenShift Container Platform 4.14 或更高版本的更新,默认值为 Global

注意

Restricted 的默认值将 IP 转发设置为 drop。

ipv4

object

可选:指定一个对象来为主机配置内部 OVN-Kubernetes 伪装地址,以服务 IPv4 地址的流量。

ipv6

object

可选:指定一个对象来为主机配置内部 OVN-Kubernetes 伪装地址,以服务 IPv6 地址的流量。

Expand
表 6.8. gatewayConfig.ipv4 对象
字段类型描述

internalMasqueradeSubnet

字符串

内部使用的伪装 IPv4 地址,以启用主机服务流量。主机配置了这些 IP 地址和共享网关网桥接口。默认值为 169.254.169.0/29

重要

对于 OpenShift Container Platform 4.17 及更新的版本,集群使用 169.254.0.0/17 作为默认的 masquerade 子网。对于升级的集群,默认 masquerade 子网没有变化。

Expand
表 6.9. gatewayConfig.ipv6 对象
字段类型描述

internalMasqueradeSubnet

字符串

内部使用的伪装 IPv6 地址,以启用主机服务流量。主机配置了这些 IP 地址和共享网关网桥接口。默认值为 fd69::/125

重要

对于 OpenShift Container Platform 4.17 及更新的版本,集群使用 fd69::/112 作为默认的 masquerade 子网。对于升级的集群,默认 masquerade 子网没有变化。

Expand
表 6.10. ipsecConfig 对象
字段类型描述

模式

字符串

指定 IPsec 实现的行为。必须是以下值之一:

  • Disabled: 在集群节点上不启用 IPsec。
  • External :对于带有外部主机的网络流量,启用 IPsec。
  • Full: IPsec 为带有外部主机的 pod 流量和网络流量启用 IPsec。
注意

您只能在集群安装过程中更改集群网络插件的配置,但 gatewayConfig 字段可作为安装后活动在运行时更改。

启用 IPSec 的 OVN-Kubernetes 配置示例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig:
      mode: Full
Copy to Clipboard Toggle word wrap

6.6.2. Cluster Network Operator 配置示例

以下示例中指定了完整的 CNO 配置:

Cluster Network Operator 对象示例

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  networkType: OVNKubernetes
Copy to Clipboard Toggle word wrap

在 OpenShift Container Platform 中,DNS Operator 部署和管理 CoreDNS 实例,为集群中的 pod 提供名称解析服务,启用基于 DNS 的 Kubernetes 服务发现,并解析内部 cluster.local 名称。

7.1. 检查 DNS Operator 的状态

DNS Operator 从 operator.openshift.io API 组实现 dns API。Operator 使用守护进程集部署 CoreDNS,为守护进程集创建一个服务,并将 kubelet 配置为指示 pod 使用 CoreDNS 服务 IP 地址进行名称解析。

流程

在安装过程中使用 Deployment 对象部署 DNS Operator。

  1. 使用 oc get 命令查看部署状态:

    $ oc get -n openshift-dns-operator deployment/dns-operator
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME           READY     UP-TO-DATE   AVAILABLE   AGE
    dns-operator   1/1       1            1           23h
    Copy to Clipboard Toggle word wrap

  2. 使用 oc get 命令来查看 DNS Operator 的状态:

    $ oc get clusteroperator/dns
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    dns       4.1.15-0.11  True        False         False      92m
    Copy to Clipboard Toggle word wrap

    AVAILABLEPROGRESSINGDEGRADED 提供了有关 Operator 状态的信息。当 CoreDNS 守护进程中至少有一个 pod 被设置为 Available 状态时,AVAILABLETrue,DNS 服务有一个集群 IP 地址。

7.2. 查看默认 DNS

每个 OpenShift Container Platform 新安装都有一个名为 defaultdns.operator

流程

  1. 使用 oc describe 命令来查看默认 dns

    $ oc describe dns.operator/default
    Copy to Clipboard Toggle word wrap

    输出示例

    Name:         default
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         DNS
    ...
    Status:
      Cluster Domain:  cluster.local 
    1
    
      Cluster IP:      172.30.0.10 
    2
    
    ...
    Copy to Clipboard Toggle word wrap

    1
    Cluster Domain 字段是用来构造完全限定的 pod 和服务域名的基本 DNS 域。
    2
    Cluster IP 是 Pod 为名称解析查询的地址。IP 由服务 CIDR 范围中的第 10 个地址定义。
  2. 要查找集群的服务 CIDR 范围,如 172.30.0.0/16,请使用 oc get 命令:

    $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'
    Copy to Clipboard Toggle word wrap

7.3. 使用 DNS 转发

您可以使用以下方法使用 DNS 转发来覆盖 /etc/resolv.conf 文件中的默认转发配置:

  • 为每个区指定名称服务器 (spec.servers)。如果转发区是 OpenShift Container Platform 管理的 ingress 域,则必须为域授权上游名称服务器。
  • 提供上游 DNS 服务器列表 (spec.upstreamResolvers)。
  • 更改默认转发策略。
注意

默认域的 DNS 转发配置可以同时在 /etc/resolv.conf 文件和上游 DNS 服务器中指定默认服务器。

流程

  1. 修改名为 default 的 DNS Operator 对象:

    $ oc edit dns.operator/default
    Copy to Clipboard Toggle word wrap

    发出上一命令后,Operator 会根据 spec.servers 创建并更新名为 dns-default 的配置映射,并使用额外的服务器配置块。如果任何服务器都没有与查询匹配的区域,则名称解析会返回上游 DNS 服务器。

    配置 DNS 转发

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      cache:
        negativeTTL: 0s
        positiveTTL: 0s
      logLevel: Normal
      nodePlacement: {}
      operatorLogLevel: Normal
      servers:
      - name: example-server 
    1
    
        zones:
        - example.com 
    2
    
        forwardPlugin:
          policy: Random 
    3
    
          upstreams: 
    4
    
          - 1.1.1.1
          - 2.2.2.2:5353
      upstreamResolvers: 
    5
    
        policy: Random 
    6
    
        protocolStrategy: ""  
    7
    
        transportConfig: {}  
    8
    
        upstreams:
        - type: SystemResolvConf 
    9
    
        - type: Network
          address: 1.2.3.4 
    10
    
          port: 53 
    11
    
        status:
          clusterDomain: cluster.local
          clusterIP: x.y.z.10
          conditions:
    ...
    Copy to Clipboard Toggle word wrap

    1
    必须符合 rfc6335 服务名称语法。
    2
    必须符合 rfc1123 服务名称语法中的子域的定义。集群域 cluster.local 是对 zones 字段的无效子域。
    3
    定义用于选择 forwardPlugin 中列出的上游解析器的策略。默认值为 Random。您还可以使用 RoundRobin, 和 Sequential 值。
    4
    每个 forwardPlugin 最多允许 15 个 upstreams
    5
    您可以使用 upstreamResolvers 覆盖默认转发策略,并将 DNS 解析转发到默认域的指定 DNS 解析器(上游解析器)。如果没有提供任何上游解析器,DNS 名称查询将进入 /etc/resolv.conf 中声明的服务器。
    6
    决定选择上游中列出的 upstreams 服务器进行查询的顺序。您可以指定这些值之一: RandomRoundRobinSequential。默认值为 Sequential
    7
    如果被省略,平台会选择一个默认值,通常是原始客户端请求的协议。设置为 TCP,以指定平台应该对所有上游 DNS 请求使用 TCP,即使客户端请求使用了 UDP。
    8
    用于配置传输类型、服务器名称和可选自定义 CA 或 CA 捆绑包,以便在将 DNS 请求转发到上游解析器时使用。
    9
    您可以指定两个类型的 upstreamsSystemResolvConfNetworkSystemResolvConf 将上游配置为使用 /etc/resolv.confNetwork 定义一个 Networkresolver。您可以指定其中一个或两者都指定。
    10
    如果指定类型是 Network,则必须提供 IP 地址。address 字段必须是有效的 IPv4 或 IPv6 地址。
    11
    如果指定类型是 Network,您可以选择性地提供端口。port 字段必须是 165535 之间的值。如果您没有为上游指定端口,则默认端口为 853。

7.4. 检查 DNS Operator 状态

您可以使用 oc describe 命令来检查状态并查看 DNS Operator 的详情。

流程

  • 查看 DNS Operator 的状态:

    $ oc describe clusteroperators/dns
    Copy to Clipboard Toggle word wrap

    虽然在特定版本中的信息和拼写可能有所不同,但预期的状态输出如下:

    Status:
      Conditions:
        Last Transition Time:  <date>
        Message:               DNS "default" is available.
        Reason:                AsExpected
        Status:                True
        Type:                  Available
        Last Transition Time:  <date>
        Message:               Desired and current number of DNSes are equal
        Reason:                AsExpected
        Status:                False
        Type:                  Progressing
        Last Transition Time:  <date>
        Reason:                DNSNotDegraded
        Status:                False
        Type:                  Degraded
        Last Transition Time:  <date>
        Message:               DNS default is upgradeable: DNS Operator can be upgraded
        Reason:                DNSUpgradeable
        Status:                True
        Type:                  Upgradeable
    Copy to Clipboard Toggle word wrap

7.5. 查看 DNS Operator 日志

您可以使用 oc logs 命令来查看 DNS Operator 日志。

流程

  • 查看 DNS Operator 的日志:

    $ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
    Copy to Clipboard Toggle word wrap

7.6. 设置 CoreDNS 日志级别

CoreDNS 和 CoreDNS Operator 的日志级别使用不同的方法设置。您可以配置 CoreDNS 日志级别来确定日志记录错误信息中的详情量。CoreDNS 日志级别的有效值为 NormalDebugTrace。默认 logLevelNormal

注意

CoreDNS 错误日志级别总是被启用。以下日志级别设置报告不同的错误响应:

  • logLevel: Normal 启用 "errors" 类: log . { class error }.
  • loglevelDebug 启用 "denial" 类: log . { class denial error }
  • logLevel: Trace 启用 "all" 类: log . { class all }.

流程

  • 要将 logLevel 设置为 Debug,输入以下命令:

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  • 要将 logLevel 设置为 Trace,输入以下命令:

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge
    Copy to Clipboard Toggle word wrap

验证

  • 要确保设置了所需的日志级别,请检查配置映射:

    $ oc get configmap/dns-default -n openshift-dns -o yaml
    Copy to Clipboard Toggle word wrap

    例如,在将 logLevel 设置为 Trace 后,您应该在每个 server 块中看到这个小节:

    errors
    log . {
        class all
    }
    Copy to Clipboard Toggle word wrap

7.7. 查看 CoreDNS 日志

您可以使用 oc logs 命令查看 CoreDNS 日志。

流程

  • 输入以下命令来查看特定 CoreDNS pod 的日志:

    $ oc -n openshift-dns logs -c dns <core_dns_pod_name>
    Copy to Clipboard Toggle word wrap
  • 输入以下命令遵循所有 CoreDNS pod 的日志:

    $ oc -n openshift-dns logs -c dns -l dns.operator.openshift.io/daemonset-dns=default -f --max-log-requests=<number> 
    1
    Copy to Clipboard Toggle word wrap
    1
    指定要流传输日志的 DNS pod 数量。最大值为 6。

7.8. 设置 CoreDNS Operator 的日志级别

CoreDNS 和 CoreDNS Operator 的日志级别使用不同的方法设置。集群管理员可以配置 Operator 日志级别来更快地跟踪 OpenShift DNS 问题。operatorLogLevel 的有效值为 NormalDebugTraceTrace 具有更详细的信息。默认 operatorlogLevelNormal。Operator 问题有七个日志记录级别: Trace, Debug, Info, Warning, Error, Fatal, 和 Panic。设置了日志级别后,具有该严重性级别或以上级别的所有内容都会记录为日志条目。

  • operatorLogLevel: "Normal" 设置 logrus.SetLogLevel("Info")
  • operatorLogLevel: "Debug" 设置 logrus.SetLogLevel("Debug")
  • operatorLogLevel: "Trace" 设置 logrus.SetLogLevel("Trace")

流程

  • 要将 operatorLogLevel 设置为 Debug,请输入以下命令:

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  • 要将 operatorLogLevel 设置为 Trace,请输入以下命令:

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge
    Copy to Clipboard Toggle word wrap

验证

  1. 要查看生成的更改,请输入以下命令:

    $ oc get dnses.operator -A -oyaml
    Copy to Clipboard Toggle word wrap

    您应该会看到两个日志级别条目。operatorLogLevel 适用于 OpenShift DNS Operator 问题,logLevel 适用于 CoreDNS pod 的 daemonset:

     logLevel: Trace
     operatorLogLevel: Debug
    Copy to Clipboard Toggle word wrap
  2. 要查看 daemonset 的日志,请输入以下命令:

    $ oc logs -n openshift-dns ds/dns-default
    Copy to Clipboard Toggle word wrap

7.9. 调整 CoreDNS 缓存

对于 CoreDNS,您可以配置成功或不成功缓存的最长持续时间,也称为正缓存或负缓存。调整 DNS 查询响应的缓存持续时间可减少任何上游 DNS 解析器的负载。

警告

将 TTL 字段设为低值可能会导致集群、任何上游解析器或两者中负载的增加。

流程

  1. 运行以下命令来编辑名为 default 的 DNS Operator 对象:

    $ oc edit dns.operator.openshift.io/default
    Copy to Clipboard Toggle word wrap
  2. 修改生存时间 (TTL) 缓存值:

    配置 DNS 缓存

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      cache:
        positiveTTL: 1h 
    1
    
        negativeTTL: 0.5h10m 
    2
    Copy to Clipboard Toggle word wrap

    1
    CoreDNS 会将字符串值 1h 转换为其相应的秒数。如果省略此字段,则假定该值为 0s,集群将使用内部默认值 900s 作为回退。
    2
    字符串值可以是单元的组合(如 0.5h10m),并被 CoreDNS 转换为相应秒数。如果省略了此字段,则假定该值为 0s,集群将使用内部默认值 30s 作为回退。

验证

  1. 要查看更改,请运行以下命令再次查看配置映射:

    $ oc get configmap/dns-default -n openshift-dns -o yaml
    Copy to Clipboard Toggle word wrap
  2. 验证您是否看到类似以下示例的条目:

           cache 3600 {
                denial 9984 2400
            }
    Copy to Clipboard Toggle word wrap

7.10. 高级任务

7.10.1. 更改 DNS Operator managementState

DNS Operator 管理 CoreDNS 组件,为集群中的 pod 和服务提供名称解析服务。默认情况下,DNS Operator 的 managementState 设置为 Managed,这意味着 DNS Operator 会主动管理其资源。您可以将其更改为 Unmanaged,这意味着 DNS Operator 不管理其资源。

以下是更改 DNS Operator managementState 的用例:

  • 您是一个开发者,希望测试配置更改来查看它是否解决了 CoreDNS 中的问题。您可以通过将 managementState 设置为 Unmanaged 来停止 DNS Operator 覆盖配置更改。
  • 您是一个集群管理员,报告了 CoreDNS 的问题,但在解决这个问题前需要应用一个临时解决方案。您可以将 DNS Operator 的 managementState 字段设置为 Unmanaged 以应用临时解决方案。

流程

  1. 在 DNS Operator 中将 managementState 更改为 Unmanaged

    oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
    Copy to Clipboard Toggle word wrap
  2. 使用 jsonpath 命令行 JSON 解析器查看 DNS Operator 的 managementState

    $ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'
    Copy to Clipboard Toggle word wrap
    注意

    managementState 设置为 Unmanaged 时,您无法升级。

7.10.2. 控制 DNS pod 放置

DNS Operator 有两个守护进程集:一个用于 CoreDNS,名为 dns-default,另一个用于管理 名为 node-resolver/etc/hosts 文件。

您可能会发现,需要控制哪些节点已分配并运行了 CoreDNS pod,尽管这不是一个常见操作。例如,如果集群管理员配置了可以禁止节点对节点间通信的安全策略,这需要限制 CoreDNS 运行 daemonset 的节点集合。如果 DNS pod 在集群中的某些节点上运行,且没有运行 DNS pod 的节点与运行 DNS pod 的节点具有网络连接,则 DNS 服务将适用于所有 pod。

node-resolver 守护进程集必须在每个节点主机上运行,因为它为集群镜像 registry 添加一个条目来支持拉取镜像。node-resolver pod 只有一个作业:查找 image-registry.openshift-image-registry.svc 服务的集群 IP 地址,并将其添加到节点主机上的 /etc/hosts 中,以便容器运行时可以解析服务名称。

作为集群管理员,您可以使用自定义节点选择器将 CoreDNS 的守护进程集配置为在某些节点上运行或不运行。

先决条件

  • 已安装 oc CLI。
  • 以具有 cluster-admin 权限的用户身份登录集群。
  • 您的 DNS Operator managementState 设置为 Managed

流程

  • 要允许 CoreDNS 的守护进程集在特定节点上运行,请配置污点和容限:

    1. 修改名为 default 的 DNS Operator 对象:

      $ oc edit dns.operator/default
      Copy to Clipboard Toggle word wrap
    2. 为污点指定污点键和一个容忍度:

       spec:
         nodePlacement:
           tolerations:
           - effect: NoExecute
             key: "dns-only"
             operators: Equal
             value: abc
             tolerationSeconds: 3600 
      1
      Copy to Clipboard Toggle word wrap
      1
      如果污点是 dns-only,它可以无限期地被容许。您可以省略 tolerationSeconds

7.10.3. 使用 TLS 配置 DNS 转发

在高度监管的环境中工作时,您可能需要在将请求转发到上游解析器时保护 DNS 流量,以便您可以确保额外的 DNS 流量和数据隐私。

请注意,CoreDNS 缓存在 10 秒内转发连接。如果没有请求,CoreDNS 将为该 10 秒打开 TCP 连接。对于大型集群,请确保您的 DNS 服务器知道可能有多个新的连接来保存打开,因为您可以在每个节点上启动连接。相应地设置 DNS 层次结构以避免性能问题。

流程

  1. 修改名为 default 的 DNS Operator 对象:

    $ oc edit dns.operator/default
    Copy to Clipboard Toggle word wrap

    集群管理员可以配置传输层安全(TLS)来转发 DNS 查询。

    使用 TLS 配置 DNS 转发

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      servers:
      - name: example-server 
    1
    
        zones:
        - example.com 
    2
    
        forwardPlugin:
          transportConfig:
            transport: TLS 
    3
    
            tls:
              caBundle:
                name: mycacert
              serverName: dnstls.example.com  
    4
    
          policy: Random 
    5
    
          upstreams: 
    6
    
          - 1.1.1.1
          - 2.2.2.2:5353
      upstreamResolvers: 
    7
    
        transportConfig:
          transport: TLS
          tls:
            caBundle:
              name: mycacert
            serverName: dnstls.example.com
        upstreams:
        - type: Network 
    8
    
          address: 1.2.3.4 
    9
    
          port: 53 
    10
    Copy to Clipboard Toggle word wrap

    1
    必须符合 rfc6335 服务名称语法。
    2
    必须符合 rfc1123 服务名称语法中的子域的定义。集群域 cluster.local 是对 zones 字段的无效子域。集群域 cluster.local 不是 zones 中的一个有效的 subdomain
    3
    在为转发 DNS 查询配置 TLS 时,将 transport 字段设置为具有值 TLS
    4
    当为转发 DNS 查询配置 TLS 时,这是用作服务器名称的一部分(SNI)的强制服务器名称来验证上游 TLS 服务器证书。
    5
    定义用于选择上游解析器的策略。默认值为 Random。您还可以使用 RoundRobin, 和 Sequential 值。
    6
    必需。使用它提供上游解析器。每个 forwardPlugin 条目最多允许 15 个 upstreams 条目。
    7
    可选。您可以使用它来覆盖默认策略,并将 DNS 解析转发到默认域的指定 DNS 解析器(上游解析器)。如果没有提供任何上游解析器,DNS 名称查询将进入 /etc/resolv.conf 中的服务器。
    8
    在使用 TLS 时,只允许网络类型,且您必须提供 IP 地址。网络类型表示,该上游解析器应该独立于 /etc/resolv.conf 中列出的上游解析器单独处理转发请求。
    9
    address 字段必须是有效的 IPv4 或 IPv6 地址。
    10
    您可以选择提供端口。port 必须是 165535 之间的值。如果您没有为上游指定端口,则默认端口为 853。
    注意

    如果 servers 未定义或无效,则配置映射只包括默认服务器。

验证

  1. 查看配置映射:

    $ oc get configmap/dns-default -n openshift-dns -o yaml
    Copy to Clipboard Toggle word wrap

    基于 TLS 转发示例的 DNS ConfigMap 示例

    apiVersion: v1
    data:
      Corefile: |
        example.com:5353 {
            forward . 1.1.1.1 2.2.2.2:5353
        }
        bar.com:5353 example.com:5353 {
            forward . 3.3.3.3 4.4.4.4:5454 
    1
    
        }
        .:5353 {
            errors
            health
            kubernetes cluster.local in-addr.arpa ip6.arpa {
                pods insecure
                upstream
                fallthrough in-addr.arpa ip6.arpa
            }
            prometheus :9153
            forward . /etc/resolv.conf 1.2.3.4:53 {
                policy Random
            }
            cache 30
            reload
        }
    kind: ConfigMap
    metadata:
      labels:
        dns.operator.openshift.io/owning-dns: default
      name: dns-default
      namespace: openshift-dns
    Copy to Clipboard Toggle word wrap

    1
    forwardPlugin 的更改会触发 CoreDNS 守护进程集的滚动更新。

Ingress Operator 实现 IngressController API,是负责启用对 OpenShift Container Platform 集群服务的外部访问的组件。

8.1. OpenShift Container Platform Ingress Operator

在创建 OpenShift Container Platform 集群时,在集群中运行的 Pod 和服务会各自分配自己的 IP 地址。IP 地址可供附近运行的其他容器集和服务访问,但外部客户端无法访问这些 IP 地址。

Ingress Operator 通过部署和管理一个或多个基于 HAProxy 的 Ingress Controller 来处理路由,使外部客户端可以访问您的服务。您可以通过指定 OpenShift Container Platform Route 和 Kubernetes Ingress 资源,来使用 Ingress Operator 路由流量。Ingress Controller 中的配置(如定义 endpointPublishingStrategy 类型和内部负载平衡)提供了发布 Ingress Controller 端点的方法。

8.2. Ingress 配置资产

安装程序在 config.openshift.io API 组中生成带有 Ingress 资源的资产,cluster-ingress-02-config.yml

Ingress 资源的 YAML 定义

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: apps.openshiftdemos.com
Copy to Clipboard Toggle word wrap

安装程序将这个资产保存在 manifests/ 目录下的 cluster-ingress-02-config.yml 文件中。此 Ingress 资源定义 Ingress 的集群范围配置。此 Ingress 配置的用法如下所示:

  • Ingress Operator 使用集群 Ingress 配置中的域,作为默认 Ingress Controller 的域。
  • OpenShift API Server Operator 使用集群 Ingress 配置中的域。在为未指定显式主机的 Route 资源生成默认主机时,还会使用此域。

8.3. Ingress Controller 配置参数

IngressController 自定义资源(CR) 包含可选配置参数,您可以配置它们来满足您的机构的特定需求。

Expand
参数描述

domain

domain 是 Ingress Controller 服务的一个 DNS 名称,用于配置多个功能:

  • 对于 LoadBalancerService 端点发布策略,domain 被用来配置 DNS 记录。请参阅 endpointPublishingStrategy
  • 当使用生成的默认证书时,该证书对及其子域有效。请参阅 defaultCertificate
  • 该值会发布到独立的 Route 状态,以便用户了解目标外部 DNS 记录的位置。

domain 值在所有 Ingress 控制器中需要是唯一的,且不能更新。

如果为空,默认值为 ingress.config.openshift.io/cluster .spec.domain

replicas

replicas 是 Ingress Controller 副本数量。如果没有设置,则默认值为 2

endpointPublishingStrategy

endpointPublishingStrategy 用于向其他网络发布 Ingress Controller 端点,以启用负载均衡器集成,并提供对其他系统的访问。

对于云环境,使用 loadBalancer 字段为 Ingress Controller 配置端点发布策略。

在 GCP、AWS 和 Azure 上,您可以配置以下 endpointPublishingStrategy 字段:

  • loadBalancer.scope
  • loadBalancer.allowedSourceRanges

如果没有设置,则默认值基于 infrastructure.config.openshift.io/cluster .status.platform

  • Azure: LoadBalancerService (具有外部范围)
  • Google Cloud Platform(GCP): LoadBalancerService (具有外部范围)

对于大多数平台,可以更新 endpointPublishingStrategy 值。在 GCP 上,您可以配置以下 endpointPublishingStrategy 字段:

  • loadBalancer.scope
  • loadbalancer.providerParameters.gcp.clientAccess

对于非云环境,如裸机平台,请使用 NodePortServiceHostNetworkPrivate 字段来为 Ingress Controller 配置端点发布策略。

如果您没有在这些字段中设置值,则默认值基于 IngressController CR 中的 .status.platform 值中指定的绑定端口。

如果需要在集群部署后更新 endpointPublishingStrategy 值,您可以配置以下 endpointPublishingStrategy 字段:

  • hostNetwork.protocol
  • nodePort.protocol
  • private.protocol

defaultCertificate

defaultCertificate 的值是一个到包括由 Ingress controller 提供的默认证书的 secret 的指代。当 Routes 没有指定其自身证书时,使用 defaultCertificate

secret 必须包含以下密钥和数据:* tls.crt:证书文件内容 * tls.key:密钥文件内容

如果没有设置,则自动生成和使用通配符证书。该证书对 Ingress Controller 的子域有效,所生成的证书的 CA 会自动与集群的信任存储集成。

内部证书(无论是生成的证书还是用户指定的证书)自动与 OpenShift Container Platform 内置的 OAuth 服务器集成。

namespaceSelector

namespaceSelector 用来过滤由 Ingress 控制器提供服务的一组命名空间。这对实现分片(shard)非常有用。

routeSelector

routeSelector 用于由 Ingress Controller 提供服务的一组 Routes。这对实现分片(shard)非常有用。

nodePlacement

NodePlacement 启用对 Ingress Controller 调度的显式控制。

如果没有设置,则使用默认值。

注意

nodePlacement 参数包括两个部分: nodeSelectortolerations。例如:

nodePlacement:
 nodeSelector:
   matchLabels:
     kubernetes.io/os: linux
 tolerations:
 - effect: NoSchedule
   operator: Exists
Copy to Clipboard Toggle word wrap

tlsSecurityProfile

tlsSecurityProfile 指定 Ingress Controller 的 TLS 连接的设置。

如果没有设置,则默认值基于 apiservers.config.openshift.io/cluster 资源。

当使用 OldIntermediateModern配置集类型时,有效的配置集可能会在不同发行版本间有所改变。例如:使用在版本 X.Y.Z 中部署的 Intermediate 配置集,升级到版本 X.Y.Z+1 可能会导致新的配置集配置应用到 Ingress Controller,从而导致一个 rollout 操作。

Ingress Controller 的最低 TLS 版本是 1.1,最高 TLS 版本为 1.3

注意

加密器和配置的安全配置集的最小 TLS 版本反映在 TLSProfile 状态中。

重要

Ingress Operator 将 OldCustom 配置集的 TLS 1.0 转换为 1.1

clientTLS

clientTLS 验证客户端对集群和服务的访问;因此,启用了 mutual TLS 身份验证。如果没有设置,则不启用客户端 TLS。

clientTLS 具有所需的子字段 spec.clientTLS.clientCertificatePolicyspec.clientTLS.ClientCA

ClientCertificatePolicy 子字段接受以下两个值之一:RequiredOptionalClientCA 子字段指定 openshift-config 命名空间中的配置映射。配置映射应包含 CA 证书捆绑包。

AllowedSubjectPatterns 是一个可选值,用于指定正则表达式列表,该列表与有效客户端证书上的可分辨名称匹配以过滤请求。正则表达式必须使用 PCRE 语法。至少一种模式必须与客户端证书的可分辨名称匹配;否则,入口控制器拒绝证书,并拒绝连接。如果没有指定,ingress 控制器不会根据可分辨的名称拒绝证书。

routeAdmission

routeAdmission 定义了处理新路由声明的策略,如允许或拒绝命名空间间的声明。

namespaceOwnership 描述了如何处理跨命名空间的主机名声明。默认为 Strict

  • Strict:不允许路由在命名空间间声明相同的主机名。
  • InterNamespaceAllowed :允许路由在命名空间间声明相同主机名的不同路径。

wildcardPolicy 描述了 Ingress Controller 如何处理采用通配符策略的路由。

  • WildcardsAllowed:表示 Ingress Controller 允许采用任何通配符策略的路由。
  • WildcardsDisallowed:表示 Ingress Controller 只接受采用 None 通配符策略的路由。将 wildcardPolicyWildcardsAllowed 更新为 WildcardsDisallowed,会导致采用 Subdomain 通配符策略的已接受路由停止工作。这些路由必须重新创建为采用 None 通配符策略,让 Ingress Controller 重新接受。WildcardsDisallowed 是默认设置。

IngressControllerLogging

logging 定义了有关在哪里记录什么内容的参数。如果此字段为空,则会启用运行日志,但禁用访问日志。

  • access 描述了客户端请求的日志记录方式。如果此字段为空,则禁用访问日志。

    • destination 描述日志消息的目的地。

      • type 是日志的目的地类型:

        • Container 指定日志应该进入 sidecar 容器。Ingress Operator 在 Ingress Controller pod 上配置名为 logs 的容器,并配置 Ingress Controller 以将日志写入容器。管理员应该配置一个自定义日志记录解决方案,从该容器读取日志。使用容器日志意味着,如果日志速率超过容器运行时或自定义日志解决方案的容量,则可能会出现日志丢失的问题。
        • Syslog 指定日志发送到 Syslog 端点。管理员必须指定可以接收 Syslog 消息的端点。管理员应该已经配置了一个自定义 Syslog 实例。
      • container 描述了 Container 日志记录目的地类型的参数。目前没有容器日志记录参数,因此此字段必须为空。
      • syslog 描述了 Syslog 日志记录目的地类型的参数:

        • address 是接收日志消息的 syslog 端点的 IP 地址。
        • port 是接收日志消息的 syslog 端点的 UDP 端口号。
        • MaxLength 是 syslog 消息的最大长度。它必须介于 4804096 字节之间。如果此字段为空,则最大长度设置为默认值 1024 字节。
        • facility 指定日志消息的 syslog 工具。如果该字段为空,则工具为 local1。否则,它必须指定一个有效的 syslog 工具: kernusermaildaemonauthsyslog, lpr, news, uucp, cron, auth2, ftp, ntp, audit, alert, cron2, local0, local1local2local3local4local5local6local7
    • httpLogFormat 指定 HTTP 请求的日志消息格式。如果此字段为空,日志消息将使用实现中的默认 HTTP 日志格式。有关 HAProxy 的默认 HTTP 日志格式,请参阅 HAProxy 文档

httpHeaders

httpHeaders 为 HTTP 标头定义策略。

通过为 IngressControllerHTTPHeaders 设置 forwardHeaderPolicy,您可以指定 Ingress 控制器何时和如何设置 ForwardedX-Forwarded-ForX-Forwarded-HostX-Forwarded-PortX-Forwarded-ProtoX-Forwarded-Proto-Version HTTP 标头。

默认情况下,策略设置为 Append

  • Append 指定 Ingress Controller 会附加标头,并保留任何现有的标头。
  • Replace 指定 Ingress Controller 设置标头,删除任何现有的标头。
  • IfNone 指定 Ingress Controller 在尚未设置标头时设置它们。
  • Never 指定 Ingress Controller 不会设置标头,并保留任何现有的标头。

通过设置 headerNameCaseAdjustments,您可以指定 HTTP 标头名对大小写的调整。每个调整都指定一个 HTTP 标头名称需要进行相关的大小写调整。例如,指定 X-Forwarded-For 表示 x-forwarded-for HTTP 标头应调整相应的大写。

这些调整仅应用于明文、边缘终止和重新加密路由,且仅在使用 HTTP/1 时有效。

对于请求标头,这些调整仅适用于具有 haproxy.router.openshift.io/h1-adjust-case=true 注解的路由。对于响应标头,这些调整适用于所有 HTTP 响应。如果此字段为空,则不会调整任何请求标头。

actions 指定对标头执行某些操作的选项。无法为 TLS 透传连接设置或删除标头。actions 字段具有额外的子字段 spec.httpHeader.actions.responsespec.httpHeader.actions.request

  • response 子字段指定要设置或删除的 HTTP 响应标头列表。
  • request 子字段指定要设置或删除的 HTTP 请求标头列表。

httpCompression

httpCompression 定义 HTTP 流量压缩的策略。

  • mimeTypes 定义应该将压缩应用到的 MIME 类型列表。例如,text/css; charset=utf-8, text/html, text/*, image/svg+xml, application/octet-stream, X-custom/customsub,格式为 type/subtype; [;attribute=value]types 是:application, image, message, multipart, text, video, 或一个自定义类型(前面带有一个 X-;如需更详细的 MIME 类型和子类型的信息,请参阅 RFC1341

httpErrorCodePages

httpErrorCodePages 指定自定义 HTTP 错误代码响应页面。默认情况下,IngressController 使用 IngressController 镜像内构建的错误页面。

httpCaptureCookies

httpCaptureCookies 指定您要在访问日志中捕获的 HTTP cookie。如果 httpCaptureCookies 字段为空,则访问日志不会捕获 Cookie。

对于您要捕获的任何 Cookie,以下参数必须位于 IngressController 配置中:

  • name 指定 Cookie 的名称。
  • MaxLength 指定 Cookie 的最大长度。
  • matchType 指定 Cookie 的 name 字段是否与捕获 Cookie 设置完全匹配,或者是捕获 Cookie 设置的前缀。matchType 字段使用 ExactPrefix 参数。

例如:

  httpCaptureCookies:
  - matchType: Exact
    maxLength: 128
    name: MYCOOKIE
Copy to Clipboard Toggle word wrap

httpCaptureHeaders

httpCaptureHeaders 指定要在访问日志中捕获的 HTTP 标头。如果 httpCaptureHeaders 字段为空,则访问日志不会捕获标头。

httpCaptureHeaders 包含两个要在访问日志中捕获的标头列表。这两个标题字段列表是 requestresponse。在这两个列表中,name 字段必须指定标头名称和 maxlength 字段,必须指定标头的最大长度。例如:

  httpCaptureHeaders:
    request:
    - maxLength: 256
      name: Connection
    - maxLength: 128
      name: User-Agent
    response:
    - maxLength: 256
      name: Content-Type
    - maxLength: 256
      name: Content-Length
Copy to Clipboard Toggle word wrap

tuningOptions

tuningOptions 指定用于调整 Ingress Controller pod 性能的选项。

  • clientFinTimeout 指定连接在等待客户端响应关闭连接时保持打开的时长。默认超时为 1s
  • clientTimeout 指定连接在等待客户端响应时保持打开的时长。默认超时为 30s
  • headerBufferBytes 为 Ingress Controller 连接会话指定保留多少内存(以字节为单位)。如果为 Ingress Controller 启用了 HTTP/2,则必须至少为 16384。如果没有设置,则默认值为 32768 字节。不建议设置此字段,因为 headerBufferBytes 值太小可能会破坏 Ingress Controller,而 headerBufferBytes 值过大可能会导致 Ingress Controller 使用比必要多的内存。
  • headerBufferMaxRewriteBytes 指定从 headerBufferBytes 为 Ingress Controller 连接会话保留多少内存(以字节为单位),用于 HTTP 标头重写和附加。headerBufferMaxRewriteBytes 的最小值是 4096headerBufferBytes 必须大于 headerBufferMaxRewriteBytes,用于传入的 HTTP 请求。如果没有设置,则默认值为 8192 字节。不建议设置此字段,因为 headerBufferMaxRewriteBytes 值可能会破坏 Ingress Controller,headerBufferMaxRewriteBytes 值太大可能会导致 Ingress Controller 使用比必要大得多的内存。
  • healthCheckInterval 指定路由器在健康检查之间等待的时间。默认值为 5s
  • serverFinTimeout 指定连接在等待服务器响应关闭连接时保持打开的时长。默认超时为 1s
  • serverTimeout 指定连接在等待服务器响应时保持打开的时长。默认超时为 30s
  • threadCount 指定每个 HAProxy 进程创建的线程数量。创建更多线程可让每个 Ingress Controller pod 处理更多连接,而代价会增加所使用的系统资源。HAProxy 支持多达 64 个线程。如果此字段为空,Ingress Controller 将使用默认值 4 个线程。默认值可能会在以后的版本中改变。不建议设置此字段,因为增加 HAProxy 线程数量可让 Ingress Controller pod 在负载下使用更多 CPU 时间,并阻止其他 pod 收到需要执行的 CPU 资源。减少线程数量可能会导致 Ingress Controller 执行不佳。
  • tlsInspectDelay 指定路由器可以保存数据以查找匹配的路由的时长。如果把这个值设置得太短,对于 edge-terminated, reencrypted, 或 passthrough 的路由,则可能会导致路由器回退到使用默认证书,即使正在使用一个更加匹配的证书时也是如此。默认检查延迟为 5s
  • tunnelTimeout 指定隧道连接在隧道闲置期间保持打开的时长,包括 websockets。默认超时为 1h
  • maxConnections 指定每个 HAProxy 进程可建立的最大同时连接数。增加这个值可让每个入口控制器 pod 以额外的系统资源成本处理更多连接。允许的值是 0-1、以及范围为 20002000000 内的任何值,或者字段可以留空。

    • 如果此字段留空,或者值为 0,Ingress Controller 将使用默认值 50000。这个值可能在以后的版本中有所改变。
    • 如果字段的值为 -1,则 HAProxy 将根据运行中容器中的可用 ulimits 动态计算最大值。与当前默认值 50000 相比,此进程会产生很大的内存用量。
    • 如果字段的值大于当前操作系统的限制,则 HAProxy 进程将不会启动。
    • 如果您选择了一个离散值,并且路由器 pod 迁移到新节点,则新节点可能没有配置相同的 ulimit。在这种情况下,pod 无法启动。
    • 如果您配置了不同的 ulimits 的节点,并且您选择离散值,则建议为该字段使用 -1 的值,以便在运行时计算连接的最大数量。

logEmptyRequests

logEmptyRequests 指定没有接收和记录请求的连接。这些空请求来自负载均衡器健康探测或 Web 浏览器规范连接(preconnect),并记录这些请求。但是,这些请求可能是由网络错误导致的,在这种情况下,记录空请求可用于诊断错误。这些请求可能是由端口扫描导致的,记录空请求有助于检测入侵尝试。此字段允许的值有 LogIgnore。默认值为 Log

LoggingPolicy 类型接受以下两个值之一:

  • log :将此值设置为 Log 表示应记录某一事件。
  • ignore :将此值设置为 Ignore 会在 HAproxy 配置中设置 dontlognull 选项。

HTTPEmptyRequestsPolicy

HTTPEmptyRequestsPolicy 描述了在收到请求前发生超时时,如何处理 HTTP 连接。此字段允许的值是 RespondIgnore。默认值为 Respond

HTTPEmptyRequestsPolicy 类型接受以下两个值之一:

  • Respond:如果字段设置为 Respond,Ingress Controller 会发送 HTTP 400408 响应,在启用了访问日志时记录连接,并在适当的指标中计数连接。
  • ignore:将这个选项设置为 Ignore 会在 HAproxy 配置中添加 http-ignore-probes 参数。如果字段设置为 Ignore,Ingnore 会在不发送响应的情况下关闭连接,然后记录连接或递增指标。

这些连接来自负载均衡器健康探测或 Web 浏览器规范连接(预连接),可以安全地忽略。但是,这些请求可能是由网络错误造成的,因此将此字段设置为 Ignore 可能会妨碍对问题的检测和诊断。这些请求可能是由端口扫描导致的,在这种情况下,记录空请求有助于检测入侵尝试。

8.3.1. Ingress Controller TLS 安全配置集

TLS 安全配置文件为服务器提供了一种方式,以规范连接的客户端在连接服务器时可以使用哪些密码。

8.3.1.1. 了解 TLS 安全配置集

您可以使用 TLS(Transport Layer Security)安全配置集来定义各种 OpenShift Container Platform 组件需要哪些 TLS 密码。OpenShift Container Platform TLS 安全配置集基于 Mozilla 推荐的配置

您可以为每个组件指定以下 TLS 安全配置集之一:

Expand
表 8.1. TLS 安全配置集
profile描述

Old

此配置集用于旧的客户端或库。该配置集基于旧的向后兼容性建议配置。

Old 配置集要求最低 TLS 版本 1.0。

注意

对于 Ingress Controller,最小 TLS 版本从 1.0 转换为 1.1。

Intermediate

此配置集是 Ingress Controller、kubelet 和 control plane 的默认 TLS 安全配置集。该配置集基于 Intermediate 兼容性推荐的配置。

Intermediate 配置集需要最小 TLS 版本 1.2。

注意

这个配置集是大多数客户端的建议配置。

Modern

此配置集主要用于不需要向后兼容的现代客户端。这个配置集基于 Modern 兼容性推荐的配置。

Modern 配置集需要最低 TLS 版本 1.3。

Custom

此配置集允许您定义要使用的 TLS 版本和密码。

警告

使用 Custom 配置集时要谨慎,因为无效的配置可能会导致问题。

注意

当使用预定义的配置集类型时,有效的配置集配置可能会在发行版本之间有所改变。例如,使用在版本 X.Y.Z 中部署的 Intermediate 配置集指定了一个规格,升级到版本 X.Y.Z+1 可能会导致应用新的配置集配置,从而导致推出部署。

8.3.1.2. 为 Ingress Controller 配置 TLS 安全配置集

要为 Ingress Controller 配置 TLS 安全配置集,请编辑 IngressController 自定义资源(CR)来指定预定义或自定义 TLS 安全配置集。如果没有配置 TLS 安全配置集,则默认值基于为 API 服务器设置的 TLS 安全配置集。

配置 Old TLS 安全配置集的 IngressController CR 示例

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...
Copy to Clipboard Toggle word wrap

TLS 安全配置集定义 Ingress Controller 的 TLS 连接的最低 TLS 版本和 TLS 密码。

您可以在 Status.Tls ProfileSpec.Tls Security Profile 下看到 IngressController 自定义资源(CR)中配置的 TLS 安全配置集的密码和最小 TLS 版本。对于 Custom TLS 安全配置集,这两个参数下列出了特定的密码和最低 TLS 版本。

注意

HAProxy Ingress Controller 镜像支持 TLS 1.3Modern 配置集。

Ingress Operator 还会将 OldCustom 配置集的 TLS 1.0 转换为 1.1

先决条件

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

流程

  1. 编辑 openshift-ingress-operator 项目中的 IngressController CR,以配置 TLS 安全配置集:

    $ oc edit IngressController default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap
  2. 添加 spec.tlsSecurityProfile 字段:

    Custom 配置集的 IngressController CR 示例

    apiVersion: operator.openshift.io/v1
    kind: IngressController
     ...
    spec:
      tlsSecurityProfile:
        type: Custom 
    1
    
        custom: 
    2
    
          ciphers: 
    3
    
          - ECDHE-ECDSA-CHACHA20-POLY1305
          - ECDHE-RSA-CHACHA20-POLY1305
          - ECDHE-RSA-AES128-GCM-SHA256
          - ECDHE-ECDSA-AES128-GCM-SHA256
          minTLSVersion: VersionTLS11
     ...
    Copy to Clipboard Toggle word wrap

    1
    指定 TLS 安全配置集类型(OldIntermediateCustom)。默认值为 Intermediate
    2
    为所选类型指定适当的字段:
    • old: {}
    • intermediate: {}
    • custom:
    3
    对于 custom 类型,请指定 TLS 密码列表和最低接受的 TLS 版本。
  3. 保存文件以使改变生效。

验证

  • 验证 IngressController CR 中是否设置了配置集:

    $ oc describe IngressController default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap

    输出示例

    Name:         default
    Namespace:    openshift-ingress-operator
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         IngressController
     ...
    Spec:
     ...
      Tls Security Profile:
        Custom:
          Ciphers:
            ECDHE-ECDSA-CHACHA20-POLY1305
            ECDHE-RSA-CHACHA20-POLY1305
            ECDHE-RSA-AES128-GCM-SHA256
            ECDHE-ECDSA-AES128-GCM-SHA256
          Min TLS Version:  VersionTLS11
        Type:               Custom
     ...
    Copy to Clipboard Toggle word wrap

8.3.1.3. 配置 mutual TLS 身份验证

您可以通过设置 spec.clientTLS 值,将 Ingress Controller 配置为启用 mutual TLS (mTLS) 身份验证。clientTLS 值将 Ingress Controller 配置为验证客户端证书。此配置包括设置 clientCA 值,这是对配置映射的引用。配置映射包含 PEM 编码的 CA 证书捆绑包,用于验证客户端的证书。另外,您还可以配置证书主题过滤器列表。

如果 clientCA 值指定了 X509v3 证书撤销列表 (CRL) 分发点,Ingress Operator 会下载并管理基于每个提供的证书中指定的 HTTP URI X509v3 CRL 分发点的 CRL 配置映射。Ingress Controller 在 mTLS/TLS 协商过程中使用此配置映射。不提供有效证书的请求将被拒绝。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您有一个 PEM 编码的 CA 证书捆绑包。
  • 如果您的 CA 捆绑包引用 CRL 发布点,还必须将最终用户或叶证书包含在客户端 CA 捆绑包中。此证书必须在 CRL 分发点下包含 HTTP URI,如 RFC 5280 所述。例如:

     Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
             Subject: SOME SIGNED CERT            X509v3 CRL Distribution Points:
                    Full Name:
                      URI:http://crl.example.com/example.crl
    Copy to Clipboard Toggle word wrap

流程

  1. openshift-config 命名空间中,从 CA 捆绑包创建配置映射:

    $ oc create configmap \
      router-ca-certs-default \
      --from-file=ca-bundle.pem=client-ca.crt \
    1
    
      -n openshift-config
    Copy to Clipboard Toggle word wrap
    1
    配置映射数据键必须是 ca-bundle.pem,数据值必须是 PEM 格式的 CA 证书。
  2. 编辑 openshift-ingress-operator 项目中的 IngressController 资源:

    $ oc edit IngressController default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap
  3. 添加 spec.clientTLS 字段和子字段来配置 mutual TLS:

    指定过滤模式的 clientTLS 配置集的 IngressController CR 示例

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        clientTLS:
          clientCertificatePolicy: Required
          clientCA:
            name: router-ca-certs-default
          allowedSubjectPatterns:
          - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"
    Copy to Clipboard Toggle word wrap

  4. 可选,输入以下命令获取 allowedSubjectPatterns 的可辨识名称 (DN)。

    $ openssl x509 -in custom-cert.pem -noout -subject
    Copy to Clipboard Toggle word wrap

    输出示例

    subject=C=US, ST=NC, O=Security, OU=OpenShift, CN=example.com
    Copy to Clipboard Toggle word wrap

8.4. 查看默认的 Ingress Controller

Ingress Operator 是 OpenShift Container Platform 的一个核心功能,开箱即用。

每个 OpenShift Container Platform 新安装都有一个名为 default 的 ingresscontroller。它可以通过额外的 Ingress Controller 来补充。如果删除了默认的 ingresscontroller,Ingress Operator 会在一分钟内自动重新创建。

流程

  • 查看默认的 Ingress Controller:

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
    Copy to Clipboard Toggle word wrap

8.5. 查看 Ingress Operator 状态

您可以查看并检查 Ingress Operator 的状态。

流程

  • 查看您的 Ingress Operator 状态:

    $ oc describe clusteroperators/ingress
    Copy to Clipboard Toggle word wrap

8.6. 查看 Ingress Controller 日志

您可以查看 Ingress Controller 日志。

流程

  • 查看 Ingress Controller 日志:

    $ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
    Copy to Clipboard Toggle word wrap

8.7. 查看 Ingress Controller 状态

您可以查看特定 Ingress Controller 的状态。

流程

  • 查看 Ingress Controller 的状态:

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
    Copy to Clipboard Toggle word wrap

8.8. 创建自定义 Ingress Controller

作为集群管理员,您可以创建新的自定义 Ingress Controller。因为默认 Ingress Controller 在 OpenShift Container Platform 更新过程中可能会改变,所以创建自定义 Ingress Controller 以在集群更新中手动保留配置会很有用。

这个示例为自定义 Ingress Controller 提供最小规格。要进一步定制您的自定义 Ingress Controller,请参阅"配置 Ingress Controller"。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 创建定义自定义 IngressController 对象的 YAML 文件:

    custom-ingress-controller.yaml 文件示例

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
        name: <custom_name> 
    1
    
        namespace: openshift-ingress-operator
    spec:
        defaultCertificate:
            name: <custom-ingress-custom-certs> 
    2
    
        replicas: 1 
    3
    
        domain: <custom_domain> 
    4
    Copy to Clipboard Toggle word wrap

    1
    IngressController 对象指定自定义名称
    2
    使用自定义通配符证书指定 secret 名称。
    3
    最小副本需要是 ONE
    4
    指定您的域名的域。IngressController 对象中指定的域以及用于证书的域必须匹配。例如,如果 domain 值为 "custom_domain.mycompany.com",则证书必须具有 SAN *.custom_domain.mycompany.com(在域中添加了 *.)。
  2. 运行以下命令来创建对象:

    $ oc create -f custom-ingress-controller.yaml
    Copy to Clipboard Toggle word wrap

8.9. 配置 Ingress Controller

8.9.1. 设置自定义默认证书

作为管理员,您可以通过创建 Secret 资源并编辑 IngressController 自定义资源 (CR),将 Ingress Controller 配置为使用自定义证书。

先决条件

  • 您必须在 PEM 编码文件中有一个证书/密钥对,其中该证书由可信证书认证机构签名,或者由您在一个自定义 PKI 中配置的私有可信证书认证机构签名。
  • 您的证书满足以下要求:

    • 该证书对入口域有效。
    • 证书使用 subjectAltName 扩展来指定通配符域,如 *.apps.ocp4.example.com
  • 您必须有一个 IngressController CR,它仅包含 默认的 IngressController CR。您可以运行以下命令来检查是否有 IngressController CR:

    $ oc --namespace openshift-ingress-operator get ingresscontrollers
    Copy to Clipboard Toggle word wrap
注意

如果您有中间证书,则必须将其包含在包含自定义默认证书的 secret 的 tls.crt 文件中。指定证书时指定的顺序是相关的; 在任意服务器证书后列出您的中间证书。

流程

以下步骤假定自定义证书和密钥对位于当前工作目录下的 tls.crttls.key 文件中。替换 tls.crttls.key 的实际路径名。在创建 Secret 资源并在 IngressController CR 中引用它时,您也可以将 custom-certs-default 替换成另一名称。

注意

此操作会导致使用滚动部署策略重新部署 Ingress Controller。

  1. 使用 tls.crttls.key 文件,创建在 openshift-ingress 命名空间中包含自定义证书的 Secret 资源。

    $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
    Copy to Clipboard Toggle word wrap
  2. 更新 IngressController CR,以引用新的证书 Secret:

    $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
      --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
    Copy to Clipboard Toggle word wrap
  3. 验证更新是否已生效:

    $ echo Q |\
      openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
      openssl x509 -noout -subject -issuer -enddate
    Copy to Clipboard Toggle word wrap

    其中:

    <domain>
    指定集群的基域名。

    输出示例

    subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
    issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
    notAfter=May 10 08:32:45 2022 GM
    Copy to Clipboard Toggle word wrap

    提示

    您还可以应用以下 YAML 来设置自定义默认证书:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      defaultCertificate:
        name: custom-certs-default
    Copy to Clipboard Toggle word wrap

    证书 Secret 名称应该与用来更新 CR 的值匹配。

修改了 IngressController CR 后,Ingress Operator 将更新 Ingress Controller 的部署以使用自定义证书。

8.9.2. 删除自定义默认证书

作为管理员,您可以删除配置了 Ingress Controller 的自定义证书。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您之前为 Ingress Controller 配置了自定义默认证书。

流程

  • 要删除自定义证书并恢复 OpenShift Container Platform 附带的证书,请输入以下命令:

    $ oc patch -n openshift-ingress-operator ingresscontrollers/default \
      --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
    Copy to Clipboard Toggle word wrap

    集群协调新证书配置时可能会有延迟。

验证

  • 要确认原始集群证书已被恢复,请输入以下命令:

    $ echo Q | \
      openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
      openssl x509 -noout -subject -issuer -enddate
    Copy to Clipboard Toggle word wrap

    其中:

    <domain>
    指定集群的基域名。

    输出示例

    subject=CN = *.apps.<domain>
    issuer=CN = ingress-operator@1620633373
    notAfter=May 10 10:44:36 2023 GMT
    Copy to Clipboard Toggle word wrap

8.9.3. 自动扩展 Ingress Controller

您可以自动缩放 Ingress Controller 以动态满足路由性能或可用性要求,如提高吞吐量的要求。

以下流程提供了一个扩展默认 Ingress Controller 的示例。

先决条件

  • 已安装 OpenShift CLI (oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问 OpenShift Container Platform 集群。
  • 已安装自定义 Metrics Autoscaler Operator 和关联的 KEDA Controller。

    • 您可以在 Web 控制台中使用 OperatorHub 安装 Operator。安装 Operator 后,您可以创建 KedaController 实例。

流程

  1. 运行以下命令,创建一个服务帐户来与 Thanos 进行身份验证:

    $ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
    Copy to Clipboard Toggle word wrap

    输出示例

    Name:                thanos
    Namespace:           openshift-ingress-operator
    Labels:              <none>
    Annotations:         <none>
    Image pull secrets:  thanos-dockercfg-kfvf2
    Mountable secrets:   thanos-dockercfg-kfvf2
    Tokens:              <none>
    Events:              <none>
    Copy to Clipboard Toggle word wrap

  2. 使用以下命令手动创建服务帐户令牌:

    $ oc apply -f - <<EOF
    apiVersion: v1
    kind: Secret
    metadata:
      name: thanos-token
      namespace: openshift-ingress-operator
      annotations:
        kubernetes.io/service-account.name: thanos
    type: kubernetes.io/service-account-token
    EOF
    Copy to Clipboard Toggle word wrap
  3. 使用服务帐户的令牌,在 openshift-ingress-operator 命名空间中定义一个 TriggerAuthentication 对象。

    1. 创建 TriggerAuthentication 对象,并将 secret 变量的值传递给 TOKEN 参数:

      $ oc apply -f - <<EOF
      apiVersion: keda.sh/v1alpha1
      kind: TriggerAuthentication
      metadata:
        name: keda-trigger-auth-prometheus
        namespace: openshift-ingress-operator
      spec:
        secretTargetRef:
        - parameter: bearerToken
          name: thanos-token
          key: token
        - parameter: ca
          name: thanos-token
          key: ca.crt
      EOF
      Copy to Clipboard Toggle word wrap
  4. 创建并应用角色以从 Thanos 读取指标:

    1. 创建一个新角色 thanos-metrics-reader.yaml,从 pod 和节点读取指标:

      thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
        namespace: openshift-ingress-operator
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        - nodes
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来应用新角色:

      $ oc apply -f thanos-metrics-reader.yaml
      Copy to Clipboard Toggle word wrap
  5. 输入以下命令在服务帐户中添加新角色:

    $ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
    Copy to Clipboard Toggle word wrap
    $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
    Copy to Clipboard Toggle word wrap
    注意

    只有在使用跨命名空间查询时,才需要参数 add-cluster-role-to-user。以下步骤使用 kube-metrics 命名空间中的查询,该命名空间需要此参数。

  6. 创建一个新的 ScaledObject YAML 文件 ingress-autoscaler.yaml,该文件以默认 Ingress Controller 部署为目标:

    ScaledObject 定义示例

    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    metadata:
      name: ingress-scaler
      namespace: openshift-ingress-operator
    spec:
      scaleTargetRef: 
    1
    
        apiVersion: operator.openshift.io/v1
        kind: IngressController
        name: default
        envSourceContainerName: ingress-operator
      minReplicaCount: 1
      maxReplicaCount: 20 
    2
    
      cooldownPeriod: 1
      pollingInterval: 1
      triggers:
      - type: prometheus
        metricType: AverageValue
        metadata:
          serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 
    3
    
          namespace: openshift-ingress-operator 
    4
    
          metricName: 'kube-node-role'
          threshold: '1'
          query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' 
    5
    
          authModes: "bearer"
        authenticationRef:
          name: keda-trigger-auth-prometheus
    Copy to Clipboard Toggle word wrap

    1
    要目标的自定义资源。在本例中,Ingress Controller。
    2
    可选:最大副本数。如果省略此字段,则默认最大值设置为 100 个副本。
    3
    openshift-monitoring 命名空间中的 Thanos 服务端点。
    4
    Ingress Operator 命名空间。
    5
    此表达式评估为,部署的集群中存在很多 worker 节点。
    重要

    如果使用跨命名空间查询,您必须在 serverAddress 字段中目标端口 9091 而不是端口 9092。您还必须有升级的特权,才能从此端口读取指标。

  7. 运行以下命令来应用自定义资源定义:

    $ oc apply -f ingress-autoscaler.yaml
    Copy to Clipboard Toggle word wrap

验证

  • 运行以下命令,验证默认 Ingress Controller 是否已扩展以匹配 kube-state-metrics 查询返回的值:

    • 使用 grep 命令搜索 Ingress Controller YAML 文件以查找副本数量:

      $ oc get -n openshift-ingress-operator ingresscontroller/default -o yaml | grep replicas:
      Copy to Clipboard Toggle word wrap
    • 获取 openshift-ingress 项目中的 pod:

      $ oc get pods -n openshift-ingress
      Copy to Clipboard Toggle word wrap

      输出示例

      NAME                             READY   STATUS    RESTARTS   AGE
      router-default-7b5df44ff-l9pmm   2/2     Running   0          17h
      router-default-7b5df44ff-s5sl5   2/2     Running   0          3d22h
      router-default-7b5df44ff-wwsth   2/2     Running   0          66s
      Copy to Clipboard Toggle word wrap

8.9.4. 扩展 Ingress Controller

手动扩展 Ingress Controller 以满足路由性能或可用性要求,如提高吞吐量的要求。oc 命令用于扩展 IngressController 资源。以下流程提供了扩展默认 IngressController 的示例。

注意

扩展不是立刻就可以完成的操作,因为它需要时间来创建所需的副本数。

流程

  1. 查看默认 IngressController 的当前可用副本数:

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    Copy to Clipboard Toggle word wrap
  2. 使用 oc patch 命令将默认 IngressController 扩展到所需的副本数。以下示例将默认 IngressController 扩展到 3 个副本。

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
    Copy to Clipboard Toggle word wrap
  3. 验证默认 IngressController 是否已扩展至您指定的副本数:

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    Copy to Clipboard Toggle word wrap
    提示

    您还可以应用以下 YAML 将 Ingress Controller 扩展为三个副本:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 3               
    1
    Copy to Clipboard Toggle word wrap
    1
    如果需要不同数量的副本,请更改 replicas 值。

8.9.5. 配置 Ingress 访问日志

您可以配置 Ingress Controller 以启用访问日志。如果您的集群没有接收许多流量,那么您可以将日志记录到 sidecar。如果您的集群接收大量流量,为了避免超出日志记录堆栈的容量,或与 OpenShift Container Platform 之外的日志记录基础架构集成,您可以将日志转发到自定义 syslog 端点。您还可以指定访问日志的格式。

当不存在 Syslog 日志记录基础架构时,容器日志记录可用于在低流量集群中启用访问日志,或者在诊断 Ingress Controller 时进行简短使用。

对于访问日志可能会超过 OpenShift Logging 堆栈容量的高流量集群,或需要任何日志记录解决方案与现有 Syslog 日志记录基础架构集成的环境,则需要 syslog。Syslog 用例可能会相互重叠。

先决条件

  • 以具有 cluster-admin 特权的用户身份登录。

流程

配置 Ingress 访问日志到 sidecar。

  • 要配置 Ingress 访问日志记录,您必须使用 spec.logging.access.destination 指定一个目的地。要将日志记录指定到 sidecar 容器,您必须指定 Container spec.logging.access.destination.type。以下示例是将日志记录到 Container 目的地的 Ingress Controller 定义:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Container
    Copy to Clipboard Toggle word wrap
  • 当将 Ingress Controller 配置为日志记录到 sidecar 时,Operator 会在 Ingress Controller Pod 中创建一个名为 logs 的容器:

    $ oc -n openshift-ingress logs deployment.apps/router-default -c logs
    Copy to Clipboard Toggle word wrap

    输出示例

    2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"
    Copy to Clipboard Toggle word wrap

配置 Ingress 访问日志记录到 Syslog 端点。

  • 要配置 Ingress 访问日志记录,您必须使用 spec.logging.access.destination 指定一个目的地。要将日志记录指定到 Syslog 端点目的地,您必须为 spec.logging.access.destination.type 指定 Syslog。如果目的地类型是 Syslog,还必须使用 spec.logging.access.destination.syslog.address 指定目标端点,您可以使用 spec.logging.access.destination.syslog.facility 指定一个工具。以下示例是将日志记录到 Syslog 目的地的 Ingress Controller 定义:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              port: 10514
    Copy to Clipboard Toggle word wrap
    注意

    Syslog 目的地端口必须是 UDP。

    syslog 目标地址必须是 IP 地址。它不支持 DNS 主机名。

使用特定的日志格式配置 Ingress 访问日志。

  • 您可以指定 spec.logging.access.httpLogFormat 来自定义日志格式。以下示例是一个 Ingress Controller 定义,它将日志记录到 IP 地址为 1.2.3.4、端口为 10514 的 syslog 端点:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              port: 10514
          httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'
    Copy to Clipboard Toggle word wrap

禁用 Ingress 访问日志。

  • 要禁用 Ingress 访问日志,请保留 spec.loggingspec.logging.access 为空:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access: null
    Copy to Clipboard Toggle word wrap

允许 Ingress Controller 在使用 sidecar 时,修改 HAProxy 日志长度。

  • 如果您使用 spec.logging.access.destination.syslog.maxLength,请使用 spec.logging.access.destination.type: Syslog

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              maxLength: 4096
              port: 10514
    Copy to Clipboard Toggle word wrap
  • 如果您使用 spec.logging.access.destination.container.maxLength,请使用 spec.logging.access.destination.type: Container

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            container:
              maxLength: 8192
            type: Container
          httpCaptureHeaders:
            request:
            - maxLength: 128
              name: X-Forwarded-For
    Copy to Clipboard Toggle word wrap
  • 要使用 Ingress 访问日志中的 X-Forwarded-For 标头查看原始客户端源 IP 地址,请参阅 Ingress 和 Application Logs 中的 X-Forwarded-For Header 中的 X-Forwarded-For Header 中的 "Capturing Original Client IP 地址。

8.9.6. 设置 Ingress Controller 线程数

集群管理员可设置线程数,以增加集群可以处理的入站的连接量。您可以修补现有的 Ingress Controller 来增加线程量。

先决条件

  • 以下假设您已创建了 Ingress Controller。

流程

  • 更新 Ingress Controller 以增加线程数量:

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
    Copy to Clipboard Toggle word wrap
    注意

    如果您的节点有能力运行大量资源,您可以使用与预期节点容量匹配的标签配置 spec.nodePlacement.nodeSelector,并将 spec.tuningOptions.threadCount 配置为一个适当的高值。

当在云平台上创建 Ingress Controller 时,Ingress Controller 默认由一个公共云负载均衡器发布。作为管理员,您可以创建一个使用内部云负载均衡器的 Ingress Controller。

警告

如果云供应商是 Microsoft Azure,则必须至少有一个指向节点的公共负载均衡器。如果不这样做,所有节点都将丢失到互联网的出站连接。

重要

如果要更改 IngressControllerscope,您可以在创建自定义资源(CR)后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。

图 8.1. LoadBalancer 图表

上图显示了与 OpenShift Container Platform Ingress LoadBalancerService 端点发布策略相关的以下概念:

  • 您可以使用 OpenShift Ingress Controller Load Balancer 在外部使用云供应商负载均衡器或内部加载负载。
  • 您可以使用负载均衡器的单个 IP 地址以及更熟悉的端口,如 8080 和 4200,如图形中所述的集群所示。
  • 来自外部负载均衡器的流量定向到 pod,并由负载均衡器管理,如下节点的实例中所述。有关实现详情请查看 Kubernetes 服务文档

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在名为 <name>-ingress-controller.yaml 的文件中创建 IngressController 自定义资源 (CR) ,如下例所示:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: <name> 
    1
    
    spec:
      domain: <domain> 
    2
    
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal 
    3
    Copy to Clipboard Toggle word wrap
    1
    <name> 替换为 IngressController 对象的名称。
    2
    指定控制器发布的应用程序的 domain
    3
    指定一个 Internal 值以使用内部负载均衡器。
  2. 运行以下命令,创建上一步中定义的 Ingress Controller:

    $ oc create -f <name>-ingress-controller.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    <name> 替换为 IngressController 对象的名称。
  3. 可选:通过运行以下命令确认创建了 Ingress Controller:

    $ oc --all-namespaces=true get ingresscontrollers
    Copy to Clipboard Toggle word wrap

8.9.8. 在 GCP 上为 Ingress Controller 配置全局访问

在带有一个内部负载均衡器的 GCP 上创建的 Ingress Controller 会为服务生成一个内部 IP 地址。集群管理员可指定全局访问选项,该选项可启用同一 VPC 网络内任何区域中的客户端作为负载均衡器,以访问集群上运行的工作负载。

如需更多信息,请参阅 GCP 文档以了解全局访问

先决条件

  • 您已在 GCP 基础架构上部署了 OpenShift Container Platform 集群。
  • 已将 Ingress Controller 配置为使用内部负载均衡器。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 配置 Ingress Controller 资源,以允许全局访问。

    注意

    您还可以创建 Ingress Controller 并指定全局访问选项。

    1. 配置 Ingress Controller 资源:

      $ oc -n openshift-ingress-operator edit ingresscontroller/default
      Copy to Clipboard Toggle word wrap
    2. 编辑 YAML 文件:

      clientAccess 配置为 Global 的示例

        spec:
          endpointPublishingStrategy:
            loadBalancer:
              providerParameters:
                gcp:
                  clientAccess: Global 
      1
      
                type: GCP
              scope: Internal
            type: LoadBalancerService
      Copy to Clipboard Toggle word wrap

      1
      gcp.clientAccess 设置为 Global
    3. 保存文件以使改变生效。
  2. 运行以下命令,以验证该服务是否允许全局访问:

    $ oc -n openshift-ingress edit svc/router-default -o yaml
    Copy to Clipboard Toggle word wrap

    输出显示,全局访问已为带有注解 networking.gke.io/internal-load-balancer-allow-global-access 的 GCP 启用。

8.9.9. 设置 Ingress Controller 健康检查间隔

集群管理员可以设置健康检查间隔,以定义路由器在两个连续健康检查之间等待的时间。这个值会作为所有路由的默认值进行全局应用。默认值为 5 秒。

先决条件

  • 以下假设您已创建了 Ingress Controller。

流程

  • 更新 Ingress Controller,以更改后端健康检查之间的间隔:

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
    Copy to Clipboard Toggle word wrap
    注意

    要覆盖单个路由的 healthCheckInterval,请使用路由注解 router.openshift.io/haproxy.health.check.interval

您可以通过删除并重新它来将默认 Ingress Controller 配置为内部。

警告

如果云供应商是 Microsoft Azure,则必须至少有一个指向节点的公共负载均衡器。如果不这样做,所有节点都将丢失到互联网的出站连接。

重要

如果要更改 IngressControllerscope,您可以在创建自定义资源(CR)后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 通过删除并重新创建集群,将 默认 Ingress Controller 配置为内部。

    $ oc replace --force --wait --filename - <<EOF
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: default
    spec:
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal
    EOF
    Copy to Clipboard Toggle word wrap

8.9.11. 配置路由准入策略

管理员和应用程序开发人员可在多个命名空间中运行具有相同域名的应用程序。这是针对多个团队开发的、在同一个主机名上公开的微服务的机构。

警告

只有在命名空间间有信任的集群才会启用跨命名空间之间的声明,否则恶意用户可能会接管主机名。因此,默认的准入策略不允许在命名空间间声明主机名。

先决条件

  • 必须具有集群管理员权限。

流程

  • 使用以下命令编辑 ingresscontroller 资源变量的.spec. routeAdmission 字段:

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

    Ingress 控制器配置参数

    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    ...
    Copy to Clipboard Toggle word wrap

    提示

    您还可以应用以下 YAML 来配置路由准入策略:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    Copy to Clipboard Toggle word wrap

8.9.12. 使用通配符路由

HAProxy Ingress Controller 支持通配符路由。Ingress Operator 使用 wildcardPolicy 来配置 Ingress Controller 的 ROUTER_ALLOW_WILDCARD_ROUTES 环境变量。

Ingress Controller 的默认行为是接受采用 None 通配符策略的路由,该策略与现有 IngressController 资源向后兼容。

流程

  1. 配置通配符策略。

    1. 使用以下命令来编辑 IngressController 资源:

      $ oc edit IngressController
      Copy to Clipboard Toggle word wrap
    2. spec 下,将 wildcardPolicy 字段设置 为 WildcardsDisallowedWildcardsAllowed

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
      Copy to Clipboard Toggle word wrap

8.9.13. HTTP 标头配置

OpenShift Container Platform 提供了不同的使用 HTTP 标头的方法。在设置或删除标头时,您可以使用 Ingress Controller 中的特定字段或单独的路由来修改请求和响应标头。您还可以使用路由注解设置某些标头。配置标头的各种方法在协同工作时可能会带来挑战。

注意

您只能在 IngressControllerRoute CR 中设置或删除标头,您无法附加它们。如果使用值设置 HTTP 标头,则该值必须已完成,且在以后不需要附加。在附加标头(如 X-Forwarded-For 标头)时,请使用 spec.httpHeaders.forwardedHeaderPolicy 字段,而不是 spec.httpHeaders.actions

8.9.13.1. 优先级顺序

当在 Ingress Controller 和路由中修改相同的 HTTP 标头时,HAProxy 会根据它是请求还是响应标头来优先选择操作。

  • 对于 HTTP 响应标头,Ingress Controller 中指定的操作会在路由中指定的操作后执行。这意味着 Ingress Controller 中指定的操作具有优先权。
  • 对于 HTTP 请求标头,路由中指定的操作会在 Ingress Controller 中指定的操作后执行。这意味着路由中指定的操作具有优先权。

例如,集群管理员使用以下配置设置 X-Frame-Options 响应标头,其值为 DENY

IngressController spec 示例

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY
Copy to Clipboard Toggle word wrap

路由所有者设置 Ingress Controller 中设置的相同响应标头,但使用以下配置值 SAMEORIGIN

Route 规格示例

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN
Copy to Clipboard Toggle word wrap

IngressController spec 和 Route spec 都配置 X-Frame-Options 标头时,Ingress Controller 中的全局级别为这个标头设置的值将具有优先权,即使一个特定的路由允许帧。对于请求标头,Route spec 值会覆盖 IngressController spec 值。

发生这个优先级,因为 haproxy.config 文件使用以下逻辑,其中 Ingress Controller 被视为前端,单独的路由被视为后端。应用到前端配置的标头值 DENY 使用后端中设置的值 SAMEORIGIN 覆盖相同的标头:

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'
Copy to Clipboard Toggle word wrap

另外,Ingress Controller 或路由中定义的任何操作都覆盖使用路由注解设置的值。

8.9.13.2. 特殊情况标头

以下标头可能会阻止完全被设置或删除,或者在特定情况下允许:

Expand
表 8.2. 特殊情况标头配置选项
标头名称使用 IngressController spec 进行配置使用 Route 规格进行配置禁止的原因使用其他方法进行配置

proxy

proxy HTTP 请求标头可以通过将标头值注入 HTTP_PROXY 环境变量来利用这个安全漏洞的 CGI 应用程序。proxy HTTP 请求标头也是非标准的,在配置期间容易出错。

主机

当使用 IngressController CR 设置 host HTTP 请求标头时,HAProxy 在查找正确的路由时可能会失败。

strict-transport-security

strict-transport-security HTTP 响应标头已使用路由注解处理,不需要单独的实现。

是: haproxy.router.openshift.io/hsts_header 路由注解

cookieset-cookie

HAProxy 集的 Cookie 用于会话跟踪,用于将客户端连接映射到特定的后端服务器。允许设置这些标头可能会影响 HAProxy 的会话关联,并限制 HAProxy 的 Cookie 的所有权。

是:

  • haproxy.router.openshift.io/disable_cookie 路由注解
  • haproxy.router.openshift.io/cookie_name 路由注解

出于合规的原因,您可以设置或删除某些 HTTP 请求和响应标头。您可以为 Ingress Controller 提供的所有路由或特定路由设置或删除这些标头。

例如,您可能希望将集群中运行的应用程序迁移到使用 mutual TLS,这需要您的应用程序检查 X-Forwarded-Client-Cert 请求标头,但 OpenShift Container Platform 默认 Ingress Controller 提供了一个 X-SSL-Client-Der 请求标头。

以下流程修改 Ingress Controller 来设置 X-Forwarded-Client-Cert 请求标头,并删除 X-SSL-Client-Der 请求标头。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问 OpenShift Container Platform 集群。

流程

  1. 编辑 Ingress Controller 资源:

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
    Copy to Clipboard Toggle word wrap
  2. 将 X-SSL-Client-Der HTTP 请求标头替换为 X-Forwarded-Client-Cert HTTP 请求标头:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      httpHeaders:
        actions: 
    1
    
          request: 
    2
    
          - name: X-Forwarded-Client-Cert 
    3
    
            action:
              type: Set 
    4
    
              set:
               value: "%{+Q}[ssl_c_der,base64]" 
    5
    
          - name: X-SSL-Client-Der
            action:
              type: Delete
    Copy to Clipboard Toggle word wrap
    1
    要在 HTTP 标头上执行的操作列表。
    2
    您要更改的标头类型。在本例中,请求标头。
    3
    您要更改的标头的名称。有关您可以设置或删除的可用标头列表,请参阅 HTTP 标头配置
    4
    在标头中执行的操作类型。此字段可以具有 SetDelete 的值。
    5
    在设置 HTTP 标头时,您必须提供一个 value。该值可以是该标头的可用指令列表中的字符串,如 DENY,也可以是使用 HAProxy 的动态值语法来解释的动态值。在这种情况下,会添加一个动态值。
    注意

    对于 HTTP 响应设置动态标头值,允许示例 fetchers 是 res.hdrssl_c_der。对于 HTTP 请求设置动态标头值,允许示例获取器为 req.hdrssl_c_der。请求和响应动态值都可以使用 lowerbase64 转换器。

  3. 保存文件以使改变生效。

8.9.15. 使用 X-Forwarded 标头

您可以将 HAProxy Ingress Controller 配置为指定如何处理 HTTP 标头的策略,其中包括 ForwardedX-Forwarded-For。Ingress Operator 使用 HTTPHeaders 字段配置 Ingress Controller 的 ROUTER_SET_FORWARDED_HEADERS 环境变量。

流程

  1. 为 Ingress Controller 配置 HTTPHeaders 字段。

    1. 使用以下命令来编辑 IngressController 资源:

      $ oc edit IngressController
      Copy to Clipboard Toggle word wrap
    2. spec 下,将 HTTPHeaders 策略字段设置为 AppendReplaceIfNoneNever:

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append
      Copy to Clipboard Toggle word wrap
8.9.15.1. 使用案例示例

作为集群管理员,您可以:

  • 配置将 X-Forwarded-For 标头注入每个请求的外部代理,然后将其转发到 Ingress Controller。

    要将 Ingress Controller 配置为通过未修改的标头传递,您需要指定 never 策略。然后,Ingress Controller 不会设置标头,应用程序只接收外部代理提供的标头。

  • 将 Ingress Controller 配置为通过未修改的外部代理在外部集群请求上设置 X-Forwarded-For 标头。

    要将 Ingress Controller 配置为在不通过外部代理的内部集群请求上设置 X-Forwarded-For 标头,请指定 if-none 策略。如果 HTTP 请求已经通过外部代理设置了标头,则 Ingress Controller 会保留它。如果缺少标头,因为请求没有通过代理,Ingress Controller 会添加标头。

作为应用程序开发人员,您可以:

  • 配置特定于应用程序的外部代理来注入 X-Forwarded-For 标头。

    要配置 Ingress Controller,以便在不影响其他路由策略的情况下将标头传递到应用程序的路由,请在应用程序的路由上添加注解 haproxy.router.openshift.io/set-forwarded-headers: if-nonehaproxy.router.openshift.io/set-forwarded-headers: never

    注意

    您可以根据每个路由设置 haproxy.router.openshift.io/set-forwarded-headers 注解,独立于 Ingress Controller 的全局设置值。

8.9.16. 在 Ingress Controller 上启用和禁用 HTTP/2

您可以在 HAProxy 中启用或禁用透明端到端的 HTTP/2 连接。此功能使应用程序所有者利用 HTTP/2 协议功能,包括单一连接、标头压缩、二 进制流等等。

您可以为单个 Ingress Controller 或整个集群启用或禁用 HTTP/2 连接。

要在从客户端到 HAProxy 的连接中启用 HTTP/2,路由必须指定一个自定义证书。使用默认证书的路由无法使用 HTTP/2。这一限制是避免连接并发问题(如客户端为使用相同证书的不同路由重新使用连接)所必需的。

从 HAProxy 到应用程序 pod 的连接只能将 HTTP/2 用于 re-encrypt 路由,而不适用于 edge-terminated 或 insecure 路由。存在这个限制的原因是,在与后端协商使用 HTTP/2 时,HAProxy 要使用 ALPN(Application-Level Protocol Negotiation),它是一个 TLS 的扩展。这意味着,端到端的 HTTP/2 适用于 passthrough 和 re-encrypt 路由,而不适用于 edge-terminated 路由。

注意

您可以使用带有不安全路由的 HTTP/2,无论 Ingress Controller 是否启用或禁用了 HTTP/2。

重要

对于非 passthrough 路由,Ingress Controller 会独立于客户端的连接来协商它与应用程序的连接。这意味着,客户端可以连接到 Ingress Controller 并协商 HTTP/1.1,Ingress Controller 可连接到应用程序,协商 HTTP/2 并使用 HTTP/2 连接将客户端 HTTP/1.1 连接转发请求。如果客户端随后试图将其连接从 HTTP/1.1 升级到 WebSocket 协议,这会导致问题。因为 Ingress Controller 无法将 WebSocket 转发到 HTTP/2,也无法将其 HTTP/2 的连接升级到 WebSocket。因此,如果您有一个应用程序旨在接受 WebSocket 连接,则必须允许使用 HTTP/2 协议,或者其它客户端将无法升级到 WebSocket 协议。

8.9.16.1. 启用 HTTP/2

您可以在特定 Ingress Controller 上启用 HTTP/2,也可以为整个集群启用 HTTP/2。

流程

  • 要在特定 Ingress Controller 上启用 HTTP/2,请输入 oc annotate 命令:

    $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true 
    1
    Copy to Clipboard Toggle word wrap
    1
    <ingresscontroller_name> 替换为 Ingress Controller 的名称以启用 HTTP/2。
  • 要为整个集群启用 HTTP/2,请输入 oc annotate 命令:

    $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
    Copy to Clipboard Toggle word wrap
提示

或者,您可以应用以下 YAML 代码来启用 HTTP/2:

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
  annotations:
    ingress.operator.openshift.io/default-enable-http2: "true"
Copy to Clipboard Toggle word wrap
8.9.16.2. 禁用 HTTP/2

您可以在特定 Ingress Controller 上禁用 HTTP/2,也可以为整个集群禁用 HTTP/2。

流程

  • 要在特定 Ingress Controller 上禁用 HTTP/2,请输入 oc annotate 命令:

    $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=false 
    1
    Copy to Clipboard Toggle word wrap
    1
    <ingresscontroller_name> 替换为 Ingress Controller 的名称以禁用 HTTP/2。
  • 要为整个集群禁用 HTTP/2,请输入 oc annotate 命令:

    $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=false
    Copy to Clipboard Toggle word wrap
提示

或者,您可以应用以下 YAML 代码来禁用 HTTP/2:

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
  annotations:
    ingress.operator.openshift.io/default-enable-http2: "false"
Copy to Clipboard Toggle word wrap

8.9.17. 为 Ingress Controller 配置 PROXY 协议

当 Ingress Controller 使用 HostNetworkNodePortServicePrivate 端点发布策略类型时,集群管理员可以配置 PROXY 协议。PROXY 协议使负载均衡器能够为 Ingress Controller 接收的连接保留原始客户端地址。原始客户端地址可用于记录、过滤和注入 HTTP 标头。在默认配置中,Ingress Controller 接收的连接只包含与负载均衡器关联的源地址。

警告

使用 Keepalived Ingress Virtual IP (VIP) 在非云平台上带有安装程序置备的集群的默认 Ingress Controller 不支持 PROXY 协议。

PROXY 协议使负载均衡器能够为 Ingress Controller 接收的连接保留原始客户端地址。原始客户端地址可用于记录、过滤和注入 HTTP 标头。在默认配置中,Ingress Controller 接收的连接只包含与负载均衡器关联的源 IP 地址。

重要

对于 passthrough 路由配置,OpenShift Container Platform 集群中的服务器无法观察原始客户端源 IP 地址。如果您需要知道原始客户端源 IP 地址,请为 Ingress Controller 配置 Ingress 访问日志记录,以便您可以查看客户端源 IP 地址。

对于重新加密和边缘路由,OpenShift Container Platform 路由器设置 ForwardedX-Forwarded-For 标头,以便应用程序工作负载检查客户端源 IP 地址。

如需有关 Ingress 访问日志的更多信息,请参阅"配置 Ingress 访问日志"。

使用 LoadBalancerService 端点发布策略类型时不支持为 Ingress Controller 配置 PROXY 协议。具有这个限制的原因是,当 OpenShift Container Platform 在云平台中运行时,IngressController 指定应使用服务负载均衡器,Ingress Operator 会配置负载均衡器服务,并根据保留源地址的平台要求启用 PROXY 协议。

重要

您必须将 OpenShift Container Platform 和外部负载均衡器配置为使用 PROXY 协议或使用 TCP。

云部署不支持此功能。具有这个限制的原因是,当 OpenShift Container Platform 在云平台中运行时,IngressController 指定应使用服务负载均衡器,Ingress Operator 会配置负载均衡器服务,并根据保留源地址的平台要求启用 PROXY 协议。

重要

您必须将 OpenShift Container Platform 和外部负载均衡器配置为使用 PROXY 协议或使用传输控制协议 (TCP)。

先决条件

  • 已创建一个 Ingress Controller。

流程

  1. 在 CLI 中输入以下命令来编辑 Ingress Controller 资源:

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
    Copy to Clipboard Toggle word wrap
  2. 设置 PROXY 配置:

    • 如果您的 Ingress Controller 使用 HostNetwork 端点发布策略类型,请将 spec.endpointPublishingStrategy.hostNetwork.protocol 子字段设置为 PROXY

      hostNetwork 配置为 PROXY 的示例

      # ...
        spec:
          endpointPublishingStrategy:
            hostNetwork:
              protocol: PROXY
            type: HostNetwork
      # ...
      Copy to Clipboard Toggle word wrap

    • 如果您的 Ingress Controller 使用 NodePortService 端点发布策略类型,请将 spec.endpointPublishingStrategy.nodePort.protocol 子字段设置为 PROXY

      nodePort 配置为 PROXY 示例

      # ...
        spec:
          endpointPublishingStrategy:
            nodePort:
              protocol: PROXY
            type: NodePortService
      # ...
      Copy to Clipboard Toggle word wrap

    • 如果您的 Ingress Controller 使用 Private 端点发布策略类型,请将 spec.endpointPublishingStrategy.private.protocol 子字段设置为 PROXY

      PROXY私有配置示例

      # ...
        spec:
          endpointPublishingStrategy:
            private:
              protocol: PROXY
          type: Private
      # ...
      Copy to Clipboard Toggle word wrap

8.9.18. 使用 appsDomain 选项指定备选集群域

作为集群管理员,您可以通过配置 appsDomain 字段来为用户创建的路由指定默认集群域替代内容。appsDomain 字段是 OpenShift Container Platform 使用的可选域,而不是默认值,它在 domain 字段中指定。如果您指定了其它域,它会覆盖为新路由确定默认主机的目的。

例如,您可以将您公司的 DNS 域用作集群中运行的应用程序的路由和入口的默认域。

先决条件

  • 已部署 OpenShift Container Platform 集群。
  • 已安装 oc 命令行界面。

流程

  1. 通过为用户创建的路由指定备选默认域来配置 appsDomain 字段。

    1. 编辑 ingress 集群资源 :

      $ oc edit ingresses.config/cluster -o yaml
      Copy to Clipboard Toggle word wrap
    2. 编辑 YAML 文件:

      示例 appsDomain 配置为 test.example.com

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            
      1
      
        appsDomain: <test.example.com>      
      2
      Copy to Clipboard Toggle word wrap

      1
      指定默认域。您不能在安装后修改默认域。
      2
      可选:用于应用程序路由的 OpenShift Container Platform 基础架构域。您可以使用 测试 等替代前缀 apps,而不是默认前缀。
  2. 通过公开路由并验证路由域更改,验证现有路由是否包含 appsDomain 字段中指定的域名:

    注意

    在公开路由前,等待 openshift-apiserver 完成滚动更新。

    1. 输入以下命令公开路由。命令输出 route.route.openshift.io/hello-openshift 以指定公开路由。

      $ oc expose service hello-openshift
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令来获取路由列表:

      $ oc get routes
      Copy to Clipboard Toggle word wrap

      输出示例

      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello_openshift-<my_project>.test.example.com
      hello-openshift   8080-tcp                 None
      Copy to Clipboard Toggle word wrap

8.9.19. 转换 HTTP 标头的大小写

默认情况下,HAProxy HTTP 的标头名称是小写的,例如,会将 Host: xyz.com 更改为 host: xyz.com。如果旧应用程序对 HTTP 标头名称中使用大小写敏感,请使用 Ingress Controller spec.httpHeaders.headerNameCaseAdjustments API 字段进行调整来适应旧的应用程序,直到它们被改变。

重要

OpenShift Container Platform 包含 HAProxy 2.8。如果要更新基于 web 的负载均衡器的这个版本,请确保将 spec.httpHeaders.headerNameCaseAdjustments 部分添加到集群的配置文件中。

作为集群管理员,您可以使用 oc patch 命令,或设置 Ingress Controller YAML 文件中的 HeaderNameCaseAdjustments 字段来转换 HTTP 标头的大小写。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  • 使用 oc patch 命令大写 HTTP 标头。

    1. 运行以下命令,将 HTTP 标头从 host 更改为 Host

      $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
      Copy to Clipboard Toggle word wrap
    2. 创建 Route 资源 YAML 文件,以便注解可应用到应用程序。

      名为 my-application 的路由示例

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        annotations:
          haproxy.router.openshift.io/h1-adjust-case: true 
      1
      
        name: <application_name>
        namespace: <application_name>
      # ...
      Copy to Clipboard Toggle word wrap

      1
      设置 haproxy.router.openshift.io/h1-adjust-case,以便 Ingress Controller 能够调整指定的 host 请求标头。
  • 通过在 Ingress Controller YAML 配置文件中配置 HeaderNameCaseAdjustments 字段指定调整。

    1. 以下示例 Ingress Controller YAML 文件将 HTTP/1 请求的 host 标头调整为 Host,以适当地注解路由:

      Ingress Controller YAML 示例

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          headerNameCaseAdjustments:
          - Host
      Copy to Clipboard Toggle word wrap

    2. 以下示例路由中,使用 haproxy.router.openshift.io/h1-adjust-case 注解启用对 HTTP 响应标头名称的大小写调整:

      路由 YAML 示例

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        annotations:
          haproxy.router.openshift.io/h1-adjust-case: true 
      1
      
        name: my-application
        namespace: my-application
      spec:
        to:
          kind: Service
          name: my-application
      Copy to Clipboard Toggle word wrap

      1
      haproxy.router.openshift.io/h1-adjust-case 设置为 true。

8.9.20. 使用路由器压缩

您可以将 HAProxy Ingress Controller 配置为为特定 MIME 类型全局指定路由器压缩。您可以使用 mimeTypes 变量定义压缩应用到的 MIME 类型的格式。类型包括:application, image, message, multipart, text, video, 或带有一个 "X-" 前缀的自定义类型。要查看 MIME 类型和子类型的完整表示法,请参阅 RFC1341

注意

为压缩分配的内存可能会影响最大连接。此外,对大型缓冲区的压缩可能导致延迟,如非常复杂的正则表达式或较长的正则表达式列表。

并非所有 MIME 类型从压缩中受益,但 HAProxy 仍然使用资源在指示时尝试压缩。通常而言,文本格式(如 html、css 和 js)与压缩格式获益,但已经压缩的格式(如图像、音频和视频)可能会因为需要压缩操作而无法获得太多的好处。

流程

  1. 为 Ingress Controller 配置 httpCompression 字段。

    1. 使用以下命令来编辑 IngressController 资源:

      $ oc edit -n openshift-ingress-operator ingresscontrollers/default
      Copy to Clipboard Toggle word wrap
    2. spec 下,将 httpCompression 策略字段设置为 mimeTypes,并指定应该应用压缩的 MIME 类型列表:

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpCompression:
          mimeTypes:
          - "text/html"
          - "text/css; charset=utf-8"
          - "application/json"
         ...
      Copy to Clipboard Toggle word wrap

8.9.21. 公开路由器指标

您可以在默认统计端口 1936 上以 Prometheus 格式公开 HAProxy 路由器指标。外部指标收集和聚合系统(如 Prometheus)可以访问 HAProxy 路由器指标。您可以在浏览器中以 HTML 的形式和以逗号分隔的值 (CSV) 格式查看 HAProxy 路由器指标。

先决条件

  • 您已将防火墙配置为访问默认统计数据端口 1936。

流程

  1. 运行以下命令来获取路由器 pod 名称:

    $ oc get pods -n openshift-ingress
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                              READY   STATUS    RESTARTS   AGE
    router-default-76bfffb66c-46qwp   1/1     Running   0          11h
    Copy to Clipboard Toggle word wrap

  2. 获取路由器的用户名和密码,路由器 Pod 存储在 /var/lib/haproxy/conf/metrics-auth/statsUsername/var/lib/haproxy/conf/metrics-auth/statsPassword 文件中:

    1. 运行以下命令来获取用户名:

      $ oc rsh <router_pod_name> cat metrics-auth/statsUsername
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令来获取密码:

      $ oc rsh <router_pod_name> cat metrics-auth/statsPassword
      Copy to Clipboard Toggle word wrap
  3. 运行以下命令,获取路由器 IP 和指标证书:

    $ oc describe pod <router_pod>
    Copy to Clipboard Toggle word wrap
  4. 运行以下命令,以 Prometheus 格式获取原始统计信息:

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
    Copy to Clipboard Toggle word wrap
  5. 运行以下命令来安全地访问指标:

    $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k
    Copy to Clipboard Toggle word wrap
  6. 运行以下命令,访问默认的 stats 端口 1936:

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
    Copy to Clipboard Toggle word wrap

    例 8.1. 输出示例

    ...
    # HELP haproxy_backend_connections_total Total number of connections.
    # TYPE haproxy_backend_connections_total gauge
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
    ...
    # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
    # TYPE haproxy_exporter_server_threshold gauge
    haproxy_exporter_server_threshold{type="current"} 11
    haproxy_exporter_server_threshold{type="limit"} 500
    ...
    # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_frontend_bytes_in_total gauge
    haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="public"} 119070
    ...
    # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_server_bytes_in_total gauge
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
    haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
    ...
    Copy to Clipboard Toggle word wrap
  7. 通过在浏览器中输入以下 URL 来启动 stats 窗口:

    http://<user>:<password>@<router_IP>:<stats_port>
    Copy to Clipboard Toggle word wrap
  8. 可选:通过在浏览器中输入以下 URL 来获取 CSV 格式的统计信息:

    http://<user>:<password>@<router_ip>:1936/metrics;csv
    Copy to Clipboard Toggle word wrap

8.9.22. 自定义 HAProxy 错误代码响应页面

作为集群管理员,您可以为 503、404 或两个错误页面指定自定义错误代码响应页面。当应用 Pod 没有运行时,HAProxy 路由器会提供一个 503 错误页面,如果请求的 URL 不存在,则 HAProxy 路由器会提供 404 错误页面。例如,如果您自定义 503 错误代码响应页面,则应用 Pod 未运行时会提供页面,并且 HAProxy 路由器为不正确的路由或不存在的路由提供默认的 404 错误代码 HTTP 响应页面。

自定义错误代码响应页面在配置映射中指定,然后修补至 Ingress Controller。配置映射键有两个可用的文件名,如下所示:error-page-503.httperror-page-404.http

自定义 HTTP 错误代码响应页面必须遵循 HAProxy HTTP 错误页面配置指南。以下是默认 OpenShift Container Platform HAProxy 路由器 http 503 错误代码响应页面的示例。您可以使用默认内容作为模板来创建自己的自定义页面。

默认情况下,当应用没有运行或者路由不正确或不存在时,HAProxy 路由器仅提供一个 503 错误页面。此默认行为与 OpenShift Container Platform 4.8 及更早版本中的行为相同。如果没有提供用于自定义 HTTP 错误代码响应的配置映射,且您使用的是自定义 HTTP 错误代码响应页面,路由器会提供默认的 404 或 503 错误代码响应页面。

注意

如果您使用 OpenShift Container Platform 默认 503 错误代码页面作为自定义的模板,文件中的标头需要编辑器而不是使用 CRLF 行结尾。

流程

  1. openshift-config 命名空间中创建一个名为 my-custom-error-code-pages 的配置映射:

    $ oc -n openshift-config create configmap my-custom-error-code-pages \
      --from-file=error-page-503.http \
      --from-file=error-page-404.http
    Copy to Clipboard Toggle word wrap
    重要

    如果没有为自定义错误代码响应页面指定正确的格式,则会出现路由器 pod 中断。要解决此中断,您必须删除或更正配置映射并删除受影响的路由器 pod,以便使用正确的信息重新创建它们。

  2. 对 Ingress Controller 进行补丁以根据名称引用 my-custom-error-code-pages 配置映射:

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

    Ingress Operator 将 my-custom-error-code-pages 配置映射从 openshift-config 命名空间复制到 openshift-ingress 命名空间。Operator 根据 openshift-ingress 命名空间中的模式 <your_ingresscontroller_name>-errorpages 命名配置映射。

  3. 显示副本:

    $ oc get cm default-errorpages -n openshift-ingress
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                       DATA   AGE
    default-errorpages         2      25s  
    1
    Copy to Clipboard Toggle word wrap

    1
    配置映射名称示例为 default-errorpages,因为 default Ingress Controller 自定义资源 (CR) 已被修补。
  4. 确认包含自定义错误响应页面的配置映射挂载到路由器卷中,其中配置映射键是具有自定义 HTTP 错误代码响应的文件名:

    • 对于 503 自定义 HTTP 自定义错误代码响应:

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
      Copy to Clipboard Toggle word wrap
    • 对于 404 自定义 HTTP 自定义错误代码响应:

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
      Copy to Clipboard Toggle word wrap

验证

验证自定义错误代码 HTTP 响应:

  1. 创建测试项目和应用程序:

    $ oc new-project test-ingress
    Copy to Clipboard Toggle word wrap
    $ oc new-app django-psql-example
    Copy to Clipboard Toggle word wrap
  2. 对于 503 自定义 http 错误代码响应:

    1. 停止应用的所有容器集。
    2. 运行以下 curl 命令或在浏览器中访问路由主机名:

      $ curl -vk <route_hostname>
      Copy to Clipboard Toggle word wrap
  3. 对于 404 自定义 http 错误代码响应:

    1. 访问不存在的路由或路由不正确。
    2. 运行以下 curl 命令或在浏览器中访问路由主机名:

      $ curl -vk <route_hostname>
      Copy to Clipboard Toggle word wrap
  4. 检查 haproxy.config 文件中的 errorfile 属性是否正确:

    $ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
    Copy to Clipboard Toggle word wrap

8.9.23. 设置 Ingress Controller 最大连接数

集群管理员可以设置 OpenShift 路由器部署的最大同时连接数。您可以修补现有的 Ingress Controller 来提高最大连接数。

先决条件

  • 以下假设您已创建了 Ingress Controller

流程

  • 更新 Ingress Controller,以更改 HAProxy 的最大连接数:

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
    Copy to Clipboard Toggle word wrap
    警告

    如果您设置了大于当前操作系统的 spec.tuningOptions.maxConnections 值,则 HAProxy 进程不会启动。有关这个参数的更多信息,请参阅"Ingress Controller 配置参数"部分中的表。

Ingress Node Firewall Operator 提供了一个无状态的、基于 eBPF 的防火墙,用于管理 OpenShift Container Platform 中的节点级别的入口流量。

9.1. Ingress Node Firewall Operator

Ingress Node Firewall Operator 通过将守护进程集部署到您在防火墙配置中指定和管理的节点,在节点级别提供入口防火墙规则。要部署守护进程集,请创建一个 IngressNodeFirewallConfig 自定义资源 (CR)。Operator 应用 IngressNodeFirewallConfig CR 来创建入口节点防火墙守护进程集 daemon,它在与 nodeSelector 匹配的所有节点上运行。

您可以配置 IngressNodeFirewall CR 的规则,并使用 nodeSelector 将值设置为 "true" 的集群。

重要

Ingress Node Firewall Operator 仅支持无状态防火墙规则。

不支持原生 XDP 驱动程序的网络接口控制器 (NIC) 将以较低性能运行。

对于 OpenShift Container Platform 4.14 或更高的版本,您必须在 RHEL 9.0 或更高版本上运行 Ingress Node Firewall Operator。

9.2. 安装 Ingress Node Firewall Operator

作为集群管理员,您可以使用 OpenShift Container Platform CLI 或 Web 控制台安装 Ingress Node Firewall Operator。

9.2.1. 使用 CLI 安装 Ingress Node Firewall Operator

作为集群管理员,您可以使用 CLI 安装 Operator。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 有管理员特权的帐户。

流程

  1. 运行以下命令来创建 openshift-ingress-node-firewall 命名空间:

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/enforce-version: v1.24
      name: openshift-ingress-node-firewall
    EOF
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令来创建 OperatorGroup CR:

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: ingress-node-firewall-operators
      namespace: openshift-ingress-node-firewall
    EOF
    Copy to Clipboard Toggle word wrap
  3. 订阅 Ingress Node Firewall Operator。

    1. 要为 Ingress Node Firewall Operator 创建 Subscription CR,请输入以下命令:

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ingress-node-firewall-sub
        namespace: openshift-ingress-node-firewall
      spec:
        name: ingress-node-firewall
        channel: stable
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF
      Copy to Clipboard Toggle word wrap
  4. 要验证是否已安装 Operator,请输入以下命令:

    $ oc get ip -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME            CSV                                         APPROVAL    APPROVED
    install-5cvnz   ingress-node-firewall.4.17.0-202211122336   Automatic   true
    Copy to Clipboard Toggle word wrap

  5. 要验证 Operator 的版本,请输入以下命令:

    $ oc get csv -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
    ingress-node-firewall.4.17.0-202211122336   Ingress Node Firewall Operator   4.17.0-202211122336   ingress-node-firewall.4.17.0-202211102047   Succeeded
    Copy to Clipboard Toggle word wrap

作为集群管理员,您可以使用 Web 控制台安装 Operator。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 有管理员特权的帐户。

流程

  1. 安装 Ingress Node Firewall Operator:

    1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
    2. 从可用的 Operator 列表中选择 Ingress Node Firewall Operator,然后点 Install
    3. Install Operator 页面中,在 Installed Namespace 下选择 Operator recommended Namespace
    4. Install
  2. 验证 Ingress Node Firewall Operator 是否已成功安装:

    1. 导航到 OperatorsInstalled Operators 页面。
    2. 确保 openshift-ingress-node-firewall 项目中列出的 Ingress Node Firewall OperatorStatusInstallSucceeded

      注意

      在安装过程中,Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息,您可以忽略这个 Failed 信息。

      如果 Operator 没有 InstallSucceeded 状态,请按照以下步骤进行故障排除:

      • 检查 Operator SubscriptionsInstall Plans 选项卡中的 Status 项中是否有任何错误。
      • 进入到 WorkloadsPods 页面,在 openshift-ingress-node-firewall 项目中检查 pod 的日志。
      • 检查 YAML 文件的命名空间。如果缺少注解,您可以使用以下命令将注解 workload.openshift.io/allowed=management 添加到 Operator 命名空间中:

        $ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
        Copy to Clipboard Toggle word wrap
        注意

        对于单节点 OpenShift 集群,openshift-ingress-node-firewall 命名空间需要 workload.openshift.io/allowed=management 注解。

9.3. 部署 Ingress Node Firewall Operator

前提条件

  • 已安装 Ingress Node Firewall Operator。

流程

要拒绝 Ingress Node Firewall Operator,请创建一个 IngressNodeFirewallConfig 自定义资源,该资源将部署 Operator 的守护进程集。您可以通过应用防火墙规则,将一个或多个 IngressNodeFirewall CRD 部署到节点。

  1. openshift-ingress-node-firewall 命名空间中创建 IngressNodeFirewallConfig,名为 ingressnodefirewallconfig
  2. 运行以下命令来部署 Ingress Node Firewall Operator 规则:

    $ oc apply -f rule.yaml
    Copy to Clipboard Toggle word wrap

9.3.1. Ingress 节点防火墙配置对象

下表中描述了 Ingress Node Firewall 配置对象的字段:

Expand
表 9.1. Ingress 节点防火墙配置对象
字段类型描述

metadata.name

string

CR 对象的名称。防火墙规则对象的名称必须是 ingressnodefirewallconfig

metadata.namespace

string

Ingress Firewall Operator CR 对象的命名空间。IngressNodeFirewallConfig CR 必须在 openshift-ingress-node-firewall 命名空间中创建。

spec.nodeSelector

string

通过指定节点标签 (label) 用于目标节点的节点选择约束。例如:

spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
Copy to Clipboard Toggle word wrap
注意

nodeSelector 中使用的一个标签必须与节点上的标签匹配,以便守护进程集启动。例如,如果节点标签 node-role.kubernetes.io/workernode-type.kubernetes.io/vm 应用到某个节点,则必须使用 nodeSelector 至少设置一个标签设置来使守护进程启动。

spec.ebpfProgramManagerMode

布尔值

指定 Node Ingress Firewall Operator 是否使用 eBPF Manager Operator,还是不管理 eBPF 程序。这个功能是一个技术预览功能。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

注意

Operator 使用 CR,并在与 nodeSelector 匹配的所有节点上创建一个入口节点防火墙守护进程集。

9.3.2. Ingress Node Firewall Operator 示例配置

以下示例中指定了完整的 Ingress Node 防火墙配置:

Ingress 节点防火墙配置对象示例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
  name: ingressnodefirewallconfig
  namespace: openshift-ingress-node-firewall
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
Copy to Clipboard Toggle word wrap

注意

Operator 使用 CR,并在与 nodeSelector 匹配的所有节点上创建一个入口节点防火墙守护进程集。

9.3.3. Ingress 节点防火墙规则对象

下表中描述了 Ingress Node Firewall 规则对象的字段:

Expand
表 9.2. Ingress 节点防火墙规则对象
字段类型描述

metadata.name

string

CR 对象的名称。

interfaces

数组

此对象的字段指定要应用防火墙规则的接口。例如,- en0- en1

nodeSelector

数组

您可以使用 nodeSelector 来选择节点来应用防火墙规则。将指定 nodeselector 标签的值设置为 true 以应用该规则。

ingress

object

Ingress 允许您配置允许从外部访问集群中的服务的规则。

9.3.3.1. Ingress 对象配置

ingress 对象的值在下表中定义:

Expand
表 9.3. Ingress 对象
字段类型描述

sourceCIDRs

数组

允许您设置 CIDR 块。您可以从不同地址系列配置多个 CIDR。

注意

不同的 CIDR 允许您使用相同的顺序规则。如果同一节点有多个 IngressNodeFirewall 对象,且带有重叠 CIDR 的接口,则 order 字段将指定首先应用该规则。规则以升序应用。

rules

数组

对于每个 source.CIDR,Ingress 防火墙 rules.order 对象的顺序以 1 开始,每个 CIDR 最多 100 个规则。低顺序规则会首先执行。

rules.protocolConfig.protocol 支持以下协议:TCP、UDP、SCTP、ICMP 和 ICMPv6。ICMP 和 ICMPv6 规则可以匹配 ICMP 和 ICMPv6 类型或代码。TCP、UDP 和 SCTP 规则针对单一一个目标端口或一个目标端口范围(格式为 <start : end-1>)进行匹配。

rules.action 设置为 allow 以应用规则,deny 来禁止规则。

注意

Ingress 防火墙规则使用阻止任何无效配置的验证 Webhook 进行验证。验证 Webhook 会阻止阻塞任何关键集群服务,如 API 服务器。

9.3.3.2. Ingress 节点防火墙规则对象示例

以下示例中指定了完整的 Ingress Node 防火墙配置:

Ingress 节点防火墙配置示例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <ingress_firewall_label_name>: <label_value> 
1

  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny
Copy to Clipboard Toggle word wrap

1
节点上必须存在 <label_name> 和 <label_value>,且必须与应用到您希望 ingressfirewallconfig CR 运行的节点的 nodeselector 标签和值匹配。<label_value> 可以是 truefalse。通过使用 nodeSelector 标签,您可以针对单独的节点组为目标,以使用 ingressfirewallconfig CR 应用不同的规则。
9.3.3.3. 零信任 Ingress Node Firewall 规则对象示例

零信任 Ingress 节点防火墙规则可为多接口集群提供额外的安全性。例如,您可以使用零信任 Ingress Node Firewall 规则来丢弃除 SSH 之外的特定接口上的网络流量。

以下示例中指定了零信任 Ingress Node Firewall 规则集的完整配置:

重要

用户需要为其提供应用程序使用的所有端口添加到允许列表,以确保正常工作。

零信任 Ingress 节点防火墙规则示例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
 name: ingressnodefirewall-zero-trust
spec:
 interfaces:
 - eth1 
1

 nodeSelector:
   matchLabels:
     <ingress_firewall_label_name>: <label_value> 
2

 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0 
3

   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny 
4
Copy to Clipboard Toggle word wrap

1
Network-interface 集群
2
<label_name> 和 <label_value> 需要与应用到 ingressfirewallconfig CR 的特定节点的 nodeSelector 标签和值匹配。
3
0.0.0.0/0 匹配任何 CIDR
4
action 设置为 Deny
重要

eBPF Manager Operator 集成只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

9.4. Ingress Node Firewall Operator 集成

Ingress 节点防火墙使用 eBPF 程序来实现其一些关键的防火墙功能。默认情况下,这些 eBPF 程序使用特定于 Ingress 节点防火墙的机制加载到内核中。您可以将 Ingress Node Firewall Operator 配置为使用 eBPF Manager Operator 来加载和管理这些程序。

当启用此集成时,会有以下限制:

  • 如果 XDP 不可用,Ingress Node Firewall Operator 使用 TCX,而 TCX 与 bpfman 不兼容。
  • Ingress Node Firewall Operator 守护进程集 pod 会保持在 ContainerCreating 状态,直到应用防火墙规则为止。
  • Ingress Node Firewall Operator 守护进程设置 pod 以特权运行。

Ingress 节点防火墙使用 eBPF 程序来实现其一些关键的防火墙功能。默认情况下,这些 eBPF 程序使用特定于 Ingress 节点防火墙的机制加载到内核中。

作为集群管理员,您可以将 Ingress Node Firewall Operator 配置为使用 eBPF Manager Operator 来加载和管理这些程序,这会添加额外的安全性和可观察性功能。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 有管理员特权的帐户。
  • 已安装 Ingress Node Firewall Operator。
  • 已安装 eBPF Manager Operator。

流程

  1. 将以下标签应用到 ingress-node-firewall-system 命名空间:

    $ oc label namespace openshift-ingress-node-firewall \
        pod-security.kubernetes.io/enforce=privileged \
        pod-security.kubernetes.io/warn=privileged --overwrite
    Copy to Clipboard Toggle word wrap
  2. 编辑名为 ingressnodefirewallconfigIngressNodeFirewallConfig 对象并设置 ebpfProgramManagerMode 字段:

    Ingress Node Firewall Operator 配置对象

    apiVersion: ingressnodefirewall.openshift.io/v1alpha1
    kind: IngressNodeFirewallConfig
    metadata:
      name: ingressnodefirewallconfig
      namespace: openshift-ingress-node-firewall
    spec:
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      ebpfProgramManagerMode: <ebpf_mode>
    Copy to Clipboard Toggle word wrap

    其中:

    <ebpf_mode> : 指定 Ingress Node Firewall Operator 是否使用 eBPF Manager Operator 来管理 eBPF 程序。必须为 truefalse。如果未设置,则不会使用 eBPF Manager。

9.6. 查看 Ingress Node Firewall Operator 规则

流程

  1. 运行以下命令来查看所有当前规则:

    $ oc get ingressnodefirewall
    Copy to Clipboard Toggle word wrap
  2. 选择返回的 <resource> 名称之一,并运行以下命令来查看规则或配置:

    $ oc get <resource> <name> -o yaml
    Copy to Clipboard Toggle word wrap

9.7. 对 Ingress Node Firewall Operator 进行故障排除

  • 运行以下命令列出已安装的 Ingress Node Firewall 自定义资源定义 (CRD):

    $ oc get crds | grep ingressnodefirewall
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    ingressnodefirewallconfigs.ingressnodefirewall.openshift.io       2022-08-25T10:03:01Z
    ingressnodefirewallnodestates.ingressnodefirewall.openshift.io    2022-08-25T10:03:00Z
    ingressnodefirewalls.ingressnodefirewall.openshift.io             2022-08-25T10:03:00Z
    Copy to Clipboard Toggle word wrap

  • 运行以下命令,以查看 Ingress Node Firewall Operator 的状态:

    $ oc get pods -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                       READY  STATUS         RESTARTS  AGE
    ingress-node-firewall-controller-manager   2/2    Running        0         5d21h
    ingress-node-firewall-daemon-pqx56         3/3    Running        0         5d21h
    Copy to Clipboard Toggle word wrap

    以下字段提供有关 Operator 状态的信息: READYSTATUSAGE、和 RESTARTS。当 Ingress Node Firewall Operator 将守护进程集部署到分配的节点时,STATUS 字段为 Running

  • 运行以下命令来收集所有入口防火墙节点 pod 的日志:

    $ oc adm must-gather – gather_ingress_node_firewall
    Copy to Clipboard Toggle word wrap

    在 sos 节点的报告中,其中包含位于 /sos_commands/ebpf 的 eBPF bpftool 输出的报告。这些报告包括用于或作为入口防火墙 XDP 处理数据包处理、更新统计信息和发出事件的查找表。

第 10 章 SR-IOV Operator

10.1. 安装 SR-IOV Network Operator

您可以在集群上安装单根 I/O 虚拟化(SR-IOV)网络 Operator,以管理 SR-IOV 网络设备和网络附加。

10.1.1. 安装 SR-IOV Network Operator

作为集群管理员,您可以使用 OpenShift Container Platform CLI 或 Web 控制台安装单根 I/O 虚拟化(SR-IOV) Network Operator。

10.1.1.1. CLI:安装 SR-IOV Network Operator

作为集群管理员,您可以使用 CLI 安装 Operator。

先决条件

  • 在裸机环境中安装的集群,其中的节点带有支持 SR-IOV 的硬件。
  • 安装 OpenShift CLI(oc)。
  • 具有 cluster-admin 特权的帐户。

流程

  1. 输入以下命令创建 openshift-sriov-network-operator 命名空间:

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sriov-network-operator
      annotations:
        workload.openshift.io/allowed: management
    EOF
    Copy to Clipboard Toggle word wrap
  2. 输入以下命令来创建 OperatorGroup 自定义资源 (CR):

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sriov-network-operators
      namespace: openshift-sriov-network-operator
    spec:
      targetNamespaces:
      - openshift-sriov-network-operator
    EOF
    Copy to Clipboard Toggle word wrap
  3. 输入以下命令为 SR-IOV Network Operator 创建 Subscription CR:

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sriov-network-operator-subscription
      namespace: openshift-sriov-network-operator
    spec:
      channel: stable
      name: sriov-network-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    EOF
    Copy to Clipboard Toggle word wrap
  4. 输入以下命令来创建 SriovoperatorConfig 资源:

    $ cat <<EOF | oc create -f -
    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableInjector: true
      enableOperatorWebhook: true
      logLevel: 2
      disableDrain: false
    EOF
    Copy to Clipboard Toggle word wrap

验证

  • 要验证是否已安装 Operator,请输入以下命令,然后检查 Operator 的输出显示 Succeeded

    $ oc get csv -n openshift-sriov-network-operator \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap
10.1.1.2. web 控制台:安装 SR-IOV Network Operator

作为集群管理员,您可以使用 Web 控制台安装 Operator。

先决条件

  • 在裸机环境中安装的集群,其中的节点带有支持 SR-IOV 的硬件。
  • 安装 OpenShift CLI(oc)。
  • 具有 cluster-admin 特权的帐户。

流程

  1. 安装 SR-IOV Network Operator:

    1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
    2. 从可用的 Operators 列表中选择 SR-IOV Network Operator,然后点击 Install
    3. Install Operator 页面中,在 Installed Namespace 下选择 Operator recommended Namespace
    4. Install
  2. 验证 SR-IOV Network Operator 是否已成功安装:

    1. 导航到 OperatorsInstalled Operators 页面。
    2. 确保 SR-IOV Network Operatoropenshift-sriov-network-operator 项目中列出,状态InstallSucceeded

      注意

      在安装过程中,Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息,您可以忽略这个 Failed 信息。

      如果 Operator 没有被成功安装,请按照以下步骤进行故障排除:

      • 检查 Operator SubscriptionsInstall Plans 选项卡中的 Status 项中是否有任何错误。
      • 进入 WorkloadsPods 页面,在 openshift-sriov-network-operator 项目中检查 pod 的日志。
      • 检查 YAML 文件的命名空间。如果缺少注解,您可以使用以下命令将注解 workload.openshift.io/allowed=management 添加到 Operator 命名空间中:

        $ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
        Copy to Clipboard Toggle word wrap
        注意

        对于单节点 OpenShift 集群,命名空间需要注解 workload.openshift.io/allowed=management

10.1.2. 后续步骤

10.2. 配置 SR-IOV Network Operator

Single Root I/O Virtualization(SR-IOV)Network Operator 管理集群中的 SR-IOV 网络设备和网络附加。

10.2.1. 配置 SR-IOV Network Operator

  • 创建一个 SriovOperatorConfig 自定义资源 (CR) 以部署所有 SR-IOV Operator 组件:

    1. 使用以下 YAML 创建名为 sriovOperatorConfig.yaml 的文件:

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovOperatorConfig
      metadata:
        name: default 
      1
      
        namespace: openshift-sriov-network-operator
      spec:
        disableDrain: false
        enableInjector: true 
      2
      
        enableOperatorWebhook: true 
      3
      
        logLevel: 2
        featureGates:
          metricsExporter: false
      Copy to Clipboard Toggle word wrap
      1
      SriovOperatorConfig 资源的唯一有效名称是 default,它必须位于部署 Operator 的命名空间中。
      2
      enableInjector 字段如果没有在 CR 中指定或明确设置为 true,则默认为 false<none>,这会防止任何 network-resources-injector pod 在命名空间中运行。建议的设置为 true
      3
      enableOperatorWebhook 字段如果没有在 CR 中指定或明确设置为 true,则默认为 false<none>,这会防止任何 operator-webhook pod 在命名空间中运行。建议的设置为 true
    2. 运行以下命令来创建资源:

      $ oc apply -f sriovOperatorConfig.yaml
      Copy to Clipboard Toggle word wrap
10.2.1.1. SR-IOV Network Operator 配置自定义资源

sriovoperatorconfig 自定义资源的字段在下表中描述:

Expand
表 10.1. SR-IOV Network Operator 配置自定义资源
字段类型描述

metadata.name

string

指定 SR-IOV Network Operator 实例的名称。默认值为 default。不要设置不同的值。

metadata.namespace

string

指定 SR-IOV Network Operator 实例的命名空间。默认值为 openshift-sriov-network-operator。不要设置不同的值。

spec.configDaemonNodeSelector

string

指定在所选节点上调度 SR-IOV 网络配置守护进程的节点选择。默认情况下,此字段没有设置,Operator 会在 worker 节点上部署 SR-IOV 网络配置守护进程集。

spec.disableDrain

布尔值

指定是否禁用节点排空过程,或者在应用新策略在节点上配置 NIC 时启用节点排空过程。将此字段设置为 true 可促进软件开发,并在单一节点上安装 OpenShift Container Platform。默认情况下不设置此字段。

对于单节点集群,在安装 Operator 后将此字段设置为 true。此字段必须保持设为 true

spec.enableInjector

布尔值

指定是否启用或禁用 Network Resources Injector 守护进程集。

spec.enableOperatorWebhook

布尔值

指定是否启用或禁用 Operator Admission Controller webhook 守护进程集。

spec.logLevel

整数

指定 Operator 的日志详细程度。默认情况下,此字段设置为 0,它只显示基本日志。设置为 2,以显示所有可用的日志。

spec.featureGates

map[string]bool

指定是否启用或禁用可选功能。例如,metricsExporter

spec.featureGates.metricsExporter

布尔值

指定是否启用或禁用 SR-IOV Network Operator 指标。默认情况下,此字段设置为 false

Network Resources Injector 是一个 Kubernetes Dynamic Admission Controller 应用。它提供以下功能:

  • 根据 SR-IOV 网络附加定义注解,对 Pod 规格中的资源请求和限值进行修改,以添加 SR-IOV 资源名称。
  • 使用 Downward API 卷修改 pod 规格,以公开 pod 注解、标签和巨页请求和限制。在 pod 中运行的容器可以作为 /etc/podnetinfo 路径下的文件来访问公开的信息。

当在 SriovOperatorConfig CR 中将 enableInjector 设置为 true 时,SR-IOV Network Operator 会启用 Network Resources Injector。network-resources-injector pod 作为守护进程集在所有 control plane 节点上运行。以下是在具有三个 control plane 节点的集群中运行的 Network Resources Injector pod 示例:

$ oc get pods -n openshift-sriov-network-operator
Copy to Clipboard Toggle word wrap

输出示例

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m
Copy to Clipboard Toggle word wrap

10.2.1.3. 禁用或启用网络资源注入器

要禁用或启用 Network Resources Injector (网络资源注入器),请完成以下步骤。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 您必须已安装了 SR-IOV Network Operator。

流程

  • 设置 enableInjector 字段。将 <value> 替换为 false 来禁用这个功能;或替换为 true 来启用这个功能。

    $ oc patch sriovoperatorconfig default \
      --type=merge -n openshift-sriov-network-operator \
      --patch '{ "spec": { "enableInjector": <value> } }'
    Copy to Clipboard Toggle word wrap
    提示

    您还可以应用以下 YAML 来更新 Operator:

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableInjector: <value>
    Copy to Clipboard Toggle word wrap

SR-IOV Network Operator Admission Controller Webhook 是一个 Kubernetes Dynamic Admission Controller 应用程序。它提供以下功能:

  • 在创建或更新时,验证 SriovNetworkNodePolicy CR。
  • 修改 SriovNetworkNodePolicy CR,在创建或更新 CR 时为 prioritydeviceType 项设置默认值。

当在 SriovOperatorConfig CR 中将 enableOperatorWebhook 设置为 true 时,Operator 会启用 SR-IOV Network Operator Admission Controller Webhook。operator-webhook pod 在所有 control plane 节点上作为守护进程集运行。

注意

禁用 SR-IOV Network Operator Admission Controller Webhook 时要小心。您可以在特定情况下禁用 webhook,如故障排除,或者想要使用不支持的设备。有关配置不支持的设备的详情,请参考将 SR-IOV Network Operator 配置为使用不支持的 NIC

以下是在具有三个 control plane 节点的集群中运行的 Operator Admission Controller webhook pod 的示例:

$ oc get pods -n openshift-sriov-network-operator
Copy to Clipboard Toggle word wrap

输出示例

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m
Copy to Clipboard Toggle word wrap

要禁用或启用准入控制器 Webhook,请完成以下步骤。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 您必须已安装了 SR-IOV Network Operator。

流程

  • 设置 enableOperatorWebhook 字段。将 <value> 替换为 false 来禁用这个功能;或替换为 true 来启用这个功能:

    $ oc patch sriovoperatorconfig default --type=merge \
      -n openshift-sriov-network-operator \
      --patch '{ "spec": { "enableOperatorWebhook": <value> } }'
    Copy to Clipboard Toggle word wrap
    提示

    您还可以应用以下 YAML 来更新 Operator:

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableOperatorWebhook: <value>
    Copy to Clipboard Toggle word wrap
10.2.1.6. 关于自定义节点选择器

SR-IOV 网络配置守护进程在集群节点上发现并配置 SR-IOV 网络设备。默认情况下,它将部署到集群中的所有 worker 节点。您可以使用节点标签指定 SR-IOV 网络配置守护进程在哪些节点上运行。

SR-IOV 网络配置守护进程在集群节点上发现并配置 SR-IOV 网络设备。默认情况下,它将部署到集群中的所有 worker 节点。您可以使用节点标签指定 SR-IOV 网络配置守护进程在哪些节点上运行。

要指定部署了 SR-IOV 网络配置守护进程的节点,请完成以下步骤。

重要

当您更新 configDaemonNodeSelector 字段时,SR-IOV 网络配置守护进程会在所选节点中重新创建。在重新创建守护进程时,集群用户无法应用任何新的 SR-IOV 网络节点策略或创建新的 SR-IOV Pod。

流程

  • 要为 Operator 更新节点选择器,请输入以下命令:

    $ oc patch sriovoperatorconfig default --type=json \
      -n openshift-sriov-network-operator \
      --patch '[{
          "op": "replace",
          "path": "/spec/configDaemonNodeSelector",
          "value": {<node_label>}
        }]'
    Copy to Clipboard Toggle word wrap

    <node_label> 替换为要应用的标签,如下例中:"node-role.kubernetes.io/worker": ""

    提示

    您还可以应用以下 YAML 来更新 Operator:

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      configDaemonNodeSelector:
        <node_label>
    Copy to Clipboard Toggle word wrap

默认情况下,SR-IOV Network Operator 会在每次策略更改前从节点排空工作负载。Operator 会执行这个操作,以确保在重新配置前没有使用虚拟功能的工作负载。

对于在单一节点上安装,没有其他节点来接收工作负载。因此,Operator 不得配置为从单一节点排空工作负载。

重要

执行以下步骤禁用排空工作负载后,您必须删除所有使用 SR-IOV 网络接口的工作负载,然后才能更改任何 SR-IOV 网络节点策略。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 您必须已安装了 SR-IOV Network Operator。

流程

  • 要将 disableDrain 字段设置为 true,并将 configDaemonNodeSelector 字段设置为 node-role.kubernetes.io/master: "",请输入以下命令:

    $ oc patch sriovoperatorconfig default --type=merge -n openshift-sriov-network-operator --patch '{ "spec": { "disableDrain": true, "configDaemonNodeSelector": { "node-role.kubernetes.io/master": "" } } }'
    Copy to Clipboard Toggle word wrap
    提示

    您还可以应用以下 YAML 来更新 Operator:

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      disableDrain: true
      configDaemonNodeSelector:
       node-role.kubernetes.io/master: ""
    Copy to Clipboard Toggle word wrap
10.2.1.9. 为托管 control plane 部署 SR-IOV Operator

配置和部署托管服务集群后,您可以在托管集群中创建 SR-IOV Operator 订阅。SR-IOV pod 在 worker 机器上运行而不是在 control plane 上运行。

先决条件

您必须在 AWS 上配置和部署托管集群。

流程

  1. 创建命名空间和 Operator 组:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sriov-network-operator
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sriov-network-operators
      namespace: openshift-sriov-network-operator
    spec:
      targetNamespaces:
      - openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap
  2. 创建 SR-IOV Operator 的订阅:

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sriov-network-operator-subsription
      namespace: openshift-sriov-network-operator
    spec:
      channel: stable
      name: sriov-network-operator
      config:
        nodeSelector:
          node-role.kubernetes.io/worker: ""
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap

验证

  1. 要验证 SR-IOV Operator 是否已就绪,请运行以下命令并查看生成的输出:

    $ oc get csv -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                         DISPLAY                   VERSION               REPLACES                                     PHASE
    sriov-network-operator.4.17.0-202211021237   SR-IOV Network Operator   4.17.0-202211021237   sriov-network-operator.4.17.0-202210290517   Succeeded
    Copy to Clipboard Toggle word wrap

  2. 要验证 SR-IOV pod 是否已部署,请运行以下命令:

    $ oc get pods -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

10.2.2. 关于 SR-IOV 网络指标导出器

Single Root I/O Virtualization (SR-IOV) 网络指标导出器读取 SR-IOV 虚拟功能 (VF) 的指标,并以 Prometheus 格式公开这些 VF 指标。启用 SR-IOV 网络指标导出器时,您可以使用 OpenShift Container Platform Web 控制台查询 SR-IOV VF 指标,来监控 SR-IOV pod 的网络活动。

当使用 web 控制台查询 SR-IOV VF 指标时,SR-IOV 网络指标导出器会获取并返回 VF 网络统计信息,以及 VF 附加到的 pod 的名称和命名空间。

下表中描述了指标导出器以 Prometheus 格式读取和公开的 SR-IOV VF 指标:

Expand
表 10.2. SR-IOV VF 指标
指标描述检查 VF 指标的 PromQL 查询示例

sriov_vf_rx_bytes

每个虚拟功能接收的字节数。

sriov_vf_rx_bytes * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_tx_bytes

每个虚拟功能传输的字节数。

sriov_vf_tx_bytes * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_rx_packets

每个虚拟功能接收的数据包。

sriov_vf_rx_packets * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_tx_packets

每个虚拟功能传输的数据包。

sriov_vf_tx_packets * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_rx_dropped

每个虚拟功能接收后丢弃的数据包。

sriov_vf_rx_dropped * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_tx_dropped

每个虚拟功能传输过程中丢弃的数据包。

sriov_vf_tx_dropped * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_rx_multicast

每个虚拟功能接收的多播数据包。

sriov_vf_rx_multicast * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_rx_broadcast

每个虚拟功能接收的广播数据包。

sriov_vf_rx_broadcast * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_kubepoddevice

链接到活跃 pod 的虚拟功能。

-

您还可以将这些查询与 kube-state-metrics 合并,以获取有关 SR-IOV pod 的更多信息。例如,您可以使用以下查询从标准 Kubernetes pod 标签获取 VF 网络统计信息以及应用程序名称:

(sriov_vf_tx_packets * on (pciAddr,node)  group_left(pod,namespace)  sriov_kubepoddevice) * on (pod,namespace) group_left (label_app_kubernetes_io_name) kube_pod_labels
Copy to Clipboard Toggle word wrap
10.2.2.1. 启用 SR-IOV 网络指标导出器

默认情况下,单根 I/O 虚拟化 (SR-IOV) 网络指标导出器被禁用。要启用指标导出器,您必须将 spec.featureGates.metricsExporter 字段设置为 true

重要

启用指标导出器后,SR-IOV Network Operator 仅在具有 SR-IOV 功能的节点上部署指标导出器。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您已以具有 cluster-admin 权限的用户身份登录。
  • 已安装 SR-IOV Network Operator。

流程

  1. 运行以下命令来启用集群监控:

    $ oc label ns/openshift-sriov-network-operator openshift.io/cluster-monitoring=true
    Copy to Clipboard Toggle word wrap

    要启用集群监控,您必须在安装了 SR-IOV Network Operator 的命名空间中创建 openshift.io/cluster-monitoring=true 标签。

  2. 运行以下命令,将 spec.featureGates.metricsExporter 字段设置为 true

    $ oc patch -n openshift-sriov-network-operator sriovoperatorconfig/default \
        --type='merge' -p='{"spec": {"featureGates": {"metricsExporter": true}}}'
    Copy to Clipboard Toggle word wrap

验证

  1. 运行以下命令,检查 SR-IOV 网络指标导出器是否已启用:

    $ oc get pods -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                     READY   STATUS    RESTARTS   AGE
    operator-webhook-hzfg4                   1/1     Running   0          5d22h
    sriov-network-config-daemon-tr54m        1/1     Running   0          5d22h
    sriov-network-metrics-exporter-z5d7t     1/1     Running   0          10s
    sriov-network-operator-cc6fd88bc-9bsmt   1/1     Running   0          5d22h
    Copy to Clipboard Toggle word wrap

    sriov-network-metrics-exporter pod 必须处于 READY 状态。

  2. 可选:使用 OpenShift Container Platform Web 控制台检查 SR-IOV 虚拟功能 (VF) 指标。如需更多信息,请参阅"查询指标"。

10.2.3. 后续步骤

10.3. 卸载 SR-IOV Network Operator

要卸载 SR-IOV Network Operator,您必须删除所有正在运行的 SR-IOV 工作负载,卸载 Operator,并删除 Operator 使用的 webhook。

10.3.1. 卸载 SR-IOV Network Operator

作为集群管理员,您可以卸载 SR-IOV Network Operator。

先决条件

  • 可以使用具有 cluster-admin 权限的账户访问 OpenShift Container Platform 集群。
  • 已安装 SR-IOV Network Operator。

流程

  1. 删除所有 SR-IOV 自定义资源(CR):

    $ oc delete sriovnetwork -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
    $ oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
    $ oc delete sriovibnetwork -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
  2. 按照 "Deleting Operators from a cluster" 部分的说明从集群中移除 SR-IOV Network Operator。
  3. 卸载 SR-IOV Network Operator 后,删除在集群中保留的 SR-IOV 自定义资源定义:

    $ oc delete crd sriovibnetworks.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworks.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
  4. 删除 SR-IOV Webhook:

    $ oc delete mutatingwebhookconfigurations network-resources-injector-config
    Copy to Clipboard Toggle word wrap
    $ oc delete MutatingWebhookConfiguration sriov-operator-webhook-config
    Copy to Clipboard Toggle word wrap
    $ oc delete ValidatingWebhookConfiguration sriov-operator-webhook-config
    Copy to Clipboard Toggle word wrap
  5. 删除 SR-IOV Network Operator 命名空间:

    $ oc delete namespace openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 Software Collections 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.

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat