Kubernetes HA Setup mit Netcup - Frage

  • Hallo,


    Ich hab da mal eine Frage. Durch die Arbeit bin ich beim "roten H" aktuell auf dem Thema Hochverfügbarkeit. Dort ist es dank der Cloud, Terraform und cloud-init recht einfach ein solches Setup aufzusetzen.

    Da ich aber treuer Netcup Kunde bin, überlege ich ein ähnliches Setup auch bei mir aufzusetzen. Allerdings würde ich gerne euer Feedback haben, falls ich etwas übersehen oder nicht richtig verstanden habe:


    Loadbalancer [LB-01] (VPS 500 G8) - Haupt-Loadbalancer

    Loadbalancer [LB-02] (VPS 200 G8) - Failover-Loadbalancer

    Failover IPv4-Adresse => Zeigt auf LB-01, im Falle eines Ausfalls automatischer? Wechsel auf LB-02 - Frage hier, ist das automatisch?
    RKE2 Server [RKE2-S-01, RKE2-S-02, RKE2-S-03] (VPS 500 G8) - Kubernetes Control-Plane, ETCD

    RKE2 Agent [RKE2-A-01] (RS Ostern XXL OST21, vorhanden) - Kubernetes Worker-Node



    LG Tina

  • Hi, bezüglich der Failover IPv4: Soweit ich weiß (kann auch falsch sein) musst du dich da selber um das Routing kümmern. Da geht m.W.n. nichts "automatisch".


    (Du kannst per API die IP hin- und her routen aber das musst du halt schon selber anstoßen, es gibt KEINE Möglichkeit im CCP einzustellen "route auf Server 1 es sei denn der ist offline, dann nimm Server 2")

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Zitat

    So machen Sie Ihre Website hoch verfügbar: Eine Failover-IP lässt sich auf verschiedenen Servern einbinden. Fällt ein Server aus, kann die IP ein anderer Server einbinden.

    Die Failover-IP-Adressen können Sie per Webinterface oder auch per SOAP-Webservice konfigurieren. Fällt ein Server aus, kann die IP so automatisch von einem anderer Server eingebunden werden.

    Das deutet jedenfalls mal darauf hin, dass ein automatischer Wechsel möglich ist.

  • Du hast im Moment nur einen Worker Node aufgelistet. Sind da noch weitere geplant? Sonst könnte man sich den HA LB ja eigentlich auch gleich sparen. Wenn es noch weitere geben sollte, wie willst du das mit dem Storage machen? Normalerweise brauchst du hier ja einen Storage as a Service oder musst das selbst aufsetzen (Ceph, GlusterFS,...). Das funktioniert hier bei Netcup aber leider eher schlecht als recht. Es gibt natürlich auch noch den etwas seltenen Fall, dass gar kein Shared Storage benötigt wird. Dann geht es natürlich auch ohne. Aber in der Praxis habe ich das ehrlich gesagt noch nie gesehen :).


    Aus meiner Erfahrung funktioniert das hier bei Netcup nicht wirklich gut. Hier brauchst du entweder eine richtige Cloud oder aber recht performante Bare Metal Server. Zumindest für alles, was über eine kleine Dev Umgebung hinaus geht.

  • Das deutet jedenfalls mal darauf hin, dass ein automatischer Wechsel möglich ist.

    Das habe ich gelesen, aber keine weiteren Informationen dazu gefunden.



    Du hast im Moment nur einen Worker Node aufgelistet. Sind da noch weitere geplant? Sonst könnte man sich den HA LB ja eigentlich auch gleich sparen. Wenn es noch weitere geben sollte, wie willst du das mit dem Storage machen? Normalerweise brauchst du hier ja einen Storage as a Service oder musst das selbst aufsetzen (Ceph, GlusterFS,...). Das funktioniert hier bei Netcup aber leider eher schlecht als recht. Es gibt natürlich auch noch den etwas seltenen Fall, dass gar kein Shared Storage benötigt wird. Dann geht es natürlich auch ohne. Aber in der Praxis habe ich das ehrlich gesagt noch nie gesehen :).


    Aus meiner Erfahrung funktioniert das hier bei Netcup nicht wirklich gut. Hier brauchst du entweder eine richtige Cloud oder aber recht performante Bare Metal Server. Zumindest für alles, was über eine kleine Dev Umgebung hinaus geht.

    Ich weiß nicht, woran es genau liegt, aber bei mir scheint sich immer mal meine Kube-API kurz zu verabschieden, das reicht aber aus um das halbe system runter zu reißen (die stateful sets, was dank readyness probe dann auch die pods mit reißt.

    Daher wollte ich eben diese etwas ausfallsicherer machen. Beim speicher hatte ich an Longhorn gedacht, sobald ich auch mehr als einen Worker habe (der muss ja auch erst mal voll werden ^^) könnte ich so den Speicher erweitern und ebenfalls ausfallsicherer machen. Backups unterstützt Longhorn über S3, ebenso wie Snapshots.


    Dennoch hat mich dein letzter Absatz überlegen lassen, ob ich nicht vielleicht doch mit Kops bei AWS ein Cluster aufsetze. Preislich muss ich da halt schauen, was mich die einzelnen Nodes kosten. Schade eigentlich - ja ich weiß Netcup ist ein Massenhoster - das es hier irgendwie noch nicht so richtig fluppt.

  • Das deutet jedenfalls mal darauf hin, dass ein automatischer Wechsel möglich ist.

    Den Automatismus hat jedoch der Kunde unter Verwendung der API (Methode changeIPRouting) selbst bereitzustellen; es gibt meines Wissens keine Möglichkeit, über die API eine Liste von Servern zu definieren, welche sich eine IP derart "teilen", dass bei einem definierten Ausfall des Servers, dem die IP zu diesem Zeitpunkt zugeordnet wurde, eine Übertragung seitens eines Netcup-Systems erfolgt. (Das würde ein eigenes Monitoring überflüssig machen.)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Ich weiß nicht, woran es genau liegt, aber bei mir scheint sich immer mal meine Kube-API kurz zu verabschieden, das reicht aber aus um das halbe system runter zu reißen (die stateful sets, was dank readyness probe dann auch die pods mit reißt.

    Daher wollte ich eben diese etwas ausfallsicherer machen.

    Ich würde mir hier mal die Master Nodes anschauen. Ich befürchte nämlich, dass die VPS 500 G8 dafür etwas unterdimensioniert sind. Gerade der Etcd Cluster wird mit den wenigen Ressourcen etwas leiden. Ich kann mir sehr gut vorstellen, dass es daran liegt. Hier würde ich schon mindestens einen VPS 1000 nehmen. Bzw. der der kube-apiserver Prozess an sich braucht schon einiges an CPU Leistung. Auf meinen Master Nodes ist das immer mit der Prozess, der für die höchste Auslastung sorgt. Daher hätte ich persönlich ein eher ungutes Gefühl, wenn man das auf so "kleinen" VPS laufen lässt. Offizielle Empfehlung lautet: 4 CPUs, 16 GB RAM. In der Regel kommt man auch mit etwas weniger klar, aber dann sollten die CPUs dediziert sein (wie z.B. bei den RS Servern). Bei den Shared VPS Ressourcen wäre ich da vorsichtig.

  • Den Automatismus hat jedoch der Kunde unter Verwendung der API (Methode changeIPRouting) selbst bereitzustellen; es gibt meines Wissens keine Möglichkeit, über die API eine Liste von Servern zu definieren, welche sich eine IP derart "teilen", dass bei einem definierten Ausfall des Servers, dem die IP zu diesem Zeitpunkt zugeordnet wurde, eine Übertragung seitens eines Netcup-Systems erfolgt. (Das würde ein eigenes Monitoring überflüssig machen.)

    Dann bräuchte ich ein externes System, dass mittels keepalive schaut, ob die LBs noch da sind und das ggf. umlegt... also dann wird das wohl eher nichts...

  • Dann bräuchte ich ein externes System, dass mittels keepalive schaut, ob die LBs noch da sind und das ggf. umlegt... also dann wird das wohl eher nichts...

    Das könnten die LB aber auch selbst machen (z.B. mit keepalived). So ein ähnliches Setup hatte ich auch mal im Einsatz. Damals war das mit den Failover IPs aber noch ziemlich verbuggt, weshalb das in der Praxis nicht wirklich funktioniert hat. Ich hoffe, das klappt mittlerweile besser. Aber mit einem einfachen Curl Script können die LBs auch selbst schauen, ob der andere noch da ist und ggfs. die IP switchen. Ein zusätzliches, externes System ist hier nicht zwingend erforderlich.

  • Das könnten die LB aber auch selbst machen (z.B. mit keepalived). So ein ähnliches Setup hatte ich auch mal im Einsatz. Damals war das mit den Failover IPs aber noch ziemlich verbuggt, weshalb das in der Praxis nicht wirklich funktioniert hat. Ich hoffe, das klappt mittlerweile besser. Aber mit einem einfachen Curl Script können die LBs auch selbst schauen, ob der andere noch da ist und ggfs. die IP switchen. Ein zusätzliches, externes System ist hier nicht zwingend erforderlich.

    Die gleiche Idee hatte ich zuerst auch, aber es gibt ja noch den Fall, dass sie nicht von außen erreichbar sind, dass muss ja auch noch geprüft werden.

  • Keepalived mit der Floating IP habe ich in Betrieb, bisher kann ich mich nicht beklagen. Prüfung erfoglt über eine IP des Cloud VLANs, von außen gibt's ein externes Monitoring das meldet ,wenn die Floating IP nicht erreichbar ist von mindestens 3 Standorten. 1 Standort reicht nicht aus. Ein weiteres Skript hat nur die Aufgabe die IPs rumzuschieben, falls die Node der neue Primary ist.

  • Keepalived mit der Floating IP habe ich in Betrieb, bisher kann ich mich nicht beklagen. Prüfung erfoglt über eine IP des Cloud VLANs, von außen gibt's ein externes Monitoring das meldet ,wenn die Floating IP nicht erreichbar ist von mindestens 3 Standorten. 1 Standort reicht nicht aus. Ein weiteres Skript hat nur die Aufgabe die IPs rumzuschieben, falls die Node der neue Primary ist.

    Das ist eben das Problem, da brauche ich weitere externe Systeme. Aber schön, das es prinzipiell klappt.

  • Brauchst du das nicht in jedem Fall, wenn du Erreichbarkeit von außerhalb garantieren willst?

    Man könnte sich überlegen, mehrere verschiedene "what-is-my-external-ip"-Dienste von innen (=VServer des Kubernetes-Clusters) abzufragen – unter der Annahme, dass eine enthaltene Rückantwort mit korrekter Information ein Nachweis der IP-Erreichbarkeit darstellt, wenngleich in der Regel nur für einen Port. Oder man verwendet TOR und erzwingt die Nutzung von Exitknoten aus verschiedenen Ländern.


    Die Frage ist hierbei, wie beispielsweise bei Nichterreichung des gesamten einzelnen Rechenzentrums verfahren werden soll, da ja in diesem Fall keine Nachricht über fehlgeschlagene Tests nach außen dringen können. Wenn man davon ausgeht, dass der Nutzer regelmäßig über erfolgreiche Tests benachrichtigt wird, benötigt es auf der Empfänger/-Clientseite eine Art "Totmannschaltung". Klingt nach "von hinten durch die Brust ins Auge" und ist de facto nur als "Notlösung" anzusehen, hat aber den Vorteil, dass man Ressourcen (Server/Monitoring-Dienste) einspart und zusätzliche Abhängigkeiten vermeidet (Monitoring-Lösungen sollten natürlich auch redundant sein).


    Um die Komplexität zu reduzieren, könnte man sich überlegen, den erstgenannten Ansatz mit dem Anmieten des kleinstmöglichen Serverpakets auf dem Markt zu kombinieren, welches nicht im selben Rechenzentrum angesiedelt ist wie alle anderen VServer; dies erspart obengenannte "Not-/Bastellösung"[*] und sollte eine gegenseitige Kontrolle des Monitoring-Systems und VServern des Kubernetes-Cluster ermöglichen – über den Daumen kann/muss man hierfür ca. einen EUR/Monat ansetzen, was IMHO nicht zu teuer ist. (Die Ausnutzung wechselnder Freikontingente bei verschiedenen Anbietern rechnet sich für diesen Einsatzzweck eigentlich nicht.)


    Daneben gibt es für eine begrenzte Anzahl von Tests auf dem Markt auch ein paar kostenlose/kostengünstige dedizierte "Monitoring-Pläne", welche sich ggf. einbinden lassen.


    Für eine wirklich garantierte Erreichbarkeit des Clusters muss sich dieses aber logischerweise über mehrere unabhängige Rechenzentren erstrecken.


    [*] hier primär auf die "Totmannschaltung" bezogen, weniger auf den TOR-Ansatz

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing