Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

网络概述

OpenShift Container Platform 4.20

了解 OpenShift Container Platform 中的基本网络概念和常规任务

Red Hat OpenShift Documentation Team

摘要

本文档介绍了 OpenShift Container Platform 中核心网络概念、基本架构和一般网络任务。

第 1 章 了解网络
复制链接

了解网络对于在 OpenShift Container Platform 中构建弹性、安全且可扩展的应用程序至关重要。从基本 pod 到 pod 的通信到复杂的流量路由和安全规则，应用程序的每个组件都依赖于网络才能正常工作。

1.1. 核心网络层和组件
复制链接

Red Hat OpenShift Networking 基于两个基本层构建： pod 网络和 服务网络 。pod 网络是应用程序实时的位置。服务网络使您的应用程序能够可靠地访问。

1.1.1. pod 网络
复制链接

pod 网络是一个扁平网络空间，集群中的所有 pod 都接收其自身唯一的 IP 地址。此网络由 Container Network Interface (CNI)插件管理。CNI 插件负责将每个 pod 放入集群网络中。

此设计允许 pod 使用 IP 地址直接相互通信，无论它们运行在哪个节点上。但是，这些 pod IP 是临时的。这意味着，当 pod 销毁时，IP 会销毁，并在创建新 pod 时分配新的 IP 地址。因此，您不应该直接依赖 pod IP 地址进行长期通信。

1.1.2. 服务网络
复制链接

服务是一个网络对象，它为 pod 的逻辑组提供单个、稳定的虚拟 IP 地址，称为 ClusterIP，以及 DNS 名称。

当请求发送到服务的 ClusterIP 时，OpenShift Container Platform 会自动对流量负载平衡到支持该服务的一个健康 pod。它使用 Kubernetes 标签和选择器来跟踪哪些 pod 属于哪个服务。此抽象使您的应用程序具有弹性，因为可以创建和销毁各个 pod，而不影响尝试访问它们的应用程序。

1.2. 管理集群中的流量
复制链接

您的应用程序需要在集群中相互通信。OpenShift Container Platform 为内部流量提供两种主要机制：直接 pod 到 pod 通信，用于简单交换和强大的服务发现，以可靠连接。

1.2.1. pod 到 pod 的通信
复制链接

pod 使用 pod 网络分配的唯一 IP 地址直接通信。一个节点上的 pod 可以在没有网络地址转换(NAT)的情况下将流量直接发送到另一个节点上的 pod。这种直接通信模型对于需要快速交换数据的服务来说效率更高。应用程序可以直接以另一个 pod 的 IP 地址为目标，以建立连接。

1.2.2. 使用 DNS 进行服务发现
复制链接

Pod 需要可靠的方法来互相查找，因为 pod IP 地址是临时的。OpenShift Container Platform 使用 CoreDNS （内置 DNS 服务器）来提供此服务发现。

您创建的每个服务都会自动接收稳定的 DNS 名称。pod 可以使用此 DNS 名称连接到该服务。DNS 系统将名称解析为服务的稳定 ClusterIP 地址。此过程可确保即使单个 pod IP 发生变化，也确保了可靠的通信。

1.3. 管理进入和离开集群的流量
复制链接

您需要外部用户访问应用程序和应用程序来安全地访问外部服务。OpenShift Container Platform 提供多个工具来管理此流量进入和移出集群的流量。

1.3.1. 使用 Ingress 和 Route 对象公开应用程序
复制链接

要允许外部流量访问集群中的服务，请使用 Ingress Controller。此组件充当将传入请求定向到正确应用的前端。您可以使用两个主要资源之一定义流量规则：

  • Ingress：用于管理从外部访问服务的标准 Kubernetes 资源，通常用于 HTTP 和 HTTPS 流量。
  • Route 对象：提供与 Ingress 相同的功能的资源，但包括更多高级 TLS 终止选项和流量分割等额外功能。路由对象 特定于 OpenShift Container Platform。

1.3.2. 使用负载均衡器分发流量
复制链接

Load Balancer 提供单个、高度可用的 IP 地址，用于将流量定向到集群。它通常在云供应商或使用裸机基础架构上使用 MetalLB 运行外，并在运行 Ingress Controller 的多个节点上分发传入的请求。

