簡體   English   中英

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 合作

讓大使與 Istio 合作很簡單。 在這個例子中,我們將使用bookinfo示例應用程序。

  1. 按照默認說明在 Kubernetes 上安裝 Istio(不使用 sidecar 之間的相互 TLS 身份驗證)
  2. 接下來,按照說明安裝 Bookinfo 示例應用程序。
  3. 驗證示例應用程序是否按預期工作。

默認情況下,Bookinfo 應用程序使用 Istio 入口。 要使用大使,我們需要:

  1. 安裝大使。

首先,您需要將 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 做了幾件事:

  • 它為 Ambassador 創建了一個 Kubernetes 服務,類型為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

  1. 現在您將修改 bookinfo 演示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)
  1. 或者,通過鍵入kubectl delete ingress gatewaybookinfo.yaml清單中刪除 Ingress 控制器。
  2. 通過轉到您在上面配置的 Ambassador LoadBalancer 的 IP 來測試 Ambassador,例如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.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM