网络

OpenShift Container Platform 4.2

配置和管理集群网络

Red Hat OpenShift Documentation Team

摘要

本文档提供有关配置和管理 OpenShift Container Platform 集群网络的说明,其中包括 DNS、Ingress 和 Pod 网络。

第 1 章 了解网络

Kubernetes 可确保 Pod 能够相互联网,并从内部网络为每个 Pod 分配一个 IP 地址。这样可保证 Pod 中所有容器的行为如同它们在同一主机上一样。为每个 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/端口能够访问这些服务。

第 2 章 访问主机

了解如何创建堡垒主机来访问 OpenShift Container Platform 实例,以及使用安全 shell (SSH) 访问 master 节点。

2.1. 访问安装程序置备的基础架构集群中 Amazon Web Services 上的主机

OpenShift Container Platform 安装程序不会为任何置备 OpenShift Container Platform 集群的 Amazon Elastic Compute Cloud (Amazon EC2) 实例创建公共 IP 地址。为了可以 SSH 到 OpenShift Container Platform 主机,您必须按照以下步骤操作。

流程

  1. 创建一个安全组,允许 SSH 访问由 openshift-install 命令创建的虚拟私有云 (VPC) 。
  2. 在安装程序创建的某个公共子网中创建 Amazon EC2 实例。
  3. 将公共 IP 地址与您创建的 Amazon EC2 实例相关联。

    与 OpenShift Container Platform 安装不同,您应该将您创建的 Amazon EC2 实例与 SSH 密钥对关联。这与您为这个实例选择的操作系统无关,因为它只是一个 SSH 堡垒将互联网桥接到 OpenShift Container Platform 集群的 VPC。它与您使用的 Amazon Machine Image (AMI) 相关。例如,在 Red Hat Enterprise Linux CoreOS 中,您可以像安装程序一样通过 Ignition 提供密钥。

  4. 一旦置备了 Amazon EC2 实例并可以 SSH 到它,您必须添加与 OpenShift Container Platform 安装关联的 SSH 密钥。这个密钥可以与堡垒实例的密钥不同,也可以相同。

    注意

    直接通过 SSH 访问仅建议在灾难恢复时使用。当 Kubernetes API 正常工作时,应该使用特权 Pod。

  5. 运行 oc get nodes,查看输出结果,然后选择一个 master 节点。主机名类似于 ip-10-0-1-163.ec2.internal
  6. 从您手动部署到 Amazon EC2 的堡垒 SSH 主机中,SSH 部署到那个 master 主机。确定您使用了在安装过程中指定的相同的 SSH 密钥:

    $ ssh -i <ssh-key-path> core@<master-hostname>

第 3 章 OpenShift Container Platform 中的 Cluster Network Operator

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

3.1. Cluster Network Operator

Cluster Network Operator 从 operator.openshift.io API 组实现 network API。Operator 使用 DaemonSet 部署 OpenShift SDN 插件,或者集群安装过程中选择的其他 SDN 插件。

流程

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

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

    $ oc get -n openshift-network-operator deployment/network-operator
    
    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    network-operator   1/1     1            1           56m
  2. 运行以下命令,以查看 Cluster Network Operator 的状态:

    $ oc get clusteroperator/network
    
    NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.2.0     True        False         False      50m

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

3.2. 查看集群网络配置

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

流程

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

    $ oc describe network.config/cluster
    
    Name:         cluster
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  config.openshift.io/v1
    Kind:         Network
    Metadata:
      Self Link:           /apis/config.openshift.io/v1/networks/cluster
    Spec: 1
      Cluster Network:
        Cidr:         10.128.0.0/14
        Host Prefix:  23
      Network Type:   OpenShiftSDN
      Service Network:
        172.30.0.0/16
    Status: 2
      Cluster Network:
        Cidr:               10.128.0.0/14
        Host Prefix:        23
      Cluster Network MTU:  8951
      Network Type:         OpenShiftSDN
      Service Network:
        172.30.0.0/16
    Events:  <none>
    1
    Spec 字段显示集群网络的已配置状态。
    2
    Status 字段显示集群网络配置的当前状态。

3.3. 查看 Cluster Network Operator 状态

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

流程

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

    $ oc describe clusteroperators/network

3.4. 查看 Cluster Network Operator 日志

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

流程

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

    $ oc logs --namespace=openshift-network-operator deployment/network-operator

3.5. Cluster Network Operator 自定义资源 (CR)

Network.operator.openshift.io 自定义资源 (CR) 中的集群网络配置存储 Cluster Network Operator (CNO) 的配置设置。Operator 管理集群网络。

您可以通过在 CNO CR 中设置 defaultNetwork 参数的参数,为 OpenShift Container Platform 集群指定集群网络配置。以下 CR 显示了 CNO 的默认配置,并且说明了您可以配置的参数和有效的参数值:

Cluster Network Operator CR

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork: 1
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork: 2
  - 172.30.0.0/16
  defaultNetwork: 3
    ...
  kubeProxyConfig: 4
    iptablesSyncPeriod: 30s 5
    proxyArguments:
      iptables-min-sync-period: 6
      - 30s

1
用于指定从哪些 IP 地址块分配 Pod IP 地址以及分配给每个节点的子网前缀长度的列表。
2
服务的 IP 地址块。OpenShift SDN Container Network Interface (CNI) 插件只支持服务网络具有单个 IP 地址块。
3
为集群网络配置软件定义型网络 (SDN)。
4
此对象的参数指定 Kubernetes 网络代理 (kube-proxy) 配置。
5
iptables 规则的刷新周期。默认值为 30s。有效的后缀包括 smh,具体参见 Go 时间包文档。
6
刷新 iptables 规则前的最短时长。此参数确保刷新的频率不会过于频繁。有效的后缀包括 smh,具体参见 Go 时间包

3.5.1. OpenShift SDN 的配置参数

以下 YAML 对象描述了 OpenShift SDN 的配置参数:

defaultNetwork:
  type: OpenShiftSDN 1
  openshiftSDNConfig: 2
    mode: NetworkPolicy 3
    mtu: 1450 4
    vxlanPort: 4789 5
1
使用的软件定义型网络 (SDN) 插件。OpenShift SDN 是 OpenShift Container Platform 4.2 中唯一支持的插件。
2
OpenShift SDN 专用配置参数。
3
OpenShift SDN CNI 插件的网络隔离模式。
4
用于 VXLAN 覆盖网络的 MTU。这个值通常是自动配置的。
5
用于所有 VXLAN 数据包的端口。默认值为 4789

3.5.2. Cluster Network Operator 示例 CR

下例中显示了 CNO 的完整 CR:

Cluster Network Operator 示例 CR

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  defaultNetwork:
    type: OpenShiftSDN
    openshiftSDNConfig:
      mode: NetworkPolicy
      mtu: 1450
      vxlanPort: 4789
  kubeProxyConfig:
    iptablesSyncPeriod: 30s
    proxyArguments:
      iptables-min-sync-period:
      - 30s

第 4 章 OpenShift Container Platform 中的 DNS Operator

DNS Operator 部署并管理 CoreDNS,以便为 Pod 提供名称解析服务,从而在 OpenShift 中启用基于 DNS 的 Kubernetes 服务发现。

4.1. DNS Operator

DNS Operator 从 operator.openshift.io API 组实现 dns API。Operator 使用 DaemonSet 部署 CoreDNS,为 DaemonSet 创建服务,并将 kubelet 配置为指示 Pod 使用 CoreDNS 服务 IP 进行名称解析。

流程

在安装过程中,DNS Operator 被部署为一个 Kubernetes 部署

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

    $ oc get -n openshift-dns-operator deployment/dns-operator
    NAME           READY     UP-TO-DATE   AVAILABLE   AGE
    dns-operator   1/1       1            1           23h

    ClusterOperator 是存放 Operator 当前状态的自定义资源对象。Operator 使用这个对象将其状态传递给集群的其余部分。

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

    $ oc get clusteroperator/dns
    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
    dns       4.1.0-0.11  True        False         False      92m

    AVAILABLEPROGRESSINGDEGRADED 提供了有关 Operator 状态的信息。当 CoreDNS DaemonSet 中至少有 1 个 Pod 报告了 Available 状态时,AVAILABLETrue

4.2. 查看默认 DNS

每个 OpenShift Container Platform 新安装都有一个名为 defaultdns.operator。它无法进行定制或被替换,也不能通过额外的 dns 来补充。

流程

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

    $ oc describe dns.operator/default
    Name:         default
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         DNS
    ...
    Status:
      Cluster Domain:  cluster.local 1
      Cluster IP:      172.30.0.10 2
    ...
    1
    Cluster Domain 字段是用于构造完全限定的 Pod 和 Service 域名的基本 DNS 域名。
    2
    Cluster IP 是 Pod 为名称解析查询的地址。IP 由 Service CIDR 范围中的第 10 个地址定义。
  2. 要查找集群的 Service CIDR,请使用 oc get 命令:

    $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'
    [172.30.0.0/16]
注意

不支持配置 CoreDNS Corefile 或 Kubernetes 插件。

4.3. DNS Operator 状态

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

流程

查看 DNS Operator 的状态:

$ oc describe clusteroperators/dns

4.4. DNS Operator 日志

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

流程

查看 DNS Operator 的日志:

$ oc logs --namespace=openshift-dns-operator deployment/dns-operator

第 5 章 OpenShift Container Platform 中的 Ingress Operator

Ingress Operator 实现了 ingresscontroller API,它是负责启用对 OpenShift Container Platform 集群服务的外部访问的组件。Operator 通过部署和管理一个或多个基于 HAProxy 的 Ingress Controller 来处理路由,从而达成这个目标。您可以通过指定 OpenShift Container Platform Route 和 Kubernetes Ingress 资源,来使用 Ingress Operator 路由流量。

5.1. Ingress 配置资产

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

Ingress 资源的 YAML 定义

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: apps.openshiftdemos.com

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

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

5.2. Ingress 控制器配置参数

ingresscontrollers.operator.openshift.io 资源提供了以下配置参数。

参数描述

domain

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

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

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

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

replicas

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

endpointPublishingStrategy

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

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

  • AWS: LoadBalancerService (具有外部范围)
  • Azure: LoadBalancerService (具有外部范围)
  • GCP: LoadBalancerService (具有外部范围)
  • 其它: HostNetwork

endpointPublishingStrategy 的值不能被更新。

defaultCertificate

defaultCertificate 的值是一个到包括由 Ingress controller 提供的默认证书的 secret 的指代。当 Routes 没有指定其自身证书时,使用 defaultCertificate

secret 必须包含以下密钥和数据:* tls.crt:证书文件内容 * tls.key:密钥文件内容

如果没有设置,则自动生成和使用通配符证书。该证书对 Ingress Controller 的子域有效,所生成的证书的 CA 会自动与集群的信任存储集成。

内部证书(无论是生成的证书还是用户指定的证书)自动与 OpenShift Container Platform 内置的 OAuth 服务器集成。

namespaceSelector

namespaceSelector 用来过滤由 Ingress 控制器提供服务的一组命名空间。这对实现分片(shard)非常有用。

routeSelector

routeSelector 用于由 Ingress 控制器提供服务的一组 Route。这对实现分片(shard)非常有用。

nodePlacement

nodePlacement 启用对 Ingress 控制器调度的明确控制。

如果没有设置,则使用默认值。

注意

nodePlacement 参数包括两个部分: nodeSelectortolerations。例如:

nodePlacement:
 nodeSelector:
   matchLabels:
     beta.kubernetes.io/os: linux
 tolerations:
 - effect: NoSchedule
   operator: Exists
注意

所有参数都是可选的。

5.2.1. Ingress 控制器端点发布策略

带有 HostNetwork 端点发布策略的 Ingress 控制器每个节点只能有一个 Pod 副本。如果您想要 n 个副本,则必须至少使用可调度这些副本的 n 个节点。因为每个 Pod 副本都会通过调度的节点主机上的端口 80443 进行请求,所以如果同一节点上的其他 Pod 使用这些端口,则无法将副本调度到该节点。

5.3. 查看默认的 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

5.4. 查看 Ingress Operator 状态

您可以查看并检查 Ingress Operator 的状态。

流程

  • 查看您的 Ingress Operator 状态:

    $ oc describe clusteroperators/ingress

5.5. 查看 Ingress Controller 日志

您可以查看 Ingress Controller 日志。

流程

  • 查看 Ingress Controller 日志:

    $ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator

5.6. 查看 Ingress Controller 状态

您可以查看特定 Ingress Controller 的状态。

流程

  • 查看 Ingress Controller 的状态:

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

5.7. 设置自定义默认证书

作为管理员,您可以通过创建 Secret 资源并编辑 IngressController 自定义资源 (CR),将 Ingress Controller 配置为使用自定义证书。

先决条件

  • 您必须在 PEM 编码文件中有一个证书/密钥对,其中该证书由可信证书认证机构签名,或者由您在一个自定义 PKI 中配置的私有可信证书认证机构签名。
  • 您的证书对 Ingress 域有效。
  • 您必须有一个 IngressController CR。您可以使用默认值:

    $ oc --namespace openshift-ingress-operator get ingresscontrollers
    NAME      AGE
    default   10m
注意

如果您有中间证书,则必须将其包含在包含自定义默认证书的 secret 的 tls.crt 文件中。指定证书时指定的顺序是相关的; 在任意服务器证书后列出您的中间证书。

流程

以下步骤假定自定义证书和密钥对位于当前工作目录下的 tls.crttls.key 文件中。替换 tls.crttls.key 的实际路径名。在创建 Secret 资源并在 IngressController CR 中引用它时,您也可以将 custom-certs-default 替换成另一名称。

注意

此操作会导致使用滚动部署策略重新部署 Ingress Controller。

  1. 使用 tls.crttls.key 文件,创建在 openshift-ingress 命名空间中包含自定义证书的 Secret 资源。

    $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
  2. 更新 IngressController CR,以引用新的证书 Secret:

    $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
      --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
  3. 验证更新是否已生效:

    $ oc get --namespace openshift-ingress-operator ingresscontrollers/default \
      --output jsonpath='{.spec.defaultCertificate}'

    输出应类似于如下:

    map[name:custom-certs-default]

    证书 Secret 名称应该与用来更新 CR 的值匹配。

修改了 IngressController CR 后,Ingress Operator 将更新 Ingress Controller 的部署以使用自定义证书。

5.8. 扩展 Ingress Controller

手动扩展 Ingress Controller 以满足路由性能或可用性要求,如增大吞吐量的要求。oc 命令可以被用来扩展 IngressController 资源。以下流程提供了扩展默认 IngressController 的示例。

流程

  1. 查看默认 IngressController 的当前可用副本数:

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    2
  2. 使用 oc patch 命令,将默认 IngressController 扩展至所需的副本数。以下示例将默认 IngressController 扩展至 3 个副本:

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
    ingresscontroller.operator.openshift.io/default patched
  3. 验证默认 IngressController 是否已扩展至您指定的副本数:

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    3
注意

扩展不是立刻就可以完成的操作,因为它需要时间来创建所需的副本数。

5.9. 通过路由标签(label)配置 Ingress Controller 分片

使用路由标签进行 Ingress Controller 分片,意味着 Ingress Controller 提供由路由选择器选择的任意命名空间中的所有路由。

在一组 Ingress Controller 之间平衡传入的流量负载时,以及在将流量隔离到特定 Ingress Controller 时,Ingress Controller 分片会很有用处。例如,A 公司的流量使用一个 Ingress Controller,B 公司的流量则使用另外一个 Ingress Controller。

流程

  1. 编辑 router-internal.yaml 文件:

    # cat router-internal.yaml
    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        routeSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
  2. 应用 Ingress Controller router-internal.yaml 文件:

    # oc apply -f router-internal.yaml

    Ingress Controller 选择具有 type: sharded 标签的任意命名空间中的路由。

5.10. 使用命名空间标签配置 Ingress Controller 分片

使用命名空间标签进行 Ingress Controller 分片,意味着 Ingress Controller 提供由命名空间选择器选择的任意命名空间中的所有路由。

在一组 Ingress Controller 之间平衡传入的流量负载时,以及在将流量隔离到特定 Ingress Controller 时,Ingress Controller 分片会很有用处。例如,A 公司的流量使用一个 Ingress Controller,B 公司的流量则使用另外一个 Ingress Controller。

流程

  1. 编辑 router-internal.yaml 文件:

    # cat router-internal.yaml
    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        namespaceSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
  2. 应用 Ingress Controller router-internal.yaml 文件:

    # oc apply -f router-internal.yaml

    Ingress Controller 选择由命名空间选择器选择的具有 type: sharded 标签的任意命名空间中的路由。

5.11. 配置 Ingress Controller 以使用内部负载均衡器

当在云平台上创建 Ingress Controller 时,Ingress Controller 默认由一个公共云负载均衡器发布。作为管理员,您可以创建一个使用内部云负载均衡器的 Ingress Controller。

警告

如果云供应商是 Microsoft Azure,则必须至少有一个指向节点的公共负载均衡器。如果不这样做,所有节点都将丢失到互联网的出站连接。

重要

如果要更改 IngressController 对象的 scope ,您必须删除并重新创建 IngressController 对象。您无法在创建自定义资源 (CR) 后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。

有关实现详情请查看 Kubernetes 服务文档

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在名为 <name>-ingress-controller.yaml 的文件中创建 IngressController 自定义资源 (CR) ,如下例所示:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: <name> 1
    spec:
      domain: <domain> 2
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal 3
    1
    <name> 替换为 IngressController 对象的名称。
    2
    指定控制器发布的应用程序的 domain
    3
    指定一个 Internal 值以使用内部负载均衡器。
  2. 运行以下命令,创建上一步中定义的 Ingress Controller:

    $ oc create -f <name>-ingress-controller.yaml 1
    1
    <name> 替换为 IngressController 对象的名称。
  3. 可选:通过运行以下命令确认创建了 Ingress Controller:

    $ oc --all-namespaces=true get ingresscontrollers

5.12. 将集群的默认 Ingress Controller 配置为内部

您可以通过删除并重新它来将默认 Ingress Controller 配置为内部。

警告

如果云供应商是 Microsoft Azure,则必须至少有一个指向节点的公共负载均衡器。如果不这样做,所有节点都将丢失到互联网的出站连接。

重要

如果要更改 IngressController 对象的 scope ,您必须删除并重新创建 IngressController 对象。您无法在创建自定义资源 (CR) 后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 通过删除并重新创建集群,将 默认 Ingress Controller 配置为内部。

    $ oc replace --force --wait --filename - <<EOF
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: default
    spec:
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal
    EOF

5.13. 其他资源

第 6 章 使用 OpenShift SDN 配置网络策略

