# Inconsistent Load Balancing Behavior When Using Kong in Kubernetes Cluster **URL:** \ **Category:** Questions\ **Tags:** kubernetes\ **Created:** [January 22, 2024, 11:33am UTC](https://discuss.konghq.com/t/inconsistent-load-balancing-behavior-when-using-kong-in-kubernetes-cluster/12305 "2024-01-22T11:33:34Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![takahashi-jo](https://avatars.discourse-cdn.com/v4/letter/t/77aa72/32.png) [@takahashi-jo](https://discuss.konghq.com/u/takahashi-jo)\ **Post date:** [January 22, 2024, 11:33am UTC](https://discuss.konghq.com/t/inconsistent-load-balancing-behavior-when-using-kong-in-kubernetes-cluster/12305/1 "2024-01-22T11:33:35Z")
Hello Kong Community, I’m experiencing an issue with load balancing in my Kubernetes environment where Kong is being used as an API gateway. While direct curl requests to the Kubernetes service are properly load balanced in a round-robin fashion, requests routed through Kong are not being evenly distributed among pods. **Environment:** - Kubernetes version: v1.25.11-eks-a5565ad - Kong version: 3.1.1 - Nginx version: openresty/1.21.4.1 - Deployment strategy: kong is deployed as a NodePort Service. **Issue Description:** - When making direct requests to the Kubernetes service (e.g., `curl http://service-name.namespace.svc.cluster.local`), the load is evenly distributed among all available pods, indicating that kube-proxy’s round-robin configuration is functioning correctly. - However, when requests are routed through Kong (e.g., `curl -H "Host: example.com" http://:`), they are not evenly distributed. Instead, requests seem to be directed towards a single pod for a certain duration before switching to another pod. **Troubleshooting Steps Taken:** - Checked the Kong upstream configuration, which is set to round-robin. - Inspected the `nginx-kong.conf` to ensure no custom load balancing settings are applied. - Increased the log level of Kong and reviewed the logs, but did not find any obvious issues related to load balancing decisions. **Questions:** 1. Could there be a configuration within Kong or its underlying Nginx setup that might be causing this uneven load distribution? 2. Are there known issues or behaviors in Kong that could lead to such a scenario, particularly when integrated within a Kubernetes cluster? 3. Any suggestions on further steps to diagnose or resolve this issue would be greatly appreciated. I have attached relevant configuration files for reference. Any help or guidance on this matter would be immensely helpful. Thank you in advance for your assistance! Best regards, takahashi-jo * * * kong > SERVICE > { > “connect\_timeout”: 60000, > “read\_timeout”: 60000, > “name”: “namespace.service-name.service-name.80”, > “tls\_verify”: null, > “tls\_verify\_depth”: null, > “host”: “service-name.namespace.80.svc”, > “created\_at”: 1705654718, > “updated\_at”: 1705654718, > “tags”: [ > “managed-by-ingress-controller” > ], > “ca\_certificates”: null, > “id”: “92a44563-bff4-42f5-8fba-2c72d8be8360”, > “protocol”: “http”, > “enabled”: true, > “port”: 80, > “path”: “/”, > “client\_certificate”: null, > “write\_timeout”: 60000, > “retries”: 5 > } > ROUTE > { > “hosts”: [ > “[example.com](http://example.com)” > ], > “path\_handling”: “v0”, > “service”: { > “id”: “92a44563-bff4-42f5-8fba-2c72d8be8360” > }, > “name”: “namespace.service-name.service-name.example.com.80”, > “strip\_path”: true, > “snis”: null, > “created\_at”: 1705654877, > “updated\_at”: 1705654877, > “request\_buffering”: true, > “paths”: [ > “/api/example” > ], > “methods”: null, > “sources”: null, > “id”: “33af07d8-e844-4d19-b7e0-2fdec963a236”, > “preserve\_host”: true, > “tags”: [ > “managed-by-ingress-controller” > ], > “headers”: null, > “destinations”: null, > “protocols”: [ > “http”, > “https” > ], > “https\_redirect\_status\_code”: 426, > “regex\_priority”: 0, > “response\_buffering”: true > } > UPSTREAM > { > “hash\_on\_query\_arg”: null, > “hash\_on\_uri\_capture”: null, > “hash\_on\_cookie”: null, > “hash\_on\_cookie\_path”: “/”, > “hash\_fallback”: “none”, > “slots”: 10000, > “algorithm”: “round-robin”, > “hash\_fallback\_uri\_capture”: null, > “client\_certificate”: null, > “host\_header”: null, > “id”: “ab44cadd-697a-45d5-bc09-d94be3ba18f5”, > “created\_at”: 1705651412, > “tags”: [ > “managed-by-ingress-controller” > ], > “hash\_fallback\_header”: null, > “healthchecks”: { > “active”: { > “type”: “http”, > “concurrency”: 10, > “healthy”: { > “interval”: 0, > “successes”: 0, > “http\_statuses”: [ > 200, > 302 > ] > }, > “headers”: null, > “http\_path”: “/”, > “https\_sni”: null, > “https\_verify\_certificate”: true, > “timeout”: 1, > “unhealthy”: { > “http\_statuses”: [ > 429, > 404, > 500, > 501, > 502, > 503, > 504, > 505 > ], > “tcp\_failures”: 0, > “timeouts”: 0, > “interval”: 0, > “http\_failures”: 0 > } > }, > “passive”: { > “healthy”: { > “successes”: 0, > “http\_statuses”: [ > 200, > 201, > 202, > 203, > 204, > 205, > 206, > 207, > 208, > 226, > 300, > 301, > 302, > 303, > 304, > 305, > 306, > 307, > 308 > ] > }, > “unhealthy”: { > “http\_statuses”: [ > 429, > 500, > 503 > ], > “tcp\_failures”: 0, > “timeouts”: 0, > “http\_failures”: 0 > }, > “type”: “http” > }, > “threshold”: 0 > }, > “hash\_on”: “none”, > “name”: “service-name.namespace.80.svc”, > “use\_srv\_name”: false, > “hash\_on\_header”: null, > “hash\_fallback\_query\_arg”: null > } * * * kubernetes > kube-proxy config > apiVersion: [kubeproxy.config.k8s.io/v1alpha1](http://kubeproxy.config.k8s.io/v1alpha1) > bindAddress: 0.0.0.0 > clientConnection: > acceptContentTypes: “” > burst: 10 > contentType: application/vnd.kubernetes.protobuf > kubeconfig: /var/lib/kube-proxy/kubeconfig > qps: 5 > clusterCIDR: “” > configSyncPeriod: 15m0s > conntrack: > maxPerCore: 32768 > min: 131072 > tcpCloseWaitTimeout: 1h0m0s > tcpEstablishedTimeout: 24h0m0s > enableProfiling: false > healthzBindAddress: 0.0.0.0:10256 > hostnameOverride: “” > iptables: > masqueradeAll: false > masqueradeBit: 14 > minSyncPeriod: 0s > syncPeriod: 30s > ipvs: > excludeCIDRs: null > minSyncPeriod: 0s > scheduler: “rr” > syncPeriod: 30s > kind: KubeProxyConfiguration > metricsBindAddress: 127.0.0.1:10249 > mode: “ipvs” > nodePortAddresses: null > oomScoreAdj: -998 > portRange: “” > udpIdleTimeout: 250ms > Service > apiVersion: v1 > kind: Service > metadata: > annotations: > … > creationTimestamp: “2024-01-19T04:45:40Z” > labels: > … > name: service-name > namespace: namespace > resourceVersion: “152616687” > uid: 2024579a-74ab-4a29-8bac-49c4d387d397 > spec: > clusterIP: 172.20.253.250 > clusterIPs: - 172.20.253.250 internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: http port: 80 protocol: TCP targetPort: 80 selector: app: service-name version: v1 sessionAffinity: None type: ClusterIP status: loadBalancer: {}