# 服务、负载均衡和联网

> Kubernetes 网络背后的概念和资源。

---

LLMS index: [llms.txt](/llms.txt)

---

<!--
title: "Services, Load Balancing, and Networking"
weight: 60
description: >
  Concepts and resources behind networking in Kubernetes.
-->

<!--
## The Kubernetes network model

The Kubernetes network model is built out of several pieces:

* Each [pod](/docs/concepts/workloads/pods/) in a cluster gets its
  own unique cluster-wide IP address.

  * A pod has its own private network namespace which is shared by
    all of the containers within the pod. Processes running in
    different containers in the same pod can communicate with each
    other over `localhost`.
-->
## Kubernetes 网络模型   {#the-kubernetes-network-model}

Kubernetes 网络模型由几个部分构成：

* 集群中的每个 [Pod](/zh-cn/docs/concepts/workloads/pods/)
  都会获得自己的、独一无二的集群范围 IP 地址。

  * Pod 有自己的私有网络命名空间，Pod 内的所有容器共享这个命名空间。
    运行在同一个 Pod 中的不同容器的进程彼此之间可以通过 `localhost` 进行通信。

<!--
* The _pod network_ (also called a cluster network) handles communication
  between pods. It ensures that (barring intentional network segmentation):

  * All pods can communicate with all other pods, whether they are
    on the same [node](/docs/concepts/architecture/nodes/) or on
    different nodes. Pods can communicate with each other
    directly, without the use of proxies or address translation (NAT).

    On Windows, this rule does not apply to host-network pods.

  * Agents on a node (such as system daemons, or kubelet) can
    communicate with all pods on that node.
-->
* **Pod 网络**（也称为集群网络）处理 Pod 之间的通信。它确保（除非故意进行网络分段）：

  * 所有 Pod 可以与所有其他 Pod 进行通信，
    无论它们是在同一个[节点](/zh-cn/docs/concepts/architecture/nodes/)还是在不同的节点上。
    Pod 可以直接相互通信，而无需使用代理或地址转换（NAT）。

    在 Windows 上，这条规则不适用于主机网络 Pod。

  * 节点上的代理（例如系统守护进程或 kubelet）可以与该节点上的所有 Pod 进行通信。

<!--
* The [Service](/docs/concepts/services-networking/service/) API
  lets you provide a stable (long lived) IP address or hostname for a service implemented
  by one or more backend pods, where the individual pods making up
  the service can change over time.

  * Kubernetes automatically manages
    [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)
    objects to provide information about the pods currently backing a Service.

  * A service proxy implementation monitors the set of Service and
    EndpointSlice objects, and programs the data plane to route
    service traffic to its backends, by using operating system or
    cloud provider APIs to intercept or rewrite packets.
-->
* [Service](/zh-cn/docs/concepts/services-networking/service/) API
  允许你为由一个或多个后端 Pod 实现的服务提供一个稳定（长效）的 IP 地址或主机名，
  其中组成服务的各个 Pod 可以随时变化。

  * Kubernetes 会自动管理
    [EndpointSlice](/zh-cn/docs/concepts/services-networking/endpoint-slices/)
    对象，以提供有关当前用来提供 Service 的 Pod 的信息。

  * 服务代理实现通过使用操作系统或云平台 API 来拦截或重写数据包，
    监视 Service 和 EndpointSlice 对象集，并在数据平面编程将服务流量路由到其后端。

