适用于：所有 API 管理层级
微服务非常适合用于生成 API。 可以使用 Azure Kubernetes 服务（AKS） 在云中快速部署和作 基于微服务的体系结构 。 然后，可以使用 Azure API 管理 将微服务发布为用于内部和外部使用的 API。 本文介绍使用 API 管理将基于 AKS 微服务的体系结构发布为 API 的选项。 它假定对 Kubernetes、API 管理和 Azure 网络有基本的了解。
将微服务发布为供使用的 API 时，管理微服务与使用它们的客户端之间的通信可能很困难。 跨领域问题包括身份验证、授权、限制、缓存、转换和监视。 无论微服务是向内部客户端还是外部客户端公开，这些问题都适用。
API 网关模式解决了这些问题。 API 网关充当微服务的前门，将客户端与微服务分离，添加另一层安全性，并通过消除处理交叉关注点的负担来降低微服务的复杂性。
API 管理 是一种用于解决 API 网关需求的包包解决方案。 可快速为微服务创建一致的新式网关，并将这些微服务发布为 API。 作为全生命周期 API 管理解决方案，它还提供其他功能，包括 API 发现、API 生命周期管理和 API 分析的自助服务开发人员门户。
AKS 和 API 管理结合使用时，共同提供一个平台用来部署、发布、保护、监视和管理基于微服务的 API。 本文介绍将 AKS 与 API 管理结合使用的几个选项。
在 Kubernetes 群集中，容器部署在 Pod 中，这是临时容器，并且具有生命周期。 当工作器节点发生故障时，节点上运行的 Pod 将丢失。 因此，Pod 的 IP 地址可以随时更改。 你不能依赖它来与 Pod 通信。
为了解决此问题，Kubernetes 引入了 服务的概念。 Kubernetes 服务是一个抽象层，用于定义 Pod 的逻辑组，并为这些 Pod 启用外部流量公开、负载均衡和服务发现。
准备好使用 API 管理将微服务发布为 API 时，需要考虑如何将 Kubernetes 中的服务映射到 API 管理中的 API。 此映射没有固定的规则。 这取决于你在开始时如何设计业务功能或域并将其划分到微服务中。 例如，如果某个服务背后的 Pod 负责对给定资源（例如 Customer）进行所有操作，则可以将该服务映射到一个 API。 如果将对资源的操作分区为多个微服务（例如 GetOrder 和 PlaceOrder），那么可以在 API 管理平台中将多个服务聚合为一个 API。 （请参阅下图。
映射也会逐步发展。 由于 API 管理会在微服务前面创建外观，因此可让你随着时间的推移重构和优化微服务。
在 AKS 群集前面部署 API 管理有几个选项。
AKS 群集始终部署在虚拟网络中，但 API 管理实例不一定部署在虚拟网络中。 当 API 管理不驻留在群集虚拟网络中时，AKS 群集需要发布公共终结点供 API 管理连接到。 在这种情况下，需要保护 API 管理和 AKS 之间的连接。 换句话说，需要确保只能通过 API 管理访问群集。 以下部分介绍了在 AKS 前面部署 API 管理的选项。
可以使用 NodePort、LoadBalancer 或 ExternalName 服务类型公开 AKS 群集中的服务。 当您这样做时，服务可以直接从公共互联网访问。 在群集前面部署 API 管理后，需要在微服务中应用身份验证来确保所有入站流量都通过 API 管理。 例如，API 管理可在向群集发出的每个请求中包含一个访问令牌。 每个微服务必须在处理请求之前验证令牌。
此选项可能提供在 AKS 前面部署 API 管理的最简单方法，尤其是在微服务中已实现身份验证逻辑时。
优点：
- API 管理端的简单配置，因为无需将 API 管理注入群集虚拟网络
- 如果服务已公开且微服务中已存在身份验证逻辑，则 AKS 端将保持不变
缺点：
- 由于终结点的公开可见性，会产生潜在的安全风险
- 不为入站群集流量创建单个入口点
- 重复的身份验证逻辑使微服务复杂化
尽管选项 1 可能更容易，但它有明显的缺点，如前所述。 如果 API 管理实例不驻留在群集虚拟网络中，则相互 TLS 身份验证（mTLS）是确保流量在 API 管理实例和 AKS 群集之间双向安全且信任的可靠方法。
API 管理对相互 TLS 身份验证提供原生支持。 可以通过 安装入口控制器在 Kubernetes 中启用它。 （请参阅下图。因此，在入口控制器中执行身份验证，从而简化了微服务。 此外，在支持专用 IP 地址的服务层中，可以将 API 管理的 IP 地址添加到入口允许列表中，以确保只有 API 管理有权访问群集。
优点：
- 在 API 管理端可以轻松配置，因为不需要将 API 管理注入到集群虚拟网络中，并且本身支持 mTLS。
- 集中保护入口控制器层的入站群集流量
- 通过最大程度地减少公开可见的群集终结点，降低了安全风险
缺点：
- 增加群集配置的复杂性，因为需要安装、配置和维护入口控制器并管理用于 mTLS 的证书
- 由于入口控制器终结点的公开可见性，因此增加了安全风险，除非使用 API 管理标准 v2 或高级层
通过 API 管理发布 API 时，使用订阅密钥保护对这些 API 的访问非常简单和典型。 需要使用已发布 API 的开发人员在调用这些 API 时必须在 HTTP 请求中包括一个有效的订阅密钥。 否则，API 管理网关会立即拒绝调用。 它们不会转发到后端服务。
若要获取用于访问 API 的订阅密钥，开发人员需要订阅。 订阅实质上是一个已命名的容器，该容器包含一对订阅密钥。 需要使用已发布 API 的开发人员可以获取订阅。 它们不需要 API 发布者的批准。 API 发布者也可以直接为 API 使用者创建订阅。
在某些情况下，具有法规约束或严格安全要求的客户可能会发现选项 1 和 2 由于公开的终结点而不可行。 其他情况下，使用微服务的 AKS 群集和应用程序可能驻留在同一虚拟网络中，因此没有理由公开群集，因为所有 API 流量都保留在虚拟网络中。 在这些方案中，可以将 API 管理部署到群集虚拟网络。 API 管理开发人员、高级和高级 v2（预览版）层支持注入到群集虚拟网络。
有两种将 API 管理部署到虚拟网络的模式：外部和内部。 目前，外部模式仅在 API 管理的经典层中可用。
如果 API 使用者不驻留在群集虚拟网络中，则应使用外部模式。 （请参阅下图。在此模式下，API 管理网关将注入群集虚拟网络，但可通过外部负载均衡器从公共 Internet 访问。 此体系结构有助于完全隐藏群集，同时仍允许外部客户端使用微服务。 此外，可以使用网络安全组（NSG）等 Azure 网络功能来限制网络流量。
如果所有 API 使用者都驻留在群集虚拟网络中，则可以使用内部模式。 （请参阅下图。）在此模式下，API 管理网关被注入到群集虚拟网络中，并且只能通过内部负载均衡器在此虚拟网络内部访问。 无法从公共 Internet 访问 API 管理网关或 AKS 群集。
在任何情况下，AKS 群集都不会对公众可见。 与选项 2 相反，入口控制器可能没有必要。 根据你的方案和配置，可能仍需要在 API 管理与微服务之间进行身份验证。 例如，如果使用服务网格，则始终需要相互 TLS 身份验证。
优点：
- 提供最安全的选项，因为 AKS 群集没有公共终结点
- 简化群集配置，因为没有公共终结点
- 提供使用内部模式隐藏虚拟网络中的 API 管理和 AKS 的功能
- 提供使用 Azure 网络功能（如 NSG）控制网络流量的功能
缺点：
- 提高部署和配置 API 管理以在虚拟网络中工作的复杂性