Działanie LoadBalancer¶
Komponent ten działa jako "wejście" na usługi wewnątrz klastra z użyciem jednego adresu IP lub nazwy domenowej. Wystawia produkcyjnie aplikację, gotową do użytkowania.
Potrzebne jest jedynie zdefiniowanie uprzednio, przed stworzeniem takiego komponentu na klastrze Load balancera jako usługa chmurowa lub self-hostowany Metallb, lub inny Load Balancer wspierany przez Kubernetes.
Możliwość rozrzucania ruchu pomiędzy replikami na klastrze. Robimy to z użyciem zewnętrznego Load Balancera, przykładowo chmurowego. Na on-prem możemy do tego użyć Metallb, który działa jako kontroler w klastrze.
Schemat LoadBalancer¶

LoadBalancer w manifescie¶
Rozpisane zmienne manifestu LoadBalancera¶
service-definition.yaml:
apiVersion: v1
kind: Service
metadata:
name: <service_name>
spec:
type: LoadBalancer
ports:
- targetPort: <port_on_pods> # (1) (optional)
port: <port_on_service> # (2) (!mandatory)
nodePort: <port_on_node> # (3) (optional)
protocol: TCP # (optional), possible values: TCP,UDP, SCTP
selector:
<label_key>:<label_value>
targetPort- (optional) port na Podzie (lub Pod'ach), jeśli nie zostanie podany - brany ten sam port co w sekcjiportport- port na Service, to na nim nasłuchuje LoadBalancernodePort- (optional) wystawiany port na Nodzie, jeśli nie jest jawnie podany - wybierany losowo z zakresu 30000 - 32767
Service LoadBalancer w pliku yaml¶
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
type: LoadBalancer
ports:
- port: 80 # port na service
targetPort: 8080 # port na podach
selector:
app: nginx-app-pod
Bardzo podobnie to działa do Service NodePort. Jeżeli nie chcemy, żeby wszystkie IP węzłów Kubernetes były dostępne na zewnątrz, albo bawić się z HAProxy, nginx możemy tą opcję zastosować. Wtedy zewnętrzny dostawca chmurowy udostępnia taki Load Balancer i się do niego wpinamy klastrem.
Podsumowując: aplikacja jest uruchomiona na Podach na portach 8080, a my wystawiamy Service na porcie 80.