这可防止任何单个节点成为瓶颈或故障点，以确保您的应用程序仍可以访问。

1.3.3. 控制出口流量
复制链接

Egress 代表源自集群内 pod 的出站流量，用于外部系统。OpenShift Container Platform 提供了几种管理此机制：

  • EgressIP：您可以将特定的、可预测的源 IP 地址分配给来自给定项目的所有出站流量。当您需要访问具有允许特定源 IP 的防火墙的数据库时，这非常有用。
  • 出口路由器：这是一个专用的 pod，充当出站流量的网关。它允许您通过单个受控的退出点路由连接。
  • 出口防火墙：这充当所有出站流量的集群级别防火墙。它允许您创建明确允许或拒绝从 pod 到特定外部目的地的连接的规则，从而增强了您的安全状况。

1.4. 保护网络流量
复制链接

OpenShift Container Platform 通过创建可控制允许哪些组件进行通信的规则来提供保护网络的工具。这主要通过两种类型的策略资源来管理：网络策略和管理网络策略。

1.4.1. 网络策略
复制链接

网络策略是一个资源，允许您控制 IP 地址或端口级别上流量流。这些策略在命名空间（项目）级别运行。这意味着它们通常由开发人员或项目管理员管理，以保护其特定应用。

默认情况下，项目中的所有 pod 都可以自由通信。但是，当您将 NetworkPolicy 应用到 pod 时，它会采用 "default-deny" stance。这意味着，它拒绝任何策略规则未明确允许的连接。您可以使用标签和选择器来定义策略应用到哪些 pod 以及允许哪些入口和出口流量。

1.4.2. 管理网络策略
复制链接

AdminNetworkPolicy 对象是 NetworkPolicy 对象的更强大的、集群范围的版本。它只能由集群管理员创建和管理。

管理网络策略的优先级高于标准 NetworkPolicy 对象。这样，管理员可以强制执行集群范围的安全规则，该规则无法被自己项目中的用户覆盖。例如，管理员可以使用 AdminNetworkPolicy 来阻止开发和生产命名空间之间的所有流量，或者为整个集群强制执行基准安全规则。

第 2 章 访问主机
复制链接

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

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 (RHCOS)中，您可以像安装程序一样通过 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 部署到该 control plane 主机。确定您使用了在安装过程中指定的相同的 SSH 密钥： 

    $ ssh -i <ssh-key-path> core@<master-hostname>
    Copy to Clipboard Toggle word wrap

第 3 章 网络仪表板
复制链接

网络指标可在 OpenShift Container Platform web 控制台的 dashboard 中的 Observe → Dashboards 下查看。

3.1. Network Observability Operator
复制链接

如果安装了 Network Observability Operator，可以通过从 Dashboards 下拉列表中选择 Netobserv 仪表板来查看网络流量指标仪表板。有关此仪表板中可用指标的更多信息，请参阅 Network Observability metrics dashboard。

3.2. 网络和 OVN-Kubernetes 仪表板
复制链接

您可以从仪表板中查看常规网络指标和 OVN-Kubernetes 指标。

要查看常规网络指标，请从 Dashboards 下拉列表中选择 Networking/Linux Subsystem Stats。您可以从控制面板查看以下网络指标：Network Utilisation、Network Saturation 和 Network Errors。

要查看 OVN-Kubernetes 指标，请从 Dashboards 下拉列表中选择 Networking/Infrastructure。您可以查看以下 OVN-Kuberenetes 指标：Networking Configuration, TCP Latency Probes, Control Plane Resources, 和 Worker Resources。

3.3. Ingress Operator 仪表板
复制链接

您可以从仪表板中查看 Ingress Operator 处理的网络指标。这包括类似如下的指标：

  • 传入和传出带宽
  • HTTP 错误率
  • HTTP 服务器响应延迟

要查看这些 Ingress 指标，请从 Dashboards 下拉列表中选择 Networking/Ingress。您可以查看以下类别的 Ingress 指标： Top 10 Per Route,Top 10 Per Namespace, 和 Top 10 Per Shard。

第 4 章 CIDR 范围定义
复制链接

