Vielen Dank michaeleifel für die ausführliche Erklärung! Ich werde mich mal am Wochenende hinsetzen und versuchen das mit meinem Ansible Playbook nachzubauen.
Posts by voja
-
-
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. -
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.
-
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?
-
VPS 500 dürfte als Master reichen, ggf. VPS 100
Nachdem was ich gelesen habe ist der etcd etwas anfällig wenn die Maschine ausgelastet ist. Da hätte ich bei VPS bedenken.
Daher hätte ich etcd+controlplane auf einem Node vorgesehen.
-
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
-
Halt, des kann nicht stimmen, oder ist bei Dir Lok kaputt, nur weil die Strecke unterbrochen ist?
Nein, ich sehe in dem Fall ja nur die kaputte Strecke. 😃
-
wenn auf Grund eines Netzwerkproblems die Verbindung zwischen Agent und Monitoring unterbrochen ist?
in dem Fall würd einem das Monitoring System mitteilen,
dass der Server xy nicht erreichbar ist, aber das würd man ohne Agent auch wissen
Failure by Design?
Ohne Netzwerkverbindung wird aber kein Alarm die Maschine verlassen… Ich habe keinen Zugriff auf das Hostsystem um extern ne Box mit SMS Versand etc. anzuschließen. Sind ja auch Rootserver.
Immerhin weiß man, dass etwas auf der Maschine nicht stimmt. Aus der Summe der Meldungen kann man dann schon anfangen den Fehler zu suchen. Sollte der Agent abrauchen kriege ich das gemeldet, sollte das Netz abrauchen dito. Und alle anderen Fehler meldet das Monitoring. -
wenn ma am zum monitorenden System was installieren muss,
um es dann in ein Monitoring "einzuhängen" hat man bereits was falsch gemacht;
Worin besteht da das Problem? Ein Agent kommt lokal an alle Infos, die über das Netzwerk nicht zugänglich wären. Bei Icinga gibt es einen Check der prüft ob alle Agents verbunden sind. Plus man kann getrenntes Monitoring aufsetzen, dass prüft ob das Monitoring ansich läuft.
-
Heute ist gesetzlicher Feiertag in Baden-Württemberg. Daher dürfte es nur den Notfallsupport geben.
Die IP-Adresse wird unter den Netzwerkeinstellungen im SCP (und nicht im CCP) zugewiesen. -
Preisfrage: Wie bekomme ich ohne Reboot fehlerhafte Einträge (Dateisystem fuse.xyz) aus /proc/self/mounts entfernt?
Geht ein umount -f ?
-
Ja: Magenta Zuhause Hybrid von der Telekom. Der Tarif ist aber veraltet. Wie die Technik dahinter funktioniert weiß ich nicht, aber es sieht wie eine Art VPN aus.
Da braucht man aber einen Telekom Router für, oder? Das hätte ich gerne vermieden. Aktuell kriegt man das als Addon zum DSL.
-
Hallo zusammen,
hat jemand von euch aus DE einen Fallback auf LTE, falls der DSL-/Kabelanschluss ausfällt? Falls ja: welcher Tarif kommt zum Einsatz?
-
Habt ihr schon von FritzFrog gelesen?
-
lag auf diesem Server
Deswegen immer schön das Monitoring monitoren. 😎
-
Ein Server mehr oder weniger offline ... wer merkt das schon - haha.
Das Monitoring? 😉
-
Wenn das Hostsystem weg ist, brauchst du die Route nicht mehr löschen - weil dann ja auch keine Container mehr existieren, die diese Route nutzen könnten
Per SSH kannst du auch die erlaubten Kommandos auf jene beiden beschränken. Pubkey dahinter und gut ist.
Ich habe das jetzt so gelöst: der keepalived managed die Failover IPs nun auf dem VLAN Interface. Jedes Hostsystem hat für IPv4 die Route via VLAN Bridge gesetzt. Für IPv6 hängen die mit einer IP im Failover Netz. Damit gibt es nur statische Routen.
-
Wenn das Hostsystem weg ist, brauchst du die Route nicht mehr löschen - weil dann ja auch keine Container mehr existieren, die diese Route nutzen könnten
Per SSH kannst du auch die erlaubten Kommandos auf jene beiden beschränken. Pubkey dahinter und gut ist.
War falsch ausgedrückt von mir. Das SSH Kommando kann warum auch immer fehlschlagen und dann kann dieses Problem nicht vom Monitoring festgelegt werden, wenn die Route nicht passt. Das ist mir zu wackelig.
-
NAT + Failover-API
Die Failover-API wird vom keepalived in den Containern angesprochen. Das NAT müsste dann ja auch vom Container aus an/ausgeschaltet werden.
-
Hosts & Container - einfacher wäre aber über SSH ein ip r d und ip r a an den entsprechenden Host zu senden.
SSH finde ich an der Stelle heikel. Einmal wegen der Sicherheit und einmal für den Fall, wenn das SSH Kommando fehlschlägt, weil ein Hostsystem weg ist.
Ich werde mir nochmal durch den Kopf gehen lassen, ob ich das über das VLAN abgebildet bekomme.
