网络
配置和管理集群网络
摘要
第 1 章 关于网络 复制链接链接已复制到粘贴板!
Red Hat OpenShift 网络是一个功能生态系统、插件和高级网络功能,它使用高级网络相关功能来扩展 Kubernetes 网络,集群需要为其一个或多个混合集群管理网络流量。这个网络功能生态系统集成了入口、出口、负载均衡、高性能吞吐量、安全性和集群内部流量管理,并提供基于角色的可观察工具来减少其自然复杂性。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
以下列表重点介绍集群中可用的一些最常用的 Red Hat OpenShift Networking 功能:
由以下 Container Network Interface (CNI) 插件之一提供的主要集群网络:
- 经认证的第三方替代主网络插件
- 用于网络插件管理的 Cluster Network Operator
- 用于 TLS 加密 Web 流量的 Ingress Operator
- 用于名称分配的 DNS Operator
- 用于裸机集群上的流量负载均衡的 MetalLB Operator
- 对高可用性的 IP 故障转移支持
- 通过多个 CNI 插件支持额外的硬件网络,包括 macvlan、ipvlan 和 SR-IOV 硬件网络
- IPv4、IPv6 和双堆栈寻址
- 用于基于 Windows 的工作负载的混合 Linux-Windows 主机集群
- Red Hat OpenShift Service Mesh 用于发现、负载均衡、服务对服务身份验证、故障恢复、指标和监控服务
- 单节点 OpenShift
- Network Observability Operator 用于网络调试和见解
- Submariner 用于 inter-cluster 网络
- Red Hat Service Interconnect 用于第 7 层 inter-cluster 网络
第 2 章 了解网络 复制链接链接已复制到粘贴板!
集群管理员有几个选项用于公开集群内的应用程序到外部流量并确保网络连接:
- 服务类型,如节点端口或负载均衡器
-
API 资源,如
Ingress和Route
默认情况下,Kubernetes 为 pod 内运行的应用分配内部 IP 地址。Pod 及其容器可以网络,但集群外的客户端无法访问网络。当您将应用公开给外部流量时,为每个容器集指定自己的 IP 地址意味着 pod 在端口分配、网络、命名、服务发现、负载平衡、应用配置和迁移方面可被视为物理主机或虚拟机。
一些云平台提供侦听 169.254.169.254 IP 地址的元数据 API,它是 IPv4 169.254.0.0/16 CIDR 块中的 连接内部 IP 地址。
此 CIDR 块无法从 pod 网络访问。需要访问这些 IP 地址的 Pod 必须通过将 pod spec 中的 spec.hostnetwork 字段设置为 true 来获得主机网络访问。
如果允许 pod 主机网络访问,则将授予 pod 对底层网络基础架构的访问权限。
2.1. OpenShift Container Platform DNS 复制链接链接已复制到粘贴板!
如果您运行多个服务,比如使用多个 pod 的前端和后端服务,则要为用户名和服务 IP 等创建环境变量,使前端 pod 可以跟后端服务通信。如果删除并重新创建服务,可以为该服务分配一个新的 IP 地址,而且需要重新创建前端 pod 来获取服务 IP 环境变量的更新值。另外,必须在任何前端 pod 之前创建后端服务,以确保正确生成服务 IP,并将它作为环境变量提供给前端 pod。
因此,OpenShift Container Platform 具有一个内置 DNS,以便服务 DNS 以及服务 IP/端口能够访问这些服务。
2.2. 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 端点的方法。
2.2.1. 路由和 Ingress 的比较 复制链接链接已复制到粘贴板!
OpenShift Container Platform 中的 Kubernetes Ingress 资源通过作为集群内 pod 运行的共享路由器服务来实现 Ingress Controller。管理 Ingress 流量的最常见方法是使用 Ingress Controller。您可以像任何其他常规 pod 一样扩展和复制此 pod。此路由器服务基于 HAProxy,后者是一个开源负载均衡器解决方案。
OpenShift Container Platform 路由为集群中的服务提供入口流量。路由提供了标准 Kubernetes Ingress Controller 可能不支持的高级功能,如 TLS 重新加密、TLS 直通和为蓝绿部署分割流量。
入口流量通过路由访问集群中的服务。路由和入口是处理入口流量的主要资源。Ingress 提供类似于路由的功能,如接受外部请求并根据路由委派它们。但是,对于 Ingress,您只能允许某些类型的连接:HTTP/2、HTTPS 和服务器名称识别(SNI),以及 TLS(证书)。在 OpenShift Container Platform 中,生成路由以满足 Ingress 资源指定的条件。
2.3. OpenShift Container Platform 网络的常见术语表 复制链接链接已复制到粘贴板!
该术语表定义了在网络内容中使用的常用术语。
- 身份验证
- 为了控制对 OpenShift Container Platform 集群的访问,集群管理员可以配置用户身份验证,并确保只有批准的用户访问集群。要与 OpenShift Container Platform 集群交互,您必须对 OpenShift Container Platform API 进行身份验证。您可以通过在您对 OpenShift Container Platform API 的请求中提供 OAuth 访问令牌或 X.509 客户端证书来进行身份验证。
- AWS Load Balancer Operator
-
AWS Load Balancer (ALB) Operator 部署和管理
aws-load-balancer-controller的实例。 - Cluster Network Operator
- Cluster Network Operator(CNO)在 OpenShift Container Platform 集群中部署和管理集群网络组件。这包括在安装过程中为集群选择的 Container Network Interface (CNI) 网络插件部署。
- 配置映射
-
配置映射提供将配置数据注入 pod 的方法。您可以在类型为
ConfigMap的卷中引用存储在配置映射中的数据。在 pod 中运行的应用程序可以使用这个数据。 - 自定义资源 (CR)
- CR 是 Kubernetes API 的扩展。您可以创建自定义资源。
- DNS
- 集群 DNS 是一个 DNS 服务器,它为 Kubernetes 服务提供 DNS 记录。由 Kubernetes 启动的容器会在其 DNS 搜索中自动包含此 DNS 服务器。
- DNS Operator
- DNS Operator 部署并管理 CoreDNS,以便为 pod 提供名称解析服务。这会在 OpenShift Container Platform 中启用基于 DNS 的 Kubernetes 服务发现。
- 部署
- 维护应用程序生命周期的 Kubernetes 资源对象。
- domain
- Domain(域)是 Ingress Controller 提供的 DNS 名称。
- egress
- 通过来自 pod 的网络出站流量进行外部数据共享的过程。
- 外部 DNS Operator
- External DNS Operator 部署并管理 ExternalDNS,以便为从外部 DNS 供应商到 OpenShift Container Platform 的服务和路由提供名称解析。
- 基于 HTTP 的路由
- 基于 HTTP 的路由是一个不受保护的路由,它使用基本的 HTTP 路由协议,并在未安全的应用程序端口上公开服务。
- 入口
- OpenShift Container Platform 中的 Kubernetes Ingress 资源通过作为集群内 pod 运行的共享路由器服务来实现 Ingress Controller。
- Ingress Controller
- Ingress Operator 管理 Ingress Controller。使用 Ingress Controller 是允许从外部访问 OpenShift Container Platform 集群的最常用方法。
- 安装程序置备的基础架构
- 安装程序部署并配置运行集群的基础架构。
- kubelet
- 在集群的每个节点上运行的一个主节点代理,以确保容器在 pod 中运行。
- Kubernetes NMState Operator
- Kubernetes NMState Operator 提供了一个 Kubernetes API,用于使用 NMState 在 OpenShift Container Platform 集群的节点上执行状态驱动的网络配置。
- kube-proxy
- kube-proxy 是一个代理服务,在每个节点上运行,有助于为外部主机提供服务。它有助于将请求转发到正确的容器,并且能够执行原语负载平衡。
- 负载均衡器
- OpenShift Container Platform 使用负载均衡器从集群外部与集群中运行的服务进行通信。
- MetalLB Operator
-
作为集群管理员,您可以将 MetalLB Operator 添加到集群中,以便在将
LoadBalancer类型服务添加到集群中时,MetalLB 可为该服务添加外部 IP 地址。 - multicast
- 通过使用 IP 多播,数据可同时广播到许多 IP 地址。
- 命名空间
- 命名空间隔离所有进程可见的特定系统资源。在一个命名空间中,只有属于该命名空间的进程才能看到这些资源。
- networking
- OpenShift Container Platform 集群的网络信息。
- node
- OpenShift Container Platform 集群中的 worker 机器。节点是虚拟机 (VM) 或物理计算机。
- OpenShift Container Platform Ingress Operator
-
Ingress Operator 实现
IngressControllerAPI,是负责启用对 OpenShift Container Platform 服务的外部访问的组件。 - pod
- 一个或多个带有共享资源(如卷和 IP 地址)的容器,在 OpenShift Container Platform 集群中运行。pod 是定义、部署和管理的最小计算单元。
- PTP Operator
-
PTP Operator 会创建和管理
linuxptp服务。 - route
- OpenShift Container Platform 路由为集群中的服务提供入口流量。路由提供了标准 Kubernetes Ingress Controller 可能不支持的高级功能,如 TLS 重新加密、TLS 直通和为蓝绿部署分割流量。
- 扩展
- 增加或减少资源容量。
- service
- 在一组 pod 上公开正在运行的应用程序。
- 单根 I/O 虚拟化 (SR-IOV) Network Operator
- Single Root I/O Virtualization(SR-IOV)Network Operator 管理集群中的 SR-IOV 网络设备和网络附加。
- 软件定义型网络 (SDN)
- OpenShift Container Platform 使用软件定义网络 (SDN) 方法来提供一个统一的集群网络,它允许 OpenShift Container Platform 集群中的不同 pod 相互间进行通信。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
- 流控制传输协议 (SCTP)
- SCTP 是基于信息的可靠协议,可在 IP 网络之上运行。
- taint
- 污点和容限可确保将 pod 调度到适当的节点上。您可以在节点上应用一个或多个污点。
- 容限 (tolerations)
- 您可以将容限应用到 pod。容限 (toleration) 允许调度程序调度具有匹配污点的 pod。
- Web 控制台
- 用于管理 OpenShift Container Platform 的用户界面(UI)。
第 3 章 访问主机 复制链接链接已复制到粘贴板!
了解如何创建堡垒主机来访问 OpenShift Container Platform 实例,以及使用安全 shell (SSH) 访问 control plane 节点。
3.1. 访问安装程序置备的基础架构集群中 Amazon Web Services 上的主机 复制链接链接已复制到粘贴板!
OpenShift Container Platform 安装程序不会为任何置备 OpenShift Container Platform 集群的 Amazon Elastic Compute Cloud (Amazon EC2) 实例创建公共 IP 地址。为了可以 SSH 到 OpenShift Container Platform 主机,您必须按照以下步骤操作。
流程
-
创建一个安全组,允许 SSH 访问由
openshift-install命令创建的虚拟私有云 (VPC) 。 - 在安装程序创建的某个公共子网中创建 Amazon EC2 实例。
将公共 IP 地址与您创建的 Amazon EC2 实例相关联。
与 OpenShift Container Platform 安装不同,您应该将您创建的 Amazon EC2 实例与 SSH 密钥对关联。这与您为这个实例选择的操作系统无关,因为它只是一个 SSH 堡垒将互联网桥接到 OpenShift Container Platform 集群的 VPC。它与您使用的 Amazon Machine Image (AMI) 相关。例如,在 Red Hat Enterprise Linux CoreOS(RHCOS) 中,您可以像安装程序一样通过 Ignition 提供密钥。
一旦置备了 Amazon EC2 实例并可以 SSH 到它,您必须添加与 OpenShift Container Platform 安装关联的 SSH 密钥。这个密钥可以与堡垒实例的密钥不同,也可以相同。
注意直接通过 SSH 访问仅建议在灾难恢复时使用。当 Kubernetes API 正常工作时,应该使用特权 Pod。
-
运行
oc get nodes,查看输出结果,然后选择一个 master 节点。主机名类似于ip-10-0-1-163.ec2.internal。 从您手动部署到 Amazon EC2 的堡垒 SSH 主机中,SSH 部署到该 control plane 主机。确定您使用了在安装过程中指定的相同的 SSH 密钥:
ssh -i <ssh-key-path> core@<master-hostname>
$ ssh -i <ssh-key-path> core@<master-hostname>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 4 章 网络仪表板 复制链接链接已复制到粘贴板!
网络指标可在 OpenShift Container Platform web 控制台的 dashboard 中的 Observe → Dashboards 下查看。
4.1. Network Observability Operator 复制链接链接已复制到粘贴板!
如果安装了 Network Observability Operator,可以通过从 Dashboards 下拉列表中选择 Netobserv 仪表板来查看网络流量指标仪表板。有关此仪表板中可用指标的更多信息,请参阅 Network Observability 指标仪表板。
4.2. 网络和 OVN-Kubernetes 仪表板 复制链接链接已复制到粘贴板!
您可以从仪表板中查看常规网络指标和 OVN-Kubernetes 指标。
要查看常规网络指标,请从 Dashboards 下拉列表中选择 Networking/Linux Subsystem Stats。您可以从控制面板查看以下网络指标:Network Utilisation、Network Saturation 和 Network Errors。
要查看 OVN-Kubernetes 指标,请从 Dashboards 下拉列表中选择 Networking/Infrastructure。您可以查看以下 OVN-Kuberenetes 指标:Networking Configuration, TCP Latency Probes, Control Plane Resources, 和 Worker Resources。
4.3. Ingress Operator 仪表板 复制链接链接已复制到粘贴板!
您可以从仪表板中查看 Ingress Operator 处理的网络指标。这包括类似如下的指标:
- 传入和传出带宽
- HTTP 错误率
- HTTP 服务器响应延迟
要查看这些 Ingress 指标,请从 Dashboards 下拉列表中选择 Networking/Ingress。您可以查看以下类别的 Ingress 指标: Top 10 Per Route,Top 10 Per Namespace, 和 Top 10 Per Shard。
第 5 章 Networking Operators 复制链接链接已复制到粘贴板!
5.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 和 OpenStack 安装的生产环境中支持 Kubernetes NMState Operator。
在 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-
描述节点上请求的网络配置。您可以通过将
NodeNetworkConfigurationPolicyCR 应用到集群来更新节点网络配置,包括添加和删除网络接口 。 NodeNetworkConfigurationEnactment- 报告每个节点上采用的网络策略。
5.1.1. 安装 Kubernetes NMState Operator 复制链接链接已复制到粘贴板!
您可以使用 web 控制台或 CLI 安装 Kubernetes NMState Operator。
5.1.1.1. 使用 Web 控制台安装 Kubernetes NMState Operator 复制链接链接已复制到粘贴板!
您可以使用 web 控制台安装 Kubernetes NMState Operator。安装 Kubernetes NMState Operator 后,Operator 将 NMState State Controller 部署为在所有集群节点中的守护进程集。
先决条件
-
您以具有
cluster-admin权限的用户身份登录。
流程
- 选择 Operators → OperatorHub。
-
在 All Items 下面的搜索字段中, 输入
nmstate并点 Enter 来搜索 Kubernetes NMState Operator。 - 点 Kubernetes NMState Operator 搜索结果。
- 点 Install 打开 Install Operator 窗口。
- 点 Install 安装 Operator。
- Operator 安装完成后,点 View Operator。
-
在 Provided APIs 下,点 Create Instance 打开对话框以创建
kubernetes-nmstate实例。 在对话框的 Name 字段中,确保实例的名称是
nmstate.注意名称限制是一个已知问题。该实例是整个集群的单个实例。
- 接受默认设置并点 Create 创建实例。
5.1.1.2. 使用 CLI 安装 Kubernetes NMState Operator 复制链接链接已复制到粘贴板!
您可以使用 OpenShift CLI(oc) 安装 Kubernetes NMState Operator。安装后,Operator 可将 NMState State Controller 部署为在所有集群节点中的守护进程集。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您以具有
cluster-admin权限的用户身份登录。
流程
创建
nmstateOperator 命名空间:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
OperatorGroup:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 订阅
nmstateOperator:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确认
nmstateOperator 部署的ClusterServiceVersion(CSV) 状态等于Succeeded:oc get clusterserviceversion -n openshift-nmstate \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get clusterserviceversion -n openshift-nmstate \ -o custom-columns=Name:.metadata.name,Phase:.status.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
nmstateOperator 实例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您的集群因为 DNS 连接问题导致 DNS 健康检查探测出现问题,您可以在
NMStateCRD 中添加以下 DNS 主机名配置,以便在可以解决这些问题的健康检查中构建:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将 DNS 主机名配置应用到集群网络。确保将
<filename>替换为 CRD 文件的名称。$ oc apply -f <filename>.yaml
$ oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,监控
nmstateCRD,直到资源达到Available条件。确保为 the-timeout 选项设置了一个值,以便在此设置的最大等待时间中没有满足Available条件时,命令会超时并生成错误消息。$ oc wait --for=condition=Available nmstate/nmstate --timeout=600s
$ oc wait --for=condition=Available nmstate/nmstate --timeout=600sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
输入以下命令验证 NMState Operator 的所有 pod 是否具有
Running状态:oc get pod -n openshift-nmstate
$ oc get pod -n openshift-nmstateCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.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)。 -
已安装
jqCLI 工具。 -
您以具有
cluster-admin权限的用户身份登录。
流程
运行以下命令,从
Subcription资源取消订阅 Kubernetes NMState Operator:oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operator
$ oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查找与 Kubernetes NMState Operator 关联的
ClusterServiceVersion(CSV) 资源:oc get --namespace openshift-nmstate clusterserviceversion
$ oc get --namespace openshift-nmstate clusterserviceversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 列出 CSV 资源的输出示例
NAME DISPLAY VERSION REPLACES PHASE kubernetes-nmstate-operator.v4.18.0 Kubernetes NMState Operator 4.18.0 Succeeded
NAME DISPLAY VERSION REPLACES PHASE kubernetes-nmstate-operator.v4.18.0 Kubernetes NMState Operator 4.18.0 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 CSV 资源。删除文件后,OLM 会删除其为 Operator 创建的某些资源,如
RBAC。oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.18.0
$ oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.18.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来删除
nmstateCR 和任何关联的Deployment资源:oc -n openshift-nmstate delete nmstate nmstate
$ oc -n openshift-nmstate delete nmstate nmstateCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete --all deployments --namespace=openshift-nmstate
$ oc delete --all deployments --namespace=openshift-nmstateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除
nmstateCR 后,从console.operator.openshift.io/clusterCR 中删除nmstate-console-plugin控制台插件名称。运行以下命令,存储在启用插件列表中存在
nmstate-console-plugin条目的位置。以下命令使用jqCLI 工具将条目的索引存储在名为INDEX的环境变量中:INDEX=$(oc get console.operator.openshift.io cluster -o json | jq -r '.spec.plugins | to_entries[] | select(.value == "nmstate-console-plugin") | .key')
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 Copied! Toggle word wrap Toggle overflow 运行以下 patch 命令,从
console.operator.openshift.io/clusterCR 中删除nmstate-console-plugin条目:oc patch console.operator.openshift.io cluster --type=json -p "[{\"op\": \"remove\", \"path\": \"/spec/plugins/$INDEX\"}]"$ oc patch console.operator.openshift.io cluster --type=json -p "[{\"op\": \"remove\", \"path\": \"/spec/plugins/$INDEX\"}]"1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
INDEX是辅助变量。您可以为此变量指定不同的名称。
运行以下命令删除所有自定义资源定义 (CRD),如
nmstates.nmstate.io:oc delete crd nmstates.nmstate.io
$ oc delete crd nmstates.nmstate.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd nodenetworkconfigurationenactments.nmstate.io
$ oc delete crd nodenetworkconfigurationenactments.nmstate.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd nodenetworkstates.nmstate.io
$ oc delete crd nodenetworkstates.nmstate.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd nodenetworkconfigurationpolicies.nmstate.io
$ oc delete crd nodenetworkconfigurationpolicies.nmstate.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除命名空间:
oc delete namespace kubernetes-nmstate
$ oc delete namespace kubernetes-nmstateCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. AWS Load Balancer Operator 复制链接链接已复制到粘贴板!
5.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。
5.2.1.1. AWS Load Balancer Operator 1.2.0 复制链接链接已复制到粘贴板!
以下公告可用于 AWS Load Balancer Operator 版本 1.2.0 :
5.2.1.1.1. 主要变化 复制链接链接已复制到粘贴板!
- 此发行版本支持 AWS Load Balancer Controller 版本 2.8.2。
-
在这个版本中,
Infrastructure资源中定义的平台标签将添加到控制器创建的所有 AWS 对象中。
5.2.1.2. AWS Load Balancer Operator 1.1.1 复制链接链接已复制到粘贴板!
以下公告可用于 AWS Load Balancer Operator 版本 1.1.1:
5.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:
5.2.1.3.1. 主要变化 复制链接链接已复制到粘贴板!
- 此发行版本使用 Kubernetes API 版本 0.27.2。
5.2.1.3.2. 新功能 复制链接链接已复制到粘贴板!
- AWS Load Balancer Operator 现在支持使用 Cloud Credential Operator 的标准化安全令牌服务 (STS) 流。
5.2.1.3.3. 程序错误修复 复制链接链接已复制到粘贴板!
FIPS 兼容集群必须使用 TLS 版本 1.2。在以前的版本中,AWS Load Balancer Controller 的 Webhook 只接受 TLS 1.3 作为最小版本,从而导致在与 FIPS 兼容的集群中出现以下错误:
remote error: tls: protocol version not supported
remote error: tls: protocol version not supportedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 现在,AWS Load Balancer Controller 接受 TLS 1.2 作为最小 TLS 版本,从而解决了这个问题。(OCPBUGS-14846)
5.2.1.4. AWS Load Balancer Operator 1.0.1 复制链接链接已复制到粘贴板!
以下公告可用于 AWS Load Balancer Operator 版本 1.0.1:
5.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 命名空间。
5.2.1.5.1. 主要变化 复制链接链接已复制到粘贴板!
-
此发行版本使用新的
v1API 版本。
5.2.1.5.2. 程序错误修复 复制链接链接已复制到粘贴板!
- 在以前的版本中,AWS Load Balancer Operator 置备的控制器无法正确将配置用于集群范围代理。这些设置现在对控制器正确应用。(OCPBUGS-4052, OCPBUGS-5295)
5.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。
5.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.class和alb.ingress.kubernetes.io/group.name注解。 -
您已配置了 AWS Load Balancer Operator,使 SVC 类型是
NodePort(而不是LoadBalancer或ClusterIP)。
5.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)。
流程
您可以通过运行以下命令来创建
Subscription对象,以按需部署 AWS Load Balancer Operator:oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'$ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检查安装计划的状态是否为
Complete:oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'$ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,查看
aws-load-balancer-operator-controller-manager部署的状态:oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager
$ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-operator-controller-manager 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-operator-controller-manager 1/1 1 1 23hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
您可以配置 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资源配置示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定要使用的子网。
- 要在 Outpost 中使用 Application Load Balancer,请指定 Outpost 子网 ID。
- 要在云中使用 Application Load Balancer,您必须在不同的可用区中指定至少两个子网。
5.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 创建并可用。
5.2.3.1. 先决条件 复制链接链接已复制到粘贴板!
-
已安装 OpenShift CLI(
oc)。 您知道集群的基础架构 ID。要显示此 ID,请在 CLI 中运行以下命令:
oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"$ oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您知道集群的 OpenID Connect (OIDC) DNS 信息。要显示此信息,请在 CLI 中输入以下命令:
oc get authentication.config cluster -o=jsonpath="{.spec.serviceAccountIssuer}"$ oc get authentication.config cluster -o=jsonpath="{.spec.serviceAccountIssuer}"1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
https://rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f是 OIDC DNS 的一个示例。
-
已登陆到 AWS Web 控制台,进入到 IAM → Access management → Identity provider,以及 OIDC Amazon Resource Name (ARN) 信息。一个 OIDC ARN 示例为
arn:aws:iam::777777777777:oidc-provider/<oidc_dns_url>。
5.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 角色:
-
使用 Cloud Credential Operator 实用程序 (
ccoctl) 和预定义的CredentialsRequest对象。 - 使用 AWS CLI 和预定义的 AWS 清单。
如果您的环境不支持 ccoctl 命令,请使用 AWS CLI。
您可以使用 Cloud Credential Operator 实用程序(ccoctl) 为 AWS Load Balancer Operator 创建 AWS IAM 角色。AWS IAM 角色与子网和虚拟私有云 (VPC) 交互。
先决条件
-
您必须提取并准备
ccoctl二进制文件。
流程
运行以下命令,下载
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
$ curl --create-dirs -o <credentials_requests_dir>/operator.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,使用
ccoctl实用程序创建 AWS IAM 角色:ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credentials_requests_dir> \ --identity-provider-arn <oidc_arn>$ ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credentials_requests_dir> \ --identity-provider-arn <oidc_arn>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-operator created 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
2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-operator created1 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 createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 个字符。
5.2.3.2.2. 使用 AWS CLI 创建 AWS IAM 角色 复制链接链接已复制到粘贴板!
您可以使用 AWS 命令行界面为 AWS Load Balancer Operator 创建 IAM 角色。IAM 角色用于与子网和虚拟私有云 (VPC) 交互。
先决条件
-
您必须有权访问 AWS 命令行界面 (
aws)。
流程
运行以下命令,使用身份提供程序生成信任策略文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,使用生成的信任策略创建 IAM 角色:
aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.json
$ aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
ROLE arn:aws:iam::<aws_account_number>:role/albo-operator 2023-08-02T12:13:22Z 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>
ROLE arn:aws:iam::<aws_account_number>:role/albo-operator 2023-08-02T12:13:22Z1 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 Copied! Toggle word wrap Toggle overflow - 1
- 为 AWS Load Balancer Operator 创建的 AWS IAM 角色的 ARN,如
arn:aws:iam::777777777777:role/albo-operator。
运行以下命令,下载 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
$ curl -o albo-operator-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-permission-policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将 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
$ aws iam put-role-policy --role-name albo-operator --policy-name perms-policy-albo-operator --policy-document file://albo-operator-permission-policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.3.3. 为 AWS Load Balancer Operator 配置 ARN 角色 复制链接链接已复制到粘贴板!
您可以将 AWS Load Balancer Operator 的 Amazon 资源名称 (ARN) 角色配置为环境变量。您可以使用 CLI 配置 ARN 角色。
先决条件
-
已安装 OpenShift CLI(
oc)。
流程
运行以下命令来创建
aws-load-balancer-operator项目:oc new-project aws-load-balancer-operator
$ oc new-project aws-load-balancer-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
OperatorGroup对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Subscription对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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。
5.2.3.4. 为 AWS Load Balancer Controller 创建 IAM 角色 复制链接链接已复制到粘贴板!
AWS Load Balancer Controller 的 CredentialsRequest 对象必须使用手动置备的 IAM 角色设置。
您可以使用以下选项创建 IAM 角色:
-
使用 Cloud Credential Operator 实用程序 (
ccoctl) 和预定义的CredentialsRequest对象。 - 使用 AWS CLI 和预定义的 AWS 清单。
如果您的环境不支持 ccoctl 命令,请使用 AWS CLI。
您可以使用 Cloud Credential Operator 实用程序(ccoctl) 为 AWS Load Balancer Controller 创建 AWS IAM 角色。AWS IAM 角色用于与子网和虚拟私有云 (VPC) 交互。
先决条件
-
您必须提取并准备
ccoctl二进制文件。
流程
运行以下命令,下载
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
$ curl --create-dirs -o <credentials_requests_dir>/controller.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,使用
ccoctl实用程序创建 AWS IAM 角色:ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credentials_requests_dir> \ --identity-provider-arn <oidc_arn>$ ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credentials_requests_dir> \ --identity-provider-arn <oidc_arn>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-controller created 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
2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-controller created1 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 createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 个字符。
5.2.3.4.2. 使用 AWS CLI 为控制器创建 AWS IAM 角色 复制链接链接已复制到粘贴板!
您可以使用 AWS 命令行界面为 AWS Load Balancer Controller 创建 AWS IAM 角色。AWS IAM 角色用于与子网和虚拟私有云 (VPC) 交互。
先决条件
-
您必须有权访问 AWS 命令行界面 (
aws)。
流程
运行以下命令,使用身份提供程序生成信任策略文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,使用生成的信任策略创建 AWS IAM 角色:
aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.json
$ aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
ROLE arn:aws:iam::<aws_account_number>:role/albo-controller 2023-08-02T12:13:22Z 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>
ROLE arn:aws:iam::<aws_account_number>:role/albo-controller 2023-08-02T12:13:22Z1 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 Copied! Toggle word wrap Toggle overflow - 1
- AWS Load Balancer Controller 的 AWS IAM 角色的 ARN,如
arn:aws:iam::777777777777:role/albo-controller。
运行以下命令,下载 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
$ curl -o albo-controller-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/assets/iam-policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将 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
$ aws iam put-role-policy --role-name albo-controller --policy-name perms-policy-albo-controller --policy-document file://albo-controller-permission-policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建定义
AWSLoadBalancerController对象的 YAML 文件:sample-aws-lb-manual-creds.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.4. 安装 AWS Load Balancer Operator 复制链接链接已复制到粘贴板!
AWS Load Balancer Operator 部署和管理 AWS Load Balancer Controller。您可以使用 OpenShift Container Platform Web 控制台或 CLI 安装来自 OperatorHub 的 AWS Load Balancer Operator。
5.2.4.1. 使用 Web 控制台安装 AWS Load Balancer Operator 复制链接链接已复制到粘贴板!
您可以使用 Web 控制台安装 AWS Load Balancer Operator。
先决条件
-
已作为具有
cluster-admin权限的用户身份登录 OpenShift Container Platform Web 控制台。 - 集群被配置为使用 AWS 作为平台类型和云供应商。
- 如果您使用安全令牌服务(STS)或用户置备的基础架构,请按照相关的准备步骤操作。例如,如果您使用 AWS 安全令牌服务,请参阅使用 AWS 安全令牌服务(STS) "在集群中准备 AWS Load Balancer Operator"。
流程
- 在 OpenShift Container Platform Web 控制台中进入 Operators → OperatorHub。
- 选择 AWS Load Balancer Operator。您可以使用 Filter by keyword 文本框,或者使用过滤器列表从 Operator 列表搜索 AWS Load Balancer Operator。
-
选择
aws-load-balancer-operator命名空间。 在 Install Operator 页面中,选择以下选项:
- 更新频道为 stable-v1。
- 安装模式 为 All namespaces on the cluster (default)。
-
Installed Namespace 为
aws-load-balancer-operator。如果aws-load-balancer-operator命名空间不存在,它会在 Operator 安装过程中创建。 - 选择 Update approval 为 Automatic 或 Manual。默认情况下,Update approval 设置为 Automatic。如果选择自动更新,Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例,而无需任何干预。如果选择手动更新,OLM 将创建一个更新请求。作为集群管理员,您必须手动批准该更新请求,以便将 Operator 更新至新版本。
- 点 Install。
验证
- 在 Installed Operators 仪表板中验证 AWS Load Balancer Operator 的 Status 显示为 Succeeded。
5.2.4.2. 使用 CLI 安装 AWS Load Balancer Operator 复制链接链接已复制到粘贴板!
您可以使用 CLI 安装 AWS Load Balancer Operator。
先决条件
-
以具有
cluster-admin权限的用户身份登录 OpenShift Container Platform Web 控制台。 - 集群被配置为使用 AWS 作为平台类型和云供应商。
-
已登陆到 OpenShift CLI (
oc)。
流程
创建一个
Namespace对象:创建定义
Namespace对象的 YAML 文件:namespace.yaml文件示例apiVersion: v1 kind: Namespace metadata: name: aws-load-balancer-operator
apiVersion: v1 kind: Namespace metadata: name: aws-load-balancer-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Namespace对象:oc apply -f namespace.yaml
$ oc apply -f namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个
OperatorGroup对象:创建定义
OperatorGroup对象的 YAML 文件:operatorgroup.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
OperatorGroup对象:oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建
Subscription对象:创建定义
Subscription对象的 YAML 文件:subscription.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Subscription对象:oc apply -f subscription.yaml
$ oc apply -f subscription.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
从订阅中获取安装计划的名称:
oc -n aws-load-balancer-operator \ get subscription aws-load-balancer-operator \ --template='{{.status.installplan.name}}{{"\n"}}'$ oc -n aws-load-balancer-operator \ get subscription aws-load-balancer-operator \ --template='{{.status.installplan.name}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查安装计划的状态:
oc -n aws-load-balancer-operator \ get ip <install_plan_name> \ --template='{{.status.phase}}{{"\n"}}'$ oc -n aws-load-balancer-operator \ get ip <install_plan_name> \ --template='{{.status.phase}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出必须是
Complete。
5.2.4.3. 创建 AWS Load Balancer Controller 复制链接链接已复制到粘贴板!
您只能在集群中安装 AWSLoadBalancerController 对象的单个实例。您可以使用 CLI 创建 AWS Load Balancer Controller。AWS Load Balancer Operator 只协调名为 resource 的集群。
先决条件
-
您已创建了
echoserver命名空间。 -
您可以访问 OpenShift CLI(
oc)。
流程
创建定义
AWSLoadBalancerController对象的 YAML 文件:sample-aws-lb.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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注解。
运行以下命令来创建
AWSLoadBalancerController对象:oc create -f sample-aws-lb.yaml
$ oc create -f sample-aws-lb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建定义
Deployment资源的 YAML 文件:sample-aws-lb.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建定义
Service资源的 YAML 文件:service-albo.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建定义
Ingress资源的 YAML 文件:ingress-albo.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,将
Ingress资源的状态保存到HOST变量中:HOST=$(oc get ingress -n echoserver echoserver --template='{{(index .status.loadBalancer.ingress 0).hostname}}')$ HOST=$(oc get ingress -n echoserver echoserver --template='{{(index .status.loadBalancer.ingress 0).hostname}}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证
Ingress资源的状态:curl $HOST
$ curl $HOSTCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.5. 配置 AWS Load Balancer Operator 复制链接链接已复制到粘贴板!
5.2.5.1. 信任集群范围代理的证书颁发机构 复制链接链接已复制到粘贴板!
您可以在 AWS Load Balancer Operator 中配置集群范围代理。配置集群范围代理后,Operator Lifecycle Manager (OLM) 会使用 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 等环境变量自动更新 Operator 的所有部署。这些变量由 AWS Load Balancer Operator 填充给受管控制器。
运行以下命令,创建配置映射以在
aws-load-balancer-operator命名空间中包含证书颁发机构 (CA) 捆绑包:oc -n aws-load-balancer-operator create configmap trusted-ca
$ oc -n aws-load-balancer-operator create configmap trusted-caCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要将可信 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
$ oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,更新 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"}]}}}'$ 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 Copied! Toggle word wrap Toggle overflow 部署 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"
$ 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 Copied! Toggle word wrap Toggle overflow 输出示例
-rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt trusted-ca
-rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt trusted-caCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:通过运行以下命令,每次 configmap 发生变化时重启 AWS Load Balancer Operator 的部署:
oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
$ oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.5.2. 在 AWS Load Balancer 中添加 TLS 终止 复制链接链接已复制到粘贴板!
您可以将域的流量路由到服务的 pod,并在 AWS 负载均衡器中添加 TLS 终止。
先决条件
-
您可以访问 OpenShift CLI(
oc)。
流程
创建定义
AWSLoadBalancerController资源的 YAML 文件:add-tls-termination-albc.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 定义入口类名称。如果集群中没有 ingress 类,AWS Load Balancer Controller 会创建一个。如果
spec.controller设置为ingress.k8s.aws/alb,AWS Load Balancer Controller 会协调额外的入口类值。
创建定义
Ingress资源的 YAML 文件:add-tls-termination-ingress.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.5.3. 通过单个 AWS Load Balancer 创建多个入口资源 复制链接链接已复制到粘贴板!
您可以通过单个 AWS Load Balancer 将流量路由到属于单个域一部分的、带有多个 ingress 资源的不同服务。每个 ingress 资源提供了域的不同端点。
先决条件
-
您可以访问 OpenShift CLI(
oc)。
流程
创建一个
IngressClassParams资源 YAML 文件,如sample-single-lb-params.yaml,如下所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
IngressClassParams资源:oc create -f sample-single-lb-params.yaml
$ oc create -f sample-single-lb-params.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
IngressClass资源 YAML 文件,如sample-single-lb-class.yaml,如下所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
IngressClass资源:oc create -f sample-single-lb-class.yaml
$ oc create -f sample-single-lb-class.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
AWSLoadBalancerController资源 YAML 文件,如sample-single-lb.yaml,如下所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 定义
IngressClass资源的名称。
运行以下命令来创建
AWSLoadBalancerController资源:oc create -f sample-single-lb.yaml
$ oc create -f sample-single-lb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
Ingress资源 YAML 文件,如sample-multiple-ingress.yaml,如下所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Ingress资源:oc create -f sample-multiple-ingress.yaml
$ oc create -f sample-multiple-ingress.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.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
$ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. 外部 DNS Operator 复制链接链接已复制到粘贴板!
5.3.1. 外部 DNS Operator 发行注记 复制链接链接已复制到粘贴板!
External DNS Operator 部署并管理 ExternalDNS,以便为从外部 DNS 供应商到 OpenShift Container Platform 的服务和路由提供名称解析。
External DNS Operator 仅在 x86_64 架构上被支持。
本发行注记介绍了 OpenShift Container Platform 中外部 DNS Operator 的开发。
5.3.1.1. 外部 DNS Operator 1.2.0 复制链接链接已复制到粘贴板!
以下公告可用于外部 DNS Operator 版本 1.2.0 :
5.3.1.1.1. 新功能 复制链接链接已复制到粘贴板!
- External DNS Operator 现在支持 AWS 共享 VPC。如需更多信息,请参阅使用共享 VPC 在不同的 AWS 帐户中创建 DNS 记录。
5.3.1.1.2. 程序错误修复 复制链接链接已复制到粘贴板!
-
操作对象的更新策略从
Rolling改为Recreate。(OCPBUGS-3630)
5.3.1.2. 外部 DNS Operator 1.1.1 复制链接链接已复制到粘贴板!
以下公告可用于外部 DNS Operator 版本 1.1.1:
5.3.1.3. 外部 DNS Operator 1.1.0 复制链接链接已复制到粘贴板!
此发行版本包含来自上游项目 0.13.1 版本的操作对象的变基。以下公告可用于外部 DNS Operator 版本 1.1.0:
5.3.1.3.1. 程序错误修复 复制链接链接已复制到粘贴板!
-
在以前的版本中,ExternalDNS Operator 为卷强制有一个空的
defaultMode值,这会导致因为与 OpenShift API 冲突而造成恒定的更新。现在,defaultMode值不会被强制,操作对象部署不会持续更新。(OCPBUGS-2793)
5.3.1.4. 外部 DNS Operator 1.0.1 复制链接链接已复制到粘贴板!
以下公告可用于外部 DNS Operator 版本 1.0.1:
5.3.1.5. 外部 DNS Operator 1.0.0 复制链接链接已复制到粘贴板!
以下公告可用于 External DNS Operator 版本 1.0.0:
5.3.1.5.1. 程序错误修复 复制链接链接已复制到粘贴板!
- 在以前的版本中,External DNS Operator 在 ExternalDNS 操作对象 pod 部署中发出有关违反 restricted SCC 策略的警告。这个问题已解决。(BZ#2086408)
5.3.2. 了解外部 DNS Operator 复制链接链接已复制到粘贴板!
External DNS Operator 部署并管理 ExternalDNS,以便为从外部 DNS 供应商到 OpenShift Container Platform 的服务和路由提供名称解析。
5.3.2.1. 外部 DNS Operator 复制链接链接已复制到粘贴板!
External DNS Operator 从 olm.openshift.io API 组实现外部 DNS API。External DNS Operator 更新服务、路由和外部 DNS 供应商。
先决条件
-
已安装
yqCLI 工具。
流程
您可以根据 OperatorHub 的要求部署外部 DNS Operator。部署外部 DNS Operator 会创建一个 Subscription 对象。
运行以下命令,检查安装计划的名称,如
install-zcvlr:oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'
$ oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检查安装计划的状态是否为
Complete:oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
$ oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,查看
external-dns-operator部署的状态:oc get -n external-dns-operator deployment/external-dns-operator
$ oc get -n external-dns-operator deployment/external-dns-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE external-dns-operator 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE external-dns-operator 1/1 1 1 23hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.2.2. 查看外部 DNS Operator 日志 复制链接链接已复制到粘贴板!
您可以使用 oc logs 命令查看外部 DNS Operator 日志。
流程
运行以下命令,查看外部 DNS Operator 的日志:
oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator
$ oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.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 记录的域名有以下限制:
| 记录类型 | 字符数 |
|---|---|
| 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"
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"
5.3.3. 安装 External DNS Operator 复制链接链接已复制到粘贴板!
您可以在 AWS、Azure 和 Google Cloud 等云供应商上安装外部 DNS Operator。
5.3.3.1. 使用 OperatorHub 安装 External DNS Operator 复制链接链接已复制到粘贴板!
您可以使用 OpenShift Container Platform OperatorHub 安装外部 DNS Operator。
流程
- 在 OpenShift Container Platform Web 控制台中点 Operators → OperatorHub。
- 点 External DNS Operator。您可以使用 Filter by keyword 文本框或过滤器列表从 Operator 列表中搜索 External DNS Operator。
-
选择
external-dns-operator命名空间。 - 在 External DNS Operator 页面中,点 Install。
在 Install Operator 页面中,确保选择了以下选项:
- 将频道更新为 stable-v1。
- 安装模式为 A specific name on the cluster。
-
安装的命名空间为
external-dns-operator。如果命名空间external-dns-operator不存在,它会在 Operator 安装过程中创建。 - 将 Approval Strategy 选为 Automatic 或 Manual。默认情况下,批准策略设置为 Automatic。
- 点 Install。
如果选择了 Automatic 更新,Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例,而无需任何干预。
如果选择 手动 更新,则 OLM 会创建一个更新请求。作为集群管理员,您必须手动批准该更新请求,才可将 Operator 更新至新版本。
验证
验证 External DNS Operator 是否在 Installed Operators 仪表板上显示 Status 为 Succeeded。
5.3.3.2. 使用 CLI 安装 External DNS Operator 复制链接链接已复制到粘贴板!
您可以使用 CLI 安装 External DNS Operator
先决条件
-
以具有
cluster-admin权限的用户身份登录 OpenShift Container Platform Web 控制台。 -
已登陆到 OpenShift CLI (
oc)。
流程
创建一个
Namespace对象:创建定义
Namespace对象的 YAML 文件:namespace.yaml文件示例apiVersion: v1 kind: Namespace metadata: name: external-dns-operator
apiVersion: v1 kind: Namespace metadata: name: external-dns-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Namespace对象:oc apply -f namespace.yaml
$ oc apply -f namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个
OperatorGroup对象:创建定义
OperatorGroup对象的 YAML 文件:operatorgroup.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
OperatorGroup对象:oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建
Subscription对象:创建定义
Subscription对象的 YAML 文件:subscription.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Subscription对象:oc apply -f subscription.yaml
$ oc apply -f subscription.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,从订阅获取安装计划的名称:
oc -n external-dns-operator \ get subscription external-dns-operator \ --template='{{.status.installplan.name}}{{"\n"}}'$ oc -n external-dns-operator \ get subscription external-dns-operator \ --template='{{.status.installplan.name}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证安装计划的状态是否为
Complete:oc -n external-dns-operator \ get ip <install_plan_name> \ --template='{{.status.phase}}{{"\n"}}'$ oc -n external-dns-operator \ get ip <install_plan_name> \ --template='{{.status.phase}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证
external-dns-operatorpod 的状态是否为Running:oc -n external-dns-operator get pod
$ oc -n external-dns-operator get podCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE external-dns-operator-5584585fd7-5lwqm 2/2 Running 0 11m
NAME READY STATUS RESTARTS AGE external-dns-operator-5584585fd7-5lwqm 2/2 Running 0 11mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证订阅的目录源是否为
redhat-operators:oc -n external-dns-operator get subscription
$ oc -n external-dns-operator get subscriptionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令检查
external-dns-operator版本:oc -n external-dns-operator get csv
$ oc -n external-dns-operator get csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.4. 外部 DNS Operator 配置参数 复制链接链接已复制到粘贴板!
External DNS Operator 包括以下配置参数。
5.3.4.1. 外部 DNS Operator 配置参数 复制链接链接已复制到粘贴板!
External DNS Operator 包括以下配置参数:
| 参数 | 描述 |
|---|---|
|
| 启用云供应商的类型。 |
|
|
允许您根据域指定 DNS 区域。如果没有指定区, zones: - "myzoneid"
|
|
|
允许您根据域指定 AWS 区域。如果没有指定域, |
|
|
允许您指定 DNS 记录、
|
5.3.5. 在 AWS 上创建 DNS 记录 复制链接链接已复制到粘贴板!
您可以使用 External DNS Operator 在 AWS 和 AWS GovCloud 上创建 DNS 记录。
您可以使用 Red Hat External DNS Operator 在 AWS 公共托管区上创建 DNS 记录。您可以使用相同的说明在 AWS GovCloud 的托管区上创建 DNS 记录。
流程
运行以下命令,检查用户配置文件,如
system:admin。用户配置集必须有权访问kube-system命名空间。如果没有凭证,您可以从kube-system命名空间中获取凭证,运行以下命令来使用云供应商客户端:oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从
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)$ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system --template={{.data.aws_access_key_id}} | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system --template={{.data.aws_secret_access_key}} | base64 -d)$ export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system --template={{.data.aws_secret_access_key}} | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 获取路由来检查域:
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
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 NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 获取 DNS 区域列表,并找到与您之前查询的路由域对应的 DNS 区域:
aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
$ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.supportCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为
路由源创建ExternalDNS资源:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 定义外部 DNS 资源的名称。
- 2
- 默认情况下,所有托管区都被选为潜在的目标。您可以包括需要的托管区。
- 3
- 目标区的域匹配必须是完全准确的(与正则表达式匹配不同)。
- 4
- 指定您要更新的区域的确切域。路由的主机名必须是指定域的子域。
- 5
- 定义
AWS Route53DNS 供应商。 - 6
- 定义 DNS 记录源的选项。
- 7
- 定义 OpenShift
路由资源,作为在之前指定的 DNS 供应商中创建的 DNS 记录来源。 - 8
- 如果源是
OpenShiftRoute,您可以传递 OpenShift Ingress Controller 名称。外部 DNS Operator 在创建 CNAME 记录时,选择该路由器的规范主机名作为目标。
使用以下命令,检查为 OCP 路由创建的记录:
aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console
$ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.5.2. 使用共享 VPC 在不同的 AWS 帐户中创建 DNS 记录 复制链接链接已复制到粘贴板!
您可以使用 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。
流程
运行以下命令,获取您创建的 IAM 角色的 Role ARN,以允许帐户 B 访问帐户 A 的 Route 53 托管区:
aws --profile account-a iam get-role --role-name user-rol1 | head -1
$ aws --profile account-a iam get-role --role-name user-rol1 | head -1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
ROLE arn:aws:iam::1234567890123:role/user-rol1 2023-09-14T17:21:54+00:00 3600 / AROA3SGB2ZRKRT5NISNJN user-rol1
ROLE arn:aws:iam::1234567890123:role/user-rol1 2023-09-14T17:21:54+00:00 3600 / AROA3SGB2ZRKRT5NISNJN user-rol1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,找到用于帐户 A 凭证的私有托管区:
aws --profile account-a route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
$ aws --profile account-a route53 list-hosted-zones | grep testextdnsoperator.apacshift.supportCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
ExternalDNS对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定 Role ARN,以便在帐户 A 中创建 DNS 记录。
使用以下命令,检查为 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
$ aws --profile account-a route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console-openshift-consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.6. 在 Azure 上创建 DNS 记录 复制链接链接已复制到粘贴板!
您可以使用外部 DNS Operator 在 Azure 上创建 DNS 记录。
不支持在支持 Microsoft Entra Workload ID 的集群或在 Microsoft Azure Government (MAG) 区域中运行的集群中使用 External DNS Operator。
5.3.6.1. 在 Azure DNS 区域中创建 DNS 记录 复制链接链接已复制到粘贴板!
您可以使用 External DNS Operator 在 Azure 的公共或私有 DNS 区域上创建域名服务器(DNS)记录。
先决条件
- 您必须具有管理员特权。
-
admin用户必须有权访问kube-system命名空间。
流程
运行以下命令,从
kube-system命名空间中获取凭证以使用云供应商客户端:CLIENT_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_client_id}} | base64 -d)$ CLIENT_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_client_id}} | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow CLIENT_SECRET=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_client_secret}} | base64 -d)$ CLIENT_SECRET=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_client_secret}} | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow RESOURCE_GROUP=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_resourcegroup}} | base64 -d)$ RESOURCE_GROUP=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_resourcegroup}} | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow SUBSCRIPTION_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_subscription_id}} | base64 -d)$ SUBSCRIPTION_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_subscription_id}} | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow TENANT_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_tenant_id}} | base64 -d)$ TENANT_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_tenant_id}} | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来登录到 Azure:
az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"$ az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来获取路由列表:
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
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 NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 获取 DNS 区域列表。
对于公共 DNS 区域,请运行以下命令:
az network dns zone list --resource-group "${RESOURCE_GROUP}"$ az network dns zone list --resource-group "${RESOURCE_GROUP}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 对于私有 DNS 区域,请运行以下命令:
az network private-dns zone list -g "${RESOURCE_GROUP}"$ az network private-dns zone list -g "${RESOURCE_GROUP}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个 YAML 文件,如
external-dns-sample-azure.yaml,该文件定义ExternalDNS对象:external-dns-sample-azure.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
故障排除
检查为路由创建的记录。
对于公共 DNS 区域,请运行以下命令:
az network dns record-set list -g "${RESOURCE_GROUP}" -z "${ZONE_NAME}" | grep console$ az network dns record-set list -g "${RESOURCE_GROUP}" -z "${ZONE_NAME}" | grep consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 对于私有 DNS 区域,请运行以下命令:
az network private-dns record-set list -g "${RESOURCE_GROUP}" -z "${ZONE_NAME}" | grep console$ az network private-dns record-set list -g "${RESOURCE_GROUP}" -z "${ZONE_NAME}" | grep consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.7. 在 Google Cloud 上创建 DNS 记录 复制链接链接已复制到粘贴板!
您可以使用 External DNS Operator 在 Google Cloud 上创建 DNS 记录。
不支持在启用了 Google Cloud Workload Identity 的集群上使用 External DNS Operator。有关 Google Cloud Workload Identity 的更多信息,请参阅 Google Cloud Workload Identity。
5.3.7.1. 在 Google Cloud 公共管理区上创建 DNS 记录 复制链接链接已复制到粘贴板!
您可以使用 External DNS Operator 在 Google Cloud 公共管理区上创建 DNS 记录。
先决条件
- 您必须具有管理员特权。
流程
运行以下命令,将
gcp-credentialssecret 复制到encoded-gcloud.json文件中:oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json$ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令导出 Google 凭证:
export GOOGLE_CREDENTIALS=decoded-gcloud.json
$ export GOOGLE_CREDENTIALS=decoded-gcloud.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令激活您的帐户:
gcloud auth activate-service-account <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json
$ gcloud auth activate-service-account <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来设置项目:
gcloud config set project <project_id as per decoded-gcloud.json>
$ gcloud config set project <project_id as per decoded-gcloud.json>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来获取路由列表:
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
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 NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,获取受管区域的列表,如
qe-cvs4g-private-zone test.gcp.example.com:gcloud dns managed-zones list | grep test.gcp.example.com
$ gcloud dns managed-zones list | grep test.gcp.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个 YAML 文件,如
external-dns-sample-gcp.yaml,该文件定义ExternalDNS对象:external-dns-sample-gcp.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检查为 OpenShift Container Platform 路由创建的 DNS 记录:
gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
$ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.8. 在 Infoblox 上创建 DNS 记录 复制链接链接已复制到粘贴板!
您可以使用 External DNS Operator 在 Infoblox 上创建 DNS 记录。
5.3.8.1. 在 Infoblox 上的公共 DNS 区域中创建 DNS 记录 复制链接链接已复制到粘贴板!
您可以使用 External DNS Operator 在 Infoblox 上的公共 DNS 区域上创建 DNS 记录。
先决条件
-
您可以访问 OpenShift CLI(
oc)。 - 您可以访问 Infoblox UI。
流程
运行以下命令,使用 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>
$ 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 Copied! Toggle word wrap Toggle overflow 运行以下命令来获取路由列表:
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
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 NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个 YAML 文件,如
external-dns-sample-infoblox.yaml,该文件定义ExternalDNS对象:external-dns-sample-infoblox.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,在 Infoblox 上创建
ExternalDNS资源:oc create -f external-dns-sample-infoblox.yaml
$ oc create -f external-dns-sample-infoblox.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过 Infoblox UI,检查为
console路由创建的 DNS 记录:- 点 Data Management → DNS → Zones。
- 选择区域名称。
5.3.9. 在外部 DNS Operator 上配置集群范围代理 复制链接链接已复制到粘贴板!
配置集群范围代理后,Operator Lifecycle Manager (OLM) 会触发对使用 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 环境变量的新内容的所有部署的 Operator 的自动更新。
5.3.9.1. 信任集群范围代理的证书颁发机构 复制链接链接已复制到粘贴板!
您可以将外部 DNS Operator 配置为信任集群范围代理的证书颁发机构。
流程
运行以下命令,创建配置映射以在
external-dns-operator命名空间中包含 CA 捆绑包:oc -n external-dns-operator create configmap trusted-ca
$ oc -n external-dns-operator create configmap trusted-caCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要将可信 CA 捆绑包注入配置映射中,请运行以下命令将
config.openshift.io/inject-trusted-cabundle=true标签添加到配置映射中:oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
$ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令更新外部 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"}]}}]'$ 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 Copied! Toggle word wrap Toggle overflow
验证
部署外部 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
$ oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. MetalLB Operator 复制链接链接已复制到粘贴板!
5.4.1. 关于 MetalLB 和 MetalLB Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以将 MetalLB Operator 添加到集群中,以便在将 LoadBalancer 类型服务添加到集群中时,MetalLB 可为该服务添加外部 IP 地址。外部 IP 地址添加到集群的主机网络中。
5.4.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.4.1.2. MetalLB Operator 自定义资源 复制链接链接已复制到粘贴板!
MetalLB Operator 为以下自定义资源监控自己的命名空间:
MetalLB-
当您在集群中添加
MetalLB自定义资源时,MetalLB Operator 会在集群中部署 MetalLB。Operator 只支持单个自定义资源实例。如果删除了实例,Operator 会从集群中删除 MetalLB。 IPAddressPoolMetalLB 需要一个或多个 IP 地址池,您可以在添加类型为
LoadBalancer的服务时分配给服务。一个IPAddressPool,包含 IP 地址列表。列表可以是使用范围设置的单个 IP 地址,如 1.1.1.1-1.1.1.1、以 CIDR 表示法指定的范围、指定为起始和结束地址的范围,或者以连字符分隔的、两者的组合。IPAddressPool需要一个名称。文档使用doc-example、doc-example-reserved和doc-example-ipv6等名称。MetalLB控制器从IPAddressPool中的地址池中分配 IP 地址。L2Advertisement和BGPAdvertisement自定义资源启用从一个指定池中广告一个给定 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 后,controller 和 speaker MetalLB 软件组件将开始运行。
MetalLB 验证所有相关自定义资源。
5.4.1.3. MetalLB 软件组件 复制链接链接已复制到粘贴板!
安装 MetalLB Operator 时,metallb-operator-controller-manager 部署会启动一个 pod。pod 是 Operator 的实施。pod 监控所有相关资源的更改。
当 Operator 启动 MetalLB 实例时,它会启动一个 controller 部署和一个 speaker 守护进程集。
您可以在 MetalLB 自定义资源中配置部署规格,以管理 controller 和 speaker pod 如何在集群中部署和运行。有关这些部署规格的更多信息,请参阅附加资源部分。
controllerOperator 会启动部署和单个 pod。当您添加类型为
LoadBalancer的服务时,Kubernetes 使用controller从地址池中分配 IP 地址。如果服务失败,请验证controllerpod 日志中有以下条目:输出示例
"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller
"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow speakerOperator 为
speakerpod 启动守护进程集。默认情况下,在集群的每个节点上启动 pod。您可以在启动MetalLB时在 MetalLB 自定义资源中指定节点选择器,将 pod 限制到特定的节点。如果controller为服务分配了 IP 地址,并且服务仍不可用,请阅读speakerpod 日志。如果speakerpod 不可用,请运行oc describe pod -n命令。对于第 2 层模式,
控制器为服务分配 IP 地址后,speakerpod 使用一种算法来确定哪些speakerpod 将宣布负载均衡器 IP 地址。该算法涉及对节点名称和负载均衡器 IP 地址进行哈希处理。如需更多信息,请参阅"MetalLB 和外部流量策略"。speaker使用地址解析协议 (ARP) 来宣布 IPv4 地址和邻居发现协议 (NDP) 来宣布 IPv6 地址。
对于 Border Gateway Protocol (BGP) 模式,controller 为服务分配 IP 地址后,每个 speaker pod 为其 BGP 对等点公告负载均衡器 IP 地址。您可以配置节点在 BGP 对等点上启动 BGP 会话。
对负载均衡器 IP 地址的请求会路由到具有声明 IP 地址的 speaker 的节点。节点接收数据包后,服务代理会将数据包路由到该服务的端点。在最佳情况下,端点可以位于同一节点上,也可以位于另一节点上。每次建立连接时,服务代理都会选择一个端点。
5.4.1.4. MetalLB 和外部流量策略 复制链接链接已复制到粘贴板!
使用第 2 层模式时,集群中的一个节点会接收服务 IP 地址的所有流量。使用 BGP 模式时,主机网络上的路由器会打开与集群中其中一个节点的连接,用于新客户端连接。集群在进入节点后如何处理流量受外部流量策略的影响。
cluster这是
spec.externalTrafficPolicy的默认值。使用
cluster流量策略时,节点接收流量后,服务代理会将流量分发到服务中的所有容器集。此策略在 pod 之间提供统一流量分布,但它会模糊客户端 IP 地址,并可能会在 pod 中显示流量源自节点而不是客户端的应用。local采用
local流量策略时,节点接收流量后,服务代理仅将流量发送到同一节点上的 pod。例如,如果节点上的speakerpod 宣布外部服务 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.4.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。 -
每个
speakerpod 都是主机网络的 pod。容器集的 IP 地址与主机网络上节点的 IP 地址相同。 -
节点 1 上的
speakerpod 使用 ARP 声明服务的外部 IP 地址192.168.100.200。声明外部 IP 地址的speakerpod 必须与服务的端点位于同一个节点上,端点必须为Ready条件。 客户端流量路由到主机网络,并连接到
192.168.100.200IP 地址。在流量进入节点后,服务代理会根据您为服务设置的外部流量策略,将流量发送到同一节点上的应用 pod 或其他节点。-
如果服务的外部流量策略设置为
cluster,则会从运行speakerpod 的节点选择广告192.168.100.200负载均衡器 IP 地址的节点。只有该节点才能接收该服务的流量。 -
如果服务的外部流量策略设置为
local,则会从运行speakerpod 的节点以及至少一个服务的端点选择广告192.168.100.200负载均衡器 IP 地址的节点。只有该节点才能接收该服务的流量。在上图中,节点 1 或 3 将广告192.168.100.200。
-
如果服务的外部流量策略设置为
-
如果节点 1 不可用,则外部 IP 地址将故障转移到另一节点。在具有应用 pod 和服务端点实例的另一个节点上,
speakerPod 开始宣布外部 IP 地址192.168.100.200,新节点接收客户端流量。在图中,唯一的候选项是节点 3。
5.4.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 来指定运行speakerpod 的节点。 -
每个
speakerpod 都是主机网络的 pod。容器集的 IP 地址与主机网络上节点的 IP 地址相同。 -
每个
speakerpod 启动一个 BGP 会话,其中包含所有 BGP 对等点,并将负载均衡器 IP 地址或聚合路由公告给 BGP 对等点。speakerpod 公告它们是 Autonomous System 65010 的一部分。图显示路由器 R1 作为同一自主系统内的 BGP peer。但是,您可以将 MetalLB 配置为与属于其他自主系统的同行启动 BGP 会话。 具有
speakerpod 的所有节点(公告负载均衡器 IP 地址)都可以接收该服务的流量。-
如果服务的外部流量策略设置为
cluster,则运行 speaker pod 的所有节点都会广告203.0.113.200负载平衡器 IP 地址,具有speakerpod 的所有节点都可以接收该服务的流量。只有外部流量策略设为 cluster 时,主机前缀才会广告给路由器对等点。 -
如果服务的外部流量策略设置为
local,则运行speakerPod 的所有节点都会运行,并且至少有一个运行的服务端点可能会广告203.0.113.200负载均衡器 IP 地址。只有这些节点才能接收该服务的流量。在上图中,节点 2 和 3 将公告203.0.113.200。
-
如果服务的外部流量策略设置为
-
您可以在添加 BGP peer 自定义资源时指定节点选择器,将 MetalLB 配置为通过指定带有特定 BGP peer 的节点选择器来控制哪些
speakerpod 启动 BGP 对等点。 - 任何配置为使用 BGP 的路由器(如 R1)都可以设置为 BGP 同级服务器。
- 客户端流量路由到主机网络上的其中一个节点。在流量进入节点后,服务代理会根据您为服务设置的外部流量策略,将流量发送到同一节点上的应用 pod 或其他节点。
- 如果节点不可用,路由器检测到失败,并启动与另一节点的新连接。您可以将 MetalLB 配置为将双向转发检测(BFD)配置集用于 BGP 对等点。BFD 提供更快的链路失败检测,以便路由器可以比没有 BFD 的情况下启动新连接。
5.4.1.7. 限制和限制 复制链接链接已复制到粘贴板!
5.4.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®
OpenShift SDN 和 OVN-Kubernetes 网络供应商支持 MetalLB 和 MetalLB。
5.4.1.7.2. 第 2 层模式的限制 复制链接链接已复制到粘贴板!
5.4.1.7.2.1. 单节点瓶颈 复制链接链接已复制到粘贴板!
MetalLB 通过单一节点路由服务的所有流量,该节点可能会成为瓶颈并限制性能。
第 2 层模式将服务的入口带宽限制为单个节点的带宽。这是使用 ARP 和 NDP 定向流量的一个根本限制。
5.4.1.7.2.2. 延迟故障转移性能 复制链接链接已复制到粘贴板!
节点之间的故障转移取决于客户端的合作。发生故障转移时,MetalLB 发送粒度 ARP 数据包来通知客户端与服务 IP 关联的 MAC 地址已更改。
大多数客户端操作系统正确处理细粒度 ARP 数据包,并及时更新其邻居缓存。当客户端快速更新其缓存时,故障转移将在几秒钟内完成。客户端通常在 10 秒内故障转移到新节点。但是,一些客户端操作系统或者根本不处理饱和的 ARP 数据包,或者存在延迟缓存更新的过时实施。
Windows、macOS 和 Linux 等常见操作系统的最新版本正确实现了第 2 层故障转移。除了较旧和不太常见的客户端操作系统外,预计不会出现故障转移较慢的问题。
为最大程度减轻计划内故障转移对过时客户端的影响,在颠倒领导地位后让旧节点保持运行几分钟。旧节点可以继续转发过期客户端的流量,直到其缓存刷新。
在计划外故障转移期间,服务 IP 无法访问,直到过期的客户端刷新其缓存条目为止。
5.4.1.7.2.3. 额外网络和 MetalLB 无法使用相同的网络 复制链接链接已复制到粘贴板!
将相同的 VLAN 用于 MetalLB 和源 pod 上设置的额外网络接口可能会导致连接失败。当 MetalLB IP 和源 pod 驻留在同一节点上时,会出现这种情况。
为了避免连接失败,请将 MetalLB IP 放在源 pod 所在的不同子网中。此配置可确保来自源 pod 的流量将采用默认网关。因此,流量可以使用 OVN 覆盖网络有效地到达其目的地,确保连接功能如预期一样。
5.4.1.7.3. BGP 模式限制 复制链接链接已复制到粘贴板!
5.4.1.7.3.1. 节点故障可能会破坏所有活跃的连接 复制链接链接已复制到粘贴板!
MetalLB 共享一个限制,这是基于 BGP 的负载平衡。当 BGP 会话终止时,如节点失败或者 speaker pod 重启时,会话终止可能会导致重置所有活跃的连接。最终用户可以 通过 peer 消息完成连接重置。
所终止的 BGP 会话的结果是特定于路由器制造商的实现。但是,您可以预测 speaker pod 数量的变化会影响 BGP 会话的数量,并且与 BGP 对等点的活动连接将中断。
为了避免或降低服务中断的可能性,您可以在添加 BGP 对等点时指定节点选择器。通过限制启动 BGP 会话的节点数量,没有 BGP 会话的节点出现错误不会影响到该服务的连接。
5.4.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.4.2. 安装 MetalLB Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以添加 MetalLB Operator,以便 Operator 可以管理集群中的 MetalLB 实例的生命周期。
MetalLB 和 IP 故障转移不兼容。如果您为集群配置了 IP 故障切换,请在安装 Operator 前执行删除 IP 故障切换的步骤。
5.4.2.1. 使用 Web 控制台从 OperatorHub 安装 MetalLB Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 OpenShift Container Platform Web 控制台安装 MetalLB Operator。
先决条件
-
以具有
cluster-admin特权的用户身份登录。
流程
- 在 OpenShift Container Platform Web 控制台中导航至 Operators → OperatorHub。
在 Filter by keyword 框中输入关键字,或滚动以查找您想要的 Operator。例如,键入
metallb来查找 MetalLB Operator。您还可以根据基础架构功能过滤选项。例如,如果您希望 Operator 在断开连接的环境中工作,请选择 Disconnected。
- 在 Install Operator 页面中,接受默认值并点 Install。
验证
确认安装成功:
- 导航到 Operators → Installed Operators 页面。
-
检查 Operator 是否安装在
openshift-operators命名空间中,其状态是否为Succeeded。
如果 Operator 没有成功安装,请检查 Operator 的状态并查看日志:
-
导航到 Operators → Installed Operators 页面,并检查
Status列中是否有任何错误或故障。 -
导航到 Workloads → Pods 页面,并检查
openshift-operators项目中报告问题的 pod 的日志。
-
导航到 Operators → Installed Operators 页面,并检查
5.4.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特权的用户身份登录。
流程
输入以下命令为 MetalLB Operator 创建命名空间:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在命名空间中创建 Operator 组自定义资源(CR):
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确认 Operator 组已安装在命名空间中:
oc get operatorgroup -n metallb-system
$ oc get operatorgroup -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME AGE metallb-operator 14m
NAME AGE metallb-operator 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个
SubscriptionCR:定义
SubscriptionCR 并保存 YAML 文件,如metallb-sub.yaml:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 您必须指定
redhat-operators值。
要创建
SubscriptionCR,请运行以下命令:oc create -f metallb-sub.yaml
$ oc create -f metallb-sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
可选: 要确保 BGP 和 BFD 指标出现在 Prometheus 中,您可以使用以下命令标记命名空间:
oc label ns metallb-system "openshift.io/cluster-monitoring=true"
$ oc label ns metallb-system "openshift.io/cluster-monitoring=true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证步骤假定 metallb-system 命名空间中安装了 MetalLB Operator。
确认安装计划位于命名空间中:
oc get installplan -n metallb-system
$ oc get installplan -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME CSV APPROVAL APPROVED install-wzg94 metallb-operator.4.16.0-nnnnnnnnnnnn Automatic true
NAME CSV APPROVAL APPROVED install-wzg94 metallb-operator.4.16.0-nnnnnnnnnnnn Automatic trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意安装 Operator 可能需要几秒钟。
要验证是否已安装 Operator,请输入以下命令,然后检查 Operator 的输出显示
Succeeded:oc get clusterserviceversion -n metallb-system \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get clusterserviceversion -n metallb-system \ -o custom-columns=Name:.metadata.name,Phase:.status.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.3. 在集群中启动 MetalLB 复制链接链接已复制到粘贴板!
安装 Operator 后,您需要配置 MetalLB 自定义资源的单一实例。配置自定义资源后,Operator 会在集群中启动 MetalLB。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 MetalLB Operator。
流程
此流程假设 MetalLB Operator 已安装在 metallb-system 命名空间中。如果使用 Web 控制台安装,请替换命名空间的 openshift-operators。
创建 MetalLB 自定义资源的单一实例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
确认 MetalLB 控制器的部署和 MetalLB speaker 的守护进程集正在运行。
验证控制器的部署是否正在运行:
oc get deployment -n metallb-system controller
$ oc get deployment -n metallb-system controllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE controller 1/1 1 1 11m
NAME READY UP-TO-DATE AVAILABLE AGE controller 1/1 1 1 11mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证发言人的守护进程集是否正在运行:
oc get daemonset -n metallb-system speaker
$ oc get daemonset -n metallb-system speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE speaker 6 6 6 6 6 kubernetes.io/os=linux 18m
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE speaker 6 6 6 6 6 kubernetes.io/os=linux 18mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 示例输出显示 6 个 speaker Pod。集群中的 speaker pod 数量可能与示例输出不同。确保输出指示集群中每个节点有一个容器集。
5.4.2.4. MetalLB 的部署规格 复制链接链接已复制到粘贴板!
当使用 MetalLB 自定义资源启动 MetalLB 实例时,您可以在 MetalLB 自定义资源中配置部署规格,以管理 controller 或 speaker pod 如何在集群中部署并运行。使用这些部署规格来管理以下任务:
- 为 MetalLB pod 部署选择节点。
- 使用 pod 优先级和 pod 关联性来管理调度。
- 为 MetalLB pod 分配 CPU 限值。
- 为 MetalLB pod 分配容器 RuntimeClass。
- 为 MetalLB pod 分配元数据。
5.4.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 节点的配置示例
使用 spec.nodeSelector 字段应用清单后,您可以检查 Operator 使用 oc get daemonset -n metallb-system speaker 命令部署的 pod 数量。同样,您可以使用 oc get nodes -l node-role.kubernetes.io/worker= 等命令显示与标签匹配的节点。
您可以选择允许节点使用关联性规则控制哪些 speaker pod 应该或不应该调度到节点上。您还可以通过应用容限列表来限制这些 pod。如需有关关联性规则、污点和容限的更多信息,请参阅其他资源。
5.4.2.4.2. 在 MetalLB 部署中配置 pod 优先级和 pod 关联性 复制链接链接已复制到粘贴板!
您可以通过配置 MetalLB 自定义资源,选择将 pod 优先级和 pod 关联性规则分配给 controller 和 speaker pod。pod 优先级指示节点上 pod 的相对重要性,并根据这个优先级调度 pod。在 controller 或 speaker pod 上设置高优先级,以确保在节点上的其他 pod 上调度优先级。
Pod 关联性管理 pod 间的关系。将 pod 关联性分配给 controller 或 speaker pod,以控制调度程序将 pod 放置到 pod 关系的节点上。例如,您可以使用 pod 关联性规则来确保某些 pod 位于同一节点或节点上,这有助于提高网络通信并减少这些组件之间的延迟。
先决条件
-
您以具有
cluster-admin权限的用户身份登录。 - 已安装 MetalLB Operator。
- 已在集群中启动 MetalLB Operator。
流程
创建
PriorityClass自定义资源,如myPriorityClass.yaml,以配置优先级级别。这个示例定义了名为high-priority的PriorityClass,值设为1000000。与具有较低优先级类的 pod 相比,在调度过程中分配此优先级类的 Pod 被视为优先级更高:apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用
PriorityClass自定义资源配置:oc apply -f myPriorityClass.yaml
$ oc apply -f myPriorityClass.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
MetalLB自定义资源,如MetalLBPodConfig.yaml,以指定priorityClassName和podAffinity值:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用
MetalLB自定义资源配置:oc apply -f MetalLBPodConfig.yaml
$ oc apply -f MetalLBPodConfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要在
metallb-system命名空间中查看分配给 pod 的优先级类,请运行以下命令:oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
$ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassNameCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
NAME PRIORITY controller-584f5c8cd8-5zbvg high-priority metallb-operator-controller-manager-9c8d9985-szkqg <none> metallb-operator-webhook-server-c895594d4-shjgx <none> speaker-dddf7 high-priorityCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证调度程序是否根据 pod 关联性规则放置 pod,请运行以下命令来查看 pod 的节点或节点的元数据:
oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
$ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.4.3. 在 MetalLB 部署中配置 pod CPU 限制 复制链接链接已复制到粘贴板!
您可以通过配置 MetalLB 自定义资源(可选)将 pod CPU 限值分配给 controller 和 speaker pod。为 controller 或 speaker pod 定义 CPU 限制可帮助您管理节点上的计算资源。这样可确保节点上的所有 pod 具有必要的计算资源来管理工作负载和集群内务。
先决条件
-
您以具有
cluster-admin权限的用户身份登录。 - 已安装 MetalLB Operator。
流程
创建
MetalLB自定义资源文件,如CPULimits.yaml,以指定controller和speakerpod 的cpu值:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用
MetalLB自定义资源配置:oc apply -f CPULimits.yaml
$ oc apply -f CPULimits.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要查看 pod 的计算资源,请运行以下命令,将
<pod_name>替换为您的目标 pod:oc describe pod <pod_name>
$ oc describe pod <pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.6. 后续步骤 复制链接链接已复制到粘贴板!
5.4.3. 升级 MetalLB Operator 复制链接链接已复制到粘贴板!
默认情况下,将命名空间订阅到 metallb-system 的 Subscription 自定义资源 (CR) 会自动将 installPlanApproval 参数设置为 Automatic。这意味着,当红帽提供的 Operator 目录包含 MetalLB Operator 的较新版本时,MetalLB Operator 会自动升级。
如果需要手动控制 MetalLB Operator 升级,请将 installPlanApproval 参数设置为 Manual。
5.4.3.1. 手动升级 MetalLB Operator 复制链接链接已复制到粘贴板!
要手动控制升级 MetalLB Operator,您必须编辑将命名空间订阅到 metallb-system 的 Subscription 自定义资源(CR)。Subscription CR 作为 Operator 安装的一部分创建,且 CR 默认将 installPlanApproval 参数设置为 Automatic。
先决条件
- 将集群更新至最新的 z-stream 版本。
- 使用 OperatorHub 安装 MetalLB Operator。
-
使用具有
cluster-admin角色的用户访问集群。
流程
输入以下命令在
metallb-system命名空间中获取metallb-operator订阅的 YAML 定义:oc -n metallb-system get subscription metallb-operator -o yaml
$ oc -n metallb-system get subscription metallb-operator -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过将
installPlanApproval参数设置为Manual来编辑SubscriptionCR:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令查找 MetalLB Operator 的最新 OpenShift Container Platform 4.16 版本:
oc -n metallb-system get csv
$ oc -n metallb-system get csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令检查命名空间中存在的安装计划。
oc -n metallb-system get installplan
$ oc -n metallb-system get installplanCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 install-tsz2g 显示为手动安装计划的输出示例
NAME CSV APPROVAL APPROVED install-shpmd metallb-operator.v4.16.0-202502261233 Automatic true install-tsz2g metallb-operator.v4.16.0-202503102139 Manual false
NAME CSV APPROVAL APPROVED install-shpmd metallb-operator.v4.16.0-202502261233 Automatic true install-tsz2g metallb-operator.v4.16.0-202503102139 Manual falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令来编辑命名空间中存在的安装计划。确保将
<name_of_installplan>替换为安装计划的名称,如install-tsz2g。oc edit installplan <name_of_installplan> -n metallb-system
$ oc edit installplan <name_of_installplan> -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在编辑器中打开安装计划后,将
spec.approval参数设置为Manual,并将spec.approved参数设置为true。注意编辑安装计划后,升级操作会启动。如果在升级操作过程中输入
oc -n metallb-system get csv命令,则输出可能会显示Replacing或Pending状态。
验证
要验证是否已升级了 Operator,请输入以下命令,然后检查 Operator 的输出显示
Succeeded:oc -n metallb-system get csv
$ oc -n metallb-system get csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.3.2. 其他资源 复制链接链接已复制到粘贴板!
Cluster Network Operator (CNO)在 OpenShift Container Platform 集群上部署和管理集群网络组件,包括在安装过程中为集群选择的 Container Network Interface (CNI) 网络插件。
5.5.1. Cluster Network Operator 复制链接链接已复制到粘贴板!
Cluster Network Operator 从 operator.openshift.io API 组实现 network API。Operator 通过使用守护进程集部署 OVN-Kubernetes 网络插件,或部署您在集群安装过程中选择的网络供应商插件。
流程
Cluster Network Operator 在安装过程中被部署为一个 Kubernetes 部署。
运行以下命令,以查看部署状态:
oc get -n openshift-network-operator deployment/network-operator
$ oc get -n openshift-network-operator deployment/network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56m
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,以查看 Cluster Network Operator 的状态:
oc get clusteroperator/network
$ oc get clusteroperator/networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.16.1 True False False 50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.16.1 True False False 50mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下字段提供有关 Operator 状态的信息:
AVAILABLE、Progressing和DEGRADED。当 Cluster Network Operator 报告可用状态条件时,AVAILABLE字段为True。
5.5.2. 查看集群网络配置 复制链接链接已复制到粘贴板!
每个 OpenShift Container Platform 新安装都有一个名为 cluster 的 network.config 对象。
5.5.3. 查看 Cluster Network Operator 状态 复制链接链接已复制到粘贴板!
您可以使用 oc describe 命令来检查状态并查看 Cluster Network Operator 的详情。
流程
运行以下命令,以查看 Cluster Network Operator 的状态:
oc describe clusteroperators/network
$ oc describe clusteroperators/networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5.4. 全局启用 IP 转发 复制链接链接已复制到粘贴板!
从 OpenShift Container Platform 4.14 开始,基于 OVN-Kubernetes 的集群部署禁用了全局 IP 地址转发,以防止集群管理员对作为路由器的节点造成不必要的影响。但是,在某些情况下,管理员希望转发一个新的配置参数 ipForwarding 来允许转发所有 IP 流量。
要为 OVN-Kubernetes 受管接口上的所有流量重新启用 IP 转发,请按照以下流程将 Cluster Network Operator 中的 gatewayConfig.ipForwarding 规格设置为 Global :
流程
运行以下命令备份现有网络配置:
oc get network.operator cluster -o yaml > network-config-backup.yaml
$ oc get network.operator cluster -o yaml > network-config-backup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令修改现有的网络配置:
oc edit network.operator cluster
$ oc edit network.operator clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
spec中添加或更新以下块,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存并关闭该文件。
应用更改后,OpenShift Cluster Network Operator (CNO) 在集群中应用更新。您可以使用以下命令监控进度:
oc get clusteroperators network
$ oc get clusteroperators networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 状态最终应报告为
Available,Progressing=False, 和Degraded=False。另外,您可以运行以下命令来全局启用 IP 转发:
oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意当您要恢复此更改时,此参数的其他有效选项为
Restricted。restricted是默认设置,并且禁用设置全局 IP 地址转发。
5.5.5. 查看 Cluster Network Operator 日志 复制链接链接已复制到粘贴板!
您可以使用 oc logs 命令来查看 Cluster Network Operator 日志。
流程
运行以下命令,以查看 Cluster Network Operator 的日志:
oc logs --namespace=openshift-network-operator deployment/network-operator
$ oc logs --namespace=openshift-network-operator deployment/network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5.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 地址范围。默认网络类型只能通过迁移从 OpenShift SDN 改为 OVN-Kubernetes。
您可以通过在名为 cluster 的 CNO 对象中设置 defaultNetwork 对象的字段来为集群指定集群网络插件配置。
5.5.6.1. Cluster Network Operator 配置对象 复制链接链接已复制到粘贴板!
下表中描述了 Cluster Network Operator(CNO)的字段:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNO 对象的名称。这个名称始终是 |
|
|
| 用于指定从哪些 IP 地址块分配 Pod IP 地址以及集群中每个节点的子网前缀长度的列表。例如: |
|
|
| 服务的 IP 地址块。OpenShift SDN 和 OVN-Kubernetes 网络插件只支持服务网络的一个 IP 地址块。例如: spec: serviceNetwork: - 172.30.0.0/14
此值是只读的,在集群安装过程中从名为 |
|
|
| 为集群网络配置网络插件。 |
|
|
| 此对象的字段指定 kube-proxy 配置。如果使用 OVN-Kubernetes 集群网络供应商,则 kube-proxy 配置不会起作用。 |
对于需要在多个网络间部署对象的集群,请确保为 install-config.yaml 文件中定义的每种网络类型指定与 clusterNetwork.hostPrefix 参数相同的值。为每个 clusterNetwork.hostPrefix 参数设置不同的值可能会影响 OVN-Kubernetes 网络插件,其中插件无法有效地在不同节点间路由对象流量。
5.5.6.1.1. defaultNetwork 对象配置 复制链接链接已复制到粘贴板!
下表列出了 defaultNetwork 对象的值:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
注意 OpenShift Container Platform 默认使用 OVN-Kubernetes 网络插件。OpenShift SDN 不再作为新集群的安装选择提供。 |
|
|
| 此对象仅对 OVN-Kubernetes 网络插件有效。 |
5.5.6.1.1.1. 配置 OpenShift SDN 网络插件 复制链接链接已复制到粘贴板!
下表描述了 OpenShift SDN 网络插件的配置字段:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| OpenShift SDN 的网络隔离模式。 |
|
|
| VXLAN 覆盖网络的最大传输单元(MTU)。这个值通常是自动配置的。 |
|
|
|
用于所有 VXLAN 数据包的端口。默认值为 |
OpenShift SDN 配置示例
5.5.6.1.1.2. 配置 OVN-Kubernetes 网络插件 复制链接链接已复制到粘贴板!
下表描述了 OVN-Kubernetes 网络插件的配置字段:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| Geneve(通用网络虚拟化封装)覆盖网络的最大传输单元(MTU)。这个值通常是自动配置的。 |
|
|
| Geneve 覆盖网络的 UDP 端口。 |
|
|
| 用于描述集群的 IPsec 模式的对象。 |
|
|
| 为 IPv4 设置指定配置对象。 |
|
|
| 为 IPv6 设置指定配置对象。 |
|
|
| 指定用于自定义网络策略审计日志的配置对象。如果未设置,则使用默认的审计日志设置。 |
|
|
|
可选:指定一个配置对象来自定义如何将出口流量发送到节点网关。有效值为 注意 在迁移出口流量时,工作负载和服务流量会受到一定影响,直到 Cluster Network Operator (CNO) 成功推出更改。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
| 字符串 |
如果您的现有网络基础架构与
默认值为 |
|
| 字符串 |
如果您的现有网络基础架构与
默认值为 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
| 字符串 |
如果您的现有网络基础架构与
默认值为 |
|
| 字符串 |
如果您的现有网络基础架构与
默认值为 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
| 整数 |
每个节点每秒生成一次的消息数量上限。默认值为每秒 |
|
| 整数 |
审计日志的最大大小,以字节为单位。默认值为 |
|
| 整数 | 保留的日志文件的最大数量。 |
|
| 字符串 | 以下附加审计日志目标之一:
|
|
| 字符串 |
syslog 工具,如 as |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
将此字段设置为
此字段与 Open vSwitch 硬件卸载功能有交互。如果将此字段设置为 |
|
|
|
您可以使用 |
|
|
| 可选:指定一个对象来为主机配置内部 OVN-Kubernetes 伪装地址,以服务 IPv4 地址的流量。 |
|
|
| 可选:指定一个对象来为主机配置内部 OVN-Kubernetes 伪装地址,以服务 IPv6 地址的流量。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
内部使用的伪装 IPv4 地址,以启用主机服务流量。主机配置了这些 IP 地址和共享网关网桥接口。默认值为 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
内部使用的伪装 IPv6 地址,以启用主机服务流量。主机配置了这些 IP 地址和共享网关网桥接口。默认值为 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定 IPsec 实现的行为。必须是以下值之一:
|
您只能在集群安装过程中更改集群网络插件的配置,但 gatewayConfig 字段可作为安装后活动在运行时更改。
启用 IPSec 的 OVN-Kubernetes 配置示例
使用 OVNKubernetes 可能会导致 IBM Power® 上的堆栈耗尽问题。
5.5.6.1.2. kubeProxyConfig 对象配置(仅限 OpenShiftSDN 容器网络接口) 复制链接链接已复制到粘贴板!
kubeProxyConfig 对象的值在下表中定义:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
注意
由于 OpenShift Container Platform 4.3 及更高版本中引进了性能改进,不再需要调整 |
|
|
|
刷新 kubeProxyConfig:
proxyArguments:
iptables-min-sync-period:
- 0s
|
5.5.6.2. Cluster Network Operator 配置示例 复制链接链接已复制到粘贴板!
以下示例中指定了完整的 CNO 配置:
Cluster Network Operator 对象示例
5.6. OpenShift Container Platform 中的 DNS Operator 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 中,DNS Operator 部署和管理 CoreDNS 实例,为集群中的 pod 提供名称解析服务,启用基于 DNS 的 Kubernetes 服务发现,并解析内部 cluster.local 名称。
5.6.1. 检查 DNS Operator 的状态 复制链接链接已复制到粘贴板!
DNS Operator 从 operator.openshift.io API 组实现 dns API。Operator 使用守护进程集部署 CoreDNS,为守护进程集创建一个服务,并将 kubelet 配置为指示 pod 使用 CoreDNS 服务 IP 地址进行名称解析。
流程
在安装过程中使用 Deployment 对象部署 DNS Operator。
使用
oc get命令查看部署状态:oc get -n openshift-dns-operator deployment/dns-operator
$ oc get -n openshift-dns-operator deployment/dns-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE dns-operator 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE dns-operator 1/1 1 1 23hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc get命令来查看 DNS Operator 的状态:oc get clusteroperator/dns
$ oc get clusteroperator/dnsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE dns 4.1.15-0.11 True False False 92m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE dns 4.1.15-0.11 True False False 92mCopy to Clipboard Copied! Toggle word wrap Toggle overflow AVAILABLE、PROGRESSING和DEGRADED提供了有关 Operator 状态的信息。当 CoreDNS 守护进程中至少有一个 pod 被设置为Available状态时,AVAILABLE为True,DNS 服务有一个集群 IP 地址。
5.6.2. 查看默认 DNS 复制链接链接已复制到粘贴板!
每个 OpenShift Container Platform 新安装都有一个名为 default 的 dns.operator。
流程
使用
oc describe命令来查看默认dns:oc describe dns.operator/default
$ oc describe dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要查找集群的服务 CIDR 范围,如
172.30.0.0/16,请使用oc get命令:oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'$ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.3. 使用 DNS 转发 复制链接链接已复制到粘贴板!
您可以使用以下方法使用 DNS 转发来覆盖 /etc/resolv.conf 文件中的默认转发配置:
-
为每个区指定名称服务器 (
spec.servers)。如果转发区是 OpenShift Container Platform 管理的 ingress 域,则必须为域授权上游名称服务器。 -
提供上游 DNS 服务器列表 (
spec.upstreamResolvers)。 - 更改默认转发策略。
默认域的 DNS 转发配置可以同时在 /etc/resolv.conf 文件和上游 DNS 服务器中指定默认服务器。
流程
修改名为
default的 DNS Operator 对象:oc edit dns.operator/default
$ oc edit dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 发出上一命令后,Operator 会根据
spec.servers创建并更新名为dns-default的配置映射,并使用额外的服务器配置块。如果任何服务器都没有与查询匹配的区域,则名称解析会返回上游 DNS 服务器。配置 DNS 转发
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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服务器进行查询的顺序。您可以指定这些值之一:Random、RoundRobin或Sequential。默认值为Sequential。 - 7
- 如果被省略,平台会选择一个默认值,通常是原始客户端请求的协议。设置为
TCP,以指定平台应该对所有上游 DNS 请求使用 TCP,即使客户端请求使用了 UDP。 - 8
- 用于配置传输类型、服务器名称和可选自定义 CA 或 CA 捆绑包,以便在将 DNS 请求转发到上游解析器时使用。
- 9
- 您可以指定两个类型的
upstreams:SystemResolvConf或Network。SystemResolvConf将上游配置为使用/etc/resolv.conf和Network定义一个Networkresolver。您可以指定其中一个或两者都指定。 - 10
- 如果指定类型是
Network,则必须提供 IP 地址。address字段必须是有效的 IPv4 或 IPv6 地址。 - 11
- 如果指定类型是
Network,您可以选择性地提供端口。port字段必须是1到65535之间的值。如果您没有为上游指定端口,则默认端口为 853。
5.6.4. 检查 DNS Operator 状态 复制链接链接已复制到粘贴板!
您可以使用 oc describe 命令来检查状态并查看 DNS Operator 的详情。
流程
查看 DNS Operator 的状态:
oc describe clusteroperators/dns
$ oc describe clusteroperators/dnsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 虽然在特定版本中的信息和拼写可能有所不同,但预期的状态输出如下:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.5. 查看 DNS Operator 日志 复制链接链接已复制到粘贴板!
您可以使用 oc logs 命令来查看 DNS Operator 日志。
流程
查看 DNS Operator 的日志:
oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.6. 设置 CoreDNS 日志级别 复制链接链接已复制到粘贴板!
CoreDNS 和 CoreDNS Operator 的日志级别使用不同的方法设置。您可以配置 CoreDNS 日志级别来确定日志记录错误信息中的详情量。CoreDNS 日志级别的有效值为 Normal、Debug 和 Trace。默认 logLevel 为 Normal。
CoreDNS 错误日志级别总是被启用。以下日志级别设置报告不同的错误响应:
-
logLevel:Normal启用 "errors" 类:log . { class error }. -
loglevel:Debug启用 "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$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要将
logLevel设置为Trace,输入以下命令:oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要确保设置了所需的日志级别,请检查配置映射:
oc get configmap/dns-default -n openshift-dns -o yaml
$ oc get configmap/dns-default -n openshift-dns -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如,在将
logLevel设置为Trace后,您应该在每个 server 块中看到这个小节:errors log . { class all }errors log . { class all }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.7. 查看 CoreDNS 日志 复制链接链接已复制到粘贴板!
您可以使用 oc logs 命令查看 CoreDNS 日志。
流程
输入以下命令来查看特定 CoreDNS pod 的日志:
oc -n openshift-dns logs -c dns <core_dns_pod_name>
$ oc -n openshift-dns logs -c dns <core_dns_pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令遵循所有 CoreDNS pod 的日志:
oc -n openshift-dns logs -c dns -l dns.operator.openshift.io/daemonset-dns=default -f --max-log-requests=<number>
$ oc -n openshift-dns logs -c dns -l dns.operator.openshift.io/daemonset-dns=default -f --max-log-requests=<number>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定要流传输日志的 DNS pod 数量。最大值为 6。
5.6.8. 设置 CoreDNS Operator 的日志级别 复制链接链接已复制到粘贴板!
CoreDNS 和 CoreDNS Operator 的日志级别使用不同的方法设置。集群管理员可以配置 Operator 日志级别来更快地跟踪 OpenShift DNS 问题。operatorLogLevel 的有效值为 Normal、Debug 和 Trace。Trace 具有更详细的信息。默认 operatorlogLevel 为 Normal。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$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要将
operatorLogLevel设置为Trace,请输入以下命令:oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要查看生成的更改,请输入以下命令:
oc get dnses.operator -A -oyaml
$ oc get dnses.operator -A -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您应该会看到两个日志级别条目。
operatorLogLevel适用于 OpenShift DNS Operator 问题,logLevel适用于 CoreDNS pod 的 daemonset:logLevel: Trace operatorLogLevel: Debug
logLevel: Trace operatorLogLevel: DebugCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要查看 daemonset 的日志,请输入以下命令:
oc logs -n openshift-dns ds/dns-default
$ oc logs -n openshift-dns ds/dns-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.9. 调整 CoreDNS 缓存 复制链接链接已复制到粘贴板!
对于 CoreDNS,您可以配置成功或不成功缓存的最长持续时间,也称为正缓存或负缓存。调整 DNS 查询响应的缓存持续时间可减少任何上游 DNS 解析器的负载。
将 TTL 字段设为低值可能会导致集群、任何上游解析器或两者中负载的增加。
流程
运行以下命令来编辑名为
default的 DNS Operator 对象:oc edit dns.operator.openshift.io/default
$ oc edit dns.operator.openshift.io/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 修改生存时间 (TTL) 缓存值:
配置 DNS 缓存
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要查看更改,请运行以下命令再次查看配置映射:
oc get configmap/dns-default -n openshift-dns -o yaml
$ oc get configmap/dns-default -n openshift-dns -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证您是否看到类似以下示例的条目:
cache 3600 { denial 9984 2400 }cache 3600 { denial 9984 2400 }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.10. 高级任务 复制链接链接已复制到粘贴板!
5.6.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以应用临时解决方案。
流程
在 DNS Operator 中将
managementState更改为Unmanaged:oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
jsonpath命令行 JSON 解析器查看 DNS Operator 的managementState:oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'$ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意当
managementState设置为Unmanaged时,您无法升级。
5.6.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 的守护进程集配置为在某些节点上运行或不运行。
先决条件
-
已安装
ocCLI。 -
以具有
cluster-admin权限的用户身份登录集群。 -
您的 DNS Operator
managementState设置为Managed。
流程
要允许 CoreDNS 的守护进程集在特定节点上运行,请配置污点和容限:
修改名为
default的 DNS Operator 对象:oc edit dns.operator/default
$ oc edit dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为污点指定污点键和一个容忍度:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 如果污点是
dns-only,它可以无限期地被容许。您可以省略tolerationSeconds。
5.6.10.3. 使用 TLS 配置 DNS 转发 复制链接链接已复制到粘贴板!
在高度监管的环境中工作时,您可能需要在将请求转发到上游解析器时保护 DNS 流量,以便您可以确保额外的 DNS 流量和数据隐私。
请注意,CoreDNS 缓存在 10 秒内转发连接。如果没有请求,CoreDNS 将为该 10 秒打开 TCP 连接。
对于大型集群,请确保您的 DNS 服务器知道可能有多个新的连接来保存打开,因为您可以在每个节点上启动连接。相应地设置 DNS 层次结构以避免性能问题。
流程
修改名为
default的 DNS Operator 对象:oc edit dns.operator/default
$ oc edit dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 集群管理员可以配置传输层安全(TLS)来转发 DNS 查询。
使用 TLS 配置 DNS 转发
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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必须是1到65535之间的值。如果您没有为上游指定端口,则默认端口为 853。
注意如果
servers未定义或无效,则配置映射只包括默认服务器。
验证
查看配置映射:
oc get configmap/dns-default -n openshift-dns -o yaml
$ oc get configmap/dns-default -n openshift-dns -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 基于 TLS 转发示例的 DNS ConfigMap 示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 对
forwardPlugin的更改会触发 CoreDNS 守护进程集的滚动更新。
5.7. OpenShift Container Platform 中的 Ingress Operator 复制链接链接已复制到粘贴板!
Ingress Operator 实现 IngressController API,是负责启用对 OpenShift Container Platform 集群服务的外部访问的组件。
5.7.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 端点的方法。
5.7.2. Ingress 配置资产 复制链接链接已复制到粘贴板!
安装程序在 config.openshift.io API 组中生成带有 Ingress 资源的资产,cluster-ingress-02-config.yml。
Ingress 资源的 YAML 定义
安装程序将这个资产保存在 manifests/ 目录下的 cluster-ingress-02-config.yml 文件中。此 Ingress 资源定义 Ingress 的集群范围配置。此 Ingress 配置的用法如下所示:
- Ingress Operator 使用集群 Ingress 配置中的域,作为默认 Ingress Controller 的域。
-
OpenShift API Server Operator 使用集群 Ingress 配置中的域。在为未指定显式主机的
Route资源生成默认主机时,还会使用此域。
5.7.3. Ingress Controller 配置参数 复制链接链接已复制到粘贴板!
IngressController 自定义资源(CR) 包含可选配置参数,您可以配置它们来满足您的机构的特定需求。
| 参数 | 描述 |
|---|---|
|
|
如果为空,默认值为 |
|
|
|
|
|
对于云环境,使用
在 Google Cloud、AWS 和 Azure 上,您可以配置以下
如果没有设置,则默认值基于
对于大多数平台,可以更新
对于非云环境,如裸机平台,请使用
如果您没有在这些字段中设置值,则默认值基于
如果需要在集群部署后更新
|
|
|
secret 必须包含以下密钥和数据:*
如果没有设置,则自动生成和使用通配符证书。该证书对 Ingress Controller 的 内部证书(无论是生成的证书还是用户指定的证书)自动与 OpenShift Container Platform 内置的 OAuth 服务器集成。 |
|
|
|
|
|
|
|
|
如果没有设置,则使用默认值。 注意
|
|
|
如果没有设置,则默认值基于
当使用
Ingress Controller 的最低 TLS 版本是 注意
加密器和配置的安全配置集的最小 TLS 版本反映在 重要
Ingress Operator 将 |
|
|
|
|
|
|
|
|
|
|
|
通过为
默认情况下,策略设置为
通过设置 这些调整仅应用于明文、边缘终止和重新加密路由,且仅在使用 HTTP/1 时有效。
对于请求标头,这些调整仅适用于具有
|
|
|
|
|
|
|
|
|
对于您要捕获的任何 Cookie,以下参数必须位于
例如: httpCaptureCookies:
- matchType: Exact
maxLength: 128
name: MYCOOKIE
|
|
|
|
|
|
|
|
|
|
|
|
这些连接来自负载均衡器健康探测或 Web 浏览器规范连接(预连接),可以安全地忽略。但是,这些请求可能是由网络错误造成的,因此将此字段设置为 |
5.7.3.1. Ingress Controller TLS 安全配置集 复制链接链接已复制到粘贴板!
TLS 安全配置文件为服务器提供了一种方式,以规范连接的客户端在连接服务器时可以使用哪些密码。
5.7.3.1.1. 了解 TLS 安全配置集 复制链接链接已复制到粘贴板!
您可以使用 TLS(Transport Layer Security)安全配置集来定义各种 OpenShift Container Platform 组件需要哪些 TLS 密码。OpenShift Container Platform TLS 安全配置集基于 Mozilla 推荐的配置。
您可以为每个组件指定以下 TLS 安全配置集之一:
| profile | 描述 |
|---|---|
|
| 此配置集用于旧的客户端或库。该配置集基于旧的向后兼容性建议配置。
注意 对于 Ingress Controller,最小 TLS 版本从 1.0 转换为 1.1。 |
|
| 此配置集是 Ingress Controller、kubelet 和 control plane 的默认 TLS 安全配置集。该配置集基于 Intermediate 兼容性推荐的配置。
注意 这个配置集是大多数客户端的建议配置。 |
|
| 此配置集主要用于不需要向后兼容的现代客户端。这个配置集基于 Modern 兼容性推荐的配置。
|
|
| 此配置集允许您定义要使用的 TLS 版本和密码。 警告
使用 |
当使用预定义的配置集类型时,有效的配置集配置可能会在发行版本之间有所改变。例如,使用在版本 X.Y.Z 中部署的 Intermediate 配置集指定了一个规格,升级到版本 X.Y.Z+1 可能会导致应用新的配置集配置,从而导致推出部署。
5.7.3.1.2. 为 Ingress Controller 配置 TLS 安全配置集 复制链接链接已复制到粘贴板!
要为 Ingress Controller 配置 TLS 安全配置集,请编辑 IngressController 自定义资源(CR)来指定预定义或自定义 TLS 安全配置集。如果没有配置 TLS 安全配置集,则默认值基于为 API 服务器设置的 TLS 安全配置集。
配置 Old TLS 安全配置集的 IngressController CR 示例
TLS 安全配置集定义 Ingress Controller 的 TLS 连接的最低 TLS 版本和 TLS 密码。
您可以在 Status.Tls Profile 和 Spec.Tls Security Profile 下看到 IngressController 自定义资源(CR)中配置的 TLS 安全配置集的密码和最小 TLS 版本。对于 Custom TLS 安全配置集,这两个参数下列出了特定的密码和最低 TLS 版本。
HAProxy Ingress Controller 镜像支持 TLS 1.3 和 Modern 配置集。
Ingress Operator 还会将 Old 或 Custom 配置集的 TLS 1.0 转换为 1.1。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。
流程
编辑
openshift-ingress-operator项目中的IngressControllerCR,以配置 TLS 安全配置集:oc edit IngressController default -n openshift-ingress-operator
$ oc edit IngressController default -n openshift-ingress-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 添加
spec.tlsSecurityProfile字段:Custom配置集的IngressControllerCR 示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存文件以使改变生效。
验证
验证
IngressControllerCR 中是否设置了配置集:oc describe IngressController default -n openshift-ingress-operator
$ oc describe IngressController default -n openshift-ingress-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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.crlIssuer: 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.crlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
在
openshift-config命名空间中,从 CA 捆绑包创建配置映射:oc create configmap \ router-ca-certs-default \ --from-file=ca-bundle.pem=client-ca.crt \ -n openshift-config
$ oc create configmap \ router-ca-certs-default \ --from-file=ca-bundle.pem=client-ca.crt \1 -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 配置映射数据键必须是
ca-bundle.pem,数据值必须是 PEM 格式的 CA 证书。
编辑
openshift-ingress-operator项目中的IngressController资源:oc edit IngressController default -n openshift-ingress-operator
$ oc edit IngressController default -n openshift-ingress-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 添加
spec.clientTLS字段和子字段来配置 mutual TLS:指定过滤模式的
clientTLS配置集的IngressControllerCR 示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选,输入以下命令获取
allowedSubjectPatterns的可辨识名称 (DN)。openssl x509 -in custom-cert.pem -noout -subject
$ openssl x509 -in custom-cert.pem -noout -subjectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
subject=C=US, ST=NC, O=Security, OU=OpenShift, CN=example.com
subject=C=US, ST=NC, O=Security, OU=OpenShift, CN=example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.5. 查看 Ingress Operator 状态 复制链接链接已复制到粘贴板!
您可以查看并检查 Ingress Operator 的状态。
流程
查看您的 Ingress Operator 状态:
oc describe clusteroperators/ingress
$ oc describe clusteroperators/ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.6. 查看 Ingress Controller 日志 复制链接链接已复制到粘贴板!
您可以查看 Ingress Controller 日志。
流程
查看 Ingress Controller 日志:
oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.7. 查看 Ingress Controller 状态 复制链接链接已复制到粘贴板!
您可以查看特定 Ingress Controller 的状态。
流程
查看 Ingress Controller 的状态:
oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.8. 创建自定义 Ingress Controller 复制链接链接已复制到粘贴板!
作为集群管理员,您可以创建新的自定义 Ingress Controller。因为默认 Ingress Controller 在 OpenShift Container Platform 更新过程中可能会改变,所以创建自定义 Ingress Controller 以在集群更新中手动保留配置会很有用。
这个示例为自定义 Ingress Controller 提供最小规格。要进一步定制您的自定义 Ingress Controller,请参阅"配置 Ingress Controller"。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建定义自定义
IngressController对象的 YAML 文件:custom-ingress-controller.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建对象:
oc create -f custom-ingress-controller.yaml
$ oc create -f custom-ingress-controller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9. 配置 Ingress Controller 复制链接链接已复制到粘贴板!
5.7.9.1. 设置自定义默认证书 复制链接链接已复制到粘贴板!
作为管理员,您可以通过创建 Secret 资源并编辑 IngressController 自定义资源 (CR),将 Ingress Controller 配置为使用自定义证书。
先决条件
- 您必须在 PEM 编码文件中有一个证书/密钥对,其中该证书由可信证书认证机构签名,或者由您在一个自定义 PKI 中配置的私有可信证书认证机构签名。
您的证书满足以下要求:
- 该证书对入口域有效。
-
证书使用
subjectAltName扩展来指定通配符域,如*.apps.ocp4.example.com。
您必须有一个
IngressControllerCR,它仅包含defaultIngressControllerCR。您可以运行以下命令来检查是否有IngressControllerCR:oc --namespace openshift-ingress-operator get ingresscontrollers
$ oc --namespace openshift-ingress-operator get ingresscontrollersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
如果您有中间证书,则必须将其包含在包含自定义默认证书的 secret 的 tls.crt 文件中。指定证书时指定的顺序是相关的; 在任意服务器证书后列出您的中间证书。
流程
以下步骤假定自定义证书和密钥对位于当前工作目录下的 tls.crt 和 tls.key 文件中。替换 tls.crt 和 tls.key 的实际路径名。在创建 Secret 资源并在 IngressController CR 中引用它时,您也可以将 custom-certs-default 替换成另一名称。
此操作会导致使用滚动部署策略重新部署 Ingress Controller。
使用
tls.crt和tls.key文件,创建在openshift-ingress命名空间中包含自定义证书的 Secret 资源。oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 更新 IngressController CR,以引用新的证书 Secret:
oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \ --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'$ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \ --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 验证更新是否已生效:
echo Q |\ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\ openssl x509 -noout -subject -issuer -enddate
$ echo Q |\ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\ openssl x509 -noout -subject -issuer -enddateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<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
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 GMCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来设置自定义默认证书:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 证书 Secret 名称应该与用来更新 CR 的值匹配。
修改了 IngressController CR 后,Ingress Operator 将更新 Ingress Controller 的部署以使用自定义证书。
5.7.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'
$ oc patch -n openshift-ingress-operator ingresscontrollers/default \ --type json -p $'- op: remove\n path: /spec/defaultCertificate'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 集群协调新证书配置时可能会有延迟。
验证
要确认原始集群证书已被恢复,请输入以下命令:
echo Q | \ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \ openssl x509 -noout -subject -issuer -enddate
$ echo Q | \ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \ openssl x509 -noout -subject -issuer -enddateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<domain>- 指定集群的基域名。
输出示例
subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMT
subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMTCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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实例。
-
您可以在 Web 控制台中使用 OperatorHub 安装 Operator。安装 Operator 后,您可以创建
流程
运行以下命令,创建一个服务帐户来与 Thanos 进行身份验证:
oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
$ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanosCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令手动创建服务帐户令牌:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用服务帐户的令牌,在
openshift-ingress-operator命名空间中定义一个TriggerAuthentication对象。创建
TriggerAuthentication对象,并将secret变量的值传递给TOKEN参数:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建并应用角色以从 Thanos 读取指标:
创建一个新角色
thanos-metrics-reader.yaml,从 pod 和节点读取指标:thanos-metrics-reader.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来应用新角色:
oc apply -f thanos-metrics-reader.yaml
$ oc apply -f thanos-metrics-reader.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
输入以下命令在服务帐户中添加新角色:
oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
$ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
$ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanosCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意只有在使用跨命名空间查询时,才需要参数
add-cluster-role-to-user。以下步骤使用kube-metrics命名空间中的查询,该命名空间需要此参数。创建一个新的
ScaledObjectYAML 文件ingress-autoscaler.yaml,该文件以默认 Ingress Controller 部署为目标:ScaledObject定义示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要如果使用跨命名空间查询,您必须在
serverAddress字段中目标端口 9091 而不是端口 9092。您还必须有升级的特权,才能从此端口读取指标。运行以下命令来应用自定义资源定义:
oc apply -f ingress-autoscaler.yaml
$ oc apply -f ingress-autoscaler.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,验证默认 Ingress Controller 是否已扩展以匹配
kube-state-metrics查询返回的值:使用
grep命令搜索 Ingress Controller YAML 文件以查找副本数量:oc get -n openshift-ingress-operator ingresscontroller/default -o yaml | grep replicas:
$ oc get -n openshift-ingress-operator ingresscontroller/default -o yaml | grep replicas:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 获取
openshift-ingress项目中的 pod:oc get pods -n openshift-ingress
$ oc get pods -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
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 66sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9.4. 扩展 Ingress Controller 复制链接链接已复制到粘贴板!
手动扩展 Ingress Controller 以满足路由性能或可用性要求,如提高吞吐量的要求。oc 命令用于扩展 IngressController 资源。以下流程提供了扩展默认 IngressController 的示例。
扩展不是立刻就可以完成的操作,因为它需要时间来创建所需的副本数。
流程
查看默认
IngressController的当前可用副本数:oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc patch命令将默认IngressController扩展到所需的副本数。以下示例将默认IngressController扩展至 3 个副本:oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证默认
IngressController是否已扩展至您指定的副本数:oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 将 Ingress Controller 扩展为三个副本:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 如果需要不同数量的副本,请更改
replicas值。
5.7.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 容器,您必须指定Containerspec.logging.access.destination.type。以下示例是将日志记录到Container目的地的 Ingress Controller 定义:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当将 Ingress Controller 配置为日志记录到 sidecar 时,Operator 会在 Ingress Controller Pod 中创建一个名为
logs的容器:oc -n openshift-ingress logs deployment.apps/router-default -c logs
$ oc -n openshift-ingress logs deployment.apps/router-default -c logsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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"
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 Copied! Toggle word wrap Toggle overflow
配置 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 定义:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意Syslog目的地端口必须是 UDP。syslog目标地址必须是 IP 地址。它不支持 DNS 主机名。
使用特定的日志格式配置 Ingress 访问日志。
您可以指定
spec.logging.access.httpLogFormat来自定义日志格式。以下示例是一个 Ingress Controller 定义,它将日志记录到 IP 地址为 1.2.3.4、端口为 10514 的syslog端点:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
禁用 Ingress 访问日志。
要禁用 Ingress 访问日志,请保留
spec.logging或spec.logging.access为空:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
允许 Ingress Controller 在使用 sidecar 时,修改 HAProxy 日志长度。
如果您使用
spec.logging.access.destination.syslog.maxLength,请使用spec.logging.access.destination.type: Syslog。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您使用
spec.logging.access.destination.container.maxLength,请使用spec.logging.access.destination.type: Container。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
要使用
Ingress访问日志中的X-Forwarded-For标头查看原始客户端源 IP 地址,请参阅 Ingress 和 Application Logs 中的 X-Forwarded-For Header 中的 X-Forwarded-For Header 中的 "Capturing Original Client IP 地址。
5.7.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}}}'$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果您的节点有能力运行大量资源,您可以使用与预期节点容量匹配的标签配置
spec.nodePlacement.nodeSelector,并将spec.tuningOptions.threadCount配置为一个适当的高值。
5.7.9.7. 配置 Ingress Controller 以使用内部负载均衡器 复制链接链接已复制到粘贴板!
当在云平台上创建 Ingress Controller 时,Ingress Controller 默认由一个公共云负载均衡器发布。作为管理员,您可以创建一个使用内部云负载均衡器的 Ingress Controller。
如果云供应商是 Microsoft Azure,则必须至少有一个指向节点的公共负载均衡器。如果不这样做,所有节点都将丢失到互联网的出站连接。
如果要更改 IngressController 的 scope,您可以在创建自定义资源(CR)后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。
图 5.2. LoadBalancer 图表
上图显示了与 OpenShift Container Platform Ingress LoadBalancerService 端点发布策略相关的以下概念:
- 您可以使用 OpenShift Ingress Controller Load Balancer 在外部使用云供应商负载均衡器或内部加载负载。
- 您可以使用负载均衡器的单个 IP 地址以及更熟悉的端口,如 8080 和 4200,如图形中所述的集群所示。
- 来自外部负载均衡器的流量定向到 pod,并由负载均衡器管理,如下节点的实例中所述。有关实现详情请查看 Kubernetes 服务文档 。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
在名为
<name>-ingress-controller.yaml的文件中创建IngressController自定义资源 (CR) ,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,创建上一步中定义的 Ingress Controller:
oc create -f <name>-ingress-controller.yaml
$ oc create -f <name>-ingress-controller.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<name>替换为IngressController对象的名称。
可选:通过运行以下命令确认创建了 Ingress Controller:
oc --all-namespaces=true get ingresscontrollers
$ oc --all-namespaces=true get ingresscontrollersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9.8. 在 Google Cloud 上为 Ingress Controller 配置全局访问 复制链接链接已复制到粘贴板!
在带有内部负载均衡器的 Google Cloud 上创建的 Ingress Controller 会为该服务生成内部 IP 地址。集群管理员可指定全局访问选项,该选项可启用同一 VPC 网络内任何区域中的客户端作为负载均衡器,以访问集群上运行的工作负载。
如需更多信息,请参阅 Google Cloud 文档以了解 全局访问。
先决条件
- 您已在 Google Cloud 基础架构上部署了 OpenShift Container Platform 集群。
- 已将 Ingress Controller 配置为使用内部负载均衡器。
-
已安装 OpenShift CLI(
oc)。
流程
配置 Ingress Controller 资源,以允许全局访问。
注意您还可以创建 Ingress Controller 并指定全局访问选项。
配置 Ingress Controller 资源:
oc -n openshift-ingress-operator edit ingresscontroller/default
$ oc -n openshift-ingress-operator edit ingresscontroller/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑 YAML 文件:
clientAccess配置为Global的示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
gcp.clientAccess设置为Global。
- 保存文件以使改变生效。
运行以下命令,以验证该服务是否允许全局访问:
oc -n openshift-ingress edit svc/router-default -o yaml
$ oc -n openshift-ingress edit svc/router-default -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示,使用注解
networking.gke.io/internal-load-balancer-allow-global-access的 Google Cloud 启用了全局访问。
5.7.9.9. 设置 Ingress Controller 健康检查间隔 复制链接链接已复制到粘贴板!
集群管理员可以设置健康检查间隔,以定义路由器在两个连续健康检查之间等待的时间。这个值会作为所有路由的默认值进行全局应用。默认值为 5 秒。
先决条件
- 以下假设您已创建了 Ingress Controller。
流程
更新 Ingress Controller,以更改后端健康检查之间的间隔:
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意要覆盖单个路由的
healthCheckInterval,请使用路由注解router.openshift.io/haproxy.health.check.interval
5.7.9.10. 将集群的默认 Ingress Controller 配置为内部 复制链接链接已复制到粘贴板!
您可以通过删除并重新它来将默认 Ingress Controller 配置为内部。
如果云供应商是 Microsoft Azure,则必须至少有一个指向节点的公共负载均衡器。如果不这样做,所有节点都将丢失到互联网的出站连接。
如果要更改 IngressController 的 scope,您可以在创建自定义资源(CR)后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
通过删除并重新创建集群,将
默认Ingress Controller 配置为内部。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9.11. 配置路由准入策略 复制链接链接已复制到粘贴板!
管理员和应用程序开发人员可在多个命名空间中运行具有相同域名的应用程序。这是针对多个团队开发的、在同一个主机名上公开的微服务的机构。
只有在命名空间间有信任的集群才会启用跨命名空间之间的声明,否则恶意用户可能会接管主机名。因此,默认的准入策略不允许在命名空间间声明主机名。
先决条件
- 必须具有集群管理员权限。
流程
使用以下命令编辑
ingresscontroller资源变量的.spec.routeAdmission 字段:oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge$ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress 控制器配置参数
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来配置路由准入策略:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9.12. 使用通配符路由 复制链接链接已复制到粘贴板!
HAProxy Ingress Controller 支持通配符路由。Ingress Operator 使用 wildcardPolicy 来配置 Ingress Controller 的 ROUTER_ALLOW_WILDCARD_ROUTES 环境变量。
Ingress Controller 的默认行为是接受采用 None 通配符策略的路由,该策略与现有 IngressController 资源向后兼容。
流程
配置通配符策略。
使用以下命令来编辑
IngressController资源:oc edit IngressController
$ oc edit IngressControllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
spec下,将wildcardPolicy字段设置为 WildcardsDisallowed或WildcardsAllowed:spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowedspec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9.13. HTTP 标头配置 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了不同的使用 HTTP 标头的方法。在设置或删除标头时,您可以使用 Ingress Controller 中的特定字段或单独的路由来修改请求和响应标头。您还可以使用路由注解设置某些标头。配置标头的各种方法在协同工作时可能会带来挑战。
您只能在 IngressController 或 Route CR 中设置或删除标头,您无法附加它们。如果使用值设置 HTTP 标头,则该值必须已完成,且在以后不需要附加。在附加标头(如 X-Forwarded-For 标头)时,请使用 spec.httpHeaders.forwardedHeaderPolicy 字段,而不是 spec.httpHeaders.actions。
5.7.9.13.1. 优先级顺序 复制链接链接已复制到粘贴板!
当在 Ingress Controller 和路由中修改相同的 HTTP 标头时,HAProxy 会根据它是请求还是响应标头来优先选择操作。
- 对于 HTTP 响应标头,Ingress Controller 中指定的操作会在路由中指定的操作后执行。这意味着 Ingress Controller 中指定的操作具有优先权。
- 对于 HTTP 请求标头,路由中指定的操作会在 Ingress Controller 中指定的操作后执行。这意味着路由中指定的操作具有优先权。
例如,集群管理员使用以下配置设置 X-Frame-Options 响应标头,其值为 DENY :
IngressController spec 示例
路由所有者设置 Ingress Controller 中设置的相同响应标头,但使用以下配置值 SAMEORIGIN :
Route 规格示例
当 IngressController spec 和 Route spec 都配置 X-Frame-Options 标头时,Ingress Controller 中的全局级别为这个标头设置的值将具有优先权,即使一个特定的路由允许帧。对于请求标头,Route spec 值会覆盖 IngressController spec 值。
发生这个优先级,因为 haproxy.config 文件使用以下逻辑,其中 Ingress Controller 被视为前端,单独的路由被视为后端。应用到前端配置的标头值 DENY 使用后端中设置的值 SAMEORIGIN 覆盖相同的标头:
另外,Ingress Controller 或路由中定义的任何操作都覆盖使用路由注解设置的值。
5.7.9.13.2. 特殊情况标头 复制链接链接已复制到粘贴板!
以下标头可能会阻止完全被设置或删除,或者在特定情况下允许:
| 标头名称 | 使用 IngressController spec 进行配置 | 使用 Route 规格进行配置 | 禁止的原因 | 使用其他方法进行配置 |
|---|---|---|---|---|
|
| 否 | 否 |
| 否 |
|
| 否 | 是 |
当使用 | 否 |
|
| 否 | 否 |
|
是: |
|
| 否 | 否 | HAProxy 集的 Cookie 用于会话跟踪,用于将客户端连接映射到特定的后端服务器。允许设置这些标头可能会影响 HAProxy 的会话关联,并限制 HAProxy 的 Cookie 的所有权。 | 是:
|
5.7.9.14. 在 Ingress Controller 中设置或删除 HTTP 请求和响应标头 复制链接链接已复制到粘贴板!
出于合规的原因,您可以设置或删除某些 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 集群。
流程
编辑 Ingress Controller 资源:
oc -n openshift-ingress-operator edit ingresscontroller/default
$ oc -n openshift-ingress-operator edit ingresscontroller/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 X-SSL-Client-Der HTTP 请求标头替换为 X-Forwarded-Client-Cert HTTP 请求标头:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意对于 HTTP 响应设置动态标头值,允许示例 fetchers 是
res.hdr和ssl_c_der。对于 HTTP 请求设置动态标头值,允许示例获取器为req.hdr和ssl_c_der。请求和响应动态值都可以使用lower和base64转换器。- 保存文件以使改变生效。
5.7.9.15. 使用 X-Forwarded 标头 复制链接链接已复制到粘贴板!
您可以将 HAProxy Ingress Controller 配置为指定如何处理 HTTP 标头的策略,其中包括 Forwarded 和 X-Forwarded-For。Ingress Operator 使用 HTTPHeaders 字段配置 Ingress Controller 的 ROUTER_SET_FORWARDED_HEADERS 环境变量。
流程
为 Ingress Controller 配置
HTTPHeaders字段。使用以下命令来编辑
IngressController资源:oc edit IngressController
$ oc edit IngressControllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
spec下,将HTTPHeaders策略字段设置为Append、Replace、IfNone或Never:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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-none或haproxy.router.openshift.io/set-forwarded-headers: never。注意您可以根据每个路由设置
haproxy.router.openshift.io/set-forwarded-headers注解,独立于 Ingress Controller 的全局设置值。
5.7.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 协议。
5.7.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
$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<ingresscontroller_name>替换为 Ingress Controller 的名称以启用 HTTP/2。
要为整个集群启用 HTTP/2,请输入
oc annotate命令:oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
或者,您可以应用以下 YAML 代码来启用 HTTP/2:
5.7.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
$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=false1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<ingresscontroller_name>替换为 Ingress Controller 的名称以禁用 HTTP/2。
要为整个集群禁用 HTTP/2,请输入
oc annotate命令:oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=false
$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
或者,您可以应用以下 YAML 代码来禁用 HTTP/2:
5.7.9.17. 为 Ingress Controller 配置 PROXY 协议 复制链接链接已复制到粘贴板!
当 Ingress Controller 使用 HostNetwork、NodePortService 或 Private 端点发布策略类型时,集群管理员可以配置 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 路由器设置 Forwarded 和 X-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。
流程
在 CLI 中输入以下命令来编辑 Ingress Controller 资源:
oc -n openshift-ingress-operator edit ingresscontroller/default
$ oc -n openshift-ingress-operator edit ingresscontroller/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 设置 PROXY 配置:
如果您的 Ingress Controller 使用
HostNetwork端点发布策略类型,请将spec.endpointPublishingStrategy.hostNetwork.protocol子字段设置为PROXY:hostNetwork配置为PROXY的示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您的 Ingress Controller 使用
NodePortService端点发布策略类型,请将spec.endpointPublishingStrategy.nodePort.protocol子字段设置为PROXY:nodePort配置为PROXY示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您的 Ingress Controller 使用
Private端点发布策略类型,请将spec.endpointPublishingStrategy.private.protocol子字段设置为PROXY:到
PROXY的私有配置示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9.18. 使用 appsDomain 选项指定备选集群域 复制链接链接已复制到粘贴板!
作为集群管理员,您可以通过配置 appsDomain 字段来为用户创建的路由指定默认集群域替代内容。appsDomain 字段是 OpenShift Container Platform 使用的可选域,而不是默认值,它在 domain 字段中指定。如果您指定了其它域,它会覆盖为新路由确定默认主机的目的。
例如,您可以将您公司的 DNS 域用作集群中运行的应用程序的路由和入口的默认域。
先决条件
- 已部署 OpenShift Container Platform 集群。
-
已安装
oc命令行界面。
流程
通过为用户创建的路由指定备选默认域来配置
appsDomain字段。编辑 ingress
集群资源 :oc edit ingresses.config/cluster -o yaml
$ oc edit ingresses.config/cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑 YAML 文件:
示例
appsDomain配置为test.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
通过公开路由并验证路由域更改,验证现有路由是否包含
appsDomain字段中指定的域名:注意在公开路由前,等待
openshift-apiserver完成滚动更新。输入以下命令公开路由。命令输出
route.route.openshift.io/hello-openshift以指定公开路由。oc expose service hello-openshift
$ oc expose service hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来获取路由列表:
oc get routes
$ oc get routesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hello-openshift hello_openshift-<my_project>.test.example.com hello-openshift 8080-tcp None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hello-openshift hello_openshift-<my_project>.test.example.com hello-openshift 8080-tcp NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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 标头。运行以下命令,将 HTTP 标头从
host更改为Host:oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
Route资源 YAML 文件,以便注解可应用到应用程序。名为
my-application的路由示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 设置
haproxy.router.openshift.io/h1-adjust-case,以便 Ingress Controller 能够调整指定的host请求标头。
通过在 Ingress Controller YAML 配置文件中配置
HeaderNameCaseAdjustments字段指定调整。以下示例 Ingress Controller YAML 文件将 HTTP/1 请求的
host标头调整为Host,以适当地注解路由:Ingress Controller YAML 示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下示例路由中,使用
haproxy.router.openshift.io/h1-adjust-case注解启用对 HTTP 响应标头名称的大小写调整:路由 YAML 示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
haproxy.router.openshift.io/h1-adjust-case设置为 true。
5.7.9.20. 使用路由器压缩 复制链接链接已复制到粘贴板!
您可以将 HAProxy Ingress Controller 配置为为特定 MIME 类型全局指定路由器压缩。您可以使用 mimeTypes 变量定义压缩应用到的 MIME 类型的格式。类型包括:application, image, message, multipart, text, video, 或带有一个 "X-" 前缀的自定义类型。要查看 MIME 类型和子类型的完整表示法,请参阅 RFC1341。
为压缩分配的内存可能会影响最大连接。此外,对大型缓冲区的压缩可能导致延迟,如非常复杂的正则表达式或较长的正则表达式列表。
并非所有 MIME 类型从压缩中受益,但 HAProxy 仍然使用资源在指示时尝试压缩。通常而言,文本格式(如 html、css 和 js)与压缩格式获益,但已经压缩的格式(如图像、音频和视频)可能会因为需要压缩操作而无法获得太多的好处。
流程
为 Ingress Controller 配置
httpCompression字段。使用以下命令来编辑
IngressController资源:oc edit -n openshift-ingress-operator ingresscontrollers/default
$ oc edit -n openshift-ingress-operator ingresscontrollers/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
spec下,将httpCompression策略字段设置为mimeTypes,并指定应该应用压缩的 MIME 类型列表:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9.21. 公开路由器指标 复制链接链接已复制到粘贴板!
您可以在默认统计端口 1936 上以 Prometheus 格式公开 HAProxy 路由器指标。外部指标收集和聚合系统(如 Prometheus)可以访问 HAProxy 路由器指标。您可以在浏览器中以 HTML 的形式和以逗号分隔的值 (CSV) 格式查看 HAProxy 路由器指标。
先决条件
- 您已将防火墙配置为访问默认统计数据端口 1936。
流程
运行以下命令来获取路由器 pod 名称:
oc get pods -n openshift-ingress
$ oc get pods -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE router-default-76bfffb66c-46qwp 1/1 Running 0 11h
NAME READY STATUS RESTARTS AGE router-default-76bfffb66c-46qwp 1/1 Running 0 11hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 获取路由器的用户名和密码,路由器 Pod 存储在
/var/lib/haproxy/conf/metrics-auth/statsUsername和/var/lib/haproxy/conf/metrics-auth/statsPassword文件中:运行以下命令来获取用户名:
oc rsh <router_pod_name> cat metrics-auth/statsUsername
$ oc rsh <router_pod_name> cat metrics-auth/statsUsernameCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来获取密码:
oc rsh <router_pod_name> cat metrics-auth/statsPassword
$ oc rsh <router_pod_name> cat metrics-auth/statsPasswordCopy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令,获取路由器 IP 和指标证书:
oc describe pod <router_pod>
$ oc describe pod <router_pod>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,以 Prometheus 格式获取原始统计信息:
curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来安全地访问指标:
curl -u user:password https://<router_IP>:<stats_port>/metrics -k
$ curl -u user:password https://<router_IP>:<stats_port>/metrics -kCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,访问默认的 stats 端口 1936:
curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例 5.1. 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过在浏览器中输入以下 URL 来启动 stats 窗口:
http://<user>:<password>@<router_IP>:<stats_port>
http://<user>:<password>@<router_IP>:<stats_port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:通过在浏览器中输入以下 URL 来获取 CSV 格式的统计信息:
http://<user>:<password>@<router_ip>:1936/metrics;csv
http://<user>:<password>@<router_ip>:1936/metrics;csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9.22. 自定义 HAProxy 错误代码响应页面 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为 503、404 或两个错误页面指定自定义错误代码响应页面。当应用 Pod 没有运行时,HAProxy 路由器会提供一个 503 错误页面,如果请求的 URL 不存在,则 HAProxy 路由器会提供 404 错误页面。例如,如果您自定义 503 错误代码响应页面,则应用 Pod 未运行时会提供页面,并且 HAProxy 路由器为不正确的路由或不存在的路由提供默认的 404 错误代码 HTTP 响应页面。
自定义错误代码响应页面在配置映射中指定,然后修补至 Ingress Controller。配置映射键有两个可用的文件名,如下所示:error-page-503.http 和 error-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 行结尾。
流程
在
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
$ oc -n openshift-config create configmap my-custom-error-code-pages \ --from-file=error-page-503.http \ --from-file=error-page-404.httpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要如果没有为自定义错误代码响应页面指定正确的格式,则会出现路由器 pod 中断。要解决此中断,您必须删除或更正配置映射并删除受影响的路由器 pod,以便使用正确的信息重新创建它们。
对 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$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Operator 将
my-custom-error-code-pages配置映射从openshift-config命名空间复制到openshift-ingress命名空间。Operator 根据openshift-ingress命名空间中的模式<your_ingresscontroller_name>-errorpages命名配置映射。显示副本:
oc get cm default-errorpages -n openshift-ingress
$ oc get cm default-errorpages -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME DATA AGE default-errorpages 2 25s
NAME DATA AGE default-errorpages 2 25s1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 配置映射名称示例为
default-errorpages,因为defaultIngress Controller 自定义资源 (CR) 已被修补。
确认包含自定义错误响应页面的配置映射挂载到路由器卷中,其中配置映射键是具有自定义 HTTP 错误代码响应的文件名:
对于 503 自定义 HTTP 自定义错误代码响应:
oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.httpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 对于 404 自定义 HTTP 自定义错误代码响应:
oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.httpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证自定义错误代码 HTTP 响应:
创建测试项目和应用程序:
oc new-project test-ingress
$ oc new-project test-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-app django-psql-example
$ oc new-app django-psql-exampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 对于 503 自定义 http 错误代码响应:
- 停止应用的所有容器集。
运行以下 curl 命令或在浏览器中访问路由主机名:
curl -vk <route_hostname>
$ curl -vk <route_hostname>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
对于 404 自定义 http 错误代码响应:
- 访问不存在的路由或路由不正确。
运行以下 curl 命令或在浏览器中访问路由主机名:
curl -vk <route_hostname>
$ curl -vk <route_hostname>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
检查
haproxy.config文件中的errorfile属性是否正确:oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
$ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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}}}'$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告如果您设置了大于当前操作系统的
spec.tuningOptions.maxConnections值,则 HAProxy 进程不会启动。有关这个参数的更多信息,请参阅"Ingress Controller 配置参数"部分中的表。
Ingress Node Firewall Operator 提供了一个无状态的、基于 eBPF 的防火墙,用于管理 OpenShift Container Platform 中的节点级别的入口流量。
5.8.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。
5.8.2. 安装 Ingress Node Firewall Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 OpenShift Container Platform CLI 或 Web 控制台安装 Ingress Node Firewall Operator。
5.8.2.1. 使用 CLI 安装 Ingress Node Firewall Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 CLI 安装 Operator。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 有管理员特权的帐户。
流程
运行以下命令来创建
openshift-ingress-node-firewall命名空间:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
OperatorGroupCR:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 订阅 Ingress Node Firewall Operator。
要为 Ingress Node Firewall Operator 创建
SubscriptionCR,请输入以下命令:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
要验证是否已安装 Operator,请输入以下命令:
oc get ip -n openshift-ingress-node-firewall
$ oc get ip -n openshift-ingress-node-firewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME CSV APPROVAL APPROVED install-5cvnz ingress-node-firewall.4.16.0-202211122336 Automatic true
NAME CSV APPROVAL APPROVED install-5cvnz ingress-node-firewall.4.16.0-202211122336 Automatic trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证 Operator 的版本,请输入以下命令:
oc get csv -n openshift-ingress-node-firewall
$ oc get csv -n openshift-ingress-node-firewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME DISPLAY VERSION REPLACES PHASE ingress-node-firewall.4.16.0-202211122336 Ingress Node Firewall Operator 4.16.0-202211122336 ingress-node-firewall.4.16.0-202211102047 Succeeded
NAME DISPLAY VERSION REPLACES PHASE ingress-node-firewall.4.16.0-202211122336 Ingress Node Firewall Operator 4.16.0-202211122336 ingress-node-firewall.4.16.0-202211102047 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8.2.2. 使用 Web 控制台安装 Ingress Node Firewall Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 Web 控制台安装 Operator。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 有管理员特权的帐户。
流程
安装 Ingress Node Firewall Operator:
- 在 OpenShift Container Platform Web 控制台中,点击 Operators → OperatorHub。
- 从可用的 Operator 列表中选择 Ingress Node Firewall Operator,然后点 Install。
- 在 Install Operator 页面中,在 Installed Namespace 下选择 Operator recommended Namespace。
- 点 Install。
验证 Ingress Node Firewall Operator 是否已成功安装:
- 导航到 Operators → Installed Operators 页面。
确保 openshift-ingress-node-firewall 项目中列出的 Ingress Node Firewall Operator 的 Status 为 InstallSucceeded。
注意在安装过程中,Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息,您可以忽略这个 Failed 信息。
如果 Operator 没有 InstallSucceeded 状态,请按照以下步骤进行故障排除:
- 检查 Operator Subscriptions 和 Install Plans 选项卡中的 Status 项中是否有任何错误。
-
进入到 Workloads → Pods 页面,在
openshift-ingress-node-firewall项目中检查 pod 的日志。 检查 YAML 文件的命名空间。如果缺少注解,您可以使用以下命令将注解
workload.openshift.io/allowed=management添加到 Operator 命名空间中:oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
$ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=managementCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意对于单节点 OpenShift 集群,
openshift-ingress-node-firewall命名空间需要workload.openshift.io/allowed=management注解。
5.8.3. 部署 Ingress Node Firewall Operator 复制链接链接已复制到粘贴板!
前提条件
- 已安装 Ingress Node Firewall Operator。
流程
要拒绝 Ingress Node Firewall Operator,请创建一个 IngressNodeFirewallConfig 自定义资源,该资源将部署 Operator 的守护进程集。您可以通过应用防火墙规则,将一个或多个 IngressNodeFirewall CRD 部署到节点。
-
在
openshift-ingress-node-firewall命名空间中创建IngressNodeFirewallConfig,名为ingressnodefirewallconfig。 运行以下命令来部署 Ingress Node Firewall Operator 规则:
oc apply -f rule.yaml
$ oc apply -f rule.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8.3.1. Ingress 节点防火墙配置对象 复制链接链接已复制到粘贴板!
下表中描述了 Ingress Node Firewall 配置对象的字段:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CR 对象的名称。防火墙规则对象的名称必须是 |
|
|
|
Ingress Firewall Operator CR 对象的命名空间。 |
|
|
| 通过指定节点标签 (label) 用于目标节点的节点选择约束。例如: spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
注意
|
Operator 使用 CR,并在与 nodeSelector 匹配的所有节点上创建一个入口节点防火墙守护进程集。
5.8.3.2. Ingress Node Firewall Operator 示例配置 复制链接链接已复制到粘贴板!
以下示例中指定了完整的 Ingress Node 防火墙配置:
Ingress 节点防火墙配置对象示例
Operator 使用 CR,并在与 nodeSelector 匹配的所有节点上创建一个入口节点防火墙守护进程集。
5.8.3.3. Ingress 节点防火墙规则对象 复制链接链接已复制到粘贴板!
下表中描述了 Ingress Node Firewall 规则对象的字段:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| CR 对象的名称。 |
|
|
|
此对象的字段指定要应用防火墙规则的接口。例如, |
|
|
|
您可以使用 |
|
|
|
|
5.8.3.3.1. Ingress 对象配置 复制链接链接已复制到粘贴板!
ingress 对象的值在下表中定义:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 允许您设置 CIDR 块。您可以从不同地址系列配置多个 CIDR。 注意
不同的 CIDR 允许您使用相同的顺序规则。如果同一节点有多个 |
|
|
|
对于每个
将 注意 Ingress 防火墙规则使用阻止任何无效配置的验证 Webhook 进行验证。验证 Webhook 会阻止阻塞任何关键集群服务,如 API 服务器。 |
5.8.3.3.2. Ingress 节点防火墙规则对象示例 复制链接链接已复制到粘贴板!
以下示例中指定了完整的 Ingress Node 防火墙配置:
Ingress 节点防火墙配置示例
- 1
- 节点上必须存在 <label_name> 和 <label_value>,且必须与应用到您希望
ingressfirewallconfigCR 运行的节点的nodeselector标签和值匹配。<label_value> 可以是true或false。通过使用nodeSelector标签,您可以针对单独的节点组为目标,以使用ingressfirewallconfigCR 应用不同的规则。
5.8.3.3.3. 零信任 Ingress Node Firewall 规则对象示例 复制链接链接已复制到粘贴板!
零信任 Ingress 节点防火墙规则可为多接口集群提供额外的安全性。例如,您可以使用零信任 Ingress Node Firewall 规则来丢弃除 SSH 之外的特定接口上的网络流量。
以下示例中指定了零信任 Ingress Node Firewall 规则集的完整配置:
用户需要为其提供应用程序使用的所有端口添加到允许列表,以确保正常工作。
零信任 Ingress 节点防火墙规则示例
5.8.4. 查看 Ingress Node Firewall Operator 规则 复制链接链接已复制到粘贴板!
流程
运行以下命令来查看所有当前规则:
oc get ingressnodefirewall
$ oc get ingressnodefirewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 选择返回的
<resource>名称之一,并运行以下命令来查看规则或配置:oc get <resource> <name> -o yaml
$ oc get <resource> <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8.5. 对 Ingress Node Firewall Operator 进行故障排除 复制链接链接已复制到粘贴板!
运行以下命令列出已安装的 Ingress Node Firewall 自定义资源定义 (CRD):
oc get crds | grep ingressnodefirewall
$ oc get crds | grep ingressnodefirewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
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:00ZCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,以查看 Ingress Node Firewall Operator 的状态:
oc get pods -n openshift-ingress-node-firewall
$ oc get pods -n openshift-ingress-node-firewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
NAME READY STATUS RESTARTS AGE ingress-node-firewall-controller-manager 2/2 Running 0 5d21h ingress-node-firewall-daemon-pqx56 3/3 Running 0 5d21hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下字段提供有关 Operator 状态的信息:
READY、STATUS、AGE、和RESTARTS。当 Ingress Node Firewall Operator 将守护进程集部署到分配的节点时,STATUS字段为Running。运行以下命令来收集所有入口防火墙节点 pod 的日志:
oc adm must-gather – gather_ingress_node_firewall
$ oc adm must-gather – gather_ingress_node_firewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 sos 节点的报告中,其中包含位于
/sos_commands/ebpf的 eBPFbpftool输出的报告。这些报告包括用于或作为入口防火墙 XDP 处理数据包处理、更新统计信息和发出事件的查找表。
5.9. SR-IOV Operator 复制链接链接已复制到粘贴板!
5.9.1. 安装 SR-IOV Network Operator 复制链接链接已复制到粘贴板!
您可以在集群上安装单根 I/O 虚拟化(SR-IOV)网络 Operator,以管理 SR-IOV 网络设备和网络附加。
5.9.1.1. 安装 SR-IOV Network Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 OpenShift Container Platform CLI 或 Web 控制台安装单根 I/O 虚拟化(SR-IOV) Network Operator。
5.9.1.1.1. CLI:安装 SR-IOV Network Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 CLI 安装 Operator。
先决条件
- 在裸机环境中安装的集群,其中的节点带有支持 SR-IOV 的硬件。
-
安装 OpenShift CLI(
oc)。 -
具有
cluster-admin特权的帐户。
流程
输入以下命令创建
openshift-sriov-network-operator命名空间:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令来创建
OperatorGroup自定义资源 (CR):Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令为 SR-IOV Network Operator 创建
SubscriptionCR:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令来创建
SriovoperatorConfig资源:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要验证是否已安装 Operator,请输入以下命令,然后检查 Operator 的输出显示
Succeeded:oc get csv -n openshift-sriov-network-operator \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get csv -n openshift-sriov-network-operator \ -o custom-columns=Name:.metadata.name,Phase:.status.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.1.1.2. web 控制台:安装 SR-IOV Network Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 Web 控制台安装 Operator。
先决条件
- 在裸机环境中安装的集群,其中的节点带有支持 SR-IOV 的硬件。
-
安装 OpenShift CLI(
oc)。 -
具有
cluster-admin特权的帐户。
流程
安装 SR-IOV Network Operator:
- 在 OpenShift Container Platform Web 控制台中,点击 Operators → OperatorHub。
- 从可用的 Operators 列表中选择 SR-IOV Network Operator,然后点击 Install。
- 在 Install Operator 页面中,在 Installed Namespace 下选择 Operator recommended Namespace。
- 点 Install。
验证 SR-IOV Network Operator 是否已成功安装:
- 导航到 Operators → Installed Operators 页面。
确保 SR-IOV Network Operator 在 openshift-sriov-network-operator 项目中列出,状态 为 InstallSucceeded。
注意在安装过程中,Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息,您可以忽略这个 Failed 信息。
如果 Operator 没有被成功安装,请按照以下步骤进行故障排除:
- 检查 Operator Subscriptions 和 Install Plans 选项卡中的 Status 项中是否有任何错误。
-
进入 Workloads → Pods 页面,在
openshift-sriov-network-operator项目中检查 pod 的日志。 检查 YAML 文件的命名空间。如果缺少注解,您可以使用以下命令将注解
workload.openshift.io/allowed=management添加到 Operator 命名空间中:oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
$ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=managementCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意对于单节点 OpenShift 集群,命名空间需要注解
workload.openshift.io/allowed=management。
5.9.1.2. 后续步骤 复制链接链接已复制到粘贴板!
5.9.2. 配置 SR-IOV Network Operator 复制链接链接已复制到粘贴板!
Single Root I/O Virtualization(SR-IOV)Network Operator 管理集群中的 SR-IOV 网络设备和网络附加。
5.9.2.1. 配置 SR-IOV Network Operator 复制链接链接已复制到粘贴板!
创建一个
SriovOperatorConfig自定义资源 (CR) 以部署所有 SR-IOV Operator 组件:使用以下 YAML 创建名为
sriovOperatorConfig.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovOperatorConfig资源的唯一有效名称是default,它必须位于部署 Operator 的命名空间中。- 2
enableInjector字段如果没有在 CR 中指定或明确设置为true,则默认为false或<none>,这会防止任何network-resources-injectorpod 在命名空间中运行。建议的设置为true。- 3
enableOperatorWebhook字段如果没有在 CR 中指定或明确设置为 true,则默认为false或<none>,这会防止任何operator-webhookpod 在命名空间中运行。建议的设置为true。
运行以下命令来创建资源:
oc apply -f sriovOperatorConfig.yaml
$ oc apply -f sriovOperatorConfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.2.1.1. SR-IOV Network Operator 配置自定义资源 复制链接链接已复制到粘贴板!
sriovoperatorconfig 自定义资源的字段在下表中描述:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
指定 SR-IOV Network Operator 实例的名称。默认值为 |
|
|
|
指定 SR-IOV Network Operator 实例的命名空间。默认值为 |
|
|
| 指定在所选节点上调度 SR-IOV 网络配置守护进程的节点选择。默认情况下,此字段没有设置,Operator 会在 worker 节点上部署 SR-IOV 网络配置守护进程集。 |
|
|
|
指定是否禁用节点排空过程,或者在应用新策略在节点上配置 NIC 时启用节点排空过程。将此字段设置为
对于单节点集群,在安装 Operator 后将此字段设置为 |
|
|
| 指定是否启用或禁用 Network Resources Injector 守护进程集。 |
|
|
| 指定是否启用或禁用 Operator Admission Controller webhook 守护进程集。 |
|
|
|
指定 Operator 的日志详细程度。默认情况下,此字段设置为 |
|
|
|
指定是否启用或禁用可选功能。例如, |
|
|
|
指定是否启用或禁用 SR-IOV Network Operator 指标。默认情况下,此字段设置为 |
5.9.2.1.2. 关于 Network Resources Injector(网络资源注入器) 复制链接链接已复制到粘贴板!
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
$ oc get pods -n openshift-sriov-network-operator
输出示例
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
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
5.9.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> } }'$ oc patch sriovoperatorconfig default \ --type=merge -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableInjector": <value> } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来更新 Operator:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.2.1.4. 关于 SR-IOV Network Operator 准入控制器 Webhook 复制链接链接已复制到粘贴板!
SR-IOV Network Operator Admission Controller Webhook 是一个 Kubernetes Dynamic Admission Controller 应用程序。它提供以下功能:
-
在创建或更新时,验证
SriovNetworkNodePolicyCR。 -
修改
SriovNetworkNodePolicyCR,在创建或更新 CR 时为priority和deviceType项设置默认值。
当在 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
$ oc get pods -n openshift-sriov-network-operator
输出示例
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
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
5.9.2.1.5. 禁用或启用 SR-IOV Network Operator 准入控制器 Webhook 复制链接链接已复制到粘贴板!
要禁用或启用准入控制器 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> } }'$ oc patch sriovoperatorconfig default --type=merge \ -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableOperatorWebhook": <value> } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来更新 Operator:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.2.1.6. 关于自定义节点选择器 复制链接链接已复制到粘贴板!
SR-IOV 网络配置守护进程在集群节点上发现并配置 SR-IOV 网络设备。默认情况下,它将部署到集群中的所有 worker 节点。您可以使用节点标签指定 SR-IOV 网络配置守护进程在哪些节点上运行。
5.9.2.1.7. 为 SR-IOV 网络配置守护进程配置自定义 NodeSelector 复制链接链接已复制到粘贴板!
SR-IOV 网络配置守护进程在集群节点上发现并配置 SR-IOV 网络设备。默认情况下,它将部署到集群中的所有 worker 节点。您可以使用节点标签指定 SR-IOV 网络配置守护进程在哪些节点上运行。
要指定部署了 SR-IOV 网络配置守护进程的节点,请完成以下步骤。
当您更新 configDaemonNodeSelector 字段时,SR-IOV 网络配置守护进程会在所选节点中重新创建。在重新创建守护进程时,集群用户无法应用任何新的 SR-IOV 网络节点策略或创建新的 SR-IOV Pod。
流程
要为 Operator 更新节点选择器,请输入以下命令:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<node_label>替换为要应用的标签,如下例中:"node-role.kubernetes.io/worker": ""。提示您还可以应用以下 YAML 来更新 Operator:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.2.1.8. 为单一节点安装配置 SR-IOV Network Operator 复制链接链接已复制到粘贴板!
默认情况下,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": "" } } }'$ oc patch sriovoperatorconfig default --type=merge -n openshift-sriov-network-operator --patch '{ "spec": { "disableDrain": true, "configDaemonNodeSelector": { "node-role.kubernetes.io/master": "" } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来更新 Operator:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.2.1.9. 为托管 control plane 部署 SR-IOV Operator 复制链接链接已复制到粘贴板!
在 AWS 平台上托管的 control plane 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
配置和部署托管服务集群后,您可以在托管集群中创建 SR-IOV Operator 订阅。SR-IOV pod 在 worker 机器上运行而不是在 control plane 上运行。
先决条件
您必须在 AWS 上配置和部署托管集群。如需更多信息,请参阅在 AWS 上配置托管集群(技术预览)。
流程
创建命名空间和 Operator 组:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 SR-IOV Operator 的订阅:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要验证 SR-IOV Operator 是否已就绪,请运行以下命令并查看生成的输出:
oc get csv -n openshift-sriov-network-operator
$ oc get csv -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME DISPLAY VERSION REPLACES PHASE sriov-network-operator.4.16.0-202211021237 SR-IOV Network Operator 4.16.0-202211021237 sriov-network-operator.4.16.0-202210290517 Succeeded
NAME DISPLAY VERSION REPLACES PHASE sriov-network-operator.4.16.0-202211021237 SR-IOV Network Operator 4.16.0-202211021237 sriov-network-operator.4.16.0-202210290517 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证 SR-IOV pod 是否已部署,请运行以下命令:
oc get pods -n openshift-sriov-network-operator
$ oc get pods -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.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 指标:
| 指标 | 描述 | 检查 VF 指标的 PromQL 查询示例 |
|---|---|---|
|
| 每个虚拟功能接收的字节数。 |
|
|
| 每个虚拟功能传输的字节数。 |
|
|
| 每个虚拟功能接收的数据包。 |
|
|
| 每个虚拟功能传输的数据包。 |
|
|
| 每个虚拟功能接收后丢弃的数据包。 |
|
|
| 每个虚拟功能传输过程中丢弃的数据包。 |
|
|
| 每个虚拟功能接收的多播数据包。 |
|
|
| 每个虚拟功能接收的广播数据包。 |
|
|
| 链接到活跃 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
(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
5.9.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。
流程
运行以下命令来启用集群监控:
oc label ns/openshift-sriov-network-operator openshift.io/cluster-monitoring=true
$ oc label ns/openshift-sriov-network-operator openshift.io/cluster-monitoring=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要启用集群监控,您必须在安装了 SR-IOV Network Operator 的命名空间中创建
openshift.io/cluster-monitoring=true标签。运行以下命令,将
spec.featureGates.metricsExporter字段设置为true:oc patch -n openshift-sriov-network-operator sriovoperatorconfig/default \ --type='merge' -p='{"spec": {"featureGates": {"metricsExporter": true}}}'$ oc patch -n openshift-sriov-network-operator sriovoperatorconfig/default \ --type='merge' -p='{"spec": {"featureGates": {"metricsExporter": true}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,检查 SR-IOV 网络指标导出器是否已启用:
oc get pods -n openshift-sriov-network-operator
$ oc get pods -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
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 5d22hCopy to Clipboard Copied! Toggle word wrap Toggle overflow sriov-network-metrics-exporterpod 必须处于READY状态。- 可选:使用 OpenShift Container Platform Web 控制台检查 SR-IOV 虚拟功能 (VF) 指标。如需更多信息,请参阅"查询指标"。
5.9.2.3. 后续步骤 复制链接链接已复制到粘贴板!
5.9.3. 卸载 SR-IOV Network Operator 复制链接链接已复制到粘贴板!
要卸载 SR-IOV Network Operator,您必须删除所有正在运行的 SR-IOV 工作负载,卸载 Operator,并删除 Operator 使用的 webhook。
5.9.3.1. 卸载 SR-IOV Network Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以卸载 SR-IOV Network Operator。
先决条件
-
可以使用具有
cluster-admin权限的账户访问 OpenShift Container Platform 集群。 - 已安装 SR-IOV Network Operator。
流程
删除所有 SR-IOV 自定义资源(CR):
oc delete sriovnetwork -n openshift-sriov-network-operator --all
$ oc delete sriovnetwork -n openshift-sriov-network-operator --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all
$ oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete sriovibnetwork -n openshift-sriov-network-operator --all
$ oc delete sriovibnetwork -n openshift-sriov-network-operator --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 按照 "Deleting Operators from a cluster" 部分的说明从集群中移除 SR-IOV Network Operator。
卸载 SR-IOV Network Operator 后,删除在集群中保留的 SR-IOV 自定义资源定义:
oc delete crd sriovibnetworks.sriovnetwork.openshift.io
$ oc delete crd sriovibnetworks.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io
$ oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io
$ oc delete crd sriovnetworknodestates.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io
$ oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworks.sriovnetwork.openshift.io
$ oc delete crd sriovnetworks.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io
$ oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 SR-IOV Webhook:
oc delete mutatingwebhookconfigurations network-resources-injector-config
$ oc delete mutatingwebhookconfigurations network-resources-injector-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete MutatingWebhookConfiguration sriov-operator-webhook-config
$ oc delete MutatingWebhookConfiguration sriov-operator-webhook-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete ValidatingWebhookConfiguration sriov-operator-webhook-config
$ oc delete ValidatingWebhookConfiguration sriov-operator-webhook-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 SR-IOV Network Operator 命名空间:
oc delete namespace openshift-sriov-network-operator
$ oc delete namespace openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 6 章 网络安全性 复制链接链接已复制到粘贴板!
6.1. 了解网络策略 API 复制链接链接已复制到粘贴板!
Kubernetes 提供了两个用户可用于强制实施网络安全的功能。允许用户强制执行网络策略的一个功能是 NetworkPolicy API,主要用于应用程序开发人员和命名空间租户,通过创建命名空间范围的策略来保护其命名空间。
第二个功能是 AdminNetworkPolicy,它由两个 API 组成:AdminNetworkPolicy (ANP) API 和 BaselineAdminNetworkPolicy (BANP) API。ANP 和 BANP 是为集群和网络管理员设计的,以通过创建集群范围的策略来保护其整个集群。集群管理员可以使用 ANPs 来强制实施优先于 NetworkPolicy 对象的不可覆盖的策略。管理员可以使用 BANP 设置并强制实施可选的集群范围的网络策略规则,当需要时,用户可以使用 NetworkPolicy 对象覆盖它。当一起使用时,ANP、BANP 和网络策略可以实现完整的多租户隔离,管理员可使用这个功能保护集群。
OpenShift Container Platform 中的 OVN-Kubernetes CNI 使用访问控制列表(ACL) Tiers 实施这些网络策略,以评估并应用它们。ACL 按照从 Tier 1 到 Tier 3 的降序进行评估。
第 1 级评估 AdminNetworkPolicy (ANP)对象。第 2 级评估 NetworkPolicy 对象。第 3 级评估 BaselineAdminNetworkPolicy (BANP)对象。
首先评估 ANP。当匹配是 ANP allow 或 deny 规则时,集群中的任何现有 NetworkPolicy 和 BaselineAdminNetworkPolicy(BANP)对象将不会被评估。当匹配是 ANP pass,评估会从 ACL 的第 1 层移到第 2 层,在其中评估 NetworkPolicy 策略。如果没有 NetworkPolicy 与流量匹配,则评估从第 2 层 ACL 移到评估 BANP 的第 3 层 ACL。
6.1.1. AdminNetworkPolicy 和 NetworkPolicy 自定义资源之间的主要区别 复制链接链接已复制到粘贴板!
下表解释了集群范围的 AdminNetworkPolicy API 和命名空间范围 NetworkPolicy API 之间的主要区别。
| 策略元素 | AdminNetworkPolicy | NetworkPolicy |
|---|---|---|
| 适用的用户 | 集群管理员 | 命名空间所有者 |
| 影响范围 | Cluster | Namespaced |
| 丢弃流量 |
当显式 |
在策略创建时通过隐式 |
| 委派流量 |
| Not applicable |
| 允许流量 |
显式 | 所有规则的默认操作都是 allow。 |
| 策略中的规则优先级 | 取决于它们出现在 ANP 中的顺序。位置更高的规则有更高的优先级。 | 规则的效果是叠加的 |
| 策略优先级 |
在 ANP 中, | 在策略之间没有策略排序。 |
| 功能优先级 | 首先通过 1 层 ACL 和 BANP 评估,最后通过第 3 层 ACL 评估。 | 在 ANP 之后,BANP 之前强制实施,它们会在 ACL 层 2 中进行评估。 |
| 匹配 pod 选择 | 在命名空间之间可应用不同的规则。 | 可以在单一命名空间中的 pod 之间应用不同的规则。 |
| 集群出口流量 |
通过 |
通过 |
| 集群入口流量 | 不支持 | 不支持 |
| 完全限定域名 (FQDN) 对等支持 | 不支持 | 不支持 |
| 命名空间选择器 |
支持通过使用 |
支持使用 |
6.2. 管理网络策略 复制链接链接已复制到粘贴板!
6.2.1. OVN-Kubernetes AdminNetworkPolicy 复制链接链接已复制到粘贴板!
6.2.1.1. AdminNetworkPolicy 复制链接链接已复制到粘贴板!
AdminNetworkPolicy (ANP)是一个集群范围的自定义资源定义(CRD)。作为 OpenShift Container Platform 管理员,您可以在创建命名空间前通过创建网络策略来使用 ANP 来保护网络。另外,您可以在集群范围的级别上创建网络策略,该级别不可由 NetworkPolicy 对象覆盖。
AdminNetworkPolicy 和 NetworkPolicy 对象之间的关键区别在于,供管理员使用,是集群范围,而后者则用于租户所有者,并且是命名空间范围。
ANP 允许管理员指定以下内容:
-
确定其评估顺序的
priority值。数值越低,优先级越高。 - 由应用策略的一组命名空间或命名空间组成的一组 pod。
-
要应用到
subject的所有入口流量的入站规则列表。 -
用于来自
subject的所有出口流量的出口规则列表。
6.2.1.1.1. AdminNetworkPolicy 示例 复制链接链接已复制到粘贴板!
例 6.1. ANP 的 YAML 文件示例
- 1
- 为您的 ANP 指定一个名称。
- 2
spec.priority字段支持在一个集群中最大 100 ANP(范围为0-99)。数越低,优先级越高,因为范围是从按最低到最高值的顺序读取的。因为当以同一优先级创建 ANP 时,无法保证哪些策略会被优先使用,所以请使用不同的优先级来设置 ANPs。- 3
- 指定要应用 ANP 资源的命名空间。
- 4
- ANP 具有入口和出口规则。
spec.ingress字段的 ANP 规则接受Pass,Deny,action字段接受的值为Allow。 - 5
- 为
ingress.name指定一个名称。 - 6
- 指定
podSelector.matchLabels,以选择namespaceSelector.matchLabels作为入口对等选择的命名空间中的 pod。 - 7
- ANP 同时具有入口和出口规则。
spec.egress字段的 ANP 规则接受Pass,Deny,action字段接受的值为Allow。
6.2.1.1.2. 规则的 AdminNetworkPolicy 操作 复制链接链接已复制到粘贴板!
作为管理员,您可以将您的 AdminNetworkPolicy 规则的 action 字段设置为 Allow,Deny, 或 Pass。由于 OVN-Kubernetes 使用分层 ACL 来评估网络流量规则,因此 3NP 允许您设置非常强大的策略规则,它们只能被管理员修改、删除规则,或通过设置更高优先级规则来覆盖它们。
6.2.1.1.2.1. AdminNetworkPolicy Allow 示例 复制链接链接已复制到粘贴板!
在优先级 9 中定义的以下 ANP 可确保允许从 monitoring 命名空间到集群中的任何租户(所有其他命名空间)的所有入口流量。
例 6.2. 强 Allow ANP 的 YAML 文件示例
这是强的 Allow ANP 的示例,因为它不可以被涉及的所有方覆盖。租户都不会阻止自己被使用 NetworkPolicy 对象监控,监控租户也不知道它可以或无法监控的内容。
6.2.1.1.2.2. AdminNetworkPolicy 拒绝示例 复制链接链接已复制到粘贴板!
在优先级 5 中定义的以下 ANP 可确保 monitoring 命名空间中的所有入口流量都被阻止到受限租户(具有标签 security: restricted的命名空间)。
例 6.3. 强 Deny ANP 的 YAML 文件示例
这是一个强大的 Deny ANP,这是所有涉及的方都无法覆盖的。受限租户所有者无法授权自己允许监控流量,基础架构监控服务无法从这些敏感命名空间中提取任何内容。
与强的 Allow 示例结合使用时,block-monitoring ANP 具有较低优先级的值,赋予其优先级更高的优先级,这样可确保不会监控受限租户。
6.2.1.1.2.3. AdminNetworkPolicy Pass 示例 复制链接链接已复制到粘贴板!
在优先级 7 定义的以下 ANP 可确保所有从 monitoring 命名空间到内部基础架构租户(具有标签 security: internal)的入口流量都将传递到 ACL 的层 2,并由命名空间的 NetworkPolicy 对象评估。
例 6.4. 强 Pass ANP 的 YAML 文件示例
这个示例是一个强大的 Pass 操作 ANP,因为它将决策委派给租户所有者定义的 NetworkPolicy 对象。如果基础架构监控服务应使用命名空间范围 NetworkPolicy 对象提取其指标,则此 pass-monitoring ANP 允许在安全级别 internal 分组的所有租户所有者。
6.2.2. OVN-Kubernetes BaselineAdminNetworkPolicy 复制链接链接已复制到粘贴板!
6.2.2.1. BaselineAdminNetworkPolicy 复制链接链接已复制到粘贴板!
BaselineAdminNetworkPolicy (BANP)是一个集群范围的自定义资源定义(CRD)。作为 OpenShift Container Platform 管理员,您可以使用 BANP 来设置并强制实施可选的基准网络策略规则,这些规则被用户使用 NetworkPolicy 对象(如果需要的话)覆盖。BANP 的规则操作是 allow 或 deny。
BaselineAdminNetworkPolicy 资源是一个集群单例对象,当传递的流量策略与集群中的任何 NetworkPolicy 对象不匹配时,可用作 guardrail 策略。BANP 也可以用作默认安全模型,该模型默认阻止集群内流量,用户需要使用 NetworkPolicy 对象来允许已知的流量。在创建 BANP 资源时,必须使用 default 作为名称。
管理员可通过 BANP 指定:
-
由一组命名空间或命名空间的
subject。 -
要应用到
subject的所有入口流量的入站规则列表。 -
用于来自
subject的所有出口流量的出口规则列表。
6.2.2.1.1. BaselineAdminNetworkPolicy 示例 复制链接链接已复制到粘贴板!
例 6.5. BANP 的 YAML 文件示例
6.2.2.1.2. BaselineAdminNetworkPolicy 拒绝示例 复制链接链接已复制到粘贴板!
以下 BANP 单例确保管理员为 internal 安全级别进入租户的所有入口监控流量设置了默认的拒绝策略。与 "AdminNetworkPolicy Pass example" 组合时,这个 deny 策略充当 ANP pass-monitoring 策略传递的所有入口流量的保护策略。
例 6.6. guardrail Deny 规则的 YAML 文件示例
您可以将带有 action 字段的值为 Pass 的 AdminNetworkPolicy 资源与 BaselineAdminNetworkPolicy 资源结合使用来创建多租户策略。此多租户策略允许一个租户在应用上收集监控数据,同时不从第二个租户收集数据。
作为管理员,如果您同时应用了 "AdminNetworkPolicy Pass action example" 和 "BaselineAdminNetwork Policy Deny example",则租户将保留创建在 BANP 之前评估的 NetworkPolicy 资源。
例如,租户 1 可以设置以下 NetworkPolicy 资源来监控入口流量:
例 6.7. NetworkPolicy 示例
在这种情况下,Tenant 1 会在 "AdminNetworkPolicy Pass action example" 之后,"BaselineAdminNetwork Policy Deny example" 之前被评估,它将拒绝所有进入 安全级别 internal 的入口监控流量。随着租户 1 的 NetworkPolicy 对象就位,它们将能够在其应用程序中收集数据。但是,租户 2 没有任何 NetworkPolicy 对象,将无法收集数据。作为管理员,您没有默认监控内部租户,而是创建了 BANP,它允许租户使用 NetworkPolicy 对象覆盖 BANP 的默认行为。
6.2.3. 监控 ANP 和 BANP 复制链接链接已复制到粘贴板!
AdminNetworkPolicy 和 BaselineAdminNetworkPolicy 资源具有可用于监控和管理您的策略的指标。有关指标的详情,请查看下表。
6.2.3.1. AdminNetworkPolicy 指标 复制链接链接已复制到粘贴板!
| Name | 描述 | 解释 |
|---|---|---|
|
| Not applicable |
集群中的 |
|
| Not applicable |
集群中的 |
|
|
|
集群中所有 ANP 策略的规则总数,按照 |
|
|
|
集群中所有 BANP 策略的规则总数,按照 |
|
|
|
集群中所有 ANP 创建的 OVN 北向数据库(nbdb)对象的总数,按照 |
|
|
|
集群中所有 BANP 创建的 OVN 北向数据库(nbdb)对象的总数,按照 |
6.2.4. AdminNetworkPolicy 的出口节点和网络对等点 复制链接链接已复制到粘贴板!
本节介绍 节点 和网络 对等点。管理员可以使用本节中的示例来设计 AdminNetworkPolicy 和 BaselineAdminNetworkPolicy,以控制其集群中的北向流量。
除了支持 east-west 流量控制外,ANP 和 BANP 还允许管理员控制其北向流量,使集群或流量离开集群或流量到集群中的其他节点。最终用户可以执行以下操作:
-
使用
节点出口对等点实现对集群节点的出口流量控制 -
使用
节点或网络出口对等对 Kubernetes API 服务器实施出口流量控制 -
使用
网络对等点对集群外的外部目的地实施出口流量控制
对于 ANP 和 BANP,只能为出口规则指定节点和网络对等点。
6.2.4.1.1. 使用节点 peer 控制到集群节点的出口流量 复制链接链接已复制到粘贴板!
使用 节点 对等管理员可以控制从 pod 到集群中节点的出口流量。这样做的好处是,您不必在向集群添加或删除节点时更改策略。
在以下示例中,通过使用节点选择器,允许任何带有restricted, confidential, 或 internal 级别安全的命名空间发送的、端口 6443 上的到 Kubernetes API 服务器的出口流量。它还拒绝来自带有 restricted, confidential, or internal 安全级别的任何命名空间的、到您的集群中的所有 worker 节点的流量。
例 6.8. 使用 nodes 对等的 ANP Allow egress 示例
6.2.4.1.2. 使用网络对等控制到外部目的地的出口流量 复制链接链接已复制到粘贴板!
集群管理员可以使用网络对等中的 CIDR 范围,并应用一个策略来控制离开 pod 的出口流量,并进入通过 network 字段指定的 CIDR 范围内配置的 IP 地址的目标。
以下示例使用网络对等,并组合了 ANP 和 BANP 策略来限制出口流量。
请谨慎使用 namespace 字段中的空选择器({})。使用空选择器时,它还选择 OpenShift 命名空间。
如果您在 ANP 或 BANP Deny 规则中使用 0.0.0.0/0 的值,您必须在将 Deny 设置为 0.0.0.0/0 前将更高的优先级 ANP Allow 规则设置为所需的目的地。
例 6.9. 使用网络对等点的 ANP 和 BANP 示例
使用网络对等来整合 network-as-egress-peer ANP 和 默认的 BANP 来强制以下 egress 策略:
- 所有 pod 都无法通过列出的 IP 地址与外部 DNS 服务器进行通信。
- 所有 pod 都可以与公司的其他内部网通信。
- 所有 pod 都可以与其他 pod、节点和服务通信。
-
所有 pod 都无法与互联网通信。将最后一个 ANP
Pass规则与强大的 BANPDeny规则合并会创建一个保护策略来保护集群中的流量。
6.2.4.1.3. 一起使用节点对等和网络对等 复制链接链接已复制到粘贴板!
集群管理员可以将节点和网络对等组合到 ANP 和 BANP 策略中。
6.2.5. AdminNetworkPolicy 故障排除 复制链接链接已复制到粘贴板!
6.2.5.1. 检查 ANP 的创建 复制链接链接已复制到粘贴板!
要检查您的 AdminNetworkPolicy (ANP) 和 BaselineAdminNetworkPolicy (BANP) 是否已正确创建,请检查以下命令的状态输出: oc describe ap 或 oc describe banp。
正常状态表示 OVN DB plumbing was successful 和 SetupSucceeded。
例 6.11. 具有良好状态的 ANP 示例
如果 Plumbing 失败,则会从相应的区控制器报告错误。
例 6.12. 带有错误状态和错误消息的 ANP 示例
有关 nbctl 命令,请参见以下部分来帮助排除不成功的策略。
6.2.5.1.1. 为 ANP 和 BANP 使用 nbctl 命令 复制链接链接已复制到粘贴板!
要对不成功的设置进行故障排除,请首先查看 OVN 北向数据库 (nbdb) 对象,包括 ACL、AdressSet 和 Port_Group。要查看 nbdb,您需要在该节点上的 pod 内部查看该节点数据库中的对象。
先决条件
-
使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
要在集群中运行 ovn nbctl 命令,您必须在相关节点的 "nbdb" 中打开远程 shell。
以下策略用于生成输出。
例 6.13. 用于生成输出的 AdminNetworkPolicy
流程
运行以下命令,使用节点信息列出 pod:
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,进入 pod 以查看北向数据库:
oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt
$ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来查看 ACL nbdb :
ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 其中, cluster-control
-
指定您要故障排除的
AdminNetworkPolicy的名称。 - AdminNetworkPolicy
-
指定类型:
AdminNetworkPolicy或BaselineAdminNetworkPolicy。
例 6.14. ACL 的输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意ingress 和 egress 的输出显示策略在 ACL 中的逻辑。例如,每次数据包与提供的
match匹配时会执行的action。运行以下命令,为规则检查特定 ACL:
ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 其中,
cluster-control -
指定 ANP 的
名称。 入口-
指定流量的
direction为类型Ingress或Egress。 1- 指定要查看的规则。
对于示名为
cluster-control的 ANP 示例,其priority是34,以下是Ingressrule1 的示例输出:例 6.15. 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 其中,
运行以下命令查看 nbdb 中的地址集:
ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例 6.16.
Address_Set的输出示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检查规则的具体地址集:
ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例 6.17.
Address_Set的输出示例_uuid : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72 addresses : ["0.0.0.0/0"] external_ids : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a11452480169090787059_uuid : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72 addresses : ["0.0.0.0/0"] external_ids : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a11452480169090787059Copy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令查看 nbdb 中的端口组:
ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'$ ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例 6.18.
Port_Group的输出示例_uuid : f50acf71-7488-4b9a-b7b8-c8a024e99d21 acls : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd] external_ids : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a14645450421485494999 ports : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]_uuid : f50acf71-7488-4b9a-b7b8-c8a024e99d21 acls : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd] external_ids : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a14645450421485494999 ports : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.6. AdminNetworkPolicy 的最佳实践 复制链接链接已复制到粘贴板!
本节为 AdminNetworkPolicy 和 BaselineAdminNetworkPolicy 资源提供最佳实践。
6.2.6.1. 设计 AdminNetworkPolicy 复制链接链接已复制到粘贴板!
在构建 AdminNetworkPolicy (ANP) 资源时,您可能会在创建策略时考虑以下内容:
- 您可以创建具有相同优先级的 ANP。如果您使用同一优先级创建两个 ANP,请确保它们不会将重叠规则应用到同一流量。每个值仅有一个规则会被应用,当相同的优先级值有多个规则时,不会保证会应用哪个规则。因为当创建了重叠的 ANP 时,无法保证哪些策略会被优先使用,所以请使用不同的优先级来设置 ANPs。
- 管理员必须创建应用于用户命名空间的 ANP,而不是系统命名空间。
不支持将 ANP 和 BaselineAdminNetworkPolicy (BANP) 应用到系统命名空间(default, kube-system, 任何以 openshift- 开头的命名空间),这样做会使集群无响应并处于无法正常工作的状态。
-
因为支持的优先级范围是
0-100,所以您可以将您的 ANP 设置为使用一个中间范围,如30-70。这样就可以为这个范围外保留一些更高和更低的优先级占位符。即使在这个中间范围内,您可能也会希望保留一些空缺,以便随着基础架构的变化,您可以根据需要以正确的优先级插入新的 ANP。如果您打包了 ANP,则可能需要重新创建它们,以适应将来的任何更改。 -
当使用
0.0.0.0/0或::/0创建一个强的Deny策略时,请确保基本流量具有较高优先级Allow或Pass规则。 -
当您需要确保一个连接无论在什么情况下都被允许时,使用
Allow作为您的action字段。ANP 中的Allow规则代表连接始终被允许,NetworkPolicy将被忽略。 -
使用
Pass作为您的action字段,将允许或拒绝连接策略委托给NetworkPolicy层。 - 确保多个规则中的选择器不会重叠,因此同一 IP 不会出现在多个策略中,这可能导致性能和扩展限制。
-
避免将
namedPorts与PortNumber和PortRange结合使用,因为这样会创建 6 个 ACL,并导致集群中的效率降低。
6.2.6.1.1. 使用 BaselineAdminNetworkPolicy 的注意事项 复制链接链接已复制到粘贴板!
您只能在集群中定义单个
BaselineAdminNetworkPolicy(BANP) 资源。以下支持用于 BANP,管理员可能在设计其 BANP 中考虑:-
您可以在用户命名空间中为 cluster-local ingress 设置默认的拒绝策略。此 BANP 将强制开发人员添加
NetworkPolicy对象来允许他们允许的入口流量,如果他们没有为 ingress 添加网络策略,则会被拒绝。 -
您可以在用户命名空间中为 cluster-local egress 设置默认拒绝策略。此 BANP 将强制开发人员添加
NetworkPolicy对象来允许他们允许的入口流量,如果他们没有为 ingress 添加网络策略,则会被拒绝。 -
您可以为出口设置到集群内 DNS 服务的默认允许策略。此类 BANP 可确保命名空间的用户不必将允许出口
NetworkPolicy设置为集群内 DNS 服务。 -
您可以设置一个出口策略,允许内部出口流量到所有容器集,但拒绝访问所有外部端点(例如
0.0.0.0/0和::/0)。此 BANP 允许用户工作负载向其他集群端点发送流量,但默认不发送到外部端点。然后,开发人员可以使用NetworkPolicy来允许其应用程序将流量发送到一组明确的外部服务。
-
您可以在用户命名空间中为 cluster-local ingress 设置默认的拒绝策略。此 BANP 将强制开发人员添加
-
确保对 BANP 设置了范围,以便它只拒绝到用户命名空间的流量,而不是系统命名空间。这是因为系统命名空间没有
NetworkPolicy对象来覆盖 BANP。
6.2.6.1.2. AdminNetworkPolicy 和 NetworkPolicy 之间的不同 复制链接链接已复制到粘贴板!
-
与
NetworkPolicy对象不同,您必须使用显式标签在 ANP 和 BANP 中引用工作负载,而不是使用空 ({}) 捕获所有选择器以避免意外选择流量。
应用到基础架构命名空间的空命名空间选择器可能会导致集群无响应且处于无法正常工作状态。
-
在 ANP 的 API 语义中,您必须在创建策略时显式定义允许或拒绝规则,这与具有隐式 deny 的
NetworkPolicy对象不同。 -
与
NetworkPolicy对象不同,AdminNetworkPolicy对象入口规则仅限于集群内 Pod 和命名空间,因此您无法不需要,从主机网络为 ingress 设置规则。
6.3. 网络策略 复制链接链接已复制到粘贴板!
6.3.1. 关于网络策略 复制链接链接已复制到粘贴板!
作为开发者,您可以定义网络策略来限制集群中 pod 的流量。
6.3.1.1. 关于网络策略 复制链接链接已复制到粘贴板!
在使用支持 Kubernetes 网络策略的网络插件的集群中,NetworkPolicy 对象控制网络隔离。在 OpenShift Container Platform 4.16 中,OpenShift SDN 支持在默认的网络隔离模式中使用网络策略。
- 在 OpenShift SDN 上:网络策略不适用于主机网络命名空间。网络策略规则不会影响启用了主机网络的 pod。网络策略规则可能会影响连接到主机网络 pod 的 pod。
-
在 Openshift-OVN-Kubernetes 中:网络策略会影响启用了主机网络的 pod,因此您必须在网络策略规则中明确允许连接到这些 pod。如果命名空间应用了任何网络策略,来自系统组件的流量(如
openshift-ingress或openshift-kube-apiserver)会被默认丢弃;您必须明确启用此流量以允许它。 -
使用没有将
podSelector字段设置为{}的namespaceSelector字段将不会包括hostNetworkpod。您必须使用namespaceSelector字段,podSelector设置为{},以便在创建网络策略时目标hostNetworkpod。 - 网络策略无法阻止来自 localhost 或来自其驻留的节点的流量。
默认情况下,项目中的所有 pod 都可被其他 pod 和网络端点访问。要在一个项目中隔离一个或多个 Pod,您可以在该项目中创建 NetworkPolicy 对象来指示允许的入站连接。项目管理员可以在自己的项目中创建和删除 NetworkPolicy 对象。
如果一个 pod 由一个或多个 NetworkPolicy 对象中的选择器匹配,那么该 pod 将只接受至少被其中一个 NetworkPolicy 对象所允许的连接。未被任何 NetworkPolicy 对象选择的 pod 可以完全访问。
网络策略仅适用于传输控制协议(TCP)、用户数据报协议(UDP)、互联网控制消息协议(ICMP)和流控制传输协议(SCTP)协议。其他协议不会受到影响。
以下示例 NetworkPolicy 对象演示了支持不同的情景:
拒绝所有流量:
要使项目默认为拒绝流量,请添加一个匹配所有 pod 但不接受任何流量的
NetworkPolicy对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 只允许 OpenShift Container Platform Ingress Controller 的连接:
要使项目只允许 OpenShift Container Platform Ingress Controller 的连接,请添加以下
NetworkPolicy对象。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 只接受项目中 pod 的连接:
重要要允许同一命名空间中的
hostNetworkpod 的入站连接,您需要将allow-from-hostnetwork策略与allow-same-namespace策略一起应用。要使 pod 接受同一项目中其他 pod 的连接,但拒绝其他项目中所有 pod 的连接,请添加以下
NetworkPolicy对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仅允许基于 pod 标签的 HTTP 和 HTTPS 流量:
要对带有特定标签(以下示例中的
role=frontend)的 pod 仅启用 HTTP 和 HTTPS 访问,请添加类似如下的NetworkPolicy对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用命名空间和 pod 选择器接受连接:
要通过组合使用命名空间和 pod 选择器来匹配网络流量,您可以使用类似如下的
NetworkPolicy对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkPolicy 对象是可添加的;也就是说,您可以组合多个 NetworkPolicy 对象来满足复杂的网络要求。
例如,对于以上示例中定义的 NetworkPolicy 对象,您可以在同一个项目中定义 allow-same-namespace 和 allow-http-and-https 策略。因此,允许带有标签 role=frontend 的 pod 接受每一策略所允许的任何连接。即,任何端口上来自同一命名空间中的 pod 的连接,以及端口 80 和 443 上的来自任意命名空间中 pod 的连接。
6.3.1.1.1. 使用 allow-from-router 网络策略 复制链接链接已复制到粘贴板!
使用以下 NetworkPolicy 来允许外部流量,而不考虑路由器配置:
- 1
policy-group.network.openshift.io/ingress:""标签支持 OpenShift-SDN 和 OVN-Kubernetes。
6.3.1.1.2. 使用 allow-from-hostnetwork 网络策略 复制链接链接已复制到粘贴板!
添加以下 allow-from-hostnetwork NetworkPolicy 对象来指示来自主机网络 pod 的流量。
6.3.1.2. 使用 OpenShift SDN 优化网络策略 复制链接链接已复制到粘贴板!
使用一个网络策略来通过 pod 上的不同标签来在命名空间中将不同 pod 进行隔离。
将 NetworkPolicy 对象应用到单一命名空间中的大量 pod 时,效率较低。因为 Pod 标签不存在于 IP 地址一级,因此网络策略会为使用 podSelector 选择的每个 pod 之间生成单独的 Open vSwitch(OVS)流量规则 。
例如,在一个 NetworkPolicy 对象中,如果 spec podSelector 和 ingress podSelector 每个都匹配 200 个 pod,则会产生 40,000 (200*200) OVS 流规则。这可能会减慢节点的速度。
在设计您的网络策略时,请参考以下指南:
使用命名空间使其包含需要隔离的 pod 组,可以减少 OVS 流规则数量。
使用
namespaceSelector或空podSelector选择整个命名空间的NetworkPolicy对象会只生成 一个与命名空间的 VXLAN 虚拟网络 ID(VNID)匹配的 OVS 流量规则。- 保留不需要在原始命名空间中隔离的 pod,并将需要隔离的 pod 移到一个或多个不同的命名空间中。
- 创建额外的目标跨命名空间网络策略,以允许来自不同隔离的 pod 的特定流量。
6.3.1.3. 使用 OVN-Kubernetes 网络插件优化网络策略 复制链接链接已复制到粘贴板!
在设计您的网络策略时,请参考以下指南:
-
对于具有相同
spec.podSelectorspec 的网络策略,使用带有多个ingress或egress规则的一个网络策略比带有ingress或egress子集的多个网络策略更高效。 每个基于
podSelector或namespaceSelectorspec 的ingress或egress规则会生成一个的 OVS 流数量,它与由网络策略选择的 pod 数量 + 由 ingress 或 egress 选择的 pod 数量成比例因此,最好使用在一个规则中可以选择您所需的 pod 的podSelector或namespaceSelector规格,而不是为每个 pod 创建单独的规则。例如,以下策略包含两个规则:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下策略表示这两个规则与以下相同的规则:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 相同的指南信息适用于
spec.podSelectorspec。如果不同的网络策略有相同的ingress或egress规则,则创建一个带有通用的spec.podSelectorspec 可能更有效率。例如,以下两个策略有不同的规则:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下网络策略将这两个相同的规则作为一个:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当只有多个选择器表示为一个选择器时,您可以应用此优化。如果选择器基于不同的标签,则可能无法应用此优化。在这些情况下,请考虑为网络策略优化应用一些新标签。
6.3.1.3.1. OVN-Kubernetes 中的 NetworkPolicy CR 和外部 IP 复制链接链接已复制到粘贴板!
在 OVN-Kubernetes 中,NetworkPolicy 自定义资源(CR)强制执行严格的隔离规则。如果服务使用外部 IP 公开,网络策略可以阻止来自其他命名空间的访问,除非明确配置为允许流量。
要允许在命名空间间访问外部 IP,请创建一个 NetworkPolicy CR,该 CR 明确允许来自所需命名空间的入口流量,并确保允许流量在指定的服务端口中。在不允许流量到所需端口的情况下,访问可能仍然会被限制。
输出示例
其中:
<policy_name>- 指定策略的名称。
<my_namespace>- 指定部署策略的命名空间的名称。
如需了解更多详细信息,请参阅"关于网络策略"。
6.3.1.4. 后续步骤 复制链接链接已复制到粘贴板!
6.3.2. 创建网络策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为命名空间创建网络策略。
6.3.2.1. 示例 NetworkPolicy 对象 复制链接链接已复制到粘贴板!
以下配置注解一个 NetworkPolicy 对象:
其中:
name- NetworkPolicy 对象的名称。
spec.podSelector- 描述策略应用到的 pod 的选择器。策略对象只能选择定义 NetworkPolicy 对象的项目中的 pod。
ingress.from.podSelector- 与策略对象允许从中入口流量的 pod 匹配的选择器。选择器与 NetworkPolicy 在同一命名空间中的 pod 匹配。
ingress.ports- 接受流量的一个或多个目标端口的列表。
6.3.2.2. 使用 CLI 创建网络策略 复制链接链接已复制到粘贴板!
要定义细致的规则来描述集群中命名空间允许的入口或出口网络流量,您可以创建一个网络策略。
如果使用具有 cluster-admin 角色的用户登录,则可以在集群中的任何命名空间中创建网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
使用具有
admin权限的用户登陆到集群。 - 您在网络策略要应用到的命名空间中。
流程
创建策略规则。
创建一个
<policy_name>.yaml文件:touch <policy_name>.yaml
$ touch <policy_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定网络策略文件名。
在创建的 文件中定义网络策略。以下示例拒绝来自所有命名空间中的所有 pod 的入口流量。这是一个基本的策略,阻止配置其他网络策略所允许的跨 pod 流量以外的所有跨 pod 网络。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下示例配置允许来自同一命名空间中的所有 pod 的入口流量:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下示例允许从特定命名空间中到一个 pod 的入口流量。此策略允许流量从在
namespace-y中运行的 pod 中获取pod-a标签。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下示例配置限制了服务的流量。应用此策略可确保每个带有标签
app=bookstore和role=api的 Pod 只能被带有标签app=bookstore的 Pod 访问。在本例中,应用可以是 REST API 服务器,标记为标签app=bookstore和role=api。这个示例配置示例解决了以下用例:
- 将到一个服务的流量限制为仅使用需要它的其他微服务。
将连接限制为只允许使用它的应用程序。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令来创建网络策略对象。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f <policy_name>.yaml -n <namespace>
$ oc apply -f <policy_name>.yaml -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定网络策略文件名。
<namespace>- 可选参数。如果您在与当前命名空间不同的命名空间中定义了对象,则参数会特定于命名空间。
成功输出列出了策略对象的名称
以及创建的状态。注意如果您使用
cluster-admin权限登录到 web 控制台,您可以选择在集群中的任何命名空间中以 YAML 或 web 控制台的形式创建网络策略。
6.3.2.3. 创建默认拒绝所有网络策略 复制链接链接已复制到粘贴板!
默认拒绝所有网络策略会阻止在主机网络 pod 之间配置其他部署网络策略和流量允许的所有跨 pod 网络。此流程通过在 my-project 命名空间中应用 deny-by-default 策略来强制实施强大的拒绝策略。
如果没有配置允许流量通信的 NetworkPolicy 自定义资源(CR),以下策略可能会导致集群中的通信问题。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
使用具有
admin权限的用户登陆到集群。 - 您在网络策略要应用到的命名空间中。
流程
创建以下 YAML,以定义
deny-by-default策略,以拒绝所有命名空间中的所有 pod 的入口流量。将 YAML 保存到deny-by-default.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
namespace-
指定要部署策略的命名空间。例如,
my-project命名空间。 podSelector-
如果此字段为空,则配置与所有 pod 匹配。因此,该策略适用于
my-project命名空间中的所有 pod。 ingress-
其中
[]表示没有指定入口规则。这会导致传入的流量丢弃至所有 pod。
输入以下命令应用策略。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2.4. 创建网络策略以允许来自外部客户端的流量 复制链接链接已复制到粘贴板!
使用 deny-by-default 策略,您可以继续配置策略,允许从外部客户端到带有标签 app=web 的 pod 的流量。
如果使用具有 cluster-admin 角色的用户登录,则可以在集群中的任何命名空间中创建网络策略。
按照以下步骤配置策略,以直接从公共互联网允许外部服务,或使用 Load Balancer 访问 pod。只有具有标签 app=web 的 pod 才允许流量。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
使用具有
admin权限的用户登陆到集群。 - 您在网络策略要应用到的命名空间中。
流程
创建策略,以直接从公共互联网的流量或使用负载均衡器访问 pod。将 YAML 保存到
web-allow-external.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令应用策略。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f web-allow-external.yaml
$ oc apply -f web-allow-external.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 此策略允许来自所有资源的流量,包括下图所示的外部流量:
6.3.2.5. 创建网络策略,允许从所有命名空间中到应用程序的流量 复制链接链接已复制到粘贴板!
您可以配置允许从所有命名空间中的所有 pod 流量到特定应用程序的策略。
如果使用具有 cluster-admin 角色的用户登录,则可以在集群中的任何命名空间中创建网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
使用具有
admin权限的用户登陆到集群。 - 您在网络策略要应用到的命名空间中。
流程
创建一个策略,允许从所有命名空间中的所有 pod 流量到特定应用。将 YAML 保存到
web-allow-all-namespaces.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
app-
仅将策略应用到 default 命名空间中的
app:webpod。 namespaceSelector选择所有命名空间中的所有 pod。
注意默认情况下,如果您没有在策略对象中指定
namespaceSelector参数,则不会选择命名空间。这意味着策略只允许从网络策略部署的命名空间的流量。
输入以下命令应用策略。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f web-allow-all-namespaces.yaml
$ oc apply -f web-allow-all-namespaces.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
输入以下命令在
default命名空间中启动 web 服务:oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令在
secondary命名空间中部署alpine镜像并启动 shell:oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 shell 中运行以下命令,并观察该服务是否允许请求:
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2.6. 创建网络策略,允许从一个命名空间中到应用程序的流量 复制链接链接已复制到粘贴板!
您可以配置允许从特定命名空间中到带有 app=web 标签的 pod 的策略。这个配置在以下情况下很有用:
- 将流量限制为部署了生产工作负载的命名空间。
- 启用部署到特定命名空间的监控工具,以从当前命名空间中提取指标。
如果使用具有 cluster-admin 角色的用户登录,则可以在集群中的任何命名空间中创建网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
使用具有
admin权限的用户登陆到集群。 - 您在网络策略要应用到的命名空间中。
流程
创建一个策略,允许来自特定命名空间中所有 pod 的流量,其标签为
purpose=production。将 YAML 保存到web-allow-prod.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
app-
仅将策略应用到 default 命名空间中的
app:webpod。 目的-
将流量仅限制为具有标签
purpose=production的命名空间中的 pod。
输入以下命令应用策略。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
输入以下命令在
default命名空间中启动 web 服务:oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
prod命名空间:oc create namespace prod
$ oc create namespace prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来标记
prod命名空间:oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
dev命名空间:oc create namespace dev
$ oc create namespace devCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来标记
dev命名空间:oc label namespace/dev purpose=testing
$ oc label namespace/dev purpose=testingCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令在
dev命名空间中部署alpine镜像并启动 shell:oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 shell 中运行以下命令,并观察请求的原因。例如,预期的输出状态为
wget:下载超时。wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,在
prod命名空间中部署alpine镜像并启动 shell:oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 shell 中运行以下命令,并观察是否允许请求:
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.3. 查看网络策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以查看命名空间的网络策略。
6.3.3.1. 示例 NetworkPolicy 对象 复制链接链接已复制到粘贴板!
以下配置注解一个 NetworkPolicy 对象:
其中:
name- NetworkPolicy 对象的名称。
spec.podSelector- 描述策略应用到的 pod 的选择器。策略对象只能选择定义 NetworkPolicy 对象的项目中的 pod。
ingress.from.podSelector- 与策略对象允许从中入口流量的 pod 匹配的选择器。选择器与 NetworkPolicy 在同一命名空间中的 pod 匹配。
ingress.ports- 接受流量的一个或多个目标端口的列表。
6.3.3.2. 使用 CLI 查看网络策略 复制链接链接已复制到粘贴板!
您可以检查命名空间中的网络策略。
如果使用具有 cluster-admin 角色的用户登录,您可以查看集群中的任何网络策略。
前提条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
admin权限的用户登陆到集群。 - 您在网络策略所在的命名空间中。
流程
列出命名空间中的网络策略。
要查看命名空间中定义的网络策略对象,请输入以下命令:
oc get networkpolicy
$ oc get networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选: 要检查特定的网络策略,请输入以下命令:
oc describe networkpolicy <policy_name> -n <namespace>
$ oc describe networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定要检查的网络策略的名称。
<namespace>可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
oc describe networkpolicy allow-same-namespace
$ oc describe networkpolicy allow-same-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
如果您使用 cluster-admin 权限登录到 web 控制台,您可以选择在集群中的任何命名空间中以 YAML 或 web 控制台的形式查看网络策略。
6.3.4. 编辑网络策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以编辑命名空间的现有网络策略。
6.3.4.1. 编辑网络策略 复制链接链接已复制到粘贴板!
您可以编辑命名空间中的网络策略。
如果使用具有 cluster-admin 角色的用户登录,则可以在集群中的任何命名空间中编辑网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
admin权限的用户登陆到集群。 - 您在网络策略所在的命名空间中。
流程
可选: 要列出一个命名空间中的网络策略对象,请输入以下命令:
oc get network policy -n <namespace>
$ oc get network policy -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<namespace>- 可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
编辑网络策略对象。
如果您在文件中保存了网络策略定义,请编辑该文件并进行必要的更改,然后输入以下命令。
oc apply -n <namespace> -f <policy_file>.yaml
$ oc apply -n <namespace> -f <policy_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<namespace>- 可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
<policy_file>- 指定包含网络策略的文件的名称。
如果您需要直接更新网络策略对象,请输入以下命令:
oc edit network policy <policy_name> -n <namespace>
$ oc edit network policy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定网络策略的名称。
<namespace>- 可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
确认网络策略对象已更新。
oc describe networkpolicy <policy_name> -n <namespace>
$ oc describe networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定网络策略的名称。
<namespace>- 可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
如果您使用 cluster-admin 权限登录到 web 控制台,您可以选择在集群中的任何命名空间中以 YAML 或通过 Actions 菜单从 web 控制台中的策略编辑网络策略。
6.3.4.2. 示例 NetworkPolicy 对象 复制链接链接已复制到粘贴板!
以下配置注解一个 NetworkPolicy 对象:
其中:
name- NetworkPolicy 对象的名称。
spec.podSelector- 描述策略应用到的 pod 的选择器。策略对象只能选择定义 NetworkPolicy 对象的项目中的 pod。
ingress.from.podSelector- 与策略对象允许从中入口流量的 pod 匹配的选择器。选择器与 NetworkPolicy 在同一命名空间中的 pod 匹配。
ingress.ports- 接受流量的一个或多个目标端口的列表。
6.3.5. 删除网络策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以从命名空间中删除网络策略。
6.3.5.1. 使用 CLI 删除网络策略 复制链接链接已复制到粘贴板!
您可以删除命名空间中的网络策略。
如果使用具有 cluster-admin 角色的用户登录,您可以删除集群中的任何网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
使用具有
admin权限的用户登陆到集群。 - 您在网络策略所在的命名空间中。
流程
要删除网络策略对象,请输入以下命令。成功输出列出了策略对象的名称以及
已删除的状态。oc delete networkpolicy <policy_name> -n <namespace>
$ oc delete networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定网络策略的名称。
<namespace>- 可选参数。如果您在与当前命名空间不同的命名空间中定义了对象,则参数会特定于命名空间。
如果使用 cluster-admin 权限登录到 web 控制台,您可以选择在集群上以 YAML 或通过 Actions 菜单从 web 控制台中的策略删除网络策略。
6.3.6. 为项目定义默认网络策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在创建新项目时修改新项目模板,使其自动包含网络策略。如果您还没有新项目的自定义模板,则需要首先创建一个。
6.3.6.1. 为新项目修改模板 复制链接链接已复制到粘贴板!
作为集群管理员,您可以修改默认项目模板,以便使用自定义要求创建新项目。
创建自己的自定义项目模板:
先决条件
-
可以使用具有
cluster-admin权限的账户访问 OpenShift Container Platform 集群。
流程
-
以具有
cluster-admin特权的用户身份登录。 生成默认项目模板:
oc adm create-bootstrap-project-template -o yaml > template.yaml
$ oc adm create-bootstrap-project-template -o yaml > template.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
使用文本编辑器,通过添加对象或修改现有对象来修改生成的
template.yaml文件。 项目模板必须创建在
openshift-config命名空间中。加载修改后的模板:oc create -f template.yaml -n openshift-config
$ oc create -f template.yaml -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用 Web 控制台或 CLI 编辑项目配置资源。
使用 Web 控制台:
- 导航至 Administration → Cluster Settings 页面。
- 单击 Configuration 以查看所有配置资源。
- 找到 Project 的条目,并点击 Edit YAML。
使用 CLI:
编辑
project.config.openshift.io/cluster资源:oc edit project.config.openshift.io/cluster
$ oc edit project.config.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow
更新
spec部分,使其包含projectRequestTemplate和name参数,再设置您上传的项目模板的名称。默认名称为project-request。带有自定义项目模板的项目配置资源
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存更改后,创建一个新项目来验证是否成功应用了您的更改。
6.3.6.2. 在新项目模板中添加网络策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在新项目的默认模板中添加网络策略。OpenShift Container Platform 将自动创建项目中模板中指定的所有 NetworkPolicy 对象。
先决条件
-
集群使用支持
NetworkPolicy对象的默认 CNI 网络插件,如设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
您需要使用具有
cluster-admin权限的用户登陆到集群。 - 您必须已为新项目创建了自定义的默认项目模板。
流程
运行以下命令来编辑新项目的默认模板:
oc edit template <project_template> -n openshift-config
$ oc edit template <project_template> -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<project_template>替换为您为集群配置的缺省模板的名称。默认模板名称为project-request。在模板中,将每个
NetworkPolicy对象作为一个元素添加到objects参数中。objects参数可以是一个或多个对象的集合。在以下示例中,
objects参数集合包括几个NetworkPolicy对象。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:创建一个新项目,并确认您的网络策略对象成功创建。
创建一个新项目
oc new-project <project>
$ oc new-project <project>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<project>替换为您要创建的项目的名称。
确认新项目模板中的网络策略对象存在于新项目中:
oc get networkpolicy
$ oc get networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出:
NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s
NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.7. 使用网络策略配置多租户隔离 复制链接链接已复制到粘贴板!
作为集群管理员,您可以配置网络策略以为多租户网络提供隔离功能。
如果使用 OpenShift SDN 网络插件,请按照本节所述配置网络策略,提供类似于多租户模式的网络隔离,但设置了网络策略模式。
6.3.7.1. 使用网络策略配置多租户隔离 复制链接链接已复制到粘贴板!
您可以配置项目,使其与其他项目命名空间中的 pod 和服务分离。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
admin权限的用户登陆到集群。
流程
创建以下
NetworkPolicy对象:名为
allow-from-openshift-ingress的策略。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意policy-group.network.openshift.io/ingress: ""是 OpenShift SDN 的首选命名空间选择器标签。您可以使用network.openshift.io/policy-group: ingress命名空间选择器标签,但这是一个比较旧的用法。名为
allow-from-openshift-monitoring的策略:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 名为
allow-same-namespace的策略:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 名为
allow-from-kube-apiserver-operator的策略:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如需了解更多详细信息,请参阅 新的
kube-apiserver-operatorWebhook 控制器验证 Webhook 的健康状况。
可选: 要确认当前项目中存在网络策略,请输入以下命令:
oc describe networkpolicy
$ oc describe networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.7.2. 后续步骤 复制链接链接已复制到粘贴板!
6.4. 网络安全的审计日志记录 复制链接链接已复制到粘贴板!
OVN-Kubernetes 网络插件使用 Open Virtual Network (OVN) 访问控制列表 (ACL) 来管理 AdminNetworkPolicy、BaselineAdminNetworkPolicy、NetworkPolicy 和 EgressFirewall 对象。审计日志记录会公开 NetworkPolicy, EgressFirewall 和 BaselineAdminNetworkPolicy 自定义资源 (CR) 的 allow 和 deny ACL 事件。日志记录还公开 AdminNetworkPolicy (ANP) CR 的 allow, deny, 和 pass ACL 的事件。
审计日志记录仅适用于 OVN-Kubernetes 网络插件。
6.4.1. 审计配置 复制链接链接已复制到粘贴板!
审计日志记录的配置作为 OVN-Kubernetes 集群网络配置的一部分指定。以下 YAML 演示了审计日志的默认值:
审计日志记录配置
下表描述了审计日志的配置字段。
| 字段 | 类型 | 描述 |
|---|---|---|
|
| 整数 |
每个节点每秒生成一次的消息数量上限。默认值为每秒 |
|
| 整数 |
审计日志的最大大小,以字节为单位。默认值为 |
|
| 整数 | 保留的日志文件的最大数量。 |
|
| 字符串 | 以下附加审计日志目标之一:
|
|
| 字符串 |
syslog 工具,如 as |
6.4.2. 审计日志记录 复制链接链接已复制到粘贴板!
您可以为审计日志配置目的地,如 syslog 服务器或 UNIX 域套接字。无论任何其他配置如何,审计日志始终保存到集群中的每个 OVN-Kubernetes pod 上的 /var/log/ovn/acl-audit-log。
您可以使用 k8s.ovn.org/acl-logging 部分为每个命名空间启用审计日志记录。在 k8s.ovn.org/acl-logging 部分中,您必须指定 allow、deny 或这两个值来为命名空间启用审计日志记录。
网络策略不支持将 Pass 操作设置为规则。
ACL-logging 实现记录网络的访问控制列表 (ACL) 事件。您可以查看这些日志来分析任何潜在的安全问题。
命名空间注解示例
要查看默认的 ACL 日志记录配置值,请参阅 cluster-network-03-config.yml 文件中的 policyAuditConfig 对象。如果需要,您可以更改此文件中的日志文件参数的 ACL 日志记录配置值。
日志信息格式与 RFC5424 中定义的 syslog 兼容。syslog 工具可配置,默认为 local0。以下示例显示了日志消息中输出的关键参数及其值:
输出参数及其值的日志记录消息示例
<timestamp>|<message_serial>|acl_log(ovn_pinctrl0)|<severity>|name="<acl_name>", verdict="<verdict>", severity="<severity>", direction="<direction>": <flow>
<timestamp>|<message_serial>|acl_log(ovn_pinctrl0)|<severity>|name="<acl_name>", verdict="<verdict>", severity="<severity>", direction="<direction>": <flow>
其中:
-
<timestamp>声明创建日志消息的时间和日期。 -
<message_serial>列出日志消息的序列号。 -
acl_log (ovn_pinctrl0)是一个字面字符串,它会在 OVN-Kubernetes 插件中输出日志消息的位置。 -
<severity>为日志消息设置严重性级别。如果您启用支持allow和deny任务的审计日志记录,则日志消息输出中会显示两个严重性级别。 -
<name>说明由网络策略创建的 OVN Network Bridging Database (nbdb) 中的 ACL-logging 实现的名称。 -
<verdict>可以是allow或drop。 -
<direction>可以是to-lport或from-lport,表示策略应用到 pod 的流量。 -
<flow>显示与OpenFlow协议等效的格式的数据包信息。此参数包含 Open vSwitch (OVS) 字段。
以下示例显示了 flow 参数用来从系统内存提取数据包信息的 OVS 字段:
flow 参数用来提取数据包信息的 OVS 字段示例
<proto>,vlan_tci=0x0000,dl_src=<src_mac>,dl_dst=<source_mac>,nw_src=<source_ip>,nw_dst=<target_ip>,nw_tos=<tos_dscp>,nw_ecn=<tos_ecn>,nw_ttl=<ip_ttl>,nw_frag=<fragment>,tp_src=<tcp_src_port>,tp_dst=<tcp_dst_port>,tcp_flags=<tcp_flags>
<proto>,vlan_tci=0x0000,dl_src=<src_mac>,dl_dst=<source_mac>,nw_src=<source_ip>,nw_dst=<target_ip>,nw_tos=<tos_dscp>,nw_ecn=<tos_ecn>,nw_ttl=<ip_ttl>,nw_frag=<fragment>,tp_src=<tcp_src_port>,tp_dst=<tcp_dst_port>,tcp_flags=<tcp_flags>
其中:
-
<proto>声明协议。有效值为tcp和udp。 -
vlan_tci=0x0000声明 VLAN 标头为0,因为没有为内部 pod 网络流量设置 VLAN ID。 -
<src_mac>指定 Media Access Control (MAC) 地址的源。 -
<source_mac>指定 MAC 地址的目的地。 -
<source_ip>列出源 IP 地址 -
<target_ip>列出目标 IP 地址。 -
<tos_dscp>声明 Differentiated Services Code Point (DSCP) 值,对网络流量进行分类并进行优先级排序。 -
<tos_ecn>声明 Explicit Congestion Notification (ECN) 值,它表示您的网络中的阻塞网络流量。 -
<ip_ttl>声明数据包的 Time To Live (TTP) 信息。 -
<fragment>指定要匹配的 IP 片段或 IP 非碎片。 -
<tcp_src_port>显示 TCP 和 UDP 协议的端口源。 -
<tcp_dst_port>列出 TCP 和 UDP 协议的目的地端口。 -
<tcp_flags>支持多个标示,如SYN,ACK,PSH等。如果您需要设置多个值,则不同的值由竖线 (|) 分隔。UDP 协议不支持此参数。
有关前面的字段描述的更多信息,请转至 ovs-fields 的 OVS 手册页。
网络策略的 ACL 拒绝日志条目示例
2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn 2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn 2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
下表描述了命名空间注解值:
| 字段 | 描述 |
|---|---|
|
|
阻止任何与 |
|
|
允许命名空间访问与 |
|
|
|
6.4.3. AdminNetworkPolicy 审计日志记录 复制链接链接已复制到粘贴板!
每个 AdminNetworkPolicy CR 启用了审计日志记录,使用 k8s.ovn.org/acl-logging 键注解 ANP 策略,如下例所示:
例 6.19. AdminNetworkPolicy CR 的注解示例
每当特定的 OVN ACL 达到并满足日志记录注解中设置的操作条件时,都会生成日志。例如,一个事件,其中任何带有标签 tenant: product-development 的命名空间都访问带有标签 tenant: backend-storage 的命名空间,则会生成日志。
ACL 日志记录限制为 60 个字符。如果您的 ANP name 字段较长,日志的其余部分将被截断。
以下是以下示例日志条目的方向索引:
| 方向 | 规则 |
|---|---|
| 入口 |
|
| Egress |
|
例 6.20. ACL 日志项示例,用于带有 Ingress:0 和 Egress:0 的名为 anp-tenant-log 的 AdminNetworkPolicy 的 Allow 操作
2024-06-10T16:27:45.194Z|00052|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1a,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.26,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=57814,tp_dst=8080,tcp_flags=syn 2024-06-10T16:28:23.130Z|00059|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:18,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.24,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=38620,tp_dst=8080,tcp_flags=ack 2024-06-10T16:28:38.293Z|00069|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:0", verdict=allow, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1a,nw_src=10.128.2.25,nw_dst=10.128.2.26,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=47566,tp_dst=8080,tcp_flags=fin|ack=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=55704,tp_dst=8080,tcp_flags=ack
2024-06-10T16:27:45.194Z|00052|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1a,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.26,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=57814,tp_dst=8080,tcp_flags=syn
2024-06-10T16:28:23.130Z|00059|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:18,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.24,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=38620,tp_dst=8080,tcp_flags=ack
2024-06-10T16:28:38.293Z|00069|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:0", verdict=allow, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1a,nw_src=10.128.2.25,nw_dst=10.128.2.26,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=47566,tp_dst=8080,tcp_flags=fin|ack=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=55704,tp_dst=8080,tcp_flags=ack
例 6.21. ACL 日志项示例,用于带有 Ingress:1 和 Egress:1 的名为 anp-tenant-log 的 AdminNetworkPolicy 的 Pass 操作
2024-06-10T16:33:12.019Z|00075|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:1", verdict=pass, severity=warning, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1b,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.27,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=37394,tp_dst=8080,tcp_flags=ack 2024-06-10T16:35:04.209Z|00081|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:1", verdict=pass, severity=warning, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1b,nw_src=10.128.2.25,nw_dst=10.128.2.27,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=34018,tp_dst=8080,tcp_flags=ack
2024-06-10T16:33:12.019Z|00075|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:1", verdict=pass, severity=warning, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1b,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.27,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=37394,tp_dst=8080,tcp_flags=ack
2024-06-10T16:35:04.209Z|00081|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:1", verdict=pass, severity=warning, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1b,nw_src=10.128.2.25,nw_dst=10.128.2.27,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=34018,tp_dst=8080,tcp_flags=ack
例 6.22. ACL 日志项示例,用于带有 Ingress:2 和 Egress:2 的名为 anp-tenant-log 的 AdminNetworkPolicy 的 Deny 操作
2024-06-10T16:43:05.287Z|00087|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:2", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:18,nw_src=10.128.2.25,nw_dst=10.128.2.24,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=51598,tp_dst=8080,tcp_flags=syn 2024-06-10T16:44:43.591Z|00090|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:2", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1c,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.28,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=33774,tp_dst=8080,tcp_flags=syn
2024-06-10T16:43:05.287Z|00087|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:2", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:18,nw_src=10.128.2.25,nw_dst=10.128.2.24,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=51598,tp_dst=8080,tcp_flags=syn
2024-06-10T16:44:43.591Z|00090|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:2", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1c,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.28,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=33774,tp_dst=8080,tcp_flags=syn
下表描述了 ANP 注解:
| 注解 | value |
|---|---|
|
|
您必须至少指定
|
6.4.4. BaselineAdminNetworkPolicy 审计日志记录 复制链接链接已复制到粘贴板!
使用 k8s.ovn.org/acl-logging 键注解 BANP 策略,在 BaselineAdminNetworkPolicy CR 中启用审计日志记录,如下例所示:
例 6.23. BaselineAdminNetworkPolicy CR 的注解示例
在示例中,一个事件,其中任何带有标签 tenant: dns 的命名空间都访问带有标签 tenant: workload 的命名空间,则会生成日志。
以下是以下示例日志条目的方向索引:
| 方向 | 规则 |
|---|---|
| 入口 |
|
| Egress |
|
例 6.24. ACL allow 日志项示例,用于带有 Ingress:0 的 default BANP 的 Allow 操作
例 6.25. ACL allow 日志项示例,用于带有 Egress:0 和 Ingress:1 的 default BANP 的 Allow 操作
下表描述了 BANP 注解:
| 注解 | value |
|---|---|
|
|
您必须至少指定
|
6.4.5. 为集群配置出口防火墙和网络策略审计 复制链接链接已复制到粘贴板!
作为集群管理员,您可以自定义集群的审计日志。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
要自定义审计日志配置,请输入以下命令:
oc edit network.operator.openshift.io/cluster
$ oc edit network.operator.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以自定义并应用以下 YAML 来配置审计日志记录:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要创建带有网络策略的命名空间,请完成以下步骤:
创建命名空间进行验证:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 成功输出使用网络策略和创建的状态列出命名空间。
为命名空间创建网络策略:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
networkpolicy.networking.k8s.io/deny-all created networkpolicy.networking.k8s.io/allow-from-same-namespace created
networkpolicy.networking.k8s.io/deny-all created networkpolicy.networking.k8s.io/allow-from-same-namespace createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
为
default命名空间中的源流量创建 pod:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
verify-audit-logging命名空间中创建两个 pod:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 成功输出会列出两个 pod,如
pod/client和pod/server,以及创建的状态。要生成流量并生成网络策略审计日志条目,请完成以下步骤:
在
verify-audit-logging命名空间中获取名为server的 pod 的 IP 地址:POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')$ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 从
default命名空间中名为client的 pod 中 ping 之前命令中的 IP 地址,并确认所有数据包都已丢弃:oc exec -it client -n default -- /bin/ping -c 2 $POD_IP
$ oc exec -it client -n default -- /bin/ping -c 2 $POD_IPCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data. --- 10.128.2.55 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 2041ms
PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data. --- 10.128.2.55 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 2041msCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从
verify-audit-logging命名空间中的客户端 pod 中,pingPOD_IP shell环境变量中存储的 IP 地址,并确认系统允许所有数据包。oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP
$ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IPCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
显示网络策略审计日志中的最新条目:
for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log done$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.6. 为命名空间启用出口防火墙和网络策略审计日志 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为命名空间启用审计日志。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
要为命名空间启用审计日志,请输入以下命令:
oc annotate namespace <namespace> \ k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'$ oc annotate namespace <namespace> \ k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<namespace>- 指定命名空间的名称。
提示您还可以应用以下 YAML 来启用审计日志记录:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 成功输出列出了审计日志记录名称和
注解的状态。
验证
显示审计日志中的最新条目:
for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log done$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.7. 为命名空间禁用出口防火墙和网络策略审计日志 复制链接链接已复制到粘贴板!
作为集群管理员,您可以禁用命名空间的审计日志。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
要为命名空间禁用审计日志,请输入以下命令:
oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-
$ oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<namespace>- 指定命名空间的名称。
提示您还可以应用以下 YAML 来禁用审计日志记录:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 成功输出列出了审计日志记录名称和
注解的状态。
6.5. Egress 防火墙 复制链接链接已复制到粘贴板!
6.5.1. 查看项目的出口防火墙 复制链接链接已复制到粘贴板!
作为集群管理员,您可以列出任何现有出口防火墙的名称,并查看特定出口防火墙的流量规则。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
6.5.1.1. 查看 EgressNetworkPolicy 自定义资源(CR) 复制链接链接已复制到粘贴板!
您可以查看集群中的 EgressNetworkPolicy CR。
先决条件
- 使用 OpenShift SDN 网络插件的集群。
-
安装 OpenShift 命令行界面 (CLI),通常称为
oc。 - 您必须登录集群。
流程
可选: 要查看集群中定义的
EgressNetworkPolicyCR 的名称,请输入以下命令:oc get egressnetworkpolicy --all-namespaces
$ oc get egressnetworkpolicy --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要检查策略,请输入以下命令。将
<policy_name>替换为要检查的策略名称。oc describe egressnetworkpolicy <policy_name>
$ oc describe egressnetworkpolicy <policy_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.1.2. 查看 EgressFirewall 自定义资源 (CR) 复制链接链接已复制到粘贴板!
您可以查看集群中的 EgressFirewall CR。
先决条件
- 使用 OVN-Kubernetes 网络插件的集群。
-
安装 OpenShift 命令行界面 (CLI),通常称为
oc。 - 您必须登录集群。
流程
可选: 要查看集群中定义的
EgressFirewallCR 的名称,请输入以下命令:oc get egressfirewall --all-namespaces
$ oc get egressfirewall --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要检查策略,请输入以下命令。将
<policy_name>替换为要检查的策略名称。oc describe egressfirewall <policy_name>
$ oc describe egressfirewall <policy_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.2. 为项目编辑出口防火墙 复制链接链接已复制到粘贴板!
作为集群管理员,您可以修改现有出口防火墙的网络流量规则。
6.5.2.1. 编辑 EgressFirewall 自定义资源 (CR) 复制链接链接已复制到粘贴板!
作为集群管理员,您可以更新一个项目的出口防火墙。
先决条件
- 使用 OVN-Kubernetes 网络插件的集群。
-
安装 OpenShift CLI (
oc) 。 - 您需要使用集群管理员身份登陆到集群。
流程
查找项目的
EgressFirewallCR 的名称。将<project>替换为项目的名称。oc get -n <project> egressfirewall
$ oc get -n <project> egressfirewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:如果您在创建出口网络防火墙时没有保存
EgressFirewall对象的副本,请输入以下命令来创建副本。oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
$ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<project>替换为项目的名称。将<name>替换为 Pod 的名称。将<filename>替换为要将 YAML 保存到的文件的名称。更改策略规则后,输入以下命令替换
EgressFirewallCR。将<filename>替换为包含更新的EgressFirewallCR 的文件名称。oc replace -f <filename>.yaml
$ oc replace -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.3. 从项目中删除出口防火墙 复制链接链接已复制到粘贴板!
作为集群管理员,您可以从项目中删除出口防火墙,从而删除对项目的离开 OpenShift Container Platform 集群的网络流量的限制。
6.5.3.1. 删除 EgressFirewall CR 复制链接链接已复制到粘贴板!
作为集群管理员,您可以从项目中删除出口防火墙。
先决条件
- 使用 OVN-Kubernetes 网络插件的集群。
-
安装 OpenShift CLI (
oc) 。 - 您需要使用集群管理员身份登陆到集群。
流程
查找项目的
EgressFirewallCR 的名称。将<project>替换为项目的名称。oc get egressfirewall -n <project>
$ oc get egressfirewall -n <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令删除
EgressFirewallCR。将<project>替换为项目名称,<name>替换为对象名称。oc delete -n <project> egressfirewall <name>
$ oc delete -n <project> egressfirewall <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.4. 为项目配置出口防火墙 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为项目创建一个出口防火墙,用于限制离开 OpenShift Container Platform 集群的出口流量。
6.5.4.1. 出口防火墙在一个项目中的工作原理 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用一个出口防火墙来限制集群内的一些 pod 或所有 pod 可以访问的外部主机。出口防火墙适用于以下情况:
- pod 只能连接到内部主机,且无法启动到公共互联网的连接。
- pod 只能连接到公共互联网,且无法启动到 OpenShift Container Platform 集群以外的内部主机的连接。
- pod 无法访问 OpenShift Container Platform 集群外的特定内部子网或主机。
- pod 只能连接到特定的外部主机。
例如,您可以允许某一个项目访问指定的 IP 范围,但拒绝其他项目对同一 IP 范围的访问。或者您可以限制应用程序开发人员从 Python pip 的镜像点进行更新,并强制要求更新只能来自于批准的源。
您可以通过创建一个 EgressFirewall 自定义资源 (CR) 来配置出口防火墙策略。出口防火墙与满足以下任一条件的网络流量匹配:
- CIDR 格式的 IP 地址范围
- 解析为 IP 地址的 DNS 名称
- 端口号
- 协议是以下协议之一: TCP、UDP 和 SCTP
6.5.4.1.1. 出口防火墙的限制 复制链接链接已复制到粘贴板!
出口防火墙有以下限制:
-
项目不能有多个
EgressFirewallCR。 -
出口防火墙规则不适用于通过路由器的网络流量。任何有权创建
RouteCR 对象的用户,都可以通过创建指向禁止的目的地的路由来绕过出口防火墙策略规则。 - 出口防火墙不适用于主机网络命名空间。启用主机网络的 Pod 不受出口防火墙规则的影响。
如果您的出口防火墙包含
0.0.0.0/0的拒绝规则,则阻止访问 OpenShift Container Platform API 服务器。您必须为每个 IP 地址添加允许规则,或使用出口策略规则中的nodeSelector类型允许规则来连接到 API 服务器。以下示例演示了确保 API 服务器访问所需的出口防火墙规则的顺序:
EgressFirewallAPI 服务器访问示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
- <namespace>
- 指定出口防火墙的命名空间。
- <api_server_address_range>
- 指定包含 OpenShift Container Platform API 服务器的 IP 地址范围。
- <cidrSelector>
指定
0.0.0.0/0值来设置全局拒绝规则,阻止访问 OpenShift Container Platform API 服务器。要查找 API 服务器的 IP 地址,请运行
oc get ep kubernetes -n default。如需更多信息,请参阅 BZ#1988324。
-
每个项目最多可定义一个具有最多 8,000 个规则的
EgressFirewall对象。 - 如果您在 Red Hat OpenShift Networking 中使用带有共享网关模式的 OVN-Kubernetes 网络插件,则返回入口回复会受到出口防火墙规则的影响。如果出口防火墙规则丢弃入口回复目的地 IP,流量将被丢弃。
- 通常,在出口防火墙策略中使用域名服务器(DNS)名称不会影响通过 CoreDNS 进行本地 DNS 解析。但是,如果您的出口防火墙策略使用域名,并且外部 DNS 服务器处理受影响 pod 的 DNS 解析,则必须包括允许访问 DNS 服务器的 IP 地址的出口防火墙规则。
违反这些限制会导致项目的出口防火墙出现问题。因此,所有外部网络流量都会被丢弃,这可能会给您的组织造成安全风险。
kube-node-lease、kube-public、kube-system、openshift 和 openshift- 项目中创建一个 EgressFirewall 资源。
6.5.4.1.2. 出口防火墙策略规则的匹配顺序 复制链接链接已复制到粘贴板!
OVN-Kubernetes 根据定义的顺序评估出口防火墙策略规则,从第一个到最后一个的顺序。第一个与 pod 的出口连接匹配的规则会被应用。该连接会忽略后续的所有规则。
6.5.4.1.3. 域名服务器 (DNS) 解析如何工作 复制链接链接已复制到粘贴板!
如果您在 egress 防火墙策略规则中使用 DNS 名称,则正确解析域名会受到以下限制:
- 域名更新会根据生存时间(TTL)持续时间进行轮询。默认情况下,持续时间为 30 分钟。当出口防火墙控制器查询本地名称服务器以获取域名时,如果响应包含 TTL 且 TTL 小于 30 分钟,控制器会将该 DNS 名称的持续时间设置为返回的值。每个 DNS 名称都会在 DNS 记录的 TTL 过期后查询。
- 在需要时,pod 必须通过相同的本地名称服务器解析域名。否则,egress 防火墙控制器和 pod 已知的域的 IP 地址可能会有所不同。如果主机名的 IP 地址不同,则出口防火墙的强制实施可能不一致。
-
因为出口防火墙控制器和 pod 异步轮询相同的本地名称服务器,所以 pod 可能会在出口控制器执行前获取更新的 IP 地址,从而导致竞争条件。由于这个限制,仅建议在
EgressFirewall对象中使用域名来更改 IP 地址的域。
6.5.4.1.3.1. 改进了 DNS 解析并解析通配符域名 复制链接链接已复制到粘贴板!
在某些情况下,与 DNS 记录关联的 IP 地址会频繁更改,或者您可能希望在出口(egress)防火墙策略规则中指定通配符域名。
在这种情况下,OVN-Kubernetes 集群管理器为每个出口防火墙策略规则中使用的每个唯一 DNS 名称创建一个 DNSNameResolver 自定义资源对象。此自定义资源存储以下信息:
改进了出口防火墙规则的 DNS 解析只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
DNSNameResolver CR 定义示例
其中:
- <name>
- 指定 DNS 名称。这可以是标准 DNS 名称或通配符 DNS 名称。对于通配符 DNS 名称,DNS 名称解析信息包含与通配符 DNS 名称匹配的所有 DNS 名称。
- <dnsName>
-
指定与
spec.name字段匹配的解析 DNS 名称。如果spec.name字段包含通配符 DNS 名称,则会创建多个dnsName条目,其中包含在解析时与通配符 DNS 名称匹配的标准 DNS 名称。如果通配符 DNS 名称也可以成功解析,则此字段也存储通配符 DNS 名称。<ip> 指定与 DNS 名称关联的当前 IP 地址。 - <ttlSeconds>
- 指定最后一次生存时间(TTL)持续时间。
- <lastLookupTime>
- 指定最后一次查找时间。
如果在 DNS 解析 DNS 名称的过程中,查询中的 DNS 名称与 DNSNameResolver CR 中定义的任何名称匹配,那么在 CR status 字段中会相应地更新之前的信息。如果 DNS 通配符名称查找失败,会在默认的 TTL 为 30 分钟后重试请求。
OVN-Kubernetes 集群管理器监视对 EgressFirewall 自定义资源对象的更新,并在更新发生时创建、修改或删除与这些出口防火墙策略关联的 DNSNameResolver CR。
不要直接修改 DNSNameResolver 自定义资源。这可能导致出口防火墙的不需要的行为。
6.5.4.2. EgressFirewall 自定义资源 (CR) 复制链接链接已复制到粘贴板!
您可以为出口防火墙定义一个或多个规则。规则是一个 Allow 规则,也可以是一个 Deny 规则,它包括规则适用的流量规格。
以下 YAML 描述了 EgressFirewall CR:
EgressFirewall 对象
其中:
- <ovn>
-
对象的名称必须是
default。 - <egress_rules>
- 如下小节所述,指定一个或多个出口网络策略规则的集合。
6.5.4.2.1. EgressFirewall 规则 复制链接链接已复制到粘贴板!
以下 YAML 描述了 EgressFirewall 资源的规则。用户可以选择 CIDR 格式的 IP 地址范围、域名,或使用 nodeSelector 字段来允许或拒绝出口流量。egress 小节需要一个包括一个或多个对象的数组。
出口策略规则小节
其中:
- <type>
-
指定规则的类型。该值必须是
Allow或Deny。 - <to>
-
指定描述出口流量匹配规则的小节,该规则指定
cidrSelector字段或dnsName字段。您不能在同一规则中使用这两个字段。 - <cidr_range>
- 指定 CIDR 格式的 IP 地址范围。
- <dns_name>
- 指定 DNS 域名。
- <nodeSelector>
-
指定标签,它们是用户定义的键和值对。标签附加到对象,如 pod。
nodeSelector允许选择一个或多个节点标签,并附加到 pod。 - <ports>
- 指定描述规则的网络端口和协议集合的可选字段。
端口小节
ports: - port: protocol:
ports:
- port:
protocol:
其中:
- <port>
-
指定网络端口,如
80或443。如果为此字段指定一个值,还必须为protocol字段指定一个值。 - <protocol>
-
指定网络协议。该值必须是
TCP、UDP或SCTP。
6.5.4.2.2. EgressFirewall CR 示例 复制链接链接已复制到粘贴板!
以下示例定义了几个出口防火墙策略规则:
其中:
- <egress>
- 指定出口防火墙策略规则对象的集合。
以下示例定义了一个策略规则,即如果流量使用 TCP 协议和目标端口 80,或任何协议和目标端口 443,则拒绝通过 172.16.1.1/32 IP 地址到主机的流量。
6.5.4.2.3. 使用 nodeSelector 的 EgressFirewall CR 示例 复制链接链接已复制到粘贴板!
作为一个集群管理员,您可以使用 nodeSelector 字段指定标签来允许或拒绝集群中节点的出口流量。标签可以应用到一个或多个节点。标签很有用,因为不是为每个节点 IP 地址添加手动规则,所以您可以使用节点选择器创建一个标签,以允许出口防火墙后面的 pod 访问主机网络 pod。以下是带有 region=east 标签的示例:
6.5.4.3. 创建 EgressFirewall 自定义资源 (CR) 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为项目创建一个出口防火墙策略对象。
如果项目已有 EgressFirewall 资源,您必须编辑现有策略来更改出口防火墙规则。
先决条件
- 使用 OVN-Kubernetes 网络插件的集群。
-
安装 OpenShift CLI (
oc) 。 - 您需要使用集群管理员身份登陆到集群。
流程
创建策略规则:
-
创建一个
<policy_name>.yaml文件,其中<policy_name>描述出口策略规则。 -
在文件中定义
EgressFirewall对象。
-
创建一个
运行以下命令来创建策略对象。将
<policy_name>替换为策略的名称,<project>替换为规则应用到的项目。oc create -f <policy_name>.yaml -n <project>
$ oc create -f <policy_name>.yaml -n <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 成功输出列出了
egressfirewall.k8s.ovn.org/v1名称以及created状态。-
可选:保存
<policy_name>.yaml文件,以便在以后进行修改。
6.6. 配置 IPsec 加密 复制链接链接已复制到粘贴板!
通过启用 IPsec,您可以加密节点之间的内部 pod 到 pod 集群流量,以及集群外部的 pod 和 IPsec 端点之间的外部流量。OVN-Kubernetes 集群网络上的节点之间的所有 pod 到 pod 网络流量都使用 IPsec 传输模式 加密。
默认禁用 IPsec。您可以在安装集群安装过程中或安装后启用 IPsec。有关集群安装的详情,请参阅 OpenShift Container Platform 安装概述。
当 libreswan 和 NetworkManager-libreswan 软件包有不同的 OpenShift Container Platform 版本时,将集群升级到 OpenShift Container Platform 4.16 会导致两个连续的计算节点重新引导操作。对于第一次重启,Cluster Network Operator (CNO)将 IPsec 配置应用到计算节点。对于第二个重启,Machine Config Operator (MCO)会将最新的机器配置应用到集群。
要将 CNO 和 MCO 更新合并到单一节点重启后,请完成以下任务:
-
在升级集群前,在对计算节点进行分组的
MachineConfigPools自定义资源(CR)中将paused参数设置为true。 -
在升级集群后,将参数设置为
false。
如需更多信息,请参阅 执行 Control Plane Only 更新。
OpenShift Container Platform 集群中 IPsec 存在以下支持限制:
- 在 IBM Cloud® 上,IPsec 仅支持 NAT-T。在此平台上不支持 Encapsulating Security Payload (ESP)。
- 如果您的集群在 Red Hat OpenShift Container Platform 中使用 托管的 control plane,则 IPsec 不支持 pod 到 pod,以及到外部主机的 IPsec 加密。
- 如果有一个或多个接口附加到 Open vSwitch (OVS),则不支持在任何网络接口中使用 ESP 硬件卸载。为集群启用 IPsec 会触发将 IPsec 与附加到 OVS 的接口搭配使用。默认情况下,OpenShift Container Platform 在附加到 OVS 的任何接口上禁用 ESP 硬件卸载。
- 如果您为未附加到 OVS 的网络接口启用了 IPsec,集群管理员必须在未附加到 OVS 的每个接口上手动禁用 ESP 硬件卸载。
-
Red Hat Enterprise Linux (RHEL)计算节点上不支持 IPsec,因为主机和每个计算节点上存在的
ovn-ipsec容器间的libreswan不兼容问题。请参阅(OCPBUGS-53316)。
以下列表概述了 IPsec 文档中的关键任务:
- 在集群安装后启用和禁用 IPsec。
- 为集群和外部主机之间的流量配置 IPsec 加密。
- 验证 IPsec 是否加密不同节点上的 pod 之间的流量。
6.6.1. 操作模式 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 集群中使用 IPsec 时,您可以从以下操作模式中选择:
| 模式 | 描述 | default |
|---|---|---|
|
| 没有流量被加密。这是集群的默认设置。 | 是 |
|
| pod 到 pod 的流量被加密,如"由 pod 到 pod IPsec 加密的网络流量类型"中所述。完成 IPsec 所需的配置步骤后,可以加密到外部节点的流量。 | 否 |
|
| 完成 IPsec 所需的配置步骤后,可以加密到外部节点的流量。 | 否 |
6.6.2. 先决条件 复制链接链接已复制到粘贴板!
对于将流量加密到外部主机的 IPsec 支持,请确保您满足以下先决条件:
-
在 OVN-Kubernetes 网络插件的
ovnKubernetesConfig.gatewayConfig规格中设置routingViaHost=true。 安装 NMState Operator。指定 IPsec 配置需要这个 Operator。如需更多信息,请参阅 Kubernetes NMState Operator。
注意Google Cloud 仅支持 NMState Operator 来配置 IPsec。
-
已安装 Butane 工具 (
butane)。要安装 Butane,请参阅安装 Butane。
这些先决条件需要将证书添加到主机 NSS 数据库中,并配置 IPsec 与外部主机进行通信。
6.6.3. 启用 IPsec 时的网络连接要求 复制链接链接已复制到粘贴板!
您必须配置机器之间的网络连接,以允许 OpenShift Container Platform 集群组件进行通信。每台机器都必须能够解析集群中所有其他机器的主机名。
| 协议 | port | 描述 |
|---|---|---|
| UDP |
| IPsec IKE 数据包 |
|
| IPsec NAT-T 数据包 | |
| ESP | N/A | IPsec Encapsulating Security Payload(ESP) |
6.6.4. pod 到 pod 流量的 IPsec 加密 复制链接链接已复制到粘贴板!
对于 pod 到 pod 流量的 IPsec 加密,以下小节描述了加密哪些特定的 pod 到 pod 的流量,使用什么加密协议,以及如何处理 X.509 证书。这些部分不适用于集群和外部主机之间的 IPsec 加密,您必须为特定的外部网络基础架构手动配置。
6.6.4.1. 由 pod 到 pod IPsec 加密的网络流量类型 复制链接链接已复制到粘贴板!
启用 IPsec 后,只有 pod 间的以下网络流量会被加密:
- 集群网络的不同节点上的 pod 间的流量
- 从主机网络上的 pod 流量到集群网络上的 pod
以下流量流没有加密:
- 集群网络上同一节点上的 pod 间的流量
- 主机网络上的 pod 间的流量
- 从集群网络上的 pod 流量到主机网络上的 pod
下图中显示了加密和未加密的流程:
6.6.4.2. 加密协议和 IPsec 模式 复制链接链接已复制到粘贴板!
使用的加密机制是 AES-GCM-16-256。完整性检查值(ICV)为 16 字节。密钥长度为 256 位。
使用的 IPsec 模式是 传输模式,这是通过向原始数据包的 IP 标头添加封装安全 Payload (ESP) 标头来加密端到端通信的模式。OpenShift Container Platform 目前不支持 pod 到 pod 通信的 IPsec Tunnel 模式。
6.6.4.3. 安全证书生成和轮转 复制链接链接已复制到粘贴板!
Cluster Network Operator(CNO)生成自签名 X.509 证书颁发机构(CA),该颁发机构(CA)用于加密。来自每个节点的证书签名请求(CSR)由 CNO 自动实现。
CA 的有效期为 10 年。独立节点证书的有效期为 5 年,并在 4 年半后自动轮转。
6.6.5. 外部流量的 IPsec 加密 复制链接链接已复制到粘贴板!
OpenShift Container Platform 支持使用 IPsec 来加密用于外部主机的流量,确保传输过程中数据的保密性和完整性。此功能依赖于您必须提供的 X.509 证书。
6.6.5.1. 支持的平台 复制链接链接已复制到粘贴板!
在以下平台上支持此功能:
- 裸机
- Google Cloud
- Red Hat OpenStack Platform(RHOSP)
- VMware vSphere
如果您有 Red Hat Enterprise Linux (RHEL)计算节点,则它们不支持对外部流量的 IPsec 加密。
如果您的集群在 Red Hat OpenShift Container Platform 中使用托管的 control plane,则不支持将流量加密到外部主机的 IPsec。
6.6.5.2. 限制: 复制链接链接已复制到粘贴板!
确保观察到以下限制:
- 在为外部流量配置 IPsec 时,NMState Operator 目前不支持 IPv6 配置。
-
提供的证书捆绑包中的证书通用名称(CN)不能以
ovs_前缀开头,因为这个命名可以与每个节点的网络安全服务(NSS)数据库中的 pod 到 pod 的 IPsec CN 名称冲突。
6.6.6. 启用 IPsec 加密 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在集群和外部 IPsec 端点之间,启用 pod 到 pod IPsec 加密和 IPsec 加密。
您可以使用以下模式之一配置 IPsec:
-
Full:pod 到 pod 和外部流量的加密 -
External:对外部流量进行加密
如果以 Full 模式配置 IPsec,还必须完成"为外部流量配置 IPsec 加密"过程。
先决条件
-
安装 OpenShift CLI (
oc) 。 -
以具有
cluster-admin权限的用户身份登录集群。 -
您已将集群 MTU 的大小减少为
46字节,以允许 IPsec ESP 标头的开销。
流程
要启用 IPsec 加密,请输入以下命令:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 完成"为外部流量配置 IPsec 加密"流程,使用 IPsec 加密外部流量。
验证
要查找 OVN-Kubernetes data plane pod 的名称,请输入以下命令:
oc get pods -n openshift-ovn-kubernetes -l=app=ovnkube-node
$ oc get pods -n openshift-ovn-kubernetes -l=app=ovnkube-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证您在集群中启用了 IPsec:
注意作为集群管理员,当您以
Full模式配置 IPsec 时,您可以验证您是否在集群中的 pod 之间启用了 IPsec。此步骤不会验证 IPsec 是否在集群和外部主机间工作。oc -n openshift-ovn-kubernetes rsh ovnkube-node-<XXXXX> ovn-nbctl --no-leader-only get nb_global . ipsec
$ oc -n openshift-ovn-kubernetes rsh ovnkube-node-<XXXXX> ovn-nbctl --no-leader-only get nb_global . ipsec1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中: &
lt;XXXXX> 指定上一步中 pod 的随机字符序列。命令的成功输出显示状态为
true。
6.6.7. 为外部流量配置 IPsec 加密 复制链接链接已复制到粘贴板!
作为集群管理员,要使用 IPsec 加密外部流量,您必须为网络基础架构配置 IPsec,包括提供 PKCS#12 证书。因为这个步骤使用 Butane 创建机器配置,所以您必须安装 butane 工具。
应用机器配置后,Machine Config Operator (MCO)会重启集群中的受影响节点以推出新机器配置。
先决条件
-
安装 OpenShift CLI (
oc) 。 -
您已在本地计算机上安装了
butane工具。 - 在集群中安装了 NMState Operator。
-
以具有
cluster-admin权限的用户身份登录集群。 - 您已为 IPsec 端点有一个现有的 PKCSxdg 证书,并以 Privacy Enhanced Mail (PEM)格式使用 CA 证书。
-
您在集群中的
Full或External模式中启用了 IPsec。 -
您必须在 OVN-Kubernetes 网络插件的
ovnKubernetesConfig.gatewayConfig规格中将routingViaHost参数设置为true。
流程
使用 NMState Operator 节点网络配置策略创建 IPsec 配置。如需更多信息,请参阅使用 nmstatectl 配置基于 IPsec 的 VPN 连接。
要识别 IPsec 端点的集群节点的 IP 地址,请输入以下命令:
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建名为
ipsec-config.yaml的文件,该文件具有 NMState Operator 的节点网络配置策略,如下例所示。有关NodeNetworkConfigurationPolicy对象的概述,请参阅 Kubernetes NMState 项目。NMState IPsec 传输配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
kubernetes.io/hostname- 指定要将策略应用到的主机名。此主机充当 IPsec 配置中的左侧主机。
name- 指定要在主机上创建的接口名称。
left-
指定在集群端终止 IPsec 隧道的集群节点的主机名。名称必须与您提供的 PKCS resources 证书中的 SAN
[Subject Alternate Name]匹配。 right-
指定外部主机名,如
host.example.com。名称应与您提供的 PKCS#12 证书中的 SAN[Subject Alternate Name]匹配。 rightsubnet指定外部主机的 IP 地址,如
10.1.2.3/32。NMState IPsec 隧道配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
要配置 IPsec 接口,请输入以下命令:
oc create -f ipsec-config.yaml
$ oc create -f ipsec-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
授予以下证书文件添加到每个主机上的网络安全服务(NSS)数据库中。这些文件在下一步中作为 Butane 配置的一部分导入。
-
left_server.p12:IPsec 端点的证书捆绑包 -
ca.pem:您使用签名证书的证书颁发机构
-
- 创建机器配置以将证书添加到集群中。
从挂载的 secret 文件中读取密码:
password=$(cat run/secrets/<left_server_password>)
$ password=$(cat run/secrets/<left_server_password>)Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
left_server_password:: 包含密码的文件名称。此文件存在于挂载的 secret 中。
-
使用
pk12util工具,它预先打包了 Red Hat Enterprise Linux (RHEL),输入以下命令指定保护PKCSedServiceSet 文件的密码。确保将 <password> 值替换为您的密码。pk12util -W "<password>" -i /etc/pki/certs/left_server.p12 -d /var/lib/ipsec/nss/
$ pk12util -W "<password>" -i /etc/pki/certs/left_server.p12 -d /var/lib/ipsec/nss/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要为 control plane 和计算节点创建 Butane 配置文件,请输入以下命令:
注意您在配置文件中指定的 Butane 版本应与 OpenShift Container Platform 版本匹配,并且始终以
0结尾。例如:4.16.0。有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要将上一步中创建的 Butane 文件转换为机器配置,请输入以下命令:
for role in master worker; do butane -d . 99-ipsec-${role}-endpoint-config.bu -o ./99-ipsec-$role-endpoint-config.yaml done$ for role in master worker; do butane -d . 99-ipsec-${role}-endpoint-config.bu -o ./99-ipsec-$role-endpoint-config.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要将机器配置应用到集群,请输入以下命令:
for role in master worker; do oc apply -f 99-ipsec-${role}-endpoint-config.yaml done$ for role in master worker; do oc apply -f 99-ipsec-${role}-endpoint-config.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要当 Machine Config Operator (MCO) 更新每个机器配置池中的机器时,它会逐一重启每个节点。在外部 IPsec 连接可用前,您必须等待所有节点更新。
验证
输入以下命令检查机器配置池状态:
oc get mcp
$ oc get mcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功更新的节点具有以下状态:
UPDATED=true、UPDATING=false、DEGRADED=false。注意默认情况下,MCO 会一次在一个池中更新一个机器,从而导致迁移总时间随着集群大小的增加而增加。
要确认 IPsec 机器配置已被成功推出,请输入以下命令:
确认创建 IPsec 机器配置:
oc get mc | grep ipsec
$ oc get mc | grep ipsecCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
80-ipsec-master-extensions 3.2.0 6d15h 80-ipsec-worker-extensions 3.2.0 6d15h
80-ipsec-master-extensions 3.2.0 6d15h 80-ipsec-worker-extensions 3.2.0 6d15hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确认已将 IPsec 扩展应用到 control plane 节点:
oc get mcp master -o yaml | grep 80-ipsec-master-extensions -c
$ oc get mcp master -o yaml | grep 80-ipsec-master-extensions -cCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确认计算节点的 IPsec 扩展的应用程序。示例输出将显示
2。oc get mcp worker -o yaml | grep 80-ipsec-worker-extensions -c
$ oc get mcp worker -o yaml | grep 80-ipsec-worker-extensions -cCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6.9. 为外部 IPsec 端点禁用 IPsec 加密 复制链接链接已复制到粘贴板!
作为集群管理员,您可以删除外部主机的现有 IPsec 隧道。
先决条件
-
安装 OpenShift CLI (
oc) 。 -
以具有
cluster-admin权限的用户身份登录集群。 -
您在集群中的
Full或External模式中启用了 IPsec。
流程
使用以下 YAML 创建名为
remove-ipsec-tunnel.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name- 指定节点网络配置策略的名称。
node_name- 指定您要删除的 IPsec 隧道的节点名称。
tunnel_name- 指定现有 IPsec 隧道的接口名称。
要删除 IPsec 隧道,请输入以下命令:
oc apply -f remove-ipsec-tunnel.yaml
$ oc apply -f remove-ipsec-tunnel.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6.10. 禁用 IPsec 加密 复制链接链接已复制到粘贴板!
作为集群管理员,您可以禁用 IPsec 加密。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
要禁用 IPsec 加密,请输入以下命令:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
可选:您可以将集群 MTU 的大小增加
46个字节,因为 IP 数据包中不再有 IPsec ESP 标头的开销。
6.7. 零信任网络 复制链接链接已复制到粘贴板!
零信任(Zero trust)一个设计安全基础架构的方法,它基于内部的环境,其中的每个交流行为都从一个不受信任的状态开始。这与传统的架构不同。传统架构可能会根据交流是否是在防火墙内发起的来确定其信任性。更具体地说,零信任会尝试缩小安全基础架构中的漏洞(依赖隐式信任模型和一次性身份验证)。
OpenShift Container Platform 可以为平台上运行的容器添加一些零信任网络功能,而无需更改容器或它们中运行的软件。红帽提供的几种产品进一步增加了容器的零信任网络功能。如果您能够更改容器中运行的软件,则还有红帽支持的其他项目,可以添加进一步的功能。
探索零信任网络的以下目标功能。
6.7.1. 信任的根 复制链接链接已复制到粘贴板!
公共证书和私钥对于零信任网络至关重要。它们用来识别另一个组件、验证和保护流量的安全组件。证书由其他证书签名,存在到根证书颁发机构 (CA) 的信任链。参与网络的所有内容需要最终具有 root CA 的公钥,以便它可以验证信任链。对于面向公共的项,通常是全局已知的根 CA,其密钥与操作系统、Web 浏览器等一起分发。但是,如果私有 CA 的证书被分发到所有方,则可以针对一个集群或一个机构运行私有 CA。
利用:
- OpenShift Container Platform:OpenShift 在安装时会创建一个集群 CA,用于保护集群资源。但是,OpenShift Container Platform 也可以在集群中为服务证书创建和签署证书,并在请求时可以将集群 CA 捆绑包注入 pod。由 OpenShift Container Platform 创建并签名的服务证书具有 26 个月的生存时间 (TTL),并在 13 个月内自动轮转。如有必要,也可以手动轮转它们。
- OpenShift cert-manager Operator :cert-manager 允许您请求由外部信任根签名的密钥。有许多可配置的签发者可以与外部签发者集成,以及与委派的签名证书一起运行的方法。cert-manager API 可供零信任网络中的其他软件使用,以请求必要的证书(如 Red Hat OpenShift Service Mesh),或者可由客户软件直接使用。
6.7.2. 流量身份验证和加密 复制链接链接已复制到粘贴板!
确保网络上的所有流量都加密,并且端点是可识别的。例如,Mutual TLS 或 mTLS,这是 mutual 身份验证的方法。
利用:
- OpenShift Container Platform:使用透明 pod 到 pod IPsec,流量的源和目的地可以通过 IP 地址来标识。这可以实现对出口流量使用 IPsec 加密。通过使用 egress IP 功能,流量的源 IP 地址可用于识别集群中的流量源。
- Red Hat OpenShift Service Mesh: 提供强大的 mTLS 功能,这些功能可以透明地增加离开 pod 的流量以提供身份验证和加密。
- OpenShift cert-manager Operator:使用自定义资源定义 (CRD) 请求可挂载用于 SSL/TLS 协议的证书。
6.7.3. 身份识别和验证 复制链接链接已复制到粘贴板!
在使用 CA 最小化证书后,您可以通过验证连接端的另一端的连接身份验证一个用户或客户端机器来建立信任关系。这还需要管理证书生命周期,以便在被破坏时限制使用。
利用:
- OpenShift Container Platform:集群签名的服务证书,以确保客户端与可信端点通信。这要求服务使用 SSL/TLS,并且客户端使用集群 CA。客户端身份必须使用某种其他方法提供。
- Red Hat Single Sign-On:提供与企业用户目录或第三方身份提供程序的请求身份验证集成。
- Red Hat OpenShift Service Mesh: 将连接透明升级到 mTLS、自动轮转、自定义证书过期以及请求使用 JSON Web 令牌 (JWT) 的身份验证。
- OpenShift cert-manager Operator :创建和管理证书,供应用程序使用。证书可以由 CRD 控制并挂载为 secret,也可以更改应用程序以直接与 cert-manager API 交互。
6.7.4. 服务间的授权 复制链接链接已复制到粘贴板!
务必要根据请求者的身份控制对服务的访问。这由平台完成,不需要每个应用程序来实现它。这样可以更好地审核和检查策略。
利用:
-
OpenShift Container Platform:可以使用 Kubernetes
NetworkPolicy和AdminNetworkPolicy对象在平台的网络层中强制实施隔离。 - Red Hat OpenShift Service Mesh: 使用标准 Istio 对象 对流量的复杂 L4 和 L7 控制,并使用 mTLS 识别流量源和目标,然后根据该信息应用策略。
6.7.5. 事务级验证 复制链接链接已复制到粘贴板!
除了识别和验证连接的功能外,控制单个事务的访问也很有用。这可包括源、可观察性和语义验证的速率限制。
利用:
- Red Hat OpenShift Service Mesh: 执行对请求的 L7 检查,拒绝 HTTP 请求、事务级 可观察性和报告。Service Mesh 还可使用 JWT 提供基于请求的身份验证。
6.7.6. 风险评估 复制链接链接已复制到粘贴板!
随着集群中的安全策略数量增加,策略允许和拒绝的视觉化变得越来越重要。这些工具可让您更轻松地创建、视觉化和管理集群安全策略。
利用:
-
Red Hat OpenShift Service Mesh: 使用 OpenShift Web 控制台创建和视觉化 Kubernetes
NetworkPolicy和AdminNetworkPolicy,以及 OpenShift NetworkingEgressFirewall对象。 - Red Hat Advanced Cluster Security for Kubernetes :对象的高级视觉化。
6.7.7. 站点范围内的策略实施和分发 复制链接链接已复制到粘贴板!
在集群中部署应用程序后,管理组成安全规则的所有对象就变得困难。务必要应用站点范围的策略,并审核部署的对象是否符合策略。这应该允许将某些权限委派给定义的绑定内的用户和集群管理员,并应允许例外策略。
利用:
6.7.8. 持续的可观察性,以及重新检查评估 复制链接链接已复制到粘贴板!
运行的集群后,您希望能够观察流量,并使用定义的规则验证流量是否被端口。这对入侵检测、共识非常重要,有助于操作负载管理。
利用:
- Network Observability Operator:允许检查、监控和警报到集群中的 pod 和节点的网络连接。
- Red Hat Advanced Cluster Management (RHACM) for Kubernetes: 监控、收集和评估系统级事件,如进程执行、网络连接和流以及特权升级。它可以决定集群的基线,然后检测异常活动并提醒您。
- Red Hat OpenShift Service Mesh : 可以监控进入和离开 pod 的流量。
- Red Hat OpenShift distributed Tracing Platform: 对于适用的应用程序,您可以看到与一个特定操作相关联的所有流量,因为它被分成子请求到微服务。这可让您识别分布式应用程序中的瓶颈。
6.7.9. 端点安全性 复制链接链接已复制到粘贴板!
务必要信任在集群中运行服务的软件没有被破坏。例如,您可能需要确保在可信硬件上运行认证的镜像,并有策略只允许基于端点特征或来自端点特征的连接。
利用:
- OpenShift Container Platform:Secureboot 可以确保集群中的节点正在运行可信软件,因此平台本身(包括容器运行时)没有被篡改。您可以将 OpenShift Container Platform 配置为仅运行 由特定签名签名的镜像。
- Red Hat Trusted Artifact Signer:这可用于可信构建链并生成已签名的容器镜像。
6.7.10. 在集群外扩展信任 复制链接链接已复制到粘贴板!
您可能希望通过允许集群到子域的 mint CA 来在集群外扩展信任。或者,您可能希望 attest 到集群中的工作负载身份到远程端点。
利用:
- OpenShift cert-manager Operator:您可以使用 cert-manager 管理委派的 CA,以便可以在不同集群之间或通过您的机构分发信任。
- Red Hat OpenShift Service Mesh: 可以使用 SPIFFE 为在远程或本地集群中运行的端点提供远程测试工作负载。
第 7 章 为手动 DNS Management 配置 Ingress Controller 复制链接链接已复制到粘贴板!
作为集群管理员,在创建 Ingress Controller 时,Operator 会自动管理 DNS 记录。当所需的 DNS 区域与集群 DNS 区域不同或 DNS 区域被托管在云供应商时,这有一些限制。
作为集群管理员,您可以将 Ingress Controller 配置为停止自动 DNS 管理并启动手动 DNS 管理。将 dnsManagementPolicy 设置为指定应自动或手动管理的时间。
当您将 Ingress Controller 从 Managed 改为 Unmanaged DNS 管理策略时,Operator 不会清理在云中置备的以前的通配符 DNS 记录。当您将 Ingress Controller 从 Unmanaged 改为 Managed DNS 管理策略时,Operator 会尝试在云供应商上创建 DNS 记录(如果不存在),或更新 DNS 记录(如果已存在)。
当您将 dnsManagementPolicy 设置为 unmanaged 时,您必须手动管理云供应商上的通配符 DNS 记录的生命周期。
7.1. Managed DNS 管理策略 复制链接链接已复制到粘贴板!
Ingress Controller 的 Managed DNS 管理策略可确保云供应商上通配符 DNS 记录的生命周期由 Operator 自动管理。
7.2. Unmanaged DNS 管理策略 复制链接链接已复制到粘贴板!
Ingress Controller 的 Unmanaged DNS 管理策略可确保云供应商上通配符 DNS 记录的生命周期不会自动管理,而是由集群管理员负责。
在 AWS 云平台中,如果 Ingress Controller 上的域与 dnsConfig.Spec.BaseDomain 不匹配,则 DNS 管理策略会自动设置为 Unmanaged。
7.3. 使用 Unmanaged DNS 管理策略创建自定义 Ingress Controller 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 Unmanaged DNS 管理策略创建新的自定义 Ingress Controller。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建名为
sample-ingress.yaml的自定义资源 (CR) 文件,包含以下内容:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 保存文件以使改变生效。
oc apply -f <name>.yaml
oc apply -f <name>.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. 修改现有 Ingress Controller 复制链接链接已复制到粘贴板!
作为集群管理员,您可以修改现有 Ingress Controller 以手动管理 DNS 记录生命周期。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
修改所选
IngressController来设置dnsManagementPolicy:SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}")SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 可选:您可以删除云供应商中的关联的 DNS 记录。
第 8 章 验证到端点的连接 复制链接链接已复制到粘贴板!
Cluster Network Operator(CNO)运行一个控制器(连接检查控制器),用于在集群的资源间执行连接健康检查。通过查看健康检查的结果,您可以诊断连接问题或解决网络连接问题,将其作为您要调查的问题的原因。
8.1. 执行的连接健康检查 复制链接链接已复制到粘贴板!
要验证集群资源是否可以访问,请向以下集群 API 服务的每个服务都有一个 TCP 连接:
- Kubernetes API 服务器服务
- Kubernetes API 服务器端点
- OpenShift API 服务器服务
- OpenShift API 服务器端点
- 负载均衡器
要验证服务和服务端点是否可在集群中的每个节点上访问,请对以下每个目标都进行 TCP 连接:
- 健康检查目标服务
- 健康检查目标端点
8.2. 连接健康检查实现 复制链接链接已复制到粘贴板!
在集群中,连接检查控制器或编配连接验证检查。连接测试的结果存储在 openshift-network-diagnostics 命名空间中的 PodNetworkConnectivity 对象中。连接测试会每分钟以并行方式执行。
Cluster Network Operator(CNO)将几个资源部署到集群,以发送和接收连接性健康检查:
- 健康检查源
-
此程序部署在一个由
Deployment对象管理的单个 pod 副本集中。程序会消耗PodNetworkConnectivity对象,并连接到每个对象中指定的spec.targetEndpoint。 - 健康检查目标
- pod 作为集群中每个节点上的守护进程集的一部分部署。pod 侦听入站健康检查。在每个节点上存在这个 pod 可以测试到每个节点的连接。
您可以使用节点选择器配置在其上运行网络连接源和目标的节点。另外,您可以为源和目标 pod 指定允许的容限。配置在 config.openshift.io/v1 API 组中的 Network API 的单例 cluster 自定义资源中定义。
Pod 调度在更新了配置后发生。因此,您必须在更新配置前应用要在选择器中使用的节点标签。更新网络连接后应用的标签将忽略 pod 放置。
请参考以下 YAML 中的默认配置:
连接源和目标 pod 的默认配置
- 1 1
- 指定网络诊断配置。如果没有指定值,或者指定了空对象,并在名为
cluster的network.operator.openshift.io自定义资源中设置spec.disableNetworkDiagnostics=true,则会禁用网络诊断。如果设置,这个值会覆盖spec.disableNetworkDiagnostics=true。 - 2
- 指定诊断模式。该值可以是空字符串、
All或Disabled。空字符串等同于指定All。 - 3
- 可选:指定连接检查源 pod 的选择器。您可以使用
nodeSelector和tolerations字段来进一步指定sourceNodepod。对于源和目标 pod,它们都是可选的。您可以省略它们,同时使用它们,或者只使用其中一个。 - 4
- 可选:指定连接检查目标 pod 的选择器。您可以使用
nodeSelector和tolerations字段来进一步指定targetNodepod。对于源和目标 pod,它们都是可选的。您可以省略它们,同时使用它们,或者只使用其中一个。
8.3. 配置 pod 连接检查放置 复制链接链接已复制到粘贴板!
作为集群管理员,您可以通过修改名为 cluster 的 network.config.openshift.io 对象来配置运行连接 pod 的节点。
先决条件
-
安装 OpenShift CLI (
oc) 。
流程
输入以下命令编辑连接检查配置:
oc edit network.config.openshift.io cluster
$ oc edit network.config.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
在文本编辑器中,更新
networkDiagnostics小节,以指定您要用于源和目标 pod 的节点选择器。 - 保存更改并退出文本编辑器。
验证
- 输入以下命令验证源和目标 pod 是否在预期的节点上运行:
oc get pods -n openshift-network-diagnostics -o wide
$ oc get pods -n openshift-network-diagnostics -o wide
输出示例
8.4. PodNetworkConnectivityCheck 对象字段 复制链接链接已复制到粘贴板!
PodNetworkConnectivityCheck 对象字段在下表中描述。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
对象的名称,其格式如下:
|
|
|
|
与对象关联的命名空间。此值始终为 |
|
|
|
连接检查来源于的 pod 的名称,如 |
|
|
|
连接检查的目标,如 |
|
|
| 要使用的 TLS 证书配置。 |
|
|
| 使用的 TLS 证书的名称(若有)。默认值为空字符串。 |
|
|
| 代表连接测试条件和最近连接发生和失败的日志的对象。 |
|
|
| 连接检查以及任何之前的状态的最新状态。 |
|
|
| 连接测试日志不会失败。 |
|
|
| 涵盖任何中断的时间连接测试日志。 |
|
|
| 成功尝试的连接测试日志。 |
下表描述了 status.conditions 阵列中对象的字段:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 连接条件从一个状态转换到另一个状态的时间。 |
|
|
| 有关最后一次转换的详情(人类可读的格式)。 |
|
|
| 有关最后一次转换的详情(机器可读的格式)。 |
|
|
| 条件的状态。 |
|
|
| 条件的类型。 |
下表描述了 status.conditions 阵列中对象的字段:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 连接失败时的时间戳。 |
|
|
| 连接日志条目,包括与成功关闭相关的日志条目。 |
|
|
| 以人类可读格式显示停机详情概述。 |
|
|
| 第一次检测到连接失败时的时间戳。 |
|
|
| 连接日志条目,包括原始失败。 |
8.4.1. 连接日志字段 复制链接链接已复制到粘贴板!
下表中描述了连接日志条目的字段。该对象用于以下字段:
-
status.failures[] -
status.successes[] -
status.outages[].startLogs[] -
status.outages[].endLogs[]
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 记录操作的持续时间。 |
|
|
| 以人类可读格式提供的状态信息。 |
|
|
|
以可读格式提供状态的原因。这个值是 |
|
|
| 指明日志条目是否成功或失败。 |
|
|
| 连接检查的开始时间。 |
8.5. 验证端点的网络连接 复制链接链接已复制到粘贴板!
作为集群管理员,您可以验证端点的连接,如 API 服务器、负载均衡器、服务或 pod,并验证是否启用了网络诊断。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin角色的用户访问集群。
流程
输入以下命令确认启用了网络诊断:
oc get network.config.openshift.io cluster -o yaml
$ oc get network.config.openshift.io cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令列出当前的
PodNetworkConnectivityCheck对象:oc get podnetworkconnectivitycheck -n openshift-network-diagnostics
$ oc get podnetworkconnectivitycheck -n openshift-network-diagnosticsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 查看连接测试日志:
- 在上一命令的输出中,标识您要查看连接日志的端点。
输入以下命令来查看对象:
oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yaml
$ oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这里的
<name>指定PodNetworkConnectivityCheck对象的名称。输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 9 章 更改集群网络的 MTU 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在集群安装后更改集群网络的最大传输单元(MTU)。这一更改具有破坏性,因为必须重启集群节点才能完成 MTU 更改。
您只能为使用 OVN-Kubernetes 插件或 OpenShift SDN 网络插件的集群更改 MTU。
9.1. 关于集群 MTU 复制链接链接已复制到粘贴板!
在安装过程中,集群网络 MTU 根据集群节点的主网络接口 MTU 自动设置。您通常不需要覆盖检测到的 MTU。
您可能想要根据以下原因更改集群网络的 MTU:
- 集群安装过程中检测到的 MTU 不正确。
- 集群基础架构现在需要不同的 MTU,如添加需要不同 MTU 的节点来获得最佳性能
只有 OVN-Kubernetes 网络插件支持更改 MTU 值。
9.1.1. 服务中断注意事项 复制链接链接已复制到粘贴板!
当您为集群启动最大传输单元(MTU)更改时,以下效果可能会影响服务可用性:
- 至少需要两个滚动重启才能完成迁移到新的 MTU。在此过程中,一些节点在重启时不可用。
- 部署到集群的特定应用程序带有较短的超时间隔,超过绝对 TCP 超时间隔可能会在 MTU 更改过程中造成中断。
9.1.2. MTU 值选择 复制链接链接已复制到粘贴板!
在规划最大传输单元(MTU)迁移时,需要考虑两个相关但不同的 MTU 值。
- Hardware MTU :此 MTU 值根据您的网络基础架构的具体设置。
-
Cluster network MTU :此 MTU 值始终小于您的硬件 MTU,以考虑集群网络覆盖开销。具体开销由您的网络插件决定。对于 OVN-Kubernetes,开销为
100字节。对于 OpenShift SDN,开销为50字节。
如果您的集群为不同的节点需要不同的 MTU 值,则必须从集群中任何节点使用的最低 MTU 值中减去网络插件的开销值。例如,如果集群中的某些节点的 MTU 为 9001,而某些节点的 MTU 为 1500,则必须将此值设置为 1400。
为了避免选择节点无法接受的 MTU 值,请使用 ip -d link 命令验证网络接口接受的最大 MTU 值 (maxmtu)。
9.1.3. 迁移过程如何工作 复制链接链接已复制到粘贴板!
下表对迁移过程进行了概述,它分为操作中的用户发起的步骤,以及在响应过程中迁移过程要执行的操作。
| 用户发起的步骤 | OpenShift Container Platform 活动 |
|---|---|
| 在 Cluster Network Operator 配置中设置以下值:
| Cluster Network Operator(CNO) :确认每个字段都设置为有效的值。
如果提供的值有效,CNO 会生成一个新的临时配置,它将集群网络集的 MTU 设置为 Machine Config Operator(MCO) :执行集群中每个节点的滚动重启。 |
| 重新配置集群中节点的主网络接口 MTU。您可以使用以下任一方法完成此操作:
| N/A |
|
在网络插件的 CNO 配置中设置 | Machine Config Operator(MCO) :使用新的 MTU 配置执行集群中每个节点的滚动重启。 |
9.2. 更改集群网络 MTU 复制链接链接已复制到粘贴板!
作为集群管理员,您可以增加或减少集群的最大传输单元 (MTU)。
您无法在 MTU 迁移过程中回滚节点的 MTU 值,但您可以在 MTU 迁移过程完成后回滚。
当 MTU 更新推出时,集群中的迁移具有破坏性且节点可能会临时不可用。
以下流程描述了如何使用机器配置、动态主机配置协议(DHCP)或 ISO 镜像更改集群网络 MTU。如果使用 DHCP 或 ISO 方法,则必须在安装集群后保留的配置工件来完成此流程。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin权限的账户访问集群。 已为集群识别目标 MTU。
-
OVN-Kubernetes 网络插件的 MTU 必须设置为比集群中的最低硬件 MTU 值小
100。 -
OpenShift SDN 网络插件的 MTU 必须设置为比集群中的最低硬件 MTU 值小
50。
-
OVN-Kubernetes 网络插件的 MTU 必须设置为比集群中的最低硬件 MTU 值小
- 如果您的节点是物理计算机,请确保集群网络和连接的网络交换机支持巨型帧。
- 如果您的节点是虚拟机 (VM),请确保虚拟机监控程序和连接的网络交换机支持巨型帧。
流程
要获得集群网络的当前 MTU,请输入以下命令:
oc describe network.config cluster
$ oc describe network.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为硬件 MTU 准备配置:
如果您的硬件 MTU 通过 DHCP 指定,请使用以下 dnsmasq 配置更新 DHCP 配置:
dhcp-option-force=26,<mtu>
dhcp-option-force=26,<mtu>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<mtu>- 指定要公告的 DHCP 服务器的硬件 MTU。
- 如果使用 PXE 的内核命令行指定硬件 MTU,请相应地更新该配置。
如果在 NetworkManager 连接配置中指定了硬件 MTU,请完成以下步骤。如果没有使用 DHCP、内核命令行或某种其他方法显式指定网络配置,则此方法是 OpenShift Container Platform 的默认方法。集群节点必须全部使用相同的底层网络配置,才能使以下过程未经修改地工作。
查找主网络接口:
如果使用 OpenShift SDN 网络插件,请输入以下命令:
oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'$ oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<node_name>- 指定集群中的节点的名称。
如果使用 OVN-Kubernetes 网络插件,请输入以下命令:
oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
$ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<node_name>- 指定集群中的节点的名称。
在
<interface>-mtu.conf文件中创建以下 NetworkManager 配置:NetworkManager 连接配置示例
[connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>
[connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<mtu>- 指定新的硬件 MTU 值。
<interface>- 指定主网络接口名称。
创建两个
MachineConfig对象,一个用于 control plane 节点,另一个用于集群中的 worker 节点:在
control-plane-interface.bu文件中创建以下 Butane 配置:注意您在配置文件中指定的 Butane 版本应与 OpenShift Container Platform 版本匹配,并且始终以
0结尾。例如:4.16.0。有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
worker-interface.bu文件中创建以下 Butane 配置:注意您在配置文件中指定的 Butane 版本应与 OpenShift Container Platform 版本匹配,并且始终以
0结尾。例如:4.16.0。有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,从 Butane 配置创建
MachineConfig对象:for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml done$ for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 警告在此流程的稍后明确指示之前,不要应用这些机器配置。应用这些机器配置现在会导致集群的稳定性丢失。
要开始 MTU 迁移,请输入以下命令指定迁移配置。Machine Config Operator 在集群中执行节点的滚动重启,以准备 MTU 更改。
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<overlay_from>- 指定当前的集群网络 MTU 值。
<overlay_to>-
指定集群网络的目标 MTU。这个值相对于
<machine_to>的值设置。对于 OVN-Kubernetes,这个值必须比<machine_to>的值小100。对于 OpenShift SDN,这个值必须比<machine_to>的值小50。 <machine_to>- 指定底层主机网络上的主网络接口的 MTU。
增加集群 MTU 的示例
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当 Machine Config Operator 更新每个机器配置池中的机器时,它会逐一重启每个节点。您必须等到所有节点都已更新。输入以下命令检查机器配置池状态:
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功更新的节点具有以下状态:
UPDATED=true、UPDATING=false、DEGRADED=false。注意默认情况下,Machine Config Operator 一次更新每个池中的一个机器,从而导致迁移总时间随着集群大小而增加。
确认主机上新机器配置的状态:
要列出机器配置状态和应用的机器配置名称,请输入以下命令:
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证以下语句是否正确:
-
machineconfiguration.openshift.io/state字段的值为Done。 -
machineconfiguration.openshift.io/currentConfig字段的值等于machineconfiguration.openshift.io/desiredConfig字段的值。
-
要确认机器配置正确,请输入以下命令:
oc get machineconfig <config_name> -o yaml | grep ExecStart
$ oc get machineconfig <config_name> -o yaml | grep ExecStartCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这里的
<config_name>是machineconfiguration.openshift.io/currentConfig字段中机器配置的名称。机器配置必须包括以下对 systemd 配置的更新:
ExecStart=/usr/local/bin/mtu-migration.sh
ExecStart=/usr/local/bin/mtu-migration.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow
更新底层网络接口 MTU 值:
如果您要使用 NetworkManager 连接配置指定新 MTU,请输入以下命令。MachineConfig Operator 会自动执行集群中节点的滚动重启。
for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml done$ for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 如果您要使用 DHCP 服务器选项或内核命令行和 PXE 指定新 MTU,请对基础架构进行必要的更改。
当 Machine Config Operator 更新每个机器配置池中的机器时,它会逐一重启每个节点。您必须等到所有节点都已更新。输入以下命令检查机器配置池状态:
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功更新的节点具有以下状态:
UPDATED=true、UPDATING=false、DEGRADED=false。注意默认情况下,Machine Config Operator 一次更新每个池中的一个机器,从而导致迁移总时间随着集群大小而增加。
确认主机上新机器配置的状态:
要列出机器配置状态和应用的机器配置名称,请输入以下命令:
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证以下语句是否正确:
-
machineconfiguration.openshift.io/state字段的值为Done。 -
machineconfiguration.openshift.io/currentConfig字段的值等于machineconfiguration.openshift.io/desiredConfig字段的值。
-
要确认机器配置正确,请输入以下命令:
oc get machineconfig <config_name> -o yaml | grep path:
$ oc get machineconfig <config_name> -o yaml | grep path:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这里的
<config_name>是machineconfiguration.openshift.io/currentConfig字段中机器配置的名称。如果机器配置被成功部署,则前面的输出会包含
/etc/NetworkManager/conf.d/99-<interface>-mtu.conf文件路径和ExecStart=/usr/local/bin/mtu-migration.sh行。
完成插件的 MTU 迁移。在这两个示例命令中,
<mtu>指定了您使用<overlay_to>指定的新集群网络 MTU。要完成 MTU 迁移,请为 OVN-Kubernetes 网络插件输入以下命令:
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要完成 MTU 迁移,请为 OpenShift SDN 网络插件输入以下命令:
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
最终调整 MTU 迁移后,每个机器配置池节点都会逐个重启一个。您必须等到所有节点都已更新。输入以下命令检查机器配置池状态:
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功更新的节点具有以下状态:
UPDATED=true、UPDATING=false、DEGRADED=false。
验证
要获得集群网络的当前 MTU,请输入以下命令:
oc describe network.config cluster
$ oc describe network.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 获取节点的主网络接口的当前 MTU:
要列出集群中的节点,请输入以下命令:
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要获取节点上主网络接口的当前 MTU 设置,请输入以下命令:
oc debug node/<node> -- chroot /host ip address show <interface>
$ oc debug node/<node> -- chroot /host ip address show <interface>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<node>- 指定上一步中的输出节点。
<interface>- 指定节点的主网络接口名称。
输出示例
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.1. 检查当前集群 MTU 值 复制链接链接已复制到粘贴板!
使用以下步骤获取集群网络的当前最大传输单元(MTU)。
流程
要获得集群网络的当前 MTU,请输入以下命令:
oc describe network.config cluster
$ oc describe network.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.2. 准备硬件 MTU 配置 复制链接链接已复制到粘贴板!
有很多方法为集群节点配置硬件最大传输单元(MTU)。以下示例显示最常见的方法。验证基础架构 MTU 的正确性。选择在集群节点中配置硬件 MTU 的首选方法。
流程
为硬件 MTU 准备配置:
如果您的硬件 MTU 通过 DHCP 指定,请使用以下 dnsmasq 配置更新 DHCP 配置:
dhcp-option-force=26,<mtu>
dhcp-option-force=26,<mtu>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<mtu>- 指定要公告的 DHCP 服务器的硬件 MTU。
- 如果使用 PXE 的内核命令行指定硬件 MTU,请相应地更新该配置。
如果在 NetworkManager 连接配置中指定了硬件 MTU,请完成以下步骤。如果没有使用 DHCP、内核命令行或某种其他方法显式指定网络配置,则此方法是 OpenShift Container Platform 的默认方法。集群节点必须全部使用相同的底层网络配置,才能使以下过程未经修改地工作。
输入以下命令查找主网络接口:
oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
$ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<node_name>- 指定集群中的节点的名称。
在 <
interface>-mtu.conf文件中创建以下NetworkManager配置:[connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>
[connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<interface>- 指定主网络接口名称。
<mtu>- 指定新的硬件 MTU 值。
9.2.3. 创建 MachineConfig 对象 复制链接链接已复制到粘贴板!
使用以下步骤创建 MachineConfig 对象。
流程
创建两个
MachineConfig对象,一个用于 control plane 节点,另一个用于集群中的 worker 节点:在
control-plane-interface.bu文件中创建以下 Butane 配置:注意您在配置文件中指定的 Butane 版本应与 OpenShift Container Platform 版本匹配,并且始终以
0结尾。例如:4.16.0。有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
worker-interface.bu文件中创建以下 Butane 配置:注意您在配置文件中指定的 Butane 版本应与 OpenShift Container Platform 版本匹配,并且始终以
0结尾。例如:4.16.0。有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令,从 Butane 配置创建
MachineConfig对象:for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml done$ for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 警告在此流程的稍后明确指示之前,不要应用这些机器配置。应用这些机器配置现在会导致集群的稳定性丢失。
9.2.4. 开始 MTU 迁移 复制链接链接已复制到粘贴板!
使用以下步骤启动 MTU 迁移。
流程
要开始 MTU 迁移,请输入以下命令指定迁移配置。Machine Config Operator 在集群中执行节点的滚动重启,以准备 MTU 更改。
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<overlay_from>- 指定当前的集群网络 MTU 值。
<overlay_to>-
指定集群网络的目标 MTU。这个值相对于
<machine_to>的值设置。对于 OVN-Kubernetes,这个值必须比<machine_to>的值小100。 <machine_to>- 指定底层主机网络上的主网络接口的 MTU。
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当 Machine Config Operator 更新每个机器配置池中的机器时,Operator 会逐一重启每个节点。您必须等到所有节点都已更新。输入以下命令检查机器配置池状态:
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功更新的节点具有以下状态:
UPDATED=true、UPDATING=false、DEGRADED=false。注意默认情况下,Machine Config Operator 一次更新每个池中的一个机器,从而导致迁移总时间随着集群大小而增加。
9.2.5. 验证机器配置 复制链接链接已复制到粘贴板!
使用以下步骤验证机器配置。
流程
确认主机上新机器配置的状态:
要列出机器配置状态和应用的机器配置名称,请输入以下命令:
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证以下语句是否正确:
-
machineconfiguration.openshift.io/state字段的值为Done。 -
machineconfiguration.openshift.io/currentConfig字段的值等于machineconfiguration.openshift.io/desiredConfig字段的值。
-
要确认机器配置正确,请输入以下命令:
oc get machineconfig <config_name> -o yaml | grep ExecStart
$ oc get machineconfig <config_name> -o yaml | grep ExecStartCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<config_name>-
指定来自
machineconfiguration.openshift.io/currentConfig字段的机器配置名称。
机器配置必须包括以下对 systemd 配置的更新:
ExecStart=/usr/local/bin/mtu-migration.sh
ExecStart=/usr/local/bin/mtu-migration.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.6. 应用新的硬件 MTU 值 复制链接链接已复制到粘贴板!
使用以下步骤应用新的硬件最大传输单元(MTU)值。
流程
更新底层网络接口 MTU 值:
如果您要使用 NetworkManager 连接配置指定新 MTU,请输入以下命令。MachineConfig Operator 会自动执行集群中节点的滚动重启。
for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml done$ for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 如果您要使用 DHCP 服务器选项或内核命令行和 PXE 指定新 MTU,请对基础架构进行必要的更改。
当 Machine Config Operator 更新每个机器配置池中的机器时,Operator 会逐一重启每个节点。您必须等到所有节点都已更新。输入以下命令检查机器配置池状态:
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功更新的节点具有以下状态:
UPDATED=true、UPDATING=false、DEGRADED=false。注意默认情况下,Machine Config Operator 一次更新每个池中的一个机器,从而导致迁移总时间随着集群大小而增加。
确认主机上新机器配置的状态:
要列出机器配置状态和应用的机器配置名称,请输入以下命令:
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证以下语句是否正确:
-
machineconfiguration.openshift.io/state字段的值为Done。 -
machineconfiguration.openshift.io/currentConfig字段的值等于machineconfiguration.openshift.io/desiredConfig字段的值。
-
要确认机器配置正确,请输入以下命令:
oc get machineconfig <config_name> -o yaml | grep path:
$ oc get machineconfig <config_name> -o yaml | grep path:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<config_name>-
指定来自
machineconfiguration.openshift.io/currentConfig字段的机器配置名称。
如果机器配置被成功部署,则前面的输出会包含
/etc/NetworkManager/conf.d/99-<interface>-mtu.conf文件路径和ExecStart=/usr/local/bin/mtu-migration.sh行。
9.2.7. 最终调整 MTU 迁移 复制链接链接已复制到粘贴板!
使用以下步骤完成 MTU 迁移。
流程
要完成 MTU 迁移,请为 OVN-Kubernetes 网络插件输入以下命令:
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<mtu>-
指定您使用
<overlay_to>指定的新集群网络 MTU。
最终调整 MTU 迁移后,每个机器配置池节点都会逐个重启一个。您必须等到所有节点都已更新。输入以下命令检查机器配置池状态:
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功更新的节点具有以下状态:
UPDATED=true、UPDATING=false、DEGRADED=false。
验证
要获得集群网络的当前 MTU,请输入以下命令:
oc describe network.config cluster
$ oc describe network.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 获取节点的主网络接口的当前 MTU:
要列出集群中的节点,请输入以下命令:
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要获取节点上主网络接口的当前 MTU 设置,请输入以下命令:
oc adm node-logs <node> -u ovs-configuration | grep configure-ovs.sh | grep mtu | grep <interface> | head -1
$ oc adm node-logs <node> -u ovs-configuration | grep configure-ovs.sh | grep mtu | grep <interface> | head -1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<node>- 指定上一步中的输出节点。
<interface>- 指定节点的主网络接口名称。
输出示例
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 10 章 配置节点端口服务范围 复制链接链接已复制到粘贴板!
在集群安装过程中,您可以配置节点端口范围来满足集群的要求。在集群安装后,只有集群管理员可以将范围扩展为安装后任务。如果您的集群使用大量节点端口,请考虑根据集群的要求增加可用端口范围。
如果您没有在集群安装过程中设置节点端口范围,则默认范围 30000-32768 应用到您的集群。在这种情况下,您可以在任一端扩展范围,但您必须在新端口范围中保留 30000-32768。
红帽没有在默认的端口范围 30000-32768 之外执行测试。对于默认端口范围以外的范围,请确保测试以验证扩展节点端口范围不会影响您的集群。特别是,请确保存在:
- 不与主机进程已经使用的任何端口重叠
- 没有与已经由使用主机网络配置的 pod 使用的端口重叠
如果您扩展范围和端口分配问题,请创建新集群并为其设置所需的范围。
如果扩展节点端口范围和 OpenShift CLI (oc)会停止工作,因为端口与 OpenShift Container Platform API 服务器冲突,您必须创建新集群。
10.1. 扩展节点端口范围 复制链接链接已复制到粘贴板!
您可以扩展集群的节点端口范围。安装 OpenShift Container Platform 集群后,您无法在当前配置的范围内缩小节点端口范围。
红帽没有在默认的端口范围 30000-32768 之外执行测试。对于默认端口范围以外的范围,请确保测试以验证扩展节点端口范围是否不会影响您的集群。如果您扩展范围和端口分配问题,请创建新集群并为其设置所需的范围。
先决条件
-
已安装 OpenShift CLI (
oc)。 -
以具有
cluster-admin权限的用户身份登录集群。 -
您确保集群基础架构允许访问扩展范围中存在的端口。例如,如果您将节点端口范围扩展到
30000-32900,您的防火墙或数据包过滤配置必须允许包含端口范围30000-32900。
流程
要扩展集群用来管理 pod 流量的
network.config.openshift.io对象中的serviceNodePortRange参数的范围,请输入以下命令:oc patch network.config.openshift.io cluster --type=merge -p \ '{$ oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "<port_range>" } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<port_range>-
指定您扩展的范围,如
30000-32900。
提示您还可以应用以下 YAML 来更新节点端口范围:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
network.config.openshift.io/cluster patched
network.config.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要确认更新的配置处于活跃状态,请输入以下命令。应用更新可能需要几分钟时间。
oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'$ oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
"service-node-port-range":["30000-32900"]
"service-node-port-range":["30000-32900"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 11 章 配置集群网络范围 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在集群安装后扩展集群网络范围。如果额外的节点需要更多 IP 地址,您可能需要扩展集群网络范围。
例如,如果您部署了集群,并将 10.128.0.0/19 指定为集群网络范围,主机前缀为 23,则限制为 16 个节点。您可以通过将集群中的 CIDR 掩码更改为 /14 来扩展到 510 个节点。
在扩展集群网络地址范围时,您的集群必须使用 OVN-Kubernetes 网络插件。不支持其他网络插件。
修改集群网络 IP 地址范围时会有以下限制:
- 指定的 CIDR 掩码大小必须总是小于当前配置的 CIDR 掩码大小,因为您只能向已安装的集群添加更多节点来增加 IP 空间
- 无法修改主机前缀
- 使用覆盖默认网关配置的 Pod 必须在集群网络扩展后重新创建
11.1. 扩展集群网络 IP 地址范围 复制链接链接已复制到粘贴板!
您可以扩展集群网络的 IP 地址范围。由于这个更改需要在集群中推出新的 Operator 配置,所以最多可能需要 30 分钟才能生效。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。 - 确保集群使用 OVN-Kubernetes 网络插件。
流程
要获取集群的集群网络范围和主机前缀,请输入以下命令:
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.clusterNetwork}"$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.clusterNetwork}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
[{"cidr":"10.217.0.0/22","hostPrefix":23}][{"cidr":"10.217.0.0/22","hostPrefix":23}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要扩展集群网络 IP 地址范围,请输入以下命令。使用上一命令输出返回的 CIDR IP 地址范围和主机前缀。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<network>-
指定您在上一步中获取的
cidr字段的网络部分。您无法更改这个值。 <cidr>-
指定网络前缀长度。例如,
14。将此值更改为比上一步中的输出值小的值,以扩展集群网络范围。 <prefix>-
指定集群的当前主机前缀。这个值必须与您在上一步中获取的
hostPrefix字段的值相同。
示例命令
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
network.config.openshift.io/cluster patched
network.config.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要确认配置是活跃的,请输入以下命令。可能需要 30 分钟才能使此更改生效。
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.clusterNetwork}"$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.clusterNetwork}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
[{"cidr":"10.217.0.0/14","hostPrefix":23}][{"cidr":"10.217.0.0/14","hostPrefix":23}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 12 章 配置 IP 故障转移 复制链接链接已复制到粘贴板!
本节论述了为 OpenShift Container Platform 集群上的 pod 和服务配置 IP 故障转移。
IP 故障转移使用 Keepalived 在一组主机上托管一组外部访问的虚拟 IP (VIP) 地址。每个 VIP 地址仅由单个主机提供服务。Keepalived 使用虚拟路由器冗余协议(VRRP)决定在主机集合中使用哪个主机提供 VIP 服务。如果主机不可用,或者 Keepalived 正在监视的服务没有响应,则 VIP 会切换到主机集中的另外一个主机。这意味着只要主机可用,便始终可以提供 VIP 服务。
集合中的每个 VIP 都由从集合中选择的节点提供服务。如果单个节点可用,则会提供 VIP。无法将 VIP 显式分发到节点上,因此可能存在没有 VIP 的节点和其他具有多个 VIP 的节点。如果只有一个节点,则所有 VIP 都在其中。
管理员必须确保所有 VIP 地址都满足以下要求:
- 可在集群外部配置的主机上访问。
- 不用于集群中的任何其他目的。
每个节点上的 keepalived 确定所需服务是否在运行。如果是,则支持 VIP,Keepalived 参与协商来确定哪个节点服务 VIP。对于要参与的节点,服务必须侦听 VIP 上的观察端口,或者必须禁用检查。
集合中的每个 VIP 都可以由不同的节点提供。
IP 故障转移会监控每个 VIP 上的端口,以确定该端口能否在节点上访问。如果端口无法访问,则不会向节点分配 VIP。如果端口设为 0,则会禁止此检查。检查脚本执行所需的测试。
当运行 Keepalived 的节点通过检查脚本时,该节点上的 VIP 可以根据其优先级和当前 master 的优先级以及抢占策略决定进入 master 状态。
集群管理员可以通过 OPENSHIFT_HA_NOTIFY_SCRIPT 变量提供一个脚本,每当节点上的 VIP 的状态发生变化时会调用此脚本。keepalived 在为 VIP 提供服务时为 master 状态;当另一个节点提供 VIP 服务时,状态为 backup;当检查脚本失败时,状态为 fault。每当状态更改时,notify 脚本都会被调用,并显示新的状态。
您可以在 OpenShift Container Platform 上创建 IP 故障转移部署配置。IP 故障转移部署配置指定 VIP 地址的集合,以及服务它们的一组节点。一个集群可以具有多个 IP 故障转移部署配置,各自管理自己的一组唯一的 VIP 地址。IP 故障转移配置中的每个节点运行 IP 故障转移 pod,此 pod 运行 Keepalived。
使用 VIP 访问带有主机网络的 pod 时,应用程序 pod 在运行 IP 故障转移 pod 的所有节点上运行。这可让任何 IP 故障转移节点成为主节点,并在需要时为 VIP 服务。如果应用程序 pod 没有在所有具有 IP 故障转移功能的节点上运行,有些 IP 故障转移节点不会为 VIP 服务,或者某些应用 pod 都不会接收任何流量。对 IP 故障转移和应用容器集使用相同的选择器和复制数,以避免这种不匹配。
在使用 VIP 访问服务时,任何节点都可以位于节点的 IP 故障转移集中,因为无论应用容器集在哪里运行,该服务都可以在所有节点上访问。任何 IP 故障转移节点可以随时变成主节点。服务可以使用外部 IP 和服务端口,或者可以使用 NodePort。设置 NodePort 是一个特权操作。
在服务定义中使用外部 IP 时,VIP 被设置为外部 IP,IP 故障转移监控端口则设为服务端口。在使用节点端口时,该端口在集群的每个节点上打开,服务则从当前服务于 VIP 的任何节点对流量进行负载平衡。在这种情况下,IP 故障转移监控端口在服务定义中设置为 NodePort。
即使一个服务 VIP 具有高可用性,但性能仍会受到影响。keepalived 确保每个 VIP 都由配置中的某个节点提供服务,即使其他节点没有,也可以在同一节点上出现多个 VIP。当 IP 故障转移在同一节点上放置多个 VIP 时,在一组 VIP 间进行外部负载平衡的策略可能会被破解。
当使用 ExternalIP 时,您可以将 IP 故障转移设置为与 ExternalIP 范围相同的 VIP 范围。您还可以禁用监控端口。在这种情况下,所有 VIP 都出现在集群中的同一节点上。任何用户都可以使用 ExternalIP 设置服务并使其高度可用。
集群中最多有 254 个 VIP。
12.1. IP 故障转移环境变量 复制链接链接已复制到粘贴板!
下表包含用于配置 IP 故障转移的变量。
| 变量名称 | default | 描述 |
|---|---|---|
|
|
|
IP 故障转移 pod 会尝试在每个虚拟 IP(VIP)上打开到此端口的 TCP 连接。如果建立连接,则服务将被视为正在运行。如果此端口设为 |
|
|
IP 故障转移用于发送虚拟路由器冗余协议 (VRRP) 流量的接口名称。默认值为
如果您的集群使用 OVN-Kubernetes 网络插件,请将此值设置为 | |
|
|
|
要创建的副本数。这必须与 IP 故障转移部署配置中的 |
|
|
要复制的 IP 地址范围列表。必须提供.例如, | |
|
|
|
用于设置虚拟路由器 ID 的偏移值。使用不同的偏移值可以在同一集群中存在多个 IP 故障转移配置。默认偏移值为 |
|
|
为 VRRP 创建的组数量。如果没有设置,则会为通过 | |
|
| 输入 |
iptables 链的名称,用于自动添加允许 VRRP 流量的 |
|
| 定期运行的脚本的 pod 文件系统中的完整路径名称,以验证应用是否正在运行。 | |
|
|
| 检查脚本运行的期间(以秒为单位)。 |
|
| 当状态发生变化时运行的脚本的 pod 文件系统的完整路径名称。 | |
|
|
|
处理新的具有更高优先级主机的策略。 |
12.2. 在集群中配置 IP 故障切换 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在整个集群中或在其中的一部分节点(由标签选项器定义)中配置 IP 故障转移。您还可以在集群中配置多个 IP 故障转移部署,每个 IP 故障转移部署相互独立。
IP 故障转移部署确保故障转移 pod 在符合限制或使用的标签的每个节点上运行。
此 pod 运行 Keepalived,它可以监控端点,并在第一个节点无法访问服务或端点时使用 Virtual Router Redundancy Protocol(VRRP)从一个节点切换到另一个节点的虚拟 IP(VIP)。
对于生产环境,设置一个选择器(selector),用于选择至少两个节点,并设置与所选节点数量相等的副本。
先决条件
-
以具有
cluster-admin权限的用户身份登录集群。 - 已创建一个 pull secret。
仅限 Red Hat OpenStack Platform (RHOSP):
- 您在目标环境中安装了 RHOSP 客户端 (RHCOS 文档)。
-
您还下载了 RHOSP
openrc.shrc 文件 (RHCOS 文档)。
流程
创建 IP 故障转移服务帐户:
oc create sa ipfailover
$ oc create sa ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为
hostNetwork更新安全性上下文约束(SCC):oc adm policy add-scc-to-user privileged -z ipfailover
$ oc adm policy add-scc-to-user privileged -z ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm policy add-scc-to-user hostnetwork -z ipfailover
$ oc adm policy add-scc-to-user hostnetwork -z ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仅限 Red Hat OpenStack Platform (RHOSP):完成以下步骤,使在 RHOSP 端口上可以访问故障转移 VIP 地址。
使用 RHOSP CLI 在 RHOSP 集群的
allowed_address_pairs参数中显示默认的 RHOSP API 和 VIP 地址:openstack port show <cluster_name> -c allowed_address_pairs
$ openstack port show <cluster_name> -c allowed_address_pairsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
*Field* *Value* allowed_address_pairs ip_address='192.168.0.5', mac_address='fa:16:3e:31:f9:cb' ip_address='192.168.0.7', mac_address='fa:16:3e:31:f9:cb'*Field* *Value* allowed_address_pairs ip_address='192.168.0.5', mac_address='fa:16:3e:31:f9:cb' ip_address='192.168.0.7', mac_address='fa:16:3e:31:f9:cb'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为 IP 故障转移部署设置不同的 VIP 地址,并通过在 RHOSP CLI 中输入以下命令使 RHOSP 端口上的地址访问。不要将任何默认的 RHOSP API 和 VIP 地址设置为 IP 故障转移部署的故障转移 VIP 地址。
在 RHOSP 端口中添加
1.1.1.1故障转移 IP 地址作为允许的地址的示例。openstack port set <cluster_name> --allowed-address ip-address=1.1.1.1,mac-address=fa:fa:16:3e:31:f9:cb
$ openstack port set <cluster_name> --allowed-address ip-address=1.1.1.1,mac-address=fa:fa:16:3e:31:f9:cbCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 创建部署 YAML 文件,为您的部署配置 IP 故障切换。请参阅后续步骤中的"IP 故障转移配置的部署 YAML 示例"。
在 IP 故障转移部署中指定以下规格,以便将故障转移 VIP 地址传递给
OPENSHIFT_HA_VIRTUAL_IPS环境变量:将
1.1.1.1VIP 地址添加到OPENSHIFT_HA_VIRTUAL_IPS的示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建部署 YAML 文件来配置 IP 故障切换。
注意对于 Red Hat OpenStack Platform (RHOSP),您不需要重新创建部署 YAML 文件。您已作为之前说明的一部分创建了此文件。
IP 故障转移配置的部署 YAML 示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IP 故障转移部署的名称。
- 2
- 要复制的 IP 地址范围列表。必须提供.例如,
1.2.3.4-6,1.2.3.9。 - 3
- 为 VRRP 创建的组数量。如果没有设置,则会为通过
OPENSHIFT_HA_VIP_GROUPS变量指定的每个虚拟 IP 范围创建一个组。 - 4
- IP 故障切换用于发送 VRRP 流量的接口名称。默认情况下使用
eth0。 - 5
- IP 故障转移 pod 会尝试在每个 VIP 上打开到此端口的 TCP 连接。如果建立连接,则服务将被视为正在运行。如果此端口设为
0,则测试会始终通过。默认值为80。 - 6
- 用于设置虚拟路由器 ID 的偏移值。使用不同的偏移值可以在同一集群中存在多个 IP 故障转移配置。默认偏移值为
0,允许的范围是0到255。 - 7
- 要创建的副本数。这必须与 IP 故障转移部署配置中的
spec.replicas值匹配。默认值为2。 - 8
iptables链的名称,用于自动添加允许 VRRP 流量的iptables规则。如果没有设置值,则不会添加iptables规则。如果链不存在,则不会创建链,Keepalived 在单播模式下运行。默认为INPUT。- 9
- 当状态发生变化时运行的脚本的 pod 文件系统的完整路径名称。
- 10
- 定期运行的脚本的 pod 文件系统中的完整路径名称,以验证应用是否正在运行。
- 11
- 处理新的具有更高优先级主机的策略。默认值为
preempt_delay 300,这会导致,在有一个较低优先级的 master 提供 VIP 时,Keepalived 实例在 5 分钟后会接管 VIP。 - 12
- 检查脚本运行的期间(以秒为单位)。默认值为
2。 - 13
- 在创建部署之前创建 pull secret,否则您将在创建部署时收到错误。
12.3. 配置检查和通知脚本 复制链接链接已复制到粘贴板!
keepalived 通过定期运行可选用户提供的检查脚本来监控应用程序的健康状况。例如,该脚本可以通过发出请求并验证响应来测试 Web 服务器。作为集群管理员,您可以提供一个可选的 notify 脚本,该脚本会在状态发生变化时调用。
检查和通知在 IP 故障转移容器集中运行的脚本,并使用容器集文件系统,而不是主机文件系统。但是,IP 故障转移 pod 使主机文件系统在 /hosts 挂载路径下可用。在配置检查或通知脚本时,您必须提供脚本的完整路径。提供脚本的建议方法是使用 ConfigMap 对象。
检查和通知脚本的完整路径名称添加到 Keepalived 配置文件 _/etc/keepalived/keepalived.conf 中,该文件会在 Keepalived 每次启动时加载。可以使用 ConfigMap 对象将脚本添加到 pod,如以下方法所述。
检查脚本
不提供检查脚本时,将运行一个简单的默认脚本来测试 TCP 连接。当监控端口为 0 时,禁止此默认测试。
每个 IP 故障转移 pod 管理一个 Keepalived 守护进程,在运行 pod 的节点上管理一个或多个虚拟 IP (VIP)地址。Keepalived 守护进程为该节点保留每个 VIP 的状态。特定节点上的特定 VIP 可能处于 master、backup 或 fault 状态。
如果检查脚本返回非零,节点会进入 backup 状态,并且它拥有的任何 VIP 被重新分配。
notify 脚本
keepalived 将以下三个参数传递给 notify 脚本:
-
$1-group或instance -
$2-group或instance的名称 -
$3- 新状态:master、backup或fault
先决条件
-
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
创建所需脚本,并创建
ConfigMap对象来容纳它。脚本没有输入参数,并且必须返回0(OK)和1(fail)。检查脚本,
mycheckscript.sh:#!/bin/bash # Whatever tests are needed # E.g., send request and verify response exit 0#!/bin/bash # Whatever tests are needed # E.g., send request and verify response exit 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
ConfigMap对象:oc create configmap mycustomcheck --from-file=mycheckscript.sh
$ oc create configmap mycustomcheck --from-file=mycheckscript.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将脚本添加到容器集。挂载的
ConfigMap对象的defaultMode必须能够使用oc命令或编辑部署配置来运行。值通常为0755、493(十进制):oc set env deploy/ipfailover-keepalived \ OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh$ oc set env deploy/ipfailover-keepalived \ OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc set volume deploy/ipfailover-keepalived --add --overwrite \ --name=config-volume \ --mount-path=/etc/keepalive \ --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'$ oc set volume deploy/ipfailover-keepalived --add --overwrite \ --name=config-volume \ --mount-path=/etc/keepalive \ --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意oc set env命令对空格敏感。=符号的两侧不能有空格。提示您还可以编辑
ipfailover-keepalived部署配置:oc edit deploy ipfailover-keepalived
$ oc edit deploy ipfailover-keepalivedCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 保存更改并退出编辑器。这会重启
ipfailover-keepalived。
12.4. 配置 VRRP 抢占 复制链接链接已复制到粘贴板!
当一个节点上的虚拟 IP(VIP)因为通过了检查脚本的检查而脱离 fault 状态时,如果其优先级低于当前处于 master 状态的节点上的 VIP,则节点上的 VIP 将进入 backup 状态。nopreempt 策略不会将 master 从主机上的较低优先级 VIP 移到主机上的优先级更高的 VIP。当使用默认的 preempt_delay 300 时,Keepalived 会等待指定的 300 秒,并将 master 移到主机上的优先级更高的 VIP。
流程
要指定抢占,输入
oc edit deploy ipfailover-keepalived以编辑路由器部署配置:oc edit deploy ipfailover-keepalived
$ oc edit deploy ipfailover-keepalivedCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 设置
OPENSHIFT_HA_PREEMPTION值:-
preempt_delay 300:Keepalived 会等待指定的 300 秒,并将master移到主机上的优先级更高的 VIP。这是默认值。 -
nopreempt:不会将master从主机上的较低优先级 VIP 移到主机上的优先级更高的 VIP。
-
12.5. 部署多个 IP 故障转移实例 复制链接链接已复制到粘贴板!
每个 IP 转移 pod 由 IP 故障转移部署配置管理,每个节点 1 个 pod,以一个 Keepalived 守护进程运行。配置更多 IP 故障转移部署配置后,会创建更多 pod,更多的守护进程加入常见的虚拟路由器冗余协议(VRRP)协商。此协商由所有 Keepalived 守护进程完成,它决定了哪些节点服务是哪个虚拟 IP(VIP)。
Keepalived 内部为每个 VIP 分配一个唯一的 vrrp-id。协商使用这一组 vrrp-ids,在做出决策时,胜出的 vrrp-id 对应的 VIP 将在胜出的节点上服务。
因此,对于 IP 故障转移部署配置中定义的每个 VIP,IP 故障转移 pod 必须分配对应的 vrrp-id。这可以从 OPENSHIFT_HA_VRRP_ID_OFFSET 开始,并按顺序将 vrrp-ids 分配到 VIP 列表来实现。vrrp-ids 的值可在 1..255 之间。
当存在多个 IP 故障转移部署配置时,您必须指定 OPENSHIFT_HA_VRRP_ID_OFFSET,以便在部署配置中增加 VIP 的数量,并且没有 vrrp-id 范围重叠。
12.6. 为超过 254 地址配置 IP 故障转移 复制链接链接已复制到粘贴板!
IP 故障转移管理有 254 个组虚拟 IP(VIP)地址的限制。默认情况下,OpenShift Container Platform 会为每个组分配一个 IP 地址。您可以使用 OPENSHIFT_HA_VIP_GROUPS 变量进行更改,使得每个组中有多个 IP 地址,并在配置 IP 故障转移时定义每个虚拟路由器冗余协议(VRRP)实例可用的 VIP 组数量。
在 VRRP 故障转移事件中,对 VIP 进行分组会为每个 VRRP 创建更广泛的 VIP 分配范围,并在集群中的所有主机都能够从本地访问服务时很有用。例如,当服务通过 ExternalIP 公开时。
使用故障转移的一个规则是,请勿将路由等服务限制到一个特定的主机。相反,服务应复制到每一主机上,以便在 IP 故障转移时,不必在新主机上重新创建服务。
如果使用 OpenShift Container Platform 健康检查,IP 故障转移和组的性质意味着不会检查组中的所有实例。因此,必须使用 Kubernetes 健康检查来确保服务处于活动状态。
先决条件
-
使用具有
cluster-admin权限的用户登陆到集群。
流程
要更改分配给每个组的 IP 地址数量,请更改
OPENSHIFT_HA_VIP_GROUPS变量的值,例如:IP 故障转换配置的
DeploymentYAML 示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 如果在有七个 VIP 的环境中将
OPENSHIFT_HA_VIP_GROUPS设置为3,它会创建三个组,将三个 VIP 分配到第一个组,为剩余的两个组各分配两个 VIP。
如果 OPENSHIFT_HA_VIP_GROUPS 设置的组数量少于设置为故障的 IP 地址数量,则组包含多个 IP 地址,且所有地址都作为一个单元移动。
12.7. ExternalIP 的高可用性 复制链接链接已复制到粘贴板!
在非云集群中,可以组合使用 IP 故障切换和 ExternalIP 到服务。对于使用 ExternalIP 创建服务的用户,结果是高可用性服务。
方法是指定集群网络配置的 spec.ExternalIP.autoAssignCIDRs 范围,然后在创建 IP 故障转移配置时使用相同的范围。
因为 IP 故障转移最多可支持整个集群的 255 个 VIP,所以 spec.ExternalIP.autoAssignCIDRs 必须为 /24 或更小。
12.8. 删除 IP 故障切换 复制链接链接已复制到粘贴板!
在初始配置 IP 故障切换时,集群中的 worker 节点会使用 iptables 规则修改,该规则明确允许 Keepalived 在 224.0.0.18 上多播数据包。由于对节点的更改,移除 IP 故障切换需要运行一个作业来删除 iptables 规则并删除 Keepalived 使用的虚拟 IP 地址。
流程
可选:识别并删除存储为配置映射的任何检查和通知脚本:
确定任何用于 IP 故障切换的 pod 是否使用配置映射作为卷:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Namespace: default Pod: keepalived-worker-59df45db9c-2x9mn Volumes that use config maps: volume: config-volume configMap: mycustomcheck
Namespace: default Pod: keepalived-worker-59df45db9c-2x9mn Volumes that use config maps: volume: config-volume configMap: mycustomcheckCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果上一步提供了用作卷的配置映射的名称,请删除配置映射:
oc delete configmap <configmap_name>
$ oc delete configmap <configmap_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
为 IP 故障切换识别现有部署:
oc get deployment -l ipfailover
$ oc get deployment -l ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE default ipfailover 2/2 2 2 105d
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE default ipfailover 2/2 2 2 105dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除部署:
oc delete deployment <ipfailover_deployment_name>
$ oc delete deployment <ipfailover_deployment_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除
ipfailover服务帐户:oc delete sa ipfailover
$ oc delete sa ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行一个作业,该作业会删除最初配置 IP 故障切换时添加的 IP 表规则:
创建一个文件,如
remove-ipfailover-job.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行作业:
oc create -f remove-ipfailover-job.yaml
$ oc create -f remove-ipfailover-job.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
job.batch/remove-ipfailover-2h8dm created
job.batch/remove-ipfailover-2h8dm createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
确认作业删除了 IP 故障切换的初始配置。
oc logs job/remove-ipfailover-2h8dm
$ oc logs job/remove-ipfailover-2h8dmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
remove-failover.sh: OpenShift IP Failover service terminating. - Removing ip_vs module ... - Cleaning up ... - Releasing VIPs (interface eth0) ...
remove-failover.sh: OpenShift IP Failover service terminating. - Removing ip_vs module ... - Cleaning up ... - Releasing VIPs (interface eth0) ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 13 章 使用调优插件配置系统控制和接口属性 复制链接链接已复制到粘贴板!
在 Linux 中,管理员可通过 sysctl 在运行时修改内核参数。您可以使用调优 Container Network Interface(CNI)元插件修改接口级网络 sysctl。tuning CNI meta 插件在一个链中运行,主 CNI 插件如下所示。
主 CNI 插件分配接口,并将此接口在运行时传递给 tuning CNI meta 插件。您可以使用 tuning CNI meta 插件更改网络命名空间中的一些 sysctl 和几个接口属性,如 promiscuous 模式、all-multicast 模式、MTU 和 MAC 地址。
13.1. 使用 tuning CNI 配置系统控制 复制链接链接已复制到粘贴板!
以下流程将调整 CNI 配置为更改接口级网络 net.ipv4.conf.IFNAME.accept_redirects sysctl。这个示例启用接受和发送 ICMP 重定向的数据包。在 tuning CNI meta 插件配置中,接口名称由 IFNAME 令牌表示,并替换为运行时接口的实际名称。
流程
使用以下内容创建网络附加定义,如
tuning-example.yaml:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 下面显示了一个 YAML 文件示例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来应用 YAML:
oc apply -f tuning-example.yaml
$ oc apply -f tuning-example.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
networkattachmentdefinition.k8.cni.cncf.io/tuningnad created
networkattachmentdefinition.k8.cni.cncf.io/tuningnad createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用类似以下示例的网络附加定义,创建示例
pod.yaml:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定配置的
NetworkAttachmentDefinition的名称。 - 2
runAsUser控制使用哪个用户 ID 运行容器。- 3
runAsGroup控制容器使用哪个主要组 ID。- 4
allowPrivilegeEscalation决定 pod 是否请求允许特权升级。如果未指定,则默认为 true。这个布尔值直接控制在容器进程中是否设置了no_new_privs标志。- 5
capabilities允许特权操作,而不提供完整的 root 访问权限。此策略可确保从 pod 中丢弃了所有功能。- 6
runAsNonRoot: true要求容器使用 0 以外的任何 UID 运行。- 7
RuntimeDefault为 pod 或容器工作负载启用默认的 seccomp 配置集。
运行以下命令来应用 yaml:
oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令验证 pod 是否已创建:
oc get pod
$ oc get podCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令登录到 pod:
oc rsh tunepod
$ oc rsh tunepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证配置的 sysctl 标记的值。例如,通过运行以下命令查找
net.ipv4.conf.net1.accept_redirects的值:sysctl net.ipv4.conf.net1.accept_redirects
sh-4.4# sysctl net.ipv4.conf.net1.accept_redirectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出
net.ipv4.conf.net1.accept_redirects = 1
net.ipv4.conf.net1.accept_redirects = 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.2. 使用调优 CNI 启用 all-multicast 模式 复制链接链接已复制到粘贴板!
您可以使用 tuning Container Network Interface (CNI) meta 插件启用 all-multicast 模式。
以下流程描述了如何配置调优 CNI 来启用 all-multicast 模式。
流程
使用以下内容创建网络附加定义,如
tuning-example.yaml:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 下面显示了一个 YAML 文件示例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令应用 YAML 文件中指定的设置:
oc apply -f tuning-allmulti.yaml
$ oc apply -f tuning-allmulti.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
networkattachmentdefinition.k8s.cni.cncf.io/setallmulti created
networkattachmentdefinition.k8s.cni.cncf.io/setallmulti createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用类似以下
examplepod.yaml文件中指定的网络附加定义创建 pod :Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定配置的
NetworkAttachmentDefinition的名称。 - 2
- 指定运行容器的用户 ID。
- 3
- 指定容器使用哪个主要组 ID。
- 4
- 指定 pod 是否可以请求特权升级。如果未指定,则默认为
true。这个布尔值直接控制在容器进程中是否设置了no_new_privs标志。 - 5
- 指定容器功能。
drop: ["ALL"]语句表示所有 Linux 功能都会从 pod 中丢弃,提供更严格的安全配置集。 - 6
- 指定容器将使用任何 UID 为 0 的用户运行。
- 7
- 指定容器的 seccomp 配置集。在这种情况下,type 被设置为
RuntimeDefault。seccomp 是一个 Linux 内核功能,它限制了进程可用的系统调用,通过最小化攻击面来提高安全性。
运行以下命令应用 YAML 文件中指定的设置:
oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令验证 pod 是否已创建:
oc get pod
$ oc get podCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE allmultipod 1/1 Running 0 23s
NAME READY STATUS RESTARTS AGE allmultipod 1/1 Running 0 23sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令登录到 pod:
oc rsh allmultipod
$ oc rsh allmultipodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,列出与 pod 关联的所有接口:
ip link
sh-4.4# ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 14 章 使用流控制传输协议 (SCTP) 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在一个裸机集群中使用集群中的流控制传输协议 (SCTP)。
14.1. 在 OpenShift Container Platform 上支持 SCTP 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在集群中的主机上启用 SCTP。在 Red Hat Enterprise Linux CoreOS (RHCOS) 上,SCTP 模块被默认禁用。
SCTP 是基于信息的可靠协议,可在 IP 网络之上运行。
启用后,您可以使用 SCTP 作为带有 pod、服务和网络策略的协议。Service 对象必须通过将 type 参数设置为 ClusterIP 或 NodePort 值来定义。
14.1.1. 使用 SCTP 协议的示例配置 复制链接链接已复制到粘贴板!
您可以通过将 pod 或服务对象中的 protocol 参数设置为 SCTP 来将 pod 或服务配置为使用 SCTP。
在以下示例中,pod 被配置为使用 SCTP:
在以下示例中,服务被配置为使用 SCTP:
在以下示例中,NetworkPolicy 对象配置为对来自具有特定标签的任何 pod 的端口 80 应用 SCTP 网络流量:
14.2. 启用流控制传输协议 (SCTP) 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在集群中的 worker 节点上加载并启用列入黑名单的 SCTP 内核模块。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin角色的用户访问集群。
流程
创建名为
load-sctp-module.yaml的文件,其包含以下 YAML 定义:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
MachineConfig对象:oc create -f load-sctp-module.yaml
$ oc create -f load-sctp-module.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选: 要在 MachineConfig Operator 应用配置更改时监测节点的状态,请使用以下命令。当节点状态变为
Ready时,则代表配置更新已被应用。oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.3. 验证流控制传输协议 (SCTP) 已启用 复制链接链接已复制到粘贴板!
您可以通过创建一个 pod 以及侦听 SCTP 流量的应用程序,将其与服务关联,然后连接到公开的服务,来验证 SCTP 是否在集群中工作。
先决条件
-
从集群访问互联网来安装
nc软件包。 -
安装 OpenShift CLI (
oc) 。 -
使用具有
cluster-admin角色的用户访问集群。
流程
创建 pod 启动 SCTP 侦听程序:
创建名为
sctp-server.yaml的文件,该文件使用以下 YAML 定义 pod:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建 pod:
oc create -f sctp-server.yaml
$ oc create -f sctp-server.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
为 SCTP 侦听程序 pod 创建服务。
创建名为
sctp-service.yaml的文件,该文件使用以下 YAML 定义服务:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要创建服务,请输入以下命令:
oc create -f sctp-service.yaml
$ oc create -f sctp-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
为 SCTP 客户端创建 pod。
使用以下 YAML 创建名为
sctp-client.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Pod对象:oc apply -f sctp-client.yaml
$ oc apply -f sctp-client.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
在服务器中运行 SCTP 侦听程序。
要连接到服务器 pod,请输入以下命令:
oc rsh sctpserver
$ oc rsh sctpserverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要启动 SCTP 侦听程序,请输入以下命令:
nc -l 30102 --sctp
$ nc -l 30102 --sctpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
连接到服务器上的 SCTP 侦听程序。
- 在终端程序里打开一个新的终端窗口或标签页。
获取
sctpservice服务的 IP 地址。使用以下命令:oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'$ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要连接到客户端 pod,请输入以下命令:
oc rsh sctpclient
$ oc rsh sctpclientCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要启动 SCTP 客户端,请输入以下命令。将
<cluster_IP>替换为sctpservice服务的集群 IP 地址。nc <cluster_IP> 30102 --sctp
# nc <cluster_IP> 30102 --sctpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 15 章 使用 PTP 硬件 复制链接链接已复制到粘贴板!
15.1. 关于 OpenShift 集群节点中的精确时间协议 复制链接链接已复制到粘贴板!
精度时间协议(PTP)用于同步网络中的时钟。与硬件支持一起使用时,PTP 能够达到微秒级的准确性,比网络时间协议 (NTP) 更加准确。
如果您的带有 PTP 的 openshift-sdn 集群使用 User Datagram Protocol (UDP) 进行硬件时间戳,且迁移到 OVN-Kubernetes 插件,则硬件时间戳无法应用到主接口设备,如 Open vSwitch (OVS) 网桥。因此,UDP 版本 4 配置无法使用 br-ex 接口。
您可以配置 linuxptp 服务,并在 OpenShift Container Platform 集群节点中使用具有 PTP 功能的硬件。
通过部署 PTP Operator,使用 OpenShift Container Platform Web 控制台或 OpenShift CLI (oc)安装 PTP。PTP Operator 会创建和管理 linuxptp 服务,并提供以下功能:
- 在集群中发现具有 PTP 功能的设备。
-
管理
linuxptp服务的配置。 -
PTP 时钟事件通知会使用 PTP Operator
cloud-event-proxysidecar 会对应用程序的性能和可靠性造成负面影响。
PTP Operator 只适用于仅在裸机基础架构上置备的集群上具有 PTP 功能的设备。
15.1.1. PTP 域的元素 复制链接链接已复制到粘贴板!
PTP 用于将网络中连接的多个节点与每个节点的时钟同步。PTP 同步时钟以领导层次结构进行组织。层次结构由最佳 master 时钟 (BMC) 算法自动创建和更新,该算法在每个时钟上运行。后续时钟与领导时钟同步,后续时钟本身可以是其他下游时钟的来源。
图 15.1. 网络中的 PTP 节点
下面描述了三种 PTP 时钟类型。
- Grandmaster 时钟
- grandmaster 时钟向网络上的其他时钟提供标准时间信息并确保准确和稳定的同步。它写入时间戳并响应来自其他时钟的时间间隔。grandmaster 时钟与全局导航 Satellite 系统 (GNSS) 时间源同步。Grandmaster 时钟是网络中权威时间来源,负责为所有其他设备提供时间同步。
- Boundary 时钟
- Boundary(边界)时钟在两个或更多个通信路径中具有端口,并且可以是指向其他目标时钟的源和目标。边界时钟作为上游目标时钟工作。目标时钟接收计时消息,针对延迟进行调整,然后创建一个新的源时间信号来传递网络。边界时钟生成一个新的计时数据包,它仍然与源时钟正确同步,并可减少直接报告到源时钟的连接设备数量。
- Ordinary 时钟
- Ordinary(普通)时钟具有一个端口连接,可根据其在网络中的位置扮演源或目标时钟的角色。普通时钟可以读取和写入时间戳。
15.1.1.1. PTP 优于 NTP 的优点 复制链接链接已复制到粘贴板!
PTP 与 NTP 相比有一个主要优势,即各种网络接口控制器 (NIC) 和网络交换机中存在的硬件支持。特殊硬件允许 PTP 考虑消息传输的延迟,并提高时间同步的准确性。为了获得最佳准确性,建议启用 PTP 时钟间的所有网络组件。
基于硬件的 PTP 提供最佳准确性,因为 NIC 可以在准确发送和接收时对 PTP 数据包进行时间戳。这与基于软件的 PTP 进行比较,这需要操作系统对 PTP 数据包进行额外的处理。
在启用 PTP 前,请确保为所需节点禁用 NTP。您可以使用 MachineConfig 自定义资源禁用 chrony 时间服务 (chronyd)。如需更多信息,请参阅禁用 chrony 时间服务。
OpenShift Container Platform 使用带有 linuxptp 和 gpsd 软件包的 PTP Operator 进行高精度网络同步。linuxptp 软件包为网络中的 PTP 时间提供工具和守护进程。带有 Global Navigation Satellite System (GNSS)功能 NIC 的集群主机使用 gpsd 来与 GNSS 时钟源进行接口。
linuxptp 软件包包括用于系统时钟同步的 ts2phc、pmc、ptp4l 和 phc2sys 程序。
- ts2phc
ts2phc将 PTP 设备中的 PTP 硬件时钟(PHC)与高度精确度同步。ts2phc用于 grandmaster 时钟配置。它收到精度计时信号,这是一个高度精确时钟源,如 Global Navigation Satellite System (GNSS)。GNSS 提供准确可靠的同步时间源,用于大型分布式网络。GNSS 时钟通常提供时间信息,其精度为几个纳秒。ts2phc系统守护进程通过读取 grandmaster 时钟中的时间信息,将时间信息从 grandmaster 时钟发送到网络中的其他 PTP 设备,并将其转换为 PHC 格式。PHC 时间供网络中的其他设备用来将其时钟与 grandmaster 时钟同步。- pmc
-
pmc根据 IEEE 标准 1588.1588 实现 PTP 管理客户端 (pmc)。pmc为ptp4l系统守护进程提供基本的管理访问权限。pmc从标准输入读取,并通过所选传输发送输出,打印它收到的任何回复。 - ptp4l
ptp4l实现 PTP 边界时钟和普通时钟,并作为系统守护进程运行。ptp4l执行以下操作:- 将 PHC 同步到源时钟与硬件时间戳
- 将系统时钟与源时钟与软件时间戳同步
- phc2sys
-
phc2sys将系统时钟与网络接口控制器 (NIC) 上的 PHC 同步。phc2sys系统守护进程持续监控 PHC 以获取计时信息。当检测到计时错误时,LareC 会更正系统时钟。
gpsd 软件包包括 ubxtool、gspipe、gpsd、GNSS 时钟与主机时钟同步的程序。
- ubxtool
-
ubxtoolCLI 可让您与 u-blox GPS 系统通信。ubxtoolCLI 使用 u-blox 二进制协议与 GPS 通信。 - gpspipe
-
gpspipe连接到gpsd输出并将其传送到stdout。 - gpsd
-
gpsd是一个服务守护进程,它监控一个或多个连接到主机的 GPS 或 AIS 接收器。
15.1.3. PTP grandmaster 时钟的 GNSS 时间概述 复制链接链接已复制到粘贴板!
OpenShift Container Platform 支持从集群中的 Global Navigation Satellite 系统(GNSS)源和 grandmaster 时钟(T-GM)接收精度 PTP 时间。
OpenShift Container Platform 仅支持 Intel E810 Westport Channel NIC 的 GNSS 源中的 PTP 时间。
图 15.2. 使用 GNSS 和 T-GM 同步概述
- 全局导航 Satellite 系统(GNSS)
GNSS 是一个基于 satellite 的系统,用来为全球范围内接收器提供定位、导航和计时信息。在 PTP 中,GNSS 接收器通常用作高度准确且稳定的参考时钟源。这些接收器从多个 GNSS satellites 接收信号,允许它们计算精确的时间信息。从 GNSS 获取的时间信息被 PTP grandmaster 时钟参考。
通过将 GNSS 用作参考,PTP 网络中的 grandmaster 时钟可以为其他设备提供高度准确的时间戳,从而在整个网络中启用精确同步。
- Digital Phase-Locked Loop (DPLL)
- DPLL 在网络中的不同 PTP 节点之间提供时钟同步。DPLL 将本地系统时钟信号的阶段与传入同步信号的阶段进行比较,例如,来自 PTP grandmaster 时钟的 PTP 信息。DPLL 持续调整本地时钟频率和阶段,以最大程度降低本地时钟和参考时钟之间的阶段差异。
15.1.3.1. 在 GNSS-synced PTP grandmaster 时钟中处理 leap 秒事件 复制链接链接已复制到粘贴板!
Leap second(闰秒)是一秒的调整,偶尔会被应用于 Coordinated Universal Time (UTC),使其与国际原子时间 (TAI) 同步。UTC 秒是无法预计的。在国际范围内认可的闰秒信息包括在 leap-seconds.list 中。此文件通过国际 Earth Rotation 和 Reference Systems Service (IERS)定期更新。一个未处理的闰秒对边缘 RAN 网络有严重影响。可能会导致边缘 RAN 应用程序立即断开语音调用和数据会话。
15.1.4. 关于 PTP 和时钟同步错误事件 复制链接链接已复制到粘贴板!
虚拟 RAN (vRAN) 等云原生应用需要访问对整个网络运行至关重要的硬件计时事件通知。PTP 时钟同步错误可能会对低延迟应用程序的性能和可靠性造成负面影响,例如:在一个分布式单元 (DU) 中运行的 vRAN 应用程序。
丢失 PTP 同步是 RAN 网络的一个关键错误。如果在节点上丢失同步,则可能会关闭无线广播,并且网络 Over the Air (OTA) 流量可能会转移到无线网络中的另一个节点。快速事件通知允许集群节点与 DU 中运行的 vRAN 应用程序通信 PTP 时钟同步状态,从而缓解工作负载错误。
事件通知可用于在同一 DU 节点上运行的 vRAN 应用。发布/订阅 REST API 将事件通知传递到消息传递总线。发布-订阅消息传递或发布-订阅消息传递是服务通信架构的异步服务,通过服务通信架构,所有订阅者会立即收到发布到某一主题的消息。
PTP Operator 为每个支持 PTP 的网络接口生成快速事件通知。您可以通过 HTTP 消息总线使用 cloud-event-proxy sidecar 容器来访问事件。
PTP 快速事件通知可用于配置为使用 PTP 普通时钟、PTP grandmaster 时钟或 PTP 边界时钟。
15.1.5. 2-card E810 NIC 配置参考 复制链接链接已复制到粘贴板!
OpenShift Container Platform 支持用于 grandmaster 时钟(T-GM) 和边界时钟(T-BC) 的 PTP 时间的单和双 NIC Intel E810 硬件。
- 双 NIC grandmaster 时钟
您可以使用具有双 NIC 硬件作为 PTP grandmaster 时钟的集群主机。一个 NIC 从全局导航 Satellite 系统(GNSS)接收计时信息。第二个 NIC 在第一次使用 E810 NIC 上的 SMA1 Tx/Rx 连接接收时间信息。集群主机上的系统时钟从连接到 GNSS satellite 的 NIC 同步。
双 NIC grandmaster 时钟是分布式 RAN (D-RAN)配置的功能,其中远程 Radio 单元(RRU)和 Baseband 单元(BBU)位于相同的无线单元站点。d-RAN 在多个站点间分发无线功能,带有将它们链接到核心网络的连接。
图 15.3. 双 NIC grandmaster 时钟
注意在双 NIC T-GM 配置中,单个
ts2phc程序在两个 PTP 硬件时钟 (PHC)上运行,每个 NIC 对应一个。- 双 NIC 边界时钟
对于提供中等范围的 5G 电信网络,每个虚拟分布式单元(vDU)需要连接到 6 个无线电单元(RU)。要使这些连接,每个 vDU 主机都需要 2 个 NIC 被配置为边界时钟。
双 NIC 硬件允许您将每个 NIC 连接到相同的上游领导时钟,并将每个 NIC 的
ptp4l实例连接给下游时钟。- 带有双 NIC 边界时钟的高可用性系统时钟
您可以将 Intel E810-XXVDA4 Salem 频道双 NIC 硬件配置为双 PTP 边界时钟,为高可用性系统时钟提供计时。如果您在不同的 NIC 上有多个时间源,此配置很有用。高可用性可确保如果两个计时源丢失或断开连接,则节点不会丢失计时同步。
每个 NIC 都连接到同一上游领导时钟。高可用性边界时钟使用多个 PTP 域与目标系统时钟同步。当 T-BC 高度可用时,主机系统时钟可以维护正确的偏移,即使一个或多个
ptp4l实例同步 NIC PHC 时钟失败。如果发生任何单一 SFP 端口或电缆失败,则边界时钟会与领导时钟保持同步。边界时钟领导源选择使用 A-BMCA 算法完成。如需更多信息,请参阅 ITU-T 建议 G.8275.1。
15.1.6. 3-card Intel E810 PTP grandmaster 时钟 复制链接链接已复制到粘贴板!
OpenShift Container Platform 支持使用 3 个 Intel E810 NIC 作为 PTP grandmaster 时钟 (T-GM) 的集群主机。
- 3card grandmaster 时钟
您可以使用具有 3 个 NIC 作为 PTP grandmaster 时钟的集群主机。一个 NIC 从全局导航 Satellite 系统(GNSS)接收计时信息。第二个和第三个 NIC 使用 E810 NIC 上的 SMA1 Tx/Rx 连接从第一个接收时间信息。集群主机上的系统时钟从连接到 GNSS satellite 的 NIC 同步。
3card NIC grandmaster 时钟可用于分布式 RAN (D-RAN)配置,其中 Radio 单元(RU)直接连接到分布式单元(DU),例如,如果 RU 和 DU 位于相同的无线单元站点。d-RAN 在多个站点间分发无线功能,带有将它们链接到核心网络的连接。
图 15.4. 3-card Intel E810 PTP grandmaster 时钟
注意在 3-card T-GM 配置中,单个
ts2phc进程报告为系统中的 3 个ts2phc实例。
15.2. 配置 PTP 设备 复制链接链接已复制到粘贴板!
PTP Operator 将 NodePtpDevice.ptp.openshift.io 自定义资源定义(CRD)添加到 OpenShift Container Platform。
安装后,PTP Operator 会在每个节点中搜索具有 PTP 功能的网络设备。Operator 为提供兼容 PTP 的网络设备的每个节点创建并更新 NodePtpDevice 自定义资源(CR)对象。
带有内置 PTP 功能的网络接口控制器(NIC)硬件有时需要特定于设备的配置。您可以通过在 PtpConfig 自定义资源(CR)中配置插件,将特定于硬件的 NIC 功能用于 PTP Operator 支持的硬件。linuxptp-daemon 服务使用 plugin 小节中的指定参数根据特定的硬件配置启动 linuxptp 进程(ptp4l 和 phc2sys)。
在 OpenShift Container Platform 4.16 中,通过 PtpConfig 插件支持 Intel E810 NIC。
15.2.1. 使用 CLI 安装 PTP Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 CLI 安装 Operator。
先决条件
- 在裸机中安装有支持 PTP 硬件的节点的集群。
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
为 PTP Operator 创建命名空间。
将以下 YAML 保存到
ptp-namespace.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
NamespaceCR:oc create -f ptp-namespace.yaml
$ oc create -f ptp-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
为 PTP Operator 创建 Operator 组。
在
ptp-operatorgroup.yaml文件中保存以下 YAML:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
OperatorGroupCR:oc create -f ptp-operatorgroup.yaml
$ oc create -f ptp-operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
订阅 PTP Operator。
将以下 YAML 保存到
ptp-sub.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
SubscriptionCR:oc create -f ptp-sub.yaml
$ oc create -f ptp-sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
要验证是否已安装 Operator,请输入以下命令:
oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Name Phase 4.16.0-202301261535 Succeeded
Name Phase 4.16.0-202301261535 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.2. 使用 Web 控制台安装 PTP Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 Web 控制台安装 PTP Operator。
如上一节所述,您必须创建命名空间和 operator 组。
流程
使用 OpenShift Container Platform Web 控制台安装 PTP Operator:
- 在 OpenShift Container Platform Web 控制台中,点击 Operators → OperatorHub。
- 从可用的 Operator 列表中选择 PTP Operator,然后点 Install。
- 在 Install Operator 页面中,在 A specific namespace on the cluster 下选择 openshift-ptp。然后点击 Install。
可选:验证是否成功安装了 PTP Operator:
- 切换到 Operators → Installed Operators 页面。
确保 openshift-ptp 项目中列出的 PTP Operator 的 Status 为 InstallSucceeded。
注意在安装过程中,Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息,您可以忽略这个 Failed 信息。
如果 Operator 没有被成功安装,请按照以下步骤进行故障排除:
- 进入 Operators → Installed Operators 页面,检查 Operator Subscriptions 和 Install Plans 选项卡中的 Status 项中是否有任何错误。
-
进入 Workloads → Pods 页面,检查
openshift-ptp项目中 pod 的日志。
15.2.3. 在集群中发现支持 PTP 的网络设备 复制链接链接已复制到粘贴板!
识别集群中存在的 PTP 功能网络设备,以便您可以配置它们
先决条件
- 已安装 PTP Operator。
流程
要返回集群中具有 PTP 功能网络设备的完整列表,请运行以下命令:
oc get NodePtpDevice -n openshift-ptp -o yaml
$ oc get NodePtpDevice -n openshift-ptp -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.4. 将 linuxptp 服务配置为 grandmaster 时钟 复制链接链接已复制到粘贴板!
您可以通过创建一个配置主机 NIC 的 PtpConfig 自定义资源(CR)将 linuxptp 服务(ptp4l、phc2sys、ts2phc)配置为 grandmaster 时钟(T-GM)。
ts2phc 工具允许您将系统时钟与 PTP grandmaster 时钟同步,以便节点可以将精度时钟信号流传输到下游 PTP 普通时钟和边界时钟。
使用 PtpConfig CR 示例,将 linuxptp 服务配置为 Intel Westport Channel E810-XXVDA4T 网络接口的 T-GM。
要配置 PTP 快速事件,请为 ptp4lOpts、ptp4lConf 和 ptpClockThreshold 设置适当的值。ptpClockThreshold 仅在启用事件时使用。如需更多信息,请参阅"配置 PTP 快速事件通知发布程序"。
先决条件
- 对于生产环境中的 T-GM 时钟,请在裸机集群主机上安装 Intel E810 Westport Channel NIC。
-
安装 OpenShift CLI (
oc) 。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 PTP Operator。
流程
创建
PtpConfigCR。例如:根据您的要求,为您的部署使用以下 T-GM 配置之一。将 YAML 保存到
grandmaster-clock-ptp-config.yaml文件中:例 15.1. E810 NIC 的 PTP grandmaster 时钟配置
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意对于 E810 Westport Channel NIC,将
ts2phc.nmea_serialport的值设置为/dev/gnss0。运行以下命令来创建 CR:
oc create -f grandmaster-clock-ptp-config.yaml
$ oc create -f grandmaster-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
检查
PtpConfig配置集是否已应用到节点。运行以下命令,获取
openshift-ptp命名空间中的 pod 列表:oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查配置集是否正确。检查与
PtpConfig配置集中指定的节点对应的linuxptp守护进程的日志。运行以下命令:oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
您可以通过创建一个配置 NIC 的 PtpConfig 自定义资源(T-GM),将 linuxptp 服务(ptp4l、phc2sys、ts2phc) 配置为 2 E810 NIC。
您可以将 linuxptp 服务配置为以下 E810 NIC 的 T-GM:
- Intel E810-XXVDA4T Westport Channel NIC
- Intel E810-CQDA2T Logan Beach NIC
对于分布式 RAN (D-RAN)用例,您可以为 2 个 NIC 配置 PTP,如下所示:
- NIC 1 与全局导航 satellite 系统(GNSS)时间源同步。
-
NIC 2 将同步到 NIC 1 提供的 1PPS 时间输出。此配置由
PtpConfigCR 中的 PTP 硬件插件提供。
2-card PTP T-GM 配置使用 ptp4l 实例,以及一个 ts2phc 实例。ptp4l 和 ts2phc 程序都配置为在两个 PTP 硬件时钟(PHC)上运行,每个 NIC 对应一个。主机系统时钟与连接到 GNSS 时间源的 NIC 同步。
使用 PtpConfig CR 示例,将 linuxptp 服务配置为双 Intel Westport Channel E810-XXVDA4T 网络接口的 T-GM。
要配置 PTP 快速事件,请为 ptp4lOpts、ptp4lConf 和 ptpClockThreshold 设置适当的值。ptpClockThreshold 仅在启用事件时使用。如需更多信息,请参阅"配置 PTP 快速事件通知发布程序"。
先决条件
- 对于生产环境中的 T-GM 时钟,请在裸机集群主机上安装两个 Intel E810 Westport Channel NIC。
-
安装 OpenShift CLI (
oc) 。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 PTP Operator。
流程
创建
PtpConfigCR。例如:将以下 YAML 保存到
grandmaster-clock-ptp-config-dual-nics.yaml文件中:例 15.2. 用于双 E810 NIC 的 PTP grandmaster 时钟配置
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意对于 E810 Westport Channel NIC,将
ts2phc.nmea_serialport的值设置为/dev/gnss0。运行以下命令来创建 CR:
oc create -f grandmaster-clock-ptp-config-dual-nics.yaml
$ oc create -f grandmaster-clock-ptp-config-dual-nics.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
检查
PtpConfig配置集是否已应用到节点。运行以下命令,获取
openshift-ptp命名空间中的 pod 列表:oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查配置集是否正确。检查与
PtpConfig配置集中指定的节点对应的linuxptp守护进程的日志。运行以下命令:oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.4.2. 将 linuxptp 服务配置为 3 E810 NIC 的 grandmaster 时钟 复制链接链接已复制到粘贴板!
您可以通过创建一个配置 NIC 的 PtpConfig 自定义资源(T-GM),将 linuxptp 服务(ptp4l、phc2sys、ts2phc) 配置为 3 E810 NIC。
您可以为以下 E810 NIC 将 linuxptp 服务配置为带有 3 个 NIC 的 T-GM:
- Intel E810-XXVDA4T Westport Channel NIC
- Intel E810-CQDA2T Logan Beach NIC
对于分布式 RAN (D-RAN)用例,您可以为 3 个 NIC 配置 PTP,如下所示:
- NIC 1 同步到全局导航 Satellite 系统(GNSS)
- NIC 2 和 3 与带有 1PPS 的 NIC 1 同步连接
使用 PtpConfig CR 示例,将 linuxptp 服务配置为 3card Intel E810 T-GM。
先决条件
- 对于生产环境中的 T-GM 时钟,在裸机集群主机上安装 3 个 Intel E810 NIC。
-
安装 OpenShift CLI (
oc) 。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 PTP Operator。
流程
创建
PtpConfigCR。例如:将以下 YAML 保存到
three-nic-grandmaster-clock-ptp-config.yaml文件中:例 15.3. 3 E810 NIC 的 PTP grandmaster 时钟配置
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意将
ts2phc.nmea_serialport的值设置为/dev/gnss0。运行以下命令来创建 CR:
oc create -f three-nic-grandmaster-clock-ptp-config.yaml
$ oc create -f three-nic-grandmaster-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
检查
PtpConfig配置集是否已应用到节点。运行以下命令,获取
openshift-ptp命名空间中的 pod 列表:oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m3q 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x6zkn 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m3q 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x6zkn 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查配置集是否正确。运行以下命令,并检查与
PtpConfig配置集中指定的节点对应的linuxptp守护进程的日志:oc logs linuxptp-daemon-74m3q -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-74m3q -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.5. grandmaster clock PtpConfig 配置参考 复制链接链接已复制到粘贴板!
以下参考信息描述了 PtpConfig 自定义资源(CR)的配置选项,将 linuxptp 服务(ptp4l、phc2sys、ts2phc)配置为 grandmaster 时钟。
| PtpConfig CR 字段 | 描述 |
|---|---|
|
|
指定一组
插件机制允许 PTP Operator 进行自动硬件配置。对于 Intel Westport Channel NIC,当 |
|
|
为 |
|
|
指定启动 |
|
| 指定丢弃数据前从发送方等待传输 (TX) 时间戳的最长时间。 |
|
| 指定 JBOD 边界时钟时间延迟值。这个值用于更正网络时间设备之间传递的时间值。 |
|
|
为 注意
确保此处列出的网络接口配置为 grandmaster,并在 |
|
|
为 |
|
|
当 |
|
|
可选。如果 |
|
|
设置
|
|
|
为 |
|
|
指定包括一个或多个 |
|
|
指定在 |
|
|
使用 |
|
|
使用 |
|
|
通过 |
|
|
使用 |
15.2.5.1. grandmaster 时钟类同步状态参考 复制链接链接已复制到粘贴板!
下表描述了 PTP grandmaster 时钟(T-GM) gm.ClockClass 状态。时钟类状态根据其准确性和稳定性根据主要参考时间时钟(PRTC)或其他计时来源对 T-GM 时钟进行分类。
holdover 规格是 PTP 时钟可以维护同步的时间,而无需从主时间源接收更新。
| 时钟类状态 | 描述 |
|---|---|
|
|
T-GM 时钟在 |
|
|
T-GM 时钟处于 |
|
|
T-GM 时钟处于 |
如需更多信息,请参阅 "Phase/time traceability information", ITU-T G.8275.1/Y.1369.1 Recommendations.
15.2.5.2. Intel Westport Channel E810 硬件配置参考 复制链接链接已复制到粘贴板!
使用这些信息了解如何使用 Intel E810-XXVDA4T 硬件插件 将 E810 网络接口配置为 PTP grandmaster 时钟。硬件固定配置决定了网络接口如何与系统中的其他组件和设备进行交互。E810-XXVDA4T NIC 有四个连接器用于外部 1PPS 信号:SMA1, SMA2, U.FL1, 和 U.FL2。
| 硬件固定 | 推荐的设置 | 描述 |
|---|---|---|
|
|
|
禁用 |
|
|
|
禁用 |
|
|
|
禁用 |
|
|
|
禁用 |
SMA1 和 U.FL1 连接器共享通道。SMA2 和 U.FL2 连接器共享通道二。
设置 spec.profile.plugins.e810.ublxCmds 参数,以在 PtpConfig 自定义资源(CR) 中配置 GNSS 时钟。
您必须配置偏移值来补偿 T-GM GPS atenna 电缆信号延迟。要配置最佳 T-GM antenna offset 值,请对 GNSS atenna 电缆信号延迟进行精确测量。红帽无法协助进行这个测量,或为所需的延迟偏移提供任何值。
这些 ublxCmds 小节各自对应于使用 ubxtool 命令应用到主机 NIC 的配置。例如:
- 1
- 以纳秒为单位测量 T-GM 延迟偏移。要获得所需的延迟偏移值,您必须使用外部测试设备测量电缆延迟。
下表描述了等效的 ubxtool 命令:
| ubxtool 命令 | 描述 |
|---|---|
|
|
启用一个tenna voltage 控制,允许在 |
|
| 启用 atenna 接收 GPS 信号。 |
|
| 配置 atenna 以接收来自 Galileo GPS satellite 的信号。 |
|
| 禁用 atenna 从 GLONASS GPS satellite 接收信号。 |
|
| 禁用 atenna 从 BeiDou GPS satellite 接收信号。 |
|
| 禁用 atenna 从 SBAS GPS satellite 接收信号。 |
|
| 配置 GNSS 接收器调查进程,以提高其初始位置估算。这可能需要 24 小时才能获得最佳结果。 |
|
| 对硬件运行单个自动扫描,并报告 NIC 状态和配置设置。 |
15.2.5.3. 双 E810 Westport Channel NIC 配置参考 复制链接链接已复制到粘贴板!
使用这些信息了解如何使用 Intel E810-XXVDA4T 硬件插件将 E810 网络接口配置为 PTP grandmaster 时钟(T-GM)。
在配置双 NIC 集群主机前,您必须使用 1PPS faceplace 连接将两个 NIC 与 SMA1 电缆连接。
当您配置双 NIC T-GM 时,您需要补补使用 SMA1 连接端口连接 NIC 时发生的 1PPS 信号延迟。电缆长度、基线温度、组件和制造容错等各种因素可能会影响信号延迟。要满足延迟要求,您必须计算用于偏移信号延迟的特定值。
| PtpConfig 字段 | 描述 |
|---|---|
|
| 使用 PTP Operator E810 硬件插件配置 E810 硬件固定。
|
|
|
使用 |
|
|
将 |
15.2.5.4. 3-card E810 NIC 配置参考 复制链接链接已复制到粘贴板!
使用此信息了解如何将 3 E810 NIC 配置为 PTP grandmaster 时钟 (T-GM)。
在配置 3card 集群主机前,您必须使用 1PPS faceplate 连接 3 个 NIC。主 NIC 1PPS_out 输出提供其他 2 NIC。
当您配置 3 个卡 T-GM 时,您需要使用 SMA1 连接端口连接 NIC 时发生 1PPS 信号延迟。电缆长度、基线温度、组件和制造容错等各种因素可能会影响信号延迟。要满足延迟要求,您必须计算用于偏移信号延迟的特定值。
| PtpConfig 字段 | 描述 |
|---|---|
|
| 使用 PTP Operator E810 硬件插件配置 E810 硬件固定。
|
|
|
使用 |
|
|
将 |
15.2.6. 为 PTP grandmaster 时钟配置动态秒处理 复制链接链接已复制到粘贴板!
PTP Operator 容器镜像包含最新的 leap-seconds.list 文件,该文件在发布时可用。您可以使用全局位置系统(GPS)公告将 PTP Operator 配置为自动更新闰秒文件。
闰秒信息存储在 openshift-ptp 命名空间中的名为 leap-configmap 的自动生成的 ConfigMap 资源中。PTP Operator 将 leap-configmap 资源挂载为 linuxptp-daemon pod 中的卷,该 pod 可以被 ts2phc 进程访问。
如果 GPS satellite 广播新的闰秒数据,PTP Operator 会使用新数据更新 leap-configmap 资源。ts2phc 进程自动获取更改。
以下步骤作为参考提供。PTP Operator 的 4.16 版本默认启用自动润秒管理。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。 - 您已在集群中安装 PTP Operator 并配置了 PTP grandmaster 时钟 (T-GM)。
流程
在
PtpConfigCR 的phc2sysOpts部分中配置自动步处理。设置以下选项:phc2sysOpts: -r -u 0 -m -N 8 -R 16 -S 2 -s ens2f0 -n 24
phc2sysOpts: -r -u 0 -m -N 8 -R 16 -S 2 -s ens2f0 -n 241 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意在以前的版本中,T-GM 需要
phc2sys配置 (-O -37) 中的偏移调整才能考虑历史的秒。这已不再需要。配置 Intel e810 NIC,以便由
PtpConfigCR 的spec.profile.plugins.e810.ublxCmds部分中的 GPS 接收器启用定期报告NAV-TIMELS消息。例如:- args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248"- args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证配置的 T-GM 是否收到来自连接的 GPS 的
NAV-TIMELS消息。运行以下命令:oc -n openshift-ptp -c linuxptp-daemon-container exec -it $(oc -n openshift-ptp get pods -o name | grep daemon) -- ubxtool -t -p NAV-TIMELS -P 29.20
$ oc -n openshift-ptp -c linuxptp-daemon-container exec -it $(oc -n openshift-ptp get pods -o name | grep daemon) -- ubxtool -t -p NAV-TIMELS -P 29.20Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 验证
leap-configmap资源是否已由 PTP Operator 成功生成,并且使用最新版本的 leap-seconds.list 保持最新状态。运行以下命令:oc -n openshift-ptp get configmap leap-configmap -o jsonpath='{.data.<node_name>}'$ oc -n openshift-ptp get configmap leap-configmap -o jsonpath='{.data.<node_name>}'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.7. 将 linuxptp 服务配置为边界时钟 复制链接链接已复制到粘贴板!
您可以通过创建 PtpConfig 自定义资源(CR)对象将 linuxptp 服务(ptp4l、phc2sys)配置为边界时钟。
使用 PtpConfig CR 示例,将 linuxptp 服务配置为特定硬件和环境的边界时钟。这个示例 CR 没有配置 PTP 快速事件。要配置 PTP 快速事件,请为 ptp4lOpts、ptp4lConf 和 ptpClockThreshold 设置适当的值。ptpClockThreshold 仅在启用事件时使用。如需更多信息,请参阅"配置 PTP 快速事件通知发布程序"。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 PTP Operator。
流程
创建以下
PtpConfigCR,然后在boundaries-clock-ptp-config.yaml文件中保存 YAML。PTP 边界时钟配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表 15.7. PTP 边界时钟 CR 配置选项 CR 字段 描述 namePtpConfigCR 的名称。配置集指定包括一个或多个
profile的数组。name指定唯一标识配置集对象的配置集对象的名称。
ptp4lOpts为
ptp4l服务指定系统配置选项。该选项不应包含网络接口名称-i <interface>和服务配置文件-f /etc/ptp4l.conf,因为网络接口名称和服务配置文件会被自动附加。ptp4lConf指定启动
ptp4l作为边界时钟所需的配置。例如,ens1f0同步来自 Pumaster 时钟,ens1f3同步连接的设备。<interface_1>接收同步时钟的接口。
<interface_2>发送同步时钟的接口。
tx_timestamp_timeout对于 Intel Columbiaville 800 系列 NIC,将
tx_timestamp_timeout设置为50。boundary_clock_jbod对于 Intel Columbiaville 800 系列 NIC,请确保
boundary_clock_jbod设置为0。对于 Intel Fortville X710 系列 NIC,请确保boundary_clock_jbod设置为1。phc2sysOpts为
phc2sys服务指定系统配置选项。如果此字段为空,PTP Operator 不会启动phc2sys服务。ptpSchedulingPolicyptp4l 和 phc2sys 进程的调度策略。默认值为
SCHED_OTHER。在支持 FIFO 调度的系统上使用SCHED_FIFO。ptpSchedulingPriority当
ptpSchedulingPolicy设置为SCHED_FIFO时,用于为ptp4l和phc2sys进程设置 FIFO 优先级的整数值(1 到 65)。当ptpSchedulingPolicy设置为SCHED_OTHER时,不使用ptpSchedulingPriority字段。ptpClockThreshold可选。如果没有
ptpClockThreshold,用于ptpClockThreshold字段的默认值。ptpClockThreshold配置在触发 PTP 时间前,PTP master 时钟已断开连接的时长。holdOverTimeout是在 PTP master clock 断开连接时,PTP 时钟事件状态更改为FREERUN前的时间值(以秒为单位)。maxOffsetThreshold和minOffsetThreshold设置以纳秒为单位,它们与CLOCK_REALTIME(phc2sys) 或 master 偏移 (ptp4l) 的值进行比较。当ptp4l或phc2sys偏移值超出这个范围时,PTP 时钟状态被设置为FREERUN。当偏移值在这个范围内时,PTP 时钟状态被设置为LOCKED。建议指定包括一个或多个
recommend对象的数组,该数组定义了如何将配置集应用到节点的规则。.recommend.profile指定在
profile部分定义的.recommend.profile对象名称。.recommend.priority使用
0到99之间的一个整数值指定priority。大数值的优先级较低,因此优先级99低于优先级10。如果节点可以根据match字段中定义的规则与多个配置集匹配,则优先级较高的配置集会应用到该节点。.recommend.match使用
nodeLabel或nodeName值指定.recommend.match规则。.recommend.match.nodeLabel通过
oc get nodes --show-labels命令,使用来自节点对象的node.Labels的key设置nodeLabel。例如,node-role.kubernetes.io/worker。.recommend.match.nodeName使用
oc get nodes命令,将nodeName设置为来自节点对象的node.Name值。例如,compute-1.example.com。运行以下命令来创建 CR:
oc create -f boundary-clock-ptp-config.yaml
$ oc create -f boundary-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
检查
PtpConfig配置集是否已应用到节点。运行以下命令,获取
openshift-ptp命名空间中的 pod 列表:oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查配置集是否正确。检查与
PtpConfig配置集中指定的节点对应的linuxptp守护进程的日志。运行以下命令:oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.7.1. 将 linuxptp 服务配置为双 NIC 硬件的边界时钟 复制链接链接已复制到粘贴板!
您可以通过为每个 NIC 创建一个 PtpConfig 自定义资源(CR)对象,将 linuxptp 服务(ptp4l、phc2sys)配置为双 NIC 硬件的边界时钟。
双 NIC 硬件允许您将每个 NIC 连接到相同的上游领导时钟,并将每个 NIC 的 ptp4l 实例连接给下游时钟。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 PTP Operator。
流程
创建两个单独的
PtpConfigCR,每个 NIC 使用 "Configuring linuxptp 服务作为边界时钟"中的引用 CR,作为每个 CR 的基础。例如:创建
boundary-clock-ptp-config-nic1.yaml,为phc2sysOpts指定值:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
boundary-clock-ptp-config-nic2.yaml,删除phc2sysOpts字段,以完全禁用第二个 NIC 的phc2sys服务:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 在第二个 NIC上 指定所需的接口来启动
ptp4l作为一个边境时钟。
注意您必须从第二个
PtpConfigCR 中完全删除phc2sysOpts字段,以禁用第二个 NIC 上的phc2sys服务。
运行以下命令来创建双 NIC
PtpConfigCR:创建 CR 来为第一个 NIC 配置 PTP:
oc create -f boundary-clock-ptp-config-nic1.yaml
$ oc create -f boundary-clock-ptp-config-nic1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 CR 来为第二个 NIC 配置 PTP:
oc create -f boundary-clock-ptp-config-nic2.yaml
$ oc create -f boundary-clock-ptp-config-nic2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
检查 PTP Operator 是否为两个 NIC 应用了
PtpConfigCR。检查与安装了双 NIC 硬件的节点对应的linuxptp守护进程的日志。例如,运行以下命令:oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
ptp4l[80828.335]: [ptp4l.1.config] master offset 5 s2 freq -5727 path delay 519 ptp4l[80828.343]: [ptp4l.0.config] master offset -5 s2 freq -10607 path delay 533 phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1 s2 freq -87239 delay 539
ptp4l[80828.335]: [ptp4l.1.config] master offset 5 s2 freq -5727 path delay 519 ptp4l[80828.343]: [ptp4l.0.config] master offset -5 s2 freq -10607 path delay 533 phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1 s2 freq -87239 delay 539Copy to Clipboard Copied! Toggle word wrap Toggle overflow
您可以将 linuxptp 服务 ptp4l 和 phc2sys 配置为双 PTP 边界时钟 (T-BC) 的高可用性 (HA) 系统时钟。
高可用性系统时钟使用来自双 NIC Intel E810 Salem 频道硬件的多个时间源,配置为两个边界时钟。两个边界时钟实例参与 HA 设置,每个设置都有自己的配置 profile。您可以将每个 NIC 连接到相同的上游领导时钟,每个 NIC 为下游时钟提供单独的 ptp4l 实例。
创建两个 PtpConfig 自定义资源 (CR) 对象,将 NIC 配置为 T-BC 和第三个 PtpConfig CR,以配置两个 NIC 之间的高可用性。
您可以在配置 HA 的 PtpConfig CR 中设置 phc2SysOpts 选项。在 PtpConfig CR 中将 phc2sysOpts 字段设置为配置两个 NIC 的 PtpConfig CR 中的空字符串。这可防止为两个配置集设置单独的 phc2sys 进程。
第三个 PtpConfig CR 配置高度可用的系统时钟服务。CR 将 ptp4lOpts 字段设置为空字符串,以防止 ptp4l 进程运行。CR 在 spec.profile.ptpSettings.haProfiles 键下添加 ptp4l 配置的配置集,并将这些配置集的内核套接字路径传递给 phc2sys 服务。当出现 ptp4l 失败时,phc2sys 服务将切换到备份 ptp4l 配置。当主配置集再次激活时,phc2sys 服务将恢复到原始状态。
确保将 spec.recommend.priority 设置为您用来配置 HA 的所有三个 PtpConfig CR 的值。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 PTP Operator。
- 使用 Intel E810 Salem 频道双 NIC 配置集群节点。
流程
创建两个单独的
PtpConfigCR,每个 NIC 使用"将 linuxptp 服务配置为双 NIC 硬件边界时钟"中的 CR 作为每个 CR 的引用。创建
ha-ptp-config-nic1.yaml文件,为phc2sysOpts字段指定一个空字符串。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为 NIC 1 应用
PtpConfigCR:oc create -f ha-ptp-config-nic1.yaml
$ oc create -f ha-ptp-config-nic1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
ha-ptp-config-nic2.yaml文件,为phc2sysOpts字段指定一个空字符串。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为 NIC 2 应用
PtpConfigCR:oc create -f ha-ptp-config-nic2.yaml
$ oc create -f ha-ptp-config-nic2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建配置 HA 系统时钟的
PtpConfigCR。例如:创建
ptp-config-for-ha.yaml文件。将haProfiles设置为与配置两个 NIC 的PtpConfigCR 中设置的metadata.name字段匹配。例如:haProfiles: ha-ptp-config-nic1,ha-ptp-config-nic2Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
ptp4lOpts字段设置为空字符串。如果它不为空,p4ptl进程开始时会带有一个严重错误。
重要在配置单个 NIC 的
PtpConfigCR 前,不要应用高可用性PtpConfigCR。运行以下命令来应用 HA
PtpConfigCR:oc create -f ptp-config-for-ha.yaml
$ oc create -f ptp-config-for-ha.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证 PTP Operator 是否已正确应用
PtpConfigCR。执行以下步骤:运行以下命令,获取
openshift-ptp命名空间中的 pod 列表:oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkrb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com ptp-operator-657bbq64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkrb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com ptp-operator-657bbq64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意应该只有一个
linuxptp-daemonpod。运行以下命令,检查配置集是否正确。检查与
PtpConfig配置集中指定的节点对应的linuxptp守护进程的日志。oc logs linuxptp-daemon-4xkrb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkrb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.8. 将 linuxptp 服务配置为常规时钟 复制链接链接已复制到粘贴板!
您可以通过创建 PtpConfig 自定义资源(CR)对象将 linuxptp 服务(ptp4l、phc2sys)配置为常规时钟。
使用 PtpConfig CR 示例,将 linuxptp 服务配置为特定硬件和环境的普通时钟。这个示例 CR 没有配置 PTP 快速事件。要配置 PTP 快速事件,请为 ptp4lOpts、ptp4lConf 和 ptpClockThreshold 设置适当的值。只有在启用事件时才需要 ptpClockThreshold。如需更多信息,请参阅"配置 PTP 快速事件通知发布程序"。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 PTP Operator。
流程
创建以下
PtpConfigCR,然后在ordinary-clock-ptp-config.yaml文件中保存 YAML。PTP 普通时钟配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表 15.8. PTP 普通时钟 CR 配置选项 CR 字段 描述 namePtpConfigCR 的名称。配置集指定包括一个或多个
profile的数组。每个配置集的名称都需要是唯一的。interface指定
ptp4l服务要使用的网络接口,如ens787f1。ptp4lOpts为
ptp4l服务指定系统配置选项,例如-2来选择 IEEE 802.3 网络传输。该选项不应包含网络接口名称-i <interface>和服务配置文件-f /etc/ptp4l.conf,因为网络接口名称和服务配置文件会被自动附加。附加--summary_interval -4来对此接口使用 PTP 快速事件。phc2sysOpts为
phc2sys服务指定系统配置选项。如果此字段为空,PTP Operator 不会启动phc2sys服务。对于 Intel Columbiaville 800 Series NIC,将phc2sysOpts选项设置为-a -r -m -n 24 -N 8 -R 16.-m将消息输出到stdout。linuxptp-daemonDaemonSet解析日志并生成 Prometheus 指标。ptp4lConf指定一个字符串,其中包含要替换默认的
/etc/ptp4l.conf文件的配置。要使用默认配置,请将字段留空。tx_timestamp_timeout对于 Intel Columbiaville 800 系列 NIC,将
tx_timestamp_timeout设置为50。boundary_clock_jbod对于 Intel Columbiaville 800 系列 NIC,将
boundary_clock_jbod设置为0。ptpSchedulingPolicyptp4l和phc2sys进程的调度策略。默认值为SCHED_OTHER。在支持 FIFO 调度的系统上使用SCHED_FIFO。ptpSchedulingPriority当
ptpSchedulingPolicy设置为SCHED_FIFO时,用于为ptp4l和phc2sys进程设置 FIFO 优先级的整数值(1 到 65)。当ptpSchedulingPolicy设置为SCHED_OTHER时,不使用ptpSchedulingPriority字段。ptpClockThreshold可选。如果没有
ptpClockThreshold,用于ptpClockThreshold字段的默认值。ptpClockThreshold配置在触发 PTP 时间前,PTP master 时钟已断开连接的时长。holdOverTimeout是在 PTP master clock 断开连接时,PTP 时钟事件状态更改为FREERUN前的时间值(以秒为单位)。maxOffsetThreshold和minOffsetThreshold设置以纳秒为单位,它们与CLOCK_REALTIME(phc2sys) 或 master 偏移 (ptp4l) 的值进行比较。当ptp4l或phc2sys偏移值超出这个范围时,PTP 时钟状态被设置为FREERUN。当偏移值在这个范围内时,PTP 时钟状态被设置为LOCKED。建议指定包括一个或多个
recommend对象的数组,该数组定义了如何将配置集应用到节点的规则。.recommend.profile指定在
profile部分定义的.recommend.profile对象名称。.recommend.priority对于普通时钟,将
.recommend.priority设置为0。.recommend.match使用
nodeLabel或nodeName值指定.recommend.match规则。.recommend.match.nodeLabel通过
oc get nodes --show-labels命令,使用来自节点对象的node.Labels的key设置nodeLabel。例如,node-role.kubernetes.io/worker。.recommend.match.nodeName使用
oc get nodes命令,将nodeName设置为来自节点对象的node.Name值。例如,compute-1.example.com。运行以下命令来创建
PtpConfigCR:oc create -f ordinary-clock-ptp-config.yaml
$ oc create -f ordinary-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
检查
PtpConfig配置集是否已应用到节点。运行以下命令,获取
openshift-ptp命名空间中的 pod 列表:oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查配置集是否正确。检查与
PtpConfig配置集中指定的节点对应的linuxptp守护进程的日志。运行以下命令:oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
下表描述了您必须对引用 PTP 配置所做的更改,以使用 Intel Columbiaville E800 系列 NIC 作为普通时钟。在应用到集群的 PtpConfig 自定义资源(CR)中进行更改。
| PTP 配置 | 推荐的设置 |
|---|---|
|
|
|
|
|
|
|
|
|
对于 phc2sysOpts,-m 会将信息输出到 stdout。linuxptp-daemon DaemonSet 解析日志并生成 Prometheus 指标。
15.2.9. 为 PTP 硬件配置 FIFO 优先级调度 复制链接链接已复制到粘贴板!
在需要低延迟性能的电信或其他部署类型中,PTP 守护进程线程在受限的 CPU 占用空间以及剩余的基础架构组件一起运行。默认情况下,PTP 线程使用 SCHED_OTHER 策略运行。在高负载下,这些线程可能没有获得无错操作所需的调度延迟。
要缓解潜在的调度延迟错误,您可以将 PTP Operator linuxptp 服务配置为允许线程使用 SCHED_FIFO 策略运行。如果为 PtpConfig CR 设置了 SCHED_FIFO,则 ptp4l 和 phc2sys 将在 chrt 的父容器中运行,且由 PtpConfig CR 的 ptpSchedulingPriority 字段设置。
设置 ptpSchedulingPolicy 是可选的,只有在遇到延迟错误时才需要。
流程
编辑
PtpConfigCR 配置集:oc edit PtpConfig -n openshift-ptp
$ oc edit PtpConfig -n openshift-ptpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 更改
ptpSchedulingPolicy和ptpSchedulingPriority字段:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
保存并退出,以将更改应用到
PtpConfigCR。
验证
获取
linuxptp-daemonpod 的名称以及应用PtpConfigCR 的对应节点:oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
ptp4l进程是否使用更新的chrtFIFO 运行:oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt
$ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2 --summary_interval -4 -m
I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2 --summary_interval -4 -mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.10. 为 linuxptp 服务配置日志过滤 复制链接链接已复制到粘贴板!
linuxptp 守护进程生成可用于调试目的的日志。在具有有限存储容量的电信或其他部署类型中,这些日志可以添加到存储要求中。
要减少数量日志消息,您可以配置 PtpConfig 自定义资源 (CR) 来排除报告 master offset 值的日志消息。master offset 日志消息以纳秒为单位报告当前节点时钟和 master 时钟之间的区别。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 PTP Operator。
流程
编辑
PtpConfigCR:oc edit PtpConfig -n openshift-ptp
$ oc edit PtpConfig -n openshift-ptpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
spec.profile中,添加ptpSettings.logReduce规格,并将值设为true:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意为了进行调试,您可以将此规格恢复到
False,使其包含 master 偏移消息。-
保存并退出,以将更改应用到
PtpConfigCR。
验证
获取
linuxptp-daemonpod 的名称以及应用PtpConfigCR 的对应节点:oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证 master 偏移信息是否不包括在日志中:
oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset"
$ oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset"1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <linux_daemon_container> 是
linuxptp-daemonpod 的名称,如linuxptp-daemon-gmv2n。
当您配置
logReduce规格时,这个命令会在linuxptp守护进程日志中报告任何master offset实例。
15.2.11. 常见 PTP Operator 故障排除 复制链接链接已复制到粘贴板!
通过执行以下步骤排除 PTP Operator 中的常见问题。
先决条件
-
安装 OpenShift Container Platform CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 使用支持 PTP 的主机在裸机集群中安装 PTP Operator。
流程
检查集群中为配置的节点成功部署了 Operator 和操作对象。
oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意当启用 PTP fast 事件总线时,就绪的
linuxptp-daemonpod 的数量是3/3。如果没有启用 PTP fast 事件总线,则会显示2/2。检查集群中是否已找到支持的硬件。
oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查节点的可用 PTP 网络接口:
oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
- <node_name>
指定您要查询的节点,例如
compute-0.example.com。输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
通过访问对应节点的
linuxptp-daemonpod,检查 PTP 接口是否已与主时钟成功同步。运行以下命令来获取
linuxptp-daemonpod 的名称以及您要排除故障的对应节点:oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在远程 shell 到所需的
linuxptp-daemon容器:oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
- <linux_daemon_container>
-
您要诊断的容器,如
linuxptp-daemon-lmvgn。
在与
linuxptp-daemon容器的远程 shell 连接中,使用 PTP Management Client (pmc) 工具诊断网络接口。运行以下pmc命令,以检查 PTP 设备的同步状态,如ptp4l。pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
# pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当节点成功同步到主时钟时的输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
对于 GNSS-sourced grandmaster 时钟,运行以下命令来验证 in-tree NIC ice 驱动程序是否正确,例如:
oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-74m2g ethtool -i ens7f0
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-74m2g ethtool -i ens7f0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
driver: ice version: 5.14.0-356.bz2232515.el9.x86_64 firmware-version: 4.20 0x8001778b 1.3346.0
driver: ice version: 5.14.0-356.bz2232515.el9.x86_64 firmware-version: 4.20 0x8001778b 1.3346.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 对于 GNSS-sourced grandmaster 时钟,请验证
linuxptp-daemon容器是否从 GNSS antenna 接收信号。如果容器没有收到 GNSS 信号,则不会填充/dev/gnss0文件。要验证,请运行以下命令:oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-jnz6r cat /dev/gnss0
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-jnz6r cat /dev/gnss0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
$GNRMC,125223.00,A,4233.24463,N,07126.64561,W,0.000,,300823,,,A,V*0A $GNVTG,,T,,M,0.000,N,0.000,K,A*3D $GNGGA,125223.00,4233.24463,N,07126.64561,W,1,12,99.99,98.6,M,-33.1,M,,*7E $GNGSA,A,3,25,17,19,11,12,06,05,04,09,20,,,99.99,99.99,99.99,1*37 $GPGSV,3,1,10,04,12,039,41,05,31,222,46,06,50,064,48,09,28,064,42,1*62
$GNRMC,125223.00,A,4233.24463,N,07126.64561,W,0.000,,300823,,,A,V*0A $GNVTG,,T,,M,0.000,N,0.000,K,A*3D $GNGGA,125223.00,4233.24463,N,07126.64561,W,1,12,99.99,98.6,M,-33.1,M,,*7E $GNGSA,A,3,25,17,19,11,12,06,05,04,09,20,,,99.99,99.99,99.99,1*37 $GPGSV,3,1,10,04,12,039,41,05,31,222,46,06,50,064,48,09,28,064,42,1*62Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.12. 在 Intel 800 系列 NIC 中获取 CGU 的 DPLL 固件版本 复制链接链接已复制到粘贴板!
您可以通过打开 debug shell 到集群节点并查询 NIC 硬件,在 Intel 800 系列 NIC 中获取 Clock Generation Unit (CGU) 的数字签名循环 (DPLL) 固件版本。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。 - 您已在集群主机中安装了 Intel 800 系列 NIC。
- 您已在带有支持 PTP 的主机的裸机集群中安装 PTP Operator。
流程
运行以下命令来启动 debug pod:
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
- <node_name>
- 是安装 Intel 800 系列 NIC 的节点。
使用
devlink工具以及安装 NIC 的总线和设备名称,检查 NIC 中的 CGU 固件版本。例如,运行以下命令:devlink dev info <bus_name>/<device_name> | grep cgu
sh-4.4# devlink dev info <bus_name>/<device_name> | grep cguCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
- <bus_name>
-
是安装 NIC 的总线。例如,
pci。 - <device_name>
-
是 NIC 设备名称。例如,
0000:51:00.0。
输出示例
cgu.id 36 fw.cgu 8032.16973825.6021
cgu.id 361 fw.cgu 8032.16973825.60212 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意固件版本的每个版本号部分都包括了前导和 3 个八位字节位。数字
16973825的二进制格式是0001 0000 0011 0000 0000 0000 0001。使用二进制值来解码固件版本。例如:Expand 表 15.10. DPLL 固件版本 二进制部分 十进制值 00011
0000 00113
0000 00000
0000 00011
15.2.13. 收集 PTP Operator 数据 复制链接链接已复制到粘贴板!
您可以使用 oc adm must-gather 命令收集有关集群的信息,包括与 PTP Operator 关联的功能和对象。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。 - 已安装 PTP Operator。
流程
要使用
must-gather来收集 PTP Operator 数据,您必须指定 PTP Operatormust-gather镜像。oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel9:v4.16
$ oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel9:v4.16Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3. 使用 REST API v2 开发 PTP 事件消费者应用程序 复制链接链接已复制到粘贴板!
在裸机集群节点上开发使用 Precision Time Protocol (PTP)事件的消费者应用程序时,您可以在单独的应用程序 pod 中部署消费者应用程序。消费者应用程序使用 PTP 事件 REST API v2 订阅 PTP 事件。
以下信息提供了开发使用 PTP 事件的消费者应用程序的一般指导。完整的事件消费者应用示例超出了此信息的范围。
15.3.1. 关于 PTP 快速事件通知框架 复制链接链接已复制到粘贴板!
使用 Precision Time Protocol (PTP) 快速事件 REST API v2 将集群应用程序订阅到裸机集群节点生成的 PTP 事件。
快速事件通知框架使用 REST API 进行通信。PTP 事件 REST API v1 和 v2 基于 O-RAN O-Cloud Notification API Specification for Event Consumers 4.0,它包括在 O-RAN ALLIANCE Specifications 中。
只有 PTP 事件 REST API v2 符合 O-RAN v4。
15.3.2. 使用 PTP 事件 REST API v2 检索 PTP 事件 复制链接链接已复制到粘贴板!
应用程序在生成者云事件代理 sidecar 中使用 O-RAN v4 兼容 REST API 订阅 PTP 事件。cloud-event-proxy sidecar 容器可以访问与主应用程序容器相同的资源,而无需使用主应用程序的任何资源,且没有大量延迟。
图 15.5. 从 PTP 事件制作者 REST API v2 中消耗 PTP 快速事件概述
-
事件在集群主机上生成 -
PTP Operator 管理的 pod 中的
linuxptp-daemon进程作为 KubernetesDaemonSet运行,并管理各种linuxptp进程 (ptp4l、phc2sys,以及可选的用于 grandmaster 时钟ts2phc)。linuxptp-daemon将事件传递给 UNIX 域套接字。 -
事件传递给 cloud-event-proxy sidecar -
PTP 插件从 UNIX 域套接字读取事件,并将其传递给 PTP Operator 管理的 pod 中的
cloud-event-proxysidecar。cloud-event-proxy将 Kubernetes 基础架构的事件提供给具有低延迟的 Cloud-Native Network Function (CNF)。 -
事件已发布 -
PTP Operator 管理的 pod 中的
cloud-event-proxysidecar 处理事件,并使用 PTP 事件 REST API v2 发布事件。 -
消费者应用程序请求订阅并接收订阅的事件 -
消费者应用程序向制作者
cloud-event-proxysidecar 发送 API 请求,以创建 PTP 事件订阅。订阅后,消费者应用程序会侦听资源限定符中指定的地址,并接收和处理 PTP 事件。
15.3.3. 配置 PTP 快速事件通知发布程序 复制链接链接已复制到粘贴板!
要为集群中的网络接口启动使用 PTP fast 事件通知,您必须在 PTP Operator PtpOperatorConfig 自定义资源 (CR) 中启用快速事件发布程序,并在您创建的 PtpConfig CR 中配置 ptpClockThreshold 值。
先决条件
-
已安装 OpenShift Container Platform CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。 - 已安装 PTP Operator。
流程
修改默认 PTP Operator 配置以启用 PTP 快速事件。
在
ptp-operatorconfig.yaml文件中保存以下 YAML:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意在 OpenShift Container Platform 4.13 或更高版本中,当将 HTTP 传输用于 PTP 事件时,您不需要在
PtpOperatorConfig资源中设置spec.ptpEventConfig.transportHost字段。更新
PtpOperatorConfigCR:oc apply -f ptp-operatorconfig.yaml
$ oc apply -f ptp-operatorconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
为 PTP 启用接口创建
PtpConfig自定义资源(CR),并设置ptpClockThreshold和ptp4lOpts所需的值。以下 YAML 演示了您必须在PtpConfigCR 中设置的必要值:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 附加
--summary_interval -4以使用 PTP 快速事件。 - 2
- 所需的
phc2sysOpts值。-m将消息输出到stdout。linuxptp-daemonDaemonSet解析日志并生成 Prometheus 指标。 - 3
- 指定一个字符串,其中包含要替换默认的
/etc/ptp4l.conf文件的配置。要使用默认配置,请将字段留空。 - 4
- 可选。如果
ptpClockThreshold小节不存在,则默认值用于ptpClockThreshold字段。小节显示默认的ptpClockThreshold值。ptpClockThreshold值配置 PTP master 时钟在触发 PTP 事件前的时长。holdOverTimeout是在 PTP master clock 断开连接时,PTP 时钟事件状态更改为FREERUN前的时间值(以秒为单位)。maxOffsetThreshold和minOffsetThreshold设置以纳秒为单位,它们与CLOCK_REALTIME(phc2sys) 或 master 偏移 (ptp4l) 的值进行比较。当ptp4l或phc2sys偏移值超出这个范围时,PTP 时钟状态被设置为FREERUN。当偏移值在这个范围内时,PTP 时钟状态被设置为LOCKED。
15.3.4. PTP 事件 REST API v2 消费者应用程序参考 复制链接链接已复制到粘贴板!
PTP 事件消费者应用程序需要以下功能:
-
使用
POST处理程序运行的 Web 服务,以接收云原生 PTP 事件 JSON 有效负载 -
订阅 PTP 事件制作者的
createSubscription功能 -
getCurrentState功能轮询 PTP 事件制作者的当前状态
以下示例 Go 片断演示了这些要求:
Go 中的 PTP 事件消费者服务器功能示例
Go 中的 PTP 事件 createSubscription 功能示例
- 1
- 将
<node_name>替换为正在生成 PTP 事件的节点 FQDN。例如,compute-1.example.com。
Go 中的 PTP 事件消费者 getCurrentState 功能示例
- 1
- 将
<node_name>替换为正在生成 PTP 事件的节点 FQDN。例如,compute-1.example.com。
15.3.5. 使用 PTP 事件 REST API v2 引用事件消费者部署和服务 CR 复制链接链接已复制到粘贴板!
在部署您的 PTP 事件消费者应用程序来与 PTP 事件 REST API v2 一起使用时,使用 PTP 事件消费者自定义资源 (CR) 示例作为一个参考。
仓库云事件消费者命名空间
参考云事件消费者部署
参考云事件消费者服务帐户
apiVersion: v1 kind: ServiceAccount metadata: name: consumer-sa namespace: cloud-events
apiVersion: v1
kind: ServiceAccount
metadata:
name: consumer-sa
namespace: cloud-events
参考云事件消费者服务
15.3.6. 使用 REST API v2 订阅 PTP 事件 复制链接链接已复制到粘贴板!
部署 cloud-event-consumer 应用程序容器,并将 cloud-event-consumer 应用程序订阅到 PTP 事件,这些事件由 PTP Operator 管理的 pod 中的 cloud-event-proxy 容器发布。
通过将 POST 请求发送到 http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions 传递适当的订阅请求有效负载,将消费者应用程序订阅到 PTP 事件。
9043 是 PTP 事件制作者 pod 中部署的 cloud-event-proxy 容器的默认端口。您可以根据需要为应用程序配置不同的端口。
15.3.7. 验证 PTP 事件 REST API v2 消费者应用程序是否收到事件 复制链接链接已复制到粘贴板!
验证应用程序 pod 中的 cloud-event-consumer 容器是否正在接收 Precision Time Protocol (PTP) 事件。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。 - 已安装并配置了 PTP Operator。
- 您已部署了云事件应用程序 pod 和 PTP 事件消费者应用程序。
流程
检查部署的事件消费者应用的日志。例如,运行以下命令:
oc -n cloud-events logs -f deployment/cloud-consumer-deployment
$ oc -n cloud-events logs -f deployment/cloud-consumer-deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选。使用
linuxptp-daemon部署中的oc和 port-forwarding 端口9043来测试 REST API。例如,运行以下命令:oc port-forward -n openshift-ptp ds/linuxptp-daemon 9043:9043
$ oc port-forward -n openshift-ptp ds/linuxptp-daemon 9043:9043Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Forwarding from 127.0.0.1:9043 -> 9043 Forwarding from [::1]:9043 -> 9043 Handling connection for 9043
Forwarding from 127.0.0.1:9043 -> 9043 Forwarding from [::1]:9043 -> 9043 Handling connection for 9043Copy to Clipboard Copied! Toggle word wrap Toggle overflow 打开新的 shell 提示符并测试 REST API v2 端点:
curl -X GET http://localhost:9043/api/ocloudNotifications/v2/health
$ curl -X GET http://localhost:9043/api/ocloudNotifications/v2/healthCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
OK
OKCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3.8. 监控 PTP 快速事件指标 复制链接链接已复制到粘贴板!
您可以从运行 linuxptp-daemon 的集群节点监控 PTP 快速事件指标。您还可以使用预先配置和自我更新的 Prometheus 监控堆栈来监控 OpenShift Container Platform Web 控制台中的 PTP 快速事件指标。
先决条件
-
安装 OpenShift Container Platform CLI
oc。 -
以具有
cluster-admin特权的用户身份登录。 - 在具有 PTP 功能硬件的节点上安装和配置 PTP Operator。
流程
运行以下命令,为节点启动 debug pod:
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
linuxptp-daemon容器公开的 PTP 指标。例如,运行以下命令:curl http://localhost:9091/metrics
sh-4.4# curl http://localhost:9091/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选。您还可以在
cloud-event-proxy容器的日志中找到 PTP 事件。例如,运行以下命令:oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxyCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
要在 OpenShift Container Platform web 控制台中查看 PTP 事件,请复制您要查询的 PTP 指标的名称,如
openshift_ptp_offset_ns。 - 在 OpenShift Container Platform web 控制台中点 Observe → Metrics。
- 将 PTP 指标名称粘贴到 Expression 字段中,然后点 Run query。
15.3.9. PTP 快速事件指标参考 复制链接链接已复制到粘贴板!
下表描述了运行 linuxptp-daemon 服务的集群节点可用的 PTP 快速事件指标。
| 指标 | 描述 | Example |
|---|---|---|
|
|
返回接口的 PTP 时钟类。对于 PTP 时钟类的可能值为:6 ( |
|
|
|
返回接口的当前 PTP 时钟状态。PTP 时钟状态的可能值为 |
|
|
| 返回主时钟发送计时数据包和接收计时数据包之间的延迟(以纳秒为单位)。 |
|
|
|
当不同 NIC 上有多个时间源时,返回高可用性系统时钟的当前状态。可能的值为 0 ( |
|
|
|
以纳秒为单位返回 2 PTP 时钟之间的频率调整。例如,在上游时钟和 NIC 之间,系统时钟和 NIC 之间,或在 PTP 硬件时钟( |
|
|
|
返回为接口配置的 PTP 时钟角色。可能的值包括 0 ( |
|
|
|
返回 2 时钟或接口之间的最大偏移量(以纳秒为单位)。例如,在上游 GNSS 时钟和 NIC ( |
|
|
| 返回 DPLL 时钟或 GNSS 时钟源和 NIC 硬件时钟之间的偏移量。 |
|
|
|
返回 |
|
|
| 返回显示 PTP 进程是否正在运行的状态代码。 |
|
|
|
为
|
|
15.3.9.1. 只有在启用 T-GM 时,PTP 快速事件指标 复制链接链接已复制到粘贴板!
下表描述了仅在启用 PTP grandmaster 时钟 (T-GM) 时可用的 PTP 快速事件指标。
| 指标 | 描述 | Example |
|---|---|---|
|
|
返回 NIC 的数字阶段锁定循环(DPLL)频率的当前状态。可能的值为 -1 ( |
|
|
|
返回 NMEA 连接的当前状态。NMEA 是 1PPS NIC 连接使用的协议。可能的值有 0 ( |
|
|
|
返回 NIC 的 DPLL 阶段的状态。可能的值为 -1 ( |
|
|
|
返回 NIC 1PPS 连接的当前状态。您可以使用 1PPS 连接在连接的 NIC 之间同步计时。可能的值有 0 ( |
|
|
|
返回全局导航 Satellite 系统(GNSS)连接的当前状态。GNSS 在全局范围内提供基于 satellite 的位置、导航和计时服务。可能的值包括 0 ( |
|
15.4. PTP 事件 REST API v2 参考 复制链接链接已复制到粘贴板!
使用以下 REST API v2 端点,将 cloud-event-consumer 应用程序订阅到 Precision Time Protocol (PTP) 事件,在 PTP 事件制作者 pod 中的 http://localhost:9043/api/ocloudNotifications/v2 中发布。
api/ocloudNotifications/v2/subscriptions-
POST:创建新订阅 -
GET:删除订阅列表 -
DELETE:删除所有订阅
-
api/ocloudNotifications/v2/subscriptions/{subscription_id}-
GET:返回指定订阅 ID 的详情 -
DELETE:删除与指定订阅 ID 关联的订阅
-
api/ocloudNotifications/v2/health-
GET:返回ocloudNotificationsAPI 的健康状况
-
api/ocloudNotifications/v2/publishers-
GET:返回集群节点的 PTP 事件发布程序列表
-
api/ocloudnotifications/v2/{resource_address}/CurrentState-
GET:返回由{resouce_address}指定的事件类型的当前状态。
-
15.4.1. PTP 事件 REST API v2 端点 复制链接链接已复制到粘贴板!
15.4.1.1. api/ocloudNotifications/v2/subscriptions 复制链接链接已复制到粘贴板!
HTTP 方法
GET api/ocloudNotifications/v2/subscriptions
描述
返回订阅列表。如果订阅存在,则返回 200 OK 状态代码以及订阅列表。
API 响应示例
HTTP 方法
POST api/ocloudNotifications/v2/subscriptions
描述
通过传递适当的有效负载来为所需的事件创建新订阅。
您可以订阅以下 PTP 事件:
-
sync-state事件 -
lock-state事件 -
gnss-sync-status events事件 -
os-clock-sync-state事件 -
clock-class事件
| 参数 | 类型 |
|---|---|
| subscription | data |
sync-state 订阅有效负载示例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
PTP lock-state 事件订阅有效负载示例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
PTP gnss-sync-status 事件订阅有效负载示例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
PTP os-clock-sync-state 事件订阅有效负载示例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
PTP clock-class 事件订阅有效负载示例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
API 响应示例
可能会出现以下订阅状态事件:
| 状态代码 | 描述 |
|---|---|
|
| 表示已创建了订阅 |
|
| 表示服务器无法处理请求,因为它是不正确的或无效 |
|
| 表示订阅资源不可用 |
|
| 表示订阅已存在 |
HTTP 方法
DELETE api/ocloudNotifications/v2/subscriptions
描述
删除所有订阅。
API 响应示例
{
"status": "deleted all subscriptions"
}
{
"status": "deleted all subscriptions"
}
HTTP 方法
GET api/ocloudNotifications/v2/subscriptions/{subscription_id}
描述
返回 ID 为 subscription_id 的订阅详情。
| 参数 | 类型 |
|---|---|
|
| string |
API 响应示例
HTTP 方法
DELETE api/ocloudNotifications/v2/subscriptions/{subscription_id}
描述
使用 ID subscription_id 删除订阅。
| 参数 | 类型 |
|---|---|
|
| string |
| HTTP 响应 | 描述 |
|---|---|
| 204 无内容 | 成功 |
15.4.1.3. api/ocloudNotifications/v2/health 复制链接链接已复制到粘贴板!
HTTP 方法
GET api/ocloudNotifications/v2/health/
描述
返回 ocloudNotifications REST API 的健康状况。
| HTTP 响应 | 描述 |
|---|---|
| 200 OK | 成功 |
15.4.1.4. api/ocloudNotifications/v2/publishers 复制链接链接已复制到粘贴板!
HTTP 方法
GET api/ocloudNotifications/v2/publishers
描述
返回集群节点的发布者详情列表。当相关的设备状态改变时,系统会生成通知。
您可以组合使用设备同步状态订阅,以提供有关系统总体同步健康状况的详细视图。
API 响应示例
| HTTP 响应 | 描述 |
|---|---|
| 200 OK | 成功 |
HTTP 方法
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/ptp-status/lock-state/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/ptp-status/clock-class/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/sync-status/sync-state/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/gnss-status/gnss-sync-state/CurrentState
描述
返回集群节点的 os-clock-sync-state,clock-class,lock-state,gnss-sync-status, 或 sync-state 事件的当前状态。
-
os-clock-sync-state通知描述了主机操作系统时钟同步状态。可以是LOCKED或FREERUN状态。 -
clock-class通知描述了 PTP 时钟类的当前状态。 -
lock-state通知描述了 PTP 设备锁定状态的当前状态。可以处于LOCKED、HOLDOVER或FREERUN状态。 -
sync-state通知描述了最少 PTP 时钟lock-state和os-clock-sync-state状态同步的当前状态。 -
GNSS-sync-status通知描述了 GNSS 时钟同步状态。
| 参数 | 类型 |
|---|---|
|
| string |
lock-state API 响应示例
os-clock-sync-state API 响应示例
clock-class API 响应示例
sync-state API 响应示例
gnss-sync-state API 响应示例
15.5. 使用 REST API v1 开发 PTP 事件消费者应用程序 复制链接链接已复制到粘贴板!
在裸机集群节点上开发使用 Precision Time Protocol (PTP)事件的消费者应用程序时,您可以在单独的应用程序 pod 中部署消费者应用程序。消费者应用程序使用 PTP 事件 REST API v1 订阅 PTP 事件。
以下信息提供了开发使用 PTP 事件的消费者应用程序的一般指导。完整的事件消费者应用示例超出了此信息的范围。
在以后的版本中,PTP 事件 REST API v1 将被弃用。在开发使用 PTP 事件的应用程序时,请使用 PTP 事件 REST API v2。
15.5.1. 关于 PTP 快速事件通知框架 复制链接链接已复制到粘贴板!
使用 Precision Time Protocol (PTP) 快速事件 REST API v2 将集群应用程序订阅到裸机集群节点生成的 PTP 事件。
快速事件通知框架使用 REST API 进行通信。PTP 事件 REST API v1 和 v2 基于 O-RAN O-Cloud Notification API Specification for Event Consumers 4.0,它包括在 O-RAN ALLIANCE Specifications 中。
只有 PTP 事件 REST API v2 符合 O-RAN v4。
15.5.2. 使用 PTP 事件 REST API v1 检索 PTP 事件 复制链接链接已复制到粘贴板!
应用程序以 sidecar 模式运行 cloud-event-proxy 容器,以订阅 PTP 事件。cloud-event-proxy sidecar 容器可以访问与主应用程序容器相同的资源,而无需使用主应用程序的任何资源,且没有大量延迟。
图 15.6. 带有消费者 sidecar 和 HTTP 消息传输的 PTP 快速事件概述
-
事件在集群主机上生成 -
PTP Operator 管理的 pod 中的
linuxptp-daemon作为 KubernetesDaemonSet运行,并管理各种linuxptp进程 (ptp4l、phc2sys,以及可选的用于 grandmaster 时钟ts2phc)。linuxptp-daemon将事件传递给 UNIX 域套接字。 -
事件传递给 cloud-event-proxy sidecar -
PTP 插件从 UNIX 域套接字读取事件,并将其传递给 PTP Operator 管理的 pod 中的
cloud-event-proxysidecar。cloud-event-proxy将 Kubernetes 基础架构的事件提供给具有低延迟的 Cloud-Native Network Function (CNF)。 -
事件是持久的 -
PTP Operator 管理的 pod 中的
cloud-event-proxysidecar 处理事件,并使用 REST API 发布云原生事件。 -
消息已传输 -
消息传输程序通过 HTTP 将事件传送到应用程序 pod 中的
cloud-event-proxysidecar。 -
来自 REST API 的事件 -
Application pod 中的
cloud-event-proxysidecar 处理事件并使用 REST API 使其可用。 -
消费者应用程序请求订阅并接收订阅的事件 -
消费者应用程序向应用程序 pod 中的
cloud-event-proxysidecar 发送 API 请求,以创建 PTP 事件订阅。cloud-event-proxysidecar 为订阅中指定的资源创建一个 HTTP 消息传递监听程序协议。
应用程序 pod 中的 cloud-event-proxy sidecar 接收来自 PTP Operator 管理的 pod 的事件,取消封装云事件对象以检索数据,并将事件发布到消费者应用程序。消费者应用程序侦听资源限定符中指定的地址,并接收和处理 PTP 事件。
15.5.3. 配置 PTP 快速事件通知发布程序 复制链接链接已复制到粘贴板!
要为集群中的网络接口启动使用 PTP fast 事件通知,您必须在 PTP Operator PtpOperatorConfig 自定义资源 (CR) 中启用快速事件发布程序,并在您创建的 PtpConfig CR 中配置 ptpClockThreshold 值。
先决条件
-
已安装 OpenShift Container Platform CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。 - 已安装 PTP Operator。
流程
修改默认 PTP Operator 配置以启用 PTP 快速事件。
在
ptp-operatorconfig.yaml文件中保存以下 YAML:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 通过将
enableEventPublisher设置为true来启用 PTP 快速事件通知。
注意在 OpenShift Container Platform 4.13 或更高版本中,当将 HTTP 传输用于 PTP 事件时,您不需要在
PtpOperatorConfig资源中设置spec.ptpEventConfig.transportHost字段。更新
PtpOperatorConfigCR:oc apply -f ptp-operatorconfig.yaml
$ oc apply -f ptp-operatorconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
为 PTP 启用接口创建
PtpConfig自定义资源(CR),并设置ptpClockThreshold和ptp4lOpts所需的值。以下 YAML 演示了您必须在PtpConfigCR 中设置的必要值:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 附加
--summary_interval -4以使用 PTP 快速事件。 - 2
- 所需的
phc2sysOpts值。-m将消息输出到stdout。linuxptp-daemonDaemonSet解析日志并生成 Prometheus 指标。 - 3
- 指定一个字符串,其中包含要替换默认的
/etc/ptp4l.conf文件的配置。要使用默认配置,请将字段留空。 - 4
- 可选。如果
ptpClockThreshold小节不存在,则默认值用于ptpClockThreshold字段。小节显示默认的ptpClockThreshold值。ptpClockThreshold值配置 PTP master 时钟在触发 PTP 事件前的时长。holdOverTimeout是在 PTP master clock 断开连接时,PTP 时钟事件状态更改为FREERUN前的时间值(以秒为单位)。maxOffsetThreshold和minOffsetThreshold设置以纳秒为单位,它们与CLOCK_REALTIME(phc2sys) 或 master 偏移 (ptp4l) 的值进行比较。当ptp4l或phc2sys偏移值超出这个范围时,PTP 时钟状态被设置为FREERUN。当偏移值在这个范围内时,PTP 时钟状态被设置为LOCKED。
15.5.4. PTP 事件消费者应用程序参考 复制链接链接已复制到粘贴板!
PTP 事件消费者应用程序需要以下功能:
-
使用
POST处理程序运行的 Web 服务,以接收云原生 PTP 事件 JSON 有效负载 -
订阅 PTP 事件制作者的
createSubscription功能 -
getCurrentState功能轮询 PTP 事件制作者的当前状态
以下示例 Go 片断演示了这些要求:
Go 中的 PTP 事件消费者服务器功能示例
Go 中的 PTP 事件 createSubscription 功能示例
- 1
- 将
<node_name>替换为正在生成 PTP 事件的节点 FQDN。例如,compute-1.example.com。
Go 中的 PTP 事件消费者 getCurrentState 功能示例
15.5.5. 引用 cloud-event-proxy 部署和服务 CR 复制链接链接已复制到粘贴板!
在部署 PTP 事件消费者应用程序时,使用 cloud-event-proxy 部署和订阅者服务 CR 示例作为参考。
使用 HTTP 传输引用 cloud-event-proxy 部署
参考 cloud-event-proxy 订阅者服务
15.5.6. 使用 REST API v1 订阅 PTP 事件 复制链接链接已复制到粘贴板!
在单独的应用程序 pod 中部署 cloud-event-consumer 应用程序容器和 cloud-event-proxy sidecar 容器。
将 cloud-event-consumer 应用程序订阅到 PTP 事件,这些事件由 cloud-event-proxy 容器发布,位于应用程序 pod 中的 http://localhost:8089/api/ocloudNotifications/v1/。
9089 是在应用程序 Pod 中部署的 cloud-event-consumer 容器的默认端口。您可以根据需要为应用程序配置不同的端口。
15.5.7. 验证 PTP 事件 REST API v1 消费者应用程序是否收到事件 复制链接链接已复制到粘贴板!
验证应用程序 pod 中的 cloud-event-proxy 容器是否接收 PTP 事件。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。 - 已安装并配置了 PTP Operator。
流程
获取活跃的
linuxptp-daemonpod 列表。运行以下命令:oc get pods -n openshift-ptp
$ oc get pods -n openshift-ptpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 8h linuxptp-daemon-k8n88 3/3 Running 0 8h
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 8h linuxptp-daemon-k8n88 3/3 Running 0 8hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,访问所需的消费者端的
cloud-event-proxy容器的指标:oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
$ oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
- <linuxptp-daemon>
指定您要查询的 pod,例如
linuxptp-daemon-2t78p。输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.5.8. 监控 PTP 快速事件指标 复制链接链接已复制到粘贴板!
您可以从运行 linuxptp-daemon 的集群节点监控 PTP 快速事件指标。您还可以使用预先配置和自我更新的 Prometheus 监控堆栈来监控 OpenShift Container Platform Web 控制台中的 PTP 快速事件指标。
先决条件
-
安装 OpenShift Container Platform CLI
oc。 -
以具有
cluster-admin特权的用户身份登录。 - 在具有 PTP 功能硬件的节点上安装和配置 PTP Operator。
流程
运行以下命令,为节点启动 debug pod:
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
linuxptp-daemon容器公开的 PTP 指标。例如,运行以下命令:curl http://localhost:9091/metrics
sh-4.4# curl http://localhost:9091/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选。您还可以在
cloud-event-proxy容器的日志中找到 PTP 事件。例如,运行以下命令:oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxyCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
要在 OpenShift Container Platform web 控制台中查看 PTP 事件,请复制您要查询的 PTP 指标的名称,如
openshift_ptp_offset_ns。 - 在 OpenShift Container Platform web 控制台中点 Observe → Metrics。
- 将 PTP 指标名称粘贴到 Expression 字段中,然后点 Run query。
15.5.9. PTP 快速事件指标参考 复制链接链接已复制到粘贴板!
下表描述了运行 linuxptp-daemon 服务的集群节点可用的 PTP 快速事件指标。
| 指标 | 描述 | Example |
|---|---|---|
|
|
返回接口的 PTP 时钟类。对于 PTP 时钟类的可能值为:6 ( |
|
|
|
返回接口的当前 PTP 时钟状态。PTP 时钟状态的可能值为 |
|
|
| 返回主时钟发送计时数据包和接收计时数据包之间的延迟(以纳秒为单位)。 |
|
|
|
当不同 NIC 上有多个时间源时,返回高可用性系统时钟的当前状态。可能的值为 0 ( |
|
|
|
以纳秒为单位返回 2 PTP 时钟之间的频率调整。例如,在上游时钟和 NIC 之间,系统时钟和 NIC 之间,或在 PTP 硬件时钟( |
|
|
|
返回为接口配置的 PTP 时钟角色。可能的值包括 0 ( |
|
|
|
返回 2 时钟或接口之间的最大偏移量(以纳秒为单位)。例如,在上游 GNSS 时钟和 NIC ( |
|
|
| 返回 DPLL 时钟或 GNSS 时钟源和 NIC 硬件时钟之间的偏移量。 |
|
|
|
返回 |
|
|
| 返回显示 PTP 进程是否正在运行的状态代码。 |
|
|
|
为
|
|
15.5.9.1. 只有在启用 T-GM 时,PTP 快速事件指标 复制链接链接已复制到粘贴板!
下表描述了仅在启用 PTP grandmaster 时钟 (T-GM) 时可用的 PTP 快速事件指标。
| 指标 | 描述 | Example |
|---|---|---|
|
|
返回 NIC 的数字阶段锁定循环(DPLL)频率的当前状态。可能的值为 -1 ( |
|
|
|
返回 NMEA 连接的当前状态。NMEA 是 1PPS NIC 连接使用的协议。可能的值有 0 ( |
|
|
|
返回 NIC 的 DPLL 阶段的状态。可能的值为 -1 ( |
|
|
|
返回 NIC 1PPS 连接的当前状态。您可以使用 1PPS 连接在连接的 NIC 之间同步计时。可能的值有 0 ( |
|
|
|
返回全局导航 Satellite 系统(GNSS)连接的当前状态。GNSS 在全局范围内提供基于 satellite 的位置、导航和计时服务。可能的值包括 0 ( |
|
15.6. PTP events REST API v1 参考 复制链接链接已复制到粘贴板!
使用以下 Precision Time Protocol (PTP) 快速事件 REST API v1 端点,将 cloud-event-consumer 应用程序订阅到 PTP 事件,由 cloud-event-proxy 容器发布,位于应用程序 pod 中的 http://localhost:8089/api/ocloudNotifications/v1/。
在以后的版本中,PTP 事件 REST API v1 将被弃用。在开发使用 PTP 事件的应用程序时,请使用 PTP 事件 REST API v2。
可用的 API 端点如下:
api/ocloudNotifications/v1/subscriptions-
POST:创建新订阅 -
GET:删除订阅列表 -
DELETE:删除所有订阅
-
api/ocloudNotifications/v1/subscriptions/{subscription_id}-
GET:返回指定订阅 ID 的详情 -
DELETE:删除与指定订阅 ID 关联的订阅
-
api/ocloudNotifications/v1/health-
GET:返回ocloudNotificationsAPI 的健康状况
-
api/ocloudNotifications/v1/publishers-
GET:返回集群节点的 PTP 事件发布程序列表
-
api/ocloudnotifications/v1/{resource_address}/CurrentState-
GET:返回以下事件类型的当前状态:sync-state,os-clock-sync-state,clock-class,lock-state, 或gnss-sync-status事件
-
15.6.1. PTP 事件 REST API v1 端点 复制链接链接已复制到粘贴板!
15.6.1.1. api/ocloudNotifications/v1/subscriptions 复制链接链接已复制到粘贴板!
HTTP 方法
GET api/ocloudNotifications/v1/subscriptions
描述
返回订阅列表。如果订阅存在,则返回 200 OK 状态代码以及订阅列表。
API 响应示例
HTTP 方法
POST api/ocloudNotifications/v1/subscriptions
描述
通过传递适当的有效负载来为所需的事件创建新订阅。如果订阅成功创建,或者已存在,则返回 201 Created 状态代码。您可以订阅以下 PTP 事件:
-
lock-state事件 -
os-clock-sync-state事件 -
clock-class事件 -
gnss-sync-status事件 -
sync-state事件
| 参数 | 类型 |
|---|---|
| subscription | data |
PTP 事件订阅有效负载示例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/compute-1.example.com/ptp"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/compute-1.example.com/ptp"
}
PTP lock-state 事件订阅有效负载示例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
PTP os-clock-sync-state 事件订阅有效负载示例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
PTP clock-class 事件订阅有效负载示例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
PTP gnss-sync-status 事件订阅有效负载示例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
sync-state 订阅有效负载示例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
HTTP 方法
DELETE api/ocloudNotifications/v1/subscriptions
描述
删除所有订阅。
API 响应示例
{
"status": "deleted all subscriptions"
}
{
"status": "deleted all subscriptions"
}
HTTP 方法
GET api/ocloudNotifications/v1/subscriptions/{subscription_id}
描述
返回 ID 为 subscription_id 的订阅详情。
| 参数 | 类型 |
|---|---|
|
| string |
API 响应示例
HTTP 方法
DELETE api/ocloudNotifications/v1/subscriptions/{subscription_id}
描述
使用 ID subscription_id 删除订阅。
| 参数 | 类型 |
|---|---|
|
| string |
API 响应示例
{
"status": "OK"
}
{
"status": "OK"
}
15.6.1.3. api/ocloudNotifications/v1/health 复制链接链接已复制到粘贴板!
HTTP 方法
GET api/ocloudNotifications/v1/health/
描述
返回 ocloudNotifications REST API 的健康状况。
API 响应示例
OK
OK
15.6.1.4. api/ocloudNotifications/v1/publishers 复制链接链接已复制到粘贴板!
api/ocloudNotifications/v1/publishers 端点仅对于 PTP Operator 管理的 pod 中的 cloud-event-proxy 容器可用。它对于应用程序 Pod 中的消费者应用程序不可用。
HTTP 方法
GET api/ocloudNotifications/v1/publishers
描述
返回集群节点的发布者详情列表。当相关的设备状态改变时,系统会生成通知。
您可以组合使用设备同步状态订阅,以提供有关系统总体同步健康状况的详细视图。
API 响应示例
HTTP 方法
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/ptp-status/lock-state/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/ptp-status/clock-class/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/sync-status/sync-state/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/gnss-status/gnss-sync-state/CurrentState
描述
返回集群节点的 os-clock-sync-state,clock-class,lock-state,gnss-sync-status, 或 sync-state 事件的当前状态。
-
os-clock-sync-state通知描述了主机操作系统时钟同步状态。可以是LOCKED或FREERUN状态。 -
clock-class通知描述了 PTP 时钟类的当前状态。 -
lock-state通知描述了 PTP 设备锁定状态的当前状态。可以处于LOCKED、HOLDOVER或FREERUN状态。 -
sync-state通知描述了至少ptp-status/lock-state和sync-status/os-clock-sync-state端点同步的当前状态。 -
GNSS-sync-status通知描述了 GNSS 时钟同步状态。
| 参数 | 类型 |
|---|---|
|
| string |
lock-state API 响应示例
os-clock-sync-state API 响应示例
clock-class API 响应示例
sync-state API 响应示例
gnss-sync-status API 响应示例
第 16 章 CIDR 范围定义 复制链接链接已复制到粘贴板!
如果您的集群使用 OVN-Kubernetes,您必须为无类别域间路由(CIDR)子网范围指定非重叠范围。
对于使用 OVN-Kubernetes 的集群,以下子网类型是强制的:
- Join :使用 join 交换将网关路由器连接到分布式路由器。join 交换减少了分布式路由器的 IP 地址数量。对于使用 OVN-Kubernetes 插件的集群,专用子网的 IP 地址都会被分配给附加到 join 交换的任何逻辑端口。
- Masquerade:在负载均衡器做出路由决策后,将从节点发送到同一节点的相同源和目标 IP 地址发生冲突。
- Transit :传输开关是跨集群中所有节点的分布式交换机类型。transit 交换会在不同区域间路由流量。对于使用 OVN-Kubernetes 插件的集群,专用子网的 IP 地址都会被分配给附加到 transit 交换的任何逻辑端口。
您可以将集群的加入和传输 CIDR 范围作为安装后任务更改。
OVN-Kubernetes 是 OpenShift Container Platform 4.14 及之后的版本中的默认网络供应商,内部使用以下 IP 地址子网范围:
-
V4JoinSubnet:100.64.0.0/16 -
V6JoinSubnet:fd98::/64 -
V4TransitSwitchSubnet:100.88.0.0/16 -
V6TransitSwitchSubnet:fd97::/64 -
defaultV4MasqueradeSubnet:169.254.169.0/29 -
defaultV6MasqueradeSubnet:fd69::/125
前面的列表包括 join、off 和 masquerade IPv4 和 IPv6 地址子网。如果您的集群使用 OVN-Kubernetes,请不要在集群或基础架构中的任何其他 CIDR 定义中包含这些 IP 地址子网范围。
16.1. Machine CIDR 复制链接链接已复制到粘贴板!
在 Machine classless inter-domain routing (CIDR) 字段中,您必须为机器或集群节点指定 IP 地址范围。
您无法在创建集群后更改 Machine CIDR 范围。
默认值为 10.0.0.0/16。这个范围不得与任何连接的网络冲突。
16.2. Service CIDR 复制链接链接已复制到粘贴板!
在 Service CIDR 字段中,您必须为服务指定 IP 地址范围。范围必须足够大,以适应您的工作负载。该地址块不得与从集群内部访问的任何外部服务重叠。默认为 172.30.0.0/16。
16.3. Pod CIDR 复制链接链接已复制到粘贴板!
在 pod CIDR 字段中,您必须为 pod 指定 IP 地址范围。
pod CIDR 与 clusterNetwork CIDR 和集群 CIDR 相同。范围必须足够大,以适应您的工作负载。该地址块不得与从集群内部访问的任何外部服务重叠。默认为 10.128.0.0/14。您可以在集群安装后扩展范围。
16.4. 主机前缀 复制链接链接已复制到粘贴板!
在 hostPrefix 参数中,您必须指定分配给调度到各个机器的 pod 的子网前缀长度。主机前缀决定了每台机器的 pod IP 地址池。
例如,如果主机前缀设置为 /23,则每台机器从 pod CIDR 地址范围中分配一个 /23 子网。默认值为 /23,允许 510 集群节点,以及每个节点的 510 个 pod IP 地址。
考虑将 clusterNetwork.cidr 参数设置为 10.128.0.0/16 的另一个示例,您要为集群定义完整的地址空间。这会为集群分配 65536 IP 地址池。然后,如果您将 hostPrefix 参数设置为 /23,则会为集群中的每个节点定义一个子网片段,其中 /23 片段成为 /16 子网网络的子网。这会为每个节点分配 512 个 IP 地址,其中 2 个 IP 地址被保留用于网络和广播目的。以下示例计算使用这些 IP 地址图来确定您可以为集群创建的最大节点数:
65536 / 512 = 128
65536 / 512 = 128
您可以使用 Red Hat OpenShift Network Calculator 计算集群的最大节点数。
第 17 章 多网络 复制链接链接已复制到粘贴板!
17.1. 了解多网络 复制链接链接已复制到粘贴板!
在 Kubernetes 中,容器网络被委派给实现 Container Network Interface (CNI) 的网络插件。
OpenShift Container Platform 使用 Multus CNI 插件来串联 CNI 插件。在集群安装过程中,您要配置 default pod 网络。默认网络处理集群中的所有一般网络流量。您可以基于可用的 CNI 插件定义额外网络,并将一个或多个此类网络附加到 pod。您可以根据需要为集群定义多个额外网络。这可让您灵活地配置提供交换或路由等网络功能的 pod。
17.1.1. 额外网络使用场景 复制链接链接已复制到粘贴板!
您可以在需要网络隔离的情况下使用额外网络,包括分离数据平面与控制平面。隔离网络流量对以下性能和安全性原因很有用:
- 性能
- 您可以在两个不同的平面上发送流量,以管理每个平面上流量的多少。
- 安全性
- 您可以将敏感的流量发送到专为安全考虑而管理的网络平面,也可隔离不能在租户或客户间共享的私密数据。
集群中的所有 pod 仍然使用集群范围的默认网络,以维持整个集群中的连通性。每个 pod 都有一个 eth0 接口,附加到集群范围的 pod 网络。您可以使用 oc exec -it <pod_name> -- ip a 命令来查看 pod 的接口。如果您添加使用 Multus CNI 的额外网络接口,则名称为 net1、net2、…、netN。
要将额外网络接口附加到 pod,您必须创建配置来定义接口的附加方式。您可以使用 NetworkAttachmentDefinition 自定义资源(CR)来指定各个接口。各个 CR 中的 CNI 配置定义如何创建该接口。
17.1.2. OpenShift Container Platform 中的额外网络 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供以下 CNI 插件,以便在集群中创建额外网络:
- bridge :配置基于网桥的额外网络,以允许同一主机上的 pod 相互通信,并与主机通信。
- bond-cni :配置 Bond CNI 二级网络,以提供将多个网络接口聚合成一个逻辑 绑定接口 的方法。
- host-device:配置 host-device 额外网络,以允许 pod 访问主机系统上的物理以太网网络设备。
- ipvlan :配置基于 ipvlan 的额外网络,以允许主机上的 Pod 与其他主机和那些主机上的 pod 通信,这类似于基于 macvlan 的额外网络。与基于 macvlan 的额外网络不同,每个 pod 共享与父级物理网络接口相同的 MAC 地址。
- vlan :配置基于 vlan 的额外网络,以为 pod 启用基于 VLAN 的网络隔离和连接。
- macvlan:配置基于 macvlan 的额外网络,以允许主机上的 Pod 通过使用物理网络接口与其他主机和那些主机上的 Pod 通信。附加到基于 macvlan 的额外网络的每个 pod 都会获得一个唯一的 MAC 地址。
- tap :配置基于 tap 的额外网络,以在容器命名空间内创建 tap 设备。tap 设备可让用户空间程序发送和接收网络数据包。
- SR-IOV :配置基于 SR-IOV 的额外网络,以允许 pod 附加到主机系统上支持 SR-IOV 的硬件的虚拟功能(VF)接口。
-
route-override: 基于额外的网络配置一个
route-override来允许 pod 覆盖和设置路由。
17.2. 配置额外网络 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为集群配置额外网络。支持以下网络类型:
17.2.1. 管理额外网络的方法 复制链接链接已复制到粘贴板!
您可以使用两种方法之一管理 OpenShift Container Platform 中额外网络的生命周期:修改 Cluster Network Operator (CNO) 配置或应用 YAML 清单。每种方法都是相互排斥的,您一次只能使用一种方法来管理额外网络。对于任一方法,额外网络由您配置的 Container Network Interface(CNI)插件管理。以下是两个不同的方法:
-
修改 Cluster Network Operator (CNO) 配置:只有集群管理员可以通过 CNO 配置额外网络。CNO 会自动创建和管理
NetworkAttachmentDefinition对象。通过使用这种方法,您可以在安装时通过配置install-config来定义NetworkAttachmentDefinition对象。 -
应用 YAML 清单:您可以通过创建
NetworkAttachmentDefinition对象直接管理额外网络。与修改 CNO 配置相比,这种方法为您提供了在涉及配置时更精细的控制和灵活性。
当使用 OVN Kubernetes 在 Red Hat OpenStack Platform (RHOSP) 中使用多个网络接口部署 OpenShift Container Platform 节点时,二级接口的 DNS 配置可能会优先于主接口的 DNS 配置。在这种情况下,删除附加到二级接口的子网 ID 的 DNS 名称服务器:
openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
$ openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
17.2.2. 额外网络的 IP 地址分配 复制链接链接已复制到粘贴板!
对于额外网络,可以使用 IP 地址管理(IPAM) CNI 插件来分配 IP 地址,该插件支持各种分配方法,包括动态主机配置协议(DHCP)和静态分配。
负责动态分配 IP 地址的 DHCP IPAM CNI 插件与两个不同的组件一起运行:
- CNI 插件 :负责与 Kubernetes 网络堆栈集成,以请求和释放 IP 地址。
- DHCP IPAM CNI 守护进程 :用于 DHCP 事件的监听程序,该事件与环境中的现有 DHCP 服务器协调,以处理 IP 地址分配请求。这个守护进程并不是 DHCP 服务器本身。
对于在 IPAM 配置中需要 type: dhcp 的网络,请确保以下内容:
- DHCP 服务器可用并在环境中运行。DHCP 服务器是集群外部的,应该成为客户的现有网络基础架构的一部分。
- DHCP 服务器被正确配置为为节点提供 IP 地址。
如果环境中 DHCP 服务器不可用,建议使用 Whereabouts IPAM CNI 插件。Whereabouts CNI 提供类似的 IP 地址管理功能,而无需外部 DHCP 服务器。
当没有外部 DHCP 服务器或首选静态 IP 地址管理时,请使用 Whereabouts CNI 插件。Whereabouts 插件包含一个协调器守护进程来管理过时的 IP 地址分配。
在整个容器生命周期中,必须定期更新 DHCP 租期,因此需要单独的守护进程 DHCP IPAM CNI 守护进程。要部署 DHCP IPAM CNI 守护进程,请修改 Cluster Network Operator (CNO)配置,以触发此守护进程的部署,作为额外网络设置的一部分。
17.2.3. 配置额外网络附加 复制链接链接已复制到粘贴板!
额外网络通过使用 k8s.cni.cncf.io API 组中的 NetworkAttachmentDefinition API 来配置。
不要将任何敏感信息或 secret 存储在 NetworkAttachmentDefinition CRD 中,因为此信息可以被项目管理用户访问。
下表中描述了 API 的配置:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 额外网络的名称。 |
|
|
| 与对象关联的命名空间。 |
|
|
| JSON 格式的 CNI 插件配置。 |
17.2.3.1. 通过 Cluster Network Operator 配置额外网络 复制链接链接已复制到粘贴板!
额外网络附加的配置作为 Cluster Network Operator(CNO)配置的一部分被指定。
以下 YAML 描述了使用 CNO 管理额外网络的配置参数:
Cluster Network Operator 配置
17.2.3.2. 从 YAML 清单配置额外网络 复制链接链接已复制到粘贴板!
从 YAML 配置文件指定额外网络的配置,如下例所示:
17.2.4. 额外网络类型的配置 复制链接链接已复制到粘贴板!
以下部分介绍了额外网络的具体配置字段。
17.2.4.1. 配置桥接额外网络 复制链接链接已复制到粘贴板!
bridge CNI 插件 JSON 配置对象描述了 Bridge CNI 插件的配置参数。下表详细介绍了这些参数:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
|
用于配置的 CNI 插件的名称: |
|
|
| IPAM CNI 插件的配置对象。该插件管理附加定义的 IP 地址分配。 |
|
|
|
可选:指定要使用的虚拟网桥名称。如果主机上不存在网桥接口,则会创建网桥接口。默认值为 |
|
|
|
可选:设置为 |
|
|
|
可选:设置为 |
|
|
|
可选:设置为 |
|
|
|
可选:设置为 |
|
|
|
可选:设置为 |
|
|
|
可选:设置为 |
|
|
| 可选:指定一个虚拟 LAN (VLAN) 标签作为整数值。默认情况下不分配 VLAN 标签。 |
|
|
|
可选:指示在连接到网桥的 |
|
|
|
可选:分配 VLAN 中继标签。默认值为 |
|
|
| 可选:将最大传输单元 (MTU) 设置为指定的值。默认值由内核自动设置。 |
|
|
|
可选:为容器侧 |
|
|
|
可选:启用 mac spoof 检查,将来自容器的流量限制为接口的 mac 地址。默认值为 |
VLAN 参数在 veth 的主机端配置 VLAN 标签,并在网桥接口上启用 vlan_filtering 功能。
要为 L2 网络配置 uplink,您必须使用以下命令在 uplink 接口上允许 VLAN:
bridge vlan add vid VLAN_ID dev DEV
$ bridge vlan add vid VLAN_ID dev DEV
17.2.4.1.1. Bridge CNI 插件配置示例 复制链接链接已复制到粘贴板!
以下示例配置了名为 bridge-net 的额外网络:
17.2.4.2. 主机设备额外网络配置 复制链接链接已复制到粘贴板!
主机 device CNI 插件 JSON 配置对象描述了 host-device CNI 插件的配置参数。
仅设置以下参数之一来指定您的网络设备:device、hwaddr、kernelpath 或 pciBusID。
下表详细介绍了配置参数:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
|
用于配置的 CNI 插件的名称: |
|
|
|
可选:设备的名称,如 |
|
|
| 可选:设备硬件 MAC 地址。 |
|
|
|
可选:Linux 内核设备路径,如 |
|
|
|
可选:网络设备的 PCI 地址,如 |
17.2.4.2.1. host-device 配置示例 复制链接链接已复制到粘贴板!
以下示例配置了名为 hostdev-net 的额外网络:
17.2.4.3. 配置 Bond CNI 二级网络 复制链接链接已复制到粘贴板!
Bond Container Network Interface (Bond CNI)允许将多个网络接口聚合到一个逻辑绑定接口中,从而增强网络冗余和容错。只有 SR-IOV 虚拟功能(VF)支持使用此插件绑定。
下表描述了 Bond CNI 插件的配置参数:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定提供给此 CNI 网络附加定义的名称。此名称用于识别和引用容器内的接口。 |
|
|
| CNI 规格版本。 |
|
|
|
指定要配置的 CNI 插件的名称: |
|
|
| 以毫秒为单位指定地址解析协议(ARP)链路监控频率。此参数定义绑定接口发送 ARP 请求的频率,以检查其聚合接口的可用性。 |
|
|
|
可选:指定绑定的最大传输单元(MTU)。默认值为 |
|
|
|
可选:指定绑定的 |
|
|
| 指定绑定策略。 |
|
|
|
可选:指定是否应在绑定启动时直接在容器网络命名空间内创建用于绑定的网络接口。如果为 |
|
|
| 指定要绑定的接口。 |
|
|
| IPAM CNI 插件的配置对象。该插件管理附加定义的 IP 地址分配。 |
17.2.4.3.1. bond CNI 插件配置示例 复制链接链接已复制到粘贴板!
以下示例配置了一个名为 bond-net1 的二级网络:
17.2.4.4. 配置 VLAN 额外网络 复制链接链接已复制到粘贴板!
VLAN CNI 插件 JSON 配置对象描述了 VLAN 的配置参数 vlan, CNI 插件。下表详细介绍了这些参数:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
|
要配置的 CNI 插件的名称: |
|
|
|
与网络附加关联的以太网接口。如果没有指定 |
|
|
|
设置 |
|
|
| IPAM CNI 插件的配置对象。该插件管理附加定义的 IP 地址分配。 |
|
|
| 可选:将最大传输单元 (MTU) 设置为指定的值。默认值由内核自动设置。 |
|
|
| 可选:要返回的 DNS 信息。例如,优先排序的 DNS 名称服务器列表。 |
|
|
|
可选:指定 |
具有 vlan 配置的 NetworkAttachmentDefinition 自定义资源定义(CRD)只能在节点上的单个 pod 上使用,因为 CNI 插件无法在同一 主接口上创建多个 vlanId 的 vlan 子接口。
17.2.4.4.1. VLAN 配置示例 复制链接链接已复制到粘贴板!
以下示例演示了一个 vlan 配置,它带有一个名为 vlan-net 的额外网络:
-
ipam.type.host-local:从指定的一组地址范围分配 IPv4 和 IPv6 IP 地址。IPAM 插件将 IP 地址存储在主机文件系统中本地,以便地址保持与主机是唯一的。
17.2.4.5. 配置 IPVLAN 额外网络 复制链接链接已复制到粘贴板!
IPVLAN CNI 插件 JSON 配置对象描述了 IPVLAN、ipvlan、CNI 插件的配置参数。下表详细介绍了这些参数:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
|
要配置的 CNI 插件的名称: |
|
|
| IPAM CNI 插件的配置对象。该插件管理附加定义的 IP 地址分配。除非插件被串联,否则需要此项。 |
|
|
|
可选:虚拟网络的操作模式。这个值必须是 |
|
|
|
可选:与网络附加关联的以太网接口。如果没有指定 |
|
|
| 可选:将最大传输单元 (MTU) 设置为指定的值。默认值由内核自动设置。 |
|
|
|
可选:指定 |
-
ipvlan对象不允许虚拟接口与master接口通信。因此,容器无法使用ipvlan接口来访问主机。确保容器加入提供主机连接的网络,如支持 Precision Time Protocol (PTP) 的网络。 -
单个
master接口无法同时配置为使用macvlan和ipvlan。 -
对于不能与接口无关的 IP 分配方案,可以使用处理此逻辑的较早插件来串联
ipvlan插件。如果省略master,则前面的结果必须包含一个接口名称,以便ipvlan插件进行 enslave。如果省略ipam,则使用前面的结果来配置ipvlan接口。
17.2.4.5.1. IPVLAN CNI 插件配置示例 复制链接链接已复制到粘贴板!
以下示例配置了名为 ipvlan -net 的额外网络:
17.2.4.6. 配置 MACVLAN 额外网络 复制链接链接已复制到粘贴板!
MACVLAN CNI 插件 JSON 配置对象描述了 MAC Virtual LAN (MACVLAN) Container Network Interface (CNI) 插件的配置参数。下表描述了这些参数:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
|
用于配置的 CNI 插件的名称: |
|
|
| IPAM CNI 插件的配置对象。该插件管理附加定义的 IP 地址分配。 |
|
|
|
可选:配置虚拟网络上的流量可见性。必须是 |
|
|
| 可选:与新创建的 macvlan 接口关联的主机网络接口。如果没有指定值,则使用默认路由接口。 |
|
|
| 可选:将最大传输单元 (MTU) 到指定的值。默认值由内核自动设置。 |
|
|
|
可选:指定 |
如果您为插件配置指定 master key,请使用与主网络插件关联的物理网络接口,以避免可能冲突。
17.2.4.6.1. MACVLAN CNI 插件配置示例 复制链接链接已复制到粘贴板!
以下示例配置了名为 macvlan-net 的额外网络:
17.2.4.7. 配置 TAP 额外网络 复制链接链接已复制到粘贴板!
TAP CNI 插件 JSON 配置对象描述了 TAP CNI 插件的配置参数。下表描述了这些参数:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
|
要配置的 CNI 插件的名称: |
|
|
| 可选:为接口请求指定的 MAC 地址。 |
|
|
| 可选:将最大传输单元 (MTU) 设置为指定的值。默认值由内核自动设置。 |
|
|
| 可选:与 tap 设备关联的 SELinux 上下文。 注意
OpenShift Container Platform 需要 |
|
|
|
可选:设置为 |
|
|
| 可选:拥有 tap 设备的用户。 |
|
|
| 可选:拥有 tap 设备的组。 |
|
|
| 可选:将 tap 设备设置为已存在的网桥的端口。 |
17.2.4.7.1. tap 配置示例 复制链接链接已复制到粘贴板!
以下示例配置了名为 mynet 的额外网络:
17.2.4.8. 在额外网络中使用 route-override 插件配置路由 复制链接链接已复制到粘贴板!
Route override CNI 插件 JSON 配置对象描述了 route-override CNI 插件的配置参数。下表详细介绍了这些参数:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
要配置的 CNI 插件的名称: |
|
|
|
可选:设置为 |
|
|
|
可选:设置为 |
|
|
| 可选:指定要从容器命名空间中删除的路由列表。 |
|
|
|
可选:指定要添加到容器命名空间的路由列表。每个路由都是带有 |
|
|
|
可选:将其设置为 |
17.2.4.8.1. route-override 插件配置示例 复制链接链接已复制到粘贴板!
route-override CNI 是 CNI 类型,旨在与父 CNI 串联时使用。CNI 类型不独立运行,它依赖于父 CNI 首先创建网络接口,并在 CNI 类型可以修改路由规则前分配 IP 地址。
以下示例配置了一个名为 mymacvlan 的二级网络。父 CNI 创建一个附加到 eth1 的网络接口,并使用 host-local IPAM 在 192.168.1.0/24 范围内分配一个 IP 地址。然后,route-override CNI 链接到父 CNI,并通过清除现有路由来修改路由规则,删除到 192.168.0.0/24 的路由,并使用自定义网关为 192.168.0.0/24 添加新路由。
其中:
"type": "macvlan"-
父 CNI 创建一个附加到
eth1的网络接口。 "type": "route-override"-
串联的
route-overrideCNI 会修改路由规则。
17.2.4.9. 配置 OVN-Kubernetes 额外网络 复制链接链接已复制到粘贴板!
Red Hat OpenShift Networking OVN-Kubernetes 网络插件允许为 pod 配置二级网络接口。要配置二级网络接口,您必须在 NetworkAttachmentDefinition 自定义资源定义 (CRD)中定义配置。
Pod 和多网络策略创建可能会处于待处理状态,直到节点的 OVN-Kubernetes control plane 代理处理了关联的 network-attachment-definition CRD。
您可以在 第 2 层 或 localnet 拓扑中配置 OVN-Kubernetes 额外网络。
- 第 2 层拓扑支持 east-west 集群流量,但不允许访问底层物理网络。
- localnet 拓扑允许连接到物理网络,但需要在集群节点上进行底层 Open vSwitch (OVS) 网桥的额外配置。
以下小节提供了 OVN-Kubernetes 当前允许从属网络的每个拓扑配置示例。
网络名称必须是唯一的。例如,不支持使用多个带有不同配置的 NetworkAttachmentDefinition CRD。
17.2.4.9.1. OVN-Kubernetes 额外网络支持的平台 复制链接链接已复制到粘贴板!
您可以使用以下支持的平台使用 OVN-Kubernetes 额外网络:
- 裸机
- IBM Power®
- IBM Z®
- IBM® LinuxONE
- VMware vSphere
- Red Hat OpenStack Platform(RHOSP)
17.2.4.9.2. OVN-Kubernetes 网络插件 JSON 配置表 复制链接链接已复制到粘贴板!
OVN-Kubernetes 网络插件 JSON 配置对象描述了 OVN-Kubernetes CNI 网络插件的配置参数。下表详细介绍了这些参数:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。所需的值为 |
|
|
|
网络的名称。这些网络不是命名空间。例如,名为 |
|
|
|
用于配置的 CNI 插件的名称。这个值必须设置为 |
|
|
|
网络的拓扑配置。必须是 |
|
|
| 用于集群间的网络的子网。
对于 在省略时,实现网络的逻辑交换机仅提供第 2 层通信,用户必须为 pod 配置 IP 地址。端口安全只阻止 MAC 欺骗。 |
|
|
| 最大传输单元 (MTU)。如果没有设置值,Cluster Network Operator (CNO)通过计算主网络接口中的 underlay MTU 的不同来设置默认的 MTU 值,如 pod 网络的 overlay MTU,如 Geneve (Generic Network Virtualization Encapsulation),以及任何启用的功能(如 IPsec)的字节容量。 |
|
|
|
包含此配置的网络附加定义 CRD 的元数据 |
|
|
| 以逗号分隔的 CIDR 和 IP 地址列表。IP 地址从可分配的 IP 地址池中删除,永远不会传递给 pod。 |
|
|
|
如果拓扑设置为 |
17.2.4.9.3. 与多网络策略兼容 复制链接链接已复制到粘贴板!
在定义网络策略时,可以使用的网络策略规则取决于 OVN-Kubernetes 二级网络是否定义了 subnets 字段。
多网络策略 API 由 k8s.cni.cncf.io API 组中的 MultiNetworkPolicy 自定义资源定义(CRD) 提供,与 OVN-Kubernetes 二级网络兼容。
请参考下表,其中详细介绍了基于 subnets CNI 配置支持的多网络策略选择器:
指定的 subnets 字段 | 允许多网络策略选择器 |
|---|---|
| 是 |
|
| 否 |
|
您可以使用 MultiNetworkPolicy 对象上的 k8s.v1.cni.cncf.io/policy-for 注解指向 NetworkAttachmentDefinition (NAD) 自定义资源(CR)。NAD CR 定义策略应用到的网络。只有在名为 blue2 的二级网络定义了 subnets 字段时,使用 pod 选择器的多网络策略示例才有效:
以下示例使用 ipBlock 网络多网络策略,该策略始终对 OVN-Kubernetes 二级网络有效:
使用 IP 块选择器的多网络策略示例
17.2.4.9.4. 配置第 2 层切换拓扑 复制链接链接已复制到粘贴板!
交换机(层 2)拓扑网络通过集群范围的逻辑交换机互连工作负载。此配置可用于 IPv6 和双栈部署。
第 2 层切换拓扑网络只允许在集群中的 pod 间传输数据数据包。
以下 JSON 示例配置交换的二级网络:
17.2.4.10. 配置 OVN-Kubernetes 额外网络的先决条件 复制链接链接已复制到粘贴板!
- 已安装 NMState Operator。如需更多信息,请参阅 Kubernetes NMState Operator。
17.2.4.11. 配置 OVN-Kubernetes 额外网络映射 复制链接链接已复制到粘贴板!
17.2.4.12. localnet 交换拓扑的配置 复制链接链接已复制到粘贴板!
交换的 localnet 拓扑通过集群范围的逻辑切换到物理网络来连接作为网络附加定义 (NAD) 创建的工作负载。
您必须将二级网络映射到 OVS 网桥,以将其用作 OVN-Kubernetes 二级网络。网桥映射允许网络流量访问物理网络。网桥映射将物理网络名称(也称为接口标签)与通过 Open vSwitch (OVS)创建的网桥相关联。
您可以创建一个 NodeNetworkConfigurationPolicy (NNCP) 对象( nmstate.io/v1 API 组的一部分),以声明性地创建映射。此 API 由 NMState Operator 提供。通过使用此 API,您可以将网桥映射应用到与指定 nodeSelector 表达式匹配的节点,如 node-role.kubernetes.io/worker: ''。使用这个声明方法,NMState Operator 会自动和透明地将额外网络配置应用到节点选择器指定的所有节点。
在附加额外网络时,您可以使用现有的 br-ex 网桥或创建新网桥。使用哪种方法取决于您的特定网络基础架构。请考虑以下方法:
-
如果您的节点只包含一个网络接口,则必须使用现有的网桥。这个网络接口由 OVN-Kubernetes 拥有和管理,不得从
br-ex网桥中删除它,或更改接口配置。如果您删除或更改网络接口,您的集群网络将停止工作。 - 如果您的节点包含多个网络接口,您可以将不同的网络接口附加到新网桥,并将该网络接口用于二级网络。这种方法可用于从主集群网络进行流量隔离。
localnet1 网络映射到以下 shared-a-bridge 示例中的 br-ex 网桥:
其中:
name- 配置对象的名称。
node-role.kubernetes.io/worker- 节点选择器指定要将节点网络配置策略应用到的节点。
localnet-
流量转发到 OVS 网桥的二级网络的名称。此二级网络必须与定义 OVN-Kubernetes 额外网络的
NetworkAttachmentDefinitionCRD 的spec.config.name字段的名称匹配。 bridge-
节点上的 OVS 网桥的名称。只有在指定
state: present时,才需要这个值。 state-
映射的状态。需要是
present(添加网桥)或absent(删除网桥)。默认值存在。
以下 JSON 示例配置了一个名为 localnet1 的 localnet 二级网络。请注意,mtu 参数的值必须与映射到 br-ex 网桥接口的二级网络接口设置的 MTU 值匹配。
在下列多个接口示例中,localnet2 网络接口连接到 ovs-br1 网桥。通过此附加,网络接口作为二级网络可用于 OVN-Kubernetes 网络插件。
其中:
name- 指定配置对象的名称。
node-role.kubernetes.io/worker- 指定用于标识节点网络配置策略应用到的节点的节点选择器。
interfaces.name- 指定一个新的 OVS 网桥,与 OVN-Kubernetes 用于集群流量的默认网桥分开运行。
mcast-snooping-enable-
指定是否启用多播侦听。启用后,多播侦听可防止网络设备向所有网络成员填充多播流量。默认情况下,OVS 网桥不启用多播侦听。默认值为
false。 `port.name- 指定主机系统上要与新的 OVS 网桥关联的网络设备。
bridge-mappings.localnet-
指定将流量转发到 OVS 网桥的二级网络的名称。此名称必须与定义 OVN-Kubernetes 二级网络的
NetworkAttachmentDefinitionCRD 中的spec.config.name字段的值匹配。 bridge-mappings.bridge-
指定节点上的 OVS 网桥的名称。只有在设置了
state: present时,才需要该值。 bridge-mappings.state-
指定映射的状态。有效的值是
present- 添加网桥;或absent- 删除网桥。默认值存在。
以下 JSON 示例配置了一个名为 localnet2 的 localnet 二级网络:请注意,mtu 参数的值必须与为 eth1 二级网络接口设置的 MTU 值匹配。
17.2.4.12.1. 为额外网络配置 pod 复制链接链接已复制到粘贴板!
您必须通过 k8s.v1.cni.cncf.io/networks 注解来指定二级网络附加。
以下示例置备有两个二级附件的 pod,一个用于本指南中提供的每个附加配置:
17.2.4.12.2. 使用静态 IP 地址配置 pod 复制链接链接已复制到粘贴板!
您可以使用静态 IP 地址配置 pod。该流程中的示例使用静态 IP 地址置备 pod。
- 您只能为第 2 层附加指定 pod 的从属网络附加的 IP 地址。
- 只有在附加配置没有功能子网时,才能为 pod 指定静态 IP 地址。
其中:
k8s.v1.cni.cncf.io/networks.name-
网络的名称。这个值在所有
NetworkAttachmentDefinitionCRD 之间必须是唯一的。 k8s.v1.cni.cncf.io/networks.mac- 为接口分配的 MAC 地址。
k8s.v1.cni.cncf.io/networks.interface- 为 pod 创建的网络接口的名称。
k8s.v1.cni.cncf.io/networks.ips- 要分配给网络接口的 IP 地址。
17.2.5. 配置网络附加的 IP 地址分配 复制链接链接已复制到粘贴板!
对于二级网络,可以使用 IP 地址管理 (IPAM) CNI 插件来分配 IP 地址,该插件支持多种分配方法,包括动态主机配置协议 (DHCP) 和静态分配。
您可以使用以下 IP 地址分配类型:
- 静态分配。
- 通过 DHCP 服务器进行动态分配。您指定的 DHCP 服务器必须可从额外网络访问。
- 通过 Whereabouts IPAM CNI 插件进行动态分配。
17.2.5.1. 静态 IP 地址分配配置 复制链接链接已复制到粘贴板!
下表描述了静态 IP 地址分配的配置:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值必须是 |
|
|
| 指定分配给虚拟接口的 IP 地址的对象数组。支持 IPv4 和 IPv6 IP 地址。 |
|
|
| 指定要在 pod 中配置的路由的一组对象。 |
|
|
| 可选:指定 DNS 配置的对象数组。 |
address 数组需要带有以下字段的对象:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
您指定的 IP 地址和网络前缀。例如,如果您指定了 |
|
|
| 出口网络流量要路由到的默认网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CIDR 格式的 IP 地址范围,如 |
|
|
| 路由网络流量的网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 发送 DNS 查询的一个或多个 IP 地址的数组。 |
|
|
|
要附加到主机名的默认域。例如,如果将域设置为 |
|
|
|
在 DNS 查找查询过程中,附加到非限定主机名(如 |
静态 IP 地址分配配置示例
17.2.5.2. 动态 IP 地址(DHCP)分配配置 复制链接链接已复制到粘贴板!
pod 在创建时获取其原始 DHCP 租期。该租期必须由集群中运行的一个小型的 DHCP 服务器部署定期续订。
对于以太网网络附加,SR-IOV Network Operator 不会创建 DHCP 服务器部署。Cluster Network Operator 负责创建最小 DHCP 服务器部署。
要触发 DHCP 服务器的部署,您必须编辑 Cluster Network Operator 配置来创建 shim 网络附加,如下例所示:
shim 网络附加定义示例
其中:
type- 为集群指定动态 IP 地址分配。
下表描述了使用 DHCP 进行动态 IP 地址地址分配的配置参数。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。需要值 |
以下 JSON 示例描述了使用 DHCP 进行动态 IP 地址地址分配的配置 p。
动态 IP 地址(DHCP)分配配置示例
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
17.2.5.3. 使用 Whereabouts 进行动态 IP 地址分配配置 复制链接链接已复制到粘贴板!
Whereabouts CNI 插件允许在不使用 DHCP 服务器的情况下动态地将 IP 地址分配给额外网络。
Whereabouts CNI 插件还支持在单独的 NetworkAttachmentDefinition CRD 中多次出现同一 CIDR 范围的重叠 IP 地址范围和配置。这在多租户环境中提供了更大的灵活性和管理功能。
17.2.5.3.1. 动态 IP 地址配置对象 复制链接链接已复制到粘贴板!
下表描述了使用 Whereabouts 进行动态 IP 地址分配的配置对象:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。需要 |
|
|
| CIDR 表示法中的 IP 地址和范围。IP 地址是通过这个地址范围来分配的。 |
|
|
| 可选: CIDR 标记中零个或更多 IP 地址和范围的列表。包含在排除地址范围中的 IP 地址。 |
|
|
| 可选:帮助确保每个 pod 的组或域都有自己的一组 IP 地址,即使它们共享相同的 IP 地址范围。设置此字段对于保持网络独立和组织非常重要,特别是在多租户环境中。 |
17.2.5.3.2. 使用 Whereabouts 的动态 IP 地址分配配置 复制链接链接已复制到粘贴板!
以下示例显示了使用 Whereabouts 的动态地址分配配置:
Whereabouts 动态 IP 地址分配
17.2.5.3.3. 使用 Whereabouts 带有重叠 IP 地址范围的动态 IP 地址分配 复制链接链接已复制到粘贴板!
以下示例显示了一个动态 IP 地址分配,它将重叠的 IP 地址范围用于多租户网络。
NetworkAttachmentDefinition 1
NetworkAttachmentDefinition 2
- 1
- 可选。如果设置,必须与
NetworkAttachmentDefinition 1的network_name匹配。
17.2.5.4. 创建abouts-reconciler 守护进程集的位置 复制链接链接已复制到粘贴板!
Whereabouts 协调器负责管理集群中 pod 的动态 IP 地址分配,使用 Whereabouts IP 地址管理 (IPAM) 解决方案。Whereabouts 协调器确保每个 pod 从指定的 IP 地址范围获得唯一的 IP 地址。Whereabouts 协调器也会在 pod 被删除或缩减时处理 IP 地址发行版本。
您还可以使用 NetworkAttachmentDefinition 自定义资源定义(CRD)进行动态 IP 地址分配。
当您通过 Cluster Network Operator 配置二级网络时,会自动创建 whereabouts-reconciler 守护进程。在从 YAML 清单配置二级网络时,Theabouts -reconciler DaemonSet 不会被自动创建。
要触发 whereabouts-reconciler 守护进程集的部署,您必须通过编辑 Cluster Network Operator 自定义资源文件来手动创建一个 whereabouts-shim 网络附加。
流程
运行以下命令来编辑
Network.operator.openshift.ioCR:oc edit network.operator.openshift.io cluster
$ oc edit network.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 CR 的
spec定义中包含此 YAML 示例中显示的additionalNetworks部分:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存文件并退出文本编辑器。
运行以下命令,验证
whereabouts-reconciler守护进程集是否已成功部署:oc get all -n openshift-multus | grep whereabouts-reconciler
$ oc get all -n openshift-multus | grep whereabouts-reconcilerCopy to Clipboard Copied! Toggle word wrap Toggle overflow pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s
pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.5.5. 配置 Whereabouts IP 协调器调度 复制链接链接已复制到粘贴板!
Whereabouts IPAM CNI 插件每天运行 IP 地址协调器。此过程会清理可能会导致 IP 地址耗尽的任何 IP 地址分配,从而防止新 pod 获取分配给它们的 IP 地址。
使用这个流程更改 IP 协调器运行的频率。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。 -
您已部署了
whereabouts-reconciler守护进程集,whereabouts-reconcilerpod 已启动并正在运行。
流程
运行以下命令,使用 IP 协调器的特定 cron 表达式在
openshift-multus命名空间中创建一个名为whereabouts-config的ConfigMap对象:oc create configmap whereabouts-config -n openshift-multus --from-literal=reconciler_cron_expression="*/15 * * * *"
$ oc create configmap whereabouts-config -n openshift-multus --from-literal=reconciler_cron_expression="*/15 * * * *"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此 cron 表达式表示 IP 协调器每 15 分钟运行一次。根据您的特定要求调整表达式。
注意whereabouts-reconciler守护进程集只能使用包含五个星号的 cron 表达式模式。红帽不支持第六个星号,它用于表示秒。运行以下命令,获取与
openshift-multus命名空间中的whereabouts-reconciler守护进程集和 pod 相关的资源信息。oc get all -n openshift-multus | grep whereabouts-reconciler
$ oc get all -n openshift-multus | grep whereabouts-reconcilerCopy to Clipboard Copied! Toggle word wrap Toggle overflow pod/whereabouts-reconciler-2p7hw 1/1 Running 0 4m14s pod/whereabouts-reconciler-76jk7 1/1 Running 0 4m14s daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 4m16s
pod/whereabouts-reconciler-2p7hw 1/1 Running 0 4m14s pod/whereabouts-reconciler-76jk7 1/1 Running 0 4m14s daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 4m16sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,以验证
whereabouts-reconcilerpod 是否运行带有配置的时间间隔的 IP 协调器:oc -n openshift-multus logs whereabouts-reconciler-2p7hw
$ oc -n openshift-multus logs whereabouts-reconciler-2p7hwCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.5.6. 为动态分配双栈 IP 地址创建配置 复制链接链接已复制到粘贴板!
您可以动态地将双栈 IP 地址分配给二级网络,以便 pod 可以通过 IPv4 和 IPv6 地址进行通信。
您可以在 ipRanges 参数中配置以下 IP 地址分配类型:
- IPv4 地址
- IPv6 地址
- 多个 IP 地址分配
流程
-
将
type设置为whereabouts。 使用
ipRanges来分配 IP 地址,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 将二级网络附加到 pod。如需更多信息,请参阅"将 pod 添加到二级网络"。
验证
输入以下命令验证所有 IP 地址是否已分配给 pod 命名空间内的网络接口:
$ oc exec -it <pod_name> -- ip a
$ oc exec -it <pod_name> -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<podname>- pod 的名称。
17.2.6. 使用 Cluster Network Operator 创建额外网络附加 复制链接链接已复制到粘贴板!
Cluster Network Operator (CNO) 管理额外网络定义。当您指定要创建的主网络时,CNO 会自动创建 NetworkAttachmentDefinition 自定义资源定义(CRD)。
请勿编辑 Cluster Network Operator 所管理的 NetworkAttachmentDefinition CRD。这样做可能会破坏额外网络上的网络流量。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
可选:为额外网络创建命名空间:
oc create namespace <namespace_name>
$ oc create namespace <namespace_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要编辑 CNO 配置,请输入以下命令:
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过为您要创建的额外网络添加配置来修改您要创建的 CR,如下例所示。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存您的更改,再退出文本编辑器以提交更改。
验证
运行以下命令确认 CNO 创建了
NetworkAttachmentDefinitionCRD。CNO 创建 CRD 之前可能会有延迟。预期输出显示 NAD CRD 的名称并创建期限(以分钟为单位)。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<namespace>- 指定添加到 CNO 配置中的网络附加的命名空间。
17.2.7. 通过应用 YAML 清单来创建额外网络附加 复制链接链接已复制到粘贴板!
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
使用额外网络配置创建 YAML 文件,如下例所示:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建额外网络:
oc apply -f <file>.yaml
$ oc apply -f <file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<file>- 指定包含 YAML 清单的文件名。
17.2.8. 关于在容器网络命名空间中配置 master 接口 复制链接链接已复制到粘贴板!
您可以创建一个基于容器命名空间中的 master 接口的 MAC-VLAN、IP-VLAN 或 VLAN 子接口。您还可以在单独的网络附加定义 CRD 中作为 pod 网络配置的一部分创建 master 接口。
要使用容器命名空间 master 接口,您必须为 NetworkAttachmentDefinition CRD 的子接口配置中存在的 linkInContainer 参数指定 true。
17.2.8.1. 在 SR-IOV VF 上创建多个 VLAN 复制链接链接已复制到粘贴板!
您可以根据 SR-IOV VF 创建多个 VLAN。对于此配置,创建一个 SR-IOV 网络,然后为 VLAN 接口定义网络附加。
下图显示了在 SR-IOV VF 上创建多个 VLAN 的设置过程。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。 - 已安装 SR-IOV Network Operator。
流程
使用以下命令,创建您要部署 pod 的专用容器命名空间:
oc new-project test-namespace
$ oc new-project test-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 SR-IOV 节点策略。
创建一个
SriovNetworkNodePolicy对象,然后在sriov-node-network-policy.yaml文件中保存 YAML:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
vendor-
SR-IOV 网络设备厂商的十六进制代码。值
15b3与 Mellanox NIC 关联。 deviceIDSR-IOV 网络设备的设备十六进制代码。
注意SR-IOV 网络节点策略配置示例,使用设置
deviceType: netdevice,专为 Mellanox 网络接口卡(NIC)量身定制。
运行以下命令来应用 YAML 配置:
oc apply -f sriov-node-network-policy.yaml
$ oc apply -f sriov-node-network-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意应用 YAML 配置可能需要一些时间,因为节点重启操作。
创建 SR-IOV 网络:
如以下示例 CR 所示,为额外的二级 SR-IOV 网络附加创建
SriovNetwork自定义资源(CR)。将 YAML 保存为sriov-network-attachment.yaml文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来应用 YAML:
oc apply -f sriov-network-attachment.yaml
$ oc apply -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 VLAN 二级网络。
使用以下 YAML 示例,创建一个名为
vlan100-additional-network-configuration.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
master-
VLAN 配置需要指定
master名称。您可以在 pod 的网络注解中指定名称。 linkInContainer-
必须指定
linkInContainer参数。
运行以下命令来应用 YAML 文件:
oc apply -f vlan100-additional-network-configuration.yaml
$ oc apply -f vlan100-additional-network-configuration.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
使用早期指定的网络创建 pod 定义。
使用以下 YAML 配置示例,创建名为
pod-a.yaml文件的文件:注意清单示例包括以下资源:
- 带有安全标签的命名空间
- 带有适当的网络注解的 Pod 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
interface-
用作 VLAN 接口
主接口的名称。
运行以下命令来应用 YAML 文件:
oc apply -f pod-a.yaml
$ oc apply -f pod-a.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令,在
test-namespace中获取nginx-pod的详细信息:oc describe pods nginx-pod -n test-namespace
$ oc describe pods nginx-pod -n test-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.8.2. 基于容器命名空间中的网桥主接口创建子接口 复制链接链接已复制到粘贴板!
您可以根据容器命名空间中的桥接 master 接口创建子接口。创建子接口可应用到其他类型的接口。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin权限的用户身份登录 OpenShift Container Platform 集群。
流程
输入以下命令,创建一个要部署 pod 的专用容器命名空间:
oc new-project test-namespace
$ oc new-project test-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下 YAML 配置示例,创建一个名为
bridge-nad.yaml的桥接NetworkAttachmentDefinition自定义资源定义(CRD)文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将
NetworkAttachmentDefinitionCRD 应用到 OpenShift Container Platform 集群:oc apply -f bridge-nad.yaml
$ oc apply -f bridge-nad.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令验证您是否已成功创建了
NetworkAttachmentDefinitionCRD。预期输出显示 NAD CRD 的名称并创建期限(以分钟为单位)。oc get network-attachment-definitions
$ oc get network-attachment-definitionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下 YAML 示例,为 IPVLAN 二级网络配置创建一个名为
ipvlan-additional-network-configuration.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
master- 指定要与网络附加关联的以太网接口。之后,以太网接口会在 pod 网络注解中配置。
linkInContainer-
指定容器网络命名空间中存在
master接口。
运行以下命令来应用 YAML 文件:
oc apply -f ipvlan-additional-network-configuration.yaml
$ oc apply -f ipvlan-additional-network-configuration.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证
NetworkAttachmentDefinitionCRD 是否已成功创建。预期输出显示 NAD CRD 的名称并创建期限(以分钟为单位)。oc get network-attachment-definitions
$ oc get network-attachment-definitionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下 YAML 配置示例,为 pod 定义创建一个名为
pod-a.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
k8s.v1.cni.cncf.io/networks,interface-
指定用作 IPVLAN 接口的
master的名称。
运行以下命令来应用 YAML 文件:
oc apply -f pod-a.yaml
$ oc apply -f pod-a.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
使用以下命令验证 pod 是否正在运行:
oc get pod -n test-namespace
$ oc get pod -n test-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow NAME READY STATUS RESTARTS AGE pod-a 1/1 Running 0 2m36s
NAME READY STATUS RESTARTS AGE pod-a 1/1 Running 0 2m36sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,显示
test-namespace中pod-a资源的网络接口信息:oc exec -n test-namespace pod-a -- ip a
$ oc exec -n test-namespace pod-a -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此输出显示网络接口
net2与物理接口net1关联。
17.3. 关于虚拟路由和转发 复制链接链接已复制到粘贴板!
17.3.1. 关于虚拟路由和转发 复制链接链接已复制到粘贴板!
虚拟路由和转发(VRF)设备与 IP 规则相结合,提供了创建虚拟路由和转发域的能力。VRF 减少了 CNF 所需的权限数量,并可提高二级网络网络拓扑的可见性。VRF 用于提供多租户功能,例如,每个租户都有自己的唯一的路由表且需要不同的默认网关。
进程可将套接字绑定到 VRF 设备。通过绑定套接字的数据包使用与 VRF 设备关联的路由表。VRF 的一个重要特性是,它只影响 OSI 模型层 3 以上的流量,因此 L2 工具(如 LLDP)不会受到影响。这可让优先级更高的 IP 规则(如基于策略的路由)优先于针对特定流量的 VRF 设备规则。
17.3.1.1. 这对针对电信业使用的 pod 的从属网络提供了好处 复制链接链接已复制到粘贴板!
在电信业,每个 CNF 都可连接到共享相同地址空间的多个不同的网络。这些从属网络可能会与集群的主网络 CIDR 冲突。使用 CNI VRF 插件,网络功能可使用相同的 IP 地址连接到不同的客户基础架构,使不同的客户保持隔离。IP 地址与 OpenShift Container Platform IP 空间重叠。CNI VRF 插件还可减少 CNF 所需的权限数量,并提高从属网络的网络拓扑的可见性。
17.4. 配置多网络策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为单根 I/O 虚拟化 (SR-IOV)、MAC Virtual Local Area Network (MacVLAN) 或 OVN-Kubernetes 额外网络配置多网络策略。macvlan 额外网络被完全支持。不支持其他类型的额外网络,如 IP Virtual Local Area Network (IPVLAN)。
支持为 SR-IOV 额外网络配置多网络策略,仅支持内核网络接口控制器 (NIC)。SR-IOV 不支持 Data Plane Development Kit (DPDK)应用程序。
17.4.1. 多网络策略和网络策略之间的区别 复制链接链接已复制到粘贴板!
虽然 MultiNetworkPolicy API 实现了 NetworkPolicy API,但请确保了解这两个策略之间的以下关键区别:
您必须使用
MultiNetworkPolicyAPI,如下例所示:apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy # ...
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
当使用 CLI 与多网络策略交互时,您必须使用
multi-networkpolicy资源名称。例如,您可以使用oc get multi-networkpolicy <name>命令来查看多网络策略对象,其中<name>是多网络策略的名称。 您可以使用
MultiNetworkPolicy对象上的k8s.v1.cni.cncf.io/policy-for注解指向NetworkAttachmentDefinition(NAD) 自定义资源(CR)。NAD CR 定义策略应用到的网络。以下示例多网络策略包括k8s.v1.cni.cncf.io/policy-for注解:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<namespace_name>- 指定命名空间名称。
<network_name>- 指定网络附加定义的名称。
17.4.2. 为集群启用多网络策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在集群中启用多网络策略支持。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
使用以下 YAML 创建
multinetwork-enable-patch.yaml文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置集群以启用多网络策略。成功输出列出了策略对象的名称以及
补丁的状态。oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml
$ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.4.3. 在 IPv6 网络中支持多网络策略 复制链接链接已复制到粘贴板!
ICMPv6 Neighbor Discovery Protocol (NDP) 是一组消息和流程,使设备能够发现和维护有关邻居节点的信息。NDP 在 IPv6 网络中扮演着关键角色,用于处理同一链路上的设备间的交互。
当 useMultiNetworkPolicy 参数被设置为 true 时,Cluster Network Operator (CNO) 会部署多网络策略的 iptables 实现。
要在 IPv6 网络中支持多网络策略,Cluster Network Operator 会在受多网络策略影响的每个 pod 中部署以下一组自定义规则:
其中:
icmpv6-type neighbor-solicitation- 此规则允许传入的 ICMPv6 邻居请求消息,它们是邻居发现协议 (NDP) 的一部分。这些消息帮助确定邻居节点的链路层地址。
icmpv6-type neighbor-advertisement- 此规则允许传入 ICMPv6 邻居公告消息,它们是 NDP 的一部分,并提供有关发件人链路层地址的信息。
icmpv6-type router-solicitation- 此规则允许传入的 ICMPv6 路由器请求消息。主机使用这些消息来请求路由器配置信息。
icmpv6-type router-advertisement- 此规则允许传入的 ICMPv6 路由器广告消息,为主机提供配置信息。
您不能编辑预定义的规则。
这些规则共同启用基本的 ICMPv6 流量,以便正确实现网络功能,包括 IPv6 环境中的地址解析和路由器通信。使用这些规则以及多网络策略拒绝流量时,应用程序应不会遇到连接问题。
17.4.4. 使用多网络策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以创建、编辑、查看和删除多网络策略。
17.4.4.1. 先决条件 复制链接链接已复制到粘贴板!
- 您已为集群启用了多网络策略支持。
17.4.4.2. 使用 CLI 创建多网络策略 复制链接链接已复制到粘贴板!
要定义细致的规则来描述集群中命名空间允许的入口或出口网络流量,您可以创建一个多网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin权限的用户登陆到集群。 - 您在多网络策略应用到的命名空间中工作。
流程
创建策略规则。
创建一个
<policy_name>.yaml文件:touch <policy_name>.yaml
$ touch <policy_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定多网络策略文件名。
在创建的文件中定义一个多网络策略。以下示例拒绝来自所有命名空间中的所有 pod 的入口流量。这是一个基本的策略,阻止配置其他网络策略所允许的跨 pod 流量以外的所有跨 pod 网络。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<network_name>指定网络附加定义的名称。
以下示例配置允许来自同一命名空间中的所有 pod 的入口流量:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<network_name>指定网络附加定义的名称。
以下示例允许从特定命名空间中到一个 pod 的入口流量。此策略允许流量从在
namespace-y中运行的 pod 中获取pod-a标签。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<network_name>指定网络附加定义的名称。
以下示例配置限制了服务的流量。应用此策略可确保每个带有标签
app=bookstore和标签role=api的 pod 只能被带有标签app=bookstore的 pod 访问。在本例中,应用可以是 REST API 服务器,标记为标签app=bookstore和role=api。这个示例配置示例解决了以下用例:
- 将到一个服务的流量限制为仅使用需要它的其他微服务。
将连接限制为只允许使用它的应用程序。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<network_name>- 指定网络附加定义的名称。
运行以下命令来创建多网络策略对象。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f <policy_name>.yaml -n <namespace>
$ oc apply -f <policy_name>.yaml -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定多网络策略文件名。
<namespace>- 可选参数。如果您在与当前命名空间不同的命名空间中定义了对象,则参数会特定于命名空间。
成功输出列出了策略对象的名称
以及创建的状态。注意如果您使用
cluster-admin权限登录到 web 控制台,您可以选择在集群中的任何命名空间中以 YAML 或 web 控制台的形式创建网络策略。
17.4.4.3. 编辑多网络策略 复制链接链接已复制到粘贴板!
您可以编辑命名空间中的多网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。 - 您在存在多网络策略的命名空间中工作。
流程
可选: 要列出命名空间中的多网络策略对象,请输入以下命令:
oc get multi-network policy -n <namespace>
$ oc get multi-network policy -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<namespace>- 可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
编辑多网络策略对象。
如果您在文件中保存了多网络策略定义,请编辑该文件并进行必要的更改,然后输入以下命令。
oc apply -n <namespace> -f <policy_file>.yaml
$ oc apply -n <namespace> -f <policy_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<namespace>- 可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
<policy_file>- 指定包含网络策略的文件的名称。
如果您需要直接更新多网络策略对象,请输入以下命令:
oc edit multi-network policy <policy_name> -n <namespace>
$ oc edit multi-network policy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定网络策略的名称。
<namespace>- 可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
确认已更新多网络策略对象。
oc describe multi-networkpolicy <policy_name> -n <namespace>
$ oc describe multi-networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定多网络策略的名称。
<namespace>- 可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
如果您使用 cluster-admin 权限登录到 web 控制台,您可以选择在集群中的任何命名空间中以 YAML 或通过 Actions 菜单从 web 控制台中的策略编辑网络策略。
17.4.4.4. 使用 CLI 查看多网络策略 复制链接链接已复制到粘贴板!
您可以检查命名空间中的多网络策略。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。 - 您在存在多网络策略的命名空间中工作。
流程
列出命名空间中的多网络策略。
要查看命名空间中定义的多网络策略对象,请输入以下命令:
oc get multi-networkpolicy
$ oc get multi-networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选: 要检查特定的多网络策略,请输入以下命令:
oc describe multi-networkpolicy <policy_name> -n <namespace>
$ oc describe multi-networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定要检查的多网络策略的名称。
<namespace>- 可选: 如果对象在与当前命名空间不同的命名空间中定义,使用它来指定命名空间。
如果您使用 cluster-admin 权限登录到 web 控制台,您可以选择在集群中的任何命名空间中以 YAML 或 web 控制台的形式查看网络策略。
17.4.4.5. 使用 CLI 删除多网络策略 复制链接链接已复制到粘贴板!
您可以删除命名空间中的多网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin权限的用户登陆到集群。 - 您在存在多网络策略的命名空间中工作。
流程
要删除多网络策略对象,请输入以下命令。成功输出列出了策略对象的名称以及
已删除的状态。oc delete multi-networkpolicy <policy_name> -n <namespace>
$ oc delete multi-networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<policy_name>- 指定多网络策略的名称。
<namespace>- 可选参数。如果您在与当前命名空间不同的命名空间中定义了对象,则参数会特定于命名空间。
如果使用 cluster-admin 权限登录到 web 控制台,您可以选择在集群上以 YAML 或通过 Actions 菜单从 web 控制台中的策略删除网络策略。
17.4.4.6. 创建默认拒绝所有多网络策略 复制链接链接已复制到粘贴板!
默认拒绝所有多网络策略会阻止除网络流量以外的所有跨 pod 网络,这些网络会被配置其他部署的网络策略和主机网络 pod 间的流量。此流程通过在 my-project 命名空间中应用 deny-by-default 策略来强制实施强大的拒绝策略。
如果没有配置允许流量通信的 NetworkPolicy 自定义资源(CR),以下策略可能会导致集群中的通信问题。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin权限的用户登陆到集群。 - 您在多网络策略应用到的命名空间中工作。
流程
创建以下 YAML,以定义
deny-by-default策略,以拒绝所有命名空间中的所有 pod 的入口流量。将 YAML 保存到deny-by-default.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
namespace-
指定要部署策略的命名空间。例如,
my-project命名空间。 annotations- 指定命名空间项目的名称,后跟网络附加定义名称。
podSelector-
如果此字段为空,则配置与所有 pod 匹配。因此,该策略适用于
my-project命名空间中的所有 pod。 policyTypes-
指定
NetworkPolicy相关规则类型列表。 - Ingress-
指定
Ingress仅policyTypes。 ingress- 指定入站规则。如果没有指定,则所有传入的流量会所有 pod 都会丢弃。
输入以下命令应用策略。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.4.4.7. 创建多网络策略以允许来自外部客户端的流量 复制链接链接已复制到粘贴板!
使用 deny-by-default 策略,您可以继续配置策略,允许从外部客户端到带有标签 app=web 的 pod 的流量。
如果使用具有 cluster-admin 角色的用户登录,则可以在集群中的任何命名空间中创建网络策略。
按照以下步骤配置策略,以直接从公共互联网允许外部服务,或使用 Load Balancer 访问 pod。只有具有标签 app=web 的 pod 才允许流量。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin权限的用户登陆到集群。 - 您在多网络策略应用到的命名空间中工作。
流程
创建策略,以直接从公共互联网的流量或使用负载均衡器访问 pod。将 YAML 保存到
web-allow-external.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令应用策略。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f web-allow-external.yaml
$ oc apply -f web-allow-external.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 此策略允许来自所有资源的流量,包括下图所示的外部流量:
17.4.4.8. 创建一个多网络策略,允许从所有命名空间中到应用程序的流量 复制链接链接已复制到粘贴板!
您可以配置允许从所有命名空间中的所有 pod 流量到特定应用程序的策略。
如果使用具有 cluster-admin 角色的用户登录,则可以在集群中的任何命名空间中创建网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin权限的用户登陆到集群。 - 您在多网络策略应用到的命名空间中工作。
流程
创建一个策略,允许从所有命名空间中的所有 pod 流量到特定应用。将 YAML 保存到
web-allow-all-namespaces.yaml文件中:+ 其中:
+
app-
仅将策略应用到 default 命名空间中的
app:webpod。 namespaceSelector- 选择所有命名空间中的所有 pod。
默认情况下,如果您没有在策略对象中指定 namespaceSelector 参数,则不会选择命名空间。这意味着策略只允许从网络策略部署的命名空间的流量。
输入以下命令应用策略。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f web-allow-all-namespaces.yaml
$ oc apply -f web-allow-all-namespaces.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
输入以下命令在
default命名空间中启动 web 服务:oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令在
secondary命名空间中部署alpine镜像并启动 shell:oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 shell 中运行以下命令,并观察该服务是否允许请求:
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.4.4.9. 创建多网络策略允许从命名空间中到应用程序的流量 复制链接链接已复制到粘贴板!
您可以配置允许从特定命名空间中到带有 app=web 标签的 pod 的策略。这个配置在以下情况下很有用:
- 将流量限制为部署了生产工作负载的命名空间。
- 启用部署到特定命名空间的监控工具,以从当前命名空间中提取指标。
如果使用具有 cluster-admin 角色的用户登录,则可以在集群中的任何命名空间中创建网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的网络插件,如 OVN-Kubernetes 网络插件或设置了mode: NetworkPolicy的 OpenShift SDN 网络插件。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin权限的用户登陆到集群。 - 您在多网络策略应用到的命名空间中工作。
流程
创建一个策略,允许来自特定命名空间中所有 pod 的流量,其标签为
purpose=production。将 YAML 保存到web-allow-prod.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
app-
仅将策略应用到 default 命名空间中的
app:webpod。 目的-
将流量仅限制为具有标签
purpose=production的命名空间中的 pod。
输入以下命令应用策略。成功输出列出了策略对象的名称
以及创建的状态。oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
输入以下命令在
default命名空间中启动 web 服务:oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
prod命名空间:oc create namespace prod
$ oc create namespace prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来标记
prod命名空间:oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
dev命名空间:oc create namespace dev
$ oc create namespace devCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来标记
dev命名空间:oc label namespace/dev purpose=testing
$ oc label namespace/dev purpose=testingCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令在
dev命名空间中部署alpine镜像并启动 shell:oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 shell 中运行以下命令,并观察请求的原因。例如,预期的输出状态为
wget:下载超时。wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,在
prod命名空间中部署alpine镜像并启动 shell:oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 shell 中运行以下命令,并观察是否允许请求:
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.5. 将 pod 附加到额外网络 复制链接链接已复制到粘贴板!
您可以将 pod 附加到二级网络。将 pod 附加到二级网络可让 pod 使用主集群网络之外的其他网络接口。
17.5.1. 将 pod 添加到额外网络 复制链接链接已复制到粘贴板!
您可以将 pod 添加到二级网络。pod 继续通过默认网络发送与集群相关的普通网络流量。
创建 pod 时会附加额外网络。但是,如果 pod 已存在,您无法为其附加额外网络。
pod 必须与额外网络处于相同的命名空间。
先决条件
-
安装 OpenShift CLI(
oc)。 - 登录到集群。
流程
为
Pod对象添加注解。只能使用以下注解格式之一:要在没有自定义的情况下附加二级网络,请使用以下格式添加注解:
metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
k8s.v1.cni.cncf.io/networks- 指定要与 pod 关联的二级网络的名称。要指定多个二级网络,请使用逗号分隔每个网络。逗号之间不可包括空格。如果您多次指定相同的二级网络,则该 pod 会将多个网络接口附加到该网络。
要通过自定义来附加二级网络,请添加具有以下格式的注解:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name-
指定
NetworkAttachmentDefinition对象定义的二级网络的名称。 namespace-
指定定义
NetworkAttachmentDefinition对象的命名空间。 default-route-
可选参数。为默认路由指定覆盖,如
192.168.17.1。
运行以下命令来创建 pod。
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<name>替换为 pod 的名称。可选:输入以下命令确认
podCR 中是否存在注解。将<name>替换为 pod 的名称。oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在以下示例中,
example-podpod 附加到net1额外网络:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
k8s.v1.cni.cncf.io/network-status- 指定对象的 JSON 数组。每个对象描述附加到 pod 的二级网络的状态。注解值保存为纯文本值。
17.5.1.1. 指定特定于 pod 的地址和路由选项 复制链接链接已复制到粘贴板!
您可以使用 JSON 格式的注解配置特定于 pod 的地址和路由选项。配置这些选项可让您为 pod 设置静态 IP 地址、MAC 地址和默认路由。
先决条件
- pod 必须与额外网络处于相同的命名空间。
-
安装 OpenShift CLI (
oc) 。 - 您必须登录集群。
流程
编辑
Pod资源定义。如果要编辑现有Pod资源,请运行以下命令在默认编辑器中编辑其定义。将<name>替换为要编辑的Pod资源的名称。oc edit pod <name>
$ oc edit pod <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
Pod资源定义中,将k8s.v1.cni.cncf.io/networks参数添加到 podmetadata映射中。k8s.v1.cni.cncf.io/networks接受 JSON 字符串,该字符串除指定附加属性外,还引用NetworkAttachmentDefinition自定义资源(CR)名称的对象。metadata: annotations: k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' # ...metadata: annotations: k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<network>- 如以下示例所示,将 替换为 JSON 对象。单引号是必需的。
在以下示例中,通过
default-route参数,注解指定了哪个网络附加将使用默认路由。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name- 指定要与 pod 关联的二级网络的名称。
default-route-
如果路由表中没有其他路由条目,则指定要路由的流量的值。如果指定了多个
default-route键,这将导致 pod 无法成为活跃状态。
默认路由将导致任何没有在其它路由中指定的流量被路由到网关。
重要将 OpenShift Container Platform 的默认路由设置为默认网络接口以外的接口时,可能会导致应该是 pod 和 pod 间的网络流量被路由到其他接口。
要验证 pod 的路由属性,可使用
oc命令在 pod 中执行ip命令。oc exec -it <pod_name> -- ip route
$ oc exec -it <pod_name> -- ip routeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您还可以引用 pod 的
k8s.v1.cni.cncf.io/network-status来查看哪个额外网络已被分配默认路由,这可以通过 JSON 格式的对象列表中的default-route键存在。要为 pod 设置静态 IP 地址或 MAC 地址,您可以使用 JSON 格式的注解。这要求您创建允许此功能的网络。这可以在 CNO 的 rawCNIConfig 中指定。
运行以下命令来编辑 CNO CR:
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下 YAML 描述了 CNO 的配置参数:
Cluster Network Operator YAML 配置
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name-
指定您要创建的二级网络附加的名称。该名称在指定的
namespace中需要是唯一的。 namespace-
指定要在其中创建网络附加的命名空间。如果您未指定值,则使用
default命名空间。 rawCNIConfig- 以 JSON 格式指定 CNI 插件配置,它基于以下模板。
以下对象描述了使用 macvlan CNI 插件的静态 MAC 地址和 IP 地址的配置参数:
使用静态 IP 和 MAC 地址的 macvlan CNI 插件 JSON 配置对象
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name-
指定要创建的二级网络附加的名称。该名称在指定的
namespace中需要是唯一的。 plugins- 指定 CNI 插件配置的数组。第一个对象指定 macvlan 插件配置,第二个对象指定 tuning 插件配置。
ips- 指定一个请求启用 CNI 插件运行时配置功能的静态 IP 地址功能。
master- 指定 macvlan 插件使用的接口。
mac- 指定一个请求启用 CNI 插件的静态 MAC 地址功能。
以上网络附加可能会以 JSON 格式的注解引用,同时使用相关的键来指定将哪些静态 IP 和 MAC 地址分配给指定 pod。
输入以下命令编辑 pod:
oc edit pod <name>
$ oc edit pod <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用静态 IP 和 MAC 地址的 macvlan CNI 插件 JSON 配置对象
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name-
指定要创建的二级网络附加的名称。该名称在指定的
namespace中需要是唯一的。 ips- 指定包括子网掩码的 IP 地址。
mac- 指定 MAC 地址。
注意静态 IP 地址和 MAC 地址不需要同时使用。您可以单独使用它们,也可以一起使用。
17.6. 从额外网络中删除 pod 复制链接链接已复制到粘贴板!
您可以从二级网络中删除 pod。您可以从二级网络中删除 pod,以将其与特定的网络配置断开连接。
17.6.1. 从额外网络中删除 pod 复制链接链接已复制到粘贴板!
您可以从二级网络中删除 pod。您可以从二级网络中删除 pod,以将其与特定的网络配置断开连接。
先决条件
- 一个额外网络被附加到 pod。
-
安装 OpenShift CLI(
oc)。 - 登录到集群。
流程
输入以下命令删除 pod:
oc delete pod <name> -n <namespace>
$ oc delete pod <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<name>- 指定 pod 的名称。
<namespace>- 指定包含 pod 的命名空间。
17.7. 编辑额外网络 复制链接链接已复制到粘贴板!
您可以修改现有二级网络的配置。您可以修改二级网络以更新网络设置或更改网络参数。
17.7.1. 修改额外网络附加定义 复制链接链接已复制到粘贴板!
您可以修改二级网络附加定义。您可以修改附加定义以更新网络设置或更改网络参数。
先决条件
- 已为集群配置了额外网络。
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
运行以下命令,在默认文本编辑器中编辑 Cluster Network Operator (CNO) CR:
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
在
additionalNetworks集合中,使用您的更改更新二级网络。 - 保存您的更改,再退出文本编辑器以提交更改。
可选:运行以下命令确认 CNO 更新了
NetworkAttachmentDefinition对象。将<network_name> 替换为要显示的二级网络的名称。CNO 根据您的更改更新NetworkAttachmentDefinition对象前可能会有延迟。oc get network-attachment-definitions <network_name> -o yaml
$ oc get network-attachment-definitions <network_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如,以下控制台输出显示名为
net1的NetworkAttachmentDefinition对象:oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'$ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}' { "cniVersion": "0.3.1", "type": "macvlan", "master": "ens5", "mode": "bridge", "ipam": {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.8. 删除额外网络 复制链接链接已复制到粘贴板!
您可以删除额外网络附加。您可以删除额外网络来清理未使用的网络配置或释放网络资源。
17.8.1. 删除额外网络附加定义 复制链接链接已复制到粘贴板!
作为集群管理员,您可以从 OpenShift Container Platform 集群中删除二级网络。二级网络不会从它所附加的任何 pod 中删除。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
运行以下命令,在默认文本编辑器中编辑 Cluster Network Operator (CNO):
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从您要删除的网络附加定义的
additionalNetworks集合中删除配置,以此修改 CR。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
additionalNetworks-
指定您要从
additionalNetworks集合中删除的二级网络附加定义。如果您要删除additionalNetworks集合中唯一二级网络附加定义的配置映射,您必须指定一个空集合。
输入以下命令从集群网络中删除网络附加定义:
oc delete net-attach-def <name_of_network_attachment_definition>
$ oc delete net-attach-def <name_of_network_attachment_definition>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 <
name_of_network_attachment_definition> 替换为您要删除的网络附加定义的名称。- 保存您的更改,再退出文本编辑器以提交更改。
可选:通过运行以下命令确认删除了额外网络 CR:
oc get network-attachment-definition --all-namespaces
$ oc get network-attachment-definition --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.9. 为 VRF 分配从属网络 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 CNI VRF 插件为虚拟路由和转发 (VRF) 域配置二级网络。此插件创建的虚拟网络与您指定的物理接口关联。
使用带有 VRF 实例的二级网络有以下优点:
- 工作负载隔离
- 通过为额外网络配置 VRF 实例来隔离工作负载流量。
- 提高了安全性
- 通过 VRF 域中的隔离网络路径启用更高的安全性。
- 多租户支持
- 通过网络分段支持每个租户的 VRF 域中唯一路由表的多租户。
使用 VRF 的应用程序必须绑定到特定设备。通常的用法是在套接字中使用 SO_BINDTODEVICE 选项。SO_BINDTODEVICE 选项将套接字绑定到在传递接口名称中指定的设备,如 eth1。要使用 SO_BINDTODEVICE 选项,应用程序必须具有 CAP_NET_RAW 功能。
OpenShift Container Platform pod 不支持通过 ip vrf exec 命令使用 VRF。要使用 VRF,将应用程序直接绑定到 VRF 接口。
17.9.1. 使用 CNI VRF 插件创建额外网络附加 复制链接链接已复制到粘贴板!
Cluster Network Operator (CNO) 管理二级网络定义。当您在集群范围的 Network 自定义资源(CR)中指定二级网络时,CNO 会自动创建 NetworkAttachmentDefinition CR。
请勿编辑 Cluster Network Operator 所管理的 NetworkAttachmentDefinition CR。这样做可能会破坏额外网络上的网络流量。
要使用 CNI VRF 插件创建额外网络附加,请执行以下步骤。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin权限的用户身份登录集群。
流程
为额外网络附加创建
NetworkCR,并为二级网络插入rawCNIConfig配置。保存为additional-network-attachment.yaml文件。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
plugins- 您必须指定一个列表。列表中的第一个项必须是支持 VRF 网络的从属网络。列表中的第二个项目是 VRF 插件配置。
type-
您必须将此参数设为
vrf。 vrfname- 接口分配的 VRF 的名称。如果 pod 中不存在 VRF,CNI 会创建 VRF。
table可选参数。指定路由表 ID。默认情况下使用
tableid参数。如果没有指定表 ID,CNI 会将可用路由表 ID 分配给 VRF。注意只有在资源类型为
netdevice时,VRF 才能正常工作。
创建
Network资源:oc create -f additional-network-attachment.yaml
$ oc create -f additional-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过运行以下命令确认 CNO 创建了
NetworkAttachmentDefinitionCR。将<namespace>替换为您在配置网络附加时指定的命名空间,如additional-network-1。预期输出显示 NAD CR 的名称和创建年龄(以分钟为单位)。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意CNO 创建 CR 之前可能会有延迟。
验证
创建 pod,并将 pod 分配给包含 VRF 插件配置的二级网络。
按照以下
pod-additional-net.yaml文件,创建一个定义Pod资源的 YAML 文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name- 指定包含 VRF 插件配置的二级网络的名称。
运行以下命令来创建
Pod资源。预期输出显示Pod资源的名称和创建期限(以分钟为单位)。oc create -f pod-additional-net.yaml
$ oc create -f pod-additional-net.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证 pod 网络附加连接到 VRF 二级网络。使用 pod 启动远程会话并运行以下命令:预期输出显示 VRF 接口的名称及其在路由表中的唯一 ID。
ip vrf show
$ ip vrf showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令确认 VRF 接口是二级接口的控制器:
ip link
$ ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP modeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 18 章 硬件网络 复制链接链接已复制到粘贴板!
18.1. 关于单根 I/O 虚拟化(SR-IOV)硬件网络 复制链接链接已复制到粘贴板!
Single Root I/O 虚拟化 (SR-IOV) 规范是针对一类 PCI 设备分配的标准,可与多个 pod 共享单个设备。
您可以使用 SR-IOV Operator 在集群中配置单一根 I/O 虚拟化(SR-IOV)设备。
通过 SR-IOV,您可以将主机节点上识别为物理功能 (PF) 的兼容网络设备分段为多个虚拟功能 (VF)。VF 和其它网络设备一样使用。该设备的 SR-IOV 网络设备驱动程序决定了如何公开容器中的 VF:
-
netdevice驱动程序: 容器netns中的常规内核网络设备 -
vfio-pci驱动程序: 挂载到容器中的字符设备
对于需要高带宽或低延迟的应用程序,您可以在裸机或 Red Hat OpenStack Platform(RHOSP)基础架构上安装 OpenShift Container Platform 集群上的额外网络使用 SR-IOV 网络设备。
您可以为 SR-IOV 网络配置多网络策略。对这个功能的支持是技术预览,SR-IOV 额外网络只支持内核 NIC。它们不支持 Data Plane Development Kit (DPDK) 应用程序。
与 SR-IOV 网络相比,在 SR-IOV 网络中创建多网络策略可能无法为应用程序提供相同的性能。
SR-IOV 网络的多网络策略只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
您可以使用以下命令在节点上启用 SR-IOV:
oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
18.1.2. 负责管理 SR-IOV 网络设备的组件 复制链接链接已复制到粘贴板!
SR-IOV Network Operator 会创建和管理 SR-IOV 堆栈的组件。Operator 执行以下功能:
- 编配 SR-IOV 网络设备的发现和管理
-
为 SR-IOV Container Network Interface(CNI)生成
NetworkAttachmentDefinition自定义资源 - 创建和更新 SR-IOV 网络设备插件的配置
-
创建节点特定的
SriovNetworkNodeState自定义资源 -
更新每个
SriovNetworkNodeState自定义资源中的spec.interfaces字段
Operator 置备以下组件:
- SR-IOV 网络配置守护进程
- SR-IOV Network Operator 启动时部署在 worker 节点上的守护进程集。守护进程负责在集群中发现和初始化 SR-IOV 网络设备。
- SR-IOV Network Operator Webhook
- 这是动态准入控制器 Webhook,用于验证 Operator 自定义资源,并为未设置的字段设置适当的默认值。
- SR-IOV Network Resources Injector(网络资源注入器)
-
这是一个动态准入控制器 Webhook,它提供通过请求和限制为自定义网络资源(如 SR-IOV VF)应用 Kubernetes pod 规格的功能。SR-IOV 网络资源注入器只会将
resource字段添加到 pod 中的第一个容器。 - 网络SR-IOV 网络设备插件
- 这个设备插件用于发现、公告并分配 SR-IOV 网络虚拟功能 (VF) 资源。在 Kubernetes 中使用设备插件能够利用有限的资源,这些资源通常为于物理设备中。设备插件可以使 Kubernetes 调度程序了解资源可用性,因此调度程序可以在具有足够资源的节点上调度 pod。
- SR-IOV CNI 插件
- SR-IOV CNI 插件会附加从 SR-IOV 网络设备插件中直接分配给 pod 的 VF 接口。
- SR-IOV InfiniBand CNI 插件
- 附加从 SR-IOV 网络设备插件中直接分配给 pod 的 InfiniBand(IB)VF 接口的 CNI 插件。
SR-IOV Network resources injector 和 SR-IOV Operator Webhook 会被默认启用,可通过编辑 default SriovOperatorConfig CR 来禁用。禁用 SR-IOV Network Operator Admission Controller Webhook 时要小心。您可以在特定情况下禁用 webhook,如故障排除,或者想要使用不支持的设备。
18.1.2.1. 支持的平台 复制链接链接已复制到粘贴板!
在以下平台上支持 SR-IOV Network Operator:
- 裸机
- Red Hat OpenStack Platform(RHOSP)
18.1.2.2. 支持的设备 复制链接链接已复制到粘贴板!
OpenShift Container Platform 支持以下网络接口控制器:
| 制造商 | model | 供应商 ID | 设备 ID |
|---|---|---|---|
| Broadcom | BCM57414 | 14e4 | 16d7 |
| Broadcom | BCM57508 | 14e4 | 1750 |
| Broadcom | BCM57504 | 14e4 | 1751 |
| Intel | X710 | 8086 | 1572 |
| Intel | X710 Backplane | 8086 | 1581 |
| Intel | X710 基本 T | 8086 | 15ff |
| Intel | XL710 | 8086 | 1583 |
| Intel | XXV710 | 8086 | 158b |
| Intel | E810-CQDA2 | 8086 | 1592 |
| Intel | E810-2CQDA2 | 8086 | 1592 |
| Intel | E810-XXVDA2 | 8086 | 159b |
| Intel | E810-XXVDA4 | 8086 | 1593 |
| Intel | E810-XXVDA4T | 8086 | 1593 |
| Intel | Ice E810-XXV Backplane | 8086 | 1599 |
| Intel | Ice E823L Backplane | 8086 | 124c |
| Intel | Ice E823L SFP | 8086 | 124d |
| Marvell | OCTEON Fusion CNF105XX | 177d | ba00 |
| Marvell | OCTEON10 CN10XXX | 177d | b900 |
| Mellanox | MT27700 系列 [ConnectX-4] | 15b3 | 1013 |
| Mellanox | MT27710 系列 [ConnectX-4 Lx] | 15b3 | 1015 |
| Mellanox | MT27800 系列 [ConnectX-5] | 15b3 | 1017 |
| Mellanox | MT28880 系列 [ConnectX-5 Ex] | 15b3 | 1019 |
| Mellanox | MT28908 系列 [ConnectX-6] | 15b3 | 101b |
| Mellanox | MT2892 Family [ConnectX‑6 Dx] | 15b3 | 101d |
| Mellanox | MT2894 Family [ConnectX‑6 Lx] | 15b3 | 101f |
| Mellanox | Mellanox MT2910 系列 [ConnectX-7] | 15b3 | 1021 |
| Mellanox | ConnectX-6 NIC 模式中的 MT42822 BlueField-2 | 15b3 | a2d6 |
| Pensando [1] | 用于 ionic 驱动程序的 DSC-25 双端口 25G 分布式服务卡 | 0x1dd8 | 0x1002 |
| Pensando [1] | 用于 ionic 驱动程序的 DSC-100 双端口 100G 分布式服务卡 | 0x1dd8 | 0x1003 |
| Silicom | STS 系列 | 8086 | 1591 |
- 支持 OpenShift SR-IOV,但在使用 SR-IOV 时,您必须使用 SR-IOV CNI 配置文件设置静态的虚拟功能(VF)介质访问控制(MAC)地址。
有关支持的卡和兼容的 OpenShift Container Platform 版本的最新列表,请参阅 Openshift Single Root I/O Virtualization(SR-IOV)和 PTP 硬件网络支持列表。
18.1.4. 后续步骤 复制链接链接已复制到粘贴板!
- 配置 SR-IOV Network Operator
- 配置 SR-IOV 网络设备
- 如果使用 OpenShift Virtualization:将虚拟机连接到 SR-IOV 网络
- 配置 SR-IOV 网络附加
- 以太网网络附加:将 pod 添加到 SR-IOV 额外网络
- InfiniBand 网络附加:将 pod 添加到 SR-IOV 额外网络
18.2. 配置 SR-IOV 网络设备 复制链接链接已复制到粘贴板!
您可以在集群中配置单一根 I/O 虚拟化(SR-IOV)设备。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
18.2.1. SR-IOV 网络节点配置对象 复制链接链接已复制到粘贴板!
您可以通过创建 SR-IOV 网络节点策略来为节点指定 SR-IOV 网络设备配置。策略的 API 对象是 sriovnetwork.openshift.io API 组的一部分。
以下 YAML 描述了 SR-IOV 网络节点策略:
- 1 1 1 1
- 自定义资源对象的名称。
- 2 2
- 安装 SR-IOV Network Operator 的命名空间。
- 3 3
- SR-IOV 网络设备插件的资源名称。您可以为资源名称创建多个 SR-IOV 网络节点策略。
在指定名称时,请确保在
resourceName中使用接受的语法表达式^[a-zA-Z0-9_]+$。 - 4 4
- 节点选择器指定要配置的节点。只有所选节点上的 SR-IOV 网络设备才会被配置。SR-IOV Container Network Interface(CNI)插件和设备插件仅在所选节点上部署。重要
SR-IOV Network Operator 按顺序将节点网络配置策略应用到节点。在应用节点网络配置策略前,SR-IOV Network Operator 会检查节点的机器配置池(MCP)是否处于不健康状态,如
Degraded或Updating。如果节点处于不健康的 MCP,将节点网络配置策略应用到集群中的所有目标节点的过程会被暂停,直到 MCP 返回健康状态。为了避免处于不健康的 MCP 的节点阻止将节点网络配置策略应用到其他节点,包括处于其他 MCP 的节点,您必须为每个 MCP 创建单独的节点网络配置策略。
- 5
- 可选: priority 是一个
0到99之间的整数。较小的值具有更高的优先级。例如,优先级10是高于优先级99。默认值为99。 - 6
- 可选:物理功能及其所有虚拟功能的最大传输单元(MTU)。最大 MTU 值可能因不同的网络接口控制器(NIC)型号而有所不同。重要
如果要在默认网络接口上创建虚拟功能,请确保将 MTU 设置为与集群 MTU 匹配的值。
如果要修改单个虚拟功能的 MTU,同时将功能分配给 pod,请将 MTU 值留在 SR-IOV 网络节点策略中。否则,SR-IOV Network Operator 会将虚拟功能的 MTU 恢复到 SR-IOV 网络节点策略中定义的 MTU 值,这可能会触发节点排空。
- 7
- 可选:将
needVhostNet设置为true,以在 pod 中挂载/dev/vhost-net设备。使用挂载的/dev/vhost-net设备及 Data Plane Development Kit (DPDK) 将流量转发到内核网络堆栈。 - 8
- 为 SR-IOV 物理网络设备创建的虚拟功能((VF)的数量。对于 Intel 网络接口控制器(NIC),VF 的数量不能超过该设备支持的 VF 总数。对于 Mellanox NIC,VF 的数量不能超过
127。 - 9
externallyManaged字段指示 SR-IOV Network Operator 是否管理所有,或只是虚拟功能(VF)的子集。将值设为false时,SR-IOV Network Operator 管理并配置 PF 上的所有 VF。注意当
externalManaged设置为true时,您必须在应用SriovNetworkNodePolicy资源前在物理功能(PF)上手动创建虚拟功能(VF)。如果没有预先创建 VF,SR-IOV Network Operator 的 Webhook 将阻止策略请求。当
externallyManaged设为false时,SR-IOV Network Operator 会自动创建和管理 VF,包括重置 VF (如果需要)。要在主机系统上使用 VF,您必须通过 NMState 创建它们,并将
externallyManaged设置为true。在这个模式中,SR-IOV Network Operator 不会修改 PF 或手动管理的 VF,策略nicSelector字段中明确定义的 VF 除外。但是,SR-IOV Network Operator 继续管理用作 pod 二级接口的 VF。- 10
- NIC 选择器标识此资源应用到的设备。您不必为所有参数指定值。建议您足够精确地识别网络设备以避免意外选择设备。
如果指定了
rootDevices,则必须同时为vendor、deviceID或pfNames指定一个值。如果同时指定了pfNames和rootDevices,请确保它们引用同一设备。如果您为netFilter指定了一个值,那么您不需要指定任何其他参数,因为网络 ID 是唯一的。 - 11
- 可选: SR-IOV 网络设备厂商的十六进制厂商代码。允许的值只能是
8086(Intel)和15b3(Mellanox)。 - 12
- 可选: SR-IOV 网络设备的十六进制设备标识符。例如,
101b是 Mellanox ConnectX-6 设备的设备 ID。 - 13
- 可选:资源需要应用到的一个或多个物理功能(PF)名称的数组。
- 14
- 可选:资源需要应用到的一个或多个 PCI 总线地址的数组。例如
0000:02:00.1。 - 15
- 可选:特定平台的网络过滤器。唯一支持的平台是 Red Hat OpenStack Platform(RHOSP)。可接受的值具有以下格式:
openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。将xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx替换为来自/var/config/openstack/latest/network_data.json元数据文件的值。此过滤器确保 VF 与特定的 OpenStack 网络关联。Operator 使用此过滤器根据 OpenStack 平台提供的元数据将 VF 映射到适当的网络。 - 16
- 可选:为从此资源创建的 VF 配置的驱动程序。允许的值只能是
netdevice和vfio-pci。默认值为netdevice。对于裸机节点上的 DPDK 模式的 Mellanox NIC,请使用
netdevice驱动程序类型,并将isRdma设置为true。 - 17
- 可选:配置是否启用远程直接访问 (RDMA) 模式。默认值为
false。如果
isRdma参数设为true,您可以继续使用启用了 RDMA 的 VF 作为普通网络设备。设备可在其中的一个模式中使用。将
isRdma设置为true,并将needVhostNet设置为true以配置 Mellanox NIC 以用于 Fast Datapath DPDK 应用程序。注意对于 intel NIC,您无法将
isRdma参数设置为true。 - 18
- 可选:VF 的链接类型。默认值为
eth(以太网)。在 InfiniBand 中将这个值改为 'ib'。当将
linkType设置为ib时,SR-IOV Network Operator Webhook 会自动将isRdma设置为true。当将linkType设定为ib时,deviceType不应该被设置为vfio-pci。不要为 SriovNetworkNodePolicy 将 linkType 设置为
eth,因为这可能会导致设备插件报告的可用设备数量不正确。 - 19
- 可选: 要启用硬件卸载,您必须将
eSwitchMode字段设置为"switchdev"。有关硬件卸载的更多信息,请参阅"配置硬件卸载"。 - 20
- 可选:要排除将一个 SR-IOV 网络资源的 NUMA 节点广告到拓扑管理器,将值设为
true。默认值为false。
18.2.1.1. SR-IOV 网络节点配置示例 复制链接链接已复制到粘贴板!
以下示例描述了 InfiniBand 设备的配置:
InfiniBand 设备的配置示例
以下示例描述了 RHOSP 虚拟机中的 SR-IOV 网络设备配置:
虚拟机中的 SR-IOV 设备配置示例
18.2.1.2. 自动发现 SR-IOV 网络设备 复制链接链接已复制到粘贴板!
SR-IOV Network Operator 将搜索集群以获取 worker 节点上的 SR-IOV 功能网络设备。Operator 会为每个提供兼容 SR-IOV 网络设备的 worker 节点创建并更新一个 SriovNetworkNodeState 自定义资源 (CR) 。
为 CR 分配了与 worker 节点相同的名称。status.interfaces 列表提供有关节点上网络设备的信息。
不要修改 SriovNetworkNodeState 对象。Operator 会自动创建和管理这些资源。
18.2.1.2.1. SriovNetworkNodeState 对象示例 复制链接链接已复制到粘贴板!
以下 YAML 是由 SR-IOV Network Operator 创建的 SriovNetworkNodeState 对象的示例:
一 个 SriovNetworkNodeState 对象
18.2.1.3. SR-IOV 设备的虚拟功能 (VF) 分区 复制链接链接已复制到粘贴板!
在某些情况下,您可能想要将同一物理功能(PF)的虚拟功能(VF)分成多个资源池。例如: 您可能想要某些 VF 使用默认驱动程序载入,而其他的 VF 负载使用 vfio-pci 驱动程序。
例如,以下 YAML 显示名为 netpf0 的、带有 VF 2 到 7 的接口的选择器:
pfNames: ["netpf0#2-7"]
pfNames: ["netpf0#2-7"]
其中:
netpf0- PF 接口名称的名称。
2- 包含在范围内的第一个 VF 索引(基于 0)。
7- 包含在范围内的最后一个 VF 索引(基于 0)。
您可以使用您满足以下要求的不同策略 CR 从同一 PF 中选择 VF:
-
对于选择相同 PF 的策略,
numVfs值必须类似。 -
VF 索引范围是从
0到<numVfs>-1之间。例如,如果您有一个策略,它的numVfs被设置为8,则<first_vf>的值不能小于0,<last_vf>的值不能大于7。 - 不同策略中的 VF 范围不得互相重叠。
-
<first_vf>不能大于<last_vf>。
以下示例演示了 SR-IOV 设备的 NIC 分区。
策略 policy-net-1 定义了一个资源池 net-1,其中包含带有默认 VF 驱动程序的 PF netpf 的 VF 0。策略 0 policy-net-1-dpdk 定义了一个资源池 net-1-dpdk,其中包含带有 vfio VF 驱动程序的 PF netpf0 的 VF 8 到 15。
策略 policy-net-1:
策略 policy-net-1-dpdk:
验证接口是否已成功分区
运行以下命令,确认 SR-IOV 设备的接口分区到虚拟功能(VF)。
ip link show <interface>
$ ip link show <interface>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<interface>替换为您在分区为 SR-IOV 设备的 VF 时指定的接口,如ens3f1。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.2.1.4. 在 OpenStack 上使用 SR-IOV 的集群测试 pod 模板 复制链接链接已复制到粘贴板!
以下 testpmd pod 演示了使用巨页、保留 CPU 和 SR-IOV 端口创建容器。
testpmd pod 示例
- 1
- 本例假定性能配置集的名称为
cnf-performance profile。
18.2.1.5. 在 OpenStack 上使用 OVS 硬件卸载的集群测试 pod 模板 复制链接链接已复制到粘贴板!
以下 testpmd pod 在 Red Hat OpenStack Platform (RHOSP) 上演示了 Open vSwitch (OVS) 硬件卸载。
testpmd pod 示例
- 1
- 如果您的性能配置集没有命名为
cnf-performance profile,请将该字符串替换为正确的性能配置集名称。
18.2.1.6. Downward API 的巨页资源注入 复制链接链接已复制到粘贴板!
当 pod 规格包含巨页的资源请求或限制时,Network Resources Injector 会自动在 pod 规格中添加 Downward API 字段,以便为容器提供巨页信息。
Network Resources Injector 添加一个名为 podnetinfo 的卷,并挂载到 pod 中的每个容器的 /etc/podnetinfo。卷使用 Downward API,并包含一个用于大页面请求和限制的文件。文件命名规则如下:
-
/etc/podnetinfo/hugepages_1G_request_<container-name> -
/etc/podnetinfo/hugepages_1G_limit_<container-name> -
/etc/podnetinfo/hugepages_2M_request_<container-name> -
/etc/podnetinfo/hugepages_2M_limit_<container-name>
上一个列表中指定的路径与 app-netutil 库兼容。默认情况下,该库配置为搜索 /etc/podnetinfo 目录中的资源信息。如果您选择自己手动指定 Downward API 路径项目,app-netutil 库除上一个列表中的路径外还会搜索以下路径。
-
/etc/podnetinfo/hugepages_request -
/etc/podnetinfo/hugepages_limit -
/etc/podnetinfo/hugepages_1G_request -
/etc/podnetinfo/hugepages_1G_limit -
/etc/podnetinfo/hugepages_2M_request -
/etc/podnetinfo/hugepages_2M_limit
与 Network Resources Injector 可以创建的路径一样,以上列表中的路径可以选择以一个 _<container-name> 后缀结尾。
18.2.2. 配置 SR-IOV 网络设备 复制链接链接已复制到粘贴板!
SR-IOV Network Operator 把 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD 添加到 OpenShift Container Platform。您可以通过创建一个 SriovNetworkNodePolicy 自定义资源 (CR) 来配置 SR-IOV 网络设备。
在应用由 SriovNetworkNodePolicy 对象中指定的配置时,SR-IOV Operator 可能会排空节点,并在某些情况下会重启节点。仅在以下情况下重启:
-
使用 Mellanox NIC (
mlx5驱动程序) 时,每次当在一个物理功能(PF)中的虚拟功能 (VF) 数量增加时,节点都会重启。 -
使用 Intel NIC 时,只有在内核参数不包含
intel_iommu=on和iommu=pt时,才会重启。
它可能需要几分钟时间来应用配置更改。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。 - 已安装 SR-IOV Network Operator。
- 集群中有足够的可用节点,用于处理从排空节点中驱除的工作负载。
- 您还没有为 SR-IOV 网络设备配置选择任何 control plane 节点。
流程
-
创建一个
SriovNetworkNodePolicy对象,然后在<name>-sriov-node-network.yaml文件中保存 YAML。使用配置的实际名称替换<name>。 -
可选:将 SR-IOV 功能的集群节点标记为
SriovNetworkNodePolicy.Spec.NodeSelector(如果它们还没有标记)。有关标记节点的更多信息,请参阅"了解如何更新节点上的标签"。 创建
SriovNetworkNodePolicy对象:oc create -f <name>-sriov-node-network.yaml
$ oc create -f <name>-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<name>指定这个配置的名称。在应用配置更新后,
sriov-network-operator命名空间中的所有 Pod 都会变为Running状态。要验证是否已配置了 SR-IOV 网络设备,请输入以下命令。将
<node_name>替换为带有您刚才配置的 SR-IOV 网络设备的节点名称。oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.2.3. 创建与 SR-IOV pod 兼容的非统一内存访问 (NUMA) 复制链接链接已复制到粘贴板!
您可以通过限制 SR-IOV 和从相同 NUMA 节点分配的 CPU 资源,使用 restricted 或 single-numa-node Topology Manager 来创建与 SR-IOV pod 兼容的 NUMA。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您已将 CPU Manager 策略配置为
static。有关 CPU Manager 的详情请参考 "Additional resources" 部分。 您已将 Topology Manager 策略配置为
single-numa-node。注意当
single-numa-node无法满足请求时,您可以将拓扑管理器策略配置为restricted。有关更灵活的 SR-IOV 网络资源调度,请参阅附加资源部分中的 NUMA 感知调度过程中排除 SR-IOV 网络拓扑。
流程
创建以下 SR-IOV pod 规格,然后在
<name>-sriov-pod.yaml文件中保存 YAML。将<name>替换为这个 pod 的名称。以下示例显示了 SR-IOV pod 规格:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建 SR-IOV pod 示例:
oc create -f <filename>
$ oc create -f <filename>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<filename>替换为您在上一步中创建的文件的名称。
确认
sample-pod配置为带有保证 QoS。oc describe pod sample-pod
$ oc describe pod sample-podCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确认
sample-pod被分配了独有的 CPU。oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确认为
sample-pod分配的 SR-IOV 设备和 CPU 位于相同的 NUMA 节点上。oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.2.4. 为 NUMA 感知调度排除 SR-IOV 网络拓扑 复制链接链接已复制到粘贴板!
在 NUMA 感知 pod 调度过程中,可以排除将 SR-IOV 网络的 Non-Uniform Memory Access (NUMA) 节点广告到拓扑管理器,以便实现更灵活的 SR-IOV 网络部署。
在某些情况下,为在单个 NUMA 节点上的一个 pod 最大化 CPU 和内存资源是一个优先操作。如果没有为 Topology Manager 提供有关 pod 的 SR-IOV 网络资源的 NUMA 节点的提示,拓扑管理器可能会将 SR-IOV 网络资源和 pod CPU 和内存资源部署到不同的 NUMA 节点。这可能会添加到网络延迟,因为需要在不同 NUMA 节点之间进行数据传输。但是,当工作负载需要最佳 CPU 和内存性能时,这是可以接受的。
例如,有一个计算节点 compute-1,它有两个 NUMA 节点:numa0 和 numa1。启用了 SR-IOV 的 NIC 存在于 numa0 上。可用于 pod 调度的 CPU 仅存在于 numa1 上。通过将 excludeTopology 规格设置为 true,拓扑管理器可将 pod 的 CPU 和内存资源分配给 numa1,并可将同一 pod 的 SR-IOV 网络资源分配给 numa0。只有将 excludeTopology 规格设置为 true 时,才能实现。否则,拓扑管理器会尝试将所有资源放在同一 NUMA 节点上。
18.2.5. SR-IOV 配置故障排除 复制链接链接已复制到粘贴板!
在进行了配置 SR-IOV 网络设备的步骤后,以下部分会处理一些错误条件。
流程
- 要显示节点状态,请运行以下命令:
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>
其中:
- <node_name>
- 指定具有 SR-IOV 网络设备的节点名称。
如果命令的输出显示"cannot allocate memory",请检查以下项目:
- 确认在 BIOS 中为节点启用了全局 SR-IOV 设置。
- 确认在 BIOS 中为该节点启用了 VT-d。
18.2.6. 后续步骤 复制链接链接已复制到粘贴板!
18.3. 配置 SR-IOV 以太网网络附加 复制链接链接已复制到粘贴板!
您可以为集群中的单根 I/O 虚拟化(SR-IOV)设备配置以太网网络附加。
在执行以下文档中的任何任务前,请确保安装了 SR-IOV Network Operator。
18.3.1. 以太网设备配置对象 复制链接链接已复制到粘贴板!
您可以通过定义 SriovNetwork 对象来配置以太网网络设备。
以下 YAML 描述了 SriovNetwork 对象:
- 1
- 对象的名称。SR-IOV Network Operator 创建一个名称相同的
NetworkAttachmentDefinition对象。 - 2
- 安装 SR-IOV Network Operator 的命名空间。
- 3
- 用于为这个额外网络定义 SR-IOV 硬件的
SriovNetworkNodePolicy对象中的spec.resourceName参数的值。 - 4
- SriovNetwork 对象的目标命名空间。只有目标命名空间中的 pod 可以附加到额外网络。当在
openshift-sriov-network-operator以外的命名空间中安装 SR-IOV Network Operator 时,不得配置此字段。 - 5
- 可选:指定要分配给额外网络的 VLAN ID。默认值为
0,表示额外网络没有 VLAN ID 标签。支持的 VLAN ID 值范围从1到4094。 - 6
- 可选:VF 的 spoof 检查模式。允许的值是字符串
"on"和"off"。重要指定的值必须由引号包括,否则 SR-IOV Network Operator 将拒绝对象。
- 7
- 为 IPAM CNI 插件指定一个配置对象做为一个 YAML 块 scalar。该插件管理附加定义的 IP 地址分配。
- 8
- 可选:虚拟功能(VF)的链接状态。允许的值是
enable、disable和auto。 - 9
- 可选:VF 的最大传输率(以 Mbps 为单位)。
- 10
- 可选:VF 的最低传输率(以 Mbps 为单位)。这个值必须小于或等于最大传输率。注意
Intel NIC 不支持
minTxRate参数。如需更多信息,请参阅 BZ#1772847。 - 11
- 可选:VF 的 IEEE 802.1p 优先级级别。默认值为
0。 - 12
- 可选:VF 的信任模式。允许的值是字符串
"on"和"off"。重要您必须在引号中包含指定的值,或者 SR-IOV Network Operator 拒绝对象。
- 13
- 可选:为这个额外网络配置功能。您可以指定
'{ "ips": true }'来启用 IP 地址支持,或指定'{ "mac": true }'来启用 MAC 地址支持。
18.3.1.1. 为动态分配双栈 IP 地址创建配置 复制链接链接已复制到粘贴板!
您可以动态地将双栈 IP 地址分配给二级网络,以便 pod 可以通过 IPv4 和 IPv6 地址进行通信。
您可以在 ipRanges 参数中配置以下 IP 地址分配类型:
- IPv4 地址
- IPv6 地址
- 多个 IP 地址分配
流程
-
将
type设置为whereabouts。 使用
ipRanges来分配 IP 地址,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 将二级网络附加到 pod。如需更多信息,请参阅"将 pod 添加到二级网络"。
验证
输入以下命令验证所有 IP 地址是否已分配给 pod 命名空间内的网络接口:
$ oc exec -it <pod_name> -- ip a
$ oc exec -it <pod_name> -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<podname>- pod 的名称。
18.3.1.2. 配置网络附加的 IP 地址分配 复制链接链接已复制到粘贴板!
对于二级网络,可以使用 IP 地址管理 (IPAM) CNI 插件来分配 IP 地址,该插件支持多种分配方法,包括动态主机配置协议 (DHCP) 和静态分配。
您可以使用以下 IP 地址分配类型:
- 静态分配。
- 通过 DHCP 服务器进行动态分配。您指定的 DHCP 服务器必须可从额外网络访问。
- 通过 Whereabouts IPAM CNI 插件进行动态分配。
18.3.1.2.1. 静态 IP 地址分配配置 复制链接链接已复制到粘贴板!
下表描述了静态 IP 地址分配的配置:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值必须是 |
|
|
| 指定分配给虚拟接口的 IP 地址的对象数组。支持 IPv4 和 IPv6 IP 地址。 |
|
|
| 指定要在 pod 中配置的路由的一组对象。 |
|
|
| 可选:指定 DNS 配置的对象数组。 |
address 数组需要带有以下字段的对象:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
您指定的 IP 地址和网络前缀。例如,如果您指定了 |
|
|
| 出口网络流量要路由到的默认网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CIDR 格式的 IP 地址范围,如 |
|
|
| 路由网络流量的网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 发送 DNS 查询的一个或多个 IP 地址的数组。 |
|
|
|
要附加到主机名的默认域。例如,如果将域设置为 |
|
|
|
在 DNS 查找查询过程中,附加到非限定主机名(如 |
静态 IP 地址分配配置示例
18.3.1.2.2. 动态 IP 地址(DHCP)分配配置 复制链接链接已复制到粘贴板!
pod 在创建时获取其原始 DHCP 租期。该租期必须由集群中运行的一个小型的 DHCP 服务器部署定期续订。
对于以太网网络附加,SR-IOV Network Operator 不会创建 DHCP 服务器部署。Cluster Network Operator 负责创建最小 DHCP 服务器部署。
要触发 DHCP 服务器的部署,您必须编辑 Cluster Network Operator 配置来创建 shim 网络附加,如下例所示:
shim 网络附加定义示例
其中:
type- 为集群指定动态 IP 地址分配。
下表描述了使用 DHCP 进行动态 IP 地址地址分配的配置参数。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。需要值 |
以下 JSON 示例描述了使用 DHCP 进行动态 IP 地址地址分配的配置 p。
动态 IP 地址(DHCP)分配配置示例
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
18.3.1.2.3. 使用 Whereabouts 进行动态 IP 地址分配配置 复制链接链接已复制到粘贴板!
Whereabouts CNI 插件允许在不使用 DHCP 服务器的情况下动态地将 IP 地址分配给额外网络。
Whereabouts CNI 插件还支持在单独的 NetworkAttachmentDefinition CRD 中多次出现同一 CIDR 范围的重叠 IP 地址范围和配置。这在多租户环境中提供了更大的灵活性和管理功能。
18.3.1.2.3.1. 动态 IP 地址配置对象 复制链接链接已复制到粘贴板!
下表描述了使用 Whereabouts 进行动态 IP 地址分配的配置对象:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。需要 |
|
|
| CIDR 表示法中的 IP 地址和范围。IP 地址是通过这个地址范围来分配的。 |
|
|
| 可选: CIDR 标记中零个或更多 IP 地址和范围的列表。包含在排除地址范围中的 IP 地址。 |
|
|
| 可选:帮助确保每个 pod 的组或域都有自己的一组 IP 地址,即使它们共享相同的 IP 地址范围。设置此字段对于保持网络独立和组织非常重要,特别是在多租户环境中。 |
18.3.1.2.3.2. 使用 Whereabouts 的动态 IP 地址分配配置 复制链接链接已复制到粘贴板!
以下示例显示了使用 Whereabouts 的动态地址分配配置:
Whereabouts 动态 IP 地址分配
18.3.1.2.3.3. 使用 Whereabouts 带有重叠 IP 地址范围的动态 IP 地址分配 复制链接链接已复制到粘贴板!
以下示例显示了一个动态 IP 地址分配,它将重叠的 IP 地址范围用于多租户网络。
NetworkAttachmentDefinition 1
- 1
- 可选。如果设置,必须与
NetworkAttachmentDefinition 2的network_name匹配。
NetworkAttachmentDefinition 2
- 1
- 可选。如果设置,必须与
NetworkAttachmentDefinition 1的network_name匹配。
18.3.1.2.4. 配置 SR-IOV 额外网络 复制链接链接已复制到粘贴板!
您可以通过创建一个 SriovNetwork 对象来配置使用 SR-IOV 硬件的额外网络。创建 SriovNetwork 对象时,SR-IOV Network Operator 会自动创建一个 NetworkAttachmentDefinition 对象。
如果一个 SriovNetwork 对象已被附加到状态为 running 的 pod,则不要修改或删除它。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建一个
SriovNetwork对象,然后在<name>.yaml文件中保存 YAML,其中<name>是这个额外网络的名称。对象规格可能类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建对象:
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这里的
<name>指定额外网络的名称。可选: 要确认与您在上一步中创建的
SriovNetwork对象关联的NetworkAttachmentDefinition对象是否存在,请输入以下命令。将<namespace>替换为您在SriovNetwork对象中指定的 networkNamespace。oc get net-attach-def -n <namespace>
$ oc get net-attach-def -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.3.1.2.5. 将 SR-IOV 网络分配给 VRF 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 CNI VRF 插件为 VRF 域分配 SR-IOV 网络接口。
要做到这一点,将 VRF 配置添加到 SriovNetwork 资源的可选 metaPlugins 参数中。
使用 VRF 的应用程序需要绑定到特定设备。通常的用法是在套接字中使用 SO_BINDTODEVICE 选项。SO_BINDTODEVICE 将套接字绑定到在传递接口名称中指定的设备,例如 eth1。要使用 SO_BINDTODEVICE,应用程序必须具有 CAP_NET_RAW 功能。
OpenShift Container Platform pod 不支持通过 ip vrf exec 命令使用 VRF。要使用 VRF,将应用程序直接绑定到 VRF 接口。
18.3.1.2.5.1. 使用 CNI VRF 插件创建额外的 SR-IOV 网络附加 复制链接链接已复制到粘贴板!
SR-IOV Network Operator 管理额外网络定义。当您指定要创建的额外 SR-IOV 网络时,SR-IOV Network Operator 会自动创建 NetworkAttachmentDefinition 自定义资源(CR)。
不要编辑 SR-IOV Network Operator 所管理的 NetworkAttachmentDefinition 自定义资源。这样做可能会破坏额外网络上的网络流量。
要使用 CNI 虚拟路由和转发(VRF)插件创建额外的 SR-IOV 网络附加,请执行以下步骤。
先决条件
-
安装 OpenShift CLI(
oc)。 - 以具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform 集群。
流程
为额外 SR-IOV 网络附加创建
SriovNetwork自定义资源 (CR) 并插入metaPlugins配置,如下例所示。将 YAML 保存为文件sriov-network-attachment.yaml。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
metaPlugins.type-
将
type参数设置为vrf。 metaPlugins.vrfname-
在
vrfname参数中为 VRF 指定名称。为 VRF 分配接口。如果您没有在 pod 中为 VRF 指定名称,SR-IOV Network Operator 会自动为 VRF 生成名称。
创建
SriovNetwork资源:oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,确认 SR-IOV Network Operator 创建了
NetworkAttachmentDefinitionCR。预期输出显示 NAD CR 的名称和创建年龄(以分钟为单位)。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <namespace>:将<namespace>替换为您在配置网络附加时指定的命名空间,如additional-sriov-network-1。注意SR-IOV Network Operator 创建 CR 之前可能会有延迟。
要验证 VRF CNI 是否已正确配置并附加额外的 SR-IOV 网络附加,请执行以下操作:
- 创建使用 VRF CNI 的 SR-IOV 网络。
- 将网络分配给 pod。
验证 pod 网络附加是否连接到 SR-IOV 额外网络。确保您远程登录 pod 并运行以下命令:预期输出显示 VRF 接口的名称及其在路由表中的唯一 ID。
ip vrf show
$ ip vrf showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令确认 VRF 接口是二级接口的
master接口:输出示例显示5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode。ip link
$ ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.3.1.2.6. 基于以太网的 SR-IOV 附加的运行时配置 复制链接链接已复制到粘贴板!
将 pod 附加到额外网络时,您可以指定运行时配置来为 pod 进行特定的自定义。例如,,您可以请求特定的 MAC 硬件地址。
您可以通过在 pod 规格中设置注解来指定运行时配置。注解键是 k8s.v1.cni.cncf.io/network,它接受一个 JSON 对象来描述运行时配置。
基于以太网的 SR-IOV 网络附加的运行时配置示例
其中:
k8s.v1.cni.cncf.io/networks.name-
SR-IOV 网络附加定义 CR 的名称。示例值为
ibl。 k8s.v1.cni.cncf.io/networks.mac-
可选参数。从 SR-IOV 网络附加定义 CR 中定义的资源类型分配的 SR-IOV 设备的 MAC 地址。要使用这个功能,还必须在
SriovNetwork对象中指定{ "mac": true }。示例值为c2:11:22:33:44:55:66:77。 k8s.v1.cni.cncf.io/networks.ips-
可选参数。从 SR-IOV 网络附加定义 CR 中定义的资源类型分配的 SR-IOV 设备的 IP 地址。支持 IPv4 和 IPv6 IP 地址。要使用这个功能,还必须在
SriovNetwork对象中指定{ "ips": true }。示例值为192.168.10.1/24", "2001::1/64.
18.3.1.2.7. 将 pod 添加到额外网络 复制链接链接已复制到粘贴板!
您可以将 pod 添加到二级网络。pod 继续通过默认网络发送与集群相关的普通网络流量。
创建 pod 时会附加额外网络。但是,如果 pod 已存在,您无法为其附加额外网络。
pod 必须与额外网络处于相同的命名空间。
先决条件
-
安装 OpenShift CLI(
oc)。 - 登录到集群。
流程
为
Pod对象添加注解。只能使用以下注解格式之一:要在没有自定义的情况下附加二级网络,请使用以下格式添加注解:
metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
k8s.v1.cni.cncf.io/networks- 指定要与 pod 关联的二级网络的名称。要指定多个二级网络,请使用逗号分隔每个网络。逗号之间不可包括空格。如果您多次指定相同的二级网络,则该 pod 会将多个网络接口附加到该网络。
要通过自定义来附加二级网络,请添加具有以下格式的注解:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name-
指定
NetworkAttachmentDefinition对象定义的二级网络的名称。 namespace-
指定定义
NetworkAttachmentDefinition对象的命名空间。 default-route-
可选参数。为默认路由指定覆盖,如
192.168.17.1。
运行以下命令来创建 pod。
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<name>替换为 pod 的名称。可选:输入以下命令确认
podCR 中是否存在注解。将<name>替换为 pod 的名称。oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在以下示例中,
example-podpod 附加到net1额外网络:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
k8s.v1.cni.cncf.io/network-status- 指定对象的 JSON 数组。每个对象描述附加到 pod 的二级网络的状态。注解值保存为纯文本值。
18.3.1.2.8. 在 SR-IOV 网络策略更新过程中配置并行节点排空 复制链接链接已复制到粘贴板!
默认情况下,SR-IOV Network Operator 会在每次策略更改前从节点排空工作负载。Operator 一次执行此操作(一个节点),以确保重新配置不会影响工作负载。
在大型集群中,按顺序排空节点可能非常耗时,需要几小时甚至几天。在时间敏感的环境中,您可以在 SriovNetworkPoolConfig 自定义资源 (CR) 中启用并行节点排空,以更快地推出 SR-IOV 网络配置。
要配置并行排空,请使用 SriovNetworkPoolConfig CR 创建节点池。然后,您可以在池中添加节点,并在 Operator 可以并行排空的池中定义最大节点数。使用这个方法,您可以启用并行排空来更快地重新配置,同时确保池中仍有足够的节点来处理任何正在运行的工作负载。
节点只能属于一个 SR-IOV 网络池配置。如果节点不是池的一部分,则节点会添加到虚拟的 default 中,带有配置以仅一次排空一个节点。
节点可能会在排空过程中重启。
该流程要求您创建 SR-IOV 资源,然后并行排空节点。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 SR-IOV Network Operator。
- 节点具有支持 SR-IOV 的硬件。
流程
创建一个定义
SriovNetworkPoolConfig资源的 YAML 文件:sriov-nw-pool.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name-
指定
SriovNetworkPoolConfig对象的名称。 namespace- 指定安装 SR-IOV Network Operator 的命名空间。
maxUnavailable- 为在更新过程中可用的节点指定一个整数或百分比值。例如,如果您有 10 个节点,并且将最大不可用设置为 2,那么可以随时并行排空 2 个节点,保留 8 个节点来处理工作负载。
nodeSelector-
使用节点选择器指定要添加池的节点。本例将具有
worker角色的所有节点添加到池中。
运行以下命令来创建
SriovNetworkPoolConfig资源:oc create -f sriov-nw-pool.yaml
$ oc create -f sriov-nw-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
sriov-test命名空间:oc create namespace sriov-test
$ oc create namespace sriov-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个用于定义
SriovNetworkNodePolicy资源的 YAML 文件,以下是一个 YAML 文件示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SriovNetworkNodePolicy资源:oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个定义
SriovNetwork资源的 YAML 文件:sriov-network.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SriovNetwork资源:oc create -f sriov-network.yaml
$ oc create -f sriov-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,查看您创建的节点池:
oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator
$ oc get sriovNetworkpoolConfig -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出显示节点池的名称,如
pool-1s,其中包括具有worker角色的所有节点,以及节点池的年龄(以秒为单位)。更新
SriovNetworkNodePolicy资源中的虚拟功能数量,以触发集群中的工作负载排空:oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'$ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检查目标集群上的排空状态:
oc get sriovNetworkNodeState -n openshift-sriov-network-operator
$ oc get sriovNetworkNodeState -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 InProgress Drain_Required DrainComplete 3d10h openshift-sriov-network-operator worker-1 InProgress Drain_Required DrainComplete 3d10h
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 InProgress Drain_Required DrainComplete 3d10h openshift-sriov-network-operator worker-1 InProgress Drain_Required DrainComplete 3d10hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 当排空过程完成后,
SYNC STATUS变为Succeeded,DESIRED SYNC STATE和CURRENT SYNC STATE值返回IDLE。
18.3.1.2.9. 排除 NUMA 感知调度的 SR-IOV 网络拓扑 复制链接链接已复制到粘贴板!
要将 SR-IOV 网络资源的 Non-Uniform Memory Access (NUMA)节点排除到拓扑管理器,您可以在 SriovNetworkNodePolicy 自定义资源中配置 excludeTopology 规格。在 NUMA 感知 pod 调度过程中,使用此配置来实现更灵活的 SR-IOV 网络部署。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您已将 CPU Manager 策略配置为
static。有关 CPU Manager 的更多信息,请参阅附加资源部分。 -
您已将 Topology Manager 策略配置为
single-numa-node。 - 已安装 SR-IOV Network Operator。
流程
创建
SriovNetworkNodePolicyCR:将以下 YAML 保存到
sriov-network-node-policy.yaml文件中,替换 YAML 中的值以匹配您的环境:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果许多
SriovNetworkNodePolicy资源以相同的 SR-IOV 网络资源为目标,则SriovNetworkNodePolicy资源必须具有与excludeTopology规格相同的值。否则,冲突策略将被拒绝。运行以下命令来创建
SriovNetworkNodePolicy资源。成功输出列出了SriovNetworkNodePolicy资源的名称以及创建的状态。oc create -f sriov-network-node-policy.yaml
$ oc create -f sriov-network-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建
SriovNetworkCR:将以下 YAML 保存到
sriov-network.yaml文件中,替换 YAML 中的值以匹配您的环境:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SriovNetwork资源。成功输出列出了SriovNetwork资源的名称以及创建的状态。oc create -f sriov-network.yaml
$ oc create -f sriov-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 pod 并从上一步中分配 SR-IOV 网络资源:
将以下 YAML 保存到
sriov-network-pod.yaml文件中,替换 YAML 中的值以匹配您的环境:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 这是使用
SriovNetworkNodePolicy资源的SriovNetwork资源的名称。
运行以下命令来创建
Pod资源。预期输出显示Pod资源的名称以及创建的状态。oc create -f sriov-network-pod.yaml
$ oc create -f sriov-network-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,将
<pod_name>替换为 pod 的名称来验证 pod 的状态:oc get pod <pod_name>
$ oc get pod <pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 打开目标 pod 的 debug 会话,以验证 SR-IOV 网络资源是否已部署到与内存和 CPU 资源不同的节点上。
运行以下命令,使用 pod 打开 debug 会话,将 <pod_name> 替换为目标 pod 名称。
oc debug pod/<pod_name>
$ oc debug pod/<pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
/host设为 debug shell 中的根目录。debug pod 从 pod 中的/host中的主机挂载 root 文件系统。将根目录改为/host,您可以从主机文件系统中运行二进制文件:chroot /host
$ chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,查看有关 CPU 分配的信息:
lscpu | grep NUMA
$ lscpu | grep NUMACopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NUMA node(s): 2 NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,... NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,...
NUMA node(s): 2 NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,... NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,...Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat /proc/self/status | grep Cpus
$ cat /proc/self/status | grep CpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Cpus_allowed: ffff Cpus_allowed_list: 1,3,5,7
Cpus_allowed: ffff Cpus_allowed_list: 1,3,5,7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出显示分配给
NUMA节点的 CPU (1、3、5 和 7),如NUMA node1。SR-IOV 网络资源可以使用另一个NUMA节点的 NIC,如NUMA node0。请注意,ffff十六进制值代表运行进程的 CPU 内核。cat /sys/class/net/net1/device/numa_node
$ cat /sys/class/net/net1/device/numa_nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出显示
NUMA节点的数量,如0。注意如果将
excludeTopology规格设为True,则所需资源可能存在于同一个 NUMA 节点上。
18.4. 配置 SR-IOV InfiniBand 网络附加 复制链接链接已复制到粘贴板!
您可以为集群中的单根 I/O 虚拟化(SR-IOV)设备配置 InfiniBand(IB)网络附加。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
18.4.1. Infiniband 设备配置对象 复制链接链接已复制到粘贴板!
您可以通过定义 SriovIBNetwork 对象来配置 InfiniBand(IB)网络设备。
以下 YAML 描述了 SriovIBNetwork 对象:
其中:
name-
对象的名称。SR-IOV Network Operator 创建一个名称相同的
NetworkAttachmentDefinition对象。 namespace- 安装 SR-IOV Operator 的命名空间。
resourceName-
用于为这个额外网络定义 SR-IOV 硬件的
SriovNetworkNodePolicy对象中的spec.resourceName参数的值。 networkNamespace-
SriovIBNetwork对象的目标命名空间。只有目标命名空间中的 pod 可以附加到网络设备。 ipam- 可选参数。为 IPAM CNI 插件指定一个配置对象做为一个 YAML 块 scalar。该插件管理附加定义的 IP 地址分配。
linkState-
可选参数。虚拟功能(VF)的链接状态。允许的值是
enable、disable和auto。 功能-
可选参数。为此网络配置功能。您可以指定
'{ "ips": true }'来启用 IP 地址支持,或'{ "infinibandGUID": true }'来启用 IB Global Unique Identifier (GUID)支持。
18.4.1.1. 为动态分配双栈 IP 地址创建配置 复制链接链接已复制到粘贴板!
您可以动态地将双栈 IP 地址分配给二级网络,以便 pod 可以通过 IPv4 和 IPv6 地址进行通信。
您可以在 ipRanges 参数中配置以下 IP 地址分配类型:
- IPv4 地址
- IPv6 地址
- 多个 IP 地址分配
流程
-
将
type设置为whereabouts。 使用
ipRanges来分配 IP 地址,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 将二级网络附加到 pod。如需更多信息,请参阅"将 pod 添加到二级网络"。
验证
输入以下命令验证所有 IP 地址是否已分配给 pod 命名空间内的网络接口:
$ oc exec -it <pod_name> -- ip a
$ oc exec -it <pod_name> -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<podname>- pod 的名称。
18.4.1.2. 配置网络附加的 IP 地址分配 复制链接链接已复制到粘贴板!
对于二级网络,可以使用 IP 地址管理 (IPAM) CNI 插件来分配 IP 地址,该插件支持多种分配方法,包括动态主机配置协议 (DHCP) 和静态分配。
您可以使用以下 IP 地址分配类型:
- 静态分配。
- 通过 DHCP 服务器进行动态分配。您指定的 DHCP 服务器必须可从额外网络访问。
- 通过 Whereabouts IPAM CNI 插件进行动态分配。
18.4.1.2.1. 静态 IP 地址分配配置 复制链接链接已复制到粘贴板!
下表描述了静态 IP 地址分配的配置:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值必须是 |
|
|
| 指定分配给虚拟接口的 IP 地址的对象数组。支持 IPv4 和 IPv6 IP 地址。 |
|
|
| 指定要在 pod 中配置的路由的一组对象。 |
|
|
| 可选:指定 DNS 配置的对象数组。 |
address 数组需要带有以下字段的对象:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
您指定的 IP 地址和网络前缀。例如,如果您指定了 |
|
|
| 出口网络流量要路由到的默认网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CIDR 格式的 IP 地址范围,如 |
|
|
| 路由网络流量的网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 发送 DNS 查询的一个或多个 IP 地址的数组。 |
|
|
|
要附加到主机名的默认域。例如,如果将域设置为 |
|
|
|
在 DNS 查找查询过程中,附加到非限定主机名(如 |
静态 IP 地址分配配置示例
18.4.1.2.2. 动态 IP 地址(DHCP)分配配置 复制链接链接已复制到粘贴板!
pod 在创建时获取其原始 DHCP 租期。该租期必须由集群中运行的一个小型的 DHCP 服务器部署定期续订。
对于以太网网络附加,SR-IOV Network Operator 不会创建 DHCP 服务器部署。Cluster Network Operator 负责创建最小 DHCP 服务器部署。
要触发 DHCP 服务器的部署,您必须编辑 Cluster Network Operator 配置来创建 shim 网络附加,如下例所示:
shim 网络附加定义示例
其中:
type- 为集群指定动态 IP 地址分配。
下表描述了使用 DHCP 进行动态 IP 地址地址分配的配置参数。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。需要值 |
以下 JSON 示例描述了使用 DHCP 进行动态 IP 地址地址分配的配置 p。
动态 IP 地址(DHCP)分配配置示例
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
18.4.1.2.3. 使用 Whereabouts 进行动态 IP 地址分配配置 复制链接链接已复制到粘贴板!
Whereabouts CNI 插件允许在不使用 DHCP 服务器的情况下动态地将 IP 地址分配给额外网络。
Whereabouts CNI 插件还支持在单独的 NetworkAttachmentDefinition CRD 中多次出现同一 CIDR 范围的重叠 IP 地址范围和配置。这在多租户环境中提供了更大的灵活性和管理功能。
18.4.1.2.3.1. 动态 IP 地址配置对象 复制链接链接已复制到粘贴板!
下表描述了使用 Whereabouts 进行动态 IP 地址分配的配置对象:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。需要 |
|
|
| CIDR 表示法中的 IP 地址和范围。IP 地址是通过这个地址范围来分配的。 |
|
|
| 可选: CIDR 标记中零个或更多 IP 地址和范围的列表。包含在排除地址范围中的 IP 地址。 |
|
|
| 可选:帮助确保每个 pod 的组或域都有自己的一组 IP 地址,即使它们共享相同的 IP 地址范围。设置此字段对于保持网络独立和组织非常重要,特别是在多租户环境中。 |
18.4.1.2.3.2. 使用 Whereabouts 的动态 IP 地址分配配置 复制链接链接已复制到粘贴板!
以下示例显示了使用 Whereabouts 的动态地址分配配置:
Whereabouts 动态 IP 地址分配
18.4.1.2.3.3. 使用 Whereabouts 带有重叠 IP 地址范围的动态 IP 地址分配 复制链接链接已复制到粘贴板!
以下示例显示了一个动态 IP 地址分配,它将重叠的 IP 地址范围用于多租户网络。
NetworkAttachmentDefinition 1
- 1
- 可选。如果设置,必须与
NetworkAttachmentDefinition 2的network_name匹配。
NetworkAttachmentDefinition 2
- 1
- 可选。如果设置,必须与
NetworkAttachmentDefinition 1的network_name匹配。
18.4.1.2.4. 配置 SR-IOV 额外网络 复制链接链接已复制到粘贴板!
您可以通过创建一个 SriovIBNetwork 对象来配置使用 SR-IOV 硬件的额外网络。创建 SriovIBNetwork 对象时,SR-IOV Network Operator 会自动创建一个 NetworkAttachmentDefinition 对象。
如果一个 SriovIBNetwork 对象已被附加到状态为 running 的 pod,则不要修改或删除它。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建一个
SriovIBNetwork对象,然后在<name>.yaml文件中保存 YAML,其中<name>是这个额外网络的名称。对象规格可能类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建对象:
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这里的
<name>指定额外网络的名称。可选: 要确认与您在上一步中创建的
SriovIBNetwork对象关联的NetworkAttachmentDefinition对象是否存在,请输入以下命令。将<namespace>替换为您在SriovIBNetwork对象中指定的 networkNamespace。oc get net-attach-def -n <namespace>
$ oc get net-attach-def -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.4.1.2.5. 基于 InfiniBand 的 SR-IOV 附加的运行时配置 复制链接链接已复制到粘贴板!
将 pod 附加到额外网络时,您可以指定运行时配置来为 pod 进行特定的自定义。例如,,您可以请求特定的 MAC 硬件地址。
您可以通过在 pod 规格中设置注解来指定运行时配置。注解键是 k8s.v1.cni.cncf.io/network,它接受一个 JSON 对象来描述运行时配置。
以下 JSON 描述了基于 InfiniBand 的 SR-IOV 网络附加的运行时配置选项。
其中:
name- SR-IOV 网络附加定义 CR 的名称。
infiniband-guid-
SR-IOV 设备的 InfiniBand GUID。要使用这个功能,还必须在
SriovIBNetwork对象中指定{ "infinibandGUID": true }。 ips-
从 SR-IOV 网络附加定义 CR 中定义的资源类型分配的 SR-IOV 设备的 IP 地址。支持 IPv4 和 IPv6 IP 地址。要使用这个功能,你还必须在
SriovIBNetwork对象中指定{ "ips": true }。
18.4.1.2.6. 将 pod 添加到额外网络 复制链接链接已复制到粘贴板!
您可以将 pod 添加到二级网络。pod 继续通过默认网络发送与集群相关的普通网络流量。
创建 pod 时会附加额外网络。但是,如果 pod 已存在,您无法为其附加额外网络。
pod 必须与额外网络处于相同的命名空间。
先决条件
-
安装 OpenShift CLI(
oc)。 - 登录到集群。
流程
为
Pod对象添加注解。只能使用以下注解格式之一:要在没有自定义的情况下附加二级网络,请使用以下格式添加注解:
metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
k8s.v1.cni.cncf.io/networks- 指定要与 pod 关联的二级网络的名称。要指定多个二级网络,请使用逗号分隔每个网络。逗号之间不可包括空格。如果您多次指定相同的二级网络,则该 pod 会将多个网络接口附加到该网络。
要通过自定义来附加二级网络,请添加具有以下格式的注解:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
name-
指定
NetworkAttachmentDefinition对象定义的二级网络的名称。 namespace-
指定定义
NetworkAttachmentDefinition对象的命名空间。 default-route-
可选参数。为默认路由指定覆盖,如
192.168.17.1。
运行以下命令来创建 pod。
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<name>替换为 pod 的名称。可选:输入以下命令确认
podCR 中是否存在注解。将<name>替换为 pod 的名称。oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在以下示例中,
example-podpod 附加到net1额外网络:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
k8s.v1.cni.cncf.io/network-status- 指定对象的 JSON 数组。每个对象描述附加到 pod 的二级网络的状态。注解值保存为纯文本值。
18.5. 为 SR-IOV 网络配置接口级网络 sysctl 设置和 all-multicast 模式 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用连接到 SR-IOV 网络设备的 pod 的 tuning Container Network Interface (CNI) meta 插件更改接口级网络 sysctl 和几个接口属性,如 promiscuous 模式、all-multicast 模式、MTU 和 MAC 地址。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
18.5.1. 为启用了 SR-IOV 的 NIC 标记节点 复制链接链接已复制到粘贴板!
如果您只想在 SR-IOV 功能的节点上启用 SR-IOV,请执行几种方法:
-
安装 Node Feature Discovery (NFD) Operator。NFD 检测启用了 SR-IOV 的 NIC,并使用
node.alpha.kubernetes-incubator.io/nfd-network-sriov.enabled = true标记节点。 检查每个节点的
SriovNetworkNodeStateCR。interfaces小节包括 worker 节点上 SR-IOV Network Operator 发现的所有 SR-IOV 设备列表。使用以下命令,为每个节点标记feature.node.kubernetes.io/network-sriov.enabled: "true":$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您可以使用您需要的任何名称标记节点。
18.5.2. 设置一个 sysctl 标记 复制链接链接已复制到粘贴板!
您可以为连接到 SR-IOV 网络设备的 pod 设置接口级网络 sysctl 设置。
在本例中,net.ipv4.conf.IFNAME.accept_redirects 在创建的虚拟接口上设置为 1。
sysctl-tuning-test 是本例中使用的命名空间。
使用以下命令来创建
sysctl-tuning-test命名空间:oc create namespace sysctl-tuning-test
$ oc create namespace sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.2.1. 在使用 SR-IOV 网络设备的节点上设置一个 sysctl 标志 复制链接链接已复制到粘贴板!
SR-IOV Network Operator 将 SriovNetworkNodePolicy.sriovnetwork.openshift.io 自定义资源定义(CRD) 添加到 OpenShift Container Platform。您可以通过创建一个 SriovNetworkNodePolicy 自定义资源 (CR) 来配置 SR-IOV 网络设备。
当应用由 SriovNetworkNodePolicy 对象中指定的配置时,SR-IOV Operator 可能会排空并重启节点。
它可能需要几分钟时间来应用配置更改。
按照以下步骤创建一个 SriovNetworkNodePolicy 自定义资源 (CR)。
流程
创建一个
SriovNetworkNodePolicy自定义资源 (CR)。例如,将以下 YAML 保存为文件policyoneflag-sriov-node-network.yaml:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 自定义资源对象的名称。
- 2
- 安装 SR-IOV Network Operator 的命名空间。
- 3
- SR-IOV 网络设备插件的资源名称。您可以为资源名称创建多个 SR-IOV 网络节点策略。
- 4
- 节点选择器指定要配置的节点。只有所选节点上的 SR-IOV 网络设备才会被配置。SR-IOV Container Network Interface(CNI)插件和设备插件仅在所选节点上部署。
- 5
- 可选: priority 是一个
0到99之间的整数。较小的值具有更高的优先级。例如,优先级10是高于优先级99。默认值为99。 - 6
- 为 SR-IOV 物理网络设备创建的虚拟功能(VF)的数量。对于 Intel 网络接口控制器(NIC),VF 的数量不能超过该设备支持的 VF 总数。对于 Mellanox NIC,VF 的数量不能超过
127。 - 7
- NIC 选择器标识要配置的 Operator 的设备。您不必为所有参数指定值。建议您足够精确地识别网络设备以避免意外选择设备。如果指定了
rootDevices,则必须同时为vendor、deviceID或pfNames指定一个值。如果同时指定了pfNames和rootDevices,请确保它们引用同一设备。如果您为netFilter指定了一个值,那么您不需要指定任何其他参数,因为网络 ID 是唯一的。 - 8
- 可选:该设备的一个或多个物理功能(PF)名称的数组。
- 9
- 可选:虚拟功能的驱动程序类型。唯一允许的值是
netdevice。对于裸机节点上的 DPDK 模式的 Mellanox NIC,请将isRdma设置为true。 - 10
- 可选:配置是否启用远程直接访问 (RDMA) 模式。默认值为
false。如果isRdma参数设为true,您可以继续使用启用了 RDMA 的 VF 作为普通网络设备。设备可在其中的一个模式中使用。将isRdma设置为true,并将needVhostNet设置为true以配置 Mellanox NIC 以用于 Fast Datapath DPDK 应用程序。
注意vfio-pci驱动程序类型不被支持。创建
SriovNetworkNodePolicy对象:oc create -f policyoneflag-sriov-node-network.yaml
$ oc create -f policyoneflag-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置更新后,
sriov-network-operator命名空间中的所有 pod 将变为Running状态。要验证是否已配置了 SR-IOV 网络设备,请输入以下命令。将
<node_name>替换为带有您刚才配置的 SR-IOV 网络设备的节点名称。预期输出显示Succeeded。oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.2.2. 在 SR-IOV 网络中配置 sysctl 复制链接链接已复制到粘贴板!
您可以通过将调优配置添加到 SriovNetwork 资源的可选 metaPlugins 参数,在 SR-IOV 创建的虚拟接口上设置特定于接口的 sysctl 设置。
SR-IOV Network Operator 管理额外网络定义。当您指定要创建的额外 SR-IOV 网络时,SR-IOV Network Operator 会自动创建 NetworkAttachmentDefinition 自定义资源(CR)。
不要编辑 SR-IOV Network Operator 所管理的 NetworkAttachmentDefinition 自定义资源。这样做可能会破坏额外网络上的网络流量。
要更改接口级别网络 net.ipv4.conf.IFNAME.accept_redirects sysctl 设置,请使用 Container Network Interface (CNI) 调整插件创建额外的 SR-IOV 网络。
先决条件
- 安装 OpenShift Container Platform CLI(oc)。
- 以具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform 集群。
流程
为额外 SR-IOV 网络附加创建
SriovNetwork自定义资源 (CR) 并插入metaPlugins配置,如下例所示。将 YAML 保存为文件sriov-network-interface-sysctl.yaml。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 对象的名称。SR-IOV Network Operator 创建一个名称相同的 NetworkAttachmentDefinition 对象。
- 2
- 安装 SR-IOV Network Operator 的命名空间。
- 3
- 用于为这个额外网络定义 SR-IOV 硬件的
SriovNetworkNodePolicy对象中的spec.resourceName参数的值。 - 4
SriovNetwork对象的目标命名空间。只有目标命名空间中的 pod 可以附加到额外网络。- 5
- 为 IPAM CNI 插件指定一个配置对象做为一个 YAML 块 scalar。该插件管理附加定义的 IP 地址分配。
- 6
- 可选:为额外网络设置功能。您可以指定
"{ "ips": true }"来启用 IP 地址支持,或指定"{ "mac": true }"来启用 MAC 地址支持。 - 7
- 可选: metaPlugins 参数用于为该设备添加额外的功能。在这种情况下,将
type字段设置为tuning。指定在sysctl字段中设置的接口级网络sysctl。
创建
SriovNetwork资源:oc create -f sriov-network-interface-sysctl.yaml
$ oc create -f sriov-network-interface-sysctl.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证 NetworkAttachmentDefinition CR 是否已成功创建
运行以下命令,确认 SR-IOV Network Operator 创建了
NetworkAttachmentDefinitionCR:oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<namespace>替换为您在SriovNetwork对象中指定的networkNamespace的值。例如:sysctl-tuning-test。预期输出显示 NAD CRD 的名称并创建期限(以分钟为单位)。
注意SR-IOV Network Operator 创建 CR 之前可能会有延迟。
验证额外 SR-IOV 网络附加是否成功
要验证 tuning CNI 是否已正确配置并附加额外的 SR-IOV 网络附加,请执行以下操作:
创建
PodCR。将以下 YAML 保存为文件examplepod.yaml:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
PodCR:oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令验证 pod 是否已创建:
oc get pod -n sysctl-tuning-test
$ oc get pod -n sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令登录到 pod:
oc rsh -n sysctl-tuning-test tunepod
$ oc rsh -n sysctl-tuning-test tunepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证配置的 sysctl 标记的值。运行以下命令,查找
net.ipv4.conf.IFNAME.accept_redirects的值:sysctl net.ipv4.conf.net1.accept_redirects
$ sysctl net.ipv4.conf.net1.accept_redirectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.3. 为与绑定 SR-IOV 接口标记关联的 pod 配置 sysctl 设置 复制链接链接已复制到粘贴板!
您可以为连接到绑定的 SR-IOV 网络设备的 pod 设置接口级网络 sysctl 设置。
在本例中,可以配置的特定网络接口级 sysctl 设置在绑定接口上设置。
sysctl-tuning-test 是本例中使用的命名空间。
使用以下命令来创建
sysctl-tuning-test命名空间:oc create namespace sysctl-tuning-test
$ oc create namespace sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.3.1. 在带有绑定的 SR-IOV 网络设备的节点上设置所有 sysctl 标志 复制链接链接已复制到粘贴板!
SR-IOV Network Operator 将 SriovNetworkNodePolicy.sriovnetwork.openshift.io 自定义资源定义(CRD) 添加到 OpenShift Container Platform。您可以通过创建一个 SriovNetworkNodePolicy 自定义资源 (CR) 来配置 SR-IOV 网络设备。
当应用由 SriovNetworkNodePolicy 对象中指定的配置时,SR-IOV Operator 可能会排空节点,并在某些情况下会重启节点。
它可能需要几分钟时间来应用配置更改。
按照以下步骤创建一个 SriovNetworkNodePolicy 自定义资源 (CR)。
流程
创建一个
SriovNetworkNodePolicy自定义资源 (CR)。将以下 YAML 保存为文件policyallflags-sriov-node-network.yaml。将policyallflags替换为配置的名称。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 自定义资源对象的名称。
- 2
- 安装 SR-IOV Network Operator 的命名空间。
- 3
- SR-IOV 网络设备插件的资源名称。您可以为资源名称创建多个 SR-IOV 网络节点策略。
- 4
- 节点选择器指定要配置的节点。只有所选节点上的 SR-IOV 网络设备才会被配置。SR-IOV Container Network Interface(CNI)插件和设备插件仅在所选节点上部署。
- 5
- 可选: priority 是一个
0到99之间的整数。较小的值具有更高的优先级。例如,优先级10是高于优先级99。默认值为99。 - 6
- 为 SR-IOV 物理网络设备创建的虚拟功能 (VF) 的数量。对于 Intel 网络接口控制器(NIC),VF 的数量不能超过该设备支持的 VF 总数。对于 Mellanox NIC,VF 的数量不能超过
127。 - 7
- NIC 选择器标识要配置的 Operator 的设备。您不必为所有参数指定值。建议您足够精确地识别网络设备以避免意外选择设备。如果指定了
rootDevices,则必须同时为vendor、deviceID或pfNames指定一个值。如果同时指定了pfNames和rootDevices,请确保它们引用同一设备。如果您为netFilter指定了一个值,那么您不需要指定任何其他参数,因为网络 ID 是唯一的。 - 8
- 可选:该设备的一个或多个物理功能(PF)名称的数组。
- 9
- 可选:虚拟功能的驱动程序类型。唯一允许的值是
netdevice。对于裸机节点上的 DPDK 模式的 Mellanox NIC,请将isRdma设置为true。 - 10
- 可选:配置是否启用远程直接访问 (RDMA) 模式。默认值为
false。如果isRdma参数设为true,您可以继续使用启用了 RDMA 的 VF 作为普通网络设备。设备可在其中的一个模式中使用。将isRdma设置为true,并将needVhostNet设置为true以配置 Mellanox NIC 以用于 Fast Datapath DPDK 应用程序。
注意vfio-pci驱动程序类型不被支持。创建 SriovNetworkNodePolicy 对象:
oc create -f policyallflags-sriov-node-network.yaml
$ oc create -f policyallflags-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置更新后,sriov-network-operator 命名空间中的所有 pod 将变为
Running状态。要验证是否已配置了 SR-IOV 网络设备,请输入以下命令。将
<node_name>替换为带有您刚才配置的 SR-IOV 网络设备的节点名称。预期输出显示Succeededoc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.3.2. 在绑定的 SR-IOV 网络中配置 sysctl 复制链接链接已复制到粘贴板!
您可以在从两个 SR-IOV 接口创建的绑定接口上设置特定于接口的 sysctl 设置。为此,可将调优配置添加到绑定网络附加定义的可选 Plugins 参数中。
不要编辑 SR-IOV Network Operator 所管理的 NetworkAttachmentDefinition 自定义资源。这样做可能会破坏额外网络上的网络流量。
要更改特定的接口级网络 sysctl 设置,请按照以下流程使用 Container Network Interface (CNI) 调优插件创建 SriovNetwork 自定义资源 (CR)。
先决条件
- 安装 OpenShift Container Platform CLI(oc)。
- 以具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform 集群。
流程
为绑定接口创建
SriovNetwork自定义资源 (CR),如下例所示。将 YAML 保存为文件sriov-network-attachment.yaml。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 对象的名称。SR-IOV Network Operator 创建一个名称相同的 NetworkAttachmentDefinition 对象。
- 2
- 安装 SR-IOV Network Operator 的命名空间。
- 3
- 用于为这个额外网络定义 SR-IOV 硬件的
SriovNetworkNodePolicy对象中的spec.resourceName参数的值。 - 4
SriovNetwork对象的目标命名空间。只有目标命名空间中的 pod 可以附加到额外网络。- 5
- 可选:为这个额外网络配置功能。您可以指定
"{ "ips": true }"来启用 IP 地址支持,或指定"{ "mac": true }"来启用 MAC 地址支持。
创建
SriovNetwork资源:oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建绑定网络附加定义,如下例所示。将 YAML 保存为文件
sriov-bond-network-interface.yaml。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 类型是
bond。 - 2
mode属性指定绑定模式。支持的绑定模式有:-
balance-rr- 0 -
active-backup- 1 balance-xor- 2对于
balance-rr或balance-xor模式,您必须为 SR-IOV 虚拟功能将trust模式设置为on。
-
- 3
- 对于 active-backup 模式,
failover属性是必需的。 - 4
linksInContainer=true标志告知 Bond CNI 在容器内找到所需的接口。默认情况下,Bond CNI 会查找主机上的这些接口,该接口无法与 SRIOV 和 Multus 集成。- 5
links部分定义将用于创建绑定的接口。默认情况下,Multus 将附加的接口命名为 "net",再加上一个连续的数字。- 6
- 为 IPAM CNI 插件指定一个配置对象做为一个 YAML 块 scalar。该插件管理附加定义的 IP 地址分配。在这个 pod 示例 IP 地址中被手动配置,因此在本例中
ipam被设置为 static。 - 7
- 为设备添加额外的功能。例如,将
type字段设置为tuning。指定在sysctl字段中设置的接口级网络 sysctl。这个示例设置可设置的所有接口级网络sysctl设置。
创建绑定网络附加定义:
oc create -f sriov-bond-network-interface.yaml
$ oc create -f sriov-bond-network-interface.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证 NetworkAttachmentDefinition CR 是否已成功创建
运行以下命令,确认 SR-IOV Network Operator 创建了
NetworkAttachmentDefinitionCR:oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<namespace>替换为您在配置网络附加时指定的 networkNamespace,如sysctl-tuning-test。预期输出显示 NAD CRD 的名称以及创建年龄(以分钟为单位)。
注意SR-IOV Network Operator 创建 CR 之前可能会有延迟。
验证额外的 SR-IOV 网络资源是否成功
要验证 tuning CNI 是否已正确配置并附加额外的 SR-IOV 网络附加,请执行以下操作:
创建
PodCR。例如,将以下 YAML 保存为文件examplepod.yaml:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 YAML:
oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令验证 pod 是否已创建:
oc get pod -n sysctl-tuning-test
$ oc get pod -n sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令登录到 pod:
oc rsh -n sysctl-tuning-test tunepod
$ oc rsh -n sysctl-tuning-test tunepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证配置的
sysctl标记的值。运行以下命令,查找net.ipv6.neigh.IFNAME.base_reachable_time_ms的值:sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
$ sysctl net.ipv6.neigh.bond0.base_reachable_time_msCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.4. 关于 all-multicast 模式 复制链接链接已复制到粘贴板!
启用 all-multicast 模式(特别是在无根应用程序上下文中)非常重要。如果没有启用此模式,则需要为 Pod 的安全上下文约束(SCC )授予 NET_ADMIN 功能。如果您要允许 NET_ADMIN 功能授予 pod 权限,以便更改超出其特定要求的更改,您可能会暴露安全漏洞。
tuning CNI 插件支持更改几个接口属性,包括 all-multicast 模式。通过启用此模式,您可以在 SR-IOV 网络设备上配置的虚拟功能 (VF) 上运行的应用程序从其他 VF 上的应用程序接收多播流量,无论是附加到同一还是不同的物理功能。
18.5.4.1. 在 SR-IOV 网络中启用 all-multicast 模式 复制链接链接已复制到粘贴板!
您可以通过以下方法在 SR-IOV 接口中启用 all-multicast 模式:
-
在
SriovNetwork资源的metaPlugins参数中添加调优配置 在调优配置中将
allmulti字段设置为true注意确保创建启用了信任的虚拟功能 (VF)。
SR-IOV Network Operator 管理额外网络定义。当您指定要创建的额外 SR-IOV 网络时,SR-IOV Network Operator 会自动创建 NetworkAttachmentDefinition 自定义资源(CR)。
不要编辑 SR-IOV Network Operator 所管理的 NetworkAttachmentDefinition 自定义资源。这样做可能会破坏额外网络上的网络流量。
按照本指南,在 SR-IOV 网络中启用 all-multicast 模式。
先决条件
- 已安装 OpenShift Container Platform CLI (oc)。
-
以具有
cluster-admin权限的用户身份登录 OpenShift Container Platform 集群。 - 已安装 SR-IOV Network Operator。
-
您已配置了适当的
SriovNetworkNodePolicy对象。
流程
使用以下设置创建一个 YAML 文件,为 Mellanox ConnectX-5 设备定义
SriovNetworkNodePolicy对象。将 YAML 文件保存为sriovnetpolicy-mlx.yaml。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
可选:如果支持 SR-IOV 的集群节点还没有标记,请添加
SriovNetworkNodePolicy.Spec.NodeSelector标签。有关标记节点的更多信息,请参阅"了解如何更新节点上的标签"。 运行以下命令来创建
SriovNetworkNodePolicy对象:oc create -f sriovnetpolicy-mlx.yaml
$ oc create -f sriovnetpolicy-mlx.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置更新后,
sriov-network-operator命名空间中的所有 pod 会自动进入Running状态。运行以下命令来创建
enable-allmulti-test命名空间:oc create namespace enable-allmulti-test
$ oc create namespace enable-allmulti-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为额外 SR-IOV 网络附加创建
SriovNetwork自定义资源 (CR) 并插入metaPlugins配置,如下例所示,并将该文件保存为sriov-enable-all-multicast.yaml。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定对象的名称。SR-IOV Network Operator 创建一个名称相同的
NetworkAttachmentDefinition对象。 - 2
- 指定 SR-IOV Network Operator 安装到的命名空间。
- 3
- 指定来自用于为这个额外网络定义 SR-IOV 硬件的
SriovNetworkNodePolicy对象的spec.resourceName参数的值。 - 4
- 为
SriovNetwork对象指定目标命名空间。只有目标命名空间中的 pod 可以附加到额外网络。 - 5
- 为 IPAM CNI 插件指定一个配置对象作为 YAML 块 scalar。该插件管理附加定义的 IP 地址分配。
- 6
- 可选:为额外网络设置功能。您可以指定
"{ "ips": true }"来启用 IP 地址支持,或指定"{ "mac": true }"来启用 MAC 地址支持。 - 7
- 指定虚拟功能的信任模式。这必须设置为 "on"。
- 8
- 使用
metaPlugins参数为设备添加更多功能。在此用例中,将type字段设置为tuning,并添加allmulti字段,并将它设为true。
运行以下命令来创建
SriovNetwork资源:oc create -f sriov-enable-all-multicast.yaml
$ oc create -f sriov-enable-all-multicast.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证 NetworkAttachmentDefinition CR
运行以下命令,确认 SR-IOV Network Operator 创建了
NetworkAttachmentDefinitionCR:oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<namespace>替换为您在SriovNetwork对象中指定的networkNamespace的值。在本例中,是enable-allmulti-test。预期输出显示 NAD CR 的名称和创建年龄(以分钟为单位)。
注意SR-IOV Network Operator 创建 CR 之前可能会有延迟。
运行以下命令,显示 SR-IOV 网络资源的信息:
oc get sriovnetwork -n openshift-sriov-network-operator
$ oc get sriovnetwork -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证额外的 SR-IOV 网络附加
要验证 tuning CNI 是否已正确配置并附加了额外的 SR-IOV 网络附加,请按照以下步骤执行:
创建
PodCR。将以下 YAML 示例保存到名为examplepod.yaml的文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
PodCR:oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令验证 pod 是否已创建:
oc get pod -n enable-allmulti-test
$ oc get pod -n enable-allmulti-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE samplepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE samplepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令登录到 pod:
oc rsh -n enable-allmulti-test samplepod
$ oc rsh -n enable-allmulti-test samplepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,列出与 pod 关联的所有接口:
ip link
sh-4.4# ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.6. 为启用 SR-IOV 的工作负载配置 QinQ 支持 复制链接链接已复制到粘贴板!
QinQ (正式称为 802.1Q-in-802.1Q)是由 IEEE 802.1ad 定义的联网技术。IEEE 802.1ad 扩展了 IEEE 802.1Q-1998 标准,并通过向已使用 802.1Q 标记的数据包引入额外的 802.1Q 标签增强 VLAN 功能。此方法也称为 VLAN 堆栈或双 VLAN。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
18.6.1. 关于 802.1Q-in-802.1Q 支持 复制链接链接已复制到粘贴板!
在传统的 VLAN 设置中,帧通常包含一个 VLAN 标签,如 VLAN-100,以及其他元数据,如服务质量 (QoS) 位和协议信息。QinQ 引入了第二个 VLAN 标签,其中服务提供商为其使用指定外部标签,提供它们的灵活性,而内部标签则保留给客户的 VLAN 专用。
QinQ 通过使用双 VLAN 标记促进嵌套 VLAN 的创建,从而在网络环境中实现更精细的分段和流量隔离。这种方法对于您需要通过通用基础架构向多个客户提供基于 VLAN 的服务的服务供应商网络特别有用,同时确保流量隔离和隔离。
下图演示了 OpenShift Container Platform 如何使用 SR-IOV 和 QinQ 实现容器化工作负载的高级网络分段和隔离。
图显示双 VLAN 标记 (QinQ) 如何在支持 SR-IOV 的 worker 节点上工作。位于 pod 命名空间中的 SR-IOV 虚拟功能 (VF),ext0 由带有 VLAN ID 和 VLAN 协议的 SR-IOV Container Network Interface (CNI) 配置。这与 S-tag 对应。在 pod 中,VLAN CNI 使用主接口 ext0 创建一个子接口。此子接口使用 802.1Q 协议添加内部 VLAN ID,该协议对应于 C-tag。
这演示了 QinQ 如何在网络内启用更精细的流量分段和隔离。帧结构在右侧详细介绍,突出显示包含 VLAN 标签、EtherType、IP、TCP 和 Payload 部分的包含。QinQ 促进通过共享基础架构向多个客户提供基于 VLAN 的服务,同时确保流量隔离和隔离。
OpenShift Container Platform SR-IOV 解决方案支持在 SriovNetwork 自定义资源 (CR) 上设置 VLAN 协议。虚拟功能 (VF) 可以使用此协议来设置 VLAN 标签,也称为外部标签。然后,Pod 可以使用 VLAN CNI 插件来配置内部标签。
| NIC | 802.1ad/802.1Q | 802.1Q/802.1Q |
|---|---|---|
| Intel X710 | 否 | 支持 |
| Intel E810 | 支持 | 支持 |
| Mellanox | 否 | 支持 |
18.6.2. 为启用 SR-IOV 的工作负载配置 QinQ 支持 复制链接链接已复制到粘贴板!
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。 - 已安装 SR-IOV Network Operator。
流程
使用以下内容创建一个名为
sriovnetpolicy-810-sriov-node-network.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SriovNetworkNodePolicy对象:oc create -f sriovnetpolicy-810-sriov-node-network.yaml
$ oc create -f sriovnetpolicy-810-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 打开一个单独的终端窗口,运行以下命令来监控
openshift-sriov-network-operator命名空间中指定节点的 SR-IOV 网络节点状态的同步状态:watch -n 1 'oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath="{.status.syncStatus}"'$ watch -n 1 'oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath="{.status.syncStatus}"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 同步状态表示从
InProgress更改为Succeeded。创建一个
SriovNetwork对象,并设置名为 S-tag 或Service Tag的外部 VLAN,因为它属于基础架构。重要您必须在交换机的中继接口上配置 VLAN。另外,您可能需要进一步配置一些交换机来支持 QinQ 标记。
使用以下内容创建一个名为
nad-sriovnetwork-1ad-810.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建对象:
oc create -f nad-sriovnetwork-1ad-810.yaml
$ oc create -f nad-sriovnetwork-1ad-810.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
使用内部 VLAN 创建
NetworkAttachmentDefinition对象。内部 VLAN 通常被称为 C-tag 或Customer Tag,它属于 Network Function:使用以下内容,创建一个名为
nad-cvlan100.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定 pod 中的 VF 接口。默认名称为
net1,因为 pod 注解中没有设置名称。
运行以下命令来应用 YAML 文件:
oc apply -f nad-cvlan100.yaml
$ oc apply -f nad-cvlan100.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
按照以下步骤,在节点上验证 QinQ 是否活跃:
使用以下内容创建一个名为
test-qinq-pod.yaml的文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建测试 pod:
oc create -f test-qinq-pod.yaml
$ oc create -f test-qinq-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在存在 pod 的目标节点上进入 debug 会话,运行以下命令显示网络接口
ens5f0的信息:oc debug node/my-cluster-node -- bash -c "ip link show ens5f0"
$ oc debug node/my-cluster-node -- bash -c "ip link show ens5f0"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出中的
vlan protocol 802.1adID 表示接口支持带有协议 802.1ad (QinQ)的 VLAN 标记。VLAN ID 为 171。
18.7. 配置高性能多播 复制链接链接已复制到粘贴板!
您可以在您的单根 I/O 虚拟化(SR-IOV)硬件网络中使用多播。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
18.7.1. 高性能多播 复制链接链接已复制到粘贴板!
OpenShift SDN 网络插件支持默认网络上的 pod 间的多播。目前,多播最适用于低带宽协调或服务发现。它不适用于高带宽的应用程序。对于流传输介质应用程序,如 IPTV 和多方视频会议,可以使用 Single Root I/O Virtualization(SR-IOV)硬件来提供接近原生的性能。
使用额外的 SR-IOV 接口进行多播时:
- pod 必须通过额外的 SR-IOV 接口发送或接收多播软件包。
- 连接 SR-IOV 接口的物理网络决定了多播路由和拓扑结构,不受 OpenShift Container Platform 的控制。
18.7.2. 为多播配置 SR-IOV 接口 复制链接链接已复制到粘贴板!
以下步骤为多播创建一个 SR-IOV 接口示例。
先决条件
-
安装 OpenShift CLI(
oc)。 -
您必须作为
cluster-admin角色用户登录集群。
流程
创建一个
SriovNetworkNodePolicy对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个
SriovNetwork对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建带有多播应用程序的 pod:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 只有在应用程序需要为 SR-IOV 接口分配多播 IP 地址时,才需要
NET_ADMIN功能。否则,可以省略它。
18.8. 使用 DPDK 和 RDMA 复制链接链接已复制到粘贴板!
OpenShift Container Platform 支持容器化 Data Plane Development Kit (DPDK) 应用程序。您可以使用单一根 I/O 虚拟化(SR-IOV)网络硬件和 Data Plane Development Kit (DPDK) 以及远程直接内存访问 (RDMA) 。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
18.8.1. 在 pod 中使用虚拟功能的示例 复制链接链接已复制到粘贴板!
您可以在附加了 SR-IOV VF 的 pod 中运行远程直接内存访问 (RDMA) 或 Data Plane Development Kit (DPDK) 应用程序。
本示例演示了在 RDMA 模式中使用虚拟功能 (VF) 的 pod:
使用 RDMA 模式的 Pod 规格
以下示例演示了在 DPDK 模式中使用 VF 的 pod:
使用 DPDK 模式的 Pod 规格
18.8.2. 在 DPDK 模式中使用 Intel NIC 的虚拟功能 复制链接链接已复制到粘贴板!
先决条件
-
安装 OpenShift CLI(
oc)。 - 安装 SR-IOV Network Operator。
-
以具有
cluster-admin特权的用户身份登录。
流程
创建以下
SriovNetworkNodePolicy对象,然后在intel-dpdk-node-policy.yaml文件中保存 YAML。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将虚拟功能(VF)的驱动器类型指定为
vfio-pci。
注意如需了解
inSriovNetworkNodePolicy的每个选项的详情,请参阅Configuring SR-IOV network devices部分。当应用由
SriovNetworkNodePolicy对象中指定的配置时,SR-IOV Operator 可能会排空节点,并在某些情况下会重启节点。它可能需要几分钟时间来应用配置更改。确保集群中有足够的可用节点,用以预先处理被驱除的工作负载。应用配置更新后,
openshift-sriov-network-operator命名空间中的所有 pod 将变为Running状态。运行以下命令来创建
SriovNetworkNodePolicy对象:oc create -f intel-dpdk-node-policy.yaml
$ oc create -f intel-dpdk-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建以下
SriovNetwork对象,然后在intel-dpdk-network.yaml文件中保存 YAML。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 为 ipam CNI 插件指定一个配置对象做为一个 YAML 块 scalar。该插件管理附加定义的 IP 地址分配。
注意如需
SriovNetwork中的每个选项的详细说明,请参阅"Configuring SR-IOV additional network" 部分。一个可选的库 app-netutil 提供了多种 API 方法来收集有关容器父 pod 的网络信息。
运行以下命令来创建
SriovNetwork对象:oc create -f intel-dpdk-network.yaml
$ oc create -f intel-dpdk-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建以下
Podspec,然后在intel-dpdk-pod.yaml文件中保存 YAML。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定
target_namespace,它与SriovNetwork对象intel-dpdk-network创建于的命令空间相同。如果要在其他命名空间中创建 pod,在Podspec 和SriovNetwork对象中更改target_namespace。 - 2
- 指定包含应用程序和应用程序使用的 DPDK 库的 DPDK 镜像。
- 3
- 指定容器内的应用程序进行大页分配、系统资源分配和网络接口访问所需的额外功能。
- 4
- 在
/mnt/huge下将巨页卷挂载到 DPDK pod。巨页卷由 emptyDir 卷类型支持,medium 为Hugepages。 - 5
- 可选:指定分配给 DPDK pod 的 DPDK 设备数。如果未明确指定,则此资源请求和限制将被 SR-IOV 网络资源注入程序自动添加。SR-IOV 网络资源注入程序是由 SR-IOV Operator 管理的准入控制器组件。它默认是启用的,可以通过把默认的
SriovOperatorConfigCR 中的enableInjector选项设置为false来禁用它。 - 6
- 指定 CPU 数量。DPDK pod 通常需要从 kubelet 分配专用 CPU。这可以通过将 CPU Manager 策略设置为
static,并创建带有有保障的QoS 的 pod 来实现。 - 7
- 指定巨页大小
hugepages-1Gi或hugepages-2Mi以及分配给 DPDK pod 的巨页数量。单独配置2Mi和1Gi巨页。配置1Gi巨页需要在节点中添加内核参数。例如:添加内核参数default_hugepagesz=1GB,hugepagesz=1G和hugepages=16将在系统引导时分配16*1Gi巨页。
运行以下命令来创建 DPDK pod:
oc create -f intel-dpdk-pod.yaml
$ oc create -f intel-dpdk-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.3. 在带有 Mellanox NIC 的 DPDK 模式中使用虚拟功能 复制链接链接已复制到粘贴板!
您可以创建一个网络节点策略,并在带有 Mellanox NIC 的 DPDK 模式中使用虚拟功能创建 Data Plane Development Kit (DPDK) pod。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 已安装 Single Root I/O Virtualization (SR-IOV) Network Operator。
-
您已以具有
cluster-admin权限的用户身份登录。
流程
将以下
SriovNetworkNodePolicyYAML 配置保存到mlx-dpdk-node-policy.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如需了解
SriovNetworkNodePolicy对象中的每个选项的详细说明,请参阅配置 SR-IOV 网络设备。当应用由
SriovNetworkNodePolicy对象中指定的配置时,SR-IOV Operator 可能会排空节点,并在某些情况下会重启节点。它可能需要几分钟时间来应用配置更改。确保集群中有足够的可用节点,用以预先处理被驱除的工作负载。应用配置更新后,
openshift-sriov-network-operator命名空间中的所有 pod 将变为Running状态。运行以下命令来创建
SriovNetworkNodePolicy对象:oc create -f mlx-dpdk-node-policy.yaml
$ oc create -f mlx-dpdk-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将以下
SriovNetworkYAML 配置保存到mlx-dpdk-network.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 为 IP 地址管理 (IPAM) Container Network Interface (CNI) 插件指定一个配置对象作为 YAML 块 scalar。该插件管理附加定义的 IP 地址分配。
注意如需了解
SriovNetwork对象中的每个选项的详细说明,请参阅配置 SR-IOV 网络设备。app-netutil选项库提供了几个 API 方法,用于收集有关容器父 pod 的网络信息。运行以下命令来创建
SriovNetwork对象:oc create -f mlx-dpdk-network.yaml
$ oc create -f mlx-dpdk-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将以下
PodYAML 配置保存到mlx-dpdk-pod.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定
target_namespace,它与SriovNetwork对象mlx-dpdk-network创建于的命令空间相同。要在不同命名空间中创建 pod,在Podspec 和SriovNetwork对象中更改target_namespace。 - 2
- 指定包含应用程序和应用程序使用的 DPDK 库的 DPDK 镜像。
- 3
- 指定容器内的应用程序进行大页分配、系统资源分配和网络接口访问所需的额外功能。
- 4
- 将巨页卷挂载到
/mnt/huge下的 DPDK pod 中。巨页卷由emptyDir卷类型支持,介质是Hugepages。 - 5
- 可选:指定分配给 DPDK pod 的 DPDK 设备数。如果没有明确指定,则 SR-IOV 网络资源注入程序会自动添加此资源请求和限制。SR-IOV 网络资源注入程序是由 SR-IOV Operator 管理的准入控制器组件。它默认是启用的,可以通过把默认的
SriovOperatorConfigCR 中的enableInjector选项设置为false来禁用它。 - 6
- 指定 CPU 数量。DPDK pod 通常需要从 kubelet 分配专用 CPU。要做到这一点,将 CPU Manager 策略设置为
static,并创建带有Guaranteed服务质量 (QoS) 的 pod。 - 7
- 指定巨页大小
hugepages-1Gi或hugepages-2Mi以及分配给 DPDK pod 的巨页数量。单独配置2Mi和1Gi巨页。配置1Gi巨页需要在节点中添加内核参数。
运行以下命令来创建 DPDK pod:
oc create -f mlx-dpdk-pod.yaml
$ oc create -f mlx-dpdk-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.4. 使用TAP CNI 运行具有内核访问权限的 rootless DPDK 工作负载 复制链接链接已复制到粘贴板!
DPDK 应用程序可以使用 virtio-user 作为异常路径,将某些类型的数据包(如日志消息)注入内核进行处理。有关此功能的更多信息,请参阅 Virtio_user 作为例外路径。
在 OpenShift Container Platform 版本 4.14 及更高版本中,您可以使用非特权 pod 和 tap CNI 插件运行 DPDK 应用程序。要启用此功能,您需要在 SriovNetworkNodePolicy 对象中将 needVhostNet 参数设置为 true 来挂载 vhost-net 设备。
图 18.1. DPDK 和TAP 示例配置
先决条件
-
已安装 OpenShift CLI(
oc)。 - 已安装 SR-IOV Network Operator。
-
您以具有
cluster-admin权限的用户身份登录。 确保在所有节点上将
container_use_devices=on设置为 root。注意使用 Machine Config Operator 设置此 SELinux 布尔值。
流程
创建一个文件,如
test-namespace.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建新的
Namespace对象:oc apply -f test-namespace.yaml
$ oc apply -f test-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个文件,如
sriov-node-network-policy.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SriovNetworkNodePolicy对象:oc create -f sriov-node-network-policy.yaml
$ oc create -f sriov-node-network-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建以下
SriovNetwork对象,然后在sriov-network-attachment.yaml文件中保存 YAML:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如需
SriovNetwork中的每个选项的详细说明,请参阅"Configuring SR-IOV additional network" 部分。一个可选的库
app-netutil提供了多种 API 方法来收集有关容器父 pod 的网络信息。运行以下命令来创建
SriovNetwork对象:oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个文件,如
tap-example.yaml,该文件定义网络附加定义,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定创建
SriovNetwork对象的target_namespace。
运行以下命令来创建
NetworkAttachmentDefinition对象:oc apply -f tap-example.yaml
$ oc apply -f tap-example.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个文件,如
dpdk-pod-rootless.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定
target_namespace创建SriovNetwork对象。如果要在其他命名空间中创建 pod,在Podspec 和SriovNetwork对象中更改target_namespace。 - 2
- 设置在这些卷中创建的卷挂载目录和文件的组所有权。
- 3
- 指定用于运行容器的主要组 ID。
- 4
- 指定包含应用程序和应用程序使用的 DPDK 库的 DPDK 镜像。
- 5
- 从容器的 securityContext 中删除所有功能 (
ALL) 意味着容器在正常操作之外没有特殊的特权。 - 6
- 指定容器内的应用程序进行大页分配、系统资源分配和网络接口访问所需的额外功能。这些功能还必须使用
setcap命令在二进制文件中设置。 - 7
- Mellanox 网络接口控制器(NIC)需要
NET_RAW功能。 - 8
- 指定用于运行容器的用户 ID。
- 9
- 此设置表示 pod 中的容器或容器不应被授予对主机系统的特权访问权限。
- 10
- 此设置允许容器在可能已分配的初始非 root 特权外升级其特权。
- 11
- 此设置可确保容器以非 root 用户身份运行。这有助于强制实施最小特权的原则,限制对容器造成潜在的影响,并减少攻击面。
- 12
- 在
/mnt/huge下将巨页卷挂载到 DPDK pod。巨页卷由 emptyDir 卷类型支持,medium 为Hugepages。 - 13
- 可选:指定分配给 DPDK pod 的 DPDK 设备数。如果没有明确指定,则 SR-IOV 网络资源注入程序会自动添加此资源请求和限制。SR-IOV 网络资源注入程序是由 SR-IOV Operator 管理的准入控制器组件。它默认是启用的,可以通过把默认的
SriovOperatorConfigCR 中的enableInjector选项设置为false来禁用它。 - 14
- 指定 CPU 数量。DPDK pod 通常需要从 kubelet 分配专用 CPU。这可以通过将 CPU Manager 策略设置为
static,并创建带有有保障的QoS 的 pod 来实现。 - 15
- 指定巨页大小
hugepages-1Gi或hugepages-2Mi以及分配给 DPDK pod 的巨页数量。单独配置2Mi和1Gi巨页。配置1Gi巨页需要在节点中添加内核参数。例如:添加内核参数default_hugepagesz=1GB,hugepagesz=1G和hugepages=16将在系统引导时分配16*1Gi巨页。 - 16
- 如果您的性能配置集没有命名为
cnf-performance profile,请将该字符串替换为正确的性能配置集名称。
运行以下命令来创建 DPDK pod:
oc create -f dpdk-pod-rootless.yaml
$ oc create -f dpdk-pod-rootless.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.5. 实现特定 DPDK 行率概述 复制链接链接已复制到粘贴板!
要实现特定的 Data Plane Development Kit (DPDK) 行率,部署 Node Tuning Operator 并配置单根 I/O 虚拟化 (SR-IOV)。您还必须为以下资源调整 DPDK 设置:
- 隔离的 CPU
- Hugepages
- 拓扑调度程序
在早期版本的 OpenShift Container Platform 中,Performance Addon Operator 用来实现自动性能优化,以便为 OpenShift Container Platform 应用程序实现低延迟性能。在 OpenShift Container Platform 4.11 及更新的版本中,这个功能是 Node Tuning Operator 的一部分。
DPDK 测试环境
下图显示了流量测试环境的组件:
- 流量生成器:可以生成高容量数据包流量的应用。
- SR-IOV 支持 NIC :与 SR-IOV 兼容的网络接口卡。该卡在物理接口上运行多个虚拟功能。
- 物理功能 (PF) :支持 SR-IOV 接口的网络适配器的 PCI Express (PCIe) 功能。
- 虚拟功能 (VF) :支持 SR-IOV 的网络适配器上的轻量级 PCIe 功能。VF 与网络适配器上的 PCIe PF 关联。VF 代表网络适配器的虚拟实例。
- 交换机 :网络交换机。节点也可以重新连接到回来。
-
testpmd: DPDK 中包含的示例应用程序。testpmd应用可用于在数据包转发模式下测试 DPDK。testpmd应用程序也是如何使用 DPDK 软件开发套件 (SDK) 构建功能全面的应用程序的示例。 - worker 0 和 worker 1:OpenShift Container Platform 节点。
18.8.6. 使用 SR-IOV 和 Node Tuning Operator 实现 DPDK 行率 复制链接链接已复制到粘贴板!
您可以使用 Node Tuning Operator 配置隔离的 CPU、巨页和拓扑调度程序。然后,您可以使用 Node Tuning Operator 和单根 I/O 虚拟化 (SR-IOV) 来实现特定的 Data Plane Development Kit (DPDK) 行率。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 已安装 SR-IOV Network Operator。
-
您已以具有
cluster-admin权限的用户身份登录。 您已部署了独立的 Node Tuning Operator。
注意在以前版本的 OpenShift Container Platform 中,Performance Addon Operator 用来实现自动性能优化,以便为 OpenShift 应用程序实现低延迟性能。在 OpenShift Container Platform 4.11 及更新的版本中,这个功能是 Node Tuning Operator 的一部分。
流程
根据以下示例创建
PerformanceProfile对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 如果系统上启用了超线程,请分配与
isolated和reservedCPU 组的相关符号链接。如果系统包含多个非统一内存访问节点 (NUMA),请将两个 NUMA 中的 CPU 分配给这两个组。您还可以将 Performance Profile Creator 用于此任务。如需更多信息,请参阅创建性能配置集。 - 2
- 您还可以指定将队列设置为保留 CPU 数的设备列表。如需更多信息,请参阅使用 Node Tuning Operator 缩减 NIC 队列。
- 3
- 分配所需的巨页的数量和大小。您可以为巨页指定 NUMA 配置。默认情况下,系统会为系统上的每个 NUMA 节点分配一个偶数数量。如果需要,您可以请求对节点使用实时内核。如需更多信息,请参阅置备具有实时功能的 worker。
-
将
yaml文件保存为mlx-dpdk-perfprofile-policy.yaml。 使用以下命令应用性能配置集:
oc create -f mlx-dpdk-perfprofile-policy.yaml
$ oc create -f mlx-dpdk-perfprofile-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.6.1. 用于容器应用程序的 DPDK 库 复制链接链接已复制到粘贴板!
一个可选的库 app-netutil 提供了几个 API 方法,用于从该 pod 中运行的容器内收集 pod 的网络信息。
此库可以将 SR-IOV 虚拟功能(VF)集成到 Data Plane Development Kit(DPDK)模式中。该程序库提供 Golang API 和 C API。
当前,采用三个 API 方法:
GetCPUInfo()- 此函数决定了哪些 CPU 可供容器使用并返回相关列表。
GetHugepages()-
此函数决定了每个容器在
Podspec 中请求的巨页内存量并返回相应的值。 GetInterfaces()- 此函数决定了容器中的一组接口,并返回相关的列表。返回值包括每个接口的接口类型和特定于类型的数据。
库的存储库包括用于构建容器镜像 dpdk-app-centos 的示例 Dockerfile。根据容器集规格中的环境变量,容器镜像可以运行以下 DPDK 示例应用之一: l2fwd、l3wd 或 testpmd。容器镜像提供了一个将 app-netutil 库集成到容器镜像本身的示例。库也可以集成到 init 容器中。init 容器可以收集所需的数据,并将数据传递给现有的 DPDK 工作负载。
18.8.6.2. 用于虚拟功能的 SR-IOV Network Operator 示例 复制链接链接已复制到粘贴板!
您可以使用单根 I/O 虚拟化 (SR-IOV) Network Operator 从节点上分配和配置虚拟功能 (VF) 的虚拟功能(VF)。
如需有关部署 Operator 的更多信息,请参阅安装 SR-IOV Network Operator。有关配置 SR-IOV 网络设备的更多信息,请参阅配置 SR-IOV 网络设备。
在 Intel VF 和 Mellanox VF 上运行 Data Plane Development Kit (DPDK) 工作负载之间存在一些区别。本节为这两个 VF 类型提供对象配置示例。以下是用于在 Intel NIC 上运行 DPDK 应用程序的 sriovNetworkNodePolicy 对象示例:
以下是 Mellanox NIC 的 sriovNetworkNodePolicy 对象示例:
18.8.6.3. SR-IOV 网络 Operator 示例 复制链接链接已复制到粘贴板!
以下是 sriovNetwork 对象的示例定义。在这种情况下,Intel 和 Mellanox 配置是相同的:
18.8.6.4. DPDK 基础工作负载示例 复制链接链接已复制到粘贴板!
以下是数据平面开发套件 (DPDK) 容器的示例:
不要使用 SLEEP 启动容器集,然后执行到容器集以启动 testpmd 或 DPDK 工作负载。这可添加额外的中断,因为 exec 进程没有固定到任何 CPU。
18.8.6.5. testpmd 脚本示例 复制链接链接已复制到粘贴板!
以下是运行 testpmd 的示例脚本:
这个示例使用两个不同的 sriovNetwork CR。环境变量包含分配给 pod 的虚拟功能 (VF) PCI 地址。如果您在 pod 定义中使用相同的网络,您必须分割 pciAddress。配置流量生成器的正确 MAC 地址非常重要。这个示例使用自定义 MAC 地址。
18.8.7. 在带有 Mellanox NIC 的 RDMA 模式中使用虚拟功能 复制链接链接已复制到粘贴板!
RDMA over Converged Ethernet (RoCE) 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
在 OpenShift Container Platform 上使用 RDMA 时,RDMA over Converged Ethernet (RoCE) 是唯一支持的模式。
先决条件
-
安装 OpenShift CLI(
oc)。 - 安装 SR-IOV Network Operator。
-
以具有
cluster-admin特权的用户身份登录。
流程
创建以下
SriovNetworkNodePolicy对象,然后在mlx-rdma-node-policy.yaml文件中保存 YAML。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如需了解
inSriovNetworkNodePolicy的每个选项的详情,请参阅Configuring SR-IOV network devices部分。当应用由
SriovNetworkNodePolicy对象中指定的配置时,SR-IOV Operator 可能会排空节点,并在某些情况下会重启节点。它可能需要几分钟时间来应用配置更改。确保集群中有足够的可用节点,用以预先处理被驱除的工作负载。应用配置更新后,
openshift-sriov-network-operator命名空间中的所有 pod 将变为Running状态。运行以下命令来创建
SriovNetworkNodePolicy对象:oc create -f mlx-rdma-node-policy.yaml
$ oc create -f mlx-rdma-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建以下
SriovNetwork对象,然后在mlx-rdma-network.yaml文件中保存 YAML。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 为 ipam CNI 插件指定一个配置对象做为一个 YAML 块 scalar。该插件管理附加定义的 IP 地址分配。
注意如需
SriovNetwork中的每个选项的详细说明,请参阅"Configuring SR-IOV additional network" 部分。一个可选的库 app-netutil 提供了多种 API 方法来收集有关容器父 pod 的网络信息。
运行以下命令来创建
SriovNetworkNodePolicy对象:oc create -f mlx-rdma-network.yaml
$ oc create -f mlx-rdma-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建以下
Podspec,然后在mlx-rdma-pod.yaml文件中保存 YAML。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定
target_namespace,它与SriovNetwork对象mlx-rdma-network创建于的命令空间相同。如果要在其他命名空间中创建 pod,在Podspec 和SriovNetwork对象中更改target_namespace。 - 2
- 指定包含应用程序和应用程序使用的 RDMA 库的 RDMA 镜像。
- 3
- 指定容器内的应用程序进行大页分配、系统资源分配和网络接口访问所需的额外功能。
- 4
- 在
/mnt/huge下将巨页卷挂载到 RDMA pod。巨页卷由 emptyDir 卷类型支持,medium 为Hugepages。 - 5
- 指定 CPU 数量。RDMA pod 通常需要从 kubelet 分配专用 CPU。这可以通过将 CPU Manager 策略设置为
static,并创建带有有保障的QoS 的 pod 来实现。 - 6
- 指定巨页大小
hugepages-1Gi或hugepages-2Mi以及分配给 RDMA pod 的巨页数量。单独配置2Mi和1Gi巨页。配置1Gi巨页需要在节点中添加内核参数。
运行以下命令来创建 RDMA pod:
oc create -f mlx-rdma-pod.yaml
$ oc create -f mlx-rdma-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.8. 在 OpenStack 上使用 OVS-DPDK 的集群测试 pod 模板 复制链接链接已复制到粘贴板!
以下 testpmd pod 演示了使用巨页、保留 CPU 和 SR-IOV 端口创建容器。
testpmd pod 示例
18.9. 使用 pod 级别绑定 复制链接链接已复制到粘贴板!
在 pod 级别的绑定对于启用需要高可用性和更多吞吐量的 pod 内的工作负载至关重要。使用 pod 级别绑定,您可以在内核模式接口上从多个根 I/O 虚拟化(SR-IOV)虚拟功能接口创建绑定接口。SR-IOV 虚拟功能传递到 pod,并附加到内核驱动程序中。
需要 pod 级别绑定的一个场景是从不同物理功能的多个 SR-IOV 虚拟功能创建绑定接口。可以利用主机上的两个不同物理功能创建绑定接口,以便在 pod 级别上实现高可用性。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
有关创建 SR-IOV 网络、网络策略、网络附加定义和 pod 等任务的指导,请参阅配置 SR-IOV 网络设备。
18.9.1. 从两个 SR-IOV 接口配置绑定接口 复制链接链接已复制到粘贴板!
绑定可让多个网络接口聚合到一个逻辑 "bonded" 接口。绑定 Container Network Interface (Bond-CNI) 将绑定功能引入容器中。
Bond-CNI 可使用单根 I/O 虚拟化 (SR-IOV) 虚拟功能创建,并将它们放在容器网络命名空间中。
OpenShift Container Platform 仅支持使用 SR-IOV 虚拟功能的 Bond-CNI。SR-IOV Network Operator 提供了管理虚拟功能所需的 SR-IOV CNI 插件。不支持其他 CNI 或接口类型。
先决条件
- 必须安装 SR-IOV Network Operator,并配置为获取容器中的虚拟功能。
- 要配置 SR-IOV 接口,必须为每个接口创建一个 SR-IOV 网络和策略。
- SR-IOV Network Operator 根据定义的 SR-IOV 网络和策略,为每个 SR-IOV 接口创建一个网络附加定义。
-
linkState设置为 SR-IOV 虚拟功能的默认值auto。
18.9.1.1. 创建绑定网络附加定义 复制链接链接已复制到粘贴板!
现在,SR-IOV 虚拟功能可用,您可以创建一个绑定网络附加定义。
- 1
- cni-type 始终设置为
bond。 - 2
mode属性指定绑定模式。注意支持的绑定模式有:
-
balance-rr- 0 -
active-backup- 1 -
balance-xor- 2
对于
balance-rr或balance-xor模式,您必须为 SR-IOV 虚拟功能将trust模式设置为on。-
- 3
- active-backup 模式的
failover属性是必需的,必须设为 1。 - 4
linksInContainer=true标志告知 Bond CNI 在容器内找到所需的接口。默认情况下,Bond CNI 会查找主机上的这些接口,该接口无法与 SRIOV 和 Multus 集成。- 5
links部分定义将用于创建绑定的接口。默认情况下,Multus 将附加的接口命名为 "net",再加上一个连续的数字。
18.9.1.2. 使用绑定接口创建 pod 复制链接链接已复制到粘贴板!
使用名为 example
podbonding.yaml的 YAML 文件创建 pod 来测试设置,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 注意网络注解:它包含两个 SR-IOV 网络附加,以及一个绑定网络附加。绑定附加使用两个 SR-IOV 接口作为绑定的端口接口。
运行以下命令来应用 yaml:
oc apply -f podbonding.yaml
$ oc apply -f podbonding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令检查 pod 接口:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果在 pod 注解中没有配置接口名称,接口名称会自动分配为
net<n>,其中<n>以1开始。可选: 如果要为 example
bond0设置一个特定的接口名称,请编辑k8s.v1.cni.cncf.io/networks注解,并将bond0设为接口名称,如下所示:annotations: k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0annotations: k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.10. 配置硬件卸载 (offloading) 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在兼容节点上配置硬件卸载,以提高数据处理性能并减少主机 CPU 的负载。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
18.10.1. 关于硬件卸载 复制链接链接已复制到粘贴板!
Open vSwitch 硬件卸载是一种处理网络任务的方法,方法是将它们从 CPU 中分离出来,并将它们卸载到网络接口控制器上的专用处理器。因此,集群可从更快的数据传输速度、CPU 工作负载减少并降低计算成本中受益。
此功能的关键元素是网络接口控制器的现代类,称为 SmartNIC。SmartNIC 是一个网络接口控制器,它可以处理计算密集型网络处理任务。与专用图形卡可提高图形性能的方式相同,T SmartNIC 可改进网络性能。在各个情形中,专用处理器提高了特定类型的处理任务的性能。
在 OpenShift Container Platform 中,您可以为具有兼容 SmartNIC 的裸机节点配置硬件卸载。SR-IOV Network Operator 配置并启用硬件卸载。
硬件卸载并不适用于所有工作负载或应用程序类型。只支持以下两种通信类型:
- pod 到 pod
- Pod 到服务,其中服务是一个由常规 pod 支持的 ClusterIP 服务
在所有情况下,只有在将 pod 和服务分配给具有兼容 SmartNIC 的节点时,硬件卸载才会发生。假设节点上带有硬件卸载的 pod 会尝试与常规节点上的服务进行通信。常规节点上,所有处理都会在内核中进行,因此 pod 到服务通信的整体性能仅限于该常规节点的最大性能。硬件卸载与 DPDK 应用程序不兼容。
在节点上启用硬件卸载,但没有配置 pod 使用,可能会导致 pod 流量的吞吐量性能降低。您无法为 OpenShift Container Platform 管理的 pod 配置硬件卸载。
18.10.2. 支持的设备 复制链接链接已复制到粘贴板!
在以下网络接口控制器上支持硬件卸载:
| 制造商 | model | 供应商 ID | 设备 ID |
|---|---|---|---|
| Mellanox | MT27800 系列 [ConnectX-5] | 15b3 | 1017 |
| Mellanox | MT28880 系列 [ConnectX-5 Ex] | 15b3 | 1019 |
| Mellanox | MT2892 系列 [ConnectX-6 Dx] | 15b3 | 101d |
| Mellanox | MT2894 系列 [ConnectX-6 Lx] | 15b3 | 101f |
| Mellanox | ConnectX-6 NIC 模式中的 MT42822 BlueField-2 | 15b3 | a2d6 |
18.10.3. 先决条件 复制链接链接已复制到粘贴板!
- 集群至少有一个裸机带有网络接口控制器,支持进行硬件卸载。
- 已安装 SR-IOV Network Operator。
- 集群使用 OVN-Kubernetes 网络插件。
-
在 OVN-Kubernetes 网络插件配置中,
gatewayConfig.routingViaHost字段被设置为false。
18.10.4. 将 SR-IOV Network Operator 设置为 systemd 模式 复制链接链接已复制到粘贴板!
要支持硬件卸载,您必须首先将 SR-IOV Network Operator 设置为 systemd 模式。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。
流程
创建一个
SriovOperatorConfig自定义资源 (CR) 以部署所有 SR-IOV Operator 组件:创建名为
sriovOperatorConfig.yaml的文件,其中包含以下 YAML:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建资源:
oc apply -f sriovOperatorConfig.yaml
$ oc apply -f sriovOperatorConfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.10.5. 为硬件卸载配置机器配置池 复制链接链接已复制到粘贴板!
要启用硬件卸载,您可以创建一个专用的机器配置池,并将其配置为使用 SR-IOV Network Operator。
先决条件
-
SR-IOV Network Operator 安装并设置为
systemd模式。
流程
为您要使用硬件卸载的机器创建机器配置池。
将节点添加到机器配置池。使用池的节点角色标签标记每个节点:
oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
$ oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选: 要验证是否创建了新池,请运行以下命令:
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将此机器配置池添加到
SriovNetworkPoolConfig自定义资源中:创建一个文件,如
sriov-pool-config.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 用于硬件卸载的机器配置池的名称。
应用配置:
oc create -f <SriovNetworkPoolConfig_name>.yaml
$ oc create -f <SriovNetworkPoolConfig_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意当您应用由
SriovNetworkPoolConfig对象中指定的配置时,SR-IOV Operator 会排空并重启机器配置池中的节点。它可能需要几分钟时间来应用配置更改。
18.10.6. 配置 SR-IOV 网络节点策略 复制链接链接已复制到粘贴板!
您可以通过创建 SR-IOV 网络节点策略来为节点创建 SR-IOV 网络设备配置。要启用硬件卸载,您必须使用值 "switchdev" 定义 .spec.eSwitchMode 字段。
以下流程为带有硬件卸载的网络接口控制器创建 SR-IOV 接口。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。
流程
创建一个文件,如
sriov-node-policy.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用策略的配置:
oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意当您应用由
SriovNetworkPoolConfig对象中指定的配置时,SR-IOV Operator 会排空并重启机器配置池中的节点。它可能需要几分钟时间来应用配置更改。
18.10.6.1. OpenStack 的 SR-IOV 网络节点策略示例 复制链接链接已复制到粘贴板!
以下示例描述了在 Red Hat OpenStack Platform (RHOSP) 上使用硬件卸载的网络接口控制器 (NIC) 的 SR-IOV 接口。
用于 RHOSP 上带有硬件卸载的 NIC 的 SR-IOV 接口
18.10.7. 使用虚拟功能提高网络流量性能 复制链接链接已复制到粘贴板!
按照以下步骤,为 OVN-Kubernetes 管理端口分配虚拟功能,并提高其网络流量性能。
此流程会导致创建两个池:第一个池具有 OVN-Kubernetes 使用的虚拟功能,第二个由剩余的虚拟功能组成。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。
流程
运行以下命令,将
network.operator.openshift.io/smart-nic标签添加到带有 SmartNIC 的每个 worker 节点:oc label node <node-name> network.operator.openshift.io/smart-nic=
$ oc label node <node-name> network.operator.openshift.io/smart-nic=Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc get nodes命令获取可用节点的列表。为管理端口创建一个名为
sriov-node-mgmt-vf-policy.yaml的策略,其内容如下:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建名为
sriov-node-policy.yaml的策略,其内容如下:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意sriov-node-mgmt-vf-policy.yaml文件具有与sriov-node-policy.yaml文件不同的pfNames和resourceName键的值。为这两个策略应用配置:
oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f sriov-node-mgmt-vf-policy.yaml
$ oc create -f sriov-node-mgmt-vf-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在集群中创建 Cluster Network Operator (CNO) ConfigMap 以进行管理配置:
创建名为
hardware-offload-config.yaml的 ConfigMap,其内容如下:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 ConfigMap 的配置:
oc create -f hardware-offload-config.yaml
$ oc create -f hardware-offload-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.10.8. 创建网络附加定义 复制链接链接已复制到粘贴板!
在定义机器配置池和 SR-IOV 网络节点策略后,您可以为您指定的网络接口卡创建网络附加定义。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。
流程
创建一个文件,如
net-attach-def.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用网络附加定义的配置:
oc create -f net-attach-def.yaml
$ oc create -f net-attach-def.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令检查是否存在新定义:
oc get net-attach-def -A
$ oc get net-attach-def -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示了新定义的命名空间、名称和年龄。
18.10.9. 在 pod 中添加网络附加定义 复制链接链接已复制到粘贴板!
创建机器配置池后,SriovNetworkPoolConfig 和 SriovNetworkNodePolicy 自定义资源以及网络附加定义后,您可以通过在 pod 规格中添加网络附加定义来将这些配置应用到 pod。
流程
在 pod 规格中,添加
.metadata.annotations.k8s.v1.cni.cncf.io/networks字段,并为硬件卸载指定您创建的网络附加定义:.... metadata: annotations: v1.multus-cni.io/default-network: net-attach-def/net-attach-def.... metadata: annotations: v1.multus-cni.io/default-network: net-attach-def/net-attach-def1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 该值必须是您为硬件卸载而创建的网络附加定义的名称和命名空间。
18.11. 将 Bluefield-2 从 DPU 切换到 NIC 复制链接链接已复制到粘贴板!
您可以将 Bluefield-2 网络设备从数据处理单元 (DPU) 模式切换到网络接口控制器 (NIC) 模式。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
18.11.1. 将 Bluefield-2 从 DPU 模式切换到 NIC 模式 复制链接链接已复制到粘贴板!
使用以下步骤将 Bluefield-2 从数据处理单元 (DPU) 模式切换到网络接口控制器 (NIC) 模式。
目前,只支持将 Bluefield-2 从 DPU 切换到 NIC 模式。不支持从 NIC 模式切换到 DPU 模式。
先决条件
- 已安装 SR-IOV Network Operator。如需更多信息,请参阅"安装 SR-IOV Network Operator"。
- 您已将 Bluefield-2 更新至最新的固件。如需更多信息,请参阅 NVIDIA BlueField-2 的固件。
流程
输入以下命令为每个计算节点添加以下标签。您必须为每个计算节点运行命令。
oc label node <node_name> node-role.kubernetes.io/sriov=
$ oc label node <node_name> node-role.kubernetes.io/sriov=Copy to Clipboard Copied! Toggle word wrap Toggle overflow
其中:
node_name- 引用计算节点的名称。
为 SR-IOV Network Operator 创建机器配置池,例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将以下
machineconfig.yaml文件应用到计算节点:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 可选:可以选择性地指定特定卡的 PCI 地址,如
ExecStart=/bin/bash -c '/etc/default/switch_in_sriov_config_daemon.sh nic 0000:5e:00.0 || echo done'。默认情况下会选择第一个设备。如果有多个设备,您必须指定要使用的 PCI 地址。在将 Bluefield-2 从 DPU 模式切换到 NIC 模式的所有节点上,PCI 地址必须相同。
- 等待计算节点重启。重启后,计算节点上的 Bluefield-2 网络设备切换到 NIC 模式。
- 可选:您可能需要重启主机硬件,因为最新的 Bluefield-2 固件版本需要硬件重启来切换到 NIC 模式。
第 19 章 OVN-Kubernetes 网络插件 复制链接链接已复制到粘贴板!
19.1. 关于 OVN-Kubernetes 网络插件 复制链接链接已复制到粘贴板!
OpenShift Container Platform 集群在 pod 和服务网络中使用虚拟网络。
Red Hat OpenShift Networking 的一部分,OVN-Kubernetes 网络插件是 OpenShift Container Platform 的默认网络供应商。OVN-Kubernetes 基于 Open Virtual Network(OVN),它提供了一个基于 overlay 的网络实现。使用 OVN-Kubernetes 插件的集群还在每个节点上运行 Open vSwitch (OVS)。OVN 在每个节点上配置 OVS 来实现声明的网络配置。
OVN-Kubernetes 是 OpenShift Container Platform 和单节点 OpenShift 部署的默认网络解决方案。
OVN-Kubernetes (来自 OVS 项目)使用许多相同的结构,如开放流规则,来决定数据包通过网络传输的方式。如需更多信息,请参阅 Open Virtual Network 网站。
OVN-Kubernetes 是 OVS 的一系列守护进程,用于将虚拟网络配置转换为 OpenFlow 规则。OpenFlow 是一种用于与网络交换机和路由器通信的协议,为远程控制网络设备上的网络流量流提供了方法。这意味着网络管理员可以配置、管理和监视网络流量的流。
OVN-Kubernetes 提供了 OpenFlow 提供的更多高级功能。OVN 支持分布式虚拟路由、分布式逻辑交换机、访问控制、动态主机配置协议(DHCP)和 DNS。OVN 在逻辑流中实施分布式虚拟路由,这些路由等同于开放流。例如,如果您有一个向网络上的 DHCP 服务器发送 DHCP 请求的 pod,则请求中的逻辑流规则可帮助 OVN-Kubernetes 处理数据包。这意味着服务器可以响应网关、DNS 服务器、IP 地址和其他信息。
OVN-Kubernetes 在每个节点上运行一个守护进程。数据库和 OVN 控制器都有守护进程集,每个节点上运行的 OVN 控制器。OVN 控制器在节点上对 Open vSwitch 守护进程进行编程,以支持以下网络供应商功能:
- 出口 IP
- 防火墙
- 硬件卸载
- 混合网络
- 互联网协议安全(IPsec)加密
- IPv6
- 多播。
- 网络策略和网络策略日志
- 路由器
19.1.1. OVN-Kubernetes 目的 复制链接链接已复制到粘贴板!
OVN-Kubernetes 网络插件是一个开源、功能齐全的 Kubernetes CNI 插件,它使用 Open Virtual Network (OVN)来管理网络流量。OVN 是一个社区开发、与供应商无关的网络虚拟化解决方案。OVN-Kubernetes 网络插件:
- 使用 OVN(开源虚拟网络)管理网络流量。OVN 是一个社区开发、与供应商无关的网络虚拟化解决方案。
- 实现 Kubernetes 网络策略支持,包括入口和出口规则。
- 使用 Geneve(通用网络虚拟化封装)协议而不是 VXLAN 在节点间创建覆盖网络。
OVN-Kubernetes 网络插件比 OpenShift SDN 提供以下优点。
- 在支持的平台上完全支持 IPv6 单堆栈和 IPv4/IPv6 双栈网络
- 支持 Linux 和 Microsoft Windows 工作负载中的混合集群
- 可选的、集群内通信的 IPsec 加密
- 将网络数据处理从主机 CPU 卸载到兼容的网卡和数据处理单元 (DPU)
19.1.2. 支持的网络插件功能列表 复制链接链接已复制到粘贴板!
Red Hat OpenShift Networking 为网络插件(OpenShift SDN 和 OVN-Kubernetes)提供了两个选项,用于网络插件。下表总结了这两个网络插件的当前功能支持:
| 功能 | OpenShift SDN | OVN-Kubernetes |
|---|---|---|
| 出口 IP | 支持 | 支持 |
| 出口防火墙 | 支持 | 支持 [1] |
| 出口路由器 | 支持 | 支持 [2] |
| 混合网络 | 不支持 | 支持 |
| 集群内通信的 IPsec 加密 | 不支持 | 支持 |
| IPv4 单堆栈 | 支持 | 支持 |
| IPv6 单堆栈 | 不支持 | 支持 [3] |
| IPv4/IPv6 双栈 | 不支持 | 支持的 [4] |
| IPv6/IPv4 双栈 | 不支持 | 支持 [5] |
| Kubernetes 网络策略 | 支持 | 支持 |
| Kubernetes 网络策略日志 | 不支持 | 支持 |
| 硬件卸载 | 不支持 | 支持 |
| 多播 | 支持 | 支持 |
- 在 OpenShift SDN 中,出口防火墙也称为出口网络策略。这和网络策略出口不同。
- OVN-Kubernetes 的出口路由器仅支持重定向模式。
- 裸机平台上的 IPv6 单堆栈网络。
- 裸机、VMware vSphere 上的 IPv4/IPv6 双栈网络(仅限安装程序置备的基础架构安装)、IBM Power®、IBM Z® 和 RHOSP 平台。
- 裸机、VMware vSphere (仅限安装程序置备的基础架构安装)和 IBM Power® 平台上的 IPv6/IPv4 双栈网络。
19.1.3. OVN-Kubernetes IPv6 和双栈限制 复制链接链接已复制到粘贴板!
OVN-Kubernetes 网络插件有以下限制:
对于为双栈网络配置的集群,IPv4 和 IPv6 流量都必须使用与默认网关相同的网络接口。
如果不满足此要求,则
ovnkube-node守护进程集中的主机上的容器集进入CrashLoopBackOff状态。如果您使用
oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml等命令显示 pod,则status字段具有多个有关默认网关的消息,如以下输出所示:I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4
I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4Copy to Clipboard Copied! Toggle word wrap Toggle overflow 唯一的解析是重新配置主机网络,以便两个 IP 系列都针对默认网关使用相同的网络接口。
对于为双栈网络配置的集群,IPv4 和 IPv6 路由表必须包含默认网关。
如果不满足此要求,则
ovnkube-node守护进程集中的主机上的容器集进入CrashLoopBackOff状态。如果您使用
oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml等命令显示 pod,则status字段具有多个有关默认网关的消息,如以下输出所示:I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interface
I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interfaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 唯一的解析是重新配置主机网络,以便两个 IP 系列都包含默认网关。
-
如果您为集群在
MachineConfig自定义资源(CR)的kernelArgument部分中将ipv6.disable参数设置为1,则 OVN-Kubernetes pod 会进入CrashLoopBackOff状态。另外,将集群更新至 OpenShift Container Platform 的更新版本会失败,因为 Network Operator 处于Degraded状态。红帽不支持为集群禁用 IPv6 寻址,因此不要将ipv6.disable参数设置为1。
19.1.4. 会话关联性 复制链接链接已复制到粘贴板!
会话关联性是适用于 Kubernetes Service 对象的功能。如果要确保每次连接到 <service_VIP>:<Port> 时,您可以使用 会话关联性,流量始终被加载到同一后端。如需更多信息,包括如何根据客户端的 IP 地址设置会话关联性,请参阅会话关联性。
19.1.4.1. 会话关联性的粘性超时 复制链接链接已复制到粘贴板!
OpenShift Container Platform 的 OVN-Kubernetes 网络插件根据最后一个数据包计算来自客户端的会话的粘性超时。例如,如果您运行 curl 命令 10 次,则粘性会话计时器从第十个数据包开始,而不是第一个数据包。因此,如果客户端不断联系该服务,则会话永远不会超时。当服务没有收到 timeoutSeconds 参数所设定的时间的数据包时,超时开始。
19.2. OVN-Kubernetes 架构 复制链接链接已复制到粘贴板!
19.2.1. OVN-Kubernetes 架构简介 复制链接链接已复制到粘贴板!
下图显示了 OVN-Kubernetes 架构。
图 19.1. OVK-Kubernetes 架构
主要组件是:
- Cloud Management System (CMS) - OVN 的特定平台客户端,为 OVN 集成提供 CMS 特定的插件。该插件将云管理系统的逻辑网络配置概念转换为 OVN 理解的 CMS 配置数据库中。
-
OVN 北向数据库(
nbdb)容器 - 存储由 CMS 插件传递的逻辑网络配置。 -
OVN 南向数据库(
sbdb)容器 - 存储每个节点上的 Open vSwitch (OVS)系统的物理和逻辑网络配置状态,包括绑定它们的表。 -
OVN 北向守护进程 (
ovn-northd) - 这是nbdb容器和sbdb容器之间的中介客户端。它以传统网络概念的形式将逻辑网络配置(从nbdb容器)转换为sbdb容器中的逻辑数据路径流。ovn-northd守护进程的容器名称为northd,它在ovnkube-nodepod 中运行。 -
ovn-controller - 这是与 OVS 和 hypervisor 交互的 OVN 代理,适用于
sbdb容器所需的任何信息或更新。ovn-controller从sbdb容器读取逻辑流,将它们转换为OpenFlow流,并将它们发送到节点的 OVS 守护进程。容器名称为ovn-controller,它在ovnkube-nodepod 中运行。
OVN 北向数据库、北向数据库和南向数据库在集群中的每个节点上运行,大部分包含对该节点本地的和进程信息。
OVN 北向数据库具有通过云管理系统(CMS)传递到它的逻辑网络配置。OVN 北向数据库包含网络的当前状态,以逻辑端口、逻辑交换机、逻辑路由器等形式显示。ovn-northd (northd 容器) 连接到 OVN 北向数据库和 OVN 南向数据库。它以传统网络概念的形式将逻辑网络配置转换为 OVN 北向数据库中的逻辑数据路径流。
OVN 南向数据库具有网络的物理和逻辑表示,并将它们连接在一起。它包含节点的机箱信息,以及其他结构,如连接到集群中其他节点所需的远程传输交换机端口。OVN 南向数据库还包含所有逻辑流。逻辑流与每个节点上运行的 ovn-controller 进程共享,ovn-controller 将它们转换为 OpenFlow 规则到程序 Open vSwitch(OVS)。
Kubernetes control plane 节点在单独的节点上包含两个 ovnkube-control-plane pod,它为集群中的每个节点执行中央 IP 地址管理 (IPAM) 分配。在任何给定时间,只有一个 ovnkube-control-plane pod 是领导。
19.2.2. 列出 OVN-Kubernetes 项目中的所有资源 复制链接链接已复制到粘贴板!
查找在 OVN-Kubernetes 项目中运行的资源和容器对于帮助您了解 OVN-Kubernetes 网络实施非常重要。
先决条件
-
使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
流程
运行以下命令,以获取 OVN-Kubernetes 项目中的所有资源、端点和
ConfigMap:oc get all,ep,cm -n openshift-ovn-kubernetes
$ oc get all,ep,cm -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 集群中的每个节点都有一个
ovnkube-nodepod。ovnkube-config配置映射具有 OpenShift Container Platform OVN-Kubernetes 配置。运行以下命令,列出
ovnkube-nodepod 中的所有容器:oc get pods ovnkube-node-bcvts -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes$ oc get pods ovnkube-node-bcvts -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出
ovn-controller ovn-acl-logging kube-rbac-proxy-node kube-rbac-proxy-ovn-metrics northd nbdb sbdb ovnkube-controller
ovn-controller ovn-acl-logging kube-rbac-proxy-node kube-rbac-proxy-ovn-metrics northd nbdb sbdb ovnkube-controllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-nodepod 由几个容器组成。它负责托管北向数据库(nbdb容器)、南向数据库(sbdb容器)、北守护进程 (northd容器)、ovn-controller和ovnkube-controller容器。ovnkube-controller容器会监视 API 对象,如 pod、egress IP、命名空间、服务、端点、出口防火墙和网络策略。它还负责为该节点从可用子网池中分配 pod IP。运行以下命令,列出
ovnkube-control-planepod 中的所有容器:oc get pods ovnkube-control-plane-65c6f55656-6d55h -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes$ oc get pods ovnkube-control-plane-65c6f55656-6d55h -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出
kube-rbac-proxy ovnkube-cluster-manager
kube-rbac-proxy ovnkube-cluster-managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-control-planepod 有一个容器(ovnkube-cluster-manager),它驻留在每个 OpenShift Container Platform 节点上。ovnkube-cluster-manager容器分配 pod 子网,将子网 IP 传输交换机到集群中的每个节点。kube-rbac-proxy容器监控ovnkube-cluster-manager容器的指标。
19.2.3. 列出 OVN-Kubernetes 北向数据库内容 复制链接链接已复制到粘贴板!
每个节点都由该节点上 ovnkube-node pod 中运行的 ovnkube-controller 容器控制。若要了解 OVN 逻辑网络实体,您需要检查作为容器在该节点上的 ovnkube-node pod 中运行的北向数据库,以查看您要查看的节点中的对象。
先决条件
-
使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
要在集群中运行 ovn nbctl 或 sbctl 命令,您必须在相关节点上的 nbdb 或 sbdb 容器中打开远程 shell
运行以下命令列出 pod:
oc get po -n openshift-ovn-kubernetes
$ oc get po -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选: 要使用节点信息列出 pod,请运行以下命令:
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,进入 pod 以查看北向数据库:
oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
$ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令以显示北向数据库中的所有对象:
ovn-nbctl show
$ ovn-nbctl showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 此处列出输出太长。列表中包含 NAT 规则、逻辑交换机、负载均衡器等。
您可以使用以下可选命令缩小并专注于特定组件:
运行以下命令以显示逻辑路由器列表:
oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c northd -- ovn-nbctl lr-list
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c northd -- ovn-nbctl lr-listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
45339f4f-7d0b-41d0-b5f9-9fca9ce40ce6 (GR_ci-ln-t487nnb-72292-mdcnq-master-2) 96a0a0f0-e7ed-4fec-8393-3195563de1b8 (ovn_cluster_router)
45339f4f-7d0b-41d0-b5f9-9fca9ce40ce6 (GR_ci-ln-t487nnb-72292-mdcnq-master-2) 96a0a0f0-e7ed-4fec-8393-3195563de1b8 (ovn_cluster_router)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意在这个输出中,您可以看到每个节点中存在路由器,再加上
ovn_cluster_router。运行以下命令以显示逻辑交换机列表:
oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl ls-list
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl ls-listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
bdd7dc3d-d848-4a74-b293-cc15128ea614 (ci-ln-t487nnb-72292-mdcnq-master-2) b349292d-ee03-4914-935f-1940b6cb91e5 (ext_ci-ln-t487nnb-72292-mdcnq-master-2) 0aac0754-ea32-4e33-b086-35eeabf0a140 (join) 992509d7-2c3f-4432-88db-c179e43592e5 (transit_switch)
bdd7dc3d-d848-4a74-b293-cc15128ea614 (ci-ln-t487nnb-72292-mdcnq-master-2) b349292d-ee03-4914-935f-1940b6cb91e5 (ext_ci-ln-t487nnb-72292-mdcnq-master-2) 0aac0754-ea32-4e33-b086-35eeabf0a140 (join) 992509d7-2c3f-4432-88db-c179e43592e5 (transit_switch)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意在这个输出中,您可以看到每个节点的 ext 交换机以及节点名称本身和 join 开关。
运行以下命令以显示负载均衡器列表:
oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl lb-list
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl lb-listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意在这个截断的输出中,您可以看到有许多 OVN-Kubernetes 负载均衡器。OVN-Kubernetes 中的负载均衡器是服务的表示。
运行以下命令,以显示可用于命令
ovn-nbctl的选项:oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb ovn-nbctl --help
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb ovn-nbctl --helpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2.4. ovn-nbctl 的命令行参数检查北向数据库内容 复制链接链接已复制到粘贴板!
下表描述了可与 ovn-nbctl 一起使用的命令行参数,以检查北向数据库的内容。
在您要查看内容的 pod 中打开一个远程 shell,然后运行 ovn-nbctl 命令。
| 参数 | 描述 |
|---|---|
|
| 从特定节点看到的北向数据库内容概述。 |
|
| 显示与指定交换机或路由器关联的详细信息。 |
|
| 显示逻辑路由器。 |
|
|
使用 |
|
| 显示指定路由器的网络地址转换详情。 |
|
| 显示逻辑交换机 |
|
|
使用 |
|
| 获取逻辑端口的类型。 |
|
| 显示负载平衡器。 |
19.2.5. 列出 OVN-Kubernetes 南向数据库内容 复制链接链接已复制到粘贴板!
每个节点都由该节点上 ovnkube-node pod 中运行的 ovnkube-controller 容器控制。若要了解 OVN 逻辑网络实体,您需要检查作为容器在该节点上的 ovnkube-node pod 中运行的北向数据库,以查看您要查看的节点中的对象。
先决条件
-
使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
要在集群中运行 ovn nbctl 或 sbctl 命令,您必须在相关节点上的 nbdb 或 sbdb 容器中打开远程 shell
运行以下命令列出 pod:
oc get po -n openshift-ovn-kubernetes
$ oc get po -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选: 要使用节点信息列出 pod,请运行以下命令:
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 进入 pod 以查看南向数据库:
oc rsh -c sbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
$ oc rsh -c sbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令以显示南向数据库中的所有对象:
ovn-sbctl show
$ ovn-sbctl showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此详细输出显示了附加到机箱的机箱和端口,本例中为所有路由器端口以及像主机网络一样运行的任何内容。任何 pod 使用源网络地址转换(SNAT)与更广泛的网络通信。其 IP 地址转换为运行 Pod 的节点的 IP 地址,然后发送到网络。
除了机箱信息外,南向数据库还具有所有逻辑流,这些逻辑流随后发送到每个节点上运行的
ovn-controller。ovn-controller将逻辑流转换为开放流规则,最终程序OpenvSwitch以便您的 pod 可以遵循开放流规则,并使其从网络移出。运行以下命令以
ovn-sbctl命令显示可用的选项:oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c sbdb ovn-sbctl --help
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c sbdb ovn-sbctl --helpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2.6. ovn-sbctl 的命令行参数,以检查南向数据库内容 复制链接链接已复制到粘贴板!
下表描述了可用于 ovn-sbctl 的命令行参数,以检查南向数据库的内容。
在您要查看内容的 pod 中打开一个远程 shell,然后运行 ovn-sbctl 命令。
| 参数 | 描述 |
|---|---|
|
| 从特定节点看到的南向数据库内容概述。 |
|
| 列出特定端口的南向数据库的内容。 |
|
| 列出逻辑流。 |
19.2.7. OVN-Kubernetes 逻辑架构 复制链接链接已复制到粘贴板!
OVN 是网络虚拟化解决方案。它创建逻辑交换机和路由器。这些交换机和路由器是互连的,以创建任何网络拓扑。当您运行 ovnkube-trace 时,日志级别设置为 2 或 5 时,OVN-Kubernetes 逻辑组件会被公开。下图显示了如何在 OpenShift Container Platform 中连接路由器和交换机。
图 19.2. OVN-Kubernetes 路由器和交换机组件
涉及数据包处理的关键组件有:
- 网关路由器
-
网关路由器有时称为 L3 网关路由器,通常在分布式路由器和物理网络之间使用。网关路由器(包括其逻辑补丁端口)绑定到物理位置(而非分布式)或机箱。此路由器上的跳接端口称为 ovn-southbound 数据库(
ovn-sbdb)中的 l3gateway 端口。 - 分布式逻辑路由器
- 分布式逻辑路由器和其后面的逻辑交换机(虚拟机和容器附加)有效驻留在每个虚拟机监控程序上。
- 加入本地交换机
- 加入本地交换机用于连接分布式路由器和网关路由器。它可减少分布式路由器中所需的 IP 地址数量。
- 使用跳接端口的逻辑交换机
- 带有补丁端口的逻辑交换机用于虚拟化网络堆栈。它们通过隧道连接远程逻辑端口。
- 使用 localnet 端口的逻辑交换机
- 使用 localnet 端口的逻辑交换机用于将 OVN 连接到物理网络。它们通过将数据包桥接到使用 localnet 端口直接连接的物理 L2 片段来连接远程逻辑端口。
- 补丁端口
- 跳接端口代表逻辑交换机和逻辑路由器之间以及对等逻辑路由器之间的连接。单个连接在每个此类连接点上都有一对跳接端口。
- l3gateway 端口
-
l3gateway 端口是
ovn-sbdb中用于网关路由器中使用的逻辑补丁端口的端口绑定条目。它们称为 l3gateway 端口,而不是跳接端口,而只是这些端口绑定到机箱,就像网关路由器本身一样。 - localnet 端口
-
桥接逻辑交换机上存在 localnet 端口,允许从每个
ovn-controller实例连接到本地可访问的网络。这有助于从逻辑交换机对物理网络的直接连接建模。逻辑交换机只能附加一个 localnet 端口。
19.2.7.1. 在本地主机上安装 network-tools 复制链接链接已复制到粘贴板!
在本地主机上安装 network-tools,以提供一组工具来调试 OpenShift Container Platform 集群网络问题。
流程
使用以下命令将
network-tools存储库克隆到工作站:git clone git@github.com:openshift/network-tools.git
$ git clone git@github.com:openshift/network-tools.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow 更改到您刚才克隆的存储库的目录:
cd network-tools
$ cd network-toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:列出所有可用的命令:
./debug-scripts/network-tools -h
$ ./debug-scripts/network-tools -hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2.7.2. 运行 network-tools 复制链接链接已复制到粘贴板!
通过运行 network-tools 来获取逻辑交换机和路由器的信息。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin权限的用户身份登录集群。 -
您已在本地主机上安装了
network-tools。
流程
运行以下命令列出路由器:
./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-list
$ ./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
944a7b53-7948-4ad2-a494-82b55eeccf87 (GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99) 84bd4a4c-4b0b-4a47-b0cf-a2c32709fc53 (ovn_cluster_router)
944a7b53-7948-4ad2-a494-82b55eeccf87 (GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99) 84bd4a4c-4b0b-4a47-b0cf-a2c32709fc53 (ovn_cluster_router)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令列出 localnet 端口:
./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=localnet
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=localnetCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令列出
l3gateway端口:./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=l3gateway
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=l3gatewayCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令列出跳接端口:
./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=patch
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=patchCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3. OVN-Kubernetes 故障排除 复制链接链接已复制到粘贴板!
OVN-Kubernetes 具有许多内置健康检查和日志来源。按照这些部分中的说明检查集群。如果需要一个支持问题单,请参阅 支持指南来通过 must-gather 收集其他信息。仅在支持团队要求这样做时,才使用 -- gather_network_logs。
19.3.1. 使用就绪度探测监控 OVN-Kubernetes 健康状况 复制链接链接已复制到粘贴板!
ovnkube-control-plane 和 ovnkube-node pod 配置有就绪度探测的容器。
先决条件
-
访问 OpenShift CLI(
oc)。 -
您可以使用
cluster-admin权限访问集群。 -
您已安装了
jq。
流程
运行以下命令,查看
ovnkube-node就绪度探测的详情:oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \ -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
$ oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \ -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-nodepod 中的北向和南向数据库容器的就绪度探测会检查数据库和ovnkube-controller容器的健康状态。ovnkube-nodepod 中的ovnkube-controller容器有一个就绪度探测来验证 OVN-Kubernetes CNI 配置文件是否存在,这代表 pod 没有运行,或者没有准备好接受配置 pod 的请求。使用以下命令,显示命名空间的所有事件,包括探测失败:
oc get events -n openshift-ovn-kubernetes
$ oc get events -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仅显示特定 pod 的事件:
oc describe pod ovnkube-node-9lqfk -n openshift-ovn-kubernetes
$ oc describe pod ovnkube-node-9lqfk -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 显示集群网络 Operator 的消息和状态:
oc get co/network -o json | jq '.status.conditions[]'
$ oc get co/network -o json | jq '.status.conditions[]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下脚本,显示
ovnkube-nodepod 中每个容器的就绪状态:for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===; \ oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \ done$ for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===; \ oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \ doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意预期的是所有容器状态都报告为
true。就绪度探测失败,将状态设置为false。
19.3.2. 在控制台中查看 OVN-Kubernetes 警报 复制链接链接已复制到粘贴板!
Alerting UI 提供有关警报及其相关警报规则和静默的详细信息。
先决条件
- 对于您要查看指标的项目,您可以作为开发者或具有查看权限的用户访问集群。
流程 (UI)
- 在 Administrator 视角中,选择 Observe → Alerting。在此视角中,Alerting UI 有三个主要页面,即 Alerts、Silences 和 Alerting Rules 页面。
- 选择 Observe → Alerting → Alerting Rules 来查看 OVN-Kubernetes 警报的规则。
19.3.3. 在 CLI 中查看 OVN-Kubernetes 警报 复制链接链接已复制到粘贴板!
您可以从命令行获取有关警报及其监管警报规则和静默的信息。
先决条件
-
使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。 -
您已安装了
jq。
流程
运行以下命令,查看活动或触发警报:
运行以下命令设置警报管理器路由环境变量:
ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \ -o jsonpath='{@.spec.host}')$ ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \ -o jsonpath='{@.spec.host}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将
$ALERT_MANAGER替换为Alertmanager实例的 URL,向警报管理器路由 API 发出curl请求:curl -s -k -H "Authorization: Bearer $(oc create token prometheus-k8s -n openshift-monitoring)" https://$ALERT_MANAGER/api/v1/alerts | jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'
$ curl -s -k -H "Authorization: Bearer $(oc create token prometheus-k8s -n openshift-monitoring)" https://$ALERT_MANAGER/api/v1/alerts | jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令来查看警报规则:
oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.4. 使用 CLI 查看 OVN-Kubernetes 日志 复制链接链接已复制到粘贴板!
您可以使用 OpenShift CLI (oc)查看 ovnkube-master 和 ovnkube-node pod 中每个 pod 的日志。
先决条件
-
使用具有
cluster-admin角色的用户访问集群。 -
访问 OpenShift CLI(
oc)。 -
您已安装了
jq。
流程
查看特定 pod 的日志:
oc logs -f <pod_name> -c <container_name> -n <namespace>
$ oc logs -f <pod_name> -c <container_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
-f- 可选:指定输出是否遵循要写到日志中的内容。
<pod_name>- 指定 pod 的名称。
<container_name>- 可选:指定容器的名称。当 pod 具有多个容器时,您必须指定容器名称。
<namespace>- 指定 pod 运行的命名空间。
例如:
oc logs ovnkube-node-5dx44 -n openshift-ovn-kubernetes
$ oc logs ovnkube-node-5dx44 -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc logs -f ovnkube-node-5dx44 -c ovnkube-controller -n openshift-ovn-kubernetes
$ oc logs -f ovnkube-node-5dx44 -c ovnkube-controller -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出的日志文件内容。
检查
ovnkube-nodepod 中所有容器的最新条目:for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \ do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \ -o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \ oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; done$ for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \ do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \ -o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \ oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令,查看
ovnkube-nodepod 中每个容器的最后 5 行:oc logs -l app=ovnkube-node -n openshift-ovn-kubernetes --all-containers --tail 5
$ oc logs -l app=ovnkube-node -n openshift-ovn-kubernetes --all-containers --tail 5Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.5. 使用 Web 控制台查看 OVN-Kubernetes 日志 复制链接链接已复制到粘贴板!
您可以在 web 控制台中查看 ovnkube-master 和 ovnkube-node pod 中每个 pod 的日志。
先决条件
-
访问 OpenShift CLI(
oc)。
流程
- 在 OpenShift Container Platform 控制台中,导航到 Workloads → Pods,或通过您要调查的资源导航到 pod。
-
从下拉菜单中选择
openshift-ovn-kubernetes项目。 - 点您要调查的 pod 的名称。
-
点 Logs。默认情况下,
ovnkube-master显示与northd容器关联的日志。 - 使用向下下拉菜单选择每个容器的日志。
19.3.5.1. 更改 OVN-Kubernetes 日志级别 复制链接链接已复制到粘贴板!
OVN-Kubernetes 的默认日志级别为 4。要调试 OVN-Kubernetes,请将日志级别设置为 5。按照以下步骤增加 OVN-Kubernetes 的日志级别,以帮助您调试问题。
先决条件
-
您可以使用
cluster-admin权限访问集群。 - 访问 OpenShift Container Platform web 控制台。
流程
运行以下命令,以获取 OVN-Kubernetes 项目中所有 pod 的详细信息:
oc get po -o wide -n openshift-ovn-kubernetes
$ oc get po -o wide -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建类似以下示例的
ConfigMap文件,并使用文件名,如env-overrides.yaml:ConfigMap文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令应用
ConfigMap文件:oc apply -n openshift-ovn-kubernetes -f env-overrides.yaml
$ oc apply -n openshift-ovn-kubernetes -f env-overrides.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
configmap/env-overrides.yaml created
configmap/env-overrides.yaml createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令重启
ovnkubepod 以应用新的日志级别:oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-0 -l app=ovnkube-node
$ oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-0 -l app=ovnkube-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-2 -l app=ovnkube-node
$ oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-2 -l app=ovnkube-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-node
$ oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证 'ConfigMap'file 是否已应用到特定 pod 的所有节点,请运行以下命令:
oc logs -n openshift-ovn-kubernetes --all-containers --prefix ovnkube-node-<xxxx> | grep -E -m 10 '(Logging config:|vconsole|DBG)'
$ oc logs -n openshift-ovn-kubernetes --all-containers --prefix ovnkube-node-<xxxx> | grep -E -m 10 '(Logging config:|vconsole|DBG)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<XXXX>指定上一步中 pod 的随机字符序列。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
可选:运行以下命令来检查
ConfigMap文件是否已应用:for f in $(oc -n openshift-ovn-kubernetes get po -l 'app=ovnkube-node' --no-headers -o custom-columns=N:.metadata.name) ; do echo "---- $f ----" ; oc -n openshift-ovn-kubernetes exec -c ovnkube-controller $f -- pgrep -a -f init-ovnkube-controller | grep -P -o '^.*loglevel\s+\d' ; done
for f in $(oc -n openshift-ovn-kubernetes get po -l 'app=ovnkube-node' --no-headers -o custom-columns=N:.metadata.name) ; do echo "---- $f ----" ; oc -n openshift-ovn-kubernetes exec -c ovnkube-controller $f -- pgrep -a -f init-ovnkube-controller | grep -P -o '^.*loglevel\s+\d' ; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.6. 检查 OVN-Kubernetes pod 网络连接 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 4.10 及更新的版本中,连接检查控制器会在集群中编配连接验证检查。这包括 Kubernetes API、OpenShift API 和单个节点。连接测试的结果存储在 openshift-network-diagnostics 命名空间中的 PodNetworkConnectivity 对象中。连接测试会每分钟以并行方式执行。
先决条件
-
访问 OpenShift CLI(
oc)。 -
使用具有
cluster-admin角色的用户访问集群。 -
您已安装了
jq。
流程
要列出当前的
PodNetworkConnectivityCheck对象,请输入以下命令:oc get podnetworkconnectivitychecks -n openshift-network-diagnostics
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnosticsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令查看每个连接对象的最新成功:
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令查看每个连接对象的最新故障:
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令查看每个连接对象的最新中断:
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 连接检查控制器也会将来自这些检查的指标记录到 Prometheus 中。
运行以下命令来查看所有指标:
oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'$ oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 查看源 pod 和 openshift api 服务之间的延迟,持续 5 分钟:
oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'$ oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.4. 使用 ovnkube-trace 追踪 Openflow 复制链接链接已复制到粘贴板!
OVN 和 OVS 流量流可以在一个名为 ovnkube-trace 的单个实用程序中模拟。ovnkube-trace 工具运行 ovn-trace、ovs-appctl ofproto/trace 和 ovn-detrace,并在单个输出中关联这些信息。
您可以从专用容器执行 ovnkube-trace 二进制文件。对于 OpenShift Container Platform 4.7 后的版本,您还可以将该二进制文件复制到本地主机中,并从该主机执行它。
19.4.1. 在本地主机上安装 ovnkube-trace 复制链接链接已复制到粘贴板!
ovnkube-trace 工具跟踪在 OVN-Kubernetes 驱动的 OpenShift Container Platform 集群中点之间的任意 UDP 或 TCP 流量的数据包模拟。将 ovnkube-trace 二进制文件复制到本地主机,使其可以针对集群运行。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
使用以下命令创建 pod 变量:
POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-control-plane -o name | head -1 | awk -F '/' '{print $NF}')$ POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-control-plane -o name | head -1 | awk -F '/' '{print $NF}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在本地主机上运行以下命令,从
ovnkube-control-planepod 复制二进制文件:oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace -c ovnkube-cluster-manager ovnkube-trace
$ oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace -c ovnkube-cluster-manager ovnkube-traceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果您使用 Red Hat Enterprise Linux (RHEL) 8 运行
ovnkube-trace工具,您必须将文件/usr/lib/rhel8/ovnkube-trace复制到本地主机。运行以下命令,使
ovnkube-trace可执行:chmod +x ovnkube-trace
$ chmod +x ovnkube-traceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,显示
ovnkube-trace可用的选项:./ovnkube-trace -help
$ ./ovnkube-trace -helpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 支持的命令行参数是熟悉的 Kubernetes 构造,如命名空间、Pod、服务,因此您不需要查找 MAC 地址、目标节点的 IP 地址或 ICMP 类型。
日志级别为:
- 0 (最小输出)
- 2 (显示 trace 命令结果的详细输出)
- 5 (调试输出)
19.4.2. 运行 ovnkube-trace 复制链接链接已复制到粘贴板!
运行 ovn-trace 以模拟 OVN 逻辑网络内的数据包转发。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。 -
您已在本地主机上安装了
ovnkube-trace
示例:测试 DNS 解析是否适用于部署的 pod
本例演示了如何从部署的 pod 测试 DNS 解析到集群中运行的核心 DNS pod。
流程
输入以下命令在 default 命名空间中启动 web 服务:
oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 列出在
openshift-dns命名空间中运行的 pod:oc get pods -n openshift-dns
oc get pods -n openshift-dnsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下
ovnkube-trace命令来验证 DNS 解析是否正常工作:Copy to Clipboard Copied! Toggle word wrap Toggle overflow src&dstpod 在同一节点上放置时的输出示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow src&dstpod 放置到另一个节点上时的输出示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ouput 表示从部署的 pod 到 DNS 端口的成功,也表示它已成功返回其他方向。因此,如果我的 Web pod 想要从核心 DNS 进行 dns 解析,则 UDP 端口 53 上支持双向流量。
例如,如果无法正常工作,并且您想要获取 ovn-trace、proto/trace 和 ovn-detrace 的 ovs-appctl,以及更多故障排除类型信息,将日志级别增加到 2,然后再次运行命令,如下所示:
这个日志级别的输出太大,无法在此处列出。在故障情况下,此命令的输出显示哪个流丢弃了该流量。例如,可以在不允许该流量的集群中配置 egress 或 ingress 网络策略。
示例:使用 debug 输出来验证配置的默认拒绝
本例演示了如何使用入口默认拒绝策略阻断流量的 debug 输出来识别。
流程
创建以下 YAML,以定义
deny-by-default策略,以拒绝所有命名空间中的所有 pod 的入口流量。将 YAML 保存到deny-by-default.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令应用策略:
oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
networkpolicy.networking.k8s.io/deny-by-default created
networkpolicy.networking.k8s.io/deny-by-default createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令在
default命名空间中启动 web 服务:oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
prod命名空间:oc create namespace prod
$ oc create namespace prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来标记
prod命名空间:oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,在
prod命名空间中部署alpine镜像并启动 shell:oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 打开另一个终端会话。
在这个新终端会话中,运行
ovn-trace以验证在命名空间prod中运行的源 podtest-6459与在default命名空间中的目标 pod 之间的通信失败:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
ovn-trace source pod to destination pod indicates failure from test-6459 to web
ovn-trace source pod to destination pod indicates failure from test-6459 to webCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将日志级别增加到 2 以公开失败的原因:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 因为默认的 deny 策略被到位,所以入口流量会被阻止
创建一个策略,允许来自特定命名空间中所有 pod 的流量,其标签为
purpose=production。将 YAML 保存到web-allow-prod.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令应用策略:
oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令运行
ovnkube-trace来验证现在允许的流量:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在在第 6 步中打开的 shell 中运行以下命令,以将 nginx 连接到 web-server:
wget -qO- --timeout=2 http://web.default
wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5. 从 OpenShift SDN 网络插件迁移 复制链接链接已复制到粘贴板!
作为集群管理员,您可以从 OpenShift 软件定义型网络(SDN)插件迁移到 OVN-Kubernetes 网络插件。
如果您的集群使用 OpenShift SDN 网络插件,则无法将集群升级到 OpenShift Container Platform 4.17。您必须首先将集群迁移到 OVN-Kubernetes 插件,然后将集群升级到 OpenShift Container Platform 4.17。
另外,如果集群使用第三方容器网络接口(CNI)插件,则无法将集群迁移到 OVN-Kubernetes 网络插件。有关这些 CNI 插件的完整列表,请参阅 认证的 OpenShift CNI 插件 (红帽知识库)。
可以使用以下方法从 OpenShift SDN 网络插件迁移到 OVN-Kubernetes 插件:
- Ansible playbook
- Ansible playbook 方法自动化离线迁移方法步骤。此方法使用与手动离线迁移方法相同的使用场景。
- 离线迁移
- 这是一个手动过程,会包括一些停机时间。此方法主要用于自我管理的 OpenShift Container Platform 部署,当您无法执行有限实时迁移到 OVN-Kubernetes 网络插件时,请考虑使用此方法。
- 有限的实时迁移(首选方法)
- 这是一个自动过程,将集群从 OpenShift SDN 迁移到 OVN-Kubernetes。
对于有限的实时迁移方法,不要使用脚本或另一个工具(如 Red Hat Ansible Automation Platform)自动从 OpenShift SDN 迁移到 OVN-Kubernetes。这可能导致 OpenShift Container Platform 集群中断或崩溃。
19.5.1. 有限实时迁移到 OVN-Kubernetes 网络插件概述 复制链接链接已复制到粘贴板!
有限的实时迁移方法是在不中断服务的情况下将 OpenShift SDN 网络插件及其网络配置、连接和相关资源迁移到 OVN-Kubernetes 网络插件的过程。它可用于 OpenShift Container Platform,并且是从 OpenShift SDN 迁移到 OVN-Kubernetes 的首选方法。如果您无法执行有限的实时迁移,您可以使用离线迁移方法。
在将 OpenShift Container Platform 集群迁移到使用 OVN-Kubernetes 网络插件前,将集群更新至最新的 z-stream 版本,以便所有最新的程序错误修复都应用到集群。
它不适用于托管 control plane 部署类型。这个迁移方法对于需要持续服务可用性的部署类型非常重要,并具有以下优点:
- 持续服务可用性
- 最小化停机时间
- 自动节点重新引导
- 从 OpenShift SDN 网络插件无缝过渡到 OVN-Kubernetes 网络插件
虽然提供了一个回滚过程,但有限的实时迁移通常被认为是一个单向过程。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
以下小节提供了有关有限实时迁移方法的更多信息。
19.5.1.1. 使用有限实时迁移方法时支持的平台 复制链接链接已复制到粘贴板!
下表提供了有关有限实时迁移类型的支持的平台信息。
| 平台 | 有限实时迁移 |
|---|---|
| 裸机硬件 | ✓ |
| Amazon Web Services (AWS) | ✓ |
| Google Cloud | ✓ |
| IBM Cloud® | ✓ |
| Microsoft Azure | ✓ |
| Red Hat OpenStack Platform(RHOSP) | ✓ |
| VMware vSphere | ✓ |
| Nutanix | ✓ |
每个列出的平台都支持在安装程序置备的基础架构和用户置备的基础架构上安装 OpenShift Container Platform 集群。
19.5.1.2. 有限实时迁移到 OVN-Kubernetes 网络插件的最佳实践 复制链接链接已复制到粘贴板!
有关迁移到使用有限实时迁移方法的 OVN-Kubernetes 网络插件时的最佳实践列表,请参阅 Limited Live Migration from OpenShift SDN to OVN-Kubernetes。
19.5.1.3. 有限实时迁移到 OVN-Kubernetes 网络插件的注意事项 复制链接链接已复制到粘贴板!
在使用有限实时迁移方法到 OVN-Kubernetes 网络插件之前,集群管理员应考虑以下信息:
- 启用 OpenShift SDN 多租户模式的集群不支持有限的实时迁移步骤。
- 出口路由器 pod 会阻止有限的实时迁移过程。在开始有限的实时迁移过程前,必须删除它们。
- 在迁移过程中,当使用 OVN-Kubernetes 和 OpenShift SDN 运行集群时,两个 CNI 会临时禁用多播和出口 IP 地址。出口防火墙正常工作。
- 迁移旨在成为单向过程。但是,对于希望回滚到 OpenShift-SDN 的用户,从 OpenShift-SDN 迁移到 OVN-Kubernetes 必须已成功。用户可以按照以下步骤从 OVN-Kubernetes 网络插件迁移到 OpenShift SDN 网络插件。
- HyperShift 集群中不支持有限的实时迁移。
- OpenShift SDN 不支持 IPsec。迁移后,集群管理员可以启用 IPsec。
- OpenShift SDN 不支持 IPv6。迁移后,集群管理员可以启用双栈。
-
OpenShift SDN 插件允许
NodeNetworkConfigurationPolicy(NNCP)自定义资源(CR)的应用程序到节点上的主接口。OVN-Kubernetes 网络插件没有此功能。 集群 MTU 是 pod 接口的 MTU 值。它始终小于硬件 MTU,以考虑集群网络覆盖开销。OVN-Kubernetes 的开销为 100 字节,OpenShift SDN 是 50 字节。
在有限的实时迁移过程中,OVN-Kubernetes 和 OpenShift SDN 并行运行。OVN-Kubernetes 管理某些节点的集群网络,而 OpenShift SDN 管理其他用户的集群网络。为确保跨 CNI 流量保持正常工作,Cluster Network Operator 会更新可路由的 MTU,以确保两个 CNI 共享相同的覆盖 MTU。因此,在迁移完成后,集群 MTU 小于 50 字节。
-
OVN-Kubernetes 会保留
100.64.0.0/16和100.88.0.0/16IP 地址范围。这些子网不能与任何其他内部或外部网络重叠。如果 OpenShift SDN 使用这些 IP 地址,或者任何可能会与此集群通信的外部网络,则您必须在启动有限的实时迁移前使用不同的 IP 地址范围。如需更多信息,请参阅"选择 OVN-Kubernetes 地址范围"。 -
如果您的带有 Precision Time Protocol (PTP) 的
openshift-sdn集群使用 User Datagram Protocol (UDP) 进行硬件时间戳,且迁移到 OVN-Kubernetes 插件,则硬件时间戳无法应用到主接口设备,如 Open vSwitch (OVS) 网桥。因此,UDP 版本 4 配置无法使用br-ex接口。 - 在大多数情况下,有限的实时迁移独立于 Multus CNI 插件创建的 pod 的二级接口。但是,如果这些二级接口在主机的默认网络接口控制器 (NIC) 上设置,例如,使用 MACVLAN、IPVLAN、SR-IOV 或桥接接口作为控制节点,则 OVN-Kubernetes 可能会遇到故障。在继续有限的实时迁移前,用户应删除此配置。
- 当主机中存在多个 NIC 时,且默认路由不在具有 Kubernetes NodeIP 的接口上,则必须使用离线迁移。
-
在启动有限实时迁移前,必须删除
openshift-sdn命名空间中的所有DaemonSet对象(不受 Cluster Network Operator (CNO) 管理。这些非受管守护进程集可能会导致迁移状态在未正确处理时保持不完整。 -
如果您运行 Operator 或您已配置了 pod 中断预算,您可能会在升级过程中遇到中断。如果在
PodDisruptionBudget中将minAvailable设置为 1,则节点会排空以应用可能会阻止驱除过程的待处理机器配置。如果重启了几个节点,则所有 pod 只能有一个节点上运行,PodDisruptionBudget字段可能会阻止节点排空。 与 OpenShift SDN 一样,OVN-Kubernetes 资源(如
EgressFirewall资源)需要ClusterAdmin权限。从 OpenShift SDN 迁移到 OVN-Kubernetes 不会自动更新 role-base 访问控制(RBAC)资源。通过aggregate-to-adminClusterRole授予项目管理员的 OpenShift SDN 资源必须手动检查并调整,因为这些更改不会包含在迁移过程中。迁移后,需要手动验证 RBAC 资源。有关迁移后设置
aggregate-to-adminClusterRole 的详情,请参考 How to allow project admins to manage Egressfirewall resources in RHOCP4 中的示例。-
当集群依赖于主机网络中的静态路由或路由策略时,pod 可以到达某些目的地,在迁移前用户应将
gatewayConfig中的routingViaHostspec 设置为true,并将ipForwarding设置为Global。这将为主机内核卸载路由决策。如需更多信息,请参阅 Openshift SDN 网络插件迁移到 OVNKubernetes 插件前的建议实践 (Red Hat Knowledgebase),并在启动有限的实时迁移前"检查集群资源的第 5 步。 -
要防止流量流问题,请检查托管依赖系统组件的任何命名空间中的现有网络策略。如果存在策略,启用源自
openshift-ingress或openshift-kube-apiserver系统服务的流量,以防止默认设置阻止此流量。
19.5.1.4. 有限的实时迁移过程是如何工作的 复制链接链接已复制到粘贴板!
下表总结了有限实时迁移过程,具体是流程中用户发起的步骤与迁移脚本在响应中执行的操作之间的部分。
| 用户发起的步骤 | 迁移操作 |
|---|---|
|
通过将 |
|
19.5.1.5. 使用有限的实时迁移方法迁移到 OVN-Kubernetes 网络插件 复制链接链接已复制到粘贴板!
使用有限的实时迁移方法迁移到 OVN-Kubernetes 网络插件是一个步骤,要求用户检查出口 IP 资源、出口防火墙资源和多播启用的命名空间的行为。管理员还必须查看其部署中的任何网络策略,并删除出口路由器资源,然后才能启动有限的实时迁移过程。以下流程应该连续使用。
19.5.1.5.1. 在启动有限实时迁移前检查集群资源 复制链接链接已复制到粘贴板!
在使用有限的实时迁移功能迁移到 OVN-Kubernetes 之前,您应该在 OpenShift SDN 部署中检查出口 IP 资源、出口防火墙资源和多播启用的命名空间。您还应检查部署中的任何网络策略。如果您在迁移前发现集群有这些资源,您应该在迁移后检查其行为,以确保它们按预期工作。
以下流程演示了如何检查出口 IP 资源、出口防火墙资源、多播支持的命名空间、网络策略和 NNCP。检查这些资源后不需要任何操作。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。
流程
作为 OpenShift Container Platform 集群管理员,检查出口防火墙资源。您可以使用
ocCLI 或 OpenShift Container Platform Web 控制台进行此操作。使用
ocCLI 工具检查出口防火墙资源:要检查出口防火墙资源,请输入以下命令:
oc get egressnetworkpolicies.network.openshift.io -A
$ oc get egressnetworkpolicies.network.openshift.io -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5d
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以使用
-o yaml标志检查出口防火墙资源的预期行为。例如:oc get egressnetworkpolicy <example_egressfirewall> -n <namespace> -o yaml
$ oc get egressnetworkpolicy <example_egressfirewall> -n <namespace> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
使用 OpenShift Container Platform Web 控制台检查出口防火墙资源:
- 在 OpenShift Container Platform web 控制台中点 Observe → Metrics。
-
在 Expression 框中,键入
sdn_controller_num_egress_firewalls,然后点 Run queries。如果您有出口防火墙资源,则会在 Expression 框中返回。
检查集群是否有出口 IP 资源。您可以使用
ocCLI 或 OpenShift Container Platform Web 控制台进行此操作。使用
ocCLI 工具检查出口 IP:要列出带有出口 IP 资源的命名空间,请输入以下命令
oc get netnamespace -A | awk '$3 != ""'
$ oc get netnamespace -A | awk '$3 != ""'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME NETID EGRESS IPS namespace1 14173093 ["10.0.158.173"] namespace2 14173020 ["10.0.158.173"]
NAME NETID EGRESS IPS namespace1 14173093 ["10.0.158.173"] namespace2 14173020 ["10.0.158.173"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
使用 OpenShift Container Platform Web 控制台检查出口 IP:
- 在 OpenShift Container Platform web 控制台中点 Observe → Metrics。
-
在 Expression 框中,键入
sdn_controller_num_egress_ips,然后点 Run queries。如果您有出口防火墙资源,则会在 Expression 框中返回。
检查集群是否有启用多播的命名空间。您可以使用
ocCLI 或 OpenShift Container Platform Web 控制台进行此操作。使用
ocCLI 工具检查启用多播的命名空间:要找到启用多播的命名空间,请输入以下命令:
oc get netnamespace -o json | jq -r '.items[] | select(.metadata.annotations."netnamespace.network.openshift.io/multicast-enabled" == "true") | .metadata.name'
$ oc get netnamespace -o json | jq -r '.items[] | select(.metadata.annotations."netnamespace.network.openshift.io/multicast-enabled" == "true") | .metadata.name'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
namespace1 namespace3
namespace1 namespace3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
使用 OpenShift Container Platform Web 控制台检查多播启用的命名空间:
- 在 OpenShift Container Platform web 控制台中点 Observe → Metrics。
-
在 Expression 框中,键入
sdn_controller_num_multicast_enabled_namespaces,然后点 Run queries。如果您启用了多播的命名空间,则会在 Expression 框中返回它们。
检查集群是否有网络策略。您可以使用
ocCLI 完成此操作。要使用
ocCLI 工具检查网络策略,请输入以下命令:oc get networkpolicy -n <namespace>
$ oc get networkpolicy -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME POD-SELECTOR AGE allow-multicast app=my-app 11m
NAME POD-SELECTOR AGE allow-multicast app=my-app 11mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
可选:如果您的集群在主机网络中使用静态路由或路由策略,请在迁移过程中将
gatewayConfig对象中的routingViaHostspec 设置为true,将ipForwardingspec 设置为Global。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证
ipForwardingspec 是否已设置为Global,routingViaHostspec 被设置为true:oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
$ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.1.5.2. 在启动有限实时迁移前删除出口路由器 pod 复制链接链接已复制到粘贴板!
在启动有限的实时迁移前,您必须检查并移除任何出口路由器 pod。如果在执行有限的实时迁移时集群中有一个出口路由器 pod,Network Operator 会阻断迁移并返回以下错误:
The cluster configuration is invalid (network type limited live migration is not supported for pods with `pod.network.openshift.io/assign-macvlan` annotation. Please remove all egress router pods). Use `oc edit network.config.openshift.io cluster` to fix.
The cluster configuration is invalid (network type limited live migration is not supported for pods with `pod.network.openshift.io/assign-macvlan` annotation.
Please remove all egress router pods). Use `oc edit network.config.openshift.io cluster` to fix.
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。
流程
要找到集群中的出口路由 pod,请输入以下命令:
oc get pods --all-namespaces -o json | jq '.items[] | select(.metadata.annotations."pod.network.openshift.io/assign-macvlan" == "true") | {name: .metadata.name, namespace: .metadata.namespace}'$ oc get pods --all-namespaces -o json | jq '.items[] | select(.metadata.annotations."pod.network.openshift.io/assign-macvlan" == "true") | {name: .metadata.name, namespace: .metadata.namespace}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
{ "name": "egress-multi", "namespace": "egress-router-project" }{ "name": "egress-multi", "namespace": "egress-router-project" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 另外,您还可以查询 OpenShift Container Platform Web 控制台上的指标。
- 在 OpenShift Container Platform web 控制台中点 Observe → Metrics。
-
在 Expression 框中,输入
network_attachment_definition_instances{networks="egress-router"}。然后,点 Add。
要删除出口路由器 pod,请输入以下命令:
oc delete pod <egress_pod_name> -n <egress_router_project>
$ oc delete pod <egress_pod_name> -n <egress_router_project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OpenShift SDN 插件允许 NodeNetworkConfigurationPolicy (NNCP) 自定义资源 (CR) 的应用程序到节点上的主接口。OVN-Kubernetes 网络插件没有此功能。
如果您的 NNCP 应用到主接口,则必须在迁移到 OVN-Kubernetes 网络插件前删除 NNCP。删除 NNCP 不会从主接口中删除配置,但 Kubernetes-NMState 无法管理此配置。相反,configure-ovs.sh shell 脚本管理主接口及其附加的配置。
先决条件
- 您创建了 NNCP CR,并将其应用到网络的主接口。
流程
运行以下命令,从 Cluster Network Operator (CNO) 配置对象中删除配置:
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过完成以下步骤,删除
NodeNetworkConfigurationPolicy(NNCP)自定义资源(CR)定义 OpenShift SDN 网络插件的主网络接口:输入以下命令检查现有 NNCP CR 是否将主接口绑定到集群:
oc get nncp
$ oc get nncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS REASON bondmaster0 Available SuccessfullyConfigured
NAME STATUS REASON bondmaster0 Available SuccessfullyConfiguredCopy to Clipboard Copied! Toggle word wrap Toggle overflow Network Manager 将绑定的主接口的连接配置文件存储在
/etc/NetworkManager/system-connections系统路径中。从集群中删除 NNCP:
oc delete nncp <nncp_manifest_filename>
$ oc delete nncp <nncp_manifest_filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.1.5.4. 启动有限的实时迁移过程 复制链接链接已复制到粘贴板!
在检查了出口 IP 资源、出口防火墙资源和多播启用命名空间的行为后,并删除了任何出口路由器资源,您可以启动有限的实时迁移过程。
先决条件
- 在网络策略隔离模式下,使用 OpenShift SDN CNI 网络插件配置集群。
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。 - 您已创建了 etcd 数据库的最新备份。
- 集群处于已知良好状态,且没有任何错误。
-
在迁移到 OVN-Kubernetes 之前,必须有一条安全组规则,以允许所有云平台上所有节点的 UDP 数据包在端口
6081上。 -
如果 OpenShift-SDN 之前使用
100.64.0.0/16和100.88.0.0/16地址范围,则代表已修补它们。流程中的步骤检查这些地址范围是否在使用。如果在使用它们,请参阅"使用 OVN-Kubernetes 地址范围"。 - 您已检查出口 IP 资源、出口防火墙资源和多播启用的命名空间。
- 在开始有限的实时迁移前,您已删除了任何出口路由器 pod。如需有关出口路由器 pod 的更多信息,请参阅"以重定向模式部署出口路由器 pod"。
- 您已参阅本文档的"正在考虑的有限实时迁移"部分。
流程
要修补集群级别的网络配置,并启动从 OpenShift SDN 到 OVN-Kubernetes 的迁移:
oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}'$ oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行此命令后,迁移过程将开始。在此过程中,Machine Config Operator 会重启集群中的节点两次。在集群升级过程中,迁移大约需要进行两次。
重要此
oc patch命令检查 OpenShift SDN 使用的重叠 CIDR。如果检测到重叠的 CIDR,您必须在有限的实时迁移进程启动前对它们进行补丁。如需更多信息,请参阅"使用 OVN-Kubernetes 地址范围"。可选: 要确保迁移过程已完成,并检查
network.config的状态,您可以输入以下命令:oc get network.config.openshift.io cluster -o jsonpath='{.status.networkType}'$ oc get network.config.openshift.io cluster -o jsonpath='{.status.networkType}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get network.config cluster -o=jsonpath='{.status.conditions}' | jq .$ oc get network.config cluster -o=jsonpath='{.status.conditions}' | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以检查有限的实时迁移指标,以进行故障排除。如需更多信息,请参阅"检查有限的实时迁移指标"。
成功迁移操作后,输入以下命令从
network.config自定义资源中删除network.openshift.io/network-type-migration-注解:oc annotate network.config cluster network.openshift.io/network-type-migration-
$ oc annotate network.config cluster network.openshift.io/network-type-migration-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.1.5.5. 修补 OVN-Kubernetes 地址范围 复制链接链接已复制到粘贴板!
OVN-Kubernetes 保留以下 IP 地址范围:
-
100.64.0.0/16。默认情况下,此 IP 地址范围用于 OVN-Kubernetes 的internalJoinSubnet参数。 -
100.88.0.0/16。默认情况下,此 IP 地址范围用于 OVN-Kubernetes 的internalTransSwitchSubnet参数。
如果 OpenShift SDN 使用这些 IP 地址,或者任何可能会与此集群通信的外部网络,则您必须在启动有限的实时迁移前使用不同的 IP 地址范围。
如果迁移最初被阻止,则可以使用以下步骤来修补 OpenShift SDN 使用的 CIDR 范围。
只有集群或网络环境与 100.64.0.0/16 子网或 100.88.0.0/16 子网重叠时才使用此可选流程。在开始有限的实时迁移操作前,请确保运行该流程中的步骤。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。
流程
如果已使用
100.64.0.0/16IP 地址范围,请输入以下命令将其修补为不同的范围。以下示例使用100.70.0.0/16。oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalJoinSubnet": "100.70.0.0/16"}}}}}'$ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalJoinSubnet": "100.70.0.0/16"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果已使用
100.88.0.0/16IP 地址范围,请输入以下命令将其修补为不同的范围。以下示例使用100.99.0.0/16。oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalTransitSwitchSubnet": "100.99.0.0/16"}}}}}'$ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalTransitSwitchSubnet": "100.99.0.0/16"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在修补 100.64.0.0/16 和 100.88.0.0/16 IP 地址范围后,您可以启动有限的实时迁移。
19.5.1.5.6. 启动有限实时迁移后检查集群资源 复制链接链接已复制到粘贴板!
以下流程演示了如何在使用 OVN-Kubernetes 时检查出口 IP 资源、出口防火墙资源、多播启用的命名空间和网络策略。如果您在 OpenShift SDN 上有这些资源,您应该在迁移后检查它们,以确保它们正常工作。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 - 您已使用有限的实时迁移成功从 OpenShift SDN 迁移到 OVN-Kubernetes。
流程
作为 OpenShift Container Platform 集群管理员,检查出口防火墙资源。您可以使用
ocCLI 或 OpenShift Container Platform Web 控制台进行此操作。使用
ocCLI 工具检查出口防火墙资源:要检查出口防火墙资源,请输入以下命令:
oc get egressfirewalls.k8s.ovn.org -A
$ oc get egressfirewalls.k8s.ovn.org -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5d
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以使用
-o yaml标志检查出口防火墙资源的预期行为。例如:oc get egressfirewall <example_egressfirewall> -n <namespace> -o yaml
$ oc get egressfirewall <example_egressfirewall> -n <namespace> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确保此资源的行为是预期的,因为它可能会在迁移后有所变化。有关出口防火墙的更多信息,请参阅"配置项目的出口防火墙"。
使用 OpenShift Container Platform Web 控制台检查出口防火墙资源:
- 在 OpenShift Container Platform web 控制台中点 Observe → Metrics。
-
在 Expression 框中,键入
ovnkube_controller_num_egress_firewall_rules,然后点 Run queries。如果您有出口防火墙资源,则会在 Expression 框中返回。
检查集群是否有出口 IP 资源。您可以使用
ocCLI 或 OpenShift Container Platform Web 控制台进行此操作。使用
ocCLI 工具检查出口 IP:要列出带有出口 IP 资源的命名空间,请输入以下命令:
oc get egressip
$ oc get egressipCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME EGRESSIPS ASSIGNED NODE ASSIGNED EGRESSIPS egress-sample 192.0.2.10 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.10 egressip-sample-2 192.0.2.14 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.14
NAME EGRESSIPS ASSIGNED NODE ASSIGNED EGRESSIPS egress-sample 192.0.2.10 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.10 egressip-sample-2 192.0.2.14 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.14Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要提供有关出口 IP 的详细信息,请输入以下命令:
oc get egressip <egressip_name> -o yaml
$ oc get egressip <egressip_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 对所有出口 IP 重复此操作。确保每个资源的行为都是预期的,因为它可能会在迁移后有所变化。有关 EgressIPs 的更多信息,请参阅"配置 EgressIP 地址"。
使用 OpenShift Container Platform Web 控制台检查出口 IP:
- 在 OpenShift Container Platform web 控制台中点 Observe → Metrics。
-
在 Expression 框中,键入
ovnkube_clustermanager_num_egress_ips,然后点 Run queries。如果您有出口防火墙资源,则会在 Expression 框中返回。
检查集群是否有启用多播的命名空间。您只能使用
ocCLI 完成此操作。要找到启用多播的命名空间,请输入以下命令:
oc get namespace -o json | jq -r '.items[] | select(.metadata.annotations."k8s.ovn.org/multicast-enabled" == "true") | .metadata.name'
$ oc get namespace -o json | jq -r '.items[] | select(.metadata.annotations."k8s.ovn.org/multicast-enabled" == "true") | .metadata.name'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
namespace1 namespace3
namespace1 namespace3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要描述每个启用多播的命名空间,请输入以下命令:
oc describe namespace <namespace>
$ oc describe namespace <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确保正确配置多播功能,并在每个命名空间中按预期工作。如需更多信息,请参阅"为项目启用多播"。
检查集群的网络策略。您只能使用
ocCLI 完成此操作。要获取命名空间中网络策略的信息,请输入以下命令:
oc get networkpolicy -n <namespace>
$ oc get networkpolicy -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME POD-SELECTOR AGE allow-multicast app=my-app 11m
NAME POD-SELECTOR AGE allow-multicast app=my-app 11mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要提供有关网络策略的详细信息,请输入以下命令:
oc describe networkpolicy allow-multicast -n <namespace>
$ oc describe networkpolicy allow-multicast -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确保网络策略的行为如预期。对网络策略的优化因 SDN 和 OVN-K 而异,因此用户可能需要调整其策略以便为不同的 CNI 实现最佳性能。如需更多信息,请参阅"关于网络策略"。
19.5.1.6. 检查有限的实时迁移指标 复制链接链接已复制到粘贴板!
可用于监控有限实时迁移的进度。可以在 OpenShift Container Platform Web 控制台中或使用 oc CLI 查看指标。
先决条件
- 您已启动了一个有限实时迁移到 OVN-Kubernetes。
流程
在 OpenShift Container Platform Web 控制台中查看有限的实时迁移指标:
- 点 Observe → Metrics。
- 在 Expression 框中,键入 openshift_network 并点 openshift_network_operator_live_migration_condition 选项。
使用
ocCLI 查看指标:输入以下命令为
openshift-monitoring命名空间中的prometheus-k8s服务帐户生成令牌:token=`oc create token prometheus-k8s -n openshift-monitoring`
$ token=`oc create token prometheus-k8s -n openshift-monitoring`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令请求有关
openshift_network_operator_live_migration_condition指标的信息:oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: Bearer $token" 'https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query?' --data-urlencode 'query=openshift_network_operator_live_migration_condition' | jq
$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: Bearer $token" 'https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query?' --data-urlencode 'query=openshift_network_operator_live_migration_condition' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
"Information about limited live migration metrics" 中的表显示可用的指标,以及 openshift_network_operator_live_migration_condition 表达式填充的标签值。使用这些信息来监控进度或对迁移进行故障排除。
19.5.1.6.1. 关于有限实时迁移指标的信息 复制链接链接已复制到粘贴板!
下表显示了可用的指标以及从 openshift_network_operator_live_migration_condition 表达式填充的标签值。使用这些信息来监控进度或对迁移进行故障排除。
| 指标 | 标签值 |
|---|---|
|
|
|
|
19.5.3. 离线迁移到 OVN-Kubernetes 网络插件概述 复制链接链接已复制到粘贴板!
离线迁移方法是一个手动过程,其中包括一些停机时间,在此期间集群无法访问。您可以使用 Ansible playbook 自动离线迁移步骤,以便您可以节省时间。此方法主要用于自我管理的 OpenShift Container Platform 部署,它是有限的实时迁移步骤的替代选择。只有在无法执行有限实时迁移到 OVN-Kubernetes 网络插件时,才使用这些方法。
在将 OpenShift Container Platform 集群迁移到使用 OVN-Kubernetes 网络插件前,将集群更新至最新的 z-stream 版本,以便所有最新的程序错误修复都应用到集群。
虽然提供了回滚过程,但离线迁移方法旨在作为单向过程。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
以下小节提供了有关离线迁移方法的更多信息。
19.5.3.1. 使用离线迁移方法时支持的平台 复制链接链接已复制到粘贴板!
下表提供了有关手动离线迁移类型的支持的平台信息。
| 平台 | 离线迁移 |
|---|---|
| 裸机硬件 | ✓ |
| Amazon Web Services (AWS) | ✓ |
| Google Cloud | ✓ |
| IBM Cloud® | ✓ |
| Microsoft Azure | ✓ |
| Red Hat OpenStack Platform(RHOSP) | ✓ |
| VMware vSphere | ✓ |
| Nutanix | ✓ |
下表提供了有关手动离线迁移类型的支持的平台信息。
| 平台 | Ansible playbook 离线迁移 |
|---|---|
| 裸机硬件 | ✓ |
| Amazon Web Services (AWS) | ✓ |
| Google Cloud | ✓ |
| IBM Cloud® | ✓ |
| Microsoft Azure | ✓ |
| VMware vSphere | ✓ |
对于这些表中列出的每个平台,平台支持在安装程序置备的基础架构和用户置备的基础架构上安装 OpenShift Container Platform 集群。
19.5.3.2. 手动离线迁移和 Ansible playbook 离线迁移方法的最佳实践 复制链接链接已复制到粘贴板!
有关使用离线迁移方法迁移到 OVN-Kubernetes 网络插件时的最佳实践列表,请参阅 OpenShift SDN 到 OVN Kubernetes CNI 离线迁移的最佳实践。
19.5.3.3. 离线迁移方法到 OVN-Kubernetes 网络插件的注意事项 复制链接链接已复制到粘贴板!
如果您在 OpenShift Container Platform 集群中有超过 150 个节点,请创建一个支持问题单,供您迁移到 OVN-Kubernetes 网络插件。
迁移过程中不会保留分配给节点的子网以及分配给各个 pod 的 IP 地址。
虽然 OVN-Kubernetes 网络插件实现 OpenShift SDN 网络插件中存在的许多功能,但配置并不相同。
如果您的集群使用以下 OpenShift SDN 网络插件功能,您必须在 OVN-Kubernetes 网络插件中手动配置相同的功能:
- 命名空间隔离
- 出口路由器 pod
-
在迁移到 OVN-Kubernetes 之前,请确保不使用以下 IP 地址范围:
100.64.0.0/16,169.254.169.0/29,100.88.0.0/16,fd98::/64,fd69::/125, 和fd97::/64。OVN-Kubernetes 在内部使用这些范围。不要在集群或基础架构的任何其他 CIDR 定义中包含这些范围。 -
如果您的带有 Precision Time Protocol (PTP) 的
openshift-sdn集群使用 User Datagram Protocol (UDP) 进行硬件时间戳,且迁移到 OVN-Kubernetes 插件,则硬件时间戳无法应用到主接口设备,如 Open vSwitch (OVS) 网桥。因此,UDP 版本 4 配置无法使用br-ex接口。 -
与 OpenShift SDN 类似,OVN-Kubernetes 资源需要
ClusterAdmin权限。从 OpenShift SDN 迁移到 OVN-Kubernetes 不会自动更新 role-base 访问控制(RBAC)资源。通过aggregate-to-adminClusterRole授予项目管理员的 OpenShift SDN 资源必须手动检查并调整,因为这些更改不会包含在迁移过程中。迁移后,需要手动验证 RBAC 资源。 -
要防止流量流问题,请检查托管依赖系统组件的任何命名空间中的现有网络策略。如果存在策略,启用源自
openshift-ingress或openshift-kube-apiserver系统服务的流量,以防止默认设置阻止此流量。
以下小节重点介绍了上述功能在 OVN-Kubernetes 和 OpenShift SDN 网络插件中的配置差异。
19.5.3.3.1. 主网络接口 复制链接链接已复制到粘贴板!
OpenShift SDN 插件允许 NodeNetworkConfigurationPolicy (NNCP)自定义资源(CR)的应用程序到节点上的主接口。OVN-Kubernetes 网络插件没有此功能。
如果您的 NNCP 应用到主接口,则必须在迁移到 OVN-Kubernetes 网络插件前删除 NNCP。删除 NNCP 不会从主接口中删除配置,但使用 OVN-Kubernetes,Kubernetes NMState 无法管理此配置。相反,configure-ovs.sh shell 脚本管理附加到这个接口的主接口和配置。
19.5.3.3.2. 命名空间隔离 复制链接链接已复制到粘贴板!
OVN-Kubernetes 仅支持网络策略隔离模式。
对于使用在多租户或子网隔离模式下配置的 OpenShift SDN 的集群,您仍然可以迁移到 OVN-Kubernetes 网络插件。请注意,在迁移操作后,多租户隔离模式会被丢弃,因此您必须手动配置网络策略,以便为 Pod 和服务达到相同的项目级别的隔离。
19.5.3.3.3. 出口 IP 地址 复制链接链接已复制到粘贴板!
OpenShift SDN 支持两种不同的 Egress IP 模式:
- 在自动分配方法中,给节点分配一个出口 IP 地址范围。
- 在手动分配方法中,给节点分配包含一个或多个出口 IP 地址的列表。
迁移过程支持迁移使用自动分配模式的 Egress IP 配置。
下表中描述了在 OVN-Kubernetes 和 OpenShift SDN 配置出口 IP 地址的不同:
| OVN-Kubernetes | OpenShift SDN |
|---|---|
|
|
有关在 OVN-Kubernetes 中使用出口 IP 地址的更多信息,请参阅"配置出口 IP 地址"。
19.5.3.3.4. 出口网络策略 复制链接链接已复制到粘贴板!
下表中描述在 OVN-Kubernetes 和 OpenShift SDN 间配置出口网络策略(也称为出口防火墙)的不同之处:
| OVN-Kubernetes | OpenShift SDN |
|---|---|
|
|
由于 EgressFirewall 对象的名称只能设置为 default,在迁移后,所有迁移的 EgressNetworkPolicy 对象都会命名为 default,而无论在 OpenShift SDN 下的名称是什么。
如果您随后回滚到 OpenShift SDN,则所有 EgressNetworkPolicy 对象都会命名为 default,因为之前的名称已丢失。
有关在 OVN-Kubernetes 中使用出口防火墙的更多信息,请参阅"配置项目出口防火墙"。
19.5.3.3.5. 出口路由器 pod 复制链接链接已复制到粘贴板!
OVN-Kubernetes 支持重定向模式的出口路由器 pod。OVN-Kubernetes 不支持 HTTP 代理模式或 DNS 代理模式的出口路由器 pod。
使用 Cluster Network Operator 部署出口路由器时,您无法指定节点选择器来控制用于托管出口路由器 pod 的节点。
19.5.3.3.6. 多播 复制链接链接已复制到粘贴板!
下表中描述了在 OVN-Kubernetes 和 OpenShift SDN 上启用多播流量的区别:
| OVN-Kubernetes | OpenShift SDN |
|---|---|
|
|
有关在 OVN-Kubernetes 中使用多播的更多信息,请参阅"启用项目多播"。
19.5.3.3.7. 网络策略 复制链接链接已复制到粘贴板!
OVN-Kubernetes 在 networking.k8s.io/v1 API 组中完全支持 Kubernetes NetworkPolicy API。从 OpenShift SDN 进行迁移时,网络策略不需要更改。
19.5.3.4. 离线迁移过程如何工作 复制链接链接已复制到粘贴板!
下表对迁移过程进行了概述,它分为操作中的用户发起的步骤,以及在响应过程中迁移过程要执行的操作。
| 用户发起的步骤 | 迁移操作 |
|---|---|
|
将名为 |
|
|
更新 |
|
| 重新引导集群中的每个节点。 |
|
19.5.3.5. 使用 Ansible playbook 迁移到 OVN-Kubernetes 网络插件 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 Ansible 集合 network.offline_migration_sdn_to_ovnk 从 OpenShift SDN Container Network Interface (CNI)网络插件迁移到集群的 OVN-Kubernetes 插件。Ansible 集合包括以下 playbook:
-
playbooks/playbook-migration.yml:包含按顺序执行的 playbook,每个 playbook 代表迁移过程中的一个步骤。 -
playbooks/playbook-rollback.yml:包含按顺序执行的 playbook,其中每个 playbook 代表回滚过程中的一个步骤。
先决条件
-
已安装
python3软件包,最小版本 3.10。 -
已安装
jmespath和jq软件包。 - 已登陆到 Red Hat Hybrid Cloud Console 并打开 Ansible Automation Platform web 控制台。
-
您创建了一条安全组规则,允许所有云平台上所有节点的端口
6081上用户数据报协议(UDP)数据包。如果没有此任务,您的集群可能无法调度 pod。 检查集群是否在主机网络中使用静态路由或路由策略。
-
如果为 true,则后续步骤需要将
routingViaHost参数设置为true,在playbooks/playbook-migration.yml文件的gatewayConfig部分中将ipForwarding参数设置为Global。
-
如果为 true,则后续步骤需要将
-
如果 OpenShift-SDN 插件使用
100.64.0.0/16和100.88.0.0/16地址范围,则您修补了地址范围。如需更多信息,请参阅附加资源部分中的 "Patching OVN-Kubernetes address ranges"。
流程
安装
ansible-core软件包,最低为 2.15 版本。以下示例命令演示了如何在 Red Hat Enterprise Linux (RHEL)上安装ansible-core软件包:sudo dnf install -y ansible-core
$ sudo dnf install -y ansible-coreCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
ansible.cfg文件,并将类似以下示例的信息添加到该文件中。确保该文件存在于与ansible-galaxy命令和 playbook 运行相同的目录中。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 Ansible Automation Platform web 控制台中进入 Connect to Hub 页并完成以下步骤:
- 在页的离线令牌部分中,点 Load token 按钮。
- 在令牌加载后,点 Copy to clipboard 图标。
-
打开
ansible.cfg文件,并将 API 令牌粘贴到token=参数中。对ansible.cfg文件中指定的服务器 URL 进行身份验证需要 API 令牌。
输入以下
ansible-galaxy命令,安装network.offline_migration_sdn_to_ovnkAnsible 集合:ansible-galaxy collection install network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection install network.offline_migration_sdn_to_ovnkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证您系统上是否安装了
network.offline_migration_sdn_to_ovnkAnsible 集合:ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
network.offline_migration_sdn_to_ovnk 1.0.2
network.offline_migration_sdn_to_ovnk 1.0.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow network.offline_migration_sdn_to_ovnkAnsible 集合保存在~/.ansible/collections/ansible_collections/network/offline_migration_sdn_to_ovnk/的默认路径中。在
playbook/playbook-migration.yml文件中配置迁移功能:Copy to Clipboard Copied! Toggle word wrap Toggle overflow migration_interface_name-
如果您在主接口上使用
NodeNetworkConfigurationPolicy(NNCP)资源,请在migration-playbook.yml文件中指定接口名称,以便在迁移过程中在主接口上删除 NNCP 资源。 migration_disable_auto_migration-
禁用 OpenShift SDN CNI 插件的自动迁移功能到 OVN-Kubernetes 插件。如果禁用功能的自动迁移,还必须将
migration_egress_ip、migration_egress_firewall和migration_multicast参数设置为false。如果您需要启用功能的自动迁移,请将 参数设置为false。 migration_routing_via_host-
设置为
true,以配置本地网关模式或false,来为集群中的节点配置共享网关模式。默认值为false。在本地网关模式中,流量通过主机网络堆栈路由。在共享网关模式中,流量不会通过主机网络堆栈路由。 migration_ip_forwarding-
如果您配置了本地网关模式,如果您需要节点的主机网络充当与 OVN-Kubernetes 相关的流量的路由器,请将 IP 转发设置为
Global。 migration_cidr-
为集群指定无类别域间路由(CIDR) IP 地址块。您不能使用任何与
10064.0.0/16CIDR 块重叠的 CIDR 块,因为 OVN-Kubernetes 网络供应商在内部使用此块。 migration_prefix- 确保指定了一个前缀值,这是集群中每个节点的 CIDR 块的片段。
migration_mtu- 可选参数,在迁移过程后将特定的最大传输单元(MTU)设置为集群网络。
migration_geneve_port-
为 OVN-Kubernetes 设置 Geneve 端口的可选参数。默认端口为
6081。 migration_ipv4_subnet-
可选参数,用于为 OVN-Kubernetes 内部设置 IPv4 地址范围。参数的默认值为
100.64.0.0/16。
要运行
playbooks/playbook-migration.yml文件,请输入以下命令:ansible-playbook -v playbooks/playbook-migration.yml
$ ansible-playbook -v playbooks/playbook-migration.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.3.6. 使用离线迁移方法迁移到 OVN-Kubernetes 网络插件 复制链接链接已复制到粘贴板!
作为集群管理员,您可以将集群的网络插件更改为 OVN-Kubernetes。在迁移过程中,您必须重新引导集群中的每个节点。
在进行迁移时,集群不可用,工作负载可能会中断。仅在服务中断可以接受时才执行迁移。
先决条件
您已在网络策略隔离模式下使用 OpenShift SDN CNI 网络插件配置集群。
重要对于使用在多租户或子网隔离模式下配置的 OpenShift SDN 的集群,您仍然可以使用离线迁移方法迁移到 OVN-Kubernetes 网络插件。请注意,在迁移操作后,多租户隔离模式会被丢弃,因此您必须手动配置网络策略,以便为 Pod 和服务达到相同的项目级别的隔离。
-
已安装 OpenShift CLI(
oc)。 -
您可以使用具有
cluster-admin角色的用户访问集群。 - 您有最新的 etcd 数据库备份。
- 您可以手动重新引导每个节点。
- 您检查集群是否处于已知良好状态,且没有任何错误。
-
您创建了一条安全组规则,允许所有云平台上所有节点的端口
6081上用户数据报协议(UDP)数据包。 - 已删除 Webhook。或者,您可以为每个 webhook 设置超时值,这在流程中详细介绍。如果您没有完成这些任务之一,您的集群可能无法调度 pod。
流程
如果您没有删除 Webhook,请通过创建
ValidatingWebhookConfiguration自定义资源,然后指定timeoutSeconds参数的超时值,将每个 webhook 的超时值设置为3秒:oc patch ValidatingWebhookConfiguration <webhook_name> --type='json' \ -p '[{"op": "replace", "path": "/webhooks/0/timeoutSeconds", "value": 3}]'oc patch ValidatingWebhookConfiguration <webhook_name> --type='json' \1 -p '[{"op": "replace", "path": "/webhooks/0/timeoutSeconds", "value": 3}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 其中
<webhook_name>是 webhook 的名称。
要备份集群网络的配置,请输入以下命令:
oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
$ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证
OVN_SDN_MIGRATION_TIMEOUT环境变量是否已设置,并等于0s:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,从 Cluster Network Operator (CNO) 配置对象中删除配置:
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过完成以下步骤,删除
NodeNetworkConfigurationPolicy(NNCP)自定义资源(CR)定义 OpenShift SDN 网络插件的主网络接口:输入以下命令检查现有 NNCP CR 是否将主接口绑定到集群:
oc get nncp
$ oc get nncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS REASON bondmaster0 Available SuccessfullyConfigured
NAME STATUS REASON bondmaster0 Available SuccessfullyConfiguredCopy to Clipboard Copied! Toggle word wrap Toggle overflow Network Manager 将绑定的主接口的连接配置文件存储在
/etc/NetworkManager/system-connections系统路径中。从集群中删除 NNCP:
oc delete nncp <nncp_manifest_filename>
$ oc delete nncp <nncp_manifest_filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
要为迁移准备所有节点,请运行以下命令在 CNO 配置对象上设置
migration字段:oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意此步骤不会立即部署 OVN-Kubernetes。相反,指定
migration字段会触发 Machine Config Operator(MCO)将新机器配置应用到集群中的所有节点,以准备 OVN-Kubernetes 部署。运行以下命令检查重启是否已完成:
oc get mcp
$ oc get mcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检查所有集群 Operator 是否可用:
oc get co
$ oc get coCopy to Clipboard Copied! Toggle word wrap Toggle overflow 另外:您可以禁用将几个 OpenShift SDN 功能自动迁移到 OVN-Kubernetes 等效功能:
- 出口 IP
- 出口防火墙
- 多播
要为之前记录的 OpenShift SDN 功能禁用配置自动迁移,请指定以下键:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
bool:指定是否启用功能的迁移。默认值是true。
可选: 您可以自定义 OVN-Kubernetes 的以下设置,以满足您的网络基础架构要求:
最大传输单元 (MTU)。在为这个可选步骤自定义 MTU 前请考虑以下几点:
- 如果您使用默认 MTU,并且要在迁移期间保留默认 MTU,则可以忽略这一步。
- 如果您使用自定义 MTU,并且要在迁移过程中保留自定义 MTU,则必须在此步骤中声明自定义 MTU 值。
如果要在迁移过程中更改 MTU 值,此步骤将无法正常工作。相反,您必须首先按照"选择集群 MTU"的说明进行操作。然后,您可以通过执行此步骤并声明自定义 MTU 值来保留自定义 MTU 值。
注意OpenShift-SDN 和 OVN-Kubernetes 具有不同的覆盖(overlay)开销。MTU 值应遵循在 "MTU 值选择" 页面中找到的准则来选择。
- Geneve(Generic Network Virtualization Encapsulation)覆盖网络端口
- OVN-Kubernetes IPv4 内部子网
网关模式和 IP 转发
-
如果您的集群在主机网络中使用静态路由或路由策略,请在迁移过程中将
gatewayConfig对象中的routingViaHostspec 设置为true,将ipForwardingspec 设置为Global。
-
如果您的集群在主机网络中使用静态路由或路由策略,请在迁移过程中将
要自定义之前记录的设置之一,请输入以下命令。如果您不需要更改默认值,请从补丁中省略该键。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
mtu-
Geneve 覆盖网络的 MTU。这个值通常是自动配置的;但是,如果集群中的节点没有都使用相同的 MTU,那么您必须将此值明确设置为比最小节点 MTU 的值小
100。 port-
Geneve 覆盖网络的 UDP 端口。如果没有指定值,则默认为
6081。端口不能与 OpenShift SDN 使用的 VXLAN 端口相同。VXLAN 端口的默认值为4789。 ipv4_subnet-
OVN-Kubernetes 内部使用的 IPv4 地址范围。您必须确保 IP 地址范围没有与 OpenShift Container Platform 安装使用的任何其他子网重叠。IP 地址范围必须大于可添加到集群的最大节点数。默认值为
100.64.0.0/16。 routingViaHost-
值
true会设置本地网关模式,值false会设置共享网关模式。默认值为false。在本地网关模式中,流量通过主机网络堆栈路由。在共享网关模式中,流量不会通过主机网络堆栈路由。 ipForwarding:-
如果您需要节点的主机网络充当与 OVN-Kubernetes 不匹配的流量,请将 IP 转发设置为
Global和本地网关模式。
更新
mtu字段的oc patch命令示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新
gatewayConfig对象的oc patch命令示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当 MCO 更新每个机器配置池中的机器时,它会逐一重启每个节点。您必须等到所有节点都已更新。输入以下命令检查机器配置池状态:
oc get mcp
$ oc get mcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功更新的节点具有以下状态:
UPDATED=true、UPDATING=false、DEGRADED=false。注意默认情况下,MCO 会一次在一个池中更新一个机器,从而导致迁移总时间随着集群大小的增加而增加。
确认主机上新机器配置的状态:
要列出机器配置状态和应用的机器配置名称,请输入以下命令:
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证以下语句是否正确:
-
machineconfiguration.openshift.io/state字段的值为Done。 -
machineconfiguration.openshift.io/currentConfig字段的值等于machineconfiguration.openshift.io/desiredConfig字段的值。
-
要确认机器配置正确,请输入以下命令:
oc get machineconfig <config_name> -o yaml | grep ExecStart
$ oc get machineconfig <config_name> -o yaml | grep ExecStartCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这里的
<config_name>是machineconfiguration.openshift.io/currentConfig字段中机器配置的名称。机器配置可包括以下对 systemd 配置的更新:
ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果节点一直处于
NotReady状态,检查机器配置守护进程 pod 日志并解决所有错误。运行以下命令列出 pod:
oc get pod -n openshift-machine-config-operator
$ oc get pod -n openshift-machine-config-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置守护进程 pod 的名称使用以下格式:
machine-config-daemon-<seq>。<seq>值是一个随机的五个字符的字母数字序列。使用以下命令,输出在上一个输出中显示的第一个机器配置守护进程 pod 的 pod 日志:
oc logs <pod> -n openshift-machine-config-operator
$ oc logs <pod> -n openshift-machine-config-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
pod是机器配置守护进程 pod 的名称。- 解决上一命令输出中显示的日志中的任何错误。
要启动迁移,请使用以下命令配置 OVN-Kubernetes 网络插件:
要指定网络供应商而不更改集群网络 IP 地址块,请输入以下命令:
oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'$ oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要指定不同的集群网络 IP 地址块,请输入以下命令:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
cidr是 CIDR 块,prefix是集群中每个节点的 CIDR 块的分片。您不能使用任何与10064.0.0/16CIDR 块重叠的 CIDR 块,因为 OVN-Kubernetes 网络供应商在内部使用此块。重要您无法在迁移过程中更改服务网络地址块。
在继续执行后续步骤前,验证 Multus 守护进程集的 rollout 是否已完成:
oc -n openshift-multus rollout status daemonset/multus
$ oc -n openshift-multus rollout status daemonset/multusCopy to Clipboard Copied! Toggle word wrap Toggle overflow Multus pod 的名称采用
multus-<xxxxx>的形式,其中<xxxxx>是由字母组成的随机序列。pod 可能需要一些时间才能重启。输出示例
Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated... ... Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available... daemon set "multus" successfully rolled out
Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated... ... Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available... daemon set "multus" successfully rolled outCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要完成更改网络插件,请重新引导集群中的每个节点。您可以使用以下方法之一重新引导集群中的节点:
重要以下脚本同时重新引导集群中的所有节点。这可能导致集群不稳定。另一种选择是,每次只手动重新引导一个节点。逐一重新引导节点会导致,在具有多个节点的集群中出现大量停机时间。
在重新引导节点前,集群 Operator 无法正常工作。
使用
oc rsh命令,您可以使用类似如下的 bash 脚本:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过
ssh命令,您可以使用类似如下的 bash 脚本:该脚本假设您已将 sudo 配置为不提示输入密码。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
确认迁移成功完成:
要确认网络插件是 OVN-Kubernetes,请输入以下命令。
status.networkType的值必须是OVNKubernetes。oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'$ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要确认集群节点处于
Ready状态,请输入以下命令:oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要确认您的 pod 不在错误状态,请输入以下命令:
oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'$ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果节点上的 pod 处于错误状态,请重新引导该节点。
要确认所有集群 Operator 没有处于异常状态,请输入以下命令:
oc get co
$ oc get coCopy to Clipboard Copied! Toggle word wrap Toggle overflow 每个集群 Operator 的状态必须是:
AVAILABLE="True"、PROGRESSING="False"和DEGRADED="False"。如果 Cluster Operator 不可用或降级,请检查集群 Operator 的日志以了解更多信息。
只有在迁移成功且集群处于良好状态时完成以下步骤:
要从 CNO 配置对象中删除迁移配置,请输入以下命令:
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要删除 OpenShift SDN 网络供应商的自定义配置,请输入以下命令:
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要删除 OpenShift SDN 网络供应商命名空间,请输入以下命令:
oc delete namespace openshift-sdn
$ oc delete namespace openshift-sdnCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功迁移操作后,输入以下命令从
network.config自定义资源中删除network.openshift.io/network-type-migration-注解:oc annotate network.config cluster network.openshift.io/network-type-migration-
$ oc annotate network.config cluster network.openshift.io/network-type-migration-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
后续步骤
- 可选:在集群迁移后,您可以将 IPv4 单堆栈集群转换为支持 IPv4 和 IPv6 地址系列的双网络集群网络。如需更多信息,请参阅"协调 IPv4/IPv6 双栈网络"。
19.5.4. 了解 OVN-Kubernetes 中外部 IP 行为的更改 复制链接链接已复制到粘贴板!
当从 OpenShift SDN 迁移到 OVN-Kubernetes (OVN-K)时,使用外部 IP 的服务可能会因为网络策略强制而在命名空间中无法访问。
在 OpenShift SDN 中,外部 IP 默认可在命名空间间访问。但是,在 OVN-K 中,网络策略严格强制执行多租户隔离,从而防止访问通过外部 IP 从其他命名空间公开的服务。
为确保访问,请考虑以下替代方案:
- 使用入口或路由 :使用外部 IP 公开服务,在保持安全控制时配置入口或路由来允许外部访问。
-
调整
NetworkPolicy自定义资源(CR):修改NetworkPolicyCR 以明确允许从所需命名空间中访问,并确保允许流量访问指定的服务端口。如果没有明确允许到所需端口的流量,访问可能仍然被阻止,即使允许命名空间。 -
使用
LoadBalancer服务:如果适用,部署LoadBalancer服务而不是依赖于外部 IP。有关配置 "NetworkPolicy 和 external IP in OVN-Kubernetes" 的更多信息。
19.6. 回滚到 OpenShift SDN 网络供应商 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 离线 迁移方法或有限的实时迁移方法从 OVN-Kubernetes 网络插件回滚到 OpenShift SDN 网络插件。这只能在迁移到 OVN-Kubernetes 网络插件后完成。
- 如果您使用离线迁移方法从 OVN-Kubernetes 网络插件迁移到 OpenShift SDN 网络插件,您应该使用离线迁移回滚方法。
- 如果您使用有限的实时迁移方法从 OVN-Kubernetes 网络插件迁移到 OpenShift SDN 网络插件,则应使用有限的实时迁移回滚方法。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
19.6.1. 使用离线迁移方法回滚到 OpenShift SDN 网络插件 复制链接链接已复制到粘贴板!
集群管理员可以使用离线迁移方法回滚到 OpenShift SDN Container Network Interface (CNI) 网络插件。在迁移过程中,您必须手动重新引导集群中的每个节点。使用离线迁移方法时,集群会存在一些停机时间。
在启动回滚前,您必须等待 OpenShift SDN 到 OVN-Kubernetes 网络插件的迁移过程成功。
如果需要回滚到 OpenShift SDN,下表描述了这个过程。
| 用户发起的步骤 | 迁移操作 |
|---|---|
| 挂起 MCO 以确保它不会中断迁移。 | MCO 停止。 |
|
将名为 |
|
|
更新 |
|
| 重新引导集群中的每个节点。 |
|
| 在集群重启中的所有节点后启用 MCO。 |
|
先决条件
-
已安装 OpenShift CLI (
oc)。 - 可以使用具有 cluster-admin 角色的用户访问集群。
- 集群安装在使用 OVN-Kubernetes 网络插件配置的基础架构上。
- etcd 数据库的最新备份可用。
- 可以为每个节点触发手动重新引导。
- 集群处于已知良好状态,没有任何错误。
流程
停止由 Machine Config Operator(MCO)管理的所有机器配置池:
在 CLI 中输入以下命令来停止
master配置池:oc patch MachineConfigPool master --type='merge' --patch \ '{ "spec": { "paused": true } }'$ oc patch MachineConfigPool master --type='merge' --patch \ '{ "spec": { "paused": true } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 CLI 中输入以下命令来停止
worker机器配置池:oc patch MachineConfigPool worker --type='merge' --patch \ '{ "spec":{ "paused": true } }'$ oc patch MachineConfigPool worker --type='merge' --patch \ '{ "spec":{ "paused": true } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
要准备迁移,请在 CLI 中输入以下命令将 migration 字段设置为
null:oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 CLI 中输入以下命令,检查
Network.config.openshift.io对象的迁移状态是否为空。空命令输出表示对象不在迁移操作中。oc get Network.config cluster -o jsonpath='{.status.migration}'$ oc get Network.config cluster -o jsonpath='{.status.migration}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将补丁应用到
Network.operator.openshift.io对象,通过在 CLI 中输入以下命令将网络插件设置为 OpenShift SDN:oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要如果您在
Network.operator.openshift.io对象上的补丁操作完成前将补丁应用到Network.config.openshift.io对象,Cluster Network Operator (CNO) 进入降级状态,这会导致 slight 延迟直到 CNO 从降级状态恢复。在 CLI 中输入以下命令,确认
Network.config.openshift.io 集群对象的网络插件的迁移状态为OpenShiftSDN:oc get Network.config cluster -o jsonpath='{.status.migration.networkType}'$ oc get Network.config cluster -o jsonpath='{.status.migration.networkType}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将补丁应用到
Network.config.openshift.io对象,通过在 CLI 中输入以下命令将网络插件设置为 OpenShift SDN:oc patch Network.config.openshift.io cluster --type='merge' \ --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'$ oc patch Network.config.openshift.io cluster --type='merge' \ --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:禁用将几个 OVN-Kubernetes 功能自动迁移到 OpenShift SDN 等效功能:
- 出口 IP
- 出口防火墙
- 多播
要为之前记录的 OpenShift SDN 功能禁用配置自动迁移,请指定以下键:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
bool:指定是否启用功能的迁移。默认值是true。可选: 您可以自定义 OpenShift SDN 的以下设置,以满足您的网络基础架构的要求:
- 最大传输单元(MTU)
- VXLAN 端口
要自定义之前记录的设置或两个设置,请在 CLI 中自定义并输入以下命令。如果您不需要更改默认值,请从补丁中省略该键。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow mtu-
VXLAN 覆盖网络的 MTU。这个值通常是自动配置的;但是,如果集群中的节点没有都使用相同的 MTU,那么您必须将此值明确设置为比最小节点 MTU 的值小
50。 port-
VXLAN 覆盖网络的 UDP 端口。如果没有指定值,则默认为
4789。端口不能与 OVN-Kubernetes 使用的生成端口相同。Geneve 端口的默认值为6081。
patch 命令示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重新引导集群中的每个节点。您可以使用以下方法之一重新引导集群中的节点:
使用
oc rsh命令,您可以使用类似如下的 bash 脚本:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过
ssh命令,您可以使用类似如下的 bash 脚本:该脚本假设您已将 sudo 配置为不提示输入密码。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
等待 Multus 守护进程集的 rollout 完成。运行以下命令查看您的 rollout 状态:
oc -n openshift-multus rollout status daemonset/multus
$ oc -n openshift-multus rollout status daemonset/multusCopy to Clipboard Copied! Toggle word wrap Toggle overflow Multus pod 的名称采用
multus-<xxxxx>的形式,其中<xxxxx>是由字母组成的随机序列。pod 可能需要一些时间才能重启。输出示例
Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated... ... Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available... daemon set "multus" successfully rolled out
Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated... ... Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available... daemon set "multus" successfully rolled outCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重新引导集群中的节点并推出 multus pod 后,通过运行以下命令启动所有机器配置池:
启动 master 配置池:
oc patch MachineConfigPool master --type='merge' --patch \ '{ "spec": { "paused": false } }'$ oc patch MachineConfigPool master --type='merge' --patch \ '{ "spec": { "paused": false } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 启动 worker 配置池:
oc patch MachineConfigPool worker --type='merge' --patch \ '{ "spec": { "paused": false } }'$ oc patch MachineConfigPool worker --type='merge' --patch \ '{ "spec": { "paused": false } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
当 MCO 更新每个配置池中的机器时,它会重新引导每个节点。
默认情况下,MCO 会在一个时间段内为每个池更新一台机器,因此迁移完成所需要的时间会随集群大小的增加而增加。
确认主机上新机器配置的状态:
要列出机器配置状态和应用的机器配置名称,请在 CLI 中输入以下命令:
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证以下语句是否正确:
-
machineconfiguration.openshift.io/state字段的值为Done。 -
machineconfiguration.openshift.io/currentConfig字段的值等于machineconfiguration.openshift.io/desiredConfig字段的值。
-
要确认机器配置正确,在 CLI 中输入以下命令:
oc get machineconfig <config_name> -o yaml
$ oc get machineconfig <config_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这里的
<config_name>是machineconfiguration.openshift.io/currentConfig字段中机器配置的名称。
确认迁移成功完成:
要确认网络插件是 OpenShift SDN,请在 CLI 中输入以下命令。
status.networkType的值必须是OpenShiftSDN。oc get Network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'$ oc get Network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要确认集群节点处于
Ready状态,请在 CLI 中输入以下命令:oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果节点一直处于
NotReady状态,检查机器配置守护进程 pod 日志并解决所有错误。要列出 pod,在 CLI 中输入以下命令:
oc get pod -n openshift-machine-config-operator
$ oc get pod -n openshift-machine-config-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置守护进程 pod 的名称使用以下格式:
machine-config-daemon-<seq>。<seq>值是一个随机的五个字符的字母数字序列。要显示以上输出中显示的每个机器配置守护进程 pod 的 pod 日志,请在 CLI 中输入以下命令:
oc logs <pod> -n openshift-machine-config-operator
$ oc logs <pod> -n openshift-machine-config-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
pod是机器配置守护进程 pod 的名称。- 解决上一命令输出中显示的日志中的任何错误。
要确认您的 pod 不在错误状态,请在 CLI 中输入以下命令:
oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'$ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果节点上的 pod 处于错误状态,请重新引导该节点。
只有在迁移成功且集群处于良好状态时完成以下步骤:
要从 Cluster Network Operator 配置对象中删除迁移配置,请在 CLI 中输入以下命令:
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要删除 OVN-Kubernetes 配置,请在 CLI 中输入以下命令:
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要删除 OVN-Kubernetes 网络供应商命名空间,请在 CLI 中输入以下命令:
oc delete namespace openshift-ovn-kubernetes
$ oc delete namespace openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.6.2. 使用 Ansible playbook 回滚到 OpenShift SDN 网络插件 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 network.offline_migration_sdn_to_ovnk Ansible 集合中的 playbooks/playbook-rollback.yml 从 OVN-Kubernetes 插件回滚到 OpenShift SDN Container Network Interface (CNI) 网络插件。
先决条件
-
已安装
python3软件包,最小版本 3.10。 -
已安装
jmespath和jq软件包。 - 已登陆到 Red Hat Hybrid Cloud Console 并打开 Ansible Automation Platform web 控制台。
-
您创建了一条安全组规则,允许所有云平台上所有节点的端口
6081上用户数据报协议(UDP)数据包。如果没有此任务,您的集群可能无法调度 pod。
流程
安装
ansible-core软件包,最低为 2.15 版本。以下示例命令演示了如何在 Red Hat Enterprise Linux (RHEL)上安装ansible-core软件包:sudo dnf install -y ansible-core
$ sudo dnf install -y ansible-coreCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
ansible.cfg文件,并将类似以下示例的信息添加到该文件中。确保该文件存在于与ansible-galaxy命令和 playbook 运行相同的目录中。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 Ansible Automation Platform web 控制台中进入 Connect to Hub 页并完成以下步骤:
- 在页的离线令牌部分中,点 Load token 按钮。
- 在令牌加载后,点 Copy to clipboard 图标。
-
打开
ansible.cfg文件,并将 API 令牌粘贴到token=参数中。对ansible.cfg文件中指定的服务器 URL 进行身份验证需要 API 令牌。
输入以下
ansible-galaxy命令,安装network.offline_migration_sdn_to_ovnkAnsible 集合:ansible-galaxy collection install network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection install network.offline_migration_sdn_to_ovnkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证您系统上是否安装了
network.offline_migration_sdn_to_ovnkAnsible 集合:ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
network.offline_migration_sdn_to_ovnk 1.0.2
network.offline_migration_sdn_to_ovnk 1.0.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow network.offline_migration_sdn_to_ovnkAnsible 集合保存在~/.ansible/collections/ansible_collections/network/offline_migration_sdn_to_ovnk/的默认路径中。在
playbooks/playbook-migration.yml文件中配置回滚功能:Copy to Clipboard Copied! Toggle word wrap Toggle overflow rollback_disable_auto_migration-
禁用 OVN-Kubernetes 插件的自动迁移功能到 OpenShift SDN CNI 插件。如果禁用功能的自动迁移,还必须将
rollback_egress_ip、rollback_egress_firewall和rollback_multicast参数设置为false。如果您需要启用功能的自动迁移,请将 参数设置为false。 rollback_mtu- 可选参数,在迁移过程后将特定的最大传输单元(MTU)设置为集群网络。
rollback_vxlanPort-
设置 VXLAN (虚拟可扩展 LAN)端口的可选参数,供 OpenShift SDN CNI 插件使用。参数的默认值为
4790。
要运行
playbooks/playbook-rollback.yml文件,请输入以下命令:ansible-playbook -v playbooks/playbook-rollback.yml
$ ansible-playbook -v playbooks/playbook-rollback.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.6.3. 使用有限的实时迁移方法回滚到 OpenShift SDN 网络插件 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用有限的实时迁移方法回滚到 OpenShift SDN Container Network Interface (CNI) 网络插件。使用此方法迁移过程中,节点会自动重新引导,并且对集群的服务不会中断。
在启动回滚前,您必须等待 OpenShift SDN 到 OVN-Kubernetes 网络插件的迁移过程成功。
如果需要回滚到 OpenShift SDN,下表描述了这个过程。
| 用户发起的步骤 | 迁移操作 |
|---|---|
|
通过将 |
|
先决条件
-
已安装 OpenShift CLI (
oc)。 - 可以使用具有 cluster-admin 角色的用户访问集群。
- 集群安装在使用 OVN-Kubernetes 网络插件配置的基础架构上。
- etcd 数据库的最新备份可用。
- 可以为每个节点触发手动重新引导。
- 集群处于已知良好状态,没有任何错误。
流程
要启动回滚到 OpenShift SDN,请输入以下命令:
oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OpenShiftSDN"}}'$ oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OpenShiftSDN"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要监控迁移的进度,请输入以下命令:
watch -n1 'oc get network.config/cluster -o json | jq ".status.conditions[]|\"\\(.type) \\(.status) \\(.reason) \\(.message)\"" -r | column --table --table-columns NAME,STATUS,REASON,MESSAGE --table-columns-limit 4; echo; oc get mcp -o wide; echo; oc get node -o "custom-columns=NAME:metadata.name,STATE:metadata.annotations.machineconfiguration\\.openshift\\.io/state,DESIRED:metadata.annotations.machineconfiguration\\.openshift\\.io/desiredConfig,CURRENT:metadata.annotations.machineconfiguration\\.openshift\\.io/currentConfig,REASON:metadata.annotations.machineconfiguration\\.openshift\\.io/reason"'
$ watch -n1 'oc get network.config/cluster -o json | jq ".status.conditions[]|\"\\(.type) \\(.status) \\(.reason) \\(.message)\"" -r | column --table --table-columns NAME,STATUS,REASON,MESSAGE --table-columns-limit 4; echo; oc get mcp -o wide; echo; oc get node -o "custom-columns=NAME:metadata.name,STATE:metadata.annotations.machineconfiguration\\.openshift\\.io/state,DESIRED:metadata.annotations.machineconfiguration\\.openshift\\.io/desiredConfig,CURRENT:metadata.annotations.machineconfiguration\\.openshift\\.io/currentConfig,REASON:metadata.annotations.machineconfiguration\\.openshift\\.io/reason"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 该命令每秒打印以下信息:
-
network.config.openshift.io/cluster对象的状态的条件,报告迁移的进度。 -
与
machine-config-operator资源相关的不同节点的状态,包括它们是否正在升级或已升级,以及它们的当前和所需的配置。
-
只有在迁移成功且集群处于良好状态时完成以下步骤:
输入以下命令从
network.config自定义资源中删除network.openshift.io/network-type-migration=注解:oc annotate network.config cluster network.openshift.io/network-type-migration-
$ oc annotate network.config cluster network.openshift.io/network-type-migration-Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令删除 OVN-Kubernetes 网络供应商命名空间:
oc delete namespace openshift-ovn-kubernetes
$ oc delete namespace openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.7. 转换为 IPv4/IPv6 双栈网络 复制链接链接已复制到粘贴板!
作为集群管理员,您可以将 IPv4 单栈集群转换为支持 IPv4 和 IPv6 地址系列的双网络集群网络。转换为双栈网络后,新的和现有 pod 启用了双栈网络。
当使用需要 IPv6 的双栈网络时,您无法使用 IPv4 映射 IPv6 地址,如 ::FFFF:198.51.100.1。
19.7.1. 转换为双栈集群网络 复制链接链接已复制到粘贴板!
作为集群管理员,您可以将单堆栈集群网络转换为双栈集群网络。
将集群转换为使用双栈网络后,您必须为它们重新创建任何现有 pod 以接收 IPv6 地址,因为只有新 pod 会被分配 IPv6 地址。
将单堆栈集群网络转换为双栈集群网络包括创建补丁并将其应用到集群的网络和子网。您可以转换为在安装程序置备的基础架构或用户置备的基础架构上运行的集群的双栈集群网络。
更改 clusterNetwork、serviceNetwork、apiServerInternalIPs 和 ingressIP 对象的每个补丁操作都会触发重启集群。更改 MachineNetworks 对象不会导致重启集群。
安装程序置备的基础架构中,如果您需要将 API 和 Ingress 服务的 IPv6 虚拟 IP (VIP)添加到现有的双栈配置的集群中,则只需要修补基础架构,而不是集群的网络。
如果您已经将集群升级到 OpenShift Container Platform 4.16 或更高版本,且您需要将单堆栈集群网络转换为双栈集群网络,则必须从 install-config.yaml 文件中为 API 和 Ingress 服务指定现有的 IPv4 machineNetwork 网络配置。此配置可确保 IPv4 流量与默认网关在同一网络接口中。
带有为 machineNetwork 网络添加 IPv4 地址块的 YAML 配置文件示例
- op: add path: /spec/platformSpec/baremetal/machineNetworks/- value: 192.168.1.0/24 # ...
- op: add
path: /spec/platformSpec/baremetal/machineNetworks/-
value: 192.168.1.0/24
# ...
- 1
- 确保为机器操作的
machineNetwork网络指定地址块。您必须为机器网络选择 API 和 Ingress IP 地址。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。 - 集群使用 OVN-Kubernetes 网络插件。
- 集群节点具有 IPv6 地址。
- 您已根据基础架构配置了启用了 IPv6 的路由器。
流程
要为集群和服务网络指定 IPv6 地址块,请创建一个类似以下示例的 YAML 配置补丁文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 CLI 中输入以下命令来修补集群网络配置:
oc patch network.config.openshift.io cluster \ --type='json' --patch-file <file>.yaml
$ oc patch network.config.openshift.io cluster \1 --type='json' --patch-file <file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 其中
file指定您创建的 YAML 文件的名称。
输出示例
network.config.openshift.io/cluster patched
network.config.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在为 API 和 Ingress 服务添加了 IPv6 VIP 的安装程序置备的基础架构中,完成以下步骤:
为集群指定 API 和 Ingress 服务的 IPv6 VIP。创建类似以下示例的 YAML 配置补丁文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 CLI 中输入以下命令来修补基础架构:
oc patch infrastructure cluster \ --type='json' --patch-file <file>.yaml
$ oc patch infrastructure cluster \ --type='json' --patch-file <file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
- <file>
指定创建的 YAML 文件的名称。
输出示例
infrastructure/cluster patched
infrastructure/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
在 CLI 中输入以下命令来显示集群网络配置:
oc describe network
$ oc describe networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查集群网络配置是否识别您在 YAML 文件中指定的 IPv6 地址块,以验证在网络配置中成功安装补丁。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为在安装程序置备的基础架构中运行的集群完成以下附加任务:
在 CLI 中输入以下命令来显示集群基础架构配置:
oc describe infrastructure
$ oc describe infrastructureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查基础架构是否识别您在 YAML 文件中指定的 IPv6 地址块,以验证在集群基础架构上安装补丁是否成功。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.7.2. 转换为单堆栈集群网络 复制链接链接已复制到粘贴板!
作为集群管理员,您可以将双栈集群网络转换为单堆栈集群网络。
如果您最初将 IPv4 单堆栈集群网络转换为双栈集群,则只能转换回 IPv4 单堆栈集群,而不是 IPv6 单堆栈集群网络。相同限制适用于对 IPv6 单堆栈集群网络的转换(只能转换回 IPv6)。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。 - 集群使用 OVN-Kubernetes 网络插件。
- 集群节点具有 IPv6 地址。
- 您已启用了双栈网络。
流程
运行以下命令来编辑
networks.config.openshift.io自定义资源 (CR):oc edit networks.config.openshift.io
$ oc edit networks.config.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
删除在 "Converting to a dual-stack cluster network " 步骤中添加到
cidr和hostPrefix参数中的 IPv4 或 IPv6 配置。
19.8. 配置 OVN-Kubernetes 内部 IP 地址子网 复制链接链接已复制到粘贴板!
作为集群管理员,您可以更改 OVN-Kubernetes 网络插件用于加入和传输子网的 IP 地址范围。
19.8.1. 配置 OVN-Kubernetes 加入子网 复制链接链接已复制到粘贴板!
您可以更改 OVN-Kubernetes 使用的 join 子网,以避免与环境中已存在的子网冲突。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。 - 确保集群使用 OVN-Kubernetes 网络插件。
流程
要更改 OVN-Kubernetes 加入子网,请输入以下命令:
oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":$ oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig": {"ipv4":{"internalJoinSubnet": "<join_subnet>"}, "ipv6":{"internalJoinSubnet": "<join_subnet>"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<join_subnet>-
指定 OVN-Kubernetes 内部使用的 IP 地址子网。子网必须大于集群中的节点数量,且必须足够大,以适应集群中的每个节点一个 IP 地址。此子网不能与 OpenShift Container Platform 或主机本身使用的任何其他子网重叠。IPv4 的默认值为
100.64.0.0/16,IPv6 的默认值是fd98::/64。
输出示例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要确认配置处于活跃状态,请输入以下命令:
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 命令操作最多可能需要 30 分钟才能使此更改生效。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.8.2. 配置 OVN-Kubernetes 传输子网 复制链接链接已复制到粘贴板!
您可以更改 OVN-Kubernetes 使用的传输子网,以避免与环境中已存在的子网冲突。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。 - 确保集群使用 OVN-Kubernetes 网络插件。
流程
要更改 OVN-Kubernetes 传输子网,请输入以下命令:
oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":$ oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig": {"ipv4":{"internalTransitSwitchSubnet": "<transit_subnet>"}, "ipv6":{"internalTransitSwitchSubnet": "<transit_subnet>"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<transit_subnet>-
为分布式传输交换机指定一个 IP 地址子网,以启用 east-west 流量。此子网不能与 OVN-Kubernetes 或主机本身使用的任何其他子网重叠。IPv4 的默认值为
100.88.0.0/16,IPv6 的默认值是fd97::/64。
输出示例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要确认配置处于活跃状态,请输入以下命令:
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可能需要 30 分钟才能使此更改生效。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.9. 配置网关 复制链接链接已复制到粘贴板!
作为集群管理员,您可以配置 gatewayConfig 对象来管理外部流量离开集群的方式。为此,您可以将 routingViaHost 参数设置为以下值之一:
-
true表示出口流量通过托管 pod 的节点上的特定本地网关路由。通过主机的出口流量路由,此流量适用于主机的路由表。 -
false表示出口流量通过专用节点路由,但一组节点共享同一网关。出口流量不会通过主机路由。Open vSwitch (OVS)将流量直接输出到节点 IP 接口。
19.9.1. 配置出口路由策略 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 Cluster Network Operator (CNO)中的 gatewayConfig 规格配置出口路由策略。您可以使用以下步骤将 routingViaHost 字段设置为 true 或 false。
如果需要节点的主机网络充当与 OVN-Kubernetes 不相关的流量的路由器,按照流程中的可选步骤启用 IP 转发和 routingViaHost=true 配置。例如,将本地网关与 IP 转发相结合的可能用例包括:
- 配置通过节点的 IP 转发所有 pod 出口流量
- 将 OVN-Kubernetes CNI 与外部网络地址转换(NAT)设备集成
- 将 OVN-Kubernetes CNI 配置为使用内核路由表
先决条件
- 您以具有 admin 权限的用户身份登录。
流程
运行以下命令备份现有网络配置:
oc get network.operator cluster -o yaml > network-config-backup.yaml
$ oc get network.operator cluster -o yaml > network-config-backup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令,将
routingViaHost参数设置为true。然后,出口流量会根据您在节点上配置的路由通过特定的网关进行路由。oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"routingViaHost": true}}}}}'$ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"routingViaHost": true}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证
routingViaHost=true配置的正确应用程序:oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
$ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 值为
true表示出口流量通过托管 pod 的节点上的特定本地网关路由。参数的false值表示一组节点共享单个网关,因此流量不会通过单个主机路由。
可选:运行以下命令来全局启用 IP 转发:
oc patch network.operator cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}'$ oc patch network.operator cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证
ipForwardingspec 是否已设置为Global:oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
$ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10. 在默认网络中配置外部网关 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在默认网络上配置外部网关。
此功能提供以下优点:
- 根据每个命名空间对出口流量进行精细控制
- 静态和动态外部网关 IP 地址的灵活配置
- 支持 IPv4 和 IPv6 地址系列
19.10.1. 先决条件 复制链接链接已复制到粘贴板!
- 集群使用 OVN-Kubernetes 网络插件。
- 您的基础架构配置为路由来自二级外部网关的流量。
19.10.2. OpenShift Container Platform 如何决定外部网关 IP 地址 复制链接链接已复制到粘贴板!
您可以使用 k8s.ovn.org API 组中的 AdminPolicyBasedExternalRoute 自定义资源 (CR) 配置二级外部网关。CR 支持静态和动态方法来指定外部网关的 IP 地址。
AdminPolicyBasedExternalRoute CR 目标的每个命名空间不能被任何其他 AdminPolicyBasedExternalRoute CR 选择。命名空间不能有并发二级外部网关。
对策略的更改在控制器中被隔离。如果策略应用失败,对其他策略的更改不会触发其他策略的重试。策略只会重新评估,在对策略本身或与策略相关的对象(如目标命名空间、Pod 网关或命名空间从动态跃点托管它们)时应用更改可能出现的差异。
- 静态分配
- 您可以直接指定 IP 地址。
- 动态分配
您可以间接指定 IP 地址,带有命名空间和 pod 选择器,以及可选的网络附加定义。
- 如果提供了网络附加定义的名称,则使用网络附加定义的外部网关 IP 地址。
-
如果没有提供网络附加定义的名称,则使用 pod 本身的外部网关 IP 地址。但是,只有在 pod 配置为将
hostNetwork设置为true时,此方法才能正常工作。
19.10.3. AdminPolicyBasedExternalRoute 对象配置 复制链接链接已复制到粘贴板!
您可以使用以下属性来定义集群范围的 AdminPolicyBasedExternalRoute 对象。命名空间一次只能由一个 AdminPolicyBasedExternalRoute CR 选择。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
指定 |
|
|
|
指定路由策略应用到的命名空间选择器。外部流量只支持 from:
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: novxlan-externalgw-ecmp-4059
命名空间只能由一个 |
|
|
|
指定数据包转发到的目的地。需要是 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定静态 IP 地址的数组。 |
|
|
| 指定与配置了网络附加定义的 pod 对应的 pod 选择器,用作外部网关目标。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定下一个目的地跃点的 IPv4 或 IPv6 地址。 |
|
|
|
可选:指定网络是否支持 Bi-Directional Forwarding Detection (BFD)。默认值为 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定一个 [set-based](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)标签选择器来过滤与此网络配置匹配的命名空间中的 pod。 |
|
|
|
指定一个 |
|
|
|
可选:指定网络是否支持 Bi-Directional Forwarding Detection (BFD)。默认值为 |
|
|
| 可选:指定网络附加定义的名称。名称必须与与 pod 关联的逻辑网络列表匹配。如果没有指定此字段,则使用 pod 的主机网络。但是,pod 必须配置为主机网络 pod,才能使用主机网络。 |
19.10.3.1. 二级外部网关配置示例 复制链接链接已复制到粘贴板!
在以下示例中,AdminPolicyBasedExternalRoute 对象使用 kubernetes.io/metadata.name: novxlan-externalgw-ecmp-4059 标签在命名空间中将两个静态 IP 地址配置为 pod 的外部网关。
在以下示例中,AdminPolicyBasedExternalRoute 对象配置一个动态外部网关。用于外部网关的 IP 地址派生自与所选 pod 关联的额外网络附加。
在以下示例中,AdminPolicyBasedExternalRoute 对象同时配置静态和动态外部网关。
19.10.4. 配置二级外部网关 复制链接链接已复制到粘贴板!
您可以为集群中的命名空间在默认网络中配置外部网关。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
-
创建包含
AdminPolicyBasedExternalRoute对象的 YAML 文件。 要创建基于 admin 策略的外部路由,请输入以下命令:
oc create -f <file>.yaml
$ oc create -f <file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<file>- 指定您在上一步中创建的 YAML 文件的名称。
输出示例
adminpolicybasedexternalroute.k8s.ovn.org/default-route-policy created
adminpolicybasedexternalroute.k8s.ovn.org/default-route-policy createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要确认已创建了基于 admin 策略的外部路由,请输入以下命令:
oc describe apbexternalroute <name> | tail -n 6
$ oc describe apbexternalroute <name> | tail -n 6Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<name>-
指定
AdminPolicyBasedExternalRoute对象的名称。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.5. 其他资源 复制链接链接已复制到粘贴板!
- 有关额外网络附加的更多信息,请参阅了解多个网络
19.11. 配置出口 IP 地址 复制链接链接已复制到粘贴板!
作为集群管理员,您可以配置 OVN-Kubernetes Container Network Interface (CNI) 网络插件,为命名空间分配一个或多个出口 IP 地址,或分配给命名空间中的特定 pod。
目前,使用 HCP 集群的 ROSA 不支持配置出口 IP。
19.11.1. 出口 IP 地址架构设计和实施 复制链接链接已复制到粘贴板!
OpenShift Container Platform 出口 IP 地址功能可确保来自一个或多个命名空间中的一个或多个 pod 的流量具有集群网络之外的服务具有一致的源 IP 地址。
例如,您可能有一个 pod 定期查询托管在集群外服务器上的数据库。要强制对服务器进行访问要求,将数据包过滤设备配置为只允许来自特定 IP 地址的流量。为确保您可以可靠地允许从该特定 pod 访问服务器,您可以为向服务器发出请求的 pod 配置特定的出口 IP 地址。
分配给命名空间的出口 IP 地址与用来向特定目的地发送流量的出口路由器不同。
在一些集群配置中,应用程序 Pod 和入口路由器 pod 在同一个节点上运行。如果您在这种情况下为应用程序项目配置出口 IP 地址,当您向应用程序项目发送请求时,不会使用 IP 地址。
不能在任何 Linux 网络配置文件中配置出口 IP 地址,比如 ifcfg-eth0。
19.11.1.1. 平台支持 复制链接链接已复制到粘贴板!
在以下平台上支持在主主机网络中运行的 Egress IP 地址功能:
| 平台 | 支持 |
|---|---|
| 裸机 | 是 |
| VMware vSphere | 是 |
| Red Hat OpenStack Platform(RHOSP) | 是 |
| Amazon Web Services (AWS) | 是 |
| Google Cloud | 是 |
| Microsoft Azure | 是 |
| IBM Z® 和 IBM® LinuxONE | 是 |
| IBM Z® and IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM | 是 |
| IBM Power® | 是 |
| Nutanix | 是 |
在以下平台上支持在二级主机网络上运行的 Egress IP 地址功能:
| 平台 | 支持 |
|---|---|
| 裸机 | 是 |
在 Amazon Web Services(AWS)上置备的集群中不支持使用 EgressIP 功能将出口 IP 地址分配给 control plane 节点。(BZ#2039656)。
19.11.1.2. 公共云平台注意事项 复制链接链接已复制到粘贴板!
通常,公共云提供商对出口 IP 施加一个限制。这意味着,对于公共云基础架构上置备的集群,每个节点都有可分配 IP 地址的限制。如下公式描述了每个节点的可分配 IP 地址或 IP 容量 上限:
IP capacity = public cloud default capacity - sum(current IP assignments)
IP capacity = public cloud default capacity - sum(current IP assignments)
虽然 Egress IP 功能管理每个节点的 IP 地址容量,但在部署中计划这个约束非常重要。例如,如果公共云提供商将 IP 地址容量限制为每个节点 10 个 IP 地址,并且您有 8 个节点,则可分配的 IP 地址总数仅为 80。为了获得更高的 IP 地址容量,您需要分配额外的节点。例如,如果您需要 150 个可分配的 IP 地址,则需要分配 7 个节点。
要确认公共云环境中任何节点的 IP 容量和子网,您可以输入 oc get node <node_name> -o yaml 命令。cloud.network.openshift.io/egress-ipconfig 注解包括节点的容量和子网信息。
注解值是一个带有单个对象的数组,其中包含为主网络接口提供以下信息的字段:
-
Interface: 指定 AWS 和 Azure 上的接口 ID 以及 Google Cloud 上的接口名称。 -
ifaddr:为一个或多个 IP 地址系列指定子网掩码。 -
capacity:指定节点的 IP 地址容量。在 AWS 上,IP 地址容量为每个 IP 地址系列提供。在 Azure 和 Google Cloud 上,IP 地址容量同时包含 IPv4 和 IPv6 地址。
为节点之间的流量自动附加和分离出口 IP 地址。这允许命名空间中许多 pod 的流量在集群外的位置上具有一致的源 IP 地址。这还支持 OpenShift SDN 和 OVN-Kubernetes,这是 OpenShift Container Platform 4.16 中 Red Hat OpenShift Networking 中的默认网络插件。
RHOSP 出口 IP 地址功能会创建一个名为 egressip-<IP address> 的 neutron 保留端口。使用与 OpenShift Container Platform 集群安装相同的 RHOSP 用户,您可以为此保留端口分配一个浮动 IP 地址,以便为出口流量具有可预测的 SNAT 地址。当 RHOSP 网络上的出口 IP 地址从一个节点移到另一个节点时,因为节点故障转移(例如,neutron 保留端口会被删除并重新创建)。这意味着浮动 IP 关联丢失,您需要手动将浮动 IP 地址重新分配给新的保留端口。
当 RHOSP 集群管理员为保留端口分配一个浮动 IP 时,OpenShift Container Platform 无法删除保留端口。CloudPrivateIPConfig 对象无法执行删除和移动操作,直到 RHOSP 集群管理员从保留端口取消分配浮动 IP。
以下示例演示了来自多个公共云提供商上节点的注解。注解被缩进以便于阅读。
AWS 上的 cloud.network.openshift.io/egress-ipconfig 注解示例
Google Cloud 上的 cloud.network.openshift.io/egress-ipconfig 注解示例
以下小节描述了支持公共云环境的 IP 地址容量,用于容量计算。
19.11.1.2.1. Amazon Web Services(AWS)IP 地址容量限制 复制链接链接已复制到粘贴板!
在 AWS 上,IP 地址分配的限制取决于配置的实例类型。如需更多信息,请参阅 每个实例类型的每个网络接口的 IP 地址
19.11.1.2.2. Google Cloud IP 地址容量限制 复制链接链接已复制到粘贴板!
在 Google Cloud 上,网络模型通过 IP 地址别名而不是 IP 地址分配来实施额外的节点 IP 地址。但是,IP 地址容量直接映射到 IP 别名容量。
IP 别名分配存在以下容量限制:
- 每个节点,IPv4 和 IPv6 的最大 IP 别名数为 100 个。
- 对于每个 VPC,IP 别名的最大数量没有被指定,但 OpenShift Container Platform 可扩展性测试显示最大为 15,000 个。
如需更多信息,请参阅 Per instance 配额和 Alias IP 范围概述。
19.11.1.2.3. Microsoft Azure IP 地址容量限制 复制链接链接已复制到粘贴板!
在 Azure 上,IP 地址分配有以下容量限制:
- 对于每个 NIC,对于 IPv4 和 IPv6,可分配 IP 地址的最大数量为 256。
- 对于每个虚拟网络,分配的 IP 地址的最大数量不能超过 65,536。
如需更多信息,请参阅网络限制。
19.11.1.3. 在额外网络接口中使用出口 IP 的注意事项 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 中,出口 IP 为管理员提供了一种控制网络流量的方法。Egress IP 可以和 br-ex Open vSwitch (OVS) 网桥接口,以及启用了 IP 连接的任何物理接口一起使用。
您可以运行以下命令来检查网络接口类型:
ip -details link show
$ ip -details link show
主网络接口被分配一个节点 IP 地址,该地址还包含子网掩码。此节点 IP 地址的信息可以通过检查 k8s.ovn.org/node-primary-ifaddr 注解从集群中的每个节点检索。在 IPv4 集群中,此注解类似以下示例:"k8s.ovn.org/node-primary-ifaddr: {"ipv4":"192.168.111.23/24"}"。
如果出口 IP 不在主网络接口子网的子网中,您可以在不是主网络接口类型的另一个 Linux 网络接口中使用出口 IP。这样一来,OpenShift Container Platform 管理员提供了对网络方面的更高级别控制,如路由、寻址、分段和安全策略。此功能允许用户选择通过特定网络接口路由工作负载流量,如流量分段或满足特殊要求。
如果出口 IP 不在主网络接口的子网中,如果节点上存在另一个网络接口,则可能会出现为出口流量选择另一个网络接口。
您可以通过检查 k8s.ovn.org/host-cidrs Kubernetes 节点注解来确定其他哪些网络接口可能支持出口 IP。此注释包含为主网络接口找到的地址和子网掩码。它还包含其他网络接口地址和子网掩码信息。这些地址和子网掩码分配给使用最长前缀匹配路由机制的网络接口,以确定哪个网络接口支持出口 IP。
OVN-Kubernetes 提供了一种机制来控制和直接从特定命名空间和 pod 出站网络流量。这样可确保它通过特定的网络接口和特定的出口 IP 地址退出集群。
19.11.1.3.1. 为不是主网络接口的网络接口分配出口 IP 的要求 复制链接链接已复制到粘贴板!
对于希望出口 IP 和流量通过不是主网络接口的特定接口路由的用户,必须满足以下条件:
- OpenShift Container Platform 安装在裸机集群中。此功能在云或 hypervisor 环境中被禁用。
- 您的 OpenShift Container Platform pod 没有配置为 host-networked。
- 如果删除了网络接口,或者 IP 地址和子网掩码允许删除在接口上托管的出口 IP,则会重新配置出口 IP。因此,egress IP 可以分配给另一个节点和接口。
- 如果您在辅助网络接口卡(NIC)上使用 Egress IP 地址,则必须使用 Node Tuning Operator 在二级 NIC 上启用 IP 转发。
19.11.1.4. 将出口 IP 分配给 pod 复制链接链接已复制到粘贴板!
要将一个或多个出口 IP 分配给命名空间中的命名空间或特定 pod,必须满足以下条件:
-
集群中至少有一个节点必须具有
k8s.ovn.org/egress-assignable: ""标签。 -
存在一个
EgressIP对象定义一个或多个出口 IP 地址,用作从命名空间中离开集群的流量的源 IP 地址。
如果您在为出口 IP 分配标记集群中的任何节点之前创建 EgressIP 对象,OpenShift Container Platform 可能会将每个出口 IP 地址分配给第一个节点,并使用 k8s.ovn.org/egress-assignable: "" 标签。
要确保出口 IP 地址在集群中的不同节点广泛分发,请在创建任何 EgressIP 对象前,始终将标签应用到您想托管出口 IP 地址的节点。
19.11.1.5. 将出口 IP 分配给节点 复制链接链接已复制到粘贴板!
在创建 EgressIP 对象时,以下条件适用于标记为 k8s.ovn.org/egress-assignable: "" 标签的节点:
- 每次不会将出口 IP 地址分配给多个节点。
- 出口 IP 地址可在可以托管出口 IP 地址的可用节点之间平衡。
如果
EgressIP对象中的spec.EgressIPs数组指定了多个 IP 地址,则适用以下条件:- 任何节点都不会托管超过一个指定的 IP 地址。
- 流量在给定命名空间的指定 IP 地址之间大致相等。
- 如果节点不可用,则会自动重新分配给它的所有出口 IP 地址,但符合前面描述的条件。
当 Pod 与多个 EgressIP 对象的选择器匹配时,无法保证在 EgressIP 对象中指定的出口 IP 地址被分配为 pod 的出口 IP 地址。
另外,如果 EgressIP 对象指定了多个出口 IP 地址,则无法保证可以使用哪些出口 IP 地址。例如,如果 pod 与带有两个出口 IP 地址 (10.10.20.1 和 10.10.20.2) 的 EgressIP 对象的选择器匹配,其中任何一个都可以用于每个 TCP 连接或 UDP 对话。
19.11.1.6. 出口 IP 地址配置架构图 复制链接链接已复制到粘贴板!
下图显示了出口 IP 地址配置。图中描述了,在一个集群的三个节点上运行的两个不同命名空间中的四个 pod。节点从主机网络上的 192.168.126.0/18 CIDR 块中分配 IP 地址。
Node 1 和 Node 3 都标记为 k8s.ovn.org/egress-assignable: "",因此可用于分配出口 IP 地址。
图中的横线描述了 pod1、pod2 和 pod 3 的流量流,通过 pod 网络来从 Node 1 和 Node 3 出口集群。当外部服务从示例 EgressIP 对象选择的任何 pod 接收流量时,源 IP 地址为 192.168.126.10 或 192.168.126.102。这两个节点之间流量大致平衡。
图中的以下资源被详细描述:
命名空间对象命名空间在以下清单中定义:
命名空间对象
Copy to Clipboard Copied! Toggle word wrap Toggle overflow EgressIP对象以下
EgressIP对象描述了一个配置,该配置选择将env标签设置为prod的任意命名空间中的所有 pod。所选 pod 的出口 IP 地址为192.168.126.10和192.168.126.102。EgressIP对象Copy to Clipboard Copied! Toggle word wrap Toggle overflow 对于上例中的配置,OpenShift Container Platform 会为可用节点分配两个出口 IP 地址。
status字段显示是否以及在哪里分配了出口 IP 地址。
19.11.2. EgressIP 对象 复制链接链接已复制到粘贴板!
以下 YAML 描述了 EgressIP 对象的 API。对象有效的范围为集群,它不是在命名空间中创建的。
以下 YAML 描述了命名空间选择器的小节:
命名空间选择器小节
namespaceSelector:
matchLabels:
<label_name>: <label_value>
namespaceSelector:
matchLabels:
<label_name>: <label_value>
- 1
- 命名空间的一个或多个匹配规则。如果提供多个匹配规则,则会选择所有匹配的命名空间。
以下 YAML 描述了 pod 选择器的可选小节:
Pod 选择器片段
podSelector:
matchLabels:
<label_name>: <label_value>
podSelector:
matchLabels:
<label_name>: <label_value>
- 1
- 可选:与指定
namespaceSelector规则匹配的命名空间中 pod 的一个或多个匹配规则。如果指定,则仅选择匹配的 pod。命名空间中的其他 Pod 不会被选择。
在以下示例中,EgressIP 对象将 192.168.126.11 和 192.168.126.102 出口 IP 地址与将 app 标签设置为 web 的 pod 关联,并位于将 env 标签设置为 prod 的命名空间中:
EgressIP 对象示例
在以下示例中,EgressIP 对象将 192.168.127.30 和 192.168.127.40 出口 IP 地址与任何没有将 environment 标签设置为 development 的 pod 相关联:
EgressIP 对象示例
19.11.3. 为 EgressIP 对象配置双栈网络 复制链接链接已复制到粘贴板!
对于为双栈网络配置的集群,您可以将双栈网络应用到单个 EgressIP 对象。然后,EgressIP 对象可以将双栈网络扩展到 pod。
红帽不支持创建两个 EgressIP 对象来代表双栈网络。例如,使用一个对象指定 IPv4 地址并使用另一个对象指定 IPv6 地址。此配置限制会影响到 pod 的地址类型分配。
先决条件
-
您创建两个出口节点,以便
EgressIP对象可将 IPv4 地址分配给一个节点,并将 IPv6 地址分配给其他节点。如需更多信息,请参阅"向节点"分配出口 IP 地址"。
流程
创建
EgressIP对象并为对象配置 IPv4 和 IPv6 地址。以下示例EgressIP对象使用选择器来标识哪些 pod 将指定的出口 IP 地址用于其出站流量:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
创建
Pod清单文件以测试并验证您的EgressIP对象。pod 充当发送出站流量的客户端工作负载,以验证EgressIP策略是否按预期工作。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<labels>-
设置自定义标识符,以便
EgressIP对象可以使用这些标签将出口 IP 地址应用到目标 pod。
从 pod 内运行
curl请求,再到外部服务器。此操作会验证出站流量是否使用您在EgressIP对象中指定的地址。curl <ipv_address>
$ curl <ipv_address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<ipv_address>-
根据
EgressIP对象,输入 IPv4 或 IPv6 地址。
19.11.4. egressIPConfig 对象 复制链接链接已复制到粘贴板!
作为出口 IP 的功能,reachabilityTotalTimeoutSeconds 参数配置 EgressIP 节点可访问性检查总超时时间(以秒为单位)。如果在这个超时时间内无法访问 EgressIP 节点,则会声明该节点。
您可以在配置文件中为 egressIPConfig 对象设置 reachabilityTotalTimeoutSeconds 的值。设置较大的值可能会导致 EgressIP 实现对节点更改做出反应的速度较慢。对于有问题的 EgressIP 节点,这个实现的反应会较慢。
如果您从 egressIPConfig 对象中省略了 reachabilityTotalTimeoutSeconds 参数,则平台会选择一个合理的默认值,这可能会随时间变化。当前的默认值为 1 秒。0 代表禁用 EgressIP 节点的访问性检查。
以下 egressIPConfig 对象描述了将 reachabilityTotalTimeoutSeconds 从默认的 1 秒探测改为 5 秒探测:
19.11.5. 标记节点以托管出口 IP 地址 复制链接链接已复制到粘贴板!
您可以将 k8s.ovn.org/egress-assignable="" 标签应用到集群中的节点,以便 OpenShift Container Platform 可以为该节点分配一个或多个出口 IP 地址。
先决条件
-
安装 OpenShift CLI(
oc)。 - 以集群管理员身份登录集群。
流程
要标记节点,使其可以托管一个或多个出口 IP 地址,请输入以下命令:
oc label nodes <node_name> k8s.ovn.org/egress-assignable=""
$ oc label nodes <node_name> k8s.ovn.org/egress-assignable=""1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 要标记的节点的名称。
提示您还可以应用以下 YAML 将标签添加到节点:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.11.6. 后续步骤 复制链接链接已复制到粘贴板!
19.12. 分配出口 IP 地址 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为从一个命名空间中,或从一个命名空间内的特定 pod 中离开集群的网络流量分配一个出口 IP 地址。
19.12.1. 为一个命名空间分配出口 IP 地址 复制链接链接已复制到粘贴板!
您可以将一个或多个出口 IP 地址分配给一个命名空间,或分配给命名空间中的特定 pod。
先决条件
-
安装 OpenShift CLI(
oc)。 - 以集群管理员身份登录集群。
- 至少配置一个节点来托管出口 IP 地址。
流程
创建
EgressIP对象:-
创建一个
<egressips_name>.yaml文件,其中<egressips_name>是对象的名称。 在您创建的文件中,定义一个
EgressIP对象,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
创建一个
运行以下命令来创建对象。
oc apply -f <egressips_name>.yaml
$ oc apply -f <egressips_name>.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<egressips_name>替换为对象的名称。
输出示例
egressips.k8s.ovn.org/<egressips_name> created
egressips.k8s.ovn.org/<egressips_name> createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
可选:保存
<egressips_name>.yaml文件,以便稍后进行修改。 为需要出口 IP 地址的命名空间添加标签。要在第 1 步中定义的
EgressIP对象的命名空间中添加标签,请运行以下命令:oc label ns <namespace> env=qa
$ oc label ns <namespace> env=qa1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<namespace>替换为需要出口 IP 地址的命名空间。
验证
要显示集群中所有正在使用的出口 IP,请输入以下命令:
oc get egressip -o yaml
$ oc get egressip -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意无论配置了多少个出口 IP 地址,
oc get egressip只返回一个出口 IP 地址。这并不是程序错误,它是 Kubernetes 的一个限制。作为临时解决方案,您可以传递-o yaml或-o json标志来返回所有正在使用的出口 IP 地址。输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.13. 配置出口服务 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用 egress 服务为负载均衡器服务后面的 pod 配置出口流量。
出口服务只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
您可以使用以下方法使用 EgressService 自定义资源(CR)管理出口流量:
将负载均衡器服务 IP 地址分配为负载均衡器服务后面的 pod 的源 IP 地址。
将负载均衡器 IP 地址分配在这个上下文中的源 IP 地址对于显示单个出口和入口点很有用。例如,在某些情况下,与负载均衡器服务后面的应用程序通信的外部系统可能会预期应用程序的源和目标 IP 地址相同。
注意当您将负载均衡器服务 IP 地址分配给服务后面的 pod 的出口流量时,OVN-Kubernetes 会将入口和出口点限制为单一节点。这限制了 MetalLB 通常提供的流量的负载均衡。
将负载均衡器后面的 pod 的出口流量分配给与默认节点网络不同的网络。
这可用于将负载均衡器后面的应用程序的出口流量分配给与默认网络不同的网络。通常,不同的网络通过使用与网络接口关联的 VRF 实例来实施。
19.13.1. 出口服务自定义资源 复制链接链接已复制到粘贴板!
在 EgressService 自定义资源中定义出口服务的配置。以下 YAML 描述了配置出口服务的字段:
- 1
- 指定出口服务的名称。
EgressService资源的名称必须与您要修改的负载均衡器服务的名称匹配。 - 2
- 指定出口服务的命名空间。
EgressService的命名空间必须与您要修改的负载均衡器服务的命名空间匹配。egress 服务是命名空间范围的。 - 3
- 为服务后面的 pod 指定出口流量的源 IP 地址。有效值为
LoadBalancerIP或Network。使用LoadBalancerIP值将LoadBalancer服务入口 IP 地址分配为出口流量的源 IP 地址。指定Network将网络接口 IP 地址分配为出口流量的源 IP 地址。 - 4
- 可选: 如果您将
LoadBalancerIP值用于sourceIPBy规格,则单一节点处理LoadBalancer服务流量。使用nodeSelector字段来限制哪些节点可以被分配。当选择节点来处理服务流量时,OVN-Kubernetes 以以下格式标记节点:egress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: ""。如果没有指定nodeSelector字段,任何节点都可以管理LoadBalancer服务流量。 - 5
- 可选:指定出口流量的路由表 ID。确保值与
NodeNetworkConfigurationPolicy资源中定义的route-table-idID 匹配。如果没有network规格,egress 服务将使用默认主机网络。
出口服务规格示例
19.13.2. 部署出口服务 复制链接链接已复制到粘贴板!
您可以部署出口服务,以管理 LoadBalancer 服务后面的 pod 的出口流量。
以下示例将出口流量配置为具有与 LoadBalancer 服务的入口 IP 地址相同的源 IP 地址。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 -
已配置了 MetalLB
BGPPeer资源。
流程
为服务创建一个带有所需 IP 的
IPAddressPoolCR:创建一个文件,如
ip-addr-pool.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为 IP 地址池应用配置:
oc apply -f ip-addr-pool.yaml
$ oc apply -f ip-addr-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建
Service和EgressServiceCR:创建一个文件,如
service-egress-service.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果使用
sourceIPBy: "LoadBalancerIP"设置,您必须在BGPAdvertisement自定义资源(CR) 中指定 load-balancer 节点。运行以下命令,为服务和出口服务应用配置:
oc apply -f service-egress-service.yaml
$ oc apply -f service-egress-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建
BGPAdvertisementCR 来公告服务:创建一个文件,如
service-bgp-advertisement.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 在本例中,
EgressServiceCR 将出口流量的源 IP 地址配置为使用负载均衡器服务 IP 地址。因此,您必须指定负载均衡器节点返回流量,以便为来自 pod 的流量使用相同的返回路径。
验证
运行以下命令,验证您可以访问 MetalLB 服务后运行的 pod 的应用程序端点:
curl <external_ip_address>:<port_number>
$ curl <external_ip_address>:<port_number>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 更新外部 IP 地址和端口号,以适合您的应用程序端点。
-
如果您将
LoadBalancer服务的入口 IP 地址分配为出口流量的源 IP 地址,请使用tcpdump等工具分析外部客户端接收的数据包来验证此配置。
19.14. 使用出口路由器 pod 的注意事项 复制链接链接已复制到粘贴板!
19.14.1. 关于出口路由器 pod 复制链接链接已复制到粘贴板!
OpenShift Container Platform 出口路由器(egress router ) pod 使用一个来自专用的私有源 IP 地址,将网络流量重定向到指定的远程服务器。出口路由器 pod 可以将网络流量发送到设置为仅允许从特定 IP 地址访问的服务器。
出口路由器 pod 并不适用于所有外向的连接。创建大量出口路由器 pod 可能会超过您的网络硬件的限制。例如,为每个项目或应用程序创建出口路由器 pod 可能会导致,在转换为使用软件来进行 MAC 地址过滤前超过了网络接口可以处理的本地 MAC 地址的数量。
出口路由器镜像与 Amazon AWS、Azure Cloud 或其他不支持第 2 层操作的云平台不兼容,因为它们与 macvlan 流量不兼容。
19.14.1.1. 出口路由器模式 复制链接链接已复制到粘贴板!
在重定向模式中,出口路由器 Pod 配置 iptables 规则,将流量从其自身 IP 地址重定向到一个或多个目标 IP 地址。需要使用保留源 IP 地址的客户端 pod 必须配置为访问出口路由器的服务,而不是直接连接到目标 IP。您可以使用 curl 命令从应用程序 pod 访问目标服务和端口。例如:
curl <router_service_IP> <port>
$ curl <router_service_IP> <port>
egress router CNI 插件只支持重定向模式。这与您可以使用 OpenShift SDN 部署的出口路由器实现不同。与 OpenShift SDN 的出口路由器不同,egress router CNI 插件不支持 HTTP 代理模式或 DNS 代理模式。
19.14.1.2. 出口路由器 pod 的实现 复制链接链接已复制到粘贴板!
出口路由器实施使用出口路由器 Container Network Interface(CNI)插件。该插件将二级网络接口添加到 pod。
出口路由器是一个带有两个网络接口的 pod。例如,pod 可以具有 eth0 和 net1 网络接口。eth0 接口位于集群网络中,pod 将继续将接口用于与集群相关的普通网络流量。net1 接口位于第二个网络中,它拥有那个网络的 IP 地址和网关。OpenShift Container Platform 集群中的其他 pod 可以访问出口路由器服务,服务使 pod 可以访问外部服务。出口路由器作为 pod 和外部系统间的桥接。
离开出口路由器的流量会通过一个节点退出,但数据包带有来自路由器 pod 的 net1 接口的 MAC 地址。
添加出口路由器自定义资源时,Cluster Network Operator 会创建以下对象:
-
pod 的
net1二级网络接口的网络附加定义。 - 出口路由器的部署。
如果您删除了一个出口路由器自定义资源,Operator 会删除上列表中与出口路由器关联的两个对象。
19.14.1.3. 部署注意事项 复制链接链接已复制到粘贴板!
出口路由器 pod 会为节点的主网络接口添加额外的 IP 地址和 MAC 地址。因此,您可能需要配置虚拟机监控程序或云供应商来允许额外的地址。
- Red Hat OpenStack Platform (RHOSP)
如果在 RHOSP 上部署 OpenShift Container Platform,则必须允许来自 OpenStack 环境上的出口路由器 Pod 的 IP 和 MAC 地址的流量。如果您不允许流量,则通信会失败:
openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
$ openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - VMware vSphere
- 如果您使用 VMware vSphere,请参阅 VMware 文档来保护 vSphere 标准交换机。通过从 vSphere Web 客户端中选择主机虚拟交换机来查看并更改 VMware vSphere 默认设置。
具体来说,请确保启用了以下功能:
19.14.1.4. 故障切换配置 复制链接链接已复制到粘贴板!
为了避免停机,Cluster Network Operator 会将出口路由器 pod 部署为部署资源。部署名称为 egress-router-cni-deployment。与部署对应的 pod 具有 app=egress-router-cni 标签。
要为部署创建新服务,请使用 oc expose deployment/egress-router-cni-deployment --port <port_number> 命令或创建类似以下示例的文件:
19.15. 以重定向模式部署出口路由器 pod 复制链接链接已复制到粘贴板!
作为集群管理员,您可以部署出口路由器 Pod,将流量重新指向来自保留源 IP 地址的指定目标 IP 地址。
出口路由器实施使用出口路由器 Container Network Interface(CNI)插件。
19.15.1. 出口路由器自定义资源 复制链接链接已复制到粘贴板!
在出口路由器自定义资源中定义出口路由器 pod 的配置。以下 YAML 描述了以重定向模式配置出口路由器的字段:
- 1
- 可选:
namespace字段指定要在其中创建出口路由器的命名空间。如果您没有在文件或命令行中指定值,则会使用default命名空间。 - 2
address字段指定要在第二个网络接口上配置的 IP 地址。- 3
ip字段指定节点用于出口路由器 pod 的物理网络中保留源 IP 地址和子网掩码。使用 CIDR 表示法指定 IP 地址和网络掩码。- 4
gateway字段指定网络网关的 IP 地址。- 5
- 可选:
redirectRules字段指定出口目的地 IP 地址、出口路由器端口和协议的组合。到指定端口和协议中的出口路由器的传入连接路由到目标 IP 地址。 - 6
- 可选:
targetPort字段指定目标 IP 地址上的网络端口。如果没有指定此字段,流量将路由到它到达的同一网络端口。 - 7
protocol字段支持 TCP、UDP 或 SCTP。- 8
- 可选:
fallbackIP字段指定目标 IP 地址。如果没有指定任何重定向规则,出口路由器会将所有流量发送到这个回退 IP 地址。如果您指定了重定向规则,则出口路由器将任何与规则中定义的网络端口的连接发送到这个回退 IP 地址。如果没有指定此字段,出口路由器会拒绝与规则中没有定义的网络端口的连接。
出口路由器规格示例
19.15.2. 以重定向模式部署出口路由器 复制链接链接已复制到粘贴板!
您可以部署出口路由器,将其自身保留源 IP 地址的流量重定向到一个或多个目标 IP 地址。
添加出口路由器后,需要使用保留源 IP 地址的客户端 pod 必须修改为连接到出口路由器,而不是直接连接到目标 IP。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
- 创建出口路由器定义。
为确保其他 pod 可以找到出口路由器 pod 的 IP 地址,请创建一个使用出口路由器的服务,如下例所示:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定出口路由器的标签。显示的值由 Cluster Network Operator 添加,且不可配置。
创建服务后,您的 Pod 可以连接到该服务。出口路由器 pod 将流量重定向到目标 IP 地址中对应的端口。连接来自保留的源 IP 地址。
验证
要验证 Cluster Network Operator 是否启动了出口路由器,请完成以下步骤:
查看 Operator 为出口路由器创建的网络附加定义:
oc get network-attachment-definition egress-router-cni-nad
$ oc get network-attachment-definition egress-router-cni-nadCopy to Clipboard Copied! Toggle word wrap Toggle overflow 网络附加定义的名称不可配置。
输出示例
NAME AGE egress-router-cni-nad 18m
NAME AGE egress-router-cni-nad 18mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看出口路由器 pod 的部署:
oc get deployment egress-router-cni-deployment
$ oc get deployment egress-router-cni-deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 部署的名称不可配置。
输出示例
NAME READY UP-TO-DATE AVAILABLE AGE egress-router-cni-deployment 1/1 1 1 18m
NAME READY UP-TO-DATE AVAILABLE AGE egress-router-cni-deployment 1/1 1 1 18mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看出口路由器 pod 的状态:
oc get pods -l app=egress-router-cni
$ oc get pods -l app=egress-router-cniCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE egress-router-cni-deployment-575465c75c-qkq6m 1/1 Running 0 18m
NAME READY STATUS RESTARTS AGE egress-router-cni-deployment-575465c75c-qkq6m 1/1 Running 0 18mCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 查看出口路由器 pod 的日志和路由表。
获取出口路由器 pod 的节点名称:
POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")$ POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在目标节点上进入一个 debug 会话。此步骤被实例化为一个名为
<node_name>-debug的 debug pod:oc debug node/$POD_NODENAME
$ oc debug node/$POD_NODENAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
/host设为 debug shell 中的根目录。debug pod 在 pod 中的/host中挂载主机 的 root 文件系统。将根目录改为/host,您可以从主机的可执行路径中运行二进制文件:chroot /host
# chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
chroot环境控制台中显示出口路由器日志:cat /tmp/egress-router-log
# cat /tmp/egress-router-logCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当您启动出口路由器时,通过创建
EgressRouter对象来启动出口路由器时,日志文件位置和日志记录级别不可配置,如下所述。在
chroot环境控制台中获取容器 ID:crictl ps --name egress-router-cni-pod | awk '{print $1}'# crictl ps --name egress-router-cni-pod | awk '{print $1}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
CONTAINER bac9fae69ddb6
CONTAINER bac9fae69ddb6Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确定容器的进程 ID。在本例中,容器 ID 是
bac9fae69ddb6:crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'# crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
68857
68857Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入容器的网络命名空间:
nsenter -n -t 68857
# nsenter -n -t 68857Copy to Clipboard Copied! Toggle word wrap Toggle overflow 显示路由表:
ip route
# ip routeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在以下示例输出中,
net1网络接口是默认路由。集群网络的流量使用eth0网络接口。192.168.12.0/24网络的流量使用net1网络接口,并来自保留源 IP 地址192.168.12.99。pod 将所有其他流量路由到网关的 IP 地址192.168.12.1。不显示服务网络的路由。输出示例
default via 192.168.12.1 dev net1 10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18 192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99 192.168.12.1 dev net1
default via 192.168.12.1 dev net1 10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18 192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99 192.168.12.1 dev net1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.16. 为项目启用多播 复制链接链接已复制到粘贴板!
19.16.1. 关于多播 复制链接链接已复制到粘贴板!
通过使用 IP 多播,数据可同时广播到许多 IP 地址。
- 目前,多播最适用于低带宽协调或服务发现。它不是一个高带宽解决方案。
-
默认情况下,网络策略会影响命名空间中的所有连接。但是,多播不受网络策略的影响。如果在与网络策略相同的命名空间中启用了多播,则始终允许多播,即使有一个
deny-all网络策略。在启用网络策略前,集群管理员应考虑对多播的影响。
默认情况下,OpenShift Container Platform pod 之间多播流量被禁用。如果使用 OVN-Kubernetes 网络插件,可以根据每个项目启用多播。
19.16.2. 启用 pod 间多播 复制链接链接已复制到粘贴板!
您可以为项目启用 pod 间多播。
先决条件
-
安装 OpenShift CLI(
oc)。 -
您必须作为
cluster-admin角色用户登录集群。
流程
运行以下命令,为项目启用多播。使用您要启用多播的项目的名称替换
<namespace>。oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=true$ oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来添加注解:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要验证项目是否启用了多播,请完成以下步骤:
将您的当前项目更改为启用多播的项目。使用项目名替换
<project>。oc project <project>
$ oc project <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod 以作为多播接收器:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod 以作为多播发送器:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在新的终端窗口或选项卡中,启动多播监听程序。
获得 Pod 的 IP 地址:
POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')$ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令启动多播监听程序:
oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname$ oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostnameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
启动多播传输。
获取 pod 网络 IP 地址范围:
CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')$ CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要发送多播信息,请输入以下命令:
oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"$ oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果多播正在工作,则上一个命令会返回以下输出:
mlistener
mlistenerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.17. 为项目禁用多播 复制链接链接已复制到粘贴板!
19.17.1. 禁用 pod 间多播 复制链接链接已复制到粘贴板!
您可以为项目禁用 pod 间多播。
先决条件
-
安装 OpenShift CLI(
oc)。 -
您必须作为
cluster-admin角色用户登录集群。
流程
运行以下命令来禁用多播:
oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled-$ oc annotate namespace <namespace> \1 k8s.ovn.org/multicast-enabled-Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 您要禁用多播的项目的
namespace。
提示您还可以应用以下 YAML 来删除注解:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.18. 跟踪网络流 复制链接链接已复制到粘贴板!
作为集群管理员,您可以从集群中收集有关 pod 网络流的信息,以帮助以下区域:
- 监控 pod 网络上的入口和出口流量。
- 对性能问题进行故障排除。
- 为容量规划和安全审计收集数据。
当您启用网络流的集合时,只会收集与流量相关的元数据。例如,不会收集实际的数据包数据,而是只收集协议、源地址、目标地址、端口号、字节数和其他数据包级别的信息。
数据采用以下一种或多种记录格式收集:
- NetFlow
- sFlow
- IPFIX
当您使用一个或多个收集器 IP 地址和端口号配置 Cluster Network Operator(CNO)时,Operator 会在每个节点上配置 Open vSwitch(OVS),以将网络流记录发送到每个收集器。
您可以将 Operator 配置为将记录发送到多种类型的网络流收集器。例如,您可以将记录发送到 NetFlow 收集器,并将记录发送到 sFlow 收集器。
当 OVS 向收集器发送数据时,每种类型的收集器接收相同的记录。例如,如果您配置两个 NetFlow 收集器,节点上的 OVS 会将相同的记录发送到两个收集器。如果您还配置了两个 sFlow 收集器,则两个 sFlow 收集器将接收相同的记录。但是,每个收集器类型都具有唯一的记录格式。
收集网络流数据并将记录发送到收集器会影响性能。节点处理数据包的速度较慢。如果性能影响太大,您可以删除收集器的目的地,以禁用收集网络流数据并恢复性能。
启用网络流收集器可能会影响集群网络的整体性能。
19.18.1. 用于跟踪网络流的网络对象配置 复制链接链接已复制到粘贴板!
下表显示了在 Cluster Network Operator(CNO)中配置网络流收集器的字段:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNO 对象的名称。这个名称始终是 |
|
|
|
一个或多个 |
|
|
| 最多 10 个收集器的 IP 地址和网络端口对列表。 |
|
|
| 最多 10 个收集器的 IP 地址和网络端口对列表。 |
|
|
| 最多 10 个收集器的 IP 地址和网络端口对列表。 |
将以下清单应用到 CNO 后,Operator 会在集群中的每个节点上配置 Open vSwitch(OVS),将网络流记录发送到侦听 192.168.1.99:2056 的 NetFlow 收集器。
跟踪网络流的配置示例
19.18.2. 为网络流收集器添加目的地 复制链接链接已复制到粘贴板!
作为集群管理器,您可以将 Cluster Network Operator(CNO)配置为发送有关 pod 网络的网络流元数据到网络流收集器。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。 - 您有一个网络流收集器,知道它所侦听的 IP 地址和端口。
流程
创建补丁文件,用于指定网络流收集器类型以及收集器的 IP 地址和端口信息:
spec: exportNetworkFlows: netFlow: collectors: - 192.168.1.99:2056spec: exportNetworkFlows: netFlow: collectors: - 192.168.1.99:2056Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用网络流收集器配置 CNO:
oc patch network.operator cluster --type merge -p "$(cat <file_name>.yaml)"
$ oc patch network.operator cluster --type merge -p "$(cat <file_name>.yaml)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
通常情况不需要进行验证。您可以运行以下命令,确认每个节点上的 Open vSwitch(OVS)已配置为将网络流记录发送到一个或多个收集器。
查看 Operator 配置,确认配置了
exportNetworkFlows字段:oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"$ oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
{"netFlow":{"collectors":["192.168.1.99:2056"]}}{"netFlow":{"collectors":["192.168.1.99:2056"]}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 查看每个节点中的 OVS 网络流配置:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.18.3. 删除网络流收集器的所有目的地 复制链接链接已复制到粘贴板!
作为集群管理员,您可以配置 Cluster Network Operator(CNO)来停止将网络流元数据发送到网络流收集器。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
删除所有网络流收集器:
oc patch network.operator cluster --type='json' \ -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'$ oc patch network.operator cluster --type='json' \ -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.19. 配置混合联网 复制链接链接已复制到粘贴板!
作为集群管理员,您可以配置 Red Hat OpenShift Networking OVN-Kubernetes 网络插件,以允许 Linux 和 Windows 节点分别托管 Linux 和 Windows 工作负载。
19.19.1. 使用 OVN-Kubernetes 配置混合网络 复制链接链接已复制到粘贴板!
您可以将集群配置为使用 OVN-Kubernetes 网络插件的混合网络。这允许支持不同节点网络配置的混合集群。
此配置是在同一集群中同时运行 Linux 和 Windows 节点所必需的。
先决条件
-
安装 OpenShift CLI (
oc) 。 -
以具有
cluster-admin权限的用户身份登录集群。 - 确保集群使用 OVN-Kubernetes 网络插件。
流程
要配置 OVN-Kubernetes 混合网络覆盖,请输入以下命令:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
cidr- 指定用于额外覆盖网络上节点的 CIDR 配置。这个 CIDR 不能与集群网络 CIDR 重叠。
hostPrefix-
指定要分配给每个节点的子网前缀长度。例如,如果
hostPrefix 设为23,则每个节点从 givencidr中分配 a/23子网,这样就能有 510(2^(32 - 23)- 2)个 pod IP 地址。如果需要从外部网络访问节点,请配置负载均衡器和路由器来管理流量。 hybridOverlayVXLANPort-
为额外覆盖网络指定自定义 VXLAN 端口。这是在 vSphere 上安装的集群中运行 Windows 节点所需要的,且不得为任何其他云供应商配置。自定义端口可以是除默认
4789端口外的任何打开的端口。有关此要求的更多信息,请参阅 Microsoft 文档中的 Pod 到主机间的 pod 连接性。
注意Windows Server Long-Term Servicing Channel(LTSC):Windows Server 2019 在带有自定义
hybridOverlayVXLANPort值的集群中不被支持,因为这个 Windows server 版本不支持选择使用自定义的 VXLAN 端口。输出示例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要确认配置是活跃的,请输入以下命令。应用更新可能需要几分钟。
oc get network.operator.openshift.io -o jsonpath="{.items[0].spec.defaultNetwork.ovnKubernetesConfig}"$ oc get network.operator.openshift.io -o jsonpath="{.items[0].spec.defaultNetwork.ovnKubernetesConfig}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 20 章 OpenShift SDN 网络插件 复制链接链接已复制到粘贴板!
20.1. 关于 OpenShift SDN 网络插件 复制链接链接已复制到粘贴板!
OpenShift SDN 的一部分,OpenShift SDN 是一个网络插件,它使用软件定义型网络 (SDN) 方法来提供一个统一的集群网络,它允许 OpenShift Container Platform 集群间 pod 间的通信。此 pod 网络由 OpenShift SDN 建立和维护,它使用 Open vSwitch (OVS) 配置覆盖网络。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
20.1.1. OpenShift SDN 网络隔离模式 复制链接链接已复制到粘贴板!
OpenShift SDN 提供三种 SDN 模式来配置 pod 网络:
-
网络策略模式允许项目管理员使用
NetworkPolicy对象配置自己的隔离策略。Network policy 是 OpenShift Container Platform 4.16 的默认模式。 - 多租户模式为 Pod 和服务提供项目级别的隔离。来自不同项目的 Pod 不能与不同项目的 Pod 和服务互相发送或接收数据包。您可以针对项目禁用隔离,允许它将网络流量发送到整个集群中的所有 pod 和服务,并从那些 pod 和服务接收网络流量。
- 子网模式提供一个扁平 pod 网络,每个 pod 都可以与所有其他 pod 和服务通信。网络策略模式提供与子网模式相同的功能。
20.1.2. 支持的网络插件功能列表 复制链接链接已复制到粘贴板!
Red Hat OpenShift Networking 为网络插件(OpenShift SDN 和 OVN-Kubernetes)提供了两个选项,用于网络插件。下表总结了这两个网络插件的当前功能支持:
| 功能 | OpenShift SDN | OVN-Kubernetes |
|---|---|---|
| 出口 IP | 支持 | 支持 |
| 出口防火墙 | 支持 | 支持 [1] |
| 出口路由器 | 支持 | 支持 [2] |
| 混合网络 | 不支持 | 支持 |
| 集群内通信的 IPsec 加密 | 不支持 | 支持 |
| IPv4 单栈 | 支持 | 支持 |
| IPv6 单栈 | 不支持 | 支持 [3] |
| IPv4/IPv6 双栈 | 不支持 | 支持的 [4] |
| IPv6/IPv4 双栈 | 不支持 | 支持 [5] |
| Kubernetes 网络策略 | 支持 | 支持 |
| Kubernetes 网络策略日志 | 不支持 | 支持 |
| 硬件卸载 | 不支持 | 支持 |
| 多播 | 支持 | 支持 |
- 在 OpenShift SDN 中,出口防火墙也称为出口网络策略。这和网络策略出口不同。
- OVN-Kubernetes 的出口路由器仅支持重定向模式。
- 裸机平台上的 IPv6 单堆栈网络。
- 裸机、VMware vSphere 上的 IPv4/IPv6 双栈网络(仅限安装程序置备的基础架构安装)、IBM Power®、IBM Z® 和 RHOSP 平台。
- 裸机、VMware vSphere (仅限安装程序置备的基础架构安装)和 IBM Power® 平台上的 IPv6/IPv4 双栈网络。
20.2. 为项目配置出口 IP 复制链接链接已复制到粘贴板!
作为集群管理员,您可以配置 OpenShift SDN Container Network Interface (CNI) 网络插件,为项目分配一个或多个出口 IP 地址。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
20.2.1. 出口 IP 地址架构设计和实施 复制链接链接已复制到粘贴板!
OpenShift Container Platform 出口 IP 地址功能可确保来自一个或多个命名空间中的一个或多个 pod 的流量具有集群网络之外的服务具有一致的源 IP 地址。
例如,您可能有一个 pod 定期查询托管在集群外服务器上的数据库。要强制对服务器进行访问要求,将数据包过滤设备配置为只允许来自特定 IP 地址的流量。为确保您可以可靠地允许从该特定 pod 访问服务器,您可以为向服务器发出请求的 pod 配置特定的出口 IP 地址。
分配给命名空间的出口 IP 地址与用来向特定目的地发送流量的出口路由器不同。
在一些集群配置中,应用程序 Pod 和入口路由器 pod 在同一个节点上运行。如果您在这种情况下为应用程序项目配置出口 IP 地址,当您向应用程序项目发送请求时,不会使用 IP 地址。
出口 IP 地址作为额外 IP 地址在节点的主网络接口中使用,且必须与节点的主 IP 地址位于同一个子网中。不能为集群中的任何其他节点分配额外的 IP 地址。
不能在任何 Linux 网络配置文件中配置出口 IP 地址,比如 ifcfg-eth0。
20.2.1.1. 平台支持 复制链接链接已复制到粘贴板!
在以下平台上支持在主主机网络中运行的 Egress IP 地址功能:
| 平台 | 支持 |
|---|---|
| 裸机 | 是 |
| VMware vSphere | 是 |
| Red Hat OpenStack Platform(RHOSP) | 是 |
| Amazon Web Services (AWS) | 是 |
| Google Cloud | 是 |
| Microsoft Azure | 是 |
| IBM Z® 和 IBM® LinuxONE | 是 |
| IBM Z® and IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM | 是 |
| IBM Power® | 是 |
| Nutanix | 是 |
在以下平台上支持在二级主机网络上运行的 Egress IP 地址功能:
| 平台 | 支持 |
|---|---|
| 裸机 | 是 |
在 Amazon Web Services(AWS)上置备的集群中不支持使用 EgressIP 功能将出口 IP 地址分配给 control plane 节点。(BZ#2039656)。
20.2.1.2. 公共云平台注意事项 复制链接链接已复制到粘贴板!
通常,公共云提供商对出口 IP 施加一个限制。这意味着,对于公共云基础架构上置备的集群,每个节点都有可分配 IP 地址的限制。如下公式描述了每个节点的可分配 IP 地址或 IP 容量 上限:
IP capacity = public cloud default capacity - sum(current IP assignments)
IP capacity = public cloud default capacity - sum(current IP assignments)
虽然 Egress IP 功能管理每个节点的 IP 地址容量,但在部署中计划这个约束非常重要。例如,如果公共云提供商将 IP 地址容量限制为每个节点 10 个 IP 地址,并且您有 8 个节点,则可分配的 IP 地址总数仅为 80。为了获得更高的 IP 地址容量,您需要分配额外的节点。例如,如果您需要 150 个可分配的 IP 地址,则需要分配 7 个节点。
要确认公共云环境中任何节点的 IP 容量和子网,您可以输入 oc get node <node_name> -o yaml 命令。cloud.network.openshift.io/egress-ipconfig 注解包括节点的容量和子网信息。
注解值是一个带有单个对象的数组,其中包含为主网络接口提供以下信息的字段:
-
Interface: 指定 AWS 和 Azure 上的接口 ID 以及 Google Cloud 上的接口名称。 -
ifaddr:为一个或多个 IP 地址系列指定子网掩码。 -
capacity:指定节点的 IP 地址容量。在 AWS 上,IP 地址容量为每个 IP 地址系列提供。在 Azure 和 Google Cloud 上,IP 地址容量同时包含 IPv4 和 IPv6 地址。
为节点之间的流量自动附加和分离出口 IP 地址。这允许命名空间中许多 pod 的流量在集群外的位置上具有一致的源 IP 地址。这还支持 OpenShift SDN 和 OVN-Kubernetes,这是 OpenShift Container Platform 4.16 中 Red Hat OpenShift Networking 中的默认网络插件。
RHOSP 出口 IP 地址功能会创建一个名为 egressip-<IP address> 的 neutron 保留端口。使用与 OpenShift Container Platform 集群安装相同的 RHOSP 用户,您可以为此保留端口分配一个浮动 IP 地址,以便为出口流量具有可预测的 SNAT 地址。当 RHOSP 网络上的出口 IP 地址从一个节点移到另一个节点时,因为节点故障转移(例如,neutron 保留端口会被删除并重新创建)。这意味着浮动 IP 关联丢失,您需要手动将浮动 IP 地址重新分配给新的保留端口。
当 RHOSP 集群管理员为保留端口分配一个浮动 IP 时,OpenShift Container Platform 无法删除保留端口。CloudPrivateIPConfig 对象无法执行删除和移动操作,直到 RHOSP 集群管理员从保留端口取消分配浮动 IP。
以下示例演示了来自多个公共云提供商上节点的注解。注解被缩进以便于阅读。
AWS 上的 cloud.network.openshift.io/egress-ipconfig 注解示例
Google Cloud 上的 cloud.network.openshift.io/egress-ipconfig 注解示例
以下小节描述了支持公共云环境的 IP 地址容量,用于容量计算。
20.2.1.2.1. Amazon Web Services(AWS)IP 地址容量限制 复制链接链接已复制到粘贴板!
在 AWS 上,IP 地址分配的限制取决于配置的实例类型。如需更多信息,请参阅 每个实例类型的每个网络接口的 IP 地址
20.2.1.2.2. Google Cloud IP 地址容量限制 复制链接链接已复制到粘贴板!
在 Google Cloud 上,网络模型通过 IP 地址别名而不是 IP 地址分配来实施额外的节点 IP 地址。但是,IP 地址容量直接映射到 IP 别名容量。
IP 别名分配存在以下容量限制:
- 每个节点,IPv4 和 IPv6 的最大 IP 别名数为 100 个。
- 对于每个 VPC,IP 别名的最大数量没有被指定,但 OpenShift Container Platform 可扩展性测试显示最大为 15,000 个。
如需更多信息,请参阅 Per instance 配额和 Alias IP 范围概述。
20.2.1.2.3. Microsoft Azure IP 地址容量限制 复制链接链接已复制到粘贴板!
在 Azure 上,IP 地址分配有以下容量限制:
- 对于每个 NIC,对于 IPv4 和 IPv6,可分配 IP 地址的最大数量为 256。
- 对于每个虚拟网络,分配的 IP 地址的最大数量不能超过 65,536。
如需更多信息,请参阅网络限制。
20.2.1.3. 限制: 复制链接链接已复制到粘贴板!
在 OpenShift SDN 网络插件中使用出口 IP 地址时会有以下限制:
- 您不能在同一节点上同时使用手动分配和自动分配的出口 IP 地址。
- 如果手动从 IP 地址范围分配出口 IP 地址,则不得将该范围用于自动 IP 分配。
- 您不能使用 OpenShift SDN 出口 IP 地址在多个命名空间间共享出口 IP 地址。
如果您需要在命名空间间共享 IP 地址,则 OVN-Kubernetes 网络插件出口 IP 地址可以跨越多个命名空间中的 IP 地址。
如果您以多租户模式使用 OpenShift SDN,则无法将出口 IP 地址与与其关联的项目附加到另一个命名空间的任何命名空间一起使用。例如,如果 project1 和 project2 通过运行 oc adm pod-network join-projects --to=project1 project2 命令被连接,则这两个项目都不能使用出口 IP 地址。如需更多信息,请参阅 BZ#1645577。
20.2.1.4. IP 地址分配方法 复制链接链接已复制到粘贴板!
您可以通过设置 NetNamespace 对象的 egressIPs 参数,将出口 IP 地址分配给命名空间。在出口 IP 地址与项目关联后,OpenShift SDN 允许您以两种方式为主机分配出口 IP 地址:
- 在自动分配方法中,给节点分配一个出口 IP 地址范围。
- 在手动分配方法中,给节点分配包含一个或多个出口 IP 地址的列表。
请求出口 IP 地址的命名空间与可以托管那些出口 IP 地址的节点匹配,然后为那些节点分配出口 IP 地址。如果在 NetNamespace 对象中设置了 egressIPs 参数,但没有节点托管该出口 IP 地址,则会丢弃来自该命名空间的出口流量。
节点高可用性是自动的。如果托管出口 IP 地址的节点不可访问,并且有可以托管那些出口 IP 地址的节点,那么出口 IP 地址将会移到新节点。当无法访问的托管原始出口 IP 地址的节点恢复正常后,出口 IP 地址会自动转移,以在不同节点之间均衡出口 IP 地址。
20.2.1.4.1. 使用自动分配的出口 IP 地址时的注意事项 复制链接链接已复制到粘贴板!
当对出口 IP 地址使用自动分配方法时,请注意以下事项:
-
您可以设置每个节点的
HostSubnet资源的egressCIDRs参数,以指明节点可以托管的出口 IP 地址范围。OpenShift Container Platform 根据您指定的 IP 地址范围设置HostSubnet资源的egressIPs参数。
如果托管命名空间的出口 IP 地址的节点不可访问,OpenShift Container Platform 会将出口 IP 地址重新分配给具有兼容出口 IP 地址范围的另外一个节点。自动分配方法最适合在把额外的 IP 地址与节点进行关联时具有灵活性的环境中安装的集群。
20.2.1.4.2. 使用手动分配出口 IP 地址时的注意事项 复制链接链接已复制到粘贴板!
这种方法允许您控制哪些节点可以托管出口 IP 地址。
如果在公共云基础架构上安装了集群,则必须确保为每个节点分配出口 IP 地址,以便有足够的备用容量来托管 IP 地址。如需更多信息,请参阅上一节中的"平台注意事项"。
当手动分配出口 IP 地址时,请考虑以下事项:
-
您可以设置每个节点的
HostSubnet资源的egressIPs参数,以指明节点可以托管的 IP 地址。 - 支持一个命名空间带有多个出口 IP 地址。
如果命名空间有多个出口 IP 地址,且这些地址托管在多个节点上,则需要考虑以下额外的注意事项:
- 如果 pod 位于托管出口 IP 地址的节点上,则该 pod 始终使用该节点上的出口 IP 地址。
- 如果 pod 不在托管出口 IP 地址的节点上,则该 pod 会随机使用出口 IP 地址。
20.2.2. 为一个命名空间启用自动分配出口 IP 地址 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 中,可以为一个或多个节点上的特定命名空间启用自动分配出口 IP 地址。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
流程
使用以下 JSON,用出口 IP 地址更新
NetNamespace资源:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<project_name>- 指定项目的名称。
<ip_address>-
为
egressIPs数组指定一个或多个出口 IP 地址。
例如,将
project1分配给 IP 地址 192.168.1.100,将project2分配给 IP 地址 192.168.1.101:oc patch netnamespace project1 --type=merge -p \ '{"egressIPs": ["192.168.1.100"]}' oc patch netnamespace project2 --type=merge -p \ '{"egressIPs": ["192.168.1.101"]}'$ oc patch netnamespace project1 --type=merge -p \ '{"egressIPs": ["192.168.1.100"]}' $ oc patch netnamespace project2 --type=merge -p \ '{"egressIPs": ["192.168.1.101"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意由于 OpenShift SDN 管理
NetNamespace对象,因此只能通过修改现有的NetNamespace对象来进行更改。不要创建新的NetNamespace对象。使用以下 JSON 设置每一主机的
egressCIDRs参数,以指明哪些节点可以托管出口 IP 地址:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<node_name>- 指定节点名称。
<ip_address_range>-
指定 CIDR 格式的 IP 地址范围。您可以为
egressCIDRs阵列指定多个地址范围。
例如,将
node1和node2设置为托管范围为 192.168.1.0 到 192.168.1.255 的出口 IP 地址:oc patch hostsubnet node1 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}' oc patch hostsubnet node2 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}'$ oc patch hostsubnet node1 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}' $ oc patch hostsubnet node2 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform 会自动以均衡的方式将特定的出口 IP 地址分配给可用的节点。在本例中,它会将出口 IP 地址 192.168.1.100 分配给
node1,并将出口 IP 地址 192.168.1.101 分配给node2,或反之。
20.2.3. 为一个命名空间配置手动分配出口 IP 地址 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 中,您可以将一个或多个出口 IP 与一个项目关联。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
流程
通过使用所需 IP 地址指定以下 JSON 对象来更新
NetNamespace对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<project_name>- 指定项目的名称。
<ip_address>-
为
egressIPs数组指定一个或多个出口 IP 地址。
例如,将
project1项目分配给 IP 地址192.168.1.100和192.168.1.101:oc patch netnamespace project1 --type=merge \ -p '{"egressIPs": ["192.168.1.100","192.168.1.101"]}'$ oc patch netnamespace project1 --type=merge \ -p '{"egressIPs": ["192.168.1.100","192.168.1.101"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要提供高可用性,将
egressIPs值设置为不同节点上的两个或多个 IP 地址。如果设置了多个出口 IP 地址,则 pod 会大致同样使用所有出口 IP 地址。注意由于 OpenShift SDN 管理
NetNamespace对象,因此只能通过修改现有的NetNamespace对象来进行更改。不要创建新的NetNamespace对象。手动将出口 IP 地址分配给节点主机。
如果在公共云基础架构上安装了集群,则必须确认该节点具有可用的 IP 地址容量。
在节点主机上的
HostSubnet对象中设置egressIPs参数。使用以下 JSON,尽可能包含您要分配给该节点主机的 IP 地址:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<node_name>- 指定节点名称。
<ip_address>-
指定一个 IP 地址。您可以为
egressIPs数组指定多个 IP 地址。
例如,指定
node1应具有出口 IP192.168.1.100、192.168.1.101和192.168.1.102:oc patch hostsubnet node1 --type=merge -p \ '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'$ oc patch hostsubnet node1 --type=merge -p \ '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在上例中,
project1的所有出口流量都将路由到托管指定出口 IP 地址的节点,然后通过网络地址转换(NAT)连接到那个 IP 地址。
20.2.4. 其他资源 复制链接链接已复制到粘贴板!
- 如果要配置手动出口 IP 地址分配,请参阅平台考虑 与 IP 容量规划相关的信息。
20.3. 为项目配置出口防火墙 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为项目创建一个出口防火墙,用于限制离开 OpenShift Container Platform 集群的出口流量。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
20.3.1. EgressNetworkPolicy 自定义资源在项目中如何工作 复制链接链接已复制到粘贴板!
作为集群管理员,您可以使用一个出口防火墙来限制集群内的一些 pod 或所有 pod 可以访问的外部主机。您可以通过创建一个 EgressNetworkPolicy 自定义资源(CR)来配置出口防火墙策略。
出口防火墙适用于以下情况:
- pod 只能连接到内部主机,且无法开始连接到公共互联网。
- pod 只能连接到公共互联网,且无法启动到 OpenShift Container Platform 集群以外的内部主机的连接。
- pod 无法访问 OpenShift Container Platform 集群外的特定内部子网或主机。
- pod 只能连接到特定的外部主机。
例如,您可以允许某一个项目访问指定的 IP 范围,但拒绝其他项目对同一 IP 范围的访问。或者您可以限制应用程序开发人员从 Python pip 的镜像点进行更新,并强制要求更新只能来自于批准的源。
在 EgressNetworkPolicy CR 中,您可以匹配满足以下条件的网络流量:
- CIDR 格式的 IP 地址范围
- 解析为 IP 地址的 DNS 名称
20.3.1.1. EgressNetworkPolicy CR 的限制 复制链接链接已复制到粘贴板!
出口防火墙有以下限制:
-
项目不能有多个
EgressNetworkPolicyCR。允许使用多个EgressNetworkPolicyCR 创建,但不应该这样做。当您创建多个自定义资源时,您会收到以下信息:丢弃所有规则。实际上,所有外部流量都会被丢弃,这可能会给您的组织造成安全风险。 - 您必须将 OpenShift SDN 配置为使用网络策略或多租户模式来配置出口防火墙。如果您使用网络策略模式,则出口防火墙只与每个命名空间的一个策略兼容,且无法用于共享网络的项目,如全局项目。
-
每个项目最多可定义一个最多具有 1000 个规则的
EgressNetworkPolicyCR。 -
default项目无法使用出口防火墙。 当在多租户模式下使用 OpenShift SDN 网络插件时,会有以下限制:
-
全局项目无法使用出口防火墙。您可以使用
oc adm pod-network make-projects-global把一个项目设置为全局项目。 -
通过
oc adm pod-network join-projects命令合并的项目,无法在任何合并的项目中使用出口防火墙。
-
全局项目无法使用出口防火墙。您可以使用
-
如果您创建无选择器服务并手动定义指向外部 IP 的端点或
EndpointSlices,则到服务 IP 的流量可能仍然被允许,即使您的EgressNetworkPolicy配置为拒绝所有出口流量。这是因为 OpenShift SDN 不会对这些外部端点完全强制执行出口网络策略。因此,这可能会导致意外的访问外部服务。 - 出口防火墙不适用于主机网络命名空间。启用主机网络的 Pod 不受出口防火墙规则的影响。
- 出口防火墙规则不适用于通过路由器的网络流量。任何有权创建 Route CR 对象的用户,都可以通过创建指向禁止的目的地的路由来绕过出口防火墙策略规则。
违反这些限制会导致项目的出口防火墙出现问题。因此,所有外部网络流量都会丢弃,这可能会导致您的机构出现安全风险。
您可以在 kube-node-lease、kube-public、kube-system、openshift 和 openshift- 项目中创建一个 Egress Firewall 资源。
20.3.1.2. EgressNetworkPolicy CR 规则的匹配顺序 复制链接链接已复制到粘贴板!
OVN-Kubernetes 网络插件根据您定义规则的第一个到最后的顺序评估出口防火墙策略规则。第一个与 pod 的出口连接匹配的规则会被应用。该插件会忽略该连接的任何后续规则。
20.3.1.3. 域名服务器 (DNS) 解析如何工作 复制链接链接已复制到粘贴板!
如果您在 egress 防火墙策略规则中使用 DNS 名称,则正确解析域名会受到以下限制:
- 域名更新会根据生存时间(TTL)持续时间进行轮询。默认情况下,持续时间为 30 秒。当出口防火墙控制器查询本地名称服务器以获取域名时,如果响应中包含的 TTL 小于 30 秒,控制器会将持续时间设置为返回的值。如果响应中的 TTL 大于 30 分钟,控制器会将持续时间设置为 30 分钟。如果 TTL 介于 30 秒到 30 分钟之间,控制器会忽略该值,并将持续时间设置为 30 秒。
- 在需要时,pod 必须通过相同的本地名称服务器解析域名。否则,egress 防火墙控制器和 pod 已知的域的 IP 地址可能会有所不同。如果主机名的 IP 地址不同,则不会应用出口防火墙的一致性强制。
-
因为出口防火墙控制器和 pod 异步轮询相同的本地名称服务器,所以 pod 可能会在出口控制器执行前获取更新的 IP 地址,从而导致竞争条件。由于这个限制,仅建议在
EgressNetworkPolicyCR 中使用域名来更改 IP 地址的域。 在
EgressNetworkPolicyCR 中使用 DNS 名称不会影响通过 CoreDNS 进行本地 DNS 解析。但是,如果您的策略使用域名,并且外部 DNS 服务器处理受影响 pod 的 DNS 解析,则必须包含允许访问 DNS 服务器的 IP 地址的出口防火墙规则。
20.3.2. EgressNetworkPolicy 自定义资源(CR) 复制链接链接已复制到粘贴板!
您可以为出口防火墙定义一个或多个规则。规则是一个 Allow 规则,也可以是一个 Deny 规则,它包括规则适用的流量规格。
以下 YAML 描述了 EgressNetworkPolicy CR:
其中:
- <name>
- 指定出口防火墙策略的名称。
- <egress>
- 如下小节所述,指定一个或多个出口网络策略规则的集合。
20.3.2.1. EgressNetworkPolicy 规则 复制链接链接已复制到粘贴板!
用户可以选择 CIDR 格式的 IP 地址范围、域名,或使用 nodeSelector 允许或拒绝出口流量。egress 小节需要一个包括一个或多个对象的数组。以下 YAML 描述了一个出口防火墙规则对象。
其中:
- <type>
-
指定规则的类型。该值必须是
Allow或Deny。 - <to>
-
指定描述出口流量匹配规则的小节,该规则指定
cidrSelector字段或dnsName字段。您不能在同一规则中使用这两个字段。 - <cidr_range>
- 指定 CIDR 格式的 IP 地址范围。
- <dns_name>
- 指定 DNS 域名。
- <nodeSelector>
-
指定标签,它们是用户定义的键和值对。标签附加到对象,如 pod。
nodeSelector允许选择一个或多个节点标签,并附加到 pod。
20.3.2.2. EgressNetworkPolicy CR 对象示例 复制链接链接已复制到粘贴板!
以下示例定义了几个出口防火墙规则:
其中:
- <egress>
- 指定出口防火墙策略规则对象的集合。
20.3.3. 创建 EgressNetworkPolicy 自定义资源(CR) 复制链接链接已复制到粘贴板!
作为集群管理员,您可以为项目创建一个 EgressNetworkPolicy CR。
如果项目已经定义了 EgressNetworkPolicy 对象,您必须编辑现有的策略来更改出口防火墙规则。
先决条件
- 使用 OpenShift SDN 网络插件的集群。
-
安装 OpenShift CLI (
oc) 。 - 您需要使用集群管理员身份登陆到集群。
流程
创建策略规则:
-
创建一个
<policy_name>.yaml文件,其中<policy_name>描述出口策略规则。 -
在 文件中定义
EgressNetworkPolicy。
-
创建一个
运行以下命令来创建策略对象。将
<policy_name>替换为策略的名称,<project>替换为规则应用到的项目。oc create -f <policy_name>.yaml -n <project>
$ oc create -f <policy_name>.yaml -n <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 成功输出列出了
egressnetworkpolicy.network.openshift.io/v1名称以及创建的状态。-
可选:保存
<policy_name>.yaml文件,以便在以后进行修改。
20.4. 为项目编辑出口防火墙 复制链接链接已复制到粘贴板!
作为集群管理员,您可以修改现有出口防火墙的网络流量规则。
20.4.1. 查看 EgressNetworkPolicy 自定义资源(CR) 复制链接链接已复制到粘贴板!
您可以查看集群中的 EgressNetworkPolicy CR。
先决条件
- 使用 OpenShift SDN 网络插件的集群。
-
安装 OpenShift 命令行界面 (CLI),通常称为
oc。 - 您必须登录集群。
流程
可选: 要查看集群中定义的
EgressNetworkPolicyCR 的名称,请输入以下命令:oc get egressnetworkpolicy --all-namespaces
$ oc get egressnetworkpolicy --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要检查策略,请输入以下命令。将
<policy_name>替换为要检查的策略名称。oc describe egressnetworkpolicy <policy_name>
$ oc describe egressnetworkpolicy <policy_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
20.5. 为项目编辑出口防火墙 复制链接链接已复制到粘贴板!
作为集群管理员,您可以修改现有出口防火墙的网络流量规则。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
20.5.1. 编辑 EgressNetworkPolicy 自定义资源(CR) 复制链接链接已复制到粘贴板!
作为集群管理员,您可以更新一个项目的出口防火墙。
先决条件
- 使用 OpenShift SDN 网络插件的集群。
-
安装 OpenShift CLI (
oc) 。 - 您需要使用集群管理员身份登陆到集群。
流程
查找项目的
EgressNetworkPolicyCR 的名称。oc get -n <project> egressnetworkpolicy
$ oc get -n <project> egressnetworkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<project>替换为项目的名称。可选:如果您在创建出口防火墙时没有保存
EgressNetworkPolicyCR 的副本,请输入以下命令来创建副本。oc get -n <project> egressnetworkpolicy <name> -o yaml > <filename>.yaml
$ oc get -n <project> egressnetworkpolicy <name> -o yaml > <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<project>替换为项目的名称。将<name>替换为 Pod 的名称。将<filename>替换为要将 YAML 保存到的文件的名称。更改策略规则后,请输入以下命令替换
EgressNetworkPolicyCR。oc replace -f <filename>.yaml
$ oc replace -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<filename> 替换为包含更新的EgressNetworkPolicyCR 的文件名称。
20.6. 从项目中删除出口防火墙 复制链接链接已复制到粘贴板!
作为集群管理员,您可以从项目中删除出口防火墙,从而删除对项目的离开 OpenShift Container Platform 集群的网络流量的限制。
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
20.6.1. 删除 EgressNetworkPolicy 自定义资源(CR) 复制链接链接已复制到粘贴板!
作为集群管理员,您可以从项目中删除出口防火墙。
先决条件
- 使用 OpenShift SDN 网络插件的集群。
-
安装 OpenShift CLI (
oc) 。 - 您需要使用集群管理员身份登陆到集群。
流程
查找项目的
EgressNetworkPolicyCR 的名称。oc get -n <project> egressnetworkpolicy
$ oc get -n <project> egressnetworkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<project>替换为项目的名称。输入以下命令删除
EgressNetworkPolicyCR。oc delete -n <project> egressnetworkpolicy <name>
$ oc delete -n <project> egressnetworkpolicy <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<project>替换为项目名称,<name>替换为对象名称。
20.7. 使用出口路由器 pod 的注意事项 复制链接链接已复制到粘贴板!
20.7.1. 关于出口路由器 pod 复制链接链接已复制到粘贴板!
OpenShift Container Platform 出口路由器(egress router ) pod 使用一个来自专用的私有源 IP 地址,将网络流量重定向到指定的远程服务器。出口路由器 pod 可以将网络流量发送到设置为仅允许从特定 IP 地址访问的服务器。
出口路由器 pod 并不适用于所有外向的连接。创建大量出口路由器 pod 可能会超过您的网络硬件的限制。例如,为每个项目或应用程序创建出口路由器 pod 可能会导致,在转换为使用软件来进行 MAC 地址过滤前超过了网络接口可以处理的本地 MAC 地址的数量。
出口路由器镜像与 Amazon AWS、Azure Cloud 或其他不支持第 2 层操作的云平台不兼容,因为它们与 macvlan 流量不兼容。
20.7.1.1. 出口路由器模式 复制链接链接已复制到粘贴板!
在重定向模式中,出口路由器 Pod 配置 iptables 规则,将流量从其自身 IP 地址重定向到一个或多个目标 IP 地址。需要使用保留源 IP 地址的客户端 pod 必须配置为访问出口路由器的服务,而不是直接连接到目标 IP。您可以使用 curl 命令从应用程序 pod 访问目标服务和端口。例如:
curl <router_service_IP> <port>
$ curl <router_service_IP> <port>
在 HTTP 代理模式 中,出口路由器 pod 作为一个 HTTP 代理在端口 8080 上运行。这个模式只适用于连接到基于 HTTP 或基于 HTTPS 服务的客户端,但通常需要较少的更改就可以使客户端 pod 正常工作。很多程序可以通过设置环境变量来使用 HTTP 代理服务器。
在 DNS 代理模式 中,出口路由器 pod 作为基于 TCP 服务的 DNS 代理运行,将其自身的 IP 地址转换到一个或多个目标 IP 地址。要使用保留的源 IP 地址,客户端 pod 必须进行修改来连接到出口路由器 pod,而不是直接连接到目标 IP 地址。此修改确保了外部的目的地将流量视为来自一个已知源的流量。
重定向模式可用于除 HTTP 和 HTTPS 以外的所有服务。对于 HTTP 和 HTTPS 服务,请使用 HTTP 代理模式。对于使用 IP 地址或域名的基于 TCP 的服务,请使用 DNS 代理模式。
20.7.1.2. 出口路由器 pod 的实现 复制链接链接已复制到粘贴板!
出口路由器 pod 的设置由一个初始化容器执行。该容器在特权环境中运行,以便可以配置 macvlan 接口并设置 iptables 规则。在初始化容器完成设置 iptables 规则后会退出。接下来,出口路由器 pod 会执行容器来处理出口路由器流量。取决于出口路由器的模式,所使用的镜像会有所不同。
环境变量决定 egress-router 镜像使用的地址。镜像将 macvlan 接口配置为使用 EGRESS_SOURCE 作为其 IP 地址,并将 EGRESS_GATEWAY 作为网关的 IP 地址。
网络地址转换(NAT)规则被设置,使任何到 TCP 或 UDP 端口上的 pod 的集群 IP 地址的连接被重新指向由 EGRESS_DESTINATION 变量指定的 IP 地址的同一端口。
如果集群中只有部分节点能够声明指定的源 IP 地址并使用指定的网关,您可以指定一个 nodeName 或 nodeSelector 来表示哪些节点可以接受。
20.7.1.3. 部署注意事项 复制链接链接已复制到粘贴板!
出口路由器 pod 会为节点的主网络接口添加额外的 IP 地址和 MAC 地址。因此,您可能需要配置虚拟机监控程序或云供应商来允许额外的地址。
- Red Hat OpenStack Platform (RHOSP)
如果在 RHOSP 上部署 OpenShift Container Platform,则必须允许来自 OpenStack 环境上的出口路由器 Pod 的 IP 和 MAC 地址的流量。如果您不允许流量,则通信会失败:
openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
$ openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - VMware vSphere
- 如果您使用 VMware vSphere,请参阅 VMware 文档来保护 vSphere 标准交换机。通过从 vSphere Web 客户端中选择主机虚拟交换机来查看并更改 VMware vSphere 默认设置。
具体来说,请确保启用了以下功能:
20.7.1.4. 故障切换配置 复制链接链接已复制到粘贴板!
为了避免停机,可以使用 Deployment 资源部署出口路由器 pod,如下例所示。要为示例部署创建新 Service 对象,使用 oc expose deployment/egress-demo-controller 命令。
20.8. 以重定向模式部署出口路由器 pod 复制链接链接已复制到粘贴板!
作为集群管理员,您可以部署一个出口路由器 pod,该 pod 被配置为将流量重新定向到指定的目的地 IP 地址。
20.8.1. 重定向模式的出口路由器 pod 规格 复制链接链接已复制到粘贴板!
为 Pod 对象中的一个出口路由器 pod 定义其配置。以下 YAML 描述了以重定向模式配置出口路由器 pod 的字段:
- 1
- 该注解告知 OpenShift Container Platform 在主网络接口控制器(NIC)上创建 macvlan 网络接口,并将 macvlan 接口移到 pod 的网络命名空间。您必须把
"true"值包括在引号中。要让 OpenShift Container Platform 在不同的 NIC 接口上创建 macvlan 接口,请将注解值设置为该接口的名称。例如:eth1。 - 2
- 保留给出口路由器 pod 使用的物理网络的 IP 地址。可选:您可以包括子网长度(
/24后缀),以便正确路由到本地子网。如果没有指定子网长度,则出口路由器只能访问使用EGRESS_GATEWAY变量指定的主机,且子网上没有其他主机。 - 3
- 值与节点使用的默认网关相同。
- 4
- 将流量定向到的外部服务器。使用这个示例,连接到 pod 流量被重新定向到
203.0.113.25,源 IP 地址为192.168.12.99。
出口路由器 pod 规格示例
20.8.2. 出口目的地配置格式 复制链接链接已复制到粘贴板!
当出口路由器 pod 被部署为重定向模式时,您可以使用以下一种或多种格式指定重定向规则:
-
<port> <protocol> <ip_address>- 到给定<port>的内向连接应该被重新定向到给定<ip_address>上的同一端口。<protocol>可以是tcp或udp。 -
<port> <protocol> <ip_address> <remote_port>- 和以上一样,除了连接被重新定向到<ip_address>上的一个不同的<remote_port>中。 -
<ip_address>- 如果最后一行是一个 IP 地址,那么其它端口上的所有连接都会被重新指向那个 IP 地址的对应端口。如果没有故障切换 IP 地址,则其它端口上的连接将被拒绝。
在示例中定义了几个规则:
-
第一行将流量从本地端口
80重定向到203.0.113.25的端口80。 -
第二行和第三行将本地端口
8080和8443重定向到203.0.113.26的远程端口80和443。 - 最后一行与之前规则中没有指定的端口的流量匹配。
配置示例
80 tcp 203.0.113.25 8080 tcp 203.0.113.26 80 8443 tcp 203.0.113.26 443 203.0.113.27
80 tcp 203.0.113.25
8080 tcp 203.0.113.26 80
8443 tcp 203.0.113.26 443
203.0.113.27
20.8.3. 以重定向模式部署出口路由器 pod 复制链接链接已复制到粘贴板!
在重定向模式中,出口路由器 pod 会设置 iptables 规则将流量从其自身 IP 地址重定向到一个或多个目标 IP 地址。需要使用保留源 IP 地址的客户端 pod 必须配置为访问出口路由器的服务,而不是直接连接到目标 IP。您可以使用 curl 命令从应用程序 pod 访问目标服务和端口。例如:
curl <router_service_IP> <port>
$ curl <router_service_IP> <port>
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
- 创建出口路由器 pod。
为确保其他 pod 可以查找出口路由器 pod 的 IP 地址,请创建一个服务指向出口路由器 pod,如下例所示:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您的 pod 现在可以连接到此服务。使用保留的出口 IP 地址将其连接重新指向外部服务器的对应端口。
20.9. 以 HTTP 代理模式部署出口路由器 pod 复制链接链接已复制到粘贴板!
作为集群管理员,您可以将出口路由器 pod 配置为代理流量到指定的 HTTP 和基于 HTTPS 的服务。
20.9.1. HTTP 模式的出口路由器 pod 规格 复制链接链接已复制到粘贴板!
为 Pod 对象中的一个出口路由器 pod 定义其配置。以下 YAML 描述了以 HTTP 模式配置出口路由器 pod 的字段:
- 1
- 该注解告知 OpenShift Container Platform 在主网络接口控制器(NIC)上创建 macvlan 网络接口,并将 macvlan 接口移到 pod 的网络命名空间。您必须把
"true"值包括在引号中。要让 OpenShift Container Platform 在不同的 NIC 接口上创建 macvlan 接口,请将注解值设置为该接口的名称。例如:eth1。 - 2
- 保留给出口路由器 pod 使用的物理网络的 IP 地址。可选:您可以包括子网长度(
/24后缀),以便正确路由到本地子网。如果没有指定子网长度,则出口路由器只能访问使用EGRESS_GATEWAY变量指定的主机,且子网上没有其他主机。 - 3
- 值与节点使用的默认网关相同。
- 4
- 一个字符串或 YAML 多行字符串指定如何配置代理。请注意,这作为 HTTP 代理容器中的环境变量指定,而不是与 init 容器中的其他环境变量指定。
20.9.2. 出口目的地配置格式 复制链接链接已复制到粘贴板!
当出口路由器 pod 以 HTTP 代理模式部署时,您可以使用以下一个或多个格式指定重定向规则。配置中的每行都指定允许或者拒绝的连接组:
-
IP 地址允许连接到那个 IP 地址,如
192.168.1.1。 -
CIDR 范围允许连接到那个 CIDR 范围,如
192.168.1.0/24。 -
主机名允许代理该主机,如
www.example.com。 -
前面带有
*的域名允许代理到那个域及其所有子域,如*.example.com。 -
!再加上以前匹配的表达式会拒绝连接。 -
如果最后一行是
*,则任何没有被显式拒绝的都会被允许。否则,任何没有被允许的都会被拒绝。
您还可以使用 * 允许到所有远程目的地的连接。
配置示例
!*.example.com !192.168.1.0/24 192.168.2.1 *
!*.example.com
!192.168.1.0/24
192.168.2.1
*
20.9.3. 以 HTTP 代理模式部署出口路由器 pod 复制链接链接已复制到粘贴板!
在 HTTP 代理模式 中,出口路由器 pod 作为一个 HTTP 代理在端口 8080 上运行。这个模式只适用于连接到基于 HTTP 或基于 HTTPS 服务的客户端,但通常需要较少的更改就可以使客户端 pod 正常工作。很多程序可以通过设置环境变量来使用 HTTP 代理服务器。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
- 创建出口路由器 pod。
为确保其他 pod 可以查找出口路由器 pod 的 IP 地址,请创建一个服务指向出口路由器 pod,如下例所示:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 确定
http端口被设置为8080。
要将客户端 pod(不是出口代理 Pod)配置为使用 HTTP 代理,设置
http_proxy或https_proxy变量:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 上一步中创建的服务。
注意不需要在所有设置中都使用
http_proxy和https_proxy环境变量。如果以上内容没有创建可以正常工作设置,请查阅 pod 中运行的工具或软件的文档。
20.10. 以 DNS 代理模式部署出口路由器 pod 复制链接链接已复制到粘贴板!
作为集群管理员,您可以将配置为代理流量的出口路由器 pod 部署到指定的 DNS 名称和 IP 地址。
20.10.1. DNS 模式的出口路由器 pod 规格 复制链接链接已复制到粘贴板!
为 Pod 对象中的一个出口路由器 pod 定义其配置。以下 YAML 描述了在 DNS 模式中配置出口路由器 pod 的字段:
- 1
- 该注解告知 OpenShift Container Platform 在主网络接口控制器(NIC)上创建 macvlan 网络接口,并将 macvlan 接口移到 pod 的网络命名空间。您必须把
"true"值包括在引号中。要让 OpenShift Container Platform 在不同的 NIC 接口上创建 macvlan 接口,请将注解值设置为该接口的名称。例如:eth1。 - 2
- 保留给出口路由器 pod 使用的物理网络的 IP 地址。可选:您可以包括子网长度(
/24后缀),以便正确路由到本地子网。如果没有指定子网长度,则出口路由器只能访问使用EGRESS_GATEWAY变量指定的主机,且子网上没有其他主机。 - 3
- 值与节点使用的默认网关相同。
- 4
- 指定一个或多个代理目的地列表。
- 5
- 可选:指定输出 DNS 代理日志输出到
stdout。
20.10.2. 出口目的地配置格式 复制链接链接已复制到粘贴板!
当路由器以 DNS 代理模式部署时,您会指定一个端口和目标映射列表。目的地可以是 IP 地址,也可以是 DNS 名称。
出口路由器 pod 支持以下格式来指定端口和目的地映射:
- 端口和远程地址
-
您可以使用两个字段格式来指定源端口和目标主机:
<port> <remote_address>。
主机可以是 IP 地址或 DNS 名称。如果提供了 DNS 名称,DNS 解析会在运行时进行。对于给定主机,代理在连接到目标主机的 IP 地址时连接到目标主机上指定的源端口。
端口和远程地址对示例
80 172.16.12.11 100 example.com
80 172.16.12.11
100 example.com
- 端口、远程地址和远程端口
-
您可以使用三字段格式
<port> <remote_address> <remote_port>指定源端口、目标主机和目的地端口。
三字段格式的行为与两字段版本相同,但目的地端口可能与源端口不同。
端口、远程地址和远程端口示例
8080 192.168.60.252 80 8443 web.example.com 443
8080 192.168.60.252 80
8443 web.example.com 443
20.10.3. 以 DNS 代理模式部署出口路由器 pod 复制链接链接已复制到粘贴板!
在 DNS 代理模式 中,出口路由器 pod 作为基于 TCP 服务的 DNS 代理运行,将其自身的 IP 地址转换到一个或多个目标 IP 地址。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
- 创建出口路由器 pod。
为出口路由器 pod 创建服务:
创建名为
egress-router-service.yaml的文件,其包含以下 YAML。将spec.ports设置为您之前为EGRESS_DNS_PROXY_DESTINATION环境变量定义的端口列表。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要创建服务,请输入以下命令:
oc create -f egress-router-service.yaml
$ oc create -f egress-router-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod 现在可以连接至此服务。使用保留的出口 IP 地址将其代理到外部服务器的对应端口。
20.11. 从配置映射配置出口路由器 pod 目的地列表 复制链接链接已复制到粘贴板!
作为集群管理员,您可以定义一个 ConfigMap 对象来指定出口路由器 pod 的目标映射。配置的特定格式取决于出口路由器 pod 的类型。有关格式的详情,请参阅特定出口路由器 pod 的文档。
20.11.1. 使用配置映射配置出口路由器目的地映射 复制链接链接已复制到粘贴板!
对于大量或经常更换的目标映射集合,您可以使用配置映射来外部维护列表。这种方法的优点是可将编辑配置映射的权限委派给没有 cluster-admin 特权的用户。因为出口路由器 pod 需要特权容器,没有 cluster-admin 特权的用户无法直接编辑 pod 定义。
配置映射更改时,出口路由器 pod 不会自动更新。您必须重启出口路由器 pod 来获得更新。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建包含出口路由器 pod 映射数据的文件,如下例所示:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以在这个文件中放入空白行和评论。
从文件创建
ConfigMap对象:oc delete configmap egress-routes --ignore-not-found
$ oc delete configmap egress-routes --ignore-not-foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc create configmap egress-routes \ --from-file=destination=my-egress-destination.txt
$ oc create configmap egress-routes \ --from-file=destination=my-egress-destination.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在以前的版本中,
egress-routes值是要创建的ConfigMap对象的名称,my-egress-destination.txt是数据从中读取的文件的名称。提示您还可以应用以下 YAML 来创建配置映射:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建出口路由器 pod 定义,并为环境片段中的
EGRESS_DESTINATION字段指定configMapKeyRef小节:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
20.12. 为项目启用多播 复制链接链接已复制到粘贴板!
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
20.12.1. 关于多播 复制链接链接已复制到粘贴板!
通过使用 IP 多播,数据可同时广播到许多 IP 地址。
- 目前,多播最适用于低带宽协调或服务发现。它不是一个高带宽解决方案。
-
默认情况下,网络策略会影响命名空间中的所有连接。但是,多播不受网络策略的影响。如果在与网络策略相同的命名空间中启用了多播,则始终允许多播,即使有一个
deny-all网络策略。在启用网络策略前,集群管理员应考虑对多播的影响。
默认情况下,OpenShift Container Platform pod 之间多播流量被禁用。如果使用 OpenShift SDN 网络插件,可以根据每个项目启用多播。
在 networkpolicy 隔离模式中使用 OpenShift SDN 网络插件:
-
pod 发送的多播数据包将传送到项目中的所有其他 pod,而无需考虑
NetworkPolicy对象。即使在无法通过单播通信时,Pod 也能通过多播进行通信。 -
一个项目中的 pod 发送的多播数据包不会传送到任何其他项目中的 pod,即使存在允许项目间通信的
NetworkPolicy对象。
以 multitenant 隔离模式使用 OpenShift SDN 网络插件时:
- pod 发送的多播数据包将传送到项目中的所有其他 pod。
- 只有在各个项目接合在一起并且每个接合的项目上都启用了多播时,一个项目中的 pod 发送的多播数据包才会传送到其他项目中的 pod。
20.12.2. 启用 pod 间多播 复制链接链接已复制到粘贴板!
您可以为项目启用 pod 间多播。
先决条件
-
安装 OpenShift CLI(
oc)。 -
您必须作为
cluster-admin角色用户登录集群。
流程
运行以下命令,为项目启用多播。使用您要启用多播的项目的名称替换
<namespace>。oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled=true$ oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要验证项目是否启用了多播,请完成以下步骤:
将您的当前项目更改为启用多播的项目。使用项目名替换
<project>。oc project <project>
$ oc project <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod 以作为多播接收器:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod 以作为多播发送器:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在新的终端窗口或选项卡中,启动多播监听程序。
获得 Pod 的 IP 地址:
POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')$ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令启动多播监听程序:
oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname$ oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostnameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
启动多播传输。
获取 pod 网络 IP 地址范围:
CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')$ CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要发送多播信息,请输入以下命令:
oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"$ oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果多播正在工作,则上一个命令会返回以下输出:
mlistener
mlistenerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
20.13. 为项目禁用多播 复制链接链接已复制到粘贴板!
20.13.1. 禁用 pod 间多播 复制链接链接已复制到粘贴板!
您可以为项目禁用 pod 间多播。
先决条件
-
安装 OpenShift CLI(
oc)。 -
您必须作为
cluster-admin角色用户登录集群。
流程
运行以下命令来禁用多播:
oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled-$ oc annotate netnamespace <namespace> \1 netnamespace.network.openshift.io/multicast-enabled-Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 您要禁用多播的项目的
namespace。
20.14. 使用 OpenShift SDN 配置网络隔离 复制链接链接已复制到粘贴板!
从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。如需更多信息,请参阅 OpenShift SDN CNI 删除。
当集群配置为使用 OpenShift SDN 网络插件的多租户隔离模式时,每个项目会被默认隔离。在多租户隔离模式下,不同项目中的 pod 或服务间不允许网络流量。
您可以通过两种方式更改项目的多租户隔离行为:
- 您可以接合一个或多个项目,允许不同项目中的 pod 和服务间的网络流量。
- 您可以对项目禁用网络隔离。它可全局访问,接受所有其他项目中的 pod 和服务的网络流量。可全局访问的项目可以访问所有其他项目中的 pod 和服务。
20.14.1. 先决条件 复制链接链接已复制到粘贴板!
- 您必须将集群配置为在多租户隔离模式中使用 OpenShift SDN 网络插件。
20.14.2. 接合项目 复制链接链接已复制到粘贴板!
您可以接合两个或多个项目,以允许不同项目中的 Pod 和服务间的网络流量。
先决条件
-
安装 OpenShift CLI(
oc)。 -
您必须作为
cluster-admin角色用户登录集群。
流程
使用以下命令,将项目接合到现有项目网络中:
oc adm pod-network join-projects --to=<project1> <project2> <project3>
$ oc adm pod-network join-projects --to=<project1> <project2> <project3>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 另外,除了指定具体的项目名称,也可以使用
--selector=<project_selector>选项来基于关联标签指定项目。可选:运行以下命令来查看您接合在一起的 Pod 网络:
oc get netnamespaces
$ oc get netnamespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 NETID 列中,同一 Pod 网络中的项目具有相同的网络 ID。
20.14.3. 隔离项目 复制链接链接已复制到粘贴板!
您可以隔离项目,使其他项目中的 pod 和服务无法访问这个项目中的 pod 和服务。
先决条件
-
安装 OpenShift CLI(
oc)。 -
您必须作为
cluster-admin角色用户登录集群。
流程
要隔离集群中的项目,请运行以下命令:
oc adm pod-network isolate-projects <project1> <project2>
$ oc adm pod-network isolate-projects <project1> <project2>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 另外,除了指定具体的项目名称,也可以使用
--selector=<project_selector>选项来基于关联标签指定项目。
20.14.4. 对项目禁用网络隔离 复制链接链接已复制到粘贴板!
您可以对项目禁用网络隔离。
先决条件
-
安装 OpenShift CLI(
oc)。 -
您必须作为
cluster-admin角色用户登录集群。
流程
对项目运行以下命令:
oc adm pod-network make-projects-global <project1> <project2>
$ oc adm pod-network make-projects-global <project1> <project2>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 另外,除了指定具体的项目名称,也可以使用
--selector=<project_selector>选项来基于关联标签指定项目。
20.15. 配置 kube-proxy 复制链接链接已复制到粘贴板!
Kubernetes 网络代理 (kube-proxy) 在每个节点上运行,并由 Cluster Network Operator (CNO) 管理。kube-proxy 维护网络规则,以转发与服务关联的端点的连接。
20.15.1. 关于 iptables 规则同步 复制链接链接已复制到粘贴板!
同步周期决定 Kubernetes 网络代理 (kube-proxy) 在节点上同步 iptables 规则的频率。
同步在发生以下事件之一时开始:
- 发生某一事件,例如服务或端点添加到集群中或从集群中删除。
- 距最后一次同步的时间已超过为 kube-proxy 定义的同步周期。
20.15.2. kube-proxy 配置参数 复制链接链接已复制到粘贴板!
您可以修改以下 kubeProxyConfig 参数。
由于 OpenShift Container Platform 4.3 及更高版本中引进了性能上的改进,现在不再需要调整 iptablesSyncPeriod 参数。
20.15.3. 修改 kube-proxy 配置 复制链接链接已复制到粘贴板!
您可以为集群修改 Kubernetes 网络代理配置。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用
cluster-admin角色登录正在运行的集群。
流程
运行以下命令来编辑
Network.operator.openshift.io自定义资源(CR):oc edit network.operator.openshift.io cluster
$ oc edit network.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 利用您对 kube-proxy 配置的更改修改 CR 中的
kubeProxyConfig参数,如以下示例 CR 中所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 保存文件并退出文本编辑器。
保存文件并退出编辑器时,
oc命令会验证其语法。如果您的修改含有语法错误,编辑器会打开该文件并显示错误消息。运行以下命令来确认配置更新:
oc get networks.operator.openshift.io -o yaml
$ oc get networks.operator.openshift.io -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:运行以下命令,确认 Cluster Network Operator 已接受配置更改:
oc get clusteroperator network
$ oc get clusteroperator networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.1.0-0.9 True False False 1m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.1.0-0.9 True False False 1mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功应用配置更新后,
AVAILABLE字段为True。
第 21 章 配置路由 复制链接链接已复制到粘贴板!
21.1. 路由配置 复制链接链接已复制到粘贴板!
21.1.1. 创建基于 HTTP 的路由 复制链接链接已复制到粘贴板!
路由允许您在公共 URL 托管应用程序。根据应用程序的网络安全配置,它可以安全或不受保护。基于 HTTP 的路由是一个不受保护的路由,它使用基本的 HTTP 路由协议,并在未安全的应用程序端口上公开服务。
以下流程描述了如何使用 hello-openshift 应用程序创建基于 HTTP 的简单路由,作为示例。
前提条件
-
已安装 OpenShift CLI(
oc)。 - 以管理员身份登录。
- 您有一个 web 应用,用于公开端口和侦听端口上流量的 TCP 端点。
流程
运行以下命令,创建一个名为
hello-openshift的项目:oc new-project hello-openshift
$ oc new-project hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,在项目中创建 pod:
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,创建名为
hello-openshift的服务:oc expose pod/hello-openshift
$ oc expose pod/hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,创建一个没有安全安全的路由到
hello-openshift应用程序:oc expose svc hello-openshift
$ oc expose svc hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要验证您创建的
路由资源,请运行以下命令:oc get routes -o yaml <name of resource>
$ oc get routes -o yaml <name of resource>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 在本例中,路由名为
hello-openshift。
创建的未安全路由的 YAML 定义示例
- 1
host字段是指向该服务的别名 DNS 记录。此字段可以是任何有效的 DNS 名称,如www.example.com。DNS 名称必须遵循 DNS952 子域惯例。如果没有指定,则会自动生成路由名称。- 2
targetPort字段是由此路由指向的服务选择的 pod 上的目标端口。注意要显示您的默认入口域,请运行以下命令:
oc get ingresses.config/cluster -o jsonpath={.spec.domain}$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.2. 为 Ingress Controller 分片创建路由 复制链接链接已复制到粘贴板!
通过使用路由,您可以通过 URL 托管应用程序。Ingress Controller 分片有助于在一组 Ingress Controller 之间平衡传入的流量负载。它还可以将流量隔离到特定的 Ingress Controller。例如,A 公司的流量使用一个 Ingress Controller,B 公司的流量则使用另外一个 Ingress Controller。
以下流程描述了如何为 Ingress Controller 分片创建路由,使用 hello-openshift 应用程序作为示例。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 您以项目管理员身份登录。
- 您有一个 web 应用来公开端口,以及侦听端口流量的 HTTP 或 TLS 端点。
- 您已为分片配置了 Ingress Controller。
流程
运行以下命令,创建一个名为
hello-openshift的项目:oc new-project hello-openshift
$ oc new-project hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,在项目中创建 pod:
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,创建名为
hello-openshift的服务:oc expose pod/hello-openshift
$ oc expose pod/hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建名为
hello-openshift-route.yaml的路由定义:为分片创建的路由的 YAML 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过运行以下命令,使用
hello-openshift-route.yaml创建到hello-openshift应用程序的路由:oc -n hello-openshift create -f hello-openshift-route.yaml
$ oc -n hello-openshift create -f hello-openshift-route.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
使用以下命令获取路由的状态:
oc -n hello-openshift get routes/hello-openshift-edge -o yaml
$ oc -n hello-openshift get routes/hello-openshift-edge -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 生成的
Route资源应类似以下示例:输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress Controller 或路由器的主机名用于公开路由。
host字段的值由 Ingress Controller 自动决定,并使用它的域。在本例中,Ingress Controller 的域为<apps-sharded.basedomain.example.net>。 - 2
- Ingress Controller 的主机名。如果没有设置主机名,则路由可以使用子域。当您指定子域时,会自动使用公开路由的 Ingress Controller 域。当路由由多个 Ingress Controller 公开时,路由由多个 URL 托管。
- 3
- Ingress Controller 的名称。在本例中,Ingress Controller 的名称为
sharded。
21.1.3. 配置路由超时 复制链接链接已复制到粘贴板!
如果您的服务需要低超时(满足服务级别可用性 (SLA) 目的)或高超时(具有慢速后端的情况),您可以为现有路由配置默认超时。
如果您在 OpenShift Container Platform 集群前面配置了用户管理的外部负载均衡器,请确保用户管理的外部负载均衡器的超时值高于路由的超时值。此配置可防止集群使用的网络的网络出现网络拥塞问题。
先决条件
- 您需要在运行的集群中部署了 Ingress Controller。
流程
使用
oc annotate命令,为路由添加超时:oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>$ oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 支持的时间单位是微秒 (us)、毫秒 (ms)、秒钟 (s)、分钟 (m)、小时 (h)、或天 (d)。
以下示例在名为
myroute的路由上设置两秒的超时:oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.4. HTTP 严格传输安全性 复制链接链接已复制到粘贴板!
HTTP 严格传输安全性 (HSTS) 策略是一种安全增强,向浏览器客户端发送信号,表示路由主机上仅允许 HTTPS 流量。HSTS 也通过信号 HTTPS 传输来优化 Web 流量,无需使用 HTTP 重定向。HSTS 对于加快与网站的交互非常有用。
强制 HSTS 策略时,HSTS 会向站点的 HTTP 和 HTTPS 响应添加 Strict Transport Security 标头。您可以在路由中使用 insecureEdgeTerminationPolicy 值,以将 HTTP 重定向到 HTTPS。强制 HSTS 时,客户端会在发送请求前将所有请求从 HTTP URL 更改为 HTTPS,无需重定向。
集群管理员可将 HSTS 配置为执行以下操作:
- 根据每个路由启用 HSTS
- 根据每个路由禁用 HSTS
- 对一组域强制每个域的 HSTS,或者结合使用命名空间标签与域
HSTS 仅适用于安全路由,可以是 edge-terminated 或 re-encrypt。其配置在 HTTP 或传递路由上无效。
21.1.4.1. 根据每个路由启用 HTTP 严格传输安全性 复制链接链接已复制到粘贴板!
HTTP 严格传输安全 (HSTS) 实施在 HAProxy 模板中,并应用到具有 haproxy.router.openshift.io/hsts_header 注解的边缘和重新加密路由。
前提条件
- 您可以使用具有项目的管理员特权的用户登陆到集群。
-
已安装 OpenShift CLI(
oc)。
流程
要在路由上启用 HSTS,请将
haproxy.router.openshift.io/hsts_header值添加到 edge-terminated 或 re-encrypt 路由中。您可以运行以下命令来使用oc annotate工具来实现此目的:oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ includeSubDomains;preload"
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\1 includeSubDomains;preload"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 在本例中,最长期限设置为
31536000ms,大约为 8.5 小时。
注意在这个示例中,等号 (
=) 包括在引号里。这是正确执行注解命令所必需的。配置了注解的路由示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必需。
Max-age测量 HSTS 策略生效的时间长度,以秒为单位。如果设置为0,它将对策略进行求反。 - 2
- 可选。包含时,
includeSubDomains告知客户端主机的所有子域都必须与主机具有相同的 HSTS 策略。 - 3
- 可选。当
max-age大于 0 时,您可以在haproxy.router.openshift.io/hsts_header中添加preload,以允许外部服务将这个站点包括在 HSTS 预加载列表中。例如,Google 等站点可以构造设有preload的站点的列表。浏览器可以使用这些列表来确定哪些站点可以通过 HTTPS 通信,即使它们与站点交互之前也是如此。如果没有设置preload,浏览器必须已经通过 HTTPS 与站点交互(至少一次)才能获取标头。
21.1.4.2. 根据每个路由禁用 HTTP 严格传输安全性 复制链接链接已复制到粘贴板!
要禁用 HTTP 严格传输安全性 (HSTS),您可以将路由注解中的 max-age 值设置为 0。
前提条件
- 您可以使用具有项目的管理员特权的用户登陆到集群。
-
已安装 OpenShift CLI(
oc)。
流程
要禁用 HSTS,请输入以下命令将路由注解中的
max-age值设置为0:oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来创建配置映射:
根据每个路由禁用 HSTS 的示例
metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=0metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要为命名空间中的所有路由禁用 HSTS,请输入以下命令:
oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
$ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要查询所有路由的注解,请输入以下命令:
oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'$ oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Name: routename HSTS: max-age=0
Name: routename HSTS: max-age=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.4.3. 强制每个域 HTTP 严格传输安全性 复制链接链接已复制到粘贴板!
要为安全路由强制实施 HTTP Strict Transport Security (HSTS),在 Ingress spec 中添加 requiredHSTSPolicies 记录来捕获 HSTS 策略的配置。
如果您将 requiredHSTSPolicy 配置为强制 HSTS,则任何新创建的路由都必须配置有兼容的 HSTS 策略注解。
要使用不合规的 HSTS 路由处理升级的集群,您可以在源更新清单并应用更新。
您无法使用 oc expose route 或 oc create route 命令在强制 HSTS 的域中添加路由,因为这些命令的 API 不接受注解。
HSTS 无法应用到不安全或非 TLS 路由,即使 HSTS 全局请求了 HSTS。
先决条件
- 您可以使用具有项目的管理员特权的用户登陆到集群。
-
已安装 OpenShift CLI(
oc)。
流程
运行以下命令来编辑 Ingress 配置 YAML,并根据需要更新字段:
oc edit ingresses.config.openshift.io/cluster
$ oc edit ingresses.config.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow HSTS 策略示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必需。
requiredHSTSPolicies会被按顺序验证,并应用第一个匹配的domainPatterns。 - 2
- 必需。您必须至少指定一个
domainPatterns主机名。可以列出任意数量的域。您可以为不同的domainPatterns包括多个强制选项部分。 - 3
- 可选。如果包含
namespaceSelector,它必须与路由所在项目的标签匹配,以便在路由上强制执行设定 HSTS 策略。仅与namespaceSelector而不是domainPatterns匹配的路由不会被验证。 - 4
- 必需。
Max-age测量 HSTS 策略生效的时间长度,以秒为单位。此策略设置允许强制实施最小和最大的max-age。-
largestMaxAge值必须在0到2147483647之间。它可以不指定,这意味着不强制实施上限。 -
smallestMaxAge值必须在0到2147483647之间。输入0来禁用 HSTS 以进行故障排除,或者如果您不需要禁用 HSTS,输入1。它可以不知道,这意味着不强制实施较低限制。
-
- 5
- 可选。在
haproxy.router.openshift.io/hsts_header中包含preload会使外部服务将此站点包括在 HSTS 预加载列表中。浏览器可以使用这些列表来决定哪些站点可通过 HTTPS 进行通信,然后再与站点交互。如果没有设置preload,浏览器需要至少与站点交互一次,才能获取该标头。可使用以下方法之一设置preload:-
RequirePreload:RequiredHSTSPolicy需要preload。 -
RequireNoPreload:preload被RequiredHSTSPolicy禁止。 -
NoOpinion:preload与RequiredHSTSPolicy没有关系。
-
- 6
- 可选。
includeSubDomainsPolicy可使用以下之一设置:-
RequireIncludeSubDomains:RequiredHSTSPolicy需要includeSubDomains。 -
RequireNoIncludeSubDomains:includeSubDomains被RequiredHSTSPolicy禁止。 -
NoOpinion:includeSubDomains与RequiredHSTSPolicy没有关系。
-
您可以通过输入
oc annotate command,将 HSTS 应用到集群或特定命名空间中的所有路由。要将 HSTS 应用到集群中的所有路由,请输入
oc annotate command。例如:oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
$ oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要将 HSTS 应用到特定命名空间中的所有路由,请输入
oc annotate command。例如:oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
$ oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
您可以查看您配置的 HSTS 策略。例如:
要查看所需的 HSTS 策略的
maxAge设置,请输入以下命令:oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'$ oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要查看所有路由上的 HSTS 注解,请输入以下命令:
oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'$ oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomainsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.5. 吞吐量问题的故障排除方法 复制链接链接已复制到粘贴板!
有时,通过 OpenShift Container Platform 部署的应用程序可能会导致网络吞吐量问题,如特定服务间的延迟异常高。
如果 pod 日志没有显示造成问题的原因,请使用以下方法之一分析性能问题:
使用
ping或tcpdump等数据包分析器,分析 pod 与其节点之间的流量。例如,在每个 pod 上运行
tcpdump工具,同时重现导致问题的行为。检查两端的捕获信息,以便比较发送和接收时间戳来分析与 pod 往来的流量的延迟。如果节点接口被其他 pod、存储设备或者数据平面的流量过载,则 OpenShift Container Platform 中可能会出现延迟。tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>
$ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
podip是 pod 的 IP 地址。运行oc get pod <pod_name> -o wide命令来获取 pod 的 IP 地址。
tcpdump命令会在/tmp/dump.pcap中生成一个包含这两个 pod 间所有流量的文件。您可以在运行分析器后立即重现问题,并在问题重现完成后马上停止分析器,从而尽量减小文件的大小。您还可以通过以下命令,在节点之间运行数据包分析器(从考量范围中剔除 SDN):tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
$ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
iperf等带宽测量工具来测量流吞吐量和 UDP 吞吐量。首先从 pod 运行该工具,然后从节点运行它,从而找到瓶颈。-
有关安装和使用
iperf的详情,请参考此红帽解决方案。
-
有关安装和使用
- 在某些情况下,因为延迟问题,集群可能会将带有路由器 pod 的节点标记为不健康。在执行操作前,使用 worker 延迟配置集调整集群等待节点状态更新的频率。
-
如果您的集群指定了较低延迟和较高延迟节点,请将 Ingress Controller 中的
spec.nodePlacement字段配置为控制路由器 pod 的放置。
21.1.6. 使用 Cookie 来保持路由有状态性 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供粘性会话,通过确保所有流量都到达同一端点来实现有状态应用程序流量。但是,如果端点 pod 以重启、扩展或更改配置的方式被终止,这种有状态性可能会消失。
OpenShift Container Platform 可以使用 Cookie 来配置会话持久性。ingress 控制器选择一个端点来处理任何用户请求,并为会话创建一个 Cookie。Cookie 在响应请求时返回,用户则通过会话中的下一请求发回 Cookie。Cookie 告知 Ingress Controller 哪个端点正在处理会话,确保客户端请求使用这个 Cookie 使请求路由到同一个 pod。
无法在 passthrough 路由上设置 Cookie,因为无法看到 HTTP 流量。相反,根据源 IP 地址计算数字,该地址决定了后端。
如果后端更改,可以将流量定向到错误的服务器,使其更不计。如果您使用负载均衡器来隐藏源 IP,则会为所有连接和流量都发送到同一 pod 设置相同的数字。
21.1.6.1. 使用 Cookie 标注路由 复制链接链接已复制到粘贴板!
您可以设置 Cookie 名称来覆盖为路由自动生成的默认名称。这样,接收路由流量的应用程序就能知道 Cookie 名称。通过删除 Cookie,它可以强制下一请求重新选择端点。结果是,如果服务器过载,该服务器会尝试从客户端中删除请求并重新分发它们。
流程
使用指定的 Cookie 名称标注路由:
oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
$ oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<route_name>- 指定路由的名称。
<cookie_name>- 指定 Cookie 的名称。
例如,使用 cookie 名称
my_cookie标注路由my_route:oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
$ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在变量中捕获路由主机名:
ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')$ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<route_name>- 指定路由的名称。
保存 cookie,然后访问路由:
curl $ROUTE_NAME -k -c /tmp/cookie_jar
$ curl $ROUTE_NAME -k -c /tmp/cookie_jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用上一个命令在连接到路由时保存的 cookie:
curl $ROUTE_NAME -k -b /tmp/cookie_jar
$ curl $ROUTE_NAME -k -b /tmp/cookie_jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.7. 基于路径的路由 复制链接链接已复制到粘贴板!
基于路径的路由指定了一个路径组件,可以与 URL 进行比较,该 URL 需要基于 HTTP 的路由流量。因此,可以使用同一主机名提供多个路由,每个主机名都有不同的路径。路由器应该匹配基于最具体路径的路由。
下表显示了路由及其可访问性示例:
| Route(路由) | 当比较到 | 可访问 |
|---|---|---|
| www.example.com/test | www.example.com/test | 是 |
| www.example.com | 否 | |
| www.example.com/test 和 www.example.com | www.example.com/test | 是 |
| www.example.com | 是 | |
| www.example.com | www.example.com/text | yes(由主机匹配,而不是路由) |
| www.example.com | 是 |
带有路径的未安全路由
- 1
- 该路径是基于路径的路由的唯一添加属性。
使用 passthrough TLS 时,基于路径的路由不可用,因为路由器不会在这种情况下终止 TLS,且无法读取请求的内容。
21.1.8. HTTP 标头配置 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了不同的使用 HTTP 标头的方法。在设置或删除标头时,您可以使用 Ingress Controller 中的特定字段或单独的路由来修改请求和响应标头。您还可以使用路由注解设置某些标头。配置标头的各种方法在协同工作时可能会带来挑战。
您只能在 IngressController 或 Route CR 中设置或删除标头,您无法附加它们。如果使用值设置 HTTP 标头,则该值必须已完成,且在以后不需要附加。在附加标头(如 X-Forwarded-For 标头)时,请使用 spec.httpHeaders.forwardedHeaderPolicy 字段,而不是 spec.httpHeaders.actions。
21.1.8.1. 优先级顺序 复制链接链接已复制到粘贴板!
当在 Ingress Controller 和路由中修改相同的 HTTP 标头时,HAProxy 会根据它是请求还是响应标头来优先选择操作。
- 对于 HTTP 响应标头,Ingress Controller 中指定的操作会在路由中指定的操作后执行。这意味着 Ingress Controller 中指定的操作具有优先权。
- 对于 HTTP 请求标头,路由中指定的操作会在 Ingress Controller 中指定的操作后执行。这意味着路由中指定的操作具有优先权。
例如,集群管理员使用以下配置设置 X-Frame-Options 响应标头,其值为 DENY :
IngressController spec 示例
路由所有者设置 Ingress Controller 中设置的相同响应标头,但使用以下配置值 SAMEORIGIN :
Route 规格示例
当 IngressController spec 和 Route spec 都配置 X-Frame-Options 标头时,Ingress Controller 中的全局级别为这个标头设置的值将具有优先权,即使一个特定的路由允许帧。对于请求标头,Route spec 值会覆盖 IngressController spec 值。
发生这个优先级,因为 haproxy.config 文件使用以下逻辑,其中 Ingress Controller 被视为前端,单独的路由被视为后端。应用到前端配置的标头值 DENY 使用后端中设置的值 SAMEORIGIN 覆盖相同的标头:
另外,Ingress Controller 或路由中定义的任何操作都覆盖使用路由注解设置的值。
21.1.8.2. 特殊情况标头 复制链接链接已复制到粘贴板!
以下标头可能会阻止完全被设置或删除,或者在特定情况下允许:
| 标头名称 | 使用 IngressController spec 进行配置 | 使用 Route 规格进行配置 | 禁止的原因 | 使用其他方法进行配置 |
|---|---|---|---|---|
|
| 否 | 否 |
| 否 |
|
| 否 | 是 |
当使用 | 否 |
|
| 否 | 否 |
|
是: |
|
| 否 | 否 | HAProxy 集的 Cookie 用于会话跟踪,用于将客户端连接映射到特定的后端服务器。允许设置这些标头可能会影响 HAProxy 的会话关联,并限制 HAProxy 的 Cookie 的所有权。 | 是:
|
21.1.9. 在路由中设置或删除 HTTP 请求和响应标头 复制链接链接已复制到粘贴板!
出于合规的原因,您可以设置或删除某些 HTTP 请求和响应标头。您可以为 Ingress Controller 提供的所有路由或特定路由设置或删除这些标头。
例如,如果内容使用多种语言编写,您可能希望让 Web 应用程序在备用位置提供内容,即使 Ingress Controller 为路由指定的默认全局位置。
以下流程会创建一个设置 Content-Location HTTP 请求标头的路由,以便与应用程序关联的 URL https://app.example.com 定向到位置 https://app.example.com/lang/en-us。将应用程序流量定向到此位置意味着使用该特定路由的任何人都可以访问以美国英语编写的 Web 内容。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 以项目管理员身份登录到 OpenShift Container Platform 集群。
- 您有一个 web 应用来公开端口,以及侦听端口流量的 HTTP 或 TLS 端点。
流程
创建一个路由定义,并将它保存到名为
app-example-route.yaml的文件中:使用 HTTP 标头指令创建路由的 YAML 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用新创建的路由定义,创建到现有 Web 应用程序的路由:
oc -n app-example create -f app-example-route.yaml
$ oc -n app-example create -f app-example-route.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
对于 HTTP 请求标头,路由定义中指定的操作会在 Ingress Controller 中对 HTTP 请求标头执行的任何操作后执行。这意味着,路由中这些请求标头设置的任何值都将优先于 Ingress Controller 中设置的值。有关 HTTP 标头处理顺序的更多信息,请参阅 HTTP 标头配置。
21.1.10. 特定于路由的注解 复制链接链接已复制到粘贴板!
Ingress Controller 可以为它公开的所有路由设置默认选项。单个路由可以通过在其注解中提供特定配置来覆盖这些默认设置。红帽不支持在 Operator 管理的路由中添加路由注解。
要创建带有多个源 IP 或子网的白名单,请使用以空格分隔的列表。任何其他限定类型会导致忽略列表,而不发出警告或错误消息。
| 变量 | 描述 | 默认的环境变量 |
|---|---|---|
|
|
设置负载平衡算法。可用选项为 |
passthrough 路由 使用 |
|
|
禁用使用 cookie 来跟踪相关连接。如果设置为 | |
|
| 指定一个可选的、用于此路由的 cookie。名称只能包含大写字母和小写字母、数字、"_" 和 "-"。默认为路由的内部密钥进行哈希处理。 | |
|
|
设置路由器支持的 pod 允许的最大连接数。 | |
|
|
设置 | |
|
|
限制通过同一源 IP 地址进行的并发 TCP 连接数。它接受一个数字值。 | |
|
|
限制具有相同源 IP 地址的客户端可以发出 HTTP 请求的速率。它接受一个数字值。 | |
|
|
限制具有相同源 IP 地址的客户端可以进行 TCP 连接的速率。它接受一个数字值。 | |
|
| 为路由设定服务器端超时。(TimeUnits) |
|
|
| 这个超时适用于隧道连接,如明文、边缘、重新加密或透传路由。使用明文、边缘或重新加密路由类型,此注解作为带有现有超时值的超时隧道应用。对于 passthrough 路由类型,注解优先于设置任何现有的超时值。 |
|
|
|
您可以设置 IngressController 或 ingress 配置。此注解重新部署路由器,并将 HA 代理配置为在全局后发出 haproxy |
|
|
| 为后端健康检查设定间隔。(TimeUnits) |
|
|
| 为路由设置允许列表。允许列表(allowlist)是以空格分开的 IP 地址和 CIDR 范围列表,用来代表批准的源地址。不是来自允许列表中的 IP 地址的请求会被丢弃。
在 | |
|
| 为 edge terminated 或 re-encrypt 路由设置 Strict-Transport-Security 标头。 | |
|
| 在后端中设置请求的重写路径。 | |
|
| 设置一个值来限制 cookies。数值是:
这个值仅适用于重新加密和边缘路由。如需更多信息,请参阅 SameSite cookies 文档。 | |
|
|
设置用于处理每个路由的
|
|
-
默认情况下,路由器会每 5 秒重新加载一次,它会从头重置容器集之间的平衡连接。因此,
roundrobin状态不会在重新加载后保留。当 pod 具有几乎相同的计算能力和存储容量时,此算法效果最佳。如果您的应用程序或服务会持续更改端点,例如,由于使用了 CI/CD 管道,可能会出现不平衡的结果。如果是这种情况下,可以使用不同的算法。 如果允许列表中的 IP 地址和 CIDR 范围超过 61,它们将被写入到一个独立的文件中,
haproxy.config会引用这个文件。此文件存储在/var/lib/haproxy/router/allowlists文件夹中。注意为确保地址被写入允许列表,请检查 Ingress Controller 配置文件中是否列出了 CIDR 范围的完整列表。etcd 对象大小限制了路由注解的大小。因此,它实际上是为您可以在允许列表中包含的 IP 地址和 CIDR 范围的最大数量创建一个阈值。
环境变量不能编辑。
路由器超时变量
TimeUnits 由一个数字及一个时间单位表示:us *(microseconds), ms(毫秒,默认)、s(秒)、m (分钟)、h *(小时) 、d (天)。
正则表达式是: [1-9][0-9]*(us\|ms\|s\|m\|h\|d)。
| 变量 | 默认 | Description |
|---|---|---|
|
|
| 后端上后续存活度检查之间的时长。 |
|
|
| 控制连接到路由的客户端的 TCP FIN 超时周期。如果发送到关闭连接的 FIN 在给定时间内没有回答,HAProxy 会关闭连接。如果设置为较低值,并且在路由器上使用较少的资源,则这不会产生任何损害。 |
|
|
| 客户端必须确认或发送数据的时长。 |
|
|
| 最长连接时间。 |
|
|
| 控制路由器到支持路由的 pod 的 TCP FIN 超时。 |
|
|
| 服务器必须确认或发送数据的时长。 |
|
|
| TCP 或 WebSocket 连接保持打开的时长。每当 HAProxy 重新加载时,这个超时期限都会重置。 |
|
|
|
设置等待出现新 HTTP 请求的最长时间。如果设置得太低,可能会导致浏览器和应用程序无法期望较小的
某些有效的超时值可以是某些变量的总和,而不是特定的预期超时。例如: |
|
|
| HTTP 请求传输可以花费的时间长度。 |
|
|
| 允许路由器至少执行重新加载和接受新更改的频率。 |
|
|
| 收集 HAProxy 指标的超时时间。 |
设置自定义超时的路由
- 1
- 使用 HAProxy 支持的时间单位(
us,ms,s,m,h,d)指定新的超时时间。如果没有提供时间单位,ms会被默认使用。
如果为 passthrough 路由设置的服务器端的超时值太低,则会导致 WebSocket 连接在那个路由上经常出现超时的情况。
只允许一个特定 IP 地址的路由
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
允许多个 IP 地址的路由
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
允许 IP 地址 CIDR 网络的路由
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
允许 IP 地址和 IP 地址 CIDR 网络的路由
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
指定重写对象的路由
- 1
- 将
/设为后端请求的重写路径。
在路由上设置 haproxy.router.openshift.io/rewrite-target 注解,指定 Ingress Controller 在将请求转发到后端应用程序之前,应该使用此路由在 HTTP 请求中重写路径。与 spec.path 中指定的路径匹配的请求路径部分将替换为注解中指定的重写对象。
下表提供了在 spec.path、请求路径和重写对象的各种组合中重写行为的路径示例。
| Route.spec.path | 请求路径 | 重写目标 | 转发请求路径 |
|---|---|---|---|
| /foo | /foo | / | / |
| /foo | /foo/ | / | / |
| /foo | /foo/bar | / | /bar |
| /foo | /foo/bar/ | / | /bar/ |
| /foo | /foo | /bar | /bar |
| /foo | /foo/ | /bar | /bar/ |
| /foo | /foo/bar | /baz | /baz/bar |
| /foo | /foo/bar/ | /baz | /baz/bar/ |
| /foo/ | /foo | / | 不适用(请求路径不匹配路由路径) |
| /foo/ | /foo/ | / | / |
| /foo/ | /foo/bar | / | /bar |
haproxy.router.openshift.io/rewrite-target 中的某些特殊字符需要特殊处理,因为它们必须正确转义。请参阅下表以了解这些字符的处理方式。
| 对于字符 | 使用字符 | 注 |
|---|---|---|
| # | \# | 避免使用 #,因为它会终止重写表达式 |
| % | % 或 %% | 避免奇数序列,如 %%% |
| ‘ | \’ | 避免 ',因为它被忽略 |
所有其他有效的 URL 字符可以在不转义的情况下使用。
21.1.11. 配置路由准入策略 复制链接链接已复制到粘贴板!
管理员和应用程序开发人员可在多个命名空间中运行具有相同域名的应用程序。这是针对多个团队开发的、在同一个主机名上公开的微服务的机构。
只有在命名空间间有信任的集群才会启用跨命名空间之间的声明,否则恶意用户可能会接管主机名。因此,默认的准入策略不允许在命名空间间声明主机名。
先决条件
- 必须具有集群管理员权限。
流程
使用以下命令编辑
ingresscontroller资源变量的.spec.routeAdmission 字段:oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge$ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress 控制器配置参数
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来配置路由准入策略:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.12. 通过 Ingress 对象创建路由 复制链接链接已复制到粘贴板!
一些生态系统组件与 Ingress 资源集成,但与路由资源不集成。要涵盖此问题单,OpenShift Container Platform 会在创建 Ingress 对象时自动创建受管路由对象。当相应 Ingress 对象被删除时,这些路由对象会被删除。
流程
在 OpenShift Container Platform 控制台中或通过
oc create命令来定义 Ingress 对象:Ingress 的 YAML 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
route.openshift.io/termination注解可用于配置Route的spec.tls.termination字段,因为Ingress没有此字段。可接受的值为edge、passthrough和reencrypt。所有其他值都会被静默忽略。当注解值未设置时,edge是默认路由。模板文件中必须定义 TLS 证书详细信息,才能实现默认的边缘路由。- 3
- 在使用
Ingress对象时,您必须指定一个显式主机名,这与使用路由时不同。您可以使用<host_name>.<cluster_ingress_domain>语法(如apps.openshiftdemos.com)以利用*.<cluster_ingress_domain>通配符 DNS 记录,为集群提供证书。否则,您必须确保有一个用于所选主机名的 DNS 记录。如果您在
route.openshift.io/termination注解中指定passthrough值,在 spec 中将path设置为'',将pathType设置为ImplementationSpecific:Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ingress.yaml
$ oc apply -f ingress.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- 2
route.openshift.io/destination-ca-certificate-secret可用于 Ingress 对象来定义带有自定义目的地证书(CA)的路由。该注解引用一个 kubernetes secret,secret-ca-cert将插入到生成的路由中。-
要从 ingress 对象使用目标 CA 指定路由对象,您必须在 secret 的
data.tls.crtspecifier 中创建一个带有 PEM 编码格式的证书的kubernetes.io/tls或Opaque类型 secret。
-
要从 ingress 对象使用目标 CA 指定路由对象,您必须在 secret 的
列出您的路由:
oc get routes
$ oc get routesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 结果包括一个自动生成的路由,其名称以
frontend-开头:NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您检查这个路由,它会类似于:
自动生成的路由的 YAML 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.13. 通过 Ingress 对象使用默认证书创建路由 复制链接链接已复制到粘贴板!
如果您在没有指定 TLS 配置的情况下创建 Ingress 对象,OpenShift Container Platform 会生成一个不安全的路由。要创建使用默认入口证书生成安全边缘终止路由的 Ingress 对象,您可以指定一个空的 TLS 配置,如下所示:
前提条件
- 您有一个要公开的服务。
-
您可以访问 OpenShift CLI(
oc)。
流程
为 Ingress 对象创建 YAML 文件。在本例中,该文件名为
example-ingress.yaml:Ingress 对象的 YAML 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用此精确的语法指定 TLS,而不指定自定义证书。
运行以下命令来创建 Ingress 对象:
oc create -f example-ingress.yaml
$ oc create -f example-ingress.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,验证 OpenShift Container Platform 是否为 Ingress 对象创建了预期的路由:
oc get routes -o yaml
$ oc get routes -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.14. 在 Ingress 注解中使用目标 CA 证书创建路由 复制链接链接已复制到粘贴板!
在 Ingress 对象上可以使用 route.openshift.io/destination-ca-certificate-secret 注解来定义带有自定义目标 CA 证书的路由。
前提条件
- 您可以在 PEM 编码文件中有一个证书/密钥对,其中的证书对路由主机有效。
- 您可以在 PEM 编码文件中有一个单独的 CA 证书来补全证书链。
- 您必须在 PEM 编码文件中有单独的目标 CA 证书。
- 您必须具有要公开的服务。
流程
输入以下命令为目标 CA 证书创建 secret:
oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>
$ oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt
$ oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
secret/dest-ca-cert created
secret/dest-ca-cert createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
route.openshift.io/destination-ca-certificate-secret添加到 Ingress 注解中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 该注解引用 kubernetes secret。
此注解中引用的机密将插入到生成的路由中。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
如果您的 OpenShift Container Platform 集群是为 IPv4 和 IPv6 双栈网络配置的,则 OpenShift Container Platform 路由可从外部访问集群。
Ingress Controller 会自动提供具有 IPv4 和 IPv6 端点的服务,但您可以为单堆栈或双栈服务配置 Ingress Controller。
先决条件
- 您在裸机上部署了 OpenShift Container Platform 集群。
-
已安装 OpenShift CLI(
oc)。
流程
要使 Ingress Controller 为工作负载提供通过 IPv4/IPv6 的流量,您可以通过设置 ipFamilies 和 ipFamilyPolicy 字段来创建服务 YAML 文件,或通过设置
ipFamilies和ipFamilyPolicy字段来修改现有服务 YAML 文件。例如:服务 YAML 文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这些资源生成对应的
端点。Ingress Controller 现在监视endpointslices。要查看
端点,请输入以下命令:oc get endpoints
$ oc get endpointsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要查看
endpointslices,输入以下命令:oc get endpointslices
$ oc get endpointslicesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
21.2. 安全路由 复制链接链接已复制到粘贴板!
安全路由提供以下几种 TLS 终止功能来为客户端提供证书。以下小节介绍了如何使用自定义证书创建重新加密、边缘和透传路由。
如果您在 Microsoft Azure 中创建通过公共端点的路由,则资源名称会受到限制。您不能创建使用某些词语的资源。如需 Azure 限制词语的列表,请参阅 Azure 文档中的解决预留资源名称错误。
21.2.1. 使用自定义证书创建重新加密路由 复制链接链接已复制到粘贴板!
您可以通过 oc create route 命令,使用重新加密 TLS 终止和自定义证书配置安全路由。
前提条件
- 您必须在 PEM 编码文件中有一个证书/密钥对,其中的证书对路由主机有效。
- 您可以在 PEM 编码文件中有一个单独的 CA 证书来补全证书链。
- 您必须在 PEM 编码文件中有单独的目标 CA 证书。
- 您必须具有要公开的服务。
不支持密码保护的密钥文件。要从密钥文件中删除密码,使用以下命令:
openssl rsa -in password_protected_tls.key -out tls.key
$ openssl rsa -in password_protected_tls.key -out tls.key
流程
此流程使用自定义证书和重新加密 TLS 终止创建 Route 资源。以下步骤假定证书/密钥对位于当前工作目录下的 tls.crt 和 tls.key 文件中。您还必须指定一个目标 CA 证书,使 Ingress Controller 信任服务的证书。您也可以根据需要指定 CA 证书来补全证书链。替换 tls.crt、tls.key、cacert.crt 和(可选)ca.crt 的实际路径名称。替换您要为 frontend 公开的 Service 资源的名称。使用适当的主机名替换 www.example.com。
使用重新加密 TLS 终止和自定义证书,创建安全
Route资源:oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
$ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您检查生成的
Route资源,它应该类似于如下:安全路由 YAML 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如需了解更多选项,请参阅
oc create route reencrypt --help。
21.2.2. 使用自定义证书创建边缘路由 复制链接链接已复制到粘贴板!
您可以通过 oc create route 命令,使用边缘 TLS 终止和自定义证书配置安全路由。使用边缘路由时,Ingress Controller 在将流量转发到目标 pod 之前终止 TLS 加密。该路由指定了 Ingress Controller 用于路由的 TLS 证书和密钥。
前提条件
- 您必须在 PEM 编码文件中有一个证书/密钥对,其中的证书对路由主机有效。
- 您可以在 PEM 编码文件中有一个单独的 CA 证书来补全证书链。
- 您必须具有要公开的服务。
不支持密码保护的密钥文件。要从密钥文件中删除密码,使用以下命令:
openssl rsa -in password_protected_tls.key -out tls.key
$ openssl rsa -in password_protected_tls.key -out tls.key
流程
此流程使用自定义证书和边缘 TLS 终止创建 Route 资源。以下步骤假定证书/密钥对位于当前工作目录下的 tls.crt 和 tls.key 文件中。您也可以根据需要指定 CA 证书来补全证书链。替换 tls.crt、tls.key 和(可选)ca.crt 的实际路径名称。替换您要为 frontend 公开的服务名称。使用适当的主机名替换 www.example.com。
使用边缘 TLS 终止和自定义证书,创建安全
Route资源。oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com
$ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您检查生成的
Route资源,它应该类似于如下:安全路由 YAML 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如需了解更多选项,请参阅
oc create route edge --help。
21.2.3. 创建 passthrough 路由 复制链接链接已复制到粘贴板!
您可以使用 oc create route 命令使用 passthrough 终止配置安全路由。如果 passthrough 终止,加密的流量会直接发送到目的地,而路由器不会提供 TLS 终止。因此,路由不需要密钥或证书。
前提条件
- 您必须具有要公开的服务。
流程
创建
Route资源:oc create route passthrough route-passthrough-secured --service=frontend --port=8080
$ oc create route passthrough route-passthrough-secured --service=frontend --port=8080Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您检查生成的
Route资源,它应该类似于如下:使用 Passthrough 终止的安全路由
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 目标 pod 负责为端点上的流量提供证书。目前,这是唯一支持需要客户端证书的方法,也称双向验证。
21.2.4. 使用外部受管证书创建路由 复制链接链接已复制到粘贴板!
在 TLS secret 中使用外部证书保护路由只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
您可以使用路由 API 的 .spec.tls.externalCertificate 字段来使用第三方证书管理解决方案配置 OpenShift Container Platform 路由。您可以通过 secret 引用外部管理的 TLS 证书,无需手动证书管理。
通过使用外部受管证书,您可以减少错误以确保更顺利地推出证书更新,并使 OpenShift 路由器能够及时提供更新的证书。边缘(edge)路由和重新加密(re-encrypt)路由可用于外部管理的证书
此功能适用于边缘路由和重新加密路由。
先决条件
-
您必须启用
RouteExternalCertificate功能门。 -
对
routes/custom-host子资源具有create 权限,该资源用于创建和更新路由。 -
您必须有一个包含 PEM 编码格式的有效证书或密钥对的 secret,类型为
kubernetes.io/tls,其中包括tls.key和tls.crt键。示例命令:$ oc create secret tls myapp-tls --cert=server.crt --key=server.key.
流程
运行以下命令,在与 secret 相同的命名空间中创建
角色对象,以允许路由器服务帐户读取访问权限:oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \ --namespace=<current-namespace>
$ oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \ --namespace=<current-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<secret-name> : 指定 secret 的实际名称。 -
<current-namespace> : 指定 secret 和路由所在的命名空间。
-
运行以下命令,在与 secret 相同的命名空间中创建
rolebinding对象,并将 router 服务帐户绑定到新创建的角色:oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace>
$ oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<current-namespace> : 指定 secret 和路由所在的命名空间。
-
创建一个定义
路由的 YAML 文件,并使用以下示例指定包含证书的 secret。安全路由的 YAML 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<secret-name> : 指定 secret 的实际名称。
-
运行以下命令来创建路由资源。如果 secret 存在并具有证书/密钥对,如果满足所有先决条件,路由器将提供生成的证书。oc apply -f <route.yaml>
$ oc apply -f <route.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<route.yaml> : 指定生成的 YAML 文件名。
-
如果没有提供 .spec.tls.externalCertificate,路由器将使用默认生成的证书。
使用 .spec.tls.externalCertificate 字段时,您无法提供 .spec.tls.certificate 字段或 .spec.tls.key 字段。
第 22 章 配置集群入口流量 复制链接链接已复制到粘贴板!
22.1. 集群入口流量配置概述 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了以下从集群外部与集群中运行的服务进行通信的方法。
建议采用以下方法,它们按顺序或首选程度排列:
- 如果您有 HTTP/HTTPS,请使用 Ingress Controller。
- 如果您有 HTTPS 之外的 TLS 加密协议。比如对于使用 SNI 标头的 TLS,请使用 Ingress Controller。
-
否则,请使用负载均衡器、外部 IP 或
NodePort。
| 方法 | 用途 |
|---|---|
| 允许访问 HTTP/HTTPS 流量和 HTTPS 以外的 TLS 加密协议(例如,使用 SNI 标头的 TLS)。 | |
| 允许流量通过从池分配的 IP 地址传到非标准端口。大多数云平台都提供了一种使用负载平衡器 IP 地址启动服务的方法。 | |
| 允许从机器网络中的一个池到特定 IP 地址的流量。对于裸机安装或类似于裸机的平台,MetalLB 提供了使用负载平衡器 IP 地址启动服务的途径。 | |
| 允许流量通过特定的 IP 地址传到非标准端口。 | |
| 在集群中的所有节点上公开某一服务。 |
22.1.1. 比较:对外部 IP 地址的容错访问 复制链接链接已复制到粘贴板!
对于提供对外部 IP 地址访问权限的通信方法,另一个考虑因素是对 IP 地址的容错访问。以下功能提供对外部 IP 地址的容错访问。
- IP 故障切换
- IP 故障切换管理一组节点的虚拟 IP 地址池。它通过 Keepalived 和虚拟路由器冗余协议 (VRRP) 实施。IP 故障转移仅仅是第 2 层机制,它依赖于多播。对于某些网络,多播可能有缺点。
- MetalLB
- MetalLB 具有 2 层模式,但它不使用多播。第 2 层模式有一个缺点,它会通过一个节点传输外部 IP 地址的所有流量。
- 手动分配外部 IP 地址
- 您可以使用 IP 地址块配置集群,用于为服务分配外部 IP 地址。默认情况下禁用此功能。此功能非常灵活,但给集群或网络管理员带来了最大的负担。集群已准备好接收目标为外部 IP 的流量,但每个客户必须决定如何将流量路由到节点。
22.2. 为服务配置 ExternalIP 复制链接链接已复制到粘贴板!
作为集群管理员,您可以指定可向集群中服务发送流量的集群外部 IP 地址块。
这个功能通常最适用于在裸机硬件上安装的集群。
22.2.1. 先决条件 复制链接链接已复制到粘贴板!
- 您的网络基础架构必须将外部 IP 地址的流量路由到集群。
22.2.2. 关于 ExternalIP 复制链接链接已复制到粘贴板!
对于非云环境,OpenShift Container Platform 支持使用 ExternalIP 工具在 Service 对象的 spec.externalIPs[] 参数中指定外部 IP 地址。使用 ExternalIP 功能配置的服务与具有 type=NodePort 的服务相似,通过流量定向到本地节点以进行负载均衡。
对于云环境,使用负载均衡器服务自动部署云负载均衡器,以服务端点为目标。
为参数指定值后,OpenShift Container Platform 会为该服务分配额外的虚拟 IP 地址。IP 地址可以存在于您为集群定义的服务网络之外。
因为默认情况下会禁用 ExternalIP,所以启用 ExternalIP 功能可能会给该服务带来安全风险,因为集群内到外部 IP 地址的流量会定向到该服务。此配置意味着集群用户可以截获用于外部资源的敏感流量。
您可以使用 MetalLB 实现或 IP 故障转移部署,将 ExternalIP 资源附加到服务:
- 自动分配一个外部 IP
-
当创建了一个带有
spec.type=LoadBalancer设置的Service对象时,OpenShift Container Platform 会从autoAssignCIDRsCIDR 块中自动为spec.externalIPs[]分配一个 IP 地址。对于此配置,OpenShift Container Platform 实施负载均衡器服务类型的云版本,并为服务分配 IP 地址。默认情况下,自动分配被禁用,必须由集群管理员配置,如 "Configuration for ExternalIP" 部分所述。 - 手动分配外部 IP
-
OpenShift Container Platform 在创建
Service对象时使用分配给spec.externalIPs[]数组的 IP 地址。您不能指定已经被其他服务使用的 IP 地址。
在使用 MetalLB 实现或 IP 故障转移部署来托管外部 IP 地址块后,您必须配置网络基础架构,以确保外部 IP 地址块路由到集群。此配置意味着,IP 地址没有在来自节点的网络接口中配置。要处理流量,您必须使用方法配置路由和访问外部 IP,如静态地址解析协议(ARP)条目。
OpenShift Container Platform 通过添加以下功能来扩展 Kubernetes 中的 ExternalIP 功能:
- 通过可配置策略对用户使用外部 IP 地址的限制
- 根据请求自动将外部 IP 地址分配给服务
22.2.3. 配置 ExternalIP 复制链接链接已复制到粘贴板!
Network.config.openshift.io 自定义资源(CR)中的以下参数管理在 OpenShift Container Platform 中使用外部 IP 地址:
-
spec.externalIP.autoAssignCIDRs定义了一个负载均衡器在为服务选择外部 IP 地址时使用的 IP 地址块。OpenShift Container Platform 只支持单个 IP 地址块进行自动分配。这个配置需要较少的步骤,而不是手动为服务分配 ExternalIP,这需要管理有限共享 IP 地址的端口空间。如果启用自动分配,Cloud Controller Manager Operator 会将外部 IP 地址分配给在其配置中带有spec.type=LoadBalancerdefind 的Service对象。 -
在手动指定 IP 地址时,
spec.externalIP.policy定义了允许的 IP 地址块。OpenShift Container Platform 不将策略规则应用到您在spec.externalIP.autoAssignCIDRs参数中定义的 IP 地址块。
如果路由正确,来自配置的外部 IP 地址块的外部流量可以通过服务公开的任何 TCP 或 UDP 端口访问服务端点。
作为集群管理员,您必须配置到 externalIPs 的路由。您还必须确保分配的 IP 地址块在集群中的一个或多个节点上终止。如需更多信息,请参阅 Kubernetes 外部 IP。
OpenShift Container Platform 支持自动和手动 IP 地址分配。这一支持保证,每个地址被分配到最多一个服务,并且每个服务都可以公开其所选端口,而不考虑由其他服务公开的端口。
要使用 OpenShift Container Platform 中由 autoAssignCIDRs 定义 的 IP 地址块,您必须为主机网络配置必要的 IP 地址分配和路由。
以下 YAML 描述了配置了外部 IP 地址的服务:
带有 spec.externalIPs[] 设置的示例 Service 对象
如果在 cloud-provider 平台上运行私有集群,您可以通过运行以下 patch 命令将 Ingress Controller 负载均衡器的发布范围改为 internal :
oc -n openshift-ingress-operator patch ingresscontrollers/ingress-controller-with-nlb --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"loadBalancer":{"scope":"Internal"}}}}'
$ oc -n openshift-ingress-operator patch ingresscontrollers/ingress-controller-with-nlb --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"loadBalancer":{"scope":"Internal"}}}}'
运行此命令后,Ingress Controller 只会将 OpenShift Container Platform 应用程序的路由限制为内部网络。
22.2.4. 对外部 IP 地址分配的限制 复制链接链接已复制到粘贴板!
作为集群管理员,您可以指定 IP 地址块来允许和拒绝服务的 IP 地址。限制只针对没有 cluster-admin 权限的用户。集群管理员始终可以将服务 spec.externalIPs[] 字段设置为任何 IP 地址。
您可以通过在策略对象中为 spec.ExternalIP.policy 参数指定无类别域间路由(CIDR)地址块来配置 IP 地址 policy。
policy 对象及其 CIDR 参数的 JSON 格式示例
在配置策略限制时,会应用以下规则:
-
如果
policy设置为{},创建带有spec.ExternalIPs[]的Service对象会导致服务失败。此设置是 OpenShift Container Platform 的默认设置。相同的行为存在于policy: null。 如果设置了
policy,并且设置了policy.allowedCIDRs[]或policy.rejectedCIDRs[],则应用以下规则:-
如果同时设置了
allowedCIDRs[]和rejectedCIDRs[],则rejectedCIDRs[]优先于allowedCIDRs[]。 -
如果设置了
allowedCIDRs[],只有在允许指定的 IP 地址时,创建带有spec.ExternalIPs[]的Service对象才能成功。 -
如果设置了
rejectedCIDRs[],只有在指定的 IP 地址未被拒绝时,创建带有spec.ExternalIPs[]的Service对象才能成功。
-
如果同时设置了
22.2.5. 策略对象示例 复制链接链接已复制到粘贴板!
本节中的示例显示不同的 spec.externalIP.policy 配置。
在以下示例中,策略会阻止 OpenShift Container Platform 使用指定的外部 IP 地址创建任何服务。
拒绝为
Service对象spec.externalIPs[]指定的任何值的策略示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在以下示例中,设置了
allowedCIDRs和rejectedCIDRs字段。包括允许和拒绝 CIDR 块的策略示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在以下示例中,
policy设置为{}。使用这个配置,使用oc get network.config.openshift.io -o yaml命令查看配置意味着policy参数不会显示在命令输出上。相同的行为存在于policy: null。允许为
Service对象spec.externalIPs[]指定的任何值的示例策略Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.2.6. ExternalIP 地址块配置 复制链接链接已复制到粘贴板!
ExternalIP 地址块的配置由名为 cluster 的网络自定义资源(CR)定义。Network CR 是 config.openshift.io API 组的一部分。
在集群安装过程中,Cluster Version Operator(CVO)会自动创建一个名为 cluster 的网络 CR。不支持创建此类型的任何其他 CR 对象。
以下 YAML 描述了 ExternalIP 配置:
network.config.openshift.io CR 名为 cluster
以下 YAML 描述了 policy 小节的字段:
network.config.openshift.io policy 小节
policy: allowedCIDRs: [] rejectedCIDRs: []
policy:
allowedCIDRs: []
rejectedCIDRs: []
22.2.6.1. 外部 IP 配置示例 复制链接链接已复制到粘贴板!
以下示例中显示了外部 IP 地址池的一些可能配置:
以下 YAML 描述了启用自动分配外部 IP 地址的配置:
带有
spec.externalIP.autoAssignCIDRs的配置示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下 YAML 为允许的和被拒绝的 CIDR 范围配置策略规则:
带有
spec.externalIP.policy的示例配置Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.2.7. 为集群配置外部 IP 地址块 复制链接链接已复制到粘贴板!
作为集群管理员,可以配置以下 ExternalIP 设置:
-
OpenShift Container Platform 用来自动填充
Service对象的spec.clusterIP字段的 ExternalIP 地址块。 -
用于限制可手动分配给
Service对象的spec.clusterIP数组的 IP 地址的策略对象。
先决条件
-
安装 OpenShift CLI(
oc)。 -
使用具有
cluster-admin角色的用户访问集群。
流程
可选: 要显示当前的外部 IP 配置,请输入以下命令:
oc describe networks.config cluster
$ oc describe networks.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要编辑配置,请输入以下命令:
oc edit networks.config cluster
$ oc edit networks.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 修改 ExternalIP 配置,如下例所示:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定
externalIP小节的配置。
要确认更新的 ExternalIP 配置,请输入以下命令:
oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'$ oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.2.9. 后续步骤 复制链接链接已复制到粘贴板!
22.3. 使用 Ingress Controller 配置集群入口流量 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了从集群外部与集群中运行的服务进行通信的方法。此方法使用了 Ingress Controller。
22.3.1. 使用 Ingress Controller 和路由 复制链接链接已复制到粘贴板!
Ingress Operator 管理 Ingress Controller 和通配符 DNS。
使用 Ingress Controller 是允许从外部访问 OpenShift Container Platform 集群的最常用方法。
Ingress Controller 配置为接受外部请求并根据配置的路由进行代理。这仅限于 HTTP、使用 SNI 的 HTTPS 以及使用 SNI 的 TLS,对于通过使用 SNI 的 TLS 工作的 Web 应用程序和服务而言已经足够。
与管理员合作将 Ingress Controller 配置为接受外部请求并根据配置的路由进行代理。
管理员可以创建通配符 DNS 条目,再设置 Ingress Controller。然后,您可以处理边缘 Ingress Controller,无需与管理员联系。
默认情况下,集群中的每个 Ingress Controller 都可以接受集群中任何项目中创建的所有路由。
Ingress Controller:
- 默认有两个副本;即,它应该在两个 worker 节点上运行。
- 可以纵向扩张,以在更多节点上具有更多副本。
这部分中的流程需要由集群管理员执行先决条件。
22.3.2. 先决条件 复制链接链接已复制到粘贴板!
在开始以下流程前,管理员必须:
- 设置集群联网环境的外部端口,使请求能够到达集群。
确定至少有一个用户具有集群管理员角色。要将此角色添加到用户,请运行以下命令:
oc adm policy add-cluster-role-to-user cluster-admin username
$ oc adm policy add-cluster-role-to-user cluster-admin usernameCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 有一个 OpenShift Container Platform 集群,其至少有一个 master 和至少一个节点,并且集群外有一个对集群具有网络访问权限的系统。此流程假设外部系统与集群位于同一个子网。不同子网上外部系统所需要的额外联网不在本主题的讨论范围内。
22.3.3. 创建项目和服务 复制链接链接已复制到粘贴板!
如果要公开的项目和服务不存在,请创建项目,然后创建该服务。
如果项目和服务都已存在,跳到公开服务以创建路由这一步。
先决条件
-
安装 OpenShift CLI (
oc),并以集群管理员身份登录。
流程
运行
oc new-project命令为您的服务创建一个新项目:oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc new-app命令来创建服务:oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证该服务是否已创建,请运行以下命令:
oc get svc -n <project_name>
$ oc get svc -n <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意默认情况下,新服务没有外部 IP 地址。
22.3.4. 通过创建路由公开服务 复制链接链接已复制到粘贴板!
您可以使用 oc expose 命令,将服务公开为路由。
先决条件
- 已登陆到 OpenShift Container Platform。
流程
登录您想公开的服务所在的项目:
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
oc expose service命令以公开路由:oc expose service nodejs-ex
$ oc expose service nodejs-exCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
route.route.openshift.io/nodejs-ex exposed
route.route.openshift.io/nodejs-ex exposedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证该服务是否已公开,您可以使用
curl等工具来检查该服务是否可从集群外部访问。要查找路由的主机名,请输入以下命令:
oc get route
$ oc get routeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要检查主机是否响应 GET 请求,请输入以下命令:
curl命令示例curl --head nodejs-ex-myproject.example.com
$ curl --head nodejs-ex-myproject.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
HTTP/1.1 200 OK ...
HTTP/1.1 200 OK ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.3.5. OpenShift Container Platform 中的 Ingress 分片 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 中,Ingress Controller 可以服务所有路由,也可以提供路由的子集。默认情况下,Ingress Controller 提供集群中任何命名空间中创建的任何路由。您可以在集群中添加额外的 Ingress Controller,以通过创建 分片来优化路由,这些分片是基于所选特征的路由子集。要将路由标记为分片的成员,请使用 route 或 namespace metadata 字段中的标签。Ingress Controller 使用选择器 (也称为 选择表达式 )从要提供服务的整个路由池中选择路由子集。
当您希望在多个 Ingress Controller 之间负载平衡传入的流量时,当您要隔离到特定 Ingress Controller 的流量或下一部分中描述的各种其他原因时,Ingress 分片很有用。
默认情况下,每个路由都使用集群的默认域。但是,可以将路由配置为使用路由器的域。
22.3.6. Ingress Controller 分片 复制链接链接已复制到粘贴板!
您可以通过向路由、命名空间或两者添加标签,使用 Ingress 分片(也称为路由器分片)在多个路由器之间分发一组路由。Ingress Controller 使用一组对应的选择器来只接受具有指定标签的路由。每个 Ingress 分片都由使用给定选择表达式过滤的路由组成。
Ingress Controller 是网络流量进入集群的主要机制,因此对它们的需求可能非常大。作为集群管理员,您可以对路由进行分片,以达到以下目的:
- 在 Ingress Controller 或路由器与一些路由之间实现平衡,由此加快对变更的响应。
- 分配特定的路由,使其具有不同于其它路由的可靠性保证。
- 允许特定的 Ingress Controller 定义不同的策略。
- 只允许特定的路由使用其他功能。
- 在不同的地址上公开不同的路由,例如使内部和外部用户能够看到不同的路由。
- 在蓝绿部署期间,将流量从应用的一个版本转移到另一个版本。
当 Ingress Controller 被分片时,一个给定路由被接受到组中的零个或多个 Ingress Controller。路由的状态描述了 Ingress Controller 是否已接受它。只有一个路由对一个分片是唯一的时,Ingress Controller 才会接受路由。
使用分片,您可以在多个 Ingress Controller 上分发路由子集。这些子集可以是非重叠的,也称为 传统 分片,或是重叠的,也称为 overlapped 分片。
下表概述了三分片方法:
| 分片方法 | 描述 |
|---|---|
| 命名空间选择器 | 将命名空间选择器添加到 Ingress Controller 后,在与命名空间选择器匹配的命名空间中的所有路由都包含在 Ingress shard 中。当 Ingress Controller 提供在命名空间中创建的所有路由时,请考虑此方法。 |
| 路由选择器 | 将路由选择器添加到 Ingress Controller 后,所有与路由选择器匹配的标签的路由都包含在 Ingress shard 中。当您希望 Ingress Controller 仅服务命名空间中的路由子集或特定路由时,请考虑此方法。 |
| 命名空间和路由选择器 | 为命名空间选择器和路由选择器方法提供 Ingress Controller 范围。当您想获得命名空间选择器和路由选择器方法的灵活性时,请考虑此方法。 |
22.3.6.1. 传统分片示例 复制链接链接已复制到粘贴板!
配置了 Ingress Controller finops-router 的示例,其标签选择器 spec.namespaceSelector.matchExpressions,其键值为 finance 和 ops :
finops-router 的 YAML 定义示例
配置了 Ingress Controller dev-router 的示例,其标签选择器 spec.namespaceSelector.matchLabels.name,其键值为 dev :
dev-router 的 YAML 定义示例
如果所有应用程序路由都位于单独的命名空间中,每个命名空间都分别使用 name:finance、name:ops 和 name:dev 标记,此配置会在两个 Ingress Controller 之间有效分发您的路由。不应处理用于控制台、身份验证和其他目的的 OpenShift Container Platform 路由。
在前面的场景中,分片成为分区的一种特殊情况,没有重叠的子集。路由在路由器分片之间划分。
默认 Ingress Controller 继续提供所有路由,除非 namespaceSelector 或 routeSelector 字段包含用于排除的路由。有关如何从默认 Ingress Controller 中排除路由的更多信息,请参阅这个 红帽知识库解决方案 和"分片默认 Ingress Controller"。
22.3.6.2. 重叠的分片示例 复制链接链接已复制到粘贴板!
配置了 Ingress Controller devops-router 的示例,其标签选择器 spec.namespaceSelector.matchExpressions,其键值为 finance 和 ops :
devops-router 的 YAML 定义示例
标签为 name:dev 和 name:ops 的命名空间中的路由现在由两个不同的 Ingress Controller 服务。使用这个配置,您有重叠的路由子集。
通过重叠的路由子集,您可以创建更复杂的路由规则。例如,您可以在向 devops-router 发送较低优先级的流量时,将优先级更高的流量放入专用的 finops-router。
22.3.6.3. 分片默认 Ingress Controller 复制链接链接已复制到粘贴板!
创建新的 Ingress shard 后,可能会接受到默认 Ingress Controller 接受的新 Ingress 分片的路由。这是因为默认 Ingress Controller 没有选择器,并默认接受所有路由。
您可以使用命名空间选择器或路由选择器来限制 Ingress Controller 使用特定标签提供路由。以下流程限制默认 Ingress Controller,使用命名空间选择器为新分片的 finance、ops 和 dev 提供。这为 Ingress 分片增加了额外的隔离。
您必须在同一 Ingress Controller 上保留所有 OpenShift Container Platform 管理路由。因此,避免在排除这些基本路由的默认 Ingress Controller 中添加额外的选择器。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 您以项目管理员身份登录。
流程
运行以下命令来修改默认 Ingress Controller:
oc edit ingresscontroller -n openshift-ingress-operator default
$ oc edit ingresscontroller -n openshift-ingress-operator defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑 Ingress Controller 以包含一个
namespaceSelector,它排除了任何finance、ops和dev标签的路由:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
默认 Ingress Controller 不再提供标记为 name:finance、name:ops 和 name:dev 的命名空间。
22.3.6.4. Ingress 分片和 DNS 复制链接链接已复制到粘贴板!
集群管理员负责为项目中的每个路由器生成单独的 DNS 条目。路由器不会将未知路由转发到另一个路由器。
考虑以下示例:
-
路由器 A 驻留在主机 192.168.0.5 上,并且具有
*.foo.com的路由。 -
路由器 B 驻留在主机 192.168.1.9 上,并且具有
*.example.com的路由。
单独的 DNS 条目必须将 *.foo.com 解析为托管 Router A 和 *.example.com 的节点到托管路由器 B 的节点:
-
*.foo.com A IN 192.168.0.5 -
*.example.com A IN 192.168.1.9
22.3.6.5. 通过路由标签(label)配置 Ingress Controller 分片 复制链接链接已复制到粘贴板!
使用路由标签进行 Ingress Controller 分片,意味着 Ingress Controller 提供由路由选择器选择的任意命名空间中的所有路由。
图 22.1. 使用路由标签进行 Ingress 分片
在一组 Ingress Controller 之间平衡传入的流量负载时,以及在将流量隔离到特定 Ingress Controller 时,Ingress Controller 分片会很有用处。例如,A 公司的流量使用一个 Ingress Controller,B 公司的流量则使用另外一个 Ingress Controller。
流程
编辑
router-internal.yaml文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定 Ingress Controller 使用的域。此域必须与默认 Ingress Controller 域不同。
应用 Ingress Controller
router-internal.yaml文件:oc apply -f router-internal.yaml
# oc apply -f router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller 选择具有
type: sharded标签的任意命名空间中的路由。使用
router-internal.yaml中配置的域创建新路由:oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.3.6.6. 使用命名空间标签配置 Ingress Controller 分片 复制链接链接已复制到粘贴板!
使用命名空间标签进行 Ingress Controller 分片,意味着 Ingress Controller 提供由命名空间选择器选择的任意命名空间中的所有路由。
图 22.2. 使用命名空间标签进行 Ingress 分片
在一组 Ingress Controller 之间平衡传入的流量负载时,以及在将流量隔离到特定 Ingress Controller 时,Ingress Controller 分片会很有用处。例如,A 公司的流量使用一个 Ingress Controller,B 公司的流量则使用另外一个 Ingress Controller。
流程
编辑
router-internal.yaml文件:cat router-internal.yaml
$ cat router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定 Ingress Controller 使用的域。此域必须与默认 Ingress Controller 域不同。
应用 Ingress Controller
router-internal.yaml文件:oc apply -f router-internal.yaml
$ oc apply -f router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller 选择由命名空间选择器选择的具有
type: sharded标签的任意命名空间中的路由。使用
router-internal.yaml中配置的域创建新路由:oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.3.6.7. 为 Ingress Controller 分片创建路由 复制链接链接已复制到粘贴板!
通过使用路由,您可以通过 URL 托管应用程序。Ingress Controller 分片有助于在一组 Ingress Controller 之间平衡传入的流量负载。它还可以将流量隔离到特定的 Ingress Controller。例如,A 公司的流量使用一个 Ingress Controller,B 公司的流量则使用另外一个 Ingress Controller。
以下流程描述了如何为 Ingress Controller 分片创建路由,使用 hello-openshift 应用程序作为示例。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 您以项目管理员身份登录。
- 您有一个 web 应用来公开端口,以及侦听端口流量的 HTTP 或 TLS 端点。
- 您已为分片配置了 Ingress Controller。
流程
运行以下命令,创建一个名为
hello-openshift的项目:oc new-project hello-openshift
$ oc new-project hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,在项目中创建 pod:
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,创建名为
hello-openshift的服务:oc expose pod/hello-openshift
$ oc expose pod/hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建名为
hello-openshift-route.yaml的路由定义:为分片创建的路由的 YAML 定义
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过运行以下命令,使用
hello-openshift-route.yaml创建到hello-openshift应用程序的路由:oc -n hello-openshift create -f hello-openshift-route.yaml
$ oc -n hello-openshift create -f hello-openshift-route.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
使用以下命令获取路由的状态:
oc -n hello-openshift get routes/hello-openshift-edge -o yaml
$ oc -n hello-openshift get routes/hello-openshift-edge -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 生成的
Route资源应类似以下示例:输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress Controller 或路由器的主机名用于公开路由。
host字段的值由 Ingress Controller 自动决定,并使用它的域。在本例中,Ingress Controller 的域为<apps-sharded.basedomain.example.net>。 - 2
- Ingress Controller 的主机名。如果没有设置主机名,则路由可以使用子域。当您指定子域时,会自动使用公开路由的 Ingress Controller 域。当路由由多个 Ingress Controller 公开时,路由由多个 URL 托管。
- 3
- Ingress Controller 的名称。在本例中,Ingress Controller 的名称为
sharded。
22.3.6.8. 其他资源 复制链接链接已复制到粘贴板!
22.4. 配置 Ingress Controller 端点发布策略 复制链接链接已复制到粘贴板!
endpointPublishingStrategy 用于向其他网络发布 Ingress Controller 端点,以启用负载均衡器集成,并提供对其他系统的访问。
在 Red Hat OpenStack Platform (RHOSP) 上,只有云供应商配置为创建运行状况监视器时,才会支持 LoadBalancerService 端点发布策略。对于 RHOSP 16.2,只有在您使用 Amphora Octavia 供应商时,才能使用此策略。
如需更多信息,请参阅 RHOSP 安装文档中的"设置 RHOSP Cloud Controller Manager 选项"部分。
22.4.1. Ingress Controller 端点发布策略 复制链接链接已复制到粘贴板!
NodePortService 端点发布策略
NodePortService 端点发布策略使用 Kubernetes NodePort 服务发布 Ingress Controller。
在这个配置中,Ingress Controller 部署使用容器网络。创建了一个 NodePortService 来发布部署。特定的节点端口由 OpenShift Container Platform 动态分配; 但是,为了支持静态端口分配,您会保留对受管 NodePortService 的节点端口字段的更改 。
图 22.3. NodePortService 图表
上图显示了与 OpenShift Container Platform Ingress NodePort 端点发布策略相关的以下概念:
- 集群中的所有可用节点均有自己的外部可访问 IP 地址。集群中运行的服务绑定到所有节点的唯一 NodePort。
-
当客户端连接到停机的节点时,例如,通过连接图形中的
10.0.128.4IP 地址,节点端口将客户端直接连接到运行该服务的可用节点。在这种情况下,不需要负载平衡。如图形中所显,10.0.128.4地址已不可用,必须使用另一个 IP 地址。
Ingress Operator 忽略对服务的 .spec.ports[].nodePort 字段的任何更新。
默认情况下,端口会自动分配,您可以访问集成的端口分配。但是,有时需要静态分配端口来与现有基础架构集成,这些基础架构可能无法根据动态端口进行重新配置。要实现与静态节点端口的集成,您可以直接更新受管服务资源。
如需有关 daemonset 的更多信息,请参阅关于 NodePort 的 Kubernetes 服务文档。
HostNetwork 端点发布策略
HostNetwork 端点发布策略会在部署 Ingress Controller 的节点端口上发布 Ingress Controller。
带有 HostNetwork 端点发布策略的 Ingress Controller 每个节点只能有一个 pod 副本。如果您想要 n 个副本,则必须至少使用可调度这些副本的 n 个节点。因为每个 Pod 副本都会通过调度的节点主机上的端口 80 和 443 进行请求,所以如果同一节点上的其他 pod 使用这些端口,则无法将副本调度到该节点。
HostNetwork 对象有一个 hostNetwork 字段,它有以下用于可选绑定端口的默认值:httpPort: 80, httpsPort: 443, 和 statsPort: 1936。通过为您的网络指定不同的绑定端口,您可以为 HostNetwork 策略在同一节点上部署多个 Ingress Controller。
Example
22.4.1.1. 将 Ingress Controller 端点发布范围配置为 Internal 复制链接链接已复制到粘贴板!
当集群管理员在没有指定集群为私有的情况下安装新集群时,将默认 Ingress Controller 创建,并将 scope 设置为 External。集群管理员可以将 External 范围的 Ingress Controller 更改为 Internal。
先决条件
-
已安装
ocCLI。
流程
要将
External范围的 Ingress Controller 更改为Internal,请输入以下命令:oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要检查 Ingress Controller 的状态,请输入以下命令:
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Progressing状态条件指示您必须执行进一步的操作。例如,状态条件可以通过输入以下命令来指示需要删除该服务:oc -n openshift-ingress delete services/router-default
$ oc -n openshift-ingress delete services/router-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果删除了该服务,Ingress Operator 会重新创建为
Internal。
22.4.1.2. 配置 Ingress Controller 端点发布范围到外部 复制链接链接已复制到粘贴板!
当集群管理员在没有指定集群为私有的情况下安装新集群时,将默认 Ingress Controller 创建,并将 scope 设置为 External。
Ingress Controller 的范围可以在安装过程中或之后配置为 Internal,集群管理员可以将 内部 Ingress Controller 更改为 External。
在某些平台上,需要删除并重新创建服务。
更改范围可能会导致 Ingress 流量中断,这可能会持续几分钟。这适用于需要删除和重新创建服务的平台,因为流程可能会导致 OpenShift Container Platform 取消置备现有服务负载均衡器、置备一个新服务负载均衡器并更新 DNS。
先决条件
-
已安装
ocCLI。
流程
要将
内部范围的 Ingress Controller 更改为外部,请输入以下命令:oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'$ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要检查 Ingress Controller 的状态,请输入以下命令:
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Progressing状态条件指示您必须执行进一步的操作。例如,状态条件可以通过输入以下命令来指示需要删除该服务:oc -n openshift-ingress delete services/router-default
$ oc -n openshift-ingress delete services/router-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果删除了该服务,Ingress Operator 会重新创建为
External。
22.4.1.3. 在 Ingress Controller 中添加单个 NodePort 服务 复制链接链接已复制到粘贴板!
您可以创建自定义 Ingress Controller 以使用 NodePortService 端点发布策略,而不是为各个项目创建 NodePort 类型 Service。要防止端口冲突,在您要通过 Ingress 分片将一组路由应用到可能具有 HostNetwork Ingress Controller 的节点时,请考虑 Ingress Controller 的此配置。
在为每个项目设置 NodePort 类型 Service 前,请阅读以下注意事项:
- 您必须为 Nodeport Ingress Controller 域创建一个通配符 DNS 记录。Nodeport Ingress Controller 路由可以从 worker 节点的地址访问。有关路由所需的 DNS 记录的更多信息,请参阅"用户置备 DNS 要求"。
-
您必须为您的服务公开路由,并为自定义 Ingress Controller 域指定
--hostname参数。 -
您必须在路由中附加分配给
NodePort类型Service的端口,以便您可以访问应用容器集。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin权限的用户身份登录。 - 您创建了通配符 DNS 记录。
流程
为 Ingress Controller 创建自定义资源 (CR) 文件:
定义
IngressController对象的信息的 CR 文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 为
IngressControllerCR 指定一个自定义名称。 - 2
- Ingress Controller 服务的 DNS 名称。例如,默认的 ingresscontroller 域是
apps.ipi-cluster.example.com,因此您要将<custom_ic_domain_name>指定为nodeportsvc.ipi-cluster.example.com。 - 3
- 指定包含自定义 Ingress Controller 的节点的标签。
- 4
- 指定一组命名空间的标签。使用键值对替换
<key>:<value>,其中<key>是新标签的唯一名称,<value>是它的值。例如:ingresscontroller: custom-ic。
使用
oc label node命令给节点添加标签:oc label node <node_name> <key>=<value>
$ oc label node <node_name> <key>=<value>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 其中
<value>必须与IngressControllerCR 的nodePlacement部分中指定的键值对匹配。
创建
IngressController对象:oc create -f <ingress_controller_cr>.yaml
$ oc create -f <ingress_controller_cr>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查找为
IngressControllerCR 创建的服务的端口:oc get svc -n openshift-ingress
$ oc get svc -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow 显示
router-nodeport-custom-ic3服务的端口80:32432/TCP的示例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-internal-default ClusterIP 172.30.195.74 <none> 80/TCP,443/TCP,1936/TCP 223d router-nodeport-custom-ic3 NodePort 172.30.109.219 <none> 80:32432/TCP,443:31366/TCP,1936:30499/TCP 155m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-internal-default ClusterIP 172.30.195.74 <none> 80/TCP,443/TCP,1936/TCP 223d router-nodeport-custom-ic3 NodePort 172.30.109.219 <none> 80:32432/TCP,443:31366/TCP,1936:30499/TCP 155mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要创建新项目,请输入以下命令:
oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要标记新命名空间,请输入以下命令:
oc label namespace <project_name> <key>=<value>
$ oc label namespace <project_name> <key>=<value>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 其中
<key>=<value>需要与 Ingress Controller CR 的namespaceSelector部分中的值匹配。
在集群中创建新应用程序:
oc new-app --image=<image_name>
$ oc new-app --image=<image_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 一个
<image_name>的示例是quay.io/openshifttest/hello-openshift:multiarch。
为服务创建
Route对象,以便 pod 可以使用该服务向集群外部公开应用程序。oc expose svc/<service_name> --hostname=<svc_name>-<project_name>.<custom_ic_domain_name>
$ oc expose svc/<service_name> --hostname=<svc_name>-<project_name>.<custom_ic_domain_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您必须在
--hostname参数中指定自定义 Ingress Controller 的域名。如果没有这样做,Ingress Operator 会使用默认的 Ingress Controller 来提供集群的所有路由。检查路由是否具有
Admitted状态,并且包含自定义 Ingress Controller 的元数据:oc get route/hello-openshift -o json | jq '.status.ingress'
$ oc get route/hello-openshift -o json | jq '.status.ingress'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新默认的
IngressControllerCR,以防止默认 Ingress Controller 管理NodePort类型Service。默认 Ingress Controller 将继续监控所有其他集群流量。oc patch --type=merge -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"namespaceSelector":{"matchExpressions":[{"key":"<key>","operator":"NotIn","values":["<value>]}]}}}'$ oc patch --type=merge -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"namespaceSelector":{"matchExpressions":[{"key":"<key>","operator":"NotIn","values":["<value>]}]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
输入以下命令验证 DNS 条目是否可以在集群内部和外部路由。命令输出之前从运行
oc label node命令接收标签的节点的 IP 地址。dig +short <svc_name>-<project_name>.<custom_ic_domain_name>
$ dig +short <svc_name>-<project_name>.<custom_ic_domain_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证集群是否使用来自外部 DNS 服务器的 IP 地址进行 DNS 解析,请输入以下命令检查集群的连接:
curl <svc_name>-<project_name>.<custom_ic_domain_name>:<port>
$ curl <svc_name>-<project_name>.<custom_ic_domain_name>:<port>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Hello OpenShift!
Hello OpenShift!Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.5. 使用负载均衡器配置集群入口流量 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了从集群外部与集群中运行的服务进行通信的方法。此方法使用了负载均衡器。
22.5.1. 使用负载均衡器使流量进入集群 复制链接链接已复制到粘贴板!
如果不需要具体的外部 IP 地址,您可以配置负载均衡器服务,以便从外部访问 OpenShift Container Platform 集群。
负载均衡器服务分配唯一 IP。负载均衡器有单一边缘路由器 IP,它可以是虚拟 IP (VIP),但仍然是一台用于初始负载均衡的计算机。
如果配置了池,则会在基础架构一级进行,而不是由集群管理员完成。
这部分中的流程需要由集群管理员执行先决条件。
22.5.2. 先决条件 复制链接链接已复制到粘贴板!
在开始以下流程前,管理员必须:
- 设置集群联网环境的外部端口,使请求能够到达集群。
确定至少有一个用户具有集群管理员角色。要将此角色添加到用户,请运行以下命令:
oc adm policy add-cluster-role-to-user cluster-admin username
$ oc adm policy add-cluster-role-to-user cluster-admin usernameCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 有一个 OpenShift Container Platform 集群,其至少有一个 master 和至少一个节点,并且集群外有一个对集群具有网络访问权限的系统。此流程假设外部系统与集群位于同一个子网。不同子网上外部系统所需要的额外联网不在本主题的讨论范围内。
22.5.3. 创建项目和服务 复制链接链接已复制到粘贴板!
如果要公开的项目和服务不存在,请创建项目,然后创建该服务。
如果项目和服务都已存在,跳到公开服务以创建路由这一步。
先决条件
-
安装 OpenShift CLI (
oc),并以集群管理员身份登录。
流程
运行
oc new-project命令为您的服务创建一个新项目:oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc new-app命令来创建服务:oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证该服务是否已创建,请运行以下命令:
oc get svc -n <project_name>
$ oc get svc -n <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意默认情况下,新服务没有外部 IP 地址。
22.5.4. 通过创建路由公开服务 复制链接链接已复制到粘贴板!
您可以使用 oc expose 命令,将服务公开为路由。
先决条件
- 已登陆到 OpenShift Container Platform。
流程
登录您想公开的服务所在的项目:
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
oc expose service命令以公开路由:oc expose service nodejs-ex
$ oc expose service nodejs-exCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
route.route.openshift.io/nodejs-ex exposed
route.route.openshift.io/nodejs-ex exposedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证该服务是否已公开,您可以使用
curl等工具来检查该服务是否可从集群外部访问。要查找路由的主机名,请输入以下命令:
oc get route
$ oc get routeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要检查主机是否响应 GET 请求,请输入以下命令:
curl命令示例curl --head nodejs-ex-myproject.example.com
$ curl --head nodejs-ex-myproject.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
HTTP/1.1 200 OK ...
HTTP/1.1 200 OK ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.5.5. 创建负载均衡器服务 复制链接链接已复制到粘贴板!
使用以下流程来创建负载均衡器服务。
先决条件
- 确保您要公开的项目和服务已经存在。
- 您的云供应商支持负载均衡器。
流程
创建负载均衡器服务:
- 登录 OpenShift Container Platform。
加载您要公开的服务所在的项目。
oc project project1
$ oc project project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 control plane 节点上打开文本文件并粘贴以下文本,根据需要编辑该文件:
负载均衡器配置文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意要将通过负载均衡器的流量限制到特定的 IP 地址,建议使用 Ingress Controller 字段
spec.endpointPublishingStrategy.loadBalancer.allowedSourceRanges。不要设置loadBalancerSourceRanges字段。- 保存并退出 文件。
运行以下命令来创建服务:
oc create -f <file-name>
$ oc create -f <file-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
oc create -f mysql-lb.yaml
$ oc create -f mysql-lb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 执行以下命令以查看新服务:
oc get svc
$ oc get svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE egress-2 LoadBalancer 172.30.22.226 ad42f5d8b303045-487804948.example.com 3306:30357/TCP 15m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE egress-2 LoadBalancer 172.30.22.226 ad42f5d8b303045-487804948.example.com 3306:30357/TCP 15mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果启用了云供应商,该服务会自动分配到一个外部 IP 地址。
在 master 上,使用 cURL 等工具来确保您可以通过公共 IP 地址访问该服务:
curl <public-ip>:<port>
$ curl <public-ip>:<port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
curl 172.29.121.74:3306
$ curl 172.29.121.74:3306Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此部分中的示例使用 MySQL 服务,这需要客户端应用程序。如果您得到一串字符并看到
Got packets out of order消息,则您已连接到该服务:如果您有 MySQL 客户端,请使用标准 CLI 命令登录:
mysql -h 172.30.131.89 -u admin -p
$ mysql -h 172.30.131.89 -u admin -pCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.6. 在 AWS 上配置集群入口流量 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了从集群外部与集群中运行的服务进行通信的方法。此方法使用 AWS 上的负载均衡器,特别是 Network Load Balancer(NLB)或 Classic Load Balancer(CLB)。两种负载均衡器都可以将客户端的 IP 地址转发到节点,但 CLB 需要支持代理协议(OpenShift Container Platform 会自动启用)。
将 Ingress Controller 配置为使用 NLB 的方法有两种:
-
通过强制替换当前使用 CLB 的 Ingress Controller。这会删除
IngressController对象,并在新的 DNS 记录传播并置备 NLB 时发生停机。 -
通过编辑使用 CLB 的现有 Ingress Controller 以使用 NLB。这会更改负载均衡器而无需删除并重新创建
IngressController对象。
两种方法都可用于从 NLB 切换到 CLB。
您可以在新的或现有 AWS 集群上配置这些负载均衡器。
22.6.1. 在 AWS 中配置 Classic Load Balancer 超时 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了为特定路由或 Ingress Controller 设置自定义超时时间的方法。另外,AWS Classic Load Balancer(CLB)都有自己的超时时间,默认的超时时间为 60 秒。
如果 CLB 的超时时间小于路由超时或 Ingress Controller 超时,负载均衡器可以预先终止连接。您可以通过增加路由和 CLB 的超时周期来防止此问题。
22.6.1.1. 配置路由超时 复制链接链接已复制到粘贴板!
如果您的服务需要低超时(满足服务级别可用性 (SLA) 目的)或高超时(具有慢速后端的情况),您可以为现有路由配置默认超时。
如果您在 OpenShift Container Platform 集群前面配置了用户管理的外部负载均衡器,请确保用户管理的外部负载均衡器的超时值高于路由的超时值。此配置可防止集群使用的网络的网络出现网络拥塞问题。
前提条件
- 您需要在运行的集群中部署了 Ingress Controller。
流程
使用
oc annotate命令,为路由添加超时:oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>$ oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 支持的时间单位是微秒 (us)、毫秒 (ms)、秒钟 (s)、分钟 (m)、小时 (h)、或天 (d)。
以下示例在名为
myroute的路由上设置两秒的超时:oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.6.1.2. 配置 Classic Load Balancer 超时 复制链接链接已复制到粘贴板!
您可以为 Classic Load Balancer(CLB)配置默认超时来扩展闲置连接。
先决条件
- 您必须在正在运行的集群中部署了 Ingress Controller。
流程
运行以下命令,为默认的
ingresscontroller设置 AWS 连接闲置超时:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:运行以下命令来恢复超时的默认值:
oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"loadBalancer":{"providerParameters":{"aws":{"classicLoadBalancer": \ {"connectionIdleTimeout":null}}}}}}}'$ oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"loadBalancer":{"providerParameters":{"aws":{"classicLoadBalancer": \ {"connectionIdleTimeout":null}}}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在更改连接超时值时,您必须指定 scope 字段,除非已经设置了当前范围。设置 scope 字段时,如果恢复默认的超时值,则不需要再次这样做。
22.6.2. 使用网络负载平衡器在 AWS 上配置集群入口流量 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了从集群外部与集群中运行的服务进行通信的方法。一个这样的方法是使用 Network Load Balancer(NLB)。您可以在新的或现有 AWS 集群上配置 NLB。
您可以将使用 Classic Load Balancer (CLB) 的 Ingress Controller 切换到使用 AWS 上的网络负载平衡器 (NLB) 的 Ingress Controller。
在这些负载均衡器间切换不会删除 IngressController 对象。
此过程可能会导致以下问题:
- 由于新的 DNS 记录传播、新的负载均衡器置备和其他因素而可能需要几分钟的中断。应用此步骤后,Ingress Controller 负载均衡器的 IP 地址和规范名称可能会改变。
- 由于服务注解的变化,会泄漏负载均衡器资源。
流程
修改您要使用 NLB 切换到的现有 Ingress Controller。这个示例假定您的默认 Ingress Controller 具有
外部范围,且没有其他自定义:ingresscontroller.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果您没有为
spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.type字段指定值,Ingress Controller 会使用在安装过程中设置的集群Ingress配置中的spec.loadBalancer.platform.aws.type值。提示如果您的 Ingress Controller 有其他要更新的自定义(如更改域),请考虑强制替换 Ingress Controller 定义文件。
运行以下命令,将更改应用到 Ingress Controller YAML 文件:
oc apply -f ingresscontroller.yaml
$ oc apply -f ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 当 Ingress Controller 更新时,可能会有几分钟的停机。
在 AWS 中,您可以将使用 Network Load Balancer (NLB) 的 Ingress Controller 切换到使用 Classic Load Balancer (CLB) 的 Ingress Controller。
在这些负载均衡器间切换不会删除 IngressController 对象。
此流程会导致预期的中断会因为新的 DNS 记录传播、新的负载均衡器置备和其他因素而可能需要几分钟。应用此步骤后,Ingress Controller 负载均衡器的 IP 地址和规范名称可能会改变。
流程
修改您要切换为使用 CLB 的现有 Ingress Controller。这个示例假定您的默认 Ingress Controller 具有
外部范围,且没有其他自定义:ingresscontroller.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果您没有为
spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.type字段指定值,Ingress Controller 会使用在安装过程中设置的集群Ingress配置中的spec.loadBalancer.platform.aws.type值。提示如果您的 Ingress Controller 有其他要更新的自定义(如更改域),请考虑强制替换 Ingress Controller 定义文件。
运行以下命令,将更改应用到 Ingress Controller YAML 文件:
oc apply -f ingresscontroller.yaml
$ oc apply -f ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 当 Ingress Controller 更新时,可能会有几分钟的停机。
您可以将使用 Classic 负载平衡器(CLB)的 Ingress Controller 替换为 AWS 上使用网络负载平衡器(NLB)的 Ingress Controller。
此过程可能会导致以下问题:
- 由于新的 DNS 记录传播、新的负载均衡器置备和其他因素而可能需要几分钟的中断。应用此步骤后,Ingress Controller 负载均衡器的 IP 地址和规范名称可能会改变。
- 由于服务注解的变化,会泄漏负载均衡器资源。
流程
创建一个新的默认 Ingress Controller 文件。以下示例假定您的默认 Ingress Controller 具有
外部范围,且没有其他自定义:ingresscontroller.yml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您的默认 Ingress Controller 有其他自定义,请确定您相应地修改该文件。
提示如果您的 Ingress Controller 没有其他自定义,且您只更新负载均衡器类型,请考虑 "Switch the Ingress Controller from using an Classic Load Balancer to a Network Load Balancer" 中详述的步骤。
强制替换 Ingress Controller YAML 文件:
oc replace --force --wait -f ingresscontroller.yml
$ oc replace --force --wait -f ingresscontroller.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 等待 Ingress Controller 已被替换。预计会有几分钟的停机时间。
22.6.2.4. 在现有 AWS 集群上配置 Ingress Controller 网络负载均衡器 复制链接链接已复制到粘贴板!
您可以在当前集群中创建一个由 AWS Network Load Balancer(NLB)支持的 Ingress Controller。
先决条件
- 您必须已安装 AWS 集群。
基础架构资源的
PlatformStatus需要是 AWS。要验证
PlatformStatus是否为 AWS,请运行:oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.type}'$ oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.type}' AWSCopy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
在现有集群中,创建一个由 AWS NLB 支持的 Ingress Controller。
创建 Ingress Controller 清单:
cat ingresscontroller-aws-nlb.yaml
$ cat ingresscontroller-aws-nlb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在集群中创建资源:
oc create -f ingresscontroller-aws-nlb.yaml
$ oc create -f ingresscontroller-aws-nlb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
在新 AWS 集群上配置 Ingress Controller NLB 之前,您必须完成 创建安装配置文件的步骤。
22.6.2.5. 在新 AWS 集群上配置 Ingress Controller 网络负载平衡 复制链接链接已复制到粘贴板!
您可在新集群中创建一个由 AWS Network Load Balancer(NLB)支持的 Ingress Controller。
先决条件
-
创建
install-config.yaml文件并完成对其所做的任何修改。
流程
在新集群中,创建一个由 AWS NLB 支持的 Ingress Controller。
进入包含安装程序的目录并创建清单:
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 对于
<installation_directory>,请指定含有集群的install-config.yaml文件的目录的名称。
在
<installation_directory>/manifests/目录中创建一个名为cluster-ingress-default-ingresscontroller.yaml的文件:touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 对于
<installation_directory>,请指定包含集群的manifests/目录的目录名称。
创建该文件后,几个网络配置文件位于
manifests/目录中,如下所示:ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
cluster-ingress-default-ingresscontroller.yaml
cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在编辑器中打开
cluster-ingress-default-ingresscontroller.yaml文件,并输入描述您想要的 Operator 配置的自定义资源(CR):Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
保存
cluster-ingress-default-ingresscontroller.yaml文件并退出文本编辑器。 -
可选:备份
manifests/cluster-ingress-default-ingresscontroller.yaml文件。创建集群时,安装程序会删除manifests/目录。
22.7. 为服务外部 IP 配置 ingress 集群流量 复制链接链接已复制到粘贴板!
您可以使用 MetalLB 实现或 IP 故障转移部署,将 ExternalIP 资源附加到服务,以便该服务可用于 OpenShift Container Platform 集群外的流量。以这种方式托管外部 IP 地址仅适用于在裸机硬件上安装的集群。
您必须确保正确配置外部网络基础架构,将流量路由到该服务。
22.7.1. 先决条件 复制链接链接已复制到粘贴板!
您的集群被配置为启用了 ExternalIP。如需更多信息,请参阅为服务配置 ExternalIPs。
注意对于 egress IP,不要使用相同的 ExternalIP。
22.7.2. 将 ExternalIP 附加到服务 复制链接链接已复制到粘贴板!
您可以将 ExternalIP 资源附加到服务。如果您将集群配置为自动将资源附加到服务,您可能不需要手动将 ExternalIP 附加到该服务。
此流程中的示例使用 IP 故障转移配置手动将 ExternalIP 资源附加到集群中的服务。
流程
在 CLI 中输入以下命令来确认 ExternalIP 资源的兼容 IP 地址范围:
oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'$ oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果设置了
autoAssignCIDRs,且您没有在 ExternalIP 资源中为spec.externalIPs指定值,OpenShift Container Platform 会自动将 ExternalIP 分配给新的Service对象。选择以下选项之一将 ExternalIP 资源附加到服务:
如果要创建新服务,请在
spec.externalIPs字段中指定一个值,在allowedCIDRs参数中指定一个包括一个或多个有效 IP 地址的数组。支持 ExternalIP 资源的服务 YAML 配置文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您要将 ExternalIP 附加到现有服务中,请输入以下命令。将
<name>替换为服务名称。将<ip_address>替换为有效的 ExternalIP 地址。您可以提供多个以逗号分开的 IP 地址。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'$ oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
"mysql-55-rhel7" patched
"mysql-55-rhel7" patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
要确认一个 ExternalIP 地址已附加到该服务,请输入以下命令。如果为新服务指定 ExternalIP,您必须首先创建该服务。
oc get svc
$ oc get svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-55-rhel7 172.30.131.89 192.174.120.10 3306/TCP 13m
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-55-rhel7 172.30.131.89 192.174.120.10 3306/TCP 13mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.8. 使用 NodePort 配置集群入口流量 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了从集群外部与集群中运行的服务进行通信的方法。此方法使用了 NodePort。
22.8.1. 使用 NodePort 使流量进入集群 复制链接链接已复制到粘贴板!
使用 NodePort 类型的 Service 资源,在集群中所有节点的特定端口上公开服务。端口在 Service 资源的 .spec.ports[*].nodePort 字段中指定。
使用节点端口需要额外的端口资源。
NodePort 在节点 IP 地址的静态端口上公开服务。默认情况下,NodePort 在 30000 到 32767 的范围内,这意味着,NodePort 不可能与服务的预期端口匹配。例如:端口 8080 可能会在节点的端口 31020 中公开。
管理员必须确保外部 IP 地址路由到节点。
NodePort 和外部 IP 地址互相独立,可以同时使用它们。
这部分中的流程需要由集群管理员执行先决条件。
22.8.2. 先决条件 复制链接链接已复制到粘贴板!
在开始以下流程前,管理员必须:
- 设置集群联网环境的外部端口,使请求能够到达集群。
确定至少有一个用户具有集群管理员角色。要将此角色添加到用户,请运行以下命令:
oc adm policy add-cluster-role-to-user cluster-admin <user_name>
$ oc adm policy add-cluster-role-to-user cluster-admin <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 有一个 OpenShift Container Platform 集群,其至少有一个 master 和至少一个节点,并且集群外有一个对集群具有网络访问权限的系统。此流程假设外部系统与集群位于同一个子网。不同子网上外部系统所需要的额外联网不在本主题的讨论范围内。
22.8.3. 创建项目和服务 复制链接链接已复制到粘贴板!
如果要公开的项目和服务不存在,请创建项目,然后创建该服务。
如果项目和服务都已存在,跳到公开服务以创建路由这一步。
先决条件
-
安装 OpenShift CLI (
oc),并以集群管理员身份登录。
流程
运行
oc new-project命令为您的服务创建一个新项目:oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc new-app命令来创建服务:oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证该服务是否已创建,请运行以下命令:
oc get svc -n <project_name>
$ oc get svc -n <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意默认情况下,新服务没有外部 IP 地址。
22.8.4. 通过创建路由公开服务 复制链接链接已复制到粘贴板!
您可以使用 oc expose 命令,将服务公开为路由。
先决条件
- 已登陆到 OpenShift Container Platform。
流程
登录您想公开的服务所在的项目:
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要为应用程序公开节点端口,请输入以下命令修改服务的自定义资源定义 (CRD):
oc edit svc <service_name>
$ oc edit svc <service_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可选: 要使用公开的节点端口确认该服务可用,请输入以下命令:
oc get svc -n myproject
$ oc get svc -n myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.217.127 <none> 3306/TCP 9m44s nodejs-ex-ingress NodePort 172.30.107.72 <none> 3306:31345/TCP 39s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.217.127 <none> 3306/TCP 9m44s nodejs-ex-ingress NodePort 172.30.107.72 <none> 3306:31345/TCP 39sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选: 要删除由
oc new-app命令自动创建的服务,请输入以下命令:oc delete svc nodejs-ex
$ oc delete svc nodejs-exCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要检查服务节点端口是否已使用
30000-32767范围内的端口更新,请输入以下命令:oc get svc
$ oc get svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在以下示例输出中,更新的端口为
30327:输出示例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE httpd NodePort 172.xx.xx.xx <none> 8443:30327/TCP 109s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE httpd NodePort 172.xx.xx.xx <none> 8443:30327/TCP 109sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.9. 使用负载均衡器允许的源范围配置集群入口流量 复制链接链接已复制到粘贴板!
您可以为 IngressController 指定 IP 地址范围列表。这在 endpointPublishingStrategy 为 LoadBalancerService 时,限制访问负载均衡器服务。
22.9.1. 配置负载均衡器允许的源范围 复制链接链接已复制到粘贴板!
您可以启用并配置 spec.endpointPublishingStrategy.loadBalancer.allowedSourceRanges 字段。通过配置负载均衡器允许的源范围,您可以将 Ingress Controller 的负载均衡器的访问限制为指定的 IP 地址范围列表。Ingress Operator 协调负载均衡器服务,并根据 AllowedSourceRanges 设置 spec.loadBalancerSourceRanges 字段。
如果您已经在 OpenShift Container Platform 的早期版本中设置了 spec.loadBalancerSourceRanges 字段或负载均衡器服务 anotation service.beta.kubernetes.io/load-balancer-source-ranges,Ingress Controller 会在升级后开始报告 Progressing=True。要解决这个问题,设置覆盖 spec.loadBalancerSourceRanges 字段的 AllowedSourceRanges,并清除 service.beta.kubernetes.io/load-balancer-source-ranges 注解。Ingress Controller 开始报告 Progressing=False。
先决条件
- 您需要在正在运行的集群中部署了 Ingress Controller。
流程
运行以下命令,为 Ingress Controller 设置允许的源范围 API:
oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"type":"LoadBalancerService", "loadbalancer": \ {"scope":"External", "allowedSourceRanges":["0.0.0.0/0"]}}}}'$ oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"type":"LoadBalancerService", "loadbalancer": \ {"scope":"External", "allowedSourceRanges":["0.0.0.0/0"]}}}}'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 示例值
0.0.0.0/0指定允许的源范围。
22.9.2. 迁移到允许的源范围 复制链接链接已复制到粘贴板!
如果您已经设置了注解 service.beta.kubernetes.io/load-balancer-source-ranges,您可以迁移到允许负载均衡器的源范围。当您设置 AllowedSourceRanges 时,Ingress Controller 根据 AllowedSourceRanges 值设置 spec.loadBalancerSourceRanges 字段,并取消设置 service.beta.kubernetes.io/load-balancer-source-ranges 注解。
如果您已经在 OpenShift Container Platform 的早期版本中设置了 spec.loadBalancerSourceRanges 字段或负载均衡器服务 anotation service.beta.kubernetes.io/load-balancer-source-ranges,Ingress Controller 会在升级后开始报告 Progressing=True。要解决这个问题,设置覆盖 spec.loadBalancerSourceRanges 字段的 AllowedSourceRanges,并清除 service.beta.kubernetes.io/load-balancer-source-ranges 注解。Ingress Controller 再次开始报告 Progressing=False。
先决条件
-
您已设置了
service.beta.kubernetes.io/load-balancer-source-ranges注解。
流程
确保设置了
service.beta.kubernetes.io/load-balancer-source-ranges:oc get svc router-default -n openshift-ingress -o yaml
$ oc get svc router-default -n openshift-ingress -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/load-balancer-source-ranges: 192.168.0.1/32apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/load-balancer-source-ranges: 192.168.0.1/32Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确保
spec.loadBalancerSourceRanges字段已取消设置:oc get svc router-default -n openshift-ingress -o yaml
$ oc get svc router-default -n openshift-ingress -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
... spec: loadBalancerSourceRanges: - 0.0.0.0/0 ...
... spec: loadBalancerSourceRanges: - 0.0.0.0/0 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 将集群更新至 OpenShift Container Platform 4.16。
运行以下命令,为
ingresscontroller设置允许的源范围 API:oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"loadBalancer":{"allowedSourceRanges":["0.0.0.0/0"]}}}}'$ oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"loadBalancer":{"allowedSourceRanges":["0.0.0.0/0"]}}}}'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 示例值
0.0.0.0/0指定允许的源范围。
22.10. 修补现有入口对象 复制链接链接已复制到粘贴板!
您可以在不重新创建对象或中断服务的情况下更新或修改现有 Ingress 对象的以下字段:
- Specifications
- Host
- 路径
- 后端服务
- SSL/TLS 设置
- 注解
22.10.1. 修补 Ingress 对象以解析 ingressWithoutClassName 警报 复制链接链接已复制到粘贴板!
ingressClassName 字段指定 IngressClass 对象的名称。您必须为每个 Ingress 对象定义 ingressClassName 字段。
如果您还没有为 Ingress 对象定义 ingressClassName 字段,您可能会遇到路由问题。24 小时后,您将收到 ingressWithoutClassName 警报,以提醒您设置 ingressClassName 字段。
流程
使用完成的 ingressClassName 字段对 Ingress 对象进行补丁,以确保正确路由和功能。
列出所有
IngressClass对象:oc get ingressclass
$ oc get ingressclassCopy to Clipboard Copied! Toggle word wrap Toggle overflow 列出所有命名空间中的所有
Ingress对象:oc get ingress -A
$ oc get ingress -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 对
Ingress对象进行补丁:oc patch ingress/<ingress_name> --type=merge --patch '{"spec":{"ingressClassName":"openshift-default"}}'$ oc patch ingress/<ingress_name> --type=merge --patch '{"spec":{"ingressClassName":"openshift-default"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<ingress_name>替换为Ingress对象的名称。此命令对Ingress对象进行补丁,使其包含所需的入口类名称。
第 23 章 Kubernetes NMState 复制链接链接已复制到粘贴板!
23.1. 观察和更新节点网络状态和配置 复制链接链接已复制到粘贴板!
安装 Kubernetes NMState Operator 后,您可以使用 Operator 观察和更新集群的节点网络状态和网络配置。
有关如何安装 NMState Operator 的更多信息,请参阅 Kubernetes NMState Operator。
您无法修改现有的 网桥、OVN-Kubernetes 管理的 Open vSwitch 网桥或任何接口、绑定、VLAN 等。但是,您可以配置自定义 br-ex 网桥。
br-ex
如需更多信息,请参阅在裸机中部署安装程序置备的集群文档或在裸机中安装用户置备的集群 文档中的"创建包括自定义 br-ex 网桥的清单对象"。
23.1.1. 使用 CLI 查看节点的网络状态 复制链接链接已复制到粘贴板!
节点网络状态是集群中所有节点的网络配置。一个 NodeNetworkState 对象存在于集群中的每个节点上。此对象定期更新,并捕获该节点的网络状态。
流程
列出集群中的所有
NodeNetworkState对象:oc get nns
$ oc get nnsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
NodeNetworkState对象以查看该节点上的网络。为了清楚,这个示例中的输出已被重新编辑:oc get nns node01 -o yaml
$ oc get nns node01 -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.1.2. 从 Web 控制台查看节点的网络状态 复制链接链接已复制到粘贴板!
作为管理员,您可以使用 OpenShift Container Platform Web 控制台观察 NodeNetworkState 资源和网络接口,并访问网络详情。
流程
进入到 Networking → NodeNetworkState。
在 NodeNetworkState 页面中,您可以查看
NodeNetworkState资源列表以及节点上创建的对应接口。您可以基于接口状态, 接口类型, 和 IP 进行过滤,或者使用基于条件名称或标签的搜索栏来缩小显示的NodeNetworkState资源范围。-
要访问
NodeNetworkState资源的详细信息,请点 Name 列中列出的NodeNetworkState资源名称。 -
要展开并查看
NodeNetworkState资源的 Network Details 部分,点 > 图标。或者,您也可以点 Network interface 列下的每个接口类型来查看网络详情。
23.1.3. NodeNetworkConfigurationPolicy 清单文件 复制链接链接已复制到粘贴板!
NodeNetworkConfigurationPolicy (NNCP)清单文件定义 Kubernetes NMState Operator 用来为 OpenShift Container Platform 集群中存在的节点配置网络的策略。
如果要将多个 NNCP CR 应用到节点,您必须按照策略名称字母排序的逻辑顺序创建 NNCP。Kubernetes NMState Operator 持续检查新创建的 NNCP CR,以便 Operator 可立即将 CR 应用到节点。请考虑以下逻辑顺序问题示例:
-
您可以创建 NNCP 1 来定义侦听 VLAN 端口的网桥接口,如
eth1.1000。 -
您可以创建 NNCP 2 来定义 VLAN 接口并为此接口指定端口,如
eth1.1000。 - 在将 NNCP 2 应用到节点前,请应用 NNCP 1。
节点会遇到节点连接问题,因为端口 eth1.1000 不存在。因此,集群会失败。
将节点网络策略应用到节点后,Kubernetes NMState Operator 根据节点网络策略详情配置节点的网络配置。
您可以使用 OpenShift CLI (oc)或 OpenShift Container Platform Web 控制台创建 NNCP。作为安装后任务,您可以创建 NNCP 或编辑现有的 NNCP。
在创建 NNCP 之前,请确保读取"示例不同接口的策略配置"文档。
如果要删除 NNCP,您可以使用 oc delete nncp 命令完成此操作。但是,此命令不会删除任何对象,如网桥接口。
删除向节点添加接口的节点网络策略不会更改节点上的策略配置。同样,删除接口不会删除策略,因为 Kubernetes NMState Operator 会在 pod 或节点重启时重新创建删除的接口。
要有效地删除 NNCP、节点网络策略和任何接口通常需要以下操作:
-
编辑 NNCP 并从文件中删除接口详情。确保您没有从文件中删除
name,state, 和type参数。 -
在 NNCP 的
interfaces.state部分下添加state: absent。 -
运行
oc apply -f <nncp_file_name>。在 Kubernetes NMState Operator 将节点网络策略应用到集群中的每个节点后,每个节点中存在的任何接口现在都会标记为 absent。 -
运行
oc delete nncp以删除 NNCP。
23.1.5. 从 Web 控制台管理策略 复制链接链接已复制到粘贴板!
您可以通过将 NodeNetworkConfigurationPolicy 清单应用到集群来更新节点网络的配置,如为节点添加或删除接口。通过访问 Networking 菜单下的 NodeNetworkConfigurationPolicy 页面中创建的策略列表,从 web 控制台管理策略。通过此页面,您可以创建、更新、监控和删除策略。
23.1.5.1. 监控策略状态 复制链接链接已复制到粘贴板!
您可以在 NodeNetworkConfigurationPolicy 页面中监控策略状态。本页以表格格式显示集群中创建的所有策略,其列如下:
- Name
- 创建的策略的名称。
- 匹配的节点
- 应用策略的节点计数。这可能是基于节点选择器或集群中的所有节点的节点子集。
- 节点网络状态
- 匹配节点的 Enactment 状态。您可以点 enactment 状态并查看状态的详细信息。
要查找所需的策略,您可以使用 Filter 选项或搜索选项根据 enactment 状态过滤列表。
23.1.5.2. 创建策略 复制链接链接已复制到粘贴板!
您可以使用 web 控制台中的表单或 YAML 创建策略。
流程
- 进入到 Networking → NodeNetworkConfigurationPolicy。
在 NodeNetworkConfigurationPolicy 页面中,点 Create,然后选择 From Form 选项。
如果没有现有策略,您可以使用表单点 Create NodeNetworkConfigurationPolicy 来创建策略。
注意要使用 YAML 创建策略,请点 Create,然后选择 With YAML 选项。以下步骤仅适用于使用表单创建策略。
- 可选:选择 Apply this NodeNetworkConfigurationPolicy only to specific subsets of nodes using the node selector 复选框,以指定必须应用策略的节点。
- 在 Policy name 字段中输入策略名称。
- 可选:在 Description 字段中输入策略的描述。
可选:在 Policy Interface (s) 部分中,默认添加了一个桥接接口,带有可编辑的字段中的预设置值。通过执行以下步骤来编辑值:
- 在 Interface name 字段中输入接口名称。
- 从 Network 状态下拉菜单中选择网络状态。默认选择的值是 Up。
从类型下拉菜单中选择接口类型。可用的值包括 Bridge, Bonding, 和 Ethernet。默认选择的值是 Bridge。
注意不支持使用表单添加 VLAN 接口。要添加 VLAN 接口,您必须使用 YAML 来创建策略。添加后,您无法使用表单编辑策略。
可选: 在 IP 配置部分中,选中 IPv4 复选框,为接口分配 IPv4 地址,并配置 IP 地址分配详情:
- 点IP 地址,将接口配置为使用静态 IP 地址;或点 DHCP 将接口配置为自动分配 IP 地址。
如果您选择了 IP 地址 选项,在 IPV4 address 字段中输入 IPv4 地址,并在 Prefix length 字段中输入前缀长度。
如果您选择了 DHCP 选项,请取消选择您要禁用的选项。可用选项包括 Auto-DNS、Auto-routes 和 Auto-gateway。所有选项都被默认选择。
- 可选:在 Port 字段中输入端口号。
- 可选: 选中启用 STP复选框以启用 STP。
- 可选: 要为策略添加一个接口,点 Add another interface to the policy。
- 可选: 要从策略中删除接口,点接口旁的 图标。
注意或者,您可以点页面顶部的 Edit YAML 继续使用 YAML 编辑表单。
- 点 Create 以完成策略创建。
23.1.6. 更新策略 复制链接链接已复制到粘贴板!
23.1.6.1. 使用表单更新策略 复制链接链接已复制到粘贴板!
流程
- 进入到 Networking → NodeNetworkConfigurationPolicy。
-
在 NodeNetworkConfigurationPolicy 页中,点您要编辑的策略旁的
图标,然后点 Edit。
- 编辑您要更新的字段。
- 点击 Save。
不支持使用表单添加 VLAN 接口。要添加 VLAN 接口,您必须使用 YAML 来创建策略。添加后,您无法使用表单编辑策略。
23.1.6.2. 使用 YAML 更新策略 复制链接链接已复制到粘贴板!
流程
- 进入到 Networking → NodeNetworkConfigurationPolicy。
- 在 NodeNetworkConfigurationPolicy 页面中,点您要编辑的策略的 Name 列下的策略名称。
- 点 YAML 选项卡,并编辑 YAML。
- 点击 Save。
23.1.6.3. 删除策略 复制链接链接已复制到粘贴板!
流程
- 进入到 Networking → NodeNetworkConfigurationPolicy。
-
在 NodeNetworkConfigurationPolicy 页面中,点您要删除的策略旁的
图标,然后点 Delete。
- 在弹出窗口中,输入策略名称以确认删除,然后点 Delete。
23.1.7. 使用 CLI 管理策略 复制链接链接已复制到粘贴板!
23.1.7.1. 在节点上创建接口 复制链接链接已复制到粘贴板!
通过将一个 NodeNetworkConfigurationPolicy (NNCP) 清单应用到集群来在集群的节点上创建一个接口。清单详细列出了请求的接口配置。
默认情况下,清单会应用到集群中的所有节点。要将接口只添加到特定的节点,在节点选择器上添加 spec: nodeSelector 参数和适当的 <key>:<value> 。
您可以同时配置多个支持 nmstate 节点。该配置适用于并行节点的 50%。如果网络连接失败,此策略可防止整个集群不可用。要将策略配置并行应用到集群的特定部分,请使用 NodeNetworkConfigurationPolicy 清单配置文件中的 maxUnavailable 参数。
如果您有两个节点,并且对这些节点应用了一个 NNCP 清单,其中 maxUnavailable 参数设置为 50%, 则一次只有一个节点可以接收 NNCP 配置。如果您引入一个额外的 NNCP 清单文件,其 maxUnavailable 参数设置为 50%,则这个 NCCP 独立于初始 NNCP。这意味着,如果 NNCP 清单对节点应用错误配置,则您无法保证集群有一半的功能。
流程
创建
NodeNetworkConfigurationPolicy清单。以下示例在所有 worker 节点上配置了一个 Linux 桥接并配置 DNS 解析器:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建节点网络策略:
oc apply -f br1-eth1-policy.yaml
$ oc apply -f br1-eth1-policy.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 节点网络配置策略清单的文件名。
23.1.9. 不同接口的策略配置示例 复制链接链接已复制到粘贴板!
在读取不同示例 NodeNetworkConfigurationPolicy (NNCP) 清单配置前,当您将策略应用到节点时请考虑以下因素,以便集群在其最佳性能条件下运行:
- 如果要将多个 NNCP CR 应用到节点,您必须按照策略名称字母排序的逻辑顺序创建 NNCP。Kubernetes NMState Operator 持续检查新创建的 NNCP CR,以便 Operator 可立即将 CR 应用到节点。
-
当您需要将策略应用到多个节点时,但只想为所有目标节点创建一个 NNCP,Kubernetes NMState Operator 会按顺序将策略应用到每个节点。您可以使用集群配置中的
maxUnavailable参数为目标节点设置策略应用程序的速度和覆盖范围。通过为参数设置一个较低的百分比值,您可以在中断只会影响接收策略应用程序的一小部分节点时,降低出现集群范围中断的风险。 -
如果您在两个 NNCP 清单中将
maxUnavailable参数设置为50%,策略配置覆盖会应用到集群中的 100% 节点。 - 当节点重启时,Kubernetes NMState Operator 无法控制它将策略应用到节点的顺序。Kubernetes NMState Operator 可能会按顺序应用相互独立的策略,这会导致网络对象降级。
- 考虑在单个策略中指定所有相关网络配置。
23.1.9.1. 示例:以太网接口节点网络配置策略 复制链接链接已复制到粘贴板!
通过将 NodeNetworkConfigurationPolicy 清单应用到集群,在集群的节点上配置以太网接口。
以下 YAML 文件是一个以太接口的清单示例。它包含了示例值,需要使用自己的信息替换。
23.1.9.2. 示例: Linux bridge interface 节点网络配置策略 复制链接链接已复制到粘贴板!
通过将一个 NodeNetworkConfigurationPolicy 清单应用到集群来在集群的节点上创建一个 Linux 网桥接口。
以下 YAML 文件是 Linux 网桥界面的清单示例。如果运行 playbook,其中会包含必须替换为您自己的信息的样本值。
23.1.9.3. 示例:VLAN 接口节点网络配置策略 复制链接链接已复制到粘贴板!
通过将一个 NodeNetworkConfigurationPolicy 清单应用到集群来在集群的节点上创建一个 VLAN 接口。
在单个 NodeNetworkConfigurationPolicy 清单中为节点的 VLAN 接口定义所有相关配置。例如,在同一 NodeNetworkConfigurationPolicy 清单中为节点定义 VLAN 接口和相关路由。
当节点重启时,Kubernetes NMState Operator 无法控制应用策略的顺序。因此,如果您将单独的策略用于相关的网络配置,Kubernetes NMState Operator 可能会按顺序应用这些策略,从而导致网络对象降级。
以下 YAML 文件是 VLAN 接口的清单示例。如果运行 playbook,其中会包含必须替换为您自己的信息的样本值。
23.1.9.4. 示例:绑定接口节点网络配置策略 复制链接链接已复制到粘贴板!
通过将一个 NodeNetworkConfigurationPolicy 清单应用到集群来在集群的节点上创建一个绑定接口。
OpenShift Container Platform 只支持以下绑定模式:
-
active-backup
-
balance-xor
-
802.3ad
不支持其他绑定模式。
balance-xor 和 802.3ad 绑定模式需要切换配置来建立"EtherChannel"或类似的端口分组。这两个模式还需要额外的负载均衡配置,具体取决于通过接口传递的流量的来源和目的地。active-backup 绑定模式不需要任何交换机配置。不支持其他绑定模式。
以下 YAML 文件是绑定接口的清单示例。如果运行 playbook,其中会包含必须替换为您自己的信息的样本值。
- 1
- 策略的名称。
- 2
- 可选: 如果没有包括
nodeSelector参数,策略会应用到集群中的所有节点。 - 3
- 这个示例使用
hostname节点选择器。 - 4
- 接口的名称。
- 5
- 可选:接口人类可读的接口描述。
- 6
- 接口的类型。这个示例创建了一个绑定。
- 7
- 创建后接口的请求状态。
- 8
- 可选:如果您不使用
dhcp,可以设置静态 IP,或让接口没有 IP 地址。 - 9
- 在这个示例中启用
ipv4。 - 10
- Bond 的驱动模式。这个示例使用
活跃的备份。 - 11
- 可选:本例使用 miimon 检查每 140ms 的绑定链接。
- 12
- 绑定中的下级节点 NIC。
- 13
- 可选:绑定的最大传输单元(MTU)。如果没有指定,其默认值为
1500。
23.1.9.5. 示例:二级绑定接口上的源负载均衡(SLB) 复制链接链接已复制到粘贴板!
您可以在二级绑定接口上运行 Open vSwitch (OVS) balance-slb 模式,以便将流量与主网络隔离。此管理流量的此配置为集群提供高可用性和流量分段功能。
以下 YAML 文件显示了二级绑定接口的清单示例。该文件包含示例值,您必须替换为您自己的信息。
23.1.9.6. 示例:同一节点网络配置策略中的多个接口 复制链接链接已复制到粘贴板!
您可以在相同的节点网络配置策略中创建多个接口。这些接口可以相互引用,允许您使用单个策略清单来构建和部署网络配置。
以下示例 YAML 文件在两个 NIC 和 VLAN 之间创建一个名为 bond10 的绑定,名为 bond10.103,它连接到绑定。
23.1.9.7. 示例:虚拟功能的节点网络配置策略(技术预览) 复制链接链接已复制到粘贴板!
通过应用 NodeNetworkConfigurationPolicy 清单,更新现有集群中的单根 I/O 虚拟化 (SR-IOV) 网络功能 (VF) 的主机网络设置。
为 SR-IOV 网络 VF 更新主机网络设置只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
您可以将 NodeNetworkConfigurationPolicy 清单应用到现有集群,以完成以下任务:
- 为 VF 配置 QoS 主机网络设置以优化性能。
- 为网络接口添加、删除或更新 VF。
- 管理 VF 绑定配置。
要在也通过 SR-IOV Network Operator 管理的物理功能上使用 NMState 更新 SR-IOV VF 的主机网络设置,您必须将相关 SriovNetworkNodePolicy 资源中的 externallyManaged 参数设置为 true。如需更多信息,请参阅附加资源部分。
以下 YAML 文件是一个清单示例,它为 VF 定义 QoS 策略。此文件包含必须替换为您自己的信息的样本值。
以下 YAML 文件是一个清单示例,它在 VF 上创建 VLAN 接口并将其添加到绑定的网络接口中。如果运行 playbook,其中会包含必须替换为您自己的信息的样本值。
23.1.9.8. 示例:带有 VRF 实例网络配置策略的网络接口 复制链接链接已复制到粘贴板!
通过应用 NodeNetworkConfigurationPolicy 自定义资源(CR)将虚拟路由和转发(VRF)实例与网络接口关联。
将 VRF 实例与网络接口关联只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
通过将 VRF 实例与网络接口关联,您可以支持流量隔离、独立路由决策和网络资源的逻辑分离。
在配置 Virtual Route Forwarding (VRF) 时,您必须将 VRF 值改为小于 1000 的表 ID,因为 OpenShift Container Platform 保留大于 1000 的值。
在裸机环境中,您可以使用 MetalLB 通过属于 VRF 实例的接口宣布负载均衡器服务。如需更多信息,请参阅附加资源部分。
以下 YAML 文件是一个将 VRF 实例与网络接口关联的示例。如果运行 playbook,其中会包含必须替换为您自己的信息的样本值。
23.1.10. 在节点上通过 InfiniBand 接口创建 IP 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform web 控制台中,您可以安装红帽认证的第三方 Operator,如 NVIDIA Network Operator,它支持 IP over InfiniBand (IPoIB) 模式。通常,您可以将第三方 Operator 与其他供应商基础架构搭配使用,以管理 OpenShift Container Platform 集群中的资源。要在集群中的节点上创建 IPoIB 接口,您必须在 NodeNetworkConfigurationPolicy (NNCP) 清单文件中定义 InfiniBand (IPoIB) 接口。
如果您需要将 IPoIB 附加到绑定接口,只有 active-backup 模式支持此配置。
OpenShift Container Platform 文档只描述了在 NodeNetworkConfigurationPolicy (NNCP) 清单文件中定义 IPoIB 接口配置。对于大多数配置步骤,您必须参考 NVIDIA 和其他第三方供应商文档。红帽支持不会覆盖 NNCP 配置以外的任何内容。
如需有关 NVIDIA Operator 的更多信息,请参阅 Red Hat OpenShift (NVIDIA Docs Hub)入门。
先决条件
- 已安装支持 IPoIB 接口的红帽认证的第三方 Operator。
流程
创建或编辑
NodeNetworkConfigurationPolicy(NNCP)清单文件,然后在文件中指定 IPoIB 接口。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<mode>-
datagram是 IPoIB 接口的默认模式。此模式为 pod 到 pod 的通信提供了改进的 CPU 性能和低延迟。connected模式是一个受支持的模式,但只在需要调整最大传输单元(MTU)值时考虑使用这个模式,以提高与周围的网络设备的节点连接。 <pkey>-
支持字符串或整数值。参数定义保护密钥或 P-key,用于身份验证和与第三方供应商(如 NVIDIA)的加密通信。值
None和0xffff代表 InfiniBand 系统中基本接口的保护密钥。 <identifier>-
支持的值包括
name、默认值和mac-address。name值将配置应用到包含指定接口名称的接口。 <mac-address>- 保存接口的 MAC 地址。对于 IP-over-InfiniBand (IPoIB) 接口,地址为 20 字节字符串。
<type>-
将接口类型设置为
infiniband。
运行以下命令,将 NNCP 配置应用到集群中的每个节点。然后,Kubernetes NMState Operator 可以在每个节点上创建一个 IPoIB 接口。
$ oc apply -f <nncp_file_name>
$ oc apply -f <nncp_file_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<nncp_file_name>-
将
<nncp_file_name>替换为 NNCP 文件的名称。
23.1.11. 捕获附加到网桥的 NIC 的静态 IP 复制链接链接已复制到粘贴板!
捕获 NIC 的静态 IP 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
在集群的节点上创建一个 Linux 网桥接口,并通过将单个 NodeNetworkConfigurationPolicy 清单应用到集群来将 NIC 的静态 IP 配置传输到桥接。
以下 YAML 文件是 Linux 网桥界面的清单示例。它包含了示例值,需要使用自己的信息替换。
23.1.12. 示例:IP 管理 复制链接链接已复制到粘贴板!
以下配置片段示例演示了不同的 IP 管理方法。
这些示例使用 ethernet 接口类型来简化示例,同时显示 Policy 配置中相关的上下文。这些 IP 管理示例可与其他接口类型一起使用。
23.1.12.1. Static 复制链接链接已复制到粘贴板!
以下片段在以太网接口中静态配置 IP 地址:
- 1
- 使用接口的静态 IP 地址替换这个值。
23.1.12.2. 没有 IP 地址 复制链接链接已复制到粘贴板!
以下片段确保接口没有 IP 地址:
当您将 ipv4.enabled 和 ipv6.enabled 参数设置为 false 时,始终将 state 参数设置为 up,以禁用接口。如果使用此配置设置了 state: down,接口会因为自动 DHCP 分配而接收 DHCP IP 地址。
23.1.12.3. 动态主机配置 复制链接链接已复制到粘贴板!
以下片段配置了一个以太网接口,它使用动态 IP 地址、网关地址和 DNS:
以下片段配置了一个以太网接口,它使用动态 IP 地址,但不使用动态网关地址或 DNS:
23.1.12.4. 介质访问控制(MAC)地址 复制链接链接已复制到粘贴板!
您可以使用 MAC 地址来识别网络接口,而不使用网络接口的名称。网络接口名称可能会因为各种原因而改变,如操作系统配置更改。但是,每个网络接口都有一个不更改的唯一 MAC 地址。这意味着,使用 MAC 地址是更永久地识别特定网络接口的方法。
identifier 参数支持的值包括默认 name 值和 mac-address 值。name 值将配置应用到包含指定接口名称的接口。
将 mac-address 值用于 identifier 参数表示 MAC 地址是网络接口的标识符。如果将 identifier 值设置为 mac-address,则必须在以下 mac-address 参数字段中输入特定的 MAC 地址。
您仍然可以为 name 参数指定一个值,但设置 identifier: mac-address 值表示 MAC 地址用作网络接口的主标识符。如果您指定了不正确的 MAC 地址,nmstate 会报告无效的参数错误。
以下片段将 MAC 地址指定为名为 eth1 的以太网设备的主标识符,其 MAC 地址为 8A:8C:92:1A:F6:98 :
23.1.12.5. DNS 复制链接链接已复制到粘贴板!
默认情况下,nmstate API 会在全局范围内存储 DNS 值,而不是将其存储在网络接口中。在某些情况下,您必须配置网络接口来存储 DNS 值。
设置一个 DNS 配置与修改 /etc/resolv.conf 文件相当。
要为网络接口定义 DNS 配置,您必须首先在网络接口 YAML 配置文件中指定 dns-resolver 部分。要将 NNCP 配置应用到您的网络接口,您需要运行 oc apply -f <nncp_file_name> 命令。
以下示例显示了全局存储 DNS 值的默认情况:
配置没有网络接口的静态 DNS。请注意,当更新主机节点上的
/etc/resolv.conf文件时,您不需要在NodeNetworkConfigurationPolicy(NNCP)清单中指定一个接口 (IPv4 或 IPv6)。全局存储 DNS 值的网络接口的 DNS 配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要您可以在 NNCP 文件的
dns-resolver.config部分下指定 DNS 选项,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果要从网络接口中删除 DNS 选项,请将以下配置应用到 NNCP,然后运行
oc apply -f <nncp_file_name>命令:... ...
# ... dns-resolver: config: {} interfaces: [] # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下示例显示,配置一个网络接口来存储 DNS 值:
如果要将静态 DNS 名称服务器排名在动态 DNS 名称服务器上,请在网络接口 YAML 配置文件中定义运行动态主机配置协议(DHCP)或 IPv6 自动配置(
autoconf)机制的接口。将
192.0.2.1添加到从 DHCPv4 网络协议检索的 DNS 名称服务器中的示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您需要配置网络接口来存储 DNS 值,而不是使用默认方法(使用
nmstateAPI 在全局范围内存储 DNS 值),您可以在网络接口 YAML 文件中设置静态 DNS 值和静态 IP 地址。重要在网络接口级别上存储 DNS 值可能会导致名称解析问题,如 Open vSwitch (OVS) 网桥、Linux 网桥或绑定。
在接口级别存储 DNS 值的配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果要为您的网络接口设置静态 DNS 搜索域和静态 DNS 名称服务器,请在网络接口 YAML 配置文件中定义运行动态主机配置协议(DHCP)或 IPv6 自动配置(
autoconf)机制的静态接口。重要在网络接口 YAML 文件中指定以下
dns-resolver配置可能会导致重启出现竞争条件,以防止NodeNetworkConfigurationPolicy(NNCP)应用到集群中运行的 pod:- 为您的网络接口设置静态 DNS 搜索域和动态 DNS 名称服务器。
-
为搜索参数指定域后缀,而不为
server参数设置 IP 地址。
设置
example.com和example.org静态 DNS 搜索域以及静态 DNS 名称服务器设置的示例配置Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.1.13. 路由和路由规则 复制链接链接已复制到粘贴板!
在为网络接口配置 IP 地址后,您可以在 NMState 配置中为集群节点配置路由和路由规则。
在配置静态路由时,您无法使用 OVN-Kubernetes br-ex 网桥作为下一个跃点接口,除非您手动配置自定义的 br-ex 网桥。
如需更多信息,请参阅在裸机中部署安装程序置备的集群文档或在裸机中安装用户置备的集群 文档中的"创建包括自定义 br-ex 网桥的清单对象"。
routes 参数定义静态路由,这些路由决定离开网络接口的流量和流量的目标网络。支持的值包括 running 和 config。
在将 NMState 配置应用到集群节点后并希望更改现有路由,您需要使用 state: absent 参数指定旧路由,并使用 state: present 参数指定新路由。然后,NMState Operator 可以删除旧的路由,并将新路由应用到集群节点。
将 state 参数设置为 ignore 表示 Operator 会忽略某些路由。
route-rules 参数为集群节点实现基于策略的路由功能。此功能允许源自一个不同源 IP 地址的流量通过使用不同的网关和网络路径进行隔离和路由。
以下 YAML 配置显示了一个静态路由,以及接口 eth1 上的一个静态路由配置:
-
config.ip-from:为源自指定 IP 地址的任何网络数据包应用一个规则。 -
config.priority:为规则设置优先级顺序。 -
config.route-table:指定 Operator 用来检查网络流量是否与ip-from条件匹配的路由表。 -
address.ip:以太网接口的静态 IP 地址。 -
config.next-hop-address:节点流量的下一跳地址。这必须与为以太接口设定的 IP 地址位于同一个子网中。
23.2. 对节点网络配置进行故障排除 复制链接链接已复制到粘贴板!
如果节点网络配置遇到问题,则策略会自动回滚,且报告失败。这包括如下问题:
- 配置没有在主机上应用。
- 主机丢失了到默认网关的连接。
- 断开了与 API 服务器的连接。
23.2.1. 对不正确的节点网络配置策略配置进行故障排除 复制链接链接已复制到粘贴板!
您可以通过应用节点网络配置策略,对整个集群中的节点网络配置应用更改。
如果应用了不正确的配置,您可以使用以下示例进行故障排除并修正失败的节点网络策略。这个示例尝试将 Linux 网桥策略应用到具有三个 control plane 节点和三个计算节点的集群。策略不会被应用,因为策略会引用错误的接口。
要查找错误,您需要调查可用的 NMState 资源。然后您可以使用正确配置来更新策略。
先决条件
-
您确保 Linux 系统上不存在
ens01接口。
流程
在集群中创建策略。以下示例创建了一个简单的网桥
br1,它具有ens01作为其成员:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将策略应用到您的网络接口:
oc apply -f ens01-bridge-testfail.yaml
$ oc apply -f ens01-bridge-testfail.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
nodenetworkconfigurationpolicy.nmstate.io/ens01-bridge-testfail created
nodenetworkconfigurationpolicy.nmstate.io/ens01-bridge-testfail createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证策略的状态:
oc get nncp
$ oc get nncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示策略失败:
输出示例
NAME STATUS ens01-bridge-testfail FailedToConfigure
NAME STATUS ens01-bridge-testfail FailedToConfigureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仅有策略状态并不表示它在所有节点或某个节点子集中是否失败。
列出节点网络配置以查看策略在任意节点上是否成功。如果策略只在一组节点中失败,输出表示问题在于特定的节点配置。如果策略在所有节点上都失败,输出会认为问题在于策略。
oc get nnce
$ oc get nnceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示策略在所有节点上都失败:
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 查看失败的原因之一。以下命令使用输出工具
jsonpath来过滤输出结果:oc get nnce compute-1.ens01-bridge-testfail -o jsonpath='{.status.conditions[?(@.type=="Failing")].message}'$ oc get nnce compute-1.ens01-bridge-testfail -o jsonpath='{.status.conditions[?(@.type=="Failing")].message}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
[2024-10-10T08:40:46Z INFO nmstatectl] Nmstate version: 2.2.37 NmstateError: InvalidArgument: Controller interface br1 is holding unknown port ens01
[2024-10-10T08:40:46Z INFO nmstatectl] Nmstate version: 2.2.37 NmstateError: InvalidArgument: Controller interface br1 is holding unknown port ens01Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上例显示
InvalidArgument错误的输出,这表示ens01是一个未知端口。在本例中,您可能需要更改策略配置文件中的端口配置。要确保正确配置了策略,请求
NodeNetworkState来查看一个或多个节点的网络配置。以下命令返回control-plane-1节点的网络配置:oc get nns control-plane-1 -o yaml
$ oc get nns control-plane-1 -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示节点上的接口名称为
ens1,但失败的策略使用了ens01:输出示例
- ipv4: # ... name: ens1 state: up type: ethernet- ipv4: # ... name: ens1 state: up type: ethernetCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过编辑现有策略修正错误:
oc edit nncp ens01-bridge-testfail
$ oc edit nncp ens01-bridge-testfailCopy to Clipboard Copied! Toggle word wrap Toggle overflow # ... port: - name: ens1# ... port: - name: ens1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 保存策略以应用更正。
检查策略的状态,以确保它被成功更新:
oc get nncp
$ oc get nncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS ens01-bridge-testfail SuccessfullyConfigured
NAME STATUS ens01-bridge-testfail SuccessfullyConfiguredCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在集群中的所有节点上都成功配置了更新的策略。
23.2.2. 在断开连接的环境中的 DNS 连接问题故障排除 复制链接链接已复制到粘贴板!
如果您在断开连接的环境中配置 nmstate 时遇到 DNS 连接问题,您可以配置 DNS 服务器来解析域 root-servers.net 的名称服务器列表。
确保 DNS 服务器包含 root-servers.net 区域的名称服务器(NS)条目。DNS 服务器不需要将查询转发到上游解析器,但服务器必须为 NS 查询返回正确的回答。
23.2.2.1. 配置名为 server 的 bind9 DNS 复制链接链接已复制到粘贴板!
对于配置为查询 bind9 DNS 服务器的集群,您可以将 root-servers.net 区域添加到至少一个 NS 记录的配置文件。例如,您可以使用 /var/named/named.localhost 作为已匹配此条件的区域文件。
流程
运行以下命令,在
/etc/named.conf配置文件末尾添加root-servers.net区域:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令重启
named服务:systemctl restart named
$ systemctl restart namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令确认
root-servers.net区已存在:journalctl -u named|grep root-servers.net
$ journalctl -u named|grep root-servers.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Jul 03 15:16:26 rhel-8-10 bash[xxxx]: zone root-servers.net/IN: loaded serial 0 Jul 03 15:16:26 rhel-8-10 named[xxxx]: zone root-servers.net/IN: loaded serial 0
Jul 03 15:16:26 rhel-8-10 bash[xxxx]: zone root-servers.net/IN: loaded serial 0 Jul 03 15:16:26 rhel-8-10 named[xxxx]: zone root-servers.net/IN: loaded serial 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证 DNS 服务器是否可以解析
root-servers.net域的 NS 记录:host -t NS root-servers.net. 127.0.0.1
$ host -t NS root-servers.net. 127.0.0.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Using domain server: Name: 127.0.0.1 Address: 127.0.0.53 Aliases: root-servers.net name server root-servers.net.
Using domain server: Name: 127.0.0.1 Address: 127.0.0.53 Aliases: root-servers.net name server root-servers.net.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.2.2.2. 配置 dnsmasq DNS 服务器 复制链接链接已复制到粘贴板!
如果您使用 dnsmasq 作为 DNS 服务器,您可以将 root-servers.net 域的解析委派给另一个 DNS 服务器,例如,使用您指定的 DNS 服务器创建新配置文件来解析 root-servers.net。
运行以下命令,创建一个将域
root-servers.net委派给另一个 DNS 服务器的配置文件:echo 'server=/root-servers.net/<DNS_server_IP>'> /etc/dnsmasq.d/delegate-root-servers.net.conf
$ echo 'server=/root-servers.net/<DNS_server_IP>'> /etc/dnsmasq.d/delegate-root-servers.net.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令重启
dnsmasq服务:systemctl restart dnsmasq
$ systemctl restart dnsmasqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令确认
root-servers.net域已被委派给另一个 DNS 服务器:journalctl -u dnsmasq|grep root-servers.net
$ journalctl -u dnsmasq|grep root-servers.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Jul 03 15:31:25 rhel-8-10 dnsmasq[1342]: using nameserver 192.168.1.1#53 for domain root-servers.net
Jul 03 15:31:25 rhel-8-10 dnsmasq[1342]: using nameserver 192.168.1.1#53 for domain root-servers.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证 DNS 服务器是否可以解析
root-servers.net域的 NS 记录:host -t NS root-servers.net. 127.0.0.1
$ host -t NS root-servers.net. 127.0.0.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: root-servers.net name server root-servers.net.
Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: root-servers.net name server root-servers.net.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 24 章 配置集群范围代理 复制链接链接已复制到粘贴板!
生产环境可能会拒绝直接访问互联网,而是提供 HTTP 或 HTTPS 代理。您可以通过修改现有集群的 Proxy 对象或在新集群的 install-config.yaml 文件中配置代理设置,将 OpenShift Container Platform 配置为使用代理。
在支持的平台中为集群启用集群范围的出口代理后,Red Hat Enterprise Linux CoreOS (RHCOS)会使用支持的平台上存在的 install-config.yaml 文件中的 networking.machineNetwork[].cidr, networking.clusterNetwork[].cidr, 和 networking.serviceNetwork[] 字段的值填充 status.noProxy 参数。
作为安装后任务,您可以更改 networking.clusterNetwork[].cidr 值,但不能更改 networking.machineNetwork[].cidr 和 networking.serviceNetwork[] 值。如需更多信息,请参阅"配置集群网络范围"。
对于在 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和 Red Hat OpenStack Platform (RHOSP)上安装,status.noProxy 参数也会使用实例元数据端点 169.254.169.254 填充。
由 RHCOS 添加到 Proxy 对象的 status: 段中的值示例
如果您的安装类型不包括设置 networking.machineNetwork[].cidr 字段,则必须在 .status.noProxy 字段中手动包含机器 IP 地址,以确保节点之间的流量可以绕过代理。
24.1. 先决条件 复制链接链接已复制到粘贴板!
查看集群需要访问的站点中的内容,决定这些站点中的任何站点是否需要绕过代理。默认情况下,所有集群系统的出站流量都需经过代理,包括对托管集群的云供应商 API 的调用。系统范围的代理仅影响系统组件,而不会影响用户工作负载。如有必要,将站点添加到 Proxy 对象的 spec.noProxy 参数,以绕过代理。
24.2. 启用集群范围代理 复制链接链接已复制到粘贴板!
Proxy 对象用于管理集群范围出口代理。当在没有配置代理的情况下安装或升级集群时,仍会生成 Proxy 对象,但它有一个空的 spec。例如:
只支持名为 cluster 的 Proxy 对象,且无法创建额外的代理。
集群管理员可以通过修改这个 cluster Proxy 对象来配置 OpenShift Container Platform 的代理。
在为集群启用集群范围代理功能并保存 Proxy 对象文件后,Machine Config Operator (MCO) 会重启集群中的所有节点,以便每个节点可以访问集群外的连接。您不需要手动重新引导这些节点。
先决条件
- 有集群管理员权限。
-
已安装 OpenShift Container Platform
ocCLI 工具。
流程
创建包含代理 HTTPS 连接所需的额外 CA 证书的 ConfigMap。
注意如果代理的身份证书由 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包的颁发机构签名,您可以跳过这一步。
创建名为
user-ca-bundle.yaml的文件,并提供 PEM 编码证书的值:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令从
user-ca-bundle.yaml文件创建配置映射:oc create -f user-ca-bundle.yaml
$ oc create -f user-ca-bundle.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
使用
oc edit命令修改Proxy对象:oc edit proxy/cluster
$ oc edit proxy/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为代理配置所需的字段:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 用于创建集群外 HTTP 连接的代理 URL。URL 方案必须是
http。 - 2
- 用于创建集群外 HTTPS 连接的代理 URL。URL 方案必须是
http或https。指定支持 URL 方案的代理的 URL。例如,如果大多数代理被配置为使用https,则大多数代理都会报告错误,但它们只支持http。此失败消息可能无法传播到日志,并可能显示为网络连接失败。如果使用侦听来自集群的https连接的代理,您可能需要配置集群以接受代理使用的 CA 和证书。 - 3
- 要排除代理的目标域名、域、IP 地址(或其他网络 CIDR)和端口号的列表(以逗号分隔)。注意
只有在配置 IPv6 地址时,才支持端口号。配置 IPv4 地址时不支持端口号。
在域前面加
.来仅匹配子域。例如:.y.com匹配x.y.com,但不匹配y.com。使用*可对所有目的地绕过所有代理。如果您的
noproxy字段需要包含域地址,您必须在noproxy字段中明确指定该 FQDN 或前缀匹配子域。您不能使用封装域的 IP 地址或 CIDR 范围。这是因为集群不会在分配路由连接前等待 DNS 返回 IP 地址,并根据请求明确检查。例如,如果您有一个 CIDR 块值,如10.0.0.0/24,noproxy字段和字段尝试访问https://10.0.0.11,则地址可以成功匹配。但是,尝试访问https://exampleserver.externaldomain.com(其 A 记录条目为10.0.0.11)会失败。对于noproxy字段,还需要额外的.externaldomain.com值。如果您扩展了未包含在安装配置中
networking.machineNetwork[].cidr字段定义的计算节点,您必须将它们添加到此列表中,以防止连接问题。如果未设置
httpProxy或httpsProxy字段,则此字段将被忽略。 - 4
- 将
httpProxy和httpsProxy值写进状态之前,执行就绪度检查时要使用的一个或多个集群外部 URL。 - 5
- 引用
openshift-config命名空间中的 ConfigMap,其包含代理 HTTPS 连接所需的额外 CA 证书。注意 ConfigMap 必须已经存在,然后才能在这里引用它。此字段是必需的,除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。
- 保存文件以应用更改。
24.3. 删除集群范围代理服务器 复制链接链接已复制到粘贴板!
cluster Proxy 对象不能被删除。要从集群中删除代理,请删除 Proxy 对象的所有 spec 字段。
先决条件
- 集群管理员权限
-
已安装 OpenShift Container Platform
ocCLI 工具
流程
使用
oc edit命令来修改代理:oc edit proxy/cluster
$ oc edit proxy/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 Proxy 对象的所有
spec字段。例如:apiVersion: config.openshift.io/v1 kind: Proxy metadata: name: cluster spec: {}apiVersion: config.openshift.io/v1 kind: Proxy metadata: name: cluster spec: {}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存文件以使改变生效。
24.4. 验证集群范围代理配置 复制链接链接已复制到粘贴板!
部署集群范围代理配置后,您可以验证它是否按预期工作。按照以下步骤检查日志并验证实施。
先决条件
- 有集群管理员权限。
-
已安装 OpenShift Container Platform
ocCLI 工具。
流程
使用
oc命令检查代理配置状态:oc get proxy/cluster -o yaml
$ oc get proxy/cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
验证输出中的代理字段,以确保它们与您的配置匹配。具体来说,检查
spec.httpProxy,spec.httpsProxy,spec.noProxy, 和spec.trustedCA字段。 检查
Proxy对象的状态:oc get proxy/cluster -o jsonpath='{.status}'$ oc get proxy/cluster -o jsonpath='{.status}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查 Machine Config Operator (MCO) 的日志,以确保成功应用配置更改:
oc logs -n openshift-machine-config-operator $(oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o name)
$ oc logs -n openshift-machine-config-operator $(oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o name)Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 查找指示代理设置的消息,并在需要时重启节点。
通过检查发出外部请求的组件的日志来验证系统组件是否使用代理,如 Cluster Version Operator (CVO):
oc logs -n openshift-cluster-version $(oc get pods -n openshift-cluster-version -l k8s-app=machine-config-operator -o name)
$ oc logs -n openshift-cluster-version $(oc get pods -n openshift-cluster-version -l k8s-app=machine-config-operator -o name)Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 查找显示外部请求已通过代理路由的日志条目。
第 25 章 配置自定义 PKI 复制链接链接已复制到粘贴板!
有些平台组件,如 Web 控制台,使用 Routes 进行通信,且必须信任其他组件的证书与其交互。如果您使用的是自定义公钥基础架构 (PKI) ,您必须将其配置为在集群中识别其私有签名的 CA 证书。
您可以使用 Proxy API 添加集群范围的可信 CA 证书。您必须在安装过程中或运行时执行此操作。
在 安装过程 中,配置集群范围的代理。您需要在
install-config.yaml文件中的additionalTrustBundle设置中定义私有签名的 CA 证书。安装程序生成名为
user-ca-bundle的 ConfigMap,其中包含您定义的附加 CA 证书。然后,Cluster Network Operator 会创建trusted-ca-bundleConfigMap,将这些内容与 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包合并,Proxy 对象的trustedCA字段中也会引用此 ConfigMap。-
在运行时,,修改默认 Proxy 对象使其包含您私有签名的 CA 证书 (集群代理启用工作流程的一部分)。这涉及创建包含集群应信任的私有签名 CA 证书的 ConfigMap,然后使用
trustedCA引用私有签名证书的 ConfigMap 修改代理服务器资源。
安装程序配置的 additionalTrustBundle 字段和 proxy 资源的 trustedCA 字段被用来管理集群范围信任捆绑包; 在安装时会使用 additionalTrustBundle ,并在运行时使用代理的trustedCA。
trustedCA 字段是对包含集群组件使用的自定义证书和密钥对的 ConfigMap 的引用。
25.1. 在安装过程中配置集群范围的代理 复制链接链接已复制到粘贴板!
生产环境可能会拒绝直接访问互联网,而是提供 HTTP 或 HTTPS 代理。您可以通过在 install-config.yaml 文件中配置代理设置,将新的 OpenShift Container Platform 集群配置为使用代理。
先决条件
您检查了集群需要访问的站点,并确定它们中的任何站点是否需要绕过代理。默认情况下,所有集群出口流量都经过代理,包括对托管云供应商 API 的调用。如果需要,您将在
Proxy 对象的spec.noProxy字段中添加站点来绕过代理。注意Proxy对象status.noProxy字段使用安装配置中的networking.machineNetwork[].cidr、networking.clusterNetwork[].cidr和networking.serviceNetwork[]字段的值填充。对于在 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和 Red Hat OpenStack Platform (RHOSP)上安装,
Proxy对象status.noProxy字段也会填充实例元数据端点(169.254.169.254)。
流程
编辑
install-config.yaml文件并添加代理设置。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 用于创建集群外 HTTP 连接的代理 URL。URL 方案必须是
http。 - 2
- 用于创建集群外 HTTPS 连接的代理 URL。
- 3
- 要从代理中排除的目标域名、IP 地址或其他网络 CIDR 的逗号分隔列表。在域前面加
.来仅匹配子域。例如:.y.com匹配x.y.com,但不匹配y.com。使用*绕过所有目的地的代理。如果您已将 AmazonEC2、Elastic Load Balancing和S3VPC 端点添加到 VPC 中,您必须将这些端点添加到noProxy字段。 - 4
- 如果提供,安装程序会在
openshift-config命名空间中生成名为user-ca-bundle的配置映射,其包含代理 HTTPS 连接所需的一个或多个额外 CA 证书。然后,Cluster Network Operator 会创建trusted-ca-bundle配置映射,将这些内容与 Red Hat Enterprise Linux CoreOS(RHCOS)信任捆绑包合并,Proxy对象的trustedCA字段中也会引用此配置映射。additionalTrustBundle字段是必需的,除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。 - 5
- 可选:决定
Proxy对象的配置以引用trustedCA字段中user-ca-bundle配置映射的策略。允许的值是Proxyonly和Always。仅在配置了http/https代理时,使用Proxyonly引用user-ca-bundle配置映射。使用Always始终引用user-ca-bundle配置映射。默认值为Proxyonly。
注意安装程序不支持代理的
readinessEndpoints字段。注意如果安装程序超时,重启并使用安装程序的
wait-for命令完成部署。例如:./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存该文件并在安装 OpenShift Container Platform 时引用。
安装程序会创建一个名为 cluster 的集群范围代理,该代理 使用 提供的 install-config.yaml 文件中的代理设置。如果没有提供代理设置,仍然会创建一个 cluster Proxy 对象,但它会有一个空 spec。
只支持名为 cluster 的 Proxy 对象,且无法创建额外的代理。
25.2. 启用集群范围代理 复制链接链接已复制到粘贴板!
Proxy 对象用于管理集群范围出口代理。当在没有配置代理的情况下安装或升级集群时,仍会生成 Proxy 对象,但它有一个空的 spec。例如:
只支持名为 cluster 的 Proxy 对象,且无法创建额外的代理。
集群管理员可以通过修改这个 cluster Proxy 对象来配置 OpenShift Container Platform 的代理。
在为集群启用集群范围代理功能并保存 Proxy 对象文件后,Machine Config Operator (MCO) 会重启集群中的所有节点,以便每个节点可以访问集群外的连接。您不需要手动重新引导这些节点。
先决条件
- 有集群管理员权限。
-
已安装 OpenShift Container Platform
ocCLI 工具。
流程
创建包含代理 HTTPS 连接所需的额外 CA 证书的 ConfigMap。
注意如果代理的身份证书由 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包的颁发机构签名,您可以跳过这一步。
创建名为
user-ca-bundle.yaml的文件,并提供 PEM 编码证书的值:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令从
user-ca-bundle.yaml文件创建配置映射:oc create -f user-ca-bundle.yaml
$ oc create -f user-ca-bundle.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
使用
oc edit命令修改Proxy对象:oc edit proxy/cluster
$ oc edit proxy/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为代理配置所需的字段:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 用于创建集群外 HTTP 连接的代理 URL。URL 方案必须是
http。 - 2
- 用于创建集群外 HTTPS 连接的代理 URL。URL 方案必须是
http或https。指定支持 URL 方案的代理的 URL。例如,如果大多数代理被配置为使用https,则大多数代理都会报告错误,但它们只支持http。此失败消息可能无法传播到日志,并可能显示为网络连接失败。如果使用侦听来自集群的https连接的代理,您可能需要配置集群以接受代理使用的 CA 和证书。 - 3
- 要排除代理的目标域名、域、IP 地址(或其他网络 CIDR)和端口号的列表(以逗号分隔)。注意
只有在配置 IPv6 地址时,才支持端口号。配置 IPv4 地址时不支持端口号。
在域前面加
.来仅匹配子域。例如:.y.com匹配x.y.com,但不匹配y.com。使用*可对所有目的地绕过所有代理。如果您的
noproxy字段需要包含域地址,您必须在noproxy字段中明确指定该 FQDN 或前缀匹配子域。您不能使用封装域的 IP 地址或 CIDR 范围。这是因为集群不会在分配路由连接前等待 DNS 返回 IP 地址,并根据请求明确检查。例如,如果您有一个 CIDR 块值,如10.0.0.0/24,noproxy字段和字段尝试访问https://10.0.0.11,则地址可以成功匹配。但是,尝试访问https://exampleserver.externaldomain.com(其 A 记录条目为10.0.0.11)会失败。对于noproxy字段,还需要额外的.externaldomain.com值。如果您扩展了未包含在安装配置中
networking.machineNetwork[].cidr字段定义的计算节点,您必须将它们添加到此列表中,以防止连接问题。如果未设置
httpProxy或httpsProxy字段,则此字段将被忽略。 - 4
- 将
httpProxy和httpsProxy值写进状态之前,执行就绪度检查时要使用的一个或多个集群外部 URL。 - 5
- 引用
openshift-config命名空间中的 ConfigMap,其包含代理 HTTPS 连接所需的额外 CA 证书。注意 ConfigMap 必须已经存在,然后才能在这里引用它。此字段是必需的,除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。
- 保存文件以使改变生效。
25.3. 使用 Operator 进行证书注入 复制链接链接已复制到粘贴板!
在您的自定义 CA 证书通过 ConfigMap 添加到集群中后,Cluster Network Operator 会将用户提供的证书和系统 CA 证书合并到单一捆绑包中,并将合并的捆绑包注入请求信任捆绑包注入的 Operator。
在配置映射中添加 config.openshift.io/inject-trusted-cabundle="true" 标签后,会删除其中的现有数据。Cluster Network Operator 获取配置映射的所有权,并只接受 ca-bundle 作为数据。您必须使用单独的配置映射存储 service-ca.crt,方法是使用 service.beta.openshift.io/inject-cabundle=true 注解或类似的配置。在同一配置映射中添加 config.openshift.io/inject-trusted-cabundle="true" 标签和 service.beta.openshift.io/inject-cabundle=true 注解可能会导致问题。
Operator 通过创建一个带有以下标签的空 ConfigMap 来请求此注入:
config.openshift.io/inject-trusted-cabundle="true"
config.openshift.io/inject-trusted-cabundle="true"
空 ConfigMap 示例:
- 1
- 指定空 ConfigMap 名称。
Operator 将这个 ConfigMap 挂载到容器的本地信任存储中。
只有在 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包中没有包括证书时才需要添加可信的 CA 证书。
证书注入不仅限于 Operator。当使用 config.openshift.io/inject-trusted-cabundle=true标记(label) 创建一个空的 ConfigMap 时,Cluster Network Operator会跨命名空间注入证书 。
ConfigMap 可以驻留在任何命名空间中,但 ConfigMap 必须作为卷挂载到需要自定义 CA 的 Pod 中的每个容器。例如:
第 26 章 RHOSP 负载均衡 复制链接链接已复制到粘贴板!
26.1. 负载均衡器服务的限制 复制链接链接已复制到粘贴板!
Red Hat OpenStack Platform (RHOSP) 上的 OpenShift Container Platform 集群使用 Octavia 来处理负载均衡器服务。因此,此类集群有很多功能限制。
RHOSP Octavia 有两个支持的供应商: Amphora 和 OVN。这些供应商在可用功能以及实施详情方面有所不同。这些差异会影响在集群中创建的负载均衡器服务。
26.1.1. 本地外部流量策略 复制链接链接已复制到粘贴板!
您可以在负载均衡器服务上设置外部流量策略 (ETP) 参数 .spec.externalTrafficPolicy,以在到达服务端点 pod 时保留传入流量的源 IP 地址。但是,如果您的集群使用 Amphora Octavia 供应商,流量的源 IP 将替换为 Amphora 虚拟机的 IP 地址。如果您的集群使用 OVN Octavia 供应商,则不会发生此行为。
将 ETP 选项设置为 Local 需要为负载均衡器创建运行状况监控器。如果没有健康监控器,流量可以路由到没有功能端点的节点,这会导致连接丢弃。要强制 Cloud Provider OpenStack 创建运行状况监视器,您必须将云供应商配置中的 create-monitor 选项的值设置为 true。
在 RHOSP 16.2 中,OVN Octavia 供应商不支持健康监控器。因此,不支持将 ETP 设置为 local。
在 RHOSP 16.2 中,Amphora Octavia 供应商不支持 UDP 池中的 HTTP 监视器。因此,UDP 负载均衡器服务会改为创建 UDP-CONNECT 监视器。由于实现详情,此配置只能使用 OVN-Kubernetes CNI 插件正常工作。当使用 OpenShift SDN CNI 插件时,UDP 服务会变得不可靠。这个问题也会影响任何 RHOSP 版本中的 OVN Octavia 供应商,因为驱动程序不支持 HTTP 健康监控器。
26.2. 使用 Octavia 为应用程序流量扩展集群 复制链接链接已复制到粘贴板!
在 Red Hat OpenStack Platform(RHOSP)上运行的 OpenShift Container Platform 集群可以使用 Octavia 负载均衡服务在多个虚拟机(VM)或浮动 IP 地址间分配流量。这个功能减少了单一机器或地址生成的瓶颈。
您必须创建自己的 Octavia 负载均衡器,将其用于应用程序网络扩展。
26.2.1. 使用 Octavia 扩展集群 复制链接链接已复制到粘贴板!
如果要使用多个 API 负载均衡器,请创建一个 Octavia 负载均衡器,然后将集群配置为使用它。
先决条件
- Octavia 包括在您的 Red Hat OpenStack Platform(RHOSP)部署中。
流程
在命令行中创建一个使用 Amphora 驱动程序的 Octavia 负载均衡器:
openstack loadbalancer create --name API_OCP_CLUSTER --vip-subnet-id <id_of_worker_vms_subnet>
$ openstack loadbalancer create --name API_OCP_CLUSTER --vip-subnet-id <id_of_worker_vms_subnet>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 可以使用自己选择的名称而不是
API_OCP_CLUSTER。负载均衡器成为活跃后,创建监听程序:
openstack loadbalancer listener create --name API_OCP_CLUSTER_6443 --protocol HTTPS--protocol-port 6443 API_OCP_CLUSTER
$ openstack loadbalancer listener create --name API_OCP_CLUSTER_6443 --protocol HTTPS--protocol-port 6443 API_OCP_CLUSTERCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意要查看负载均衡器的状态,请输入
openstack loadbalancer list。创建一个使用轮循算法的池,并启用了会话持久性:
openstack loadbalancer pool create --name API_OCP_CLUSTER_pool_6443 --lb-algorithm ROUND_ROBIN --session-persistence type=<source_IP_address> --listener API_OCP_CLUSTER_6443 --protocol HTTPS
$ openstack loadbalancer pool create --name API_OCP_CLUSTER_pool_6443 --lb-algorithm ROUND_ROBIN --session-persistence type=<source_IP_address> --listener API_OCP_CLUSTER_6443 --protocol HTTPSCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为确保 control plane 机器可用,创建一个健康监控器:
openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP API_OCP_CLUSTER_pool_6443
$ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP API_OCP_CLUSTER_pool_6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 control plane 机器作为负载均衡器池的成员添加:
for SERVER in $(MASTER-0-IP MASTER-1-IP MASTER-2-IP) do openstack loadbalancer member create --address $SERVER --protocol-port 6443 API_OCP_CLUSTER_pool_6443 done
$ for SERVER in $(MASTER-0-IP MASTER-1-IP MASTER-2-IP) do openstack loadbalancer member create --address $SERVER --protocol-port 6443 API_OCP_CLUSTER_pool_6443 doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选: 要重复使用集群 API 浮动 IP 地址,取消设置它:
openstack floating ip unset $API_FIP
$ openstack floating ip unset $API_FIPCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为创建的负载均衡器 VIP 添加未设置的
API_FIP或一个新地址:openstack floating ip set --port $(openstack loadbalancer show -c <vip_port_id> -f value API_OCP_CLUSTER) $API_FIP
$ openstack floating ip set --port $(openstack loadbalancer show -c <vip_port_id> -f value API_OCP_CLUSTER) $API_FIPCopy to Clipboard Copied! Toggle word wrap Toggle overflow
您的集群现在使用 Octavia 进行负载平衡。
26.3. 用户管理的负载均衡器的服务 复制链接链接已复制到粘贴板!
您可以在 Red Hat OpenStack Platform(RHOSP)上配置 OpenShift Container Platform 集群,使其外部管理的负载均衡器来代替默认负载均衡器。
配置用户管理的负载均衡器取决于您的厂商的负载均衡器。
本节中的信息和示例仅用于指导目的。有关供应商负载均衡器的更多信息,请参阅供应商文档。
红帽支持用户管理的负载均衡器的以下服务:
- Ingress Controller
- OpenShift API
- OpenShift MachineConfig API
您可以选择是否要为用户管理的负载均衡器配置一个或多个所有服务。仅配置 Ingress Controller 服务是一个通用的配置选项。要更好地了解每个服务,请查看以下图表:
图 26.1. 显示 OpenShift Container Platform 环境中运行的 Ingress Controller 的网络工作流示例
图 26.2. 显示 OpenShift Container Platform 环境中运行的 OpenShift API 的网络工作流示例
图 26.3. 显示 OpenShift Container Platform 环境中运行的 OpenShift MachineConfig API 的网络工作流示例
用户管理的负载均衡器支持以下配置选项:
- 使用节点选择器将 Ingress Controller 映射到一组特定的节点。您必须为这个集合中的每个节点分配一个静态 IP 地址,或者将每个节点配置为从动态主机配置协议(DHCP)接收相同的 IP 地址。基础架构节点通常接收这种类型的配置。
以子网上的所有 IP 地址为目标。此配置可减少维护开销,因为您可以在这些网络中创建和销毁节点,而无需重新配置负载均衡器目标。如果您使用较小的网络上的机器集来部署入口 pod,如
/27或/28,您可以简化负载均衡器目标。提示您可以通过检查机器配置池的资源来列出网络中存在的所有 IP 地址。
在为 OpenShift Container Platform 集群配置用户管理的负载均衡器前,请考虑以下信息:
- 对于前端 IP 地址,您可以对前端 IP 地址、Ingress Controller 的负载均衡器和 API 负载均衡器使用相同的 IP 地址。查看厂商的文档以获取此功能的相关信息。
对于后端 IP 地址,请确保 OpenShift Container Platform control plane 节点的 IP 地址在用户管理的负载均衡器生命周期内不会改变。您可以通过完成以下操作之一来实现此目的:
- 为每个 control plane 节点分配一个静态 IP 地址。
- 将每个节点配置为在每次节点请求 DHCP 租期时从 DHCP 接收相同的 IP 地址。根据供应商,DHCP 租期可能采用 IP 保留或静态 DHCP 分配的形式。
- 在 Ingress Controller 后端服务的用户管理的负载均衡器中手动定义运行 Ingress Controller 的每个节点。例如,如果 Ingress Controller 移到未定义节点,则可能会出现连接中断。
26.3.1. 配置用户管理的负载均衡器 复制链接链接已复制到粘贴板!
您可以在 Red Hat OpenStack Platform(RHOSP)上配置 OpenShift Container Platform 集群,使其外部管理的负载均衡器来代替默认负载均衡器。
在配置用户管理的负载均衡器前,请确保阅读用户管理的负载均衡器部分。
阅读适用于您要为用户管理的负载均衡器配置的服务的以下先决条件。
MetalLB,在集群中运行,充当用户管理的负载均衡器。
OpenShift API 的先决条件
- 您定义了前端 IP 地址。
TCP 端口 6443 和 22623 在负载均衡器的前端 IP 地址上公开。检查以下项:
- 端口 6443 提供对 OpenShift API 服务的访问。
- 端口 22623 可以为节点提供 ignition 启动配置。
- 前端 IP 地址和端口 6443 可以被您的系统的所有用户访问,其位置为 OpenShift Container Platform 集群外部。
- 前端 IP 地址和端口 22623 只能被 OpenShift Container Platform 节点访问。
- 负载均衡器后端可以在端口 6443 和 22623 上与 OpenShift Container Platform control plane 节点通信。
Ingress Controller 的先决条件
- 您定义了前端 IP 地址。
- TCP 端口 443 和 80 在负载均衡器的前端 IP 地址上公开。
- 前端 IP 地址、端口 80 和端口 443 可以被您的系统所有用户访问,以及 OpenShift Container Platform 集群外部的位置。
- 前端 IP 地址、端口 80 和端口 443 可被 OpenShift Container Platform 集群中运行的所有节点访问。
- 负载均衡器后端可以在端口 80、443 和 1936 上与运行 Ingress Controller 的 OpenShift Container Platform 节点通信。
健康检查 URL 规格的先决条件
您可以通过设置健康检查 URL 来配置大多数负载均衡器,以确定服务是否可用或不可用。OpenShift Container Platform 为 OpenShift API、Machine Configuration API 和 Ingress Controller 后端服务提供这些健康检查。
以下示例显示了之前列出的后端服务的健康检查规格:
Kubernetes API 健康检查规格示例
Path: HTTPS:6443/readyz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Machine Config API 健康检查规格示例
Path: HTTPS:22623/healthz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Ingress Controller 健康检查规格示例
Path: HTTP:1936/healthz/ready Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 5 Interval: 10
Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
流程
配置 HAProxy Ingress Controller,以便您可以在端口 6443、22623、443 和 80 上从负载均衡器访问集群。根据您的需要,您可以在 HAProxy 配置中指定来自多个子网的单个子网或 IP 地址的 IP 地址。
带有列出子网的 HAProxy 配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 带有多个列出子网的 HAProxy 配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
curlCLI 命令验证用户管理的负载均衡器及其资源是否正常运行:运行以下命令并查看响应,验证集群机器配置 API 是否可以被 Kubernetes API 服务器资源访问:
curl https://<loadbalancer_ip_address>:6443/version --insecure
$ curl https://<loadbalancer_ip_address>:6443/version --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果配置正确,您会收到 JSON 对象的响应:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令并观察输出,验证集群机器配置 API 是否可以被 Machine 配置服务器资源访问:
curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果配置正确,命令的输出会显示以下响应:
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令并观察输出,验证控制器是否可以被端口 80 上的 Ingress Controller 资源访问:
curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果配置正确,命令的输出会显示以下响应:
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cacheCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令并观察输出,验证控制器是否可以被端口 443 上的 Ingress Controller 资源访问:
curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果配置正确,命令的输出会显示以下响应:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
配置集群的 DNS 记录,使其以用户管理的负载均衡器的前端 IP 地址为目标。您必须在负载均衡器上将记录更新为集群 API 和应用程序的 DNS 服务器。
修改 DNS 记录示例
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front EndCopy to Clipboard Copied! Toggle word wrap Toggle overflow <load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front EndCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要DNS 传播可能需要一些时间才能获得每个 DNS 记录。在验证每个记录前,请确保每个 DNS 记录传播。
要使 OpenShift Container Platform 集群使用用户管理的负载均衡器,您必须在集群的
install-config.yaml文件中指定以下配置:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 为
type参数设置UserManaged,为集群指定用户管理的负载均衡器。参数默认为OpenShiftManagedDefault,它表示默认的内部负载均衡器。对于openshift-kni-infra命名空间中定义的服务,用户管理的负载均衡器可将coredns服务部署到集群中的 pod,但忽略keepalived和haproxy服务。 - 2
- 指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共 IP 地址,以便 Kubernetes API 可以与用户管理的负载均衡器通信。
- 3
- 指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共 IP 地址,以便用户管理的负载均衡器可以管理集群的入口流量。
验证
使用
curlCLI 命令验证用户管理的负载均衡器和 DNS 记录配置是否正常工作:运行以下命令并查看输出,验证您可以访问集群 API:
curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果配置正确,您会收到 JSON 对象的响应:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令并查看输出,验证您可以访问集群机器配置:
curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果配置正确,命令的输出会显示以下响应:
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令并查看输出,验证您可以在端口上访问每个集群应用程序:
curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果配置正确,命令的输出会显示以下响应:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令并查看输出,验证您可以在端口 443 上访问每个集群应用程序:
curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果配置正确,命令的输出会显示以下响应:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 27 章 使用 MetalLB 进行负载平衡 复制链接链接已复制到粘贴板!
27.1. 配置 MetalLB 地址池 复制链接链接已复制到粘贴板!
作为集群管理员,您可以添加、修改和删除地址池。MetalLB Operator 使用地址池自定义资源来设置 MetalLB 可分配给服务的 IP 地址。示例中使用的命名空间假定命名空间是 metallb-system。
有关如何安装 MetalLB Operator 的更多信息,请参阅关于 MetalLB 和 MetalLB Operator。
27.1.1. 关于 IPAddressPool 自定义资源 复制链接链接已复制到粘贴板!
下表中描述了 IPAddressPool 自定义资源的字段。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
指定地址池的名称。添加服务时,您可以在 |
|
|
| 指定地址池的命名空间。指定 MetalLB Operator 使用的同一命名空间。 |
|
|
|
可选:指定分配给 |
|
|
| 指定分配给服务的 MetalLB Operator 的 IP 地址列表。您可以在一个池中指定多个范围 ; 它们将共享相同的设置。以 CIDR 表示法指定每个范围,或者指定为以连字符隔开的起始和结束 IP 地址。 |
|
|
|
可选:指定 MetalLB 是否从这个池自动分配 IP 地址。如果要使用 注意
对于 IP 地址池配置,请确保 address 字段只指定可用的 IP,而不被其他网络设备(特别是网关地址)使用,以防止启用 |
|
|
|
可选:这样可确保在启用 IP 地址以 |
您可以通过配置 spec.serviceAllocation 规格,将 IP 地址从 IPAddressPool 分配给服务和命名空间。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 可选:当多个 IP 地址池与服务或命名空间匹配时,定义 IP 地址池之间的优先级。较低数字表示优先级更高。 |
|
|
| 可选:指定您可以分配给 IP 地址池 IP 地址的命名空间列表。 |
|
|
| 可选:指定您可以使用列表格式的标签选择器从 IP 地址池分配给 IP 地址的命名空间标签。 |
|
|
| 可选:指定您可以使用列表格式的标签选择器从地址池中分配给 IP 地址的服务标签。 |
27.1.2. 配置地址池 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在集群中添加地址池来控制 MetalLB 可分配给负载均衡器服务的 IP 地址。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建一个文件,如
ipaddresspool.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 分配给
IPAddressPool的该标签可通过BGPAdvertisementCRD 中的ipAddressPoolSelectors来引用,以将IPAddressPool与广告关联。
应用 IP 地址池的配置:
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
输入以下命令来查看地址池:
oc describe -n metallb-system IPAddressPool doc-example
$ oc describe -n metallb-system IPAddressPool doc-exampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
确认输出中已存在地址池名称,如
doc-example,以及 IP 地址范围。
27.1.3. 为 VLAN 配置 MetalLB 地址池 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在集群中添加地址池来控制 MetalLB 可分配给负载均衡器服务的创建的 VLAN 上的 IP 地址
先决条件
-
安装 OpenShift CLI (
oc) 。 - 配置单独的 VLAN。
-
以具有
cluster-admin特权的用户身份登录。
流程
创建一个文件,如
ipaddresspool-vlan.yaml,该文件类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 IP 地址池的配置:
oc apply -f ipaddresspool-vlan.yaml
$ oc apply -f ipaddresspool-vlan.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为确保此配置适用于您需要将
specgatewayConfig.ipForwarding设置为Global的 VLAN。运行以下命令来编辑网络配置自定义资源 (CR):
oc edit network.operator.openshift/cluster
$ oc edit network.operator.openshift/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 更新
spec.defaultNetwork.ovnKubernetesConfig部分,将gatewayConfig.ipForwarding设置为Global。它应该类似如下:Example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.1.4. 地址池配置示例 复制链接链接已复制到粘贴板!
以下示例演示了特定场景的地址池配置。
27.1.4.1. 示例:IPv4 和 CIDR 范围 复制链接链接已复制到粘贴板!
您可以使用无类别域间路由(CIDR)标记指定 IP 地址范围。您可以将 CIDR 表示法与使用连字符分隔下限和上限的表示法合并。
27.1.4.2. 示例:分配 IP 地址 复制链接链接已复制到粘贴板!
您可以将 autoAssign 字段设置为 false,以防止 MetalLB 自动从地址池中分配 IP 地址。然后,您可以从 IP 地址池分配单个 IP 地址或多个 IP 地址。要分配 IP 地址,请将 /32 CIDR 表示法附加到 spec.addresses 参数中的目标 IP 地址。此设置可确保只有特定 IP 地址可以分配,保留非保留 IP 地址供应用程序使用。
分配多个 IP 地址的 IPAddressPool CR 示例
添加服务时,您可以从地址池中请求特定的 IP 地址,或者在注解中指定池名称,从池中请求任何 IP 地址。
27.1.4.3. 示例:IPv4 和 IPv6 地址 复制链接链接已复制到粘贴板!
您可以添加使用 IPv4 和 IPv6 的地址池。您可以像几个 IPv4 示例一样在 地址 列表中指定多个范围。
无论服务被分配一个 IPv4 地址、一个 IPv6 地址,还是由您添加该服务来确定。spec.ipFamilies 和 spec.ipFamilyPolicy 字段控制 IP 地址如何分配给该服务。
- 1
- 其中
10.0.100.0/28是本地网络 IP 地址,后跟/28网络前缀。
27.1.4.4. 示例:将 IP 地址池分配给服务或命名空间 复制链接链接已复制到粘贴板!
您可以将 IP 地址从 IPAddressPool 分配给您指定的服务和命名空间。
如果您将服务或命名空间分配给多个 IP 地址池,MetalLB 将使用较高优先级 IP 地址池中的可用 IP 地址。如果分配的 IP 地址池没有 IP 地址可用,MetalLB 将使用较低优先级或没有优先级的 IP 地址池的可用 IP 地址。
对于 namespaceSelectors 和 serviceSelectors 规格,您可以使用 matchLabels 标签选择器、matchExpressions 标签选择器或两者。本例展示了每个规格的一个标签选择器。
27.1.5. 后续步骤 复制链接链接已复制到粘贴板!
27.2. 关于 IP 地址池的广告 复制链接链接已复制到粘贴板!
您可以配置 MetalLB,以便使用第 2 层协议、BGP 协议或两者来广告 IP 地址。通过第 2 层,MetalLB 提供了容错的外部 IP 地址。使用 BGP,MetalLB 为外部 IP 地址和负载均衡提供容错功能。
MetalLB 支持将 L2 和 BGP 用于同一组 IP 地址。
MetalLB 提供了将地址池分配给特定 BGP 对等对象到网络上节点子集的灵活性。这可以实现更复杂的配置,例如促进节点隔离或网络分段。
27.2.1. 关于 BGPAdvertisement 自定义资源 复制链接链接已复制到粘贴板!
BGPAdvertise 对象的字段在下表中定义:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定 BGP 广告的名称。 |
|
|
| 指定 BGP 广告的命名空间。指定 MetalLB Operator 使用的同一命名空间。 |
|
|
|
可选:指定 32 位 CIDR 掩码中包含的位数。为了聚合发言人向 BGP 对等者公告的路由,掩码将应用于多个服务 IP 地址的路由,speaker 会公告聚合的路由。例如,聚合长度为 |
|
|
|
可选:指定 128 位 CIDR 掩码中包含的位数。例如,在聚合长度为 |
|
|
| 可选:指定一个或多个 BGP 社区。每个社区都被指定为两个 16 位值,用冒号字符分隔。知名的社区必须指定为 16 位值:
|
|
|
| 可选:指定这个广播的本地首选项。此 BGP 属性适用于 Autonomous System 中的 BGP 会话。 |
|
|
|
可选:用于使用这个广告进行广告的 |
|
|
|
可选:使用这个广告进行广告的 |
|
|
|
可选: |
|
|
|
可选:使用列表为每个 |
27.2.2. 使用 BGP 公告和基本用例配置 MetalLB 复制链接链接已复制到粘贴板!
按如下所示配置 MetalLB,使对等 BGP 路由器为每个 MetalLB 分配为服务的负载均衡器 IP 地址接收一个 203.0.113.200/32 路由和一个 fc00:f853:ccd:e799::1/128 路由。因为没有指定 localPref 和 community 字段,所以路由会公告,并将 localPref 设置为 0,且没有 BGP 社区。
27.2.2.1. 示例:使用 BGP 传输基本地址池配置 复制链接链接已复制到粘贴板!
按如下所示配置 MetalLB,以便使用 BGP 协议公告 IPAddressPool。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建 IP 地址池。
创建一个文件,如
ipaddresspool.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 IP 地址池的配置:
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 BGP 公告。
创建一个文件,如
bgpadvertisement.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置:
oc apply -f bgpadvertisement.yaml
$ oc apply -f bgpadvertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.3. 使用 BGP 广告和高级用例配置 MetalLB 复制链接链接已复制到粘贴板!
按如下所示配置 MetalLB,使得 MetalLB 分配给负载均衡器的 IP 地址范围是 203.0.113.200 到 203.0.113.203,以及 fc00:f853:ccd:e799::0 到 fc00:f853:ccd:e799::f。
为了说明两个 BGP 公告,在 MetalLB 分配 IP 地址 203.0.113.200 时,请考虑实例。以该 IP 地址为例,发言人向 BGP 对等点公告两个路由:
-
203.0.113.200/32,localPref设置为100,社区设置为NO_ADVERTISE社区的数字值。此规范指示它们可以使用此路由的对等路由器,但它们不应将有关此路由的信息传播到 BGP 对等点。 -
203.0.113.200/30将 MetalLB 分配的负载均衡器 IP 地址聚合到一个路由中。MetalLB 公告到 BGP 对等点的聚合路由,并将 community 属性设置为8000:800。BGP 同行将203.0.113.200/30个路由传播到其他 BGP 同级服务器。当流量通过发言人路由到节点时,使用203.0.113.200/32路由将流量转发到集群以及与该服务关联的 pod。
当添加更多服务和 MetalLB 从池中分配更多负载均衡器 IP 地址时,对等路由器收到一个本地路由,203.0.113.20x/32,以及 203.0.113.200/30 聚合路由。您添加的每个服务都会生成 /30 路由,但 MetalLB 会将路由重复数据删除到一个 BGP 公告,然后再与对等路由器通信。
27.2.3.1. 示例:使用 BGP 传输高级地址池配置 复制链接链接已复制到粘贴板!
按如下所示配置 MetalLB,以便使用 BGP 协议公告 IPAddressPool。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建 IP 地址池。
创建一个文件,如
ipaddresspool.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 IP 地址池的配置:
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 BGP 公告。
创建一个文件,如
bgpadvertisement1.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置:
oc apply -f bgpadvertisement1.yaml
$ oc apply -f bgpadvertisement1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个文件,如
bgpadvertisement2.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置:
oc apply -f bgpadvertisement2.yaml
$ oc apply -f bgpadvertisement2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.4. 从节点的子集公告 IP 地址池 复制链接链接已复制到粘贴板!
要从 IP 地址池公告 IP 地址,请只使用特定的节点集合,使用 BGPAdvertisement 自定义资源中的 .spec.nodeSelector 规格。此规格将 IP 地址池与集群中的一组节点关联。如果您在集群中的不同子网上有节点,而您想要从特定子网的地址池中公告 IP 地址,例如仅面向公共的子网。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
使用自定义资源创建 IP 地址池:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过在 BGPAdvertisement 自定义资源中定义
.spec.nodeSelector值,控制pool1广告的 IP 地址来自集群中的哪些节点:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在本例中,pool1 广告的 IP 地址仅来自 NodeA 和 NodeB。
27.2.5. 关于 L2Advertisement 自定义资源 复制链接链接已复制到粘贴板!
l2Advertise 对象的字段在下表中定义:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定 L2 广告的名称。 |
|
|
| 指定 L2 广告的命名空间。指定 MetalLB Operator 使用的同一命名空间。 |
|
|
|
可选:用于使用这个广告进行广告的 |
|
|
|
可选:使用这个广告进行广告的 |
|
|
|
可选: 重要 限制节点,因为下一跃点只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。 有关红帽技术预览功能支持范围的更多信息,请参阅以下链接: |
|
|
|
可选:用于声明负载均衡器 IP 的 |
27.2.6. 使用 L2 广告配置 MetalLB 复制链接链接已复制到粘贴板!
按如下所示配置 MetalLB,以便使用 L2 协议广告 IPAddressPool。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建 IP 地址池。
创建一个文件,如
ipaddresspool.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 IP 地址池的配置:
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 L2 广告。
创建一个文件,如
l2advertisement.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置:
oc apply -f l2advertisement.yaml
$ oc apply -f l2advertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.7. 使用 L2 广告和标签配置 MetalLB 复制链接链接已复制到粘贴板!
BGPAdvertisement 和 L2Advertisement 中的 ipAddress Pools 字段用于根据分配给 IPAddressPool 的标签将 IPAddressPool 与广告相关联。
本例演示了如何配置 MetalLB,以便通过配置 ipAddressPoolSelectors 字段来广告使用 L2 协议的 IPAddressPools。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建 IP 地址池。
创建一个文件,如
ipaddresspool.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 IP 地址池的配置:
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
使用
ipAddressPoolSelectors创建 L2 广告广告 IP。创建一个文件,如
l2advertisement.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置:
oc apply -f l2advertisement.yaml
$ oc apply -f l2advertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.8. 为所选接口配置带有 L2 广告的 MetalLB 复制链接链接已复制到粘贴板!
默认情况下,分配给该服务的 IP 地址池的 IP 地址将从所有网络接口公告。L2Advertisement 自定义资源定义中的 interfaces 字段用于限制公告 IP 地址池的网络接口。
本例演示了如何配置 MetalLB,以便仅从所有节点的 interfaces 字段中列出的网络接口公告 IP 地址池。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
您以具有
cluster-admin权限的用户身份登录。
流程
创建 IP 地址池。
创建一个文件,如
ipaddresspool.yaml,并输入类似以下示例的配置详情:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为 IP 地址池应用配置,如下例所示:
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
使用
接口选择器创建 L2 广告广告 IP。创建一个 YAML 文件,如
l2advertisement.yaml,并输入类似以下示例的配置详情:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为公告应用配置,如下例所示:
oc apply -f l2advertisement.yaml
$ oc apply -f l2advertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
接口选择器不会影响 MetalLB 如何使用 L2 选择给定 IP 的节点。如果节点没有所选接口,则所选节点不会宣布该服务。
27.2.9. 使用二级网络配置 MetalLB 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 4.14 中,默认的网络行为是不允许在网络接口之间转发 IP 数据包。因此,当在二级接口上配置 MetalLB 时,您需要添加机器配置来只为所需的接口启用 IP 转发。
从 4.13 升级的 OpenShift Container Platform 集群不受影响,因为在升级过程中设置了全局参数来启用全局 IP 转发。
要为二级接口启用 IP 转发,有两个选项:
- 为所有接口启用 IP 转发。
为特定接口启用 IP 转发。
注意为特定接口启用 IP 转发提供了更精细的控制,同时为所有接口启用它应用全局设置。
流程
通过创建并应用
MachineConfigCR,为特定二级接口启用转发,如bridge-net。-
创建
MachineConfigCR,为名为bridge-net的指定的二级接口启用 IP 转发。 将以下 YAML 保存到
enable-ip-forward.yaml文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 要启用 IP 转发的节点角色,如
worker
运行以下命令来应用配置:
oc apply -f enable-ip-forward.yaml
$ oc apply -f enable-ip-forward.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
创建
另外,您可以运行以下命令来全局启用 IP 转发:
oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.3. 配置 MetalLB BGP peer 复制链接链接已复制到粘贴板!
作为集群管理员,您可以添加、修改和删除边框网关协议(BGP)对等点。MetalLB Operator 使用 BGP peer 自定义资源来标识 MetalLB speaker pod 联系的对等者启动 BGP 会话。对等点接收 MetalLB 分配给服务的负载均衡器 IP 地址的路由公告。
27.3.1. 关于 BGP peer 自定义资源 复制链接链接已复制到粘贴板!
下表中描述了 BGP peer 自定义资源的字段。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定 BGP peer 自定义资源的名称。 |
|
|
| 指定 BGP peer 自定义资源的命名空间。 |
|
|
|
为 BGP 会话的本地末尾指定 Autonomous System Number (ASN)。在您添加的所有 BGP peer 自定义资源中,指定相同的值。范围是从 |
|
|
|
指定 BGP 会话的远程端的 ASN。范围是从 |
|
|
|
检测用于会话远程端的 ASN,而不明确设置它。为具有相同 ASN 的对等点指定 |
|
|
| 指定建立 BGP 会话的对等点的 IP 地址。 |
|
|
| 可选:指定建立 BGP 会话时要使用的 IP 地址。该值必须是 IPv4 地址。 |
|
|
|
可选:指定用来建立 BGP 会话的对等端口。范围为 |
|
|
|
可选:指定到 BGP 对等点的保留时间。最小值为 3 秒( |
|
|
|
可选:指定向 BGP 对等发送保留消息之间的最大间隔。如果指定此字段,还必须为 |
|
|
| 可选:指定要公告到 BGP peer 的路由器 ID。如果指定了此字段,则必须在添加的每个 BGP peer 自定义资源中指定相同的值。 |
|
|
| 可选:指定 MD5 密码,以发送到执行 TCP MD5 经过身份验证的 BGP 会话的路由器的对等点。 |
|
|
|
可选:指定 BGP Peer 的身份验证 secret 的名称。secret 必须存在于 |
|
|
| 可选:指定 BFD 配置集的名称。 |
|
|
| 可选:使用匹配表达式和匹配标签指定选择器,以控制哪些节点可以连接到 BGP 对等点。 |
|
|
|
可选:指定 BGP peer 是否有多个网络跃点。如果 BGP peer 没有直接连接到同一网络,则 speaker 无法建立 BGP 会话,除非此字段设置为 |
passwordSecret 字段与 password 字段相互排斥,包含对包含密码的 secret 的引用。设置这两个字段会导致解析失败。
27.3.2. 配置 BGP peer 复制链接链接已复制到粘贴板!
作为集群管理员,您可以添加 BGP peer 自定义资源来与网络路由器交换路由信息,并为服务公告 IP 地址。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 使用 BGP 公告配置 MetalLB。
流程
创建一个文件,如
bgppeer.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 BGP peer 的配置:
oc apply -f bgppeer.yaml
$ oc apply -f bgppeer.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.3.3. 为给定地址池配置一组特定的 BGP 对等组 复制链接链接已复制到粘贴板!
此流程演示了如何:
-
配置一组地址池(
pool1和pool2)。 -
配置一组 BGP 对等点(
pe1和peer2)。 -
配置 BGP 广告,将
pool1分配给peer1,将pool2分配给peer2。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建地址池
pool1。创建一个文件,如
ipaddresspool1.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为 IP 地址池
pool1应用配置:oc apply -f ipaddresspool1.yaml
$ oc apply -f ipaddresspool1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建地址池
pool2。创建一个文件,如
ipaddresspool2.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为 IP 地址池
pool2应用配置:oc apply -f ipaddresspool2.yaml
$ oc apply -f ipaddresspool2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 BGP
peer1。创建一个文件,如
bgppeer1.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 BGP peer 的配置:
oc apply -f bgppeer1.yaml
$ oc apply -f bgppeer1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 BGP
peer2。创建一个文件,如
bgppeer2.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 BGP peer2 的配置:
oc apply -f bgppeer2.yaml
$ oc apply -f bgppeer2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 BGP 广告 1。
创建一个文件,如
bgpadvertisement1.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置:
oc apply -f bgpadvertisement1.yaml
$ oc apply -f bgpadvertisement1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 BGP 广告 2。
创建一个文件,如
bgpadvertisement2.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置:
oc apply -f bgpadvertisement2.yaml
$ oc apply -f bgpadvertisement2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.3.4. 通过网络 VRF 公开服务 复制链接链接已复制到粘贴板!
您可以通过在网络接口上将 VRF 与 BGP 对等点关联,通过虚拟路由和转发(VRF)实例公开服务。
通过 BGP 对等点上的 VRF 公开服务只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
通过使用网络接口上的 VRF 通过 BGP 对等点公开服务,您可以将流量隔离到服务,配置独立路由决策,并在网络接口上启用多租户支持。
通过一个属于网络 VRF 的接口建立 BGP 会话,MetalLB 可以通过该接口公告服务,并让外部流量通过这个接口访问该服务。但是,network VRF 路由表与 OVN-Kubernetes 使用的默认 VRF 路由表不同。因此,流量无法访问 OVN-Kubernetes 网络基础架构。
要启用定向到服务的流量访问 OVN-Kubernetes 网络基础架构,您必须配置路由规则来为网络流量定义下一跃点。如需更多信息,请参阅附加资源部分中的"使用 MetalLB 管理对称路由"中的 NodeNetworkConfigurationPolicy 资源。
这些是通过带有 BGP peer 的网络 VRF 公开服务的高级步骤:
- 定义 BGP peer 并添加网络 VRF 实例。
- 为 MetalLB 指定 IP 地址池。
- 为 MetalLB 配置 BGP 路由广告,以使用指定的 IP 地址池以及与 VRF 实例关联的 BGP 对等点公告路由。
- 部署服务来测试配置。
先决条件
-
已安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin权限的用户身份登录。 -
您定义了一个
NodeNetworkConfigurationPolicy,将虚拟路由和转发(VRF)实例与网络接口关联。有关完成此先决条件的更多信息,请参阅附加资源部分。 - 在集群中安装了 MetalLB。
流程
创建
BGPPeer自定义资源 (CR):创建一个文件,如
frrviavrf.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定要与 BGP peer 关联的网络 VRF 实例。MetalLB 可以公告服务并根据 VRF 中的路由信息做出路由决策。
注意您必须在
NodeNetworkConfigurationPolicyCR 中配置此网络 VRF 实例。如需更多信息,请参阅附加资源。运行以下命令,应用 BGP peer 的配置:
oc apply -f frrviavrf.yaml
$ oc apply -f frrviavrf.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个
IPAddressPoolCR:创建一个文件,如
first-pool.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为 IP 地址池应用配置:
oc apply -f first-pool.yaml
$ oc apply -f first-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建
BGPAdvertisementCR:创建一个文件,如
first-adv.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 在本例中,MetalLB 将来自
first-poolIP 地址池的 IP 地址范围公告给frrviavrfBGP peer。
运行以下命令,应用 BGP 公告的配置:
oc apply -f first-adv.yaml
$ oc apply -f first-adv.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个
Namespace,Deployment, 和ServiceCR:创建一个文件,如
deploy-service.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为命名空间、部署和服务应用配置:
oc apply -f deploy-service.yaml
$ oc apply -f deploy-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令来识别 MetalLB speaker pod:
oc get -n metallb-system pods -l component=speaker
$ oc get -n metallb-system pods -l component=speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE speaker-c6c5f 6/6 Running 0 69m
NAME READY STATUS RESTARTS AGE speaker-c6c5f 6/6 Running 0 69mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,在 speaker pod 中验证 BGP 会话的状态是否为
Established,替换变量以匹配您的配置:oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> neigh"
$ oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> neigh"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
BGP neighbor is 192.168.30.1, remote AS 200, local AS 100, external link BGP version 4, remote router ID 192.168.30.1, local router ID 192.168.30.71 BGP state = Established, up for 04:20:09 ...
BGP neighbor is 192.168.30.1, remote AS 200, local AS 100, external link BGP version 4, remote router ID 192.168.30.1, local router ID 192.168.30.71 BGP state = Established, up for 04:20:09 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令验证该服务是否已正确公告:
oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> ipv4"
$ oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> ipv4"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.3.5. BGP 对等配置示例 复制链接链接已复制到粘贴板!
27.3.5.1. 示例:限制节点连接到 BGP peer 复制链接链接已复制到粘贴板!
您可以指定节点选择器字段来控制哪些节点可以连接到 BGP 对等点。
27.3.5.2. 示例:为 BGP peer 指定 BFD 配置集 复制链接链接已复制到粘贴板!
您可以指定一个 BFD 配置集,以与 BGP 对等点关联。BFD 复杂的 BGP 通过单独提供与 BGP 间通信故障的更快速检测。
删除双向转发检测 (BFD) 配置集并删除添加到边框网关协议 (BGP) 对等资源中的 bfdProfile 不会禁用 BFD。相反,BGP 对等点开始使用默认的 BFD 配置集。要从 BGP peer 资源禁用 BFD,请删除 BGP 对等配置,并在没有 BFD 配置集的情况下重新创建它。如需更多信息,请参阅 BZ#2050824。
27.3.5.3. 示例:为双栈网络指定 BGP 对等点 复制链接链接已复制到粘贴板!
要支持双栈网络,请为 IPv4 添加一个 BGP peer 自定义资源,并为 IPv6 添加一个 BGP peer 自定义资源。
27.3.6. 后续步骤 复制链接链接已复制到粘贴板!
27.4. 配置社区别名 复制链接链接已复制到粘贴板!
作为集群管理员,您可以配置一个社区别名并在不同的广告中使用它。
27.4.1. 关于社区自定义资源 复制链接链接已复制到粘贴板!
community 自定义资源是社区的一个别名集合。用户可使用 BGPAdvertis 定义广告 ipAddressPools 时使用的命名别名。下表中描述了 community 自定义资源的字段。
community CRD 仅适用于 BGPAdvertisement。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
指定 |
|
|
|
指定 |
|
|
|
指定可在 BGPAdvertisements 中使用的 BGP 社区别名列表。社区别名由名称(别名)和值(数字:number)组成。通过引用 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
|
|
|
|
与给定名称对应的 BGP |
27.4.2. 使用 BGP 广告和社区别名配置 MetalLB 复制链接链接已复制到粘贴板!
按如下所示配置 MetalLB,以便 BGP 协议广告 IPAddressPool,并将社区别名设置为 NO_ADVERTISE 社区的数字值。
在以下示例中,对等 BGP 路由器 doc-example-peer-community 接收一个 203.0.113.200/32 路由,以及一个 fc00:f853:ccd:e799::1/128 路由,每个 load-balancer IP 地址都分配给服务。使用 NO_ADVERTISE 社区配置了一个社区别名。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建 IP 地址池。
创建一个文件,如
ipaddresspool.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 IP 地址池的配置:
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建名为
community1的社区别名。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个名为
doc-example-bgp-peer的 BGP peer。创建一个文件,如
bgppeer.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 BGP peer 的配置:
oc apply -f bgppeer.yaml
$ oc apply -f bgppeer.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个带有社区别名的 BGP 广告。
创建一个文件,如
bgpadvertisement.yaml,内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 在这里指定
CommunityAlias.name,而不是社区自定义资源 (CR) 名称。
应用配置:
oc apply -f bgpadvertisement.yaml
$ oc apply -f bgpadvertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.5. 配置 MetalLB BFD 配置集 复制链接链接已复制到粘贴板!
作为集群管理员,您可以添加、修改和删除双向检测(BFD)配置集。MetalLB Operator 使用 BFD 配置集自定义资源来识别哪个 BGP 会话使用 BFD 来单独提供比 BGP 更快地提供的路径故障检测。
27.5.1. 关于 BFD 配置集自定义资源 复制链接链接已复制到粘贴板!
下表中描述了 BFD 配置集自定义资源的字段。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定 BFD 配置集自定义资源的名称。 |
|
|
| 指定 BFD 配置集自定义资源的命名空间。 |
|
|
| 指定确定数据包丢失的检测倍数。远程传输间隔乘以这个值来确定连接丢失检测计时器。
例如,当本地系统的检测倍数设置为
范围为 |
|
|
|
指定回显传输模式。如果您不使用分布式 BFD,则回显传输模式仅在 peer 也是 FRR 时才可以正常工作。默认值为
启用回显传输模式时,请考虑增加控制数据包的传输间隔,以减少带宽使用量。例如,考虑将传输间隔增加到 |
|
|
|
指定此系统用来发送和接收回显数据包的最小传输间隔(较少的)。范围为 |
|
|
| 指定传入控制数据包的最低预期 TTL。此字段只适用于多跃点会话。 设置最小 TTL 的目的是使数据包验证要求更加严格,并避免从其他会话接收控制数据包。
默认值为 |
|
|
| 指定会话是否标记为主动或者被动。被动会话不会尝试启动连接。相反,被动会话会等待来自 peer 的控制数据包,然后再开始回复。 当您有一个作为星星网络的中央节点,并且您希望发送不需要系统发送的控制数据包时,如果您有一个路由器将会话标记为被动。
默认值为 |
|
|
|
指定此系统可以接收控制数据包的最低间隔。范围为 |
|
|
|
指定此系统用来发送控制数据包的最小传输间隔(较少的)。范围为 |
27.5.2. 配置 BFD 配置集 复制链接链接已复制到粘贴板!
作为集群管理员,您可以添加 BFD 配置集,并配置 BGP 对等点来使用配置集。BFD 仅提供比 BGP 快于 BGP 的路径故障检测速度。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。
流程
创建一个文件,如
bfdprofile.yaml,其内容如下:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为 BFD 配置集应用配置:
oc apply -f bfdprofile.yaml
$ oc apply -f bfdprofile.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.5.3. 后续步骤 复制链接链接已复制到粘贴板!
- 将 BGP peer 配置为使用 BFD 配置集。
27.6. 将服务配置为使用 MetalLB 复制链接链接已复制到粘贴板!
作为集群管理员,当添加类型为 LoadBalancer 的服务时,您可以控制 MetalLB 如何分配 IP 地址。
27.6.1. 请求特定 IP 地址 复制链接链接已复制到粘贴板!
与其他一些负载均衡器实施一样,MetalLB 接受服务规格中的 spec.loadBalancerIP 字段。
如果请求的 IP 地址位于任何地址池中,MetalLB 会分配请求的 IP 地址。如果请求的 IP 地址不在任何范围内,MetalLB 会报告警告。
特定 IP 地址的服务 YAML 示例
如果 MetalLB 无法分配请求的 IP 地址,服务报告的 EXTERNAL-IP 会报告 <pending>,运行 oc describe service <service_name> 会包括一个类似以下示例的事件。
当 MetalLB 无法分配请求的 IP 地址时的示例
... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning AllocationFailed 3m16s metallb-controller Failed to allocate IP for "default/invalid-request": "4.3.2.1" is not allowed in config
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning AllocationFailed 3m16s metallb-controller Failed to allocate IP for "default/invalid-request": "4.3.2.1" is not allowed in config
27.6.2. 从特定池中请求 IP 地址 复制链接链接已复制到粘贴板!
要从特定范围分配 IP 地址,但您不关注特定的 IP 地址,您可以使用 metallb.universe.tf/address-pool 注解从指定地址池中请求 IP 地址。
来自特定池的 IP 地址的服务 YAML 示例
如果您为 <address_pool_name> 指定的地址池不存在,MetalLB 会尝试从允许自动分配的池中分配 IP 地址。
27.6.3. 接受任何 IP 地址 复制链接链接已复制到粘贴板!
默认情况下,地址池配置为允许自动分配。MetalLB 从这些地址池中分配 IP 地址。
若要接受任何为自动分配配置的池的 IP 地址,不需要特殊注释或配置。
接受任何 IP 地址的服务 YAML 示例
27.6.5. 使用 MetalLB 配置服务 复制链接链接已复制到粘贴板!
您可以将负载平衡服务配置为使用地址池中的外部 IP 地址。
先决条件
-
安装 OpenShift CLI (
oc) 。 - 安装 MetalLB Operator 并启动 MetalLB。
- 至少配置一个地址池。
- 配置网络,将流量从客户端路由到集群的主机网络。
流程
创建一个
<service_name>.yaml文件。在文件中,确保将spec.type字段设置为LoadBalancer。有关如何请求 MetalLB 分配给服务的外部 IP 地址的信息,请参考示例。
创建服务:
oc apply -f <service_name>.yaml
$ oc apply -f <service_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
service/<service_name> created
service/<service_name> createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
描述该服务:
oc describe service <service_name>
$ oc describe service <service_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.7. 使用 MetalLB 管理对称路由 复制链接链接已复制到粘贴板!
作为集群管理员,您可以通过从 MetalLB、NMState 和 OVN-Kubernetes 实现功能来有效地管理带有多个主机接口的 MetalLB 负载均衡器服务后面的 pod 的流量。通过结合此上下文中的这些功能,您可以提供对称路由、流量隔离,并支持具有不同网络上的客户端及重叠 CIDR 地址。
要实现此功能,了解如何使用 MetalLB 实施虚拟路由和转发(VRF)实例,并配置出口服务。
使用带有 MetalLB 和出口服务的 VRF 实例配置对称流量只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
27.7.1. 使用 MetalLB 管理对称路由的挑战 复制链接链接已复制到粘贴板!
当您将 MetalLB 与多个主机接口搭配使用时,MetalLB 通过主机上的所有可用接口公开并宣布服务。这可能会造成与网络隔离、非对称返回流量和重叠 CIDR 地址相关的挑战。
确保返回流量达到正确的客户端的一个选项是使用静态路由。但是,使用这个解决方案,MetalLB 无法隔离服务,然后通过不同的接口声明每个服务。另外,静态路由需要手动配置,并在添加远程站点时需要维护。
在实现 MetalLB 服务时,对称路由的进一步挑战是外部系统预期应用程序的源和目标 IP 地址相同的情况。OpenShift Container Platform 的默认行为是将主机网络接口的 IP 地址分配为来自 pod 的流量的源 IP 地址。这在多个主机接口中存在问题。
您可以通过实施组合来自 MetalLB、NMState 和 OVN-Kubernetes 的功能的配置来解决这些挑战。
27.7.2. 使用带有 MetalLB 的 VRF 管理对称路由概述 复制链接链接已复制到粘贴板!
您可以使用 NMState 在主机上配置 VRF 实例、将 VRF 实例与 MetalLB BGPPeer 资源关联,以及为出口流量配置出口服务来克服实施对称路由的挑战。
图 27.1. 使用带有 MetalLB 的 VRF 管理对称路由的网络概述
配置过程涉及三个阶段:
1.定义 VRF 和路由规则
-
配置
NodeNetworkConfigurationPolicy自定义资源 (CR),将 VRF 实例与网络接口关联。 - 使用 VRF 路由表直接入口和出口流量。
2.将 VRF 链接到 MetalLB BGPPeer
-
配置 MetalLB
BGPPeer资源,以使用网络接口上的 VRF 实例。 -
通过将
BGPPeer资源与 VRF 实例关联,指定的网络接口成为 BGP 会话的主接口,MetalLB 通过这个接口公告服务。
3.配置出口服务
- 配置出口服务,为出口流量选择与 VRF 实例关联的网络。
- 可选:将出口服务配置为使用 MetalLB 负载均衡器服务的 IP 地址作为出口流量的源 IP。
27.7.3. 使用带有 MetalLB 的 VRF 配置对称路由 复制链接链接已复制到粘贴板!
您可以为需要同一入口和出口网络路径的 MetalLB 服务后面的应用程序配置对称网络路由。
这个示例将 VRF 路由表与 MetalLB 和出口服务相关联,以便为 LoadBalancer 服务后面的 pod 启用对称路由。
-
如果您在
EgressServiceCR 中使用sourceIPBy: "LoadBalancerIP"设置,您必须在BGPAdvertisement自定义资源 (CR) 中指定负载均衡器节点。 -
在使用带有
gatewayConfig.routingViaHost规格设置为true的 OVN-Kubernetes 的集群中,您可以使用sourceIPBy: "Network"设置。另外,如果您使用sourceIPBy: "Network"设置,您必须在使用网络 VRF 实例配置的节点上调度应用程序工作负载。
先决条件
-
安装 OpenShift CLI(
oc)。 -
以具有
cluster-admin特权的用户身份登录。 - 安装 Kubernetes NMState Operator。
- 安装 MetalLB Operator。
流程
创建一个
NodeNetworkConfigurationPolicyCR 来定义 VRF 实例:创建一个文件,如
node-network-vrf.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 策略的名称。
- 2
- 这个示例将策略应用到带有
vrf:true标签的所有节点。 - 3
- 接口的名称。
- 4
- 接口的类型。这个示例创建了一个 VRF 实例。
- 5
- VRF 附加到的节点接口。
- 6
- VRF 的路由表 ID 的名称。
- 7
- 与 VRF 关联的接口的 IPv4 地址。
- 8
- 定义网络路由的配置。
next-hop-address字段定义路由的下一跃点的 IP 地址。next-hop-interface字段定义路由的传出接口。在本例中,VRF 路由表是2,它引用您在EgressServiceCR 中定义的 ID。 - 9
- 定义额外的路由规则。
ip-to字段必须与Cluster NetworkCIDR、Service NetworkCIDR 和Internal Masquerade子网 CIDR 匹配。您可以运行以下命令来查看这些 CIDR 地址规格的值:oc describe network.operator/cluster。 - 10
- 计算路由时使用的 Linux 内核的主路由表的 ID 为
254。
运行以下命令来应用策略:
oc apply -f node-network-vrf.yaml
$ oc apply -f node-network-vrf.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建
BGPPeer自定义资源 (CR):创建一个文件,如
frr-via-vrf.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定要与 BGP peer 关联的 VRF 实例。MetalLB 可以公告服务并根据 VRF 中的路由信息做出路由决策。
运行以下命令,应用 BGP peer 的配置:
oc apply -f frr-via-vrf.yaml
$ oc apply -f frr-via-vrf.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个
IPAddressPoolCR:创建一个文件,如
first-pool.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为 IP 地址池应用配置:
oc apply -f first-pool.yaml
$ oc apply -f first-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建
BGPAdvertisementCR:创建一个文件,如
first-adv.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,应用 BGP 公告的配置:
oc apply -f first-adv.yaml
$ oc apply -f first-adv.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个
EgressServiceCR:创建一个文件,如
egress-service.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定出口服务的名称。
EgressService资源的名称必须与您要修改的负载均衡器服务的名称匹配。 - 2
- 指定出口服务的命名空间。
EgressService的命名空间必须与您要修改的负载均衡器服务的命名空间匹配。egress 服务是命名空间范围的。 - 3
- 这个示例将
LoadBalancer服务入口 IP 地址分配为出口流量的源 IP 地址。 - 4
- 如果为
sourceIPBy规格指定LoadBalancer,则单一节点处理LoadBalancer服务流量。在本例中,只有标签vrf: "true"的节点才能处理服务流量。如果没有指定节点,OVN-Kubernetes 会选择一个 worker 节点来处理服务流量。当选择节点时,OVN-Kubernetes 以以下格式标记节点:egress-service.k8s.ovn.org/<svc_namespace>-<svc_name>: ""。 - 5
- 指定出口流量的路由表 ID。确保值与
NodeNetworkConfigurationPolicy资源中定义的route-table-idID 匹配,例如route-table-id: 2。
运行以下命令,为出口服务应用配置:
oc apply -f egress-service.yaml
$ oc apply -f egress-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,验证您可以访问 MetalLB 服务后运行的 pod 的应用程序端点:
curl <external_ip_address>:<port_number>
$ curl <external_ip_address>:<port_number>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 更新外部 IP 地址和端口号,以适合您的应用程序端点。
-
可选:如果您将
LoadBalancer服务入口 IP 地址指定为出口流量的源 IP 地址,请使用tcpdump等工具分析外部客户端接收的数据包,以此验证此配置。
27.8. 配置 MetalLB 和 FRR-K8s 的集成 复制链接链接已复制到粘贴板!
FRRConfiguration 自定义资源只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅以下链接:
FRRouting (FRR) 是一个免费的开源互联网路由协议套件,用于 Linux 和 UNIX 平台。FRR-K8s 是基于 Kubernetes 的 DaemonSet,它以 Kubernetes 兼容的方式公开 FRR API 的子集。作为集群管理员,您可以使用 FRRConfiguration 自定义资源 (CR) 将 MetalLB 配置为使用 FRR-K8s 作为后端。您可以使用它来提供 FRR 服务,例如接收路由。如果您使用 FRR-K8s 作为后端运行 MetalLB,MetalLB 会生成与应用的 MetalLB 配置对应的 FRR-K8s 配置。
27.8.1. 激活 MetalLB 和 FRR-K8s 的集成 复制链接链接已复制到粘贴板!
以下流程演示了如何激活 FRR-K8s 作为 MetalLB 的后端。
先决条件
- 您已在裸机硬件上安装了集群。
-
已安装 OpenShift CLI(
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。
流程
将
MetalLBCR 的bgpBackend字段设置为frr-k8s,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.8.2. FRR 配置 复制链接链接已复制到粘贴板!
您可以创建多个 FRRConfiguration CR,以便在 MetalLB 中使用 FRR 服务。MetalLB 生成一个 FRRConfiguration 对象,它 FRR-K8s 与所有用户创建的所有配置合并。
例如,您可以配置 FRR-K8s,以接收给定邻居公告的所有前缀。以下示例将 FRR-K8s 配置为接收带有主机 172.18.0.5 的 BGPPeer 公告的所有前缀:
FRRConfiguration CR 示例
您还可以将 FRR-K8s 配置为始终阻止一组前缀,而不考虑应用的配置。这可用于避免到可能造成集群故障的 pod 或 ClusterIP CIDR 的路由。以下示例阻止了一组前缀 192.168.1.0/24 :
MetalLB CR 示例
您可以将 FRR-K8s 设置为阻止 Cluster Network CIDR 和 Service Network CIDR。您可以运行以下命令来查看这些 CIDR 地址规格的值:
oc describe network.config/cluster
$ oc describe network.config/cluster
27.8.3. 配置 FRRConfiguration CRD 复制链接链接已复制到粘贴板!
以下部分提供了使用 FRRConfiguration 自定义资源 (CR) 的参考示例。
27.8.3.1. router 字段 复制链接链接已复制到粘贴板!
您可以使用 router 字段配置多个路由器,每个虚拟路由和转发 (VRF) 资源对应一个。对于每个路由器,您必须定义自主系统号 (ASN)。
您还可以定义要连接的边框网关协议 (BGP) 邻居列表,如下例所示:
FRRConfiguration CR 示例
27.8.3.2. toAdvertise 字段 复制链接链接已复制到粘贴板!
默认情况下,FRR-K8s 不会公告配置为路由器配置的前缀。要公告它们,您可以使用 toAdvertise 字段。
您可以公告前缀的子集,如下例所示:
FRRConfiguration CR 示例
- 1
- 广告一个前缀子集。
以下示例演示了如何公告所有前缀:
FRRConfiguration CR 示例
- 1
- 公告所有前缀。
27.8.3.3. toReceive 字段 复制链接链接已复制到粘贴板!
默认情况下,FRR-K8s 不处理邻居公告的任何前缀。您可以使用 toReceive 字段来处理此类地址。
您可以为前缀的子集配置,如下例所示:
FRRConfiguration CR 示例
以下示例将 FRR 配置为处理声明的所有前缀:
FRRConfiguration CR 示例
27.8.3.4. bgp 字段 复制链接链接已复制到粘贴板!
您可以使用 bgp 字段定义各种 BFD 配置集,并将它们与邻居关联。在以下示例中,BFD 备份 BGP 会话,FRR 可以检测链接失败:
FRRConfiguration CR 示例
27.8.3.5. nodeSelector 字段 复制链接链接已复制到粘贴板!
默认情况下,FRR-K8s 将配置应用到守护进程运行的所有节点。您可以使用 nodeSelector 字段指定要应用配置的节点。例如:
FRRConfiguration CR 示例
FRRConfiguration 自定义资源的字段在下表中描述:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定 FRR 来配置的路由器(每个 VRF 一个)。 |
|
|
| 用于会话的本地后端的自主系统编号(ASN)。 |
|
|
|
指定 |
|
|
| 指定用于建立来自此路由器会话的主机 vrf。 |
|
|
| 指定要建立 BGP 会话的邻居。 |
|
|
| 指定用于会话远程结尾的 ASN。 |
|
|
| 指定要建立会话的 IP 地址。 |
|
|
| 指定建立会话时要结束的端口。默认值为 179。 |
|
|
|
指定用来建立 BGP 会话的密码。 |
|
|
|
指定邻居的身份验证 secret 的名称。secret 必须是 "kubernetes.io/basic-auth" 类型,并且与 FRR-K8s 守护进程位于同一个命名空间中。密钥 "password" 将密码存储在 secret 中。 |
|
|
| 根据 RFC4271 指定请求的 BGP 保留时间。默认为 180s。 |
|
|
|
根据 RFC4271 指定请求的 BGP keepalive 时间。默认值为 |
|
|
| 指定 BGP 在连接尝试到邻居之间等待的时间。 |
|
|
| 指明 BGPPeer 是否离开了多跃点。 |
|
|
| 指定用于与 BGP 会话关联的 BFD 会话的 BFD Profile 名称。如果没有设置,则不会设置 BFD 会话。 |
|
|
| 表示要公告给邻居的前缀列表,以及相关的属性。 |
|
|
| 指定要公告到邻居的前缀列表。此列表必须与您在路由器中定义的前缀匹配。 |
|
|
|
指定处理前缀时要使用的模式。您可以将 |
|
|
| 指定与公告的本地首选项关联的前缀。您必须在允许公告的前缀中指定与本地首选项关联的前缀。 |
|
|
| 指定与本地首选项关联的前缀。 |
|
|
| 指定与前缀关联的本地首选项。 |
|
|
| 指定与公告的 BGP 社区关联的前缀。您必须在您要公告的前缀列表中包含与本地首选项关联的前缀。 |
|
|
| 指定与社区关联的前缀。 |
|
|
| 指定与前缀关联的社区。 |
|
|
| 指定要从邻居接收的前缀。 |
|
|
| 指定要从邻居接收的信息。 |
|
|
| 指定来自邻居的前缀。 |
|
|
|
指定处理前缀时要使用的模式。当设置为 |
|
|
| 禁用 MP BGP 以防止它将 IPv4 和 IPv6 路由划分为不同的 BGP 会话。 |
|
|
| 指定从此路由器实例公告的所有前缀。 |
|
|
| 指定配置邻居时要使用的 bfd 配置集列表。 |
|
|
| 要在配置的其他部分中引用的 BFD 配置集的名称。 |
|
|
|
指定此系统可以接收控制数据包的最小间隔(以毫秒为单位)。默认值为 |
|
|
|
指定排除 jitter 的最小传输间隔,此系统希望用来发送 BFD 控制数据包(以毫秒为单位)。默认值为 |
|
|
| 配置检测倍数以确定数据包丢失。要确定连接丢失检测计时器,请将远程传输间隔乘以这个值。 |
|
|
|
配置此系统可以处理的最小 echo receive transfer-interval (以毫秒为单位)。默认值为 |
|
|
| 启用或禁用回显传输模式。这个模式默认为禁用,在多跃点设置中不支持。 |
|
|
| 将会话标记为被动。被动会话不会尝试启动连接,并在开始回复前等待来自对等的控制数据包。 |
|
|
| 仅限多跃点会话。为传入的 BFD 控制数据包配置最低预期 TTL。 |
|
|
| 限制尝试应用此配置的节点。如果指定,则只有标签与指定选择器匹配的节点才会应用配置。如果没有指定,则所有节点都会尝试应用此配置。 |
|
|
| 定义 FRRConfiguration 的观察状态。 |
27.8.4. FRR-K8s 如何合并多个配置 复制链接链接已复制到粘贴板!
如果多个用户添加选择同一节点的配置,FRR-K8s 会合并配置。每个配置都只能扩展其他配置。这意味着,可以添加新的邻居到路由器,或向邻居公告额外的前缀,但不能删除由其他配置添加的组件。
27.8.4.1. 配置冲突 复制链接链接已复制到粘贴板!
某些配置可能会导致冲突,从而导致错误,例如:
- 同一路由器的不同 ASN (在同一 VRF 中)
- 同一邻居的不同 ASN (具有相同 IP / 端口)
- 多个带有相同名称的 BFD 配置集,但不同的值
当守护进程为节点找到无效的配置时,它会将配置报告为无效,并恢复到之前有效的 FRR 配置。
27.8.4.2. 合并 复制链接链接已复制到粘贴板!
在合并时,可以执行以下操作:
- 将您要公告的 IP 集合扩展到邻居。
- 使用 IP 集合添加额外的邻居。
- 扩展您要关联社区的 IP 集合。
- 允许邻居的传入路由。
每个配置都必须自包含。例如,通过利用来自其他配置的前缀,不允许在路由器部分中定义的前缀。
如果要应用的配置兼容,则合并可以正常工作,如下所示:
-
frr-K8s结合了所有路由器。 -
frr-K8s合并每个路由器的所有前缀和邻居。 -
frr-K8s合并每个邻居的所有过滤器。
不太严格的过滤会优先于更严格的过滤。例如,接受某些前缀的过滤会优先于不接受任何前缀的过滤,接受所有前缀的过滤优先于接受部分前缀的过滤。
27.9. MetalLB 日志记录、故障排除和支持 复制链接链接已复制到粘贴板!
如果您需要对 MetalLB 配置进行故障排除,请查看以下部分来了解常用命令。
27.9.1. 设置 MetalLB 日志记录级别 复制链接链接已复制到粘贴板!
MetalLB 在带有默认设置 info 的容器中使用 FRRouting(FRR)会生成大量日志。您可以通过设置 logLevel 来控制生成的日志的详细程度,如下例所示。
通过将 logLevel 设置为 debug 来深入了解 MetalLB,如下所示:
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
流程
创建一个文件,如
setdebugloglevel.yaml,其内容类似以下示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用配置:
oc replace -f setdebugloglevel.yaml
$ oc replace -f setdebugloglevel.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意使用
oc replace可以被理解为,metallbCR 已被创建,您在此处更改了日志级别。显示
speakerpod 的名称:oc get -n metallb-system pods -l component=speaker
$ oc get -n metallb-system pods -l component=speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE speaker-2m9pm 4/4 Running 0 9m19s speaker-7m4qw 3/4 Running 0 19s speaker-szlmx 4/4 Running 0 9m19s
NAME READY STATUS RESTARTS AGE speaker-2m9pm 4/4 Running 0 9m19s speaker-7m4qw 3/4 Running 0 19s speaker-szlmx 4/4 Running 0 9m19sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意重新创建发言人和控制器 Pod,以确保应用更新的日志记录级别。对于 MetalLB 的所有组件,会修改日志记录级别。
查看
speaker日志:oc logs -n metallb-system speaker-7m4qw -c speaker
$ oc logs -n metallb-system speaker-7m4qw -c speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 查看 FRR 日志:
oc logs -n metallb-system speaker-7m4qw -c frr
$ oc logs -n metallb-system speaker-7m4qw -c frrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.9.1.1. FRRouting(FRR)日志级别 复制链接链接已复制到粘贴板!
下表描述了 FRR 日志记录级别。
| 日志级别 | 描述 |
|---|---|
|
| 为所有日志记录级别提供所有日志信息。 |
|
|
这些信息有助于相关人员进行问题诊断。设置为 |
|
| 提供始终应记录的信息,但在正常情况下,不需要用户干预。这是默认的日志记录级别。 |
|
|
任何可能导致 |
|
|
对 |
|
| 关闭所有日志。 |
27.9.2. BGP 故障排除问题 复制链接链接已复制到粘贴板!
红帽支持在 speaker Pod 的容器中使用 FRRouting(FRR)的 BGP 实施。作为集群管理员,如果您需要对 BGP 配置问题进行故障排除,您需要在 FRR 容器中运行命令。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
流程
显示
speakerpod 的名称:oc get -n metallb-system pods -l component=speaker
$ oc get -n metallb-system pods -l component=speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 56m speaker-gvfnf 4/4 Running 0 56m ...
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 56m speaker-gvfnf 4/4 Running 0 56m ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 显示 FRR 的运行配置:
oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show running-config"
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show running-config"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 显示 BGP 概述:
oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp summary"
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp summary"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 显示接收地址池的 BGP 对等点:
oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp ipv4 unicast 203.0.113.200/30"
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp ipv4 unicast 203.0.113.200/30"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
ipv4替换为ipv6,以显示接收 IPv6 地址池的 BGP 对等点。将203.0.113.200/30替换为地址池的 IPv4 或 IPv6 IP 地址范围。输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 确认输出中包含 BGP peer 的 IP 地址。
27.9.3. BFD 问题故障排除 复制链接链接已复制到粘贴板!
红帽支持双向转发检测(BFD)实施,在 speaker Pod 中使用 FRRouting(FRR)。BFD 实施依赖于 BFD 对等点,也被配置为带有已建立的 BGP 会话的 BGP 对等点。作为集群管理员,如果您需要排除 BFD 配置问题,则需要在 FRR 容器中运行命令。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
流程
显示
speakerpod 的名称:oc get -n metallb-system pods -l component=speaker
$ oc get -n metallb-system pods -l component=speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 26m speaker-gvfnf 4/4 Running 0 26m ...
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 26m speaker-gvfnf 4/4 Running 0 26m ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 显示 BFD 对等点:
oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bfd peers brief"
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bfd peers brief"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Session count: 2 SessionId LocalAddress PeerAddress Status ========= ============ =========== ====== 3909139637 10.0.1.2 10.0.2.3 up <.>
Session count: 2 SessionId LocalAddress PeerAddress Status ========= ============ =========== ====== 3909139637 10.0.1.2 10.0.2.3 up <.>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确认
PeerAddress列包含每个 BFD 对等点。如果输出没有列出输出要包含的 BFD peer IP 地址,并与 peer 对 BGP 连接性进行故障排除。如果状态字段显示down,请检查在节点和对等点间的链接和设备连接。您可以使用oc get pods -n metallb-system speaker-66bth -o jsonpath='{.spec.nodeName}'命令确定 speaker pod 的节点名称。
27.9.4. BGP 和 BFD 的 MetalLB 指标 复制链接链接已复制到粘贴板!
OpenShift Container Platform 捕获与 BGP peer 和 BFD 配置集相关的 MetalLB 的以下 Prometheus 指标。
| Name | 描述 |
|---|---|
|
| 统计从每个 BFD peer 接收的 BFD 控制数据包的数量。 |
|
| 统计发送到每个 BFD 对等点的 BFD 控制数据包的数量。 |
|
| 统计从每个 BFD 对等点接收的 BFD 回显数据包的数量。 |
|
| 计算发送到每个 BFD 的 BFD 回显数据包的数量。 |
|
|
统计 BFD 会话进入 |
|
|
指示与 BFD 对等点的连接状态。 |
|
|
统计 BFD 会话进入 |
|
| 统计每个 BFD Zebra 通知的数量。 |
| Name | 描述 |
|---|---|
|
| 计算公告给 BGP 对等的负载均衡器 IP 地址前缀的数量。术语 前缀(prefix) 和聚合路由(aggregated route) 具有相同的含义。 |
|
|
指示与 BGP 对等点的连接状态。 |
|
| 计算发送到每个 BGP 对等点的 BGP 更新消息数量。 |
|
| 计算发送到每个 BGP 对等点的 BGP 打开消息数量。 |
|
| 计算从每个 BGP 对等点接收的 BGP 打开消息的数量。 |
|
| 计算发送到每个 BGP 对等点的 BGP 通知消息数量。 |
|
| 计算从每个 BGP 对等点接收的 BGP 更新消息数量。 |
|
| 计算发送到每个 BGP 对等点的 BGP keepalive 消息数量。 |
|
| 计算从每个 BGP 对等点接收的 BGP keepalive 消息数量。 |
|
| 计算发送到每个 BGP 对等点的 BGP 路由刷新消息的数量。 |
|
| 计算发送到每个 BGP 对等点的 BGP 消息总数。 |
|
| 计算从每个 BGP 对等点接收的 BGP 消息总数。 |
其他资源
- 有关使用监控仪表板的信息,请参阅使用监控仪表板查询所有项目的指标。
27.9.5. 关于收集 MetalLB 数据 复制链接链接已复制到粘贴板!
您可以使用 oc adm must-gather CLI 命令来收集有关集群、MetalLB 配置和 MetalLB Operator 的信息。以下功能和对象与 MetalLB 和 MetalLB Operator 关联:
- 在其中部署 MetalLB Operator 的命名空间和子对象
- 所有 MetalLB Operator 自定义资源定义(CRD)
oc adm must-gather CLI 命令会收集红帽用来实施 BGP 和 BFD 的 FRRouting(FRR)的以下信息:
-
/etc/frr/frr.conf -
/etc/frr/frr.log -
/etc/frr/daemons配置文件 -
/etc/frr/vtysh.conf
上述列表中的日志和配置文件从每个 speaker pod 中的 frr 容器收集。
除了日志和配置文件外,oc adm must-gather CLI 命令还会从以下 vtysh 命令收集输出:
-
show running-config -
show bgp ipv4 -
show bgp ipv6 -
show bgp neighbor -
show bfd peer
运行 oc adm must-gather CLI 命令时不需要额外的配置。
其他资源
第 28 章 将二级接口指标与网络附加关联 复制链接链接已复制到粘贴板!
管理员可以使用 pod_network_info 指标来分类和监控二级网络接口。指标通过添加标识接口类型的标签(通常基于关联的 NetworkAttachmentDefinition 资源)来实现此目的。
28.1. 为监控扩展二级网络指标 复制链接链接已复制到粘贴板!
二级设备或接口用于不同目的。需要对二级网络接口的指标进行分类,以允许有效的聚合和监控。
公开的指标会包括接口,但不会指定接口的起始位置。当没有其他接口时,这可以正常工作。但是,当添加二级接口时,依赖接口名称会变得有问题,因为很难识别其目的并有效地使用其指标。
添加二级接口时,它们的名称取决于添加它们的顺序。二级接口可以属于不同的网络,它们各自满足不同的目的。
通过使用 pod_network_name_info,可以使用标识接口类型的额外信息来扩展当前的指标。这样,就可以聚合指标,并为特定接口类型添加特定的警告。
网络类型从 NetworkAttachmentDefinition 资源的名称生成,用于区分不同的二级网络类。例如,属于不同网络或使用不同的 CNI 的不同接口使用不同的网络附加定义名称。
28.2. 网络指标守护进程 复制链接链接已复制到粘贴板!
网络指标守护进程是收集并发布与网络相关的指标的守护进程组件。
kubelet 已经发布了您可以观察到的网络相关指标。这些指标是:
-
container_network_receive_bytes_total -
container_network_receive_errors_total -
container_network_receive_packets_total -
container_network_receive_packets_dropped_total -
container_network_transmit_bytes_total -
container_network_transmit_errors_total -
container_network_transmit_packets_total -
container_network_transmit_packets_dropped_total
这些指标中的标签包括:
- Pod 名称
- Pod 命名空间
-
接口名称(比如
eth0)
这些指标在为 pod 添加新接口之前(例如通过 Multus )可以正常工作。在添加了新接口后,无法清楚地知道接口名称代表什么。
interface 标签指向接口名称,但它不知道接口的作用是什么。在有多个不同接口的情况下,无法了解您监控的指标代表什么网络。
现在引入了新的 pod_network_name_info 可以帮助解决这个问题。
28.3. 带有网络名称的指标 复制链接链接已复制到粘贴板!
Network Metrics daemonset 发布 pod_network_name_info 量表指标,固定值为 0。
pod_network_name_info示例
pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
使用 Multus 所添加的注解生成网络名称标签。它是网络附加定义所属命名空间的连接,加上网络附加定义的名称。
新的指标本身不会提供很多值,但与网络相关的 container_network_* 指标一起使用,可以为二集网络的监控提供更好的支持。
通过使用类似以下的 promql 查询,可以获取包含值的新指标,以及从 k8s.v1.cni.cncf.io/network-status 注解中检索的网络名称:
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.