虚拟 IP 和服务代理

每个 Kubernetes 集群中的 节点 都会运行一个 kube-proxy（除非您已部署自己的替代组件来代替 kube-proxy）。

kube-proxy 组件负责为类型不是 ExternalName 的 服务 实现虚拟 IP 机制。kube-proxy 的每个实例都会监视 Kubernetes 控制平面 以了解服务和 EndpointSlice 对象 的添加和删除。对于每个服务，kube-proxy 会调用适当的 API（取决于 kube-proxy 模式）来配置节点以捕获到服务的 clusterIP 和 port 的流量，并将该流量重定向到服务的某个端点（通常是 Pod，但也可能是用户提供的任意 IP 地址）。控制循环确保每个节点上的规则与 API 服务器指示的服务和 EndpointSlice 状态可靠地同步。

一个经常出现的问题是，为什么 Kubernetes 依赖于代理来将入站流量转发到后端。其他方法怎么样？例如，是否可以配置具有多个 A 值（或 IPv6 的 AAAA）的 DNS 记录，并依赖于轮询名称解析？

使用代理来处理服务的原因有很多。

• DNS 实现的历史悠久，它们不尊重记录 TTL，并在名称查找结果应该过期后缓存它们。
• 某些应用程序只执行一次 DNS 查找，并无限期地缓存结果。
• 即使应用程序和库确实进行了适当的重新解析，DNS 记录上的低或零 TTL 也会给 DNS 带来沉重的负载，这将难以管理。

在本页面的后面，您可以了解各种 kube-proxy 实现的工作原理。总的来说，您应该注意，在运行 kube-proxy 时，内核级规则可能会被修改（例如，iptables 规则可能会被创建），在某些情况下，这些规则直到您重新启动才会被清理。因此，运行 kube-proxy 应该只由了解在计算机上运行低级、特权网络代理服务的后果的管理员执行。虽然 kube-proxy 可执行文件支持 cleanup 功能，但此功能不是官方功能，因此只能按原样使用。

此参考中的某些详细信息引用了一个示例：无状态图像处理工作负载的后端 Pod，以三个副本运行。这些副本是可互换的——前端不在乎使用哪个后端。虽然构成后端集的实际 Pod 可能会发生变化，但前端客户端不应该需要知道这一点，也不应该需要跟踪后端集本身。

代理模式

kube-proxy 以不同的模式启动，这些模式由其配置决定。

在 Linux 节点上，kube-proxy 可用的模式为

iptables

一种模式，其中 kube-proxy 使用 iptables 配置数据包转发规则。

ipvs

一种模式，其中 kube-proxy 使用 ipvs 配置数据包转发规则。

nftables

一种模式，其中 kube-proxy 使用 nftables 配置数据包转发规则。

在 Windows 上，kube-proxy 只有一个模式可用

kernelspace

一种模式，其中 kube-proxy 在 Windows 内核中配置数据包转发规则

iptables 代理模式

此代理模式仅在 Linux 节点上可用。

在此模式下，kube-proxy 使用内核 netfilter 子系统的 iptables API 配置数据包转发规则。对于每个端点，它都会安装 iptables 规则，这些规则默认情况下会随机选择一个后端 Pod。

示例

例如，考虑本页前面描述的图像处理应用程序。创建后端服务时，Kubernetes 控制平面会分配一个虚拟 IP 地址，例如 10.0.0.1。对于此示例，假设服务端口为 1234。集群中的所有 kube-proxy 实例都会观察到新服务的创建。

当节点上的 kube-proxy 看到一个新服务时，它会安装一系列 iptables 规则，这些规则会将虚拟 IP 地址重定向到更多 iptables 规则（按服务定义）。每个服务规则都链接到每个后端端点的进一步规则，而每个端点规则都使用目标 NAT 将流量重定向到后端。

当客户端连接到服务的虚拟 IP 地址时，iptables 规则就会生效。会选择一个后端（基于会话亲和性或随机），并将数据包重定向到后端，而不会重写客户端 IP 地址。

当流量通过节点端口或负载均衡器传入时，也会执行相同的基本流程，尽管在这种情况下，客户端 IP 地址会发生更改。

优化 iptables 模式性能

