我在我們的系統中有許多寧靜的服務
- 有些是我們在kubernetes集群中的
- 其他人在傳統基礎設施上并托管在虛擬機上
我們的許多restful 服務會相互同步呼叫（所以不是異步使用訊息佇列）
我們還有許多使用這些服務的 UI（胖客戶端或 Web 應用程式）
我們可以像這樣定義一個簡單的 k8s 清單檔案
- 莢
- 服務
- 入口
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
我真的不確定集群上的寧靜服務相互通信的最佳方式是什么。
- It seems like there is only one good route for callers outside the cluster which is use the url built by the ingress rule
- Two options within the cluster
This might illustrate it further with an example
| Caller | Receiver | Example Url | |
|---|---|---|---|
| UI | On Cluster | http://clusterip/orders | The UI would use the cluster ip and the ingress rule to reach the order manager |
| Service off cluster | On Cluster | http://clusterip/orders | Just like the UI |
| On Cluster | On Cluster | http://clusterip/orders | Could use ingress rule like the above approach |
| On Cluster | On Cluster | http://orderManager-service:50588/ | Could use the service name and port directly |
I write cluster ip a few times above but in real life we put something top so there is a friendly name like http://mycluster/orders
So when caller and reciever are both on cluster is it either
- Use the ingress rule which is also used by services and apps outside the cluster
- Use the nodeport service name which is used in the ingress rule
- Or perhaps something else!
One benefit of using nodeport service name is that you do not have to change your base URL.
- The ingress rule appends an extra elements to the route (in the above case orders)
- When I move a restful service from legacy to k8s cluster it will increase the complexity
uj5u.com熱心網友回復：
這取決于您是否希望通過入口控制器路由請求。
發送到 Ingress 資源中配置的完整 URL 的請求將由您的 Ingress 控制器處理。控制器本身——在本例中為 NGINX——將請求代理到服務。然后請求將被路由到一個 Pod。
將請求直接發送到服務的 URL 會跳過您的入口控制器。請求直接路由到 Pod。
兩個選項之間的權衡取決于您的設定。
通過入口控制器發送請求會增加請求延遲和資源消耗。如果您的入口控制器除了路由請求之外什么都不做，我建議將請求直接發送到服務。
但是，如果您將入口控制器用于其他目的，例如身份驗證、監控、日志記錄或跟蹤，那么您可能更喜歡控制器處理內部請求。
例如，在我的一些集群上，我使用 NGINX 入口控制器來測量請求延遲并跟蹤 HTTP 回應狀態。我通過入口控制器在同一集群中運行的應用程式之間路由請求，以便獲得該資訊。為了提高可觀察性，我付出了增加延遲和資源使用的代價。
在您的情況下，權衡是否值得取決于您。如果您的入口控制器僅執行基本路由，那么我的建議是完全跳過它。如果它做得更多，那么您需要權衡通過它路由請求的利弊。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/358996.html