我的系统中有许多restful服务
- 一些是我们的在kubernetes集群中
- 其他位于遗留基础架构上，并且托管在VM的上
我们的许多restful服务对彼此进行同步调用(因此不异步使用消息队列(
我们还有许多UI(胖客户端或网络应用程序(使用这些服务
我们可以定义一个简单的k8s清单文件，如
- 播客
- 服务
- Ingress
apiVersion: v1
kind: Pod
metadata:
name: "orderManager"
spec:
containers:
- name: "orderManager"
image: "gitlab-prem.com:5050/image-repo/orderManager:orderManager_1.10.22"
---
apiVersion: v1
kind: Service
metadata:
name: "orderManager-service"
spec:
type: NodePort
selector:
app: "orderManager"
ports:
- protocol: TCP
port: 50588
targetPort: 50588
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: orderManager-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /orders
pathType: Prefix
backend:
service:
name: "orderManager-service"
port:
number: 50588
我真的不确定集群上restful服务相互通信的最佳方式是什么。
- 对于集群之外的调用者来说，似乎只有一个好的路由，那就是使用由ingress规则构建的url
- 集群中的两个选项
这可能会通过的例子进一步说明这一点
| Caller | Receiver | 示例Url | |
|---|---|---|---|
| UI | 在集群上 | http://clusterip/orders | 用户界面将使用集群ip和入口规则到达订单经理 |
| 群集外服务http://clusterip/orders | 就像UI一样 | ||
| 在群集上 | On Clusterhttp://clusterip/orders | 可以使用与上述方法类似的入口规则 | |
| 在群集上 | On Clusterhttp://orderManager-service:50588/ | 可以直接使用服务名称和端口 |
这取决于您是否希望通过ingress控制器路由请求。
发送到Ingress资源中配置的完整URL的请求将由Ingress控制器处理。控制器本身——在这种情况下是NGINX——将代理请求到服务。然后，请求将被路由到Pod。
将请求直接发送到服务的URL只需跳过入口控制器。请求被直接路由到Pod。
两个选项之间的权衡取决于您的设置。
通过入口控制器发送请求会增加请求延迟和资源消耗。如果你的入口控制器除了路由请求之外什么都不做，我建议你直接向服务发送请求。
但是，如果您将ingress控制器用于其他目的，如身份验证、监控、日志记录或跟踪，那么您可能更喜欢控制器处理内部请求。
例如，在我的一些集群上，我使用NGINX入口控制器来测量请求延迟并跟踪HTTP响应状态。我通过入口控制器在同一集群中运行的应用程序之间路由请求，以便获得可用的信息。为了提高可观察性，我付出了增加延迟和资源使用的代价。
在你的情况下，这种权衡是否值得取决于你。如果你的入口控制器只做基本的路由，那么我的建议是完全跳过它。如果它做得更多，那么你需要权衡通过它路由请求的利弊