Answers: <p>Suddenly found the answer with ipvs.</p>
  <p>All that had to be done was put kube-proxy in ipvs mode with rr (roundrobin) scheduler.</p>
  <pre><code>kubectl -n kube-system edit cm kube-proxy
  
  scheduler: &quot;rr&quot;
  mode: ipvs
  </code></pre>
  <p>Then restart kube-proxy and we have proper loadbalancing</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-09-09T06:39:39.077Z
Answers: 2021-09-09T06:39:39.077Z
Answers: Serve Laurijssen
Answers: <p>If you're trying to use a NodePort, then your Service type should be NodePort.</p>
  <pre><code>     nodePort: 32001
       type: NodePort      #(not LoadBalancer)
  </code></pre>
  <p>It is my understanding that the LoadBalancer type is essentially built for cloud environments where the cloud provider provides a load balancer.  You are NOT creating a load balancer by creating a LoadBalancer Service type.  The load balancer is a separate thing.  The Cluster type is <em>supposed</em> to load balance internally, but I haven't been able to produce that behavior reliably.  Options for the integrated load balancer to work with LoadBalancer type, on premise, seem to be incredibly limited.  You can use a standard load balancer, like HAProxy, outside the cluster environment, with NodePort type on the backend.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-09-03T05:44:07.587Z
Answers: yeah it seems so that it's limited. Thinking of creating a simple python script which round robins through the ip's of the cluster myself
Answers: Serve Laurijssen
Answers: CC BY-SA 4.0
Answers: 2021-09-02T15:50:57.680Z
Answers: 2021-09-02T15:50:57.680Z
Answers: Adam Winter
Body: <p>I've got a service running in an on premise k8s environment. It is basically an nginx image, and a call takes like 10 seconds.
  replicas is two and of course two pods are running. But almost if not every call goes to one pod, queueing up calls. If there's many calls they just wait until all of them are ready, not a single one goes to the other pod.</p>
  <pre><code>apiVersion: v1
  kind: Service
  metadata:
   name: revproxy-svc
  spec:
   selector:
     role: app
   ports:
     - protocol: TCP
       port: 80
       targetPort: 80
       nodePort: 32001
   type: LoadBalancer
   externalName: my.domain.nl 
  
  ---
  
  apiVersion: apps/v1
  kind: Deployment
  metadata:
   name: proxy-deployment 
   labels:
     role: app
  spec:
   replicas: 2
   selector:
     matchLabels:
       role: app
   template:
     metadata:
       labels:
         role: app
     spec: 
       containers:
       - name: web
         image: &quot;10.203.32.90:5000/myproxy&quot;
         resources:
          requests:
            cpu: 500m
         env:
          - name: NODE_IP
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP
         imagePullPolicy: Always
  </code></pre>
  <p>What do we need to config to set up proper loadbalancing?</p>
  
Comments: CC BY-SA 4.0
Comments: 2021-09-01T13:00:32.013Z
Comments: Are you using a cloud based Kubernetes ? If so, you should troubleshoot on the cloud provider level.
Comments: Hedi Nasr
Comments: CC BY-SA 4.0
Comments: 2021-09-01T13:14:01.853Z
Comments: forgot to mention, its on premise
Comments: Serve Laurijssen
Tags: <docker><kubernetes>
Title: k8s pods not load balanced
UserDisplayName: Serve Laurijssen
ThreadText: # k8s pods not load balanced
  
  (Asked by: username_0 on 2021-09-01)
  
  I've got a service running in an on premise k8s environment. It is basically an nginx image, and a call takes like 10 seconds.
  replicas is two and of course two pods are running. But almost if not every call goes to one pod, queueing up calls. If there's many calls they just wait until all of them are ready, not a single one goes to the other pod.
  
  ```
  apiVersion: v1
  kind: Service
  metadata:
   name: revproxy-svc
  spec:
   selector:
     role: app
   ports:
     - protocol: TCP
       port: 80
       targetPort: 80
       nodePort: 32001
   type: LoadBalancer
   externalName: my.domain.nl 
  
  ---
  
  apiVersion: apps/v1
  kind: Deployment
  metadata:
   name: proxy-deployment 
   labels:
     role: app
  spec:
   replicas: 2
   selector:
     matchLabels:
       role: app
   template:
     metadata:
       labels:
         role: app
     spec: 
       containers:
       - name: web
         image: "10.203.32.90:5000/myproxy"
         resources:
          requests:
            cpu: 500m
         env:
          - name: NODE_IP
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP
         imagePullPolicy: Always
  
  ```
  
  What do we need to config to set up proper loadbalancing?
  
  **Tags:** docker, kubernetes
  
  > **Comments:**
  > **username_1**: Are you using a cloud based Kubernetes ? If so, you should troubleshoot on the cloud provider level.  
  > **username_0**: forgot to mention, its on premise  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2021-09-09. Score: 2 | Accepted answer
  
  Suddenly found the answer with ipvs.
  
  All that had to be done was put kube-proxy in ipvs mode with rr (roundrobin) scheduler.
  
  ```
  kubectl -n kube-system edit cm kube-proxy
  
  scheduler: "rr"
  mode: ipvs
  
  ```
  
  Then restart kube-proxy and we have proper loadbalancing
  
  
  ---
  
  ### Answer by username_2 on 2021-09-02. Score: 2
  
  If you're trying to use a NodePort, then your Service type should be NodePort.
  
  ```
       nodePort: 32001
       type: NodePort      #(not LoadBalancer)
  
  ```
  
  It is my understanding that the LoadBalancer type is essentially built for cloud environments where the cloud provider provides a load balancer. You are NOT creating a load balancer by creating a LoadBalancer Service type. The load balancer is a separate thing. The Cluster type is *supposed* to load balance internally, but I haven't been able to produce that behavior reliably. Options for the integrated load balancer to work with LoadBalancer type, on premise, seem to be incredibly limited. You can use a standard load balancer, like HAProxy, outside the cluster environment, with NodePort type on the backend.
  
  > **Comments:**
  > **username_0**: yeah it seems so that it's limited. Thinking of creating a simple python script which round robins through the ip's of the cluster myself  
  
  ---
  
  