在 iptables 模式下，kube-proxy 为每个服务创建一些 iptables 规则，并为每个端点 IP 地址创建一些 iptables 规则。在具有数万个 Pod 和服务的集群中，这意味着数万个 iptables 规则，并且当服务（或其 EndpointSlices）发生变化时，kube-proxy 可能需要很长时间才能在内核中更新这些规则。您可以通过 kube-proxy 配置文件（通过 kube-proxy --config <path> 指定）的 iptables 部分 中的选项来调整 kube-proxy 的同步行为。

...
iptables:
  minSyncPeriod: 1s
  syncPeriod: 30s
...

minSyncPeriod

minSyncPeriod 参数设置尝试将 iptables 规则与内核重新同步之间的最短持续时间。如果它是 0s，那么 kube-proxy 每次服务或端点发生变化时都会立即同步规则。这在非常小的集群中可以正常工作，但在短时间内发生大量变化时会导致大量冗余工作。例如，如果您有一个由具有 100 个 Pod 的 部署 支持的服务，并且您删除了部署，那么使用 minSyncPeriod: 0s，kube-proxy 最终会将服务的端点从 iptables 规则中逐个删除，总共进行 100 次更新。使用更大的 minSyncPeriod，多个 Pod 删除事件会聚合在一起，因此 kube-proxy 最终可能会进行 5 次更新，每次删除 20 个端点，这在 CPU 方面会更有效，并且会导致更快地同步完整的更改集。

minSyncPeriod 的值越大，可以聚合的工作就越多，但缺点是每个单独的更改最终可能需要等待长达 minSyncPeriod 的时间才能被处理，这意味着 iptables 规则花费更多的时间与当前 API 服务器状态不同步。

1s 的默认值应该在大多数集群中都能正常工作，但在非常大的集群中，可能需要将其设置为更大的值。特别是，如果 kube-proxy 的 sync_proxy_rules_duration_seconds 指标指示平均时间远大于 1 秒，那么增加 minSyncPeriod 可能会使更新更有效。

更新旧版 minSyncPeriod 配置

旧版本的 kube-proxy 在每次同步时都会更新所有服务的规则；这会导致大型集群中的性能问题（更新延迟），而推荐的解决方案是设置更大的 minSyncPeriod。自 Kubernetes v1.28 以来，kube-proxy 的 iptables 模式使用了一种更简洁的方法，只在服务或 EndpointSlices 实际发生变化时才进行更新。

如果您之前覆盖了 minSyncPeriod，则应尝试删除该覆盖，并让 kube-proxy 使用默认值（1s）或至少使用比升级前更小的值。

如果您没有运行来自 Kubernetes 1.30 的 kube-proxy，请检查您实际运行的版本的行为和相关建议。

syncPeriod

syncPeriod 参数控制一些与单个服务和 EndpointSlices 的更改无关的同步操作。特别是，它控制 kube-proxy 多快地注意到外部组件是否干扰了 kube-proxy 的 iptables 规则。在大型集群中，kube-proxy 也只会在每 syncPeriod 执行一次某些清理操作，以避免不必要的工作。

在大多数情况下，增加 syncPeriod 预计不会对性能产生太大影响，但在过去，有时将它设置为非常大的值（例如，1h）是有用的。现在不再推荐这样做，并且很可能比提高性能更损害功能。

IPVS 代理模式

此代理模式仅在 Linux 节点上可用。

在 ipvs 模式下，kube-proxy 使用内核 IPVS 和 iptables API 创建规则，将流量从服务 IP 重定向到端点 IP。

IPVS 代理模式基于 netfilter 钩子函数，类似于 iptables 模式，但使用哈希表作为底层数据结构，并在内核空间中工作。这意味着 kube-proxy 在 IPVS 模式下比 iptables 模式下具有更低的延迟重定向流量，在同步代理规则时具有更好的性能。与 iptables 代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。

IPVS 为将流量平衡到后端 Pod 提供了更多选项；这些是

• rr（轮询）：流量在后端服务器之间平均分配。

• wrr（加权轮询）：流量根据服务器的权重路由到后端服务器。权重较高的服务器接收新的连接并获得比权重较低的服务器更多的请求。

• lc（最少连接）：更多流量分配给活动连接较少的服务器。

• wlc（加权最少连接）：更多流量路由到连接数相对于其权重较少的服务器，即连接数除以权重。