6.1. 关于网络策略

在使用支持 Kubernetes 网络策略的 Kubernetes Container Network Interface (CNI) 插件的集群中,网络隔离完全由 NetworkPolicy 对象控制。在 OpenShift Container Platform 4.2 中,OpenShift SDN 支持在默认的网络隔离模式中使用 NetworkPolicy。

注意

OpenShift Container Platform 中提供了 Kubernetes v1 NetworkPolicy 功能,但 Egress 策略类型和 IPBlock 除外。

警告

网络策略不适用于主机网络命名空间。启用主机网络的 Pod 不受 NetworkPolicy 对象规则的影响 。

默认情况下,项目中的所有 Pod 都可被其他 Pod 和网络端点访问。要在一个项目中隔离一个或多个 Pod,您可以在该项目中创建 NetworkPolicy 对象来指示允许的入站连接。项目管理员可以在自己的项目中创建和删除 NetworkPolicy 对象。

如果一个 Pod 由一个或多个 NetworkPolicy 对象中的选择器匹配,那么该 Pod 将只接受至少被其中一个 NetworkPolicy 对象所允许的连接。未被任何 NetworkPolicy 对象选择的 Pod 可以完全访问。

以下示例 NetworkPolicy 对象演示了支持不同的情景:

  • 拒绝所有流量:

    要使项目默认为拒绝流量,请添加一个匹配所有 Pod 但不接受任何流量的 NetworkPolicy 对象:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
    spec:
      podSelector:
      ingress: []
  • 只允许 OpenShift Container Platform Ingress Controller 的连接:

    要使项目只允许 OpenShift Container Platform Ingress Controller 的连接,请添加以下 NetworkPolicy 对象:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-ingress
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: ingress
      podSelector: {}
      policyTypes:
      - Ingress

    如果 Ingress Controller 配置了endpointPublishingStrategy: HostNetwork,则 Ingress Controller Pod 在主机网络中运行。在主机网络中运行时,来自 Ingress Controller 的网络流量会被分配 netid:0 Virtual Network ID (VNID) 。与 Ingress Operator 关联的命名空间的 netid 不同,因此 allow-from-openshift-ingress 中的 matchLabel 网络策略与 default Ingress Controller 的流量不匹配。因为 default 命名空间被分配了 netid:0 VNID,所以可以通过把 default 命名空间标记(label)为 network.openshift.io/policy-group: ingress 来允许来自于 default Ingress Controller 的网络流量。

  • 只接受项目中 Pod 的连接:

    要使 Pod 接受同一项目中其他 Pod 的连接,但拒绝其他项目中所有 Pod 的连接,请添加以下 NetworkPolicy 对象:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-same-namespace
    spec:
      podSelector:
      ingress:
      - from:
        - podSelector: {}
  • 只允许基于 Pod 标签的 HTTP 和 HTTPS 流量:

    要对带有特定标签(以下示例中的 role=frontend)的 Pod 仅启用 HTTP 和 HTTPS 访问,请添加类似如下的 NetworkPolicy 对象:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-http-and-https
    spec:
      podSelector:
        matchLabels:
          role: frontend
      ingress:
      - ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 443
  • 使用命名空间和 Pod 选择器接受连接:

    要通过组合使用命名空间和 Pod 选择器来匹配网络流量,您可以使用类似如下的一个 NetworkPolicy 对象:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-pod-and-namespace-both
    spec:
      podSelector:
        matchLabels:
          name: test-pods
      ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                project: project_name
            podSelector:
              matchLabels:
                name: test-pods

NetworkPolicy 对象是可添加的;也就是说,您可以组合多个 NetworkPolicy 对象来满足复杂的网络要求。

例如,对于以上示例中定义的 NetworkPolicy 对象,您可以在同一个项目中定义 allow-same-namespaceallow-http-and-https 策略。因此,允许带有标签 role=frontend 的 Pod 接受每一策略所允许的任何连接。即,任何端口上来自同一命名空间中 Pod 的连接,以及端口 80443 上来自任意命名空间中 Pod 的连接。

6.2. 示例 NetworkPolicy 对象

下文解释了示例 NetworkPolicy 对象:

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017
1
NetworkPolicy 对象的名称
2
一个选择器(selector)用于描述策略应用到的 Pod。策略对象只能选择定义了 NetworkPolicy 对象的项目中的 Pod。
3
与策略对象允许从其传入流量的 Pod 匹配的选择器。选择器将匹配任何项目中的 Pod。
4
接受流量的一个或多个目标端口的列表。

6.3. 创建 NetworkPolicy 对象

要定义细致的规则来描述集群中项目允许的 Ingress 网络流量,您可以创建 NetworkPolicy 对象。

先决条件

  • 使用 OpenShift SDN 网络插件的集群,并设置了 mode: NetworkPolicy。此模式是 OpenShift SDN 的默认模式。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须登录集群。

流程

  1. 创建策略规则:

    1. 创建一个 <policy-name>.yaml 文件,其中 <policy-name> 描述策略规则。
    2. 在刚才创建的文件中,定义一个策略对象,如下例所示:

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: <policy-name> 1
      spec:
        podSelector:
        ingress: []
      1
      为策略对象指定一个名称。
  2. 运行以下命令来创建策略对象:

    $ oc create -f <policy-name>.yaml -n <project>

    在以下示例中,在名为 project1 的项目中创建一个新 NetworkPolicy 对象:

    $ oc create -f default-deny.yaml -n project1
    networkpolicy "default-deny" created

6.4. 删除 NetworkPolicy 对象

您可以删除 NetworkPolicy 对象。

先决条件

  • 使用 OpenShift SDN 网络插件的集群,并设置了 mode: NetworkPolicy。此模式是 OpenShift SDN 的默认模式。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须登录集群。

流程

  • 要删除 NetworkPolicy 对象,请运行以下命令:

    $ oc delete networkpolicy -l name=<policy-name> 1
    1
    指定要删除的 NetworkPolicy 对象的名称。

6.5. 查看 NetworkPolicy 对象

您可以列出集群中的 NetworkPolicy 对象。

先决条件

  • 使用 OpenShift SDN 网络插件的集群,并设置了 mode: NetworkPolicy。此模式是 OpenShift SDN 的默认模式。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须登录集群。

流程

  • 要查看集群中定义的 NetworkPolicy 对象,请运行以下命令:

    $ oc get networkpolicy

6.6. 使用 NetworkPolicy 配置多租户隔离

您可以配置项目,使其与其他项目中的 Pod 和服务分离。

先决条件

  • 使用 OpenShift SDN 网络插件的集群,并设置了 mode: NetworkPolicy。此模式是 OpenShift SDN 的默认模式。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须登录集群。

流程

  1. 创建包含 NetworkPolicy 对象定义的以下文件:

    1. 名为 allow-from-openshift-ingress.yaml 的文件,包含以下内容:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
    2. 名为 allow-from-openshift-monitoring.yaml 的文件,包含以下内容:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
  2. 对于每个策略文件,运行以下命令来创建 NetworkPolicy 对象:

    $ oc apply -f <policy-name>.yaml \ 1
      -n <project> 2
    1
    <policy-name> 替换为包含该策略的文件的文件名。
    2
    <project> 替换为将 NetworkPolicy 对象应用到的项目的名称。
  3. 如果 default Ingress Controller 配置设置了 spec.endpointPublishingStrategy: HostNetwork 值,您需要为 default OpenShift Container Platform 命名空间添加一个标记来允许 Ingress Controller 和项目间的网络流量:

    1. 确定您的 default Ingress Controller 是否使用了 HostNetwork 端点发布策略:

      $ oc get --namespace openshift-ingress-operator ingresscontrollers/default \
        --output jsonpath='{.status.endpointPublishingStrategy.type}'
    2. 如果上个命令报告了端点发布策略为 HostNetwork,在 default 命名空间中设置一个标记:

      $ oc label namespace default 'network.openshift.io/policy-group=ingress'
  4. 可选:运行以下命令确认当前项目中存在 NetworkPolicy 对象:

    $ oc get networkpolicy <policy-name> -o yaml

    在以下示例中会显示 allow-from-openshift-ingress NetworkPolicy 对象:

    $ oc get networkpolicy allow-from-openshift-ingress -o yaml
    
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-ingress
      namespace: project1
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: ingress
      podSelector: {}
      policyTypes:
      - Ingress

6.7. 为新项目创建默认网络策略

作为集群管理员,您可以在创建新项目时修改新项目模板,使其自动包含 NetworkPolicy 对象。

6.7.1. 为新项目修改模板

作为集群管理员,您可以修改默认项目模板,以便使用自定义要求创建新项目。

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

流程

  1. 以具有 cluster-admin 特权的用户身份登录。
  2. 生成默认项目模板:

    $ oc adm create-bootstrap-project-template -o yaml > template.yaml
  3. 使用文本编辑器,通过添加对象或修改现有对象来修改生成的 template.yaml 文件。
  4. 项目模板必须创建在 openshift-config 命名空间中。加载修改后的模板:

    $ oc create -f template.yaml -n openshift-config
  5. 使用 Web 控制台或 CLI 编辑项目配置资源。

    • 使用 Web 控制台:

      1. 导航至 AdministrationCluster Settings 页面。
      2. 点击 Global Configuration,查看所有配置资源。
      3. 找到 Project 的条目,并点击 Edit YAML
    • 使用 CLI:

      1. 编辑 project.config.openshift.io/cluster 资源:

        $ oc edit project.config.openshift.io/cluster
  6. 更新 spec 部分,使其包含 projectRequestTemplatename 参数,再设置您上传的项目模板的名称。默认名称为 project-request

    带有自定义项目模板的项目配置资源

    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
      ...
    spec:
      projectRequestTemplate:
        name: <template_name>

  7. 保存更改后,创建一个新项目来验证是否成功应用了您的更改。

6.7.2. 在新项目模板中添加网络策略对象

作为集群管理员,您可以在新项目的默认模板中添加网络策略对象。OpenShift Container Platform 将自动创建项目中模板指定的所有 NetworkPolicy CR。

先决条件

  • 使用 OpenShift SDN 网络插件的集群,并设置了 mode: NetworkPolicy。此模式是 OpenShift SDN 的默认模式。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您需要使用具有 cluster-admin 权限的用户登陆到集群。
  • 您必须已为新项目创建了自定义的默认项目模板。

流程

  1. 运行以下命令来编辑新项目的默认模板:

    $ oc edit template <project_template> -n openshift-config

    <project_template> 替换为您为集群配置的缺省模板的名称。默认模板名称为 project-request

  2. 在模板中,将每个 NetworkPolicy 对象作为一个元素添加到 objects参数中。objects 参数可以是一个或多个对象的集合。

    在以下示例中,objects 参数集合包括几个 NetworkPolicy 对象:

    objects:
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
    ...
  3. 可选:通过运行以下命令创建一个新项目,来确认您的网络策略对象已被成功创建:

    1. 创建一个新项目

      $ oc new-project <project> 1
      1
      <project> 替换为您要创建的项目的名称。
    2. 确认新项目模板中的网络策略对象存在于新项目中:

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s

第 7 章 多网络

7.1. 了解多网络

在 Kubernetes 中,容器联网由实现了 Container Network Interface (CNI) 的网络插件负责。

OpenShift Container Platform 使用 Multus CNI 插件来实现对 CNI 插件的链接。在集群安装过程中,您要配置default Pod 网络。默认网络处理集群中的所有一般网络流量。您可以基于可用的 CNI 插件定义额外网络,并将一个或多个这种网络附加到 Pod。您可以根据需要为集群定义多个额外网络。这可让您灵活地配置提供交换或路由等网络功能的 Pod。

7.1.1. 额外网络使用场景

您可以在需要网络隔离的情况下使用额外网络,包括分离数据平面与控制平面。隔离网络流量对以下性能和安全性原因很有用:

性能
您可以在两个不同的平面上发送流量,以管理每个平面上流量的多少。
安全性
您可以将敏感的流量发送到专为安全考虑而管理的网络平面,也可隔离不能在租户或客户间共享的私密数据。

集群中的所有 Pod 仍然使用集群范围的默认网络,以维持整个集群中的连通性。每个 Pod 都有一个 eth0 接口,附加到集群范围的 Pod 网络。您可以使用 oc exec -it <pod_name> -- ip a 命令来查看 Pod 的接口。如果您添加了使用 Multus CNI 的额外网络接口,它们会命名为 net1net2、...、netN

要将额外网络接口附加到 Pod,您必须创建配置来定义接口的附加方式。您可以使用 NetworkAttachmentDefinition 类型的自定义资源 (CR) 来指定各个接口。各个 CR 中的 CNI 配置定义如何创建该接口。

7.1.2. OpenShift Container Platform 中的额外网络

OpenShift Container Platform 提供以下 CNI 插件,以便在集群中创建额外网络:

  • bridge创建基于网桥的额外网络可让同一主机中的 Pod 相互通信,并与主机通信。
  • host-device创建 host-device 额外网络可让 Pod 访问主机系统上的物理以太网网络设备。
  • macvlan创建基于 macvlan 的额外网络可让主机上的 Pod 通过使用物理网络接口与其他主机和那些主机上的 Pod 通信。附加到基于 macvlan 的额外网络的每个 Pod 都会获得一个唯一的 MAC 地址。
  • ipvlan创建基于 ipvlan 的额外网络可让主机上的 Pod 与其他主机和那些主机上的 Pod 通信,这类似于基于 macvlan 的额外网络。与基于 macvlan 的额外网络不同,每个 Pod 共享与父级物理网络接口相同的 MAC 地址。
  • SR-IOV创建基于 SR-IOV 的额外网络可让 Pod 附加到主机系统上支持 SR-IOV 的硬件的虚拟功能 (VF) 接口。

7.2. 将 Pod 附加到额外网络

作为集群用户,您可以将 Pod 附加到额外网络。

7.2.1. 将 Pod 添加到额外网络

您可以将 Pod 添加到额外网络。Pod 继续通过默认网络发送与集群相关的普通网络流量。

先决条件

  • Pod 必须与额外网络处于相同的命名空间。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须登录集群。

流程

要添加带有额外网络的 Pod,请完成以下步骤:

  1. 在 Pod 资源定义中,将 k8s.v1.cni.cncf.io/networks 参数添加到 Pod metadata 映射中。k8s.v1.cni.cncf.io/networks 接受由一个或多个 NetworkAttachmentDefinition 自定义资源 (CR) 名称组成并用逗号分隔的字符串:

    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
    1
    <network> 替换为要与 Pod 关联的额外网络的名称。要指定多个额外网络,请使用逗号分隔各个网络。逗号之间不可包括空格。如果您多次指定同一额外网络,则 Pod 会将多个网络接口附加到该网络。

    在以下示例中,两个额外网络附加到 Pod:

    apiVersion: v1
    kind: Pod
    metadata:
      name: example-pod
      annotations:
        k8s.v1.cni.cncf.io/networks: net1,net2
    spec:
      containers:
      - name: example-pod
        command: ["/bin/bash", "-c", "sleep 2000000000000"]
        image: centos/tools
  2. 运行以下命令来创建 Pod:

    $ oc create -f pod.yaml
  3. 可选:通过运行以下命令,确认 Pod CR 中是否存在注解。将 <name> 替换为 Pod 的名称。

    $ oc get pod <name> -o yaml

    在以下示例中,example-pod Pod 附加到 net1 额外网络:

    $ oc get pod example-pod -o yaml
    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: macvlan-bridge
        k8s.v1.cni.cncf.io/networks-status: |- 1
          [{
              "name": "openshift-sdn",
              "interface": "eth0",
              "ips": [
                  "10.128.2.14"
              ],
              "default": true,
              "dns": {}
          },{
              "name": "macvlan-bridge",
              "interface": "net1",
              "ips": [
                  "20.2.2.100"
              ],
              "mac": "22:2f:60:a5:f8:00",
              "dns": {}
          }]
      name: example-pod
      namespace: default
    spec:
      ...
    status:
      ...
    1
    k8s.v1.cni.cncf.io/networks-status 参数是对象的 JSON 数组。每个对象描述附加到 Pod 的额外网络的状态。注解值保存为纯文本值。

7.3. 从额外网络中删除 Pod

作为集群用户,您可以从额外网络中删除 Pod。

7.3.1. 从额外网络中删除 Pod

您可以从额外网络中删除 Pod。

先决条件

  • 已为集群配置了额外网络。
  • 将额外网络附加到 Pod。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须登录集群。

流程

要从额外网络中删除 Pod,请完成以下步骤:

  1. 运行以下命令来编辑 Pod 资源定义。将 <name> 替换为要编辑的 Pod 的名称。

    $ oc edit pod <name>
  2. 通过执行以下操作之一,更新 annotations 映射,以便从 Pod 中删除额外网络:

    • 要从 Pod 中删除所有额外网络,请从 Pod 资源定义中删除 k8s.v1.cni.cncf.io/networks 参数,如下例所示:

      apiVersion: v1
      kind: Pod
      metadata:
        name: example-pod
        annotations: {}
      spec:
        containers:
        - name: example-pod
          command: ["/bin/bash", "-c", "sleep 2000000000000"]
          image: centos/tools
    • 要从 Pod 中删除一个特定的额外网络,请删除这个额外网络的 NetworkAttachmentDefinition 名称,以更新 k8s.v1.cni.cncf.io/networks 参数。
  3. 可选:通过运行以下命令,确认 Pod 不再附加到额外网络。将 <name> 替换为 Pod 的名称。

    $ oc describe pod <name>

    在以下示例中,example-pod Pod 仅附加到默认集群网络。

    $ oc describe pod example-pod
    
    Name:               example-pod
    ...
    Annotations:        k8s.v1.cni.cncf.io/networks-status:
                          [{
                              "name": "openshift-sdn",
                              "interface": "eth0",
                              "ips": [
                                  "10.131.0.13"
                              ],
                              "default": true, 1
                              "dns": {}
                          }]
    Status:             Running
    ...
    1
    只有默认集群网络附加到 Pod。

7.4. 配置桥接网络

作为集群管理员,您可以使用 bridge Container Network Interface (CNI) 插件为集群配置额外网络。配置之后,节点上的所有 Pod 都会连接到虚拟交换机。每个 Pod 都会在额外网络中分配一个 IP 地址。

7.4.1. 使用 bridge CNI 插件创建额外网络附加

Cluster Network Operator (CNO) 管理额外网络定义。当您指定要创建的额外网络时,CNO 会自动创建 NetworkAttachmentDefinition 自定义资源 (CR)。

重要

请勿编辑 Cluster Network Operator 所管理的 NetworkAttachmentDefinition CR。这样做可能会破坏额外网络上的网络流量。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

