Kubernetes HA Setup

  • Hallo,


    mich würde mal interessieren wie ihr einen kleinen HA fähigen Kubernetes Cluster bei Netcup dimensionieren würdet.


    Auf dem Cluster sollen ein paar Anwendungen laufen, die jeweils 2-4 GB Speicher belegen.


    Kann man etcd plus Controlplane auf einen RS 1000 packen (und davon dann drei Stück wegen HA)? Dazu würden sich dann mindestens drei Workernodes gesellen, dachte an RS 2000-4000.


    Oder würdet ihr ein anderes Setup vorschlagen?



    Viele Grüße

    Volker

  • So richtig HA geht meiner Meinung nach mit Netcup nicht, da man nicht schnell genug und automatisiert die ölffentliche IP-Adresse des Clusters (müsste dann eine Failover-IP sein) umswitchen kann - jedenfalls habe ich das bisher nicht geschafft. Sollte jemand dafür eine Lösung haben... gerne her damit.


    Was bei Netcup dafür noch fehlt wäre ein managed LoadBalancer, so wie es da beim roten H gibt.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Habe 3 Master im Einsatz die über ein CloudVLAN miteinander kommunizieren. Nach außen hin switche ich die FailoverIP, das ist <20 Sekunden eigentlich erledigt. Das passiert automatisch über Keepalived was Checks ausführt. Bspw wenn ich eine Node tainte, dann wird die IP verschoben.


    Schneller geht`s beim Loadbalancer auch nicht unbedingt, es sei denn man hat sekündliche Healthchecks. VPS500 sollte reichen, wichtig ist auf jeden Fall ne 2C Maschine.

  • Kubernetes API Check-Skript: (Vorher entsprechenden Service Account / RBAC anlegen)


    Bash
    #!/bin/bash
    TOKEN=XXXX
    [ -z $(curl -m 2 -s -f -H "Authorization: Bearer $TOKEN" -k "https://localhost:6443/api/v1/nodes/$HOSTNAME" | jq -r '.spec.unschedulable | select(.==true)') ] && exit 0 || exit 1

    Das rumschieben über die SOAP API absolvieren dann zwei Shellskript die als Daemon auf dem System laufen und von keepalived benachrichtigt werden.


    Die Keepalived Konfiguration beinhaltet sowohl eine IPv4 als auch eine IPv6 Floating IP, welche über die gleiche Keepalived Instanz verwaltet werden, daher die etwas komische "virtual_ipaddress_excluded" Notation.

  • Habe 3 Master im Einsatz die über ein CloudVLAN miteinander kommunizieren. Nach außen hin switche ich die FailoverIP, das ist <20 Sekunden eigentlich erledigt. Das passiert automatisch über Keepalived was Checks ausführt. Bspw wenn ich eine Node tainte, dann wird die IP verschoben.


    Schneller geht`s beim Loadbalancer auch nicht unbedingt, es sei denn man hat sekündliche Healthchecks. VPS500 sollte reichen, wichtig ist auf jeden Fall ne 2C Maschine.

    Zum Verständnis: wo läuft der HA Proxy? Ist das auf dem Kubernetes Node wo etcd bzw. die Controlplane läuft? Oder läuft der innerhalb vom Kubernetes als Pod? Was läuft alles auf dem Master?

  • So richtig HA geht meiner Meinung nach mit Netcup nicht, da man nicht schnell genug und automatisiert die ölffentliche IP-Adresse des Clusters (müsste dann eine Failover-IP sein) umswitchen kann - jedenfalls habe ich das bisher nicht geschafft. Sollte jemand dafür eine Lösung haben... gerne her damit.

    Ich habe auch ein Setup mit keepalived, das eine IPv4 und IPv6 Failover umschwenkt. Allerdings noch nicht mit Kubernetes zusammen. Manchmal dauert das Umschalten und ich musste für meine Anwendung Optimierungen einbauen, damit es zu keinem Nodeflapping (und damit längeren Downtimes) gibt.

  • Zum Verständnis: wo läuft der HA Proxy? Ist das auf dem Kubernetes Node wo etcd bzw. die Controlplane läuft? Oder läuft der innerhalb vom Kubernetes als Pod? Was läuft alles auf dem Master?

    Der HAProxy läuft als Pod in Kubernetes, exposed aber per Konfiguration verschiedene Ports. Auf den Nodes / Workern läuft aber auch ein HAProxy der die Kubernetes API von den Master loadbalanced. Deswegen macht das Umschalten der Floating IP auch gar nichts im Cluster selbst sondern dadurch ist "nur" die Verbindung von draußen an die FloatingIP unterbrochen. Das der Ingress aber auch auf allen Nodes auf alle Requests reagiert und sie weiterleitet, kann jede beliebige Node auch bspw per "/etc/hosts" angesprochen werden.

  • Der HAProxy läuft als Pod in Kubernetes, exposed aber per Konfiguration verschiedene Ports. Auf den Nodes / Workern läuft aber auch ein HAProxy der die Kubernetes API von den Master loadbalanced. Deswegen macht das Umschalten der Floating IP auch gar nichts im Cluster selbst sondern dadurch ist "nur" die Verbindung von draußen an die FloatingIP unterbrochen. Das der Ingress aber auch auf allen Nodes auf alle Requests reagiert und sie weiterleitet, kann jede beliebige Node auch bspw per "/etc/hosts" angesprochen werden.

    Okay, das verstehe ich jetzt.


    Der keepalived läuft aber in dem Fall nicht als pod, oder? Der kann überall laufen, wo der Ingress Endpunkte hat. Die prüft der keepalived. Falls der master nicht mehr healthy ist, würde also einfach der nächste übernehmen, die IP umschalten und dann sind alle Ports direkt wieder erreichbar, nur eben auf dem anderen Node.

  • Okay, das verstehe ich jetzt.


    Der keepalived läuft aber in dem Fall nicht als pod, oder? Der kann überall laufen, wo der Ingress Endpunkte hat. Die prüft der keepalived. Falls der master nicht mehr healthy ist, würde also einfach der nächste übernehmen, die IP umschalten und dann sind alle Ports direkt wieder erreichbar, nur eben auf dem anderen Node.

    Soweit korrekt. Keepalived läuft auf der Node selber tatsächlich, konfiguriert / installiert per Ansible. Ich habe 3 Master. Die Worker Nodes sprechen immer lokal gegen einen HAProxy, der als Backends alle 3 API Endpunkte der Master hat.


    Wenn jetzt Master 1 ausfällt, kratzt den Worker das nicht, weil er über den HAProxy immer noch mit den beiden anderen Mastern sprechen kann (loadbalanced API). Soweit zum Cluster internen Ablauf.


    Externer Ablauf:

    - Sowohl die IPv4 als auch die IPv6 werden über die Shellskripte umgeschaltet. Die IP Konfiguration ist in Keepalived hinterlegt, sodass nur der aktive Master auch wirklich die Floating IP auf dem Interface konfiguriert hat. In dem Moment wo ich keepalived beende, verschwindet auch die FloatingIP vom Interface, falls die Node Master war. Die Shellskripte prüfen jede Minute den Status von Keepalived und falls die Node Master ist, wird zusätzlich geprüft ob der Node die Floating IP zugewiesen ist. Falls nicht, wird diese zugewiesen. Dies trifft sowohl auf die Kubernetes API IP zu, als auch die Ingress IP über welche ich dann meine Seiten erreiche.


    Bis auf die bereits erwähnten ca. 20 Sekunden fällt es mir nicht aktiv auf, wenn die IP rumgeschoben wird. Mein externes Monitoring prüft alle Seiten im 30 Sekundentakt und selbst dort ist es selten zu sehen. Mittlerweile hab ich auch in Icinga2 ein dynamisches Monitoring Skript für keepalived:

    - prüfe ob Node master ist (keepalived status)

    - Falls master. sind die FlaotingIPs auf dem Interface up

    - Falls slave, Node sollte keine FloatingIP haben


    Gruß

  • Hallo,

    vielen Dank für die super Erklärung des HA Setup für die ControlPlane


    aber wie macht ihr das mit Kubernetes LoadBalancern / Ingress im HA Umfeld?

    wie kriege ich den Traffic von example.org auf meinem Frontend Service im Cluster?


    Zeigt eure Frontend Domain dann per DNS auf die Failover IPv4? und die Master übernehmen das Routing per NGINX Ingress Controller? oder gebt ihr euch über BareMetal LoadBalancer wie MetalLB dann die Failover IP manuell?

    Wie genau habt ihr das eingerichtet?

    Es macht ja keinen Sinn einen speziellen Worker manuell anzusprechen per DNS von example.org, wenn ich HA haben will :D


    Lieber Gruss

  • Mahlzeit,

    bitte sehr.

    Zeigt eure Frontend Domain dann per DNS auf die Failover IPv4? und die Master übernehmen das Routing per NGINX Ingress Controller?

    Jein. Es müssen nicht unbedingt die master sein, sondern die "Ingress" Nodes. In meinem Fall erledigt HAProxy das. Alle Dienste sind von allen Ingress Nodes erreichbar. Ich kann also auch meiner /etc/hosts den Domaineintrag gegen die Adresse eines Worker tauschen und erreiche trotzdem weiterhin alle Dienste. Das ist auch tatsächlich der DNS Fallback vom Anbieter, wenn die Failover IP doch mal nicht tut.


    Gruß