Clarify if requests are actually load balanced to different replicas w/o a load balancer in the service.yaml file
Opened this issue · 2 comments
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.
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 86mIn 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-5ca62667dcfcThis 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.
I think we can close this issue.