要为集群创建额外网络,请完成以下步骤:

  1. 运行以下命令来编辑 CNO CR:

    $ oc edit networks.operator.openshift.io cluster
  2. 通过为要创建的额外网络添加配置来修改您要创建的 CR,如以下示例 CR 中所示。

    以下 YAML 配置 bridge CNI 插件:

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: 1
      - name: test-network-1
        namespace: test-1
        type: Raw
        rawCNIConfig: '{
          "cniVersion": "0.3.1",
          "type": "bridge",
          "master": "eth1",
          "ipam": {
            "type": "static",
            "addresses": [
              {
                "address": "191.168.1.1/24"
              }
            ]
          }
        }'
    1
    指定额外网络附加定义的配置。
  3. 保存您的更改,再退出文本编辑器以提交更改。
  4. 可选:通过运行以下命令确认 CNO 创建了 NetworkAttachmentDefinition CR。CNO 创建 CR 之前可能会有延迟。

    $ oc get network-attachment-definitions -n <namespace>
    NAME                 AGE
    test-network-1       14m

7.4.1.1. 配置网桥

使用 bridge Container Network Interface (CNI) 插件的额外网络附加配置由以下两个部分提供:

  • Cluster Network Operator (CNO) 配置
  • CNI 插件配置

CNO 配置指定额外网络附加的名称,以及用于在其中创建网络附加的命名空间。该插件由 CNO 配置中 rawCNIConfig 参数指定的 JSON 对象进行配置。

以下 YAML 描述了 CNO 的配置参数:

Cluster Network Operator YAML 配置

name: <name> 1
namespace: <namespace> 2
rawCNIConfig: '{ 3
  ...
}'
type: Raw

1
为您要创建的额外网络附加指定名称。该名称在指定的 namespace 中需要是唯一的。
2
指定要在其中创建网络附加的命名空间。如果您未指定值,则使用 default 命名空间。
3
基于以下模板,以 JSON 格式指定 CNI 插件配置。

以下对象描述了 bridge CNI 插件的配置参数:

bridge CNI 插件 JSON 配置对象

{
  "cniVersion": "0.3.1",
  "name": "<name>", 1
  "type": "bridge",
  "bridge": "<bridge>", 2
  "ipam": { 3
    ...
  },
  "ipMasq": false, 4
  "isGateway": false, 5
  "isDefaultGateway": false, 6
  "forceAddress": false, 7
  "hairpinMode": false, 8
  "promiscMode": false, 9
  "vlan": <vlan>, 10
  "mtu": <mtu> 11
}

1
为您之前为 CNO 配置提供的 name 参数指定值。
2
指定要使用的虚拟网桥名称。如果主机上不存在网桥接口,则进行创建。默认值为 cni0
3
为 ipam CNI 插件指定配置对象。该插件为网络附加定义管理 IP 地址分配。
4
设置为 true,从而为离开虚拟网络的流量启用 IP 伪装。所有流量的源 IP 地址都会改写为网桥 IP 地址。如果网桥没有 IP 地址,此设置无效。默认值为 false
5
设置为 true,从而为网桥分配 IP 地址。默认值为 false
6
设置为 true,从而将网桥配置为虚拟网络的默认网关。默认值为 false。如果 isDefaultGateway 设置为 true,则 isGateway 也会自动设置为 true
7
设置为 true,从而允许将之前分配的 IP 地址分配给虚拟网桥。设置为 false 时,如果将来自于重叠子集的 IPv4 地址或者 IPv6 地址分配给虚拟网桥,则会发生错误。默认值为 false
8
设置为 true,从而允许虚拟网桥通过接收了以太网帧的虚拟端口将其重新发送回去。这个模式也被称为反射中继。默认值为 false
9
设置为 true,从而在网桥上启用混杂模式。默认值为 false
10
以整数值形式指定虚拟 LAN (VLAN) 标签。默认情况下不分配 VLAN 标签。
11
将最大传输单位 (MTU) 设置为指定的值。默认值由内核自动设置。
7.4.1.1.1. 网桥配置示例

以下示例配置了名为 bridge-net 的额外网络:

name: bridge-net
namespace: work-network
type: Raw
rawCNIConfig: '{ 1
  "cniVersion": "0.3.1",
  "type": "bridge",
  "master": "eth1",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}'
1
以 YAML 字符串形式指定 CNI 配置对象。

7.4.1.2. 配置 ipam CNI 插件

IP 地址管理 (IPAM) CNI 插件为其他 CNI 插件管理 IP 地址分配。您可以配置 ipam 以进行静态 IP 地址分配或使用 DHCP 进行动态 IP 地址分配。您指定的 DHCP 服务器必须可从额外网络访问。

重要

在 OpenShift Container Platform 4.2.0 中,如果您将 Pod 附加到使用 DHCP 进行 IP 地址管理的额外网络中,则 Pod 将无法启动。OpenShift Container Platform 4.2.1 已修复了这个问题。如需更多信息,请参阅 BZ#1754686

以下 JSON 配置对象描述了您可以设置的参数。

重要

如果您将 type 参数设置为 DHCP 值,则无法设置任何其他参数。

ipam CNI 插件 JSON 配置对象

{
  "ipam": {
    "type": "<type>", 1
    "addresses": [ 2
      {
        "address": "<address>", 3
        "gateway": "<gateway>" 4
      }
    ],
    "routes": [ 5
      {
        "dst": "<dst>" 6
        "gw": "<gw>" 7
      }
    ],
    "dns": { 8
      "nameservers": ["<nameserver>"], 9
      "domain": "<domain>", 10
      "search": ["<search_domain>"] 11
    }
  }
}

1
指定 static,以配置插件来管理 IP 地址分配。指定 DHCP,以允许 DHCP 服务器管理 IP 地址分配。如果指定了 DHCP 值,则无法指定任何其他参数。
2
定义分配给虚拟接口的 IP 地址的数组。支持 IPv4 和 IPv6 IP 地址。
3
您以 CIDR 格式指定的分配给 worker 节点上 Pod 的 IP 地址块,如 10.1.1.0/24
4
出口网络流量要路由到的默认网关。
5
描述要在 Pod 中配置的路由的数组。
6
CIDR 格式的 IP 地址范围。
7
用于将网络流量路由到的网关。
8
DNS 配置。可选。
9
用来发送 DNS 查询的一个或多个 IP 地址的数组。
10
附加到主机名的默认域。例如,如果将域设置为 example.com,对 example-host 的 DNS 查找查询将被改写为 example-host.example.com
11
在 DNS 查找查询过程中,附加到非限定主机名(如 example-host)的域名的数组。
7.4.1.2.1. 静态 IP 地址分配配置示例

您可以配置 ipam 以进行静态 IP 地址分配:

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.1/24"
        }
      ]
  }
}
7.4.1.2.2. 动态 IP 地址分配配置示例

您可以配置 ipam 以使用 DHCP:

{
  "ipam": {
    "type": "DHCP"
  }
}

7.5. 配置 macvlan 网络

作为集群管理员,您可以使用 macvlan CNI 插件为集群配置额外网络。将 Pod 附加到网络时,插件会从主机上的父接口创建一个子接口。为每个子设备生成一个唯一的硬件 MAC 地址。

重要

此插件为子接口生成的这种唯一 MAC 地址可能与您的云供应商的安全策略不兼容。

7.5.1. 使用 macvlan CNI 插件创建额外网络附加

Cluster Network Operator (CNO) 管理额外网络定义。当您指定要创建的额外网络时,CNO 会自动创建 NetworkAttachmentDefinition 自定义资源 (CR)。

重要

请勿编辑 Cluster Network Operator 所管理的 NetworkAttachmentDefinition CR。这样做可能会破坏额外网络上的网络流量。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

要为集群创建额外网络,请完成以下步骤:

  1. 运行以下命令来编辑 CNO CR:

    $ oc edit networks.operator.openshift.io cluster
  2. 通过为要创建的额外网络添加配置来修改您要创建的 CR,如以下示例 CR 中所示。

    以下 YAML 配置 macvlan CNI 插件:

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: 1
      - name: test-network-1
        namespace: test-1
        type: SimpleMacvlan
        simpleMacvlanConfig:
          ipamConfig:
            type: static
            staticIPAMConfig:
              addresses:
              - address: 10.1.1.0/24
    1
    指定额外网络附加定义的配置。
  3. 保存您的更改,再退出文本编辑器以提交更改。
  4. 可选:通过运行以下命令确认 CNO 创建了 NetworkAttachmentDefinition CR。CNO 创建 CR 之前可能会有延迟。

    $ oc get network-attachment-definitions -n <namespace>
    NAME                 AGE
    test-network-1       14m

7.5.1.1. 配置 macvlan CNI 插件

以下 YAML 描述了 macvlan Container Network Interface (CNI) 插件的配置参数:

macvlan YAML 配置

name: <name> 1
namespace: <namespace> 2
type: SimpleMacvlan
simpleMacvlanConfig:
  master: <master> 3
  mode: <mode> 4
  mtu: <mtu> 5
  ipamConfig: 6
    ...

1
为您要创建的额外网络附加指定名称。该名称在指定的 namespace 中需要是唯一的。
2
指定要在其中创建网络附加的命名空间。如果没有指定值,则使用 default 命名空间。
3
与虚拟接口关联的以太网接口。如果没有指定 master 的值,则使用主机系统的主以太网接口。
4
配置虚拟网络上的流量可见性。必须是 bridgepassthruprivateVepa。如果没有提供 mode 的值,则默认值为 bridge
5
将最大传输单位 (MTU) 设置为指定的值。默认值由内核自动设置。
6
为 ipam CNI 插件指定配置对象。该插件管理网络附加定义的 IP 地址分配。
7.5.1.1.1. macvlan 配置示例

以下示例配置了名为 macvlan-net 的额外网络:

name: macvlan-net
namespace: work-network
type: SimpleMacvlan
simpleMacvlanConfig:
  ipamConfig:
    type: DHCP

7.5.1.2. 配置 ipam CNI 插件

IP 地址管理 (IPAM) CNI 插件为其他 CNI 插件管理 IP 地址分配。您可以配置 ipam 以进行静态 IP 地址分配或使用 DHCP 进行动态 IP 地址分配。您指定的 DHCP 服务器必须可从额外网络访问。

重要

在 OpenShift Container Platform 4.2.0 中,如果您将 Pod 附加到使用 DHCP 进行 IP 地址管理的额外网络中,则 Pod 将无法启动。OpenShift Container Platform 4.2.1 已修复了这个问题。如需更多信息,请参阅 BZ#1754686

以下 YAML 配置描述了您可以设置的参数。

重要

如果您将 type 参数设置为 DHCP 值,则无法设置任何其他参数。

ipam CNI 插件 YAML 配置对象

ipamConfig:
  type: <type> 1
  ... 2

1
指定 static,以配置插件来管理 IP 地址分配。指定 DHCP,以允许 DHCP 服务器管理 IP 地址分配。如果指定了 DHCP 值,则无法指定任何其他参数。
2
如果将 type 参数设为 static,请提供 staticIPAMConfig 参数。
7.5.1.2.1. 静态 ipam 配置 YAML

以下 YAML 描述了静态 IP 地址分配的配置:

静态 ipam 配置 YAML

ipamConfig:
  type: static
  staticIPAMConfig:
    addresses: 1
    - address: <address> 2
      gateway: <gateway> 3
    routes: 4
    - destination: <destination> 5
      gateway: <gateway> 6
    dns: 7
      nameservers: 8
      - <nameserver>
      domain: <domain> 9
      search: 10
      - <search_domain>

1
定义分配给虚拟接口的 IP 地址的一系列映射。支持 IPv4 和 IPv6 IP 地址。
2
您以 CIDR 格式指定的分配给 worker 节点上 Pod 的 IP 地址块,如 10.1.1.0/24
3
出口网络流量要路由到的默认网关。
4
描述要在 Pod 中配置的路由的一系列映射。
5
CIDR 格式的 IP 地址范围。
6
用于将网络流量路由到的网关。
7
DNS 配置。可选。
8
用于发送 DNS 查询的一个或多个 IP 地址的集合。
9
附加到主机名的默认域。例如,如果将域设置为 example.com,对 example-host 的 DNS 查找查询将被改写为 example-host.example.com
10
在 DNS 查找查询过程中,附加到非限定主机名(如 example-host)的域名的数组。
7.5.1.2.2. 动态 ipam 配置 YAML

以下 YAML 描述了静态 IP 地址分配的配置:

动态 ipam 配置 YAML

ipamConfig:
  type: DHCP

7.5.1.2.3. 静态 IP 地址分配配置示例

以下示例显示了静态 IP 地址的 ipam 配置:

ipamConfig:
  type: static
  staticIPAMConfig:
    addresses:
    - address: 198.51.100.11/24
      gateway: 198.51.100.10
    routes:
    - destination: 0.0.0.0/0
      gateway: 198.51.100.1
    dns:
      nameservers:
      - 198.51.100.1
      - 198.51.100.2
      domain: testDNS.example
      search:
      - testdomain1.example
      - testdomain2.example
7.5.1.2.4. 动态 IP 地址分配配置示例

以下示例显示了 DHCP 的 ipam 配置:

ipamConfig:
  type: DHCP

7.6. 配置 ipvlan 网络

作为集群管理员,您可以使用 ipvlan Container Network Interface (CNI) 插件为集群配置额外网络。此插件创建的虚拟网络与您指定的物理接口关联。

7.6.1. 使用 ipvlan CNI 插件创建额外网络附加

Cluster Network Operator (CNO) 管理额外网络定义。当您指定要创建的额外网络时,CNO 会自动创建 NetworkAttachmentDefinition 自定义资源 (CR)。

重要

请勿编辑 Cluster Network Operator 所管理的 NetworkAttachmentDefinition CR。这样做可能会破坏额外网络上的网络流量。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

要为集群创建额外网络,请完成以下步骤:

  1. 运行以下命令来编辑 CNO CR:

    $ oc edit networks.operator.openshift.io cluster
  2. 通过为要创建的额外网络添加配置来修改您要创建的 CR,如以下示例 CR 中所示。

    以下 YAML 配置 ipvlan CNI 插件:

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: 1
      - name: test-network-1
        namespace: test-1
        type: Raw
        rawCNIConfig: '{
          "cniVersion": "0.3.1",
          "type": "ipvlan",
          "master": "eth1",
          "mode": "l2",
          "ipam": {
            "type": "static",
            "addresses": [
              {
                "address": "191.168.1.1/24"
              }
            ]
          }
        }'
    1
    指定额外网络附加定义的配置。
  3. 保存您的更改,再退出文本编辑器以提交更改。
  4. 可选:通过运行以下命令确认 CNO 创建了 NetworkAttachmentDefinition CR。CNO 创建 CR 之前可能会有延迟。

    $ oc get network-attachment-definitions -n <namespace>
    NAME                 AGE
    test-network-1       14m

7.6.1.1. 配置 ipvlan

使用 ipvlan Container Network Interface (CNI) 插件的额外网络附加配置由以下两个部分提供:

  • Cluster Network Operator (CNO) 配置
  • CNI 插件配置

CNO 配置指定额外网络附加的名称,以及用于在其中创建网络附加的命名空间。该插件由 CNO 配置中 rawCNIConfig 参数指定的 JSON 对象进行配置。

以下 YAML 描述了 CNO 的配置参数:

Cluster Network Operator YAML 配置

name: <name> 1
namespace: <namespace> 2
rawCNIConfig: '{ 3
  ...
}'
type: Raw

1
为您要创建的额外网络附加指定名称。该名称在指定的 namespace 中需要是唯一的。
2
指定要在其中创建网络附加的命名空间。如果您未指定值,则使用 default 命名空间。
3
基于以下模板,以 JSON 格式指定 CNI 插件配置。

以下对象描述了 ipvlan CNI 插件的配置参数:

ipvlan CNI 插件 JSON 配置对象

{
  "cniVersion": "0.3.1",
  "name": "<name>", 1
  "type": "ipvlan",
  "mode": "<mode>", 2
  "master": "<master>", 3
  "mtu": <mtu>, 4
  "ipam": { 5
    ...
  }
}

1
为您之前为 CNO 配置提供的 name 参数指定值。
2
指定虚拟网络的操作模式。这个值必须是 l2l3l3s。默认值为 l2
3
指定与网络附加关联的以太网接口。如果没有指定 master,则使用默认网络路由的接口。
4
将最大传输单位 (MTU) 设置为指定的值。默认值由内核自动设置。
5
为 ipam CNI 插件指定配置对象。该插件管理网络附加定义的 IP 地址分配。
7.6.1.1.1. ipvlan 配置示例

以下示例配置了名为 ipvlan -net 的额外网络:

name: ipvlan-net
namespace: work-network
type: Raw
rawCNIConfig: '{ 1
  "cniVersion": "0.3.1",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "dhcp"
    }
}'
1
以 YAML 字符串形式指定 CNI 配置对象。

7.6.1.2. 配置 ipam CNI 插件

IP 地址管理 (IPAM) CNI 插件为其他 CNI 插件管理 IP 地址分配。您可以配置 ipam 以进行静态 IP 地址分配或使用 DHCP 进行动态 IP 地址分配。您指定的 DHCP 服务器必须可从额外网络访问。

重要

在 OpenShift Container Platform 4.2.0 中,如果您将 Pod 附加到使用 DHCP 进行 IP 地址管理的额外网络中,则 Pod 将无法启动。OpenShift Container Platform 4.2.1 已修复了这个问题。如需更多信息,请参阅 BZ#1754686

以下 JSON 配置对象描述了您可以设置的参数。

重要

如果您将 type 参数设置为 DHCP 值,则无法设置任何其他参数。

ipam CNI 插件 JSON 配置对象

{
  "ipam": {
    "type": "<type>", 1
    "addresses": [ 2
      {
        "address": "<address>", 3
        "gateway": "<gateway>" 4
      }
    ],
    "routes": [ 5
      {
        "dst": "<dst>" 6
        "gw": "<gw>" 7
      }
    ],
    "dns": { 8
      "nameservers": ["<nameserver>"], 9
      "domain": "<domain>", 10
      "search": ["<search_domain>"] 11
    }
  }
}

