minikube 内部服务之间的请求分布不均匀

如何解决minikube 内部服务之间的请求分布不均匀

我在 minikube 中部署了 2 个不同的微服务作为后端，分别称为部署 A 和部署 B。这两个部署都有不同的 pod 副本在运行。

部署 B 作为服务 B 公开。部署 A 的 Pod 通过 ClusterIP 类型的服务 B 调用部署 B 的 Pod。

部署 B 的 Pod 有一个在其中运行的 scrapyd 应用程序，并在其中部署了抓取蜘蛛。每个 celery worker（部署 A 的 pods）从 redis 队列中获取一个任务并调用 scrapyd 服务来调度蜘蛛。

一切正常，但在我扩展应用程序（分别部署 A 和 B）后，我观察到资源消耗不均匀，使用 kubectl top pods 我观察到部署 B 的一些 pod 根本没有使用。我观察到的模式是，只有部署 B 的那些 Pod 在部署 A 的所有 Pod 启动后才启动并运行，永远不会被使用。

这是正常行为吗？我怀疑部署 A 和 B 的 Pod 之间的连接是持久的 我很困惑为什么部署 B 的 Pod 处理的请求不是均匀分布的？很抱歉这个幼稚的问题。我是这个领域的新手。

部署 A 的清单是：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: celery-worker
  labels:
    deployment: celery-worker
spec:
  replicas: 1
  selector:
    matchLabels:
      pod: celery-worker
  template:
    metadata:
      labels:
        pod: celery-worker
    spec:
      containers:
        - name: celery-worker
          image: celery:latest
          imagePullPolicy: Never
          command: ['celery','-A','mysite','worker','-E','-l','info',]
          resources:
            limits:
              cpu: 500m
            requests:
              cpu: 200m
      terminationGracePeriodSeconds: 200

而部署 B 是

apiVersion: apps/v1
kind: Deployment
metadata:
  name: scrapyd
  labels:
    app: scrapyd
spec:
  replicas: 1
  selector:
    matchLabels:
      pod: scrapyd
  template:
    metadata:
      labels:
        pod: scrapyd
    spec:
      containers:
        - name: scrapyd
          image: scrapyd:latest
          imagePullPolicy: Never
          ports:
            - containerPort: 6800
          resources:
            limits:
              cpu: 800m
            requests:
              cpu: 800m
      terminationGracePeriodSeconds: 100

---
kind: Service
apiVersion: v1
metadata:
  name: scrapyd
spec:
  selector:
    pod: scrapyd
  ports:
  - protocol: TCP
    port: 6800
    targetPort: 6800

kubectl top pods 的输出：

解决方法

所以我想出的上述问题的解决方案如下：

在当前设置中，使用此链接安装 linkerd。 Linkerd Installation in Kubernetes

之后将 linkerd 代理注入 celery 部署中，如下所示：

cat celery/deployment.yaml | linkerd inject - | kubectl apply -f -

这确保了来自 celery 的请求首先传递到这个代理，然后在 L7 层直接负载均衡到scrapy。在这种情况下，kube-proxy 被绕过，L4 上的默认负载平衡不再起作用。