• lblc（基于位置的最少连接）：如果服务器没有过载且可用，则来自同一 IP 地址的流量将发送到同一后端服务器；否则，流量将发送到连接较少的服务器，并将其保留以供将来分配。

• lblcr（基于位置的最少连接，带复制）：来自同一 IP 地址的流量将发送到连接最少的服务器。如果所有后端服务器都过载，它会选择一个连接较少的服务器并将其添加到目标集中。如果目标集在指定时间内没有改变，则会从集中移除负载最重的服务器，以避免高程度的复制。

• sh（源哈希）：通过根据源 IP 地址查找静态分配的哈希表，将流量发送到后端服务器。

• dh（目标哈希）：通过根据目标地址查找静态分配的哈希表，将流量发送到后端服务器。

• sed（最短预期延迟）：流量转发到预期延迟最短的后端服务器。如果发送到服务器，预期延迟为 (C + 1) / U，其中 C 是服务器上的连接数，U 是服务器的固定服务速率（权重）。

• nq（从不排队）：如果存在空闲服务器，则将流量发送到空闲服务器，而不是等待快速服务器；如果所有服务器都繁忙，则算法将回退到 sed 行为。

nftables 代理模式

此代理模式仅在 Linux 节点上可用。

在此模式下，kube-proxy 使用内核 netfilter 子系统的 nftables API 配置数据包转发规则。对于每个端点，它都会安装 nftables 规则，这些规则默认情况下会随机选择一个后端 Pod。

nftables API 是 iptables API 的继任者，尽管它旨在提供比 iptables 更好的性能和可扩展性，但截至 1.30，kube-proxy nftables 模式仍处于开发阶段，并不一定预期在此时胜过其他 Linux 模式。

kernelspace 代理模式

此代理模式仅在 Windows 节点上可用。

kube-proxy 在 Windows 虚拟过滤平台 (VFP) 中配置数据包过滤规则，VFP 是 Windows vSwitch 的扩展。这些规则处理节点级虚拟网络中的封装数据包，并重写数据包，以便目标 IP 地址（和第 2 层信息）对于将数据包路由到正确目的地是正确的。Windows VFP 类似于 Linux nftables 或 iptables 等工具。Windows VFP 扩展了 Hyper-V 交换机，该交换机最初是为了支持虚拟机网络而实现的。

当节点上的 Pod 将流量发送到虚拟 IP 地址时，并且 kube-proxy 选择另一个节点上的 Pod 作为负载均衡目标时，kernelspace 代理模式会重写该数据包，使其目标为目标后端 Pod。Windows 主机网络服务 (HNS) 确保配置数据包重写规则，以便返回流量看起来来自虚拟 IP 地址，而不是特定的后端 Pod。

kernelspace 模式的直接服务器返回

作为基本操作的替代方案，托管服务后端 Pod 的节点可以直接应用数据包重写，而不是将此负担放在运行客户端 Pod 的节点上。这称为直接服务器返回。

要使用此功能，您必须使用 --enable-dsr 命令行参数运行 kube-proxy 并且启用 WinDSR 功能网关。

直接服务器返回还优化了 Pod 返回流量的情况，即使两个 Pod 都在同一节点上运行。

会话亲和性

在这些代理模型中，绑定到服务的 IP:Port 的流量将被代理到适当的后端，而客户端不知道任何关于 Kubernetes 或服务或 Pod 的信息。

如果您想确保来自特定客户端的连接每次都传递到同一个 Pod，您可以通过将服务的 .spec.sessionAffinity 设置为 ClientIP 来选择基于客户端 IP 地址的会话亲和性（默认值为 None）。

会话粘性超时

您还可以通过为服务适当设置 .spec.sessionAffinityConfig.clientIP.timeoutSeconds 来设置最大会话粘性时间。（默认值为 10800，相当于 3 小时）。

IP 地址分配到服务

与 Pod IP 地址不同，Pod IP 地址实际上路由到固定目的地，服务 IP 实际上并不由单个主机应答。相反，kube-proxy 使用数据包处理逻辑（例如 Linux iptables）来定义虚拟 IP 地址，这些地址根据需要透明地重定向。

当客户端连接到 VIP 时，它们的流量会自动传输到适当的端点。服务的环境变量和 DNS 实际上是根据服务的虚拟 IP 地址（和端口）填充的。