1
指定 static,以配置插件来管理 IP 地址分配。指定 DHCP,以允许 DHCP 服务器管理 IP 地址分配。如果指定了 DHCP 值,则无法指定任何其他参数。
2
定义分配给虚拟接口的 IP 地址的数组。支持 IPv4 和 IPv6 IP 地址。
3
您以 CIDR 格式指定的分配给 worker 节点上 Pod 的 IP 地址块,如 10.1.1.0/24
4
出口网络流量要路由到的默认网关。
5
描述要在 Pod 中配置的路由的数组。
6
CIDR 格式的 IP 地址范围。
7
用于将网络流量路由到的网关。
8
DNS 配置。可选。
9
用来发送 DNS 查询的一个或多个 IP 地址的数组。
10
附加到主机名的默认域。例如,如果将域设置为 example.com,对 example-host 的 DNS 查找查询将被改写为 example-host.example.com
11
在 DNS 查找查询过程中,附加到非限定主机名(如 example-host)的域名的数组。
7.6.1.2.1. 静态 IP 地址分配配置示例

您可以配置 ipam 以进行静态 IP 地址分配:

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.1/24"
        }
      ]
  }
}
7.6.1.2.2. 动态 IP 地址分配配置示例

您可以配置 ipam 以使用 DHCP:

{
  "ipam": {
    "type": "DHCP"
  }
}

7.7. 配置 host-device 网络

作为集群管理员,您可以使用 host-device Container Network Interface (CNI) 插件为集群配置额外网络。该插件允许您将指定网络设备从主机的网络命名空间移到 Pod 的网络命名空间。

7.7.1. 使用 host-device CNI 插件创建额外网络附加

Cluster Network Operator (CNO) 管理额外网络定义。当您指定要创建的额外网络时,CNO 会自动创建 NetworkAttachmentDefinition 自定义资源 (CR)。

重要

请勿编辑 Cluster Network Operator 所管理的 NetworkAttachmentDefinition CR。这样做可能会破坏额外网络上的网络流量。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

要为集群创建额外网络,请完成以下步骤:

  1. 运行以下命令来编辑 CNO CR:

    $ oc edit networks.operator.openshift.io cluster
  2. 通过为要创建的额外网络添加配置来修改您要创建的 CR,如以下示例 CR 中所示。

    以下 YAML 配置 host-device CNI 插件:

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: 1
      - name: test-network-1
        namespace: test-1
        type: Raw
        rawCNIConfig: '{
          "cniVersion": "0.3.1",
          "type": "host-device",
          "device": "eth1"
        }'
    1
    指定额外网络附加定义的配置。
  3. 保存您的更改,再退出文本编辑器以提交更改。
  4. 可选:通过运行以下命令确认 CNO 创建了 NetworkAttachmentDefinition CR。CNO 创建 CR 之前可能会有延迟。

    $ oc get network-attachment-definitions -n <namespace>
    NAME                 AGE
    test-network-1       14m

7.7.1.1. 配置 host-device

使用 host-device Container Network Interface (CNI) 插件的额外网络附加配置由以下两个部分提供:

  • Cluster Network Operator (CNO) 配置
  • CNI 插件配置

CNO 配置指定额外网络附加的名称,以及用于在其中创建网络附加的命名空间。该插件由 CNO 配置中 rawCNIConfig 参数指定的 JSON 对象进行配置。

以下 YAML 描述了 CNO 的配置参数:

Cluster Network Operator YAML 配置

name: <name> 1
namespace: <namespace> 2
rawCNIConfig: '{ 3
  ...
}'
type: Raw

1
为您要创建的额外网络附加指定名称。该名称在指定的 namespace 中需要是唯一的。
2
指定要在其中创建网络附加的命名空间。如果您未指定值,则使用 default 命名空间。
3
基于以下模板,以 JSON 格式指定 CNI 插件配置。
重要

仅设置以下参数之一来指定您的网络设备:deviceHWaddrkernelpathpciBusID

以下对象描述了 host-device CNI 插件的配置参数:

host-device CNI 插件 JSON 配置对象

{
  "cniVersion": "0.3.1",
  "name": "<name>", 1
  "type": "host-device",
  "device": "<device>", 2
  "hwaddr": "<hwaddr>", 3
  "kernelpath": "<kernelpath>", 4
  "pciBusID": "<pciBusID>", 5
    "ipam": { 6
    ...
  }
}

1
为您之前为 CNO 配置提供的 name 参数指定值。
2
指定设备的名称,如 eth0
3
指定设备硬件 MAC 地址。
4
指定 Linux 内核设备路径,如 /sys/devices/pci0000:00/0000:00:1f.6
5
指定网络设备的 PCI 地址,如 0000:00:1f.6
6
为 ipam CNI 插件指定配置对象。该插件管理网络附加定义的 IP 地址分配。
7.7.1.1.1. host-device 配置示例

以下示例配置了名为 hostdev-net 的额外网络:

name: hostdev-net
namespace: work-network
type: Raw
rawCNIConfig: '{ 1
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "eth1"
}'
1
以 YAML 字符串形式指定 CNI 配置对象。

7.7.1.2. 配置 ipam CNI 插件

IP 地址管理 (IPAM) CNI 插件为其他 CNI 插件管理 IP 地址分配。您可以配置 ipam 以进行静态 IP 地址分配或使用 DHCP 进行动态 IP 地址分配。您指定的 DHCP 服务器必须可从额外网络访问。

重要

在 OpenShift Container Platform 4.2.0 中,如果您将 Pod 附加到使用 DHCP 进行 IP 地址管理的额外网络中,则 Pod 将无法启动。OpenShift Container Platform 4.2.1 已修复了这个问题。如需更多信息,请参阅 BZ#1754686

以下 JSON 配置对象描述了您可以设置的参数。

重要

如果您将 type 参数设置为 DHCP 值,则无法设置任何其他参数。

ipam CNI 插件 JSON 配置对象

{
  "ipam": {
    "type": "<type>", 1
    "addresses": [ 2
      {
        "address": "<address>", 3
        "gateway": "<gateway>" 4
      }
    ],
    "routes": [ 5
      {
        "dst": "<dst>" 6
        "gw": "<gw>" 7
      }
    ],
    "dns": { 8
      "nameservers": ["<nameserver>"], 9
      "domain": "<domain>", 10
      "search": ["<search_domain>"] 11
    }
  }
}

1
指定 static,以配置插件来管理 IP 地址分配。指定 DHCP,以允许 DHCP 服务器管理 IP 地址分配。如果指定了 DHCP 值,则无法指定任何其他参数。
2
定义分配给虚拟接口的 IP 地址的数组。支持 IPv4 和 IPv6 IP 地址。
3
您以 CIDR 格式指定的分配给 worker 节点上 Pod 的 IP 地址块,如 10.1.1.0/24
4
出口网络流量要路由到的默认网关。
5
描述要在 Pod 中配置的路由的数组。
6
CIDR 格式的 IP 地址范围。
7
用于将网络流量路由到的网关。
8
DNS 配置。可选。
9
用来发送 DNS 查询的一个或多个 IP 地址的数组。
10
附加到主机名的默认域。例如,如果将域设置为 example.com,对 example-host 的 DNS 查找查询将被改写为 example-host.example.com
11
在 DNS 查找查询过程中,附加到非限定主机名(如 example-host)的域名的数组。
7.7.1.2.1. 静态 IP 地址分配配置示例

您可以配置 ipam 以进行静态 IP 地址分配:

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.1/24"
        }
      ]
  }
}
7.7.1.2.2. 动态 IP 地址分配配置示例

您可以配置 ipam 以使用 DHCP:

{
  "ipam": {
    "type": "DHCP"
  }
}

7.8. 为 SR-IOV 配置额外网络

重要

网络接口卡 (NIC) SR-IOV 硬件只是一个技术预览功能。红帽产品服务等级协议 (SLA) 不支持技术预览功能,且可能无法完成。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的详情,请参阅 https://access.redhat.com/support/offerings/techpreview/

7.8.1. 关于 OpenShift Container Platform 中的 SR-IOV 硬件

OpenShift Container Platform 包含在节点上使用 SR-IOV 硬件的功能。您可以将 SR-IOV 虚拟功能 (VF) 接口附加到带有 SR-IOV 硬件的节点上的 Pod。

您可以通过部署 SR-IOV Network Operator,使用 OpenShift Container Platform 控制台来安装 SR-IOV。SR-IOV Network Operator 会创建和管理 SR-IOV 堆栈的组件。Operator 提供以下功能:

  • 在集群中发现 SR-IOV 网络设备。
  • 在节点上初始化支持的 SR-IOV NIC 模型。
  • 在节点上置备 SR-IOV 网络设备插件。
  • 在节点上置备 SR-IOV CNI 插件可执行文件。
  • 在集群中置备 Network Resources Injector(网络资源注入器)。
  • 管理 SR-IOV 网络设备插件的配置。
  • 为 SR-IOV CNI 插件生成 NetworkAttachmentDefinition 自定义资源 (CR) 。

以上提到的 SR-IOV 组件的功能。

  • SR-IOV 网络设备插件是一个 Kubernetes 设备插件,用于发现、公告和分配 SR-IOV 网络虚拟功能 (VF) 资源。在 Kubernetes 中使用设备插件能够利用有限的资源,这些资源通常为于物理设备中。设备插件可以使 Kubernetes 调度程序了解资源可用性,因此调度程序可以在具有足够资源的节点上调度 Pod。
  • SR-IOV CNI 插件探测从 SR-IOV 设备插件中直接分配给 Pod 的 VF 接口。
  • Network Resources Injector 是一个 Kubernetes Dynamic Admission Controller Webhook,它提供通过请求和限制为自定义网络资源(如 SR-IOV VF)应用 Kubernetes Pod 规格的功能。
注意

Network Resources Injector 会被默认启用且无法禁用。

7.8.1.1. 支持的设备

OpenShift Container Platform 支持以下网络接口卡 (NIC):

  • Intel XXV710-DA2 25G 卡,厂商 ID 0x8086,设备 ID 0x158b
  • Mellanox MT27710 系列 [ConnectX-4 Lx] 25G 卡,厂商 ID 0x15b3,设备 ID 0x1015
  • Mellanox MT27800 系列 [ConnectX-5] 100G 卡,厂商 ID 0x15b3,设备 ID 0x1017

7.8.1.2. 自动发现 SR-IOV 网络设备

SR-IOV Network Operator 将搜索集群以获取 worker 节点上的 SR-IOV 功能网络设备。Operator 会为每个提供兼容 SR-IOV 网络设备的 worker 节点创建并更新一个 SriovNetworkNodeState 自定义资源 (CR) 。

每个 worker 节点都会创建了一个 CR,并共享与该节点相同的名称。.spec.interfaces 列表提供有关节点上网络设备的信息。

重要

不要修改 SriovNetworkNodeState CR。Operator 会自动创建和管理这些资源。

以下是由 SR-IOV Network Operator 创建的 SriovNetworkNodeState CR 示例:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 1
  namespace: sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: d41d8cd98f00b204e9800998ecf8427e
status:
  interfaces: 2
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded
1
name 参数的值与 worker 节点的名称相同。
2
interfaces 集合包括 Operator 在 worker 节点上 发现的所有 SR-IOV 设备列表。

7.8.1.3. 在 Pod 中使用虚拟功能 (VF) 的示例

您可以在附加了 SR-IOV VF 的 Pod 中运行远程直接内存访问 (RDMA) 或 Data Plane Development Kit (DPDK) 应用程序。在以下示例中,Pod 在 RDMA 模式中使用 VF:

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>
    imagePullPolicy: IfNotPresent
    securityContext:
     capabilities:
        add: ["IPC_LOCK"]
    command: ["sleep", "infinity"]

以下示例演示了在 DPDK 模式中使用 VF 的 Pod:

apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-dpdk-net
spec:
  containers:
  - name: testpmd
    image: <DPDK_image>
    securityContext:
     capabilities:
        add: ["IPC_LOCK"]
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
      requests:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

7.8.2. 安装 SR-IOV Network Operator

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

7.8.2.1. 使用 CLI 安装 Operator

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

先决条件

  • 在裸机环境中安装的集群,其中的节点带有支持 SR-IOV 的硬件。
  • OpenShift Container Platform 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 通过完成以下操作,为 SR-IOV Network Operator 创建命名空间:

    1. 创建用来定义 sriov-network-operator 命名空间的以下 Namespace 自定义资源 (CR) ,然后在 sriov-namespace.yaml 文件中保存这些 YAML 数据:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: sriov-network-operator
        labels:
          openshift.io/run-level: "1"
    2. 运行以下命令创建命名空间:

      $ oc create -f sriov-namespace.yaml
  2. 通过创建以下对象,在您上一步创建的命名空间中安装 SR-IOV Network Operator:

    1. 创建以下 OperatorGroup CR,并在 sriov-operatorgroup.yaml 文件中保存 YAML:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: sriov-network-operators
        namespace: sriov-network-operator
      spec:
        targetNamespaces:
        - sriov-network-operator
    2. 通过运行以下命令来创建 OperatorGroup CR:

      $ oc create -f sriov-operatorgroup.yaml
    3. 运行以下命令获取下一步所需的 channel 值。

      $ oc get packagemanifest sriov-network-operator -n openshift-marketplace -o jsonpath='{.status.defaultChannel}'
      
      4.2
    4. 创建以下订阅 CR,并将 YAML 保存到 sriov-sub.yaml 文件中:

      订阅示例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: sriov-network-operator-subscription
        namespace: sriov-network-operator
      spec:
        channel: <channel> 1
        name: sriov-network-operator
        source: redhat-operators 2
        sourceNamespace: openshift-marketplace

      1
      使用在前一步中获得的值指定 .status.defaultChannel 参数。
      2
      您必须指定 redhat-operators 值。
    5. 运行以下命令创建订阅对象:

      $ oc create -f sriov-sub.yaml
    6. 进入 sriov-network-operator 项目:

      $ oc project sriov-network-operator
      
      Now using project "sriov-network-operator"

7.8.2.2. 使用 Web 控制台安装 Operator

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

注意

如上一节所述,您必须创建命名空间 CR 和 OperatorGroup CR。

流程

  1. 使用 OpenShift Container Platform Web 控制台安装 SR-IOV Network Operator:

    1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
    2. 从可用的 Operators 列表中选择 SR-IOV Network Operator,然后点 Install
    3. Create Operator Subscription 页面中,在集群的一个特定的命名空间中 选择sriov-network-operator。然后,点击 Subscribe
  2. 可选:验证 SR-IOV Network Operator 是否已成功安装:

    1. 切换到 OperatorsInstalled Operators 页面。
    2. 确保 SR-IOV Network Operatorsriov-network-operator 项目中列出,状态InstallSucceeded

      注意

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

      如果 Operator 没有被成功安装,请按照以下步骤进行故障排除:

      • 进入 Operators → Installed Operators 页面,检查 Operator SubscriptionsInstall Plans 选项卡中的 Status 项中是否有任何错误。
      • 进入 WorkloadsPods 页面,在 sriov-network-operator 项目中检查 Pod 的日志。

7.8.3. 配置 SR-IOV 网络设备

SR-IOV Network Operator 把 SriovNetworkNodePolicy.sriovnetwork.openshift.io 自定义资源定义 (CRD) 添加到 OpenShift Container Platform。您可以通过创建一个 SriovNetworkNodePolicy 自定义资源 (CR) 来配置 SR-IOV 网络设备。

注意

当应用由 SriovNetworkNodePolicy CR 指定的配置时,SR-IOV Operator 可能会排空节点,并在某些情况下会重启节点。它可能需要几分钟时间来应用配置更改。确保集群中有足够的可用节点,用以预先处理被驱除的工作负载。

在应用了配置更新后,sriov-network-operator 命名空间中的所有 Pod 都将变为 Running 状态。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。
  • 您必须已安装了 SR-IOV Operator。

流程

  1. 创建以下 SriovNetworkNodePolicy CR,然后在 <name>-sriov-node-network.yaml 文件中保存 YAML。使用配置的实际名称替换 <name>

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: <name> 1
      namespace: sriov-network-operator 2
    spec:
      resourceName: <sriov_resource_name> 3
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true" 4
      priority: <priority> 5
      mtu: <mtu> 6
      numVfs: <num> 7
      nicSelector: 8
        vendor: "<vendor_code>" 9
        deviceID: "<device_id>" 10
        pfNames: ["<pf_name>", ...] 11
        rootDevices: ["<pci_bus_id>", "..."] 12
      deviceType: <device_type> 13
      isRdma: false 14
    1
    为 CR 指定一个名称。
    2
    指定 SR-IOV Operator 安装到的命名空间。
    3
    指定 SR-IOV 设备插件的资源名称。如果 Pod spec 中引用了,则会添加 openshift.io/ 前缀。您可以为一个资源名称创建多个 SriovNetworkNodePolicy CR。
    4
    指定节点选择器来选择要配置哪些节点。用户可以选择手动标记节点,也可以使用 Kubernetes Node Feature Discovery 等工具进行。只有所选节点上的 SR-IOV 网络设备才会被配置。SR-IOV CNI 插件和设备插件只能部署到所选节点上。
    5
    指定一个 099 之间的整数。大数值的优先级较低,因此优先级 99 低于优先级 10
    6
    为虚拟功能(VF)的最大传输单位 (MTU) 指定一个值。MTU 的值必须是在 19000 之间。如果您不需要指定 MTU,请指定一个 " 值。
    7
    为 SR-IOV 物理网络设备指定要创建的虚拟功能 (VF) 的数量。对于 Intel 网络接口卡 (NIC) ,VF 的数量不能超过该设备支持的 VF 总数。对于 Mellanox NIC,VF 的数量不能超过 128
    8
    nicSelector 映射为 Operator 选择要配置的以太网设备。您不需要为所有参数指定值。建议您以足够的准确度来识别以太网适配器,以便尽量减小意外选择其他以太网设备的可能性。如果指定了rootDevices,则必须同时为 vendordeviceIDpfNames 指定一个值。如果同时指定了 pfNamesrootDevices,请确保它们指向同一个设备。
    9
    指定 SR-IOV 网络设备的厂商十六进制代码。允许的值只能是 808615b3
    10
    指定 SR-IOV 网络设备的设备十六进制代码。允许的值只能是 158b10151017
    11
    参数接受包括以太网设备的一个或多个物理功能 (PF) 的数组。
    12
    参数接受一个包括一个或多个 PCI 总线地址,用于以太网设备的物理功能的数组。使用以下格式提供地址: 0000:02:00.1
    13
    指定虚拟功能的驱动程序类型。您可以指定以下值之一:netdevicevfio-pci。默认值为 netdevice
    14
    指定是否启用 RDMA 模式。默认值为 false。在 Mellanox 以太网适配器中只支持 RDMA over Converged Ethernet (RoCE) 模式。
    注意

    如果将 RDMA 标记设定为 true,您可以继续使用启用了 RDMA 的 VF 作为普通网络设备。设备可在其中的一个模式中使用。

  2. 运行以下命令来创建 CR:

    $ oc create -f <filename> 1
    1
    <filename> 替换为您在上一步中创建的文件的名称。

