問題描述
我們在K8S內架設串流伺服器，在做loadtest時發現，當流量變高之後，K8S用來管理線程的cadvisor所調用的ksoftirqd會占掉非常大的CPU使用率，並導致整個worker node變得緩慢。
相關的問題說明請見: Debugging network stalls on Kubernetes
形成原因
這是因為當使用 Kubernetes 的 NodePort 來公開一個服務時，它將在每個工作節點上開放一個端口，以便外部可以連接到該端口，並將流量轉發到服務的後端 Pod 上。當流量高峰期間，可能會導致節點的 CPU 負載增加，並導致大量的 IRQ 請求，這是因為每個數據包都會觸發一次 IRQ 請求。
IRQ 是中斷請求的簡寫，是一種處理設備 I/O 操作的機制。當設備有 I/O 操作時，它會觸發一個中斷請求，通知操作系統或應用程序需要處理這個 I/O 操作。在網絡通信中，每個數據包都會觸發一次 IRQ 請求，因此當流量高峰期間，大量的 IRQ 請求可能會導致節點的 CPU 負載增加，從而影響應用程序的性能。
為了減輕這個問題，您可以考慮使用負載均衡器來替代 NodePort，將流量分發到多個節點上，從而分散 CPU 負載。您還可以考慮對節點進行調優，以提高節點的性能和吞吐量。例如，可以調整節點的 CPU 和內存資源配額，優化網絡配置，減少網絡延遲等。此外，也可以嘗試使用更高效的網絡協議，如 UDP 協議，以減少 CPU 負載。
IRQ是甚麼
IRQ（Interrupt Request）是計算機系統中的中斷請求，它是用來通知 CPU 執行特定的操作的信號。中斷請求通常由外部設備發出，例如鍵盤、鼠標、網卡、磁盤控制器等，這些設備需要與 CPU 進行通信，以便進行數據傳輸、讀寫、處理等操作。
IRQ 的實現通常涉及到硬件和軟件兩個方面。在硬件方面，通常需要在主板上預留一些專門的中斷請求線（IRQ lines），用於連接各種外設和 CPU，以便它們之間進行數據傳輸和通信。一般來說，一個計算機系統會有多個 IRQ lines，每個 IRQ line 對應一個外設或者一組相關的外設。
在軟件方面，操作系統需要通過中斷控制器來管理各個 IRQ lines，以便在接收到外設發出的中斷請求時，及時地響應並處理。一般來說，中斷控制器會將中斷請求轉發給 CPU，CPU 再執行相應的中斷處理程序來處理中斷請求。
IRQ是計算機硬件的設計決定。當網絡適配器（NIC）接收到數據包時，它會發送一個中斷請求（IRQ）給處理器，通知處理器需要處理這個數據包。處理器收到 IRQ 後，會停止當前的任務，並開始處理中斷請求。處理完中斷請求後，處理器會返回到之前的任務繼續執行。.
網絡適配器是什麼
網絡適配器，也稱為網絡接口卡（Network Interface Card，NIC），是計算機中用於實現網絡通信的硬件設備之一。它通常安裝在計算機主板上，負責接收和發送網絡數據包。網絡適配器可以連接到不同類型的網絡，例如以太網、Wi-Fi、藍牙等，以實現不同的網絡通信方式。
網絡適配器在計算機中的作用是將數據轉換為網絡能夠識別和傳輸的格式，例如將數據包封裝成以太網幀，以便在以太網上進行傳輸。同時，網絡適配器也負責監控網絡上的數據流量，並在需要時觸發 IRQ 請求，通知處理器需要處理數據包。
網絡適配器的性能對網絡通信的效率和吞吐量有很大影響。在高性能計算環境中，通常會選擇高速的網絡適配器，例如 10GbE、40GbE、100GbE 等，以滿足大規模數據傳輸的需求。
為什麼在K8S的IQR會比一般Linux主機更明顯
當一般主機傳輸大量流時，也會產生網絡適配器的 IRQ 請求。但是，這種情況下的 IRQ 請求通常可以被系統有效地處理，並不會對 CPU 的負載產生太大的影響。這是因為一般主機的網絡適配器通常採用了更為先進的中斷卸載技術，如 RSS（Receive Side Scaling）、RPS（Receive Packet Steering）等，可以將 IRQ 請求在多個 CPU 核心上進行分配，從而有效地提高系統的網絡吞吐量。
在 Kubernetes 中，由於每個節點上的 Pod 分佈不確定，因此無法像一般主機那樣進行有效的中斷卸載。此外，由於網絡流量是從 NodePort 直接傳輸到 Pod，中間可能還需要經過多個網絡層，從而增加了系統的網絡負載。因此，在高負載情況下，使用 NodePort 公開服務可能會導致大量 IRQ 請求，從而增加 CPU 的負載。為了解決這個問題，可以考慮使用負載均衡器等技術，將流量轉發到多個節點上，以降低單個節點的負載。
解決方法
由於我們所架設的伺服器為串流伺服器，原本在一般的Linux主機裡面，我們會使用NGINX去做反向代理，讓主機知道現在的連接目標為串流，如下面這個nginx.conf的範例
http {
include mime.types;
default_type application/octet-stream; #設定所傳輸的格式為串流
sendfile on;
}
這樣子當有人透過http去拉取串流時，NIC就會採取長連接的方式去處理這條串流，但是，因為現在我們將串流伺服器移到K8S裡面去，連線請求處理的地方會在worker node所在的NIC上去處理，而不是在串流服務的POD去處理的。因此，即便我們在POD裡面設定連線方式為串流，在worker node上面也是不知道這件事情的。
所以我們會必須要在K8S的ingress裡面去做進一步的設定，第一步要先了解自己的K8S的ingress是用甚麼實作的，例如像我們的K8S是用kubernetes/ingress-nginx實作的
設定介紹: NGINX Configuration
這邊會有三個方式去實作
- ConfigMap：使用 Configmap 在 NGINX 中設置全局配置。
- Annotations：如果您想要特定 Ingress 規則的特定配置，請使用它。
- 自定義模板：當需要更具體的設置時，如open_file_cache，調整監聽選項，
rcvbuf或者當無法通過 ConfigMap 更改配置時。
以下是一個使用 types 設置 MIME 類型的示例：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
nginx.ingress.kubernetes.io/server-snippet: |
types {
text/html html htm shtml;
text/css css;
text/xml xml;
image/gif gif;
image/jpeg jpeg jpg;
application/javascript js;
application/atom+xml atom;
application/rss+xml rss;
text/mathml mml;
text/plain txt;
text/vnd.sun.j2me.app-descriptor jad;
text/vnd.wap.wml wml;
text/x-component htc;
image/png png;
image/tiff tif tiff;
image/vnd.wap.wbmp wbmp;
image/x-icon ico;
image/x-jng jng;
image/x-ms-bmp bmp;
image/svg+xml svg svgz;
image/webp webp;
application/font-woff woff;
application/font-woff2 woff2;
application/vnd.ms-fontobject eot;
application/x-font-ttf ttc ttf;
application/x-httpd-php php;
application/x-shockwave-flash swf;
application/json json;
application/octet-stream flv; #這邊可以設定MINE TYPE
}
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-service
port:
name: http
這樣子就可以正確的於ingress處理串流的連接了!
相關官方說明: Annotations – Ingress-Nginx Controller、Custom Headers – Ingress-Nginx Controller
