我使用的是Kubernetes,RKE2,有3个主节点和10个工作节点。在我的实现中,我有一个API路由,它需要花费3分钟进行计算。事实证明,我并行调用这条路线的次数越多,得到答案所需的时间就越长。有时候,它所花费的时间甚至比串行调用路由所花费的时间还要长。根据我的观察,请求在pod之间的分布并不均匀。如果我发出20个请求并有20个服务pod,则只使用6或7个pod,有些pod接收2,3甚至4个请求。显然,收到3个和4个请求的pod会花费更多的时间来返回答案。这个链接How to distribute requests to pods on a Kubernetes service澄清了负载平衡应该如何以及什么是循环调度的问题,但显然我的集群没有按照它应该的方式运行。据我所知,20个pod和20个几乎同时发生的请求的默认行为应该是每个pod一个请求。几个星期来我一直在努力治疗这个问题,但没有成功。我希望有更多Kubernetes经验的人可以帮助我和社区中有同样问题的其他人。
遵循kubernetes上的yaml部署
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: alignment-pvc
namespace: development
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi
volumeName: alignment-pv-dev
storageClassName: longhorn-static
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: alignment-deployment
namespace: development
labels:
version: v1
app: alignment
spec:
replicas: 1
selector:
matchLabels:
app: alignment
template:
metadata:
labels:
app: alignment
spec:
nodeName: m21429.contaboserver.net
containers:
- image: joaollr/alignment:75819c1d8168f5187165d9f79a1af8cde27b47d4
imagePullPolicy: Always
name: alignment
ports:
- containerPort: 8000
envFrom:
- configMapRef:
name: core-config
resources:
requests:
memory: "1Gi"
cpu: "0.2"
limits:
memory: "15Gi"
cpu: "4"
volumeMounts:
- mountPath: /data
name: alignment-pvc
- mountPath: /raster
name: raster-pvc
- mountPath: /vector
name: vector-pvc
imagePullSecrets:
- name: regcred
volumes:
- name: alignment-pvc
persistentVolumeClaim:
claimName: alignment-pvc
- name: raster-pvc
persistentVolumeClaim:
claimName: raster-pvc
readOnly: true
- name: vector-pvc
persistentVolumeClaim:
claimName: vector-pvc
readOnly: true
---
apiVersion: v1
kind: Service
metadata:
name: alignment-service
namespace: development
labels:
app: alignment
service: alignment
spec:
ports:
- name: http
port: 8000
selector:
app: alignment
1条答案
按热度按时间but5z9lq1#
Kubernetes服务分发(通常)由
kube-proxy
执行。kube-proxy
有两种“模式”:iptables和ipv。“iptables”是默认值,使用随机分布。必须明确选择“ipvs”,并默认使用轮询(rr)。因此,首先尝试切换到proxy-mode=ipvs。但是...
这并不简单,因为每个节点上的kube-proxy示例都是独立工作的。这意味着在节点A上分发的请求可以选择与在节点B上分发的请求相同的目标。因此,只有当所有请求都分布在同一个节点上时,您才会获得完美的循环。如果您的流量来自外部源并进入 * 一个 * 节点(即无ECMP)。
一些CNI插件,如Cilium或Antrea,可以选择绕过
kube-proxy
并以自己的方式进行服务分发。你应该检查一下你的系统中是否存在这种情况。