7.8.4. 配置 SR-IOV 额外网络

您可以通过创建一个 SriovNetwork 自定义资源 (CR) 来配置使用 SR-IOV 硬件的额外网络。当创建 SriovNetwork CR 时,SR-IOV Operator 会自动创建一个 NetworkAttachmentDefinition CR。

注意

如果一个 SriovNetwork 自定义资源 (CR) 已被附件到状态为 running 的 Pod 后,则不能修改或删除它。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 创建以下 SriovNetwork CR,然后在 <name>-sriov-network.yaml 文件中保存 YAML。用这个额外网络的名称替换 <name>

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: <name> 1
      namespace: sriov-network-operator 2
    spec:
      networkNamespace: <target_namespace> 3
      ipam: |- 4
        ...
      vlan: <vlan> 5
      resourceName: <sriov_resource_name> 6
    1
    <name> 替换为 CR 的名称。Operator 将创建一个具有相同名称的 NetworkAttachmentDefinition CR。
    2
    指定 SR-IOV Operator 安装到的命名空间。
    3
    <target_namespace> 替换为创建 NetworkAttachmentDefinition CR 的命名空间。
    4
    为 ipam CNI 插件指定一个配置对象做为一个 YAML 块 scalar。该插件管理网络附加定义的 IP 地址分配。
    5
    使用额外网络的虚拟 LAN (VLAN) ID 替换 <vlan>。它需要是一个从 04095 范围内的一个整数值。默认值为 0
    6
    <sriov_resource_name> 替换为来自用于为这个额外网络定义 SR-IOV 硬件的 SriovNetworkNodePolicy CR 的 .spec.resourceName 参数的值。
  2. 运行以下命令来创建 CR:

    $ oc create -f <filename> 1
    1
    <filename> 替换为您在上一步中创建的文件的名称。
  3. 可选:通过运行以下命令,确认与在上一步中创建的 SriovNetwork CR 关联的 NetworkAttachmentDefinition CR 是否存在。将 <namespace> 替换为您在 SriovNetwork CR 中指定的命名空间。

    oc get net-attach-def -n <namespace>

7.8.4.1. 配置 ipam CNI 插件

IP 地址管理 (IPAM) CNI 插件为其他 CNI 插件管理 IP 地址分配。您可以配置 ipam 以进行静态 IP 地址分配或使用 DHCP 进行动态 IP 地址分配。您指定的 DHCP 服务器必须可从额外网络访问。

重要

在 OpenShift Container Platform 4.2.0 中,如果您将 Pod 附加到使用 DHCP 进行 IP 地址管理的额外网络中,则 Pod 将无法启动。OpenShift Container Platform 4.2.1 已修复了这个问题。如需更多信息,请参阅 BZ#1754686

以下 JSON 配置对象描述了您可以设置的参数。

重要

如果您将 type 参数设置为 DHCP 值,则无法设置任何其他参数。

ipam CNI 插件 JSON 配置对象

{
  "ipam": {
    "type": "<type>", 1
    "addresses": [ 2
      {
        "address": "<address>", 3
        "gateway": "<gateway>" 4
      }
    ],
    "routes": [ 5
      {
        "dst": "<dst>" 6
        "gw": "<gw>" 7
      }
    ],
    "dns": { 8
      "nameservers": ["<nameserver>"], 9
      "domain": "<domain>", 10
      "search": ["<search_domain>"] 11
    }
  }
}

1
指定 static,以配置插件来管理 IP 地址分配。指定 DHCP,以允许 DHCP 服务器管理 IP 地址分配。如果指定了 DHCP 值,则无法指定任何其他参数。
2
定义分配给虚拟接口的 IP 地址的数组。支持 IPv4 和 IPv6 IP 地址。
3
您以 CIDR 格式指定的分配给 worker 节点上 Pod 的 IP 地址块,如 10.1.1.0/24
4
出口网络流量要路由到的默认网关。
5
描述要在 Pod 中配置的路由的数组。
6
CIDR 格式的 IP 地址范围。
7
用于将网络流量路由到的网关。
8
DNS 配置。可选。
9
用来发送 DNS 查询的一个或多个 IP 地址的数组。
10
附加到主机名的默认域。例如,如果将域设置为 example.com,对 example-host 的 DNS 查找查询将被改写为 example-host.example.com
11
在 DNS 查找查询过程中,附加到非限定主机名(如 example-host)的域名的数组。
7.8.4.1.1. 静态 IP 地址分配配置示例

您可以配置 ipam 以进行静态 IP 地址分配:

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.1/24"
        }
      ]
  }
}
7.8.4.1.2. 动态 IP 地址分配配置示例

您可以配置 ipam 以使用 DHCP:

{
  "ipam": {
    "type": "DHCP"
  }
}

7.8.5. 将 Pod 添加到额外网络

您可以将 Pod 添加到额外网络。Pod 继续通过默认网络发送与集群相关的普通网络流量。

注意

如果指定了与 SR-IOV CNI 插件关联的 NetworkAttachmentDefinition CR,则 Network Resources Injector 会自动将 resource 参数注入 Pod CR。

先决条件

  • Pod 必须与额外网络处于相同的命名空间。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须登录集群。
  • 您必须安装了 SR-IOV Operator ,并定义了 SriovNetwork CR。

流程

要添加带有额外网络的 Pod,请完成以下步骤:

  1. 在 Pod 资源定义中,将 k8s.v1.cni.cncf.io/networks 参数添加到 Pod metadata 映射中。k8s.v1.cni.cncf.io/networks 接受由一个或多个 NetworkAttachmentDefinition 自定义资源 (CR) 名称组成并用逗号分隔的字符串:

    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
    1
    <network> 替换为要与 Pod 关联的额外网络的名称。要指定多个额外网络,请使用逗号分隔各个网络。逗号之间不可包括空格。如果您多次指定同一额外网络,则 Pod 会将多个网络接口附加到该网络。

    在以下示例中,两个额外网络附加到 Pod:

    apiVersion: v1
    kind: Pod
    metadata:
      name: example-pod
      annotations:
        k8s.v1.cni.cncf.io/networks: net1,net2
    spec:
      containers:
      - name: example-pod
        command: ["/bin/bash", "-c", "sleep 2000000000000"]
        image: centos/tools
  2. 运行以下命令来创建 Pod:

    $ oc create -f pod.yaml
  3. 可选:通过运行以下命令,确认 Pod CR 中是否存在注解。将 <name> 替换为 Pod 的名称。

    $ oc get pod <name> -o yaml

    在以下示例中,example-pod Pod 附加到 net1 额外网络:

    $ oc get pod example-pod -o yaml
    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: macvlan-bridge
        k8s.v1.cni.cncf.io/networks-status: |- 1
          [{
              "name": "openshift-sdn",
              "interface": "eth0",
              "ips": [
                  "10.128.2.14"
              ],
              "default": true,
              "dns": {}
          },{
              "name": "macvlan-bridge",
              "interface": "net1",
              "ips": [
                  "20.2.2.100"
              ],
              "mac": "22:2f:60:a5:f8:00",
              "dns": {}
          }]
      name: example-pod
      namespace: default
    spec:
      ...
    status:
      ...
    1
    k8s.v1.cni.cncf.io/networks-status 参数是对象的 JSON 数组。每个对象描述附加到 Pod 的额外网络的状态。注解值保存为纯文本值。

7.9. 编辑额外网络

作为集群管理员,您可以修改现有额外网络的配置。

7.9.1. 修改额外网络附加定义

作为集群管理员,您可以对现有额外网络进行更改。任何已附加到额外网络的现有 Pod 都不会被更新。

先决条件

  • 已为集群配置了额外网络。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

要为集群编辑额外网络,请完成以下步骤:

  1. 运行以下命令,在默认文本编辑器中编辑 Cluster Network Operator (CNO) CR:

    $ oc edit networks.operator.openshift.io cluster
  2. additionalNetworks 集合中,用您的更改更新额外网络。
  3. 保存您的更改,再退出文本编辑器以提交更改。
  4. 可选:通过运行以下命令确认 CNO 更新了 NetworkAttachmentDefinition CR。将 <network-name> 替换为要显示的额外网络名称。在 CNO 根据您的更改对 NetworkAttachmentDefinition CR 进行更新前,可能会有一些延迟。

    $ oc get network-attachment-definitions <network-name> -o yaml

    例如,以下控制台输出显示名为 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"]}} }

7.10. 删除额外网络

作为集群管理员,您可以删除额外网络附加。

7.10.1. 删除额外网络附加定义

作为集群管理员,您可以从 OpenShift Container Platform 集群中删除额外网络。额外网络不会从它所附加的 Pod 中删除。

重要

在 OpenShift Container Platform 4.2.0 中,从 Cluster Network Operator 配置中将其删除后,您必须手动删除额外网络 CR。以后的发行版本中会修复此问题。如需更多信息,请参阅 BZ#1755908

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 以具有 cluster-admin 特权的用户身份登录。

流程

要从集群中删除额外网络,请完成以下步骤:

  1. 运行以下命令,在默认文本编辑器中编辑 Cluster Network Operator (CNO):

    $ oc edit networks.operator.openshift.io cluster
  2. 从您要删除的网络附加定义的 additionalNetworks 集合中删除配置,以此修改 CR。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: [] 1
    1
    如果要删除 additionalNetworks 集合中唯一额外网络附加定义的配置映射,您必须指定一个空集合。
  3. 保存您的更改,再退出文本编辑器以提交更改。
  4. 运行以下命令,删除额外网络的 NetworkAttachmentDefinition CR。将 <name> 替换为要删除的额外网络名称。

    $ oc delete network-attachment-definition <name>
  5. 可选:通过运行以下命令确认删除了额外网络 CR:

    $ oc get network-attachment-definition --all-namespaces

第 8 章 OpenShift SDN

8.1. 关于 OpenShift SDN

OpenShift Container Platform 使用软件定义网络 (SDN) 方法来提供一个统一的集群网络,它允许 OpenShift Container Platform 集群中的不同 Pod 相互间进行通信。此 Pod 网络是由 OpenShift SDN 建立和维护的,它使用 Open vSwitch (OVS) 配置覆盖网络。

OpenShift SDN 提供三种 SDN 模式来配置 Pod 网络:

  • 网络策略模式允许项目管理员使用 NetworkPolicy 对象配置其自身的隔离策略。NetworkPolicy 是 OpenShift Container Platform 4.2 的默认模式。
  • 多租户模式为 Pod 和服务提供项目级别的隔离。来自不同项目的 Pod 不能与不同项目的 Pod 和服务互相发送或接收数据包。您可以针对项目禁用隔离,允许它将网络流量发送到整个集群中的所有 Pod 和服务,并从那些 Pod 和服务接收网络流量。
  • 子网模式提供一个扁平 Pod 网络,每个 Pod 都可以与所有其他 Pod 和服务通信。网络策略模式提供与子网模式相同的功能。

8.2. 为项目配置出口 IP

作为集群管理员,您可以配置 OpenShift SDN 网络供应商,为项目分配一个或多个出口 IP 地址。

8.2.1. 项目出口流量的出口 IP 地址分配

通过为项目配置出口 IP 地址,来自指定项目的所有出站外部连接将共享相同的固定源 IP 地址。外部资源可以根据出口 IP 地址识别来自特定项目的流量。分配给项目的出口 IP 地址与用来向特定目的地发送流量的出口路由器不同。

出口 IP 地址是作为额外 IP 地址在节点的主网络接口中实现的,且必须与节点的主 IP 地址处于同一个子网中。

重要

不能在任何 Linux 网络配置文件中配置出口 IP 地址,比如 ifcfg-eth0

在主网络接口上允许额外 IP 地址可能需要在使用某些云或虚拟机解决方案时进行额外的配置。

您可以通过设置 NetNamespace 资源的 egressIPs 参数,将出口 IP 地址分配给命名空间。在出口 IP 与项目关联后,OpenShift SDN 允许您以两种方式为主机分配出口 IP:

  • 自动分配方法中,给节点分配一个出口 IP 地址范围。
  • 手动分配方法中,给节点分配包含一个或多个出口 IP 地址的列表。

请求出口 IP 地址的命名空间与可以托管那些出口 IP 地址的节点匹配,然后为那些节点分配出口 IP 地址。如果在 NetNamespace 资源中设置了 egressIPs 参数,但没有节点托管该出口 IP 地址,则会丢弃来自该命名空间的出口流量。

节点高可用性是自动的。如果托管出口 IP 地址的节点不可访问,并且有可以托管那些出口 IP 地址的节点,那么出口 IP 地址将会移到新节点。当无法访问的托管原始出口 IP 地址的节点恢复正常后,出口 IP 地址会自动转移,以在不同节点之间均衡出口 IP 地址。

重要

您不能在同一节点上同时使用手动分配和自动分配的出口 IP 地址。如果手动从 IP 地址范围分配出口 IP 地址,则不得将该范围用于自动 IP 分配。

8.2.1.1. 使用自动分配的出口 IP 地址时的注意事项

当对出口 IP 地址使用自动分配方法时,请注意以下事项:

  • 您可以设置每个节点的 HostSubnet 资源的 egressCIDRs 参数,以指明节点可以托管的出口 IP 地址范围。OpenShift Container Platform 根据您指定的 IP 地址范围设置 HostSubnet 资源的 egressIPs 参数。
  • 使用自动分配模式时,支持每个命名空间具有一个出口 IP 地址。

如果托管命名空间的出口 IP 地址的节点不可访问,OpenShift Container Platform 会将出口 IP 地址重新分配给具有兼容出口 IP 地址范围的另外一个节点。自动分配方法最适合在把额外的 IP 地址与节点进行关联时具有灵活性的环境中安装的集群。

8.2.1.2. 使用手动分配出口 IP 地址时的注意事项

当手动分配出口 IP 地址时,请考虑以下事项:

  • 您可以设置每个节点的 HostSubnet 资源的 egressIPs 参数,以指明节点可以托管的 IP 地址。
  • 支持一个命名空间带有多个出口 IP 地址。

当命名空间有多个出口 IP 地址时,如果托管第一个出口 IP 地址的节点不可访问,OpenShift Container Platform 将自动切换到使用下一个可用的出口 IP 地址,直到可以再次访问第一个出口 IP 地址。

建议在公共云环境中(可能有将额外 IP 地址与节点关联的限制)安装的集群使用这个方法。

8.2.2. 为一个命名空间启用自动分配出口 IP 地址

在 OpenShift Container Platform 中,可以为一个或多个节点上的特定命名空间启用自动分配出口 IP 地址。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 使用以下 JSON,用出口 IP 地址更新 NetNamespace 资源:

     $ oc patch netnamespace <project_name> --type=merge -p \ 1
      '{
        "egressIPs": [
          "<ip_address>" 2
        ]
      }'
    1
    指定项目的名称。
    2
    指定单个出口 IP 地址。不支持使用多 IP 地址。

    例如,将 project1 分配给 IP 地址 192.168.1.100,将 project2 分配给 IP 地址 192.168.1.101:

    $ oc patch netnamespace project1 --type=merge -p \
      '{"egressIPs": ["192.168.1.100"]}'
    $ oc patch netnamespace project2 --type=merge -p \
      '{"egressIPs": ["192.168.1.101"]}'
  2. 使用以下 JSON 设置每一主机的 egressCIDRs 参数,以指明哪些节点可以托管出口 IP 地址:

    $ oc patch hostsubnet <node_name> --type=merge -p \ 1
      '{
        "egressCIDRs": [
          "<ip_address_range_1>", "<ip_address_range_2>" 2
        ]
      }'
    1
    指定节点名称。
    2
    以 CIDR 格式指定一个或多个 IP 地址范围。

    例如,将 node1node2 设置为托管范围为 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"]}'

    OpenShift Container Platform 会自动以均衡的方式将特定的出口 IP 地址分配给可用的节点。在本例中,它会将出口 IP 地址 192.168.1.100 分配给 node1,并将出口 IP 地址 192.168.1.101 分配给 node2,或反之。

8.2.3. 为一个命名空间配置手动分配出口 IP 地址

在 OpenShift Container Platform 中,您可以将一个或多个出口 IP 与一个项目关联。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 通过使用所需 IP 地址指定以下 JSON 对象,更新 NetNamespace 资源:

    $ oc patch netnamespace <project> --type=merge -p \ 1
      '{
        "egressIPs": [ 2
          "<ip_address>"
          ]
      }'
    1
    指定项目的名称。
    2
    指定一个或多个出口 IP 地址。egressIPs 参数是一个数组。

    例如,将 project1 项目分配给 IP 地址 192.168.1.100

    $ oc patch netnamespace project1 --type=merge \
      -p '{"egressIPs": ["192.168.1.100"]}'

    您可以将 egressIPs 设置为位于不同节点上的两个或多个 IP 地址,以提供高可用性。如果设置了多个出口 IP 地址,Pod 会将列表中的第一个 IP 用于出口,但如果托管该 IP 地址的节点失败,Pod 会在短暂的延迟后切换到使用列表中的下一个 IP。

  2. 手动将出口 IP 分配给节点主机。在节点主机上的 HostSubnet 对象中设置 egressIPs 参数。使用以下 JSON,尽可能纳入您要分配给该节点主机的所有 IP:

    $ oc patch hostsubnet <node_name> --type=merge -p \ 1
      '{
        "egressIPs": [ 2
          "<ip_address_1>",
          "<ip_address_N>"
          ]
      }'
    1
    指定项目的名称。
    2
    指定一个或多个出口 IP 地址。egressIPs 字段是一个数组。

    例如,指定 node1 应具有出口 IP 192.168.1.100192.168.1.101192.168.1.102

    $ oc patch hostsubnet node1 --type=merge -p \
      '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'

    在上例中,project1 的所有出口流量都会被路由到托管指定出口 IP 地址的节点,然后(使用 NAT)连接到那个 IP 地址。

8.3. 配置出口防火墙来控制对外部 IP 地址的访问

作为集群管理员,您可以为项目创建一个出口防火墙,用于限制离开 OpenShift Container Platform 集群的出口流量。

8.3.1. 出口防火墙在一个项目中的工作原理

做为一个集群的系统管理员,您可以使用一个出口防火墙(egress firewall)来限制集群内的所有或部分 Pods 可以访问的外部主机。出口防火墙适用于以下情况:

  • Pod 只能连接到内部主机,且无法启动到公共互联网的连接。
  • Pod 只能连接到公共互联网,且无法启动到 OpenShift Container Platform 集群以外的内部主机的连接。
  • Pod 无法访问 OpenShift Container Platform 集群外的特定内部子网或主机。
  • Pod 只能连接到特定的外部主机。

