Kube.netes NGINX Ingress with Angular 返回錯誤的 MIME-Type

Question

我有一個 Angular 應用程序部署到 kube.netes 與kube.netes 入口 controller 。 一種是單節點集群設置，另一種是多節點集群設置。 兩種設置都會出現 MIME 類型問題，但單節點可以非常快速地解決它，而在多節點上，延遲是不可接受的。

在多節點集群上， Time To First Byte大約需要 5 秒：

• 對 example.com 的初始調用
• runtime-es2015.js
• polyfills-es2015.js
• appConfig.json（自定義配置文件）
• 網站圖標.ico
• 各種 png/svg 文件

在正常時間范圍內有效的是：

• main-es2015.js
• 腳本.js
• styles.css
• ng-validate.js

我的集群設置如下：

• 2 個控制平面節點
• 2個工作節點
• Cluster.networking 與運河
• 集群是用 RKE 設置的（如果重要的話）

index.html應用中的 index.html 包含：

<base href="/">

多節點入口：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: multi-node-ingress
  namespace: non-default-namespace
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: example.com
    http:
      paths:
        - path: /?(.*)
          backend:
            serviceName: ng-app-name
            servicePort: 80

在我的 DNS 供應商處，我將A條目添加到我的兩個工作節點以直接將所有流量轉發給它們。 第 4 層沒有進行負載均衡。

在 Open Shift 教程的幫助下，我能夠獲得.pcap捕獲，我可以在 wireshark 中對其進行分析。 Content-Type是text/html用於調用例如http://example.com/favicon.svg ，這會導致404 Not Found 。 然而，大約 5 秒后（絕不會低於該閾值），它有時會得到解決。

我的容器 nginx-config 如下所示：

user  nginx;
worker_processes  auto;
...

events {
  worker_connections  1024;
}

http {
  include       /etc/nginx/mime.types;

  server {
    listen 80;

    location / {
      root /usr/share/nginx/html;
      try_files $uri $uri/ /index.html;
    }

    gzip on;
  }
}

我注意到的是，如果我刪除該行include /etc/nginx/mime.types; 頁面加載完全失敗，出現Wrong MIME-Type錯誤。 但如果它存在，則需要大約 5.02 到 5.15 秒（絕不會低於 5 秒）才能找到資源。

github 上有一個問題可能與我的問題有關，但問題是根本沒有加載任何內容（錯誤的 MIME 類型）。 我確實加載了頁面，它的速度非常慢。

上述 Github 問題的一個建議是添加我使用 Config Map 所做的自定義類型module ：

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
data:
  http-snippet: |
    types {
      text/javascript .js;
      module .js;
    }
  default-type: application/octet-stream

這些類型被添加到入口控制器的 nginx.conf 中，但沒有任何效果。
默認類型沒有被拾取，仍然是text/html 。

版本：

• Kube.netes 1.18
• Angular 10
• nginx:1.19.3-alpine 用於在容器內托管 Angular 應用程序

Answer 1

DNS 響應通常被緩存，因此如果您連續執行兩個請求並且第二個請求仍然具有相同Time to first Byte您可以消除 DNS 延遲。 您可以通過 Wireshark 驗證 DNS 延遲。

不同的命名空間幾乎沒有什么區別。

你沒有說任何關於雲提供商的細節，但我假設有負載平衡器（可能卸載 SSL 解密）平衡 2 個工作節點（入口偵聽）之間的請求。 您肯定可以啟用某種日志記錄，所以這樣做。

您的 nginx 入口也保留訪問日志，因此您可以檢查它們kubectl logs <nginx-ingress-pod> -n nginx-ingress - 您必須在每個工作節點（或入口 pod 所在的每個節點）上運行它). 在這些日志中，您會發現 nginx 需要多長時間才能收到來自 Angular App pod 的響應。

結合使用 Wireshark、負載平衡器日志、nginx 入口日志和 Angular 日志（也許您需要提高日志記錄級別才能看到每個 HTTP 請求），您應該能夠查明問題出在哪里。

Answer 2

問題是文件不是從同一個節點加載的，重試機制大約需要 5 秒。 這可以通過添加node-affinity和注釋來解決，如下所示：

nginx.ingress.kubernetes.io/affinity-mode: "persistent"
nginx.ingress.kubernetes.io/affinity: "cookie"

使用此注釋，每個后續請求都將命中相同的節點。 這對於高流量站點來說可能是個問題，但對我們來說這很好用。

有關更多詳細信息，請參閱有關node-affinity的 nginx 文檔。