避免冲突

Kubernetes 的主要理念之一是，您不应该暴露在可能导致您的操作因非自身原因而失败的情况。对于服务资源的设计，这意味着不要让您选择自己的 IP 地址，如果该选择可能与其他人的选择发生冲突。这是一个隔离故障。

为了允许您为服务选择 IP 地址，我们必须确保没有两个服务会发生冲突。Kubernetes 通过从为 API 服务器 配置的 service-cluster-ip-range CIDR 范围内分配给每个服务一个唯一的 IP 地址来实现这一点。

IP 地址分配跟踪

为了确保每个服务都收到一个唯一的 IP 地址，内部分配器会在创建每个服务之前，在 etcd 中原子地更新全局分配映射。映射对象必须存在于注册表中，才能让服务获得 IP 地址分配，否则创建将失败，并显示一条消息，指示无法分配 IP 地址。

在控制平面中，一个后台控制器负责创建该映射（需要支持从使用内存中锁定的旧版 Kubernetes 版本迁移）。Kubernetes 还使用控制器来检查无效分配（例如：由于管理员干预）以及清理不再被任何服务使用的已分配 IP 地址。

使用 Kubernetes API 进行 IP 地址分配跟踪

如果您启用 MultiCIDRServiceAllocator 功能网关 和 networking.k8s.io/v1alpha1 API 组，控制平面将用一个修改后的实现替换现有的 etcd 分配器，该实现使用 IPAddress 和 ServiceCIDR 对象而不是内部全局分配映射。然后，与服务关联的每个集群 IP 地址都将引用一个 IPAddress 对象。

启用功能网关还会用一个替代方案替换后台控制器，该方案处理 IPAddress 对象并支持从旧分配器模型迁移。Kubernetes 1.30 不支持从 IPAddress 对象迁移到内部分配映射。

修改后的分配器的主要优点之一是它消除了可用于服务的集群 IP 地址的 IP 地址范围的大小限制。启用 MultiCIDRServiceAllocator 后，IPv4 没有限制，对于 IPv6，您可以使用 IP 地址网络掩码，这些掩码为 /64 或更小（与旧实现中的 /108 相比）。

通过 API 使 IP 地址分配可用意味着您作为集群管理员可以允许用户检查分配给其服务的 IP 地址。Kubernetes 扩展（例如 网关 API）可以使用 IPAddress API 来扩展 Kubernetes 的固有网络功能。

以下是一个用户查询 IP 地址的简短示例

kubectl get services

NAME         TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   2001:db8:1:2::1   <none>        443/TCP   3d1h

kubectl get ipaddresses

NAME              PARENTREF
2001:db8:1:2::1   services/default/kubernetes
2001:db8:1:2::a   services/kube-system/kube-dns

Kubernetes 还允许用户使用 ServiceCIDR 对象动态定义服务的可用 IP 范围。在引导过程中，将从 kube-apiserver 的 --service-cluster-ip-range 命令行参数的值创建名为 kubernetes 的默认 ServiceCIDR 对象

kubectl get servicecidrs

NAME         CIDRS         AGE
kubernetes   10.96.0.0/28  17m

用户可以创建或删除新的 ServiceCIDR 对象来管理服务的可用 IP 范围

cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1alpha1
kind: ServiceCIDR
metadata:
  name: newservicecidr
spec:
  cidrs:
  - 10.96.0.0/24
EOF

servicecidr.networking.k8s.io/newcidr1 created

kubectl get servicecidrs

NAME             CIDRS         AGE
kubernetes       10.96.0.0/28  17m
newservicecidr   10.96.0.0/24  7m

服务虚拟 IP 地址的 IP 地址范围

Kubernetes 使用以下公式 min(max(16, cidrSize / 16), 256) 将 ClusterIP 范围划分为两个频段，基于配置的 service-cluster-ip-range 的大小。该公式的释义是永远不小于 16 或大于 256，并在它们之间使用分级阶梯函数。

Kubernetes 倾向于通过从上频段选择来为服务分配动态 IP 地址，这意味着如果您想将特定 IP 地址分配给 type: ClusterIP 服务，您应该手动从下频段分配一个 IP 地址。这种方法降低了分配冲突的风险。

