红帽全球峰会This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.网络
配置和管理集群网络
摘要
第 1 章 了解网络
集群管理员有几个选项可将集群中运行的应用程序公开给外部流量并保护网络连接安全：
- 服务类型，如节点端口或负载均衡器
-
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 对底层网络基础架构的访问权限。
1.1. OpenShift Container Platform DNS
如果您运行多个服务，比如使用多个 pod 的前端和后端服务，则要为用户名和服务 IP 等创建环境变量，使前端 pod 可以跟后端服务通信。如果删除并重新创建服务，可以为该服务分配一个新的 IP 地址，而且需要重新创建前端 pod 来获取服务 IP 环境变量的更新值。另外，必须在任何前端 pod 之前创建后端服务，以确保正确生成服务 IP，并将它作为环境变量提供给前端 pod。
因此，OpenShift Container Platform 具有一个内置 DNS，以便服务 DNS 以及服务 IP/端口能够访问这些服务。
1.2. OpenShift Container Platform Ingress Operator
在创建 OpenShift Container Platform 集群时，在集群中运行的 Pod 和服务会各自分配自己的 IP 地址。IP 地址可供附近运行的其他容器集和服务访问，但外部客户端无法访问这些 IP 地址。Ingress Operator 实现 IngressController API，是负责启用对 OpenShift Container Platform 集群服务的外部访问的组件。
Ingress Operator 通过部署和管理一个或多个基于 HAProxy 的 Ingress Controller 来处理路由，使外部客户端可以访问您的服务。您可以通过指定 OpenShift Container Platform Route 和 Kubernetes Ingress 资源，来使用 Ingress Operator 路由流量。Ingress Controller 中的配置（如定义 endpointPublishingStrategy 类型和内部负载平衡）提供了发布 Ingress Controller 端点的方法。
1.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 章 访问主机
了解如何创建堡垒主机来访问 OpenShift Container Platform 实例，以及使用安全 shell (SSH) 访问 control plane 节点（也称为 master 节点）。
2.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 主机（也称为 master 主机）。确定您使用了在安装过程中指定的相同的 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
第 3 章 网络 Operator 概述
OpenShift Container Platform 支持多种类型的网络 Operator。您可以使用这些网络 Operator 管理集群网络。
3.1. Cluster Network Operator
Cluster Network Operator(CNO)在 OpenShift Container Platform 集群中部署和管理集群网络组件。这包括在安装过程中为集群选择的 Container Network Interface(CNI)默认网络供应商插件部署。如需更多信息，请参阅 OpenShift Container Platform 中的 Cluster Network Operator。
3.2. DNS Operator
DNS Operator 部署并管理 CoreDNS，以便为 pod 提供名称解析服务。这会在 OpenShift Container Platform 中启用基于 DNS 的 Kubernetes 服务发现。如需更多信息，请参阅 OpenShift Container Platform 中的 DNS Operator。
3.3. Ingress Operator
创建 OpenShift Container Platform 集群时，集群中运行的 pod 和服务将为每个分配的 IP 地址。IP 地址可以被其他 pod 和服务访问，但外部客户端无法访问。Ingress Operator 实现 Ingress Controller API，并负责启用对 OpenShift Container Platform 集群服务的外部访问。如需更多信息，请参阅 OpenShift Container Platform 中的 Ingress Operator。
Cluster Network Operator（CNO）在 OpenShift Container Platform 集群上部署和管理集群网络组件，包括在安装过程中为集群选择的 Container Network Interface（CNI）默认网络供应商插件。
4.1. Cluster Network Operator
Cluster Network Operator 从 operator.openshift.io API 组实现 network API。Operator 通过使用守护进程集，部署 OpenShift SDN 默认 Container Network Interface（CNI）网络供应商插件，或部署您在集群安装过程中选择的默认网络供应商插件。
流程
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.5.4 True False False 50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.5.4 True False False 50mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下字段提供有关 Operator 状态的信息：
AVAILABLE、Progressing和DEGRADED。当 Cluster Network Operator 报告可用状态条件时，AVAILABLE字段为True。
4.2. 查看集群网络配置
每个 OpenShift Container Platform 新安装都有一个名为 cluster 的 network.config 对象。
4.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
4.4. 查看 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
4.5. 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- 集群网络供应商，如 OpenShift SDN 或 OVN-Kubernetes。
在集群安装后，您无法修改上一节中列出的字段。
您可以通过在名为 cluster 的 CNO 对象中设置 defaultNetwork 对象的字段来为集群指定集群网络供应商配置。
4.5.1. Cluster Network Operator 配置对象
Cluster Network Operator（CNO）的字段在下表中描述：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNO 对象的名称。这个名称始终是 |
|
|
| 用于指定从哪些 IP 地址块分配 Pod IP 地址以及分配给集群中每个节点的子网前缀长度的列表。例如：
此值是只读的，在集群安装过程中从名为 |
|
|
| 服务的 IP 地址块。OpenShift SDN 和 OVN-Kubernetes Container Network Interface（CNI）网络供应商只支持服务网络具有单个 IP 地址块。例如： spec: serviceNetwork: - 172.30.0.0/14
此值是只读的，在集群安装过程中从名为 |
|
|
| 为集群网络配置 Container Network Interface（CNI）集群网络供应商。 |
|
|
| 此对象的字段指定 kube-proxy 配置。如果您使用 OVN-Kubernetes 集群网络供应商，则 kube-proxy 的配置不会起作用。 |
defaultNetwork 对象配置
defaultNetwork 对象的值在下表中定义：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
注意 OpenShift Container Platform 默认使用 OpenShift SDN Container Network Interface（CNI）集群网络供应商。 |
|
|
| 此对象仅对 OpenShift SDN 集群网络供应商有效。 |
|
|
| 此对象仅对 OVN-Kubernetes 集群网络供应商有效。 |
配置 OpenShift SDN CNI 集群网络供应商
下表描述了 OpenShift SDN Container Network Interface（CNI）集群网络供应商的配置字段。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| OpenShift SDN 的网络隔离模式。 |
|
|
| VXLAN 覆盖网络的最大传输单元 (MTU) 。这个值通常是自动配置的。 |
|
|
|
用于所有 VXLAN 数据包的端口。默认值为 |
您只能在集群安装过程中更改集群网络供应商的配置。
OpenShift SDN 配置示例
配置 OVN-Kubernetes CNI 集群网络供应商
下表描述了 OVN-Kubernetes CNI 集群网络供应商的配置字段。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| Geneve（Generic Network Virtualization Encapsulation）覆盖网络的最大传输单元（MTU）。这个值通常是自动配置的。 |
|
|
| Geneve 覆盖网络的 UDP 端口。 |
|
|
| 如果存在该字段，则会为集群启用 IPsec。 |
您只能在集群安装过程中更改集群网络供应商的配置。
OVN-Kubernetes 配置示例
kubeProxyConfig 对象配置
kubeProxyConfig 对象的值在下表中定义：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
注意
由于 OpenShift Container Platform 4.3 及更高版本中引进了性能上的改进，现在不再需要调整 |
|
|
|
刷新 kubeProxyConfig:
proxyArguments:
iptables-min-sync-period:
- 0s
|
4.5.2. Cluster Network Operator 配置示例
以下示例中指定了完整的 CNO 配置：
Cluster Network Operator 对象示例
第 5 章 OpenShift Container Platform 中的 DNS Operator
DNS Operator 部署并管理 CoreDNS，以便为 Pod 提供名称解析服务，从而在 OpenShift 中启用基于 DNS 的 Kubernetes 服务发现。
5.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 dns 4.1.0-0.11 True False False 92m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE dns 4.1.0-0.11 True False False 92mCopy to Clipboard Copied! Toggle word wrap Toggle overflow AVAILABLE、PROGRESSING和DEGRADED提供了有关 Operator 状态的信息。当 CoreDNS 守护进程中至少有一个 pod 被设置为Available状态时，AVAILABLE为True。
5.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，使用
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
输出示例
[172.30.0.0/16]
[172.30.0.0/16]5.3. 使用 DNS 转发
您可以针对一个区（zone），使用 DNS 转发来覆盖 /etc/resolv.conf 中指定的转发配置，方法是指定这个区使用哪个名称解析服务器。如果转发区是 OpenShift Container Platform 管理的 Ingress 域，那么上游名称服务器必须为域授权。
流程
修改名为
default的 DNS Operator 对象：oc edit dns.operator/default
$ oc edit dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这允许 Operator 使用基于
Server的额外服务器配置块来创建和更新名为dns-default的 ConfigMap。如果没有服务器带有与查询匹配的区，则命名解析功能会返回到由/etc/resolv.conf中指定的名称服务器。DNS 示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果
servers未定义或无效，则 ConfigMap 只包括默认服务器。查看 ConfigMap：
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 基于以上 DNS 示例的 DNS ConfigMap 示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 对
forwardPlugin的更改会触发 CoreDNS 守护进程集的滚动更新。
5.4. DNS Operator 状态
您可以使用 oc describe 命令来检查状态并查看 DNS Operator 的详情。
流程
查看 DNS Operator 的状态：
oc describe clusteroperators/dns
$ oc describe clusteroperators/dns5.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-operator第 6 章 OpenShift Container Platform 中的 Ingress Operator
6.1. OpenShift Container Platform Ingress Operator
在创建 OpenShift Container Platform 集群时，在集群中运行的 Pod 和服务会各自分配自己的 IP 地址。IP 地址可供附近运行的其他容器集和服务访问，但外部客户端无法访问这些 IP 地址。Ingress Operator 实现 IngressController API，是负责启用对 OpenShift Container Platform 集群服务的外部访问的组件。
Ingress Operator 通过部署和管理一个或多个基于 HAProxy 的 Ingress Controller 来处理路由，使外部客户端可以访问您的服务。您可以通过指定 OpenShift Container Platform Route 和 Kubernetes Ingress 资源，来使用 Ingress Operator 路由流量。Ingress Controller 中的配置（如定义 endpointPublishingStrategy 类型和内部负载平衡）提供了发布 Ingress Controller 端点的方法。
6.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资源生成默认主机时，还会使用此域。
6.3. Ingress 控制器配置参数
ingresscontrollers.operator.openshift.io 资源提供了以下配置参数。
| 参数 | 描述 |
|---|---|
|
|
一个
如果为空，默认值为 |
|
|
|
|
|
如果没有设置，则默认值基于
|
|
|
secret 必须包含以下密钥和数据：*
如果没有设置，则自动生成和使用通配符证书。该证书对 Ingress Controller 的 内部证书（无论是生成的证书还是用户指定的证书）自动与 OpenShift Container Platform 内置的 OAuth 服务器集成。 |
|
|
|
|
|
|
|
|
如果没有设置，则使用默认值。 注意
|
|
|
如果没有设置，则默认值基于
当使用
Ingress 控制器的 TLS 的最低版本是 重要
HAProxy Ingress controller 镜像不支持 TLS
Ingress Operator 还会将
OpenShift Container Platform 路由器启用 Red Hat-distributed OpenSSL 默认集合 TLS 注意
加密器和配置的安全配置集的最小 TLS 版本反映在 |
|
|
|
|
|
|
|
|
通过为
默认情况下，策略设置为
|
所有参数都是可选的。
6.3.1. Ingress Controller TLS 安全配置集
TLS 安全配置文件为服务器提供了一种方式，以规范连接的客户端在连接服务器时可以使用哪些密码。
6.3.1.1. 了解 TLS 安全配置集
您可以使用 TLS（Transport Layer Security）安全配置集来定义各种 OpenShift Container Platform 组件需要哪些 TLS 密码。OpenShift Container Platform TLS 安全配置集基于 Mozilla 推荐的配置。
您可以为每个组件指定以下 TLS 安全配置集之一：
| 配置集 | 描述 |
|---|---|
|
| 此配置集用于旧的客户端或库。该配置集基于旧的向后兼容性建议配置。
注意 对于 Ingress Controller，最小 TLS 版本从 1.0 转换为 1.1。 |
|
| 这个配置集是大多数客户端的建议配置。它是 Ingress Controller 和 control plane 的默认 TLS 安全配置集。该配置集基于 Intermediate 兼容性推荐的配置。
|
|
| 此配置集主要用于不需要向后兼容的现代客户端。这个配置集基于 Modern 兼容性推荐的配置。
注意
在 OpenShift Container Platform 4.6、4.7 和 4.8 中，Meder 重要
|
|
| 此配置集允许您定义要使用的 TLS 版本和密码。 警告
使用 注意
OpenShift Container Platform 路由器启用 Red Hat-istributed OpenSSL 默认 TLS |
当使用预定义的配置集类型时，有效的配置集配置可能会在发行版本之间有所改变。例如，使用在版本 X.Y.Z 中部署的 Intermediate 配置集指定了一个规格，升级到版本 X.Y.Z+1 可能会导致应用新的配置集配置，从而导致推出部署。
6.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 配置集需要 TLS 1.3，因此不支持它。Ingress Operator 会将 Modern 配置集转换为 Intermediate。Ingress Operator 还会将 Old 或 Custom 配置集的 TLS 1.0 转换为 1.1，将Custom 配置集的 TLS 1.3 转换为 1.2。
先决条件
-
您可以使用具有
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
6.3.2. Ingress 控制器端点发布策略
NodePortService 端点发布策略
NodePortService 端点发布策略使用 Kubernetes NodePort 服务发布 Ingress Controller。
在这个配置中，Ingress Controller 部署使用容器网络。创建了一个 NodePortService 来发布部署。特定的节点端口由 OpenShift Container Platform 动态分配; 但是，为了支持静态端口分配，您会保留对受管 NodePortService 的节点端口字段的更改 。
图 6.1. 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 控制器每个节点只能有一个 pod 副本。如果您想要 n 个副本，则必须至少使用可调度这些副本的 n 个节点。因为每个 Pod 副本都会通过调度的节点主机上的端口 80 和 443 进行请求，所以如果同一节点上的其他 pod 使用这些端口，则无法将副本调度到该节点。
6.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
6.5. 查看 Ingress Operator 状态
您可以查看并检查 Ingress Operator 的状态。
流程
查看您的 Ingress Operator 状态：
oc describe clusteroperators/ingress
$ oc describe clusteroperators/ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6. 查看 Ingress Controller 日志
您可以查看 Ingress Controller 日志。
流程
查看 Ingress Controller 日志：
oc logs --namespace=openshift-ingress-operator deployments/ingress-operator
$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.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
6.8. 配置 Ingress Controller
6.8.1. 设置自定义默认证书
作为管理员，您可以通过创建 Secret 资源并编辑 IngressController 自定义资源 (CR)，将 Ingress Controller 配置为使用自定义证书。
先决条件
- 您必须在 PEM 编码文件中有一个证书/密钥对，其中该证书由可信证书认证机构签名，或者由您在一个自定义 PKI 中配置的私有可信证书认证机构签名。
您的证书满足以下要求：
- 该证书对入口域有效。
-
证书使用
subjectAltName扩展来指定通配符域，如*.apps.ocp4.example.com。
您必须有一个
IngressControllerCR。您可以使用默认值：oc --namespace openshift-ingress-operator get ingresscontrollers
$ oc --namespace openshift-ingress-operator get ingresscontrollersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME AGE default 10m
NAME AGE default 10mCopy 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 证书 Secret 名称应该与用来更新 CR 的值匹配。
修改了 IngressController CR 后，Ingress Operator 将更新 Ingress Controller 的部署以使用自定义证书。
6.8.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
6.8.3. 扩展 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 输出示例
2
2Copy 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.operator.openshift.io/default patched
ingresscontroller.operator.openshift.io/default patchedCopy 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 输出示例
3
3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
扩展不是立刻就可以完成的操作，因为它需要时间来创建所需的副本数。
6.8.4. 配置 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.endpoint指定一个目的地端点，并可使用spec.logging.access.destination.syslog.facility指定一个工具。以下示例是将日志记录到Syslog目的地的 Ingress Controller 定义：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意Syslog目的地端口必须是 UDP。
使用特定的日志格式配置 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
6.8.5. Ingress Controller 分片
Ingress Controller 或路由器是网络流量进入集群的主要机制，因此对它们的需求可能非常大。作为集群管理员，您可以对路由进行分片，以达到以下目的：
- 在 Ingress Controller 或路由器与一些路由之间实现平衡，由此加快对变更的响应。
- 分配特定的路由，使其具有不同于其它路由的可靠性保证。
- 允许特定的 Ingress Controller 定义不同的策略。
- 只允许特定的路由使用其他功能。
- 在不同的地址上公开不同的路由，例如使内部和外部用户能够看到不同的路由。
Ingress Controller 可以使用路由标签或命名空间标签作为分片方法。
6.8.5.1. 通过路由标签（label）配置 Ingress Controller 分片
使用路由标签进行 Ingress Controller 分片，意味着 Ingress Controller 提供由路由选择器选择的任意命名空间中的所有路由。
在一组 Ingress Controller 之间平衡传入的流量负载时，以及在将流量隔离到特定 Ingress Controller 时，Ingress Controller 分片会很有用处。例如，A 公司的流量使用一个 Ingress Controller，B 公司的流量则使用另外一个 Ingress Controller。
流程
编辑
router-internal.yaml文件：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 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标签的任意命名空间中的路由。
6.8.5.2. 使用命名空间标签配置 Ingress Controller 分片
使用命名空间标签进行 Ingress Controller 分片，意味着 Ingress Controller 提供由命名空间选择器选择的任意命名空间中的所有路由。
在一组 Ingress Controller 之间平衡传入的流量负载时，以及在将流量隔离到特定 Ingress Controller 时，Ingress Controller 分片会很有用处。例如，A 公司的流量使用一个 Ingress Controller，B 公司的流量则使用另外一个 Ingress Controller。
如果部署 Keepalived Ingress VIP，请不要为 endpointPublishingStrategy 参数部署一个值为 HostNetwork 的非默认 Ingress Controller。这样做可能会导致问题。将值 NodePort 而不是 HostNetwork 用于 endpointPublishingStrategy。
流程
编辑
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 应用 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标签的任意命名空间中的路由。
6.8.6. 配置 Ingress Controller 以使用内部负载均衡器
当在云平台上创建 Ingress Controller 时，Ingress Controller 默认由一个公共云负载均衡器发布。作为管理员，您可以创建一个使用内部云负载均衡器的 Ingress Controller。
如果云供应商是 Microsoft Azure，则必须至少有一个指向节点的公共负载均衡器。如果不这样做，所有节点都将丢失到互联网的出站连接。
如果要更改 IngressController 对象的 scope ，您必须删除并重新创建 IngressController 对象。您无法在创建自定义资源 (CR) 后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。
图 6.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
6.8.7. 将集群的默认 Ingress Controller 配置为内部
您可以通过删除并重新它来将默认 Ingress Controller 配置为内部。
如果云供应商是 Microsoft Azure，则必须至少有一个指向节点的公共负载均衡器。如果不这样做，所有节点都将丢失到互联网的出站连接。
如果要更改 IngressController 对象的 scope ，您必须删除并重新创建 IngressController 对象。您无法在创建自定义资源 (CR) 后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。
先决条件
-
安装 OpenShift CLI（
oc）。 -
以具有
cluster-admin特权的用户身份登录。
流程
通过删除并重新创建集群，将
默认Ingress Controller 配置为内部。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.8.8. 配置路由准入策略
管理员和应用程序开发人员可在多个命名空间中运行具有相同域名的应用程序。这是针对多个团队开发的、在同一个主机名上公开的微服务的机构。
只有在命名空间间有信任的集群才会启用跨命名空间之间的声明，否则恶意用户可能会接管主机名。因此，默认的准入策略不允许在命名空间间声明主机名。
先决条件
- 必须具有集群管理员权限。
流程
使用以下命令编辑
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
6.8.9. 使用通配符路由
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
6.8.10. 使用 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
使用案例示例
作为集群管理员，您可以：
配置将
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 的全局设置值。
6.8.11. 启用 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 路由，而不适用于 nsecure 或 edge-terminated 路由。
使用重新加密路由，在 Ingress Controller 上启用了 HTTP/2 的 WebSockets 需要通过 HTTP/2 支持 WebSocket。HTTP/2 的 websocket 是 HAProxy 2.4 的一个功能，目前在 OpenShift Container Platform 中不被支持。
对于非 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 协议。
流程
在单一 Ingress Controller 上启用 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=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<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
6.8.12. 使用 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 文件：
test.example.com的appsDomain配置示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
通过公开路由并验证路由域更改，验证现有路由是否包含
appsDomain字段中指定的域名：注意在公开路由前，等待
openshift-apiserver完成滚动更新。公开路由：
oc expose service hello-openshift route.route.openshift.io/hello-openshift exposed
$ oc expose service hello-openshift route.route.openshift.io/hello-openshift exposedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例：
oc get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hello-openshift hello_openshift-<my_project>.test.example.com hello-openshift 8080-tcp None
$ oc get routes 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
第 7 章 验证到端点的连接
Cluster Network Operator（CNO）运行一个控制器（连接检查控制器），用于在集群的资源间执行连接健康检查。通过查看健康检查的结果，您可以诊断连接问题或解决网络连接问题，将其作为您要调查的问题的原因。
7.1. 执行连接健康检查
要验证集群资源是否可以访问，请向以下集群 API 服务的每个服务都有一个 TCP 连接：
- Kubernetes API 服务器服务
- Kubernetes API 服务器端点
- OpenShift API 服务器服务
- OpenShift API 服务器端点
- 负载均衡器
要验证服务和服务端点是否可在集群中的每个节点上访问，请对以下每个目标都进行 TCP 连接：
- 健康检查目标服务
- 健康检查目标端点
7.2. 连接健康检查实现
在集群中，连接检查控制器或编配连接验证检查。连接测试的结果存储在 openshift-network-diagnostics 命名空间中的 PodNetworkConnectivity 对象中。连接测试会每分钟以并行方式执行。
Cluster Network Operator（CNO）将几个资源部署到集群，以发送和接收连接性健康检查：
- 健康检查源
-
此程序部署在一个由
Deployment对象管理的单个 pod 副本集中。程序会消耗PodNetworkConnectivity对象，并连接到每个对象中指定的spec.targetEndpoint。 - 健康检查目标
- pod 作为集群中每个节点上的守护进程集的一部分部署。pod 侦听入站健康检查。在每个节点上存在这个 pod 可以测试到每个节点的连接。
7.3. PodNetworkConnectivityCheck 对象字段
PodNetworkConnectivityCheck 对象字段在下表中描述。
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
对象的名称，其格式如下：
|
|
|
|
与对象关联的命名空间。此值始终为 |
|
|
|
连接检查来源于的 pod 的名称，如 |
|
|
|
连接检查的目标，如 |
|
|
| 要使用的 TLS 证书配置。 |
|
|
| 使用的 TLS 证书的名称（若有）。默认值为空字符串。 |
|
|
| 代表连接测试条件和最近连接发生和失败的日志的对象。 |
|
|
| 连接检查以及任何之前的状态的最新状态。 |
|
|
| 连接测试日志不会失败。 |
|
|
| 涵盖任何中断的时间连接测试日志。 |
|
|
| 成功尝试的连接测试日志。 |
下表描述了 status.conditions 阵列中对象的字段：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 连接条件从一个状态转换到另一个状态的时间。 |
|
|
| 有关最后一次转换的详情（人类可读的格式）。 |
|
|
| 有关最后一次转换的详情（机器可读的格式）。 |
|
|
| 条件的状态。 |
|
|
| 条件的类型。 |
下表描述了 status.conditions 阵列中对象的字段：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 连接失败时的时间戳。 |
|
|
| 连接日志条目，包括与成功关闭相关的日志条目。 |
|
|
| 以人类可读格式显示停机详情概述。 |
|
|
| 第一次检测到连接失败时的时间戳。 |
|
|
| 连接日志条目，包括原始失败。 |
连接日志字段
下表中描述了连接日志条目的字段。该对象用于以下字段：
-
status.failures[] -
status.successes[] -
status.outages[].startLogs[] -
status.outages[].endLogs[]
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 记录操作的持续时间。 |
|
|
| 以人类可读格式提供的状态信息。 |
|
|
|
以可读格式提供状态的原因。这个值是 |
|
|
| 指明日志条目是否成功或失败。 |
|
|
| 连接检查的开始时间。 |
7.4. 验证端点的网络连接
作为集群管理员，您可以验证端点的连接性，如 API 服务器、负载均衡器、服务或 Pod。
先决条件
-
安装 OpenShift CLI（
oc）。 -
使用具有
cluster-admin角色的用户访问集群。
流程
要列出当前的
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
第 8 章 配置节点端口服务范围
作为集群管理员，您可以扩展可用的节点端口范围。如果您的集群使用大量节点端口，可能需要增加可用端口的数量。
默认端口范围为 30000-32767。您永远不会缩小端口范围，即使您首先将其扩展超过默认范围。
8.1. 先决条件
-
集群基础架构必须允许访问您在扩展范围内指定的端口。例如，如果您将节点端口范围扩展到
30000-32900，防火墙或数据包过滤配置必须允许32768-32900端口范围。
8.2. 扩展节点端口范围
您可以扩展集群的节点端口范围。
先决条件
-
安装 OpenShift CLI（
oc）。 -
使用具有
cluster-admin权限的用户登陆到集群。
流程
要扩展节点端口范围，请输入以下命令。将
<port>替换为新范围内的最大端口号码。oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'$ oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'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-33000"]
"service-node-port-range":["30000-33000"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 9 章 在裸机集群中使用流控制传输协议 (SCTP)
作为集群管理员，您可以使用集群中的流控制传输协议 (SCTP)。
9.1. 支持 OpenShift Container Platform 上的流控制传输协议 (SCTP)
作为集群管理员，您可以在集群中的主机上启用 SCTP。在 Red Hat Enterprise Linux CoreOS (RHCOS) 上，SCTP 模块被默认禁用。
SCTP 是基于信息的可靠协议，可在 IP 网络之上运行。
启用后，您可以使用 SCTP 作为带有 pod、服务和网络策略的协议。Service 对象必须通过将 type 参数设置为 ClusterIP 或 NodePort 值来定义。
9.1.1. 使用 SCTP 协议的示例配置
您可以通过将 pod 或服务对象中的 protocol 参数设置为 SCTP 来将 pod 或服务配置为使用 SCTP。
在以下示例中，pod 被配置为使用 SCTP:
在以下示例中，服务被配置为使用 SCTP:
在以下示例中，NetworkPolicy 对象配置为对来自具有特定标签的任何 pod 的端口 80 应用 SCTP 网络流量：
9.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
9.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
第 10 章 配置 PTP 硬件
精确时钟协议 (PTP) 硬件只是技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。
10.1. 关于 PTP 硬件
OpenShift Container Platform 包含在节点上使用 PTP（Precision Time Protocol） 硬件的能力。您可以在具有 PTP 功能硬件的集群中配置 linuxptp 服务。
PTP Operator 只适用于仅在裸机基础架构上置备的集群上具有 PTP 功能的设备。
您可以通过部署 PTP Operator，使用 OpenShift Container Platform 控制台来安装 PTP。PTP Operator 会创建和管理 linuxptp 服务。Operator 提供以下功能：
- 在集群中发现具有 PTP 功能的设备。
- 管理 linuxptp 服务的配置。
10.2. 自动发现 PTP 网络设备
PTP Operator 将 NodePtpDevice.ptp.openshift.io 自定义资源定义（CRD）添加到 OpenShift Container Platform。PTP Operator 将搜索集群中每个节点上的具有 PTP 功能的网络设备。Operator 会为每个提供兼容 PTP 设备的节点创建和更新 NodePtpDevice 自定义资源（CR）对象。
为每个节点创建一个 CR，并共享与该节点相同的名称。.status.devices 列表提供有关节点上 PTP 设备的信息。
以下是由 PTP Operator 创建的 NodePtpDevice CR 示例：
10.3. 安装 PTP Operator
作为集群管理员，您可以使用 OpenShift Container Platform CLI 或 Web 控制台来安装 PTP Operator。
10.3.1. CLI：安装 PTP Operator
作为集群管理员，您可以使用 CLI 安装 Operator。
先决条件
- 在裸机中安装有支持 PTP 硬件的节点的集群。
-
安装 OpenShift CLI（
oc）。 -
以具有
cluster-admin特权的用户身份登录。
流程
要为 PTP Operator 创建命名空间，输入以下命令：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要为 Operator 创建 Operator 组，输入以下命令：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 订阅 PTP Operator。
运行以下命令，将 OpenShift Container Platform 主版本和次版本设置为环境变量，该变量在下一步中作为
channel的值。OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要为 PTP Operator 创建订阅，输入以下命令：
Copy 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 ptp-operator.4.4.0-202006160135 Succeeded
Name Phase ptp-operator.4.4.0-202006160135 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3.2. Web 控制台：安装 PTP Operator
作为集群管理员，您可以使用 Web 控制台安装 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 的日志。
10.4. 配置 Linuxptp 服务
PTP Operator 将 PtpConfig.ptp.openshift.io 自定义资源定义 (CRD) 添加至 OpenShift Container Platform。您可以通过创建 PtpConfig 自定义资源（CR）对象来配置 Linuxptp 服务（ptp4l、phc2sys）。
先决条件
-
安装 OpenShift CLI（
oc）。 -
以具有
cluster-admin特权的用户身份登录。 - 已安装了 PTP Operator。
流程
创建以下
PtpConfigCR，然后在<name>-ptp-config.yaml文件中保存 YAML。使用配置的实际名称替换<name>。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 为
PtpConfigCR 指定名称。 - 2
- 指定安装 PTP Operator 的命名空间。
- 3
- 指定包括一个或多个
profile的数组。 - 4
- 指定用于唯一标识配置集（profile）对象的配置集对象名称。
- 5
- 指定
ptp4l服务要使用的网络接口名称，如ens787f1。 - 6
- 为
ptp4l服务指定系统配置选项，如-s -2。这不应该包含接口名称-i <interface>和服务配置文件-f /etc/ptp4l.conf，因为这些文件会被自动附加。 - 7
- 为
phc2sys服务指定系统配置选项，如-a -r。 - 8
- 指定包括一个或多个
recommend对象的数组，该数组定义了如何将配置集应用到节点的规则。 - 9
- 指定
profile部分中定义的profile对象名称。 - 10
- 使用
0到99之间的一个整数值指定priority。大数值的优先级较低，因此优先级99低于优先级10。如果根据match项中定义的规则，节点可以与多个配置集相匹配，具有最高优先级的配置集将被应用到那个节点。 - 11
- 使用
nodeLabel或nodeName指定match规则。 - 12
- 使用节点对象中的
node.Labels的key指定nodeLabel。 - 13
- 使用节点对象的
node.Name指定nodeName。
运行以下命令来创建 CR：
oc create -f <filename>
$ oc create -f <filename>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<filename>替换为您在上一步中创建的文件的名称。
可选：检查
PtpConfig配置集是否应用到与nodeLabel或nodeName匹配的节点。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 11 章 网络策略
11.1. 关于网络策略
作为集群管理员，您可以定义网络策略以限制到集群中的 pod 的网络通讯。
11.1.1. 关于网络策略
在使用支持 Kubernetes 网络策略的 Kubernetes Container Network Interface（CNI）插件的集群中，网络隔离完全由 NetworkPolicy 对象控制。在 OpenShift Container Platform 4.7 中，OpenShift SDN 支持在默认的网络隔离模式中使用网络策略。
在使用 OpenShift SDN 集群网络供应商时，网络策略会有以下限制：
-
不支持由
egress字段指定的出口网络策略。 -
网络策略支持 IPBlock，但不支持
except。如果创建的策略带有一个有except的 IPBlock 项，SDN pod 的日志中会出现警告，策略中的整个 IPBlock 项都会被忽略。
网络策略不适用于主机网络命名空间。启用主机网络的 Pod 不受网络策略规则的影响。
默认情况下，项目中的所有 pod 都可被其他 pod 和网络端点访问。要在一个项目中隔离一个或多个 Pod，您可以在该项目中创建 NetworkPolicy 对象来指示允许的入站连接。项目管理员可以在自己的项目中创建和删除 NetworkPolicy 对象。
如果一个 pod 由一个或多个 NetworkPolicy 对象中的选择器匹配，那么该 pod 将只接受至少被其中一个 NetworkPolicy 对象所允许的连接。未被任何 NetworkPolicy 对象选择的 pod 可以完全访问。
以下示例 NetworkPolicy 对象演示了支持不同的情景：
拒绝所有流量：
要使项目默认为拒绝流量，请添加一个匹配所有 pod 但不接受任何流量的
NetworkPolicy对象：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 的连接：
要使 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 的连接。
11.1.2. 网络策略优化
使用一个网络策略来通过 pod 上的不同标签来在命名空间中将不同 pod 进行隔离。
有效使用网络策略规则的指南只适用于 OpenShift SDN 集群网络供应商。
将 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 的特定流量。
11.1.3. 后续步骤
11.2. 创建网络策略
作为具有 admin 角色的用户，您可以为命名空间创建网络策略。
11.2.1. 创建网络策略
要定义细致的规则来描述集群中命名空间允许的入口或出口网络流量，您可以创建一个网络策略。
如果使用具有 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 的入口流量
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 允许来自所有命名空间中的所有 pod 的入口流量
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>- 可选： 如果对象在与当前命名空间不同的命名空间中定义，使用它来指定命名空间。
输出示例
networkpolicy "default-deny" created
networkpolicy "default-deny" createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.2.2. 示例 NetworkPolicy 对象
下文解释了示例 NetworkPolicy 对象：
11.3. 查看网络策略
以具有 admin 角色的用户，您可以查看命名空间的网络策略。
11.3.1. 查看网络策略
您可以检查命名空间中的网络策略。
如果使用具有 cluster-admin 角色的用户登录，您可以查看集群中的任何网络策略。
先决条件
-
已安装 OpenShift CLI（
oc）。 -
您可以使用具有
admin权限的用户登陆到集群。 - 您在网络策略所在的命名空间中。
流程
列出命名空间中的网络策略：
要查看命名空间中定义的
NetworkPolicy对象，输入以下命令：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 oc describe命令的输出Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.3.2. 示例 NetworkPolicy 对象
下文解释了示例 NetworkPolicy 对象：
11.4. 编辑网络策略
作为具有 admin 角色的用户，您可以编辑命名空间的现有网络策略。
11.4.1. 编辑网络策略
您可以编辑命名空间中的网络策略。
如果使用具有 cluster-admin 角色的用户登录，则可以在集群中的任何命名空间中编辑网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的集群网络供应商，如 OVN-Kubernetes 网络供应商或设置了mode: NetworkPolicy的 OpenShift SDN 网络供应商。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI（
oc）。 -
您可以使用具有
admin权限的用户登陆到集群。 - 您在网络策略所在的命名空间中。
流程
可选： 要列出一个命名空间中的网络策略对象，请输入以下命令：
oc get networkpolicy -n <namespace>
$ oc get networkpolicy -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中：
<namespace>- 可选： 如果对象在与当前命名空间不同的命名空间中定义，使用它来指定命名空间。
编辑
NetworkPolicy对象。如果您在文件中保存了网络策略定义，请编辑该文件并进行必要的更改，然后输入以下命令。
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>- 指定包含网络策略的文件的名称。
如果您需要直接更新
NetworkPolicy对象，请输入以下命令：oc edit networkpolicy <policy_name> -n <namespace>
$ oc edit networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中：
<policy_name>- 指定网络策略的名称。
<namespace>- 可选： 如果对象在与当前命名空间不同的命名空间中定义，使用它来指定命名空间。
确认
NetworkPolicy对象已更新。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>- 可选： 如果对象在与当前命名空间不同的命名空间中定义，使用它来指定命名空间。
11.4.2. 示例 NetworkPolicy 对象
下文解释了示例 NetworkPolicy 对象：
11.5. 删除网络策略
以具有 admin 角色的用户，您可以从命名空间中删除网络策略。
11.5.1. 删除网络策略
您可以删除命名空间中的网络策略。
如果使用具有 cluster-admin 角色的用户登录，您可以删除集群中的任何网络策略。
先决条件
-
集群使用支持
NetworkPolicy对象的集群网络供应商，如 OVN-Kubernetes 网络供应商或设置了mode: NetworkPolicy的 OpenShift SDN 网络供应商。此模式是 OpenShift SDN 的默认模式。 -
已安装 OpenShift CLI（
oc）。 -
您可以使用具有
admin权限的用户登陆到集群。 - 您在网络策略所在的命名空间中。
流程
要删除
NetworkPolicy对象，请输入以下命令：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>- 可选： 如果对象在与当前命名空间不同的命名空间中定义，使用它来指定命名空间。
输出示例
networkpolicy.networking.k8s.io/allow-same-namespace deleted
networkpolicy.networking.k8s.io/allow-same-namespace deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.6. 为项目定义默认网络策略
作为集群管理员，您可以在创建新项目时修改新项目模板，使其自动包含网络策略。如果您还没有新项目的自定义模板，则需要首先创建一个。
11.6.1. 为新项目修改模板
作为集群管理员，您可以修改默认项目模板，以便使用自定义要求创建新项目。
创建自己的自定义项目模板：
流程
-
以具有
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 页面。
- 点击 Global 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 - 保存更改后，创建一个新项目来验证是否成功应用了您的更改。
11.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对象：重要对于 OVN-Kubernetes 网络供应商插件，当 Ingress Controller 配置为使用
HostNetwork端点发布策略时，不支持应用网络策略，以便允许入口流量，所有其他流量都会被拒绝。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 NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s
$ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.7. 使用网络策略配置多租户隔离
作为集群管理员，您可以配置网络策略以为多租户网络提供隔离功能。
如果使用 OpenShift SDN 集群网络供应商，请按照本节所述配置网络策略，提供类似于多租户模式的网络隔离，但具有设置网络策略模式。
11.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
可选： 要确认当前项目中存在网络策略，请输入以下命令：
oc describe networkpolicy
$ oc describe networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.7.2. 后续步骤
第 12 章 多网络
12.1. 了解多网络
在 Kubernetes 中，容器联网由实现了 Container Network Interface (CNI) 的网络插件负责。
OpenShift Container Platform 使用 Multus CNI 插件来实现对 CNI 插件的链接。在集群安装过程中，您要配置 default pod 网络。默认网络处理集群中的所有一般网络流量。您可以基于可用的 CNI 插件定义额外网络，并将一个或多个这种网络附加到 pod。您可以根据需要为集群定义多个额外网络。这可让您灵活地配置提供交换或路由等网络功能的 pod。
12.1.1. 额外网络使用场景
您可以在需要网络隔离的情况下使用额外网络，包括分离数据平面与控制平面。隔离网络流量对以下性能和安全性原因很有用：
- 性能
- 您可以在两个不同的平面上发送流量，以管理每个平面上流量的多少。
- 安全性
- 您可以将敏感的流量发送到专为安全考虑而管理的网络平面，也可隔离不能在租户或客户间共享的私密数据。
集群中的所有 pod 仍然使用集群范围的默认网络，以维持整个集群中的连通性。每个 pod 都有一个 eth0 接口，附加到集群范围的 pod 网络。您可以使用 oc exec -it <pod_name> -- ip a 命令来查看 pod 的接口。如果您添加使用 Multus CNI 的额外网络接口，则名称为 net1、net2、…、netN。
要将额外网络接口附加到 pod，您必须创建配置来定义接口的附加方式。您可以使用 NetworkAttachmentDefinition 自定义资源（CR）来指定各个接口。各个 CR 中的 CNI 配置定义如何创建该接口。
12.1.2. OpenShift Container Platform 中的额外网络
OpenShift Container Platform 提供以下 CNI 插件，以便在集群中创建额外网络：
- bridge ：配置基于网桥的额外网络，以允许同一主机上的容器集相互通信，并与主机通信。
- host-device ：配置 host-device 额外网络，以允许 pod 访问主机系统上的物理以太网网络设备。
- ipvlan ：配置基于 ipvlan 的额外网络，以允许主机上的 pod 与其他主机和那些主机上的 pod 通信，这类似于基于 macvlan 的额外网络。与基于 macvlan 的额外网络不同，每个 pod 共享与父级物理网络接口相同的 MAC 地址。
- macvlan ：配置基于 macvlan 的额外网络， 以允许主机上的 pod 通过使用物理网络接口与其他主机和那些主机上的 pod 通信。附加到基于 macvlan 的额外网络的每个 pod 都会获得一个唯一的 MAC 地址。
- SR-IOV ：配置基于 SR-IOV 的额外网络，以允许 pod 附加到主机系统上支持 SR-IOV 的硬件的虚拟功能(VF)接口。
12.2. 配置额外网络
作为集群管理员，您可以为集群配置额外网络。支持以下网络类型：
12.2.1. 管理额外网络的方法
您可以通过两种方法管理额外网络的生命周期：每种方法都是互斥的，您一次只能使用一种方法来管理额外网络。对于这两种方法，额外网络都由您配置的 Container Network Interface(CNI)插件管理。
对于额外网络，通过您配置为额外网络一部分的 IP 地址管理(IPAM)CNI 插件来置备 IP 地址。IPAM 插件支持各种 IP 地址分配方法，包括 DHCP 和静态分配。
-
修改 Cluster Network Operator(CNO)配置： CNO 会自动创建和管理
NetworkAttachmentDefinition对象。除了管理对象生命周期外，CNO 还确保 DHCP 可用于使用 DHCP 分配的 IP 地址的额外网络。 -
应用 YAML 清单：您可以通过创建
NetworkAttachmentDefinition对象直接管理额外网络。这种方法允许通过串联 CNI 插件。
12.2.2. 配置额外网络附加
通过 k8s.cni.cncf.io API 组中的 NetworkAttachmentDefinition API 配置额外网络。下表描述了 API 的配置：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 额外网络的名称。 |
|
|
| 与对象关联的命名空间。 |
|
|
| CNI 插件配置 JSON 格式。 |
12.2.2.1. 通过 Cluster Network Operator 配置额外网络
额外网络附加的配置作为 Cluster Network Operator(CNO)配置的一部分指定。
以下 YAML 描述了使用 CNO 管理额外网络的配置参数：
Cluster Network Operator 配置
12.2.2.2. 从 YAML 清单配置额外网络
额外网络的配置是从 YAML 配置文件指定的，如下例所示：
12.2.3. 额外网络类型的配置
以下部分介绍了额外网络的具体配置字段。
12.2.3.1. 配置网桥额外网络
以下对象描述了 bridge CNI 插件的配置参数：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
| |
|
|
|
指定要使用的虚拟网桥名称。如果主机上不存在网桥接口，则进行创建。默认值为 |
|
|
| IPAM CNI 插件的配置对象。该插件管理网络附加定义的 IP 地址分配。 |
|
|
|
设置为 |
|
|
|
设置为 |
|
|
|
设置为 |
|
|
|
设置为 |
|
|
|
设置为 |
|
|
|
设置为 |
|
|
| 以整数值形式指定虚拟 LAN (VLAN) 标签。默认情况下不分配 VLAN 标签。 |
|
|
| 将最大传输单位 (MTU) 设置为指定的值。默认值由内核自动设置。 |
12.2.3.1.1. 网桥配置示例
以下示例配置了名为 bridge-net 的额外网络：
12.2.3.2. 主机设备额外网络的配置
仅设置以下参数之一来指定您的网络设备：device、HWaddr、kernelpath 或 pciBusID。
以下对象描述了 host-device CNI 插件的配置参数：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
|
要配置的 CNI 插件的名称： |
|
|
|
可选：设备的名称，如 |
|
|
| 可选：设备硬件 MAC 地址。 |
|
|
|
可选：Linux 内核设备路径，如 |
|
|
|
可选：网络设备的 PCI 地址，如 |
|
|
| IPAM CNI 插件的配置对象。该插件管理网络附加定义的 IP 地址分配。 |
12.2.3.2.1. host-device 配置示例
以下示例配置了名为 hostdev-net 的额外网络：
12.2.3.3. 配置 IPVLAN 额外网络
以下对象描述了 IPVLAN CNI 插件的配置参数：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
|
要配置的 CNI 插件的名称： |
|
|
|
虚拟网络的操作模式。这个值必须是 |
|
|
|
与网络附加关联的以太网接口。如果没有指定 |
|
|
| 将最大传输单位 (MTU) 设置为指定的值。默认值由内核自动设置。 |
|
|
| IPAM CNI 插件的配置对象。该插件管理网络附加定义的 IP 地址分配。
不要指定 |
12.2.3.3.1. ipvlan 配置示例
以下示例配置了名为 ipvlan -net 的额外网络：
12.2.3.4. MACVLAN 额外网络的配置
以下对象描述了 macvlan CNI 插件的配置参数：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CNI 规格版本。需要 |
|
|
|
您之前为 CNO 配置提供的 |
|
|
|
要配置的 CNI 插件的名称：mac |
|
|
|
配置虚拟网络上的流量可见性。必须是 |
|
|
| 与虚拟接口关联的以太网、绑定或 VLAN 接口。如果未指定值，则使用主机系统的主以太网接口。 |
|
|
| 到指定值的最大传输单元(MTU)。默认值由内核自动设置。 |
|
|
| IPAM CNI 插件的配置对象。该插件管理网络附加定义的 IP 地址分配。 |
12.2.3.4.1. macvlan 配置示例
以下示例配置了名为 macvlan-net 的额外网络：
12.2.4. 为额外网络配置 IP 地址分配
IP 地址管理(IPAM)Container Network Interface(CNI)插件为其他 CNI 插件提供 IP 地址。
您可以使用以下 IP 地址分配类型：
- 静态分配。
- 通过 DHCP 服务器进行动态分配。您指定的 DHCP 服务器必须可从额外网络访问。
- 通过 Whereabouts IPAM CNI 插件进行动态分配。
12.2.4.1. 静态 IP 地址分配配置
下表描述了静态 IP 地址分配的配置：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值是 |
|
|
| 指定分配给虚拟接口的 IP 地址的对象数组。支持 IPv4 和 IPv6 IP 地址。 |
|
|
| 指定要在 pod 中配置的路由的对象数组。 |
|
|
| 可选：指定 DNS 配置的对象数组。 |
address 数组需要带有以下字段的对象：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
您指定的 IP 地址和网络前缀。例如：如果您指定 |
|
|
| 出口网络流量要路由到的默认网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CIDR 格式的 IP 地址范围，如 |
|
|
| 网络流量路由的网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 用来发送 DNS 查询的一个或多个 IP 地址的数组。 |
|
|
|
要附加到主机名的默认域。例如，如果将域设置为 |
|
|
|
在 DNS 查找查询过程中，附加到非限定主机名（如 |
静态 IP 地址分配配置示例
12.2.4.2. 动态 IP 地址(DHCP)分配配置
以下 JSON 描述了使用 DHCP 进行动态 IP 地址地址分配的配置：
pod 在创建时获取其原始 DHCP 租期。该租期必须由集群中运行的一个小型的 DHCP 服务器部署定期续订。
要触发 DHCP 服务器的部署，您必须编辑 Cluster Network Operator 配置来创建 shim 网络附加，如下例所示：
shim 网络附加定义示例
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值 |
动态 IP 地址(DHCP)分配配置示例
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}12.2.4.3. 使用 Whereabouts 进行动态 IP 地址分配配置
Whereabouts CNI 插件允许在不使用 DHCP 服务器的情况下动态地将 IP 地址分配给额外网络。
下表描述了使用 Whereabouts 进行动态 IP 地址分配的配置：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值是 |
|
|
| CIDR 表示法中的 IP 地址和范围。IP 地址是通过这个地址范围来分配的。 |
|
|
| 可选： CIDR 表示法中存在零或多个 IP 地址和范围的列表。包含在排除地址范围中的 IP 地址。 |
使用 Whereabouts 的动态 IP 地址分配配置示例
12.2.5. 使用 Cluster Network Operator 创建额外网络附加
Cluster Network Operator (CNO) 管理额外网络定义。当您指定要创建的额外网络时，CNO 会自动创建 NetworkAttachmentDefinition 对象。
不要编辑 Cluster Network Operator 所管理的 NetworkAttachmentDefinition 对象。这样做可能会破坏额外网络上的网络流量。
先决条件
-
安装 OpenShift CLI（
oc）。 -
以具有
cluster-admin特权的用户身份登录。
流程
要编辑 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 创建了 NetworkAttachmentDefinition 对象。CNO 创建对象之前可能会有延迟。
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 配置的网络附加的命名空间。
输出示例
NAME AGE test-network-1 14m
NAME AGE test-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.2.6. 通过应用 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 清单的文件的名称。
12.3. 关于虚拟路由和转发
12.3.1. 关于虚拟路由和转发
虚拟路由和转发（VRF）设备与 IP 规则相结合，提供了创建虚拟路由和转发域的能力。VRF 减少了 CNF 所需的权限数量，并可提高二级网络网络拓扑的可见性。VRF 用于提供多租户功能，例如，每个租户都有自己的唯一的路由表且需要不同的默认网关。
进程可将套接字绑定到 VRF 设备。通过绑定套接字的数据包使用与 VRF 设备关联的路由表。VRF 的一个重要特性是，它只影响 OSI 模型层 3 以上的流量，因此 L2 工具（如 LLDP）不会受到影响。这可让优先级更高的 IP 规则（如基于策略的路由）优先于针对特定流量的 VRF 设备规则。
12.3.1.1. 这对针对电信业使用的 pod 的从属网络提供了好处
在电信业，每个 CNF 都可连接到共享相同地址空间的多个不同的网络。这些从属网络可能会与集群的主网络 CIDR 冲突。使用 CNI VRF 插件，网络功能可使用相同的 IP 地址连接到不同的客户基础架构，使不同的客户保持隔离。IP 地址与 OpenShift Container Platform IP 空间重叠。CNI VRF 插件还可减少 CNF 所需的权限数量，并提高从属网络的网络拓扑的可见性。
12.4. 将 pod 附加到额外网络
作为集群用户，您可以将 pod 附加到额外网络。
12.4.1. 将 pod 添加到额外网络
您可以将 pod 添加到额外网络。pod 继续通过默认网络发送与集群相关的普通网络流量。
创建 pod 时会附加额外网络。但是，如果 pod 已存在，您无法为其附加额外网络。
pod 必须与额外网络处于相同的命名空间。
先决条件
-
安装 OpenShift CLI（
oc）。 - 登录到集群。
流程
为
Pod对象添加注解。只能使用以下注解格式之一：要在没有自定义的情况下附加额外网络，请使用以下格式添加注解。将
<network>替换为要与 pod 关联的额外网络的名称：metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 要指定多个额外网络，请使用逗号分隔各个网络。逗号之间不可包括空格。如果您多次指定同一额外网络，则该 pod 会将多个网络接口附加到该网络。
要通过自定义来附加额外网络，请添加具有以下格式的注解：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令来创建 pod。将
<name>替换为 pod 的名称。oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选： 要确认
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 - 1
k8s.v1.cni.cncf.io/networks-status参数是对象的 JSON 数组。每个对象描述附加到 pod 的额外网络的状态。注解值保存为纯文本值。
12.4.1.1. 指定特定于 pod 的地址和路由选项
将 pod 附加到额外网络时，您可能需要在特定 pod 中指定有关该网络的其他属性。这可让您更改路由的某些方面，并指定静态 IP 地址和 MAC 地址。要达到此目的，您可以使用 JSON 格式的注解。
先决条件
- pod 必须与额外网络处于相同的命名空间。
-
安装 OpenShift 命令行界面（
oc）。 - 您必须登录集群。
流程
要在指定地址和/或路由选项的同时将 pod 添加到额外网络，请完成以下步骤：
编辑
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>,...]]'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<network>替换为 JSON 对象，如下例所示。单引号是必需的。
在以下示例中，通过
default-route参数，注解指定了哪个网络附加将使用默认路由。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
默认路由将导致任何没有在其它路由中指定的流量被路由到网关。
将 OpenShift Container Platform 的默认路由设置为默认网络接口以外的接口时，可能会导致应该是 pod 和 pod 间的网络流量被路由到其他接口。
要验证 pod 的路由属性，可使用 oc 命令在 pod 中执行 ip 命令。
oc exec -it <pod_name> -- ip route
$ oc exec -it <pod_name> -- ip route
您还可以引用 pod 的 k8s.v1.cni.cncf.io/networks-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 配置
以下对象描述了使用 macvlan CNI 插件的静态 MAC 地址和 IP 地址的配置参数：
使用静态 IP 和 MAC 地址的 macvlan CNI 插件 JSON 配置对象
以上网络附加可能会以 JSON 格式的注解引用，同时使用相关的键来指定将哪些静态 IP 和 MAC 地址分配给指定 pod。
使用以下内容编辑 pod：
oc edit pod <name>
$ oc edit pod <name>使用静态 IP 和 MAC 地址的 macvlan CNI 插件 JSON 配置对象
静态 IP 地址和 MAC 地址不需要同时使用，您可以单独使用，也可以一起使用。
要验证一个带有额外网络的 pod 的 IP 地址和 MAC 属性，请使用 oc 命令在 pod 中执行 ip 命令。
oc exec -it <pod_name> -- ip a
$ oc exec -it <pod_name> -- ip a12.5. 从额外网络中删除 pod
作为集群用户，您可以从额外网络中删除 pod。
12.5.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 的命名空间。
-
12.6. 编辑额外网络
作为集群管理员，您可以修改现有额外网络的配置。
12.6.1. 修改额外网络附加定义
作为集群管理员，您可以对现有额外网络进行更改。任何附加到额外网络的现有 pod 都不会被更新。
先决条件
- 已为集群配置了额外网络。
-
安装 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}}' { "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"]}} }$ 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
12.7. 删除额外网络
作为集群管理员，您可以删除额外网络附加。
12.7.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 - 1
- 如果要删除
additionalNetworks集合中唯一额外网络附加定义的配置映射，您必须指定一个空集合。
- 保存您的更改，再退出文本编辑器以提交更改。
可选：通过运行以下命令确认删除了额外网络 CR：
oc get network-attachment-definition --all-namespaces
$ oc get network-attachment-definition --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8. 为 VRF 分配从属网络
CNI VRF 插件只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。
12.8.1. 为 VRF 分配从属网络
作为集群管理员，您可以使用 CNI VRF 插件为 VRF 域配置额外网络。此插件创建的虚拟网络与您指定的物理接口关联。
使用 VRF 的应用程序需要绑定到特定设备。通常的用法是在套接字中使用 SO_BINDTODEVICE 选项。SO_BINDTODEVICE 将套接字绑定到在传递接口名称中指定的设备，例如 eth1。要使用 SO_BINDTODEVICE，应用程序必须具有 CAP_NET_RAW 功能。
12.8.1.1. 使用 CNI VRF 插件创建额外网络附加
Cluster Network Operator (CNO) 管理额外网络定义。当您指定要创建的额外网络时，CNO 会自动创建 NetworkAttachmentDefinition 自定义资源（CR）。
请勿编辑 Cluster Network Operator 所管理的 NetworkAttachmentDefinition CR。这样做可能会破坏额外网络上的网络流量。
要使用 CNI VRF 插件创建额外网络附加，请执行以下步骤。
先决条件
- 安装 OpenShift Container Platform CLI（oc）。
- 以具有 cluster-admin 权限的用户身份登录 OpenShift 集群。
流程
为额外网络附加创建
Network自定义资源 (CR)，并为额外网络插入rawCNIConfig配置，如下例所示。将 YAML 保存为文件additional-network-attachment.yaml。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意只有在资源类型为
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。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME AGE additional-network-1 14m
NAME AGE additional-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意CNO 创建 CR 之前可能会有延迟。
验证额外的 VRF 网络附加是否成功
要验证 VRF CNI 是否已正确配置并附加额外网络附加，请执行以下操作：
- 创建使用 VRF CNI 的网络。
- 将网络分配给 pod。
验证 Pod 网络附加是否已连接到 VRF 额外网络。远程 shell 到 pod 并运行以下命令：
ip vrf show
$ ip vrf showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Name Table ----------------------- red 10
Name Table ----------------------- red 10Copy 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
第 13 章 硬件网络
13.1. 关于单根 I/O 虚拟化（SR-IOV）硬件网络
Single Root I/O 虚拟化 (SR-IOV) 规范是针对一类 PCI 设备分配的标准，可与多个 pod 共享单个设备。
通过 SR-IOV，您可以将主机节点上识别为物理功能 (PF) 的兼容网络设备分段为多个虚拟功能 (VF)。VF 和其它网络设备一样使用。该设备的 SR-IOV 设备驱动程序决定了如何公开容器中的 VF：
-
netdevice驱动程序： 容器netns中的常规内核网络设备 -
vfio-pci驱动程序： 挂载到容器中的字符设备
您可以将 SR-IOV 网络设备与 OpenShift Container Platform 集群上安装在裸机或 Red Hat OpenStack Platform(RHOSP)基础架构上安装的额外网络一起使用，用于需要高带宽或低延迟的应用程序。
您可以使用以下命令在节点上启用 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"13.1.1. 负责管理 SR-IOV 网络设备的组件
SR-IOV Network Operator 会创建和管理 SR-IOV 堆栈的组件。它执行以下功能：
- 编配 SR-IOV 网络设备的发现和管理
-
为 SR-IOV Container Network Interface（CNI）生成
NetworkAttachmentDefinition自定义资源 - 创建和更新 SR-IOV 网络设备插件的配置
-
创建节点特定的
SriovNetworkNodeState自定义资源 -
更新每个
SriovNetworkNodeState自定义资源中的spec.interfaces字段
Operator 置备以下组件：
- SR-IOV 网络配置守护进程
- SR-IOV Operator 启动时在 worker 节点上部署的 DaemonSet。守护进程负责在集群中发现和初始化 SR-IOV 网络设备。
- SR-IOV 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 来禁用。
13.1.1.1. 支持的平台
SR-IOV Network Operator 在以下平台上受支持：
- 裸机
- Red Hat OpenStack Platform (RHOSP)
13.1.1.2. 支持的设备
OpenShift Container Platform 支持以下网络接口控制器：
| 制造商 | Model | 供应商 ID | 设备 ID |
|---|---|---|---|
| Intel | X710 | 8086 | 1572 |
| Intel | XXV710 | 8086 | 158b |
| Mellanox | MT27700 系列 [ConnectX-4] | 15b3 | 1013 |
| Mellanox | MT27710 系列 [ConnectX-4 Lx] | 15b3 | 1015 |
| Mellanox | MT27800 系列 [ConnectX-5] | 15b3 | 1017 |
| Mellanox | MT28908 系列 [ConnectX-6] | 15b3 | 101b |
13.1.1.3. 自动发现 SR-IOV 网络设备
SR-IOV Network Operator 将搜索集群以获取 worker 节点上的 SR-IOV 功能网络设备。Operator 会为每个提供兼容 SR-IOV 网络设备的 worker 节点创建并更新一个 SriovNetworkNodeState 自定义资源 (CR) 。
为 CR 分配了与 worker 节点相同的名称。status.interfaces 列表提供有关节点上网络设备的信息。
不要修改 SriovNetworkNodeState 对象。Operator 会自动创建和管理这些资源。
13.1.1.3.1. SriovNetworkNodeState 对象示例
以下 YAML 是由 SR-IOV Network Operator 创建的 SriovNetworkNodeState 对象的示例：
一 个 SriovNetworkNodeState 对象
13.1.1.4. 在 pod 中使用虚拟功能的示例
您可以在附加了 SR-IOV VF 的 pod 中运行远程直接内存访问 (RDMA) 或 Data Plane Development Kit (DPDK) 应用程序。
本示例演示了在 RDMA 模式中使用虚拟功能 (VF) 的 pod：
使用 RDMA 模式的 Pod 规格
以下示例演示了在 DPDK 模式中使用 VF 的 pod:
使用 DPDK 模式的 Pod 规格
13.1.1.5. 用于容器应用程序的 DPDK 库
一个可选的库 app-netutil 提供了几个 API 方法，用于从该 pod 中运行的容器内收集 pod 的网络信息。
此库旨在帮助将 SR-IOV 虚拟功能（VF）集成到 Data Plane Development Kit（DPDK）模式中。该程序库提供 Golang API 和 C API。
当前，采用 3 个 API 方法：
GetCPUInfo()- 此函数决定了哪些 CPU 可供容器使用，并将列表返回给调用者。
GetHugepages()此函数决定了每个容器在
Podspec 中请求的巨页内存量，并将值返回给调用者。注意通过 Kubernetes Downward API 公开巨页是 Kubernetes 1.20 中的一个 alpha 功能，在 OpenShift Container Platform 中不启用。您可以通过在 Kubernetes 1.20 或更高版本中启用功能门
FEATURE_GATES="DownwardAPIHugePages=true"来测试 API。GetInterfaces()- 此函数决定了容器中的一组接口，并返回列表，以及接口类型和类型特定数据。
还有一个 Docker 镜像示例 dpdk-app-centos，它可以根据 pod-spec: l2fwd、l3wd 或 testpmd 中的环境变量运行以下 DPDK 示例应用程序之一。这个 Docker 镜像提供了一个将 app-netutil 整合到容器镜像本身的示例。该程序库也可以整合到 init-container 中，该容器收集所需数据并将数据传递给现有的 DPDK 工作负载。
13.1.2. 后续步骤
- 配置 SR-IOV Network Operator
- 可选： 配置 SR-IOV Network Operator
- 配置 SR-IOV 网络设备
- 如果使用 OpenShift Virtualization: 为虚拟机配置 SR-IOV 网络设备
- 配置 SR-IOV 网络附加
- 将 pod 添加到额外网络
13.2. 安装 SR-IOV Network Operator
您可以在集群上安装单根 I/O 虚拟化（SR-IOV）网络 Operator，以管理 SR-IOV 网络设备和网络附加。
13.2.1. 安装 SR-IOV Network Operator
作为集群管理员，您可以使用 OpenShift Container Platform CLI 或 web 控制台安装 SR-IOV Network Operator。
13.2.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。
运行以下命令以获取 OpenShift Container Platform 的主版本和次版本。下一步中需要
channel值。OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要为 SR-IOV Network Operator 创建 Subscription CR，输入以下命令：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
要验证是否已安装 Operator，请输入以下命令：
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 输出示例
Name Phase sriov-network-operator.4.4.0-202006160135 Succeeded
Name Phase sriov-network-operator.4.4.0-202006160135 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.2.1.2. web 控制台：安装 SR-IOV Network Operator
作为集群管理员，您可以使用 Web 控制台安装 Operator。
您必须使用 CLI 创建 operator 组。
先决条件
- 在裸机环境中安装的集群，其中的节点带有支持 SR-IOV 的硬件。
-
安装 OpenShift CLI（
oc）。 -
具有
cluster-admin特权的帐户
流程
为 SR-IOV Network Operator 创建一个命名空间：
- 在 OpenShift Container Platform web 控制台中，点 Administration → Namespaces。
- 点 Create Namespace。
-
在 Name 字段中输入
openshift-sriov-network-operator，然后点击 Create。
安装 SR-IOV Network Operator：
- 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
- 从可用的 Operators 列表中选择 SR-IOV Network Operator，然后点击 Install。
- 在 Install Operator 页面中，在 A specific namespace on the cluster 中选择 openshift-sriov-network-operator。
- 点击 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 的日志。
13.2.2. 后续步骤
13.3. 配置 SR-IOV Network Operator
Single Root I/O Virtualization（SR-IOV）Network Operator 管理集群中的 SR-IOV 网络设备和网络附加。
13.3.1. 配置 SR-IOV Network Operator
通常不需要修改 SR-IOV Network Operator 配置。我们推荐在大多数用例中使用默认配置。只有 Operator 的默认行为与您的用例不兼容时，才需要按照以下步骤修改相关配置。
SR-IOV Network Operator 添加了 SriovOperatorConfig.sriovnetwork.openshift.io 自定义资源定义 (CRD)。Operator 会在 openshift-sriov-network-operator 命名空间中自动创建一个名为 default 的 SriovOperatorConfig 自定义资源 (CR)。
default CR 包含集群的 SR-IOV Network Operator 配置。要更改 Operator 配置，您必须修改这个 CR。
SriovOperatorConfig 对象为配置 Operator 提供以下几个字段：
-
enableInjector允许项目管理员启用或禁用 Network Resources Injector 守护进程集。 -
enableOperatorWebhook允许项目管理员启用或禁用 Operator Admission Controller webhook 守护进程集。 -
configDaemonNodeSelector允许项目管理员在所选节点上调度 SR-IOV 网络配置守护进程。
13.3.1.1. 关于 Network Resources Injector（网络资源注入器）。
Network Resources Injector 是一个 Kubernetes Dynamic Admission Controller 应用。它提供以下功能：
-
根据 SR-IOV 网络附加定义注解，对
Pod规格中的资源请求和限值进行修改，以添加 SR-IOV 资源名称。 -
使用下游 API 卷修改
Pod规格，将 pod 注解和标签作为/etc/podnetinfo路径下的文件提供给正在运行的容器。
默认情况下，Network Resources Injector 由 SR-IOV 操作器启用，并作为守护进程集在所有 control plane 节点上运行（也称为 master 节点）。以下是在具有三个 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 10mSR-IOV Operator Admission Controller Webhook 是一个 Kubernetes Dynamic Admission Controller 应用程序。它提供以下功能：
-
在创建或更新时，验证
SriovNetworkNodePolicyCR。 -
修改
SriovNetworkNodePolicyCR，在创建或更新 CR 时为priority和deviceType项设置默认值。
默认情况下，SR-IOV Operator Admission Controller Webhook 由 Operator 启用，并作为守护进程集在所有 control plane 节点上运行。以下是在具有三个 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 16m13.3.1.3. 关于自定义节点选择器
SR-IOV 网络配置守护进程在集群节点上发现并配置 SR-IOV 网络设备。默认情况下，它将部署到集群中的所有 worker 节点。您可以使用节点标签指定 SR-IOV 网络配置守护进程在哪些节点上运行。
13.3.1.4. 禁用或启用网络资源注入器
要禁用或启用默认启用的网络资源注入器，请完成以下步骤。
先决条件
-
安装 OpenShift CLI（
oc）。 -
以具有
cluster-admin特权的用户身份登录。 - 您必须已安装了 SR-IOV 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
13.3.1.5. 禁用或启用 SR-IOV Operator 准入控制器 Webhook
要禁用或启用默认启用的准入控制器 Webhook，请完成以下步骤。
先决条件
-
安装 OpenShift CLI（
oc）。 -
以具有
cluster-admin特权的用户身份登录。 - 您必须已安装了 SR-IOV 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
13.3.1.6. 为 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": ""。
13.3.2. 后续步骤
13.4. 配置 SR-IOV 网络设备
您可以在集群中配置单一根 I/O 虚拟化（SR-IOV）设备。
13.4.1. SR-IOV 网络节点配置对象
您可以通过创建 SR-IOV 网络节点策略来为节点指定 SR-IOV 网络设备配置。策略的 API 对象是 sriovnetwork.openshift.io API 组的一部分。
以下 YAML 描述了 SR-IOV 网络节点策略：
- 1
- 自定义资源对象的名称。
- 2
- 安装 SR-IOV Operator 的命名空间。
- 3
- SR-IOV 设备插件的资源名称。您可以为资源名称创建多个 SR-IOV 网络节点策略。
- 4
- 节点选择器指定要配置的节点。只有所选节点上的 SR-IOV 网络设备才会被配置。SR-IOV Container Network Interface（CNI）插件和设备插件仅在所选节点上部署。
- 5
- 可选： priority 是一个
0到99之间的整数。较小的值具有更高的优先级。例如，优先级10是高于优先级99。默认值为99。 - 6
- 可选：虚拟功能的最大传输单元（MTU）。最大 MTU 值可能因不同的网络接口控制器（NIC）型号而有所不同。
- 7
- 为 SR-IOV 物理网络设备创建的虚拟功能(（VF）的数量。对于 Intel 网络接口控制器（NIC），VF 的数量不能超过该设备支持的 VF 总数。对于 Mellanox NIC，VF 的数量不能超过
128。 - 8
- NIC 选择器标识要配置的 Operator 的设备。您不必为所有参数指定值。建议您足够精确地识别网络设备以避免意外选择设备。
如果指定了
rootDevices，则必须同时为vendor、deviceID或pfNames指定一个值。如果同时指定了pfNames和rootDevices，请确保它们引用同一设备。如果您为netFilter指定了一个值，那么您不需要指定任何其他参数，因为网络 ID 是唯一的。 - 9
- 可选： SR-IOV 网络设备的厂商十六进制代码。允许的值只能是
8086和15b3。 - 10
- 可选： SR-IOV 网络设备的设备十六进制代码。允许的值只能是
158b、1015和1017。 - 11
- 可选：该设备的一个或多个物理功能（PF）名称的数组。
- 12
- 可选：用于该设备的 PF 的一个或多个 PCI 总线地址的数组。使用以下格式提供地址:
0000:02:00.1。 - 13
- 可选：特定平台的网络过滤器。唯一支持的平台是 Red Hat OpenStack Platform（RHOSP）。可接受的值具有以下格式：
openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。将xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx替换为来自/var/config/openstack/latest/network_data.json元数据文件的值。 - 14
- 可选：虚拟功能的驱动程序类型。允许的值只能是
netdevice和vfio-pci。默认值为netdevice。对于裸机节点上的 Data Plane Development Kit（DPDK）模式中的 Mellanox NIC，请使用
netdevice驱动程序类型，并将isRdma设为true。 - 15
- 可选：是否启用远程直接访问（RDMA）模式。默认值为
false。如果将
isRDMA参数设定为true，您可以继续使用启用了 RDMA 的 VF 作为普通网络设备。设备可在其中的一个模式中使用。 - 16
- 可选：VF 的链接类型。您可以指定以下值之一：
eth或ib。为 Ethernet 指定eth，或为 InfiniBand 指定ib。默认值为eth。当将
linkType设置为ib时，SR-IOV Network Operator Webhook 会自动将isRdma设置为true。当将linkType设定为ib时，deviceType不应该被设置为vfio-pci。
13.4.1.1. SR-IOV 网络节点配置示例
以下示例描述了 InfiniBand 设备的配置：
InfiniBand 设备的配置示例
以下示例描述了 RHOSP 虚拟机中的 SR-IOV 网络设备配置：
虚拟机中的 SR-IOV 设备配置示例
13.4.1.2. SR-IOV 设备的虚拟功能 (VF) 分区
在某些情况下，您可能想要将同一个物理功能 (PF) 的虚拟功能 (VF) 分成多个资源池。例如： 您可能想要某些 VF 使用默认驱动程序载入，而其他的 VF 负载使用 vfio-pci 驱动程序。在这样的部署中，您可以使用SriovNetworkNodePolicy 自定义资源 (CR) 中的 pfNames 选项器（selector）来为池指定 VF 的范围，其格式为： <pfname>#<first_vf>-<last_vf>。
例如，以下 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 netpf0 的 VF 0 。策略 policy-net-1-dpdk 定义了一个资源池 net-1-dpdk，其中包含带有 vfio VF 驱动程序的 PF netpf0 的 VF 8 到 15。
策略 policy-net-1:
策略 policy-net-1-dpdk:
13.4.2. 配置 SR-IOV 网络设备
SR-IOV Network Operator 把 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD 添加到 OpenShift Container Platform。您可以通过创建一个 SriovNetworkNodePolicy 自定义资源 (CR) 来配置 SR-IOV 网络设备。
在应用由 SriovNetworkNodePolicy 对象中指定的配置时，SR-IOV Operator 可能会排空节点，并在某些情况下会重启节点。
它可能需要几分钟时间来应用配置更改。
先决条件
-
已安装 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
13.4.3. 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 网络设备的节点名称。
错误输出： 无法分配内存
"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"
"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"当节点表示无法分配内存时，检查以下项目：
- 确认在 BIOS 中为节点启用了全局 SR-IOV 设置。
- 确认在 BIOS 中为该节点启用了 VT-d。
13.4.4. 将 SR-IOV 网络分配给 VRF
CNI VRF 插件只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。
作为集群管理员，您可以使用 CNI VRF 插件为 VRF 域分配 SR-IOV 网络接口。
要做到这一点，将 VRF 配置添加到 SriovNetwork 资源的可选 metaPlugins 参数中。
使用 VRF 的应用程序需要绑定到特定设备。通常的用法是在套接字中使用 SO_BINDTODEVICE 选项。SO_BINDTODEVICE 将套接字绑定到在传递接口名称中指定的设备，例如 eth1。要使用 SO_BINDTODEVICE，应用程序必须具有 CAP_NET_RAW 功能。
13.4.4.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 Container Platform 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 创建
SriovNetwork资源：oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.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>替换为您在配置网络附加时指定的命名空间，如additional-sriov-network-1。
输出示例
NAME AGE additional-sriov-network-1 14m
NAME AGE additional-sriov-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意SR-IOV Network Operator 创建 CR 之前可能会有延迟。
验证额外 SR-IOV 网络附加是否成功
要验证 VRF CNI 是否已正确配置并附加额外的 SR-IOV 网络附加，请执行以下操作：
- 创建使用 VRF CNI 的 SR-IOV 网络。
- 将网络分配给 pod。
验证 pod 网络附加是否已连接到 SR-IOV 额外网络。远程 shell 到 pod 并运行以下命令：
ip vrf show
$ ip vrf showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Name Table ----------------------- red 10
Name Table ----------------------- red 10Copy 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 mode ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.4.5. 后续步骤
13.5. 配置 SR-IOV 以太网网络附加
您可以为集群中的单根 I/O 虚拟化（SR-IOV）设备配置以太网网络附加。
13.5.1. 以太网设备配置对象
您可以通过定义 SriovNetwork 对象来配置以太网网络设备。
以下 YAML 描述了 SriovNetwork 对象：
- 1
- 对象的名称。SR-IOV Network Operator 创建一个名称相同的
NetworkAttachmentDefinition对象。 - 2
- 安装 SR-IOV Network Operator 的命名空间。
- 3
- 用于为这个额外网络定义 SR-IOV 硬件的
SriovNetworkNodePolicy对象中的spec.resourceName参数的值。 - 4
SriovNetwork对象的目标命名空间。只有目标命名空间中的 pod 可以附加到额外网络。- 5
- 可选：额外网络的虚拟 LAN（VLAN）ID。它需要是一个从
0到4095范围内的一个整数值。默认值为0。 - 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 地址支持。
13.5.1.1. 为额外网络配置 IP 地址分配
IP 地址管理(IPAM)Container Network Interface(CNI)插件为其他 CNI 插件提供 IP 地址。
您可以使用以下 IP 地址分配类型：
- 静态分配。
- 通过 DHCP 服务器进行动态分配。您指定的 DHCP 服务器必须可从额外网络访问。
- 通过 Whereabouts IPAM CNI 插件进行动态分配。
13.5.1.1.1. 静态 IP 地址分配配置
下表描述了静态 IP 地址分配的配置：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值是 |
|
|
| 指定分配给虚拟接口的 IP 地址的对象数组。支持 IPv4 和 IPv6 IP 地址。 |
|
|
| 指定要在 pod 中配置的路由的对象数组。 |
|
|
| 可选：指定 DNS 配置的对象数组。 |
address 数组需要带有以下字段的对象：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
您指定的 IP 地址和网络前缀。例如：如果您指定 |
|
|
| 出口网络流量要路由到的默认网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CIDR 格式的 IP 地址范围，如 |
|
|
| 网络流量路由的网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 用来发送 DNS 查询的一个或多个 IP 地址的数组。 |
|
|
|
要附加到主机名的默认域。例如，如果将域设置为 |
|
|
|
在 DNS 查找查询过程中，附加到非限定主机名（如 |
静态 IP 地址分配配置示例
13.5.1.1.2. 动态 IP 地址(DHCP)分配配置
以下 JSON 描述了使用 DHCP 进行动态 IP 地址地址分配的配置：
pod 在创建时获取其原始 DHCP 租期。该租期必须由集群中运行的一个小型的 DHCP 服务器部署定期续订。
SR-IOV Network Operator 不创建 DHCP 服务器部署。Cluster Network Operator 负责创建小型的 DHCP 服务器部署。
要触发 DHCP 服务器的部署，您必须编辑 Cluster Network Operator 配置来创建 shim 网络附加，如下例所示：
shim 网络附加定义示例
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值 |
动态 IP 地址(DHCP)分配配置示例
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}13.5.1.1.3. 使用 Whereabouts 进行动态 IP 地址分配配置
Whereabouts CNI 插件允许在不使用 DHCP 服务器的情况下动态地将 IP 地址分配给额外网络。
下表描述了使用 Whereabouts 进行动态 IP 地址分配的配置：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值是 |
|
|
| CIDR 表示法中的 IP 地址和范围。IP 地址是通过这个地址范围来分配的。 |
|
|
| 可选： CIDR 表示法中存在零或多个 IP 地址和范围的列表。包含在排除地址范围中的 IP 地址。 |
使用 Whereabouts 的动态 IP 地址分配配置示例
13.5.2. 配置 SR-IOV 额外网络
您可以通过创建一个 SriovNetwork 对象来配置使用 SR-IOV 硬件的额外网络。创建 SriovNetwork 对象时，SR-IOV 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
13.5.3. 后续步骤
13.6. 配置 SR-IOV InfiniBand 网络附加
您可以为集群中的单根 I/O 虚拟化（SR-IOV）设备配置 InfiniBand（IB）网络附加。
13.6.1. Infiniband 设备配置对象
您可以通过定义 SriovIBNetwork 对象来配置 InfiniBand（IB）网络设备。
以下 YAML 描述了 SriovIBNetwork 对象：
- 1
- 对象的名称。SR-IOV Network Operator 创建一个名称相同的
NetworkAttachmentDefinition对象。 - 2
- 安装 SR-IOV Operator 的命名空间。
- 3
- 用于为这个额外网络定义 SR-IOV 硬件的
SriovNetworkNodePolicy对象中的spec.resourceName参数的值。 - 4
SriovIBNetwork对象的目标命名空间。只有目标命名空间中的 pod 可以附加到网络设备。- 5
- 可选：将 IPAM CNI 插件配置为 YAML 块 scalar。该插件管理网络附加定义的 IP 地址分配。
- 6
- 可选：虚拟功能（VF）的链接状态。允许的值是
enable、disable和auto。 - 7
- 可选：为此网络配置功能。您可以指定
"{ "ips": true }"来启用 IP 地址支持，或者"{ "infinibandGUID": true }"启用 IB Global Unique Identifier（GUID）支持。
13.6.1.1. 为额外网络配置 IP 地址分配
IP 地址管理(IPAM)Container Network Interface(CNI)插件为其他 CNI 插件提供 IP 地址。
您可以使用以下 IP 地址分配类型：
- 静态分配。
- 通过 DHCP 服务器进行动态分配。您指定的 DHCP 服务器必须可从额外网络访问。
- 通过 Whereabouts IPAM CNI 插件进行动态分配。
13.6.1.1.1. 静态 IP 地址分配配置
下表描述了静态 IP 地址分配的配置：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值是 |
|
|
| 指定分配给虚拟接口的 IP 地址的对象数组。支持 IPv4 和 IPv6 IP 地址。 |
|
|
| 指定要在 pod 中配置的路由的对象数组。 |
|
|
| 可选：指定 DNS 配置的对象数组。 |
address 数组需要带有以下字段的对象：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
您指定的 IP 地址和网络前缀。例如：如果您指定 |
|
|
| 出口网络流量要路由到的默认网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
CIDR 格式的 IP 地址范围，如 |
|
|
| 网络流量路由的网关。 |
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 用来发送 DNS 查询的一个或多个 IP 地址的数组。 |
|
|
|
要附加到主机名的默认域。例如，如果将域设置为 |
|
|
|
在 DNS 查找查询过程中，附加到非限定主机名（如 |
静态 IP 地址分配配置示例
13.6.1.1.2. 动态 IP 地址(DHCP)分配配置
以下 JSON 描述了使用 DHCP 进行动态 IP 地址地址分配的配置：
pod 在创建时获取其原始 DHCP 租期。该租期必须由集群中运行的一个小型的 DHCP 服务器部署定期续订。
要触发 DHCP 服务器的部署，您必须编辑 Cluster Network Operator 配置来创建 shim 网络附加，如下例所示：
shim 网络附加定义示例
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值 |
动态 IP 地址(DHCP)分配配置示例
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}13.6.1.1.3. 使用 Whereabouts 进行动态 IP 地址分配配置
Whereabouts CNI 插件允许在不使用 DHCP 服务器的情况下动态地将 IP 地址分配给额外网络。
下表描述了使用 Whereabouts 进行动态 IP 地址分配的配置：
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
|
IPAM 地址类型。值是 |
|
|
| CIDR 表示法中的 IP 地址和范围。IP 地址是通过这个地址范围来分配的。 |
|
|
| 可选： CIDR 表示法中存在零或多个 IP 地址和范围的列表。包含在排除地址范围中的 IP 地址。 |
使用 Whereabouts 的动态 IP 地址分配配置示例
13.6.2. 配置 SR-IOV 额外网络
您可以通过创建一个 SriovIBNetwork 对象来配置使用 SR-IOV 硬件的额外网络。创建 SriovIBNetwork 对象时，SR-IOV 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
13.6.3. 后续步骤
13.7. 将 pod 添加到额外网络
您可以将 pod 添加到现有的单根 I/O 虚拟化（SR-IOV）网络。
13.7.1. 网络附加的运行时配置
将 pod 附加到额外网络时，您可以指定运行时配置来为 pod 进行特定的自定义。例如,,您可以请求特定的 MAC 硬件地址。
您可以通过在 pod 规格中设置注解来指定运行时配置。注解键是 k8s.v1.cni.cncf.io/network,它接受一个 JSON 对象来描述运行时配置。
13.7.1.1. 基于以太网的 SR-IOV 附加的运行时配置
以下 JSON 描述了基于以太网的 SR-IOV 网络附加的运行时配置选项。
运行时配置示例
13.7.1.2. 基于 InfiniBand 的 SR-IOV 附加的运行时配置
以下 JSON 描述了基于 InfiniBand 的 SR-IOV 网络附加的运行时配置选项。
运行时配置示例
13.7.2. 将 pod 添加到额外网络
您可以将 pod 添加到额外网络。pod 继续通过默认网络发送与集群相关的普通网络流量。
创建 pod 时会附加额外网络。但是，如果 pod 已存在，您无法为其附加额外网络。
pod 必须与额外网络处于相同的命名空间。
SR-IOV 网络资源注入器会自动将 resource 字段添加到 pod 中的第一个容器中。
如果您在 Data Plane Development Kit(DPDK)模式中使用 Intel 网络接口控制器(NIC)，则只有 pod 中的第一个容器被配置为访问 NIC。如果在 SriovNetworkNodePolicy 对象中的 deviceType 设置为 vfio-pci，则会为 DPDK 模式配置 SR- IOV 额外网络。
您可以解决此问题，方法是确保需要访问 NIC 的容器是 Pod 对象中定义的第一个容器，或者禁用 Network Resource Injector。如需更多信息，请参阅 BZ# 953。
先决条件
-
安装 OpenShift CLI（
oc）。 - 登录到集群。
- 安装 SR-IOV Operator。
-
创建
SriovNetwork对象或SriovIBNetwork对象以将 pod 附加到。
流程
为
Pod对象添加注解。只能使用以下注解格式之一：要在没有自定义的情况下附加额外网络，请使用以下格式添加注解。将
<network>替换为要与 pod 关联的额外网络的名称：metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 要指定多个额外网络，请使用逗号分隔各个网络。逗号之间不可包括空格。如果您多次指定同一额外网络，则该 pod 会将多个网络接口附加到该网络。
要通过自定义来附加额外网络，请添加具有以下格式的注解：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令来创建 pod。将
<name>替换为 pod 的名称。oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选： 要确认
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 - 1
k8s.v1.cni.cncf.io/networks-status参数是对象的 JSON 数组。每个对象描述附加到 pod 的额外网络的状态。注解值保存为纯文本值。
13.7.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 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
13.8. 配置高性能多播
您可以在您的单根 I/O 虚拟化（SR-IOV）硬件网络中使用多播。
13.8.1. 高性能多播
OpenShift SDN 默认 Container Network Interface (CNI) 网络供应商支持默认网络上的 pod 间的多播。目前，多播最适用于低带宽协调或服务发现。它不适用于高带宽的应用程序。对于流传输介质应用程序，如 IPTV 和多方视频会议，可以使用 Single Root I/O Virtualization（SR-IOV）硬件来提供接近原生的性能。
使用额外的 SR-IOV 接口进行多播时：
- pod 必须通过额外的 SR-IOV 接口发送或接收多播软件包。
- 连接 SR-IOV 接口的物理网络决定了多播路由和拓扑结构，不受 OpenShift Container Platform 的控制。
13.8.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功能。否则，可以省略它。
13.9. 在 DPDK 和 RDMA 模式中使用虚拟功能（VF）的示例
您可以使用单一根 I/O 虚拟化（SR-IOV）网络硬件和 Data Plane Development Kit (DPDK) 以及远程直接内存访问 (RDMA) 。
Data Plane Development Kit (DPDK) 只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。
13.9.1. 在 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。
注意请参阅
Configuring SR-IOV network devices一节以了解SriovNetworkNodePolicy中的每个选项的信息。当应用由
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 插件指定一个空对象
"{}"。DPDK 在用户空间模式下工作，不需要 IP 地址。
注意如需
SriovNetwork中的每个选项的详细说明，请参阅"Configuring SR-IOV additional network" 部分。运行以下命令来创建
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 和SriovNetowrk对象中更改target_namespace。 - 2
- 指定包含应用程序和应用程序使用的 DPDK 库的 DPDK 镜像。
- 3
- 指定容器内的应用程序进行大页分配、系统资源分配和网络接口访问所需的额外功能。
- 4
- 在
/dev/hugepages下将巨页卷挂载到 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
13.9.2. 在带有 Mellanox NIC 的 DPDK 模式中使用虚拟功能
先决条件
-
安装 OpenShift CLI（
oc）。 - 安装 SR-IOV Network Operator。
-
以具有
cluster-admin特权的用户身份登录。
流程
创建以下
SriovNetworkNodePolicy对象，然后在mlx-dpdk-node-policy.yaml文件中保存 YAML。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意请参阅
Configuring SR-IOV network devices一节以了解SriovNetworkNodePolicy中的每个选项的信息。当应用由
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 创建以下
SriovNetwork对象，然后在mlx-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" 部分。运行以下命令来创建
SriovNetworkNodePolicy对象：oc create -f mlx-dpdk-network.yaml
$ oc create -f mlx-dpdk-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建以下
Podspec，然后在mlx-dpdk-pod.yaml文件中保存 YAML。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定
target_namespace，它与SriovNetwork对象mlx-dpdk-network创建于的命令空间相同。如果要在其他命名空间中创建 pod，在Podspec 和SriovNetowrk对象中更改target_namespace。 - 2
- 指定包含应用程序和应用程序使用的 DPDK 库的 DPDK 镜像。
- 3
- 指定容器内的应用程序进行大页分配、系统资源分配和网络接口访问所需的额外功能。
- 4
- 在
/dev/hugepages下将巨页卷挂载到 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巨页需要在节点中添加内核参数。
运行以下命令来创建 DPDK pod:
oc create -f mlx-dpdk-pod.yaml
$ oc create -f mlx-dpdk-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.9.3. 在带有 Mellanox NIC 的 RDMA 模式中使用虚拟功能
在 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 注意请参阅
Configuring SR-IOV network devices一节以了解SriovNetworkNodePolicy中的每个选项的信息。当应用由
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" 部分。运行以下命令来创建
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 和SriovNetowrk对象中更改target_namespace。 - 2
- 指定包含应用程序和应用程序使用的 RDMA 库的 RDMA 镜像。
- 3
- 指定容器内的应用程序进行大页分配、系统资源分配和网络接口访问所需的额外功能。
- 4
- 在
/dev/hugepages下将巨页卷挂载到 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
13.10. 卸载 SR-IOV Network Operator
要卸载 SR-IOV Network Operator，您必须删除任何正在运行的 SR-IOV 工作负载，卸载 Operator，并删除 Operator 使用的 webhook。
13.10.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
第 14 章 OpenShift SDN 默认 CNI 网络供应商
14.1. 关于 OpenShift SDN 默认 CNI 网络供应商
OpenShift Container Platform 使用软件定义网络 (SDN) 方法来提供一个统一的集群网络，它允许 OpenShift Container Platform 集群中的不同 pod 相互间进行通信。此 pod 网络是由 OpenShift SDN 建立和维护的，它使用 Open vSwitch (OVS) 配置覆盖网络。
14.1.1. OpenShift SDN 网络隔离模式
OpenShift SDN 提供三种 SDN 模式来配置 pod 网络：
-
网络策略模式允许项目管理员使用
NetworkPolicy对象配置自己的隔离策略。Network policy 是 OpenShift Container Platform 4.7 的默认模式。 - 多租户模式为 Pod 和服务提供项目级别的隔离。来自不同项目的 Pod 不能与不同项目的 Pod 和服务互相发送或接收数据包。您可以针对项目禁用隔离，允许它将网络流量发送到整个集群中的所有 pod 和服务，并从那些 pod 和服务接收网络流量。
- 子网模式提供一个扁平 pod 网络，每个 pod 都可以与所有其他 pod 和服务通信。网络策略模式提供与子网模式相同的功能。
14.1.2. 支持的默认 CNI 网络供应商功能列表
OpenShift Container Platform 为默认的 Container Network Interface (CNI) 网络供应商提供两个支持的选择：OpenShift SDN 和 OVN-Kubernetes。下表总结了这两个网络供应商当前支持的功能：
| 功能 | OpenShift SDN | OVN-Kubernetes |
|---|---|---|
| 出口 IP | 支持 | 支持 |
| Egress 防火墙 [1] | 支持 | 支持 |
| 出口路由器 | 支持 | 部分支持 [3] |
| IPsec 加密 | 不支持 | 支持 |
| Kubernetes 网络策略 | 部分支持 [2] | 支持 |
| 多播 | 支持 | 支持 |
- 在 OpenShift SDN 中，出口防火墙也称为出口网络策略。这和网络策略出口不同。
-
OpenShift SDN 的网络策略不支持出口规则和一些
ipBlock规则。 - OVN-Kubernetes 的出口路由器仅支持重定向模式。
14.2. 为项目配置出口 IP
作为集群管理员，您可以配置 OpenShift SDN 默认 Container Network Interface (CNI) 网络供应商，为项目分配一个或多个出口 IP 地址。
14.2.1. 项目出口流量的出口 IP 地址分配
通过为项目配置出口 IP 地址，来自指定项目的所有出站外部连接将共享相同的固定源 IP 地址。外部资源可以根据出口 IP 地址识别来自特定项目的流量。分配给项目的出口 IP 地址与用来向特定目的地发送流量的出口路由器不同。
出口 IP 地址是作为额外 IP 地址在节点的主网络接口中实现的，且必须与节点的主 IP 地址处于同一个子网中。
不能在任何 Linux 网络配置文件中配置出口 IP 地址，比如 ifcfg-eth0。
Amazon Web Services(AWS)、Google Cloud Platform(GCP)和 Azure 上的出口 IP 仅在 OpenShift Container Platform 版本 4.10 及更新的版本中支持。
在使用一些虚拟机解决方案时，在主网络接口上允许额外的 IP 地址可能需要额外的配置。
您可以通过设置 NetNamespace 对象的 egressIPs 参数,将出口 IP 地址分配给命名空间。在出口 IP 与项目关联后，OpenShift SDN 允许您以两种方式为主机分配出口 IP：
- 在自动分配方法中，给节点分配一个出口 IP 地址范围。
- 在手动分配方法中，给节点分配包含一个或多个出口 IP 地址的列表。
请求出口 IP 地址的命名空间与可以托管那些出口 IP 地址的节点匹配，然后为那些节点分配出口 IP 地址。如果在 NetNamespace 对象中设置了 egressIPs 参数，但没有节点托管该出口 IP 地址，则会丢弃来自该命名空间的出口流量。
节点高可用性是自动的。如果托管出口 IP 地址的节点不可访问，并且有可以托管那些出口 IP 地址的节点，那么出口 IP 地址将会移到新节点。当无法访问的托管原始出口 IP 地址的节点恢复正常后，出口 IP 地址会自动转移，以在不同节点之间均衡出口 IP 地址。
将出口 IP 地址与 OpenShift SDN 集群网络供应商搭配使用时会有以下限制：
- 您不能在同一节点上同时使用手动分配和自动分配的出口 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。
14.2.1.1. 使用自动分配的出口 IP 地址时的注意事项
当对出口 IP 地址使用自动分配方法时，请注意以下事项：
-
您可以设置每个节点的
HostSubnet资源的egressCIDRs参数，以指明节点可以托管的出口 IP 地址范围。OpenShift Container Platform 根据您指定的 IP 地址范围设置HostSubnet资源的egressIPs参数。 - 使用自动分配模式时，支持每个命名空间具有一个出口 IP 地址。
如果托管命名空间的出口 IP 地址的节点不可访问，OpenShift Container Platform 会将出口 IP 地址重新分配给具有兼容出口 IP 地址范围的另外一个节点。自动分配方法最适合在把额外的 IP 地址与节点进行关联时具有灵活性的环境中安装的集群。
14.2.1.2. 使用手动分配出口 IP 地址时的注意事项
此方法用于集群，在公共云环境中将其他 IP 地址与节点（如公共云环境中）关联可能存在限制。
当手动分配出口 IP 地址时，请考虑以下事项：
-
您可以设置每个节点的
HostSubnet资源的egressIPs参数，以指明节点可以托管的 IP 地址。 - 支持一个命名空间带有多个出口 IP 地址。
当命名空间有多个出口 IP 地址时，如果托管第一个出口 IP 地址的节点不可访问，OpenShift Container Platform 将自动切换到使用下一个可用的出口 IP 地址，直到可以再次访问第一个出口 IP 地址。
14.2.2. 为一个命名空间启用自动分配出口 IP 地址
在 OpenShift Container Platform 中，可以为一个或多个节点上的特定命名空间启用自动分配出口 IP 地址。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI（
oc）。
流程
使用以下 JSON，用出口 IP 地址更新
NetNamespace资源：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，将
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 例如，将
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，或反之。
14.2.3. 为一个命名空间配置手动分配出口 IP 地址
在 OpenShift Container Platform 中，您可以将一个或多个出口 IP 与一个项目关联。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI（
oc）。
流程
通过使用所需 IP 地址指定以下 JSON 对象来更新
NetNamespace对象：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，将
project1项目分配给 IP 地址192.168.1.100：oc patch netnamespace project1 --type=merge \ -p '{"egressIPs": ["192.168.1.100"]}'$ oc patch netnamespace project1 --type=merge \ -p '{"egressIPs": ["192.168.1.100"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以将
egressIPs设置为位于不同节点上的两个或多个 IP 地址，以提供高可用性。如果设置了多个出口 IP 地址，Pod 会将列表中的第一个 IP 用于出口，但如果托管该 IP 地址的节点失败，Pod 会在短暂的延迟后切换到使用列表中的下一个 IP。注意由于 OpenShift SDN 管理
NetNamespace对象，因此只能通过修改现有的NetNamespace对象来进行更改。不要创建新的NetNamespace对象。手动将出口 IP 分配给节点主机。在节点主机上的
HostSubnet对象中设置egressIPs参数。使用以下 JSON，尽可能纳入您要分配给该节点主机的所有 IP：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，指定
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 地址。
14.3. 为项目配置出口防火墙
作为集群管理员，您可以为项目创建一个出口防火墙，用于限制离开 OpenShift Container Platform 集群的出口流量。
14.3.1. 出口防火墙在一个项目中的工作原理
作为集群管理员，您可以使用一个出口防火墙来限制集群内的一些 pod 或所有 pod 可以访问的外部主机。出口防火墙适用于以下情况：
- pod 只能连接到内部主机，且无法启动到公共互联网的连接。
- pod 只能连接到公共互联网，且无法启动到 OpenShift Container Platform 集群以外的内部主机的连接。
- pod 无法访问 OpenShift Container Platform 集群外的特定内部子网或主机。
- pod 只能连接到特定的外部主机。
例如，您可以允许某一个项目访问指定的 IP 范围，但拒绝其他项目对同一 IP 范围的访问。或者您可以限制应用程序开发人员从 Python pip 的镜像点进行更新，并强制要求更新只能来自于批准的源。
您可以通过创建一个 EgressNetworkPolicy 自定义资源（CR）对象来配置出口防火墙策略。出口防火墙与满足以下任一条件的网络流量匹配：
- CIDR 格式的 IP 地址范围
- 解析为 IP 地址的 DNS 名称
如果您的出口防火墙包含 0.0.0.0/0 的拒绝规则，则阻止访问 OpenShift Container Platform API 服务器。为确保 pod 能够继续访问 OpenShift Container Platform API 服务器，您必须在出口防火墙规则中包含 API 服务器侦听的 IP 地址范围，如下例所示：
要查找 API 服务器的 IP 地址，请运行 oc get ep kubernetes -n default。
如需更多信息，请参阅 BZ#1988324。
您必须将 OpenShift SDN 配置为使用网络策略或多租户模式来配置出口防火墙。
如果您使用网络策略模式，则出口防火墙只与每个命名空间的一个策略兼容，且无法用于共享网络的项目，如全局项目。
出口防火墙规则不适用于通过路由器的网络流量。任何有权创建 Route CR 对象的用户，都可以通过创建指向禁止的目的地的路由来绕过出口防火墙策略规则。
14.3.1.1. 出口防火墙的限制
出口防火墙有以下限制：
- 项目不能有多个 EgressNetworkPolicy 对象。
- 每个项目最多可定义一个最多具有 1000 个规则的 EgressNetworkPolicy 对象。
-
default项目无法使用出口防火墙。 当在多租户模式下使用 OpenShift SDN 默认 Container Network Interface (CNI) 网络供应商时，会有以下限制：
-
全局项目无法使用出口防火墙。您可以使用
oc adm pod-network make-projects-global把一个项目设置为全局项目。 -
通过
oc adm pod-network join-projects命令合并的项目，无法在任何合并的项目中使用出口防火墙。
-
全局项目无法使用出口防火墙。您可以使用
违反这些限制会导致项目的出口防火墙出现问题，并可能导致所有外部网络流量被丢弃。
kube-node-lease、kube-public、kube-system、openshift 和 openshift- 项目中可以创建 Egress Firewall 资源。
14.3.1.2. 出口防火墙策略规则的匹配顺序
出口防火墙策略规则按照它们定义的顺序来评估，从第一个到最后一个的顺序。第一个与 pod 的出口连接匹配的规则会被应用。该连接会忽略后续的所有规则。
14.3.1.3. 域名服务器 (DNS) 解析如何工作
如果您在 egress 防火墙策略规则中使用 DNS 名称，则正确解析域名会受到以下限制：
- 域名更新根据本地非授权服务器返回的域的 TTL（time to live）值进行轮询。
- 在需要时，pod 必须通过相同的本地名称服务器解析域名。否则，egress 防火墙控制器和 pod 已知的域的 IP 地址可能会有所不同。如果主机名的 IP 地址不同，则出口防火墙的强制实施可能不一致。
- 因为出口防火墙控制器和 pod 异步轮询相同的本地名称服务器，所以 pod 可能会在出口控制器执行前获取更新的 IP 地址，从而导致竞争条件。由于这个限制，仅建议在 EgressNetworkPolicy 对象中使用域名来更改 IP 地址的域。
出口防火墙始终允许 pod 访问 pod 所在的用于 DNS 解析的节点的外部接口。
如果您在出口防火墙策略中使用域名，且您的 DNS 解析不是由本地节点上的 DNS 服务器处理，那么您必须添加出口防火墙规则，允许访问您的 DNS 服务器的 IP 地址。如果您在 pod 中使用域名。
14.3.2. EgressNetworkPolicy 自定义资源 (CR) 对象
您可以为出口防火墙定义一个或多个规则。规则是一个 Allow 规则，也可以是一个 Deny 规则，它包括规则适用的流量规格。
以下 YAML 描述了一个 EgressNetworkPolicy CR 对象：
EgressNetworkPolicy 对象
14.3.2.1. EgressNetworkPolicy 规则
以下 YAML 描述了一个出口防火墙规则对象。egress 小节需要一个包括一个或多个对象的数组。
出口策略规则小节
egress:
- type: <type>
to:
cidrSelector: <cidr>
dnsName: <dns_name>
egress:
- type: <type>
to:
cidrSelector: <cidr>
dnsName: <dns_name> 14.3.2.2. EgressNetworkPolicy CR 对象示例
以下示例定义了几个出口防火墙策略规则：
- 1
- 出口防火墙策略规则对象的集合。
14.3.3. 创建出口防火墙策略对象
作为集群管理员，您可以为项目创建一个出口防火墙策略对象。
如果项目已经定义了一个 EgressNetworkPolicy 对象，您必须编辑现有的策略来更改出口防火墙规则。
先决条件
- 使用 OpenShift SDN 默认 Container Network Interface (CNI) 网络供应商插件的集群。
-
安装 OpenShift CLI（
oc）。 - 您需要使用集群管理员身份登陆到集群。
流程
创建策略规则：
-
创建一个
<policy_name>.yaml文件，其中<policy_name>描述出口策略规则。 - 在您创建的文件中，定义出口策略对象。
-
创建一个
运行以下命令来创建策略对象。将
<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 在以下示例中，在名为
project1的项目中创建一个新的 EgressNetworkPolicy 对象：oc create -f default.yaml -n project1
$ oc create -f default.yaml -n project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
egressnetworkpolicy.network.openshift.io/v1 created
egressnetworkpolicy.network.openshift.io/v1 createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
可选：保存
<policy_name>.yaml文件，以便在以后进行修改。
14.4. 为项目编辑出口防火墙
作为集群管理员，您可以修改现有出口防火墙的网络流量规则。
14.4.1. 查看 EgressNetworkPolicy 对象
您可以查看集群中的 EgressNetworkPolicy 对象。
先决条件
- 使用 OpenShift SDN 默认 Container Network Interface (CNI) 网络供应商插件的集群。
-
安装 OpenShift 命令行界面 (CLI)，通常称为
oc。 - 您必须登录集群。
流程
可选： 要查看集群中定义的 EgressNetworkPolicy 对象的名称，请输入以下命令：
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
14.5. 为项目编辑出口防火墙
作为集群管理员，您可以修改现有出口防火墙的网络流量规则。
14.5.1. 编辑 EgressNetworkPolicy 对象
作为集群管理员，您可以更新一个项目的出口防火墙。
先决条件
- 使用 OpenShift SDN 默认 Container Network Interface (CNI) 网络供应商插件的集群。
-
安装 OpenShift CLI（
oc）。 - 您需要使用集群管理员身份登陆到集群。
流程
查找项目的 EgressNetworkPolicy 对象的名称。将
<project>替换为项目的名称。oc get -n <project> egressnetworkpolicy
$ oc get -n <project> egressnetworkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选，如果您在创建出口网络防火墙时没有保存 EgressNetworkPolicy 对象的副本，请输入以下命令来创建副本。
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 保存到的文件的名称。更改了策略规则后，请输入以下命令替换 EgressNetworkPolicy 对象。将
<filename>替换为包含更新的 EgressNetworkPolicy 对象的文件名称。oc replace -f <filename>.yaml
$ oc replace -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.6. 从项目中删除出口防火墙
作为集群管理员，您可以从项目中删除出口防火墙，从而删除对项目的离开 OpenShift Container Platform 集群的网络流量的限制。
14.6.1. 删除 EgressNetworkPolicy 对象
作为集群管理员，您可以从项目中删除出口防火墙。
先决条件
- 使用 OpenShift SDN 默认 Container Network Interface (CNI) 网络供应商插件的集群。
-
安装 OpenShift CLI（
oc）。 - 您需要使用集群管理员身份登陆到集群。
流程
查找项目的 EgressNetworkPolicy 对象的名称。将
<project>替换为项目的名称。oc get -n <project> egressnetworkpolicy
$ oc get -n <project> egressnetworkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令删除 EgressNetworkPolicy 对象。将
<project>替换为项目名称，<name>替换为对象名称。oc delete -n <project> egressnetworkpolicy <name>
$ oc delete -n <project> egressnetworkpolicy <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.7. 使用出口路由器 pod 的注意事项
14.7.1. 关于出口路由器 pod
OpenShift Container Platform 出口路由器（egress router ） pod 使用一个来自专用的私有源 IP 地址，将网络流量重定向到指定的远程服务器。出口路由器 Pod 允许您将网络流量发送到设置的服务器，以便只允许从特定的 IP 地址访问。
出口路由器 pod 并不适用于所有外向的连接。创建大量出口路由器 pod 可能会超过您的网络硬件的限制。例如，为每个项目或应用程序创建出口路由器 pod 可能会导致，在转换为使用软件来进行 MAC 地址过滤前超过了网络接口可以处理的本地 MAC 地址的数量。
出口路由器镜像与 Amazon AWS、Azure Cloud 或其他不支持第 2 层操作的云平台不兼容，因为它们与 macvlan 流量不兼容。
14.7.1.1. 出口路由器模式
在重定向模式中，出口路由器 Pod 配置 iptables 规则，将流量从其自身 IP 地址重定向到一个或多个目标 IP 地址。需要使用保留源 IP 地址的客户端 pod 必须修改来连接到出口路由器，而不是直接连接到目标 IP。
在 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 代理模式。
14.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 来表示哪些节点可以接受。
14.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 - Red Hat Virtualization (RHV)
- 如果使用 RHV，必须为虚拟网络接口控制器(vNIC)选择 No Network Filter。
- VMware vSphere
- 如果使用 VMware vSphere，请参阅 VMware 文档 以了解 vSphere 标准交换机的安全。通过从 vSphere Web 客户端中选择主机虚拟交换机来查看并更改 VMware vSphere 默认设置。
具体来说，请确保启用了以下功能：
14.7.1.4. 故障切换配置
为了避免停机，可以使用 Deployment 资源部署出口路由器 pod，如下例所示。要为示例部署创建新 Service 对象，使用 oc expose deployment/egress-demo-controller 命令。
14.8. 以重定向模式部署出口路由器 pod
作为集群管理员，您可以部署一个出口路由器 pod，该 pod 被配置为将流量重新定向到指定的目的地 IP 地址。
14.8.1. 重定向模式的出口路由器 pod 规格
为 Pod 对象中的一个出口路由器 pod 定义其配置。以下 YAML 描述了以重定向模式配置出口路由器 pod 的字段：
- 1
- 该注解告知 OpenShift Container Platform 在主网络接口控制器(NIC)上创建一个 macvlan 网络接口，并将 macvlan 接口移到 pod 的网络命名空间中。您必须把
"true"值包括在引号中。要在不同的 NIC 接口上让 OpenShift Container Platform 创建 macvlan 接口，请将注解值设置为该接口的名称。例如：eth1。 - 2
- 保留给出口路由器 pod 使用的物理网络的 IP 地址。可选：您可以包括子网长度（
/24后缀），以便正确路由到本地子网。如果没有指定子网长度，则出口路由器只能访问使用EGRESS_GATEWAY变量指定的主机，且子网上没有其他主机。 - 3
- 值与节点使用的默认网关相同。
- 4
- 将流量定向到的外部服务器。使用这个示例，连接到 pod 流量被重新定向到
203.0.113.25，源 IP 地址为192.168.12.99。
出口路由器 pod 规格示例
14.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.2714.8.3. 以重定向模式部署出口路由器 pod
在重定向模式中，出口路由器 pod 会设置 iptables 规则将流量从其自身 IP 地址重定向到一个或多个目标 IP 地址。需要使用保留源 IP 地址的客户端 pod 必须修改来连接到出口路由器，而不是直接连接到目标 IP。
先决条件
-
安装 OpenShift CLI（
oc）。 -
以具有
cluster-admin特权的用户身份登录。
流程
- 创建出口路由器 pod。
为确保其他 pod 可以查找出口路由器 pod 的 IP 地址，请创建一个服务指向出口路由器 pod，如下例所示：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您的 pod 现在可以连接到此服务。使用保留的出口 IP 地址将其连接重新指向外部服务器的对应端口。
14.9. 以 HTTP 代理模式部署出口路由器 pod
作为集群管理员，您可以将出口路由器 pod 配置为代理流量到指定的 HTTP 和基于 HTTPS 的服务。
14.9.1. HTTP 模式的出口路由器 pod 规格
为 Pod 对象中的一个出口路由器 pod 定义其配置。以下 YAML 描述了以 HTTP 模式配置出口路由器 pod 的字段：
- 1
- 该注解告知 OpenShift Container Platform 在主网络接口控制器(NIC)上创建一个 macvlan 网络接口，并将 macvlan 接口移到 pod 的网络命名空间中。您必须把
"true"值包括在引号中。要在不同的 NIC 接口上让 OpenShift Container Platform 创建 macvlan 接口，请将注解值设置为该接口的名称。例如：eth1。 - 2
- 保留给出口路由器 pod 使用的物理网络的 IP 地址。可选：您可以包括子网长度（
/24后缀），以便正确路由到本地子网。如果没有指定子网长度，则出口路由器只能访问使用EGRESS_GATEWAY变量指定的主机，且子网上没有其他主机。 - 3
- 值与节点使用的默认网关相同。
- 4
- 一个字符串或 YAML 多行字符串指定如何配置代理。请注意，这作为 HTTP 代理容器中的环境变量指定，而不是与 init 容器中的其他环境变量指定。
14.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
*14.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环境变量。如果以上内容没有创建可以正常工作设置，请查阅 pod 中运行的工具或软件的文档。_proxy和 https_proxy
14.10. 以 DNS 代理模式部署出口路由器 pod
作为集群管理员，您可以将配置为代理流量的出口路由器 pod 部署到指定的 DNS 名称和 IP 地址。
14.10.1. DNS 模式的出口路由器 pod 规格
为 Pod 对象中的一个出口路由器 pod 定义其配置。以下 YAML 描述了在 DNS 模式中配置出口路由器 pod 的字段：
- 1
- 该注解告知 OpenShift Container Platform 在主网络接口控制器(NIC)上创建一个 macvlan 网络接口，并将 macvlan 接口移到 pod 的网络命名空间中。您必须把
"true"值包括在引号中。要在不同的 NIC 接口上让 OpenShift Container Platform 创建 macvlan 接口，请将注解值设置为该接口的名称。例如：eth1。 - 2
- 保留给出口路由器 pod 使用的物理网络的 IP 地址。可选：您可以包括子网长度（
/24后缀），以便正确路由到本地子网。如果没有指定子网长度，则出口路由器只能访问使用EGRESS_GATEWAY变量指定的主机，且子网上没有其他主机。 - 3
- 值与节点使用的默认网关相同。
- 4
- 指定一个或多个代理目的地列表。
- 5
- 可选：指定输出 DNS 代理日志输出到
stdout。
14.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 44314.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 地址将其代理到外部服务器的对应端口。
14.11. 从配置映射配置出口路由器 pod 目的地列表
作为集群管理员，您可以定义一个 ConfigMap 对象来指定出口路由器 pod 的目标映射。配置的特定格式取决于出口路由器 pod 的类型。有关格式的详情，请参阅特定出口路由器 pod 的文档。
14.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是数据从中读取的文件的名称。创建出口路由器 pod 定义，并为环境片段中的
EGRESS_DESTINATION字段指定configMapKeyRef小节：Copy to Clipboard Copied! Toggle word wrap Toggle overflow