【问题标题】:Does ClusterIP service distributes requests between replica pods?ClusterIP 服务是否在副本 pod 之间分配请求?
【发布时间】:2018-02-14 14:10:16
【问题描述】:

你们知道ClusterIP 服务是否在目标部署副本之间分配工作负载吗?

我有 5 个后端副本,其中一个 ClusterIP 服务选择它们。我还有另外 5 个 nginx pod 副本指向这个后端部署。但是当我运行一个繁重的请求时,后端会停止响应其他请求,直到它完成繁重的请求。

更新

这是我的配置:

注意:我已经替换了一些与公司相关的信息。

内容提供者部署:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name:  frontend
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: webapp
        tier: frontend
    spec:
      containers:
      - name:  python-gunicorn
        image:  <my-user>/webapp:1.1.2
        command: ["/env/bin/gunicorn", "--bind", "0.0.0.0:8000", "main:app", "--chdir", "/deploy/app", "--error-logfile", "/var/log/gunicorn/error.log", "--timeout", "7200"]
        resources:
          requests:
            # memory: "64Mi"
            cpu: "0.25"
          limits:
            # memory: "128Mi"
            cpu: "0.4"
        ports:
        - containerPort: 8000
        imagePullPolicy: Always
        livenessProbe:
          httpGet:
            path: /login
            port: 8000
          initialDelaySeconds: 30
          timeoutSeconds: 1200
      imagePullSecrets:
        # NOTE: the secret has to be created at the same namespace level on which this deployment was created
        - name: dockerhub

内容提供服务:

apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    app: webapp
    tier: frontend
spec:
  # type: LoadBalancer
  ports:
  - port: 8000
    targetPort: 8000
  selector:
    app: webapp
    tier: frontend

Nginx 部署:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      volumes:
      - name: secret-volume
        secret:
          secretName: nginxsecret
      - name: configmap-volume
        configMap:
          name: nginxconfigmap
      containers:
      - name: nginxhttps
        image: ymqytw/nginxhttps:1.5
        command: ["/home/auto-reload-nginx.sh"]
        ports:
        - containerPort: 443
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 30
          timeoutSeconds: 1200
        resources:
          requests:
            # memory: "64Mi"
            cpu: "0.1"
          limits:
            # memory: "128Mi"
            cpu: "0.25"
        volumeMounts:
        - mountPath: /etc/nginx/ssl
          name: secret-volume
        - mountPath: /etc/nginx/conf.d
          name: configmap-volume

Nginx 服务:

apiVersion: v1
kind: Service
metadata:
  name: nginxsvc
  labels:
    app: nginxsvc
spec:
  type: LoadBalancer
  ports:
  - port: 80
    protocol: TCP
    name: http
  - port: 443
    protocol: TCP
    name: https
  selector:
    app: nginx

Nginx 配置文件:

server {
    server_name     local.mydomain.com;
    rewrite ^(.*) https://local.mydomain.com$1 permanent;
}

server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        listen 443 ssl;

        root /usr/share/nginx/html;
        index index.html;

        keepalive_timeout    70;
        server_name www.local.mydomain.com local.mydomain.com;
        ssl_certificate /etc/nginx/ssl/tls.crt;
        ssl_certificate_key /etc/nginx/ssl/tls.key;

        location / {
            proxy_pass  http://localhost:8000;
            proxy_connect_timeout       7200;
            proxy_send_timeout          7200;
            proxy_read_timeout          7200;
            send_timeout                7200;
    }
}

【问题讨论】:

  • 是的,ClusterIP 服务分配工作负载

标签: kubernetes


【解决方案1】:

是的,服务类型ClusterIP 使用kube-proxyiptables 规则以round robin 的方式大致均匀地分配请求。

documentation 说:

默认情况下,后端的选择是循环。

虽然,round robin 请求的分布可能会受到以下因素的影响:

  1. 繁忙的后端
  2. 粘性会话
  3. 基于连接(如果后端 pod 已建立 TCP 会话或安全隧道,并且用户多次点击 ClusterIP
  4. 自定义主机级/节点级iptables Kubernetes 外部规则

【讨论】:

  • 你知道request级别的round robin算法吗?还是为了连接级别?一个请求由一个或多个 pod 响应?
  • @Mauricio 支持我的回答,如果您认为它有用,请接受它,以便其他人知道这是正确的答案,谢谢! kubernetes.io/docs/concepts/services-networking/service/…“任何connections 到这个“代理端口”都将被代理到服务的后端 Pod 之一”。如果请求不是基于连接 (UDP),则循环分发发生在请求级别。我在测试中都看到了。
【解决方案2】:

ClusterIP 由kube-proxy 通过 iptables NAT 规则上的概率匹配实现,所以是的,它在支持给定服务的 pod 之间或多或少地平均分配请求。

根据您的后端,这仍然可能导致不太理想的情况,即您的部分请求在其中一个后端被阻止,因为它等待大量请求完成处理。

另外,请记住,这是在连接级别完成的,因此如果您建立了一个连接,然后通过同一个 TCP 连接运行多个请求,它不会在后端之间跳转。

【讨论】:

  • 那么,为什么我的请求在 Pod 处理繁重的请求时没有得到答复?
  • 好吧,对于初学者来说,瓶颈可能在不同的地方,即。 db 表锁。需要详细了解您部署的内容以提供更多提示。
  • 我已更新我的问题以提供更多详细信息。谢谢。
  • nginx应该代理到python服务的集群dns名称,而不是localhost。
猜你喜欢
  • 1970-01-01
  • 2020-02-04
  • 2018-10-28
  • 2021-07-02
  • 2021-03-16
  • 2021-10-27
  • 1970-01-01
  • 1970-01-01
  • 2020-10-11
相关资源
最近更新 更多