流量策略

您可以设置 .spec.internalTrafficPolicy 和 .spec.externalTrafficPolicy 字段来控制 Kubernetes 如何将流量路由到健康（“就绪”）后端。

内部流量策略

您可以设置 .spec.internalTrafficPolicy 字段来控制来自内部来源的流量的路由方式。有效值为 Cluster 和 Local。将该字段设置为 Cluster 以将内部流量路由到所有就绪端点，并将 Local 设置为仅路由到就绪的节点本地端点。如果流量策略为 Local 且没有节点本地端点，则 kube-proxy 会丢弃流量。

外部流量策略

您可以设置.spec.externalTrafficPolicy字段来控制来自外部来源的流量如何路由。有效值为Cluster和Local。将该字段设置为Cluster将外部流量路由到所有就绪的端点，而将该字段设置为Local将仅路由到就绪的节点本地端点。如果流量策略为Local并且没有节点本地端点，则kube-proxy不会转发与相关服务相关的任何流量。

如果指定了Cluster，则所有节点都符合负载均衡目标的条件，只要该节点未被删除且kube-proxy处于运行状态。在此模式下：负载均衡器健康检查配置为针对服务代理的准备就绪端口和路径。在kube-proxy的情况下，这相当于：${NODE_IP}:10256/healthz。kube-proxy将返回HTTP代码200或503。kube-proxy的负载均衡器健康检查端点在以下情况下返回200：

1. kube-proxy处于运行状态，这意味着
   • 它能够推进网络编程并且在执行此操作时不会超时（超时定义为：2 × iptables.syncPeriod）；并且
2. 节点未被删除（节点未设置删除时间戳）。

kube-proxy在节点被删除时返回503并将节点标记为不符合条件的原因是，kube-proxy支持终止节点的连接排空。从Kubernetes管理的负载均衡器的角度来看，当节点正在/正在被删除时，会发生一些重要的事情。

在删除期间

• kube-proxy将开始失败其准备就绪探测，并实质上将节点标记为不符合负载均衡器流量的条件。负载均衡器健康检查失败会导致支持连接排空的负载均衡器允许现有连接终止，并阻止新的连接建立。

删除后

• Kubernetes云控制器管理器中的服务控制器从引用的合格目标集中删除节点。从负载均衡器的后端目标集中删除任何实例会立即终止所有连接。这也是kube-proxy在节点删除时首先失败健康检查的原因。

对于Kubernetes供应商来说，重要的是要注意，如果任何供应商将kube-proxy准备就绪探测配置为存活探测：kube-proxy将在节点删除后一直重新启动，直到它被完全删除。kube-proxy公开了一个/livez路径，与/healthz路径相反，它不考虑节点的删除状态，只考虑其推进网络编程的进度。因此，/livez是为希望为kube-proxy定义存活探测的任何人推荐的路径。

部署kube-proxy的用户可以通过评估指标来检查准备就绪/存活状态：proxy_livez_total/proxy_healthz_total。这两个指标都发布两个系列，一个带有200标签，另一个带有503标签。

对于Local服务：kube-proxy将在以下情况下返回200：

1. kube-proxy处于运行状态/准备就绪，并且
2. 在相关节点上有一个本地端点。

节点删除不会影响kube-proxy针对负载均衡器健康检查的返回代码。这样做的原因是：删除节点最终会导致所有端点同时在这些节点上运行时出现入口流量中断。

Kubernetes项目建议云提供商集成代码配置针对服务代理的healthz端口的负载均衡器健康检查。如果您正在使用或实现自己的虚拟IP实现，人们可以使用它来代替kube-proxy，您应该设置一个类似的健康检查端口，其逻辑与kube-proxy实现匹配。

终止端点的流量

如果在kube-proxy中启用了ProxyTerminatingEndpoints 功能门控并且流量策略为Local，则该节点的kube-proxy使用更复杂的算法来为服务选择端点。启用该功能后，kube-proxy会检查该节点是否有本地端点以及所有本地端点是否都被标记为终止。如果有本地端点并且所有端点都处于终止状态，则kube-proxy将转发流量到这些终止端点。否则，kube-proxy将始终优先转发流量到未终止的端点。

这种针对终止端点的转发行为是为了允许NodePort和LoadBalancer服务在使用externalTrafficPolicy: Local时优雅地排空连接。

