![](/img/trans.png)
[英]Why is my inter-service traffic showing in the Passthrough Cluster in Kiali
[英]kiali showing unkown traffic via sending through ambassador
我已經安裝了服務網格(Istio)並與大使合作將流量路由到我們的應用程序。 每當我通過 Istio Ingress 發送流量時,它工作正常並與大使一起工作,但是當通過大使發送時,它顯示未知,您可以在附圖中看到,可能與大使不使用 Istio sidecar 的事實有關.
用於部署大使服務的代碼:
apiVersion: v1
kind: Service
metadata:
name: ambassador
spec:
type: LoadBalancer
externalTrafficPolicy: Local
ports:
- name: ambassador-http
port: 80
targetPort: 8080
selector:
service: ambassador
---
有什么我可以在這里添加的嗎?
謝謝
是的,這是可能的,這里是 Abmassador文檔中的詳細指南:
讓大使與 Istio 合作很簡單。 在這個例子中,我們將使用bookinfo
示例應用程序。
默認情況下,Bookinfo 應用程序使用 Istio 入口。 要使用大使,我們需要:
首先,您需要將 Ambassador-admin 服務部署到您的集群:
使用我們在線提供的 YAML 文件是最簡單的(當然,如果您願意,您當然可以下載它們並在本地使用它們!)。
首先,您需要檢查 Kubernetes 是否啟用了 RBAC:
kubectl cluster-info dump --namespace kube-system | grep authorization-mode
如果您在輸出中看到類似--authorization-mode=Node,RBAC
的內容,則 RBAC 已啟用。
如果啟用了 RBAC,則需要使用:
kubectl apply -f https://getambassador.io/yaml/ambassador/ambassador-rbac.yaml
如果沒有 RBAC,您可以使用:
kubectl apply -f https://getambassador.io/yaml/ambassador/ambassador-no-rbac.yaml
(請注意,如果您將來打算使用雙向 TLS 進行 Ambassador 和 Istio/services 之間的通信,那么您部署 Ambassador-admin 服務和下面的 Ambassador LoadBalancer 服務的順序可能需要互換)
接下來,您將部署一個大使服務,該服務充當通過 LoadBalancer 類型進入集群的入口點。 創建以下 YAML 並將其放入名為ambassador-service.yaml
的文件中。
---
apiVersion: getambassador.io/v1
kind: Mapping
metadata:
name: httpbin
spec:
prefix: /httpbin/
service: httpbin.org
host_rewrite: httpbin.org
然后,使用 kubectl 將其應用到kubectl
:
kubectl apply -f ambassador-service.yaml
上面的 YAML 做了幾件事:
LoadBalancer
。 請注意,如果您不是在LoadBalancer
是受支持類型(即 MiniKube)的環境中進行部署,則需要將其更改為不同類型的服務,例如NodePort
。/httpbin/
路由到公共httpbin.org
HTTP 請求和響應服務(它提供了可用於診斷目的的有用端點)。 在Ambassador中,Kubernetes注解(如上圖)用於配置。 更常見的是,您希望將路由配置為服務部署過程的一部分,如這個更高級的示例所示。您可以通過執行以下命令來查看兩個大使服務是否正確運行(並在幾分鍾后分配時獲取 LoadBalancer IP 地址):
$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ambassador LoadBalancer 10.63.247.1 35.224.41.XX 8080:32171/TCP 11m
ambassador-admin NodePort 10.63.250.17 <none> 8877:32107/TCP 12m
details ClusterIP 10.63.241.224 <none> 9080/TCP 16m
kubernetes ClusterIP 10.63.240.1 <none> 443/TCP 24m
productpage ClusterIP 10.63.248.184 <none> 9080/TCP 16m
ratings ClusterIP 10.63.255.72 <none> 9080/TCP 16m
reviews ClusterIP 10.63.252.192 <none> 9080/TCP 16m
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
ambassador-2680035017-092rk 2/2 Running 0 13m
ambassador-2680035017-9mr97 2/2 Running 0 13m
ambassador-2680035017-thcpr 2/2 Running 0 13m
details-v1-3842766915-3bjwx 2/2 Running 0 17m
productpage-v1-449428215-dwf44 2/2 Running 0 16m
ratings-v1-555398331-80zts 2/2 Running 0 17m
reviews-v1-217127373-s3d91 2/2 Running 0 17m
reviews-v2-2104781143-2nxqf 2/2 Running 0 16m
reviews-v3-3240307257-xl1l6 2/2 Running 0 16m
上面我們看到分配給我們的 LoadBalancer 的外部 IP 是 35.224.41.XX(XX 用於屏蔽實際值),並且所有大使 Pod 都在運行(大使依賴 Kubernetes 提供高可用,所以應該有兩個在集群中的每個節點上運行的小 pod)。
您可以通過使用測試路由到httpbin.org
來獲取發出請求的外部集群Origin IP來測試 Ambassador 是否已正確安裝:
$ curl 35.224.41.XX/httpbin/ip
{
"origin": "35.192.109.XX"
}
如果您看到類似的響應,那么一切都很好!
(獎勵:如果您想使用一點 awk 魔法將 LoadBalancer IP 導出到變量 AMBASSADOR_IP,那么您可以鍵入export AMBASSADOR_IP=$(kubectl get services ambassador | tail -1 | awk '{ print $4 }')
並使用curl $AMBASSADOR_IP/httpbin/ip
bookinfo.yaml
清單以包含必要的 Ambassador 注釋。 見下文。---
apiVersion: getambassador.io/v1
kind: Mapping
metadata:
name: productpage
spec:
prefix: /productpage/
rewrite: /productpage
service: productpage:9080
---
apiVersion: v1
kind: Service
metadata:
name: productpage
labels:
app: productpage
spec:
ports:
- port: 9080
name: http
selector:
app: productpage
上面的注解實現了從 '/productpage/' URI 到在端口 9080 ('productpage:9080') 上運行的 Kubernetes productpage 服務的 Ambassador 映射。 “前綴”映射 URI 取自作為入口點的大使服務根的上下文(通過端口 80 暴露在外部,因為它是負載均衡器),例如“35.224.41.XX/productpage/”。
您現在可以從本地文件系統上的 Istio GitHub 存儲庫的根目錄應用此清單(注意使用 istioctl kube-inject 包裝應用程序):
kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo.yaml)
kubectl delete ingress gateway
從bookinfo.yaml
清單中刪除 Ingress 控制器。35.192.109.XX/productpage/
。 您可以通過鍵入kubectl get services ambassador
Ambassador 再次查看大使的實際 IP 地址。此外,根據文檔,不需要注入大使 pod。
是的,我已經配置了所有這些東西。 這就是我在附圖中提到它的原因。 我是從 kiali 儀表板中獲取的。 我分享了 bookinfo 應用程序的輸出。 我已經部署了我自己的應用程序,它也運行良好。 但我想把這個未知的東西弄短。 我正在使用 AWS EKS 集群。
關於大使的注意事項:大使不應該有 Istio sidecar,原因有兩個。 首先,它不能,因為運行兩個單獨的 Envoy 實例會導致它們共享內存段的沖突。 第二個是大使無論如何都不應該出現在你的網格中。 網格非常適合處理從服務到服務的流量路由,但由於大使是您的入口點,它應該完全負責決定路由到哪個服務以及如何做。 讓大使和 Istio 都嘗試設置路由規則會讓人頭疼,而且沒有多大意義。
來自不屬於服務網格一部分的來源的所有流量都將顯示為unknown
。
看看 kiali 關於未知數的說法: https ://kiali.io/faq/graph/#many-unknown
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.