Kubernetes HA Setup mit Netcup - Frage

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")

Quote

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.

Quote from tab

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.)

Quote from t_b

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.

Quote from t_b

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.

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.

Quote from t_b

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?

Quote from cltrmx

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

Quote from Paul

..oder musst das selbst aufsetzen (Ceph, GlusterFS,...). Das funktioniert hier bei Netcup aber leider eher schlecht als recht.

Mein GlusterFS über drei Root Server läuft selbst über das kostenlose 100Mbit/s VLAN hervorragend.