当部署经过滚动更新时，支持负载均衡器的节点可能会从N个该部署的副本过渡到0个副本。在某些情况下，外部负载均衡器可以在健康检查探测之间向具有0个副本的节点发送流量。将流量路由到终止端点可确保正在缩减Pod的节点可以优雅地接收并排空到这些终止Pod的流量。当Pod完成终止时，外部负载均衡器应该已经看到节点的健康检查失败，并已将节点完全从后端池中删除。

流量分配

Kubernetes服务中的spec.trafficDistribution字段允许您表达对如何将流量路由到服务端点的偏好。kube-proxy等实现将spec.trafficDistribution字段用作指南。与特定偏好相关的行为可能在不同实现之间略有不同。

PreferClose与kube-proxy

对于kube-proxy，这意味着优先将流量发送到与客户端位于同一区域的端点。EndpointSlice控制器使用hints更新EndpointSlice，以传达此偏好，kube-proxy随后将其用于路由决策。如果客户端的区域没有可用的端点，则流量将针对该客户端在整个集群范围内路由。

在没有trafficDistribution值的的情况下，kube-proxy的默认路由策略是将流量分配到集群中的任何端点。

与service.kubernetes.io/topology-mode: Auto的比较

带有PreferClose的trafficDistribution字段和service.kubernetes.io/topology-mode: Auto注释都旨在优先考虑同一区域的流量。但是，它们的方法存在关键差异

• service.kubernetes.io/topology-mode: Auto：尝试根据可分配的CPU资源，在区域之间按比例分配流量。这种启发式方法包括安全措施（例如，针对少量端点的回退行为），并且可能会导致该功能在某些情况下出于负载均衡原因而被禁用。这种方法牺牲了一些可预测性，以换取潜在的负载均衡。

• trafficDistribution: PreferClose：这种方法旨在更简单、更可预测：“如果区域中有端点，它们将接收该区域的所有流量，如果区域中没有端点，流量将分配到其他区域”。虽然这种方法可能提供更高的可预测性，但这意味着您需要控制管理潜在的过载。

如果service.kubernetes.io/topology-mode注释设置为Auto，它将优先于trafficDistribution。（该注释将来可能会被弃用，转而使用trafficDistribution字段）。

与流量策略的交互

与trafficDistribution字段相比，流量策略字段（externalTrafficPolicy和internalTrafficPolicy）旨在提供更严格的流量位置要求。以下是trafficDistribution与它们的交互方式

• 流量策略的优先级：对于给定的服务，如果流量策略（externalTrafficPolicy或internalTrafficPolicy）设置为Local，它将优先于trafficDistribution: PreferClose，用于相应的流量类型（分别为外部或内部）。

• trafficDistribution的影响：对于给定的服务，如果流量策略（externalTrafficPolicy或internalTrafficPolicy）设置为Cluster（默认值），或者如果未设置这些字段，则trafficDistribution: PreferClose将指导相应流量类型（分别为外部或内部）的路由行为。这意味着将尝试将流量路由到与客户端位于同一区域的端点。

使用流量分配控制的注意事项

• 端点过载的可能性增加：PreferClose启发式方法将尝试将流量路由到最接近的健康端点，而不是将流量均匀地分布到所有端点。如果您在一个区域内没有足够的端点，它们可能会过载。如果传入流量没有按比例分布到各个区域，这种情况尤其可能发生。为了缓解这种情况，请考虑以下策略

  • Pod拓扑分布约束：使用Pod拓扑分布约束将您的Pod更均匀地分布到各个区域。

  • 区域特定部署：如果您预计会看到倾斜的流量模式，请为每个区域创建一个单独的部署。这种方法允许单独的工作负载独立扩展。生态系统中还有一些工作负载管理插件可以提供帮助，它们超出了Kubernetes项目本身的范围。

• 实现特定的行为：每个数据平面实现可能对该字段的处理方式略有不同。如果您使用的是除kube-proxy之外的实现，请参考该实现的特定文档，以了解该字段是如何处理的。

下一步

要了解有关服务的更多信息，请阅读使用服务连接应用程序。

您也可以

• 阅读有关服务作为概念的内容
• 阅读有关入口作为概念的内容
• 阅读API参考，了解服务API