<p>a have a problem with Kubernetes service. My service only sends requests to one pod ignoring other pods. I don't know why and how can I debug it. It should distribute request in a round-robin way. For me, it seems that something's wrong service but I don't know to debug it. Outputs of kubectl describe service and nodes along with endpoints</p>

<pre><code>
apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30002
  selector:
    app: web
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
spec:
  selector:
    matchLabels:
      app: web
  replicas: 3
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web-app
        image: webimage
        ports:
          - containerPort: 80
        imagePullPolicy: Never
        resources:
          limits:
            cpu: "0.5"
          requests:
            cpu: "0.5"


Name:                     web-svc
Namespace:                default
Labels:                   &lt;none&gt;
Annotations:              Selector:  app=webpod
Type:                     NodePort
IP:                       10.111.23.112
Port:                     &lt;unset&gt;  80/TCP
TargetPort:               80/TCP
NodePort:                 &lt;unset&gt;  30002/TCP
Endpoints:                10.244.1.7:80,10.244.1.8:80,10.244.1.9:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   &lt;none&gt;


Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       &lt;none&gt;
Selector:          &lt;none&gt;
Type:              ClusterIP
IP:                10.96.0.1
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         172.18.0.3:6443
Session Affinity:  None
Events:            &lt;none&gt;

Name:         web-depl-5c87b748f-kvtqr
Namespace:    default
Priority:     0
Node:         kind-worker/172.18.0.2
Start Time:   Mon, 04 May 2020 04:20:34 +0000
Labels:       app=webpod
              pod-template-hash=5c87b748f
Annotations:  &lt;none&gt;
Status:       Running
IP:           10.244.1.8
IPs:
  IP:           10.244.1.8
Controlled By:  ReplicaSet/web-depl-5c87b748f
Containers:
  web:
    Container ID:   containerd://8b431d80fd729c8b0d7e16fa898ad860d1a223b3e191367a68e3b65e330fe61a
    Image:          web
    Image ID:       sha256:16a4c5d1a652b1accbacc75807abc1d9a05e2be38115dc8a5f369a04a439fad2
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Mon, 04 May 2020 04:20:36 +0000
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:  500m
    Requests:
      cpu:        500m
    Environment:  &lt;none&gt;
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-c9tgf (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-c9tgf:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-c9tgf
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  &lt;none&gt;
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          &lt;none&gt;
=========
Name:         iweblens-svc
Namespace:    default
Labels:       &lt;none&gt;
Annotations:  endpoints.kubernetes.io/last-change-trigger-time: 2020-05-04T04:20:36Z
Subsets:
  Addresses:          10.244.1.7,10.244.1.8,10.244.1.9
  NotReadyAddresses:  &lt;none&gt;
  Ports:
    Name     Port  Protocol
    ----     ----  --------
    &lt;unset&gt;  80    TCP

Events:  &lt;none&gt;

</code></pre>

Zaharlan
<p>Is the client using a persistent/long-lived connection? Because the service endpoint will only distribute the new connections in a round-robin manner as per your setting. Kubernetes doesn't offer any built-in mechanism to load balance long-lived connections. For long-lived connections, you can handle the load balancing on the client side or use a reverse proxy (service mesh/traefik ingress) which can take care of the load balancing responsibility.</p>