如果您的集群使用 OVN-Kubernetes，您必须为无类别域间路由(CIDR)子网范围指定非重叠范围。

重要

对于 OpenShift Container Platform 4.17 及更新的版本，集群使用 169.254.0.0/17（IPv4），或 fd69::/112（IPv6）作为默认的伪装子网。用户也应避免这些范围。对于升级的集群，默认 masquerade 子网没有变化。

提示

您可以使用 Red Hat OpenShift Network Calculator 在集群创建过程中设置 CIDR 范围前确定您的网络需求。

您必须有一个红帽帐户才能使用该计算器。

以下子网类型，对于使用 OVN-Kubernetes 的集群是强制的：

  • Join ：使用 join 交换将网关路由器连接到分布式路由器。join 交换减少了分布式路由器的 IP 地址数量。对于使用 OVN-Kubernetes 插件的集群，专用子网的 IP 地址都会被分配给附加到 join 交换的任何逻辑端口。
  • Masquerade：在负载均衡器做出路由决策后，将从节点发送到同一节点的相同源和目标 IP 地址发生冲突。
  • Transit ：传输开关是跨集群中所有节点的分布式交换机类型。transit 交换会在不同区域间路由流量。对于使用 OVN-Kubernetes 插件的集群，专用子网的 IP 地址都会被分配给附加到 transit 交换的任何逻辑端口。
注意

您可以将集群的加入、伪装和传输 CIDR 范围作为安装后任务更改。

OVN-Kubernetes 是 OpenShift Container Platform 4.14 及之后的版本中的默认网络供应商，内部使用以下 IP 地址子网范围：

  • V4JoinSubnet: 100.64.0.0/16
  • V6JoinSubnet: fd98::/64
  • V4TransitSwitchSubnet: 100.88.0.0/16
  • V6TransitSwitchSubnet: fd97::/64
  • defaultV4MasqueradeSubnet: 169.254.0.0/17
  • defaultV6MasqueradeSubnet: fd69::/112
重要

前面的列表包括了 join、transfer 和 masquerade IPv4 和 IPv6 地址子网。如果您的集群使用 OVN-Kubernetes，请不要在集群或基础架构中的任何其他 CIDR 定义中包含这些 IP 地址子网范围。

4.1. Machine CIDR
复制链接

在 Machine classless inter-domain routing (CIDR) 字段中，您必须为机器或集群节点指定 IP 地址范围。

注意

创建集群后无法更改机器 CIDR 范围。

默认值为 10.0.0.0/16。这个范围不得与任何连接的网络冲突。

4.2. Service CIDR
复制链接

在 Service CIDR 字段中，您必须为服务指定 IP 地址范围。范围必须足够大，以适应您的工作负载。该地址块不得与从集群内部访问的任何外部服务重叠。默认为 172.30.0.0/16。

4.3. Pod CIDR
复制链接

在 pod CIDR 字段中，您必须为 pod 指定 IP 地址范围。

pod CIDR 与 clusterNetwork CIDR 和集群 CIDR 相同。范围必须足够大，以适应您的工作负载。该地址块不得与从集群内部访问的任何外部服务重叠。默认为 10.128.0.0/14。您可以在集群安装后扩展范围。

4.4. 主机前缀
复制链接

在 Host Prefix 字段中，您必须指定分配给调度到各个机器的 pod 的子网前缀长度。主机前缀决定了每台机器的 pod IP 地址池。

例如，如果主机前缀设置为 /23，则每台机器从 pod CIDR 地址范围中分配一个 /23 子网。默认值为 /23，允许 510 集群节点，以及每个节点的 510 个 pod IP 地址。

4.5. 托管 control plane 的 CIDR 范围
复制链接

要在 OpenShift Container Platform 上部署托管的 control plane，请使用以下所需的无类别域间路由(CIDR)子网范围：

  • v4InternalSubnet: 100.65.0.0/16 (OVN-Kubernetes)
  • clusterNetwork: 10.132.0.0/14 (pod network)
  • serviceNetwork: 172.31.0.0/16

如需有关 OpenShift Container Platform CIDR 范围定义的更多信息，请参阅"CIDR 范围定义"。

Legal Notice
复制链接

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat