3 回答

TA貢獻(xiàn)1886條經(jīng)驗(yàn) 獲得超2個(gè)贊
您正在使用 NodePort 公開(kāi)服務(wù),因此沒(méi)有反向代理,但您直接連接到您的 Pod。這是一個(gè)不錯(cuò)的選擇。(稍后您可能想使用 Ingress)
您看到的是只有一個(gè) Pod 處理您的請(qǐng)求。您希望每個(gè)請(qǐng)求都負(fù)載均衡到不同的 pod。你的假設(shè)是正確的,但是負(fù)載均衡不是發(fā)生在HTTP請(qǐng)求層,而是發(fā)生在TCP層。
因此,當(dāng)您擁有持久的 TCP 連接并重新使用它時(shí),您將不會(huì)體驗(yàn)到您期望的負(fù)載平衡。由于建立 TCP 連接的延遲時(shí)間相當(dāng)昂貴,因此通常會(huì)進(jìn)行優(yōu)化以避免重復(fù)打開(kāi)新的 TCP 連接:HTTP keep-alive。
大多數(shù)框架和客戶(hù)端默認(rèn)啟用 Keep Alive,Go 也是如此。嘗試s.SetKeepAlivesEnabled(false)
看看是否可以解決您的問(wèn)題。(僅推薦用于測(cè)試?。?/p>
您還可以使用多個(gè)不同的客戶(hù)端,通過(guò)命令行使用curl 或在Postman 中禁用keep-alive。

TA貢獻(xiàn)1993條經(jīng)驗(yàn) 獲得超6個(gè)贊
在 Kubernetes 集群中,發(fā)送到 k8s 服務(wù)的請(qǐng)求通過(guò)kube-proxy進(jìn)行路由。
默認(rèn)kube-proxy
模式是Iptalbles
從 Kubernetes v1.2 開(kāi)始的,它允許服務(wù)和后端 Pod 之間更快的數(shù)據(jù)包解析。后端 Pod 之間的負(fù)載平衡直接通過(guò)iptables rules
.
也許您沒(méi)有生成足夠的負(fù)載,而一個(gè) pod 無(wú)法處理,這就是您從 路由到同一個(gè) pod 的原因kube-proxy
。

TA貢獻(xiàn)1890條經(jīng)驗(yàn) 獲得超9個(gè)贊
我嘗試使用請(qǐng)求標(biāo)頭,它解決了負(fù)載平衡問(wèn)題,其中所有請(qǐng)求僅命中單個(gè)副本,而對(duì)于演示或測(cè)試,能夠?qū)⒄?qǐng)求分發(fā)到所有副本非常有用
連接:保持活動(dòng) 連接:關(guān)閉
該請(qǐng)求總是到達(dá)同一個(gè) pod
curl?-H?"Connection:?keep-alive"?http://your-service:port/path
但是,使用close
,請(qǐng)求會(huì)平衡到所有 pod
curl?-H?"Connection:?close"?http://your-service:port/path
- 3 回答
- 0 關(guān)注
- 244 瀏覽
添加回答
舉報(bào)