您可以通过创建一个 EgressNetworkPolicy 自定义资源 (CR) 对象并指定 CIDR 格式的 IP 地址范围或指定 DNS 名称来配置出口防火墙策略。例如,您可以允许某一个项目访问指定的 IP 范围,但拒绝其他项目对同一 IP 范围的访问。或者您可以限制应用程序开发人员从 Python pip 的镜像点进行更新,并强制要求更新只能来自于批准的源。

重要

您必须将 OpenShift SDN 配置为使用网络策略或多租户模式来配置出口防火墙策略。

如果使用网络策略模式,egress 策略只与每个命名空间的一个策略兼容,且无法在需要共享网络的项目中使用,如全局项目。

小心

出口防火墙规则不适用于通过路由器的网络流量。任何有权创建 Route CR 对象的用户,都可以通过创建指向禁止访问的目的地的路由,来绕过出口网络策略规则。

8.3.1.1. 出口防火墙的限制

出口防火墙有以下限制:

  • 项目不能有多个 EgressNetworkPolicy 对象。
  • default 项目无法使用出口网络策略。
  • 当在多租户模式下使用 OpenShift SDN 网络供应商时,会有以下限制:

    • 全局项目无法使用出口防火墙。您可以使用 oc adm pod-network make-projects-global 把一个项目设置为全局项目。
    • 通过 oc adm pod-network join-projects 命令合并的项目,无法在任何合并的项目中使用出口防火墙。

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

8.3.1.2. 出口网络策略规则的匹配顺序

egress 网络策略规则是按照它们定义的顺序来评估的,从第一个到最后一个的顺序。第一个与 Pod 的出口连接匹配的规则会被应用。该连接会忽略后续的所有规则。

8.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 中使用域名。

8.3.2. EgressNetworkPolicy 自定义资源 (CR) 对象

以下 YAML 描述了一个 EgressNetworkPolicy CR 对象:

kind: EgressNetworkPolicy
apiVersion: v1
metadata:
  name: <name> 1
spec:
  egress: 2
    ...
1
为出口防火墙指定一个名称
2
如下小节所述,指定一个或多个出口网络策略规则的集合。

8.3.2.1. EgressNetworkPolicy 规则

以下 YAML 描述了一个出口防火墙规则对象。egress 键需要一个包括一个或多个对象的数组。

egress:
- type: <type> 1
  to: 2
    cidrSelector: <cidr> 3
    dnsName: <dns-name> 4
1
指定规则类型。该值必须是 AllowDeny
2
为规则指定一个 cidrSelectordnsName 的值。您不能在规则中同时使用这两个键。
3
以 CIDR 格式指定一个 IP 地址范围。
4
指定一个域名。

8.3.2.2. EgressNetworkPolicy CR 对象示例

以下示例定义了几个出口防火墙策略规则:

kind: EgressNetworkPolicy
apiVersion: v1
metadata:
  name: default-rules 1
spec:
  egress: 2
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Allow
    to:
      dnsName: www.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
1
策略对象的名称。
2
出口防火墙策略规则对象的集合。

8.3.3. 创建出口防火墙策略对象

作为集群管理员,您可以为项目创建一个出口防火墙策略对象。

重要

如果项目已经定义了一个 EgressNetworkPolicy 对象,您必须编辑现有的策略来更改出口防火墙规则。

先决条件

  • 使用 OpenShift SDN 网络供应商插件的集群。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您需要使用集群管理员身份登陆到集群。

流程

  1. 创建策略规则:

    1. 创建一个 <policy-name>.yaml 文件,其中 <policy-name> 描述出口策略规则。
    2. 在您创建的文件中,定义出口策略对象。
  2. 运行以下命令来创建策略对象:

    $ oc create -f <policy-name>.yaml -n <project>

    在以下示例中,在名为 project1 的项目中创建一个新的 EgressNetworkPolicy 对象:

    $ oc create -f default-rules.yaml -n project1
    egressnetworkpolicy.network.openshift.io/default-rules created
  3. 可选:保存 <policy-name>.yaml ,以便在以后进行修改。

8.4. 为项目编辑出口防火墙

作为集群管理员,您可以修改现有出口防火墙的网络流量规则。

8.4.1. 编辑 EgressNetworkPolicy 对象

作为集群管理员,您可以更新一个项目的出口防火墙。

先决条件

  • 使用 OpenShift SDN 网络插件的集群。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您需要使用集群管理员身份登陆到集群。

流程

要编辑项目的现有出口网络策略对象,请完成以下步骤:

  1. 查找项目的 EgressNetworkPolicy 对象的名称。将 <project> 替换为项目的名称。

    $ oc get -n <project> egressnetworkpolicy
  2. 可选,如果您在创建出口网络防火墙时没有保存 EgressNetworkPolicy 对象的副本,请输入以下命令来创建副本。

    $ oc get -n <project> \ 1
      egressnetworkpolicy <name> \ 2
      -o yaml > <filename>.yaml 3
    1
    <project> 替换为项目的名称
    2
    <name> 替换为 Pod 的名称。
    3
    <filename> 替换为要保存 YAML 的文件名称。
  3. 输入以下命令替换 EgressNetworkPolicy 对象。将 <filename> 替换为包含更新的 EgressNetworkPolicy 对象的文件名称。

    $ oc replace -f <filename>.yaml

8.4.2. EgressNetworkPolicy 自定义资源 (CR) 对象

以下 YAML 描述了一个 EgressNetworkPolicy CR 对象:

kind: EgressNetworkPolicy
apiVersion: v1
metadata:
  name: <name> 1
spec:
  egress: 2
    ...
1
为出口防火墙指定一个名称
2
如下小节所述,指定一个或多个出口网络策略规则的集合。

8.4.2.1. EgressNetworkPolicy 规则

以下 YAML 描述了一个出口防火墙规则对象。egress 键需要一个包括一个或多个对象的数组。

egress:
- type: <type> 1
  to: 2
    cidrSelector: <cidr> 3
    dnsName: <dns-name> 4
1
指定规则类型。该值必须是 AllowDeny
2
为规则指定一个 cidrSelectordnsName 的值。您不能在规则中同时使用这两个键。
3
以 CIDR 格式指定一个 IP 地址范围。
4
指定一个域名。

8.4.2.2. EgressNetworkPolicy CR 对象示例

以下示例定义了几个出口防火墙策略规则:

kind: EgressNetworkPolicy
apiVersion: v1
metadata:
  name: default-rules 1
spec:
  egress: 2
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Allow
    to:
      dnsName: www.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
1
策略对象的名称。
2
出口防火墙策略规则对象的集合。

8.5. 从项目中删除出口防火墙

作为集群管理员,您可以从项目中删除出口防火墙,从而删除对项目的离开 OpenShift Container Platform 集群的网络流量的限制。

8.5.1. 删除 EgressNetworkPolicy 对象

作为集群管理员,您可以从项目中删除出口防火墙。

先决条件

  • 使用 OpenShift SDN 网络插件的集群。
  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您需要使用集群管理员身份登陆到集群。

流程

要为项目删除出口网络策略对象,请完成以下步骤:

  1. 查找项目的 EgressNetworkPolicy 对象的名称。将 <project> 替换为项目的名称。

    $ oc get -n <project> egressnetworkpolicy
  2. 输入以下命令删除 EgressNetworkPolicy 对象。将 <project> 替换为项目名称,<name> 替换为对象名称。

    $ oc delete -n <project> egressnetworkpolicy <name>

8.6. 使用多播

8.6.1. 关于多播

通过使用 IP 多播,数据可同时广播到许多 IP 地址。

重要

目前,多播最适用于低带宽协调或服务发现。它不是一个高带宽解决方案。

默认情况下,OpenShift Container Platform Pod 之间多播流量被禁用。如果使用 OpenShift SDN 网络插件,可以根据每个项目启用多播。

networkpolicy 隔离模式使用 OpenShift SDN 网络插件时:

  • Pod 发送的多播数据包将传送到项目里的所有其他 Pod,而无需考虑 NetworkPolicy 对象。即使在无法通过单播通信时,Pod 也能通过多播进行通信。
  • 一个项目中的 Pod 发送的多播数据包不会传送到任何其他项目中的 Pod,即使存在允许项目间通信的 NetworkPolicy 对象。

multitenant 隔离模式使用 OpenShift SDN 网络插件时:

  • Pod 发送的多播数据包将传送到项目里的所有其他 Pod。
  • 只有在各个项目接合在一起并且每个接合的项目上都启用了多播时,一个项目中的 Pod 发送的多播数据包才会传送到其他项目中的 Pod。

8.6.2. 启用 Pod 间多播

您可以为项目启用 Pod 间多播。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须作为 cluster-admin 角色用户登录集群。

流程

  • 运行以下命令,为项目启用多播:

    $ oc annotate netnamespace <namespace> \ 1
        netnamespace.network.openshift.io/multicast-enabled=true
    1
    您要启用多播的项目的 namespace

8.6.3. 禁用 Pod 间多播

您可以为项目禁用 Pod 间多播。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须作为 cluster-admin 角色用户登录集群。

流程

  • 运行以下命令来禁用多播:

    $ oc annotate netnamespace <namespace> \ 1
        netnamespace.network.openshift.io/multicast-enabled-
    1
    您要禁用多播的项目的 namespace

8.7. 使用 OpenShift SDN 配置网络隔离

将集群配置为使用 OpenShift SDN CNI 插件的多租户隔离模式时,每个项目会被默认隔离。在多租户隔离模式下,不同项目中的 Pod 或服务间不允许网络流量。

您可以通过两种方式更改项目的多租户隔离行为:

  • 您可以接合一个或多个项目,允许不同项目中的 Pod 和服务间的网络流量。
  • 您可以对项目禁用网络隔离。它可全局访问,接受所有其他项目中的 Pod 和服务的网络流量。可全局访问的项目可以访问所有其他项目中的 Pod 和服务。

先决条件

  • 您必须将集群配置为以多租户隔离模式使用 OpenShift SDN Container Network Interface (CNI) 插件。

8.7.1. 接合项目

您可以接合两个或多个项目来允许不同项目中的 Pod 和服务间的网络流量。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须作为 cluster-admin 角色用户登录集群。

流程

  1. 使用以下命令,将项目接合到现有项目网络中:

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

    另外,除了指定具体的项目名称,也可以使用 --selector=<project_selector> 选项来基于关联标签指定项目。

  2. 可选:运行以下命令来查看您接合在一起的 Pod 网络:

    $ oc get netnamespaces

    NETID 列中,同一 Pod 网络中的项目具有相同的网络 ID。

8.7.2. 隔离项目

您可以隔离项目,使其他项目中的 Pod 和服务无法访问这个项目中的 Pod 和服务。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须作为 cluster-admin 角色用户登录集群。

流程

  • 要隔离集群中的项目,请运行以下命令:

    $ oc adm pod-network isolate-projects <project1> <project2>

    另外,除了指定具体的项目名称,也可以使用 --selector=<project_selector> 选项来基于关联标签指定项目。

8.7.3. 对项目禁用网络隔离

您可以对项目禁用网络隔离。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 您必须作为 cluster-admin 角色用户登录集群。

流程

  • 对项目运行以下命令:

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

    另外,除了指定具体的项目名称,也可以使用 --selector=<project_selector> 选项来基于关联标签指定项目。

8.8. 配置 kube-proxy

Kubernetes 网络代理 (kube-proxy) 在每个节点上运行,并由 Cluster Network Operator (CNO) 管理。kube-proxy 维护网络规则,以转发与服务关联的端点的连接。

8.8.1. 关于 iptables 规则同步

同步周期决定 Kubernetes 网络代理 (kube-proxy) 在节点上同步 iptables 规则的频率。

同步在发生以下事件之一时开始:

  • 发生某一事件,例如服务或端点添加到集群中或从集群中删除。
  • 距最后一次同步的时间已超过为 kube-proxy 定义的同步周期。

8.8.2. 修改 kube-proxy 配置

您可以为集群修改 Kubernetes 网络代理配置。

先决条件

  • 安装 OpenShift 命令行界面 (CLI),通常称为 oc
  • 使用 cluster-admin 角色登录正在运行的集群。

流程

  1. 通过运行以下命令,编辑 Network.operator.openshift.io 自定义资源 (CR):

    $ oc edit network.operator.openshift.io cluster
  2. 利用您对 kube-proxy 配置的更改修改 CR 中的 kubeProxyConfig 参数,如以下示例 CR 中所示:

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      kubeProxyConfig:
        iptablesSyncPeriod: 30s
        proxyArguments:
          iptables-min-sync-period: ["30s"]
  3. 保存文件并退出文本编辑器。

    保存文件并退出编辑器时,oc 命令会验证其语法。如果您的修改含有语法错误,编辑器会打开该文件并显示错误消息。

  4. 运行以下命令来确认配置更新:

    $ oc get networks.operator.openshift.io -o yaml

    该命令返回的输出类似如下示例:

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: Network
      metadata:
        name: cluster
      spec:
        clusterNetwork:
        - cidr: 10.128.0.0/14
          hostPrefix: 23
        defaultNetwork:
          type: OpenShiftSDN
        kubeProxyConfig:
          iptablesSyncPeriod: 30s
          proxyArguments:
            iptables-min-sync-period:
            - 30s
        serviceNetwork:
        - 172.30.0.0/16
      status: {}
    kind: List
  5. 可选:运行以下命令,确认 Cluster Network Operator 已接受配置更改:

    $ oc get clusteroperator network
    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.1.0-0.9   True        False         False      1m

    成功应用配置更新后,AVAILABLE 字段为 True

8.8.3. kube-proxy 配置参数

您可以修改以下 kubeProxyConfig 参数:

表 8.1. 参数

参数描述默认值

iptablesSyncPeriod

iptables 规则的刷新周期。

一个时间间隔,如 30s2m。有效的后缀包括 smh,具体参见 Go 时间包文档。

30s

proxyArguments.iptables-min-sync-period

刷新 iptables 规则前的最短时长。此参数确保刷新的频率不会过于频繁。

一个时间间隔,如 30s2m。有效的后缀包括 smh,具体参见 Go 时间包

30s

第 9 章 配置路由

9.1. 路由配置

9.1.1. 配置路由超时

如果您的服务需要低超时(满足服务级别可用性 (SLA) 目的)或高超时(具有慢速后端的情况),您可以为现有路由配置默认超时。

先决条件

  • 您需要在运行的集群中部署了 Ingress Controller。

流程

  1. 使用 oc annotate 命令,为路由添加超时:

    $ oc annotate route <route_name> \
        --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 1
    1
    支持的时间单位是微秒 (us)、毫秒 (ms)、秒钟 (s)、分钟 (m)、小时 (h)、或天 (d)。

    以下示例在名为 myroute 的路由上设置两秒的超时:

    $ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s

9.1.2. 启用 HTTP 严格传输安全性

HTTP 严格传输安全性 (HSTS) 策略是一种安全增强,可确保主机上只允许 HTTPS 流量。所有 HTTP 请求都会默认丢弃。这可用于确保与网站安全交互,或提供安全应用程序让用户受益。

当 HSTS 启用时,HSTS 会添加一个 Strict Transport Security 标头到站点的 HTTPS 响应。您可以在要重定向的路由中使用 insecureEdgeTerminationPolicy 值,以将 HTTP 发送到 HTTPS。但是,当启用 HSTS 时,客户端会在发送请求前将所有来自 HTTP URL 的请求更改为 HTTPS,从而消除对重定向的需求。客户端不需要支持此功能,而且也可通过设置 max-age=0 来禁用。

重要

HSTS 仅适用于安全路由(边缘终止或重新加密)。其配置在 HTTP 或传递路由上无效。

流程

  • 要在路由上启用 HSTS,请将 haproxy.router.openshift.io/hsts_header 值添加到边缘终止或重新加密路由:

    apiVersion: v1
    kind: Route
    metadata:
      annotations:
        haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload 1 2 3
    1
    max-age 是唯一的必要参数。它会测量 HSTS 策略生效的时间长度,以秒为单位。每当从主机收到含有 HSTS 标头的响应时,客户端会更新 max-age。如果 max-age 超时,客户端会丢弃该策略。
    2
    includeSubDomains 是可选的。含有此参数时,它会告知客户端应像主机一样对待主机上的所有子域。
    3
    preload 是可选的。当 max-age 大于 0 时,在 haproxy.router.openshift.io/hsts_header 中包含 preload 会使外部服务将这个站点包括在 HSTS 预加载列表中。例如,Google 等站点可以构造设有 preload 的站点的列表。浏览器可以使用这些列表来决定哪些站点可通过 HTTPS 进行通信,然后再与站点交互。如果没有设置 preload,浏览器必须通过 HTTPS 与站点交互才能获取该标头。

9.1.3. 吞吐量问题错误排解

有时,通过 OpenShift Container Platform 部署的应用程序可能会导致网络吞吐量问题,如特定服务间的延迟异常高。

如果 Pod 日志未能揭示造成问题的原因,请使用以下方法分析性能问题:

  • 使用 ping 或 tcpdump 等数据包分析器,分析 Pod 与其节点之间的流量。

    例如,在每个 Pod 上运行 tcpdump 工具,同时重现导致问题的行为。检查两端的捕获信息,以便比较发送和接收时间戳来分析与 Pod 往来的流量的延迟。如果节点接口被其他 Pod、存储设备或者数据平面的流量过载,则 OpenShift Container Platform 中可能会出现延迟。

    $ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2> 1
    1
    podip 是 Pod 的 IP 地址。运行 oc get pod <pod_name> -o wide 命令来获取 Pod 的 IP 地址。

    tcpdump 在 /tmp/dump.pcap 中生成一个包含这两个 Pod 间所有流量的文件。最好在运行分析器后立即重现问题,并在问题重现完成后马上停止分析器,从而尽量减小文件的大小。您还可以通过以下命令,在节点之间运行数据包分析器(从考量范围中剔除 SDN):

    $ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
  • 使用 iperf 等带宽测量工具来测量数据流吞吐量和 UDP 吞吐量。先从 Pod 运行该工具,再从节点运行,以此来查找瓶颈。

9.1.4. 使用 Cookie 来保持路由有状态性

OpenShift Container Platform 提供粘性会话,通过确保所有流量都到达同一端点来实现有状态应用程序流量。但是,如果端点 Pod 以重启、扩展或更改配置的方式终止,这种有状态性可能会消失。

OpenShift Container Platform 可以使用 Cookie 来配置会话持久性。Ingress Controller 选择一个端点来处理任何用户请求,并为会话创建一个 Cookie。Cookie 在响应请求时返回,用户则通过会话中的下一请求发回 Cookie。Cookie 告知 Ingress Controller 哪个端点正在处理会话,确保客户端请求使用这个 Cookie 使请求路由到同一个 Pod。

