Clarify if requests are actually load balanced to different replicas w/o a load balancer in the service.yaml file

[RS1999ent]

Yesterday, we discussed that the loadbalancer = {} field in the -service.yaml files for different services specifies a load balancer to use when sending requests to different pod replicas. Since this field in empty in hotel reservation, it isn't clear that requests would be load balanced even if we have multiple replicas.

It'd be good to clarify this and figure out how to load balance traffic.

[RoyZhang7]

Based on this k8s load balancing doc and another, there are several ways to balance loads; and the default (also simplest one) is to use the built-in virtual IP and services proxies in k8s by making a service ClusterIP type.
All services in HotelResevation are of type ClusterIP:

kubectl get services --all-namespaces
NAMESPACE     NAME                        TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)                                                                       AGE
default       consul                      ClusterIP   192.168.160.136   <none>        8300/TCP,8400/TCP,8500/TCP,8600/UDP                                           86m
default       frontend                    ClusterIP   192.168.232.103   <none>        5000/TCP                                                                      86m
default       geo                         ClusterIP   192.168.222.69    <none>        8083/TCP                                                                      86m
default       jaeger                      ClusterIP   192.168.245.20    <none>        14269/TCP,5778/TCP,14268/TCP,14267/TCP,16686/TCP,5775/UDP,6831/UDP,6832/UDP   86m
default       kubernetes                  ClusterIP   192.168.128.1     <none>        443/TCP                                                                       91m
default       memcached-profile           ClusterIP   192.168.226.34    <none>        11211/TCP                                                                     86m
default       memcached-rate              ClusterIP   192.168.194.227   <none>        11211/TCP                                                                     86m
default       memcached-reserve           ClusterIP   192.168.207.29    <none>        11211/TCP                                                                     86m
default       mongodb-geo                 ClusterIP   192.168.171.150   <none>        27017/TCP                                                                     86m
default       mongodb-profile             ClusterIP   192.168.252.227   <none>        27017/TCP                                                                     86m
default       mongodb-rate                ClusterIP   192.168.242.153   <none>        27017/TCP                                                                     86m
default       mongodb-recommendation      ClusterIP   192.168.187.154   <none>        27017/TCP                                                                     86m
default       mongodb-reservation         ClusterIP   192.168.210.13    <none>        27017/TCP                                                                     86m
default       mongodb-user                ClusterIP   192.168.156.156   <none>        27017/TCP                                                                     86m
default       profile                     ClusterIP   192.168.182.57    <none>        8081/TCP                                                                      86m
default       rate                        ClusterIP   192.168.173.27    <none>        8084/TCP                                                                      86m
default       recommendation              ClusterIP   192.168.181.84    <none>        8085/TCP                                                                      86m
default       reservation                 ClusterIP   192.168.164.9     <none>        8087/TCP                                                                      86m
default       search                      ClusterIP   192.168.158.246   <none>        8082/TCP                                                                      86m
default       user                        ClusterIP   192.168.215.96    <none>        8086/TCP                                                                      86m

In summary, all services in hotelreservation are of type ClusterIP, which means they're using the built-in proxy mechanism (kube-proxy) for internal load balancing. When a pod makes a request to a service's ClusterIP, kube-proxy intercepts this incoming request. It then load-balances the request across all the pods that are endpoints of that service, which is normally configured using round-robin in kube-proxy's iptables or ipvs mode.

kubectl get configmap kube-proxy -n kube-system -o yaml
apiVersion: v1
data:
  config.conf: |-
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    bindAddress: 0.0.0.0
    bindAddressHardFail: false
    clientConnection:
      acceptContentTypes: ""
      burst: 10
      contentType: application/vnd.kubernetes.protobuf
      kubeconfig: /var/lib/kube-proxy/kubeconfig.conf
      qps: 5
    clusterCIDR: 192.168.0.0/17
    configSyncPeriod: 15m0s
    conntrack:
      maxPerCore: 32768
      min: 131072
      tcpCloseWaitTimeout: 1h0m0s
      tcpEstablishedTimeout: 24h0m0s
    detectLocal:
      bridgeInterface: ""
      interfaceNamePrefix: ""
    detectLocalMode: ""
    enableProfiling: false
    featureGates:
      EphemeralContainers: true
    healthzBindAddress: 0.0.0.0:10256
    hostnameOverride: node-0
    iptables:
      masqueradeAll: false
      masqueradeBit: 14
      minSyncPeriod: 0s
      syncPeriod: 30s
    ipvs:
      excludeCIDRs: []
      minSyncPeriod: 0s
      scheduler: rr
      strictARP: true
      syncPeriod: 30s
      tcpFinTimeout: 0s
      tcpTimeout: 0s
      udpTimeout: 0s
    kind: KubeProxyConfiguration
    metricsBindAddress: 127.0.0.1:10249
    mode: ipvs
    nodePortAddresses: []
    oomScoreAdj: -999
    portRange: ""
    showHiddenMetricsForVersion: ""
    udpIdleTimeout: 250ms
    winkernel:
      enableDSR: false
      forwardHealthCheckVip: false
      networkName: ""
      rootHnsEndpointName: ""
      sourceVip: ""
  kubeconfig.conf: |-
    apiVersion: v1
    kind: Config
    clusters:
    - cluster:
        certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        server: https://127.0.0.1:6443
      name: default
    contexts:
    - context:
        cluster: default
        namespace: default
        user: default
      name: default
    current-context: default
    users:
    - name: default
      user:
        tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
kind: ConfigMap
metadata:
  creationTimestamp: "2024-08-09T00:33:01Z"
  labels:
    app: kube-proxy
  name: kube-proxy
  namespace: kube-system
  resourceVersion: "568"
  uid: fcbac5f5-dd77-4d91-a8a8-5ca62667dcfc

This is the kube-proxy configmap from hotelreservation. We can see mode: ipvs, ipvs: scheduler: rr strictARP: true syncPeriod: 30s, indicating 1) The scheduler is set to "rr" (round-robin), which means requests are distributed evenly across all pods backing a service, 2) strictARP is enabled, which helps in scenarios with floating IPs, and 3) syncPeriod of 30s means IPVS rules are synced every 30 seconds.

[RoyZhang7]

I think we can close this issue.