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

1.4. pod 如何通信

Pod 使用 IP 地址进行通信，并使用 DNS 来发现 pod 或服务的 IP 地址。集群使用各种策略类型来控制允许的通信。Pod 以两种方式通信： pod 到 pod 的通信和服务到 pod 的通信。

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

pod 到 pod 的通信代表 pod 能够在集群中相互通信。这对微服务和分布式应用的功能至关重要。

集群中的每个 pod 都会被分配一个唯一 IP 地址，用来直接与其他 pod 通信。Pod 到 pod 的通信对于集群内部通信非常有用，Pod 需要相互间交换数据或协作执行任务。例如，Pod A 可以使用 Pod B 的 IP 地址直接向 Pod B 发送请求。pod 可以在没有网络地址转换(NAT)的情况下通过扁平网络通信。这允许在不同节点间的 pod 间无缝通信。

1.4.1.1. 示例：控制 pod 到 pod 的通信
复制链接

在有多个容器的基于微服务的应用中，前端 pod 需要与后端 pod 通信来检索数据。通过使用 pod 到 pod 的通信（直接或通过服务进行），这些 pod 可以有效地交换信息。

要控制和保护 pod 到 pod 的通信，您可以定义网络控制。这些控制用来强制实施安全性和合规要求，它基于标签和选择器指定 pod 如何相互交流。 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-some-pods
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: app
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: backend
      ports:
        - protocol: TCP
          port: 80

1.4.2. 服务到 pod 的通信
复制链接

服务到 pod 通信可确保服务能够可靠地将网络流量路由到适当的 pod。服务是对象，用于定义 pod 的逻辑集合并提供稳定的端点，如 IP 地址和 DNS 名称。Pod IP 地址可能会改变。服务抽象 pod IP 地址，以提供一致的访问应用程序组件，即使 IP 地址有变化。

服务到 pod 通信的主要概念包括：

  • 端点：端点定义了与服务关联的 pod 的 IP 地址和端口。
  • 选择器：选择器（Selector）使用标签（如键值对）来定义选择服务应目标的一组对象的条件。
  • 服务：服务为一组 pod 提供稳定的 IP 地址和 DNS 名称。此抽象允许其他组件与服务而不是单个 pod 通信。
  • 服务发现：DNS 使服务可被发现。在创建服务时，会为其分配一个 DNS 名称。其他 pod 发现此 DNS 名称，并使用它来与服务通信。

  • 服务类型 ：服务类型控制如何在集群内部或外部公开服务。

    • ClusterIP 在内部集群 IP 上公开服务。它是默认的服务类型，使该服务只能从集群内部访问。
    • NodePort 允许外部流量来访问服务，它使用节点的 IP 通过一个静态端口公开服务。
    • LoadBalancer 使用云供应商的负载均衡器向外部公开服务。

服务使用选择器来标识应接收流量的 pod。选择器与 pod 上的标签匹配，以确定哪些 pod 是服务的一部分。示例：带有选择器 app: myapp 的服务，会将流量路由到带有标签 app: myapp 的所有 pod。

端点会被动态更新，以反映与服务选择器匹配的 pod 的当前 IP 地址。{product-name} 维护这些端点，并确保服务将流量路由到正确的 pod。

通信流指的是 Kubernetes 中的服务将流量路由到适当 pod 时发生的步骤和交互序列。服务到 pod 通信的典型通信流如下：

  • 服务创建：当您创建服务时，您可以定义服务类型、服务侦听的端口以及选择器标签。 

      apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    selector:
      app: myapp
    ports:
      - protocol: TCP
        port: 80
        targetPort: 8080
  • DNS 解析：每个 pod 都有一个 DNS 名称，其他 pod 可以使用该名称与服务通信。例如，如果服务在 my-app 命名空间中的名称为 my-service，其 DNS 名称为 my-service.my-app.svc.cluster.local。
  • 流量路由 ：当 pod 将请求发送到服务的 DNS 名称时，OpenShift Container Platform 会将名称解析为服务的 ClusterIP。然后，服务使用端点将流量路由到与其选择器匹配的其中一个 pod。
  • 负载平衡：服务还提供基本的负载平衡。它们在所有与选择器匹配的 pod 之间分发传入的流量。这样可确保没有单个 pod 消耗太多的流量。

1.4.2.1. 示例：控制服务到 pod 的通信
复制链接

集群正在运行基于微服务的应用，它有两个组件：前端和后端。前端需要与后端通信来获取数据。

流程

  1. 创建后端服务。 

    apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

  2. 配置后端 pod。 

    apiVersion: v1
kind: Pod
metadata:
  name: backend-pod
  labels:
    app: backend
spec:
  containers:
    - name: backend-container
      image: my-backend-image
      ports:
        - containerPort: 8080

  3. 建立前端通信。

    前端 pod 现在可以使用 DNS 名称 backend.default.svc.cluster.local 与后端服务通信。该服务可确保流量路由到其中一个后端 Pod。

服务到 pod 通信会抽象管理 pod IP 的复杂性，并确保集群中的可靠和高效的通信。

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2026 Red Hat返回顶部