9.1.5. 特定于路由的注解

Ingress Controller 可以为它公开的所有路由设置默认选项。单个路由可以通过在其注解中提供特定配置来覆盖这些默认设置。

表 9.1. 路由注解

变量描述默认的环境变量

haproxy.router.openshift.io/balance

设置负载平衡算法。可用选项包括 sourceroundrobinleastconn

passthrough 路由 使用 ROUTER_TCP_BALANCE_SCHEME 。否则,使用 ROUTER_LOAD_BALANCE_algorithm

haproxy.router.openshift.io/disable_cookies

禁用使用 cookie 来跟踪相关连接。如果设置为 trueTRUE,则使用均衡算法来选择每个传入 HTTP 请求的后端服务连接。

 

router.openshift.io/cookie_name

指定一个可选的、用于此路由的 cookie。名称只能包含大写字母和小写字母、数字、"_" 和 "-"。默认为路由的内部密钥进行哈希处理。

 

haproxy.router.openshift.io/pod-concurrent-connections

设置路由器支持的 pod 允许的最大连接数。注意:如果存在多个 pod,则每个 pod 都可允许这里设置的连接数量。但是,如果有多个路由器,它们之间没有协调关系,每个路由器都可能会多次连接。如果没有设置,或者将其设定为 0,则没有限制。

 

haproxy.router.openshift.io/rate-limit-connections

设置 trueTRUE 来启用速率限制功能。

 

haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp

限制一个 IP 地址共享的并行 TCP 连接数。

 

haproxy.router.openshift.io/rate-limit-connections.rate-http

限制 IP 地址可以发出 HTTP 请求的速率。

 

haproxy.router.openshift.io/rate-limit-connections.rate-tcp

限制 IP 地址可以进行 TCP 连接的速率。

 

haproxy.router.openshift.io/timeout

为路由设定服务器端超时。(TimeUnits)

ROUTER_DEFAULT_SERVER_TIMEOUT

router.openshift.io/haproxy.health.check.interval

为后端健康检查设定间隔。(TimeUnits)

ROUTER_BACKEND_CHECK_INTERVAL

haproxy.router.openshift.io/ip_whitelist

为路由设置白名单。

 

haproxy.router.openshift.io/hsts_header

为 edge terminated 或 re-encrypt 路由设置 Strict-Transport-Security 标头。

 
注意

环境变量不能被编辑。

设置自定义超时的路由

apiVersion: v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms 1
...

1
使用 HAProxy 支持的时间单位(us, ms, s, m, h, d)指定新的超时时间。如果没有提供时间单位,ms 会被默认使用。
注意

如果为 passthrough 路由设置的服务器端的超时值太低,则会导致 WebSocket 连接在那个路由上经常出现超时的情况。

9.2. 安全路由

以下部分介绍如何使用自定义证书创建重新加密和边缘路由。

重要

如果您在 Microsoft Azure 中创建通过公共端点的路由,则资源名称会受到限制。您不能创建使用某些词语的资源。如需 Azure 限制词语的列表,请参阅 Azure 文档中的解决预留资源名称错误

9.2.1. 使用自定义证书创建重新加密路由

您可以通过 oc create route 命令,使用重新加密 TLS 终止和自定义证书配置安全路由。

先决条件

  • 您必须在 PEM 编码文件中有一个证书/密钥对,其中的证书对路由主机有效。
  • 您可以在 PEM 编码文件中有一个单独的 CA 证书来补全证书链。
  • 您必须在 PEM 编码文件中有单独的目标 CA 证书。
  • 您必须具有要公开的 Service 资源。
注意

不支持密码保护的密钥文件。要从密钥文件中删除密码,使用以下命令:

$ openssl rsa -in password_protected_tls.key -out tls.key

流程

此流程使用自定义证书和重新加密 TLS 终止创建 Route 资源。以下步骤假定证书/密钥对位于当前工作目录下的 tls.crttls.key 文件中。您还必须指定一个目标 CA 证书,使 Ingress Controller 信任服务的证书。您也可以根据需要指定 CA 证书来补全证书链。替换 tls.crttls.keycacert.crt 和(可选)ca.crt 的实际路径名称。替换您要为 frontend 公开的 Service 资源的名称。使用正确的主机名替换 www.example.com

  • 使用重新加密 TLS 终止和自定义证书,创建安全 Route 资源:

    $ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com

    如果您检查生成的 Route 资源,它应该类似于如下:

    安全路由 YAML 定义

    apiVersion: v1
    kind: Route
    metadata:
      name: frontend
    spec:
      host: www.example.com
      to:
        kind: Service
        name: frontend
      tls:
        termination: reencrypt
        key: |-
          -----BEGIN PRIVATE KEY-----
          [...]
          -----END PRIVATE KEY-----
        certificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        caCertificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        destinationCACertificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----

    如需了解更多选项,请参阅 oc create route reencrypt --help

9.2.2. 使用自定义证书创建边缘路由

您可以通过 oc create route 命令,使用边缘 TLS 终止和自定义证书配置安全路由。使用边缘路由时,Ingress Controller 在将流量转发到目标 Pod 之前终止 TLS 加密。该路由指定了 Ingress Controller 用于路由的 TLS 证书和密钥。

先决条件

  • 您必须在 PEM 编码文件中有一个证书/密钥对,其中的证书对路由主机有效。
  • 您可以在 PEM 编码文件中有一个单独的 CA 证书来补全证书链。
  • 您必须具有要公开的 Service 资源。
注意

不支持密码保护的密钥文件。要从密钥文件中删除密码,使用以下命令:

$ openssl rsa -in password_protected_tls.key -out tls.key

流程

此流程使用自定义证书和边缘 TLS 终止创建 Route 资源。以下步骤假定证书/密钥对位于当前工作目录下的 tls.crttls.key 文件中。您也可以根据需要指定 CA 证书来补全证书链。替换 tls.crttls.key 和(可选)ca.crt 的实际路径名称。替换您要为 frontend 公开的 Service 资源的名称。使用正确的主机名替换 www.example.com

  • 使用边缘 TLS 终止和自定义证书,创建安全 Route 资源:

    $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com

    如果您检查生成的 Route 资源,它应该类似于如下:

    安全路由 YAML 定义

    apiVersion: v1
    kind: Route
    metadata:
      name: frontend
    spec:
      host: www.example.com
      to:
        kind: Service
        name: frontend
      tls:
        termination: edge
        key: |-
          -----BEGIN PRIVATE KEY-----
          [...]
          -----END PRIVATE KEY-----
        certificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        caCertificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----

    如需了解更多选项,请参阅 oc create route edge --help

第 10 章 配置集群入口流量

10.1. 集群入口流量配置概述

OpenShift Container Platform 提供了以下从集群外部与集群中运行的服务进行通信的方法。

建议采用以下方法,它们按顺序或首选程度排列:

  • 如果您有 HTTP/HTTPS,请使用 Ingress Controller。
  • 如果您有 HTTPS 之外的 TLS 加密协议,比如对于使用 SNI 标头的 TLS,请使用 Ingress Controller。
  • 否则,请使用负载均衡器、外部 IP 或 NodePort
方法用途

使用 Ingress Controller

允许访问 HTTP/HTTPS 流量和 HTTPS 以外的 TLS 加密协议(例如,使用 SNI 标头的 TLS)。

使用负载均衡器服务自动分配外部 IP

允许流量通过从池分配的 IP 地址传到非标准端口。

手动将外部 IP 分配给服务

允许流量通过特定的 IP 地址传到非标准端口。

配置 NodePort

在集群中的所有节点上公开某一服务。

10.2. 使用 Ingress Controller 配置集群入口流量

OpenShift Container Platform 提供了从集群外部与集群中运行的服务进行通信的方法。此方法使用了 Ingress Controller。

10.2.1. 使用 Ingress Controller 和路由

Ingress Operator 管理 Ingress Controller 和通配符 DNS。

使用 Ingress Controller 是允许从外部访问 OpenShift Container Platform 集群的最常用方法。

Ingress Controller 配置为接受外部请求并根据配置的路由进行代理。这仅限于 HTTP、使用 SNI 的 HTTPS 以及使用 SNI 的 TLS,对于通过使用 SNI 的 TLS 工作的 Web 应用程序和服务而言已经足够。

与管理员合作将 Ingress Controller 配置为接受外部请求并根据配置的路由进行代理。

管理员可以创建通配符 DNS 条目,再设置 Ingress Controller。然后,您可以处理边缘 Ingress Controller,无需与管理员联系。

在不同项目中创建一组路由时,整组路由都可用于这一组 Ingress Controller。每个 Ingress Controller 准许来自这一组路由的路由。默认情况下,所有 Ingress Controller 都准许所有路由。

Ingress Controller:

  • 默认有两个副本;即,它应该在两个 worker 节点上运行。
  • 可以纵向扩张,以在更多节点上具有更多副本。
注意

这部分中的流程需要由集群管理员执行先决条件。

先决条件

在开始以下流程前,管理员必须:

  • 设置集群联网环境的外部端口,使请求能够到达集群。
  • 确定至少有一个用户具有集群管理员角色。要将此角色添加到用户,请运行以下命令:

    oc adm policy add-cluster-role-to-user cluster-admin username
  • 有一个 OpenShift Container Platform 集群,其至少有一个 master 和至少一个节点,并且集群外有一个对集群具有网络访问权限的系统。此流程假设外部系统与集群位于同一个子网。不同子网上外部系统所需要的额外联网不在本主题的讨论范围内。

10.2.2. 创建项目和服务

如果您要公开的项目和服务尚不存在,请首先创建项目,再创建服务。

如果项目和服务都已存在,跳到公开服务以创建路由这一步。

先决条件

  • 按照 oc CLI 并以一个集群管理员身份登陆。

流程

  1. 为您的服务创建一个新项目:

    $ oc new-project <project_name>

    例如:

    $ oc new-project myproject
  2. 使用 oc new-app 命令来创建服务。例如:

    $ oc new-app \
        -e MYSQL_USER=admin \
        -e MYSQL_PASSWORD=redhat \
        -e MYSQL_DATABASE=mysqldb \
        registry.redhat.io/rhscl/mysql-80-rhel7
  3. 运行以下命令,以查看新服务是否已创建:

    $ oc get svc -n myproject
    NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
    mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s

    默认情况下,新服务没有外部 IP 地址。

10.2.3. 通过创建路由公开服务

您可以使用 oc expose 命令,将服务公开为路由。

流程

公开服务:

  1. 登录 OpenShift Container Platform。
  2. 登录您想公开的服务所在的项目。

    $ oc project project1
  3. 运行以下命令以公开路由:

    $ oc expose service <service_name>

    例如:

    $ oc expose service mysql-80-rhel7
    route "mysql-80-rhel7" exposed
  4. 使用 cURL 等工具来确保您可以使用服务的集群 IP 地址来访问该服务:

    $ curl <pod_ip>:<port>

    例如:

    $ curl 172.30.131.89:3306

    此部分中的示例使用 MySQL 服务,这需要客户端应用程序。如果您得到一串字符并看到 Got packets out of order 消息,则您已连接到该服务。

    如果您有 MySQL 客户端,请使用标准 CLI 命令登录:

    $ mysql -h 172.30.131.89 -u admin -p
    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    
    MySQL [(none)]>

10.2.4. 通过路由标签(label)配置 Ingress Controller 分片

使用路由标签进行 Ingress Controller 分片,意味着 Ingress Controller 提供由路由选择器选择的任意命名空间中的所有路由。

在一组 Ingress Controller 之间平衡传入的流量负载时,以及在将流量隔离到特定 Ingress Controller 时,Ingress Controller 分片会很有用处。例如,A 公司的流量使用一个 Ingress Controller,B 公司的流量则使用另外一个 Ingress Controller。

流程

  1. 编辑 router-internal.yaml 文件:

    # cat router-internal.yaml
    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        routeSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
  2. 应用 Ingress Controller router-internal.yaml 文件:

    # oc apply -f router-internal.yaml

    Ingress Controller 选择具有 type: sharded 标签的任意命名空间中的路由。

10.2.5. 使用命名空间标签配置 Ingress Controller 分片

使用命名空间标签进行 Ingress Controller 分片,意味着 Ingress Controller 提供由命名空间选择器选择的任意命名空间中的所有路由。

在一组 Ingress Controller 之间平衡传入的流量负载时,以及在将流量隔离到特定 Ingress Controller 时,Ingress Controller 分片会很有用处。例如,A 公司的流量使用一个 Ingress Controller,B 公司的流量则使用另外一个 Ingress Controller。

流程

  1. 编辑 router-internal.yaml 文件:

    # cat router-internal.yaml
    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        namespaceSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
  2. 应用 Ingress Controller router-internal.yaml 文件:

    # oc apply -f router-internal.yaml

    Ingress Controller 选择由命名空间选择器选择的具有 type: sharded 标签的任意命名空间中的路由。

10.2.6. 其他资源

10.3. 使用负载均衡器配置集群入口流量

OpenShift Container Platform 提供了从集群外部与集群中运行的服务进行通信的方法。此方法使用了负载均衡器。

10.3.1. 使用负载均衡器使流量进入集群

如果不需要具体的外部 IP 地址,您可以配置负载均衡器服务,以便从外部访问 OpenShift Container Platform 集群。

负载均衡器服务分配唯一 IP。负载均衡器有单一边缘路由器 IP,它可以是虚拟 IP (VIP),但仍然是一台用于初始负载均衡的计算机。

注意

如果配置了池,则会在基础架构一级进行,而不是由集群管理员完成。

注意

这部分中的流程需要由集群管理员执行先决条件。

先决条件

在开始以下流程前,管理员必须:

  • 设置集群联网环境的外部端口,使请求能够到达集群。
  • 确定至少有一个用户具有集群管理员角色。要将此角色添加到用户,请运行以下命令:

    oc adm policy add-cluster-role-to-user cluster-admin username
  • 有一个 OpenShift Container Platform 集群,其至少有一个 master 和至少一个节点,并且集群外有一个对集群具有网络访问权限的系统。此流程假设外部系统与集群位于同一个子网。不同子网上外部系统所需要的额外联网不在本主题的讨论范围内。

10.3.2. 创建项目和服务

如果您要公开的项目和服务尚不存在,请首先创建项目,再创建服务。

如果项目和服务都已存在,跳到公开服务以创建路由这一步。

先决条件

  • 按照 oc CLI 并以一个集群管理员身份登陆。

流程

  1. 为您的服务创建一个新项目:

    $ oc new-project <project_name>

    例如:

    $ oc new-project myproject
  2. 使用 oc new-app 命令来创建服务。例如:

    $ oc new-app \
        -e MYSQL_USER=admin \
        -e MYSQL_PASSWORD=redhat \
        -e MYSQL_DATABASE=mysqldb \
        registry.redhat.io/rhscl/mysql-80-rhel7
  3. 运行以下命令,以查看新服务是否已创建:

    $ oc get svc -n myproject
    NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
    mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s

    默认情况下,新服务没有外部 IP 地址。

10.3.3. 通过创建路由公开服务

您可以使用 oc expose 命令,将服务公开为路由。

流程

公开服务:

  1. 登录 OpenShift Container Platform。
  2. 登录您想公开的服务所在的项目。

    $ oc project project1
  3. 运行以下命令以公开路由:

    $ oc expose service <service_name>

    例如:

    $ oc expose service mysql-80-rhel7
    route "mysql-80-rhel7" exposed
  4. 使用 cURL 等工具来确保您可以使用服务的集群 IP 地址来访问该服务:

    $ curl <pod_ip>:<port>

    例如:

    $ curl 172.30.131.89:3306

    此部分中的示例使用 MySQL 服务,这需要客户端应用程序。如果您得到一串字符并看到 Got packets out of order 消息,则您已连接到该服务。

    如果您有 MySQL 客户端,请使用标准 CLI 命令登录:

    $ mysql -h 172.30.131.89 -u admin -p
    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    
    MySQL [(none)]>

10.3.4. 创建负载均衡器服务

使用以下流程来创建负载均衡器服务。

先决条件

  • 确保您要公开的项目和服务已经存在。

流程

创建负载均衡器服务:

  1. 登录 OpenShift Container Platform。
  2. 加载您要公开的服务所在的项目。

    $ oc project project1
  3. 在 master 节点上打开一个文本文件并粘贴以下文本,根据需要编辑该文件:

    负载均衡器配置文件示例

    apiVersion: v1
    kind: Service
    metadata:
      name: egress-2 1
    spec:
      ports:
      - name: db
        port: 3306 2
      loadBalancerIP:
      type: LoadBalancer 3
      selector:
        name: mysql 4

    1
    为负载均衡器服务输入一个描述性名称。
    2
    输入您要公开的服务所侦听的同一个端口
    3
    输入 loadbalancer 作为类型。
    4
    输入服务的名称。
  4. 保存并退出文件。
  5. 运行以下命令来创建服务:

    oc create -f <file-name>

    例如:

    oc create -f mysql-lb.yaml
  6. 执行以下命令以查看新服务:

    $ oc get svc
    NAME       TYPE           CLUSTER-IP      EXTERNAL-IP                             PORT(S)          AGE
    egress-2   LoadBalancer   172.30.22.226   ad42f5d8b303045-487804948.example.com   3306:30357/TCP   15m

    如果启用了云供应商,该服务会自动分配到一个外部 IP 地址。

  7. 在 master 上,使用 cURL 等工具来确保您可以通过公共 IP 地址访问该服务:

    $ curl <public-ip>:<port>

    例如:

    $ curl 172.29.121.74:3306

    此部分中的示例使用 MySQL 服务,这需要客户端应用程序。如果您得到一串字符并看到 Got packets out of order 消息,则您已连接到该服务。

    如果您有 MySQL 客户端,请使用标准 CLI 命令登录:

    $ mysql -h 172.30.131.89 -u admin -p
    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    
    MySQL [(none)]>

10.4. 使用服务外部 IP 配置集群入口流量

OpenShift Container Platform 提供了从集群外部与集群中运行的服务进行通信的方法。此方法使用了服务外部 IP。

10.4.1. 使用服务外部 IP 使流量进入集群

若要公开服务,一种方法是将外部 IP 地址直接分配给您想从集群外访问的服务。

必须在您的基础架构平台中置备您要使用的外部 IP 地址,并附加到集群节点。

通过对服务使用外部 IP,OpenShift Container Platform 会设置 NAT 规则,允许到达附加到该 IP 地址的任何集群节点的流量发送到其中一个内部 Pod。这与内部服务 IP 地址类似,但外部 IP 会告知 OpenShift Container Platform 此服务也应通过给定的 IP 对外部公开。管理员必须将该 IP 地址分配给集群中某一节点上的主机(节点)接口。另外,该地址也可用作虚拟 IP (VIP)。

