在 GKE 上安裝 kiali 會導致后端 NotFound 錯誤

Question

我已經安裝了 kiali 運算符並嘗試從 Ingress 上的 URL(xxxx/kiali) 加載 UI。 以下是我在加載 url 時得到的文本。

響應 404（后端 NotFound），[ /kiali/ ] 的服務規則不存在

我所有的集群組件都是綠色的，如下所示。 任何想法？

Answer 1

我遇到了同樣的問題，終於讓它工作了。 經過一些比較測試和很多困惑之后，這是發生了什么以及如何解決它：

1. 最新的官方 istio 1.7.4 教程提供了一個示例入口 yaml，其中包含一個新屬性pathType ，該屬性僅適用於 GKE 1.18 及更高版本：

kind: Ingress
...
  - host: my-kiali.io
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          serviceName: kiali
          ...

現在，GKE 1.18 僅在 GCP 的 RAPID 發布通道中可用。 對於 GCP 控制台默認的 REGULAR 通道，目前最高為 GKE 1.17。 如果是這樣，那很明顯需要注意和修復，因為 1.17 的kubectl apply會抱怨語法錯誤。 不明顯的是，在 1.17 和更早版本中，我們需要 append 通配符到path ，以便它讀取：

      - path: /*

如果沒有該通配符* ， ingress將向瀏覽器返回您提到的錯誤消息（此請求的 HTTP 回復狀態代碼確實為 404，如正文中所建議的那樣）：

response 404 (backend NotFound), service rules for [ /kiali/ ] non-existent 

這是簡單的部分，並回答了您的問題（希望如此）。 現在進入下一個問題，雖然它不是你問題的一部分......

2. 假設我們解決了問題 1。我們現在使用kubectl apply...部署入口。 然后我們需要等待幾分鍾讓 GCP 創建外部負載均衡器。 各種互聯網文獻說要等到分配外部 IP 地址 - 您可以在 GCP 控制台上檢查負載均衡器或：

$ kubectl describe ingress istio-system -n istio-system | grep Address

但我認為這還不夠——而且這種現象不僅限於 Istio。 IP地址分配后，還需要進一步等待，直到GCP報告所有后端健康檢查都處於HEALTHY狀態。 您可以在 CLI 中檢查它：

$ kubectl get ingress istio-system -n istio-system -o yaml | grep ingress.kubernetes.io/backends

    ingress.kubernetes.io/backends: '{...,"k8s1-898cbc37-istio-system-kiali-20001-dfe8fc73":"HEALTHY",...}'

或在 GCP 控制台中：

額外的等待時間是多久？ 對我來說，從 IP 被分配到后端健康的時間，花了 7 分鍾：

$ kubectl describe ingress istio-system -n istio-system
...
Events:
  Type    Reason  Age    From                     Message
  ----    ------  ----   ----                     -------
  Normal  ADD     ...    loadbalancer-controller  istio-system/istio-system
  Normal  CREATE  7m21s  loadbalancer-controller  ip: 34.120.142.25

盡管readinessProbe要短得多：

$ cat istio-1.7.4/samples/addons/kiali.yaml
        ...
        readinessProbe:
          httpGet:
            ...
          initialDelaySeconds: 5
          periodSeconds: 30

實際等待和periodSeconds之間的巨大差異可能會在操作過程中引起相當多的混亂。

When a browser tries to hit http://my-kiali.io (BTW, must add that hostname to C:\Windows\System32\drivers\etc\hosts ), here's what the browser will experience over different phases on the wait:

• 在這 7 分鍾的大部分等待中（在分配 IP 之后），瀏覽器將獲得 HTTP 404。請注意，這與您的問題中的錯誤不同。 My 404 here is the HTTP status for the very first URL http://my-kiali.io/ , meaning that the backend isn't in HEALTHY status -- the HTTP request never reached the Kiali pod. 相比之下，您的 404 實際上前面有一個 HTTP 302 （從/重定向到/kiali/ ），這意味着后端是健康的（這就是 HTTP 302 回復/重定向是由 Kiali pod 生成的）但是'找不到重定向的 URL 路徑/kiali/的轉發規則（因為該規則缺少通配符* ）。

• 在這 7 分鍾的等待快結束時，瀏覽器可能會在短時間內獲得 HTTP 502（“壞網關”）。 這只是負載均衡器正在轉換的時候。

• 等待 7 分鍾后，瀏覽器首先會得到 HTTP 302（“重定向”），它從/重定向到/kiali/ ，然后是 HTTP 200（成功重定向后）。 Kiali GUI 控制台成功顯示在瀏覽器上。

問題解決了！

PS：如果您確實在關注 Istio 官方教程，您可能會遇到其他 2 個（不相關的）錯誤：

a） timeoutSeconds與periodSeconds ：

Error during sync: error running backend syncing routine: googleapi: Error 400: Invalid value for field 'resource.timeoutSec': '30'. TimeoutSec should be less than checkIntervalSec., invalid

解決方案是編輯所有istio-1.7.4/samples/addons/*.yaml以使timeoutSeconds小於periodSeconds 。

b) my-istio-tracing.io servicePort服務端口。 示例類型： 教程中顯示的kind: Ingress端口號錯誤。 正確的端口號應該是80 ：

  - host: my-istio-tracing.io
    http:
      paths:
      - ...
        backend:
          ...
          servicePort: 9411  # <<=== This should be 80.