跳到主要内容

Internal communication method between K8s Pod A and Pod B via API GW

本指南解释了如何通过 API 网关在同一集群环境中启用两个 Kubernetes Pod 之间的内部通信 - Pod A（客户端）和 Pod B（服务器）。API 网关使用 Kubernetes 服务名称和 Kong 代理规则在内部路由请求。

概念概述​

  • Pod A：发起 API 请求的客户端 Pod。
  • Pod B：接收和处理 API 请求的服务器 Pod。
  • API Gateway：根据配置的规则使用服务发现和基于头部的路由（通过 Kong）路由请求。

此配置使得在同一集群中运行的服务之间能够无缝进行内部 API 调用，确保可扩展性和服务抽象。

分步配置​

将 Pod B 的服务注册为 API 后端​

在 APIM 控制台中创建 API 时，指定 Pod B 的 Kubernetes Service FQDN 作为后端 URL。此 FQDN 确保网关能够在内部将流量路由到适当的服务。

示例后端 URL：

[http://svc-apim-gateway-manager.apim.svc.cluster.local:8081](http://svc-apim-gateway-manager.apim.svc.cluster.local:8081/)
  • svc-apim-gateway-manager：Pod B 的 Kubernetes 服务名称。
  • apim：Pod B 的命名空间。
  • svc.cluster.local：默认集群域。
  • 8081：Pod B 暴露的服务端口。

此后端注册使 API GW 能够使用基于内部 DNS 的服务发现将流量路由到 Pod B。

通过 Kong 代理从 Pod A 发起请求​

在 API 注册后，Pod A 可以通过访问 Kong 代理的内部服务地址并设置正确的 Host 头来调用暴露的 API。Kong 会相应地将请求路由到 Pod B。

示例请求：

curl -H "Host: `<desired-host>`" \
http://`<KONG_PROXY_SERVICE>`.`<kong-namespace>`.svc.cluster.local/svc-b/api
  • 将 desired-host 替换为在 API 配置中注册的主机名。
  • 将 KONG_PROXY_SERVICE 替换为您的 Kong Proxy 的服务名称。
  • 将 kong-namespace 替换为 Kong 部署所在的命名空间。
  • /svc-b/api 是映射到后端 API 的路径。

Host 头部决定了在 Kong 中将触发哪个路由。确保它与 API 创建时注册的路由匹配。

Notes​

  • 此设置完全在 Kubernetes 网络内使用内部 DNS。
  • 确保 Kong Proxy 可以访问目标服务的 FQDN。
  • 所有相关服务（Kong、Pod A、Pod B）必须在可以通过 DNS 或适当的网络策略解析彼此服务的命名空间中。