这些 IP 地址不由 OpenShift Container Platform 管理,管理员负责确保流量能通过此 IP 到达节点。

注意

这部分中的流程需要由集群管理员执行先决条件。

先决条件

在开始以下流程前,管理员必须:

  • 设置集群联网环境的外部端口,使请求能够到达集群。
  • 确定至少有一个用户具有集群管理员角色。要将此角色添加到用户,请运行以下命令:

    oc adm policy add-cluster-role-to-user cluster-admin username
  • 有一个 OpenShift Container Platform 集群,其至少有一个 master 和至少一个节点,并且集群外有一个对集群具有网络访问权限的系统。此流程假设外部系统与集群位于同一个子网。不同子网上外部系统所需要的额外联网不在本主题的讨论范围内。

10.4.2. 创建项目和服务

如果您要公开的项目和服务尚不存在,请首先创建项目,再创建服务。

如果项目和服务都已存在,跳到公开服务以创建路由这一步。

先决条件

  • 按照 oc CLI 并以一个集群管理员身份登陆。

流程

  1. 为您的服务创建一个新项目:

    $ oc new-project <project_name>

    例如:

    $ oc new-project myproject
  2. 使用 oc new-app 命令来创建服务。例如:

    $ oc new-app \
        -e MYSQL_USER=admin \
        -e MYSQL_PASSWORD=redhat \
        -e MYSQL_DATABASE=mysqldb \
        registry.redhat.io/rhscl/mysql-80-rhel7
  3. 运行以下命令,以查看新服务是否已创建:

    $ oc get svc -n myproject
    NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
    mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s

    默认情况下,新服务没有外部 IP 地址。

10.4.3. 通过创建路由公开服务

您可以使用 oc expose 命令,将服务公开为路由。

流程

公开服务:

  1. 登录 OpenShift Container Platform。
  2. 登录您想公开的服务所在的项目。

    $ oc project project1
  3. 运行以下命令以公开路由:

    $ oc expose service <service_name>

    例如:

    $ oc expose service mysql-80-rhel7
    route "mysql-80-rhel7" exposed
  4. 使用 cURL 等工具来确保您可以使用服务的集群 IP 地址来访问该服务:

    $ curl <pod_ip>:<port>

    例如:

    $ curl 172.30.131.89:3306

    此部分中的示例使用 MySQL 服务,这需要客户端应用程序。如果您得到一串字符并看到 Got packets out of order 消息,则您已连接到该服务。

    如果您有 MySQL 客户端,请使用标准 CLI 命令登录:

    $ mysql -h 172.30.131.89 -u admin -p
    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    
    MySQL [(none)]>

10.5. 使用 NodePort 配置集群入口流量

OpenShift Container Platform 提供了从集群外部与集群中运行的服务进行通信的方法。此方法使用了 NodePort

10.5.1. 使用 NodePort 使流量进入集群

使用 NodePort 类型的 Service 资源,在集群中所有节点的特定端口上公开服务。端口在 Service 资源的 .spec.ports[*].nodePort 字段中指定。

重要

使用 NodePort 需要额外的端口资源。

NodePort 在节点 IP 地址的静态端口上公开服务。默认情况下,NodePort3000032767 的范围内,这意味着,NodePort 不可能与服务的预期端口匹配。例如:端口 8080 可能会在节点的端口 31020 中公开。

管理员必须确保外部 IP 地址路由到节点。

NodePort 和外部 IP 地址互相独立,可以同时使用它们。

注意

这部分中的流程需要由集群管理员执行先决条件。

先决条件

在开始以下流程前,管理员必须:

  • 设置集群联网环境的外部端口,使请求能够到达集群。
  • 确定至少有一个用户具有集群管理员角色。要将此角色添加到用户,请运行以下命令:

    $ oc adm policy add-cluster-role-to-user cluster-admin <user_name>
  • 有一个 OpenShift Container Platform 集群,其至少有一个 master 和至少一个节点,并且集群外有一个对集群具有网络访问权限的系统。此流程假设外部系统与集群位于同一个子网。不同子网上外部系统所需要的额外联网不在本主题的讨论范围内。

10.5.2. 创建项目和服务

如果您要公开的项目和服务尚不存在,请首先创建项目,再创建服务。

如果项目和服务都已存在,跳到公开服务以创建路由这一步。

先决条件

  • 按照 oc CLI 并以一个集群管理员身份登陆。

流程

  1. 为您的服务创建一个新项目:

    $ oc new-project <project_name>

    例如:

    $ oc new-project myproject
  2. 使用 oc new-app 命令来创建服务。例如:

    $ oc new-app \
        -e MYSQL_USER=admin \
        -e MYSQL_PASSWORD=redhat \
        -e MYSQL_DATABASE=mysqldb \
        registry.redhat.io/rhscl/mysql-80-rhel7
  3. 运行以下命令,以查看新服务是否已创建:

    $ oc get svc -n myproject
    NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
    mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s

    默认情况下,新服务没有外部 IP 地址。

10.5.3. 通过创建路由公开服务

您可以使用 oc expose 命令,将服务公开为路由。

流程

公开服务:

  1. 登录 OpenShift Container Platform。
  2. 登录您想公开的服务所在的项目。

    $ oc project project1
  3. 要为应用程序公开节点端口,请输入以下命令。OpenShift Container Platform 会自动在 30000-32767 范围内选择可用端口。

    $ oc expose dc mysql-80-rhel7 --type=NodePort --name=mysql-ingress
  4. 可选: 要使用公开的节点端口确认该服务可用,请输入以下命令:

    $ oc get svc -n myproject
    NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
    mysql-80-rhel7   ClusterIP   172.30.217.127   <none>        3306/TCP         9m44s
    mysql-ingress    NodePort    172.30.107.72    <none>        3306:31345/TCP   39s
  5. 可选: 要删除由 oc new-app 命令自动创建的服务,请输入以下命令:

    $ oc delete svc mysql-80-rhel7

第 11 章 配置集群范围代理

生产环境可能会拒绝直接访问互联网,而是提供 HTTP 或 HTTPS 代理。您可以通过修改现有集群的 Proxy 对象或在新集群的 install-config.yaml 文件中配置代理设置,将 OpenShift Container Platform 配置为使用代理。

重要

只有当您为支持的供应商使用用户置备的基础架构安装时,才会支持集群范围的代理服务器。

先决条件

  • 查看 集群需要访问的站点中的内容,决定这些站点中的任何站点是否需要绕过代理。默认情况下,所有集群出站流量都需经过代理,包括对托管集群的云供应商 API 的调用。若有需要,将站点添加到 Proxy 对象的 spec.noProxy 字段来绕过代理服务器。

    注意

    Proxy 对象的 status.noProxy 字段默认填充实例元数据端点 (169.254.169.254),以及您的安装配置中 networking.machineCIDRnetworking.clusterNetwork.cidrnetworking.serviceNetwork 字段的值。

11.1. 启用集群范围代理

Proxy 对象用于管理集群范围出口代理。如果在安装或升级集群时没有配置代理,则 Proxy 对象仍会生成,但它会有一个空的 spec。例如:

apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
  name: cluster
spec:
  trustedCA:
    name: ""
status:

集群管理员可以通过修改这个 cluster Proxy 对象来配置 OpenShift Container Platform 的代理。

注意

只支持名为 cluster 的 Proxy 对象,且无法创建额外的代理。

先决条件

  • 集群管理员权限
  • 已安装 OpenShift Container Platform oc CLI 工具

流程

  1. 创建包含代理 HTTPS 连接所需的额外 CA 证书的 ConfigMap。

    注意

    如果代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名,您可以跳过这一步。

    1. 利用以下内容,创建一个名为 user-ca-bundle.yaml 的文件,并提供 PEM 编码证书的值:

      apiVersion: v1
      data:
        ca-bundle.crt: | 1
          <MY_PEM_ENCODED_CERTS> 2
      kind: ConfigMap
      metadata:
        name: user-ca-bundle 3
        namespace: openshift-config 4
      1
      这个数据键必须命名为 ca-bundle.crt
      2
      一个或多个 PEM 编码的 X.509 证书,用来为代理的身份证书签名。
      3
      要从 Proxy 对象引用的 ConfigMap 名称。
      4
      ConfigMap 必须在 openshift-config 命名空间中。
    2. 从此文件创建 ConfigMap:

      $ oc create -f user-ca-bundle.yaml
  2. 使用 oc edit 命令修改 Proxy 对象:

    $ oc edit proxy/cluster
  3. 为代理配置所需的字段:

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      name: cluster
    spec:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: http://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
      readinessEndpoints:
      - http://www.google.com 4
      - https://www.google.com
      trustedCA:
        name: user-ca-bundle 5
    1
    用于创建集群外 HTTP 连接的代理 URL。URL 必须是 http
    2
    用于创建集群外 HTTPS 连接的代理 URL。如果没有指定,则 httpProxy 会同时用于 HTTP 和 HTTPS 连接。URL 方案必须是 http;目前不支持 https
    3
    要排除代理的目标域名、域、IP 地址或其他网络 CIDR 的逗号分隔列表。域之前加上前缀 . 可包含该域的所有子域。使用 * 可对所有目的地绕过所有代理。请注意,如果您要纵向扩展未包含在安装配置的 networking.machineCIDR 中的 worker,您必须将它们添加到此列表中,以防止连接问题。
    4
    httpProxyhttpsProxy 值写进状态之前,执行就绪度检查时要使用的一个或多个集群外部 URL。
    5
    引用 openshift-config 命名空间中的 ConfigMap,其包含代理 HTTPS 连接所需的额外 CA 证书。注意 ConfigMap 必须已经存在,然后才能在这里引用它。此字段是必需的,除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。
  4. 保存文件以应用更改。

11.2. 删除集群范围代理服务器

cluster Proxy 对象不能被删除。要从集群中删除代理,请删除 Proxy 对象的所有 spec 字段。

先决条件

  • 集群管理员权限
  • 已安装 OpenShift Container Platform oc CLI 工具

流程

  1. 使用 oc edit 命令来修改代理:

    $ oc edit proxy/cluster
  2. 删除 Proxy 对象的所有 spec 字段。例如:

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      name: cluster
    spec: {}
    status: {}
  3. 保存文件以应用更改。

第 12 章 配置自定义 PKI

有些平台组件,如 Web 控制台,使用 Routes 进行通信,且必须信任其他组件的证书与其交互。如果您使用的是自定义公钥基础架构 (PKI) ,您必须将其配置为在集群中识别其私有签名的 CA 证书。

您可以使用 Proxy API 添加集群范围的可信 CA 证书。您必须在安装过程中或运行时执行此操作。

注意

OpenShift Container Platform 4.2.23 及更高版本支持使用 Proxy API 添加集群范围的可信 CA 证书。

  • 安装过程 中,配置集群范围的代理。您需要在 install-config.yaml 文件中的 additionalTrustBundle 设置中定义私有签名的 CA 证书。

    安装程序生成名为 user-ca-bundle 的 ConfigMap,其中包含您定义的附加 CA 证书。然后,Cluster Network Operator 会创建 trusted-ca-bundle ConfigMap,将这些内容与 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包合并,Proxy 对象的 trustedCA 字段中也会引用此 ConfigMap。

  • 运行时,修改默认 Proxy 对象使其包含您私有签名的 CA 证书 (集群代理启用工作流程的一部分)。这涉及创建包含集群应信任的私有签名 CA 证书的 ConfigMap,然后使用 trustedCA 引用私有签名证书的 ConfigMap 修改代理服务器资源。
注意

安装程序配置的 additionalTrustBundle 字段和 proxy 资源的 trustedCA 字段被用来管理集群范围信任捆绑包; 在安装时会使用 additionalTrustBundle ,并在运行时使用代理的trustedCA

trustedCA 字段是对包含集群组件使用的自定义证书和密钥对的 ConfigMap 的引用。

12.1. 在安装过程中配置集群范围代理

生产环境可能会拒绝直接访问互联网,而是提供 HTTP 或 HTTPS 代理。您可以通过在 install-config.yaml 文件中配置代理设置,将新的 OpenShift Container Platform 集群配置为使用代理。

先决条件

  • 现有的 install-config.yaml 文件。
  • 查看集群需要访问的站点,并决定是否需要绕过代理。默认情况下代理所有集群出口流量,包括对托管云供应商 API 的调用。若有需要,将站点添加到 Proxy 对象的 spec.noProxy 字段来绕过代理服务器。

    注意

    Proxy 对象的 status.noProxy 字段默认填充实例元数据端点 (169.254.169.254),以及您的安装配置中 networking.machineCIDRnetworking.clusterNetwork.cidrnetworking.serviceNetwork 字段的值。

流程

  1. 编辑 install-config.yaml 文件并添加代理设置。例如:

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: http://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    ...
    1
    用于创建集群外 HTTP 连接的代理 URL。URL 必须是 http
    2
    用于创建集群外 HTTPS 连接的代理 URL。如果未指定此字段,httpProxy 会同时用于 HTTP 和 HTTPS 连接。URL 方案必须是 http;目前不支持 https
    3
    要排除代理的目标域名、域、IP 地址或其他网络 CIDR 的逗号分隔列表。域之前加上前缀 . 可包含该域的所有子域。使用 * 可对所有目的地绕过所有代理。
    4
    如果提供,安装程序会在 openshift-config 命名空间中生成名为 user-ca-bundle 的 ConfigMap,其包含代理 HTTPS 连接所需的一个或多个额外 CA 证书。然后,Cluster Network Operator 会创建 trusted-ca-bundle ConfigMap,将这些内容与 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包合并,Proxy 对象的 trustedCA 字段中也会引用此 ConfigMap。additionalTrustBundle 字段是必需的,除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。
    注意

    安装程序不支持代理的 readinessEndpoints 字段。

  2. 保存该文件,并在安装 OpenShift Container Platform 时引用。

安装程序会创建一个名为 cluster 的集群范围代理,该代理使用提供的 install-config.yaml 文件中的代理设置。如果没有提供代理设置,仍然会创建 cluster Proxy 对象,但它会有一个零 spec

注意

只支持名为 cluster 的 Proxy 对象,且无法创建额外的代理。

12.2. 启用集群范围代理

Proxy 对象用于管理集群范围出口代理。如果在安装或升级集群时没有配置代理,则 Proxy 对象仍会生成,但它会有一个空的 spec。例如:

apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
  name: cluster
spec:
  trustedCA:
    name: ""
status:

集群管理员可以通过修改这个 cluster Proxy 对象来配置 OpenShift Container Platform 的代理。

注意

只支持名为 cluster 的 Proxy 对象,且无法创建额外的代理。

先决条件

  • 集群管理员权限
  • 已安装 OpenShift Container Platform oc CLI 工具

流程

  1. 创建包含代理 HTTPS 连接所需的额外 CA 证书的 ConfigMap。

    注意

    如果代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名,您可以跳过这一步。

    1. 利用以下内容,创建一个名为 user-ca-bundle.yaml 的文件,并提供 PEM 编码证书的值:

      apiVersion: v1
      data:
        ca-bundle.crt: | 1
          <MY_PEM_ENCODED_CERTS> 2
      kind: ConfigMap
      metadata:
        name: user-ca-bundle 3
        namespace: openshift-config 4
      1
      这个数据键必须命名为 ca-bundle.crt
      2
      一个或多个 PEM 编码的 X.509 证书,用来为代理的身份证书签名。
      3
      要从 Proxy 对象引用的 ConfigMap 名称。
      4
      ConfigMap 必须在 openshift-config 命名空间中。
    2. 从此文件创建 ConfigMap:

      $ oc create -f user-ca-bundle.yaml
  2. 使用 oc edit 命令修改 Proxy 对象:

    $ oc edit proxy/cluster
  3. 为代理配置所需的字段:

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      name: cluster
    spec:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: http://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
      readinessEndpoints:
      - http://www.google.com 4
      - https://www.google.com
      trustedCA:
        name: user-ca-bundle 5
    1
    用于创建集群外 HTTP 连接的代理 URL。URL 必须是 http
    2
    用于创建集群外 HTTPS 连接的代理 URL。如果没有指定,则 httpProxy 会同时用于 HTTP 和 HTTPS 连接。URL 方案必须是 http;目前不支持 https
    3
    要排除代理的目标域名、域、IP 地址或其他网络 CIDR 的逗号分隔列表。域之前加上前缀 . 可包含该域的所有子域。使用 * 可对所有目的地绕过所有代理。请注意,如果您要纵向扩展未包含在安装配置的 networking.machineCIDR 中的 worker,您必须将它们添加到此列表中,以防止连接问题。
    4
    httpProxyhttpsProxy 值写进状态之前,执行就绪度检查时要使用的一个或多个集群外部 URL。
    5
    引用 openshift-config 命名空间中的 ConfigMap,其包含代理 HTTPS 连接所需的额外 CA 证书。注意 ConfigMap 必须已经存在,然后才能在这里引用它。此字段是必需的,除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。
  4. 保存文件以应用更改。

12.3. 使用 Operator 进行证书注入

在您的自定义 CA 证书通过 ConfigMap 添加到集群中后,Cluster Network Operator 会将用户提供的证书和系统 CA 证书合并到单一捆绑包中,并将合并的捆绑包注入请求信任捆绑包注入的 Operator。

Operator 通过创建一个带有以下标签的空 ConfigMap 来请求此注入:

config.openshift.io/inject-trusted-cabundle="true"

Operator 将这个 ConfigMap 挂载到容器的本地信任存储中。

注意

只有在 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包中没有包括证书时才需要添加可信的 CA 证书。

证书注入不仅限于 Operator。当使用 config.openshift.io/inject-trusted-cabundle=true标记(label) 创建一个空的 ConfigMap 时,Cluster Network Operator会跨命名空间注入证书 。

ConfigMap 可以驻留在任何命名空间中,但 ConfigMap 必须作为卷挂载到需要自定义 CA 的 Pod 中的每个容器。例如:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-example-custom-ca-deployment
  namespace: my-example-custom-ca-ns
spec:
  . . .
    spec:
      . . .
      containers:
        - name: my-container-that-needs-custom-ca
          volumeMounts:
          - name: trusted-ca
            mountPath: /etc/pki/ca-trust/extracted/pem
            readOnly: true
      volumes:
      - name: trusted-ca
        configMap:
          name: trusted-ca
          items:
            - key: ca-bundle.crt 1
              path: tls-ca-bundle.pem 2
1
CA-bundle.crt 需要作为 ConfigMap 密钥。
2
TLS-ca-bundle.pem 需要作为 ConfigMap 的路径。

法律通告

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.