如何在kubernetes中平均分配请求数量到pod副本

f4t66c6m  于 2023-06-28  发布在  Kubernetes
关注(0)|答案(1)|浏览(97)

我使用的是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
but5z9lq

but5z9lq1#

Kubernetes服务分发(通常)由kube-proxy执行。kube-proxy有两种“模式”:iptables和ipv。“iptables”是默认值,使用随机分布。必须明确选择“ipvs”,并默认使用轮询(rr)。
因此,首先尝试切换到proxy-mode=ipvs。但是...
这并不简单,因为每个节点上的kube-proxy示例都是独立工作的。这意味着在节点A上分发的请求可以选择与在节点B上分发的请求相同的目标。因此,只有当所有请求都分布在同一个节点上时,您才会获得完美的循环。如果您的流量来自外部源并进入 * 一个 * 节点(即无ECMP)。
一些CNI插件,如Cilium或Antrea,可以选择绕过kube-proxy并以自己的方式进行服务分发。你应该检查一下你的系统中是否存在这种情况。

相关问题