<!--
* The [Gateway](/docs/concepts/services-networking/gateway/) API
  (or its predecessor, [Ingress](/docs/concepts/services-networking/ingress/))
  allows you to make Services accessible to clients that are outside the cluster.

  * A simpler, but less-configurable, mechanism for cluster
    ingress is available via the Service API's
    [`type: LoadBalancer`](/docs/concepts/services-networking/service/#loadbalancer),
    when using a supported <a class='glossary-tooltip' title='一个提供云计算平台的组织。' data-bs-toggle='tooltip' data-bs-placement='top' href='/zh-cn/docs/reference/glossary/?all=true#term-cloud-provider' target='_blank' aria-label='云提供商（Cloud Provider）'>云提供商（Cloud Provider）</a>.

* [NetworkPolicy](/docs/concepts/services-networking/network-policies) is a built-in
  Kubernetes API that allows you to control traffic between pods, or between pods and
  the outside world.
-->
* [Gateway](/zh-cn/docs/concepts/services-networking/gateway/) API
  （或其前身 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)）
  使得集群外部的客户端能够访问 Service。

  * 当使用受支持的 <a class='glossary-tooltip' title='一个提供云计算平台的组织。' data-bs-toggle='tooltip' data-bs-placement='top' href='/zh-cn/docs/reference/glossary/?all=true#term-cloud-provider' target='_blank' aria-label='云提供商（Cloud Provider）'>云提供商（Cloud Provider）</a> 时，通过 Service API 的
    [`type: LoadBalancer`](/zh-cn/docs/concepts/services-networking/service/#loadbalancer)
    可以使用一种更简单但可配置性较低的集群 Ingress 机制。

* [NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies)
  是一个内置的 Kubernetes API，允许你控制 Pod 之间的流量或 Pod 与外部世界之间的流量。

<!--
In older container systems, there was no automatic connectivity
between containers on different hosts, and so it was often necessary
to explicitly create links between containers, or to map container
ports to host ports to make them reachable by containers on other
hosts. This is not needed in Kubernetes; Kubernetes's model is that
pods can be treated much like VMs or physical hosts from the
perspectives of port allocation, naming, service discovery, load
balancing, application configuration, and migration.
-->
在早期的容器系统中，不同主机上的容器之间没有自动连通，
因此通常需要显式创建容器之间的链路，或将容器端口映射到主机端口，以便其他主机上的容器能够访问。
在 Kubernetes 中并不需要如此操作；在 Kubernetes 的网络模型中，
从端口分配、命名、服务发现、负载均衡、应用配置和迁移的角度来看，Pod 可以被视作虚拟机或物理主机。

<!--
Only a few parts of this model are implemented by Kubernetes itself.
For the other parts, Kubernetes defines the APIs, but the
corresponding functionality is provided by external components, some
of which are optional:

* Pod network namespace setup is handled by system-level software implementing the
  [Container Runtime Interface](/docs/concepts/containers/cri/).
-->
这个模型只有少部分是由 Kubernetes 自身实现的。
对于其他部分，Kubernetes 定义 API，但相应的功能由外部组件提供，其中一些是可选的：

* Pod 网络命名空间的设置由实现[容器运行时接口（CRI）](/zh-cn/docs/concepts/containers/cri/)的系统层面软件处理。

<!--
* The pod network itself is managed by a
  [pod network implementation](/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
  On Linux, most container runtimes use the
  <a class='glossary-tooltip' title='容器网络接口 (Container network interface；CNI) 插件是遵循 appc/CNI 协议的一类网络插件。' data-bs-toggle='tooltip' data-bs-placement='top' href='/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/' target='_blank' aria-label='Container Networking Interface (CNI)'>Container Networking Interface (CNI)</a>
  to interact with the pod network implementation, so these
  implementations are often called _CNI plugins_.

* Kubernetes provides a default implementation of service proxying,
  called <a class='glossary-tooltip' title='kube-proxy 是集群中每个节点上运行的网络代理。' data-bs-toggle='tooltip' data-bs-placement='top' href='/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/' target='_blank' aria-label='kube-proxy'>kube-proxy</a>, but some pod
  network implementations instead use their own service proxy that
  is more tightly integrated with the rest of the implementation.
-->
* Pod 网络本身由
  [Pod 网络实现](/zh-cn/docs/concepts/cluster-administration/addons/#networking-and-network-policy)管理。
  在 Linux 上，大多数容器运行时使用<a class='glossary-tooltip' title='容器网络接口 (Container network interface；CNI) 插件是遵循 appc/CNI 协议的一类网络插件。' data-bs-toggle='tooltip' data-bs-placement='top' href='/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/' target='_blank' aria-label='容器网络接口（CNI）'>容器网络接口（CNI）</a>
  与 Pod 网络实现进行交互，因此这些实现通常被称为 **CNI 插件**。

* Kubernetes 提供了一个默认的服务代理实现，称为 <a class='glossary-tooltip' title='kube-proxy 是集群中每个节点上运行的网络代理。' data-bs-toggle='tooltip' data-bs-placement='top' href='/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/' target='_blank' aria-label='kube-proxy'>kube-proxy</a>，
  但某些 Pod 网络实现使用其自己的服务代理，以便与实现的其余组件集成得更紧密。

<!--
* NetworkPolicy is generally also implemented by the pod network
  implementation. (Some simpler pod network implementations don't
  implement NetworkPolicy, or an administrator may choose to
  configure the pod network without NetworkPolicy support. In these
  cases, the API will still be present, but it will have no effect.)

* There are many [implementations of the Gateway API](https://gateway-api.sigs.k8s.io/implementations/),
  some of which are specific to particular cloud environments, some more
  focused on "bare metal" environments, and others more generic.
-->
* NetworkPolicy 通常也由 Pod 网络实现提供支持。
  （某些更简单的 Pod 网络实现不支持 NetworkPolicy，或者管理员可能会选择在不支持 NetworkPolicy
  的情况下配置 Pod 网络。在这些情况下，API 仍然存在，但将没有效果。）

* [Gateway API 的实现](https://gateway-api.sigs.k8s.io/implementations/)有很多，
  其中一些特定于某些云环境，还有一些更专注于“裸金属”环境，而其他一些则更加通用。

## 接下来

<!--
The [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/)
tutorial lets you learn about Services and Kubernetes networking with a hands-on example.

[Cluster Networking](/docs/concepts/cluster-administration/networking/) explains how to set
up networking for your cluster, and also provides an overview of the technologies involved.
-->
[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/)教程通过一个实际的示例让你了解
Service 和 Kubernetes 如何联网。

[集群网络](/zh-cn/docs/concepts/cluster-administration/networking/)解释了如何为集群设置网络，
还概述了所涉及的技术。

<!--
To learn about specific networking concepts, see:

* [Service](/docs/concepts/services-networking/service/) - expose an application behind a single outward-facing endpoint
* [Ingress](/docs/concepts/services-networking/ingress/) - protocol-aware HTTP/HTTPS routing using URIs, hostnames, and paths
* [Gateway API](/docs/concepts/services-networking/gateway/) - dynamic infrastructure provisioning and advanced traffic routing
* [Network Policies](/docs/concepts/services-networking/network-policies/) - control traffic flow at the IP address or port level (OSI layer 3 or 4)
* [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/) - discover services within your cluster using DNS
-->
要了解具体的网络概念，请参阅：

* [Service](/zh-cn/docs/concepts/services-networking/service/) - 将应用程序暴露在单个面向外部的端点之后
* [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) - 使用
  URI、主机名和路径实现协议感知的 HTTP/HTTPS 路由
* [Gateway API](/zh-cn/docs/concepts/services-networking/gateway/) - 动态基础设施制备和高级流量路由
* [NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/) - 在
  IP 地址或端口级别（OSI 第 3 层或第 4 层）控制流量
* [Service 和 Pod 的 DNS](/zh-cn/docs/concepts/services-networking/dns-pod-service/) - 使用 DNS 发现集群中的服务

---

Section pages:

- [服务（Service）](/zh-cn/docs/concepts/services-networking/service/): 将在集群中运行的应用通过同一个面向外界的端点公开出去，即使工作负载分散于多个后端也完全可行。
- [Ingress](/zh-cn/docs/concepts/services-networking/ingress/): 使用一种能感知协议配置的机制来解析 URI、主机名称、路径等 Web 概念， 让你的 HTTP（或 HTTPS）网络服务可被访问。 Ingress 概念允许你通过 Kubernetes API 定义的规则将流量映射到不同后端。
- [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/): 为了让 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 在集群中工作， 你必须运行一个 Ingress 控制器。你需要选择至少一个 Ingress 控制器并确保其已被部署到你的集群中。 本页列出了你可以部署的常见 Ingress 控制器。
- [Gateway API](/zh-cn/docs/concepts/services-networking/gateway/): Gateway API 是一组 API 类别，可提供动态基础设施制备和高级流量路由。
- [EndpointSlice](/zh-cn/docs/concepts/services-networking/endpoint-slices/): EndpointSlice API 是 Kubernetes 用于扩缩 Service 以处理大量后端的机制，还允许集群高效更新其健康后端的列表。
- [网络策略](/zh-cn/docs/concepts/services-networking/network-policies/): 如果你希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量， NetworkPolicy 可以让你为集群内以及 Pod 与外界之间的网络流量指定规则。 你的集群必须使用支持 NetworkPolicy 实施的网络插件。
- [Service 与 Pod 的 DNS](/zh-cn/docs/concepts/services-networking/dns-pod-service/): 你的工作负载可以使用 DNS 发现集群内的 Service，本页说明具体工作原理。
- [IPv4/IPv6 双协议栈](/zh-cn/docs/concepts/services-networking/dual-stack/): Kubernetes 允许你配置单协议栈 IPv4 网络、单协议栈 IPv6 网络或同时激活这两种网络的双协议栈网络。本页说明具体配置方法。
- [拓扑感知路由](/zh-cn/docs/concepts/services-networking/topology-aware-routing/): **拓扑感知路由**提供了一种机制帮助保持网络流量处于流量发起的区域内。 在集群中 Pod 之间优先使用相同区域的流量有助于提高可靠性、性能（网络延迟和吞吐量）或降低成本。
- [Windows 网络](/zh-cn/docs/concepts/services-networking/windows-networking/)
- [Service ClusterIP 分配](/zh-cn/docs/concepts/services-networking/cluster-ip-allocation/)
- [服务内部流量策略](/zh-cn/docs/concepts/services-networking/service-traffic-policy/): 如果集群中的两个 Pod 想要通信，并且两个 Pod 实际上都在同一节点运行， **服务内部流量策略** 可以将网络流量限制在该节点内。 通过集群网络避免流量往返有助于提高可靠性、增强性能（网络延迟和吞吐量）或降低成本。